canonical-certification-server does not include config files nor does it create /etc/checkbox.d (or plainbox.d)

[Jeff Lane ]

the old cert tool created a dir: /etc/checkbox.d and stored the checkbox ini files and a few config files there: network.cfg and virtualization.cfg.

canonical-certification-server does not seem to pull in these files.

After chatting with Daniel, it appears that they are not being packaged when the canonical-certification-server packages are built.

<roadmr> bladernr: fwiw, plainbox-provider-checkbox should be the one packaging those files and creating that legacy dir

without these files in the expected location, the virtualization and multi-nic tests will fail to execute.

[Daniel Manrique (roadmr)]

At the moment the old checkbox package is the only one creating and installing these files.

A problem we will have is that two packages can't install the same file, so it may not be as easy as packaging the same file twice.

I checked and the only two scripts that have that location hardcoded are virtualization and network. One option would be defining a new location for config files (i.e. /etc/plainbox.d or something that makes more sense) and having those two scripts also check that other location. It may be easier than jumping through packaging hoops so that both packages can manage the same file.

[Zygmunt Krynicki (zyga)]

15:43 < roadmr> zyga: hey, would you mind giving your opinion on this bug? https://bugs.launchpad.net/checkbox/+bug/1260507
15:43 < roadmr> zyga: you don't need to write code or anything, just check if the solution I proposed makes sense so we can start actually coding it
15:44 < zyga> roadmr: sure
15:45 < roadmr> thanks!
15:46 < zyga> roadmr: hmm
15:46 < zyga> roadmr: being lazy, are those jobs actively looking at /etc/checkbox.d/foo.conf for their configuration?
15:46 < roadmr> zyga: yes, they are, the location is hardcoded in the script
15:46 < zyga> roadmr: ok
15:47 < zyga> roadmr: can we patch them to use environment variables instead?
15:47 < roadmr> zyga: we can obviously change the scripts themselves, but we need to keep backward compatibility for checkbox
15:47 < zyga> roadmr: (I'm not saying that's the way, just exploring)
15:47 < zyga> roadmr: does checkbox-old support setting environment somehow?
15:47 < roadmr> zyga: yes, we could do that, and checkbox-old can do the environment thing
15:48 < roadmr> zyga: spideyman wanted to have a dedicated config file so it would be easier/more discoverable
15:48 < zyga> roadmr: ok, so it'd be a transition of some sort, is that expected to be a problem for our users?
15:48 < zyga> ah
15:48 < roadmr> magic env variables were a bit more opaque
15:48 < zyga> that's true
15:48 < zyga> hmm
15:48 < zyga> so for now, I don't know, we can bundle those files but what should we put inside?
15:48 < zyga> I assume that each installation would need to edit those
15:49 < roadmr> zyga: checkbox includes some defaults (think skeletons), they won't work out of the box but they're easy to find
15:49 < roadmr> zyga: they're also documented, so as long as we include those dummy files we should be OK
15:49 < zyga> ok
15:49 < zyga> IMHO for now our jobs are okay to configure with environment (while ugly that will work)
15:49 < roadmr> zyga: so it'd be just a matter of packaging them in plainbox-provider-checkbox or something. Again, the problem is that I don't think I can put them in the same location
15:49 < zyga> later on we may think of something better
15:49 < zyga> ohhh
15:49 < zyga> crapper
15:49 < zyga> yeah
15:49 < zyga> let me think
15:49 < roadmr> zyga: yes, otherwise it would be a non-issue :D
15:52 < roadmr> zyga: remember we can always hack the scripts to look for their config files in two potential locations. It's kludgy but would be reasonable as a transitional measure I think
15:52 < zyga> roadmr: so apart from having a dummy package with two dummy config files, there are no easy solutions
15:53 < zyga> roadmr: urgh, no, that's not good
15:53 < roadmr> can we put a "rabbit-hole" tag in that bug? \o/
15:53 < zyga> roadmr: I think my vote would be to allow config to be specified from environment and explain plainbox.conf (or derivative) to provider that in the environment section
15:54 < zyga> roadmr: shall we add this to the bug report?
15:54 < roadmr> zyga: ok, so how about we look for checkbox.d/whatever, if *not* found, then the scripts should fall back to env variables
15:54 < roadmr> zyga: then as you say those can be configured in plainbox.conf
15:55 < roadmr> zyga: an advantage of plainbox.c...

[Daniel Manrique (roadmr)]

I'll replicate the commit message here to further document how this was solved.

scripts/network and scripts/virtualization can now be configured via environment variables, in addition to the existing config file mechanism and command-line parameters.

This is most useful with canonical-certification-server or other plainbox-based testing tools (i.e. in the absence of checkbox proper). In this case all configuration is centralized in the plainbox config file (/etc/xdg/plainbox.conf). These variables can be defined in the [environment] section with the familiar config file syntax.

For virtualization, the KVM_IMAGE and KVM_TIMEOUT variables are picked up.

For network, it's TEST_TARGET_FTP, TEST_TARGET_IPERF, TEST_USER and TEST_PASS. Separate variables are used for iperf and ftp to mimic the existing config file behavior (but note that a single --target command-line parameter is used in all cases).

Across the board, the preference order is command line -> environment -> config file.