← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 2107446] Re: When a new security group rule is created, logging is not properly configured

 

Reviewed:  https://review.opendev.org/c/openstack/neutron/+/956094
Committed: https://opendev.org/openstack/neutron/commit/6e70cd450c8b920a1055af88e000f824f8bea2cf
Submitter: "Zuul (22348)"
Branch:    master

commit 6e70cd450c8b920a1055af88e000f824f8bea2cf
Author: Elvira Garcia <egarciar@xxxxxxxxxx>
Date:   Tue Jul 29 17:42:36 2025 +0200

    [SGL] Use admin context to retrieve log objs
    
    Previously we tried to search which log objects existed based on the
    context of the user who is creating a change on a security group rule.
    This is not correct as only admin can fetch log objects.
    
    Closes-Bug: #2107446
    Change-Id: Ia65e06c83ced9cde7618d4d7f3c7b0b3ae48c3fa
    Signed-off-by: Elvira Garcia <egarciar@xxxxxxxxxx>


** Changed in: neutron
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/2107446

Title:
  When a new security group rule is created, logging is not properly
  configured

Status in neutron:
  Fix Released

Bug description:
  OpenStack Version: 2024.1 (with OVN)

  How to reproduce:
  1. Create new security group in Project A
  $ openstack security group create sg-test-01 --project project-a

  2. Configure logging for that security group.
  $ openstack network log create log-test-01 --event ALL --resource-type security_group --resource sg-test-01 --project project-a

  3. Create a security group rule using a context where the project is set to Project A
  $ openstack security group rule create sg-test-01 --ingress --protocol tcp --remote-ip 1.1.1.1/32 --dst-port 1111 --project project-a

  4. Create a security group rule using a context where the project is set to Project B
  $ openstack security group rule create sg-test-01 --ingress --protocol tcp --remote-ip 2.2.2.2/32 --dst-port 2222 --project project-a

  5. Check the acl table in OVN NB DB.
  $ ovn-nbctl list acl
  Defaulted container "ovsdb" out of: ovsdb, init (init)

  _uuid               : f574dfbe-6342-4ed6-9fbe-a2c5fe1de820
  action              : allow-related
  direction           : to-lport
  external_ids        : {"neutron:security_group_rule_id"="967de8be-4cd1-4a2c-93ef-473b1ffc74b4"}
  label               : 867022203
  log                 : true
  match               : "outport == @pg_0a6255a5_2892_476b_92a7_74b792072c18 && ip4 && ip4.src == 1.1.1.1/32 && tcp && tcp.dst == 1111"
  meter               : acl_log_meter
  name                : neutron-7961f56c-b0d7-4c3b-9bc8-828a446dd53e
  options             : {log-related="true"}
  priority            : 1002
  severity            : info

  _uuid               : 3918f28c-8f6d-4a73-b0ad-a35174fcb386
  action              : allow-related
  direction           : to-lport
  external_ids        : {"neutron:security_group_rule_id"="f132a1a4-a2aa-448f-8d25-60936814c0ea"}
  label               : 0
  log                 : false
  match               : "outport == @pg_0a6255a5_2892_476b_92a7_74b792072c18 && ip4 && ip4.src == 2.2.2.2/32 && tcp && tcp.dst == 2222"
  meter               : []
  name                : []
  options             : {}
  priority            : 1002
  severity            : []

  --

  Expected :
  In step 5, both ACLs created in steps 3 and 4 should have logging enabled.

  Actual :
  Only the ACL created in step 3 has logging enabled.
  The ACL from step 4 does not have logging configured.

  It appears that the issue is caused by a project ID filter applied
  during the logging update process when a new security group rule is
  created.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/2107446/+subscriptions



References