Open Stack

On Wed, May 7, 2014 at 8:32 AM, Brian Curtin <brian at python.org> wrote:

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


Cool, that is even better.

So then step 3 would be:

* Each project can continue maintaining there existing python-*client or
just deprecate it in favor of the what ClientTools will have.

If so that sounds great.


Would client tools be limited to only a pythonSDK or in the future could it
potentially have other languages?


>
> _______________________________________________
> 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/20140507/9d4438af/attachment.html>