Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFE] Add rootless container log collection to podman plugin #3596

Open
robbmanes opened this issue Apr 15, 2024 · 1 comment
Open

[RFE] Add rootless container log collection to podman plugin #3596

robbmanes opened this issue Apr 15, 2024 · 1 comment

Comments

@robbmanes
Copy link
Contributor

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
Copy link
Member

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants