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? > > 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
