upgrade from bionic-queens to bionic-rocky results in "nova-os-api-compute.service is not running" in nagios (used to say "to-stein", but actually happens on upgrade to rocky)
Bug #1849897 reported by
Drew Freiberger
This bug affects 2 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Nova Cloud Controller Charm |
Triaged
|
High
|
Unassigned |
Bug Description
After performing upgrades from xenial-queens through to bionic-stein, it has resulted in a stale nagios check defined:
nova-api-os-compute - CRITICAL: nova-api-
When I investigate, I find nova-api-os-compute service is masked on the system.
It appears this has moved to an apache2 wsgi service ala:
/etc/apache2/
I would like to suggest changing this nagios check to validate content availability of this wsgi service rather than checking status of the systemd service that is no longer valid.
Changed in charm-nova-cloud-controller: | |
status: | New → Triaged |
importance: | Undecided → High |
tags: | added: openstack-upgrade |
summary: |
- upgrade from rocky to stein results in "nova-os-api-compute.service is - not running" in nagios + upgrade from rocky to bionic results in "nova-os-api-compute.service is + not running" in nagios (used to say "to-stein", but actually happens on + upgrade to rocky) |
Changed in charm-nova-cloud-controller: | |
status: | In Progress → Triaged |
assignee: | Alex Kavanagh (ajkavanagh) → nobody |
summary: |
- upgrade from rocky to bionic results in "nova-os-api-compute.service is - not running" in nagios (used to say "to-stein", but actually happens on - upgrade to rocky) + upgrade from bionic-queens to bionic-rocky results in "nova-os-api- + compute.service is not running" in nagios (used to say "to-stein", but + actually happens on upgrade to rocky) |
tags: | added: aubergine |
To post a comment you must log in.
So, I've reproduced it and it actually happens from the upgrade of bionic-queens (distro) -> bionic-rocky. It does move from its "own" api executable to being run under wsgi in apache2. The fix (as Drew reported) is to migrate the check to validating the wsgi service. An interim is to simply rely on the fact that the apache2 check "means" that the api is running at bionic and remove the defunct nova-api-os-compute check altogether.
I'll investigate the difficulty on the former, but put a patch in to clean up the defunct check at bionic+.