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