Open Stack

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
>>
>> __________________________________________________________________________
>> 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
>
> __________________________________________________________________________
> 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