Open Stack

Glad to see that the Bp is hypervisor independent.

We'll provide the Hyper-V implementation, based on this TODO comment:

https://review.openstack.org/#/c/99916/3/nova/virt/hyperv/driver.py

Thanks,

Alessandro


> On 25.07.2014, at 03:08, "Michael Still" <mikal at stillhq.com> wrote:
> 
> Yep, I think this one has well and truly crossed the line. Exception granted.
> 
> Michael
> 
> On Fri, Jul 25, 2014 at 2:30 AM, Andrew Laski
> <andrew.laski at rackspace.com> wrote:
>> 
>> ________________________________________
>> From: Day, Phil [philip.day at hp.com]
>> Sent: Thursday, July 24, 2014 9:20 AM
>> To: OpenStack Development Mailing List (not for usage questions); Daniel P. Berrange
>> Subject: Re: [openstack-dev] [Nova][Spec freeze exception] Controlled shutdown of GuestOS
>> 
>> According to: https://etherpad.openstack.org/p/nova-juno-spec-priorities   alaski has also singed up for this if I drop the point of contention - which I'ev done
>> 
>> 
>> Yes, I will sponsor this one as well.  This is more a bug fix than a feature IMO and would be really nice to get into Juno.
>> 
>> 
>> 
>>> -----Original Message-----
>>> From: Michael Still [mailto:mikal at stillhq.com]
>>> Sent: 24 July 2014 00:50
>>> To: Daniel P. Berrange; OpenStack Development Mailing List (not for usage
>>> questions)
>>> Subject: Re: [openstack-dev] [Nova][Spec freeze exception] Controlled
>>> shutdown of GuestOS
>>> 
>>> Another core sponsor would be nice on this one. Any takers?
>>> 
>>> Michael
>>> 
>>> On Thu, Jul 24, 2014 at 4:14 AM, Daniel P. Berrange <berrange at redhat.com>
>>> wrote:
>>>> On Wed, Jul 23, 2014 at 06:08:52PM +0000, Day, Phil wrote:
>>>>> Hi Folks,
>>>>> 
>>>>> I'd like to propose the following as an exception to the spec freeze, on the
>>> basis that it addresses a potential data corruption issues in the Guest.
>>>>> 
>>>>> https://review.openstack.org/#/c/89650
>>>>> 
>>>>> We were pretty close to getting acceptance on this before, apart from a
>>> debate over whether one additional config value could be allowed to be set
>>> via image metadata - so I've given in for now on wanting that feature from a
>>> deployer perspective, and said that we'll hard code it as requested.
>>>>> 
>>>>> Initial parts of the implementation are here:
>>>>> https://review.openstack.org/#/c/68942/
>>>>> https://review.openstack.org/#/c/99916/
>>>> 
>>>> Per my comments already, I think this is important for Juno and will
>>>> sponsor it.
>>>> 
>>>> Regards,
>>>> Daniel
>>>> --
>>>> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/
>>> :|
>>>> |: http://libvirt.org              -o-             http://virt-manager.org :|
>>>> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
>>>> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|
>>>> 
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> 
>>> 
>>> 
>>> --
>>> Rackspace Australia
>>> 
>>> _______________________________________________
>>> 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
> 
> 
> 
> -- 
> Rackspace Australia
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev