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

[Dave Scott <Dave.Scott@xxxxxxxxxxxxx>]

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?

Yes.

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 :-)

Cheers,
Dave

> 
> ---
> 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