Open Stack

On Wed, 12 Mar 2014 14:31:13 +0000
"Murray, Paul (HP Cloud Services)" <pmurray at hp.com> wrote:

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

Even if you don't want to make any guarantees around API stability I'd
suggest still putting some versioning info in at the start. So at least
the various parts can detect and warn when they might be broken.

Chris

> 
> 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
> > 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev