Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1463635 - sosreport openstack plugin should be updated for containerized deployment
Summary: sosreport openstack plugin should be updated for containerized deployment
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sos
Version: 7.4
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: pre-dev-freeze
: ---
Assignee: Pavel Moravec
QA Contact: Jan Houska
URL:
Whiteboard:
Depends On:
Blocks: 1500289 1506908 1515325
TreeView+ depends on / blocked
 
Reported: 2017-06-21 11:45 UTC by Jean-Francois Saucier
Modified: 2018-04-10 18:03 UTC (History)
21 users (show)

Fixed In Version: sos-3.5-1.el7
Doc Type: Enhancement
Doc Text:
The "openstack" sosreport plug-in has been updated to enable sosreport to collect data from containerized Red Hat OpenStack Platform deployments.
Clone Of:
: 1500289 (view as bug list)
Environment:
Last Closed: 2018-04-10 18:01:47 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2018:0963 None None None 2018-04-10 18:03:36 UTC

Description Jean-Francois Saucier 2017-06-21 11:45:21 UTC
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.

Comment 4 Pavel Moravec 2017-06-28 07:18:17 UTC
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)

Comment 10 Bryn M. Reeves 2017-06-28 12:40:26 UTC
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.

Comment 11 Martin Schuppert 2017-06-28 15:23:17 UTC
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.

Comment 15 Bogdan Dobrelya 2017-07-17 07:43:02 UTC
Upstream TripleO bug https://bugs.launchpad.net/tripleo/+bug/1700909

Comment 16 Pavel Moravec 2017-10-04 08:54:06 UTC
mschuppert or jsaucier committed to do OtherQA.

Comment 17 Pavel Moravec 2017-10-10 10:09:25 UTC
posted to upstream via https://github.com/sosreport/sos/commit/55800f71bdcfdea22b1d6e1c68848e58eb087d1c

Comment 19 Pavel Moravec 2017-10-10 11:19:10 UTC
dist-git commit 21a684f7b2a581a8d6c7596fd788ff3726787dd9

Comment 21 Pavel Moravec 2017-11-02 15:15:25 UTC
Fixed via sos 3.5 rebase.

Comment 31 errata-xmlrpc 2018-04-10 18:01:47 UTC
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


Note You need to log in before you can comment on or make changes to this bug.