Open Stack

On 10 January 2017 at 14:13, Duarte Cardoso, Igor
<igor.duarte.cardoso at intel.com> wrote:
> Hi networking-sfc,
>
>
>
> While working on the SFC Graphs patch, I observed the following limitation
> when creating port-chains: http://paste.openstack.org/show/594387/.
>
>
>
> My objective was to have 2 port-chains acting on the same classification of
> traffic but from different logical source ports – my expectation was that
> there wouldn’t be any clash here.
>
>
>
> However, the flow-classifiers clash when they are associated to those 2
> different port-chains.
>
>
>
> The exception is raised in [1] and the attributes of the flow-classifier
> being checked are in [2], where neither logical source port or logical
> destination port are specified.
>
>
>
> Is there a specific reasoning behind this or can it be considered a bug? For
> the SFC Graphs work, it’s important that this limitation be lifted – I’m
> happy to submit a patch to correct it.
>
> Let me know your thoughts.
>
>
>
> [1]
> https://github.com/openstack/networking-sfc/blob/9b4a918177768a036c192a62fa473841c333b644/networking_sfc/db/sfc_db.py#L259
>
> [2]
> https://github.com/openstack/networking-sfc/blob/b8dd1151343fef826043f408cd3027c5133fde30/networking_sfc/db/flowclassifier_db.py#L159

This must be the theme for this week's networking-sfc topic then, I
ended up hitting the same problem while anylyzing the tempest race
condition failures [1].

Each test creates a new port to use for its port pair, and a new flow
classifier. The flow classifier has the same parameters, except for
the source logical port (the related port is used here).
Apparently the test failure (a PortChainFlowClassifierInConflict
exception) is caused by a flow classifier from a previous test
conflicting with the new one.

My thoughts here: this should indeed be allowed, and I think this
restriction comes from an incorrect use of the *_conflict() functions
[2]: we should use the full flowclassifier_conflict() instead of
flowclassifier_basic_conflict(), as it adds logical port conflict
check and is the "main" conflict check function.
That is in fact the fix I just sent for review [3], local tempest runs
went fine here. Feedback welcome!


[1] https://bugs.launchpad.net/networking-sfc/+bug/1655618
[2] https://github.com/openstack/networking-sfc/blob/b8dd1151343fef826043f408cd3027c5133fde30/networking_sfc/db/flowclassifier_db.py#L191
[3] https://review.openstack.org/#/c/419525/

-- 
Bernard Cafarelli