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