---
tags: Discussion
---
# Day 2 Upgrade

https://github.com/airshipit/treasuremap/issues/175
- Managing Airship 2 Releases within a site.
- Discovery - Notifications of when upgrade for a workload is needed/available (upgrade decision)
- Pre-step
- Manifest structures for upgradeable workload resources to support the upgrade path
- Upgrade phase plan
- Dependency/pre-requisite checking and validation prior to applying upgrades
- upgrade rules implemented as a manifest
- Applying an upgrade to a target cluster and/or sub-cluster(s)
- Dry runs?
- Maintenance window?
- Upgrade validation/error handling/rollback
- Rollback?

Next steps:
- Prioritize upgrades from table: k8s, CAPI, ironic, containerd
- Release management. Do we need to upgrade to a specific version
- Define metadata for upgrades: is it valid; reboot needed; impacts to other running item (control plane, workloads, etc.)
- OS - do we need another server for rolling upgrade; validate the flow
- Greenfield of a new version of a component
- Brownfield upgrade from a specific version to the new version