Как стать автором
Обновить

Комментарии 93

DevOps и эджайл сделали с индустрией ПО то, что происходило годами и десятилетиями в других сферах. Слава Богу профессионализм ещё в почете. И крутые специалисты найдут себе работу… Но как побочный эффект — опенсурц умер.

Боюсь, да: open-source умер в контексте «почитать-код-подумать-внести-свой-вклад-чтобы-стало-лучше». Средней руки спец возьмёт то, что есть, и будет долго ныть в issues, не читая документацию, вместо того, чтобы создать PR/MR.
можно подумать кому-то этот PR/MR нужен. Там с той стороны сидят ребята на поддуве у facebook, microsoft или какой-другой компании и у них свой план. А на MR скорее ответят, что его как-то не так оформили или ещё как-то докопаются до мелочей.

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

Здесь бы великолепно смотрелась ссылка на пример такого MR.

Да легко:
https://github.com/async-rs/async-std/pull/122
https://github.com/withoutboats/romio/pull/106


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


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


Ребята сидят на поддуве у Ferrous Systems, если что. Вчитываемся в PR, делаем выводы, голосуем/отписываемся.

Как-то звучит как обида с вашей стороны.

Когда не принимают PR это всегда обидно.
Особенно, когда у твоего PR есть «пальцы вверх».
Второй выглядит конечно странно, но у меня, как человека со стороны, нет ниодной причины подозревать в чем-то кого-то. С чего вдруг дело в пиаре? Неадекватность — это тут видно вполне.

По первому, выглядит как типичная ситуация, когда PR сделан без согласования с ментейнерами. Вместо того, чтобы копошиться в нем, править коммиты, можно закрыть его, открыть баг для обсуждения, а уже потом писать решение в новом PR. Никакого криминала. Вам обидно — это другой вопрос. Участвуйте в обсуждении, может придете к компромиссу.

Первый PR был открыт за полмесяца до смены парадигмы.

И? Это ничего не меняет.

Open Source в таком контексте никогда и не жил массово. Да и технически никогда не мог так жить.


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


Вместо того, чтобы настаивать на мастерстве ракетно-космического уровня, мы просто прикручиваем сверху ещё больше слоёв. И ни у кого нет сил сказать «нет». IT-софт ушёл слишком далеко от любого подобия инженерного дела.

Опять же, вы понимаете, что такой софт качественный в значительной мере потому, что он простой с точки зрения бизнес логики? Там безумно мало вещей, которые делают программы сложными. Никакой параметризации, ничего такого.

НЛО прилетело и опубликовало эту надпись здесь
> Средней руки спец возьмёт то, что есть, и будет долго ныть в issues,
А что делать… Правда тут есть момент в том, имеет ли место проблема или это «не чтение документации». Если второе то такое быстро закрывается, а первое часто висит годами.

> вместо того, чтобы создать PR/MR.
Чтобы сделать PR, нужно разобраться в коде, сделать фикс который ничего не сломает, вероятно написать/дописать автотесты, причём в стиле фирмы и ещё много работы. А потом ещё передать права на свою работу, часто без этого не берут PR, типа левый программер, надо поменять лицензию например — обходи потом по всем, собирай разрешения, удаляй их код если они не одобрили.
И если не провёл много сотен часов в коде этой утилиты, то часто сделать этот PR это работа даже не на неделю а может быть и больше, тогда как сотруднику — пол дня на всё. С другой стороны, я бы воздержался использовать софт, у которого нужно ориентироваться как в своём чтобы всё работало.

Ещё позиция многих людей — это опенсорц, тут никто ничего никому не обязан. И я сам с этим столкнулся, когда видел проблемы, но авторы вместо того чтобы их править, слали пачками письма «купите подписку всего за 3 килобакса в месяц и мы будем решать ваши issue». А сообщество такое «ну и что, имеют право». То есть находишь баг, репортишь, а в ответ «гони бабла». Именно такая позиция и убивает опенсорс. И вызывает желание критические ошибки не разработчикам сдавать, а продавать куда-то как 0day. Или и то и другое сразу.
Я конечно понимаю, что работы может быть и так много, а ещё семья-друзья ждут, а ещё — что гораздо приятнее пилить новые фишки чем ловить баги и править старый код, но это противоречие убийственно для опенсорса.
Хотя тема вообще-то про devops.

На самом деле опенсурс и девопс идут рука об руку.
Потому что бизнес требует результат вчера, денег на покупку коробочного решения не дает (попробуй обоснуй! к тому же, у "коробок" своих болячек полно), приходится выкручиваться как можешь.

А мне бы был полезен другой опрос, про вовлеченность и как ее починить, коллега (:)
Лично я вполне согласен с рецептами починки от Майкла — собственно, поэтому и сделал перевод, ибо зацепило.
А какие это рецепты?
Так вот же:
Касательно той штуки насчёт депрессии/выгорания — берегите своё мастерство. Наслаждайтесь производительностью. Создавайте пуленепробиваемые вещи. Делитесь написанными скриптами. Ведите блоги. Что угодно. Общайтесь и делитесь ещё больше.
Как я понял, автор не знает что делать с повсеместным падением уровня вовлеченности в open source проектах
взаимодействие и опыт работы с людьми — большой позитив. Но они, кажется, тормозятся везде.
Симптомом которого было внедрение Agile практик и DevOps. И он не знает, что с этим делать.
Я хочу помочь с этим бороться, но, в конце концов, вовлечённость и мозговые штурмы — моё топливо. Если вовлечённости нет, и я не могу эту вовлечённость починить — я ничего с этого не получу.
Всё же, на мой взгляд, внедрение agile и DevOps — пара причин, которые привели к текущей ситуации.
Говоря прямо, инструменты, требующие определённого уровня квалификации, пошли в широкие массы. Результат печален: если условный спец умеет/успевает только использовать инструмент, но никак не разбираться в нём детально, то, конечно, никакой вовлечённости этот инструмент в нём не разожжёт, и никаких MR/PR никто от этого спеца не увидит. В лучшем случае — те самые унылые issues, потому что «доку не читай @ в чаты пиши».

Поэтому инструменты должны иметь некий заградительный уровень, порог входа. Тогда идиоты будут отсеиваться на входе. С другой стороны, именно поэтому появятся альтернативные инструменты, которые будут с виду простыми, буду обещать легкое решение проблем, но потом для более сложных задач и конфигураций они не будут подходить и тот, кто их взял, начнет изобретать костыли и велосипеды для решения своей задачи.

Вот прям повеяло простыми нажатиями кнопки «сделать хорошо» :-)
К сожалению, одинаково универсальных инструментов нет, и те, кто это не понимает, всегда будут огорчены тем, что «X не умеет Y, а Z — умеет, но при этом стоит денег». Остаётся только пожимать плечами и вчитываться в исходники очередного инструмента :-)
Действительно, где тут рецепты? Что в переводе, что в оригинале — мало связный поток сознания непонятно о чем.
Я думаю проблема ещё заключается в том, что спецы, работающие в компаниях, берут исходники из открытого проекта, дорабатывают его под себя или исправляют ошибки, но обратно в открытый доступ этот код уже не попадает
НЛО прилетело и опубликовало эту надпись здесь
если используется только внутри компании где было сделано то вообще-то не нарушает, распространять закрытый код без выкладки кода при этом запрещено.
Выложить по ошибкам PR проще, чтобы меньше патчить код на новых версиях, но зачастую реализовано то что большинству не нужно, оформлено не как нужно, код надо рефакторить, иногда ломает например работу на arm итд.
Есть разные ситуации. В некоторых проектах PR висят сотнями, на которые разработчи не обращают внимания. Где-то автор давно забил на поддержку. Где-то с другой стороны сидят люди за зарплату, у которых есть свой взгляд на вещи и более приоритетные таски.

Ревью это на самом деле затратно. Нередко в PR предлагают кастыли, решающие чьи-то сиюминутные проблемы. Без тестов, без документации. Превращать интервью в менторинг или найти время, чтобы переписать самому? Снизить издержки можно. Для этого надо знакомить потенциальных контрибьютеров с принятыми правилами, архитектурой, вкладываться в документацию. На это опять же нужно время и набор самостоятельных скиллов.

Автор ансибла недоволен софтом с багами? Удивительно.

Вот прям с языка снял. Настолько слабодокументированной и баг-на-баге-багом-погоняет системы — еще поискать! Настолько, что под свои задачи хочется сесть и написать свой ансибл…
А кто же мешает? Напишите! Возможно, ваши задачи окажутся близки кому-то ещё, и мы станем свидетелями рождения нового замечательного инструмента управления конфигурацией — проявится то самое взаимодействие, о котором пишет Майкл.
НЛО прилетело и опубликовало эту надпись здесь
В 2.9, как минимум, сломано то, что завязано на вывод фактов из переменных, получаемых через register. Вот только на днях пришлось править драйвера для молекулы, т.к. в 2.9 вместо ключа ansible_facts (который использовался в предыдущих версиях), стали использовать ansible_info. И весь код, который завязан на привычную структуру фактов, перестал работать.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь

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

НЛО прилетело и опубликовало эту надпись здесь
Старое название чего? Имя ключа поменялось. Если вы будете парсить вывод модуля и обратитесь к привычной структуре словаря прежних версий, то вас ожидает фейл. Т.к. ансибл просто вам сообщит, что такого ключа в словаре нет, и будет прав.
НЛО прилетело и опубликовало эту надпись здесь
При чем тут название модуля? Я говорил о том, что в выводе модуля поменялось название одного из ключей. И даже ссылку на код привел. Вы понимаете разницу между названием модуля и тем, что он выдает в вывод?
НЛО прилетело и опубликовало эту надпись здесь

Да нивапрос.


- name: Get list of Load balancers
  azure_rm_loadbalancer_facts:
    resource_group: "{{ az_resource_group_name }}"
    tags: "{{ vmss_tags[item.name]  }}"
  loop: "{{ molecule_yml.platforms }}"
  register: lb_sets

- name: Destroy Load balancer resources
  azure_rm_loadbalancer:
    resource_group: "{{ az_resource_group_name }}"
    location: "{{ az_location }}"
    name: "{{ item.ansible_facts.azure_loadbalancers[0].name }}"
    state: absent
  register: lbs
  loop: "{{ lb_sets.results }}"
  loop_control:
    label: "{{ item.item.name }}"
  when: item.ansible_facts.azure_loadbalancers | length > 0

Вот это отлично отрабатывает на Ansible 2.8. А на 2.9 ломается. Предвосхищая вопрос: да, мы уже переписали код, чуть усложнив выборку, и теперь он работает и на 2.9 тоже. Но факт, что просто от смены версии рабочий код плейбуки сломался для этих модулей и пришлось его переписывать.

НЛО прилетело и опубликовало эту надпись здесь

Ну, это уже вопрос семантики — можно или нельзя называть "сломался". Мы все читали и проапгрейдили, о чем я написал с самого начала. Переименовывать модули пока не будем, иначе на 2.8 работать перестанет. Мы обычно стараемся поддерживать совместимость кода с двумя последними версиями. Вопрос считаем закрытым?

НЛО прилетело и опубликовало эту надпись здесь
Ну вы можете любое изменение в продукте называть «сломался», ведь предыдущее состояние изменилось. Но не понимаю зачем.

Нет. Не любое изменение = "сломался".
Сломался — это когда поведение радикально изменилось. Есть же понятие обратной совместимости? Есть. Так вот — если ее не соблюдать, то "сломался".

В 2.9, как минимум, сломано то, что завязано на вывод фактов из переменных, получаемых через register. Вот только на днях пришлось править драйвера для молекулы, т.к. в 2.9 вместо ключа ansible_facts (который использовался в предыдущих версиях), стали использовать ansible_info. И весь код, который завязан на привычную структуру фактов, перестал работать.
Часто issue создают люди, которые не понимают, как работает та или иная часть/функция/модуль, да ещё и с комментариями — «хочу, чтобы работало вот так».

Любой ишью имеет ценность. Даже если он именно в ключе "хочу, чтобы работало вот так", но был реджекнут — это уже информация для будущих поколений, что так работать не будет.
Другой вопрос, что очень многие ишью дублируют другие (трекер не читай @ ишью создавай) или описаны очень… поверхностно (HELP! HELP! волки!). Или ответ на них есть в доке. И с помощью Ишью легко сделать DOS атаку на представителей разработки конкретного софта. Заведи 100 ненужных ишью — пускай разработчики их разгребают ((((((

Вся катастрофа ансибла — в том, что НИКТО не знает, как оно работает. Как написано — так и работает. Отношения между переменными, import'ами и include'ами — мистика совершеннейшая. Я недавно описывал совершеннейший WTF с import_role, который переопределяет переменные для таски, в которой import, но только вне scope остальных import'ов. Попытка разобраться с этим — это изучение карты минного поля.


А главная проблема ansible — глобальный массив переменных, который иногда притворяется локальными переменными.

В контексте статьи хочу заметить, что исходники Ансибла при этом открыты, то есть всегда есть возможность прочитать и понять, _как именно_ работает. Ну и, конечно же, обсудить с сообществом.

А если этого не хочется по каким-то причинам — всегда можно взять и написать свою систему, которая будет:
  • легковесной,
  • простой в использовании,
  • не будет содержать багов,
  • и будет абсолютно бесплатной в использовании.

P.S. Лично я проблем с глобальными переменными не встречаю вовсе — и так уже пять лет!.. По моим ощущениям, чаще источники подобных проблем кроются в непонимании объектной модели Ansible (как говорится, «не о присутствующих», сугубо по опыту чата @pro_ansible).

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


У нас на работе множество людей, которые ни разу не сталкивались с неконсистеностью модели Асибла. Например, все бухгалтеры ни разу не сталкивались с проблемами при написании плейбук ансибла. Повар тоже не сталкивался. А вот операторы и программисты сталкиваются постоянно.


Если вы так уверены в консистености ансибла, то объясните вот это:
https://habr.com/en/company/southbridge/blog/471896/#comment_20769540

Что-то я не вижу, чтобы где-то озвучивал подобную уверенность:
Если вы так уверены в консистености ансибла
Во-вторых, если посмотреть на плейбук по ссылке, то вы изменяете глобальные переменные внутри отдельных вызовов ролей и удивляетесь результату. С чем именно консистентен подход с изменением глобальных переменных в отдельных вызовах?

Мой вопрос о том, что если import_role меняет переменные на этапе загрузки (как обычно это делает import), то почему последующий импорт не затирает значения предыдущего import'а? Т.е. почему каждая роль получает "своё" значение перменной, но таска, которая "не при делах" получает значение последней роли? Где тут консистентность?


Я вам даже задам другой вопрос. Как вы думаете, что будет, если я эту "глобальную переменную" задам в блоке vars для play? Попробуйте ответить, опираясь на знание в голове, а не на эксперимент.

Да не хочу я делать странное, про которое в доке написано «не надо так». Вот есть ссылка, по ней вторым абзацем лежит фраза:
Avoid defining the variable “x” in 47 places and then ask the question “which x gets used”. Why? Because that’s not Ansible’s Zen philosophy of doing things.
В переводе означает «Избегайте определения переменной в 47 местах, чтобы потом не спрашивать, какое значение используется».
Именно так я и делаю.

Как интересно. И каким образом этот дзен консистентен с идеей переиспользуемых ролей?


Допустим, вам надо на сервере x настроить 20 почти одинаковых копий приложения, отличающихся конфигурационным файлом и параметром в template'е systemd.


Есть роль, которая может настроить приложение.


Ваши действия? Желательно, с учётом reusable roles.

А здесь уже вижу запрос на конструктив — респект.

Подобные случаи выглядят достаточно просто: роль, у неё есть набор параметров. Для того, чтобы роль не падала при запуске без параметров, параметры устанавливаются в некие безопасные умолчания через defaults/main.yml.

А сам управляющий плейбук может выглядеть вот так:
---
- hosts: <hostgroup1>
  roles:
    - role: role1
      param1: value1
- hosts: <hostgroup2>
  roles:
    - role: role1
      param1: value2


Вполне себе reusable.

А в пределах одной play? Я понимаю, что на тривиальных примерах "распилите на два" работает хорошо, но в середине сложного кода "распил" на play может быть неконструктивным. Хорошим примером может быть ситуация, когда долго собираются set_facts до запуска роли.

Занятно, что в вашем вопросе содержится ответ :-) Сбор фактов часто является самой долго исполняющейся частью плейбука, соответственно, его принято отключать.
Вариант отключения сбора фактов
У меня обычно в плейбуках встречается что-то похожее:
---
- hosts: <hostgroup1>:<hostgroup2>
  gather_facts: yes
  tasks: []
- hosts: <hostgroup1>
  gather_facts: no
  roles:
    - role: role1
      param1: value1
- hosts: <hostgroup2>
  gather_facts: no
  roles:
    - role: role1
      param1: value2


Ну или если хочется красоты:
Красота
---
- hosts: <hostgroup1>:<hostgroup2>
  gather_facts: yes
  tasks: []
- hosts: <hostgroup1>
  gather_facts: no
  roles:
    - role: role1
      param1: "{{ bar  }}"
- hosts: <hostgroup2>
  gather_facts: no
  roles:
    - role: role1
      param1: "{{ bar  }}"

А переменная bar, соответственно, определена для каждой группы.

Если прямо совсем нет возможности делать несколько play (плеев? драм?), то вот ссылочка на официальную документацию. Можно заставить роль исполняться несколько раз.

Т.е. вы предлагаете import_role не использовать. Вполне вариант. Ещё можно не использовать любой произвольный набор модулей, в которых пост-фактум нашлись баги.


Я не понимаю, почему


   - debug: var=foo
     vars:
       foo: 1

имеет scope (в пределах task), а


   - import_role: name=foobar
     vars:
       foo: 1

имеет scope… глобальный, кроме ролей, которым передан vars, который влияет на глобальный scope и в пределах роли.


Вот моё понимание консистентности не укладывается в эту реальность.


Хотите ещё смешного?


- hosts: localhost
  tasks:
   - debug: var=[a,b]
  vars:
    a: '{% if True %}{"x": 1}{% endif %}'
    b: '{% if True %} {"x":1}{% endif %}'

Расскажите мне, почему a — это словарь, а b — строка. (Я-то знаю, вы мне с точки зрения разумного дизайна объясните).

Про первое. Я не использую import_role просто потому, что не получу каких-то реальных преимуществ от его использования. А про особенности — см. доку, плюс здесь.
Исходя из двух указанных мест, лично мне понятно, что я получу определённые проблемы вместе с import_role, не получив абсолютно ничего конструктивного взамен. Тащить в проект что-то новое только потому, что могу — не-а, не моё. Продакшн ведь.

Про второе. Достаточно спеку YaML'а почитать. По спеке символ пробела разделяет токены YaML. Во втором случае нет пробела — значит, фигурная скобка является просто первым символом в строке, и не образует токен.

Предлагаю на этом прекратить коллективное чтение документации вслух, т.к. я не уверен, что обсуждение содержит что-то конструктивное/интересное для других читающих. Частные, узкоспециализированные вопросы можете задать в ЛС, на почту, либо в телегу (на выступлениях я указываю контакты в презентациях).

То есть ваша позиция — "в нём баг, его не надо использовать, а в остальном всё хорошо". Эта позиция применима при любом количестве багов в любом наборе модулей.


Я import_role использую для интеграции одних ролей в другие. Если роль ставит приложение, вешает алиас IP и конфигурирует nginx для приложения, то если мы делаем таски в include_tasks (потому что у нас список приложений), то без import_role никак. Точнее, я решил проблему с помощью include_role, но это обход индивидуального WTF.


Насчёт второго — вы не вчитались в пример. И a и b в кавычках, т.е. с точки зрения yaml это одно и то же, а смешное наступает на этапе парсинга вывода jinja.

НЛО прилетело и опубликовало эту надпись здесь

Моя задача — сопровождать проекты.


С ходу:
Проект 1 (целиком мой):


find . |grep -v .git |wc -l
896
find . -type f |grep -v .git |xargs wc -l
16412

Проект 2 (коллективный):
files: 10225
lines: 738985


Проект 3 (общий):
files: 7821
lines: 1329654


Я все эти проблемы находил не "из принципа", а в процессе отладки. Фигня с import_role, например, случилась при переходе с 2.7 на 2.8 (или 2.6 на 2.7? Не помню.), причём была настолько подлой, что проблему поймали уже operations team в продакшене — все тесты проходили на "ура", просто была "небольшая путаница в ip".


Когда вы говорите "воротить import_role там, где не нужно", у меня к вам вопрос: а где нужно? Вот, вы, например, где используете?

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


все тесты проходили на "ура", просто была "небольшая путаница в ip".

Во-первых, нужен канареечный релиз, чтобы такое отлаживать. Да, отладка на продакшене. А что делать!?
Во-вторых, это может приводить к факапам, как, например, у яндекса, с мисконфигурацией сетевых устройств. ЛЕГКО.

Я рад бы делать канареечный релиз в продакшене, но продакшен держит bgp-сессии с роутерами tier1 провайдеров, и сделать a/b-тестирование на tier1 не получается в силу нехватки оных.


На самом деле даже a/b ничего не нашло бы, потому что просто перепутались сесии — у всех там full view, так что проблему заметили много позже.

Вот оно — вот она причина, почему BGP кладется вместе с половиной энторнетов… Это просто админы (недо)освоили ансибл…


/я без конкретики, а просто нытье в общем/

А он кладётся? Обычно страдают только пользователи одного аплинка, либо AS, которым неповезло и чьи префиксы зааносил очередной пакистанский ютубодав.


Для того, чтобы это сделать, не нужен ансибл, достаточно чуть-чуть кривых рук.

НЛО прилетело и опубликовало эту надпись здесь

include_role обладает своими чудными свойствами. Вот, например (следите за руками):


roles/role1/tasks/main.yaml:


- set_fact:
   foo: role
- debug: var=foo

play.yaml


- hosts: localhost
  tasks:
    - include_role: name=role1
      vars:
       - foo: vars
    - debug: var=foo

Как вы думаете, что будет выведено на экран? Вот я сейчас пример делал, и мне самому страшно стало.

НЛО прилетело и опубликовало эту надпись здесь

А как же reusable role? Роль делает set_fact, а увидеть не может. У меня, например, очень часто есть такой паттерн:


- uri:
    url ...
  register: foo_res

- set_fact:
     foobar: foo_res.json.some.field.inside

И вот это поломано, например, если роль в одном месте была вызвана напрямую, а в другом была include_role.


Выше оратор сказал, что не использует import_role. Теперь, мне, расскажут, что использовать include_role тоже неправильно?


PS Пример я писал заново и сам восхитился эффектом. Я такого не ожидал, я думал, будет просто overshadow внутри роли. Что при этом set_fact за пределы роли уедет (а самой роли не достанется) — это для меня новое.


Каждый день новость и всё болит (с) анекдот.

НЛО прилетело и опубликовало эту надпись здесь

Стоп. Если бы оно просто "перезаписало" (как вы предлагаете с -e) — уменя бы не было вопросов. Перезаписало и перезаписало.


Но почему, перезаписав, оно использует другое значение? Если я перезаписал значение foo в role, почему в выводе vars? Если я перезаписал значение в vars, то почему в выводе role?

НЛО прилетело и опубликовало эту надпись здесь

Странно? Да, есть, много.


Это и есть моя главная претензия к ансиблу. Чем больше его используешь, тем страннее.


Вот, например, сегодняшнее открытие:


ansible_interfaces содержит интерфейсы в нормальном виде (например, br-42), а параметры интерфейса можно посмотреть в ansible_br_42. Просто вздохнуть, дописать в список бесконечного wtf'а, который находишь каждый день, и продолжать.

Сделай свой форк — будь мужчиной )))))

Форк делать бесполезно. Ансибл можно брать как inspiration, но не более.


Что ансибл сделал: нашёл правильную модель, нафигачил миллион модулей, решил проблему бутстрапа.
Что ансибл сделал неправильно: катастрофическая модель переменных, wtf-конвертация типов jinja2-питон

НЛО прилетело и опубликовало эту надпись здесь

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

НЛО прилетело и опубликовало эту надпись здесь

И я единственный, кто жалуется на нелогичность ансибла? Может, проблема всё-таки в системе типизации jinja-python и странной системе переменнных?

НЛО прилетело и опубликовало эту надпись здесь

Я думаю, что это честно, что нет local scope variables в ансибле. Вспомните сколько гемора в языках типа С/C++ с этими областями видимости. Нужно реально помнить в каждый конкретный момент времени с какой из одноименных переменных Вы работаете.
Конечно, это работает только в случае, если Вы сами изобретаете эмулируете область видимости путем жесткого применения некоей конвенции о наименовании переменных.


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

Не нужно делать import_role. Делайте либо include_role, либо просто нормальный традиционный вызов ролей в плее через roles.
У JBoss'a всегда была модель бизнеса: в open source максимум бета, остальное — за деньги. Как говорится: «Не сотвори себе кумира». Кто сказал, что OS — это бесплатно? За все бесплатное кто-то обязательно платит. Это относится в равной степени ко всем модным штучкам, т.к. их чаще всего и делают для привлечения денег. Создали Аджайл — получили целую индустрию коучеров и последователей, назвали одмина DevOps'ом, нет кодить он как не умел, так и не умеет, как плел жгуты так и плетет, но теперь за него можно взять полтийник в час, а не четвертной.
Ну допустим, я — девопс. Начинал кодить еще с ассемблера.
Но у девопса минимальная магнитуда влияния на разработчиков и методологию.
Всем заправляют ПМы.
Всем заправляют ПМы.

Даже если они есть, то они не обязательно всем заправляют. А ведь иногда их и нет вообще :)

Всем заправляют ПМы.

Это — та реальность, в которой живёте вы, но у кого-то другого ситуация может отличаться: его мнение имеет значение. И только вы можете либо соглашаться со своей ситуацией, либо как-то её менять.
Благодарю!
Исходная ссылка где-то в профильных чатах мелькнула, увидел автора — решил прочитать. Понял, что это — «ОГО!», потому что симптомы, описанные в статье, действительно ощущаются: на конференциях и митапах в лучшем случае — делимся своими удачными практиками, а в худшем — просто перенимаем чужие.
При этом есть несколько решений, которые в своих… ну не областях, наверное, а нишах сегмента администрирования стали именно что неписанным стандартом, и ничего принципиально нового не появляется пару-тройку лет точно. Ну правда, а что свежего в сегменте можно вспомнить хотя бы за последний год? Разве ту же VictoriaMetrics, но и всё, пожалуй… Ну а если я ошибаюсь — что ж, с удовольствием не только прочту названия новых продуктов в комментариях, но и попробую хотя бы их потестировать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации