Studying functional programming is an opportunity to greatly broaden your horizons, discover a whole new way to represent programs, to approach problems and reach solutions while thinking about languages. Programming in a functional language is pretty much fundamentally similar to programming in any other type of language (like logic programming), it represents programs and algorithms through distinct forms of abstraction and gives you a new toolset with which to solve programming problems. many of the techniques of functional programming are beginning to be included in new mainstream languages, so taking the time now to immerse yourself in them will leave you with a headstart and a thorough understanding of those techniques.

In that regard i started learning Scheme and reading/solving the exercises in the book “Structure and Interpretation of Computer Programs. Scheme is a very small language which is one of the two major lisp dialects (the other being Common Lisp), one of the oldest functional programming languages. Scheme is small and elegant (the entire language can be built on top of a handful of primitive list manipulating operations), there is also a multitude of sources and educational material to choose from (should you decide to study it too). As such, Scheme is the perfect place to dive into the techniques of functional abstraction. In your new venture make sure to have a look and get accustomed with techniques like:

• recursion
• macros
• closures
• first class functions
• lamda expressions

Vim ? with a Lisp Variant?

Yes, i love vim and in no way am i changing editor just to write in a new language so no Emacs is not an option.

Movement

" A few lisp specific settings
 set lisp               " enable vim's lisp mode
 set autoindent         " new lines copy previous indent 
 set showmatch          " shows matching paren/brace/bracket
 set cpoptions=-m       " when included a showmatch will always wait half a second,
                        " when not it will either wait half a second or until you type a char.
 set foldmethod=indent  " fold indented text

 %     " find the matching paren/brace/bracket
 [(    " go to previous unmatched "("
 [)    " go to previous unmatched ")"

 " this saved me a few keystrokes
 :map [9 [(
 :map [0 [)

 " these can help for searching "(" or ")"
 :map <C-F9> /(<cr>
 :map <C-F10> /)<cr>

 " selecting stuff
 ib   " inner block selection
 ab   " outer block selection

 " like C you can indent and reindent stuff with "=" and "=="

TSlime.vim

TSlime is a simple vim script to send portion of text from your vim buffer to a running interpreter session. You only need to be running vim inside a tmux session and provide the session name,window,pane number to tslime so that it knows where to send subsequent commands.

Then you just select your desired block of text and send it over with

as you might have heard, we’re providing nightly builds of the parts of ownCloud, which is ownCloud community server as well as the ownCloud client on its supported platforms Linux, Windows and Mac.

The nightly builds of the client for Windows and Mac and the source balls can be downloaded from the nightly directory on our download server. They are named after the last release, followed by a date time stamp, which is simply a concatentation of the year, month and day the nightly was built on. For linux we maintain a so called nightly repository in the openSUSE Buildservice which builds for various distributions. That can be added to the linux package management system and that way every morning, an update is there for you. The ownCloud server is built only in the nightly repository from this daily source.

What are nightlies for?

To test ownCloud is a very difficult task. ownCloud is a complex system consisting of variuos parts (anybody thought ownCloud is just a “LAMP web app”?) which supports a huge variety of environments. That multiplies to a huge variety that needs to be tested. We had issues with that in the past and as a result, providing easy access to ready-to-run testing versions is one important action we are taking to improve quality as that enables more people to participate on tests.

Of course nightly builds are not released software, nor got they extensive testing. Nightly builds must never be used on production installations, please, really don’t do.

But maybe you have a test server or virtual machine somewhere in spare. So it would be great if you could install a nightly version on that, combine it with a nightly built client, and see if everything runs as you would expect it.

Another great purpose of the nightly builds is to use it for bug verification. In client development we often comment on bugs with sentences like this is fixed now, please verify with the current nightly build. That way bug reporter get a very quick way to verify the fix of their issue and developers can be sure that their fix really is sufficient.

How are nightlies built?

We are doing the nightly builds through an instance of Jenkins, a continous integration server. With a little script we wrote Jenkins feeds the OBS every night, so this is completely automatted. But more on that in a subsequent blog.

Today is release day!

We just release ownCloud Client 1.2.5, hurrah! It’s a small bug fix release, but it will make more people happy users! It fixes three ugly crashes we found with the help of encouraged bug hunters. One of them was an race between our thread which runs csync and the Qt SSL stack we’re obviously using. That caused a crash which happened after quite some run time, or also never… Hard to reproduce and debug, but finally Danimo and his mighty friends were able to nail that.

The new client can be found through it’s download page, here is the Changelog.

If you find issues, please help us to improve ownCloud by commenting or reporting the bugs on our bugtracker. Thanks!

RPM packages of what will become Apache Subversion 1.8 fairly soon are now available for testing on all current releases of openSUSE and SLE 11.

Note that in this release, serf will replace neon as the default HTTP library, to the extend that the latter is removed completely. I wrote about ra_serf before and added support for it in recent packages. You can test this now with either 1.7 or 1.8 if you are concerned about performance in your network. Please note that for servers running httpd and mod_dav_svn, increasing MaxKeepAliveRequests is highly recommended.

Update: Apache Subversion 1.8 is now released. You can find maintained packages via the software search in the devel:tools:scm:svn project. This will be part of the next release of openSUSE.

Carrying on from my last post, the failed chef-client run came down to the init script in ceph 0.56 not yet knowing how to iterate /var/lib/ceph/{mon,osd,mds} and automatically start the appropriate daemons. This functionality seems to have been introduced in 0.58 or so by commit c8f528a. So I gave it another shot with a build of ceph 0.60.

On each of my ceph nodes, a bit of upgrading and cleanup. Note the choice of ceph 0.60 was mostly arbitrary, I just wanted the latest thing I could find an RPM for in a hurry. Also some of the rm invocations won’t be necessary, depending on what state things are actually in:

# zypper ar -f http://download.opensuse.org/repositories/home:/dalgaaf:/ceph:/extra/openSUSE_12.3/home:dalgaaf:ceph:extra.repo
# zypper ar -f http://gitbuilder.ceph.com/ceph-rpm-opensuse12-x86_64-basic/ref/next/x86_64/ ceph.com-next_openSUSE_12_x86_64
# zypper in ceph-0.60
# kill $(pidof ceph-mon)
# rm /etc/ceph/*
# rm /var/run/ceph/*
# rm -r /var/lib/ceph/*/*

That last gets rid of any half-created mon directories.

I also edited the Ceph environment to only have one mon (one of my colleagues rightly pointed out that you need an odd number of mons, and I had declared two previously, for no good reason). That’s knife environment edit Ceph on my desktop, and set "mon_initial_members": "ceph-0" instead of "ceph-0,ceph-1".

I also had to edit each of the nodes, to add an osd_devices array to each node, and remove the mon role from ceph-1. That’s knife node edit ceph-0.example.com then insert:

  "normal": {
    ...
    "ceph": {
      "osd_devices": [  ]
    }
  ...

Without the osd_devices array defined, the osd recipe fails (“undefined method `each_with_index’ for nil:NilClass”). I was kind of hoping an empty osd_devices array would allow ceph to use the root partition. No such luck, the cookbook really does expect you to be doing a sensible deployment with actual separate devices for your OSDs. Oh, well. I’ll try that another time. For now at least I’ve demonstrated that ceph-0.60 does give you what appears to be a clean mon setup when using the upstream cookbooks on openSUSE 12.3:

knife ssh name:ceph-0.example.com -x root chef-client
[2013-04-15T06:32:13+00:00] INFO: *** Chef 10.24.0 ***
[2013-04-15T06:32:13+00:00] INFO: Run List is [role[ceph-mon], role[ceph-osd], role[ceph-mds]]
[2013-04-15T06:32:13+00:00] INFO: Run List expands to [ceph::mon, ceph::osd, ceph::mds]
[2013-04-15T06:32:13+00:00] INFO: HTTP Request Returned 404 Not Found: No routes match the request: /reports/nodes/ceph-0.example.com/runs
[2013-04-15T06:32:13+00:00] INFO: Starting Chef Run for ceph-0.example.com
[2013-04-15T06:32:13+00:00] INFO: Running start handlers
[2013-04-15T06:32:13+00:00] INFO: Start handlers complete.
[2013-04-15T06:32:13+00:00] INFO: Loading cookbooks [apache2, apt, ceph]
[2013-04-15T06:32:13+00:00] INFO: Processing template[/etc/ceph/ceph.conf] action create (ceph::conf line 6)
[2013-04-15T06:32:13+00:00] INFO: template[/etc/ceph/ceph.conf] updated content
[2013-04-15T06:32:13+00:00] INFO: template[/etc/ceph/ceph.conf] mode changed to 644
[2013-04-15T06:32:13+00:00] INFO: Processing service[ceph_mon] action nothing (ceph::mon line 23)
[2013-04-15T06:32:13+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-15T06:32:14+00:00] INFO: execute[ceph-mon mkfs] ran successfully
[2013-04-15T06:32:14+00:00] INFO: execute[ceph-mon mkfs] sending start action to service[ceph_mon] (immediate)
[2013-04-15T06:32:14+00:00] INFO: Processing service[ceph_mon] action start (ceph::mon line 23)
[2013-04-15T06:32:15+00:00] INFO: service[ceph_mon] started
[2013-04-15T06:32:15+00:00] INFO: Processing ruby_block[tell ceph-mon about its peers] action create (ceph::mon line 64)
mon already active; ignoring bootstrap hint

[2013-04-15T06:32:16+00:00] INFO: ruby_block[tell ceph-mon about its peers] called
[2013-04-15T06:32:16+00:00] INFO: Processing ruby_block[get osd-bootstrap keyring] action create (ceph::mon line 79)
2013-04-15 06:32:16.872040 7fca8e297780 -1 monclient(hunting): authenticate NOTE: no keyring found; disabled cephx authentication
2013-04-15 06:32:16.872042 7fca8e297780 -1 unable to authenticate as client.admin
2013-04-15 06:32:16.872400 7fca8e297780 -1 ceph_tool_common_init failed.
[2013-04-15T06:32:18+00:00] INFO: ruby_block[get osd-bootstrap keyring] called
[2013-04-15T06:32:18+00:00] INFO: Processing package[gdisk] action upgrade (ceph::osd line 37)
[2013-04-15T06:32:27+00:00] INFO: package[gdisk] upgraded from uninstalled to 
[2013-04-15T06:32:27+00:00] INFO: Processing service[ceph_osd] action nothing (ceph::osd line 48)
[2013-04-15T06:32:27+00:00] INFO: Processing directory[/var/lib/ceph/bootstrap-osd] action create (ceph::osd line 67)
[2013-04-15T06:32:27+00:00] INFO: Processing file[/var/lib/ceph/bootstrap-osd/ceph.keyring.raw] action create (ceph::osd line 76)
[2013-04-15T06:32:27+00:00] INFO: entered create
[2013-04-15T06:32:27+00:00] INFO: file[/var/lib/ceph/bootstrap-osd/ceph.keyring.raw] owner changed to 0m
[2013-04-15T06:32:27+00:00] INFO: file[/var/lib/ceph/bootstrap-osd/ceph.keyring.raw] group changed to 0
[2013-04-15T06:32:27+00:00] INFO: file[/var/lib/ceph/bootstrap-osd/ceph.keyring.raw] mode changed to 440
[2013-04-15T06:32:27+00:00] INFO: file[/var/lib/ceph/bootstrap-osd/ceph.keyring.raw] created file /var/lib/ceph/bootstrap-osd/ceph.keyring.raw
[2013-04-15T06:32:27+00:00] INFO: Processing execute[format as keyring] action run (ceph::osd line 83)
creating /var/lib/ceph/bootstrap-osd/ceph.keyring
added entity client.bootstrap-osd auth auth(auid = 18446744073709551615 key=AQAOl2tR0M4bMRAAatSlUh2KP9hGBBAP6u5AUA== with 0 caps)
[2013-04-15T06:32:27+00:00] INFO: execute[format as keyring] ran successfully
[2013-04-15T06:32:28+00:00] INFO: Chef Run complete in 14.479108446 seconds
[2013-04-15T06:32:28+00:00] INFO: Running report handlers
[2013-04-15T06:32:28+00:00] INFO: Report handlers complete

Witness:

ceph-0:~ # rcceph status
=== mon.ceph-0 === 
mon.ceph-0: running {"version":"0.60-468-g98de67d"}

On the note of building an easy-to-deploy Ceph appliance, assuming you’re not using Chef and just want something to play with, I reckon the way to go is use config pretty similar to what would be deployed by this Chef cookbook, i.e. an absolute minimal /etc/ceph/ceph.conf, specifying nothing other than initial mons, then use the various Ceph CLI tools to create mons and osds on each node and just rely on the init script in Ceph >= 0.58 to do the right thing with what it finds (having to explicitly specify each mon, osd and mds in the Ceph config by name always bugged me). Bonus points for using csync2 to propagate /etc/ceph/ceph.conf across the cluster.