On 26 August 2014 00:41, Tudor Rogoz ro...@adobe.com wrote:
Hi Marco,
What I really need is the relation status, not necessarily a synchronous
execution for “add relation”.When I link 2 charms through a relation, I want
to have the possibility (by running the status command or a different
Last week:
*WAL-E*: I reviewed Stuart Bishop's WAL-E merge proposal which adds
experimental support via the wal-e utility for shipping logs to a variety
of blobs stores (Swift, s3, and azure's WABs). In general, the addition
looks good, a fine addition to a fine charm. I requested some
As a follow up to this email:
[0] was triaged - the ElasticSearch bundle is now available here:
https://code.launchpad.net/~charmers/charms/bundles/elasticsearch/bundle
[2] was pushed a while ago and is a byproduct of bug triage not happening.
I've closed out the bug and verified the wildfly
I did a follow-up review for the pgbouncer merge proposal since Stuart
addressed my comments from last week, and gave it my +1. [1]
I also took a look at a merge proposal for the NTP charm which also
got my +1. [2]
Finally, I attempted to review Jason's improved Diaspora charm branch,
but ran
About immutable configuration parameters. IMHO it'd make a better user
experience if juju added support for them.
It's understandable that the desire is for juju to be a full 'life-cycle'
management interface for the services it deploys, from deployment to operations
and all the way to
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
12 matches
Mail list logo
