[users at bb.net] debugging DockerLatentWorker

[stefan]

On 2019-03-13 9:48 a.m., Pierre Tardy wrote:
>
>
>     So, I have managed to resolve my problems, so I'd like to report
>     back my findings, for the record.
>
>     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.
>
> 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.
>  This would allow to use arbitrary docker image for running your builds.
>
> Normally this is well explained in 
> http://docs.buildbot.net/latest/manual/configuration/workers-docker.html

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

>
>     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).
>
>     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.
>
> That buildbot.tac is already prepared in the official docker images
> https://github.com/buildbot/buildbot/blob/master/worker/docker/buildbot.tac


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.

>     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 ?
>
> You just have to set the BUILDMASTER 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.

well, without the `--network host` argument I wasn't able to reach the 
master under its fqdn.

>     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.
>
>
> Feel free to contribute one! :)

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.

The travis-ci spec would then be a particular instance of that...

Thanks,

Stefan

--

       ...ich hab' noch einen Koffer in Berlin...
     

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.buildbot.net/pipermail/users/attachments/20190313/7546686f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.png
Type: image/png
Size: 1478 bytes
Desc: not available
URL: <http://lists.buildbot.net/pipermail/users/attachments/20190313/7546686f/attachment.png>