Open Stack

On Aug 27, 2013, at 18:52 , Russell Bryant <rbryant at redhat.com<mailto:rbryant at redhat.com>> wrote:

On 08/27/2013 10:53 AM, Alessandro Pilotti wrote:
That's IMO a different story: backporting a driver is usually quite
trivial as it affects only one service (nova-compute) and one
interaction point with Nova (the driver's interface). Between Havana and
Grizzly for example, the entire Hyper-V driver can be backported without
substantial issues. On the deployment side, we have to care only about
updating the code which runs con the compute nodes, using vanilla
OpenStack components on the controller and remaining nodes.

Backporting the public APIs is a whole different story, it affects way
more components that need to be deployed (nova-api as a minimum of
course), with way more interaction points that might incur into patching
hell.

Do you really know that?  This is pretty hand wavy.  I think you're
making this backport out to be _way_ more complicated than it is.  I
don't see why it's any more complicated than a virt driver feature backport.

What about publishing the API as blacklisted by default? This way it
would be available only to users that enable it explicitly, while still
supporting the scenario described above.

It still makes no sense to me to merge an API for a feature that can't
be used.


I just committed a fully working implementation of the live-snapshot blueprint in the Hyper-V driver.
The tests haven't been published yet (I need to clean them up a bit before).

Here's the patch: https://review.openstack.org/#/c/44595/

My plan was to write it and publish it at the beginning of the next cycle, but I was wondering if with this we could save the live-snapshot APIs in Havana, so I hurried up a bit. :-)
I know that it's awfully late to bring it up for Havana, if it's not possible to accept it, no problem at all of course, I'm going to bring it back at the beginning of the Icehouse cycle.

The results in terms of boot times are quite impressive. This feature, especially combined with the Hyper-V RemoteFX feature in Havana (host GPU access in the instances) can bring VDI snenarios to another level, just to name one of the use cases.
We are already at work on the cloudbase-init side to support the initialization on the client side. The compute node takes of course care of changing Mac addresses and attaching a new config drive (when needed).

Alessandro


--
Russell Bryant

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto: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/20130831/a6075080/attachment.html>