Adding new security group rule Custom ICMP rule has wrong error messages

Bug #1511748 reported by Suraj Deshmukh
34
This bug affects 5 people
Affects Status Importance Assigned to Milestone
OpenStack Dashboard (Horizon)
Fix Released
High
Yves-Gwenael Bourhis

Bug Description

When adding new rules to 'default' security group. When trying to add new 'Custom ICMP rule', I am not able to select 'Type' as -1 and 'Code' as -1 as well. But the same works from the command line utility i.e. [$ nova secgroup-add-rule default icmp -1 -1 0.0.0.0/0].

But the problem is the errors that are provided are wrong. Instead of 'wrong code' or 'wrong type' it says 'wrong port'. The exact info can be seen in snapshot at [1]. I am running this off a devstack single node instance.

[1] http://ibin.co/2KphvtVSTrCV

Revision history for this message
Suraj Deshmukh (surajssd009005) wrote :
Changed in horizon:
assignee: nobody → Suraj Deshmukh (surajssd009005)
Revision history for this message
Suraj Deshmukh (surajssd009005) wrote :

This Bug solving depends on Bug #1511940 being solved.

Changed in horizon:
status: New → In Progress
Revision history for this message
yujie (16189455-d) wrote :

Not able to reproduce in latest kilo.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to horizon (master)

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on horizon (master)

Change abandoned by Suraj Deshmukh (<email address hidden>) on branch: master
Review: https://review.openstack.org/249546
Reason: There were improper changes made to .po files

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to horizon (master)

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

tags: added: mitaka-backport-potential
Revision history for this message
Yves-Gwenael Bourhis (yves-gwenael-bourhis) wrote :

This bug affects the stable/mitaka branche and needs a backport because it unallows creating a simple ping rule as described in this duplicate bug : https://bugs.launchpad.net/horizon/+bug/1583545

Revision history for this message
Rob Cresswell (robcresswell-deactivatedaccount) wrote :

Assignee removed due to inactivity.

Changed in horizon:
assignee: Suraj Deshmukh (surajssd009005) → nobody
importance: Undecided → High
milestone: none → newton-1
Changed in horizon:
assignee: nobody → Yves-Gwenael Bourhis (yves-gwenael-bourhis)
Changed in horizon:
milestone: newton-1 → newton-2
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to horizon (master)

Reviewed: https://review.openstack.org/249662
Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=edfde8b3f54cc4264d770e5fd49f07d164a85a28
Submitter: Jenkins
Branch: master

commit edfde8b3f54cc4264d770e5fd49f07d164a85a28
Author: Suraj Deshmukh <email address hidden>
Date: Wed Nov 25 14:53:17 2015 +0530

    ICMP type & code validation while adding Security Group rules

    While adding new 'Security Group Rule' viz. 'Custom ICMP rule' when
    wrong ICMP 'type' or 'code' was given the errors it would show were
    'Not a valid port number'; which is misleading. The errors should
    rather be 'Not a valid ICMP type' or 'Not a valid ICMP code'.

    Also for validating ICMP 'type' and 'code' there wasn't any dedicated
    functionality in 'oslo.utils/netutils' so the code for validating 'TCP
    ports' was used. TCP ports are in range 0 to 65535 while ICMP 'type'
    and 'code' are in range 0 to 255, so using 'TCP port validation' code
    is incorrect.

    When -1 is used in 'ICMP code' or 'ICMP type' that means any number
    0 to 255 is valid.

    Here newer dedicated functionality of 'oslo.utils/netutils' is used
    for validating ICMP 'type' and ICMP 'code'.

    Change-Id: I8e227a0021d418294fa7b7756d58e39f2100850a
    Closes-Bug: #1511748

Changed in horizon:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to horizon (stable/mitaka)

Fix proposed to branch: stable/mitaka
Review: https://review.openstack.org/328909

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to horizon (stable/mitaka)

Reviewed: https://review.openstack.org/328909
Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=0b4b2976afc57ca4fd4ec1dd77ae9d578bc012bf
Submitter: Jenkins
Branch: stable/mitaka

commit 0b4b2976afc57ca4fd4ec1dd77ae9d578bc012bf
Author: Suraj Deshmukh <email address hidden>
Date: Wed Nov 25 14:53:17 2015 +0530

    ICMP type & code validation while adding Security Group rules

    While adding new 'Security Group Rule' viz. 'Custom ICMP rule' when
    wrong ICMP 'type' or 'code' was given the errors it would show were
    'Not a valid port number'; which is misleading. The errors should
    rather be 'Not a valid ICMP type' or 'Not a valid ICMP code'.

    Also for validating ICMP 'type' and 'code' there wasn't any dedicated
    functionality in 'oslo.utils/netutils' so the code for validating 'TCP
    ports' was used. TCP ports are in range 0 to 65535 while ICMP 'type'
    and 'code' are in range 0 to 255, so using 'TCP port validation' code
    is incorrect.

    When -1 is used in 'ICMP code' or 'ICMP type' that means any number
    0 to 255 is valid.

    Here newer dedicated functionality of 'oslo.utils/netutils' is used
    for validating ICMP 'type' and ICMP 'code'.

    Change-Id: I8e227a0021d418294fa7b7756d58e39f2100850a
    Closes-Bug: #1511748
    (cherry picked from commit edfde8b3f54cc4264d770e5fd49f07d164a85a28)

tags: added: in-stable-mitaka
Revision history for this message
Doug Hellmann (doug-hellmann) wrote : Fix included in openstack/horizon 10.0.0.0b2

This issue was fixed in the openstack/horizon 10.0.0.0b2 development milestone.

Revision history for this message
Davanum Srinivas (DIMS) (dims-v) wrote : Fix included in openstack/horizon 9.1.0

This issue was fixed in the openstack/horizon 9.1.0 release.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote :

This issue was fixed in the openstack/horizon 9.1.0 release.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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