<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 18 October 2016 at 12:09, Dean Troyer <span dir="ltr"><<a href="mailto:dtroyer@gmail.com" target="_blank">dtroyer@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Oct 17, 2016 at 5:29 PM, Adrian Turjak <<a href="mailto:adriant@catalyst.net.nz">adriant@catalyst.net.nz</a>> wrote:<br>
> What I'm wondering is can the current client cache be changed to be keyed<br>
> off the client_manager.region_name? That way the change is only in how the<br>
> clients are built and the code elsewhere doesn't change unless it actually<br>
> does something by manually changing region_name. This would then be a change<br>
> that would go unnoticed outside of the clientmanger and simply add a new<br>
> feature.<br>
><br>
> Actually, I got distracted while writing this email and wrote a patch:<br>
> <a href="https://review.openstack.org/#/c/387696" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/387696</a><br>
><br>
> Using the test command in my first email, this works. It should simply work<br>
> with all existing cases, but the test suite should confirm that first of<br>
> course.<br>
><br>
> With that change anyone can easily work exactly as before (region_name will<br>
> be set to your default region), and new features that are multi-region can<br>
> be introduced without any pain provided they know to update<br>
> client_manager.region_name.<br>
<br>
</span>This is where I have a problem with this approach.  Those are<br>
descriptors, and make_client() is only called at first reference.  Any<br>
given command can not assume it will be the first one to initialize<br>
the client, or not.  Changing region_name like that is not going to<br>
reset the descriptor, that would now become a manual call.<br>
<br>
For the minimialist case of a CLI re-loading for each command issued<br>
(the common case it seems) this is less of an issue.  But for any<br>
longer-running invocation, such as interactive mode or a non-cli<br>
consumer of osc-lib, this quickly gets to be sub-optimal.  Keeping a<br>
client dict keyed off region name allows you to keep all of those<br>
clients (instantiated only as needed/used) around as long as you need<br>
them and not require re-creating them.<br>
<br>
There is also an interaction with the requests session cache that I do<br>
not think will be a problem, but have not yet thought through all the<br>
way here that we should consider.<br>
<span class=""><br>
> I have been following this a little and it does sound interesting. Am<br>
> curious what solution is found for this. Can plugins overwrite existing<br>
> commands? That way if someone wanted a server create with their own features<br>
> they just make a plugin that replaces the standard command. While a bit of a<br>
> blunt solution, it does seem like the simplest, although people need to be<br>
> aware when installing plugins that they can replace/overwrite default<br>
> commands and be careful to install only trusted plugins.<br>
<br>
</span>Currently there is _no_ checking done WRT the command namespaces, any<br>
plugin can happily stomp on any other command.  The results are<br>
officially undefined, mostly because the load order via setuptools is<br>
not deterministic or assured.  My server create plugin works, but we<br>
can not assure that will always be the case, which is why this is not<br>
released yet.<br>
<br>
The next plugin interface revision will have a notion of registering<br>
its commands so we can be more deliberate with the call orders and<br>
also collision checking.  There also needs to be some way to sanity<br>
check that not just any old thing that you might not be aware of is<br>
hooking your commands.<br>
<span class="im HOEnZb"><br>
dt<br>
<br>
--<br>
<br>
Dean Troyer<br>
<a href="mailto:dtroyer@gmail.com">dtroyer@gmail.com</a><br>
<br>
</span><div class="HOEnZb"><div class="h5">______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div><div class="gmail_extra">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.<br><br></div><div class="gmail_extra">The region_name is not part of the authentication request, it's used to lookup the endpoint and so is passed to Client creation. <br><br></div><div class="gmail_extra">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.<br><br><br></div><div class="gmail_extra">Jamie<br></div><div class="gmail_extra"><br></div></div>