That's very nice and certainly needed, but it may be a problem - i.e. a commercial entity distributing Cloudstack binaries, depending on the bureaucracy at the moment, it could be at best an unofficial solution. /imho
-- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro ----- Original Message ----- > From: "Rohit Yadav" <rohit.ya...@shapeblue.com> > To: dev@cloudstack.apache.org > Sent: Tuesday, 14 October, 2014 12:05:48 > Subject: Re: CloudStack Mirrors > Hi, > > We think one issue with current CloudStack repositories and hosting locations > are that they are not very informative about what tag/commit was used to build > the deb/rpms, systemvmtemplate etc and if they are oss or non-oss/noredist or > if they were patched or built out of official CloudStack releases, and they > may > not host all the artifacts (templates, debs, rpms) since 4.0. > > ShapeBlue has a product patching service for their customers so we invested > some > time in last few weeks to build the infrastructure to solve these issues. To > host this publicly for everyone (and yes including the patch repositories, > since we try to do most of our work upstream and share our branches publicly > https://github.com/shapeblue/cloudstack), we’re working on having a dedicated > site/page that holds release notes and relevant information of all the things > that we’ll host. The infrastructure is reliable and pretty fast, soon we’ll be > able to add more nodes in other geographic locations and make it public. > > On 14-Oct-2014, at 3:43 pm, Leo Simons <lsim...@schubergphilis.com> wrote: >> On Oct 14, 2014, at 10:44 AM, Erik Weber <terbol...@gmail.com> wrote: >>> I'm not familiar with Apache policies in this regard, but is there any way >>> we could establish a set of official / supported mirrors that all answer on >>> the same DNS address? >>> I.e. so that we only have to document one url >> >> Typically the mirroring people use 302 redirects rather than DNS magic. >> >> Basically, to do it right, I think we should choose one route of >> >> 1. use existing apache mirror infrastructure >> * discuss with infrastructure@ the sanity of hosting systemvms on the >> existing >> mirrors, if ok, @see >> http://www.apache.org/info/how-to-mirror.html >> http://people.apache.org/~bodewig/mirror.html >> http://www.apache.org/dev/mirrors.html >> http://www.apache.org/dev/release-download-pages >> * release systemvms as actual/official apache artifacts >> * create a custom version of dyn.cgi/download.cgi if/as needed >> * update scripts to point at that CGI, i.e. >> >> http://www.apache.org/dyn/closer.cgi/cloudstack/releases/4.4.1/systemvm/systemvm-4.4.1.xen.bz2 >> >> 2. use existing sourceforge mirror infrastructure >> * release systemvms as semi-official binaries built from apache source >> * create a project on sourceforge >> * use the sourceforge mirror infrastructure >> * example of apache project doing this >> http://www.openoffice.org/download/index.html >> http://sourceforge.net/projects/openofficeorg.mirror/ >> * update scripts to point at that magic, i.e. >> curl -o systemvm-4.4.1.xen.bz2 -L >> >> http://sourceforge.net/projects/cloudstack.mirror/files/4.4.1/systemvm/systemvm-4.4.1.xen.bz2/download >> * tell infrastructure@ we are doing this just so they’re aware of the need >> and >> how we addressed it >> >> The problem with using the apache mirrors is that traditionally apache >> promises >> to keep the total repo somewhat size-limited. Lot of sites mirror apache (and >> fsf) because its 50GB or so, as opposed to the 100s of GBs you need to be a >> source forge or linux mirror. >> >> The OpenOffice approach is interesting because before becoming an apache >> project >> they had huge mirror infrastructure (built with mirrorbrain), some of which >> actually migrated to apache hardware IIRC with quite a bit of invested >> effort, >> but now it seems they abandoned that, and are just using sourceforge. So I >> suggest learning their lessons and doing the same. >> >> All the people around the world providing mirroring for open source projects >> will probably appreciate not having another thing to configure :) >> >> >> cheers, >> >> >> Leo >> > > Regards, > Rohit Yadav > Software Architect, ShapeBlue > M. +91 88 262 30892 | rohit.ya...@shapeblue.com > Blog: bhaisaab.org | Twitter: @_bhaisaab > > > > Find out more about ShapeBlue and our range of CloudStack related services > > IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//> > CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/> > CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> > CloudStack Infrastructure > Support<http://shapeblue.com/cloudstack-infrastructure-support/> > CloudStack Bootcamp Training > Courses<http://shapeblue.com/cloudstack-training/> > > This email and any attachments to it may be confidential and are intended > solely > for the use of the individual to whom it is addressed. Any views or opinions > expressed are solely those of the author and do not necessarily represent > those > of Shape Blue Ltd or related companies. If you are not the intended recipient > of this email, you must neither take any action based upon its contents, nor > copy or show it to anyone. Please contact the sender if you believe you have > received this email in error. Shape Blue Ltd is a company incorporated in > England & Wales. ShapeBlue Services India LLP is a company incorporated in > India and is operated under license from Shape Blue Ltd. Shape Blue Brasil > Consultoria Ltda is a company incorporated in Brasil and is operated under > license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by > The Republic of South Africa and is traded under license from Shape Blue Ltd. > ShapeBlue is a registered trademark.
