Medlyn, Dayne (VSL - Ft Collins) wrote:
Kaitlin,
Just a follow-up. I think your idea of adding a release attribute is a good one. All three values (release, revision, and changeset) would allow a more precise way to pin functionality to builds. I would expect the release to reflect the latest official release number (currently 0.5.2 I believe) with the running revisions and changesets demarking changes off the release, i.e. currently: release 0.5.2, revision 875, changeset: cde25ad65c74+.
Sure - I think it would be useful as well. It would give you a base version and then the revision / changeset can get you a hint of what patches might be included on top of the release. I'll see if I can get that worked up in the next day or two. Just to note - the current release is 0.5.5. Revision 883, changeset 10e45fca47f0.
Thanks for all your help.
Dayne
-----Original Message----- From: libvirt-cim-bounces@redhat.com [mailto:libvirt-cim- bounces@redhat.com] On Behalf Of Kaitlin Rupert Sent: Wednesday, May 20, 2009 3:51 PM To: List for discussion and development of libvirt CIM Subject: Re: [Libvirt-cim] What does NumberOfBlocks and ConsumableBlocks in the Xen_Memory class represent?
Kaitlin,
Do you know if I can rely on a standard format for the Revision field, in VirtualSystemManagementService class? Looking at the code I see it is provided as a build variable "-DLIBVIRT_CIM_RV=" that gets set in
Medlyn, Dayne (VSL - Ft Collins) wrote: the acinclude.m4 script.
I suppose any of the distributions can label this any way they see fit. Right - the distros have control over how they wish to set this value.
So far I have seen:
SLES11: 0.5.2 RHEL5.3: 613+ Upstream, we use the changeset and the revision numbers from mercurial. The problem the distros face is that that they may be using 0.5.2 as a base, but they will have their own patches applied - some from upstream libvirt-cim and some from in house.
Our 0.4.1 build: 590 Current testing builds: 875
Any thought on any standard format? I don't know of an easy way to force a standard format since its up to the distros discretion to change whatever method we go with.
It might be possible to use a combination of the distro package version and the Revision values from the VirtualSystemManagementService class.
Do you know what the build number was for 0.5.1 (somewhere between 590 and 613)? At the moment I am planning to handle the x.x.x and x\D+ cases. If anyone has any other thoughts or experiences I am open to them.
0.5.1 is 657 - you can check out the release versions at: http://libvirt.org/hg/libvirt-cim/tags
613 is somewhere between 0.4.0 (590) and 0.5.0 (632).
Unfortunately, I'm not coming up with an easy way as to how to handle the difference in the distros. We have to detect the libvirt version, which we do using a acinclude.m4 based on the version the distro reports. That might be a more reliable way, but it's less dynamic.
We could add a release attribute to libvirt-cim (in addition to the changeset and revision values), but that won't help you with existing versions.
Thanks.
Dayne
Just for confirmation, does this mean that for anything 0.5.1 and newer I should expect: -NumberOfBlocks the maximum memory allocated to the guest -ConsumableBlocks the memory currently assigned to the guest
And for anything older than 0.5.1 I should expect:
-NumberOfBlocks the memory currently assigned to the guest -ConsumableBlocks the maximum memory allocated to the guest Yes, that's correct. We're one the same page here. Sorry for the confusing detour there. ;)
-- Kaitlin Rupert IBM Linux Technology Center kaitlin@linux.vnet.ibm.com
_______________________________________________ Libvirt-cim mailing list Libvirt-cim@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-cim
_______________________________________________ Libvirt-cim mailing list Libvirt-cim@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-cim
-- Kaitlin Rupert IBM Linux Technology Center kaitlin@linux.vnet.ibm.com