You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Based on fencing policies a set of nodes can share identical configuration. We should set the configuration only once instead of doing that for each node separately.
For example, if "fence-config-" + nodeName does not exist, try "fence-config-type-" + labelValue(type) instead. The fall-back can be hierarchical as long as it is simple enough to implement without unneeded complexity. Of course, the set of labels that can be actually used this way needs to be limited. It could be part of the fence controller configuration. E.g.
...
node-config-label-fallback:
- type
- label2
- label3
...
In case the "fence-config-type-" + labelValue(type) does not exist, try "fence-config-label2-" + labelValue(label2). And so on.
E.g. a node has type=compute label, then look for "fence-config-type-compute" configmap.
The text was updated successfully, but these errors were encountered:
Based on fencing policies a set of nodes can share identical configuration. We should set the configuration only once instead of doing that for each node separately.
For example, if
"fence-config-" + nodeName
does not exist, try"fence-config-type-" + labelValue(type)
instead. The fall-back can be hierarchical as long as it is simple enough to implement without unneeded complexity. Of course, the set of labels that can be actually used this way needs to be limited. It could be part of the fence controller configuration. E.g.In case the
"fence-config-type-" + labelValue(type)
does not exist, try"fence-config-label2-" + labelValue(label2)
. And so on.E.g. a node has
type=compute
label, then look for"fence-config-type-compute"
configmap.The text was updated successfully, but these errors were encountered: