Open Stack

Yeah, the entry_points seems a good way to go.

-Lianhao

Doug Hellmann wrote on 2013-02-07:
> 
> 
> On Wed, Feb 6, 2013 at 3:32 PM, Caitlin Bestler <caitlin.bestler at nexenta.com> wrote:
> 
> 
> 	On 2/6/2013 10:26 AM, Anne Gentle wrote:
> 
> 
> 
> 
> 
> 		On Wed, Feb 6, 2013 at 9:22 AM, Daniel P. Berrange <berrange at redhat.com> wrote:
> 
> 
> 			Nova (and most other OpenStack components) have an ever increasing
> 			number of configuration parameters which accept classnames.
> 			Obviously, we're doing this to make it possible to plug in custom
> 			implementations of various interfaces, which is great.
> 
> 			There are two downsides to this
> 
> 			 - The user has to know about obscure, often undocumented, python
> 			   module names.
> 
> 
> 
> 
> 		Thanks for shining a light on this particular difficulty. While we now have a sample nova.conf with descriptions, any use of and
> changes to class names in both nova and quantum have caused headaches for users. And doc bugs too.
> 
> 
> 
> 			 - Any time we rename a class, or refactor code possibly deleting
> 			   or merging classes, we break the end config file upon upgrade.
> 
> 			The first point is a mere usability matter, but the second point
> 			is a serious deployment issue IMHO, which can only get worse as
> 			usage of OpenStack increases & people expect more stability and
> 			consistency across upgrades.
> 
> 			Historically code changes have been pretty fast & loose config
> 			parameters, arbitrarily changing them at any time for any reason.
> 			AFAIK there are no formal rules defined about changing config
> 			paramaters, but in some of the recent changes I've submitted
> 			which involved config changes, reviewers wanted backwards compat
> 			to be maintained. The result that when renaming, or obsoleting
> 			existing classses we're having to keep around stubs for the old
> 			classes to avoid breaking user config files. This is not a good
> 			approach for long term maintainability of the codebase.
> 
> 			IMHO the core issue here is that by using classnames in config
> 			parameters we are exposing what we (developers) generally consider
> 			to be internal/private implementation details to the end user. End
> 			user expectations wrt upgrades are thus restricting what we can do
> 			with our internal implementations.
> 
> 			I don't think it is acceptable to have a situation where configuration
> 			file parameters restrict what we can do in terms of re-arranging /
> 			refactoring our codebase. Provided we maintain the same featureset
> 			compatibility, we should be free todo any code refactoring we desire.
> 
> 			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
> 
> 
> 
> 		I would completely support this and wish I had dev resources to put
> behind the effort. Is there a group who wants to work on this?
> 
> 
> 		44 isn't bad out of over 600 I might add.
> 
> 
> 		Let me help any way I can.
> 
> 		Anne
> 
> 
> 
> 
> 
> 	One approach to solving this might be to just differentiate between configuration intended for python coders
> 	from configuration intended for end users.
> 
> 	Because OpenStack is frequently used a toolkit, rather than as a finished product, there will be resistance to
> 	removing the ability to explicitly name classes. If you're redirecting the plumbing this is useful stuff.
> 
> 
> 
> Entry points takes care of all of this. The code can live anywhere, and each entry point gets a nice, short, unique name to use in the
> configuration file. Developers can point to anything they want, and non-developers don't have to know class names. We all win.
> 
> Doug
> 
> 
> 
> 	But I think a typical end user is about as likely to reconfigure this plumbing as they are to try to change the
> 	plumbing in their own home.
> 
> 	So why not define a type of configuration that *must* make sense in end user terminology, i.e for non-plumbers.
> 	That configuration would then be used to generate the plumbing level configuration. If it done correctly, the same
> 	user-domain configuration items will still make sense even when there is a major upgrade to the internals.
> 
> 	We would track whether a given plumbing-level configuration had been hand-customized, and if not, regenerate
> 	it from the user-level configuration with each new release.
> 
> 	I fear that just trying to redirect all configuration to be "user friendly" will meet with to much resistance from those
> 	who actually need to do some custom plumbing. I think we need a solution that addresses both plumbers and non-plumbers.
> 
> 
> 
> 	_______________________________________________ 	OpenStack-dev mailing
> list 	OpenStack-dev at lists.openstack.org
> 	http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
>