[00:01] <menn0> axw: review done
[00:50] <axw> menn0: thanks, I'll run up a 1.25 env and test on there before I land
[00:56] <menn0> axw: great, thanks
[01:42] <menn0> axw: thanks for the edits
[01:42] <axw> menn0: so 2.4 handles the "_id $in [...]" method well - it completed instantly. using Bulk isn't terrible though, it takes 3 seconds to remove 10000 docs
[01:42] <axw> menn0: so I'm inclined to just use Bulk for simplicity
[01:43] <menn0> axw: that SGTM
[01:43] <axw> menn0: np
[01:43] <axw> cool
[01:43] <menn0> axw: 3s for 10000 docs locally or on azure?
[01:43] <axw> menn0: on azure
[01:46] <axw> one last test with 2.0 on a fresh VM
[01:54] <menn0> axw: that seems like it should be fine to me
[01:55] <axw> menn0: cool. I'm just going to test on the exact same VM size, with mongo 3.x/wiredtiger without waiting for things to go pear shaped this time. should be a better comparison
[01:55] <axw> if it's the same I'll shipit
[01:55] <menn0> axw: +1
[03:07] <wallyworld> axw: when you have time, a small one, no rush https://github.com/juju/juju/pull/6516
[03:10] <axw> wallyworld: what is the "elsewhere" that tests the same functionality?
[03:10] <wallyworld> axw: test cases in testChangeRemoteApplications
[03:13] <axw> wallyworld: LGTM
[03:13] <wallyworld> ty
[03:47] <wallyworld> axw: this line https://github.com/juju/version/blob/master/version.go#L143 causes this bug https://bugs.launchpad.net/juju/+bug/1637079 . I think we should just remove that series check entirely from ParseBinary? The bugs happens when you have a juju agent running on a system without zesty in its distro info data and the agent tries to parse zesty tools
[03:47] <mup> Bug #1637079: Upgrade stuck due to out-of-date distro-info-data package <canonical-is> <eda> <juju:Triaged by alexis-bruemmer> <https://launchpad.net/bugs/1637079>
[03:48] <axw> wallyworld: SGTM, but does removing that get you all the way?
[03:48] <wallyworld> i think so, will check a bit more closely to try and be sure
[03:51] <axw> wallyworld: we should be changing the binary format to replace series with OS at some point. there's no need for separate agent binaries per series
[03:54] <wallyworld> axw: oh tell me about it. bootstrapping on aws is sooooooo because it uploads i think 3 copies of the tools tarballs, one for each of a few series. takes forever
[03:54] <wallyworld> maybe a 2.2 thing
[03:55] <axw> wallyworld: seriously? I thought we fixed that to just upload one, and have the controller explode it into the various series
[03:56] <axw> if we're uploading multiple times, I think we can fix that without changing the format at least
[03:56] <wallyworld> hmmm. maybe. i haven't checked in a while. maybe the tarball has grown so large it still take sages
[03:56] <axw> it does take a long time
[03:56] <wallyworld> on ADSL yeah it does :-(
[04:47] <wallyworld> axw: two small ones for whenever https://github.com/juju/utils/pull/247 https://github.com/juju/version/pull/4
[05:14] <wallyworld> axw: thanks for reviews. there's little that can be done for other usages of GetOSFromSeries() in juju - all cases require the OS to make a decision about something wrt cloud init and such. so i'll just update the deps
[05:15] <axw> okey dokey
[05:23] <wallyworld> damn, pulling in tip of utils breaks other apis, sigh
[09:21] <rogpeppe> anyone know ModelMachineInfo.Status is instance status or agent status?
[10:13] <rogpeppe> anyone around that may be able to do a review of a change to testing/checkers to ignore time zones when comparing times? https://github.com/juju/testing/pull/115
[10:14] <rogpeppe> dimitern: ^
[10:32] <dimitern> rogpeppe: looking
[10:32] <rogpeppe> dimitern: thanks!
[10:33] <rogpeppe> dimitern: are you all at the sprint this week?
[10:33] <dimitern> rogpeppe: thankfully, no :)
[10:33] <rogpeppe> dimitern: :)
[10:33] <rogpeppe> dimitern: just it seem very quiet here atm
[10:33] <dimitern> rogpeppe: LGTM, but I'm curious - why was that needed?
[10:34] <rogpeppe> dimitern: just a test failure due to two times being different only in zone (we were using UTC, bson unmarshals as local) and i got fed up. i've wanted to make this change for ages :)
[10:34] <dimitern> rogpeppe: quiet yes.. I'm tasked with making sure develop merges OK into staging though, so I haven't noticed :)
[12:07] <perrito666> morning all
[12:52] <zeestrat> Hey, when is 2.0.1 coming to the juju/stable PPA?
[13:27] <dimitern> mgz: ping
[13:30] <mgz> dimitern: yo
[13:31] <dimitern> mgz: hey, I've been watching the last few CI runs on develop
[13:31] <dimitern> mgz: any idea about the build errors?
[13:31] <mgz> the last few?
[13:31] <mgz> the earlier ones were from balloons changing the packaging branch
[13:32] <mgz> but those should be gone with the latest builds?
[13:32] <mgz> hm, something new
[13:32] <dimitern> latest one still has a few: http://reports.vapour.ws/releases/4540
[13:33] <mgz> also those results are misleading
[13:33] <mgz> hardly anything actually ran
[13:34] <mgz> there was talk about poking around with S3 on friday, I'll look and see what actually changed
[13:34] <dimitern> ok
[13:35] <dimitern> mgz: do you think we could merge develop into staging today, or we need a bless first?
[13:35] <mgz> ideally we get a bless, but of the last 10 runs most have failed due to non-juju code reasons
[13:36] <balloons> we do need a bless. I was hoping a PR would land so we'd get a testrun -- really nothing has landed?
[13:37] <balloons> ohh, no, it landed.. I see, weird
[13:37] <mgz> stuff has landed, we're stuck on the build/publish step
[13:37] <mgz> of xenial ppc64 build at least is blocking things
[13:37] <mgz> perhaps other stuff?
[13:37]  * mgz goes to clean up ppc64el-slave
[13:38] <mgz> which stilson are you today...
[13:40] <mgz> hm, 05 isn't actually out of disk
[13:47] <mgz> dimitern: I deleting a bunch of things from that machine and am trying a rerun of the ppc64 build job
[13:47] <dimitern> mgz: +1
[13:47] <mgz> that should unblock various things, obviously we have some config issues as well
[13:47] <mgz> as the jobs that failed shouldn't run before publish I presume
[13:54] <SimonKLB> who's involved with the juju charm store development?
[13:55] <SimonKLB> i renamed a user to use it's username for a team instead, launchpad seem ok with it, but it's not possible to make the changes migrate to the juju charm store
[13:55] <SimonKLB> or at least im not sure how to do it
[13:56] <natefinch> rogpeppe: ^
[13:57] <mgz> ah, standup is a different hour
[13:57] <mgz> thanks clocks...
[13:57] <natefinch> haha
[13:58] <natefinch> I laugh, but ours changes next week
[13:58] <mgz> yeah, then standup time will move again
[14:01] <mgz> hm, no katco today?
[14:02] <mgz> she appeareth
[14:04] <mgz> dimitern: standup!
[14:04] <mgz> also... other people who are around?
[14:04] <katco> dimitern: macgreag1ir: voidspace: frobware: standup time
[14:05] <voidspace> katco: oh, screw - our clocks changed and I forgot that changed standup time
[14:05] <voidspace> katco: omw
[14:05] <katco> no worries!
[14:06] <katco> dooferlad: standup time
[14:07] <dimitern> katco: isn't it in an hour's time?
[14:07] <natefinch> nope, you guys had daylight saving end and we haven't yet
[14:07] <mgz> dimitern: clocks, they are a changin'
[14:07] <natefinch> next week it'll be back to the same time
[14:07] <natefinch> since we end our saving time next week
[14:07] <natefinch> huzzah
[14:07] <katco> dimitern: confusion abounds
[14:07] <dimitern> oh I see
[14:07] <dimitern> omw then
[14:09] <rogpeppe> SimonKLB: I'm not sure exactly what you mean by "i renamed a user to use it's username for a team instead,"
[15:11] <rick_h___> rogpeppe: in SSO you can change the user be but that blows up on the chsrmstore without manual intervention
[15:11] <rogpeppe> rick_h___: yeah, we discussed it by PM
[15:12] <rick_h___> Ah cool
[15:12] <rogpeppe> rick_h___: my question above was because i found the grammar hard to parse
[15:15] <SimonKLB> my bad \o
[15:16] <SimonKLB> rick_h___: would deleting the user be sufficient? because i only have some test-charms pushed
[15:16] <SimonKLB> do whatever is the easiest for you guys
[15:21] <voidspace> dimitern: so for maas 2, "not_networks" needs to be changed in gomaasapi rather than in juju
[15:22] <dimitern> voidspace: for maas 2.1 only IIRC - let me double check
[15:22] <voidspace> dimitern: according to bug 163919 it's maas 2.0
[15:22] <mup> Bug #163919: didyouknow plugin bug <Exaile:Invalid> <https://launchpad.net/bugs/163919>
[15:22] <voidspace> uhm
[15:22] <voidspace> bug 1636919
[15:23] <mup> Bug #1636919: MAAS machine selected with space in violation of constraint <ci> <jujuqa> <maas-provider> <networking> <juju:Triaged> <MAAS:Invalid> <https://launchpad.net/bugs/1636919>
[15:23] <voidspace> dimitern: ah, no - it's an api change as well
[15:23] <voidspace> dimitern: (for gomaasapi)
[15:23] <voidspace> dimitern: juju needs to pass a slice of strings not a string
[15:23] <dimitern> voidspace: according to http://maas.ubuntu.com/docs2.0/api.html#machines - not_networks is still acceptable for API 2.0
[15:24] <voidspace> dimitern: I've pinged mpontillo on #juju (canonical)
[15:24] <voidspace> dimitern: no response yet, but I'll check with him
[15:25] <voidspace> dimitern: what maas API version do you see with 2.1? I don't have 2.1 setup
[15:26] <dimitern> voidspace: I've checked the source, but as for 2.1 API docs -  http://maas.ubuntu.com/docs2.1/api.html#machines still mentions not_networks and not "not_subnets"
[15:26] <dimitern> voidspace: I guess the docs were not updated recently
[15:26] <voidspace> dimitern: well, if they're incorrect for 2.1 they could be incorrect for 2.0 as well...
[15:26] <mgz> dimitern: I filed bugs
[15:27] <voidspace> dimitern: I'll find out
[15:27] <voidspace> mgz: the maas guys are at the sprint - as far as you know is "not_subnets" correct for 2.0 or only for 2.1?
[15:27] <mgz> for both
[15:27] <dimitern> voidspace: If all else fails, use the source :)
[15:27] <voidspace> dimitern: so you're saying that according to the source, "not_networks" is correct for 2.0?
[15:27] <voidspace> we don't officially support 2.1 yet anyway ;-)
[15:28] <mgz> bug 1637009 probably what you're most interested in
[15:28] <mup> Bug #1637009: [2.0,2.1] Node acquisition constraints API documentation needs to be updated to match reality <MAAS:In Progress by mpontillo> <MAAS 1.9:In Progress by mpontillo> <MAAS 2.0:In Progress by mpontillo> <https://launchpad.net/bugs/1637009>
[15:28]  * voidspace goes to checkout maas
[15:28] <dimitern> voidspace, yeah - I can confirm on the actual 2.0 vmaas here..
[15:28] <voidspace> dimitern: ah, so that's in contradiction to the bug that mgz just linked to
[15:28] <mgz> bug 1637182 and bug 1637192 also relevent
[15:28] <mup> Bug #1637182: Help and documentation 'list of unicodes' inconsistent <MAAS:In Progress by mpontillo> <MAAS 1.9:In Progress by mpontillo> <MAAS 2.0:In Progress by mpontillo> <https://launchpad.net/bugs/1637182>
[15:28] <mup> Bug #1637192: [2.0,2.1] Allocate using subnets or not_subnets with space fails <MAAS:Triaged by mpontillo> <MAAS 1.9:Triaged by mpontillo> <MAAS 2.0:Triaged by mpontillo> <https://launchpad.net/bugs/1637192>
[15:30] <mgz> and bug 1636250
[15:30] <mup> Bug #1636250: [2.1] machines allocate API returns a random machine if incorrect - parameters are used <MAAS:Fix Committed by andreserl> <https://launchpad.net/bugs/1636250>
[15:31] <mgz> not_networks is accepted and silently ignored on 2.0 and 2.1
[15:31] <dimitern> mgz: not quite: http://paste.ubuntu.com/23407376/
[15:33] <dimitern> mgz: for 2.1 - http://paste.ubuntu.com/23407383/
[15:33] <dimitern> but I'll test it with the MAAS CLI manually on both
[15:33] <mgz> what am I looking for there dimitern?
[15:34] <mgz> I only see (wrong) docstring matches for your grep
[15:35] <mgz> also, bugs document the pretty extensive testing I did for this across three maas versions
[15:37] <dimitern> mgz: I've tried `$ maas 21-root machines allocate dry_run=True not_subnets=space:0 verbose=True` on 2.1 and got `unorderable types: Subnet() < Subnet()`
[15:38] <dimitern> with not_networks there's no error, but it doesn't seem to work
[15:38] <mgz> dimitern: see bug 1637192 as linked above
[15:38] <mup> Bug #1637192: [2.0,2.1] Allocate using subnets or not_subnets with space fails <MAAS:Triaged by mpontillo> <MAAS 1.9:Triaged by mpontillo> <MAAS 2.0:Triaged by mpontillo> <https://launchpad.net/bugs/1637192>
[15:39] <mgz> there's a bit more background to that that's on a maas mailing list
[15:39] <mgz> but I think the bug has the conclusion at least
[16:33] <mpontillo> dimitern: the 'unorderable types' one is a bug in the error message. what we're trying to do is render a string that says something like "failed to match constraint: xyz", but when we go to figure out what to put in xyz we crash ;-)
[16:34] <mpontillo> dimitern: https://code.launchpad.net/~mpontillo/maas/update-constraints-docs--bugs-1637182-1637009/+merge/309617 clarifies the docs
[16:34] <dimitern> mpontillo: cheeers! :)
[16:39] <mpontillo> dimitern: but yeah, I can confirm that going from 1.x to 2.x we renamed the '[not_]networks' constraint to '[not_]subnets'. MAAS 2.1 was also recently changed to reject unknown constraints.
[16:40] <dimitern> mpontillo: so *both* 2.0 and 2.1 API only accept "not_subnets" (even if it doesn't complain in the former case) ?
[16:41] <mpontillo> dimitern: correct, when we moved to MAAS 2.x we made that change. we also dropped legacy 'connected_to' and 'not_connected_to' constraints in 2.x
[16:44] <dimitern> mpontillo: ok, thanks for confirming!
[16:45] <mpontillo> dimitern: voidspace: np. also, be aware when testing this that the corresponding *positive* constraints will probably not do what you expect. that is, 'subnets' and 'not_subnets' do not filter an inverse set of machines if multiple subnets match the specifier.
[16:46] <mpontillo> (long story short, only matching nodes *not* in a set of subnets is well-supported, if you try to pass in, for example, subnets:space:x and space x has 3 subnets, we'll try to find a node with all 3, which is probably not useful)
[16:47] <mpontillo> but that is more of a wishlist because this works as-expected when using the interfaces constraint.
[16:49] <voidspace> mpontillo: ok, thanks
[18:27] <redir> rick_h___: yt?
[18:54] <perrito666> voidspace: still working?
[18:54] <voidspace> perrito666: still around anyway
[18:55] <perrito666> voidspace: I am trying to determine an issue that is most likely unrelated to this but am getting a constant spam error because juju cant  SetLinkLayerDevices
[18:55] <perrito666> voidspace: how big of an issue is that error?
[18:55] <voidspace> perrito666: ah, I've seen that - I think it's spurious
[18:55] <perrito666> voidspace: apparently Its trying to use the same id for more than one thing
[18:56] <perrito666> voidspace: ack, I thought so
[18:56] <voidspace> perrito666: dimitern is really the one who needs to answer I'm afraid
[18:56] <perrito666> yep, blame said the same but he is not here :p
[18:56] <voidspace> perrito666: but I saw the same error when I was trying to diagnose a vsphere issue - and it had nothing to do with that error
[18:56] <perrito666> voidspace: yeah, same here
[18:56] <perrito666> :)
[18:57] <perrito666> spaces are blowing all over the place in vsphere
[18:58] <voidspace> perrito666: yeah, that needs fixing - it shouldn't error out if spaces aren't supported
[18:59] <voidspace> perrito666: if you file a bug I'll fix it ;-)
[19:02] <perrito666> voidspace: I dont have enough information, I believe this is actually causing a problem for me here
[20:04] <natefinch> perrito666: what auth types does vsphere allow?
[20:05] <natefinch> perrito666: just userpass?
[20:06] <natefinch> anyone else know?  Would be nice if our docs specified this :/
[20:07] <natefinch> looks like just userpass from the credential s chema
[20:11] <voidspace> natefinch: perrito666: I've only ever *seen* userpass...
[20:11] <voidspace> perrito666: actually, the specific issue I saw was "unrecognised type" for an interface, not id re-use
[20:11] <voidspace> perrito666: so that is "new"
[20:23] <babbageclunk> morning everyone! I'm in Hamilton!
[20:27] <perrito666> natefinch: I have the same experience as voidspace
[20:27] <perrito666> voidspace: I learned it was due to id reuse after digging into the code the error is completely misleading
[20:35] <redir> babbageclunk: congrats
[20:35] <veebers> babbageclunk: nice! Where is your final destination in NZ?
[20:37] <voidspace> perrito666: ah, ok
[20:39] <babbageclunk> veebers: uh, a grave somewhere I guess? ;)
[20:39] <babbageclunk> I mean, Welly.
[20:40] <babbageclunk> But we'll have a longish boringish interlude in Palmerston North while all our stuff is being shipped.
[20:44] <veebers> babbageclunk: wow dark. I love it
[20:44] <babbageclunk> veebers: I mean, Palmy's not that bad.
[20:44] <veebers> ^_^
[21:12] <perrito666> hey all, how do I pass availability zone to bootstrap?
[22:04] <mup> Bug #1637695 changed: Charm-guide: Openstack on LXD directions do not work <juju:New> <https://launchpad.net/bugs/1637695>
[23:13] <perrito666> Alexis wallyworld I'll be a few mins late to the standup sorry
[23:13] <wallyworld> np