Open Stack

> Coincidentally, I have a WIP oslo-config branch for this:
> 
>  https://github.com/markmc/oslo-config/commits/deprecated-group
> 
> It's getting pretty tight for Grizzly, but I hope to push this up for
> review today.

That's perfect! Please let me know if you can make it for Grizzly, I'd be glad to test it. I'll wait to send my patch for review in the meantime, as with yours any compatibility issue would be solved.

> Usually, we avoid breaking existing configurations. But, in the case of
> hyper-v, I'd be fine with you guys saying "we did't have many users in
> Folsom, so backwards compat isn't a big concern".

Folsom was the first release for us (I'm not counting the pre Essex driver) with the initial Nova support. For Grizzly we're quite overwhelmed by customers response, especially after we added Quantum and another gazillion features to Nova, Cinder, our Windows Cloud-Init etc. So it's a good moment for doing some small cleanup by moving those few options to the proper place. :-) 

Thanks!

Alessandro



On Feb 15, 2013, at 13:07 , Mark McLoughlin <markmc at redhat.com> wrote:

> On Fri, 2013-02-15 at 12:22 +0200, Alessandro Pilotti wrote:
>> Hi guys,
>> 
>> As discussed with russelb and during the OpenStack Hyper-V meetings, it'd be a great to move compute driver specific onfigurations from nova.conf's [DEFAULT] group to a driver specific group (e.g. [LIBVIRT], [HYPERV], etc).
>> 
>> We already added new options in Grizzly to the [HYPERV] group and for consistency, before closing Grizzly, we'd like to move the existing Hyper-V ones added in Folsom there as well.
>> 
>> This approach could be IMO applied to all the drivers (in the Havana timeframe at this point, I guess).
>> The obvious issue is that breaking backwards compatibility is not an option.
>> 
>> openstack.common.cfg.Opt() offers a "deprecated_name" argument, but AFAIK this applies only for options belonging to the same group:
>> https://github.com/openstack/nova/blob/master/nova/openstack/common/cfg.py#L518
>> 
>> What about adding a "deprecated_group" as well or a "<group>.<option>" syntax for "deprecated_name"? This way we could handle the transition smoothly.
> 
> Coincidentally, I have a WIP oslo-config branch for this:
> 
>  https://github.com/markmc/oslo-config/commits/deprecated-group
> 
> It's getting pretty tight for Grizzly, but I hope to push this up for
> review today.
> 
>> Getting back to the specific Hyper-V case, if deprecated options are not possible at this stage, we'd prefer to rename them anyway now. The Hyper-V support is far more complete in this release then it was in Folsom. Moving or deprecating the options in Havana will create way more confusion than doing it now.
>> 
>> Here are the Hyper-V config options that need to be moved to the [HYPERV] group:
>> https://github.com/openstack/nova/blob/master/nova/virt/hyperv/vmops.py#L43
>> https://github.com/openstack/nova/blob/master/nova/virt/hyperv/volumeops.py#L35
>> 
>> Any additional ideas?
> 
> Usually, we avoid breaking existing configurations. But, in the case of
> hyper-v, I'd be fine with you guys saying "we did't have many users in
> Folsom, so backwards compat isn't a big concern".
> 
> Cheers,
> Mark.
> 
> 
> _______________________________________________
> 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/20130216/5d4b3817/attachment.html>