Skip to content
This repository has been archived by the owner on May 6, 2022. It is now read-only.

Build / push is painful if not using gcr and gke #67

Closed
krancour opened this issue Nov 30, 2016 · 4 comments
Closed

Build / push is painful if not using gcr and gke #67

krancour opened this issue Nov 30, 2016 · 4 comments

Comments

@krancour
Copy link
Contributor

It's been tough trying to get through the walkthrough on minikube. (And because I am working locally, I really only want to push built images to a local registry.) I think the difficulty I'm encountering exposes a fault that the build, push, and (helm) install are too tightly coupled to an (unfair) expectation that such Google services are being used.

I would propose that we abandon such assumptions and use a more generic option to allow users to simply specify a docker registry URL without any assumption that it is gcr.

@pmorie
Copy link
Contributor

pmorie commented Nov 30, 2016 via email

@martinmaly
Copy link
Contributor

I'd say that it is however important that it be possible to use build/push with registries commonly used. I.e. that it be possible to (easily) have make push into gcr (or any other registry). Specifically it means making it possible to authenticate against the registry so that the docker push command succeeds.

The goal, IMO, is ease of use and not requiring lot of manual steps to use the system.

It would be great to add support for other registries without degrading the experience with gcr, and ensuring that experience with other registries is equally easy, or even easier.

@krancour
Copy link
Contributor Author

krancour commented Nov 30, 2016

It can simply be stated as a pre-requisite that the user is authenticated to whatever registry they wish to push to. That's not unreasonable and it does not undermine ease of use for any registry-- gcr included.

I think one thing we really need to try and avoid here is boiling the ocean. I've spent most of my evening poring over the build / push process, scripts, etc. and it seems that so much of what was built, presumably as a convenience, makes lots of assumptions that make those same bits a hindrance for anyone who doesn't satisfy those assumptions. Personally, I'm inclined to say that less is more here.

@krancour
Copy link
Contributor Author

Closing, as I have replaced this with a more concrete proposal on how to move forward. See #77

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants