different delivery formats

[Daniel P. Berrange]

On Mon, Feb 13, 2012 at 10:58:52AM +0000, Daniel P. Berrange wrote:
> On Mon, Feb 13, 2012 at 11:55:26AM +0100, Alan Pevec wrote:
> > On Mon, Feb 13, 2012 at 11:36 AM, Daniel P. Berrange
> > <berrange at redhat.com> wrote:
> > > I have a hard time accepting the argument that cloud disk images would
> > > be too big for mirrors. We're talking 100-200 MB per disk image typical.
> > > Even if we provided 3 formats, in two architectures we'd almost certainly
> > > be less than 1 GB in total size.
> > >
> > > Now look at Fedora 16 updates directory - 12 GB for x86_64, 12 GB for
> > > i386, and 9 GB for SRPMs.  So that's 33 GB of RPMs for Updates alone.
> > > Now the base release was another 73 GB. So for just RPMs, for 1 release
> > > of Fedora we're talking 100 GB.
> > >
> > > Our cloud images would be a mere 1% of the total Fedora size mirrors
> > > have to carry per release.
> > 
> > Do we care update updates i.e. update the image every time any package
> > inside gets updated ?
> > By looking at timestamps, Ubuntu's images[1] seem to be updated rather
> > frequently.
> 
> Hmm, yes, they do seem to get periodic updates, though not on a time
> based schedule. I wonder what criteria they use for doing updated
> images.

Followup thoughts.... what do we do for updates of the Fedora AMIs ?
Do the AMIs just live on GA forever, with end users expected to run
yum update after initial deployment ?

Seems that whatever we do with AMIs for updates, we should do for the
standalone images, and vica-verca.

So if we're only providing GA based AMIs, then we can do the same
for images initially.

For providing updates, we could follow a similar distribution policy
to the RPMs. ie the build system has archives of all historic image
builds, but the main download servers only ever show the GA image and
the most recently published update. This would limit disk usage on the
mirror servers, regardless of how frequently we issued updates

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|