You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a developer in GitOps team I would like to be able to track my cluster state in my GitOps repository.
I would like the controllers to make the changes to my cluster either:
Indirectly by commiting the desired state back to my GitOps repository
Or
By commiting the state change back to my repository after making the changes in cluster.
Use Cases
An example use case would be management of blue-green deployment in declarative fashion. When I make a change to a rollout then the Service gets changed as well. Currently this is done by patching and leads to differences between state described in GitOps repository and the state actually deployed into cluster. Tools which perform automatic synchronization would detect this and thus would undo the changes made by controller.
Message from the maintainers:
Impacted by this bug? Give it a 👍. We prioritize the issues with the most 👍.
The text was updated successfully, but these errors were encountered:
Agree that this is outside the purview of Argo Rollouts. Argo CD Image Updater is an example of how this could be done as a separate project (but for changes to image registries and live objects). I think you should explore that as an option since git writeback isn't something that would likely ever be part of the controller.'
Second, the upcoming notification support will have support for webhook notifications that could be invoked upon RolloutUpdated events. You may be able to leverage argo rollout notifications to achieve your use case by calling a webhook of your own service, which could perform the git writeback.
Summary
As a developer in GitOps team I would like to be able to track my cluster state in my GitOps repository.
I would like the controllers to make the changes to my cluster either:
Or
Use Cases
An example use case would be management of blue-green deployment in declarative fashion. When I make a change to a rollout then the Service gets changed as well. Currently this is done by patching and leads to differences between state described in GitOps repository and the state actually deployed into cluster. Tools which perform automatic synchronization would detect this and thus would undo the changes made by controller.
Message from the maintainers:
Impacted by this bug? Give it a 👍. We prioritize the issues with the most 👍.
The text was updated successfully, but these errors were encountered: