<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 10 November 2015 at 16:12, Giulio Fidente <span dir="ltr"><<a href="mailto:gfidente@redhat.com" target="_blank">gfidente@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 11/10/2015 04:47 PM, Dmitry Tantsur wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 11/10/2015 04:37 PM, Giulio Fidente wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 11/10/2015 04:16 PM, Dmitry Tantsur wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 11/10/2015 04:08 PM, Tzu-Mainn Chen wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi all,<br>
<br>
At the last IRC meeting it was agreed that the new TripleO REST API<br>
should forgo the Tuskar name, and simply be called... the TripleO<br>
API.  There's one more point of discussion: where should the API<br>
live?  There are two possibilities:<br>
<br>
a) Put it in tripleo-common, where the business logic lives.  If we<br>
do this, it would make sense to rename tripleo-common to simply<br>
tripleo.<br>
</blockquote>
<br>
+1 for both<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
b) Put it in its own repo, tripleo-api<br>
</blockquote></blockquote>
<br>
if both the api (coming) and the cli (currently python-tripleoclient)<br>
are meant to consume the shared code (business logic) from<br>
tripleo-common, then I think it makes sense to keep each in its own repo<br>
... so that we avoid renaming tripleo-common as well<br>
</blockquote>
<br>
tripleoclient should not consume tripleo-common<br>
</blockquote>
<br></span>
so FWIW I think my vote is different depending on the plans:<br>
<br>
a. if python-tripleoclient will be changed so that it uses tripleo-api, then I'd vote for option 1) (have tripleo-api in -common and rename)<br></blockquote><div><br></div><div>I think this is what we want. Supporting both a Python API and REST API adds a ton of extra work. It will take some time to transition the CLI over, but I think it is worth it.<br><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
b. if python-tripleoclient will be changed so that it uses the shared library in -common, then I'd vote for for option 2) (have tripleo-api in its own repo)<br>
<br>
<br>
on a side note, I think it should always be possible for the deployer to skip any business logic to give complete control over the template params for both the initial deployments and the updates<span class="im HOEnZb"><br>
-- <br>
Giulio Fidente<br>
GPG KEY: 08D733BA | IRC: giulivo<br>
<br></span><div class="HOEnZb"><div class="h5">
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>