Add floating IP allocation and auto-association in launch instance form
= Introduction =
Allocating then associating a floating IP to an instance is a common use case. For the moment, the workflow for this use case is broken into several pieces:
* "Access & Security" page > "Floating IP" tab > Allocate IP,
* "Launch Instance" modal
* "Instances" page > More > Associate a floating IP
In the "launch instance" form a user wants a straightforward way:
* to allocate a new floating IP
* to automatically attach a floating IP of his choice after a successful instance launch
= User interface proposal =
In the "Launch Instance" form, in the "Network" tab, there is:
* a dropdown with several choices:
** "do not attach a floating IP" (default choice)
** several floating IPs (already allocated and NOT attached)
* a "+" button to allocate a new one that open the "Allocate Floating IP" existing form.
This UI proposed is similar to "create keypair / choose keypair" look & feel in the "Access & Security" tab of the launch instance form.
Blueprint information
- Status:
- Complete
- Approver:
- David Lyle
- Priority:
- High
- Drafter:
- Cédric Soulas
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Obsolete
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
- Rob Cresswell
Related branches
Related bugs
Sprints
Whiteboard
Gerrit topic: https:/
Addressed by: https:/
Attach a floating ip to an created instance
doug-fish: This looks like a nice conept. I'd think the entire panel should be hidden if the user doesn't have access to associate a floating ip -- and I see the code already handles this. LGTM!
asahlin: I 2nd the motion. It is a usability improvement to be able to allocate & associate a FIP, when launching an instance (all logically combined on 1 panel) vs navigating through the ui in multiple spots/ steps.
amotoki (Nov 26, 2014): The proposal itself is nice and I believe it is a good direction. When considering Neutron network, the situation is not so simple and there are several things to be considered. (1) Floating IP can be associated only with a port which is reachable from a router connected to an external network, so a floating IP specified cannot always be associated with a port of a launched instance. (2) In Neutron network an instance can be connected to multiple networks, so we need a way to specify which network a specified floating IP is associated to. (3) Floating IP association can fail. We need a way to report floating IP association failure appropriately. Could you share your thought?
tsufiev (Nov 26, 2014): I agree that the UI improvement is really, really good. But also would second amotoki concerns, especially (3): do Neutron/Nova have some locking mechanism for floating ips? Otherwise userA may end up selecting an IP which would be stolen by userB while userA's VM is being built.
amotoki (Dec 4, 2014)
@tsuflev: Regarding "locking mechanism for floating ips", when neutron is used, Neutron
manages floating IPs and nova acts as just a proxy to neutron, so we don't need to care
a floating IP is stolen by another user.
My point of (3) is just I want to see a separate error message for floating IP association failure
from VM launch failure. By this proposal "launch instance" now will be a non-atomic operation
which consists of multiple operations (boot an instance, allocate an floating IP and associate
floating IP with the new instance). This means we need a good error message and good rolling
back mechanism in the implementation.
peristeri (Nov 26, 2014): @amotoki For (1) I see your point here. I'm guessing the selection to which network to connect should be first available network instead of the order of the network. For (2) I'm proposing a separate drop field called "assigned floating ip" (3) If the instance creation fails, the cleanup should be neutron.
amotoki (Dec 4, 2014)
@peristeri I am not sure I understand your description correctly.
For (1), I don't think the first available network is a good candidate for floating IP.
Instead, IMHO, as a bottom line, the first *selected* network should be used.
Otherwise Floating IP association completely has no meaning and it may be confusing.
Ideally a floating IP should be associated to a port on a specified selected network (of course).
This is the main reason that we don't have auto FIP association for Neutron.
For (2), I am not sure what "separate drop field" means. Where will this field be displayed?
In addition "assigned floating IP" seems a bit odd because floating IP is not associated with
an instance when "Launch Instance" form is displayed.
For (3), my point is how an error message is displayed and how a rollback is handled.
If a floating IP association failed, is the related instance deleted, or is an instance without
FIP created?
peristeri (Dec 5, 2014)
@amotoki Sorry for the poor description. In short (1) Select the first network that has an interface to the public network. (2) It might be a bad idea to add a separate drop section for networks to attach a floating ip. (3) I propose creating the instance but pop a warning that the instance is not connected to a public network.
tsufiev (Nov 27, 2014) I have an additional proposal regarding @amotoki (1): enable floating IP selection just after the network for instance has been selected and dynamically filter only those floating IPs that are reachable from the selected network. I know that it would make the implementation more difficult, but in terms of UX this approach seems more reasonable to me.
amotoki (Dec 4, 2014) -- I replied inline to related comments above. Please find them.
