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

[George Shuklin <george.shuklin@xxxxxxxxx>]

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?

Thanks again.

PS Can I post this reply to Xen wiki? I think it will be very userfull
for XenAPI users.

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