On 18/10/16 03:36, Dean Troyer wrote: > On Sun, Oct 16, 2016 at 9:11 PM, Adrian Turjak > <adri...@catalyst.net.nz <mailto:adri...@catalyst.net.nz>> wrote: > > The problem I'm running into is for some of our custom plugins we > require the commands to run in all regions. We do this by getting the > region list from keystone, and then doing the command in each region. > > ... > > Is there a way to explicitly reinitialise the client_manager? > 'client_mananger.reinitialise()' or something as easy? Maybe even a > clear cache command? > > > There is not a way to re-init the ClientManager, and really, you don't > want to do that, but you do want a new compute client for each > region. OSC sets up the ClientManager client attributes with > descriptors in common/clientmanager.py get_plugin_modules(). At this > point we do not have any region information, so to do that you would > have to do it later, but it is simple enough to return whatever you > want from your plugin's make_client(). Normally that will be a client > object for the desired API, for your plugin it could be a dict of > client objects keyed off region_name. Then your consuming code would > need to deref those with: > > for region in regions: > nova_client = self.app.client_manager.compute[region] > do_something(nova_client) > > > > While explicitly initialising clients isn't exactly difficult, it is > something that would make more sense to simply work in the base > openstackclient code as multi-region commands can and will be > useful for > a lot of people. > > > Generalizing this to all of the existing plugins would be an enormous > change, but doable. We would need to think hard about how many of > these things we need to handle, not just region, but cell or whatever > else may be out there that a command would want to iterate on. I don't think it is worth doing such a change exactly because it would be a huge amount of work. Thats why I was hoping to have the value returned be partly keyed off 'client_manager.region_name'. The clients do get built off that value already, and I've tested altering that value before the first client is built and even if my authed region was RegionOne, if I manually set it to RegionTwo, the client will be built for region two. The problem is that once cached, the client will always be RegionTwo.
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. > Note that we currently can not reliably hook existing commands to > extend them, for example to support a 'server create' that uses --ram, > --vcpu and --disk in place of --flavor. That will be discussed next > week in BCN. 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.
__________________________________________________________________________ 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
