From within OSC code calling SecurityGroup.addSecurityGroupMember with members of the same type should work as expected: new and different members should be added. This issue does not seem to reflect directly on OSC APIs or UI but it does affect unit testing and it could have other not yet found side effects.
Actual Behavior
From within OSC code calling SecurityGroup.addSecurityGroupMember with members of the same type does not work. Only the first member gets added, this is happening because the type of the security members collection is TreeSet which uses compareTo to identify if elements are the same. Currently the SecurityGroupMember implements compareTo using the type only, thus adding elements of the same type does not work. This does not seem to be affecting any behavior on the APIs or UIs, the reason seems because the persistence framework instantiates the set of SGMs with a different collection other than TreeSet this affects the unit tests though.
Steps to Reproduce
Since this is currently only affecting unit tests the repro steps involve removing the workaround added for the unit tests and running them:
Run the unit tests AllocateDAIWithSGIMembersTaskTest
Observe the unit tests are passing
Remove the workaround/TODO on UpdateDAIToSGIMembersTaskTest.newSGM which is currently mocking the compareTo method of the SGM
Rerun the unit tests AllocateDAIWithSGIMembersTaskTest and observe that they will now fail due to the TreeSet issue.
Additional Information
Once the TreeSet issue is addressed, i.e.: use a HashSet then the tests should pass without the need for any workaround.
Expected Behavior
From within OSC code calling
SecurityGroup.addSecurityGroupMember
with members of the same type should work as expected: new and different members should be added. This issue does not seem to reflect directly on OSC APIs or UI but it does affect unit testing and it could have other not yet found side effects.Actual Behavior
From within OSC code calling
SecurityGroup.addSecurityGroupMember
with members of the same type does not work. Only the first member gets added, this is happening because the type of the security members collection isTreeSet
which usescompareTo
to identify if elements are the same. Currently the SecurityGroupMember implementscompareTo
using thetype
only, thus adding elements of the same type does not work. This does not seem to be affecting any behavior on the APIs or UIs, the reason seems because the persistence framework instantiates the set of SGMs with a different collection other thanTreeSet
this affects the unit tests though.Steps to Reproduce
Since this is currently only affecting unit tests the repro steps involve removing the workaround added for the unit tests and running them:
AllocateDAIWithSGIMembersTaskTest
UpdateDAIToSGIMembersTaskTest.newSGM
which is currently mocking the compareTo method of the SGMAllocateDAIWithSGIMembersTaskTes
t and observe that they will now fail due to the TreeSet issue.Additional Information
Once the TreeSet issue is addressed, i.e.: use a HashSet then the tests should pass without the need for any workaround.
Status