Hi Murali, I have an internal issue, 'Cannot add additional network range to NVP isolated network', meaning the user wants to expand a guest network. Is it an idea to integrate this question into your design? I realize that you are adressing the API mainly but the relation seems so close that I am bringing it up anyway.
regards, Daan Hoogland On Tue, May 28, 2013 at 3:56 PM, Murali Reddy <murali.re...@citrix.com>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. > > 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 > >
