[mos] Button 'Deassociate floating IP' disappeared from Horizon menu

[Anastasia Palkina]

"build_id": "2014-06-02_00-40-36",
"mirantis": "yes",
"build_number": "334",
"nailgun_sha": "0828946af6a2e757fb018c2f69f7f81f0ea4b7f1",
"ostf_sha": "3690709d95c1f42506b6d955b44221910cec8527",
"fuelmain_sha": "7fbe99c86a4fffcb5ebc5b86046dcf1c20776f61",
"astute_sha": "55df06b2e84fa5d71a1cc0e78dbccab5db29d968",
"release": "4.1B",
"fuellib_sha": "c64ffdc5e7bfe7fa8eb971be1fea2260ee849ab5"

1. Create new environment (Ubuntu, simple mode)
2. Choose Savanna installation
3. Add compute, controller, cinder
4. Choose debugging
5. Start deployment. It was successful
6. Start OSTF tests. Test "Check network connectivity from instance via floating IP" has failed with error: Floating IP cannot be removed
7. Manually created instance, associate floating IP
8. Button 'Deassociate floating IP' disappeared from menu (see screen)

[Alexei Kornienko (alexei-kornienko)]

I have couple of questions about your deployment:

1) VersionConflict: (six 1.4.1 (/usr/lib/python2.7/dist-packages), Requirement.parse('six<1.4.1'))
I see this error in logs of several services. Under normal conditions this should not happen. Could you please check why requirements are not installed correctly?

2) Calling method <bound method FloatingIPController.index of <nova.api.openstack.compute.contrib.floating_ips.FloatingIPController object at 0x4f478d0>> _process_stack /usr/lib/python2.7/dist-packages/nova/api/openstack/wsgi.py:962
2014-06-02T12:32:12.203879+00:00 debug: 2014-06-02 12:32:06.626 10393 WARNING nova.openstack.common.db.sqlalchemy.session [req-73182e09-21b3-4007-8f70-203760db98ae 2e53b942929e40eeae094e4a3faadd2a b3edad09fe4048229641c1b4b0c54305] Got mysql server has gone away: (2006, 'MySQL server has gone away')

It seems that Nova API service is getting 'MySQL server has gone away' errors from time to time (>30 errors in log file) Seems that there are some issues with db connection and it may cause failures in many places across openstack. Is it possible that it may be the root of failures here?

[Anastasia Palkina (apalkina)]

1) There is a bug about VersionConflict: https://bugs.launchpad.net/fuel/+bug/1325519
2) I don't know the specific of it

[Alexander Maretskiy (maretskiy)]

The interesting point is ability to deassociate floating IP via "Access & Security -> Floating IPs -> {instance} -> Deassociate" - this works fine

[Alexander Maretskiy (maretskiy)]

This is a configuration issue: the value of "simple_ip_management" should be set to True:

On controller node, /usr/share/openstack-dashboard/openstack_dashboard/local/local_settings.py, line 88
HORIZON_CONFIG["simple_ip_management"] = True

[Mike Scherbakov (mihgen)]

Assuming that it is configuration issue, assigning this bug to Fuel Library team to deal with it.

[OpenStack Infra (hudson-openstack)]

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

[Dmitry Borodaenko (angdraug)]

Actually simple_ip_management is set to False for a reason, it is incompatible with Neutron:
http://docs.openstack.org/developer/horizon/topics/settings.html#simple-ip-management
https://bugs.launchpad.net/horizon/+bug/1196541

[Dmitry Borodaenko (angdraug)]

Please explain how simple_ip_management setting affects presense of "Disassociate floating IP" button in Horizon.

[Alexander Maretskiy (maretskiy)]

The following code is responsible for rendering "Disassociate floating IP" element of drop-down table action (within class SimpleDisassociateIP):

/usr/share/openstack-dashboard/openstack_dashboard/dashboards/project/instances/tables.py, lines 539-542:

     def allowed(self, request, instance):
         if not conf.HORIZON_CONFIG["simple_ip_management"]:
             return False
         return not is_deleting(instance)

[Dmitry Borodaenko (angdraug)]

Thanks, superficially looking it's not going to be a trivial fix to address this limitation in Horizon. If the fix really ends up non-trivial, we shouldn't be backporting it to 4.1 and 5.0.

[Timur Sufiev (tsufiev-x)]

This seems to me more like a Neutron limitation, not Horizon one. Quote from the link above:

Currently “simple” floating IP address management is not compatible with Neutron. There are two reasons for this. First, Neutron does not support the default floating IP pool at the moment. Second, a Neutron floating IP can be associated with each VIF and we need to check whether there is only one VIF for an instance to enable simple association support.

So, if we could overcome that Neutron limitation, Horizon fix would be trivial.

[Ilya Shakhat (shakhat)]

Timur, I'm not agree.
Neutron provides API to disassociate floating ip. The call is simple and requires id of floating ip to be provided. Horizon however doesn't support it. I suppose that UI could be as following:
  * if instance has only 1 interface then disassociate may work in single click.
  * if instance has more than 1 interface then popup should be shown allowing user to select which one floating ip to delete.

However the fix seems to be not easy. Currently Horizon retrieves instance's ip addresses from nova, which returns list of ips without distinguish between private and floating ips.

[Timur Sufiev (tsufiev-x)]

Lowering to 'Low' as 'Disassociate Floating IP' action is still available from Access and Security -> Floating IPs.

[Timur Sufiev (tsufiev-x)]

Text for release notes:

If one of 2 Neutron options was chosen in network configuration section during the Environment deployment, there won't be 'Disassociate' option in Project->Instances table for an Instance with an associated floating IP (contrary to the case when 'Nova Network' option was chosen during deployment). This action can be found (and performed) in Project->Access & Security->Floating IPs table.

[Timur Sufiev (tsufiev-x)]

The upstream UX bug for Horizon is here https://bugs.launchpad.net/horizon/+bug/1226003 and since it relies on modification table filtering to use GET-requests instead of POST-requests (a feature targeted with a separate blueprint), it definitely won't make it to the Juno release. Removing 6.0 Milestone as not realistic one.

[Timur Sufiev (tsufiev-x)]

Moving to 8.0 because the upstream patch relies on a change to horizon tables that community has no interest in reviewing/merging (and merging it into MOS codebase could create problems with future syncing of upstream code).

[Timur Sufiev (tsufiev-x)]

Setting to Won't Fix as we're not able to easily fix that on our own, w/o upstream support.