|
Post by mraineri on Jan 16, 2020 13:40:49 GMT
I should also add that it shouldn't cause issues to have extra namespaces referenced in the document; they will just be unused by clients.
|
|
|
Post by mraineri on Jan 16, 2020 13:38:15 GMT
No, you do not need to include everything. You only need to include schemas and namespaces your service implements. Generally speaking, OData clients will use properties like "@odata.context" and "@odata.type" in conjunction with "$metadata" to look up definitions. So, if your service reports "#ComputerSystem.v1_5_0.ComputerSystem" as a value for "@odata.type", then "$metadata" needs to contain a reference to the "ComputerSystem.v1_5_0" namespace. There's a bit more info about this found in section 5 (Metadata document) of our Redfish and OData White Paper here: www.dmtf.org/sites/default/files/standards/documents/DSP2052_1.0.0.pdf
|
|
|
Post by mraineri on Jan 9, 2020 12:54:02 GMT
|
|
|
Post by mraineri on Jan 9, 2020 12:50:12 GMT
This is interesting. The duration format we leveraged if from the OData definition (in OData CSDL, the type is Edm.Duration). Looking deeper into this, OData restricts the usage to only go up as high as "days"; months, weeks, and years are not allowed to be represented. I think we need to take a closer look at this since our specification does not match the OData usage.
|
|
|
Post by mraineri on Jan 7, 2020 19:54:02 GMT
|
|
|
Post by mraineri on Nov 21, 2019 15:44:13 GMT
Yes, that is perfectly legal to do. The service itself has a property within ServiceRoot to identify the protocol version of Redfish in which it conforms, and each resource independently identifies its schema version. So, you can mix the different combinations as you need to based on your own requirements for what needs to be supported for your service.
|
|
|
Post by mraineri on Nov 20, 2019 18:14:31 GMT
HttpPushUriTargets is a property that allows the client to configure which targets are updated when the client performs a POST to the URI specified by HttpPushUri. This is important in cases where a single manager is responsible for multiple systems, and a user only wants to perform an update for a single system.
I would expect clients to first configure HttpPushUriTargets to specify what devices/components in the service are to be updated (which could be a URI to a ComputerSystem, a URI to something in the Firmware Inventory Collection, or something else), and then the client would perform a POST to the URI specified by "HttpPushUri". If HttpPushUriTargets property is an empty array, I would expect the service to make decisions internally as to where the image is applied.
One thing to point out is the forum is trying to move away from HttpPushUri; we've seen interop problems with it since the current definition is very loose and up to implementers to decide the protocol aspects of it. As of specification 1.8.0, we've introduced "MultipartPushUri" and specified how clients and services use that functionality.
|
|
|
Post by mraineri on Nov 19, 2019 19:49:33 GMT
I think we want to have a message in the Base message registry for this case (and others) where a property value is not correct. It could be due to a regex violation per the patterns term, password complexity rules, or some other problem. But essentially we need something more deterministic for a client to know a value is not correct.
|
|
|
Post by mraineri on Nov 18, 2019 18:26:31 GMT
The schema bundle and specification are not really tied together; both can be updated independently. However, we tend to release both at the same time during our release cycles. Implementations are not required to update their schemas to a given bundle; some implementations may just pick which schema files they'd like updates for, and leave other ones at older versions if they have no need for added functionality. "@odata.type" can be used to get the particular version of a resource; for example, "#LogEntry.v1_5_0.LogEntry" means the resource is following the LogEntry schema with version 1.4.0. We do document in the schema which release bundle the version was added though; you should see terms at the bottom of the schema file like this:
"owningEntity": "DMTF", "release": "2019.3", "title": "#LogEntry.v1_5_0.LogEntry" } This was relatively new term we've been using in schema files (maybe in the last 18 months), so older schemas won't have the "release" term.
|
|
|
Post by mraineri on Nov 15, 2019 13:07:33 GMT
That looks like an older version of the description. We have clarified it over time, and the latest version has that sentence removed. I vaguely remember an issue that was raised about that a while ago. Here's the latest descriptions for that property:
"MessageId": { "description": "The MessageId, event data, or OEM-specific information. This property decodes from the entry type. If the entry type is `Event`, this property contains a Redfish Specification-defined MessageId. If the entry type is `SEL`, this property contains the Event Data. Otherwise, this property contains OEM-specific information.", "longDescription": "This property shall contain the MessageId, event data, or OEM-specific information. This property decodes from the entry type. If the entry type is `Event`, this property contains a Redfish Specification-defined MessageId property of the event. If the entry type is `SEL`, this property contains the three IPMI Event Data bytes. In this case, the format should follow the `^0[xX](([a-fA-F]|[0-9]){2}){3}$` pattern, where Event Data 1 is the first byte in the string, Event Data 2 is the second byte in the string, and Event Data 3 is the third byte in the string. Otherwise, this property contains OEM-specific information.", "readonly": true, "type": "string" },
|
|
|
Post by mraineri on Nov 15, 2019 13:03:50 GMT
The expectation with POSTing an image to the URI specified by HttpPushUri is the update will being when the image is received. There are additional properties that have been added to help with scheduling aspects of it (similar to how you can use @redfish.OperationApplyTime to specify when the update starts when using the SimpleUpdate action). Version 1.4.0 of the UpdateService added "HttpPushUriOptions", which contains "HttpPushUriApplyTime/ApplyTime" and "HttpPushUriApplyTime/MaintenanceWindowStartTime".
I should note that due to how loose the definition is with HttpPushUri, most implementations likely treated this as an OEM method of updating. So, while in my mind those are the semantics around it, there's very little enforcement, and entirely possible an implementation requires another step to start the update.
We recently published a newer push method with the "MultipartHttpPushUri" property in version 1.6.0 of the UpdateService, which points to the Redfish spec for full details about expected behavior; this was added in 1.8.0 of the spec. Effectively you would POST to the URI specified by MultipartHttpPushUri using HTTP multipart forms, where one of the forms is a JSON body containing parameters (and annotations such as @redfish.OperationApplyTime if needed). Once the image is pushed, you'll get back a Task, and can monitor the progress of the update similar to how SimpleUpdate should behave.
|
|
|
Post by mraineri on Nov 12, 2019 17:58:34 GMT
That's not quite true.
MessageIds are specific messages within a Registry, such as "Resource.1.0.ResourceCreated", meaning that only events containing that specific message will be sent to the subscriber. "RegistryPrefixes" is used to filter on an entire set of messages, such as "Resource". You could recreate the same semantics by specifying every single message in a given registry in the "MessageIds" array, but that becomes a large burden.
The same sort of difference applies with "ResourceTypes" and "OriginResources". You can specify something like "Power" for "ResourceTypes" to receive all events originating from all "Power" Resources, or give a specific Resource in "OriginResources" like "/redfish/v1/Chassis/1/Power" to only get events from a particular instance of a Resource.
|
|
|
Post by mraineri on Nov 11, 2019 14:40:21 GMT
That's correct, the conversion tool will fill in "format" based on a few different things: - If the type is "Edm.DateTimeOffset", put in "date-time" - If the property contains "OData.IsURL", or is the "target" property in an action, put in "uri-reference" - If the property contains "Validation.Pattern", copy the pattern into "format"
We've definitely been behind with keeping the spec up to date with all of the terms we've been using in schema. I think it would be a good idea to add this an other terms that may be missing. It would go in both sections 9.2 (the general schema annotation listing) and section 11 (how they're used in the different schema languages).
|
|
|
Post by mraineri on Nov 8, 2019 20:43:01 GMT
I should also note that the "redfish-schema" file is an extension of the core JSON Schema vocabulary; since "$schema" has the value "http://json-schema.org/draft-07/schema#", this pulls in the referenced core JSON Schema definitions. This is where things like "format", "definitions", "properties", and other JSON Schema terms are defined.
|
|
|
Post by mraineri on Nov 8, 2019 15:03:57 GMT
|
|