<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 18/10/16 14:09, Dean Troyer wrote:<br>
</div>
<blockquote
cite="mid:CAOJFoEu16YJEmKZ-FP99NT3xq1aY1OiH9HNM9shApYESQpTZBA@mail.gmail.com"
type="cite">
<pre wrap="">On Mon, Oct 17, 2016 at 5:29 PM, Adrian Turjak <a class="moz-txt-link-rfc2396E" href="mailto:adriant@catalyst.net.nz"><adriant@catalyst.net.nz></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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:
<a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/387696">https://review.openstack.org/#/c/387696</a>
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.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
I'm not sure why being the first one to initialize the client or not
is a problem in anything other than interactive move. The only worry
would be in interactive mode where if one command altered
client_manger.region_name it does so globally and the next command
will reuse the set region. In all the common cases region_name will
first be set/reset from OS_REGION_NAME or clouds.yaml.<br>
<br>
Other things that may confuse people:<br>
client_manager.region_name = "RegionOne"<br>
nova = client_manager.compute # reference to nova in RegionOne<br>
# do stuff ...<br>
client_manager.region_name = "RegionTwo"<br>
# still a reference to nova in RegionOne<br>
nova = client_manager.compute # only now is a reference to nova in
RegionTwo<br>
<br>
<br>
With this suggestion all I'm doing is moving your suggestion
('nova_client = self.app.client_manager.
<div><wbr style="font-size:12.8px">compute[region]') down to the
cache layer and having the cache still act like a singleton but
actually be a mapping of regions to clients. It fixes my problem
and needs no major refactoring elsewhere which is a plus. Although
option would be to leave the cache in osc-lib untouched as a pure
singleton and just make a new one for openstackclient that does
support regions.<br>
<br>
For anyone using multi-region commands and the interactive mode,
we would need a different solution, but in part that could wait
until there are officially supported multi-region commands/plugins
.<br>
<br>
Ultimately I'm not fussed what the solution is, but I do think
that not having support for changing regions in the client manager
or per region clients is a waste. Plugins like ours, or future
multi-region features, will have to explicitly create the per
region clients themselves, and while not hard it does make having
a central client manager less useful or means they are duplicating
the make_client functions for existing clients like nova.<br>
<br>
That said, I think the work being done with the OpenStackClient is
fantastic. It has been a massive effort and now especially with
plugins it is wonderful to work with. So don't take this as a
complaint, I genuinely do want to help make it better!<br>
</div>
</body>
</html>