On Fri, Aug 15, 2014 at 7:36 AM, Gabriel Samfira < gsamf...@cloudbasesolutions.com> wrote:
> I think this thread has become a bit lengthy, and we have started to > loose perspective on what we are actually trying to accomplish. > agreed. afaics that's how do we support logging on windows. > Gustavo's idea to save the logs to is awesome and it works across > platforms, allows immense flexibility and would give people a powerful > tool. We should deffinately aspire to get that done sooner rather then > later. However, at this point in time its only an idea, without a clear > blueprint. > agreed. > > What Nate is proposing *already exists*, its tangible, proposed as a PR > and improves the way juju handles logs. > you'll have to be more specific, there's been a shotgun of statements in this thread, touching on logstash, aggregation removal, rsyslog removal, log rotation, deferring to stderr/stdout, 12factor apps, working with ha state servers, etc. > The only thing I see missing, that might ease people's minds is a > --log-file option (that works with --debug) to actually enforce the usage > of a log file. If we omit that option, then juju should just log to > stdout/stderr. So we get to keep what we have, but also solve a huge PITA > on Windows or any other platform that have limitations in this respect, > with a minimal change... > afaics your referencing your branch ( https://github.com/gabriel-samfira/syslog) which will directly send logs to a remote aggregating syslog server on windows nodes. with regard to the default service behavior on windows, where does stdout/stderr go for a service? isn't the expected behavior for a windows service to use the event log facility? ie. to be inline with expected windows behavior and extant juju semantics, shouldn't we have multiple handlers on the log facility, one to rsyslog, and one to event log on windows. > > Please keep in mind that its better to move forward no matter how small > the steps, then to just stand still while we figure out the perfect logging > system. I would much rather have windows support today, then 2 months from > now when someone actually gets around to implement a *new* logging system. > > This should not be a discussion about which logging system is _best_. This > should be a discussion about which logging system is _better_ and available > *now*. Otherwise we risk of getting caught up in details and loose sight of > our actual goal. > > Just my 2 cents. > > Regards, > Gabriel > > Thanks, Kapil > > On 14.08.2014 23:47, Kapil Thangavelu wrote: > > > > > On Thu, Aug 14, 2014 at 2:14 PM, Nate Finch <nate.fi...@canonical.com> > wrote: > >> I didn't bring up 12 factor, it's irrelevant to my argument. >> >> I'm trying to make our product simpler and easier to maintain. That is >> all. If there's another cross-platform solution that we can use, I'd be >> happy to consider it. We have to change the code to support Windows. I'd >> rather the diff be +50 -150 than +75 -0. I don't know how to state it >> any simpler than that. >> >> > the abrogation of responsibility which is what ic you adocating for in > this thread, also makes our product quite a lot less usable imo... Our > product is a distributed system with emergent behavior. Having a debug log > is one of the most useful things you can have to observe the system and > back in py days was one of the most used features and it was just a simple > dump to the db with querying. Its unfortunate that ability to use it > usefully didn't land to core till recently and did so in broken fashion > (still requiring internal tag names for filtering).. or lots more people > would be using it. Gustavo's suggestion of storing the structured log data > in mongo sounds really good to me. Yes, features are work and require code > but that sort of implementation is also cross platform portable. The > current implementation and proposed alternatives I find somewhat ridicolous > in that we basically dump structured data into an unstructured format only > to reparse it every time we look at it (or ingest into logstash) given that > we already have the structured data. Asking people to setup one of those > distributed log aggregation systems systems and configure them is a huge > task, and anyone suggesting punting that to an end user or charm developer > has never setup one up themselves i suspect. ie. an analogy imo > http://xahlee.info/comp/i/fault-tolerance_NoSQL.png As for the operations > follks who do have them.. we can continue sending messages send to local > syslog and let them collect per their preference. > > -k > > > > >> >> On Thu, Aug 14, 2014 at 1:35 PM, Gustavo Niemeyer < >> gustavo.nieme...@canonical.com> wrote: >> >>> On Thu, Aug 14, 2014 at 1:35 PM, Nate Finch <nate.fi...@canonical.com> >>> wrote: >>> > On Thu, Aug 14, 2014 at 12:24 PM, Gustavo Niemeyer >>> > <gustavo.nieme...@canonical.com> wrote: >>> >> >>> >> > Why support two things when you can support just one? >>> >> >>> >> Just to be clear, you really mean "why support two existing and well >>> >> known things when I can implement a third thing", right? >>> > >>> > Yes, that is exactly what I mean. >>> >>> Okay, on that basis and without any better rationale than "12factor >>> says I can do anything" I'd be tempted to request further analysis on >>> the problem if the decision was on my hands. There are more >>> interesting problems to solve than redoing what already exists. >>> >>> >>> gustavo @ http://niemeyer.net >>> >> >> >> -- >> 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 > >
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
