Create dedicated documentation page on upgrade procedures

オープン
#773 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
35/100
issue の種類
ドキュメント
明瞭さ
おおむね明確
活発さ
停滞
技術スタック
helm, kubernetes

調査の方向性

まず、Antora リポジトリにある既存のアップグレードおよびリリースノートのドキュメントを見つけ、次に issue で説明されている platform、product、CRD、operator、Helm、OpenShift の手順を確認します。アップグレードシーケンス、任意の reconciliation の一時停止、カスタムイメージ、pod の再起動、CRD の制限事項、および関連するリリースノートを扱う専用ページを追加します。記載されている各シナリオと注意事項が、1 つの見つけやすいページに明確に文書化されていれば完了です。

索引モデルが issue の本文から書いたものです。

説明

customer-request

Our documentation should contain a dedicated page on our possible upgrade scenarios.

Upgrades of the platform can be done in multiple steps:

  • Optional: Set reconciliationPaused to true for some or all of your products
  • Update CRDs
  • Update Operators
  • Optional: Set reconciliationPaused to false

Then we also have the product updates

  • Upgrade productVersion

There are a few extra things we should document or take into consideration:

  • Extra steps/caution needed when using custom images
  • Document that (and why) pods will restart after an operator upgrade
  • Document the fact that Helm can't manage CRDs: https://helm.sh/docs/chart_best_practices/custom_resource_definitions/
  • Document OpenShift upgrade procedure
  • Hint at platform release notes
  • Hint at always having to check the release notes of the underlying products
主要言語
CSS
スター
13
フォーク
14
平均マージ
4日 8時間
マージ済み PR(30日)
10

コントリビューションガイド

このリポジトリのコントリビューションガイドは索引されていません

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

stackabletech/documentation のほかの issue

stackabletech/documentation の issue をすべて見る

似ている issue

DevOps の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。