Add rollback controller boilerplate #436
Conversation
IsaacJames
force-pushed
the
CI-3637-init-rollback-controller
branch
from
4639c2d to
42743f8
Compare
cmd/rollback-manager/main.go
Outdated
|
|
||
| manager, err := ctrl.NewManager(ctrl.GetConfigOrDie(), ctrl.Options{ | ||
| LeaderElection: commonOptions.ManagerLeaderElection, | ||
| LeaderElectionID: "deploy.crds.gocardless.com", |
There was a problem hiding this comment.
I think this has to be rollback.deploy.crds.gocardless.com as the documentation states:
LeaderElectionID determines the name of the resource that leader election will use for holding the leader lock.
I don't think this is as applicable to us, as we don't plan to run multiple replicas of the controller as of yet, but it might be useful if we decide to do it in the future.
There was a problem hiding this comment.
Right, gotcha. I'm assuming we should also change the release controller election ID to release.deploy.crds.gocardless.com then.
| verbs: | ||
| - get | ||
| - list | ||
| - watch |
There was a problem hiding this comment.
I'm not sure what the mechanism would be, but wouldn't the controller also need to update the Release?
I can think of a scenario where a rollback has happened, and we want to release status to indicate that it has occurred. I'm pretty sure we wouldn't want the rollback controller to update the status field of the release resource directly, but maybe we could manage that through annotations on the releases.
There was a problem hiding this comment.
I'm not (yet) convinced we need to update an existing Release by the rollback controller. However, if we decide to do so, maybe updating a specific (rollback controller owned) condition would be suitable?
However, maybe a better way would be to somehow inject this information through deployment mechanism during deployment, so it would be present during the creation of the Release resource? We already have the message field, so I assume there was some idea of how this could get propagated?
There was a problem hiding this comment.
Yep, I think I agree with @0x0013 - if we want to reflect the rollback in the Release resource I'd prefer to include that information in the ArgoCD notification and have the release-recorder inject it somehow than have both controllers managing the Release resource, even if indirectly via annotations.
Co-authored-by: Emil Lozev <elozev@gocardless.com>
Adding the rollback controller boilerplate.