apt-get install nova-compute has odd configuration order

[James Page]

Detected during autopkgtests:

Created symlink /etc/systemd/system/multi-user.target.wants/nova-novncproxy.service → /lib/systemd/system/nova-novncproxy.service.
Setting up nova-scheduler (2:14.0.0~rc2-0ubuntu3) ...
Created symlink /etc/systemd/system/multi-user.target.wants/nova-scheduler.service → /lib/systemd/system/nova-scheduler.service.
Setting up nova-network (2:14.0.0~rc2-0ubuntu3) ...
Created symlink /etc/systemd/system/multi-user.target.wants/nova-network.service → /lib/systemd/system/nova-network.service.
Setting up nova-consoleauth (2:14.0.0~rc2-0ubuntu3) ...
Created symlink /etc/systemd/system/multi-user.target.wants/nova-consoleauth.service → /lib/systemd/system/nova-consoleauth.service.
Setting up nova-compute-kvm (2:14.0.0~rc2-0ubuntu3) ...
Setting up nova-compute (2:14.0.0~rc2-0ubuntu3) ...
Created symlink /etc/systemd/system/multi-user.target.wants/nova-compute.service → /lib/systemd/system/nova-compute.service.
Setting up autopkgtest-satdep (0) ...
Setting up nova-compute-libvirt (2:14.0.0~rc2-0ubuntu3) ...
Adding user `nova' to group `libvirt' ...
Adding user nova to group libvirt
Done.

nova-compute-kvm -> nova-compute-libvirt -> nova-compute -> nova-compute-kvm | nova-compute-hypervisor

this is a little circular - installing 'nova-compute-kvm' dtrt and ensures nova-compute-libvirt is configured before nova-compute-kvm, resulting in the correct group membership of nova->libvirt, but install of 'nova-compute' results in the group membership being setup after the nova-compute daemon starts.

Result is that on first exec, nova-compute can't access the libvirt socket, but the systemd unit restarts the daemon a few times until the permission is correct.

[Corey Bryant (corey.bryant)]

Marking this as a duplicate of LP: #1761140 as fixes are underway for it.