Plugin doesn't get called when explicit rules are auto-created.

Bug #1156504 reported by Tomoe Sugihara
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
neutron
Expired
Medium
Unassigned

Bug Description

When security groups are created, explicit rules are automatically created--- allow all for egress, allow all ingress withing "default" SG. Those auto-creations are done directly through DB models, so plugin doesn't get called. Plugin would have no chances to do something upon creation of a SG rule.

Tags: sg-fw
Revision history for this message
Tomoe Sugihara (tomoe) wrote :

I should have caught this earlier when I was working on adding explicit egress rules. I'm now working on a patch to fix this.

Revision history for this message
Aaron Rosen (arosen) wrote :

For grizzly I would recommend backporting a pactch for you plugin to explicity add the rules and then we can do something better in Havana.

Changed in quantum:
milestone: none → havana-1
Revision history for this message
Tomoe Sugihara (tomoe) wrote :

Hi Aaron,

Makes sense. I'm working on a patch for H1. As for our plugin, our code in G still need more work to support SG, so I'm working on SG implementation targeted for H. Hopefully I can backport something to G in the future.

Changed in quantum:
importance: Undecided → Medium
tags: added: sg-fw
Revision history for this message
Tomoe Sugihara (tomoe) wrote :
Download full text (4.1 KiB)

Hi Aaron,

With my following change, I found a mutual recursion issue in the NVP plugin where _ensure_default_security_group() gets called infinitely.

diff --git a/quantum/db/securitygroups_db.py b/quantum/db/securitygroups_db.py
index c2b42b5..b812d20 100644
--- a/quantum/db/securitygroups_db.py
+++ b/quantum/db/securitygroups_db.py
@@ -105,22 +105,33 @@ class SecurityGroupDbMixin(ext_sg.SecurityGroupPluginBase):
             for ethertype in ext_sg.sg_supported_ethertypes:
                 if s.get('name') == 'default':
                     # Allow intercommunication
- ingress_rule = SecurityGroupRule(
- id=uuidutils.generate_uuid(), tenant_id=tenant_id,
- security_group=security_group_db,
- direction='ingress',
- ethertype=ethertype,
- source_group=security_group_db)
- context.session.add(ingress_rule)
-
- egress_rule = SecurityGroupRule(
- id=uuidutils.generate_uuid(), tenant_id=tenant_id,
- security_group=security_group_db,
- direction='egress',
- ethertype=ethertype)
- context.session.add(egress_rule)
-
- return self._make_security_group_dict(security_group_db)
+ ingress_rule = {'security_group_rule':
+ {'tenant_id': tenant_id,
+ 'security_group_id':
+ security_group_db.id,
+ 'direction': 'ingress',
+ 'ethertype': ethertype,
+ 'port_range_min': None,
+ 'port_range_max': None,
+ 'remote_group_id':
+ security_group_db.id,
+ 'protocol': None,
+ 'remote_ip_prefix': None}}
+ self.create_security_group_rule(context, ingress_rule)
+
+ egress_rule = {'security_group_rule':
+ {'tenant_id': tenant_id,
+ 'security_group_id': security_group_db.id,
+ 'direction': 'egress',
+ 'ethertype': ethertype,
+ 'port_range_min': None,
+ 'port_range_max': None,
+ 'remote_group_id': None,
+ 'protocol': None,
+ 'remote_ip_prefix': None}}
+ self.create_security_group_rule(context, egress_rule)
+
+ return self.get_security_group(context, security_group_db.id)

     def get_security_groups(self, context, filters=None, fields=None,
                             sorts=None, limit=None,

Would it make sense to remove _ensure_default_security_group() call in create_security_group_rule_bulk() as follows?
I thought it'd be OK because you wouldn't create a SG rule without having a SG and SG c...

Read more...

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to quantum (master)

Fix proposed to branch: master
Review: https://review.openstack.org/25354

Changed in quantum:
assignee: nobody → Tomoe Sugihara (tomoe)
status: New → In Progress
Changed in quantum:
milestone: havana-1 → none
Revision history for this message
Eugene Nikanorov (enikanorov) wrote :

The patch was abandoned more than a year ago. I suggest marking it as Won't fix as community seems not to be interested in fixing this.

Changed in neutron:
status: In Progress → Incomplete
Revision history for this message
Armando Migliaccio (armando-migliaccio) wrote :

This bug is > 172 days without activity. We are unsetting assignee and milestone and setting status to Incomplete in order to allow its expiry in 60 days.

If the bug is still valid, then update the bug status.

Changed in neutron:
assignee: Tomoe Sugihara (tomoe) → nobody
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for neutron because there has been no activity for 60 days.]

Changed in neutron:
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.