Open Stack

On 5/17/12 4:38 PM, Doug Hellmann wrote:
>
> <snip>
>
> In the wikistatus plugin I notice that you modify the global FLAGS 
> when wikistatus.py is imported. Is that the right time to do that, or 
> should it happen during the on-load handler in the plugin class? Or 
> maybe even in the plugin manager, which could ask the plugin for the 
> new options and then modify FLAGS itself. It seems like lots of Nova 
> code modifies FLAGS during import, but having an explicit trigger for 
> that (rather than depending on import order) seems safer to me.
I don't feel strongly about this -- I'm just following the example set 
by existing Nova code.  Can you think of a corner case where loading it 
at import time would cause problems?  Alternatively, can you think of a 
corner case where we would want a flag to be defined during the magic 
moment /between/ import time and the load callback?

I can't think of a case for either, although I have the vague feeling 
that the latter is slightly more possible (if still improbable.)

>
> If the entry point for each plugin is given a unique name (instead of 
> being called "plugin", as the sharedfs plugin is) we would be able to 
> log "loading plugin X" as well as provide options to control which 
> plugins are activated. I don't know if that latter idea is a goal or not.
If leaving in that option is free, then I'm all for it.  I'm still a bit 
new to entry points... is the entry-point name a totally arbitrary string?

Also, is supporting unique names the same thing as /requiring/ unique 
names?  Would this ultimately result in us needing a governed, 
hierarchical namespace?

>
>     - Two different loading pathways -- is that useful or just confusing?
>
>
>
> "One and only one obvious way to do it."

OK, I'm convinced.  Outside of the common client, are entrypoints 
already a hard dependency elsewhere in OpenStack such that we don't lose 
anything by requiring them?

>     - Should the plugin base class interpose itself between the plugin
>     and python-openstackclient in order to enforce interface
>     versioning?  Is that even possible?
>
>
> We could probably figure out a way to do that, but I don't know why 
> you would want to. What did you have in mind? Which interface are you 
> worried about versioning, the CLI itself?

I'm not sure I do want to, but here's my concern:  Right now the common 
client's API for extending the commandline is entirely internal to the 
common client itself.  When I write the sharedfs plugin to make use of 
that same API, I'm treating that internal API as external... and I don't 
like being the only person in the world doing that.

Of course, if the expectation is that that common client API will soon 
become public/documented/frozen anyway, then there's no problem.

-Andrew

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120518/8e5bec63/attachment.html>