|
|
Post by zzzzs on Feb 28, 2022 9:19:44 GMT
Hi all, I have a question why Redfish-Service-Validator tool fails to validate Oem, namespace OemManager has node OpenBmc in OemManager_v1.xml. Thanks for any clarification! <edmx:DataServices> <Schema xmlns="http://docs.oasis-open.org/odata/ns/edm" Namespace="OemManager"> <ComplexType Name="Oem" BaseType="Resource.OemObject"> <Annotation Term="OData.AdditionalProperties" Bool="true" /> <Annotation Term="OData.Description" String="OemManager Oem properties." /> <Annotation Term="OData.AutoExpand"/> <Property Name="Customization" Type="OemManager.Customization"/> <Property Name="Manufacturing" Type="OemManager.Manufacturing"/> <Property Name="OpenBMC" Type="OemManager.OpenBMC"/> <Property Name="OpenBmc" Type="OemManager.OpenBmc"/> </ComplexType> Oem.OpenBMC [JSON Object] OemManager.OpenBMC Yes complex Oem.OpenBMC.FirmwareBuildTime 20220228155159 string Yes PASS Oem.OpenBmc [JSON Object] none Yes FAIL ERROR - Type OpenBmc not found under namespace OemManager in schema of parent ERROR - VirtualMedia: GET of resource at URI /redfish/v1/Managers/bmc/VirtualMedia returned HTTP 403. Check URI. ERROR - Oem.OpenBmc: This type is invalid none "Oem": { "@odata.id": "/redfish/v1/Managers/bmc#/Oem", "@odata.type": "#OemManager.Oem", "OpenBmc": { "@odata.id": "/redfish/v1/Managers/bmc#/Oem/OpenBmc", "@odata.type": "#OemManager.OpenBmc", "Certificates": { "@odata.id": "/redfish/v1/Managers/bmc/Truststore/Certificates" }, "Fan": { "@odata.id": "/redfish/v1/Managers/bmc#/Oem/OpenBmc/Fan", "@odata.type": "#OemManager.Fan", |
|
|
|
Post by mraineri on Feb 28, 2022 13:57:49 GMT
There are some things not syntactically correct with how the OEM property is constructed, so the validator isn't able to map the payload with the schema file. I've added line numbers to make it easier to follow.
1 <edmx:DataServices>
2 <Schema xmlns="http://docs.oasis-open.org/odata/ns/edm" Namespace="OemManager">
3 <ComplexType Name="Oem" BaseType="Resource.OemObject">
4 <Annotation Term="OData.AdditionalProperties" Bool="true" />
5 <Annotation Term="OData.Description" String="OemManager Oem properties." />
6 <Annotation Term="OData.AutoExpand"/>
7 <Property Name="Customization" Type="OemManager.Customization"/>
8 <Property Name="Manufacturing" Type="OemManager.Manufacturing"/>
9 <Property Name="OpenBMC" Type="OemManager.OpenBMC"/>
10 <Property Name="OpenBmc" Type="OemManager.OpenBmc"/>
11 </ComplexType>
12
13 "Oem": {
14 "@odata.id": "/redfish/v1/Managers/bmc#/Oem",
15 "@odata.type": "#OemManager.Oem",
16 "OpenBmc": {
17 "@odata.id": "/redfish/v1/Managers/bmc#/Oem/OpenBmc",
18 "@odata.type": "#OemManager.OpenBmc",
19 "Certificates": {
20 "@odata.id": "/redfish/v1/Managers/bmc/Truststore/Certificates"
21 },
22 "Fan": {
23 "@odata.id": "/redfish/v1/Managers/bmc#/Oem/OpenBmc/Fan",
24 "@odata.type": "#OemManager.Fan",
On line 3, "Name" should be "OpenBmc", and "BaseType" should be removed. "Oem" is already defined in Redfish and OEM extensions just need the object nested within "Oem" to be defined. There also does not need to be a base type since this is a starting point for your OEM extension. Changing the name to "OpenBmc" will allow the tool to resolve the @odata.type reference at line 18.
Line 6 should be deleted; the "AutoExpand" term only applies to NavigationProperty instances where the referenced URI is to be expanded. A ComplexType is simply a JSON object. This shouldn't impact the service validator since it's not going to care about these types of nits, but it would be good to delete it to avoid possible issues with other tools that might consume CSDL.
Line 15 should be deleted. "Oem" (the outer most construct of the OEM extensions object) is already defined to be a flexible container for OEM extensions. What happens here is you're overriding the DMTF definition with your own.
There is an example mockup with schema that might be worth looking over as well. In the DSP2043 bundle (https://www.dmtf.org/sites/default/files/standards/documents/DSP2043_2021.4.zip), there's a "public-oem-examples" folder where ServiceRoot and AccountService have small OEM extensions. The folder "Contoso.com" has the CSDL for those extensions (ContosoAccountService_v1.xml and ContosoServiceRoot_v1.xml). It's also worth noting the naming conventions; for the OEM extensions; the file names (and namespaces) have company identifiers to avoid potential naming collisions with other organizations. The naming style won't result in issues with the service validator, but it's a good practice to follow.
|
|
|
|
Post by zzzzs on Mar 1, 2022 3:38:41 GMT
Thanks for your advice.
|
|
|
|
Post by zzzzs on Mar 1, 2022 8:31:29 GMT
There are some things not syntactically correct with how the OEM property is constructed, so the validator isn't able to map the payload with the schema file. I've added line numbers to make it easier to follow.
1 <edmx:DataServices>
2 <Schema xmlns="http://docs.oasis-open.org/odata/ns/edm" Namespace="OemManager">
3 <ComplexType Name="Oem" BaseType="Resource.OemObject">
4 <Annotation Term="OData.AdditionalProperties" Bool="true" />
5 <Annotation Term="OData.Description" String="OemManager Oem properties." />
6 <Annotation Term="OData.AutoExpand"/>
7 <Property Name="Customization" Type="OemManager.Customization"/>
8 <Property Name="Manufacturing" Type="OemManager.Manufacturing"/>
9 <Property Name="OpenBMC" Type="OemManager.OpenBMC"/>
10 <Property Name="OpenBmc" Type="OemManager.OpenBmc"/>
11 </ComplexType>
12
13 "Oem": {
14 "@odata.id": "/redfish/v1/Managers/bmc#/Oem",
15 "@odata.type": "#OemManager.Oem",
16 "OpenBmc": {
17 "@odata.id": "/redfish/v1/Managers/bmc#/Oem/OpenBmc",
18 "@odata.type": "#OemManager.OpenBmc",
19 "Certificates": {
20 "@odata.id": "/redfish/v1/Managers/bmc/Truststore/Certificates"
21 },
22 "Fan": {
23 "@odata.id": "/redfish/v1/Managers/bmc#/Oem/OpenBmc/Fan",
24 "@odata.type": "#OemManager.Fan",
On line 3, "Name" should be "OpenBmc", and "BaseType" should be removed. "Oem" is already defined in Redfish and OEM extensions just need the object nested within "Oem" to be defined. There also does not need to be a base type since this is a starting point for your OEM extension. Changing the name to "OpenBmc" will allow the tool to resolve the @odata.type reference at line 18.
Line 6 should be deleted; the "AutoExpand" term only applies to NavigationProperty instances where the referenced URI is to be expanded. A ComplexType is simply a JSON object. This shouldn't impact the service validator since it's not going to care about these types of nits, but it would be good to delete it to avoid possible issues with other tools that might consume CSDL.
Line 15 should be deleted. "Oem" (the outer most construct of the OEM extensions object) is already defined to be a flexible container for OEM extensions. What happens here is you're overriding the DMTF definition with your own. There is an example mockup with schema that might be worth looking over as well. In the DSP2043 bundle (https://www.dmtf.org/sites/default/files/standards/documents/DSP2043_2021.4.zip), there's a "public-oem-examples" folder where ServiceRoot and AccountService have small OEM extensions. The folder "Contoso.com" has the CSDL for those extensions (ContosoAccountService_v1.xml and ContosoServiceRoot_v1.xml). It's also worth noting the naming conventions; for the OEM extensions; the file names (and namespaces) have company identifiers to avoid potential naming collisions with other organizations. The naming style won't result in issues with the service validator, but it's a good practice to follow.
Is it valid? Should I merge "Manufacturing", "OpenBMC", "Customization" into "OpenBmc" or "Contoso"? "Oem": { "@odata.id": "/redfish/v1/Managers/bmc#/Oem", "Customization": { "@odata.id": "/redfish/v1/Managers/bmc/Oem/Customization", "@odata.type": "#OemManager.Customization" }, "Manufacturing": { "@odata.type": "#OemManager.Manufacturing" }, "OpenBMC": { "@odata.id": "/redfish/v1/Managers/bmc/Oem/OpenBMC", "@odata.type": "#OemManager.OpenBMC", }, "OpenBmc": { "@odata.id": "/redfish/v1/Managers/bmc#/Oem/OpenBmc", "@odata.type": "#OemManager.v1_0_0.OpenBmc", "Certificates": { "@odata.id": "/redfish/v1/Managers/bmc/Truststore/Certificates" }, "Fan": { "@odata.id": "/redfish/v1/Managers/bmc#/Oem/OpenBmc/Fan", } } } }, |
|
|
|
Post by mraineri on Mar 1, 2022 13:53:31 GMT
It depends on your intent. If these are all considered "OpenBMC OEM extensions", then I would put them all inside of the "OpenBMC" object. For example:
"Oem": {
"OpenBMC": {
"@odata.type": "#OemManager.v1_0_0.OpenBmc",
"Customization": { ... },
"Manufacturing": { ... },
"Certificates": { ... },
"Fans": { ... },
...
}
},
If your intent is to create different OEM extensions for different organizations to isolate the extensions (and maybe enable/disable them at certain points), then it might make more sense to make it their own OEM objects. However, I would avoid general names like "Manufacturing"; you should still have something about "OpenBMC" in the name. There is some guidance for this in the "OEM-specified object naming" clause of the Redfish Spec. For example:
"Oem": {
"OpenBMC_Customization": {
"@odata.type": "#OemManager.v1_0_0.Customization"
},
"OpenBMC_Manufacturing": {
"@odata.type": "#OemManager.v1_0_0.Manufacturing"
},
"OpenBMC": {
"@odata.type": "#OemManager.v1_0_0.OpenBmc",
"Certificates": { ... },
"Fans": { ... },
...
}
},
|
|
|
|
Post by zzzzs on Mar 3, 2022 11:16:19 GMT
Sorry for wasting your time, I want do like this, but the tool still fails to verify. "Oem": { "OpenBMC_Customization": { "@odata.type": "#OemManager.v1_0_0.Customization" }, "OpenBMC_Manufacturing": { "@odata.type": "#OemManager.v1_0_0.Manufacturing" }, "OpenBMC": { "@odata.type": "#OemManager.v1_0_0.OpenBmc", "Certificates": { ... }, "Fans": { ... }, ... } }, Oem [JSON Object] Resource.Oem Yes complex Oem.OpenBmc [JSON Object] Resource.OemObject Yes FAIL Oem.OpenBmc_Customization [JSON Object] Resource.OemObject Yes FAIL Oem.OpenBmc_Manufacturing [JSON Object] Resource.OemObject Yes FAIL ERROR - getResourceObject: Namespace appears nonexistent in SchemaXML: #OemManager.v1_0_0.OpenBmc /redfish/v1/$metadata#Resource.Oem ERROR - getResourceObject: Namespace appears nonexistent in SchemaXML: #OemManager.v1_0_0.Customization /redfish/v1/$metadata#Resource.Oem ERROR - getResourceObject: Namespace appears nonexistent in SchemaXML: #OemManager.v1_0_0.Manufacturing /redfish/v1/$metadata#Resource.Oem This Oem extension is in /redfish/v1/Managers/bmc. OemManager.xml references the Manger namespace, why nonexistent in SchemaXML Attachments:OemManager_v1.xml (23.22 KB)
Manager_v1.xml (87.71 KB)
|
|
|
|
Post by mraineri on Mar 3, 2022 13:53:03 GMT
There are a few things that need addressing.
In OemManager_v1.xml, lines 24, 33, and 38 have an early tag termination, which is resulting in invalid XML. For example:
<ComplexType Name="OpenBmc_Manufacturing"/>
<Annotation Term="OData.AdditionalProperties" Bool="False" />
<Annotation Term="OData.Description" String="Oem properties for Manufacturing." />
should be:
<ComplexType Name="OpenBmc_Manufacturing"> <---- Removed "/" at the end
<Annotation Term="OData.AdditionalProperties" Bool="False" />
<Annotation Term="OData.Description" String="Oem properties for Manufacturing." />
The namespace labels you're using with the @odata.type values do not match. Your @odata.type properties reference the namespace "OemManager.v1_0_0", but the only namespace in the schema file is "OemManager". Since it would be good to align with the versioning guidance in the Redfish spec, line 23 in OemManager_v1.xml should have the namespace set to "OemManager.v1_0_0". You will also need to update other "Type" attributes in the file to match the new namespace name.
|
|
