Open Stack

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 <harlowja at yahoo-inc.com>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 - ¥¸¥§©`¥à¥º <thiagocmartinsc at gmail.com>
> Date: Thursday, October 24, 2013 1:17 PM
> To: Joshua Harlow <harlowja at yahoo-inc.com>
> Cc: Tim Bell <Tim.Bell at cern.ch>, Alexander Stellwag <
> openstack at stellwag.net>, "openstack at lists.openstack.org" <
> openstack at lists.openstack.org>
> 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 <harlowja at yahoo-inc.com> 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" <Tim.Bell at cern.ch> 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:openstack at stellwag.net]
>> >> Sent: 24 October 2013 16:53
>> >> To: openstack at lists.openstack.org
>> >> 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     : openstack at lists.openstack.org
>> >Unsubscribe :
>> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>
>>
>> _______________________________________________
>> Mailing list:
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> Post to     : openstack at lists.openstack.org
>> Unsubscribe :
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>
>
>
> _______________________________________________
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20131024/b92c35a0/attachment.html>