Floating IP address management

Partial fix for #54 (closed). Suggestion for reviewer, read it commit-by-commit.

• Introduces floating IP addresses view in Exosphere
  • Shows floating IPs and their status (assigned to an instance or not)
  • Shows floating IP address quota and utilization of same
  • Hides IPs assigned to instances by default, but allows user to choose to see them
  • Allows user to assign and unassign a floating IP to/from an instance (still slightly fraught, see post-merge checklist)

Working plan/todo

• Public/floating IP Addresses view
  • Show floating IP quota and usage
  • Show status
  • Show which instance an IP is assigned to
  • (IPs assigned to instance hidden by a "fold", by default?)
  • Ability to assign IP to an existing instance, sort of like the attach volume modal
  • Ability to un-assign IP from an instance, only if that instance has at least one other floating IP?
  • Ability to delete IPs
• Fix pluralization of "Floating IP Addresses"
• Factor out goToButton where it is used in other views
• Prevent user from trying to assign a floating IP to a server that already has a floating IP assigned
• Appease elm-analyse
• Consistent ordering of floating IPs in list view
• Rebase on master

How to Test

• Look at your floating IPs!
• Look at your floating IP quota
• Expand and contract the "already assigned to servers" fold
• Try to assign/unassign an IP to/from a server, though this will be fraught for now, see post-merge checklist

Screenshots

Post-Merge Checklist

• (#509 (closed)) Create issue: Exosphere automatically assigns floating IPs to existing servers after user un-assigns them

  • Our types and orchestration code have an embedded assumption, that any existing active server without a floating IP address needs a floating IP address. Exosphere will try to create/assign a floating IP address if a user removes it.
  • If we're letting people un-assign floating IPs from existing servers, this will work against the user's intention/expectation.
  • Exosphere should understand the difference between these circumstances:
    • New server is deploying and needs a floating IP assigned
    • Existing server which finished deploying doesn't have a floating IP, possibly because the user un-assigned it, and no action needs to be taken
  • ServerLaunchPriorFloatingIpState should probably become an exoOriginProp
  • Is a floating IP needed in order to complete the server deployment process? If so, we should prevent user from un-assigning the floating IP until deployment completes.
  • Re-introduce button to un-assign floating IP button in server detail view
  • See also #217 (closed), maybe both of these should be solved in one pass.

• (#510) Create issue: UI doesn't reflect state of waiting for floating IP to be assigned/unassigned

  • After user initiates a floating IP assign/unassign action, there is a delay in a floating IP actually getting assigned/unassigned to/from a server. In the meantime, the UI looks like nothing happened when the assign/unassign button was pressed.
  • This is a specific case of a more general problem where the OpenStack API sometimes takes a while to reflect the result of a user-requested asynchronous action. How should we model the circumstance where an action has been requested and is in progress? How should the UI reflect this circumstance?
  • We have had to solve this already (see server exoProps "deletionAttempted" and "targetOpenstackStatus"). Is there a better general solution that would apply both there and here?

• (#511 (closed)) Create issue: parallel data structure of floating IPs stored in server.osProps.serverDetails and project.floatingIps

  • UUID and status are not returned with IP address in server details from Nova, only floating IP details from Neutron, and we are using a single type (with two Maybe fields) to represent both of these things.
  • This complicates logic in various parts of the app and causes need for additional getter/setter functions
  • Possible solutions:
    • Don't use IP addresses returned in server details from Nova -- instead, only use ports and floatingIps returned from Neutron?
    • Use different types for IP address returned in server details from Nova, and IP address returned from Neutron list of floating IPs?