From cloudstack-dev-return-17319-apmail-incubator-cloudstack-dev-archive=incubator.apache.org@incubator.apache.org Tue Jan 15 21:47:38 2013 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 912E7E407 for ; Tue, 15 Jan 2013 21:47:38 +0000 (UTC) Received: (qmail 96624 invoked by uid 500); 15 Jan 2013 21:47:38 -0000 Delivered-To: apmail-incubator-cloudstack-dev-archive@incubator.apache.org Received: (qmail 96591 invoked by uid 500); 15 Jan 2013 21:47:38 -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 96580 invoked by uid 99); 15 Jan 2013 21:47:38 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 15 Jan 2013 21:47:38 +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 (nike.apache.org: domain of Alex.Huang@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; Tue, 15 Jan 2013 21:47:32 +0000 X-IronPort-AV: E=Sophos;i="4.84,475,1355097600"; d="scan'208";a="3859567" Received: from sjcpmailmx01.citrite.net ([10.216.14.74]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Jan 2013 21:47:10 +0000 Received: from SJCPMAILBOX01.citrite.net ([10.216.4.72]) by SJCPMAILMX01.citrite.net ([10.216.14.74]) with mapi; Tue, 15 Jan 2013 13:47:09 -0800 From: Alex Huang To: "cloudstack-dev@incubator.apache.org" Date: Tue, 15 Jan 2013 13:47:09 -0800 Subject: RE: SystemVM keypair setting in developer mode Thread-Topic: SystemVM keypair setting in developer mode Thread-Index: Ac3zZrivoeUMPNG9RXCLmg3GuJ/HbgAANlRw Message-ID: References: <355CA416-931B-4B94-8793-4084AC6FA88C@schubergphilis.com> 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 My mistake there. Thanks Marcus for reverting it and David for pointing it= out. The windows developer deployment fails because of this check and I changed = it to make it work for a training session but checked it in by mistake when= I checked in the sample plugin code. Reverting will mean windows will break again. I need to study it a little = bit to figure out why it breaks. --Alex > -----Original Message----- > From: Marcus Sorensen [mailto:shadowsor@gmail.com] > Sent: Tuesday, January 15, 2013 1:24 PM > To: cloudstack-dev@incubator.apache.org > Subject: Re: SystemVM keypair setting in developer mode >=20 > Ok, I'm going to put it back for now, and if there's an issue that can't = be > resolved some other way then we can address it further. I'm fairly > confident that it was ok previously since 4.0 seems to deploy fine. I jus= t > didn't want to get into a commit war where someone keeps changing it back > because it causes some other problem, without bringing it up. >=20 > On Tue, Jan 15, 2013 at 2:17 PM, Hugo Trippaers < > HTrippaers@schubergphilis.com> wrote: >=20 > > I ran into the same problem as well, but I didn't do the check where it > > came from. I just "fixed" it in the openvswitch branch and continued > > working. > > > > I think it's a plain and simple mistake. > > > > Cheers, > > > > Hugo > > > > Verstuurd vanaf mijn iPad > > > > Op 15 jan. 2013 om 22:08 heeft "Marcus Sorensen" > > > het volgende geschreven: > > > > > Yes, I just got bitten by this as well. I'm hoping Alex can comment o= n > > the > > > commit because I'm not super familiar with this or what was being fix= ed > > by > > > the change to an OR. It used to be that they keys would generate if y= ou > > > were running as user 'cloud' OR the developer configuration flag was = set. > > > This was accomplished with an &&, which is confusing. The commit > changed > > it > > > to an ||, which means that it only sets up the keys if you're running= as > > > user 'cloud' AND the developer flag is set. > > > > > > Went from: > > > > > > if (!username.equalsIgnoreCase("cloud") && !devel) { > > > > > > to: > > > > > > if (!username.equalsIgnoreCase("cloud") || !devel) { > > > > > > I think this will actually break KVM altogether in 4.1, because now t= he > > > management server needs to be run as user cloud AND the devel flag ha= s > to > > > be set in order to generate keys. > > > > > > This sounds lame, but I was confused enough by that if statement that= I > > put > > > it into some test code to verify: > > > > > > public class TestCase { > > > public static void main(String[] args) { > > > String username =3D args[0]; > > > String devel =3D args[1]; > > > if (!username.equalsIgnoreCase("cloud") || !devel.equals("1"))= { > > > System.out.println("skipping keys"); > > > } else { > > > System.out.println("generating keys"); > > > } > > > } > > > } > > > > > > How it was, looks right. If you're running as cloud it will generate > > > regardless, otherwise the dev flag has to be set: > > > > > > marcus@mlsorensen-bsdesk:~$ java TestCase cloud 0 > > > generating keys > > > marcus@mlsorensen-bsdesk:~$ java TestCase cloud 1 > > > generating keys > > > marcus@mlsorensen-bsdesk:~$ java TestCase root 0 > > > skipping keys > > > marcus@mlsorensen-bsdesk:~$ java TestCase root 1 > > > generating keys > > > > > > How it is now. You have to be cloud and you need to have the dev flag > > set: > > > > > > marcus@mlsorensen-bsdesk:~$ java TestCase cloud 0 > > > skipping keys > > > marcus@mlsorensen-bsdesk:~$ java TestCase cloud 1 > > > generating keys > > > marcus@mlsorensen-bsdesk:~$ java TestCase root 0 > > > skipping keys > > > marcus@mlsorensen-bsdesk:~$ java TestCase root 1 > > > skipping keys > > > > > > > > > On Wed, Dec 19, 2012 at 10:34 PM, Dave Cahill > > wrote: > > > > > >> Hi, > > >> > > >> There seem to be crossed wires about systemVM keypairs and whether > the > > >> management server can be run as a user other than "cloud". > > >> > > >> On Nov 1st, in the mailing list thread "Setting the ssh.publickey an= d > > >> ssh.privatekey options", we decided that if a user is in developer m= ode > > >> (used mvn -P developer -pl developer -Ddeploydb), the "developer" > key > > >> should be inserted into the database, allowing systemvm keypairs to = be > > set > > >> even if the user is not "cloud". This was reviewed ( > > >> https://reviews.apache.org/r/7861/) and committed ( > > >> > > >> > > https://github.com/apache/incubator- > cloudstack/commit/476e771c1c8f81b87a77883922bc1b35dea213fc > > >> ). > > >> > > >> However, a Dec 1st commit changes the condition from: > > >> Disallow setting systemvm keypairs if the user is not "cloud" user A= ND > > is > > >> not in developer mode > > >> to > > >> Disallow setting systemvm keypairs if the user is not "cloud" user O= R is > > >> not in developer mode > > >> > > >> This effectively means the management server can't be run as a non- > cloud > > >> user. > > >> > > >> I can't tell form the commit message if this effect is intentional: > > >> "Removed that darn exceptions when cloudstack is running in windows. > > It's a > > >> simple or check that was written as an and check" > > >> > > >> > > https://github.com/apache/incubator- > cloudstack/commit/6036f73725889b3557263e1a4a80106f11217974 > > >> > > >> Anyone have any insights? > > >> > > >> Thanks, > > >> Dave. > > >> > >