vRA да, но если это будет пакетным предложением - почему нет

это сразу автоматом конкурент ансиблу и таверу

SSE уже этим был и работал отлично и стоил копейки

не совсем так, SSE как all in one installer будет жить еще два года на enterprise.saltstack.com

а потом будет как ova в vra

я не думаю что его сейчас купить можно будет

Продажи уже прекращают с 31 января, с 1 февраля только вместе VRA

Пару лет назад тестил, так и не смог понять как через этот пеппер указывать saltenv=branchname pillarenv=branchname
В тюитоге так и стоить внутри контейнера с мастером TeamCity agent 🤣😂

И все ждут пока одна задача выполнит я, т. К. другие в очереди 🤦‍♂

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

а больше ни кому не показалось что он не всё умеет ?

Ещё тогда он не умел запускать оркестрацию, а это жирный -

у солта есть аналог ансиблового wait_for? кроме salt.states.http.wait_for_successful_query. нужно чекать доступность порта и только потом переходить к след таску

у нас кастомный стейт для этого

у меня в заметках такое запасено

influxdb:
 pkg.installed: []
 service.running:
   - name: influxdb
 cmd.run:
   - name: until nc -z localhost 8086; do sleep 1; done
   - timeout: 10
   - onchanges:
     - service: influxdb

influxdb-user-example:
 influxdb_user.present:
   - name: example
   - passwd: example
   - require:
     - cmd: influxdb

но по факту никогда не использовал :)

Мы юзаем cmd.run и https://docs.saltproject.io/en/latest/ref/states/requisites.html#retrying-states

а скажите плез, если стейт зависит от какой-то реалтаймовой инфы с миньонов, например собираем кластер где каждый инстанс должен знать о каждом, то инфу удобно брать из майна раннером на мастере, типа вот так:

{% set minion_ips = salt.saltutil.runner('mine.get',
    tgt='G@consul_node_role:server and G@env:' ~ env,
    fun='internal_ip_addrs',
    tgt_type='compound') %}

но инфа в грейнах на мастере может быть устаревшая, и для гарантии перед этим я дергаю раннер с mine.update:

{% set mine_updated = salt.saltutil.runner('mine.update',
    tgt='G@consul_node_role:server and G@env:' ~ env,
    mine_functions='internal_ip_addrs',
    tgt_type='compound') %}

Это ок, или есть какой-то более правильный метод?
и что произойдет, если запустить стейт через salt-call на самом миньоне? корректно логика обновления майна на мастере отработает?

mine асихронный и mine.update тоже.
То есть просто вызвав его ты не гарантируешь что в момент работы логики шахта будет уже актуальная. Это гонка.

Так что надо акуратней.

Альтернативы использовать какой-нибудь KV Storage и slots

Посмотрю, спасибо

что-то странное, кмк
salt-run salt.execute '*' grains.get arg=ipv4

выдает такой выхлоп:

consul-0.salt-test1:
    p
consul-1.salt-test1:
    p
consul-2.salt-test1:
    p
salt-master-ams:
    p

в arg можно передать что угодно, возвращается всегда вторая буква этого чего угодно.

Но если дернуть salt-run salt.execute '*' grains.ls, то ответ нормальный, список грейнов.

я опять чего-то не понимаю? 🙂

{% set minion_ips = salt.saltutil.runner('mine.get',
    tgt='G@consul_node_role:server and G@env:' ~ env,
    fun='internal_ip_addrs',
    tgt_type='compound') %}

{% set mine_updated = salt.saltutil.runner('mine.update',
    tgt='G@consul_node_role:server and G@env:' ~ env,
    mine_functions='internal_ip_addrs',
    tgt_type='compound') %}

да, решить пытаюсь эту же задачу.