Back to bug 1381628
| Who | When | What | Removed | Added |
|---|---|---|---|---|
| Marios Andreou | 2016-10-04 15:22:07 UTC | Assignee | jstransk | mandreou |
| Marios Andreou | 2016-10-05 15:51:20 UTC | Blocks | 1337794 | |
| Marios Andreou | 2016-10-06 16:56:55 UTC | Link ID | OpenStack gerrit 382748 | |
| Marios Andreou | 2016-10-12 13:59:02 UTC | Status | NEW | POST |
| Jaromir Coufal | 2016-10-13 19:20:32 UTC | Priority | unspecified | high |
| Target Release | --- | 10.0 (Newton) | ||
| CC | jcoufal | |||
| Target Milestone | --- | ga | ||
| Mike Burns | 2016-10-14 17:16:59 UTC | Status | POST | MODIFIED |
| Fixed In Version | openstack-tripleo-heat-templates-5.0.0-0.20161008015357.0d3e3e3.1.el7ost | |||
| Jon Schlueter | 2016-10-14 17:35:20 UTC | CC | jschluet | |
| Target Milestone | ga | rc | ||
| errata-xmlrpc | 2016-10-17 12:47:50 UTC | Status | MODIFIED | ON_QA |
| Sofer Athlan-Guyot | 2016-10-19 12:14:50 UTC | CC | sathlang | |
| Randy Perryman | 2016-10-20 14:37:28 UTC | CC | randy_perryman | |
| Depends On | 1305654 | |||
| Randy Perryman | 2016-10-20 14:38:01 UTC | Depends On | 1305654 | |
| Randy Perryman | 2016-10-20 14:40:58 UTC | CC | mandreou | |
| Flags | needinfo?(mandreou) | |||
| Randy Perryman | 2016-10-20 14:41:16 UTC | Depends On | 1305654 | |
| Randy Perryman | 2016-10-20 16:30:00 UTC | Flags | needinfo?(mandreou) | |
| Randy Perryman | 2016-10-20 16:31:24 UTC | Blocks | 1387343 | |
| Randy Perryman | 2016-10-20 16:31:54 UTC | Blocks | 1387344 | |
| Karl Hastings | 2016-10-20 17:19:19 UTC | CC | kasmith | |
| Blocks | 1305654 | |||
| Depends On | 1305654 | |||
| Marios Andreou | 2016-10-21 07:57:58 UTC | Flags | needinfo?(mandreou) needinfo?(mandreou) | |
| Jaromir Coufal | 2016-10-28 07:18:54 UTC | Keywords | Triaged | |
| Arik Chernetsky | 2016-11-01 12:40:31 UTC | QA Contact | achernet | nlevinki |
| Arik Chernetsky | 2016-11-01 12:40:54 UTC | CC | achernet | |
| QA Contact | nlevinki | ohochman | ||
| Marios Andreou | 2016-11-29 12:25:28 UTC | Status | ON_QA | VERIFIED |
| CC | mlammon | |||
| Doc Text | Feature: As discussed at https://bugs.launchpad.net/tripleo/+bug/1630247 in upstream TripleO sahara services go from default On in Mitaka to default Off in Newton. As part of the upgrades procedure for OSP 9 to OSP 10 the sahara services are enabled (i.e. retained) by default. If the operator decides they do *not* want sahara after their upgrade, they need to include the provided -e 'major-upgrade-remove-sahara.yaml' environment file as part of the deployment command for the controller upgrade and converge steps (this environment file *must* be specified last, especially for the converge step, but it could be done for both steps to avoid confustion). The sahara services would not be restarted after the major upgrade in this case. Reason: If sahara services weren't handled as a special case during the OSP9 to OSP10 upgrade then they would not be enabled and/or configured by default in the upgraded OSP10 environment. Result: Sahara services are retained as part of the upgrade. The operator can still explicitly disable if so desired. Feature: Reason: Result: | |||
| Doc Type | If docs needed, set a value | Enhancement | ||
| Marios Andreou | 2016-11-29 12:26:06 UTC | Doc Text | Feature: As discussed at https://bugs.launchpad.net/tripleo/+bug/1630247 in upstream TripleO sahara services go from default On in Mitaka to default Off in Newton. As part of the upgrades procedure for OSP 9 to OSP 10 the sahara services are enabled (i.e. retained) by default. If the operator decides they do *not* want sahara after their upgrade, they need to include the provided -e 'major-upgrade-remove-sahara.yaml' environment file as part of the deployment command for the controller upgrade and converge steps (this environment file *must* be specified last, especially for the converge step, but it could be done for both steps to avoid confustion). The sahara services would not be restarted after the major upgrade in this case. Reason: If sahara services weren't handled as a special case during the OSP9 to OSP10 upgrade then they would not be enabled and/or configured by default in the upgraded OSP10 environment. Result: Sahara services are retained as part of the upgrade. The operator can still explicitly disable if so desired. Feature: Reason: Result: | Feature: As discussed at https://bugs.launchpad.net/tripleo/+bug/1630247 in upstream TripleO sahara services go from default On in Mitaka to default Off in Newton. As part of the upgrades procedure for OSP 9 to OSP 10 the sahara services are enabled (i.e. retained) by default. If the operator decides they do *not* want sahara after their upgrade, they need to include the provided -e 'major-upgrade-remove-sahara.yaml' environment file as part of the deployment command for the controller upgrade and converge steps (this environment file *must* be specified last, especially for the converge step, but it could be done for both steps to avoid confustion). The sahara services would not be restarted after the major upgrade in this case. Reason: If sahara services weren't handled as a special case during the OSP9 to OSP10 upgrade then they would not be enabled and/or configured by default in the upgraded OSP10 environment. Result: Sahara services are retained as part of the upgrade. The operator can still explicitly disable if so desired. Feature: |
| Martin Lopes | 2016-12-01 00:50:11 UTC | CC | mlopes | |
| Doc Text | Feature: As discussed at https://bugs.launchpad.net/tripleo/+bug/1630247 in upstream TripleO sahara services go from default On in Mitaka to default Off in Newton. As part of the upgrades procedure for OSP 9 to OSP 10 the sahara services are enabled (i.e. retained) by default. If the operator decides they do *not* want sahara after their upgrade, they need to include the provided -e 'major-upgrade-remove-sahara.yaml' environment file as part of the deployment command for the controller upgrade and converge steps (this environment file *must* be specified last, especially for the converge step, but it could be done for both steps to avoid confustion). The sahara services would not be restarted after the major upgrade in this case. Reason: If sahara services weren't handled as a special case during the OSP9 to OSP10 upgrade then they would not be enabled and/or configured by default in the upgraded OSP10 environment. Result: Sahara services are retained as part of the upgrade. The operator can still explicitly disable if so desired. Feature: | As described in https://bugs.launchpad.net/tripleo/+bug/1630247, the Sahara service in upstream Newton TripleO is now disabled by default. As part of the upgrade procedure from Red Hat OpenStack Platform 9 to Red Hat OpenStack Platform 10, the Sahara services are enabled/retained by default. If the operator decides they do *not* want Sahara after the upgrade, they need to include the provided `-e 'major-upgrade-remove-sahara.yaml'` environment file as part of the deployment command for the controller upgrade and converge steps. Note: this environment file *must* be specified last, especially for the converge step, but it could be done for both steps to avoid confusion. In this case, the Sahara services would not be restarted after the major upgrade. This approach allows Sahara services to be properly managed during the OSP9 to OSP10 upgrade, otherwise they would not have been enabled/configured by default in the upgraded OSP10 environment. As a result, Sahara services are retained as part of the upgrade. In addition, the operator can still explicitly disable Sahara, if necessary. |
||
| Martin Lopes | 2016-12-01 01:04:13 UTC | Doc Text | As described in https://bugs.launchpad.net/tripleo/+bug/1630247, the Sahara service in upstream Newton TripleO is now disabled by default. As part of the upgrade procedure from Red Hat OpenStack Platform 9 to Red Hat OpenStack Platform 10, the Sahara services are enabled/retained by default. If the operator decides they do *not* want Sahara after the upgrade, they need to include the provided `-e 'major-upgrade-remove-sahara.yaml'` environment file as part of the deployment command for the controller upgrade and converge steps. Note: this environment file *must* be specified last, especially for the converge step, but it could be done for both steps to avoid confusion. In this case, the Sahara services would not be restarted after the major upgrade. This approach allows Sahara services to be properly managed during the OSP9 to OSP10 upgrade, otherwise they would not have been enabled/configured by default in the upgraded OSP10 environment. As a result, Sahara services are retained as part of the upgrade. In addition, the operator can still explicitly disable Sahara, if necessary. | As described in https://bugs.launchpad.net/tripleo/+bug/1630247, the Sahara service in upstream Newton TripleO is now disabled by default. As part of the upgrade procedure from Red Hat OpenStack Platform 9 to Red Hat OpenStack Platform 10, the Sahara services are enabled/retained by default. If the operator decides they do not want Sahara after the upgrade, they need to include the provided `-e 'major-upgrade-remove-sahara.yaml'` environment file as part of the deployment command for the controller upgrade and converge steps. Note: this environment file must be specified last, especially for the converge step, but it could be done for both steps to avoid confusion. In this case, the Sahara services would not be restarted after the major upgrade. This approach allows Sahara services to be properly handled during the OSP9 to OSP10 upgrade, otherwise they would not have been enabled/configured by default in the upgraded OSP10 environment. As a result, Sahara services are retained as part of the upgrade. In addition, the operator can still explicitly disable Sahara, if necessary. |
| errata-xmlrpc | 2016-12-14 13:48:15 UTC | Status | VERIFIED | RELEASE_PENDING |
| errata-xmlrpc | 2016-12-14 16:07:45 UTC | Status | RELEASE_PENDING | CLOSED |
| Resolution | --- | ERRATA | ||
| Last Closed | 2016-12-14 11:07:45 UTC | |||
| Martin Lopes | 2017-01-10 03:21:36 UTC | Doc Text | As described in https://bugs.launchpad.net/tripleo/+bug/1630247, the Sahara service in upstream Newton TripleO is now disabled by default. As part of the upgrade procedure from Red Hat OpenStack Platform 9 to Red Hat OpenStack Platform 10, the Sahara services are enabled/retained by default. If the operator decides they do not want Sahara after the upgrade, they need to include the provided `-e 'major-upgrade-remove-sahara.yaml'` environment file as part of the deployment command for the controller upgrade and converge steps. Note: this environment file must be specified last, especially for the converge step, but it could be done for both steps to avoid confusion. In this case, the Sahara services would not be restarted after the major upgrade. This approach allows Sahara services to be properly handled during the OSP9 to OSP10 upgrade, otherwise they would not have been enabled/configured by default in the upgraded OSP10 environment. As a result, Sahara services are retained as part of the upgrade. In addition, the operator can still explicitly disable Sahara, if necessary. | As described in https://bugs.launchpad.net/tripleo/+bug/1630247, the Sahara service in upstream Newton TripleO is now disabled by default. As part of the upgrade procedure from Red Hat OpenStack Platform 9 to Red Hat OpenStack Platform 10, the Sahara services are enabled/retained by default. If the operator decides they do not want Sahara after the upgrade, they need to include the provided `-e 'major-upgrade-remove-sahara.yaml'` environment file as part of the deployment command for the controller upgrade and converge steps. Note: this environment file must be specified last, especially for the converge step, but it could be done for both steps to avoid confusion. In this case, the Sahara services would not be restarted after the major upgrade. This approach allows Sahara services to be properly handled during the OSP9 to OSP10 upgrade. As a result, Sahara services are retained as part of the upgrade. In addition, the operator can still explicitly disable Sahara, if necessary. |
Back to bug 1381628