Open Stack

On Wed, May 7, 2014 at 7:38 AM, Doug Hellmann
<doug.hellmann at dreamhost.com> wrote:
> 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).

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.