Bug: ProgressDeadlineExceeded not set for CE-level resolution/apply failures

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

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

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
52/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
静か
技術スタック
go
領域
backend

調査の方向性

ファイルやテストは指定されていません。まず CE レベルの解決と apply のステータス処理を追跡します。完了条件は、成功したインストールから変更された CE が新しい progression の開始を記録し、設定された期限の経過後に Progressing=False/ProgressDeadlineExceeded に到達し、解決または apply が成功するまでその状態に留まることです。

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

説明

Consider this scenario:

  1. At T0, user creates a CE, which leads to a successful installation:
  • Progressing=True/Succeeded
  • lastTransitionTime=T0
  1. Much later at T100, user modifies the CE to ask for a non-existent version:
  • Progressing=True/Retrying
  • lastTransitionTime=T0 (because this only changes when status changes)

What currently happens at T100+progressDeadlineMinutes is.... nothing. We should exceed the deadline at that point, but there is nothing in the CE API anywhere that records when we've actually started progressing from steady state again.

If we change (1) such that it results in Progressing=False/Succeeded, then (2) would transition to Progressing=True, which means lastTransitionTime would also be set to T100, which would mean would could close that scenario's progressing deadline bug by setting Progressing=False/ProgressDeadlineExceeded, which we wouldn't subsequently change until we successfully resolve/apply the COS again.

Originally posted by @joelanford in https://github.com/operator-framework/operator-controller/issues/2810#issuecomment-5231204488

主要言語
Go
スター
213
フォーク
85
平均マージ
1日 8時間
マージ済み PR（30日）
36

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

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

はじめの一歩

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

operator-framework/operator-controller のほかの issue

operator-framework/operator-controller の issue をすべて見る

似ている issue

Go の issue をもっと見る

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

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