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>, "xen-api@xxxxxxxxxxxxxxxxxxx" <xen-api@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-API] XenAPI: Why OpaqueRef instead direct UUID
From: Dave Scott <Dave.Scott@xxxxxxxxxxxxx>
Date: Fri, 1 Apr 2011 18:31:35 +0100
Accept-language: en-US
Acceptlanguage: en-US
Delivery-date: Fri, 01 Apr 2011 10:31:51 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1300810180.2402.35.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>
Sender: xen-api-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acvoq5+EJ5fMUo94Rw+7PqwjgLCIswH5Jrrg
Thread-topic: [Xen-API] XenAPI: Why OpaqueRef instead direct UUID
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!)?

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