---
tags: Agenda
---
# Flight Plan

[TOC]
## Old Etherpad https://etherpad.openstack.org/p/Airship_FlightPlan
## Scope for Airship 2 Release
What are we doing between Beta and Product/Release

### Bot Jenkins Jobs

https://jenkins.nc.opensource.att.com/job/development/job/MaintenanceJobs/

### Hostconfig
* Complete All Day 2 Provisioning Lifecycle management activities .
* Hostconfig activities/roles/tasks
### ImageBuilder
* Declarative Image Management
* Integration with CI
### Airshipctl
* Integration with ImageBuilder
* complete security/secrets subcommands i.e. password / secrets rotation
* Complete Host Generator / Variable Catalogue using BIOS/FIRMWARE
* CAPI v1alphav4 integration?
* Migration from Flux Helm Operator > Flux helm-controller
* Finalize Airshipctl incomplete commands
* airshipctl document validate
* airshipctl clusterctl delete
* airshipctl cluster status
* Auditing
* ?? What does this mean for s in terms of capabilitites for Airshipctl
* PhaseManifest
* Airshipctl & Telemetry of the Phase Run's
* Do we need to define what this means?
* Multicluster/ Workload cluster support
* Inject or extrapolate kubeconfig into manifests when appropriate

### Airship in a POD

### Treasuremap
* Integration with airship hostconfig for day 2 CI/CD
* HostConfig Function is part of the library.
* Integration with airshipctl secrets capabilitites?
* Continue to enhance their catalog of well curated software library to support industry use cases.
* Complete NC type - Should be able to deploy CNTT like deployments.
* This means full core baremetal deployments.
* Where do we integrate/gate/functionality such as RAID/BIOS config changes ? Is that a Treasuremap item

### Documentation

### GAPS - What else do we want to add for discussion , add below:

## Projects

| Project | Issues |
| - | - |
| Host Config Operator | https://github.com/airshipit/hostconfig-operator/issues?q=is%3Aopen+is%3Aissue+label%3Atriage |
| Treasuremap | https://github.com/airshipit/treasuremap/issues?q=is%3Aopen+is%3Aissue+label%3Atriage |
| Images - Image Builder | https://github.com/airshipit/images/labels |
| Airshipctl | https://github.com/airshipit/airshipctl/issues?q=is%3Aopen+is%3Aissue+label%3Atriage |
| Docs | https://github.com/airshipit/docs/issues |

## Discussions
### June 9, 2021
* [#555](https://github.com/airshipit/airshipctl/issues/555) < K8s 1.18 to 1.20 upgrade. Get concurrence on creating additional issues for upgrading k8s for the additional providers (Azure, GCP, Openstack). Will [#556](https://github.com/airshipit/airshipctl/issues/556) suffice to cover Docker or is that just a temporary deal?

ISSUES:
1. Normalize the phase plans across the different airshipctl sites, by setting up the same site-type inheritance *for the phases entrypoint* as already exists for `test-site`. The default phase plan in the `gating` type should be suitable for the general case -- i.e. everything besides bare metal deployments (which have their own phases). At the e.g. `docker` site level, it can just consume those phase plans & use them; at the `test-site` level it'll need to patch the plan to have all the bare metal phases as it has today.
2. Make the `gating` type a fully-fledged type, by moving the meat of the phase payload entrypoints from the site level to the type level. The site-level phase payload entrypoints will be very skinny after this (just like in treasuremap), making only the tweaks that are needed to tune the phase payloads per-provider.

### May 26, 2021
* (Larry) Looking to close airshipctl issue #443. Need a quick discussion to get a consensus on whether new issue is needed per issue comments. Are we making it a standard with our manifests to deploy CRD and CR in different phases or is this a case-by-case thing? https://github.com/airshipit/airshipctl/issues/443#issuecomment-841486573

### May 19, 2021
* Triage
* Review 2.1 issues missing priority (just a few)
* Sync up on 2.1 Timeline and Logistics
* When should we create v2.1 branches?
* When should we tag images?
* Walk through the branching process
* etc..
* Can we make the release announcement a single document (for OpenFoundation and Blog).

### May 5, 2021
* **<u>V2.1 Open Issue Count:**</u>
* 105 open issues
* 70 assigned
* 23 critical, 24 medium, 9 low, 8 non-docs not prioritized, 6 docs not prioritized
* 35 unnassigned --> **move to Future?**
* 5 critical, 11 medium, 2 low, 4 non-docs not prioritized, 13 docs not prioritized

* **<u>New issues - can they be moved to Future?**</u>
* Unassigned
* [Make executors respect timeouts (airshipctl #533, v2.1)]( https://github.com/airshipit/airshipctl/issues/533) STATUS: Kostiantyn to discuss on 5/6 (future) Design Call
* Assigned
* (Siraj Y) - [Generate VersionsCatalogue and NetworkCatalogue schemas via kubebuilder (airshipctl #532, v2.1)]( https://github.com/airshipit/airshipctl/issues/532) STATUS: Siraj confirms this will be complete <= 1 week.
* (Bijaya) - [Metadata.yaml should be a complete kubernetes style yaml (airshipctl #530, v2.1)](https://github.com/airshipit/airshipctl/issues/530) STATUS: Bijaya confirms this will be complete <= 2 week(s).
* Unknown
* [Bump urllib3 from 1.25.3 to 1.25.8 in docs #34](https://github.com/airshipit/docs/pull/34)

### April 28, 2021
### April 21, 2021
### April 14, 2021

### April 7, 2021

### March 31, 2021

* Sync up on remaining work for v2.0 release
* Remaining patches from yesterday's merge push
* SSH key gen: https://review.opendev.org/c/airship/airshipctl/+/774251
* Sreejith's Helm-Collator update to airshipctl: https://review.opendev.org/c/airship/airshipctl/+/784122
* Bump treasuremap's airshipctl pin: https://review.opendev.org/c/airship/treasuremap/+/784091
* Kustomize install script in TM: https://review.opendev.org/c/airship/treasuremap/+/783911
* STL3 manifests
* Deployment documentation
* When should we create v2.0 branches?
* When the four patchsets above merge.
* Full list of branched repos?
* treasuremap (will pin images and collate charts)
* airshipctl
* Full list of tagged repos?
* airshipctl
* images
* charts
* hostconfig-operator
* treasuremap
* When should we tag images?
* Soon after branching
* Then update treasuremap versions.yamls to point at pins
* Walk through the branching process
* Treasuremap:
1. Branch Treasuremap v2 -> new v2.0 branch (today)
2. Stabilize v2.0 branch, pin versions.yaml airship components to v2.0.0 tags in v2.0 branch
3. At about the same time:
* Rename master branch -> v1.9
* Rename v2 branch -> master
* Tag v2.0 branch -> v2.0.0
* Other v2.0 release automation
* Let's revisit our strategy for tagging/pinning KRM functions now that our overall release strategy has evolved
* Decision:
* Stay with the previous plan of moving vX tags for KRM functions
* Tag KRM functions with vX.Y.Z as well
* Start the KRM functions at tags v2 / v2.0.0, but they'll rev independently of the rest of Airship after that
* We can decide to pin to either vX or vX.Y.Z in our formal releases
* Some 2.1 issues have been closed. Should any of these be marked with 2.0 milestone for release purposes:
* https://github.com/airshipit/airshipctl/issues?q=is%3Aissue+is%3Aclosed+milestone%3Av2.1
* https://github.com/airshipit/treasuremap/issues?q=is%3Aissue+is%3Aclosed+milestone%3Av2.1

### March 24, 2021

#### Continued Planning for the v2.0 release
* Critical PSs & Issues
* Any open V2.0 items we can move to V2.1, or Future?
* Logistics
* Blog post with announcement
* Writing 2 Documents
* Airship 2 - Under the hood - lifecycle (ongoing almost done)
* Airship 2 - Under the hood - manifest (just started)
* Airship 2 Announcement ...
* Overview (high level explanation)
* Date links
* Say that the other blogs are ... [ Maybe just link to the other available blogs]
* Feature list needed?
* Tool will work BAU. Compare against Beta, and produce lists
* Will manually add the content of the overview.

* Branch v2 will be created monday cob (CST) for all repos
*
* Monday will decide what issues and ops are punted to 2.1
* Wed Flight Plan - Decide what we should merge from master into v2
* Thu (Condititonal) Morning Create the release artifacts if we have the working BMH
* LAb Status report by Monday 4 EST
* This will move day to day if the lab is no working.

* Release Process [ document process ]
* Branching strategy .
* Will create new branches for every Major and Minor release
* Patches will be applied to specific minor or major branches that they apply to.
* Development will occur against master
* Branch for upcoming release is created a few days before target milestone
* How many days before we think we need to do this?
* About a week or sooner
* Guidance is to do it at the Point in time where dev is somewhat stable?

### March 17, 2021

### March 10, 2021

#### Planning for the v2.0 release
* What is the release ?
* artifacts we own
* ImageBuilder IMAGE that is tagged 2.0
* airshipctl IMAGE that is tagged 2.0
* HostConfig IMAGE that is tagged 2.0
* artifacts we dont own
* Plugins IMAGE that is tagged with their own version number
* How does arship keep track of the related artifacts
* updating versions catalogue
* will be updated every we cut a release, and therefore i.e will tie to ppropriate point plugin version.
* TODO manual versions update for now, see if we can get automation in place
* Update treasuremp appropriately
* Script release will :
* generates release notes
* generates the airshipctl image in quay with the right tag
* TODO lets update the github actions on teh repo for the release.
* Announcement in the BLOG or Mailing List
* Start writing what that going to look a ...
* Go here to read the docs??

* How does the release work
* Two phase appproach :
* 1st we build artifacts offr version release. Tag all artifacts
* update versions.yaml in arshipctl
* Update treasuremap version

#### Planning for the v2.1 release
When :
Target is End of April ..

Time to define a release?
Potential scope:
* Robustness
* More complete hostconfig toolkit
* More solid treasuremap..
* Driving the BM lab in STl3 from treasuremap gates.
* Whatever falls out of 2.0
* Plan in use ...
* Can we have a gate that uses airshipctl plan instead of phases.
* Solidify the documentation
*
* Scope that is fast-followon to v2.0
* SIP & VINO
* Treasuremap manifests for subclusters
* Consider moving some Day-2 operations / baremetal-operator scope here
* Updating some versions?, like
* CAPI...
* CAPM3
* Metal3

What do we want our release scheule to be - 3 or 4 times per year maybe?
#### Issues review (Mike email/list sent Monday)
Keeping/abandoning a few V2.0 PSs, and confirming if unassigned V2 Issues can be moved to postV2

### March 3, 2021
#### Treasuremap function > type labeling
* Completed labeling, added comments to include in the labeled type.

### Feb 25, 2021
#### Path forward for Treasuremap function > type mapping
Next steps from the 2/23 Design Call
1) Are we going to rename the network-cloud type to multi-tenant-type? Is so, the assumption is we’ll want a new V2.0 issue for that. How will that impact the downstream work? **New Issue: Rename network-cloud type to multi-tenant: https://github.com/airshipit/treasuremap/issues/97**
2) Should we create a new `type: multi-tenant` label? Currently have `type: airship-core` & `type: network-cloud`. **Done**
3) Create a post V2.0 issue for the “new” network-cloud type which would incorporate OSH **Yes: create new issue: https://github.com/airshipit/treasuremap/issues/98**
4) Create new a new V2.0 issue to include Host Config Operator, NGINX Ingress Controller, Tigera Operator in the airship-core type (for the functions which have already been delivered) **Yes: create a new issue: https://github.com/airshipit/treasuremap/issues/99(HCO). NGINX and Tigera already included in airship-core**
5) Andrew & Larry to go through the issues list from the spreadsheet and label the issues with `type: airship-core` or `type: multi-tenant/nc` labels
6) Socialize that those who are working these issues need to ensure they’re incorporated into the appropriate type based on the added label.
____________________

ISSUE : Treasuremap will nightly pin airshipctl, to keep a stable working version of treasuremap. A gate will validate that its safe to update airshipctl: https://github.com/airshipit/treasuremap/issues/100

### Feb 17, 2021
* status of the gerrit to github bot.

### Feb 10, 2021

#### Can any of these airshipctl issues be closed?
449 – One related change is merged. May need more.
429 – Need status
427 – Related change merged
405 – Related change merged
379 – Two related changes merged
374 – All related patchsets seem to be merged
359 – Three related changes merged
320 – Related change merged and comment says “IMO this issue might be closed”
252 – Question in comments as to whether this can be closed
202 – This was closed once and then re-opened by gerrit activity. All patchsets now seem to be merged
179 – Obsolete?
79 – Comments indicate may be ready to close

Bot :
* Add Ians change/ps
*

### Feb 3, 2021
#### Vote for Discontinue SIG YAML Calls below
* (Rodolfo) +1
* (Dmitry) +1
* (mattmceuen) +1

#### New Repo in Airship []:
Create new Repo gerrit-to-github-bot
Fork this
https://github.com/ianpittwood/Gerrit-to-Github-Issues
Project creation request:
https://review.opendev.org/c/openstack/project-config/+/773936
Need to be able to use it for multile repos
Either multiple instances or change the code

#### Will manage pushing -> Priority of Issues and State of v2 by relying on queries such as :
is:open is:issue label:priority/critical label:"ready for review"
Filtering on each project but Prioritu label, and ready for review.

Discuss on Flight Plan/Mailing list ..

Repositories sip + vino should start to upstream issues after a cut over date when the code has met minimal reqs downstream. Will prep the repos with labels, milestone.

#### Treasuremap Exercise
Functions that are not assocated with types will not be tested. Since CI/CDD pipelines only applies to types.

* We have a collection of functions
* We need to map the functions target to v2 or beyond
* We need to identify which type a function belongs to
* We need to define which types will be part of v2

How do we tag/identify what functions go with what types? Labels, new issues?
* Create label for each type for identification purposes.
* When creating the issue for the function, include which type(s) in which the function should be included.
* The developer who is working the function creation issue should be responsible for including it in the types that are specified in the issue.
* We are making the assumption all other types inherit airship-core, and will also inherit the functions associated with airship-core.
* When a new type is defined, part of the issue to create the type should include which functions are part of the type.
* What should we capture in regards to incubation phase? << **Needs Discussion** @jezogwza

### Jan 27, 2021

#### Agree on new Milestone Target Date for GA of v2
* Agree new Milestone is MArch 31 strategy wise, for all Airship v2 scope.
* However we want a quantification that shows the work that means between now and then.

### Jan 20, 2021

#### Issues Needed
* cluster init , when run twice in a row causes issues. [#450](https://github.com/airshipit/airshipctl/issues/450)
* image command needs to be removed once image builder integration is fully merged. -- Email sent to Craig to confirm
* plan list support -o yaml to be equivalent to phase list -o yaml [Already been worked]
* Enhance the way version command works to a more generic approach tie to the repository brannch/version etc

https://docs.google.com/spreadsheets/d/1YnVC_yQr7m-TUDaLz0xGndkoVIlO2emIwoGirbPBz-8/edit#gid=0

### Jan 13, 2021
#### Discuss approach for types
* How do we tag/identify what functions go with what types? Labels, new issues?
* Create label for each type for identification purposes.
* When creating the issue for the function, include which type(s) in which the function should be included.
* The developer who is working the function creation issue should be responsible for including it in the types that are specified in the issue.
* We are making the assumption all other types inherit airship-core, and will also inherit the functions associated with airship-core.
* When a new type is defined, part of the issue to create the type should include which functions are part of the type.
* What should we capture in regards to incubation phase? << **Needs Discussion** @jezogwza
* What functions should be included in the airship-core & nc types?
* Which of those functions are deemed necessary for v2.0 GA vs. follow on after GA?
* This assumes that we'll be including both airship-core & nc types as part of the v2.0 treasuremap offering (vs. just airship-core)
#### Prioritize issues with triage label
* Examine list of issues with the `triage` label and prioritize them

### Jan 6, 2021
#### Lets start the year
* by assesing where we are
* Milestone for v2 is Jan 31, do we need to move it
* Is there a conference or other timeline incentive to align with?

---
Issue : Define Strategy for gating once plan run is available.

### Dec 16, 2020
#### Treasuremap review
* New LMA issues - Sudeep Batra
* Close out existing issues #11 - #16 inclusive
* Treasuremap issues, should we start specifying to which type they apply? Label(s)?
* Existing open issues sorted by oldest to newest
https://github.com/airshipit/treasuremap/issues?page=1&q=is%3Aissue+is%3Aopen+-label%3Aairshipv1+sort%3Acreated-asc
* Review for current relevance
* Assign priority as most do not have

How do we indicate tha a function belongs to a type:
- New issue explicitly stating include function X in type y, by tis mechanism ?
-
### Dec 9, 2020
#### Category labels
With the design evolution, the original "component/xxx" labels have become stale. At the same time, we are trying to be more fine grained in identifying the outstanding work & priority.

We have dropped the component labels and are introducing the following new categories in order of importance for all open, unassigned issues:

| Label | Description |
| ------------------ | --------------------------------------------------- |
| 1-Core | Relates to airshipctl core components (i.e. go code)|
| 2-Manifests | Relates to manifest/document set related issues |
| 3-Container | Relates to plugin related issues |
| 4-Gating | Relates to issues with Zuul & gating |
| 5-Documentation | Improvements or additions to documentation |
| 6-upstream/project | Requires a change to an external project. The "project" should be the project name (e.g. clusterctl, helm, metal3, etc.) |
| 7-NiceToHave | Relates to issues of lower priority that are not part of critical functionality or have work arounds. When these get pulled in, should get one of the above category labels |

References:
https://github.com/airshipit/airshipctl/labels
https://github.com/airshipit/airshipctl/labels/1-Core
https://github.com/airshipit/airshipctl/labels/2-Manifests
https://github.com/airshipit/airshipctl/labels/3-Container
https://github.com/airshipit/airshipctl/labels/4-Gating
https://github.com/airshipit/airshipctl/labels/5-Documentation
https://github.com/airshipit/airshipctl/labels/6-upstream/helm
https://github.com/airshipit/airshipctl/labels/6-upstream/metal3-io
https://github.com/airshipit/airshipctl/labels/7-NiceToHave

All open treasuremap issues are labeled as 2-Manifests
https://github.com/airshipit/airshipctl/treasuremap/2-Manifests

Lets cchange
#### "Ready for Review" without assignees
There's a handful of issues that are currently "Ready for Review" that were likely referenced with the "Related Change" commit tag. Look to see if any can be closed.
https://github.com/airshipit/airshipctl/issues?q=is%3Aissue+is%3Aopen+no%3Aassignee+label%3A%22ready+for+review%22

#### Priority of open treasuremap issues
Several open treasuremap issues that do not have priority. Review to see if they are stale or should be updated with a priority
https://github.com/airshipit/treasuremap/issues?q=is%3Aissue+is%3Aopen+-label%3Apriority%2Fcritical+-label%3Apriority%2Fmedium+-label%3Aairshipv1

### Dec 2, 2020
#### V2.0 Checkpoint
* Discuss plan for any beta sub-releases before GA.
* https://github.com/airshipit/airshipctl/issues/354 < Revisit based on work Sean has done
* If we do, what would be included and what are target dates?
* Are there high priority [unassigned issues](https://github.com/airshipit/airshipctl/issues?q=is%3Aissue+is%3Aopen+no%3Aassignee+milestone%3Av2.0) that should be addressed sooner rather than later?
* Do we want to organize the open issues into an ordered backlog? Can coordiante offline.

- sub releases ...
- Airship
What is an Airship version
Is it a collection of airship components..?
Or every components has the same version,
i.e.
- v2.0
- v2.3

we need to define a mechanism to manage interelated consistency between subcomponets.
define :
* v[MAJOR RELEASE].[MINOR RELEASE].[POINT RELEASE]

- Airshipctl
- Periodically..
- 2 weeks aling with sprints ?
- Monthly..
- How do we release
- Push a tag/...
details to follow
- Release Numbering/Version
- v2.0-beta.1
- v2.0-beta.2
- ....
- v2.0.0-beta.n
- v2.0.0
- v2.0.1
- v2.0.2
- v2.0.3
- ImageBuilder
- Hostconfig
- Release Numbering/Version
- v2.0.0-beta.1
- v2.0.0
- v2.0.3 - No changes

* https://github.com/airshipit/airshipui/issues
There are currently 15 open airshipui issues (including 1 documentation) and none of them are currently assigned. Need to go through these issues to ensure each is still valid and assign a priority so that we can put focus on a few of these for design discussion and implementation. It seems the higher priority items are probably 41, 45, 55, 48, 56, 57, 58.

### Nov 18, 2020
### Nov 11, 2020
* [Review stale issues](https://github.com/airshipit/airshipctl/issues?q=is%3Aissue+is%3Aopen+label%3Astale) < click for filter
* [V2.0 issues Ready for Review](https://github.com/airshipit/airshipctl/issues?q=is%3Aissue+is%3Aopen+label%3A%22ready+for+review%22+milestone%3A%22v2.0%22) < Any critical ones needing more immediate attention?

### Oct 21, 2020
* Host Config Operator issues (new project to triage coming out of 10/15 design call)
* https://github.com/airshipit/hostconfig-operator/issues
* Will #1 serve as a model for the rest?
* Integration with treasuremap, are we good with one general integration issue, or will we need 1:1 with each host-config-operator issue?
* https://github.com/airshipit/treasuremap/issues/41

### Oct 14, 2020

How do we keep documentation up to date.
MAtt mentioned some model that openstack helm is using to gate the documentation. TBD ...

### Oct 7, 2020

#### New Issues
* Need to define a CRD/Schema for the Variable Catalogue's
* Do we need multiple Kind's?
* Should try to keep the number of catalogues to a minimum.
* i.e. Versions vs Network is very different?
* So that is the reason why we need multiple.
* This should be define in the airshipctl/tree/master/pkg/api/v1alpha1 like other objects.
* Let's start with the Versions catalogue (https://github.com/airshipit/airshipctl/blob/master/manifests/function/airshipctl-catalogues/versions-airshipctl.yaml) to determine the ability of driving this with a structured CRD.

* Need an issue to deal with "remote direct to use phases"
* That is associated with this patchset.

Related Change #752363
Subject: Refactor remote direct to use phases
Link: https://review.opendev.org/752363
Status: NEW
Owner: Kostyantyn Kalynovskyi ([e-mail])

Approvals
Code-Review
+1 Vladislav Kuzmin
+1 Vladimir Kozhukalov
+1 srinivasa muly
Verified
+1 Zuul
Workflow
-1 Kostyantyn Kalynovskyi
Last Updated: 2020-10-06 11:00:07 CDT
### Sept 30, 2020

Is the time right to introduce schema / CRDs for catalogues?
* Today they're all un-schema'd VariableCatalogue objects
* Opportunities to fat finger all kinds of things
* Catalogues are going to have per-site content, so need a good UX
* If we implement this Now, need to delete VariableCatalogues in a few cases
* Related to the no-op "VariableCatalogue plugin script"
* If we implement this Later... I thought Kustomize Functions
bought us something, but I can't think of what that would be
* Proposal: implement it Now, and do JSON patch deletes on
catalogues when needed