I confirmed that Bug #978354 found in RDO is also in RHOS. # rpm -qa | grep quantum openstack-quantum-openvswitch-2013.1.2-3.el6ost.noarch python-quantum-2013.1.2-3.el6ost.noarch openstack-quantum-2013.1.2-3.el6ost.noarch python-quantumclient-2.2.1-1.el6ost.noarch +++ This bug was initially created as a clone of Bug #978354 +++ Description of problem: You cannot add a security group rule such as: protocol: icmp type: 8 code: 0 It causes the following error: 2013-06-26 21:15:47.348 15711 TRACE nova.api.openstack QuantumClientException: For TCP/UDP protocols, port_range_min must be <= port_range_max I'm using the Horizon dashboard to add the rule, but it would be the same for a direct API operation. Version-Release number of selected component (if applicable): # rpm -qa | grep quantum python-quantumclient-2.2.1-3.fc19.noarch python-quantum-2013.1.2-1.fc19.noarch openstack-quantum-openvswitch-2013.1.2-1.fc19.noarch openstack-quantum-2013.1.2-1.fc19.noarch Additional info: The problem lies in _validate_security_group_rules() in quantum/db/securitygroups_db.py In this function, the following condition is validated. rule['port_range_min'] <= rule['port_range_max'] But in the case of ICMP protocol rule, since rule['port_range_min'] and rule['port_range_max'] correspond to icmp type and code, this validation is wrong. Instead, the following condition should be checked. if ( rule['port_range_min'] >= -1 and rule['port_range_min'] <= 255 and rule['port_range_max'] >= -1 and rule['port_range_max'] <= 255): See the attachment for my patch, but this is just a quick hack. More fundamental refactoring should be done to handle different protocols separately.
A mitigation for this issue is to open ALL ICMP type range (set min==max==0). A more granular configuration, like enabling only ping (type-8), is not supported with the current code base. I assume this is an u/s issue.
It seems like in rhos 4.0 (2013-11-08.1 puddle) this validation has been fixed already: $ neutron security-group-rule-create --protocol icmp --port-range-min 8 --port-range-max 0 default Created a new security_group_rule: +-------------------+--------------------------------------+ | Field | Value | +-------------------+--------------------------------------+ | direction | ingress | | ethertype | IPv4 | | id | 16d50488-718d-4cf9-b02b-cee52d436def | | port_range_max | 0 | | port_range_min | 8 | | protocol | icmp | | remote_group_id | | | remote_ip_prefix | | | security_group_id | 9d0fbe03-909a-4ef8-9022-f1ba664554b3 | | tenant_id | c6218eb9b8c44c91861ea7998db55505 | +-------------------+--------------------------------------+
Moving to Verified per comment#4.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHEA-2013-1859.html