relation between cgred (libcgroup) and libvirt

[Clint Byrum]

On Wed, 2011-02-09 at 22:35 -0600, Serge E. Hallyn wrote:
> I suspect that once again I'm just not thinking 'the upstart way'.  A
> system can have none, either, or both of cgred and libvirt set to run
> on a system.  They don't need each other.  However, if both are going
> to run, then libvirt needs to start after cgred or else it won't be
> able to start VMs.
> 
> So the first problem is that libcgroup isn't upstartified and the init
> jobs are ugly, but I'll handle that.  However, I'm not sure how I
> should relate the two jobs.  Do I need to stick to having extra
> pre-script logic in libvirt to check whether cgred should run but
> isn't yet ready?  Or is there a better way?  Making cgred
> 'start on starting libvirt-bin' is wrong both because we don't want
> to make cgred wait for libvirt and bc it should start on a libvirt-free
> system.
> 

At first glance.. this came to mind:

start on runlevel [2345] or starting libvirt-bin
                  ^-- the usual start on for sysv scripts
                            ^-- special case

This will, unfortunately, race if libvirt-bin also starts on runlevel
[2345], since the starting libvirt-bin will just bounce off when the
goal is already at 'start'.

So then I thought

start on starting rc RUNLEVEL=[2345] or starting libvirt-bin

the starting rc will likely make this finish starting well before
libvirt-bin. But then this has the same problem if libvirt-bin gets
changed to start on starting rc RUNLEVEL=[2345]

I feel like my answer to everything is this wait-for-state job but ...
it would solve the issue. You could add, to cgred:

# libvirt-cgred-wait
start on starting libvirt-bin
stop on started cgred or stopped cgred

task
normal exit 2
script
  status cgred | grep -q "start/running" && exit 0
  start cgred || true
  sleep 3600
end script
# EOF

Which will make libvirt wait for cgred only when cgred is installed.