How to run CKAN tests

Published 1/4/2018 by e0ne in Python

CKAN is an open-source DMS (data management system) for powering data hubs and data portals. CKAN makes it easy to publish, share and use data. It powers datahub.io, catalog.data.gov and europeandataportal.eu/data/en/dataset among many other sites. http://ckan.org/

Open source world is interesting and challenging. Sometimes it’s easy and cheap. Sometimes it’s hard to contribute and costs a lot. Looking into the CKAN I was surprised that it’s used by government portals. That’s why I tried to use it a bit. Here is my short manual that extends an official one how to run functional and unit tests.

Unfortunately, I don’t have enough time to make a pull request (maybe you can do it instead of me:) ), so I just make a blog now.

The main issues with tests run are:

 

  • Documentation doesn’t cover all steps
  • CKAN uses outdated versions of Solr and Node.JS
  • Some bugs in tests which will be described later

 

All these things were found (or even reverse-engineered) in sources and CKAN’s CI results. You can found all needed data in the manual, GitHub (https://github.com/ckan/ckan/blob/master/circle.yml and https://github.com/ckan/ckan/blob/master/.circleci-matrix.yml)  and CI report for any pull request (https://github.com/ckan/ckan/pulls). I use the same versions as CI does.

 

I use Ubuntu 16.04 LTS distro in my environment. I strongly recommend to do it inside some virtual machine or containers. So it won’t break anything on your desktop or laptop.

1. Getting sources

Let’s go! First of all, you need to clone sources:

git clone https://github.com/ckan/ckan.git

 

2. Node.JS installation

For UI integration test you need to install Node.JS v. 0.10.33. It won’t work on the latest version for sure. 

curl -O https://nodejs.org/dist/v0.10.33/node-v0.10.33.tar.g

tar pxzf  node-v0.10.33.tar.gz

cd node-v0.10.33

./configure && make

sudo make install

 

You can install required npm packages now to run tests in the future:

npm install -g mocha-phantomjs@3.5.0 phantomjs@~1.9.1

 

3. PostgreSQL installation

I used that version of PostgreSQL which is available on my Linux distro:

apt install postgresql

apt install postgresql-server-dev-9.5

4. Redis

It should be simple, just run:

apt install redis-server

 

5. Python dependencies.

I use virtualenv wherever it’s possible:

cd ~/ckan

virtualenv .venv && . .venv/bin/activate

Once virtualenv is ready and activated, it’s time to install python packages:

pip install -r requirement-setuptools.txt

pip install -r requirements.txt

pip install -r dev-requirements.txt

python setup.py develop 

 

6. Database configuration

Configure some environment variables to get everything working. I used the same values as we’ve got in the Circle CI configuration:

export CKAN_POSTGRES_DB=ckan_test

export CKAN_POSTGRES_USER=ckan_default

export CKAN_POSTGRES_PWD=pass

export CKAN_DATASTORE_POSTGRES_DB=datastore_test

export CKAN_DATASTORE_POSTGRES_WRITE_USER=ckan_default

export CKAN_DATASTORE_POSTGRES_READ_USER=datastore_default

export CKAN_DATASTORE_POSTGRES_READ_PWD=passexport

Create required databases and grant permissions:

sudo -E -u postgres ./bin/postgres_init/1_create_ckan_db.sh

sudo -E -u postgres ./bin/postgres_init/2_create_ckan_datastore_db.sh

sed -i -e 's/.*datastore.read_url.*/ckan.datastore.read_url = postgresql:\/\/datastore_default:pass@\/datastore_test/' test-core.ini

paster datastore -c test-core.ini set-permissions | sudo -u postgres psql

 

7. Solr installation and configuration

To get tests passed I use Solr v. 4.3.1. There is a filed bug about Solr version. CKAN tests don’t work with Solr 6.x now:

curl-O  http://archive.apache.org/dist/lucene/solr/4.3.1/solr-4.3.1.tgz

tar zxvf solr-4.3.1.tgz

Now you have to start Solr. You can run it as a daemon or run it in a separate terminal:

cd solr-4.3.1/example/

java -jar start.jar

 

Solr initialization is required too:

export SOLR_HOME=~/solr-4.3.1

cd ~/ckan

./bin/solr_init/create_core.sh

 

8. Initialize test data

paster db init -c test-core.ini

 

9. Run test CKAN server

paster serve test-core.ini

10. Finally, run UI tests

mocha-phantomjs http://localhost:5000/base/test/index.html

11. Run unit and functional tests

To run all tests you need to execute the following command:

nosetests --ckan --reset-db --with-pylons=test-core.ini --nologcapture ckan ckanext

Unfortunately, you’ll have some failed bugs due to the https://github.com/ckan/ckan/issues/3675 :(. To successfully run all tests, you should use segments. E.g.:

nosetests --ckan --reset-db --with-pylons=test-core.ini --nologcapture --segments=abc ckan ckanext

 


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