Open Stack

On Aug 5, 2014, at 4:52 PM, Joshua Harlow <harlowja at yahoo-inc.com> wrote:

> I'm pretty sure yahoo is another case, with a large set of clusters on nova-network still ;)
> 
> I believe we have been active in these discussions, although I'm unsure what was discussed at the meetup (being that I had planned vacation, right now actually). 
> 
> Anyways I think yahoo is fine with being a use case, but I can check when I get back.
> 

tl;dr: we’re willing to be a use case, but our internal timeline is such that in all likelihood
this will be as a post-mortem.

We (Yahoo) have thousands of pets that need migrated as well as an unspecified
number of cattle. A “live" strategy is strongly preferred (I’m not saying “live" migration
since in our case it needs to be an in-place operation, not shuffling instances around).
But several seconds of network outage? No problem. Disabling VM creation/deletion,
or even the entire Nova API for a few hours? Well take the grumbling from our internal
teams. A suspend/snapshot/cold-migrate would be an absolute last resort, and frankly
could push back our aggressive migration timeline significantly.

We’re interested in Oleg Bondarev’s solution, and I’ve even made some suggestions
in review comments as to how it can be made more “live," but it’s clear there are a
number of objections the greater Nova community has for it. Chief among these are the
addition of code and an API to Nova for what is essentially a one-shot operation, inability
to deal with more complicated configurations, and reliance on features only available in a
fresh release of libvirt. (As it turns out, only the latter affects us, but we’re a bit of an outlier
in the community.) It’s still under consideration for us, even if the community rejects the
approach.

As an alternative, we’re looking at DB-to-DB translation, with a one-shot script run on
the compute nodes to move network taps. We’d actually worked this out back in the
Quantum/Folsom era but backed off due to OVS/device driver issues (don’t ask -- I still
get nightmares). This, of course, would require an API outage, and is a "big bang"
approach (one of the attractions of Oleg’s approach is that we can migrate a few low-
value instances and then examine results carefully before proceeding). But once again,
our solution is likely to be of limited interest -- flat network without DHCP, no routers or
floating IPs, unconventional (for OpenStack) use of VLANs -- though we’d be happy
to share once the dust settles.

                        -Ed Hall
                        edhall at yahoo-inc.com

> 
> On Aug 5, 2014, at 7:11 PM, "Joe Gordon" <joe.gordon0 at gmail.com> wrote:
> 
>> 
>> On Aug 5, 2014 12:57 PM, "Jay Pipes" <jaypipes at gmail.com> wrote:
>> >
>> > On 08/05/2014 03:23 PM, Collins, Sean wrote:
>> >>
>> >> On Tue, Aug 05, 2014 at 12:50:45PM EDT, Monty Taylor wrote:
>> >>>
>> >>> However, I think the cost to providing that path far outweighs
>> >>> the benefit in the face of other things on our plate.
>> >>
>> >>
>> >> Perhaps those large operators that are hoping for a
>> >> Nova-Network->Neutron zero-downtime live migration, could dedicate
>> >> resources to this requirement? It is my direct experience that features
>> >> that are important to a large organization will require resources
>> >> from that very organization to be completed.
>> >
>> >
>> > Indeed, that's partly why I called out Metacloud in the original post, as they were brought up as a deployer with this potential need. Please, if there are any other shops that:
>> Perhaps I am not remembering all the details discussed at the nova mid-cycle, but Metacloud was brought up as an example company uses nova network and not neutron, not as a company that needs live migration. And that getting them to move to neutron would be a good litmus test for nova-network performance parity, something that is very hard to do in the gate.   But that was all said without any folks from Metacloud in the room, so we may both be wrong.
>> 
>> >
>> > * Currently deploy nova-network
>> > * Need to move to Neutron
>> > * Their tenants cannot tolerate any downtime due to a cold migration
>> >
>> > Please do comment on this thread and speak up.
>> >
>> > Best,
>> > -jay
>> >
>> >
>> > _______________________________________________
>> > OpenStack-dev mailing list
>> > OpenStack-dev at lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140806/20cc21c6/attachment.html>