The connection between floating and public networks is unclear in UI

[Andrew Woodward]

Neutron floating IP range was located with the Public network in 6.1 and 7.0. for 8.0 It's with the "Neutron L3 Configuration". Because the Neutron floating range must be a sub-section of the Public Network but not overlap with the range used for nodes, it must be located close enough to be read on a reasonable sized screen with out scrolling.

[Aleksey Kasatkin (alekseyk-ru)]

AFAIC, with node groups in UI it is more relevant to separate Public and Floating as Floating ranges are related to just one of existing Public networks in this case. Moreover, it is incorrect to show Floating range as wrong for all Public networks (i.e., for every node groups).

[Andrew Woodward (xarses)]

Its a UX issue, it was moved close together due to numerous complaints from users about that not understood relationship between the two and the separation in the config.

You are correct. It doesn't belong inside the public network range. But it must be visible in the same screen page and it's relation needs to be identified

[Sergey Vasilenko (xenolog)]

We are going to separate Public and Floating networks.
Also this will provide ability to have multiple separated floating networks (L2 segments + subnets).

Floating range into Public network will be hinder of planned fature.

[Vitaly Kramskikh (vkramskikh)]

Andrew, with multirack what you want to do is just invalid. If you insist, feel free to file a bug "users do not understood relationship between the floating and public networks" - we'll try to find out why is it so and come up with another solution rather than moving floating IP range into public network, which is not possible anymore since we support multirack

[Andrew Woodward (xarses)]

@Sergey, untill the relationship is gone, this is valid

@Vitaly It doesn't have to be inside it as it was before.

As long as the relationship between Public Network, and the range, and the validation between the two exists, the data must be presented in such a way that 1) the relationship is understood 2)That in the UI the settings are near enough to each other that a user with an average screen can make edits to the related fields with out scrolling to know what the values of the other fields that this is dependent on are, so they don't have to scroll constantly

[Aleksey Kasatkin (alekseyk-ru)]

Probably, add some hint near Public network and near Floating ranges. But when network template is loaded we could have no Public network (such network can have different name) so it will be incorrect. It is another story to sync template with UI.

Maybe, add some quick link from Public network to Floating also. It is harder to implement such quick link in opposite direction as Floating can point to arbitrary Public network or do not point to it at all. I'm not sure such links is a very good idea. Need to ask Vitaly.

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/255170
Committed: https://git.openstack.org/cgit/openstack/fuel-web/commit/?id=2c90987b8b2b9b74087534512b7f9e962fffd264
Submitter: Jenkins
Branch: master

commit 2c90987b8b2b9b74087534512b7f9e962fffd264
Author: Julia Aranovich <email address hidden>
Date: Wed Dec 9 12:56:13 2015 +0300

    Improve floating ranges validation

    Closes-Bug: #1518435

    Change-Id: I694b8255cb15db75f292099806974a5f374b7868

[Anastasia Palkina (apalkina)]

Verified on ISO #303

VERSION:
  feature_groups:
    - mirantis
  production: "docker"
  release: "8.0"
  api: "1.0"
  build_number: "303"
  build_id: "303"
  fuel-nailgun_sha: "352548386007399a95a6f21b1fcd9c48a0726325"
  python-fuelclient_sha: "b2bbcdf1c0f38adb34cff01cb6040006911f2ea5"
  fuel-agent_sha: "49bb78675b749d15ae8f0f045dc2b0811777a9d6"
  fuel-nailgun-agent_sha: "a33a58d378c117c0f509b0e7badc6f0910364154"
  astute_sha: "c56dfde2da034151a7e707b381c4cf9d213b4ba2"
  fuel-library_sha: "14576a3dbb3be5e4013c306776dc2eaefe0c15e0"
  fuel-ostf_sha: "9910a4726cbd038c257582b429527e40c4c3cb20"
  fuel-mirror_sha: "dbbe9ddc2c8a336aa7ab62952761bd079e374d1d"
  fuelmenu_sha: "680b720291ff577f4c058cee25f85e563c96312e"
  shotgun_sha: "cacb93cbc28910ff0dc38f30a855efa9af50d8ce"
  network-checker_sha: "d443ef47abeda58d319bc8d33d5005dd09440a02"
  fuel-upgrade_sha: "1e894e26d4e1423a9b0d66abd6a79505f4175ff6"
  fuelmain_sha: "74e9affd54e5a31fd55ed75a3402940dd186a621"

[Randeep Jalli (jallirs)]

These are :
1. the astute.yaml I used to deploy as generated by the fuelmenu.
2. /etc/nailgun/settings.yaml before i had to make any changes to it and reboot the server.
3. The bootstrap_admin_node.sh output
4. The nailgun output where i tried to run nailgund from command line and it failed with:

2016-03-23 16:59:01.848 DEBUG [7f54cf0c5740] (settings) Trying to read config file /etc/nailgun/settings.yaml
2016-03-23 16:59:02.252 INFO [7f54cf0c5740] (app) Fuel version: {'release': '9.0', 'api': '1', 'openstack_version': 'liberty-9.0', 'feature_groups': [['advanced', 'true']]}
Traceback (most recent call last):
  File "/bin/nailgund", line 9, in <module>
    load_entry_point('nailgun==9.0.0', 'console_scripts', 'nailgund')()
  File "/usr/lib/python2.7/site-packages/nailgun/app.py", line 95, in appstart
    run_server(build_middleware(build_app().wsgifunc),
  File "/usr/lib/python2.7/site-packages/nailgun/app.py", line 42, in build_app
    app = web.application(urls(), locals(),
  File "/usr/lib/python2.7/site-packages/nailgun/urls.py", line 25, in urls
    "/api/v1", api_urls.app(),
  File "/usr/lib/python2.7/site-packages/nailgun/api/v1/urls.py", line 400, in app
    return web.application(*get_all_urls())
  File "/usr/lib/python2.7/site-packages/nailgun/api/v1/urls.py", line 390, in get_all_urls
    all_urls.extend(get_feature_groups_urls())
  File "/usr/lib/python2.7/site-packages/nailgun/api/v1/urls.py", line 382, in get_feature_groups_urls
    feature_groups_urls.get(feature, [])])
TypeError: unhashable type: 'list'

[Randeep Jalli (jallirs)]

Wrong post... sorry