On Aug 5, 2014, at 4:52 PM, Joshua Harlow <harlo...@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
edh...@yahoo-inc.com
>
> On Aug 5, 2014, at 7:11 PM, "Joe Gordon" <joe.gord...@gmail.com> wrote:
>
>>
>> On Aug 5, 2014 12:57 PM, "Jay Pipes" <jaypi...@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@lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
