Auto-associate floating IP.
nova has a flag that indicates that each VM should automatically have a floating IP assigned and associated at the time of VM creation.
In quantum, the equivalent would be at port creation time. In Nova this is a system wide flag, but in quantum this woud likely be an option that is enabled per-network (i.e., for a particular network, it is automatically assigned a floating IP from external network X). this would map to a amazon VPC use case as well.
Blueprint information
- Status:
- Complete
- Approver:
- Kyle Mestery
- Priority:
- High
- Drafter:
- Salvatore Orlando
- Direction:
- Needs approval
- Assignee:
- Simeon Monov
- Definition:
- Obsolete
- Series goal:
- None
- Implementation:
-
Not started
- Milestone target:
-
next
- Started by
- Completed by
- Armando Migliaccio
Whiteboard
Nov-09-2015(armax): If someone is interested in pursuing it, this must be re-submitted according to guidelines defined in [1]
[1] http://
-----------------
10-July (mestery): Moving assignee to Simeon. Previous assignee had gone silent and wasn't responding to emails or IRC pings. Simeon will complete this one.
--- Update 2013-11-18 [salv-orlando]
Assigning High priority as it is a nova-parity feature Item
------
This is a nova-parity item, so I'm temporarily assigning it to H-3.
For quantum to auto assign the floatingip, we need auto create router too. So do we want to implement auto create router, add the router interface and then add router gateway?
Maybe make it simple, we can fail if there is not a router available for it.
danwent: yes, there are some fairly tricky checks here. First off, we would want to specify WHICH external network the floating ip should be allocated from. When this field would be set, we would want to make sure there is a router that connects that external network, to the internal network (or more likely, an internal subnet, which perhaps implies that this field should actually be associated with a subnet, not a network). Then, if a router interface or router gateway is deleted, we would have to reject this deletion with a 409 if there was an auto-floatingip policy that the deletion would violate.
Update 2013-03-10: I am happy to draft a spec for this. The design is probably a bit trickier than what it seems. The association should not really be between an internal network and external one, but between a subnet and an external network. In theory this could lead to auto association of multiple floating IPs (and I think this shouldn't be a problem).
I feel the auto-associate policy could be specified when a subnet is attached to a router. This operation (add-interface with auto-associate) could fail with 400 if the router has no gateway configured.
Once the design is discussed and approved I can do the implementation or leave it to someone from the community, if we find any taker.
Update by Steven Weston on 2013-11-13 -- Comments by Salvatore regarding implementation:
To quickly sum up the discussion around this blueprint, it could be implemented in two ways:
- providing automation in the neutron API (creating the floating IP together with the port)
- automating the operation on the orchestration side (nova-api in this case).
There are pro and cons in both solutions. In my humble opinion, the only thing I would care of is that the existing operation in the Neutron API stay "atomic" as they are.
Gerrit topic: https:/
Addressed by: https:/
Auto-associate floating IP
