[00:12] <cherylj> menn0: I can take a look later (after I put the kid to bed)
[00:13] <cherylj> tych0 - running lxd init; systemctl restart lxd.service worked to get the lxd provider to bootstrap
[00:13] <menn0> cherylj: thank you (no rush)
[00:14] <cherylj> tych0: will juju need to do that when provisioning lxd containers (using deploy --to lxd)?
[00:46] <redir> cherylj: is there a kanban board with the helpdocs updates on it?
[00:47] <anastasiamac> redir: i think bug squad is still it..
[00:47] <anastasiamac> redir: i'll pm u :D
[01:03] <cherylj> redir: I haven't been keeping up to date on all the helpdocs bugs and their comments
[01:03] <cherylj> redir: might be a good idea to change the titles of them once they've been acked and are ready to merge....  makes it easy to quickly search for them in lp
[01:04] <redir> cherylj: anastasiamac got me to the board. So I can move cards appropriately.
[01:04] <cherylj> redir: they're not all there, btw
[01:04] <cherylj> feel free to add if you'd like
[01:05] <redir> cherylj: will do when I get to one in lp that isn't on the board.
[01:06] <cherylj> redir: if you're interested, bug 1566237 is an easy non-help docs bug
[01:06] <mup> Bug #1566237: juju ssh doesn't work with multiple models <juju-core:Triaged> <https://launchpad.net/bugs/1566237>
[01:09] <redir> cherylj: k
[01:21] <mup> Bug #1567161 opened: juju2 beta3, cannot download charm, failed to download, 400 <landscape> <juju-core:New> <https://launchpad.net/bugs/1567161>
[01:33] <mup> Bug #1566843 changed: juju add-credential should set default when there is only one credential (when using interactive mode) <docteam> <juju-release-support> <usability> <juju-core:Invalid by axwalk> <https://launchpad.net/bugs/1566843>
[01:33] <mup> Bug #1567169 opened: juju deploy bundle does not honor existing machine definitions <conjure> <juju-core:New> <https://launchpad.net/bugs/1567169>
[01:57] <redir> so if I want to run one test a la `go test . -name TestThatIWantToRun` do I need to do something special for gocheck to honor that?
[01:57] <anastasiamac> axw: I wonder if TerminateInstances call should be re-written to use retry too instead of shortAttempt...
[01:59] <axw> anastasiamac: probably
[01:59] <anastasiamac> redir: go test -gocheck.v -gocheck.f TestYouWant
[02:00] <anastasiamac> redir: which I think is a regular expression, so u can have both 'myTestSuite' or 'individualTestName' or whatever matching...
[02:00] <redir> thank you
[02:00] <redir> if it is a pass through then it should be a regexp
[02:02] <redir> and thank you
[02:02] <anastasiamac> u r welcome \o/
[02:03] <mup> Bug #1567170 opened: Disallow upgrading with --upload-tools for hosted models <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1567170>
[02:15] <mup> Bug #1567175 opened: Service start is not reliable with any network initialization issues <juju-core:New> <https://launchpad.net/bugs/1567175>
[02:22] <redir_eod> see you all tomorrow sometime
[02:23] <thumper> o/ redir_eod
[02:36] <mup> Bug #1567179 opened: ec2 terminate instances should retry with exponential delay on err <juju-core:New> <https://launchpad.net/bugs/1567179>
[02:36] <mup> Bug #1567182 opened: Fallback to installing mongo 2.4 if no 3.2 doesn't work <mongodb> <juju-core:Triaged by hduran-8> <https://launchpad.net/bugs/1567182>
[02:39] <davecheney> menn0: while i'm waiting for other thigns
[02:39] <davecheney> i started a set of PR's about testing that we talked about
[02:39] <davecheney> https://github.com/juju/juju/pull/5023
[02:40] <menn0> davecheney: taking a look
[02:43] <menn0> davecheney: very nice. land it!
[02:45] <cherylj> menn0: that lxd failure has been hit on other branches, so it's not unique to model migrations
[02:46] <menn0> cherylj: ok good
[03:00] <davecheney> menn0: thanks
[03:00] <davecheney> lots more where that came from
[03:04] <cherylj> oh god
[03:04] <cherylj> I hacked distro-info to return xenial as the lts
[03:04] <cherylj> to see what fails in unit tests
[03:04] <cherylj> so many failures
[03:05] <natefinch> was gonna say, maybe you should catalog what passes.  Might be faster.
[03:05] <cherylj> lol
[03:06] <mup> Bug #1567169 changed: juju deploy bundle does not honor existing machine definitions <conjure> <juju-core:Invalid> <https://launchpad.net/bugs/1567169>
[03:08]  * cherylj cries
[03:08] <cherylj> we're going to be screwed in 2 weeks
[03:08] <cherylj> better to know now?
[03:08] <rick_h_> cherylj: more time for wine between now and then?
[03:09] <cherylj> rick_h_: I wish.  We gotta fix these or else we will not be able to release anything once xenial is our official lts
[03:10] <rick_h_> cherylj: understand, it's 11pm have to go light hearted
[03:10] <natefinch> cherylj: really really smart to check that.... sorry the results weren't more in our favor.
[03:12] <mup> Bug #1567169 opened: juju deploy bundle does not honor existing machine definitions <conjure> <juju-core:Invalid> <https://launchpad.net/bugs/1567169>
[03:13] <cherylj> 92 test failures so far
[03:13] <cherylj> well, to be fair, there are some lxd failures because I don't have lxd on my laptop
[03:13] <cherylj> so maybe 80
[03:14] <natefinch> man, I really hate that our code cares what series exist and relies on that data never to change and never to be out of date.
[03:15] <cherylj> 2 years is forever, man
[03:15] <cherylj> trusty 4 lyfe
[03:15] <natefinch> cherylj: 2 years my butt. This happens every 6 months when a new series comes out and also as a bonus, whenever we get a new windows or OSX release... I suppose probably centos as well.
[03:16] <mup> Bug #1567169 changed: juju deploy bundle does not honor existing machine definitions <conjure> <juju-core:Invalid> <https://launchpad.net/bugs/1567169>
[03:16] <cherylj> haha
[03:17] <cherylj> and what unit test run would be complete without a test timeout!!
[03:19] <cherylj> I wonder how many would pass if we set testing.FakeDefaultSeries = xenial
[03:19] <cherylj> or, what we should do is testing.FakeDefaultSeries = actualDefaultSeries
[03:19] <cherylj> and people can patch
[03:19] <cherylj> if they need to
[03:20] <cherylj> anyway that's a problem for tomorrow Cheryl
[03:20] <rick_h_> night cherylj
[03:20] <natefinch> poor tomorrow Cheryl
[03:20] <cherylj> yeah, yesterday Cheryl is terrible
[03:20] <cherylj> :)
[03:20] <natefinch> lol... yeah, I hate yesterday Nate. That guy's an idiot.
[03:44] <davecheney> func (s *BaseRepoSuite) SetUpSuite(c *gc.C)    {}
[03:44] <davecheney> func (s *BaseRepoSuite) TearDownSuite(c *gc.C) {}
[03:44] <davecheney> great
[03:44] <davecheney> that's just great
[03:46] <anastasiamac> davecheney: we should have this on the t-shirt "juju, just great"
[03:51] <menn0> thumper: easy review pls http://reviews.vapour.ws/r/4466/
[04:03] <menn0> davecheney: http://reviews.vapour.ws/r/4466/ pls
[04:07] <davecheney> lookin'
[04:07] <davecheney> LGTM, mostly harmless
[04:12] <menn0> davecheney: ta
[04:13] <davecheney> menn0: https://github.com/juju/juju/pull/5025
[04:13] <davecheney> more of the same
[04:16] <natefinch> ahhh... damn macaroons
[05:25] <mup> Bug #1567228 opened: "juju destroy-controller" can leak hosted models <juju-core:Triaged> <https://launchpad.net/bugs/1567228>
[07:09] <frobware> dimitern, if you need an immediate fix for the broken /e/n/i try this http://pastebin.ubuntu.com/15653945/
[07:10] <dimitern> frobware, cheers, I'll try this on the next test I'm doing shortly
[07:11] <frobware> dimitern, it's obviously not the complete story... but is in essence the fix
[07:12] <frobware> dimitern, any joy with the case where the first add-machine lxd:0 fails?
[07:40] <dimitern> frobware, sorry, I had to step afk
[07:41] <dimitern> frobware, well, add-machine lxd:0 only works (post-bootstrap), if you first juju switch admin, is that what you mean?
[07:41] <dimitern> frobware, otherwise it says no such machine 0
[07:41] <dimitern> but apart from that, yes - it still fails, still digging..
[07:42] <frobware> dimitern, nope. if you switch to :admin and add-machine lxd:0 the first one fails to work until the agent is restarted on the node hosting the container.
[07:44] <frobware> dimitern, I think we're saying the same things (give or take the model switch)
[07:44] <dimitern> frobware, yeah
[07:44] <dimitern> frobware, :) I was about to write the same thing
[08:58] <thumper> frobware, dimitern: why is there no standup listed for today?
[08:59] <thumper> voidspace, babbageclunk: care to hangout to discuss maas2?
[09:00] <thumper> I was awaiting a standup that doesn't appear to be scheduled
[09:03] <voidspace> thumper: team meeting today at 11am instead
[09:03] <voidspace> thumper: but sure
[09:03] <thumper> I'm not going to hang around for that
[09:03] <voidspace> thumper: that's our loss
[09:04] <thumper> ow, ow, ow.... cramp
[09:04]  * thumper stretches
[09:04] <voidspace> dimitern: we could use you to talk to babbageclunk and thumper about the link layer model and what information we need from maas
[09:04]  * thumper is in the sapphire normal standup hangout
[09:04] <voidspace> dimitern: currently the maas 1 code uses stuff like link.Parent() and IPAddresses that don't seem to exist in MAAS 2
[09:05] <thumper> well it does
[09:05] <voidspace> thumper: omw
[09:05] <thumper> ..
[09:05] <thumper> hmm
[09:09] <dimitern> oops sorry guys, omw
[09:10] <dimitern> voidspace, babbageclunk, thumper, standup HO?
[09:10] <voidspace> dimitern: we're there
[09:10] <voidspace> dimitern: hello
[09:21] <dimitern> babbageclunk, dooferlad, frobware, join us guys for standup?
[09:21] <dooferlad> dimitern: sure. URL?
[09:21] <babbageclunk> Coming now
[09:34] <mup> Bug #1567296 opened: Plugin API fails with multiple juju binaries <juju-core:New> <https://launchpad.net/bugs/1567296>
[10:02] <rogpeppe> anyone know what the best way to shut down a juju lxd provider controller is when juju won't let me (probably because i started it with an old juju version) ?
[10:12] <davecheney> whoopse, that was rather aburpt
[10:12] <davecheney> sorry about that
[10:17] <mgz> rogpeppe: the best way has been build that old env and kill-controller with that
[10:17] <rogpeppe> mgz: unfortunately i've no idea what version i used to bootstrap the old env
[10:17] <rogpeppe> mgz: i think i need to go behind the scenes
[10:18] <rogpeppe> mgz: but my naive approach ("lxd shutdown") doesn't seem to have got me to a good place
[10:19] <rogpeppe> mgz: i just removed $HOME/.local/share/juju and now i'm getting "ERROR invalid config: no addresses match"
[10:19] <rogpeppe> mgz: when i try "juju bootstrap local lxd"
[10:19] <rogpeppe> mgz: :-(
[10:19] <rogpeppe> mgz: AFAIK i haven't *got* a config
[10:22] <mgz> rogpeppe: yeah, it's a joy
[10:23] <rogpeppe> mgz: i've just proposed https://github.com/juju/cmd/pull/35 to make it easier to debug that kind of error message
[10:26] <rogpeppe> mgz: that makes the error somewhat more informative... 2016-04-07 10:25:39 DEBUG cmd supercommand.go:449 error details: [{github.com/juju/juju/cmd/juju/commands/bootstrap.go:406: } {github.com/juju/juju/environs/open.go:104: } {github.com/juju/juju/environs/open.go:175: } {github.com/juju/juju/provider/lxd/provider.go:44: } {github.com/juju/juju/provider/lxd/environ.go:43: invalid config} {github.com/juju/juju/provider/lxd/config.go:
[10:26] <rogpeppe> 182: } {github.com/juju/juju/provider/lxd/config.go:255: } {github.com/juju/juju/tools/lxdclient/config.go:65: } {github.com/juju/juju/tools/lxdclient/remote.go:199: } {no addresses match}]
[10:31] <mgz> didn't that used to have prettier formatting?
[10:36] <voidspace> frobware: dimitern: babbageclunk: doing a merge of master onto maas2
[10:36] <voidspace> frobware: dimitern: babbageclunk: some fixing to do as anastasiamac fixed a maas bug that changes the maasInstance interface
[10:37] <babbageclunk> voidspace: nothing too nasty I hope?
[10:37] <rogpeppe> mgz: possible. i don't care much :)
[10:38] <voidspace> babbageclunk: maasInstance.zone() now returns an error - so the interface definition and our maas2Instance implementation need updating
[10:38] <rogpeppe> mgz: FWIW the error is because juju's looking for netif lxdbr0 but my machine only has lxcbr0
[10:38] <voidspace> babbageclunk: plus there are a bunch of new tests that do a type cast to maasInstance that should now be maas1Instance
[10:38] <voidspace> babbageclunk: plus another bugfix by davecheney in maas storage
[10:38] <voidspace> babbageclunk: nothing too nasty, no - easy enough
[10:52] <perrito666> morning
[10:55] <rogpeppe> mgz: ha, i upgraded lxd and now there *is* an lxdbr0 interface but it doesn't have any ipv4 addresses so i get the same failure
[10:56] <rogpeppe> anyone used the lxd provider with the latest juju, by any chance?
[10:56] <TheMue> morning perrito666
[10:56] <rogpeppe> voidspace: do you know anything about this issue, by any chance?
[11:04] <rick_h_> rogpeppe: there's an email thread.on the juju list around this i think
[11:04] <rick_h_> rogpeppe: from yesterday
[11:04] <rogpeppe> rick_h_: yeah, just looking for it
[11:05] <rogpeppe> rick_h_: found
[11:07] <rogpeppe> rick_h_: i don't think it helps me though
[11:08] <rogpeppe> rick_h_: there's no "lxd-bridge" service on my machine AFAICS.
[11:08] <voidspace> rogpeppe: no, afraid not
[11:09] <voidspace> rogpeppe: I just saw an upgrade do the same thing (well - change the bridge name) on my server too though
[11:09] <voidspace> rogpeppe: jam might know if he's still around
[11:09] <rogpeppe> voidspace: yeah, it seems to break everything
[11:09] <voidspace> :-(
[11:09] <voidspace> or maybe frobware I know he's done a lot of work with lxd
[11:09] <rogpeppe> voidspace: i guess i need to create an ipv4 address on the bridge somehow
[11:09] <voidspace> rogpeppe: it should *get* an ipv4 address
[11:10] <voidspace> so it's odd
[11:10] <rogpeppe> voidspace: it really seems that it shouldn't *need* an ipv4 address anyway
[11:10] <rogpeppe> voidspace: aren't we supposed to work with ipv6?
[11:10] <voidspace> maybe look in /etc/network/interfaces and see how the bridge is defined
[11:10] <rogpeppe> voidspace: good idea
[11:10] <voidspace> rogpeppe: I'm not convinced I think we've *tried* to be compatible but not been thorough
[11:10] <rogpeppe> voidspace: FWIW ifconfig shows this: http://paste.ubuntu.com/15667206/
[11:10] <voidspace> rogpeppe: and ifdown/ifup iit
[11:11] <rogpeppe> voidspace: well, utils.GetAddressForInterface discards all ipv6 addresses...
[11:11] <voidspace> rogpeppe: no packets dropped and some traffic
[11:12] <voidspace> rogpeppe: we have a preferIPv6 setting somewhere - does that code not honour it
[11:12] <rogpeppe> voidspace: almost nothing in /etc/network/interfaces
[11:12] <rogpeppe> voidspace: just two lines:
[11:12] <rogpeppe> auto lo
[11:12] <rogpeppe> iface lo inet loopback
[11:12] <rogpeppe> voidspace: nothing in interfaces.d either
[11:12] <voidspace> oh, odd
[11:12] <voidspace> I wonder where it is - this is xenial?
[11:13] <rogpeppe> voidspace: nope, trusty
[11:13] <voidspace> ah
[11:13] <voidspace> I've not worked with trusty networking - I can commission a trusty box though
[11:13]  * rogpeppe has been meaning to find the time to reinstall from scratch for *ages*
[11:14] <dimitern> rogpeppe, for trusty you need to add "trusty-backports" to /e/apt/sources.list && sudo apt-get update && sudo apt-get install -t trusty-backports lxd
[11:15] <rogpeppe> dimitern: like: add-apt-repository trusty-backports ?
[11:15] <dimitern> rogpeppe, voidspace, prefer-ipv6 is no longer respected (always false), but the setting itself is not gone yet (will be soon though)
[11:15] <rogpeppe> dimitern: hiya BTW :)
[11:15] <dimitern> rogpeppe, it's not a repo, it's a cloud pocket or something like that
[11:15] <dimitern> rogpeppe, ;) hey
[11:15] <rogpeppe> dimitern: what exact line(s) do i need to add for /etc/apt/sources.list ?
[11:16] <dimitern> rogpeppe, if you paste yours, I can show you - can remember off-hand
[11:16] <rogpeppe> dimitern: paste what?
[11:16] <dimitern> rogpeppe, /etc/apt/sources.list from the trusty machine in question
[11:16] <rogpeppe> dimitern: the current contents of my sources.list
[11:17] <rogpeppe> dimitern: https://pastebin.canonical.com/153655/
[11:18] <dimitern> rogpeppe, actually - here's a wiki page: https://help.ubuntu.com/community/UbuntuBackports
[11:18] <dimitern> rogpeppe, so you need a line like this somewhere: deb http://archive.ubuntu.com/ubuntu trusty-backports main restricted universe multiverse
[11:19] <dimitern> rogpeppe, but looking at your paste you seem to have it enabled already
[11:22] <rogpeppe> dimitern: yeah
[11:23] <dimitern> rogpeppe, so just apt-get update && apt-get install lxd/trusty-backports should work now
[11:24] <rogpeppe> dimitern: still same problem after doing that
[11:24] <dimitern> rogpeppe, the container still did not start?
[11:25] <rogpeppe> dimitern: juju refuses to do anything because the interface has no ipv4 addresses
[11:25] <dimitern> rogpeppe, lxdbr0 ?
[11:25] <rogpeppe> dimitern: yeah
[11:28] <dimitern> rogpeppe, hmm I'm not that familiar with lxdbr0 specifics, but you should be able to use "lxc-bridge: lxcbr0" in your bootstrap config
[11:28] <dimitern> rogpeppe, provided lxc1 package is also installed and lxcbr0 exists
[11:28] <voidspace> dimitern: frobware: babbageclunk: dooferlad: merge master onto maas2 http://reviews.vapour.ws/r/4473/
[11:28] <rogpeppe> dimitern: i'd prefer to be able to bootstrap without using that tbh
[11:29] <rogpeppe> dimitern: but i'll try it
[11:30] <dimitern> rogpeppe, well, on trusty lxd is still kinda flaky; btw you might instead need to change /etc/default/lxd to enable IPv4 addresses
[11:30] <dimitern> rogpeppe, check this, it might help - https://github.com/lxc/lxd/pull/971/files
[11:30] <rogpeppe> dimitern: unknown config field "lxc-bridge"
[11:42] <dimitern> rogpeppe, ah, sorry - that's no longer supported yeah :/ - I guess the second option then - changing /e/d/lxd (or lxd-bridge) there to provide IPv4 addresses
[11:42] <voidspace> dimitern: frobware: dooferlad: babbageclunk: branch adding a feature flag for the MAAS 2 work http://reviews.vapour.ws/r/4474/
[11:42] <rogpeppe> dimitern: /etc/default/lxd doesn't exist for me
[11:43] <rogpeppe> dimitern: ah, but lxd-bridge does
[11:43] <dimitern> rogpeppe, right - there
[11:43] <dimitern> voidspace, looking
[11:46] <rogpeppe> dimitern: hmm, i added a bunch of ipv4 stuff in lxd-bridge, restarted lxd (sudo initctl restart lxd), but no ipv4 addresses seem to be arriving
[11:46] <rogpeppe> dimitern: FWIW my lxd-bridge file now looks like this: http://paste.ubuntu.com/15667827/
[11:48] <dimitern> rogpeppe, try adding a new container
[11:48] <rogpeppe> dimitern: is that easy? i've not used lxd directly before.
[11:48] <anastasiamac> voidspace: in fact, if possible, it'd be awesome if any property accessors from maas instance also returned errors... it was very sad that we were swallowing that one :/
[11:49] <rogpeppe> dimitern: is the lxd command the way to do it?
[11:49] <rogpeppe> dimitern: (i don't see anything that talks about creating a new container in its help)
[11:49]  * rogpeppe googles
[11:50] <dimitern> rogpeppe, lxc launch ...
[11:50] <rogpeppe> dimitern: not lxd?
[11:51] <dimitern> rogpeppe, lxc is the cli client, lxd is the server daemon
[11:51] <dimitern> voidspace, LGTM
[11:51] <rogpeppe> dimitern: ok, now i have to work out how to fetch an image...
[11:52] <dimitern> https://linuxcontainers.org/lxd/getting-started-cli/ << nice guide
[11:52] <dimitern> rogpeppe ^^
[11:52] <rogpeppe> dimitern: ah, launch ubuntu failed but launch ubuntu:14.04 worked
[11:53] <rogpeppe> dimitern: still no ipv4 address
[11:53] <dimitern> rogpeppe, I think juju adds an alias "ubuntu" for the current series image
[11:54] <dimitern> rogpeppe, ah :/ bad luck - folks in #server @c might be able to help
[11:54] <rogpeppe> dimitern: i'll just give up and use ec2 i think. i've already spent too much time chasing this.
[11:54] <rogpeppe> dimitern: thanks for your help.
[11:55] <voidspace> dimitern: thanks
[11:55] <voidspace> anastasiamac: the way we interact with maas has completely changed
[11:55] <voidspace> anastasiamac: isn't it horrifically late for you now?
[11:56] <dimitern> rogpeppe, np
[11:56] <voidspace> dimitern: shall I just land the master merge?
[11:56] <voidspace> dimitern: http://reviews.vapour.ws/r/4473/
[11:58] <anastasiamac> voidspace: i had a preview of new maas abstraction (peeked at thumper's branch)! it's awesome \o/ thank you for doing it!
[11:58] <voidspace> anastasiamac: yeah, it's very cool - all thumper's work, we're just using
[11:58] <anastasiamac> voidspace: it's 10pm... for normal ppl probably not a work hour... but who here respects that? :D
[11:59] <voidspace> anastasiamac: ah, I thought it was later
[11:59] <voidspace> heh
[12:00] <anastasiamac> voidspace: r u re-writting maas19 interactions in similar way too?
[12:00] <anastasiamac> or it stays the same?
[12:01] <dimitern> voidspace, does it build and pass make check?
[12:37] <babbageclunk> voidspace: sorry, been talking to frobware, not doing much typing
[12:41] <mup> Bug #1567396 opened: tools/lxdclient should not be using a global variable for several functions <lxd> <tech-debt> <testing> <juju-core:Triaged> <https://launchpad.net/bugs/1567396>
[12:41] <frobware> dooferlad, ping
[12:42] <dooferlad> frobware: pong
[12:43] <frobware> dooferlad, can we HO about the bond issue - was interested in your repro case
[12:43] <voidspace> anastasiamac: probably not, too much work :-(
[12:43] <dooferlad> frobware: sure, but I really need lunch
[12:43] <voidspace> anastasiamac: MAAS 2 is new code so worth doing right
[12:43] <dooferlad> frobware: can it wait 30 minutes?
[12:43] <frobware> dooferlad, whenever works
[12:43] <dooferlad> frobware: thanks!
[12:43] <voidspace> dimitern: yep, builds and passes
[12:43] <voidspace> dimitern: I had some conflict resolution to do - nothing too difficult though
[12:44] <anastasiamac> voidspace: sounds sensible
[12:45] <voidspace> babbageclunk: my feature flag change has landed on MAAS2
[12:46] <babbageclunk> voidspace: Sweet
[12:46] <voidspace> babbageclunk: so after you update you'll need to set the MAAS2 feature flag to bootstrap against MAAS 2.0
[12:46] <dimitern> voidspace, lgtm
[12:46] <voidspace> anastasiamac: it would certainly be possible, and nicer... so if anyone has any spare time :-)
[12:46] <voidspace> dimitern: ta
[12:48] <anastasiamac> voidspace: well, i don't think it's worth it... but the decision should b based on maas.19 life expectancy ... if it's to be short-lived, I'd say that what we have now will do...
[12:48] <voidspace> anastasiamac: yeah
[12:48] <voidspace> nobody ever has any spare time anyway
[12:49] <anastasiamac> so true
[13:28] <rogpeppe> could i have a review on this almost-entirely-trivial one line change, please? it should make some things easier to debug in the future. https://github.com/juju/cmd/pull/35
[13:29] <dooferlad> frobware: back
[13:40] <natefinch> rogpeppe: would prefer not to log the error twice
[13:40] <natefinch> rogpeppe: can you do an if debug enabled...
[13:40] <frobware> dooferlad, was your repro case with h/w?
[13:41] <dooferlad> frobware: yes
[13:41] <frobware> dooferlad, as opposed to KVM
[13:41] <rogpeppe> natefinch: what would you do by preference? it's *really* useful to be able to see the error details.
[13:41] <rogpeppe> natefinch: you'd print the error differently if debug enabled?
[13:42] <rogpeppe> natefinch: i think it's kinda reasonable to have a separate debug line exposing details of the error without changing the usual error printing
[13:42] <natefinch> rogpeppe: yes... details if debug enabled, otherwise just the string..... otherwise you're printing the error twice, which could be confusing, make it look like we did something twice
[13:43] <rogpeppe> natefinch: tbh i think we'd want the error details on a separate line for readability anyway
[13:43] <rogpeppe> natefinch: perhaps a better error message string would felp?
[13:43] <rogpeppe> help
[13:44] <natefinch> rogpeppe: I just worry that two log entries would be confusing. Maybe if debug is enabled, append the details to the single errorf log message?
[13:45] <rogpeppe> natefinch: if you do that, that line becomes very unwieldy
[13:45] <rogpeppe> natefinch: i think it should be reasonably obvious - one's at debug level and they both contain the same text.
[13:46] <rogpeppe> natefinch: perhaps surround it all in brackets? "(error details: xxxx)" and print after the main error message?
[13:46] <natefinch> rogpeppe: then put a comment in the code that states you're doing it on purpose, otherwise someone's going to come along and "clean up" the "duplicate" log output.
[13:46] <natefinch> rogpeppe: I do think after is better than before
[13:47] <natefinch> rogpeppe: and brackets will make it more obvious that it's not just another instance of the error.
[13:47] <natefinch> rogpeppe: and maybe use a sans-serif font, since that'll make it stand out more.
[13:47] <rogpeppe> natefinch: :)
[13:56] <mup> Bug #1567458 opened: destroy-controller message and failure is not user friendly <juju-core:New> <https://launchpad.net/bugs/1567458>
[14:10] <rogpeppe> natefinch: better now? https://github.com/juju/cmd/pull/35/files
[14:15] <natefinch> rogpeppe: lgtm
[14:15] <rogpeppe> natefinch: thanks
[14:15] <alexisb> morning all
[14:18] <dooferlad> morning alexisb
[14:18] <perrito666> hi alexisb
[15:20] <kwmonroe> hey tych0, does your lxdbr0 fix always return 'lxdbr0', or do we check elsewhere for whatever the user configured?  (https://github.com/juju/juju/pull/5004/files#diff-d0829a0ea5ffc060343eba40ecd40aa8R66)
[15:24] <tych0> kwmonroe: yes, that only gets called when the user hasn't configured anything
[15:24] <tych0> kwmonroe: expand the last hunk of the diff and you can see
[15:25] <voidspace> babbageclunk: StartInstance can allocate and start a machine
[15:25] <voidspace> babbageclunk: and I've done as much of StartInstance as is possible without further work in gomaasapi
[15:26] <voidspace> babbageclunk: now to test it all...
[15:26] <voidspace> babbageclunk: don't forget to write up what you've done in the doc
[15:27] <kwmonroe> cool tych0, thx
[15:56] <frobware> babbageclunk, http://juju-sapphire.github.io/
[16:02] <frobware> babbageclunk, https://github.com/dimitern/testcharms
[16:04] <perrito666> cherylj: ping
[16:04] <babbageclunk> voidspace: nice! I've got the storage stuff done, although not tested yet. Need to merge your master merge.
[16:04] <cherylj> hey perrito666, what up
[16:04] <voidspace> babbageclunk: cool
[16:05] <babbageclunk> voidspace: will write up now
[16:05] <voidspace> babbageclunk: I found another undocumented parameter to AllocateMachine
[16:05] <voidspace> babbageclunk: storage....
[16:05] <babbageclunk> voidspace: yay
[16:05] <perrito666> hey, I am trying to test my fix using lxd provider but I get a permission denied on my instances :( when juju tries to ssh, did you enconter this issue testing with xenial?
[16:05] <voidspace> babbageclunk: so storage and spaces are not yet supported, but trivially easy to add them
[16:06] <babbageclunk> voidspace: why not spaces?
[16:07] <voidspace> babbageclunk: because interfaces parameter is missing on AllocateMachineArgs
[16:07] <voidspace> that's the first undocumented parameter, storage is the second
[16:07] <perrito666> cherylj: that was for you
[16:07] <voidspace> they haven't changed since 1.9 - but they weren't documented there either...
[16:07] <babbageclunk> voidspace: ah, right - thought you meant because storage isn't done yet
[16:08] <cherylj> perrito666: I'm thinking of what might be causing that....
[16:08] <voidspace> babbageclunk: no, you specify storage to AllocateMachine (as well as the storage specific code)
[16:08] <voidspace> babbageclunk: I'm off to do some exercise - bbiab
[16:08] <cherylj> perrito666: when are you running into this?  during bootstrap?
[16:09] <cherylj> perrito666: do you have a --debug output you could paste?
[16:09] <voidspace> babbageclunk: what happened with StopInstances - is it done?
[16:09] <voidspace> babbageclunk: I need that too really, it's used by StartInstance
[16:09] <perrito666> cherylj: during bootstrap everything seems fine until the moment where it has to try logging int
[16:09] <perrito666> which is odd because the ubuntu user has the right credentials in authorized keys
[16:09] <cherylj> perrito666: what's your host?  xenial?
[16:10] <perrito666> wily
[16:10] <babbageclunk> voidspace: It's done but not tested - it needed storage so I parked it while I was doing that.
[16:11] <babbageclunk> voidspace: Once storage is merged and pushed I'll merge storage into stop instances and push that too.
[16:11] <babbageclunk> Then you can use both/
[16:11] <mup> Bug #1567518 opened: Payload commands don't work <juju-core:New> <https://launchpad.net/bugs/1567518>
[16:13] <cherylj> perrito666: could you humor me and paste the --debug output?
[16:15] <cherylj> redir_afk: your PR: https://github.com/juju/juju/pull/5022 is going to conflict with one of mine because I also removed that lower case test :)
[16:15] <cherylj> it's a race to merge!!
[16:16] <perrito666> cherylj: sure I was waiting for it to finish
[16:17] <perrito666> cherylj: https://pastebin.canonical.com/153710/
[16:17] <cherylj> oh oh oh I think I may know
[16:17] <cherylj> perrito666: are you in the lxd group?
[16:17] <perrito666> yes
[16:17] <cherylj> I thought I saw something similar
[16:17] <cherylj> damn
[16:18] <cherylj>  not that then
[16:18] <cherylj> why is it connecting to 10.0.3.1??
[16:19] <cherylj> perrito666: can you run lxd list and see what the IP is for juju-bf76fca1-e52a-4c5a-877e-650f42945363-machine-0?
[16:19] <cherylj> sorry lxc list
[16:19] <perrito666> well it was destroyed by juju now but it was
[16:19] <perrito666> juju-bf76fca1-e52a-4c5a-877e-650f42945363-machine-0 | RUNNING | 10.0.3.1 (lxcbr0) |      | PERSISTENT | 0
[16:19] <cherylj> perrito666: did you update lxd and do all that reconfiguring?
[16:19] <perrito666> cherylj: yup
[16:20]  * perrito666 tries trusty
[16:20] <cherylj> and did you configure it to use lxdbr0?
[16:20] <cherylj> I think this is the same issue that they're running into in CI
[16:20] <perrito666> I changed my lxd to use lxcbr0
[16:20] <perrito666> cherylj: I found that issue yesterday and fixed it right away
[16:22] <cherylj> perrito666: I think this is a lxd or config issue - I don't think any instance should be assigned the bridge IP (10.0.3.1)
[16:24] <perrito666> the problem happens only when using xenial, odd
[16:35] <cherylj> perrito666: I'm going to play with the machine in CI that's also running into this and see what I can do
[16:38] <perrito666> tx
[16:38] <perrito666> the problem is not present in trusty
[16:40] <perrito666> its  https://cloud-images.ubuntu.com/releases/ the place where images should be being downloaded from?
[16:45] <perrito666> cherylj: confirmed, this happens with xenial image
[16:47] <frankban> cherylj: is http://reports.vapour.ws/releases/3868/job/run-unit-tests-xenial-amd64/attempt/788 really related to embedded-gui? or is it a known problem?
[16:48] <cherylj> frankban: that looks like a CI issue.
[16:48] <cherylj> not related to the branch
[16:48] <frankban> cherylj: sorry. I meant http://reports.vapour.ws/releases/3868/job/lxd-deploy-xenial-amd64/attempt/491
[16:49] <cherylj> frankban: not an issue with your branch.  I am working to get that fixed atm :)
[16:50] <frankban> cherylj: ccol, so embedded-gui is clean (at least latest branch), I am merging another one there
[16:50] <frankban> cherylj: ty
[16:50] <cherylj> np!
[16:50] <cherylj> frankban: is the --no-gui bootstrap flag the last piece for that branch?
[16:51] <frankban> cherylj: yes, if QA goes ok it's the last one
[16:51] <cherylj> k, thanks!  (and thank you for having makyo pick up that bundle bug!)
[16:51] <frankban> cherylj: so I am thinking about merging embedded-gui into master tonight or tomorrow morning, after QA
[16:51] <frankban> cherylj: np
[16:51] <cherylj> frankban: we will merge it for you once it gets a good CI run
[16:51] <cherylj> so no need to worry about that
[16:52] <frankban> cherylj: awesome!
[16:52] <cherylj> and we'll let you know if there are problems too :)
[16:52] <frankban> cherylj: cool
[16:54] <frankban> cherylj: oh, after this one lands I'd have to merge master back into embedded-gui, so that we can start QAing with new lxd stuff etc. is that a problem?
[16:54] <perrito666> cherylj: is there any other way that I can test my fix? are there xenial images in amazon?
[16:55] <cherylj> frankban: can you work directly on master once we land embedded-gui?  If your changes aren't radical / pervasive, you should do that
[16:55] <cherylj> perrito666: yes :)  bootstrap on aws with default-series=xenial works  just fine :)
[16:55] <perrito666> tx a lot
[16:56] <frankban> cherylj: when are we landing embedded-gui?
[16:57] <cherylj> frankban: after it gets a good CI run
[16:57] <frankban> cherylj: ok, ack
[16:57] <cherylj> so if everything passes, today or tomorrow
[16:57] <frankban> cherylj: ok, so I'll not merge master back, so we'll have a single CI run, correct?
[16:58] <cherylj> frankban: when did you last merge master?
[16:58] <frankban> cherylj: Apr 4 13:44:16
[16:59] <cherylj> frankban: yeah, I'd re-merge master before we do another CI run.  There have been fixes to CI failures since then
[16:59] <frankban> cherylj: ok, I'll do that asap then
[17:00] <cherylj> thx!
[17:00] <frankban> cherylj: --no-gui just landed, Il'' merge master
[17:08] <redir> cherylj: let me know what order you prefer
[17:11] <frankban> cherylj: ok mrege job is running https://github.com/juju/juju/pull/5036
[17:12] <perrito666> aghhh xenial really hates me
[17:12] <perrito666> finally booting, bbl in about one hour, mail me if anybody needs me
[17:58] <lazyPower> So, i'm not sure what to plug in a bug here if someone has a second to lend a hand so i can file a bug about this properly i'd appreciate the help - https://youtu.be/ApLWbc2qQ30  <-- illustration of the issue
[18:05] <rick_h_> lazyPower: you killed it!
[18:06] <rick_h_> lazyPower: so...it sure looks like storage-get somehow took down the stateserver?
[18:06] <rick_h_> lazyPower: can you juju status outside of the debug-hook?
[18:10] <cherylj> ....um... I'm pretty sure that we shouldn't be setting the lxc bridge address as an API Host port for the lxd provider
[18:10] <cherylj> Has anyone deployed a service in lxd recently?
[18:11] <alexisb> cherylj, I have been trying but failing
[18:11] <cherylj> I've gotten lxd to bootstrap
[18:11] <alexisb> though before service deploy
[18:11] <alexisb> my controller bootstraps
[18:11] <alexisb> and hosted model fails
[18:11] <cherylj> but the service deployed just stays in " Waiting for agent initialization to finish "
[18:11] <cherylj> fudgey mcfudgeington
[18:12] <alexisb> lovely
[18:12] <alexisb> heh
[18:12] <cherylj> I look at the log and it's trying to connect on the WRONG IP to the controller
[18:12] <alexisb> cherylj, dont you like opening bugs??
[18:12] <cherylj> well, I don't really need to triage bugs that I open, so that's something, right?
[18:12] <cherylj> heh
[18:12] <alexisb> o the bright side
[18:13] <alexisb> see rick_h_ cherylj knows how to see the bright side ;)
[18:13] <cherylj> nice
[18:14] <rick_h_> the bright side is the best side!
[18:17] <mbruzek> cherylj: I tried to bootstrap lxd today, did not get it to work.  ERROR failed to bootstrap model: waited for 10m0s without getting any addresses
[18:17] <cherylj> sinzui_: the bright side here is that I got lxd to bootstrap on the xenial slave
[18:17] <cherylj> sinzui_: the bad part is that agents talk to the wrong IP for the state server
[18:18] <sinzui_> cherylj: but the test still doesn't pass http://juju-ci.vapour.ws:8080/view/Juju%20Revisions/job/lxd-deploy-xenial-amd64/492/console
[18:18] <cherylj> sinzui_:  is the revision stale?  I was getting that until I pulled master again
[18:19] <sinzui_> cherylj: ^ I can seen this setup container/vm non sense before and I had to update severalt hings
[18:19] <cherylj> mbruzek: I just worked around that issue in our CI machines.  I had to do the dpkg-reconfigure lxd step mentioned in the thread
[18:19] <lazyPower> rick_h_ - sorry about missing the messages, not sure what happened... some weirdness with my znc i guess... 1 sec while i get you the status output
[18:19] <sinzui_> cherylj: master? maybe I should make it the most important thing to test next
[18:19] <cherylj> sinzui_: yeah, I was pulling from master
[18:19] <mbruzek> cherylj:  I read that, but if I work around it now, will I not have to undo the workaround when Juju fixes the problem?
[18:19] <rick_h_> lazyPower: yea, the question is that you seem to lost connectivity to the state server, so is that it went down for everyone? or just something on that unit you were on? or what
[18:20] <lazyPower> just that unit it appears, and it comes back
[18:20] <lazyPower> its like storage-get is segfaulting or getting an invalid token?
[18:20] <lazyPower> https://gist.github.com/f8f928f5927cd08c55200d6d91652754
[18:20] <lazyPower> there's an error to that effect in one of the debug-hook sessions
[18:20] <mup> Bug #1567594 opened: upgrade-gui command isn't in the juju tab complete <juju-core:New> <https://launchpad.net/bugs/1567594>
[18:20]  * lazyPower fishes that up as well
[18:21] <mbruzek> cherylj: so my question is if I work around it. Wil I have to undo that change when it is fixed
[18:21] <mbruzek> ?
[18:21] <cherylj> mbruzek: my understanding is that the dpkg-reconfigure step is going to be a permanent thing on the lxd side as part that update.
[18:21] <lazyPower> http://paste.ubuntu.com/15676295/ <- that thing is what i was referring to about the session being mismatched
[18:21] <cherylj> mbruzek: as long as there isn't another lxd update that breaks things
[18:21] <cherylj> mbruzek: this should be a one time thing
[18:22] <cherylj> mbruzek: and changes in master (not beta3) will be fixing this "for good"
[18:22] <mbruzek> cherylj: Wouldn't we want to change Juju to look for the new device?
[18:22] <lazyPower> aha paydirt, there's a treasure trove of stacks in the log
[18:22] <cherylj> well
[18:22]  * lazyPower fires up a bug
[18:22] <cherylj> mbruzek: those changes are in master
[18:22] <rick_h_> lazyPower: hmm, yea. I'd go with a bug along the lines of "storage-get causes state server to 'error: bad request'
[18:22] <cherylj> mbruzek: and will be part of the release next week
[18:23] <mbruzek> cherylj: So my  understanding is the old lxd named the bridge one way, the  new lxd names it something new, so the fix is to reconfigure lxd to use the old name.
[18:23] <mbruzek> cherylj: I figured Juju was just going to start looking for the new name.
[18:23] <mbruzek> cherylj: Or am I misunderstanding the email thread?
[18:23] <cherylj> mbruzek: yeah, that's how you can get it working with beta3.  The changes in master are to make juju smarter about choosing the name, I believe
[18:23] <cherylj> not hard coding
[18:23] <mbruzek> cherylj: perfect
[18:24] <mbruzek> cherylj: Thank you for explaining it to me.
[18:25] <cherylj> mbruzek: no worries, it helped me too...  and I see in the code that we look first for lxdbr0, then fall back to lxcbr0 if not present
[18:28] <lazyPower> https://bugs.launchpad.net/juju-core/+bug/1567598
[18:28] <mup> Bug #1567598: storage-get causes state server to 'error: bad request' <juju-core:New> <https://launchpad.net/bugs/1567598>
[18:29] <cherylj> latent bug alert!
[18:29] <cherylj> heh
[18:30] <cherylj> these lxd issues have revealed a latent bug in the lxd provider
[18:41] <mup> Bug #1567598 opened: storage-get causes state server to 'error: bad request' <storage> <juju-core:New> <https://launchpad.net/bugs/1567598>
[18:56] <redir> can I set an env variable via gocheck to have it pass it/set it up for tests?
[18:57] <redir> or just run with an env var set?
[19:02] <mup> Bug #1567607 opened: vsphere bootstrap fails when environments.yaml has a password with the # character <bootstrap> <cdo-qa> <vsphere> <juju-core:New> <https://launchpad.net/bugs/1567607>
[19:13] <perrito666> cherylj: http://reviews.vapour.ws/r/4481/
[20:03] <mup> Bug #1567635 opened: FilterLXCAddresses should be updated to also filter out lxd bridge addresses <network> <juju-core:Triaged> <https://launchpad.net/bugs/1567635>
[21:06] <bogdanteleaga> how can I get logs with debug-log from a controller?
[21:23] <mwhudson> perrito666: ping
[21:24] <mwhudson> perrito666: looks like mongo/mongo.go only looks for /usr/lib/juju/mongo3/bin/mongod but iiuc that's never going to be released
[21:24] <mwhudson> perrito666: and it should look for /usr/lib/juju/mongo32/bin/mongod instead?
[21:24] <mwhudson> er 3.2
[21:26] <redir> Anyone around with knowledge of juju/juju/cmd/juju/commands/ssh bits ?
[21:27] <mwhudson> er er this got fixed and then reverted in master a few days ago
[21:50] <bogdanteleaga> anybody from networking around?
[21:51] <rick_h_> bogdanteleaga: sorry, they're UK/EU
[21:51] <thumper> bogdanteleaga: what do you need?
[21:53] <bogdanteleaga> thumper, just deployed a windows machine with 2.0 and I'm getting a *lot* of spam in the logs
[21:53] <bogdanteleaga> http://sprunge.us/LdKN
[21:53] <bogdanteleaga> not sure what it's even trying to do
[21:55] <thumper> bogdanteleaga: that isn't just spam, but a bug
[21:56] <thumper> notice this:
[21:56] <thumper> machine-3: 2016-04-08 05:35:45 DEBUG juju.worker.dependency engine.go:475 "machiner" manifold worker stopped: cannot update observed network config: cannot set link-layer devices to machine "3": invalid device "Loopback Pseudo-Interface 1": Name "Loopback Pseudo-Interface 1" not valid
[21:56] <thumper> machine-3: 2016-04-08 05:35:45 ERROR juju.worker.dependency engine.go:522 "machiner" manifold worker returned unexpected error: cannot update observed network config: cannot set link-layer devices to machine "3": invalid device "Loopback Pseudo-Interface 1": Name "Loopback Pseudo-Interface 1" not valid
[21:56] <thumper> unit-noop-2: 2016-04-08 05:35:47 INFO juju.worker.upgrader upgrader.go:178 desired tool version: 2.0-beta4
[21:56] <thumper> machine-3: 2016-04-08 05:35:48 DEBUG juju.worker.dependency engine.go:461 "machiner" manifold worker started
[21:56] <thumper> machine 3 bis anyway
[21:56] <thumper> trying to set an invaliddevice
[21:57] <thumper> machiner worker stops
[21:57] <thumper> and then restarts
[21:57] <thumper> rince and repeat
[21:57] <bogdanteleaga> yeah, I notice the lack of a machiner
[21:57] <bogdanteleaga> at least it gets a few seconds of activity to launch the unit \o/
[21:57] <thumper> so, obvious bug there
[21:58] <thumper> bogdanteleaga: btw, bumped into a guy over here who when to uni with a some cloudbase guys
[21:58] <thumper> adi I think
[21:58] <thumper> and someone else
[21:59] <bogdanteleaga> we've got quite a few adi's :p
[21:59] <bogdanteleaga> any chance you know his name?
[21:59] <bogdanteleaga> (the guy you met)
[21:59] <thumper> bogdanteleaga: Elvis Adomnica
[22:00] <thumper> bogdanteleaga: he now teaches at Otago Polytechnic
[22:00] <thumper> such a small world
[22:02] <bogdanteleaga> thumper, yup :)
[22:02] <bogdanteleaga> for a second I thought you're at some sprint in europe :p
[22:03] <thumper> he
[22:03] <thumper> not yet
[22:03] <thumper> speaking of which
[22:03] <thumper> alexisb: we haven't talked further about team sprint location
[22:03] <alexisb> thumper, yea
[22:03] <alexisb> I suck
[22:03] <thumper> it is a busy time
[22:04] <thumper> everyone has other focus
[22:06] <mup> Bug #1567676 opened: windows: networker tries to update invalid device and blocks machiner from working <juju-core:New> <https://launchpad.net/bugs/1567676>
[22:11] <thumper> anyone? https://github.com/juju/gomaasapi/pull/27
[22:13] <mwhudson> um
[22:13] <mwhudson> do the juju tests pass with mongodb 3.2?
[22:13]  * thumper shrugs
[22:14]  * mwhudson bangs head on nearby flat surface
[22:16] <mwhudson> i'm seeing some failures on s390x but i bet they're not the fault of my patches
[22:16] <mwhudson> ... error string = "server returned error on SASL authentication step: Authentication failed."
[22:16] <mwhudson> ... regex string = "auth fail(s|ed)"
[22:19] <thumper> heh
[22:19] <alexisb> mwhudson, the only bug we have for s390 is https://bugs.launchpad.net/juju-core/+bug/1565044
[22:19] <mup> Bug #1565044: s390x unit tests fail because not tools for arch <ci> <jujuqa> <s390x> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1565044>
[22:20] <mwhudson> ahem ahem ahem http://data.vapour.ws/juju-ci/products/version-3869/run-unit-tests-mongodb3/build-484/consoleText
[22:20] <mwhudson> + echo 'mongodb3 unittests are not supported by master'
[22:20] <mwhudson> mongodb3 unittests are not supported by master
[22:20] <mwhudson> + exit 0
[22:21] <mwhudson> alexisb: i don't want to load more onto the juju team but is someone working on this?
[22:22] <mwhudson> if juju in xenial is going to use mongodb3.2 it seems like the tests should work with that combination...
[22:22] <alexisb> mwhudson, yep
[22:22] <alexisb> we will get someone on it
[22:22] <mwhudson> ok cool
[22:36] <mup> Bug #1567683 opened: lxd provider should filter bridge addresses from instance.Address() <lxd> <network> <juju-core:Triaged> <https://launchpad.net/bugs/1567683>
[22:43] <alexisb> thumper, is menn0 around today?
[22:43] <thumper> yep
[22:43] <thumper> heh, he reboots and forgets to reconnect to IRC
[22:44] <alexisb> I sent mail thanks
[22:52] <alexisb> finally!
[22:53] <thumper> alexisb: finally what?
[22:54] <alexisb> got the lxdbr0 configured correctly
[22:54] <alexisb> now juju will work until I try and deploy a service
[22:54] <alexisb> :)
[22:54] <alexisb> it is a start
[23:01]  * mwhudson gives up testing juju on his own machine and just gives money to amazon instead
[23:02] <alexisb> mwhudson, you can expense a certain amount
[23:02] <alexisb> and we have shared amazon accounts - though I dont have all the details
[23:02] <alexisb> as I use my own
[23:03] <mup> Bug #1567690 opened: Can't push charm to my new LP home <juju-core:New> <https://launchpad.net/bugs/1567690>
[23:05] <rick_h_> alexisb: mwhudson 200/mo no qiestions as long as it's juju related
[23:06] <rick_h_> more with reasons/etc
[23:06] <anastasiamac> a review plz http://reviews.vapour.ws/r/4484/ (it's an easy one-liner)
[23:15] <mwhudson> rick_h_: i expect i'll be spending about $2 :-)
[23:17] <anastasiamac> axw: perrito666: standup
[23:17] <axw> onm
[23:17] <axw> omw
[23:38] <redir> axw: http://reviews.vapour.ws/r/4485/ and I'll bbiab.
[23:38] <axw> redir: cheers, looking