Ну, это моя профессиональная деформация, но я знаю лично десяток людей имеющих OpenStack в продакшн. Конечно, иногда я испытываю противоречивые чувства по поводу нашего production env, но в целом Neutron показывает себя лучшей частью всей системы, хотя очень сложной.
Rackspace, Cern это первое что пришло в голову.
Ну, кому простая труба, а кому VXLAN туннель созданный by OVSwitch. И правила для у этого OVSwitch достаточно мудреные. Все признаки SDN ;)
Может это уже устарело? В любом случае, сразу после установки, если вы позаботились о libvirt и Ваш nova пользователь способен к безпарольному ssh на другие compute hosts, `nova live-migration` работает без всяких дополнительных настроек.
Так что OpenStack поддерживает live migration out of box. По крайней мере так это выглядит для нас.
В случае если Вы используете shared storage и настроили libvirt
`nova live-migration <VM-ID> <HOST-NAME>`
работает без дополнительных настроек OpenStack.
«управление останавливается» звучит для меня как синхронный подход! ;)
В любом случаем большое спасибо, Кокаин один из лучших framework с которым
я знаком, есть повод глянуть на его Go библиотеку.
Позвольте поинтересоваться как вам удается иметь
regionId := region.GetRegionByLbs(req, this.lbs, this.geobase) асинхронным?
Мне чтобы добиться асинхроности приходиться передавть в функцию chan
и ожидать результата с помощью select.
Спасибо.
От на тебе, до вот тебе очень большое расстояние ;)
Я имею в ввиду что то, что вы видите на «витрине» китайского интернет магазина,
и то что они пришлют вам в конце концов — это две большие разницы.
Согласен практически со всем. В разработке без virtualenv не обойтись.
Может дело личного вкуса, но для меня Pyramid и entry points
привносят слишком много магии. И получается что установка и
настройка OpenStack, который использует Pyramid, превращается
в нетривиальную задачу.
Но, наверное, главная причина по которой мы не используем eggs
заключается в том, что наши приложения часто устанавливают третьи лица,
которые и знать не хотят что там внутри Python. А так как речь
идет о множестве машин, то установка и обновление идет через Puppet, Chef
etc которые работают c RPM из коробки.
Мне не понятен Ваш сарказм. Вот как это работает у нас:
RPM кладет приложение в /var/lib/appname
При этом в эту же директорию помещаются наши модули,
/var/lib/appname/foo, /var/lib/appname/bar,…
Init script устанавливает переменную окружения PYTHONPATH=/var/lib/appname
После этого import foo, import bar просто работают.
И зачем здесь virtualenv?
Как я понял, идет обсуждение способа распространения Python приложений.
Я, в составе небольшой группы единомышленников, занимаюсь этим много лет.
И с высоты нашего опыта использование любых способов кроме
rpm/deb выглядит крайне недальновидно. По множеству причин.
Я говорю «мы» потому что сам когда то предлагал использовать eggs, virtualenv, etc.
Но старшие товарищи поправили ;)
Ну а wheels _лично_ мне показались излишне сложным решением.
Остались ли еще не ясные моменты в моих комментариях?
Для меня это выглядит слишком мудрено. Мы считаем что единственно правильный
путь распространения пакетов для Linux это deb/rpm.
FPM делает создание пакетов тривиальным.
Мы даже не используем virtualenv — вполне достаточно установить PYTHONPATH.
А вот мне интересно, чисто в порядке дискуссии, какой такой язык «в руках деструктивного маньяка с топором» будет выглядеть хорошо? Ну или хотя бы лучше чем Python.
Ну, кому простая труба, а кому VXLAN туннель созданный by OVSwitch. И правила для у этого OVSwitch достаточно мудреные. Все признаки SDN ;)
Так что OpenStack поддерживает live migration out of box. По крайней мере так это выглядит для нас.
`nova live-migration <VM-ID> <HOST-NAME>`
работает без дополнительных настроек OpenStack.
В любом случаем большое спасибо, Кокаин один из лучших framework с которым
я знаком, есть повод глянуть на его Go библиотеку.
regionId := region.GetRegionByLbs(req, this.lbs, this.geobase) асинхронным?
Мне чтобы добиться асинхроности приходиться передавть в функцию chan
и ожидать результата с помощью select.
Спасибо.
Что бы это могло быть?
Спасибо за Ваше мнение, дам китайским интернет магазинам еще один шанс :)
Я имею в ввиду что то, что вы видите на «витрине» китайского интернет магазина,
и то что они пришлют вам в конце концов — это две большие разницы.
использовать вот это orchardup.github.io/fig/
Может дело личного вкуса, но для меня Pyramid и entry points
привносят слишком много магии. И получается что установка и
настройка OpenStack, который использует Pyramid, превращается
в нетривиальную задачу.
Но, наверное, главная причина по которой мы не используем eggs
заключается в том, что наши приложения часто устанавливают третьи лица,
которые и знать не хотят что там внутри Python. А так как речь
идет о множестве машин, то установка и обновление идет через Puppet, Chef
etc которые работают c RPM из коробки.
RPM кладет приложение в /var/lib/appname
При этом в эту же директорию помещаются наши модули,
/var/lib/appname/foo, /var/lib/appname/bar,…
Init script устанавливает переменную окружения PYTHONPATH=/var/lib/appname
После этого import foo, import bar просто работают.
И зачем здесь virtualenv?
Я, в составе небольшой группы единомышленников, занимаюсь этим много лет.
И с высоты нашего опыта использование любых способов кроме
rpm/deb выглядит крайне недальновидно. По множеству причин.
Я говорю «мы» потому что сам когда то предлагал использовать eggs, virtualenv, etc.
Но старшие товарищи поправили ;)
Ну а wheels _лично_ мне показались излишне сложным решением.
Остались ли еще не ясные моменты в моих комментариях?
путь распространения пакетов для Linux это deb/rpm.
FPM делает создание пакетов тривиальным.
Мы даже не используем virtualenv — вполне достаточно установить PYTHONPATH.