Skip to content
This repository has been archived by the owner on Mar 28, 2020. It is now read-only.

Deploying a cluster with different repository/version fails on pull #1960

Open
carlosedp opened this issue May 4, 2018 · 3 comments
Open

Comments

@carlosedp
Copy link

I'm deploying an etcd-operator on ARM64 (compiled and built my own images) but when trying to deploy the etcd cluster with the Google provided etcd images from gcr.io/google-containers/etcd-arm64, I specify the image version "3.2.18" but etcd-operator adds a "v" to the version trying to pull gcr.io/google-containers/etcd-arm64:v3.2.18 failing because gcr doesn't prefix the versions with "v".

I understand this was modeled after CoreOS image store on Quay where the images have the "v" after before the SemVer but it would be more flexible if the repository and version could just be concatenated.

@prune998
Copy link

Have the exact same issue here...

Also, when using private repo + auth, we need to add to the Deployment Spec :

"imagePullSecrets": [
          {
            "name": "your-auth-secret"
          }
        ],

Which is not taken care of in the PodPolicy spec of the etcdCluster (I could provide a patch for this and the v issue above if maintainers agree for this change.

Thanks

@prune998
Copy link

Will also work on a PR to support imagePullSecrets

@prune998
Copy link

The ImagePullSecrets can be set in a ServiceAccount as described in https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account

Would it be a better solution to allow to set a ServiceAccount in the etcdCluster resource ?

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

2 participants