|
Post by jautor on Aug 28, 2023 15:22:43 GMT
Hi Dmitry,
You've certainly hit upon a use case where that amount of parameter flexibility would be needed. And while you could define that today in an Action, as you noted with the object/pattern as with the HttpHeader property, that would not allow the service to provide the usage "hints" (assuming the service knows those or can discover them).
You are on the right track, and I'll discuss with the group how to handle this. We noticed recently that ActionInfo cannot describe much for an object-type parameter (but we haven't hit the need for that in the standard so far), so some need for more support there is not unexpected.
My concern will be to ensure that this is explicitly captured in the Action definition - if an Action needs this capability (to give a list of parameters that are specific to an instance of a resource type), it must be called out in the Action. I would not want to leave it open to "any action" to add these extended parameters. Doing that would allow OEMs to create "required OEM parameters" on any action which destroys interoperability.
I think we'll also need to think about how much attribute information the service will have available - whether an ActionInfo resource could reasonably provide that information, or if it should provide a reference to an AttributeRegistry that a client could retreive separately (if the client is going to be that aware of the schema/definitions).
Jeff
|
|
|
Post by jautor on Jul 31, 2023 21:27:30 GMT
`Location` / `PartLocation` is the preferred, since that information is placed within context of the adapter's resources (whether that be PCIeDevice or the more specific ones like FabricAdapter).
Jeff
|
|
|
Post by jautor on Jul 31, 2023 18:42:01 GMT
And the `Status` / `State` values, along with `RelatedItem` can be used to differentiate between the image "in use" vs. "uploaded but not active".
|
|
|
Post by jautor on Jul 24, 2023 16:33:15 GMT
Hmmm... I need to take a closer look to see what the value should be. That "object" in `GenerateCSR` is an "idRef". The purpose of the `ObjectDataType` property was to describe JSON object structures by referencing their definition in schema. An idRef is really a special case - while technically an object, it's going to include a single `@odata.id` property as a link to a Redfish resource.
So it will not be either of those values, but rather something else. I need to research what the "proper" `@odata.type` value would be for an "idRef". Stay tuned - I also think we need to add some description text for `ObjectDataType` to explain this case - as it does appear in several Actions.
Jeff
|
|
|
Post by jautor on Jul 24, 2023 16:21:31 GMT
I find a description in SPEC chapter "OpenAPI". It mentions "The service shall return the openapi.yaml file, if present in the Redfish service, as a YAML document by using either the application/yaml or application/vnd.oai.openapi MIME types." Just have one more question. Is this means we don't have to provide openapi.yaml file in Redfish Service if our implementation have no plan to support it right? Thanks, Caffrey Correct, the specification goal is that if you support OpenAPI, we want to ensure that the YAML file can be retrieved from a known location in a known format. But there is no requirement to provide the openapi.yaml file. Jeff
|
|
|
Post by jautor on Jul 14, 2023 15:18:18 GMT
Note that the DMTF does publish a set of mockups (DSP2043) to show samples of a number of different products / implementations. www.dmtf.org/sites/default/files/standards/documents/DSP2043_2023.1.zipWe generally start with one of the existing mockups in DSP2043 (or from a live system) and modify it to model new functionality. A tool that created a mockup from schema alone would probably result in as much work to prune out the hundreds of additional resources that would not apply to a particular implementation (and also fill out actual data values throughout) as it would be to modify an existing mockup... Jeff
|
|
|
Post by jautor on Jul 14, 2023 4:39:14 GMT
hi, I see in latest schema, "SupportedCollectionFunctions" is still writable. Please kindly arrange schema update if its need to be corrected. Thank you. BR, Caffrey It has been corrected in the latest schema (DSP8010 2023.1), TelemetryService.v1_2_4 or TelemetryService.v1_3_2. If you're seeing something different, let me know. Jeff
|
|
|
Post by jautor on Jul 13, 2023 21:44:16 GMT
Hi Jeff, Base on the example provided by @mani, this might also depend on BIOS design. The override behavior actually controlled by BIOS. BMC only provides setting data. After BOIS see override settings data, it actually change settings in BIOS. Please see if this case can explain our case. BR, Caffrey
This setting is an "override" of the boot order as owned by the BIOS (or whatever platform firmware component actually controls the boot process). While we'd like other interfaces (BIOS Setup UI) to coordinate with the BMC settings for the best user experience, it's not required.
If a user has managed to get to the BIOS setup while a 'Continuous` "BootSourceOverride" was in place, it may be a good idea to cancel that override, since it's obviously not working (or the user has had to work to get out of a loop).
The `Continuous` value was added to allow for deployment processes that may fail or need multiple boot cycles to complete - the intent being that once the process completed successfully, it would change the override setting back to `Disabled`.
I'm sorry there's not an easier answer here - it's not an issue specific to Redfish, but rather to the complexity that results from multiple interfaces that are not guaranteed to be in sync with each other...
Jeff
|
|
|
Post by jautor on Jul 13, 2023 21:19:06 GMT
While an implementation may change an AllowableValues list based on configuration (some values may be supported by the service firmware, but not a particular instance of hardware, for example), it should not alter the list based on state. As Mike points out, removing the current state can cause confusion, and quite frankly, is more software work... The AllowableValues annotations should generally be static values.
Jeff
|
|
|
Post by jautor on Jul 12, 2023 16:28:17 GMT
You're correct that the standard schemas don't have a method currently to enable/disable buttons. And I agree that there's certainly some industry-normal functionality there - especially for the power button. Many systems allow for the power button to be disabled, or to choose the reaction to a button press.
Other buttons like a reset/NMI - are those configurable by the user? Turning off a "hard to accidentally hit" reset button would seem counter-productive...
Jeff
|
|
|
Post by jautor on Jul 10, 2023 17:54:57 GMT
Ok, good. There is an example of this called "OperatingConfig" which provides a 'profile' of settings for a Processor instance. You will see a collection of OperatingConfig resources, and on each processor there is a property called "AppliedOperatingConfig" which points to the member of the collection that is currently in use (applied) to that particular processor.
So you would perform POST (create) and DELETE operations on a collection of "profiles" and make some property where appropriate to allow the configuration of which profile to actually use.
Jeff
|
|
|
Post by jautor on Jul 6, 2023 23:46:42 GMT
So "Profiles" is a heavily overloaded term (and we unfortunately also use it in Redfish as there just wasn't a better word, but I don't think you're referring to the Redfish Interoperability Profile in this case) - so without some context of what that means in this case, this is only general thinking...
Assuming this is something where a "profile" is created/deleted/updated by an end user, you would probably create a collection of those, and then provide a "ProfileService" resource that would show how those are being used. See the "AccountService" and "ManagerAccount" schemas for an example. You might need an Action to perform something like "Apply Profile" if a PATCH on a single property "ProfileApplied": <URI of profile> wouldn't suffice...
If you can give us an example of what "profile" means in your case, we might be able to give more guidance...
Jeff
|
|
|
Post by jautor on Jul 6, 2023 23:38:28 GMT
For the PDU the functional view can be found under "PowerEquipment/RackPDU/SomeRackPDU/...", where all measurements can be read and outlets can be switched too (a relay is the physic behind that). Now i am asking where the pyhsical representation of this "switching component" should be placed at. Normally i would assume that besides "/Chassis/SomeRackPDU/Sensors/.." there should be another collection like "/Chassis/SomeRackPDU/Actors/..", but i can't find it or an eqivalent. Background is that we have accessorys that contain sensors and actors. For example an device with digital inputs aswell as outputs. Take a look at Controls for those outputs. But our thinking on configurable inputs/outputs that they show up in the standard Redfish model once they have been configured to be "something" that is available in the standard resource definitions. So an input configured (with proper hardware) to be a temperature sensor for a rack would show up as such - and be reported in the EnvironmentMetrics for the Chassis that represents the rack. Until that configuration has been performed, we don't have a standard model to show that "unconfigured input/output" - and it's not clear if there's a benefit for attempting to standardize that. I think there are so many options and possibilities that there would be no interoperable overlap among vendors/implementations, so just do an OEM definition that meets your needs, and ensure those devices show up in the standard locations and models once they have been configured... And if there's more Control or Sensor types to add to the standard, of course, let us know! No, a Chassis instance could just be a physical container, likely with some product identification (make/model/serial number) and with perhaps some environment sensors. We envisioned a Rack to be just that - a way to show the physical location of a bunch of gear that share a common piece of infrastructure, with their position in the rack and external sensors that provide "rack level" temperature, power consumption, etc. reported in one place that can be associated with all the individual pieces enclosed. Jeff
|
|
|
Post by jautor on Jun 17, 2023 17:35:32 GMT
Yes, all Redfish schemas in the v1.xx.xx range are backwards compatible, and therefore, any of the profile requirements are as well. A profile may specify minimum schema versions, but it will effectively do that by placing requirements on a properties added to later versions of that schema.
If your implementation supports the properties required by the profile, the schema version will not matter. For instance, you implement the Memory v1.12 schema, and want to conform to a profile which requires `SecurityState` (added in v1.7) and `SparePartNumber` (added in v1.11). As long as the implementation includes both of those properties, it would pass the profile conformance test, even though the latest version of the Memory schema is v1.17.
Jeff
|
|
|
Post by jautor on Jun 9, 2023 22:52:49 GMT
The intent was to surface whatever identifier the manufacturer provides to the end customer/user to "match up" a device discovered on the network (via DHCP, SSDP , or whatever means) with initial, pre-shared credentials. While UUID can absolutely serve that purpose - that value is not generally what is provided to end users. It may be the unit serial number, the MAC address of the BMC, or something else entirely. Since we have no control over the factory or deployment processes that assign those values, and those will all be vendor-specific, we defined this property to solely provide that identifier - regardless of its origin or use elsewhere...
That said, the description in the schema doesn't seem to get that point across, so we need to improve it.
Jeff
|
|