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_<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]
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