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

auto update without registry on local images #9088

Closed
vrothberg opened this issue Jan 25, 2021 · 7 comments
Closed

auto update without registry on local images #9088

vrothberg opened this issue Jan 25, 2021 · 7 comments
Assignees
Labels
In Progress This issue is actively being worked by the assignee, please do not work on this at this time. kind/feature Categorizes issue or PR as related to a new feature. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.

Comments

@vrothberg
Copy link
Member

/kind feature

Description

After a private chat with a user on auto updates, it became clear that auto updates could also be applied without having a container registry. For instance, when images built locally, the use case remains the same. Currently, auto updates only work when the image on the remote registry has changed.

There a couple of things to think about:

  • Currently, containers configured for auto updates must use fully-qualified image references. Short names are not supported. Should this change? It seems very common to just use short names locally.
  • Should we introduce a new auto-update policy? Currently it's called "image" (and maybe should be aliased to "registry"). The local one could be called "local". Then we could easily support short names.

@fatherlinux @mrguitar ... do you have feedback suggestions?

@openshift-ci-robot openshift-ci-robot added the kind/feature Categorizes issue or PR as related to a new feature. label Jan 25, 2021
@mrguitar
Copy link

The majority of the "production" use cases seem to prefer separating builds from runtime environments. That said, I like this idea and it seems really useful for certain types of use cases. This would be valuable for my home systems and I can see other development-ish use cases where this would be helpful.

Agreed that short names are common for local use. I don't have a strong opinion on good options here, but would requiring "localhost/[name]" be an acceptable compromise? requiring a local policy feels cumbersome, but it's possible that's a better option.

@fatherlinux
Copy link
Contributor

+1 Ben. Also, since we have the secure short names feature now (or will), I think this could probably be done in a way has defense in depth and prevents an attack from a man in the middle.

I could also see this being used in an environment with really slow internet connection. It might be cheaper to deliver a Dockerfile/Containerfile out and have the image build from some local cache of packages. It's probably an edge case, but could be really convenient if you happen to be a user with that edge case.

@github-actions
Copy link

A friendly reminder that this issue had no activity for 30 days.

@rhatdan
Copy link
Member

rhatdan commented Mar 1, 2021

@vrothberg Is this is issue you wanted @ParkerVR to look at?

@ParkerVR
Copy link
Collaborator

ParkerVR commented Mar 1, 2021

@rhatdan touched based with @vrothberg on this and will discuss more in depth tmmr

@ParkerVR ParkerVR self-assigned this Mar 2, 2021
@github-actions
Copy link

github-actions bot commented Apr 2, 2021

A friendly reminder that this issue had no activity for 30 days.

@ParkerVR ParkerVR added the In Progress This issue is actively being worked by the assignee, please do not work on this at this time. label Apr 15, 2021
@ParkerVR ParkerVR linked a pull request Apr 20, 2021 that will close this issue
@ParkerVR ParkerVR removed a link to a pull request Apr 20, 2021
@vrothberg
Copy link
Member Author

Implemented in #10063.

@github-actions github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Sep 22, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 22, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
In Progress This issue is actively being worked by the assignee, please do not work on this at this time. kind/feature Categorizes issue or PR as related to a new feature. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.
Projects
None yet
Development

No branches or pull requests

6 participants