Bug 1469583 - [Docs][RFE][Director] Selectively disable updates to existing nodes - e.g. when no change on them needed, like scaling-out computes
[Docs][RFE][Director] Selectively disable updates to existing nodes - e.g. wh...
Product: Red Hat OpenStack
Classification: Red Hat
Component: documentation (Show other bugs)
12.0 (Pike)
Unspecified Unspecified
high Severity high
: ga
: 12.0 (Pike)
Assigned To: Dan Macpherson
Mikey Ariel
: FutureFeature
Depends On: 1395308
  Show dependency treegraph
Reported: 2017-07-11 10:08 EDT by Dan Macpherson
Modified: 2017-12-18 23:20 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-12-18 23:20:53 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
OpenStack gerrit 485211 None None None 2017-07-27 11:21 EDT

  None (edit)
Description Dan Macpherson 2017-07-11 10:08:38 EDT
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.

Requires documentation in the Director Guide with the scaling chapter.
Comment 1 Sofer Athlan-Guyot 2017-07-25 04:34:07 EDT
Hi Mike,

I think scale out operation is more a Compute matter, correct me if I'm wrong.

Comment 2 James Slagle 2017-07-27 11:21:38 EDT
Here are the proposed upstream docs to use as the basis for the downstream docs:

Let me know if I can expand on anything.
Comment 3 Lucy Bopf 2017-08-03 02:16:03 EDT
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.)
Comment 4 Lucy Bopf 2017-08-07 22:36:28 EDT
Assigning to Dan for review.
Comment 5 James Slagle 2017-08-14 17:12:14 EDT
We need very clear documentation of its limitations and warnings.

To summarize:
* 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.
Comment 6 Dan Macpherson 2017-09-18 01:00:17 EDT
Hi James,

I know there was some discussion about backporting this to OSP11 and OSP10. Where did the DFG land on that decision?
Comment 7 James Slagle 2017-10-05 10:13:57 EDT
(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:

OSP11: https://bugzilla.redhat.com/show_bug.cgi?id=1451322
OSP10: https://bugzilla.redhat.com/show_bug.cgi?id=1469453

Note You need to log in before you can comment on or make changes to this bug.