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 .....