[Spacewalk-list] Relationship between Spacewalk repo, channel, and metadata

[Michael Snyder]

Thank you Paul for the response...

I performed some trials with the following scenario:

- create repository EPEL.repo
- create channel EPEL1
  - associate EPEL.repo to channel EPEL1
- create channel EPEL2
  - associate EPEL.repo to channel EPEL2

Then I set up tcpdump captures collecting packets for the upstream repo provider address.

Spacewalk-repo-sync  of channel EPEL1 resulted in many gigabytes of data being retrieved from the upstream repo.  Inspection of the channel for package list shows all the expected RPMs for the channel.

Spacewalk-repo-sync of channel EPEL2 resulted in about 10 megabytes of data being retrieved from the upstream repo.  The process shows adding the thousands of RPM packages to the channel, but at a local-disk-speed rate (much faster than the sync of EPEL1).  Inspection of the channel for package list shows all the expected RPMs for the channel.

What I'd conclude is:
 + the Spacewalk "repository" is actually a "bucket-of-RPMs" that are associated with the channel.
 + actual repository metadata is maintained in the channel construct.
 + so a sync of channels with a common repository behind them will require, for each channel, a retrieval of repository metadata from the upstream source (and all of the attendant prerequisites of network availability, upstream host availability, etc.).

Is that a correct and reasonable representation of the relationship between Spacewalk channels and Spacewalk repositories?

Thanks,
Mike

-----Original Message-----
From: spacewalk-list-bounces at redhat.com [mailto:spacewalk-list-bounces at redhat.com] On Behalf Of Paul Robert Marino
Sent: Sunday, April 27, 2014 2:59 PM
To: spacewalk-list at redhat.com
Subject: Re: [Spacewalk-list] Relationship between Spacewalk repo, channel, and metadata

On Sun, Apr 27, 2014 at 1:24 PM, Michael Snyder <msnyder at digitalriver.com> wrote:
> Hello!
>
>
>
> This is a question I’ve tried to research against the code base and 
> existing documentation, but haven’t achieved the nirvana of enlightment.
>
>
>
> Spacewalk has the abstraction of a repository object, which can then 
> be linked to one or more channels within an organization (by way of “Channels”
> -> “Manage Software Channels” -> [specific-channel-link] -> 
> -> “Repositories”,
> select repositories by checkbox to be attached to the channel).
>
>
>
> The enlightenment I wish to find is:
>
> + when performing a channel synchronization, the operation follows the
> repository abstraction/container to the source (upstream) URL to 
> synchronize packages into Spacewalk.  This is good so far…
>
> + but when a repository abstraction/container is selected by multiple
> channels, each channel synchronization appears to follow the 
> repository upstream link and try to sync every time.
>
>
>
> What I’d like to know, if it’s possible:
>
> + to modify the spacewalk-repo-sync operation to selectively only 
> + follow the
> upstream package sync the first time.

? this question confuses me ?
Each sync operation only pulls in differentials not all of the packages.

>
> + subsequent channel synchronizations that reference a 
> + recently-updated
> repository accept that it was just updated, and only reference the 
> Spacewalk-local repository metadata to update the channel metadata.

If I get what you are saying here the answer is no it doesn't do that exactly.
For similar functionality you could implement through a cron job look at spacewalk-clone-by-date it can sync differentials between channels just leave out the -d option.
here is the man file online note
http://rpm.pbone.net/index.php3/stat/45/idpl/21735494/numer/8/nazwa/spacewalk-clone-by-date
the tool is part of the spacewalk-utils rpm

note: I'm not sure if it syncs package groups so you may want to sync off the parent channel once in a while just to get any updates to the comps.xml file but if you have already synced it via this method it should be a quick operation.


>
>
>
> Are there any insights to if this is possible, how it is invoked if it 
> is possible, or have a just taken a huge swing-and-a-miss on my part 
> because it already works the way I’ve described as desirable?
>
>
>
> Thanks,
>
> Mike
>
>
>
>
> _______________________________________________
> Spacewalk-list mailing list
> Spacewalk-list at redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list

_______________________________________________
Spacewalk-list mailing list
Spacewalk-list at redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list