[openstack-dev] Event reporter usage
Joshua Harlow
harlowja at yahoo-inc.com
Tue Mar 5 05:10:37 UTC 2013
Hi all,
I was just looking through the grizzly code and came upon a new goodie:
compute_utils.EventReporter
Is there a blueprint for how this is going to be used, it looks like its being used to save 'states' for later 'resuming' for an orchestration unit (conductor?)?
Is that correct? I haven't been following this to much so was wondering as yahoo! and nttdata 'centralized' orchestration unit prototype (aka https://etherpad.openstack.org/the-future-of-orch) also needs such state transition data, but we would like to keep usage of said states and recording of states starting/finishing and such in 1 place (and not dispersed throughout the code). I also see stuff like https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L247 which is creating records based off of function names, is there a reason we can't actually solidify on what the different states are beforehand and not creating them on the fly. Isn't that a more sane and longer-term approach where said states and there transitions are in 1 place and not all over?
Just a personal concern but has there been any any determination of how writing all this data into the DB (via the MQ) will affect DB size, its a pretty big change from writing nothing in the DB (or vm_state and task_state) to writing detailed information about when each function starts and stops, has there been any size estimation on the change so that deployers can ensure they adjust correctly? Maybe in general, but is there any good design docs on the conductor, its features in grizzly and such. If people are going to use it, I'd like to know what all its doing in grizzly and what new database tables it adds, what new MQ dependencies it adds, and so on. Does anyone else think that would be useful?
-Josh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130304/0bafaef3/attachment.html>
More information about the OpenStack-dev
mailing list