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 9459D107E2 for ; Fri, 23 Aug 2013 23:26:49 +0000 (UTC) Received: (qmail 43620 invoked by uid 500); 23 Aug 2013 23:26:49 -0000 Delivered-To: apmail-cloudstack-dev-archive@cloudstack.apache.org Received: (qmail 43584 invoked by uid 500); 23 Aug 2013 23:26:49 -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 43576 invoked by uid 99); 23 Aug 2013 23:26:49 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 23 Aug 2013 23:26:49 +0000 X-ASF-Spam-Status: No, hits=-5.0 required=5.0 tests=RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of Chiradeep.Vittal@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 23:26:45 +0000 X-IronPort-AV: E=Sophos;i="4.89,945,1367971200"; d="scan'208";a="47113350" Received: from sjcpex01cl03.citrite.net ([10.216.14.145]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA; 23 Aug 2013 23:26:22 +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 16:26:21 -0700 From: Chiradeep Vittal 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: AQHOoC1nhnkUMiCjg0u3SjpONxjsLZmjK8MAgAB3tACAABFNAP//uzAA Date: Fri, 23 Aug 2013 23:26:20 +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.3.6.130613 x-originating-ip: [10.216.48.12] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org Slight correction: the templates are exactly the same. No difference. Scripts may be different due to hot plug On 8/23/13 1:32 PM, "Alena Prokharchyk" wrote: >Also note that VPC VR uses different template and diff script sets from >regular 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 =AD originally it >starts up with just 1 Control Nic, and (n) Public Nics + (n) Guest nics >are being plugged/unplugged on demand =AD when Public IP address is >acquired from the new Vlan, or when new Guest network is implemented in >the VPC. This logic is handled by Java code. > * Regular VR in Isolated network always starts up with pre-defined >set of nics =AD Control, Public and Guest. There can be only one situation >when new Nic is added to the VR =AD 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 create 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 >for 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 > >