Open Stack

On Tue, May 6, 2014 at 5:45 PM, Joe Gordon <joe.gordon0 at gmail.com> wrote:
>
>
>
> 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?

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
>> dtroyer at gmail.com
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>