Virtual Media upstream status.

[Czarnowski, Przemyslaw]

On 30.04.2022 00:52, Ed Tanous wrote:
> 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?
Still working internally on UT's requested, unfortunately VM is not top 
priority feature here. But trying best to put the work forward.

> 
> 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?
New deamon will replace old one, this has been settled in other email 
thread.

> 
> 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?
Service being upstreamed, besides some bug fixes, is quite stable at the 
moment. Quite recently async dbus interface has been added. No more 
suggestions from our side.

> 
> 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.
I am aware of discord byt lurking mostly so far, trying to catch and 
answer VM questions. Thanks for letting me know.

> 
> 
>>
>> --
>> Best regards,
>> Przemyslaw Czarnowski


-- 
Best regards,
Przemyslaw Czarnowski