ルータの帯域変更でサブネットの再作成が必要になる

[yamamoto-febc]

問題

以下のようなコードにおいてルータの帯域変更を行うとサブネットの再作成が必要になる。

resource sakuracloud_internet "foobar" {
  name = "foobar"
}

resource "sakuracloud_subnet" "foobar" {
  internet_id = sakuracloud_internet.foobar.id
  next_hop    = sakuracloud_internet.foobar.min_ip_address
}

運用フェーズにおいてはサブネットの再作成は影響が大きく、tfstateの編集や再インポートなどで回避することになり煩雑だし事故の元である。

対応案

この問題は帯域変更を行うとスイッチ+ルータ(sakuracloud_internet)のリソースIDが変更されてしまうことにある。 現在はスイッチ+ルータとサブネットが親子関係で別リソースになっていることでサブネット側でIDが変更されたことを検知できない。

利用者側でtfファイルにてignore_changesを付与する、またはプロバイダー側で親子関係を1リソースで表すことで対応できる。

親子関係を1リソースで表す

パケットフィルタ(sakuracloud_packet_filter)に実装例がある。 1リソースになることで帯域変更時のID変更に追随かのうとなるためこの問題は発生しなくなるが、リソースのスキーマが変更されるため互換性維持(現在の親子関係)についても一定期間維持しておく必要があることに注意が必要である。