Call for Gardening Tasks
Joseph Reynolds
jrey at linux.ibm.com
Sat Apr 11 00:23:17 AEST 2020
On 4/9/20 5:19 PM, Vijay Khemka wrote:
>
> 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.
>
Can we flesh out the list of features?
https://github.com/openbmc/docs/blob/master/features.md
The openbmc/docs repo has good stuff for developers. Can we take it the
next level by adding:
- Guide for system integrators - source and build config, signing keys, etc.
- Guide for initial BMC setup - genesis boot, discovery, configure IP,
certs, users, etc.
- Guide for system admins - ongoing tasks like auditing logs, firmware
updates, etc.
- Security technical implementation guide (STIG).
We've discussed these in the OpenBMC security working group, and I've
collected some details here:
https://github.com/ibm-openbmc/dev/issues/1531
I would be happy to contribute to these ... just looking for someone to
collaborate with. :-)
> 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?
>
We discussed the rust language in the OpenBMC security working group
meetings 2019-10-02
OpenBMC security working group minutes:
https://docs.google.com/document/d/1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI
> -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.
>
Richard,
Thanks for your efforts to move this forward.
Security wish list here:
https://github.com/openbmc/openbmc/wiki/Security-working-group#security-feature-wish-list
- Joseph
> 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
>
More information about the openbmc
mailing list