Quantum Service Restarted More Often Then Necessary (quantum dependencies need review)

[Mark T. Voelker]

Per bug 1086440:
https://bugs.launchpad.net/openstack-cisco/folsom/+bug/1086440

In our current Puppet model, we're restarting Quantum more often than is strictly necessary due to Quantum starting before configuration/database population is complete. Having fixed the critical issue of the tables not being populated, we now need to address the more-often-than-necessary restarting of Quantum.

[Chris Ricker (chris-ricker)]

Raising to critical to avoid the user experience of quantum restarting constantly out from under them as a slow denial of service

[Ian Wells (ijw-ubuntu)]

Looking at the dependencies. Most are there, I think, but we have 6 or so top-level modules and I'm not convinced that their interdependencies are right. Mainly comes down to asking yourself which processes read which files and which depend on the DB (bit hard to say; also, annoyingly, the DB details are stored in quantum.conf so it's hard to say which processes actually read and connect and which ones simply ignore the block).

Also, there's a dependency we can't model in puppet - installing the OVS agent is unlikely to work until the Quantum DB has been created ('unlikely' == 'I haven't tried but I'm sceptical'), and since the DB is on another machine we can't easily do that.

[Robert Starmer (starmer)]

Resolved with pulls in vswitch, quantum, and openstack modules.
puppet-quantum: f3687d40ef92faebde5bcc90d31c2c7167b8058a
puppet-vswitch: 8271d1fd1947b4cd5e9ee05754a2be2d4503cd7a
puppet-openstack: 2068989ae5a5629105a4e809c8680db0de383b65