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 > > Jirka > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev