Floating IP assignment flexibility

When a user creates a new instance, by default, Exosphere will determine whether the instance gets a fixed IP address in publicly routable (non-RFC 1918) IPv4 space. Exosphere will only create/assign a floating IP address for the instance if its fixed IP is in private (RFC 1918) space. In the create server view, there is now an advanced option to override this behavior: the user can instruct Exosphere to create or not create a floating IP for that instance.

In other words, this fixes problems:

• Exosphere should not automatically assign a floating IP address to an instance when:
  • The user un-assigns the floating IP address from an existing instance (#509 (closed))
  • A new instance gets a fixed IP address in publicly routable (outside RFC 1918) space (#217 (closed))
  • A new instance was created with the user indicating that a floating IP address should not be created/assigned for/to it (#217 (closed))

Fixes #509 (closed) and #217 (closed).

How to Test

Create new instances with each different floating IP address creation option.

• On any cloud, the options to always and never create a floating IP address for a new instance work as expected.
• On a cloud where instances receive fixed IP addresses in IPv4 private (RFC 1918) address space (e.g. Jetstream), when creating a new instance with the default (automatic) floating IP creation option, Exosphere should assign a floating IP address to the instance.
• On a cloud where instances receive fixed IP addresses in IPv4 public (non-RFC 1918) address space (e.g. Nectar), when creating a new instance with the default (automatic) floating IP creation option, Exosphere should not assign a floating IP address to the instance.
  • When creating a new instance on Nectar cloud, use the "Classic provider" network (per these instructions)

Screenshots

In create server view:

Post-Merge Checklist

• #514 Create issue: first-class support for non-floating public IP addresses in server details view
  • if an instance has a fixed IP address in publicly routable (outside RFC 1918) space, then attempt to use/expose interactions (e.g. Guacamole-based interactions and native SSH) at this fixed IP address
  • server details view should display an instance's public (non-RFC 1918) IP address most prominently, regardless of whether that IP address is fixed or floating
• #515 Create issue: should FloatingIPCreationOption become a member of ExoOriginProps? It is only used/relevant for servers created by Exosphere.
• #516 (closed) Create issue: re-introduce button to unassign floating IP address in server details view
• #518 Create issue: clouds JSON configuration object could give deployer the option to specify how to deal with public IP addresses for new instances: whether a floating IP is required, optional, or even supported at all. This could determine how Exosphere exposes floating IP address-related actions throughout the app.

Working notes

Todo

• Our UI is conflating public and floating IP addresses. In the case of Nectar, non-floating (fixed) IPs are public, and in theory, a floating IP may be in private network space.
  • A modest solution is to just separate out the nomenclature for public IPs and floating IPs -- on some cloud providers these will be the same term, and in some it may differ.
• Use localized nomenclature for floating IPs
• Helpers.Helpers.ipv4AddressInRfc1918Space needs a better return type to represent possible states:
  • Input value is an IPv4 address and it is in RFC 1918 space
  • Input value is an IPv4 address and it is not in RFC 1918 space
  • Input value is not an IPv4 address (either IPv6 or mis-formatted)
• The code that serializes FloatingIpCreationOption to a string, and the code that attempts to turn the string back to the custom type, should be a matched pair of encoder/decoder helper functions

Design notes

Consider that soon (per #54 (closed)), user will also have option (disabled by default) to keep a floating IP address when the server is deleted.

• New advanced option in create server view:
  • "Create floating IP address?"
  • Help text: "In order to access your instance, a floating IP address is often needed, but some clouds do not require one."
  • Choices:
    • "Automatic" (default choice)
      • Help text: "Exosphere will try to detect whether the instance needs a floating IP in order to be accessed over the internet, and create one if needed."
    • "Yes"
      • Help text: "Exosphere will create a floating IP address and assign it to the new instance."
    • "No"
      • Help text: "Exosphere will not create a floating IP address for this instance."

Need to model: 1. user's choice of whether to create a floating IP address for a given new server, and if so, 2. whether Exosphere still needs to attempt to fulfill the user's choice (or has already done so).

• Should we persist this information to local storage?
  • Reasons to do it:
    • Ensures that Exosphere will behave correctly if the app is quit/closed during the server creation/provisioning process, and then later re-opened.
  • Reasons not to do it:
    • This would be the first time we persist any information about servers in local storage -- new territory.
• Should we persist this information to the server metadata?
  • Reasons to do it:
    • Ensures that Exosphere will behave correctly if the app is quit/closed during the server creation/provisioning process, and then later re-opened.
    • Doesn't require us to start persisting information about servers in local storage.
  • Reasons not to do it:
    • Consumes server metadata, which is a limited resource (with a quota) on some OpenStack clouds
    • More app logic depends on asynchronous API operations.

If we do not persist this information then worst case, a floating IP address doesn't get created for a new server, and a user can just create and assign one later. So, learning toward not persisting it, for simplicity's sake!