On Thu, 2014-01-16 at 09:03 +0100, Flavio Percoco wrote: > On 15/01/14 21:35 +0000, Jesse Noller wrote: > > > >On Jan 15, 2014, at 1:37 PM, Doug Hellmann <doug.hellm...@dreamhost.com> > >wrote: > > > >> Several people have mentioned to me that they are interested in, or > >> actively working on, code related to a "common" client library -- > >> something meant to be reused directly as a basis for creating a common > >> library for all of the openstack clients to use. There's a blueprint [1] > >> in oslo, and I believe the keystone devs and unified CLI teams are > >> probably interested in ensuring that the resulting API ends up meeting all > >> of our various requirements. > >> > >> If you're interested in this effort, please subscribe to the blueprint and > >> use that to coordinate efforts so we don't produce more than one common > >> library. ;-) > >> > >> Thanks, > >> Doug > >> > >> > >> [1] https://blueprints.launchpad.net/oslo/+spec/common-client-library-2 > > > >*raises hand* > > > >Me me! > > > >I’ve been talking to many contributors about the Developer Experience stuff > >I emailed out prior to the holidays and I was starting blueprint work, but > >this is a great pointer. I’m going to have to sync up with Alexei. > > > >I think solving this for openstack developers and maintainers as the > >blueprint says is a big win in terms of code reuse / maintenance and > >consistent but more so for *end-user developers* consuming openstack clouds. > > > >Some background - there’s some terminology mismatch but the rough idea is > >the same: > > > >* A centralized “SDK” (Software Development Kit) would be built condensing > >the common code and logic and operations into a single namespace. > > > >* This SDK would be able to be used by “downstream” CLIs - essentially the > >CLIs become a specialized front end - and in some cases, only an argparse or > >cliff front-end to the SDK methods located in the (for example) > >openstack.client.api.compute > > > >* The SDK would handle Auth, re-auth (expired tokens, etc) for long-lived > >clients - all of the openstack.client.api.** classes would accept an Auth > >object to delegate management / mocking of the Auth / service catalog stuff > >to. This means developers building applications (say for example, horizon) > >don’t need to worry about token/expired authentication/etc. > > > >* Simplify the dependency graph & code for the existing tools to enable > >single binary installs (py2exe, py2app, etc) for end users of the command > >line tools. > > > >Short version: if a developer wants to consume an openstack cloud; the would > >have a single SDK with minimal dependencies and import from a single > >namespace. An example application might look like: > > > >from openstack.api import AuthV2 > >from openstack.api import ComputeV2 > > > >myauth = AuthV2(…., connect=True) > >compute = ComputeV2(myauth) > > > >compute.list_flavors() > > > > I know this is an example but, could we leave the version out of the > class name? Having something like: > > from openstack.api.v2 import Compute > > or > > from openstack.compute.v2 import Instance > > (just made that up) > > for marconi we're using the later.
++ -jay _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
