[00:34] thumper, perrito666, redir: Anyone up for a review? https://github.com/juju/juju/pull/6544 [00:49] babbageclunk: someone lookin? [00:50] redir: I think thumper said he would. [00:50] ack [00:50] haha, mistyped that as thumber first [00:51] yeah, I'm looking [01:27] babbageclunk: sorry for the delay [01:27] thumper: no worries [01:27] got myself confused with something in the review [01:27] but all good [01:45] veebers: my build failed due to lack of memory: http://juju-ci.vapour.ws:8080/job/github-merge-juju/9627/console [01:45] veebers: can you give something a kick? Should I just restart the build? [01:48] babbageclunk: let me have a look [01:53] babbageclunk: the issue is there are a bunch of (probably) leaked lxd containers running on that machine, i'm just attempting to clarify what I can kill safely to free up space [02:13] babbageclunk: ok, hopefully I haven't destroyed the universe (just killed a bunch of machines) can you go ahead and !!build!! that PR of yours? It should get through this time [02:16] veebers: Thanks! [02:20] babbageclunk: nw, let me know if you have any other issues [02:40] poo [02:40] something screwy is happening [02:53] thumper: with CI? (he asks after having removed some machines) [03:21] veebers: no, with migration [03:39] babbageclunk: around to be a rubber duck? [03:43] thumper: sure - actually I could use a rubber duck in turn [03:44] ok, 1:1 HO? [10:20] Bug #1640113 opened: In LXD machines in localdomain not resolvable [10:34] uhm, i just deployed wordpress+mysql on one machine and haproxy on another then BOOM it deployed 15 machines all of a sudden on aws [10:34] i have no idea how that happened [11:04] morning all [11:43] mgz: is http://juju-ci.vapour.ws:8080/job/github-merge-develop-to-staging/ really the merge develop to staging job? [11:43] * dooferlad has a conflict I can't resolve because develop hasn't merged back into staging [12:25] dooferlad: that should be it [12:35] dooferlad: if you want to actually land your branch you'll need to merge the conflicting change from staging into it to resolve (or rebase on later change) [15:08] voidspace: can you join the other #juju please and help someone out? [15:08] rick_h: #juju on canonical? [15:08] voidspace: yes please [15:08] rick_h: in standup now, but will take a look as well [15:08] K [15:11] rick_h: standup? [15:12] natefinch: can't ATM. About to give a lightening talk. [15:12] rick_h: kk [15:12] Phone irc'ing while in line [15:12] ahh [15:26] Is there a reason why action names can't include numbers, i.e., an action named iperf3 will throw a "ERROR bad action name iperf3" when trying to deploy/upgrade the charm. [15:34] at the moment my girl is at "science club" on Tuesdays, so I can stay for the whole of standup [15:35] just FYI [15:35] and I have a hospital appointment tomorrow morning [15:36] science club sounds fun [15:38] mgz: only her second one today, they made a dinosaur tooth last week but she really wants explosions which they have been promised at some point by "Atomic Tom" who takes it... [15:39] ehehe, in it for the bangs [15:39] always [15:39] :-) [15:40] katco: o/ [15:47] uhm, nope, my hospital appointment is Thursday morning [15:48] perrito666: can you answer aisrael's question about actions? [15:48] aisrael: I suspect the answer maybe "no good reason"... Can you file a bug about it? [15:49] AFAIK, no good reason [15:49] var actionNameRule = regexp.MustCompile("^[a-z](?:[a-z-]*[a-z])?$") [15:49] voidspace: Yep, I'll do that. I figured if it was for a reason, the docs/charm tools need to be updated to reflect it. [15:49] aisrael: yep [15:49] aisrael: natefinch: looks easy to fix then... [15:50] voidspace: natefinch: excellent, thanks. Filing a bug now. [15:50] assuming there is no good reason [15:50] aisrael: if we find a reason we'll let you know :-D [16:18] voidspace: no, I dont know why that is [16:38] voidspace: do you know why we have a networking interface defined for vsphere? https://bugs.launchpad.net/juju/+bug/1638401 exists because provider/vsphere/environ_network.go exists [16:38] Bug #1638401: vsphere: spaces spams the logs with an error [16:39] dooferlad: that was done by third party so they might have just cargo culted [16:39] perrito666: ah, thanks [16:57] dooferlad: no, no idea [16:58] voidspace: no worries, the question was answered by perrito666. [16:58] dooferlad: cool :-) [17:07] bbl relocation [19:11] * redir steps out to vote and grab lunch on the way back. [19:32] bbl [20:20] o/ babbageclunk [20:21] morning thumper! [20:22] exciting day today [20:23] back [20:23] seeing this when bootstraping an LXD controller: ERROR juju.state database.go:231 using unknown collection "remoteApplications" [20:23] any ideas? [20:24] 2.0.1-xenial-amd64 [20:25] babbageclunk: terrifying day you mean? [20:25] babbageclunk: I worked out how to work around the bug in migrations to finish QAing my branch [20:25] thumper: yes, that [20:25] thumper: oh, nice! [20:25] so doing that now [20:26] thumper: I think I worked out an approach to sharing some of the code in logsink, trying it out. [20:28] SimonKLB: oh, that looks like a bug, what bootstrap command did you use? [20:30] perrito666: just `juju bootstrap localhost a-name` [20:31] i saw this: https://bugs.launchpad.net/juju/cross-model-relations/+bug/1634956 [20:31] Bug #1634956: unknown remoteApplications on deploy [20:31] but in my case it was right away after the controller was installed [20:31] i didnt deploy anything [20:32] SimonKLB: I see, I believe we can work around this bug by setting a flag, let me look for it [20:33] * redir back [20:35] babbageclunk: hazaar, have now confirmed it works [20:47] SimonKLB: JUJU_DEV_FEATURE_FLAGS=cross-model [20:49] perrito666: great, thanks! i realized why i saw it early btw, it shows up when i run juju status [21:16] babbageclunk: https://github.com/juju/juju/pull/6548 [21:17] thumper: ooh, longish - let me finish the thought I'm sketching out then I'll review yours. [21:18] babbageclunk: ta === beisner- is now known as beisner [22:13] thumper: Sorry, got a bit caught up in the weeds there. Can you look at this https://github.com/juju/juju/commit/eafd1f8286d4898907bf826af12c8512b1e76f8a and tell me what you think of the approach? [22:13] thumper: reviewing your PR now [22:13] ok [22:14] babbageclunk: where should I comment? [22:16] thumper: not sure. On the commit? Or here is fine. === hml_ is now known as hml [22:19] newStrategy as a member of logSinkHandler seems weird, dbStrategy ? [22:19] is it always a db strategy? [22:21] Well, it's a func that makes a strategy (because the strategy is stateful). [22:21] ugh.... [22:21] it is doing two things, and I think it should do one [22:22] thumper: it's always a db strategy, but it also has an opinion about the log file prefix. [22:22] should be a dbStrategy and a fileStrategy [22:22] I don't think the migration logs should be put into the same file as the logsink file [22:22] thumper: no, they wouldn't - I'd expect that we'd give it a different directory [22:23] hmm... [22:23] like what? [22:25] I guess it depends how we want the migrated logs to look after the migration is finished. [22:25] Should they be in the same places they would've been on the source controller machine? [22:26] Or is it ok to have them mashed in to one place? Basically I haven't thought about the file side of it. [22:27] the logsink file is really just a backup of the logs that the controller has received [22:28] not normally meant for user consumption [22:28] Right - so we mostly care about the DB logs then? [22:28] much more, yes [22:29] ok [22:29] I'm just thinking about how much we care about migration logs on the disk of the controller [22:29] problem is that it won't get rolled [22:29] unlikely to be too big, but you never know [22:29] and how many we may have on any particular controller [22:29] True - it could be big, although it's not growing. [22:30] * thumper nods [22:32] A different file prefix sounds alright to start with then. [22:33] yeah [22:33] Also, these are model logs - I was thinking about controller logs, which have much more in them, right? [22:34] true [22:34] although I have been talking with menno about how to make the models have the apiserver logs for that model [22:34] so, small for now [22:43] thumper: yo, you wanted a repo bot-managed? [22:44] it already is [22:44] so no worries [22:51] thumper: oops, misunderstood what fileprefix was doing there - I thought it was a filename prefix, not a log line prefix [22:54] thumper: In that case maybe I move all of the logging into the strategy, as well as the version number parsing. [22:54] * thumper nods [22:55] thumper: not at all attached to the name strategy, by the way, if you can think of something better - just picked something so I could try it. [22:55] thumper: as in, someone did it yesterday, or we'd done it before and forgot? [23:20] thumper: reviewd [23:20] e