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).
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.
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
