Flight Plan
- Flight Plan
- Old Etherpad https://etherpad.openstack.org/p/Airship_FlightPlan
- Scope for Airship 2 Release
- Projects
- Discussions
- June 9, 2021
- May 26, 2021
- May 19, 2021
- May 5, 2021
- April 28, 2021
- April 21, 2021
- April 14, 2021
- April 7, 2021
- March 31, 2021
- March 24, 2021
- March 17, 2021
- March 10, 2021
- March 3, 2021
- Feb 25, 2021
- Feb 17, 2021
- Feb 10, 2021
- Feb 3, 2021
- Jan 27, 2021
- Jan 20, 2021
- Jan 13, 2021
- Jan 6, 2021
- Dec 16, 2020
- Dec 9, 2020
- Dec 2, 2020
- Nov 18, 2020
- Nov 11, 2020
- Oct 21, 2020
- Oct 14, 2020
- Oct 7, 2020
- Sept 30, 2020
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
Discussions
June 9, 2021
- #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 suffice to cover Docker or is that just a temporary deal?
ISSUES:
- 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.
- 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
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
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
- 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:
- Branch Treasuremap v2 -> new v2.0 branch (today)
- Stabilize v2.0 branch, pin versions.yaml airship components to v2.0.0 tags in v2.0 branch
- 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:
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
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
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
- 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
- Should we create a new
type: multi-tenant
label? Currently have type: airship-core
& type: network-cloud
. Done
- 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
- 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
- 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
- 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 :
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
- 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"ready+for+review"
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.
- If we do, what would be included and what are target dates?
- Are there high priority unassigned issues 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.
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
Oct 21, 2020
- Host Config Operator issues (new project to triage coming out of 10/15 design call)
- Integration with treasuremap, are we good with one general integration issue, or will we need 1:1 with each host-config-operator issue?
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
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