Call for Gardening Tasks
James Feist
james.feist at linux.intel.com
Sat Apr 11 04:00:48 AEST 2020
On 4/10/2020 7:30 AM, krtaylor wrote:
> On 4/10/20 9:23 AM, Joseph Reynolds wrote:
>> On 4/9/20 5:19 PM, Vijay Khemka wrote:
I'd really like to see clang-tidy or other checks for style added into
the build CI. The number of style violations waste lots of time in
code-review for both the submitter and reviewers.
>>>
>>> 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
>
> Heck, can we start by simply fleshing out what devs (companies) are/have
> worked on for this release? ;-)
> https://github.com/openbmc/openbmc/wiki/Current-Release-Content
>
> - krtaylor
>
>>
>> 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