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 61D6FE7CB for ; Mon, 4 Feb 2013 06:13:20 +0000 (UTC) Received: (qmail 54273 invoked by uid 500); 4 Feb 2013 06:13:20 -0000 Delivered-To: apmail-incubator-cloudstack-dev-archive@incubator.apache.org Received: (qmail 54235 invoked by uid 500); 4 Feb 2013 06:13:19 -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 54222 invoked by uid 99); 4 Feb 2013 06:13:19 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Feb 2013 06:13:19 +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 sudha.ponnaganti@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; Mon, 04 Feb 2013 06:13:12 +0000 X-IronPort-AV: E=Sophos;i="4.84,597,1355097600"; d="scan'208";a="6127479" Received: from sjcpmailmx02.citrite.net ([10.216.14.75]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Feb 2013 06:12:37 +0000 Received: from SJCPMAILBOX01.citrite.net ([10.216.4.73]) by SJCPMAILMX02.citrite.net ([10.216.14.75]) with mapi; Sun, 3 Feb 2013 22:12:37 -0800 From: Sudha Ponnaganti To: "cloudstack-dev@incubator.apache.org" Date: Sun, 3 Feb 2013 22:12:37 -0800 Subject: RE: [DISCUSS] Packaging in 4.1 Thread-Topic: [DISCUSS] Packaging in 4.1 Thread-Index: Ac4CdRi0EpV5ZcVYToWcUlBXr7V1uwAKUPew Message-ID: <7914B38A4445B34AA16EB9F1352942F1012F15861558@SJCPMAILBOX01.citrite.net> References: <6DE00C9FDF08A34683DF71786C70EBF02F69715B@SBPOMB402.sbp.lan> 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 Wanted to check when would this be implemented?? Several QA folks depend on= the packages and need this working.=20 We have been still building using waf but today that is also not working as= some references are removed.=20 Is it possible to accelerate this process or leave old way of packaging in = place till you are done with the new changes Thanks /sudha -----Original Message----- From: rohityadav89@gmail.com [mailto:rohityadav89@gmail.com] On Behalf Of R= ohit Yadav Sent: Sunday, February 03, 2013 5:14 PM To: cloudstack-dev@incubator.apache.org Subject: Re: [DISCUSS] Packaging in 4.1 On Mon, Feb 4, 2013 at 4:41 AM, David Nalley wrote: > On Sun, Feb 3, 2013 at 3:58 PM, Rohit Yadav wrote: >> On Sun, Feb 3, 2013 at 3:07 PM, David Nalley wrote: >> ... >>> >>> So EL6 has pygments 1.1.1 - you require 1.5, so in some ways it's=20 >>> worth than clint (clint is in EPEL, but no new version of pygments=20 >>> in >>> EPEL/CentOS-Extras/CentOS-Plus) >> >> I want people to use pip to install the cli because it's the easiest=20 >> and because rpm/deb packages may have dependency issues like you=20 >> mentioned =3D> may not work on all distros, what we can do is when=20 >> people install cloudstack-cli rpm or deb, it runs a script that=20 >> installs pip (if unavailable) and cloudmonkey. cloudmonkey is pure=20 >> python, so the rpm/deb can also ship bundling src tarballs of=20 >> cloudmonkey and its dependencies and install from it. Advise best way=20 >> of doing this? > > I guess we won't be installing the CLI via RPMs at least for EL6. > > You are assuming that they would have internet access when installing > - which is not a valid assumption. > > Honestly, the above idea makes me blanch. A package that reports as=20 > installed, and may or may not have installed - may have installed a=20 > compromised package (see rubygems.org compromise recently, kernel.org,=20 > and a number of other site compromises.), or might have installed=20 > packages I didn't know about is a Bad Idea (tm) The sysadmin doesn't=20 > know you are installing some of the dependencies, there is no record=20 > of those packages in the package manager, and there might potentially=20 > be conflicts with system packages, a security vulnerability in one of=20 > those dependencies wouldn't be caught on audit, etc etc. /facepalm\, it's just a problem of packaging. The package can include cli o= r any other artifact's dependencies, so in case of cli, you bundle both pyg= ments and prettytable in cli's rpm/deb. AFAIK all of them are pure python s= o easily installable. The cool people can use pip to install. > > And I really don't intend for this to sound like a rant, but the one=20 > of the important benefits behind using packages and a package manager=20 > is that a sysadmin needs (and often is required to have by government > regulations) a single source of truth about the software installed on=20 > a machine. No, it's not a rant, I understand. > Developers love things like Maven central, pypi, CPAN, and rubygems,=20 > and for good reason, they are fast, flexible, and make their life=20 > easy. To a sysadmin managing machines in production, they are=20 > anathema; they make system state difficult or impossible to determine,=20 > they make audits painful. I just assumed the sysadmin who would install CloudStack, cli and whatnot w= on't be stupid, at the same time I want his life to be less miserable. > In addition they make troubleshooting > incredibly difficult. Do I have $foo installed - which version? Are=20 > there multiple copies of $foo installed on the system? Which one is=20 > actually being called/loaded? Alright, but I'm talking only about the cli, since most users, admins inclu= ded, would want it to run on their machines, the installation should be eas= iest, that's why I said they can use pip, so it works on their windows, osx= , linux, bsd boxes and that's why it's pure python (written that way). Regards. > > --David