Using global state machine to maintain image status

In our meeting, we talked about the possibility that this type of refactoring would work better as a first step in the I release. Let me know if I misunderstood the conclusion there (markwash)

Talked with Harlowja, seems the FSM in taskflow lib is a good candidate to use for the BP: https://etherpad.openstack.org/p/CinderTaskFlowFSM (zhiyan)

I think we need a lot more information here. What is being centralized/globalized? the data, or the transitions, or some other aspect? And how would the code need to change, more broadly?
I think a specification would be very useful.

Personally, i feel like the domain layer is the way that we centralize the logic of managing state transitions, without having to serialize them in any one component. But I'm not sure if that is relevant, or a disagreement, or an agreement with this proposal :-)

markwash more-info 2014-02-14

I also prefer to implement such image status state machine in domain layer as a centralize image status transfer management logic. Actually I proposed this idea when we fix bug #1241379, therefore currently Glance has a simple image status transfer checking logic at [1]. It does enforce a graph of states when image do a status transfer, but we are still left many places in the code where an event occurs and we must check the state to determine what to do. So I'm thinking whether we need a FSM in Glance, we feed the incoming event into it, and the results would be the execution of a specific code given the current state with the event. I consider it's an ideal solution and it will be a large refactoring.
[1] https://github.com/openstack/glance/blob/master/glance/domain/__init__.py#L140

What you think markwash? Any comments and input are welcome.

zhiyan 2014-02-18

I guess the issue that I see is how we define "incoming event". To me, an incoming event is defined as some method invocation on a domain object. Perhaps you agree? In that form, however, it doesn't seem like this has much of anything to do with Cinder or Taskflow.

I think its just not really clear to me what specific state transitions need to be added or moved. If you could list those here, that would be very helpful in considering this blueprint.

markwash more-info 2014-03-07

I think this effort is in general good, but maybe we can just pick it up in terms of bug fixes. Or we could see it recreated along more specific lines of the state transitions that are currently happening *outside* of the domain model.
markwash rejected 2014-03-28