Call for Gardening Tasks

[Vijay Khemka]

On 4/10/20, 11:02 AM, "openbmc on behalf of James Feist" <openbmc-bounces+vijaykhemka=fb.com at lists.ozlabs.org on behalf of james.feist at linux.intel.com> wrote:

    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.

Yes I agree, we may also need to add some basic automation testing in CI.
    
    >>>
    >>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI&d=DwIDaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=v9MU0Ki9pWnTXCWwjHPVgpnCR80vXkkcrIaqU7USl5g&m=MqzeHbAdDCDQPPqxtL2sbM9gBlKXoGdiz5hj06g1We8&s=gWsiuACR8FSiP_Fmoa1yO1h3IoDH42VkUE6pUOZqRTA&e=  
    >>
    >>
    >>> -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
    >>>
    >>
    >