2016-05-31 22:56 GMT+03:00 Joshua Harlow <harlo...@fastmail.com>: > Denis Makogon wrote: > >> Hello. >> >> It is hard to tell if given API will be final version, but i tried to >> make it similar to CLI and its capabilities. So, why not? >> >> 2016-05-31 22:02 GMT+03:00 Joshua Harlow <harlo...@fastmail.com >> <mailto:harlo...@fastmail.com>>: >> >> Cool good to know, >> >> I see >> >> https://github.com/docker/compose/pull/3535/files#diff-1d1516ea1e61cd8b44d000c578bbd0beR66 >> >> Would that be the primary API? Hard to tell what is the API there >> actually, haha. Is it the run() method? >> >> I was thinking more along the line that higgins could be a >> 'interpreter' of the same docker-compose format (or similar format); >> if the library that is being created takes a docker-compose file and >> turns it into a 'intermediate' version/format that'd be cool. The >> compiled version would then be 'executable' (and introspectable to) >> by say higgins (which could say traverse over that intermediate >> version and activate its own code to turn the intermediate versions >> primitives into reality), or a docker-compose service could or ... >> >> >> What abou TOSCA? From my own perspective compose format is too limited, >> so it is really necessary to consider regarding use of TOSCA in Higgins >> workflows. >> > > 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).
For cursory glance, in OpenStack only Tacker and Murano are supporting TOSCA. From outside the world i know that Cloudify/Aria use using TOSCA. > > > >> >> Libcompose also seems to be targeted at a higher level library, from >> at least reading the summary, neither seem to be taking a compose >> yaml file, turning it into a intermediate format, exposing that >> intermediate format to others for introspection/execution (and also >> likely providing a default execution engine that understands that >> format) but instead both just provide an equivalent of: >> >> >> That's why i've started this thread, as community we have use cases for >> Higgins itself and for compose but most of them are not formalized or >> even written. Isn't this a good time to define them? >> >> project = make_project(yaml_file) >> project.run/up() >> >> Which probably isn't the best API for something like a web-service >> that uses that same library to have. IMHO having a long running >> run() method >> >> >> Well, compose allows to run detached executions for most of its API >> calls. By use of events, we can track service/containers statuses (but >> it is not really trivial). >> > > That's not exactly the same as what I was thinking, > > Let's take a compose yaml file, > https://github.com/DataDog/docker-compose-example/blob/master/docker-compose.yml > > 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. > > 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. > >> exposed, without the necessary state tracking, ability to >> interrupt/pause/resume that run() method and such is not going to >> end well for users of that lib (especially a web-service that needs >> to periodically be `service webservice stop` or restart, or ...). >> >> >> Yes, agreed. But docker or swarm by itself doesn't provide such API >> (can't tell the same for K8t). >> > > 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 > > >> Denis Makogon wrote: >> >> Hello Stackers. >> >> >> As part of discussions around what Higgins is and what its >> mission there >> are were couple of you who mentioned docker-compose [1] and >> necessity of >> doing the same thing for Higgins but from scratch. >> >> I don't think that going that direction is the best way to spend >> development cycles. So, that's why i ask you to take a look at >> recent >> patchset submitted to docker-compose upstream [2] that makes >> this tool >> (initially designed as CLI) to become a library with Python >> API. The >> whole idea is to make docker-compose look similar to libcompose >> [3] >> (written on Go). >> >> If we need to utilize docker-compose features in Higgins i'd >> recommend >> to work on this with Docker community and convince them to land >> that >> patch to upstream. >> >> If you have any questions, please let me know. >> >> [1] https://docs.docker.com/compose/ >> [2] https://github.com/docker/compose/pull/3535 >> [3] https://github.com/docker/libcompose >> >> >> Kind regards, >> Denys Makogon >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> < >> http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev