AppFlowy is an open-source alternative to Notion
https://github.com/AppFlowy-IO/appflowy

Очередное залипалово: https://gandalf.lakera.ai/. Ваша задача задавать подсказки (prompt) таким образом, чтобы Гендальф раскрыл вам пароль.

Не, ну а чтобы и нет, давно пора:
https://github.com/openstack/openstack-helm

Тем временем вышел релиз Kubevirt 1.0.0 🎉

За исключением функции хотплага сетевых интерфейсов в ченджлоге ничего интересного.
Но теперь версия явно заявляет что KubeVirt стабилен и готов к продакшену.

https://github.com/kubevirt/kubevirt/releases/tag/v1.0.0

Интересная альтернатива гитлабу

https://github.com/theonedev/onedev

Сегодня игрался с talos.dev, оказался приятно удивлен.
И тебе bare-metal provisioning, и PXE, и локальный сетап с бесшовными обновлениями куба. Даже модули ядра предусмотрели, вообще красота.
Наконец-то кто-то сделал Kubernetes правильно!

https://github.com/siderolabs/talos

А вот тут кто-то уже и WebUI к Talos приделал

https://youtu.be/TCIkPvC9_ZA

Я тут задумался, а на чём можно сделать kubernetes-style API-сервер. А нашёл целый проект Kubernetes без Kubelet’а 🤔

https://dev.to/ashokan/kwok-kubernetes-without-kubelet-ie1

Должно быть огонь использовать KWOK с VirtualKubelet

https://github.com/virtual-kubelet/virtual-kubelet

А вообще вот что я на самом деле искал:
You may use this code if you want to build an Extension API Server to use with API Aggregation, or to build a stand-alone Kubernetes-style API server.

https://github.com/kubernetes/sample-apiserver

Тут в коментах накинули ещё интересную либу, которая позволяет транслировать запросы kube-apiserver к etcd в реляцеонные бд, такие как SQLite, PostgreSQL и MySQL

https://github.com/k3s-io/kine

Краткий обзор на docker buildx для мультиплатформеной сборки докерфайлов
https://dev.to/aws-builders/using-docker-buildx-to-create-cross-platform-docker-images-for-seamless-compatibility-4k8b

Сегодня решил поразбираться с тем каким же магическим образом собирается talos.
А для сборки он использует buildx + bldr подключаемый как LLB к buildkit

Был удивлён что теперь Docker поддерживает и кастомные форматы (не только Dockerfile) и позволяет билдить их с использованием внешних инструментов, именуемых LLB
Для того чтобы этот инструмент запустился, достаточно указать условый коментарий в файле:

# syntax = ghcr.io/siderolabs/bldr:v0.2.0

Затем запустить сборку обычным докером:

docker build -f my-file

в итоге сборка такого файла будет произведена LLB-плагином скачаным из registry

больше деталей и другие билдеры тут:

https://github.com/moby/buildkit#exploring-llb

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

https://github.com/openebs/mayastor/releases/tag/v2.3.0

Эти же ребята пилят CSI-драйвер для ZFS. Сам не пробовал, но выглядит вполне рабочим решением.

https://github.com/openebs/zfs-localpv

Прокачай свой tmux

https://medium.com/free-code-camp/tmux-in-practice-scrollback-buffer-47d5ffa71c93

Я тут решил разобраться с тем как работает cloud-init чтобы найти хоть какие-то спецификации для конфигурации. Забегая вперёд скажу - их нет. С архитектурной точки зрения это просто какой-то ужас. Но что-то откопать таки удалось.

Начнём с того что cloud-init поддерживает большое количество датасорсов, там и OpenStack, и OpenNebula, и AWS, и Azure, и Google Cloud, и всё такое…

Все они собираются в единую структуру - instance metadata, которая слава богу имеет стандартизированную спеку. Её можно использовать в скриптах и темплейтах, но передать её напрямую ни через один датасорс нельзя.

Что же из себя представляет датасорс? Как правило это метод получения конфигурации из облака, который, в зависимости от облака в котором работает, превращает метаданные облака в instance metadata. Меня интересовали в первую очередь форматы OpenStack configDrive и NoCloud, которые позволяют передавать метаданные инстанса через ISO или файловую систему со специально определённый лейбл.

И тут начинается самое весёлое, так как единого стандарта нет, но есть некоторые негласные соглашения. А именно, что данные передаются в виде четырёх структур: meta-data, user-data, vendor-data и network-config (именование может быть разное, но суть примерно одна)

- meta-data - более-менее общий для всех клаудов, в нём чаще всего передают instance-id, local-hostname и public-keys для ssh.
- user-data - позволяет принимать в себя cloud-config структуру, которая тоже не стандартизирована, но тоже имеет общепринятые поля, либо вообще может быть чем угодно, например баш-скриптом, jinja-темплейтом для cloud-config’а или скрипта, так и конкатенировать в себя всё вышеперечисленное.
- vendor-data - тоже самое что и user-data, но по логике предоставляется вендором, а не пользователем
- network-config - у разных вендоров разный, но в NoCloud он более-менее стандартизирован и представляет собой конфиг netplan в чистом виде.

Классный powerline для tmux’а
https://github.com/wfxr/tmux-power

Очередная классная статья которая наглядно объясняет то как работают сеть в Kubernetes

https://dev.to/danielepolencic/tracing-pod-to-pod-network-traffic-in-kubernetes-434k

Штука которая умеет патчить произвольные ресурсы на этапе деплоя:
https://github.com/kubemod/kubemod

Seagate выпускают диски 18TB, которые на самом деле являются 2 диска в 1:

Logically, the Exos 2X18 becomes two 9TB drives, and the two actuators address their own logical unit numbers (LUN0 and LUN1), which are addressed independently by the host’s operating system.

https://blocksandfiles.com/2022/11/16/seagate-18tb-disk-speed/