Это не усложнение алгоритма сравнения. Это сам алгоритм сравнения как он есть. Вот искажение стейта это попытка оптимизации сравнения, необходимость которой ещё нужно обосновать.

У всего своя задача. Стейт должен просто отражать последнее известное состояние системы. И пусть просто отражает. Ответ на вопрос "соответствует ли прошлое состояние текущему" должен давать код провайдера. Пусть даёт.

логично.
спасибо за фидбек, посмотрю на это с другой стороны, скорее всего я начал копать не туда )

Вчитался в доку. По-видимому StateFunc для этого и сделан. В том числе. Преобразовывать данные перед сравнением. Тогда мне кажется, нужно убрать StateFunc для TypeList. Ты же уже каждый элемент преобразовал. Со списком терраформ сам разберётся.

он эксперимента ради там остался в коде, который я привел выше.

Но он не работает.

То есть в стейт все равно сохраняется “зАбОрЧиК”.
И мне приходится дополнительно уже в самом CreateContext извлекать []interface{} неймсерверов, преобразовывать их руками в нижний регистр и делать снова data.Set(“nameservers”, …)

То есть очень много лишних телодвижений.

Все-таки все больше склоняюсь к мысли чтобы юзеру бросать ошибку, а в остальном пускай он сам уже или делает lower(…) в самом терраформе, или иными словами - предоставляет валидные данные.

Не хорошо. Юзер не виноват. Доменные имена case insensitive по RFC. Тут такое ещё дело. По-моему тут должен быть не list, а set. Разве нужно что-то менять, если имена серверов местами переставили? Тогда преобразование регистра можно будет засунуть в SchemaSetFunc, и проблема отпадёт просто по построению.

имеете ввиду schema.TypeSet ?

Угу. Вместо TypeList.

мм, хороший вопрос.
Вообще да, от перемен местами ничего не должно меняться.

Я волнуюсь по поводу синтаксиса.
Надо посмотреть какой синтаксис будет с TypeSet, будут сложности если я сделаю Breaking changes..

Но вы натолкнули меня на ряд важных мыслей

Тут не на удобство нужно смотреть. Если доменная модель предполагает, что порядок не важен и дубликатов не должно быть, то это не список, а множество, и всё тут.

ну по поводу порядка это можно избежать, если порядок другой - я могу сохранить текущий порядок в стейте
но если юзер, конечно, сам поменяет в терраформ файле - вот тогда будет залёт

Подскажите, как правильно сделать, если я в провиженере хочу поставить другое ядро и ребутнуть ноду

  provisioner "remote-exec" {
    inline = [
      "sudo apt-get upgrade -y",
      "sudo apt-get install -y linux-generic-hwe-20.04-edge",
      "sudo shutdown -r now"
    ]
  }

сейчас как-то так написал, но ожидаемо фейлится
нужен какой-то механизм, ожидающий поднятие ноды

TypeSet это и есть механизм, который решает вопросы с порядком и уникальностью.

А юзер не то, чтобы поменяет порядок, он может захотеть брать список хостов из списка ресурсов, описанных через for_each, а там порядок никто не гарантирует. Потому что под капотом независимые ресурсы опрашиваются параллельно. Кто первый посчитался, того и тапки. И будет apply флапать.

В общем, если эти хосты по постановке задачи являются множеством (уникальные неупорядоченные объекты), то и реализовывать нужно через TypeSet.

это очень хороший момент
я перед проектированием смотрел другие провайдеры

например, у того же амазона, route53_zone рекорд, там name_servers сделаны тоже листом.

Это, похоже, было моей ошибкой смотреть “как у других”

Если об этом речь: https://github.com/hashicorp/terraform-provider-aws/blob/main/aws/resource_aws_route53_zone.go#L89 , то там computed: true, это информационное поле, оно изменений не вызывает. Будет output шуметь, ничего страшного.

А вот, например, значения aws_route53_record.records уже сделаны через TypeSet: https://github.com/hashicorp/terraform-provider-aws/blob/main/aws/resource_aws_route53_record.go#L233

ага, тоже только что увидел.
И синтаксически я же могу внутренний элемент сделать просто стрингой и для юзера в принципе ничего не поменяется, это для меня хороший выход.

В любом случае вы мне много интересных вещей подсказали которые бы я гуглил долго, за что вам большое спасибо.

Они, я так понял, просто используют стандартный хешстринг, а вот хз как они с регистром буков воюют.

всем салют
кто то юзает gavinbuney/kubectl в azure aks ?
у меня с таким конфигом не коннектится к кубу

failed to create kubernetes rest client for update of resource: Get "http://localhost/api?timeout=32s": dial tcp 127.0.0.1:80: connect: connection refused

provider "kubectl" {
  host                   = module.aks.admin_host
  username               = module.aks.admin_username
  password               = module.aks.admin_password
  client_certificate     = base64decode(module.aks.admin_client_certificate)
  client_key             = base64decode(module.aks.admin_client_key)
  cluster_ca_certificate = base64decode(module.aks.admin_cluster_ca_certificate)
}

пытаюсь цепануться с админскими кредами к кубу

причем вроде обычный кубернетес провайдер с этими кредами работает

На 127.0.0.1:80 есть апи кубера?