Open Stack

Hi fawad
Yes, you're right.
I mentioned that not to answer the exact question, but think to drop some
line around it.
I do hope we can provide the capacity in the API layer, and let the
security group become more intuitive for users.

On Tue, Sep 16, 2014 at 10:45 PM, Fawad Khaliq <fawad at plumgrid.com> wrote:

> Hi Boahua,
>
> Thanks for sharing your thoughts. The issues seen are not related to
> "access", they are all related to API layer, so having ALLOW all etc does
> not fix/workaround the problems I mentioned.
>
> Please do share if you have something more to add.
>
> Fawad Khaliq
>
> On Tue, Sep 16, 2014 at 7:28 PM, Baohua Yang <yangbaohua at gmail.com> wrote:
>
>> The similar problem has been discussed before.
>> There is no definitive answer, and currently seems we cannot simply
>> disable it since G version.
>> However, we can add some ALLOW rules to bypass the rules inside the
>> iptables chains.
>> Hope there be more flexibility to controller the security groups in the
>> future release.
>>
>>
>> On Tue, Sep 16, 2014 at 4:00 PM, Fawad Khaliq <fawad at plumgrid.com> wrote:
>>
>>> Folks,
>>>
>>> I have had discussions with some folks individually about this but I
>>> would like bring this to a broader audience.
>>>
>>> I have been playing with security groups and I see the notion of
>>> 'default' security group seems to create some nuisance/issues.
>>>
>>> There are list of things I have noticed so far:
>>>
>>>    - Tenant for OpenStack services (normally named service/services)
>>>    also ends up having default security group.
>>>    - Port create operation ends up ensuring default security groups for
>>>    all the tenants as this completely seems out of the context of the tenant
>>>    the port operation takes place. (bug?)
>>>    - Race conditions where if system is stressed and Neutron tries to
>>>    ensure the first default security group and in parallel another call comes,
>>>    Neutron ends up trying to create multiple default security groups as the
>>>    checks for duplicate groups are invalidated as soon as the call make past a
>>>    certain point in code.
>>>    - API performance where orchestration chooses to spawn 1000 tenants
>>>    and we see unnecessary overhead.
>>>    - For plugins that use RESTful proxy backends require the backend
>>>    systems to be up at the time neutron starts. [Minor, but affects some
>>>    packaging solutions]
>>>
>>>
>>> To summarize, is there a way to disable default security groups?
>>> Expected answer is no; can we introduce a way to disable it? If that does
>>> not make sense, should we go ahead and fix the issues around it?
>>>
>>> I am sure some of you must have seen some of these issues and solved
>>> them already. Please do share how do tackle these issues?
>>>
>>> Thanks,
>>> Fawad Khaliq
>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> Best wishes!
>> Baohua
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best wishes!
Baohua
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140916/c5b694cc/attachment.html>