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

[Michael DeHaan]

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 at 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