- CIM - libvirt List Archives

[PATCH 00 of 12] #3 - Adoption of changes to std_assoc struct in std_association for all associations
by Heidi Eckhart 03 Dec '07

03 Dec '07

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

3 16

[PATCH 0 of 2] Remove devid-style InstanceID support from ELEC and EC.
by Kaitlin Rupert 03 Dec '07

03 Dec '07

Removed devid-style InstanceID support from ELEC - this class now uses just the name of domain. This caused a needed update in EC - cap_to_cs() no longer needs to parse devid-style InstanceIDs.

2 5

[PATCH 0 of 2] Added Association declaration to mof
by Heidi Eckhart 03 Dec '07

03 Dec '07

The qualifier [Association] was missing in the mof for ElementSettingData and HostedSystem.

2 3

[PATCH] Patch guidelines added to SubmittingPatches
by Jay Gagnon 03 Dec '07

03 Dec '07

# 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

3 6

Failing qurey of VirtualSystemManagementCapabilities in Pegasus
by Guo Lian Yun 03 Dec '07

03 Dec '07

Hi, I try to test VirtualSystemManagementCapabilities and get results as follows: Failing queries in Pegasus: wbemein http://root:password@localhost/root/virt:Xen_VirtualSystemManagementCapabil… The return results list below, and that make tog-pegasus stop. * * wbemein: Http Exception: server returned nothing (no headers, no data) * However, I can get expected results in sfcb. wbemein http://root:password@localhost/root/virt:Xen_VirtualSystemManagementCapabil… localhost:5988/root/virt:Xen_VirtualSystemManagementCapabilities.InstanceID="zeit/0" Best, Regards Daisy Guo Lian Yun E-mail: yunguol(a)cn.ibm.com IBM China Development Lab, Shanghai, China TEL: (86)-21-61008057

2 1

[PATCH 0 of 2] #2 Fix (again) VSMCaps and ElementCaps
by Dan Smith 03 Dec '07

03 Dec '07

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

3 4

Failing qurey of EnabledLogicalElementCapabilities in Pegasus
by daisy 03 Dec '07

03 Dec '07

Hi, I try to test EnabledLogicalElementCapabilities and get results as follows: Failing queries in Pegasus: wbemein http://root:password@localhost/root/virt:Xen_EnabledLogicalElementCapabilit… * * wbemein: Http Exception: server returned nothing (no headers, no data) * However, I can get expected results in sfcb. wbemein http://root:password@localhost/root/virt:Xen_EnabledLogicalElementCapabilit… localhost:5988/root/virt:Xen_EnabledLogicalElementCapabilities.InstanceID="Domain-0/0" Best, Regards Daisy Guo Lian Yun E-mail: yunguol(a)cn.ibm.com IBM China Development Lab, Shanghai, China TEL: (86)-21-61008057

1 0

Failing qurey of VirtualSystemManagementCapabilities in Pegasus
by daisy 03 Dec '07

03 Dec '07

Hi, I try to test VirtualSystemManagementCapabilities and get results as follows: Failing queries in Pegasus: wbemein http://root:password@localhost/root/virt:Xen_VirtualSystemManagementCapabil… The return results list below, and that make tog-pegasus stop. * * wbemein: Http Exception: server returned nothing (no headers, no data) * However, I can get expected results in sfcb. wbemein http://root:password@localhost/root/virt:Xen_VirtualSystemManagementCapabil… localhost:5988/root/virt:Xen_VirtualSystemManagementCapabilities.InstanceID="zeit/0" Best, Regards Daisy Guo Lian Yun E-mail: yunguol(a)cn.ibm.com IBM China Development Lab, Shanghai, China TEL: (86)-21-61008057

1 0

[PATCH] SDC doesn't support specific RASD classes
by Kaitlin Rupert 03 Dec '07

03 Dec '07

# HG changeset patch # User Kaitlin Rupert <karupert(a)us.ibm.com> # Date 1196451201 28800 # Node ID d5af3e219c22e8b32de64c69a29aea970ab6a9a4 # Parent 6515e4a1c90bba936fa1a15ddf2f501491e16fb5 SDC doesn't support specific RASD classes. Instead of using Xen_ResourceAllocationSettingData / KVM_ResourceAllocationSettingData in the resource_allocation_setting_data list, we should use specific RASD class names so that specifying a specific RASD class as a result class is supported. I also missed this one while reviewing Heidi's patches. Signed-off-by: Kaitlin Rupert <karupert(a)us.ibm.com> diff -r 6515e4a1c90b -r d5af3e219c22 src/Virt_SettingsDefineCapabilities.c --- a/src/Virt_SettingsDefineCapabilities.c Fri Nov 30 10:43:37 2007 -0800 +++ b/src/Virt_SettingsDefineCapabilities.c Fri Nov 30 11:33:21 2007 -0800 @@ -847,8 +847,14 @@ char* group_component[] = { }; char* part_component[] = { - "Xen_ResourceAllocationSettingData", - "KVM_ResourceAllocationSettingData", + "Xen_DiskResourceAllocationSettingData", + "Xen_MemResourceAllocationSettingData", + "Xen_NetResourceAllocationSettingData", + "Xen_ProcResourceAllocationSettingData", + "KVM_DiskResourceAllocationSettingData", + "KVM_MemResourceAllocationSettingData", + "KVM_NetResourceAllocationSettingData", + "KVM_ProcResourceAllocationSettingData", NULL };

3 2

[PATCH] ESD does not support specific result clases properly
by Kaitlin Rupert 03 Dec '07

03 Dec '07

# HG changeset patch # User Kaitlin Rupert <karupert(a)us.ibm.com> # Date 1196448217 28800 # Node ID 6515e4a1c90bba936fa1a15ddf2f501491e16fb5 # Parent a10df58ddd0ed7f8e905ce21a28a5e585fd304ff ESD does not support specific result clases properly. Specifying a result class of Xen_VirtualSystemSettingData does not work (see query below), however a result class of CIM_ManagedElement does work. This is because I tried to make this provider accept both generic and specific result classes. Heidi's libcmpiutil API update makes it so that the providers don't need to be concerned with handling more generic cases (CIM_ManagedElement, CIM_VirtualSystemSettingData, etc). Also, I missed this during Heidi's patch review - instead of using Xen_ResourceAllocationSettingData / KVM_ResourceAllocationSettingData in the resource_allocation_setting_data list, we should use specific RASD class names so that specifying a specific RASD class as a result class is supported. See below for failing query. Failing queries: wbemcli ain -ac Xen_ElementSettingData -arc Xen_VirtualSystemSettingData 'http://root:elm3b41@localhost/root/virt:Xen_VirtualSystemSettingData.Instan…"Xen:Domain-0"' wbemcli ain -ac Xen_ElementSettingData -arc Xen_ProcResourceAllocationSettingData 'http://root:elm3b41@localhost/root/virt:Xen_ProcResourceAllocationSettingDa…"Domain-0/3"' Signed-off-by: Kaitlin Rupert <karupert(a)us.ibm.com> diff -r a10df58ddd0e -r 6515e4a1c90b src/Virt_ElementSettingData.c --- a/src/Virt_ElementSettingData.c Fri Nov 30 11:40:21 2007 +0100 +++ b/src/Virt_ElementSettingData.c Fri Nov 30 10:43:37 2007 -0800 @@ -178,13 +178,14 @@ char* virtual_system_setting_data[] = { }; char* resource_allocation_setting_data[] = { - "Xen_ResourceAllocationSettingData", - "KVM_ResourceAllocationSettingData", - NULL -}; - -char* managed_element[] = { - "CIM_ManagedElement", + "Xen_DiskResourceAllocationSettingData", + "Xen_MemResourceAllocationSettingData", + "Xen_NetResourceAllocationSettingData", + "Xen_ProcResourceAllocationSettingData", + "KVM_DiskResourceAllocationSettingData", + "KVM_MemResourceAllocationSettingData", + "KVM_NetResourceAllocationSettingData", + "KVM_ProcResourceAllocationSettingData", NULL }; @@ -198,7 +199,7 @@ static struct std_assoc _vssd_to_vssd = .source_class = (char**)&virtual_system_setting_data, .source_prop = "ManagedElement", - .target_class = (char**)&managed_element, + .target_class = (char**)&virtual_system_setting_data, .target_prop = "SettingData", .assoc_class = (char**)&assoc_classname, @@ -211,7 +212,7 @@ static struct std_assoc _rasd_to_rasd = .source_class = (char**)&resource_allocation_setting_data, .source_prop = "ManagedElement", - .target_class = (char**)&managed_element, + .target_class = (char**)&resource_allocation_setting_data, .target_prop = "SettingData", .assoc_class = (char**)&assoc_classname,

3 2