In der vergangenen Woche konnte ich ein Test-Setup mit OpenStack Havana (für CentOS) von Grund auf einrichten. Wir haben uns erst einmal auf die Verwaltung der virtuellen Maschinene mittels KVM/libvirt konzentriert und weitere Komponenten wie Quantum erst einmal außen vor gelassen. Zusätzlich haben wir zur Verwaltung des Block Storage cinder aufgsetzt.

In der ersten Installation haben wir bewusst auf Hilfen wie DevStack verzichtet. Wir wollten auch etwas unter die Haube schauen. Ich finde es bemerkenswert, dass die Installation quasi nur aus Copy and Paste aus der OpenStack Dokumentation besteht.

Nachdem der Identity-Service keystone aufgesetzt, der Image-Service glance , der Block Storage cinder , das Dashboard horizon und die Compute-Nodes nova in relativen Standardkonfigurationen eingerichtet waren, haben wir uns an unsere Testfälle gesetzt. Zur Einrichtung der Compute-Nodes ist noch zu sagen, dass alle Zugriff auf die MySQL-Datenbank der Master-Node benötigen.

Das Anlegen und Verwalten der Images geht über die wirklich guten command line tools leicht von der Hand. Daraus Images zu starten ist ebenfalls einfach. Wenn man erst einmal vernünftige Images erstellt hat. Zu vergleichszwecken haben wir Gentoo-Images erzeugt, die so nah an unseren aktuellen VMs liegen wie möglich. Beim Erstellen der Images ist darauf zu achten, einen dhcp-client zu liefern und sich beim hochfahren eine dynamische IP zu holen. Um die Verwaltung kümmert sich OpenStack. Aus Images schreibbare Volumes zu erzeugen gelingt ähnlich einfach wie das Bereitstellen von Images.

Bis hier her hat alles exakt nach Dokumentation funktioniert. Hier noch einmal ein großes Lob für.

Wir spielten ein bisschen mit hoch und runter der VMs rum und waren ein bisschen vom JavaScript-VNC-Interface angetan. Das erste Problem auf das wir gestoßen sind, war die nicht funktionierende Migration. Doch auch hier gab war die Lösung durch Exceptions im Log einfach zu finden. Die Benutzer nova jeder Compute-Node müssen ohne Passwort (ssh-keys) auf die anderen Compute-Nodes zugreifen dürfen. Dies ist vor allem für das Kopieren der Daten nötig. Leider kann man bei der Migration einer VM keine Ziel-Node angeben. Die Auswahl obliegt OpenStack. Es gibt aber die (von uns ungetestete) Möglichkeit mittels Filter in die Auswahl der Ziel-Node einzugreifen. Ich verstehe hier ja durchaus den Sinn. Den Endanwender soll die zugrunde liegende Hardware nicht interessieren. Doch zurück zur Migration. Diese Erfolgt im Falle von laufenden Images immer einhergehend mit einem Neustart der VM. Die in libvirt unterstützte Live-Migration wird von OpenStack (noch) nicht unterstützt. Verwendet man an Stelle von Images aber Volumes, ist mit ein wenig Konfigurationsarbeit auch eine Live-Migration möglich. Wenn in beiden Migrationsfällen die Migration auf die Ziel-Node fehlschlägt, wird der nächste probiert.

OpenStack Havana fühlt sich erstaunlich fertig an und arbeitet an den meisten Stellen wie ich es erwartet habe. Kommt es mal zu Fehlern, lassen sich diese in den Logs finden. Wie das aber leider bei Exceptions im Log so oft der Fall ist, ist häufig nicht klar was genau passiert ist. Oft fehlen daher Quell- und Ziel-Node, was das Debugging erschwert. Schön finde ich die Möglichkeit an bestimmten Stellen eigenen Code einhängen zu können. Siehe Filter oder Driver.

Was mir persönlich ganz gut Gefällt ist die Art und Weise wie OpenStack arbeitet. Es dient als Verwaltungs-Layer und verwendet unter der Haube viele Komponenten die es schon lange gibt und die dementsprechend reif sind. z.B. dnsmasq als dhcp-Server, iSCSI mittels tgt für den Block Storage, u.a. libvirt als Hypervisor. Wenn man im OpenStack mal eine Instanz verloren hat, bedeutet das so keineswegs, dass man nicht mehr dran kommt.

Besonders positiv möchte ich die command line tools erwähnen. Sie kommen alle mit bash_completion daher und bedienen sich intuitiv.

http://vim.wikia.com/wiki/Modeline_magic

For example in python executables that does not ends with .py. I know, do never ever do this. Rollout packages using entry_point console_script. But however.

# vim: set filetype=python tabstop=4 softtabstop=4 shiftwidth=4 textwidth=120 smarttab expandtab:

Do not forget to use "set modeline" in your ~/.vimrc.

But only if you are aware of https://bugs.gentoo.org/show_bug.cgi?id=14088 and https://bugs.gentoo.org/show_bug.cgi?id=73715

Since paster is not compatible with python 3, I need an alternative.

I want to create a python package with a nested namespace. The package name and the first namespace should be the same all the time. For example my.monitoring. The next namespace should be flexible, to generate my.monitoring.solr, or my.monitoring.mysql. Some boilerplate code should be created and at least one script should be generated on installation of the new packages. The script generation is done by entry_points console_script in setup.py

      entry_points="""

      # -*- Entry points: -*-
      [console_scripts]
      solr_stats = my.monitoring.solr.script:solr_main
      """,

mr.bob perfectly does everything I need. Check it out!

Both server running ejabberd 2.1.x

Sync the config files.

# rsync -avP oldhost:/etc/ejabberd/ /etc/ejabberd/

Maybe also copy ssl-certs and allow ejabberd to access the pem file.

On the old server. ejabberd must be still running.

# ejabberdctl backup /tmp/ejabberd-oldhost.backup

On the new server. ejabberd must be already running.

# ejabberdctl restore /tmp/ejabberd-oldhost.backup

This is just a kind of stub. But however ;)

>>> import paramiko.agent

>>> a = paramiko.agent.Agent()
>>> k = a.get_keys()[0]
>>> d = k.sign_ssh_data(None, 'Hello World')
### Transfer d
>>> from paramiko import Message
>>> from paramiko.rsakey import RSAKey
>>> with open('id_rsa.pub') as f:
...     keytype, b64key, _ = f.next().strip().split(None, 2)
...
>>> import base64
>>> pkey = RSAKey(data=base64.b64decode(b64key))
>>> msg=Message(d)
>>> pkey.verify_ssh_sig('Hello World', msg)
True
>>> pkey.verify_ssh_sig('Hellö World', msg)
False

ssh-agent should run.

I integrated pylint into Jenkins to get a better code quality overview. Most of the integrations is quite easy and straightforward.

1. Install the violations plugin for Jenkins.

Jenkins -> Manage Jenkins -> Manage Plugins, or just /pluginManager

2. Create a pylint config and added it to my repo. Using output-format=parseable

$ pylint --generate-rcfile > pylint.cfg

$ ... customize pylint.cfg
$ git add pylint.cfg
$ git commit -a -m "added pylint"
$ git push

3. Added the pylint run to my Jenkins build job.

Jenkins -> MyJob -> Configure

Add build step -> Execute shell

if [ ! -d venv ] ; then

   virtualenv --python=python2.7 venv
fi
source venv/bin/activate
export PYTHONPATH="$PWD:$PYTHONPATH"

pip install pylint

cd repo
### Need this because some strange control sequences when using default TERM=xterm
export TERM="linux"

## || exit 0 because pylint only exits with 0 if everything is correct
pylint --rcfile=pylint.cfg $(find . -maxdepth 1 -name "*.py" -print) MYMODULE/ > pylint.log || exit 0

4. Add the Violation reporting

Jenkins -> MyJob -> Configure

Add post-build Action -> Report Violations

Filled the field pylint with the pattern **/pylint.log

So the next build also performed the pylint run, and generated the report with graphs.

... with the list of source files.

Unfortunately, on click onto the filename, I got an empty page, where I expected the source view, including detected warnings and errors.

I quick search on the jenkins server showed the xml results of the pylint run. The xml was valid, and seemed to be correct. So the reneration of the report should not be the problem.

A web search just gave me some defects, similar to my problem, but the tickets all are still open. So I digged around in the Violations cofiguration in MyJob. Just by "educated guess", I filled the field "Source Path Pattern" with **/

et voila, the the results for each file were available after the next build.

Maybe just because I did not update that often in the last weeks, I ran into this error:

# pacman -Suy

:: Synchronizing package databases...
 core is up to date
 extra is up to date
 community is up to date
 multilib is up to date
error: failed to prepare transaction (could not satisfy dependencies)
:: Starting full system upgrade...
:: poppler-qt: requires poppler=0.22.5

First updating poppler-qt, or to be more exact poppler-qt4, and poppler-glib solved the problem.

# pacman -S poppler-qt

resolving dependencies...
looking for inter-conflicts...
:: poppler-qt4 and poppler-qt are in conflict. Remove poppler-qt? [y/N] y
error: failed to prepare transaction (could not satisfy dependencies)
:: poppler-glib: requires poppler=0.22.5

# pacman -S poppler-qt poppler-glib
resolving dependencies...
looking for inter-conflicts...
:: poppler-qt4 and poppler-qt are in conflict. Remove poppler-qt? [y/N] y

Packages (4): poppler-0.24.0-1  poppler-qt-0.22.5-1 [removal]
              poppler-glib-0.24.0-1  poppler-qt4-0.24.0-1

Total Download Size:    1.18 MiB
Total Installed Size:   5.90 MiB
Net Upgrade Size:       0.08 MiB

:: Proceed with installation? [Y/n] 
:: Retrieving packages ...
 poppler-0.24.0-1-x86_64  922.3 KiB   657K/s 00:01 [----------------------] 100%
 poppler-qt4-0.24.0-...   130.0 KiB   395K/s 00:00 [----------------------] 100%
 poppler-glib-0.24.0...   158.3 KiB   697K/s 00:00 [----------------------] 100%
(3/3) checking keys in keyring                     [----------------------] 100%
(3/3) checking package integrity                   [----------------------] 100%
(3/3) loading package files                        [----------------------] 100%
(3/3) checking for file conflicts                  [----------------------] 100%
(4/4) checking available disk space                [----------------------] 100%
(1/1) removing poppler-qt                          [----------------------] 100%
(1/3) upgrading poppler                            [----------------------] 100%
(2/3) installing poppler-qt4                       [----------------------] 100%
(3/3) upgrading poppler-glib                       [----------------------] 100%

Currently I'm working on a MacBook. Not entirely by choice, however.

I'm trying to use my almost used environment, including tmux. As Terminal replacement I'm using iTerm2, since it seems to be faster. Unfortunately I was not able to use ALT-[left|right] to jump words backward and forward. The only thing I had to do to solve this... capturing the sequences of ALT-left and ALT-right and place them into ~/.inputrc

# Press ALT-left

$ read
^[^[[D
# and ALT-right
$ read
^[^[[C
$ vi ~/.inputrc
"\e\e[D": backward-word
"\e\e[C": forward-word

And open an new instance of iTerm2.

Neues aus der Rubrik "Die sprechenste Fehlermeldung des Tages":

$ mplayer -dumpstream dvb:// -dumpfile test.ts

MPlayer SVN-r36285-4.8.0 (C) 2000-2013 MPlayer Team
Cannot test OS support for SSE, disabling to be safe.
205 audio & 424 video codecs
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.

Playing dvb://.
DVB CONFIGURATION IS EMPTY, exit
Failed to open dvb://.

Selbstverständlich bedeutet diese Meldung nicht, dass es keine Datei ~/.mplayer/channels.conf gibt. Oder selbige vielleicht leer ist. Mitnichten. In Wirklichkeit ist selbstverständlich gemeint, dass mein Benutzer keinen Zugriff auf /dev/dvb/adapter0 hat.

    "errors": {

       "project": "Not given or wrong type", 
       "team": "Not given or wrong type"
   },

Erst einmal ist es blöd, dass die API mir nicht sagt ob ich den Parameter nun nicht angegeben oder ihn falsch gesetzt habe. Egal welche Kombination und Typen ich übergebe, die Meldung bleibt die selbe. Auch wenn ich die Parameter weg lasse.

Da bleibt wieder einmal nichts anderes übrig, als das Code-Repo zu suchen und den Codo zu durchforsten. Stellt sich heraus... die Parameter müssen id und projectid heißen.

Das ist doch böswillig!?