Hi Manan, My comments inline.
Thanks, Saksham -----Original Message----- From: Manan Shah [mailto:manan.s...@citrix.com] Sent: Thursday, January 24, 2013 5:50 AM To: cloudstack-dev@incubator.apache.org Subject: Re: [DISCUSS] IP Address Reservation within a network Hi Saksham, Few additional comments. 1. Can you please update the FS to identify if this would be supported for Isolated, VPC as well as Shared networks or not [Saksham]: For isolated networks and VPC this feature will be supported. Shared Networks have implicit reservation already built in by specifying the start ip and end ip. Unlike isolated networks for which CloudStack designs (create CIDR, net mask, gateway etc), shared networks are admin designed and implemented. So shared networks are not supported. 2. Not sure if I completely understand your update Network. What happens if the user provides the GuestVMCIDR and there are some IP Addresses outside of that which are already allocated to Guest VMs? What will happen in that case? Shouldn't we just reject the updateNetwork call in that case? [Saksham]: The proposed work flow would be: 1) When the Update Network API is called with a valid GuestVmCIDR, but there are some IP Addresses outside of that range which are already allocated to Guest VMs, the API fails with error message informing about already running VMs outside the range, and asking for shutdown. 2) So further shutdown of all the VMs could be done by the admin. 3) The Update Network API will be called again, a Boolean flag will confirm his choice about re-implementation and finally the network will be re-implemented with reservation. 4) The VMs eventually, will acquire new IPs in the GuestVmCIDR. The workflow will be quite identical to upgrade Network offering case in updateNetwork API, when the network is upgraded to a network offering using external device, causing a change in Guest CIDR. 3. If a network offering is upgraded to have external devices, what happens to the GuestVM CIDR that the user might have provided prior to the upgrade? Its not very clear what would happen in that case. [Saksham]: When such upgrade happens the following things occur: 1) The network is re-implemented and Guest CIDR itself changes from say 10.1.1.0/24 to 10.1.2.0/20. The VMs will acquire new IPs in the new network. 2) Since the Guest VM CIDR was a subset of 10.1.1.0/24 so now it becomes invalid. 3) The user can now apply reservation again in this new network 10.1.2.0/20 4) Also an alert message would make the user realize that he has to reconfigure his physical machines in the new network space after the reservation is done. Can you please update the FS with these details? Yes, I am working towards it. Regards, Manan Shah On 1/22/13 2:23 AM, "Saksham Srivastava" <saksham.srivast...@citrix.com> wrote: >Please find the updated FS at: > >https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS+-+IP+Range+Re >ser >vation+within+a+Network > >Thanks, >Saksham >________________________________________ >From: Saksham Srivastava [saksham.srivast...@citrix.com] >Sent: Tuesday, January 22, 2013 12:20 PM >To: cloudstack-dev@incubator.apache.org >Subject: RE: [DISCUSS] IP Address Reservation within a network > >My comments inline. I will update the FS with the feedback. > >Thanks, >Saksham > >________________________________________ >From: Chiradeep Vittal [chiradeep.vit...@citrix.com] >Sent: Saturday, January 19, 2013 5:09 AM >To: CloudStack DeveloperList >Subject: Re: [DISCUSS] IP Address Reservation within a network > >The current way of inferring a cidr from gateway and netmask is odd. I >support the addition of a 'cidr' parameter to the createNetwork API. If >it is supplied then that should be the basis of specifying the cidr >rather than the gateway/netmask combo. > >[Saksham]: Thanks Chiradeep for your insight. I agree addition of new >optional parameter "cidr" >but to maintain backward compatibility of the api, any one from >Gateway/Netmask combo or cidr could be used. > >On 1/17/13 8:07 AM, "Sowmya Krishnan" <sowmya.krish...@citrix.com> wrote: > >>Hi Saksham, >> >>To comment on your question: >>>> Should shared guest networks also allow for IP reservation >>>>considering the current scenario where Start IP and End IP are >>>>mandatory during shared guest network creation. >> >>Isn't this functionality already implicitly present for shared >>networks since we specify network and start, end IPs during creation? >> >[Saksham] Yes, the functionality is already there but implicit. >We need to document the case of shared network in this context. > >>Few comments on the FS: >> >>1. What is the reason for using Start IP and End IP in place of CIDR? >>Is it to make it consistent with shared Network? Considering the edge >>case which you've mentioned in the FS - Case 5, the Guest VM CIDR >>would occupy the entire n/w and no reservation will be possible in >>that n/w for that range. Isn't it better to use CIDR? > >[Saksham] Yes the initial idea was to have IP range, but after the >discussion here, I will change it to Guest Vm CIDR. >Further, its a complete admin/user choice what he specifies as the >address space for Guest VMs. >It could result in no reservation also (the edge case) but as an >orchestration layer, CloudStack should not validate it. > >>2. While reserving IPs for new or existing n/w, is it allowed to have >>non-contiguous IP ranges? Ex: I want to reserve 192.168.0.10 - >>192.168.0.20. This in effect leads to non-contiguous Guest IP Range. >>In this case will we end up having multiple Guest CIDRs for the network? > >[Saksham] The feature currently only allows a single GuestVm CIDR. > >>3. After updating a guest n/w with reserved IPs, will the network be >>re-implemented? It should ideally not.. > >[Saksham] The network will restart when we do a change in the IP range >because existing VMs also need to be accommodated in the new range. So >a reimplementation cannot be avoided. > >>4. While updating a guest n/w with reserved IPs following checks >>should be performed: >> 4a. Only expansion is possible >> 4b. The range is contiguous (if answer to 2 is No) >> 4c. If using default CIDR, newly defined Guest CIDR should match >>the existing one > >[Saksham] Updating the guest Vm CIDR is still an open issue. > >>5. In case of network offerings using external devices, user cannot >>currently define CIDR - this constraint will continue to exist for IP >>reservation too? Or will extending IP range be allowed in the existing >>n/w and then allow reservation over the new range defined? > >[Saksham] Reservation will be done only after the network is >implemented, instead of doing it at createNetwork level. >So networks using external devices will be allowed to have reservation >once they are implemented. > >>6. In the DB, is it necessary to store both Start IP-End IP along with >>guest_vm_cidr? Wouldn't effective cidr suffice since it's derived? > >[Saksham] You are correct, guest_vm_cidr will suffice >> >>Thanks, >>Sowmya >> >>-----Original Message----- >>From: Saksham Srivastava [mailto:saksham.srivast...@citrix.com] >>Sent: Tuesday, January 15, 2013 10:37 PM >>To: cloudstack-dev@incubator.apache.org >>Subject: [DISCUSS] IP Address Reservation within a network >> >> >>Please find the FS for the feature at >>https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS-+IP+Range+Re >>ser >>v >>ation+within+a+Network >> >>Few of the points I want to bring for discussion: >> >>1) Extending the functionality to shared network >> Should shared guest networks also allow for IP reservation >>considering the current scenario where Start IP and End IP are >>mandatory during shared guest network creation. >> >>2) Extending the GuestVm CIDR once a network is setup. >> Ideally GuestVM CIDR can be extended to be equal to Guest CIDR. >>But >>Extending the range requires evaluation of each IP in the extended >>range whether it has been allocated or not. >> Ping test is a primitive solution as ICMP denying hosts may not >>respond. >>Need suggestions on that. >> >>Regards, >>Saksham Srivastava >> >> >>-----Original Message----- >>From: Saksham Srivastava [mailto:saksham.srivast...@citrix.com] >>Sent: Thursday, January 10, 2013 12:19 PM >>To: cloudstack-dev@incubator.apache.org >>Subject: RE: [DISCUSS] IP Address Reservation within a network >> >>Using VLSM at the zone creation the admin can create multiple subnets >>from a parent subnet, but that is not what we are targeting at. >>CloudStack admin should not be interested to create a subnet for Non >>CloudStack hosts IMHO. >>This particular requirement is to only have a definite subnet for >>CloudStack Guest VMs and all other IPs in the parent subnet can be >>assigned to non CloudStack purposes. >> >>Thanks, >>Saksham >>________________________________________ >>From: Kelcey Damage (BT) [kel...@backbonetechnology.com] >>Sent: Friday, January 04, 2013 11:56 PM >>To: cloudstack-dev@incubator.apache.org >>Subject: RE: [DISCUSS] IP Address Reservation within a network >> >>So I see this and now wonder why do we even specify the guest CIDR at >>zone creation? Why not just use VLSM at network creation? Or some >>other instance in time controlled by the client/admin provisioning process. >> >>Thanks >> >>-kd >> >>>-----Original Message----- >>>From: Saksham Srivastava [mailto:saksham.srivast...@citrix.com] >>>Sent: Friday, January 04, 2013 9:41 AM >>>To: cloudstack-dev@incubator.apache.org >>>Cc: Manan Shah; Chiradeep Vittal >>>Subject: RE: [DISCUSS] IP Address Reservation within a network >>> >>>The admin can specify the CIDR to be used for guest VMs (Guest CIDR) >>>during advanced zone creation. >>> >>>This CIDR is used by default for the Guest Networks. >>> >>>The proposed plan is to have a new parameter say "CS-GuestVM CIDR" >>>which will be a subset of the Guest CIDR. >>>For instance at the time of zone creation the Guest CIDR is >>>10.1.1.0/24 And >>the >>>"CS-GuestVM CIDR" is specified as 10.1.1.0/26 So the remaining IPs >>>can now be used for Non Cloudstack VMs/Physical servers. >>>The plan is to now use only 10.1.1.0/26 as the CIDR for Cloudstack >>>Guest >>Vms. >>> >>>Currently when the user wants to create a new Guest network , he >>>specifies the gateway and subnet mask. >>>The proposal is that he will have additional options to specify the >>>start >>range >>>and end range for guest vms. The remaining IPs can then be used for >>>Non Cloudstack vms. >>> >>>Also the ranges will be frozen once the network is created. >>> >>>Thanks, >>>Saksham >>> >>>-----Original Message----- >>>From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] >>>Sent: Thursday, January 03, 2013 12:59 PM >>>To: CloudStack DeveloperList >>>Cc: Manan Shah >>>Subject: Re: [DISCUSS] IP Address Reservation within a network >>> >>>The proposed workflow seems counter-intuitive to me from an end-user >>>perspective. >>>How about: reserve a range of *usable* ip addresses. Then the admin >>>is free to use the remainder of the range. >>>Questions: >>>1. Is it one range or multiple? >>>2. Are there update semantics, or are the ranges frozen once the >>>network is created? >>> >>> >>>On 12/31/12 2:11 AM, "Saksham Srivastava" >>><saksham.srivast...@citrix.com> >>>wrote: >>> >>>>Hi all, >>>> >>>>I have started looking into this feature and would like to have the >>>>community feedback/suggestions on it. >>>> >>>>I would be sharing the FS shortly. >>>> >>>>Thanks, >>>>Saksham >>>> >>>> >>>> >>>>On Saturday 22 December 2012 06:51 AM, Manan Shah wrote: >>>>> Hi, >>>>> >>>>> >>>>> I would like to propose a new feature for IP Reservation within a >>>>>network. >>>>> I have created a JIRA ticket and provided the requirements at the >>>>>following location. Please provide feedback on the requirements. >>>>> JIRA Ticket: https://issues.apache.org/jira/browse/CLOUDSTACK-705 >>>>> Requirements: >>>>> >>>>>https://cwiki.apache.org/confluence/display/CLOUDSTACK/IP+Range+Res >>>erv >>>>>ati >>>>>on >>>>> +within+a+Network >>>>> >>>>> >>>>> Regards, >>>>> Manan Shah >>>>> >>>>> >> >> >
