Add failure modes telemetry - #646

Issue #509

@rdimitrov @domdomegg @tadasant Is there a possibility where we can run a deployment on staging for some time then push to production? Wanted to check the cardinality number for this release before it goes to production, something like this(screenshot), here it is high because of so many deployments I have done that won't be case for production. I have done very good testing around this but still wanted to see if this is an option.

Is there a possibility where we can run a deployment on staging for some time then push to production? Wanted to check the cardinality number for this release before it goes to production, something like this(screenshot), here it is high because of so many deployments I have done that won't be case for production. I have done very good testing around this but still wanted to see if this is an option.

I believe what we have now is what you describe - all commits to main get deployed to staging and only the latest release gets deployed to prod. Would that work for you or perhaps you'll need something else?

@rdimitrov That works assuming once we verify the above details then only release happens for production env, basically we might have to wait for other release to be deployed meanwhile.

Just being cautious here, looking at workflow files, looks like everything is getting deployed on production, anywhere that I can check the latest release part? just to make sure if this approach will work.

You can check the workflows for how the container images are published but overall we use the main floating tag for staging and the latest floating tag for prod of which:

• The main tag follows all commits to main

• The latest tag follows all released versions, i.e. v1.x.y, etc.

@rdimitrov Thank you for clearing this out 🙂

I should have clarified this earlier, my bad. I am not looking at release process for specific tag, I wanted to get the stats for this branch before this gets deployed to production. In deploy.yml every commit to main is deploying to staging and then to production. When this branch will be merged it will get deployed to both environment. But to understand the cardinality as per above screenshot, I have to collect stats from staging env first, verify it and if cardinality is under control the deploy it to production.

In deploy.yml every commit to main is deploying to staging and then to production. When this branch will be merged it will get deployed to both environment

Ah yeah, this is how it used to work. But we changed it a couple weeks ago so that deploy only deploys main to staging by default. And to get to production you need to create a GitHub release.

Super @domdomegg I will do a final testing on my end once again and we can then take it to staging.

@domdomegg @rdimitrov

• Did 2-3 deployments, looks under control, out of bound labels are only pod ids.
• Simulated Image pull back error also, it means events logs are also coming

============================================================

We can try this on staging

Should get deployed to staging automatically :)

Thank you @domdomegg