| mup | Bug #1575403 changed: juju2: juju deploy --to and -n not usable together? <landscape> <juju-core:Invalid> <https://launchpad.net/bugs/1575403> | 00:01 |
|---|---|---|
| davecheney | cherylj: https://github.com/juju/juju/pull/5297 | 00:18 |
| mup | Bug #1575983 opened: Having 2 machine-0 is confusing <juju-core:New> <https://launchpad.net/bugs/1575983> | 00:37 |
| mup | Bug #1575983 changed: Having 2 machine-0 is confusing <juju-core:New> <https://launchpad.net/bugs/1575983> | 00:40 |
| mup | Bug #1575983 opened: Having 2 machine-0 is confusing <juju-core:New> <https://launchpad.net/bugs/1575983> | 00:49 |
| davecheney | menn0: https://github.com/juju/juju/pull/5297 | 00:50 |
| davecheney | do you have a sec for a small review of a blocker | 00:50 |
| menn0 | davecheney: give me 2 minutes | 00:50 |
| menn0 | davecheney: looking now | 00:56 |
| axw | davecheney: LGTM | 00:59 |
| menn0 | 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 |
| menn0 | can you explain it? | 01:03 |
| axw | menn0: only if Stdout==Stderr exactly will cmd/exec guarantee that only one goroutine writes to one at a time | 01:04 |
| axw | (I wondered too) | 01:04 |
| menn0 | davecheney, axw: in that case, would this be a better solution? http://paste.ubuntu.com/16090295/ | 01:06 |
| menn0 | then we don't lose the interleaving of stdout and stderr | 01:06 |
| axw | that assumes there's no stderr in the success case... which probably should always be true | 01:07 |
| * axw shrugs | 01:07 | |
| axw | just use CombinedOutput in that case then | 01:07 |
| menn0 | true | 01:08 |
| menn0 | 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 |
| menn0 | davecheney, axw: just leave it | 01:09 |
| redir | wallyworld: cherylj: whomever... http://reviews.vapour.ws/r/4724/ | 01:18 |
| wallyworld | looking | 01:18 |
| davecheney | menn0: interlieving of stdout/stderr is undefined | 01:26 |
| davecheney | it'll make the test brittle | 01:26 |
| davecheney | menn0: there is a data race becase var both bytes.Buffer is being written by two writers | 01:26 |
| davecheney | menn0: but we're not looking for stderr, we're looking for stdout, which is the juju version | 01:26 |
| davecheney | the code cannot cope with anything on stderrr | 01:26 |
| davecheney | the code cannot cope with anything on stderr | 01:27 |
| menn0 | davecheney: all good. your change avoids any unnecessary complexity. | 01:28 |
| davecheney | menn0: fwiw i wish the test wasn't written like that | 01:32 |
| davecheney | the test is written to cope with the fact that the mock exec.Command is weak | 01:32 |
| wallyworld | 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:37 |
| menn0 | axw: thanks for the review. a few things: | 01:48 |
| menn0 | the calls are bulk on the server side | 01:48 |
| menn0 | they're just not on the client side | 01:49 |
| axw | menn0: ah, didn't look properly, sorry | 01:49 |
| menn0 | regarding passing tags, instead of machine or unit ids ... i'm fine with that | 01:50 |
| menn0 | the client will have to have the logic to figure out which is which but that's fine | 01:50 |
| === natefinch-afk is now known as natefinch | ||
| axw | 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:51 |
| menn0 | 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 |
| menn0 | also, if they're returned together then the client needs to figure out which one to use | 01:52 |
| menn0 | maybe that's a good thing | 01:52 |
| natefinch | davecheney, menn0: sorry for the crappy code/test | 01:53 |
| menn0 | but it would be quite a change to the current commands | 01:53 |
| menn0 | axw: ^^ | 01:53 |
| axw | menn0: OK, forget about that for now then | 01:53 |
| axw | menn0: thanks | 01:53 |
| menn0 | axw: I agree the current approach isn't ideal | 01:54 |
| davecheney | natefinch: it's ok | 01:54 |
| menn0 | axw: esp when there's mixed IPv4/6 deployments | 01:54 |
| davecheney | it's not that crappy | 01:54 |
| davecheney | patchvalue comes with it's own costs | 01:54 |
| menn0 | axw: I'll just make the calls take tags instead of raw ids for now | 01:55 |
| axw | menn0: SGTM, thanks | 01:55 |
| mup | Bug #1575983 changed: Having 2 machine-0 is confusing <juju-core:Invalid> <https://launchpad.net/bugs/1575983> | 02:20 |
| mup | Bug #1576003 opened: Juju 2.0: default bootstrap-timeout insufficient for physical machines <juju-core:New> <https://launchpad.net/bugs/1576003> | 02:20 |
| redir_ | wallyworld: got a minute to discuss? | 02:29 |
| wallyworld | sure | 02:29 |
| redir_ | tanzanite? | 02:29 |
| wallyworld | standup hangout | 02:29 |
| redir_ | there | 02:29 |
| wallyworld | axw: can you let me know when you have 5 mins? | 02:55 |
| axw | wallyworld: I have 5 mins | 02:55 |
| axw | maybe even more | 02:55 |
| wallyworld | axw: standup ho | 02:55 |
| mup | Bug #1576021 opened: 1.25.6 cannot deploy on CI maas 1.9 or 1.8 <ci> <maas-provider> <regression> <juju-ci-tools:Triaged> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1576021> | 04:23 |
| axw | dimitern: FYI, http://reviews.vapour.ws/r/4625/diff/3-4/ -- see comments for an alternative method of filtering instances in ec2 | 08:21 |
| dimitern | axw: thanks! looking | 08:21 |
| frobware | ping | 08:23 |
| dimitern | 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 |
| axw | dimitern: okey dokey | 08:24 |
| dimitern | frobware: was that for me? | 08:25 |
| dimitern | 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:29 |
| frobware | dimitern, heh, nope. off-by-1. :) | 08:30 |
| dimitern | ha :) | 08:30 |
| axw | 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:30 |
| babbageclunk | voidspace: so do you want to propose your kflavor/mount_point fix instead? | 08:31 |
| voidspace | babbageclunk: https://github.com/juju/gomaasapi/pull/49 | 08:31 |
| axw | dimitern: that would be fine if RunInstances is always called with exactly the same args | 08:31 |
| axw | (for a given machine) | 08:31 |
| voidspace | babbageclunk: I'm doing mount_point / filesystem as a separate branch as it's a bit more involved | 08:31 |
| voidspace | dimitern: https://github.com/juju/gomaasapi/pull/49 | 08:31 |
| voidspace | babbageclunk: dimitern: as it's a critical juju bug we'll also need to propose juju PR bumping gomaasapi | 08:32 |
| babbageclunk | voidspace: I'll get on with the constraint schema change - it's also a bit more involved, means changing the gomaasapi interfaces. | 08:33 |
| frobware | dimitern, voidspace, babbageclunk, dooferlad, jam: would appreciate a review for http://reviews.vapour.ws/r/4722/ | 08:33 |
| dimitern | axw: agreed, as the API docs say "A client token is valid for at least 24 hours after the termination of the instance" | 08:33 |
| voidspace | babbageclunk: this is a separate issue - the problem with space / storage constraints? | 08:34 |
| babbageclunk | voidspace: yup | 08:34 |
| dimitern | voidspace, frobware: looking at both | 08:34 |
| voidspace | thanks | 08:35 |
| babbageclunk | frobware: looking now | 08:35 |
| axw | 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:35 |
| frobware | dimitern, voidspace, babbageclunk, dooferlad: might not be in standup. expecting Lenovo engineer to turn up with parts to fix my latop. | 08:37 |
| voidspace | frobware: ok | 08:38 |
| dimitern | frobware: no standup today btw | 08:38 |
| babbageclunk | oh yeah - big meeting at 11 instead? | 08:39 |
| frobware | dimitern, ah, ok. was on autopilot | 08:39 |
| dimitern | 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:40 |
| dimitern | s/should like/sure looks like/ | 08:41 |
| voidspace | dimitern: babbageclunk: corresponding juju PR: https://github.com/juju/juju/pull/5301 | 08:43 |
| axw | 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:43 |
| dimitern | axw: hopefully in 2.1 or 2.2 :) | 08:44 |
| dimitern | voidspace: that one also LGTM | 08:44 |
| voidspace | dimitern: ta | 08:49 |
| jam | frobware: I just reviewed http://reviews.vapour.ws/r/4722/ | 08:50 |
| voidspace | mgz: did you file a bug for the filesystem issue? | 08:52 |
| frobware | jam, thanks | 08:53 |
| voidspace | mgz: so the schema for partition can already handle filesystem being null | 09:02 |
| dimitern | frobware: reviewed | 09:02 |
| voidspace | mgz: so it's just mount_point and label need to be optional | 09:02 |
| voidspace | mgz: the output you sent me - was that blockdevices? http://paste.ubuntu.com/16085749/ | 09:05 |
| voidspace | some of those have no partitions but a top-level filesystem, which we don't expose anyway | 09:05 |
| voidspace | hmmm... that may bite us in the future | 09:05 |
| voidspace | we'll see | 09:05 |
| frobware | 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:15 |
| dimitern | 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:17 |
| dimitern | frobware: even a single extra space before e.g. ` #LXD_IPV4_ADDR="0.1.2.0/24"` | 09:19 |
| voidspace | mgz: I found https://bugs.launchpad.net/juju-core/+bug/1575808 - which answers my questions | 09:34 |
| mup | Bug #1575808: filesystem 2.0 schema check failed: mount_point: expected string, got nothing <bootstrap> <ci> <maas-provider> <juju-core:In Progress by mfoord> <https://launchpad.net/bugs/1575808> | 09:34 |
| voidspace | dimitern: frobware: babbageclunk: https://github.com/juju/gomaasapi/pull/50 | 09:41 |
| dimitern | voidspace: LGTM +2 suggestions | 09:44 |
| voidspace | dimitern: without the ok check it panics | 09:45 |
| dimitern | voidspace: it panics, after the schema was coerced ? | 09:46 |
| voidspace | dimitern: ah, you mean still use the two value form of the cast but ignore ok | 09:46 |
| dimitern | yeah | 09:46 |
| voidspace | dimitern: yep - because nil is a valid option | 09:46 |
| voidspace | dimitern: and you can't cast nil to a string... | 09:46 |
| voidspace | dimitern: your suggestion works | 09:47 |
| dimitern | voidspace: no, it's already verified to be a string at that point | 09:47 |
| voidspace | dimitern: nope, string or nil | 09:47 |
| voidspace | but this works | 09:47 |
| voidspace | value, _ := thing.(string) | 09:47 |
| dimitern | voidspace: yeah, but (string) with ignored ok will yield "" for a nil value | 09:47 |
| voidspace | dimitern: yes | 09:48 |
| voidspace | dimitern: the single value form of the cast panics | 09:48 |
| voidspace | not the double value form | 09:48 |
| voidspace | dimitern: so thank you | 09:48 |
| dimitern | voidspace: ta | 09:48 |
| voidspace | dimitern: updated | 09:49 |
| voidspace | hmmm, no | 09:49 |
| voidspace | *now* updated | 09:50 |
| dimitern | voidspace: looking | 09:55 |
| voidspace | dimitern: too late | 09:55 |
| dimitern | babbageclunk: fair question btw - I've replied with some examples | 09:55 |
| dimitern | voidspace: thanks :) | 09:55 |
| voidspace | dimitern: frobware: babbageclunk: https://github.com/juju/juju/pull/5302 | 09:57 |
| voidspace | dimitern: thanks | 09:58 |
| dimitern | voidspace: you're on fire today :D | 09:58 |
| dimitern | nice! | 09:58 |
| voidspace | dimitern: easy ones I can do... | 09:58 |
| voidspace | heh | 09:58 |
| axw | wallyworld anastasiamac_: team meeting? | 10:04 |
| axw | dimitern: ^^ | 10:05 |
| mup | Bug #1576120 opened: "juju kill-controller" removes controllers.yaml entry even if destroying fails <juju-core:Triaged> <https://launchpad.net/bugs/1576120> | 10:06 |
| dimitern | I won't make it to the team meeting :/ | 10:11 |
| wallyworld | axw: was at soccer | 11:09 |
| frankban | 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:17 |
| axw | frankban: sorry was afk, reviewed now | 11:40 |
| axw | wallyworld: you gave mattyw's branch a shipit, but I don't think we should be ignoring errors ... | 11:44 |
| axw | I mean it's not ignored, but we should surely be checking for specific types of errors | 11:44 |
| wallyworld | 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 |
| wallyworld | the type of error doesn't really matter | 11:45 |
| axw | wallyworld: you might fail to read the controllers.yaml file? or the cross-process mutex fails? | 11:46 |
| wallyworld | axw: right, but what can be done besides exiting with an error? | 11:46 |
| axw | wallyworld: that's exactly what we should do | 11:47 |
| wallyworld | that's what i thoguht we did, i may have misread the change | 11:47 |
| axw | wallyworld: except in the case where the controller just wasn't found | 11:47 |
| axw | wallyworld: ah | 11:47 |
| axw | wallyworld: no, it's me that's doing the misreading :) | 11:47 |
| wallyworld | whew | 11:47 |
| axw | wallyworld: I looked at the diff back-to-front | 11:48 |
| wallyworld | i *almost* did the same thing :-) | 11:48 |
| axw | sorry! | 11:48 |
| wallyworld | np :) | 11:48 |
| mup | Bug #1576184 opened: "juju create-backup" fails if you're not operating on the admin model <juju-core:New> <https://launchpad.net/bugs/1576184> | 12:18 |
| mup | Bug #1576184 changed: "juju create-backup" fails if you're not operating on the admin model <juju-core:New> <https://launchpad.net/bugs/1576184> | 12:30 |
| frankban | axw: ty! | 12:36 |
| mup | Bug #1576184 opened: "juju create-backup" fails if you're not operating on the admin model <juju-core:New> <https://launchpad.net/bugs/1576184> | 12:37 |
| babbageclunk | voidspace, dimitern, frobware: change for constraint parsing here: https://github.com/juju/gomaasapi/pull/51 | 12:40 |
| voidspace | babbageclunk: looking | 12:41 |
| dimitern | babbageclunk: I think it will be a lot nicer, if we used the schema to process the constraintsMap | 12:43 |
| dimitern | babbageclunk: e.g. like when deserializing a vlan embedded into a subnet | 12:43 |
| voidspace | other than that it looks alright to me | 12:43 |
| voidspace | relatively straightforward | 12:44 |
| voidspace | I don't think it's that clunky, but if you can do as dimitern says then it sounds better | 12:44 |
| babbageclunk | dimitern: ok - I'll look at that | 12:44 |
| dimitern | 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:46 |
| babbageclunk | 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:47 |
| dimitern | babbageclunk: that as well, yeah | 12:48 |
| babbageclunk | dimitern: ok - something that takes an interface{} and returns a nice map[string][]int would be a huge improvement. | 12:48 |
| dimitern | babbageclunk: see for example how (the lot more complicated) interface_set is handled in machine_2_0 | 12:49 |
| babbageclunk | 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:51 |
| dimitern | babbageclunk: ignoring the API version sounds like a bad idea - esp. if the response format differs | 12:52 |
| dimitern | babbageclunk: a much simpler (alas inconsistent) way will be to define a struct with JSON serialization tags for the map and its keys | 12:53 |
| babbageclunk | dimitern: Oh, I thought this was down-stack from a machine_2_0 function, but you're right. | 12:54 |
| dimitern | babbageclunk: (inconsistent with the other code I mean) | 12:54 |
| dimitern | babbageclunk: look at how devices or interfaces are handled in the 1.0 code in provider/maas/ (before the changes to gomaasapi) | 12:54 |
| babbageclunk | dimitern: yeah, I don't really understand why this code didn't use the builtin JSON serialisation tags. | 12:55 |
| dimitern | babbageclunk: me too (fwiw) :) | 12:55 |
| dimitern | babbageclunk: but I guess the schema is the sexy new thing everybody should use everywhere now :) | 12:56 |
| babbageclunk | dimitern: it's ok, but it doesn't much help with the type system stepping all over everything. | 12:57 |
| dimitern | 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:58 |
| babbageclunk | dimitern: yeah, but I probably should try to keep it consistent. <sigh> | 12:59 |
| dimitern | babbageclunk: here's a trick: just put all that in a separate file :) inconsistency less obvious | 13:00 |
| perrito666 | morning | 13:19 |
| babbageclunk | dimitern, voidspace: put up a tweaked version that just pulls out the common conversion code | 13:33 |
| === babbageclunk is now known as babbageclunk|afk | ||
| * babbageclunk|afk goes for a run. | 13:34 | |
| dimitern | jam: ping | 14:41 |
| voidspace | babblooking | 14:43 |
| babbageclunk | voidspace, dimitern: any objections to me merging https://github.com/juju/gomaasapi/pull/51 | 14:50 |
| dimitern | babbageclunk: sorry, got distracted, will have a look now quickly | 14:50 |
| babbageclunk | dimitern: thanks! | 14:50 |
| voidspace | babbageclunk: LLLGTM | 14:53 |
| voidspace | uhm, or something like that | 14:53 |
| babbageclunk | :) | 14:53 |
| voidspace | babbageclunk: so I assume there's a follow-up in juju coming to use this | 14:54 |
| dimitern | 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:54 |
| dimitern | babbageclunk: what will happen if you type-assert to map[string]map[string][]int instead on line 826 in controller.go? | 14:55 |
| dimitern | babbageclunk: if it works, then convertConstraintMatches becomes unnecessary and you could just iterate over the nested map for both top-level keys | 14:57 |
| babbageclunk | 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:57 |
| dimitern | babbageclunk: you can still type assert the nested maps - e.g. https://play.golang.org/p/D2cz2Af4vE | 14:59 |
| dimitern | babbageclunk: but I'm OK with landing this as is and possibly trying a bit simpler approach in a follow-up | 15:00 |
| dimitern | (and the follow-up itself doesn't have to be done today) | 15:00 |
| dimitern | :) | 15:00 |
| babbageclunk | dimitern: I think the problem is that you can't do the next level down - https://play.golang.org/p/0jmajp13vl | 15:01 |
| alexisb | voidspace, babbageclunk nicely done on the bugs reported by CI for maas 2.0 | 15:03 |
| babbageclunk | 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:03 |
| babbageclunk | dimitern: and then walk through those turning the leaf interface{}s into ints. | 15:04 |
| babbageclunk | alexisb: thanks! | 15:04 |
| katco | ericsnow: standup time | 15:04 |
| babbageclunk | dimitern: (at least, that's what I think - I'd be happy to have that code be simpler!) | 15:05 |
| dimitern | babbageclunk: you can go as deep as you want: https://play.golang.org/p/UmVNx8N8tu | 15:08 |
| dimitern | 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 |
| babbageclunk | dimitern: Right, but that's essentially what I had in https://github.com/juju/gomaasapi/pull/51/commits/61b3b97003699be0c103f21cb26e7fb924d19b4b | 15:10 |
| mup | Bug #1570796 changed: container startup issue when juju network management disabled <juju-core:Invalid> <https://launchpad.net/bugs/1570796> | 15:10 |
| mup | Bug #1576266 opened: apiclientSuite.SetUpTest fails because no tools available <ci> <go1.6> <test-failure> <unit-tests> <windows> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1576266> | 15:10 |
| mup | Bug #1576270 opened: 'juju create-backup' fails first on a mongodump dependency then auth failure <docteam> <juju-core:New> <https://launchpad.net/bugs/1576270> | 15:10 |
| babbageclunk | dimitern: the casting is all interspersed with the matching devices and interfaces. | 15:11 |
| babbageclunk | dimitern: anyway, thanks! | 15:11 |
| babbageclunk | dimitern: :) | 15:11 |
| dimitern | babbageclunk: that looks better, yeah - remember the schema gives us some confidence to do e.g. matchMap := source.(map[string][]int) directly | 15:12 |
| babbageclunk | 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:14 |
| dimitern | babbageclunk: anyway, it was an interesting exercise I guess :) | 15:17 |
| babbageclunk | dimitern: yup yup - thanks! | 15:18 |
| jcastro | alexisb: filing bugs in juju core, launchpad or github? | 15:47 |
| jcastro | if launchpad shouldn't we disable the github issues tracker? | 15:47 |
| alexisb | jcastro, launchpad | 15:47 |
| natefinch | jcastro: we've talked about that a bnuch | 15:47 |
| alexisb | jcastro, we have discussed disabling it | 15:48 |
| jcastro | we need to make it obvious then, I just realized I've been filing bugs in the wrong place | 15:48 |
| jcastro | and I work here | 15:48 |
| alexisb | our current policy is that we open launchpad bugs for folks | 15:48 |
| babbageclunk | voidspace, dimitern, frobware: review? http://reviews.vapour.ws/r/4733/ | 15:51 |
| babbageclunk | this is the other side of my gomaasapi constraint change. | 15:51 |
| natefinch | code review anyone? https://github.com/juju/utils/pull/208 | 15:51 |
| natefinch | very short and sweet | 15:51 |
| dimitern | babbageclunk: did you try this live against MAAS2 ? | 15:54 |
| babbageclunk | dimitern: ooh, no - thanks for reminding me! That was what lead me down this crazy rabbithole in the first place! | 15:54 |
| dimitern | babbageclunk: :) ok | 15:55 |
| mup | Bug #1576295 opened: add-credential input field should support tab completion <juju-core:New> <https://launchpad.net/bugs/1576295> | 15:55 |
| babbageclunk | 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:15 |
| dimitern | babbageclunk: how are the machine NICs configured? | 16:16 |
| babbageclunk | dimitern: it's running, but juju says pending. I can't ssh in by juju ssh or directly. | 16:16 |
| dimitern | babbageclunk: it doesn't let you in or it doesn't connect ? | 16:16 |
| dimitern | babbageclunk: if EPERM, try ssh -i ~/.local/share/juju/ssh/juju_id_rsa.pub ubuntu@<IP-known-by-maas> | 16:17 |
| babbageclunk | dimitern: network looks like this http://pastebin.ubuntu.com/16098886/ | 16:19 |
| babbageclunk | dimitern: juju ssh just hangs | 16:20 |
| babbageclunk | dimitern: I tried ssh with the key, that says: Connection closed by 192.168.150.4 | 16:21 |
| dimitern | babbageclunk: I suspect the DHCP primary is the reason for this | 16:21 |
| babbageclunk | dimitern: any way to log in on the terminal? Probably no default password for ubuntu user, right? | 16:21 |
| babbageclunk | dimitern: ok | 16:21 |
| dimitern | 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 |
| mup | Bug #1576301 opened: Cryptic error message if Juju uses the wrong json file from GCE <juju-core:New> <https://launchpad.net/bugs/1576301> | 16:22 |
| dimitern | babbageclunk: you can hack the userdata juju passes to maas to include setting the password (or removing it) | 16:22 |
| mup | Bug #1576313 opened: windows: uniter tests fail because logs get dumped to stderr <juju-core:New> <https://launchpad.net/bugs/1576313> | 16:22 |
| babbageclunk | dimitern: ok, so I released the machine, but I can't remove it in juju - just stays in pending. | 16:25 |
| dimitern | babbageclunk: remove-machine # --force | 16:25 |
| babbageclunk | dimitern: I tried that - it looks like it timed out on its own eventually | 16:26 |
| babbageclunk | dimitern: ok, so I've changed it from DHCP to auto? Try again? | 16:26 |
| babbageclunk | dimitern: Or should I try deploying it in MAAS and making sure I can ssh to it as I'd expect? | 16:26 |
| dimitern | babbageclunk: either auto or static should work (that's true for all types of NICs) | 16:27 |
| dimitern | babbageclunk: well, that's also an option if you're not sure juju does the right thing | 16:27 |
| dimitern | babbageclunk: but as you explain it, it looks like juju did good, maas didn't | 16:28 |
| dimitern | there's still a LOT maas can do to improve the UX around misconfigured nodes, networks, images, .. | 16:28 |
| natefinch | 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:28 |
| mgz | bogdanteleaga: new bug is very like fixed bug 1470601 | 16:29 |
| mup | Bug #1470601: UniterSuite.TestLeadership fails on windows <blocker> <ci> <regression> <unit-tests> <juju-core:Fix Released by bteleaga> <https://launchpad.net/bugs/1470601> | 16:30 |
| ericsnow | natefinch: sure | 16:30 |
| dimitern | 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:30 |
| babbageclunk | dimitern: I'm getting "Unable to allocate static IP due to address exhaustion." - I think my DHCP covers the whole subnet | 16:31 |
| babbageclunk | dimitern: where can I adjust the range? I can't find it. | 16:32 |
| babbageclunk | dimitern: Do I need to delete and re-add the subnet? | 16:33 |
| babbageclunk | dimitern: ah, found it - on the VLAN | 16:35 |
| bogdanteleaga | 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:35 |
| mgz | bogdanteleaga: heh | 16:36 |
| dimitern | babbageclunk: no need to remove the subnet, adjust the range | 16:36 |
| babbageclunk | 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:37 |
| dimitern | babbageclunk: have a look at the subnet in the ui | 16:38 |
| dimitern | babbageclunk: you should see a bunch of used addresses at the end | 16:38 |
| dimitern | babbageclunk: and there are also the CLI commands for iprange(s) that control what's reserved, etc. | 16:39 |
| dimitern | babbageclunk: but I haven't actually tried (I did poke around in the postgres db directly though with maas-region --dbshell :) | 16:40 |
| dimitern | babbageclunk: `sudo maas-region dbshell -i` - it's the familiar django dbshell (running psql) | 16:42 |
| ericsnow | natefinch: ship-it | 16:43 |
| natefinch | ericsnow: thanks! | 16:44 |
| mup | Bug #1576324 opened: Juju2.0 commandline client inconsistent treatment of yaml files <landscape> <usability> <juju-core:New> <https://launchpad.net/bugs/1576324> | 16:52 |
| mup | Bug #1576324 changed: Juju2.0 commandline client inconsistent treatment of yaml files <landscape> <usability> <juju-core:New> <https://launchpad.net/bugs/1576324> | 16:55 |
| babbageclunk | dimitern: hmm. I shouldn't have deleted that subnet while it was in use, I don't think. | 16:59 |
| babbageclunk | dimitern: I think I might need to reinstall MAAS tomorrow. | 16:59 |
| dimitern | babbageclunk: sounds good (after a few times it becomes always second nature :) | 17:01 |
| dimitern | s/always/almost/ | 17:01 |
| mup | Bug #1576324 opened: Juju2.0 commandline client inconsistent treatment of yaml files <landscape> <usability> <juju-core:New> <https://launchpad.net/bugs/1576324> | 17:02 |
| babbageclunk | dimitern: Sometimes taking off and nuking the site from orbit really *is* the only way to be sure! | 17:02 |
| rogpeppe | anyone know if there's a way to list what models are stored locally? | 17:36 |
| cherylj | rogpeppe: what models or what controllers? | 17:37 |
| rogpeppe | cherylj: what models | 17:37 |
| rogpeppe | cherylj: all the models i can juju switch to | 17:37 |
| cherylj | rogpeppe: well, all the models locally won't necessarily be all the ones you can switch to | 17:38 |
| cherylj | hmm | 17:38 |
| rogpeppe | cherylj: ah, switch allows you to switch to remotely held models too? | 17:38 |
| cherylj | actually | 17:38 |
| cherylj | yeah, you could be granted access to a model | 17:38 |
| cherylj | and it wouldn't be in your local cache | 17:38 |
| rogpeppe | cherylj: juju switch will automatically go and grab a model into the local cache? | 17:39 |
| cherylj | there's a way you can list models you have access to for a paricular controller | 17:39 |
| cherylj | juju list-models will limit it to ones you have access to | 17:39 |
| cherylj | (unless you're an admin and use the whatever all-models flag) | 17:39 |
| rogpeppe | cherylj: but there's no way to find out what models i have cached locally? | 17:40 |
| cherylj | rogpeppe: I'm not sure if the model info will be stored locally | 17:40 |
| cherylj | when you switch to it | 17:40 |
| cherylj | I'd have to see | 17:40 |
| rogpeppe | cherylj: well, model info is stored locally | 17:40 |
| rogpeppe | cherylj: i'm presuming that's used sometimes | 17:40 |
| cherylj | rogpeppe: not apart from manually looking in ~/.local/share/juju/models.yaml | 17:41 |
| mup | Bug #1576342 opened: `juju status` should show leadership primitives <juju-core:New> <https://launchpad.net/bugs/1576342> | 17:44 |
| mup | Bug #1576346 opened: upgrade-charm with a local charm fails with trailing slash <juju-core:New> <https://launchpad.net/bugs/1576346> | 17:44 |
| bdx | hey whats going on everyone? Does anyone know the timeframe for RC1? | 17:46 |
| cherylj | bdx: we're most likely going to do another beta next week. Not sure when we're going to have something we want to call rc1 | 17:46 |
| bdx | cherylj: ok, awesome. thx | 17:48 |
| mup | Bug #1576359 opened: Cannot talk to a new model with a reused name <juju-release-support> <switch> <juju-core:Triaged> <https://launchpad.net/bugs/1576359> | 18:20 |
| kwmonroe | hey juju-dev, i have 2 models in azure, and both have a "machine-4". the last one to come up seems to steal the dns entry. is this a bug, or am i doing networking wrong? http://paste.ubuntu.com/16115389/ | 18:35 |
| mup | Bug #1576366 opened: juju 2 beta6: show-controller --format=json is broken <landscape> <juju-core:New> <https://launchpad.net/bugs/1576366> | 18:44 |
| mup | Bug #1576368 opened: blockdevice 2.0 schema check failed: model: expected string, got nothing <ci> <deploy> <maas-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1576368> | 18:44 |
| natefinch | kwmonroe: not sure... definitely worth filing a bug, though. | 18:46 |
| katco | mgz: ping | 18:52 |
| mgz | katco: yo | 18:52 |
| katco | mgz: o/ | 18:52 |
| mgz | \o\ | 18:52 |
| katco | mgz: i'm removing HP cloud schtuff in master, and there's some code in the openstack provider that considers an instance started if the status is BuildSpawning... is that safe to remove? | 18:53 |
| katco | mgz: https://github.com/juju/juju/blob/master/provider/openstack/provider.go#L1089-L1097 | 18:53 |
| katco | mgz: just want to remove the nova.StatusBuildSpawning from L1093, and a corresponding test | 18:54 |
| mgz | yeah, it should be, I don't think any trunk version of openstack used that form of status | 18:54 |
| katco | mgz: awesome, ty | 18:54 |
| mgz | katco: hm, we may want to keep something, looking at https://github.com/openstack/nova/tree/master/nova/compute *_state.py files | 18:57 |
| katco | mgz: it looks like the only reference to spawning is for task states whereis this is server state | 19:01 |
| katco | mgz: you know way more about openstack, but seems safe to me? could ask in #openstack maybe | 19:01 |
| mgz | katco: yeah, the HP way of displaying "BUILD(spawning)" was HP specific | 19:02 |
| mgz | but the isAliveServer logic is pretty ropey | 19:02 |
| katco | yeah | 19:02 |
| * katco just remembered ods is going on | 19:03 | |
| mgz | katco: I think I'd remove the code as it exists and file a bug against goose to update/make the various exposed states more usable | 19:03 |
| mgz | yeah, it's a good and a bad week to ask about openstack things :) | 19:04 |
| katco | hehe | 19:04 |
| katco | mgz: as in, don't expose the state, expose a synthesized concept of machine up? | 19:04 |
| mgz | katco: well, we get three types of status/state exposed, but goose doesn't give us that cleanly | 19:05 |
| katco | 14:05> go get -u gopkg.in/juju/charm.v6-unstable | 19:07 |
| katco | # cd /home/kate/workspace/go/src/gopkg.in/juju/charm.v6-unstable; git pull --ff-only | 19:07 |
| katco | fatal: unable to access 'https://gopkg.in/juju/charm.v6-unstable/': server certificate verification failed. CAfile: none CRLfile: none | 19:07 |
| katco | is this just me? | 19:08 |
| mgz | katco: I think I made all the upstreams for charm etc go straight to github | 19:08 |
| mgz | ha, actually, didn't restore that after my drive got wiped | 19:09 |
| mgz | so, lets see | 19:09 |
| natefinch | katco: I don't get that | 19:10 |
| mgz | katco: worked for me | 19:10 |
| katco | hm, ok... now wondering what the heck is up with my machine | 19:10 |
| natefinch | However, I have been having problems with go get -u.... I get this: http://pastebin.ubuntu.com/16118444/ | 19:10 |
| natefinch | maybe godeps + go get -u is a bad combo | 19:11 |
| katco | natefinch: i think your're just on a detached head | 19:12 |
| katco | natefinch: try git checkout master first | 19:12 |
| natefinch | katco: right, but I think that's because of godeps | 19:13 |
| katco | natefinch: well yes, godeps checks a commit out which puts you on a detached head unless the commit happens to be master | 19:13 |
| natefinch | katco: right, ok, so it's just godeps messing up go get -u. That's fine. | 19:14 |
| natefinch | annoying, but fine :) | 19:14 |
| mup | Bug #1576376 opened: azure multi model dns failure <juju-core:New> <https://launchpad.net/bugs/1576376> | 19:17 |
| natefinch | ericsnow: I think reviewboard is grumpy. My last couple of PRs haven't been picked up | 19:23 |
| ericsnow | natefinch: :( | 19:24 |
| cherylj | hey katco, did you see I scheduled the interview for tomorrow morning? Will you be able to make it? | 19:27 |
| ericsnow | natefinch: you mean like http://reviews.vapour.ws/r/4735? <wink> | 19:27 |
| katco | cherylj: yes, i'll be there. sorry i haven't responded yet. | 19:28 |
| cherylj | katco: no worries, just wanted to make sure. | 19:28 |
| katco | cherylj: thanks for setting that up | 19:28 |
| cherylj | katco: did you want to chat for a bit first to make a plan? I'm not sure how you and mattyw worked things out before | 19:28 |
| natefinch | ericsnow: yeah, weird, it didn't update the PR with the link | 19:28 |
| natefinch | ericsnow: I'm not sure what to do with the test that ensures we don | 19:33 |
| natefinch | ericsnow: don't support SSL. It seems redundant with this change, but... I was hesitant to remove a test that still passed and still tested something we want to be true,. | 19:33 |
| === urulama is now known as urulama|____ | ||
| mup | Bug #1572772 changed: URLsSuite.TestImageMetadataURL paths fail on windows <ci> <regression> <test-failure> <unit-tests> <windows> <juju-core:Fix Released by hduran-8> <https://launchpad.net/bugs/1572772> | 20:47 |
| mup | Bug #1575463 changed: buildSuite.TestGetVersion* CryptAcquireContext: Provider DLL failed to initialize <blocker> <centos> <ci> <ppc64el> <regression> <test-failure> <unit-tests> <windows> <juju-core:Fix Released by axwalk> <https://launchpad.net/bugs/1575463> | 21:29 |
| redir | so this https://github.com/juju/juju/blob/master/environs/config/config.go#L342 should validate that 'series' is a valid LTS series, yes? | 21:33 |
| perrito666 | bbl ~1h | 21:34 |
| redir | ericsnow, natefinch, katco ^^ | 21:36 |
| katco | redir: sec otp | 21:36 |
| ericsnow | redir: not a valid *LTS* necessarily | 21:36 |
| ericsnow | redir: just one the charm package recognizes as valid | 21:37 |
| redir | ericsnow: um, so the error is wrong or the test is wrong? | 21:37 |
| redir | ericsnow: but it should verify an actual LTS series, no? | 21:38 |
| ericsnow | redir: charm.IsValidSeries() just ensures that the string is a valid simple name: "^[a-z]+([a-z0-9]+)?$" | 21:39 |
| ericsnow | redir: the LTS-ness comes from being the result of the "distro-info --lts" command | 21:40 |
| redir | right but distroLtsSeriesFunc returns the latest LTS series so that doesn't seem like a valid check | 21:40 |
| redir | should it be more correct, ericsnow ? | 21:41 |
| redir | or omitted? | 21:41 |
| ericsnow | redir: the charm.IsValidSeries() call is just making sure the data we got back from "distro-info --lts" is valid | 21:41 |
| redir | well is a lower case string that doesn't start with a number. | 21:42 |
| ericsnow | redir: I think the error message is fine given the context of the function | 21:42 |
| redir | which isn't a valid LTS | 21:42 |
| redir | which means the function could return a nonsense string | 21:42 |
| ericsnow | redir: it doesn't have to verify that; it's more a sanity check of the output | 21:43 |
| redir | partial sanity check:) | 21:43 |
| ericsnow | redir: we're relying on "distro-info --lts" to do the right thing | 21:43 |
| redir | OK | 21:45 |
| perrito666 | Wallyworld ill be half hour later to the 1:1 I misread the calendar | 21:59 |
| wallyworld | perrito666: no problem at all, just ping me | 21:59 |
| perrito666 | Tx | 21:59 |
| perrito666 | wallyworld: I am in the call | 22:26 |
| wallyworld | ok | 22:26 |
| mup | Bug #1575472 changed: Data Race github.com/juju/juju/environs/tools/build.g <ci> <race-condition> <regression> <test-failure> <unit-tests> <juju-core:Fix Released by dave-cheney> <https://launchpad.net/bugs/1575472> | 23:06 |
| mup | Bug #1575472 opened: Data Race github.com/juju/juju/environs/tools/build.g <ci> <race-condition> <regression> <test-failure> <unit-tests> <juju-core:Fix Released by dave-cheney> <https://launchpad.net/bugs/1575472> | 23:15 |
| mup | Bug #1575472 changed: Data Race github.com/juju/juju/environs/tools/build.g <ci> <race-condition> <regression> <test-failure> <unit-tests> <juju-core:Fix Released by dave-cheney> <https://launchpad.net/bugs/1575472> | 23:24 |
| axw | anastasiamac_: what's the 3 day weekend? don't think it is over here | 23:45 |
| anastasiamac_ | axw: oh... maybe jsut qld: labour day :D | 23:45 |
| axw | anastasiamac_: ah, ours is earlier in the year | 23:45 |
| anastasiamac_ | oh.. | 23:45 |
| anastasiamac_ | axw: m happy to have both off - it's sinful to work on labour day... right? | 23:46 |
| wallyworld | davecheney: i just saw for the first time your compiler benchmarks. wtf. i thought go > 1.2 was slow, but wow. was it just that the go compiler sucks compared to c++? | 23:47 |
| axw | C | 23:48 |
| wallyworld | go 1.7 looks like it is getting back to parity | 23:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!