[openstack-dev] [higgins] Docker-compose support
lildee1991 at gmail.com
Tue May 31 19:24:44 UTC 2016
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 <harlowja at fastmail.com>:
> Cool good to know,
> I see
> 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
> 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)
> 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
> 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)
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev