I think we got our wires crossed in early development. The way that a module build depends on pdc to get the deps of a module seems unnecessary. We should try to reduce that complexity.
Do you mean we could get them from module metadata directly?
I do... but @psabata pointed out after I filed this card that the whole reason we did the PDC interaction was to give us a way to flexibly specify the tag name (instead of hardcoding a convention).
We should think a little more about this card, but maybe end up closing it as WONTFIX.
In trying to get rida working for the base-runtime team, I disabled the code in rida that queries PDC for deps and the koji tag (pdc-updater was failing to get the information in to PDC, so the whole build process would fail).
We should restore that code in rida (just with a git checkout -p on the dev instance).
git checkout -p
Then, we need to fix whatever bug is in pdc-updater or PDC that was causing the propagation to fail.
The pdc-updater expects commit hash in the scm_url, but it is not present there for base-runtime module. The question is whether we should build using the latest commit in this case or just fail to accept that build in Orchestrator.
Oh, that makes sense. Good find.
There's code in rida that allows it to just take the latest commit if no ref is specified. I saw this and started using it, but let's remove that code and disallow it. Better to be explicit, I think.
Meh, my comment didn't make it, apparently. Typing it again...
So to clarify what my idea on how this should work is:
1) the module "NVR"-to-tagname naming policy lives in pdc-updater 2) rida should query PDC for tagnames for both the module currently being built as well as its dependencies; without this, if the naming policy changes, rida wouldn't be able to use modules/tagnames created while the old policy was in place 3) rida shouldn't query PDC for module dependency trees, it has all that data in the modulemd file; the reason why we are storing these trees in PDC is that the currently stil nonexistent module-rebuilding service would have a way to find out what modules need to be rebuilt if another module they depend on or include has changed
Thanks everyone. Closing this as wontfix. We'll keep things the way they are.
@ralph changed the status to Closed
Closed
Login to comment on this ticket.