[00:01] axw: review done [00:50] menn0: thanks, I'll run up a 1.25 env and test on there before I land [00:56] axw: great, thanks [01:42] axw: thanks for the edits [01:42] 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] menn0: so I'm inclined to just use Bulk for simplicity [01:43] axw: that SGTM [01:43] menn0: np [01:43] cool [01:43] axw: 3s for 10000 docs locally or on azure? [01:43] menn0: on azure [01:46] one last test with 2.0 on a fresh VM [01:54] axw: that seems like it should be fine to me [01:55] 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] if it's the same I'll shipit [01:55] axw: +1 [03:07] axw: when you have time, a small one, no rush https://github.com/juju/juju/pull/6516 [03:10] wallyworld: what is the "elsewhere" that tests the same functionality? [03:10] axw: test cases in testChangeRemoteApplications [03:13] wallyworld: LGTM [03:13] ty [03:47] 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] Bug #1637079: Upgrade stuck due to out-of-date distro-info-data package [03:48] wallyworld: SGTM, but does removing that get you all the way? [03:48] i think so, will check a bit more closely to try and be sure [03:51] 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] 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] maybe a 2.2 thing [03:55] wallyworld: seriously? I thought we fixed that to just upload one, and have the controller explode it into the various series [03:56] if we're uploading multiple times, I think we can fix that without changing the format at least [03:56] hmmm. maybe. i haven't checked in a while. maybe the tarball has grown so large it still take sages [03:56] it does take a long time [03:56] on ADSL yeah it does :-( [04:47] axw: two small ones for whenever https://github.com/juju/utils/pull/247 https://github.com/juju/version/pull/4 [05:14] 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] okey dokey [05:23] damn, pulling in tip of utils breaks other apis, sigh [09:21] anyone know ModelMachineInfo.Status is instance status or agent status? [10:13] 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] dimitern: ^ [10:32] rogpeppe: looking [10:32] dimitern: thanks! [10:33] dimitern: are you all at the sprint this week? [10:33] rogpeppe: thankfully, no :) [10:33] dimitern: :) [10:33] dimitern: just it seem very quiet here atm [10:33] rogpeppe: LGTM, but I'm curious - why was that needed? [10:34] 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] rogpeppe: quiet yes.. I'm tasked with making sure develop merges OK into staging though, so I haven't noticed :) === Guest79971 is now known as ahasenack === ahasenack is now known as Guest85272 [12:07] morning all [12:52] Hey, when is 2.0.1 coming to the juju/stable PPA? [13:27] mgz: ping [13:30] dimitern: yo [13:31] mgz: hey, I've been watching the last few CI runs on develop [13:31] mgz: any idea about the build errors? [13:31] the last few? [13:31] the earlier ones were from balloons changing the packaging branch [13:32] but those should be gone with the latest builds? [13:32] hm, something new [13:32] latest one still has a few: http://reports.vapour.ws/releases/4540 [13:33] also those results are misleading [13:33] hardly anything actually ran [13:34] there was talk about poking around with S3 on friday, I'll look and see what actually changed [13:34] ok [13:35] mgz: do you think we could merge develop into staging today, or we need a bless first? [13:35] ideally we get a bless, but of the last 10 runs most have failed due to non-juju code reasons [13:36] we do need a bless. I was hoping a PR would land so we'd get a testrun -- really nothing has landed? [13:37] ohh, no, it landed.. I see, weird [13:37] stuff has landed, we're stuck on the build/publish step [13:37] of xenial ppc64 build at least is blocking things [13:37] perhaps other stuff? [13:37] * mgz goes to clean up ppc64el-slave [13:38] which stilson are you today... [13:40] hm, 05 isn't actually out of disk [13:47] dimitern: I deleting a bunch of things from that machine and am trying a rerun of the ppc64 build job [13:47] mgz: +1 [13:47] that should unblock various things, obviously we have some config issues as well [13:47] as the jobs that failed shouldn't run before publish I presume [13:54] who's involved with the juju charm store development? [13:55] 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] or at least im not sure how to do it [13:56] rogpeppe: ^ [13:57] ah, standup is a different hour [13:57] thanks clocks... [13:57] haha [13:58] I laugh, but ours changes next week [13:58] yeah, then standup time will move again [14:01] hm, no katco today? [14:02] she appeareth [14:04] dimitern: standup! [14:04] also... other people who are around? [14:04] dimitern: macgreag1ir: voidspace: frobware: standup time [14:05] katco: oh, screw - our clocks changed and I forgot that changed standup time [14:05] katco: omw [14:05] no worries! [14:06] dooferlad: standup time [14:07] katco: isn't it in an hour's time? [14:07] nope, you guys had daylight saving end and we haven't yet [14:07] dimitern: clocks, they are a changin' [14:07] next week it'll be back to the same time [14:07] since we end our saving time next week [14:07] huzzah [14:07] dimitern: confusion abounds [14:07] oh I see [14:07] omw then [14:09] SimonKLB: I'm not sure exactly what you mean by "i renamed a user to use it's username for a team instead," === hml_ is now known as hml [15:11] rogpeppe: in SSO you can change the user be but that blows up on the chsrmstore without manual intervention [15:11] rick_h___: yeah, we discussed it by PM [15:12] Ah cool [15:12] rick_h___: my question above was because i found the grammar hard to parse [15:15] my bad \o [15:16] rick_h___: would deleting the user be sufficient? because i only have some test-charms pushed [15:16] do whatever is the easiest for you guys [15:21] dimitern: so for maas 2, "not_networks" needs to be changed in gomaasapi rather than in juju [15:22] voidspace: for maas 2.1 only IIRC - let me double check [15:22] dimitern: according to bug 163919 it's maas 2.0 [15:22] Bug #163919: didyouknow plugin bug [15:22] uhm [15:22] bug 1636919 [15:23] Bug #1636919: MAAS machine selected with space in violation of constraint

[15:23] dimitern: ah, no - it's an api change as well [15:23] dimitern: (for gomaasapi) [15:23] dimitern: juju needs to pass a slice of strings not a string [15:23] voidspace: according to http://maas.ubuntu.com/docs2.0/api.html#machines - not_networks is still acceptable for API 2.0 [15:24] dimitern: I've pinged mpontillo on #juju (canonical) [15:24] dimitern: no response yet, but I'll check with him [15:25] dimitern: what maas API version do you see with 2.1? I don't have 2.1 setup [15:26] 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] voidspace: I guess the docs were not updated recently [15:26] dimitern: well, if they're incorrect for 2.1 they could be incorrect for 2.0 as well... [15:26] dimitern: I filed bugs [15:27] dimitern: I'll find out [15:27] 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] for both [15:27] voidspace: If all else fails, use the source :) [15:27] dimitern: so you're saying that according to the source, "not_networks" is correct for 2.0? [15:27] we don't officially support 2.1 yet anyway ;-) [15:28] bug 1637009 probably what you're most interested in [15:28] Bug #1637009: [2.0,2.1] Node acquisition constraints API documentation needs to be updated to match reality [15:28] * voidspace goes to checkout maas [15:28] voidspace, yeah - I can confirm on the actual 2.0 vmaas here.. [15:28] dimitern: ah, so that's in contradiction to the bug that mgz just linked to [15:28] bug 1637182 and bug 1637192 also relevent [15:28] Bug #1637182: Help and documentation 'list of unicodes' inconsistent [15:28] Bug #1637192: [2.0,2.1] Allocate using subnets or not_subnets with space fails [15:30] and bug 1636250 [15:30] Bug #1636250: [2.1] machines allocate API returns a random machine if incorrect - parameters are used [15:31] not_networks is accepted and silently ignored on 2.0 and 2.1 [15:31] mgz: not quite: http://paste.ubuntu.com/23407376/ [15:33] mgz: for 2.1 - http://paste.ubuntu.com/23407383/ [15:33] but I'll test it with the MAAS CLI manually on both [15:33] what am I looking for there dimitern? [15:34] I only see (wrong) docstring matches for your grep [15:35] also, bugs document the pretty extensive testing I did for this across three maas versions [15:37] 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] with not_networks there's no error, but it doesn't seem to work [15:38] dimitern: see bug 1637192 as linked above [15:38] Bug #1637192: [2.0,2.1] Allocate using subnets or not_subnets with space fails [15:39] there's a bit more background to that that's on a maas mailing list [15:39] but I think the bug has the conclusion at least [16:33] 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] dimitern: https://code.launchpad.net/~mpontillo/maas/update-constraints-docs--bugs-1637182-1637009/+merge/309617 clarifies the docs [16:34] mpontillo: cheeers! :) [16:39] 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] 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] 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] mpontillo: ok, thanks for confirming! [16:45] 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] (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] but that is more of a wishlist because this works as-expected when using the interfaces constraint. [16:49] mpontillo: ok, thanks === Guest85272 is now known as ahasenack === ahasenack is now known as Guest84237 [18:27] rick_h___: yt? [18:54] voidspace: still working? [18:54] perrito666: still around anyway [18:55] 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] voidspace: how big of an issue is that error? [18:55] perrito666: ah, I've seen that - I think it's spurious [18:55] voidspace: apparently Its trying to use the same id for more than one thing [18:56] voidspace: ack, I thought so [18:56] perrito666: dimitern is really the one who needs to answer I'm afraid [18:56] yep, blame said the same but he is not here :p [18:56] 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] voidspace: yeah, same here [18:56] :) [18:57] spaces are blowing all over the place in vsphere [18:58] perrito666: yeah, that needs fixing - it shouldn't error out if spaces aren't supported [18:59] perrito666: if you file a bug I'll fix it ;-) [19:02] voidspace: I dont have enough information, I believe this is actually causing a problem for me here [20:04] perrito666: what auth types does vsphere allow? [20:05] perrito666: just userpass? [20:06] anyone else know? Would be nice if our docs specified this :/ [20:07] looks like just userpass from the credential s chema [20:11] natefinch: perrito666: I've only ever *seen* userpass... [20:11] perrito666: actually, the specific issue I saw was "unrecognised type" for an interface, not id re-use [20:11] perrito666: so that is "new" [20:23] morning everyone! I'm in Hamilton! [20:27] natefinch: I have the same experience as voidspace [20:27] voidspace: I learned it was due to id reuse after digging into the code the error is completely misleading [20:35] babbageclunk: congrats [20:35] babbageclunk: nice! Where is your final destination in NZ? [20:37] perrito666: ah, ok [20:39] veebers: uh, a grave somewhere I guess? ;) [20:39] I mean, Welly. [20:40] But we'll have a longish boringish interlude in Palmerston North while all our stuff is being shipped. [20:44] babbageclunk: wow dark. I love it [20:44] veebers: I mean, Palmy's not that bad. [20:44] ^_^ [21:12] hey all, how do I pass availability zone to bootstrap? [22:04] Bug #1637695 changed: Charm-guide: Openstack on LXD directions do not work [23:13] Alexis wallyworld I'll be a few mins late to the standup sorry [23:13] np