Hi people,
I saw a ping from last Friday:
12:21 jcastro bloodearnest, noodles775: evan is asking (We're at a
sprint) on how we test the ansible bits in a charm?
12:47 bloodearnest jcastro: not easily, other than actually running
it, which is a downside to using ansible currently
12:47
Hello,
As I am subscribed to all bugs in Juju (as some of you may also be),
today I got an email from a CakePHP charm review. On this one, a charmer
had to reject the submission because, when promulgating, the tool runs
`charm proof` to make sure things are not broken, not promulgating if
any
If I may make a suggestion, how about looking into Gerrit as a review system:
http://gerrit-review.googlesource.com/Documentation/
Its the review system of choice for the OpenStack project and allows
interdependent pull requests. You can see it in action here:
https://review.openstack.org/
Mages, shamans, and practitioners of high mana magic.
All critical bugs affecting stable and devel are fixed, but devel has
yet to passed CI. Sorry.There was a bout of cloud failures that I
discounted by replaying the tests. run-unit-tests-precise-amd64 failed
4 times in a row, but the test
Ah, and one more thing: when developing the chaos-injection mechanism
in the mgo/txn package, I also added both a chance parameter for
either killing or slowing down a given breakpoint. It sounds like it
would be useful for juju's mechanism too. If you kill every time, it's
hard to tell whether
Not much to add except to say I really like this work and I think it is
going to really help us make Juju much better when encountering failures. I
also like the idea of providing easy access to triggering failures through
CLI commands.
On Wed, Aug 13, 2014 at 10:29 AM, Gustavo Niemeyer
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 existing state objects and documents. The downside of this approach is
I like the idea of being able to trigger failures stochastically. I'll
integrate this into whatever we settle on for Juju's failure injection.
On 14 August 2014 02:29, Gustavo Niemeyer gustavo.nieme...@canonical.com
wrote:
Ah, and one more thing: when developing the chaos-injection mechanism
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 anything about their log output,
they should just dump it all to stdout and another process should take
care of shuttling the data, logging it, culling it,
Just to back up Dave's arguments - all sys admins I know would be a big -1 on
Juju doing it's own log rolling. It's a recipe for lost log files, missing data
etc. It's a mixing of responsibilities that should be handled separately.
Just on the volume point Dave raised - we do log a lot but that's
10 matches
Mail list logo
