Skip to content

Latest commit

 

History

History
111 lines (86 loc) · 7.21 KB

canary-worflows.md

File metadata and controls

111 lines (86 loc) · 7.21 KB
Raw

reconcile loops interactions

The ExtendedDaemonset controller is composed with 3 different reconcile loops; One by CRD:

  • ExtendedDaemonset
  • ExtendedDaemonsetReplicaset
  • ExtendedDaemonsetSettings

The differents reconcile loops need some time to interact together. To do so, some of them are watching events happening on the other CRDs, But only the CRD managed by the reconcile loop can modify the CRD. All the other CRDs could be read but never updated.

The following sections explain these interactions depending on the cases.

Automatic canary pause

When the user has configured the canary auto-pause feature. The following sequence diagram explains the interactions between reconciling loops when the ERS reconcile loop detects that the auto-pause conditions have been reached.

sequence diagram

sequenceDiagram
    participant ers as ERS-Controller
    participant api as API-Server
    participant eds as EDS-Controller

    ers-->>api: watch ers,pods,nodes
    eds-->>api: watch eds,ers,nodes

    api->>ers: pod restart x4
    activate ers
    ers->>+api: get parent EDS
    api->>-ers: EDS
    Note right of ers: get EDS canary configuration
    Note right of ers: to many pod restart,<br/>  create CanaryPaused ers.status.conditions
    ers->>api: update ers
    deactivate ers

    api->>eds: ers status updated
    activate eds
    eds->>+api: get childs ERSs
    api->>-ers: ERSs (active,canary)
    Note left of eds: read child ers status: canary is now paused
    Note left of eds: updated eds.status: state and <br/> create canaryPaused eds.status.conditions
    eds->>api: update eds.status
    deactivate eds
Loading

User adds a pause annotation on a EDS instance

The following diagram represents the usecase when the user adds a canary pause annotation on top of the EDS instance.

Sequence Diagram

sequenceDiagram
    participant user as user
    participant api as API-Server
    participant eds as EDS-Controller
    participant ers as ERS-Controller
    

    ers-->>api: watch ers,pods,nodes
    eds-->>api: watch eds,ers,nodes

    user->>api: Add pause annotation on EDS instance
    activate eds
    Note left of eds: canary-paused annotation detected
    Note left of eds: create new canaryPause condition in eds.status.conditions
    eds->>api: update eds.status
    deactivate eds
    api->>ers: eds updated
    activate ers
    ers->>+api: get parent EDS
    api->>-ers: EDS
    Note left of ers: eds canaryPause condition detected
    Note left of ers: pause ers deployment
    deactivate ers
Loading

Automatic canary failed

Very similar to the "Automatic canary pause". The "auto-failed" functionality reverts the EDS instance configuration to stop the Canary phase. To do so, the ExtendedDaemonset reconcile loop is updated the EDS.Spec.Template with the "Active" ExtendedDaemonsetReplicaset.spec.Template.

Sequence Diagram

sequenceDiagram
    participant ers as ERS-Controller
    participant api as API-Server
    participant eds as EDS-Controller

    ers-->>api: watch ers,pods,nodes
    eds-->>api: watch eds,ers,nodes

    api->>ers: pod restart x4
    activate ers
    ers->>+api: get parent EDS
    api->>-ers: EDS
    Note right of ers: get EDS canary configuration
    Note right of ers: to many pod restart,<br/>  create CanaryFailed ers.status.conditions
    ers->>api: update ers
    deactivate ers

    api->>eds: ers status updated
    activate eds
    eds->>+api: get childs ERSs
    api->>-ers: ERSs (active,canary)
    Note left of eds: read canary child ers status: canary is now Failed
    Note left of eds: updated eds.status: state and <br/> create CanaryFailed eds.status.conditions
    eds->>api: update eds.spec.template and eds.status
    deactivate eds
Loading