Open Stack

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