Open Stack

Thanks

 Ok I got the spec.

Let's discuss underlaying filtering rule layer in next patch.

2012年11月28日水曜日 Dan Wendlandt dan at nicira.com:

>
>
> On Wed, Nov 28, 2012 at 4:06 AM, Akihiro MOTOKI <motoki at da.jp.nec.com>wrote:
>
>  Hi Nachi,
>
> I will check and test your new patch.
> As I raised these issues, I commented inline. There is no confliciton with
> Dan's comment.
>
>
> (2012/11/28 10:39), Nachi Ueno wrote:
>
> Hi Dan
>
>  Thank you for your reply
>
>
> 2012/11/27 Dan Wendlandt <dan at nicira.com>
>
>
>
>  On Tue, Nov 27, 2012 at 2:34 PM, Nachi Ueno <nachi at nttmcl.com> wrote:
>
> Hi Aaron, Akihiro, Gary
>
>  I would like to ask your opinion about the security group specs.
>
>  [Discussion 1]  security group rule applied for port for network:* ports?
>
>  - Dhcp port (looks not needed)
>
>
>  I don't see obvious use cases here, and a tenant could definitely shoot
> themselves in the foot by configuring security groups here.  Not supporting
> them here would make sense.
>
>   I totally with Dan.  I don't see any useful usecases either.
>
>
>     - Router port ( I could see many usecases, but this may be
> implemented as a service extension such as VPM)
>
>
>  This is tricky.  It make sense to do packet filtering at router ports,
> but I would argue that security groups are the wrong abstraction here.
>  Security groups are very directional, as their original intent was to
> project an "inside" VM from the "outside" world.   That directionality
> doesn't really make sense on router port in my experience.
>
>     My understanding is similar to Dan.
> I see security groups are basically applied to network endpoints such as
> VIF of VM.
> Router is not an network endpoint and the meaning of 'direction' is turned
> for a router port.
> It is better packet filtering at router is supported by other scheme than
> security groups.
>
>
>
>
>
>  IMO, if we take this limitation, these limitation should be done in
> securitygroups_db class.
>
>
>  seems reasonable.
>
>   yes, I think we all agree there.
>
> dan
>
>
>>
>> Ideally some underlying layer of security group seems a better place to
>> implement such logic
>> and securitygroups_db class should dedicate itself to manage security
>> group and its rule.
>> It makes it easier to manage provider specific rules I think.
>>
>>
>>
>> Thanks,
>> Akihiro
>>
>>
>>
>>
>>>
>>>  Dan
>>>
>>>
>>>
>>>
>>>>    Thanks
>>>>  Nachi
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev at lists.openstack.org <javascript:_e({}, 'cvml',
>>>> 'OpenStack-dev at lists.openstack.org');>
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>
>>>
>>>  --
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> Dan Wendlandt
>>> Nicira, Inc: www.nicira.com
>>> twitter: danwendlandt
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org <javascript:_e({}, 'cvml',
>>> 'OpenStack-dev at lists.openstack.org');>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing listOpenStack-dev at lists.openstack.org <javascript:_e({}, 'cvml', '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 <javascript:_e({}, 'cvml',
>> 'OpenStack-dev at lists.openstack.org');>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Wendlandt
> Nicira, Inc: www.nicira.com
> twitter: danwendlandt
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121128/fc5bbc1d/attachment.html>