Open Stack

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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev