Oh yes, rollback is the right word!
On Tue, Apr 15, 2014 at 1:01 AM, David Easter <[email protected]> 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" <[email protected]> wrote: > > >On 04/13/2014 10:53 PM, Mike Scherbakov wrote: > >> > >> On Fri, Apr 11, 2014 at 2:11 PM, Aleksey Kasatkin > >> <[email protected] <mailto:[email protected]>> 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 : [email protected] > >> <mailto:[email protected]> > >> 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 : [email protected] > >Unsubscribe : https://launchpad.net/~fuel-dev > >More help : https://help.launchpad.net/ListHelp > > > -- Mike Scherbakov #mihgen
-- Mailing list: https://launchpad.net/~fuel-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp
