Floating addresses unnecessarily allocated to admin project

[Jesse Pretorius]

{"ostf_sha": "e33390c275e225d648b36997460dc29b1a3c20ae", "auth_required": true, "api": "1.0", "nailgun_sha": "67c4f1c18ab0833175f6dc7f0f9c49c3eb722287", "production": "docker", "fuelmain_sha": "63d0775708b0f5fa4d6d1e09a316d9c26f7e5444", "astute_sha": "b52910642d6de941444901b0f20e95ebbcb2b2e9", "feature_groups": ["experimental"], "release": "5.1", "fuellib_sha": "d699fc178559e98cfd7d53b58478b46553ffe39e"}

Environment:
 - Neutron with GRE
 - Ubuntu

Problem:
When building an environment it appears that there are Floating IP's associated with the admin tenant for no apparent reason. The number of IP's associated is equal to the number of nodes registered with the Fuel Master (not the number of nodes allocated to the environment) - in my environment it is 10.

This is a waste of IP addresses from the Floating IP Pool - these addresses should not be associated with the admin tenant.

[Sergey Vasilenko (xenolog)]

Floating IP allocation to the admin tenant was made only for demo purpose.
I suggest make checkpoint or field with count of auto-allocated IP addresses in UI.

[Jesse Pretorius (jesse-pretorius)]

The demo-related stuff (floating IP's, internal network, router, etc) should rather be deployed into a demo tenant, not an admin tenant. Pushing these into a demo tenant encourages bad behavior by users who aren't aware of how things should be deployed.

Just yesterday on IRC we were fielding questions from a user about why his instances weren't receiving DHCP addresses on the external network. He was building instances directly onto it, which is obviously not the correct behavior.

[Mike Scherbakov (mihgen)]

Is it still medium priority bug? Can you simply get these IPs back to pool for some other tenant to use?

[Sergey Vasilenko (xenolog)]

I think this bug has low priority.
This pre-allocated IPs can be easily returned to pool.

[Vladimir Kuklin (vkuklin)]

We do not allocate ip addresses since 6.0 anymore. This bug is invalid.