As far as I'm aware, most of this sort of thing is managed by the state machines on the resources themselves, combined with the transactional database to move between states it keeps the management servers in sync.
I'm not sure the problem is specific to having multiple mgmt servers. You'd have the same race with a single mgmt server, but having one makes it easier to solve (e.g. via synchronize block). There are probably many different ways to tackle this. My immediate thought is that cloudstack needs to know about your external accounts if its to be expected to handle them. But I imagine you could also use any old database transaction to do what you want, maybe have your own accounts table you can lock. Another option is simply to make the action idempotent. Why does creating the same account twice result in two accounts? Can that be fixed? On Dec 22, 2013 1:25 PM, "Mike Tutkowski" <mike.tutkow...@solidfire.com> wrote: > Hi, > > I was wondering how we control access to shared resources that are being > utilized by different management servers at the same time. > > For example: > > When a user attaches a volume (that's based on the SolidFire plug-in) to a > VM, my plug-in looks at the CloudStack account that is requesting the > operation. If this CloudStack account does not have a corresponding account > on the SolidFire SAN, I must create one (there is a 1:1 mapping between > CloudStack and SolidFire accounts). > > How can I protect against a situation where my plug-in is running in > multiple management servers and performing this kind of operation at the > same time (in other words, I don't want both instances of the plug-in to > see no SolidFire account and then they each end up creating one, which > breaks the 1:1 mapping between a CloudStack account and a SolidFire > account)? > > Thanks! > > -- > *Mike Tutkowski* > *Senior CloudStack Developer, SolidFire Inc.* > e: mike.tutkow...@solidfire.com > o: 303.746.7302 > Advancing the way the world uses the > cloud<http://solidfire.com/solution/overview/?video=play> > *™* >
