Open Stack

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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev