Bug 2181347
| Summary: | sos dnf cleanup 2.0 | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | jcastran |
| Component: | sos | Assignee: | Pavel Moravec <pmoravec> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Supportability QE <supportability-qe> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 8.7 | CC: | agk, jcastillo, jjansky, plambri, sbradley, theute |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | sos-4.5.4-1.el8 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2023-06-27 14:10:00 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
> but can we just symlink things like dnf/dnf_repolist to yum/yum_repolist? No, plugins cannot write content outside of their own private plugin subdirectory. This is an integral part of the plugin API. > The list commands don't make changes. We don't need an extra "--assumeno" here. There is no prompt. Ack, we can drop this option if it's causing issues. IIRC this is/was a holdover from the very early days of the `yum` plugin and we've just carried it forward for years. > `dnf_--assumeno_list_installed_dnf` is already grabbed by `dnf list installed`, we're just duplicating efforts here. My understanding is that this was meant to be a useful at-a-glance reference for dnf plugins (or, earlier, yum plugins). If that's not the case we can likely drop this collection. We'll want to make sure that there's no automation looking at this though. But we merged yum into dnf. > That is why we merged the plugins into one: https://github.com/sosreport/sos/pull/2903 (plus a few further pieces from former yum plugin were added to dnf plugin, like https://github.com/sosreport/sos/pull/3031). All of these should be in sos-4.4-4 which is the release candidate for 8.8/9.2 . Let me know if something is missing there. So wouldn't that theoretically mean that dnf owns yum as well? Anyways I figured it was a long shot. My immediate reaction upon seeing yum was missing was that yum was broken or the plugin was skipped. Its just moving data we used to have somewhere else just puts a pause on finding it. > Ack, we can drop this option if it's causing issues. IIRC this is/was a holdover from the very early days of the `yum` plugin and we've just carried it forward for years. I would appreciate it. Looks like it was added in 8.2 and I never really knew why https://github.com/sosreport/sos/pull/2091. Just to really try and fight for my yum/dnf complaint. This means that as we look at RHEL 8 sosreports, its different between versions of sos which is a real pain when comparing things. 8.7 and below (the majority) will all have yum and dnf and different commands in both latest 8.7 and later will have only dnf (In reply to jcastran from comment #3) > Just to really try and fight for my yum/dnf complaint. This means that as we > look at RHEL 8 sosreports, its different between versions of sos which is a > real pain when comparing things. 8.7 and below (the majority) will all have > yum and dnf and different commands in both > > latest 8.7 and later will have only dnf I understand the your complaint. On the other side, the package manager for RHEL8 is dnf and any related diagnostic information should be found under that plugin / dir - despite the legacy yum -> dnf symlink. Moreover, *adding* *back* the yum plugin - to upstream to prevent the "UX regression" - would make a little sense - now there is no reason for such plugin, over there. We are usually very conservative in removing legacy stuff from sos, where we - usually - rather collect more deprecated data than stop collecting something that is still supported on a close-to-EOL system. We should apply this conservative approach also to merging plugins (if/once that happens next time). Anyway the --assumeno option is worth to remove when applicable (there *are* dnf subcommands where it does matter). Do you agree with reverting back exactly the https://github.com/sosreport/sos/pull/2091/files ? I think all those subcommands should not wait for human interaction any time. (In reply to Pavel Moravec from comment #4) > Anyway the --assumeno option is worth to remove when applicable (there *are* > dnf subcommands where it does matter). Do you agree with reverting back > exactly the https://github.com/sosreport/sos/pull/2091/files ? I think all > those subcommands should not wait for human interaction any time. Kindly re-requesting this needinfo where it should be safe to remove --assumeno option. I think that reverting that commit would remove the assumeno's without impacting the commands. Reading the submitters comment, do we know if they had any use case or examples of such an interaction? I am also not aware of any interactive input needed ~ dnf could wait for some interactive input from a user. Use --assumeno, to keep going without modifying dnf's state. ~ https://github.com/sosreport/sos/pull/3211 raised for the two changes: 1) --assumeno option removal 2) "dnf list installed *dnf*" cmd removal Hello, this bug is assumed to be fixed in errata https://access.redhat.com/errata/RHBA-2023:3801 so I am closing this BZ as fixed in current release. If you feel otherwise, please reopen the BZ and provide details what is missing. |
The sos_commands directory includes unnecessary options and commands we dont need. Support is looking at r6, r7, r8 and r9 sosreports and the unnecessary options and slight adjustments makes for a real pain to just jump in and look at data we want to see. 1. We got rid of sos_commands/yum. I understand we're moving towards dnf being its own thing but can we just symlink things like dnf/dnf_repolist to yum/yum_repolist? Would be great if we could have it look like this: ~~~ # for i in $(ls sos_commands/dnf/); do ln -s ../dnf/$i sos_commands/yum/$(echo $i |sed 's/dnf/yum/g');done # tree . ├── dnf │ ├── dnf_-C_repolist │ ├── dnf_-C_repolist_--verbose │ ├── dnf_history │ ├── dnf_list_extras │ ├── dnf_list_installed │ ├── dnf_module_list │ ├── dnf_module_list_--installed │ ├── dnf_--version │ ├── package-cleanup_--dupes │ └── package-cleanup_--problems └── yum ├── package-cleanup_--dupes -> ../dnf/package-cleanup_--dupes ├── package-cleanup_--problems -> ../dnf/package-cleanup_--problems ├── yum_-C_repolist -> ../dnf/dnf_-C_repolist ├── yum_-C_repolist_--verbose -> ../dnf/dnf_-C_repolist_--verbose ├── yum_history -> ../dnf/dnf_history ├── yum_list_extras -> ../dnf/dnf_list_extras ├── yum_list_installed -> ../dnf/dnf_list_installed ├── yum_module_list -> ../dnf/dnf_module_list ├── yum_module_list_--installed -> ../dnf/dnf_module_list_--installed └── yum_--version -> ../dnf/dnf_--version ~~~ 2. The list commands don't make changes. We don't need an extra "--assumeno" here. There is no prompt. dnf_--assumeno_list_extras dnf_--assumeno_list_installed_dnf dnf_--assumeno_module_list dnf_--assumeno_module_list_--installed dnf_-C_repolist dnf_-C_repolist_--verbose dnf_history dnf_list_installed dnf_--version package-cleanup_--dupes package-cleanup_--problems 3. `dnf_--assumeno_list_installed_dnf` is already grabbed by `dnf list installed`, we're just duplicating efforts here.