<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 2019-03-13 9:48 a.m., Pierre Tardy
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAJ+soVexbSwdn3PAmi1nHfUjb=Mn-U0f3NfEhc22Z6Tf8SrZCQ@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div class="gmail_quote">
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div text="#000000" bgcolor="#FFFFFF"><br>
              <p>So, I have managed to resolve my problems, so I'd like
                to report back my findings, for the record.</p>
              <p>The main issue was my own confusion about how
                DockerLatentWorker actually operate. Having successfully
                built my project with `bbtravis run`, I expected the
                basic mechanism to be the same, i.e. a Worker "shell" to
                push commands into a docker instance. What I had failed
                to realize was that a buildbot worker instance actually
                had to run *inside* the container.</p>
            </div>
          </blockquote>
          <div>Yes, this is unfortunate. Easier approach would be to
            inject the worker binary inside the container, but this is
            not something we started working on.</div>
          <div> This would allow to use arbitrary docker image for
            running your builds.</div>
          <div><br>
          </div>
          <div>Normally this is well explained in <a
href="http://docs.buildbot.net/latest/manual/configuration/workers-docker.html"
              moz-do-not-send="true">http://docs.buildbot.net/latest/manual/configuration/workers-docker.html</a></div>
        </div>
      </div>
    </blockquote>
    <p>Well, yeah, in hindsight it looks clear. The problem is that
      before you understand it, it has to be clear, too. :-) (But
      slightly more seriously, I agree it's actually clear: I was
      blinded by my own wrong expectations.)<br>
    </p>
    <blockquote type="cite"
cite="mid:CAJ+soVexbSwdn3PAmi1nHfUjb=Mn-U0f3NfEhc22Z6Tf8SrZCQ@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_quote">
          <div><br>
          </div>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div text="#000000" bgcolor="#FFFFFF">
              <p>After that clarification, and having rebuilt my docker
                image correspondingly, things started to fall into place
                (I could inspect the logs from the container to see the
                debug).</p>
              <p>The next stumbling block was the setting up of the
                communication between master and worker. With some help
                from IRC I was able to rewrite the `buildbot.tac` worker
                code to fetch master name, password, as well as some
                other variables from the environment, which the
                DockerLatentWorker conveniently prepared.</p>
            </div>
          </blockquote>
          <div>That buildbot.tac is already prepared in the official
            docker images</div>
          <div><a
href="https://github.com/buildbot/buildbot/blob/master/worker/docker/buildbot.tac"
              moz-do-not-send="true">https://github.com/buildbot/buildbot/blob/master/worker/docker/buildbot.tac</a><br>
          </div>
        </div>
      </div>
    </blockquote>
    <p><br>
    </p>
    <p>Fair enough. This is also a bit confusing: there are many
      different ways to use docker: one is to simply encapsulate the
      environment to run buildbot *in* (once for the master, once for
      the worker), another one is to use *inside* the worker. Combined
      with my confusion as to whether docker runs inside the worker, or
      the worker runs inside docker (actually both !), this didn't help.<br>
    </p>
    <blockquote type="cite"
cite="mid:CAJ+soVexbSwdn3PAmi1nHfUjb=Mn-U0f3NfEhc22Z6Tf8SrZCQ@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_quote">
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div text="#000000" bgcolor="#FFFFFF">
              <p>The last item was / is how to establish the master host
                address such that the worker can reach it from inside
                the container. Given that the master passes the hostname
                down to the worker, and given that in my case I was
                running the worker on the same machine, I simply added
                `--network host` to the worker's `host_config`
                constructor argument, and things started to work. Still,
                this seems a bit hackish at best. Any idea how to do
                that properly ?</p>
            </div>
          </blockquote>
          <div>You just have to set the <span style="color:rgb(3,47,98);font-family:SFMono-Regular,Consolas,"Liberation Mono",Menlo,Courier,monospace;font-size:12px;white-space:pre">BUILDMASTER </span>variable
            to the master fqdn. Even if the container runs on localhost,
            worker  would be able to more easily reach it. as normally,
            docker takes care of the routing and the dns.</div>
        </div>
      </div>
    </blockquote>
    <p>well, without the `--network host` argument I wasn't able to
      reach the master under its fqdn.<br>
    </p>
    <blockquote type="cite"
cite="mid:CAJ+soVexbSwdn3PAmi1nHfUjb=Mn-U0f3NfEhc22Z6Tf8SrZCQ@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_quote">
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div text="#000000" bgcolor="#FFFFFF">
              <p>I still think one or two example setups would be nice,
                as a starting point. So far all I have found were
                exampes using a LocalWorker, or (in case of the buildbot
                metabot), a KubeLatentWorker, which is one step too
                much.<br>
              </p>
            </div>
          </blockquote>
          <div><br>
          </div>
          <div>Feel free to contribute one! :)</div>
        </div>
      </div>
    </blockquote>
    <p>I'm considering it (once my comfort level improves a bit). I'm
      also considering to contribute to the buildbot_travis extension:
      I'm now using a slightly different yml spec, so generalized the
      code that maps the yml file to a set of builds with corresponding
      build steps.<br>
    </p>
    <p>The travis-ci spec would then be a particular instance of that...<br>
    </p>
    <p>Thanks,<br>
    </p>
    <div class="moz-signature">
      <div class="moz-signature"><img moz-do-not-send="false"
          src="cid:part3.48A44D0A.BF77D44F@seefeld.name" alt="Stefan"
          width="73" height="45"><br>
        <pre>--

      ...ich hab' noch einen Koffer in Berlin...
    </pre>
      </div>
    </div>
  </body>
</html>