sahara services during mitaka to newton upgrade
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
tripleo |
Fix Released
|
High
|
Marios Andreou |
Bug Description
In Mitaka tripleo-
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:/
[2] https:/
Changed in tripleo: | |
status: | Triaged → Fix Released |
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 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 /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:00 < tosky> oh
16:00 < marios> jistr: tosky basically we can 'detect' if sahara is running during controller_
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:/
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 ...