Cannot list rules in default security group

Bug #1256935 reported by Lars Kellogg-Stedman
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
python-openstackclient
Fix Released
Undecided
Terry Howe

Bug Description

Listing the rules in a security group other than "default" works just fine:

    $ openstack security group rule list webserver
    +--------------------------------------+-------------+-----------+------------+
    | ID | IP Protocol | IP Range | Port Range |
    +--------------------------------------+-------------+-----------+------------+
    | 59a49c72-1844-4ea1-9b3b-db7e308ba899 | tcp | 0.0.0.0/0 | 8080:8080 |
    | 847c4151-823d-4542-b27e-b24ea7841160 | tcp | 0.0.0.0/0 | 443:443 |
    | bf8304e5-e1eb-4751-a4c7-f75963cd42c4 | tcp | 0.0.0.0/0 | 80:80 |
    +--------------------------------------+-------------+-----------+------------+

But trying to do the same for the "default" group results in an error:

    $ openstack security group rule list default
    ERROR: cliff.app %u format: a number is required, not NoneType

Using the ID instead of the name results in the same error:

    $ openstack security group rule list 8c49cd42-7c42-4a1f-af1d-492a0687fc12
    ERROR: cliff.app %u format: a number is required, not NoneType

Revision history for this message
Dean Troyer (dtroyer) wrote :

What release/commit were you using? I get this when running as a user:

dtroyer@bunsen:~ $ os security group rule list default
+-----+-------------+-----------+------------+
| ID | IP Protocol | IP Range | Port Range |
+-----+-------------+-----------+------------+
| 467 | icmp | 0.0.0.0/0 | |
| 468 | tcp | 0.0.0.0/0 | 22:22 |
| 469 | tcp | 0.0.0.0/0 | 6082:6082 |
+-----+-------------+-----------+------------+

Changed in python-openstackclient:
status: New → Incomplete
Revision history for this message
Lars Kellogg-Stedman (larsks) wrote :

This is version 0.2.2:

    $ openstack --version
    openstack 0.2.2

Running "nova secgroup-list-rules default" returns:

+-------------+-----------+---------+-----------+--------------+
| IP Protocol | From Port | To Port | IP Range | Source Group |
+-------------+-----------+---------+-----------+--------------+
| | | | | default |
| | | | | default |
| icmp | -1 | -1 | 0.0.0.0/0 | |
| tcp | 22 | 22 | 0.0.0.0/0 | |
+-------------+-----------+---------+-----------+--------------+

Revision history for this message
Lars Kellogg-Stedman (larsks) wrote :

I get the same error when using code from e06e1a2:

$ openstack --version
openstack 0.2.2.29
$ openstack security group rule list default
INFO: urllib3.connectionpool Starting new HTTP connection (1): rdo-havana-api.default.virt
INFO: urllib3.connectionpool Starting new HTTP connection (1): 192.168.122.136
ERROR: cliff.app %u format: a number is required, not NoneType

Revision history for this message
Lars Kellogg-Stedman (larsks) wrote :

The _xform_security_group function in openstackclient/compute/v2/security_group.py is being called with sgroup set to:

{u'from_port': None, u'group': {u'tenant_id': u'db73ba54c4d04066a4c151be0e4ec5de', u'name': u'default'}, u'ip_protocol': None, u'to_port': None, u'parent_group_id': u'8c49cd42-7c42-4a1f-af1d-492a0687fc12', u'ip_range': {}, u'id': u'674861df-3f94-4d52-91b1-c06932592914'}

The error stems from trying to format the port_range value:

    info.update(
        {'port_range': "%u:%u" % (
            info.pop('from_port'),
            info.pop('to_port'),
        )}
    )

At first glance this seems like a valid rule (it's based on security groups rather than ports), so this should probably require that both from_port and to_port are not None.

Revision history for this message
Lars Kellogg-Stedman (larsks) wrote :

...in fact, looking at the code, it looks like it currently doesn't handle security group based rules at all (rules that permit traffic by security group membership rather than by ip/port). Try this:

$ neutron security-group-create testgroup
$ neutron security-group-rule-create --direction ingress --remote-group-id testgroup testgroup

And then:

$ openstack security group rule list testgroup
INFO: urllib3.connectionpool Starting new HTTP connection (1): rdo-havana-api.default.virt
INFO: urllib3.connectionpool Starting new HTTP connection (1): 192.168.122.136
ERROR: cliff.app %u format: a number is required, not NoneType

Revision history for this message
Terry Howe (thowe-g) wrote :

I'm seeing this and other bad behavior, but the same thing works with the neutron security groups. I have the security group code for neutron on a branch waiting for gerrit reviews. i think that will resolve this issue.

Changed in python-openstackclient:
assignee: nobody → Terry Howe (thowe-g)
status: Incomplete → Confirmed
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to python-openstackclient (master)

Fix proposed to branch: master
Review: https://review.openstack.org/75091

Changed in python-openstackclient:
status: Confirmed → In Progress
Terry Howe (thowe-g)
Changed in python-openstackclient:
status: In Progress → Fix Committed
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to python-openstackclient (master)

Reviewed: https://review.openstack.org/75091
Committed: https://git.openstack.org/cgit/openstack/python-openstackclient/commit/?id=ada9d35cbe477d7225d217c6c1926b5fb8aa0a92
Submitter: Jenkins
Branch: master

commit ada9d35cbe477d7225d217c6c1926b5fb8aa0a92
Author: Terry Howe <email address hidden>
Date: Thu Feb 20 09:29:38 2014 -0700

    Fix format errors in nova security group rule list

    * port range was throwing exception for None to/from ports
    * ip_range didn't always have cidr causing error
    * ip_protocol None at times and looked bad

    Closes-Bug #1256935

    Change-Id: I451a0f038a3e9646bca3f278c5d6f6d7e3097a83

Dean Troyer (dtroyer)
Changed in python-openstackclient:
milestone: none → m3
Dean Troyer (dtroyer)
Changed in python-openstackclient:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.