On Tue, May 2, 2017 at 7:32 PM, Adrian Turjak <adri...@catalyst.net.nz> wrote: > Shade in this context is both really easy, and harder since I can't just > give it the same session so it can reuse the same token. I've tried > seeing if I can pilfer the OpenStackCloudConfig from OSC but passing > that to shade seemed to break. If you run that interpreter command you > can explore the OSC objects too. "self.app.cloud_config" or > "self.app.cloud" appears to be close to what we want, but I can't get it > to play nice with shade as it appears to be a OSC extension of the > os-client-config class.
With last week's release of os-client-config 1.27.0 and osc-lib 1.5.1 and the addition of these to global-requirements minimums for today's OSC 3.10.0 release we are in a place to move most of the special-case code back in to osc-lib and os-client-config. Much of this is due to backward-compatibility issues that OSC needed to handle. > If the interpreter is started from envvars you can do "cloud = > openstack_cloud()" and shade does the right thing. If it was started > with --os-cloud then you can also do "cloud = > openstack_cloud(cloud=self.app.cloud.config.get('cloud'))". The latter > also works with envvars as "self.app.cloud.config.get('cloud')" returns > an empty string so shade looks at envvars. I can easily make a function > that just returns shade with a new token, just kind of sucks that there > is no way to pass it a valid session/token for it to reuse. Would be > fantastic if you can take a gander at that as I don't know that much > about Shade. I'd prefer to have this thing use a single shared session > or token as much as possible. Both OSC and Shade use ksa Sessions, that bit should be directly sharable and includes the token handling. OSC's auth stuff changed a bit in the 3.10.0 release in the first step of simplifying it and actually being able to use os-client-config as intended. There are a bunch of timing issues regarding _when_ auth plugins get loaded that differ between Shade and OSC's usage. once we complete resolving that the level of reuse should be able to go up substantially. dt -- Dean Troyer dtro...@gmail.com __________________________________________________________________________ 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