LGTM for correctness.

Thoughts on naming: etcd.ErrorForCreate(...) reads like the function call is making an "etcd Error". But it is making an API error from and etcd error. If you put your new code in the parent package, and rename the functions, it would read better, to my eye. For example errors.FromEtcdError(r.assignPod(binding.PodID, binding.Host), "CREATE", "binding", "")

Even better (though out of scope for this PR), if errors was renamed to error, then: error.FromEtcdError(...)

I didn't want to put it in the parent package because I don't think etcd is special in this context - only an etcd registry impl ever needs to know about them.

etcd.CreateErrorFrom(err error)? etcd.ErrorOnCreate(err error)?

I'd suggest the naming pattern "InterpretXError". I also think the pattern should be that sub packages (like etcd) register error interpretation handlers with the main errors package. @smarterclayton did convince me that we need separate handlers for each of the REST operations, though.

I guess I don't see enough overlap between registry implementations to justify having a central registry / handler pattern. Etcd errors should never make it out of the Registry interface, much less to storage or clients.

Renamed with InterpretXError, still holding out against making a central registry of this vs just being domain specific helpers.

ok, LGTM after import rename :)

Import renamed