Open Stack

On Tue, May 6, 2014 at 6:54 AM, Dean Troyer <dtroyer at gmail.com> wrote:

> On Tue, May 6, 2014 at 7:02 AM, Thierry Carrez <thierry at 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
> dtroyer at gmail.com
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140506/26e566e4/attachment.html>