|
Post by hramasub on Oct 8, 2018 6:30:12 GMT
Great, Thanks !
|
|
|
Post by hramasub on Oct 4, 2018 8:14:10 GMT
Add POWER to the InsructionSet enum property in the Processor schema.
"InstructionSet": { "enum": [ "POWER", ... ], "enumDescriptions": { "POWER": "POWER 64-bit.", ... }, "type": "string" },
|
|
|
Post by hramasub on Oct 4, 2018 8:09:51 GMT
Add POWER to the ProcessorArchitecture property enum in Processor schema.
"ProcessorArchitecture": { "enum": [ "POWER" ... ],
"enumDescriptions": { "POWER": "POWER.", ... }, "type": "string" },
|
|
|
Post by hramasub on Oct 12, 2017 4:03:46 GMT
Thanks Jeff. I would be good to have the $metadata illustrate the OEM extension as well.
|
|
|
Post by hramasub on Oct 11, 2017 11:26:39 GMT
Is there an example of the Service Metadata response (xml doc) that must be returned for the https://<ip>/redfish/v1/$metadata URL ?
Specifically, I couldn't find concrete examples of the edmx:Schema tag must be formatted.
Please provide an illustration complete with all elements of the metadata response including: 1) Standard Redfish resources and Services. 2) OEM extension collections and/or resources.
Thanks!
|
|
|
Post by hramasub on Mar 1, 2017 5:31:25 GMT
The @odata.type property does _not_ provide the URL prefix. How does a client determine the URL prefix for the schemas: e.g. for DMTF schema: redfish.dmtf.org/schemas/ for OEM schema : www.contoso.com/redfish/schemas/"JsonSchemas" collection is _not_ a resource defined in the Redfish specification. Hence, a service implementation will have to define an OEM schema for that ? This appears to be a _cyclic dependency_. Do you have a suggestion to implement Jsonschemas collection without having to define an OEM schema for it?
|
|
|
Post by hramasub on Feb 27, 2017 13:04:05 GMT
Please provide an illustrative example of a Service Metadata document for a service which has the following types of OEM extensions : a) custom resources (say, an Audit Log resource collection with Audit Log entries) b) custom properties for standard redfish resources (say, an Engineering Revision number for a Processor)
note: The above oem extension uses are made up just to understand the concepts. They are not necessarily per the redfish resource modeling guidelines.
|
|
|
Post by hramasub on Feb 27, 2017 12:54:33 GMT
How does a generic client validate the response returned by the server ?
i.e. how does the client identify the schema against which the response must be validated ?
The URI in the Service Metadata document refers to the XML file and not the json file.
So, how is the path to the .json schema file for a given resource determined?
|
|
|
Post by hramasub on Feb 27, 2017 12:41:52 GMT
Are the array elements in the OData Service document limited to the *top* level collection resources and services ?
Besides authentication concerns, certain resources may be ephemeral, such as a given chassis which can be hot-plugged out. Hence it may be necessary to generate the "url" for such resources at run time ?
|
|
|
Post by hramasub on Feb 15, 2017 9:20:08 GMT
This readme for Redfish references the patent disclosures- Is an implementation of Redfish *infringing* on these and other undisclosed patents?
- Is an implementation of Redfish entitled to *package* (e.g. included in the software / installable image etc.) and *distribute* the Redfish schema files ?
|
|
|
Post by hramasub on Feb 15, 2017 8:59:38 GMT
What is the intended usage of the "copyright" property in the schema files ? - Is this only a *legend* Since this is a property defined outside of the "definitions" ?
- Is copyright a *metadata* that needs to be ever returned in the response body ?
|
|
|
Post by hramasub on Oct 28, 2016 5:38:54 GMT
Hence the "required" properties in the schema is applicable and need to be validated only PUT request ? i.e. even if the json schema "required" a set of properties to be mandatorily present in the body, it is acceptable for them not to be, if the body is in a PATCH request ?
Which section of the redfish specification talks about this behavior ?
|
|
|
Post by hramasub on Sept 21, 2016 16:04:41 GMT
There are a few advanced Power configuration data that needs to be accessed via Redfish API.
I am looking for directions on how to add these extensions.
Reading through this guidelines (https://www.dmtf.org/sites/default/files/Redfish%20Modeling%20Guidelines_0.pptx, slide #6), the following appears to be the available options:
A) Add to existing schema: a) Add new property : --> HOW ? Please provide example. b) Add new embedded object : --> HOW ? Please provide example. c) Add new enum values : --> HOW ? Please provide example.
B) Create new schema type: a) Add new subordinate resource : --> HOW ? Please provide example. b) Add new top-level collection : --> HOW ? Please provide example.
Consider the following use case of adding the following properties for configuring *Processor Frequency Scaling* : 1) Frequency Scaling Status (String: Enabled/Disabled) 2) Frequency Scaling Stepping (Number: 0 to 100)
Would the following be the changes required (per approach (B) above) ? Change#1) Create a *new* schema file for aggregating vendor specific frequency scaling properties + File name = Contoso_FrequencyScaling.v1_0_0.json + title = "#FrequencyScaling.v1_0_0.FrequencyScaling" + $ref = "#/definitions/FrequencyScaling"
Change#2) Create a new Complex Property FrequencyScaling as follows: "FrequencyScaling": { "Status" : { "type": "string" "enum": [ "Disabled", "Enabled" ] }, "StepValuePercentage" : { "type": number, "minimum": 0, "maximum": 100 } }
Change#3) Return FrequencyScaling as a property under Power::Oem::Contoso, whose odata.type points to the property defined under the new schema.
Is there also a means to add this as a sub-property directly under Power (per approach (A) above) ?
|
|
|
Post by hramasub on Sept 21, 2016 12:06:59 GMT
j2hilland: Thanks for taking time to comment. A few followup queries: 1) Do you use *python* based tools to validate the mockups against the schema before git merge ? 2) Would it be feasible to solicit comments from the engineering team ?
|
|
|
Post by hramasub on Sept 13, 2016 3:31:51 GMT
I am developing a Redfish server using python. My system runs a fastcgi compliant web server and hence I have the following building blocks: webserver : lighttpd (https://www.lighttpd.net/) wsgi adapter : flup (https://www.saddi.com/software/flup/) REST framework : bottle (http://bottlepy.org/docs/dev/index.html) Having received a PATCH request for a Redfish resource, I would like to *validate* the json body against the schema. I find the following projects as close fits for that purpose: *jsonschema* (Python module for json schema *validation*): pypi.python.org/pypi/jsonschemagithub.com/Julian/jsonschema*json-schema-objects* (Python class *binding* for json schema): github.com/cwacek/python-jsonschema-objectsWhile these tools are able to work with *simple* and *standalone* json schema files, I have not been able to parse Redfish schema. The following are some of the issues which I encountered while using those tools on Redfish schema: 1) Versioning of json schema (separate files for each version). 2) Naming syntax with special characters such as '#' and white spaces. 3) Linked / references to other schema via $ref. 4) Odata elements in schema. Given the requirement for python based Redfish *server*, what is the recommendation for validating the content body against the schema ?
|
|