Bug 1258455
| Summary: | [RFE][neutron]: Enable setting default rules for default security group | |||
|---|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Pablo Iranzo Gómez <pablo.iranzo> | |
| Component: | openstack-neutron | Assignee: | Slawek Kaplonski <skaplons> | |
| Status: | CLOSED MIGRATED | QA Contact: | Toni Freger <tfreger> | |
| Severity: | low | Docs Contact: | ||
| Priority: | low | |||
| Version: | 13.0 (Queens) | CC: | amedeo.salvati, aperotti, aruffin, astupnik, bshephar, cgussobo, chrisw, coldford, dhill, enothen, gurpsing, ihrachys, jlibosva, jzaher, markmc, mtomaska, nyechiel, pablo.iranzo, rlondhe, scohen, skaplons, sputhenp, srevivo, tmicheli, visinha | |
| Target Milestone: | --- | Keywords: | FutureFeature, Reopened, Triaged | |
| Target Release: | --- | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| URL: | https://blueprints.launchpad.net/neutron/+spec/default-rules-for-default-security-group | |||
| Whiteboard: | upstream_milestone_none upstream_definition_obsolete upstream_status_not-started | |||
| Fixed In Version: | Doc Type: | Enhancement | ||
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 2070140 (view as bug list) | Environment: | ||
| Last Closed: | 2023-10-20 20:00:11 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 2070140 | |||
|
Description
Pablo Iranzo Gómez
2015-08-31 12:25:52 UTC
Can you please clarify the use-case for this request? Note that ML2 port-security extension was added in RHEL OpenStack Platform 7. This allows to disable the security-group feature (including the anti-spoofing rules) on a per port basis, so that customers should be able to deploy VNF applications inside VMs without interruption from Neutron. I am not sure if the helps here or not. Hi Nir, As discussed with Sadique, this is for allowing the modification the rules that are in place when a new security group is created. Customer is interested in OSP reseller functionality and want to be able to define the default rules to be created on each new SG defined. Thanks, Pablo *** Bug 886303 has been marked as a duplicate of this bug. *** To give context here, the feature was extensively discussed in upstream community for a long time, and the decision there is that it's impossible to implement the feature in a backwards compatible way for security groups that are established API for which existing users have behavioral assumptions (incl. the fact that default behavior allows outgoing connections). The suggestion from the upstream drivers (design) team is to explore alternative API for that matter, f.e. building it on top of fwaas-v2 API that is still experimental. Realistically, to get the feature implemented and supported in OSP, significant amount of engineering work is expected, including first helping fwaas community to build fwaas-v2 as a viable alternative for fwaas-v1 (v2 is still experimental and incomplete, and there is no clear ETA as to when it will mature). Closing this RFE based on comment #13 above. Hi guys, We do have some customers requesting this feature over and over again. Did things evolve in the right direction since 2015-2018 that would allow us to have some sort of default security groups for new tenants ? That would really help operators automate further some manual work that we are trying to automate with all those cloud APIs but we have to ways of saying "allow icmp, tcp port 22 and tcp port 3389 for all new guests using this new tenant" . Thank you very much, David Hill Hello, Per David's previous comment, this customer is asking for this enhancement, please let us know if/when possible - https://access.redhat.com/support/cases/#/case/02694779 Thanks, Allan Greentree Red Hat OpenStack Support (In reply to Ihar Hrachyshka from comment #13) > To give context here, the feature was extensively discussed in upstream > community for a long time, and the decision there is that it's impossible to > implement the feature in a backwards compatible way for security groups that > are established API for which existing users have behavioral assumptions > (incl. the fact that default behavior allows outgoing connections). The > suggestion from the upstream drivers (design) team is to explore alternative > API for that matter, f.e. building it on top of fwaas-v2 API that is still > experimental. > > Realistically, to get the feature implemented and supported in OSP, > significant amount of engineering work is expected, including first helping > fwaas community to build fwaas-v2 as a viable alternative for fwaas-v1 (v2 > is still experimental and incomplete, and there is no clear ETA as to when > it will mature). Is it still the case that it is impossible to implement this feature in a backwards compatible way, or did things evolve since 2017 in a direction that would facilitate development of the requested feature? If the former, shouldn't this BZ be closed as WONTFIX so that we don't keep associating cases here? If the latter, can someone on the DFG reevaluate the comment above and give an estimation of what it would take to complete this feature and what is the most optimistic target release? Thanks in advance. We have a customer that also needs this functionality. Repeating Eric Nothen's request, can someone on the DFG reevaluate the comment above and give an estimation of what it would take to complete this feature and what is the most optimistic target release? Hi, It is the same the customer is asking for. *** Bug 1763942 has been marked as a duplicate of this bug. *** |