On 18/10/16 14:09, Dean Troyer wrote: > On Mon, Oct 17, 2016 at 5:29 PM, Adrian Turjak <adri...@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!
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev