Older blog entries for Rich (starting at number 75)

Ceilometer API, Net::OpenStack::Ceilometer

A couple of weeks ago, I agreed to give a talk at Infrastructure.Next about the Ceilometer component of OpenStack. Immediately afterwards, I regretted this, simply because I'm not exactly an expert on Ceilometer. But I've often said that the best way to learn something is to teach it, and what better way to learn about Ceilometer than prepare a presentation about it.

I also find that the folks with the in-depth technical knowledge of a subject might not be the right ones to give intro talks, because they tend to get into the weeds before their audience can get a big picture.

And so I started on a quest to understand Ceilometer, get some basic reporting working, and put together a howto style presentation on reporting with Ceilometer.

It turns out that several things worked very strongly in my favor:

* Ceilometer is installed and enabled by default when you install RDO. So there was no difficulty in getting it installed and configured.

* The documentation has lots of examples in it, and the API works exactly as documented.

* My presentation is only a half hour, rather than the hour that I initially thought it was, so I ended up having to trim the content, rather than come up with additional examples.

Along the way, I got tired of trying to issue HTTP API requests from the command line, and parse the response. Being a Perl guy, I started to write some perl code around this, and before I knew it, I had a full module to do all of the stuff that I wanted for my presentation.

It's up on Github at https://github.com/rbowen/NetOpenStackCeilometer and I expect I'll put it on CPAN eventually, once it stabilizes a little. In particular, the statistics() method lacks a lot of the capabilities of Ceilometer's statistics functionality, and does only what I needed for my talk. Also the interface is kind of icky.

I should note that there are some other OpenStack modules already on CPAN, and this one takes a very different approach. This is the main reason I haven't put this on CPAN yet. The other modules, by Naveed Massjouni, use Moose, and I have not yet used Moose for anything. I'm reluctant to put my stuff on CPAN while it uses such a different approach.

Patches welcome. I'd love to hear if you find this at all useful.

Come see me at Infrastructure.Next.

Syndicated 2014-01-16 15:14:34 (Updated 2014-01-22 19:58:23) from Notes In The Margin

Copyright statements in source files

Earlier today I was looking at a source file for the Ceilometer docs and noticed that there's a copyright statement at the top.

Now, in no way do I want to pick on Nicholas. There are hundreds of such copyright statements in the OpenStack docs and code, and this is just the example I happened to be looking at.

(Note that my employer has its share of copyright statements in the OpenStack code. Pretty much every company participating in OpenStack does this. I think we need to stop.)

I sent a note to the OpenStack-docs list, and it has generated a thread of remarks.

As I understand it, people are encouraged to put copyright statements in contributed source code and documentation, and add copyright lines to files that they modify.

I believe this to be a very bad thing to do, for the following reasons:

* If I edit a file and it says at the top that the file is copyright BigCo, I am discouraged from editing that file, because of the implication that I'm treading on someone else's toes. Files should not have any indication that they are "owned" by any one person or company. (See this by Karl Fogel for more on "owning" code.) This actively discourages people jumping in and fixing stuff.

* If N people contribute to a file, are we supposed to have N copyright statements in the file? This doesn't scale over time. Imagine what these files will look like 10 years from now, and fix the problem now.

* Having author names in a file encourages people to contribute for the wrong reasons.

* Git keeps track of who contributed what changes. It's not necessary to have explicit copyright statements.

The first of those reasons is, to me, the most compelling. Anything that discourages contribution, particularly from beginners, should be eschewed as much as possible.

I have had people ask me, when encountering a copyright statement in source code, whether they have to ask that person's permission before submitting a patch. If we can avoid even one person asking this question, we've done a service to the project.

I also worry that companies that insist on copyright statements in their contributions understand neither copyright law nor Open Source. On the one hand, the audit trail in Git protects your record of contribution, and thus your copyright. On the other hand, if your copyright is that important to you, perhaps you shouldn't be contributing it to an Open Source project. It's anti-community to say to a project that they can have your contribution, but only as long as you get to assert that it's your personal property. Open Source is about community and collaboration. If the building is owned by the community, what do you gain by insisting that a particular brick is yours?

At the Apache Software Foundation, we had this debate a decade ago, and decided that author tags in source code were anti-community, and thus discouraged. To quote from the thread of comments at the time, and, in particular, to quote Sander Striker:

At the Apache Software foundation we discourage the use of author tags in source code. There are various reasons for this, apart from the legal ramifications. Collaborative development is about working on projects as a group and caring for the project as a group. Giving credit is good, and should be done, but in a way that does not allow for false attribution, even by implication. There is no clear line for when to add or remove an author tag. Do you add your name when you change a comment? When you put in a one-line fix? Do you remove other author tags when you refactor the code and it looks 95% different? What do you do about people who go about touching every file, changing just enough to make the virtual author tag quota, so that their name will be everywhere?

There are better ways to give credit, and our preference is to use those. From a technical standpoint author tags are unnecessary; if you wish to find out who wrote a particular piece of code, the version control system can be consulted to figure that out. Author tags also tend to get out of date. Do you really wish to be contacted in private about a piece of code you wrote five years ago and were glad to have forgotten?

This is a slightly different issue (author tags rather than copyright statements) but makes exactly the same point. Do I add a copyright statement when I correct grammar or spelling in a doc? How about when I add a paragraph or reorder sentences for greater clarity? At what point do I remove your copyright statement because I've changed so much of that file?

And then of course, you should consider the bigger question - why do you care? What are you trying to protect against? If you're trying to protect against your contribution being taken by the community and used for other purposes, perhaps contributing to an Apache-licensed code base isn't the smartest thing to do.

Syndicated 2014-01-14 19:26:43 from Notes In The Margin


I posted a few days ago about personal ticket tracking, and received a lot of suggestions. The one that worked for me immediately was Todo.txt, which augments the way I was already doing things - plain text with a little markup - with a set of tools to give me reporting and a command-line interface to add/edit/remove items.

You can read more about it on the todotxt.com website, of course. I'm feeling much more productive today. Maybe it's an illusion, but my 'done' list is growing, and my 'todo' list isn't stressing me out as much, so that's progress.

Check it out.

Syndicated 2014-01-13 21:40:58 from Notes In The Margin

Personal ticket tracker

I ask this every few years, because I've never found a particularly good solution. I'd love to hear what you use.

I need a personal ticket tracker. I'm not talking about a check-it-off style To Do List app, but rather something more approaching a software ticket tracker.

I need to be able to set priority, dependencies, and relationships between tasks (ie, projects comprised of several subtasks). I need to be able to get reports of what I did on a given day or week or month. I need to be able to set deadlines on tasks, and get reminders when a deadline is approaching.

I have never used a full-blown project management tool, and that *might* be what I want, but I suspect that it's not, as I'm doing N projects at any given moment, and I don't want something monolithic for each.

In the past I've used RT, which is a great project by an awesome company, but it's a bit difficult to get set up initially, mostly because it is *so* configurable.

While I was at SourceForge, I used the Allura ticket tracker (ie, the tracker attached to projects) and that's fine if your tasks are public-facing, as mine were there. The facility for private tasks was (at the time) a little weak.

I've also used a lot of different ToDo list apps. TeuxDeux is far and away the best of them, but I have since moved to Android, so, no joy there.

Oh, yeah, access from web and mobile are essentials, so a desktop-only project management tool is out.

At the moment, I'm using a text file, written in markdown, which gets converted to a web page, but this doesn't do a good job of reporting (I move done items to a "done this week" list), or of priorities and dependencies. I have "Now", "Today", "Soon" and "Later" lists, and what ends up happening is that everything is either in the "Now" or "Later" lists, and I just do stuff in order of the list.

I'd love to see what other folks use to track enormous ToDo lists of this type, particularly people who are as scatterbrained as I am.

Syndicated 2014-01-10 18:01:04 from Notes In The Margin

Raspberry Pi Jukebox (XMBC)

tldr; I wanted to use my Raspberry Pi as a jukebox (music only) using XMBC, but it doesn't like to run without a screen.

I recently acquired a second Raspberry Pi. I'm using the first one for a bunch of web automation stuff for work, and I intended to use the new one to encourage my son in the direction of hacking/programming stuff. However, he's mostly interested in Minecraft, which also has a lot of potential when it comes to hacking/programming, but doesn't really lend itself to the low power of the RaspPi. So, for the moment, I have this additional Pi sitting around to play with.

One of the cool things that folks are doing with RaspPi is the XMBC project, which is a home theater server. There's several Raspberry Pi distros of it, and I tried the Raspbmc distro, since it was *really* easy to install.

It boots up directly into the media center UI, much like a Roku does, so there's no mucking about with user accounts, and no learning curve for folks who aren't Linux users. Very slick.

Unfortunately, I primarily wanted to use this as a jukebox, for music, and not for media. As such, I wanted to run it "headless" - ie, without a screen - and be able to control it entirely with the remote, for the purposes of playing music in my office.

I ran into two problems.

One, in order to do what I wanted, I needed to have several USB devices hanging off of the Pi, including a wireless networking dongle and a USB hard drive. Both of these draw quite a lot of power, and so can't be plugged directly into the Pi, but have to be plugged into a powered USB hub. It appears that all of the USB hubs I have don't provide sufficient power. From the reading I did, this seems to be a common problem - that "powered' USB hubs often don't provide as much power as they promise, and so it makes it hard to actual use powered devices on them. The symptom I experienced was that the hard drive kept powering down every few minutes, and I'd get a warning message on the Pi.

Which brings me to my second problem.

When rebooting the Pi, I very consistently got a warning message that I hadn't powered it down properly. This warning message is a popup dialog that requires you to click OK. A second dialog warns you against shutting down the device incorrectly, and also has an OK button. Unfortunately, this means that it's effectively impossible to run the device without a screen, 'cause you can't see to click OK. As stupid as that sounds, this was a game-stopper for me, as I don't want to dedicate a screen to my jukebox in my very limited office space.

FWIW, I eventually purchased a Roku (as I blogged earlier) as a late Christmas present to myself and Maria, and it does the jukebox stuff as well as all of the other shiny things.

But I'd still like to do something with this Pi sitting on my desk. Suggestions welcomed.

Syndicated 2014-01-10 16:30:49 from Notes In The Margin


My "I don't need it but I want it" technology purchase this Christmas was a Roku.

I spent several hours early on the Christmas break trying to build a XBMC raspberry pi media center to act as an office jukebox. This worked ok, but I learned two things. One, it doesn't like to run "headless" (ie, without an active screen) and two, you really need a powered USB hub if you're going to plug in any non-trivial (ie, not a keyboard) USB devices, such as a wifi dongle or a USB hard drive.

Anyways, as fun as that was, I wanted something more polished, and picked up the Roku 3 at Radio Shack. In addition to playing my music collection, it can also do Pandora, Netflix, and a few thousand other things.

So, it's kind of overkill for what I wanted - just an easy way to play my music with a simple remote control - it's a fun toy, and also a great way to watch Netflix in the evening.

It's also interesting to compare this with the Google Chromecast that I picked up at LinuxCon a few months ago. While the Chromecast is a cool device, it's *way* behind Roku in terms of content and apps, and it's going to take a lot of catching up before I'd consider using it in place of the Roku. I'm sure that they'll get more content, but they may have already lost the race.

Syndicated 2014-01-02 15:23:14 from Notes In The Margin

Proliferation of OSes

As of yesterday, we now have the following operating systems in this house:

* Windows 7

* Chrome OS
* OS X
* Fedora 20
* CentOS 6

* Android
* iOS
* Random AT&T phone

* Android
* Android with CyanogenMod

Raspberry Pi
* Pidora
* Raspbian

And, of course, being The Computer Guy, they're mostly my job. Fun, fun.

Syndicated 2013-12-23 19:37:09 from Notes In The Margin

Blog comments

I just upgraded Habari (the blog software) and in the process of purging spam comments, I appear to have also nuked all legitimate comments. I suppose I should be upset, since there were almost 3000 comments on the site, but it feels like a chance to start fresh, and not have to paw through a million spam comments for the occasional diamond.

The one page with really valuable comments is archived at archive.org

Syndicated 2013-12-23 18:28:23 (Updated 2013-12-23 18:30:29) from Notes In The Margin

Red Hat stands behind the code

Cool OpenStack video with footage of Red Hat engineers at the OpenStack summit in Hong Kong last month.