On 08/18/2016 09:29 AM, Marios Andreou wrote: > On 17/08/16 15:46, Jiří Stránský wrote: >> On 16.8.2016 21:08, Brad P. Crochet wrote: >>> Hello TripleO-ians, >>> >>> I've started to look again at the introduced, but unused/undocumented >>> upgrade commands. It seems to me that given the current state of the >>> upgrade process (at least from Liberty -> Mitaka), these commands make >>> a lot less sense. >>> >>> I see one of two directions to take on this. Of course I would love to >>> hear other options. >>> >>> 1) Revert these commands immediately, and forget they ever existed. >>> They don't exactly work, and as I said, were never officially >>> documented, so I don't think a revert is out of the question. >>> >>> or >>> >>> 2) Do a major overhaul, and rethink the interface entirely. For >>> instance, the L->M upgrade introduced a couple of new steps (the AODH >>> migration and the Keystone migration). These would have either had to >>> have completely new commands added, or have some type of override to >>> the existing upgrade command to handle them. >>> >>> Personally, I would go for step 1. The 'overcloud deploy' command can >>> accomplish all of the upgrade steps that involve Heat. In order for >>> the new upgrade commands to work properly, there's a lot that needs to >>> be refactored out of the deploy command itself so that it can be >>> shared with deploy and upgrade, like passing of passwords and the >>> like. I just don't see a need for discrete commands when we have an >>> existing command that will do it for us. And with the addition of an >>> answer file, it makes it even easier. >>> >>> Thoughts? >>> >> +1 for approach no. 1. Currently `overcloud deploy` meets the upgrade >> needs and it gave us some flexibility to e.g. do migrations like AODH >> and Keystone WSGI. I don't think we should have a special command for >> upgrades at this point. >> >> The situation may change as we go towards upgrades of composable >> services, and perhaps wrap upgrades in Mistral if/when applicable, but >> then the potential upgrade command(s) would probably be different from >> the current ones anyway, so +1 for removing them. > +1 from me too, especially because this ^^^ (the workflow we currently > have and use will change quite drastically I expect) > > thanks, sorry I didn't spot this earlier, > marios
+1 for me too, even if, I think for an end-user experience it's not ideal and the CLI would be a better way for this point. >> Jirka >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
