[00:08] <redir> glad everyone is in good health and spirits.
[00:10] <redir> anastasiamac: I'm at a loss to help that person with https://github.com/CanonicalLtd/jujucharms.com/issues/372
[00:10] <redir> he was in asking for help on Friday.
[00:11] <redir> But got beyond my depth
[12:49] <voidspace> short review for anyone who fancies it: https://github.com/juju/persistent-cookiejar/pull/19
[12:52] <mgz> voidspace: hm, that is shorter than I expected
[12:52] <voidspace> mgz: heh, good
[12:52] <voidspace> mgz: hey, do you know how easy it would be to get a custom build of juju into a ppa?
[12:53] <voidspace> mgz: all juju tests pass with that branch of persistent-cookiejar, FYI
[12:53] <mgz> it's not super hard, but also of somewhat questionable use
[12:54] <voidspace> 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] <voidspace> 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] <voidspace> mgz: maybe I'll ask rick what he thinks at standup
[13:06] <rick_h> voidspace: yea this is part of the snap request
[13:06] <rick_h> To start to make it universal for folks testing
[13:20] <voidspace> 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] <rick_h> voidspace: right, but we can start to get docs together for it. snap install it, remove cleanly.
[13:23] <rick_h> voidspace: can you link me to the bug? /me is curious who we're talking about here
[13:23] <voidspace> rick_h: https://bugs.launchpad.net/juju-wait/+bug/1632362
[13:23] <mup> Bug #1632362: error during juju-wait ERROR cannot load cookies: file locked for too long; giving up: cannot acquire lock: resource temporarily unavailable <eda> <oil> <juju:In Progress by mfoord> <Juju Wait Plugin:Invalid> <https://launchpad.net/bugs/1632362>
[13:23] <voidspace> rick_h: lustostag
[13:24] <voidspace> rick_h: he's not online right now
[13:25] <rick_h> voidspace: oh, it this larry from OIL?
[13:25] <rick_h> voidspace: hmm, /me thought he should be able to handle the binary.
[13:25] <voidspace> rick_h: Greg Lutostanski
[13:25] <voidspace> the bug was reported by Larry, no response from him
[13:26] <rick_h> voidspace: ah ok, larry is on the bug to and should be able to work with it as well.
[13:26] <voidspace> k, no response yet - just digging into snapcraft as our snapcraft.yaml in the development tree fetches from github
[13:26] <voidspace> but grabbing coffee first
[13:26] <voidspace> brb
[13:26] <voidspace> (if I find Greg or Larry online later I'll chat to them)
[13:30] <rick_h> voidspace: yea, please reach out to cmars or balloons if there's any snap help there.
[14:58] <voidspace> natefinch: o/
[14:58] <perrito666> bbl lunch
[15:00] <rick_h> jujuteam standup please
[15:00] <rick_h> voidspace: ^
[15:00] <voidspace> kk
[15:00]  * rick_h needs to check if folks setup nick highlight
[15:17] <katco> rick_h: really difficult to estimate; errors hiding other errors =/ http://pastebin.ubuntu.com/23476038/
[15:18] <rick_h> katco: ok, np. just wanted to see how to set expectations re: next line of work
[15:23] <katco> rick_h: do we still need our 1:1 given we met tr?
[15:24] <rick_h> katco: up to you, I have gotten out my notes so it's available time for yourself if you want it
[15:24] <katco> rick_h: i don't have anything new
[15:25] <rick_h> katco: k, I'll leave you to awesome fun test land then, but poke me with a stick if anything comes up
[15:25] <katco> rick_h: will do
[16:39] <mup> Bug #1641643 opened: Boostrapping node fails to complete cloud init does to failure of System Logging Service <cdo-qa> <juju-core:New> <https://launchpad.net/bugs/1641643>
[17:13] <redir> 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] <rick_h> redir: the folks managing the store need to help. Uiteam
[18:11] <redir> 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] <perrito666> redir: I know not, sorry :(
[18:11] <redir> perrito666: np, worth asking
[18:12] <katco> redir: i suggest passing that function in as an argument and see what breaks. continue up the stack
[18:13] <redir> katco: yeah that seems to mean passing state down through the hall of abstrat mirrors
[18:13] <katco> redir: no don't pass state. *please* don't do that!
[18:13] <katco> redir: just pass that one function
[18:14] <redir> which is on state
[18:14] <redir> I"ll look
[18:14] <katco> redir: right, but you don't have to pass a reference to state, just the function
[18:14] <katco> redir: remember functions are reified
[18:14] <redir> yeah, just changing untold layers of abstraction
[18:15] <katco> redir: big systems necessitate this to be at all maintainable
[18:15] <redir> yes
[18:16] <katco> 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] <katco> redir: good luck!
[18:22] <redir> thanks katco
[18:24] <voidspace> mgz: if you have a chance, I'd love your comments on my branch
[18:26] <mgz> voidspace: sure thing, will do that now
[19:26] <perrito666> rick_h: perri.to
[19:38] <natefinch> really? We stop people from putting capital letters in their application names?  Geez.
[19:57] <thumper> morning folks
[20:02] <rick_h> morning thumper
[20:02] <thumper> o/
[20:11] <katco> thumper: hey, hope everything is well down there
[20:11] <thumper> fine in Dunedin
[20:11] <thumper> although main highway down the island is shut at the top
[20:11] <thumper> due to slips
[20:11] <thumper> lots of them
[20:11] <thumper> someone said 100000 slips
[20:11] <katco> wow
[20:11] <thumper> big ones will take a long time to clear to make road passable again
[20:12] <thumper> and railway tracks were pushed off their footing, across the road and into the sea
[20:12] <thumper> some cool photos
[20:12] <rick_h> 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] <mup> Bug #1640535: HA tests fail after the leader is deleted <ci> <ha> <regression> <juju:Triaged by rharding> <https://launchpad.net/bugs/1640535>
[20:13] <thumper> hmm...
[20:13] <rick_h> 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] <mup> Bug #1640535: HA tests fail after the leader is deleted <ci> <ha> <regression> <juju:Triaged by rharding> <https://launchpad.net/bugs/1640535>
[20:14] <rick_h> oops
[20:14] <rick_h> dammit, different irc client working different
[20:14]  * rick_h goes to get the boy from school biab
[20:40] <perrito666> jam: are you around?
[20:49] <rick_h> perrito666: midnight there atm and he's on a couple of swap days
[20:49] <rick_h> perrito666: might be best to go async or if there's something someone else can help with
[20:50] <perrito666> rick_h: just a curiosity, I need someone old enough in the project :) and his name was on the code
[20:50] <rick_h> perrito666: gotcha
[21:53] <voidspace> mgz: you still around?
[21:58] <mgz> voidspace: heya
[21:58] <voidspace> mgz: hey, thanks for the review
[21:58] <voidspace> mgz: I'll change that variable name, good call
[21:59] <mgz> the other comment I think there's no change required
[21:59] <voidspace> mgz: but on the encode then replace dance - because only alphanumeric characters are valid for lock names
[21:59] <voidspace> mgz: yeah, I think it's needed
[21:59] <voidspace> mgz: but I agree it's not ideal
[21:59] <voidspace> mgz: anyway, thanks :-)
[21:59] <voidspace> will do it now and land it, so we can get the change into the develop branch
[22:00] <mgz> 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] <voidspace> right
[22:01] <voidspace> and base32 would generate longer strings so we'd chop out more of the hash when we truncate it
[22:01] <voidspace> (40 char limit for lock names)
[22:14] <perrito666> 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] <rick_h> perrito666: you can, but you have to do it as the default to pull and staging is meant to be that
[22:15] <rick_h> 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] <perrito666> rick_h: oh, I was just talking about the papercut when PRing
[22:16] <perrito666> but I guess GH is not That configurable
[22:16] <rick_h> 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] <perrito666> rick_h: correct, I thought it had a "branch to push" and "branch to pull"
[23:19] <babbageclunk> menn0: ping?
[23:19] <menn0> babbageclunk: howdy
[23:20] <babbageclunk> menn0: The logsink endpoint - does the client just keep the websocket open and keep sending logs to it as they come in?
[23:21] <menn0> babbageclunk: simplisticly speaking, yes
[23:21] <babbageclunk> menn0: hmm, except it still gets shut down at migration, right?
[23:21]  * menn0 checks
[23:32] <menn0> babbageclunk: sorry for the delay... a bit of drama here... looking now
[23:33] <babbageclunk> menn0: No worries!
[23:33] <menn0> babbageclunk: so yeah, logsender is shut down during migrations
[23:35] <menn0> babbageclunk: there is a deque which accumulates when the logsender isn't active/connected
[23:36] <babbageclunk> menn0: I've added code to the logsink handler to release the state when the connection finishes, but it's never happening.
[23:39] <menn0> babbageclunk: i'll probably need more context...
[23:41] <babbageclunk> menn0: Might be easier to explain in person!