Open rootik opened 1 year ago
The Contour integration is built in such a way that it expects to create the HTTPProxy
object itself using the values provided in the Canary definition and so it ends up overriding any existing HTTPProxy
objects.
Users are expected to create another HTTPProxy
with the desired .spec.virtualHost
which will include the one generated by Flagger:
apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
name: devops-test-app-ingress
namespace: devops
spec:
virtualhost:
fqdn: devops-test-app.contoso.com
tls:
secretName: star-cert
includes:
- name: podinfo
namespace: test
conditions:
- prefix: /
I recommend you go through the tutorial once: https://fluxcd.io/flagger/tutorials/contour-progressive-delivery/
Thanks for your reply. Why would flagger then touch existing HTTPProxy
objects bound to a certain deployment?
Describe the bug
We are trying to use flagger in our progressive delivery efforts particularly in A/B testing scenario. Ingress provider we use is Contour while the mesh provider is linkerd. Testing of weighted canary deployments with linkerd was successful, but A/B testing with Contour went into a failure. When starting the canary iteration flagger modifies
HTTPProxy
resource and dropsvirtualhost
object from it. Which causes theHTTPProxy
to become orphaned. Just a note: we are not using nestedHTTPProxy
definitions so each deployment defines it's own rootHTTPProxy
.Another thing: flagger doesn't roll back the
HTTPProxy
CRD to the original state after unsuccessful rollout resulting the application to stop serving requests.To Reproduce
Canary definition
Original
HTTPProxy
CRDHTTPProxy
CRD after flagger starts canary advancementExpected behavior
virtualhost
object definition inHTTPProxy
during canary advancement in A/B testing scenartio.HTTPProxy
CRD to the original state if the rollout was unsuccessful.Additional context