sahara services during mitaka to newton upgrade

Bug #1630247 reported by Marios Andreou on 2016-10-04
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
tripleo
High
Marios Andreou

Bug Description

In Mitaka tripleo-heat-templates sahara services are deployed by default [1] whereas in Newton they have to be explicitly enabled [2]

This bug is for tracking the patches we need to deal with this problem. On controller upgrade we need to determine whether or not to startup sahara-* services after the package update.

On converge we need to decide whether to override Newton and actually deploy sahara or leave it off as the Newton templates specify

[1] https://github.com/openstack/tripleo-heat-templates/blob/stable/mitaka/puppet/manifests/overcloud_controller_pacemaker.pp#L1413
[2] https://github.com/openstack/tripleo-heat-templates/blob/stable/newton/overcloud-resource-registry-puppet.j2.yaml#L138

Marios Andreou (marios-b) wrote :
Download full text (9.5 KiB)

FWIW some discussion around this and the approach we take from irc:

15:59 < marios> jistr: tosky i think we need a launchpad bug for discussing what we will do here
16:00 < tosky> oh
16:00 < marios> jistr: tosky basically we can 'detect' if sahara is running during controller_pacemaker_1.sh because all the things are still running then. but by pacemaker_3.sh we've moved to next gen HA so we can't tell then if sahara was running earlier
16:01 < marios> jistr: tosky so another thought was writing to file/signal between those two steps but that is ugly :/
16:01 < tosky> I would kind of expect that you can read the old status before starting to upgrade it, and then you can't properly know the old status because it was upgraded :)
16:02 < marios> tosky: jistr: we'd ideally use 'enabled_services' from the newton templates, but default is for sahara to be off now so it wouldn't tell us if it was previously running (no enabled_services for mitaka)
16:02 < jistr> marios, tosky: but reading the old status might not help, right? It's not so much whether sahar was running or not, as we know it *was* running in Mitaka. It's more about whether the user wants to keep it or not...
16:02 < jistr> i.e. the gap between the Mitaka and Newton defaults
16:03 < marios> jistr: tosky so tosky was trying to answer the 'can we just detect' which is was what was asked of us to do
16:03 < tosky> right, we know that it was on
16:03 < tosky> marios: but as jistr pointed out, we know that from the beginning
16:03 < tosky> if you stripped out sahara, you did some magic custom post-config manipulation
16:04 < marios> tosky: jistr yeah was thinking some more... like right, so it would be not trivial to just remove it then ^^
16:04 < marios> tosky: jistr so that assumption means we don't need to try and detect and donig the env file/flag like the current review is ok
16:05 < marios> tosky: jistr unless they manually steopped sahara for some reason but then they'd know to explicitly disable it from the docs i guess
16:05 < jistr> marios, tosky: yea i think so. What we're asking is inherently undetectable AFAICT, it's a user decision.
16:06 < jistr> yea it might be detectable in cases when the users did something special with their deployment, as tosky wrote earlier, but that probably can't be considered the general case
16:06 < tosky> and if they did it once, they know they should explicitely remove it with the new switch
16:06 < tosky> yep: if they know about it and they don't want anymore, they can force its removal now; if they don't care, default -> keep
16:07 < jistr> +1 on default = keep
16:08 < jistr> +2'd the patch
16:08 < marios> jistr: advantage of doing this https://review.openstack.org/#/c/375517/2/environments/major-upgrade-pacemaker.yaml is we should be able to reuse for converge (though may not help at that point, i mean we need to use the existing 'deploy sahara' environment file
16:09 < marios> jistr: by 'this' i mean having a KeepSaharaServices in paramater_defaults frmo the controller step... will be persisted
16:10 < jistr> marios: yea we'll need some amount of docs around this whole issue simply b/c the Mitaka vs. Newton defaults differ, so one either ...

Read more...

Marios Andreou (marios-b) wrote :
Changed in tripleo:
importance: Undecided → High
milestone: none → newton-rc3
Marios Andreou (marios-b) wrote :

another sahara-api related mitaka.. newton issue at https://review.openstack.org/#/c/358022/ fyi (with its own earlier bug, just adding for context)

Reviewed: https://review.openstack.org/375517
Committed: https://git.openstack.org/cgit/openstack/tripleo-heat-templates/commit/?id=2e6cc07c1a74c2dd7be70568f49834bace499937
Submitter: Jenkins
Branch: master

commit 2e6cc07c1a74c2dd7be70568f49834bace499937
Author: marios <email address hidden>
Date: Fri Sep 23 17:19:07 2016 +0300

    Adds Environment File for Removing Sahara during M/N upgrade

    The default path if the operator does nothing is to keep the
    sahara services on mitaka to newton upgrades.

    If the operator wishes to remove sahara services then they
    need to specify the provided major-upgrade-remove-sahara.yaml
    environment file in the stack upgrade commands.

    The existing migration to ha arch already removes the constraints
    and pcs resource for sahara api/engine so we just need to stop
    it from starting again if we want to remove it.

    This adds a KeepSaharaServiceOnUpgrade parameter to determine if
    Sahara is disabled from starting up after the controllers are
    upgraded (defaults true).

    Finally it is worth noting that we default the sahara services
    as 'on' during converge here in the resource_registry of the
    converge environment file; any subsequent stack updates where
    the deployment contains sahara services will need to
    include the -e /environments/services/sahara.yaml environment
    file.

    Related-Bug: 1630247
    Change-Id: I59536cae3260e3df52589289b4f63e9ea0129407

Reviewed: https://review.openstack.org/382748
Committed: https://git.openstack.org/cgit/openstack/tripleo-heat-templates/commit/?id=6d17088192d859c22880380ad3fa3a668eec9292
Submitter: Jenkins
Branch: stable/newton

commit 6d17088192d859c22880380ad3fa3a668eec9292
Author: marios <email address hidden>
Date: Fri Sep 23 17:19:07 2016 +0300

    Adds Environment File for Removing Sahara during M/N upgrade

    The default path if the operator does nothing is to keep the
    sahara services on mitaka to newton upgrades.

    If the operator wishes to remove sahara services then they
    need to specify the provided major-upgrade-remove-sahara.yaml
    environment file in the stack upgrade commands.

    The existing migration to ha arch already removes the constraints
    and pcs resource for sahara api/engine so we just need to stop
    it from starting again if we want to remove it.

    This adds a KeepSaharaServiceOnUpgrade parameter to determine if
    Sahara is disabled from starting up after the controllers are
    upgraded (defaults true).

    Finally it is worth noting that we default the sahara services
    as 'on' during converge here in the resource_registry of the
    converge environment file; any subsequent stack updates where
    the deployment contains sahara services will need to
    include the -e /environments/services/sahara.yaml environment
    file.

    Related-Bug: 1630247
    Change-Id: I59536cae3260e3df52589289b4f63e9ea0129407
    (cherry picked from commit 2e6cc07c1a74c2dd7be70568f49834bace499937)

tags: added: in-stable-newton
Changed in tripleo:
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers