Bug 1387343

Summary: sahara services during mitaka to newton upgrade go from default Off to default On
Product: Red Hat OpenStack Reporter: Randy Perryman <randy_perryman>
Component: openstack-tripleo-heat-templatesAssignee: Jiri Stransky <jstransk>
Status: CLOSED DUPLICATE QA Contact: Arik Chernetsky <achernet>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 8.0 (Liberty)CC: achernet, jcoufal, jschluet, kasmith, mandreou, mburns, randy_perryman, rhel-osp-director-maint, sathlang
Target Milestone: ---   
Target Release: 10.0 (Newton)   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1381628 Environment:
Last Closed: 2016-10-21 12:01:16 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:
Bug Depends On: 1381628    
Bug Blocks: 1305654, 1337794    

Description Randy Perryman 2016-10-20 16:31:24 UTC 
+++ This bug was initially created as a clone of Bug #1381628 +++

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:

--- Additional comment from marios on 2016-10-06 13:04:22 EDT ---

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

--- Additional comment from marios on 2016-10-12 09:59:02 EDT ---

moved to POST as it merged into newton upstream

--- Additional comment from Randy Perryman on 2016-10-20 10:40:58 EDT ---

I am seeing the same thing with Upgrade from OSP 8 to OSP 9 is the same fix available for this?

--- Additional comment from Randy Perryman on 2016-10-20 12:30:00 EDT ---

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 1 Marios Andreou 2016-10-21 08:07:27 UTC 
A bit confused by the bug title here... in mitaka to newton it is exactly the opposite (on to off) - please clarify what we are tracking here. 

If it is the same as BZ 1381628 then we don't need a new bug, or it *is* diferrent and if so how please
Comment 2 Randy Perryman 2016-10-21 12:01:16 UTC 

*** This bug has been marked as a duplicate of bug 1387344 ***