Red Hat Bugzilla – Bug 1469583
[Docs][RFE][Director] Selectively disable updates to existing nodes - e.g. when no change on them needed, like scaling-out computes
Last modified: 2017-10-16 00:02:45 EDT
== DECRIPTION ==
Betfair would like to be able to prevent existing overcloud nodes from receiving updates when scale out operations are run through 'openstack overcloud deploy --scale-out' on the undercloud. Effectively, the requirement is to be able to add new nodes to an overcloud without touching the existing nodes at all, if that is desirable.
== DOCS IMPACT ==
Requires documentation in the Director Guide with the scaling chapter.
I think scale out operation is more a Compute matter, correct me if I'm wrong.
Here are the proposed upstream docs to use as the basis for the downstream docs:
Let me know if I can expand on anything.
Updating DFG to match the engineering RFE on which this was based.
(We use this field for tracking, so if it's supposed to be for Compute, we'll need confirmation from that DFG.)
Assigning to Dan for review.
We need very clear documentation of its limitations and warnings.
* blacklist and/or —skip-deploy-identifier should be supported on change of stack like scale or change of config (as long as that change is not needed on a given node)
* it is the responsibility of the operator to know where and what change needs to be applied if they want to exclude some node from the list.
* This is not applicable for updates and upgrades of environments as those procedures have their own ways how to select which node is actionable at what time.
* If the operator prevents a node from getting a needed configuration, they should be aware of the disclaimer that any other operations (like scale, updates and upgrades using OSP-d) of such environments are NOT supported after that point
** this includes updates/upgrades/scale up or down/node replacement
So I think we should test the feature itself and add successful update/upgrade after this feature was used. This should be the scope.
I know there was some discussion about backporting this to OSP11 and OSP10. Where did the DFG land on that decision?
(In reply to Dan Macpherson from comment #6)
> Hi James,
> I know there was some discussion about backporting this to OSP11 and OSP10.
> Where did the DFG land on that decision?
Just the --skip-deploy-identifier portion (not the blacklist) was backported to OSP11 and OSP10: