Я, к сожалению, не знаю, что за опция такая l3_agent_size, наиболее подходящими кажутся min_l3_agents_per_router и max_l3_agents_per_router…
По поводу решедулинга: «получили возможность», действительно, некорректное высказывание, ведь функционал существовал в ранних релизах, вот только и багов было достаточно. Вспомнить хотя бы баг, когда при падении neutron-server'a отказывал и l3-agent… Новинка в Queens — это выделение DVR/SNAT в отдельный namespace, что в совокупности с включением automatic_l3agent_failover
позволяет в случае сбоя SNAT-службы быстро переключиться с текущего на резервный роутер l3-агента, запущенного на другой ноде.
вручную вообще не рекомендуется, но если вы имеете ввиду почти вручную — packstack, да, это простенько, понятненько и круто. Знаем-плавали.
Не-а, «вручную» в данном случае означает «полностью вручную», без намека на автоматизацию (и уж тем более не all-in-one, только кластер): установка пакетов из cloud-archive или исходников из репозиториев.
К чему вот такая автоматизация установки, которая тебе говорит всё время «Unknown Error» даже в процессе удачного деплоя?
Сочувствую, всегда обидно, когда такое происходит. Можно попробовать оправдать RedHat тем, что это было давно (все-таки 13-ый релиз вышел), но это будет не совсем правдой, — у 8-ки поддержка истекает только в следующем году. Да и простительно ли такое поведение коммерческому продукту?..
Ansible вроде уже есть, но были костыляки вроде того, что Ansible вызывал Puppet и делал часть работы — это как вообще так и зачем?
Не знаю таких примеров, где это встречалось?
Что касается pure Ansible, то проект openstack-ansible — зрелое и универсальное решение, двигающееся в ногу с релизной политикой OpenStack.
Вы совершенно правы! Но когда OpenStack находился на пике своей популярности, об этом старались не думать, не закладывали RnD, не просчитывали риски от столкновения с жестоким миром open-source, — его просто хотели, и все. Понимание приходило значительно позже… Была свидетелем подобной ситуации.
Я искренне считаю, что OpenStack развивается, идя по пути упрощения установки. Документация становится понятнее, debug — нагляднее, количество known exceptions растёт… Но из-за высокого порога вхождения в тему (в принципе) и использования готовых инструментов развёртывания (в частности) деплой зачастую превращается в боль. Ещё и поэтому мы "пилим" свою автоматизацию, с выверенными конфигами и обработчиками.
На мой взгляд, сначала стоит задеплоить pure Openstack вручную пару раз, чтобы наработать экспертную базу, а потом постигать логику работы решений автоматического развёртывания. Обычно к этому моменту уже хватает понимания, в какой момент времени инсталляция пошла не по плану, что делать и кто виноват.
Здесь имеется в виду, что далеко не все смогли справиться с подводными камнями/проблемами/нюансами… Особенно не повезло малому бизнесу (например, компаниям, в которых один системный администратор отвечает за всю существующую инфраструктуру, включая OpenStack).
Нет, у меня был опыт работы только с Mirantis Openstack (в далёком 2016).
По поводу автоматизации: как и процедуры развёртывания инфраструктуры, так и процедуры ее апгрейда мы пишем сами, не полагаясь на готовые решения. Это во многом обуславливается желанием от начала и до конца контролировать данные процессы.
Добрый день!
Спасибо за Ваш отклик, постараюсь в ближайшее время составить развернутый комментарий на тему документации Watcher. В качестве примеров:
Если обратить внимание на раздел Configuring Watcher, можно заметить, что документ содержит массу deprecated options; за актуальной конфигурацией приходится обращаться в Installation Guide.
Совсем не помешали бы Sample Configuration File и Sample Policy File.
По поводу решедулинга: «получили возможность», действительно, некорректное высказывание, ведь функционал существовал в ранних релизах, вот только и багов было достаточно. Вспомнить хотя бы баг, когда при падении neutron-server'a отказывал и l3-agent… Новинка в Queens — это выделение DVR/SNAT в отдельный namespace, что в совокупности с включением automatic_l3agent_failover
Сочувствую, всегда обидно, когда такое происходит. Можно попробовать оправдать RedHat тем, что это было давно (все-таки 13-ый релиз вышел), но это будет не совсем правдой, — у 8-ки поддержка истекает только в следующем году. Да и простительно ли такое поведение коммерческому продукту?..
Не знаю таких примеров, где это встречалось?
Что касается pure Ansible, то проект openstack-ansible — зрелое и универсальное решение, двигающееся в ногу с релизной политикой OpenStack.
Вы совершенно правы! Но когда OpenStack находился на пике своей популярности, об этом старались не думать, не закладывали RnD, не просчитывали риски от столкновения с жестоким миром open-source, — его просто хотели, и все. Понимание приходило значительно позже… Была свидетелем подобной ситуации.
Я искренне считаю, что OpenStack развивается, идя по пути упрощения установки. Документация становится понятнее, debug — нагляднее, количество known exceptions растёт… Но из-за высокого порога вхождения в тему (в принципе) и использования готовых инструментов развёртывания (в частности) деплой зачастую превращается в боль. Ещё и поэтому мы "пилим" свою автоматизацию, с выверенными конфигами и обработчиками.
На мой взгляд, сначала стоит задеплоить pure Openstack вручную пару раз, чтобы наработать экспертную базу, а потом постигать логику работы решений автоматического развёртывания. Обычно к этому моменту уже хватает понимания, в какой момент времени инсталляция пошла не по плану, что делать и кто виноват.
Спасибо, приятно слышать!
Пока нет, но уже вот-вот запустим. Если Вы подписаны на блог ТС, то эту новость никак не пропустите.)
Нет, у меня был опыт работы только с Mirantis Openstack (в далёком 2016).
По поводу автоматизации: как и процедуры развёртывания инфраструктуры, так и процедуры ее апгрейда мы пишем сами, не полагаясь на готовые решения. Это во многом обуславливается желанием от начала и до конца контролировать данные процессы.
Спасибо за Ваш отклик, постараюсь в ближайшее время составить развернутый комментарий на тему документации Watcher. В качестве примеров:
Очень выручают схемы, за них отдельное спасибо!