cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sudha Ponnaganti <>
Subject RE: [DISCUSS] Packaging in 4.1
Date Mon, 04 Feb 2013 06:12:37 GMT
Wanted to check when would this be implemented?? Several QA folks depend on the packages and
need this working. 
We have been still building using waf but today that is also not working as some references
are removed. 

Is it possible to accelerate this process or leave old way of packaging in place till you
are done with the new changes


-----Original Message-----
From: [] On Behalf Of Rohit Yadav
Sent: Sunday, February 03, 2013 5:14 PM
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 
>>> worth than clint (clint is in EPEL, but no new version of pygments 
>>> in
>>> EPEL/CentOS-Extras/CentOS-Plus)
>> I want people to use pip to install the cli because it's the easiest 
>> and because rpm/deb packages may have dependency issues like you 
>> mentioned => may not work on all distros, what we can do is when 
>> people install cloudstack-cli rpm or deb, it runs a script that 
>> installs pip (if unavailable) and cloudmonkey. cloudmonkey is pure 
>> python, so the rpm/deb can also ship bundling src tarballs of 
>> cloudmonkey and its dependencies and install from it. Advise best way 
>> 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 
> installed, and may or may not have installed - may have installed a 
> compromised package (see compromise recently,, 
> and a number of other site compromises.), or might have installed 
> packages I didn't know about is a Bad Idea (tm) The sysadmin doesn't 
> know you are installing some of the dependencies, there is no record 
> of those packages in the package manager, and there might potentially 
> be conflicts with system packages, a security vulnerability in one of 
> those dependencies wouldn't be caught on audit, etc etc.

/facepalm\, it's just a problem of packaging. The package can include cli or any other artifact's
dependencies, so in case of cli, you bundle both pygments and prettytable in cli's rpm/deb.
AFAIK all of them are pure python so 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 
> of the important benefits behind using packages and a package manager 
> is that a sysadmin needs (and often is required to have by government
> regulations) a single source of truth about the software installed on 
> a machine.

No, it's not a rant, I understand.

> Developers love things like Maven central, pypi, CPAN, and rubygems, 
> and for good reason, they are fast, flexible, and make their life 
> easy. To a sysadmin managing machines in production, they are 
> anathema; they make system state difficult or impossible to determine, 
> they make audits painful.

I just assumed the sysadmin who would install CloudStack, cli and whatnot won'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 
> there multiple copies of $foo installed on the system? Which one is 
> actually being called/loaded?

Alright, but I'm talking only about the cli, since most users, admins included, would want
it to run on their machines, the installation should be easiest, 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).

> --David

View raw message