On Wed, May 7, 2014 at 8:32 AM, Brian Curtin <br...@python.org> wrote:
> On Wed, May 7, 2014 at 7:38 AM, Doug Hellmann > <doug.hellm...@dreamhost.com> wrote: > > On Tue, May 6, 2014 at 5:45 PM, Joe Gordon <joe.gord...@gmail.com> > wrote: > >> > >> > >> > >> 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? > > > > 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@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
