On Aug 27, 2013, at 18:52 , Russell Bryant <rbry...@redhat.com<mailto:rbry...@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@lists.openstack.org<mailto: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
