Return-Path: 
 <dev-return-39327-apmail-cloudstack-dev-archive=cloudstack.apache.org@cloudstack.apache.org>
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 EDF9210D48
	for <apmail-cloudstack-dev-archive@www.apache.org>;
 Sat, 27 Jul 2013 10:42:22 +0000 (UTC)
Received: (qmail 62132 invoked by uid 500); 27 Jul 2013 10:42:22 -0000
Delivered-To: apmail-cloudstack-dev-archive@cloudstack.apache.org
Received: (qmail 61968 invoked by uid 500); 27 Jul 2013 10:42:21 -0000
Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@cloudstack.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@cloudstack.apache.org>
List-Post: <mailto:dev@cloudstack.apache.org>
List-Id: <dev.cloudstack.apache.org>
Reply-To: dev@cloudstack.apache.org
Delivered-To: mailing list dev@cloudstack.apache.org
Received: (qmail 61949 invoked by uid 99); 27 Jul 2013 10:42:21 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 27 Jul 2013 10:42:21 +0000
X-ASF-Spam-Status: No, hits=1.2 required=5.0
	tests=RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS,URIBL_BLACK
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of koushik.das@citrix.com
 designates 203.166.19.134 as permitted sender)
Received: from [203.166.19.134] (HELO SMTP.CITRIX.COM.AU) (203.166.19.134)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 27 Jul 2013 10:42:17 +0000
X-IronPort-AV: E=Sophos;i="4.89,757,1367971200";
   d="scan'208";a="3969225"
Received: from sinpex01cl03.citrite.net ([10.151.46.34])
  by SYDPIPO01.CITRIX.COM.AU with ESMTP/TLS/AES128-SHA;
 27 Jul 2013 10:41:54 +0000
Received: from SINPEX01CL02.citrite.net ([169.254.2.235]) by
 SINPEX01CL03.citrite.net ([169.254.3.145]) with mapi id 14.02.0342.004; Sat,
 27 Jul 2013 18:41:52 +0800
From: Koushik Das <koushik.das@citrix.com>
To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org>
Subject: RE: [DISCUSS] vlan uri format change
Thread-Topic: [DISCUSS] vlan uri format change
Thread-Index: AQHOiov1cgk7A88tWkmE/LK2cWCePpl4VdKQ
Date: Sat, 27 Jul 2013 10:41:51 +0000
Message-ID: 
 <DEB2697CC649A142980A3B54B3B818C3064731BD@SINPEX01CL02.citrite.net>
References: 
 <CAGQtxvYHOTN5jZqUpLX5M-hmj3crXOxvzYbTtNTWaoOmsqronA@mail.gmail.com>
 <51D13B28.4030107@stratosphere.co.jp>
 <CAGQtxvbuUdpDRdApEd2r7_PhmYJDpQ0R9B3Wwne+1+6dJovd=w@mail.gmail.com>
 <20130727053959.GA1027@cloud-2.local>
In-Reply-To: <20130727053959.GA1027@cloud-2.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.16.2.160]
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

I raised this in a separate thread. Daan created a new patch https://review=
s.apache.org/r/12849/ to address backward compat.

> -----Original Message-----
> From: Prasanna Santhanam [mailto:tsp@apache.org]
> Sent: Saturday, July 27, 2013 11:12 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] vlan uri format change
>=20
> Daan,
>=20
> This broke the KVM setups last week on master. I couldn't find your commi=
t-
> id for this change scanning the git logs. Toshiaki-san was looking at
> CLOUDSTACK-3682 regarding this change [1] where he makes the scheme
> backwards compatible to work with KVM agents of the past.
> Could you please have a look at the changeset?
>=20
> [1] https://reviews.apache.org/r/12985/
>=20
> On Mon, Jul 01, 2013 at 10:28:57AM +0200, Daan Hoogland wrote:
> > The gain is that enums like BroadcastDomainType and IsolationType do
> > not have to check for different formats in the presented uri. It also
> > makes it more intiutive what the parts in the uri mean; vlan://<id>
> > would inmply that id is a hostname instead of a scheme specific identif=
ier.
> >
> > I think I am reducing complexity, not introducing any. The present use
> > of uri for vlans is abuse of the construct, i don't think my proposed
> > new use is.
> >
> >
> > On Mon, Jul 1, 2013 at 10:17 AM, Hiroaki KAWAI
> <kawai@stratosphere.co.jp>wrote:
> >
> > > Daan, I'm curious about what is the improvement of changing the vlan
> > > String format in URI?
> > >
> > > I'm -1 on pushing more complexity in URI, because that's abuse of
> > > URI class and sounds it's time to get rid of URI.
> > >
> > >
> > >
> > > (2013/07/01 16:47), Daan Hoogland wrote:
> > >
> > >> H,
> > >>
> > >> I've been trying to get a patch accepted and had some discussions
> > >> to do it in parts as well. I would like to refresh the first part:
> > >>
> > >> vlans are now referred as vlan://<id>. I would like to change this
> > >> to vlan:<id>. This will changee addressing the id as a scheme
> > >> specific part instead of as a host. As a result it will be easier
> > >> to fix the code to use Nicira NVP and other sdn networks whereever
> > >> vlans are used now. Doing this will result in a patch that is a
> > >> subset of my earlier patch. It touches a lot of core code and tests
> > >> but has been tested  thoroughly for VPC gateways with both vlans
> > >> and Nicira NVP.
> > >>
> > >> regards,
> > >> Daan
> > >>
> > >>
> > >
>=20
> --
> Prasanna.,
>=20
> ------------------------
> Powered by BigRock.com