Comment 5 for bug 1361071

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.