Call for Gardening Tasks

Vijay Khemka vijaykhemka at fb.com
Fri Apr 10 08:19:59 AEST 2020


I can see following small tasks which need refactoring

IPMID:
Some of standard commands are incomplete here like “restore power policies”, some of sensors  sdrs etc.

Dbus interface:
Define more dbus interfaces being used in common code. I see multiple repos has these interfaces hard coded. And I agree for client side code would really be helpful.

Phosphor package clean up:
There are many phosphor packages in image which are added by default and lots of systemd unit are running irrespective of platform requirements.

Documentation:
Many repos doesn’t have proper documentations and it will be really good to add and a root level documents giving an idea about different features and mapped to multiple available repos.

I will add more once I remember back.

Regards
-Vijay

From: openbmc <openbmc-bounces+vijaykhemka=fb.com at lists.ozlabs.org> on behalf of Richard Hanley <rhanley at google.com>
Date: Thursday, April 9, 2020 at 2:57 PM
To: OpenBMC Maillist <openbmc at lists.ozlabs.org>
Subject: Re: Call for Gardening Tasks

Here are some ideas I have as a wishlist for gardening/improvements.

Client Models for DBus
Right now sdbusplus does a pretty good job of making server development easy.  However, I wish we had some more tooling on the client side. I see a decent amount of repeated code around ObjectMapper.

One way to separate concerns and cut down on boilerplate is to have a model library. A call to a model would spin off an async method call to manage the data marshalling, which would then call a lambda with a fully reified object.  This is similar in concept to the way models work in web development.

Unit Testing in bmcweb
This is pretty easy to say, and harder to do. I've been thinking a bit about how to add in unit tests without them being too fragile. (This was also something that geissonator mentioned).

DBus Virtualization and Playback
One thing that I think makes unit testing in some modules hard is that there is a high barrier around mocking DBus.  I'm not sure the best way to build this sustainably, but it would help improve our CI testing.

OpenAPI for Redfish
So far the general impression I've seen with this is that the Swagger output for OpenAPI isn't really good for C++.  Either the ergonomics aren't really good, or there is a lot of code bloat.  I'd love to have some OpenAPI bindings that work well in OpenBMC.

RUST!?!?
I'm betting a lot of people have thought about Rust. I'd love to hear what people have tried and what are the sticking points.  Any thoughts on what module/functionality could be a decent candidate for breaking ground here?

-Richard

On Thu, Apr 9, 2020 at 2:54 PM Richard Hanley <rhanley at google.com<mailto:rhanley at google.com>> wrote:
Hi everyone,

Last week I started a thread on Open BMC Gardening<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.ozlabs.org_pipermail_openbmc_2020-2DApril_021100.html&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=v9MU0Ki9pWnTXCWwjHPVgpnCR80vXkkcrIaqU7USl5g&m=fAZZtmWl4g8Vngk56_Rs09hgS96TYQMeyRsyZKGHzAo&s=HXdHl56jq4p5eXbhyUHUkkmoF_hGh5tJWMUaVKQ68VM&e=>, and I wanted to kick off the process.

The basic idea here is to get a survey of various improvement tasks throughout OpenBMC.  Some things might be small refactoring or changes that can be done incrementally (i.e. weeding the garden). Other tasks might be more research or structural (i.e. excavating the garden).

Just getting these in writing can be helpful for others to gauge what they should focus on. It also helps leave breadcrumbs for any new developer interested in the subject.

So here's how I see this working. Anyone who has some ideas can reply to this thread with a short to medium description.  Try to avoid new features, and instead look at ways we could improve the status quo. Think about changes and tools that would make your day to day life better.

From there we can do a write up about what we know about the issue.  This can function as an early stage design doc that gives a broad overview on where the dev's head is at right now.

Finally, we can do a quarterly review to keep the garden refreshed. Obviously, things can change between that time, but having a semi-regular cadence will hopefully give us a better chance of keeping this up to date.

- Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200409/2571b426/attachment.htm>


More information about the openbmc mailing list