Open Stack

As Heat integrates with more OpenStack client libraries it has become 
obvious that there is a real lack of consistency in how client 
connections are created.

Our client connection handling can be seen here
https://github.com/heat-api/heat/blob/master/heat/engine/clients.py

Horizon's connection handling is throughout these files
https://github.com/openstack/horizon/tree/master/openstack_dashboard/api

The consistency issues include:
- Keyword arguments differ for the same attributes
   - username, user
   - password, api-key
   - project_id, tenant_id
   - proxy_token, token, preauthtoken
- Positional arguments vary from some to none
- Some clients require an explicit call to authenticate()
- When only a token is passed in, clients differ in what other 
parameters are required (if it works at all)

I think it should be possible to clean this up in a backwards-compatible 
way, and it seems that oslo (openstack-common) has a part to play here.

I'd like to suggest the following approach for feedback.

First to handle any differences in client behaviours (token handling, 
auth flows):
- Document how clients should initialize and authenticate in both the 
username/password and token case. Maybe this exists already? Keystone 
developer help would be appreciated here.
- Raise issues for clients who do things differently

In parallel, to make all client __init__ methods consistent:
- Choose a client that does things the Right Way 
(python-keystoneclient?) that other clients should align with.
- Write some code in oslo (openstack-common) which does the following
   - consumes the positional and keyword arguments passed to client __init__
   - log deprecation warnings for all positional arguments, and any 
non-blessed keywords
   - validates arguments and raises ValueError
   - transforms deprecated arguments to a standardised dict which the 
client uses for initialization
- Port each client to use this, including a standard chunk to add to the 
docstring

Does this approach sound reasonable? I'd especially like to hear from 
any project that objects to their client lib getting this treatment.

cheers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121112/f25d59ba/attachment.html>