cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manan Shah <>
Subject Re: [PROPOSAL] EIP across zones
Date Wed, 20 Mar 2013 21:40:15 GMT
Thanks Murali for the FS. Below are some questions/comments.

1. Is there a reason why we wouldn't support this feature for VPC?
2. Your FS talks about supporting EIP for Shared Networks as well. Are you
going to support that? If so, are you going to support it only when NS is
enabled as a LB service provider?
3. On Stopping a VM in basic zone today, CS does not detach the EIP from
the VM. I believe the functionality should be consistent with the current
support as well as consistent across Basic and Advanced Zones
4. In Advanced Zone Network with EIP service, I am assuming you will not
allocate a Public IP for every guest VM. Your FS talks about Advanced Zone
behaving exactly like Basic Zone. That's why I am asking.
5. Currently, we support EIP in Basic Zone. For basic zone users, it might
get confusing that there are two ways to do EIP in Basic Zone.

Manan Shah

On 3/19/13 2:23 AM, "Murali Reddy" <> wrote:

>On 19/03/13 4:08 AM, "Chiradeep Vittal" <>
>>Thanks for this. I'd like to note that there is no evidence that AWS
>>maintains a separate pool of "Elastic Public IP" and "Ephemeral Public
>>IP". If we drop this phantom construct, then the feature is greatly
>> - there are not 2 workflows to acquire a persistent public ip
>> - there are no additional APIs
>> - the only thing that needs to be done is to move the public ip resource
>>to the region level from the zone level
>Chiradeep, thanks for your feedback. I agree to that fact that there is no
>evidence that AWS maintains a separate pool of "Elastic Public IP" and
>"Ephemeral Public IP". I don't have operational insights of datacenter
>network infra, I would imagine data centre edge routers will advertise
>subnets typically. It does not seem trivial to move a public IP across
>data centres, hence the 'phantom construct' :)
>Can you please elaborate what you meant by "move the public ip resource to
>the region level from the zone level"? Are you suggesting that public IP
>that are configured at zone level today to be a resource at region level?
>which means that current deployments with more than one datacenter with
>their respective public IP address pool per zone will be migrated to a
>single public IP address pool at region level? If region level public IP
>pool/subnet is allocated to instances across multiple zones, the IP
>address allocation is scattered then how does routing will work? If
>CloudStack just assumes that public IP (non RFC 1918) can be
>moved/allocated across the zones, then (irrespective of EIP service is
>enabled or not) we have can public IP pools configured at region level.
>But question is, is it a fair assumption?
>>On 3/17/13 10:31 PM, "Murali Reddy" <> wrote:
>>>I would like to propose enhancing current EIP functionality (currently
>>>available in basic zone). I have made a case for this feature earlier
>>>and captured requirements in the feature bug [2]. This proposal would
>>>like to introduce following functionality.
>>>  1.  EIP service with in 'advanced' zone where acquired zone level
>>>public IP can be 'static nat' to any instance account owns in that zone.
>>>  2.  to introduce a new category of public IP called 'EIP' that are
>>>provisioned by admin at region level and are available for user
>>>  3.  to provide EIP service across zones (both basic and advanced)
>>>acquired region level public IP can be 'static nat' to any instance an
>>>account owns in that region.
>>>I would like to seek the feedback on the functional requirements and
>>>design. FS is available at [3].

View raw message