Open Stack

Thanks guys, very helpful.

Aaron


On Wed, Jun 25, 2014 at 11:53 PM, Jamie Lennox <jamielennox at redhat.com>
wrote:

> On Wed, 2014-06-25 at 22:42 -0500, Dean Troyer wrote:
> > On Wed, Jun 25, 2014 at 10:18 PM, Aaron Rosen <aaronorosen at gmail.com>
> > wrote:
> >         I'm looking at creating a new python-<new_project_name>client
> >         and I was wondering if there was any on going effort to share
> >         code between the clients or not? I've looked at the code in
> >         python-novaclient and python-neutronclient and both of them
> >         seem to have their own homegrown HTTPClient and keystone
> >         integration. Figured I'd ping the mailing list here before I
> >         go on and make my own homegrown HTTPClient as well.
> >
> >
> > For things in the library level of a client please consider using
> > keystoneclient's fairly new session layer as the basis of your HTTP
> > layer.  That will also give you access to the new style auth plugins,
> > assuming you want to do Keystone auth with this client.
> >
> >
> > I'm not sure if Jamie has any examples of using this without leaning
> > on the backward-compatibility bits that the existing clients need.
> >
> >
> > The Python SDK is being built on a similar Session layer (without the
> > backeard compat bits).
> >
> >
> > dt
>
> I'd love to suggest following in the footsteps of the SDK, but it's just
> a little early for that.
>
> Today the best thing i think would be to use the session from
> keystoneclient, and copy and paste the adapter:
> https://review.openstack.org/#/c/86237/ which is approved but not in a
> release yet. A client object takes a session and kwargs and creates an
> adapter with them.
>
> Then reuse the managers from
>
> https://github.com/openstack/oslo-incubator/blob/master/openstack/common/apiclient/base.py
> I'm personally not a fan, but most of the other clients use this layout
> and I assume you're more interested in getting things done in a standard
> way than arguing over client design (If you are interested in that the
> SDK project could always use a hand). Pass the adapter to the managers.
>
> Don't write a CLI, you can extend OSC to handle your new service. There
> are no docs for it (that i'm aware of) but the included services all use
> the plugin interface so you can copy from one of those.
>
> I don't have a pure example of these things, but if any of the above is
> unclear feel free to find me on IRC and i'll step you through it.
>
> Jamie
>
> >
> >
> > --
> >
> > Dean Troyer
> > dtroyer at gmail.com
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> _______________________________________________
> 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/20140626/b3e7cc9c/attachment.html>