Lettuce и Python3

Published 12/3/2012 by e0ne in Python

 

Решил я для своих маленьких и уютных домашних проектов (pet project'ов) использовать Python 3.3. Казалось бы, ничто не предвещало беды. Ну кроме как отсутстие поддержки Python 3.x у некоторых библиотек. В частности, Lettuce(http://lettuce.it/).

Но так, как я уже выбрал не самый простой, на данный момент, путь (да, я про python3), то отступать было не куда, решил портировать Lettuce под Python 3.3. Возможно, свою роль в этом сыграли еще свежие воспоминания о UA Pycon 2012, в частности, доклад Михаила Коробова “Как всем перейти на Python 3.x” (http://ua.pycon.org/talks/26).

Дальше все понеслось и после нескольких часов ковыряния в исходниках Lettuce и его зависимостей, github fork, py2to3, http://wiki.python.org/moin/PortingPythonToPy3k, http://lettuce.it/dev/index.html, https://groups.google.com/forum/?fromgroups=#!topic/lettuce-developers/MaOPzOuMQzg и постоянных попытках запустить это все получилась первая рабочая версия:), commit, push, кофе, кофе, печеньки... До беты, конечно, еще писать и писать (фиксить и фиксить), но начало уже есть  и отступать некуда, ибо сзади остались только Python 2.x и большой enterprise.

Ссылки на GitHub repos:

 

 

Продолжение следует...

 


 

Никогда не знаешь, где упадет OpenStack(c) 
Я, в процессе очередного дебагга.

Те, кто читает мой твиттер (@e0ne), должны знать, что в последнее время я работаю с OpenStack’ом, а именно занимаюсь(конечно, не один я) попытками его запуска на Red Hat Enterprise Linux (RHEL), CentOS, Scientific Linux, etc. Т.к. все это построено на базе полной и непросветной enterpise в виде RHEL, то сборка нового дистрибутива, как правило, у меня начинается со сборки именно под эту ОС. 

Вот я и хочу поделиться своими впечатлениями от сборки последней версии OpenStack’а под RHEL. Началось все с попытки запустить чуть менее чем полностью поломанную версию essex-1. Потом все продолжилось с версией essex-2. Основные моменты, которые мешали мне радоваться жизни - переделки в glance, связанные и security, которые на время поломали работоспособность EC2 API. 

Проект Glance - это услуги по отбору, регистрации и поиску виртуальных «machine images» (VMI). В рамках Glance используется RESTful API, что позволяет делать запрос метаданных VMI и выполнять поиск фактического образа (VMI). (http://openstack.ru/openstack_glance.html)

И тут я решил попробовать запустить все из последней версии исходников, с master’а...

После небольших усилий инстансы (виртуалки) начали запускаться, но были проблемы с сетью. Команда “killall dnsmasq”, подсказанная моим коллегой, решила часть проблем, а именно - выдачу IP адреса виртуальной машине. Далее в логах при загрузке неворуженым глазом были замечены такие проблемы:

 

Что означало, что запущенный инстанс не может получить данный от Metadata Server’а. Т.к. Metadata Server нормально работал в Diablo, то сразу вспомнились 2 вещи:

 

 

Далее по аналогии с Nova API был создан файл /etc/init.d/openstack-nova-api-metadata, который предназначался для запуске сервиса Metadata Server’а. Metadata Server, на первый взгляд, успешно запустился, то я попытался запустить снова инстанс, что мне привело к предыдущей ошибке. Логи Metadata Server’а немного испугали:

 

Мозг сразу начал представлять кошмары, связанные с выводом strace, linux kernel debugger’ом и так далее. Вовремя опомнившись, я полез в Google. Поиск по “exit code 134” ничего полезного не дал. А вот поиск по “iptables-restore buffer overflow” дал нужный результат в виде двух багов iptables: http://bugzilla.netfilter.org/show_bug.cgi?id=641 иhttps://bugzilla.redhat.com/show_bug.cgi?id=545600. Довольно-таки стандартное, на сколько мне известно, переполнение буфера, вызванное функцией strcpy, которую, к слову, не очень-то и рекомендуют использовать. Подробности в этом комментарии: https://bugzilla.redhat.com/show_bug.cgi?id=545600#c6

 

 

Т.к. обновление iptables в RHEL 6.1 - не самая приоритетная для меня задача, то я решил зайти с другой стороны - посмотреть что же делает OpenStack для получения такого результата.

 

 

https://github.com/openstack/nova/blob/master/bin/nova-api-metadata

Metadata Server запускается таким же способом, как и другие REST-сервисы Nova, поэтому проблему нужно было искать где-то дальше. Об этом же говорили и логи, и ошибка, связанная с iptables.

https://github.com/openstack/nova/blob/master/nova/network/linux_net.py

 

Метод metadata_accept() отрабатывает без ошибок и падает все в iptables_manager.apply().

 

Т.к. данный метод используется далеко не в одном месте

 

 

то ошибка где-то в передаваемых параметрах. В качестве параметров к iptables-restore у меня передавалось такое:

 ip-restore-full.jpg

 

 

Зная о баге в iptables и то, что падало все только при запуске Metadata Server’а, то получилось быстро найти нужную команду, которая все ломала:

iptables-restore <<EOF
*nat
:nova-api-metadata-POSTROUTING - [0:0]
-A POSTROUTING -j nova-api-metadata-POSTROUTING
COMMIT
EOF

len(‘nova-api-metadata-POSTROUTING’)==29, что вместе с символом конца строки в языке С давало нам 30 символов и при копировании их в массив из 29 символов давало нам переполнение буффера (см. ссылки на баги выше). Хорошо, проблема найдена, теперь нужно ее устранить. Для этого находим код, где у нас генерируется имя chain’а:

chain1.jpg, chain2.jpg

 

где:

binary_name = os.path.basename(inspect.stack()[-1][1])

Таким образом проблема была в имени исполняемого файла. Переименовав “/usr/bin/nova-api-metadata” в “/usr/bin/nova-metadata ” все заработало. Вопрос лишь в том, насколько долго оно будет работать с таким “фиксом”? 

Более правильное решение нужно делать исправляя код OpenStack’а и/или обновляя iptables. Также интересно как это себя ведет на других RHEL-based дистрибутивах(версия iptables) и ubuntu, но это уже проверю завтра, а пока поставил качаться нужные образы дистрибутивов...

[Update]

Баг с iptables проверен после установки чистой ОС после установки всех апдейтов с помощью команды "yum update" на следующих ОС:

  • RHEL 6.1 x86_64 - iptables v1.4.7, buffer overflow detected
  • RHEL 6.2 x86_64 - iptables v1.4.7, buffer overflow detected
  • CentOS 6.1 x86_64 - iptables v1.4.7 buffer overflow detected
  • CentOS 6.2 x86_64 - iptables v1.4.7 buffer overflow detected
  • Scientific Linux 6.1 x86_64 - iptables v1.4.7 buffer overflow detected
  • Fedora 15 x86_64 - testing in process
  • Fedora 16 x86_64 - testing in process

 


 

Сейчас только ленивый не писал об облаках. То, что раньше было просто веб-сервисом - сайчас SaaS. Вот раньше я пользовался gmail просто как почтой, теперь мне навязывают что это SaaS и поэтому это еще лучше. Как пользователю - мне все-равно как оно устроено.  Но вернемся ближе к теме поста и посмотрим какие облака вообще бывают.

Наиболее распространенные типы облаков (clouds) это (точные определения можно найти на Википедии, я говорю так, как выглядит это для меня):

  • SaaS (Software as a Service) - софт, как правило, веб-приложения, который работает где-то там на на сервере и не требует установки и/или мощного клиента. Такое себе арендованное ПО.
  • PaaS (Platform as a Service) - платформа для разработки ПО (Google App Engine, Azure). Позволяет с минимальными усилиями писать масштабируемые приложения. Тут провайдер PaaS берет на себя все или почти заботы по масштабированию приложения, обеспечению беспрерывной работы, администрированию серверов и т.д.
  • IaaS (Infrastructure as a Service) - грубо говоря, вам в аренду даются n-е количество серверов(облако), где при необходимости можно быстренько добавить и/или уменьшить количество серверов, памяти на них, объем винчестеров и т.д. Как пример IaaS - Amazon EC2.

Разработка любого облака - достаточно сложное и интересное занятие. Создать с нуля можно, но много уже есть готового. Opensource проектов для создания своего приватного клауда становится все больше. Openstack - один из таких проектов. Это IaaS платформа, написанная на Python. Если немного погуглить, то можно найти нечто похожее на Java и Ruby.

Описывать архитектуру и как работает Openstack я сейчас не буду. Я расскажу лишь о том, что нужно знать для комфортной работы с Openstack’ом. Мне, как веб-разработчику было достаточно быстро войти в процесс, т.к. проект требует спецефических знаний. Один лишь список модулей питона, которые необходимы для запуска одного из компонентов Openstack’а nova содержит 35 пунктов.

  • Python - ведь на нем все написано. Как правило, код достаточно простой и понятный, много комментариев. При написании кода соблюдается PEP8.
  • Знание linux-подобных ОС. Прежде всего, Openstack разрабатывался для работы под Ubuntu, но есть сборки и для других ОС. Под другими ОС имеется в виду Red Hat, CentOS, Fedora и т.д. И врядли он когда-нибудь будет работать под Windows - уж слишком много OS-specific мест наподобии работы с образами виртуальных машин, работа с сетью и т.д. Так же количество гипервизоров по linux значительно больше. Комфортная работа с консолью и понимание того как устроена ОС - навыки, без которых сложно будет работать.
  • Так как одной из основных задач Openstack’a является запуск виртуальных машин(серверов), то знание того как работает виртуализация будут большим плюсом.
  • Работа с сетью, понимание как что работает (VLAN, bridge-интерфейсы, маршрутизация и т.д.), уметь пользоваться iptables.
  • Git - проект хостится на GitHub’е.

Openstack в сети: http://openstack.org
GitHub: https://github.com/openstack