Хотел описать набор практик для создания бэкапов в Restic
Набралось материала на целую статью.

https://habr.com/ru/articles/769622/

Зачем споры FluxCD vs ArgoCD, если можно использовать и то и другое?
https://github.com/flux-subsystem-argo/flamingo/

А вы знали, что в Kubernetes завезли лайф ресайз ресурсов пода без рестарта?
Довольно подробный разбор фичи:
https://medium.com/@karla.saur/trying-out-the-new-in-place-pod-resource-resizing-68a0b3c42b72

Не делает дедуплекацию, но концепт интересный https://tindevops.medium.com/argocd-folder-structure-fda9003271b2

Привет всем, кто меня знает. Кто не знает, наверняка видел мои статьи и доклады про OpenNebula, LINSTOR и KubeVirt.
Я тут немного осмелел и решил пилить своё облако, опенсорсное, на базе KubeVirt.

Я здесь за двумя вещами:
- Хочу собрать список хотелок и болей при использовании OpenNebula / OpenStack.
- Хочу обсудить возможности сотрудничества.
Так как мне нужен стабильный месячный доход для того чтобы продолжать заниматься разработкой и, в дальнейшем, конечно же команда.

Скажем так:
Что если я спроектирую вам облако полностью под ваши нужды, с крутым API и всеми возможностями, и попрошу за это меньше денег чем среднестатистический инженер на поддержку такого же сетапа? Если интересно, пишите, давайте обсуждать! 🙂

хэштег #япиарюсь

Ключевые цели платформы:

1. Стандартизация и максимальное переиспользование компонентов:
Cтремиться к унификации и максимальному переиспользованию всех компонентов, как в пределах платформы, так и вне её. Этот подход исключает вендорлок, минимизирует настройки и активно практикует обмен знаниями.

2. Использование свободных технологий и инструментов:
На данный момент все компоненты платформы основаны на широко известных и признанных в сообществе свободных инструментах и технологиях. Мне нравится такой подход и я хотел бы сохранить его в будущем.

3. Сотрудничество с проектами:
Как в случае проекта KubeVirt, если функция, разрабатываемая для платформы, может быть полезной вышестоящему проекту, с большой вероятностью она будет передана непосредственно в апстрим, вместо того чтобы реализовавать её внутри платформы.

4. Функциональность и обновления:
Основная задача платформы — предоставить оптимальную конфигурацию компонентов, создав готовый, протестированный дистрибутив, готовый для мгновенного внедрения в продакшн, а также безпроблемные обновления всех компонентов, включая операционную систему, ядро и саму платформу.

5. Расширяемость и сообщество:
Пользователи платформы смогут модифицировать существующие приложения и подключать сторонние репозитории. Разработка модулей будет доступна каждому, кто хоть немного знаком с примитивами Kubernetes. В дальнейшем планируется создание community-репозитория с пользовательскими модулями. Однако в ядро платформы войдут только протестированные между ссобой компоненты, необходимые для базового функционала.

6. API как приоритет:
Несмотря на то, что у платформы будет графический интерфейс, его основная цель — обеспечить быстрое погружение и наглядную демонстрацию функций платформы.
Мне хочется верить, что пользователи по достоинству оценят удобный API платформы и предпочтут описывать свою инфраструктуру как код, вместо кликания мышкой в веб-интерфейсе.

Grafana-operator становится частью Grafana
https://github.com/grafana-operator/grafana-operator/discussions/1324