[00:16] <babbageclunk> axw: can you take a gander at https://github.com/juju/juju/pull/6868?
[00:37] <axw> babbageclunk: looking
[00:43] <axw> babbageclunk: all the other works are quiesced while this code runs, right?
[00:43] <axw> workers*
[00:44] <axw> babbageclunk: the provisioner won't be trying to update things, for example?
[00:49] <anastasiamac> menn0: axw: for bug 1660087, we just need to know if it has been addressed in later revisions, on 2.1.x
[00:49] <mup> Bug #1660087: Controller and all models unresponsive <canonical-is> <juju:Triaged by menno.smits> <https://launchpad.net/bugs/1660087>
[00:50] <axw> anastasiamac: can't say until we know what the root cause is
[00:50] <anastasiamac> axw: hopefully, logs attached to the bug will help :D
[00:51] <axw> anastasiamac: yeah, hopefully. I'll look when I can
[00:51] <anastasiamac> axw: nps \o/
[00:57] <babbageclunk> axw: yeah, that's right - they're all gated by the migration flag
[00:58] <axw> babbageclunk: ok, thanks. I've left some comments
[00:58] <babbageclunk> axw: cool, thanks!
[01:04] <menn0> anastasiamac: sorry I was out for a bit
[01:04] <menn0> anastasiamac: what axw said :)
[01:04] <anastasiamac> menn0: thnx :)
[01:19]  * menn0 is going dark for a while to focus on CAAS 
[01:32]  * redir goes eod
[01:34]  * redir will look at #1654603 in the morning if still waiting for PPC64EL MAAS access.
[01:34] <mup> Bug #1654603: kill-controller takes too long, is it waiting for hooks to finish? <landscape> <juju:Triaged> <https://launchpad.net/bugs/1654603>
[02:25] <babbageclunk> Does anyone know how to get maas to see a change in max ram after changing it in vmm?
[02:26] <babbageclunk> Do I need to remove and recommission it, or is there a more direct way?
[02:32] <anastasiamac> babbageclunk: i wonder if maybe we should reach out to MAAS guys? dunno if any of them are in this channel..
[02:33] <babbageclunk> anastasiamac: yeah, I'll go ask over there.
[04:47] <mup> Bug #1660522 opened: Un-removeable "life: dead", "agent-state: pending"  agents  <canonical-bootstack> <juju-core:New> <https://launchpad.net/bugs/1660522>
[05:24] <axw> jam: bridge testing again, didn't notice IRC failed to reconnect. wallyworld raised the same issue of remove-storage vs. detach-storage
[05:25] <axw> jam: my question is what that means in the case of shared storage
[05:26] <axw> jam: we can just have it mean "detach from the application", which might be reasonable?
[05:51] <jam> axw: sorry, I've got a bunch of different things in my head right now. I just wanted to make sure I understood what made you uneasy, so that I understand the full problem. I probably won't be able to switch to that for a bit
[05:52] <axw> jam: it's all good, I'm looking at the lxd/maas networking issue now
[07:01] <axw> wallyworld: ping?
[07:01] <wallyworld> hey
[07:01] <axw> wallyworld: yo. about the firewaller thing. can you HO? might be easier
[07:02] <wallyworld> sure, give me 5
[07:02] <axw> wallyworld: np, ping when
[07:09] <wallyworld> 1:1?
[07:20] <axw> wallyworld: yes
[07:35] <mup> Bug #1660542 opened: container mac addresses should use 'locally assigned' section <lxd> <mac-address> <network> <juju-core:Triaged> <https://launchpad.net/bugs/1660542>
[07:35] <mup> Bug #1660543 opened: container mac addresses should use 'locally assigned' section <lxd> <mac-address> <network> <juju-core:Triaged> <https://launchpad.net/bugs/1660543>
[07:41] <wallyworld> axw: changes pushed
[07:41] <axw> wallyworld: looking
[07:44] <axw> wallyworld: LGTM
[07:44] <wallyworld> ty
[08:26] <babbageclunk> axw: take another look? https://github.com/juju/juju/pull/6868
[08:26] <axw> babbageclunk: looking
[08:27] <babbageclunk> axw: thanks! you weren't kidding when you said callAPI was ugly.
[08:27] <axw> babbageclunk: yeah :/
[08:27] <axw> babbageclunk: probably should just bite the bullet and write our own wrapper API clients
[08:28] <axw> (not in this PR though)
[08:28] <babbageclunk> axw: no :)
[08:30] <axw> babbageclunk: done
[08:30] <babbageclunk> axw: cheers
[11:00] <mup> Bug #1660543 changed: container mac addresses should use 'locally assigned' section <lxd> <mac-address> <network> <juju-core:Triaged> <https://launchpad.net/bugs/1660543>
[12:30] <perrito666> morning all
[13:48] <rick_h> redir: ping when/if you're about
[13:55] <perrito666> rick_h: I doubt he will be here for a couple of hours
[13:55] <rick_h> perrito666: yea, just realized. I ping'd him out of band
[13:55]  * rick_h somehow thought the day was farther along
[14:15] <jam> a review of https://github.com/juju/juju/pull/6893 is requested
[14:15] <jam> it involves refactoring the code that checks what bridges to create for containers, but doesn't, itself, change any of the logic
[14:15] <jam> just pulls it off of Machine where it didn't really belong.
[14:15] <jam> frobware: ^^
[14:59] <frobware> jam: reviewed
[15:07] <jam> frobware: responded and pushed up an update
[15:07] <jam> care to take another look
[15:08] <frobware> jam: looking
[15:09] <frobware> jam: LGTM
[15:14] <frobware> jam: I was just taking another look on the files that were added.
[15:17] <frobware> jam: those tests - they were just the tests that were moved?
[15:19] <frobware> jam: if the error doesn't bubble up to the user then I think what you suggested is fine.
[15:20] <jam> frobware: so how the code is *currently* used, the only caller of it ensures that its only dealing with bridges first
[15:20] <jam> frobware: I added the check because I split the code from where it was created from where the check was done
[15:20] <jam> frobware: and I believe in validating inputs in case someone uses it differently in the future
[15:21] <jam> frobware: hypothetically, that sort of error could bubble to the user if we have a bug in our software, so I did tweak the wording
[15:21] <frobware> jam: ack
[16:51] <redir> rick_h: pong
[16:51] <redir> I see a task in the Juju Show
[16:52] <rick_h> redir: howdy, yep
[16:52] <redir> todo made
[16:52] <rick_h> redir: wanted to see if you had some details/etc you wanted/could flesh out
[16:52] <rick_h> redir: ty
[16:52] <redir> rick_h: not much, uvtool is gone and it works on ARM64 where kvm does on ARM64 now.
[16:53] <rick_h> redir: and works everywhere else expected and this is 2.2 ?
[16:53] <redir> otherwise there's no change to the API or feature set, but I can make an outline
[16:53] <redir> rick_h: still trying to get access to ppc64el HW to test and debug there.
[17:39] <redir> brb need to let the tree trimmers in the garden
[18:15] <perrito666> brb, afternoon snack :)
[19:42] <redir> perrito666: you made me hungry
[19:42] <perrito666> redir: sad to be you mate :p
[19:42] <perrito666> I actually had to drive 15 min to get the snack
[20:22] <redir> develop is broken
[20:34] <redir> same breakage in 2.1
[20:46] <menn0> redir: what's the breakage? (I haven't looked)
[20:47] <redir> # github.com/juju/juju/worker/machineactions
[20:47] <redir> worker/machineactions/handleactions.go:70: unknown "github.com/juju/utils/exec".RunParams field 'User' in struct literal
[20:47] <redir> worker/machineactions/handleactions.go:87: not enough arguments to return
[20:47] <redir> menn0: ^ was going to look at the history after lunch
[20:47] <menn0> how the hell did that get in?
[20:48] <redir> the commit where that went in was the 26th
[20:48] <redir> perhaps before verify.bash was enabled on CI
[20:49] <redir> s/enabled/fully enabled
[20:49] <redir> and someone prolly didn't have the pre-commit hook enabled
[21:03] <menn0> redir: seems likely
[21:06] <redir> OK nm, I think It is me
[21:06] <redir> shockingly
[21:08] <redir> I fatfingered godeps update and missed the error
[22:10] <anastasiamac_> menn0: as an OCR, this PR addresses frequent intermittent bug: https://github.com/juju/juju/pull/6892
[22:33] <perrito666> jam: YUNO squash?
[22:48] <redir> perrito666: prolly because there were conflicts and or merges
[22:55] <redir> juju deploy charm1 charm2 # is this valid syntax?
[23:16] <redir> it appears not but it deploys charm2
[23:28] <redir> but claims it deployed charm1
[23:44] <redir> be a couple minutes late to s/u
[23:46] <menn0> redir: that sounds like sensible behaviour :-/