|
Post by mraineri on May 17, 2024 12:23:52 GMT
You'd still get a single task; there's no way in Redfish to spawn multiple tasks from a single operation.
If you really do need to break down the management to have a different task per target, then you could use "SubTasks" to express this (or "Steps" in the Job resource if you transitioned to a Job as part of the flow). However, the client's handling will always stem from the the root task or job, so it's important to surface all relevant messages from the sub tasks or steps.
|
|
|
Post by mraineri on May 16, 2024 12:56:47 GMT
The statement in the spec is a "should" (recommendation), so no it's not a "must". What you have today is legal.
However, we recommend adding the OEM identifier in the URI to avoid potential URI collections if another company implements an OEM action with the same name.
|
|
|
Post by mraineri on May 14, 2024 12:32:47 GMT
"/redfish/v1/UpdateService/Actions/UpdateService.SimpleUpdate" is correct; we'll need to fix the examples in the white paper. Thanks for catching this.
|
|
|
Post by mraineri on May 12, 2024 21:45:48 GMT
EventDestination would be what you use; like when subscribing to any other events from the BMC, you would create an EventDestination resource by performing a POST to /redfish/v1/EventService/Subscriptions. There are properties in EventDestination that you would set in the POST request to specify syslog, primarily the usage of:
- "Destination" to express a syslog server receiving the notifications
- "SubscriptionType" to indicate syslog
- "Protocol" to specify why type of transport for syslog (TLS, TCP, UDP, or RELP)
- "SyslogFilters" to control what notifications are sent
{ "Destination": "syslog://192.168.1.50:514", "Context": "Syslog Example", "Protocol": "SyslogTCP", "SubscriptionType": "Syslog", "SyslogFilters": [ { "LogFacilities": [ "Kern", "User" ], "LowestSeverity": "Warning" } ] }
|
|
|
Post by mraineri on May 11, 2024 22:15:01 GMT
This is supported in the standard today. For example, if you were to use the following query in a GET request...
/redfish/v1/Systems?$filter=SystemType eq 'Physical'&$expand=.
The expected response would be an expansion of the ComputerSystemCollection with only members whose "SystemType" equals "Physical".
Do you have samples of what you're trying to do and what response you're getting? If you're doing something like above and not getting expected results, then that would indicate a bug in the service that should be raised with the system vendor.
|
|
|
Post by mraineri on May 7, 2024 12:57:29 GMT
We decided it was extraneous to do so when giving guidance on how to construct the URI for ActionInfo on a particular action. "Actions" is reserved in Redfish, so there is no risk of collision since it cannot be used beyond the containment for Redfish action representation.
|
|
|
Post by mraineri on May 3, 2024 12:16:33 GMT
It's for when the entire task is complete. "Pending" is not a completed state for a task, thus TaskStatus is not expected to be present.
Effectively the only times you can have TaskStatus present is if the state is Completed, Killed, Exception, or Cancelled.
|
|
|
Post by mraineri on May 3, 2024 12:06:36 GMT
> How do I know whether my BMC supports credential bootstrapping over IPMI?
Unfortunately that's a detail we leave to system vendors to solve. The rationale is the UEFI implementation for a system will have a-priori knowledge about the platform (and BMC) given the tight coupling in development.
|
|
|
Post by mraineri on May 1, 2024 13:16:36 GMT
I see another mistake. In your ContosoLDAPService schema file, you're defining the ComplexType object with the name "ContosoLDAPService", but @odata.type contains "#ContosoLDAPService.v1_0_0.LDAPService". You'll need to do one of the following:
- Change @odata.type to "#ContosoLDAPService.v1_0_0.ContosoLDAPService"
- Change the ComplexType name to "LDAPService"
|
|
|
Post by mraineri on May 1, 2024 12:53:03 GMT
The general starting point for everyone is to look for the SMBIOS Type 42 structure that advertises the Redfish host interface. From there, you can learn two things:
- The physical device used for the network interface to the BMC
- IP address info about the BMC
- If the BMC supports credential bootstrapping over IPMI
If the BMC supports credential bootstrapping over IPMI, that gives you a generic method to fetch temporary Redfish credentials. If not, then you'll need non-standard methods to determine how to authenticate with your BMC when using Redfish (if it even requires authentication over the host interface).
After that point, it's a matter of loading an appropriate device driver to enable the network interface to the BMC, and using the discovered IP information to initiate HTTP traffic.
The context for where this is supported is really up to your environment. As long as UEFI initializes the SMBIOS information, you can follow this process wherever you'd like.
|
|
|
Post by mraineri on May 1, 2024 12:42:57 GMT
Are you able to supply an If-Match header with redfishtest? I see in the curl output "If-Match" was added; I'm actually not sure how the curl command automatically added If-Match (I've always needed to manually include it). I'm wondering if your service is requiring the ETag to be sent in the If-Match header for the request.
|
|
|
Post by mraineri on Apr 29, 2024 13:01:37 GMT
Does the debug log contain the HTTP request headers and request body?
What's the output of the following curl command?
curl -k -u Administrator:oldPassword12 -X PATCH https://X.X.X.X/v1/AccountService/Accounts/1 -H "Content-Type: application/json" -d "{ \"Password\": \"newPassword24\" }"
|
|
|
Post by mraineri on Apr 25, 2024 11:47:48 GMT
The difference is $skiptoken is an opaque token that the service generates to track collection pages from client requests. It's entirely up to you if you want to use a skiptoken versus echoing other query parameters the client used in the next page link; both would behave identically. How you generate it and track it internally is entirely up to you. For example, the client's original request could be something like... GET /redfish/v1/SomeCollection?$filter='Color' eq 'Red' In the response, the next page link might contain "/redfish/v1/SomeCollection?$skiptoken=213498732549". When the client then performs "GET /redfish/v1/SomeCollection?$skiptoken=213498732549", it'll go to the next page for the original "GET /redfish/v1/SomeCollection?$filter='Color' eq 'Red'" request. Here are some useful links to how it works in pure OData environments, which is where this is derived: * learn.microsoft.com/en-us/odata/webapi/skiptoken-for-server-side-paging* community.sap.com/t5/technology-blogs-by-members/difference-between-skip-and-skiptoken-in-odata/ba-p/13560047
|
|
|
Post by mraineri on Apr 24, 2024 0:14:23 GMT
Thanks for catching that; it looks like it's just a description issue to me rather than an issue in the schema type definition. I'll raise this for others to review to see if they agree.
|
|
|
Post by mraineri on Apr 19, 2024 12:33:02 GMT
Well this certainly took me a while to see... There's a spelling error in your namespace for the RoleMapping extension:
<Schema xmlns="http://docs.oasis-open.org/odata/ns/edm" Namespace="ContososRoleMapping.v1_0_0">
should be
<Schema xmlns="http://docs.oasis-open.org/odata/ns/edm" Namespace="ContosoRoleMapping.v1_0_0">
(There's a stray s between Contoso and Role).
And the last issue appears to be due to the lack of schema definition for "ContosoAccountService.v1_0_0".
|
|