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. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev