[openstack-dev] networking-sfc 7.0.0.0rc1 (rocky)

[no-reply]

Hello everyone,

A new release candidate for networking-sfc for the end of the Rocky
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/networking-sfc/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Rocky release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/rocky release
branch at:

http://git.openstack.org/cgit/openstack/networking-sfc/log/?h=stable/rocky

Release notes for networking-sfc can be found at:

http://docs.openstack.org/releasenotes/networking-sfc/

If you find an issue that could be considered release-critical, please
file it at:

https://bugs.launchpad.net/networking-sfc

and tag it *rocky-rc-potential* to bring it to the networking-sfc
release crew's attention.


__
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-dev] [networking-sfc] Add extension to DB UT

[Vikash Kumar]

Hi All,

 I have added tap extension for https://blueprints.launchpad.
net/networking-sfc/+spec/sfc-tap-port-pair.

 I wanted to add extension for DB validation. Where should i add the
extension ? I tried adding extension here:

https://github.com/openstack/networking-sfc/blob/master/
networking_sfc/tests/unit/db/test_sfc_db.py#L281

  but seems thats not working.


I have validated the extension on devstack setup and it works as
expected.

   Any pointers ?

Regards,
Vikash
__
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

Re: [openstack-dev] [networking-sfc] pep8 failing

[Bernard Cafarelli]

Indeed, recreating the environment with "tox -r" should help here (to
get the new lib)

On 16 May 2017 at 20:28, Ihar Hrachyshka  wrote:
> Make sure you have the latest neutron-lib in your tree: neutron-lib==1.6.0
>
> On Tue, May 16, 2017 at 3:05 AM, Vikash Kumar
>  wrote:
>> Hi Team,
>>
>>   pep8 is failing in master code. translation hint helpers are removed from
>> LOG messages. Is this purposefully done ? Let me know if it is not, will
>> change it.
>>
>> ./networking_sfc/db/flowclassifier_db.py:342:13: N531  Log messages require
>> translation hints!
>> LOG.info("Deleting a non-existing flow classifier.")
>> ^
>> ./networking_sfc/db/sfc_db.py:383:13: N531  Log messages require translation
>> hints!
>> LOG.info("Deleting a non-existing port chain.")
>> ^
>> ./networking_sfc/db/sfc_db.py:526:13: N531  Log messages require translation
>> hints!
>> LOG.info("Deleting a non-existing port pair.")
>> ^
>> ./networking_sfc/db/sfc_db.py:658:13: N531  Log messages require translation
>> hints!
>> LOG.info("Deleting a non-existing port pair group.")
>> ^
>> ./networking_sfc/services/flowclassifier/driver_manager.py:38:9: N531  Log
>> messages require translation hints!
>> LOG.info("Configured Flow Classifier drivers: %s", names)
>> ^
>> ./networking_sfc/services/flowclassifier/driver_manager.py:44:9: N531  Log
>> messages require translation hints!
>> LOG.info("Loaded Flow Classifier drivers: %s",
>> ^
>> ./networking_sfc/services/flowclassifier/driver_manager.py:80:9: N531  Log
>> messages require translation hints!
>> LOG.info("Registered Flow Classifier drivers: %s",
>> ^
>> ./networking_sfc/services/flowclassifier/driver_manager.py:87:13: N531  Log
>> messages require translation hints!
>> LOG.info("Initializing Flow Classifier driver '%s'",
>> ^
>> ./networking_sfc/services/flowclassifier/driver_manager.py:107:17: N531  Log
>> messages require translation hints!
>> LOG.error(
>> ^
>> ./networking_sfc/services/flowclassifier/plugin.py:63:17: N531  Log messages
>> require translation hints!
>> LOG.error("Create flow classifier failed, "
>> ^
>> ./networking_sfc/services/flowclassifier/plugin.py:87:17: N531  Log messages
>> require translation hints!
>> LOG.error("Update flow classifier failed, "
>> ^
>> ./networking_sfc/services/flowclassifier/plugin.py:102:17: N531  Log
>> messages require translation hints!
>> LOG.error("Delete flow classifier failed, "
>> ^
>> ./networking_sfc/services/sfc/driver_manager.py:38:9: N531  Log messages
>> require translation hints!
>> LOG.info("Configured SFC drivers: %s", names)
>> ^
>> ./networking_sfc/services/sfc/driver_manager.py:43:9: N531  Log messages
>> require translation hints!
>> LOG.info("Loaded SFC drivers: %s", self.names())
>> ^
>> ./networking_sfc/services/sfc/driver_manager.py:78:9: N531  Log messages
>> require translation hints!
>> LOG.info("Registered SFC drivers: %s",
>> ^
>> ./networking_sfc/services/sfc/driver_manager.py:85:13: N531  Log messages
>> require translation hints!
>> LOG.info("Initializing SFC driver '%s'", driver.name)
>> ^
>> ./networking_sfc/services/sfc/driver_manager.py:104:17: N531  Log messages
>> require translation hints!
>> LOG.error(
>> ^
>> ./networking_sfc/services/sfc/plugin.py:57:17: N531  Log messages require
>> translation hints!
>> LOG.error("Create port chain failed, "
>> ^
>> ./networking_sfc/services/sfc/plugin.py:82:17: N531  Log messages require
>> translation hints!
>> LOG.error("Update port chain failed, port_chain '%s'",
>> ^
>> ./networking_sfc/services/sfc/plugin.py:97:17: N531  Log messages require
>> translation hints!
>> LOG.error("Delete port chain failed, portchain '%s'",
>> ^
>> ./networking_sfc/services/sfc/plugin.py:122:17: N531  Log messages require
>> translation hints!
>> LOG.error("Create port pair failed, "
>> ^
>> ./networking_sfc/services/sfc/plugin.py:144:17: N531  Log messages require
>> translation hints!
>> LOG.error("Update port pair failed, port_pair '%s'",
>> ^
>> ./networking_sfc/services/sfc/plugin.py:159:17: N531  Log messages require
>> translation hints!
>> LOG.error("Delete port pair failed, port_pair '%s'",
>> ^
>> ./networking_sfc/services/sfc/plugin.py:185:17: N531  Log messages require
>> translation hints!
>> LOG.error("Create port pair group failed, "
>> ^
>> ./networking_sfc/services/sfc/plugin.py:213:17: N531  

Re: [openstack-dev] [networking-sfc] pep8 failing

[Ihar Hrachyshka]

Make sure you have the latest neutron-lib in your tree: neutron-lib==1.6.0

On Tue, May 16, 2017 at 3:05 AM, Vikash Kumar
 wrote:
> Hi Team,
>
>   pep8 is failing in master code. translation hint helpers are removed from
> LOG messages. Is this purposefully done ? Let me know if it is not, will
> change it.
>
> ./networking_sfc/db/flowclassifier_db.py:342:13: N531  Log messages require
> translation hints!
> LOG.info("Deleting a non-existing flow classifier.")
> ^
> ./networking_sfc/db/sfc_db.py:383:13: N531  Log messages require translation
> hints!
> LOG.info("Deleting a non-existing port chain.")
> ^
> ./networking_sfc/db/sfc_db.py:526:13: N531  Log messages require translation
> hints!
> LOG.info("Deleting a non-existing port pair.")
> ^
> ./networking_sfc/db/sfc_db.py:658:13: N531  Log messages require translation
> hints!
> LOG.info("Deleting a non-existing port pair group.")
> ^
> ./networking_sfc/services/flowclassifier/driver_manager.py:38:9: N531  Log
> messages require translation hints!
> LOG.info("Configured Flow Classifier drivers: %s", names)
> ^
> ./networking_sfc/services/flowclassifier/driver_manager.py:44:9: N531  Log
> messages require translation hints!
> LOG.info("Loaded Flow Classifier drivers: %s",
> ^
> ./networking_sfc/services/flowclassifier/driver_manager.py:80:9: N531  Log
> messages require translation hints!
> LOG.info("Registered Flow Classifier drivers: %s",
> ^
> ./networking_sfc/services/flowclassifier/driver_manager.py:87:13: N531  Log
> messages require translation hints!
> LOG.info("Initializing Flow Classifier driver '%s'",
> ^
> ./networking_sfc/services/flowclassifier/driver_manager.py:107:17: N531  Log
> messages require translation hints!
> LOG.error(
> ^
> ./networking_sfc/services/flowclassifier/plugin.py:63:17: N531  Log messages
> require translation hints!
> LOG.error("Create flow classifier failed, "
> ^
> ./networking_sfc/services/flowclassifier/plugin.py:87:17: N531  Log messages
> require translation hints!
> LOG.error("Update flow classifier failed, "
> ^
> ./networking_sfc/services/flowclassifier/plugin.py:102:17: N531  Log
> messages require translation hints!
> LOG.error("Delete flow classifier failed, "
> ^
> ./networking_sfc/services/sfc/driver_manager.py:38:9: N531  Log messages
> require translation hints!
> LOG.info("Configured SFC drivers: %s", names)
> ^
> ./networking_sfc/services/sfc/driver_manager.py:43:9: N531  Log messages
> require translation hints!
> LOG.info("Loaded SFC drivers: %s", self.names())
> ^
> ./networking_sfc/services/sfc/driver_manager.py:78:9: N531  Log messages
> require translation hints!
> LOG.info("Registered SFC drivers: %s",
> ^
> ./networking_sfc/services/sfc/driver_manager.py:85:13: N531  Log messages
> require translation hints!
> LOG.info("Initializing SFC driver '%s'", driver.name)
> ^
> ./networking_sfc/services/sfc/driver_manager.py:104:17: N531  Log messages
> require translation hints!
> LOG.error(
> ^
> ./networking_sfc/services/sfc/plugin.py:57:17: N531  Log messages require
> translation hints!
> LOG.error("Create port chain failed, "
> ^
> ./networking_sfc/services/sfc/plugin.py:82:17: N531  Log messages require
> translation hints!
> LOG.error("Update port chain failed, port_chain '%s'",
> ^
> ./networking_sfc/services/sfc/plugin.py:97:17: N531  Log messages require
> translation hints!
> LOG.error("Delete port chain failed, portchain '%s'",
> ^
> ./networking_sfc/services/sfc/plugin.py:122:17: N531  Log messages require
> translation hints!
> LOG.error("Create port pair failed, "
> ^
> ./networking_sfc/services/sfc/plugin.py:144:17: N531  Log messages require
> translation hints!
> LOG.error("Update port pair failed, port_pair '%s'",
> ^
> ./networking_sfc/services/sfc/plugin.py:159:17: N531  Log messages require
> translation hints!
> LOG.error("Delete port pair failed, port_pair '%s'",
> ^
> ./networking_sfc/services/sfc/plugin.py:185:17: N531  Log messages require
> translation hints!
> LOG.error("Create port pair group failed, "
> ^
> ./networking_sfc/services/sfc/plugin.py:213:17: N531  Log messages require
> translation hints!
> LOG.error("Update port pair group failed, "
> ^
> ./networking_sfc/services/sfc/plugin.py:229:17: N531  Log messages require
> translation hints!
> LOG.error("Delete port pair 

[openstack-dev] [networking-sfc] pep8 failing

[Vikash Kumar]

Hi Team,

  pep8 is failing in master code. *translation hint helpers *are removed
from LOG messages. Is this purposefully done ? Let me know if it is not,
will change it.

./networking_sfc/db/flowclassifier_db.py:342:13: N531  Log messages require
translation hints!
LOG.info("Deleting a non-existing flow classifier.")
^
./networking_sfc/db/sfc_db.py:383:13: N531  Log messages require
translation hints!
LOG.info("Deleting a non-existing port chain.")
^
./networking_sfc/db/sfc_db.py:526:13: N531  Log messages require
translation hints!
LOG.info("Deleting a non-existing port pair.")
^
./networking_sfc/db/sfc_db.py:658:13: N531  Log messages require
translation hints!
LOG.info("Deleting a non-existing port pair group.")
^
./networking_sfc/services/flowclassifier/driver_manager.py:38:9: N531  Log
messages require translation hints!
LOG.info("Configured Flow Classifier drivers: %s", names)
^
./networking_sfc/services/flowclassifier/driver_manager.py:44:9: N531  Log
messages require translation hints!
LOG.info("Loaded Flow Classifier drivers: %s",
^
./networking_sfc/services/flowclassifier/driver_manager.py:80:9: N531  Log
messages require translation hints!
LOG.info("Registered Flow Classifier drivers: %s",
^
./networking_sfc/services/flowclassifier/driver_manager.py:87:13: N531  Log
messages require translation hints!
LOG.info("Initializing Flow Classifier driver '%s'",
^
./networking_sfc/services/flowclassifier/driver_manager.py:107:17: N531
Log messages require translation hints!
LOG.error(
^
./networking_sfc/services/flowclassifier/plugin.py:63:17: N531  Log
messages require translation hints!
LOG.error("Create flow classifier failed, "
^
./networking_sfc/services/flowclassifier/plugin.py:87:17: N531  Log
messages require translation hints!
LOG.error("Update flow classifier failed, "
^
./networking_sfc/services/flowclassifier/plugin.py:102:17: N531  Log
messages require translation hints!
LOG.error("Delete flow classifier failed, "
^
./networking_sfc/services/sfc/driver_manager.py:38:9: N531  Log messages
require translation hints!
LOG.info("Configured SFC drivers: %s", names)
^
./networking_sfc/services/sfc/driver_manager.py:43:9: N531  Log messages
require translation hints!
LOG.info("Loaded SFC drivers: %s", self.names())
^
./networking_sfc/services/sfc/driver_manager.py:78:9: N531  Log messages
require translation hints!
LOG.info("Registered SFC drivers: %s",
^
./networking_sfc/services/sfc/driver_manager.py:85:13: N531  Log messages
require translation hints!
LOG.info("Initializing SFC driver '%s'", driver.name)
^
./networking_sfc/services/sfc/driver_manager.py:104:17: N531  Log messages
require translation hints!
LOG.error(
^
./networking_sfc/services/sfc/plugin.py:57:17: N531  Log messages require
translation hints!
LOG.error("Create port chain failed, "
^
./networking_sfc/services/sfc/plugin.py:82:17: N531  Log messages require
translation hints!
LOG.error("Update port chain failed, port_chain '%s'",
^
./networking_sfc/services/sfc/plugin.py:97:17: N531  Log messages require
translation hints!
LOG.error("Delete port chain failed, portchain '%s'",
^
./networking_sfc/services/sfc/plugin.py:122:17: N531  Log messages require
translation hints!
LOG.error("Create port pair failed, "
^
./networking_sfc/services/sfc/plugin.py:144:17: N531  Log messages require
translation hints!
LOG.error("Update port pair failed, port_pair '%s'",
^
./networking_sfc/services/sfc/plugin.py:159:17: N531  Log messages require
translation hints!
LOG.error("Delete port pair failed, port_pair '%s'",
^
./networking_sfc/services/sfc/plugin.py:185:17: N531  Log messages require
translation hints!
LOG.error("Create port pair group failed, "
^
./networking_sfc/services/sfc/plugin.py:213:17: N531  Log messages require
translation hints!
LOG.error("Update port pair group failed, "
^
./networking_sfc/services/sfc/plugin.py:229:17: N531  Log messages require
translation hints!
LOG.error("Delete port pair group failed, "
^
./networking_sfc/services/sfc/agent/extensions/sfc.py:111:13: N531  Log
messages require translation hints!
LOG.error("SFC L2 extension handle_port failed")
^
./networking_sfc/services/sfc/agent/extensions/sfc.py:124:9: N531  Log
messages require translation hints!
LOG.info("a device %s is removed", port_id)
 

[openstack-dev] [networking-sfc] Load distribution bug with OVS driver

[Bernard Cafarelli]

Hi,

this is a follow-up/summary of launchpad bug 1675289 [0].

From the original spec [1], with the OVS driver we should have groups
witt the "hash" selection method, and for parameters source
IP/port/protocol

However this requires OpenFlow 1.5, so we actually have default
selection method and no parameters customization. Selection is done on
both source and destination [2], so in our case close to the
"theorical" parameters.

Additionally we can set "lb_fields" via API, but they are not currenly
used in the driver. These also sound quite OVS-specific, not sure how
other drivers handle it.

Anyway, I outlined the possible change to fix this properly in the bug
(if I got everything correctly).

Feedback and comments welcome!

[0] https://bugs.launchpad.net/networking-sfc/+bug/1675289
[1] 
https://github.com/openstack/networking-sfc/blob/master/doc/source/ovs_driver_and_agent_workflow.rst#group-table-flows
[2] 
https://github.com/openvswitch/ovs/commit/1d1aae0b2f9a149bf74000d975fbf29d133cd9ca

-- 
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-dev] networking-sfc meetings cancelled this week

[Henry Fourie]

All,
  networking-sfc meetings will resume on May 18.
- Louis
__
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-dev] [networking-sfc] No networking-sfc meeting today

[Henry Fourie]

All,
   There will be no networking-sfc meetings for the next two weeks.
Will resume on May 18.
- Louis
__
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-dev] [networking-sfc]PPG reuse restriction

[Vikash Kumar]

Hi Team,

  I inserted a single arm SF. Created a port-pair with ingress-port and
egress-port as same. Created rest of the resource and it traffic was as
expected through SF in one direction. After, that I tried to create reverse
flow and it failed due to:

   a. reverse port-chain create failed as ppg in use.
   b. port-pair-create failed as same 'ingress' and 'egress' port is in
use. Thus ppg also can't be created.

So, we can't create a new ppg (with same details) neither can we reuse,
which restrict the reverse path creation by user.

What is the correct solution to achieve same ? What is the implication
if we let the ppg reuse ??

-- 
Regards,
Vikash
__
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

Re: [openstack-dev] [networking-sfc] About insertion modes and SFC Encapsulation

[Duarte Cardoso, Igor]

Below,

Best regards,
Igor.

From: Vikash Kumar [mailto:vikash.ku...@oneconvergence.com]
Sent: Tuesday, March 21, 2017 6:29 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>; Duarte Cardoso, Igor 
<igor.duarte.card...@intel.com>
Subject: Re: [openstack-dev] [networking-sfc] About insertion modes and SFC 
Encapsulation

Also, for TAP devices, they can be deployed in both active ( forward traffic 
back to networking​ devices) and passive mode . Our *current BP* scope is only 
for passive TAP. Apart from these two, there are other mode of deployment s 
also.

Others reading can add.

On Tue, Mar 21, 2017, 11:16 PM Vikash Kumar 
<vikash.ku...@oneconvergence.com<mailto:vikash.ku...@oneconvergence.com>> wrote:
Hi Igor,


On Tue, Mar 21, 2017 at 10:02 PM, Duarte Cardoso, Igor 
<igor.duarte.card...@intel.com<mailto:igor.duarte.card...@intel.com>> wrote:
Hi Vikash,

It’s best to start with RFC 7665.

NSH decouples traffic forwarding from both the internals of packets and service 
functions. A special entity called SFF will take on that job. L2/L3 then become 
something that the SFF might have to deal with it.

​which means it can co-exist with (L2/L3 insertion mode) and not necessarily 
mutually exclusive.
[IDC] It can’t because it shouldn’t be captured in the API. When you create a 
port-chain you have to specify the encap protocol that will render it as a 
whole, let’s say NSH. Then you go to the port-pairs and specify whether they 
support that protocol or whether they have to be proxied in an L2 or an L3 way 
(and these three possibilities are mutually exclusive).
If the port-pair supports NSH, you don’t specify anything about L2 or L3 
insertion modes. The logical SFFs (physically OVS e.g.) will be configured with 
the flows that will be able to forward traffic to the right service function – 
those flows can look like an L2 if the port-pair is on the current node and we 
just need to push NSH on Ethernet, or maybe they will look like an L4 insertion 
mode, if we have to cross nodes using VXLAN – but this will be 
backend/deployment/environment specific, and that’s what I mean by “L2/L3 then 
become something that the SFF might have to deal with it”. It’s not something 
to capture in the API.

​

However, networking-sfc API doesn’t expose or require details about individual 
SFC dataplane elements such as the SFF… it is up to the backend/driver to know 
those low-level details.

​Agree.
​

NSH doesn’t classify and forward traffic itself. It’s only a header that 
identifies what and where in the chain the packet belongs to/is (plus other 
goodies such as metadata). Classifier will classify, SFF will forward.

​   I was referring to NSH in totality and not excluding SFF 
(https://tools.ietf.org/html/draft-ietf-sfc-nsh-12). Look like I extended the 
scope of NSH in term of  SFC. ​



By the way, I left a question on the tap blueprint whiteboard, I’ll copy it 
here too:
“Is there a use case for "tap chains"? I.e. not only you send traffic to your 
tap function, but then your tap function also sends traffic to a next hop too, 
so a full chain starts after traffic gets tapped at the first chain (the first 
chain also continues).”
I suppose the answer is no since you mentioned “Note - TAP SFs do not forward 
packet”, but I’m happy to hear extended info about this – from anyone reading.

Best regards,
Igor.

From: Vikash Kumar 
[mailto:vikash.ku...@oneconvergence.com<mailto:vikash.ku...@oneconvergence.com>]
Sent: Tuesday, March 21, 2017 3:32 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [networking-sfc] About insertion modes and SFC 
Encapsulation

Hi,
   Moving definition of SF from port-pair to port-pair-group looks good.
   TAP is also an insertion mode like L2/L3 but since it simplifies to keep 
'tap-enabled' field also in port-pair-group, so it should be fine from 
implementation point of view (Note - TAP SFs do not forward packet). TAP 
enabled and L2/L3 insertion mode should be mutually exclusive.
   According to IETF draft NSH can classify & forward traffic (correct ?) but 
then the draft assumes uniformity of working of devices (which IMHO refers L3) 
which doesn't cover the entire use case. Can insertion mode (L2/L3) & traffic 
encapsulation(NSH) co-exist also ?



On Mon, Mar 20, 2017 at 11:35 PM, Cathy Zhang 
<cathy.h.zh...@huawei.com<mailto:cathy.h.zh...@huawei.com>> wrote:
Hi Igor,

Moving the correlation from port-pair to port-pair-group makes sense. In the 
future I think we should add all new attributes for a SF to 
port-pair-group-param.

But I think L2/L3 is different from encap type NSH or MPLS. An L3 type SF can 
support either NSH or MPLS. I would suggest the following:

port-pair-group (port-pair

Re: [openstack-dev] [networking-sfc] About insertion modes and SFC Encapsulation

[Vikash Kumar]

Also, for TAP devices, they can be deployed in both active ( forward
traffic back to networking​ devices) and passive mode . Our *current BP*
scope is only for passive TAP. Apart from these two, there are other mode
of deployment s also.

Others reading can add.

On Tue, Mar 21, 2017, 11:16 PM Vikash Kumar <vikash.ku...@oneconvergence.com>
wrote:

Hi Igor,



On Tue, Mar 21, 2017 at 10:02 PM, Duarte Cardoso, Igor <
igor.duarte.card...@intel.com> wrote:

Hi Vikash,



It’s best to start with RFC 7665.



NSH decouples traffic forwarding from both the internals of packets and
service functions. A special entity called SFF will take on that job. L2/L3
then become something that the SFF might have to deal with it.


​which means it can co-exist with (L2/L3 insertion mode) and not
necessarily mutually exclusive.
​


However, networking-sfc API doesn’t expose or require details about
individual SFC dataplane elements such as the SFF… it is up to the
backend/driver to know those low-level details.


​Agree.

​



NSH doesn’t classify and forward traffic itself. It’s only a header that
identifies what and where in the chain the packet belongs to/is (plus other
goodies such as metadata). Classifier will classify, SFF will forward.


​   I was referring to NSH in totality and not excluding SFF (
https://tools.ietf.org/html/draft-ietf-sfc-nsh-12). Look like I extended
the scope of NSH in term of  SFC. ​






By the way, I left a question on the tap blueprint whiteboard, I’ll copy it
here too:

“Is there a use case for "tap chains"? I.e. not only you send traffic to
your tap function, but then your tap function also sends traffic to a next
hop too, so a full chain starts after traffic gets tapped at the first
chain (the first chain also continues).”

I suppose the answer is no since you mentioned “Note - TAP SFs do not
forward packet”, but I’m happy to hear extended info about this – from
anyone reading.



Best regards,

Igor.



*From:* Vikash Kumar [mailto:vikash.ku...@oneconvergence.com]
*Sent:* Tuesday, March 21, 2017 3:32 PM
*To:* OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
*Subject:* Re: [openstack-dev] [networking-sfc] About insertion modes and
SFC Encapsulation



Hi,

   Moving definition of SF from port-pair to port-pair-group looks good.

   TAP is also an insertion mode like L2/L3 but since it simplifies to keep
'tap-enabled' field also in port-pair-group, so it should be fine from
implementation point of view (Note - TAP SFs do not forward packet). TAP
enabled and L2/L3 insertion mode should be mutually exclusive.

   According to IETF draft NSH can classify & forward traffic (correct ?)
but then the draft assumes uniformity of working of devices (which IMHO
refers L3) which doesn't cover the entire use case. Can insertion mode
(L2/L3) & traffic encapsulation(NSH) co-exist also ?






On Mon, Mar 20, 2017 at 11:35 PM, Cathy Zhang <cathy.h.zh...@huawei.com>
wrote:

Hi Igor,



Moving the correlation from port-pair to port-pair-group makes sense. In
the future I think we should add all new attributes for a SF to
port-pair-group-param.



But I think L2/L3 is different from encap type NSH or MPLS. An L3 type SF
can support either NSH or MPLS. I would suggest the following:



port-pair-group (port-pair-group-params):

insertion-mode:

- L2

- L3 (default)

   Correlation:

- MPLS

- NSH

tap-enabled:

- False (default)

- True



Thanks,

Cathy



*From:* Duarte Cardoso, Igor [mailto:igor.duarte.card...@intel.com]
*Sent:* Monday, March 20, 2017 8:02 AM
*To:* OpenStack Development Mailing List (not for usage questions)
*Subject:* [openstack-dev] [networking-sfc] About insertion modes and SFC
Encapsulation



Hi networking-sfc,



At the latest IRC meeting [1] it was agreed to split TAP from the possible
insertion modes (initial spec version [2]).



I took the ARs to propose coexistence of insertion modes, correlation and
(now) a new tap-enabled attribute, and send this email about possible
directions.



Here are my thoughts, let me know yours:



1.   My expectation for future PP and PPG if TAP+insertion modes go
ahead and nothing else changes (only relevant details outlined):



port-pair (service-function-params):

correlation:

- MPLS

- None (default)

port-pair-group (port-pair-group-params):

insertion-mode:

- L2

- L3 (default)

tap-enabled:

- False (default)

- True



2.   What I propose for future PP and PPG (only relevan

Re: [openstack-dev] [networking-sfc] About insertion modes and SFC Encapsulation

[Henry Fourie]

Igor,
  Inline.

-Louis

From: Duarte Cardoso, Igor [mailto:igor.duarte.card...@intel.com]
Sent: Monday, March 20, 2017 8:02 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [networking-sfc] About insertion modes and SFC 
Encapsulation

Hi networking-sfc,

At the latest IRC meeting [1] it was agreed to split TAP from the possible 
insertion modes (initial spec version [2]).

I took the ARs to propose coexistence of insertion modes, correlation and (now) 
a new tap-enabled attribute, and send this email about possible directions.

Here are my thoughts, let me know yours:


1.   My expectation for future PP and PPG if TAP+insertion modes go ahead 
and nothing else changes (only relevant details outlined):

port-pair (service-function-params):
correlation:
- MPLS
- None (default)
port-pair-group (port-pair-group-params):
insertion-mode:
- L2
- L3 (default)
tap-enabled:
- False (default)
- True


2.   What I propose for future PP and PPG (only relevant details outlined):

port-pair (service-function-params):

port-pair-group (port-pair-group-params):
mode:
- L2
- L3 (default)
- MPLS
- NSH
tap-enabled:
- False (default)
- True

With what's proposed in 2.:
- every combination will be possible with no clashes and no validation required.
- port-pair-groups will always group "homogeneous" sets of port-pairs, making 
load-balacing and next-hop processing simpler and consistent.
- the "forwarding" details of a Service Function are no longer dictated both by 
port-pair and port-pair-group, but rather only by port-pair-group.

LF: agree, it appears that L2, L3, MPLS, NSH are mutually exclusive.
Agree on tap-enabled.

Are there any use cases for having next-hop SF candidates (individual 
port-pairs) supporting different SFC Encapsulation protocols?
I understand, however, that removing correlation from port-pairs might not be 
ideal given that it's a subtractive API change.

[1] 
http://eavesdrop.openstack.org/meetings/service_chaining/2017/service_chaining.2017-03-16-17.02.html
[2] https://review.openstack.org/#/c/442195/
[3] 
https://github.com/openstack/networking-sfc/blob/17c537b35d41a3e1fd80da790ae668e52cea6b88/doc/source/system_design%20and_workflow.rst#usage

Best regards,
Igor.
__
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

Re: [openstack-dev] [networking-sfc] About insertion modes and SFC Encapsulation

[Duarte Cardoso, Igor]

Hi Vikash,

It’s best to start with RFC 7665.

NSH decouples traffic forwarding from both the internals of packets and service 
functions. A special entity called SFF will take on that job. L2/L3 then become 
something that the SFF might have to deal with it. However, networking-sfc API 
doesn’t expose or require details about individual SFC dataplane elements such 
as the SFF… it is up to the backend/driver to know those low-level details.

NSH doesn’t classify and forward traffic itself. It’s only a header that 
identifies what and where in the chain the packet belongs to/is (plus other 
goodies such as metadata). Classifier will classify, SFF will forward.


By the way, I left a question on the tap blueprint whiteboard, I’ll copy it 
here too:
“Is there a use case for "tap chains"? I.e. not only you send traffic to your 
tap function, but then your tap function also sends traffic to a next hop too, 
so a full chain starts after traffic gets tapped at the first chain (the first 
chain also continues).”
I suppose the answer is no since you mentioned “Note - TAP SFs do not forward 
packet”, but I’m happy to hear extended info about this – from anyone reading.

Best regards,
Igor.

From: Vikash Kumar [mailto:vikash.ku...@oneconvergence.com]
Sent: Tuesday, March 21, 2017 3:32 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [networking-sfc] About insertion modes and SFC 
Encapsulation

Hi,
   Moving definition of SF from port-pair to port-pair-group looks good.
   TAP is also an insertion mode like L2/L3 but since it simplifies to keep 
'tap-enabled' field also in port-pair-group, so it should be fine from 
implementation point of view (Note - TAP SFs do not forward packet). TAP 
enabled and L2/L3 insertion mode should be mutually exclusive.
   According to IETF draft NSH can classify & forward traffic (correct ?) but 
then the draft assumes uniformity of working of devices (which IMHO refers L3) 
which doesn't cover the entire use case. Can insertion mode (L2/L3) & traffic 
encapsulation(NSH) co-exist also ?



On Mon, Mar 20, 2017 at 11:35 PM, Cathy Zhang 
<cathy.h.zh...@huawei.com<mailto:cathy.h.zh...@huawei.com>> wrote:
Hi Igor,

Moving the correlation from port-pair to port-pair-group makes sense. In the 
future I think we should add all new attributes for a SF to 
port-pair-group-param.

But I think L2/L3 is different from encap type NSH or MPLS. An L3 type SF can 
support either NSH or MPLS. I would suggest the following:

port-pair-group (port-pair-group-params):
insertion-mode:
- L2
- L3 (default)
   Correlation:
- MPLS
- NSH
tap-enabled:
- False (default)
- True

Thanks,
Cathy

From: Duarte Cardoso, Igor 
[mailto:igor.duarte.card...@intel.com<mailto:igor.duarte.card...@intel.com>]
Sent: Monday, March 20, 2017 8:02 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [networking-sfc] About insertion modes and SFC 
Encapsulation

Hi networking-sfc,

At the latest IRC meeting [1] it was agreed to split TAP from the possible 
insertion modes (initial spec version [2]).

I took the ARs to propose coexistence of insertion modes, correlation and (now) 
a new tap-enabled attribute, and send this email about possible directions.

Here are my thoughts, let me know yours:


1.   My expectation for future PP and PPG if TAP+insertion modes go ahead 
and nothing else changes (only relevant details outlined):

port-pair (service-function-params):
correlation:
- MPLS
- None (default)
port-pair-group (port-pair-group-params):
insertion-mode:
- L2
- L3 (default)
tap-enabled:
- False (default)
- True


2.   What I propose for future PP and PPG (only relevant details outlined):

port-pair (service-function-params):

port-pair-group (port-pair-group-params):
mode:
- L2
- L3 (default)
- MPLS
- NSH
tap-enabled:
- False (default)
- True

With what’s proposed in 2.:
- every combination will be possible with no clashes and no validation required.
- port-pair-groups will always group “homogeneous” sets of port-pairs, making 
load-balacing and next-hop processing simpler and consistent.
- the “forwarding” details of a Service Function are no longer

Re: [openstack-dev] [networking-sfc] About insertion modes and SFC Encapsulation

[Vikash Kumar]

Hi,

   Moving definition of SF from port-pair to port-pair-group looks good.

   TAP is also an insertion mode like L2/L3 but since it simplifies to keep
'tap-enabled' field also in port-pair-group, so it should be fine from
implementation point of view (Note - TAP SFs do not forward packet). TAP
enabled and L2/L3 insertion mode should be mutually exclusive.

   According to IETF draft NSH can classify & forward traffic (correct ?)
but then the draft assumes uniformity of working of devices (which IMHO
refers L3) which doesn't cover the entire use case. Can insertion mode
(L2/L3) & traffic encapsulation(NSH) co-exist also ?



On Mon, Mar 20, 2017 at 11:35 PM, Cathy Zhang <cathy.h.zh...@huawei.com>
wrote:

> Hi Igor,
>
>
>
> Moving the correlation from port-pair to port-pair-group makes sense. In
> the future I think we should add all new attributes for a SF to
> port-pair-group-param.
>
>
>
> But I think L2/L3 is different from encap type NSH or MPLS. An L3 type SF
> can support either NSH or MPLS. I would suggest the following:
>
>
>
> port-pair-group (port-pair-group-params):
>
> insertion-mode:
>
> - L2
>
> - L3 (default)
>
>Correlation:
>
> - MPLS
>
> - NSH
>
> tap-enabled:
>
> - False (default)
>
> - True
>
>
>
> Thanks,
>
> Cathy
>
>
>
> *From:* Duarte Cardoso, Igor [mailto:igor.duarte.card...@intel.com]
> *Sent:* Monday, March 20, 2017 8:02 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* [openstack-dev] [networking-sfc] About insertion modes and SFC
> Encapsulation
>
>
>
> Hi networking-sfc,
>
>
>
> At the latest IRC meeting [1] it was agreed to split TAP from the possible
> insertion modes (initial spec version [2]).
>
>
>
> I took the ARs to propose coexistence of insertion modes, correlation and
> (now) a new tap-enabled attribute, and send this email about possible
> directions.
>
>
>
> Here are my thoughts, let me know yours:
>
>
>
> 1.   My expectation for future PP and PPG if TAP+insertion modes go
> ahead and nothing else changes (only relevant details outlined):
>
>
>
> port-pair (service-function-params):
>
> correlation:
>
> - MPLS
>
> - None (default)
>
> port-pair-group (port-pair-group-params):
>
> insertion-mode:
>
> - L2
>
> - L3 (default)
>
> tap-enabled:
>
> - False (default)
>
> - True
>
>
>
> 2.   What I propose for future PP and PPG (only relevant details
> outlined):
>
>
>
> port-pair (service-function-params):
>
> 
>
> port-pair-group (port-pair-group-params):
>
> mode:
>
> - L2
>
> - L3 (default)
>
> - MPLS
>
> - NSH
>
> tap-enabled:
>
> - False (default)
>
> - True
>
>
>
> With what’s proposed in 2.:
>
> - every combination will be possible with no clashes and no validation
> required.
>
> - port-pair-groups will always group “homogeneous” sets of port-pairs,
> making load-balacing and next-hop processing simpler and consistent.
>
> - the “forwarding” details of a Service Function are no longer dictated
> both by port-pair and port-pair-group, but rather only by port-pair-group.
>
>
>
> Are there any use cases for having next-hop SF candidates (individual
> port-pairs) supporting different SFC Encapsulation protocols?
>
> I understand, however, that removing correlation from port-pairs might not
> be ideal given that it’s a subtractive API change.
>
>
>
> [1] http://eavesdrop.openstack.org/meetings/service_chaining/201
> 7/service_chaining.2017-03-16-17.02.html
>
> [2] https://review.openstack.org/#/c/442195/
>
> [3] https://github.com/openstack/networking-sfc/blob/17c537b35d4
> 1a3e1fd80da790ae668e52cea6b88/doc/source/system_design%
> 20and_workflow.rst#usage
>
>
>
> Best regards,
>
> Igor.
>
> __
> 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
>
>


-- 
Regards,
Vikash
__
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

Re: [openstack-dev] [networking-sfc] About insertion modes and SFC Encapsulation

[Duarte Cardoso, Igor]

Hi Cathy,

I understand MPLS is a special protocol because:
- It allows Service Function Path identification (rfc7665) -> compatible with 
SFC Encapsulation
- It doesn't fully encapsulate the original frames -> incompatible with SFC 
Encapsulation
- Not necessary for this conversation, but also important to keep in mind: it 
can't transport additional metadata -> incompatible with SFC Encapsulation

So, I will start by discussing NSH specifically (being the fully-compatible SFC 
Encapsulation protocol). And so, the way I look at insertion modes (if split 
from correlations) is that in practice they become something I would describe 
as "SFC Proxy modes".

If a Service Function supports NSH, great, the NSH-encapsulated packets are 
fully exposed to the SFs and no "SFC Proxy mode" needs to be dictated (NSH is 
the mechanism itself). So, specifying L2 or L3 for insertion types would be of 
no meaning. At runtime and at the network forwarding level we might witness 
different ways of reaching the SFs, which could approximate L2 or L3 insertion 
types - but this isn't something to be modelled in networking-sfc's API but 
rather automatically controlled by the backend.

If a Service Function does not support NSH, we are in the presence of a legacy 
SF and so more information is needed to model how this SF expects packets 
(since there is no standard way). Consequently, specifying the insertion types, 
such as L2 or L3, is important. For the former, it means the SF machine has its 
interfaces running in promiscuous mode and is similar to a switch, for the 
latter it means the SF machine's interfaces are not in promiscuous mode and it 
is similar to a router.

With NSH, these insertion mode details are abstracted from the SFs.
The networking backend of neutron/networking-sfc will already know where each 
VM is and how to reach them and will  be responsible for making sure the NSH 
packet is delivered to the correct hop without needing additional information 
(from the networking-sfc API).

So, in summary, L2, L3, NSH and (in practice today @ networking-sfc) MPLS, are 
all mutually exclusive.

Best regards,
Igor.

From: Cathy Zhang [mailto:cathy.h.zh...@huawei.com]
Sent: Monday, March 20, 2017 6:05 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [networking-sfc] About insertion modes and SFC 
Encapsulation

Hi Igor,

Moving the correlation from port-pair to port-pair-group makes sense. In the 
future I think we should add all new attributes for a SF to 
port-pair-group-param.

But I think L2/L3 is different from encap type NSH or MPLS. An L3 type SF can 
support either NSH or MPLS. I would suggest the following:

port-pair-group (port-pair-group-params):
insertion-mode:
- L2
- L3 (default)
   Correlation:
- MPLS
- NSH
tap-enabled:
- False (default)
- True

Thanks,
Cathy

From: Duarte Cardoso, Igor [mailto:igor.duarte.card...@intel.com]
Sent: Monday, March 20, 2017 8:02 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [networking-sfc] About insertion modes and SFC 
Encapsulation

Hi networking-sfc,

At the latest IRC meeting [1] it was agreed to split TAP from the possible 
insertion modes (initial spec version [2]).

I took the ARs to propose coexistence of insertion modes, correlation and (now) 
a new tap-enabled attribute, and send this email about possible directions.

Here are my thoughts, let me know yours:


1.   My expectation for future PP and PPG if TAP+insertion modes go ahead 
and nothing else changes (only relevant details outlined):

port-pair (service-function-params):
correlation:
- MPLS
- None (default)
port-pair-group (port-pair-group-params):
insertion-mode:
- L2
- L3 (default)
tap-enabled:
- False (default)
- True


2.   What I propose for future PP and PPG (only relevant details outlined):

port-pair (service-function-params):

port-pair-group (port-pair-group-params):
mode:
- L2
- L3 (default)
- MPLS
- NSH
tap-enabled:
- False (default)
- True

With what's proposed in 2.:
- every combination will be possible with no clashes and no validation required.
- port-pair-groups will always group "homogeneous" sets of p

Re: [openstack-dev] [networking-sfc] About insertion modes and SFC Encapsulation

[Cathy Zhang]

Hi Igor,

Moving the correlation from port-pair to port-pair-group makes sense. In the 
future I think we should add all new attributes for a SF to 
port-pair-group-param.

But I think L2/L3 is different from encap type NSH or MPLS. An L3 type SF can 
support either NSH or MPLS. I would suggest the following:

port-pair-group (port-pair-group-params):
insertion-mode:
- L2
- L3 (default)
   Correlation:
- MPLS
- NSH
tap-enabled:
- False (default)
- True

Thanks,
Cathy

From: Duarte Cardoso, Igor [mailto:igor.duarte.card...@intel.com]
Sent: Monday, March 20, 2017 8:02 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [networking-sfc] About insertion modes and SFC 
Encapsulation

Hi networking-sfc,

At the latest IRC meeting [1] it was agreed to split TAP from the possible 
insertion modes (initial spec version [2]).

I took the ARs to propose coexistence of insertion modes, correlation and (now) 
a new tap-enabled attribute, and send this email about possible directions.

Here are my thoughts, let me know yours:


1.   My expectation for future PP and PPG if TAP+insertion modes go ahead 
and nothing else changes (only relevant details outlined):

port-pair (service-function-params):
correlation:
- MPLS
- None (default)
port-pair-group (port-pair-group-params):
insertion-mode:
- L2
- L3 (default)
tap-enabled:
- False (default)
- True


2.   What I propose for future PP and PPG (only relevant details outlined):

port-pair (service-function-params):

port-pair-group (port-pair-group-params):
mode:
- L2
- L3 (default)
- MPLS
- NSH
tap-enabled:
- False (default)
- True

With what's proposed in 2.:
- every combination will be possible with no clashes and no validation required.
- port-pair-groups will always group "homogeneous" sets of port-pairs, making 
load-balacing and next-hop processing simpler and consistent.
- the "forwarding" details of a Service Function are no longer dictated both by 
port-pair and port-pair-group, but rather only by port-pair-group.

Are there any use cases for having next-hop SF candidates (individual 
port-pairs) supporting different SFC Encapsulation protocols?
I understand, however, that removing correlation from port-pairs might not be 
ideal given that it's a subtractive API change.

[1] 
http://eavesdrop.openstack.org/meetings/service_chaining/2017/service_chaining.2017-03-16-17.02.html
[2] https://review.openstack.org/#/c/442195/
[3] 
https://github.com/openstack/networking-sfc/blob/17c537b35d41a3e1fd80da790ae668e52cea6b88/doc/source/system_design%20and_workflow.rst#usage

Best regards,
Igor.
__
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-dev] [networking-sfc] About insertion modes and SFC Encapsulation

[Duarte Cardoso, Igor]

Hi networking-sfc,

At the latest IRC meeting [1] it was agreed to split TAP from the possible 
insertion modes (initial spec version [2]).

I took the ARs to propose coexistence of insertion modes, correlation and (now) 
a new tap-enabled attribute, and send this email about possible directions.

Here are my thoughts, let me know yours:


1.   My expectation for future PP and PPG if TAP+insertion modes go ahead 
and nothing else changes (only relevant details outlined):

port-pair (service-function-params):
correlation:
- MPLS
- None (default)
port-pair-group (port-pair-group-params):
insertion-mode:
- L2
- L3 (default)
tap-enabled:
- False (default)
- True


2.   What I propose for future PP and PPG (only relevant details outlined):

port-pair (service-function-params):

port-pair-group (port-pair-group-params):
mode:
- L2
- L3 (default)
- MPLS
- NSH
tap-enabled:
- False (default)
- True

With what's proposed in 2.:
- every combination will be possible with no clashes and no validation required.
- port-pair-groups will always group "homogeneous" sets of port-pairs, making 
load-balacing and next-hop processing simpler and consistent.
- the "forwarding" details of a Service Function are no longer dictated both by 
port-pair and port-pair-group, but rather only by port-pair-group.

Are there any use cases for having next-hop SF candidates (individual 
port-pairs) supporting different SFC Encapsulation protocols?
I understand, however, that removing correlation from port-pairs might not be 
ideal given that it's a subtractive API change.

[1] 
http://eavesdrop.openstack.org/meetings/service_chaining/2017/service_chaining.2017-03-16-17.02.html
[2] https://review.openstack.org/#/c/442195/
[3] 
https://github.com/openstack/networking-sfc/blob/17c537b35d41a3e1fd80da790ae668e52cea6b88/doc/source/system_design%20and_workflow.rst#usage

Best regards,
Igor.
__
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

Re: [openstack-dev] [networking-sfc] patch test failed due to "import error: vlanmanager"

[Kevin Benton]

Well it was likely using an older version of neutron if that import was
failing. If you run the tests some time ago on that machine you would have
to run 'tox -r' to reclone neutron.

On Mar 9, 2017 08:46, "Vikash Kumar" <vikash.ku...@oneconvergence.com>
wrote:

> Hi Igor,
>
> I was trying on Ubuntu 14.04 (trusty). This was weird though.
>
> On Thu, Mar 9, 2017 at 4:54 PM, Duarte Cardoso, Igor <
> igor.duarte.card...@intel.com> wrote:
>
>> Hi Vikash,
>>
>>
>>
>> What OS were you trying on before?
>>
>>
>>
>> Best regards,
>>
>> Igor.
>>
>>
>>
>> *From:* Vikash Kumar [mailto:vikash.ku...@oneconvergence.com]
>> *Sent:* Thursday, March 9, 2017 10:08 AM
>> *To:* OpenStack Development Mailing List (not for usage questions) <
>> openstack-dev@lists.openstack.org>; ke...@benton.pub
>>
>> *Subject:* Re: [openstack-dev] [networking-sfc] patch test failed due to
>> "import error: vlanmanager"
>>
>>
>>
>> Tried on Ubuntu 16.04, its fine.
>>
>>
>>
>> On Thu, Mar 9, 2017 at 12:17 PM, Vikash Kumar <
>> vikash.ku...@oneconvergence.com> wrote:
>>
>> Import path looks OK
>> https://github.com/openstack/networking-sfc/blob/master/netw
>> orking_sfc/services/sfc/agent/extensions/openvswitch/sfc_driver.py#L23
>>
>>
>>
>> Are u suggesting something else?
>>
>>
>>
>> On Thu, Mar 9, 2017 at 3:02 AM, Kevin Benton <ke...@benton.pub> wrote:
>>
>> That location was recently changed in the Neutron side.[1] It sounds like
>> sfc has to be updated.
>>
>>
>>
>> 1. https://github.com/openstack/neutron/commit/4ec456d31501f
>> 09c68b5c23c488878da32dce75e
>>
>>
>>
>> On Tue, Mar 7, 2017 at 9:41 PM, Vikash Kumar <
>> vikash.ku...@oneconvergence.com> wrote:
>>
>> Hi Igor,
>>
>>This is weird. I just did a fresh clone and executed *"tox" *command.
>> I am getting same error. Am I missing anything here ? There is no private
>> change here.  Below is the link for entire log.
>>
>>  http://paste.openstack.org/show/601870/
>>
>>
>>
>> On Tue, Mar 7, 2017 at 10:46 PM, Duarte Cardoso, Igor <
>> igor.duarte.card...@intel.com> wrote:
>>
>> Hi Vikash,
>>
>> Please stick to pastebin for complete logs.
>>
>>
>>
>> Check your migration files:
>>
>>
>>
>> FAILED: Contract HEAD file does not match migration timeline head,
>> expected: 48072cb59133
>>
>>
>>
>> Best regards,
>>
>> Igor.
>>
>>
>>
>> *From:* Vikash Kumar [mailto:vikash.ku...@oneconvergence.com]
>> *Sent:* Tuesday, March 7, 2017 5:03 PM
>> *To:* openstack-dev <openstack-dev@lists.openstack.org>
>> *Subject:* Re: [openstack-dev] [networking-sfc] patch test failed due to
>> "import error: vlanmanager"
>>
>>
>>
>> Complete log:
>>
>>  py35 create: /home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35
>> py35 installdeps: -r/home/vikash/guess_vk/python
>> -dev/networking-sfc/requirements.txt, -r/home/vikash/guess_vk/python
>> -dev/networking-sfc/test-requirements.txt
>> py35 develop-inst: /home/vikash/guess_vk/python-dev/networking-sfc
>> py35 installed: /home/vikash/guess_vk/python-d
>> ev/networking-sfc/.tox/py35/lib/python3.5/site.py:165:
>> DeprecationWarning: 'U' mode is deprecated,  f = open(fullname,
>> "rU"),alabaster==0.7.10,alembic==0.9.1,amqp==1.4.9,anyjson==
>> 0.3.3,appdirs==1.4.2,astroid==1.3.8,Babel==2.3.4,beautifulso
>> up4==4.5.3,cachetools==2.0.0,cffi==1.9.1,cliff==2.4.0,cmd2=
>> =0.7.0,contextlib2==0.5.4,coverage==4.3.4,cryptography==
>> 1.7.2,debtcollector==1.12.0,decorator==4.0.11,docutils==0.13
>> .1,dulwich==0.17.1,eventlet==0.19.0,extras==1.0.0,fasteners
>> ==0.14.1,fixtures==3.0.0,flake8==2.5.5,futurist==0.21.
>> 0,greenlet==0.4.12,hacking==0.12.0,httplib2==0.10.3,idna==2.
>> 4,imagesize==0.7.1,iso8601==0.1.11,Jinja2==2.9.5,jsonpatch==
>> 1.15,jsonpointer==1.10,jsonschema==2.6.0,keystoneauth
>> 1==2.18.0,keystonemiddleware==4.14.0,kombu==3.0.37,
>> linecache2==1.0.0,logilab-common==1.3.0,logutils==0.3.4.
>> 1,Mako==1.0.6,MarkupSafe==0.23,mccabe==0.2.1,mock==2.0.0,
>> monotonic==1.2,mox3==0.20.0,msgpack-python==0.4.8,netaddr==0.7.19,netifaces==0.10.5,-e
>> git+https://github.com/openstack/networking-sfc.git@c51052e3
>> 748e917731f449b0ff4dc20d2e484490#egg=networking_sfc,-e git+
>> https://github.com/open

Re: [openstack-dev] [networking-sfc] patch test failed due to "import error: vlanmanager"

[Vikash Kumar]

Hi Igor,

I was trying on Ubuntu 14.04 (trusty). This was weird though.

On Thu, Mar 9, 2017 at 4:54 PM, Duarte Cardoso, Igor <
igor.duarte.card...@intel.com> wrote:

> Hi Vikash,
>
>
>
> What OS were you trying on before?
>
>
>
> Best regards,
>
> Igor.
>
>
>
> *From:* Vikash Kumar [mailto:vikash.ku...@oneconvergence.com]
> *Sent:* Thursday, March 9, 2017 10:08 AM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>; ke...@benton.pub
>
> *Subject:* Re: [openstack-dev] [networking-sfc] patch test failed due to
> "import error: vlanmanager"
>
>
>
> Tried on Ubuntu 16.04, its fine.
>
>
>
> On Thu, Mar 9, 2017 at 12:17 PM, Vikash Kumar <
> vikash.ku...@oneconvergence.com> wrote:
>
> Import path looks OK
> https://github.com/openstack/networking-sfc/blob/master/
> networking_sfc/services/sfc/agent/extensions/openvswitch/sfc_driver.py#L23
>
>
>
> Are u suggesting something else?
>
>
>
> On Thu, Mar 9, 2017 at 3:02 AM, Kevin Benton <ke...@benton.pub> wrote:
>
> That location was recently changed in the Neutron side.[1] It sounds like
> sfc has to be updated.
>
>
>
> 1. https://github.com/openstack/neutron/commit/
> 4ec456d31501f09c68b5c23c488878da32dce75e
>
>
>
> On Tue, Mar 7, 2017 at 9:41 PM, Vikash Kumar <vikash.kumar@oneconvergence.
> com> wrote:
>
> Hi Igor,
>
>This is weird. I just did a fresh clone and executed *"tox" *command.
> I am getting same error. Am I missing anything here ? There is no private
> change here.  Below is the link for entire log.
>
>  http://paste.openstack.org/show/601870/
>
>
>
> On Tue, Mar 7, 2017 at 10:46 PM, Duarte Cardoso, Igor <
> igor.duarte.card...@intel.com> wrote:
>
> Hi Vikash,
>
> Please stick to pastebin for complete logs.
>
>
>
> Check your migration files:
>
>
>
> FAILED: Contract HEAD file does not match migration timeline head,
> expected: 48072cb59133
>
>
>
> Best regards,
>
> Igor.
>
>
>
> *From:* Vikash Kumar [mailto:vikash.ku...@oneconvergence.com]
> *Sent:* Tuesday, March 7, 2017 5:03 PM
> *To:* openstack-dev <openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [networking-sfc] patch test failed due to
> "import error: vlanmanager"
>
>
>
> Complete log:
>
>  py35 create: /home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35
> py35 installdeps: 
> -r/home/vikash/guess_vk/python-dev/networking-sfc/requirements.txt,
> -r/home/vikash/guess_vk/python-dev/networking-sfc/test-requirements.txt
> py35 develop-inst: /home/vikash/guess_vk/python-dev/networking-sfc
> py35 installed: 
> /home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35/lib/python3.5/site.py:165:
> DeprecationWarning: 'U' mode is deprecated,  f = open(fullname,
> "rU"),alabaster==0.7.10,alembic==0.9.1,amqp==1.4.9,
> anyjson==0.3.3,appdirs==1.4.2,astroid==1.3.8,Babel==2.3.4,
> beautifulsoup4==4.5.3,cachetools==2.0.0,cffi==1.9.1,
> cliff==2.4.0,cmd2==0.7.0,contextlib2==0.5.4,coverage==
> 4.3.4,cryptography==1.7.2,debtcollector==1.12.0,
> decorator==4.0.11,docutils==0.13.1,dulwich==0.17.1,eventlet=
> =0.19.0,extras==1.0.0,fasteners==0.14.1,fixtures==3.
> 0.0,flake8==2.5.5,futurist==0.21.0,greenlet==0.4.12,hacking=
> =0.12.0,httplib2==0.10.3,idna==2.4,imagesize==0.7.1,iso8601=
> =0.1.11,Jinja2==2.9.5,jsonpatch==1.15,jsonpointer==1.10,jsonschema==2.6.0,
> keystoneauth1==2.18.0,keystonemiddleware==4.14.0,
> kombu==3.0.37,linecache2==1.0.0,logilab-common==1.3.0,
> logutils==0.3.4.1,Mako==1.0.6,MarkupSafe==0.23,mccabe==0.2.
> 1,mock==2.0.0,monotonic==1.2,mox3==0.20.0,msgpack-python==
> 0.4.8,netaddr==0.7.19,netifaces==0.10.5,-e git+https://github.com/
> openstack/networking-sfc.git@c51052e3748e917731f449b0ff4dc2
> 0d2e484490#egg=networking_sfc,-e git+https://github.com/
> openstack/neutron.git@41be555eddb0f9947fdaa4e73fa74a
> 72677d4d11#egg=neutron,neutron-lib==1.2.0,openstackdocstheme==1.6.1,
> openstacksdk==0.9.13,os-api-ref==1.3.0,os-client-config==
> 1.26.0,os-testr==0.8.0,osc-lib==1.3.0,oslo.concurrency==
> 3.19.0,oslo.config==3.22.0,oslo.context==2.12.1,oslo.db==
> 4.17.0,oslo.i18n==3.13.0,oslo.log==3.21.0,oslo.messaging==5.
> 18.0,oslo.middleware==3.23.1,oslo.policy==1.19.0,oslo.
> reports==1.17.0,oslo.rootwrap==5.4.0,oslo.serialization==2.
> 17.0,oslo.service==1.19.0,oslo.utils==3.22.0,oslo.
> versionedobjects==1.22.0,oslosphinx==4.10.0,oslotest==
> 2.14.0,ovs==2.7.0,packaging==16.8,paramiko==2.1.2,Paste==2.
> 0.3,PasteDeploy==1.5.2,pbr==2.0.0,pecan==1.2.1,pep8==1.5.7,
> pika==0.10.0,pika-pool==0.1.3,positional==1.1.1,prett

Re: [openstack-dev] [networking-sfc] patch test failed due to "import error: vlanmanager"

[Duarte Cardoso, Igor]

Hi Vikash,

What OS were you trying on before?

Best regards,
Igor.

From: Vikash Kumar [mailto:vikash.ku...@oneconvergence.com]
Sent: Thursday, March 9, 2017 10:08 AM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>; ke...@benton.pub
Subject: Re: [openstack-dev] [networking-sfc] patch test failed due to "import 
error: vlanmanager"

Tried on Ubuntu 16.04, its fine.

On Thu, Mar 9, 2017 at 12:17 PM, Vikash Kumar 
<vikash.ku...@oneconvergence.com<mailto:vikash.ku...@oneconvergence.com>> wrote:
Import path looks OK
https://github.com/openstack/networking-sfc/blob/master/networking_sfc/services/sfc/agent/extensions/openvswitch/sfc_driver.py#L23



Are u suggesting something else?

On Thu, Mar 9, 2017 at 3:02 AM, Kevin Benton 
<ke...@benton.pub<mailto:ke...@benton.pub>> wrote:
That location was recently changed in the Neutron side.[1] It sounds like sfc 
has to be updated.

1. 
https://github.com/openstack/neutron/commit/4ec456d31501f09c68b5c23c488878da32dce75e

On Tue, Mar 7, 2017 at 9:41 PM, Vikash Kumar 
<vikash.ku...@oneconvergence.com<mailto:vikash.ku...@oneconvergence.com>> wrote:
Hi Igor,
   This is weird. I just did a fresh clone and executed "tox" command. I am 
getting same error. Am I missing anything here ? There is no private change 
here.  Below is the link for entire log.

 http://paste.openstack.org/show/601870/

On Tue, Mar 7, 2017 at 10:46 PM, Duarte Cardoso, Igor 
<igor.duarte.card...@intel.com<mailto:igor.duarte.card...@intel.com>> wrote:
Hi Vikash,
Please stick to pastebin for complete logs.

Check your migration files:

FAILED: Contract HEAD file does not match migration timeline head, expected: 
48072cb59133

Best regards,
Igor.

From: Vikash Kumar 
[mailto:vikash.ku...@oneconvergence.com<mailto:vikash.ku...@oneconvergence.com>]
Sent: Tuesday, March 7, 2017 5:03 PM
To: openstack-dev 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [networking-sfc] patch test failed due to "import 
error: vlanmanager"

Complete log:

 py35 create: /home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35
py35 installdeps: 
-r/home/vikash/guess_vk/python-dev/networking-sfc/requirements.txt, 
-r/home/vikash/guess_vk/python-dev/networking-sfc/test-requirements.txt
py35 develop-inst: /home/vikash/guess_vk/python-dev/networking-sfc
py35 installed: 
/home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35/lib/python3.5/site.py:165:
 DeprecationWarning: 'U' mode is deprecated,  f = open(fullname, 
"rU"),alabaster==0.7.10,alembic==0.9.1,amqp==1.4.9,anyjson==0.3.3,appdirs==1.4.2,astroid==1.3.8,Babel==2.3.4,beautifulsoup4==4.5.3,cachetools==2.0.0,cffi==1.9.1,cliff==2.4.0,cmd2==0.7.0,contextlib2==0.5.4,coverage==4.3.4,cryptography==1.7.2,debtcollector==1.12.0,decorator==4.0.11,docutils==0.13.1,dulwich==0.17.1,eventlet==0.19.0,extras==1.0.0,fasteners==0.14.1,fixtures==3.0.0,flake8==2.5.5,futurist==0.21.0,greenlet==0.4.12,hacking==0.12.0,httplib2==0.10.3,idna==2.4,imagesize==0.7.1,iso8601==0.1.11,Jinja2==2.9.5,jsonpatch==1.15,jsonpointer==1.10,jsonschema==2.6.0,keystoneauth1==2.18.0,keystonemiddleware==4.14.0,kombu==3.0.37,linecache2==1.0.0,logilab-common==1.3.0,logutils==0.3.4.1,Mako==1.0.6,MarkupSafe==0.23,mccabe==0.2.1,mock==2.0.0,monotonic==1.2,mox3==0.20.0,msgpack-python==0.4.8,netaddr==0.7.19,netifaces==0.10.5,-e
 
git+https://github.com/openstack/networking-sfc.git@c51052e3748e917731f449b0ff4dc20d2e484490#egg=networking_sfc,-e
 
git+https://github.com/openstack/neutron.git@41be555eddb0f9947fdaa4e73fa74a72677d4d11#egg=neutron,neutron-lib==1.2.0,openstackdocstheme==1.6.1,openstacksdk==0.9.13,os-api-ref==1.3.0,os-client-config==1.26.0,os-testr==0.8.0,osc-lib==1.3.0,oslo.concurrency==3.19.0,oslo.config==3.22.0,oslo.context==2.12.1,oslo.db==4.17.0,oslo.i18n==3.13.0,oslo.log==3.21.0,oslo.messaging==5.18.0,oslo.middleware==3.23.1,oslo.policy==1.19.0,oslo.reports==1.17.0,oslo.rootwrap==5.4.0,oslo.serialization==2.17.0,oslo.service==1.19.0,oslo.utils==3.22.0,oslo.versionedobjects==1.22.0,oslosphinx==4.10.0,oslotest==2.14.0,ovs==2.7.0,packaging==16.8,paramiko==2.1.2,Paste==2.0.3,PasteDeploy==1.5.2,pbr==2.0.0,pecan==1.2.1,pep8==1.5.7,pika==0.10.0,pika-pool==0.1.3,positional==1.1.1,prettytable==0.7.2,psutil==5.2.0,psycopg2==2.7,pyasn1==0.2.3,pycadf==2.5.0,pycparser==2.17,pyflakes==0.8.1,Pygments==2.2.0,pyinotify==0.9.6,pylint==1.4.5,PyMySQL==0.7.10,pyparsing==2.2.0,python-cinderclient==1.11.0,python-dateutil==2.6.0,python-designateclient==2.6.0,python-editor==1.0.3,python-glanceclient==2.6.0,python-keystoneclient==3.10.0,python-mimeparse==1.6.0,python-neutronclient==6.1.0,python-novaclient==7.1.0,python-openstackclient==3.8.1,python-subunit==1.2.0,pytz==2016.10,PyYAML==3.12,reno==2.1.2,repoze.lru==0.6,requests==2.12.5,requests-mock==1.3.0,requestsexceptions==1.2.0,retrying==1.3.3,rfc3986==0.4.

Re: [openstack-dev] [networking-sfc] patch test failed due to "import error: vlanmanager"

[Vikash Kumar]

Tried on Ubuntu 16.04, its fine.

On Thu, Mar 9, 2017 at 12:17 PM, Vikash Kumar <
vikash.ku...@oneconvergence.com> wrote:

> Import path looks OK
> https://github.com/openstack/networking-sfc/blob/master/
> networking_sfc/services/sfc/agent/extensions/openvswitch/sfc_driver.py#L23
>
>
> Are u suggesting something else?
>
> On Thu, Mar 9, 2017 at 3:02 AM, Kevin Benton <ke...@benton.pub> wrote:
>
>> That location was recently changed in the Neutron side.[1] It sounds like
>> sfc has to be updated.
>>
>> 1. https://github.com/openstack/neutron/commit/4ec456d31501f
>> 09c68b5c23c488878da32dce75e
>>
>> On Tue, Mar 7, 2017 at 9:41 PM, Vikash Kumar <
>> vikash.ku...@oneconvergence.com> wrote:
>>
>>> Hi Igor,
>>>
>>>This is weird. I just did a fresh clone and executed *"tox" *command.
>>> I am getting same error. Am I missing anything here ? There is no private
>>> change here.  Below is the link for entire log.
>>>
>>>  http://paste.openstack.org/show/601870/
>>>
>>> On Tue, Mar 7, 2017 at 10:46 PM, Duarte Cardoso, Igor <
>>> igor.duarte.card...@intel.com> wrote:
>>>
>>>> Hi Vikash,
>>>>
>>>> Please stick to pastebin for complete logs.
>>>>
>>>>
>>>>
>>>> Check your migration files:
>>>>
>>>>
>>>>
>>>> FAILED: Contract HEAD file does not match migration timeline head,
>>>> expected: 48072cb59133
>>>>
>>>>
>>>>
>>>> Best regards,
>>>>
>>>> Igor.
>>>>
>>>>
>>>>
>>>> *From:* Vikash Kumar [mailto:vikash.ku...@oneconvergence.com]
>>>> *Sent:* Tuesday, March 7, 2017 5:03 PM
>>>> *To:* openstack-dev <openstack-dev@lists.openstack.org>
>>>> *Subject:* Re: [openstack-dev] [networking-sfc] patch test failed due
>>>> to "import error: vlanmanager"
>>>>
>>>>
>>>>
>>>> Complete log:
>>>>
>>>>  py35 create: /home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35
>>>> py35 installdeps: -r/home/vikash/guess_vk/python
>>>> -dev/networking-sfc/requirements.txt, -r/home/vikash/guess_vk/python
>>>> -dev/networking-sfc/test-requirements.txt
>>>> py35 develop-inst: /home/vikash/guess_vk/python-dev/networking-sfc
>>>> py35 installed: /home/vikash/guess_vk/python-d
>>>> ev/networking-sfc/.tox/py35/lib/python3.5/site.py:165:
>>>> DeprecationWarning: 'U' mode is deprecated,  f = open(fullname,
>>>> "rU"),alabaster==0.7.10,alembic==0.9.1,amqp==1.4.9,anyjson==
>>>> 0.3.3,appdirs==1.4.2,astroid==1.3.8,Babel==2.3.4,beautifulso
>>>> up4==4.5.3,cachetools==2.0.0,cffi==1.9.1,cliff==2.4.0,cmd2==
>>>> 0.7.0,contextlib2==0.5.4,coverage==4.3.4,cryptography==1.7.2
>>>> ,debtcollector==1.12.0,decorator==4.0.11,docutils==0.13.1,du
>>>> lwich==0.17.1,eventlet==0.19.0,extras==1.0.0,fasteners==0.
>>>> 14.1,fixtures==3.0.0,flake8==2.5.5,futurist==0.21.0,greenle
>>>> t==0.4.12,hacking==0.12.0,httplib2==0.10.3,idna==2.4,ima
>>>> gesize==0.7.1,iso8601==0.1.11,Jinja2==2.9.5,jsonpatch==1.15,
>>>> jsonpointer==1.10,jsonschema==2.6.0,keystoneauth1==2.18.0,
>>>> keystonemiddleware==4.14.0,kombu==3.0.37,linecache2==1.0.0,
>>>> logilab-common==1.3.0,logutils==0.3.4.1,Mako==1.0.6,MarkupSa
>>>> fe==0.23,mccabe==0.2.1,mock==2.0.0,monotonic==1.2,mox3==0.
>>>> 20.0,msgpack-python==0.4.8,netaddr==0.7.19,netifaces==0.10.5,-e git+
>>>> https://github.com/openstack/networking-sfc.git@c51052e3
>>>> 748e917731f449b0ff4dc20d2e484490#egg=networking_sfc,-e git+
>>>> https://github.com/openstack/neutron.git@41be555eddb0f99
>>>> 47fdaa4e73fa74a72677d4d11#egg=neutron,neutron-lib==1.2.0,ope
>>>> nstackdocstheme==1.6.1,openstacksdk==0.9.13,os-api-ref==1.3.
>>>> 0,os-client-config==1.26.0,os-testr==0.8.0,osc-lib==1.3.0,os
>>>> lo.concurrency==3.19.0,oslo.config==3.22.0,oslo.context==2.1
>>>> 2.1,oslo.db==4.17.0,oslo.i18n==3.13.0,oslo.log==3.21.0,oslo.
>>>> messaging==5.18.0,oslo.middleware==3.23.1,oslo.policy==1.19.
>>>> 0,oslo.reports==1.17.0,oslo.rootwrap==5.4.0,oslo.serializa
>>>> tion==2.17.0,oslo.service==1.19.0,oslo.utils==3.22.0,oslo.
>>>> versionedobjects==1.22.0,oslosphinx==4.10.0,oslotest==
>>>> 2.14.0,ovs==2.7.0,packaging==16.8,paramiko==2.1.2,Paste==2

Re: [openstack-dev] [networking-sfc] patch test failed due to "import error: vlanmanager"

[Vikash Kumar]

Import path looks OK
https://github.com/openstack/networking-sfc/blob/master/networking_sfc/services/sfc/agent/extensions/openvswitch/sfc_driver.py#L23


Are u suggesting something else?

On Thu, Mar 9, 2017 at 3:02 AM, Kevin Benton <ke...@benton.pub> wrote:

> That location was recently changed in the Neutron side.[1] It sounds like
> sfc has to be updated.
>
> 1. https://github.com/openstack/neutron/commit/
> 4ec456d31501f09c68b5c23c488878da32dce75e
>
> On Tue, Mar 7, 2017 at 9:41 PM, Vikash Kumar <vikash.kumar@oneconvergence.
> com> wrote:
>
>> Hi Igor,
>>
>>This is weird. I just did a fresh clone and executed *"tox" *command.
>> I am getting same error. Am I missing anything here ? There is no private
>> change here.  Below is the link for entire log.
>>
>>  http://paste.openstack.org/show/601870/
>>
>> On Tue, Mar 7, 2017 at 10:46 PM, Duarte Cardoso, Igor <
>> igor.duarte.card...@intel.com> wrote:
>>
>>> Hi Vikash,
>>>
>>> Please stick to pastebin for complete logs.
>>>
>>>
>>>
>>> Check your migration files:
>>>
>>>
>>>
>>> FAILED: Contract HEAD file does not match migration timeline head,
>>> expected: 48072cb59133
>>>
>>>
>>>
>>> Best regards,
>>>
>>> Igor.
>>>
>>>
>>>
>>> *From:* Vikash Kumar [mailto:vikash.ku...@oneconvergence.com]
>>> *Sent:* Tuesday, March 7, 2017 5:03 PM
>>> *To:* openstack-dev <openstack-dev@lists.openstack.org>
>>> *Subject:* Re: [openstack-dev] [networking-sfc] patch test failed due
>>> to "import error: vlanmanager"
>>>
>>>
>>>
>>> Complete log:
>>>
>>>  py35 create: /home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35
>>> py35 installdeps: -r/home/vikash/guess_vk/python
>>> -dev/networking-sfc/requirements.txt, -r/home/vikash/guess_vk/python
>>> -dev/networking-sfc/test-requirements.txt
>>> py35 develop-inst: /home/vikash/guess_vk/python-dev/networking-sfc
>>> py35 installed: /home/vikash/guess_vk/python-d
>>> ev/networking-sfc/.tox/py35/lib/python3.5/site.py:165:
>>> DeprecationWarning: 'U' mode is deprecated,  f = open(fullname,
>>> "rU"),alabaster==0.7.10,alembic==0.9.1,amqp==1.4.9,anyjson==
>>> 0.3.3,appdirs==1.4.2,astroid==1.3.8,Babel==2.3.4,beautifulso
>>> up4==4.5.3,cachetools==2.0.0,cffi==1.9.1,cliff==2.4.0,cmd2==
>>> 0.7.0,contextlib2==0.5.4,coverage==4.3.4,cryptography==1.7.
>>> 2,debtcollector==1.12.0,decorator==4.0.11,docutils==0.13.1,
>>> dulwich==0.17.1,eventlet==0.19.0,extras==1.0.0,fasteners==
>>> 0.14.1,fixtures==3.0.0,flake8==2.5.5,futurist==0.21.0,
>>> greenlet==0.4.12,hacking==0.12.0,httplib2==0.10.3,idna==2.4,
>>> imagesize==0.7.1,iso8601==0.1.11,Jinja2==2.9.5,jsonpatch==1.
>>> 15,jsonpointer==1.10,jsonschema==2.6.0,keystoneauth1==2.18.
>>> 0,keystonemiddleware==4.14.0,kombu==3.0.37,linecache2==1.0.
>>> 0,logilab-common==1.3.0,logutils==0.3.4.1,Mako==1.0.6,
>>> MarkupSafe==0.23,mccabe==0.2.1,mock==2.0.0,monotonic==1.2,
>>> mox3==0.20.0,msgpack-python==0.4.8,netaddr==0.7.19,netifaces==0.10.5,-e
>>> git+https://github.com/openstack/networking-sfc.git@c51052e3
>>> 748e917731f449b0ff4dc20d2e484490#egg=networking_sfc,-e git+
>>> https://github.com/openstack/neutron.git@41be555eddb0f99
>>> 47fdaa4e73fa74a72677d4d11#egg=neutron,neutron-lib==1.2.0,ope
>>> nstackdocstheme==1.6.1,openstacksdk==0.9.13,os-api-ref==1.3.
>>> 0,os-client-config==1.26.0,os-testr==0.8.0,osc-lib==1.3.0,os
>>> lo.concurrency==3.19.0,oslo.config==3.22.0,oslo.context==2.
>>> 12.1,oslo.db==4.17.0,oslo.i18n==3.13.0,oslo.log==3.21.0,oslo
>>> .messaging==5.18.0,oslo.middleware==3.23.1,oslo.policy==1.
>>> 19.0,oslo.reports==1.17.0,oslo.rootwrap==5.4.0,oslo.
>>> serialization==2.17.0,oslo.service==1.19.0,oslo.utils==3.
>>> 22.0,oslo.versionedobjects==1.22.0,oslosphinx==4.10.0,
>>> oslotest==2.14.0,ovs==2.7.0,packaging==16.8,paramiko==2.1.
>>> 2,Paste==2.0.3,PasteDeploy==1.5.2,pbr==2.0.0,pecan==1.2.1,
>>> pep8==1.5.7,pika==0.10.0,pika-pool==0.1.3,positional==1.1.1,
>>> prettytable==0.7.2,psutil==5.2.0,psycopg2==2.7,pyasn1==0.2.
>>> 3,pycadf==2.5.0,pycparser==2.17,pyflakes==0.8.1,Pygments==
>>> 2.2.0,pyinotify==0.9.6,pylint==1.4.5,PyMySQL==0.7.10,
>>> pyparsing==2.2.0,python-cinderclient==1.11.0,python-
>>> dateutil==2.6.0,python-designateclient==2.6.0,python-editor=
>>> =1.0.3,pytho

Re: [openstack-dev] [networking-sfc] patch test failed due to "import error: vlanmanager"

[Kevin Benton]

That location was recently changed in the Neutron side.[1] It sounds like
sfc has to be updated.

1.
https://github.com/openstack/neutron/commit/4ec456d31501f09c68b5c23c488878da32dce75e

On Tue, Mar 7, 2017 at 9:41 PM, Vikash Kumar <
vikash.ku...@oneconvergence.com> wrote:

> Hi Igor,
>
>This is weird. I just did a fresh clone and executed *"tox" *command.
> I am getting same error. Am I missing anything here ? There is no private
> change here.  Below is the link for entire log.
>
>  http://paste.openstack.org/show/601870/
>
> On Tue, Mar 7, 2017 at 10:46 PM, Duarte Cardoso, Igor <
> igor.duarte.card...@intel.com> wrote:
>
>> Hi Vikash,
>>
>> Please stick to pastebin for complete logs.
>>
>>
>>
>> Check your migration files:
>>
>>
>>
>> FAILED: Contract HEAD file does not match migration timeline head,
>> expected: 48072cb59133
>>
>>
>>
>> Best regards,
>>
>> Igor.
>>
>>
>>
>> *From:* Vikash Kumar [mailto:vikash.ku...@oneconvergence.com]
>> *Sent:* Tuesday, March 7, 2017 5:03 PM
>> *To:* openstack-dev <openstack-dev@lists.openstack.org>
>> *Subject:* Re: [openstack-dev] [networking-sfc] patch test failed due to
>> "import error: vlanmanager"
>>
>>
>>
>> Complete log:
>>
>>  py35 create: /home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35
>> py35 installdeps: -r/home/vikash/guess_vk/python
>> -dev/networking-sfc/requirements.txt, -r/home/vikash/guess_vk/python
>> -dev/networking-sfc/test-requirements.txt
>> py35 develop-inst: /home/vikash/guess_vk/python-dev/networking-sfc
>> py35 installed: /home/vikash/guess_vk/python-d
>> ev/networking-sfc/.tox/py35/lib/python3.5/site.py:165:
>> DeprecationWarning: 'U' mode is deprecated,  f = open(fullname,
>> "rU"),alabaster==0.7.10,alembic==0.9.1,amqp==1.4.9,anyjson==
>> 0.3.3,appdirs==1.4.2,astroid==1.3.8,Babel==2.3.4,beautifulso
>> up4==4.5.3,cachetools==2.0.0,cffi==1.9.1,cliff==2.4.0,cmd2=
>> =0.7.0,contextlib2==0.5.4,coverage==4.3.4,cryptography==
>> 1.7.2,debtcollector==1.12.0,decorator==4.0.11,docutils==0.13
>> .1,dulwich==0.17.1,eventlet==0.19.0,extras==1.0.0,fasteners
>> ==0.14.1,fixtures==3.0.0,flake8==2.5.5,futurist==0.21.
>> 0,greenlet==0.4.12,hacking==0.12.0,httplib2==0.10.3,idna==2.
>> 4,imagesize==0.7.1,iso8601==0.1.11,Jinja2==2.9.5,jsonpatch==
>> 1.15,jsonpointer==1.10,jsonschema==2.6.0,keystoneauth
>> 1==2.18.0,keystonemiddleware==4.14.0,kombu==3.0.37,
>> linecache2==1.0.0,logilab-common==1.3.0,logutils==0.3.4.
>> 1,Mako==1.0.6,MarkupSafe==0.23,mccabe==0.2.1,mock==2.0.0,
>> monotonic==1.2,mox3==0.20.0,msgpack-python==0.4.8,netaddr==0.7.19,netifaces==0.10.5,-e
>> git+https://github.com/openstack/networking-sfc.git@c51052e3
>> 748e917731f449b0ff4dc20d2e484490#egg=networking_sfc,-e git+
>> https://github.com/openstack/neutron.git@41be555eddb0f99
>> 47fdaa4e73fa74a72677d4d11#egg=neutron,neutron-lib==1.2.0,ope
>> nstackdocstheme==1.6.1,openstacksdk==0.9.13,os-api-ref==1.3.
>> 0,os-client-config==1.26.0,os-testr==0.8.0,osc-lib==1.3.0,
>> oslo.concurrency==3.19.0,oslo.config==3.22.0,oslo.context==
>> 2.12.1,oslo.db==4.17.0,oslo.i18n==3.13.0,oslo.log==3.21.0,
>> oslo.messaging==5.18.0,oslo.middleware==3.23.1,oslo.
>> policy==1.19.0,oslo.reports==1.17.0,oslo.rootwrap==5.4.0,
>> oslo.serialization==2.17.0,oslo.service==1.19.0,oslo.
>> utils==3.22.0,oslo.versionedobjects==1.22.0,oslosphinx==4.
>> 10.0,oslotest==2.14.0,ovs==2.7.0,packaging==16.8,paramiko==
>> 2.1.2,Paste==2.0.3,PasteDeploy==1.5.2,pbr==2.0.0,
>> pecan==1.2.1,pep8==1.5.7,pika==0.10.0,pika-pool==0.1.3,posit
>> ional==1.1.1,prettytable==0.7.2,psutil==5.2.0,psycopg2==2.7,
>> pyasn1==0.2.3,pycadf==2.5.0,pycparser==2.17,pyflakes==0.8.
>> 1,Pygments==2.2.0,pyinotify==0.9.6,pylint==1.4.5,PyMySQL==
>> 0.7.10,pyparsing==2.2.0,python-cinderclient==1.11.0,
>> python-dateutil==2.6.0,python-designateclient==2.6.0,python-
>> editor==1.0.3,python-glanceclient==2.6.0,python-keystoneclie
>> nt==3.10.0,python-mimeparse==1.6.0,python-neutronclient==6.
>> 1.0,python-novaclient==7.1.0,python-openstackclient==3.8.1,
>> python-subunit==1.2.0,pytz==2016.10,PyYAML==3.12,reno==2.
>> 1.2,repoze.lru==0.6,requests==2.12.5,requests-mock==1.3.0,re
>> questsexceptions==1.2.0,retrying==1.3.3,rfc3986==0.4.1,
>> Routes==2.4.1,ryu==4.12,simplejson==3.10.0,six==1.10.0,
>> snowballstemmer==1.2.1,Sphinx==1.5.3,SQLAlchemy==1.0.17,
>> sqlalchemy-migrate==0.11.0,sqlparse==0.2.3,statsd==3.2.1,ste
>> vedore==1.21.0,tempest-lib==1.0.0,Tempita==0.5.2,tenacity==

Re: [openstack-dev] [networking-sfc] patch test failed due to "import error: vlanmanager"

[Vikash Kumar]

Hi Igor,

   This is weird. I just did a fresh clone and executed *"tox" *command. I
am getting same error. Am I missing anything here ? There is no private
change here.  Below is the link for entire log.

 http://paste.openstack.org/show/601870/

On Tue, Mar 7, 2017 at 10:46 PM, Duarte Cardoso, Igor <
igor.duarte.card...@intel.com> wrote:

> Hi Vikash,
>
> Please stick to pastebin for complete logs.
>
>
>
> Check your migration files:
>
>
>
> FAILED: Contract HEAD file does not match migration timeline head,
> expected: 48072cb59133
>
>
>
> Best regards,
>
> Igor.
>
>
>
> *From:* Vikash Kumar [mailto:vikash.ku...@oneconvergence.com]
> *Sent:* Tuesday, March 7, 2017 5:03 PM
> *To:* openstack-dev <openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [networking-sfc] patch test failed due to
> "import error: vlanmanager"
>
>
>
> Complete log:
>
>  py35 create: /home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35
> py35 installdeps: 
> -r/home/vikash/guess_vk/python-dev/networking-sfc/requirements.txt,
> -r/home/vikash/guess_vk/python-dev/networking-sfc/test-requirements.txt
> py35 develop-inst: /home/vikash/guess_vk/python-dev/networking-sfc
> py35 installed: 
> /home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35/lib/python3.5/site.py:165:
> DeprecationWarning: 'U' mode is deprecated,  f = open(fullname,
> "rU"),alabaster==0.7.10,alembic==0.9.1,amqp==1.4.9,
> anyjson==0.3.3,appdirs==1.4.2,astroid==1.3.8,Babel==2.3.4,
> beautifulsoup4==4.5.3,cachetools==2.0.0,cffi==1.9.1,
> cliff==2.4.0,cmd2==0.7.0,contextlib2==0.5.4,coverage==
> 4.3.4,cryptography==1.7.2,debtcollector==1.12.0,
> decorator==4.0.11,docutils==0.13.1,dulwich==0.17.1,eventlet=
> =0.19.0,extras==1.0.0,fasteners==0.14.1,fixtures==3.
> 0.0,flake8==2.5.5,futurist==0.21.0,greenlet==0.4.12,hacking=
> =0.12.0,httplib2==0.10.3,idna==2.4,imagesize==0.7.1,iso8601=
> =0.1.11,Jinja2==2.9.5,jsonpatch==1.15,jsonpointer==1.10,jsonschema==2.6.0,
> keystoneauth1==2.18.0,keystonemiddleware==4.14.0,
> kombu==3.0.37,linecache2==1.0.0,logilab-common==1.3.0,
> logutils==0.3.4.1,Mako==1.0.6,MarkupSafe==0.23,mccabe==0.2.
> 1,mock==2.0.0,monotonic==1.2,mox3==0.20.0,msgpack-python==
> 0.4.8,netaddr==0.7.19,netifaces==0.10.5,-e git+https://github.com/
> openstack/networking-sfc.git@c51052e3748e917731f449b0ff4dc2
> 0d2e484490#egg=networking_sfc,-e git+https://github.com/
> openstack/neutron.git@41be555eddb0f9947fdaa4e73fa74a
> 72677d4d11#egg=neutron,neutron-lib==1.2.0,openstackdocstheme==1.6.1,
> openstacksdk==0.9.13,os-api-ref==1.3.0,os-client-config==
> 1.26.0,os-testr==0.8.0,osc-lib==1.3.0,oslo.concurrency==
> 3.19.0,oslo.config==3.22.0,oslo.context==2.12.1,oslo.db==
> 4.17.0,oslo.i18n==3.13.0,oslo.log==3.21.0,oslo.messaging==5.
> 18.0,oslo.middleware==3.23.1,oslo.policy==1.19.0,oslo.
> reports==1.17.0,oslo.rootwrap==5.4.0,oslo.serialization==2.
> 17.0,oslo.service==1.19.0,oslo.utils==3.22.0,oslo.
> versionedobjects==1.22.0,oslosphinx==4.10.0,oslotest==
> 2.14.0,ovs==2.7.0,packaging==16.8,paramiko==2.1.2,Paste==2.
> 0.3,PasteDeploy==1.5.2,pbr==2.0.0,pecan==1.2.1,pep8==1.5.7,
> pika==0.10.0,pika-pool==0.1.3,positional==1.1.1,prettytable=
> =0.7.2,psutil==5.2.0,psycopg2==2.7,pyasn1==0.2.3,pycadf==2.
> 5.0,pycparser==2.17,pyflakes==0.8.1,Pygments==2.2.0,
> pyinotify==0.9.6,pylint==1.4.5,PyMySQL==0.7.10,pyparsing==
> 2.2.0,python-cinderclient==1.11.0,python-dateutil==2.6.0,
> python-designateclient==2.6.0,python-editor==1.0.3,python-
> glanceclient==2.6.0,python-keystoneclient==3.10.0,python-
> mimeparse==1.6.0,python-neutronclient==6.1.0,python-
> novaclient==7.1.0,python-openstackclient==3.8.1,python-
> subunit==1.2.0,pytz==2016.10,PyYAML==3.12,reno==2.1.2,
> repoze.lru==0.6,requests==2.12.5,requests-mock==1.3.0,
> requestsexceptions==1.2.0,retrying==1.3.3,rfc3986==0.4.
> 1,Routes==2.4.1,ryu==4.12,simplejson==3.10.0,six==1.10.
> 0,snowballstemmer==1.2.1,Sphinx==1.5.3,SQLAlchemy==1.0.
> 17,sqlalchemy-migrate==0.11.0,sqlparse==0.2.3,statsd==3.2.1,
> stevedore==1.21.0,tempest-lib==1.0.0,Tempita==0.5.2,tenacity==3.7.1,
> testrepository==0.0.20,testresources==2.0.1,testscenarios==0.5.0,
> testtools==2.2.0,tinyrpc==0.5,traceback2==1.4.0,unittest2==
> 1.1.0,waitress==1.0.2,warlock==1.2.0,WebOb==1.6.3,WebTest==
> 2.0.26,wrapt==1.10.8
> py35 runtests: PYTHONHASHSEED='177840'
> py35 runtests: commands[0] | find . -type f -name *.py[c|o] -delete
> py35 runtests: commands[1] | find . -type d -name __pycache__ -delete
> py35 runtests: commands[2] | /home/vikash/guess_vk/python-
> dev/networking-sfc/tools/ostestr_compat_shim.sh
> /home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35/lib/python3.5/site.py:165:
> DeprecationWa

Re: [openstack-dev] [networking-sfc] patch test failed due to "import error: vlanmanager"

[Duarte Cardoso, Igor]

Hi Vikash,
Please stick to pastebin for complete logs.

Check your migration files:

FAILED: Contract HEAD file does not match migration timeline head, expected: 
48072cb59133

Best regards,
Igor.

From: Vikash Kumar [mailto:vikash.ku...@oneconvergence.com]
Sent: Tuesday, March 7, 2017 5:03 PM
To: openstack-dev <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [networking-sfc] patch test failed due to "import 
error: vlanmanager"

Complete log:

 py35 create: /home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35
py35 installdeps: 
-r/home/vikash/guess_vk/python-dev/networking-sfc/requirements.txt, 
-r/home/vikash/guess_vk/python-dev/networking-sfc/test-requirements.txt
py35 develop-inst: /home/vikash/guess_vk/python-dev/networking-sfc
py35 installed: 
/home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35/lib/python3.5/site.py:165:
 DeprecationWarning: 'U' mode is deprecated,  f = open(fullname, 
"rU"),alabaster==0.7.10,alembic==0.9.1,amqp==1.4.9,anyjson==0.3.3,appdirs==1.4.2,astroid==1.3.8,Babel==2.3.4,beautifulsoup4==4.5.3,cachetools==2.0.0,cffi==1.9.1,cliff==2.4.0,cmd2==0.7.0,contextlib2==0.5.4,coverage==4.3.4,cryptography==1.7.2,debtcollector==1.12.0,decorator==4.0.11,docutils==0.13.1,dulwich==0.17.1,eventlet==0.19.0,extras==1.0.0,fasteners==0.14.1,fixtures==3.0.0,flake8==2.5.5,futurist==0.21.0,greenlet==0.4.12,hacking==0.12.0,httplib2==0.10.3,idna==2.4,imagesize==0.7.1,iso8601==0.1.11,Jinja2==2.9.5,jsonpatch==1.15,jsonpointer==1.10,jsonschema==2.6.0,keystoneauth1==2.18.0,keystonemiddleware==4.14.0,kombu==3.0.37,linecache2==1.0.0,logilab-common==1.3.0,logutils==0.3.4.1,Mako==1.0.6,MarkupSafe==0.23,mccabe==0.2.1,mock==2.0.0,monotonic==1.2,mox3==0.20.0,msgpack-python==0.4.8,netaddr==0.7.19,netifaces==0.10.5,-e
 
git+https://github.com/openstack/networking-sfc.git@c51052e3748e917731f449b0ff4dc20d2e484490#egg=networking_sfc,-e
 
git+https://github.com/openstack/neutron.git@41be555eddb0f9947fdaa4e73fa74a72677d4d11#egg=neutron,neutron-lib==1.2.0,openstackdocstheme==1.6.1,openstacksdk==0.9.13,os-api-ref==1.3.0,os-client-config==1.26.0,os-testr==0.8.0,osc-lib==1.3.0,oslo.concurrency==3.19.0,oslo.config==3.22.0,oslo.context==2.12.1,oslo.db==4.17.0,oslo.i18n==3.13.0,oslo.log==3.21.0,oslo.messaging==5.18.0,oslo.middleware==3.23.1,oslo.policy==1.19.0,oslo.reports==1.17.0,oslo.rootwrap==5.4.0,oslo.serialization==2.17.0,oslo.service==1.19.0,oslo.utils==3.22.0,oslo.versionedobjects==1.22.0,oslosphinx==4.10.0,oslotest==2.14.0,ovs==2.7.0,packaging==16.8,paramiko==2.1.2,Paste==2.0.3,PasteDeploy==1.5.2,pbr==2.0.0,pecan==1.2.1,pep8==1.5.7,pika==0.10.0,pika-pool==0.1.3,positional==1.1.1,prettytable==0.7.2,psutil==5.2.0,psycopg2==2.7,pyasn1==0.2.3,pycadf==2.5.0,pycparser==2.17,pyflakes==0.8.1,Pygments==2.2.0,pyinotify==0.9.6,pylint==1.4.5,PyMySQL==0.7.10,pyparsing==2.2.0,python-cinderclient==1.11.0,python-dateutil==2.6.0,python-designateclient==2.6.0,python-editor==1.0.3,python-glanceclient==2.6.0,python-keystoneclient==3.10.0,python-mimeparse==1.6.0,python-neutronclient==6.1.0,python-novaclient==7.1.0,python-openstackclient==3.8.1,python-subunit==1.2.0,pytz==2016.10,PyYAML==3.12,reno==2.1.2,repoze.lru==0.6,requests==2.12.5,requests-mock==1.3.0,requestsexceptions==1.2.0,retrying==1.3.3,rfc3986==0.4.1,Routes==2.4.1,ryu==4.12,simplejson==3.10.0,six==1.10.0,snowballstemmer==1.2.1,Sphinx==1.5.3,SQLAlchemy==1.0.17,sqlalchemy-migrate==0.11.0,sqlparse==0.2.3,statsd==3.2.1,stevedore==1.21.0,tempest-lib==1.0.0,Tempita==0.5.2,tenacity==3.7.1,testrepository==0.0.20,testresources==2.0.1,testscenarios==0.5.0,testtools==2.2.0,tinyrpc==0.5,traceback2==1.4.0,unittest2==1.1.0,waitress==1.0.2,warlock==1.2.0,WebOb==1.6.3,WebTest==2.0.26,wrapt==1.10.8
py35 runtests: PYTHONHASHSEED='177840'
py35 runtests: commands[0] | find . -type f -name *.py[c|o] -delete
py35 runtests: commands[1] | find . -type d -name __pycache__ -delete
py35 runtests: commands[2] | 
/home/vikash/guess_vk/python-dev/networking-sfc/tools/ostestr_compat_shim.sh
/home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35/lib/python3.5/site.py:165:
 DeprecationWarning: 'U' mode is deprecated
  f = open(fullname, "rU")
/home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35/lib/python3.5/site.py:165:
 DeprecationWarning: 'U' mode is deprecated
  f = open(fullname, "rU")
/home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35/lib/python3.5/site.py:165:
 DeprecationWarning: 'U' mode is deprecated
  f = open(fullname, "rU")
/home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35/lib/python3.5/site.py:165:
 DeprecationWarning: 'U' mode is deprecated
  f = open(fullname, "rU")
/home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35/lib/python3.5/site-packages/positional/__init__.py:74:
 DeprecationWarning: inspect.getargspec() is deprecated, use 
inspect.signature() instead
  spec = inspect.getargspec(func)
/home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35/lib/python3

Re: [openstack-dev] [networking-sfc] patch test failed due to "import error: vlanmanager"

[Vikash Kumar]

Complete log:

 py35 create: /home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35
py35 installdeps:
-r/home/vikash/guess_vk/python-dev/networking-sfc/requirements.txt,
-r/home/vikash/guess_vk/python-dev/networking-sfc/test-requirements.txt
py35 develop-inst: /home/vikash/guess_vk/python-dev/networking-sfc
py35 installed:
/home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35/lib/python3.5/site.py:165:
DeprecationWarning: 'U' mode is deprecated,  f = open(fullname,
"rU"),alabaster==0.7.10,alembic==0.9.1,amqp==1.4.9,anyjson==0.3.3,appdirs==1.4.2,astroid==1.3.8,Babel==2.3.4,beautifulsoup4==4.5.3,cachetools==2.0.0,cffi==1.9.1,cliff==2.4.0,cmd2==0.7.0,contextlib2==0.5.4,coverage==4.3.4,cryptography==1.7.2,debtcollector==1.12.0,decorator==4.0.11,docutils==0.13.1,dulwich==0.17.1,eventlet==0.19.0,extras==1.0.0,fasteners==0.14.1,fixtures==3.0.0,flake8==2.5.5,futurist==0.21.0,greenlet==0.4.12,hacking==0.12.0,httplib2==0.10.3,idna==2.4,imagesize==0.7.1,iso8601==0.1.11,Jinja2==2.9.5,jsonpatch==1.15,jsonpointer==1.10,jsonschema==2.6.0,keystoneauth1==2.18.0,keystonemiddleware==4.14.0,kombu==3.0.37,linecache2==1.0.0,logilab-common==1.3.0,logutils==0.3.4.1,Mako==1.0.6,MarkupSafe==0.23,mccabe==0.2.1,mock==2.0.0,monotonic==1.2,mox3==0.20.0,msgpack-python==0.4.8,netaddr==0.7.19,netifaces==0.10.5,-e
git+
https://github.com/openstack/networking-sfc.git@c51052e3748e917731f449b0ff4dc20d2e484490#egg=networking_sfc,-e
git+
https://github.com/openstack/neutron.git@41be555eddb0f9947fdaa4e73fa74a72677d4d11#egg=neutron,neutron-lib==1.2.0,openstackdocstheme==1.6.1,openstacksdk==0.9.13,os-api-ref==1.3.0,os-client-config==1.26.0,os-testr==0.8.0,osc-lib==1.3.0,oslo.concurrency==3.19.0,oslo.config==3.22.0,oslo.context==2.12.1,oslo.db==4.17.0,oslo.i18n==3.13.0,oslo.log==3.21.0,oslo.messaging==5.18.0,oslo.middleware==3.23.1,oslo.policy==1.19.0,oslo.reports==1.17.0,oslo.rootwrap==5.4.0,oslo.serialization==2.17.0,oslo.service==1.19.0,oslo.utils==3.22.0,oslo.versionedobjects==1.22.0,oslosphinx==4.10.0,oslotest==2.14.0,ovs==2.7.0,packaging==16.8,paramiko==2.1.2,Paste==2.0.3,PasteDeploy==1.5.2,pbr==2.0.0,pecan==1.2.1,pep8==1.5.7,pika==0.10.0,pika-pool==0.1.3,positional==1.1.1,prettytable==0.7.2,psutil==5.2.0,psycopg2==2.7,pyasn1==0.2.3,pycadf==2.5.0,pycparser==2.17,pyflakes==0.8.1,Pygments==2.2.0,pyinotify==0.9.6,pylint==1.4.5,PyMySQL==0.7.10,pyparsing==2.2.0,python-cinderclient==1.11.0,python-dateutil==2.6.0,python-designateclient==2.6.0,python-editor==1.0.3,python-glanceclient==2.6.0,python-keystoneclient==3.10.0,python-mimeparse==1.6.0,python-neutronclient==6.1.0,python-novaclient==7.1.0,python-openstackclient==3.8.1,python-subunit==1.2.0,pytz==2016.10,PyYAML==3.12,reno==2.1.2,repoze.lru==0.6,requests==2.12.5,requests-mock==1.3.0,requestsexceptions==1.2.0,retrying==1.3.3,rfc3986==0.4.1,Routes==2.4.1,ryu==4.12,simplejson==3.10.0,six==1.10.0,snowballstemmer==1.2.1,Sphinx==1.5.3,SQLAlchemy==1.0.17,sqlalchemy-migrate==0.11.0,sqlparse==0.2.3,statsd==3.2.1,stevedore==1.21.0,tempest-lib==1.0.0,Tempita==0.5.2,tenacity==3.7.1,testrepository==0.0.20,testresources==2.0.1,testscenarios==0.5.0,testtools==2.2.0,tinyrpc==0.5,traceback2==1.4.0,unittest2==1.1.0,waitress==1.0.2,warlock==1.2.0,WebOb==1.6.3,WebTest==2.0.26,wrapt==1.10.8
py35 runtests: PYTHONHASHSEED='177840'
py35 runtests: commands[0] | find . -type f -name *.py[c|o] -delete
py35 runtests: commands[1] | find . -type d -name __pycache__ -delete
py35 runtests: commands[2] |
/home/vikash/guess_vk/python-dev/networking-sfc/tools/ostestr_compat_shim.sh

/home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35/lib/python3.5/site.py:165:
DeprecationWarning: 'U' mode is deprecated
  f = open(fullname, "rU")
/home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35/lib/python3.5/site.py:165:
DeprecationWarning: 'U' mode is deprecated
  f = open(fullname, "rU")
/home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35/lib/python3.5/site.py:165:
DeprecationWarning: 'U' mode is deprecated
  f = open(fullname, "rU")
/home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35/lib/python3.5/site.py:165:
DeprecationWarning: 'U' mode is deprecated
  f = open(fullname, "rU")
/home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35/lib/python3.5/site-packages/positional/__init__.py:74:
DeprecationWarning: inspect.getargspec() is deprecated, use
inspect.signature() instead
  spec = inspect.getargspec(func)
/home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35/lib/python3.5/site-packages/wrapt/wrappers.py:522:
DeprecationWarning: Using the 'sqlite_db' argument is deprecated: Config
option sqlite_db is deprecated for removal,please use option `connection`.
  args, kwargs)
/home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35/lib/python3.5/site-packages/wrapt/wrappers.py:561:
DeprecationWarning: Using the 'retry_on_request' argument is deprecated:
Retry on request is always enabled
  args, kwargs)

[openstack-dev] [networking-sfc] patch test failed due to "import error: vlanmanager"

[Vikash Kumar]

Hi,

I was testing patch on master branch, but the test is failing because
of the import error.

http://paste.openstack.org/show/601794/

-- 
Regards,
Vikash
__
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

Re: [openstack-dev] [networking-sfc] Stable/Ocata Version

[Jeffrey Zhang]

roger. thanks all guys.

On Tue, Mar 7, 2017 at 3:26 AM, Cathy Zhang <cathy.h.zh...@huawei.com>
wrote:

> Just completed.
>
>
>
> Cathy
>
>
>
> *From:* Jeffrey Zhang [mailto:zhang.lei@gmail.com]
> *Sent:* Friday, March 03, 2017 6:59 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [networking-sfc] Stable/Ocata Version
>
>
>
> any update for releasing stable/ocata branch or tag? It is Mar already.
>
>
>
> On Tue, Feb 21, 2017 at 1:23 AM, Henry Fourie <louis.fou...@huawei.com>
> wrote:
>
> Gary,
>
>The plan is to have a stable/ocata branch by end of month.
>
> -Louis
>
>
>
> *From:* Gary Kotton [mailto:gkot...@vmware.com]
> *Sent:* Sunday, February 19, 2017 4:29 AM
> *To:* OpenStack List
> *Subject:* [openstack-dev] [networking-sfc] Stable/Ocata Version
>
>
>
> Hi,
>
> When will this repo have a stable/ocata branch?
>
> Thanks
>
> Gary
>
>
> __
> 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
>
>
>
>
>
> --
>
> Regards,
>
> Jeffrey Zhang
>
> Blog: http://xcodest.me
>
> __
> 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
>
>


-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
__
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

Re: [openstack-dev] [networking-sfc] Stable/Ocata Version

[Cathy Zhang]

Just completed.

Cathy

From: Jeffrey Zhang [mailto:zhang.lei@gmail.com]
Sent: Friday, March 03, 2017 6:59 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [networking-sfc] Stable/Ocata Version

any update for releasing stable/ocata branch or tag? It is Mar already.

On Tue, Feb 21, 2017 at 1:23 AM, Henry Fourie 
<louis.fou...@huawei.com<mailto:louis.fou...@huawei.com>> wrote:
Gary,
   The plan is to have a stable/ocata branch by end of month.

-Louis

From: Gary Kotton [mailto:gkot...@vmware.com<mailto:gkot...@vmware.com>]
Sent: Sunday, February 19, 2017 4:29 AM
To: OpenStack List
Subject: [openstack-dev] [networking-sfc] Stable/Ocata Version

Hi,
When will this repo have a stable/ocata branch?
Thanks
Gary

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Regards,
Jeffrey Zhang
Blog: http://xcodest.me<http://xcodest.me/>
__
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

Re: [openstack-dev] [networking-sfc] Stable/Ocata Version

[Dariusz Śmigiel]

2017-03-06 11:25 GMT-06:00 Henry Fourie :
> Jeffrey,
>
>The branch pull is awaiting approval:
>
> https://review.openstack.org/#/c/439200

Just got merged.

__
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

Re: [openstack-dev] [networking-sfc] Stable/Ocata Version

[Henry Fourie]

Jeffrey,
   The branch pull is awaiting approval:
https://review.openstack.org/#/c/439200

-Louis

From: Jeffrey Zhang [mailto:zhang.lei@gmail.com]
Sent: Friday, March 03, 2017 6:59 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [networking-sfc] Stable/Ocata Version

any update for releasing stable/ocata branch or tag? It is Mar already.

On Tue, Feb 21, 2017 at 1:23 AM, Henry Fourie 
<louis.fou...@huawei.com<mailto:louis.fou...@huawei.com>> wrote:
Gary,
   The plan is to have a stable/ocata branch by end of month.

-Louis

From: Gary Kotton [mailto:gkot...@vmware.com<mailto:gkot...@vmware.com>]
Sent: Sunday, February 19, 2017 4:29 AM
To: OpenStack List
Subject: [openstack-dev] [networking-sfc] Stable/Ocata Version

Hi,
When will this repo have a stable/ocata branch?
Thanks
Gary

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Regards,
Jeffrey Zhang
Blog: http://xcodest.me<http://xcodest.me/>
__
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

Re: [openstack-dev] [networking-sfc] Stable/Ocata Version

[Jeffrey Zhang]

any update for releasing stable/ocata branch or tag? It is Mar already.

On Tue, Feb 21, 2017 at 1:23 AM, Henry Fourie <louis.fou...@huawei.com>
wrote:

> Gary,
>
>The plan is to have a stable/ocata branch by end of month.
>
> -Louis
>
>
>
> *From:* Gary Kotton [mailto:gkot...@vmware.com]
> *Sent:* Sunday, February 19, 2017 4:29 AM
> *To:* OpenStack List
> *Subject:* [openstack-dev] [networking-sfc] Stable/Ocata Version
>
>
>
> Hi,
>
> When will this repo have a stable/ocata branch?
>
> Thanks
>
> Gary
>
> __
> 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
>
>


-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
__
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

Re: [openstack-dev] [networking-sfc] PTG notes

[Cathy Zhang]

Hi Bernard,

Thanks for the notes! I just talked with Louis. We will pull the stable branch 
for networking-sfc today. 
I hope after the branch is pulled, everyone can help doing more testing on the 
stable branch to make it more stable:-)

Thanks,
Cathy


-Original Message-
From: Bernard Cafarelli [mailto:bcafa...@redhat.com] 
Sent: Tuesday, February 28, 2017 7:04 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [networking-sfc] PTG notes

Hi,

I will miss the next two IRC meetings, so here is a quick summary email of PTG 
topics of interest for networking-sfc in the Pike cycle.

* Release, stable branching, stadium requirements For Ocata, neutron-lib 
patches are waiting for our stable branch creation (should be OK today?). The 
release itself is not as urgent, so we can still run some tests after merging 
the last open feature [0], and before tagging the release For Pike, stadium 
projects will synchronize releases with neutron [1] Except from more generic 
requirements, no new specific requirements to expect in this cycle

* Tempest tests
Two interesting items here:
 * Split tempest plugin repositories [2]: if agreed we will move the tempest 
plugin in a separate branchless repository (and proper configuration depending 
on features)
 * Refactor of tempest scenario base classes [3]: we will probably have to keep 
our copy of manager.py, and update to new API when it is ready

* Python 3.5 support
This is a project-wide goal for Pike, we have python3 unit tests already, but 
we should add a tempest/python3 check, and make it work (without forgetting the 
currently buggy multinode check)

* neutron-lib hacking checks
These are additional PEP8 checks we should enable as a neutron-lib consumer 
project. Some changes are underway [4], but we should enable these in 
networking-sfc

* API updates
Changes need to be advertised via a new extension (SFC graphs current review)

* Push notifications
This is in progress for Neutron [5], but can be nice for stadium projects too

* Common classifier
This probably deserves its separate topic, but we had an interesting session 
(possible consumers: networking-bpvpn, networking-sfc, FWaaS, QoS, 
Tap-as-a-Service, …) [6]


The completed neutron etherpad is at [7], with Kevin's nice summary at [8] I 
leave it to other PTG attendees to correct/extend this list!

[0] https://review.openstack.org/#/c/420339/
[1] https://review.openstack.org/#/c/437699/
[2] https://etherpad.openstack.org/p/qa-ptg-pike-tempest-plugins
[3] http://lists.openstack.org/pipermail/openstack-dev/2017-February/112938.html
[4] http://lists.openstack.org/pipermail/openstack-dev/2017-February/112988.html
[5] https://blueprints.launchpad.net/neutron/+spec/push-notifications
[6] https://review.openstack.org/#/c/333993/
[7] https://etherpad.openstack.org/p/neutron-ptg-pike-final
[8] http://lists.openstack.org/pipermail/openstack-dev/2017-February/113032.html

--
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

[openstack-dev] [networking-sfc] PTG notes

[Bernard Cafarelli]

Hi,

I will miss the next two IRC meetings, so here is a quick summary
email of PTG topics of interest for networking-sfc in the Pike cycle.

* Release, stable branching, stadium requirements
For Ocata, neutron-lib patches are waiting for our stable branch
creation (should be OK today?). The release itself is not as urgent,
so we can still run some tests after merging the last open feature
[0], and before tagging the release
For Pike, stadium projects will synchronize releases with neutron [1]
Except from more generic requirements, no new specific requirements to
expect in this cycle

* Tempest tests
Two interesting items here:
 * Split tempest plugin repositories [2]: if agreed we will move the
tempest plugin in a separate branchless repository (and proper
configuration depending on features)
 * Refactor of tempest scenario base classes [3]: we will probably
have to keep our copy of manager.py, and update to new API when it is
ready

* Python 3.5 support
This is a project-wide goal for Pike, we have python3 unit tests
already, but we should add a tempest/python3 check, and make it work
(without forgetting the currently buggy multinode check)

* neutron-lib hacking checks
These are additional PEP8 checks we should enable as a neutron-lib
consumer project. Some changes are underway [4], but we should enable
these in networking-sfc

* API updates
Changes need to be advertised via a new extension (SFC graphs current review)

* Push notifications
This is in progress for Neutron [5], but can be nice for stadium projects too

* Common classifier
This probably deserves its separate topic, but we had an interesting
session (possible consumers: networking-bpvpn, networking-sfc, FWaaS,
QoS, Tap-as-a-Service, …) [6]


The completed neutron etherpad is at [7], with Kevin's nice summary at [8]
I leave it to other PTG attendees to correct/extend this list!

[0] https://review.openstack.org/#/c/420339/
[1] https://review.openstack.org/#/c/437699/
[2] https://etherpad.openstack.org/p/qa-ptg-pike-tempest-plugins
[3] http://lists.openstack.org/pipermail/openstack-dev/2017-February/112938.html
[4] http://lists.openstack.org/pipermail/openstack-dev/2017-February/112988.html
[5] https://blueprints.launchpad.net/neutron/+spec/push-notifications
[6] https://review.openstack.org/#/c/333993/
[7] https://etherpad.openstack.org/p/neutron-ptg-pike-final
[8] http://lists.openstack.org/pipermail/openstack-dev/2017-February/113032.html

-- 
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

Re: [openstack-dev] [networking-sfc] Stable/Ocata Version

[Henry Fourie]

Gary,
   The plan is to have a stable/ocata branch by end of month.

-Louis

From: Gary Kotton [mailto:gkot...@vmware.com]
Sent: Sunday, February 19, 2017 4:29 AM
To: OpenStack List
Subject: [openstack-dev] [networking-sfc] Stable/Ocata Version

Hi,
When will this repo have a stable/ocata branch?
Thanks
Gary
__
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

Re: [openstack-dev] [networking-sfc] Stable/Ocata Version

[Cathy Zhang]

We have been preparing for the ocata release. We are currently working on 
getting some final patches reviewed and merged.
Once those are merged, we will pull a stable/ocata branch around end of Feb or 
early March the latest.

Thanks,
Cathy

From: Gary Kotton [mailto:gkot...@vmware.com]
Sent: Sunday, February 19, 2017 4:29 AM
To: OpenStack List
Subject: [openstack-dev] [networking-sfc] Stable/Ocata Version

Hi,
When will this repo have a stable/ocata branch?
Thanks
Gary
__
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-dev] [networking-sfc] Stable/Ocata Version

[Gary Kotton]

Hi,
When will this repo have a stable/ocata branch?
Thanks
Gary
__
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

Re: [openstack-dev] [networking-sfc] What resources can and can't be reused

[Cathy Zhang]

Hi Igor,

The list of rules are correct.

Best regards,
Cathy

From: Duarte Cardoso, Igor [mailto:igor.duarte.card...@intel.com]
Sent: Monday, February 13, 2017 1:27 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [networking-sfc] What resources can and can't be 
reused

Hi Louis,

Yes, that makes sense - thanks for the feedback and the responses on my points.

Best regards,
Igor.

From: Henry Fourie [mailto:louis.fou...@huawei.com]
Sent: Monday, February 13, 2017 9:15 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [networking-sfc] What resources can and can't be 
reused

Igor,
   For #6, the requirement on source-port for a flow-classifier is only for the 
OVS driver. This is not a restriction for other backend drivers.
In the case where there is no need for a sfc proxy to re-classify traffic 
returned from the egress port of a SF,
i.e., the SF is NSH-aware and it can receive, process and return the NSH, this 
restriction does not apply.
- Louis

From: Duarte Cardoso, Igor [mailto:igor.duarte.card...@intel.com]
Sent: Monday, February 13, 2017 12:27 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [networking-sfc] What resources can and can't be 
reused

Hi Cathy,

Relax only a couple of them. For Ocata I'm looking at disabling #6 if the 
chain/graph doesn't include sfc proxies (#6 seems to only be necessary if there 
are sfc proxies [1]). For Pike it would be interesting to make port-pair-groups 
completely reusable, as long as the flow classifiers don't make the choice of 
chain ambiguous.

[1] 
http://eavesdrop.openstack.org/meetings/service_chaining/2017/service_chaining.2017-01-12-17.14.log.html

Best regards,
Igor.

From: Cathy Zhang [mailto:cathy.h.zh...@huawei.com]
Sent: Monday, February 13, 2017 7:50 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [networking-sfc] What resources can and can't be 
reused

Hi Igor,

Before we dive into evaluation of the rules you listed below, I would like to 
understand whether you are suggesting to enforce the rules or relax the  
rules/constraints you listed?
Could you clarify it?

Thanks,
Cathy

From: Duarte Cardoso, Igor [mailto:igor.duarte.card...@intel.com]
Sent: Monday, February 13, 2017 11:12 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [networking-sfc] What resources can and can't be reused

Hi networking-sfc,

As part of my work regarding SFC Encapsulation and SFC Graphs, I exercised the 
API to understand exactly what resources can be reused, to possibly relax a few 
of the constraints when a chain is encapsulated end-to-end.
I'm requesting that the leaders and cores take a look at the list below, and 
reply if you see something that doesn't look quite right (or have any other 
comment/question). Thanks!

1. Every flow-classifier must have a logical source port.
2. The flow-classifier must be unique in its (full) definition.
3. A port-chain can have multiple flow-classifiers associated with exactly the 
same definition BUT different logical source ports.
4. The port-chains can be ambiguous, i.e. match on the same classification 
criteria, if and only if there are 0 flow classifiers associated.
5. The flow classifiers can only be used once, by a single port-chain.
6. Different port-chains cannot be associated to different flow classifiers 
that specify the same classification criteria BUT different logical source 
ports (this is https://bugs.launchpad.net/networking-sfc/+bug/1638421).
7. A port-pair's ingress cannot be in use by another port-pair's ingress.
8. A port-pair's egress cannot be in use by another port-pair's egress.
9. A port-pair can be associated to another port-pair's ingress and egress 
ports BUT swapped (i1=e2, e1=i2).
10. The port-pairs become "in use" when a port-pair-group associates them, so 
they can't be reused across port-pair-groups.
11. A port-chain can include port-pair-groups already associated to other 
port-chains, as long as not the exact same sequence as another port-chain (e.g. 
pc1: [ppg1,ppg2]; pc2: [ppg1] - is fine).

Best regards,
Igor.

__
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

Re: [openstack-dev] [networking-sfc] What resources can and can't be reused

[Duarte Cardoso, Igor]

Hi Louis,

Yes, that makes sense - thanks for the feedback and the responses on my points.

Best regards,
Igor.

From: Henry Fourie [mailto:louis.fou...@huawei.com]
Sent: Monday, February 13, 2017 9:15 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [networking-sfc] What resources can and can't be 
reused

Igor,
   For #6, the requirement on source-port for a flow-classifier is only for the 
OVS driver. This is not a restriction for other backend drivers.
In the case where there is no need for a sfc proxy to re-classify traffic 
returned from the egress port of a SF,
i.e., the SF is NSH-aware and it can receive, process and return the NSH, this 
restriction does not apply.
- Louis

From: Duarte Cardoso, Igor [mailto:igor.duarte.card...@intel.com]
Sent: Monday, February 13, 2017 12:27 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [networking-sfc] What resources can and can't be 
reused

Hi Cathy,

Relax only a couple of them. For Ocata I'm looking at disabling #6 if the 
chain/graph doesn't include sfc proxies (#6 seems to only be necessary if there 
are sfc proxies [1]). For Pike it would be interesting to make port-pair-groups 
completely reusable, as long as the flow classifiers don't make the choice of 
chain ambiguous.

[1] 
http://eavesdrop.openstack.org/meetings/service_chaining/2017/service_chaining.2017-01-12-17.14.log.html

Best regards,
Igor.

From: Cathy Zhang [mailto:cathy.h.zh...@huawei.com]
Sent: Monday, February 13, 2017 7:50 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [networking-sfc] What resources can and can't be 
reused

Hi Igor,

Before we dive into evaluation of the rules you listed below, I would like to 
understand whether you are suggesting to enforce the rules or relax the  
rules/constraints you listed?
Could you clarify it?

Thanks,
Cathy

From: Duarte Cardoso, Igor [mailto:igor.duarte.card...@intel.com]
Sent: Monday, February 13, 2017 11:12 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [networking-sfc] What resources can and can't be reused

Hi networking-sfc,

As part of my work regarding SFC Encapsulation and SFC Graphs, I exercised the 
API to understand exactly what resources can be reused, to possibly relax a few 
of the constraints when a chain is encapsulated end-to-end.
I'm requesting that the leaders and cores take a look at the list below, and 
reply if you see something that doesn't look quite right (or have any other 
comment/question). Thanks!

1. Every flow-classifier must have a logical source port.
2. The flow-classifier must be unique in its (full) definition.
3. A port-chain can have multiple flow-classifiers associated with exactly the 
same definition BUT different logical source ports.
4. The port-chains can be ambiguous, i.e. match on the same classification 
criteria, if and only if there are 0 flow classifiers associated.
5. The flow classifiers can only be used once, by a single port-chain.
6. Different port-chains cannot be associated to different flow classifiers 
that specify the same classification criteria BUT different logical source 
ports (this is https://bugs.launchpad.net/networking-sfc/+bug/1638421).
7. A port-pair's ingress cannot be in use by another port-pair's ingress.
8. A port-pair's egress cannot be in use by another port-pair's egress.
9. A port-pair can be associated to another port-pair's ingress and egress 
ports BUT swapped (i1=e2, e1=i2).
10. The port-pairs become "in use" when a port-pair-group associates them, so 
they can't be reused across port-pair-groups.
11. A port-chain can include port-pair-groups already associated to other 
port-chains, as long as not the exact same sequence as another port-chain (e.g. 
pc1: [ppg1,ppg2]; pc2: [ppg1] - is fine).

Best regards,
Igor.

__
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

Re: [openstack-dev] [networking-sfc] What resources can and can't be reused

[Henry Fourie]

Igor,
   For #6, the requirement on source-port for a flow-classifier is only for the 
OVS driver. This is not a restriction for other backend drivers.
In the case where there is no need for a sfc proxy to re-classify traffic 
returned from the egress port of a SF,
i.e., the SF is NSH-aware and it can receive, process and return the NSH, this 
restriction does not apply.
- Louis

From: Duarte Cardoso, Igor [mailto:igor.duarte.card...@intel.com]
Sent: Monday, February 13, 2017 12:27 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [networking-sfc] What resources can and can't be 
reused

Hi Cathy,

Relax only a couple of them. For Ocata I'm looking at disabling #6 if the 
chain/graph doesn't include sfc proxies (#6 seems to only be necessary if there 
are sfc proxies [1]). For Pike it would be interesting to make port-pair-groups 
completely reusable, as long as the flow classifiers don't make the choice of 
chain ambiguous.

[1] 
http://eavesdrop.openstack.org/meetings/service_chaining/2017/service_chaining.2017-01-12-17.14.log.html

Best regards,
Igor.

From: Cathy Zhang [mailto:cathy.h.zh...@huawei.com]
Sent: Monday, February 13, 2017 7:50 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [networking-sfc] What resources can and can't be 
reused

Hi Igor,

Before we dive into evaluation of the rules you listed below, I would like to 
understand whether you are suggesting to enforce the rules or relax the  
rules/constraints you listed?
Could you clarify it?

Thanks,
Cathy

From: Duarte Cardoso, Igor [mailto:igor.duarte.card...@intel.com]
Sent: Monday, February 13, 2017 11:12 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [networking-sfc] What resources can and can't be reused

Hi networking-sfc,

As part of my work regarding SFC Encapsulation and SFC Graphs, I exercised the 
API to understand exactly what resources can be reused, to possibly relax a few 
of the constraints when a chain is encapsulated end-to-end.
I'm requesting that the leaders and cores take a look at the list below, and 
reply if you see something that doesn't look quite right (or have any other 
comment/question). Thanks!

1. Every flow-classifier must have a logical source port.
2. The flow-classifier must be unique in its (full) definition.
3. A port-chain can have multiple flow-classifiers associated with exactly the 
same definition BUT different logical source ports.
4. The port-chains can be ambiguous, i.e. match on the same classification 
criteria, if and only if there are 0 flow classifiers associated.
5. The flow classifiers can only be used once, by a single port-chain.
6. Different port-chains cannot be associated to different flow classifiers 
that specify the same classification criteria BUT different logical source 
ports (this is https://bugs.launchpad.net/networking-sfc/+bug/1638421).
7. A port-pair's ingress cannot be in use by another port-pair's ingress.
8. A port-pair's egress cannot be in use by another port-pair's egress.
9. A port-pair can be associated to another port-pair's ingress and egress 
ports BUT swapped (i1=e2, e1=i2).
10. The port-pairs become "in use" when a port-pair-group associates them, so 
they can't be reused across port-pair-groups.
11. A port-chain can include port-pair-groups already associated to other 
port-chains, as long as not the exact same sequence as another port-chain (e.g. 
pc1: [ppg1,ppg2]; pc2: [ppg1] - is fine).

Best regards,
Igor.

__
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

Re: [openstack-dev] [networking-sfc] What resources can and can't be reused

[Henry Fourie]

Igor,
  See inline.

-Louis

From: Duarte Cardoso, Igor [mailto:igor.duarte.card...@intel.com]
Sent: Monday, February 13, 2017 11:12 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [networking-sfc] What resources can and can't be reused

Hi networking-sfc,

As part of my work regarding SFC Encapsulation and SFC Graphs, I exercised the 
API to understand exactly what resources can be reused, to possibly relax a few 
of the constraints when a chain is encapsulated end-to-end.
I'm requesting that the leaders and cores take a look at the list below, and 
reply if you see something that doesn't look quite right (or have any other 
comment/question). Thanks!


1.  Every flow-classifier must have a logical source port.
LF:  - this is only true for OVS drivers.

2.  The flow-classifier must be unique in its (full) definition.
LF: correct

3.  A port-chain can have multiple flow-classifiers associated with exactly 
the same definition BUT different logical source ports.
LF: correct


4.  The port-chains can be ambiguous, i.e. match on the same classification 
criteria, if and only if there are 0 flow classifiers associated.
LF: If a port-chain has no classifier, then there is no classification so no 
traffic flows through it.

5. The flow classifiers can only be used once, by a single port-chain.
LF: correct.


6.  Different port-chains cannot be associated to different flow 
classifiers that specify the same classification criteria BUT different logical 
source ports (this is https://bugs.launchpad.net/networking-sfc/+bug/1638421).
LF: correct

7. A port-pair's ingress cannot be in use by another port-pair's ingress.
LF: correct a SF port can only be the  ingress port of one port pair.

8. A port-pair's egress cannot be in use by another port-pair's egress.
LF: correct a SF port can only be the  egress port of one port pair.

9. A port-pair can be associated to another port-pair's ingress and egress 
ports BUT swapped (i1=e2, e1=i2).
LF: correct.

10. The port-pairs become "in use" when a port-pair-group associates them, so 
they can't be reused across port-pair-groups.
LF: correct, a port-pair can only be in one port-pair group.

11. A port-chain can include port-pair-groups already associated to other 
port-chains, as long as not the exact same sequence as another port-chain (e.g. 
pc1: [ppg1,ppg2]; pc2: [ppg1] - is fine).
LF: correct.

Best regards,
Igor.

__
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

Re: [openstack-dev] [networking-sfc] What resources can and can't be reused

[Duarte Cardoso, Igor]

Hi Cathy,

Relax only a couple of them. For Ocata I'm looking at disabling #6 if the 
chain/graph doesn't include sfc proxies (#6 seems to only be necessary if there 
are sfc proxies [1]). For Pike it would be interesting to make port-pair-groups 
completely reusable, as long as the flow classifiers don't make the choice of 
chain ambiguous.

[1] 
http://eavesdrop.openstack.org/meetings/service_chaining/2017/service_chaining.2017-01-12-17.14.log.html

Best regards,
Igor.

From: Cathy Zhang [mailto:cathy.h.zh...@huawei.com]
Sent: Monday, February 13, 2017 7:50 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [networking-sfc] What resources can and can't be 
reused

Hi Igor,

Before we dive into evaluation of the rules you listed below, I would like to 
understand whether you are suggesting to enforce the rules or relax the  
rules/constraints you listed?
Could you clarify it?

Thanks,
Cathy

From: Duarte Cardoso, Igor [mailto:igor.duarte.card...@intel.com]
Sent: Monday, February 13, 2017 11:12 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [networking-sfc] What resources can and can't be reused

Hi networking-sfc,

As part of my work regarding SFC Encapsulation and SFC Graphs, I exercised the 
API to understand exactly what resources can be reused, to possibly relax a few 
of the constraints when a chain is encapsulated end-to-end.
I'm requesting that the leaders and cores take a look at the list below, and 
reply if you see something that doesn't look quite right (or have any other 
comment/question). Thanks!

1. Every flow-classifier must have a logical source port.
2. The flow-classifier must be unique in its (full) definition.
3. A port-chain can have multiple flow-classifiers associated with exactly the 
same definition BUT different logical source ports.
4. The port-chains can be ambiguous, i.e. match on the same classification 
criteria, if and only if there are 0 flow classifiers associated.
5. The flow classifiers can only be used once, by a single port-chain.
6. Different port-chains cannot be associated to different flow classifiers 
that specify the same classification criteria BUT different logical source 
ports (this is https://bugs.launchpad.net/networking-sfc/+bug/1638421).
7. A port-pair's ingress cannot be in use by another port-pair's ingress.
8. A port-pair's egress cannot be in use by another port-pair's egress.
9. A port-pair can be associated to another port-pair's ingress and egress 
ports BUT swapped (i1=e2, e1=i2).
10. The port-pairs become "in use" when a port-pair-group associates them, so 
they can't be reused across port-pair-groups.
11. A port-chain can include port-pair-groups already associated to other 
port-chains, as long as not the exact same sequence as another port-chain (e.g. 
pc1: [ppg1,ppg2]; pc2: [ppg1] - is fine).

Best regards,
Igor.

__
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

Re: [openstack-dev] [networking-sfc] What resources can and can't be reused

[Cathy Zhang]

Hi Igor,

Before we dive into evaluation of the rules you listed below, I would like to 
understand whether you are suggesting to enforce the rules or relax the  
rules/constraints you listed?
Could you clarify it?

Thanks,
Cathy

From: Duarte Cardoso, Igor [mailto:igor.duarte.card...@intel.com]
Sent: Monday, February 13, 2017 11:12 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [networking-sfc] What resources can and can't be reused

Hi networking-sfc,

As part of my work regarding SFC Encapsulation and SFC Graphs, I exercised the 
API to understand exactly what resources can be reused, to possibly relax a few 
of the constraints when a chain is encapsulated end-to-end.
I'm requesting that the leaders and cores take a look at the list below, and 
reply if you see something that doesn't look quite right (or have any other 
comment/question). Thanks!

1. Every flow-classifier must have a logical source port.
2. The flow-classifier must be unique in its (full) definition.
3. A port-chain can have multiple flow-classifiers associated with exactly the 
same definition BUT different logical source ports.
4. The port-chains can be ambiguous, i.e. match on the same classification 
criteria, if and only if there are 0 flow classifiers associated.
5. The flow classifiers can only be used once, by a single port-chain.
6. Different port-chains cannot be associated to different flow classifiers 
that specify the same classification criteria BUT different logical source 
ports (this is https://bugs.launchpad.net/networking-sfc/+bug/1638421).
7. A port-pair's ingress cannot be in use by another port-pair's ingress.
8. A port-pair's egress cannot be in use by another port-pair's egress.
9. A port-pair can be associated to another port-pair's ingress and egress 
ports BUT swapped (i1=e2, e1=i2).
10. The port-pairs become "in use" when a port-pair-group associates them, so 
they can't be reused across port-pair-groups.
11. A port-chain can include port-pair-groups already associated to other 
port-chains, as long as not the exact same sequence as another port-chain (e.g. 
pc1: [ppg1,ppg2]; pc2: [ppg1] - is fine).

Best regards,
Igor.

__
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-dev] [networking-sfc] What resources can and can't be reused

[Duarte Cardoso, Igor]

Hi networking-sfc,

As part of my work regarding SFC Encapsulation and SFC Graphs, I exercised the 
API to understand exactly what resources can be reused, to possibly relax a few 
of the constraints when a chain is encapsulated end-to-end.
I'm requesting that the leaders and cores take a look at the list below, and 
reply if you see something that doesn't look quite right (or have any other 
comment/question). Thanks!

1. Every flow-classifier must have a logical source port.
2. The flow-classifier must be unique in its (full) definition.
3. A port-chain can have multiple flow-classifiers associated with exactly the 
same definition BUT different logical source ports.
4. The port-chains can be ambiguous, i.e. match on the same classification 
criteria, if and only if there are 0 flow classifiers associated.
5. The flow classifiers can only be used once, by a single port-chain.
6. Different port-chains cannot be associated to different flow classifiers 
that specify the same classification criteria BUT different logical source 
ports (this is https://bugs.launchpad.net/networking-sfc/+bug/1638421).
7. A port-pair's ingress cannot be in use by another port-pair's ingress.
8. A port-pair's egress cannot be in use by another port-pair's egress.
9. A port-pair can be associated to another port-pair's ingress and egress 
ports BUT swapped (i1=e2, e1=i2).
10. The port-pairs become "in use" when a port-pair-group associates them, so 
they can't be reused across port-pair-groups.
11. A port-chain can include port-pair-groups already associated to other 
port-chains, as long as not the exact same sequence as another port-chain (e.g. 
pc1: [ppg1,ppg2]; pc2: [ppg1] - is fine).

Best regards,
Igor.

__
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

Re: [openstack-dev] [networking-sfc]

[Sridhar Ramaswamy]

Networking-sfc features are available to orchestrate using a TOSCA
template through Tacker. The feature is called VNF Forwarding Graph
(VNFFG) and it is available both through tacker cli and horizon
screens.

See tacker docs here for more details,

http://docs.openstack.org/developer/tacker/devref/vnffg_usage_guide.html
http://docs.openstack.org/developer/tacker/devref/vnffgd_template_description.html

On a different note, the last I tried, I also used that setting to get
sfc working on Ubuntu 16.04 devstack,

# Enable networking-sfc
SFC_UPDATE_OVS=False
enable_plugin networking-sfc https://git.openstack.org/openstack/networking-sfc



On Tue, Jan 24, 2017 at 5:30 AM, Bernard Cafarelli  wrote:
> On 20 January 2017 at 00:06, Michael Gale  wrote:
>> Hello,
>>
>> Are there updated install docs for sfc? The only install steps for a
>> testbed I can find are here and they seem outdated:
>> https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining
> There is also a SFC chapter in the networking guide:
> http://docs.openstack.org/newton/networking-guide/config-sfc.html
>
> Which parts do you find outdated? Some references to Ubuntu/OVS
> versions may need a cleanup, but the design and API parts should still
> be OK
> (OSC client, SFC graph API, symmetric ports and other goodies are
> still under review and not yed merged)
>
>> Also from the conference videos there seems to be some Horizon menu /
>> screens that are available?
> Not for networking-sfc directly, but there is a SFC tab in the tacker
> horizon plugin (or will be, someone from the tacker team can confirm
> that)
>
>
> --
> 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

Re: [openstack-dev] [networking-sfc]

[Henry Fourie]

Michael,
  Regarding horizon support for networking-sfc, the screens shown
on the demo were developed in an earlier patch that was not merged.
https://review.openstack.org/#/c/258430/

This work is still in progress.
 - Louis

-Original Message-
From: Bernard Cafarelli [mailto:bcafa...@redhat.com] 
Sent: Tuesday, January 24, 2017 5:31 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [networking-sfc]

On 20 January 2017 at 00:06, Michael Gale <gale.mich...@gmail.com> wrote:
> Hello,
>
> Are there updated install docs for sfc? The only install steps for 
> a testbed I can find are here and they seem outdated:
> https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining
There is also a SFC chapter in the networking guide:
http://docs.openstack.org/newton/networking-guide/config-sfc.html

Which parts do you find outdated? Some references to Ubuntu/OVS versions may 
need a cleanup, but the design and API parts should still be OK (OSC client, 
SFC graph API, symmetric ports and other goodies are still under review and not 
yed merged)

> Also from the conference videos there seems to be some Horizon menu / 
> screens that are available?
Not for networking-sfc directly, but there is a SFC tab in the tacker horizon 
plugin (or will be, someone from the tacker team can confirm
that)


--
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

Re: [openstack-dev] [networking-sfc]

[Bernard Cafarelli]

Hi Michael,
On 25 January 2017 at 06:50, Michael Gale  wrote:
> My biggest hurdle was around getting the devstack environment functioning, I
> was following the steps here:
> https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining
>
> I think the issues are related to using Ubuntu 16.04 instead of Ubuntu 14.04
> and devstack now recommends 16.04. So the OVS steps seem out of place and in
> my local.conf file I needed to set:
> --snip--
> export SFC_UPDATE_OVS=False
[...]
> This could be related to my lack of experience with Devstack, also I was
> concerned with having to set SFC_UPDATE_OVS=False in the configuration. Is
> this affecting the underlying functionality of SFC.
Ah, yes you did the right thing here, with newer distributions you do
not need this, as the available OVS version is enough to run SFC (and
in fact on 16.04 compilation would fail as you experienced).
In fact this was removed on master and backported to stable/newton branch:
https://git.openstack.org/cgit/openstack/networking-sfc/commit/?h=stable/newton=9256feca05db53bcfa656441b63d555874d3cf68

> Also the link to the Horizon add-on would be great.
>
> Thanks
> Michael
>
>
> On Tue, Jan 24, 2017 at 6:30 AM, Bernard Cafarelli 
> wrote:
>>
>> On 20 January 2017 at 00:06, Michael Gale  wrote:
>> > Hello,
>> >
>> > Are there updated install docs for sfc? The only install steps for a
>> > testbed I can find are here and they seem outdated:
>> > https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining
>> There is also a SFC chapter in the networking guide:
>> http://docs.openstack.org/newton/networking-guide/config-sfc.html
>>
>> Which parts do you find outdated? Some references to Ubuntu/OVS
>> versions may need a cleanup, but the design and API parts should still
>> be OK
>> (OSC client, SFC graph API, symmetric ports and other goodies are
>> still under review and not yed merged)
>>
>> > Also from the conference videos there seems to be some Horizon menu /
>> > screens that are available?
>> Not for networking-sfc directly, but there is a SFC tab in the tacker
>> horizon plugin (or will be, someone from the tacker team can confirm
>> that)


-- 
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

Re: [openstack-dev] [networking-sfc]

[Michael Gale]

Hello Bernard,
I believe the design docs and API parts are good and once I had the
environment up and running I didn't have any problems following the
examples or running the commands.

My biggest hurdle was around getting the devstack environment functioning,
I was following the steps here:
https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining

I think the issues are related to using Ubuntu 16.04 instead of Ubuntu
14.04 and devstack now recommends 16.04. So the OVS steps seem out of place
and in my local.conf file I needed to set:
--snip--
export SFC_UPDATE_OVS=False
# Disable security groups
Q_USE_SECGROUP=False
LIBVIRT_FIREWALL_DRIVER=nova.virt.firewall.NoopFirewallDriver
enable_plugin networking-sfc git://
git.openstack.org/openstack/networking-sfc stable/newton
--snip--

This could be related to my lack of experience with Devstack, also I was
concerned with having to set SFC_UPDATE_OVS=False in the configuration. Is
this affecting the underlying functionality of SFC.

Also the link to the Horizon add-on would be great.

Thanks
Michael


On Tue, Jan 24, 2017 at 6:30 AM, Bernard Cafarelli 
wrote:

> On 20 January 2017 at 00:06, Michael Gale  wrote:
> > Hello,
> >
> > Are there updated install docs for sfc? The only install steps for a
> > testbed I can find are here and they seem outdated:
> > https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining
> There is also a SFC chapter in the networking guide:
> http://docs.openstack.org/newton/networking-guide/config-sfc.html
>
> Which parts do you find outdated? Some references to Ubuntu/OVS
> versions may need a cleanup, but the design and API parts should still
> be OK
> (OSC client, SFC graph API, symmetric ports and other goodies are
> still under review and not yed merged)
>
> > Also from the conference videos there seems to be some Horizon menu /
> > screens that are available?
> Not for networking-sfc directly, but there is a SFC tab in the tacker
> horizon plugin (or will be, someone from the tacker team can confirm
> that)
>
>
> --
> 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
>



-- 

“The Man who says he can, and the man who says he can not.. Are both
correct”
__
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

Re: [openstack-dev] [networking-sfc]

[Henry Fourie]

Cathy,
   I believe Mohan Kumar did that work.
 - Louis

-Original Message-
From: Cathy Zhang 
Sent: Tuesday, January 24, 2017 5:39 PM
To: OpenStack Development Mailing List (not for usage questions); Henry Fourie; 
Vikram Choudhary
Cc: Cathy Zhang
Subject: RE: [openstack-dev] [networking-sfc]

There is a SFC Horizon code patch available. And our presentation video GUI is 
based on that. 

Louis/Vikram,

I am on business trip and have difficulty to access some openstack links. Could 
you share the link to our SFC Horizon work?

Thanks,
Cathy

-Original Message-
From: Bernard Cafarelli [mailto:bcafa...@redhat.com]
Sent: Tuesday, January 24, 2017 9:31 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [networking-sfc]

On 20 January 2017 at 00:06, Michael Gale <gale.mich...@gmail.com> wrote:
> Hello,
>
> Are there updated install docs for sfc? The only install steps for 
> a testbed I can find are here and they seem outdated:
> https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining
There is also a SFC chapter in the networking guide:
http://docs.openstack.org/newton/networking-guide/config-sfc.html

Which parts do you find outdated? Some references to Ubuntu/OVS versions may 
need a cleanup, but the design and API parts should still be OK (OSC client, 
SFC graph API, symmetric ports and other goodies are still under review and not 
yed merged)

> Also from the conference videos there seems to be some Horizon menu / 
> screens that are available?
Not for networking-sfc directly, but there is a SFC tab in the tacker horizon 
plugin (or will be, someone from the tacker team can confirm
that)


--
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

Re: [openstack-dev] [networking-sfc]

[Cathy Zhang]

There is a SFC Horizon code patch available. And our presentation video GUI is 
based on that. 

Louis/Vikram,

I am on business trip and have difficulty to access some openstack links. Could 
you share the link to our SFC Horizon work?

Thanks,
Cathy

-Original Message-
From: Bernard Cafarelli [mailto:bcafa...@redhat.com] 
Sent: Tuesday, January 24, 2017 9:31 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [networking-sfc]

On 20 January 2017 at 00:06, Michael Gale <gale.mich...@gmail.com> wrote:
> Hello,
>
> Are there updated install docs for sfc? The only install steps for 
> a testbed I can find are here and they seem outdated:
> https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining
There is also a SFC chapter in the networking guide:
http://docs.openstack.org/newton/networking-guide/config-sfc.html

Which parts do you find outdated? Some references to Ubuntu/OVS versions may 
need a cleanup, but the design and API parts should still be OK (OSC client, 
SFC graph API, symmetric ports and other goodies are still under review and not 
yed merged)

> Also from the conference videos there seems to be some Horizon menu / 
> screens that are available?
Not for networking-sfc directly, but there is a SFC tab in the tacker horizon 
plugin (or will be, someone from the tacker team can confirm
that)


--
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

Re: [openstack-dev] [networking-sfc]

[Bernard Cafarelli]

On 20 January 2017 at 00:06, Michael Gale  wrote:
> Hello,
>
> Are there updated install docs for sfc? The only install steps for a
> testbed I can find are here and they seem outdated:
> https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining
There is also a SFC chapter in the networking guide:
http://docs.openstack.org/newton/networking-guide/config-sfc.html

Which parts do you find outdated? Some references to Ubuntu/OVS
versions may need a cleanup, but the design and API parts should still
be OK
(OSC client, SFC graph API, symmetric ports and other goodies are
still under review and not yed merged)

> Also from the conference videos there seems to be some Horizon menu /
> screens that are available?
Not for networking-sfc directly, but there is a SFC tab in the tacker
horizon plugin (or will be, someone from the tacker team can confirm
that)


-- 
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

Re: [openstack-dev] [networking-sfc] Does SFC support chaining of Layer 2 devices?

[Vikash Kumar]

Louis,

   Typical L2 IDS devices mostly work in transparent/TAP mode which means
traffic is diverted to these devices without manipulating any packet
header. Interfaces/Ports of these devices are in promiscuous mode. Based on
the filtering rules , these devices take action on packets, most commonly
drop if found malicious otherwise sent out through outgoing interface.





On Sat, Jan 21, 2017 at 12:04 AM, Henry Fourie <louis.fou...@huawei.com>
wrote:

> Vikash,
>
>Unclear what you mean by SFC spinning an L2 IDS?
>
> What is the behavior of L2 IDS devices?
>
> -Louis
>
>
>
> *From:* Vikash Kumar [mailto:vikash.ku...@oneconvergence.com]
> *Sent:* Wednesday, January 18, 2017 10:49 PM
> *To:* openstack-dev
> *Subject:* [openstack-dev] [networking-sfc] Does SFC support chaining of
> Layer 2 devices?
>
>
>
> All,
>
>I am exploring SFC for chaining an IDS device (strictly in L2 mode). As
> of now, it looks SFC default supports only L3 devices. SFC APIs doesn't
> have any way to specify the nature of device and without that, it seems
> there is no way an operator can spin any device/VNF except L3 mode VNFs. Is
> anything I am missing here ? Can one still spin a L2 IDS with SFC ?
>
>
>
> --
>
> Regards,
>
> Vikash
>
> __
> 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
>
>


-- 
Regards,
Vikash
__
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

Re: [openstack-dev] [networking-sfc] Does SFC support chaining of Layer 2 devices?

[Henry Fourie]

Vikash,
   Unclear what you mean by SFC spinning an L2 IDS?
What is the behavior of L2 IDS devices?

-Louis

From: Vikash Kumar [mailto:vikash.ku...@oneconvergence.com]
Sent: Wednesday, January 18, 2017 10:49 PM
To: openstack-dev
Subject: [openstack-dev] [networking-sfc] Does SFC support chaining of Layer 2 
devices?

All,
   I am exploring SFC for chaining an IDS device (strictly in L2 mode). As of 
now, it looks SFC default supports only L3 devices. SFC APIs doesn't have any 
way to specify the nature of device and without that, it seems there is no way 
an operator can spin any device/VNF except L3 mode VNFs. Is anything I am 
missing here ? Can one still spin a L2 IDS with SFC ?


--
Regards,
Vikash
__
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

Re: [openstack-dev] [networking-sfc] Does SFC support chaining of Layer 2 devices?

[Vikash Kumar]

On Thu, Jan 19, 2017 at 12:18 PM, Vikash Kumar <
vikash.ku...@oneconvergence.com> wrote:

> All,
>
>I am exploring SFC for chaining an IDS device (strictly in L2 mode). As
> of now, it looks SFC default supports only L3 devices. SFC APIs doesn't
> have any way to specify the nature of device and without that, it seems
> there is no way an operator can spin any device/VNF except L3 mode VNFs. Is
> anything I am missing here ? Can one still spin a L2 IDS with SFC ?
>
>
> --
> Regards,
> Vikash
>



-- 
Regards,
Vikash
__
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-dev] [networking-sfc]

[Michael Gale]

Hello,

Are there updated install docs for sfc? The only install steps for a
testbed I can find are here and they seem outdated:
https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining

Also from the conference videos there seems to be some Horizon menu /
screens that are available?

Michael
__
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-dev] [networking-sfc] Does SFC support chaining of Layer 2 devices?

[Vikash Kumar]

All,

   I am exploring SFC for chaining an IDS device (strictly in L2 mode). As
of now, it looks SFC default supports only L3 devices. SFC APIs doesn't
have any way to specify the nature of device and without that, it seems
there is no way an operator can spin any device/VNF except L3 mode VNFs. Is
anything I am missing here ? Can one still spin a L2 IDS with SFC ?


-- 
Regards,
Vikash
__
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

Re: [openstack-dev] [networking-sfc] Limitation on port chains + flow classifiers

[Cathy Zhang]

This clash check was added on purpose to avoid the ambiguity of the following 
scenario (This is just one of many similar scenarios):

VM2, VM3 hosted on Int-Bridge1 of Server1
VM4 hosted on Int-Bridge2 of Server2
VM5 hosted on Int-Bridge3 of Server3

Chain1: VM1, VM2, VM4
Chain2: VM1, VM3, VM5

Suppose FC1 for Chain1 and FC2 for Chain2 are the same except logical source 
port(Igor's testing scenario). 
If we allow this, then when the Int-Bridge1 on Server1 receives the packet from 
VM2 or VM3, it can not distinguish 
which chain the packet is associated with and thus don't know whether to 
forward the packet to VM4 or VM5  
since the packet's n-tuple classification is the same (logical source port is 
not carried in the packet). 

If the SF2 on VM2 and the SF3 on VM3 are chain-ID aware (eg. Supports NSH), 
then the ambiguity can be resolved and we can remove this check. 
Another alternative is to support a chain-ID-correlation mechanism between the 
SF and the vSwitch. 

Thanks,
Cathy

 

-Original Message-
From: Bernard Cafarelli [mailto:bcafa...@redhat.com] 
Sent: Thursday, January 12, 2017 7:44 AM
To: OpenStack Development Mailing List (not for usage questions)
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

Re: [openstack-dev] [networking-sfc] Limitation on port chains + flow classifiers

[Duarte Cardoso, Igor]

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

Re: [openstack-dev] [networking-sfc] Limitation on port chains + flow classifiers

[Bernard Cafarelli]

On 10 January 2017 at 14:13, Duarte Cardoso, Igor
 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

__
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-dev] [networking-sfc] Limitation on port chains + flow classifiers

[Duarte Cardoso, Igor]

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

Best regards,
Igor.

__
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

Re: [openstack-dev] [networking-sfc] Intermittent database transaction issues, affecting the tempest gate

[Bernard Cafarelli]

After some research, this review fixes the tempest failures:
https://review.openstack.org/#/c/416503/1 (newer patchset has an
unrelated fix for the functional tests gate)

Multiple local tempest runs and gate rechecks all turned green with
this fix. That is the good news part.

The bad news is that I am still not sure on the root cause. The code
that triggers the problems is:
https://github.com/openstack/networking-sfc/blob/f5b52d5304796e44431b3874117aa0be91ed13d8/networking_sfc/services/sfc/drivers/ovs/db.py#L292
_get_port_detail() is just a wrapper on CommonDbMixin._get_by_id()
from neutron, so is it triggered by two _model_query() calls in a row?

Hoping someone can shed a light here, next time it may not be as an
easy fix as removing an unused line


On 22 December 2016 at 20:48, Mike Bayer <mba...@redhat.com> wrote:
>
> On 12/20/2016 06:50 PM, Cathy Zhang wrote:
>>
>> Hi Bernard,
>>
>> Thanks for the email. I will take a look at this. Xiaodong has been
>> working on tempest test scripts.
>> I will work with Xiaodong on this issue.
>
>
> I've added a comment to the issue which refers to upstream SQLAlchemy issue
> https://bitbucket.org/zzzeek/sqlalchemy/issues/3803 as a potential
> contributor, though looking at the logs linked from the issue it appears
> that database deadlocks are also occurring which may also be a precursor
> here.   There are many improvements in SQLAlchemy 1.1 such that the
> "rollback()" state should not be as susceptible to a corrupted database
> connection as seems to be the case here.
>
>
>
>
>
>>
>> Cathy
>>
>>
>> -Original Message-
>> From: Bernard Cafarelli [mailto:bcafa...@redhat.com]
>> Sent: Tuesday, December 20, 2016 3:00 AM
>> To: OpenStack Development Mailing List
>> Subject: [openstack-dev] [networking-sfc] Intermittent database
>> transaction issues, affecting the tempest gate
>>
>> Hi everyone,
>>
>> we have an open bug (thanks Igor for the report) on DB transaction issues:
>> https://bugs.launchpad.net/networking-sfc/+bug/1630503
>>
>> The thing is, I am seeing  quite a few tempest gate failures that follow
>> the same pattern: at some point in the test suite, the service gets
>> warnings/errors from the DB layer (reentrant call, closed transaction,
>> nested rollback, …), and all following tests fail.
>>
>> This affects both master and stable/newton branches (not many changes for
>> now in the DB parts between these branches)
>>
>> Some examples:
>> * https://review.openstack.org/#/c/400396/ failed with console log
>>
>> http://logs.openstack.org/96/400396/2/check/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/c27920b/console.html#_2016-12-16_12_44_47_564544
>> and service log
>>
>> http://logs.openstack.org/96/400396/2/check/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/c27920b/logs/screen-q-svc.txt.gz?level=WARNING#_2016-12-16_12_44_32_301
>> * https://review.openstack.org/#/c/405391/ failed,
>>
>> http://logs.openstack.org/91/405391/2/check/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/7e2b1de/console.html.gz#_2016-12-16_13_05_17_384323
>> and
>> http://logs.openstack.org/91/405391/2/check/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/7e2b1de/logs/screen-q-svc.txt.gz?level=WARNING#_2016-12-16_13_04_11_840
>> * another on master branch: https://review.openstack.org/#/c/411194/
>> with
>> http://logs.openstack.org/94/411194/1/gate/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/90633de/console.html.gz#_2016-12-15_22_36_15_216260
>> and
>> http://logs.openstack.org/94/411194/1/gate/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/90633de/logs/screen-q-svc.txt.gz?level=WARNING#_2016-12-15_22_35_53_310
>>
>> I took a look at the errors, but only found old-and-apparently-fixed
>> pymysql bugs, and suggestions like:
>> *
>> http://docs.sqlalchemy.org/en/latest/faq/sessions.html#this-session-s-transaction-has-been-rolled-back-due-to-a-previous-exception-during-flush-or-similar
>> *  https://review.openstack.org/#/c/230481/
>> Not really my forte, so if someone could take a look at these logs and fix
>> the problem, it would be great! Especially with the upcoming multinode
>> tempest gate
>>
>> Thanks,
>> --
>> 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
>> __
>> OpenStac

Re: [openstack-dev] [networking-sfc] Intermittent database transaction issues, affecting the tempest gate

[Mike Bayer]

On 12/20/2016 06:50 PM, Cathy Zhang wrote:

Hi Bernard,

Thanks for the email. I will take a look at this. Xiaodong has been working on 
tempest test scripts.
I will work with Xiaodong on this issue.


I've added a comment to the issue which refers to upstream SQLAlchemy 
issue https://bitbucket.org/zzzeek/sqlalchemy/issues/3803 as a potential 
contributor, though looking at the logs linked from the issue it appears 
that database deadlocks are also occurring which may also be a precursor 
here.   There are many improvements in SQLAlchemy 1.1 such that the 
"rollback()" state should not be as susceptible to a corrupted database 
connection as seems to be the case here.







Cathy


-Original Message-
From: Bernard Cafarelli [mailto:bcafa...@redhat.com]
Sent: Tuesday, December 20, 2016 3:00 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [networking-sfc] Intermittent database transaction 
issues, affecting the tempest gate

Hi everyone,

we have an open bug (thanks Igor for the report) on DB transaction issues:
https://bugs.launchpad.net/networking-sfc/+bug/1630503

The thing is, I am seeing  quite a few tempest gate failures that follow the 
same pattern: at some point in the test suite, the service gets warnings/errors 
from the DB layer (reentrant call, closed transaction, nested rollback, …), and 
all following tests fail.

This affects both master and stable/newton branches (not many changes for now 
in the DB parts between these branches)

Some examples:
* https://review.openstack.org/#/c/400396/ failed with console log
http://logs.openstack.org/96/400396/2/check/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/c27920b/console.html#_2016-12-16_12_44_47_564544
and service log
http://logs.openstack.org/96/400396/2/check/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/c27920b/logs/screen-q-svc.txt.gz?level=WARNING#_2016-12-16_12_44_32_301
* https://review.openstack.org/#/c/405391/ failed,
http://logs.openstack.org/91/405391/2/check/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/7e2b1de/console.html.gz#_2016-12-16_13_05_17_384323
and 
http://logs.openstack.org/91/405391/2/check/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/7e2b1de/logs/screen-q-svc.txt.gz?level=WARNING#_2016-12-16_13_04_11_840
* another on master branch: https://review.openstack.org/#/c/411194/
with 
http://logs.openstack.org/94/411194/1/gate/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/90633de/console.html.gz#_2016-12-15_22_36_15_216260
and 
http://logs.openstack.org/94/411194/1/gate/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/90633de/logs/screen-q-svc.txt.gz?level=WARNING#_2016-12-15_22_35_53_310

I took a look at the errors, but only found old-and-apparently-fixed pymysql 
bugs, and suggestions like:
* 
http://docs.sqlalchemy.org/en/latest/faq/sessions.html#this-session-s-transaction-has-been-rolled-back-due-to-a-previous-exception-during-flush-or-similar
*  https://review.openstack.org/#/c/230481/
Not really my forte, so if someone could take a look at these logs and fix the 
problem, it would be great! Especially with the upcoming multinode tempest gate

Thanks,
--
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



__
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

Re: [openstack-dev] [networking-sfc] Intermittent database transaction issues, affecting the tempest gate

[Cathy Zhang]

Hi Bernard,

Thanks for the email. I will take a look at this. Xiaodong has been working on 
tempest test scripts. 
I will work with Xiaodong on this issue. 

Cathy


-Original Message-
From: Bernard Cafarelli [mailto:bcafa...@redhat.com] 
Sent: Tuesday, December 20, 2016 3:00 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [networking-sfc] Intermittent database transaction 
issues, affecting the tempest gate

Hi everyone,

we have an open bug (thanks Igor for the report) on DB transaction issues:
https://bugs.launchpad.net/networking-sfc/+bug/1630503

The thing is, I am seeing  quite a few tempest gate failures that follow the 
same pattern: at some point in the test suite, the service gets warnings/errors 
from the DB layer (reentrant call, closed transaction, nested rollback, …), and 
all following tests fail.

This affects both master and stable/newton branches (not many changes for now 
in the DB parts between these branches)

Some examples:
* https://review.openstack.org/#/c/400396/ failed with console log
http://logs.openstack.org/96/400396/2/check/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/c27920b/console.html#_2016-12-16_12_44_47_564544
and service log
http://logs.openstack.org/96/400396/2/check/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/c27920b/logs/screen-q-svc.txt.gz?level=WARNING#_2016-12-16_12_44_32_301
* https://review.openstack.org/#/c/405391/ failed,
http://logs.openstack.org/91/405391/2/check/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/7e2b1de/console.html.gz#_2016-12-16_13_05_17_384323
and 
http://logs.openstack.org/91/405391/2/check/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/7e2b1de/logs/screen-q-svc.txt.gz?level=WARNING#_2016-12-16_13_04_11_840
* another on master branch: https://review.openstack.org/#/c/411194/
with 
http://logs.openstack.org/94/411194/1/gate/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/90633de/console.html.gz#_2016-12-15_22_36_15_216260
and 
http://logs.openstack.org/94/411194/1/gate/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/90633de/logs/screen-q-svc.txt.gz?level=WARNING#_2016-12-15_22_35_53_310

I took a look at the errors, but only found old-and-apparently-fixed pymysql 
bugs, and suggestions like:
* 
http://docs.sqlalchemy.org/en/latest/faq/sessions.html#this-session-s-transaction-has-been-rolled-back-due-to-a-previous-exception-during-flush-or-similar
*  https://review.openstack.org/#/c/230481/
Not really my forte, so if someone could take a look at these logs and fix the 
problem, it would be great! Especially with the upcoming multinode tempest gate

Thanks,
--
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

[openstack-dev] [networking-sfc] Intermittent database transaction issues, affecting the tempest gate

[Bernard Cafarelli]

Hi everyone,

we have an open bug (thanks Igor for the report) on DB transaction issues:
https://bugs.launchpad.net/networking-sfc/+bug/1630503

The thing is, I am seeing  quite a few tempest gate failures that
follow the same pattern: at some point in the test suite, the service
gets warnings/errors from the DB layer (reentrant call, closed
transaction, nested rollback, …), and all following tests fail.

This affects both master and stable/newton branches (not many changes
for now in the DB parts between these branches)

Some examples:
* https://review.openstack.org/#/c/400396/ failed with console log
http://logs.openstack.org/96/400396/2/check/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/c27920b/console.html#_2016-12-16_12_44_47_564544
and service log
http://logs.openstack.org/96/400396/2/check/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/c27920b/logs/screen-q-svc.txt.gz?level=WARNING#_2016-12-16_12_44_32_301
* https://review.openstack.org/#/c/405391/ failed,
http://logs.openstack.org/91/405391/2/check/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/7e2b1de/console.html.gz#_2016-12-16_13_05_17_384323
and 
http://logs.openstack.org/91/405391/2/check/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/7e2b1de/logs/screen-q-svc.txt.gz?level=WARNING#_2016-12-16_13_04_11_840
* another on master branch: https://review.openstack.org/#/c/411194/
with 
http://logs.openstack.org/94/411194/1/gate/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/90633de/console.html.gz#_2016-12-15_22_36_15_216260
and 
http://logs.openstack.org/94/411194/1/gate/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/90633de/logs/screen-q-svc.txt.gz?level=WARNING#_2016-12-15_22_35_53_310

I took a look at the errors, but only found old-and-apparently-fixed
pymysql bugs, and suggestions like:
* 
http://docs.sqlalchemy.org/en/latest/faq/sessions.html#this-session-s-transaction-has-been-rolled-back-due-to-a-previous-exception-during-flush-or-similar
*  https://review.openstack.org/#/c/230481/
Not really my forte, so if someone could take a look at these logs and
fix the problem, it would be great! Especially with the upcoming
multinode tempest gate

Thanks,
-- 
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

Re: [openstack-dev] [networking-sfc] #networking-sfc IRC channel

[Cathy Zhang]

Hi Igor,

Good idea. I will get this #networking-sfc channel registered. 

Thanks,
Cathy

-Original Message-
From: Ravi Sekhar Reddy Konda [mailto:ravisekhar.ko...@oracle.com] 
Sent: Wednesday, November 23, 2016 7:37 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [networking-sfc] #networking-sfc IRC channel

+1


Thanks,
Ravi Sekhar
- Original Message -
From: bcafa...@redhat.com
To: openstack-dev@lists.openstack.org
Sent: Wednesday, November 23, 2016 7:18:53 PM GMT +05:30 Chennai, Kolkata, 
Mumbai, New Delhi
Subject: Re: [openstack-dev] [networking-sfc] #networking-sfc IRC channel

+1, a specific channel would be nice!

On 23 November 2016 at 13:09, Mohan Kumar <nmohankumar1...@gmail.com> wrote:
> Yes , It will be good
>
> Thanks.,
> Mohankumar.N
>
> On Wed, Nov 23, 2016 at 4:56 PM, Duarte Cardoso, Igor 
> <igor.duarte.card...@intel.com> wrote:
>>
>> Hi networking-sfc’s leaders, devs and users,
>>
>>
>>
>> What do you think about having an IRC channel dedicated to 
>> networking-sfc’s discussions and sync?
>>
>>
>>
>> For the time being  I have joined #networking-sfc @ freenode, and 
>> will stay online to keep it open.
>>
>>
>>
>> Best regards,
>>
>> Igor.
>>
>>
>>
>>
>> _
>> _ 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
>



--
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
__
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

Re: [openstack-dev] [networking-sfc] #networking-sfc IRC channel

[Henry Fourie]

Igor
+1

-Louis

From: Duarte Cardoso, Igor [mailto:igor.duarte.card...@intel.com]
Sent: Wednesday, November 23, 2016 3:26 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [networking-sfc] #networking-sfc IRC channel

Hi networking-sfc's leaders, devs and users,

What do you think about having an IRC channel dedicated to networking-sfc's 
discussions and sync?

For the time being  I have joined #networking-sfc @ freenode, and will stay 
online to keep it open.

Best regards,
Igor.

__
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

Re: [openstack-dev] [networking-sfc] #networking-sfc IRC channel

[Ravi Sekhar Reddy Konda]

+1


Thanks,
Ravi Sekhar
- Original Message -
From: bcafa...@redhat.com
To: openstack-dev@lists.openstack.org
Sent: Wednesday, November 23, 2016 7:18:53 PM GMT +05:30 Chennai, Kolkata, 
Mumbai, New Delhi
Subject: Re: [openstack-dev] [networking-sfc] #networking-sfc IRC channel

+1, a specific channel would be nice!

On 23 November 2016 at 13:09, Mohan Kumar <nmohankumar1...@gmail.com> wrote:
> Yes , It will be good
>
> Thanks.,
> Mohankumar.N
>
> On Wed, Nov 23, 2016 at 4:56 PM, Duarte Cardoso, Igor
> <igor.duarte.card...@intel.com> wrote:
>>
>> Hi networking-sfc’s leaders, devs and users,
>>
>>
>>
>> What do you think about having an IRC channel dedicated to
>> networking-sfc’s discussions and sync?
>>
>>
>>
>> For the time being  I have joined #networking-sfc @ freenode, and will
>> stay online to keep it open.
>>
>>
>>
>> Best regards,
>>
>> Igor.
>>
>>
>>
>>
>> __
>> 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
>



-- 
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

Re: [openstack-dev] [networking-sfc] #networking-sfc IRC channel

[Bernard Cafarelli]

+1, a specific channel would be nice!

On 23 November 2016 at 13:09, Mohan Kumar  wrote:
> Yes , It will be good
>
> Thanks.,
> Mohankumar.N
>
> On Wed, Nov 23, 2016 at 4:56 PM, Duarte Cardoso, Igor
>  wrote:
>>
>> Hi networking-sfc’s leaders, devs and users,
>>
>>
>>
>> What do you think about having an IRC channel dedicated to
>> networking-sfc’s discussions and sync?
>>
>>
>>
>> For the time being  I have joined #networking-sfc @ freenode, and will
>> stay online to keep it open.
>>
>>
>>
>> Best regards,
>>
>> Igor.
>>
>>
>>
>>
>> __
>> 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
>



-- 
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

Re: [openstack-dev] [networking-sfc] #networking-sfc IRC channel

[Mohan Kumar]

Yes , It will be good

Thanks.,
Mohankumar.N

On Wed, Nov 23, 2016 at 4:56 PM, Duarte Cardoso, Igor <
igor.duarte.card...@intel.com> wrote:

> Hi networking-sfc’s leaders, devs and users,
>
>
>
> What do you think about having an IRC channel dedicated to
> networking-sfc’s discussions and sync?
>
>
>
> For the time being  I have joined #networking-sfc @ freenode, and will
> stay online to keep it open.
>
>
>
> Best regards,
>
> Igor.
>
>
>
> __
> 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

Re: [openstack-dev] [networking-sfc] #networking-sfc IRC channel

[Vikram Choudhary]

+1 for networking-sfc!

From: Duarte Cardoso, Igor [mailto:igor.duarte.card...@intel.com]
Sent: 23 November 2016 16:56
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [networking-sfc] #networking-sfc IRC channel

Hi networking-sfc's leaders, devs and users,

What do you think about having an IRC channel dedicated to networking-sfc's 
discussions and sync?

For the time being  I have joined #networking-sfc @ freenode, and will stay 
online to keep it open.

Best regards,
Igor.

__
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-dev] [networking-sfc] #networking-sfc IRC channel

[Duarte Cardoso, Igor]

Hi networking-sfc's leaders, devs and users,

What do you think about having an IRC channel dedicated to networking-sfc's 
discussions and sync?

For the time being  I have joined #networking-sfc @ freenode, and will stay 
online to keep it open.

Best regards,
Igor.

__
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

Re: [openstack-dev] [networking-sfc][devstack][mitaka] Chain doesn't work

[Cathy Zhang]

Hi Alioune,

SFC is working fine. Your problem is with configuration of your specific 
Service Function.
AFAIK, Farhad has responded to your question before.
https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg95199.html

Thanks,
Cathy

From: Alioune [mailto:baliou...@gmail.com]
Sent: Wednesday, November 02, 2016 5:40 AM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Cathy Zhang; Mohan Kumar
Subject: Re: [networking-sfc][devstack][mitaka] Chain doesn't work

Any suggestion ?

On Monday, 24 October 2016, Alioune 
> wrote:
Hi all,
I'm trying to implement service chain in OpenStack using networking-sfc 
(stable/mitaka) and OVS 2.5.90

The following is the architecture I used :

SRC DST
  ||
  == br-int 
 |
   SF1
SF1: 55.55.55.3
SRC: 55.55.55.4
DST: 55.55.55.5

I can create port-pairs, port-pair-group, classifier and chain with these 
commands:

neutron flow-classifier-create  --ethertype IPv4  --source-ip-prefix 
55.55.55.4/32  --logical-source-port 
0009034f-4c39-4cbf-be7d-fcf82dad024c  --protocol icmp  FC1
neutron port-pair-create --ingress=p1 --egress=p1 PP1
neutron port-pair-group-create --port-pair PP1 PG1
neutron port-chain-create --port-pair-group PG1 --flow-classifier FC1 PC1
I could ping from SRC to DST before setting the chain, but after the chain 
creating ping doesn't work.
ICMP echo request packets arrive to SF1 port but it doesn't send back the 
packets in order to allow them to get their destination DST (see output below).
The Opendaylight/SFC project uses NSH aware service function (SF) that send 
back packets to the chains after analyzing them, I would like to know :
- How networking-sfc configures SF to send back packets to the chain as seem in 
some of your presentation ?
- What's wrong in my configurations (see commands and ovs-ofctl output below) ? 
I've followed the main steps described in your wiki page.
Best Regards,


vagrant@vagrant-ubuntu-trusty-64:~$ neutron port-list
+--+--+---+--+
| id   | name | mac_address   | fixed_ips   
 |
+--+--+---+--+
| 0009034f-4c39-4cbf-be7d-fcf82dad024c |  | fa:16:3e:dd:16:f7 | 
{"subnet_id": "8bf8a2e1-ecad-4b4b-beb1-d760a16667bc", "ip_address": 
"55.55.55.4"}|
| 082e896d-5982-458c-96e7-0dd372d3d7d9 | p1   | fa:16:3e:90:b4:67 | 
{"subnet_id": "8bf8a2e1-ecad-4b4b-beb1-d760a16667bc", "ip_address": 
"55.55.55.3"}|
| 2ad109e4-42a8-4554-b884-a32344e91036 |  | fa:16:3e:74:9a:fa | 
{"subnet_id": "3cf6eb27-7258-4252-8f3d-b6f9d27c948b", "ip_address": 
"192.168.105.2"} |
| 51f055c0-ff4d-47f4-9328-9a0d7ca204f3 |  | fa:16:3e:da:f9:93 | 
{"subnet_id": "8bf8a2e1-ecad-4b4b-beb1-d760a16667bc", "ip_address": 
"55.55.55.1"}|
| 656ad901-2bc0-407a-a581-da955ecf3b59 |  | fa:16:3e:7f:44:01 | 
{"subnet_id": "8bf8a2e1-ecad-4b4b-beb1-d760a16667bc", "ip_address": 
"55.55.55.2"}|
| b1d14a4f-cde6-4c44-b42e-0f0466dba32a |  | fa:16:3e:a6:c6:35 | 
{"subnet_id": "8bf8a2e1-ecad-4b4b-beb1-d760a16667bc", "ip_address": 
"55.55.55.5"}|
+--+--+---+--+

vagrant@vagrant-ubuntu-trusty-64:~$ ifconfig |grep 082e896d
qbr082e896d-59 Link encap:Ethernet  HWaddr b6:96:27:fa:ab:af
qvb082e896d-59 Link encap:Ethernet  HWaddr b6:96:27:fa:ab:af
qvo082e896d-59 Link encap:Ethernet  HWaddr 7e:1a:7b:7d:09:df
tap082e896d-59 Link encap:Ethernet  HWaddr fe:16:3e:90:b4:67

vagrant@vagrant-ubuntu-trusty-64:~$ sudo tcpdump -i tap082e896d-59 icmp
tcpdump: WARNING: tap082e896d-59: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tap082e896d-59, link-type EN10MB (Ethernet), capture size 65535 
bytes
10:51:10.229674 IP 55.55.55.4 > 55.55.55.5: ICMP echo 
request, id 15617, seq 61, length 64
10:51:11.230318 IP 55.55.55.4 > 55.55.55.5: ICMP echo 
request, id 15617, seq 62, length 64
10:51:12.233451 IP 55.55.55.4 > 55.55.55.5: ICMP echo 
request, id 15617, seq 63, length 64
10:51:13.234496 IP 55.55.55.4 > 55.55.55.5: ICMP echo 
request, id 15617, seq 64, length 64
10:51:14.235583 IP 55.55.55.4 > 55.55.55.5: ICMP echo 
request, id 15617, seq 65, length 64
10:51:15.236585 IP 55.55.55.4 > 55.55.55.5: ICMP echo 
request, id 

Re: [openstack-dev] [networking-sfc][devstack][mitaka] Chain doesn't work

[Alioune]

Any suggestion ?

On Monday, 24 October 2016, Alioune  wrote:

> Hi all,
>
> I'm trying to implement service chain in OpenStack using networking-sfc
> (stable/mitaka) and OVS 2.5.90
>
>
> The following is the architecture I used :
>
> SRC DST
>   ||
>   == br-int 
>  |
>SF1
> SF1: 55.55.55.3
> SRC: 55.55.55.4
> DST: 55.55.55.5
>
> I can create port-pairs, port-pair-group, classifier and chain with these
> commands:
>
> neutron flow-classifier-create  --ethertype IPv4  --source-ip-prefix
> 55.55.55.4/32  --logical-source-port 0009034f-4c39-4cbf-be7d-fcf82dad024c
> --protocol icmp  FC1
> neutron port-pair-create --ingress=p1 --egress=p1 PP1
> neutron port-pair-group-create --port-pair PP1 PG1
> neutron port-chain-create --port-pair-group PG1 --flow-classifier FC1 PC1
>
> I could ping from SRC to DST before setting the chain, but after the chain
> creating ping doesn't work.
>
> ICMP echo request packets arrive to SF1 port but it doesn't send back the
> packets in order to allow them to get their destination DST (see output
> below).
>
> The Opendaylight/SFC project uses NSH aware service function (SF) that
> send back packets to the chains after analyzing them, I would like to know :
>
> - How networking-sfc configures SF to send back packets to the chain as
> seem in some of your presentation ?
> - What's wrong in my configurations (see commands and ovs-ofctl output
> below) ? I've followed the main steps described in your wiki page.
>
> Best Regards,
>
>
> vagrant@vagrant-ubuntu-trusty-64:~$ neutron port-list
> +--+--+-
> --+-
> -+
> | id   | name | mac_address   |
> fixed_ips
> |
> +--+--+-
> --+-
> -+
> | 0009034f-4c39-4cbf-be7d-fcf82dad024c |  | fa:16:3e:dd:16:f7 |
> {"subnet_id": "8bf8a2e1-ecad-4b4b-beb1-d760a16667bc", "ip_address":
> "55.55.55.4"}|
> | 082e896d-5982-458c-96e7-0dd372d3d7d9 | p1   | fa:16:3e:90:b4:67 |
> {"subnet_id": "8bf8a2e1-ecad-4b4b-beb1-d760a16667bc", "ip_address":
> "55.55.55.3"}|
> | 2ad109e4-42a8-4554-b884-a32344e91036 |  | fa:16:3e:74:9a:fa |
> {"subnet_id": "3cf6eb27-7258-4252-8f3d-b6f9d27c948b", "ip_address":
> "192.168.105.2"} |
> | 51f055c0-ff4d-47f4-9328-9a0d7ca204f3 |  | fa:16:3e:da:f9:93 |
> {"subnet_id": "8bf8a2e1-ecad-4b4b-beb1-d760a16667bc", "ip_address":
> "55.55.55.1"}|
> | 656ad901-2bc0-407a-a581-da955ecf3b59 |  | fa:16:3e:7f:44:01 |
> {"subnet_id": "8bf8a2e1-ecad-4b4b-beb1-d760a16667bc", "ip_address":
> "55.55.55.2"}|
> | b1d14a4f-cde6-4c44-b42e-0f0466dba32a |  | fa:16:3e:a6:c6:35 |
> {"subnet_id": "8bf8a2e1-ecad-4b4b-beb1-d760a16667bc", "ip_address":
> "55.55.55.5"}|
> +--+--+-
> --+-
> -+
>
> vagrant@vagrant-ubuntu-trusty-64:~$ ifconfig |grep 082e896d
> qbr082e896d-59 Link encap:Ethernet  HWaddr b6:96:27:fa:ab:af
> qvb082e896d-59 Link encap:Ethernet  HWaddr b6:96:27:fa:ab:af
> qvo082e896d-59 Link encap:Ethernet  HWaddr 7e:1a:7b:7d:09:df
> tap082e896d-59 Link encap:Ethernet  HWaddr fe:16:3e:90:b4:67
>
> vagrant@vagrant-ubuntu-trusty-64:~$ sudo tcpdump -i tap082e896d-59 icmp
> tcpdump: WARNING: tap082e896d-59: no IPv4 address assigned
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on tap082e896d-59, link-type EN10MB (Ethernet), capture size
> 65535 bytes
> 10:51:10.229674 IP 55.55.55.4 > 55.55.55.5: ICMP echo request, id 15617,
> seq 61, length 64
> 10:51:11.230318 IP 55.55.55.4 > 55.55.55.5: ICMP echo request, id 15617,
> seq 62, length 64
> 10:51:12.233451 IP 55.55.55.4 > 55.55.55.5: ICMP echo request, id 15617,
> seq 63, length 64
> 10:51:13.234496 IP 55.55.55.4 > 55.55.55.5: ICMP echo request, id 15617,
> seq 64, length 64
> 10:51:14.235583 IP 55.55.55.4 > 55.55.55.5: ICMP echo request, id 15617,
> seq 65, length 64
> 10:51:15.236585 IP 55.55.55.4 > 55.55.55.5: ICMP echo request, id 15617,
> seq 66, length 64
> 10:51:16.237568 IP 55.55.55.4 > 55.55.55.5: ICMP echo request, id 15617,
> seq 67, length 64
> 10:51:17.238974 IP 55.55.55.4 > 55.55.55.5: ICMP echo request, id 15617,
> seq 68, length 64
> 10:51:18.244244 IP 55.55.55.4 > 55.55.55.5: ICMP echo request, id 15617,
> seq 69, length 64
> 10:51:19.245758 IP 55.55.55.4 > 55.55.55.5: ICMP echo request, id 15617,
> seq 70, length 64
> 10:51:20.246521 IP 55.55.55.4 > 55.55.55.5: ICMP echo request, id 15617,
> seq 71, length 64
>
>
>
> vagrant@vagrant-ubuntu-trusty-64:~/openstack_networking/simple-sf$ 

[openstack-dev] [networking-sfc][devstack][mitaka] Chain doesn't work

[Alioune]

Hi all,

I'm trying to implement service chain in OpenStack using networking-sfc
(stable/mitaka) and OVS 2.5.90


The following is the architecture I used :

SRC DST
  ||
  == br-int 
 |
   SF1
SF1: 55.55.55.3
SRC: 55.55.55.4
DST: 55.55.55.5

I can create port-pairs, port-pair-group, classifier and chain with these
commands:

neutron flow-classifier-create  --ethertype IPv4  --source-ip-prefix
55.55.55.4/32  --logical-source-port 0009034f-4c39-4cbf-be7d-fcf82dad024c
--protocol icmp  FC1
neutron port-pair-create --ingress=p1 --egress=p1 PP1
neutron port-pair-group-create --port-pair PP1 PG1
neutron port-chain-create --port-pair-group PG1 --flow-classifier FC1 PC1

I could ping from SRC to DST before setting the chain, but after the chain
creating ping doesn't work.

ICMP echo request packets arrive to SF1 port but it doesn't send back the
packets in order to allow them to get their destination DST (see output
below).

The Opendaylight/SFC project uses NSH aware service function (SF) that send
back packets to the chains after analyzing them, I would like to know :

- How networking-sfc configures SF to send back packets to the chain as
seem in some of your presentation ?
- What's wrong in my configurations (see commands and ovs-ofctl output
below) ? I've followed the main steps described in your wiki page.

Best Regards,


vagrant@vagrant-ubuntu-trusty-64:~$ neutron port-list
+--+--+---+--+
| id   | name | mac_address   |
fixed_ips
|
+--+--+---+--+
| 0009034f-4c39-4cbf-be7d-fcf82dad024c |  | fa:16:3e:dd:16:f7 |
{"subnet_id": "8bf8a2e1-ecad-4b4b-beb1-d760a16667bc", "ip_address":
"55.55.55.4"}|
| 082e896d-5982-458c-96e7-0dd372d3d7d9 | p1   | fa:16:3e:90:b4:67 |
{"subnet_id": "8bf8a2e1-ecad-4b4b-beb1-d760a16667bc", "ip_address":
"55.55.55.3"}|
| 2ad109e4-42a8-4554-b884-a32344e91036 |  | fa:16:3e:74:9a:fa |
{"subnet_id": "3cf6eb27-7258-4252-8f3d-b6f9d27c948b", "ip_address":
"192.168.105.2"} |
| 51f055c0-ff4d-47f4-9328-9a0d7ca204f3 |  | fa:16:3e:da:f9:93 |
{"subnet_id": "8bf8a2e1-ecad-4b4b-beb1-d760a16667bc", "ip_address":
"55.55.55.1"}|
| 656ad901-2bc0-407a-a581-da955ecf3b59 |  | fa:16:3e:7f:44:01 |
{"subnet_id": "8bf8a2e1-ecad-4b4b-beb1-d760a16667bc", "ip_address":
"55.55.55.2"}|
| b1d14a4f-cde6-4c44-b42e-0f0466dba32a |  | fa:16:3e:a6:c6:35 |
{"subnet_id": "8bf8a2e1-ecad-4b4b-beb1-d760a16667bc", "ip_address":
"55.55.55.5"}|
+--+--+---+--+

vagrant@vagrant-ubuntu-trusty-64:~$ ifconfig |grep 082e896d
qbr082e896d-59 Link encap:Ethernet  HWaddr b6:96:27:fa:ab:af
qvb082e896d-59 Link encap:Ethernet  HWaddr b6:96:27:fa:ab:af
qvo082e896d-59 Link encap:Ethernet  HWaddr 7e:1a:7b:7d:09:df
tap082e896d-59 Link encap:Ethernet  HWaddr fe:16:3e:90:b4:67

vagrant@vagrant-ubuntu-trusty-64:~$ sudo tcpdump -i tap082e896d-59 icmp
tcpdump: WARNING: tap082e896d-59: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tap082e896d-59, link-type EN10MB (Ethernet), capture size
65535 bytes
10:51:10.229674 IP 55.55.55.4 > 55.55.55.5: ICMP echo request, id 15617,
seq 61, length 64
10:51:11.230318 IP 55.55.55.4 > 55.55.55.5: ICMP echo request, id 15617,
seq 62, length 64
10:51:12.233451 IP 55.55.55.4 > 55.55.55.5: ICMP echo request, id 15617,
seq 63, length 64
10:51:13.234496 IP 55.55.55.4 > 55.55.55.5: ICMP echo request, id 15617,
seq 64, length 64
10:51:14.235583 IP 55.55.55.4 > 55.55.55.5: ICMP echo request, id 15617,
seq 65, length 64
10:51:15.236585 IP 55.55.55.4 > 55.55.55.5: ICMP echo request, id 15617,
seq 66, length 64
10:51:16.237568 IP 55.55.55.4 > 55.55.55.5: ICMP echo request, id 15617,
seq 67, length 64
10:51:17.238974 IP 55.55.55.4 > 55.55.55.5: ICMP echo request, id 15617,
seq 68, length 64
10:51:18.244244 IP 55.55.55.4 > 55.55.55.5: ICMP echo request, id 15617,
seq 69, length 64
10:51:19.245758 IP 55.55.55.4 > 55.55.55.5: ICMP echo request, id 15617,
seq 70, length 64
10:51:20.246521 IP 55.55.55.4 > 55.55.55.5: ICMP echo request, id 15617,
seq 71, length 64



vagrant@vagrant-ubuntu-trusty-64:~/openstack_networking/simple-sf$ sudo
ovs-ofctl dump-flows br-int -O OpenFlow13

2016-10-24T11:28:43Z|1|ofp_actions|INFO|OFPAT_SET_MPLS_TTL is
deprecated in OpenFlow13 (use Set-Field)
OFPST_FLOW reply (OF1.3) (xid=0x2):
 cookie=0xbbf3cb977f3738c7, duration=2418.957s, table=0, n_packets=2297,
n_bytes=225106, 

Re: [openstack-dev] [networking-sfc][devstack][mitaka]

[Henry Fourie]

Navdeep,
  Post port-chain, port-pair-group, port-pair config to questions at 
https://launchpad.net/networking-sfc
  Use these commands to determine traffic flow and post results also.

  sudo ovs-ofctl -O openflow13 dump-flows br-int

  sudo ovs-ofctl -O Openflow13 dump-groups br-int


-Louis

From: Navdeep Uniyal [mailto:navdeep.uni...@neclab.eu]
Sent: Wednesday, October 12, 2016 3:06 AM
To: Cathy Zhang
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [networking-sfc][devstack][mitaka]

Hi Cathy,

Thanks for your reply. I have the setup done without any errors with only one 
vm in the chain. I want to move all the icmp traffic from vm1 to vm3 via vm2. 
My Flow classifier looks like:
"neutron flow-classifier-create --ethertype IPv4 --source-ip-prefix 
10.0.0.18/32 --destination-ip-prefix 10.0.0.6/32 --protocol icmp FC1"
But using tcpdump on vm2 ingress port, I could not see any traffic. Please let 
me know how can I debug this and what could be the possible issue.


Best Regards,
Navdeep Uniyal


From: Cathy Zhang [mailto:cathy.h.zh...@huawei.com]
Sent: Dienstag, 11. Oktober 2016 19:50
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [networking-sfc][devstack][mitaka]

Hi Navdeep,

Please see inline.

Cathy

From: Navdeep Uniyal [mailto:navdeep.uni...@neclab.eu]
Sent: Tuesday, October 11, 2016 5:42 AM
To: openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [networking-sfc][devstack][mitaka]

Hi all,

I have been trying out networking-sfc to create service function chain in 
Openstack. I could create all the port pairs, port-pair-groups, flow classifier 
and the chain but I could not see the packets on the desired hops.
I am trying to create a simple sfc with 3 VMs(vm1 to vm3) in the setup. I just 
want to check how it works. In my setup, vm1 is the Traffic generator(iperf) 
and vm3 is the traffic receiver(iperf server). Now, the  2 vms (vm2 and 3) are 
in the same network with vm1 and I want to move the iperf traffic from 
vm1->vm2->vm3. In order to achieve this, I have created 2 port pairs of vm2  
and vm3 and both pairs are in separate port pair groups (PG1 and PG2), also 
created a Flow classifier FC1 and finally chain with PG1, PG2 and FC1.  Now my 
question is, is my setup correct in order to achieve the sfc result as I stated 
above? Do I need to include the vm1 in the port pair group?

Cathy> You only need to include VM2 in a port pair group. Traffic source and 
traffic destination do not need to be included in the chain's port pair group, 
instead their IP addresses should be included in the flow classifier so that 
the system knows which flow needs to go through the chain. Here is a link to 
thw wiki.
https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining

Cathy




Below is the flow classifier:

++--+
| Field  | Value
|
++--+
| description  |
  |
| destination_ip_prefix   |  |
| destination_port_range_max |  |
| destination_port_range_min |  |
| ethertype| IPv4   
  |
| id | 
e5000ade-50ad-41ed-a159-b89c4blp97ec |
| l7_parameters  | {}   
|
| logical_destination_port   |  |
| logical_source_port   | 63cdf664-dd67-455c-8345-f01ef58c23e5 |
| name| FC1 
 |
| project_id   | 
6b90cd3356144681b44274d4881c5fc7 |
| protocol  | tcp   
   |
| source_ip_prefix  | 10.0.0.18/32  
   |
| source_port_range_max  |  |
| source_port_range_min  |  |
| tenant_id | 
6b90cd3310104681b44274d4881c5fc7 |
++--+



Is there any wiki with some example case explained with testing scenario?


Best Regards,
Navdeep Uniyal
Email: navdeep.uni...@neclab.eu<mailto:navdeep.uni...@neclab.eu>
-
Software Engineer
NEC Europe Ltd.
NEC Laboratories Europe
Kurfürstenanlage 36, D-69115 Heidelberg,

NEC Europe Ltd | Registered Office: Athene, Odyssey Busines

Re: [openstack-dev] [networking-sfc][devstack][mitaka]

[Navdeep Uniyal]

Hi Cathy,

Thanks for your reply. I have the setup done without any errors with only one 
vm in the chain. I want to move all the icmp traffic from vm1 to vm3 via vm2. 
My Flow classifier looks like:
"neutron flow-classifier-create --ethertype IPv4 --source-ip-prefix 
10.0.0.18/32 --destination-ip-prefix 10.0.0.6/32 --protocol icmp FC1"
But using tcpdump on vm2 ingress port, I could not see any traffic. Please let 
me know how can I debug this and what could be the possible issue.


Best Regards,
Navdeep Uniyal


From: Cathy Zhang [mailto:cathy.h.zh...@huawei.com]
Sent: Dienstag, 11. Oktober 2016 19:50
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [networking-sfc][devstack][mitaka]

Hi Navdeep,

Please see inline.

Cathy

From: Navdeep Uniyal [mailto:navdeep.uni...@neclab.eu]
Sent: Tuesday, October 11, 2016 5:42 AM
To: openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [networking-sfc][devstack][mitaka]

Hi all,

I have been trying out networking-sfc to create service function chain in 
Openstack. I could create all the port pairs, port-pair-groups, flow classifier 
and the chain but I could not see the packets on the desired hops.
I am trying to create a simple sfc with 3 VMs(vm1 to vm3) in the setup. I just 
want to check how it works. In my setup, vm1 is the Traffic generator(iperf) 
and vm3 is the traffic receiver(iperf server). Now, the  2 vms (vm2 and 3) are 
in the same network with vm1 and I want to move the iperf traffic from 
vm1->vm2->vm3. In order to achieve this, I have created 2 port pairs of vm2  
and vm3 and both pairs are in separate port pair groups (PG1 and PG2), also 
created a Flow classifier FC1 and finally chain with PG1, PG2 and FC1.  Now my 
question is, is my setup correct in order to achieve the sfc result as I stated 
above? Do I need to include the vm1 in the port pair group?

Cathy> You only need to include VM2 in a port pair group. Traffic source and 
traffic destination do not need to be included in the chain's port pair group, 
instead their IP addresses should be included in the flow classifier so that 
the system knows which flow needs to go through the chain. Here is a link to 
thw wiki.
https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining

Cathy




Below is the flow classifier:

++--+
| Field  | Value
|
++--+
| description  |
  |
| destination_ip_prefix   |  |
| destination_port_range_max |  |
| destination_port_range_min |  |
| ethertype| IPv4   
  |
| id | 
e5000ade-50ad-41ed-a159-b89c4blp97ec |
| l7_parameters  | {}   
|
| logical_destination_port   |  |
| logical_source_port   | 63cdf664-dd67-455c-8345-f01ef58c23e5 |
| name| FC1 
 |
| project_id   | 
6b90cd3356144681b44274d4881c5fc7 |
| protocol  | tcp   
   |
| source_ip_prefix  | 10.0.0.18/32  
   |
| source_port_range_max  |  |
| source_port_range_min  |  |
| tenant_id | 
6b90cd3310104681b44274d4881c5fc7 |
++--+



Is there any wiki with some example case explained with testing scenario?


Best Regards,
Navdeep Uniyal
Email: navdeep.uni...@neclab.eu<mailto:navdeep.uni...@neclab.eu>
-
Software Engineer
NEC Europe Ltd.
NEC Laboratories Europe
Kurfürstenanlage 36, D-69115 Heidelberg,

NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West End  
Road, London, HA4 6QE, GB | Registered in England 2832014
__
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

Re: [openstack-dev] [networking-sfc][devstack][mitaka]

[Cathy Zhang]

Hi Navdeep,

Please see inline.

Cathy

From: Navdeep Uniyal [mailto:navdeep.uni...@neclab.eu]
Sent: Tuesday, October 11, 2016 5:42 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [networking-sfc][devstack][mitaka]

Hi all,

I have been trying out networking-sfc to create service function chain in 
Openstack. I could create all the port pairs, port-pair-groups, flow classifier 
and the chain but I could not see the packets on the desired hops.
I am trying to create a simple sfc with 3 VMs(vm1 to vm3) in the setup. I just 
want to check how it works. In my setup, vm1 is the Traffic generator(iperf) 
and vm3 is the traffic receiver(iperf server). Now, the  2 vms (vm2 and 3) are 
in the same network with vm1 and I want to move the iperf traffic from 
vm1->vm2->vm3. In order to achieve this, I have created 2 port pairs of vm2  
and vm3 and both pairs are in separate port pair groups (PG1 and PG2), also 
created a Flow classifier FC1 and finally chain with PG1, PG2 and FC1.  Now my 
question is, is my setup correct in order to achieve the sfc result as I stated 
above? Do I need to include the vm1 in the port pair group?

Cathy> You only need to include VM2 in a port pair group. Traffic source and 
traffic destination do not need to be included in the chain's port pair group, 
instead their IP addresses should be included in the flow classifier so that 
the system knows which flow needs to go through the chain. Here is a link to 
thw wiki.
https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining

Cathy




Below is the flow classifier:

++--+
| Field  | Value
|
++--+
| description  |
  |
| destination_ip_prefix   |  |
| destination_port_range_max |  |
| destination_port_range_min |  |
| ethertype| IPv4   
  |
| id | 
e5000ade-50ad-41ed-a159-b89c4blp97ec |
| l7_parameters  | {}   
|
| logical_destination_port   |  |
| logical_source_port   | 63cdf664-dd67-455c-8345-f01ef58c23e5 |
| name| FC1 
 |
| project_id   | 
6b90cd3356144681b44274d4881c5fc7 |
| protocol  | tcp   
   |
| source_ip_prefix  | 10.0.0.18/32  
   |
| source_port_range_max  |  |
| source_port_range_min  |  |
| tenant_id | 
6b90cd3310104681b44274d4881c5fc7 |
++--+



Is there any wiki with some example case explained with testing scenario?


Best Regards,
Navdeep Uniyal
Email: navdeep.uni...@neclab.eu<mailto:navdeep.uni...@neclab.eu>
-
Software Engineer
NEC Europe Ltd.
NEC Laboratories Europe
Kurfürstenanlage 36, D-69115 Heidelberg,

NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West End  
Road, London, HA4 6QE, GB | Registered in England 2832014
__
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-dev] [networking-sfc][devstack][mitaka]

[Navdeep Uniyal]

Hi all,

I have been trying out networking-sfc to create service function chain in 
Openstack. I could create all the port pairs, port-pair-groups, flow classifier 
and the chain but I could not see the packets on the desired hops.
I am trying to create a simple sfc with 3 VMs(vm1 to vm3) in the setup. I just 
want to check how it works. In my setup, vm1 is the Traffic generator(iperf) 
and vm3 is the traffic receiver(iperf server). Now, the  2 vms (vm2 and 3) are 
in the same network with vm1 and I want to move the iperf traffic from 
vm1->vm2->vm3. In order to achieve this, I have created 2 port pairs of vm2  
and vm3 and both pairs are in separate port pair groups (PG1 and PG2), also 
created a Flow classifier FC1 and finally chain with PG1, PG2 and FC1.  Now my 
question is, is my setup correct in order to achieve the sfc result as I stated 
above? Do I need to include the vm1 in the port pair group?
Below is the flow classifier:

++--+
| Field  | Value
|
++--+
| description  |
  |
| destination_ip_prefix   |  |
| destination_port_range_max |  |
| destination_port_range_min |  |
| ethertype| IPv4   
  |
| id | 
e5000ade-50ad-41ed-a159-b89c4blp97ec |
| l7_parameters  | {}   
|
| logical_destination_port   |  |
| logical_source_port   | 63cdf664-dd67-455c-8345-f01ef58c23e5 |
| name| FC1 
 |
| project_id   | 
6b90cd3356144681b44274d4881c5fc7 |
| protocol  | tcp   
   |
| source_ip_prefix  | 10.0.0.18/32  
   |
| source_port_range_max  |  |
| source_port_range_min  |  |
| tenant_id | 
6b90cd3310104681b44274d4881c5fc7 |
++--+



Is there any wiki with some example case explained with testing scenario?


Best Regards,
Navdeep Uniyal
Email: navdeep.uni...@neclab.eu
-
Software Engineer
NEC Europe Ltd.
NEC Laboratories Europe
Kurfürstenanlage 36, D-69115 Heidelberg,

NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West End  
Road, London, HA4 6QE, GB | Registered in England 2832014
__
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

Re: [openstack-dev] [networking-sfc] OpenFlow version to use in the OVS agent

[Bernard Cafarelli]

Thanks, the comment and function name led me to think it was supposed
to only return the matching group.
So I will keep current 1.3 version in the L2 agent extension then!

On 20 September 2016 at 20:48, Cathy Zhang <cathy.h.zh...@huawei.com> wrote:
> Hi Bernard,
>
> Networking-sfc currently uses OF1.3. Although OF1.3 dumps all groups, 
> networking-sfc has follow-on filter code to select the info associated with 
> the specific group ID from the dump. So we are fine and let's keep it as 
> OF1.3.
>
> We can upgrade to OF1.5 when Neutron uses OF1.5.
>
> Thanks,
> Cathy
>
>
> -Original Message-
> From: Bernard Cafarelli [mailto:bcafa...@redhat.com]
> Sent: Tuesday, September 20, 2016 7:16 AM
> To: OpenStack Development Mailing List
> Subject: [openstack-dev] [networking-sfc] OpenFlow version to use in the OVS 
> agent
>
> In the OVSSfcAgent migration to a L2 agent extension review[1], Igor Duarte 
> Cardoso noticed a difference on the OpenFlow versions between a comment and 
> actual code.
> In current code [2], we have:
> # We need to dump-groups according to group Id, # which is a feature of 
> OpenFlow1.5 full_args = ["ovs-ofctl", "-O openflow13", cmd, self.br_name
>
> Indeed, only OpenFlow 1.5 and later support dumping a specific group [3]. 
> Earlier versions of OpenFlow always dump all groups.
> So current code will return all groups:
> $ sudo ovs-ofctl -O OpenFlow13 dump-groups br-int 1 OFPST_GROUP_DESC reply 
> (OF1.3) (xid=0x2):
>  
> group_id=1,type=select,bucket=actions=set_field:fa:16:3e:05:46:69->eth_dst,resubmit(,5),bucket=actions=set_field:fa:16:3e:cd:b7:7e->eth_dst,resubmit(,5)
>  
> group_id=2,type=select,bucket=actions=set_field:fa:16:3e:2d:f3:28->eth_dst,resubmit(,5)
> $ sudo ovs-ofctl -O OpenFlow15 dump-groups br-int 1 OFPST_GROUP_DESC reply 
> (OF1.5) (xid=0x2):
>  
> group_id=1,type=select,bucket=bucket_id:0,actions=set_field:fa:16:3e:05:46:69->eth_dst,resubmit(,5),bucket=bucket_id:1,actions=set_field:fa:16:3e:cd:b7:7e->eth_dst,resubmit(,5)
>
> This code behavior will not change in my extension rewrite, so this will 
> still have to be fixed. though I am not sure on the solution:
> * We can use Openflow 1.5, but its support looks experimental? And Neutron 
> apparently only uses up to 1.4 (for OVS firewall extension)
> * Method to dump a group can "grep" the group ID in the complete dump.
> Not as efficient but works with OpenFlow 1.1+
> * Use another system to load balance across the port pairs?
>
> Thoughts?
> In gerrit, I kept it set to 1.5 (no impact for now as this is still marked as 
> WIP)
>
> [1]: https://review.openstack.org/#/c/351789
> [2]: 
> https://github.com/openstack/networking-sfc/blob/master/networking_sfc/services/sfc/common/ovs_ext_lib.py
> [3]: http://openvswitch.org/support/dist-docs/ovs-ofctl.8.txt
>
> --
> 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



-- 
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

Re: [openstack-dev] [networking-sfc] OpenFlow version to use in the OVS agent

[Cathy Zhang]

Hi Bernard,

Networking-sfc currently uses OF1.3. Although OF1.3 dumps all groups, 
networking-sfc has follow-on filter code to select the info associated with the 
specific group ID from the dump. So we are fine and let's keep it as OF1.3. 

We can upgrade to OF1.5 when Neutron uses OF1.5. 

Thanks,
Cathy


-Original Message-
From: Bernard Cafarelli [mailto:bcafa...@redhat.com] 
Sent: Tuesday, September 20, 2016 7:16 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [networking-sfc] OpenFlow version to use in the OVS 
agent

In the OVSSfcAgent migration to a L2 agent extension review[1], Igor Duarte 
Cardoso noticed a difference on the OpenFlow versions between a comment and 
actual code.
In current code [2], we have:
# We need to dump-groups according to group Id, # which is a feature of 
OpenFlow1.5 full_args = ["ovs-ofctl", "-O openflow13", cmd, self.br_name

Indeed, only OpenFlow 1.5 and later support dumping a specific group [3]. 
Earlier versions of OpenFlow always dump all groups.
So current code will return all groups:
$ sudo ovs-ofctl -O OpenFlow13 dump-groups br-int 1 OFPST_GROUP_DESC reply 
(OF1.3) (xid=0x2):
 
group_id=1,type=select,bucket=actions=set_field:fa:16:3e:05:46:69->eth_dst,resubmit(,5),bucket=actions=set_field:fa:16:3e:cd:b7:7e->eth_dst,resubmit(,5)
 
group_id=2,type=select,bucket=actions=set_field:fa:16:3e:2d:f3:28->eth_dst,resubmit(,5)
$ sudo ovs-ofctl -O OpenFlow15 dump-groups br-int 1 OFPST_GROUP_DESC reply 
(OF1.5) (xid=0x2):
 
group_id=1,type=select,bucket=bucket_id:0,actions=set_field:fa:16:3e:05:46:69->eth_dst,resubmit(,5),bucket=bucket_id:1,actions=set_field:fa:16:3e:cd:b7:7e->eth_dst,resubmit(,5)

This code behavior will not change in my extension rewrite, so this will still 
have to be fixed. though I am not sure on the solution:
* We can use Openflow 1.5, but its support looks experimental? And Neutron 
apparently only uses up to 1.4 (for OVS firewall extension)
* Method to dump a group can "grep" the group ID in the complete dump.
Not as efficient but works with OpenFlow 1.1+
* Use another system to load balance across the port pairs?

Thoughts?
In gerrit, I kept it set to 1.5 (no impact for now as this is still marked as 
WIP)

[1]: https://review.openstack.org/#/c/351789
[2]: 
https://github.com/openstack/networking-sfc/blob/master/networking_sfc/services/sfc/common/ovs_ext_lib.py
[3]: http://openvswitch.org/support/dist-docs/ovs-ofctl.8.txt

--
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

[openstack-dev] [networking-sfc] OpenFlow version to use in the OVS agent

[Bernard Cafarelli]

In the OVSSfcAgent migration to a L2 agent extension review[1], Igor
Duarte Cardoso noticed a difference on the OpenFlow versions between a
comment and actual code.
In current code [2], we have:
# We need to dump-groups according to group Id,
# which is a feature of OpenFlow1.5
full_args = ["ovs-ofctl", "-O openflow13", cmd, self.br_name

Indeed, only OpenFlow 1.5 and later support dumping a specific group
[3]. Earlier versions of OpenFlow always dump all groups.
So current code will return all groups:
$ sudo ovs-ofctl -O OpenFlow13 dump-groups br-int 1
OFPST_GROUP_DESC reply (OF1.3) (xid=0x2):
 
group_id=1,type=select,bucket=actions=set_field:fa:16:3e:05:46:69->eth_dst,resubmit(,5),bucket=actions=set_field:fa:16:3e:cd:b7:7e->eth_dst,resubmit(,5)
 
group_id=2,type=select,bucket=actions=set_field:fa:16:3e:2d:f3:28->eth_dst,resubmit(,5)
$ sudo ovs-ofctl -O OpenFlow15 dump-groups br-int 1
OFPST_GROUP_DESC reply (OF1.5) (xid=0x2):
 
group_id=1,type=select,bucket=bucket_id:0,actions=set_field:fa:16:3e:05:46:69->eth_dst,resubmit(,5),bucket=bucket_id:1,actions=set_field:fa:16:3e:cd:b7:7e->eth_dst,resubmit(,5)

This code behavior will not change in my extension rewrite, so this
will still have to be fixed. though I am not sure on the solution:
* We can use Openflow 1.5, but its support looks experimental? And
Neutron apparently only uses up to 1.4 (for OVS firewall extension)
* Method to dump a group can "grep" the group ID in the complete dump.
Not as efficient but works with OpenFlow 1.1+
* Use another system to load balance across the port pairs?

Thoughts?
In gerrit, I kept it set to 1.5 (no impact for now as this is still
marked as WIP)

[1]: https://review.openstack.org/#/c/351789
[2]: 
https://github.com/openstack/networking-sfc/blob/master/networking_sfc/services/sfc/common/ovs_ext_lib.py
[3]: http://openvswitch.org/support/dist-docs/ovs-ofctl.8.txt

-- 
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

Re: [openstack-dev] [networking-sfc] SFC flows issue

[Ravi Sekhar Reddy Konda]

9 
actions=resubmit(,25) 
cookie=0x936171a2fbba22bd, duration=2361.229s, table=24, n_packets=40, 
n_bytes=1680, priority=2,arp,in_port=16,arp_spa=192.168.0.4 
actions=resubmit(,25) 
cookie=0x936171a2fbba22bd, duration=2359.474s, table=24, n_packets=5, 
n_bytes=210, priority=2,arp,in_port=17,arp_spa=192.168.0.12 
actions=resubmit(,25) 
cookie=0x936171a2fbba22bd, duration=1506.775s, table=24, n_packets=9, 
n_bytes=378, priority=2,arp,in_port=18,arp_spa=192.168.0.8 
actions=resubmit(,25) 
cookie=0x936171a2fbba22bd, duration=5522.815s, table=24, n_packets=219, 
n_bytes=9198, priority=0 actions=drop 
cookie=0x936171a2fbba22bd, duration=2411.489s, table=25, n_packets=33, 
n_bytes=2960, priority=2,in_port=15,dl_src=fa:16:3e:48:88:96 actions=NORMAL 
cookie=0x936171a2fbba22bd, duration=2361.270s, table=25, n_packets=1014, 
n_bytes=138605, priority=2,in_port=16,dl_src=fa:16:3e:bb:be:c2 actions=NORMAL 
cookie=0x936171a2fbba22bd, duration=2359.543s, table=25, n_packets=50, 
n_bytes=4684, priority=2,in_port=17,dl_src=fa:16:3e:9a:29:f1 actions=NORMAL 
cookie=0x936171a2fbba22bd, duration=1506.817s, table=25, n_packets=30, 
n_bytes=2716, priority=2,in_port=18,dl_src=fa:16:3e:9f:25:c8 actions=NORMAL 
stack@cloud-VirtualBox:~/test$ 

Thanks in advance, 
Ravi 

- Original Message - 
From: all 
To: openstack-dev@lists.openstack.org 
Sent: Tuesday, September 6, 2016 1:17:11 PM GMT +05:30 Chennai, Kolkata, 
Mumbai, New Delhi 
Subject: Re: [openstack-dev] [networking-sfc] SFC flows issue 



Hi Ravi , 


Could you share tcpdump on P3 as well ( sudo tcpdump -n -e -i "P3 
tab-interface" ) 


IMO , the possible reasons would be 


[1] port-security on SF port may block the packet , since it destined to 
different ip address. 


[2] The SF program may alter the IP Header (Destination field ) 


Flow rules are looks okay , and it shows packets are dropped in between p2 and 
p3 . 




Thanks., 
Mohankumar.N 





On Sat, Sep 3, 2016 at 10:07 AM, Ravi Sekhar Reddy Konda < 
ravisekhar.ko...@oracle.com > wrote: 




Hi Networking SFC team 






I am trying out networking-SFC on the AllInOne Devstack(master branch) VM 
brought up on the VirtualBox. 
I am trying out the following scenario 

|--| |--| |--| 
| SRC-VM | | SF-VM | | DST-VM | 
|--| |--| |--| 
p1 | p2 | |p3 p4 | 
| | | | 
| | | | 
Net1-
 


P1 -> 192.168.0.6 "fa:16:3e:d8:8f:28" 
P2 -> 192.168.0.10 "fa:16:3e:12:7e:50" 
P3 -> 192.168.0.5 "fa:16:3e:1e:f8:c2" 
P4 -> 192.168.0.14 "fa:16:3e:4d:e8:c3" 


On SF-VM, I have written a simple application to capture the packets on eth0 
and forward to eth1 

The issue I am facing is packets are getting sent from Port-1 (SRC-VM) to 
Port-2 (SF-VM), but I am not seeing packets getting sent from Port-3 (SF-VM) to 
Port-4 (DST-VM) 

Here is the Classifier I created 

neutron flow-classifier-create --ethertype IPv4 --source-ip-prefix 
192.168.0.6/32 --logical-source-port 6c700c35-6505-4304-89cd-b48513884cf5 
--destination-ip-prefix 192.168.0.14/32 --logical-destination-port 
d0b218c9-57f4-4d38-b363-2086b8dbc8b9 --protocol icmp fc1 

==> Can you please let me know are the flows as expected in this scenario 
OFPST_FLOW reply (OF1.3) (xid=0x2): 
cookie=0x9118e6e52dd3dfa0, duration=34624.734s, table=0, n_packets=399, 
n_bytes=39102, 
priority=30,icmp,in_port=9,nw_src=192.168.0.6,nw_dst=192.168.0.14 
actions=group:1 
cookie=0x9118e6e52dd3dfa0, duration=34624.696s, table=0, n_packets=0, 
n_bytes=0, priority=30,icmp,in_port=13,nw_src=192.168.0.6,nw_dst=192.168.0.14 
actions=NORMAL 
cookie=0x9118e6e52dd3dfa0, duration=45300.986s, table=0, n_packets=0, 
n_bytes=0, priority=20,mpls actions=resubmit(,10) 
cookie=0x9118e6e52dd3dfa0, duration=42858.783s, table=0, n_packets=0, 
n_bytes=0, priority=10,icmp6,in_port=9,icmp_type=136 actions=resubmit(,24) 
cookie=0x9118e6e52dd3dfa0, duration=42250.745s, table=0, n_packets=0, 
n_bytes=0, priority=10,icmp6,in_port=10,icmp_type=136 actions=resubmit(,24) 
cookie=0x9118e6e52dd3dfa0, duration=37845.792s, table=0, n_packets=0, 
n_bytes=0, priority=10,icmp6,in_port=12,icmp_type=136 actions=resubmit(,24) 
cookie=0x9118e6e52dd3dfa0, duration=37617.801s, table=0, n_packets=0, 
n_bytes=0, priority=10,icmp6,in_port=13,icmp_type=136 actions=resubmit(,24) 
cookie=0x9118e6e52dd3dfa0, duration=42858.758s, table=0, n_packets=73, 
n_bytes=3066, priority=10,arp,in_port=9 actions=resubmit(,24) 
cookie=0x9118e6e52dd3dfa0, duration=42250.725s, table=0, n_packets=151, 
n_bytes=6342, priority=10,arp,in_port=10 actions=resubmit(,24) 
cookie=0x9118e6e52dd3dfa0, duration=37845.769s, table=0, n_packets=666039, 
n_bytes=27973638, priority=10,arp,in_port=12 actions=resubmit(,24) 
cookie=0x9118e6e52dd3dfa0, duration=37617.782s, table=0, n_packets=666069, 
n_bytes=27974898, priority=10,arp,in_port=13 acti

Re: [openstack-dev] [networking-sfc] SFC flows issue

[Mohan Kumar]

Hi Ravi ,

Could you share tcpdump on P3 as well ( sudo tcpdump  -n -e -i
 "P3 tab-interface" )

IMO , the possible reasons would be

[1]  port-security on SF port  may block the packet , since it destined to
different ip address.

[2]  The SF program may alter the IP Header (Destination field )

Flow rules are looks okay , and it shows packets are dropped in between p2
and p3 .


Thanks.,
Mohankumar.N



On Sat, Sep 3, 2016 at 10:07 AM, Ravi Sekhar Reddy Konda <
ravisekhar.ko...@oracle.com> wrote:

> Hi Networking SFC team
>
>  I am trying out networking-SFC on the AllInOne Devstack(master branch) VM
> brought up on the VirtualBox.
>  I am trying out the following scenario
>
>   |--|  |--|
> |--|
>   | SRC-VM  |  |   SF-VM
> |   |  DST-VM |
>   |--|
> |--|   |--|
> p1 |p2 |
> |p3   p4 |
>  | |
> ||
>  | |
> ||
> Net1
> -
>
>
> P1 ->  192.168.0.6  "fa:16:3e:d8:8f:28"
> P2 ->  192.168.0.10   "fa:16:3e:12:7e:50"
> P3 ->  192.168.0.5 "fa:16:3e:1e:f8:c2"
> P4 ->  192.168.0.14   "fa:16:3e:4d:e8:c3"
>
> On SF-VM, I have written a simple application to capture the packets on
> eth0 and forward to eth1
>
> The issue I am facing is packets are getting sent from Port-1 (SRC-VM) to
> Port-2 (SF-VM), but I am not seeing packets getting sent from Port-3
> (SF-VM) to Port-4 (DST-VM)
>
> Here is the Classifier I created
>
> neutron flow-classifier-create --ethertype IPv4 --source-ip-prefix
> 192.168.0.6/32 --logical-source-port 6c700c35-6505-4304-89cd-b48513884cf5
> --destination-ip-prefix 192.168.0.14/32 --logical-destination-port
> d0b218c9-57f4-4d38-b363-2086b8dbc8b9 --protocol icmp fc1
>
> ==> Can you please let me know are the flows as expected in this scenario
> OFPST_FLOW reply (OF1.3) (xid=0x2):
>  cookie=0x9118e6e52dd3dfa0, duration=34624.734s, table=0, n_packets=399,
> n_bytes=39102, 
> priority=30,icmp,in_port=9,nw_src=192.168.0.6,nw_dst=192.168.0.14
> actions=group:1
>  cookie=0x9118e6e52dd3dfa0, duration=34624.696s, table=0, n_packets=0,
> n_bytes=0, priority=30,icmp,in_port=13,nw_src=192.168.0.6,nw_dst=192.168.0.14
> actions=NORMAL
>  cookie=0x9118e6e52dd3dfa0, duration=45300.986s, table=0, n_packets=0,
> n_bytes=0, priority=20,mpls actions=resubmit(,10)
>  cookie=0x9118e6e52dd3dfa0, duration=42858.783s, table=0, n_packets=0,
> n_bytes=0, priority=10,icmp6,in_port=9,icmp_type=136 actions=resubmit(,24)
>  cookie=0x9118e6e52dd3dfa0, duration=42250.745s, table=0, n_packets=0,
> n_bytes=0, priority=10,icmp6,in_port=10,icmp_type=136
> actions=resubmit(,24)
>  cookie=0x9118e6e52dd3dfa0, duration=37845.792s, table=0, n_packets=0,
> n_bytes=0, priority=10,icmp6,in_port=12,icmp_type=136
> actions=resubmit(,24)
>  cookie=0x9118e6e52dd3dfa0, duration=37617.801s, table=0, n_packets=0,
> n_bytes=0, priority=10,icmp6,in_port=13,icmp_type=136
> actions=resubmit(,24)
>  cookie=0x9118e6e52dd3dfa0, duration=42858.758s, table=0, n_packets=73,
> n_bytes=3066, priority=10,arp,in_port=9 actions=resubmit(,24)
>  cookie=0x9118e6e52dd3dfa0, duration=42250.725s, table=0, n_packets=151,
> n_bytes=6342, priority=10,arp,in_port=10 actions=resubmit(,24)
>  cookie=0x9118e6e52dd3dfa0, duration=37845.769s, table=0,
> n_packets=666039, n_bytes=27973638, priority=10,arp,in_port=12
> actions=resubmit(,24)
>  cookie=0x9118e6e52dd3dfa0, duration=37617.782s, table=0,
> n_packets=666069, n_bytes=27974898, priority=10,arp,in_port=13
> actions=resubmit(,24)
>  cookie=0x9118e6e52dd3dfa0, duration=45302.016s, table=0, n_packets=0,
> n_bytes=0, priority=2,in_port=1 actions=drop
>  cookie=0x9118e6e52dd3dfa0, duration=42858.804s, table=0, n_packets=10993,
> n_bytes=2219925, priority=9,in_port=9 actions=resubmit(,25)
>  cookie=0x9118e6e52dd3dfa0, duration=42250.774s, table=0, n_packets=22275,
> n_bytes=4028172, priority=9,in_port=10 actions=resubmit(,25)
>  cookie=0x9118e6e52dd3dfa0, duration=37845.822s, table=0, n_packets=9967,
> n_bytes=1989597, priority=9,in_port=12 actions=resubmit(,25)
>  cookie=0x9118e6e52dd3dfa0, duration=37617.828s, table=0, n_packets=11154,
> n_bytes=2154155, priority=9,in_port=13 actions=resubmit(,25)
>  cookie=0x9118e6e52dd3dfa0, duration=45268.699s, table=0, n_packets=14048,
> n_bytes=1104503, priority=3,in_port=1,vlan_tci=0x/0x1fff
> actions=push_vlan:0x8100,set_field:4098->vlan_vid,NORMAL
>  cookie=0x9118e6e52dd3dfa0, duration=45302.314s, table=0, 

[openstack-dev] [networking-sfc] SFC flows issue

[Ravi Sekhar Reddy Konda]

Hi Networking SFC team 






I am trying out networking-SFC on the AllInOne Devstack(master branch) VM 
brought up on the VirtualBox. 
I am trying out the following scenario 

|--| |--| |--| 
| SRC-VM | | SF-VM | | DST-VM | 
|--| |--| |--| 
p1 | p2 | |p3 p4 | 
| | | | 
| | | | 
Net1-
 


P1 -> 192.168.0.6 "fa:16:3e:d8:8f:28" 
P2 -> 192.168.0.10 "fa:16:3e:12:7e:50" 
P3 -> 192.168.0.5 "fa:16:3e:1e:f8:c2" 
P4 -> 192.168.0.14 "fa:16:3e:4d:e8:c3" 


On SF-VM, I have written a simple application to capture the packets on eth0 
and forward to eth1 

The issue I am facing is packets are getting sent from Port-1 (SRC-VM) to 
Port-2 (SF-VM), but I am not seeing packets getting sent from Port-3 (SF-VM) to 
Port-4 (DST-VM) 

Here is the Classifier I created 

neutron flow-classifier-create --ethertype IPv4 --source-ip-prefix 
192.168.0.6/32 --logical-source-port 6c700c35-6505-4304-89cd-b48513884cf5 
--destination-ip-prefix 192.168.0.14/32 --logical-destination-port 
d0b218c9-57f4-4d38-b363-2086b8dbc8b9 --protocol icmp fc1 

==> Can you please let me know are the flows as expected in this scenario 
OFPST_FLOW reply (OF1.3) (xid=0x2): 
cookie=0x9118e6e52dd3dfa0, duration=34624.734s, table=0, n_packets=399, 
n_bytes=39102, 
priority=30,icmp,in_port=9,nw_src=192.168.0.6,nw_dst=192.168.0.14 
actions=group:1 
cookie=0x9118e6e52dd3dfa0, duration=34624.696s, table=0, n_packets=0, 
n_bytes=0, priority=30,icmp,in_port=13,nw_src=192.168.0.6,nw_dst=192.168.0.14 
actions=NORMAL 
cookie=0x9118e6e52dd3dfa0, duration=45300.986s, table=0, n_packets=0, 
n_bytes=0, priority=20,mpls actions=resubmit(,10) 
cookie=0x9118e6e52dd3dfa0, duration=42858.783s, table=0, n_packets=0, 
n_bytes=0, priority=10,icmp6,in_port=9,icmp_type=136 actions=resubmit(,24) 
cookie=0x9118e6e52dd3dfa0, duration=42250.745s, table=0, n_packets=0, 
n_bytes=0, priority=10,icmp6,in_port=10,icmp_type=136 actions=resubmit(,24) 
cookie=0x9118e6e52dd3dfa0, duration=37845.792s, table=0, n_packets=0, 
n_bytes=0, priority=10,icmp6,in_port=12,icmp_type=136 actions=resubmit(,24) 
cookie=0x9118e6e52dd3dfa0, duration=37617.801s, table=0, n_packets=0, 
n_bytes=0, priority=10,icmp6,in_port=13,icmp_type=136 actions=resubmit(,24) 
cookie=0x9118e6e52dd3dfa0, duration=42858.758s, table=0, n_packets=73, 
n_bytes=3066, priority=10,arp,in_port=9 actions=resubmit(,24) 
cookie=0x9118e6e52dd3dfa0, duration=42250.725s, table=0, n_packets=151, 
n_bytes=6342, priority=10,arp,in_port=10 actions=resubmit(,24) 
cookie=0x9118e6e52dd3dfa0, duration=37845.769s, table=0, n_packets=666039, 
n_bytes=27973638, priority=10,arp,in_port=12 actions=resubmit(,24) 
cookie=0x9118e6e52dd3dfa0, duration=37617.782s, table=0, n_packets=666069, 
n_bytes=27974898, priority=10,arp,in_port=13 actions=resubmit(,24) 
cookie=0x9118e6e52dd3dfa0, duration=45302.016s, table=0, n_packets=0, 
n_bytes=0, priority=2,in_port=1 actions=drop 
cookie=0x9118e6e52dd3dfa0, duration=42858.804s, table=0, n_packets=10993, 
n_bytes=2219925, priority=9,in_port=9 actions=resubmit(,25) 
cookie=0x9118e6e52dd3dfa0, duration=42250.774s, table=0, n_packets=22275, 
n_bytes=4028172, priority=9,in_port=10 actions=resubmit(,25) 
cookie=0x9118e6e52dd3dfa0, duration=37845.822s, table=0, n_packets=9967, 
n_bytes=1989597, priority=9,in_port=12 actions=resubmit(,25) 
cookie=0x9118e6e52dd3dfa0, duration=37617.828s, table=0, n_packets=11154, 
n_bytes=2154155, priority=9,in_port=13 actions=resubmit(,25) 
cookie=0x9118e6e52dd3dfa0, duration=45268.699s, table=0, n_packets=14048, 
n_bytes=1104503, priority=3,in_port=1,vlan_tci=0x/0x1fff 
actions=push_vlan:0x8100,set_field:4098->vlan_vid,NORMAL 
cookie=0x9118e6e52dd3dfa0, duration=45302.314s, table=0, n_packets=24842, 
n_bytes=2954751, priority=0 actions=NORMAL 
cookie=0x9118e6e52dd3dfa0, duration=34624.792s, table=5, n_packets=399, 
n_bytes=39102, priority=0,ip,dl_dst=fa:16:3e:12:7e:50 
actions=push_mpls:0x8847,set_field:65791->mpls_label,set_mpls_ttl(255),push_vlan:0x8100,set_field:4099->vlan_vid,resubmit(,10)
 
cookie=0x9118e6e52dd3dfa0, duration=34624.649s, table=10, n_packets=399, 
n_bytes=39102, 
priority=1,mpls,dl_vlan=3,dl_dst=fa:16:3e:12:7e:50,mpls_label=65791 
actions=pop_vlan,pop_mpls:0x0800,output:10 
cookie=0x9118e6e52dd3dfa0, duration=45300.979s, table=10, n_packets=0, 
n_bytes=0, priority=0 actions=drop 
cookie=0x9118e6e52dd3dfa0, duration=45302.309s, table=23, n_packets=0, 
n_bytes=0, priority=0 actions=drop 
cookie=0x9118e6e52dd3dfa0, duration=42858.796s, table=24, n_packets=0, 
n_bytes=0, 
priority=2,icmp6,in_port=9,icmp_type=136,nd_target=fe80::f816:3eff:fed8:8f28 
actions=NORMAL 
cookie=0x9118e6e52dd3dfa0, duration=42250.752s, table=24, n_packets=0, 
n_bytes=0, 
priority=2,icmp6,in_port=10,icmp_type=136,nd_target=fe80::f816:3eff:fe12:7e50 
actions=NORMAL 
cookie=0x9118e6e52dd3dfa0, duration=37845.802s, table=24, n_packets=0, 

Re: [openstack-dev] [networking-sfc] Newton release plans?

[Cathy Zhang]

Hi James,

Networking-sfc will release Newton version after Neutron pull the stable/Newton 
branch (around late Oct. and Early Nov time frame).
Basically after the branch is pulled, we will make sure all unit, functional, 
tempest tests including multi-node end-to-end tests against stable/Newton 
branch are passed, and then will do the release.

Thanks,
Cathy

From: James Page [mailto:james.p...@canonical.com]
Sent: Monday, August 08, 2016 2:08 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [networking-sfc] Newton release plans?

Hi Networking SFC team

I'm trying to get a view on a few Neutron related projects with the objective 
of lining up a release in Ubuntu and Debian alongside OpenStack Newton of 
vmware-nsx, networking-l2gw, networking-sfc and tap-as-a-service.

What are your plans for Newton? I can push snapshots into Debian/Ubuntu during 
development, but it would be nice to know at what point in time networking-sfc 
will release a version for Newton so we don't end up with a dangling snapshot 
of networking-sfc after the release of Ubuntu 16.10 and OpenStack Newton.

Cheers

James
__
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-dev] [networking-sfc] Newton release plans?

[James Page]

Hi Networking SFC team

I'm trying to get a view on a few Neutron related projects with the
objective of lining up a release in Ubuntu and Debian alongside OpenStack
Newton of vmware-nsx, networking-l2gw, networking-sfc and tap-as-a-service.

What are your plans for Newton? I can push snapshots into Debian/Ubuntu
during development, but it would be nice to know at what point in time
networking-sfc will release a version for Newton so we don't end up with a
dangling snapshot of networking-sfc after the release of Ubuntu 16.10 and
OpenStack Newton.

Cheers

James
__
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

Re: [openstack-dev] networking-sfc: unable to use SFC (ovs driver) with multiple networks

[Na Zhu]

Hi MartinX,

I think you can move p2 to net1 and p3 to net4, or you can put p1, p2, p3 
and p4 in the same network.



Regards,
Juno Zhu
IBM China Development Labs (CDL) Cloud IaaS Lab
Email: na...@cn.ibm.com
5F, Building 10, 399 Keyuan Road, Zhangjiang Hi-Tech Park, Pudong New 
District, Shanghai, China (201203)



From:   Cathy Zhang <cathy.h.zh...@huawei.com>
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>, "martinx.bans...@intel.com" 
<martinx.bans...@intel.com>
Date:   2016/06/22 02:36
Subject:    Re: [openstack-dev] networking-sfc: unable to use SFC (ovs 
driver) with multiple networks



Hi MartinX,

I sent you a reply on 6/14. 

Cathy

-Original Message-
From: Banszel, MartinX [mailto:martinx.bans...@intel.com] 
Sent: Thursday, June 16, 2016 4:49 AM
To: 'openstack-dev@lists.openstack.org'
Subject: [openstack-dev] networking-sfc: unable to use SFC (ovs driver) 
with multiple networks

Hello,

I'd need some help with using the SFC implementation in openstack.

I use liberty version of devstack + liberty branch of networking-sfc.

It's not clear to me if the SFC instance and it's networks should be 
separated from the remaining virtual network topology or if it should be 
connected to it.

E.g. consider the following topology, where SFC and its networks net2 and 
net3 (one for ingress port, one for egress port) are connected to the 
tenants networks. I know that all three instances can share one network 
but a use case I am trying to implement requires that every instance has 
it's separated network and there is a different network for ingress and 
egress port of the SF.

 +---+ +-+ +---+
 | VMSRC | |  VMSFC  | | VMDST |
 +---+---+ +--+---+--+ +---+---+
 | p1 (1.1.1.1) p2|   |p3  |p4 
(4.4.4.4)
 ||   ||
-++--- net1   |   |  --+---+- 
net4
  |   |   ||
  |  ---+-+---) net2   |
  |  ---)--+--+ net3   |
  | |  |   |
  |  +--+--+--+|
  +--+ ROUTER ++
 ++


All networks are connected to a single router ROUTER. I created a flow 
classifier that matches all traffic going from VMSRC to VMDST 
(--logical-source-port p1 --source-ip-prefix=1.1.1.1/32 
--destination-ip-prefix=4.4.4.4/32), port pair p2,p3, a port pair group 
containing this port pair and a port chain containing this port pair group 
and flow classifier.

If I try to ping from VMSRC the 5.4.4.4 address, it is correctly steered 
through the VMSFC (where just the ip_forwarding is set to 1) and forwarded 
back through the p3 port to the ROUTER.  The router finds out that there 
are packets with source address 1.1.1.1 coming from port where is should 
not (the router expects those packets from the net1 interface), they don't 
pass the reverse path filter and the router drops them.

It works when I set the rp_filter off via sysctl command in the router 
namespace on the controller. But I don't want to do this -- I expect the 
sfc to work without such changes.

Is such topology supported? What should the topology look like?

I have noticed, that when I disconnect the net2 and net3 from the ROUTER, 
and add new routers ROUTER2 and ROUTER3 to the net2 and net3 networks 
respectivelly and don't connect them anyhow to the ROUTER nor the rest of 
the topology, the OVS is able to send the traffic to the p2 port on the 
ingress side. However, on the egress side the packet is routed to the 
ROUTER3 which drops it as it doesn't have any route for it.

Thanks for any hints!

Best regards
Martin Banszel
--
Intel Research and Development Ireland Limited Registered in Ireland 
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare 
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the 
sole use of the intended recipient(s). Any review or distribution by 
others is strictly prohibited. If you are not the intended recipient, 
please contact the sender and delete all copies.


__
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

- Message from Cathy Zhang <cathy.h.zh...@huawei.com> on Wed, 15 Jun 
2016 00:58:33 + -
To:
"OpenStack Development Mailin

Re: [openstack-dev] networking-sfc: unable to use SFC (ovs driver) with multiple networks

[Cathy Zhang]

Hi MartinX,

I sent you a reply on 6/14. 

Cathy

-Original Message-
From: Banszel, MartinX [mailto:martinx.bans...@intel.com] 
Sent: Thursday, June 16, 2016 4:49 AM
To: 'openstack-dev@lists.openstack.org'
Subject: [openstack-dev] networking-sfc: unable to use SFC (ovs driver) with 
multiple networks

Hello,

I'd need some help with using the SFC implementation in openstack.

I use liberty version of devstack + liberty branch of networking-sfc.

It's not clear to me if the SFC instance and it's networks should be separated 
from the remaining virtual network topology or if it should be connected to it.

E.g. consider the following topology, where SFC and its networks net2 and net3 
(one for ingress port, one for egress port) are connected to the tenants 
networks. I know that all three instances can share one network but a use case 
I am trying to implement requires that every instance has it's separated 
network and there is a different network for ingress and egress port of the SF.

 +---+ +-+ +---+
 | VMSRC | |  VMSFC  | | VMDST |
 +---+---+ +--+---+--+ +---+---+
 | p1 (1.1.1.1) p2|   |p3  |p4 (4.4.4.4)
 ||   ||
-++--- net1   |   |  --+---+- net4
  |   |   ||
  |  ---+-+---) net2   |
  |  ---)--+--+ net3   |
  | |  |   |
  |  +--+--+--+|
  +--+ ROUTER ++
 ++


All networks are connected to a single router ROUTER. I created a flow 
classifier that matches all traffic going from VMSRC to VMDST 
(--logical-source-port p1 --source-ip-prefix=1.1.1.1/32 
--destination-ip-prefix=4.4.4.4/32), port pair p2,p3, a port pair group 
containing this port pair and a port chain containing this port pair group and 
flow classifier.

If I try to ping from VMSRC the 5.4.4.4 address, it is correctly steered 
through the VMSFC (where just the ip_forwarding is set to 1) and forwarded back 
through the p3 port to the ROUTER.  The router finds out that there are packets 
with source address 1.1.1.1 coming from port where is should not (the router 
expects those packets from the net1 interface), they don't pass the reverse 
path filter and the router drops them.

It works when I set the rp_filter off via sysctl command in the router 
namespace on the controller. But I don't want to do this -- I expect the sfc to 
work without such changes.

Is such topology supported? What should the topology look like?

I have noticed, that when I disconnect the net2 and net3 from the ROUTER, and 
add new routers ROUTER2 and ROUTER3 to the net2 and net3 networks respectivelly 
and don't connect them anyhow to the ROUTER nor the rest of the topology, the 
OVS is able to send the traffic to the p2 port on the ingress side. However, on 
the egress side the packet is routed to the ROUTER3 which drops it as it 
doesn't have any route for it.

Thanks for any hints!

Best regards
Martin Banszel
--
Intel Research and Development Ireland Limited Registered in Ireland Registered 
Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 
308263


This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). Any review or distribution by others is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender and delete all copies.


__
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
--- Begin Message ---
Hi Banszel,

Please see inline. 

Thanks,
Cathy 

-Original Message-
From: Banszel, MartinX [mailto:martinx.bans...@intel.com] 
Sent: Tuesday, June 14, 2016 9:07 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] networking-sfc: unable to use SFC (ovs driver) with 
multiple networks

Hello,

I'd need some help with using the SFC implementation in openstack.

I use liberty version of devstack + liberty branch of networking-sfc.

It's not clear to me if the SFC instance and it's networks should be separated 
from the remaining virtual network topology or if it should be connected to it.

E.g. consider the following topology, where SFC and its networks net2 and net3 
(one for ingress port, one for egress port) are connected to the tenants 
networks. I know that all three instances can share one network

[openstack-dev] networking-sfc: unable to use SFC (ovs driver) with multiple networks

[Banszel, MartinX]

Hello,

I'd need some help with using the SFC implementation in openstack.

I use liberty version of devstack + liberty branch of networking-sfc.

It's not clear to me if the SFC instance and it's networks should be separated
from the remaining virtual network topology or if it should be connected to it.

E.g. consider the following topology, where SFC and its networks net2 and net3
(one for ingress port, one for egress port) are connected to the tenants
networks. I know that all three instances can share one network but a use case I
am trying to implement requires that every instance has it's separated network
and there is a different network for ingress and egress port of the SF.

 +---+ +-+ +---+
 | VMSRC | |  VMSFC  | | VMDST |
 +---+---+ +--+---+--+ +---+---+
 | p1 (1.1.1.1) p2|   |p3  |p4 (4.4.4.4)
 ||   ||
-++--- net1   |   |  --+---+- net4
  |   |   ||
  |  ---+-+---) net2   |
  |  ---)--+--+ net3   |
  | |  |   |
  |  +--+--+--+|
  +--+ ROUTER ++
 ++


All networks are connected to a single router ROUTER. I created a flow
classifier that matches all traffic going from VMSRC to VMDST
(--logical-source-port p1 --source-ip-prefix=1.1.1.1/32
--destination-ip-prefix=4.4.4.4/32), port pair p2,p3, a port pair group
containing this port pair and a port chain containing this port pair group and
flow classifier.

If I try to ping from VMSRC the 5.4.4.4 address, it is correctly steered through
the VMSFC (where just the ip_forwarding is set to 1) and forwarded back through
the p3 port to the ROUTER.  The router finds out that there are packets with
source address 1.1.1.1 coming from port where is should not (the router expects
those packets from the net1 interface), they don't pass the reverse path filter
and the router drops them.

It works when I set the rp_filter off via sysctl command in the router namespace
on the controller. But I don't want to do this -- I expect the sfc to work
without such changes.

Is such topology supported? What should the topology look like?

I have noticed, that when I disconnect the net2 and net3 from the ROUTER, and
add new routers ROUTER2 and ROUTER3 to the net2 and net3 networks respectivelly
and don't connect them anyhow to the ROUTER nor the rest of the topology, the
OVS is able to send the traffic to the p2 port on the ingress side. However, on
the egress side the packet is routed to the ROUTER3 which drops it as it doesn't
have any route for it.

Thanks for any hints!

Best regards
Martin Banszel
--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.


__
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

Re: [openstack-dev] networking-sfc: unable to use SFC (ovs driver) with multiple networks

[Cathy Zhang]

Hi Banszel,

Please see inline. 

Thanks,
Cathy 

-Original Message-
From: Banszel, MartinX [mailto:martinx.bans...@intel.com] 
Sent: Tuesday, June 14, 2016 9:07 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] networking-sfc: unable to use SFC (ovs driver) with 
multiple networks

Hello,

I'd need some help with using the SFC implementation in openstack.

I use liberty version of devstack + liberty branch of networking-sfc.

It's not clear to me if the SFC instance and it's networks should be separated 
from the remaining virtual network topology or if it should be connected to it.

E.g. consider the following topology, where SFC and its networks net2 and net3 
(one for ingress port, one for egress port) are connected to the tenants 
networks. I know that all three instances can share one network but a use case 
I am trying to implement requires that every instance has it's separated 
network and there is a different network for ingress and egress port of the SF.

 +---+ +-+ +---+
 | VMSRC | |  VMSFC  | | VMDST |
 +---+---+ +--+---+--+ +---+---+
 | p1 (1.1.1.1) p2|   |p3  |p4 (4.4.4.4)
 ||   ||
-++--- net1   |   |  --+---+- net4
  |   |   ||
  |  ---+-+---) net2   |
  |  ---)--+--+ net3   |
  | |  |   |
  |  +--+--+--+|
  +--+ ROUTER ++
 ++


All networks are connected to a single router ROUTER. I created a flow 
classifier that matches all traffic going from VMSRC to VMDST 
(--logical-source-port p1 --source-ip-prefix=1.1.1.1/32 
--destination-ip-prefix=4.4.4.4/32), port pair p2,p3, a port pair group 
containing this port pair and a port chain containing this port pair group and 
flow classifier.

If I try to ping from VMSRC the 5.4.4.4 address, it is correctly steered 
through the VMSFC (where just the ip_forwarding is set to 1) and forwarded back 
through the p3 port to the ROUTER.  The router finds out that there are packets 
with source address 1.1.1.1 coming from port where is should not (the router 
expects those packets from the net1 interface), they don't pass the reverse 
path filter and the router drops them.

It works when I set the rp_filter off via sysctl command in the router 
namespace on the controller. But I don't want to do this -- I expect the sfc to 
work without such changes.

Is such topology supported? What should the topology look like?

Cathy> No, current networking-sfc does not support this topology. 

I have noticed, that when I disconnect the net2 and net3 from the ROUTER, and 
add new routers ROUTER2 and ROUTER3 to the net2 and net3 networks respectivelly 
and don't connect them anyhow to the ROUTER nor the rest of the topology, the 
OVS is able to send the traffic to the p2 port on the ingress side. However, on 
the egress side the packet is routed to the ROUTER3 which drops it as it 
doesn't have any route for it.
Cathy> Router3 will not have any rule to forward the packet since 
networking-sfc does not install any new forwarding rules into a Router, that is 
why it is dropped. Anyway the current implementation does not have proper 
support for chain across multiple subnets. If you put VMSRC and VMSFC in the 
same subnet and VMDST in another subnet, it should work. 

Thanks for any hints!

Best regards
Martin Banszel
--
Intel Research and Development Ireland Limited Registered in Ireland Registered 
Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 
308263


This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). Any review or distribution by others is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender and delete all copies.


__
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

[openstack-dev] networking-sfc: unable to use SFC (ovs driver) with multiple networks

[Banszel, MartinX]

Hello,

I'd need some help with using the SFC implementation in openstack.

I use liberty version of devstack + liberty branch of networking-sfc.

It's not clear to me if the SFC instance and it's networks should be separated
from the remaining virtual network topology or if it should be connected to it.

E.g. consider the following topology, where SFC and its networks net2 and net3
(one for ingress port, one for egress port) are connected to the tenants
networks. I know that all three instances can share one network but a use case I
am trying to implement requires that every instance has it's separated network
and there is a different network for ingress and egress port of the SF.

 +---+ +-+ +---+
 | VMSRC | |  VMSFC  | | VMDST |
 +---+---+ +--+---+--+ +---+---+
 | p1 (1.1.1.1) p2|   |p3  |p4 (4.4.4.4)
 ||   ||
-++--- net1   |   |  --+---+- net4
  |   |   ||
  |  ---+-+---) net2   |
  |  ---)--+--+ net3   |
  | |  |   |
  |  +--+--+--+|
  +--+ ROUTER ++
 ++


All networks are connected to a single router ROUTER. I created a flow
classifier that matches all traffic going from VMSRC to VMDST
(--logical-source-port p1 --source-ip-prefix=1.1.1.1/32
--destination-ip-prefix=4.4.4.4/32), port pair p2,p3, a port pair group
containing this port pair and a port chain containing this port pair group and
flow classifier.

If I try to ping from VMSRC the 5.4.4.4 address, it is correctly steered through
the VMSFC (where just the ip_forwarding is set to 1) and forwarded back through
the p3 port to the ROUTER.  The router finds out that there are packets with
source address 1.1.1.1 coming from port where is should not (the router expects
those packets from the net1 interface), they don't pass the reverse path filter
and the router drops them.

It works when I set the rp_filter off via sysctl command in the router namespace
on the controller. But I don't want to do this -- I expect the sfc to work
without such changes.

Is such topology supported? What should the topology look like?

I have noticed, that when I disconnect the net2 and net3 from the ROUTER, and
add new routers ROUTER2 and ROUTER3 to the net2 and net3 networks respectivelly
and don't connect them anyhow to the ROUTER nor the rest of the topology, the
OVS is able to send the traffic to the p2 port on the ingress side. However, on
the egress side the packet is routed to the ROUTER3 which drops it as it doesn't
have any route for it.

Thanks for any hints!

Best regards
Martin Banszel
--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.


__
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

Re: [openstack-dev] [networking-sfc] how to install networking-sfc on compute node

[Mohan Kumar]

Juno Zhu ,

Please check this wiki  link :
https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining#Multi-Host_Installation

Thanks.,
Mohankumar.N


On Fri, Jun 3, 2016 at 12:43 PM, Na Zhu <na...@cn.ibm.com> wrote:

> Yes, but networking-sfc rewrite the q-agt binary file, when i install
> networking-sfc in allinone mode, the q-aget binary file is:
> juno@sfc:~/devstack$ cat /usr/local/bin/neutron-openvswitch-agent
> #!/usr/bin/python
> # PBR Generated from u'console_scripts'
>
> import sys
>
> from networking_sfc.services.sfc.agent.agent import main
>
>
> if __name__ == "__main__":
> sys.exit(main())
> steve@sfc:~/devstack$
>
>
>
>
>
> Regards,
> Juno Zhu
> IBM China Development Labs (CDL) Cloud IaaS Lab
> Email: na...@cn.ibm.com
> 5F, Building 10, 399 Keyuan Road, Zhangjiang Hi-Tech Park, Pudong New
> District, Shanghai, China (201203)
>
>
>
> From:Vikram Choudhary <viks...@gmail.com>
> To:"OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org>
> Date:2016/06/03 15:05
> Subject:Re: [openstack-dev] [networking-sfc] how to install
> networking-sfc on compute node
> --
>
>
>
>
>
> On Thu, Jun 2, 2016 at 9:11 PM, Na Zhu <*na...@cn.ibm.com*
> <na...@cn.ibm.com>> wrote:
> Hi,
>
> From this link
> *https://github.com/openstack/networking-sfc/tree/master/devstack*
> <https://github.com/openstack/networking-sfc/tree/master/devstack>, it is
> about installing networking-sfc together with neutron-server,
> I want to install networking-sfc on compute node, can anyone tell me how
> to set the local.conf?
> networking-sfc support is only required on the controller node as it uses
> q-agt (ovs driver implementation) for downloading flows to the ovs. By
> default, we already run q-agt on the compute node.
>
>
>
>
> Regards,
> Juno Zhu
> IBM China Development Labs (CDL) Cloud IaaS Lab
> Email: *na...@cn.ibm.com* <na...@cn.ibm.com>
> 5F, Building 10, 399 Keyuan Road, Zhangjiang Hi-Tech Park, Pudong New
> District, Shanghai, China (201203)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> *openstack-dev-requ...@lists.openstack.org?subject:unsubscribe*
> <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
> *http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev*
> <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
>
>
>
> __
> 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

Re: [openstack-dev] [networking-sfc] how to install networking-sfc on compute node

[Na Zhu]

Yes, but networking-sfc rewrite the q-agt binary file, when i install 
networking-sfc in allinone mode, the q-aget binary file is:
juno@sfc:~/devstack$ cat /usr/local/bin/neutron-openvswitch-agent
#!/usr/bin/python
# PBR Generated from u'console_scripts'

import sys

from networking_sfc.services.sfc.agent.agent import main


if __name__ == "__main__":
sys.exit(main())
steve@sfc:~/devstack$ 





Regards,
Juno Zhu
IBM China Development Labs (CDL) Cloud IaaS Lab
Email: na...@cn.ibm.com
5F, Building 10, 399 Keyuan Road, Zhangjiang Hi-Tech Park, Pudong New 
District, Shanghai, China (201203)



From:   Vikram Choudhary <viks...@gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date:   2016/06/03 15:05
Subject:    Re: [openstack-dev] [networking-sfc] how to install 
networking-sfc on compute node





On Thu, Jun 2, 2016 at 9:11 PM, Na Zhu <na...@cn.ibm.com> wrote:
Hi,

>From this link 
https://github.com/openstack/networking-sfc/tree/master/devstack, it is 
about installing networking-sfc together with neutron-server,
I want to install networking-sfc on compute node, can anyone tell me how 
to set the local.conf? 
networking-sfc support is only required on the controller node as it uses 
q-agt (ovs driver implementation) for downloading flows to the ovs. By 
default, we already run q-agt on the compute node.




Regards,
Juno Zhu
IBM China Development Labs (CDL) Cloud IaaS Lab
Email: na...@cn.ibm.com
5F, Building 10, 399 Keyuan Road, Zhangjiang Hi-Tech Park, Pudong New 
District, Shanghai, China (201203)

__
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



__
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

Re: [openstack-dev] [networking-sfc] how to install networking-sfc on compute node

[Vikram Choudhary]

On Thu, Jun 2, 2016 at 9:11 PM, Na Zhu  wrote:

> Hi,
>
> From this link
> https://github.com/openstack/networking-sfc/tree/master/devstack, it is
> about installing networking-sfc together with neutron-server,
> I want to install networking-sfc on compute node, can anyone tell me how
> to set the local.conf?

networking-sfc support is only required on the controller node as it uses
q-agt (ovs driver implementation) for downloading flows to the ovs. By
default, we already run q-agt on the compute node.

>
>
>
>
> Regards,
> Juno Zhu
> IBM China Development Labs (CDL) Cloud IaaS Lab
> Email: na...@cn.ibm.com
> 5F, Building 10, 399 Keyuan Road, Zhangjiang Hi-Tech Park, Pudong New
> District, Shanghai, China (201203)
>
> __
> 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

[openstack-dev] [networking-sfc] how to install networking-sfc on compute node

[Na Zhu]

Hi,

>From this link 
https://github.com/openstack/networking-sfc/tree/master/devstack, it is 
about installing networking-sfc together with neutron-server,
I want to install networking-sfc on compute node, can anyone tell me how 
to set the local.conf? 



Regards,
Juno Zhu
IBM China Development Labs (CDL) Cloud IaaS Lab
Email: na...@cn.ibm.com
5F, Building 10, 399 Keyuan Road, Zhangjiang Hi-Tech Park, Pudong New 
District, Shanghai, China (201203)

__
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