Setting single-nova-consoleauth to False doesn't re-create the systemd service

Bug #1705514 reported by Junien Fridrick
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack Nova Cloud Controller Charm
Fix Released
Medium
Unassigned

Bug Description

Hi,

Following the fix released for LP#1660244, and since we had single-nova-consoleauth set to the default of True, the sysV service for nova-consoleauth got disabled and the systemd unit (we're running xenial) got removed.

It turns out we need single-nova-consoleauth set to False. When I change the option, the sysV service didn't get re-enabled, the systemd unit didn't get re-created, and the actual nova-consoleauth daemon didn't get started.

I had to do the following to get things back to where they should be :
sudo /lib/systemd/systemd-sysv-install enable nova-consoleauth
sudo /etc/init.d/nova-consoleauth start

I believe this should be done automatically whenever someone sets single-nova-consoleauth to False.

Thank you

Changed in charm-nova-cloud-controller:
status: New → In Progress
importance: Undecided → Medium
assignee: nobody → Jorge Niedbalski (niedbalski)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to charm-nova-cloud-controller (master)

Fix proposed to branch: master
Review: https://review.openstack.org/486186

Alvaro Uria (aluria)
tags: added: canonical-bootstack
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on charm-nova-cloud-controller (master)

Change abandoned by Jorge Niedbalski R. (<email address hidden>) on branch: master
Review: https://review.openstack.org/486186
Reason: Not following up this review

Frode Nordahl (fnordahl)
Changed in charm-nova-cloud-controller:
status: In Progress → Triaged
assignee: Jorge Niedbalski (niedbalski) → nobody
Revision history for this message
Billy Olsen (billy-olsen) wrote :

Upon review, this was fixed in commit edc18d49 as the fix for LP#1765215. The primary issue is that it was using upstart service management instead of systemd service management. That's been changed to use the charmhelpers' service_resume function which works for supported underlying init systems.

Changed in charm-nova-cloud-controller:
status: Triaged → Fix Released
milestone: none → 18.02
Revision history for this message
Billy Olsen (billy-olsen) wrote :

Marked as 18.02 as bug #1765215 was backported to stable/18.02

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to charm-nova-cloud-controller (master)

Related fix proposed to branch: master
Review: https://review.openstack.org/579038

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to charm-nova-cloud-controller (master)

Reviewed: https://review.openstack.org/579038
Committed: https://git.openstack.org/cgit/openstack/charm-nova-cloud-controller/commit/?id=dc56287105dfc80900fdfed2cdc867c4063592ee
Submitter: Zuul
Branch: master

commit dc56287105dfc80900fdfed2cdc867c4063592ee
Author: Billy Olsen <email address hidden>
Date: Thu Jun 28 18:34:02 2018 -0700

    Don't resume service if unit is paused

    Disabling the single-nova-consoleauth while the unit is paused
    will restart the nova-consoleauth service on the local unit.
    This patch only resumes the service locally if the local unit
    is not currently paused.

    Change-Id: Id66375ab758e1b33b96a819d2ce788a4434b1686
    Related-Bug: #1765215
    Related-Bug: #1705514

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.