|
|
Post by kapil1024 on Sept 27, 2021 17:21:33 GMT
Redfish Schema Supplement DSP0268 2021.2 - Section 6.115 VirtualMedia 1.5.0
There is a new property "VerifyCertificate" under section "6.115.3 Properties" but, unlike many other properties, it is not part of "6.115.4.2 InsertMedia". Is it intentional?
It requires two Redfish operations with current schema to set "VerifyCertificate" property and perform "InsertMedia" action.
|
|
|
|
Post by mraineri on Sept 27, 2021 18:47:57 GMT
Yes, that's intentional. It's very likely that one type of user will be setting up certificates an policies for a service, which might include configuring the certificates that are acceptable when mounting remote media. Then, another user who is performing one-time boot, deploying workloads, or attaching other types of data to a system would need to insert and eject media as they see fit for their day-to-day operations, and would be relying on the policies already configured rather than recreating them on each insert operation.
|
|
|
|
Post by kapil1024 on Sept 28, 2021 4:16:51 GMT
Does it mean that "/redfish/v1/Managers/{ManagerId}/VirtualMedia/{VirtualMediaId}" has to support a PATCH method in order to modify "VerifyCertificate" property?
I believe it is equally possible that user want to set this property along with Insert operation. System/Manager can pick persistent value (i.e. 6.115.3 Properties) if not provided as part of Insert operation.
|
|
|
|
Post by kapil1024 on Sept 30, 2021 8:18:23 GMT
Another query on VirtualMedia: redfish.dmtf.org/schemas/v1/VirtualMediaCollection.json contains below list of possible URIs - "/redfish/v1/Managers/{ManagerId}/VirtualMedia", "/redfish/v1/Systems/{ComputerSystemId}/VirtualMedia", "/redfish/v1/CompositionService/ResourceBlocks/{ResourceBlockId}/Systems/{ComputerSystemId}/VirtualMedia", "/redfish/v1/ResourceBlocks/{ResourceBlockId}/Systems/{ComputerSystemId}/VirtualMedia" but redfish.dmtf.org/schemas/v1/CertificateCollection.json doesn't list URIs corresponding to "/redfish/v1/Managers/{ManagerId}/VirtualMedia" e.g. "/redfish/v1/Systems/{ComputerSystemId}/VirtualMedia/{VirtualMediaId}/Certificates", "/redfish/v1/Systems/{ComputerSystemId}/VirtualMedia/{VirtualMediaId}/ClientCertificates", "/redfish/v1/CompositionService/ResourceBlocks/{ResourceBlockId}/Systems/{ComputerSystemId}/VirtualMedia/{VirtualMediaId}/Certificates", "/redfish/v1/CompositionService/ResourceBlocks/{ResourceBlockId}/Systems/{ComputerSystemId}/VirtualMedia/{VirtualMediaId}/ClientCertificates", "/redfish/v1/ResourceBlocks/{ResourceBlockId}/Systems/{ComputerSystemId}/VirtualMedia/{VirtualMediaId}/Certificates", "/redfish/v1/ResourceBlocks/{ResourceBlockId}/Systems/{ComputerSystemId}/VirtualMedia/{VirtualMediaId}/ClientCertificates", |
|
|
|
Post by mraineri on Sept 30, 2021 12:29:21 GMT
The reason for that is the usage of VirtualMedia under Manager was deprecated in favor of ComputerSystem. The reason being is while the virtual media support is exposed by the manager, it's all tied to a computer system and to an end user they're trying to mount media on a given system.
The thought was since the addition of certificates is new and requires changes on the service to support, we'd like to encourage folks to migrate to the preferred path for virtual media. However, if there's a need to support certificates in the deprecated location for virtual media, we can raise that to the group.
|
|
