David Lutterkort wrote:
On Thu, 2007-05-17 at 11:55 -0400, Michael DeHaan wrote:
Basically we want to make it easier to create channels, to mirror
existing channels, to add software to channels, to compose channels, and
to control access of what computers (or profiles, etc) have access to
what channels.
That would be really useful. Having used mrepo some, which addresses
similar use cases, my two biggest problems with it are (1) mirrors are
flaky, and switching mirrors requires editing the mrepo config (2) mrepo
is file-based, not package-based; that makes defining what exactly to
mirror cumbersome and fragile.
As brought up a bit in the notes, from talking with many larger
datacenter admins, some additional tooling is needed
to control what packages get slurped in (not just everything/latest) as
well as being able to snapshot
mirrors at points in time for testing and then deployment. It seems a
lot of these tools are written in house around
existing things like yum-utils, and the same philosophy of "can't we all
share this effort" applies as it did with Cobbler I think.
It's not that these tools themselves are exceedingly complex, but that
unifying glue to simplify them (and make such code available
to higher level applications also) would be a huge bonus.
One approach would be to define a 'channel' through a (partial)
kickstart file, one that just has repo statements and a %packages
section, with the resulting package set being the (partially) depclosed
set of packages from the repos for that channel; might be that the %
packages syntax for kickstart needs to be amended to accomodate all the
ways in which people want to compose channels, but that will have to be
seen.
In addition, there's a lot of overlap with existing yum-utils; it would
definitely be good to avoid code duplication with them, instead
extending/refactoring as much as possible. As an example, yum doesn't
deal with rsync URL's right now. If that is needed for this mirroring
tool, it should be added to yum instead of using mirroring-specific
code.
Agreed, and in fact, intended.
We all see this being heavily reliant on yum-utils, particularly
reposync, and yumdownloader (and also, obviously, createrepo). What is
needed is some good glue that unites all of this (which ultimately ends
up being fairly simple), though also there is some need for software to
do things like manage errata (updating just parts of things) and be able
to control who has access to what software -- some of which isn't doable
in yum-utils today. This might speak yum API for greater flexibility
in some areas.
There's some obvious overlap with mirror manager, too [1], especially
when it comes to describing what is being mirrored; not sure how much of
what's described on that page is implemented currently.
This too, possibly ... https://hosted.fedoraproject.org/projects/bodhi ...
One of the primary goals here is to get something that is well
supportive of older OS's as well and also command line + API tools that
can easily integrate with things like cobbler + virt-factory.
A lot of tools like this seem to be web apps, which presents a problem
for adminstrative scripting and integration in tools like
Virt-Factory. There isn't too much need
of a web app specifically here (you can't put a web app on cron), but
that doesn't preclude one from existing. However approaching these
projects on combining efforts
is definitely a good thing to do.
David
[1] http://fedoraproject.org/wiki/Infrastructure/MirrorManagement
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
I think it was posted earlier, but if not, we have a mockup manpage in
git (thanks to Máirín Duffy)
*http://tinyurl.com/2uyvzg*
There are also some meeting notes from one of our earlier meetings,
though these have evolved some since...
http://et.redhat.com/page/Surfr-notes-18-May-2007
Anyhow, more comments/feedback welcome.
--Michael
