Bug 2136445

Summary: [RHOSP 17.1] Deprecate sensubility
Product: Red Hat OpenStack Reporter: Martin Magr <mmagr>
Component: collectd-sensubilityAssignee: Martin Magr <mmagr>
Status: CLOSED ERRATA QA Contact: Leonid Natapov <lnatapov>
Severity: medium Docs Contact: mgeary <mgeary>
Priority: medium    
Version: 18.0 (Zed)CC: jamparke, jamsmith, lmadsen, mrunge, prgutier
Target Milestone: gaKeywords: Triaged
Target Release: 17.1   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Deprecated Functionality
Doc Text:
Monitoring of API health status via podman using sensubility is deprecated in RHOSP 17.1. + Only the sensubility layer is deprecated. API health checks remain in support. The sensubility layer exists for interfacing with Sensu, which is no longer a supported interface.
Story Points: ---
Clone Of:
: 2141683 (view as bug list) Environment:
Last Closed: 2023-08-16 01:12:25 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: 2141683    

Description Martin Magr 2022-10-20 10:14:33 UTC
We should think about deprecation of collectd-sensubility for following reasons:

1. we don't have customers requiring Sensu compatibility any more
2. availability monitoring feature implemented the way Sensu or Sensubility implemented is not requested any more.
3. sensubility is currently used internally only for reporting health of API containers, which can be achieved by modifying Python script currently executed by sensubility to be executed by collectd-exec. This script can use collectd communication protocol to report results back as proper collectd metric instead of sensubility sending it as a json message to sg-core, which then needs to transform it to a metric. That said it would be possible to also deprecate the sensubility plugin for sg-core.

Comment 1 Martin Magr 2022-10-20 10:16:55 UTC
In case that the feature for availability monitoring performed by script execution on monitored node would be requested, we could introduce it back with sg-agent project, which is better suited for STF purposes anyway.

Comment 2 Leif Madsen 2022-10-26 12:41:42 UTC
(In reply to Martin Magr from comment #1)
> In case that the feature for availability monitoring performed by script
> execution on monitored node would be requested, we could introduce it back
> with sg-agent project, which is better suited for STF purposes anyway.

We definitely need to provide API health checks. If there is another way to handle that outside of sensubility, then I'm in favour of that. I'd like to see that implementation done as a demo before we do anything around deprecation. We would also need to scope how that affects our deployment models, documentation, QE, etc.

Once that is scoped, then I would be in favour of deprecating sensubility as long as we don't regress the ability to collect API health checks, request times, etc.

Comment 3 Leif Madsen 2022-11-07 18:36:05 UTC
Discussion with Martin and Jamie today lead to us writing a deprecation note for sensubility, with removal for RHOSP 18.0. The sensubility layer is no longer required as we do not support interfacing with sensu, and thus the continued use of sensubility simply provides another abstraction layer which is not necessary to provide the API health check functionality.

In the future (RHOSP 18.0) we will remove sensubility and implement API health checks directly from collectd exec plugin to allow telemetry to transmit via other write plugins, such as write_prometheus. It will also simplify our implementation by not having a dedicated (separate) QDR transport implementation.

CC: @mmagr @jamparke

Comment 6 Leif Madsen 2023-06-16 18:20:12 UTC
Moving this to VERIFIED as this issue is only a release note for deprecated functionality. It has been reviewed by the documentation team.

Comment 15 errata-xmlrpc 2023-08-16 01:12:25 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 (Release of components for Red Hat OpenStack Platform 17.1 (Wallaby)), 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-2023:4577

Comment 16 Red Hat Bugzilla 2023-12-15 04:25:45 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days