<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jan 16, 2014 at 2:22 PM, Renat Akhmerov <span dir="ltr"><<a href="mailto:rakhmerov@mirantis.com" target="_blank">rakhmerov@mirantis.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div><ul>
<li>Keeping all the clients physically separate/combining them in to a single library. Two things here:</li><ul><li>In case of combining them, what exact project are we considering? If this list is limited to core projects like nova and keystone what policy could we have for other projects to join this list? (Incubation, graduation, something else?)</li>
</ul></ul></div></div></blockquote><div> FWIW, OpenStackClient has Identity built-in as very little else is useful without it.  Compute, Image and Volume are in the repo but structured using the new plugin system to make sure that works well.  Object-store is in the repo but I consider it experimental as it also includes the project API layer and my first cut at a common REST client.</div>
<div><br></div><div>I've already written a POC for solum and some other things to demonstrate how to add additional projects simply by installing the python-*client package.  <a href="https://github.com/dtroyer/python-oscplugin">https://github.com/dtroyer/python-oscplugin</a> is a trivial example.</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><ul><ul><li>In terms of granularity and easiness of development I’m for keeping them separate but have them use the same boilerplate code, basically we need a OpenStack Rest Client Framework which is flexible enough to address all the needs in an abstract domain agnostic manner. I would assume that combining them would be an additional organizational burden that every stakeholder would have to deal with.</li>
</ul></ul></div></div></blockquote><div>If it is not a library that is actually shared you will get back to the current situation over time. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><ul><li>Has anyone ever considered an idea of generating a fully functional REST client automatically based on an API specification (WADL could be used for that)? Not sure how convenient it would be, it really depends on a particular implementation, but as an idea it could be at least thought of. Sounds a little bit crazy though, I recognize it :).</li>
</ul></div><div><blockquote type="cite"><div><div class="h5"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span style="color:rgb(34,34,34)"></span></div></div></div></div></div></blockquote></div></div>
</blockquote></div><div class="gmail_extra">When you have stable and accurate documents of this sort, let's talk.  You may have noticed that few (any?) of the recent major API revs are documented in this manner...</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">dt</div><div><br></div>-- <br><br>Dean Troyer<br><a href="mailto:dtroyer@gmail.com">dtroyer@gmail.com</a><br>
</div></div>