Open Stack

On 18/10/16 14:09, Dean Troyer 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'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.

Other things that may confuse people:
client_manager.region_name = "RegionOne"
nova = client_manager.compute # reference to nova in RegionOne
# do stuff ...
client_manager.region_name = "RegionTwo"
# still a reference to nova in RegionOne
nova = client_manager.compute # only now is a reference to nova in RegionTwo


With this suggestion all I'm doing is moving your suggestion
('nova_client = self.app.client_manager.
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.

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 .

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.

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!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161018/9cba19c3/attachment.html>