Open Stack

On Wed, Feb 06, 2013 at 11:18:41AM -0500, Mark McLoughlin wrote:
> On Wed, 2013-02-06 at 16:10 +0000, Daniel P. Berrange wrote:
> > On Wed, Feb 06, 2013 at 10:46:52AM -0500, Mark McLoughlin wrote:
> > > On Wed, 2013-02-06 at 15:22 +0000, Daniel P. Berrange wrote:
> > > > The only way we can do this is if we do *NOT* require the use of
> > > > classnames in config parameters. Instead we should treat all these
> > > > config parameters as being more like enumerations, and map those to
> > > > classnames internally
> > > > 
> > > > eg for the compute_driver instead of having the user set
> > > > 
> > > >   compute_driver=nova.virt.libvirt.LibvirtDriver
> > > > 
> > > > they would do
> > > > 
> > > >   compute_driver=libvirt 
> > > 
> > > I think there's already good consensus on this and the idea is to use
> > > entry points and stevedore to achieve it.
> > > 
> > > See:
> > > 
> > >   https://blueprints.launchpad.net/nova/+spec/entrypoints-plugins
> > >   https://review.openstack.org/11027
> > >   https://review.openstack.org/15030
> > 
> > Heh, I've even seen that blueprint before, but it was hard to understand
> > just what it was on about. A etherpad transcript of a conversation that
> > you weren't present for, doesn't make a nice design doc for blueprint :-(
> > 
> > > The end result is exactly that
> > > 
> > >   compute_driver=libvirt
> > > 
> > > will work, along with backwards compat for the original name.
> > > 
> > > It just needs to be resurrected and finished off.
> > 
> > Indeed, it looks like that is definitely something to have as a
> > priority item. Even if those patches were resurrected it looks
> > like quite alot more work is needed, give that they only tackle
> > 3 out of 44+ config parameters!
> > 
> > Do we have any official position on config file upgrade support
> > at this time ?  It would be helpful to reviewers if they could
> > clearly identify whether a proposed config change is acceptable
> > or not from an upgrade POV, since currently people are holding
> > different changes to different standards before approval
> 
> "Official position", heh.
> 
> I'd say that we should not be changing configuration options in
> incompatible ways without a deprecation period (of a release cycle)
> unless we're talking about a really obscure config option that is highly
> unlikely to have been used by real users.
> 
> Got examples of where we didn't follow that general rule?

I was mostly thinking of the change from 'connection_type' to
'compute_driver', though that was in Folsom dev, rather than
Grizzly. Looking at a diff of nova.conf-sample from folsom
vs grizzly, the only significant change I see 

-floating_ip_dns_manager=nova.network.dns_driver.DNSDriver
+floating_ip_dns_manager=nova.network.noop_dns_driver.NoopDNSDriver

-instance_dns_manager=nova.network.dns_driver.DNSDriver
+instance_dns_manager=nova.network.noop_dns_driver.NoopDNSDriver


The old class still exists, but instead of it being a no-op, it will
now raise exceptions. If you want the same no-op behaviour as before
you need to change the config. Guess this could be something you'd
consider one of the obscure edge cases though :-)


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 :|