Rename operator deployment

[andreasgerstmayr]

Commit 7fa448a added additional labels to the operator deployment and its selector field.

Unfortunately the selector field is immutable, and when OLM tries to patch the deployment while upgrading, Kubernetes will reject this update.

A workaround is to rename the deployment, as suggested here: operator-framework/operator-lifecycle-manager#952

[iblancasa]

I have some questions:

1. This is something we need to do just because the selector field was modified. Not something we'll need to do for each new version, right?
2. Are we going to bump the operator to version 2 and that is the reason for v2 postfix?

Also... maybe it's ok to not support the upgrade from the 0.1.0 version. That will simplify everything

[codecov-commenter]

Codecov Report

Merging #432 (cd5bd6d) into main (d556798) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #432   +/-   ##
=======================================
  Coverage   77.93%   77.93%           
=======================================
  Files          55       55           
  Lines        4252     4252           
=======================================
  Hits         3314     3314           
  Misses        793      793           
  Partials      145      145           

Flag	Coverage Δ
unittests	77.93% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

[andreasgerstmayr]

I have some questions:

1. This is something we need to do just because the selector field was modified. Not something we'll need to do for each new version, right?

Yes, exactly. The selectors shouldn't change in the future.

2. Are we going to bump the operator to version 2 and that is the reason for `v2` postfix?

I choose v2 in a sense of "v2-of-the-deployment", not of the operator. The name of the operator deployment should be an internal detail and shouldn't matter much.

Also... maybe it's ok to not support the upgrade from the 0.1.0 version. That will simplify everything

That's also an option. What are your concerns about renaming the deployment? Does anything rely on the name of the deployment (note, I didn't rename the labels of the deployment, only the name)?

Afaics nothing should break.. except one thing, if you install the operator via manifests, than the old deployment is not pruned. imho that's a general problem and will happen every time when we drop or rename any component (Service, ConfigMap, etc).

[andreasgerstmayr]

Also... maybe it's ok to not support the upgrade from the 0.1.0 version. That will simplify everything

Hm, yeah it also changes the pod name, then the blog post example output won't match anymore. Maybe it's not that important to support upgrades from 0.1.0, I don't know :)

[iblancasa]

That's also an option. What are your concerns about renaming the deployment? Does anything rely on the name of the deployment (note, I didn't rename the labels of the deployment, only the name)?

I think the v2 can be a little bit misleading because we can think relates somehow to version 2 of the operator. Also, I'm not sure if we want to keep that v2 postfix forever because of one change between the first and second versions.

It's not a strong opinion.

[andreasgerstmayr]

I agree, I'm also not too happy about the rename with -v2. I'd like it renamed to just tempo-operator (I'm not a big fan of controller-manager), but that's also not possible because the kustomize files prefix everything with tempo-operator, so the deployment name in the kustomize files would be empty then.

[frzifus]

Just some thoughts on it. ^^