Merge lp:~zyga/checkbox/no-resource-limits into lp:checkbox
| Status: | Merged |
|---|---|
| Approved by: | Zygmunt Krynicki on 2015-09-25 |
| Approved revision: | 4030 |
| Merged at revision: | 4031 |
| Proposed branch: | lp:~zyga/checkbox/no-resource-limits |
| Merge into: | lp:checkbox |
| Diff against target: |
615 lines (+174/-153) 7 files modified
plainbox/docs/changelog.rst (+14/-0) plainbox/docs/dev/resources.rst (+31/-42) plainbox/plainbox/impl/commands/inv_special.py (+6/-5) plainbox/plainbox/impl/ctrl.py (+34/-29) plainbox/plainbox/impl/resource.py (+65/-46) plainbox/plainbox/impl/test_resource.py (+22/-22) plainbox/plainbox/impl/unit/test_job.py (+2/-9) |
| To merge this branch: | bzr merge lp:~zyga/checkbox/no-resource-limits |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Sylvain Pineau | 2015-09-24 | Approve on 2015-09-25 | |
|
Review via email:
|
|||
| Sylvain Pineau (sylvain-pineau) wrote : | # |
Attempt to merge into lp:checkbox failed due to conflicts:
text conflict in plainbox/
- 4030. By Zygmunt Krynicki on 2015-09-25
-
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 <email address hidden>


Thanks for the doc update, it really helps understanding what's possible with resources expressions now. I even didn't realized that you could also introduce imported resources, that's even better.
+1