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

Add support for risc-v (and plan for platform addition in general) #502

Open
brandond opened this issue Oct 24, 2023 · 15 comments
Open

Add support for risc-v (and plan for platform addition in general) #502

brandond opened this issue Oct 24, 2023 · 15 comments
Labels
enhancement New feature or request

Comments

@brandond
Copy link
Member

brandond commented Oct 24, 2023

We are working in the background to add risc-v support to k3s at k3s-io/k3s#7151. However, one of the challenges of this effort is lack of risc-v platform support in rancher-mirrored images.

While we could simply add this to the arch list, this would change the multi-arch digest for any tags that we currently mirror that have this platform available. We should figure out how to add this platform to only new tags, in a way that is minimally disruptive to the list maintenance process, and can be reused when adding new platforms in the future.

One possibility would be to

  1. Add a new config file that tracks platform:start:end - where either or both start and end may be unspecified to indicate minimum and maximum values for the respective options.
  2. Existing platforms would be listed with an empty start and end date.
  3. Use the output of git blame --date=unix images-list to determine when an entry was added
  4. Add the platform to the list to be mirrored if the entry is newer than that platform's start date, and older than the end date

Note that we are evaluating when the entry was added to the list, NOT when the entry was published to the source registry. This approach should work as long as we continue to not modify existing list entries, such that git blame properly indicates the correct date for the addition of the entry.

@brandond
Copy link
Member Author

cc @superseb for thoughts

@superseb
Copy link
Contributor

Seems like the same issue as in #379 (comment), where we want to switch to sync all archs. First question to be answered is if we want to mirror archs that we don't "support" (if we want to combine efforts).

If yes, we can sync all archs and use a simpler approach like copying the current images-list at the moment we switch to determine if the image/tag needs the old or new approach.

If no, we need something as described in this issue. We could still simply copy the current images-list to images-list-before-risc and compare in the script if it's new or not. But I assume that having duplicated lists might not be what we want?

@brandond
Copy link
Member Author

Yeah I guess just mirroring all would be fine; I'm honestly not sure where the requirement to selectively mirror platforms came from, or if we need to retain it. I'd love to avoid creating multiple copies of the image list if at all possible; can you think of any pitfalls to using git blame to identify the entries that should observe the new behavior?

If that's not reliable (and I'm concerned it might not be) then perhaps we could just add a new optional field to the end of the list that would enable the new platform mirroring behavior.

@superseb
Copy link
Contributor

We can easily trial this, but I think it will be fine. What is the concern? I think we could actually just use that as the method to move to syncing all archs.

Running a quick test with a bash one liner on the current images-list and a randomly chosen epoch, I get good results on what images need old and new logic. If you can share the concerns I can test it some more.

@brandond
Copy link
Member Author

I guess I'm just concerned that using blame ties us to being exceptionally careful about never modifying existing rows. If something gets accidentally touched by a newer commit, it'll get promoted up to all arch. As long as we're careful I guess it should be ok.

@superseb
Copy link
Contributor

If we add a CI check for modifying existing rows as part of this, it should be good.

Copy link
Contributor

This repository uses an automated workflow to automatically label issues which have not had any activity (commit/comment/label) for 60 days. This helps us manage the community issues better. If the issue is still relevant, please add a comment to the issue so the workflow can remove the label and we know it is still valid. If it is no longer relevant (or possibly fixed in the latest release), the workflow will automatically close the issue in 14 days. Thank you for your contributions.

@brandond
Copy link
Member Author

brandond commented Jan 2, 2024

unstale. @superseb are you up for this, if not I'll take a shot.

@brandond brandond added enhancement New feature or request and removed status/stale labels Jan 2, 2024
Copy link
Contributor

github-actions bot commented Mar 3, 2024

This repository uses an automated workflow to automatically label issues which have not had any activity (commit/comment/label) for 60 days. This helps us manage the community issues better. If the issue is still relevant, please add a comment to the issue so the workflow can remove the label and we know it is still valid. If it is no longer relevant (or possibly fixed in the latest release), the workflow will automatically close the issue in 14 days. Thank you for your contributions.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Mar 18, 2024
@brandond
Copy link
Member Author

Bad stalebot.

@brandond brandond reopened this Mar 18, 2024
Copy link
Contributor

This repository uses an automated workflow to automatically label issues which have not had any activity (commit/comment/label) for 60 days. This helps us manage the community issues better. If the issue is still relevant, please add a comment to the issue so the workflow can remove the label and we know it is still valid. If it is no longer relevant (or possibly fixed in the latest release), the workflow will automatically close the issue in 14 days. Thank you for your contributions.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Jun 1, 2024
@brandond
Copy link
Member Author

brandond commented Jun 1, 2024

still in the backlog

@brandond brandond reopened this Jun 1, 2024
Copy link
Contributor

github-actions bot commented Aug 1, 2024

This repository uses an automated workflow to automatically label issues which have not had any activity (commit/comment/label) for 60 days. This helps us manage the community issues better. If the issue is still relevant, please add a comment to the issue so the workflow can remove the label and we know it is still valid. If it is no longer relevant (or possibly fixed in the latest release), the workflow will automatically close the issue in 14 days. Thank you for your contributions.

@brandond
Copy link
Member Author

brandond commented Aug 1, 2024

no

@henryys
Copy link

henryys commented Sep 13, 2024

unstale. @superseb are you up for this, if not I'll take a shot.

hi,brandond, i'm very care about this method,How is the progress of this adaptation work?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants