|
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".
|
|
|
Post by mraineri on Apr 17, 2024 23:30:51 GMT
This topic was brought up on our tools that perform schema conversions here: github.com/DMTF/Redfish-Tools/issues/464. With the new tool changes, future publications will better handle cases where a $ref is used in addition to "nullable". This doesn't address the "readOnly" observation though. However, although the property is marked as read-only, Redfish's usage of this annotation has only applied to PATCH operations; RAIDType cannot be modified after a Volume is created, but can be specified when a user is creating a Volume via POST. The schema languages originally used by Redfish had a bit more interpretation to the permissions term than OpenAPI, and we likely did not read into this detail too much when adopting OpenAPI definitions. We may need to discuss this further internally to see if we need to adjust our schema tools to account for this expectation in OpenAPI, but our intent is to limit the usage of readOnly with regards to PATCH operations.
|
|
|
Post by mraineri on Apr 17, 2024 14:56:25 GMT
|
|
|
Post by mraineri on Apr 16, 2024 17:10:47 GMT
If the URI is working in the browser with the credentials you're supplying, then it looks like an issue with the plugin for ManageIQ itself (or at least with how it's being configured). Unfortunately I haven't worked with ManageIQ myself, so I'm not sure where to poke next... I'll ask around to see if I can find anyone who has used that tool before...
|
|
|
Post by mraineri on Apr 16, 2024 12:51:41 GMT
In that case, you'll just return "AuthenticationTokenRequired" to tell the client they need to supply the extra token.
One thing to note is in the service-generated onetime passcode, it'll return both the "AuthenticationTokenRequired" and "OneTimePasscodeSent"; the first message is always used to tell the client to provide the "Token" property, and the second message here is specific to telling the client to check their email for the token.
|
|
|
Post by mraineri on Apr 15, 2024 14:33:33 GMT
You don't need to link anything in the AccountService schema. The usage of "@odata.type" in the response payload is the linkage needed to map to a schema file; "#ContosoRoleMapping.v1_0_0.RoleMapping" tells the tool to look through all schema files for the "ContosoRoleMapping.v1_0_0" namespace for the "RoleMapping" definition. Likewise, other tools that are schema-aware will key off the "@odata.type" property to perform that schema lookup, so it's never necessary to modify standard schemas to insert any type of linkage.
Are you able to attach the full text file? I'd like to see earlier portions of the text file that would show it stepping through and parsing the schema files.
|
|
|
Post by mraineri on Apr 15, 2024 14:05:43 GMT
1) No, this only applies when a user supplies only "UserName" and "Password", and the MFA configuration is to generate onetime tokens in response to the login attempt. This is like when you log into your bank's website and it prompts you for a token they just sent to you via text or email.
2) Correct; you can have this enabled in a ManagerAccount resource and email the user without having any LDAP/AD configurations.
3) Yes, but it's conditional on whether it's configured with the lead-in "When a multi-factor authentication type that requires tokens is enabled". It's not required to support the capability. The same is true with the email usage with the lead-in "if the multi-factor authentication type uses a service-generated onetime passcode". This is also an optional capability, but the behavior is mandatory if you support it and the user has it enabled.
|
|
|
Post by mraineri on Apr 15, 2024 11:11:06 GMT
Why is your BMC a Chassis and not a Manager? BMCs are traditionally modeled as Manager resources.
I assume "Erot" is some "root of trust"; why is this it's own Chassis and not something like the "TrustedComponent" resource?
Regardless of the answer to the modeling questions, what you're highlighting is an issue that every aggregator needs to solve. Some aggregators cache resource trees and response bodies locally so they do not have to query downstream devices as often. The method you use is ultimately going to depend upon your aggregator's design and accounting for any limitations with the devices you're aggregating (such as if you can rely on event notifications for resource changes).
|
|
|
Post by mraineri on Apr 11, 2024 14:16:10 GMT
For FW Update: "Targets" is the right thing to use here. That gives the user the control to specify an exact device to update if they do not want the service to automatically pick the "right" devices. This would be the URI of the resource representing the device (like /redfish/v1/Managers/BMC5). We have the following in the long description for Targets to call out some expected behaviors:
> These targets should correspond to software inventory instances or their related items. If this parameter is not present or contains no targets, the service shall apply the software image to all applicable targets, as determined by the service. If the target specifies a device resource, the software image file shall be applied to the specified device. If the target specifies a resource collection, the software image shall be applied to each applicable member of the specified collection. If the target resource specifies an Aggregate resource, the software image file shall be applied to each applicable element of the specified aggregate. If the target resource specifies a ComputerSystem resource, the software image file shall be applied to the applicable components within the specified computer system.
For FW Inventory: You'd need to grow the members of the FW inventory collection. It's a flat list of everything known to the service. So, I would expect URIs like "/redfish/v1/UpdateService/FirmwareInventory/BMC5".
For Tasks: It would be the responsibility of the aggregator to instantiate a task for itself and internally track the task of the satellite BMC. From the external user's perspective. This would be rolled up under /redfish/v1/TaskService/Tasks like every other task for the aggregator.
|
|
|
Post by mraineri on Apr 11, 2024 14:03:01 GMT
Are these new schema files populated in the local directory where the tool caches schema files? It should be in "./SchemaFiles/metadata".
If they're there, can you add "--debugging" to the CLI for the tool and provide the text log file?
|
|
|
Post by mraineri on Apr 10, 2024 19:12:35 GMT
I think you're right... I'll raise it to discuss further.
|
|
|
Post by mraineri on Apr 10, 2024 13:38:36 GMT
You do not need to define an entity like that. You only need to do that if you're making an OEM resource.
Since the prefix of the action name is "Contoso_ABC_ComputerSystem", then it would be in a namespace called "Contoso_ABC_ComputerSystem".
There is a full example of how to define this in the public-oem-examples mockup. The "/redfish/v1/AccountService" resource has an example "AutoConfig" OEM action, and the schema definition is found in Contoso.com/ContosoAccountService_v1.xml.
|
|
|
Post by mraineri on Apr 10, 2024 13:34:00 GMT
If you're using an action, then it would be a POST operation. All actions are performed via POST operations, and you can specify requirements for the request body with action parameters.
|
|