3 ms·

> So, looking at the architecture, it seems like you have some design components that overlap with pieces design components in CoreOS. I'm not clear as to what

by gabrtv 12y ago

> So, looking at the architecture, it seems like you have some design components that overlap with pieces design components in CoreOS. I'm not clear as to what components are really application components vs. platform operations components, so maybe that's it. Deis was architected before the CoreOS integration. While we love CoreOS, architecturally we need to remain scheduler agnostic. Probably a good opportunity for a blog post... > the use of rsyslog in lieu of systemd seems like really going against the CoreOS grain We view platform logging as separate from application-level logging. Aggregating logs through the systemd journal is possible, but it would tie us a little too closely to systemd. Using log sidekick containers (as we do) is more portable and easier to funnel to end developers.

cbsmith 12y ago
> Deis was architected before the CoreOS integration. Okay this makes sense. If I were in your shoes, I might be tempted to radically reexamine the architecture in light of CoreOS's design. Otherwise you end up duplicating work or working at cross purposes, and CoreOS's components (systemd, etcd, fleet, etc.) are pretty cleanly separable from both CoreOS and each other already, so you shouldn't end up being married to CoreOS should there be some kind of problem. Given that you're maintaining a level of agnosticism, what do you see as the main thing you are gaining by integrating CoreOS? > We view platform logging as separate from application-level logging. One can certainly take that view, but I'd argue it does lead to more complexity for managing logging. > Aggregating logs through the systemd journal is possible, but it would tie us a little too closely to systemd. Using log sidekick containers (as we do) is more portable and easier to funnel to end developers. Fair enough, but if you really want to be agnostic, I'd say have the contract that in the end everything goes in to a syslogd of some kind, but have the default approach to getting that job done be via systemd (with /run/systemd/journal/syslog to get it the rest of the way). If someone wants to use rsyslog or something else to do the job, so be it. While using the log sidekick approach is popular, it's actually quite inefficient and clumsy. Particularly on magnetic disk, you've got this nice, efficient, append only per-event log writing that doesn't even have to be cached and then you periodically scrape through the old stuff as if it were just a blob of bytes. The big win though is that you no longer need a sidekick for managing logging from each container. No muss no fuss about where the logs are, etc. Instead you just direct logging to systemd (or if need be, the syslogd socket). No sidekick required!
cbsmith 12y ago
Just so we're clear, I'm voting you up despite my critique of your answer; I really appreciate you providing insight to your design process.

by gabrtv 12y ago

cbsmith 12y ago

> Deis was architected before the CoreOS integration. Okay this makes sense. If I were in your shoes, I might be tempted to radically reexamine the architecture in light of CoreOS's design. Otherwise you end up duplicating work or working at cross purposes, and CoreOS's components (systemd, etcd, fleet, etc.) are pretty cleanly separable from both CoreOS and each other already, so you shouldn't end up being married to CoreOS should there be some kind of problem. Given that you're maintaining a level of agnosticism, what do you see as the main thing you are gaining by integrating CoreOS? > We view platform logging as separate from application-level logging. One can certainly take that view, but I'd argue it does lead to more complexity for managing logging. > Aggregating logs through the systemd journal is possible, but it would tie us a little too closely to systemd. Using log sidekick containers (as we do) is more portable and easier to funnel to end developers. Fair enough, but if you really want to be agnostic, I'd say have the contract that in the end everything goes in to a syslogd of some kind, but have the default approach to getting that job done be via systemd (with /run/systemd/journal/syslog to get it the rest of the way). If someone wants to use rsyslog or something else to do the job, so be it. While using the log sidekick approach is popular, it's actually quite inefficient and clumsy. Particularly on magnetic disk, you've got this nice, efficient, append only per-event log writing that doesn't even have to be cached and then you periodically scrape through the old stuff as if it were just a blob of bytes. The big win though is that you no longer need a sidekick for managing logging from each container. No muss no fuss about where the logs are, etc. Instead you just direct logging to systemd (or if need be, the syslogd socket). No sidekick required!

cbsmith 12y ago

Just so we're clear, I'm voting you up despite my critique of your answer; I really appreciate you providing insight to your design process.