Open Stack

On Mon, Oct 17, 2016 at 5:29 PM, Adrian Turjak <adriant at catalyst.net.nz> wrote:
> What I'm wondering is can the current client cache be changed to be keyed
> off the client_manager.region_name? That way the change is only in how the
> clients are built and the code elsewhere doesn't change unless it actually
> does something by manually changing region_name. This would then be a change
> that would go unnoticed outside of the clientmanger and simply add a new
> feature.
>
> Actually, I got distracted while writing this email and wrote a patch:
> https://review.openstack.org/#/c/387696
>
> Using the test command in my first email, this works. It should simply work
> with all existing cases, but the test suite should confirm that first of
> course.
>
> With that change anyone can easily work exactly as before (region_name will
> be set to your default region), and new features that are multi-region can
> be introduced without any pain provided they know to update
> client_manager.region_name.

This is where I have a problem with this approach.  Those are
descriptors, and make_client() is only called at first reference.  Any
given command can not assume it will be the first one to initialize
the client, or not.  Changing region_name like that is not going to
reset the descriptor, that would now become a manual call.

For the minimialist case of a CLI re-loading for each command issued
(the common case it seems) this is less of an issue.  But for any
longer-running invocation, such as interactive mode or a non-cli
consumer of osc-lib, this quickly gets to be sub-optimal.  Keeping a
client dict keyed off region name allows you to keep all of those
clients (instantiated only as needed/used) around as long as you need
them and not require re-creating them.

There is also an interaction with the requests session cache that I do
not think will be a problem, but have not yet thought through all the
way here that we should consider.

> I have been following this a little and it does sound interesting. Am
> curious what solution is found for this. Can plugins overwrite existing
> commands? That way if someone wanted a server create with their own features
> they just make a plugin that replaces the standard command. While a bit of a
> blunt solution, it does seem like the simplest, although people need to be
> aware when installing plugins that they can replace/overwrite default
> commands and be careful to install only trusted plugins.

Currently there is _no_ checking done WRT the command namespaces, any
plugin can happily stomp on any other command.  The results are
officially undefined, mostly because the load order via setuptools is
not deterministic or assured.  My server create plugin works, but we
can not assure that will always be the case, which is why this is not
released yet.

The next plugin interface revision will have a notion of registering
its commands so we can be more deliberate with the call orders and
also collision checking.  There also needs to be some way to sanity
check that not just any old thing that you might not be aware of is
hooking your commands.

dt

-- 

Dean Troyer
dtroyer at gmail.com