Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
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.
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
> 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?
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).
> 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.
(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)
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.
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
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