[PATCH] Fix indication_tester's filter deletion issue
# HG changeset patch # User Jay Gagnon <grendel@linux.vnet.ibm.com> # Date 1205167743 14400 # Node ID 4b34c7474e59f939200cdfeaa7d3414cfc6f7c13 # Parent d93bb8c00423a88f1c9475a8e6076b1945e1dd01 Fix indication_tester's filter deletion issue A while ago we discovered that giving the same name to various tests in indication_tester doesn't work, even when the first test's filter, handler, and subscription should have been deleted once it was done running. It turns out that indication_tester wasn't deleting the filter, due to some bad xml. This fixes the xml and eliminates the need to use the -n switch unless you want multiple simultaneous tests. Signed-off-by: Jay Gagnon <grendel@linux.vnet.ibm.com> diff -r d93bb8c00423 -r 4b34c7474e59 tools/indication_tester.py --- a/tools/indication_tester.py Mon Mar 03 06:48:26 2008 -0800 +++ b/tools/indication_tester.py Mon Mar 10 12:49:03 2008 -0400 @@ -181,7 +181,7 @@ def delete_inst_xml(name, type, sysname) <NAMESPACE NAME="PG_InterOp"/> </LOCALNAMESPACEPATH> <IPARAMVALUE NAME="InstanceName"> - <INSTANCENAME CLASSNAME="CIM_Indication%sCIMXML"> + <INSTANCENAME CLASSNAME="CIM_Indication%s"> <KEYBINDING NAME="SystemCreationClassName"> <KEYVALUE>CIM_ComputerSystem</KEYVALUE> </KEYBINDING> @@ -189,7 +189,7 @@ def delete_inst_xml(name, type, sysname) <KEYVALUE>%s</KEYVALUE> </KEYBINDING> <KEYBINDING NAME="CreationClassName"> - <KEYVALUE>CIM_Indication%sCIMXML</KEYVALUE> + <KEYVALUE>CIM_Indication%s</KEYVALUE> </KEYBINDING> <KEYBINDING NAME="Name"> <KEYVALUE>%s%s</KEYVALUE>
JG> diff -r d93bb8c00423 -r 4b34c7474e59 tools/indication_tester.py JG> --- a/tools/indication_tester.py Mon Mar 03 06:48:26 2008 -0800 JG> +++ b/tools/indication_tester.py Mon Mar 10 12:49:03 2008 -0400 JG> @@ -181,7 +181,7 @@ def delete_inst_xml(name, type, sysname) JG> <NAMESPACE NAME="PG_InterOp"/> JG> </LOCALNAMESPACEPATH> JG> <IPARAMVALUE NAME="InstanceName"> JG> - <INSTANCENAME CLASSNAME="CIM_Indication%sCIMXML"> JG> + <INSTANCENAME CLASSNAME="CIM_Indication%s"> JG> <KEYBINDING NAME="SystemCreationClassName"> JG> <KEYVALUE>CIM_ComputerSystem</KEYVALUE> JG> </KEYBINDING> JG> @@ -189,7 +189,7 @@ def delete_inst_xml(name, type, sysname) JG> <KEYVALUE>%s</KEYVALUE> JG> </KEYBINDING> JG> <KEYBINDING NAME="CreationClassName"> JG> - <KEYVALUE>CIM_Indication%sCIMXML</KEYVALUE> JG> + <KEYVALUE>CIM_Indication%s</KEYVALUE> JG> </KEYBINDING> JG> <KEYBINDING NAME="Name"> JG> <KEYVALUE>%s%s</KEYVALUE> Can you explain why the XML was wrong and why this fixes it? Thanks! -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@us.ibm.com
Dan Smith wrote:
Can you explain why the XML was wrong and why this fixes it?
Sure. I used -d to see what xml was actually going across for the filter. The create xml started off like this: <?xml version="1.0" encoding="utf-8"?> <CIM CIMVERSION="2.0" DTDVERSION="2.0"> <MESSAGE ID="4711" PROTOCOLVERSION="1.0"> <SIMPLEREQ> <IMETHODCALL NAME="CreateInstance"> <LOCALNAMESPACEPATH> <NAMESPACE NAME="root"/> <NAMESPACE NAME="PG_InterOp"/> </LOCALNAMESPACEPATH> <IPARAMVALUE NAME="NewInstance"> <INSTANCE CLASSNAME="CIM_IndicationFilter"> And then the corresponding delete xml started off like this: <?xml version="1.0" encoding="utf-8"?> <CIM CIMVERSION="2.0" DTDVERSION="2.0"> <MESSAGE ID="4711" PROTOCOLVERSION="1.0"> <SIMPLEREQ> <IMETHODCALL NAME="DeleteInstance"> <LOCALNAMESPACEPATH> <NAMESPACE NAME="root"/> <NAMESPACE NAME="PG_InterOp"/> </LOCALNAMESPACEPATH> <IPARAMVALUE NAME="InstanceName"> <INSTANCENAME CLASSNAME="CIM_IndicationFilterCIMXML"> The classnames don't match up, so when we make the delete request the CIMOM can't find the right instance to delete. Both handler and subscription have the classnames properly matched, so they get created and deleted properly. Now the one other thing I noticed is that handler and subscription have the CIMXML suffix on both create and delete, so maybe the more correct solution is to add it to the filter create, not remove it from the filter delete. Do we have anything official that can answer that for us? -- -Jay
JG> The classnames don't match up, so when we make the delete request JG> the CIMOM can't find the right instance to delete. Ah, excellent. JG> Both handler and subscription have the classnames properly JG> matched, so they get created and deleted properly. Now the one JG> other thing I noticed is that handler and subscription have the JG> CIMXML suffix on both create and delete, so maybe the more correct JG> solution is to add it to the filter create, not remove it from the JG> filter delete. Do we have anything official that can answer that JG> for us? The create is obviously working, so making the delete use the same classname is the proper approach. Thanks! -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@us.ibm.com
Jay Gagnon wrote:
Dan Smith wrote:
Can you explain why the XML was wrong and why this fixes it?
Sure. I used -d to see what xml was actually going across for the filter. The create xml started off like this: <?xml version="1.0" encoding="utf-8"?> <CIM CIMVERSION="2.0" DTDVERSION="2.0"> <MESSAGE ID="4711" PROTOCOLVERSION="1.0"> <SIMPLEREQ> <IMETHODCALL NAME="CreateInstance"> <LOCALNAMESPACEPATH> <NAMESPACE NAME="root"/> <NAMESPACE NAME="PG_InterOp"/> </LOCALNAMESPACEPATH> <IPARAMVALUE NAME="NewInstance"> <INSTANCE CLASSNAME="CIM_IndicationFilter">
And then the corresponding delete xml started off like this: <?xml version="1.0" encoding="utf-8"?> <CIM CIMVERSION="2.0" DTDVERSION="2.0"> <MESSAGE ID="4711" PROTOCOLVERSION="1.0"> <SIMPLEREQ> <IMETHODCALL NAME="DeleteInstance"> <LOCALNAMESPACEPATH> <NAMESPACE NAME="root"/> <NAMESPACE NAME="PG_InterOp"/> </LOCALNAMESPACEPATH> <IPARAMVALUE NAME="InstanceName"> <INSTANCENAME CLASSNAME="CIM_IndicationFilterCIMXML">
The classnames don't match up, so when we make the delete request the CIMOM can't find the right instance to delete. Both handler and subscription have the classnames properly matched, so they get created and deleted properly. Now the one other thing I noticed is that handler and subscription have the CIMXML suffix on both create and delete, so maybe the more correct solution is to add it to the filter create, not remove it from the filter delete. Do we have anything official that can answer that for us?
The reason is defined within the CIM model: There exists only the one class CIM_IndicationHandlerCIMXML with the CIMXML suffix. CIM_IndicationHandler is the parent of this class and abstract, which means that no instances of this class are allowed. So instances of the Handler are CIM_IndicationHandlerCIMXML. For CIM_IndicationFilter and CIM_IndicationSubscription no class with the CIMXML suffix exists. In this cases the CIMXML suffix is a typo. ls /var/lib/Pegasus/repository/root#PG_InterOp/classes ... -rw-r----- 1 root pegasus 2599 2008-01-10 12:07 CIM_Indication.# -rw-r----- 1 root pegasus 5699 2008-01-10 12:07 CIM_IndicationFilter.CIM_ManagedElement -rw-r----- 1 root pegasus 6679 2008-01-10 12:07 CIM_IndicationHandler.CIM_ListenerDestination -rw-r----- 1 root pegasus 7045 2008-01-10 12:07 CIM_IndicationHandlerCIMXML.CIM_IndicationHandler -rw-r----- 1 root pegasus 11290 2008-01-10 12:07 CIM_IndicationSubscription.# ... -- Regards Heidi Eckhart Software Engineer IBM Linux Technology Center - Open Hypervisor
participants (3)
-
Dan Smith -
Heidi Eckhart -
Jay Gagnon