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_<clientname>] >>>> 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_<clientname>] 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 [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
