|
Post by mraineri on Jun 6, 2018 11:56:08 GMT
You're correct in that there is no real subscription. When a client connects to the SSE URI, all events tracked by the service will be reported to the client. In this model, the client performs the event filtering when it receives data on the SSE connection.
Unfortunately I do not know how to answer your second question; ultimately you should be doing what makes the most sense for your implementation. I imagine you'd probably have a single source where events are generated, and that would be the place to push data to all open SSE connections.
|
|
|
Post by mraineri on Jun 5, 2018 14:32:14 GMT
With regards to Chinook, Chinook was a submission to extend the Redfish data model. The Redfish Forum took the submission and modified it further to cover the gaps for how a service can express Memory, Storage, and Fabrics. These extensions were made part of the standard towards the end of 2016.
However, this is not to be confused with a profile. Chinook was a proposed data model. A profile may be used by an organization to specify requirements on a service for what elements of the data model are made available, such as requiring Memory, Storage, and Fabrics resources being exposed (and which properties in those resources are required).
|
|
|
Post by mraineri on Jun 5, 2018 14:01:21 GMT
You're correct; the capabilities object currently does not convey that sort of information. The intent of the capabilities object is to describe the structure of the POST request; it wasn't intended to show implementation specific restrictions on how things can be composed. Currently this would require the client to try a composition request, see it fail, and modify the request as the service indicates. I'll bring this up for discussion within the group to see if there's a better solution.
|
|
|
Post by mraineri on Jun 5, 2018 13:57:51 GMT
"Status" as an object is not marked with any sort of permissions. We do that in the Redfish data model for all objects in resources since there are cases where different properties in the same object can have different permissions. In the case of Status, all of the underlying properties ("State", "HealthRollup", and "Health") are marked with "Read" as the permission. So, it should not be possible to PATCH or PUT the Status object on a resource.
We define Actions on resources for cases where we expect the client wants to be able to affect a resource in a particular manner, but the PUT and PATCH HTTP verbs do not make sense for the given context. PUT and PATCH are methods where a client wants to directly change a value in the resource (like changing an AssetTag property). Doing something like a "Reset" doesn't translate very well to PUT and PATCH, so Actions are used in these scenarios. It's possible that some Actions will have an effect on some properties though. For example, performing a "Reset" with the ResetType set to "ForceOff" will likely change the "Status" of the resource.
|
|
|
Post by mraineri on Jun 5, 2018 13:48:26 GMT
The current definition of Actions and the ResetType enum do not allow for additional parameters or additional parameters on Actions. You can support a subset of what's defined for a given enum, but you cannot use anything beyond the list. Redfish properties have the same restriction.
If you're trying to add new properties, parameters, or enum values, this should be done within the OEM object for the resource.
|
|
|
Post by mraineri on May 29, 2018 19:27:56 GMT
We discussed this briefly today. The idea we're thinking about currently is adding a NetworkProtocol resource subordinate to each EthernetInterface. This will allow you to control a protocol on an interface by interface basis. However, we think there may be some complexities with going this route, mainly what is client software supposed to do if it finds a NetworkProtocol resource subordinate to a given Manager in addition to NetworkProtocol resources subordinate to each interface. What's your opinion on this type of approach?
|
|
|
Post by mraineri on May 21, 2018 11:48:01 GMT
|
|
|
Post by mraineri on May 18, 2018 19:23:43 GMT
We actually recently added support for using SSE as a method of receiving events. Within section 8.5 of version 1.5.0 of the Redfish Specification ( www.dmtf.org/sites/default/files/standards/documents/DSP0266_1.5.0.pdf), we allow for a client to perform a GET on a URI specified by a new property in the EventService called "ServerSentEventUri". All events generated by the service will be sent to the client on the open socket. So, with this mechanism, a client does not need to make a subscription, and wait for events to be published. However, our mockup server tool does not support this sort of functionality. The mockup server is a very simple service that just provides single JSON files when a client makes a GET request.
|
|
|
Post by mraineri on May 18, 2018 18:57:56 GMT
#1 is the correct method. As of last summer, we've provisioned all of our resources to support an Actions property, so OEM actions belong inside of "Oem" within the Actions property. We have an example of this in our mockups for a ComputerSystem.
Here's the sample
"Actions": { "#ComputerSystem.Reset": { <Standard ComputerSystem Reset Action> }, "Oem": { "#Contoso.Reset": { "target": "/redfish/v1/Systems/437XR1138R2/Oem/Contoso/Actions/Contoso.Reset" } } },
|
|
|
Post by mraineri on May 2, 2018 13:02:25 GMT
Using "#System.Rest" in the "Actions" object is not correct. The format of the object inside of the Actions object needs to be in the form of "#<Namespace>.<ActionName>". Since the Action definition is inside of the "ComputerSystem" Namespace within the ComputerSystem_v1.xml schema, and it's "Name" is defined as "Reset", the action descriptor must be "#ComputerSystem.Reset". In JSON Schema, this is also explicitly called out as "#ComputerSystem.Reset".
There is also another issue. "Target" has a capital T; this needs to be a lower case T ("target") per the specification.
I suggest contacting the vendor to fix this; they're not adhering to the schema or specification.
Could you also please point me to where on the Redfish site you see an example of "#System.Reset"? I cannot find a reference for that (at least in the mockups or specification).
|
|
|
Post by mraineri on Apr 25, 2018 12:01:29 GMT
Hi Chenwang86, Dell EMC supports the DMTF Redfish API through the iDRAC RESTful API available on the iDRAC7, iDRAC8, and iDRAC9 embedded management controllers for Dell EMC PowerEdge 12th, 13th and 14th generation servers. There are several guides and white papers on the Dell EMC website that show what has been implemented on the iDRAC and the APIs available. Thanks. -Mike
|
|
|
Post by mraineri on Mar 28, 2018 17:51:31 GMT
A Referenceable Member really is just a JSON object in a Resource that also has an @odata.id property. The reason for doing this is there are cases where we want to leverage using Navigation Properties in the data model so that we can show relationships with objects nested in a given resource. Because of this, we define Recerenceable Members as an EntityType in the CSDL schemas instead of the ComplexType definition; Navigation Properties must point to an EntityType with a valid @odata.id property.
For example, lets take an event in regards to a temperature sensor. Since the Thermal resource for a Chassis consists of a list of many Temperature sensors (which are defined as Referenceable Members within the Thermal resource), it wouldn't be very useful to simply give a link to the Thermal resource. Instead, the OriginOfCondition property for the Event payload can link to the individual Temperature object in the Thermal resource using the specific Temperature's @odata.id property.
|
|
|
Post by mraineri on Mar 16, 2018 11:58:16 GMT
Actions in the response payload are represented in the following manner: { "#Namespace.ActionName": { "target": "some URI" } }
This format is defined by OData and leveraged by Redfish. "Namespace" is the CSDL Namespace where the action is defined, and "ActionName" is the name of the Action object in the schema file. The "Namespace" can ultimately be found based on the referenced namespaces in the $metadata resource. So, if a client were to come across the action "#Contoso.Reset", the methodology to resolve where the action is defined would be to: - Go to the $metadata resource and locate the namespace "Contoso"
- Go to the file referenced by $metadata and locate the namespace "Contoso"
- Within the "Contoso" namespace, locate the Action named "Reset"
This same process can be applied generically with all actions (not just OEM actions). Unfortunately the DPS2043 bundle does not have the $metadata resource updated to include these same OEM namespaces. But effectively to correct this, $metadata would also include something like this: <edmx:Reference Uri="http://Contoso.com/schemas/Contoso_v1.xml"> <edmx:Include Namespace="Contoso"/> </edmx:Reference>
|
|
|
Post by mraineri on Feb 20, 2018 18:41:11 GMT
That's correct; that's why as a general methodology with using "deprecated" in the schema is to keep the definition around until a new major version is introduced. This allows a good amount of time for services and clients to transition to new definitions.
While we haven't gone through this yet, we suspect that transitioning to a new major version of schema will break backwards compatibility and will require both client and service work in order to transition to a 2.X.X version. So, that sort of breaking point is ideal from a standards perspective to pull out deprecated definitions. Keep in mind, just because a schema may transition to a new major version, clients and services can still use older versions of the schema until they're ready to transition, which means they can continue to use deprecated definitions until they can be updated.
|
|
|
Post by mraineri on Feb 20, 2018 12:56:47 GMT
We track descriptions for those in the Redfish Schemas themselves. The schema files "RedfishExtensions_v1.xml" and "redfish-schema.v1_X_0.json" contain the annotations we've defined in the SPMF. Each of the schema files in both CSDL and JSON Schema will reference one of the two files in order to leverage those definitions. For example, in the file Chassis.v1_6_0.json, it contains the term "$schema" with the value "http://redfish.dmtf.org/schemas/v1/redfish-schema.v1_3_0.json", which is the JSON Schema method of including additional meta-schema elements. We can discuss it within the group to see if it's worth copying the descriptions into the specification, but at least they're in the schema files themselves currently.
For your other questions... 1) Generally speaking, we'd clean up the schemas and remove deprecated properties when a new major version of the schema is introduced; this is mentioned in the description for the deprecated term: "Deprecated properties are likely to be removed in a future major version of the schema." One thing to keep in mind though is major version changes tend to break backwards compatibility, so we try to avoid those if possible. 2) We could leverage the same term to deprecate an entire resource, but that's not something we've encountered yet. Ultimately I think there will need to be careful thought when doing that, since we'd have to scrub all of the NavigationProperty elements that reference the deprecated schema and in turn deprecate those properties.
|
|