|
Post by mraineri on Jul 15, 2019 20:12:14 GMT
Redfish Profiles is a broad concept; different organizations can create Redfish Profiles to describe requirements for a Redfish interface, as long as they follow the Redfish Profile Specification and schema for the profile. OCP profiles are a specific set of Redfish Profiles, which are being created to describe their particular management requirements for Redfish.
Organizations are allowed to submit their profiles to the DMTF for republishing on that link you've provided so that they can be hosted in a central location. No one has done this yet though. The DMTF might publish profiles at some point, but we'd rather see other organizations in the industry design these profiles since they're a method of conveying what they want out of Redfish from different implementations.
|
|
|
Post by mraineri on Jul 12, 2019 19:38:35 GMT
We're expecting that other organizations will follow the same path and will also be responsible for their respective profiles since ultimately the intent of a profile is to capture requirements that are outside the scope of the DMTF.
|
|
|
Post by mraineri on Jul 11, 2019 12:14:15 GMT
There are a few things that we have available to might be helpful to you. The DMTF YouTube channel has several videos on the core topics of Redfish, such as general modeling practices, and different types of client workflows: www.youtube.com/channel/UC2MIRFVOvpOo_hMT-TQU4gg
Mockups found here would be a good place to see what types of data a service is likely to present: redfish.dmtf.org/redfish/mockups/v1. The "Simple Rack-mounted Server" is a pretty standard representation of a sever.
|
|
|
Post by mraineri on Jul 11, 2019 12:08:15 GMT
Yeah, I understand the request. I'll bring this up in the group for further discussion along with the other requests.
|
|
|
Post by mraineri on Jul 2, 2019 19:04:21 GMT
Historically speaking, MaxPasswordLength and MinPasswordLength have usually been implementation specific and not necessarily a configurable item. However, things like this I can see as being configurable in some cases, and we can raise this in the group for further discussion.
As far as adding a regex pattern for password requirements, I'd be concerned about interoperability of expressing that string generically across multiple implementations. It seems like the string itself can be complex and might not be easy for humans to enter.
|
|
|
Post by mraineri on Jun 13, 2019 18:13:32 GMT
Perfect; I'd love to hear about those issues as you find them! I know some tools I've used have had mixed results for me. The only thing that seemed to consistently work was Swagger Editor for producing a human readable document of the API. From what I could tell at the time, there was lack of support of following external references in the OpenAPI community tools (especially with the code generators). There was one user who had a lot of progress though more recently and it's discussed in this thread: github.com/DMTF/Redfish-Tools/issues/179
|
|
|
Post by mraineri on Jun 13, 2019 17:50:13 GMT
And I agree; using "last" in those descriptions is odd. I think it would be best to remove that word since a given Task is not meant to be "restarted".
|
|
|
Post by mraineri on Jun 13, 2019 17:49:13 GMT
In the case where a Task is currently ongoing, I would expect "EndTime" to simply not be returned in the response payload. This is much like the case where you might have a DIMM not populated in a system, so properties like PartNumber, SerialNumber, and CapacityMiB are all not returned since the "State" of the resource is "Absent". Using null for the property value traditionally means that the property should be filled in by the service, but the service is unable to ascertain the value for the property.
|
|
|
Post by mraineri on Jun 13, 2019 17:27:51 GMT
The individual files for the resources (like Fabric.v1_0_5.yaml) are not meant to be used as an entire OpenAPI spec and will definitely not validate as one. These files are just individual sets of definitions. The expectation is everything would be processed from openapi.yaml file, which references the definitions within the smaller files. So, if you're building code, documentation, or something else, you will need to use the openapi.yaml file.
Beyond the migration of the URIs from the resource files to openapi.yaml, as well as the discrepancy with some of the properties that use common enum definitions, have you noticed anything else that is missing? As Jeff said, the intent is to have 100% coverage between the formats, and anything different/missing is a bug that will need to be fixed. We're not aware of other issues with the coverage between the different formats.
|
|
|
Post by mraineri on Jun 13, 2019 15:41:40 GMT
Within the conversion of JSON Schema to OpenAPI, there's a simplification made to reduce the OpenAPI documentation produced; when a link is found, it will replace the link with the "idRef" property. However, there are cases where we have external enum definitions; there is a bug in how this is being handled with the conversion tool and it treats this as a link and not an enum. This was raised on the tools repo as an issue here: github.com/DMTF/Redfish-Tools/issues/218
|
|
|
Post by mraineri on Jun 4, 2019 18:26:54 GMT
As a standard, we provision for the fact that clients might want to be able to write those properties, and recognize the more general use cases for it. However, as an implementer, you're allowed to implement a sub-set of the schema; if you do not wish to expose PATCH functionality (or simply make those properties read-only), that's entirely legal.
There are a few clauses in the specification about this: "A service may implement a writable property as read-only." "A service may implement a subset of the capabilities that are allowed on the Resource or Resource Collection." (This is with regards to a service supporting GET, POST, PATCH, etc)
|
|
|
Post by mraineri on Apr 30, 2019 14:50:07 GMT
The current data model just represents end certificates. The management of CA certificates is still an open discussion point within the standard.
|
|
|
Post by mraineri on Apr 25, 2019 12:27:09 GMT
We have a couple of YouTube videos available on the subject:
But as an example for your question, you would form a POST request against the Event Destination Collection URI, which should be "/redfish/v1/EventService/Subscriptions" if the service is conforming to the URI patterns we've specified in 1.6.0 of the specification.
The body of the request will contain an Event Destination object, which would look like this
{ "Destination": "http://my-event-listener-address", "Context": "Some context string for the listener to use", "Protocol": "Redfish" } There are other properties you can use in the payload to help specify types of events, particular messages, and specific resources you'd like to listen to. For example, adding "OriginResources" to the payload will mean that the listener will only receive events from the specified resources.
Unfortunately we do not have a Slack channel at this time, but we could discuss this internally.
I hope this helps.
|
|
|
Post by mraineri on Apr 17, 2019 19:15:09 GMT
You're close; the data in the body for the request needs to contain "ResetType": <TypeOfReset>.
{ "ResetType": "ForceRestart" }
The sections "6.4.4.7. Actions (POST)" and "6.5.4.7. Actions property" has some examples of this with a ComputerSystem, but the Manager version of the Reset action has the exact same parameter. You might also need to perform a GET on the Manager resource (/redfish/v1/Managers/Self) in order to see the values you're allowed to pass in for "ResetType".
Hope this helps!
|
|
|
Post by mraineri on Mar 26, 2019 18:47:00 GMT
I would think that reducing scope should be okay. For example, if "Capabilities.InsertRestrictions" is set to true in the published schema, you should be allowed to set it to false. However, the reverse is not true; increasing scope is not something we've allowed to do for schema modifications. We can add this clarification to the spec.
|
|