> On Feb. 1, 2013, 11:07 a.m., Murali Reddy wrote: > > Also its not clear to me, how you are ensuring that IP is allocated only > > from the guest CIDR range when its different from the network CIDR?
Murali, thanks a lot for your reviews. I am answering all your queries here. For this feature a column guest_cidr is added in networks table. So there are now 2 columns in the table "cidr" and "guest_cidr". 1) For non isolated guest networks there has been no change at all, the "cidr" column continues to be the way it used to be i.e. the network cidr. and "guest_cidr" always continues to be null, throughout the life cycle. ============================================================================ 2) For isolated guest networks : Whenever a network is created, "cidr" will have network cidr and "guest_cidr" will be null.(The way it has been working). When there is no reservation, "guest_cidr" is null, and "cidr" continues to be the network cidr. When first time reservation happens, a valid guestvmcidr is passed as parameter in updateNetwork API: "guest_cidr" copies the value of network cidr from "cidr" column and "cidr" gets populated with guestvmcidr so "cidr" is now the effective IP range for guest vms. Now for the next time when reservation is reapplied, the "guest_cidr" already has network cidr and "cidr" gets again re-popluated by the new guestvmcidr passed in the API. Same continues for every subsequent reservation. Guest VMs always pick IPs from "cidr" as usual and thus reservation gets applied. In short "guest_cidr" will now always have the network cidr "cidr" will always have the guestvmcidr value When the network is reimplemented like in case of upgrade to ext offerings : "cidr" is set to network cidr by copying the value from "guest_cidr" "guest_cidr" is reset to null to avoid an inconsistent state after the reimplementation. After reimplementation "cidr" will have the new network cidr and "guest_cidr" will be null and reservation can now be reapplied. The reason of doing this was not to touch Gurus and NetworkManagerImpl at all and also not to alter the functionality of "cidr" and continue it to serve as the address space for Guest VMs. ============================================================================= Response: guestcidr is the network cidr cidr is the effective cidr for guest vms reserved_ip_range is list of IPs to be used for non cloudstack purposes. The reason to add reserved_ip_range is to help reduce the IP calculations by admin. For instance : guestcidr = 10.1.1.0/24 cidr 10.1.1.64/26 reservediprange : 10.1.1.1-10.1.1.63 , 10.1.1.128-10.1.1.254 So to ease the calculation for the admin and also list the reservation range which is the prime aim of this feature, reservediprange is added. I would sincerely agree to document both the request and response to avoid any ambiguity. - saksham ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9180/#review16004 ----------------------------------------------------------- On Feb. 1, 2013, 10:34 a.m., saksham srivastava wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/9180/ > ----------------------------------------------------------- > > (Updated Feb. 1, 2013, 10:34 a.m.) > > > Review request for cloudstack, Murali Reddy and Chiradeep Vittal. > > > Description > ------- > > CLOUDSTACK-705 IP Address reservation for Isolated Guest Networks > > > CloudStack uses Guest CIDR for dhcp-range for the Guest VMs. The entire CIDR > is used by CloudStack for assigning IPs to Guest VMs. > IP Address Reservation will allow part of address space to be used for non > CloudStack hosts/physical servers also, by restricting the address space of > CloudStack Guest VMs. > Reservation can be configured using update Network API by specifying > guestvmCidr as an additional parameter. > Reservation will be applicable for Isolated Guest Networks including VPC. > reservediprange in the response will return the IP range that can be used for > non Cloudstack hosts. > > > This addresses bug CLOUDSTACK-705. > > > Diffs > ----- > > api/src/com/cloud/network/Network.java a70bf02 > api/src/com/cloud/network/NetworkProfile.java e3be941 > api/src/com/cloud/network/NetworkService.java 786afb1 > api/src/com/cloud/network/vpc/VpcService.java 68e062c > api/src/org/apache/cloudstack/api/ApiConstants.java d895191 > > api/src/org/apache/cloudstack/api/command/user/network/UpdateNetworkCmd.java > 978c71b > api/src/org/apache/cloudstack/api/response/NetworkResponse.java 40d6850 > server/src/com/cloud/api/ApiResponseHelper.java 2dcd09c > server/src/com/cloud/network/NetworkServiceImpl.java 5c70caa > server/src/com/cloud/network/NetworkVO.java 8020e7a > server/src/com/cloud/network/vpc/VpcManagerImpl.java 26e882e > server/test/com/cloud/network/MockNetworkManagerImpl.java af0b03f > server/test/com/cloud/vpc/MockNetworkManagerImpl.java 382068a > server/test/com/cloud/vpc/MockVpcManagerImpl.java 25799d1 > setup/db/create-schema.sql a847b43 > setup/db/db/schema-40to410.sql 6d5b262 > > Diff: https://reviews.apache.org/r/9180/diff/ > > > Testing > ------- > > Tested manually the following scenarios: > Applying reservation when there are running VMs inside the guest_vm_cidr. > Applying reservation when there are running VMs outside the > guest_vm_cidr.(not allowed) > Applying reservation when external device like Netscaler is configured in the > guest_cidr. > Applying reservation in VPC tiers. > Applying reservation outside the range of guest_cidr.(not allowed) > > > Thanks, > > saksham srivastava > >
