[00:09] davecheney: shipit [00:24] waigani: Your PR was used to test the new juju-core-slave. You have extra comments sorry. you might care about the last run which looks like a legitimate run https://github.com/juju/juju/pull/3883 [00:25] sinzui: okay, looking ... [00:34] sinzui: fixed, repushing [00:35] waigani: great I will watch to be sure your branch gets a fair test [00:35] sinzui: thanks :) [00:46] thumper: danka [00:51] mwhudson: go 1.5.2 was just released [00:51] davecheney: i saw it was close [00:51] well, they've tagged the branch [00:51] the binary artifacts will be coming soon [00:52] cool [00:52] * mwhudson runs away, will look later on === ses is now known as Guest54267 [02:07] poo [02:08] thumper: ? [02:08] found a bug in the migration steps for 1.21 [02:18] another one? [02:41] perrito666: yeah [02:42] * thumper goes to make coffee before he tears this apart [03:07] Bug #1522025 changed: juju upgrade-juju should confirm it has enough disk space to complete

[03:16] Bug #1522025 opened: juju upgrade-juju should confirm it has enough disk space to complete

[03:28] Bug #1522025 changed: juju upgrade-juju should confirm it has enough disk space to complete

[03:42] * thumper is not enjoying reading this code [03:45] davecheney: you ocr? got time to look at http://reviews.vapour.ws/r/3293 ? several of the files are new test charms or param renames [03:45] thumper: I've been having that feeling a lot lately [04:24] thumper: can i pull master and run up a multi-env controller without a feature flag yet? === Guest78115 is now known as jose [04:25] wallyworld: no [04:25] damn === jose is now known as Guest38423 [04:25] because I'm fixing bugs :) [04:25] not features [04:25] thumper: we're starting to need it for x-model work, i guess i could merge in your feature branch [04:26] um... [04:26] could do [04:26] or just use flag [04:26] oh fucking awesome [04:26] i'll use feature flag [04:26] * thumper headdesks [04:26] * thumper headdesks [04:26] * thumper headdesks [04:26] * thumper headdesks [04:26] * thumper headdesks [04:26] * thumper headdesks [04:26] * thumper headdesks [04:26] * thumper headdesks [04:26] lol [04:26] * thumper headdesks [04:26] ouch [04:27] a test is passing because it isn't doing the asserts it think its doing [04:27] lol [04:27] hope it's not my code [04:28] fuck fuck fuckity fuck [04:28] * thumper digs deeper === Guest38423 is now known as jose [04:31] davecheney: so about any reviews? [04:32] well, I added a line to make the test fail [04:32] which test? [04:40] state upgradeSuite.TestMigrateUnitPortsToOpenedPorts [06:31] thanks davecheney :-) [07:11] axw: thanks for review, questions answered plus a couple of changes, ptal when you are free [07:11] wallyworld: thanks, looking [07:18] wallyworld: shipit [07:18] axw: awesome, tyvm [09:52] * frobware wonders why in late 2015 he has a /boot partition which is 100MB in size because that's just too damn small... [10:28] dimitern, voidspace, dooferlad: I'm a little hosed atm. No working desktop. an upgrade gone wrong - lack of disk space seems to be root cause. [10:29] frobware, oh sh*t :/ [10:29] frobware, best of luck fixing it then [10:30] frobware: crumbs. Ask for help if you need it. [10:30] dooferlad, trying to chroot of a usb boot ... [10:32] frobware: have you tried a boot repair USB stick or a recovery mode with networking support boot? [10:32] chrooting seems painful [10:36] dooferlad, my genuine /boot has no working kernel. do you know if a 'boot repair' disk will add one? [10:38] frobware: ah, no. It seems to cover bad grub options, file system corruption and other bootloader related stuff, but not a missing kernel [10:39] dooferlad, mkinitramfs failed (enospace) so ... [10:39] frobware: you should be OK deleting old kernels and related junk from /boot and retrying that. As long as one kernel is left that works... [10:41] I have working kernels [10:41] correction: I have NO working kernels. [10:57] dimitern: can I have another review of http://reviews.vapour.ws/r/3294/ please? [11:01] dooferlad, sure - looking [11:04] dooferlad, replied [11:11] frobware: oh, ouch [11:16] frobware: dimitern: dooferlad: this PR adds a providerId field to spaces and a providerId parameter to AddSpace [11:16] http://reviews.vapour.ws/r/3307/ [11:16] it's a pre-req of my next couple of PRs [11:18] dimitern: passing spaces through as constraints to maas will obviously need to use ProviderId and not Name [11:18] dimitern: but if you make that change then the CLI command to add space will no longer work for maas spaces - you'll *need* space discovery [11:18] (which is coming) [11:18] so maybe don't make that change yet [11:25] voidspace, looking [11:25] voidspace, space add is not fully implemented [11:25] voidspace, so it should be fine there, and for space create we have the card to not allow it when SupportsSpaces is false [11:30] dimitern: ah, sorry - it was space create I meant [11:30] dimitern: and we won't actually need "space add" I don't think [11:30] dimitern: we'll really just need "space import" or whatever to update all definitions [11:31] dimitern: a subsequent PR of mine will be adding SupportsSpaceDiscovery to NetworkingEnviron [11:32] dimitern: so that will be the switch to disable space / subnet create [11:32] dimitern: frobware: fwereade: dooferlad: bike shed on name, agent API facade for space and subnet creation (agent not client) [11:33] dimitern: frobware: fwereade: dooferlad: "networking" ? [11:33] voidspace, name it for the worker [11:33] it's a bit too generic but it's also true [11:33] fwereade: ok, that's easy enough [11:33] voidspace, that's the granularity we're looking for [11:33] discoverspaces [11:33] fwereade: cool, thanks [11:35] time for a rename then :-) [11:38] voidspace, right - agreed about space import [11:38] voidspace, +1 for SupportsSpaceManagement instead FWIW [11:39] voidspace, reviewed btw [11:40] management means nothing [11:40] it's a weasel word [11:41] dimitern: thanks for the review [11:42] voidspace, well, "discovery" is a bit misleading as it implies we can't do discovery in other clouds *ever* [11:44] dimitern: it doesn't imply that [11:44] dimitern: when we *can* they'll return true [11:44] that's precisely the point of it [11:44] when we can support it for a provider the result of that method will change [11:44] dimitern: you want me to change BackingSubnetInfo.ProviderId to string? I didn't touch that in my PR [11:44] voidspace, ok, but then we can't forbid space create because discovery is not supported [11:45] dimitern: "create" means create it on the provider [11:45] dimitern: so we can forbid it where we can't create it on the provider [11:45] voidspace, not BackingSubnetInfo specifically [11:45] dimitern: that's the first issue you raised [11:45] BackingSubnetInfo specifically... [11:45] voidspace, but st.Subnet.ProviderId() returns network.Id [11:46] voidspace, well it doesn't but it should (and BackingSubnetInfo represents st.SubnetInfo) [11:47] dimitern: I think network.Id would probably be better here [11:47] ..which also uses string aargh.. [11:47] I can fix that too [11:47] it just adds work [11:47] voidspace, I'd like to use network.Id for anything user-facing w.r.t. provider ids [11:47] ok [11:47] I'll include those changes here [11:47] voidspace, doesn't have to happend now, if we store the correct value/type on the state doc [11:48] state/doc is using string [11:48] dimitern: should we use network.Id or string in mongo? [11:48] voidspace, yeah, as it should, but the related method that returns the provider id field value should cast it to network.Id [11:48] dimitern: threading network.Id throufh our code is fine [11:48] dimitern: I might as well do it now [11:49] voidspace, in mongo we use only native types or locally defined types in state [11:49] voidspace, ok, cheers [11:49] ok [11:49] voidspace, thanks [11:52] changed them, now to fix the 17 million things that break with type errors... :-D [11:52] at least the compiler tells me where they are... [11:57] dimitern: so state.SubnetInfo.ProviderId should also be network.Id [11:57] voidspace, yes [11:57] dimitern: cool [11:58] dimitern: so *really* ProvisioningInfo.SubnetsToZones should be map[network.Id][]string [11:58] dimitern: instead of map[string][]string [11:58] dimitern: but that would be an incompatible API change, so I'm going to leave it [11:58] voidspace, nope [11:59] dimitern: what do you mean by nope? :-) [11:59] voidspace, field types for api structs like mongo docs need to use types defined in the params (or state) package [11:59] nope I'm wrong, nope I shouldn't leave it, nope I'm right [11:59] so it shouldn't be network.Id [11:59] voidspace, not on the params [11:59] ok [12:00] dimitern: thanks [12:46] morning [12:48] perrito666: morning [12:59] * frobware celebrates the restoration of /boot with lunch [13:00] frobware: \o/ [13:02] voidspace, was pretty easy after I realised that the first couple of times I did the restore I was doing the restore to /boot which in /, which was in a LVM, but /boot should have been a physical partition... just forget to mount it during the chroot. :) [13:03] and during lunch I think we'll do a complete system backup. :) [13:04] cool [13:13] dimitern: ping [13:13] voidspace, pong [13:13] dimitern: one issue you said: [13:13] dimitern: After adding the index, here if err == nil, we should still try fetching the space back to see if it got added (see how AddNetworkInterface handles the similar case). [13:13] dimitern: do you mean AddSubnet rather than AddNetworkInterface? [13:13] dimitern: because if you mean AddNetworkInterface I can't find that code [13:14] dimitern: is it to handle where adding can fail silently, because the providerid isn't unique? [13:14] voidspace, AddNetworkInterface is in state/machine.go [13:14] dimitern: yes [13:14] dimitern: but there's no code as you describe in that method... [13:15] voidspace, the switch at the end - case nil: ? [13:15] whereas I *think* what you mean is the case in AddSubnet but I want to check I'm understanding you [13:15] dimitern: oh right, I missed that [13:16] dimitern: yuck, that's horrible code [13:16] voidspace, but yeah - AddSubnet is actually a better (simpler) example [13:16] how did I miss that [13:16] voidspace, since the check is the same - providerid unique when != "" [13:16] but anyway, I'll follow the AddSubnet pattern if it's doing the same thing [13:17] voidspace, I'm refactoring AddNetworkInterface to be less icky hopefully :) [13:17] ah, I grepped for AddNetworkInterface and found it in SetInstanceInfo [13:17] and was reading that code [13:17] cool [13:17] SetInstanceInfo *calls* AddNetworkInterface, but it isn't AddNetworkInterface... :-) === Ursinha_ is now known as Ursinha [13:44] Bug #1522409 opened: juju machine 0 watcher unable to connect to units

[14:36] food for thought: state/State has 195 *exported* methods [14:40] dimitern, voidspace, dooferlad: PTAL @ http://reviews.vapour.ws/r/3308/ [14:40] dooferlad, you've got another review btw [14:41] dimitern, voidspace, dooferlad: too many distractions ^ that was a merge of the wrong branch in my repo [14:41] frobware, if it's a straight forward revert, just land it I think [14:42] frobware, except - I'll add a comment [14:43] frobware, the head -n1 added with my recent PR is not there when getting the gateway [14:43] frobware, ah, sorry - it is actually [14:45] dimitern, it's still there post the revert? [14:45] frobware, it is (in the expectedBlaBalCloudConfig) [14:45] (the one with the bridge script) [14:48] dimitern, I was confused why my cherry-pick for the bond change was not clean - now I know why... sigh. [14:48] frobware, well, good catch :) [15:56] voidspace, ping [15:58] dimitern: pong [15:59] voidspace, in case you're having issues with the ProviderId index (as I'm discovering now) [16:00] dimitern: I am... [16:00] dimitern: well, sort of [16:00] it's causing unrelated bindings tests to fail [16:00] but a worse problem right now is that my space tests don't appear to be running [16:00] voidspace, I *think* the correct solution is only verify for uniqueness if ProviderId != "" [16:01] dimitern: I thought that's what sparse did [16:01] voidspace, well, yeah, but since ProviderId is also omitempty, it will be missing [16:01] if not set [16:02] "" != {$exists, false} as it happens [16:02] ok [16:02] dimitern: that's exactly how ProviderId on Subnets is defined though [16:02] voidspace, well, it might be different for subnet.. but for NICs I'm having a bunch of issues, still debugging the Add.. call [16:02] omitempty but with a unique, sparse index [16:03] dimitern: ok [16:03] I'm adding it to space - but just following what we did with subnets [16:04] voidspace, well, that sounds sensible for subnets, but after spending >1h fiddling with indices, uniqueness, etc. I'm beginning to think having ProviderId defined like that for NICs is not a good idea [16:05] dimitern: heh, fun [16:06] e.g. imagine machine-0 with eth0 with aa:bb:cc:dd:ee:f0 for mac, "0.1.2.0/24" for subnet, there's no trouble having eth0 (same mac and all), but on subnet "2001:db8::/64" [16:06] dammit SpacesSuite is not being run at all [16:06] voidspace, sh*t! really? [16:06] well, not on my machine right now [16:06] it maybe a general problem [16:07] voidspace, it might be due to the order of go test args (as I've discovered: -check.v -check.f *and* -race and/or -cover never finds the -check.f) [16:08] dimitern: no args except package [16:08] (I was originally trying with -check.f - but even without it I'm not seeing my deliberately failing tests) [16:08] same with subnets test [16:08] what the hell is going on [16:10] voidspace, state.ConnSuite logs the beginning and end of SetUpTest btw - e.g. with -check.vv [16:10] voidspace, I found also -check.list useful [16:11] thanks [16:13] dimitern: soooo... changing state/package_test.go from the state package to the state_test package seems to have changed things [16:13] now I get build failures [16:15] voidspace, wow - and here's davecheney who changed that recently :) [16:16] dimitern: that change means that most state tests don't run [16:18] voidspace, it's gets weirder - grep for MgoTestPackage in state/ [16:19] voidspace, uh, no actually no surprises there [16:19] heh [16:20] voidspace, that's a bug right there - https://github.com/juju/juju/pull/3806/files#diff-d4970ae51fd6268f6325442698dbe02a [16:20] yeah, wrong package :-) [16:20] oops... [16:21] voidspace, that was 10 days ago! [16:21] it took me about an hour or so just now to track it down [16:21] I wonder how nobody found out [16:21] couldn't work out why my tests weren't running [16:22] happy belated birthday wwitzel3 ! [16:22] I'm filing a bug [16:23] dimitern: thanks [16:23] alexisb: thanks :) [16:32] dimitern: frobware: meeting? [16:33] Bug #1522484 opened: state package tests no longer run since PR #3806

[16:45] dimitern: I'm going to run state tests on maas-spaces [16:45] dimitern, voidspace, dooferlad: ok to rebase our maas-spaces when the state fix lands? [16:45] voidspace, sgmt [16:45] dimitern: I have a bunch of endpoint_bindings tests fail - and I can't tell if they're caused by my changes or not [16:45] sgtm even [16:45] frobware: go for it [16:46] frobware, I'd rather deal with the conflicts than let more regressions slip by :) [16:46] dimitern: and it looks like that unique index on provider id is causing me issues [16:46] voidspace, I'll have a look there and propose a fix if needed [16:46] I add three spaces with empty provider ids and then AllSpaces only returns one space [16:46] dimitern: cool [16:46] damn :/ [16:46] adding that check in AddSpace to see if silent failure is the cause of that [16:47] we'll see [16:48] if it is the problem I'll need to check we don't have the same problem with subnets which use the same pattern [16:48] maybe we have that problem but just haven't hit it because we always have a providerid [16:49] voidspace, I'm reading https://docs.mongodb.org/v2.4/core/index-sparse/ now - it seems unique+sparse might not be what we need actually [16:49] right [16:50] dimitern: it sounds exactly right [16:50] dimitern: [16:50] You can specify a sparse and unique index, that rejects documents that have duplicate values for a field, but allows multiple documents that omit that key. [16:51] voidspace, ok, then we should not use that index I think [16:51] voidspace, we can verify while adding that there's no existing space with the given non-empty provider id [16:51] dimitern: eh, it sounds exactly like what we want [16:51] hmmm... [16:52] dimitern: I don't have the failing tests on maas-spaces, so introduced by my changes [16:52] voidspace, AIUI you can have both doc{id:"foo", providerid:"bar"} and doc{id:"foo1"}, but then you can't have doc{id:"foo2"} as well [16:52] dimitern: see their example [16:52] at the bottom of that page [16:53] you can [16:53] voidspace, hmm well it sounds reasonable.. [16:53] but I can't seem to make it work for NICs [16:53] it certainly *seems* like what we want [16:53] dimitern: are you using omitempty? [16:54] voidspace, yep [16:54] ok [16:54] ah, well.. perhaps it's because I'm over-complicating things as usual [16:55] voidspace, in cases where we need uniqueness on multiple fields, what does work fine and it's easy to verify is a compound _id field, like a global key [16:57] Bug #1517258 changed: juju 1.24.7 precise: container failed to start and was destroyed

[16:57] but still coupled with individual fields having values used in the compound key - e.g. 8e5a492b-7631-409b-8134-7997678d731e:m#4/lxc/4#n#juju-public + EnvUUID + MachineId + NetworkName (on ports) [16:58] dimitern: http://stackoverflow.com/questions/28183109/dealing-with-mongodb-unique-sparse-compound-indexes [16:58] it seems like unique and sparse don't work together well for compound indices [16:58] so it's probably currently broken for subnetsC [16:58] voidspace, yeah, that's what I've (re)discovered I guess [16:59] voidspace, not necessarily, as both spaces and subnets + provider id act similarly; but it's definitely broken for network interfaces docs [17:00] (I mean there are no compound indices effectively, as env-uuid+field_name is always set) [17:00] ah, subnetsC isn't compound [17:01] dimitern: I was trying to make spacesC compound on env-uuid [17:01] I'll have to leave that as a TODO [17:01] frobware, voidspace, btw I see no failures in state/ on maas-spaces tip after changing package_test.go's package to state_test [17:02] dimitern: yeah, I tried it too and saw no failure [17:02] so rebase might wait [17:02] I think most of my failures were actually caused by the index problem [17:02] about to find out [17:02] voidspace, yeah, sorry for steering you down that rat hole :( [17:03] well, it's what we *should* do [17:03] not your fault mongodb is broken [17:03] :) cheers [17:11] voidspace, what I've just noticed is even weirder - I see exactly the same number of tests passing (1245) in state/ for almost the same time (~198s) both with and without the change in package_test.go [17:12] voidspace, when I run go test -check.f in state/ [17:12] ericsnow: I made a slight modification of the apiClient code, to remove the need for the resourceAPIClient type.... let me know what you think: http://reviews.vapour.ws/r/3310/diff/# (feel free to ignore the upload stuff in there, since it's still a WIP). I know you made changes around that code too, but wanted to get your opinion of what I did. [17:12] that is odd [17:13] voidspace, however I suspect it's different for go test github.com/juju/juju/state -check.v [17:13] ericsnow: it also makes the function you have to write for every command completely trivial, which is nice. Just a little adapter === ses is now known as Guest17653 [17:15] natefinch: looking [17:16] ericsnow: I haven't updated tests yet, obviously. [17:19] voidspace, same result with go test github.com/juju/juju/state -check.v and unpatched package_test [17:20] (albeit without any output) [17:20] dimitern: I wonder if we have some black box state tests then [17:20] and we need both [17:21] dimitern: e.g. compat_test.go is in the state package [17:21] dimitern: allwatcher_internal_test is as well [17:23] voidspace, yeah, same for the upgrades [17:26] hi mgz, cherylj - is 1.25.2 avail in a ppa anywhere atm? [17:26] beisner: no, not yet [17:28] heh what do you know.. go test ./... -check.list almost managed to bring the quad core i7 to its knees [17:28] dimitern: PR updated, all those issues addressed by the way [17:28] voidspace, awesome! having a look now.. [17:29] dimitern: small change, touches 25 files... [17:31] voidspace, does it still work if the spacesC and subnetsC index was defined as Key: []string{"env-uuid", "provider"}, Unique: true, Sparse: true? [17:31] dimitern: no [17:31] dimitern: causes failures [17:31] dimitern: the sparse is then ignored [17:32] voidspace, won't we have the issue where you can't have a space with no provider id in 2 different environments? [17:32] voidspace, or with the same provider id for that matter [17:32] dimitern: yes [17:32] dimitern: but we already have that with subnets and a TODO to fix it... [17:32] not good enough? [17:33] voidspace, ok, fair enough [17:33] how about we add a card for fixing both to the iteration backlog [17:33] voidspace, just checking the options ;) [17:33] cool [17:33] voidspace, +1 [17:34] voidspace, lgtm [17:35] thanks [17:35] I thought that would take an hour at the start of the day [17:35] took a bit longer... [17:36] voidspace, gotta love mongo, right? :D [17:36] right, back to the api [17:36] dimitern: yeah... and our testing infrastructure [17:36] ok time to call it a day [17:37] dimitern: o/ [17:38] voidspace, :) [17:41] voidspace, dooferlad, dimitern: Strike 2 - http://reviews.vapour.ws/r/3311/ - this is the correct branch for the change I reverted earlier. [17:43] frobware: as it's just a forward port, ShipIt! [17:43] voidspace, ty [17:58] rick_h_, hadn't forgotten your HA question - just got a little sidetracked with a broken desktop... [17:58] frobware: I forgot the question now heh [17:59] rick_h_, HA for OpenStack. Reference platform is 28 nodes. Need to look at the charm to see if that's always the case. [17:59] rick_h_, if so think I'll enter the h/w business. :) [17:59] frobware: :/ ok I think this was more can we do HA on Juju vs openstack on guimaas [18:02] rick_h_, my 28 came from: https://wiki.ubuntu.com/ServerTeam/OpenStackHA [18:02] frobware: right, I don't think I was asking about openstack HA [18:02] frobware: but "can I deploy openstack (6? 8?) nodes and have Juju be HA there [18:02] rick_h_, so not being at the beginning of the call I think I've missed the context. [18:02] frobware: to test upgrades of that deployment [18:03] rick_h_, ok gotcha [18:03] frobware: how small can I get a functioning OS and have Juju HA state servers is what I'd like to see [18:03] frobware: and then investigate growth of the test case from there [19:12] Bug #1522544 opened: workers restart endlessly === ericsnow is now known as ericsnow_afk [20:00] morning folks [20:04] morning thumper. Happy friday [20:09] o/ thumper [20:24] wwitzel3: ping me via email when/if your branch is ready and I'll see what I can do to integrate with it. [20:28] thumper, when do you head to the airport? [20:29] alexisb: tomorrow lunch time [20:30] thumper, aw ok [20:35] back later === natefinch is now known as natefinch-afk [20:47] ok, I have a fix for this 1.21 upgrade step [20:52] why do we have no reviewers today? [20:52] http://reviews.vapour.ws/r/3313/diff/# [20:52] someone plz [20:53] cherylj, waigani, or davecheney? ^^^ [20:57] thumper: tal now [20:57] ta [22:05] ok, time for coffee... again [23:15] axw: perrito666: a minute late [23:15] k === ericsnow_afk is now known as ericsnow