Association targets of floating IP should be limited to reachable IP from external network

[Kevin Fox]

I often create vm's with one public network interface (network with a router), and one or more private interfaces (IE, network without router). When adding a floating ip to one of these instances, it randomly picks one of the ip's and it is a pain to find the other one in the ui when it is wrong.

I believe a floating ip can only be attached when there is a router on the network. If so, can Horizon filter out all the ip address options that do not have a router associated with them?

[Babitha (babitha31)]

Hi Kevin,
Could you please tell me how to reproduce this bug

[Kevin Fox (kevin-fox-y)]

Its not a bug per-se, more of a usability issue.

The fact that all of a tenants all vm's ports show up in the list makes it large. When I have dozens of vm's each with one public and one or more private networks attached, searching the list is difficult, plus half or more of the options can't have floating ip's anyway. So finding the port by ip address that would work with the floating ip can be time consuming.

Does this help?

[Akihiro Motoki (amotoki)]

I think the proposed feature is useful for better UX. It is not a bug so I mark this as "Wish List". It may be worth registered as a blueprint.

[Akihiro Motoki (amotoki)]

From UX perspective, I start to think it should be a bug with Medium priority rather than WishList. It easily happens when a tenant has multiple networks (a network with connectivity to public network and an isolated network) and has more instances.

[OpenStack Infra (hudson-openstack)]

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

[Akihiro Motoki (amotoki)]

IMHO it is nice we have this in Juno because it reduces confusion in users when an instance has multiple networks.

[OpenStack Infra (hudson-openstack)]

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

commit 277c7bc7376891dc5235b67a3892c6c042483b8d
Author: Akihiro Motoki <email address hidden>
Date: Mon Aug 25 19:03:43 2014 +0900

    Display only reachable IP as Floating IP association target

    In Neutron deployments some VM port can be unreachable from
    external network and cannot be associated with floating IP.
    It is confusing if these ports are listed in Floating IP
    Associate form.

    Change-Id: I2d8faf0dbf4490d198b883fe1becfd950b1b4d14
    Closes-Bug: #1252403

[Daniel Speichert (dasp)]

I believe this has created a regression. A user without admin role does not see its own ports in a project to associate the IP to.
Can somebody verify that?

[Stefan Walter (walteste)]

On my Juno installation a _member_ role only user cannot see the ports of VMs he started when attaching a floating IP. On the command line attaching the floating IP works with the same user credentials using 'neutron port-list', 'floatingip-list' and 'neutron floatingip-associate'.

I'm using RDO on RHEL7 with the following version numbers:

openstack-dashboard-2014.2.1-1.el7.centos.noarch
openstack-neutron-2014.2.1-1.el7.centos.noarch

[OpenStack Infra (hudson-openstack)]

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

[Vincent Untz (vuntz)]

This change does indeed breaks the floating IP association when the gateway router is not part of the tenant we're currently looking at. Patch above should fix the regression.

[Martin Gerhard Loschwitz (martin-loschwitz)]

I think it's debatable whether the original patch should be reverted. There are certain SDN solutions out there that do not require the router for a floating IP to be visible from the actual VM. In OpenContrail, the whole DNAT and SNAT magic happens on the vrouter level and even works if there is no connection at all between the tenant network and the external network. The original patch that has caused this regression, in fact, breaks floating IP assignment with Juno and OpenContrail 2.0.

[OpenStack Infra (hudson-openstack)]

Change abandoned by David Lyle (<email address hidden>) on branch: master
Review: https://review.openstack.org/142605
Reason: This review is > 4 weeks without comment, and failed Jenkins the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.