f1a4857d61
Ironic in API 1.82 added the option for nodes to be associated with a specific shard key. This can be used to partition up the nodes within a single ironic conductor group into smaller sets of nodes that can each be managed by their own nova-compute ironic service. We add a new [ironic]shard config option to allow operators to say which shard each nova-compute process should target. As such, when the shard is set we ignore the peer_list setting and always have a hash ring of one. Also corrects an issue where [ironic]/conductor_group was considered a mutable configuration; it is not mutable, nor is shards. In any situation where an operator changes the scope of nodes managed by a nova compute process, a restart is required. blueprint ironic-shards Co-Authored-By: Jay Faulkner <jay@jvf.cc> Change-Id: Ie0c71f7bc5a62d607ffd3134837299fee952a947
13 lines
626 B
YAML
13 lines
626 B
YAML
---
|
|
features:
|
|
- |
|
|
Ironic nova-compute services can now target a specific shard of ironic
|
|
nodes by setting the config ``[ironic]shard``.
|
|
This is particularly useful when using active-passive methods to choose
|
|
on which physical host your ironic nova-compute process is running,
|
|
while ensuring ``[DEFAULT]host`` stays the same for each shard.
|
|
You can use this alongside ``[ironic]conductor_group`` to further limit
|
|
which ironic nodes are managed by each nova-compute service.
|
|
Note that when you use ``[ironic]shard`` the ``[ironic]peer_list``
|
|
is hard coded to a single nova-compute service.
|