Open Stack

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