[00:01] <mup> Bug #1575403 changed: juju2: juju deploy --to and -n not usable together? <landscape> <juju-core:Invalid> <https://launchpad.net/bugs/1575403>
[00:18] <davecheney> cherylj: https://github.com/juju/juju/pull/5297
[00:37] <mup> Bug #1575983 opened: Having 2 machine-0 is confusing <juju-core:New> <https://launchpad.net/bugs/1575983>
[00:40] <mup> Bug #1575983 changed: Having 2 machine-0 is confusing <juju-core:New> <https://launchpad.net/bugs/1575983>
[00:49] <mup> Bug #1575983 opened: Having 2 machine-0 is confusing <juju-core:New> <https://launchpad.net/bugs/1575983>
[00:50] <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:56] <menn0> davecheney: looking now
[00:59] <axw> davecheney: LGTM
[01:03] <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:04] <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:06] <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:07] <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:08] <menn0> true
[01:09] <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:18] <redir> wallyworld: cherylj: whomever... http://reviews.vapour.ws/r/4724/
[01:18] <wallyworld> looking
[01:26] <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:27] <davecheney> the code cannot cope with anything on stderr
[01:28] <menn0> davecheney: all good. your change avoids any unnecessary complexity.
[01:32] <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:37] <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:48] <menn0> axw: thanks for the review. a few things:
[01:48] <menn0> the calls are bulk on the server side
[01:49] <menn0> they're just not on the client side
[01:49] <axw> menn0: ah, didn't look properly, sorry
[01:50] <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:51] <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:52] <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:53] <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:54] <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:55] <menn0> axw: I'll just make the calls take tags instead of raw ids for now
[01:55] <axw> menn0: SGTM, thanks
[02:20] <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:29] <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:55] <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
[04:23] <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>
[08:21] <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:23] <frobware> ping
[08:24] <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:25] <dimitern> frobware: was that for me?
[08:29] <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:30] <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:31] <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:32] <voidspace> babbageclunk: dimitern: as it's a critical juju bug we'll also need to propose juju PR bumping gomaasapi
[08:33] <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:34] <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:35] <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:37] <frobware> dimitern, voidspace, babbageclunk, dooferlad: might not be in standup. expecting Lenovo engineer to turn up with parts to fix my latop.
[08:38] <voidspace> frobware: ok
[08:38] <dimitern> frobware: no standup today btw
[08:39] <babbageclunk> oh yeah - big meeting at 11 instead?
[08:39] <frobware> dimitern, ah, ok. was on autopilot
[08:40] <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:41] <dimitern> s/should like/sure looks like/
[08:43] <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:44] <dimitern> axw: hopefully in 2.1 or 2.2 :)
[08:44] <dimitern> voidspace: that one also LGTM
[08:49] <voidspace> dimitern: ta
[08:50] <jam> frobware: I just reviewed http://reviews.vapour.ws/r/4722/
[08:52] <voidspace> mgz: did you file a bug for the filesystem issue?
[08:53] <frobware> jam, thanks
[09:02] <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:05] <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:15] <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:17] <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:19] <dimitern> frobware: even a single extra space before e.g. ` #LXD_IPV4_ADDR="0.1.2.0/24"`
[09:34] <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:41] <voidspace> dimitern: frobware: babbageclunk: https://github.com/juju/gomaasapi/pull/50
[09:44] <dimitern> voidspace: LGTM +2 suggestions
[09:45] <voidspace> dimitern: without the ok check it panics
[09:46] <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:47] <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:48] <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:49] <voidspace> dimitern: updated
[09:49] <voidspace> hmmm, no
[09:50] <voidspace> *now* updated
[09:55] <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:57] <voidspace> dimitern: frobware: babbageclunk: https://github.com/juju/juju/pull/5302
[09:58] <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
[10:04] <axw> wallyworld anastasiamac_: team meeting?
[10:05] <axw> dimitern: ^^
[10:06] <mup> Bug #1576120 opened: "juju kill-controller" removes controllers.yaml entry even if destroying fails <juju-core:Triaged> <https://launchpad.net/bugs/1576120>
[10:11] <dimitern> I won't make it to the team meeting :/
[11:09] <wallyworld> axw: was at soccer
[11:17] <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:40] <axw> frankban: sorry was afk, reviewed now
[11:44] <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:45] <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:46] <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:47] <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:48] <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 :)
[12:18] <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:30] <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:36] <frankban> axw: ty!
[12:37] <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:40] <babbageclunk> voidspace, dimitern, frobware: change for constraint parsing here: https://github.com/juju/gomaasapi/pull/51
[12:41] <voidspace> babbageclunk: looking
[12:43] <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:44] <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:46] <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:47] <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:48] <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:49] <dimitern> babbageclunk: see for example how (the lot more complicated) interface_set is handled in machine_2_0
[12:51] <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:52] <dimitern> babbageclunk: ignoring the API version sounds like a bad idea - esp. if the response format differs
[12:53] <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:54] <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:55] <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:56] <dimitern> babbageclunk: but I guess the schema is the sexy new thing everybody should use everywhere now :)
[12:57] <babbageclunk> dimitern: it's ok, but it doesn't much help with the type system stepping all over everything.
[12:58] <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:59] <babbageclunk> dimitern: yeah, but I probably should try to keep it consistent. <sigh>
[13:00] <dimitern> babbageclunk: here's a trick: just put all that in a separate file :) inconsistency less obvious
[13:19] <perrito666> morning
[13:33] <babbageclunk> dimitern, voidspace: put up a tweaked version that just pulls out the common conversion code
[13:34]  * babbageclunk|afk goes for a run.
[14:41] <dimitern> jam: ping
[14:43] <voidspace> babblooking
[14:50] <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:53] <voidspace> babbageclunk: LLLGTM
[14:53] <voidspace> uhm, or something like that
[14:53] <babbageclunk> :)
[14:54] <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:55] <dimitern> babbageclunk: what will happen if you type-assert to map[string]map[string][]int instead on line 826 in controller.go?
[14:57] <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:59] <dimitern> babbageclunk: you can still type assert the nested maps - e.g. https://play.golang.org/p/D2cz2Af4vE
[15:00] <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:01] <babbageclunk> dimitern: I think the problem is that you can't do the next level down - https://play.golang.org/p/0jmajp13vl
[15:03] <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:04] <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:05] <babbageclunk> dimitern: (at least, that's what I think - I'd be happy to have that code be simpler!)
[15:08] <dimitern> babbageclunk: you can go as deep as you want: https://play.golang.org/p/UmVNx8N8tu
[15:10] <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:11] <babbageclunk> dimitern: the casting is all interspersed with the matching devices and interfaces.
[15:11] <babbageclunk> dimitern: anyway, thanks!
[15:11] <babbageclunk> dimitern: :)
[15:12] <dimitern> babbageclunk: that looks better, yeah - remember the schema gives us some confidence to do e.g. matchMap := source.(map[string][]int) directly
[15:14] <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:17] <dimitern> babbageclunk: anyway, it was an interesting exercise I guess :)
[15:18] <babbageclunk> dimitern: yup yup - thanks!
[15:47] <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:48] <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:51] <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:54] <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:55] <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>
[16:15] <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:16] <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:17] <dimitern> babbageclunk: if EPERM, try ssh -i ~/.local/share/juju/ssh/juju_id_rsa.pub ubuntu@<IP-known-by-maas>
[16:19] <babbageclunk> dimitern: network looks like this http://pastebin.ubuntu.com/16098886/
[16:20] <babbageclunk> dimitern: juju ssh just hangs
[16:21] <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:22] <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:25] <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:26] <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:27] <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:28] <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:29] <mgz> bogdanteleaga: new bug is very like fixed bug 1470601
[16:30] <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:31] <babbageclunk> dimitern: I'm getting "Unable to allocate static IP due to address exhaustion." - I think my DHCP covers the whole subnet
[16:32] <babbageclunk> dimitern: where can I adjust the range? I can't find it.
[16:33] <babbageclunk> dimitern: Do I need to delete and re-add the subnet?
[16:35] <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:36] <mgz> bogdanteleaga: heh
[16:36] <dimitern> babbageclunk: no need to remove the subnet, adjust the range
[16:37] <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:38] <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:39] <dimitern> babbageclunk: and there are also the CLI commands for iprange(s) that control what's reserved, etc.
[16:40] <dimitern> babbageclunk: but I haven't actually tried (I did poke around in the postgres db directly though with maas-region --dbshell :)
[16:42] <dimitern> babbageclunk: `sudo maas-region dbshell -i` - it's the familiar django dbshell (running psql)
[16:43] <ericsnow> natefinch: ship-it
[16:44] <natefinch> ericsnow: thanks!
[16:52] <mup> Bug #1576324 opened: Juju2.0 commandline client inconsistent treatment of yaml files  <landscape> <usability> <juju-core:New> <https://launchpad.net/bugs/1576324>
[16:55] <mup> Bug #1576324 changed: Juju2.0 commandline client inconsistent treatment of yaml files  <landscape> <usability> <juju-core:New> <https://launchpad.net/bugs/1576324>
[16:59] <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.
[17:01] <dimitern> babbageclunk: sounds good (after a few times it becomes always second nature :)
[17:01] <dimitern> s/always/almost/
[17:02] <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:36] <rogpeppe> anyone know if there's a way to list what models are stored locally?
[17:37] <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:38] <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:39] <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:40] <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:41] <cherylj> rogpeppe: not apart from manually looking in ~/.local/share/juju/models.yaml
[17:44] <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:46] <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:48] <bdx> cherylj: ok, awesome. thx
[18:20] <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:35] <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:44] <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:46] <natefinch> kwmonroe: not sure... definitely worth filing a bug, though.
[18:52] <katco> mgz: ping
[18:52] <mgz> katco: yo
[18:52] <katco> mgz: o/
[18:52] <mgz> \o\
[18:53] <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:54] <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:57] <mgz> katco: hm, we may want to keep something, looking at https://github.com/openstack/nova/tree/master/nova/compute *_state.py files
[19:01] <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:02] <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:03]  * 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:04] <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:05] <mgz> katco: well, we get three types of status/state exposed, but goose doesn't give us that cleanly
[19:07] <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:08] <katco> is this just me?
[19:08] <mgz> katco: I think I made all the upstreams for charm etc go straight to github
[19:09] <mgz> ha, actually, didn't restore that after my drive got wiped
[19:09] <mgz> so, lets see
[19:10] <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:11] <natefinch> maybe godeps + go get -u is a bad combo
[19:12] <katco> natefinch: i think your're just on a detached head
[19:12] <katco> natefinch: try git checkout master first
[19:13] <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:14] <natefinch> katco: right, ok, so it's just godeps messing up go get -u. That's fine.
[19:14] <natefinch> annoying, but fine :)
[19:17] <mup> Bug #1576376 opened: azure multi model dns failure <juju-core:New> <https://launchpad.net/bugs/1576376>
[19:23] <natefinch> ericsnow: I think reviewboard is grumpy.  My last couple of PRs haven't been picked up
[19:24] <ericsnow> natefinch: :(
[19:27] <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:28] <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:33] <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,.
[20:47] <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>
[21:29] <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:33] <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:34] <perrito666> bbl ~1h
[21:36] <redir> ericsnow, natefinch, katco ^^
[21:36] <katco> redir: sec otp
[21:36] <ericsnow> redir: not a valid *LTS* necessarily
[21:37] <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:38] <redir> ericsnow: but it should verify an actual LTS series, no?
[21:39] <ericsnow> redir: charm.IsValidSeries() just ensures that the string is a valid simple name: "^[a-z]+([a-z0-9]+)?$"
[21:40] <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:41] <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:42] <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:43] <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:45] <redir> OK
[21:59] <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
[22:26] <perrito666> wallyworld: I am in the call
[22:26] <wallyworld> ok
[23:06] <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:15] <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:24] <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:45] <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:46] <anastasiamac_> axw: m happy to have both off - it's sinful to work on labour day... right?
[23:47] <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:48] <axw> C
[23:51] <wallyworld> go 1.7 looks like it is getting back to parity