[openstack-dev] [nova][cinder][ceilometer][glance][all] Loading clients from a CONF object

Mark McLoughlin markmc at redhat.com
Wed Jun 11 20:18:16 UTC 2014


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.

Mark.




More information about the OpenStack-dev mailing list