Need a way to skip OEM URI validation

DMTF / Redfish-URI-Validator

The Redfish URI Validator is a Python3 tool which scans all resources on a given service and verifies the URIs on the service match the patterns described in a provided OpenAPI specification.

Other

1 stars 2 forks source link

Need a way to skip OEM URI validation #4

Closed snk20501 closed 5 years ago

snk20501 commented 5 years ago

Hi,

Tool doesn't have a way to skip level2 OEM resources, so will show unexpected ERRORs for OEM resources.

For example, if we have following OEM resource and show under ServiceRoot, tool will show Warning in test report and this is expected because OEM schema not included in openapi.ymal.

"Oem": { "ABC": { "@odata.type": "#ABC.v1_0_0.ABC", "ABC": { "@odata.id": "/redfish/v1/ABC" } } }

But resources under "/redfish/v1/ABC" will be reported as ERROR in report, because can't find match URI pattern in openapi.ymal, like "/redfish/v1/ABC/LogServices".

Please help to check this problem. Thank you so much.

BR, Caffrey

jautor commented 5 years ago

Discussion 8/29 - Will investigate this but agree there should be an option (probably default to true) to skip OEM resources as they won't validate against the standard/published schema files.

snk20501 commented 5 years ago

Good to know. Thanks for the support.

billdodd commented 5 years ago

I can't reproduce the error. If I run the tool on a service with Oem resources, I can see warnings for Oem elements, like this:

But I don't see any errors.

Can you post a screenshot of the exact error you get along with the JSON of the resource that references the Oem resource?

snk20501 commented 5 years ago

@billdodd I will provide reference data.

mraineri commented 5 years ago

@billdodd have you started work on this? Depending on the data given by @snk20501, I may be addressing this as part of fixing #1

billdodd commented 5 years ago

@mraineri - No, I haven't. I wasn't able to reproduce the error, so was waiting for more detail from the originator.

mraineri commented 5 years ago

If the report shows "warning" for OEM resources not listed in the "paths" object of the specified OpenAPI document, is this okay?

My expectation is that vendors should provide their own updated OpenAPI document with OEM URIs so that clients could generate documentation and code for a particular implementation if needed.

mraineri commented 5 years ago

@jautor I could go either way on this, but I like the idea of having fewer arguments for the tool and accepting warnings for these scenarios. I know you feel strongly about presentation of tool output, so I'll let you make the final decision ;)

jautor commented 5 years ago

I think a warning is fine here, as long as the message mentions that this is due to OEM (extension) usage, as opposed to a "wrong" URI - which would be a failure. I agree that additional utility options are not likely to help here.

So there's two OEM warning cases:

OEM schema type not listed in OpenAPI document
OEM usage of a standard or listed type (contained in OpenAPI document) but a URI not listed.

I haven't looked, but I assume through the traversal that the utility knows that it is following OEM section links?

mraineri commented 5 years ago

Yeah, both will show up as a warning. The code I'm adding doesn't care about schema type and purely builds a property hierarchy from Service Root to the resource under test. If "Oem" is in that hierarchy, it will show a warning and state "OEM resource X was not found in the OpenAPI specification", where X is the URI being tested.

mraineri commented 5 years ago

Closing; resolved with recent PR.