I think the ability to migrate instances and projects between clouds is very valid and applies to other use cases besides avoiding an upgrade.
The instance migration process that Tim describes is one that we use, too. It's relatively easy for end-users and requires no admin intervention. Project migration is a very interesting concept. I'd imagine it would include things like users, key pair entries, security groups, networks, etc. I agree with Joshua about why it's bad to avoid upgrades. I've seen a ton of effort go into making in-place upgrades possible and safe and it's very much appreciated. I upgraded an environment from Folsom to Grizzly a few weeks ago and none of the users noticed it happened. I definitely don't recommend blindly doing "apt-get dist-upgrade" on a production environment, though :) On the flip side, sometimes it can be easier to just migrate rather than upgrade in-place. I think where the line is drawn with that decision varies from person to person. On Thu, Oct 24, 2013 at 2:56 PM, Joshua Harlow <[email protected]>wrote: > I agree its not simple (from experience), > > There is a difference though between 'simpler for now' and the 'right > thing to do', > > If software doesn't support the right thing to do ('upgrade', > 'dist-upgrade' - or yum equivalent) then the community needs to make that > work (and stop with new features). > > Otherwise the community is in a whole world of trouble. If openstack is > to make the life of operations & other people better and the only way to > operate it is to build new regions, then something feels backwards in this > equation. > > IMHO bypassing the problem is not a long-term solution (and is not > healthy for openstack to even recommend this). > > I don't even think its a short-term solution honestly since building a > new region costs $$ and downtime. Who wants to do that every 6 months, I > can surely tell u I don't :) > > From: Martinx - ジェ�`ムズ <[email protected]> > Date: Thursday, October 24, 2013 1:17 PM > To: Joshua Harlow <[email protected]> > Cc: Tim Bell <[email protected]>, Alexander Stellwag < > [email protected]>, "[email protected]" < > [email protected]> > Subject: Re: [Openstack] Migrate instances/tenants between clouds > > I do not even want to try to upgrade my system... > > I know that DPKG is awesome and handle system upgrades carefully but, > sounds more simpler to just build a new Region... > > > This doesn't sound trivial (like `apt-get update ; apt-get > dist-upgrade`): > > > http://www.openstack.org/summit/portland-2013/session-videos/presentation/getting-from-grizzly-to-havana-a-devops-upgrade-pattern > > Don't you think!? > > > > On 24 October 2013 17:48, Joshua Harlow <[email protected]> wrote: > >> Whatever happened to doing in-place upgrades? >> >> Has that been problematic for u, are people just not doing it? If they are >> avoiding it, why? >> >> Shouldn't just going from folsom->havana work, if not, why not; it worries >> me that this isn't priority #0 if it doesn't work. >> >> On 10/24/13 10:51 AM, "Tim Bell" <[email protected]> wrote: >> >> > >> >Have you tried >> > >> >- snapshot >> >- glance download of the snapshot >> >- glance upload of the snapshot to new instance >> >- boot from snapshot >> > >> >The process we use at CERN is documented at >> > >> http://information-technology.web.cern.ch/book/cern-cloud-infrastructure-u >> >ser-guide/images/migrating-using-images >> > >> >This could be a good technique to document in the standard CERN openstack >> >user guide. >> > >> >BTW, this does increase the storage in your glance server since you'll >> >loose any commonality between multiple images. So, make sure you've lots >> >of space on Glance. >> > >> >Tim >> > >> >> -----Original Message----- >> >> From: Alexander Stellwag [mailto:[email protected]] >> >> Sent: 24 October 2013 16:53 >> >> To: [email protected] >> >> Subject: [Openstack] Migrate instances/tenants between clouds >> >> >> >> Hi stackers, >> >> >> >> we're looking for a tool / script / blueprint to migrate instances or >> >>even complete tenants between multiple installations of OpenStack >> >> (possibly running different versions). >> >> >> >> I searched around the net but didn't find anything appropriate. Is any >> >>of you aware of such a tool? >> >> >> >> The current use-case is a migration from a folsom/nova-network based >> >>installation into our new havana/neutron based cloud. It is not >> >> necessary to migrate instances and volumes online but it should work at >> >>least semi-automatically to make it usable in large deployments. >> >> >> >> Any hints would be greatly appreciated. >> >> >> >> Cheers, >> >> Alex >> >> -- >> >> Alexander Stellwag >> >> Deutsche Telekom AG Products & Innovation Infrastructure Design >> > >> > >> >_______________________________________________ >> >Mailing list: >> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >> >Post to : [email protected] >> >Unsubscribe : >> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >> >> >> _______________________________________________ >> Mailing list: >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >> Post to : [email protected] >> Unsubscribe : >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >> > > > _______________________________________________ > Mailing list: > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : [email protected] > Unsubscribe : > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > -- Joe Topjian Systems Architect Cybera Inc. www.cybera.ca Cybera is a not-for-profit organization that works to spur and support innovation, for the economic benefit of Alberta, through the use of cyberinfrastructure.
_______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : [email protected] Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
