|
|
Post by kilgorep on Oct 12, 2022 21:45:09 GMT
I'm looking at implementing some of the new annotations added in the 2022.2 bundle with the intent of communicating to clients any constraints around property values supplied in a PATCH request, namely via @redfish.Allowable[Numbers|Pattern|Values].
In the case of a Links property, namely Links.DedicatedSpareDrives in the Volume resource, would stacking one of these new annotations onto an @odata.id be supported by the spec? Something like:
{
"Links": {
"DedicatedSpareDrives": [
{ "@odata.id.@Redfish.AllowablePattern": "\/redfish\/v1\/Systems\/1\/Storage\/1\/Drives\/[0-9]{1}" }
]
}
}
If not, is there a better alternative available?
|
|
|
|
Post by jautor on Oct 13, 2022 0:25:53 GMT
Well, you can't annotate an annotation, so that won't work - and it certainly wasn't the intent to use the allowable values annotations to craft URI patterns...
But for this specific case, it seems like this might be better defined as an actual property, to give a list of "available drives that could be used as a dedicated spare". Your example seems to be just "drive 0-9", but I'm assuming there will be cases where the list would be much more restrictive?
I'll bring this up to some of the storage folks and see if that would be an answer...
Jeff
|
|
|
|
Post by kilgorep on Oct 13, 2022 13:40:57 GMT
Thanks for the feedback Jeff. It did look a little screwy to me writing it, but I figured it was worth sanity checking.
As for your alternative suggestion, I agree that adding a dedicated property like Links.AllowableSpareDrives or something along those lines to the Volume resource would probably be more easily usable by everyone involved (storage devices / MCs / clients), particularly for the reason you mentioned. An array of spare drive URIs would definitely be easier to craft and interpret than a regex string capturing a potentially discontinuous list of spare drives.
|
|
