[RFE] Add rootless container log collection to podman plugin

[robbmanes]

Currently, you can either do -k podman.logs to get root container logs, or you can do containers_common.rootless_user=$USER to run rootless machinectl based podman commands, but you can't do both; there's no current way I know of to get rootless container logs from podman at this moment via sos report.

We probably need to add iteration over the found containers in https://github.com/sosreport/sos/blob/517e8315479cf86af734dfcda01cbc5574cc32cf/sos/report/plugins/containers_common.py to allow for this if the user adds something like containers_common.logs=true. I don't have immediate time to work on it so I didn't just file a PR but figured I'd add this is an RFE for my backlog.

[TurboTurtle]

Yeah, in the current design it would go into containers_common, but I've also thought for a while this could use another once-over in terms of design.

It's not obvious at the moment that containers_common is used for this sort of collection, and it'd be undeniably a more expected experience that, for example, the podman plugin collects podman logs and commands for non-root users.

What do we think about folding containers_common into their "base" plugins? We'd still have to leverage machinectl afaik, and then decide if we want to make the rootlessusers option (or something similar) repeated across these plugins, or expose it via a top-level option (which might have some future implications?). When we first created containers_common, we decided we didn't want to duplicate the options in the name of user experience, but we've had some time with the current posture so I'm wondering if we have any feedback on that being the right or wrong call yet? @robbmanes anything from sbr-containers in terms of preference here?

[TurboTurtle]

Now that we have #3648 should we break apart containers_common to allow the individual plugins to do their rootless collections natively?

We could make a report-level --rootless-users (or whatever) option instead of doing this at the plugin level so that we maintain the "one option sets it everywhere" posture that we currently have by way of centralizing the rootless collections (though, with some additional work we could allow the global option to be used, with plugin-specific options to do overrides like we have for plugin timeouts?).

@arif-ali @robbmanes @pmoravec thoughts?

[pmoravec]

I like the idea, esp. the "global option overriden-able by plugin one, likewise timeout". Just I am unsure on some details:

• originally, I thought we might get e.g. container IDs alongside with container runtime and similarly like network devices (i.e. extend _check_container_runtime (https://github.com/sosreport/sos/blob/main/sos/report/__init__.py#L182) to get list of containers, incl. managed by individual users). BUT as this list can be overriden by plugins independently, it would be difficult to "merge the plugins specs" at this early stage. But maybe Report class can keep mapping user->plugins that is iterativelly built by individual plugins ad hoc? Or each plugin will inspect containers for "its" users independently on others?
• Having --rootless-users(*) set to foo,bar and -k aap_containerised.rootless-users=bar,qux, what users the plugin should override to? Union (foo,bar,qux) or override (bar,qux)?

(*) I know it is an example WIP name, but I feel it is confusing. It lacks "container" info in its name. BUT container-rootless-users is terribly long though I see no shorter option..?