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

Jamie Lennox jamielennox at redhat.com
Thu Jun 12 00:02:24 UTC 2014


On Wed, 2014-06-11 at 04:43 +0000, Angus Salkeld wrote:
> On 11/06/14 13:10, 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. 
> 
> Nice, we have this bug too in Solum: https://bugs.launchpad.net/solum/+bug/1292334
> 
> It is partly about the duplication in code needed to get a client.
> The other part of the bug is the config options (which you are dealing with).
> 
> The other thing to think about is other services want a connection based on
> user token (plus the cafile stuff above) like in solum/heat.
> 
> It would be nice to be able to create a connection based on a context and a config.
> 
> You might also want to look at Steve Baker's monster patch series:
> https://review.openstack.org/#/q/status:open+project:openstack/heat+branch:master+topic:bp/client-plugins,n,z
> 
> This stuff should really be in the clients.
> 
> -Angus

Indeed, so this is part of the reason for the separation of session and
auth plugin. Session will often want to be client dependent (though
there's no reason not to share) and simply loaded from conf, but auth
may need to be from conf or user based.

My current thought is that i pass down an auth plugin out of auth_token
middleware so that starting a client with user credentials would look
something like: 

    sess = session.Session.from_config_options(CONF, 'cinder')
    sess.auth = env['keystone.user_auth_plugin']
    
    cinder = cinderclient.v1.client.Client(sess) 

That auth plugin would be fairly simple so you could easily construct it
from the context or from the headers created by auth_token (i don't know
how common the context object is between services to do it that way). 

> > 
> > Thanks 
> > 
> > Jamie
> > 
> > [1] https://review.openstack.org/#/c/98955/
> > [2] https://review.openstack.org/#/c/95015/
> > 
> > 
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev






More information about the OpenStack-dev mailing list