-
Notifications
You must be signed in to change notification settings - Fork 55
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
add ostree-container upload support #359
Comments
Meh, we can probably start with hardcoding it in the Groovy for now?
Yeah, we don't have any yet. We'll have to set it up.
I think conceptually this should be part of the release job. I guess right after/in parallel with the OSTree import request (that code only runs for production builds of course, but the image push would just always run since there's no compose/prod distinction there). For mechanical streams like rawhide, the release job is automatically triggered by the build pipeline. |
I don't think I can hack on this due to https://pagure.io/centos-infra/issue/386 - anyone who has access who can take this issue? |
I pinged a few folks there. They're pretty responsive usually so let's give it a bit more time? |
This is the RHCOS version of coreos/fedora-coreos-config#1097 I was hoping to land this in FCOS first but I'm kind of blocked on that in coreos/fedora-coreos-pipeline#359, so let's settle for parallel. NOTE! This **does not change** the effect of `cosa upload-oscontainer` etc. Some discussion on that here: ostreedev/ostree-rs-ext#23 and I will file more issues related to that. However, what this *will* do is allow us to push this *additional* image arounnd and make `podman run registry.ci.openshift.org/rhcos/rhcos:4.8` e.g. work. In other words to start this will just be something *we* use to quickly inspect rhcos-as-container, not something we actually ship. (OK that's kind of a lie, it will end up in a place like e.g. http://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/pre-release/4.9.0-0.nightly-2021-07-20-014024/ instead of the existing `ostree.tar` so in theory other people outside of our group could run it too, but 🤫)
OK, I have cluster/jenkins access now. Does anyone know who owns https://quay.io/organization/coreos ? What do we need to create quay.io/coreos/fedora-coreos ? |
@bgilbert may have the necessary permissions, or otherwise definitely know who to contact (likely James). |
This is a bit hacky but should work. My initial goal here is just automated uploads of our builds, so that we can start getting a better feel for managing "ostree-in-container" releases. We should sync to `quay.io/coreos` but that needs someone to set that up. Also, I'd like to make the destination configurable in the same way as the S3 bucket, proposal PR in coreos/fedora-coreos-config#1175 Closes: coreos#359
This is a bit hacky but should work. My initial goal here is just automated uploads of our builds, so that we can start getting a better feel for managing "ostree-in-container" releases. We should sync to `quay.io/coreos` but that needs someone to set that up. Also, I'd like to make the destination configurable in the same way as the S3 bucket, proposal PR in coreos/fedora-coreos-config#1175 Closes: coreos#359
I have admin access to the org. Connect to VPN and file a ticket with my team and I'll sort it out. I guess I'll need everyone's Quay logins, and what level of access they should have. |
This is the RHCOS version of coreos/fedora-coreos-config#1097 I was hoping to land this in FCOS first but I'm kind of blocked on that in coreos/fedora-coreos-pipeline#359, so let's settle for parallel. NOTE! This **does not change** the effect of `cosa upload-oscontainer` etc. Some discussion on that here: ostreedev/ostree-rs-ext#23 and I will file more issues related to that. However, what this *will* do is allow us to push this *additional* image arounnd and make `podman run registry.ci.openshift.org/rhcos/rhcos:4.8` e.g. work. In other words to start this will just be something *we* use to quickly inspect rhcos-as-container, not something we actually ship. (OK that's kind of a lie, it will end up in a place like e.g. http://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/pre-release/4.9.0-0.nightly-2021-07-20-014024/ instead of the existing `ostree.tar` so in theory other people outside of our group could run it too, but 🤫)
This is the RHCOS version of coreos/fedora-coreos-config#1097 I was hoping to land this in FCOS first but I'm kind of blocked on that in coreos/fedora-coreos-pipeline#359, so let's settle for parallel. NOTE! This **does not change** the effect of `cosa upload-oscontainer` etc. Some discussion on that here: ostreedev/ostree-rs-ext#23 and I will file more issues related to that. However, what this *will* do is allow us to push this *additional* image arounnd and make `podman run registry.ci.openshift.org/rhcos/rhcos:4.8` e.g. work. In other words to start this will just be something *we* use to quickly inspect rhcos-as-container, not something we actually ship. (OK that's kind of a lie, it will end up in a place like e.g. http://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/pre-release/4.9.0-0.nightly-2021-07-20-014024/ instead of the existing `ostree.tar` so in theory other people outside of our group could run it too, but 🤫)
This is the RHCOS version of coreos/fedora-coreos-config#1097 I was hoping to land this in FCOS first but I'm kind of blocked on that in coreos/fedora-coreos-pipeline#359, so let's settle for parallel. NOTE! This **does not change** the effect of `cosa upload-oscontainer` etc. Some discussion on that here: ostreedev/ostree-rs-ext#23 and I will file more issues related to that. However, what this *will* do is allow us to push this *additional* image arounnd and make `podman run registry.ci.openshift.org/rhcos/rhcos:4.8` e.g. work. In other words to start this will just be something *we* use to quickly inspect rhcos-as-container, not something we actually ship. (OK that's kind of a lie, it will end up in a place like e.g. http://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/pre-release/4.9.0-0.nightly-2021-07-20-014024/ instead of the existing `ostree.tar` so in theory other people outside of our group could run it too, but 🤫)
I've been thinking about this and I think it should go to quay.io/fedora/coreos (i.e. not quay.io/coreos/fcos) - in keeping with this thread. |
WIP PR in #383 |
This is a bit hacky but should work. My initial goal here is just automated uploads of our builds, so that we can start getting a better feel for managing "ostree-in-container" releases. We should sync to `quay.io/coreos` but that needs someone to set that up. Also, I'd like to make the destination configurable in the same way as the S3 bucket, proposal PR in coreos/fedora-coreos-config#1175 Closes: coreos#359
This is a bit hacky but should work. My initial goal here is just automated uploads of our builds, so that we can start getting a better feel for managing "ostree-in-container" releases. We should sync to `quay.io/coreos` but that needs someone to set that up. Also, I'd like to make the destination configurable in the same way as the S3 bucket, proposal PR in coreos/fedora-coreos-config#1175 Closes: coreos#359
Part of coreos/fedora-coreos-tracker#812
Specifically this should build on coreos/fedora-coreos-config#1097
ostree-format: oci
quay.io/coreos/fedora-coreos:rawhide
Concerns:
The text was updated successfully, but these errors were encountered: