Reported on the mailing list here:
https://lists.opendaylight.org/pipermail/controller-dev/2014-July/005499.html
If you have the YANG data model, have you tried specifying "ordered-by-user" in the list?
Thanks
Kiran
----Original Message----
From: controller-dev-bounces at lists.opendaylight.org controller-dev-bounces at lists.opendaylight.org
On Behalf Of Shigeru Yasuda
Sent: Tuesday, July 08, 2014 11:18 AM
To: controller-dev at lists.opendaylight.org; openflowplugin-dev at lists.opendaylight.org; vtn-dev at lists.opendaylight.org
Subject: [controller-dev] Flow actions were reordered.
Hi folks,
I observed that flow actions in a flow entry were reordered unexpectedly when I tested VTN with OF13 plugin.
I configured 3 actions in a flow entry (via sal-compatibility):
action[0]: PUSH_VLAN
action[1]: SET_FIELD (VLAN_VID)
action[2]: OUTPUT
But above actions were encoded into an OF13 FLOW_MOD as follows:
action[0]: OUTPUT
action[1]: PUSH_VLAN
action[2]: SET_FIELD (VLAN_VID)
I embedded some trace logs into the controller source, then I observed that flow actions in MD-SAL flow were already reordered when
FlowChangeListener.add() was called.
_applyActions=ApplyActions [
_action=[
Action [
_order=2, _key=ActionKey [_order=2],
_action=OutputActionCase [
_outputAction=OutputAction [
_outputNodeConnector=Uri [_value=openflow:4:1],
augmentation=[]
],
augmentation=[]
],
augmentation=[]
],
Action [
_order=0, _key=ActionKey [_order=0],
_action=PushVlanActionCase [
_pushVlanAction=PushVlanAction [
_ethernetType=33024,
augmentation=[]
],
augmentation=[]
],
augmentation=[]
],
Action [
_order=1, _key=ActionKey [_order=1],
_action=SetVlanIdActionCase [
_setVlanIdAction=SetVlanIdAction [
_vlanId=VlanId [_value=10],
augmentation=[]
],
augmentation=[]
],
augmentation=[]
]
],
augmentation=[]
], ...
And I enabled trace logging for BindingToNormalizedNodeCodec class in sal-binding-broker, then I observed that MD-SAL actions were deserialized out of order.
2014-07-09 00:37:40.849 GMT+09:00 [pool-17-thread-1] TRACE \
o.o.c.m.s.b.i.BindingToNormalizedNodeCodec - \
InstanceIdentifier Path Deserialization: [... snipped ..] \
action/(urn:opendaylight:flow:inventory?revision=2013-08-19)output-action
2014-07-09 00:37:40.851 GMT+09:00 [pool-17-thread-1] TRACE \
o.o.c.m.s.b.i.BindingToNormalizedNodeCodec - \
InstanceIdentifier Path Deserialization: [... snipped ..] \
action/(urn:opendaylight:flow:inventory?revision=2013-08-19)set-vlan-id-action
2014-07-09 00:37:40.851 GMT+09:00 [pool-17-thread-1] TRACE \
o.o.c.m.s.b.i.BindingToNormalizedNodeCodec - \
InstanceIdentifier Path Deserialization: [... snipped ..] \
action/(urn:opendaylight:flow:inventory?revision=2013-08-19)push-vlan-action
The order of elements in a YANG data list seems to be unspecified because it may be randomized by deserialization. My understanding is correct?
If so, I think openflowplugin should sort MD-SAL actions according to action order (Action.getOrder()) when it converts MD-SAL actions into OF actions.
Regards,
–
Shigeru Yasuda