Return-Path: X-Original-To: apmail-incubator-cloudstack-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-cloudstack-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 07B69DFAE for ; Thu, 24 Jan 2013 00:20:32 +0000 (UTC) Received: (qmail 18188 invoked by uid 500); 24 Jan 2013 00:20:31 -0000 Delivered-To: apmail-incubator-cloudstack-dev-archive@incubator.apache.org Received: (qmail 18157 invoked by uid 500); 24 Jan 2013 00:20:31 -0000 Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: cloudstack-dev@incubator.apache.org Delivered-To: mailing list cloudstack-dev@incubator.apache.org Received: (qmail 18149 invoked by uid 99); 24 Jan 2013 00:20:31 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 24 Jan 2013 00:20:31 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of manan.shah@citrix.com designates 66.165.176.63 as permitted sender) Received: from [66.165.176.63] (HELO SMTP02.CITRIX.COM) (66.165.176.63) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 24 Jan 2013 00:20:26 +0000 X-IronPort-AV: E=Sophos;i="4.84,525,1355097600"; d="scan'208";a="4611173" Received: from sjcpmailmx02.citrite.net ([10.216.14.75]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 24 Jan 2013 00:20:05 +0000 Received: from SJCPMAILBOX01.citrite.net ([10.216.4.73]) by SJCPMAILMX02.citrite.net ([10.216.14.75]) with mapi; Wed, 23 Jan 2013 16:20:04 -0800 From: Manan Shah To: "cloudstack-dev@incubator.apache.org" Date: Wed, 23 Jan 2013 16:19:58 -0800 Subject: Re: [DISCUSS] IP Address Reservation within a network Thread-Topic: [DISCUSS] IP Address Reservation within a network Thread-Index: Ac35yI65Ofqlm4fURZSD8l/CLajZ0Q== Message-ID: In-Reply-To: <33740054EBF5B64BB213E2E0916F2C13F074EA03B8@BANPMAILBOX01.citrite.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org 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 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? 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. Can you please update the FS with these details? Regards, Manan Shah On 1/22/13 2:23 AM, "Saksham Srivastava" wrote: >Please find the updated FS at: > >https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS+-+IP+Range+Reser >vation+within+a+Network > >Thanks, >Saksham >________________________________________ >From: Saksham Srivastava [saksham.srivastava@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.Vittal@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" 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.srivastava@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+Reser >>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.srivastava@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) [kelcey@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.srivastava@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.Vittal@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" >>> >>>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 >>>>> >>>>> >> >> >