Created same SG rule to one SG in case of neutron server active-active

[Nam]

I had three controller. i found a bug, i can create same security group rules to one security group at same timing

How to reproduce:

Topology: http://codepad.org/ff0debPB

Step 1: Create on security group:
$ neutron security-group-create test-secgroup

Step 2: Create multiple security-group-rules that specifying same attributes
Please run following command from multiple servers at same timing.
- On controller1:
$ neutron security-group-rule-create test-secgroup
- On controller2:
$ neutron security-group-rule-create test-secgroup

After check security-group-rule:

Running command: $ neutron security-group-rule-list
This is the result: http://codepad.org/TiFHzopW
(Plese focus on line 06 and line 15)

After check database: http://codepad.org/zFogYuVA
Please focus on record number 03 (line 06) and record number 12 (line 15)

I think. In originally, one command on controller will be fail and we catch a message as following: "Security group rule already exists. Rule id is 04a88afd-6378-49e7-b454-17e40755a645.". But currently, two commands are success

[Manjeet Singh Bhatia (manjeet-s-bhatia)]

Could you explain more about setup? how many compute, network and controller you have

I tried this with devstack 2 node. it did create another rule when it already exists.

http://paste.openstack.org/show/483650/

[Manjeet Singh Bhatia (manjeet-s-bhatia)]

I missed not in previous comment. actually it did not create another rule when it exists already

[Nam (namnh)]

Hi Manjeet Singh Bhatia:

Yes. I will explain more detail:

- First: I build three controller nodes by Devstack. It has services include: nova, neutron, glance, keystone, horizon. After done, I turn off all of services.

- Second: I configure MariaBD Galera to cluster database, configuration to sync time.

- Third: I configure pacemaker to create VIP (Virtual IP) and setup haproxy to load balancing requests and configure cluster Rabbitmp

- Finally: I edit the files configure of services in Openstack so that they will point to VIP then I change the endpoint of services to VIP in the keystone database.

Next step: I run step by step as I mentioned as above and the I received result as I reported.

Please consider to you must run two commands AT SAME TIMMING on two controller nodes. You will reproduce this bug.

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Change abandoned by Armando Migliaccio (<email address hidden>) on branch: master
Review: https://review.openstack.org/272398
Reason: This review is > 4 weeks without comment, and failed Jenkins the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.

[Armando Migliaccio (armando-migliaccio)]

Needs a new owner.

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/345978
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=fb375bd7a40f6ff86ac1db2134466d0183690f7e
Submitter: Jenkins
Branch: master

commit fb375bd7a40f6ff86ac1db2134466d0183690f7e
Author: Anh Tran <email address hidden>
Date: Fri Jul 22 17:59:03 2016 +0700

    Prevent duplicate SG rules in 'concurrent requests' case

    Problem: The process of transaction is too short.
    In case of concurrent requests, both requests can pass all tests
    and going to write to database. Sometimes the transaction of first
    request closed before the transaction of the second request has been
    open, because of the above problem. So both of them can access the
    latest data (revision number), then passing the StaleDataError and
    writing to database successfully.

    This patch moved the _check_for_duplicate_rules_in_db into transaction
    to prevent race condition.

    Change-Id: I9ff2bf830c0c9d1114833d33603622f447ee7ca2
    Closes-bug: #1532696

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron 9.0.0.0b3 development milestone.