Ashish, I hear your approach from Neutron managing this, so this assumes some topology for multisite. Based on Release notes of OpenStack Mitaka... I see
Deprecate security_group_api configuration option. The current values are nova and neutron. In future the correct security_group_api option will be chosen based on the value of use_neutron which provides a more coherent user experience. I heard that JuJu uses its own secgroup which is different from Neutron and thus JOID installer had no issues based on changes to secgroup in Mitaka So prescribing some flow you have mentioned for security group is interesting and like to know what topology of multisite you are referring to, to be able to absorb, what actually is being proposed here for tech team to understand. Suggest you refer this to security working group or may be bring to weekly tech discussions as what exactly is current state of security group in OPNFV multisite project and what you would like to change to make it better. If this is out of context please ignore it. Thanks Prakash Prakash Ramchandran [logo_huawei] R&D USA FutureWei Technologies, Inc Email: prakash.ramchand...@huawei.com<mailto:s.c...@huawei.com> Work: +1 (408) 330-5489 Mobile: +1 (408) 406-5810 2330 Central Expy, Santa Clara, CA 95050, USA From: opnfv-tech-discuss-boun...@lists.opnfv.org [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Ashish singh Sent: Thursday, September 08, 2016 8:58 AM To: opnfv-tech-discuss; caizhiyuan (A); Meimei; Sama, Malla Reddy; Zhipeng Huang; Ashish singh; Dimitri Mazmanov; joehuang; Ashish Singh7 Subject: [opnfv-tech-discuss] [multisite] Secgroup syncing Approach Hi All, I have drafted a basic approach for security group synching in release D and it is as follows. - Get list of secgroups with rules for a tenant from all the regions which do not have remote group references(currently, we ignore remote secgroup references as there can be lot nested dependencies). - Traverse each region and do the following - Get the list of secgroup which are present in all the regions except the current region, These are the secgroups which we need to sync in current region: say it GRP_TO_BE_SYNCED - There can be case where the secgroup from GRP_TO_BE_SYNCED may have the same rules as the secgroup in current region(If not initially but which will obviously happen after a sync job). - Traverse through the GRP_TO_BE_SYNCED and check if there are such secgroups(rules overlapping groups), if there, ignore it. After this filtering, the remaining secgroup will be the final list of secgroup which should be created for the current region. - Create the secgroup with the final list of secgroups in the region. - Repeat the process for all the tenant in batches. The default security group is not syned, as I feel region specific default secgroup has to there in each region. We must use neutron to perform all our operations as with neutron we have total control over it. For creating a security group we need the following information --tenant-id TENANT_ID The owner tenant ID. --description DESCRIPTION Description of security group rule. --direction {ingress,egress} Direction of traffic: ingress/egress. --ethertype ETHERTYPE IPv4/IPv6 --protocol PROTOCOL Protocol of packet. Allowed values are [icmp, icmpv6, tcp, udp] and integer representations [0-255] --port-range-min PORT_RANGE_MIN Starting port range. For ICMP it is type. --port-range-max PORT_RANGE_MAX Ending port range. For ICMP it is code. --remote-ip-prefix REMOTE_IP_PREFIX CIDR to match on. We have all these details with us available. Let us take this forward, Please review/comment. -- Best Regards, Ashish Singh
_______________________________________________ opnfv-tech-discuss mailing list opnfv-tech-discuss@lists.opnfv.org https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
