|
Post by j2hilland on Mar 17, 2017 14:17:44 GMT
You can find the definitions for all properties and enumerations in the Schemas on redfish.dmtf.org. Look on this page for the schema index, click it and follow it to the schema you are looking for. This is particular enumeration is in Event and defined as EventType in that file. You can find the descriptions at redfish.dmtf.org/schemas/Event_v1.xml
|
|
|
Post by j2hilland on Feb 17, 2017 17:54:23 GMT
You should read the DMTF patent policy and discuss it with your lawyers. I'm willing to bet that the list published by the DMTF does not contain all of the patents that an implementation may need to secure rights to use. Not all patent owners are DMTF members. Furthermore, the DMTF patent disclosure rules does not ensure that all member company patents are put on this page.
|
|
|
Post by j2hilland on Jan 9, 2017 21:13:38 GMT
A quick note on ETags - while they are "recommended" for everything other than ManagerAccount resources, they are strongly encouraged. If your implementation supports multiple users logged on simultaneously, there is a chance that there could be a condition in your clients where they update stale data. This would lead to unhappy customers of your interface. And ETags are easy to implement.
|
|
|
Post by j2hilland on Nov 7, 2016 21:47:42 GMT
Read the section called "Asynchronous Operations". Basically, anything except a GET could take longer than the client calling the API planned on. That is currently the only way tasks start. So it could be an action (POST), it could be a Create (POST), delete (DELETE) or even modify (PUT/PATCH) at least theoretically. We have it on our list to create a YouTube video on Tasks, but it may be a few more weeks at least.
|
|
|
Post by j2hilland on Nov 7, 2016 15:41:12 GMT
@odata.id is a read-only property, so wouldn't be part of the post. It will be returned in the body and would be the "self" pointer for the resource created, thus the service side would create it. Clients don't get to pick the URI they want to create in Redfish.
OriginResources is different - and is new. It allows clients to pick which URIs they want to receive events about. Expect most implementations to not support this one for quite a while. It's really for aggregators and Swordfish where more resources are available to provide advanced functionality.
|
|
|
Post by j2hilland on Nov 3, 2016 21:39:24 GMT
So there is @odata.type, odata.context and @odata.id. OData.context is easiest to just leave unversioned. Take a look at DSP2043 (but a non work-in-progress version) and unzip it and look at the $metadata resource and you'll see the connection between the context and the $metadata. So just leave those as /redfish/v1/$metdata#<namespace>.<entity>. Odata.id is the self pointer. Note that the Id property in the resource will be the last segment of the URI. So if Id is 1 of a chassis, it would be /redfish/v1/chassis/1. Odata.type is the schema namespace and entity and we play a trick here. The namespace also has the version in it from an OData view point, as well as the entity definition. For JSON schema, it tells you the schema and version. So it is Chassis.v1_0_0.Chassis. We have to use the "v" because Odata won't let you start with a number and the underscores to make it a string since the period is a delimiter. So in the mockup, you will find that /redfish/v1/Chassis/1 has the following properties:
"@odata.context": "/redfish/v1/$metadata#Chassis.Chassis", "@odata.id": "/redfish/v1/Chassis/1", "@odata.type": "#Chassis.v1_0_0.Chassis"
I hope that explains it. Once you get it down, just follow the pattern!
|
|
|
Post by j2hilland on Nov 3, 2016 20:14:43 GMT
This is a hard to understand part of the spec, regardless of which spec you look at. That's why we have the mockups. Fist of all, remember this property should only ever be decoded by generic OData clients. The rest of the client community is likely to never care. Looking at a Chassis from our mockups, it has the format "/redfish/v1/$metadata#Chassis.Chassis" The first part is the canonical location of the $metadata object. It has references to all other schema used in an implementation. In the DMTF samples, the metadata document has the schema location as well as namespaces that are both versioned and un-versioned. The second part has the namespace and the entity definition. For DMTF schemas, we keep these the same. Thus it is Chassis.Chassis.
There are other formats you can use, such as the path format, but as we were developing the mockups we found it to be problematic for both clients and services and thus recommend the simpler format.
|
|
|
Post by j2hilland on Oct 28, 2016 14:16:29 GMT
The specification is normative in nature and doesn't have a lot of educational material (hence the YouTube, this forum, mockups, etc). We know we need to get more examples of PUT/PATCH out there. So it depends on the nature of the property. If it's required & writeable, you probably would supply it on the PUT. Quite frankly, there are very few resources where PUT is expected (hence the support for PATCH).
So you have to draw this conclusion from: - "Properties that are required to be implemented by all services are annotated with the required annotation." That tells you that you always have to set it. Now, the implementation might supply that value (like for Id, for example) - Schema is annotated with Redfish.Readonly = true for non-writable properties. So if it's both Writable and Required, then the PUT would have it.
But more importantly, you have done a GET on the resource first. That tells the client which properties are supported by the implementation. So there may be more properties supported than are Required. And if there are those that are writable and not supplied on the PUT, the implementation can return an error.
So the best semantic for the client is probably to do the GET, modify what is needed and then do the PUT. An implementation is expected to ignore the non-writable properties and do the update. It can create an ErrorInfo with warnings on the non-writable ones but it isn't required.
Or just do a PATCH.
|
|
|
Post by j2hilland on Oct 27, 2016 16:10:09 GMT
It doesn't need to - only the fields that you are changing. PUT would need all of them, but that's why we support PATCH so you can only change one property if you want.
|
|
|
Post by j2hilland on Oct 26, 2016 19:48:10 GMT
1) You cannot add properties to BootSource as an OEM. They are a fixed enumeration as part of Redfish - that's how we get interoperability between implementations. You have a couple of choices: a) an OEM section that has a property like "additionalBootSource" or something or b) submit your enumeration additions to the DMTF through the feedback portal and see if they are willing to add them. If you want to discuss them here, we can give you a good idea if they are likely to make it in or not. 2) Yes, you do not have to have all of the values available in the array. That is why it is a property and not a schema definition. So you can do as you suggest.
|
|
|
Post by j2hilland on Sept 22, 2016 19:10:27 GMT
The PowerPoint is just some of the recommendations and isn't meant as a substitute for reading the spec (which has additional information). But you ask a very good question, so I'll comment. You can't add it to an existing anything. The additionalProperties=false in the JSONSchema and similar rules in CSDL prevent this. But notice that every single resource has "OEM" in it and that construct does have additionalProperties=true. So that's the place you add the extension. There is a good example of this in ComputerSystem mockups for System/1 for an extension for a fictional company called "Contoso". So let's assume your Company name or stock ticker is "XYZZY". You would do two things: 1) define a Schema in both CSDL and JSON Schema to match the payload you want to add and 2) put that Schema in the OEM section. Using your example of FrequencyScaling, I think it would go best in Processor resources under the processor collection. I don't think you should put it under ComputerSystem, but you might. You would never extend a collection. Those are un-versioned and really are just meant to be a "bag of stuff" with no properties/semantics other than being a bag. So the actual Resource, with my company name being XYZZY, would look something like this: { "@odata.context": "/redfish/v1/$metadata#Systems/Members/1/Processors/Members/$entity", "@odata.id": "/redfish/v1/Systems/1/Processors/1", "@odata.type": "#Processor.v1_0_0.Processor", "Name": "Processor", "Id": "1", "Socket": "CPU 1", "ProcessorType": "CPU", "ProcessorArchitecture": "x86", "InstructionSet": "x86-64", "Manufacturer": "Intel(R) Corporation", "Model": "Multi-Core Intel(R) Xeon(R) processor 7xxx Series", "ProcessorID": { <Snip> }, "MaxSpeedMHz": 3700, "TotalCores": 8, "TotalThreads": 16, "Status": { "State": "Enabled", "Health": "OK" } "Oem" : { "XYZZY" : { "@odata.type": "http://schemas.xyzzy.com/XyzzyProcessor.v1_0_0.XyzzyProcessor", "FrequencyScaling" { "Status" : { "State" : "Enabled" } "StepValuePercentage" : 10 } } } } Notice a couple of things here: 1) Both the local JSONSchema (resource off of the root at /redfish/v1) and the $metadata should have references to this oem schema and the links header should have a rel value that points to it as well. And I might just want to put that file at "http://schemas.xyzzy.com/XyzzyProcessor.v1_0_0.xml" and "http://schemas.xyzzy.com/XyzzyProcessor.v1_0_0.json" or register it with the DMTF. 2) Notice that I used the Status property from Resource and used State from it. This is the unification/leverage that is talked about in the powerpoint deck of "Inheritance By Copy". Don't invent your own state/status mechanism. use the one the DMTF defined, even in your own schema. 3) The Schema would, in fact, just be a complexType and not a navigation property as I don't have an @odata.id or anything else. An example of schemas for those would be IPAddress. You can take it, rename it and modify it. ONE MORE THING: This sounds like a pretty common feature that just wasn't included in Redfish (yet). You can almost be sure it will be at some point and will probably be different than what you have (we don't try to do that but it happens for technical reasons sometimes). We would greatly appreciate it if you would submit the idea through the DMTF Feedback Portal at www.dmtf.org/standards/feedback and if you did so within the next week or two, we should have it as part of the standard by the next release. In fact, I'll champion it myself if you would kindly submit it to be part of the standard.
|
|
|
Post by j2hilland on Sept 22, 2016 18:53:17 GMT
We do some python validation but not as much as we probably should. We're really validating the CSDL more than anything. Which engineering team in #2? The HPE one? If so, I'll ask them to comment directly.
|
|
|
Post by j2hilland on Sept 19, 2016 20:20:28 GMT
I personally don't use this set of tools and since nobody else has responded, I can tell you that there are engineers here at HPE that are validating payload. And I know that when we were developing the standard, we had an engineer validate payload against the JSON Schema. In fact, the GitHub repo we use for developing the spec validates our mockups against schema or else it won't let us do the Merge.
That being said, I remember issues with the generic python libraries especially around $ref. The Odata elements should validate because the schema reference copies of them in JSON Schema, so if you have $ref fixed, that shouldn't be an issue. If there are white spaces, those sound like bugs to me and we would like to know about them.
So what is the recommendation for validating the content? That it should be Schema conformant and any errors should be noted and returned in the error response to the request.
|
|
|
Post by j2hilland on Sept 12, 2016 14:42:12 GMT
They are technically valid but since it is a may, Clients should be written to not depend on a Redfish Service to be able to respond to the Request. In fact, I don't know of any that currently support this syntax. Redfish is a hypermedia API. That means Clients should not construct URIs. The best way to ensure a service will be able to respond to your request is to do a GET on abc.oem.org/redfish/v1/Systems/437XR1138R2/ and look for the SerialNumber property in the Response payload.
|
|