|
|
Post by cprabhudesai on Nov 17, 2020 22:53:13 GMT
I'm trying to understand how an end user is supposed to instantiate a Fabric in a setup/system that allows such flexibility. Naturally, there needs to be a "POST"-like operation to the FabricCollection with a JSON object following the Fabric schema. What fields are required/optional while creating this new fabric instance, or updatable later, can be defined by specifying a CollectionCapabilities object. I'm going to go with an assumption that I don't need to provide an example, the section from the specification should suffice. With that understanding about Collection + CollectionCapabilities, I started to review the URIs associated with FabricCollection to confirm that the resource indeed allowed modification. It so happens that there is only a "GET" operation defined for /redfish/v1/Fabrics and insertable is false in FabricCollection schema definition, which is puzzling. Why is there a distinction between different types of Collections? (I'm sure there's a good reason, I'm simply not privy to it) If that question is too broad, maybe helping me understand how I could proceed with minimal Oem extensions would be a first step. Please forgive any gaps in understanding the specification, I'm afraid it's growing at a much faster pace than what I can perceive. Thanks, Chinmay |
|
|
|
Post by mraineri on Nov 19, 2020 20:02:41 GMT
You do have the right semantics in that if you, as a client, want to create the representation of a fabric in the service, you would make a POST request to the FabricCollection in order to describe such a fabric.
However, it's not clear to us that a client would need to have this level of control. Typically, at least from the experience we've had, services know about a fabric based on their hardware resources. This could be in the form of management connectivity to different types of switches, HBAs that connect to a fabric, or other hardware interfaces. So, clients don't need to tell a service about a fabric that might exist, but rather services should be populating this for you already based on their internal connectivity to other components. If the client has to tell the service about the presence of a fabric, it doesn't seem like the service would be able to perform any sort of management of the fabric itself.
That being said though, it's possible we don't have an understanding today of scenarios where a service doesn't know about a fabric ahead of time. Do you have a particular use case where a service needs to be told about a fabric? If so, we can certainly discuss that further in the forum to see if we should allow for a user to perform a POST to the FabricCollection resource.
|
|
|
|
Post by cprabhudesai on Nov 19, 2020 22:33:39 GMT
mraineri Thanks for getting back quickly and giving us the opportunity to explain our use case. We understand why this might be unclear, generally speaking, a fabric and the participating entities may be "discovered" during hardware bring-up so to speak by means that you pointed out viz. management connectivity etc. While it may not be common, we may have a situation where this kind of granularity of control/configurability is possible for a client. Our team is drafting some use cases that might help you understand what we are trying to tackle, please stand-by. As we understand the scope of this work and see if it makes sense to propose and add these capabilities to Redfish specification, we plan to use OEM extensions to be able to support this endeavor, it seems like the most logical step.
Here are some questions around OEM extensions (please note: we will conform to the spec for usage, examples are short for brevity) 1. We see that the FabricCollection has an Oem field which can be used, will it be "writable" even if the schema itself doesn't support modifications? (I checked the schema for Resource_Oem, it doesn't specify the supported operations) Request: GET /redfish/v1/Fabrics HTTP/1.1
Response: HTTP/1.1 200 OK
Content-Type: application/json
{
<rest_of_fabric_collection>
"Oem": {
"Contoso": {
"@odata.type": "#Contoso.Fabric"
"property1": null,
"property2": {},
"property3": [list of strings]
}
}
}
Will the following operation be legal? Request: POST /redfish/v1/Fabrics HTTP/1.1
Content-Type: application/json
{
"Oem": {
"Contoso": {
"property1": "abc",
"property2": {},
"property3": []
}
}
}
Response: HTTP/1.1 200 OK
Content-Type: application/json
{
<rest_of_fabric_collection>
"Oem": {
"Contoso": {
"@odata.type": "#Contoso.Fabric"
"property1": "abc",
"property2": {},
"property3": []
}
}
}
2. If not, would we need to use an OEM extension URI? Request: POST /redfish/v1/Fabrics/Oem/Contoso/Fabrics HTTP/1.1
Content-Type: application/json
{
"property1": "abc",
"property2": {},
"property3": []
}Response: HTTP/1.1 200 OK
Content-Type: application/json
{
"@odata.type": "#Contoso.Fabric"
"property1": "abc",
"property2": {},
"property3": []
}3. Would it be ok to use an OEM URI to accept the POST method, but have the /redfish/v1/Fabrics URI reflect the changes as well? Any help is appreciated, thanks! Best wishes, Chinmay
|
|
|
|
Post by cprabhudesai on Nov 20, 2020 18:30:02 GMT
mraineri Here when you say "services" do you mean a "Service" component within a Redfish service viz. CompositionService? or do you mean a "Redfish service" itself? Some clarification would definitely help. Thanks, Chinmay
|
|
|
|
Post by jautor on Nov 21, 2020 17:25:10 GMT
mraineri Here when you say "services" do you mean a "Service" component within a Redfish service viz. CompositionService? or do you mean a "Redfish service" itself? Some clarification would definitely help. Thanks, Chinmay Redfish describes the "public-facing" or end-user interface. The software/firmware/components implementing the Redfish Service will have numerous internal data providers or means to discover or manage the actual hardware, devices, services, etc. So "behind the scenes", its expected that those resources are populated (written/created/modified) somehow - but those details are not exposed to the end user. For a fabric, we assume that the implementation would create the Fabric resource(s) from its internal knowledge, and end-user configuration would occur at the "Zone" level (or Endpoint or EndpointGroup). If that's a bad assumption - that your hardware would allow an end-user to "create" a Fabric resource, we can re-visit that assumption. You certainly should not have to add OEM extensions to accomplish what would normally be a POST to a Resource Collection. But we'd like to understand the use cases as we want these methods to be interoperable. Jeff |
|
