Swamy, please see inline comments On 16/10/12 2:19 PM, "Venkata SwamyBabu Budumuru" <venkataswamybabu.budum...@citrix.com> wrote:
>Hi Murali, > >First of all spec is crystal clear and has all the details about what you >are planning to do. > >I have the following few queries after reviewing your FS. > >(1) Is this enhancement made for enterprise clouds? because, I don't see >a reason why on public clouds, tenant doesn't want public access while >using EIP & ELB offering. No assumptions made on enterprise cloud or public cloud for this enhancement. This is just a mechanism to provide the flexibility to cloud deployer. If a tenant want's public access to his VM's, he can still acquire a public IP and can establish 1:1 NAT. > >(2) As per my understanding, opting for EIP/ELB is possible only at the >time of zone creation which is in the hands of cloud admin who opts for >this option only after deciding whether he want to conserve public IPs or >not? > >Rather, Isn't it a good idea to provide the flexibility of associate or >disassociate IP to the end user ? I mean how about adding logic to >associate and disassociate (including the one with is_system=1) along >with the above >mentioned behavior? IIUIC, your concern is user should still have the ability to acquire and release public IP's in the basic zone? I am not changing this semantics, user can still acquire a public IP and assign or re-assign the public IP to any of the VM's he owns. > >(3) After zone creation, if admin wants to move from an offering that has >eip_associate_public_ip=1 to eip_associate_public_ip=0 or vice versa then >do we have that option? No. Updating the network from offering with 'AssociatePublicIP' capability to different offering without AssociatePublicIP is not permitted. I will call that out in the specification. > >(4) how about masking this option (associatePubIP) OFF for Isolated by >default in UI Sure. Option to set 'associatePubIP' should only be seen in the UI only for guest traffic type 'shared'. >(5) As per my understanding, we don't have any impact on ec2 API calls >due to this change. correct me if you see anything. In general EC2 api calls should not be impacted. Not sure if it will break any EC2 API integration due to EIP semantics change. Can anyone comment on EC2 API use on basic zone with EIP service, are there any assumption made that VM gets the public IP by default? > >Thanks, >SWAMY > >-----Original Message----- >From: Murali Reddy [mailto:murali.re...@citrix.com] >Sent: Tuesday, October 16, 2012 1:48 PM >To: cloudstack-dev@incubator.apache.org >Subject: [4.1 feature RFC] Optional Public IP assignment for EIP with >Basic Zone > >I am trying to change EIP semantics supported by CloudStack for 4.1 >release. Today if some one deploys a basic zone with EIP service, then by >default a public IP is allocated for the user VM along with private IP, >and then a 1:1 NAT is established between the public IP and private IP of >the user VM. In a deployment where public IP's are scarce this result in >wastage of public IP. I am changing CloudStack behaviour so that cloud >admin has the flexibility to enable or disable default public IP >allocation for the user VM's in the basic zone with EIP service. I >opened enhancement request [1] and the functional requirements are >detailed at [2] please comment. > >[1] https://issues.apache.org/jira/browse/CLOUDSTACK-265 >[2] >https://cwiki.apache.org/confluence/display/CLOUDSTACK/Optional+Public+IP+ >assignment+for+EIP+with+Basic+Zone > >
