A pile of reblochon (get closer, you can smell them)

SUSE’s Hackweek #9 is over. It has been an awesome week during which I worked hard to make docker a first class citizen on openSUSE. I also spent some time working on an openSUSE container that could be used by docker’s users.

The project has been tracked on this page of hackweek’s wiki, this is a detailed report of what I achieved.

Installing docker on openSUSE 12.3

Docker has been packaged inside of this OBS project.

So installing it requires just two commands:

sudo zypper ar http://download.opensuse.org/repositories/home:/flavio_castelli:/docker/openSUSE_12.3 docker
sudo zypper in docker

There’s also a 1 Click Install for the lazy ones :)

Zypper will install docker and its dependencies which are:

• lxc: docker’s “magic” is built on top of LXC.
• bridge-utils: is used to setup the bridge interface used by docker’s containers.
• dnsmasq: is used to start the dhcp server used by the containers.
• iptables: is used to get containers’ networking work.
• bsdtar: is used by docker to compress/extract the containers.
• aufs3 kernel module: is used by docker to track the changes made to the containers.

The aufs3 kernel module is not part of the official kernel and is not available on the official repositories. Hence adding docker will trigger the installation of a new kernel package on your machine.

Both the kernel and the aufs3 packages are going to be installed from the home:flavio_castelli:docker repository but they are in fact links to the packages created by Michal Hrusecky inside of his aufs project on OBS.

Note well: docker works only on 64bit hosts. That’s why there are no 32bit packages.

Docker appliance

If you don’t want to install docker on your system or you are just curious and want to jump straight into action there’s a SUSE Studio appliance ready for you. You can find it here.

If you are not familiar with SUSE Gallery let me tell you two things about it:

• you can download the appliance on your computer and play with it or…
• you can clone the appliance on SUSE Studio and customize it even further or…
• you can test the appliance from your browser using SUSE Studio’s Testdrive feature (no SUSE Studio account required!).

The latter option is really cool, because it will allow you to play with docker immediately. There’s just one thing to keep in mind about Testdrive: outgoing connections are disabled, so you won’t be able to install new stuff (or download new docker images). Fortunately this appliance comes with the busybox container bundled, so you will be able to play a bit with docker.

Running docker

The docker daemon must be running in order to use your containers. The openSUSE package comes with a init script which can be used to manage it.

The script is /etc/init.d/docker, but there’s also the usual symbolic link called /usr/sbin/rcdocker.

To start the docker daemon just type:

sudo /usr/sbin/rcdocker start

This will trigger the following actions:

1. The docker0 bridge interface is created. This interface is bridged with eth0.
2. A dnsmasq instance listening on the docker0 interface is started.
3. IP forwarding and IP masquerading are enabled.
4. Docker daemon is started.

All the containers will get an IP on the 10.0.3.0/24 network.

Playing with docker

Now is time to play with docker.

First of all you need to download an image: docker pull base

This will fetch the official Ubuntu-based image created by the dotCloud guys.

You will be able to run the Ubuntu container on your openSUSE host without any problem, that’s LXC’s “magic” ;)

If you want to use only “green” products just pull the openSUSE 12.3 container I created for you:

docker pull flavio/opensuse-12-3

Please experiment a lot with this image and give me your feedback. The dotCloud guys proposed me to promote it to top-level base image, but I want to be sure everything works fine before doing that.

Now you can go through the examples reported on the official docker’s documentation.

Create your own openSUSE images with SUSE Studio

I think it would be extremely cool to create docker’s images using SUSE Studio. As you might know I’m part of the SUSE Studio team, so I looked a bit into how to add support to this new format.

– personal opinion –

There are some technical challenges to solve, but I don’t think it would be hard to address them.

– personal opinion –

If you are interested in adding the docker format to SUSE Studio please create a new feature request on openFATE and vote it!

In the meantime there’s another way to create your custom docker images, just keep reading.

Create your own openSUSE images with KIWI

KIWI is the amazing tool at the heart of SUSE Studio and can be used to create LXC containers.

As said earlier docker runs LXC containers, so we are going to follow these instructions.

First of all install KIWI from the Virtualization:Appliances project on OBS:

sudo zypper ar http://download.opensuse.org/repositories/Virtualization:/Appliances/openSUSE_12.3 virtualization:appliances
sudo zypper in kiwi kiwi-doc

We are going to use the configuration files of a simple LXC container shipped the kiwi-doc package:

cp -r /usr/share/doc/packages/kiwi/examples/suse-11.3/suse-lxc-guest ~/openSUSE_12_3_docker

The openSUSE_12_3_docker directory contains two configuration files used by KIWI (config.sh and config.xml) plus the root directory.

The contents of this directory are going to be added to the resulting container. It’s really important to create the /etc/resolv.conf file inside of the final image since docker is going to mount the resol.conf file of the host system inside of the running guest. If the file is not found docker won’t be able to start our container.

An empty file is enough:

touch ~/openSUSE_12_3_docker/root/etc/resolv.conf

Now we can create the rootfs of the container using KIWI:

sudo /usr/sbin/kiwi --prepare ~/openSUSE_12_3_docker --root /tmp/openSUSE_12_3_docker_rootfs

We can skip the next step reported on KIWI’s documentation, that’s not needed with docker because it will produce an invalid container. Just execute the following command:

sudo tar cvjpf openSUSE_12_3_docker.tar.bz2 -C /tmp/openSUSE_12_3_docker_rootfs/ .

This will produce a tarball containing the rootfs of your container.

Now you can import it inside of docker, there are two ways to achieve that:

• from a web server.
• from a local file.

Importing the image from a web server is really convenient if you ran KIWI on a different machine.

Just move the tarball to a directory which is exposed by the web server. If you don’t have one installed just move to the directory containing the tarball and type the following command:

python -m SimpleHTTPServer 8080

This will start a simple http server listening on port 8080 of your machine.

On the machine running docker just type:

docker import http://mywebserver/openSUSE_12_3_docker.tar.bz2 my_openSUSE_image latest

If the tarball is already on the machine running docker you just need to type:

cat ~/openSUSE_12_3_docker.tar.bz2 | docker import - my_openSUSE_image latest

Docker will download (just in the 1st case) and import the tarball. The resulting image will be named ‘my_openSUSE_image’ and it will have a tag named ‘latest’.

The name of the tag is really important since docker tries to run the image with the ‘latest’ tag unless you explicitly specify a different value.

Conclusion

Hackweek #9 has been both productive and fun for me. I hope you will have fun too using docker on openSUSE.

As usual, feedback is welcome.

Sometimes it’s most interesting to just dive in and see what breaks. There’s a Chef cookbook for Ceph on github which seems rather more recently developed than the one in SUSE-Cloud/barclamp-ceph, and seeing as its use is documented in the Ceph manual, I reckon that’s the one I want to be using. Of course, the README says “Tested as working: Ubuntu Precise (12.04)”, and I’m using openSUSE 12.3…

First things first, need a Chef server, so I installed openSUSE 12.3 on a VM, then installed Chef 10 on that, roughly following the manual installation instructions. Note for those following along at home – sometimes the blocks I’ve copied here are just commands, sometimes they include command output as well. You’ll figure it out

# zypper ar -f http://download.opensuse.org/repositories/systemsmanagement:/chef:/10/openSUSE_12.3/systemsmanagement:chef:10.repo
# zypper in rubygem-chef-server
# chkconfig couchdb on
# rccouchdb start
# chkconfig rabbitmq-server on
# rcrabbitmq-server start
# rabbitmqctl add_vhost /chef
# rabbitmqctl add_user chef testing
# rabbitmqctl set_permissions -p /chef chef ".*" ".*" ".*"
# for service in solr expander server server-webui; do
      chkconfig chef-$service on
      rcchef-$service start
  done

I didn’t bother editing /etc/chef/server.rb, the config as shipped works fine (not that the AMQP password is very secure, mind). The only catch is the web UI didn’t start. IIRC this is due to /etc/chef/webui.pem not existing yet (chef-server creates it, but this doesn’t finish until later).

Then configured knife:

# knife configure -i
WARNING: No knife configuration file found
Where should I put the config file? [/root/.chef/knife.rb]
Please enter the chef server URL: [http://os-chef.example.com:4000]
Please enter a clientname for the new client: [root]
Please enter the existing admin clientname: [chef-webui]
Please enter the location of the existing admin client's private key: [/etc/chef/webui.pem]
Please enter the validation clientname: [chef-validator]
Please enter the location of the validation key: [/etc/chef/validation.pem]
Please enter the path to a chef repository (or leave blank):
Creating initial API user...
Created client[root]
Configuration file written to /root/.chef/knife.rb

And make a client for me:

# knife client create tserong -d -a -f /tmp/tserong.pem
Created client[tserong]

Then set up my desktop as a Chef workstation (roughly following these docs, and again pulling Chef from systemsmanagement:chef:10 on OBS):

# sudo zypper in rubygem-chef
# cd ~
# git clone git://github.com/opscode/chef-repo.git
# cd chef-repo
# mkdir -p ~/.chef
# scp root@os-chef:/etc/chef/validation.pem ~/.chef/
# scp root@os-chef:/tmp/tserong.pem ~/.chef/
# knife configure
WARNING: No knife configuration file found
Where should I put the config file? [/home/tserong/.chef/knife.rb]
Please enter the chef server URL: [http://desktop.example.com:4000] http://os-chef.example.com:4000
Please enter an existing username or clientname for the API: [tserong]
Please enter the validation clientname: [chef-validator]
Please enter the location of the validation key: [/etc/chef/validation.pem] /home/tserong/.chef/validation.pem
Please enter the path to a chef repository (or leave blank): /home/tserong/chef-repo
[...]
Configuration file written to /home/tserong/.chef/knife.rb

Make sure it works:

# knife client list
chef-validator
chef-webui
root
tserong

Grab the cookbooks and upload them to the Chef server. The Ceph cookbook claims to depend on apache and apt, although presumably the former is only necessary for RADOSGW, and the latter for Debian-based systems. Anyway:

# cd ~/chef-repo
# git submodule add git@github.com:opscode-cookbooks/apache2.git cookbooks/apache2
# git submodule add git@github.com:opscode-cookbooks/apt.git cookbooks/apt
# git submodule add git@github.com:ceph/ceph-cookbooks.git cookbooks/ceph
# knife cookbook upload apache2
# knife cookbook upload apt
# knife cookbook upload ceph

Boot up a couple more VMs to be Ceph nodes, using the appliance image from last time. These need chef-client installed, and need to be registered with the chef server. knife bootstrap will install chef-client and dependencies for you, but after looking at the source, if /usr/bin/chef doesn’t exist, it actually uses wget or curl to pull http://opscode.com/chef/install.sh and runs that. How this is considered a good idea is completely baffling to me, so again I installed our chef build from OBS on each of my Ceph nodes (note to self: should add this to appliance image on Studio):

# zypper ar -f http://download.opensuse.org/repositories/systemsmanagement:/chef:/10/openSUSE_12.3/systemsmanagement:chef:10.repo
# zypper in rubygem-chef

And ran the now-arguably-safe knife bootstrap from my desktop:

# knife bootstrap ceph-0.example.com
Bootstrapping Chef on ceph-0.example.com
[...]
# knife bootstrap ceph-1.example.com
Bootstrapping Chef on ceph-1.example.com
[...]

Then, roughly following the Ceph Deploying with Chef document.

Generate a UUID and monitor secret (had to do the latter on one of my Ceph VMs, as ceph-authtool is conveniently already installed):

# uuidgen -r
f80aba97-26c5-4aa3-971e-09c5a3afa32f
# ceph-authtool /dev/stdout --name=mon. --gen-key
[mon.]
key = AQC8umZRaDlKKBAAqD8li3u2JObepmzFzDPM3g==

Then on my desktop:

knife environment create Ceph

This I filled in with:

{
  "name": "Ceph",
  "description": "",
  "cookbook_versions": {
  },
  "json_class": "Chef::Environment",
  "chef_type": "environment",
  "default_attributes": {
    "ceph": {
      "monitor-secret": "AQC8umZRaDlKKBAAqD8li3u2JObepmzFzDPM3g==",
      "config": {
        "fsid": "f80aba97-26c5-4aa3-971e-09c5a3afa32f",
        "mon_initial_members": "ceph-0,ceph-1",
        "global": {
        },
        "osd": {
          "osd journal size": "1000",
          "filestore xattr use omap": "true"
        }
      }
    }
  },
  "override_attributes": {
  }
}

Uploaded roles:

# knife role from file cookbooks/ceph/roles/ceph-mds.rb
# knife role from file cookbooks/ceph/roles/ceph-mon.rb
# knife role from file cookbooks/ceph/roles/ceph-osd.rb
# knife role from file cookbooks/ceph/roles/ceph-radosgw.rb

Assigned roles to nodes:

# knife node run_list add ceph-0.example.com 'role[ceph-mon],role[ceph-osd],role[ceph-mds]'
# knife node run_list add ceph-1.example.com 'role[ceph-mon],role[ceph-osd],role[ceph-mds]'

I didn’t bother with recipe[ceph::repo] as I don’t care about installation right now (Ceph is already installed in my VM images).

Had to set "chef_environment": "Ceph" for each node by running:

# knife node edit ceph-0.example.com
# knife node edit ceph-1.example.com

Didn’t set Ceph osd_devices per node – I’m just playing, so can sit on top of the root partition.

Now let’s see if it works:

# knife ssh name:ceph-0.example.com -x root chef-client
[2013-04-11T13:44:47+00:00] INFO: *** Chef 10.24.0 ***
[2013-04-11T13:44:48+00:00] INFO: Run List is [role[ceph-mon], role[ceph-osd], role[ceph-mds]]
[2013-04-11T13:44:48+00:00] INFO: Run List expands to [ceph::mon, ceph::osd, ceph::mds]
[2013-04-11T13:44:48+00:00] INFO: HTTP Request Returned 404 Not Found: No routes match the request: /reports/nodes/ceph-0.example.com/runs
[2013-04-11T13:44:48+00:00] INFO: Starting Chef Run for ceph-0.example.com
[2013-04-11T13:44:48+00:00] INFO: Running start handlers
[2013-04-11T13:44:48+00:00] INFO: Start handlers complete.
[2013-04-11T13:44:48+00:00] INFO: Loading cookbooks [apache2, apt, ceph]
No ceph-mon found.

[2013-04-11T13:44:48+00:00] INFO: Processing template[/etc/ceph/ceph.conf] action create (ceph::conf line 6)
[2013-04-11T13:44:48+00:00] INFO: template[/etc/ceph/ceph.conf] backed up to /var/chef/backup/etc/ceph/ceph.conf.chef-20130411134448
[2013-04-11T13:44:48+00:00] INFO: template[/etc/ceph/ceph.conf] updated content
[2013-04-11T13:44:48+00:00] INFO: template[/etc/ceph/ceph.conf] owner changed to 0
[2013-04-11T13:44:48+00:00] INFO: template[/etc/ceph/ceph.conf] group changed to 0
[2013-04-11T13:44:48+00:00] INFO: template[/etc/ceph/ceph.conf] mode changed to 644
[2013-04-11T13:44:48+00:00] INFO: Processing service[ceph_mon] action nothing (ceph::mon line 23)
[2013-04-11T13:44:48+00:00] INFO: Processing execute[ceph-mon mkfs] action run (ceph::mon line 40)
creating /var/lib/ceph/tmp/ceph-ceph-0.mon.keyring
added entity mon. auth auth(auid = 18446744073709551615 key=AQC8umZRaDlKKBAAqD8li3u2JObepmzFzDPM3g== with 0 caps)
ceph-mon: mon.noname-a 192.168.4.118:6789/0 is local, renaming to mon.ceph-0
ceph-mon: set fsid to f80aba97-26c5-4aa3-971e-09c5a3afa32f
ceph-mon: created monfs at /var/lib/ceph/mon/ceph-ceph-0 for mon.ceph-0
[2013-04-11T13:44:49+00:00] INFO: execute[ceph-mon mkfs] ran successfully
[2013-04-11T13:44:49+00:00] INFO: execute[ceph-mon mkfs] sending start action to service[ceph_mon] (immediate)
[2013-04-11T13:44:49+00:00] INFO: Processing service[ceph_mon] action start (ceph::mon line 23)
[2013-04-11T13:44:49+00:00] INFO: service[ceph_mon] started
[2013-04-11T13:44:49+00:00] INFO: Processing ruby_block[tell ceph-mon about its peers] action create (ceph::mon line 64)
connect to
/var/run/ceph/ceph-mon.ceph-0.asok
failed with
(2) No such file or directory

connect to
/var/run/ceph/ceph-mon.ceph-0.asok
failed with
(2) No such file or directory

[2013-04-11T13:44:49+00:00] INFO: ruby_block[tell ceph-mon about its peers] called
[2013-04-11T13:44:49+00:00] INFO: Processing ruby_block[get osd-bootstrap keyring] action create (ceph::mon line 79)
2013-04-11 13:44:49.928800 7f58e9677700 0
-- :/23863 >> 192.168.4.117:6789/0 pipe(0x18f0d30 sd=3 :0 s=1 pgs=0 cs=0 l=1).fault

2013-04-11 13:44:52.928739 7f58efc1c700 0 -- :/23863 >> 192.168.4.118:6789/0 pipe(0x7f58e0000c00 sd=3 :0 s=1 pgs=0 cs=0 l=1).fault
2013-04-11 13:44:55.929375 7f58e9677700 0 -- :/23863 >> 192.168.4.117:6789/0 pipe(0x7f58e0003010 sd=3 :0 s=1 pgs=0 cs=0 l=1).fault
2013-04-11 13:44:58.929211 7f58efc1c700 0 -- :/23863 >> 192.168.4.118:6789/0 pipe(0x7f58e00039f0 sd=3 :0 s=1 pgs=0 cs=0 l=1).fault
2013-04-11 13:45:01.929787 7f58e9677700 0 -- :/23863 >> 192.168.4.117:6789/0 pipe(0x7f58e00023b0 sd=3 :0 s=1 pgs=0 cs=0 l=1).fault
[...]

And it’s stuck there, trying and failing to talk to something.

See those “no such file or directory” errors after “service[ceph_mon] started”? Yeah? Well, the mon isn’t started, hence the missing sockets in /var/run/ceph.

Why isn’t the mon started? Turns out the ceph init script won’t start any mon (or osd or mds for that matter) if you don’t have entries in the config file with some suffix, e.g. [mon.a]. And all I’ve got is:

[global]
  fsid =  f80aba97-26c5-4aa3-971e-09c5a3afa32f
  mon initial members = ceph-0,ceph-1
  mon host = 192.168.4.118:6789, 192.168.4.117:6789

[osd]
    osd journal size = 1000
    filestore xattr use omap = true

But given the mon recipe triggers ceph-mon-all-starter if using upstart (which it would be, on the “Tested as working: Ubuntu Precise”), and ceph-mon-all-starter seems to just ultimately run something like ceph-mon --cluster=ceph -i ceph-0 regardless of what’s in the config file… Maybe I can cheat.

Directly starting ceph-mon from a shell on ceph-0 before the chef-client run turned out to be a bad idea (bit of a chicken and egg problem figuring out what to inject into the “mon host” line of the config file). So I put a bit of evil into the mon recipe:

diff --git a/recipes/mon.rb b/recipes/mon.rb
index 5cd76de..a518830 100644
--- a/recipes/mon.rb
+++ b/recipes/mon.rb
@@ -61,6 +61,10 @@ EOH
   notifies :start, "service[ceph_mon]", :immediately
 end
 
+execute 'hack to force mon start' do
+  command "ceph-mon --cluster=ceph -i #{node['hostname']}"
+end
+
 ruby_block "tell ceph-mon about its peers" do
   block do
     mon_addresses = get_mon_addresses()

Try again:

# knife ssh name:ceph-0.example.com -x root chef-client
[2013-04-11T15:10:43+00:00] INFO: *** Chef 10.24.0 ***
[2013-04-11T15:10:44+00:00] INFO: Run List is [role[ceph-mon], role[ceph-osd], role[ceph-mds]]
[2013-04-11T15:10:44+00:00] INFO: Run List expands to [ceph::mon, ceph::osd, ceph::mds]
[2013-04-11T15:10:44+00:00] INFO: HTTP Request Returned 404 Not Found: No routes match the request: /reports/nodes/ceph-0.example.com/runs
[2013-04-11T15:10:44+00:00] INFO: Starting Chef Run for ceph-0.example.com
[2013-04-11T15:10:44+00:00] INFO: Running start handlers
[2013-04-11T15:10:44+00:00] INFO: Start handlers complete.
[2013-04-11T15:10:44+00:00] INFO: Loading cookbooks [apache2, apt, ceph]
[2013-04-11T15:10:44+00:00] INFO: Storing updated cookbooks/ceph/recipes/mon.rb in the cache.
No ceph-mon found.

[2013-04-11T15:10:44+00:00] INFO: Processing template[/etc/ceph/ceph.conf] action create (ceph::conf line 6)
[2013-04-11T15:10:44+00:00] INFO: Processing service[ceph_mon] action nothing (ceph::mon line 23)
[2013-04-11T15:10:44+00:00] INFO: Processing execute[ceph-mon mkfs] action run (ceph::mon line 40)
[2013-04-11T15:10:44+00:00] INFO: Processing execute[hack to force mon start] action run (ceph::mon line 65)
starting mon.ceph-0 rank 1 at 192.168.4.118:6789/0 mon_data /var/lib/ceph/mon/ceph-ceph-0 fsid f80aba97-26c5-4aa3-971e-09c5a3afa32f
[2013-04-11T15:10:44+00:00] INFO: execute[hack to force mon start] ran successfully
[2013-04-11T15:10:44+00:00] INFO: Processing ruby_block[tell ceph-mon about its peers] action create (ceph::mon line 69)
adding peer 192.168.4.118:6789/0 to list: 192.168.4.117:6789/0,192.168.4.118:6789/0

adding peer 192.168.4.117:6789/0 to list: 192.168.4.117:6789/0,192.168.4.118:6789/0

[2013-04-11T15:10:44+00:00] INFO: ruby_block[tell ceph-mon about its peers] called
[2013-04-11T15:10:44+00:00] INFO: Processing ruby_block[get osd-bootstrap keyring] action create (ceph::mon line 84)
2013-04-11 15:10:44.432266 7f8f9f8c0700  0 
-- :/25965 >> 192.168.4.117:6789/0 pipe(0x16d9d30 sd=3 :0 s=1 pgs=0 cs=0 l=1).fault

2013-04-11 15:10:50.433053 7f8f9f7bf700  0 -- 192.168.4.118:0/25965 >> 192.168.4.117:6789/0 pipe(0x7f8f94001d30 sd=3 :0 s=1 pgs=0 cs=0 l=1).fault
2013-04-11 15:10:56.433268 7f8fa5e65700  0 -- 192.168.4.118:0/25965 >> 192.168.4.117:6789/0 pipe(0x7f8f94001d30 sd=3 :0 s=1 pgs=0 cs=0 l=1).fault
2013-04-11 15:11:02.433987 7f8f9f8c0700  0 -- 192.168.4.118:0/25965 >> 192.168.4.117:6789/0 pipe(0x7f8f94002db0 sd=3 :0 s=1 pgs=0 cs=0 l=1).fault
2013-04-11 15:11:08.434358 7f8f9f7bf700  0 -- 192.168.4.118:0/25965 >> 192.168.4.117:6789/0 pipe(0x7f8f94004fb0 sd=3 :0 s=1 pgs=0 cs=0 l=1).fault

At this point it’s stalled presumably waiting to talk to the other mon, so in another terminal window had to kick off a chef-client run on ceph-1 to get it into the same state as ceph-0 (knife ssh name:ceph-1.example.com -x root chef-client). This allowed both nodes to progress to the next problem:

2013-04-11 15:11:28.563438 7f8fa5e67780 -1 monclient(hunting): authenticate NOTE: no keyring found; disabled cephx authentication
2013-04-11 15:11:28.563443 7f8fa5e67780 -1 unable to authenticate as client.admin
2013-04-11 15:11:28.563814 7f8fa5e67780 -1 ceph_tool_common_init failed.
2013-04-11 15:11:29.572208 7f2369130780 -1 monclient(hunting): authenticate NOTE: no keyring found; disabled cephx authentication
2013-04-11 15:11:29.572210 7f2369130780 -1 unable to authenticate as client.admin
2013-04-11 15:11:29.572527 7f2369130780 -1 ceph_tool_common_init failed.
2013-04-11 15:11:31.380073 7f1907d18780 -1 monclient(hunting): authenticate NOTE: no keyring found; disabled cephx authentication
2013-04-11 15:11:31.380078 7f1907d18780 -1 unable to authenticate as client.admin
2013-04-11 15:11:31.380720 7f1907d18780 -1 ceph_tool_common_init failed.
2013-04-11 15:11:32.392345 7fc2bc462780 -1 monclient(hunting): authenticate NOTE: no keyring found; disabled cephx authentication
[...]

And we’re spinning again.

But that’s enough for one day.

It’s Hack Week 9 at SUSE, and I’m working on a cracking project this time around. I’ve codenamed it ‘KLyDE’, for K Lightweight Desktop Environment, and it’s an effort to point KDE at the lightweight desktop market.  Surely some mistake, you say?  KDE and lightweight kan’t fit in the same sentence.  I think they can.

This project has been bouncing around my head for a couple of years now, starting on a train ride back from the KDE PIM meeting in Osnabrück in 2010, then I presented it at COSCUP 2012 in Taiwan last August. But work commitments and family always got in the way of completing/finishing it.  SUSE’s hack week gives me 40 hours to throw at it and this time I wasn’t going to tackle it alone, so I enlisted my bro(grammer)s Jos and Klaas.

As has been repeated on Planet KDE over the past decade, KDE is not intrinisically bloated.  At its core, it jumps through a lot of hoops for memory efficiency and speed, and is modular to a fault. But most packagings of KDE take a kitchen sink approach, and when you install your KDE distribution you get a full suite of desktop, applets and applications.  The other major criticism of KDE is that it is too configurable.  The KlyDE project applies KDE’s modularity and configurability to the challenge of making a lightweight desktop.  However, what I don’t want to do is a hatchet job where functionality is crudely chopped out of the desktop to fit some conception of light weight.

We’re approaching problem from 3 sides:

Minimal footprint

The first method of attacking this is by packaging. It involves factoring optional components of the KDE desktop out of the base installation into subpackages that the main packages only have weak dependencies upon, allowing a minimal installation without them.  This targets big lumps of ram/cpu usage and objects of user hatred like Nepomuk and Akonadi, but also smaller items like Activities and Attica (social desktop support) and non-core window decorations/styles/etc.  The actual KDE build includes everything; the optional components are always available, so those who do need one of them can just add the package and start using it.

The second approach is by configuration.  This allows different profiles of KDE desktop with the same installed packages.  We’ve collected sets of configs that represent these profiles, but I’m not entirely sure how to package this yet.  One way would be to ship default profiles as X sessions.  Another would be a first run wizard or KCModule so users can select profile and apply it to their configuration after login.

Simple config
Is a mixture of usability and perception.  A simplified configuration presents fewer choices and is therefore easier to understand.  It also looks faster and more lightweight, because people equate visual simplicity with efficiency.  This is incorrect, of course, but I’m not above exploiting this fallacy to give people what they want. For this aspect, we’re providing an alternate set of System Settings metadata to give it a cut down tree.  The full set remains available, if needed.

Fast startup

Is the most high-risk-for-reward effort.  It’s mostly a perception/first impression thing.  A working desktop shouldn’t need to be started up all the time.  But for people trying out KLyDE for the first time, a fast startup supports the claim to minimalism.  The interesting thing I note so far is that the package splitting and configuration in 1) makes very little different to startup time.  The optional components of KDE are already highly optimised to not affect startup time.  So I’m investigating alternate startup systems; refactoring startkde, Dantti’s systemk, Plasma Active’s startactive, and a systemd-managed startup.

Progress

The packaging effort is mostly done; we have packages in an Open Build Service project, that give you a bare Plasma Workspace when installed on top of a minimal X SUSE 12.3 installation with –no-recommends.

Jos has put a great effort into understanding System Settings and has produced a simple layout, I just need to complete my patch to allow it to use the alternative metadata scheme at runtime.  If we have time, we’ll also customise some KCMs to provide a simple way to control KDE’s theming.

I’ve been busy converting systemd, kdeinit and ksmserver into a native systemd startup by defining systemd unit files.  It’s a steep learning curve as it exposes a number of assumptions on both sides, but I’m getting there.  The unoptimised systemdkde.target starts up in 4s here, vs 6s for the same .kde4 started by startkde.  That might be due to legacy/fault tolerance parts of startkde being left out, so I won’t give more detailed numbers yet.

Next steps

You can see the state of the project on Trello. I’d like to see if there is a startup time  win by parallelizing kded and ksmserver starting modules and apps. I’d like to make an openSUSE pattern for existing installations, and an iso or a disk image for testers.  I’ve also submitted a talk on the subject for Akademy, so I’d like to work on that and get some real data to support this work.

 

It's Hack Week 9 at SUSE, and I'm working on a cracking project this time around. I've codenamed it 'KLyDE', for K Lightweight Desktop Environment, and it's an effort to point KDE at the lightweight desktop market.  Surely some mistake, you say?  KDE and lightweight kan't fit in the same sentence.  I think they can.

This project has been bouncing around my head for a couple of years now, starting on a train ride back from the KDE PIM meeting in Osnabrück in 2010, then I presented it at COSCUP 2012 in Taiwan last August. But work commitments and family always got in the way of completing/finishing it.  SUSE's hack week gives me 40 hours to throw at it and this time I wasn't going to tackle it alone, so I enlisted my bro(grammer)s Jos and Klaas.

As has been repeated on Planet KDE over the past decade, KDE is not intrinsically bloated.  At its core, it jumps through a lot of hoops for memory efficiency and speed, and is modular to a fault. But most packagings of KDE take a kitchen sink approach, and when you install your KDE distribution you get a full suite of desktop, applets and applications.  The other major criticism of KDE is that it is too configurable.  The KlyDE project applies KDE's modularity and configurability to the challenge of making a lightweight desktop.  However, what I don't want to do is a hatchet job where functionality is crudely chopped out of the desktop to fit some conception of light weight. Read on after the break to see how we're doing it.

We're approaching problem from 3 sides:

Minimal footprint

The first method of attacking this is by packaging. It involves factoring optional components of the KDE desktop out of the base installation into subpackages that the main packages only have weak dependencies upon, allowing a minimal installation without them.  This targets big lumps of ram/cpu usage and objects of user hatred like Nepomuk and Akonadi, but also smaller items like Activities and Attica (social desktop support) and non-core window decorations/styles/etc.  The actual KDE build includes everything; the optional components are always available, so those who do need one of them can just add the package and start using it.

The second approach is by configuration.  This allows different profiles of KDE desktop with the same installed packages.  We've collected sets of configs that represent these profiles, but I'm not entirely sure how to package this yet.  One way would be to ship default profiles as X sessions.  Another would be a first run wizard or KCModule so users can select profile and apply it to their configuration after login.

Simple config Is a mixture of usability and perception.  A simplified configuration presents fewer choices and is therefore easier to understand.  It also looks faster and more lightweight, because people equate visual simplicity with efficiency.  This is incorrect, of course, but I'm not above exploiting this fallacy to give people what they want. For this aspect, we're providing an alternate set of System Settings metadata to give it a cut down tree.  The full set remains available, if needed.

Fast startup

Is the most high-risk-for-reward effort.  It's mostly a perception/first impression thing.  A working desktop shouldn't need to be started up all the time.  But for people trying out KLyDE for the first time, a fast startup supports the claim to minimalism.  The interesting thing I note so far is that the package splitting and configuration in 1) makes very little different to startup time.  The optional components of KDE are already highly optimised to not affect startup time.  So I'm investigating alternate startup systems; refactoring startkde, Dantti's systemk, Plasma Active's startactive, and a systemd-managed startup.

Progress

The packaging effort is mostly done; we have packages in an Open Build Service project, that give you a basic 'KlyDE' Plasma Workspace when installed on top of a minimal X SUSE 12.3 installation with --no-recommends.

Jos has put a great effort into understanding System Settings and has produced a simple layout, I just need to complete my patch to allow it to use the alternative metadata scheme at runtime.  If we have time, we'll also customise some KCMs to provide a simple way to control KDE's theming.

I've been busy converting systemd, kdeinit and ksmserver into a native systemd startup by defining systemd unit files.  It's a steep learning curve as it exposes a number of assumptions on both sides, but I'm getting there.  The unoptimised systemdkde.target starts up in 4s here, vs 6s for the same .kde4 started by startkde.  That might be due to legacy/fault tolerance parts of startkde being left out, so I won't give more detailed numbers yet.

Update Thursday 9pm The freedesktop.org sprint is happening at the SUSE offices this weekend so I had a long discussion with Lennart Pöttering about the systemd session effort. It left us with a number of open questions such as how to perform XSMP session restore and XDG autostart of apps, tasks which align with what systemd does, and I got some useful tips on how to start up a real session without losing configurability

Next steps

You can see the state of the project on Trello. I'd like to see if there is a startup time  win by parallelizing kded and ksmserver starting modules and apps. I'd like to make an openSUSE pattern for existing installations, and an iso or a disk image for testers.  I've also submitted a talk on the subject for Akademy, so I'd like to work on that and get some real data to support this work.

 

During the ongoing SUSE Hack Week I had the possibility to make the CoreText-using code in LibreOffice work well enough to be usable. Thus a 64-bit build of LibreOffice is now also fairly usable, at least as long as you don't use any exotic functionality, knock on wood.

As such, it has been possible for a long time to build LibreOffice for OS X with a current Xcode 4.x and its Clang compiler, also as 64-bit code.

LibreOffice has traditionally used the ATSUI API to display text on Mac OS X. ATSUI was deprecated years ago and superseded by CoreText. ATSUI is still present in the OS, but only for 32-bit code. 64-bit code has to use CoreText. Which is a good thing, of course; it forces developers to finally stop using obsolete API if they want to produce 64-bit code.

Naturally, CoreText is also what iOS provides, so it was necessary to get the CoreText engine into shape also for the benefit of the iOS porting effort.

Note that this work has been available in the LibreOffice source code repository continuously, even while known to be far from usable. I don't believe in the "check in the code when it is ready" way of working in an Open Source community.

There are still some known glitches. For instance, the placement of glyphs on a line that you are editing is slightly "nervous". Glyphs might jump back and forth a pixel when you add or remove characters. I will work on fixing this.

Those who are interested can find daily builds.  ("Daily" should be taken with a grain of salt; whether builds have been uploaded for a given day or not depends on whether I remember to keep my tinderbox running, and in what shape the master branch is.)

If you want to build a CoreText-using LibreOffice yourself, use the --enable-coretext option. To build a 64-bit LibreOffice, use --enable-64-bit.

Thanks to Norbert Thiebaud for his initial work on using CoreText.

This week is SUSE Hack Week 9. I wanted to spend some time working on a Ceph appliance image to make it easy to play with Ceph on openSUSE and/or SLES.

I tried making a SLES 11 SP2 appliance with SUSE Studio. I had to add the filesystems and devel:libraries:c_c++ repos from OBS to get reasonably up-to-date Ceph 0.56 and libboost_thread.so.1.49.0, but on boot when the appliance tried to expand its root filesystem, it died claiming it couldn’t load libe2p.so.2. Studio claims to be pulling in e2fsprogs from both the SP2 Updates and filesystems repo, so maybe that’s the problem. It seems impossible to choose one or the other, as they are the same version. (Update: it was just pointed out to me that you can click the little box next to the version number to choose which one is installed – must try again.)

So I left that alone and tried an openSUSE 12.3 appliance. The filesystems/ceph build for 12.3 is disabled, so I branched it and kicked off a build which failed with an exciting OOM error:

[ 3831s] [ 3803.167109] Out of memory: Kill process 16364 (cc1plus) score 254 or sacrifice child
[ 3831s] [ 3803.167959] Killed process 16364 (cc1plus) total-vm:825128kB, anon-rss:168760kB, file-rss:4kB
[ 3831s] g++: internal compiler error: Killed (program cc1plus)
[ 3831s] Please submit a full bug report,
[ 3831s] with preprocessed source if appropriate.
[ 3831s] See  for instructions.

Guess I should do what it says and file a bug. But I really did want something to play with immediately, so I added http://ceph.com/rpm/opensuse12/x86_64/ as a repo, and pulled in the upstream Ceph 0.56 RPMs. This seems to have worked and given me an openSUSE 12.3 image I can use to run through the Ceph 5-Minute Quick Start, Block Device Quick Start and CephFS Quick Start. So, here’s my extremely terse openSUSEified version of those quick start documents:

5-Minute Quick Start

Deploy the Appliance Image

I’m doing this with a couple of VMs, so in my case I make a couple of copies of the image:

# cp ~/openSUSE_12.3_Ceph_0.56.x86_64-0.0.3.qcow2 \
    /var/lib/libvirt/images/ceph-quickstart-server.qcow2
# cp ~/openSUSE_12.3_Ceph_0.56.x86_64-0.0.3.qcow2 \
    /var/lib/libvirt/images/ceph-quickstart-client.qcow2

Then I use virt-manager to create two VMs, backed by those images. Boot ’em up, log in (root password is “linux”), run yast network and set sensible hostnames (“ceph-client” and “ceph-server” instead of “linux-kjqd”, although admittedly those names wouldn’t be very sensible in a real deployment with more than one node).

Edit the Configuration File

The appliance image includes the /etc/ceph/ceph.conf file from the original 5-minute quick start, so log in to ceph-server, edit that file and replace {hostname} and {ip-address} with their real values, then copy the configuration file to ceph-client:

# scp /etc/ceph/ceph.conf ceph-client:/etc/ceph/

Deploy the Configuration

On ceph-server, create directories for each daemon:

# mkdir -p /var/lib/ceph/osd/ceph-0
# mkdir -p /var/lib/ceph/osd/ceph-1
# mkdir -p /var/lib/ceph/mon/ceph-a
# mkdir -p /var/lib/ceph/mds/ceph-a

Still on ceph-server, run the following:

# cd /etc/ceph
# mkcephfs -a -c /etc/ceph/ceph.conf -k ceph.keyring

Start Ceph

On ceph-server:

# chkconfig ceph on
# rcceph start
# ceph health

This will initially show something like:

HEALTH_ERR 576 pgs stuck inactive; 576 pgs stuck unclean; no osds

Eventually it will say HEALTH_OK and you’re good to go.

Copy the Keyring to the Client

This is necessary for authentication:

# scp /etc/ceph/ceph.keyring ceph-client:/etc/ceph/

Block Device Quick Start

On ceph-client:

# rbd create foo --size 4096
# modprobe rbd
# rbd map foo --pool rbd --name client.admin
# mkfs.ext4 -m0 /dev/rbd1
# mkdir /mnt/myrbd
# mount /dev/rbd1 /mnt/myrbd

(Why is this /dev/rbd1, not /dev/rbd/rbd/foo as in the original quick start?)

CephFS Quick Start

On ceph-client (kernel driver, not FUSE):

# mkdir /mnt/mycephfs
# mount -t ceph -o name=admin,secret=$(ceph-authtool \
    --name client.admin /etc/ceph/ceph.keyring --print-key) \
    ceph-server:/ /mnt/mycephfs

Interestingly, this gives “mount: error writing /etc/mtab: Invalid argument”, but still seems to actually mount the filesystem.

Also note that it appears I have 32GB of space for Ceph to use, even though ceph-server only has a 16GB root partition. I rather think that’s because there’s two OSDs, but both are just running off the root filesystem, they’re not separate disks/filesystems. I assume this is one of those Don’t Try This At Home things.

 

After almost 10 years since the first version, version 1.0.0 of the Icecream distributed build tool has been released.


Yes, it's been almost a decade with us. And as it usually is with versions 1.0.0 after such a long time, it doesn't actually bring anything breadth-taking. But there of course have been some fixes and improvements since version 0.9.7, and in fact even one larger feature found its way in, out-of-the-box support for the Clang compiler, including support for its plugins. Written by yours truly, after finding out about this compiler and finding out it was pretty difficult to get it to work with 0.9.7 icecream at least in some way. And also being the reason for repeatedly bugging Coolo about another icecream release :) .

And, on the way to 1.0.0, the development repository has been moved to GitHub. Which should be good, as IMO the fact that it used to be developed in the KDE SVN helped to make the false impression that it is somehow specific to KDE, limiting its use among developers of other projects. This is probably actually the biggest feature of the 1.0.0 release.

So, thanks to everyone who has helped to make compiling a much more pleasant experience (possibly even with the added colors in the icecream monitor ;) ).

Hello friends

Here is another wallpaper proposal for the 13.1 complimentary wallpaper package. The idea here is to form a nice transparency effect with words that relate to the world of Open Source and openSUSE, or course.

I also added a dark leaf in the center to add some green to the image. However the green leaf can be taken out easily if you think it doesn't work well. For the effects and purposes of keeping a dark background design in the pile of complimentary wallpapers.

Please keep your wallpaper submissions, projects and ideas coming. We are gathering your suggestions so please send them in. If you need help creating a wallpaper and submitting it to our project, given that you may not understand the formatting criteria, please contact me or anyone else at the #opensuse-artwork channel on IRC.

For now, here is the new wallpaper (I followed some tutorials online for this one) :D

Thank you!

Anditosan

KDE has released its monthly update for the 4.10 release, and after a brief wait while the Open Build Service worked over the released tarballs, the openSUSE KDE team is pleased to announce the availability of the 4.10.2 release packages for openSUSE 12.2 and 12.3.

[]({{ site.url }}/images/2013/04/757111961.png)

Despite being a minor release, more than 100 bugs were fixed, in particular there were many KDEPIM fixes touching both the low level stack and KMail/KAddressbook/Kontact. Some highlights on the fixed issues:

• Issues creating IMAP folders with KDEPIM (KDE bugs 291143, 292418, 305987)

• Issues with encrypted mails in KDEPIM (KDE bugs 301088, 313478)

• KMail not creating required folders at startup (KDE bug 303117)

• Crashes when using the semantic desktop framework (KDE bug 313478)

• Improvements to CalDAV support in KDEPIM

And this is just a small part of the complete list.

As usual, packages live in the KDE:Release:410 (openSUSE 12.3, openSUSE 12.2) repository. You can add the repositories through zypper or YaST.

The KDE:Distro:Factory repository has also been updated. If you want to contribute and help KDE packaging in openSUSE, use the KDE:Distro:Factory version, otherwise stick to the KDE:Release:410.

The package manager may complain about needing a downgrade of the branding packages: it is harmless, as some packages were splitted and as such they report a lower version number. Just accept the downgrade in the branding packages and all will be well.

Report bugs in packaging to Novell’s Bugzilla, and bugs in the software directly to KDE.

Have fun with 4.10.2!