Open Stack

On 03/04/13 at 09:10pm, Joshua Harlow wrote:
>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?)?

This came out of the instance actions blueprint 
https://blueprints.launchpad.net/nova/+spec/instance-actions which has 
more useful rationale info in the wiki 
https://wiki.openstack.org/wiki/NovaInstanceActions.

The summary is that this is storing information about what user 
initiated actions have taken place on an instance, and associated 
'events' needed to complete that action.  For instance a boot action has 
a scheduling event and then a run_instance event.  In addition to 
tracking and displaying this information for users who want to know what 
has taken place with their instance, it also provides a mechanism to 
stop setting an instance to ERROR every time something goes wrong.  
Something like a failed password reset needs a way to report that 
failure, but doesn't need the full restrictions of an instance fault.  
This behaviour hasn't been changed yet but I'd like to get to it soon.

>
>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?

The reason that code is going off of method names is because this isn't 
really tied to states, as mentioned above it's more about events needed 
to make something happen which can be more than one per state.  Now, the 
actions that these events are attached to do more closely line up with 
state transitions and are solidified at 
https://github.com/openstack/nova/blob/master/nova/compute/instance_actions.py.

With that explanation out of the way I will say that I'm keenly 
interested in this orchestration work and realize that it will likely 
involve rethinking how best to accomplish the two goals I had in mind, 
an 'action log' and better error reporting.  I completely agree that 
recording of state transitions shouldn't be dispersed throughout the 
code unnecessarily and am happy to morph the instance actions code to 
sit with the orchestration code.  I will be following and participating 
in the orchestration discussions as much as possible.

>
>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?

For your first question, no I don't have any numbers around how this 
will affect DB size yet.  I hope to be able to start looking at this 
soon.  One feature I didn't get to add but which may be useful would be 
a configurable limit on the number of actions and events recorded.  
Maybe just the last 10 or so.

>
>-Josh
>
>
>
>

>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev