12:49 a.m.
# HG changeset patch
# User Jay Gagnon <grendel(a)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(a)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>
1:08 a.m.
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(a)us.ibm.com
2:12 a.m.
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
2:30 a.m.
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(a)us.ibm.com
11:52 p.m.
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
6080
days inactive
6082
days old
4 comments
3 participants
participants (3)
-
Dan Smith -
Heidi Eckhart -
Jay Gagnon