[00:01] Bug #1575403 changed: juju2: juju deploy --to and -n not usable together?

[00:18] cherylj: https://github.com/juju/juju/pull/5297 [00:37] Bug #1575983 opened: Having 2 machine-0 is confusing [00:40] Bug #1575983 changed: Having 2 machine-0 is confusing [00:49] Bug #1575983 opened: Having 2 machine-0 is confusing [00:50] menn0: https://github.com/juju/juju/pull/5297 [00:50] do you have a sec for a small review of a blocker [00:50] davecheney: give me 2 minutes [00:56] davecheney: looking now [00:59] davecheney: LGTM [01:03] davecheney, axw: I have no real issue with the change but I don't understand why there was a data race to begin with [01:03] can you explain it? [01:04] menn0: only if Stdout==Stderr exactly will cmd/exec guarantee that only one goroutine writes to one at a time [01:04] (I wondered too) [01:06] davecheney, axw: in that case, would this be a better solution? http://paste.ubuntu.com/16090295/ [01:06] then we don't lose the interleaving of stdout and stderr [01:07] that assumes there's no stderr in the success case... which probably should always be true [01:07] * axw shrugs [01:07] just use CombinedOutput in that case then [01:08] true [01:09] whatever... it's a minor thing and I guess there is the risk that there might be something on stderr for the success case [01:09] davecheney, axw: just leave it [01:18] wallyworld: cherylj: whomever... http://reviews.vapour.ws/r/4724/ [01:18] looking [01:26] menn0: interlieving of stdout/stderr is undefined [01:26] it'll make the test brittle [01:26] menn0: there is a data race becase var both bytes.Buffer is being written by two writers [01:26] menn0: but we're not looking for stderr, we're looking for stdout, which is the juju version [01:26] the code cannot cope with anything on stderrr [01:27] the code cannot cope with anything on stderr [01:28] davecheney: all good. your change avoids any unnecessary complexity. [01:32] menn0: fwiw i wish the test wasn't written like that [01:32] the test is written to cope with the fact that the mock exec.Command is weak [01:37] redir: i have some suggestions which had been on my mind before but which I've now enumerated in the review. happy to discuss [01:48] axw: thanks for the review. a few things: [01:48] the calls are bulk on the server side [01:49] they're just not on the client side [01:49] menn0: ah, didn't look properly, sorry [01:50] regarding passing tags, instead of machine or unit ids ... i'm fine with that [01:50] the client will have to have the logic to figure out which is which but that's fine === natefinch-afk is now known as natefinch [01:51] menn0: yeah, my only concern with it is that the client would have to be updated to handle new entities. but I think that's never going to happen, or only extremely rarely [01:52] I considered lumping the addresses together but the concept of a preferred private and public addresses is baked right into the machine docs [01:52] also, if they're returned together then the client needs to figure out which one to use [01:52] maybe that's a good thing [01:53] davecheney, menn0: sorry for the crappy code/test [01:53] but it would be quite a change to the current commands [01:53] axw: ^^ [01:53] menn0: OK, forget about that for now then [01:53] menn0: thanks [01:54] axw: I agree the current approach isn't ideal [01:54] natefinch: it's ok [01:54] axw: esp when there's mixed IPv4/6 deployments [01:54] it's not that crappy [01:54] patchvalue comes with it's own costs [01:55] axw: I'll just make the calls take tags instead of raw ids for now [01:55] menn0: SGTM, thanks [02:20] Bug #1575983 changed: Having 2 machine-0 is confusing [02:20] Bug #1576003 opened: Juju 2.0: default bootstrap-timeout insufficient for physical machines [02:29] wallyworld: got a minute to discuss? [02:29] sure [02:29] tanzanite? [02:29] standup hangout [02:29] there [02:55] axw: can you let me know when you have 5 mins? [02:55] wallyworld: I have 5 mins [02:55] maybe even more [02:55] axw: standup ho [04:23] Bug #1576021 opened: 1.25.6 cannot deploy on CI maas 1.9 or 1.8

[08:21] dimitern: FYI, http://reviews.vapour.ws/r/4625/diff/3-4/ -- see comments for an alternative method of filtering instances in ec2 [08:21] axw: thanks! looking [08:23] ping [08:24] axw: I was thinking about using client-token like this, but decided to go with a simpler approach for now - adapting the group-based selection [08:24] dimitern: okey dokey [08:25] frobware: was that for me? [08:29] axw: can you expand on this: The only danger is if we need to make non-idempotent calls to RunInstances for the machine ID ? [08:30] dimitern, heh, nope. off-by-1. :) [08:30] ha :) [08:30] dimitern: if provisioning fails, then you do "juju retry-provisioning", then we will call StartInstances again. if we use a predictable ClientToken, then the result of StartInstances should always be the same [08:31] voidspace: so do you want to propose your kflavor/mount_point fix instead? [08:31] babbageclunk: https://github.com/juju/gomaasapi/pull/49 [08:31] dimitern: that would be fine if RunInstances is always called with exactly the same args [08:31] (for a given machine) [08:31] babbageclunk: I'm doing mount_point / filesystem as a separate branch as it's a bit more involved [08:31] dimitern: https://github.com/juju/gomaasapi/pull/49 [08:32] babbageclunk: dimitern: as it's a critical juju bug we'll also need to propose juju PR bumping gomaasapi [08:33] voidspace: I'll get on with the constraint schema change - it's also a bit more involved, means changing the gomaasapi interfaces. [08:33] dimitern, voidspace, babbageclunk, dooferlad, jam: would appreciate a review for http://reviews.vapour.ws/r/4722/ [08:33] axw: agreed, as the API docs say "A client token is valid for at least 24 hours after the termination of the instance" [08:34] babbageclunk: this is a separate issue - the problem with space / storage constraints? [08:34] voidspace: yup [08:34] voidspace, frobware: looking at both [08:35] thanks [08:35] frobware: looking now [08:35] dimitern: also, at some point I want retry-provisioning to be replaced with automatic retries. so any potential problem would be exasperated. I don't *think* there's any problem, but also don't want to change it this close to RC :) [08:37] dimitern, voidspace, babbageclunk, dooferlad: might not be in standup. expecting Lenovo engineer to turn up with parts to fix my latop. [08:38] frobware: ok [08:38] frobware: no standup today btw [08:39] oh yeah - big meeting at 11 instead? [08:39] dimitern, ah, ok. was on autopilot [08:40] axw: it should like a daunting task to do that generically for all providers, and idempotently as well (at juju-level, possibly relying on cloud-specific features underneath, like client-token) [08:41] s/should like/sure looks like/ [08:43] dimitern: babbageclunk: corresponding juju PR: https://github.com/juju/juju/pull/5301 [08:43] dimitern: I don't think it's *that* hard, and we don't need to have the the idempotent provisioning if we reap unknown instances. but I'm sure I'll find gotchas if/when I do it :) [08:44] axw: hopefully in 2.1 or 2.2 :) [08:44] voidspace: that one also LGTM [08:49] dimitern: ta [08:50] frobware: I just reviewed http://reviews.vapour.ws/r/4722/ [08:52] mgz: did you file a bug for the filesystem issue? [08:53] jam, thanks [09:02] mgz: so the schema for partition can already handle filesystem being null [09:02] frobware: reviewed [09:02] mgz: so it's just mount_point and label need to be optional [09:05] mgz: the output you sent me - was that blockdevices? http://paste.ubuntu.com/16085749/ [09:05] some of those have no partitions but a top-level filesystem, which we don't expose anyway [09:05] hmmm... that may bite us in the future [09:05] we'll see [09:15] jam, dimitern: you both had comments about parsing the file and whitspace and trim, et al. I was treating this as a machine generated file - how far and how robust should we try to be? [09:17] frobware: I'm ok with assuming that, but when the format changes even a little, we might fail unpredictably (even silently), so more logging should help [09:19] frobware: even a single extra space before e.g. ` #LXD_IPV4_ADDR="0.1.2.0/24"` [09:34] mgz: I found https://bugs.launchpad.net/juju-core/+bug/1575808 - which answers my questions [09:34] Bug #1575808: filesystem 2.0 schema check failed: mount_point: expected string, got nothing

[09:41] dimitern: frobware: babbageclunk: https://github.com/juju/gomaasapi/pull/50 [09:44] voidspace: LGTM +2 suggestions [09:45] dimitern: without the ok check it panics [09:46] voidspace: it panics, after the schema was coerced ? [09:46] dimitern: ah, you mean still use the two value form of the cast but ignore ok [09:46] yeah [09:46] dimitern: yep - because nil is a valid option [09:46] dimitern: and you can't cast nil to a string... [09:47] dimitern: your suggestion works [09:47] voidspace: no, it's already verified to be a string at that point [09:47] dimitern: nope, string or nil [09:47] but this works [09:47] value, _ := thing.(string) [09:47] voidspace: yeah, but (string) with ignored ok will yield "" for a nil value [09:48] dimitern: yes [09:48] dimitern: the single value form of the cast panics [09:48] not the double value form [09:48] dimitern: so thank you [09:48] voidspace: ta [09:49] dimitern: updated [09:49] hmmm, no [09:50] *now* updated [09:55] voidspace: looking [09:55] dimitern: too late [09:55] babbageclunk: fair question btw - I've replied with some examples [09:55] voidspace: thanks :) [09:57] dimitern: frobware: babbageclunk: https://github.com/juju/juju/pull/5302 [09:58] dimitern: thanks [09:58] voidspace: you're on fire today :D [09:58] nice! [09:58] dimitern: easy ones I can do... [09:58] heh [10:04] wallyworld anastasiamac_: team meeting? [10:05] dimitern: ^^ [10:06] Bug #1576120 opened: "juju kill-controller" removes controllers.yaml entry even if destroying fails [10:11] I won't make it to the team meeting :/ [11:09] axw: was at soccer [11:17] axw: could you please take a look at a quick fix for macaroon login that we need in the GUI for next beta? https://github.com/juju/juju/pull/5305 [11:40] frankban: sorry was afk, reviewed now [11:44] wallyworld: you gave mattyw's branch a shipit, but I don't think we should be ignoring errors ... [11:44] I mean it's not ignored, but we should surely be checking for specific types of errors [11:45] axw: at that point, the controller name is either invalid or not found so we exit. i think that's the right thing to do? [11:45] the type of error doesn't really matter [11:46] wallyworld: you might fail to read the controllers.yaml file? or the cross-process mutex fails? [11:46] axw: right, but what can be done besides exiting with an error? [11:47] wallyworld: that's exactly what we should do [11:47] that's what i thoguht we did, i may have misread the change [11:47] wallyworld: except in the case where the controller just wasn't found [11:47] wallyworld: ah [11:47] wallyworld: no, it's me that's doing the misreading :) [11:47] whew [11:48] wallyworld: I looked at the diff back-to-front [11:48] i *almost* did the same thing :-) [11:48] sorry! [11:48] np :) [12:18] Bug #1576184 opened: "juju create-backup" fails if you're not operating on the admin model [12:30] Bug #1576184 changed: "juju create-backup" fails if you're not operating on the admin model [12:36] axw: ty! [12:37] Bug #1576184 opened: "juju create-backup" fails if you're not operating on the admin model [12:40] voidspace, dimitern, frobware: change for constraint parsing here: https://github.com/juju/gomaasapi/pull/51 [12:41] babbageclunk: looking [12:43] babbageclunk: I think it will be a lot nicer, if we used the schema to process the constraintsMap [12:43] babbageclunk: e.g. like when deserializing a vlan embedded into a subnet [12:43] other than that it looks alright to me [12:44] relatively straightforward [12:44] I don't think it's that clunky, but if you can do as dimitern says then it sounds better [12:44] dimitern: ok - I'll look at that [12:46] babbageclunk: basically, define a getConstraintsMapDeserializationFunc and the related constraintsMapDeserializationFuncs map with twoDotOh: constraints_map_2_0 (ugh! I really don't like underscores in go code :( btw but I'd rather have consistency with pre-existing code) [12:47] dimitern: Right, so put a StringMap(Any) for each of them, and then a separate function for each that does another checker.Coerce call? Sounds like it's worth a go. [12:48] babbageclunk: that as well, yeah [12:48] dimitern: ok - something that takes an interface{} and returns a nice map[string][]int would be a huge improvement. [12:49] babbageclunk: see for example how (the lot more complicated) interface_set is handled in machine_2_0 [12:51] dimitern: I don't want to go back through the version dispatch though - I'm just going to make a function and call that directly. [12:52] babbageclunk: ignoring the API version sounds like a bad idea - esp. if the response format differs [12:53] babbageclunk: a much simpler (alas inconsistent) way will be to define a struct with JSON serialization tags for the map and its keys [12:54] dimitern: Oh, I thought this was down-stack from a machine_2_0 function, but you're right. [12:54] babbageclunk: (inconsistent with the other code I mean) [12:54] babbageclunk: look at how devices or interfaces are handled in the 1.0 code in provider/maas/ (before the changes to gomaasapi) [12:55] dimitern: yeah, I don't really understand why this code didn't use the builtin JSON serialisation tags. [12:55] babbageclunk: me too (fwiw) :) [12:56] babbageclunk: but I guess the schema is the sexy new thing everybody should use everywhere now :) [12:57] dimitern: it's ok, but it doesn't much help with the type system stepping all over everything. [12:58] babbageclunk: going with the struct(s)+json tags will be a lot cleaner to do for such a simple map format, and since it will be in gomaasapi no need to jump through hoops like in provider/maas/interfaces.go (e.g. serialize to JSON only to get the []byte blob and deserialize it via the struct) [12:59] dimitern: yeah, but I probably should try to keep it consistent. [13:00] babbageclunk: here's a trick: just put all that in a separate file :) inconsistency less obvious [13:19] morning [13:33] dimitern, voidspace: put up a tweaked version that just pulls out the common conversion code === babbageclunk is now known as babbageclunk|afk [13:34] * babbageclunk|afk goes for a run. [14:41] jam: ping [14:43] babblooking [14:50] voidspace, dimitern: any objections to me merging https://github.com/juju/gomaasapi/pull/51 [14:50] babbageclunk: sorry, got distracted, will have a look now quickly [14:50] dimitern: thanks! [14:53] babbageclunk: LLLGTM [14:53] uhm, or something like that [14:53] :) [14:54] babbageclunk: so I assume there's a follow-up in juju coming to use this [14:54] babbageclunk: it could be a bit simpler, considering the "storage" and "interfaces" are both validated to be maps with string keys and []int values [14:55] babbageclunk: what will happen if you type-assert to map[string]map[string][]int instead on line 826 in controller.go? [14:57] babbageclunk: if it works, then convertConstraintMatches becomes unnecessary and you could just iterate over the nested map for both top-level keys [14:57] dimitern: I couldn't get that to work - the values actually have interface objects in them, so they need to be visited to unpack them. [14:59] babbageclunk: you can still type assert the nested maps - e.g. https://play.golang.org/p/D2cz2Af4vE [15:00] babbageclunk: but I'm OK with landing this as is and possibly trying a bit simpler approach in a follow-up [15:00] (and the follow-up itself doesn't have to be done today) [15:00] :) [15:01] dimitern: I think the problem is that you can't do the next level down - https://play.golang.org/p/0jmajp13vl [15:03] voidspace, babbageclunk nicely done on the bugs reported by CI for maas 2.0 [15:03] dimitern: so you can't do the full cast on line 826, you have to walk through the key/values converting the interface{}s to []interface{} [15:04] dimitern: and then walk through those turning the leaf interface{}s into ints. [15:04] alexisb: thanks! [15:04] ericsnow: standup time [15:05] dimitern: (at least, that's what I think - I'd be happy to have that code be simpler!) [15:08] babbageclunk: you can go as deep as you want: https://play.golang.org/p/UmVNx8N8tu [15:10] babbageclunk: but as I said, as long as it fixes the bug let's land it, and improve upon it when we have some spare time [15:10] dimitern: Right, but that's essentially what I had in https://github.com/juju/gomaasapi/pull/51/commits/61b3b97003699be0c103f21cb26e7fb924d19b4b [15:10] Bug #1570796 changed: container startup issue when juju network management disabled [15:10] Bug #1576266 opened: apiclientSuite.SetUpTest fails because no tools available

[15:10] Bug #1576270 opened: 'juju create-backup' fails first on a mongodump dependency then auth failure

[15:11] dimitern: the casting is all interspersed with the matching devices and interfaces. [15:11] dimitern: anyway, thanks! [15:11] dimitern: :) [15:12] babbageclunk: that looks better, yeah - remember the schema gives us some confidence to do e.g. matchMap := source.(map[string][]int) directly [15:14] except that panics - it complains that the actual value is a map[string]interface{} (even though all of the interface{}s actually hold []interface{}s and all of them have ints). [15:17] babbageclunk: anyway, it was an interesting exercise I guess :) [15:18] dimitern: yup yup - thanks! [15:47] alexisb: filing bugs in juju core, launchpad or github? [15:47] if launchpad shouldn't we disable the github issues tracker? [15:47] jcastro, launchpad [15:47] jcastro: we've talked about that a bnuch [15:48] jcastro, we have discussed disabling it [15:48] we need to make it obvious then, I just realized I've been filing bugs in the wrong place [15:48] and I work here [15:48] our current policy is that we open launchpad bugs for folks [15:51] voidspace, dimitern, frobware: review? http://reviews.vapour.ws/r/4733/ [15:51] this is the other side of my gomaasapi constraint change. [15:51] code review anyone? https://github.com/juju/utils/pull/208 [15:51] very short and sweet [15:54] babbageclunk: did you try this live against MAAS2 ? [15:54] dimitern: ooh, no - thanks for reminding me! That was what lead me down this crazy rabbithole in the first place! [15:55] babbageclunk: :) ok [15:55] Bug #1576295 opened: add-credential input field should support tab completion [16:15] dimitern: hmm. So I can add a machine using --constraints spaces=private, and it picks the right machine and starts deploying..., but the machine never comes up [16:16] babbageclunk: how are the machine NICs configured? [16:16] dimitern: it's running, but juju says pending. I can't ssh in by juju ssh or directly. [16:16] babbageclunk: it doesn't let you in or it doesn't connect ? [16:17] babbageclunk: if EPERM, try ssh -i ~/.local/share/juju/ssh/juju_id_rsa.pub ubuntu@ [16:19] dimitern: network looks like this http://pastebin.ubuntu.com/16098886/ [16:20] dimitern: juju ssh just hangs [16:21] dimitern: I tried ssh with the key, that says: Connection closed by 192.168.150.4 [16:21] babbageclunk: I suspect the DHCP primary is the reason for this [16:21] dimitern: any way to log in on the terminal? Probably no default password for ubuntu user, right? [16:21] dimitern: ok [16:22] babbageclunk: I've never tried that and maas docs are not quite clear what does it mean (it's not the same as Auto) [16:22] Bug #1576301 opened: Cryptic error message if Juju uses the wrong json file from GCE [16:22] babbageclunk: you can hack the userdata juju passes to maas to include setting the password (or removing it) [16:22] Bug #1576313 opened: windows: uniter tests fail because logs get dumped to stderr [16:25] dimitern: ok, so I released the machine, but I can't remove it in juju - just stays in pending. [16:25] babbageclunk: remove-machine # --force [16:26] dimitern: I tried that - it looks like it timed out on its own eventually [16:26] dimitern: ok, so I've changed it from DHCP to auto? Try again? [16:26] dimitern: Or should I try deploying it in MAAS and making sure I can ssh to it as I'd expect? [16:27] babbageclunk: either auto or static should work (that's true for all types of NICs) [16:27] babbageclunk: well, that's also an option if you're not sure juju does the right thing [16:28] babbageclunk: but as you explain it, it looks like juju did good, maas didn't [16:28] there's still a LOT maas can do to improve the UX around misconfigured nodes, networks, images, .. [16:28] ericsnow: MR OCR, can you check out my patch? it's 31 lines, half of that is comments. https://github.com/juju/utils/pull/208 [16:29] bogdanteleaga: new bug is very like fixed bug 1470601 [16:30] Bug #1470601: UniterSuite.TestLeadership fails on windows

[16:30] natefinch: sure [16:30] babbageclunk: re cloud-init and ubuntu password: http://blog.scottlowe.org/2015/11/09/changing-passwords-cloud-init/ (you can hack provider/maas/ where it creates a cloudinit config; alternatively, in maas you can add it to the custom preseed scripts used for deployments) [16:31] dimitern: I'm getting "Unable to allocate static IP due to address exhaustion." - I think my DHCP covers the whole subnet [16:32] dimitern: where can I adjust the range? I can't find it. [16:33] dimitern: Do I need to delete and re-add the subnet? [16:35] dimitern: ah, found it - on the VLAN [16:35] mgz, yeah, I think what we talked about earlier is happening, the fix to that bug was to create a reg key that just happened to stick around [16:36] bogdanteleaga: heh [16:36] babbageclunk: no need to remove the subnet, adjust the range [16:37] dimitern: I can't see how to do that - I can either provide DHCP or disable it, but they never give me the option to adjust the range. [16:38] babbageclunk: have a look at the subnet in the ui [16:38] babbageclunk: you should see a bunch of used addresses at the end [16:39] babbageclunk: and there are also the CLI commands for iprange(s) that control what's reserved, etc. [16:40] babbageclunk: but I haven't actually tried (I did poke around in the postgres db directly though with maas-region --dbshell :) [16:42] babbageclunk: `sudo maas-region dbshell -i` - it's the familiar django dbshell (running psql) [16:43] natefinch: ship-it [16:44] ericsnow: thanks! [16:52] Bug #1576324 opened: Juju2.0 commandline client inconsistent treatment of yaml files

[16:55] Bug #1576324 changed: Juju2.0 commandline client inconsistent treatment of yaml files

[16:59] dimitern: hmm. I shouldn't have deleted that subnet while it was in use, I don't think. [16:59] dimitern: I think I might need to reinstall MAAS tomorrow. [17:01] babbageclunk: sounds good (after a few times it becomes always second nature :) [17:01] s/always/almost/ [17:02] Bug #1576324 opened: Juju2.0 commandline client inconsistent treatment of yaml files

[17:02] dimitern: Sometimes taking off and nuking the site from orbit really *is* the only way to be sure! [17:36] anyone know if there's a way to list what models are stored locally? [17:37] rogpeppe: what models or what controllers? [17:37] cherylj: what models [17:37] cherylj: all the models i can juju switch to [17:38] rogpeppe: well, all the models locally won't necessarily be all the ones you can switch to [17:38] hmm [17:38] cherylj: ah, switch allows you to switch to remotely held models too? [17:38] actually [17:38] yeah, you could be granted access to a model [17:38] and it wouldn't be in your local cache [17:39] cherylj: juju switch will automatically go and grab a model into the local cache? [17:39] there's a way you can list models you have access to for a paricular controller [17:39] juju list-models will limit it to ones you have access to [17:39] (unless you're an admin and use the whatever all-models flag) [17:40] cherylj: but there's no way to find out what models i have cached locally? [17:40] rogpeppe: I'm not sure if the model info will be stored locally [17:40]