Add floating IP support when using Neutron

What does this PR do?

This PR adds support for allocating a Floating IP when using an OpenStack environment with Neutron. It also removes previous commented out commands for neutron anticipating this use case since the existing nova command will also work on a neutron environment as tested in this PR extensively. This PR also continues to work with a Nova Network environment that automatically assigns a public_ip to each instance.

How should this be manually tested?

Source the environment variables for an OpenStack deployment using Neutron and run any playbook that uses the openstack-create role.

Is there a relevant Issue open for this?

There are a few issues to be aware of that this PR attempts to address/mitigate when possible or document here. Issues detailed in this section.

Non-standard Neutron Deployment Configurations

Most Neutron deployments use a standard isolated private network for tenants which can attach to a public external network to use floating IPs to route traffic externally. By default instances are only assigned a private IP on the isolated network and a user will need to assign a floating IP.

Assigning a Floating IP for a Neutron Network is a two step process. First an IP must be allocated from the defined external floating network pool. Then this IP must be associated with the Nova ID of the instance. These actions can be completed by the user in most standard OpenStack deployments and should not need admin access. However, it is possible that different Neutron configurations may exist that may not work with the tasks added in this PR and will need to be added in future PRs. An example would be a Provider Network which allows tenants to attach instances directly to an external network that has a real physical gateway. The instances would get this IP assigned directly to them as a private IP, so there is no need for a floating (public) IP. The way the openstack-create role works right now cannot handle this use case as it expects a public IP. This should not be an issue in the current Neutron deployment in our lab but may need to be addressed in the future.

Floating IP Pool May Become Fully Allocated

Another use case that may not be addressed by this PR would be if the floating pool has been exhausted which may require the user to first free some up. This may occur as when these instances are deleted the floating IPs are unassociated but are not returned to the pool, they are still allocated to the tenant. This PR uses the auto_floating_ip option in the nova_compute Ansible module. This module allocates a new IP from the floating pool every time, it does not re-use allocated but available IPs. The terminate.yml playbook will address this in a future PR so when instances are deleted their associated floating IP will be unallocated to the tenant and returned to the pool. I have working code in progress to first check for allocated but available floating IPs instead of using the Ansible module to automatically create a new one each time. I will submit in a new PR when testing is complete, I removed it from this PR to speed up the acceptance of most standard use cases to move forward with testing on Neutron environments and not hold up this PR. To work around this issue if it occurs, simply delete any allocated but unassociated floating IPs manually.

Default floating IP pool

The OpenStack environment used will need to have the external network specified as the default floating pool in order for the nova_compute Ansible module to automatically create and assign a floating IP. This can be accomplished by either setting this value in /etc/nova/nova.conf to the external network and restarting OpenStack nova services on the controller, or the cloud operator can set or change the name of the external network to the one specified as the default floating pool. If using a PackStack deployment the default floating pool is called public.

The external network can be discovered with either nova or neutron commands as such:

$ nova floating-ip-pool-list
+----------+
| name     |
+----------+
| external |
+----------+

$ neutron net-external-list
+--------------------------------------+----------+---------------------------------------+
| id                                   | name     | subnets                               |
+--------------------------------------+----------+---------------------------------------+
| 747c2ce3-7209-4eab-a177-8541df4db97f | external | 00892630-42a5-496f-b5aa-af9f7be3cc32  |
+--------------------------------------+----------+---------------------------------------+

Once the external network is known it must be set any controllers in /etc/nova/nova.conf:

default_floating_pool=external

And services restarted:

openstack-service restart

As mentioned, I have in-progress code that uses neutron commands directly to determine the external network using the commands mentioned in this section and re-use any allocated but available IPs. However, I am currently blocked as this requires massive changes to the way our playbooks and roles refer to the existing nova_compute registered variable. In this case instead of using auto_floating_ip, the allocation and association are done post-creation. However, this means the public_ip variable is empty in the openstack_create.results data. The host groups will need to be created after this floating IP allocation and the other tasks will need to refer to the host group instead of openstack_create.results. I will continue to work on this and add a PR in the future once testing is complete and I discuss this with the team.

Who would you like to review this?

/cc @oybed @sabre1041 @etsauer

rhtconsulting / rhc-ose