[Spacewalk-list] How to force a channel repodata rebuild?

[Jon Miller]

On Tue, May 7, 2013 at 6:50 AM, Tomas Lestach <tlestach at redhat.com> wrote:

> > So, about the regeneration of the repodata.... when I manually
> > removed the data and triggered the rebuild, the datetime
> > modification information on the files were the same as before I
> > removed the data.
>
> Do you mean repomd.xml, primary.xml.gz, ... ?
> Do you check it on the server or on the client?
>
My checks were always on the server side. When I re-checked yesterday, I
compared the contents of primary.xml, other.xml, filelists.xml and
repomd.xml. (Include below what I specifically did to check for any
differences[1])


>
> > It was as if the regeneration of the data was
> > using cached valued to reproduce the same data. It was only when we
> > make package changes to the channel that we actually got a "fresh"
> > repodata.
> >
> > This morning I took a closer look at the repodata, from a backup I
> > took prior to deleting it, and could not find any differences except
> > with the repomd.xml file that had updated timestamp and sha.
>
> So, here you write something different than above, when you wrote the
> datetime modification information on the files were the same.
>
Sorry, I was primarily focused on the other xml files because I was looking
for specific metadata concerning the libart_lgpl package. I'll include the
actual diff of the repomd.xml below[2].


> > Could
> > this imply something "else" was corrupted within Spacewalk? What
> > sort of metadata does SW store about the RPMs that reside in the
> > channels?
>
> We cache only the repodata parts for every rpm. When regenerating
> repodata, we put all the repodata rpm parts together (according to the
> channel rpms) and generate whole repodata files. All the files are
> newly created, so the modification dates shall be set accordingly.
>
> When I mentioned the contents of the repodata, after our initial removal
and triggering Spacewalk to rebuild it, looked identical along with
modification times, I am referring to the modification time as seen on the
filesystem via an "ls" command as well as what the Channel information
showed. Our incident was on May 2nd whereas the repodata for our
centos6.2-x86-64 channel was showing a modtime of April 22nd both before
and after the rebuild of the repodata. It was only after we removed a
package and then re-sync'ed the contents of the channel did we see an
updated modtime on the repodata and our issue disappeared.

Thanks,
Jon Miller

[1]: Commands used to compare old repodata vs. current:
mkdir tmp && cd tmp
tar -xzvf /tmp/repodata_20130502.tgz
 var/cache/rhn/repodata/centos6.2-x86_64
mv var/cache/rhn/repodata/centos6.2-x86_64 centos6.2-x86_64.bad
rm -rf var
cp -pr /var/cache/rhn/repodata/centos6.2-x86_64 centos6.2-x86_64.good
gunzip */*gz
sed -i -e 's/><package/>\n<package/g' -e 's/><file/>\n  <file/g' */*.xml
git diff --no-index --color-words *.bad/primary.xml *.good/primary.xml
git diff --no-index --color-words *.bad/other.xml *.good/other.xml
git diff --no-index --color-words *.bad/filelists.xml *.good/filelists.xml
git diff --no-index --color-words *.bad/repomd.xml *.good/repomd.xml # only
diff that produced output

[2]: Actual diff from the repomd.xml file
$ diff -u *.bad/repomd.xml *.good/repomd.xml
--- centos6.2-x86_64.bad/repomd.xml     2013-05-07 08:07:13.000000000 -0700
+++ centos6.2-x86_64.good/repomd.xml    2013-05-07 08:07:16.000000000 -0700
@@ -1,2 +1,2 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<repomd xmlns="http://linux.duke.edu/metadata/repo"><data
type="primary"><location href="repodata/primary.xml.gz"/><checksum
type="sha">63cc0cb94e9c0fbc958cafd73952ba02e612f239</checksum><open-checksum
type="sha">bba7811915fee90f9c6ae257ed10954731d70ac7</open-checksum><timestamp>1366682902</timestamp></data><data
type="filelists"><location href="repodata/filelists.xml.gz"/><checksum
type="sha">9fdb004ad90e60e5e34722e553faadac68fa28bd</checksum><open-checksum
type="sha">eef5c815e9978738055d25d5cb9bc272e0b3e146</open-checksum><timestamp>1366682902</timestamp></data><data
type="other"><location href="repodata/other.xml.gz"/><checksum
type="sha">6b928d9937c117b8d0d90171cdb7087b0a841556</checksum><open-checksum
type="sha">67d55b493f3d89bb62645aff637d98e6df3ac704</open-checksum><timestamp>1366682902</timestamp></data><data
type="group"><location href="repodata/comps.xml"/><checksum
type="sha">01beeafb865b9e6bcefc9b3272ebcb1a93e16da0</checksum><timestamp>1366682902</timestamp></data></repomd>
\ No newline at end of file
+<repomd xmlns="http://linux.duke.edu/metadata/repo"><data
type="primary"><location href="repodata/primary.xml.gz"/><checksum
type="sha">63cc0cb94e9c0fbc958cafd73952ba02e612f239</checksum><open-checksum
type="sha">bba7811915fee90f9c6ae257ed10954731d70ac7</open-checksum><timestamp>1367522246</timestamp></data><data
type="filelists"><location href="repodata/filelists.xml.gz"/><checksum
type="sha">9fdb004ad90e60e5e34722e553faadac68fa28bd</checksum><open-checksum
type="sha">eef5c815e9978738055d25d5cb9bc272e0b3e146</open-checksum><timestamp>1367522246</timestamp></data><data
type="other"><location href="repodata/other.xml.gz"/><checksum
type="sha">6b928d9937c117b8d0d90171cdb7087b0a841556</checksum><open-checksum
type="sha">67d55b493f3d89bb62645aff637d98e6df3ac704</open-checksum><timestamp>1367522246</timestamp></data><data
type="group"><location href="repodata/comps.xml"/><checksum
type="sha">01beeafb865b9e6bcefc9b3272ebcb1a93e16da0</checksum><timestamp>1367522246</timestamp></data></repomd>
\ No newline at end of file
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20130507/c26774f4/attachment.htm>