Bug 1381628

Summary: sahara services during mitaka to newton upgrade go from default On to default Off
Product: Red Hat OpenStack Reporter: Marios Andreou <mandreou>
Component: openstack-tripleo-heat-templatesAssignee: Marios Andreou <mandreou>
Status: CLOSED ERRATA QA Contact: Omri Hochman <ohochman>
Severity: unspecified Docs Contact:
Priority: high    
Version: 10.0 (Newton)CC: achernet, jcoufal, jschluet, kasmith, mandreou, mburns, mlammon, mlopes, randy_perryman, rhel-osp-director-maint, sathlang
Target Milestone: rcKeywords: Triaged
Target Release: 10.0 (Newton)   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: openstack-tripleo-heat-templates-5.0.0-0.20161008015357.0d3e3e3.1.el7ost Doc Type: Enhancement
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. As a result, Sahara services are retained as part of the upgrade. In addition, the operator can still explicitly disable Sahara, if necessary.
Story Points: ---
Clone Of:
: 1387343 1387344 (view as bug list) Environment:
Last Closed: 2016-12-14 16:07:45 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 1305654, 1337794, 1387343, 1387344    

Description Marios Andreou 2016-10-04 15:20:55 UTC
Description of problem:
As described in the upstream bug @ https://bugs.launchpad.net/tripleo/+bug/1630247 Sahara services go from default On in OSP9 but default Off for OSP10.

This bug is to track the related changes for the downstream package builds (see upstream bug for details on reviews)

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Marios Andreou 2016-10-06 17:04:22 UTC
Adding a note here on request:

For the duration of the OSP9 to OSP10 upgrade we handle this special case and default to keeping the existing sahara services, both after the controller upgrade step and after the converge step. This is done with the review at [0] which has now landed into stable/newton.

However, *any* subsequent stack update operations will *have* to include the existing -e 'services/sahara.yaml' [1]  environment file, as part of the deployment command. Not doing so would mean that none of the Sahara related configuration would be effected, since by default Newton specifies that sahara services map to 'OS::Heat::None' [2]

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. The sahara services would not be restarted after the major upgrade in this case.



[0] https://review.openstack.org/#/c/382748/
[1] https://github.com/openstack/tripleo-heat-templates/blob/master/environments/services/sahara.yaml
[2] https://github.com/openstack/tripleo-heat-templates/blob/883addf267933395c580e0eab3efc379401c946c/overcloud-resource-registry-puppet.j2.yaml#L138

Comment 2 Marios Andreou 2016-10-12 13:59:02 UTC
moved to POST as it merged into newton upstream

Comment 5 Randy Perryman 2016-10-20 14:40:58 UTC
I am seeing the same thing with Upgrade from OSP 8 to OSP 9 is the same fix available for this?

Comment 6 Randy Perryman 2016-10-20 16:30:00 UTC
What rpm supplies the -e 'major-upgrade-remove-sahara.yaml'?  

I have installed the following:

openstack-tripleo-heat-templates-2.0.0-34.el7ost.noarch

Comment 7 Marios Andreou 2016-10-21 07:57:58 UTC
Hi Randy - I think you are seeing the opposite in fact. There was no sahara in 8 and then it was introduced as a service in 9 (so you would have gained a sahara service after upgrading 8->9).

The 'major-upgrade-remove-sahara.yaml' is new for Newton (see the gerrit review above in external trackers) so will be part of the 10 release.

I see you have filed two bugzillas which must be related to what you're seeing (BZ 1387344 and 1387343 - will comment there momentarily) but the fix for this bug is specific to a Mitaka to Newton upgrade (and so OSP9-->OSP10) and where the default path is to *keep* sahara, unless the operator chooses not to by including that env. file

Comment 8 mlammon 2016-11-22 15:33:26 UTC
Deployed RHOS 9 successfully
Upgrade 9-> and included /usr/share/openstack-tripleo-heat-templates/environments/major-upgrade-remove-sahara.yaml
during the control and convergence steps and upgrade was successful.

I saw no issues with controller and everything running


[heat-admin@controller-0 ~]$ sudo systemctl list-unit-files | grep sahara
openstack-sahara-all.service                       disabled
openstack-sahara-api.service                       disabled
openstack-sahara-engine.service                    disabled
 

Environment:
openstack-sahara-common-5.0.0-3.el7ost.noarch
openstack-sahara-engine-5.0.0-3.el7ost.noarch
openstack-sahara-api-5.0.0-3.el7ost.noarch
openstack-sahara-5.0.0-3.el7ost.noarch
openstack-sahara-ui-5.0.0-3.el7ost.noarch
[heat-admin@controller-0 ~]$

Comment 11 errata-xmlrpc 2016-12-14 16:07:45 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHEA-2016-2948.html