This actually appears to be a more general-purpose issue than I originally
thought.
It seems we often perform checks on the state of a given object before we
submit a job to the job queue. This is fine because it is nice if we can
fail early.
However, some of these properties we check can change
I just returned to this problem a little while ago today.
The original reason I asked this question was because I noticed an issue
when attaching multiple volumes to a VM at the same time.
The attach logic is properly funneled through the VM job queue, but it
still fails (for the second attach co
+Min.
Unfortunately, I don’t think the framework is enhanced for all the
different kinds of resources, but it should be the way to go.
IMHO Serialization through states was/is just a hacky way of getting
around the situation and should be discontinued.
Ideally, state of a resource should reflect
It appears that the job queue is used for some commands while for others it
is not.
Is the intend of the job queue to only serialize operations that are sent
to VMs?
On Tue, Jan 13, 2015 at 3:14 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:
> This is 4.6.
>
> It seems like our state-
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 the
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"
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
