On Thu, Aug 18, 2016 at 4:25 AM, mathieu bultel <[email protected]> wrote: > 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 >>>
I have proposed the following reverts: python-tripleoclient: https://review.openstack.org/#/c/357192/ https://review.openstack.org/#/c/357194/ https://review.openstack.org/#/c/357195/ tripleo-common: https://review.openstack.org/#/c/357219/ https://review.openstack.org/#/c/357220/ https://review.openstack.org/#/c/357221/ -- Brad __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
