[00:02] thumper: easy one: http://reviews.vapour.ws/r/5658/ [00:03] Bug #1622738 changed: Multi-series charms failing in 1.25.6

[00:12] Bug #1622738 opened: Multi-series charms failing in 1.25.6

[00:21] wallyworld: updated http://reviews.vapour.ws/r/5640/ [00:21] Bug #1622738 changed: Multi-series charms failing in 1.25.6

[00:21] ta, looking [00:21] mup stuttering? [00:27] * redir wonders if that usually happens or if that is a new rocket feature. [00:27] redir: lgtm ty. const also looks nicer separated out from all the text [00:27] wallyworld: tx [00:28] merging and heading out for EoD [00:28] redir: one mup was for opening the bug, the other for changing it [00:28] have fun [00:28] OIC, changed open changed [00:32] wallyworld: Is the --file some.yaml flag only for app config? [00:32] yes [00:32] IIANM [00:32] heh [00:33] tx [00:51] axw: veebers: http://reviews.vapour.ws/r/5659/ [01:00] anastasiamac: thanks, reviewed [01:06] axw: sure, off-the-top-of ur-head, after bootstrap, what's GUI's URL? [01:06] anastasiamac: just run "juju gui" [01:06] axw: tyvm [01:46] veebers: can you let me know when that set-config change is merged? [01:50] wallyworld: for the CI test? It's done now oh wait I'll just update the jenkins machines right now too [01:50] sorry I should have retyped that, but characters are expensive over here <_< [01:50] veebers: awesome, cause a merge job failed because it complained about set-config [01:50] wallyworld: oh? do you have a link? [01:51] http://juju-ci.vapour.ws:8080/job/github-merge-juju/9193/ [01:51] thanks [01:52] wallyworld: sorry that's totally my fault, I merged it all etc. but forgot to update the jenkins machines with the updated code [01:52] The update job is running now [01:52] no worries [01:52] ty [02:12] wallyworld: migration prechecks now use your new MachineStatus helper: http://reviews.vapour.ws/r/5660/ [02:13] great [02:17] menn0: i have a quibble about the message in the down case [02:17] wallyworld: ok [02:18] wallyworld: the message came from the fact that we're checking if the machine agent has StatusStarted [02:19] we call it "started" in status too [02:19] I'll try to think of something [02:19] sure, but consider where it was started and is now down [02:19] down may be transient [02:19] so i think we need to special case that status [02:22] wallyworld: how about I just use the status string directly? "machine 0 agent is down" "machine 0 agent is pending" etc [02:24] wallyworld: actually, that doesn't work for error... "machine 0 agent is error" [02:26] yeah [02:26] wallyworld: I think I'll go with: "machine 0 agent is not functioning (down)" [02:27] or "not functioning at this time" [02:27] wallyworld: hmmm, a tad long but I see where you're going [02:27] just want to convey that it is likely transient [02:28] yeah, fair enough. i'll go with that. [02:29] not functioning, to me, mean broken [02:30] is it just not responding? or not yet made it to a good state? [02:34] natefinch: in this case it could be either [02:34] natefinch: I think "not functioning at this time" covers both reasonably [02:35] natefinch: this is only for the error returned by migration prechecks. juju status will provide more detail. [03:03] wallyworld, thumper: FYI I'm looking at bug 1616531 [03:03] Bug #1616531: "panic: unknown OS for series" when running client on Fedora [03:03] sgtm [03:03] k [04:03] thumper, wallyworld, axw: the client won't work on fedora at all b/c we don't explicitly support it [04:03] ^^^^ this kills me [04:03] but we have Arch support [04:04] what do you think about me changing the support for Arch (which is only supported on the client) to "generic linux" [04:04] ? [04:04] so any linux system which isn't ubuntu or linux uses that [04:04] ? [04:04] yes... please... although why is ubuntu special? [04:05] ubuntu and centos need to be special because we support them server side [04:05] sure, but that's server side [04:05] so we need to know how to interact with package managers etc [04:09] menn0: sorry, had to talk to a roofing man. my roof, my roof, my roof (is not on fire) but needs lots of repairs :-( [04:09] * wallyworld reads backscroll [04:11] maybe I was misunderstanding... we should absolutely be able to run the client on any linux. IIRC, when I was looking at it in December of last year, there's a spurious check in the version package that ensures it understands what series it is running on [04:12] menn0: yeah, so client and server are different for the reasons you say. also, the basis for strictly knowing the series goes back to juju 0.1 when tools were series specific. they sort of still are but don't need to be. the issue though is still bootstrap but there the main problem is matching the arch which I think will be solved by your suggested approach [04:12] natefinch: that's to build the tools [04:12] there's some work to be done to uncouple tools from series [04:13] it's not necessarily a totally trivial exercise but really needs to be done [04:13] wallyworld: IIRC we hit this just running the client on unknown series.. but I could be mistaken [04:13] yes, correct [04:14] the series needs to be known in some circumstances [04:14] i think it may possibly over eager [04:14] in checking for it, but i'd need to look at the code [04:14] it's used to decide on paths [04:14] not sure if that's for good reasons yet [04:14] ah yes, that rings a bell [04:14] it's probably all tied up to when tools had series in the path name [04:14] that code probably only needs to know about the OS [04:15] and we didn;t have simplestreams [04:15] so juju just had to read a directory listing [04:15] and pick tools matching series from the path name [04:15] paths *should* only be OS-specific [04:15] i agree, just explainign the history [04:15] yep [04:15] the assumption was that tools could be different on precise vs trusty [04:16] but IIANM that has never been somthing we have ever done [04:16] we have always shipped the same binary on all *nix etc [04:16] yep [04:16] goes to show how decisions made in juju 0.1 we are still paying for :-) [04:17] in theory you could compile with different versions of go to get different binaries, but they'd still all work on all distros/series [04:17] true [04:17] compile with the most modern/optimised compiler [04:18] so the way I see it there's 3 courses of action for me right now [04:18] 1. add support for Fedora explicitly - pretty dumb but gets us out of the immediate problem [04:18] 2. change the support for Arch to be support for GenericLinux - slightly more work but means the client will work on all Linuxes [04:19] 3. Work out all the places series is used where OS should be and fix them - lots more work and more risky [04:19] I'm thinking [04:19] #2 [04:19] thumper, wallyworld, natefinch: thoughts? [04:20] yeah i think 2 sounds ok. will need careful testing [04:20] #2, but with the addition of removing this line: https://github.com/juju/version/blob/master/version.go#L143 which I think would fix our "Every 6 months juju breaks" problem because the client encounters series it doesn't know about. [04:21] yeah, it breaks if people's distroinfo package is not up to date [04:21] we could remove the need to read the distro info file entirely maybe [04:21] on the client at least [04:22] that would be awesome [04:22] ah wait [04:22] we need the series to parse simplestreams onthe client [04:22] but that may just be to see what tools are needed server side [04:22] sure [04:22] so inother words, there be dragons [04:22] we'll just need to think carefully [04:22] and if you have series = xxxxxxxx then it won't find tools, big deal [04:23] well no tools = no bootstrap [04:23] yes [04:23] but once the tools are in streams bam, bootstrap [04:23] and that's not good [04:23] i thinking about the custom tools case [04:24] anyway, it just needs careful thought and testing to cover all the cases we support [04:25] Bug #1598362 changed: MongoDB replica error in machine-0

[04:25] the local series shouldn't impact what you bootstrap, anyway, IMO. Why would I want my laptop's OS to change what OS juju runs on? [04:26] it used to matter if you compiled tools [04:26] but we can make it not matter. but there's a bunch of code to change [04:26] yeah [04:27] and tests [04:27] that will be the most sucky biyt [04:29] ok, I'll proceed with caution [04:29] will be good to get this fixed though [04:31] Bug #1598362 opened: MongoDB replica error in machine-0

[04:32] menn0: proceed with a large hammer and good protective gear :) [04:39] * wallyworld weeps making changes which affect uniter tests. oh the joy [04:42] wallyworld: opportunity to improve uniter tests? :D [04:42] that would require a week all on its own sadly [04:42] they're not that bad, just fiddly [04:43] they use a DSL, and when one bit breaks, a lot of failures occur [04:45] menn0: I'd keep Arch, and add generic linux [04:46] Bug #1598362 changed: MongoDB replica error in machine-0

[04:46] axw: do we support arch server side? there's some indications that the azure provider does (but maybe I reading that wrong) [04:46] menn0: I wish we used a format that retained OS + version [04:46] err, distro [04:46] menn0: no we don't. I guess we could just replace it and add it back later if we need it [05:25] Bug #1622836 opened: Cannot bootstrap to Google Compute Engine [05:31] Bug #1622836 changed: Cannot bootstrap to Google Compute Engine [05:35] wallyworld: with a very small change I can use the client on fedora [05:35] great [05:35] wallyworld: bootstrap works if I use --agent-version to grab a published version [05:36] wallyworld: but trying to use my own binaries fails to find local tools [05:36] menn0: try hacking the client version to a released version and should shoul dnot need --agent-version either [05:36] that's because it is using rc1 [05:36] as the version [05:36] oh wait [05:36] wallyworld: I thought it could have been something to do with the series being "unknown" [05:37] you have built jujud locally [05:37] yeah, in that case, series will be reported by jujd as "unknown" i think yeah [05:38] i'd have to look into it to be sure [05:39] i've got to stop for now... will keep digging later [05:39] wallyworld: thanks [05:39] i'll look as well [05:40] i just need to finish something [05:41] wallyworld: hey, did you have time to check charm caching issue? should i just file a bug? [05:42] urulama_: the relevant folks know about it; it's been on the radar for a few weeks I found out. there's a meeting tonight to discuss further [05:43] i hope something will be fixed over the next week or so [05:43] not sure if there's a bug already filed === urulama_ is now known as urulama [05:44] wallyworld: kk [05:46] Bug #1622836 opened: Cannot bootstrap on Google Compute Engine [05:50] laters folks [06:07] Bug #1622836 changed: Cannot bootstrap on Google Compute Engine [06:13] Bug #1622836 opened: Cannot bootstrap on Google Compute Engine [06:16] Bug #1622836 changed: Cannot bootstrap on Google Compute Engine

=== frankban|afk is now known as frankban [11:22] voidspace, frobware, fwereade_: anyone fancy a boring mechanical review? http://reviews.vapour.ws/r/5665/ [11:26] babbageclunk: as it touches apiserver is there any impact to other users/clients? [11:28] frobware: Hmm, good question. It doesn't change any of the values, just the names, so I don't think so, but I'll have a closer look. [11:41] babbageclunk, LGTM [11:42] frobware, babbageclunk: re apiserver, indeed, you *can* change type names and field names so long as the serialization doesn't change [11:42] frobware, babbageclunk: but it's easier to say and remember "don't touch apiserver" [11:45] fwereade_: Cool - thanks! [13:58] fwereade: if you have time https://github.com/juju/juju/pull/6231 [14:02] natefinch: ping for standup [14:02] frobware: ping for standup [14:02] rick_h_: ah, yes. omw. [15:44] perrito666, ping [15:44] alexisb: pong [15:44] heya perrito666 [15:44] hey :) how's health? [15:45] wanted to confirm that you were on the critical backup and restore bug: https://bugs.launchpad.net/juju/+bug/1622677 [15:45] Bug #1622677: Agents lost after restore-backup

[15:45] I am feeling better, still sick but functional today [15:45] perrito666, anything blocking you on teh bug above? [15:46] alexisb: nope, running the test now to see if my fix worked :) [15:46] nice :) [15:49] frobware: ping [15:50] frobware: updated https://github.com/juju/juju/pull/6219, now running make check and later will do a live test on maas [15:51] frobware: but I'll appreciate if you test it live locally as well - it shouldn't cause issues for cases where it worked before [15:52] Hmmm, my build's failing in godeps with `cannot create repo: cannot find project root: unrecognized import path "google.golang.org/cloud"` [16:01] dimitern: trying again [16:02] dimitern: btw, I see something similar to brad using the manual provider [16:02] frobware: what's that? [16:03] morning [16:03] dimitern: just chooes lxdbr0 in lieu of all the bridges available [16:04] dimitern: any chance you could try and gently persuade the big data charmers to try the NSS plugin... ? :) [16:04] frobware: sure :) will talk to them [16:04] dimitern: Azure (surprise suprise) is the odd ball [16:05] frobware: yeah - frustrating.. I've read your update re reverse lookups [16:05] dimitern: so even there it's nothing to do with the plugin. you cannot reverse lookup the hosts IP address. [16:06] frobware: oh - at all? that's weird indeed [16:06] dimitern: in your testing are you layering my bridge-tout-le-monde on top of your changes? [16:07] frobware: no, intentionally [16:07] frobware: just tip of master with my PR [16:08] dimitern: OK, I'm going to add the bridge script changes as well [16:08] frobware: one of the nodes is using the same config as CI - eth0 = unconf, eth1 = static [16:09] mgz: would you expect a bootstrapped azure instance to last more than a few hours or are they automatically GC'd? [16:10] frobware: IIRC they are, for the shared account [16:11] dimitern: I thought so too. but, equally, I thought I'd get a least an afternoon. :) [16:12] frobware: :) === frankban is now known as frankban|afk [16:16] frobware: we've had various fun issues with azure cleanup [16:17] mgz: everytime I go back to my azure science experiment... it's all gone away [16:17] but I'm not sure the winazurearm script actually deletes machines [16:17] let me check [16:18] frobware: OLD_MACHINE_AGE is 6, and that's in hours [16:18] so, it shouldn't wipe your stuff before that [16:18] * frobware gives up on lunch [16:19] mgz: in this case it's possible that it has been 6 hours. bootstrapped, got sidetracked... [16:23] frobware: so my PR seems to work fine on maas 1.9 with xenial and trusty nodes - both fullly conf'd and with some unconf'd NICs (mix of vlans and just phys); lxds come up with multiple NICs, as expected [16:23] frobware: make check also passed in the meantime, now testing the same on maas 2.0 [17:29] good god, aliases are annoying to code [18:20] * redir is expecting a power outage in the near future. [18:21] * redir got an SMS that I might experience one from the power company. [18:28] redir: not sure if I would be impressed they're texting me or annoyed they're turning off my power [18:28] redir: probably both :) [18:28] natefinch: agreed [18:29] there was a bunch of beeping (sounded like nearby UPSen) but I haven't lost power yet. So maybe I'm spared [19:12] alexisb: you around? === mwhudson is now known as Guest72628 [19:26] natefinch, I am now [19:26] whats up? [19:33] alexisb: was working on expenses... things seems to have changed some since the last time I submitted them (granted, it was a few months ago). what category do I give to expenses for using cloud services for work? [20:14] easy review: http://reviews.vapour.ws/r/5668/ [20:14] anyone ^ [20:20] redir: whoa, a Get function that didn't return anything? Wacky [20:22] .Get(lost) [20:22] redir: I actually prefer it the old way (except for the get function that doesn't actually get)... but still looks correct [20:23] redir: ship it! [20:23] natefinch: we talked about changing get to ensure and api to client [20:23] but there's a bunch of legacy stuff that isn't broken [20:23] so why fix it [20:23] yep [20:23] intertia wins, this time. [20:24] tx [20:27] redir- I'm looking too [20:29] redir - why cache the client on the command if you're going to pass it into the methods? [20:29] babbageclunk: I wasn't goign to pass it. [20:30] But In the diff you've got a kind of hybrid approach - you're caching it in getApi and then still passing it around. [20:30] babbageclunk: we collapsed 3 commands into one. They share an API in the same command, so why pass it to the three helper functions rather than make it an object member [20:31] Sure - call getApi in Init and store it in c.api? [20:31] babbageclunk: the c.api is for allowing tests to pass in a fake api at test time [20:32] Can the tests set c.api? [20:32] if there's c.api isn't nil the newcommandfortest func has attached one and we use it [20:32] babbageclunk: yes [20:32] Then just setting it directly seems ok [20:32] (Maybe I'm misunderstanding?) [20:33] babbageclunk: https://goo.gl/1AjCqJ is where the test sets the api for testing [20:34] babbageclunk: 2 primary reasons we put it back this way are: it's the way things already to it and returning the client makes it the callers responsibility to call client.Close when done. [20:35] hopefully that made sense [20:37] I don't think clients should have to get the api from one method and pass it in again, just so they can indicate when they're done. Instead they can call a close method on the thing that holds the api. [20:38] otherwise you kind of smear the ownership of api out between the two bits of code. [20:38] babbageclunk: I agree [20:41] Ok cool - sorry to stick my oar in, just got excited by the prospect of an easy review! :) [20:42] hah [20:42] I know what you mean. [20:50] Ha, I got a trophy because my review id was a palindrome! [20:57] marcoceppi_: ping, trying to snap install charm but fails without sudo and sudo gives it to root but not me? === Guest72628 is now known as mwhudson [21:13] menn0: oh look who is on call reviewer today... another one for ya http://reviews.vapour.ws/r/5670/ [21:16] menn0: I was wondering about adding juju/errors to juju/txn [21:16] it doesn't currently use it at all [21:16] thumper: ok, of course. leave it then [21:16] ok [21:24] thumper: rick_h_ created a dup ticket with bug 1623097 [21:24] Bug #1623097: remove juju list-shares [21:24] * menn0 sorts it out [21:25] menn0: oh sorry there [21:25] rick_h_: np. I kept the new one since that's referenced by the work thumper did [21:26] thumper: ship it [21:26] menn0: just doing another with the updated juju/txn [21:26] running the state tests [21:26] thumper: ok [21:26] I figure if they pass (which they should), I don't have to run them all [21:26] I'll push and prep review now [21:28] menn0: http://reviews.vapour.ws/r/5671/ [21:29] thumper: interesting theory regarding the tests :) [21:29] thumper: when I make that assumption I'm usually wrong [21:29] thumper: ship it anyway [21:29] well, the bot still runs them all [21:29] sure [21:29] but this should give me a good check [21:29] the bot usually proves me wrong [21:29] hmm... bot got stuck on one of my other branches [21:30] didn't pick it up again [21:30] thumper: are you using $$merge$$? apparently it's been changed to only accept that [21:31] oh really? [21:31] thumper: that bit me yesterday [21:31] how boring [21:31] I know! [21:31] I didn't [21:31] * menn0 likes being rude to the bot [21:31] used $$intermittent$$ [21:32] yeah, that doesn't work any more === menn0 is now known as menn0-exercise [21:44] thumper: i'm -1 on removing list-shares. show-model is yaml by default. list-shares is a nice tabular output and has a different focus to show-model [21:45] i have found it very useful [21:45] wallyworld: merge is in progress... [21:45] wallyworld: fight with rick_h_ [21:45] i think we really should get input from john etc first [21:45] did you ask him? [21:46] no, was just going through critical bugs on the milestone [21:47] well, that was a mistake IMO :-/ [21:48] wallyworld: seeing if we can stop the merge [21:48] it could well be that it should be removed, but let's get a broader opinion from rick, john etc first. you can say "told you so" [21:48] ok [21:48] I have on strong opinons [21:48] but I do like tabular output of things [21:48] :-) [21:48] over yaml [21:48] how can I get the current cloud/model/region in a command? [21:48] whoami [21:49] ? [21:49] thumper: yeah, that's part of it, the tabular. plus the focused question "who can see/access my model" [21:49] perhaps I should argue more [21:50] yea, rick_h_ fight, I'm -1 on keeping it for just that output format [21:50] it's clear in show-model, does't require us to find a new name for a command that does't fit anythingt [21:50] can't tabular just be a --format [21:51] it's a show-* command [21:51] so it's yaml output [21:51] besides it's an uncapped list [21:51] oh, missed that bit of docs [21:53] but at least it has a --format flag [21:53] just not a tabular option [22:05] * thumper sighs [22:11] thumper: talked to rick. we agree to "juju list-users " [22:11] so give list-users an optional positional arg for modl [22:11] update the bug plz [22:11] will do [22:11] with whatever the resulting discussion was [22:11] so this is a controller command? [22:11] bug number? [22:12] it is now a controller command yes [22:12] i think it can probably stay as one, access the model manager facade [22:12] which is a controller facade [22:13] the output for list-users model vs list-users for controller can stay the same; in both cases show user name, display name, access level, last connected time etc [22:16] wallyworld: https://bugs.launchpad.net/bugs/1623097 [22:16] Bug #1623097: remove juju list-shares