shykes · August 9, 2013 19:02
diff --git a/gistfile1.irclog b/gistfile1.irclog
 10:57 shykes: lastly, we have 2 big limitations for real-world use: logging and reboots
 10:57 klizhentas: shykes: can you elaborate on logging?
 10:57 shykes: klizhentas: several people have asked me how to integrate their docker setup into syslog or another logging system
 10:57 shykes: it's not practical
 10:58 shykes: 1) I can't just get a firehose of every container's logs (let alone of a smart subset of them)
 10:59 tobstarr: shykes: I would like to have at least some syslog forwarded booted in each container
 10:59 backjlack: systemd allows you to do this.
 11:00 shykes: 2) it's hard to get a stream of a container's logs in a way that is both reliable and continuous
 11:00 fkautz: so, is the problem that they can't hook into syslogd or that it's impracticle for us to provide syslogd support?
 11:00 klizhentas: isn't that app specific - so I can tell my container to talk to whatever loggin daemon out there?
 11:00 tobstarr: klizhentas: that is pretty hard with e.g. nginx
 11:00 backjlack: e.g.: set up a process to log in real time and it lets you filter by whatever service you want.
 11:00 shykes: impractical for us to offer provide integration with logging systems
 11:01 keeb: i am a little late to adding commentary as the issues were listed, but
 11:01 shykes: just to calibrate expectations on this topic here
 11:02 keeb: the events add a great way to make reliable containers, and having multiple tags from a single build would be hugely beneficial for a problem i am dealing with today
 11:02 shykes: the goal is to get a subset of problems that are 1) from real-world usage, 2) considered important by the people in the meeting
 11:02 shykes: so that others in the meeting get an opportunity to volunteer to fix them :)
 11:02 fkautz: they technically can run docker attach and point it to a logging system
 11:03 shykes: fkautz: that's not enough, because 'docker attach' needs to run continuously
 11:03 shykes: fkautz: if the logging client disconnects and comes back, it can't get back what it missed
 11:03 shykes: fkautz: the only alternative is to call 'docker logs' which replays everything everytime
 11:04 backjlack: shykes: What about making docker run watchable to get everything in realtime, thus allowing integration with absolutely any desired logging system?
 11:04 shykes: If someone wants to volunteer to fix the logging situation, I will gladly discuss details and design separately
 11:04 shykes: Of coure we can't fix everything every time
 11:04 shykes: But no need to discuss in detail if nobody is available to fix it just yet
 11:04 tobstarr: I would say +1 for fixing logging
	10:57 shykes: lastly, we have 2 big limitations for real-world use: logging and reboots
	10:57 klizhentas: shykes: can you elaborate on logging?
	10:57 shykes: klizhentas: several people have asked me how to integrate their docker setup into syslog or another logging system
	10:57 shykes: it's not practical
	10:58 shykes: 1) I can't just get a firehose of every container's logs (let alone of a smart subset of them)
	10:59 tobstarr: shykes: I would like to have at least some syslog forwarded booted in each container
	10:59 backjlack: systemd allows you to do this.
	11:00 shykes: 2) it's hard to get a stream of a container's logs in a way that is both reliable and continuous
	11:00 fkautz: so, is the problem that they can't hook into syslogd or that it's impracticle for us to provide syslogd support?
	11:00 klizhentas: isn't that app specific - so I can tell my container to talk to whatever loggin daemon out there?
	11:00 tobstarr: klizhentas: that is pretty hard with e.g. nginx
	11:00 backjlack: e.g.: set up a process to log in real time and it lets you filter by whatever service you want.
	11:00 shykes: impractical for us to offer provide integration with logging systems
	11:01 keeb: i am a little late to adding commentary as the issues were listed, but
	11:01 shykes: just to calibrate expectations on this topic here
	11:02 keeb: the events add a great way to make reliable containers, and having multiple tags from a single build would be hugely beneficial for a problem i am dealing with today
	11:02 shykes: the goal is to get a subset of problems that are 1) from real-world usage, 2) considered important by the people in the meeting
	11:02 shykes: so that others in the meeting get an opportunity to volunteer to fix them :)
	11:02 fkautz: they technically can run docker attach and point it to a logging system
	11:03 shykes: fkautz: that's not enough, because 'docker attach' needs to run continuously
	11:03 shykes: fkautz: if the logging client disconnects and comes back, it can't get back what it missed
	11:03 shykes: fkautz: the only alternative is to call 'docker logs' which replays everything everytime
	11:04 backjlack: shykes: What about making docker run watchable to get everything in realtime, thus allowing integration with absolutely any desired logging system?
	11:04 shykes: If someone wants to volunteer to fix the logging situation, I will gladly discuss details and design separately
	11:04 shykes: Of coure we can't fix everything every time
	11:04 shykes: But no need to discuss in detail if nobody is available to fix it just yet
	11:04 tobstarr: I would say +1 for fixing logging