On Wed, May 7, 2014 at 7:38 AM, Doug Hellmann <doug.hellm...@dreamhost.com> wrote: > On Tue, May 6, 2014 at 5:45 PM, Joe Gordon <joe.gord...@gmail.com> wrote: >> >> >> >> On Tue, May 6, 2014 at 6:54 AM, Dean Troyer <dtro...@gmail.com> wrote: >>> >>> On Tue, May 6, 2014 at 7:02 AM, Thierry Carrez <thie...@openstack.org> >>> wrote: >>>> >>>> Would you take over the Python client libraries as well ? On one hand >>>> they need /some/ domain expertise, but on the other I see no reason to >>>> special-case Python against other SDKs, and that may give the libraries >>>> a bit more attention and convergence (they currently are the ugly >>>> stepchild in some programs, and vary a lot). >>> >>> >>> The future of the existing client libs has not been settled, my working >>> assumption is that they would remain with their home programs as they are >>> now. From the start OpenStackClient was meant to be a clean-slate for the >>> CLI and the Python SDK is taking the same basic approach. >> >> >> >> Very excited for the OpenStackClient, it is already way nicer then the >> existing clients. >> >> >> Just working this out in my head. So the work flow would be: >> >> 1. At first ClientTools consist of just the OpenStackClient >> 2. When the pythonSDK is ready to move off of stackforge, it will live in >> ClientTools >> 3. Specific python-*clients will be rewritten (from scratch?) to use the >> PythonSDK. But this time they won't have a built in CLI. These libraries >> will live along side the respective servers (so nova's python-novaclient >> will live in Compute)? All while moving OpenStackClient to the new libraries >> >> >> Is that what you are proposing? > > My understanding is that the SDK aims to be a ground-up replacement > for the existing disparate client libraries. Whether that replacement > is appropriate for use inside OpenStack may be up for debate (I think > I remember someone saying that wasn't necessarily a goal, with the > focus being on end users, but I haven't been able to attend many of > the meetings so my information may be out of date).
Ideally the python-openstacksdk becomes the one-stop shop for interacting with OpenStack as an OpenStack contributor, an operator, an end-user of an OpenStack cloud, etc. If you're writing Python code to work with OpenStack, that would be the place to go for code, tools, examples, and documentation. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
