Open Stack

Reviewing this thread to come to a conclusion.... (for myself at least - and hopefully so I can document something so reviewers know why I did it)

For approach:
1. plugins should use stevedore with entry points (as stated by Russell)
2. the plugins should be explicitly selected through configuration 

For api stability:
I'm not sure there was a consensus. Personally I would write a base class for the plugins and document in it that the interface is unstable. Sound good?

BTW: this is one of those things that could be put in a place to make and record decisions (like the gerrit idea for blueprints). But now I am referring to another thread.... [http://lists.openstack.org/pipermail/openstack-dev/2014-March/029232.html ]

Paul.


-----Original Message-----
From: Sandy Walsh [mailto:sandy.walsh at rackspace.com] 
Sent: 04 March 2014 21:25
To: Murray, Paul (HP Cloud Services)
Cc: OpenStack Development Mailing List (not for usage questions); dms at danplanet.com
Subject: Re: [openstack-dev] [Nova] What is the currently accepted way to do plugins

And sorry, as to your original problem, the loadables approach is kinda messy since only the classes that are loaded when *that* module are loaded are used (vs. explicitly specifying them in a config). You may get different results when the flow changes.

Either entry-points or config would give reliable results.


On 03/04/2014 03:21 PM, Murray, Paul (HP Cloud Services) wrote:
> In a chat with Dan Smith on IRC, he was suggesting that the important thing was not to use class paths in the config file. I can see that internal implementation should not be exposed in the config files - that way the implementation can change without impacting the nova users/operators.

There's plenty of easy ways to deal with that problem vs. entry points.

MyModule.get_my_plugin() ... which can point to anywhere in the module permanently.

Also, we don't have any of the headaches of merging setup.cfg sections (as we see with oslo.* integration).

> Sandy, I'm not sure I really get the security argument. Python provides every means possible to inject code, not sure plugins are so different. Certainly agree on choosing which plugins you want to use though.

The concern is that any compromised part of the python eco-system can get auto-loaded with the entry-point mechanism. Let's say Nova auto-loads all modules with entry-points the [foo] section. All I have to do is create a setup that has a [foo] section and my code is loaded.
Explicit is better than implicit.

So, assuming we don't auto-load modules ... what does the entry-point approach buy us?


> From: Russell Bryant [rbryant at redhat.com] We should be careful though.  
> We need to limit what we expose as external plug points, even if we consider them unstable.  If we don't want it to be public, it may not make sense for it to be a plugin interface at all.

I'm not sure what the concern with introducing new extension points is?
OpenStack is basically just a big bag of plugins. If it's optional, it's supposed to be a plugin (according to the design tenets).



> 
> --
> Russell Bryant
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>