Несмотря на популярность Envoy количество его мейнтейнеров очень ограничено. Они в большом дефиците. Доменируют среди них сотрудники Google, у которых свои приоритеты и OKR. Обычно, кто открывает issue, тот и закрывает их патчем. Основная задача мейнтейнера - убедиться, что патч надлежащего качества и хорошо вписывается в архитектуру. Исключения - security issues.
У структуры документации логика есть. БОльшая часть - авто-сгенерирована из коментариев к Protobuf-декларациям. Остальное - поэлементное описание расширений, поскольку практически весь функционал находится в расширениях, включая даже HTTP connection manager, который по сути тоже опциональный фильтр. Кстати, рекомендую делать свою сборку Envoy, убрав все ненужные расширения. Будет немножко быстрее и меньше footprint.
В порядке саморекламы: два года назад я был официальным мейнтейнером Envoy.
Я в каждом опроснике пишу, что openspace floor plan плохо сказывается не только на моей вовлечённости, но и на продуктивности.
Пока не помогало. Видимо большинству он как раз нравится.
Но вообще бизнес по продаже опросников процветает, HR-бюджеты осваиваются, люди работают, пилят экслюзивные опросники, пишут статьи со ссылками на, типа, авторитеты. Интересно, что бы по этому поводу сказал Дэвид Грабер, автор "Bullshit job".
Необязательно анализировать систему сборки. Компайл-опции можно, например, из debuginfo взять, который в dwarf-формате. Как решался вопрос с динамическим хедером не знаю. Не исключено, что и не решался.
Но сейчас понимаю, что, может, я и наврал про зависимости только первого уровня. Возможно второй уровень тоже ребилдился. Давно дело было. Но точно помню, что экономия на времени билдов была существенная)
Видимо, проблему апдейта устройства вы решаете перефлэшиванием образа целиком. В Маемо делали инкрементальные апдейты и проводили дополнительное тестирование на сломанную бинарную совместимость как раз из-за разных дефайнов, например.
Позже один из инженеров написал скрипт, который скрейпил билдсреду на предмет опций компилятора, линкера, еще чего-то, что сейчас входит в стандарт buildinfo с reproducible-builds.org и сохранял вместе с бинарниками. Это упростило обнаружение коллизий и сократило количество билдов.
Когда-то, давным давно я работал в Нокии в проекте Maemo. Тогда ещё не было Jenkins, и система сборки была своя. Количество репозиториев было значительно больше 500 и дело не ограничивалось Git'ом. Например, репозиторий браузера был на экзотическом Mercurial, и разработчики наотрез отказывались от переезда на Git, потому что их workflow был завязан на апстримовый репозиторий, который у Mozilla был тоже на Mercurial. Ну, и других VCS было в товарных количествах - Subversion, CVS, Darcs и даже deb-src.
В общем, чтобы всё было максимально гибко нельзя было полагаться на триггер билда по PR. Некоторые пакеты релизились вместе, и вместе должны были билдиться. Такое было редко, но случалось. Если их билдить по отдельности, то ни тот, ни другой билд не проходил. Ну, например, либы меняла API, и приложение в новой версии использовало новый API. С версионированием API в embedded никто заморачиваться не хотел, особенно на этапе разработки ещё незарелизинной платформы.
Отсюда вытекала необходимость сканирования всех репозиториев по крону на предмет не PR, а tag'ов с новой версией. Workflow в командах был очень разнообразный, но чаще было так: разработчик делал PR, его ревьювили, особо продвинутые команды запускали свой локальный CI для него. Если всё было хорошо, то его мержили и ставили tag новой версии. Вот эти tag'и уже триггерили общесистемный CI.
Для построения дерева билда, а точнее топологически отсортированного списка, тоже использовалась NetworkX. Но перестраивались не все новые пакеты со всеми зависимостями, а только новые пакеты с неизменившимися зависимостями первого уровня, чтобы убедиться, что API не сломался. Перестравивать все уровни зависимостей смысла нет, только если для обогрева атмосферы (это основная претензия к системам типа OBS или Yocto). Причём новые бинарники неизменившихся зависимостей в итоговый образ не включались. Это необходимо было для того, чтобы Software Updates были поменьше, и чтобы на этапе тестирования этих updates выявить забытые version bumps из-за сломанного ABI.
Полные ребилды делались только при апдейте тулчейнов.
Хорошее было время. Система получилась ну очень гибкая. Но сейчас, если бы начал всё делать заново, то скорее всего написал бы, что-нибудь на основе ServerlessWorkflow.
Мне показалось, что как раз с Маемо ui/ux был перетащен на MeeGo, и в каком-то сильно изменëнном виде продолжает жить как Sailfish. Если хотите увидеть оригинальный MeeGo, погуглите MeeGo WeTab. Вообще концептов ui было много. И это была проблема. Даже не все увидели свет. Тот же N900 должен был быть совсем другим (или N9? не помню уже) - без явно выраженных приложений, но с add-on'ами. И принцип одного приложения для пользования всеми возможными мессенджерами (telepathy framework) - отголосок той концепции. Хотя telepathy появился ещё в N800.
А так да. Linux он везде Linux.
Помню было забавно читать русские переводы тогдашних пресс-релизов. В одном было написано, что Nokia готовится выпустить телефон с новым "iconic UI". Это было переведено как "пользовательский интерфейс на основе иконок". Уверяю вас, там не иконки имелись в виду.
На самом деле от MeeGo в этом телефоне только название маркетинга ради. Внутри это чистый Maemo. MeeGo занималась другая команда, и она пилила свой билд на основе rpm в сотрудничестве с Intel. Ниже на картинке - мой авторский экземпляр :) Пользовался им несколько лет, поэтому надпись сбоку слегка затёрлась.
Виртуалки, конечно, в подах запускаются. Абъюзим аннотации подов для их конфигурации и для управления lifecycle'ом. Зато не нужен отдельный шедулер. Конечный пользователь, разумеется, сам под не создает: есть отдельный контроллер для нашего CRD, который уже разбирается с тем, что именно надо вписать в ресурс пода и как его изменить, чтобы, например, произошел graceful shutdown. В KubeVirt, если мне память не изменяет, для этого есть отдельный CRD типа Action. К сожалению, руки не доходят, чтобы на эту тему статью писать, хотя в планах было. Показать пока тоже не могу - процесс опенсорсинга сильно бюрократизирован.
Писать свой kubelet - это, по-моему, уже перебор. Для достаточной нам функциональности вполне хватает собственного шима отвечающего вот этой спеке. В репозитории containerd есть код скелета шима, который просто надо наполнить своим "мясом". Вообще, архитектура containerd и его плагинная система заслуживает отдельного разговора. Кроме того, недавно там появился SandboxAPI, облегчающий запуск тасков внутри виртуалок. Но это решение ориентировано именно на таски. Для ваших задач (и наших) поможет не сильно.
Диски хранятся в локальном LVM ноды. Используется собственный CSI плагин, который нарезает диски из LVM в момент, когда под уже зашедулен на ноду. CSI - тоже большая тема, поскольку ориентирована на remote storage, а не на local. Наше решение довольно простецкое - OCI-хук скачивает образ и заливает его в готовое устройство на этапе createRuntime. Хотя, наверное, идеологически правильнее применить для local storage готовый populator (ссылку быстро найти не могу, искать лучше по имени Patrick Ohly - он этой темой занимался, когда PMEM был ещё big thing в Intel).
Кроме KubeVirt можно ещё посмотреть Virtink. Он легче KubeVirt: обходится без долгоживущего launcher'а, без libvirt и даже без QEMU (вместо него Stratovirt). К сожалению, не поддерживает блочные устройства: VM-ки грузятся с docker-образов, как обычные контейнеры.
Нам, правда, не подошло ни то, ни другое. Написали свой маленький runtime shim для собственного runtimeClass, который вместо runc сразу запускает либо QEMU, либо Stratovirt (напрямую без libvirt) и управляет lifecycle'ом VM-ки через QMP. Аналога virt-handler'а нет. Оказалось, что OCI-hook'ов достаточно, чтобы запровиженить блочные устройства и macvtap. CNI у нас на основе OpenvSwitch - macvtap пробрасывается на порты в нём.
TLDR: Посылка первая: когда на человека падает манна небесная в виде стольника, он часто готов поделиться четвертаком с ближним. Посылка вторая: ближний же считает, что делящийся манной поступит несправедливо, если решит поделиться с ним меньшей частью. Вывод: Всё хорошо прекрасная маркиза. мы уже живём в наиболее справедливом из миров. Где потребительные стоимости просто падают с неба на тех, кто сверху и ими же распределяются среди тех, кто снизу.
Во-вторых, интересно, что Google утверждает, что эффективность tcmalloc растёт при росте «поточности» приложений, однако мы видим результаты в пользу других аллокаторов
Этот график из 2018 года. Гугловский tcmalloc был анонсирован только два года назад, когда в него были добавлены restartable sequences. На графике речь идёт скорее всего о tcmalloc из gperftools. Лучше померить производительность самостоятельно.
Интересно, а проектирование и производство самих EUV-степперов хоть в какой-нибудь программе предполагается? Понятно, что проще санкции обходить, но всё-таки...
Это он сейчас развивается отдельно. А изначально он развивался в рамках Envoy. Идея сделать его Universal Data Plane появилась чуть позже.
Это так. Но тем не менее возможность такая есть, как описано здесь https://github.com/envoyproxy/envoy/issues/378#issuecomment-1728846036
И если очень надо, не очень сложно было бы написать своё расширение к Envoy.
Несмотря на популярность Envoy количество его мейнтейнеров очень ограничено. Они в большом дефиците. Доменируют среди них сотрудники Google, у которых свои приоритеты и OKR. Обычно, кто открывает issue, тот и закрывает их патчем. Основная задача мейнтейнера - убедиться, что патч надлежащего качества и хорошо вписывается в архитектуру. Исключения - security issues.
У структуры документации логика есть. БОльшая часть - авто-сгенерирована из коментариев к Protobuf-декларациям. Остальное - поэлементное описание расширений, поскольку практически весь функционал находится в расширениях, включая даже HTTP connection manager, который по сути тоже опциональный фильтр. Кстати, рекомендую делать свою сборку Envoy, убрав все ненужные расширения. Будет немножко быстрее и меньше footprint.
В порядке саморекламы: два года назад я был официальным мейнтейнером Envoy.
Натурально принципиальная электрическая схема в комплекте имеется. Когда-то люди умели в опенсорс железа.
Я в каждом опроснике пишу, что openspace floor plan плохо сказывается не только на моей вовлечённости, но и на продуктивности.
Пока не помогало. Видимо большинству он как раз нравится.
Но вообще бизнес по продаже опросников процветает, HR-бюджеты осваиваются, люди работают, пилят экслюзивные опросники, пишут статьи со ссылками на, типа, авторитеты. Интересно, что бы по этому поводу сказал Дэвид Грабер, автор "Bullshit job".
Необязательно анализировать систему сборки. Компайл-опции можно, например, из debuginfo взять, который в dwarf-формате. Как решался вопрос с динамическим хедером не знаю. Не исключено, что и не решался.
Но сейчас понимаю, что, может, я и наврал про зависимости только первого уровня. Возможно второй уровень тоже ребилдился. Давно дело было. Но точно помню, что экономия на времени билдов была существенная)
Видимо, проблему апдейта устройства вы решаете перефлэшиванием образа целиком. В Маемо делали инкрементальные апдейты и проводили дополнительное тестирование на сломанную бинарную совместимость как раз из-за разных дефайнов, например.
Позже один из инженеров написал скрипт, который скрейпил билдсреду на предмет опций компилятора, линкера, еще чего-то, что сейчас входит в стандарт buildinfo с reproducible-builds.org и сохранял вместе с бинарниками. Это упростило обнаружение коллизий и сократило количество билдов.
Ну, если libc, то нужно почти всë ребилдить, конечно. Но она ведь далеко не на каждый PR обновляется. Это спасает.
Когда-то, давным давно я работал в Нокии в проекте Maemo. Тогда ещё не было Jenkins, и система сборки была своя. Количество репозиториев было значительно больше 500 и дело не ограничивалось Git'ом. Например, репозиторий браузера был на экзотическом Mercurial, и разработчики наотрез отказывались от переезда на Git, потому что их workflow был завязан на апстримовый репозиторий, который у Mozilla был тоже на Mercurial. Ну, и других VCS было в товарных количествах - Subversion, CVS, Darcs и даже deb-src.
В общем, чтобы всё было максимально гибко нельзя было полагаться на триггер билда по PR. Некоторые пакеты релизились вместе, и вместе должны были билдиться. Такое было редко, но случалось. Если их билдить по отдельности, то ни тот, ни другой билд не проходил. Ну, например, либы меняла API, и приложение в новой версии использовало новый API. С версионированием API в embedded никто заморачиваться не хотел, особенно на этапе разработки ещё незарелизинной платформы.
Отсюда вытекала необходимость сканирования всех репозиториев по крону на предмет не PR, а tag'ов с новой версией. Workflow в командах был очень разнообразный, но чаще было так: разработчик делал PR, его ревьювили, особо продвинутые команды запускали свой локальный CI для него. Если всё было хорошо, то его мержили и ставили tag новой версии. Вот эти tag'и уже триггерили общесистемный CI.
Для построения дерева билда, а точнее топологически отсортированного списка, тоже использовалась NetworkX. Но перестраивались не все новые пакеты со всеми зависимостями, а только новые пакеты с неизменившимися зависимостями первого уровня, чтобы убедиться, что API не сломался. Перестравивать все уровни зависимостей смысла нет, только если для обогрева атмосферы (это основная претензия к системам типа OBS или Yocto). Причём новые бинарники неизменившихся зависимостей в итоговый образ не включались. Это необходимо было для того, чтобы Software Updates были поменьше, и чтобы на этапе тестирования этих updates выявить забытые version bumps из-за сломанного ABI.
Полные ребилды делались только при апдейте тулчейнов.
Хорошее было время. Система получилась ну очень гибкая. Но сейчас, если бы начал всё делать заново, то скорее всего написал бы, что-нибудь на основе ServerlessWorkflow.
Мне показалось, что как раз с Маемо ui/ux был перетащен на MeeGo, и в каком-то сильно изменëнном виде продолжает жить как Sailfish. Если хотите увидеть оригинальный MeeGo, погуглите MeeGo WeTab. Вообще концептов ui было много. И это была проблема. Даже не все увидели свет. Тот же N900 должен был быть совсем другим (или N9? не помню уже) - без явно выраженных приложений, но с add-on'ами. И принцип одного приложения для пользования всеми возможными мессенджерами (telepathy framework) - отголосок той концепции. Хотя telepathy появился ещё в N800.
А так да. Linux он везде Linux.
Помню было забавно читать русские переводы тогдашних пресс-релизов. В одном было написано, что Nokia готовится выпустить телефон с новым "iconic UI". Это было переведено как "пользовательский интерфейс на основе иконок". Уверяю вас, там не иконки имелись в виду.
На самом деле от MeeGo в этом телефоне только название маркетинга ради. Внутри это чистый Maemo. MeeGo занималась другая команда, и она пилила свой билд на основе rpm в сотрудничестве с Intel. Ниже на картинке - мой авторский экземпляр :) Пользовался им несколько лет, поэтому надпись сбоку слегка затёрлась.
Виртуалки, конечно, в подах запускаются. Абъюзим аннотации подов для их конфигурации и для управления lifecycle'ом. Зато не нужен отдельный шедулер. Конечный пользователь, разумеется, сам под не создает: есть отдельный контроллер для нашего CRD, который уже разбирается с тем, что именно надо вписать в ресурс пода и как его изменить, чтобы, например, произошел graceful shutdown. В KubeVirt, если мне память не изменяет, для этого есть отдельный CRD типа Action. К сожалению, руки не доходят, чтобы на эту тему статью писать, хотя в планах было. Показать пока тоже не могу - процесс опенсорсинга сильно бюрократизирован.
Писать свой kubelet - это, по-моему, уже перебор. Для достаточной нам функциональности вполне хватает собственного шима отвечающего вот этой спеке. В репозитории containerd есть код скелета шима, который просто надо наполнить своим "мясом". Вообще, архитектура containerd и его плагинная система заслуживает отдельного разговора. Кроме того, недавно там появился SandboxAPI, облегчающий запуск тасков внутри виртуалок. Но это решение ориентировано именно на таски. Для ваших задач (и наших) поможет не сильно.
Диски хранятся в локальном LVM ноды. Используется собственный CSI плагин, который нарезает диски из LVM в момент, когда под уже зашедулен на ноду. CSI - тоже большая тема, поскольку ориентирована на remote storage, а не на local. Наше решение довольно простецкое - OCI-хук скачивает образ и заливает его в готовое устройство на этапе createRuntime. Хотя, наверное, идеологически правильнее применить для local storage готовый populator (ссылку быстро найти не могу, искать лучше по имени Patrick Ohly - он этой темой занимался, когда PMEM был ещё big thing в Intel).
Спасибо! Отличная статья.
Кроме KubeVirt можно ещё посмотреть Virtink. Он легче KubeVirt: обходится без долгоживущего launcher'а, без libvirt и даже без QEMU (вместо него Stratovirt). К сожалению, не поддерживает блочные устройства: VM-ки грузятся с docker-образов, как обычные контейнеры.
Нам, правда, не подошло ни то, ни другое. Написали свой маленький runtime shim для собственного runtimeClass, который вместо runc сразу запускает либо QEMU, либо Stratovirt (напрямую без libvirt) и управляет lifecycle'ом VM-ки через QMP. Аналога virt-handler'а нет. Оказалось, что OCI-hook'ов достаточно, чтобы запровиженить блочные устройства и macvtap. CNI у нас на основе OpenvSwitch - macvtap пробрасывается на порты в нём.
TLDR:
Посылка первая: когда на человека падает манна небесная в виде стольника, он часто готов поделиться четвертаком с ближним.
Посылка вторая: ближний же считает, что делящийся манной поступит несправедливо, если решит поделиться с ним меньшей частью.
Вывод: Всё хорошо прекрасная маркиза. мы уже живём в наиболее справедливом из миров. Где потребительные стоимости просто падают с неба на тех, кто сверху и ими же распределяются среди тех, кто снизу.
Как вы стали миллионером?
Я написал книжку "Как стать миллионером".
Кому-нибудь известны организации, где больше 8 человек могут править один документ?
Хотя... одновременно-редактируемых документов может быть много. Интересно, можно ли сделать кластер collabora office.
"Информация - ценный ресурс"
"Информации слишком много"
Я один вижу здесь противоречие? Или теперь вообще все тексты пишутся роботами для роботов (во всех смыслах)?
Этот график из 2018 года. Гугловский tcmalloc был анонсирован только два года назад, когда в него были добавлены restartable sequences. На графике речь идёт скорее всего о tcmalloc из gperftools. Лучше померить производительность самостоятельно.
This is cool. Would be nice to read a similar piece on io_uring and io ring.
А как на Кипре со школьным образованием? В Греции, говорят, совсем всё плохо.
Оптимист - это, как известно, плохо информированный пессимист. Почему оптимизм противопоставлен скептицизму совершенно непонятно.
Почему скептики угодили в квадрант с общественным развитием? Им претит личная выгода?
Интересно, а проектирование и производство самих EUV-степперов хоть в какой-нибудь программе предполагается? Понятно, что проще санкции обходить, но всё-таки...