-
Notifications
You must be signed in to change notification settings - Fork 17
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 support for querying OCI graph #99
Conversation
It's confusingly named `stream_metadata_url` but actually is the URL to the update guidance.
Found this helpful in debugging.
Currently, we're starting a total of N x M scrapers, where N is the number of streams, and M the number of arches. So right now, this would be 3 x 4 = 12 scrapers. This is very wasteful because each scraper individually downloads the release index and update metadata every 30 seconds, even though that metadata is not different per architecture. I think the reason it was set up this way is in case we wanted to host separate e.g. release index or update files _per_ architecture in S3 instead of all together. This can be seen by the fact the code supports templating those URLs with `basearch`. However, it's unlikely we'll be changing that design decision, so let's just do the saner thing and rework the scraping to be stream-based. This is done by changing the scraper to host not one single `Graph` object, but instead a `HashMap<String, Graph>` which maps architectures to graphs. Then, when a request for a graph comes in, we lookup in our cache keying off of the requested architecture. This is prep for adding another dimension to the matrix, which is whether the OCI version of the graph was requested. If we didn't do this cleanup first, it would have blown up the number of scrapers to 24. Part of coreos/fedora-coreos-tracker#1823.
When parsing the release index, check for the new `oci-images` key. If present, also build up a separate graph with only nodes containing OCI information. In that case, the node payload is the pullspec and the scheme declared in the node metadata is `oci`. When a client requests a graph, check if the `oci=` URL parameter was set. If so, return back the OCI graph instead of the OSTree one. Part of coreos/fedora-coreos-tracker#1823.
This is a mix of both new and old clippy warnings. Just doing it in one commit to make it easier.
To be clear, this doesn't technically require OCI metadata to be present in the release index (by design it must be compatible with existing metadata). I will say that this could've been done more cleanly. I can imagine abstracting a bit more between the two types of graphs to make the code nicer. But OTOH, I don't think it's useful to spend too much time on this repo. |
I think as a way to review this, someone else should probably stand it up locally and test with local release index metadata like I did. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a very trivial LGTM from my side. My expertise in Rust is embarassingly miniscule.
Add a configuration knob in `update` to optionnaly use OCI pullspec instead of ostree checksums. This will default to false. Requires coreos/fedora-coreos-cincinnati#99 and coreos/rpm-ostree#5120
Add a configuration knob in `update` to optionnaly use OCI pullspec instead of ostree checksums. This will default to false. Requires coreos/fedora-coreos-cincinnati#99 and coreos/rpm-ostree#5120
Add a configuration knob in `update` to optionnaly use OCI pullspec instead of ostree checksums. This will default to false. Requires coreos/fedora-coreos-cincinnati#99 and coreos/rpm-ostree#5120
Parse rpm-ostree status to detect if the current booted deployment is an OCI image. If so, query the OCI graph for cincinnati and rebase to the correct OCI image. Requires coreos/fedora-coreos-cincinnati#99 and coreos/rpm-ostree#5120 Part of: coreos/fedora-coreos-tracker#1823
Parse rpm-ostree status to detect if the current booted deployment is an OCI image. If so, query the OCI graph for cincinnati and rebase to the correct OCI image. Requires coreos/fedora-coreos-cincinnati#99 and coreos/rpm-ostree#5120 Part of: coreos/fedora-coreos-tracker#1823
Parse rpm-ostree status to detect if the current booted deployment is an OCI image. If so, query the OCI graph for cincinnati and rebase to the correct OCI image. Requires coreos/fedora-coreos-cincinnati#99 and coreos/rpm-ostree#5120 Part of: coreos/fedora-coreos-tracker#1823
Parse rpm-ostree status to detect if the current booted deployment is an OCI image. If so, query the OCI graph for cincinnati and rebase to the correct OCI image. Requires coreos/fedora-coreos-cincinnati#99 and coreos/rpm-ostree#5120 Part of: coreos/fedora-coreos-tracker#1823
Cincinnati now serves a separate graph for OCI images, since coreos/fedora-coreos-cincinnati#99 Allow displaying the oci graph by passing `oci=true` as a query parameter. See coreos/fedora-coreos-tracker#1823
Cincinnati now serves a separate graph for OCI images, since coreos/fedora-coreos-cincinnati#99 Allow displaying the oci graph by passing `oci=true` as a query parameter. See coreos/fedora-coreos-tracker#1823
When parsing the release index, check for the new
oci-images
key. Ifpresent, also build up a separate graph with only nodes containing OCI
information. In that case, the node payload is the pullspec and the
scheme declared in the node metadata is
oci
.When a client requests a graph, check if the
oci=
URL parameter wasset. If so, return back the OCI graph instead of the OSTree one.
Part of coreos/fedora-coreos-tracker#1823.