[PATCH] SD doesn't return instances in all cases
by Kaitlin Rupert
# HG changeset patch
# User Kaitlin Rupert <karupert(a)us.ibm.com>
# Date 1196460977 28800
# Node ID 1776beb36f5cffcfad4e581a8841f77f20bc3927
# Parent d5af3e219c22e8b32de64c69a29aea970ab6a9a4
SD doesn't return instances in all cases.
Virt_SystemDevice doesn't return instances when CIM_ManagedElement is passed as a result class argument. This only applies to the VM to device case (see failint query below).
The problem is that we use the result class to determine which device type to return. If no result class is specified, we return all associated devices. However, if CIM_ManagedElement is specified, we are unable to match the device type, and we return nothing.
I think all of this can be removed because filter_results() in libcmpiutil should remove the need for this kind of checking.
Failing query:
wbemcli ain -ac Xen_SystemDevice -arc CIM_ManagedElement 'http://root:elm3b41@localhost/root/virt:Xen_ComputerSystem.CreationClassN..."Xen_ComputerSystem",Name="Domain-0"'
Signed-off-by: Kaitlin Rupert <karupert(a)us.ibm.com>
diff -r d5af3e219c22 -r 1776beb36f5c src/Virt_SystemDevice.c
--- a/src/Virt_SystemDevice.c Fri Nov 30 11:33:21 2007 -0800
+++ b/src/Virt_SystemDevice.c Fri Nov 30 14:16:17 2007 -0800
@@ -171,22 +171,10 @@ static CMPIStatus sys_to_dev(const CMPIO
goto out;
}
- if (info->result_class) {
- int type;
-
- type = device_type_from_classname(info->result_class);
-
- ret = get_dom_devices(host,
- list,
- type,
- CLASSNAME(ref),
- NAMESPACE(ref));
- } else {
- ret = get_all_devices(host,
- list,
- CLASSNAME(ref),
- NAMESPACE(ref));
- }
+ ret = get_all_devices(host,
+ list,
+ CLASSNAME(ref),
+ NAMESPACE(ref));
if (ret >= 0) {
CMSetStatus(&s, CMPI_RC_OK);
17 years
[PATCH] Add patching guidelines to site
by Jay Gagnon
# HG changeset patch
# User Jay Gagnon <grendel(a)linux.vnet.ibm.com>
# Date 1196783327 18000
# Node ID 1a3e2e6e3ec15d8f600eb21477e18b6a48ccb2df
# Parent d182b5a3324feb2d8403d995f8208f8e0057aa6d
Add patching guidelines to site.
Signed-off-by: Jay Gagnon <grendel(a)linux.vnet.ibm.com>
diff -r d182b5a3324f -r 1a3e2e6e3ec1 doc/Makefile.am
--- a/doc/Makefile.am Mon Dec 03 11:22:46 2007 -0500
+++ b/doc/Makefile.am Tue Dec 04 10:48:47 2007 -0500
@@ -5,6 +5,7 @@ WEB_PAGES = index.html \
downloads.html \
intro.html \
news.html \
+ patches.html \
platforms.html \
schema.html
diff -r d182b5a3324f -r 1a3e2e6e3ec1 doc/libvirt-cim.html
--- a/doc/libvirt-cim.html Mon Dec 03 11:22:46 2007 -0500
+++ b/doc/libvirt-cim.html Tue Dec 04 10:48:47 2007 -0500
@@ -57,6 +57,183 @@
<a href="http://libvirt.org/hg/libvirt-cim/archive/tip.tar.gz">tarball</a> or
<a href="http://libvirt.org/hg/libvirt-cim/archive/tip.zip">zip</a>
file snapshot of the repository.
+</p>
+
+<h2><a name="Patches">Patches</a></h2>
+
+<p>To submit patches to libvirt-cim, you must follow the DCO process, outlined
+below:</p>
+
+<h3>Developer's Certificate of Origin 1.1</h3>
+<p>By making a contribution to this project, I certify that:</p>
+<ol>
+<li>
+ <p>
+ The contribution was created in whole or in part by me and I
+ have the right to submit it under the open source license indicated in
+ the file; or
+ </p>
+</li>
+<li>
+ <p>
+ The contribution is based upon previous work that, to the best of my
+ knowledge, is covered under an appropriate open source license and I have the
+ right under that license to submit that work with modifications, whether
+ created in whole or in part by me, under the same open source license
+ (unless I am permitted to submit under a different license), as indicated in
+ the file; or
+ </p>
+</li>
+<li>
+ <p>
+ The contribution was provided directly to me by some other person who
+ certified (1), (2) or (3) and I have not modified it.
+ </p>
+</li>
+<li>
+ <p>
+ I understand and agree that this project and the contribution are public and
+ that a record of the contribution (including all personal information I
+ submit with it, including my sign-off) is maintained indefinitely and may be
+ redistributed consistent with this project or the open source license(s)
+ involved.
+ </p>
+</li>
+</ol>
+
+<p>then you just add a line saying</p>
+
+<p style="text-align:center">
+ Signed-off-by: Random J Developer <random(a)developer.example.org>
+</p>
+
+<p>using your real name (sorry, no pseudonyms or anonymous contributions.)</p>
+
+<h3>Guidelines for Submitting Patches.</h3>
+<p>
+ Patches should be submitted using Mercurial's patchbomb extension, and we
+ recommend using the queues extension as well. On top of that, we have some
+ guidelines you should follow when submitting patches. This makes reviewing
+ patches easier, which in turns improves the chances of your patch being
+ accepted in a timely fashion.
+</p>
+<p>
+ For help on how to use the patchbomb extension, see
+ <a href="http://hgbook.red-bean.com/hgbookch14.html">Section 14.4</a> of <i>
+ Distributed revision control with Mercurial</i>.
+</p>
+<p>
+ For help on the queues extension, see
+ <a href="http://hgbook.red-bean.com/hgbookch12.html">Chapter 12</a>.
+</p>
+
+<h4>Single Patches:</h4>
+<ol>
+<li>
+ <p>
+ When you add a patch to the queue you have an idea of where you're going with
+ it, and the commit message should reflect that. Be specific. Avoid just
+ saying something like, "Various fixes to AllocationCapabilities." Add a list
+ of what was actually fixed, like, "Add EnumInstanceNames support," and,
+ "Eliminate duplicate instances."
+</p>
+</li>
+<li>
+ <p>
+ The first line of your commit message will be the subject of the patch email
+ when you send it out, so write it like a subject. Keep it short and to the
+ point, then start a new line and feel free to be as verbose as you need to
+ be. The entire commit message will be included in the patch.
+ </p>
+</li>
+<li>
+ <p>
+ Stay on task with a patch. If you notice other problems while you are
+ working on a patch, and they are not most definitely specific to your patch,
+ they should be another patch. The same goes for nitpicking. While it might
+ be only a line or two here and there that is off track, this is actually one
+ of the easiest ways to make a patch difficult to review. All the trivial
+ changes hide what is really going on. Make the unrelated changes a new
+ patch or don't make them at all.
+ </p>
+</li>
+<li>
+ <p>
+ If your patch addresses a strange issue or a rare edge case that the
+ reviewers are unlikely to be familiar with, make sure the commit message
+ include some example testcase with results, so the reviewers can verify
+ your patch more quickly.
+ </p>
+</li>
+<li>
+ <p>
+ Before you email, export. If you have a patch called "alloc_fixes", which
+ would be emailed with "hg email alloc_fixes", you should first run "hg export
+ alloc_fixes". This lets you review your patch. Does it have any typos in
+ the comments? Did you accidentally include an irrelevant change? Is your
+ commit message still accurate and useful? This is the single biggest step in
+ ensuring you have a good patch.
+ </p>
+</li>
+<li>
+ <p>
+ If your patch needs to be reworked and resent, prepend a "version number" to
+ the first line of the commit message. For example, "Add EnumInstance to
+ RASD," becomes "#2 Add EnumInstance to RASD." This helps mail readers thread
+ discussions correctly and helps maintainers know they are applying the right
+ version of your patch. At the end of the commit message, explain what is
+ different from one version to the next. Nobody likes having to diff a diff.
+ </p>
+</li>
+<li>
+ <p>
+ If your patch depends on a patch that exists on the mailing list but not in
+ the tree, it is okay to send your patch to the list as long as your commit
+ message mentions the dependency. It is also a good idea to import the
+ patch into your tree before you make your patch. For example, a new patch
+ called "cu_statusf API change" is on the list, and your patch needs the new
+ API. Save the email (no need to trim headers) as api_change.eml, then do
+ "hg qimport api_change.eml" and "hg qpush" so that the patch is applied to
+ your tree. Now write your patch on top of it. You should still indicate
+ the dependency in your commit message.
+</li>
+</ol>
+
+<h4>Patchsets:</h4>
+<ol>
+<li>
+ <p>
+ When you send a group of patches, Mercurial's email extension will create a
+ "header" email. Make the subject and body of that email meaningful, so we
+ know how the patches relate. It's easy to say, "Each patch has a commit
+ message, it's obvious how they work together," but the rest of the list
+ usually won't agree with that. If the commit messages for each patch are
+ good, you shouldn't need more than a sentence or two to tie them all
+ together, but you do need it.
+ </p>
+</li>
+<li>
+ <p>
+ If any of your patches are rejected and you rework them, resend the entire
+ set. This prevents things like, "So use patch 1 of 4 from the set I sent
+ yesterday, 2 and 3 of 4 from the patch I sent an hour later, and patch 4
+ of 4 from today."
+ </p>
+</li>
+<li>
+ <p>
+ If you resend a patchset, apply part (6) of the Single Patches guidelines to
+ your "Patch [0 of 3]" header email, for all the same reasons.
+ </p>
+</li>
+</ol>
+
+<p>Questions/Comments on the Guidelines should be directed to:</p>
+<p>
+ Jay Gagnon
+ <a href="mailto:grendel@linux.vnet.ibm.com">grendel(a)linux.vnet.ibm.com</a>
+ <br>
+ Patch Compliance Officer
</p>
<h2><a name="Schema">Schema</a></h2>
diff -r d182b5a3324f -r 1a3e2e6e3ec1 doc/site.xsl
--- a/doc/site.xsl Mon Dec 03 11:22:46 2007 -0500
+++ b/doc/site.xsl Tue Dec 04 10:48:47 2007 -0500
@@ -50,6 +50,9 @@
</xsl:when>
<xsl:when test="$name = '#Schema'">
<xsl:text>schema.html</xsl:text>
+ </xsl:when>
+ <xsl:when test="$name = '#Patches'">
+ <xsl:text>patches.html</xsl:text>
</xsl:when>
<xsl:when test="$name = ''">
<xsl:text>unknown.html</xsl:text>
17 years
[PATCH 0 of 9] Reorganized association provider registration
by Heidi Eckhart
The association provider was registered for each subclass with a different
name. That caused duplicated instances as the same provider gets
called twice, but has no chance to figure out for which registration. This
patch set tries to fix it. Please review. Thanks.
Based on:
- #2 Fix (again) VSMCaps and ElementCap
- Remove devid-style InstanceID support from ELEC and EC
17 years
[PATCH 00 of 12] #3 - Adoption of changes to std_assoc struct in std_association for all associations
by Heidi Eckhart
Sorry saw Kaitlin's comments too late :(.
This is the follow up patch to the API changes made in
std_association. The struct std_assoc does now take lists
for source, target and assoc classnames.
Diff tp patch set #1:
- fixed SD: former patch specified HostSystem as group_component instead of ComputerSystem
- fixed HS: class ResourcePoolConfigurationService was missing for dependent
- fixed SDC: fixed check against CMPIRc in alloc_cap_to_rasd; this still needs to be fixed in another patch, as ResourceType is no key property but is handled as one
Diff to patch set #2:
- fixed RAFP: need to specify subclasses of ResourceAllocationSettingData
- fixed: SDS: need to specify subclasses of ResourceAllocationSettingData
- fixed VSSDC: need to specify subclasses of ResourceAllocationSettingData
17 years
[PATCH] Patch guidelines added to SubmittingPatches
by Jay Gagnon
# HG changeset patch
# User Jay Gagnon <grendel(a)linux.vnet.ibm.com>
# Date 1196350280 18000
# Node ID a4193d586c20dd4aa9767f1299d9a1e91c0786a8
# Parent c478a5b30689a80159588c8f914ac97263694372
Patch guidelines added to SubmittingPatches.
I did a bit of editing from the original suggestions, so any grammar-minded people should probably run through it once. I also incorporated the following from the team call:
The two "stay on track"-style rules were merged.
Patch numbering for resends was expanded to all patches, not just patchsets.
Including an example test for edge cases was added.
Patch dependency handling was added.
Signed-off-by: Jay Gagnon <grendel(a)linux.vnet.ibm.com>
diff -r c478a5b30689 -r a4193d586c20 doc/SubmittingPatches
--- a/doc/SubmittingPatches Wed Nov 28 11:06:22 2007 -0800
+++ b/doc/SubmittingPatches Thu Nov 29 10:31:20 2007 -0500
@@ -33,3 +33,91 @@ using your real name (sorry, no pseudony
using your real name (sorry, no pseudonyms or anonymous contributions.)
+
+Guidelines for Submitting Patches.
+
+ Patches should be submitted using Mercurial's patchbomb extension,
+ and we recommend using the queues extension as well. On top of that,
+ we have some guidelines you should follow when submitting patches.
+ This makes reviewing patches easier, which in turns improves the
+ chances of your patch being accepted in a timely fashion.
+
+Single Patches:
+
+ (a) When you add a patch to the queue you have an idea of where you're
+ going with it, and the commit message should reflect that. Be
+ specific. Avoid just saying something like, "Various fixes to
+ AllocationCapabilities." Add a list of what was actually fixed,
+ like, "Add EnumInstanceNames support," and, "Eliminate duplicate
+ instances."
+
+ (b) The first line of your commit message will be the subject of the
+ patch email when you send it out, so write it like a subject. Keep
+ it short and to the point, then start a new line and feel free to be
+ as verbose as you need to be. The entire commit message will be
+ included in the patch.
+
+ (c) Stay on task with a patch. If you notice other problems while you
+ are working on patch, and they are not most definitely specific to
+ your patch, they should be another patch. The same goes for
+ nitpicking. While it might be only a line or two here and there
+ that is off track, this is actually one of the easiest ways to make
+ a patch difficult to review. All the trivial changes hide what is
+ really going on. Make the unrelated changes a new patch or don't
+ make them at all.
+
+ (d) If your patch addresses a strange issue or a rare edge case that
+ the reviewers are unlikely to be familiar with, make sure the commit
+ message include some example testcase with results, so the reviewers
+ can verify your patch more quickly.
+
+ (e) Before you email, export. If you have a patch called "alloc_fixes",
+ which would be emailed with "hg email alloc_fixes", you should first
+ run "hg export alloc_fixes". This lets you review your patch. Does
+ it have any typos in the comments? Did you accidentally include an
+ irrelevant change? Is your commit message still accurate and useful?
+ This is the single biggest step in ensuring you have a good patch.
+
+ (f) If your patch needs to be reworked and resent, prepend a "version
+ number" to the first line of the commit message. For example, "Add
+ EnumInstance to RASD," becomes "#2 Add EnumInstance to RASD." This
+ helps mail readers thread discussions correctly and helps
+ maintainers know they are applying the right version of your patch.
+ At the end of the commit message, explain what is different from one
+ version to the next. Nobody likes having to diff a diff.
+
+ (g) If your patch depends on a patch that exists on the mailing list but
+ not in the tree, it is okay to send your patch to the list as long
+ as your commit message mentions the dependency. It is also a good
+ idea to import the patch into your tree before you make your patch.
+ For example, a new patch called "cu_statusf API change" is on the
+ list, and your patch needs the new API. Save the email (no need to
+ trim headers) as api_change.eml, then do "hg qimport api_change.eml"
+ and "hg qpush" so that the patch is applied to your tree. Now write
+ your patch on top of it. You should still indicate the dependency
+ in your commit message.
+
+
+Patchsets:
+
+ (a) When you send a group of patches, Mercurial's email extension will
+ create a "header" email. Make the subject and body of that email
+ meaningful, so we know how the patches relate. It's easy to say,
+ "Each patch has a commit message, it's obvious how they work
+ together," but the rest of the list usually won't agree with that.
+ If the commit messages for each patch are good, you shouldn't need
+ more than a sentence or two to tie them all together, but you do
+ need it.
+
+ (b) If any of your patches are rejected and you rework them, resend the
+ entire set. This prevents things like, "So use patch 1 of 4 from
+ the set I sent yesterday, 2 and 3 of 4 from the patch I sent an hour
+ later, and patch 4 of 4 from today."
+
+ (c) If you resend a patchset, apply part (f) of the Single Patches
+ guidelines to your "Patch [0 of 3]" header email, for all the same
+ reasons.
+
+Questions/Comments on the Guidelines should be directed to:
+Jay Gagnon <grendel(a)linux.vnet.ibm.com>
+Patch Compliance Officer
\ No newline at end of file
17 years
[PATCH 0 of 2] #2 Fix (again) VSMCaps and ElementCaps
by Dan Smith
There was a lot of cruft in both VSMCaps and ElementCaps around generating
a dynamic InstanceID with the HostSystem.Name in it that is really not
necessary.
This set just changes to a static InstanceID for VSMCaps and removes all
the supporting code that it obviates.
Changes:
- Just a rebase on tip
17 years
