Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (athena.apache.org: domain of mike.tutkowski@solidfire.com
 designates 209.85.219.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CEDCD8E1.3249E%nitin.mehta@citrix.com>
References: 
 <CACOnxCiH1DTUmAwjdrQ+v-NH-9hCEtwEWxn7_X_pWr7+K+UreQ@mail.gmail.com>
	<CEDCD8E1.3249E%nitin.mehta@citrix.com>
Date: Sun, 22 Dec 2013 20:58:23 -0700
Message-ID: 
 <CACOnxChQPSrB3j8y-TJ6qcsCc6UcsMz1esoG7v7bdmaw4P1cTg@mail.gmail.com>
Subject: Re: Distributed locking mechanism?
From: Mike Tutkowski <mike.tutkowski@solidfire.com>
To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org>
Content-Type: multipart/alternative; boundary=001a11c2c484a4628d04ee2ba3e9

--001a11c2c484a4628d04ee2ba3e9
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

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] - handlin=
g
> 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 kin=
d
> >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 wa=
nt
> >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 m=
y
> >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 stat=
e
> >> machines on the resources themselves, combined with the transactional
> >> database to move between states it keeps the management servers in syn=
c.
> >>
> >> 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 t=
o
> >>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 yo=
u
> >>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.co=
m
> >
> >> 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 th=
e
> >> > 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-i=
n
> >>to
> >> > see no SolidFire account and then they each end up creating one, whi=
ch
> >> > 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=3Dplay>
> >> > * *
> >> >
> >>
> >
> >
> >
> >--
> >*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=3Dplay>
> >* *
>
>


--=20
*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=3Dplay>
*=99*

--001a11c2c484a4628d04ee2ba3e9--