This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


RE: [Xen-API] XenAPI: Why OpaqueRef instead direct UUID

To: 'George Shuklin' <george.shuklin@xxxxxxxxx>
Subject: RE: [Xen-API] XenAPI: Why OpaqueRef instead direct UUID
From: Dave Scott <Dave.Scott@xxxxxxxxxxxxx>
Date: Fri, 1 Apr 2011 20:55:19 +0100
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-api@xxxxxxxxxxxxxxxxxxx" <xen-api@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 01 Apr 2011 12:55:40 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1301682577.2003.5.camel@mabase>
List-help: <mailto:xen-api-request@lists.xensource.com?subject=help>
List-id: Discussion of API issues surrounding Xen <xen-api.lists.xensource.com>
List-post: <mailto:xen-api@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=unsubscribe>
References: <1300810180.2402.35.camel@mabase> <81A73678E76EA642801C8F2E4823AD21956019EF0B@xxxxxxxxxxxxxxxxxxxxxxxxx> <1301682577.2003.5.camel@mabase>
Sender: xen-api-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcvwmsU4mdihJCASQ0+OAweP7LRW2gAC0KYg
Thread-topic: [Xen-API] XenAPI: Why OpaqueRef instead direct UUID
Hi George,

> Thank you very much. Yes, I understand now.
> I look to the source code (as far as I can), they are looked for me
> like
> a pirmary key for database.
> Can I assume that opaqueRef is consistent between xapi restart, master
> change, pool upgrade and so on?
> In other words, can I use OpaqueRef as full replacement for uuids?


Although we've always been hesitant to guarantee this, as you've noted we use 
the OpaqueRef as the primary key inside our database. Plus we have never 
changed them and realistically I think we will never need to change them. Plus 
it is very convenient to be able to cache them-- I'm keen to exploit this to 
make the event mechanism more efficient.

So I believe storing OpaqueRefs (instead of uuids) is a safe thing to do.
> Thanks again.
> PS Can I post this reply to Xen wiki? I think it will be very userfull
> for XenAPI users.

Please do! The more wiki edits the better :-)


> ---
> wBR, George.
> В Птн, 01/04/2011 в 18:31 +0100, Dave Scott пишет:
> > Hi George,
> >
> > Sorry for the delay replying to your message.
> >
> > > I am using XenAPI for a long time. We have found some performance
> > > issues
> > > with XenAPI: the conversion from OpaqueRef to UUID. Each OpaqueRef
> > > should be resolved manually, and this almost doubles request amount.
> > >
> > > I got used to them, but I still do not understand why they was
> > > introduced in XenAPI.
> > >
> > > Could someone describe me the reason behind OpaqueRefs? Why they
> are
> > > only valid within a single session? Why they are added in the fist
> > > place?
> >
> > Here's a brief history of what happened:
> >
> > First we wanted to create an API for managing VMs, VIFs, VBDs etc. We
> thought we would have VMs etc being objects and "references" would be
> the primary way to name them. We wanted to reserve the right to change
> what a reference looks like, so that we could maybe encode some (eg)
> security-related information (like a capability) or some scope-related
> information (eg if you had nested pools) in the future. To discourage
> people from looking at the actual strings too much, we put the prefix
> "OpaqueRef" on as a warning :)
> >
> > So far, everything is relatively clean.
> >
> > Since xen domains have uuids, we added a VM.uuid field. I think we
> also added a VDI.uuid field at this point -- with hindsight this was a
> mistake. We believed that each storage type could use a uuid to
> identify a disk but it turned out that some storage types had nowhere
> convenient to actually store the information so it could be retrieved
> efficiently. We added a VDI.location field to contain the most
> appropriate primary key to identify a VDI within an SR and the VDI.uuid
> field became a bit vestigial.
> >
> > So far, everything is still ok.
> >
> > We then started developing the "xe" cli. At this point we made the
> crucial decision that OpaqueRef: strings were just too visually ugly to
> use in a commandline interface and decided to name objects by uuid.
> This was fine for VMs and VDIs but nothing else had a uuid field.
> Inevitably we then added uuids to other objects so now they're almost
> ubiquitous.
> >
> > Now we have two parallel object naming mechanisms which is a bit
> strange. My current rule of thumb is that: whenever I'm using the
> XenAPI directly (eg in python) I will use refs exclusively (no uuids).
> When I write scripts that use the "xe" CLI I will use uuids exclusively
> (no refs).
> >
> > Does that make sense (even if it is a little bit unfortunate!)?
> >
> > Cheers,
> > Dave

xen-api mailing list
<Prev in Thread] Current Thread [Next in Thread>