cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ewan Mellor <Ewan.Mel...@eu.citrix.com>
Subject RE: RPM / DEB repository
Date Fri, 24 Aug 2012 19:01:16 GMT
> -----Original Message-----
> From: Wido den Hollander [mailto:wido@widodh.nl]
> Sent: 24 August 2012 10:58
> To: cloudstack-dev@incubator.apache.org
> Subject: RPM / DEB repository
> 
> Hi,
> 
> While working on the documentation I'm figured it would be nice if we would
> have a RPM / DEB repository.
> 
> The CloudStack packages depend on a lot of external packages and if admins
> would install using yum or apt these dependencies would be resolved
> automatically.
> 
> For example:
> 
> $ echo "deb http://dl.cloudstack.org/debian 4.0" >
> /etc/apt/sources.list.d/cs.list $ apt-get update $ apt-get install cloud-agent
> 
> This is a Ubuntu example, but the same goes for RHEL.
> 
> We would however need to host binary packages, are we allowed to do so
> on the ASF infra?
> 
> Otherwise I'm volunteering to provide space for this mirror.
> 
> It would really simplify a lot of things if we could have such a repository
> instead of having admins download all the seperate RPM or DEB packages
> manually.
> 
> I'm trying to get rid of:
> 
> $ tar xzf cloudstack-4.0.tar.gz
> $ cd cloudstack-4.0
> $ ./install.sh
> 
> Such install scripts do all kinds of "black magic" which the admin knows
> nothing about. I'm documenting all the steps an admin has to take to
> prepare, install and configure the management server and agent on RHEL
> (CentOS) or Ubuntu.
> 
> Do you guys see a benefit in this idea?
> 
> A couple of steps to be taken if we want this:
> * Space (Again, offering!)
> * Builds need to be uploaded, these have to be tested very well!
> * Signing of the builds, who does that?

That sounds like a great idea to me.

As far as I understand, we are allowed to host binaries on Apache infrastructure as long as
they are pure ASF-licensed software.  That means that our standard builds will be no problem
at all, but we wouldn't be able to host packages with optional features (e.g. NetApp or VMware
support) turned on.

We have special permission to ship builds that depend on libvirt-java (see LEGAL-144), so
we can host a second set of packages with KVM support enabled.  (This will not be necessary
after the September release of libvirt-java, because they have relicensed to MIT for us.)

Signing would be the same as for the official builds I guess.  John was collecting keys, IIRC.
 Maybe we should generate a CloudStack package signing key that we all sign.

Cheers,

Ewan.

Mime
View raw message