Bug 1469583 - [Docs][RFE][Director] Selectively disable updates to existing nodes - e.g. when no change on them needed, like scaling-out computes
Summary: [Docs][RFE][Director] Selectively disable updates to existing nodes - e.g. wh...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: documentation
Version: 12.0 (Pike)
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ga
: 12.0 (Pike)
Assignee: Dan Macpherson
QA Contact: Mikey Ariel
URL:
Whiteboard: docs-accepted
Depends On: 1395308
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-07-11 14:08 UTC by Dan Macpherson
Modified: 2017-12-19 04:20 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-12-19 04:20:53 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
OpenStack gerrit 485211 0 None None None 2017-07-27 15:21:37 UTC

Description Dan Macpherson 2017-07-11 14:08:38 UTC
== 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.

Comment 1 Sofer Athlan-Guyot 2017-07-25 08:34:07 UTC
Hi Mike,

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

Thanks,

Comment 2 James Slagle 2017-07-27 15:21:38 UTC
Here are the proposed upstream docs to use as the basis for the downstream docs:
https://review.openstack.org/485211

Let me know if I can expand on anything.

Comment 3 Lucy Bopf 2017-08-03 06:16:03 UTC
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-08 02:36:28 UTC
Assigning to Dan for review.

Comment 5 James Slagle 2017-08-14 21:12:14 UTC
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 05:00:17 UTC
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 14:13:57 UTC
(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?

Dan,

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.