Re: [openstack-dev] [nova][cinder][ceilometer][glance][all] Loading clients from a CONF object
On Fri, Jun 13, 2014 at 3:27 AM, Jamie Lennox wrote: > > > And as we're going to have to live with this for a while, I'd rather use > > the more clear version of this in keystone instead of the Heat stanzas. > > Anyone else have an opinion on this? > I like keeping sections' names simple and clear, but it looks like you should add some common section ([services_common]?) since 6 out of 6 options in your example will very probable be repeated for every client. -- Kind regards, Yuriy. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][cinder][ceilometer][glance][all] Loading clients from a CONF object
On Wed, 2014-06-11 at 19:52 -0400, Sean Dague wrote: > On 06/11/2014 07:47 PM, Jamie Lennox wrote: > > On Thu, 2014-06-12 at 09:13 +1200, Steve Baker wrote: > >> On 12/06/14 08:18, Mark McLoughlin wrote: > >>> On Wed, 2014-06-11 at 16:57 +1200, Steve Baker wrote: > On 11/06/14 15:07, Jamie Lennox wrote: > > Among the problems cause by the inconsistencies in the clients is that > > all the options that are required to create a client need to go into the > > config file of the service. This is a pain to configure from the server > > side and can result in missing options as servers fail to keep up. > > > > With the session object standardizing many of these options there is the > > intention to make the session be loadable directly from a CONF object. A > > spec has been proposed to this for nova-specs[1] to outline the problem > > and the approach in more detail. > > > > The TL;DR version is that I intend to collapse all the options to load a > > client down such that each client will have one ini section that looks > > vaguely like: > > > > [cinder] > > cafile = '/path/to/cas' > > certfile = 'path/to/cert' > > timeout = 5 > > auth_name = v2password > > username = 'user' > > password = 'pass' > > > > This list of options is then managed from keystoneclient, thus servers > > will automatically have access to new transport options, authentication > > mechanisms and security fixes as they become available. > > > > The point of this email is to make people aware of this effort and that > > if accepted into nova-specs the same pattern will eventually make it to > > your service (as clients get updated and manpower allows). > > > > The review containing the config option names is still open[2] so if you > > wish to comment on particulars, please take a look. > > > > Please leave a comment on the reviews or reply to this email with > > concerns or questions. > > > > Thanks > > > > Jamie > > > > [1] https://review.openstack.org/#/c/98955/ > > [2] https://review.openstack.org/#/c/95015/ > Heat already needs to have configuration options for every client, and > we've gone with the following pattern: > http://git.openstack.org/cgit/openstack/heat/tree/etc/heat/heat.conf.sample#n612 > > Do you have any objection to aligning with what we already have?, > specifically: > [clients_] > ca_file=... > cert_file=... > key_file=... > > > > No, i can use those options - i went with the former because that's what > > is used by auth_token middleware and i assumed everyone would be > > familiar with them. I don't think it matters what is used so long as > > it's consistent. > > > > Regarding the [clients_] that header name would be passed as > > a parameter so services can still do what they like there. > > Honestly, I really like > > [nova] > > better than > > [clients_nova] This won't be controlled by keystoneclient - i'll let the services fight that out amongst themselves, but the rest of this thread suggests just [nova] > And as we're going to have to live with this for a while, I'd rather use > the more clear version of this in keystone instead of the Heat stanzas. Anyone else have an opinion on this? There's always the possibility that i can maintain a deprecated ca_file for cafile etc in keystoneclient, however this will mean that every service will get this deprecation so i've been trying to avoid that. There is a mechanism there to allow the individual services to create the correct deprecations so it's just a matter of figuring out what we want the 'correct' name to be. > -Sean > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][cinder][ceilometer][glance][all] Loading clients from a CONF object
On 2014-06-12, 7:18 AM, Sean Dague wrote: On 06/11/2014 08:12 PM, Mathieu Gagné wrote: On 2014-06-11, 7:52 PM, Sean Dague wrote: I'm concerned about the [nova] section being (one day) overloaded with options unrelated to the actual nova client configuration. Although my concern could be wrong. I feel like you need to put your opperator hat on when it comes to conf files. Nova is the compute service. Talking to nova is doing nova things. Nova_client has no real meaning, and it actually gets kind of confusing what's a client in an openstack cloud. Because neutron is a nova client, nova is a neutron / glance client / cinder client, glance is a swift client. So that subtlety makes sense to people that spend time reading code. But from an Ops perspective, seems to just add a layer of confusion. The config file should be a view that makes sense from configuring a system by someone that's not reading the code. Not just a reflection of the code structure dejour that parses it. Which is why I think [nova] makes sense. I agree with you, [nova] looks more suitable. -- Mathieu ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][cinder][ceilometer][glance][all] Loading clients from a CONF object
On 06/11/2014 08:12 PM, Mathieu Gagné wrote: > On 2014-06-11, 7:52 PM, Sean Dague wrote: >> >> Honestly, I really like >> >> [nova] >> >> better than >> >> [clients_nova] >> >> And as we're going to have to live with this for a while, I'd rather use >> the more clear version of this in keystone instead of the Heat stanzas. >> > > What about [novaclient] or [nova_client] ? > > I'm concerned about the [nova] section being (one day) overloaded with > options unrelated to the actual nova client configuration. Although my > concern could be wrong. I feel like you need to put your opperator hat on when it comes to conf files. Nova is the compute service. Talking to nova is doing nova things. Nova_client has no real meaning, and it actually gets kind of confusing what's a client in an openstack cloud. Because neutron is a nova client, nova is a neutron / glance client / cinder client, glance is a swift client. So that subtlety makes sense to people that spend time reading code. But from an Ops perspective, seems to just add a layer of confusion. The config file should be a view that makes sense from configuring a system by someone that's not reading the code. Not just a reflection of the code structure dejour that parses it. Which is why I think [nova] makes sense. -Sean -- Sean Dague http://dague.net signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][cinder][ceilometer][glance][all] Loading clients from a CONF object
On 2014-06-11, 7:52 PM, Sean Dague wrote: Honestly, I really like [nova] better than [clients_nova] And as we're going to have to live with this for a while, I'd rather use the more clear version of this in keystone instead of the Heat stanzas. What about [novaclient] or [nova_client] ? I'm concerned about the [nova] section being (one day) overloaded with options unrelated to the actual nova client configuration. Although my concern could be wrong. -- Mathieu ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][cinder][ceilometer][glance][all] Loading clients from a CONF object
On Wed, 2014-06-11 at 04:43 +, Angus Salkeld wrote: > On 11/06/14 13:10, Jamie Lennox wrote: > > Among the problems cause by the inconsistencies in the clients is that > > all the options that are required to create a client need to go into the > > config file of the service. This is a pain to configure from the server > > side and can result in missing options as servers fail to keep up. > > > > With the session object standardizing many of these options there is the > > intention to make the session be loadable directly from a CONF object. A > > spec has been proposed to this for nova-specs[1] to outline the problem > > and the approach in more detail. > > > > The TL;DR version is that I intend to collapse all the options to load a > > client down such that each client will have one ini section that looks > > vaguely like: > > > > [cinder] > > cafile = '/path/to/cas' > > certfile = 'path/to/cert' > > timeout = 5 > > auth_name = v2password > > username = 'user' > > password = 'pass' > > > > This list of options is then managed from keystoneclient, thus servers > > will automatically have access to new transport options, authentication > > mechanisms and security fixes as they become available. > > > > The point of this email is to make people aware of this effort and that > > if accepted into nova-specs the same pattern will eventually make it to > > your service (as clients get updated and manpower allows). > > > > The review containing the config option names is still open[2] so if you > > wish to comment on particulars, please take a look. > > > > Please leave a comment on the reviews or reply to this email with > > concerns or questions. > > Nice, we have this bug too in Solum: > https://bugs.launchpad.net/solum/+bug/1292334 > > It is partly about the duplication in code needed to get a client. > The other part of the bug is the config options (which you are dealing with). > > The other thing to think about is other services want a connection based on > user token (plus the cafile stuff above) like in solum/heat. > > It would be nice to be able to create a connection based on a context and a > config. > > You might also want to look at Steve Baker's monster patch series: > https://review.openstack.org/#/q/status:open+project:openstack/heat+branch:master+topic:bp/client-plugins,n,z > > This stuff should really be in the clients. > > -Angus Indeed, so this is part of the reason for the separation of session and auth plugin. Session will often want to be client dependent (though there's no reason not to share) and simply loaded from conf, but auth may need to be from conf or user based. My current thought is that i pass down an auth plugin out of auth_token middleware so that starting a client with user credentials would look something like: sess = session.Session.from_config_options(CONF, 'cinder') sess.auth = env['keystone.user_auth_plugin'] cinder = cinderclient.v1.client.Client(sess) That auth plugin would be fairly simple so you could easily construct it from the context or from the headers created by auth_token (i don't know how common the context object is between services to do it that way). > > > > Thanks > > > > Jamie > > > > [1] https://review.openstack.org/#/c/98955/ > > [2] https://review.openstack.org/#/c/95015/ > > > > > > ___ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][cinder][ceilometer][glance][all] Loading clients from a CONF object
On 06/11/2014 07:47 PM, Jamie Lennox wrote: > On Thu, 2014-06-12 at 09:13 +1200, Steve Baker wrote: >> On 12/06/14 08:18, Mark McLoughlin wrote: >>> On Wed, 2014-06-11 at 16:57 +1200, Steve Baker wrote: On 11/06/14 15:07, Jamie Lennox wrote: > Among the problems cause by the inconsistencies in the clients is that > all the options that are required to create a client need to go into the > config file of the service. This is a pain to configure from the server > side and can result in missing options as servers fail to keep up. > > With the session object standardizing many of these options there is the > intention to make the session be loadable directly from a CONF object. A > spec has been proposed to this for nova-specs[1] to outline the problem > and the approach in more detail. > > The TL;DR version is that I intend to collapse all the options to load a > client down such that each client will have one ini section that looks > vaguely like: > > [cinder] > cafile = '/path/to/cas' > certfile = 'path/to/cert' > timeout = 5 > auth_name = v2password > username = 'user' > password = 'pass' > > This list of options is then managed from keystoneclient, thus servers > will automatically have access to new transport options, authentication > mechanisms and security fixes as they become available. > > The point of this email is to make people aware of this effort and that > if accepted into nova-specs the same pattern will eventually make it to > your service (as clients get updated and manpower allows). > > The review containing the config option names is still open[2] so if you > wish to comment on particulars, please take a look. > > Please leave a comment on the reviews or reply to this email with > concerns or questions. > > Thanks > > Jamie > > [1] https://review.openstack.org/#/c/98955/ > [2] https://review.openstack.org/#/c/95015/ Heat already needs to have configuration options for every client, and we've gone with the following pattern: http://git.openstack.org/cgit/openstack/heat/tree/etc/heat/heat.conf.sample#n612 Do you have any objection to aligning with what we already have?, specifically: [clients_] ca_file=... cert_file=... key_file=... > > No, i can use those options - i went with the former because that's what > is used by auth_token middleware and i assumed everyone would be > familiar with them. I don't think it matters what is used so long as > it's consistent. > > Regarding the [clients_] that header name would be passed as > a parameter so services can still do what they like there. Honestly, I really like [nova] better than [clients_nova] And as we're going to have to live with this for a while, I'd rather use the more clear version of this in keystone instead of the Heat stanzas. -Sean -- Sean Dague http://dague.net signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][cinder][ceilometer][glance][all] Loading clients from a CONF object
On Thu, 2014-06-12 at 09:13 +1200, Steve Baker wrote: > On 12/06/14 08:18, Mark McLoughlin wrote: > > On Wed, 2014-06-11 at 16:57 +1200, Steve Baker wrote: > >> On 11/06/14 15:07, Jamie Lennox wrote: > >>> Among the problems cause by the inconsistencies in the clients is that > >>> all the options that are required to create a client need to go into the > >>> config file of the service. This is a pain to configure from the server > >>> side and can result in missing options as servers fail to keep up. > >>> > >>> With the session object standardizing many of these options there is the > >>> intention to make the session be loadable directly from a CONF object. A > >>> spec has been proposed to this for nova-specs[1] to outline the problem > >>> and the approach in more detail. > >>> > >>> The TL;DR version is that I intend to collapse all the options to load a > >>> client down such that each client will have one ini section that looks > >>> vaguely like: > >>> > >>> [cinder] > >>> cafile = '/path/to/cas' > >>> certfile = 'path/to/cert' > >>> timeout = 5 > >>> auth_name = v2password > >>> username = 'user' > >>> password = 'pass' > >>> > >>> This list of options is then managed from keystoneclient, thus servers > >>> will automatically have access to new transport options, authentication > >>> mechanisms and security fixes as they become available. > >>> > >>> The point of this email is to make people aware of this effort and that > >>> if accepted into nova-specs the same pattern will eventually make it to > >>> your service (as clients get updated and manpower allows). > >>> > >>> The review containing the config option names is still open[2] so if you > >>> wish to comment on particulars, please take a look. > >>> > >>> Please leave a comment on the reviews or reply to this email with > >>> concerns or questions. > >>> > >>> Thanks > >>> > >>> Jamie > >>> > >>> [1] https://review.openstack.org/#/c/98955/ > >>> [2] https://review.openstack.org/#/c/95015/ > >> Heat already needs to have configuration options for every client, and > >> we've gone with the following pattern: > >> http://git.openstack.org/cgit/openstack/heat/tree/etc/heat/heat.conf.sample#n612 > >> > >> Do you have any objection to aligning with what we already have?, > >> specifically: > >> [clients_] > >> ca_file=... > >> cert_file=... > >> key_file=... No, i can use those options - i went with the former because that's what is used by auth_token middleware and i assumed everyone would be familiar with them. I don't think it matters what is used so long as it's consistent. Regarding the [clients_] that header name would be passed as a parameter so services can still do what they like there. > > Sounds like there's a good case for an Oslo API for creating client > > objects from configuration. > > > Yes it does. Although depending on the use-case, the combination of > config options and arguments will be different. > > An Oslo API to solve the problem of every client requiring special > snowflake creation code[1][2] would be very useful. So i have another review[3] that is attempting to standardize other common components of the client and how they relate to session. This object would be created by the client though so i'm not yet sure how we would go about using this to do common config options. It might be as simple as creating the common client **kwargs from the config and then having the services initialize the clients with them. At least there is potential there if all clients take those some common set of variables. There are always going to be some options that are unique to a client that will have to be handled manually though. > [1] > https://review.openstack.org/#/c/97981/5/heat/engine/clients/os/cinder.py > [2] > https://review.openstack.org/#/c/97980/5/heat/engine/clients/os/neutron.py [3] https://review.openstack.org/#/c/86237/ > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][cinder][ceilometer][glance][all] Loading clients from a CONF object
On 12/06/14 08:18, Mark McLoughlin wrote: > On Wed, 2014-06-11 at 16:57 +1200, Steve Baker wrote: >> On 11/06/14 15:07, Jamie Lennox wrote: >>> Among the problems cause by the inconsistencies in the clients is that >>> all the options that are required to create a client need to go into the >>> config file of the service. This is a pain to configure from the server >>> side and can result in missing options as servers fail to keep up. >>> >>> With the session object standardizing many of these options there is the >>> intention to make the session be loadable directly from a CONF object. A >>> spec has been proposed to this for nova-specs[1] to outline the problem >>> and the approach in more detail. >>> >>> The TL;DR version is that I intend to collapse all the options to load a >>> client down such that each client will have one ini section that looks >>> vaguely like: >>> >>> [cinder] >>> cafile = '/path/to/cas' >>> certfile = 'path/to/cert' >>> timeout = 5 >>> auth_name = v2password >>> username = 'user' >>> password = 'pass' >>> >>> This list of options is then managed from keystoneclient, thus servers >>> will automatically have access to new transport options, authentication >>> mechanisms and security fixes as they become available. >>> >>> The point of this email is to make people aware of this effort and that >>> if accepted into nova-specs the same pattern will eventually make it to >>> your service (as clients get updated and manpower allows). >>> >>> The review containing the config option names is still open[2] so if you >>> wish to comment on particulars, please take a look. >>> >>> Please leave a comment on the reviews or reply to this email with >>> concerns or questions. >>> >>> Thanks >>> >>> Jamie >>> >>> [1] https://review.openstack.org/#/c/98955/ >>> [2] https://review.openstack.org/#/c/95015/ >> Heat already needs to have configuration options for every client, and >> we've gone with the following pattern: >> http://git.openstack.org/cgit/openstack/heat/tree/etc/heat/heat.conf.sample#n612 >> >> Do you have any objection to aligning with what we already have?, >> specifically: >> [clients_] >> ca_file=... >> cert_file=... >> key_file=... > Sounds like there's a good case for an Oslo API for creating client > objects from configuration. > Yes it does. Although depending on the use-case, the combination of config options and arguments will be different. An Oslo API to solve the problem of every client requiring special snowflake creation code[1][2] would be very useful. [1] https://review.openstack.org/#/c/97981/5/heat/engine/clients/os/cinder.py [2] https://review.openstack.org/#/c/97980/5/heat/engine/clients/os/neutron.py ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][cinder][ceilometer][glance][all] Loading clients from a CONF object
On Wed, 2014-06-11 at 16:57 +1200, Steve Baker wrote: > On 11/06/14 15:07, Jamie Lennox wrote: > > Among the problems cause by the inconsistencies in the clients is that > > all the options that are required to create a client need to go into the > > config file of the service. This is a pain to configure from the server > > side and can result in missing options as servers fail to keep up. > > > > With the session object standardizing many of these options there is the > > intention to make the session be loadable directly from a CONF object. A > > spec has been proposed to this for nova-specs[1] to outline the problem > > and the approach in more detail. > > > > The TL;DR version is that I intend to collapse all the options to load a > > client down such that each client will have one ini section that looks > > vaguely like: > > > > [cinder] > > cafile = '/path/to/cas' > > certfile = 'path/to/cert' > > timeout = 5 > > auth_name = v2password > > username = 'user' > > password = 'pass' > > > > This list of options is then managed from keystoneclient, thus servers > > will automatically have access to new transport options, authentication > > mechanisms and security fixes as they become available. > > > > The point of this email is to make people aware of this effort and that > > if accepted into nova-specs the same pattern will eventually make it to > > your service (as clients get updated and manpower allows). > > > > The review containing the config option names is still open[2] so if you > > wish to comment on particulars, please take a look. > > > > Please leave a comment on the reviews or reply to this email with > > concerns or questions. > > > > Thanks > > > > Jamie > > > > [1] https://review.openstack.org/#/c/98955/ > > [2] https://review.openstack.org/#/c/95015/ > Heat already needs to have configuration options for every client, and > we've gone with the following pattern: > http://git.openstack.org/cgit/openstack/heat/tree/etc/heat/heat.conf.sample#n612 > > Do you have any objection to aligning with what we already have?, > specifically: > [clients_] > ca_file=... > cert_file=... > key_file=... Sounds like there's a good case for an Oslo API for creating client objects from configuration. Mark. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][cinder][ceilometer][glance][all] Loading clients from a CONF object
On 11/06/14 15:07, Jamie Lennox wrote: > Among the problems cause by the inconsistencies in the clients is that > all the options that are required to create a client need to go into the > config file of the service. This is a pain to configure from the server > side and can result in missing options as servers fail to keep up. > > With the session object standardizing many of these options there is the > intention to make the session be loadable directly from a CONF object. A > spec has been proposed to this for nova-specs[1] to outline the problem > and the approach in more detail. > > The TL;DR version is that I intend to collapse all the options to load a > client down such that each client will have one ini section that looks > vaguely like: > > [cinder] > cafile = '/path/to/cas' > certfile = 'path/to/cert' > timeout = 5 > auth_name = v2password > username = 'user' > password = 'pass' > > This list of options is then managed from keystoneclient, thus servers > will automatically have access to new transport options, authentication > mechanisms and security fixes as they become available. > > The point of this email is to make people aware of this effort and that > if accepted into nova-specs the same pattern will eventually make it to > your service (as clients get updated and manpower allows). > > The review containing the config option names is still open[2] so if you > wish to comment on particulars, please take a look. > > Please leave a comment on the reviews or reply to this email with > concerns or questions. > > Thanks > > Jamie > > [1] https://review.openstack.org/#/c/98955/ > [2] https://review.openstack.org/#/c/95015/ Heat already needs to have configuration options for every client, and we've gone with the following pattern: http://git.openstack.org/cgit/openstack/heat/tree/etc/heat/heat.conf.sample#n612 Do you have any objection to aligning with what we already have?, specifically: [clients_] ca_file=... cert_file=... key_file=... cheers ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][cinder][ceilometer][glance][all] Loading clients from a CONF object
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/06/14 13:10, Jamie Lennox wrote: > Among the problems cause by the inconsistencies in the clients is that > all the options that are required to create a client need to go into the > config file of the service. This is a pain to configure from the server > side and can result in missing options as servers fail to keep up. > > With the session object standardizing many of these options there is the > intention to make the session be loadable directly from a CONF object. A > spec has been proposed to this for nova-specs[1] to outline the problem > and the approach in more detail. > > The TL;DR version is that I intend to collapse all the options to load a > client down such that each client will have one ini section that looks > vaguely like: > > [cinder] > cafile = '/path/to/cas' > certfile = 'path/to/cert' > timeout = 5 > auth_name = v2password > username = 'user' > password = 'pass' > > This list of options is then managed from keystoneclient, thus servers > will automatically have access to new transport options, authentication > mechanisms and security fixes as they become available. > > The point of this email is to make people aware of this effort and that > if accepted into nova-specs the same pattern will eventually make it to > your service (as clients get updated and manpower allows). > > The review containing the config option names is still open[2] so if you > wish to comment on particulars, please take a look. > > Please leave a comment on the reviews or reply to this email with > concerns or questions. Nice, we have this bug too in Solum: https://bugs.launchpad.net/solum/+bug/1292334 It is partly about the duplication in code needed to get a client. The other part of the bug is the config options (which you are dealing with). The other thing to think about is other services want a connection based on user token (plus the cafile stuff above) like in solum/heat. It would be nice to be able to create a connection based on a context and a config. You might also want to look at Steve Baker's monster patch series: https://review.openstack.org/#/q/status:open+project:openstack/heat+branch:master+topic:bp/client-plugins,n,z This stuff should really be in the clients. - -Angus > > Thanks > > Jamie > > [1] https://review.openstack.org/#/c/98955/ > [2] https://review.openstack.org/#/c/95015/ > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTl95aAAoJEFrDYBLxZjWooMsH/iIyev/6HSdCf2/aTtfvJgK2 M0knBZi1Xo3JsjZ14zA1Cz6jJGu0gn3EB4fBqBBWa/a5Ts7bIaOGJgzOhudMtptM Z8Y4CE7kZ7Jqc42a1NVoJjxUkrb1yGZqdS6rsF6MxMLSjYd+xSqVe4RIHoUtomVP YttR7wN2cIXPACFqBBIWnpmcDzhEF1foYW67Kx4JPmDQj5XVC5NW8pXLu735yNyh /aSajYcmUn+6kCsh0OILu7jBak1apislPDhrogyH8S93Tne1G/2gM0f9unnaUq5v JuP+p+EatbVjewpOB7NuVDWD1oTl+VqleaEjiRvdI+c20LOcsOSHcmp8r24s52A= =EizV -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
