Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Vincent Zurczak
    @vincent-zurczak
    The client could not connect, but I do not know why the connection failed.
    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"}
    amchess
    @amchess
    Based on the tutorial, the ubuntu:latest image should be all I need because
    Vincent Zurczak
    @vincent-zurczak
    This second error is normal, our Docker driver does not generate images in the same way than before.
    amchess
    @amchess
    from that Roboconf can generate the demo_roboconf_demo docker container
    Vincent Zurczak
    @vincent-zurczak
    You can mention the tutorial as much as you want, I told you it is not up-to-date. ;)
    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...
    amchess
    @amchess
    ok
    Vincent Zurczak
    @vincent-zurczak
    And what makes more scared...
    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...
    amchess
    @amchess
    Perhaps, this error is because
    I forced a manual demo_robo_conf_demo image
    for all containers at the same time
    Vincent Zurczak
    @vincent-zurczak
    Not sure. I am reading Marc's message about your plans. :)
    amchess
    @amchess
    ok
    everyway, thanks for your response
    overall for the tutorial not updated
    (your confirmation)
    Vincent Zurczak
    @vincent-zurczak
    OK. Marc indicated Docker as an intermediate solution to test Mongo and your Java web app. Right?
    amchess
    @amchess
    yes
    we wanted before a successful local test...
    on docker
    Vincent Zurczak
    @vincent-zurczak
    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.
    amchess
    @amchess
    ok
    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)
    Vincent Zurczak
    @vincent-zurczak
    I do not know whether you have questions or not.
    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.
    Vincent Zurczak
    @vincent-zurczak
    Hi. A night later, I have realized I told you something wrong. The example is right. But the target handler to use is not 'embedded", it's "in-memory". I had other things in mind yesterday, sorry.
    amchess
    @amchess
    what example do you mean?
    il est spécifié "in-memory"
    et je l'ai fait