Home » Projects » Opentestman » Issues

Broken constraint of CIM_IPProtocolEndpoint.AddressOrigin

September 11th, 2008 | posted by falk.fiedler
Bug ID:252
Project:Opentestman
Component:Code
Category:bug report
Priority:normal
Assigned:Unassigned
Status:active
Description

There are two constraints. One saying, if the IPProtocolEndpoint is associated via a IPAssignmentSettingData to a DHCPSettingData, the AddressOrigin has to be 4. The other saying, if the IPProtocolEndpoint is associated via a IPAssignmentSettingData to a StaticIPAssignmentSettingData, the AddressOrigin has to be 3.
If there are associations to both DHCPSettingData and StaticIPAssignmentSettingData, at least one of these constraints failes.
In this case whether both values (3 and 4) must be allowed or the associating ElementSettingData hast to be taken into account, where the constraint, which ElementSettingData's "IsCurrent"-property set to 1, is beating the other.

Updates

#1 submitted by falk.fiedler on Thu, 09/11/2008 - 11:52

debug and results (r2967) are available at
http://openmsp.peppercon.de/opentestman/patches/r2955/20080911.1.debug_results.tgz

#2 submitted by akash_malhotra on Fri, 09/12/2008 - 02:05

No where in the specification it states that both 3 and 4 can coexist. Since this value is not array, one value needs to be assigned. Is there any specific used case you are referring to?

#3 submitted by falk.fiedler on Fri, 09/12/2008 - 06:44
#4 submitted by falk.fiedler on Fri, 09/12/2008 - 06:56

You are right, only one value can exist. We have the following situation (sorry, I tried to format it with blockcode in a more block-diagram-style, but at least my browser ditn't display it):

--------------------
DHCPSettingData
|
OrderedComponent
|
IPAssignmentSettingData
|
ElementSettingData (IsCurrent=1)
|
IPProtocolEndpoint (AddressOrigin=4)
|
ElementSettingData (IsCurrent=2)
|
IPAssignmentSettingData
|
OrderedComponent
|
StaticIPAssignementSettingData
--------------------

One constraint says, if there is an association towards DHCPSettingData (yes, we have), AddressOrigin must be 4. The other constraint says, if there is an association towards StaticIPAssignmentSettingData (yes, we have this too), AddressOrigin must be 3. This one failes. Or the first one will fail if AddressOrigin will be set to 3.

So if we have this constellation, there are times when AddressOrigin is 3 and times when AddressOrigin is 4. The only thing that changes is the "IsCurrent"-property of the ElementSettingDatas which is telling about the currently applied IPSettings.