Re: repo management and snapshots
I thought a bit more on this..
On Thu, Sep 01, 2011 at 03:12:32PM -0400, Greg Chavez wrote:
On Tue, Aug 30, 2011 at 9:25 AM, Gerhardus Geldenhuis
<gerhardus.geldenhuis(a)gmail.com> wrote:
> Thanks for the response.
> I was also thinking about a sym link or hard link approach to save disk
> space. There is a cobbler hard link command mentioned on some of the online
> docs but this is not mentioned in the man page that I was reading but might
> be due to the version I am using.
The link things I have seen so far were all to be applied afterwards, so
one makes a copy and in cycles runs the job for hardlinking. Actually
having the links created directly would be nice, this would need fewer
ressources.
symlinks as well as hardlinks could be used.
symlinks:
pro: could also point to different filesystems
con: you can not freely remove the original tree that got 'snapshotted'
as symlinks could point here
hardlinks:
con: work only in one filesystem
pro: you can also remove the original tree, the rpm files stay until the
last reference is removed.
The repodata inside the repository that is beeing snapshotted would have
to be copied into the snapshot from what i see (or removed in the snapshot
to save space, and created inside the snapshot when required). This is
because the original repos contents can change, thus also the repodata.
> See this hard link flag made me wonder if
> there were already a solution in place. If I put some more thought into
> this... would this be something that is useful other people and could
> potentially be implemented more generically?
I have no real feeling how big the need is.
Basically what most people do currently is fill a repo specifically with
what they want to use, then deploy many servers using this repo. Same in
satellite terms: clone a channel, hook up the deployed servers to that.
Your idea is for a repo which can change randomly (i.e. hourly fresh
patches come in there) and whenever you deploy a server you want it to
use this channel - but for a redeployment get the server deployed with
the same state again.
Mostly the first of the two styles is used nowadays I guess.
cheers, Christian