Open Stack

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. 

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

So i have another review[3] that is attempting to standardize other
common components of the client and how they relate to session. This
object would be created by the client though so i'm not yet sure how we
would go about using this to do common config options. It might be as
simple as creating the common client **kwargs from the config and then
having the services initialize the clients with them. 

At least there is potential there if all clients take those some common
set of variables. There are always going to be some options that are
unique to a client that will have to be handled manually though.

> [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

[3] https://review.openstack.org/#/c/86237/

> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev