Comments 93
DevOps и эджайл сделали с индустрией ПО то, что происходило годами и десятилетиями в других сферах. Слава Богу профессионализм ещё в почете. И крутые специалисты найдут себе работу… Но как побочный эффект — опенсурц умер.
И соглашусь, и нет. С одной стороны, есть многие проекты, которые с радостью примут правильный PR/MR, т.к. разработчиков всегда не хватает.
С другой стороны, опен сурс это тоже способ коммерции. И подсадить сообщество на свой продукт и потом продавать его коммерческую версию. И собирать хорошие идеи у сообщества, ничего не давая взамен. И ещё много чего.
Да легко:
https://github.com/async-rs/async-std/pull/122
https://github.com/withoutboats/romio/pull/106
Первый ультимативно закрыли из-за смены политики в отношении зависимостей, без предложения отребейзить или поправить код. После чего открыли свой ишью и втроем думают, как же решить проблему, решенную в моем PR. До сих пор не придумали.
Второй хотят закрыть с аргументом "это троллинг, это спам", потому что это мешает им пиарить свой собственный проект.
Ребята сидят на поддуве у Ferrous Systems, если что. Вчитываемся в PR, делаем выводы, голосуем/отписываемся.
Как-то звучит как обида с вашей стороны.
По первому, выглядит как типичная ситуация, когда PR сделан без согласования с ментейнерами. Вместо того, чтобы копошиться в нем, править коммиты, можно закрыть его, открыть баг для обсуждения, а уже потом писать решение в новом PR. Никакого криминала. Вам обидно — это другой вопрос. Участвуйте в обсуждении, может придете к компромиссу.
Open Source в таком контексте никогда и не жил массово. Да и технически никогда не мог так жить.
Очень мало, даже опытных специалистов, может взять и написать к условному проекту код, который бы придерижвался стиля разработки в проекте (в том числе и не описанного), а еще что бы решение совпадало с тем, как его видит автор проекта .
Вместо того, чтобы настаивать на мастерстве ракетно-космического уровня, мы просто прикручиваем сверху ещё больше слоёв. И ни у кого нет сил сказать «нет». IT-софт ушёл слишком далеко от любого подобия инженерного дела.
Опять же, вы понимаете, что такой софт качественный в значительной мере потому, что он простой с точки зрения бизнес логики? Там безумно мало вещей, которые делают программы сложными. Никакой параметризации, ничего такого.
А что делать… Правда тут есть момент в том, имеет ли место проблема или это «не чтение документации». Если второе то такое быстро закрывается, а первое часто висит годами.
> вместо того, чтобы создать PR/MR.
Чтобы сделать PR, нужно разобраться в коде, сделать фикс который ничего не сломает, вероятно написать/дописать автотесты, причём в стиле фирмы и ещё много работы. А потом ещё передать права на свою работу, часто без этого не берут PR, типа левый программер, надо поменять лицензию например — обходи потом по всем, собирай разрешения, удаляй их код если они не одобрили.
И если не провёл много сотен часов в коде этой утилиты, то часто сделать этот PR это работа даже не на неделю а может быть и больше, тогда как сотруднику — пол дня на всё. С другой стороны, я бы воздержался использовать софт, у которого нужно ориентироваться как в своём чтобы всё работало.
Ещё позиция многих людей — это опенсорц, тут никто ничего никому не обязан. И я сам с этим столкнулся, когда видел проблемы, но авторы вместо того чтобы их править, слали пачками письма «купите подписку всего за 3 килобакса в месяц и мы будем решать ваши issue». А сообщество такое «ну и что, имеют право». То есть находишь баг, репортишь, а в ответ «гони бабла». Именно такая позиция и убивает опенсорс. И вызывает желание критические ошибки не разработчикам сдавать, а продавать куда-то как 0day. Или и то и другое сразу.
Я конечно понимаю, что работы может быть и так много, а ещё семья-друзья ждут, а ещё — что гораздо приятнее пилить новые фишки чем ловить баги и править старый код, но это противоречие убийственно для опенсорса.
Хотя тема вообще-то про devops.
«Пишу исходники, и свободно в них ориентируюсь» :)
Касательно той штуки насчёт депрессии/выгорания — берегите своё мастерство. Наслаждайтесь производительностью. Создавайте пуленепробиваемые вещи. Делитесь написанными скриптами. Ведите блоги. Что угодно. Общайтесь и делитесь ещё больше.
взаимодействие и опыт работы с людьми — большой позитив. Но они, кажется, тормозятся везде.Симптомом которого было внедрение Agile практик и DevOps. И он не знает, что с этим делать.
Я хочу помочь с этим бороться, но, в конце концов, вовлечённость и мозговые штурмы — моё топливо. Если вовлечённости нет, и я не могу эту вовлечённость починить — я ничего с этого не получу.
Говоря прямо, инструменты, требующие определённого уровня квалификации, пошли в широкие массы. Результат печален: если условный спец умеет/успевает только использовать инструмент, но никак не разбираться в нём детально, то, конечно, никакой вовлечённости этот инструмент в нём не разожжёт, и никаких MR/PR никто от этого спеца не увидит. В лучшем случае — те самые унылые issues, потому что «доку не читай @ в чаты пиши».
Поэтому инструменты должны иметь некий заградительный уровень, порог входа. Тогда идиоты будут отсеиваться на входе. С другой стороны, именно поэтому появятся альтернативные инструменты, которые будут с виду простыми, буду обещать легкое решение проблем, но потом для более сложных задач и конфигураций они не будут подходить и тот, кто их взял, начнет изобретать костыли и велосипеды для решения своей задачи.
К сожалению, одинаково универсальных инструментов нет, и те, кто это не понимает, всегда будут огорчены тем, что «X не умеет Y, а Z — умеет, но при этом стоит денег». Остаётся только пожимать плечами и вчитываться в исходники очередного инструмента :-)
Выложить по ошибкам PR проще, чтобы меньше патчить код на новых версиях, но зачастую реализовано то что большинству не нужно, оформлено не как нужно, код надо рефакторить, иногда ломает например работу на arm итд.
Ревью это на самом деле затратно. Нередко в PR предлагают кастыли, решающие чьи-то сиюминутные проблемы. Без тестов, без документации. Превращать интервью в менторинг или найти время, чтобы переписать самому? Снизить издержки можно. Для этого надо знакомить потенциальных контрибьютеров с принятыми правилами, архитектурой, вкладываться в документацию. На это опять же нужно время и набор самостоятельных скиллов.
Автор ансибла недоволен софтом с багами? Удивительно.
Я не говорил, что сломано все. Но вот этот модуль оказался сломан по отношению к старому коду, т.к. изменились названия ключей вывода модуля.
Да нивапрос.
- 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 работать перестанет. Мы обычно стараемся поддерживать совместимость кода с двумя последними версиями. Вопрос считаем закрытым?
Ну вы можете любое изменение в продукте называть «сломался», ведь предыдущее состояние изменилось. Но не понимаю зачем.
Нет. Не любое изменение = "сломался".
Сломался — это когда поведение радикально изменилось. Есть же понятие обратной совместимости? Есть. Так вот — если ее не соблюдать, то "сломался".
Любой ишью имеет ценность. Даже если он именно в ключе "хочу, чтобы работало вот так", но был реджекнут — это уже информация для будущих поколений, что так работать не будет.
Другой вопрос, что очень многие ишью дублируют другие (трекер не читай @ ишью создавай) или описаны очень… поверхностно (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, не получив абсолютно ничего конструктивного взамен. Тащить в проект что-то новое только потому, что могу — не-а, не моё. Продакшн ведь.
Про второе. Достаточно спеку 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, так что проблему заметили много позже.
include_role обладает своими чудными свойствами. Вот, например (следите за руками):
roles/role1/tasks/main.yaml:
- set_fact:
foo: role
- debug: var=fooplay.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'а, который находишь каждый день, и продолжать.
Сделай свой форк — будь мужчиной )))))
Я часто это слышу от товарищей, которые любят покидаться тряпками не вникая в задачу. Когда формулируешь задачу — обычно замолкают.
И я единственный, кто жалуется на нелогичность ансибла? Может, проблема всё-таки в системе типизации jinja-python и странной системе переменнных?
Я думаю, что это честно, что нет local scope variables в ансибле. Вспомните сколько гемора в языках типа С/C++ с этими областями видимости. Нужно реально помнить в каждый конкретный момент времени с какой из одноименных переменных Вы работаете.
Конечно, это работает только в случае, если Вы сами изобретаете эмулируете область видимости путем жесткого применения некоей конвенции о наименовании переменных.
P.S. именно поэтому в классических языках и не рекомендуют делать глобальные переменные, суть — глобальное состояние, т.к. код превращается в лапшу.
Но у девопса минимальная магнитуда влияния на разработчиков и методологию.
Всем заправляют ПМы.
Всем заправляют ПМы.
Даже если они есть, то они не обязательно всем заправляют. А ведь иногда их и нет вообще :)
Всем заправляют ПМы.
Это — та реальность, в которой живёте вы, но у кого-то другого ситуация может отличаться: его мнение имеет значение. И только вы можете либо соглашаться со своей ситуацией, либо как-то её менять.
спасибо, отличная статья, хороший перевод
Исходная ссылка где-то в профильных чатах мелькнула, увидел автора — решил прочитать. Понял, что это — «ОГО!», потому что симптомы, описанные в статье, действительно ощущаются: на конференциях и митапах в лучшем случае — делимся своими удачными практиками, а в худшем — просто перенимаем чужие.
При этом есть несколько решений, которые в своих… ну не областях, наверное, а нишах сегмента администрирования стали именно что неписанным стандартом, и ничего принципиально нового не появляется пару-тройку лет точно. Ну правда, а что свежего в сегменте можно вспомнить хотя бы за последний год? Разве ту же VictoriaMetrics, но и всё, пожалуй… Ну а если я ошибаюсь — что ж, с удовольствием не только прочту названия новых продуктов в комментариях, но и попробую хотя бы их потестировать.
DevOps — всё