Итак ... У меня есть случай, когда я по существу делаю:
resource "openstack_compute_instance_v2" "foo" {
count = N
...
network {
...
}
network {
...
}
}
resource "ovh_domain_zone_record" "foo" {
count = N
...
target = "${openstack_compute_instance_v2.foo.*.network.1.fixed_ip_v4[count.index]}"
}
, и все замечательно ... пока это не так.
Если создание ресурса длясбой экземпляра с частичным состоянием, когда экземпляр создан, но не запущен, ему также не назначено ничего в network.1.fixed_ip_v4
* ovh_domain_zone_record.foo: 1 error(s) occurred:
* ovh_domain_zone_record.foo[2]: index 2 out of range for list openstack_compute_instance_v2.foo.*.network.1.fixed_ip_v4 (max 2) in:
${openstack_compute_instance_v2.foo.*.network.1.fixed_ip_v4[count.index]}
, поэтому кажется, что проблема заключается в том, что если ресурс со счетчикомприводит к непоследовательному состоянию во всех его экземплярах (некоторые имеют значение атрибута, некоторые нет), и на этот атрибут позднее ссылается другой ресурс с тем же количеством для создания соответствующих «родственных» ресурсов (в моем случае DNS-имена для хостов) тогда список, полученный в результате интерполяции $ {resource. *. attribute}, не будет содержать нулевых записей, где произошел сбой основного ресурса.Вместо этого он будет короче от подсчета по количеству неудач, и, следовательно, terraform потерпит неудачу с количеством неисправных ресурсов, так как последние экземпляры родственных ресурсов не смогут получить их информацию.
Во-вторых, это будет означать, что еслине удалось создать основной ресурс, скажем, для второго экземпляра, для третьего не удастся создать связанный ресурс.Тогда весь TF будет жаловаться, а не действовать вообще, поэтому он не будет создан неправильно и на самом деле не является проблемой.
Вопрос в том, как создавать наборы связанных ресурсов при использовании count = N?