Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Composing flatpaks does not work because they use a different repo name in Fedora #2658

Closed
bowlofeggs opened this issue Oct 9, 2018 · 3 comments
Labels
Crash Issues related to an unhandled crash High priority These issues are higher priority than normal

Comments

@bowlofeggs
Copy link
Contributor

@owtaylor and I tested a flatpak compose today in Bodhi's staging, and found that it fails to find the flatpak in the registry because it expects it to have the Fedora version prepended into the repository name:

[2018-10-09 16:31:31][bodhi.server   ERROR]f29-flatpak-updates-testing /usr/bin/bodhi-skopeo-lite copy docker://candidate-regi[10/215]g 
.stg.fedoraproject.org/f29/flatpak-runtime:f29-20181008180041.2 returned a non-0 exit code: 1g 
[2018-10-09 16:31:31][bodhi.server   ERROR]f29-flatpak-updates-testingg
Traceback (most recent call last):g 
  File "/usr/bin/bodhi-skopeo-lite", line 11, in <module>g 
    load_entry_point('bodhi-server==3.10.0', 'console_scripts', 'bodhi-skopeo-lite')() 
  File "/usr/lib/python2.7/site-packages/click/core.py", line 722, in __call__g                     
    return self.main(*args, **kwargs)g 
  File "/usr/lib/python2.7/site-packages/click/core.py", line 697, in maing 
    rv = self.invoke(ctx) 
  File "/usr/lib/python2.7/site-packages/click/core.py", line 1066, in invokeg 
    return _process_result(sub_ctx.command.invoke(sub_ctx))g  
  File "/usr/lib/python2.7/site-packages/click/core.py", line 895, in invokeg 
    return ctx.invoke(self.callback, **ctx.params)g 
  File "/usr/lib/python2.7/site-packages/click/core.py", line 535, in invokeg 
    return callback(*args, **kwargs)g 
  File "/usr/lib/python2.7/site-packages/bodhi/server/scripts/skopeo_lite.py", line 768, in copyg 
    Copier(src.get_endpoint(), tmp).copy()g 
  File "/usr/lib/python2.7/site-packages/bodhi/server/scripts/skopeo_lite.py", line 726, in copyg 
    info = self.src.get_manifest()g 
  File "/usr/lib/python2.7/site-packages/bodhi/server/scripts/skopeo_lite.py", line 633, in get_manifestg 
    return get_manifest(self.session, self.repo, self.tag)g 
  File "/usr/lib/python2.7/site-packages/bodhi/server/scripts/skopeo_lite.py", line 345, in get_manifestg 
    response.raise_for_status()g 
  File "/usr/lib/python2.7/site-packages/requests/models.py", line 935, in raise_for_statusg 
    raise HTTPError(http_error_msg, response=self)g 
requests.exceptions.HTTPError: 404 Client Error: Not Found for url: https://candidate-registry.stg.fedoraproject.org/v2/f29/flatpak-rug 
ntime/manifests/f29-20181008180041.2g

The URL should not have had that f29/ added before flatpak-runtime, but that is hardcoded into Bodhi since containers have it.

@owtaylor suggested that we could use the Koji metadata to know the name of the registry repository instead of hardcoding it. For example, https://koji.stg.fedoraproject.org/koji/buildinfo?buildID=1137170 tells us that candidate-registry.stg.fedoraproject.org/flatpak-runtime:f29-20181008180041.2 is a pull URL. This works for containers too:

koji call getBuild cockpit-176-5.fc28
{'build_id': 1141835,
 'completion_time': '2018-09-04 13:38:12',
 'completion_ts': 1536068292.0,
 'creation_event_id': 36252316,
 'creation_time': '2018-09-04 13:38:15.365648',
 'creation_ts': 1536068295.36565,
 'epoch': None,
 'extra': {'container_koji_task_id': 29485206,
           'image': {'autorebuild': False,
                     'help': None,
                     'index': {'digests': {'application/vnd.docker.distribution.manifest.list.v2+json': 'sha256:2bd64a888535a6b0428a3cfcaa4aa7cec5dd3e3bbb4ed84e315e985e2d5c6bb5'},
                               'pull': ['candidate-registry.fedoraproject.org/f29/cockpit@sha256:2bd64a888535a6b0428a3cfcaa4aa7cec5dd3e3bbb4ed84e315e985e2d5c6bb5',
                                        'candidate-registry.fedoraproject.org/f29/cockpit:176-5.fc28'],
                               'tags': ['latest', '176', '176-5.fc28']},
                     'isolated': False,
                     'parent_image_builds': {'registry.fedoraproject.org/fedora:29': None}},
           'submitter': 'containerbuild'},
 'id': 1141835,
 'name': 'cockpit',
 'nvr': 'cockpit-176-5.fc28',
 'owner_id': 3998,
 'owner_name': 'cverna',
 'package_id': 17959,
 'package_name': 'cockpit',
 'release': '5.fc28',
 'source': 'https://src.fedoraproject.org/container/cockpit.git#851196158dc74a4ba970c1024bde58be86d49f25',
 'start_time': '2018-09-04 13:17:46',
 'start_ts': 1536067066.0,
 'state': 1,
 'task_id': None,
 'version': '176',
 'volume_id': 0,
 'volume_name': 'DEFAULT'}
@bowlofeggs bowlofeggs added High priority These issues are higher priority than normal Crash Issues related to an unhandled crash labels Oct 9, 2018
owtaylor added a commit to owtaylor/bodhi that referenced this issue Oct 9, 2018
Instead of hardcoding that a registry image is at <release>/<name>,
look it up via the registry metadata that OSBS writes.

Fixes fedora-infra#2658
owtaylor added a commit to owtaylor/bodhi that referenced this issue Oct 9, 2018
Instead of hardcoding that a registry image is at <release>/<name>,
look it up via the registry metadata that OSBS writes.

Fixes fedora-infra#2658

Signed-off-by: Owen W. Taylor <otaylor@fishsoup.net>
bowlofeggs pushed a commit to owtaylor/bodhi that referenced this issue Oct 23, 2018
Instead of hardcoding that a registry image is at <release>/<name>,
look it up via the registry metadata that OSBS writes.

Fixes fedora-infra#2658

Signed-off-by: Owen W. Taylor <otaylor@fishsoup.net>
bowlofeggs pushed a commit to owtaylor/bodhi that referenced this issue Oct 23, 2018
Instead of hardcoding that a registry image is at <release>/<name>,
look it up via the registry metadata that OSBS writes.

Fixes fedora-infra#2658

Signed-off-by: Owen W. Taylor <otaylor@fishsoup.net>
owtaylor added a commit to owtaylor/bodhi that referenced this issue Oct 31, 2018
Instead of hardcoding that a registry image is at <release>/<name>,
look it up via the registry metadata that OSBS writes.

Fixes fedora-infra#2658

Signed-off-by: Owen W. Taylor <otaylor@fishsoup.net>
owtaylor added a commit to owtaylor/bodhi that referenced this issue Nov 5, 2018
Instead of hardcoding that a registry image is at <release>/<name>,
look it up via the registry metadata that OSBS writes.

Fixes fedora-infra#2658

Signed-off-by: Owen W. Taylor <otaylor@fishsoup.net>
@mergify mergify bot closed this as completed in #2659 Nov 5, 2018
mergify bot pushed a commit that referenced this issue Nov 5, 2018
Instead of hardcoding that a registry image is at <release>/<name>,
look it up via the registry metadata that OSBS writes.

Fixes #2658

Signed-off-by: Owen W. Taylor <otaylor@fishsoup.net>
@bowlofeggs
Copy link
Contributor Author

This feature is planned for inclusion in the upcoming 3.11.0 release: #2709

@bowlofeggs
Copy link
Contributor Author

This patch has been deployed to Bodhi's staging environment:

https://bodhi.stg.fedoraproject.org

Please test and let us know if you find issues!

@bowlofeggs
Copy link
Contributor Author

This fix is now deployed to Fedora's production instance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Crash Issues related to an unhandled crash High priority These issues are higher priority than normal
Projects
None yet
Development

No branches or pull requests

1 participant