"Problem with field requires: wrong" error occurred during the job generation stage

Hi Sam,

Could you please attach the output of udevadm info --export-db?

This is most likely because one of your disks has a strange name with characters that generate an invalid job name.

During testing we found, for example, a disk whose name was "dm-0", and the generated job name would be staging/disk/stats_dm-0, the dash (-) is invalid in a job name, so plainbox is discarding the job.

I think you're right, it looks like there is a dash in its name

OK a simple repro case from trunk is:

- set up and activate a venv
$ plainbox run -i 2013.com.canonical.certification::__disk__
===========================[ Running Selected Jobs ]============================
----------------------------------[ __disk__ ]----------------------------------
ID: 2013.com.canonical.certification::__disk__
(Command output hidden)
ERROR plainbox.ctrl: Ignoring invalid generated job 2013.com.canonical.certification::staging/disk/stats_{name}: Problem with field requires: wrong
Outcome: job passed
==================================[ Results ]===================================
2013.com.canonical.certification::__disk__: pass

I filed bug 1364614 in connection with this.

But *this* bug is because of the following. Notice it happens when running __disk__. This is one of the old local/category jobs:

id: __disk__
plugin: local
_description: Disk tests
command:
  shopt -s extglob
  cat $PLAINBOX_PROVIDER_DATA/../jobs/disk.txt?(.in)

So it's catting jobs/disk.txt, interpreting the content as new job definitions. It processes each one as it sees them, and when processing the template definition, it barfs because the requires: field it sees contains weird stuff (from the resource program compiler's point of view):

requires:
 block_device.{name}_state != 'removable'

the {name} is confusing it. But this only came out because the requires expression makes the interpreter barf; interestingly, if I remove the requirement, it does read it and create a job named, literally, staging/disk/stats_{name}.

So there is something strange about how a template unit is processed if it was read from a local job.

Since these staging/disk* jobs are 100% "new-style" jobs, a possible workaround would be moving it to a file of its own; it will then not appear under __disk__ category, but since that constitutes the old categorization mechanism, we could simply move this job over to the new categorization stuff entirely.

As mentioned, that's only a workaround, a better solution would be figuring out why this is being interpreted badly and fixing that.

One more observation: this problem is not critical, as the staging/disk job is experimental, everything else should work well

I'll see what I can do about this. I have some ideas on how to really make templates work for everything based on what we've learned lately. I'll post some updates to the mailing list