Зачем так категорично? У разных компаний и команд свои представления о том, как менеджить пользователей. Кто-то вполне живет с тем, что все пользователи для доступа к инфре создаются в гитлабе, т.е. каталогом по сути является сам гитлаб. Приносить в такую инфру отдельно стоящий каталог ради десятка пользователей в одной группе — зачем?
Есть ещё вариант, но древний, поэтому думаю, что вряд ли станете связываться.
Была аналогичная задача общаться из браузера по ком порту, но вместо описания протокола был код на Дельфи. Самым простым оказалось сделать обёртку в виде ActiveX и через него получать данные от устройства в js.
kind ещё хорош, когда надо потестить что-то в разных версиях куба.
И вдруг кому-то пригодится, есть скрипт для запуска kind с локальным регистри и ингрессом. Там ничего необычного, всё взято из документации, просто объединено в скрипт, работающий на ubuntu и mac.
Справедливости ради, jq работает медленно из-за бага в версии 1.6. Версия 1.5 или самосбор из мастера работают быстро. https://github.com/stedolan/jq/issues/2069 Ждать ли jq 1.7 или собирать самому или без хлопот взять старый jq или новый jshon — это уже другой вопрос.
Тоже странно такое слышать, но видимо это никак не изменить, естественный процесс развития языка. Вот была потребность обозначать разновидности кинескопных телевизоров, были «ламповые» на лампах и обычные на транзисторах/микросхемах, а потом ещё «плоские» в языке появились. А теперь есть потребность отличать «ламповые» с кинескопом от всех остальных «не ламповых». Произносить слово «ламповый» куда проще чем аббревиатуру ЭЛТ, вот и прижилось. Коллекционерам и ретро энтузиастам конечно жить проще от этого не стало, думаешь вот поищу сейчас «ламповый телевизор» и найду какой-нибудь интересный УЛТ или УНТ, а тебе в объявлениях всякий шлак микросхемный с телетекстом выпадает =)
Идеальный пайплайн обязан как минимум: очень быстро работать, прям чтоб сделал git push и тут же всплыла уведомляшка «пайплайн выполнен», всегда запускать только нужные команды, показывать понятные сообщения об ошибках. И раз уж разговор про идеальность, то должна быть возможность локально отладить CI: позапускать джобы и подёргать триггеры без бесконечных пушей конфига.
Для себя энтропию или «меру неупорядоченности системы» объясняю как «количество бардака вокруг». Есть такой шуточный взгляд, что любая полезная деятельность человека это по сути попытки уменьшить энтропию вокруг. Стереть пыль, помыть посуду, вынести мусор — уменьшение энтропии. Скачивать файлы в папку Downloads, кидать одежду где попало, коробочка с шурупами и винтиками вперемешку — увеличение энтропии.
Точно такие же объяснения и в физике — растёт температура, атомы двигаются быстрее, энтропия повышается. Температура уменьшается, атомы «застывают», энтропия понижается, вплоть до нулевой энтропии: остановки атомов при 0 Кельвинов.
Возможности проверок через Jsonschema в Polaris и правда урезаны. Даже не столько набором валидаторов jsonschema, а тем что проверять можно Pod или Container.
target: Container # target can be "Container" or "Pod"
Похоже, что в недостатки Polaris можно добавить «Не умеет работать с CRD».
Спасибо за развёрнутый ответ! У меня опыт с Prometheus и я как-то предположил, что тамошние операции с указанием интервала это примерно тоже самое что и GROUP BY ($__interval) в Influx. Там есть семейство операций *_over_time и вот они как раз умеют работать с $__interval с учётом данных во всех промежуточных точках, которые есть в базе.
Чтобы не пропустить редкие случаи проблем и при этом не запрашивать много точек, помогают min_over_time/max_over_time/count_over_time, но можно пойти дальше и сократить количество запрашиваемых точек, т.к. важен только факт присутствия какого-то статуса в промежутке времени. Собственно так и появился плагин grafana-statusmap, с ним количество запрашиваемых точек выходит меньше, чем для $__interval, но при этом всё равно можно видеть редкие проблемы. Т.е. в вашем случае на доске с тестами я бы сделал отдельный график «Запуск тестов» или «Статус тестов» с этим плагином и показывал бы на нём наличие метрик по тестам или метрику успешности тестов. При этом на графиках с DERIVATIVE() может быть пусто, но в «Статус тестов» будут квадратики — значит в то время был неуспешный тест, значит можно уточнить time range, $__interval уменьшиться и на графиках что-то появится.
Если есть желание попробовать, можно в личке обсудить, я бы потом утащил в README как пример использования для influx.
Про $granularity не очень понятно. Это переменная dashboard-ы со списком, чтобы вручную выбирать интервал группировки? А чем не подходит GROUP BY ($__interval)?
Петабайт на малинке, есть такой эксперимент https://www.youtube.com/watch?v=BBnomwpF_uY
Почему же нет ООП, из коробки можно конструировать классы. Плюс есть Moose, ещё мощнее штука.
Зачем так категорично? У разных компаний и команд свои представления о том, как менеджить пользователей. Кто-то вполне живет с тем, что все пользователи для доступа к инфре создаются в гитлабе, т.е. каталогом по сути является сам гитлаб. Приносить в такую инфру отдельно стоящий каталог ради десятка пользователей в одной группе — зачем?
Это был бы тот ещё анекдот, если бы оказалось, что безопасники nvidia взломали не хакеров, а amd.
На Корвете был клон — «Докер».
Есть ещё вариант, но древний, поэтому думаю, что вряд ли станете связываться.
Была аналогичная задача общаться из браузера по ком порту, но вместо описания протокола был код на Дельфи. Самым простым оказалось сделать обёртку в виде ActiveX и через него получать данные от устройства в js.
Стекление чертежей... Студенческие времена... Так можно было на ватмане нарисовать прям во весь размер и потом с тубусом ходить в кафешки =)
kind ещё хорош, когда надо потестить что-то в разных версиях куба.
И вдруг кому-то пригодится, есть скрипт для запуска kind с локальным регистри и ингрессом. Там ничего необычного, всё взято из документации, просто объединено в скрипт, работающий на ubuntu и mac.
Справедливости ради, jq работает медленно из-за бага в версии 1.6. Версия 1.5 или самосбор из мастера работают быстро. https://github.com/stedolan/jq/issues/2069 Ждать ли jq 1.7 или собирать самому или без хлопот взять старый jq или новый jshon — это уже другой вопрос.
Тоже странно такое слышать, но видимо это никак не изменить, естественный процесс развития языка. Вот была потребность обозначать разновидности кинескопных телевизоров, были «ламповые» на лампах и обычные на транзисторах/микросхемах, а потом ещё «плоские» в языке появились. А теперь есть потребность отличать «ламповые» с кинескопом от всех остальных «не ламповых». Произносить слово «ламповый» куда проще чем аббревиатуру ЭЛТ, вот и прижилось. Коллекционерам и ретро энтузиастам конечно жить проще от этого не стало, думаешь вот поищу сейчас «ламповый телевизор» и найду какой-нибудь интересный УЛТ или УНТ, а тебе в объявлениях всякий шлак микросхемный с телетекстом выпадает =)
Идеальный пайплайн обязан как минимум: очень быстро работать, прям чтоб сделал git push и тут же всплыла уведомляшка «пайплайн выполнен», всегда запускать только нужные команды, показывать понятные сообщения об ошибках. И раз уж разговор про идеальность, то должна быть возможность локально отладить CI: позапускать джобы и подёргать триггеры без бесконечных пушей конфига.
А может и 59049. В начале статьи Эйнштейн намекает, что там троичная логика.
Gemcraft!
Для себя энтропию или «меру неупорядоченности системы» объясняю как «количество бардака вокруг». Есть такой шуточный взгляд, что любая полезная деятельность человека это по сути попытки уменьшить энтропию вокруг. Стереть пыль, помыть посуду, вынести мусор — уменьшение энтропии. Скачивать файлы в папку Downloads, кидать одежду где попало, коробочка с шурупами и винтиками вперемешку — увеличение энтропии.
Точно такие же объяснения и в физике — растёт температура, атомы двигаются быстрее, энтропия повышается. Температура уменьшается, атомы «застывают», энтропия понижается, вплоть до нулевой энтропии: остановки атомов при 0 Кельвинов.
А почему в тэгах Brainfuck?
Да. С самого начала у нас была именно такая задумка и мы её придерживаемся :)
Возможности проверок через Jsonschema в Polaris и правда урезаны. Даже не столько набором валидаторов jsonschema, а тем что проверять можно Pod или Container.
Похоже, что в недостатки Polaris можно добавить «Не умеет работать с CRD».
Спасибо за развёрнутый ответ! У меня опыт с Prometheus и я как-то предположил, что тамошние операции с указанием интервала это примерно тоже самое что и
GROUP BY ($__interval)в Influx. Там есть семейство операций *_over_time и вот они как раз умеют работать с $__interval с учётом данных во всех промежуточных точках, которые есть в базе.Чтобы не пропустить редкие случаи проблем и при этом не запрашивать много точек, помогают min_over_time/max_over_time/count_over_time, но можно пойти дальше и сократить количество запрашиваемых точек, т.к. важен только факт присутствия какого-то статуса в промежутке времени. Собственно так и появился плагин grafana-statusmap, с ним количество запрашиваемых точек выходит меньше, чем для
$__interval, но при этом всё равно можно видеть редкие проблемы. Т.е. в вашем случае на доске с тестами я бы сделал отдельный график «Запуск тестов» или «Статус тестов» с этим плагином и показывал бы на нём наличие метрик по тестам или метрику успешности тестов. При этом на графиках сDERIVATIVE()может быть пусто, но в «Статус тестов» будут квадратики — значит в то время был неуспешный тест, значит можно уточнить time range,$__intervalуменьшиться и на графиках что-то появится.Если есть желание попробовать, можно в личке обсудить, я бы потом утащил в README как пример использования для influx.
Гречка в контейнерах затарена. Нет, не в эфемерных.
Про
$granularityне очень понятно. Это переменная dashboard-ы со списком, чтобы вручную выбирать интервал группировки? А чем не подходитGROUP BY ($__interval)?