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
