Open Stack

Hi Quantum folks (particulary who involve secgroup implementation),

During reviewing and tesitng Nachi's secgroup implementation,
quesitons are raised about secgroup spec I would like to confirm.

(1) How should a rule without both source_ip_prefix (source IP cidr) and source_group_id should handled?
There are two possible options: (a) If both source_ip_prefix and source_group_id are not specified,  reject such a rule.
(b) (a) If both source_ip_prefix and source_group_id are not specified, assume source_ip_prefix is 0.0.0.0/0.
Note that in the current implementation, the secgroup db layyer accepts such rule but lb implmentation ignores it.
It is confusing and it needs to be improved.

(2) How should source_ip_prefix or source_group_id be translated into the implementation for egress rule?
IMO they should be interpreted as "destination" in egress rule. How do you think?
Naming of "source_*" comes from the traditional secgroup context (i.e., "ingress") and it would be better to rename attribute names.

Thanks,
Akihiro

(2012/11/29 10:38), Nachi Ueno wrote:
> 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 <mailto: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 <http://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 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 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 <http://www.nicira.com>
>     twitter: danwendlandt
>     ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121202/625c4990/attachment.html>