[openstack-dev] Configuration Options, APIs, Class Paths, Oh my!

Eric Windisch eric at cloudscaling.com
Wed Oct 31 15:20:22 UTC 2012


> 
> I would argue that you *are* forking the code, even if not doing so
> without modifying the code.
> 
> I also don't see what's so hard about carrying patches. Packagers have
> mastered this. If you have custom code, I presume you have custom
> packages, too.
> 
> 
> 


I should note that with your suggestion, were someone to deploy a new backend today to code that lives in common, such as RPC, they'd need to patch it into each project, rather than simply distributing a single module and simply passing the *_backend option.  Currently, in reality, you CAN just distribute a single module, pass that option, and it will work for all of the projects.

I think this will hit ServiceGroup API pretty hard since I feel stable Grizzly will depend greatly on 3rd-party backends. Currently, the only scoped backends for Grizzly are MySQL and Zookeeper. The MySQL backend isn't an improvement over what is in Folsom, and many people will want an alternative to Zookeeper.

This is something that might usefully live in a third-party repo. Someone will be able to download the code, install it, and pass in an option to all of their OpenStack services.  It might not be stable across backports/fixes, but it will be possible.

Regards,
Eric Windisch

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121031/dd2d7f93/attachment.html>


More information about the OpenStack-dev mailing list