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: [email protected] 
[mailto:[email protected]] On Behalf Of Paul Robert Marino
Sent: Sunday, April 27, 2014 2:59 PM
To: [email protected]
Subject: Re: [Spacewalk-list] Relationship between Spacewalk repo, channel, and 
metadata

On Sun, Apr 27, 2014 at 1:24 PM, Michael Snyder <[email protected]> 
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
> [email protected]
> https://www.redhat.com/mailman/listinfo/spacewalk-list

_______________________________________________
Spacewalk-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/spacewalk-list

_______________________________________________
Spacewalk-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/spacewalk-list

Reply via email to