On Tue, Aug 26, 2014 at 3:27 AM, Andrew Wilkins
andrew.wilk...@canonical.com wrote:
It doesn't have to be the tomb itself; it can be an interface which is
implemented by a type wrapping a tomb. My point was that it seems
unnecessary to add channels and signalling when we already have that with
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
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
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.
I was referring to Nate's lumberjack package (PR
My personal vote would be:
a) Use something that can write directly to multiple syslog receivers over
a TLS encrypted connection from inside the jujud binary (e.g. don't use
rsyslog to read the log files and forward them on to the state servers, but
just write directly)
I'd actually like to
On 27/08/14 14:56, John Meinel wrote:
My personal vote would be:
a) Use something that can write directly to multiple syslog receivers over
a TLS encrypted connection from inside the jujud binary (e.g. don't use
rsyslog to read the log files and forward them on to the state servers, but
On Wed, Aug 27, 2014 at 3:04 PM, Ian Booth ian.bo...@canonical.com wrote:
On 27/08/14 14:56, John Meinel wrote:
My personal vote would be:
a) Use something that can write directly to multiple syslog receivers over
a TLS encrypted connection from inside the jujud binary (e.g. don't use
