<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-05-31 22:56 GMT+03:00 Joshua Harlow <span dir="ltr"><<a href="mailto:harlowja@fastmail.com" target="_blank">harlowja@fastmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Denis Makogon wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
Hello.<br>
<br>
It is hard to tell if given API will be final version, but i tried to<br>
make it similar to CLI and its capabilities. So, why not?<br>
<br>
2016-05-31 22:02 GMT+03:00 Joshua Harlow <<a href="mailto:harlowja@fastmail.com" target="_blank">harlowja@fastmail.com</a><br></span>
<mailto:<a href="mailto:harlowja@fastmail.com" target="_blank">harlowja@fastmail.com</a>>>:<span class=""><br>
<br>
Cool good to know,<br>
<br>
I see<br>
<a href="https://github.com/docker/compose/pull/3535/files#diff-1d1516ea1e61cd8b44d000c578bbd0beR66" rel="noreferrer" target="_blank">https://github.com/docker/compose/pull/3535/files#diff-1d1516ea1e61cd8b44d000c578bbd0beR66</a><br>
<br>
Would that be the primary API? Hard to tell what is the API there<br>
actually, haha. Is it the run() method?<br>
<br>
I was thinking more along the line that higgins could be a<br>
'interpreter' of the same docker-compose format (or similar format);<br>
if the library that is being created takes a docker-compose file and<br>
turns it into a 'intermediate' version/format that'd be cool. The<br>
compiled version would then be 'executable' (and introspectable to)<br>
by say higgins (which could say traverse over that intermediate<br>
version and activate its own code to turn the intermediate versions<br>
primitives into reality), or a docker-compose service could or ...<br>
<br>
<br>
What abou TOSCA? From my own perspective compose format is too limited,<br>
so it is really necessary to consider regarding use of TOSCA in Higgins<br>
workflows.<br>
</span></blockquote>
<br>
Does anyone in the wider world actually use TOSCA anywhere? Has it gained any adoption? I've watched the TOSCA stuff, but have really been unable to tell what kind of an impact TOSCA actually has had (everyone seems to make there own format, and not care that much about TOSCA in general, for better or worse).</blockquote><div><br></div><div>For cursory glance, in OpenStack only Tacker and Murano are supporting TOSCA. From outside the world i know that Cloudify/Aria use using TOSCA.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
Libcompose also seems to be targeted at a higher level library, from<br>
at least reading the summary, neither seem to be taking a compose<br>
yaml file, turning it into a intermediate format, exposing that<br>
intermediate format to others for introspection/execution (and also<br>
likely providing a default execution engine that understands that<br>
format) but instead both just provide an equivalent of:<br>
<br>
<br>
That's why i've started this thread, as community we have use cases for<br>
Higgins itself and for compose but most of them are not formalized or<br>
even written. Isn't this a good time to define them?<br>
<br>
project = make_project(yaml_file)<br>
project.run/up()<br>
<br>
Which probably isn't the best API for something like a web-service<br>
that uses that same library to have. IMHO having a long running<br>
run() method<br>
<br>
<br>
Well, compose allows to run detached executions for most of its API<br>
calls. By use of events, we can track service/containers statuses (but<br>
it is not really trivial).<br>
</blockquote>
<br></span>
That's not exactly the same as what I was thinking,<br>
<br>
Let's take a compose yaml file, <a href="https://github.com/DataDog/docker-compose-example/blob/master/docker-compose.yml" rel="noreferrer" target="_blank">https://github.com/DataDog/docker-compose-example/blob/master/docker-compose.yml</a><br>
<br>
At some point this is turned into a set of actions to run (a workflow perhaps) to turn that yaml file into an actual running solution, now likely the creators of libcompose or the python version embedded those actions directly into the interpretation and made them inseparable but that doesn't need to be the case.<span class=""><br>
<br></span></blockquote><div><br></div><div>Well, if to follow that logic in Higgins we don't need compose at all, but we need DSL translator with ability to embed custom actions over services/containers descriptions.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
exposed, without the necessary state tracking, ability to<br>
interrupt/pause/resume that run() method and such is not going to<br>
end well for users of that lib (especially a web-service that needs<br>
to periodically be `service webservice stop` or restart, or ...).<br>
<br>
<br>
Yes, agreed. But docker or swarm by itself doesn't provide such API<br>
(can't tell the same for K8t).<br>
</blockquote>
<br></span>
Meh, that's not such a good excuse to try to do it (or at least to think about it). If we only did what was already done, we probably wouldn't be doing things over email or driving cars or... :-P<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
<br>
Denis Makogon wrote:<br>
<br>
Hello Stackers.<br>
<br>
<br>
As part of discussions around what Higgins is and what its<br>
mission there<br>
are were couple of you who mentioned docker-compose [1] and<br>
necessity of<br>
doing the same thing for Higgins but from scratch.<br>
<br>
I don't think that going that direction is the best way to spend<br>
development cycles. So, that's why i ask you to take a look at<br>
recent<br>
patchset submitted to docker-compose upstream [2] that makes<br>
this tool<br>
(initially designed as CLI) to become a library with Python<br>
API. The<br>
whole idea is to make docker-compose look similar to libcompose [3]<br>
(written on Go).<br>
<br>
If we need to utilize docker-compose features in Higgins i'd<br>
recommend<br>
to work on this with Docker community and convince them to land that<br>
patch to upstream.<br>
<br>
If you have any questions, please let me know.<br>
<br>
[1] <a href="https://docs.docker.com/compose/" rel="noreferrer" target="_blank">https://docs.docker.com/compose/</a><br>
[2] <a href="https://github.com/docker/compose/pull/3535" rel="noreferrer" target="_blank">https://github.com/docker/compose/pull/3535</a><br>
[3] <a href="https://github.com/docker/libcompose" rel="noreferrer" target="_blank">https://github.com/docker/libcompose</a><br>
<br>
<br>
Kind regards,<br>
Denys Makogon<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe:<br>
<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></div></div>
<<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><span class=""><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>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe:<br>
<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></span>
<<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><span class=""><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>
<br>
<br>
__________________________________________________________________________<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>
</span></blockquote><div class="HOEnZb"><div class="h5">
<br>
__________________________________________________________________________<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>