Flight Plan - HackMD

--- 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 ### 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 (kkalynovskyi@mirantis.com) 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

Example	Syntax
Header	# Header
Unordered List	- Unordered List
Ordered List	1. Ordered List
Todo List	- [ ] Todo List
Blockquote	> Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th	19^th^
H₂O	H~2~O
Inserted text	++Inserted text++
Marked text	==Marked text==
Link	[link text](https:// "title")
Image	![image alt](https:// "title")
`Code`	`Code`
`var i = 0;`	```javascript var i = 0; ```
	:smile:
Externals	{%youtube youtube_id %}
L^aT_eX	$L^aT_eX$
This is a alert area.	:::info This is a alert area. :::