Discuss target state implementation of Docker/Kernel/Os/Security Patches etc
When: Occurs every Tuesday from 1:00 PM to 2:00 PM effective 2/26/2019 until 3/29/2019. (UTC-05:00) Eastern Time (US & Canada) Where: https://attcorp.webex.com/join/rp2723 *~*~*~*~*~*~*~*~*~* Reducing to a single day 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 1st 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 .....
When: Occurs every Tuesday from 1:00 PM to 2:00 PM effective 2/26/2019 until 3/29/2019. (UTC-05:00) Eastern Time (US & Canada) Where: https://attcorp.webex.com/join/rp2723 *~*~*~*~*~*~*~*~*~* Reducing to a single day 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 1st 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 .....
participants (1)
-
PACHECO, RODOLFO J