Virtual Media upstream status.

[Ed Tanous]

On Fri, Apr 29, 2022 at 1:42 PM Hawrylewicz Czarnowski, Przemyslaw
<przemyslaw.hawrylewicz.czarnowski at intel.com> wrote:
>
> Hi.
>
> In response to Ed's request, I started this topic to discuss upstreaming activities (to both existing and new code). And to make update seamless and effective.
>
> As service upstream is little stalled waiting for UT to be completed (almost completed), I wanted to attack the problem from another surface. I've pushed bmcweb patches as it got old since first submission.
>
> There are two blocking problems I am aware of in current nbd_proxy code. First is that compilation fails. The second is a race appearing sometimes during disconnection. But those are the simple ones.
>
> There is more to rework for redfish part. There are two patches
> * Make status of InsertMedia action consistent (I29d53483) https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/53343/1
> * Apply async dbus API (I1d016126) https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/53345/1
>
> First one addresses simple problem with inconsistent responses from rest api calls connected with actions. Proxy mode does not support InsertMedia action, but is implemented for legacy so response has to be applied accordingly. It has been fixed with some code generalization.
>
> The second one applies latest design changes (https://github.com/openbmc/docs/blob/master/designs/virtual-media.md, dbus communication part).
>
> Those are must-have changes to work with the service state we upstream at the moment.
>
> After service upstream is completed changes removing nbd_proxy option in meson has to be reverted as the last part.
>
> No more activities are planned now from out side, but later on we may focus on adding privileges support for websockets (AFAIK it is not supported on level of web server yet).

Great to hear from you!  You mention a lot about the bmcweb-side
changes, which are a pretty minor part (I just merged 2 of the 4
patches), and I'm happy to review them.  The part that interests me is
the backend daemon upstreaming to make this feature useful and
testable outside of the Intel tree;  When would you expect that to
occur?  Will it be an incremental update to jsnb?

In terms of bmcweb, there's currently two implementations, the jsnb
targeted one, and the one you're working on above.  Is there any
reason to keep the jsnb one once this new daemon has been updated?

The design doc referenced above is about 3 years old at this point,
are there any design updates that need to happen, or is it still
relatively accurate?

I'm glad to have someone working on it.  If you need quicker response
times to short-run things, most of the maintainers and myself are on
Discord, and would be happy to help you work through the specifics of
the patches needed to get this in.


>
> --
> Best regards,
> Przemyslaw Czarnowski