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.wa...@rackspace.com] Sent: 04 March 2014 21:25 To: Murray, Paul (HP Cloud Services) Cc: OpenStack Development Mailing List (not for usage questions); d...@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 [rbry...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
