RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1259733 - Sahara plugin captures details only for "unified" deployment
Summary: Sahara plugin captures details only for "unified" deployment
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sos
Version: 7.2
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: rc
: ---
Assignee: Pavel Moravec
QA Contact: Miroslav Hradílek
URL:
Whiteboard:
Depends On:
Blocks: 1269565 1295396 1298112 1313485
TreeView+ depends on / blocked
 
Reported: 2015-09-03 12:51 UTC by Luigi Toscano
Modified: 2016-11-04 04:54 UTC (History)
13 users (show)

Fixed In Version: sos-3.3-0.el7
Doc Type: Enhancement
Doc Text:
The openstack_sahara plug-in has been enhanced in the sos package. The plug-in additionally collects logs from openstack-sahara-api and openstack-sahara-engine packages, and thus allows users to gather information of both newly split openstack-shara deployments.
Clone Of:
: 1269565 (view as bug list)
Environment:
Last Closed: 2016-11-04 04:54:29 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:2380 0 normal SHIPPED_LIVE sos bug fix and enhancement update 2016-11-03 13:52:35 UTC

Description Luigi Toscano 2015-09-03 12:51:58 UTC 
Description of problem:
Since OpenStack Kilo (used as base of RHEL-OSP 7), the suggested upstream way to configure Sahara is using the "split" mode: two services (openstack-sahara-api and openstack-sahara-engine) instead of the single openstack-sahara-all.
The other differences are:
- log files go to /var/log/sahara-{api,engine}.log instead of /var/log/sahara-all.log
- init system files for split mode come from RPM packages openstack-sahara-api and openstack-sahara-engine; init system files for unified mode come still from RPM package openstack-sahara.

Please note that, even if RHEL-OSP documentation for manual deployment document the usage of -api + -engine, the unified mode is still supported (and packstack still uses it). The unified mode will be removed at some point in the future, but it seems it will stay at least for Liberty.

So both modes should be supported from sos point of view.


Version-Release number of selected component (if applicable):
sos-3.2-16.el7ost.2.noarch
Comment 2 Bryn M. Reeves 2015-09-03 13:10:59 UTC 
> sos-3.2-16.el7ost.2.noarch

This is not a RHEL7 package; it's from the RHOS build.

This needs to be upstream first: there is no difference between the current RHEL7 plugin and the upstream version (which is what was submitted to us originally).

Lee, can you clarify what's needed here for EL7?
Comment 3 Luigi Toscano 2015-09-03 13:29:33 UTC 
Right, it's the package from RHEL-OSP, sorry. Anyway, the candidate package for RHEL 7 (sos-3.2-32.el7.noarch.rpm) contains the same code (which, as you pointed out, matches the current upstream).
Comment 4 Bryn M. Reeves 2015-09-03 13:53:02 UTC 
> it's the package from RHEL-OSP, sorry.

It's np - just want to be clear on where the fix is expected - if it's needed in the RHEL-OSP packages (and won't wait until the next sync between RHEL/OSP) then it will need a separate bug against that product.
Comment 5 Pavel Moravec 2015-09-07 07:26:28 UTC 
(In reply to Bryn M. Reeves from comment #2)
> > sos-3.2-16.el7ost.2.noarch
> 
> This is not a RHEL7 package; it's from the RHOS build.
> 
> This needs to be upstream first: there is no difference between the current
> RHEL7 plugin and the upstream version (which is what was submitted to us
> originally).
> 
> Lee, can you clarify what's needed here for EL7?

I got a request to include it in 7.2. Though it is quite late in release schedule, I am not 100% against it (partially due to sos package respin due to 1244648 / 1243092). _If_ this BZ is requested to be added to 7.2 GA, then under these conditions:

- provide business justification (when / how often -api and -engine modes are (supposed to be) used, consequences of not collecting the data etc) - the sooner the better, to get PM ack for rhel7.2+

- have upstream PR ready until this Wednesday 9.9. (just to have one respin of this BZ together with fix of 1244648#c5 that I dont want to delay too much)

- set OtherQE as I doubt sos QE would accept it (even in situation no particular requirements of what to change/verify are known atm)
Comment 8 Poornima 2015-09-08 12:02:21 UTC 
requesting for review : https://github.com/poornimakshirsagar/sos/commit/f55e2cb0c904e7882f07d8b800c1a8b14cd2435e
Comment 9 Luigi Toscano 2015-09-08 12:42:02 UTC 
(In reply to Poornima from comment #8)
> requesting for review :
> https://github.com/poornimakshirsagar/sos/commit/f55e2cb0c904e7882f07d8b800c1a8b14cd2435e

I tested the above patch with both scenarios (-all vs -api+-engine) and the relevant information are captured.
Comment 10 Pavel Moravec 2015-09-10 11:52:30 UTC 
Patch not yet in upstream and no business justification provided here - deferring to post-7.2GA release (7.2.z once the flag is available).
Comment 11 Pavel Moravec 2015-09-21 07:05:46 UTC 
In case of presence in RHEL7.2, Luigi offered to QE this.

devel_ack as upstream PR ACKed and just pending commit.
Comment 17 Pavel Moravec 2016-02-21 08:15:07 UTC 
posted in 2 upstream commits:

ca0463f36cd6ab02bd27f5ef9682660a0d212dcd
887fc720db5eb980088f771187311e85e04598f9
Comment 19 Mike McCune 2016-03-28 23:20:28 UTC 
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions
Comment 22 Luigi Toscano 2016-07-01 11:32:22 UTC 
The candidate package is able to capture the logs (journalctl) also for the split services openstack-sahara-api and openstack-sahara-engine (in addition to the deprecated unified openstack-sahara-all). 
Capturing is properly triggered when the packages with the split services are installed and the old unified package is not available.
Text log files were always collected (they are in the same directory)

Verified against a candidate RH-OSP9 installation using:
sos-3.3-1.el7.noarch.
Comment 25 errata-xmlrpc 2016-11-04 04:54:29 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://rhn.redhat.com/errata/RHBA-2016-2380.html
Note You need to log in before you can comment on or make changes to this bug.