Request to create a new repository for dbus-top

[quadpixels]

Hello Everyone,

This is a request for creating a new repository called dbus-top and migrate openbmc-tools/dbus-top there, so that we can create a BitBake recipe for it (asa currently BitBake recipes pointing to openbmc-tools are not accepted.)

The dbus-top tool is a top-like tool with a logic similar to htop, iftop, iotop, intel_gpu_top, etc. It currently displays DBus-related measurements such as number of method calls and signals per second, and also OpenBMC-related statistics, such as the number of sensors, and association edges.

The tool was used by a few people as a learning tool to understand the basics of how the OpenBMC system works, as well as for triaging certain problems encountered during development.

The tool could be helpful OpenBMC developers for as long as OpenBMC does not get rid of DBus as an IPC protocol (which may be a long time). It also has room for improvement and can be used as a playground for ncurses-based UI development, and experimenting with ideas on BMC health monitoring/metrics. Splitting this tool into a separate repository can make it easier for the above explorations and should not impact the rest of the OpenBMC system in a noticeable way.

Thanks!

[edtanous]

While I don't use the dbus-top tool myself, this request seems reasonable to me. Who would you propose as a maintainer? Ideally it would be someone with experience in maintaining OpenBMC projects in the past, but there are certainly opportunities for mentorship if you would like to do it.

(asa currently BitBake recipes pointing to openbmc-tools are not accepted

Is this true? I didn't think we had that policy, especially for debug tools that I assume wouldn't be enabled in a default image. Can you point to where you've had a recipe rejected?

[williamspatrick]

Can you point to where you've had a recipe rejected?

https://gerrit.openbmc.org/c/openbmc/openbmc/+/59690

There was also some discussion in Discord for more color:

https://discord.com/channels/775381525260664832/775381525260664836/1054876080697245786

[edtanous]

ACK. Like I said, I have no strong opinions here. Having the tool in its own repo seems fine.

[bradbishop]

I didn't think we had that policy

I wasn't aware of it either - I think it might only be a couple days old.

From what I can gather the thinking seems to be that moving it to another git repository will somehow make it get more/better quality peer review? FWIW I don't really believe that...but I'm probably not understanding the motivation correctly.

I don't think OpenBMC needs more repositories but if @quadpixels is willing to do the migration work I'll support that.

[quadpixels]

Thanks for the support! I see the support for a separate repository as a belief in the usefulness of the tool from the community's leaders. This also feels like setting an expectation that this tool should become useful enough so that it meets a certain bar. My understanding of the bar is it has to be able to "really" resolve problems.

The "problem-solving" abilities are still under exploration; In addition to showing DBus statistics, I've tried dumping the association graph, Ed mentioned on Discord the tool can verify compliance of Entity-Manager objects and their schema.

Debugging with dbus could involve more than "dbus-top"; the PCAP visualizer (dbus-vis) is also part of this effort, and personally I have been able to debug more issues using dbus-vis than using dbus-top.

Most recently I'm testing a way to obtain the DBus method calls from bmcweb associated with the processing of a given URI. I think if this works reliably, there may be a possibility to expand it into something more general - to be able to find out about the behavior of a system by looking at DBus activity alone, for example.

So in my opinion the most important question to make DBus-based methods useful is to find out methodologies we could do about DBus messages, whether it's in an on-line method in dbus-top or an offline method that looks at a pcap file does not really matter. (feels like research work?)

Being located in an OpenBMC repository has the benefit of being in proximity with the people who are familiar with and have insight into the OpenBMC components that make use of DBus. I would imagine when doing a code review, I'll try to make sure the tool runs normally on a BMC, as well as reach out to people who could comment on the data measured by the tool.

[williamspatrick]

Looks like this is approved.

@bradbishop - can you do the work to create the repo?
@quadpixels - Who will be the maintainers of this repo?

[quadpixels]

Hmm I guess, as a public repository, it is now in the same arena as everything out there (on the internet) that aim at "goodness / coolness / usefulnes" that is universally applicable. So I collected some thoughts based on the coolest & most hard-core things I heard related to OpenBMC . . .

Some thoughts:

• amboar mentioned "we need something like Tokio Console". My take on this point is, Tokio Console sets a good example for UI design we can start working towards immediately (being written in and for Rust is another point of interest)
• This tool (and also the PCAP visualizer) has referened "dbus_pcap" a lot.
• Rust is one of the coolest things in OpenBMC and may be in Linux too.
  • As a low-risk repository, this repository may serve as a "playground" for experiments with Rust?

So I think @amboar is in a good position as a maintainer because AmBoar is familiar with all the items above, especially, amboar authored dbus_pcap.

I think anyone who works on OpenBMC can have their insights on the usefulness of this tool, and I will be willing to learn from any person showing interest and expressing comments regarding this repository.

[williamspatrick]

I'm not sure I understand the Rust angle here.

If the intention is to port the existing code to Rust either prior to converting to the new repo or soon afterward, I will definitely change my vote. We need to have a bigger discussion on how to start incorporating Rust because it isn't entirely as straight-forward of just using rustc or cargo.

It seems like @zevweiss is probably spearheading some of this (based on the mailing list post). I suggest working with him if you have an interest in seeing Rust leveraged in OpenBMC also, but this should be kept independent of putting the existing dbus-top code into a separate repo in my opinion.

I am fine with @amboar and @quadpixels being co-maintainers of this new repo, if @amboar is willing.

[quadpixels]

Thanks for clarifying, I realize I accidentally stepped on a topic that is beyond my level, as I don't know about Rust or OpenBMC enough to cast influence on the community's technical direction regarding adopting Rust, and I have no intention to do so with this repository at all.

I mentioned Rust only because I see it as related (although a bit remotely related). I think Tokio Console's UI looks cool, Rust is cool, and if we deliver a dbus-top that also looks cool and useful and liked by users, that will also be cool. That is all I wanted to express from the Rust angle.

I agree that to use this repository in a responsible way and do a good service to the community, we should port existing dbus-top code to it, fix existing bugs, and polish it.

[amboar]

I can help maintain it and try to provide advice on direction and such. I don't expect to have capacity to actually work on it.

[bradbishop]

@bradbishop - can you do the work to create the repo?

done! Please push an OWNERS file.

[quadpixels]

Can I ask a beginner-level question: who would the owner be (that comment above says I and amboar are "co-maintainers", so it sounds like the owner is someone else)

After knowing who the owner is I can work on an OWNERS file. Thanks!

[amboar]

No, we will be the owners. Just list both of us in the OWNERS file.

[williamspatrick]

I believe this is resolved.