1.29 upgrade notes (#834)

* refresh generic upgrade page

* blurb about ceph and gaps in the main release notes

* refresh ceph page with new ceph-csi usage

* refresh specific 1.29 upgrade page

* tweak o7k integration page

* blurb about o7k and cloud integrators in the main release notes

* Update pages/k8s/1.29/release-notes.md

Co-authored-by: Louise K. Schmidtgen <[email protected]>

* full stops look funny in lists

* sync general and specific release notes

* add big warning at the top of the upgrade page

* Update pages/k8s/1.29/upgrading.md

---------

Co-authored-by: Louise K. Schmidtgen <[email protected]>
Co-authored-by: Nick Veitch <[email protected]>

pages/k8s/1.29/release-notes.md

@@ -15,7 +15,7 @@ toc: False
 ---
 # 1.29
 
-### February 23, 2024 - `charmed-kubernetes --channel 1.29/stable`
+### February 12, 2024 - `charmed-kubernetes --channel 1.29/stable`
 
 The release bundle can also be [downloaded here](https://raw.githubusercontent.com/charmed-kubernetes/bundle/main/releases/1.29/bundle.yaml).
 
@@ -24,8 +24,8 @@ The release bundle can also be [downloaded here](https://raw.githubusercontent.c
 ### Charmed Operator Framework (Ops)
 
 We're pleased to announce the completion of the Charmed Kubernetes refactor that began
-last year. Charms have moved from the `reactive` and `pod-spec` styles to the `ops`
-framework in order to enable access to common charm libraries, gain better Juju support,
+last year. Core charms have moved from the `reactive` and `pod-spec` styles to the `ops`
+framework. This shift aims to enable access to common charm libraries, gain better Juju support,
 and provide a more consistent charming experience for community engagement.
 
 ### Out of the box monitoring enhancements
@@ -38,6 +38,20 @@ observability tools.
 This release expands our COS integration so that it includes rich monitoring for the
 control plane and worker node components of Charmed Kubernetes.
 
+### Ceph CSI
+
+Ceph CSI resource management has been decoupled from the `kubernetes-control-plane`
+charm. All new deployments should leverage the [ceph-csi][] charm for Ceph storage
+provisioning, including support for CephFS. See the [updated documentation][ceph] for
+details on deploying Charmed Kubernetes with Ceph support.
+
+### OpenStack integration
+
+OpenStack capabilities (including cinder storage and cloud provider) have been decoupled
+from the `kubernetes-control-plane` charm. All new deployments should leverage the new
+`openstack-integrator`, `openstack-controller-manager`, and `cinder-csi` charms. See the
+[updated documentation][openstack] for more details.
+
 ### NVIDIA GPU Operator
 
 The new [nvidia-gpu-operator][] charm simplifies the management of NVIDIA GPU resources
@@ -73,7 +87,29 @@ support and is offered as an alternative to the default Calico CNI.
 All bug fixes and other feature updates in this release can be found at
 [the launchpad milestone page for 1.29](https://launchpad.net/charmed-kubernetes/+milestone/1.29).
 
-## Known Issues
+<a id='notes-issues'> </a>
+
+## Notes and Known Issues
+
+### Integration gaps
+
+While Charmed Kubernetes core charms have been rewritten in the `ops` framework, some
+integrations with other charms in the Juju ecosystem are not available in this release.
+If your deployment depends on the following, we recommend remaining on Charmed Kubernetes
+1.28 until compatible support is provided in a subsequent release:
+
+- AWS IAM authentication: [aws-iam](https://charmhub.io/aws-iam)
+- Keystone authentication: [keystone](https://charmhub.io/keystone)
+- Vault storage: [vault](https://charmhub.io/vault)
+
+### Cloud integrators
+
+Direct integration between `[aws|azure|gcp|openstack]-integrator` charms and
+`kubernetes-control-plane` has been removed in this release. The recommended method for
+enabling native cloud features is to use the respective out-of-tree cloud provider
+charms. See the cloud-specific documentation for details.
+
+### Bugs
 
 A list of known bugs scheduled to be fixed in the first maintenance release can be found
 on the [1.29+ck1 milestone page](https://launchpad.net/charmed-kubernetes/+milestone/1.29+ck1).
@@ -93,6 +129,9 @@ relevant sections of the [upstream release notes][upstream-changelog-1.29].
 <!--LINKS-->
 
 [rel]: /kubernetes/docs/release-notes
+[ceph-csi]: https://charmhub.io/ceph-csi?channel=1.29/stable
+[ceph]: /kubernetes/docs/ceph
+[openstack]: /kubernetes/openstack-integration
 [nvidia-gpu-operator]: https://charmhub.io/nvidia-gpu-operator?channel=1.29/stable
 [gpu-workers]: /kubernetes/docs/gpu-workers
 [install-local]: /kubernetes/docs/install-local

pages/k8s/1.29/upgrading.md

@@ -13,9 +13,18 @@ layout: [base, ubuntu-com]
 toc: False
 ---
 
+<div class="p-notification--caution is-inline">
+  <div markdown="1" class="p-notification__content">
+    <span class="p-notification__title">Caution:</span>
+    <p class="p-notification__message">This release includes topology changes and new best practices for integrating <strong>Charmed Kubernetes</strong> with other Juju ecosystem solutions. Be sure to read and understand the *What's new* section of the <a href="/kubernetes/docs/1.29/release-notes">1.29 release notes</a> prior to upgrading your cluster.<br/>
+    <br/>
+    Additionally, some features from previous <strong>Charmed Kubernetes</strong> releases are not yet available in this release. If you rely on a component identified as an *Integration gap* in the <a href="/kubernetes/docs/1.29/release-notes#notes-issues">Notes and Known Issues</a> section of the release notes, remain on release 1.28 (or earlier) and do not upgrade to 1.29 at this time.</p>
+  </div>
+</div>
+
 It is recommended that you keep your **Kubernetes** deployment updated to the latest available stable version. You should also update the other applications which make up **Charmed Kubernetes**. Keeping up to date ensures you have the latest bug-fixes and security patches for smooth operation of your cluster.
 
-You can check the latest release version on the [Kubernetes release page on GitHub][k8s-release].
+New minor versions of **Kubernetes** are set to release three times per year. You can check the latest release version on the [Kubernetes release page on GitHub][k8s-release].
 
 <div class="p-notification--information is-inline">
   <div markdown="1" class="p-notification__content">
@@ -52,7 +61,7 @@ You should also make sure:
 -   Your Juju client and controller/models are running the same, stable version of Juju (see the [Juju docs][juju-controller-upgrade]).
 -   You read the [Upgrade notes][notes] to see if any caveats apply to the versions you are upgrading to/from.
 -   You read the [Release notes][release-notes] for the version you are upgrading to, which will alert you to any important changes to the operation of your cluster.
--   You read the [Upstream release notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.29.md#deprecation) for details of deprecation notices and API changes for Kubernetes 1.29 which may impact your workloads.
+-   You read the [Upstream release notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.29.md#deprecation) for details of Kubernetes deprecation notices and API changes that may impact your workloads.
 
 It is also important to understand that **Charmed Kubernetes** will only upgrade,
 and migrate if necessary, components relating specifically to elements of
@@ -68,7 +77,7 @@ deprecated APIs.
   </div>
 </div>
 
-## Upgrading the Machine's Series (required for machines currently running 18.04(Bionic))
+## Upgrading the series (required for machines currently running Ubuntu 18.04)
 
 All of the charms support [upgrading machine series via Juju](https://juju.is/docs/juju/manage-machines#heading--upgrade-a-machine).
 As each machine is upgraded, the applications on that machine will be stopped and the unit will
@@ -84,12 +93,13 @@ outside of the cycle of new releases of Kubernetes.
 
 This includes:
 
+- calico or other CNI
+- coredns
 - easyrsa
 - etcd
-- flannel, calico or other CNI
 
 Note that this may include other applications which you may have installed, such as
-Elasticsearch, Prometheus, Nagios, Helm, etc.
+Ceph, Docker Registry, MetalLB, Volcano, etc.
 
 <a id='upgrading-containerd'> </a>
 
@@ -117,15 +127,16 @@ juju refresh etcd --channel=1.29/stable
 To upgrade **etcd** itself, you will need to set the **etcd** charm channel config.
 
 To determine the correct channel, go to the
-[releases section of the bundle repository][bundle-repo] page and check the relevant
-**Charmed Kubernetes** bundle. Within the bundle, you should see which channel
-the **etcd** charm is configured to use.
+[releases section of the bundle repository](https://github.com/charmed-kubernetes/bundle/tree/main/releases)
+and check the relevant **Charmed Kubernetes** bundle. Within the bundle, you will see
+which channel the **etcd** charm is configured to use.
 
 Once you know the correct channel, set the **etcd** charm's channel config:
 
 ```bash
 juju config etcd channel=3.4/stable
 ```
+
 ### Upgrading MetalLB (if used)
 
 Previous versions of Charmed Kubernetes adopted a two charm approach for MetalLB. These were deployed in a K8s model with the suggested name `metallb-system`.
@@ -171,18 +182,18 @@ juju refresh easyrsa --channel=1.29/stable
 ```
 
 Any other infrastructure charms should be upgraded in a similar way. For
-example, if you are using the flannel CNI:
+example, if you are using the calico CNI:
 
 ```bash
-juju refresh flannel --channel=1.29/stable
+juju refresh calico --channel=1.29/stable
 ```
 
 <div class="p-notification--caution">
   <p markdown="1" class="p-notification__response">
     <span class="p-notification__status">Note:</span>
 Some services may be briefly interrupted during the upgrade process. Upgrading
-your CNI (e.g. flannel) will cause a small amount of network downtime. Upgrading
-<strong>easyrsa</strong> will not cause any downtime. The behaviour of other
+your CNI (e.g. calico) will cause a small amount of network downtime. Upgrading
+easyrsa will not cause any downtime. The behaviour of other
 components you have added to your cluster may vary - check individual documentation
 for these charms for more information on upgrades.
   </p>
@@ -193,8 +204,8 @@ for these charms for more information on upgrades.
 Before you upgrade the **Kubernetes** components, you should be aware of the exact
 release you wish to upgrade to.
 
-The **Kubernetes** charms use **snap** _channels_ to manage the version of
-**Kubernetes** to use. Channels are explained in more detail in the
+The **Kubernetes** charms use snap _channels_ to manage the version of
+**Kubernetes** they use. Channels are explained in more detail in the
 [official snap documentation][snap-channels], but in terms of **Kubernetes** all you
 need to know are the major and minor version numbers and the 'risk-level':
 
@@ -205,7 +216,7 @@ need to know are the major and minor version numbers and the 'risk-level':
 | beta       | Latest alpha/beta of Kubernetes for the specified release |
 | edge       | Nightly builds of the specified release of Kubernetes     |
 
-For most use cases, it is strongly recommended to use the 'stable' version of charms.
+For most use cases, it is strongly recommended to use the _stable_ charm versions.
 
 ### Upgrading the **kube-api-loadbalancer**
 
@@ -222,11 +233,6 @@ that of NGINX rather than Kubernetes.
 
 ### Upgrading the **kubernetes-control-plane** units
 
-**Note**: Older versions of Charmed Kubernetes used `kubernetes-master` as the charm name. This has been updated
-to `kubernetes-control-plane`. However, it is not possible to rename a deployed application. If you 
-originally installed version 1.23 or before, your units will follow the old naming scheme and you should
-substitute `kubernetes-control-plane` for `kubernetes-master` in the following commands.
-
 To start upgrading the Kubernetes control plane units, first upgrade the charm:
 
 ```bash