Now that MBS is back in action (https://pagure.io/releng/issue/10850), I tried to kick off some flatpak builds, but it looks like something has regressed and the container builds no longer work:
$ fedpkg flatpak-build Created task: 89457822 Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=89457822 Watching tasks (this may be safely interrupted)... 89457822 buildContainer (noarch): free 89457822 buildContainer (noarch): free -> FAILED: Fault: <Fault 2001: 'Image build failed. Error in plugin resolve_module_compose: 401 Client Error: Unauthorized for url: https://odcs.fedoraproject.org/api/1/composes/. OSBS build id: flatpak-runtime-f36-8fbe6-6'> 0 free 0 open 0 done 1 failed 89457822 buildContainer (noarch) failed
Is
hi @kalev ,
Could you retest and give us the feedback in this ticket if the issue persist?
Metadata Update from @phsmoura: - Issue priority set to: Waiting on Assignee (was: Needs Review) - Issue tagged with: high-gain, high-trouble, ops
Hi @phsmoura,
I just retested it and it's still failing exactly the same way:
$ fedpkg flatpak-build Created task: 89468957 Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=89468957 Watching tasks (this may be safely interrupted)... 89468957 buildContainer (noarch): free 89468957 buildContainer (noarch): free -> FAILED: Fault: <Fault 2001: 'Image build failed. Error in plugin resolve_module_compose: 401 Client Error: Unauthorized for url: https://odcs.fedoraproject.org/api/1/composes/. OSBS build id: flatpak-runtime-f36-8fbe6-7'> 0 free 0 open 0 done 1 failed 89468957 buildContainer (noarch) failed
If you want to test it yourself, you should be able to reproduce it with:
fedpkg clone modules/flatpak-runtime cd flatpak-runtime git checkout f36 fedpkg flatpak-build
@abompard could this be a ipsilon issue?
I know odcs is using openidc...
I am not super fresh on this but I think we are using an authentication token for odcs and it might have expired.
https://pagure.io/fedora-infra/ansible/blob/main/f/playbooks/groups/osbs/setup-orchestrator-namespace.yml#_40 https://pagure.io/fedora-infra/ansible/blob/main/f/playbooks/groups/osbs/setup-worker-namespace.yml#_23
I had a How To about this https://pagure.io/fedora-infra/howtos/blob/main/f/refresh_osbs_odcs_oicd_token.md
But not sure how much has changed with the new authentication system, but that can be a good starting point.
I have regenerating the comment according to @cverna's instructions and redeployed it, could you test again please @kalev?
Thanks, @abompard!
Looks like it didn't help, still the same error:
$ fedpkg flatpak-build Created task: 89535768 Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=89535768 Watching tasks (this may be safely interrupted)... 89535768 buildContainer (noarch): free 89535768 buildContainer (noarch): free -> FAILED: Fault: <Fault 2001: 'Image build failed. Error in plugin resolve_module_compose: 401 Client Error: Unauthorized for url: https://odcs.fedoraproject.org/api/1/composes/. OSBS build id: flatpak-runtime-f36-8fbe6-9'> 0 free 0 open 0 done 1 failed 89535768 buildContainer (noarch) failed
On IRC kalev reported that it still does not work. I think I found why: the token generated by scripts/generate-oidc-token is linked to the osbs client ID, but this client ID is not declared in Ipsilon (files/ipsilon/openidc.{{env}}static). As a result Ipsilon invalidates it with its cleanup procedures.
scripts/generate-oidc-token
osbs
files/ipsilon/openidc.{{env}}static
I've added the osbs client in Ipsilon's config and re-added the generated token, it should work now. Could you test please @kalev?
I should add that there's a better way to do this with regards to OIDC authentication, but there may be very valid reasons to generate tokens this way, I don't know how OSBS works or is deployed. The proper way would be to: - deploy a kerberos keytab on the host(s) where OSBS are run - have the osbs client authenticate to Ipsilon with this kerberos keytab - Store the token that Ipsilon will return after authentication - Use this token to access the server API, just as the current token is used today.
Worked this time! Thanks a lot for figuring this out.
Metadata Update from @kalev: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Hum, I checked and the token seemed to have been updated correctly.
@abompard could you check the git diff of the token in the private repo, to see if you spot anything weird?
Metadata Update from @cverna: - Issue status updated to: Open (was: Closed)
@cverna did you mean to re-open the ticket?
Oops no, I just edited my comment to fix a typo.
Metadata Update from @cverna: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.