<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Dec 11, 2013 at 9:35 AM, James Slagle <span dir="ltr"><<a href="mailto:james.slagle@gmail.com" target="_blank">james.slagle@gmail.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="im">On Wed, Dec 11, 2013 at 7:33 AM, Jiří Stránský <<a href="mailto:jistr@redhat.com">jistr@redhat.com</a>> wrote:<br>
> Previously, we had planned Tuskar arcitecture like this:<br>
><br>
> tuskar-ui <-> tuskarclient <-> tuskar-api <-> heat-api|ironic-api|etc.<br>
<br>
</div>To be clear, tuskarclient is just a library right?  So both the UI and<br>
CLI use tuskarclient, at least was that the original plan?</blockquote><div><br></div><div>I would expect tuskarclient above to be the Python API bindings without the business logic.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I don't think we want the business logic in the UI.</blockquote><div><br></div><div>+1</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">

> Now this raises a question - how do we get CLI reasonably on par with<br>
> abilities of the UI? (Or am i wrong that Anna the infrastructure<br>
> administrator would want that?)<br>
<br>
</div>IMO, we want an equivalent CLI and UI.  A big reason is so that it can<br>
be sanely scripted/automated.</blockquote><div><br></div><div>At a minimum you need to be sure that all of the atomic operations in your business logic are exposed via _some_ API.  ie, to script something the script may be where the business logic exists.</div>
<div><br></div><div>Building on that is moving that logic into a library that calls multiple Python client APIs.  This may or may not be part of tuskarclient.</div><div><br></div><div>The next step up is to put your business logic into what we used to call middleware, the layer between client and backend.  This is server-side and IMHO where it belongs.  This is really the ONLY way you can ensure that various clients get the same experience.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><span style="color:rgb(34,34,34)">python-openstackclient consumes other clients :).  Ok, that's probably</span><br>
</div>
not a great example :).<br></blockquote><div><br></div><div>:) No, not really.  But it is also developing some 'value-added' functions that are cross-project APIs and has a similar problem.  So far that is just smoke and mirrors hiding the duck tape behind the scenes but it is not unlike some of the things that Horizon does for user convenience.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This approach makes the most sense to me.  python-tuskarclient would<br>
make the decisions about if it can call the heat api directly, or the<br>
tuskar api, or some other api.  The UI and CLI would then both use<br>
python-tuskarclient.</blockquote><div><br></div><div>If you do this keep the low-level API bindings separate from the higher-level logical API. </div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
> 2) Make a thicker tuskar-api and put the business logic there. (This is the<br>
> original approach with consuming other services from tuskar-api. The<br>
> feedback on this approach was mostly negative though.)<br>
<br>
</div>So, typically, I would say this is the right approach.  However given<br>
what you pointed out above that sometimes we can use other API's<br>
directly, we then have a seperation where sometimes you have to use<br>
tuskar-api and sometimes you'd use heat/etc api.  By using<br>
python-tuskarclient, you're really just pushing that abstraction into<br>
a library instead of an API, and I think that makes some sense.</blockquote><div><br></div><div>Consider that pushig out to the client requires that the client be in sync with what is deployed.  You'll have to make sure your client logic can handle the multiple versions of server APIs that it will encounter.  Putting that server-side lets you stay in sync with the other OpenStack APIs you need to use.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> 3) Keep tuskar-api and python-tuskarclient thin, make another library<br>
> sitting between Tuskar UI and all python-***clients. This new project would<br>
> contain the logic of using undercloud services to provide the "tuskar<br>
> experience" it would expose python bindings for Tuskar UI and contain a CLI.<br>
> (Think of it like traditional python-*client but instead of consuming a REST<br>
> API, it would consume other python-*clients. I wonder if this is<br>
> overengineering. We might end up with too many projects doing too few<br>
> things? :) )<br>
<br>
</div>I don't follow how this new library would be different from<br>
python-tuskarclient.  Unless I'm just misinterpreting what<br>
python-tuskarclient is meant to be, which may very well be true :).</blockquote><div><br></div><div>This is essentially what I suggested above.  It need not be a separate repo or installable package, but the internal API should have its own namespace/modules/whatever.</div>
<div><br></div><div>dt</div></div><div><br></div>-- <br><br>Dean Troyer<br><a href="mailto:dtroyer@gmail.com">dtroyer@gmail.com</a><br>
</div></div>