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