Parsing manifests: URNs and hardware types
I'm parsing manifests (using the Manifest class from geni-lib/geni/rspec/pgmanifest.py
) from the history table, apt_instance_aggregate_history. My conversation with @johnsond suggests that there are some strange cases that might need additional attention & investigation.
-
I'm currently looking at the experiments that were created on or after Dec 1, 2017. In over 15K such experiments, there are 1593 nodes for which component_ids appear to be missing (component_id attributes for nodes inside the Manifest objects are set to None). uuid="cd37032b-5f8d-11e8-b228-90e2ba22fee4" is a recent 10-node experiment (created: 2018-05-24 14:05:35) with such behavior. Some of the node elements in the corresponding manifest do not have component_id attributes. In the corresponding rspec, we found no site attributes; there are some component_manager_id attributes, and it looks like they want to use different hardware types from several sites. Perhaps, this is not a bug, but a rare use case; we would like to know how to interpret this type of cases and how to best process them in order to extract the URNs.
-
uuid="24ea79fd-1205-11e8-b223-90e2ba22fee4" is an example of another strange case. The manifest for it includes both
<hardware_type name="c220g1"/>
and<emulab:vnode name="c220g2-011013" hardware_type="c220g2"/>
for each of the two nodes. Considering this mismatch between c220g1 and c220g2, should one of the tags always be used instead of the other in determining the node's hardware type? Does it look like a bug? There are similar cases where the confusion is between "pc3000" and "pc", "pc" and "d710", etc. -
uuid="cde69e44-1352-11e8-b223-90e2ba22fee4" is one of 86 experiments where a manifest includes a custom namespace (called "rs"). In these cases, hardware_type attributes shows up inside the
rs:vnode
element instead ofemulab:vnode
used in all other manifests. Is it worth it to take a closer look at such manifests or should I plan to handle them as an exception and simply look insiders:vnode
if it is present?
@johnsond Am I missing anything from our conversations in this summary?
The goal of this parsing is to reliably extract hardware types of all nodes in the past experiments (and match the usage data against the reservation data).