Merge lp:~jtv/maas/boot-image-dict into lp:~maas-committers/maas/trunk
Status: | Merged |
---|---|
Approved by: | Jeroen T. Vermeulen |
Approved revision: | no longer in the source branch. |
Merged at revision: | 2237 |
Proposed branch: | lp:~jtv/maas/boot-image-dict |
Merge into: | lp:~maas-committers/maas/trunk |
Diff against target: |
411 lines (+178/-110) 2 files modified
src/provisioningserver/import_images/boot_resources.py (+98/-74) src/provisioningserver/import_images/tests/test_boot_resources.py (+80/-36) |
To merge this branch: | bzr merge lp:~jtv/maas/boot-image-dict |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Graham Binns (community) | Approve | ||
Review via email: mp+214210@code.launchpad.net |
Commit message
Turn the “hierarchical dicts” in the new import code into a proper class, BootImageDict.
Description of the change
The import code is a bewildering constellation of dict-based data structures. In order to be able to test, maintain, and debug this code, we need a bit more structure. This came up in my ongoing attempt to write unit tests for the new code.
Much of the dict-ey code is about dicts that index by architecture, subarchitecture, release, and label. Another, very similar kind of dict uses the same constructor but contains something else. I'm prying the two apart, turning that first kind into a class with limited methods, so we have a clear idea of what does and doesn't happen to its contents. In the process I'm conquering the fear of hidden interactions with Simplestreams code.
One thing the encapsulation allowed me to do is to simplify the dict's structure. It now maps ImageSpec, a tuple type, to boot resource — another kind of dict that I'd like to turn into a class. And boot_reverse turns a BootImageDict inside out to return that other kind of dict that uses the same constructor. You guessed it: that too I would like to turn into a class.
The one complication was in dumping the dict to JSON: you can't have tuples as keys in a JSON object. Moreover, you can't just change the format of the maas.meta file, which is where the JSON goes, because we have no idea what its purpose is or where it is used. And so inside the new dump_json method, I do convert back to the old format. This turns out to be a lot easier than continually managing the full deeply-nested structure, as I did in an earlier stage in the evolution of this branch.
The testing for dump_json overlaps with test code that I previously added to the end-to-end test. I can probably take that back out again now, in favour of the new unit test. But I wanted to have a solid anchor for the refactoring, so that I didn't accidentally change the format.
Jeroen
This is great work; thanks Jeroen. A couple of quibbles:
[1]
19 +class BootImageDict:
20 + """Mapping of boot-image data.
21 +
22 + Maps `ImageSpec` tuples to metadata for Simplestreams products.
23 +
24 + This class is deliberately a bit more restrictive and less ad-hoc than a
25 + dict. It helps keep a clear view of the data structures in this module.
You've said that it's "a bit more restrictive and less ad-hoc than a
dict" but it's still called a BootImageDict and it implements items(),
which makes it look a bit like it *might* be a dict. But if you try to
use it like a dict, it'll go boom:
>>> from provisioningser ver.import_ images. boot_resources import BootImageDict
>>> image_dict = BootImageDict()
>>> image_dict['spam'] = 'eggs'
TypeError: 'BootImageDict' object does not support item assignment
If it's not going to behave like a dict we shouldn't call it a dict. If
it's meant to behave like a dict it should at least implement the
requisite methods, or raise a sensible error when those methods are
called on it (as shouldn't happen).
[2]
86 + """Complement `BootImageDict` with entries from another.
Missing "one" after "Complement".