|
|
Post by malbolge on Sept 18, 2023 15:34:11 GMT
RDE provides a well-defined way for an RDE device to implant it's Resources into an external device's Redfish Service's hierarchy. Paraphrasing, the RDE device says "I have a NetworkAdapter - I'll handle requests to read/write it, I'll parse the headers, I'll provide events error annotations and whatnot, you just generate an ID for it, put it somewhere in your model where it makes sense and whenever someone asks for it, forward this request to me" - and the Redfish service obliges, resulting in one Redfish service (though RDE) dispatching Redfish requests to be handled by the correct device.
What if I want the exact same thing, but my device isn't RDE, but a fully-fledged Redfish service, with it's own HTTPS, it's own auth and all? Is there a way to tell a master Redfish service to grab Resources from a slave Redfish service and integrate them the same way RDE does?
|
|
|
|
Post by mraineri on Sept 18, 2023 15:53:24 GMT
Yes, that would be done via the AggregationService model. An "aggregator" can collect information from other services and assemble them all into a singular service. Users can add new AggregationSource resources to specify the target systems to pull into the aggregator's view of the world.
I wouldn't expect this to necessarily be done by a BMC in a single system, but rather would be part of a software solution to give a single pane of glass management experience to its users, perhaps running as a service on an existing server.
|
|
|
|
Post by malbolge on Sept 18, 2023 16:08:25 GMT
I wouldn't expect this to necessarily be done by a BMC in a single system, but rather would be part of a software solution to give a single pane of glass management experience to its users, perhaps running as a service on an existing server. I'm guessing this is because the RDE-equivalent specification of how precisely this aggregation is to happen, is not covered by Redfish? So if a BMC were to perform this kind of aggregation, it would be fully proprietary, with Redfish providing the Model, but not how to perform the aggregation? Otherwise, the intended use-case for AggregationService is for a pure software application with no (physical) Resources of it's own to talk to several BMCs? If I understand correctly, this would mean odata links would be expanded to absolute links containing IPs of the individual machines - or would the "supervisor" software application function as a HTTPS proxy? |
|
|
|
Post by mraineri on Sept 18, 2023 16:14:17 GMT
There is an "Aggregation" clause that outlines common expectations, but beyond that you're right, it's entirely implementation specific. In this type of configuration, I would expect this to be software-driven and not one for one equivalent to the RDE world.
Some aggregators may simply be a passthrough window and give direct, absolute links to resources downstream. Some may hide this internally and act as a proxy layer. Some will likely cache the downstream model and insert copies into its own view, and thus have relative links that all map to its cached data. Others might be more intelligent and insert/remove properties of interest that might not be well managed on the downstream device.
|
|
|
|
Post by malbolge on Sept 18, 2023 16:25:04 GMT
With device complexity going up (making it progressively more difficult for a BMC to manage a Redfish representation of a device) and compute costs going down (making it more feasible to run HTTP+JSON on a peripheral) it appears to me that Redfish2Redfish aggregation is a looming alternative to RDE2Redfish aggregation. Are there any proposals/discussions on this topic?
|
|
|
|
Post by mraineri on Sept 18, 2023 19:24:16 GMT
Like with RDE, Redfish defines the client-service interactions and the data model that goes over the interface. How it's utilized in this type of scenario seems like more of a design decision when trying to create a product versus something we need to enforce in a specification, and no one has requested filling certain gaps for this usage. Perhaps there might be functionality missing that would be needed to make this work, and if you have specific cases in mind, we can certainly hear them and see if they're worth standardizing.
|
|
|
|
Post by malbolge on Sept 19, 2023 12:15:21 GMT
The use-case is an alternative to RDE for network controllers, where composition is done on the level of Redfish2Redfish, rather than RDE2Redfish - for use with Redfish services (BMCs) which for one reason or another don't want to use RDE but still want the benefits of Redfish-based manageability - including a single access point / pane of glass management interface that encompasses the whole machine.
It may be a rather narrow use-case, since it only applies to network cards. A redfish server wouldn't do much good on a RAID controller, it has no easy way to expose itself to the outside world. (Although something like peer2peer NCSI PT over MCTP could alleviate this)
Obviously a NIC can expose a tiny self-contained Redfish server and pretend it's a standalone ComputerSystem with a NetworkAdapter in vacuum. That technically still allows the user to interact with the NIC via Redfish - but I feel this goes against the intuitive expectation of having all Redfish capabilities in a single model - and inconsistent with physical reality, where such a NIC would in fact be a slave device in some server that already has a Redfish model exposed through the BMC.
|
|
|
|
Post by mraineri on Sept 19, 2023 13:03:46 GMT
That still sounds like a design pattern you might consider when integrating a card like that into a system rather than something we need to define in the specification. Is there something specifically about the specification as it stands today that is preventing this type of implementation?
|
|
|
|
Post by malbolge on Sept 22, 2023 14:50:05 GMT
After some research, nothing is preventing it, but there's nothing facilitating the kind of seamless plug&play experience you get with RDE either.
I understand that DSP0218 explicitly set out to solve the problem of Redfish model integration that the Redfish model itself never intended to solve - rather, integration of separate Redfish services is left for something like openstack/ironic to put together.
To summarize - aggregation of separate Redfish services (ie. Redfish BMC + Redfish NIC) is out of scope of DMTF, no standardized solution is planned and if integration is desired, the customer has to DIY a solution using 3rd party tools. Whether that's feasible depends on how large the deployment is.
|
|
