|
|
Post by arunthomas on Jul 18, 2023 11:22:22 GMT
we are using the different schema bundles(not specific to versions like 2020.1, 2021.4, 2022.1) In Openapi.yaml file we are able to see version details under info section info: contact: name: DMTF url: www.dmtf.org/standards/redfish description: This contains the definition of a Redfish service. title: Redfish version: '2019.2' x-copyright: Copyright 2019 DMTF. For the full DMTF copyright policy, see www.dmtf.org/about/policies/copyright Since resource(s) belong to different schema version, can we use version like version: '2019.2', '2020.1', '2021.4', '2022.1' Or remove version from Openapi.yaml . Thanks, Arun |
|
|
|
Post by mraineri on Jul 19, 2023 23:40:42 GMT
The openapi.yaml file really is a glorified set of paths and pointers to specific resource versions. This document is highly editable by the implementer to show the capabilities of the service. For the sake of convenience during publication, we (DMTF) put the 8010 version number in the file to show all the paths and resources defined in the bundle, but you can certainly use your own version number that makes sense for your implementation.
|
|
|
|
Post by AMI_Mani on Jul 20, 2023 18:25:08 GMT
Hi,
As per Redfish specification, below details available in 6.7 Redfish-defined URIs and relative reference rules section
/redfish/v1/openapi.yaml Redfish OpenAPI YAML document. Services should support this URI.
Which means recommended to implement OpenAPI and not mandatory. Also openapi.yaml is not coming service root(/redfish/v1/) and user needs to give direct request to /redfish/v1/openapi.yaml to check supported or not
Is it Mandatory for redfish service to be OpenAPI compliant? Already we are defining OEM schemas in json format and available as part of BMC. Do we need to define OEM resource, attributes in Yaml file? Since we have OEM property applicable for many standard resources and duplicate standard resource yaml files to add these OEM attributes which can create storage space issue in BMC
Do we have any tool like Redfish Service validator to vaidate OpenAPI Compliance? If there is no error in Redfish Service validator means we can consider it has passed OpenAPI conformance also
Thanks,
Mani
|
|
|
|
Post by mraineri on Jul 21, 2023 13:10:39 GMT
There's no such thing as "OpenAPI conformance" beyond implementing to the OpenAPI schema definitions. In Redfish, we put all schema definitions in three, functionally equivalent formats: CSDL, JSON Schema, and OpenAPI. You can test the service against any of these schema formats and if you pass one of the formats, then you would (in theory at least) pass against the other two. The Redfish-Service-Validator verifies you implemented to the schema definitions.
You do not need to carry the OpenAPI schemas on-chip to be OpenAPI conformant; it's acceptable for users to have their own local copy of these to generate documentation or code.
|
|
|
|
Post by AMI_Caffrey on Jul 24, 2023 2:46:02 GMT
I find a description in SPEC chapter "OpenAPI". It mentions "The service shall return the openapi.yaml file, if present in the Redfish service, as a YAML document by using either the application/yaml or application/vnd.oai.openapi MIME types."
Just have one more question. Is this means we don't have to provide openapi.yaml file in Redfish Service if our implementation have no plan to support it right?
Thanks,
Caffrey
|
|
|
|
Post by jautor on Jul 24, 2023 16:21:31 GMT
I find a description in SPEC chapter "OpenAPI". It mentions "The service shall return the openapi.yaml file, if present in the Redfish service, as a YAML document by using either the application/yaml or application/vnd.oai.openapi MIME types." Just have one more question. Is this means we don't have to provide openapi.yaml file in Redfish Service if our implementation have no plan to support it right? Thanks, Caffrey Correct, the specification goal is that if you support OpenAPI, we want to ensure that the YAML file can be retrieved from a known location in a known format. But there is no requirement to provide the openapi.yaml file. Jeff |
|
