I think just catching/handling the exception here will give you exactly what you want. It doesn't eliminate the race but it mitigates any negative impacts. Maybe change your logic to first "get_account", then based on results you can do the create or not On Dec 22, 2013 5:25 PM, "Mike Tutkowski" <mike.tutkow...@solidfire.com> wrote:
> 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> > *™* >
