iotlab-experiment: errors when binaries have same name but different paths

[miri64]

When running iotlab-experiment with two distinct binaries with the same name e.g. (using RIOT's tests/gnrc_udp for two different boards):

iotlab-experiment submit -d 30 \
    -l1,archi=samr21:at86rf233+site=saclay,bin/samr21-xpro/tests_gnrc_udp.elf \
    -l1,archi=arduino-zero:xbee+site=bin/arduino-zero/tests_gnrc_udp.elf

I get an error:

usage: iotlab-experiment [-h] [-u USERNAME] [-p PASSWORD] [-v]
                         [--jmespath JMESPATH] [--format FORMAT]
                         {submit,script,stop,get,load,reload,info,wait} ...
iotlab-experiment: error: Has different values for same key 'tests_gnrc_udp.elf'

Is there a way (except renaming the binary) to get around this somehow?

[rienafairefr]

Hi Martine,
Unfortunately this is inherent to the way the experiment is submitted. Because this is a multipart upload, and because the firmware association only considers the firmware file name, if we ever allowed the API to succeed on such a request, then we wouldn't be able to know which firmware to use for which node, because they are named the same. It's like having two files with the same name in a directory, it's just impossible.

You could theoretically send a multipart manually with duplicated entries (without cli-tools, or by modifying cli-tools), containing both firmware files, but the backend API would assume the first one it encounters is the one needed by a given node, and you would get samr21 nodes flashed with arduino-zero firmwares, or the inverse.

To work around this and get the behavior your want, I think the only options are:

• name the firmwares differently, should be possible through a flag on the make command to build the RIOT app
• flash the firmwares sequentially, i.e. start the experiment without firmwares, then send iotlab-node -up <firmware> -l [...] to each group of node separately

Hope it helps,
Matthieu

[miri64]

To work around this and get the behavior your want, I think the only options are:

That's what I did in the end ;-). BTW why not identify the binaries by e.g. a hash in the backend? That's how e.g. Git gets around such problems.

[rienafairefr]

You could ask @cladmi who wrote that part of the system at least 4 years ago about that ;-) But identifying a file by its basename/filename probably seemed like a sensible idea. It makes the experiment JSON description also easier to create/read for us humans (git stores hashes for file changes but what human reads inside the .git directorty on a regular basis ? ;-) )

Good luck with everything 👍

[cladmi]

A solution could be to store a name with a hash or something internally.
Because the server does not care if its called "firmware.elf" or "sha1_firwmare.elf."

I can look into it.

[rienafairefr]

maybe we could use the full relative name (bin/samr21-xpro/tests_gnrc_udp.elf vs bin/arduino-zero/tests_gnrc_udp.elf ) ? these are obviously unique. I'm not sure what / inside multipart data key would do though.

[cladmi]

@fsaintma would know. I think there will be issues now (or be refused by the server) has I think that when exporting an experiment all files are flat in the archive.