[07:48] <tasdomas> hi
[07:49] <tasdomas> what is the purpose of amulet.raise_status(amulet.PASS) ?
[11:05] <Odd_Bloke> How large a disk does the bootstrap node need?
[11:05] <Odd_Bloke> Would 10GB be sufficient?
[11:31] <marcoceppi> Odd_Bloke: that should be sufficent
[11:31] <Odd_Bloke> marcoceppi: Great, thanks.
[11:31] <marcoceppi> tasdomas: that more or less exits the test and prints a PASS line
[11:32] <tasdomas> marcoceppi, I'm asking because if I did that, the test was marked as failed
[11:32] <marcoceppi> rofl, I don't think that's the intention of that command
[12:25] <Odd_Bloke> marcoceppi: If you have a few minutes: https://code.launchpad.net/~daniel-thewatkins/charm-helpers/lp1370053/+merge/260864
[12:26] <marcoceppi> Odd_Bloke: ack, taking a look
[12:31] <Odd_Bloke> marcoceppi: Thanks muchly!
[12:31] <Odd_Bloke> That should let me sort out issues in the ubuntu-repository-cache merge proposals.
[12:31] <Odd_Bloke> Then you can merge those. ;)
[12:31] <marcoceppi> \o/
[12:36] <tasdomas> marcoceppi, bundletester is a great tool!
[12:37] <marcoceppi> tasdomas: it is very nice, we hope to have it be what `charm test` and `juju test` run in the near future
[12:39] <tasdomas> marcoceppi, that would be nice - charm test fails for me (using local provider)
[12:46] <coreycb> jamespage, hey, can you take a look at my response to your comment here?  A charm-helpers fix is needed for upgrade-charm:  https://code.launchpad.net/~corey.bryant/charms/trusty/quantum-gateway/end-of-life/+merge/265035
[13:12] <beisner> marcoceppi, it appears that amulet.SKIP is unexpectedly invoking --set-e behavior.  end result is a failed test run instead of a single skipped test.  I don't generally use amulet.SKIP or amulet.PASS explicitly, but dosaboy has a percona-cluster amulet test in flight which does, and that's where we are seeing this.
[13:12] <beisner> marcoceppi, according juju test -h this ^ would appear to not be the expected behavior.
[13:14] <beisner> marcoceppi, i've not dug into the code, but could it be that any amulet.raise use takes us down a fail path (given tasdomas is also seeing amulet.PASS raises cause a fail)?
[13:17] <tasdomas> beisner, that's what I saw - I just assumed I was using it wron
[13:17] <tasdomas> g
[13:26] <g3naro> yo!
[13:42] <g3naro> ok,, is there a charm that can build and configre a docker-registry server ?
[13:42] <g3naro> or should i somehow package a puppet class that does setup for this
[14:08] <mbruzek> g3naro: I am not aware of a charm that sets up a docker-registry server.  That is a good candidate for a new charm *nudge* *nudge*
[14:08] <mbruzek> g3naro: charms can be written in puppet or chef, or any thing that runs on Ubuntu
[14:09] <mbruzek> also centos
[14:10] <mbruzek> g3naro: If you want to search for charms use this url: https://jujucharms.com/
[14:11] <mbruzek> It searches charms that are in a personal namespace and ones that are in the recommended section of the charm store.
[14:17] <g3naro> ahh ok great!
[14:37] <marcoceppi> beisner: it shouldn't PASS -> FAIL is determined by the test runner
[14:38] <marcoceppi> PASS exits with code 100, juju test has a flag to determine how to handle SKIP (as OK, or problem)
[14:38] <beisner> marcoceppi, raising a SKIP or PAAS causes juju test to exit non-zero.
[14:38] <marcoceppi> not sure how bundletester handles this
[14:38] <beisner> PASS even
[14:38] <marcoceppi> beisner: well that's not the expected outcome
[14:39] <marcoceppi> and is the first I've heard of this. Do you have an example of the test/cahrm causing this so I can repro?
[14:39] <beisner> dosaboy, ^
[14:39] <marcoceppi> stub: ping
[14:39] <marcoceppi> stub: actually, going to PM
[14:40] <dosaboy> marcoceppi: https://code.launchpad.net/~hopem/charms/trusty/percona-cluster/min-cluster-size/+merge/265502
[14:40] <dosaboy> try running 'make test'
[14:40] <dosaboy> you'll see that most tests skip since they require a vip
[14:40] <dosaboy> yet they all get marked as fail
[14:40] <dosaboy> all the ones that skip that is
[14:45] <beisner> dosaboy, even though this may be unexpected behavior, i would recommend that we allow the test to fail if it's not fed everything it needs (and not even try to SKIP it).
[14:45] <beisner> dosaboy, otherwise a binary pass/fail in ci for a merge proposal may not always mean the same thing.
[14:47] <marcoceppi> dosaboy beisner do you have output? I'm getting skips as expected
[14:47] <marcoceppi> what version of charm-tools are you using?
[14:47] <beisner> marcoceppi, one diff:   use --set-e
[14:47] <beisner> marcoceppi, uosci runner injects that into the makefile so that if something fails, we have an environment to pull logs from
[14:48] <dosaboy> beisner, marcoceppi: i don;'t use --set-e and i still get "failed: 5" which is all those that skip
[14:48] <marcoceppi> bleh, I hate how half baked this tool is, it should really just always get logs
[14:48] <beisner> otherwise if a test fails, the juju environment is torn down before juju test exits, and we don't really have data to inspect.
[14:48] <dosaboy> charm-tools 1.5.1-0ubuntu1~ubuntu14.04.1~ppa1
[14:51] <marcoceppi> this is stupid logic doing stupid things
[14:51] <marcoceppi> I'll open a bug for juju test and get a patch release out
[14:52]  * beisner coffees..
[15:18] <marcoceppi> so, I found the problem with skip
[15:24] <apuimedo> mbruzek: ping
[15:24] <mbruzek> pong
[15:24] <apuimedo> mbruzek: how are you?
[15:25] <mbruzek> I am well.  How are things with you?
[15:26] <apuimedo> mbruzek: not too bad
[15:26] <apuimedo> I did the change you suggested
[15:26] <apuimedo> https://code.launchpad.net/~celebdor/charms/precise/cassandra/hostname_resolve/+merge/257120
[15:26] <mbruzek> great I will review it today
[15:28] <apuimedo> thanks
[15:28] <apuimedo> mbruzek: should I change it to needs review?
[15:28] <mbruzek> yes
[15:29] <mbruzek> thank you for the followup
[15:34] <apuimedo> ;-)
[15:43] <marcoceppi> apuimedo: any reason why you're using the precise version of cassandra and not the new trusty version?
[15:44] <apuimedo> marcoceppi: the trusty version was not there when I satarted with this
[15:44] <apuimedo> I guess I should move to it
[15:44] <apuimedo> and check if it can do what I need to
[15:44] <marcoceppi> apuimedo: it's available now, you should just be able to deploy the trusty version instead
[15:45] <marcoceppi> it's a lot smarter about how to handle clustering and versions of cassandra
[15:45] <apuimedo> I'm very glad to hear that
[15:46] <apuimedo> marcoceppi: I can't see about choosing a specific version
[15:46] <marcoceppi> apuimedo: how specific do you need? this supports more generic options like datastax vs apache and has support for apache cassandra 2.0 and 2.1 atm
[15:47] <apuimedo> I need to install 2.0.1
[15:47] <apuimedo> from datastax
[15:47] <marcoceppi> you mean datastax enterprise or just the cassandra 2.0.1?
[15:48] <apuimedo>         #   - deb http://debian.datastax.com/community stable main
[15:50] <marcoceppi> apuimedo: you can set that in the config.yaml
[15:50] <marcoceppi> install_sources
[15:51] <apuimedo> marcoceppi: yes, but I need an older package from that source
[15:51] <apuimedo> I guess I would have to patch this new cassandra to allow you to specify a specific version
[15:51] <marcoceppi> apuimedo: I see
[15:51] <marcoceppi> apuimedo: well, you can continue to use the precise version, don't get me wrong
[15:52] <marcoceppi> just wanted to make sure you were aware of teh trusty version
[15:52] <apuimedo> I would like to use the trusty
[15:52] <apuimedo> so probably what we can do is
[15:53] <apuimedo> we get this merged for precise
[15:53] <apuimedo> and then for the next release I patch the new cassandra charm to accept version
[15:53] <apuimedo> and move our bundle to use it
[15:53] <marcoceppi> cool
[15:53] <marcoceppi> thanks for the all the work so far!
[15:54] <apuimedo> ;-)
[16:17] <mbruzek> apuimedo: What package_version can I set the cassandra charm to?
[16:18] <apuimedo> I'll give you the config
[16:19] <apuimedo> mbruzek: http://paste.ubuntu.com/11920807/
[16:19] <g3naro> we come in peeeeace
[17:15] <coreycb> jamespage, gnuoy: can one of you review this?  it's needed by neutron-gateway in order to allow upgrading from quantum-gateway to neutron-gateway.  https://code.launchpad.net/~corey.bryant/charm-helpers/upgrade-charm/+merge/265450
[19:19] <pmatulis> are log levels for debug-log and juju-log the same? TRACE, DEBUG, INFO, WARNING, ERROR
[19:51] <marcoceppi> pmatulis: probably
[23:22] <sebas5384> lazyPower: ping