Red Hat Bugzilla – Bug 1463635
sosreport openstack plugin should be updated for containerized deployment
Last modified: 2018-04-10 14:03:36 EDT
Description of problem: Trying to get a sosreport from a OSP-12 containerized deployment result in file with no relevant log in it. The log has been moved to /var/log/containers/* if OSP-12 is deployed with containers. Version-Release number of selected component (if applicable): sos-3.4-5.el7.noarch OSP-12 using the latest branch (2017-06-19.1) How reproducible: Always. Steps to Reproduce: 1. Deploy OSP-12 with containers 2. Log on a controller or compute 3. Generate a sosreport Actual results: The content from /var/log/containers/* is ignored. The old files are included in the sosreport but they are now empty. For example : /var/log/keystone/keystone.log is empty in a containerized deployment. The real log file is : /var/log/containers/keystone/keystone.log Expected results: Grab the content of /var/log/containers/* if OSP-12 is deployed with containers. Additional info: It will be possible to deploy OSP-12 both with or without containers. The plugin should have a way of checking that and grab the relevant log files.
Is the proper check whether sosreport runs in a container whether env.variable 'container' exists and is set to either 'docker' or 'oci' ? If not, how to determine if I am in a container? (rather asking to double-clarify, due to the past experience with changes in this area)
From an sos perspective, as Pavel mentions, the current proposed patch is fine. All file collection is speculative; if a plugin requests a file, and it exists, then it is collected. Errors are only logged in the event that a path exists, but cannot be collected (e.g. an IO error or other exception is raised). We don't have a problem with adding 'variant' locations for files, in general, since we already need to cope with variation in version, distribution, and in some cases configuration. In extremis (i.e. the changes for TripleO were becoming awkward to manage in existing plugin classes), then we can create a new policy and tagging class for TripleO and effectively treat it as a different distribution.
I have created 2 new pull requests: * https://github.com/sosreport/sos/pull/1047 since https://github.com/sosreport/sos/pull/1046 was missing gnocchi logs * https://github.com/sosreport/sos/pull/1048 with OSP12 the env OS_TENANT_NAME changed to OS_PROJECT_NAME and therefore the OSP commands would not get triggered against the env when the new rc file got sourced. With 1046, 1047 and 1048 we should have all information from OSP12 for the existing plugins. We'd need to create new plugins for panko and aodh. I have realized an issue with sos-3.4 when running on an overcloud controller node. Since we have puppet-tripleo in the package list of openstack_instack plugin, this plugin gets triggered on the overcloud controller where we do not want to run it and it results in timeouts. I'll file a new bug for this issue and submit a pull request.
Upstream TripleO bug https://bugs.launchpad.net/tripleo/+bug/1700909
mschuppert or jsaucier committed to do OtherQA.
posted to upstream via https://github.com/sosreport/sos/commit/55800f71bdcfdea22b1d6e1c68848e58eb087d1c
dist-git commit 21a684f7b2a581a8d6c7596fd788ff3726787dd9
Fixed via sos 3.5 rebase.
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-2018:0963