I tried
and I have a Json response
I have just created roboconf/roboconf.github.io#90 about the tutorial to update...
2017-11-14 11:14:39,376 | ERROR | edTargetHandler$CheckingRunnable | An error occurred while configuring machine 'rbcf_8d6bd158-4b52-4a81-a1d9-1124577f53cd'. com.github.dockerjava.api.exception.NotFoundException: {"message":"No such image: demo_roboconf_demo:latest"}
2017-11-14 11:17:26,870 | ERROR | ManagedApplication | Agent /MySQL VM has not sent heart beats for quite a long time. Status changed to PROBLEM.
No image was generated, no container was launched. This error is obvious.
Eventually...
A method was found for cap-add but it does not have the right parameter type. Skipping it. You may want to add a feature request.
I do not know what to think about it for the moment (even if I do understand what it means).
Now...
I forced a manual demo_robo_conf_demo image
for all containers at the same time
overall for the tutorial not updated
(your confirmation)
we wanted before a successful local test...
on docker
I would suggest switching directly to the third step, that is to say creating or updating a Roboconf application with your components. The graph part is fairly simple. What takes times is writing recipes. It all depends on how you deploy. There are 3 approaches to mix Roboconf and Docker, and the one you are using is not the best one (it is the oldest one and has many drawbacks). I suggest you use the "embedded" target handler to test locally.
If your scripts manage Docker images, that will have no impact on your machine. You can use in-memory agents that will execute real recipes. And your recipes will be Docker containers. This way, you will be able to test locally and be able to switch seamlessly to a real IaaS.
I'll check whether I have an example somewhere.
thanks
And here, you have examples of Roboconf components / scripts that manage Docker containers. https://github.com/roboconf-recipes/docker-cassandra-cluster/tree/master/src/main/model/graph/cassandraNode/scripts
This is how I manage Docker deployments now with Roboconf.
With the "target.properties" file, agents are not running in Docker or on a VM. They run inside the DM.
And they execute real recipes / scripts. And these scripts manage Docker containers.
This way, you can test locally. Once you want to deploy on a real IaaS, just replace the "target.properties" file.
Obviously, make sure to not rely on Docker links or networks. Inject the location of other components at startup.
(location = IP)
I'll take a look at this chat tomorrow.
As a summary, do not focus on using the "Docker target", use the "embedded" one instead.