In CloudStack, currently there are four distinct operations available with
public IP's at network service and manager layers.
1. Acquiring a public IP from zone level public IP pool
2. Associate acquired public IP with a guest network/VPC
3. Disassociate an associated public IP with a guest network/VPC
4. Release acquired public IP
But at API, #1, #2 are rolled in to 'associateIpAddress' so an acquired
public IP is always associated with a network. Similarly #3, #4 is rolled
into 'disassociateIpAddress' API. Operations #2, #3 are not exposed
through the API layer. So in effect,
- Public IP are always need to be associated with a network/VPC
- Network rules for LB/PF/NAT etc expects that public IP is already
associated with the network
- On network/VPC delete CloudStack implicitly releases acquired public
IP's by the user.
- There is no way to transfer association of a public IP from a guest
network/VPC to another guest network/VPC. This is commonly used pattern to
mask the failures in AWS [2].
As part of the portable IP feature [1], I have relaxed these
restriction for portable IP's. So an acquired portable IP need not be
associated with a guest network/VPC always and association can be
transferred across the networks. For e.g on acquired portable IP, when an
user enables static NAT for a portable IP to VM1 in network1, disables
static NAT to VM1 and then enables static NAT with VM2 in network2,
CloudStack will implicitly transfers the association of the portable IP
from network1 to network2.
What I want to bring to discussion is portability as characteristic of
public IP vs special pool of public IP's. I have made portable IP's to be
a region level resource, which enables portable IP's association be
transferable across the networks in different zones of a region. But
portability semantics can be implemented for zone level public IP as well,
with restriction that association can be transferred across guest networks
in same physical network of a zone. This seems to me an useful
functionality to have for zone level public IP. I have extended
'associateIpAddress' API to specify a boolean flag 'is_portable' that
indicates user is requesting a portable IP. In the current implementation
this flag is interpreted as request for allocating region level public IP
pool. If it make sense then I can relax this restriction with minimal
change to indicate 'is_portable' as portable characteristics of public IP.
So 'is_portable' flag can be used irrespective of region level or zone
level public IP. And then introduce another flag to 'associateIpAddress'
API, that explicitly requests that an IP from region level pool should be
allocated which by default can be moved across the networks from different
zones in that region.
Effort I am proposing is to get API semantics right with minimal changes.
I am not proposing to enable portability for zone level public Ip's for
4.2 but can be done for later release. Please comment.
[1]https://cwiki.apache.org/confluence/display/CLOUDSTACK/portable+public+I
P
[2]http://en.clouddesignpattern.org/index.php/CDP:Floating_IP_Pattern
