Thank you.
I wrote an article in xenwiki:
http://wiki.xensource.com/xenwiki/OpaqueRef_and_uuid_relationship_in_xapi
As usual, I do some ugly mistakes in Enlish texts, so I hope for some
polishing from community.
В Птн, 01/04/2011 в 20:55 +0100, Dave Scott пишет:
> 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
|
Home