A more succinct view of canaries

[JamWils]

Problem

We have gotten feedback on numerous occasions now that the "Progressive Delivery" UI lacks a compelling feature set.

Jobs to be done

• As a user, I might not be fully aware of Flagger and its capabilities. I don't know that it is creating a duplicate set of objects with "canaries".
• As a user, I need to jump to various tabs to get the full context of what a canary is doing at any given point of time. It would be nicer to see a more consolidated view of everything without jumping to tabs. This means I want to know which "success" or "failure" metric it is currently testing. I need to quickly see which metrics passed. I need to know the traffic distribution between the existing "deployment" and the "canary" rolling out. [Sept 2023 update: addressing this via Pipelines UI work.]
• As a user, I need to be able to view my canaries rolling out across clusters. I need to be able to see the progress they are making and the current UI is too basic to fit that need. [Sept 2023 update: addressing this via Pipelines UI work.]
• As a user, I need to know when a canary is successful and that the existing objects are "no longer active". [Sept 2023 update: addressing this via Pipelines UI work.]
• As a user, I need to have a safe production rollout. From the pipelines view I can see which versions are rolling out, but I have no insights into whether any canaries exist, and if they do how they are doing. [Sept 2023 update: addressing this via Pipelines UI work.]

[mmoulian]

I started working on this first proposal. The idea is to separate the information into different stages or columns for each copy of the Pod. The line above can show the status of it.

About the analysis, it is not clear to me when the request occurs and which components are affected.

[mmoulian]

@JamWils
Two detail diagram options:
-One with "namespace" on each Pod
-Another with "namespace" on the outside, because all belong to the same
I have a lot of technical questions about this ,also I also need information to figure out how I can include the analytics data here.

[JamWils]

@mmoulian and @alfaris while this is an Argo Rollouts demo, I think this nicely shows how "progressive delivery" works on a system

https://www.youtube.com/watch?v=DfeL7cdTx4c&t=592s

[mmoulian]

I've watched another video explaining the Argo interface. It's very interesting:
https://www.youtube.com/watch?v=aWDIQMbp1cc&t=64s

[mmoulian]

@JamWils
I have been working in a more dashboard approach to the Delivery interface. This condense 3 pages into one (details, objects and analysis). Show how the traffic is split in two Pods with different weights. I worked two states. The first one each element is healthy. The second one some elements have problem and the traffic change. @yiannistri Can you help us with your technical opinion?

914d97d6a3.png)

[lasomethingsomething]

@mmoulian Just discovered this while going through backlog issues one by one -- it covers main points that are part of the new Pipelines/Delivery UI work (reducing jumping between tabs, posting deployment strategy info on the Pipelines view, etc.), and also expresses similar goals. I'll give a closer look next week, please also do. :)

[lasomethingsomething]

@aryan9600 Jus found this and thought I'd ping in case you wanted to give it a look and provide feedback. We'll need to revisit the designs posted here, but as it turns out James' "jobs to be done" overlap quite a lot with what we're planning to do with Pipelines/Delivery so this issue remains useful and worth pondering.

[aryan9600]

I agree with most of what James said here. We need to think about several things, but here's an incomplete list:

• users should be informed about the objects that Flagger creates on its own when a Canary object is first applied on the cluster. i.e. when the object's .status.phase is Initializing
• users should be able to see at any point in time, how much weight the primary and canary Deployments are receiving.
• users should be able to view which metrics are being queried to drive the Canary run forward. this is particularly helpful, when things arent going as planned, for eg: if the request-success-rate metric is not meeting its required target, the user should be made aware of this particular roadblock, so that they can quickly intervene and see if they can manually remedy it.
• there should be some sort of progress indicator which informs users how far has the Canary run come since it first started.
• we should definitely show the number of failed checks that have occurred and the number of failed checks that are allowed to occur before the Canary run is marked as failed.