~rodsmith/checkbox/smart-utf-probs

Viewing all changes in revision 4029.1.1.

  • Committer: Zygmunt Krynicki
  • Date: 2015-09-25 08:39:43 UTC
  • mto: This revision was merged to the branch mainline in revision 4031.
  • Revision ID: zygmunt.krynicki@canonical.com-20150925083943-adiuer9vsyd7yu9y
plainbox: add support for multiple resource requirements

This patch essentially allows a requirement program to use more than one
resource. In practice this unlocks a host of capabilities where we can
freely combine manifests, syfs data, udev data and anything else that
makes sense in a given context and turn that into a resource expression.

The primary consumer of this is the TPM provider that has some
non-trivial logic in requirement programs. This logic allows us to
construct a flat lost of jobs to run and thanks to the more complicated
expressions, get them to effectively implement and if-the-else
navigation among jobs so that regardless of what state the TPM hardware
is at the beginning of the test, we can correctly navigate the user
through the testing process.

Technically the ResourceNodeVisitor now collects a list of names as it
traverses the program AST. The MultipleResourcesReferenced exception is
gone entirely. The ResourceExpression class has an API change, as
.resource_id becomes a .resource_id_list. There is a similar change in
_resource_alias_list but this API is private.

There are surprisingly few users of resource_id. Most of the work was in
the controller module (ctrl.py) where we now look at all the resources
to convert them to dependencies. There are a few odd test cases for job
definition units and one utility script that generates .dot diagrams.

The most important note is, that multiple resources should be
discouraged for resource jobs that produce many resource records. The
complexity of evaluating a resource expression over N resources is the
product of the number of resource records in each resource. It's safe to
say that it works best for resource jobs with just one record.

At a later stage we may implement some simple low-hanging optimizations
where resource computation like res.attr == "value" can be converted
from O(N) to O(1) per evaluation at an O(N) one-time cost.

Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>

expand all expand all

Show diffs side-by-side

added added

removed removed

Lines of Context: