Bug 1259733
| Summary: | Sahara plugin captures details only for "unified" deployment | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Luigi Toscano <ltoscano> | |
| Component: | sos | Assignee: | Pavel Moravec <pmoravec> | |
| Status: | CLOSED ERRATA | QA Contact: | Miroslav Hradílek <mhradile> | |
| Severity: | high | Docs Contact: | ||
| Priority: | unspecified | |||
| Version: | 7.2 | CC: | agk, bmr, dkutalek, gavin, isenfeld, lmiksik, ltoscano, lyarwood, mhradile, pkshiras, plambri, pmoravec, sbradley | |
| Target Milestone: | rc | Keywords: | OtherQA | |
| Target Release: | --- | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| 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.
|
Story Points: | --- | |
| Clone Of: | ||||
| : | 1269565 (view as bug list) | Environment: | ||
| Last Closed: | 2016-11-04 04:54:29 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: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 1269565, 1295396, 1298112, 1313485 | |||
> 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) requesting for review : https://github.com/poornimakshirsagar/sos/commit/f55e2cb0c904e7882f07d8b800c1a8b14cd2435e (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. 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). In case of presence in RHEL7.2, Luigi offered to QE this. devel_ack as upstream PR ACKed and just pending commit. posted in 2 upstream commits: ca0463f36cd6ab02bd27f5ef9682660a0d212dcd 887fc720db5eb980088f771187311e85e04598f9 This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions 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