Matteo Ruina
Matteo Ruina
Hello community! I presented the [ArgoCD progressive rollout controller](https://github.com/maruina/argocd-progressive-rollout-controller) proof of concept at the latest community meeting. I got some feedback that would be a good candidate for incubating in...
While trying the latest version, we got the following error ``` Warning FailedCreatePodSandBox 16m kubelet, ip-172-17-224-226.eu-central-1.compute.internal Failed create pod sandbox: rpc error: code = Unknown desc = [failed to set...
Currently if an Application fails to sync, the whole ProgressiveSync fails. In ArgoCD we can specify a # of retries as per https://argo-cd.readthedocs.io/en/stable/operator-manual/application.yaml ``` # The retry feature is available...
We have an hardcoded dependecy on controller-runtimer v0.8.0 that we should eliminate. Unfortunately we need to import gitops-engine that still has a dependency on k8s/k8s so we still need the...
To make sure the operator doesn't get stuck in an infinite loop, we need a safeguard mechanism. We want this to be eventual consistent, because there might be a delay...
The ProgressiveSync CRD is designed as to support `maxTargets` and `maxParallel` as [IntOrString](https://pkg.go.dev/k8s.io/apimachinery/pkg/util/intstr#IntOrString). Consider the following scenario, when you have 4 clusters and a ProgressiveSync similar to ``` [...] stages:...
An ArgoCD Application can specify a destination server using `server` or `name` as per https://github.com/argoproj/argo-cd/blob/master/pkg/apis/application/v1alpha1/types.go#L524 At the moment we just look at `server` we need to support both.
Implement the requeue specification ## TODO [ ] Annotate the ProgressiveRollout CRD to protect against controller restart ## NOTES [ ] See https://book.kubebuilder.io/cronjob-tutorial/controller-implementation.html for some hints around adding annotations, timeouts...
When a progressive sync is completed, the controller sets the CRD status to `Completed`. In the case when a stage fails, the controller doesn't have the logic to set the...
In #8 we introduced the concept of `status.stages`. To complete the information about the status of each stage, we should extend `status.stages` with information about the cluster status. It should...