|
|
Post by dmitry on Feb 20, 2020 6:43:39 GMT
Hi Everyone,
The Redfish specification applies definition that a resource collection is a set of resources that share the same schema definition.
The way it is formulated leaves me with the following three interpretations:
1. All members in a collection must be of the same type which is based on the collection element type.
- collection(sensor.sensor) consisting only from sensor.v1_0_0.sensor resources (based on sensor.sensor) is valid
- collection(sensor.sensor) consisting from sensor.v1_0_0.sensor resource and other resources (based on sensor.sensor) is invalid
2. All members in a collection must be of types based on the collection element type and must be defined in the same schema (namespace).
- collection(sensor.sensor) consisting of mysensor.v1_0_0.discretesensor (based on sensor.sensor) and mysensor.v1_0_0.numericsensor (based on sensor.sensor) is valid
- collection(sensor.sensor) consisting of mysensor.v1_0_0.discretesensor (based on sensor.sensor) and mysensor.v1_1_0.numericsensor (based on sensor.sensor) is invalid
3. All members in a collection must be of types based on the collection element type and can be defined in different schemas (namespaces).
- collection(sensor.sensor) consisting of mysensor.v1_0_0.discretesensor (based on sensor.sensor) and mysensor.v1_1_0.numericsensor (based on sensor.sensor) is valid
Could someone elaborate how to perceive the definition?
Thanks,
Dmitry
|
|
|
|
Post by jautor on Feb 21, 2020 23:13:37 GMT
The "namespace" vs. "schema" is a construct that came from the adoption of OData and the CSDL schema language. It's used for providing versioning information about each schema, but not for multiple definitions. There is exactly one "resource type" per schema file, even though there are numerous namespaces (for versions and for some shared object definitions).
A Resource Collection can contain any number of compatible resource versions, but no other resource types.
- You could see a collection of "Sensor", containing "Sensor.v1_0_0", "Sensor.v1.3.0", and "Sensor.v1.8.2". But it could not contain a "Chassis.v1_3_0".
So your #1 is correct. But #2 can't happen because Redfish would not create different resource definitions within a schema. If we create a DiscreteSensor, it would get it's own schema file and definition, not be something that would be included in the Sensor_v1.xml schema file.
And your #3 is partially correct in that a Resource Collection can contain different versions of a schema, but again, your example has two different resource definitions coming from a single schema file which would not occur in Redfish.
We should add some variation of versions in some of our public mockups so there's an example of this...
Jeff
|
|
|
|
Post by dmitry on Mar 25, 2020 12:52:41 GMT
Thanks for clarifications.
Though I assume I have an answer, but I would like to make it crystal clear for me ))
Please, consider an example:
I defined a new resource type "DiscreteSensor" in a corresponding schema DiscreteSensor_v1.xml.
The abstract base DisceteSensor resource inherits (has its base type) from a "Sensor.Sensor" resource type defined in Sensor_v1.xml.
Is it viable to place DiscreteSensor resources as members of a SensorCollection resource collection?
From the previous answer I could assume it is not, but an authorized confirmation would be very much appreciated.
Thanks in advance,
Dmitry
|
|
|
|
Post by jautor on Mar 25, 2020 16:04:16 GMT
Short answer is, as you expected, no, that would not be allowed. All members of a resource collection must use the same schema.
We don't use inheritance in the Redfish models to avoid the model complexity that it creates. In cases where we've found a reason to "extend" a schema definition for another purpose, we copy the definitions into a new schema. We call this "inheritance by copy" - and yes, it creates work for the schema writer to maintain them and keep them in sync if that is desired - but that's our job.
You can also use the OEM section within a resource to extend a schema to cover something unique to your product or design, while still fitting into existing models for the majority of the data.
Also, since you used "DiscreteSensor" as an example - if there's something missing in the "Sensor" model that could be added to cover your case, please provide that feedback! We didn't describe a discrete sensor in the model (yet), because we didn't have a use case for one. That does not mean that there are no discrete sensors in Redfish. Instead, using the Redfish design tenets, we would much rather define a property to show the actual "purpose" of that discrete sensor value. For example, a "door sensor" would be rendered instead as "DoorStatus": "Open" or "Closed", not as a generic discrete sensor with an "active" or "inactive" value.
Jeff
|
|
|
|
Post by dmitry on Mar 26, 2020 5:38:15 GMT
Thanks for the confirmation, Jeff.
The Redfish design tenets are well understood, but it seems, at least from the sensor perspective, they are too restrictive for fast prototyping.
We want to adapt Redfish as a management interface for devices where SAF HPI or IPMI was previously employed, and bound to a problem of mapping a variety of sensors and controls into the schema. As I mentioned before, we want to expose several discrete sensors types, but maintaining them in the Sensors collection seems inappropriate because the Sensor resource is targeted on exposing a numeric sensor. I think I wouldn't be wrong if I guess that some other companies break their heads on this problem too.
Ultimately, according to the Redfish design tenets, all new sensors/controls will be somehow wrapped up by some new meaningful resources. But there always be a need for supporting new kinds of sensors or controls in a timely manner, and preferably in a standardized one.
And I'm just trying to figure out whether it is worth adding standard Redfish schemas for a collection of raw sensors and raw controls for quick system prototyping.
Such, I assume two collections of raw sensors and raw controls within a Chassis which will contain resources with some shared schema and path, but with specifics defined in Oem property.
--Dmitry
|
|
|
|
Post by jautor on Apr 1, 2020 15:15:29 GMT
Ultimately, according to the Redfish design tenets, all new sensors/controls will be somehow wrapped up by some new meaningful resources. But there always be a need for supporting new kinds of sensors or controls in a timely manner, and preferably in a standardized one. Yes, certainly - and we've very much streamlined the process for getting new items defined and added to the standard. The specification process timeline is very likely shorter than your test and release cycles. Well, for prototyping do whatever makes sense to figure out the best design pattern for anything new. But strongly encourage you to provide that feedback and input to the Redfish Forum so that anything applicable to the industry can be added to the standard. If you have any examples you can share here, that would be helpful, too. Jeff |
|
