taverna-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stian Soiland-Reyes <st...@apache.org>
Subject Re: Finalize Docker Invoke JSON format
Date Wed, 08 Jun 2016 16:28:13 GMT
Is it possible/easy to submit stdin input via the REST API?

The API discusses if "One client attaches to STDIN" under the "Attach
to a container" section.

this uses HTTP 1.1 upgrade to a pure TCP connection - this would put
restrictions on how you can do the HTTP connection, or is that easy to
do say with Apache HTTP Components?

Perhaps look at existing Docker APIs for Java?

https://github.com/docker-java/docker-java (Apache license)
https://github.com/spotify/docker-client (Apache license)

Sending from Taverna should be easy as you can ask for an input stream
from every kind of reference, and just forward the bytes straight to
that attached stream, e.g. with CommonIO.copy(InputStream,

As a good simple test for stdin/stdout, perhaps "wc" in the busybox
image to count words - e.g. replicating something like:

stain@biggiebuntu:~/src/taverna$ echo "Hello there man" | docker run
-i busybox wc
        1         3        16

On 8 June 2016 at 01:52, Nadeesh Dilanga <nadeesh092@gmail.com> wrote:
> Hi Alan,
> Can you please elaborate what you mean by " It is not sufficient to just
> start the container if it expects input data to be sent to stdin, or to be
> in specific locations." ?
> When starting a container using remote API, the only response we get is a
> HTTP status code along with a message body with container id which
> indicates the container started successfully. I assume you meant more on IF
> the application in the container expects input data to be applied and sent
> to stdin, and for such cases how we are going to cater that requirement ?
> On Mon, Jun 6, 2016 at 4:33 AM, Alan Williams <alaninmcr@googlemail.com>
> wrote:
>> On 04-Jun-16 05:10, Nadeesh Dilanga wrote:
>>> Hi all,
>>> I am starting this thread to discuss and finalize the docker commands we
>>> need to expose for client side(Taverna).
>>> Latest stable docker remote API is version 1.23[1]. And it has several
>>> APIs
>>> that can be useful.
>> Yes. Where do you intend to run the docker containers? That would be
>> similar to how you can specify where to run tool services - although I
>> dislike how that is done.
>> The original JIRA [2] mentioned about the JSON format to a docker run. I
>>> hope it meant about the docker config.json ?
>> That would be a lot of configuration. I am not sure that it is sensible to
>> have it all specified in the workflow.
>> Because, given we use remote APIs, I would like to know what are the
>>> expectations are ?
>>> 1. Do we assume that Images are created and published to the registry.
>> Yes, certainly for running you will know the registry and the image.
>> 2. Do we assume that docker container is created
>> I don't think you can, as that would mean there are steps needed to be
>> done before the workflow can be run.
>> Given #1 and #2 done, then we are talking about starting the
>>> container(~docker run). If that is the case, when we use remote APIs we
>>> only need following, and no need of a JSON:
>>> Request: POST /containers/(id or name)/start
>>> Response: HTTP/1.1 204 No Content
>>> There are other responses too:
>>> Status Codes:
>>>    - *204* – no error
>>>    - *304* – container already started
>>>    - *404* – no such container
>>>    - *500* – server error
>> You will need to look at how the input data is read and the results
>> returned. It is not sufficient to just start the container if it expects
>> input data to be sent to stdin, or to be in specific locations.
>> [1] -
>>> https://docs.docker.com/engine/reference/api/docker_remote_api_v1.23/
>> Alan

Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons

View raw message