| Summary: | OS::TripleO::NodeExtraConfigPost customizations with a CREATE action are also re-run on upgrade | ||
|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Udi Kalifon <ukalifon> |
| Component: | rhosp-director | Assignee: | Angus Thomas <athomas> |
| Status: | CLOSED NOTABUG | QA Contact: | Arik Chernetsky <achernet> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 8.0 (Liberty) | CC: | bnemec, ccamacho, dbecker, mandreou, mbultel, mburns, mcornea, morazi, rhel-osp-director-maint, rhos-flags, ukalifon |
| Target Milestone: | zstream | Keywords: | Triaged |
| Target Release: | 8.0 (Liberty) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-09-07 11:12:56 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Udi Kalifon
2016-04-17 19:40:58 UTC
Hey Udi, we just chatted with jistr about this on irc. It seems like another consequence of our explicit setting of OS::Heat::None for the entire OS::TripleO::ControllerPostDeployment: during the first two upgrade steps. SO when it gets unset back to normal on the converge it gets treated as create. I don't know what the specific extra config being applied here is and if it causes problems. But I think this is a fair point that you would not expect it to run. How about, we note the issue in the docs, that any node extra config will be re-executed on upgrade. If you don't want that to happen then explicitly set the OS::TripleO::NodeExtraConfigPost to OS::Heat::None in the pacemaker_converge.yaml environment file? I think it is a very complicated workaround, in an upgrade process which is already complicated enough... Setting OS::TripleO::NodeExtraConfigPost to OS::Heat::None can also have other implications, otherwise it would already be set like that (as it is in the first 2 steps). But I'm not an expert and it's not my decision to say if documenting it is enough. In any ways it would need a lot of testing. Due to the time of creation of this BZ I'll close it, please feel free to re-open it if it's required. |