Hello David,
The following RFE’s were created in order to address the same use case:
https://bugs.launchpad.net/neutron/+bug/1592000
https://bugs.launchpad.net/neutron/+bug/1592028 (blueprint
https://review.openstack.org/#/c/391654)
IMO, These usability issues in the security-group API should b
On 31 October 2016 at 22:28, 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*: Appl
.
Thanks
Gary
From: Kevin Benton
Reply-To: OpenStack List
Date: Monday, October 31, 2016 at 11: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
nstack-dev@lists.openstack.org>>
Date: Monday, October 31, 2016 at 2:59 PM
To: OpenStack List
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron] Cloud Provider Security Groups
I believe the FWaaS v2 work is attempting to capture this concept of
pro
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 exis
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
