[00:43] so anyone have any insight as to the recent jump in github stars on juju? [00:44] looks like 200+ in the last couple of days [00:44] also been on the Go trending list [00:46] wallyworld: ^ you notice that yet? [00:47] stokachu: no I haven't but that is good news [00:47] yea it is, im interested to see what drove the traffic [00:47] stokachu: maybe 2.2 beta1 memory fixes enticing people to grab it [00:47] maybe the graphs on there [00:55] well, nate finch did write a blog post [00:55] about juju [00:55] and mentioned it on twitter, and lots of gophers follow him [00:56] and it is the biggest open source Go project [01:12] thumper: I'd say almost certainly nate's blog post, it was on HN front page for a while [01:28] ah [01:28] makes sense [01:31] babbageclunk: standup? [01:32] bugger sorry [02:37] poo [02:37] my state tests have gotten very unreliable [02:37] probably something I did [02:37] but not sure what [02:37] * thumper looks deeper [02:38] so much for "quick fix" [02:49] :( [02:49] * thumper sighs [02:51] see related panic is a big fat lie [02:51] when the panic is in tear down [03:05] yep, definitely something I have done [03:05] but I'm struggling to figure out which change broke it [03:05] :( [03:07] well, the good part is I have a repeatable failing test that I haven't touched [03:07] not directly anyway [03:07] ... [03:07] * thumper thinks he has an idea... [03:11] awesome. we have bootstrap command tests that are "passing", but are completely broken because they're using the wrong gc.C [03:11] * axw head desks [03:13] axw: awesome [03:13] winning [03:13] well, I have isolated my test failure down to something that shouldn't cause a failure [03:13] so that's kinda goodish [03:23] ok... moved a few lines... [03:25] oh fuck... [03:25] think I have found a bug in our state runners code [03:26] particulary the situation when we try to stop workers before they have fully started [03:29] this makes no sense [06:29] wallyworld: can you please review this trivial one: https://github.com/juju/juju/pull/7153 [06:30] sure === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === dpb1_ is now known as dpb1 === akhavr1 is now known as akhavr === lazyPower is now known as lp|Kubecon === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr [21:31] hi, can i get a review of https://github.com/juju/juju/pull/7157 ? [22:36] cmars: i'll take a look [22:36] menn0, thanks [22:54] wallyworld: What's the best way to determine whether a relation is cross-model from inside a RelationUnit? [22:56] babbageclunk: i'd have to look at the code, but in general, you need to see if the other end is a remote application. there's watcher code which does something similar to that as there's a remote relations watcher from memory [22:57] wallyworld: The only way I can see is to go through the endpoints calling RemoteUnit on the unitnames and if it works then it's remote. [22:57] remote unit doesn't mean what you think it does [22:58] wallyworld: ah [22:58] remote unit in this context is the other end of the relation regardless of model [22:58] from a relation unit you get the relation [22:59] from a relation you get the endoints [22:59] you then look to see if the endpoint at the other end has a remote app [22:59] endpoints have applicationname as an attribute [22:59] wallyworld: ok, I'll use that. [22:59] there should be code already to do that sort of thing [22:59] wallyworld: thanks! [23:00] i'll have a look and see if i can dig something up [23:04] babbageclunk: there's no specific code as such that can be reused, but the above is the general approach [23:05] wallyworld: cool - I'll put a IsCrossModel (better name?) method on Relation. [23:05] i think that's ok [23:53] menn0, thumper thanks for the review, updated https://github.com/juju/juju/pull/7157 [23:54] cmars: will look soon