tripleo

Bug #1782139
Comment #0

Comment 0 for bug 1782139

Revision history for this message

Bogdan Dobrelya (bogdando) wrote on 2018-07-17: [RFE] allow non existent --templates paths to be auto-populated for operators

When testing (or doing in production perhaps) mixed versions deployments of UC/OC and mixed upgrades, we/operators have to decouple the --templates paths, historically in quickstart and other places, like custom wrappers, but not in the product (tripleoclient et al). That is needed to not break the default RPM directory for the installed tripleo heat templates package, which is a subject of serial yum operations performed for the mixed deployment/upgrade cases.

Custom scripts/CI/QA tools (quickstart/infrared) does not scale and has to be maintained separately from tripleo, nor does this provide a solution for operators having these mixed use cases in production.

The --templates paths decoupling logic must be productized, therefore. An initial attempt had been made in [0], [1] but it was rejected. The current model for --templates is only:

1. (no --templates args, uses default /usr/share location)
2. --templates foo (foo must exist, so we use it)

The t-h-t decoupling RFE expects additional case 3 supported in the tripleoclient for the existing standalone/overcloud/undercloud deployment/upgrade commands:

3. -- templates foo (if foo does not exist, create and populate it from the default RPM directory effectively decoupling it for future use).

[0] https://review.openstack.org/#/c/582529/
[1] https://review.openstack.org/#/c/582916/

More background/facts on the RFE request:

* there was a *-compat RPM for exactly this purpose (diverging the mixed tht paths) a while back.
* in CI previously we unpacked the RPM to a different path to enable that behavior.
* ops are used to build custom wrappers around 'openstack overcloud deploy' that rsync-ed the content of the t-h-t located in /usr/share, and commited into a local git to run deployments based on a copy of the t-h-t and allowing it to diverge at will. Fact is: this is a strong advice @Tengu got from the Red Hat fast formation about Director, when he was in Barcelona for the Summit
* upgrades team maintains a lot of custom overrides and scripts for quickstart to support mixed upgrades and there are issues arise like https://bugs.launchpad.net/tripleo/+bug/1781227, which really should better off fixed in the client, than quickstart/infrared/you-name-it.

The --templates paths decoupling logic must be productized, therefore. An initial attempt had been made in [0], [1] but it was rejected. The current model for --templates is only:

1. (no --templates args, uses default /usr/share location)
2. --templates foo (foo must exist, so we use it)

The t-h-t decoupling RFE expects additional case 3 supported in the tripleoclient for the existing standalone/overcloud/undercloud deployment/upgrade commands:

3. -- templates foo (if foo does not exist, create and populate it from the default RPM directory effectively decoupling it for future use).

[0] https://review.openstack.org/#/c/582529/
[1] https://review.openstack.org/#/c/582916/

More background/facts on the RFE request:

* there was a *-compat RPM for exactly this purpose (diverging the mixed tht paths) a while back.
 * in CI previously we unpacked the RPM to a different path to enable that behavior.
 * ops are used to build custom wrappers around 'openstack overcloud deploy' that rsync-ed the content of the t-h-t located in /usr/share, and commited into a local git to run deployments based on a copy of the t-h-t and allowing it to diverge at will. Fact is: this is a strong advice @Tengu got from the Red Hat fast formation about Director, when he was in Barcelona for the Summit
 * upgrades team maintains a lot of custom overrides and scripts for quickstart to support mixed upgrades and there are issues arise like https://bugs.launchpad.net/tripleo/+bug/1781227, which really should better off fixed in the client, than quickstart/infrared/you-name-it.