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@ostcore-wslab2 ]$ euca-describe-groups
GROUPproject1defaultdefault
[apetrovich@ostcore-wslab2 ]$ euca-add-group -d mygroup description mygroup
GROUPmygroupmygroup description
[apetrovich@ostcore-wslab2 ]$ euca-describe-groups
GROUPproject1defaultdefault
GROUPproject1mygroupmygroup description
[apetrovich@ostcore-wslab2 ]$ euca-add-group -d another description mygroup2
GROUPmygroup2another description
[apetrovich@ostcore-wslab2 ]$ euca-describe-groups
GROUPproject1defaultdefault
GROUPproject1mygroupmygroup description
GROUPproject1mygroup2another description
[apetrovich@ostcore-wslab2 ]$ euca-authorize --protocol icmp -t -1:-1
--source-group mygroup mygroup2
mygroup2 mygroup None icmp -1 -1 0.0.0.0/0
GROUPmygroup2
PERMISSIONmygroup2ALLOWSicmp-1-1GRPNAME
mygroupFROMCIDR0.0.0.0/0
[apetrovich@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@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
