Canceling for today since many of the more vocal parties cannot make it.

Discuss target state implementation of Airship Docker/Kubelet/Kernel/OS etc upgrade

I scheduled a series, will figure out when it’s appropriate

What do we need to discuss ?

The ability to manage the delivery of any update across groups of hosts in a declarative way.

The ability to control disruption effects from those updates

Next Meeting:

Looking at the https://github.com/GoogleCloudPlatform/metacontroller approach and comparing against what we discussed today.

Everyone (in Airship Community)  is welcome to participate on this discussions.

Approach Discussed on our 1^st Meeting

https://go.gliffy.com/go/publish/12934972

Sample CR’s ..

apiVersion: airship/v1

kind: MultiNodeAction

metadata:

  name: DoSomethingPerRack

spec:

# List of sets of nodes that theis applies to. Indicates the cadence. 1 set at a time

  failureSet:

    set1:

      rack: rack1

    set2:

      rack: rack2

# - Indicate the Action(What are we doing) -

# - Indicate effect Upgrade and Reboot, Reboot Only, ..

   intentions:

      - UpgradeDockerAction

      - UpgradeKubeletAction

      - RebootAction

## This is teh CR that a node agent consumes

apiVersion: airship/v1

kind: NodeAction

metadata:

  name: Set1

spec:

  setIndicator:

      rack: rack1

   intentions:

      ListOFActions:

      - UpgradeDocker

      - UpgradeKubelet

      - Reboot

## This is the CR's for ACTIONS that the NodeAgent ingests as well

apiVersion: airship/v1

kind: Action

metadata:

  name: Reboot

spec:

  script .....

apiVersion: nc.att.com/v1

kind: Action

metadata:

  name: UpgradeDocker

spec:

  script .....

apiVersion: nc.att.com/v1

kind: Action

metadata:

  name: UpgradeKubelet

spec:

  script .....