Open Stack

This is a bug that is a result of changing the behavior of source groups.  For a while we emulated the old style aws source group style that doesn't allow specifying protocol and ports.  This was changed recently and it looks like this check was missed.

Vish

On Oct 6, 2011, at 6:20 AM, Aleksandr Petrovich wrote:

> Hi guys.
> Recently, I've stumbled upon strange behaviour of euca-authorize
> command. I'm using Diablo release
> If I create two security groups and add a rule using  euca-authorize
> command to authorize ICMP traffic from one group to another, why am I
> not able to add another rule for, say, tcp traffic?
> Here are the commands I've tried:
> 
> [apetrovich at ostcore-wslab2 ]$ euca-describe-groups
> GROUP    project1    default    default
> [apetrovich at ostcore-wslab2 ]$ euca-add-group -d "mygroup description" mygroup
> GROUP    mygroup    mygroup description
> [apetrovich at ostcore-wslab2 ]$ euca-describe-groups
> GROUP    project1    default    default
> GROUP    project1    mygroup    mygroup description
> [apetrovich at ostcore-wslab2 ]$ euca-add-group -d "another description" mygroup2
> GROUP    mygroup2    another description
> [apetrovich at ostcore-wslab2 ]$ euca-describe-groups
> GROUP    project1    default    default
> GROUP    project1    mygroup    mygroup description
> GROUP    project1    mygroup2    another description
> [apetrovich at ostcore-wslab2 ]$ euca-authorize --protocol icmp -t -1:-1
> --source-group mygroup mygroup2
> mygroup2 mygroup None icmp -1 -1 0.0.0.0/0
> GROUP    mygroup2
> PERMISSION    mygroup2    ALLOWS    icmp    -1    -1    GRPNAME
> mygroup    FROM    CIDR    0.0.0.0/0
> [apetrovich at ostcore-wslab2 ]$ euca-authorize --protocol tcp
> --port-range 22 --source-group mygroup mygroup2
> mygroup2 mygroup None tcp 22 22 0.0.0.0/0
> ApiError: {'to_port': 22, 'group_id': 2L, 'protocol': 'tcp',
> 'from_port': 22, 'parent_group_id': 3L} - This rule already exists in
> group
> 
> This seems very strange, so I digged in to the sources and found that
> this is happens because of  the method _security_group_rule_exists of
> the nova.api.ec2.CloudController:
> 
> def _security_group_rule_exists(self, security_group, values):
>         """Indicates whether the specified rule values are already
>            defined in the given security group.
>         """
>         for rule in security_group.rules:
>             if 'group_id' in values:
>                 if rule['group_id'] == values['group_id']:
>                     return rule['id']
>             else:
>                 is_duplicate = True
>                 for key in ('cidr', 'from_port', 'to_port', 'protocol'):
>                     if rule[key] != values[key]:
>                         is_duplicate = False
>                         break
>                 if is_duplicate:
>                     return rule['id']
>         return False
> 
> And it looks like it explicitly checks for the source group of the new
> rule, and if there is already exists a rule with the same source group
> it returns id of that group, so, it is not possible to add a different
> rule with the same source group. Is it expected behaviour and I'm
> missing something, or is it just a bug?
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp