Zigo's blog

This is the 2nd point release of OpenStack Havana (this is the name of the current stable release of OpenStack). It was out on Thursday (US time), and I uploaded it on Friday (Chinese time). Unfortunately, I realized that the latest python-keystoneclient didn’t support the –token and –endpoint command line options, effectively breaking Keystone itself, and all automated endpoint registration in all core packages. So after fixing Keystone and openstack-pkg-tools, I had to re-upload a 2nd Debian release.

However, after this glitch, the packages passed successfully our CI testing suite: my friends at eNovance and I run the tempest functional test suite each time there’s this kind of major update, so that we can validate the packages are working as expected. And all went well after the new keystone command line options were fixed in the postinst scripts.

As a side note, I fail to see consistency on deprecating these interfaces. While we still have the old “glance index” thing in the Glance client (this is really old), keystoneclient just broke backward compatibility, when keystone is quite recent. So, it looks to me that it wasn’t a great idea to just remove –token and –endpoint this way (though I can understand the need of consistency). Hopefully, this will all be fixed anyway, when we move to the unified python-openstackclient command lines instead of per-project clients.

I realized today that the pkg-openstack team now maintains more than 100 packages. This of course includes general purpose Python modules, which probably will move to the Python module team if it one day supports Git (life is too short: I do not wish to learn such a deprecated technology as SVN). Though this is still a lot of packages, and some more are coming: as per the OpenStack TODO list wiki page, Ironic (a replacement for nova-baremetal), TripleO (OpenStack on OpenStack), Tuskar (contols where things are deployed with TripleO) and Designate (DNS as a Service) are already packaged, and I am waiting for the Icehouse (this is the name of the next stable release) beta3 to be out to upload them to Experimental. This is scheduled for the 6th of March. I believe I am currently nearly up-to-date with the current global-requirements.txt (eg: python dependencies of OpenStack), pending a few Python module upgrades, so hopefully, packaging OpenStack Icehouse beta3 will smooth.

I thought it would have been smooth, though it wasn’t. OpenRC shipped /sbin/rc, which conflicted with the “rc” shell (an implementation of the AT&T Plan 9 shell), and /sbin/runscript was conflicting with minicom. With the help of upstream authors, /sbin/rc was renamed /sbin/openrc, and /sbin/runscript was renamed /sbin/openrc-run.

However, the main goal is reached: after last summer Google Summer of Code project, and a bit of rework for the ruff edges, OpenRC made it to Debian.

So, if you wish to try OpenRC, which is a direct replacement for sysv-rc, just add the Debian Experimental repository to your sources.list, and do “apt-get install openrc”. The only issue will be the first reboot, though that should be fine if one manually shuts down every running daemon, and then type what the postinst suggests as command echoed on the screen. Suggestions on how to improve this is welcome. I warmly also welcome more general feedback.

I’d like to publicly thank Patrick Lauer, Benda (李明宇),  WIlliam Hubbs, Alexander Vershilov (who are all OpenRC upstreams), Bill Wang who was the GSoC studdent working on OpenRC, Roger Leigh who is the current sysv-init/sysv-rc maintainer, for their help and support when porting OpenRC to Debian. Without them, it wouldn’t have been possible.

The point of switching to a new init system is to get rid of huge init scripts. Well, here’s an example OpenRC runscript, rewriting /etc/init.d/rsyslog:

#!/sbin/runscript

command=/usr/sbin/rsyslogd
name="enhanced syslogd"

depend()
{
        provide rsyslogd syslog
        need $remote_fs $time
}

Pretty minimalistic to me... For the record, the original sysv-rc script was 126 lines, and the above is just 10 lines.

OpenStack “upstream” was released today. Thanks to the release team and a big up to TTX for his work.

By the time you read this, probably all of my uploads have reached your local Debian mirror.

Please try Havana using either Sid from any Debian mirror, or using the Wheezy backports available here:

deb http://havana.pkgs.enovance.com/debian havana main
deb http://archive.gplhost.com/debian havana-backports main

Yes, you will need *both* repositories. This is unofficial, though these are the exact same packages as in Sid, just rebuilt for Wheezy.

On the package side, here’s what is new:

– All packages who needs it can now be configured through debconf for the RabbitMQ settings. This is on top of what was already available for Grizzly, which is automated configuration for: keystone auth token, the database, the API endpoints and much more. (remember: this is fully optional, you can always use the non-interactive mode…)

– All Quantum pluggin packages have been removed, and now everything is self-contained in the neutron-common package. The selection of which plugin to use is done directly using the core_plugin= directive in /etc/neutron/neutron.conf. This will also control the init.d script of neutron-server, so that it loads the corresponding ini file in /etc/neutron/plugins. The plugin selection is done through Debconf, so that users don’t have to write the full path of the plugin class, which is (for most) very cryptic (am I the only one who thinks that writing neutron.plugins.openvswitch.ovs_neutron_plugin.OVSNeutronPluginV2 in a configuration file is user friendly?).

– All of the package descriptions and Debconf templates have been reviewed by the Debian internationalization team, and most strings are translated in Czech, Danish, French, Italian, Japanese and Russian (sometimes even more) for almost all packages (thanks everyone!).

I’d like to publicly thanks eNovance for sponsoring my packaging work, and Mehdi Abaakouk for his work on our CI with the tempest tests.

Happy Havana release testing,
Please report bugs through the Debian BTS.

Announcement

After a very long work, over the course of 4 months, I have finished packaging the first RC1 of OpenStack. This comes on time, just 9 days before the official Havana release. Please do try this RC1 before the official 2013.2, code name Havana, is released, and hopefully uploaded to Debian. All of the packages are available from Debian Experimental, keeping Grizzly in Sid. However, there is also some private repositories that I maintain, holding Wheezy backports:

deb http://havana.pkgs.enovance.com/debian havana main

deb http://archive.gplhost.com/debian havana-backports main

The first repository holds the packages maintained within the Alioth group. These are built directly from my Jenkins machine, on each git push. The 2nd repository is holding backports from Sid to Wheezy for the packages that I don’t actively maintain (though a lot of them are in the Python module team, in which I do a lot of packaging and updates as well).

A few numbers

A few numbers about this now. I had to work on 145 source packages: at least backport them to Wheezy, and push them in the GPLHost archive repository above. This generates 360 binary packages. Out of these, I maintain 77 source packages within the Alioth OpenStack group, generating 209 .deb files. That’s a lot of stuff to deal with (and I feel sometimes a bit dizzy about it). While OpenStack is a big jigsaw puzzle to solve for the users, it is even more for someone who has to deal with all the (sometimes buried in the the code) Python dependencies. I hope others will come and join me in this packaging effort, since over the time, there’s more and more work to be done, as the project grows. Note that most of the work is unfortunately done on packaging (and updating) the Python dependencies, working on the packages themselves is done last, at the end of the cycle.

Other things not packaged (yet)

Before the release (and the forthcoming Hongkong summit on the 5th of November), I hope to be able to finish packaging TripleO. TripleO is in fact OpenStack on OpenStack, which works with nova-baremetal. I have no idea how to test or install this, though it sounds like a lot of fun. There are 6 source packages that need to be done. Also, pending on the FTP masters NEW queue, is Trove: Database as a Service. I hope this one can get through soon. There is, also, Marconi, which is an incubated project for a new message queuing service, which probably will replace RabbitMQ (I’m not sure yet what it does, and I will be happy to hear about it at the summit). Lastly, there’s Ironic, which will at some point, replace nova-baremetal. That is, it does cloud computing over bare metal, without virtualization.

All of these new projects are still in an incubation stage, and are not part of the official release yet. Though, I have learned over the course of this past year, that with OpenStack, it’s never early enough to start the packaging work.

Thanks to my sponsor!

Please note that all of this wouldn’t be possible without eNovance sponsoring my packaging work. A big up to all of them for supporting and loving Debian! You guys rox. Also a special thanks to Mehdi / Sileth, for his work testing everything with the Tempest functional tests and the CI platform.