owned this note   changed 4 years ago  
Published Linked with GitHub

Flight Plan

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 < 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:

  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

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

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
  • 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.

      • 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

Oct 21, 2020

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

  • 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
Select a repo