Open Stack

2016-05-31 22:56 GMT+03:00 Joshua Harlow <harlowja at 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 <harlowja at fastmail.com
>> <mailto: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.
>>
>
> 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-request at lists.openstack.org?subject:unsubscribe
>>         <
>> http://OpenStack-dev-request@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://OpenStack-dev-request@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
>>
>
> __________________________________________________________________________
> 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/20160601/7da30122/attachment.html>