[openstack-dev] [Nova] What is the currently accepted way to do plugins

Sandy Walsh sandy.walsh at RACKSPACE.COM
Tue Mar 4 17:49:33 UTC 2014


This brings up something that's been gnawing at me for a while now ... why use entry-point based loaders at all? I don't see the problem they're trying to solve. (I thought I got it for a while, but I was clearly fooling myself)

1. If you use the "load all drivers in this category" feature, that's a security risk since any compromised python library could hold a trojan.

2. otherwise you have to explicitly name the plugins you want (or don't want) anyway, so why have the extra indirection of the entry-point? Why not just name the desired modules directly? 

3. the real value of a loader would be to also extend/manage the python path ... that's where the deployment pain is. "Use <fully qualified filename> driver and take care of the pathing for me." Abstracting the module/class/function name isn't a great win. 

I don't see where the value is for the added pain (entry-point management/package metadata) it brings. 

CMV,

-S
________________________________________
From: Russell Bryant [rbryant at redhat.com]
Sent: Tuesday, March 04, 2014 1:29 PM
To: Murray, Paul (HP Cloud Services); OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Nova] What is the currently accepted way to do plugins

On 03/04/2014 06:27 AM, Murray, Paul (HP Cloud Services) wrote:
> One of my patches has a query asking if I am using the agreed way to
> load plugins: https://review.openstack.org/#/c/71557/
>
> I followed the same approach as filters/weights/metrics using
> nova.loadables. Was there an agreement to do it a different way? And if
> so, what is the agreed way of doing it? A pointer to an example or even
> documentation/wiki page would be appreciated.

The short version is entry-point based plugins using stevedore.

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.

--
Russell Bryant

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



More information about the OpenStack-dev mailing list