Re: [openstack-dev] [neutron][sfc][fwaas][taas][horizon] where would we like to have horizon dashboard for neutron stadium projects?

[Akihiro Motoki]

Thanks for your feedback, all!
It seems we have a consensus and the route is "(a) dashboard
repository per project".
I would suggest -dashboard as a repository name where  is your
main repo name.


2017-04-11 0:09 GMT+09:00 Akihiro Motoki :
> Hi neutrinos (and horizoners),
>
> As the title says, where would we like to have horizon dashboard for
> neutron stadium projects?
> There are several projects under neutron stadium and they are trying
> to add dashboard support.
>
> I would like to raise this topic again. No dashboard support lands since then.
> Also Horizon team would like to move in-tree neutron stadium dashboard
> (VPNaaS and FWaaS v1 dashboard) to outside of horizon repo.
>
> Possible approaches
> 
>
> Several possible options in my mind:
> (a) dashboard repository per project
> (b) dashboard code in individual project
> (c) a single dashboard repository for all neutron stadium projects
>
> Which one sounds better?
>
> Pros and Cons
> 
>
> (a) dashboard repository per project
>   example, networking-sfc-dashboard repository for networking-sfc
>   Pros
>- Can use existing horizon related project convention and knowledge
>  (directory structure, testing, translation support)
>- Not related to the neutron stadium inclusion. Each project can
> provide its dashboard
>  support regardless of neutron stadium inclusion.
>  Cons
>- An additional repository is needed.
>
> (b) dashboard code in individual project
>   example, dashboard module for networking-sfc
>   Pros:
>- No additional repository
>- Not related to the neutron stadium inclusion. Each project can
> provide its dashboard
>  support regardless of neutron stadium inclusion.
>  Cons:
>- Requires extra efforts to support neutron and horizon codes in a
> single repository
>  for testing and translation supports. Each project needs to
> explore the way.
>
> (c) a single dashboard repository for all neutron stadium projects
>(something like neutron-advanced-dashboard)
>   Pros:
> - No additional repository per project
>   Each project do not need a basic setup for dashboard and
> possible makes things simple.
>   Cons:
> - Inclusion criteria depending on the neutron stadium inclusion/exclusion
>   (Similar discussion happens as for neutronclient OSC plugin)
>   Project before neutron stadium inclusion may need another 
> implementation.
>
>
> My vote is (a) or (c) (to avoid mixing neutron and dashboard codes in a repo).
>
> Note that as dashboard supports for feature in the main neutron repository
> are implemented in the horizon repository as we discussed several months ago.
> As an example, trunk support is being development in the horizon repo.
>
> Thanks,
> Akihiro

__
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] [neutron][sfc][fwaas][taas][horizon] where would we like to have horizon dashboard for neutron stadium projects?

[Akihiro Motoki]

Hi TIm,

I think no user-visible changes happen for users.
Do you have any example in your mind?

I understand horizon lacks supports of some hooks (such as adding a
menu to an existing table).
If there are missing things,

2017-04-12 2:24 GMT+09:00 Tim Bell <tim.b...@cern.ch>:
> Are there any implications for the end user experience by going to different
> repos (such as requiring dedicated menu items)?
>
>
>
> Tim
>
>
>
> From: "Sridar Kandaswamy (skandasw)" <skand...@cisco.com>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org>
> Date: Tuesday, 11 April 2017 at 17:01
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org>
>
>
> Subject: Re: [openstack-dev] [neutron][sfc][fwaas][taas][horizon] where
> would we like to have horizon dashboard for neutron stadium projects?
>
>
>
> Hi All:
>
>
>
> From and FWaaS perspective – we also think (a)  would be ideal.
>
>
>
> Thanks
>
>
>
> Sridar
>
>
>
> From: Kevin Benton <ke...@benton.pub>
> Reply-To: OpenStack List <openstack-dev@lists.openstack.org>
> Date: Monday, April 10, 2017 at 4:20 PM
> To: OpenStack List <openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [neutron][sfc][fwaas][taas][horizon] where
> would we like to have horizon dashboard for neutron stadium projects?
>
>
>
> I think 'a' is probably the way to go since we can mainly rely on existing
> horizon guides for creating new dashboard repos.
>
>
>
> On Apr 10, 2017 08:11, "Akihiro Motoki" <amot...@gmail.com> wrote:
>
> Hi neutrinos (and horizoners),
>
> As the title says, where would we like to have horizon dashboard for
> neutron stadium projects?
> There are several projects under neutron stadium and they are trying
> to add dashboard support.
>
> I would like to raise this topic again. No dashboard support lands since
> then.
> Also Horizon team would like to move in-tree neutron stadium dashboard
> (VPNaaS and FWaaS v1 dashboard) to outside of horizon repo.
>
> Possible approaches
> 
>
> Several possible options in my mind:
> (a) dashboard repository per project
> (b) dashboard code in individual project
> (c) a single dashboard repository for all neutron stadium projects
>
> Which one sounds better?
>
> Pros and Cons
> 
>
> (a) dashboard repository per project
>   example, networking-sfc-dashboard repository for networking-sfc
>   Pros
>- Can use existing horizon related project convention and knowledge
>  (directory structure, testing, translation support)
>- Not related to the neutron stadium inclusion. Each project can
> provide its dashboard
>  support regardless of neutron stadium inclusion.
>  Cons
>- An additional repository is needed.
>
> (b) dashboard code in individual project
>   example, dashboard module for networking-sfc
>   Pros:
>- No additional repository
>- Not related to the neutron stadium inclusion. Each project can
> provide its dashboard
>  support regardless of neutron stadium inclusion.
>  Cons:
>- Requires extra efforts to support neutron and horizon codes in a
> single repository
>  for testing and translation supports. Each project needs to
> explore the way.
>
> (c) a single dashboard repository for all neutron stadium projects
>(something like neutron-advanced-dashboard)
>   Pros:
> - No additional repository per project
>   Each project do not need a basic setup for dashboard and
> possible makes things simple.
>   Cons:
> - Inclusion criteria depending on the neutron stadium
> inclusion/exclusion
>   (Similar discussion happens as for neutronclient OSC plugin)
>   Project before neutron stadium inclusion may need another
> implementation.
>
>
> My vote is (a) or (c) (to avoid mixing neutron and dashboard codes in a
> repo).
>
> Note that as dashboard supports for feature in the main neutron repository
> are implemented in the horizon repository as we discussed several months
> ago.
> As an example, trunk support is being development in the horizon repo.
>
> Thanks,
> Akihiro
>
> __
> 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] [neutron][sfc][fwaas][taas][horizon] where would we like to have horizon dashboard for neutron stadium projects?

[SUZUKI, Kazuhiro]

Hi,

> I think (a) is also good from TaaS dashboard.

This opinion is agreed as a TaaS project.

Regards,
Kaz


From: "SUZUKI, Kazuhiro" <k...@jp.fujitsu.com>
Subject: Re: [openstack-dev] [neutron][sfc][fwaas][taas][horizon] where would 
we like to have horizon dashboard for neutron stadium projects?
Date: Wed, 12 Apr 2017 09:19:42 +0900 (JST)

> Hi,
> 
> I think (a) is also good from TaaS dashboard.
> 
> Regards,
> Kaz
> 
> 
> From: Akihiro Motoki <amot...@gmail.com>
> Subject: [openstack-dev] [neutron][sfc][fwaas][taas][horizon] where would we 
> like to have horizon dashboard for neutron stadium projects?
> Date: Tue, 11 Apr 2017 00:09:10 +0900
> 
>> Hi neutrinos (and horizoners),
>> 
>> As the title says, where would we like to have horizon dashboard for
>> neutron stadium projects?
>> There are several projects under neutron stadium and they are trying
>> to add dashboard support.
>> 
>> I would like to raise this topic again. No dashboard support lands since 
>> then.
>> Also Horizon team would like to move in-tree neutron stadium dashboard
>> (VPNaaS and FWaaS v1 dashboard) to outside of horizon repo.
>> 
>> Possible approaches
>> 
>> 
>> Several possible options in my mind:
>> (a) dashboard repository per project
>> (b) dashboard code in individual project
>> (c) a single dashboard repository for all neutron stadium projects
>> 
>> Which one sounds better?
>> 
>> Pros and Cons
>> 
>> 
>> (a) dashboard repository per project
>>   example, networking-sfc-dashboard repository for networking-sfc
>>   Pros
>>- Can use existing horizon related project convention and knowledge
>>  (directory structure, testing, translation support)
>>- Not related to the neutron stadium inclusion. Each project can
>> provide its dashboard
>>  support regardless of neutron stadium inclusion.
>>  Cons
>>- An additional repository is needed.
>> 
>> (b) dashboard code in individual project
>>   example, dashboard module for networking-sfc
>>   Pros:
>>- No additional repository
>>- Not related to the neutron stadium inclusion. Each project can
>> provide its dashboard
>>  support regardless of neutron stadium inclusion.
>>  Cons:
>>- Requires extra efforts to support neutron and horizon codes in a
>> single repository
>>  for testing and translation supports. Each project needs to
>> explore the way.
>> 
>> (c) a single dashboard repository for all neutron stadium projects
>>(something like neutron-advanced-dashboard)
>>   Pros:
>> - No additional repository per project
>>   Each project do not need a basic setup for dashboard and
>> possible makes things simple.
>>   Cons:
>> - Inclusion criteria depending on the neutron stadium inclusion/exclusion
>>   (Similar discussion happens as for neutronclient OSC plugin)
>>   Project before neutron stadium inclusion may need another 
>> implementation.
>> 
>> 
>> My vote is (a) or (c) (to avoid mixing neutron and dashboard codes in a 
>> repo).
>> 
>> Note that as dashboard supports for feature in the main neutron repository
>> are implemented in the horizon repository as we discussed several months ago.
>> As an example, trunk support is being development in the horizon repo.
>> 
>> Thanks,
>> Akihiro
>> 
>> __
>> 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] [neutron][sfc][fwaas][taas][horizon] where would we like to have horizon dashboard for neutron stadium projects?

[SUZUKI, Kazuhiro]

Hi,

I think (a) is also good from TaaS dashboard.

Regards,
Kaz


From: Akihiro Motoki <amot...@gmail.com>
Subject: [openstack-dev] [neutron][sfc][fwaas][taas][horizon] where would we 
like to have horizon dashboard for neutron stadium projects?
Date: Tue, 11 Apr 2017 00:09:10 +0900

> Hi neutrinos (and horizoners),
> 
> As the title says, where would we like to have horizon dashboard for
> neutron stadium projects?
> There are several projects under neutron stadium and they are trying
> to add dashboard support.
> 
> I would like to raise this topic again. No dashboard support lands since then.
> Also Horizon team would like to move in-tree neutron stadium dashboard
> (VPNaaS and FWaaS v1 dashboard) to outside of horizon repo.
> 
> Possible approaches
> 
> 
> Several possible options in my mind:
> (a) dashboard repository per project
> (b) dashboard code in individual project
> (c) a single dashboard repository for all neutron stadium projects
> 
> Which one sounds better?
> 
> Pros and Cons
> 
> 
> (a) dashboard repository per project
>   example, networking-sfc-dashboard repository for networking-sfc
>   Pros
>- Can use existing horizon related project convention and knowledge
>  (directory structure, testing, translation support)
>- Not related to the neutron stadium inclusion. Each project can
> provide its dashboard
>  support regardless of neutron stadium inclusion.
>  Cons
>- An additional repository is needed.
> 
> (b) dashboard code in individual project
>   example, dashboard module for networking-sfc
>   Pros:
>- No additional repository
>- Not related to the neutron stadium inclusion. Each project can
> provide its dashboard
>  support regardless of neutron stadium inclusion.
>  Cons:
>- Requires extra efforts to support neutron and horizon codes in a
> single repository
>  for testing and translation supports. Each project needs to
> explore the way.
> 
> (c) a single dashboard repository for all neutron stadium projects
>(something like neutron-advanced-dashboard)
>   Pros:
> - No additional repository per project
>   Each project do not need a basic setup for dashboard and
> possible makes things simple.
>   Cons:
> - Inclusion criteria depending on the neutron stadium inclusion/exclusion
>   (Similar discussion happens as for neutronclient OSC plugin)
>   Project before neutron stadium inclusion may need another 
> implementation.
> 
> 
> My vote is (a) or (c) (to avoid mixing neutron and dashboard codes in a repo).
> 
> Note that as dashboard supports for feature in the main neutron repository
> are implemented in the horizon repository as we discussed several months ago.
> As an example, trunk support is being development in the horizon repo.
> 
> Thanks,
> Akihiro
> 
> __
> 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] [neutron][sfc][fwaas][taas][horizon] where would we like to have horizon dashboard for neutron stadium projects?

[Tim Bell]

Are there any implications for the end user experience by going to different 
repos (such as requiring dedicated menu items)?

Tim

From: "Sridar Kandaswamy (skandasw)" <skand...@cisco.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Tuesday, 11 April 2017 at 17:01
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [neutron][sfc][fwaas][taas][horizon] where would 
we like to have horizon dashboard for neutron stadium projects?

Hi All:

From and FWaaS perspective – we also think (a)  would be ideal.

Thanks

Sridar

From: Kevin Benton <ke...@benton.pub<mailto:ke...@benton.pub>>
Reply-To: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Monday, April 10, 2017 at 4:20 PM
To: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron][sfc][fwaas][taas][horizon] where would 
we like to have horizon dashboard for neutron stadium projects?

I think 'a' is probably the way to go since we can mainly rely on existing 
horizon guides for creating new dashboard repos.

On Apr 10, 2017 08:11, "Akihiro Motoki" 
<amot...@gmail.com<mailto:amot...@gmail.com>> wrote:
Hi neutrinos (and horizoners),

As the title says, where would we like to have horizon dashboard for
neutron stadium projects?
There are several projects under neutron stadium and they are trying
to add dashboard support.

I would like to raise this topic again. No dashboard support lands since then.
Also Horizon team would like to move in-tree neutron stadium dashboard
(VPNaaS and FWaaS v1 dashboard) to outside of horizon repo.

Possible approaches


Several possible options in my mind:
(a) dashboard repository per project
(b) dashboard code in individual project
(c) a single dashboard repository for all neutron stadium projects

Which one sounds better?

Pros and Cons


(a) dashboard repository per project
  example, networking-sfc-dashboard repository for networking-sfc
  Pros
   - Can use existing horizon related project convention and knowledge
 (directory structure, testing, translation support)
   - Not related to the neutron stadium inclusion. Each project can
provide its dashboard
 support regardless of neutron stadium inclusion.
 Cons
   - An additional repository is needed.

(b) dashboard code in individual project
  example, dashboard module for networking-sfc
  Pros:
   - No additional repository
   - Not related to the neutron stadium inclusion. Each project can
provide its dashboard
 support regardless of neutron stadium inclusion.
 Cons:
   - Requires extra efforts to support neutron and horizon codes in a
single repository
 for testing and translation supports. Each project needs to
explore the way.

(c) a single dashboard repository for all neutron stadium projects
   (something like neutron-advanced-dashboard)
  Pros:
- No additional repository per project
  Each project do not need a basic setup for dashboard and
possible makes things simple.
  Cons:
- Inclusion criteria depending on the neutron stadium inclusion/exclusion
  (Similar discussion happens as for neutronclient OSC plugin)
  Project before neutron stadium inclusion may need another implementation.


My vote is (a) or (c) (to avoid mixing neutron and dashboard codes in a repo).

Note that as dashboard supports for feature in the main neutron repository
are implemented in the horizon repository as we discussed several months ago.
As an example, trunk support is being development in the horizon repo.

Thanks,
Akihiro

__
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
__
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] [neutron][sfc][fwaas][taas][horizon] where would we like to have horizon dashboard for neutron stadium projects?

[Henry Fourie]

Akihiro,
Option (a) would have my vote.
 - Louis

-Original Message-
From: Akihiro Motoki [mailto:amot...@gmail.com] 
Sent: Monday, April 10, 2017 8:09 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [neutron][sfc][fwaas][taas][horizon] where would we 
like to have horizon dashboard for neutron stadium projects?

Hi neutrinos (and horizoners),

As the title says, where would we like to have horizon dashboard for neutron 
stadium projects?
There are several projects under neutron stadium and they are trying to add 
dashboard support.

I would like to raise this topic again. No dashboard support lands since then.
Also Horizon team would like to move in-tree neutron stadium dashboard (VPNaaS 
and FWaaS v1 dashboard) to outside of horizon repo.

Possible approaches


Several possible options in my mind:
(a) dashboard repository per project
(b) dashboard code in individual project
(c) a single dashboard repository for all neutron stadium projects

Which one sounds better?

Pros and Cons


(a) dashboard repository per project
  example, networking-sfc-dashboard repository for networking-sfc
  Pros
   - Can use existing horizon related project convention and knowledge
 (directory structure, testing, translation support)
   - Not related to the neutron stadium inclusion. Each project can provide its 
dashboard
 support regardless of neutron stadium inclusion.
 Cons
   - An additional repository is needed.

(b) dashboard code in individual project
  example, dashboard module for networking-sfc
  Pros:
   - No additional repository
   - Not related to the neutron stadium inclusion. Each project can provide its 
dashboard
 support regardless of neutron stadium inclusion.
 Cons:
   - Requires extra efforts to support neutron and horizon codes in a single 
repository
 for testing and translation supports. Each project needs to explore the 
way.

(c) a single dashboard repository for all neutron stadium projects
   (something like neutron-advanced-dashboard)
  Pros:
- No additional repository per project
  Each project do not need a basic setup for dashboard and possible makes 
things simple.
  Cons:
- Inclusion criteria depending on the neutron stadium inclusion/exclusion
  (Similar discussion happens as for neutronclient OSC plugin)
  Project before neutron stadium inclusion may need another implementation.


My vote is (a) or (c) (to avoid mixing neutron and dashboard codes in a repo).

Note that as dashboard supports for feature in the main neutron repository are 
implemented in the horizon repository as we discussed several months ago.
As an example, trunk support is being development in the horizon repo.

Thanks,
Akihiro

__
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] [neutron][sfc][fwaas][taas][horizon] where would we like to have horizon dashboard for neutron stadium projects?

[Sridar Kandaswamy (skandasw)]

Hi All:

>From and FWaaS perspective - we also think (a)  would be ideal.

Thanks

Sridar

From: Kevin Benton <ke...@benton.pub<mailto:ke...@benton.pub>>
Reply-To: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Monday, April 10, 2017 at 4:20 PM
To: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron][sfc][fwaas][taas][horizon] where would 
we like to have horizon dashboard for neutron stadium projects?

I think 'a' is probably the way to go since we can mainly rely on existing 
horizon guides for creating new dashboard repos.

On Apr 10, 2017 08:11, "Akihiro Motoki" 
<amot...@gmail.com<mailto:amot...@gmail.com>> wrote:
Hi neutrinos (and horizoners),

As the title says, where would we like to have horizon dashboard for
neutron stadium projects?
There are several projects under neutron stadium and they are trying
to add dashboard support.

I would like to raise this topic again. No dashboard support lands since then.
Also Horizon team would like to move in-tree neutron stadium dashboard
(VPNaaS and FWaaS v1 dashboard) to outside of horizon repo.

Possible approaches


Several possible options in my mind:
(a) dashboard repository per project
(b) dashboard code in individual project
(c) a single dashboard repository for all neutron stadium projects

Which one sounds better?

Pros and Cons


(a) dashboard repository per project
  example, networking-sfc-dashboard repository for networking-sfc
  Pros
   - Can use existing horizon related project convention and knowledge
 (directory structure, testing, translation support)
   - Not related to the neutron stadium inclusion. Each project can
provide its dashboard
 support regardless of neutron stadium inclusion.
 Cons
   - An additional repository is needed.

(b) dashboard code in individual project
  example, dashboard module for networking-sfc
  Pros:
   - No additional repository
   - Not related to the neutron stadium inclusion. Each project can
provide its dashboard
 support regardless of neutron stadium inclusion.
 Cons:
   - Requires extra efforts to support neutron and horizon codes in a
single repository
 for testing and translation supports. Each project needs to
explore the way.

(c) a single dashboard repository for all neutron stadium projects
   (something like neutron-advanced-dashboard)
  Pros:
- No additional repository per project
  Each project do not need a basic setup for dashboard and
possible makes things simple.
  Cons:
- Inclusion criteria depending on the neutron stadium inclusion/exclusion
  (Similar discussion happens as for neutronclient OSC plugin)
  Project before neutron stadium inclusion may need another implementation.


My vote is (a) or (c) (to avoid mixing neutron and dashboard codes in a repo).

Note that as dashboard supports for feature in the main neutron repository
are implemented in the horizon repository as we discussed several months ago.
As an example, trunk support is being development in the horizon repo.

Thanks,
Akihiro

__
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
__
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] [neutron][sfc][fwaas][taas][horizon] where would we like to have horizon dashboard for neutron stadium projects?

[Kevin Benton]

I think 'a' is probably the way to go since we can mainly rely on existing
horizon guides for creating new dashboard repos.

On Apr 10, 2017 08:11, "Akihiro Motoki"  wrote:

> Hi neutrinos (and horizoners),
>
> As the title says, where would we like to have horizon dashboard for
> neutron stadium projects?
> There are several projects under neutron stadium and they are trying
> to add dashboard support.
>
> I would like to raise this topic again. No dashboard support lands since
> then.
> Also Horizon team would like to move in-tree neutron stadium dashboard
> (VPNaaS and FWaaS v1 dashboard) to outside of horizon repo.
>
> Possible approaches
> 
>
> Several possible options in my mind:
> (a) dashboard repository per project
> (b) dashboard code in individual project
> (c) a single dashboard repository for all neutron stadium projects
>
> Which one sounds better?
>
> Pros and Cons
> 
>
> (a) dashboard repository per project
>   example, networking-sfc-dashboard repository for networking-sfc
>   Pros
>- Can use existing horizon related project convention and knowledge
>  (directory structure, testing, translation support)
>- Not related to the neutron stadium inclusion. Each project can
> provide its dashboard
>  support regardless of neutron stadium inclusion.
>  Cons
>- An additional repository is needed.
>
> (b) dashboard code in individual project
>   example, dashboard module for networking-sfc
>   Pros:
>- No additional repository
>- Not related to the neutron stadium inclusion. Each project can
> provide its dashboard
>  support regardless of neutron stadium inclusion.
>  Cons:
>- Requires extra efforts to support neutron and horizon codes in a
> single repository
>  for testing and translation supports. Each project needs to
> explore the way.
>
> (c) a single dashboard repository for all neutron stadium projects
>(something like neutron-advanced-dashboard)
>   Pros:
> - No additional repository per project
>   Each project do not need a basic setup for dashboard and
> possible makes things simple.
>   Cons:
> - Inclusion criteria depending on the neutron stadium
> inclusion/exclusion
>   (Similar discussion happens as for neutronclient OSC plugin)
>   Project before neutron stadium inclusion may need another
> implementation.
>
>
> My vote is (a) or (c) (to avoid mixing neutron and dashboard codes in a
> repo).
>
> Note that as dashboard supports for feature in the main neutron repository
> are implemented in the horizon repository as we discussed several months
> ago.
> As an example, trunk support is being development in the horizon repo.
>
> Thanks,
> Akihiro
>
> __
> 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] [neutron][sfc][fwaas][taas][horizon] where would we like to have horizon dashboard for neutron stadium projects?

[Doug Hellmann]

Excerpts from Akihiro Motoki's message of 2017-04-11 00:09:10 +0900:
> Hi neutrinos (and horizoners),
> 
> As the title says, where would we like to have horizon dashboard for
> neutron stadium projects?
> There are several projects under neutron stadium and they are trying
> to add dashboard support.
> 
> I would like to raise this topic again. No dashboard support lands since then.
> Also Horizon team would like to move in-tree neutron stadium dashboard
> (VPNaaS and FWaaS v1 dashboard) to outside of horizon repo.
> 
> Possible approaches
> 
> 
> Several possible options in my mind:
> (a) dashboard repository per project
> (b) dashboard code in individual project
> (c) a single dashboard repository for all neutron stadium projects
> 
> Which one sounds better?
> 
> Pros and Cons
> 
> 
> (a) dashboard repository per project
>   example, networking-sfc-dashboard repository for networking-sfc
>   Pros
>- Can use existing horizon related project convention and knowledge
>  (directory structure, testing, translation support)
>- Not related to the neutron stadium inclusion. Each project can
> provide its dashboard
>  support regardless of neutron stadium inclusion.
>  Cons
>- An additional repository is needed.
> 
> (b) dashboard code in individual project
>   example, dashboard module for networking-sfc
>   Pros:
>- No additional repository
>- Not related to the neutron stadium inclusion. Each project can
> provide its dashboard
>  support regardless of neutron stadium inclusion.
>  Cons:
>- Requires extra efforts to support neutron and horizon codes in a
> single repository
>  for testing and translation supports. Each project needs to
> explore the way.
> 
> (c) a single dashboard repository for all neutron stadium projects
>(something like neutron-advanced-dashboard)
>   Pros:
> - No additional repository per project
>   Each project do not need a basic setup for dashboard and
> possible makes things simple.
>   Cons:
> - Inclusion criteria depending on the neutron stadium inclusion/exclusion
>   (Similar discussion happens as for neutronclient OSC plugin)
>   Project before neutron stadium inclusion may need another 
> implementation.
> 
> 
> My vote is (a) or (c) (to avoid mixing neutron and dashboard codes in a repo).
> 
> Note that as dashboard supports for feature in the main neutron repository
> are implemented in the horizon repository as we discussed several months ago.
> As an example, trunk support is being development in the horizon repo.
> 
> Thanks,
> Akihiro
> 

From the release team's perspective, we would prefer (a), because
having one deliverable per package simplifies packaging and makes
more sense for deployments (no one would end up with dashboard
panels for features not supported by the backend).

Doug

__
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] [neutron][sfc][fwaas][taas][horizon] where would we like to have horizon dashboard for neutron stadium projects?

[Akihiro Motoki]

Hi neutrinos (and horizoners),

As the title says, where would we like to have horizon dashboard for
neutron stadium projects?
There are several projects under neutron stadium and they are trying
to add dashboard support.

I would like to raise this topic again. No dashboard support lands since then.
Also Horizon team would like to move in-tree neutron stadium dashboard
(VPNaaS and FWaaS v1 dashboard) to outside of horizon repo.

Possible approaches


Several possible options in my mind:
(a) dashboard repository per project
(b) dashboard code in individual project
(c) a single dashboard repository for all neutron stadium projects

Which one sounds better?

Pros and Cons


(a) dashboard repository per project
  example, networking-sfc-dashboard repository for networking-sfc
  Pros
   - Can use existing horizon related project convention and knowledge
 (directory structure, testing, translation support)
   - Not related to the neutron stadium inclusion. Each project can
provide its dashboard
 support regardless of neutron stadium inclusion.
 Cons
   - An additional repository is needed.

(b) dashboard code in individual project
  example, dashboard module for networking-sfc
  Pros:
   - No additional repository
   - Not related to the neutron stadium inclusion. Each project can
provide its dashboard
 support regardless of neutron stadium inclusion.
 Cons:
   - Requires extra efforts to support neutron and horizon codes in a
single repository
 for testing and translation supports. Each project needs to
explore the way.

(c) a single dashboard repository for all neutron stadium projects
   (something like neutron-advanced-dashboard)
  Pros:
- No additional repository per project
  Each project do not need a basic setup for dashboard and
possible makes things simple.
  Cons:
- Inclusion criteria depending on the neutron stadium inclusion/exclusion
  (Similar discussion happens as for neutronclient OSC plugin)
  Project before neutron stadium inclusion may need another implementation.


My vote is (a) or (c) (to avoid mixing neutron and dashboard codes in a repo).

Note that as dashboard supports for feature in the main neutron repository
are implemented in the horizon repository as we discussed several months ago.
As an example, trunk support is being development in the horizon repo.

Thanks,
Akihiro

__
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] [neutron][sfc] stable/ocata version

[Jeffrey Zhang]

great. thanks.

On Tue, Mar 7, 2017 at 3:14 AM, Dariusz Śmigiel 
wrote:

> 2017-03-06 11:27 GMT-06:00 Henry Fourie :
> > Gary,
> >
> >Awaiting approval:
> >
> > https://review.openstack.org/#/c/439200
> >
> > -Louis
> >
> It's merged. Stable branch is created.
>
> __
> 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] [neutron][sfc] stable/ocata version

[Dariusz Śmigiel]

2017-03-06 11:27 GMT-06:00 Henry Fourie :
> Gary,
>
>Awaiting approval:
>
> https://review.openstack.org/#/c/439200
>
> -Louis
>
It's merged. Stable branch is created.

__
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] [neutron][sfc] stable/ocata version

[Henry Fourie]

Gary,
   Awaiting approval:
https://review.openstack.org/#/c/439200

-Louis

From: Gary Kotton [mailto:gkot...@vmware.com]
Sent: Saturday, March 04, 2017 11:01 PM
To: OpenStack List
Subject: [openstack-dev] [neutron][sfc] stable/ocata version

Hi,
We are pretty blocked at the moment with our gating on stable/ocata. This is 
due to the fact that there is no networking-sfc version tagged for ocata.
Is there any ETA for this?
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] [neutron][sfc][release] stable/ocata version

[Gary Kotton]

Great! Thanks for the update

From: "Armando M." <arma...@gmail.com>
Reply-To: OpenStack List <openstack-dev@lists.openstack.org>
Date: Monday, March 6, 2017 at 5:03 PM
To: OpenStack List <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [neutron][sfc][release] stable/ocata version



On 5 March 2017 at 23:24, Ihar Hrachyshka 
<ihrac...@redhat.com<mailto:ihrac...@redhat.com>> wrote:
With https://review.openstack.org/#/c/437699/ in, stadium projects
will no longer have any other option but to follow the common
schedule. That change is new for Pike+ so we may still see some issues
with Ocata release process.

The stable branch for Ocata is being cut in [1]. Everything else that targets 
Pike is a go.

[1] https://review.openstack.org/#/c/439200/


Ihar

On Sun, Mar 5, 2017 at 8:03 PM, Jeffrey Zhang 
<zhang.lei@gmail.com<mailto:zhang.lei@gmail.com>> wrote:
> Add [release] tag in subject.
>
> Do not follow the OpenStack release schedule will cause lots of issues. Like
> requirements changes, patches is merged which should not be merged into
> stable.
>
> It also may break the deploy project release schedule( like Kolla will not
> be
> released until sfc release ocata branch and tag ).
>
> I hope sfc team could follow the OpenStack release schedule, even though it
> may
> cause some cherry-pick, but it is safer and how OpenStack project live.
>
>
> On Sun, Mar 5, 2017 at 3:44 PM, Gary Kotton 
> <gkot...@vmware.com<mailto:gkot...@vmware.com>> wrote:
>>
>> Please note that things are going to start to get messy now – there are
>> changes in neutron that break master and these will affect the cutting of
>> the stable version. One example is https://review.openstack.org/441654
>>
>>
>>
>> So I suggest cutting a stable ASAP and then cherrypicking patches
>>
>>
>>
>> From: Gary Kotton <gkot...@vmware.com<mailto:gkot...@vmware.com>>
>> Reply-To: OpenStack List 
>> <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
>> Date: Sunday, March 5, 2017 at 9:36 AM
>>
>>
>> To: OpenStack List 
>> <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
>> Subject: Re: [openstack-dev] [neutron][sfc] stable/ocata version
>>
>>
>>
>> Thanks!
>>
>>
>>
>> From: Jeffrey Zhang <zhang.lei@gmail.com<mailto:zhang.lei@gmail.com>>
>> Reply-To: OpenStack List 
>> <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
>> Date: Sunday, March 5, 2017 at 9:12 AM
>> To: OpenStack List 
>> <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
>> Subject: Re: [openstack-dev] [neutron][sfc] stable/ocata version
>>
>>
>>
>> This is talked in [0]. sfc team said
>>
>>
>>
>> > we will pull a stable/ocata branch around end of Feb or early March the
>> > latest.
>>
>>
>>
>> [0]
>> http://lists.openstack.org/pipermail/openstack-dev/2017-February/112580.html
>>
>>
>>
>> On Sun, Mar 5, 2017 at 3:01 PM, Gary Kotton 
>> <gkot...@vmware.com<mailto:gkot...@vmware.com>> wrote:
>>
>> Hi,
>>
>> We are pretty blocked at the moment with our gating on stable/ocata. This
>> is due to the fact that there is no networking-sfc version tagged for ocata.
>>
>> Is there any ETA for this?
>>
>> 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<https://urldefense.proofpoint.com/v2/url?u=http-3A__xcodest.me=DwMFaQ=uilaK90D4TOVoH58JNXRgQ=PMrZQUSXojEgJQPh7cZrz1Lvja0OwAstg0U82FalZrw=e9oFxLk6K7GOvDVL0y3uKlSTQHtU9tnXcMGHL46H37I=9fysx1MmSeqhencLNvi8w-M1Ryv8UPPz6Mdx6bUkveA=>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-re

Re: [openstack-dev] [neutron][sfc][release] stable/ocata version

[Armando M.]

On 5 March 2017 at 23:24, Ihar Hrachyshka <ihrac...@redhat.com> wrote:

> With https://review.openstack.org/#/c/437699/ in, stadium projects
> will no longer have any other option but to follow the common
> schedule. That change is new for Pike+ so we may still see some issues
> with Ocata release process.
>

The stable branch for Ocata is being cut in [1]. Everything else that
targets Pike is a go.

[1] https://review.openstack.org/#/c/439200/


> Ihar
>
> On Sun, Mar 5, 2017 at 8:03 PM, Jeffrey Zhang <zhang.lei@gmail.com>
> wrote:
> > Add [release] tag in subject.
> >
> > Do not follow the OpenStack release schedule will cause lots of issues.
> Like
> > requirements changes, patches is merged which should not be merged into
> > stable.
> >
> > It also may break the deploy project release schedule( like Kolla will
> not
> > be
> > released until sfc release ocata branch and tag ).
> >
> > I hope sfc team could follow the OpenStack release schedule, even though
> it
> > may
> > cause some cherry-pick, but it is safer and how OpenStack project live.
> >
> >
> > On Sun, Mar 5, 2017 at 3:44 PM, Gary Kotton <gkot...@vmware.com> wrote:
> >>
> >> Please note that things are going to start to get messy now – there are
> >> changes in neutron that break master and these will affect the cutting
> of
> >> the stable version. One example is https://review.openstack.org/441654
> >>
> >>
> >>
> >> So I suggest cutting a stable ASAP and then cherrypicking patches
> >>
> >>
> >>
> >> From: Gary Kotton <gkot...@vmware.com>
> >> Reply-To: OpenStack List <openstack-dev@lists.openstack.org>
> >> Date: Sunday, March 5, 2017 at 9:36 AM
> >>
> >>
> >> To: OpenStack List <openstack-dev@lists.openstack.org>
> >> Subject: Re: [openstack-dev] [neutron][sfc] stable/ocata version
> >>
> >>
> >>
> >> Thanks!
> >>
> >>
> >>
> >> From: Jeffrey Zhang <zhang.lei@gmail.com>
> >> Reply-To: OpenStack List <openstack-dev@lists.openstack.org>
> >> Date: Sunday, March 5, 2017 at 9:12 AM
> >> To: OpenStack List <openstack-dev@lists.openstack.org>
> >> Subject: Re: [openstack-dev] [neutron][sfc] stable/ocata version
> >>
> >>
> >>
> >> This is talked in [0]. sfc team said
> >>
> >>
> >>
> >> > we will pull a stable/ocata branch around end of Feb or early March
> the
> >> > latest.
> >>
> >>
> >>
> >> [0]
> >> http://lists.openstack.org/pipermail/openstack-dev/2017-Febr
> uary/112580.html
> >>
> >>
> >>
> >> On Sun, Mar 5, 2017 at 3:01 PM, Gary Kotton <gkot...@vmware.com> wrote:
> >>
> >> Hi,
> >>
> >> We are pretty blocked at the moment with our gating on stable/ocata.
> This
> >> is due to the fact that there is no networking-sfc version tagged for
> ocata.
> >>
> >> Is there any ETA for this?
> >>
> >> Thanks
> >>
> >> Gary
> >>
> >>
> >>
> >>
> >> 
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: openstack-dev-requ...@lists.op
> enstack.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.op
> enstack.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.op
> enstack.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] [neutron][sfc][release] stable/ocata version

[Ihar Hrachyshka]

With https://review.openstack.org/#/c/437699/ in, stadium projects
will no longer have any other option but to follow the common
schedule. That change is new for Pike+ so we may still see some issues
with Ocata release process.

Ihar

On Sun, Mar 5, 2017 at 8:03 PM, Jeffrey Zhang <zhang.lei@gmail.com> wrote:
> Add [release] tag in subject.
>
> Do not follow the OpenStack release schedule will cause lots of issues. Like
> requirements changes, patches is merged which should not be merged into
> stable.
>
> It also may break the deploy project release schedule( like Kolla will not
> be
> released until sfc release ocata branch and tag ).
>
> I hope sfc team could follow the OpenStack release schedule, even though it
> may
> cause some cherry-pick, but it is safer and how OpenStack project live.
>
>
> On Sun, Mar 5, 2017 at 3:44 PM, Gary Kotton <gkot...@vmware.com> wrote:
>>
>> Please note that things are going to start to get messy now – there are
>> changes in neutron that break master and these will affect the cutting of
>> the stable version. One example is https://review.openstack.org/441654
>>
>>
>>
>> So I suggest cutting a stable ASAP and then cherrypicking patches
>>
>>
>>
>> From: Gary Kotton <gkot...@vmware.com>
>> Reply-To: OpenStack List <openstack-dev@lists.openstack.org>
>> Date: Sunday, March 5, 2017 at 9:36 AM
>>
>>
>> To: OpenStack List <openstack-dev@lists.openstack.org>
>> Subject: Re: [openstack-dev] [neutron][sfc] stable/ocata version
>>
>>
>>
>> Thanks!
>>
>>
>>
>> From: Jeffrey Zhang <zhang.lei@gmail.com>
>> Reply-To: OpenStack List <openstack-dev@lists.openstack.org>
>> Date: Sunday, March 5, 2017 at 9:12 AM
>> To: OpenStack List <openstack-dev@lists.openstack.org>
>> Subject: Re: [openstack-dev] [neutron][sfc] stable/ocata version
>>
>>
>>
>> This is talked in [0]. sfc team said
>>
>>
>>
>> > we will pull a stable/ocata branch around end of Feb or early March the
>> > latest.
>>
>>
>>
>> [0]
>> http://lists.openstack.org/pipermail/openstack-dev/2017-February/112580.html
>>
>>
>>
>> On Sun, Mar 5, 2017 at 3:01 PM, Gary Kotton <gkot...@vmware.com> wrote:
>>
>> Hi,
>>
>> We are pretty blocked at the moment with our gating on stable/ocata. This
>> is due to the fact that there is no networking-sfc version tagged for ocata.
>>
>> Is there any ETA for this?
>>
>> 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
>

__
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] [neutron][sfc][release] stable/ocata version

[Jeffrey Zhang]

Add [release] tag in subject.

Do not follow the OpenStack release schedule will cause lots of issues. Like
requirements changes, patches is merged which should not be merged into
stable.

It also may break the deploy project release schedule( like Kolla will not
be
released until sfc release ocata branch and tag ).

I hope sfc team could follow the OpenStack release schedule, even though it
may
cause some cherry-pick, but it is safer and how OpenStack project live.


On Sun, Mar 5, 2017 at 3:44 PM, Gary Kotton <gkot...@vmware.com> wrote:

> Please note that things are going to start to get messy now – there are
> changes in neutron that break master and these will affect the cutting of
> the stable version. One example is https://review.openstack.org/441654
>
>
>
> So I suggest cutting a stable ASAP and then cherrypicking patches
>
>
>
> *From: *Gary Kotton <gkot...@vmware.com>
> *Reply-To: *OpenStack List <openstack-dev@lists.openstack.org>
> *Date: *Sunday, March 5, 2017 at 9:36 AM
>
> *To: *OpenStack List <openstack-dev@lists.openstack.org>
> *Subject: *Re: [openstack-dev] [neutron][sfc] stable/ocata version
>
>
>
> Thanks!
>
>
>
> *From: *Jeffrey Zhang <zhang.lei@gmail.com>
> *Reply-To: *OpenStack List <openstack-dev@lists.openstack.org>
> *Date: *Sunday, March 5, 2017 at 9:12 AM
> *To: *OpenStack List <openstack-dev@lists.openstack.org>
> *Subject: *Re: [openstack-dev] [neutron][sfc] stable/ocata version
>
>
>
> This is talked in [0]. sfc team said
>
>
>
> ​> we will pull a stable/ocata branch around end of Feb or early March the
> latest.
>
>
>
> [0] http://lists.openstack.org/pipermail/openstack-dev/
> 2017-February/112580.html
>
>
>
> On Sun, Mar 5, 2017 at 3:01 PM, Gary Kotton <gkot...@vmware.com> wrote:
>
> Hi,
>
> We are pretty blocked at the moment with our gating on stable/ocata. This
> is due to the fact that there is no networking-sfc version tagged for ocata.
>
> Is there any ETA for this?
>
> 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
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__xcodest.me_=DwMFaQ=uilaK90D4TOVoH58JNXRgQ=PMrZQUSXojEgJQPh7cZrz1Lvja0OwAstg0U82FalZrw=6_isL-K77U2G5VKK49-mlfFOK02rPelnU35II7kFuaA=g3cKOpPjE5Oe13XGD9APDryFCpweg0haylD5oit44Yc=>
>
> __
> 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] [neutron][sfc] stable/ocata version

[Gary Kotton]

Please note that things are going to start to get messy now – there are changes 
in neutron that break master and these will affect the cutting of the stable 
version. One example is https://review.openstack.org/441654

So I suggest cutting a stable ASAP and then cherrypicking patches

From: Gary Kotton <gkot...@vmware.com>
Reply-To: OpenStack List <openstack-dev@lists.openstack.org>
Date: Sunday, March 5, 2017 at 9:36 AM
To: OpenStack List <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [neutron][sfc] stable/ocata version

Thanks!

From: Jeffrey Zhang <zhang.lei@gmail.com>
Reply-To: OpenStack List <openstack-dev@lists.openstack.org>
Date: Sunday, March 5, 2017 at 9:12 AM
To: OpenStack List <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [neutron][sfc] stable/ocata version

This is talked in [0]. sfc team said

​> we will pull a stable/ocata branch around end of Feb or early March the 
latest.

[0] http://lists.openstack.org/pipermail/openstack-dev/2017-February/112580.html

On Sun, Mar 5, 2017 at 3:01 PM, Gary Kotton 
<gkot...@vmware.com<mailto:gkot...@vmware.com>> wrote:
Hi,
We are pretty blocked at the moment with our gating on stable/ocata. This is 
due to the fact that there is no networking-sfc version tagged for ocata.
Is there any ETA for this?
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<https://urldefense.proofpoint.com/v2/url?u=http-3A__xcodest.me_=DwMFaQ=uilaK90D4TOVoH58JNXRgQ=PMrZQUSXojEgJQPh7cZrz1Lvja0OwAstg0U82FalZrw=6_isL-K77U2G5VKK49-mlfFOK02rPelnU35II7kFuaA=g3cKOpPjE5Oe13XGD9APDryFCpweg0haylD5oit44Yc=>
__
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] [neutron][sfc] stable/ocata version

[Gary Kotton]

Thanks!

From: Jeffrey Zhang <zhang.lei@gmail.com>
Reply-To: OpenStack List <openstack-dev@lists.openstack.org>
Date: Sunday, March 5, 2017 at 9:12 AM
To: OpenStack List <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [neutron][sfc] stable/ocata version

This is talked in [0]. sfc team said

​> we will pull a stable/ocata branch around end of Feb or early March the 
latest.

[0] http://lists.openstack.org/pipermail/openstack-dev/2017-February/112580.html

On Sun, Mar 5, 2017 at 3:01 PM, Gary Kotton 
<gkot...@vmware.com<mailto:gkot...@vmware.com>> wrote:
Hi,
We are pretty blocked at the moment with our gating on stable/ocata. This is 
due to the fact that there is no networking-sfc version tagged for ocata.
Is there any ETA for this?
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<https://urldefense.proofpoint.com/v2/url?u=http-3A__xcodest.me_=DwMFaQ=uilaK90D4TOVoH58JNXRgQ=PMrZQUSXojEgJQPh7cZrz1Lvja0OwAstg0U82FalZrw=6_isL-K77U2G5VKK49-mlfFOK02rPelnU35II7kFuaA=g3cKOpPjE5Oe13XGD9APDryFCpweg0haylD5oit44Yc=>
__
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] [neutron][sfc] stable/ocata version

[Jeffrey Zhang]

This is talked in [0]. sfc team said

​> we will pull a stable/ocata branch around end of Feb or early March the
latest.

[0]
http://lists.openstack.org/pipermail/openstack-dev/2017-February/112580.html

On Sun, Mar 5, 2017 at 3:01 PM, Gary Kotton  wrote:

> Hi,
>
> We are pretty blocked at the moment with our gating on stable/ocata. This
> is due to the fact that there is no networking-sfc version tagged for ocata.
>
> Is there any ETA for this?
>
> 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

[openstack-dev] [neutron][sfc] stable/ocata version

[Gary Kotton]

Hi,
We are pretty blocked at the moment with our gating on stable/ocata. This is 
due to the fact that there is no networking-sfc version tagged for ocata.
Is there any ETA for this?
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] [Neutron] SFC stable/mitaka version

[Ihar Hrachyshka]

Akihiro Motoki  wrote:


2016-07-29 18:34 GMT+09:00 Ihar Hrachyshka :

Cathy Zhang  wrote:


Hi Ihar and all,

Yes, we have been preparing for such a release. We will do one more round
of testing to make sure everything works fine, and then I will submit the
release request.
There is a new patch on "stadium: adopt openstack/releases in subproject
release process" which is not Merged yet.
Shall I follow this
http://docs.openstack.org/developer/neutron/stadium/sub_project_guidelines.html#sub-project-release-process
to submit the request?
Do you have a good bug example for Neutron sub-project release request?



For the time being, until the patch landds, you may follow any of those
directions.

An example of a release request bug is:
https://bugs.launchpad.net/networking-bagpipe/+bug/1589502


BTW, a functional and tempest patch for networking-sfc has been uploaded
and it might take some time for the team to complete the review. The  
test is

non-voting. Do you think we should wait until this patch is merged or
release can be done without it?



It would be great to have CI voting, but then, you already lag with the
release for months comparing to release date of Neutron Mitaka, and you  
risk

getting into Phase II support mode before you even release the first
version. If you don’t envision release blocker bugs in the branch, I would
suggest you release the thing and then follow up with bug fixes for  
whatever

you catch later on. In a way, it’s better to release a half baked release
than to not release at all. That’s to follow the ‘release often’ mantra,  
and

boost adoption.


I agree with Ihar, but I think there are several points to be checked
before the release.

- The code should be tested against mitaka version of neutron.
  Currently the master branch of networking-sfc is tested against neutron master
  and we haven't tested it against neutron stable/mitaka after Mitaka
was released.


That’s why we suggest* in devref to release at around same time as neutron:

*  
http://docs.openstack.org/developer/neutron/stadium/sub_project_guidelines.html#stable-branches


"Stable branches for subprojects should be created at the same time when  
corresponding neutron stable branches are created. This is to avoid  
situations when a postponed cut-off results in a stable branch that  
contains some patches that belong to the next release. This would require  
reverting patches, and this is something you should avoid."




- networking-sfc branch already contains newton db migration (see
db/migration/alambic_migrations/versions/newton).
  What I am not sure is whether it needs to be a part of mitaka release or not,
  but you need to be careful when cutting stable/mitaka branch.


Good catch. From alembic perspective, it does not matter where scripts are  
located, so it’s probably minor.


Ihar

__
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] [Neutron] SFC stable/mitaka version

[Akihiro Motoki]

2016-07-29 18:34 GMT+09:00 Ihar Hrachyshka <ihrac...@redhat.com>:
> Cathy Zhang <cathy.h.zh...@huawei.com> wrote:
>
>> Hi Ihar and all,
>>
>> Yes, we have been preparing for such a release. We will do one more round
>> of testing to make sure everything works fine, and then I will submit the
>> release request.
>> There is a new patch on "stadium: adopt openstack/releases in subproject
>> release process" which is not Merged yet.
>> Shall I follow this
>> http://docs.openstack.org/developer/neutron/stadium/sub_project_guidelines.html#sub-project-release-process
>> to submit the request?
>> Do you have a good bug example for Neutron sub-project release request?
>
>
> For the time being, until the patch landds, you may follow any of those
> directions.
>
> An example of a release request bug is:
> https://bugs.launchpad.net/networking-bagpipe/+bug/1589502
>
>>
>> BTW, a functional and tempest patch for networking-sfc has been uploaded
>> and it might take some time for the team to complete the review. The test is
>> non-voting. Do you think we should wait until this patch is merged or
>> release can be done without it?
>
>
> It would be great to have CI voting, but then, you already lag with the
> release for months comparing to release date of Neutron Mitaka, and you risk
> getting into Phase II support mode before you even release the first
> version. If you don’t envision release blocker bugs in the branch, I would
> suggest you release the thing and then follow up with bug fixes for whatever
> you catch later on. In a way, it’s better to release a half baked release
> than to not release at all. That’s to follow the ‘release often’ mantra, and
> boost adoption.

I agree with Ihar, but I think there are several points to be checked
before the release.

- The code should be tested against mitaka version of neutron.
  Currently the master branch of networking-sfc is tested against neutron master
  and we haven't tested it against neutron stable/mitaka after Mitaka
was released.

- networking-sfc branch already contains newton db migration (see
db/migration/alambic_migrations/versions/newton).
  What I am not sure is whether it needs to be a part of mitaka release or not,
  but you need to be careful when cutting stable/mitaka branch.

Thanks,
Akihiro


>
>
>>
>> Thanks,
>> Cathy
>>
>> -----Original Message-
>> From: Ihar Hrachyshka [mailto:ihrac...@redhat.com]
>> Sent: Wednesday, July 27, 2016 1:24 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [Neutron] SFC stable/mitaka version
>>
>> Tony Breeds <t...@bakeyournoodle.com> wrote:
>>
>>> On Wed, Jul 06, 2016 at 12:40:48PM +, Gary Kotton wrote:
>>>>
>>>> Hi,
>>>> Is anyone looking at creating a stable/mitaka version? What if
>>>> someone want to use this for stable/mitaka?
>>>
>>>
>>> If that's a thing you need it's a matter of Armando asking the release
>>> managers to create it.
>>
>>
>> I only suggest Armando is not dragged into it, the release liaison
>> (currently me) should be able to handle the request if it comes from the
>> core team for the subproject.
>>
>> Ihar
>
>
>
>
> __
> 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] [Neutron] SFC stable/mitaka version

[Ihar Hrachyshka]

Cathy Zhang <cathy.h.zh...@huawei.com> wrote:


Hi Ihar and all,

Yes, we have been preparing for such a release. We will do one more round  
of testing to make sure everything works fine, and then I will submit the  
release request.
There is a new patch on "stadium: adopt openstack/releases in subproject  
release process" which is not Merged yet.
Shall I follow this  
http://docs.openstack.org/developer/neutron/stadium/sub_project_guidelines.html#sub-project-release-process  
to submit the request?

Do you have a good bug example for Neutron sub-project release request?


For the time being, until the patch landds, you may follow any of those  
directions.


An example of a release request bug is:  
https://bugs.launchpad.net/networking-bagpipe/+bug/1589502




BTW, a functional and tempest patch for networking-sfc has been uploaded  
and it might take some time for the team to complete the review. The test  
is non-voting. Do you think we should wait until this patch is merged or  
release can be done without it?


It would be great to have CI voting, but then, you already lag with the  
release for months comparing to release date of Neutron Mitaka, and you  
risk getting into Phase II support mode before you even release the first  
version. If you don’t envision release blocker bugs in the branch, I would  
suggest you release the thing and then follow up with bug fixes for  
whatever you catch later on. In a way, it’s better to release a half baked  
release than to not release at all. That’s to follow the ‘release often’  
mantra, and boost adoption.




Thanks,
Cathy

-Original Message-
From: Ihar Hrachyshka [mailto:ihrac...@redhat.com]
Sent: Wednesday, July 27, 2016 1:24 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] SFC stable/mitaka version

Tony Breeds <t...@bakeyournoodle.com> wrote:


On Wed, Jul 06, 2016 at 12:40:48PM +, Gary Kotton wrote:

Hi,
Is anyone looking at creating a stable/mitaka version? What if
someone want to use this for stable/mitaka?


If that's a thing you need it's a matter of Armando asking the release
managers to create it.


I only suggest Armando is not dragged into it, the release liaison  
(currently me) should be able to handle the request if it comes from the  
core team for the subproject.


Ihar




__
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] [Neutron] SFC stable/mitaka version

[Cathy Zhang]

Hi Assaf,

Yes, that makes sense. 

Thanks,
Cathy

-Original Message-
From: Assaf Muller [mailto:as...@redhat.com] 
Sent: Thursday, July 28, 2016 1:06 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] SFC stable/mitaka version

On Thu, Jul 28, 2016 at 3:02 PM, Cathy Zhang <cathy.h.zh...@huawei.com> wrote:
> Hi Ihar and all,
>
> Yes, we have been preparing for such a release. We will do one more round of 
> testing to make sure everything works fine, and then I will submit the 
> release request.
> There is a new patch on "stadium: adopt openstack/releases in subproject 
> release process" which is not Merged yet.
> Shall I follow this 
> http://docs.openstack.org/developer/neutron/stadium/sub_project_guidelines.html#sub-project-release-process
>  to submit the request?
> Do you have a good bug example for Neutron sub-project release request?
>
> BTW, a functional and tempest patch for networking-sfc has been uploaded and 
> it might take some time for the team to complete the review. The test is 
> non-voting. Do you think we should wait until this patch is merged or release 
> can be done without it?

The ideal is that any testing you're doing downstream or manually should be 
happening upstream and via CI. If you feel the need to run things one more time 
then that means that the upstream CI that is running for SFC is insufficient. A 
secondary incentive is to boost adoption - People tend to be attracted to 
stable projects with higher quality testing. I would advise accelerating the 
functional and tempest tests patches and releasing when your CI is in a better 
state.

>
> Thanks,
> Cathy
>
> -Original Message-
> From: Ihar Hrachyshka [mailto:ihrac...@redhat.com]
> Sent: Wednesday, July 27, 2016 1:24 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Neutron] SFC stable/mitaka version
>
> Tony Breeds <t...@bakeyournoodle.com> wrote:
>
>> On Wed, Jul 06, 2016 at 12:40:48PM +, Gary Kotton wrote:
>>> Hi,
>>> Is anyone looking at creating a stable/mitaka version? What if 
>>> someone want to use this for stable/mitaka?
>>
>> If that's a thing you need it's a matter of Armando asking the 
>> release managers to create it.
>
> I only suggest Armando is not dragged into it, the release liaison (currently 
> me) should be able to handle the request if it comes from the core team for 
> the subproject.
>
> Ihar
>
> __
>  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] [Neutron] SFC stable/mitaka version

[Assaf Muller]

On Thu, Jul 28, 2016 at 3:02 PM, Cathy Zhang <cathy.h.zh...@huawei.com> wrote:
> Hi Ihar and all,
>
> Yes, we have been preparing for such a release. We will do one more round of 
> testing to make sure everything works fine, and then I will submit the 
> release request.
> There is a new patch on "stadium: adopt openstack/releases in subproject 
> release process" which is not Merged yet.
> Shall I follow this 
> http://docs.openstack.org/developer/neutron/stadium/sub_project_guidelines.html#sub-project-release-process
>  to submit the request?
> Do you have a good bug example for Neutron sub-project release request?
>
> BTW, a functional and tempest patch for networking-sfc has been uploaded and 
> it might take some time for the team to complete the review. The test is 
> non-voting. Do you think we should wait until this patch is merged or release 
> can be done without it?

The ideal is that any testing you're doing downstream or manually
should be happening upstream and via CI. If you feel the need to run
things one more time then that means that the upstream CI that is
running for SFC is insufficient. A secondary incentive is to boost
adoption - People tend to be attracted to stable projects with higher
quality testing. I would advise accelerating the functional and
tempest tests patches and releasing when your CI is in a better state.

>
> Thanks,
> Cathy
>
> -Original Message-
> From: Ihar Hrachyshka [mailto:ihrac...@redhat.com]
> Sent: Wednesday, July 27, 2016 1:24 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Neutron] SFC stable/mitaka version
>
> Tony Breeds <t...@bakeyournoodle.com> wrote:
>
>> On Wed, Jul 06, 2016 at 12:40:48PM +, Gary Kotton wrote:
>>> Hi,
>>> Is anyone looking at creating a stable/mitaka version? What if
>>> someone want to use this for stable/mitaka?
>>
>> If that's a thing you need it's a matter of Armando asking the release
>> managers to create it.
>
> I only suggest Armando is not dragged into it, the release liaison (currently 
> me) should be able to handle the request if it comes from the core team for 
> the subproject.
>
> Ihar
>
> __
> 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] [Neutron] SFC stable/mitaka version

[Cathy Zhang]

Hi Ihar and all,

Yes, we have been preparing for such a release. We will do one more round of 
testing to make sure everything works fine, and then I will submit the release 
request. 
There is a new patch on "stadium: adopt openstack/releases in subproject 
release process" which is not Merged yet. 
Shall I follow this 
http://docs.openstack.org/developer/neutron/stadium/sub_project_guidelines.html#sub-project-release-process
 to submit the request? 
Do you have a good bug example for Neutron sub-project release request?  

BTW, a functional and tempest patch for networking-sfc has been uploaded and it 
might take some time for the team to complete the review. The test is 
non-voting. Do you think we should wait until this patch is merged or release 
can be done without it? 

Thanks,
Cathy

-Original Message-
From: Ihar Hrachyshka [mailto:ihrac...@redhat.com] 
Sent: Wednesday, July 27, 2016 1:24 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] SFC stable/mitaka version

Tony Breeds <t...@bakeyournoodle.com> wrote:

> On Wed, Jul 06, 2016 at 12:40:48PM +, Gary Kotton wrote:
>> Hi,
>> Is anyone looking at creating a stable/mitaka version? What if 
>> someone want to use this for stable/mitaka?
>
> If that's a thing you need it's a matter of Armando asking the release 
> managers to create it.

I only suggest Armando is not dragged into it, the release liaison (currently 
me) should be able to handle the request if it comes from the core team for the 
subproject.

Ihar

__
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] [Neutron] SFC stable/mitaka version

[Tony Breeds]

On Wed, Jul 27, 2016 at 10:23:30PM +0200, Ihar Hrachyshka wrote:

> I only suggest Armando is not dragged into it, the release liaison
> (currently me) should be able to handle the request if it comes from the
> core team for the subproject.

Good point.  I defaulted to PTL but you're right the release liason is also
totally reasonable.

Yours Tony.


signature.asc
Description: PGP signature
__
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] [Neutron] SFC stable/mitaka version

[Ihar Hrachyshka]

Tony Breeds  wrote:


On Wed, Jul 06, 2016 at 12:40:48PM +, Gary Kotton wrote:

Hi,
Is anyone looking at creating a stable/mitaka version? What if someone  
want

to use this for stable/mitaka?


If that's a thing you need it's a matter of Armando asking the release  
managers

to create it.


I only suggest Armando is not dragged into it, the release liaison  
(currently me) should be able to handle the request if it comes from the  
core team for the subproject.


Ihar


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] [Neutron] SFC stable/mitaka version

[Tony Breeds]

On Wed, Jul 06, 2016 at 12:40:48PM +, Gary Kotton wrote:
> Hi,
> Is anyone looking at creating a stable/mitaka version? What if someone want
> to use this for stable/mitaka?

If that's a thing you need it's a matter of Armando asking the release managers
to create it.

Yours Tony.


signature.asc
Description: PGP signature
__
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] [Neutron] SFC stable/mitaka version

[Gary Kotton]

Hi,
Is anyone looking at creating a stable/mitaka version? What if someone want to 
use this for stable/mitaka?
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] [neutron][SFC]

[Alioune]

>> If you configured chain , the packet to destination VM will go
>>>>>> though all the SF VMs,  say if you execute " ping destiantion-vm-ip"   
>>>>>> the
>>>>>> tcpdump in SF vms should display the  packet counter.
>>>>>>
>>>>>>  Sometimes port_security, security_group will  block the packets to
>>>>>> enter tab interface if the destination ip not its vm ip . So make sure 
>>>>>> you
>>>>>> disabled "security_group"  and "port_security" and  check the same
>>>>>>
>>>>>> neutron port-update  p1 --no-security-groups
>>>>>>
>>>>>> neutron port-update  p1 --port-security-enabled=False
>>>>>>
>>>>>> p1 ==> neutron-port
>>>>>>
>>>>>> Thanks.,
>>>>>> Mohankumar.N
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Jun 13, 2016 at 1:57 PM, Alioune <baliou...@gmail.com> wrote:
>>>>>>
>>>>>>> Hi Mohan,
>>>>>>>
>>>>>>>  could you tell me how did verify that the SFC is correctly working ?
>>>>>>>
>>>>>>> I ran "tcpdump" on SFs' Tap interfaces and tried a connection but
>>>>>>> there was no packet going through these interfaces.
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> On Monday, 13 June 2016, Mohan Kumar <nmohankumar1...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Alioune / nazhu,
>>>>>>>>
>>>>>>>>   Logical-source-port is not mandatory in API , you can create
>>>>>>>> Flow_classifier without logical-source-port , This restriction is 
>>>>>>>> moved to
>>>>>>>> OVS driver . Please refer review link
>>>>>>>> https://review.openstack.org/#/c/313801/5
>>>>>>>>
>>>>>>>>  If your back end driver is OVS , you need to specify the
>>>>>>>> logical-source-port is much needed as per design to avoid the return 
>>>>>>>> packet
>>>>>>>> to reclassified .
>>>>>>>>
>>>>>>>> Thanks.,
>>>>>>>> Mohankumar.N
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Jun 13, 2016 at 7:49 AM, Na Zhu <na...@cn.ibm.com> wrote:
>>>>>>>>
>>>>>>>>> I find this issue also, I filed a bug about it
>>>>>>>>> https://bugs.launchpad.net/networking-sfc/+bug/1586721
>>>>>>>>> I think logical-source-port can be optional.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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:Alioune <baliou...@gmail.com>
>>>>>>>>> To:"OpenStack Development Mailing List (not for usage
>>>>>>>>> questions)" <openstack-dev@lists.openstack.org>
>>>>>>>>> Date:2016/06/10 22:28
>>>>>>>>> Subject:Re: [openstack-dev] [neutron][SFC]
>>>>>>>>> --
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hi Mohan,
>>>>>>>>> Even if I clone the master branch of networking-sfc project,I get
>>>>>>>>> the following errir when creating flow-classifier, therefore I do 
>>>>>>>>> precise
>>>>>>>>

Re: [openstack-dev] [neutron][SFC]

[Na Zhu]

Hi Mohan,

Thanks your information. I see there is restriction check in OVS flow 
classifier driver, but you can see that in the flow classifier table, the 
column logical_source_port nullable is false, this affects every driver.




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:   Mohan Kumar <nmohankumar1...@gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date:   2016/06/13 15:49
Subject:        Re: [openstack-dev] [neutron][SFC]



Hi Alioune / nazhu,

  Logical-source-port is not mandatory in API , you can create 
Flow_classifier without logical-source-port , This restriction is moved to 
OVS driver . Please refer review link  
https://review.openstack.org/#/c/313801/5

 If your back end driver is OVS , you need to specify the 
logical-source-port is much needed as per design to avoid the return 
packet to reclassified .

Thanks.,
Mohankumar.N


On Mon, Jun 13, 2016 at 7:49 AM, Na Zhu <na...@cn.ibm.com> wrote:
I find this issue also, I filed a bug about it 
https://bugs.launchpad.net/networking-sfc/+bug/1586721
I think logical-source-port can be optional.





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:Alioune <baliou...@gmail.com>
To:"OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date:    2016/06/10 22:28
Subject:Re: [openstack-dev] [neutron][SFC]




Hi Mohan,
Even if I clone the master branch of networking-sfc project,I get the 
following errir when creating flow-classifier, therefore I do precise the 
 logical-source-port.

2016-06-10 05:34:05.693 10799 ERROR neutron.api.v2.resource DBError: 
(pymysql.err.IntegrityError) (1048, u"Column 'logical_source_port' cannot 
be null") 
 
I'm trying the example in [1] 

Here is a "ovs-ofctl dump-flows" on br-int ofter creating port-chain, I 
expected to see vxlan or gre tunnel encapsulation entries as explained in 
[1], may I know why there is no tunnel entry in br-int ?

sudo ovs-ofctl dump-flows br-int
NXST_FLOW reply (xid=0x4):
 cookie=0x90444f3c8fabcbe0, duration=2840.983s, table=0, n_packets=0, 
n_bytes=0, idle_age=2840, priority=10,icmp6,in_port=16,icmp_type=136 
actions=resubmit(,24)
 cookie=0x90444f3c8fabcbe0, duration=2837.039s, table=0, n_packets=0, 
n_bytes=0, idle_age=2837, priority=10,icmp6,in_port=17,icmp_type=136 
actions=resubmit(,24)
 cookie=0x90444f3c8fabcbe0, duration=2831.688s, table=0, n_packets=0, 
n_bytes=0, idle_age=2831, priority=10,icmp6,in_port=19,icmp_type=136 
actions=resubmit(,24)
 cookie=0x90444f3c8fabcbe0, duration=2831.038s, table=0, n_packets=0, 
n_bytes=0, idle_age=2831, priority=10,icmp6,in_port=18,icmp_type=136 
actions=resubmit(,24)
 cookie=0x90444f3c8fabcbe0, duration=2801.555s, table=0, n_packets=0, 
n_bytes=0, idle_age=2801, priority=10,icmp6,in_port=20,icmp_type=136 
actions=resubmit(,24)
 cookie=0x90444f3c8fabcbe0, duration=2840.605s, table=0, n_packets=8, 
n_bytes=336, idle_age=2591, priority=10,arp,in_port=16 
actions=resubmit(,24)
 cookie=0x90444f3c8fabcbe0, duration=2836.759s, table=0, n_packets=0, 
n_bytes=0, idle_age=2836, priority=10,arp,in_port=17 actions=resubmit(,24)
 cookie=0x90444f3c8fabcbe0, duration=2831.485s, table=0, n_packets=0, 
n_bytes=0, idle_age=2831, priority=10,arp,in_port=19 actions=resubmit(,24)
 cookie=0x90444f3c8fabcbe0, duration=2830.816s, table=0, n_packets=21, 
n_bytes=882, idle_age=1605, priority=10,arp,in_port=18 
actions=resubmit(,24)
 cookie=0x90444f3c8fabcbe0, duration=2801.309s, table=0, n_packets=10, 
n_bytes=420, idle_age=545, priority=10,arp,in_port=20 
actions=resubmit(,24)
 cookie=0x90444f3c8fabcbe0, duration=15755.073s, table=0, n_packets=3241, 
n_bytes=366555, idle_age=545, priority=0 actions=NORMAL
 cookie=0x90444f3c8fabcbe0, duration=15754.687s, table=23, n_packets=0, 
n_bytes=0, idle_age=15754, priority=0 actions=drop
 cookie=0x90444f3c8fabcbe0, duration=2841.201s, table=24, n_packets=0, 
n_bytes=0, idle_age=2841, 
priority=2,icmp6,in_port=16,icmp_type=136,nd_target=fe80::f816:3eff:fe2d:c29d 
actions=NORMAL
 cookie=0x90444f3c8fabcbe0, duration=2837.177s, table=24, n_packets=0, 
n_bytes=0, idle_age=2837, 
priority=2,icmp6,in_port=17,icmp_type=136,nd_target=fe80::f816:3eff:fee0:f8ca 
actions=NORMAL
 cookie=0x90444f3c8fabcbe0, duration=2831.794s, table=24, n_packets=0, 
n_bytes=0, idle_age=2831, 
priority=2,icmp6,in_port=19,icmp_type=136,nd_target=fe80::f816:3eff:fe86:a668 
actions=NORMAL
 cookie=0x90444f3c8fabcbe0, duration=2831.150s, table=24, n_packets=0, 
n_bytes=0, idle_age=2831, 
priority=2,icmp6,in_port=18,icmp_type=136,nd_targe

Re: [openstack-dev] [neutron][SFC]

[Mohan Kumar]

Hi Alioune / nazhu,

  Logical-source-port is not mandatory in API , you can create
Flow_classifier without logical-source-port , This restriction is moved to
OVS driver . Please refer review link
https://review.openstack.org/#/c/313801/5

 If your back end driver is OVS , you need to specify the
logical-source-port is much needed as per design to avoid the return packet
to reclassified .

Thanks.,
Mohankumar.N


On Mon, Jun 13, 2016 at 7:49 AM, Na Zhu <na...@cn.ibm.com> wrote:

> I find this issue also, I filed a bug about it
> https://bugs.launchpad.net/networking-sfc/+bug/1586721
> I think logical-source-port can be optional.
>
>
>
>
>
> 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:Alioune <baliou...@gmail.com>
> To:"OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org>
> Date:2016/06/10 22:28
> Subject:Re: [openstack-dev] [neutron][SFC]
> --
>
>
>
> Hi Mohan,
> Even if I clone the master branch of networking-sfc project,I get the
> following errir when creating flow-classifier, therefore I do precise the
>  logical-source-port.
>
> 2016-06-10 05:34:05.693 10799 ERROR neutron.api.v2.resource DBError:
> (pymysql.err.IntegrityError) (1048, u"Column 'logical_source_port' cannot
> be null")
>
> I'm trying the example in [1]
>
> Here is a "ovs-ofctl dump-flows" on br-int ofter creating port-chain, I
> expected to see vxlan or gre tunnel encapsulation entries as explained in
> [1], may I know why there is no tunnel entry in br-int ?
>
> sudo ovs-ofctl dump-flows br-int
> NXST_FLOW reply (xid=0x4):
>  cookie=0x90444f3c8fabcbe0, duration=2840.983s, table=0, n_packets=0,
> n_bytes=0, idle_age=2840, priority=10,icmp6,in_port=16,icmp_type=136
> actions=resubmit(,24)
>  cookie=0x90444f3c8fabcbe0, duration=2837.039s, table=0, n_packets=0,
> n_bytes=0, idle_age=2837, priority=10,icmp6,in_port=17,icmp_type=136
> actions=resubmit(,24)
>  cookie=0x90444f3c8fabcbe0, duration=2831.688s, table=0, n_packets=0,
> n_bytes=0, idle_age=2831, priority=10,icmp6,in_port=19,icmp_type=136
> actions=resubmit(,24)
>  cookie=0x90444f3c8fabcbe0, duration=2831.038s, table=0, n_packets=0,
> n_bytes=0, idle_age=2831, priority=10,icmp6,in_port=18,icmp_type=136
> actions=resubmit(,24)
>  cookie=0x90444f3c8fabcbe0, duration=2801.555s, table=0, n_packets=0,
> n_bytes=0, idle_age=2801, priority=10,icmp6,in_port=20,icmp_type=136
> actions=resubmit(,24)
>  cookie=0x90444f3c8fabcbe0, duration=2840.605s, table=0, n_packets=8,
> n_bytes=336, idle_age=2591, priority=10,arp,in_port=16 actions=resubmit(,24)
>  cookie=0x90444f3c8fabcbe0, duration=2836.759s, table=0, n_packets=0,
> n_bytes=0, idle_age=2836, priority=10,arp,in_port=17 actions=resubmit(,24)
>  cookie=0x90444f3c8fabcbe0, duration=2831.485s, table=0, n_packets=0,
> n_bytes=0, idle_age=2831, priority=10,arp,in_port=19 actions=resubmit(,24)
>  cookie=0x90444f3c8fabcbe0, duration=2830.816s, table=0, n_packets=21,
> n_bytes=882, idle_age=1605, priority=10,arp,in_port=18 actions=resubmit(,24)
>  cookie=0x90444f3c8fabcbe0, duration=2801.309s, table=0, n_packets=10,
> n_bytes=420, idle_age=545, priority=10,arp,in_port=20 actions=resubmit(,24)
>  cookie=0x90444f3c8fabcbe0, duration=15755.073s, table=0, n_packets=3241,
> n_bytes=366555, idle_age=545, priority=0 actions=NORMAL
>  cookie=0x90444f3c8fabcbe0, duration=15754.687s, table=23, n_packets=0,
> n_bytes=0, idle_age=15754, priority=0 actions=drop
>  cookie=0x90444f3c8fabcbe0, duration=2841.201s, table=24, n_packets=0,
> n_bytes=0, idle_age=2841,
> priority=2,icmp6,in_port=16,icmp_type=136,nd_target=fe80::f816:3eff:fe2d:c29d
> actions=NORMAL
>  cookie=0x90444f3c8fabcbe0, duration=2837.177s, table=24, n_packets=0,
> n_bytes=0, idle_age=2837,
> priority=2,icmp6,in_port=17,icmp_type=136,nd_target=fe80::f816:3eff:fee0:f8ca
> actions=NORMAL
>  cookie=0x90444f3c8fabcbe0, duration=2831.794s, table=24, n_packets=0,
> n_bytes=0, idle_age=2831,
> priority=2,icmp6,in_port=19,icmp_type=136,nd_target=fe80::f816:3eff:fe86:a668
> actions=NORMAL
>  cookie=0x90444f3c8fabcbe0, duration=2831.150s, table=24, n_packets=0,
> n_bytes=0, idle_age=2831,
> priority=2,icmp6,in_port=18,icmp_type=136,nd_target=fe80::f816:3eff:feb4:965f
> actions=NORMAL
>  cookie=0x90444f3c8fabcbe0, duration=2801.675s, table=24, n_packets=0,
> n_bytes=0, idle_age=2801,
> priority=2,icmp6,in_port=20,icmp_type=136,nd_target=fe80::f816:3eff:fe5a:3097
> actions=NORMAL
>  cookie=0x90444f3c8fabcbe0,

Re: [openstack-dev] [neutron][SFC]

[Na Zhu]

I find this issue also, I filed a bug about it 
https://bugs.launchpad.net/networking-sfc/+bug/1586721
I think logical-source-port can be optional.





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:   Alioune <baliou...@gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date:   2016/06/10 22:28
Subject:        Re: [openstack-dev] [neutron][SFC]



Hi Mohan,
Even if I clone the master branch of networking-sfc project,I get the 
following errir when creating flow-classifier, therefore I do precise the 
 logical-source-port.

2016-06-10 05:34:05.693 10799 ERROR neutron.api.v2.resource DBError: 
(pymysql.err.IntegrityError) (1048, u"Column 'logical_source_port' cannot 
be null") 
 
I'm trying the example in [1] 

Here is a "ovs-ofctl dump-flows" on br-int ofter creating port-chain, I 
expected to see vxlan or gre tunnel encapsulation entries as explained in 
[1], may I know why there is no tunnel entry in br-int ?

sudo ovs-ofctl dump-flows br-int
NXST_FLOW reply (xid=0x4):
 cookie=0x90444f3c8fabcbe0, duration=2840.983s, table=0, n_packets=0, 
n_bytes=0, idle_age=2840, priority=10,icmp6,in_port=16,icmp_type=136 
actions=resubmit(,24)
 cookie=0x90444f3c8fabcbe0, duration=2837.039s, table=0, n_packets=0, 
n_bytes=0, idle_age=2837, priority=10,icmp6,in_port=17,icmp_type=136 
actions=resubmit(,24)
 cookie=0x90444f3c8fabcbe0, duration=2831.688s, table=0, n_packets=0, 
n_bytes=0, idle_age=2831, priority=10,icmp6,in_port=19,icmp_type=136 
actions=resubmit(,24)
 cookie=0x90444f3c8fabcbe0, duration=2831.038s, table=0, n_packets=0, 
n_bytes=0, idle_age=2831, priority=10,icmp6,in_port=18,icmp_type=136 
actions=resubmit(,24)
 cookie=0x90444f3c8fabcbe0, duration=2801.555s, table=0, n_packets=0, 
n_bytes=0, idle_age=2801, priority=10,icmp6,in_port=20,icmp_type=136 
actions=resubmit(,24)
 cookie=0x90444f3c8fabcbe0, duration=2840.605s, table=0, n_packets=8, 
n_bytes=336, idle_age=2591, priority=10,arp,in_port=16 
actions=resubmit(,24)
 cookie=0x90444f3c8fabcbe0, duration=2836.759s, table=0, n_packets=0, 
n_bytes=0, idle_age=2836, priority=10,arp,in_port=17 actions=resubmit(,24)
 cookie=0x90444f3c8fabcbe0, duration=2831.485s, table=0, n_packets=0, 
n_bytes=0, idle_age=2831, priority=10,arp,in_port=19 actions=resubmit(,24)
 cookie=0x90444f3c8fabcbe0, duration=2830.816s, table=0, n_packets=21, 
n_bytes=882, idle_age=1605, priority=10,arp,in_port=18 
actions=resubmit(,24)
 cookie=0x90444f3c8fabcbe0, duration=2801.309s, table=0, n_packets=10, 
n_bytes=420, idle_age=545, priority=10,arp,in_port=20 
actions=resubmit(,24)
 cookie=0x90444f3c8fabcbe0, duration=15755.073s, table=0, n_packets=3241, 
n_bytes=366555, idle_age=545, priority=0 actions=NORMAL
 cookie=0x90444f3c8fabcbe0, duration=15754.687s, table=23, n_packets=0, 
n_bytes=0, idle_age=15754, priority=0 actions=drop
 cookie=0x90444f3c8fabcbe0, duration=2841.201s, table=24, n_packets=0, 
n_bytes=0, idle_age=2841, 
priority=2,icmp6,in_port=16,icmp_type=136,nd_target=fe80::f816:3eff:fe2d:c29d 
actions=NORMAL
 cookie=0x90444f3c8fabcbe0, duration=2837.177s, table=24, n_packets=0, 
n_bytes=0, idle_age=2837, 
priority=2,icmp6,in_port=17,icmp_type=136,nd_target=fe80::f816:3eff:fee0:f8ca 
actions=NORMAL
 cookie=0x90444f3c8fabcbe0, duration=2831.794s, table=24, n_packets=0, 
n_bytes=0, idle_age=2831, 
priority=2,icmp6,in_port=19,icmp_type=136,nd_target=fe80::f816:3eff:fe86:a668 
actions=NORMAL
 cookie=0x90444f3c8fabcbe0, duration=2831.150s, table=24, n_packets=0, 
n_bytes=0, idle_age=2831, 
priority=2,icmp6,in_port=18,icmp_type=136,nd_target=fe80::f816:3eff:feb4:965f 
actions=NORMAL
 cookie=0x90444f3c8fabcbe0, duration=2801.675s, table=24, n_packets=0, 
n_bytes=0, idle_age=2801, 
priority=2,icmp6,in_port=20,icmp_type=136,nd_target=fe80::f816:3eff:fe5a:3097 
actions=NORMAL
 cookie=0x90444f3c8fabcbe0, duration=2840.794s, table=24, n_packets=8, 
n_bytes=336, idle_age=2591, priority=2,arp,in_port=16,arp_spa=55.55.55.3 
actions=NORMAL
 cookie=0x90444f3c8fabcbe0, duration=2836.901s, table=24, n_packets=0, 
n_bytes=0, idle_age=2836, priority=2,arp,in_port=17,arp_spa=55.55.55.4 
actions=NORMAL
 cookie=0x90444f3c8fabcbe0, duration=2831.587s, table=24, n_packets=0, 
n_bytes=0, idle_age=2831, priority=2,arp,in_port=19,arp_spa=55.55.55.6 
actions=NORMAL
 cookie=0x90444f3c8fabcbe0, duration=2830.933s, table=24, n_packets=21, 
n_bytes=882, idle_age=1605, priority=2,arp,in_port=18,arp_spa=55.55.55.5 
actions=NORMAL
 cookie=0x90444f3c8fabcbe0, duration=2801.431s, table=24, n_packets=10, 
n_bytes=420, idle_age=545, priority=2,arp,in_port=20,arp_spa=55.55.55.8 
actions=NORMAL
 cookie=0x90444f3c8fabcbe0, duration=15754.273s, table=24, n_packets=0, 
n_bytes=0, idle_age=15754, priority=0 actions=drop


is there a link that explains 

Re: [openstack-dev] [neutron][SFC]

[Alioune]

> *To:* Mohan Kumar
> *Cc:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [neutron][SFC]
>
>
>
> Thanks Mohan,
>
>
>
> After setting service_plugins and adding sfc tables to neutrondb, I can
> create port-pair, port-pair-group but classifier creation still claim a
> logical-source-port parameter.
>
>
>
> neutron flow-classifier-create  --ethertype IPv4  --source-ip-prefix
> 55.55.55.2/32  --destination-ip-prefix 55.55.55.9/32  --protocol tcp
>  --source-port 22:22  --destination-port 1:65000 FC1
>
> ERROR:
>
> neutron flow-classifier-create: error: argument --logical-source-port is
> required
>
> Try 'neutron help flow-classifier-create' for more information.
>
>
>
> Please someone can explain what does --logical-source-port correspond to ?
>
> Does the classifier require port-create like SF ?
>
>
>
> Regards,
>
>
>
>
>
> On 9 June 2016 at 09:21, Mohan Kumar <nmohankumar1...@gmail.com> wrote:
>
> *Alioune,*
>
>
>
> *networking-sfc  resources not installed / not reachable , *If installation
> is okay, Possibly you may missed service_plugins entry in *neutron.conf *(
> in case of manual networking-sfc installation)
>
>
>
> it should be ,
>
>
>
> *service_plugins =
> neutron.services.l3_router.l3_router_plugin.L3RouterPlugin,networking_sfc.services.flowclassifier.plugin.FlowClassifierPlugin,networking_sfc.services.sfc.plugin.SfcPlugin*
>
>
>
> *and restart q-svc services in screen -x *
>
>
>
> *Thanks.,*
>
> *Mohankumar.N *
>
>
>
> On Thu, Jun 9, 2016 at 12:58 AM, Alioune <baliou...@gmail.com> wrote:
>
> I've switched from devstack to a normal deployment of openstack/mitaka and
> neutron-l2 agent is working fine with sfc. I can boot instances, create
> ports.
>
> However I can not create neither flow-classifier nor port-pair ...
>
>
>
> neutron flow-classifier-create --ethertype IPv4 --source-ip-prefix
> 22.1.20.1/32 --destination-ip-prefix 172.4.5.6/32 --protocol tcp
> --source-port 23:23 --destination-port 100:100 FC1
>
>
>
> returns: neutron flow-classifier-create: error: argument
> --logical-source-port is required
>
> Try 'neutron help flow-classifier-create' for more information.
>
>
>
>  neutron port-pair-create --ingress=p1 --egress=p2 PP1
>
> 404 Not Found
>
>
>
> The resource could not be found.
>
>
>
> Neutron server returns request_ids:
> ['req-1bfd0983-4a61-4b32-90b3-252004d90e65']
>
>
>
> neutron --version
>
> 4.1.1
>
>
>
> p1,p2,p3,p4 have already been created, I can ping instances attached to
> these ports.
>
> Since I've not installed networking-sfc, are there additional config to
> set in neutron config files ?
>
> Or is it due to neutron-client version ?
>
>
>
> Regards
>
>
>
> On 8 June 2016 at 20:31, Mohan Kumar <nmohankumar1...@gmail.com> wrote:
>
> neutron agent not able to fetch details from ovsdb . Could you check below
> options 1.restart ovsdb-server and execute ovs_vsctl list-br  2.   execute
> ovs- vsctl list-br manually and try to check error.
>
> 3. Could be ovs cleanup issue , please check the output of sudo service
> openvswitch restart and /etc/init.d/openvswich** restart , both should be
> same
>
> Thanks.,
> Mohankumar.N
>
> On Jun 7, 2016 6:04 PM, "Alioune" <baliou...@gmail.com> wrote:
>
> Hi Mohan/Cathy
>
>  I've installed now ovs 2.4.0 and followed
> https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining but I
> got this error :
>
> Regards,
>
>
>
> + neutron-ovs-cleanup
>
> 2016-06-07 11:25:36.465 22147 INFO neutron.common.config [-] Logging
> enabled!
>
> 2016-06-07 11:25:36.468 22147 INFO neutron.common.config [-]
> /usr/local/bin/neutron-ovs-cleanup version 7.1.1.dev4
>
> 2016-06-07 11:25:36.505 22147 ERROR neutron.agent.ovsdb.impl_vsctl [-]
> Unable to execute ['ovs-vsctl', '--timeout=10', '--oneline',
> '--format=json', '--', 'list-br'].
>
> 2016-06-07 11:25:36.505 22147 ERROR neutron.agent.ovsdb.impl_vsctl
> Traceback (most recent call last):
>
> 2016-06-07 11:25:36.505 22147 ERROR neutron.agent.ovsdb.impl_vsctl   File
> "/opt/stack/neutron/neutron/agent/ovsdb/impl_vsctl.py", line 63, in
> run_vsctl
>
> 2016-06-07 11:25:36.505 22147 ERROR neutron.agent.ovsdb.impl_vsctl
> log_fail_as_error=False).rstrip()
>
> 2016-06-07 11:25:36.505 22147 ERROR neutron.agent.ovsdb.impl_vsctl   File
> "/opt/stack/neutron/neutron/agent/linux/utils.py", line 159, in execute
>
> 2016-06-07 11:25:36.505 22147 ERROR neutron.agent.ovsdb.impl_vsct

Re: [openstack-dev] [neutron][SFC]

[Henry Fourie]

Alioune,
   The logical-source-port refers to a Neutron port of the VM that
originates the traffic that is to be processed by the port-chain.

-Louis

From: Alioune [mailto:baliou...@gmail.com]
Sent: Thursday, June 09, 2016 6:50 AM
To: Mohan Kumar
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][SFC]

Thanks Mohan,

After setting service_plugins and adding sfc tables to neutrondb, I can create 
port-pair, port-pair-group but classifier creation still claim a 
logical-source-port parameter.

neutron flow-classifier-create  --ethertype IPv4  --source-ip-prefix 
55.55.55.2/32<http://55.55.55.2/32>  --destination-ip-prefix 
55.55.55.9/32<http://55.55.55.9/32>  --protocol tcp  --source-port 22:22  
--destination-port 1:65000 FC1
ERROR:
neutron flow-classifier-create: error: argument --logical-source-port is 
required
Try 'neutron help flow-classifier-create' for more information.

Please someone can explain what does --logical-source-port correspond to ?
Does the classifier require port-create like SF ?

Regards,


On 9 June 2016 at 09:21, Mohan Kumar 
<nmohankumar1...@gmail.com<mailto:nmohankumar1...@gmail.com>> wrote:
Alioune,

networking-sfc  resources not installed / not reachable , If installation is 
okay, Possibly you may missed service_plugins entry in neutron.conf ( in case 
of manual networking-sfc installation)

it should be ,

service_plugins = 
neutron.services.l3_router.l3_router_plugin.L3RouterPlugin,networking_sfc.services.flowclassifier.plugin.FlowClassifierPlugin,networking_sfc.services.sfc.plugin.SfcPlugin

and restart q-svc services in screen -x

Thanks.,
Mohankumar.N

On Thu, Jun 9, 2016 at 12:58 AM, Alioune 
<baliou...@gmail.com<mailto:baliou...@gmail.com>> wrote:
I've switched from devstack to a normal deployment of openstack/mitaka and 
neutron-l2 agent is working fine with sfc. I can boot instances, create ports.
However I can not create neither flow-classifier nor port-pair ...

neutron flow-classifier-create --ethertype IPv4 --source-ip-prefix 
22.1.20.1/32<http://22.1.20.1/32> --destination-ip-prefix 
172.4.5.6/32<http://172.4.5.6/32> --protocol tcp --source-port 23:23 
--destination-port 100:100 FC1

returns: neutron flow-classifier-create: error: argument --logical-source-port 
is required
Try 'neutron help flow-classifier-create' for more information.

 neutron port-pair-create --ingress=p1 --egress=p2 PP1
404 Not Found

The resource could not be found.

Neutron server returns request_ids: ['req-1bfd0983-4a61-4b32-90b3-252004d90e65']

neutron --version
4.1.1

p1,p2,p3,p4 have already been created, I can ping instances attached to these 
ports.
Since I've not installed networking-sfc, are there additional config to set in 
neutron config files ?
Or is it due to neutron-client version ?

Regards

On 8 June 2016 at 20:31, Mohan Kumar 
<nmohankumar1...@gmail.com<mailto:nmohankumar1...@gmail.com>> wrote:

neutron agent not able to fetch details from ovsdb . Could you check below 
options 1.restart ovsdb-server and execute ovs_vsctl list-br  2.   execute ovs- 
vsctl list-br manually and try to check error.

3. Could be ovs cleanup issue , please check the output of sudo service 
openvswitch restart and /etc/init.d/openvswich** restart , both should be same

Thanks.,
Mohankumar.N
On Jun 7, 2016 6:04 PM, "Alioune" 
<baliou...@gmail.com<mailto:baliou...@gmail.com>> wrote:
Hi Mohan/Cathy
 I've installed now ovs 2.4.0 and followed 
https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining but I got 
this error :
Regards,

+ neutron-ovs-cleanup
2016-06-07 11:25:36.465 22147 INFO neutron.common.config [-] Logging enabled!
2016-06-07 11:25:36.468 22147 INFO neutron.common.config [-] 
/usr/local/bin/neutron-ovs-cleanup version 7.1.1.dev4
2016-06-07 11:25:36.505 22147 ERROR neutron.agent.ovsdb.impl_vsctl [-] Unable 
to execute ['ovs-vsctl', '--timeout=10', '--oneline', '--format=json', '--', 
'list-br'].
2016-06-07 11:25:36.505 22147 ERROR neutron.agent.ovsdb.impl_vsctl Traceback 
(most recent call last):
2016-06-07 11:25:36.505 22147 ERROR neutron.agent.ovsdb.impl_vsctl   File 
"/opt/stack/neutron/neutron/agent/ovsdb/impl_vsctl.py", line 63, in run_vsctl
2016-06-07 11:25:36.505 22147 ERROR neutron.agent.ovsdb.impl_vsctl 
log_fail_as_error=False).rstrip()
2016-06-07 11:25:36.505 22147 ERROR neutron.agent.ovsdb.impl_vsctl   File 
"/opt/stack/neutron/neutron/agent/linux/utils.py", line 159, in execute
2016-06-07 11:25:36.505 22147 ERROR neutron.agent.ovsdb.impl_vsctl raise 
RuntimeError(m)
2016-06-07 11:25:36.505 22147 ERROR neutron.agent.ovsdb.impl_vsctl RuntimeError:
2016-06-07 11:25:36.505 22147 ERROR neutron.agent.ovsdb.impl_vsctl Command: 
['sudo', 'ovs-vsctl', '--timeout=10', '--oneline', '--format=json', '--', 
'list-br']
2016-06-07 11:25:36.505 22147 ERROR neutron.agent.ovsdb.impl_vsctl Exit code: 1

Re: [openstack-dev] [neutron][SFC]

[Mohan Kumar]

;>>>>> "/opt/stack/neutron/neutron/agent/ovsdb/impl_vsctl.py", line 83, in 
>>>>>>> execute
>>>>>>> 2016-06-07 11:25:36.512 22147 ERROR neutron txn.add(self)
>>>>>>> 2016-06-07 11:25:36.512 22147 ERROR neutron   File
>>>>>>> "/opt/stack/neutron/neutron/agent/ovsdb/api.py", line 70, in __exit__
>>>>>>> 2016-06-07 11:25:36.512 22147 ERROR neutron self.result =
>>>>>>> self.commit()
>>>>>>> 2016-06-07 11:25:36.512 22147 ERROR neutron   File
>>>>>>> "/opt/stack/neutron/neutron/agent/ovsdb/impl_vsctl.py", line 50, in 
>>>>>>> commit
>>>>>>> 2016-06-07 11:25:36.512 22147 ERROR neutron res =
>>>>>>> self.run_vsctl(args)
>>>>>>> 2016-06-07 11:25:36.512 22147 ERROR neutron   File
>>>>>>> "/opt/stack/neutron/neutron/agent/ovsdb/impl_vsctl.py", line 70, in
>>>>>>> run_vsctl
>>>>>>> 2016-06-07 11:25:36.512 22147 ERROR neutron ctxt.reraise = False
>>>>>>> 2016-06-07 11:25:36.512 22147 ERROR neutron   File
>>>>>>> "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 
>>>>>>> 204,
>>>>>>> in __exit__
>>>>>>> 2016-06-07 11:25:36.512 22147 ERROR neutron
>>>>>>> six.reraise(self.type_, self.value, self.tb)
>>>>>>> 2016-06-07 11:25:36.512 22147 ERROR neutron   File
>>>>>>> "/opt/stack/neutron/neutron/agent/ovsdb/impl_vsctl.py", line 63, in
>>>>>>> run_vsctl
>>>>>>> 2016-06-07 11:25:36.512 22147 ERROR neutron
>>>>>>> log_fail_as_error=False).rstrip()
>>>>>>> 2016-06-07 11:25:36.512 22147 ERROR neutron   File
>>>>>>> "/opt/stack/neutron/neutron/agent/linux/utils.py", line 159, in execute
>>>>>>> 2016-06-07 11:25:36.512 22147 ERROR neutron raise RuntimeError(m)
>>>>>>> 2016-06-07 11:25:36.512 22147 ERROR neutron RuntimeError:
>>>>>>> 2016-06-07 11:25:36.512 22147 ERROR neutron Command: ['sudo',
>>>>>>> 'ovs-vsctl', '--timeout=10', '--oneline', '--format=json', '--', 
>>>>>>> 'list-br']
>>>>>>> 2016-06-07 11:25:36.512 22147 ERROR neutron Exit code: 1
>>>>>>> 2016-06-07 11:25:36.512 22147 ERROR neutron
>>>>>>> 2016-06-07 11:25:36.512 22147 ERROR neutron
>>>>>>> + exit_trap
>>>>>>> + local r=1
>>>>>>> ++ jobs -p
>>>>>>> + jobs=
>>>>>>> + [[ -n '' ]]
>>>>>>> + kill_spinner
>>>>>>> + '[' '!' -z '' ']'
>>>>>>> + [[ 1 -ne 0 ]]
>>>>>>> + echo 'Error on exit'
>>>>>>> Error on exit
>>>>>>> + generate-subunit 1465296797 1939 fail
>>>>>>> + [[ -z /opt/stack/logs ]]
>>>>>>> + /home/alioune/devstack/tools/worlddump.py -d /opt/stack/logs
>>>>>>> World dumping... see /opt/stack/logs/worlddump-2016-06-07-112537.txt
>>>>>>> for details
>>>>>>> + exit 1
>>>>>>>
>>>>>>>
>>>>>>> On 7 June 2016 at 12:08, Mohan Kumar <nmohankumar1...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi shihanzhang / Alioune ,
>>>>>>>>
>>>>>>>> *your kernel (check with uname -r )  should support OVS version ,
>>>>>>>> below table compare kern*el versions and corresponding Open
>>>>>>>> vSwitch release support
>>>>>>>>
>>>>>>>> | Open vSwitch | Linux kernel
>>>>>>>> |::|:-:
>>>>>>>> |1.4.x | 2.6.18 to 3.2
>>>>>>>> |1.5.x | 2.6.18 to 3.2
>>>>>>>> |1.6.x | 2.6.18 to 3.2
>>>>>>>> |1.7.x | 2.6.18 to 3.3
>>>>>>>> |1.8.x | 2.6.18 to 3.4
>>>>>>>> |1.9.x | 2.6.18 to 3.8
>>>>>>>> |1.10.x| 2.6.18 to 3.8
>>>>>>>> |1.11.x| 2.6.18 to 3.8
>>>>>>>> |2.0.x | 2.6.32 to 3.10
>>>>>

Re: [openstack-dev] [neutron][SFC]

[Alioune]

  ctxt.reraise = False
>>>>>> 2016-06-07 11:25:36.512 22147 ERROR neutron   File
>>>>>> "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 
>>>>>> 204,
>>>>>> in __exit__
>>>>>> 2016-06-07 11:25:36.512 22147 ERROR neutron
>>>>>> six.reraise(self.type_, self.value, self.tb)
>>>>>> 2016-06-07 11:25:36.512 22147 ERROR neutron   File
>>>>>> "/opt/stack/neutron/neutron/agent/ovsdb/impl_vsctl.py", line 63, in
>>>>>> run_vsctl
>>>>>> 2016-06-07 11:25:36.512 22147 ERROR neutron
>>>>>> log_fail_as_error=False).rstrip()
>>>>>> 2016-06-07 11:25:36.512 22147 ERROR neutron   File
>>>>>> "/opt/stack/neutron/neutron/agent/linux/utils.py", line 159, in execute
>>>>>> 2016-06-07 11:25:36.512 22147 ERROR neutron raise RuntimeError(m)
>>>>>> 2016-06-07 11:25:36.512 22147 ERROR neutron RuntimeError:
>>>>>> 2016-06-07 11:25:36.512 22147 ERROR neutron Command: ['sudo',
>>>>>> 'ovs-vsctl', '--timeout=10', '--oneline', '--format=json', '--', 
>>>>>> 'list-br']
>>>>>> 2016-06-07 11:25:36.512 22147 ERROR neutron Exit code: 1
>>>>>> 2016-06-07 11:25:36.512 22147 ERROR neutron
>>>>>> 2016-06-07 11:25:36.512 22147 ERROR neutron
>>>>>> + exit_trap
>>>>>> + local r=1
>>>>>> ++ jobs -p
>>>>>> + jobs=
>>>>>> + [[ -n '' ]]
>>>>>> + kill_spinner
>>>>>> + '[' '!' -z '' ']'
>>>>>> + [[ 1 -ne 0 ]]
>>>>>> + echo 'Error on exit'
>>>>>> Error on exit
>>>>>> + generate-subunit 1465296797 1939 fail
>>>>>> + [[ -z /opt/stack/logs ]]
>>>>>> + /home/alioune/devstack/tools/worlddump.py -d /opt/stack/logs
>>>>>> World dumping... see /opt/stack/logs/worlddump-2016-06-07-112537.txt
>>>>>> for details
>>>>>> + exit 1
>>>>>>
>>>>>>
>>>>>> On 7 June 2016 at 12:08, Mohan Kumar <nmohankumar1...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi shihanzhang / Alioune ,
>>>>>>>
>>>>>>> *your kernel (check with uname -r )  should support OVS version ,
>>>>>>> below table compare kern*el versions and corresponding Open vSwitch
>>>>>>> release support
>>>>>>>
>>>>>>> | Open vSwitch | Linux kernel
>>>>>>> |::|:-:
>>>>>>> |1.4.x | 2.6.18 to 3.2
>>>>>>> |1.5.x | 2.6.18 to 3.2
>>>>>>> |1.6.x | 2.6.18 to 3.2
>>>>>>> |1.7.x | 2.6.18 to 3.3
>>>>>>> |1.8.x | 2.6.18 to 3.4
>>>>>>> |1.9.x | 2.6.18 to 3.8
>>>>>>> |1.10.x| 2.6.18 to 3.8
>>>>>>> |1.11.x| 2.6.18 to 3.8
>>>>>>> |2.0.x | 2.6.32 to 3.10
>>>>>>> |2.1.x | 2.6.32 to 3.11
>>>>>>> |2.3.x | 2.6.32 to 3.14
>>>>>>> |2.4.x | 2.6.32 to 4.0
>>>>>>> |2.5.x | 2.6.32 to 4.3
>>>>>>>
>>>>>>> http://openvswitch.org/support/dist-docs/FAQ.md.txt (
>>>>>>> ### Q: What Linux kernel versions does each Open vSwitch release work 
>>>>>>> with?)
>>>>>>>
>>>>>>> I installed SFC with OVS 2.4.0  and 2.5.0 and not seen any issue
>>>>>>>
>>>>>>> Please check SFC wiki for installation guidelines : 
>>>>>>> https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining
>>>>>>>
>>>>>>>
>>>>>>> Thanks.,
>>>>>>>
>>>>>>> Mohankumar.N
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jun 7, 2016 at 1:46 PM, shihanzhang <ayshihanzh...@126.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Alioune and Cathy,
>>>>>>>>  For devstack on ubuntu14.04, the default ovs version is 2.0.2,
>>>>

Re: [openstack-dev] [neutron][SFC]

[Mohan Kumar]

'--timeout=10', '--oneline', '--format=json', '--', 
>>>>> 'list-br']
>>>>> 2016-06-07 11:25:36.512 22147 ERROR neutron Exit code: 1
>>>>> 2016-06-07 11:25:36.512 22147 ERROR neutron
>>>>> 2016-06-07 11:25:36.512 22147 ERROR neutron
>>>>> + exit_trap
>>>>> + local r=1
>>>>> ++ jobs -p
>>>>> + jobs=
>>>>> + [[ -n '' ]]
>>>>> + kill_spinner
>>>>> + '[' '!' -z '' ']'
>>>>> + [[ 1 -ne 0 ]]
>>>>> + echo 'Error on exit'
>>>>> Error on exit
>>>>> + generate-subunit 1465296797 1939 fail
>>>>> + [[ -z /opt/stack/logs ]]
>>>>> + /home/alioune/devstack/tools/worlddump.py -d /opt/stack/logs
>>>>> World dumping... see /opt/stack/logs/worlddump-2016-06-07-112537.txt
>>>>> for details
>>>>> + exit 1
>>>>>
>>>>>
>>>>> On 7 June 2016 at 12:08, Mohan Kumar <nmohankumar1...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi shihanzhang / Alioune ,
>>>>>>
>>>>>> *your kernel (check with uname -r )  should support OVS version ,
>>>>>> below table compare kern*el versions and corresponding Open vSwitch
>>>>>> release support
>>>>>>
>>>>>> | Open vSwitch | Linux kernel
>>>>>> |::|:-:
>>>>>> |1.4.x | 2.6.18 to 3.2
>>>>>> |1.5.x | 2.6.18 to 3.2
>>>>>> |1.6.x | 2.6.18 to 3.2
>>>>>> |1.7.x | 2.6.18 to 3.3
>>>>>> |1.8.x | 2.6.18 to 3.4
>>>>>> |1.9.x | 2.6.18 to 3.8
>>>>>> |1.10.x| 2.6.18 to 3.8
>>>>>> |1.11.x| 2.6.18 to 3.8
>>>>>> |2.0.x | 2.6.32 to 3.10
>>>>>> |2.1.x | 2.6.32 to 3.11
>>>>>> |2.3.x | 2.6.32 to 3.14
>>>>>> |2.4.x | 2.6.32 to 4.0
>>>>>> |2.5.x | 2.6.32 to 4.3
>>>>>>
>>>>>> http://openvswitch.org/support/dist-docs/FAQ.md.txt (
>>>>>> ### Q: What Linux kernel versions does each Open vSwitch release work 
>>>>>> with?)
>>>>>>
>>>>>> I installed SFC with OVS 2.4.0  and 2.5.0 and not seen any issue
>>>>>>
>>>>>> Please check SFC wiki for installation guidelines : 
>>>>>> https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining
>>>>>>
>>>>>>
>>>>>> Thanks.,
>>>>>>
>>>>>> Mohankumar.N
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Jun 7, 2016 at 1:46 PM, shihanzhang <ayshihanzh...@126.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Alioune and Cathy,
>>>>>>>  For devstack on ubuntu14.04, the default ovs version is 2.0.2,
>>>>>>> so there was the error as Alioune said.
>>>>>>>  Do we need to install speical ovs version in networking-sfc
>>>>>>> devstack plugin.sh?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 在 2016-06-07 07:48:26，"Cathy Zhang" <cathy.h.zh...@huawei.com> 写道：
>>>>>>>
>>>>>>> Hi Alioune,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Which OVS version are you using?
>>>>>>>
>>>>>>> Try openvswitch version 2.4.0 and restart the openvswitch-server
>>>>>>> before installing the devstack.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Cathy
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *From:* Alioune [mailto:baliou...@gmail.com]
>>>>>>> *Sent:* Friday, June 03, 2016 9:07 AM
>>>>>>> *To:* openstack-dev@lists.openstack.org
>>>>>>> *Cc:* Cathy Zhang
>>>>>>> *Subject:* [openstack-dev][neutron][SFC]
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Pro

Re: [openstack-dev] [neutron][SFC]

[Alioune]

gt;> Hi shihanzhang / Alioune ,
>>>>>
>>>>> *your kernel (check with uname -r )  should support OVS version ,
>>>>> below table compare kern*el versions and corresponding Open vSwitch
>>>>> release support
>>>>>
>>>>> | Open vSwitch | Linux kernel
>>>>> |::|:-:
>>>>> |1.4.x | 2.6.18 to 3.2
>>>>> |1.5.x | 2.6.18 to 3.2
>>>>> |1.6.x | 2.6.18 to 3.2
>>>>> |1.7.x | 2.6.18 to 3.3
>>>>> |1.8.x | 2.6.18 to 3.4
>>>>> |1.9.x | 2.6.18 to 3.8
>>>>> |1.10.x| 2.6.18 to 3.8
>>>>> |1.11.x| 2.6.18 to 3.8
>>>>> |2.0.x | 2.6.32 to 3.10
>>>>> |2.1.x | 2.6.32 to 3.11
>>>>> |2.3.x | 2.6.32 to 3.14
>>>>> |2.4.x | 2.6.32 to 4.0
>>>>> |2.5.x | 2.6.32 to 4.3
>>>>>
>>>>> http://openvswitch.org/support/dist-docs/FAQ.md.txt (
>>>>> ### Q: What Linux kernel versions does each Open vSwitch release work 
>>>>> with?)
>>>>>
>>>>> I installed SFC with OVS 2.4.0  and 2.5.0 and not seen any issue
>>>>>
>>>>> Please check SFC wiki for installation guidelines : 
>>>>> https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining
>>>>>
>>>>>
>>>>> Thanks.,
>>>>>
>>>>> Mohankumar.N
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jun 7, 2016 at 1:46 PM, shihanzhang <ayshihanzh...@126.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Alioune and Cathy,
>>>>>>  For devstack on ubuntu14.04, the default ovs version is 2.0.2,
>>>>>> so there was the error as Alioune said.
>>>>>>  Do we need to install speical ovs version in networking-sfc
>>>>>> devstack plugin.sh?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 在 2016-06-07 07:48:26，"Cathy Zhang" <cathy.h.zh...@huawei.com> 写道：
>>>>>>
>>>>>> Hi Alioune,
>>>>>>
>>>>>>
>>>>>>
>>>>>> Which OVS version are you using?
>>>>>>
>>>>>> Try openvswitch version 2.4.0 and restart the openvswitch-server
>>>>>> before installing the devstack.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Cathy
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From:* Alioune [mailto:baliou...@gmail.com]
>>>>>> *Sent:* Friday, June 03, 2016 9:07 AM
>>>>>> *To:* openstack-dev@lists.openstack.org
>>>>>> *Cc:* Cathy Zhang
>>>>>> *Subject:* [openstack-dev][neutron][SFC]
>>>>>>
>>>>>>
>>>>>>
>>>>>> Probleme with OpenStack SFC
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I've installed Openstack SFC with devstack and all module are
>>>>>> corretly running except the neutron L2-agent
>>>>>>
>>>>>>
>>>>>>
>>>>>> After a "screen -rd", it seems that there is a conflict between
>>>>>> l2-agent and SFC (see trace bellow).
>>>>>>
>>>>>> I solved the issue with "sudo ovs-vsctl set bridge br
>>>>>> protocols=OpenFlow10,OpenFlow11,OpenFlow12,OpenFlow13" on all openvswitch
>>>>>> bridge (br-int, br-ex, br-tun and br-mgmt0).
>>>>>>
>>>>>> I would like to know:
>>>>>>
>>>>>>   - If someone knows why this error arrises ?
>>>>>>
>>>>>>  - is there another way to solve it ?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2016-06-03 12:51:56.323 WARNING
>>>>>> neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
>>>>>> [req-1258bbbc-7211-4cfd-ab7c-8b856604f768 None None] OVS is dead.
>>>>>&

Re: [openstack-dev] [neutron][SFC]

[Mohan Kumar]

6-06-07 11:25:36.512 22147 ERROR neutron   File
>>> "/opt/stack/neutron/neutron/cmd/ovs_cleanup.py", line 89, in main
>>> 2016-06-07 11:25:36.512 22147 ERROR neutron ovs_bridges =
>>> set(ovs.get_bridges())
>>> 2016-06-07 11:25:36.512 22147 ERROR neutron   File
>>> "/opt/stack/neutron/neutron/agent/common/ovs_lib.py", line 132, in
>>> get_bridges
>>> 2016-06-07 11:25:36.512 22147 ERROR neutron return
>>> self.ovsdb.list_br().execute(check_error=True)
>>> 2016-06-07 11:25:36.512 22147 ERROR neutron   File
>>> "/opt/stack/neutron/neutron/agent/ovsdb/impl_vsctl.py", line 83, in execute
>>> 2016-06-07 11:25:36.512 22147 ERROR neutron txn.add(self)
>>> 2016-06-07 11:25:36.512 22147 ERROR neutron   File
>>> "/opt/stack/neutron/neutron/agent/ovsdb/api.py", line 70, in __exit__
>>> 2016-06-07 11:25:36.512 22147 ERROR neutron self.result =
>>> self.commit()
>>> 2016-06-07 11:25:36.512 22147 ERROR neutron   File
>>> "/opt/stack/neutron/neutron/agent/ovsdb/impl_vsctl.py", line 50, in commit
>>> 2016-06-07 11:25:36.512 22147 ERROR neutron res =
>>> self.run_vsctl(args)
>>> 2016-06-07 11:25:36.512 22147 ERROR neutron   File
>>> "/opt/stack/neutron/neutron/agent/ovsdb/impl_vsctl.py", line 70, in
>>> run_vsctl
>>> 2016-06-07 11:25:36.512 22147 ERROR neutron ctxt.reraise = False
>>> 2016-06-07 11:25:36.512 22147 ERROR neutron   File
>>> "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 204,
>>> in __exit__
>>> 2016-06-07 11:25:36.512 22147 ERROR neutron six.reraise(self.type_,
>>> self.value, self.tb)
>>> 2016-06-07 11:25:36.512 22147 ERROR neutron   File
>>> "/opt/stack/neutron/neutron/agent/ovsdb/impl_vsctl.py", line 63, in
>>> run_vsctl
>>> 2016-06-07 11:25:36.512 22147 ERROR neutron
>>> log_fail_as_error=False).rstrip()
>>> 2016-06-07 11:25:36.512 22147 ERROR neutron   File
>>> "/opt/stack/neutron/neutron/agent/linux/utils.py", line 159, in execute
>>> 2016-06-07 11:25:36.512 22147 ERROR neutron raise RuntimeError(m)
>>> 2016-06-07 11:25:36.512 22147 ERROR neutron RuntimeError:
>>> 2016-06-07 11:25:36.512 22147 ERROR neutron Command: ['sudo',
>>> 'ovs-vsctl', '--timeout=10', '--oneline', '--format=json', '--', 'list-br']
>>> 2016-06-07 11:25:36.512 22147 ERROR neutron Exit code: 1
>>> 2016-06-07 11:25:36.512 22147 ERROR neutron
>>> 2016-06-07 11:25:36.512 22147 ERROR neutron
>>> + exit_trap
>>> + local r=1
>>> ++ jobs -p
>>> + jobs=
>>> + [[ -n '' ]]
>>> + kill_spinner
>>> + '[' '!' -z '' ']'
>>> + [[ 1 -ne 0 ]]
>>> + echo 'Error on exit'
>>> Error on exit
>>> + generate-subunit 1465296797 1939 fail
>>> + [[ -z /opt/stack/logs ]]
>>> + /home/alioune/devstack/tools/worlddump.py -d /opt/stack/logs
>>> World dumping... see /opt/stack/logs/worlddump-2016-06-07-112537.txt for
>>> details
>>> + exit 1
>>>
>>>
>>> On 7 June 2016 at 12:08, Mohan Kumar <nmohankumar1...@gmail.com> wrote:
>>>
>>>> Hi shihanzhang / Alioune ,
>>>>
>>>> *your kernel (check with uname -r )  should support OVS version , below
>>>> table compare kern*el versions and corresponding Open vSwitch release
>>>> support
>>>>
>>>> | Open vSwitch | Linux kernel
>>>> |::|:-:
>>>> |1.4.x | 2.6.18 to 3.2
>>>> |1.5.x | 2.6.18 to 3.2
>>>> |1.6.x | 2.6.18 to 3.2
>>>> |1.7.x | 2.6.18 to 3.3
>>>> |1.8.x | 2.6.18 to 3.4
>>>> |1.9.x | 2.6.18 to 3.8
>>>> |1.10.x| 2.6.18 to 3.8
>>>> |1.11.x| 2.6.18 to 3.8
>>>> |2.0.x | 2.6.32 to 3.10
>>>> |2.1.x | 2.6.32 to 3.11
>>>> |2.3.x | 2.6.32 to 3.14
>>>> |2.4.x | 2.6.32 to 4.0
>>>> |2.5.x | 2.6.32 to 4.3
>>>>
>>>> http://openvswitch.org/support/dist-docs/FAQ.md.txt (
>>>> ### Q: What Linux kernel versions does each Open vSwitch release work 
>>>> with?)
>>>>
>>>> I installed SFC with OVS 2.4.0  and 2.5.0 and not seen any issue
>>>>
>>>> Please check SFC wiki for installation guidelines : 
>>>> https://wiki.openstack.org/wiki/Neutron/ServiceInser

Re: [openstack-dev] [neutron][SFC]

[Alioune]

 self.result =
>> self.commit()
>> 2016-06-07 11:25:36.512 22147 ERROR neutron   File
>> "/opt/stack/neutron/neutron/agent/ovsdb/impl_vsctl.py", line 50, in commit
>> 2016-06-07 11:25:36.512 22147 ERROR neutron res = self.run_vsctl(args)
>> 2016-06-07 11:25:36.512 22147 ERROR neutron   File
>> "/opt/stack/neutron/neutron/agent/ovsdb/impl_vsctl.py", line 70, in
>> run_vsctl
>> 2016-06-07 11:25:36.512 22147 ERROR neutron ctxt.reraise = False
>> 2016-06-07 11:25:36.512 22147 ERROR neutron   File
>> "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 204,
>> in __exit__
>> 2016-06-07 11:25:36.512 22147 ERROR neutron six.reraise(self.type_,
>> self.value, self.tb)
>> 2016-06-07 11:25:36.512 22147 ERROR neutron   File
>> "/opt/stack/neutron/neutron/agent/ovsdb/impl_vsctl.py", line 63, in
>> run_vsctl
>> 2016-06-07 11:25:36.512 22147 ERROR neutron
>> log_fail_as_error=False).rstrip()
>> 2016-06-07 11:25:36.512 22147 ERROR neutron   File
>> "/opt/stack/neutron/neutron/agent/linux/utils.py", line 159, in execute
>> 2016-06-07 11:25:36.512 22147 ERROR neutron raise RuntimeError(m)
>> 2016-06-07 11:25:36.512 22147 ERROR neutron RuntimeError:
>> 2016-06-07 11:25:36.512 22147 ERROR neutron Command: ['sudo',
>> 'ovs-vsctl', '--timeout=10', '--oneline', '--format=json', '--', 'list-br']
>> 2016-06-07 11:25:36.512 22147 ERROR neutron Exit code: 1
>> 2016-06-07 11:25:36.512 22147 ERROR neutron
>> 2016-06-07 11:25:36.512 22147 ERROR neutron
>> + exit_trap
>> + local r=1
>> ++ jobs -p
>> + jobs=
>> + [[ -n '' ]]
>> + kill_spinner
>> + '[' '!' -z '' ']'
>> + [[ 1 -ne 0 ]]
>> + echo 'Error on exit'
>> Error on exit
>> + generate-subunit 1465296797 1939 fail
>> + [[ -z /opt/stack/logs ]]
>> + /home/alioune/devstack/tools/worlddump.py -d /opt/stack/logs
>> World dumping... see /opt/stack/logs/worlddump-2016-06-07-112537.txt for
>> details
>> + exit 1
>>
>>
>> On 7 June 2016 at 12:08, Mohan Kumar <nmohankumar1...@gmail.com> wrote:
>>
>>> Hi shihanzhang / Alioune ,
>>>
>>> *your kernel (check with uname -r )  should support OVS version , below
>>> table compare kern*el versions and corresponding Open vSwitch release
>>> support
>>>
>>> | Open vSwitch | Linux kernel
>>> |::|:-:
>>> |1.4.x | 2.6.18 to 3.2
>>> |1.5.x | 2.6.18 to 3.2
>>> |1.6.x | 2.6.18 to 3.2
>>> |1.7.x | 2.6.18 to 3.3
>>> |1.8.x | 2.6.18 to 3.4
>>> |1.9.x | 2.6.18 to 3.8
>>> |1.10.x| 2.6.18 to 3.8
>>> |1.11.x| 2.6.18 to 3.8
>>> |2.0.x | 2.6.32 to 3.10
>>> |2.1.x | 2.6.32 to 3.11
>>> |2.3.x | 2.6.32 to 3.14
>>> |2.4.x | 2.6.32 to 4.0
>>> |2.5.x | 2.6.32 to 4.3
>>>
>>> http://openvswitch.org/support/dist-docs/FAQ.md.txt (
>>> ### Q: What Linux kernel versions does each Open vSwitch release work with?)
>>>
>>> I installed SFC with OVS 2.4.0  and 2.5.0 and not seen any issue
>>>
>>> Please check SFC wiki for installation guidelines : 
>>> https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining
>>>
>>>
>>> Thanks.,
>>>
>>> Mohankumar.N
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Jun 7, 2016 at 1:46 PM, shihanzhang <ayshihanzh...@126.com>
>>> wrote:
>>>
>>>> Hi Alioune and Cathy,
>>>>  For devstack on ubuntu14.04, the default ovs version is 2.0.2, so
>>>> there was the error as Alioune said.
>>>>  Do we need to install speical ovs version in networking-sfc
>>>> devstack plugin.sh?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> 在 2016-06-07 07:48:26，"Cathy Zhang" <cathy.h.zh...@huawei.com> 写道：
>>>>
>>>> Hi Alioune,
>>>>
>>>>
>>>>
>>>> Which OVS version are you using?
>>>>
>>>> Try openvswitch version 2.4.0 and restart the openvswitch-server before
>>>> installing the devstack.
>>>>
>>>>
>>>>
>>>> Cathy
>>>>
>>>>
>>>>
>>>> *From:* Alioune [mailto:baliou...@gmail.com]
>>>> *Sent:* Friday, June 03, 2016 9:07 AM
>>>&g

Re: [openstack-dev] [neutron][SFC]

[Alioune]

| Linux kernel
> |::|:-:
> |1.4.x | 2.6.18 to 3.2
> |1.5.x | 2.6.18 to 3.2
> |1.6.x | 2.6.18 to 3.2
> |1.7.x | 2.6.18 to 3.3
> |1.8.x | 2.6.18 to 3.4
> |1.9.x | 2.6.18 to 3.8
> |1.10.x| 2.6.18 to 3.8
> |1.11.x| 2.6.18 to 3.8
> |2.0.x | 2.6.32 to 3.10
> |2.1.x | 2.6.32 to 3.11
> |2.3.x | 2.6.32 to 3.14
> |2.4.x | 2.6.32 to 4.0
> |2.5.x | 2.6.32 to 4.3
>
> http://openvswitch.org/support/dist-docs/FAQ.md.txt (
> ### Q: What Linux kernel versions does each Open vSwitch release work with?)
>
> I installed SFC with OVS 2.4.0  and 2.5.0 and not seen any issue
>
> Please check SFC wiki for installation guidelines : 
> https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining
>
>
> Thanks.,
>
> Mohankumar.N
>
>
>
>
>
> On Tue, Jun 7, 2016 at 1:46 PM, shihanzhang <ayshihanzh...@126.com> wrote:
>
>> Hi Alioune and Cathy,
>>  For devstack on ubuntu14.04, the default ovs version is 2.0.2, so
>> there was the error as Alioune said.
>>  Do we need to install speical ovs version in networking-sfc
>> devstack plugin.sh?
>>
>>
>>
>>
>>
>> 在 2016-06-07 07:48:26，"Cathy Zhang" <cathy.h.zh...@huawei.com> 写道：
>>
>> Hi Alioune,
>>
>>
>>
>> Which OVS version are you using?
>>
>> Try openvswitch version 2.4.0 and restart the openvswitch-server before
>> installing the devstack.
>>
>>
>>
>> Cathy
>>
>>
>>
>> *From:* Alioune [mailto:baliou...@gmail.com]
>> *Sent:* Friday, June 03, 2016 9:07 AM
>> *To:* openstack-dev@lists.openstack.org
>> *Cc:* Cathy Zhang
>> *Subject:* [openstack-dev][neutron][SFC]
>>
>>
>>
>> Probleme with OpenStack SFC
>>
>> Hi all,
>>
>> I've installed Openstack SFC with devstack and all module are corretly
>> running except the neutron L2-agent
>>
>>
>>
>> After a "screen -rd", it seems that there is a conflict between l2-agent
>> and SFC (see trace bellow).
>>
>> I solved the issue with "sudo ovs-vsctl set bridge br
>> protocols=OpenFlow10,OpenFlow11,OpenFlow12,OpenFlow13" on all openvswitch
>> bridge (br-int, br-ex, br-tun and br-mgmt0).
>>
>> I would like to know:
>>
>>   - If someone knows why this error arrises ?
>>
>>  - is there another way to solve it ?
>>
>>
>>
>> Regards,
>>
>>
>>
>> 2016-06-03 12:51:56.323 WARNING
>> neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
>> [req-1258bbbc-7211-4cfd-ab7c-8b856604f768 None None] OVS is dead.
>> OVSNeutronAgent will keep running and checking OVS status periodically.
>>
>> 2016-06-03 12:51:56.330 DEBUG
>> neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
>> [req-1258bbbc-7211-4cfd-ab7c-8b856604f768 None None] Agent rpc_loop -
>> iteration:4722 completed. Processed ports statistics: {'regular':
>> {'updated': 0, 'added': 0, 'removed': 0}}. Elapsed:0.086 from (pid=12775)
>> loop_count_and_wait
>> /opt/stack/neutron/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py:1680
>>
>> 2016-06-03 12:51:58.256 DEBUG
>> neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
>> [req-1258bbbc-7211-4cfd-ab7c-8b856604f768 None None] Agent rpc_loop -
>> iteration:4723 started from (pid=12775) rpc_loop
>> /opt/stack/neutron/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py:1732
>>
>> 2016-06-03 12:51:58.258 DEBUG neutron.agent.linux.utils
>> [req-1258bbbc-7211-4cfd-ab7c-8b856604f768 None None] Running command
>> (rootwrap daemon): ['ovs-ofctl', '-O openflow13', 'dump-flows', 'br-int',
>> 'table=23'] from (pid=12775) execute_rootwrap_daemon
>> /opt/stack/neutron/neutron/agent/linux/utils.py:101
>>
>> 2016-06-03 12:51:58.311 ERROR neutron.agent.linux.utils
>> [req-1258bbbc-7211-4cfd-ab7c-8b856604f768 None None]
>>
>> Command: ['ovs-ofctl', '-O openflow13', 'dump-flows', 'br-int',
>> 'table=23']
>>
>> Exit code: 1
>>
>> Stdin:
>>
>> Stdout:
>>
>> Stderr:
>> 2016-06-03T12:51:58Z|1|vconn|WARN|unix:/var/run/openvswitch/br-int.mgmt:
>> version negotiation failed (we support version 0x04, peer supports version
>> 0x01)
>>
>> ovs-ofctl: br-int: failed to connect to socket (Broken pipe)
>>
>>
>>
>> 2016-06-03 12:51:58.323 ERROR
>> networkin

Re: [openstack-dev] [neutron][SFC]

[Mohan Kumar]

Hi shihanzhang / Alioune ,

*your kernel (check with uname -r )  should support OVS version , below
table compare kern*el versions and corresponding Open vSwitch release
support

| Open vSwitch | Linux kernel
|::|:-:
|1.4.x | 2.6.18 to 3.2
|1.5.x | 2.6.18 to 3.2
|1.6.x | 2.6.18 to 3.2
|1.7.x | 2.6.18 to 3.3
|1.8.x | 2.6.18 to 3.4
|1.9.x | 2.6.18 to 3.8
|1.10.x| 2.6.18 to 3.8
|1.11.x| 2.6.18 to 3.8
|2.0.x | 2.6.32 to 3.10
|2.1.x | 2.6.32 to 3.11
|2.3.x | 2.6.32 to 3.14
|2.4.x | 2.6.32 to 4.0
|2.5.x | 2.6.32 to 4.3

http://openvswitch.org/support/dist-docs/FAQ.md.txt (
### Q: What Linux kernel versions does each Open vSwitch release work with?)

I installed SFC with OVS 2.4.0  and 2.5.0 and not seen any issue

Please check SFC wiki for installation guidelines :
https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining


Thanks.,

Mohankumar.N





On Tue, Jun 7, 2016 at 1:46 PM, shihanzhang <ayshihanzh...@126.com> wrote:

> Hi Alioune and Cathy,
>  For devstack on ubuntu14.04, the default ovs version is 2.0.2, so
> there was the error as Alioune said.
>  Do we need to install speical ovs version in networking-sfc devstack
> plugin.sh?
>
>
>
>
>
> 在 2016-06-07 07:48:26，"Cathy Zhang" <cathy.h.zh...@huawei.com> 写道：
>
> Hi Alioune,
>
>
>
> Which OVS version are you using?
>
> Try openvswitch version 2.4.0 and restart the openvswitch-server before
> installing the devstack.
>
>
>
> Cathy
>
>
>
> *From:* Alioune [mailto:baliou...@gmail.com]
> *Sent:* Friday, June 03, 2016 9:07 AM
> *To:* openstack-dev@lists.openstack.org
> *Cc:* Cathy Zhang
> *Subject:* [openstack-dev][neutron][SFC]
>
>
>
> Probleme with OpenStack SFC
>
> Hi all,
>
> I've installed Openstack SFC with devstack and all module are corretly
> running except the neutron L2-agent
>
>
>
> After a "screen -rd", it seems that there is a conflict between l2-agent
> and SFC (see trace bellow).
>
> I solved the issue with "sudo ovs-vsctl set bridge br
> protocols=OpenFlow10,OpenFlow11,OpenFlow12,OpenFlow13" on all openvswitch
> bridge (br-int, br-ex, br-tun and br-mgmt0).
>
> I would like to know:
>
>   - If someone knows why this error arrises ?
>
>  - is there another way to solve it ?
>
>
>
> Regards,
>
>
>
> 2016-06-03 12:51:56.323 WARNING
> neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
> [req-1258bbbc-7211-4cfd-ab7c-8b856604f768 None None] OVS is dead.
> OVSNeutronAgent will keep running and checking OVS status periodically.
>
> 2016-06-03 12:51:56.330 DEBUG
> neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
> [req-1258bbbc-7211-4cfd-ab7c-8b856604f768 None None] Agent rpc_loop -
> iteration:4722 completed. Processed ports statistics: {'regular':
> {'updated': 0, 'added': 0, 'removed': 0}}. Elapsed:0.086 from (pid=12775)
> loop_count_and_wait
> /opt/stack/neutron/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py:1680
>
> 2016-06-03 12:51:58.256 DEBUG
> neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
> [req-1258bbbc-7211-4cfd-ab7c-8b856604f768 None None] Agent rpc_loop -
> iteration:4723 started from (pid=12775) rpc_loop
> /opt/stack/neutron/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py:1732
>
> 2016-06-03 12:51:58.258 DEBUG neutron.agent.linux.utils
> [req-1258bbbc-7211-4cfd-ab7c-8b856604f768 None None] Running command
> (rootwrap daemon): ['ovs-ofctl', '-O openflow13', 'dump-flows', 'br-int',
> 'table=23'] from (pid=12775) execute_rootwrap_daemon
> /opt/stack/neutron/neutron/agent/linux/utils.py:101
>
> 2016-06-03 12:51:58.311 ERROR neutron.agent.linux.utils
> [req-1258bbbc-7211-4cfd-ab7c-8b856604f768 None None]
>
> Command: ['ovs-ofctl', '-O openflow13', 'dump-flows', 'br-int', 'table=23']
>
> Exit code: 1
>
> Stdin:
>
> Stdout:
>
> Stderr:
> 2016-06-03T12:51:58Z|1|vconn|WARN|unix:/var/run/openvswitch/br-int.mgmt:
> version negotiation failed (we support version 0x04, peer supports version
> 0x01)
>
> ovs-ofctl: br-int: failed to connect to socket (Broken pipe)
>
>
>
> 2016-06-03 12:51:58.323 ERROR
> networking_sfc.services.sfc.common.ovs_ext_lib
> [req-1258bbbc-7211-4cfd-ab7c-8b856604f768 None None]
>
> Command: ['ovs-ofctl', '-O openflow13', 'dump-flows', 'br-int', 'table=23']
>
> Exit code: 1
>
> Stdin:
>
> Stdout:
>
> Stderr:
> 2016-06-03T12:51:58Z|1|vconn|WARN|unix:/var/run/openvswitch/br-int.mgmt:
> version negotiation failed (we support version 0x04, peer supports version
> 0x01)
>

Re: [openstack-dev] [neutron][SFC]

[shihanzhang]

Hi Alioune and Cathy,
 For devstack on ubuntu14.04, the default ovs version is 2.0.2, so there 
was the error as Alioune said.
 Do we need to install speical ovs version in networking-sfc devstack 
plugin.sh?






在 2016-06-07 07:48:26，"Cathy Zhang" <cathy.h.zh...@huawei.com> 写道：


Hi Alioune,

 

Which OVS version are you using?

Try openvswitch version 2.4.0 and restart the openvswitch-server before 
installing the devstack.

 

Cathy

 

From: Alioune [mailto:baliou...@gmail.com]
Sent: Friday, June 03, 2016 9:07 AM
To:openstack-dev@lists.openstack.org
Cc: Cathy Zhang
Subject: [openstack-dev][neutron][SFC]

 

Probleme with OpenStack SFC

Hi all, 

I've installed Openstack SFC with devstack and all module are corretly running 
except the neutron L2-agent

 

After a "screen -rd", it seems that there is a conflict between l2-agent and 
SFC (see trace bellow).

I solved the issue with "sudo ovs-vsctl set bridge br 
protocols=OpenFlow10,OpenFlow11,OpenFlow12,OpenFlow13" on all openvswitch 
bridge (br-int, br-ex, br-tun and br-mgmt0).

I would like to know:

  - If someone knows why this error arrises ?

 - is there another way to solve it ?

 

Regards,

 

2016-06-03 12:51:56.323 WARNING 
neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent 
[req-1258bbbc-7211-4cfd-ab7c-8b856604f768 None None] OVS is dead. 
OVSNeutronAgent will keep running and checking OVS status periodically.

2016-06-03 12:51:56.330 DEBUG 
neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent 
[req-1258bbbc-7211-4cfd-ab7c-8b856604f768 None None] Agent rpc_loop - 
iteration:4722 completed. Processed ports statistics: {'regular': {'updated': 
0, 'added': 0, 'removed': 0}}. Elapsed:0.086 from (pid=12775) 
loop_count_and_wait 
/opt/stack/neutron/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py:1680

2016-06-03 12:51:58.256 DEBUG 
neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent 
[req-1258bbbc-7211-4cfd-ab7c-8b856604f768 None None] Agent rpc_loop - 
iteration:4723 started from (pid=12775) rpc_loop 
/opt/stack/neutron/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py:1732

2016-06-03 12:51:58.258 DEBUG neutron.agent.linux.utils 
[req-1258bbbc-7211-4cfd-ab7c-8b856604f768 None None] Running command (rootwrap 
daemon): ['ovs-ofctl', '-O openflow13', 'dump-flows', 'br-int', 'table=23'] 
from (pid=12775) execute_rootwrap_daemon 
/opt/stack/neutron/neutron/agent/linux/utils.py:101

2016-06-03 12:51:58.311 ERROR neutron.agent.linux.utils 
[req-1258bbbc-7211-4cfd-ab7c-8b856604f768 None None]

Command: ['ovs-ofctl', '-O openflow13', 'dump-flows', 'br-int', 'table=23']

Exit code: 1

Stdin:

Stdout:

Stderr: 
2016-06-03T12:51:58Z|1|vconn|WARN|unix:/var/run/openvswitch/br-int.mgmt: 
version negotiation failed (we support version 0x04, peer supports version 0x01)

ovs-ofctl: br-int: failed to connect to socket (Broken pipe)

 

2016-06-03 12:51:58.323 ERROR networking_sfc.services.sfc.common.ovs_ext_lib 
[req-1258bbbc-7211-4cfd-ab7c-8b856604f768 None None]

Command: ['ovs-ofctl', '-O openflow13', 'dump-flows', 'br-int', 'table=23']

Exit code: 1

Stdin:

Stdout:

Stderr: 
2016-06-03T12:51:58Z|1|vconn|WARN|unix:/var/run/openvswitch/br-int.mgmt: 
version negotiation failed (we support version 0x04, peer supports version 0x01)

ovs-ofctl: br-int: failed to connect to socket (Broken pipe)

 

2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib 
Traceback (most recent call last):

2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib   
File 
"/opt/stack/networking-sfc/networking_sfc/services/sfc/common/ovs_ext_lib.py", 
line 125, in run_ofctl

2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib
 process_input=process_input)

2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib   
File "/opt/stack/neutron/neutron/agent/linux/utils.py", line 159, in execute

2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib
 raise RuntimeError(m)

2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib 
RuntimeError:

2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib 
Command: ['ovs-ofctl', '-O openflow13', 'dump-flows', 'br-int', 'table=23']

2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib 
Exit code: 1

2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib 
Stdin:

2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib 
Stdout:

2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib 
Stderr: 
2016-06-03T12:51:58Z|1|vconn|WARN|unix:/var/run/openvswitch/br-int.mgmt: 
version negotiation failed (we support version 0x04, peer supports version 0x01)

2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib 
ovs-ofctl: br-int: fai

Re: [openstack-dev] [neutron][SFC]

[Cathy Zhang]

Hi Alioune,

Which OVS version are you using?
Try openvswitch version 2.4.0 and restart the openvswitch-server before 
installing the devstack.

Cathy

From: Alioune [mailto:baliou...@gmail.com]
Sent: Friday, June 03, 2016 9:07 AM
To: openstack-dev@lists.openstack.org
Cc: Cathy Zhang
Subject: [openstack-dev][neutron][SFC]

Probleme with OpenStack SFC
Hi all,
I've installed Openstack SFC with devstack and all module are corretly running 
except the neutron L2-agent

After a "screen -rd", it seems that there is a conflict between l2-agent and 
SFC (see trace bellow).
I solved the issue with "sudo ovs-vsctl set bridge br 
protocols=OpenFlow10,OpenFlow11,OpenFlow12,OpenFlow13" on all openvswitch 
bridge (br-int, br-ex, br-tun and br-mgmt0).
I would like to know:
  - If someone knows why this error arrises ?
 - is there another way to solve it ?

Regards,

2016-06-03 12:51:56.323 WARNING 
neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent 
[req-1258bbbc-7211-4cfd-ab7c-8b856604f768 None None] OVS is dead. 
OVSNeutronAgent will keep running and checking OVS status periodically.
2016-06-03 12:51:56.330 DEBUG 
neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent 
[req-1258bbbc-7211-4cfd-ab7c-8b856604f768 None None] Agent rpc_loop - 
iteration:4722 completed. Processed ports statistics: {'regular': {'updated': 
0, 'added': 0, 'removed': 0}}. Elapsed:0.086 from (pid=12775) 
loop_count_and_wait 
/opt/stack/neutron/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py:1680
2016-06-03 12:51:58.256 DEBUG 
neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent 
[req-1258bbbc-7211-4cfd-ab7c-8b856604f768 None None] Agent rpc_loop - 
iteration:4723 started from (pid=12775) rpc_loop 
/opt/stack/neutron/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py:1732
2016-06-03 12:51:58.258 DEBUG neutron.agent.linux.utils 
[req-1258bbbc-7211-4cfd-ab7c-8b856604f768 None None] Running command (rootwrap 
daemon): ['ovs-ofctl', '-O openflow13', 'dump-flows', 'br-int', 'table=23'] 
from (pid=12775) execute_rootwrap_daemon 
/opt/stack/neutron/neutron/agent/linux/utils.py:101
2016-06-03 12:51:58.311 ERROR neutron.agent.linux.utils 
[req-1258bbbc-7211-4cfd-ab7c-8b856604f768 None None]
Command: ['ovs-ofctl', '-O openflow13', 'dump-flows', 'br-int', 'table=23']
Exit code: 1
Stdin:
Stdout:
Stderr: 
2016-06-03T12:51:58Z|1|vconn|WARN|unix:/var/run/openvswitch/br-int.mgmt: 
version negotiation failed (we support version 0x04, peer supports version 0x01)
ovs-ofctl: br-int: failed to connect to socket (Broken pipe)

2016-06-03 12:51:58.323 ERROR networking_sfc.services.sfc.common.ovs_ext_lib 
[req-1258bbbc-7211-4cfd-ab7c-8b856604f768 None None]
Command: ['ovs-ofctl', '-O openflow13', 'dump-flows', 'br-int', 'table=23']
Exit code: 1
Stdin:
Stdout:
Stderr: 
2016-06-03T12:51:58Z|1|vconn|WARN|unix:/var/run/openvswitch/br-int.mgmt: 
version negotiation failed (we support version 0x04, peer supports version 0x01)
ovs-ofctl: br-int: failed to connect to socket (Broken pipe)

2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib 
Traceback (most recent call last):
2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib   
File 
"/opt/stack/networking-sfc/networking_sfc/services/sfc/common/ovs_ext_lib.py", 
line 125, in run_ofctl
2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib
 process_input=process_input)
2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib   
File "/opt/stack/neutron/neutron/agent/linux/utils.py", line 159, in execute
2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib
 raise RuntimeError(m)
2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib 
RuntimeError:
2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib 
Command: ['ovs-ofctl', '-O openflow13', 'dump-flows', 'br-int', 'table=23']
2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib 
Exit code: 1
2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib 
Stdin:
2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib 
Stdout:
2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib 
Stderr: 
2016-06-03T12:51:58Z|1|vconn|WARN|unix:/var/run/openvswitch/br-int.mgmt: 
version negotiation failed (we support version 0x04, peer supports version 0x01)
2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib 
ovs-ofctl: br-int: failed to connect to socket (Broken pipe)
2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib
2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib
2016-06-03 12:51:58.335 ERROR networking_sfc.services.sfc.common.ovs_ext_lib 
[req-1258bbbc-7211-4cfd-ab7c-8b856604f768 None None] Unable to execute 
['ovs-ofctl', '-O openflow13', '

[openstack-dev] [neutron][SFC]

[Alioune]

Probleme with OpenStack SFC
Hi all,
I've installed Openstack SFC with devstack and all module are corretly
running except the neutron L2-agent

After a "screen -rd", it seems that there is a conflict between l2-agent
and SFC (see trace bellow).
I solved the issue with "sudo ovs-vsctl set bridge br
protocols=OpenFlow10,OpenFlow11,OpenFlow12,OpenFlow13" on all openvswitch
bridge (br-int, br-ex, br-tun and br-mgmt0).
I would like to know:
  - If someone knows why this error arrises ?
 - is there another way to solve it ?

Regards,

2016-06-03 12:51:56.323 WARNING
neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
[req-1258bbbc-7211-4cfd-ab7c-8b856604f768 None None] OVS is dead.
OVSNeutronAgent will keep running and checking OVS status periodically.
2016-06-03 12:51:56.330 DEBUG
neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
[req-1258bbbc-7211-4cfd-ab7c-8b856604f768 None None] Agent rpc_loop -
iteration:4722 completed. Processed ports statistics: {'regular':
{'updated': 0, 'added': 0, 'removed': 0}}. Elapsed:0.086 from (pid=12775)
loop_count_and_wait
/opt/stack/neutron/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py:1680
2016-06-03 12:51:58.256 DEBUG
neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
[req-1258bbbc-7211-4cfd-ab7c-8b856604f768 None None] Agent rpc_loop -
iteration:4723 started from (pid=12775) rpc_loop
/opt/stack/neutron/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py:1732
2016-06-03 12:51:58.258 DEBUG neutron.agent.linux.utils
[req-1258bbbc-7211-4cfd-ab7c-8b856604f768 None None] Running command
(rootwrap daemon): ['ovs-ofctl', '-O openflow13', 'dump-flows', 'br-int',
'table=23'] from (pid=12775) execute_rootwrap_daemon
/opt/stack/neutron/neutron/agent/linux/utils.py:101
2016-06-03 12:51:58.311 ERROR neutron.agent.linux.utils
[req-1258bbbc-7211-4cfd-ab7c-8b856604f768 None None]
Command: ['ovs-ofctl', '-O openflow13', 'dump-flows', 'br-int', 'table=23']
Exit code: 1
Stdin:
Stdout:
Stderr:
2016-06-03T12:51:58Z|1|vconn|WARN|unix:/var/run/openvswitch/br-int.mgmt:
version negotiation failed (we support version 0x04, peer supports version
0x01)
ovs-ofctl: br-int: failed to connect to socket (Broken pipe)

2016-06-03 12:51:58.323 ERROR
networking_sfc.services.sfc.common.ovs_ext_lib
[req-1258bbbc-7211-4cfd-ab7c-8b856604f768 None None]
Command: ['ovs-ofctl', '-O openflow13', 'dump-flows', 'br-int', 'table=23']
Exit code: 1
Stdin:
Stdout:
Stderr:
2016-06-03T12:51:58Z|1|vconn|WARN|unix:/var/run/openvswitch/br-int.mgmt:
version negotiation failed (we support version 0x04, peer supports version
0x01)
ovs-ofctl: br-int: failed to connect to socket (Broken pipe)

2016-06-03 12:51:58.323 TRACE
networking_sfc.services.sfc.common.ovs_ext_lib Traceback (most recent call
last):
2016-06-03 12:51:58.323 TRACE
networking_sfc.services.sfc.common.ovs_ext_lib   File
"/opt/stack/networking-sfc/networking_sfc/services/sfc/common/ovs_ext_lib.py",
line 125, in run_ofctl
2016-06-03 12:51:58.323 TRACE
networking_sfc.services.sfc.common.ovs_ext_lib
process_input=process_input)
2016-06-03 12:51:58.323 TRACE
networking_sfc.services.sfc.common.ovs_ext_lib   File
"/opt/stack/neutron/neutron/agent/linux/utils.py", line 159, in execute
2016-06-03 12:51:58.323 TRACE
networking_sfc.services.sfc.common.ovs_ext_lib raise RuntimeError(m)
2016-06-03 12:51:58.323 TRACE
networking_sfc.services.sfc.common.ovs_ext_lib RuntimeError:
2016-06-03 12:51:58.323 TRACE
networking_sfc.services.sfc.common.ovs_ext_lib Command: ['ovs-ofctl', '-O
openflow13', 'dump-flows', 'br-int', 'table=23']
2016-06-03 12:51:58.323 TRACE
networking_sfc.services.sfc.common.ovs_ext_lib Exit code: 1
2016-06-03 12:51:58.323 TRACE
networking_sfc.services.sfc.common.ovs_ext_lib Stdin:
2016-06-03 12:51:58.323 TRACE
networking_sfc.services.sfc.common.ovs_ext_lib Stdout:
2016-06-03 12:51:58.323 TRACE
networking_sfc.services.sfc.common.ovs_ext_lib Stderr:
2016-06-03T12:51:58Z|1|vconn|WARN|unix:/var/run/openvswitch/br-int.mgmt:
version negotiation failed (we support version 0x04, peer supports version
0x01)
2016-06-03 12:51:58.323 TRACE
networking_sfc.services.sfc.common.ovs_ext_lib ovs-ofctl: br-int: failed to
connect to socket (Broken pipe)
2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib
2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib
2016-06-03 12:51:58.335 ERROR
networking_sfc.services.sfc.common.ovs_ext_lib
[req-1258bbbc-7211-4cfd-ab7c-8b856604f768 None None] Unable to execute
['ovs-ofctl', '-O openflow13', 'dump-flows', 'br-int', 'table=23'].
2016-06-03 12:51:58.337 WARNING
neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
[req-1258bbbc-7211-4cfd-ab7c-8b856604f768 None None] OVS is dead.
OVSNeutronAgent will keep running and checking OVS status periodically.
2016-06-03 12:51:58.341 DEBUG
neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
[req-1258bbbc-7211-4cfd-ab7c-8b856604f768 None 

[openstack-dev] [neutron][sfc] Is there a bug in networking-sfc?

[张广明]

Hi Cathy and other guys
 I am a beginner that use networking-sfc. I create a port-chain-list
that want to steer a flow that is  from public-net to private-net  to SF
node.  The DVR is enable in my test environment.
The test result is the flow was steered from destination node  to SF node
and return to the destination  node rightly, but the flow was match the
classify rule again,so the flow can not to be send to
the destination VM.
  In networking-sfc agent code . there is a
function update_src_node_flow_rules  that create a normal flow to handle
this case. But in networking-sfc ovs dirver code,
_update_src_node_flowrules  can't
call ask_agent_to_update_src_node_flow_rules to notify agent to
exec update_src_node_flow_rules. The reason is  the function
 _get_portchain_src_node_flowrule return None. In  function
_get_portchain_src_node_flowrule , the check
that was marked red is not right in this  case.


def _get_portchain_src_node_flowrule(self, node,
 add_fc_ids=None, del_fc_ids=None):
try:
add_fc_rt = []
del_fc_rt = []

if add_fc_ids:
for fc in self._get_fcs_by_ids(add_fc_ids):
if not fc.get('logical_source_port', None):
add_fc_rt.append(fc)

if del_fc_ids:
for fc in self._get_fcs_by_ids(del_fc_ids):
if not fc.get('logical_source_port', None):
del_fc_rt.append(fc)

if not add_fc_rt and not del_fc_rt:
return None

return self._build_portchain_flowrule_body_without_port(
node, add_fc_rt, del_fc_rt)
except Exception as e:
LOG.exception(e)
LOG.error(_LE("_get_portchain_src_node_flowrule failed"))


  Is it a bug or my configure is wrong?



root@rg1-com01 ~]# neutron  flow-classifier-show
 4542a747-b205-41ff-970c-1ea11fa956fc
++--+
| Field  | Value|
++--+
| description|  |
| destination_ip_prefix  | 192.168.1.0/24   |
| destination_port_range_max |  |
| destination_port_range_min |  |
| ethertype  | IPv4 |
| id | 4542a747-b205-41ff-970c-1ea11fa956fc |
| l7_parameters  | {}   |
| logical_destination_port   |  |
| logical_source_port| f18895cf-6c4b-495a-8bd5-e8f12ae86541 |
| name   | FC-F3|
| protocol   |  |
| source_ip_prefix   | 192.168.200.0/24 |
| source_port_range_max  |  |
| source_port_range_min  |  |
| tenant_id  | 02e5a953a113479388103c585f5b5ae1 |
++--+

the original flow  is 192.168.200.2 to 192.168.200.202 floatingip(
192.168.1.202  private ip)
logical_source_port  is  fg-xxx interface in namespace fip.

Thanks
Jim
__
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] [neutron][sfc] A standards-compliant SFC API

[Armando M.]

On 20 April 2016 at 09:31, Duarte Cardoso, Igor <
igor.duarte.card...@intel.com> wrote:

> Dear OpenStack Community,
>
>
>
> We've been investigating options in/around OpenStack for supporting
> Service Function Chaining. The networking-sfc project has made significant
> progress in this space, and we see lots of value in what has been
> completed. However, when we looked at the related IETF specs on SFC we
> concluded that there would be value in further developing an SFC API and
> related classification functionality to enhance the alignment between the
> work in the OpenStack community with the standards work. We would like to
> propose the SFC part as a potential networking-sfc v2 API, but are open to
> other options too based on your feedback.
>
>
>
> I have submitted a spec to the neutron-specs repo [1], where you can check
> what our initial thoughts for this new API are, and provide your feedback
> or questions regarding the same.
>
>
>
> Your thoughts on this are deeply appreciated. We are looking forward to
> having further discussions with everyone interested in giving feedback or
> establishing collaborations during the OpenStack Summit in Austin.
>
>
>
> [1] https://review.openstack.org/#/c/308453
>

Thanks for reaching out.

The networking-sfc initiative so far has been pretty autonomous. The
project has its own launchpad project [1] and its own docs to document APIs
and proposals [2]. During the long journey that Neutron has been through,
we have been adjusting how to manage the project in order to strike a good
balance between development agility, product stability and community needs.
We're always looking forward to improving that balance and this means that
how we track certain initiatives may evolve in the future. For now, it's
probably best to target the mailing list with tag [networking-sfc] (in
addition to neutron), as well as the project noted below.

[1] https://launchpad.net/networking-sfc
[2] http://docs.openstack.org/developer/networking-sfc/


>
> Thank you,
>
> Igor & the Intel OpenStack networking team.
>
> __
> 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] [neutron][sfc] A standards-compliant SFC API

[Duarte Cardoso, Igor]

Dear OpenStack Community,

We've been investigating options in/around OpenStack for supporting Service 
Function Chaining. The networking-sfc project has made significant progress in 
this space, and we see lots of value in what has been completed. However, when 
we looked at the related IETF specs on SFC we concluded that there would be 
value in further developing an SFC API and related classification functionality 
to enhance the alignment between the work in the OpenStack community with the 
standards work. We would like to propose the SFC part as a potential 
networking-sfc v2 API, but are open to other options too based on your feedback.

I have submitted a spec to the neutron-specs repo [1], where you can check what 
our initial thoughts for this new API are, and provide your feedback or 
questions regarding the same.

Your thoughts on this are deeply appreciated. We are looking forward to having 
further discussions with everyone interested in giving feedback or establishing 
collaborations during the OpenStack Summit in Austin.

[1] https://review.openstack.org/#/c/308453

Thank you,
Igor & the Intel OpenStack networking team.
__
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] [neutron][sfc]

[Cathy Zhang]

Hi Oguz,

I will forward you the email on the steps of using DevStack to set up SFC. 

As you mentioned, the DevStack support patch for networking-sfc is being worked 
on and under review. 
The codes that support this feature including unit test codes have been 
developed and uploaded for review. We are now  actively working on integration 
testing of all code pieces as well as end-to-end testing of this feature, and 
bug fixes. 

Thanks,
Cathy

-Original Message-
From: Oguz Yarimtepe [mailto:oguzyarimt...@gmail.com] 
Sent: Tuesday, November 24, 2015 1:38 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [neutron][sfc]

Hi,

Is there any working Devstack configuration for sfc testing? I just saw one 
commit that is waiting review.

__
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] [neutron][sfc]

[Oguz Yarimtepe]

Hi,

Is there any working Devstack configuration for sfc testing? I just saw 
one commit that is waiting review.


__
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] [neutron][sfc] How could an L2 agent extension access agent methods ?

[Andreas Scheuring]

Perfect.

The agent will have all static hooks for the extensions in place, like
they are used in todays agents (the modular agent was derived from
existing lb agent). The knowledge which concrete extension
implementation to chose (e.g. lb) comes from the implementation specific
manager class that is required for instantiating the modular agent. So
it is ensured that with lb you get the lb extensions, with sriov you get
the sriov extensions.

There are no plans to make extensions more "modular" (whatever this
means in this context) as well in the first round. But we can discuss
for a second stage.

Thanks

-- 
Andreas
(IRC: scheuran)



On Mi, 2015-11-18 at 15:28 +0100, Ihar Hrachyshka wrote:
> Andreas Scheuring  wrote:
> 
> > Hi all,
> > I wonder if this is somehow in conflict with the modular l2 agent
> > approach I'm currently following up for linuxbridge, macvtap and sriov?
> > - RFE: [1]
> > - Frist patchset [2]
> >
> > I don't think so, but to be sure I wanted to raise it up.
> 
> I don’t believe it’s in conflict, though generally, I suggest you move  
> extensions code into modular l2 agent pieces, if possible. We will have  
> extensions enabled for lb, ovs, and sr-iov the least in Mitaka.
> 
> Ihar
> 
> __
> 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] [neutron][sfc] How could an L2 agent extension access agent methods ?

[Andreas Scheuring]

Hi all, 
I wonder if this is somehow in conflict with the modular l2 agent
approach I'm currently following up for linuxbridge, macvtap and sriov?
- RFE: [1]
- Frist patchset [2]

I don't think so, but to be sure I wanted to raise it up.




[1] https://bugs.launchpad.net/neutron/+bug/1468803
[2] https://review.openstack.org/#/c/246318/

-- 
Andreas
(IRC: scheuran)



On Mo, 2015-11-16 at 20:42 +, Cathy Zhang wrote:
> I have updated the etherpad to add "Overall requirement - API cross check 
> among the features that can manipulate the same flow's forwarding behavior".
> 
> Thanks,
> Cathy
> 
> -Original Message-
> From: Paul Carver [mailto:pcar...@paulcarver.us] 
> Sent: Monday, November 16, 2015 7:50 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [neutron][sfc] How could an L2 agent extension 
> access agent methods ?
> 
> On 11/13/2015 7:03 PM, Henry Fourie wrote:
> 
> >
> >   I wonder whether just pushing flows into the existing tables at random 
> > points in time can be unstable and break the usual flow assumed by the main 
> > agent loop.
> > LF> No not expect any issues.
> >
> > Am I making sense?
> >
> > [1] https://etherpad.openstack.org/p/l2-agent-extensions-api-expansion
> >
> 
> I attempted to describe a possible issue at the bottom of the Etherpad in the 
> bullet point "Overall requirement - Flow prioritization mechanism"
> 
> 
> 
> __
> 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] [neutron][sfc] How could an L2 agent extension access agent methods ?

[Ihar Hrachyshka]

Andreas Scheuring  wrote:


Hi all,
I wonder if this is somehow in conflict with the modular l2 agent
approach I'm currently following up for linuxbridge, macvtap and sriov?
- RFE: [1]
- Frist patchset [2]

I don't think so, but to be sure I wanted to raise it up.


I don’t believe it’s in conflict, though generally, I suggest you move  
extensions code into modular l2 agent pieces, if possible. We will have  
extensions enabled for lb, ovs, and sr-iov the least in Mitaka.


Ihar

__
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] [neutron][sfc] How could an L2 agent extension access agent methods ?

[Paul Carver]

On 11/13/2015 7:03 PM, Henry Fourie wrote:



  I wonder whether just pushing flows into the existing tables at random points 
in time can be unstable and break the usual flow assumed by the main agent loop.
LF> No not expect any issues.

Am I making sense?

[1] https://etherpad.openstack.org/p/l2-agent-extensions-api-expansion



I attempted to describe a possible issue at the bottom of the Etherpad 
in the bullet point "Overall requirement - Flow prioritization mechanism"




__
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] [neutron][sfc] How could an L2 agent extension access agent methods ?

[Cathy Zhang]

I have updated the etherpad to add "Overall requirement - API cross check among 
the features that can manipulate the same flow's forwarding behavior".

Thanks,
Cathy

-Original Message-
From: Paul Carver [mailto:pcar...@paulcarver.us] 
Sent: Monday, November 16, 2015 7:50 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][sfc] How could an L2 agent extension 
access agent methods ?

On 11/13/2015 7:03 PM, Henry Fourie wrote:

>
>   I wonder whether just pushing flows into the existing tables at random 
> points in time can be unstable and break the usual flow assumed by the main 
> agent loop.
> LF> No not expect any issues.
>
> Am I making sense?
>
> [1] https://etherpad.openstack.org/p/l2-agent-extensions-api-expansion
>

I attempted to describe a possible issue at the bottom of the Etherpad in the 
bullet point "Overall requirement - Flow prioritization mechanism"



__
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] [neutron][sfc] How could an L2 agent extension access agent methods ?

[Henry Fourie]

Ihar,
   See inline.
- Louis

-Original Message-
From: Ihar Hrachyshka [mailto:ihrac...@redhat.com] 
Sent: Thursday, November 12, 2015 1:12 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][sfc] How could an L2 agent extension 
access agent methods ?

Henry Fourie <louis.fou...@huawei.com> wrote:

> Ihar,
>Networking-sfc installs flows on br-int and br-tun for steering 
> traffic to the SFC port-pairs. On each bridge additional tables are 
> used for an egress forwarding pipeline (from the service VM port) and 
> an ingress pipeline (to the service VM port). Rpc operations between 
> the OVS driver and agents is used to initiate the flow installation.
>
> We'd like to work with you on defining the L2 extensions.

Hi Henry,

thanks for taking time to specify your needs. Could you please update the 
etherpad [1] with these details?

LF> Will do.

Speaking of new ovs tables you need, how do you reference to them?
LF> br-int has one new table SF_SELECTOR in the ingress pipeline that is used 
steer traffic to the correct service VM
by matching on the NSP (Network Service Path) of the MPLS (NSH) header.
br-tun has two new tables in the egress pipeline: GRP_SELECTOR used to select a 
Group Table by matching on the NSP of the MPLS (NSH) header
and a set of Group Tables to perform load distribution for a port-pair group.
  
 Is there any ordering guarantees for flows you will need to set that should be 
provided in scope of that public API of the agent?
LF> No.

 I wonder whether just pushing flows into the existing tables at random points 
in time can be unstable and break the usual flow assumed by the main agent loop.
LF> No not expect any issues.

Am I making sense?

[1] https://etherpad.openstack.org/p/l2-agent-extensions-api-expansion

Ihar

__
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] [neutron][sfc] How could an L2 agent extension access agent methods ?

[Ihar Hrachyshka]

Henry Fourie  wrote:


Ihar,
   Networking-sfc installs flows on br-int and br-tun for steering
traffic to the SFC port-pairs. On each bridge additional tables are used
for an egress forwarding pipeline (from the service VM port) and an
ingress pipeline (to the service VM port). Rpc operations between the
OVS driver and agents is used to initiate the flow installation.

We'd like to work with you on defining the L2 extensions.


Hi Henry,

thanks for taking time to specify your needs. Could you please update the  
etherpad [1] with these details?


Speaking of new ovs tables you need, how do you reference to them? Is there  
any ordering guarantees for flows you will need to set that should be  
provided in scope of that public API of the agent? I wonder whether just  
pushing flows into the existing tables at random points in time can be  
unstable and break the usual flow assumed by the main agent loop.


Am I making sense?

[1] https://etherpad.openstack.org/p/l2-agent-extensions-api-expansion

Ihar

__
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] [neutron][sfc] How could an L2 agent extension access agent methods ?

[Paul Carver]

On 11/9/2015 9:59 PM, Vikram Choudhary wrote:

Hi Cathy,

Could you please check on this. My mother passed away yesterday and I
will be on leave for couple of weeks.


I'm very sorry to hear that. Please take all the time you need.


__
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] [neutron][sfc] How could an L2 agent extension access agent methods ?

[Henry Fourie]

Ihar,
   Networking-sfc installs flows on br-int and br-tun for steering
traffic to the SFC port-pairs. On each bridge additional tables are used
for an egress forwarding pipeline (from the service VM port) and an
ingress pipeline (to the service VM port). Rpc operations between the
OVS driver and agents is used to initiate the flow installation.

We'd like to work with you on defining the L2 extensions.

 - Louis


- 
-Original Message-
From: Ihar Hrachyshka [mailto:ihrac...@redhat.com] 
Sent: Monday, November 09, 2015 4:44 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][sfc] How could an L2 agent extension 
access agent methods ?

Thanks Thomas, much appreciated.

I need to admit that we haven’t heard from SFC folks just yet. I will try to 
raise awareness that we wait for their feedback today on team meeting.  
Adding [sfc] tag to the topic to get more attention.

Ihar

Thomas Morin <thomas.mo...@orange.com> wrote:

> Hi Ihar,
>
> Ihar Hrachyshka :
>> Reviving the thread.
>> [...] (I appreciate if someone checks me on the following though):
>
> This is an excellent recap.
>
>>  I set up a new etherpad to collect feedback from subprojects [2].
>
> I've filled in details for networking-bgpvpn.
> Please tell me if you need more information.
>
>> Once we collect use cases there and agree on agent API for extensions 
>> (even if per agent type), we will implement it and define as stable 
>> API, then pass objects that implement the API into extensions thru 
>> extension manager. If extensions support multiple agent types, they 
>> can still distinguish between which API to use based on agent type 
>> string passed into extension manager.
>>
>> I really hope we start to collect use cases early so that we have 
>> time to polish agent API and make it part of l2 extensions earlier in 
>> Mitaka cycle.
>
> We'll be happy to validate the applicability of this approach as soon 
> as something is ready.
>
> Thanks for taking up this work!
>
> -Thomas
>
>
>
>> Ihar Hrachyshka <ihrac...@redhat.com> wrote:
>>
>>>> On 30 Sep 2015, at 12:53, Miguel Angel Ajo <mangel...@redhat.com> wrote:
>>>>
>>>>
>>>>
>>>> Ihar Hrachyshka wrote:
>>>>>> On 30 Sep 2015, at 12:08, thomas.mo...@orange.com wrote:
>>>>>>
>>>>>> Hi Ihar,
>>>>>>
>>>>>> Ihar Hrachyshka :
>>>>>>>> Miguel Angel Ajo :
>>>>>>>>> Do you have a rough idea of what operations you may need to do?
>>>>>>>> Right now, what bagpipe driver for networking-bgpvpn needs to 
>>>>>>>> interact with is:
>>>>>>>> - int_br OVSBridge (read-only)
>>>>>>>> - tun_br OVSBridge (add patch port, add flows)
>>>>>>>> - patch_int_ofport port number (read-only)
>>>>>>>> - local_vlan_map dict (read-only)
>>>>>>>> - setup_entry_for_arp_reply method (called to add static ARP
>>>>>>>> entries)
>>>>>>> Sounds very tightly coupled to OVS agent.
>>>>>>>>> Please bear in mind, the extension interface will be available 
>>>>>>>>> from different agent types (OVS, SR-IOV, [eventually LB]), so 
>>>>>>>>> this interface you're talking about could also serve as a 
>>>>>>>>> translation driver for the agents (where the translation is 
>>>>>>>>> possible), I totally understand that most extensions are 
>>>>>>>>> specific agent bound, and we must be able to identify the 
>>>>>>>>> agent we're serving back exactly.
>>>>>>>> Yes, I do have this in mind, but what we've identified for now 
>>>>>>>> seems to be OVS specific.
>>>>>>> Indeed it does. Maybe you can try to define the needed pieces in 
>>>>>>> high level actions, not internal objects you need to access to.
>>>>>>> Like ‘- connect endpoint X to Y’, ‘determine segmentation id for 
>>>>>>> a network’ etc.
>>>>>> I've been thinking about this, but would tend to reach the 
>>>>>> conclusion that the things we need to interact with are pretty 
>>>>>> hard to abstract out into something that would be generic across 
>>>>>> different agents.  Everything we need to do in our case relates 
>>>>>> to how the agents use

Re: [openstack-dev] [neutron][sfc] How could an L2 agent extension access agent methods ?

[Cathy Zhang]

Hi Ihar,

Thanks for initiating this discussion. I am in OPNFV Summit. Henry Fourie of 
SFC project team will reply with our feedback. 

Cathy

-Original Message-
From: Ihar Hrachyshka [mailto:ihrac...@redhat.com] 
Sent: Monday, November 09, 2015 4:44 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][sfc] How could an L2 agent extension 
access agent methods ?

Thanks Thomas, much appreciated.

I need to admit that we haven’t heard from SFC folks just yet. I will try to 
raise awareness that we wait for their feedback today on team meeting.  
Adding [sfc] tag to the topic to get more attention.

Ihar

Thomas Morin <thomas.mo...@orange.com> wrote:

> Hi Ihar,
>
> Ihar Hrachyshka :
>> Reviving the thread.
>> [...] (I appreciate if someone checks me on the following though):
>
> This is an excellent recap.
>
>>  I set up a new etherpad to collect feedback from subprojects [2].
>
> I've filled in details for networking-bgpvpn.
> Please tell me if you need more information.
>
>> Once we collect use cases there and agree on agent API for extensions 
>> (even if per agent type), we will implement it and define as stable 
>> API, then pass objects that implement the API into extensions thru 
>> extension manager. If extensions support multiple agent types, they 
>> can still distinguish between which API to use based on agent type 
>> string passed into extension manager.
>>
>> I really hope we start to collect use cases early so that we have 
>> time to polish agent API and make it part of l2 extensions earlier in 
>> Mitaka cycle.
>
> We'll be happy to validate the applicability of this approach as soon 
> as something is ready.
>
> Thanks for taking up this work!
>
> -Thomas
>
>
>
>> Ihar Hrachyshka <ihrac...@redhat.com> wrote:
>>
>>>> On 30 Sep 2015, at 12:53, Miguel Angel Ajo <mangel...@redhat.com> wrote:
>>>>
>>>>
>>>>
>>>> Ihar Hrachyshka wrote:
>>>>>> On 30 Sep 2015, at 12:08, thomas.mo...@orange.com wrote:
>>>>>>
>>>>>> Hi Ihar,
>>>>>>
>>>>>> Ihar Hrachyshka :
>>>>>>>> Miguel Angel Ajo :
>>>>>>>>> Do you have a rough idea of what operations you may need to do?
>>>>>>>> Right now, what bagpipe driver for networking-bgpvpn needs to 
>>>>>>>> interact with is:
>>>>>>>> - int_br OVSBridge (read-only)
>>>>>>>> - tun_br OVSBridge (add patch port, add flows)
>>>>>>>> - patch_int_ofport port number (read-only)
>>>>>>>> - local_vlan_map dict (read-only)
>>>>>>>> - setup_entry_for_arp_reply method (called to add static ARP
>>>>>>>> entries)
>>>>>>> Sounds very tightly coupled to OVS agent.
>>>>>>>>> Please bear in mind, the extension interface will be available 
>>>>>>>>> from different agent types (OVS, SR-IOV, [eventually LB]), so 
>>>>>>>>> this interface you're talking about could also serve as a 
>>>>>>>>> translation driver for the agents (where the translation is 
>>>>>>>>> possible), I totally understand that most extensions are 
>>>>>>>>> specific agent bound, and we must be able to identify the 
>>>>>>>>> agent we're serving back exactly.
>>>>>>>> Yes, I do have this in mind, but what we've identified for now 
>>>>>>>> seems to be OVS specific.
>>>>>>> Indeed it does. Maybe you can try to define the needed pieces in 
>>>>>>> high level actions, not internal objects you need to access to.
>>>>>>> Like ‘- connect endpoint X to Y’, ‘determine segmentation id for 
>>>>>>> a network’ etc.
>>>>>> I've been thinking about this, but would tend to reach the 
>>>>>> conclusion that the things we need to interact with are pretty 
>>>>>> hard to abstract out into something that would be generic across 
>>>>>> different agents.  Everything we need to do in our case relates 
>>>>>> to how the agents use bridges and represent networks internally:
>>>>>> linuxbridge has one bridge per Network, while OVS has a limited 
>>>>>> number of bridges playing different roles for all networks with 
>>>>>> internal segmentation.
&g

Re: [openstack-dev] [neutron][sfc] How could an L2 agent extension access agent methods ?

[Cathy Zhang]

Hi Vikram,

Thanks for the heads-up. Take care of yourself and your family.
We will provide the feedback on L2 agent.

Thanks,
Cathy

From: Vikram Choudhary [mailto:viks...@gmail.com]
Sent: Monday, November 09, 2015 6:59 PM
To: OpenStack Development Mailing List (not for usage questions); Cathy Zhang
Subject: Re: [openstack-dev] [neutron][sfc] How could an L2 agent extension 
access agent methods ?


Hi Cathy,

Could you please check on this. My mother passed away yesterday and I will be 
on leave for couple of weeks.

Thanks
Vikram
On 09-Nov-2015 6:15 pm, "Ihar Hrachyshka" 
<ihrac...@redhat.com<mailto:ihrac...@redhat.com>> wrote:
Thanks Thomas, much appreciated.

I need to admit that we haven’t heard from SFC folks just yet. I will try to 
raise awareness that we wait for their feedback today on team meeting. Adding 
[sfc] tag to the topic to get more attention.

Ihar

Thomas Morin <thomas.mo...@orange.com<mailto:thomas.mo...@orange.com>> wrote:
Hi Ihar,

Ihar Hrachyshka :
Reviving the thread.
[...] (I appreciate if someone checks me on the following though):

This is an excellent recap.
 I set up a new etherpad to collect feedback from subprojects [2].

I've filled in details for networking-bgpvpn.
Please tell me if you need more information.
Once we collect use cases there and agree on agent API for extensions (even if 
per agent type), we will implement it and define as stable API, then pass 
objects that implement the API into extensions thru extension manager. If 
extensions support multiple agent types, they can still distinguish between 
which API to use based on agent type string passed into extension manager.

I really hope we start to collect use cases early so that we have time to 
polish agent API and make it part of l2 extensions earlier in Mitaka cycle.

We'll be happy to validate the applicability of this approach as soon as 
something is ready.

Thanks for taking up this work!

-Thomas


Ihar Hrachyshka <ihrac...@redhat.com<mailto:ihrac...@redhat.com>> wrote:
On 30 Sep 2015, at 12:53, Miguel Angel Ajo 
<mangel...@redhat.com<mailto:mangel...@redhat.com>> wrote:



Ihar Hrachyshka wrote:
On 30 Sep 2015, at 12:08, 
thomas.mo...@orange.com<mailto:thomas.mo...@orange.com> wrote:

Hi Ihar,

Ihar Hrachyshka :
Miguel Angel Ajo :
Do you have a rough idea of what operations you may need to do?
Right now, what bagpipe driver for networking-bgpvpn needs to interact with is:
- int_br OVSBridge (read-only)
- tun_br OVSBridge (add patch port, add flows)
- patch_int_ofport port number (read-only)
- local_vlan_map dict (read-only)
- setup_entry_for_arp_reply method (called to add static ARP entries)
Sounds very tightly coupled to OVS agent.
Please bear in mind, the extension interface will be available from different 
agent types
(OVS, SR-IOV, [eventually LB]), so this interface you're talking about could 
also serve as
a translation driver for the agents (where the translation is possible), I 
totally understand
that most extensions are specific agent bound, and we must be able to identify
the agent we're serving back exactly.
Yes, I do have this in mind, but what we've identified for now seems to be OVS 
specific.
Indeed it does. Maybe you can try to define the needed pieces in high level 
actions, not internal objects you need to access to. Like ‘- connect endpoint X 
to Y’, ‘determine segmentation id for a network’ etc.
I've been thinking about this, but would tend to reach the conclusion that the 
things we need to interact with are pretty hard to abstract out into something 
that would be generic across different agents.  Everything we need to do in our 
case relates to how the agents use bridges and represent networks internally: 
linuxbridge has one bridge per Network, while OVS has a limited number of 
bridges playing different roles for all networks with internal segmentation.

To look at the two things you  mention:
- "connect endpoint X to Y" : what we need to do is redirect the traffic 
destinated to the gateway of a Neutron network, to the thing that will do the 
MPLS forwarding for the right BGP VPN context (called VRF), in our case br-mpls 
(that could be done with an OVS table too) ; that action might be abstracted 
out to hide the details specific to OVS, but I'm not sure on how to  name the 
destination in a way that would be agnostic to these details, and this is not 
really relevant to do until we have a relevant context in which the linuxbridge 
would pass packets to something doing MPLS forwarding (OVS is currently the 
only option we support for MPLS forwarding, and it does not really make sense 
to mix linuxbridge for Neutron L2/L3 and OVS for MPLS)
- "determine segmentation id for a network": this is something really 
OVS-agent-specific, the linuxbridge agent uses multiple linux bridges, and does 
not rely on internal segmentation

Completely abstracting out packet forwarding pipelines in OVS and

Re: [openstack-dev] [neutron][sfc] How could an L2 agent extension access agent methods ?

[Ihar Hrachyshka]

Thanks Thomas, much appreciated.

I need to admit that we haven’t heard from SFC folks just yet. I will try  
to raise awareness that we wait for their feedback today on team meeting.  
Adding [sfc] tag to the topic to get more attention.


Ihar

Thomas Morin  wrote:


Hi Ihar,

Ihar Hrachyshka :

Reviving the thread.
[...] (I appreciate if someone checks me on the following though):


This is an excellent recap.


 I set up a new etherpad to collect feedback from subprojects [2].


I've filled in details for networking-bgpvpn.
Please tell me if you need more information.

Once we collect use cases there and agree on agent API for extensions  
(even if per agent type), we will implement it and define as stable API,  
then pass objects that implement the API into extensions thru extension  
manager. If extensions support multiple agent types, they can still  
distinguish between which API to use based on agent type string passed  
into extension manager.


I really hope we start to collect use cases early so that we have time  
to polish agent API and make it part of l2 extensions earlier in Mitaka  
cycle.


We'll be happy to validate the applicability of this approach as soon as  
something is ready.


Thanks for taking up this work!

-Thomas




Ihar Hrachyshka  wrote:


On 30 Sep 2015, at 12:53, Miguel Angel Ajo  wrote:



Ihar Hrachyshka wrote:

On 30 Sep 2015, at 12:08, thomas.mo...@orange.com wrote:

Hi Ihar,

Ihar Hrachyshka :

Miguel Angel Ajo :

Do you have a rough idea of what operations you may need to do?
Right now, what bagpipe driver for networking-bgpvpn needs to  
interact with is:

- int_br OVSBridge (read-only)
- tun_br OVSBridge (add patch port, add flows)
- patch_int_ofport port number (read-only)
- local_vlan_map dict (read-only)
- setup_entry_for_arp_reply method (called to add static ARP  
entries)

Sounds very tightly coupled to OVS agent.
Please bear in mind, the extension interface will be available  
from different agent types
(OVS, SR-IOV, [eventually LB]), so this interface you're talking  
about could also serve as
a translation driver for the agents (where the translation is  
possible), I totally understand
that most extensions are specific agent bound, and we must be  
able to identify

the agent we're serving back exactly.
Yes, I do have this in mind, but what we've identified for now  
seems to be OVS specific.
Indeed it does. Maybe you can try to define the needed pieces in  
high level actions, not internal objects you need to access to.  
Like ‘- connect endpoint X to Y’, ‘determine segmentation id for a  
network’ etc.
I've been thinking about this, but would tend to reach the  
conclusion that the things we need to interact with are pretty hard  
to abstract out into something that would be generic across  
different agents.  Everything we need to do in our case relates to  
how the agents use bridges and represent networks internally:  
linuxbridge has one bridge per Network, while OVS has a limited  
number of bridges playing different roles for all networks with  
internal segmentation.


To look at the two things you  mention:
- "connect endpoint X to Y" : what we need to do is redirect the  
traffic destinated to the gateway of a Neutron network, to the thing  
that will do the MPLS forwarding for the right BGP VPN context  
(called VRF), in our case br-mpls (that could be done with an OVS  
table too) ; that action might be abstracted out to hide the details  
specific to OVS, but I'm not sure on how to  name the destination in  
a way that would be agnostic to these details, and this is not  
really relevant to do until we have a relevant context in which the  
linuxbridge would pass packets to something doing MPLS forwarding  
(OVS is currently the only option we support for MPLS forwarding,  
and it does not really make sense to mix linuxbridge for Neutron  
L2/L3 and OVS for MPLS)
- "determine segmentation id for a network": this is something  
really OVS-agent-specific, the linuxbridge agent uses multiple linux  
bridges, and does not rely on internal segmentation


Completely abstracting out packet forwarding pipelines in OVS and  
linuxbridge agents would possibly allow defining an interface that  
agent extension could use without to know about anything specific to  
OVS or the linuxbridge, but I believe this is a very significant  
taks to tackle.


If you look for a clean way to integrate with reference agents, then  
it’s something that we should try to achieve. I agree it’s not an  
easy thing.


Just an idea: can we have a resource for traffic forwarding, similar  
to security groups? I know folks are not ok with extending security  
groups API due to compatibility reasons, so maybe fwaas is the place  
to experiment with it.


Hopefully it will be acceptable to create an interface, even it  
exposes a set of methods specific to the linuxbridge agent and a set  
of methods 

Re: [openstack-dev] [neutron][sfc] How could an L2 agent extension access agent methods ?

[Vikram Choudhary]

Hi Cathy,

Could you please check on this. My mother passed away yesterday and I will
be on leave for couple of weeks.

Thanks
Vikram
On 09-Nov-2015 6:15 pm, "Ihar Hrachyshka"  wrote:

> Thanks Thomas, much appreciated.
>
> I need to admit that we haven’t heard from SFC folks just yet. I will try
> to raise awareness that we wait for their feedback today on team meeting.
> Adding [sfc] tag to the topic to get more attention.
>
> Ihar
>
> Thomas Morin  wrote:
>
> Hi Ihar,
>>
>> Ihar Hrachyshka :
>>
>>> Reviving the thread.
>>> [...] (I appreciate if someone checks me on the following though):
>>>
>>
>> This is an excellent recap.
>>
>>  I set up a new etherpad to collect feedback from subprojects [2].
>>>
>>
>> I've filled in details for networking-bgpvpn.
>> Please tell me if you need more information.
>>
>> Once we collect use cases there and agree on agent API for extensions
>>> (even if per agent type), we will implement it and define as stable API,
>>> then pass objects that implement the API into extensions thru extension
>>> manager. If extensions support multiple agent types, they can still
>>> distinguish between which API to use based on agent type string passed into
>>> extension manager.
>>>
>>> I really hope we start to collect use cases early so that we have time
>>> to polish agent API and make it part of l2 extensions earlier in Mitaka
>>> cycle.
>>>
>>
>> We'll be happy to validate the applicability of this approach as soon as
>> something is ready.
>>
>> Thanks for taking up this work!
>>
>> -Thomas
>>
>>
>>
>> Ihar Hrachyshka  wrote:
>>>
>>> On 30 Sep 2015, at 12:53, Miguel Angel Ajo  wrote:
>
>
>
> Ihar Hrachyshka wrote:
>
>> On 30 Sep 2015, at 12:08, thomas.mo...@orange.com wrote:
>>>
>>> Hi Ihar,
>>>
>>> Ihar Hrachyshka :
>>>
 Miguel Angel Ajo :
>
>> Do you have a rough idea of what operations you may need to do?
>>
> Right now, what bagpipe driver for networking-bgpvpn needs to
> interact with is:
> - int_br OVSBridge (read-only)
> - tun_br OVSBridge (add patch port, add flows)
> - patch_int_ofport port number (read-only)
> - local_vlan_map dict (read-only)
> - setup_entry_for_arp_reply method (called to add static ARP
> entries)
>
 Sounds very tightly coupled to OVS agent.

> Please bear in mind, the extension interface will be available
>> from different agent types
>> (OVS, SR-IOV, [eventually LB]), so this interface you're talking
>> about could also serve as
>> a translation driver for the agents (where the translation is
>> possible), I totally understand
>> that most extensions are specific agent bound, and we must be
>> able to identify
>> the agent we're serving back exactly.
>>
> Yes, I do have this in mind, but what we've identified for now
> seems to be OVS specific.
>
 Indeed it does. Maybe you can try to define the needed pieces in
 high level actions, not internal objects you need to access to. Like ‘-
 connect endpoint X to Y’, ‘determine segmentation id for a network’ 
 etc.

>>> I've been thinking about this, but would tend to reach the
>>> conclusion that the things we need to interact with are pretty hard to
>>> abstract out into something that would be generic across different 
>>> agents.
>>> Everything we need to do in our case relates to how the agents use 
>>> bridges
>>> and represent networks internally: linuxbridge has one bridge per 
>>> Network,
>>> while OVS has a limited number of bridges playing different roles for 
>>> all
>>> networks with internal segmentation.
>>>
>>> To look at the two things you  mention:
>>> - "connect endpoint X to Y" : what we need to do is redirect the
>>> traffic destinated to the gateway of a Neutron network, to the thing 
>>> that
>>> will do the MPLS forwarding for the right BGP VPN context (called VRF), 
>>> in
>>> our case br-mpls (that could be done with an OVS table too) ; that 
>>> action
>>> might be abstracted out to hide the details specific to OVS, but I'm not
>>> sure on how to  name the destination in a way that would be agnostic to
>>> these details, and this is not really relevant to do until we have a
>>> relevant context in which the linuxbridge would pass packets to 
>>> something
>>> doing MPLS forwarding (OVS is currently the only option we support for 
>>> MPLS
>>> forwarding, and it does not really make sense to mix linuxbridge for
>>> Neutron L2/L3 and OVS for MPLS)
>>> - "determine segmentation id for a network": this is something
>>> really OVS-agent-specific, the linuxbridge agent uses 

Re: [openstack-dev] [neutron][sfc] Neutron stadium distribution and/or packaging

[Kevin Benton]

No, I wouldn't consider that to be monkey-patching. That's something that
we have a pluggable driver interface for. As Ihar pointed out, you will
have to be careful maintaining it since the class you are subclassing may
move or alter the '_build_cmdline_callback' method, but that isn't a huge
deal.

What I wouldn't want to see is a sub-project modifying core components of
the OVS agent or ML2 plugin and claiming that it is still using the OVS
agent or ML2 plugin.

On Mon, Aug 31, 2015 at 4:36 AM, Neil Jerram 
wrote:

> Hi Kevin,
>
> I currently have an example of this kind of thing that I'm working on, and
> I'd appreciate hearing your view on what is the best solution.
>
> My requirement was to change some of the command line options with which
> the DHCP agent invokes Dnsmasq.  My first implementation of this was in
> core Neutron, triggered by an interface driver method or property, and you
> can see various versions of that at [1].  Then I realized that I could also
> do this using an out-of-core subclass of Dnsmasq, and you can see that
> approach at [2].
>
> [1] https://review.openstack.org/#/c/206077/
> [2] https://review.openstack.org/#/c/218486/
>
> I guess the question is: would you consider [2] to be a monkey-patch, in
> the sense that you had in mind when writing below?  If it is, I guess that
> means that I should continue pursuing the approach of [1].
>
> Many thanks,
> Neil
>
>
>
> On 31/08/15 06:53, Kevin Benton wrote:
>
> If your sub-project requires changes to the Neutron API or client, then
> those need to be made in the in the main neutron and client projects.
> monkey-patching or completely replacing components of the main neutron
> project is not the way to go.
>
> The purpose of big tent isn't to have a bunch of sub-projects change the
> neutron core APIs and reference in ways they deem necessary. That will lead
> to a terrible user experience where the core functionality changes
> depending on which sub-projects are loaded. Sub-projects should add new
> extensions or write drivers/plugins for various backends.
>
> On Fri, Aug 28, 2015 at 7:19 PM, Paul Carver 
> wrote:
>
>> It's possible that I've misunderstood "Big Tent/Stadium", but I thought
>> we were talking about enhancements to Neutron, not separate unrelated
>> projects.
>>
>> We have several efforts focused on adding capabilities to Neutron. This
>> isn't about "polluting" the Neutron namespace but rather about adding
>> capabilities that Neutron currently is missing.
>>
>> My concern is that we need to add to the Neutron API, the Neutron CLI,
>> and enhance the capabilities of the OvS agent. I'm under the impression
>> that the "Neutron Stadium" allows us to do this, but I'm fuzzy on the
>> implementation details.
>>
>> Is the "Neutron Stadium" expected to allow additions to the Neutron API,
>> the Neutron client, and the Neutron components such as ML2 and the OvS
>> agent?
>>
>>
>>
>> __
>> 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
>>
>
>
>
> --
> Kevin Benton
>
>
>
> __
> 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
>
>


-- 
Kevin Benton
__
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] [neutron][sfc] Neutron stadium distribution and/or packaging

[Jay Pipes]

On 08/31/2015 01:50 AM, Kevin Benton wrote:

The purpose of big tent isn't to have a bunch of sub-projects change the
neutron core APIs and reference in ways they deem necessary. That will
lead to a terrible user experience where the core functionality changes
depending on which sub-projects are loaded.


Exactly correct.

Best,
-jay

__
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] [neutron][sfc] Neutron stadium distribution and/or packaging

[Neil Jerram]

Thanks, Kevin and Ihar, for your advice on this.  I think I know what to do 
with my change now, and I hope I haven't too much hijacked the previous 
direction of this thread.

Regards,
  Neil


From: Kevin Benton
Sent: Monday, 31 August 2015 16:38
To: OpenStack Development Mailing List (not for usage questions)
Reply To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][sfc] Neutron stadium distribution and/or 
packaging


No, I wouldn't consider that to be monkey-patching. That's something that we 
have a pluggable driver interface for. As Ihar pointed out, you will have to be 
careful maintaining it since the class you are subclassing may move or alter 
the '_build_cmdline_callback' method, but that isn't a huge deal.

What I wouldn't want to see is a sub-project modifying core components of the 
OVS agent or ML2 plugin and claiming that it is still using the OVS agent or 
ML2 plugin.

On Mon, Aug 31, 2015 at 4:36 AM, Neil Jerram 
<neil.jer...@metaswitch.com<mailto:neil.jer...@metaswitch.com>> wrote:
Hi Kevin,

I currently have an example of this kind of thing that I'm working on, and I'd 
appreciate hearing your view on what is the best solution.

My requirement was to change some of the command line options with which the 
DHCP agent invokes Dnsmasq.  My first implementation of this was in core 
Neutron, triggered by an interface driver method or property, and you can see 
various versions of that at [1].  Then I realized that I could also do this 
using an out-of-core subclass of Dnsmasq, and you can see that approach at [2].

[1] https://review.openstack.org/#/c/206077/
[2] https://review.openstack.org/#/c/218486/

I guess the question is: would you consider [2] to be a monkey-patch, in the 
sense that you had in mind when writing below?  If it is, I guess that means 
that I should continue pursuing the approach of [1].

Many thanks,
Neil



On 31/08/15 06:53, Kevin Benton wrote:
If your sub-project requires changes to the Neutron API or client, then those 
need to be made in the in the main neutron and client projects. monkey-patching 
or completely replacing components of the main neutron project is not the way 
to go.

The purpose of big tent isn't to have a bunch of sub-projects change the 
neutron core APIs and reference in ways they deem necessary. That will lead to 
a terrible user experience where the core functionality changes depending on 
which sub-projects are loaded. Sub-projects should add new extensions or write 
drivers/plugins for various backends.

On Fri, Aug 28, 2015 at 7:19 PM, Paul Carver 
<pcar...@paulcarver.us<mailto:pcar...@paulcarver.us>> wrote:
It's possible that I've misunderstood "Big Tent/Stadium", but I thought we were 
talking about enhancements to Neutron, not separate unrelated projects.

We have several efforts focused on adding capabilities to Neutron. This isn't 
about "polluting" the Neutron namespace but rather about adding capabilities 
that Neutron currently is missing.

My concern is that we need to add to the Neutron API, the Neutron CLI, and 
enhance the capabilities of the OvS agent. I'm under the impression that the 
"Neutron Stadium" allows us to do this, but I'm fuzzy on the implementation 
details.

Is the "Neutron Stadium" expected to allow additions to the Neutron API, the 
Neutron client, and the Neutron components such as ML2 and the OvS agent?



__
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



--
Kevin Benton


__
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




--
Kevin Benton
__
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] [neutron][sfc] Neutron stadium distribution and/or packaging

[Neil Jerram]

Hi Kevin,

I currently have an example of this kind of thing that I'm working on, and I'd 
appreciate hearing your view on what is the best solution.

My requirement was to change some of the command line options with which the 
DHCP agent invokes Dnsmasq.  My first implementation of this was in core 
Neutron, triggered by an interface driver method or property, and you can see 
various versions of that at [1].  Then I realized that I could also do this 
using an out-of-core subclass of Dnsmasq, and you can see that approach at [2].

[1] https://review.openstack.org/#/c/206077/
[2] https://review.openstack.org/#/c/218486/

I guess the question is: would you consider [2] to be a monkey-patch, in the 
sense that you had in mind when writing below?  If it is, I guess that means 
that I should continue pursuing the approach of [1].

Many thanks,
Neil


On 31/08/15 06:53, Kevin Benton wrote:
If your sub-project requires changes to the Neutron API or client, then those 
need to be made in the in the main neutron and client projects. monkey-patching 
or completely replacing components of the main neutron project is not the way 
to go.

The purpose of big tent isn't to have a bunch of sub-projects change the 
neutron core APIs and reference in ways they deem necessary. That will lead to 
a terrible user experience where the core functionality changes depending on 
which sub-projects are loaded. Sub-projects should add new extensions or write 
drivers/plugins for various backends.

On Fri, Aug 28, 2015 at 7:19 PM, Paul Carver 
> wrote:
It's possible that I've misunderstood "Big Tent/Stadium", but I thought we were 
talking about enhancements to Neutron, not separate unrelated projects.

We have several efforts focused on adding capabilities to Neutron. This isn't 
about "polluting" the Neutron namespace but rather about adding capabilities 
that Neutron currently is missing.

My concern is that we need to add to the Neutron API, the Neutron CLI, and 
enhance the capabilities of the OvS agent. I'm under the impression that the 
"Neutron Stadium" allows us to do this, but I'm fuzzy on the implementation 
details.

Is the "Neutron Stadium" expected to allow additions to the Neutron API, the 
Neutron client, and the Neutron components such as ML2 and the OvS agent?



__
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



--
Kevin Benton

__
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] [neutron][sfc] Neutron stadium distribution and/or packaging

[Ihar Hrachyshka]

> On 31 Aug 2015, at 13:36, Neil Jerram  wrote:
> 
> Hi Kevin,
> 
> I currently have an example of this kind of thing that I'm working on, and 
> I'd appreciate hearing your view on what is the best solution.
> 
> My requirement was to change some of the command line options with which the 
> DHCP agent invokes Dnsmasq.  My first implementation of this was in core 
> Neutron, triggered by an interface driver method or property, and you can see 
> various versions of that at [1].  Then I realized that I could also do this 
> using an out-of-core subclass of Dnsmasq, and you can see that approach at 
> [2].
> 
> [1] https://review.openstack.org/#/c/206077/
> [2] https://review.openstack.org/#/c/218486/
> 
> I guess the question is: would you consider [2] to be a monkey-patch, in the 
> sense that you had in mind when writing below?  If it is, I guess that means 
> that I should continue pursuing the approach of [1].
> 

I believe Dnsmasq class does not intend to maintain a stable API, so the method 
that you override may change its name at any moment, breaking your subproject. 
The fact that the method name starts with underscore only suggests that it’s 
not the best approach to extend it. If you would like to base your driver on 
top of Dnsmasq, ideally, you would work with neutron community to detect pieces 
that are absolutely needed for your subproject, and work on defining a stable 
API that you can then reuse.

But if the only thing you need is to pass some custom configuration to dnsmasq, 
then you may already have all you need. Specifically, you could configure 
dnsmasq_config_file = in dhcp_agent.ini to point to a file that contains all 
your custom settings.

Ihar
__
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] [neutron][sfc] Neutron stadium distribution and/or packaging

[Kevin Benton]

If your sub-project requires changes to the Neutron API or client, then
those need to be made in the in the main neutron and client projects.
monkey-patching or completely replacing components of the main neutron
project is not the way to go.

The purpose of big tent isn't to have a bunch of sub-projects change the
neutron core APIs and reference in ways they deem necessary. That will lead
to a terrible user experience where the core functionality changes
depending on which sub-projects are loaded. Sub-projects should add new
extensions or write drivers/plugins for various backends.

On Fri, Aug 28, 2015 at 7:19 PM, Paul Carver  wrote:

> It's possible that I've misunderstood "Big Tent/Stadium", but I thought we
> were talking about enhancements to Neutron, not separate unrelated projects.
>
> We have several efforts focused on adding capabilities to Neutron. This
> isn't about "polluting" the Neutron namespace but rather about adding
> capabilities that Neutron currently is missing.
>
> My concern is that we need to add to the Neutron API, the Neutron CLI, and
> enhance the capabilities of the OvS agent. I'm under the impression that
> the "Neutron Stadium" allows us to do this, but I'm fuzzy on the
> implementation details.
>
> Is the "Neutron Stadium" expected to allow additions to the Neutron API,
> the Neutron client, and the Neutron components such as ML2 and the OvS
> agent?
>
>
>
> __
> 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
>



-- 
Kevin Benton
__
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] [neutron][sfc] Neutron stadium distribution and/or packaging

[Paul Carver]

Has anyone written anything up about expectations for how Big Tent or 
Neutron Stadium projects are expected to be 
installed/distributed/packaged?


In particular, I'm wondering how we're supposed to handle changes to 
Neutron components. For the networking-sfc project we need to make 
additions to the API and corresponding additions to neutronclient as 
well as modifying the OvS agent to configure new flow table entries in OvS.


The code is in a separate Git repo as is expected of a Stadium project 
but it doesn't make sense that we would package altered copies of files 
that are deployed by the regular Neutron packages.


Should we be creating 99%+ of the functionality in filenames that don't 
conflict and then making changes to files in the Neutron and 
neutronclient repos to stitch together the 1% that adds our new 
functionality to the existing components? Or do we stage the code in the 
Stadium project's repo then subsequently request to merge it into the 
neutron/neutronclient repo? Or is there some other preferred way to 
integrate the added features?




__
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] [neutron][sfc] Neutron stadium distribution and/or packaging

[Ihar Hrachyshka]

 On 28 Aug 2015, at 14:08, Paul Carver pcar...@paulcarver.us wrote:
 
 Has anyone written anything up about expectations for how Big Tent or 
 Neutron Stadium projects are expected to be installed/distributed/packaged?
 

Seems like your questions below are more about extendability than e.g. 
packaging.

 In particular, I'm wondering how we're supposed to handle changes to Neutron 
 components. For the networking-sfc project we need to make additions to the 
 API and corresponding additions to neutronclient as well as modifying the OvS 
 agent to configure new flow table entries in OvS.
 
 The code is in a separate Git repo as is expected of a Stadium project but it 
 doesn't make sense that we would package altered copies of files that are 
 deployed by the regular Neutron packages.
 

Of course you should not ship you custom version of neutron with your 
sub-project. Instead, you should work with neutron team to make sure you have 
all needed to extend it without duplicating efforts in your project.

 Should we be creating 99%+ of the functionality in filenames that don't 
 conflict and then making changes to files in the Neutron and neutronclient 
 repos to stitch together the 1% that adds our new functionality to the 
 existing components? Or do we stage the code in the Stadium project's repo 
 then subsequently request to merge it into the neutron/neutronclient repo? Or 
 is there some other preferred way to integrate the added features?
 

I presume that all sub-projects should use their own python namespace and not 
pollute neutron.* namespace. If that’s not the case for your sub-project, you 
should migrate to a new namespace asap.

If there is anything missing in neutron or neutronclient for you to integrate 
with it, then you should work in those repositories to get the extension hooks 
or features you miss, and after it’s in neutron, you will merely utilise them 
from your sub-project. Of course it means some kind of dependency on the 
progress in neutron repository to be able to estimate feature plans in your 
sub-project.

Ihar
__
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] [neutron][sfc] Neutron stadium distribution and/or packaging

[Kyle Mestery]

On Fri, Aug 28, 2015 at 8:07 AM, Ihar Hrachyshka ihrac...@redhat.com
wrote:

  On 28 Aug 2015, at 14:08, Paul Carver pcar...@paulcarver.us wrote:
 
  Has anyone written anything up about expectations for how Big Tent or
 Neutron Stadium projects are expected to be
 installed/distributed/packaged?
 

 Seems like your questions below are more about extendability than e.g.
 packaging.


I agree, though I will say that your project is listed as
release:independent [1]. This means that networking-sfc will NOT release
when neutron and neutron-[fwaas, lbaas, vpnaas] release Liberty, but can
release whenever it desires. This would be when the code is complete and
the team has decided a release should be made. The process for handling
this release is documented here [2] (though wait for that to refresh based
on the review which merged here [3]).

[1] http://governance.openstack.org/reference/projects/neutron.html
[2]
http://docs.openstack.org/developer/neutron/devref/sub_project_guidelines.html#releases
[3] https://review.openstack.org/#/c/217723/


  In particular, I'm wondering how we're supposed to handle changes to
 Neutron components. For the networking-sfc project we need to make
 additions to the API and corresponding additions to neutronclient as well
 as modifying the OvS agent to configure new flow table entries in OvS.
 
  The code is in a separate Git repo as is expected of a Stadium project
 but it doesn't make sense that we would package altered copies of files
 that are deployed by the regular Neutron packages.
 

 Of course you should not ship you custom version of neutron with your
 sub-project. Instead, you should work with neutron team to make sure you
 have all needed to extend it without duplicating efforts in your project.

  Should we be creating 99%+ of the functionality in filenames that don't
 conflict and then making changes to files in the Neutron and neutronclient
 repos to stitch together the 1% that adds our new functionality to the
 existing components? Or do we stage the code in the Stadium project's repo
 then subsequently request to merge it into the neutron/neutronclient repo?
 Or is there some other preferred way to integrate the added features?
 

 I presume that all sub-projects should use their own python namespace and
 not pollute neutron.* namespace. If that’s not the case for your
 sub-project, you should migrate to a new namespace asap.

 If there is anything missing in neutron or neutronclient for you to
 integrate with it, then you should work in those repositories to get the
 extension hooks or features you miss, and after it’s in neutron, you will
 merely utilise them from your sub-project. Of course it means some kind of
 dependency on the progress in neutron repository to be able to estimate
 feature plans in your sub-project.

 I'll second Ihar here. If you have dependencies in other projects, those
need to be worked in so they can be consumed by networking-sfc.


 Ihar
 __
 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] [neutron][sfc] Neutron stadium distribution and/or packaging

[Paul Carver]

It's possible that I've misunderstood Big Tent/Stadium, but I thought 
we were talking about enhancements to Neutron, not separate unrelated 
projects.


We have several efforts focused on adding capabilities to Neutron. This 
isn't about polluting the Neutron namespace but rather about adding 
capabilities that Neutron currently is missing.


My concern is that we need to add to the Neutron API, the Neutron CLI, 
and enhance the capabilities of the OvS agent. I'm under the impression 
that the Neutron Stadium allows us to do this, but I'm fuzzy on the 
implementation details.


Is the Neutron Stadium expected to allow additions to the Neutron API, 
the Neutron client, and the Neutron components such as ML2 and the OvS 
agent?



__
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] [Neutron][SFC] Wiki update - deleting old SFC API

[Sean M. Collins]

On Fri, Jul 24, 2015 at 04:27:57PM EDT, Cathy Zhang wrote:
 Do you know the process of getting the API spec published at 
 http://specs.openstack.org/openstack/neutron-specs/? We can port the merged 
 networking-sfc API spec and the latest patch over. Or we have to wait until 
 we have some working codes for key functionality? 

Ah - see I keep forgetting that the API spec for SFC is currently a doc
in the networking-sfc repo. I think that's OK for now, at least it's
published and versioned somewhere. We'd need to ask someone from infra
how we can get the doc/source tree published - most likely to
docs.openstack.org/developer

-- 
Sean M. Collins

__
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] [Neutron][SFC]The proposed Neutron API extension for packet forwarding has a lot of duplication to the Neutron SFC API

[Sean M. Collins]

On Sun, Jul 26, 2015 at 12:34:29AM EDT, Paul Carver wrote:
 I would, however, like input on the idea of CLI and API shortcuts. I don't
 think the API proposed in 186663 should be a completely separate
 implementation of creating flow table entries, but I can see the appeal of
 CLI options and perhaps API operations that allow the end user a quick and
 easy way of invoking the degenerate case without going through the
 multi-step, multi-api call execution of the full API.
 
 Is there a precedent for CLI options and/or single API calls that invoke a
 predefined multi-step path through a more comprehensive API? Perhaps the
 Get me a network work for example?
 
 It isn't very user friendly to force people to learn and navigate a
 complicated and comprehensive API if all they want to do is one simple and
 very common use case out of a myriad of possible and possibly esoteric
 applications of the full API.


I think when the API is too complex, where python-neutronclient is
expected to create a better UX, that means that the API itself may need
some further thinking and simplification. I think you are right however,
that Get me a network is the first case where we've recognized that
the workflow to create a tenant network and have internet connectivity
is quite involved, and that there needs to be some more automation of
the different steps.

My $0.02 is try and see if we can simplify the API to remove these
multi-step, multi-api calls. Fixing it in the CLI only makes it easy for
those that are using that specific CLI, and leaves everyone else out in
the cold.

-- 
Sean M. Collins

__
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] [Neutron][SFC]The proposed Neutron API extension for packet forwarding has a lot of duplication to the Neutron SFC API

[Paul Carver]

On 7/27/2015 4:49 PM, Sean M. Collins wrote:



I think when the API is too complex, where python-neutronclient is
expected to create a better UX, that means that the API itself may need
some further thinking and simplification. I think you are right however,
that Get me a network is the first case where we've recognized that
the workflow to create a tenant network and have internet connectivity
is quite involved, and that there needs to be some more automation of
the different steps.


I don't think it's a matter of expecting python-neutronclient to provide 
a better UX for the full SFC API. It's more a matter of two different 
classes of user. One class of user has some fairly complex use cases 
that can't be satisfied with a hard coded one true logic behind a 
simple do what I want API. Another class of user doesn't need all that 
complexity and would like a single API call that does exactly the one 
use case they need without the flexibility of handling all the similar 
but not identical use cases.


More input on ways to simplify the API [1] without reducing 
functionality is welcome, but that wasn't what my question was about.


My question was, if there's one particular use case that's especially 
common, but it's essentially just a single use case out of a collection 
of similar use cases, is it reasonable to create an API and/or CLI 
shortcut that allows people who don't want or need the full range of 
use case to just get their common one?


P.S. I'm not offering any opinion on whether [2] is or is not in fact 
common. I'm just saying that [2] appears to be a subset of [1] but [2] 
isn't sufficient to meet the needs of people who need [1]. Rather than 
implementing both [1] and [2] independently or forcing people who want 
[2] to use [1], I'm saying that it might be nice if we could provide 
something approximately equivalent to [2] using the implementation 
mechanics of [1].


[1] 
https://github.com/openstack/networking-sfc/blob/master/doc/source/api.rst

[2] https://review.openstack.org/#/c/186663/

__
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] [Neutron][SFC]The proposed Neutron API extension for packet forwarding has a lot of duplication to the Neutron SFC API

[Paul Carver]

On 7/24/2015 6:50 PM, Cathy Zhang wrote:

Hi Everyone,
In our last networking-sfc project IRC meeting, an issue was brought up that 
the API proposed in https://review.openstack.org/#/c/186663/ has a lot of 
duplication to the SFC API https://review.openstack.org/#/c/192933/ that is 
being currently implemented. In the IRC meeting, the project team reached 
consensus that we only need one API and the service chain API can cover the 
functionality needed by https://review.openstack.org/#/c/186663/. Please refer 
to the meeting log 
http://eavesdrop.openstack.org/meetings/service_chaining/2015/service_chaining.2015-07-23-17.02.log.html
 for more discussion info. Please let us know if you have different opinion.
Thanks,


I would, however, like input on the idea of CLI and API shortcuts. I 
don't think the API proposed in 186663 should be a completely separate 
implementation of creating flow table entries, but I can see the appeal 
of CLI options and perhaps API operations that allow the end user a 
quick and easy way of invoking the degenerate case without going through 
the multi-step, multi-api call execution of the full API.


Is there a precedent for CLI options and/or single API calls that invoke 
a predefined multi-step path through a more comprehensive API? Perhaps 
the Get me a network work for example?


It isn't very user friendly to force people to learn and navigate a 
complicated and comprehensive API if all they want to do is one simple 
and very common use case out of a myriad of possible and possibly 
esoteric applications of the full API.



__
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] [Neutron][SFC] Wiki update - deleting old SFC API

[Sean M. Collins]

On Thu, Jul 23, 2015 at 10:45:50PM EDT, Paul Carver wrote:
 On a general topic of wiki cleanup, what's the preferred mechanism for 
 documenting APIs?

I prefer that the APIs be submitted in a spec, so that they are
published on

http://specs.openstack.org/openstack/neutron-specs/

At least there, changes can be reviewed by others - the problem with the
wiki is it can be changed without any review. At least with
neutron-specs it's versioned and there is discussion that is
captured and preserved.

I'm +1 on cleaning/deleting stuff from the wiki about the old SFC API

-- 
Sean M. Collins

__
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] [Neutron][SFC] Wiki update - deleting old SFC API

[Cathy Zhang]

Hi Paul,

-Original Message-
From: Paul Carver [mailto:pcar...@paulcarver.us] 
Sent: Thursday, July 23, 2015 7:46 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron][SFC] Wiki update - deleting old SFC API

On a general topic of wiki cleanup, what's the preferred mechanism for 
documenting APIs?

Wiki page [1] largely duplicates the content of the spec in [2]
I dislike duplication of information because it's likely to get out of 
sync. I'd rather use hyperlinks whenever possible. However, linking to a 
Gerrit review isn't the most end user friendly way of presenting an API. 
One option is to link to the GitHub version of the rendered RST file [3] 
but I'd like to know if there are any other preferred practices.

Cathy Agree with you. Let's remove those duplicate sections and add the link 
to the rendered RST file [3] if there are no other preferred practices. Would 
you like to take care of this or I can clean this up? 

Thanks,
Cathy


[1] https://wiki.openstack.org/wiki/Neutron/APIForServiceChaining
[2] https://review.openstack.org/#/c/192933/
[3] 
https://github.com/openstack/networking-sfc/blob/master/doc/source/api.rst



__
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] [Neutron][SFC] Wiki update - deleting old SFC API

[Cathy Zhang]

Hi Sean,

-Original Message-
From: Sean M. Collins [mailto:s...@coreitpro.com] 
Sent: Friday, July 24, 2015 7:45 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][SFC] Wiki update - deleting old SFC API

On Thu, Jul 23, 2015 at 10:45:50PM EDT, Paul Carver wrote:
 On a general topic of wiki cleanup, what's the preferred mechanism for 
 documenting APIs?

I prefer that the APIs be submitted in a spec, so that they are
published on

http://specs.openstack.org/openstack/neutron-specs/

At least there, changes can be reviewed by others - the problem with the
wiki is it can be changed without any review. At least with
neutron-specs it's versioned and there is discussion that is
captured and preserved.

Cathy +1. 
Cathy Do you know the process of getting the API spec published at 
http://specs.openstack.org/openstack/neutron-specs/? We can port the merged 
networking-sfc API spec and the latest patch over. Or we have to wait until we 
have some working codes for key functionality? 


I'm +1 on cleaning/deleting stuff from the wiki about the old SFC API
Cathy +1 too. 

-- 
Sean M. Collins

__
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] [Neutron][SFC] Wiki update - deleting old SFC API

[Paul Carver]

On a general topic of wiki cleanup, what's the preferred mechanism for 
documenting APIs?


Wiki page [1] largely duplicates the content of the spec in [2]
I dislike duplication of information because it's likely to get out of 
sync. I'd rather use hyperlinks whenever possible. However, linking to a 
Gerrit review isn't the most end user friendly way of presenting an API. 
One option is to link to the GitHub version of the rendered RST file [3] 
but I'd like to know if there are any other preferred practices.


[1] https://wiki.openstack.org/wiki/Neutron/APIForServiceChaining
[2] https://review.openstack.org/#/c/192933/
[3] 
https://github.com/openstack/networking-sfc/blob/master/doc/source/api.rst




__
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] [Neutron][SFC] Launchpad cleanup

[Paul Carver]

Is it possible to delete dead blueprints or at least change the section 
at the top to just provide a URL to the blueprint that supersedes it?


Blueprint [1] links to a bunch of abandoned reviews and references its 
parent Blueprint [2] which also links to abandoned work. The current 
work on service chaining is taking place under [3] and [4].



[1] https://blueprints.launchpad.net/neutron/+spec/neutron-service-chaining
[2] 
https://blueprints.launchpad.net/neutron/+spec/neutron-services-insertion-chaining-steering
[3] 
https://blueprints.launchpad.net/neutron/+spec/openstack-service-chain-framework
[4] 
https://blueprints.launchpad.net/neutron/+spec/neutron-api-extension-for-service-chaining


__
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] [Neutron][SFC] Wiki update - deleting old SFC API

[Paul Carver]

As a courtesy to anyone who may have worked on it, I wanted to notify 
the list that I'm going to delete [1] from wiki page [2]. I may actually 
delete [2] completely. I'm going to update the content on [3] to 
reference the new SFC API spec that has just been merged. Currently [3] 
links to [2] which links to [1]. [1] is a Google doc from 2013. If 
anybody who worked on it (or even anyone who didn't) would like to 
review [4] to see if we missed anything critical, your input is most 
welcome.


This is part of a larger effort to improve search engine results because 
currently searches along the lines of Neutron service chaining are 
ranking abandoned specs and outdated documents higher than the current 
work that is being actively implemented.


[1] 
https://docs.google.com/document/d/1fmCWpCxAN4g5txmCJVmBDt02GYew2kvyRsh0Wl3YF2U/edit

[2] https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining/API
[3] https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining
[4] 
https://github.com/openstack/networking-sfc/blob/master/doc/source/api.rst


__
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