fuel-dev team mailing list archive

[Mike Scherbakov <mscherbakov@xxxxxxxxxxxx>]

Oh yes, rollback is the right word!


On Tue, Apr 15, 2014 at 1:01 AM, David Easter <deaster@xxxxxxxxxxxx> wrote:

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


-- 
Mike Scherbakov
#mihgen