upon charm upgrade, haproxy configuration is removed, but nrpe check_haproxy_servers still enabled

Bug #1906444 reported by Drew Freiberger
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Ceilometer Charm
New
Undecided
Unassigned

Bug Description

This is related to bug lp#1773894.

When using ceilometer with gnocchi in ocata+ releases (I'm specifically working with cloud:xenial-queens), the nrpe check for haproxy_servers is still configured by the charm even though haproxy is disabled.

Also, the old haproxy.cfg file is still hanging around, with haproxy installed, but not running. The cleanup of the pacemaker resources was properly solved in the fix for lp#1773894, but I think some additional cleanup of haproxy monitoring, package installation, and configuration need cleanup.
Please add something in upgrade-charm that will run charmhelpers nrpe.remove_deprecated_check('haproxy_servers') if haproxy=False.

Revision history for this message
Drew Freiberger (afreiberger) wrote :

This logic from the patch to 1773894 should probably be applied in some way to the update_nrpe_config() in ceilometer_hooks.py.

    haproxy_enabled = True
    cmp_codename = CompareOpenStackReleases(
        get_os_codename_install_source(config('openstack-origin')))
    if cmp_codename >= 'ocata':
        haproxy_enabled = False

The current code calls charmhelpers nrpe.add_haproxy_checks(). Charmhelpers may need a "remove_haproxy_checks()" to fully implement this in a reusable way, otherwise, you can call nrpe.remove_deprecated_check(['haproxy_servers', 'haproxy_queue']).

Revision history for this message
Drew Freiberger (afreiberger) wrote :

workaround is to remove/add relation between ceilometer:nrpe-external-master and the related nrpe charm.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.