Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <504F8807.5080709@widodh.nl>
Date: Tue, 11 Sep 2012 20:50:47 +0200
From: Wido den Hollander <wido@widodh.nl>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: cloudstack-dev@incubator.apache.org
Subject: Re: [DISCUSS] Install.sh vs. pacakge repos
References: 
 <CAKprHVY6AwA1Adw3GL0+CnEcBbu-OyJbszSCCp8da3wMeqf6=w@mail.gmail.com>
In-Reply-To: 
 <CAKprHVY6AwA1Adw3GL0+CnEcBbu-OyJbszSCCp8da3wMeqf6=w@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


On 09/11/2012 05:45 PM, David Nalley wrote:
> On Tue, Sep 11, 2012 at 8:23 AM, Wido den Hollander <wido@widodh.nl> wrote:
>> On 09/11/2012 12:16 PM, Suresh Sadhu wrote:
>>>
>>> HI All,
>>>
>>> Installer fail to read the cloud packages  and MS installation on Ubuntu
>>> 12.04 was not successful(No packages were installed) Raised a blocker bug.
>>> Please find the issue details in the below mentioned issue:
>>>
>>
>> I'd like to bring this up again, do we REALLY want this install.sh script?
>
>
> This really deserves its own thread, because it won't receive the
> attention it deserves in the original thread.
>
> I talked with infra about this a few weeks back, and while they said
> they really wanted downstreams to package, they weren't vehemently
> opposed to use creating our own repo, but we'd have to figure out how
> to make it work with the mirror system.
>

A Debian/Ubutnu repository is just a bunch of directories and files, 
that could be distributed I think?

The question is, do we want this to go on ASF infra or us an external 
mirror for it?

> Personally - the packages as they exist are great for people doing a
> first, small scale install, but it doesn't scale. While I am not
> necessarily opposed to the installer, I also recognize the problems
> from a real world deployment perspective.
>

I disagree on the first point. When manually installing packages with 
dpkg you will run into dependency hell. You (you=install script) 
manually have to "apt-get install" several packages.

The problem you run into here is that you start doing redundant work. In 
the "control" file you specify which packages you depend on. If you'd 
use apt(itude) it will resolve those dependencies for you. But when 
doing a manual install with dpkg it will complain about every single 
package which is missing.

This leads to having install.sh a couple of directives to install 
packages we already specific in the control file. On the longer run you 
get packages installed by install.sh which are no longer required, but 
apt has no way of knowing they can be removed.

Packages should always enter a Debian system through apt to know which 
package was depending on which package so apt(itude) can do their work.

Adding a repository and install CloudStack is just 4 commands, isn't 
that simple enough?

$ echo "deb http://cloudstack.apt-get.eu/ubuntu $(lsb_release -s -c) 
4.0" > /etc/apt/sources.list.d/cloudstack.list
$ wget -O - http://cloudstack.apt-get.eu/release.asc|apt-key add -
$ apt-get update
$ apt-get install cloud-agent

Again, the repo of mine is just an example :)

> However, there is an impact, at a minimum all of our documentation
> will need rewriting, so personally, I'd prefer that for 4.0.0 - that
> we do repos if we can figure it out in time, and keep the installer as
> an option as well.
>


Re-writing the docs is a couple of hours work I'd be more then happy to 
do for 4.0 if we go for a repo.

I honestly must admit that in some recent docs I already assumed there 
would be a repo for 4.0...

It would be awesome if Jenkins could produce packages and send them to 
the mirror, but it's more then doable to build the packages locally and 
upload them, it's not like we are doing 10 releases a month.

It's just placing the packages in the "pool" directory and have a script 
re-scan the repo.

The question remains: Do we want this to be on ASF infra or do we host 
this externally?

Wido