[EXTERNAL] Re: Call for Gardening Tasks

Neeraj Ladkani neladk at microsoft.com
Sat Apr 11 04:16:01 AEST 2020 

My wish list 

- Documentation is a biggest gap in adoption so we should try to have clear documentation on 
	- Build
	- Dev Practices 
	- Debug 
	- Best Known Methods of debugging ( Static and Runtime) 
	- Documentation of each feature 
	- User Guide
- Boot time optimization and runtime optimization ( dbus latencies) 
- OpenBMC resiliency (bmc hang, bmc corruption etc ) 
- Package Manager- Ability to update only required services 
- BMC update tool that runs from Windows

Thanks
Neeraj


-----Original Message-----
From: openbmc <openbmc-bounces+neladk=microsoft.com at lists.ozlabs.org> On Behalf Of krtaylor
Sent: Friday, April 10, 2020 7:31 AM
To: openbmc at lists.ozlabs.org
Subject: [EXTERNAL] Re: Call for Gardening Tasks

On 4/10/20 9:23 AM, Joseph Reynolds wrote:
> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Fopenbmc%2Fdocs%2Fblob%2Fmaster%2Ffeatures.md&data=02%7C01
> %7Cneladk%40microsoft.com%7C916cecb7f02d49a69bb608d7dd5bfa4f%7C72f988b
> f86f141af91ab2d7cd011db47%7C1%7C0%7C637221259424623201&sdata=26yPC
> Yk5SPlxyj6WrHtlpchoB0mzq9AlFgb6j18Z4iA%3D&reserved=0

Heck, can we start by simply fleshing out what devs (companies) are/have worked on for this release?  ;-)
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenbmc%2Fopenbmc%2Fwiki%2FCurrent-Release-Content&data=02%7C01%7Cneladk%40microsoft.com%7C916cecb7f02d49a69bb608d7dd5bfa4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637221259424623201&sdata=2zoKeeNq3EX5qXfUhVhsf1RqHNaO399ujhERcBznENg%3D&reserved=0

- 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Fibm-openbmc%2Fdev%2Fissues%2F1531&data=02%7C01%7Cneladk%4
> 0microsoft.com%7C916cecb7f02d49a69bb608d7dd5bfa4f%7C72f988bf86f141af91
> ab2d7cd011db47%7C1%7C0%7C637221259424623201&sdata=ke66m%2FP7mUydIN
> 3ZIkEeyqa%2FROX8fwaalodOQIkIXbM%3D&reserved=0
> 
> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs
> .google.com%2Fdocument%2Fd%2F1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWm
> AOI&data=02%7C01%7Cneladk%40microsoft.com%7C916cecb7f02d49a69bb608
> d7dd5bfa4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63722125942462
> 3201&sdata=ilCVzuzeyRqDFu56ha9zXoE1%2F6mpGNK0e7YwQIuoRSg%3D&re
> served=0
> 
> 
>> -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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fur
>> ldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__lists.ozlabs.org_p
>> ipermail_openbmc_2020-2DApril_021100.html%26d%3DDwMFaQ%26c%3D5VD0RTtN
>> lTh3ycd41b3MUw%26r%3Dv9MU0Ki9pWnTXCWwjHPVgpnCR80vXkkcrIaqU7USl5g%26m%
>> 3DfAZZtmWl4g8Vngk56_Rs09hgS96TYQMeyRsyZKGHzAo%26s%3DHXdHl56jq4p5eXbhy
>> UHUkkmoF_hGh5tJWMUaVKQ68VM%26e%3D&data=02%7C01%7Cneladk%40microso
>> ft.com%7C916cecb7f02d49a69bb608d7dd5bfa4f%7C72f988bf86f141af91ab2d7cd
>> 011db47%7C1%7C0%7C637221259424623201&sdata=supFlb87zz%2FJCHbTfRkZ
>> iDs4qI63%2BitxltEnVh6RQ0s%3D&reserved=0>,
>>
>>     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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Fopenbmc%2Fopenbmc%2Fwiki%2FSecurity-working-group%23security-
> feature-wish-list&data=02%7C01%7Cneladk%40microsoft.com%7C916cecb7
> f02d49a69bb608d7dd5bfa4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C
> 637221259424623201&sdata=BnjKuY%2FHdSY9HfZhVSenKiK9L4SZ%2FD8sNiler
> wD23dU%3D&reserved=0
> 
> 
> - 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