Call for Gardening Tasks

[Richard Hanley]

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> wrote:

> Hi everyone,
>
> Last week I started a thread on Open BMC Gardening
> <https://lists.ozlabs.org/pipermail/openbmc/2020-April/021100.html>, 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/9675acc0/attachment-0001.htm>