Open Stack

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=...
> 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