Rationale for having master builds in docker containers?

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Holger Freyther holger at freyther.de
Thu Dec 6 16:26:47 UTC 2018



> On 6. Dec 2018, at 12:12, Tomcsányi, Domonkos <domi at tomcsanyi.net> wrote:
> 
> Hi Neels,
> 
> 2018. dec. 6. dátummal, 13:38 időpontban Neels Hofmeyr <nhofmeyr at sysmocom.de> írta:
> 
>> 
>> Those are the projects that run the python-based external tests, which involve
>> opening up VTY and CTRL ports among others, because we start up the program and
>> interact with it on VTY and CTRL. That means each of those projects is not able
>> to run tests more than once per slave, or we get sporadic conflicts of not
>> being able to start the main program. That was really annoying.
>> 
>> Another complex way would be to round robin through a range of ports or
>> localhost addresses or something, and tweak the .cfg for each test run so that
>> the ports never conflict :/
>> 
>> Or some sort of network segmenting?
> 
> I think Linux network namespaces would be a possible solution for this issue, if I understood correctly, but setting that up feels to me more complicated then using Docker.
> Just my 2cents.

I just skimmed through this thread but it seems to have the right answers.

The primary reason was being able to run multiple instances of the VTY tests
without having to make the (test)software more complex (e.g. bind to vty
port 0 and then parse it) (and the db paths and af_unix paths)


Secondary reasons are making the build environment volatile and managing the
dependencies differently.


For the primary one I looked at "ip netns exec" first but IIRC couldn't find
tools to automatically clean things up. I briefly considered writing something
that does clone+unshare(2) but the toolchain of docker was further and provided
immediate results.

holger


More information about the OpenBSC mailing list