[Redfish] VirtualMedia

[Rapkiewicz, Pawel]

>> 
>> 1. Using systemd to monitor /tmp/nbd-proxy.X.sock files, and based on 
>> any change it will start nbd-client with appropriate options, like:
>> nbd-client -u /tmp/nbd-proxy.X.sock -b 512 /dev/nbdX then it will 
>> start "state_hook" script from the above commit with appropriate 
>> parameters.

> One advantage of using the nbd-proxy is that it manages the disk udev events and polls to know when to start the "state_hook".

I understand that, and definitely I'm not against using udev, I'd like to avoid limiting throughput by proxying data through one more service. 
We can write a mechanism based on core OS features (systemd/udev). I described systemd usage so far, but it can be split for systemd and udev as well. For example:

systemd:
to monitor if new /tmp/nbd-proxy.X.sock file appeared and start nbd-client accordingly

udev:
add a rule in /etc/udev/rules.d, which will watch for new nbd device attached, and start "state_hook"

The above approach seems to be right, however it limits the functionality to exposing nbd device to host only (or whatever state_hook would do in future). Since there are no others usage so far we can stick with that.

The second one described, with DBus allows more flexibility, but requires additional service on DBus.

>> 
>> 5. bmcweb calls appropriate Virtual Media DBus method,

> The first point talks about systemd monitoring the socket creation, which seems like a stand-alone service file. But here we're talking about a DBus method that theoretically would start nbd-client?

Yes the second option is to write a DBus service for spawning nbd-client, and perhaps (in future) deal with Redfish virtual media, like NFS, CIFS, etc. The DBus approach gives a little more flexibility.

>> 
>> - Can be extended (if needed) to allow mounting other types of 
>> protocols,
as described in DMTF's VirtualMedia schema (NFS, CIFS, etc) all having same DBus interface the Virtual Media Redfish

> The Redfish interface was designed to be able to mount a host from a network share rather than proxying over a websocket, that's the reason we haven't added the Redfish endpoint yet. Do you see us eventually implementing the Redfish API or just sticking with websocket implementations?

If we'd like to have Redfish as primary interface (WebUI using redfish endpoints instead of current ones) I think it's desired to implement such support. Even if current Virtual Media schemas does not cover proxying over websockets, this can be added as OEM extension. 

Regards,
Pawel
--------------------------------------------------------------------

Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN.

Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek
przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by
others is strictly prohibited.