Bug 1469583
| Summary: | [Docs][RFE][Director] Selectively disable updates to existing nodes - e.g. when no change on them needed, like scaling-out computes | ||
|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Dan Macpherson <dmacpher> |
| Component: | documentation | Assignee: | Dan Macpherson <dmacpher> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Mikey Ariel <mariel> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 12.0 (Pike) | CC: | agurenko, jslagle, lbopf, mariel, mburns, sathlang, srevivo |
| Target Milestone: | ga | Keywords: | FutureFeature |
| Target Release: | 12.0 (Pike) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | docs-accepted | ||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-12-19 04:20:53 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1395308 | ||
| Bug Blocks: | |||
|
Description
Dan Macpherson
2017-07-11 14:08:38 UTC
Hi Mike, I think scale out operation is more a Compute matter, correct me if I'm wrong. Thanks, 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. 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. 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. Hi James, 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? 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 This content has been published as part of beta: https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/12-beta/html/director_installation_and_usage/sect-scaling_the_overcloud#Scaling-Blacklisting_Nodes |