Should Dump Offload URL be a walkable path under /redfish/v1

asmithakr
Minnow

Posts: 5

Should Dump Offload URL be a walkable path under /redfish/v1 Jul 30, 2020 6:59:34 GMT

Quote

Post by asmithakr on Jul 30, 2020 6:59:34 GMT

I have referred to the OCP Proposal for Diagnostic data where the dump offload URL was given as `redfish/v1/Systems/system/LogServices/Dump/attachment/<dump-id>`

When I used the same in my code, I have received a comment saying,

"""
Every resource under /redfish/v1/ is defined by a Redfish schema and is a walkable path, e.g. can go to /redfish/v1/Managers/ and then to /redfish/v1/Managers/bmc

Where as /redfish/v1/Systems/system/LogServices/Dump/attachment/ is not!

""
So,

1. Is the path given in the proposal a valid one?

As per the proposal, when the user fires the get request on the LogEntry, the offload URL will be obtained (which will be the above URL)
So nth level request will get the path for n+1. I felt this might justify it as a valid URL.

2. Or should we have something like 'https://${bmc}/Systems/system/LogServices/Dump/attachment/<dump-id>'?

ratagupt
Guppy

Posts: 87

Should Dump Offload URL be a walkable path under /redfish/v1 Jul 30, 2020 12:49:42 GMT

Quote

Post by ratagupt on Jul 30, 2020 12:49:42 GMT

I think what asmitha want to ask is

in the offloadURL if we define the URL like as (/redfish/v1/Systems/system/LogServices/Dump/attachment/<id>)

Here in this URL, each level is backed by some redfish schema

Systems: ComputerSystemCollection
system: computerSystem
Logservices: LogServiceCollection
Dump: LogService
Attachement: don't have the schema.

Can we have some random keyword(attachement) here in the offloadURL like above?

mraineri
Administrator

Posts: 1,132

Should Dump Offload URL be a walkable path under /redfish/v1 Jul 30, 2020 15:51:02 GMT

Quote

Post by mraineri on Jul 30, 2020 15:51:02 GMT

The URI could be under /redfish/v1. While references to URIs like this are not Redfish resources, you still might want the URI structure to include /redfish/v1. However, be careful when doing so; it's possible to accidentally conflict with a future resource URI defined by the DMTF.

We have some language in the spec regarding these types of properties (the "Non-resource reference properties" clause).

Non-resource reference properties provide a reference to services or documents that are not Redfish-defined resources. These properties shall include the Uri term in their property name. For example, AssemblyBinaryDataUri in the Assembly schema. The access protocol and data format of the referenced URI may be defined in schema for that property. Non-resource reference properties that refer to local HTTP/S targets shall follow the Redfish protocol, including use of Redfish sessions and access control, unless otherwise specified by the property definition in schema.

There is some ambiguity about the types of operations allowed on the URI from the spec, but the intent is at the very least HTTP GET would be usable on the URI, and in other cases the property itself specifies other types of operations allowed.

Last Edit: Jul 30, 2020 15:52:05 GMT by mraineri