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

Ability to use specific platform when generating ImagesLock #198

Open
gabegorelick opened this issue Dec 10, 2021 · 2 comments
Open

Ability to use specific platform when generating ImagesLock #198

gabegorelick opened this issue Dec 10, 2021 · 2 comments
Assignees
Labels
carvel accepted This issue should be considered for future work and that the triage process has been completed enhancement This issue is a feature request

Comments

@gabegorelick
Copy link

gabegorelick commented Dec 10, 2021

Describe the problem/challenge you have

kbld is often used to generate lockfiles that are passed to imgpkg to generate a bundle. When such a lockfile contains a multi-platform image index, the resulting imgpkg bundle will include all images in the index. This is great if you need to distribute the bundle to a lot of different platforms, but if you know the exact platform you're targeting then including all those other platform images in the bundle wastes a lot of space (Windows images in particular can be very large).

Describe the solution you'd like
kbld should be able to replace index references with specific images based on the desired platform (OS, architecture). That way, imgpkg won't bundle up unwanted images.

Anything else you would like to add:
Discussed in https://kubernetes.slack.com/archives/CH8KCCKA5/p1639157591175300


Questions:

  1. what should the UX be?
    • command-line args (e.g. --force-arch=X --force-platform=Y)
    • addition(s) to kind: Config
  2. should origins: include the platform/architecture supplied by the user? (more generally, should we include the total command-line used?)
  3. ...

Vote on this request

This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.

👍 "I would like to see this addressed as soon as possible"
👎 "There are other more important things to focus on right now"

We are also happy to receive and review Pull Requests if you want to help working on this issue.

@gabegorelick gabegorelick added carvel triage This issue has not yet been reviewed for validity enhancement This issue is a feature request labels Dec 10, 2021
@pivotaljohn pivotaljohn added priority/unprioritized-backlog Higher priority than priority/awaiting-more-evidence. Contributions are welcome. carvel accepted This issue should be considered for future work and that the triage process has been completed and removed carvel triage This issue has not yet been reviewed for validity labels Jan 4, 2022
@pivotaljohn
Copy link
Contributor

For use cases where both producing and deploying the artifacts are under the control of the same party, this seems particularly useful.

There are a number questions to flesh out before we begin (see description and Slack convo).

@cppforlife cppforlife removed the priority/unprioritized-backlog Higher priority than priority/awaiting-more-evidence. Contributions are welcome. label Apr 17, 2022
@cppforlife cppforlife self-assigned this Apr 17, 2022
@cppforlife
Copy link
Contributor

in progress: #234

@aaronshurley aaronshurley moved this to To Triage in Carvel Jul 25, 2022
@github-project-automation github-project-automation bot moved this to To Triage in Carvel Feb 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
carvel accepted This issue should be considered for future work and that the triage process has been completed enhancement This issue is a feature request
Projects
Status: To Triage
Development

No branches or pull requests

3 participants