On 14 August 2014 07:31, Menno Smits menno.sm...@canonical.com wrote:
I like the idea being able to trigger failures using the juju command line.
I'm undecided about how the need to fail should be stored. An obvious
location would be in a new collection managed by state, or even as a field
on
Please forgive the lengthy response :). The following are just a few
thoughts regarding this subject.
On 14.08.2014 06:13, David Cheney wrote:
Ian asked me to post my thoughts here.
I am not in favour of applications rolling their own logs, I believe
that applications should not know
What's the status on this? I think this could really help our workflow.
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
Many operations teams already have a standard log collecting systems. I
think it would be best to be flexible enough to work in environments with
existing systems.
Standard ways are logging to syslog so any syslog implementation can be
used, or logging to stdout so a supervisor like djb
Godeps should pull down new revisions, as of a month or so ago. You just
need to do go get -u launchpad.net/godeps and you'll get the new revision.
I don't believe it go-gets packages you don't already have, though.
On Thu, Aug 14, 2014 at 11:27 AM, Dimiter Naydenov
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
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
On Thu, Aug 14, 2014 at 3:14 PM, Nate Finch nate.fi...@canonical.com wrote:
I didn't bring up 12 factor, it's irrelevant to my argument.
Is there someone else sending messages under your name?
On Thu, Aug 14, 2014 at 12:23 PM, Nate Finch nate.fi...@canonical.com wrote:
The front page of
Will CI failures using mongodb-2.6 be considered critical and block the build ?
On Fri, Aug 15, 2014 at 10:07 AM, Ian Booth ian.bo...@canonical.com wrote:
A little while back we started work as a background task to port Juju to work
with Mongo 2.6. After a final push from Andrew to get
No, not yet. The landing tests are still run using 2.4.
The job to test with mongo 2.6 is/will initially be separate.
On 15/08/14 11:11, David Cheney wrote:
Will CI failures using mongodb-2.6 be considered critical and block the build
?
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
There is no mongo 2.6 build; it's all the one code base.
juju-core works out-of-the-box on both mongo 2.4 and 2.6.
The landing tests are run on top of mongo 2.4 as usual. If any of the tests
fail, then the bot will be blocked.
Perhaps I don't understand the question?
On 15/08/14 13:47, David
On Fri, Aug 15, 2014 at 11:58 AM, Ian Booth ian.bo...@canonical.com wrote:
There is no mongo 2.6 build; it's all the one code base.
juju-core works out-of-the-box on both mongo 2.4 and 2.6.
The landing tests are run on top of mongo 2.4 as usual. If any of the tests
fail, then the bot will be
(if someone tests and finds a bug)...
On Fri, Aug 15, 2014 at 12:17 PM, Andrew Wilkins
andrew.wilk...@canonical.com wrote:
On Fri, Aug 15, 2014 at 11:58 AM, Ian Booth ian.bo...@canonical.com
wrote:
There is no mongo 2.6 build; it's all the one code base.
juju-core works out-of-the-box on
On 15/08/14 14:17, Andrew Wilkins wrote:
On Fri, Aug 15, 2014 at 11:58 AM, Ian Booth ian.bo...@canonical.com wrote:
There is no mongo 2.6 build; it's all the one code base.
juju-core works out-of-the-box on both mongo 2.4 and 2.6.
The landing tests are run on top of mongo 2.4 as usual. If
14 matches
Mail list logo
