Happy new year – cleaning up the server room!

Welcome to 2013!

Alex and I are using this time of the year when most of our colleagues are still on holidays to perform maintenance on our office infrastructure.

To prepare for all the goodness we have planned for the Flying Circus in 2013 we decided to upgrade our internet connectivity (switching from painful consumer-grade DSL/SDSL connections to fibre, yeah!)  and also clean up our act in our small private server room. For that we decided to buy a better UPS and PDUs, a new rack to get some space between the servers and clean up the wiring.

Yesterday we prepared the parts we can do ourselves in preparation of the electricians coming in on Friday to start installing that nice Eaton 9355 8kVA UPS.

So, while the office was almost empty two of us managed to use our experience with the data center setups we do to turn a single rack  (pictures of which we’re too ashamed to post) into this:

 

Although the office was almost abandoned, those servers to serve a real purpose and we had to be careful to avoid too massive interruptions as they do handle:

  • our phone system and office door bell
  • secondary DNS for our infrastructure and customer domains
  • chat and support systems
  • monitoring with business-critical alerting

Here’s how we did it:

  • Power down all the components that are not production-related and move them from the existing rack (right one on the front picture) to the new one. For that we already had our rack logically split between “infrastructure development” and “office business” machines.
  • Move the development components (1 switch, 7 servers, 1 UPS) to the new rack. Wire everything again (nicely!) and power it up. Use the power-up cycle to verify that IPMI remote control works. Also notice which machines don’t boot cleanly (which we only found on machines that are under development regarding kernels anyway, yay).
  • Notice that the old UPS isn’t able to actually run all those servers’ load and keep one turned off until we get the new UPS installed.
  • Now that we had space in the existing rack we re-distributed the servers there as well to make the arrangement more logical (routers, switches, and other telco-related stuff at the top). Turn off single servers one-by-one and keep everyone in the office informed about short outages.
  • Install new PDUs in the space we got after removing superfluous cables. Get lots of scratches while taking stuff out and in.
  • Update our inventory databases, take pictures, write blog post. 🙂

As the existing setup was quite old and grew over time we were pretty happy to be able to apply the lessons we learned in those years in between and get everything cleaned up in less than 10 hours. We notice the following things that we did differently this time (and have been doing so in the data center for a while already):

  • Create bundles of network cables for one server (we use 4) and put them  in a systematic pattern into the switch, label them once with the servername at each end. Colors indicate VLAN.
  • Use real PDUs both for IEC and Schuko equipment. Avoid consumer-grade power-distribution.
  • Leave a rack unit between each component to allow operating without hurting yourself, the flexibility to pass wires (KVM) to the front, and to avoid temperature peaks within the rack.
  • Having over-capacity makes it easier to keep things clean which in turn makes you more flexible and brings ease to your mind to focus on the important stuff.

As the pictures indicate we aren’t completely done installing all the shiny new things, so here’s what’s left for the next days and weeks:

  • Wait for the electricians and Eaton to install and activate our new UPS.
  • Wire up the new PDUs with the new UPS and clean up the power wiring for each server.
  • Wait for the telco to finish digging and putting fibre into the street and get their equipment installed so we can enjoy a “real” internet connection.

All in all, we had a very productive and happy first working day in 2013. If this pace keeps up then we should encounter the singularity sometime in April.

yafowil in a Pyramid project

In a new Pyramid project we used deform to render forms. We did not really like it. (The reasons might be detailed in another post.)

To see if other form libraries do better I gave yafowil a try at our gocept Developer Punsch 3: yafowil comes with written documentation. To get a form in our Pyramid application I had to find out some things which are not so clearly documented:

  • Let the project depend on yafowil.webob via setup.py as it contains the necessary WebOb integration.
  • Import the loader from yafowil like below, to allow yafowil to register all its known components (even all the packages in the yafowil.wiget namespace). Otherwise I got strange errors. (The loader symbol is not needed at all in the rest of the code of the form.)
from yafowil import loader
  • To get a value displayed in the rendered form use value keyword parameter in the factory like this:
form['name'] = factory('field:label:text',
                       props=dict(label=u'name', required=True),
                       value=value_getter)

value can be a plain value or a function which gets the widget and the runtime data of the widget as parameters.

  • Some widgets need JavaScript-Libraries. The integration with Pyramid or Fanstatic is not part of the framework. yafowil.base.Factory.resources_for could be a starting point. (I did not do this yet, so it might be wrong.)

Conclusion: yafowil looks like an interesting framework and after getting a starting point it should be useable in Pyramid, too. Maybe this post can help to ease it a bit.

neu@gocept.com

gravGestatten, Stefan Walluhn mein Name – neustes Mitglied der gocept Crew. Seit vielen Jahren bin ich im Unix/Linux-Umfeld als Systemadministrator und Programmierer tätig. Bisher habe ich in erster Linie für kulturellen Zusammenhängen gearbeitet. Über lange Zeit betreute ich die IT des freien Radio Corax in Halle (Saale). Ebenfalls in Halle war ich an der Gründung des Vereins Terminal.21 e.V. beteiligt, der sich zum Ziel gesetzt hat, moderne Technologien für soziale und kulturelle Projekte verfügbar zu machen. Im Rahmen des Vereins gebe ich Schulungen und Workshops zu IT-Themen. Gemeinsam betreiben wir eine mobile IT-Ausstattung zu Festivals und Großevents. Im Jahr 2011 eröffnete Terminal.21 einen lokalen Hackerspace und versucht seither, die IT-Szene der Stadt zu vernetzen.

Seit Mitte November verstärke ich das Team von gocept. Zusammen mit den „alten Hasen“ kümmere ich mich als Administrator um Server und Netzwerk. Gemeinsam sorgen wir für einen stabilen Betrieb der Dienste, finden auftretende Fehler und erdenken solide Lösungen.

Gleich nach meinem Einstieg hatte ich die Gelegenheit, mit allen gocept Mitarbeitern zum Sprint an die Ostsee zu fahren. Zum einen konnte ich das Team auf sehr angenehme Weise kennenlernen, zum anderen hatten wir Zeit in Ruhe gemeinsam zu arbeiten. Während die Entwickler mit verschiedenen JavaScript-Bibliotheken experimentierten haben sich die Admins Ceph, ein verteiltes Dateisystem, angesehen und dessen Einsatz bei gocept evaluiert. Neben ersten Aufgaben im Tagesgeschäft erwartet mich mit Ceph ein größeres Projekt. Ich bleibe gespannt und freue mich auf eine weiterhin interessante Tätigkeit als Administrator bei gocept.

Notizen aus dem Norden

Unsere Herberge auf Rügen 2012
Unsere Herberge auf Rügen 2012

Heute neigt sich unser diesjähriger Sprint dem Ende. Am Dienstag sind wir gen Norden auf die Insel Rügen gefahren, um uns für 3 Tage intensiv darüber zu unterhalten, wie wir in Zukunft Software entwickeln wollen. Der Fokus lag dabei auf der Client-Seite, also dem Teil der Anwendung, der im Browser ausgeführt wird. Hier wollen wir weitere Erfahrung sammeln und Konzepte suchen, wie man wart- und testbaren, strukturierten Code schreibt.

Im Vorfeld haben wir uns auf drei JavaScript Frameworks/Bibliotheken geeinigt, die wir uns dann am Mittwoch in drei Gruppen à zwei Personen intensiv angeschaut haben: Ember, Obviel und Backbone. Neben Dokumentation lesen und Tutorials ausprobieren haben wir auch gegen einen selbst-gestrickten “Spielserver” programmiert, um durch die praktische Erfahrung ein Gefühl für die Konzepte hinter dem Framework zu bekommen und einschätzen zu können, inwieweit sich das Framework in unserem Alltag einsetzen lässt.

Ember hat uns für den Einsatz bei “Grüne Wiese”-Projekten begeistert. Durch die strikte Trennung von Model, View und Controller (MVC) schreibt man nicht nur automatisch saubereren, sondern auch testbaren Code. Das Objekt-Modell bringt automatisierte, bidirektionale Aktualisierung zwischen Model und View mit, und für die Speicherung auf dem Server gibt es ein kleines, gut integriertes REST-Plugin. Der Aufwand, eine funktionierende CRUD-Anwendung, die Änderungen automatisch an den Server propagiert, zu entwickeln, ist mit Ember erstaunlich gering. Auch wie Ember es erlaubt, seine Klassen zu beerben, ist uns positiv aufgefallen. Leider haben wir es nicht geschafft, zwei Ember-Anwendungen auf einer Seite zu laden. Auch ist die Dokumentation noch recht dünn, was daran liegen dürfte, dass Ember noch ein junges Produkt ist.

Hilfreiche Links zu Ember:

Obviel ist streng genommen unser eigenes “Kind”, denn erste Ideen dazu entstanden im Jahre 2008 bei gocept. Obviel ist ein Client-seitiges Web-Framework für jQuery mit einem einfachen, aber genialen Prinzip: für ein JavaScript-Objekt rendert man einen View in einem Element. Dreh- und Angelpunkt bei Obviel sind die Interfaces, die definieren, wie ein View Objekte, die das Interface implementieren, rendert. Entwickler, die mit der Komponenten-Architektur von Zope vertraut sind, werden keine Probleme haben, Obviel zu verstehen. Weiterhin lässt sich Obviel problemlos in bestehende Projekte integrieren, es enthält Unterstützung für Internationalisierung (i18n), Forms mit Validierung, verschiedene Template-Engines, Subviews, …

Hilfreiche Links:

Backbone unterstützt den Entwickler bei der Strukturierung seiner Webanwendungen durch in Code gegossene Konventionen. Es wirkt sehr fokussiert, denn es tut nicht wirklich viel, aber das Wenige tut es sehr sinnvoll. Backbone ist, im Gegensatz zu Ember, sehr gut dokumentiert, löst aber im Moment keines unserer Probleme. Da Backbone insbesondere keine Unterstützung für data binding bietet, haben wir noch Knockout und Rivets ins Spiel gebracht. Für ersteres steht mit Knockback der „Glue-Code“, um die Frameworks miteinander zu verheiraten, schon zur Verfügung, für letzteres mussten wir ihn uns aus der Dokumentation und dem Issue-Tracker des Projekts zusammensuchen.

Weiterführende Links:

Ein Fazit zu ziehen fällt uns nicht leicht: Ember behalten wir für das nächste “Grüne Wiese”-Projekt auf jeden Fall im Auge. Da uns Backbone und Knockout/Rivets nicht überzeugen konnten, haben wir uns noch spontan AngularJS angeschaut – aber auch hier ist im Moment die Ernüchterung groß: Persistieren von Daten ist ein ungelöstes Problem, die Watcher auf dem Model (data binding) feuern nur unregelmäßig oder viel zu oft. Nach längerem Probieren haben wir herausgefunden, dass wir eine eigene Direktive schreiben müssen, die sich um die Persistierung kümmert.

Bleibt also Obviel, das wir an der einen oder anderen Stelle in unseren Projekten schon verwenden. Es wird wohl auch in Zukunft unser Werkzeug, um bestehenden JavaScript-Code zu verbessern oder neue Frontend-Einheiten zu bauen.

Das gocept-Team

Python 2 and 3 compatible builds with zc.buildout

Creating a single-source build environment with zc.buildout that works for both Python 2 and 3 is a bit of a hassle. This blog post shows how to do it for a minimal demo project.

During the sprints at PyCon DE 2012, we tried to make the upcoming 1.0 release of the nagiosplugin library compatible with both Python 2.7 and Python 3.2. Going for a single code base (without preprocessing steps like 3to2) was no too hard. The only thing left was a single-source zc.buildout setup suited for both Python 2.7 and 3.2. It worked out at last, but currently it needs two buildout configurations. This is a little bit kludgy. I hope that things will improve in the near future so that a single-source build environment with zc.buildout will be possible.

In the following, I will demonstrate the steps with a simple demo project called MultiVersion. It contains nothing more than a single class that is supposed to run under both Python 2 and 3. There is also a unit test to verify that the code works. We use zope.testrunner to run the unit tests. The code’s functionality is irrelevant for the examples, so I left it out. You can download the full source if you are interested.

1. Use a recent enough virtualenv

Older versions of virtualenv are generally not suited since they ship with obsolete releases of distribute and pip. Check if the virtualenv included in your GNU/Linux distribution is too old. Anything below 1.8 reduces the chance of success, so better install a current virtualenv locally then. Likewise, our bootstrap.py must be recent enough to support both Python 2 and 3. The standard bootstrap.py from python-distribute.org does currently not work with Python 3.

Now we are ready to create a virtualenv in a fresh source checkout.

Python 3.2:

$ virtualenv -p python3.2 .
Running virtualenv with interpreter /usr/bin/python3.2
New python executable in ./bin/python3.2
Installing distribute.....done.
Installing pip.....done.

Python 2.7:

$ virtualenv -p python2.7 .
Running virtualenv with interpreter /usr/bin/python2.7
New python executable in ./bin/python2.7
Not overwriting existing python script ./bin/python (you must use ./bin/python2.7)
Installing setuptools.....done.
Installing pip.....done.

2. Running buildout with Python 3.2

I will discuss the steps for Python 3.2 first, since main development will concentrate on newer Python versions. After that, I will describe the necessary steps to make the build environment backward compatible.

To run zc.buildout, we need a buildout.cfg file. I prefer to pin package versions in all projects to ensure reliable builds. As of writing this blog post, there is just an alpha release of zc.buildout that supports Python 3.2. Unfortunately, this version of zc.buildout supports Python 3.2 only, so don’t try this with Python 3.3.

My basic buildout.cfg looks like this:

[buildout]
allow-picked-versions = false
develop = .
newest = false
package = multiversion
parts = multiversion test
versions = versions

[versions]
distribute = 0.6.28
z3c.recipe.scripts = 1.0.1
zc.buildout = 2.0.0a2
zc.recipe.egg = 2.0.0a2
zc.recipe.testrunner = 1.4.0
zope.exceptions = 4.0.1
zope.interface = 4.0.1
zope.testrunner = 4.0.4

[multiversion]
recipe = zc.recipe.egg
eggs = ${buildout:package}
interpreter = py

[test]
recipe = zc.recipe.testrunner
eggs = ${buildout:package}
defaults = ['--auto-color']

In my experience, it is best to pin distutils to exactly the same version that is included in virtualenv’s support files. While differing versions are possible, they may trigger hard to find bugs since it is not always clear which version is used is which step.

I use the Python interpreter from my virtualenv’s bin directory while creating the buildout executable. This saves me from using activate/deactivate scripts which are slightly cumbersome in my opinion.

$ bin/python3.2 bootstrap.py
Creating directory 'blog-python-2-3/parts'.
Creating directory 'blog-python-2-3/develop-eggs'.
Generated script 'blog-python-2-3/bin/buildout'.

$ bin/buildout
Develop: 'blog-python-2-3/.'
Installing multiversion.
Generated interpreter 'blog-python-2-3/bin/py'.
Installing test.
Generated script 'blog-python-2-3/bin/test'.

Now we have a working build for Python 3.2:

$ bin/test
Running zope.testrunner.layer.UnitTests tests:
  Set up zope.testrunner.layer.UnitTests in 0.000 seconds.
  Ran 1 tests with 0 failures and 0 errors in 0.002 seconds.
Tearing down left over layers:
  Tear down zope.testrunner.layer.UnitTests in 0.000 seconds.

3. Running buildout with Python 2.7

Unfortunately, the current zc.buildout alpha release does not work with anything except Python 3.2. Running bootstrap.py fails:

$ bin/python2.7 bootstrap.py
Getting distribution for 'zc.buildout==2.0.0a2'.
While:
  Bootstrapping.
  Getting distribution for 'zc.buildout==2.0.0a2'.
Error: Couldn't find a distribution for 'zc.buildout==2.0.0a2'.

There is no single zc.buildout distribution that fits both Python 2.7 and 3.2. To get around this, I need to create a special-case buildout.cfg that changes version pinnings for incompatible packages. Besides zc.buildout, zc.recipe.egg needs different versions for Python 2.7 and 3.2 as well.

I create buildout-2.x.cfg (slightly grumbling):

[buildout]
extends = buildout.cfg

[versions]
zc.buildout = 1.6.3
zc.recipe.egg = 1.3.2

This one does the job when used with both bootstrap and buildout:

$ bin/python2.7 bootstrap.py -c buildout-2.x.cfg
Generated script 'blog-python-2-3/bin/buildout'.

$ bin/buildout -c buildout-2.x.cfg
Develop: 'blog-python-2-3/.'
Installing multiversion.
Generated interpreter 'blog-python-2-3/bin/py'.
Installing test.
Generated script 'blog-python-2-3/bin/test'.

We now have a build environment that builds single-source code for both Python 2.7 and 3.2 using zc.buildout. Of course, this technique could be extended to support even more versions. But I hope that the incompatible packages will be updated in the near future so that the need for special-case buildout.cfg files will go away. What seems to be most missing: a release of zc.buildout that supports all major Python versions.

TL;DR

  • Use a current virtualenv version.
  • Use a compatible bootstrap.py.
  • Pin your package versions.
  • Versions for some packages (including zc.buildout) must be special-cased.

Acknowledgements

I would like to thank Andrei Chirila and Michael Howitz for a great sprint session.

gocept Developer Punsch 3

Nachdem wir dieses Jahr bereits zwei “Developer-BBQs” veranstaltet haben, laden wir am Freitag, 7.12.2012 ab 14:00 Uhr ein weiteres Mal in unser Büro ein. Jahreszeitenbedingt unter dem Titel “Developer-Punsch”!

Die Veranstaltung richtet sich wie immer an alle (Web-)Entwickler und Sysadmins, die wie wir gerne mal über den Tellerrand schauen. In einem an Open Space angelehnten Format möchten wir uns vorher gesammelten Themen widmen, die auch gerne mitgebracht werden können [1].

Wir würden uns freuen, zahlreiche Interessierte aus der Region und auch darüber hinaus  empfangen zu dürfen.

Ab ca. 19 Uhr wird es etwas zu Essen geben und der Punsch wird serviert.

Um Anmeldung per Mail (mail@gocept.com) oder auf dem Etherpad [1] wird gebeten.

P.S.: Since we are addressing local audience we are keeping this post in German. Basically we want developers and admins in our area to meet up, exchange ideas, and enjoy hot punch.

[1] Etherpad zur Anmeldung und Themensammlung

Introducing the “Flying Circus”

We have been busy in the last months to improve the presentation of our hosting and operations services a lot – and if you attended the Plone Conference in Arnhem, you may have noticed some bits and pieces already: T-Shirts, nice graphics, a new logo, etc.

When pondering how to name our product we quickly decided that just using the old “gocept.net” domain wasn’t good enough. As we are also ambivalent about the whole “cloud hype” we were looking for something else: something specific, something with technology, something where people who know their trade do awesome stuff, something not for the fearsome but for people with visions and grand ideas.

What we found was this:

Image

 

We call it the “Flying Circus” – for fearless man doing exactly what is needed to boost the performance, security, and reliability of your web application!

All this is just getting started and we will show a lot more at the PyConDE next week. Or, if you can not make it there, register for more information on flyingcircus.io!