Use more descriptive names for networks in Neutron

[Mike Scherbakov]

After OpenStack deployment with Fuel, user sees net04 and net04_ext networks which he can use for VMs.
Names "net04", "net04_ext" are non-descriptive and new comers are not able to easy understand which network should be used.

For example, if user chooses net04_ext, then VM will not get IP address.

Let's come up with better naming. I can suggest the following:
tenant_with_dhcp - private tenant network with DHCP enabled.
external_no_dhcp - external network, no DHCP.

Marking this bug as High, as it affects UX and presence of Fuel & OpenStack significantly, and such easy items should be resolved quickly to ensure easy of use.

[Timur Nurlygayanov (tnurlygayanov)]

I suggest to use the following nemes:
private_with_dhcp - private tenant network with DHCP enabled.
external_no_dhcp - external network, no DHCP.

[Andrey Danin (gcon-monolake)]

net04 is a default private network for Admin tenant. So, I think, it should be private_admin_tenant_net.
net04_ext should be external_network. I don't think someone want to run Neutron-DHCP in any external network, so it's not necessary to add 'no_dhcp' mark to the network name.

[Mike Scherbakov (mihgen)]

This bug also impacts documentation. Please don't forget to change it with the bug fix.

[Sergey Vasilenko (xenolog)]

While implementing this we should take into consideration following reasons:
* we plan separate external and floating networks
* we plan support multiple floating networks
* in the future Neutron may will support IPv6

[Mike Scherbakov (mihgen)]

This is NOT a Wishlist. I've seen people complaining about it.
This bug was High initially, please see what is in description:

Marking this bug as High, as it affects UX and presence of Fuel & OpenStack significantly, and such easy items should be resolved quickly to ensure easy of use.

It still affects all newbies. We are making a tool with the mission to give an ability to deploy openstack even for a kid.

[Mike Scherbakov (mihgen)]

Bumped to high as it affects UX. We need to push this to 8.0 though as we passed FF and it seems like too invasive change now.

[Andrey Maximov (maximov)]

Fuel defines the names of networks and pass them to puppet-neutron as input parameters, so the fix should be implemented on fuel side.

[Sergey Vasilenko (xenolog)]

This bug will be automatically fixed after implementing https://blueprints.launchpad.net/fuel/+spec/combine-tun-and-vlan-cases

[Matthew Mosesohn (raytrac3r)]

FYI there are hardcoded references to net04 in fuel-web, fuel-library, fuel-ostf, and fuel-qa. It's going to be tricky to rename it just because it will need coordination.

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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

[Matthew Mosesohn (raytrac3r)]

This will not be backported to 7.0. It's a major change.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/228514
Committed: https://git.openstack.org/cgit/stackforge/fuel-library/commit/?id=7707739ec815c71e4e818f4c01d9b848022a5558
Submitter: Jenkins
Branch: master

commit 7707739ec815c71e4e818f4c01d9b848022a5558
Author: Matthew Mosesohn <email address hidden>
Date: Mon Sep 28 18:53:52 2015 +0300

    Allow default neutron names to be configured

    Neutron resources net04, net04_ext, and router04
    are now defined in hiera in neutron_config with
    the following keys, respectively:
      default_private_net
      default_floating_net
      default_router

    In the absence of hiera config, they will be defined
    as their default names, as mentioned above.

    Change-Id: I466fd09296e952259b36488fe861bf72d00b6587
    Partial-Bug: #1349702

[OpenStack Infra (hudson-openstack)]

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

[Matthew Mosesohn (raytrac3r)]

Fuel Library part done, QA and OSTF parts are pending nailgun changes so the correct values can be set/looked up. Passing to Igor Kalnitsky who will take care of nailgun part.

Pending reviews:
https://review.openstack.org/238474
https://review.openstack.org/#/c/228552/

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/240264
Committed: https://git.openstack.org/cgit/openstack/fuel-qa/commit/?id=c1ab3a2d0bc4c06225742f02e9840f0ca7a61f87
Submitter: Jenkins
Branch: master

commit c1ab3a2d0bc4c06225742f02e9840f0ca7a61f87
Author: Tatyana Leontovich <email address hidden>
Date: Thu Oct 29 17:11:42 2015 +0200

    Get predifened net name from nailgun

    Neutron predefined network names
    like net04 and net04_ext can be modified,
    so we need get such data from nailgun

    Change-Id: Ia23ea08303d08abc9bcc31a7749ad23b34755997
    Partial-Bug: #1349702

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/228552
Committed: https://git.openstack.org/cgit/openstack/fuel-ostf/commit/?id=25c87380395f2e42ca01ea6357b72d4407ff4201
Submitter: Jenkins
Branch: master

commit 25c87380395f2e42ca01ea6357b72d4407ff4201
Author: Matthew Mosesohn <email address hidden>
Date: Mon Sep 28 20:49:21 2015 +0300

    Allow custom private network name

    Private network name "net04" should now use
    customizable value configured in nailgun.
    If this value is not present in nailgun, it
    defaults back to "net04".

    Change-Id: I66b7cde820c114b9c447fc4c169a51d3a63d0bea
    Partial-Bug: #1349702

[OpenStack Infra (hudson-openstack)]

Change abandoned by Matthew Mosesohn (<email address hidden>) on branch: master
Review: https://review.openstack.org/238474
Reason: already implemented by Tatyana Leontovich

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/238630
Committed: https://git.openstack.org/cgit/openstack/fuel-web/commit/?id=8b07f46ab6b2f03a997be83b5af2de6dbaebd9ec
Submitter: Jenkins
Branch: master

commit 8b07f46ab6b2f03a997be83b5af2de6dbaebd9ec
Author: Igor Kalnitsky <email address hidden>
Date: Thu Oct 22 14:50:59 2015 +0300

    Neutron: add internal & floating names to params

    In order to remove internal and floating network names hardcoding from
    Nailgun database, let's move them to neutron parameters. It'll simplify
    support for developers, and allow user to change them as they want.

    Change-Id: Ic0ca82047cb750609a5313c2eab02569b9633239
    Partial-Bug: #1349702

[Dmitry Pyzhov (dpyzhov)]

We agreed that bug scope is implemented. There is no need to allow user to change network names on UI.

[Mike Scherbakov (mihgen)]

> We agreed that bug scope is implemented. There is no need to allow user to change network names on UI.
Why so.. ?

Please see my original request in description:
> Let's come up with better naming. I can suggest the following:
> tenant_with_dhcp - private tenant network with DHCP enabled.
> external_no_dhcp - external network, no DHCP.

It would be ideal if user can define name in the UI which he/she likes better, but I'm fine if we just rename..

[Dmitriy Novakovskiy (dnovakovskiy)]

I think the UX here should be the following:
- On Networking step of deployment wizard user is prompted to enter network names:
-- "Please enter the name for default Tenant network. It will have DHCP service active, you will be attaching your VMs to this network by default"
-- "Please enter the name for default External network. Please don't attach VMs to it - it should be used for Floating IP allocation only"
-- some links to documentation discussing Floating IPs and tenant networks in details

In such way we'll have our yet-not-very-experienced user properly informed and guided.

Default names for networks (in text boxes for user's input or if we decide not to provide flexibility described above):
- net04 => network_for_vms_dhcp_on
- net04_ext => network_for_floating_ip

[Mike Scherbakov (mihgen)]

Thanks Dmitry. I would be fine if we just provide options in settings tab to start, as it would be simplest solution.

We just need to estimate how much would take to do just a settings tab options, and how much it would take for Dmitry's proposal. As we don't have either option implemented, I'm reopening this issue...

[Sheena Conant (sheena-conant)]

I'm not terribly familiar with Networking options, but it seems like if we were to just introduce intuitive names that would be sufficient (and prevent the users from specifying something nonsensical). Also, we've been discussing in Fuel UI team for a couple of releases the addition of in-line contextual documentation. This seems like a prime example of where in-line documentation would provide a lot of value - I will try to prioritize this work for Mitaka/9.0.

[Ihor Kalnytskyi (ikalnytskyi)]

Mike, Dima, Sheena,

I'm not sure whether you understand what's done in scope of this bug or not, but let me explain a bit.

Previously we had hardcoded net04 and net04_ext everywhere. It was hardcoded in Nailgun, it was hardcoded in puppet manifests, it was hardcoded in OSTF, it was hardcoded in system tests and so on. So even simple renaming was painful, since it was required to do renaming across several projects.. and merge patches at one time.

So we've decided to remove this hardcoded, and currently there's only one source of truth - Nailgun. Both library, OSTF and system tests retrieve names from Nailgun. So that's better, isn't it?

From Nailgun POV, it's not hardcoded anymore either. Each cluster stores these names in neutron_config settings, so different cluster may have different names. So what we need to do now is to show these fields on UI somehow. If so, I believe the bug should be assigned to Fuel UI team and the 'tricky' tag must be removed.

[Matthew Mosesohn (raytrac3r)]

+1 to UI team
-1 to removing tricky. It reflects the amount of effort that went into this bug. It's not a trivial "replace 1 string in 1 file" fix, but one that required a significant amount of work.

[Mike Scherbakov (mihgen)]

Igor,
I'm just saying that original scope is not complete. That's why I reopened this issue. I understand that now it is just UI part, but we need to complete it.

[Vitaly Kramskikh (vkramskikh)]

I still don't understand what is expected from us. Why don't you use our usual mechanism of cluster attributes defined in openstack.yaml?

[Ihor Kalnytskyi (ikalnytskyi)]

Vitaly,

Unfortunately Nailgun's network code base looks like spaghetti, and I don't want to make pasta. :) So these new fields (internal_name and floating_name) were introduced near settings they are belonged to:

  https://github.com/openstack/fuel-web/blob/89ef1c52e7d1626b4534e5c869b2e44e4d4a47af/nailgun/nailgun/fixtures/openstack.yaml#L443-L470

Moreover, these setting are neutron only and shouldn't be shown for nova_network. While nova_network is going to be removed and we're able to hide settings based on network provider, I still think it's not ok to put network settings in different places. So that's why they are there.

So could you please, Vitaly, show them on Network tab near the related settings?

[Vitaly Kramskikh (vkramskikh)]

Igor,

How are the new fields different from these:

https://github.com/openstack/fuel-web/blob/89ef1c52e7d1626b4534e5c869b2e44e4d4a47af/nailgun/nailgun/fixtures/openstack.yaml#L897-L944

And how will changing the path turn nailgun code into pasta? I don't really understand. But handling this fields in UI the way they are implemented will add more hardcode to the UI code.

> Moreover, these setting are neutron only and shouldn't be shown for nova_network
Naturally solved with our restriction mechanism. With the current approach we should hardcode this condition in UI.

> While nova_network is going to be removed and we're able to hide settings based on network provider, I still think it's not ok to put network settings in different places
We already have lots of network settings in the cluster attributes - though they are currently shown on the network tab. If you don't understand what I'm talking about, please check out the latest master - in the last few days there were significant changes to the network and settings tab, and all the network-related settings are moved to the network tab.

> So could you please, Vitaly, show them on Network tab near the related settings?
Where exactly? In Neutron L2 or Neutron L3. If it's the new group, what's its name? How these should these fields should be validated?
With the current approach, we need to get answer to these questions and add some hardcode to the UI. If we use our common settings format, we can describe answers to all these questions declaratively.

I think since we implemented segmentation of the settings tab, we should discourage extending networking_parameters and eventually move everything from networking_parameters to the attributes.

If you still don't understand what I'm talking about, please check our the latest Fuel UI in fake mode.

[Ihor Kalnytskyi (ikalnytskyi)]

Vitaly,

> How are the new fields different from these: ...

Please read my comment above. I said how they are differ: they are directly related to the settings in neutron_config dict. It'd be super strange to setup internal and external networks in different places at once. DVR or L2 are kind separated things, while we have internal and external network setup on Network tab. If we want to have good UX, we have to put names for these networks in the same section where the networks are setup (Network tab, where the CIDR/ranges are configures for those networks).

> We already have lots of network settings in the cluster attributes

And that's not good that we have network settings in different places. They should be at one place, not everywhere in the code.

> please check out the latest master - in the last few days there were significant changes to the network and settings tab

1. Few days? These names have became a part of neutron_config few weeks ago. So you even doesn't have possibility to

2. Anyway, we shouldn't design backend keeping in mind that Web UI is only consumer. And again, the network names have been put to neutron_config, because neutron_config has other *network* stuff like cidr/ranges/etc.

[Vitaly Kramskikh (vkramskikh)]

> If we want to have good UX, we have to put names for these networks in the same section where the networks are setup (Network tab, where the CIDR/ranges are configures for those networks).
Ok, so it's Neutron L2 configuration. Please provide me with validation rules - what is the max length and allowed symbols.

> And that's not good that we have network settings in different places. They should be at one place, not everywhere in the code.
Agreed, but at least it's a good start - before we had network configuration field on both network and settings tab. What do you think of the idea which I said above - get rid of neutron_config at all and move everything from there to cluster attributes? Not now and immediately, but I think that's what we should eventually achieve.

> And again, the network names have been put to neutron_config, because neutron_config has other *network* stuff like cidr/ranges/etc.
We already have Guest OS DNS settings in networking_parameters, and Host OS DNS in the cluster attributes. What do you think about it?

> Anyway, we shouldn't design backend keeping in mind that Web UI is only consumer.
That's true, but what you ask me to do contradicts with this statement - instead of describing labels, locationg, validation info declaratively in our usual format so that any other client can consume and handle this info you want me to hardcode it Fuel UI.

So please provide me with the validation info and I'll make the change on the current backend. But please answer the questions and tell me what you think.

[Mike Scherbakov (mihgen)]

Vitaly - could you please engage with Sergey Vasilenko / Stas Makar / Alexey Kasatkin on questions above... ?

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/250392
Committed: https://git.openstack.org/cgit/openstack/fuel-web/commit/?id=0c0337cb08b34e84fe6f6e36e88bbbf19be2cf0b
Submitter: Jenkins
Branch: master

commit 0c0337cb08b34e84fe6f6e36e88bbbf19be2cf0b
Author: Alexandra Morozova <email address hidden>
Date: Thu Nov 26 14:54:51 2015 +0100

    Showing Internal and Floating name on Networks tab

    Closes-bug: #1349702
    Change-Id: I6881cdb5d86eedb6efe600e11104efa0319b567e

[Nastya Urlapova (aurlapova)]

@Timur, as usual we add Fuel version that was used for verification.

[Tatyanka (tatyana-leontovich)]

VERSION:
  feature_groups:
    - mirantis
  production: "docker"
  release: "8.0"
  api: "1.0"
  build_number: "466"
  build_id: "466"
  fuel-nailgun_sha: "f81311bbd6fee2665e3f96dcac55f72889b2f38c"
  python-fuelclient_sha: "4f234669cfe88a9406f4e438b1e1f74f1ef484a5"
  fuel-agent_sha: "6823f1d4005a634b8436109ab741a2194e2d32e0"
  fuel-nailgun-agent_sha: "b2bb466fd5bd92da614cdbd819d6999c510ebfb1"
  astute_sha: "b81577a5b7857c4be8748492bae1dec2fa89b446"
  fuel-library_sha: "fe03d887361eb80232e9914eae5b8d54304df781"
  fuel-ostf_sha: "ab5fd151fc6c1aa0b35bc2023631b1f4836ecd61"
  fuel-mirror_sha: "b62f3cce5321fd570c6589bc2684eab994c3f3f2"
  fuelmenu_sha: "fac143f4dfa75785758e72afbdc029693e94ff2b"
  shotgun_sha: "63645dea384a37dde5c01d4f8905566978e5d906"
  network-checker_sha: "9f0ba4577915ce1e77f5dc9c639a5ef66ca45896"
  fuel-upgrade_sha: "616a7490ec7199f69759e97e42f9b97dfc87e85b"
  fuelmain_sha: "727f7076f04cb0caccc9f305b149a2b5b5c2af3a"