Hiroki Kawahara
Hiroki Kawahara
ちょっとairflow詳しくないんで、どういうふうに使うのか想像できないです 具体的に教えてもらっていいですか
args に余計な要素がある場合にエラーにならない問題であると認識している 要検証
prometheus に対応したい #101 各VMのリソース監視などをどうするかは考える必要がありそう とりあえずuiにgrafanaを組み込んでおくのはありっぽい
そこまで時間がかからずにそれができるならいいんですけどね libguestfs もなかなかしんどそうですし
https://github.com/n0stack/n0stack/tree/master/n0core/pkg/driver/n0deploy http://docs.n0st.ac/en/master/developer/adr/n0deploy.html 実験的にn0deployというものを実装してみている
色々考え途中だったことについてここにつらつらと書いていきます。整理できていなかったものなので支離滅裂だと思います。すみません。 ### `annotations.*/request_node_name` について - なぜ、現在のn0coreの処理に絶対に必要なパラメータをannotationにしているかというと、スケジューリングを実装した場合、エンドユーザーには必要がないパラメータであるからです - また、VMとBSが同じノードにいるという制約上、 `MigrateBlockStorage` のような内部向けエンドポイントを持つ必要があるのではないかと考えました - しかし、iscsiなどのプロトコルを利用した場合、 `MigrateBlockStorage` というエンドポイントは必要がなくなるためあくまで一般的なAPIを目指し、実装に依存するものだけannotationに含めるn0proto にどのように入れ込むか頭を悩ませていました。 - マルチリージョンとかになると需要がありそう?
現在はvm、ネットワーク、ブロックストレージのすべてがモビリティを持っていないので、スケジューリングや移動などが難しい状況であると認識しています 自分は先にVXLANやVLANなどを使ったネットワークのモビリティと、Cephなどの仮想ストレージ基盤を使ったブロックストレージのモビリティの確保が先に必要になるかと思っていました
ちなみにしばらくやるつもりはない n0protoが下位互換性をなくす、我が家のサーバを刷新するなどのタイミングでやるつもり
depends on #217
depends on #224