On Tue, May 28, 2013 at 01:56:21PM +0000, Murali Reddy wrote: > 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.
+1 to this proposal (with one concern noted below). > > 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. Does it make sense to actually get the API for 4.2 to match this proposal? Once we release it, changing the meaning really means breaking the contract, right? > > [1]https://cwiki.apache.org/confluence/display/CLOUDSTACK/portable+public+I > P > [2]http://en.clouddesignpattern.org/index.php/CDP:Floating_IP_Pattern > >
