Stanley
Потому что "это другое"
Stanley
Так-так, а почему?
Потому что кубер это не опенстек, а опенстек это не кубер. Разные вещи, для разных целей, разная идеология
Mikhail
такого героя в белоснежнке и 7 гномах не было)))
Mikhail
Так-так, а почему?
я бы сказал, что если вы админите кубер, то вряд-ли будете админить еще и опенстек в рамках одного проекта, т.к. слишком большие задачи
Stanley
Белоснежка это кстати больше про кубер. Одна мастернода, семь воркеров...
Mikhail
но деплоить сервисы стека в кубере можно
akbarov
Спасибо огромное добрый люди, пошел изучать. Вы лучшие ❤️
Stanley
Посетила бизнес идея - открыть курсы по опенстеку. :)
Mikhail
Посетила бизнес идея - открыть курсы по опенстеку. :)
ага, в отусе, они уже курсы по темпесту делали курсы)))
Stanley
Это да. На астрее... Плак-плак
Mikhail
а в астру есть уже советский кубер?
Stanley
Тут такое дело. Рассказать то можно. Но вот научить.. ХЗ. Опенстек это скорее идея, нежели технологическое решение. Он меняется. Он нестабилен. Он другой.
Stanley
То есть, кубер это примерно одна десятка стека. Если ОЧЕНЬ упрощенно.
Mikhail
ну как научить стеку, надо учить базе: линукс, сети, виртуализация, схд
Stanley
Да
Mikhail
костылинг на питоне и го
Stanley
На питоне. Го там пока не особо...
akbarov
Тут такое дело. Рассказать то можно. Но вот научить.. ХЗ. Опенстек это скорее идея, нежели технологическое решение. Он меняется. Он нестабилен. Он другой.
Не, ну это понятно. Основная идея это же закинуть человека в лодку, а дальше он сам будет изучать
Stanley
Не, ну это понятно. Основная идея это же закинуть человека в лодку, а дальше он сам будет изучать
Таки обсудим деньги (жадно потирает ручки). :)
Stanley
И никакой лодки то и нет...
Mikhail
ну я бы сказал с кубером тут тоже общее, что кубер это тоже больше о контейнерах и сетях и хранилках, но кмк там все сильно проще чем в стеке
Stanley
ну я бы сказал с кубером тут тоже общее, что кубер это тоже больше о контейнерах и сетях и хранилках, но кмк там все сильно проще чем в стеке
Да, я вон написал - раз в десять проще.
Stanley
То есть, кубер это про другое
Stanley
И он необходим
Mikhail
кстати, а еще можно стеком кубер запускать)))
Mikhail
прикиньте запускать сервисы стека в кубере, а стеком далть менеджед кубернетес?
Mikhail
Не магнумом единым
https://github.com/gardener/gardener-extension-provider-openstack
J
Напиши в понедельник, что у тебя там с ipmi. Я вряд ли помогу, но могу от души посочувствовать.
Привет)
А вроде разобрались. Новые супермикры адски долго инициализируются и в это время BMC то доступен то нет, когда BMC в режиме shared\failover без выделенного BMC порта.
Там была проблема что при деплое conductor не мог дернуть power status и фейлил деплой.
Пока просто увеличил command_retry_timeout, вместо минуты по дефолту поставил три.
[ipmi]
command_retry_timeout = 180
akbarov
Но шифт стоит как моя квартира которой нет 😁
Dmitry
J
Взлом жопы лицензии отменяется)
J
Откладывается точнее)
J
На момент когда будет время красотой заниматься.
Stanley
k9s и кубспрей вам в дышло :)
NS 🇷🇺
А почему нет?
Pavel
Спрей общий, инвертонри свой
Pavel
спрей это ansible. что в ивентори написал то и делает.
Pavel
Так там либо спрей либо capi либо еще что-то выскокоуровневое.
Pavel
опеншифт - это не ванильный k8s если кто-то влезет на его плюшки будет очень больно возращаться на ванильный k8s
Stanley
опеншифт - это не ванильный k8s если кто-то влезет на его плюшки будет очень больно возращаться на ванильный k8s
Как увидишь цену - вовсе и не больно окажется. :)
Pavel
Зависит от окружения.
Pavel
Так нет. у нас нет регионов
Pavel
просто разные независимые инсталляции
• _
Похоже, кто-то настучал пожаловался на тебя стандартным способом в TG. А бот подхватил)
Stanley
Ну лишь бы работало. Я вообще не понимаю почему нельзя кубер через tf ставить...
Stanley
Но это сугубо потому что я не знаю что такое кубер. :)
Mikhail
Через тангстен фабрик? 😀
Mikhail
Котангенс, проверочное слово кот
Stanley
а кто мешает в tf запихнуть скрипты cloud-init и пост-деплоя? Получится нормальный такой кубер. Управлять - да хоть тем же k9s.
Pavel
Nikita
приветствую, подскажите, пожалуйста, если ли возможность-инструменты для мониторинга-ограничения api запросов к openstack?
J
приветствую, подскажите, пожалуйста, если ли возможность-инструменты для мониторинга-ограничения api запросов к openstack?
В каком виде?
Лимиты на каждого пользователя\проект или глобальные?
J
Или как?
Nikita
В каком виде?
Лимиты на каждого пользователя\проект или глобальные?
и глобально, и на юзера, проект
J
И рыбку съесть и на хуй сесть, как говорится.
Nikita
да я ж спросил просто , есть ли
J
Глобально легко. Если используешь балансировщик, то можно на нем, в зависимости от того чем балансируешь
Или через ratelimit фильтр в api_paste.ini.
J
А для каждого пользователя\проекта не предусмотрено. Только в S3, разве что.
Nikita
А для каждого пользователя\проекта не предусмотрено. Только в S3, разве что.
вот это и хотел услышал
Nikita
Mr
вот это и хотел услышал
Есть sddc, там на базе опенстека можно нарезать по пользователям целые виртуальные датацантры. Отдельно, дорого
J
вот это и хотел услышал
Можно еще изобрести очень грубый рейт лимит, отзывая токены чтобы вынудить клиента переполучать токен. На это уйдет время и таким образом получишь окно в запросах.
Это получится как раз очень кривой рейт лимит для проекта\пользователя.
J
Просят статистику…
Ну так и haproxy и nginx и varnish и traefik, прости хоспаде и всё что используют в качестве балансировщиков умеют отдавать статистику.
J
Статистика то не проблема как раз)
J
По каждому конкретному юзеру можно по логам статистику собрать.
Nikita
Статистика то не проблема как раз)
просто из анализа статистики потом выплывет вопрос лимитов
J
просто из анализа статистики потом выплывет вопрос лимитов
Не обязательно. Какая в них объективная необходимость может возникнуть?
J
Разве что, кто-то будет досить api бестолковыми запросами.