I am pleased to announce another goiardi release.

This release, version 0.3.3 of goiardi, doesn’t add much in the way of new functionality. The data store and indexer have been tweaked slightly, and go tests have been added for some of the goiardi components. The go test coverage isn’t complete, and most goiardi testing is handled with chef-pedant, but these golang tests will be handy for testing internal functionality that could break, yet not show up in the chef-pedant testing.

While there isn’t much in this release, I decided to make one here because it’s a good place to make one before starting to tackle authentication. Enjoy.

Update: It’s a little embarrassing, but there was a problem merging branches, and a necessary change got backed out or overlooked, so version 0.3.1 has been superseded by version 0.3.3. On the off chance anyone got the previous version, I apologize.

It’s in progress, but goiardi’s getting actual golang test coverage. It’s being built out in the test_writing branch, and so far has coverage with the crypto, data store, indexer, and utility libraries inside goiardi. Already the data store and indexer save and load functions have been reworked to make testing easier, and more tests will be coming soon.

Previously goiardi testing was done with chef-pedant, and that will continue to be the primary means of testing goiardi. However, there are areas where actual go tests will be useful, particularly with things like the data store and indexer that don’t get quite as exercised by chef-pedant. My current thinking is that the go tests should focus more on internals, while chef-pedant coverage is important for testing its public behavior.

Pushed up a change in the latest goiardi master last night that fixes an issue with saving the persistent index and data store files where, if the temp directory was not on the same partition, renaming the file after saving would cause an error. I was clued into this by a tweet in Japanese that seemed to say something about that. Ooops.

As of the most recent commit, goiardi can now rebuild its search index in case it accidentally got deleted or corrupted somehow.

To rebuild, just run knife index rebuild (or knife index rebuild -y if you don’t want to be bothered to press “y” to confirm that you really want to do it). You’ll get a message from knife that ‘knife index rebuild’ has been removed for Chef 11+ servers. This can be ignored; while goiardi identifies itself as a Chef 11+ server, this command will work because they’ve kept it in for older versions of Chef.

Originally posted on time.to.pullthepl.ug.

I am pleased to announce another goiardi (a Chef server written in go) release.

Version 0.3.0 of goiardi adds the ability to save the in-memory data store and the search index to disk, rather than losing everything everytime the server restarts. If the options are set, goiardi will save when it receives a SIGTERM or SIGINT signal, as well as save in the background periodically. The interval defaults to five minutes, but can be specified as an option as well. In the interest of safety and data integrity, goiardi will first save to a temporary file before renaming it to the save file name.

Of course, goiardi will also still happily run entirely in memory as before.

NB: Bear in mind that even if the data has been saved to disk goiardi still keeps the data store and search index in memory while it’s running. This could cause problems if you try to shove too much data into it. I expect most use cases would have no problems (famous last words), but the appropriate caution is warranted.

It still does no authentication or permission checking, and while it does its best to avoid data corruption and data loss it is not a real database and should not be relied on as such. It may be useful for situations where you do not want or need a full real Chef server, but could use persistent data which you don’t get with chef-zero.

Next tasks coming up: provide a way to reindex the data, improve existing docs as needed and write more, make actual go tests, fork chef-pedant and make a “goiardi” mode to simplify testing against chef-pedant.

Anyway, that’s what this release has. Have fun with it if you’re so inclined, and thank you if you do.

Originally posted on time.to.pullthepl.ug.

A while back, I decided that I would like to learn Go, which is a pretty neat language all around (in my humble opinion). I had to come up with some sort of project that would be ambitious enough to teach myself a lot of the language features, but not so huge that I’d give up in frustration. Then I thought of a name, and realized what I had to do.

After many evenings spent coding, I’m proud to announce the first offical release of Goiardi, an in-memory Chef server written in Go (the README has more information). (I started on it before I found out about Chef-Zero, but I decided to keep at it anyway. Chef-Zero was also a huge help in figuring out what the Chef server behavior ought to be.) At this time it has pretty much all the features Chef-Zero does, but sorting searches isn’t working yet. If anyone has real examples of how those sorts are specified, I’d love to hear them.

Goiardi does not support authenication or validation at all, so it isn’t very secure. Of course, it also doesn’t persist its contents, so you probably shouldn’t rely on it for your infrastructure provisioning needs.

Aside from the authentication and permission tests, goiardi performs pretty well against chef-pedant. There are a few minor tests that fail because of slight JSON formatting differences or error messages that don’t agree with chef-pedant, but otherwise it does quite well. Improving its performance against chef-pedant is, of course, an ongoing concern. It should do fine as a stand-in for chef-zero though, or some other situation where you need a chef server running but don’t care if it loses all its information when it quits.

Goiardi is, like many Chef things, open source and licensed under version 2.0 of the Apache License.

The Future

Where to go from here? Goiardi certainly has a lot of room for improvement. The first things I intend to do with it are allowing you to use a config file to store options, and allowing freezing the in-memory data structures to disk so they persist when goiardi is shut down. Those aren’t in this release because if I kept adding “just one more thing” before making a formal release, I’d never actually get it out.

Further in the future, handling real authenication and permissions is pretty important. A real Chef Server mode, where goiardi uses Solr and a real database, is on the roadmap down the road as well. SSL, better documentation, and making the Go code more idiomatic where needed are also on the TODO list.

Anyway, there is is. Feel free to check it out, bang on it, see where it breaks (and where it works). Suggestions, code, and comments are always welcome. Hopefully the comments are nice, but this is the Internet.

Update: At least part of the future is now. Goiardi has config file support now with 0.2.1, huzzah! This release also fixes a problem building goiardi with more recent versions of go-flags.

Goiardi has been tested to compile with the native go compiler and run on Mac OS X (10.7 and 10.8), Debian ‘wheezy’, and Arch Linux. It also builds and runs with gccgo (using the -compiler gccgo option to go), tested on Arch Linux. Efforts are ongoing to get it to build with gccgo without the go command on OmniOS, but so far they’ve been unsuccessful.

The Name

If you’re wondering about the name, Ettore Boiardi was the real Chef Boyardee. Wakka wakka.