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>: > 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. > > 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). > 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). > 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  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  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  >> (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. >> >>  https://docs.docker.com/compose/ >>  https://github.com/docker/compose/pull/3535 >>  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://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