Add ContainedByChassis to inventory catalog

[dchanman]

The motivation for this is part of DMTF/Redfish-Use-Case-Checkers#62, where we'd like to create a usecase checker for assigning location-based identifiers for replaceable components in a system.

The motivation for that Usecase Checker is to help codify the Google repair identifier requirements documented in https://github.com/google/ecclesia-machine-management/blob/master/ecclesia/lib/redfish/g3doc/topology.md

The Google usage requirement depends on using label to provide an identifier relative to a less ambiguous FRU in the system. The RelativeRepairableUnitUri identifies such a less ambiguous FRU.

The current standard does not narrowly define ServiceLabel, leading to usage proposals where physical hierarchy is embedded into the ServiceLabel itself: e.g. https://github.com/DMTF/Redfish/issues/5172. The overall motivation for https://github.com/google/ecclesia-machine-management/blob/master/ecclesia/lib/redfish/g3doc/topology.md is to provide an interoperable proposal to represent such desired hierarchies.

Signed-off-by: Derek Chan [email protected]

[mraineri]

One thing that occurred to me is that the structure of the inventory is all in the context of an array of objects, where each object represents a chassis instance, which contains an array of objects per component class. I think we already have the mapping you're suggesting as part of the general structure of the inventory.

So, if we use the simple rack mounted server mockup as an example, it should produce a structure like this:

[
    {
        "ChassisName": "1U",    <--- This equates to /redfish/v1/Chassis/1U
        "Chassis": [],
        "Processors": [
            { <CPU1 info> },
            { <CPU2 info> }
            { <FPGA1 info> }
        ],
        "Memory": [
            { <DIMM1 info> },
            { <DIMM2 info> },
            { <DIMM3 info> },
            { <DIMM4 info> }
        ],
        <Other device classes>
    }
]

[dchanman]

Thanks Mike,

I'm wondering if the structure you are describing would extend to Chassis hierarchies to simpli

For example, for a hypothetical system with multiple identical compute risers:

[
    {
        "ChassisName": "Tray",
        "Chassis": ["Backplane 1", "Backplane 2"],  <- will we have these populated?
    },
    {
        "ChassisName": "Backplane 1",
        "Chassis": ["Module 1", "Module 3"],
    },
    {
        "ChassisName": "Backplane 2",
        "Chassis": ["Module 2", "Module 4"],
    },
    {
        "ChassisName": "Module 1",
        "Processors": [...],
        "Memory": [...],
    },
    {
        "ChassisName": "Module 2",
        "Processors": [...],
        "Memory": [...],
    },
    {
        "ChassisName": "Module 3",
        "Processors": [...],
        "Memory": [...],
    },
    {
        "ChassisName": "Module 4",
        "Processors": [...],
        "Memory": [...],
    }
]

Assuming we have the above, part of the motivation for this CL is also to make it easier to look up the relationship in the opposite direction. We seem to be able to look up child Chassis, but aren't easily looking up parent Chassis.

[mraineri]

Discussion 8/5: From the proposed usage, since all of the device objects are already assigned in a chassis object, all we need is to add the contains/containedby relationship in each of the chassis objects.

[mraineri]

I think we can move these new items up to line 60, and simply look at Contains/ContainedBy when building the outer chassis object. A component within a chassis should be placed in the right chassis object, which means you shouldn't need to track the containment path at the component level.

[dchanman]

Need to work on this some more.

[mraineri]

11/18: Derek still needs to get back to testing this; will follow-up later.

[dchanman]

Internally at Google we've been investigating a different way of fetching the equivalent ContainedByChassis information using other properties within Location; I don't think this pull is relevant any longer.