Bug 1640141
| Summary: | sosreport can't find /var/lib/config-data/puppet-generated/neutron/etc/neutron/plugin.ini | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Noam Manos <nmanos> |
| Component: | sos | Assignee: | Pavel Moravec <pmoravec> |
| Status: | CLOSED ERRATA | QA Contact: | Miroslav Hradílek <mhradile> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.5 | CC: | agk, apevec, bmr, gavin, lhh, mschuppe, nmanos, plambri, sbradley |
| Target Milestone: | rc | ||
| Target Release: | 7.6 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | sos-3.7-1.el7 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-08-06 13:15:33 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: | |||
|
Description
Noam Manos
2018-10-17 12:22:29 UTC
The issue is that we have a broken link outside the container: [root@controller-0 ~]# ll /var/lib/config-data/puppet-generated/neutron/etc/neutron/plugin.ini lrwxrwxrwx. 1 root root 37 Oct 22 08:49 /var/lib/config-data/puppet-generated/neutron/etc/neutron/plugin.ini -> /etc/neutron/plugins/ml2/ml2_conf.ini [root@controller-0 ~]# ll /etc/neutron/plugins/ml2/ml2_conf.ini ls: cannot access /etc/neutron/plugins/ml2/ml2_conf.ini: No such file or directory As this is mapped into the neutron container its ok inside: [root@controller-0 ~]# docker exec -it -u root neutron_api ls -la /etc/neutron/plugin.ini lrwxrwxrwx. 1 root root 37 Oct 22 09:00 /etc/neutron/plugin.ini -> /etc/neutron/plugins/ml2/ml2_conf.ini > Expected results:
> sosreport to collect openstack_neutron with no error
So in case symlink target (here towards /etc/neutron/plugins/ml2/ml2_conf.ini outside the container) is missing, sosreport should raise a warning instead of an error? So it is just about log verbosity?
Definitely sosreport cant collect files it does not have access to. So until the "docker exec -it .." command is executed, sosreport wont collect (or further scrub secret info in) the file. And sosreport should warn in some way something unexpectedly failed.
Do you suggest change in:
- no log on stdout/stderr
- sos_logs will contain a warning (not print to stdout) instead of error (that is print to stdout)
- BUT the change will apply only for "[Errno 2] No such file or directory" error type - since we must warn the user running sosreport (customer) in case we collect some file but some password obfuscation failed - so they might be leaking some secret info by providing the sosreport archive
Does this change make sense?
(note to myself: reproducer for me: 1) on a system without grafana installed: mkdir /etc/grafana ln -s /etc/grafana/grafana.ini-missing /etc/grafana/grafana.ini sosreport -o grafana --batch --build (and the problem happens on self.do_path_regex_sub called for (broken) _symlinks_ only) ) (In reply to Pavel Moravec from comment #3) > > Expected results: > > sosreport to collect openstack_neutron with no error > > So in case symlink target (here towards > /etc/neutron/plugins/ml2/ml2_conf.ini outside the container) is missing, > sosreport should raise a warning instead of an error? So it is just about > log verbosity? > > Definitely sosreport cant collect files it does not have access to. So until > the "docker exec -it .." command is executed, sosreport wont collect (or > further scrub secret info in) the file. And sosreport should warn in some > way something unexpectedly failed. > > Do you suggest change in: > - no log on stdout/stderr > - sos_logs will contain a warning (not print to stdout) instead of error > (that is print to stdout) > - BUT the change will apply only for "[Errno 2] No such file or directory" > error type - since we must warn the user running sosreport (customer) in > case we collect some file but some password obfuscation failed - so they > might be leaking some secret info by providing the sosreport archive > > Does this change make sense? Warning is good if it's not revealing other problem. I believe that the fix than should be in the broken link, unless it's OK to have this broken link: [root@controller-0 ~]# ll /etc/neutron/plugins/ml2/ml2_conf.ini ls: cannot access /etc/neutron/plugins/ml2/ml2_conf.ini: No such file or directory (In reply to Noam Manos from comment #5) > (In reply to Pavel Moravec from comment #3) > > > Expected results: > > > sosreport to collect openstack_neutron with no error > > > > So in case symlink target (here towards > > /etc/neutron/plugins/ml2/ml2_conf.ini outside the container) is missing, > > sosreport should raise a warning instead of an error? So it is just about > > log verbosity? > > > > Definitely sosreport cant collect files it does not have access to. So until > > the "docker exec -it .." command is executed, sosreport wont collect (or > > further scrub secret info in) the file. And sosreport should warn in some > > way something unexpectedly failed. > > > > Do you suggest change in: > > - no log on stdout/stderr > > - sos_logs will contain a warning (not print to stdout) instead of error > > (that is print to stdout) > > - BUT the change will apply only for "[Errno 2] No such file or directory" > > error type - since we must warn the user running sosreport (customer) in > > case we collect some file but some password obfuscation failed - so they > > might be leaking some secret info by providing the sosreport archive > > > > Does this change make sense? > > > Warning is good if it's not revealing other problem. I believe that the fix > than should be in the broken link, unless it's OK to have this broken link: > > [root@controller-0 ~]# ll /etc/neutron/plugins/ml2/ml2_conf.ini ls: cannot > access /etc/neutron/plugins/ml2/ml2_conf.ini: No such file or directory I'd also vote for log it as warning. It's ok to have the broken link as it is a good link inside the container as this is the config volume mapped into the container. Technically, it must be info verbosity and to warning (as I learned now) - also warning is printed to stdout the same way. Anyway, the change is reasonable either way, PR raised. POSTed to upstream Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2019:2295 |