Yeah, if it were just a single management server, I could use "synchronized", but since it's not I was curious how we handle this situation.
Perhaps your recommendation in regards to using a database table is the way to go here. Do you know of any code in CloudStack that performs this kind of action that I could use as a template? I actually looked into this SolidFire API more and - in this case - account name must be unique in the SAN, so it's a non-issue (I thought like volumes that account names could be reused and you would identify the one you want based on its unique ID only). Technically it's not really a non-issue, though. For example, two threads could try to create the same account at the same time, but one would get an exception (duplicate account name). That's OK, though. I could re-write the logic to catch the exception and look for the account again (if the account is there, you're OK; else, there really is a problem). CloudStack doesn't need to know about SolidFire accounts, though (just my plug-in does). SolidFire has this kind of division in our SAN to support APIs that query for statistics based on a tenant's particular account. On Sun, Dec 22, 2013 at 2:40 PM, Marcus Sorensen <shadow...@gmail.com>wrote: > 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> > > *™* > > > -- *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> *™*
