cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daan Hoogland <daan.hoogl...@gmail.com>
Subject Re: [DISCUSS] portable IP vs public IP
Date Tue, 28 May 2013 14:26:39 GMT
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.Reddy@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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message