[openstack-dev] [neutron] [fwaas] Neutron FWaaS weekly team meeting cancelled on May 24.

2018-05-17 Thread Sridar Kandaswamy (skandasw)
Hi All:

With the Summit at Vancouver, we will cancel the FWaaS weekly meeting for May 
24 14:00 UTC. We will resume as usual from May 31.

Thanks

Sridar
__
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][neutron-fwaas] Request for inclusion of bug fixes in RC

2018-02-01 Thread Sridar Kandaswamy (skandasw)
Thanks An. The team has been working with An to review and validate these 
changes – we believe we are close to the final version and should be able to 
merge by tomorrow barring any unforeseen surprises. So pls consider adding 
these to the RC as they address some critical issues as outlined below.

Thanks

Sridar

On 2/1/18, 10:12 PM, "a...@vn.fujitsu.com"  wrote:

Hi, 

I would like to request inclusion of the following patches which address 
bugs found in our testing.

https://review.openstack.org/#/c/539461/
Addressing: https://bugs.launchpad.net/neutron/+bug/1746404

'auto_associate_default_firewall_group' got an error when new port is 
created
We started with a CfgOpt to Disable default FWG on ports. This has caused 
issues with Conntrack so this option is being removed. Also on a related note, 
we were mistakenly applying on other ports - so tightened up the validation to 
ensure that it is a VM port.

And
https://review.openstack.org/#/c/536234/
Addressing: https://bugs.launchpad.net/neutron/+bug/1746855

FWaaS V2 failures with Ml2 is Linuxbridge or security group driver is 
iptables_hybrid
We have failures with Linuxbridge as it is not a supported option and if SG 
uses iptables_hybrid driver - we have seen issues which possibly might be 
addressed [1], but with not enough validation we would like to prevent this 
scenario as well. With more testing and addressing any issues we can remove the 
restriction on SG with iptables_hybrid driver in the R release.

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

Cheers,
An

__
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][horizon] FWaaS/VPNaaS dashboard split out from horizon

2017-06-02 Thread Sridar Kandaswamy (skandasw)
Thanks Akihiro. From an FWaaS perspective, in agreement with Takashi on
points below. On repository name, I am not religious as long as we keep
things consistent.

Thanks

Sridar

On 6/1/17, 12:59 AM, "Takashi Yamamoto"  wrote:

>On Wed, May 31, 2017 at 10:12 PM, Akihiro Motoki 
>wrote:
>> Hi all,
>>
>> As discussed last month [1], we agree that each neutron-related
>> dashboard has its own repository.
>> I would like to move this forward on FWaaS and VPNaaS
>> as the horizon team plans to split them out as horizon plugins.
>>
>> A couple of questions hit me.
>>
>> (1) launchpad project
>> Do we create a new launchpad project for each dashboard?
>> At now, FWaaS and VPNaaS projects use 'neutron' for their bug tracking
>> from the historical reason, it sometimes There are two choices: the
>> one is to accept dashboard bugs in 'neutron' launchpad,
>> and the other is to have a separate launchpad project.
>>
>> My vote is to create a separate launchpad project.
>> It allows users to search and file bugs easily.
>
>+1
>
>>
>> (2) repository name
>>
>> Are neutron-fwaas-dashboard / neutron-vpnaas-dashboard good repository
>> names for you?
>> Most horizon related projects use -dashboard or -ui as their
>>repo names.
>> I personally prefers to -dashboard as it is consistent with the
>> OpenStack dashboard
>> (the official name of horizon). On the other hand, I know some folks
>> prefer to -ui
>> as the name is shorter enough.
>> Any preference?
>
>+1 for -dashboard.
>-ui sounds too generic to me.
>
>>
>> (3) governance
>> neutron-fwaas project is under the neutron project.
>> Does it sound okay to have neutron-fwaas-dashboard under the neutron
>>project?
>> This is what the neutron team does for neutron-lbaas-dashboard before
>> and this model is adopted in most horizon plugins (like trove, sahara
>> or others).
>
>+1
>
>>
>> (4) initial core team
>>
>> My thought is to have neutron-fwaas/vpnaas-core and horizon-core as
>> the initial core team.
>> The release team and the stable team follow what we have for
>> neutron-fwaas/vpnaas projects.
>> Sounds reasonable?
>
>+1
>
>>
>>
>> Finally, I already prepare the split out version of FWaaS and VPNaaS
>> dashboards in my personal github repos.
>> Once we agree in the questions above, I will create the repositories
>> under git.openstack.org.
>
>great, thank you.
>
>>
>> [1] 
>>http://lists.openstack.org/pipermail/openstack-dev/2017-April/thread.html
>>#115200
>>
>> 
>>_
>>_
>> 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


[openstack-dev] [neutron][fwaas] Weekly FWaaS meeting cancelled next week due to the Summit.

2017-05-02 Thread Sridar Kandaswamy (skandasw)
Hi All:

We will skip the weekly FWaaS meeting for next week with many of us traveling 
to the summit.

Thanks

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

2017-04-11 Thread Sridar Kandaswamy (skandasw)
Hi All:

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

Thanks

Sridar

From: Kevin Benton >
Reply-To: OpenStack List 
>
Date: Monday, April 10, 2017 at 4:20 PM
To: OpenStack List 
>
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" 
> 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-dev] [neutron][fwaas] No FWaaS Meeting this week.

2017-02-21 Thread Sridar Kandaswamy (skandasw)
Hi All:

Skipping this weeks FWaaS IRC meeting with some members at/traveling to PTG.

We will resume next week as usual.

Thanks

Sridar
__
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-fwaas] issue with firewall and sfc

2017-01-31 Thread Sridar Kandaswamy (skandasw)
Hi Vikash:

The support for VM ports is in progress and we should have that completed 
fairly early in Pike. We have had some prelim thoughts on integration with SFC 
but have not come to that point yet. If u have some interest, u are also 
welcome to join our weekly meeting [1] and we can discuss more.

Thanks

Sridar

[1] http://eavesdrop.openstack.org/#Firewall_as_a_Service_(FWaaS)_Team_Meeting

From: Vikash Kumar 
>
Reply-To: OpenStack List 
>
Date: Tuesday, January 31, 2017 at 2:49 AM
To: OpenStack List 
>
Subject: [openstack-dev] [neutron-fwaas] issue with firewall and sfc

Hi,

   I am looking to fwaas_v2, which now allows the firewall rules to get apply 
on VM ports also. The doc suggests it will work in tandem with neutron SFC. 
However, in SFC the port-security is disabled and if thats the case, where will 
the IPTABLE rules will be rendered ?

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


Re: [openstack-dev] [neutron] PTL nominations deadline and non-candidacy

2017-01-11 Thread Sridar Kandaswamy (skandasw)
 Sad to see u step down, thanks so much Armando for taking a "How can I help 
remove any roadblocks so we can move forward" approach to leadership. As part 
of a smaller project, ur support has certainly helped us make progress.

Thanks

Sridar
PS: I was wondering if there will be a farewell speech somewhere to match other 
recent events. :-)

From: joehuang >
Reply-To: OpenStack List 
>
Date: Tuesday, January 10, 2017 at 4:52 PM
To: OpenStack List 
>
Subject: Re: [openstack-dev] [neutron] PTL nominations deadline and 
non-candidacy

Sad to know that you will step down from Neutron PTL. Had several f2f talk with 
you, and got lots of valuable feedback from you. Thanks a lot!

Best Regards
Chaoyi Huang (joehuang)

From: Armando M. [arma...@gmail.com]
Sent: 09 January 2017 22:11
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [neutron] PTL nominations deadline and non-candidacy

Hi neutrinos,

The PTL nomination week is fast approaching [0], and as you might have guessed 
by the subject of this email, I am not planning to run for Pike. If I look back 
at [1], I would like to think that I was able to exercise the influence on the 
goals I set out with my first self-nomination [2].

That said, when it comes to a dynamic project like neutron one can't never 
claim to be *done done* and for this reason, I will continue to be part of the 
neutron core team, and help the future PTL drive the next stage of the 
project's journey.

I must admit, I don't write this email lightly, however I feel that it is now 
the right moment for me to step down, and give someone else the opportunity to 
grow in the amazing role of neutron PTL! I have certainly loved every minute of 
it!

Cheers,
Armando

[0] https://releases.openstack.org/ocata/schedule.html
[1] 
https://review.openstack.org/#/q/project:openstack/election+owner:armando-migliaccio
[2] https://review.openstack.org/#/c/223764/
__
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][fwaas] Weekly FWaaS meetings cancelled next 2 weeks.

2016-12-20 Thread Sridar Kandaswamy (skandasw)
Hi All:

We will skip the weekly FWaaS meetings on Dec 27 and Jan 3 with the Holiday 
Season. We will start back on Jan 10 as usual.

Happy Holidays to all.

Thanks

Sridar
__
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] Where will Neutron go in future?

2016-12-20 Thread Sridar Kandaswamy (skandasw)
Hi Zhi:

With the L3 implementation, FWaaS acts on traffic that is seen by the router 
(we have some issues with DVR) so it is really constrained to N - S. SG will of 
course see all traffic. Once we have the FWaaS L2 implementation - it opens up 
the possibilities to be applied on a VM port and hence can see all traffic.

Thanks

Sridar

From: zhi <changzhi1...@gmail.com<mailto:changzhi1...@gmail.com>>
Reply-To: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Monday, December 19, 2016 at 10:43 PM
To: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron] Where will Neutron go in future?

Hi, Srider.

Thanks for your reply. I still have a question about SG and FWaaS. VM's 
east-west traffic belongs to FWaaS or SG? What about VM's north-south traffic?

I think that VM's east-west traffic belongs to SG and the north-south traffic 
belongs to FWaaS, isn't it? :)


Thanks
Zhi Chang

2016-12-20 1:45 GMT+08:00 Sridar Kandaswamy (skandasw) 
<skand...@cisco.com<mailto:skand...@cisco.com>>:
Hi Zhi:

FWaaS has been seen more as an edge (on L3 ports) use case as opposed to SG 
which is on a VM port. Also, as u can see there are differences in the 
attributes on the Rule specification at the most basic level. At this point, we 
are working thru the implementation of FWaaS on L2 ports so that makes ur 
question more relevant. At least one school of thought that we have been 
working with is that the FWaaS API can be more open and continue to evolve to 
support for instance L4-L7 use cases amongst others, but the SG API will 
continue to stay a simpler model (some have also pointed the need for SG to be 
aligned with AWS).

This is still in evolution and we would welcome participation, if u can - pls 
do drop in to our weekly team meeting [1] and we can discuss further.

Thanks

Sridar
[1] http://eavesdrop.openstack.org/#Firewall_as_a_Service_(FWaaS)_Team_Meeting


From: zhi <changzhi1...@gmail.com<mailto:changzhi1...@gmail.com>>
Reply-To: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Sunday, December 18, 2016 at 7:36 PM
To: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron] Where will Neutron go in future?

Hi, Nate, thanks for your reply.

May I ask a little stupid question? What's the difference between fwaas and 
security group? In my opinion, fwaas and security group are both using linux 
iptables now. So, what's the differences between them?

Thanks
Zhi Chang

__
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] Where will Neutron go in future?

2016-12-19 Thread Sridar Kandaswamy (skandasw)
Hi Zhi:

FWaaS has been seen more as an edge (on L3 ports) use case as opposed to SG 
which is on a VM port. Also, as u can see there are differences in the 
attributes on the Rule specification at the most basic level. At this point, we 
are working thru the implementation of FWaaS on L2 ports so that makes ur 
question more relevant. At least one school of thought that we have been 
working with is that the FWaaS API can be more open and continue to evolve to 
support for instance L4-L7 use cases amongst others, but the SG API will 
continue to stay a simpler model (some have also pointed the need for SG to be 
aligned with AWS).

This is still in evolution and we would welcome participation, if u can - pls 
do drop in to our weekly team meeting [1] and we can discuss further.

Thanks

Sridar
[1] http://eavesdrop.openstack.org/#Firewall_as_a_Service_(FWaaS)_Team_Meeting


From: zhi >
Reply-To: OpenStack List 
>
Date: Sunday, December 18, 2016 at 7:36 PM
To: OpenStack List 
>
Subject: Re: [openstack-dev] [neutron] Where will Neutron go in future?

Hi, Nate, thanks for your reply.

May I ask a little stupid question? What's the difference between fwaas and 
security group? In my opinion, fwaas and security group are both using linux 
iptables now. So, what's the differences between them?

Thanks
Zhi Chang
__
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] proposing Ryan Tidwell and Nate Johnston as service LTs

2016-12-15 Thread Sridar Kandaswamy (skandasw)
+1. From the neutron-fwaas perspective, Nate has been instrumental in driving 
our integration with neutron on the agent extension framework, neutron-lib as 
well as on CI.

Thanks

Sridar

From: Kevin Benton >
Reply-To: OpenStack List 
>
Date: Thursday, December 15, 2016 at 5:00 PM
To: OpenStack List 
>
Subject: Re: [openstack-dev] [neutron] proposing Ryan Tidwell and Nate Johnston 
as service LTs

+1

On Dec 15, 2016 19:03, "Armando M." 
> wrote:
Hi neutrinos,

I would like to propose Ryan and Nate as the go-to fellows for service-related 
patches.

Both are core in their repos of focus, namely neutron-dynamic-routing and 
neutron-fwaas, and have a good understanding of the service framework, the 
agent framework and other bits and pieces. At this point, entrusting them with 
the responsibility is almost a formality.

Cheers,
Armando

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

__
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][fwaas] neutron-fwaas meeting time change

2016-11-16 Thread Sridar Kandaswamy (skandasw)
Thanks Nate. Based on further conversations and with the time change I
think what we intended was:

14:00 UTC

Tokyo: 11:00pm
Bengaluru: 07:30pm
US (EST):  09:00am
US (PST):  06:00am

I am fine with Mon or Tue.

Thanks

Sridar

On 11/14/16, 12:07 PM, "Nate Johnston"  wrote:

>On Sat, Oct 29, 2016 at 08:41:42AM +, Nate Johnston wrote:
>> Hello neutron-fwaas team,
>> 
>> With the expiration of Daylight Savings Time imminent in the USA, I
>>would like
>> to propose that we change the meeting time for the neutron-fwaas IRC
>>meeting
>> from the current value of 0400 UTC.  Here are a few proposals:
>> 
>> First proposed time: 1300 UTC
>> Tokyo (UTC+0900): 10:00 PM
>> Bengaluru (UTC+0530): 6:30 PM
>> US Eastern (UTC-0400): 9:00 AM
>> US Pacific (UTC-0700): 6:00 AM
>
>This was the option agreed to in the team meeting[1], and in the team
>meeting a
>preference for Thursday was expressed.  That is however a popular
>timeslot, and
>so there are no available channels at that time on Wednesday or Thursday.
> 
>
>What would be the best day for a meeting: Monday or Tuesday?
>
>Let's keep to the old meeting time until the meeting time change[2]
>merges.
>
>Thanks!
>
>--N.
>
>[1] 
>http://eavesdrop.openstack.org/meetings/fwaas/2016/fwaas.2016-11-02-04.00.
>log.html#l-105
>[2] https://review.openstack.org/#/c/393793/
>
>
>__
>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] Cloud Provider Security Groups

2016-10-31 Thread Sridar Kandaswamy (skandasw)
Hi All:

Thanks Kevin. David, yes I think we have a model that will work for u and would 
definitely want to discuss this more with u. I do hope that this can also help 
refine some of our thoughts. U can join us in our weekly IRC [1] (next one is 
tomorrow) and we can create an agenda item for more discussion. If the time is 
inconvenient, pls reach out to me and we set a time for a discussion with the 
team.

[1] http://eavesdrop.openstack.org/#Firewall_as_a_Service_(FWaaS)_Team_Meeting

Thanks

Sridar

From: Kevin Benton >
Reply-To: OpenStack List 
>
Date: Monday, October 31, 2016 at 2:59 PM
To: OpenStack List 
>
Subject: Re: [openstack-dev] [neutron] Cloud Provider Security Groups

I believe the FWaaS v2 work is attempting to capture this concept of 
provider-set rules to address this very use-case.

One of the items from the spec[1] sounds closely related:

'Adds an explicit action attribute to rules so that "deny" and "reject" actions 
can be specified in addition to the existing "allow" action. This is 
particularly important for tenant or service provider network admins that 
specify firewall policies meant to apply to all of a tenant's or service 
provider's instances, regardless of application.'

1. 
https://github.com/openstack/neutron-specs/blob/master/specs/newton/fwaas-api-2.0.rst

On Mon, Oct 31, 2016 at 5:28 PM, David G. Bingham 
> wrote:
Yo Neutron devs :-)

I was wondering if something like the following subject has come up:  
"Cloud-provider Security Groups”.

*Goal of this email*: Gauge the community’s need and see if this has come up in 
past.
*Requirement*: Apply a provider-managed global set of network flows to all 
instances.
*Use Case*: For our private cloud, have need to dynamically allow network 
traffic flows from other internal network sources across all instances.
*Basic Idea*: Provide an *admin-only* accessible security group ruleset that 
would persist and apply these "cloud-provider" security group rules to all 
instances of a cloud. This *may* be in the form of new "provider" API or an 
extension to existing API only accessible via "admin". When instances are 
created, this global SG ruleset would be applied to each VM/ironic instance. 
This feature likely should be capable of being enabled/disabled depending on 
the provider's need.

*Real example*: Company security team wants to audit consistent security 
software installations (i.e. HIPS) across our entire fleet of servers for 
compliance reporting. Each vm/ironic instance is required to have this software 
installed and up to date. Security audit team actually audits each and every 
server to ensure it is running, patched and up to date. These auditing tools 
source from a narrow set of internal IPs/ports and each instance must allow 
access to these auditing tools.

--- What we do today to hack a "cloud-provider" flow in a private cloud ---
1) We've locked down the default rules (only admins can modify which makes 
effectively kills a lot of canned neutron tools).
2) We've written an external script that iterates over all projects in our 
private cloud (~10k projects)
3) For each project:
3a) Fetch default SGs for that project and do a comparison of its default rules 
against *target* default rules
3b) Create any new missing rules, delete any removed rules
3c) Next project
This process is cumbersome, takes 20+ hours to run (over ~10k projects) and has 
to be throttled such that it doesn't over-hammer neutron while its still 
serving production traffic.

--- What we'd like to do in future ---
1) Call Security Group API that would modify a "cloud-provider" ruleset.
2) When updated, agents on HVs detect the "cloud-provider" change and then 
apply the rules across all instances.
Naturally there are going to be a lot of technical hurdles to make this happen 
while a cloud is currently in-flight.

Other uses for “Provider SGs":
* We want to enable new shared features (i.e. monitoring aaS) that all our 
internal projects can take advantage of. When the monitoring team adds/modifies 
IPs to scale, we'd apply these cloud-provider rules on behalf of all projects 
in the private cloud without users having concern themselves about the 
monitoring team's changes.
* We want to allow access to some internal sites to our VPN users on specific 
ports. These VPN ranges are dynamically changed by the VPN team. Our teams 
should not need to go into individual projects to add a new rule when VPN team 
changes ranges.
* This list could go on and on and naturally makes much more sense in a 
*private cloud* scenario, but there may be cases for public providers.

I’d be happy to create a spec.

Seen this before? Thoughts? Good, Bad or Ugly? :-)

Thanks,
David Bingham (wwriverrat on irc)
GoDaddy


[openstack-dev] [fwaas] Weekly meeting cancelled on Oct 25th due to the Summit.

2016-10-18 Thread Sridar Kandaswamy (skandasw)
Hi All:

We will cancel the FWaaS meeting next week due to the summit and resume the 
week after on Nov 1 as usual.

Thanks and Safe travels.

Sridar
__
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][FWaaS] __init__ arguments issue status

2016-05-06 Thread Sridar Kandaswamy (skandasw)
Hi All:

In digging thru this, yes with the neutron change, it changed the MRO as below 
and thus the issue.


(,
 , , , 
, ,

<—— the issue is at this point where we have a mismatch with args

,
 ,
 )


Nate, Margaret – thanks for digging thru this – lets get together during the 
day to discuss this more. Margaret, to answer ur question – it worked before 
due to a favorable ordering with the older hacked inheritance relationship. We 
can find a way to fix this in fwaas but more importantly need to get some 
missing pieces in to the Observer Hierarchy patch set as well.


Thanks


Sridar

From: Doug Wiegley 
>
Reply-To: OpenStack List 
>
Date: Thursday, May 5, 2016 at 9:40 PM
To: OpenStack List 
>
Subject: Re: [openstack-dev] [neutron][FWaaS] __init__ arguments issue status

This break is almost certainly because of the following neutron change, to 
unwind the incestuous inheritance that was in neutron (dependency arrow was 
circular):

https://review.openstack.org/#/c/223343/

I don’t expect there will be a lot of appetite to revert that, so it will need 
to be addressed in neutron-fwaas. Likely it should’ve had an ML warning first, 
sorry about that, this has been a longstanding issue.

doug



On May 5, 2016, at 7:00 PM, Frances, Margaret 
> 
wrote:

Hi Doug.

The old and new MROs are both pretty complicated, and it’s not entirely clear 
to me yet why the original one worked. (The MROs are included below for reading 
pleasure; they're embellished to show the incoming args to self’s init and 
outgoing args to super’s init in each case.)

I’m fairly sure the APIs for the mixins can be made the same, and I’ll try 
that.  But I still wonder if in fact the problem is a base class ordering issue.

The error that 223343 produced occurs in method call #6 in the "AFTER" MRO, 
where we get the following trace:

super(PeriodicTasks, self).__init__()
TypeError: __init__() takes exactly 2 arguments (1 given)


For grins, we changed PeriodicTasks’s call to super init as suggested by the 
trace:

super(PeriodicTasks, self).__init__(conf)


At this point FWaaSAgentRpcCallbackMixin (AFTER, #8) complained:

super(FWaaSAgentRpcCallbackMixin, self).__init__(host)
TypeError: object.__init__() takes no parameters


Changing *that* class as suggested elicited the following (to me baffling) 
result:

super(FWaaSAgentRpcCallbackMixin, self).__init__()
TypeError: __init__() takes exactly 2 arguments (1 given)


I find it baffling because FWaaSAgentRpcCallbackMixin is the end of the line, 
it’s a subclass of object, and object doesn’t allow arguments to init (so whose 
init is that? that’s the next thing I’m going to look at).  (It’s for these 
same reasons that I don’t understand why things worked before the 223343 
change.)

I’m still looking at things.  (And learning about MRO, which I’ve never really 
dealt with before.)  Will run pdb and see what surfaces.

Thanks for your help.  Thoughts, comments, suggestions all welcome.
Margaret


BEFORE 223343
 1. varmour_router_vArmourL3NATAgent (host, conf)-->(host, conf)
 2. agent_L3NATAgent  (host, conf)-->(conf)
 3. firewall_l3_agent_FWaaSL3AgentRpcCallback (conf)-->(host)
 4. api_FWaaSAgentRpcCallbackMixin (host)-->(host)
 5. ha_AgentMixin (host)-->(host)
 6. dvr_AgentMixin (host)-->(host)
 7. manager_Manager (host)-->(conf)
 8. periodic_task_PeriodicTasks(conf)-->()
 9. firewall_l3_agent_FWaaSL3AgentRpcCallback(conf)-->(host)
10. api_FWaaSAgentRpcCallbackMixin(host)-->(host)
11. object

AFTER 223343
 1. varmour_router_vArmourL3NATAgent (host, conf)-->(host, conf)
 2. agent_L3NATAgent  (host, conf)-->(host)
 3. ha_AgentMixin (host)-->(host)
 4. dvr_AgentMixin (host)-->(host)
 5. manager_Manager (host)-->(conf)
 6. periodic_task_PeriodicTasks(conf)-->()
 7. firewall_l3_agent_FWaaSL3AgentRpcCallback (conf)-->(host)
 8. api_FWaaSAgentRpcCallbackMixin(host)-->(host)
 9. object

--
Margaret Frances
Eng 4, Prodt Dev Engineering



On May 5, 2016, at 7:06 PM, Doug Hellmann 
> wrote:

Excerpts from Nate Johnston's message of 2016-05-05 17:40:13 -0400:
FWaaS team,

After a day of looking at the tests currently failing in the FWaaS repo, I
believe I have the issue narrowed down considerably. First, to restate what
is going on.  If you check out the neutron-fwaas repository and run `tox -e
py27` in it, you will get six errors all in the
neutron_fwaas.tests.unit.services.firewall.agents.varmour.test_varmour_router.TestVarmourRouter
section.
Running the py34 tests results in similar problems.  The failures follow
the following form:

Captured traceback:

~~~

   Traceback (most recent call last):

 File

Re: [openstack-dev] [neutron][fwaas][vpnaas][lbaas][octavia] summit summary - future of the advanced services

2016-05-05 Thread Sridar Kandaswamy (skandasw)
Hi All:

Doug, thanks for the update and agree. On fwaas - we have some new
contributors who are enthusiastic to make things happen in N. But if
contributor priorities change and we struggle - will reach out to expedite
the removal.

Thanks

Sridar

On 5/5/16, 9:56 AM, "Doug Wiegley"  wrote:

>Egads, that¹s a long subject prefix.  Anyways, we had a design session on
>the future of the advanced services:
>
>https://etherpad.openstack.org/p/newton-neutron-future-adv-services
>
>In a nutshell, vpn and fw are critically lacking active contributors at
>present. Again. A proposal was made to remove them from the neutron
>stadium, effectively making them the equivalent of stackforge projects
>(openstack experimental in the new terminology.)  This was rejected in
>favor of giving them until Ocata-1 to retain stadium status, similar to
>the criteria laid out in the later neutron stadium discussion:
>
>https://etherpad.openstack.org/p/newton-neutron-community-stadium-evolutio
>n
>
>Given how often we¹ve extended the lives of those two repos by yet
>another six months, this time we¹ll be looking for regular progress up to
>ocata-1, with final criteria being done (ish) by then. But, as agreed at
>the summit, if things go utterly dark post-summit, then you can expect to
>see governance patches to remove them from the stadium much faster than
>Ocata-1.
>
>After that session, but worth mentioning here, further discussions led to
>a proposal to make lbaas a standalone project, with a standalone
>endpoint, but adopting the current API:
>
>https://review.openstack.org/#/c/310805/
>https://review.openstack.org/#/c/310667/
>
>and here¹s a WIP governance patch for flavor:
>
>https://review.openstack.org/313056
>
>This achieved broad consensus among those present for the follow-up
>conversations (-1 nits on that patch aside), but please comment on any of
>those if you have comments/concerns.
>
>Next steps:
>
>- Monitor progress of vpn and fw.
>- Cleanup lbaas spinout specs, generate a timeline for minimum work
>required.
>
>Thanks,
>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 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][fwaas] how a disabled firewall should behave

2016-01-26 Thread Sridar Kandaswamy (skandasw)
Hi Takashi:

There were discussions around this sometime in the H cycle w.r.t the
reference implementation. IIRC, the consensus was that if a Firewall is
configured, the points of insertion should be conservative and drop all
traffic when admin_state_up is False. Only removing the Firewall will pass
all traffic. And the code does that [1] which u have probab already
checked.

[1] 
https://github.com/openstack/neutron-fwaas/blob/master/neutron_fwaas/servic
es/firewall/drivers/linux/iptables_fwaas.py#L120

Thanks

Sridar


On 1/26/16, 2:15 AM, "Takashi Yamamoto"  wrote:

>hi,
>
>what a firewall with admin_state_up=False should do?
>my intuition says such a firewall should pass all traffic. (same as no
>firewall)
>but the reference implementation seems to block everything. (same as a
>firewall without any rules)
>i wrote a tempest test case (test_firewall_disable_rule) mirroring the
>behaviour of the reference implementation
>because i couldn't find any documentation.
>but i'm now wondering if it was correct.
>is the reference implementation's behavior intended?  how other vendors
>do?
>
>__
>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][vpnaas] VPNaaS project status

2015-11-12 Thread Sridar Kandaswamy (skandasw)
Could not agree more. Thanks very much Paul.  And thanks also for always being 
a sounding board for common things across FWaaS and VPNaaS.

Thanks

Sridar

From: Madhusudhan Kandadai 
>
Reply-To: OpenStack List 
>
Date: Thursday, November 12, 2015 at 7:28 AM
To: OpenStack List 
>
Subject: Re: [openstack-dev] [neutron][vpnaas] VPNaaS project status

Thanks Paul for leading over the previous releases. Looking forward to have 
your guidance in neutron.

On Thu, Nov 12, 2015 at 8:48 PM, Kyle Mestery 
> wrote:
On Thu, Nov 12, 2015 at 9:56 AM, Paul Michali 
> wrote:
Neutron community,

During the past several releases, while leading the VPNaaS project, I've seen 
many great enhancements and features added to the VPNaaS project by the 
community, including support for StrongSwan, Libreswan, completion of the 
project split out, functional and rally tests, endpoint groups, multiple local 
subnets, vendor drivers, etc.

There is still work needed (certificate support the most important, followed by 
documentation and scale testing), but there is a solid (in my bias and 
subjective opinion :) foundation in place for people to play with this 
capability.

As I mentioned to Armando at the summit, it's time for me to move on to other 
areas of Neutron, and as such, I'm stepping down as VPNaaS chair and wrapping 
up work on the project over the next few weeks. I'll still try to review VPNaaS 
commits as much as possible, and be available to advise in this area.

Towards that end, I've updated the VPNaaS wiki page 
(https://wiki.openstack.org/wiki/Meetings/VPNaaS) to list what I think are 
outstanding work that can be done in this area, from important to wish items.  
Meetings have transitioned to on-demand, and future meetings can either be done 
as an on-demand topic in the Neutron IRC meeting, or as an on-demand special 
meeting.

I'll go through the VPNaaS bugs in Launchpad and comment on them, as to my 
opinion of importance, priority, relevance, etc.

Regards,


Thanks for all your hard work over the previous releases Paul! Looking forward 
to what you'll be doing next in Neutron.

Thanks,
Kyle

PCM (pc_m)

__
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][fwaas] openstack summit meetup

2015-10-20 Thread Sridar Kandaswamy (skandasw)
There are two slots (combined with LBaaS) Thu, Oct 29, 11am and the follow on 
at 11:50am [1].

Thanks

Sridar

[1] http://mitakadesignsummit.sched.org/overview/type/neutron


From: Oğuz Yarımtepe >
Reply-To: OpenStack List 
>
Date: Tuesday, October 20, 2015 at 9:42 PM
To: OpenStack List 
>
Subject: [openstack-dev] [neutron][fwaas] openstack summit meetup

Hi,

Will there be a meetup or design session for FWaaS? I just saw the roadmap 
presentation at the main conf.

--
Oğuz Yarımtepe
http://about.me/oguzy
__
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][fwaas] FWaaS IRC meetings to happen alternate Wed (no mtg today).

2015-06-10 Thread Sridar Kandaswamy (skandasw)
Hi All:

Just a reminder to FWaaS meeting attendees, as discussed in last weeks FWaaS 
IRC [1], with all the PTO’s going on and the need for time to build up on the 
SG alignment discussions – it was felt that it would be good to go to an 
alternate week format. So the next meeting will be on Jun 17 [2].

Whenever there is a need, we can revert back to the weekly format.

Thanks

Sridar

[1] 
http://eavesdrop.openstack.org/meetings/networking_fwaas/2015/networking_fwaas.2015-06-03-18.31.log.html
[2] https://wiki.openstack.org/wiki/Meetings/FWaaS

__
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] [fwaas] - Collecting use cases for API improvements

2015-05-27 Thread Sridar Kandaswamy (skandasw)
Hi All:

Thanks German for articulating this – we did have this discussion on last Fri 
as well on the need to have more user inputs. FWaaS has been in a bit of a 
Catch22 situation with the experimental state. Regarding feature velocity –  it 
has definitely been frustrating and we also lost contributors along the journey 
due to their frustration with moving things forward making things worse.

Kilo has been interesting in that there are more new contributors, repo split 
and more in terms of vendor support has gone in than ever before. We hope that 
this will improve traction for the customers they represent as well. Adding 
more user inputs and having a concerted conversation will definitely help. I 
echo Kyle and can certainly speak for all the current contributors in also 
helping out in any way possible to get this going. New Contributors are always 
welcome – Slawek  Vikram among the  most recent new contributors know this 
well.

Thanks

Sridar

From: Vikram Choudhary viks...@gmail.commailto:viks...@gmail.com
Date: Wednesday, May 27, 2015 at 5:54 PM
To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron] [fwaas] - Collecting use cases for API 
improvements

Hi German,

Thanks for the initiative. I am currently working for few of the FWaaS BP's 
proposed for Liberty and definitely would like to be a part of this effort.

BTW did you mean FWaaS IRC meeting to take up this discussion further?

Thanks
Vikram


On Thu, May 28, 2015 at 4:20 AM, Kyle Mestery 
mest...@mestery.commailto:mest...@mestery.com wrote:
On Wed, May 27, 2015 at 5:36 PM, Eichberger, German 
german.eichber...@hp.commailto:german.eichber...@hp.com wrote:
All,


During the FWaaS session in Vancouver [1] it became apparent that both the 
FWaaS API and the Security Groups API are lacking in functionality and the 
connection between the two is not well defined.


For instance if a cloud user opens up all ports in the security groups they 
still can’t connect and might figure out days later that there is a second API 
(FWaaS) which prevents him from connecting to his service. This will probably 
make for a frustrating experience.


Similarly, the operators I spoke to all said that the current FWaaS 
implementation isn’t going far enough and needs a lot of missing functionality 
added to fulfill their requirements on a Firewall implementation.


With that backdrop I am proposing to take a step back and assemble a group of 
operators and users to collect use cases for the firewall service – both FWaaS 
and Security Groups based. I believe it is important at this juncture to really 
focus on the users and less on technical limitations. I also think this reset 
is necessary to make a service which meets the needs of operators and users 
better.


Once we have collected the use cases we can evaluate our current API’s and 
functionality and start making the necessary improvements to turn FWaaS into a 
service which covers most of the use cases and requirements.


Please join me in this effort. We have set up an etherpad [2] to start 
collecting the use cases and will discuss them in an upcoming meeting.


Thanks for sending this out German. I took home the same impressions that you 
did. Similar to what we did with the LBaaS project (to great success last 
summer), I think we should look at FWaaS API V2 with the new contributors 
coming on as equals and helping to define the new operator focused API. My 
suggestion is we look at doing the work to lay the foundation during Liberty 
for a successful launch of this API during the Mxx cycle. I'm happy to step in 
here and guide the new group of contributors similar to what we did for LBaaS.

Thanks,
Kyle


Thanks,

German





[1] https://etherpad.openstack.org/p/YVR-neutron-sg-fwaas-future-direction

[2] https://etherpad.openstack.org/p/fwaas_use_cases


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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:unsubscribehttp://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][fwaas] neutron/agent/firewall.py

2014-12-19 Thread Sridar Kandaswamy (skandasw)
+1 Mathieu. Paul, this is not related to FWaaS.

Thanks

Sridar

On 12/19/14, 2:23 PM, Mathieu Gagné mga...@iweb.com wrote:

On 2014-12-19 5:16 PM, Paul Michali (pcm) wrote:

 This has a FirewallDriver and NoopFirewallDriver. Should this be moved
 into the neutron_fwaas repo?


AFAIK, FirewallDriver is used to implement SecurityGroup:

See:
- 
https://github.com/openstack/neutron/blob/master/neutron/agent/firewall.py
#L26-L29
- 
https://github.com/openstack/neutron/blob/master/neutron/agent/linux/iptab
les_firewall.py#L45
- 
https://github.com/openstack/neutron/blob/master/neutron/plugins/hyperv/ag
ent/security_groups_driver.py#L25

This class looks to not be used by neutron-fwaas

-- 
Mathieu

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron][LBaaS][Octavia] Octavia's API becoming spun out LBaaS

2014-10-26 Thread Sridar Kandaswamy (skandasw)
Hi Doug:

On 10/26/14, 6:01 PM, Doug Wiegley do...@a10networks.com wrote:

Hi Brandon,

 4. I brought this up now so that we can decide whether we want to
 discuss it at the advanced services spin out session.  I don't see the
 harm in opinions being discussed before the summit, during the summit,
 and more thoroughly after the summit.

I agree with this sentiment.  I¹d just like to pull-up to the decision
level, and if we can get some consensus on how we move forward, we can
bring a concrete plan to the summit instead of 40 minutes of Kumbaya.  We
love each other.  Check.  Things are going to change sometime.  Check.  We
might spin-out someday.  Check.  Now, let¹s jump to the interesting part.

 3. The main reason a spin out makes sense from Neutron is that the scope
 for Neutron is too large for the attention advances services needs from
 the Neutron Core.  If all of advanced services spins out, I see that

There is merit here, but consider the sorts of things that an advanced
services framework should be doing:

- plugging into neutron ports, with all manner of topologies
- service VM handling
- plugging into nova-network
- service chaining
- applying things like security groups to services

Š this is all stuff that Octavia is talking about implementing itself in a
basically defensive manner, instead of leveraging other work.  And there
are specific reasons for that.  But, maybe we can at least take steps to
not be incompatible about it.  Or maybe there is a hierarchy of Neutron -
Services - LB, where we¹re still spun out, but not doing it in a way that
we have to re-implement the world all the time.  It¹s at least worth a
conversation or three.

In total agreement and I have heard these sentiments in multiple
conversations across multiple players.
It would be really fruitful to have a constructive conversation on this
across the services, and there are
enough similar issues to make this worthwhile.

Thanks

Sridar


Thanks,
Doug




On 10/26/14, 6:35 PM, Brandon Logan brandon.lo...@rackspace.com wrote:

Good questions Doug.  My answers are as follows:

1. Yes
2. Some time after Kilo (same as I don't know when)
3. The main reason a spin out makes sense from Neutron is that the scope
for Neutron is too large for the attention advances services needs from
the Neutron Core.  If all of advanced services spins out, I see that
repeating itself within an advanced services project.  More and more
advanced services will get added in and the scope will become too
large.  There would definitely be benefits to it though, but I think we
would end up being right where we are today.
4. I brought this up now so that we can decide whether we want to
discuss it at the advanced services spin out session.  I don't see the
harm in opinions being discussed before the summit, during the summit,
and more thoroughly after the summit.

Yes the brunt of the time will not be spent on the API, but since it
seemed like an opportunity to kill two birds with one stone, I figured
it warranted a discussion.

Thanks,
Brandon

On Sun, 2014-10-26 at 23:15 +, Doug Wiegley wrote:
 Hi all,
 
 Before we get into the details of which API goes where, I¹d like to see
us
 answer the questions of:
 
 1. Are we spinning out?
 2. When?
 3. With or without the rest of advanced services?
 4. Do we want to wait until we (the royal ³we² of ³the Neutron team²)
have
 had the Paris summit discussions on vendor split-out and adv. services
 spinout before we answer those questions?  (Yes, that question is
leading.)
 
 To me, the ³where does the API live² is an implementation detail, and
not
 where the time will need to be spent.
 
 For the record, my answers are:
 
 1. Yes.
 2. I don¹t know.
 3. I don¹t know; this needs some serious discussion.
 4. Yes.
 
 Thanks,
 doug
 
 On 10/24/14, 3:47 PM, Brandon Logan brandon.lo...@rackspace.com
wrote:
 
 With the recent talk about advanced services spinning out of Neutron,
 and the fact most of the LBaaS community has wanted LBaaS to spin out
of
 Neutron, I wanted to bring up a possibility and gauge interest and
 opinion on this possibility.
 
 Octavia is going to (and has) an API.  The current thinking is that an
 Octavia driver will be created in Neutron LBaaS that will make a
 requests to the Octavia API.  When LBaaS spins out of Neutron, it will
 need a standalone API.  Octavia's API seems to be a good solution to
 this.  It will support vendor drivers much like the current Neutron
 LBaaS does.  It has a similar API as Neutron LBaaS v2, but its not an
 exact duplicate.  Octavia will be growing more mature in stackforge at
a
 higher velocity than an Openstack project, so I expect by the time
Kilo
 comes around it's API will be very mature.
 
 Octavia's API doesn't have to be called Octavia either.  It can be
 separated out and it can be called Openstack LBaaS, and the rest of
 Octavia (the actual brains of it) will just be another driver to
 Openstack LBaaS, which would retain the Octavia name.
 
 This is my 

Re: [openstack-dev] [Neutron] Simple proposal for stabilizing new features in-tree

2014-08-14 Thread Sridar Kandaswamy (skandasw)
Hi Aaron:


There is a certain fear of another cascading chain of emails so with hesitation 
i send this email out. :-)


1) I could not agree with u more on the issue with the logs and the pain with 
debugging issues here. Yes for sure bugs do keep popping up but often times, 
(speaking for fwaas) - given the L3 agent interactions - there are a multitude 
of reasons for a failure. An L3Agent crash or a router issue - also manifests 
itself as an fwaas issue - i think ur first paste is along those lines (perhaps 
i could be wrong without much context here).


The L3Agent - service coexistence is far from ideal - but this experience has 
lead to two proposals - a vendor proposal [1] that actually tries to address 
such agent limitations and collaboration on another community proposal[2] to 
enable the L3 Agent to be more suited to hosting services. Hopefully [2] will 
get picked up in K and should help provide the necessary infrastructure to 
clean up the reference implementation.


2) Regarding ur point on the  FWaaS API - the intent of the feature by design 
was to keep the service abstraction separate from how it is inserted in the 
network - to keep this vendor/technology neutral. The first priority, post 
Havana was to address  service insertion to get away from the all routers model 
[3] but did not get the blessings needed. Now with a redrafted proposal for 
Juno[4] again an effort is being made to address this now for the second time 
in the 2 releases post H.


In general, I would make a request that before we decide to go ahead and start 
moving things out into an incubator area - more discussion is needed.  We don’t 
want  to land up in a situation in K-3 where we find out that this model does 
not quite work for whatever reason. Also i wonder about the hoops to get out 
from incubation. As vendors who try to align with the community and upstream 
our work - we don’t want to land up waiting more cycles - there is quite a bit 
of frustration that is felt here too.


Lets also think about the impacts on feature velocity, somehow that keeps 
popping into my head every time i buy a book from a certain online retailer. :-)


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

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

[3] https://review.openstack.org/#/c/62599/

[4] https://review.openstack.org/#/c/93128/


Thanks


Sridar


From: Aaron Rosen aaronoro...@gmail.commailto:aaronoro...@gmail.com
Reply-To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Wednesday, August 13, 2014 at 3:56 PM
To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] Simple proposal for stabilizing new 
features in-tree

Hi,

I've been thinking a good bit on this on the right way to move forward with 
this and in general the right way new services should be added. Yesterday I was 
working on a bug that was causing some problems in the openstack infra. We 
tracked down the issue then I uploaded a patch for it. A little while later 
after jenkins voted back a -1 so I started looking through the logs to see what 
the source of the failure was (which was actually unrelated to my patch). The 
random failure in the fwaas/vpn/l3-agent code which all outputs to the same log 
file that contains many traces for every run even successful ones. In one skim 
of this log file I was able to spot 4 [1]bugs which shows  these new 
experimental services that we've added to neutron have underlying problems 
(even though they've been in the tree for 2 releases+ now). This puts a huge 
strain on the whole openstack development community as they are always recheck 
no bug'ing due to neutron failures.

If you look at the fwaas work that was done. This merged over two releases ago 
and still does not have a complete API as there is no concept of where 
enforcement should be done. Today, enforcement is done across all of a tenant's 
routers making it more or less useless imho and we're just carrying it along in 
the tree (and it's causing us problems)!

I think Mark's idea of neutron-incubator[2] is a great step forward to 
improving neutron.

We can easily move these things out of the neutron source tree and we can plug 
these things in here:
https://github.com/openstack/neutron/blob/master/etc/neutron.conf#L52
https://github.com/openstack/neutron/blob/master/etc/neutron.conf#L72
(GASP: We have seen shipped our own API's here to customers before we were able 
to upstream them).

This allows us to decouple these experimental things from the neutron core and 
allows us to release these components on their own making things more 
modular/maintainable and stable (I think these things might even be better long 
term living out of the tree).  Most importantly though it doesn't put a burden 
on everyone else.


Best,

Aaron


[1]
http://paste.openstack.org/show/94664/
http://paste.openstack.org/show/94670/

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Sridar Kandaswamy (skandasw)
Hi All:

+1 Ivar. Yes the timing of the alternate proposal does make the notion of spec 
reviews seem like a process tick mark with no seeming benefit. It is indeed 
unfair to the folks who have put in a lot of effort with an approved spec to 
have a workflow change pulled on them so late in the cycle.

Thanks

Sridar

From: Ivar Lazzaro ivarlazz...@gmail.commailto:ivarlazz...@gmail.com
Reply-To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Wednesday, August 6, 2014 at 12:01 PM
To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way forward


Hi Joe,

Are you suggesting to stop/remove everything that is not related to Nova Parity 
for the Juno release? Because then I fail to see why this and Mark's proposal 
are targeted  only to GBP.

In my humble opinion, these kind of concerns should be addressed at BP approval 
time. Otherwise the whole purpose of the BP process feels void.

If we really feel like proposing a new way of addressing new features in 
Neutron (which basically is a workflow change), we should discuss all of it for 
the next release without blocking patches which went through the whole approval 
process and are ready to be merged after community effort (BP process, Weakly 
meetings, POC, reviews). Just like has been done in other similar cases (eg. 
3rd Party CI). This of course is IMHO.

Ivar.

On Aug 6, 2014 4:55 PM, Joe Gordon 
joe.gord...@gmail.commailto:joe.gord...@gmail.com wrote:



On Wed, Aug 6, 2014 at 4:12 PM, Kevin Benton 
blak...@gmail.commailto:blak...@gmail.com wrote:
Are there any parity features you are aware of that aren't receiving adequate 
developer/reviewer time? I'm not aware of any parity features that are in a 
place where throwing more engineers at them is going to speed anything up. 
Maybe Mark McClain (Nova parity leader) can provide some better insight here, 
but that is the impression I've gotten as an active Neutron contributor 
observing the ongoing parity work.

I cannot speak for which parts of nova-parity are short staffed, if any, but 
from an outsiders perspective I don't think neutron will hit full parity in 
Juno. And I would be very surprised to hear that more developers working on 
parity won't help. For example we are already in Juno-3 and the following work 
is yet to be completed (as per the neutron gap wiki):

* Make check-tempest-dsvm-neutron-full stable enough to vote
* Grenade testing
* DVR (Neutron replacement for Nova multi-host)
* Document Open Source Options
* Real world (not in gate) performance, stability and scalability testing 
(performance parity with nova-networking).



Given that, pointing to the Nova parity work seems a bit like a red herring. 
This new API is being developed orthogonally to the existing API endpoints and 
I don't think it was ever the expectation that Nova would switch to this during 
the Juno timeframe anyway. The new API will not be used during normal operation 
and should not impact the existing API at all.



On Tue, Aug 5, 2014 at 5:51 PM, Sean Dague 
s...@dague.netmailto:s...@dague.net wrote:
On 08/05/2014 07:28 PM, Joe Gordon wrote:



 On Wed, Aug 6, 2014 at 12:20 AM, Robert Kukura 
 kuk...@noironetworks.commailto:kuk...@noironetworks.com
 mailto:kuk...@noironetworks.commailto:kuk...@noironetworks.com wrote:

 On 8/4/14, 4:27 PM, Mark McClain wrote:
 All-

 tl;dr

 * Group Based Policy API is the kind of experimentation we be
 should attempting.
 * Experiments should be able to fail fast.
 * The master branch does not fail fast.
 * StackForge is the proper home to conduct this experiment.
 The disconnect here is that the Neutron group-based policy sub-team
 that has been implementing this feature for Juno does not see this
 work as an experiment to gather data, but rather as an important
 innovative feature to put in the hands of early adopters in Juno and
 into widespread deployment with a stable API as early as Kilo.


 The group-based policy BP approved for Juno addresses the critical
 need for a more usable, declarative, intent-based interface for
 cloud application developers and deployers, that can co-exist with
 Neutron's current networking-hardware-oriented API and work nicely
 with all existing core plugins. Additionally, we believe that this
 declarative approach is what is needed to properly integrate
 advanced services into Neutron, and will go a long way towards
 resolving the difficulties so far trying to integrate LBaaS, FWaaS,
 and VPNaaS APIs into the current Neutron model.

 Like any new service API in Neutron, the initial group policy API
 release will be subject to incompatible changes before being
 declared stable, and hence would be labeled experimental in
 Juno. This does not mean that it is an experiment where to fail
 

Re: [openstack-dev] [neutron] Spec exceptions are closed, FPF is August 21

2014-08-01 Thread Sridar Kandaswamy (skandasw)
Hi All:


There is no doubt the cores are quite stretched and it does take a finite 
amount of time to absorb the context and the content of the multitude of 
patches on any given core reviewer¹s queue. Life happens for everyone and 
things slip thru the cracks, but this suggestion on a timeline for reassessing 
the sticky -2 after a response from the patch owner seems very reasonable to 
adopt.


It certainly helps the submitter to make forward progress rather than exit the 
project in frustration (I know of at least one instance with a contributor 
expressing this as a reason to move on) and establishes a process so that cores 
can rely on a automatic throttle mechanism if they suddenly find themselves 
dealing with other things that are a higher priority for them.


Thanks


Sridar

From: Mandeep Dhami dh...@noironetworks.commailto:dh...@noironetworks.com
Reply-To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Friday, August 1, 2014 at 4:53 AM
To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron] Spec exceptions are closed, FPF is 
August 21

Hi Armando:

  If a core-reviewer puts a -2, there must be a good reason for it

I agree. The problem is that after the initial issue identified in the initial 
-2 review has been fixed, and the patch updated, it (sometimes) happens that we 
can not get the original reviewer to re-review that update for weeks - creating 
the type of issues identified in this thread.

I would agree that if this was a one-off scenarios, we should handling this as 
a specific case as you suggest. Unfortunately, this is not a one-off instance, 
and hence my request for clearer guidelines from PTL for such cases.

Regards,
Mandeep



On Thu, Jul 31, 2014 at 3:54 PM, Armando M. 
arma...@gmail.commailto:arma...@gmail.com wrote:
It is not my intention debating, pointing fingers and finding culprits, these 
issues can be addressed in some other context.

I am gonna say three things:

1) If a core-reviewer puts a -2, there must be a good reason for it. If other 
reviewers blindly move on as some people seem to imply here, then those 
reviewers should probably not review the code at all! My policy is to review 
all the code I am interested in/I can, regardless of the score. My -1 may be 
someone's +1 (or vice versa), so 'trusting' someone else's vote is the wrong 
way to go about this.

2) If we all feel that this feature is important (which I am not sure it was 
being marked as 'low' in oslo, not sure how it was tracked in Neutron), there 
is the weekly IRC Neutron meeting to raise awareness, since all cores 
participate; to the best of my knowledge we never spoke (or barely) of the 
rootwrap work.

3) If people do want this work in Juno (Carl being one of them), we can figure 
out how to make one final push, and assess potential regression. We 'rushed' 
other features late in cycle in the past (like nova/neutron event 
notifications) and if we keep this disabled by default in Juno, I don't think 
it's really that risky. I can work with Carl to give the patches some more love.

Armando



On 31 July 2014 15:40, Rudra Rugge 
ru...@contrailsystems.commailto:ru...@contrailsystems.com wrote:
Hi Kyle,

I also agree with Mandeep's suggestion of putting a time frame on the lingering 
-2 if the addressed concerns have been taken care of. In my experience also a 
sticky -2 detracts other reviewers from reviewing an updated patch.

Either a time-frame or a possible override by PTL (move to -1) would help make 
progress on the review.

Regards,
Rudra


On Thu, Jul 31, 2014 at 2:29 PM, Mandeep Dhami 
dh...@noironetworks.commailto:dh...@noironetworks.com wrote:
Hi Kyle:

As -2 is sticky, and as there exists a possibility that the original core might 
not get time to get back to re-reviewing his, do you think that there should be 
clearer guidelines on it's usage (to avoid what you identified as dropping of 
the balls)?

Salvatore had a good guidance in a related thread [0], do you agree with 
something like that?

I try to avoid -2s as much as possible. I put a -2 only when I reckon your
patch should never be merged because it'll make the software unstable or
tries to solve a problem that does not exist. -2s stick across patches and
tend to put off other reviewers.

[0] http://lists.openstack.org/pipermail/openstack-dev/2014-July/041339.html


Or do you think that 3-5 days after an update that addresses the issues 
identified in the original -2, we should automatically remove that -2? If this 
does not happen often, this process does not have to be automated, just an 
exception that the PTL can exercise to address issues where the original 
reason for -2 has been addressed and nothing new has been identified?



On Thu, Jul 31, 2014 at 11:25 AM, Kyle Mestery 
mest...@mestery.commailto:mest...@mestery.com wrote:
On Thu, Jul 31, 2014 at 7:11 AM, Yuriy Taraday 

Re: [openstack-dev] [Neutron] FWaaS: Support for explicit commit

2013-08-13 Thread Sridar Kandaswamy (skandasw)
Hi All:

In discussing with some more folks from a deployment perspective - managing 
rules for  PCI compliance and Audit requirements is quite important. And as is 
pointed below by Sumit, this can help enable a gate for any audit checks before 
actually applying it on the backend. Another use case discussed was  that 
firewall rules are often bloated because often admins hesitate to remove old 
and unused rules because no one wants to take a chance on the effects. This 
could also serve as a validation point before an actual update is effected on a 
commit.

Thanks

Sridar 

-Original Message-
From: Sumit Naiksatam [mailto:sumitnaiksa...@gmail.com] 
Sent: Monday, August 12, 2013 12:24 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Neutron] FWaaS: Support for explicit commit

Hi Aaron,

I seemed to have missed this email from you earlier. As compared to existing 
Neutron resources, the FWaaS Firewall resource and workflow is slightly 
different, since it's a two step process. The rules/policy creation is 
decoupled (for audit reasons) from its application on the backend firewall. 
Hence the need for the commit-like operation which expresses the intent that 
the state of the rules/policy be applied to the backend firewall. We can 
provide capabilities for bulk creation/update of rules/policies as well but 
that I believe is independent of this.

I posted a patch yesterday night for this 
(https://review.openstack.org/#/c/41353/).

Thanks,
~Sumit.

On Wed, Aug 7, 2013 at 5:19 PM, Aaron Rosen aro...@nicira.com wrote:
 Hi Sumit,

 Neutron has a concept of a bulk creation where multiple things can be 
 created in one api request rather that N (and then be implemented 
 atomically on the backend). In my opinion, I think it would be better 
 to implement a bulk update/delete operation rather than a commit. I 
 think that having something like this that is generic could be useful 
 to other api's in neutron.

 I do agree that one has to keep track of the order they are 
 changing/adding/delete rules so that they don't allow two things to 
 communicate that shouldn't be allowed to. If someone wanted to perform 
 this type of bulk atomic change now could they create a new profile 
 with the rules they desire and then switch out which profile is 
 attached to the firewall?

 Best,

 Aaron


 On Wed, Aug 7, 2013 at 3:40 PM, Sumit Naiksatam 
 sumitnaiksa...@gmail.com
 wrote:

 We had some discussion on this during the Neutron IRC meeting, and 
 per that discussion I have created a blueprint for this:

 https://blueprints.launchpad.net/neutron/+spec/neutron-fwaas-explicit
 -commit

 Further comments can be posted on the blueprint whiteboard and/or the 
 design spec doc.

 Thanks,
 ~Sumit.

 On Fri, Aug 2, 2013 at 6:43 PM, Sumit Naiksatam 
 sumitnaiksa...@gmail.com wrote:
  Hi All,
 
  In Neutron Firewall as a Service (FWaaS), we currently support an 
  implicit commit mode, wherein a change made to a firewall_rule is 
  propagated immediately to all the firewalls that use this rule (via 
  the firewall_policy association), and the rule gets applied in the 
  backend firewalls. This might be acceptable, however this is 
  different from the explicit commit semantics which most firewalls support.
  Having an explicit commit operation ensures that multiple rules can 
  be applied atomically, as opposed to in the implicit case where 
  each rule is applied atomically and thus opens up the possibility 
  of security holes between two successive rule applications.
 
  So the proposal here is quite simple -
 
  * When any changes are made to the firewall_rules 
  (added/deleted/updated), no changes will happen on the firewall 
  (only the corresponding firewall_rule resources are modified).
 
  * We will support an explicit commit operation on the firewall 
  resource. Any changes made to the rules since the last commit will 
  now be applied to the firewall when this commit operation is invoked.
 
  * A show operation on the firewall will show a list of the 
  currently committed rules, and also the pending changes.
 
  Kindly respond if you have any comments on this.
 
  Thanks,
  ~Sumit.

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev