Thanks Bernard, Louis, IRC meeting, Given the encapsulation requirement when having SFC Graphs, there is then no need to call flowclassifier_basic_conflict() for the said graphs. I will see how to avoid calling flowclassifier_basic_conflict() specifically when creating graphs of port chains. Will likely need to touch multiple parts of the code since port chain resources must already exist before a graph can connect them.
Best regards, Igor. -----Original Message----- From: Bernard Cafarelli [mailto:bcafa...@redhat.com] Sent: Thursday, January 12, 2017 3:44 PM To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [networking-sfc] Limitation on port chains + flow classifiers On 10 January 2017 at 14:13, Duarte Cardoso, Igor <igor.duarte.card...@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/9b4a918177768a036c192 > a62fa473841c333b644/networking_sfc/db/sfc_db.py#L259 > > [2] > https://github.com/openstack/networking-sfc/blob/b8dd1151343fef826043f > 408cd3027c5133fde30/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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
