Open Stack

It's all fun and games... until someone has to do the work. :)

The entry_point drum beat has been around for while, at least the last 2 
design summits. But when you look at Nova, there are at least 3 
different ways we load things today, so this ends up being in the 
"Tedious Task" realm to get us there.

Monty's tried a couple of times, but the first came late in Folsom, so 
the change was way to destabilizing. The second was early in Grizzly, 
had a huge impact on the unit test run time, which never got addressed, 
and I think got Abandoned.

I'd say right now we're too late in Grizzly for this. But a real plan 
for Havana is probably a good one.

  * Converting our existing oslo importer to entry points
  * Converting the LazyPluggable loaded stuff to entry points
  * Making nova extensions actually entry points

With it will come some substantial deprecation again, but that's 
probably fine. Something like this should drop by havana-1 or havana-2, 
by the time we get into havana-3 it's just too late for such changes.

	-Sean

On 02/06/2013 09:21 PM, Lu, Lianhao wrote:
> 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
>>
>>
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


-- 
Sean Dague
IBM Linux Technology Center
email: sdague at linux.vnet.ibm.com
alt-email: sldague at us.ibm.com