Bug 1930633
| Summary: | [RFE] Add an option to serialize pre-deployment and basic config steps for overcloud deployment and minor updates | ||
|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Alex Stupnikov <astupnik> |
| Component: | openstack-tripleo | Assignee: | James Slagle <jslagle> |
| Status: | NEW --- | QA Contact: | Joe H. Rahme <jhakimra> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | 17.0 (Wallaby) | CC: | dsneddon, hjensas, jelle.hoylaerts.ext, mburns, sbaker |
| Target Milestone: | --- | Keywords: | FutureFeature |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | Bug | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Alex Stupnikov
2021-02-19 10:10:55 UTC
In future versions there might be a way to execute the network deployment outside of the deployment which might assist in this. However there seems to be a larger issue around os-net-config's ability to tweak some settings without causing network outages. I don't think serializing these steps makes sense from a overall execution time perspective. I think perhaps the RFE here should be how can we reduce the impact of network updates in general rather than asking for a solution in the deployment framework. The issue here is that the playbook runs for all hosts at the same time. We want the controller role only to run updates serially. This works for many things, but with NetworkDeploymentActions we need that to happen serially on the controllers. I suspect that there are other services which would be risky to update in serial on the controllers. Other roles can run playbooks at the same time, but cluster members should not be updated at the same time. What do we need to do to run NetworkDeploymentActions (and all network actions) serially on the controller roles? This should happen one layer up from os-net-config, in the undercloud. (In reply to Dan Sneddon from comment #2) > I suspect that there are other services which would be risky to update in > serial on the controllers. Other roles can run playbooks at the same time, > but cluster members should not be updated at the same time. Sorry, I meant it is risky to update all controllers in parallel. Controllers should be updated serially, computes in parallel, and I won't comment about what should happen in the case of storage nodes. (In reply to Alex Schultz from comment #1) > In future versions there might be a way to execute the network deployment > outside of the deployment which might assist in this. However there seems to > be a larger issue around os-net-config's ability to tweak some settings > without causing network outages. I don't think serializing these steps > makes sense from a overall execution time perspective. I think perhaps the > RFE here should be how can we reduce the impact of network updates in > general rather than asking for a solution in the deployment framework. From an execution time perspective, there are only 3 controllers, so executing in serial vs. parallel would not add much time. The problem is that there doesn't exist today a way to update controllers in a serial fashion. We could implement that in networking, but that isn't where it belongs and I suspect we will eventually run into other services which should not be updated on all controllers at the same time. I'm going to pass this back to DF since we need a general framework mechanism to specify whether a particular task should run serially (controller nodes) or in parallel (all other roles). Once this mechanism exists we can switch the os-net-config calls to use it. Technically it's not necessarily just 3 nodes as it's any nodes running pacemaker services. I don't think this is a good idea to try and handle in the framework. The better solution would be to remove network configuration from the deployment process entirely so that it can be performed out of band. |