Logging api

Reviewers:  @bernerdschaefer, @peterbourgon 

First pass at the internals of the logging API.  This is two layers thick.  There is a RingBuffer for log messages, and on top of this is a data structure that implements storage for and operations for each container.  (The RingBuffer probably should have been a separate submit.)

The next piece to be worked on will be the HTTP logging interface.
I'm going to disagree.  These shouldn't generically interoperate t with any
random string or unit64.  That's why this feature exists in the language.
 (E.g. don't use RAM where you're supposed to use DiskCapacity, that
example coming directly from google internal communications about using
type aliasing in go.)


On Tue, Jul 29, 2014 at 4:34 PM, Peter Bourgon <notifications@github.com>
wrote:

> In harpoon-agent/logs.go:
>
> >  )
> >
> > -func receiveLogs() {
> > +type logAction int
> > +const (
> > +	_ = iota
> > +	logActionReceive logAction = iota
> > +	logActionLast
> > +	logActionListen
> > +	logActionDropListener
> > +	logActionExit
> > +)
> > +
> > +type ContainerID string;
> > +type ListenerID int32;
>
> Also, because you don't define any behavior on these types, I don't think
> they should be types. Rather, prefer using the underlying data types, e.g.
>
> type containerLog struct {
>     containerID    string
>     nextListenerID uint64
>     // ...}
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/soundcloud/harpoon/pull/13/files#r15526095>.
>