Open Stack

On Aug 8, 2014, at 14:09 , Russell Bryant <rbryant at redhat.com> wrote:

> On 08/06/2014 01:41 PM, Jay Pipes wrote:
>> On 08/06/2014 01:40 AM, Tom Fifield wrote:
>>> On 06/08/14 13:30, Robert Collins wrote:
>>>> On 6 August 2014 17:27, Tom Fifield <tom at openstack.org> wrote:
>>>>> On 06/08/14 13:24, Robert Collins wrote:
>>>> 
>>>>>> What happened to your DB migrations then? :)
>>>>> 
>>>>> 
>>>>> Sorry if I misunderstood, I thought we were talking about running VM
>>>>> downtime here?
>>>> 
>>>> While DB migrations are running things like the nova metadata service
>>>> can/will misbehave - and user code within instances will be affected.
>>>> Thats arguably VM downtime.
>>>> 
>>>> OTOH you could define it more narrowly as 'VMs are not powered off' or
>>>> 'VMs are not stalled for more than 2s without a time slice' etc etc -
>>>> my sense is that most users are going to be particularly concerned
>>>> about things for which they have to *do something* - e.g. VMs being
>>>> powered off or rebooted - but having no network for a short period
>>>> while vifs are replugged and the overlay network re-establishes itself
>>>> would be much less concerning.
>>> 
>>> I think you've got it there, Rob - nicely put :)
>>> 
>>> In many cases the users I've spoken to who are looking for a live path
>>> out of nova-network on to neutron are actually completely OK with some
>>> "API service" downtime (metadata service is an API service by their
>>> definition). A little 'glitch' in the network is also OK for many of
>>> them.
>>> 
>>> Contrast that with the original proposal in this thread ("snapshot VMs
>>> in old nova-network deployment, store in Swift or something, then launch
>>> VM from a snapshot in new Neutron deployment") - it is completely
>>> unacceptable and is not considered a migration path for these users.
>> 
>> Who are these users? Can we speak with them? Would they be interested in
>> participating in the documentation and migration feature process?
> 
> Yes, I'd really like to see some participation in the development of a
> solution if it's an important requirement.  Until then, it feels like a
> case of an open question of "what do you want".  Of course the answer is
> "a pony”.

Sorry for coming late to the conversation but its been a fairly busy week and I’m just now getting caught up.

The short answer is that if Metacloud were to migrate from nova-network to Neutron we would absolutely require as non-disruptive a process as possible. While we espouse the ideals of cloud and cattle to our clients, we can’t control how they use their clouds and we have to deal with the fact that legacy applications (aka pets) exist and run successfully today on-top of our clouds. 

Our overall approach is guided by the following 2 principals.

Minimize the network disruption to individual VMs. Ideally this is measured in seconds, but during a major version upgrade (something like a conversion from nova-network to Neutron) 5 minutes could be tolerated. 
Never disrupt the running VM. If we can avoid having to restart the container in any way, we do. This is by far the most disrupt action for our clients, especially for “pets” so we avoid it.

As previously mentioned in the thread, actual orchestration (aka API) outage doesn’t matter. If we have to take a 2 hour orchestration outage, while not ideal, its with-in the realm of possibility. As an example, our in-place major version upgrades are 1 hour or less of orchestration outage, 5 minutes or less of network outage, and 0 VM downtime. ts also important to note that these are not arbitrary requirements we’ve made up. This is what we see the vast of majority of clients expect and in some cases require from us. I would think that most cloud deployment running production work loads would require a similar set of restrictions.

I’m really sorry I couldn’t be in Oregon last week to engage in these conversations. I’m happy to discuss via this list, or IRC, or in regular IRC meetings our thoughts around this, requirements, potential assistance we could provide etc.

--
Chet Burgess
Chief Architect | Metacloud, Inc.
Email: cfb at metacloud.com | Tel: 855-638-2256, Ext. 2428
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140808/35caefea/attachment.html>