cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Tutkowski <mike.tutkow...@solidfire.com>
Subject Re: Distributed locking mechanism?
Date Mon, 23 Dec 2013 03:58:23 GMT
Great, thanks, everyone.

Although I can get around this particular issue without the "InLockTable"
this time, "InLockTable" is really useful to know as I can see it coming
into play with other actions I may need to take.


On Sun, Dec 22, 2013 at 7:04 PM, Nitin Mehta <Nitin.Mehta@citrix.com> wrote:

> Mike - I think your use case can be answered by Alex's wiki [1] - handling
> locking section.
> You can look for where all the methods provided in Generic Dao (that end
> in "InLockTable") is referred to get a better idea.
>
> [1]
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Data+Access+Layer
>
> Thanks,
> -Nitin
>
> On 22/12/13 4:24 PM, "Mike Tutkowski" <mike.tutkowski@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
> ><shadowsor@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*™*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message