Open Stack

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 <harlowja at 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 [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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160531/63d8482e/attachment.html>