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 493CDD39A for ; Thu, 6 Sep 2012 22:37:13 +0000 (UTC) Received: (qmail 2480 invoked by uid 500); 6 Sep 2012 22:37:13 -0000 Delivered-To: apmail-incubator-cloudstack-dev-archive@incubator.apache.org Received: (qmail 2422 invoked by uid 500); 6 Sep 2012 22:37:13 -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 2414 invoked by uid 99); 6 Sep 2012 22:37:12 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 06 Sep 2012 22:37:12 +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 Edison.su@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, 06 Sep 2012 22:37:08 +0000 X-IronPort-AV: E=Sophos;i="4.80,381,1344211200"; d="scan'208";a="207349923" Received: from sjcpmailmx01.citrite.net ([10.216.14.74]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 06 Sep 2012 22:36:47 +0000 Received: from SJCPMAILBOX01.citrite.net ([10.216.4.72]) by SJCPMAILMX01.citrite.net ([10.216.14.74]) with mapi; Thu, 6 Sep 2012 15:36:46 -0700 From: Edison Su To: "cloudstack-dev@incubator.apache.org" Date: Thu, 6 Sep 2012 15:36:46 -0700 Subject: RE: Review Request: maven kvm hypervisor plugin build without -Dnonoss Thread-Topic: Review Request: maven kvm hypervisor plugin build without -Dnonoss Thread-Index: Ac2Mfppliub6AKI1QL+zQ6pj7ETiNQAAVzBg Message-ID: References: <20120905103850.583.2968@reviews.apache.org> <20120906170426.591.95278@reviews.apache.org> <504907FA.90103@widodh.nl> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: 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 I'll add a switch to enable and disable kvm. > -----Original Message----- > From: Marcus Sorensen [mailto:shadowsor@gmail.com] > Sent: Thursday, September 06, 2012 3:25 PM > To: cloudstack-dev@incubator.apache.org > Subject: Re: Review Request: maven kvm hypervisor plugin build without > -Dnonoss >=20 > You can disable it in the default build, but still allow it in waf > build, correct? Or at the very least it seems that the RPM build > should ship building the agent with a message saying 'do x y z to > enable KVM first' or some such. >=20 > Nobody is going to build an RPM and not want KVM support, it's not > like the citrix or Vmware resources can be used with RHEL/CentOS. >=20 > On Thu, Sep 6, 2012 at 3:40 PM, David Nalley wrote: > > On Thu, Sep 6, 2012 at 4:30 PM, Wido den Hollander > wrote: > >> > >> > >> On 09/06/2012 08:05 PM, Marcus Sorensen wrote: > >>> > >>> Trying to get a working RPM build of 4.0 going... I assume my > latest > >>> issue is related to this. "class not found: > >>> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource", if > >>> someone is building RPMs isn't it safe to assume they want the > >>> kvm/libvirt pieces? What was Wido's fix? I don't see this patch > >>> applied to maven-waf, just 623f199b0378683e6f5f0c2b2b5c692b6504d16f > as > >>> latest. > >> > >> > >> Sorry, I completely missed this review! > >> > >> The legal issue with KVM was approved like Elan posted, see LEGAL- > 144 as I > >> mentioned in the commit message. > >> > >> I saw Elan's post on the ml, checked out the legal status and > enabled KVM > >> again since we were allowed to do so :) > >> > >> Wido > >> > > > > > > I am not sure that this is my understanding. > > Doesn't the 'default build option' have to miss KVM because it > > currently doesn't have a license that permits it? Or did we decide to > > identify this as a system dependency? > > > > I know we got blessing to produce KVM-inclusive convenience binaries, > > but point 1 of the accepted proposal in LEGAL-144 says: > > Disable KVM support in the default build, as per policy. > > > > --David