---
tags: Agenda
---
# Airship SIG Yaml

[TOC]

## [Recordings ](https://hackmd.io/CvuF8MzmR9KPqyAePnilPQ)
## Old Etherpad https://etherpad.openstack.org/p/Airship_Yaml

## February 1, 2021
No topics, call cancelled.

## January 25, 2021
No topics, call cancelled.

## January 18, 2021
Holiday in US

## January 11, 2021
No call this week.

## January 4, 2021
### Assess where we are related to Release 2.0..
* Treasuremap Strategy to achieve Release 2
- Manifest Busy Base Work
- Function work.. Build Library
- Composite/Type work .. Use Library
- Gating Work deploy as part of type.
- Manifest Enhanced Work
- Specializations, Enhance Functions
- Extra Functions.
- Gating
- Integration with airshipctl complete ?
- Integration with imagebuilder
- Other Work
- Branching Strategy
- Align this with 2.0 Release Date [https://github.com/airshipit/treasuremap/issues/50]
- Auditing
- CNCF Conformance.. (*** Not Required)
-- Is this needed as an ongoing Treasuremap gate/...

I think issues align with this somewhat : https://review.opendev.org/q/status:open+-is:wip+project:airship/treasuremap+branch:v2

LABS:
* STL 1 AIRSHIP 1 long running - Keep as is
* STL 2 - Testng for v1, keep as is
* STL 3 - Use for Airship v2 from Treasuremap...
* The work for this is not in treasuremap yet...
* This is fundamental work here. Follow up with Arjit...

ISSUES :
* Use Image Builder in Treasduremap for BM Nodes ...
* Define BM site Type

* Release 2 Target fopr Treasuremap is to satisfy (TBD) for airship-coresite type.

## December 14, 2020

## December 7, 2020

### Discuss Replacement Transformer Image Versioning (YAML Call perhaps)
Following discussion of https://github.com/airshipit/airshipctl/issues/419

apiVersion: airshipit.org/v1alpha1
kind: ReplacementTransformer
metadata:
 
  name: ......
  annotations:
    config.kubernetes.io/function: |-
      container:
        image: quay.io/airshipit/replacement-transformer:latest

Need a mechanism to specify the version for the plugin image once , and not in every ReplacementTarnsformer artifact.

Conclusion :
* We wil create a tag for each plugin , i.e. v1.0
* We expect this tag to be used across the ReplacementTrasformer artifacts
* If we need a new version, we would manually manage the image defintion across the manifests
* Expectation is that the plugins should not change frequent, and therefore the risk of the ReplacementTransformer artifacts drifting is small.

Tag Management for Plugins
* Use github actions for release/tags.

Create ***Issue*** for Plugin Release management.

***Issue*** :
Develop a Tool to manage updating function that are sourced from other upstream... Need to be able to identify how and where the information is gathere.

:::danger
TODO : Discussion with Tigera about including the https://docs.projectcalico.org/manifests/tigera-operator.yaml as a version released artifact.

:::

## November 30, 2020

## November 16, 2020
### List of functions to refactor to new structure
From the 11/12 Design call, identify the list of functions impacted so we can be as specific as possible when creating the issue.

:::info
4. New issue to refactor functions to follow the pattern below.
a. If a function uses no copied upstream base, leave out `[function]/upstream/`
b. If a function is *only* an upstream base, put it under `[function]/upstream/` and have a thin passthrough `[function]/kustomization.yaml`

@startsalt
{
{T
 /
 + manifests/
 ++ function/
 +++ capi/
 ++++ vx.y.z/
 +++++ upstream/ | Put the upstream here
 ++++++ <ReadME..  ***metadata*** for how we build  this from >
 +++++ replacements/
 +++++ patches1..n.yaml | Airship specific patches
 +++++ kustomization.yaml | Apply our patches on top of upstream
 }
}
@endsalt

:::

### Out of the box supported encrpytion in manifests for airshipctl (Alexey/Constantine)

1) Example https://review.opendev.org/#/c/762728 - By Alexey
3) Works out of the box, no need for any code changes, use as is.
4) Go this way, and develop small automation that will help easily generate variable catalogue with secrets, user will manually inject it afterwards?

Note 1: the command that was used to get the encrypted file:

sops -e -p FBC7B9E2A4F9289AC0C1D4843D16CEE4A27381B4 -e --encrypted-regex
'^(certificate-authority-data|certificate-authority-data|client-certificate-data|client-key-data)$' kubeconfig.yaml > encrypted-kubeconfig.yaml

Note 2: starting sops 3.6.1 it will be possible to do it in more unified way:

sops -e -p FBC7B9E2A4F9289AC0C1D4843D16CEE4A27381B4 -e --unencrypted-regex '^(kind|apiVersion|group|metadata|server)$' kubeconfig.yaml > encrypted-kubeconfig.yaml

need to wait for [this PR](https://github.com/GoogleContainerTools/kpt-functions-catalog/pull/122) to be merged or build the updated image.

### Phase render to have flag to be renedered by executor, phase, bundle - default phase:

airshipctl phase render --render [phase|executor|bundle]
* If phase, [documentEntrypoint](https://github.com/airshipit/airshipctl/blob/master/manifests/phases/phases.yaml#L85) is rendred
* If executor, executor interface will render however it wants
* if bundle, bunlde containing phases will be returned

## November 9, 2020
We still have a non-read-only kubectl command in our deployment process,
to remove the master taint from the target cluster control plane prior
to pivoting from the ephemeral to target:
https://github.com/airshipit/airshipctl/blob/master/tools/deployment/31_deploy_initinfra_target_node.sh#L22-L26

Can we accomplish this declaratively, or, programmatically via airshipctl?

We also use kubectl to pause the ephemeral cluster's BMH definitions
while orchestrating a move:
https://github.com/airshipit/airshipctl/blob/master/tools/deployment/33_cluster_move_target_node.sh#L27

Can we accomplish this programmatically via airshipctl phase clusterctl-move?

## November 2, 2020

## October 26, 2020
### Armada conversion demo

## October 19, 2020
Path forward with image builder integration

https://hackmd.io/6CgeJKqVQJ6vpT2DC5mx6A
Is anyone actively working https://github.com/airshipit/airshipctl/issues/248 & https://github.com/airshipit/airshipctl/issues/249
Still open questions?

### Finalize *"need an airshipctl list clusters based on the document set #323"*
https://github.com/airshipit/airshipctl/issues/323
Discussion here https://hackmd.io/3AGF1UHJTcOHHhSE0rnT9w

### Cluster ctl library adds support to retrieving kubeconfig for a workload cluster
This should be leveraged y airshipctl to update the site level kubeconfig after the workload cluster are created or redeployed.
Identify the appropriate issue that asks for the airshipctl command.

### Where do Workload cluster artifacts get deployed?
Clearly the namespace will be predefined /declared and will be Tenant/Workload custer specific

### Design a Method to Capture Manifest Version Information During Phase Deployment
#335
https://github.com/airshipit/airshipctl/issues/335
Discussion at https://hackmd.io/BbFyJRKGRQiuXYJduPhu4Q

## October 12, 2020

Will identify SIG YAML Design Topic from the Critical list of issues https://github.com/airshipit/airshipctl/issues?q=is%3Aopen+is%3Aissue+milestone%3Av2.0++-label%3Apriority%2Fcritical+label%3A%22design+needed%22+

### Need an airshipctl list clusters based on the document set #323
https://github.com/airshipit/airshipctl/issues/323
Discussion here https://hackmd.io/3AGF1UHJTcOHHhSE0rnT9w

### Develop an endpoints catalog #317
https://github.com/airshipit/airshipctl/issues/317

## October 5, 2020

### [Image Builder Declarative Discussion](https://hackmd.io/6CgeJKqVQJ6vpT2DC5mx6A)

### Request for reviews
* [Incorporate HWCC in deployment gate.](https://review.opendev.org/#/c/748421)