Телеграмм чат группы saltstack страница 939

Roman

потому что pkg.add_repo_key это execution модуль, а не state модуль

Щас погуглил и вспомнил. Спасибо

11:44пожаловаться #1

Maksim Terentev in Saltstack

Всем хай!
Как вы в pillar stack удаляете элемент словаря?
Есть сложно-составной пиллар - несколько ext_pillar: mysql, gitstack1, gitstack2, git

# gitstack1
# data1.yml
data:
  dict:
    key11: val11
    key12: val12
    key13: val13


Хочу избавиться от key12 и в итоге получить

data:
  dict:
    key11: val11
    key13: val13


Пробовал так

# gitstack2
# data2.yml
data:
  dict:
    __: remove
    key12:

Получаю этот же словарь но со значением null
data:
  dict:
    key11: val11
    key12: null
    key13: val13

Как удалить элемент?

18:02пожаловаться #2

Pillar stack спасёт. А с обычным пилларом не знаю. Мб никак

18:10пожаловаться #3

Maksim Terentev in Saltstack

Vladimir Skubriev

Pillar stack спасёт. А с обычным пилларом не знаю. Мб никак

пока не спасает, он меняет значение элемента на null
а мне надо чтоб элемент исчез

18:22пожаловаться #4

Maksim Terentev

пока не спасает, он меняет значение элемента на null
а мне надо чтоб элемент исчез

Он очень умный. Там можно скриптонуть взять то что есть, вырезать, записать.

18:23пожаловаться #5

Я попробовал обычный пиллар и понял что для совсем простых вещёй. Со стэком конечно совсем не просто в начале. Но если всё понять становится очевидным что он должен быть по дефолту. ИМХО

18:25пожаловаться #6

Maksim Terentev

# gitstack1
# data1.yml
data:
  dict:
    key11: val11
    key12: val12
    key13: val13


Хочу избавиться от key12 и в итоге получить

data:
  dict:
    key11: val11
    key13: val13


Пробовал так

# gitstack2
# data2.yml
data:
  dict:
    __: remove
    key12:

Получаю этот же словарь но со значением null
data:
  dict:
    key11: val11
    key12: null
    key13: val13

Как удалить элемент?

не пробовал но в примере из офф доки должен полностью ключ удалять да...

19:20пожаловаться #7

но кстати ЛИЧНОЕ МНЕНИЕ - если такое приходится делать то ииерархия выстроенна не правильно

19:21пожаловаться #8

мы идем от общего к частному и только добавлем по пути

19:22пожаловаться #9

Maksim Terentev in Saltstack

Kirill Proskurin

мы идем от общего к частному и только добавлем по пути

Согласен, у нас также. А в данном случае речь о тестовой ветке, в которой набор данных может сильно отличаться

19:36пожаловаться #10

    default: ==> arm-image: [INFO    ] Running state [/boot/ssh] at time 21:23:48.376837
    default: ==> arm-image: [INFO    ] Executing state file.managed for [/boot/ssh]
    default: ==> arm-image: [ERROR   ] File changed:
    default: ==> arm-image: New file
    default: ==> arm-image: [INFO    ] Completed state [/boot/ssh] at time 21:23:48.455883 (duration_in_ms=79.045)

23:29пожаловаться #11

какое-то дерьмо, почему оно ошибку кидает?

23:30пожаловаться #12

стейт был такой

/boot/ssh:
  file.managed:
    - name: /boot/ssh
    - contents: ""

23:30пожаловаться #13

может дело в
If source is left blank or None (use ~ in YAML), the file will be created as an empty file and the content will not be managed.
?

23:31пожаловаться #14

2020 July 24

contents != source

00:36пожаловаться #15

ну наличие contents автоматом отменяет необходимость прописывать source

01:59пожаловаться #16

по крайней мере в моем мире

01:59пожаловаться #17

salt_master_conf:
  file.managed:
    - user: root
    - group: root
    - mode: '0644'
    - names:
      - /etc/salt/master.d/master.conf:
        - source: salt://saltmaster/master.conf
      - /etc/salt/minion.d/minion-99.conf:
        - source: salt://saltmaster/minion.conf

15:04пожаловаться #18

насколько бест пректис писать так, вместо того, чтобы полностью писать отдельные file.managed ?

15:05пожаловаться #19

а если нужны разные права на файлы?
оно под капотом просто разворачивается "как надо"?