charm attempts to restart nova-compute and hangs

Bug #1639289 reported by Vance Morris
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Nova Compute Proxy Charm
New
Undecided
Unassigned

Bug Description

At first deploy, before any relations are added, the charm configures /etc/nova/nova.conf and then tries to restart openstack-nova-compute.service. This hangs with the following messages in the nova logs:

2016-11-04 12:14:57.355 63556 ERROR oslo.messaging._drivers.impl_rabbit [req-1d48673b-bac0-406b-b144-dc522ba88679 - - - - -] AMQP server on 127.0.0.1:5672 is unreachable: [Errno 111] ECONNREFUSED. Trying again in 32 seconds.

I'm waiting for the start process to timeout (not sure what the period is, but i'm up to 7 minutes now).

openstack-nova-compute.service shouldn't be restarted until the rabbitmq-server relation is added and satisfied.

Revision history for this message
Vance Morris (vmorris) wrote :

[root@zs93k24 nova]# systemctl status openstack-nova-compute.service
● openstack-nova-compute.service - OpenStack Nova Compute Server
   Loaded: loaded (/usr/lib/systemd/system/openstack-nova-compute.service; disabled; vendor preset: disabled)
   Active: activating (start) since Fri 2016-11-04 12:09:47 EDT; 42min ago
 Main PID: 63556 (nova-compute)
   CGroup: /system.slice/openstack-nova-compute.service
           └─63556 /usr/bin/python2 /usr/bin/nova-compute

Nov 04 12:09:47 zs93k24 systemd[1]: Starting OpenStack Nova Compute Server...
Nov 04 12:09:51 zs93k24 nova-compute[63556]: Option "logdir" from group "DEFAULT" is deprecated. Use option "log-dir" from group "DEFAULT".

stopping the service manually caused the charm hooks to continue to catch, and ended up at
INFO unit.nova-compute-proxy/11.juju-log cloud-compute:64: Unit is ready

Revision history for this message
Ryan Beisner (1chb1n) wrote :

At the moment, the recommended deploy routine is:

1. Deploy the control plane (including rabbitmq-server), and wait for it to complete. Hooks should be done, relations should be settled.

2. Then, deploy the nova-compute-proxy charm.

Ultimately, the nova-compute-proxy charm should have workload status and "require relations" blocking, so that the charm waits to conduct z/kvm operations until the control plane is ready.

There is a bug to track that[1]. Once bug that is addressed, this bug will also likely be addressed.

[1] https://bugs.launchpad.net/charm-nova-compute-proxy/+bug/1638772

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.