Skip to content
This repository has been archived by the owner on Aug 12, 2024. It is now read-only.

Update the image source to not be Kubernetes-centric #673

Open
everettraven opened this issue Aug 3, 2023 · 2 comments
Open

Update the image source to not be Kubernetes-centric #673

everettraven opened this issue Aug 3, 2023 · 2 comments
Labels
lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale.

Comments

@everettraven
Copy link
Contributor

Currently, the image source for unpacking bundle images requires the use of Kubernetes and embeds a lot of, likely unnecessary, Kubernetes specific logic and parameters. The concept of unpacking from bundle images shouldn't rely on the use of Kubernetes and require parameters to adhere to Kuberneteisms.

As an example of why one might not want to require the use of Kubernetes for unpacking the bundle contents, consider a case where someone would like to create a CLI for unpacking bundle contents locally (although currently not feasible due to the unexported unpacking library, but there are various issues that would cause this library to be exported in the future). It doesn't make sense to force someone to have access to a Kubernetes cluster for unpacking the image locally when something like Docker/Podman could be used - or even a Go library such as https://github.com/containers/image or https://github.com/google/go-containerregistry.

@joelanford
Copy link
Member

There are two facets here, I think:

  1. The image source might still have access to a Kubernetes client to create a pod in a cluster to do the unpacking. However, it is not technically necessary for the image source itself to have knowledge of any potential related objects (e.g. the bundle that initiated the unpacking) to be able to actually unpack the bundle.
  2. We can completely remove Kubernetes-isms by changing the image source to talk directly to an image repository.

If we do (2), then (1) is moot because we're no longer creating a pod.

If we do just (1), then we may need to decide how important it is to set an owner reference on the unpack pod and whether there's a way to do it without leaking Kubernetes details in the Unpack abstraction.

@github-actions
Copy link

github-actions bot commented Oct 3, 2023

This issue has become stale because it has been open 60 days with no activity. The maintainers of this repo will remove this label during issue triage or it will be removed automatically after an update. Adding the lifecycle/frozen label will cause this issue to ignore lifecycle events.

@github-actions github-actions bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Oct 3, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale.
Projects
None yet
Development

No branches or pull requests

2 participants