v0.9.2
0.9.0 の EC2 永続 Workspace を実デプロイとして動かして分かった問題の追補です。 事前に焼いた golden スナップショットから作った home はまったく起動できず、golden を 手で焼く手順には終わらない工程がありました。
- Workspace イメージが変わったら、Control Plane が golden を焼き直します。
焼き直しはリリースごとの手作業で、忘れたことに気づく手掛かりはログの警告だけでした。
Control Plane は予約した種を起動して home を候補として取得し、その候補から 2 つ目の
予約メンバーを起動して、そちらが立ち上がったときだけ候補を公開します。起動しない候補は
理由付きで却下として残します。プールの空きが 2 つ未満のときは始めず、同じイメージで
候補が 2 回失敗したら諦めます。
AF_ECS_EC2_GOLDEN_AUTOBAKE=0で無効にできます。
- golden スナップショットから作った home がまったく起動せず、タスクが永久に再起動して
いました（理由を述べるログもありません）。 golden の home には種のリンクが既に入って
いる一方、新規ユーザーの keep ボリュームは空なので、entrypoint は
~/.configを存在 しない先へ向けたまま自滅していました。空の home では踏みようがないため、「golden から 新規ユーザーを作り始めるデプロイ」でだけ現れます。 - home ボリュームができる前に Start が失敗した Workspace が、毎分・永久に再試行されて いました。 期限をボリュームの作成時刻から測っていたため、ボリュームを持たない行には 期限を測る時計がありませんでした。Workspace 自身の作成時刻を使うようにしました。
- golden の手焼きが、手順どおりには完了できませんでした。 手順は「スイーパーが
スロットを解放するのを待つ」と書いていましたが、Stop は home を付けたままにするので、
bake-golden.shはいくら待ってもスロットを拒否し続けました。インスタンスが稼働中の ときだけ拒否するようにしました。周辺の説明も実測に合わせて訂正しました——待ち時間は 実際に使用したブロック量に比例すること、種はサインインできるメンバーであること、種に リポジトリを clone してはならないこと。
Upgrade notes
Section titled “Upgrade notes”ecs-ec2 以外のデプロイでは作業はありません。ecs-ec2 では本リリースから自動焼き直しが
有効なので、イメージタグを動かした後、Control Plane がプールのスロットを 2 つ使って
golden を焼き、起動することを確かめます。それが終わるまで新規ユーザーの home は空から
作られます（golden が無かった頃と同じ、遅い初回起動です）。前のイメージで焼かれた golden
は使わずに拒否するためです。