search

coreos / etcd-operator

etcd operator creates/configures/manages etcd clusters atop Kubernetes
https://coreos.com/blog/introducing-the-etcd-operator.html
Apache License 2.0
1.75k stars 741 forks source link

removed auto-adding v to the etcd image version #2079

Open prune998 opened 5 years ago

prune998 commented 5 years ago

When creating an etcdCluster resource, you provide an Image and a Version. Version` is a semver version depending on the EtcD image version you wish to use.

The default is to use Quay images, which are versioned using a pattern of v + semver, like v3.0.12.

So defining :

apiVersion: "etcd.database.coreos.com/v1beta2"
kind: "EtcdCluster"
metadata:
  name: "example-etcd-cluster"
spec:
  size: 3
  version: "3.1.10"
  repository: "quay.io/coreos/etcd"

Will create a Pod using image quay.io/coreos/etcd:v3.1.10.

This may be fine with Quay images, but when you are working with other Docker Registries, you may not want to add the v to the version.

The Operator should not force you to use a specific version pattern.

This PR removes the v addition to the version, allowing to use a real version name in the CRD.

etcd-bot commented 5 years ago

Can one of the admins verify this patch?

etcd-bot commented 5 years ago

Can one of the admins verify this patch?

etcd-bot commented 5 years ago

Can one of the admins verify this patch?

prune998 commented 5 years ago

issue referenced in

alaypatel07 commented 5 years ago

I am wondering if instead of composing the image name using repository and version, it would be simpler to replace it with a key called image? The CR will look like:

apiVersion: "etcd.database.coreos.com/v1beta2"
kind: "EtcdCluster"
metadata:
  name: "example-etcd-cluster"
spec:
  size: 3
  image: "quay.io/coreos/etcd:v3.1.10"
prune998 commented 5 years ago

Maybe doing this will make it harder to manage the upgrade process when only the image version is changed ? That would also imply an API change, while this PR does not.

alaypatel07 commented 5 years ago

I could be wrong, but I thought if we can compare the image instead of version here, the upgrade process can be handled.

Agreed, this would mean an API change, and I do not know if we would want it for simplicity or not.

xmlking commented 5 years ago

we also have issue with auto-adding v our Pod Security Policy restrict images using with version number. we have to sign them and we have to use tag with digest something like this "sha256:4567464gfjfjfgjfjfjfjfjjfjfjfjfj354345534" if it adds "v" , then it breaks

NormanFoxLee commented 5 years ago

Is it possible to add digest: so we can use image@digest instead image:version?