← Back to team overview

fuel-dev team mailing list archive

Re: Patching OpenStack UI considerations

 

> It is patching, not upgrade.

+1 - Upgrade to a new major version is in the next release.  Hopefully,
we¹ll take advantage of new capabilities in IceHouse to do this:

http://gigaom.com/2014/04/13/prepping-for-openstack-icehouse/


> As far as I know from D.Ilyin, we will be able to downgrade only to the
>version which was before the migration.

+1 - Don¹t think of it as downgrade - think of it more as rollback in case
the update fails.  It¹s just there to rollback to the version of files
present prior to starting the update.

Thanks,

- David J. Easter
  Director of Product Management, Mirantis



On 4/14/14, 7:42 AM, "Bogdan Dobrelya" <bdobrelia@xxxxxxxxxxxx> wrote:

>On 04/13/2014 10:53 PM, Mike Scherbakov wrote:
>> 
>> On Fri, Apr 11, 2014 at 2:11 PM, Aleksey Kasatkin
>> <akasatkin@xxxxxxxxxxxx <mailto:akasatkin@xxxxxxxxxxxx>> wrote:
>> 
>> 
>>     Folks,
>> 
>>     There are several options to implement patching of OpenStack in
>>UI/API:
>> 
>>     1. Rollback to previously deployed version can be initiated
>>     automatically or using UI/API (with separate button "Rollback").
>>     AFAIC, manual rollback will be suitable in situation where we need
>>     to find reasons of failure or cluster remains in operational state
>>     (failure is not fatal).
>> 
>> Ok 
>> 
>>     2. Upgrade/Downgrade options:
>> 
>> It is patching, not upgrade. Upgrade is when we upgrade to new OpenStack
>> release, or another major milestone, which requires DB migrations.
>> 
>>         a. One button "Upgrade" and drop-down list with all versions
>>     which can be upgraded/downgraded to.
>> 
>> Patch, with the list of versions we can migrate to. As far as I know
>> from D.Ilyin, we will be able to downgrade only to the version which was
>> before the migration. BTW, how are we gonna track whether we can
>> downgrade or not? If we already downgraded, for example, you won't be
>> able to downgrade more.
>
>IMHO, there could be the only one way to track such states for
>environments - use special attributes in Nailgun DB. Of cause,
>update/rollback (upgrade/downgrade - later) scripts have to update these
>states appropriately.
>
>> 
>>         b. Two buttons: "Upgrade", "Downgrade" with separate lists of
>>     versions.
>> 
>>     Please share your thoughts and proposals here.
>> 
>>     Thanks,
>>     Aleksey Kasatkin
>> 
>> 
>> 
>>     --
>>     Mailing list: https://launchpad.net/~fuel-dev
>>     Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
>>     <mailto:fuel-dev@xxxxxxxxxxxxxxxxxxx>
>>     Unsubscribe : https://launchpad.net/~fuel-dev
>>     More help   : https://help.launchpad.net/ListHelp
>> 
>> 
>> 
>> 
>> -- 
>> Mike Scherbakov
>> #mihgen
>> 
>> 
>
>
>-- 
>Best regards,
>Bogdan Dobrelya,
>Skype #bogdando_at_yahoo.com
>Irc #bogdando
>
>-- 
>Mailing list: https://launchpad.net/~fuel-dev
>Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
>Unsubscribe : https://launchpad.net/~fuel-dev
>More help   : https://help.launchpad.net/ListHelp




Follow ups

References