Cert manager version doesnt match the documentation

[kiuka]

Environment:

Kubespray version (commit) (git rev-parse --short HEAD):
Latest

Anything else do we need to know:
The documentation says that it uses cert-manager v0.11.0 (which would be the latest version) but meanwhile in the code it still uses 0.5.2 (https://github.com/kubernetes-sigs/kubespray/blob/master/roles/kubernetes-apps/ingress_controller/cert_manager/templates/deploy-cert-manager.yml.j2)

Am I missing something and cert-manager is not part of kubespray anymore or is this a bug?

[kiuka]

As I see it was updated here, but the deployment file does not use this variable at all:

19bc79b#diff-c2bdcdbb150201cf87aa5c6490a6d182

[kiuka]

And also which is even bigger problem that the cert-manager-controller has the new version and thats incompatible with the old cert-manager.

[Miouge1]

You are probably looking at the labels field which is just a label. Cert-manager version is defined in roles/download/defaults/main.yml

Then copied into cert_manager_controller_image_tag here, and finally used here.

[kiuka]

@Miouge1 exactly, thats for the controller and the actual cert manager version is hardcoded here: https://github.com/kubernetes-sigs/kubespray/blob/master/roles/kubernetes-apps/ingress_controller/cert_manager/templates/deploy-cert-manager.yml.j2#L9

[Miouge1]

And that's just a label. It has no impact on the docker image used etc... try it out for yourself to double check.

[kiuka]

Well, I have tried and it wasnt working so I had to setup from scratch. But close it please if you feel its working, it didnt work for me because the controller and the cert manager wasnt compatible with one and the other.

[asubb]

I've hit on the same issue. Kubespray 2.13.0.

Though tried to find some quick and dirty fix. Based on release log https://github.com/jetstack/cert-manager/releases/tag/v0.11.0, there are a few new resources were absent. While I succeeded to create them, that didn't help much.

After diving deeper into helm chart, I found a few deployments and services are also missing as well as more complicated role management. So I'm under impression nowadays integration is completely broken and should be rewritten from scratch :( Would be glad to be mistaken.

Seems nowadays it's easier to install cert-manager separately.

[bmelbourne]

@Miouge1

I've successfully implemented Cert-Manager v0.15.1 in Kubespray v2.13.2 for my recent client.

Cert-Manager v0.15.2 was released a few days ago.

I'd be happy to create a PR to get this version integrated with the latest Kubespray codebase?

[Magnitus-]

I also had issues using the Cert-Manager as installed by Kubespray. There were api version mismatch with the examples provided in the Cert-Manager documentation (and there were other access-related issues once I resolved those).

Just applying the manifests of a more recent version of Cert-Manager as indicated here worked for me: https://cert-manager.io/docs/installation/kubernetes/#installing-with-regular-manifests

[floryut]

@Miouge1

I've successfully implemented Cert-Manager v0.15.1 in Kubespray v2.13.2 for my recent client.

Cert-Manager v0.15.2 was released a few days ago.

I'd be happy to create a PR to get this version integrated with the latest Kubespray codebase?

Oh my, please do ! :) this is something needed, and I didn't have a cluster setup with that to properly update and test it.

[Magnitus-]

@Miouge1
I've successfully implemented Cert-Manager v0.15.1 in Kubespray v2.13.2 for my recent client.
Cert-Manager v0.15.2 was released a few days ago.
I'd be happy to create a PR to get this version integrated with the latest Kubespray codebase?

Oh my, please do ! :) this is something needed, and I didn't have a cluster setup with that to properly update and test it.

Please, let me know if I'm just creating noise, but I'm wondering if you really want to take on the burden of supporting cert-manager for this project (in the context of what I assume is an idempotent mostly declarative installer).

From what I could gather from the cert-manager documentation, their api is not stable and there are breaking changes with each release that requires a careful migration: https://cert-manager.io/docs/installation/upgrading/#upgrading-using-static-manifests

What I assume this means if someone has a previous version of cert-manager installed and the version is bumped up in a future release of kubepray is: the best the installer can do in such a situation is abort the installation and tell the user he/she will have to migrate this manually.

Then again, maybe the version of cert-manager will remain the same in a given release of kubespray and such breaking changes are to be expected across releases in which case this would be a non-issue.

Anyways, food for thought.

[floryut]

@Miouge1
I've successfully implemented Cert-Manager v0.15.1 in Kubespray v2.13.2 for my recent client.
Cert-Manager v0.15.2 was released a few days ago.
I'd be happy to create a PR to get this version integrated with the latest Kubespray codebase?

Oh my, please do ! :) this is something needed, and I didn't have a cluster setup with that to properly update and test it.

Please, let me know if I'm just creating noise, but I'm wondering if you really want to take on the burden of supporting cert-manager for this project (in the context of what I assume is an idempotent mostly declarative installer).

From what I could gather from the cert-manager documentation, their api is not stable and there are breaking changes with each release that requires a careful migration: https://cert-manager.io/docs/installation/upgrading/#upgrading-using-static-manifests

What I assume this means if someone has a previous version of cert-manager installed and the version is bumped up in a future release of kubepray is: the best the installer can do in such a situation is abort the installation and tell the user he/she will have to migrate this manually.

Then again, maybe the version of cert-manager will remain the same in a given release of kubespray and such breaking changes are to be expected across releases in which case this would be a non-issue.

Anyways, food for thought.

Kind of agree with you, but I'm hopeful they will have something stable overtime.. best we can do right now is putting a bit warning in the release note and tell users to be careful if an old version is already installed ?

[Magnitus-]

Kind of agree with you, but I'm hopeful they will have something stable overtime.. best we can do right now is putting a bit warning in the release note and tell users to be careful if an old version is already installed ?

Agreed. While common sense should dictate caution when running a newer revision of Kubespray on a pre-existing cluster (ie, try it on a dummy environment), I'm guessing based on what I've seen so far in the industry that someone would fall for it.

I cogitated about it over the weekend and I think there are two potential longer term solutions to the problem (not mutually exclusive) until it becomes stables:

• Allow the user to fixate the version of cert-manager in his/her kubespray configuration (like you are doing with the version of Kubernetes)
• Like previously mentioned, check for a pre-existing release of cert-manager in the specified namespace and if there is one: Abort if the version doesn't match and skip that step if it does

Even when it becomes stable, the above would provide a path forward in case of future breaking api changes or just for ultra-cautious developers who want to lock their versions to prevent regression bugs.

I could look into it if you like.