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

[Dave Scott <Dave.Scott@xxxxxxxxxxxxx>]

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
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/mailman/listinfo/xen-api