Hi David, (some comments in-line)
As a user that wants to deploy a charm on a Windows machine, I want to be able to have a local log file on that machine for the machine agent and for the units deployed to it. I also want to be able to aggregate all those logs the same way Ubuntu workloads do (at the moment, to the syslog on the state machine(s) ). Right now, the debug-log that juju generates works the same way on both platforms. However, windows services cannot redirect stdout to a file the same way we do it using upstart. So when starting juju as a service, that log does not get written. So I guess the issues right now are: * how can we have a local logfile on both Ubuntu as well as Windows? (lumberjack is one option that works on both platforms) * how can we aggregate logs from both platforms? (using a go package to write directly to syslog is one option that works cross platform) On 27.08.2014 04:32, David Cheney wrote: > Hi Horatio, > > I don't see a way to resolve the very disparate set of opinions you've > highlighted below. It's also not clear from your email who is > responsible for making a decision. > > I suggest reframing the discussion as user stories. ie > > * As a Juju user with a Windows workstation I want to use juju > debug-log (this should work today) > * As a Juju user who has deployed a mixed environment (to the best of > my knowledge there is no requirement for the state servers to run on > Windows, this seems contrary to Canonical's goal of Free Software) The goal is to eventually have a 1-to-1 feature set on both platforms. This includes a working state machine on windows as well (to be honest, it probably works already, just need to use WinRM instead of ssh to bootstrap it), containers using Hyper-V, and anything else that is supported by Ubuntu and feasible in Windows. Thanks, Gabriel > containing a windows workload charm I want to view the logs from that > charm. > > Dave > > On Wed, Aug 27, 2014 at 5:35 AM, Horacio Duran > <horacio.du...@canonical.com> wrote: >> Hey, In an effort to move forward with juju's windows integration I have >> summarized what seems to be the core points of this discussion to the best >> of my ability (please excuse me if I missed or misunderstood something). >> The two core points of discussion on this thread are: >> * should we remove all-machines.log: which has been voted against, at least >> for the moment, since it is used for debug-log. >> * how do we support logging in windows: The strongest suggestions here are a >> syslog package by gabriel and logging into MongoDB by Gustavo. >> >> We do require some decision on the front of windows logging to have a >> complete windows support. Ideally we need senior citizens of juju dev >> community to weight into this in order to get a clear path to follow. >> >> Here is a summary I made to help myself while following this discussion: >> >> Nate original suggestion: >> * Remove all-machines.log: Claiming it takes a lot of space and it is not a >> multi platform solution >> >> Tim, John, Aaaron, etc: >> * all-machines.log is required for debug-log >> * makes it big and it would be nice to rotate it. >> >> Nate, gabriel: >> * keep all-machines.log >> * use a go-only solution (syslog package with ports from gabriel for >> windows) >> John >> * agrees. >> >> Nate, gabriel: >> * remove rsyslog from al OSes in favor of one solution that fits all OSes >> * Replace with go only solution. >> >> Dave: >> * Dont mind about the logs, make it just output and let external tools >> handle logging and rotation. >> * all-machines.log might be a bit bloated and it could contain less data >> that is more useful. >> (Here is the reference to 12factor that will later be attibuted to nate) >> Ian: >> * Agrees with dave, yet we should provide a rolling mechanism. >> >> Gabriel: >> * Windows does not support capturing stdout as a logging mechanism, it >> requires to explicitly log into the event log. >> * Thinks that using rsyslog to stream logs from agents to state server is >> too much overhead on external tools. >> * Proposes replacing external rsyslog with in app solution for the case of >> streaming logs. >> * Alternative solution, he does not recommend it, to create (and bundle with >> jujud.exe) a wrapper for windows only. >> >> Gustavo: >> * Present a possible alternative by using a MongoDB "capped collection" >> which will suit our use cases but does not recommend it because of the idea >> needs maturing on some details. >> >> Matt: >> * We should provide the option to log to stdout or syslog. >> >> Kapil: >> * Supports Gustavo's idea of logging in a structured form into Mongo as it >> makes sense to dump structured data with structure instead of serializing it >> to be de-serialized later. >> * We can send also messages to syslog and let OPS people collec them >> themselves. >> >> Gabriel (summarizing) >> * I will be looking into event log for local windows logging. This will >> probably require writing a package. >> * the syslog change will solve in the sort term, the aggregation issue from >> Windows nodes (when something better comes along, I will personally send a >> case of beer or ice-cream...or both, to whomever removes syslog as a >> dependency) >> * lumberjack works *now* for local logging on both Windows and Ubuntu. It >> simply removes 2 dependencies (for logging) with just a few lines of code... >> >> -- >> Horacio >> >> >> -- >> Juju-dev mailing list >> Juju-dev@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju-dev >> -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
