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). > > >> >> >>> In the case you'd absorb the Python client libraries, it might make >>> sense to ship the keystone middleware in a separate package that would >>> still live in the Identity program. >> >> >> This needs to happen anyway, it's time for my semi-annual request to >> dolphm... >> >>> I think we need people caring for the end user and their experience of >>> interacting with an OpenStack-backed cloud. I understand that CLI/SDK >>> specialists and GUI-oriented specialists are different crowds, but they >>> share the same objective and would benefit IMHO from being in the same >>> program. There could be two subteams to care for specialists in both >>> areas (or even 3 if you separate the CLI and SDK folks). Overall from >>> the TC perspective it would make a much stronger proposal if you somehow >>> could present a united (and without overlap) proposal. >> >> >> To be honest, until the most recent ML thread I hadn't thought about the >> UX team or even if they were active. We have three basic categories of >> projects delivering code: web UI (Horizon), CLI (OpenStackClient) and SDK >> (at least three active language-based teams). They all should consume the >> output from a UX R&D effort, I guess I am open on the program structure to >> make that work. Horizon is already a part of a program, OSC needs to be and >> the SDKs will also need to be in the near future. >> >> >> dt >> >> -- >> >> Dean Troyer >> dtro...@gmail.com >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
