[00:08] glad everyone is in good health and spirits. [00:10] anastasiamac: I'm at a loss to help that person with https://github.com/CanonicalLtd/jujucharms.com/issues/372 [00:10] he was in asking for help on Friday. [00:11] But got beyond my depth [12:49] short review for anyone who fancies it: https://github.com/juju/persistent-cookiejar/pull/19 [12:52] voidspace: hm, that is shorter than I expected [12:52] mgz: heh, good [12:52] mgz: hey, do you know how easy it would be to get a custom build of juju into a ppa? [12:53] mgz: all juju tests pass with that branch of persistent-cookiejar, FYI [12:53] it's not super hard, but also of somewhat questionable use [12:54] mgz: hah, I uploaded a custom binary for the reporter of the bug this addresses - and they don't know what to do with it and are asking for a ppa [12:54] mgz: I've added another comment to the bug, but I've told them I'd try to get it into a ppa [12:54] mgz: maybe I'll ask rick what he thinks at standup [13:06] voidspace: yea this is part of the snap request [13:06] To start to make it universal for folks testing [13:20] rick_h: I'm looking at snapping it now, but I don't think they would know what to do with that either [13:23] voidspace: right, but we can start to get docs together for it. snap install it, remove cleanly. [13:23] voidspace: can you link me to the bug? /me is curious who we're talking about here [13:23] rick_h: https://bugs.launchpad.net/juju-wait/+bug/1632362 [13:23] Bug #1632362: error during juju-wait ERROR cannot load cookies: file locked for too long; giving up: cannot acquire lock: resource temporarily unavailable [13:23] rick_h: lustostag [13:24] rick_h: he's not online right now [13:25] voidspace: oh, it this larry from OIL? [13:25] voidspace: hmm, /me thought he should be able to handle the binary. [13:25] rick_h: Greg Lutostanski [13:25] the bug was reported by Larry, no response from him [13:26] voidspace: ah ok, larry is on the bug to and should be able to work with it as well. [13:26] k, no response yet - just digging into snapcraft as our snapcraft.yaml in the development tree fetches from github [13:26] but grabbing coffee first [13:26] brb [13:26] (if I find Greg or Larry online later I'll chat to them) [13:30] voidspace: yea, please reach out to cmars or balloons if there's any snap help there. [14:58] natefinch: o/ [14:58] bbl lunch [15:00] jujuteam standup please [15:00] voidspace: ^ [15:00] kk [15:00] * rick_h needs to check if folks setup nick highlight [15:17] rick_h: really difficult to estimate; errors hiding other errors =/ http://pastebin.ubuntu.com/23476038/ [15:18] katco: ok, np. just wanted to see how to set expectations re: next line of work [15:23] rick_h: do we still need our 1:1 given we met tr? [15:24] katco: up to you, I have gotten out my notes so it's available time for yourself if you want it [15:24] rick_h: i don't have anything new [15:25] katco: k, I'll leave you to awesome fun test land then, but poke me with a stick if anything comes up [15:25] rick_h: will do [16:39] Bug #1641643 opened: Boostrapping node fails to complete cloud init does to failure of System Logging Service

[17:13] rick_h: someone, rock_, was in looking for help on https://github.com/CanonicalLtd/jujucharms.com/issues/372 but I didn't know where to point them. Thoughts? [17:17] redir: the folks managing the store need to help. Uiteam [18:11] perrito666 natefinch katco anyone have any idea on how to get access to https://goo.gl/tNVh06 in a kvm container https://goo.gl/NJV7gg ? [18:11] redir: I know not, sorry :( [18:11] perrito666: np, worth asking [18:12] redir: i suggest passing that function in as an argument and see what breaks. continue up the stack [18:13] katco: yeah that seems to mean passing state down through the hall of abstrat mirrors [18:13] redir: no don't pass state. *please* don't do that! [18:13] redir: just pass that one function [18:14] which is on state [18:14] I"ll look [18:14] redir: right, but you don't have to pass a reference to state, just the function [18:14] redir: remember functions are reified [18:14] yeah, just changing untold layers of abstraction [18:15] redir: big systems necessitate this to be at all maintainable [18:15] yes [18:16] redir: at any rate, that's what i do: fix the module by requiring injection, and that takes me up the stack to where i can pass it in [18:16] redir: good luck! [18:22] thanks katco [18:24] mgz: if you have a chance, I'd love your comments on my branch [18:26] voidspace: sure thing, will do that now [19:26] rick_h: perri.to [19:38] really? We stop people from putting capital letters in their application names? Geez. [19:57] morning folks [20:02] morning thumper [20:02] o/ [20:11] thumper: hey, hope everything is well down there [20:11] fine in Dunedin [20:11] although main highway down the island is shut at the top [20:11] due to slips [20:11] lots of them [20:11] someone said 100000 slips [20:11] wow [20:11] big ones will take a long time to clear to make road passable again [20:12] and railway tracks were pushed off their footing, across the road and into the sea [20:12] some cool photos [20:12] thumper: going to need a hand with alexisb out. This seems :( and need to know if anyone on your side can look? https://bugs.launchpad.net/juju/+bug/1640535 [20:12] Bug #1640535: HA tests fail after the leader is deleted [20:13] hmm... [20:13] thumper: going to need a hand with alexisb out. This seems :( and need to know if anyone on your side can look? https://bugs.launchpad.net/juju/+bug/1640535 [20:13] Bug #1640535: HA tests fail after the leader is deleted [20:14] oops [20:14] dammit, different irc client working different [20:14] * rick_h goes to get the boy from school biab [20:40] jam: are you around? [20:49] perrito666: midnight there atm and he's on a couple of swap days [20:49] perrito666: might be best to go async or if there's something someone else can help with [20:50] rick_h: just a curiosity, I need someone old enough in the project :) and his name was on the code [20:50] perrito666: gotcha [21:53] mgz: you still around? [21:58] voidspace: heya [21:58] mgz: hey, thanks for the review [21:58] mgz: I'll change that variable name, good call [21:59] the other comment I think there's no change required [21:59] mgz: but on the encode then replace dance - because only alphanumeric characters are valid for lock names [21:59] mgz: yeah, I think it's needed [21:59] mgz: but I agree it's not ideal [21:59] mgz: anyway, thanks :-) [21:59] will do it now and land it, so we can get the change into the develop branch [22:00] my comment was going to be base32 it instead, but given we just need the uniqueness, losing two of the encoded characters isn't really a big deal [22:01] right [22:01] and base32 would generate longer strings so we'd chop out more of the hash when we truncate it [22:01] (40 char limit for lock names) [22:14] who is admin for our github? I believe there is a way to set develop as the default branch when trying to merge [22:14] perrito666: you can, but you have to do it as the default to pull and staging is meant to be that [22:15] perrito666: moving it to develop as the default branch isn't the goal, it's just a pain point because we can't get blesses and merges to staging due to our test woes [22:15] rick_h: oh, I was just talking about the papercut when PRing [22:16] but I guess GH is not That configurable [22:16] perrito666: it does have a single "default branch" that you can change, but I don't think it's wise for us to do that [22:16] rick_h: correct, I thought it had a "branch to push" and "branch to pull" [23:19] menn0: ping? [23:19] babbageclunk: howdy [23:20] menn0: The logsink endpoint - does the client just keep the websocket open and keep sending logs to it as they come in? [23:21] babbageclunk: simplisticly speaking, yes [23:21] menn0: hmm, except it still gets shut down at migration, right? [23:21] * menn0 checks [23:32] babbageclunk: sorry for the delay... a bit of drama here... looking now [23:33] menn0: No worries! [23:33] babbageclunk: so yeah, logsender is shut down during migrations [23:35] babbageclunk: there is a deque which accumulates when the logsender isn't active/connected [23:36] menn0: I've added code to the logsink handler to release the state when the connection finishes, but it's never happening. [23:39] babbageclunk: i'll probably need more context... [23:41] menn0: Might be easier to explain in person!