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