Open Stack

On Thu, Aug 18, 2016 at 4:25 AM, mathieu bultel <mbultel at redhat.com> 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