Open Stack

On 18 October 2016 at 12:09, Dean Troyer <dtroyer at gmail.com> wrote:

> 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
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

A comment from the cheap seats, almost all clients are using a
keystoneauth1 session at this point and that's where your authentication
information is being cached. There is essentially no cost to creating a
client with an existing session as auth happens on demand.

The region_name is not part of the authentication request, it's used to
lookup the endpoint and so is passed to Client creation.

Given this maybe there is no longer any value in a ClientCache? It was
mostly useful to prevent clients doing dumb and share auth amongst them. So
long as the session/auth is created and saved once, a client can be created
per use/request with this information (including region) with no real
performance impact.


Jamie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161018/9cf4fd7a/attachment.html>