|
|
Post by nschellenberger on May 17, 2023 18:12:26 GMT
As we increasingly flesh out our Redfish support for our hardware, we find ourselves increasingly wondering what the proper/expected/canonical way is to model various relationships. In particular it seems that there is an intended modelling domain notion in Redfish of "physical" (Chassis) v. "logical" (ComputerSystem?). There also seem to be expectations concerning what is represented where and how. To give some concrete examples of the general sorts of questions and responses I'm referring to: For example, today one of our fellows asked me what the expected @odata.id would be for the Chassis/Processors navprop directly in Chassis versus those in a ComputerSystem/Processors racked in that chassis. In answering that, I realised that there is also an older (pre-Fabric) Chassis/Links/Processors link navprop. In general, a lot of entities seem to have a lot of potential "attachment points", many equally plausible--once you discover them.... (I'm assuming that the rackmount would have Chassis/Links/Processors pointing to members of ComputerSystem/Processors and no Chassis/Processors; and that an expansion chassis of GPUs would have no Chassis/Links/Processors but would have Chassis/Processors--somehow also plumbed into Chassis/PCIeDevices and Chassis/PCIeSlots? Again iDRAC and iLO seem to do things differently to one another here as well.) The phrases "we recommend" or "it's recommended" are the sort of guidance we would be grateful to get. Is this wisdom collated somewhere in some single location? Are there documents or specifications that these sorts of things could be inferred from? Apologies in advance if I have missed an obvious resource or if I've posted to the wrong forum. |
|
|
|
Post by jautor on May 23, 2023 20:24:33 GMT
Hi Neil,
I was looking through some of our published materials, especially in the DCIM space (power and cooling gear), to see if there was something good to point to. But I'm not finding much that fully explains (or excuses!) the model...
So you're absolutely correct that resources in the data model generally fall into either the "physical" or the "logical" category - but I have suggested that we use the term "functional" instead of "logical" - because that term is so heavily overloaded in the IT / OS world. And what you also need to understand is that in the Redfish data model, there's going to be a mix of good answers, bad answers (which hopefully are deprecated in the model, but kept in place for backward compatibility), and items that may seem to be duplicate answers - but are intended for different types of gear. And all of that may not be obvious, and certainly not without reading the schema guide-level descriptions and details. And even then, I'm sure there's room for improvement in many places - where it was clear to the authors because we're super close to it - but won't be at all obvious to anyone else... Any feedback to improve any of that is welcomed and encouraged!
And so I think we need to add some guidance and history, probably to the "Redfish Data Model Specification" so it's in a place that folks will find it, regarding the physical/functional views in the data model. But let me give a start of that...
We modeled the physical view mostly through the `Chassis` resource. Where a Chassis is roughly a sheet metal box. And our recent guidance has been that every physical thing must be "Contained" by a Chassis. That can be assumed for resources subordinate to a Chassis resource, or can be called out by a Link called `ContainedBy` that points to the physical Chassis. For things bigger than a rack, such as a room or a building, we made the `Facility` resource. And we jokingly say that's just a Chassis made out of drywall or concrete instead of sheet metal...
Everything else in the model is a "Functional" resource - which in the general-purpose computer /server space means any resources visible from the operating system. Now, you'll see items like Processor and Memory which represent both - and we did that to avoid a lot of duplicate resources (one for the physical DIMM, another for the 128GB of RAM it surfaces to the OS). And that same resource can also represent an empty slot (an Absent resource in our terminology) so we don't have to model that as yet another resource.
And so in those functional resources, you'll see links to a Chassis to show that physical containment. Or again, it can be assumed for subordinate resources (there's a Chassis link for Memory, but not in MemoryMetrics, for example). And in Chassis, you'll see links to all the potential functions that could exist (and be contained within). And while that list of links continues to grow - we wanted to give explicit links for each schema type - so that a client didn't have to chase down every resource just to determine which ones were relevant.
Over time, we've tried to make this more consistent, as folks have also become more comfortable with a few additional "overhead" resources (a simple Chassis that contains one function like a PDU) in exchange for a very consistent model to determine physical containment, location, etc.
So that's a start, I've brought up the topic and I'll be proposing some text like the above to add to the educational materials. Because it's important for both implementers and users to understand how the model is supposed to work!
Jeff
|
|
|
|
Post by nschellenberger on May 26, 2023 21:17:36 GMT
Thank you very much jautor for being so generous with your time in your response! It may be helpful even to have some "low level" guidance/rationale spelled out on the various modelling objects e.g. in LongDescription (which would then naturally help populate the various docs generated from those). Some of that is already done in places (thank you!) but there is always more that could be done, even just incrementally. TL;DR Advice welcomed on what the canonical URI ought to be for each entity; and what Links to where in the entity graphs. As always, we can make choices for ourselves and muddle on, but it would be handy to know if we're "doing it wrong".... In our case, we have various bits and pieces that are used to perform compositions, which we want to model/manipulate using a CompositionService in a top level orchestrator Redfish service. We envision that it would also need (?) to have an AggregationService to aggregate expandable ComputerSystems and the various expansion Chassis. These ComputerSystems and Chassis contain bespoke FabricAdapters providing a Fabric providing the physical access to composable PCIe devices present on the Chassis PCIe backplanes. (For the moment compute/processors, but ultimately including storage.) We also need to surface the PCIeSlots and PCIeDevices/PCIeFunctions for the composable resources in the Chassis and the fixed ones in the ComputerSystems. For added complexity, the ComputerSystems and Chassis also have BMCs which it would be nice to be able to surface, at least as remote managers. From the composition examples/mocks e.g. Composable System etc. it seems that the intended modelling of navprops and links for the Redfish service running on e.g. an expansion enclosure is to have: - Chassis (physical) for the physical enclosure
- Links/Contains to the sub-"Chassis", as below
- Links/ComputerSystems to current composition(s) (?)
- Links/ManagedBy etc. ref to this service? Or the BMC? Both?
- PCIeSlots presumably must be here? But does that then imply PCIeDevices must be canonical (or at least aliased) here?
- Our FabricAdapter (which is not, itself, a composable resource, but is managed by this Redfish service)
- PCIeDevices for the physical compute/processor resources? Or do these go at the Chassis level? If so, which Chassis, enclosure or logical (see next)?
- Sub-"Chassis" (less physical
 ) for each independently composable (?) ResourceBlock acting as a sort of "resource handle(?)"- These Chassis have minimal properties themselves e.g. no Processors, PCIeDevice, PCIeSlots etc.
- Links/ContainedBy to the Chassis
- Links/ManagedBy to self? Or BMC?
- When would one use just one "abstract resource handle" Chassis with multiple ResourceBlocks instead? Is there a rule-of-thumb?
- ResourceBlocks (really quite abstract) in the ServiceRoot with appropriate composable resource(s)
- What principle governs when a ResourceBlock has more than one ref in e.g. its Collection(Processor) vs many? Just whether the resources being modelled are independently composable or not? Or is there a more subtle distinction here?
- Typically we've used the rule-of-thumb that a ContainsTarget or, less formally and context dependent, a ResourceCollection represents the canonical location in the graph (i.e. the odata.id and URI) for an entity instance. Here we have neither but the Redfish.Uris implies that there are endpoints (possibly alias redirects? but to where in the graph?) to e.g. /redfish/v1/CompositionService/ResourceBlocks/{ResourceBlockId}/Processors/{ProcessorId}.
- The mocks seem to imply that these are the canonical locations for Processors etc. and that they appear nowhere else in the graph.
Similar(-ish) for each Redfish services representing each of the physical, expandable ComputerSystems. Our top level orchestrator runs an AggregationService (bringing together all of the Chassis and ComputerSystems) and a CompositionService. - Chassis (physical) proxied for every physical expansion enclosure O(10**3)
- Links/Contains to the aggregated/proxied sub-Chassis, as below
- Links/ComputerSystems to the aggregated/proxied ServiceRoot/Systems representing the expandable physical ComputerSystems
- Chassis for all the various "resource handles" O(10**4)
- CompositionService/ResourceBlocks O(10**4)
- For all of the many aggregated ResourceBlocks from Chassis
- For all of the "virtual" expandable ComputerSystems
- Similar questions to the above concerning canonical location; aliases; Links etc. but now with proxying/rewriting also to consider....
|
|
) for each independently composable (?) ResourceBlock acting as a sort of "resource handle(?)"