| 2018-07-17 12:34:59 |
Bogdan Dobrelya |
bug |
|
|
added bug |
| 2018-07-17 12:35:33 |
Bogdan Dobrelya |
tripleo: milestone |
|
stein-1 |
|
| 2018-07-17 12:35:37 |
Bogdan Dobrelya |
tripleo: importance |
Undecided |
High |
|
| 2018-07-17 12:35:43 |
Bogdan Dobrelya |
tags |
|
ux |
|
| 2018-07-17 12:37:06 |
Bogdan Dobrelya |
description |
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. |
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) decoupling implementations 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. |
|
| 2018-07-17 12:39:13 |
Bogdan Dobrelya |
description |
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) decoupling implementations 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. |
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) decoupling implementations 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). Alternatively, there can be some git/gerrit integration as well, for example pushing patches each time the templates population occurs)
[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. |
|
| 2018-07-17 12:50:04 |
Bogdan Dobrelya |
tripleo: status |
New |
Opinion |
|
| 2018-07-17 12:50:18 |
Bogdan Dobrelya |
tripleo: importance |
High |
Medium |
|
| 2018-07-17 12:50:37 |
Bogdan Dobrelya |
tags |
ux |
upgrade ux |
|
| 2018-07-17 13:13:36 |
Bogdan Dobrelya |
description |
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) decoupling implementations 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). Alternatively, there can be some git/gerrit integration as well, for example pushing patches each time the templates population occurs)
[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. |
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) decoupling implementations 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. Especially now that we also have underclouds installed from heat tenmplates, like overclouds do. 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). Alternatively, there can be some git/gerrit integration as well, for example pushing patches each time the templates population occurs)
[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. |
|
| 2018-07-17 13:14:28 |
Bogdan Dobrelya |
summary |
[RFE] allow non existent --templates paths to be auto-populated for operators |
[RFE] support automatic t-h-t decoupling and versioning for mixed UC/OC cases (git integration) |
|
| 2018-07-17 13:23:23 |
Bogdan Dobrelya |
description |
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) decoupling implementations 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. Especially now that we also have underclouds installed from heat tenmplates, like overclouds do. 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). Alternatively, there can be some git/gerrit integration as well, for example pushing patches each time the templates population occurs)
[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. |
=============
Problem scope
=============
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) decoupling implementations 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. Especially now that we also have underclouds installed from heat tenmplates, like overclouds do. 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)
More background/facts on the RFE request (think of it as alternatives?):
* 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.
=================
Proposed solution
=================
The t-h-t decoupling RFE expects additional case 3 supported in the tripleoclient --templates logic 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). That is a very basic automation, a first step TBD. An initial attempt had been made in [0], [1] but it was rejected. Ideally, there should be some git (optionally, with gerrit) integration instead. Like pushing patches instead of committing changes in the example steps below, each time the initial templates population and an rsync update operation happens in the client automation.
[0] https://review.openstack.org/#/c/582529/
[1] https://review.openstack.org/#/c/582916/
=======
Example
=======
Assumes any customizations to the heat templates should be done by operators manually, before/after the committing steps.
(mixed deploy UC X, OC Y, where X < Y, or X > Y)
1. install openstack-tripleo-heat-templates RPM version X (it is in /usr/share/openstack-tripleo-heat-templates on undercloud)
2. depoy undercloud version X w/o custom --templates args
#? cannot use default templates path (/usr/share rpm DIR), so tht gets populated into an *empty* (what else it can be?) --templates /tmp/notexisted from RPM dir
3. copy t-h-t used for the step 2 to some uc-tht path, and commit as a git repo uc-tht
4. install t-h-t RPM Y for overcloud of version Y (not exactly yum update'd, but may be another release repo), caveats:
a. to be safe on installing other version, purge the /usr/share/openstack-tripleo-heat-templates, assuming we cannot fully trust the packaging post- actions?
5. deploy overcloud version Y w/o custom --templates args
6. copy t-h-t used for the step 6 to some oc-tht path, and commit as a git repo oc-tht
#?, w/o messing into UC tht X (see the step 2 notes) , using whatever --templates dir it wants (quickstart still uses /usr/share... default, this cannot be changed yet)
(mixed upgrade)
7. update undercloud tht RPM to X', caveats:
a. this overrides the /usr/share contents used to deploy overcloud Y before
b. to be safe on upgrading, purge the /usr/share/openstack-tripleo-heat-templates, assuming we cannot fully trust the packaging post- actions?
c. copy installed t-h-t to the uc-tht path,
8. upgrade undercloud to X', using --templates uc-tht
9. commit changes from the step 7.c in the repo uc-tht
10. update overcloud tht RPM to Y', caveats:
a. this overrides the /usr/share contents used to deploy overcloud Y before
b. to be safe on upgrading, purge the /usr/share/openstack-tripleo-heat-templates, assuming we cannot fully trust the packaging post- actions?
c. copy installed t-h-t to the oc-tht path
11. upgrade overcloud to Y', using --templates oc-tht
12. commit changes from the step 10.c in the repo oc-tht
13. from now on, any future uc/oc maintanance command should keep using the diverged --templates paths
a. caveats: all those purge/copy/commit dances are the must, each time, and become highly error-prone now that we have also undercloud heat installer instead of instack.
b. the steps 3, 6, 7.c, 9, 10.c, 12 should be took off its high error-proneness by the client automation and built in git integration |
|
| 2018-07-17 13:45:39 |
Bogdan Dobrelya |
description |
=============
Problem scope
=============
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) decoupling implementations 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. Especially now that we also have underclouds installed from heat tenmplates, like overclouds do. 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)
More background/facts on the RFE request (think of it as alternatives?):
* 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.
=================
Proposed solution
=================
The t-h-t decoupling RFE expects additional case 3 supported in the tripleoclient --templates logic 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). That is a very basic automation, a first step TBD. An initial attempt had been made in [0], [1] but it was rejected. Ideally, there should be some git (optionally, with gerrit) integration instead. Like pushing patches instead of committing changes in the example steps below, each time the initial templates population and an rsync update operation happens in the client automation.
[0] https://review.openstack.org/#/c/582529/
[1] https://review.openstack.org/#/c/582916/
=======
Example
=======
Assumes any customizations to the heat templates should be done by operators manually, before/after the committing steps.
(mixed deploy UC X, OC Y, where X < Y, or X > Y)
1. install openstack-tripleo-heat-templates RPM version X (it is in /usr/share/openstack-tripleo-heat-templates on undercloud)
2. depoy undercloud version X w/o custom --templates args
#? cannot use default templates path (/usr/share rpm DIR), so tht gets populated into an *empty* (what else it can be?) --templates /tmp/notexisted from RPM dir
3. copy t-h-t used for the step 2 to some uc-tht path, and commit as a git repo uc-tht
4. install t-h-t RPM Y for overcloud of version Y (not exactly yum update'd, but may be another release repo), caveats:
a. to be safe on installing other version, purge the /usr/share/openstack-tripleo-heat-templates, assuming we cannot fully trust the packaging post- actions?
5. deploy overcloud version Y w/o custom --templates args
6. copy t-h-t used for the step 6 to some oc-tht path, and commit as a git repo oc-tht
#?, w/o messing into UC tht X (see the step 2 notes) , using whatever --templates dir it wants (quickstart still uses /usr/share... default, this cannot be changed yet)
(mixed upgrade)
7. update undercloud tht RPM to X', caveats:
a. this overrides the /usr/share contents used to deploy overcloud Y before
b. to be safe on upgrading, purge the /usr/share/openstack-tripleo-heat-templates, assuming we cannot fully trust the packaging post- actions?
c. copy installed t-h-t to the uc-tht path,
8. upgrade undercloud to X', using --templates uc-tht
9. commit changes from the step 7.c in the repo uc-tht
10. update overcloud tht RPM to Y', caveats:
a. this overrides the /usr/share contents used to deploy overcloud Y before
b. to be safe on upgrading, purge the /usr/share/openstack-tripleo-heat-templates, assuming we cannot fully trust the packaging post- actions?
c. copy installed t-h-t to the oc-tht path
11. upgrade overcloud to Y', using --templates oc-tht
12. commit changes from the step 10.c in the repo oc-tht
13. from now on, any future uc/oc maintanance command should keep using the diverged --templates paths
a. caveats: all those purge/copy/commit dances are the must, each time, and become highly error-prone now that we have also undercloud heat installer instead of instack.
b. the steps 3, 6, 7.c, 9, 10.c, 12 should be took off its high error-proneness by the client automation and built in git integration |
=============
Problem scope
=============
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) decoupling implementations 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. Especially now that we also have underclouds installed from heat tenmplates, like overclouds do. 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)
More background/facts on the RFE request (think of it as alternatives?):
* there was a *-compat RPM for exactly this purpose (diverging the mixed tht paths) a while back. If we do not really want automate this in client, let's document the mixed upgrades scenario in the advanced installation guide then, including anything needed to be done to the *-compat things.
* 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.
=================
Proposed solution
=================
The t-h-t decoupling RFE expects additional case 3 supported in the tripleoclient --templates logic 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).
An initial attempt had been proposed in [0] (reverted), [1]. These correspond to partial implementing the step #3 in the example. In the end, there should be git (optionally, with gerrit) integration instead for the steps 3, 6, 7.c, 9, 10.c, 12.
There is implementation alternatives, like pushing patches instead of committing changes in the example steps below, each time the initial templates population (steps 3, 6) and rsync updates happening in the client automation.
The trigger for the git integration should be also another
CLI option perhaps, instead of overloading --templates missing logic.
[0] https://review.openstack.org/#/c/582529/
[1] https://review.openstack.org/#/c/582916/
=======
Example
=======
Assumes any customizations to the heat templates should be done by operators manually, before/after the committing steps.
(mixed deploy UC X, OC Y, where X < Y, or X > Y)
1. install openstack-tripleo-heat-templates RPM version X (it is in /usr/share/openstack-tripleo-heat-templates on undercloud)
2. depoy undercloud version X w/o custom --templates args
#? cannot use default templates path (/usr/share rpm DIR), so tht gets populated into an *empty* (what else it can be?) --templates /tmp/notexisted from RPM dir
3. copy t-h-t used for the step 2 to some uc-tht path, and commit as a git repo uc-tht
4. install t-h-t RPM Y for overcloud of version Y (not exactly yum update'd, but may be another release repo), caveats:
a. to be safe on installing other version, purge the /usr/share/openstack-tripleo-heat-templates, assuming we cannot fully trust the packaging post- actions?
5. deploy overcloud version Y w/o custom --templates args
6. copy t-h-t used for the step 6 to some oc-tht path, and commit as a git repo oc-tht
#?, w/o messing into UC tht X (see the step 2 notes) , using whatever --templates dir it wants (quickstart still uses /usr/share... default, this cannot be changed yet)
(mixed upgrade)
7. update undercloud tht RPM to X', caveats:
a. this overrides the /usr/share contents used to deploy overcloud Y before
b. to be safe on upgrading, purge the /usr/share/openstack-tripleo-heat-templates, assuming we cannot fully trust the packaging post- actions?
c. copy installed t-h-t to the uc-tht path,
8. upgrade undercloud to X', using --templates uc-tht
9. commit changes from the step 7.c in the repo uc-tht
10. update overcloud tht RPM to Y', caveats:
a. this overrides the /usr/share contents used to deploy overcloud Y before
b. to be safe on upgrading, purge the /usr/share/openstack-tripleo-heat-templates, assuming we cannot fully trust the packaging post- actions?
c. copy installed t-h-t to the oc-tht path
11. upgrade overcloud to Y', using --templates oc-tht
12. commit changes from the step 10.c in the repo oc-tht
13. from now on, any future uc/oc maintanance command should keep using the diverged --templates paths
a. caveats: all those purge/copy/commit dances are the must, each time, and become highly error-prone now that we have also undercloud heat installer instead of instack.
b. the steps 3, 6, 7.c, 9, 10.c, 12 should be took off its high error-proneness by the client automation and built in git integration |
|
| 2018-09-11 10:12:57 |
Bogdan Dobrelya |
summary |
[RFE] support automatic t-h-t decoupling and versioning for mixed UC/OC cases (git integration) |
[RFE] support automatic t-h-t decoupling and versioning for mixed UC/OC cases (git integration for deployment plans and tht) |
|
| 2018-09-11 13:41:51 |
Thomas Herve |
bug |
|
|
added subscriber Thomas Herve |
| 2018-10-18 12:26:45 |
Bogdan Dobrelya |
tripleo: status |
Opinion |
Triaged |
|
| 2018-10-18 12:26:48 |
Bogdan Dobrelya |
tripleo: importance |
Medium |
Wishlist |
|
| 2018-10-30 16:24:26 |
Juan Antonio Osorio Robles |
tripleo: milestone |
stein-1 |
stein-2 |
|
| 2018-11-05 13:18:03 |
Bogdan Dobrelya |
tags |
upgrade ux |
edge upgrade ux |
|
| 2019-01-13 22:44:24 |
Emilien Macchi |
tripleo: milestone |
stein-2 |
stein-3 |
|
| 2019-03-14 02:28:44 |
Alex Schultz |
tripleo: milestone |
stein-3 |
train-1 |
|
| 2019-06-07 20:13:44 |
Alex Schultz |
tripleo: milestone |
train-1 |
train-2 |
|
| 2019-07-29 14:39:45 |
Alex Schultz |
tripleo: milestone |
train-2 |
train-3 |
|
| 2019-09-11 21:25:22 |
Alex Schultz |
tripleo: milestone |
train-3 |
ussuri-1 |
|
| 2019-12-19 14:58:55 |
Emilien Macchi |
tripleo: milestone |
ussuri-1 |
ussuri-2 |
|
| 2020-02-10 20:41:51 |
wes hayutin |
tripleo: milestone |
ussuri-2 |
ussuri-3 |
|
| 2020-04-13 18:18:39 |
wes hayutin |
tripleo: milestone |
ussuri-3 |
ussuri-rc3 |
|
| 2020-05-26 20:46:04 |
wes hayutin |
tripleo: milestone |
ussuri-rc3 |
victoria-1 |
|
| 2020-07-28 12:38:43 |
Emilien Macchi |
tripleo: milestone |
victoria-1 |
victoria-3 |
|
| 2020-11-03 11:55:38 |
Marios Andreou |
tripleo: milestone |
victoria-3 |
wallaby-1 |
|
| 2020-12-08 11:26:10 |
Marios Andreou |
tripleo: milestone |
wallaby-1 |
wallaby-2 |
|
| 2021-01-29 15:13:39 |
Marios Andreou |
tripleo: milestone |
wallaby-2 |
wallaby-3 |
|
| 2021-02-18 16:46:29 |
Marios Andreou |
tripleo: status |
Triaged |
Incomplete |
|
| 2021-02-18 16:46:29 |
Marios Andreou |
tripleo: milestone |
wallaby-3 |
|
|
| 2021-04-20 04:17:54 |
Launchpad Janitor |
tripleo: status |
Incomplete |
Expired |
|
