Return-Path: X-Original-To: apmail-cloudstack-dev-archive@www.apache.org Delivered-To: apmail-cloudstack-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id A12CA10121 for ; Fri, 23 Aug 2013 20:33:00 +0000 (UTC) Received: (qmail 58390 invoked by uid 500); 23 Aug 2013 20:32:59 -0000 Delivered-To: apmail-cloudstack-dev-archive@cloudstack.apache.org Received: (qmail 58359 invoked by uid 500); 23 Aug 2013 20:32:59 -0000 Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cloudstack.apache.org Delivered-To: mailing list dev@cloudstack.apache.org Received: (qmail 58350 invoked by uid 99); 23 Aug 2013 20:32:59 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 23 Aug 2013 20:32:59 +0000 X-ASF-Spam-Status: No, hits=-2.8 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of Alena.Prokharchyk@citrix.com designates 66.165.176.89 as permitted sender) Received: from [66.165.176.89] (HELO SMTP.CITRIX.COM) (66.165.176.89) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 23 Aug 2013 20:32:53 +0000 X-IronPort-AV: E=Sophos;i="4.89,944,1367971200"; d="scan'208,217";a="47077469" Received: from sjcpex01cl03.citrite.net ([10.216.14.145]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA; 23 Aug 2013 20:32:31 +0000 Received: from SJCPEX01CL02.citrite.net ([169.254.2.241]) by SJCPEX01CL03.citrite.net ([10.216.14.145]) with mapi id 14.02.0342.004; Fri, 23 Aug 2013 13:32:30 -0700 From: Alena Prokharchyk To: "dev@cloudstack.apache.org" CC: "jeffrey.mcgovern@sungard.com" Subject: Re: VPG only in VPC VRs? Thread-Topic: VPG only in VPC VRs? Thread-Index: AQHOoC5dHa3U4z9bQEqpiz4z6k2t15mjoRuAgAACWgD//5v/gA== Date: Fri, 23 Aug 2013 20:32:30 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 x-originating-ip: [10.216.48.12] Content-Type: multipart/alternative; boundary="_000_CE3D11EC349CDalenaprokharchykcitrixcom_" MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org --_000_CE3D11EC349CDalenaprokharchykcitrixcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Also note that VPC VR uses different template and diff script sets from reg= ular Isolated network's VR. Before the migration, we have to: 1) Merge code base for VR and VPC VR. Use the same template for both. 2) As a part of the Java code merge: * The current VPC VR uses hot plug nic mechanism =96 originally it star= ts up with just 1 Control Nic, and (n) Public Nics + (n) Guest nics are bei= ng plugged/unplugged on demand =96 when Public IP address is acquired from = the new Vlan, or when new Guest network is implemented in the VPC. This log= ic is handled by Java code. * Regular VR in Isolated network always starts up with pre-defined set = of nics =96 Control, Public and Guest. There can be only one situation when= new Nic is added to the VR =96 when new public IP address is acquired from= the Vlan diff from the Source nat IP vlan. In this case we do plug the nic= on the VR, but this logic is handled by the VR scripts. WE don't even crea= te a nic entry in the DB for this new Nic. * After the merge, VR in regular Isolated network should also implement= plug/unplug logic. 3) Add the DB upgrade for existing customers (including template upgrade fo= r existing Vrs) There more to do as a part of this fix, listed the above off the top of my = head. -alena. From: Marcus Sorensen > Reply-To: "dev@cloudstack.apache.org" > Date: Friday, August 23, 2013 12:30 PM To: "dev@cloudstack.apache.org" > Cc: "jeffrey.mcgovern@sungard.com" > Subject: Re: VPG only in VPC VRs? I agree with Chiradeep, but it brings up a point that in some future release we probably need to convert/migrate existing VR/isolated network combos into VPCs so we can deprecate them entirely, as well as migrate the applicable api calls into creating the functionally equivalent VPCs... or something like that. I think VPC is probably also lacking in a few features yet, so they're not quite a replacement at the moment. Remote access VPN for example. On Fri, Aug 23, 2013 at 1:22 PM, Chiradeep Vittal > wrote: Are you asking why VR for isolated networks does not have this feature? I feel that isolated networks are legacy and whatever you want to do with isolated networks you should be able to do with a VPC in a single tier. On 8/23/13 11:19 AM, "Chip Childers" > wrote: Can someone explain the history / reasoning around why VPG's are only available for VPC VRs? And while we're at it... how about the same question around Site-to-site VPN's (and client VPN's in reverse)? Thanks! -chip --_000_CE3D11EC349CDalenaprokharchykcitrixcom_--