ai1968
Minnow
https://www.youtube.com/c/alexeyi
Posts: 4
|
Post by ai1968 on Oct 21, 2022 15:46:58 GMT
Hi,
I work on an Interoperability Profile and found that it is impossible to specify more than one level nested PropertyRequirements statements because the Profile Schema does not allow that. Could you tell me, is there a way to improve the standard profile schema to allow more than one level nesting of the PropertyRequirements constructions?
|
|
|
|
Post by jautor on Oct 22, 2022 15:08:05 GMT
The schema should support nesting two object levels deep from the root of a resource:
<Resource>
<Object>
<Object>
<Property>
Can you show us those cases where you need to specify requirements beyond that level? We were hoping to avoid the need to nest more than two objects deep. And we may be able to offer some alternatives to accomplish the same goal in the profile.
Jeff
|
|
ai1968
Minnow
https://www.youtube.com/c/alexeyi
Posts: 4
|
Post by ai1968 on Oct 22, 2022 16:13:31 GMT
Hi Jeff,
Thanks. Could you take a look on the following fragment from my profile? It is intended for the ActiveDirectory AccountService property value verification:
Aleksey
"ActiveDirectory": {
"PropertyRequirements" : {
"Authentication" : {
"ReadRequirement" : "Conditional",
"ConditionalRequirements" : [
{
"CompareProperty" : "ServiceEnabled",
"CompareType" : "Equal",
"CompareValues" : [true],
"ReadRequirement" : "Mandatory"
}
],
"PropertyRequirements" : {
"AuthenticationType" : {
"Comparison" : "Present"
},
"Password" : {
"Comparison" : "Present"
},
"UserName" : {
"Comparison" : "NotEqual",
"Values" : [null]
}
}
},
"RemoteRoleMapping" : {
"ReadRequirement" : "Conditional",
"ConditionalRequirements" : [
{
"CompareProperty" : "ServiceEnabled",
"CompareType" : "Equal",
"CompareValues" : [true],
"ReadRequirement" : "Mandatory"
}
],
"Comparison" : "NotEqual",
"Values" : [null]
},
"ServiceEnabled" : {
"Comparison" : "AnyOf",
"Values" : [true, false]
}
}
},
|
|
|
|
Post by jyundt on Dec 2, 2022 16:54:48 GMT
jautor I also have several use cases for this. As an example: {
"SchemaDefinition": "RedfishInteroperabilityProfile.v1_5_1",
"ProfileName": "nested_property_requirements",
"Resources": {
"Processor": {
"PropertyRequirements": {
"ProcessorId": {
"PropertyRequirements": {
"EffectiveFamily": {},
"EffectiveModel": {},
"IdentificationRegisters": {},
"MicrocodeInfo": {},
"Step": {},
"VendorId": {}
}
}
}
}
}
}
I only realized that our Interop Profiles were invalid when I bumped our CI/CD pipeline to use DSP8013_2022.2 / RedfishInteroperabilityProfile.v1_5_1.json and most of our profiles failed to validate. Is there a better way to specify these types of nested PropertyRequirements? FWIW, I think that the Interop Validator sorta processes these correctly. Screenshot of that snippet from one of our servers: 
|
|
|
|
Post by jautor on Dec 5, 2022 20:32:14 GMT
I only realized that our Interop Profiles were invalid when I bumped our CI/CD pipeline to use DSP8013_2022.2 / RedfishInteroperabilityProfile.v1_5_1.json and most of our profiles failed to validate. Is there a better way to specify these types of nested PropertyRequirements? Oh, yikes... Well, it appears that our JSON schema is not correct, and that with the "tightened" annotations to disallow "additional properties", you're hitting the error in the schema. Your profile looks completely fine as shown. We've incorrectly placed the `PropertyProfile` definition in the schema definition. But the specification, and the tool usage, is correct. I've opened an issue and made fixes to the JSON schema to correct this, and will ask the group to place it in the next release. The good news is that the fix also allows for unlimited levels of object/property nesting, so that's an improvement over my previous solution to that one... Thanks again for finding this! Jeff |
|
