#2788 Kojira and tag inheritance
Closed: Dropped 2 years ago by alexi. Opened 3 years ago by alexi.

We have a relatively complicated tag inheritance setup for our user's Koji tags:

Screenshot_2021-03-26_14-46-52.png

When we update the external repos assigned to centos8-defaults, we see that kojira does a regen-repo on it, as you would expect. However, user builds on mytag8-build will fail due to old metadata until we manually run a regen-repo on it. Is this supposed to happen, or is this something that kojira should be handling as well? Should we just script something to run regen-repo on all *-build tags after we update the external repos?


Metadata Update from @tkopecek:
- Custom field Size adjusted to None
- Issue set to the milestone: 1.26

3 years ago

It looks weird - it definitely should trigger newRepo for mytag8-build. Isn't it just a repo with much lower priority, so it get regenerated later? You can check the kojira.log if it appears there. (and/or enable --queue-file to see repo regen ordering)

No, I don't see it getting regenerated later either. I tried enabling --queue-file but it just seems to create a file with a single line: Tag Expired Score.

So the situation is:

  • mytag8-build inherits from centos8-defaults
  • centos8-defaults has external repos associated with it
  • updates to those external repos triggers a regen for centos8-defaults, but not mytag8-build

Are you sure that it was the external repo change that triggered the regen?

Are you seeing lines like Repo %i no longer current due to external repo change in kojira.log?

Yes, I do see lines like that, but I can't figure out what repo they refer to to see what it's really doing.

See what the current repo id for mytag8-build is (the taginfo command will show the number), and see if there is a kojira log line like that for that repo.

No, there's no line for mytag8-build in the kojira logs.

We have a script that basically does the same thing kojira's check_external_repos does now, so we may be launching regen-repos before kojira has a chance to. I've disabled our script to see if somehow that's interfering with kojira. Our script would regen centos8-defaults but not mytag8-build because it wasn't inheritance-aware.

It seems it was actually our script that was regening centos8-defaults, without it kojira didn't do it on it's own. Could this be related to the fact that the external repos are in merge mode bare? I do see kojira working as it should on our Centos 7 tags, but those are set up with no inheritance and koji external repos.

@alexi Sorry for long silence. I've now time to look at it. Dumb question - is external repo checking enabled in config? (We don't do that by default because of potentially broken external repodata).

check_external_repos = True

Second thing - database needs to use UTC - otherwise time comparisons could be off.

Yes, check_external_repos is enabled and I'm running 1.24.1, which IIRC already has the UTC fixes.

Hmm, I've tried to replicate this concrete structure (with some local-served repo) and it works correctly. Maybe it is not related to external repo at all. Can you try to tag some build into mytag8-build directly and see if repo gets regenerated?

One case comes to my mind but that also seems unlikely - it mytag8-build is not used in any target, it will be ignored. But you've tried some builds against it so evidently it is not the case.

Yes, building a package to mytag8-build does regenerate the repo as it should.

The issue is when the external repos of centos8-defaults change, that gets regenerated but the tags that inherit it do not, so builds in mytag8-build fail because they're still looking for the old contents of the external repos.

What about "Check external repo ... for tag <id>" with same id from taginfo mytag8-build. Or more generally, is there that id at all refrenced anywhere in kojira.log with debug turned on?

Metadata Update from @tkopecek:
- Issue set to the milestone: None (was: 1.26)

2 years ago

I'm not entirely sure because I added some external workarounds just in case it happened again. Since nobody else seems to have this issue, I guess we can close it.

Metadata Update from @alexi:
- Issue close_status updated to: Dropped
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.

Metadata
Attachments 1