cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pradeep Soundararajan <>
Subject RE: [DISCUSS] Packaging in 4.1
Date Wed, 06 Feb 2013 10:00:04 GMT
Thanks Hugo, Wido and Noa for bringing this to some closure :)

I am able to package rpm using "packaging/centos63/" after some modification in
the script since cloud.spec is looking for 'cloudstack' Name.

-mkdir -p $RPMDIR/SOURCES/cloud-$VERSION
+mkdir -p $RPMDIR/SOURCES/cloudstack-$VERSION

-(cd ../../; tar -c --exclude .git --exclude dist  .  | tar -C $RPMDIR/SOURCES/cloud-$VERSION
-x )
-(cd $RPMDIR/SOURCES/; tar -czf cloud-$VERSION.tgz cloud-$VERSION)
+(cd ../../; tar -c --exclude .git --exclude dist  .  | tar -C $RPMDIR/SOURCES/cloudstack-$VERSION
-x )
+(cd $RPMDIR/SOURCES/; tar -czf cloudstack-$VERSION.tgz cloudstack-$VERSION)

Packaging went fine after the above modification but I have observed some issues while installing
the package.  I believe you have changed the installation path from */cloud/* to */cloudstack/*
and also observed you have changed all the rpm names from cloud* to cloudstack*.  If that
is a situation then I feel we cannot upgrade from 4.0 since they were pointing to different
rpm names and they were loaded in a different location.  I feel,  this would raise lot of
compatibility issues here and there.

Noticed you have changed cloud-client to cloudstack-management. I feel, we have to modify script accordingly in order to satisfy all the changed conditions.

Time being shall we keep all the internals intact with the same name cloud instead of cloudstack?

Please let us know if any one see any other issues.

Pradeep S

-----Original Message-----
From: Wido den Hollander [] 
Sent: Wednesday, February 06, 2013 1:33 AM
Subject: Re: [DISCUSS] Packaging in 4.1

On 02/05/2013 06:33 PM, Noa Resare wrote:
> I built the latest from the packaging branch. I think it is shaping up 
> nicely. Some thoughts:
> How would you feel with postponing the config directory changes until 4.2?
> While I agree conceptually that they are an improvement, waiting with 
> them would keep the diff size down, simplifying merge and the focus of 
> stabilization for 4.1

Yes, I stumbled upon the same while merging master into packaging.

It doesn't hurt anybody to keep it in the current shape, the end result will be the same.


> /n
> On Mon, Feb 4, 2013 at 11:33 AM, Wido den Hollander <> wrote:
>> On 02/04/2013 07:12 AM, Sudha Ponnaganti wrote:
>>> 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
>> I fully understand. As I told David, I think the DEB work is about 
>> one day of work, but then again, there is something like $dayjob.
>> What might be even tougher is to get the RPM and DEB packages fully 
>> synced. cloudstack-common for example should contain exactly the same 
>> files in the RPM and DEB version, so Hugo and I will have to keep in touch.
>> I really want to have the DEB packaging working this week, period.
>> Wido
>>   Thanks
>>> /sudha
>>> -----Original Message-----
>>> From: [**] On 
>>> Behalf Of Rohit Yadav
>>> Sent: Sunday, February 03, 2013 5:14 PM
>>> To: 
>>> cloudstack-dev@incubator.**<cloudstack-dev@incubator.apach
>>> 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
>>>> 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).
>>> Regards.
>>>> --David

View raw message