This is 4.6. It seems like our state-transitioning logic is intended (as one might expect) to protect the object in question from transitions that are invalid given it's current state (this is what I would expect).
I do not see, say, the attach and detach operations being serialized. It seems they are running simultaneously. On Tue, Jan 13, 2015 at 2:09 PM, Nitin Mehta <[email protected]> wrote: > States shouldn¹t be used to serialize operations on a volume. It should be > used to denote the lifecycle of the volume instead. > I think the async job manager does take care of the serialization. Which > version do you see this issue happening ? > > Thanks, > -Nitin > > On 13/01/15 12:28 PM, "Mike Tutkowski" <[email protected]> > wrote: > > >Hi, > > > >Does anyone know why we don't currently have a state and applicable > >transitions in Volume.State for attaching and detaching volumes? > > > >It seems like you'd want to, say, transition to Attaching only when you're > >in the Ready state (or maybe some other states, as well). > > > >I think right now you can confuse the system by sending an attach command > >and then a detach command before the attach command finishes (it's a race > >condition...I don't think it always causes trouble). > > > >Thoughts? > > > >Thanks, > >Mike > > > >-- > >*Mike Tutkowski* > >*Senior CloudStack Developer, SolidFire Inc.* > >e: [email protected] > >o: 303.746.7302 > >Advancing the way the world uses the cloud > ><http://solidfire.com/solution/overview/?video=play>* * > > -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: [email protected] o: 303.746.7302 Advancing the way the world uses the cloud <http://solidfire.com/solution/overview/?video=play>*™*
