Open Stack

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140611/7ee45382/attachment.pgp>