[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [et-mgmt-tools] What do you want in yum/channel management tools?



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 redhat com
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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]