[00:09] <thumper> davecheney: shipit
[00:24] <sinzui> 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] <waigani> sinzui: okay, looking ...
[00:34] <waigani> sinzui: fixed, repushing
[00:35] <sinzui> waigani: great I will watch to be sure your branch gets a fair test
[00:35] <waigani> sinzui: thanks :)
[00:46] <davecheney> thumper: danka
[00:51] <davecheney> mwhudson: go 1.5.2 was just released
[00:51] <mwhudson> davecheney: i saw it was close
[00:51] <davecheney> well, they've tagged the branch
[00:51] <davecheney> the binary artifacts will be coming soon
[00:52] <mwhudson> cool
[00:52]  * mwhudson runs away, will look later on
[02:07] <thumper> poo
[02:08] <davecheney> thumper: ?
[02:08] <thumper> found a bug in the migration steps for 1.21
[02:18] <perrito666> another one?
[02:41] <thumper> perrito666: yeah
[02:42]  * thumper goes to make coffee before he tears this apart
[03:07] <mup> Bug #1522025 changed: juju upgrade-juju should confirm it has enough disk space to complete <upgrade-juju> <juju-core:New> <https://launchpad.net/bugs/1522025>
[03:16] <mup> Bug #1522025 opened: juju upgrade-juju should confirm it has enough disk space to complete <upgrade-juju> <juju-core:New> <https://launchpad.net/bugs/1522025>
[03:28] <mup> Bug #1522025 changed: juju upgrade-juju should confirm it has enough disk space to complete <upgrade-juju> <juju-core:New> <https://launchpad.net/bugs/1522025>
[03:42]  * thumper is not enjoying reading this code
[03:45] <wallyworld> 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] <natefinch> thumper: I've been having that feeling a lot lately
[04:24] <wallyworld> thumper: can i pull master and run up a multi-env controller without a feature flag yet?
[04:25] <thumper> wallyworld: no
[04:25] <wallyworld> damn
[04:25] <thumper> because I'm fixing bugs :)
[04:25] <thumper> not features
[04:25] <wallyworld> thumper: we're starting to need it for x-model work, i guess i could merge in your feature branch
[04:26] <thumper> um...
[04:26] <thumper> could do
[04:26] <wallyworld> or just use flag
[04:26] <thumper> oh fucking awesome
[04:26] <wallyworld> 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] <wallyworld> lol
[04:26]  * thumper headdesks
[04:26] <wallyworld> ouch
[04:27] <thumper> a test is passing because it isn't doing the asserts it think its doing
[04:27] <natefinch> lol
[04:27] <wallyworld> hope it's not my code
[04:28] <thumper> fuck fuck fuckity fuck
[04:28]  * thumper digs deeper
[04:31] <wallyworld> davecheney: so about any reviews?
[04:32] <thumper> well, I added a line to make the test fail
[04:32] <wallyworld> which test?
[04:40] <thumper> state upgradeSuite.TestMigrateUnitPortsToOpenedPorts
[06:31] <wallyworld> thanks davecheney :-)
[07:11] <wallyworld> axw: thanks for review, questions answered plus a couple of changes, ptal when you are free
[07:11] <axw> wallyworld: thanks, looking
[07:18] <axw> wallyworld: shipit
[07:18] <wallyworld> 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] <frobware> 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] <dimitern> frobware, oh sh*t :/
[10:29] <dimitern> frobware, best of luck fixing it then
[10:30] <dooferlad> frobware: crumbs. Ask for help if you need it.
[10:30] <frobware> dooferlad, trying to chroot of a usb boot ...
[10:32] <dooferlad> frobware: have you tried a boot repair USB stick or a recovery mode with networking support boot?
[10:32] <dooferlad> chrooting seems painful
[10:36] <frobware> dooferlad, my genuine /boot has no working kernel. do you know if a 'boot repair' disk will add one?
[10:38] <dooferlad> 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] <frobware> dooferlad, mkinitramfs failed (enospace) so ...
[10:39] <dooferlad> 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] <frobware> I have working kernels
[10:41] <frobware> correction: I have NO working kernels.
[10:57] <dooferlad> dimitern: can I have another review of http://reviews.vapour.ws/r/3294/ please?
[11:01] <dimitern> dooferlad, sure - looking
[11:04] <dimitern> dooferlad, replied
[11:11] <voidspace> frobware: oh, ouch
[11:16] <voidspace> frobware: dimitern: dooferlad: this PR adds a providerId field to spaces and a providerId parameter to AddSpace
[11:16] <voidspace> http://reviews.vapour.ws/r/3307/
[11:16] <voidspace> it's a pre-req of my next couple of PRs
[11:18] <voidspace> dimitern: passing spaces through as constraints to maas will obviously need to use ProviderId and not Name
[11:18] <voidspace> 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] <voidspace> (which is coming)
[11:18] <voidspace> so maybe don't make that change yet
[11:25] <dimitern> voidspace, looking
[11:25] <dimitern> voidspace, space add is not fully implemented
[11:25] <dimitern> 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] <voidspace> dimitern: ah, sorry - it was space create I meant
[11:30] <voidspace> dimitern: and we won't actually need "space add" I don't think
[11:30] <voidspace> dimitern: we'll really just need "space import" or whatever to update all definitions
[11:31] <voidspace> dimitern: a subsequent PR of mine will be adding SupportsSpaceDiscovery to NetworkingEnviron
[11:32] <voidspace> dimitern: so that will be the switch to disable space / subnet create
[11:32] <voidspace> dimitern: frobware: fwereade: dooferlad: bike shed on name, agent API facade for space and subnet creation (agent not client)
[11:33] <voidspace> dimitern: frobware: fwereade: dooferlad: "networking" ?
[11:33] <fwereade> voidspace, name it for the worker
[11:33] <voidspace> it's a bit too generic but it's also true
[11:33] <voidspace> fwereade: ok, that's easy enough
[11:33] <fwereade> voidspace, that's the granularity we're looking for
[11:33] <voidspace> discoverspaces
[11:33] <voidspace> fwereade: cool, thanks
[11:35] <voidspace> time for a rename then :-)
[11:38] <dimitern> voidspace, right - agreed about space import
[11:38] <dimitern> voidspace, +1 for SupportsSpaceManagement instead FWIW
[11:39] <dimitern> voidspace, reviewed btw
[11:40] <voidspace> management means nothing
[11:40] <voidspace> it's a weasel word
[11:41] <voidspace> dimitern: thanks for the review
[11:42] <dimitern> voidspace, well, "discovery" is a bit misleading as it implies we can't do discovery in other clouds *ever*
[11:44] <voidspace> dimitern: it doesn't imply that
[11:44] <voidspace> dimitern: when we *can* they'll return true
[11:44] <voidspace> that's precisely the point of it
[11:44] <voidspace> when we can support it for a provider the result of that method will change
[11:44] <voidspace> dimitern: you want me to change BackingSubnetInfo.ProviderId to string? I didn't touch that in my PR
[11:44] <dimitern> voidspace, ok, but then we can't forbid space create because discovery is not supported
[11:45] <voidspace> dimitern: "create" means create it on the provider
[11:45] <voidspace> dimitern: so we can forbid it where we can't create it on the provider
[11:45] <dimitern> voidspace, not BackingSubnetInfo specifically
[11:45] <voidspace> dimitern: that's the first issue you raised
[11:45] <voidspace> BackingSubnetInfo specifically...
[11:45] <dimitern> voidspace, but st.Subnet.ProviderId() returns network.Id
[11:46] <dimitern> voidspace, well it doesn't but it should (and BackingSubnetInfo represents st.SubnetInfo)
[11:47] <voidspace> dimitern: I think network.Id would probably be better here
[11:47] <dimitern> ..which also uses string aargh..
[11:47] <voidspace> I can fix that too
[11:47] <voidspace> it just adds work
[11:47] <dimitern> voidspace, I'd like to use network.Id for anything user-facing w.r.t. provider ids
[11:47] <voidspace> ok
[11:47] <voidspace> I'll include those changes here
[11:47] <dimitern> voidspace, doesn't have to happend now, if we store the correct value/type on the state doc
[11:48] <voidspace> state/doc is using string
[11:48] <voidspace> dimitern: should we use network.Id or string in mongo?
[11:48] <dimitern> voidspace, yeah, as it should, but the related method that returns the provider id field value should cast it to network.Id
[11:48] <voidspace> dimitern: threading network.Id throufh our code is fine
[11:48] <voidspace> dimitern: I might as well do it now
[11:49] <dimitern> voidspace, in mongo we use only native types or locally defined types in state
[11:49] <dimitern> voidspace, ok, cheers
[11:49] <voidspace> ok
[11:49] <dimitern> voidspace, thanks
[11:52] <voidspace> changed them, now to fix the 17 million things that break with type errors... :-D
[11:52] <voidspace> at least the compiler tells me where they are...
[11:57] <voidspace> dimitern: so state.SubnetInfo.ProviderId should also be network.Id
[11:57] <dimitern> voidspace, yes
[11:57] <voidspace> dimitern: cool
[11:58] <voidspace> dimitern: so *really* ProvisioningInfo.SubnetsToZones should be map[network.Id][]string
[11:58] <voidspace> dimitern: instead of map[string][]string
[11:58] <voidspace> dimitern: but that would be an incompatible API change, so I'm going to leave it
[11:58] <dimitern> voidspace, nope
[11:59] <voidspace> dimitern: what do you mean by nope? :-)
[11:59] <dimitern> voidspace, field types for api structs like mongo docs need to use types defined in the params (or state) package
[11:59] <voidspace> nope I'm wrong, nope I shouldn't leave it, nope I'm right
[11:59] <voidspace> so it shouldn't be network.Id
[11:59] <dimitern> voidspace, not on the params
[11:59] <voidspace> ok
[12:00] <voidspace> dimitern: thanks
[12:46] <perrito666> morning
[12:48] <voidspace> perrito666: morning
[12:59]  * frobware celebrates the restoration of /boot with lunch
[13:00] <voidspace> frobware: \o/
[13:02] <frobware> 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] <frobware> and during lunch I think we'll do a complete system backup. :)
[13:04] <voidspace> cool
[13:13] <voidspace> dimitern: ping
[13:13] <dimitern> voidspace, pong
[13:13] <voidspace> dimitern: one issue you said:
[13:13] <voidspace> 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] <voidspace> dimitern: do you mean AddSubnet rather than AddNetworkInterface?
[13:13] <voidspace> dimitern: because if you mean AddNetworkInterface I can't find that code
[13:14] <voidspace> dimitern: is it to handle where adding can fail silently, because the providerid isn't unique?
[13:14] <dimitern> voidspace, AddNetworkInterface is in state/machine.go
[13:14] <voidspace> dimitern: yes
[13:14] <voidspace> dimitern: but there's no code as you describe in that method...
[13:15] <dimitern> voidspace, the switch at the end - case nil: ?
[13:15] <voidspace> whereas I *think* what you mean is the case in AddSubnet but I want to check I'm understanding you
[13:15] <voidspace> dimitern: oh right, I missed that
[13:16] <voidspace> dimitern: yuck, that's horrible code
[13:16] <dimitern> voidspace, but yeah - AddSubnet is actually a better (simpler) example
[13:16] <voidspace> how did I miss that
[13:16] <dimitern> voidspace, since the check is the same - providerid unique when != ""
[13:16] <voidspace> but anyway, I'll follow the AddSubnet pattern if it's doing the same thing
[13:17] <dimitern> voidspace, I'm refactoring AddNetworkInterface to be less icky hopefully :)
[13:17] <voidspace> ah, I grepped for AddNetworkInterface and found it in SetInstanceInfo
[13:17] <voidspace> and was reading that code
[13:17] <voidspace> cool
[13:17] <voidspace> SetInstanceInfo *calls* AddNetworkInterface, but it isn't AddNetworkInterface... :-)
[13:44] <mup> Bug #1522409 opened: juju machine 0 watcher unable to connect to units <sts> <juju-core:New> <https://launchpad.net/bugs/1522409>
[14:36] <ericsnow> food for thought: state/State has 195 *exported* methods
[14:40] <frobware> dimitern, voidspace, dooferlad: PTAL @ http://reviews.vapour.ws/r/3308/
[14:40] <dimitern> dooferlad, you've got another review btw
[14:41] <frobware> dimitern, voidspace, dooferlad: too many distractions ^ that was a merge of the wrong branch in my repo
[14:41] <dimitern> frobware, if it's a straight forward revert, just land it I think
[14:42] <dimitern> frobware, except - I'll add a comment
[14:43] <dimitern> frobware, the head -n1 added with my recent PR is not there when getting the gateway
[14:43] <dimitern> frobware, ah, sorry - it is actually
[14:45] <frobware> dimitern, it's still there post the revert?
[14:45] <dimitern> frobware, it is (in the expectedBlaBalCloudConfig)
[14:45] <dimitern> (the one with the bridge script)
[14:48] <frobware> dimitern, I was confused why my cherry-pick for the bond change was not clean - now I know why... sigh.
[14:48] <dimitern> frobware, well, good catch :)
[15:56] <dimitern> voidspace, ping
[15:58] <voidspace> dimitern: pong
[15:59] <dimitern> voidspace, in case you're having issues with the ProviderId index (as I'm discovering now)
[16:00] <voidspace> dimitern: I am...
[16:00] <voidspace> dimitern: well, sort of
[16:00] <voidspace> it's causing unrelated bindings tests to fail
[16:00] <voidspace> but a worse problem right now is that my space tests don't appear to be running
[16:00] <dimitern> voidspace, I *think* the correct solution is only verify for uniqueness if ProviderId != ""
[16:01] <voidspace> dimitern: I thought that's what sparse did
[16:01] <dimitern> voidspace, well, yeah, but since ProviderId is also omitempty, it will be missing
[16:01] <dimitern> if not set
[16:02] <dimitern> "" != {$exists, false} as it happens
[16:02] <voidspace> ok
[16:02] <voidspace> dimitern: that's exactly how ProviderId on Subnets is defined though
[16:02] <dimitern> 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] <voidspace> omitempty but with a unique, sparse index
[16:03] <voidspace> dimitern: ok
[16:03] <voidspace> I'm adding it to space - but just following what we did with subnets
[16:04] <dimitern> 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] <voidspace> dimitern: heh, fun
[16:06] <dimitern> 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] <voidspace> dammit SpacesSuite is not being run at all
[16:06] <dimitern> voidspace, sh*t! really?
[16:06] <voidspace> well, not on my machine right now
[16:06] <voidspace> it maybe a general problem
[16:07] <dimitern> 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] <voidspace> dimitern: no args except package
[16:08] <voidspace> (I was originally trying with -check.f - but even without it I'm not seeing my deliberately failing tests)
[16:08] <voidspace> same with subnets test
[16:08] <voidspace> what the hell is going on
[16:10] <dimitern> voidspace, state.ConnSuite logs the beginning and end of SetUpTest btw - e.g. with -check.vv
[16:10] <dimitern> voidspace, I found also -check.list useful
[16:11] <voidspace> thanks
[16:13] <voidspace> dimitern: soooo... changing state/package_test.go from the state package to the state_test package seems to have changed things
[16:13] <voidspace> now I get build failures
[16:15] <dimitern> voidspace, wow - and here's davecheney who changed that recently :)
[16:16] <voidspace> dimitern: that change means that most state tests don't run
[16:18] <dimitern> voidspace, it's gets weirder - grep for MgoTestPackage in state/
[16:19] <dimitern> voidspace, uh, no actually no surprises there
[16:19] <voidspace> heh
[16:20] <dimitern> voidspace, that's a bug right there - https://github.com/juju/juju/pull/3806/files#diff-d4970ae51fd6268f6325442698dbe02a
[16:20] <voidspace> yeah, wrong package :-)
[16:20] <voidspace> oops...
[16:21] <dimitern> voidspace, that was 10 days ago!
[16:21] <voidspace> it took me about an hour or so just now to track it down
[16:21] <dimitern> I wonder how nobody found out
[16:21] <voidspace> couldn't work out why my tests weren't running
[16:22] <alexisb> happy belated birthday wwitzel3 !
[16:22] <dimitern> I'm filing a bug
[16:23] <voidspace> dimitern: thanks
[16:23] <wwitzel3> alexisb: thanks :)
[16:32] <voidspace> dimitern: frobware: meeting?
[16:33] <mup> Bug #1522484 opened: state package tests no longer run since PR #3806 <blocker> <ci> <regression> <unit-tests> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1522484>
[16:45] <voidspace> dimitern: I'm going to run state tests on maas-spaces
[16:45] <frobware> dimitern, voidspace, dooferlad: ok to rebase our maas-spaces when the state fix lands?
[16:45] <dimitern> voidspace, sgmt
[16:45] <voidspace> 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] <dimitern> sgtm even
[16:45] <dooferlad> frobware: go for it
[16:46] <dimitern> frobware, I'd rather deal with the conflicts than let more regressions slip by :)
[16:46] <voidspace> dimitern: and it looks like that unique index on provider id is causing me issues
[16:46] <dimitern> voidspace, I'll have a look there and propose a fix if needed
[16:46] <voidspace> I add three spaces with empty provider ids and then AllSpaces only returns one space
[16:46] <voidspace> dimitern: cool
[16:46] <dimitern> damn :/
[16:46] <voidspace> adding that check in AddSpace to see if silent failure is the cause of that
[16:47] <voidspace> we'll see
[16:48] <voidspace> 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] <voidspace> maybe we have that problem but just haven't hit it because we always have a providerid
[16:49] <dimitern> 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] <voidspace> right
[16:50] <voidspace> dimitern: it sounds exactly right
[16:50] <voidspace> dimitern:
[16:50] <voidspace> 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] <dimitern> voidspace, ok, then we should not use that index I think
[16:51] <dimitern> voidspace, we can verify while adding that there's no existing space with the given non-empty provider id
[16:51] <voidspace> dimitern: eh, it sounds exactly like what we want
[16:51] <voidspace> hmmm...
[16:52] <voidspace> dimitern: I don't have the failing tests on maas-spaces, so introduced by my changes
[16:52] <dimitern> 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] <voidspace> dimitern: see their example
[16:52] <voidspace> at the bottom of that page
[16:53] <voidspace> you can
[16:53] <dimitern> voidspace, hmm well it sounds reasonable..
[16:53] <dimitern> but I can't seem to make it work for NICs
[16:53] <voidspace> it certainly *seems* like what we want
[16:53] <voidspace> dimitern: are you using omitempty?
[16:54] <dimitern> voidspace, yep
[16:54] <voidspace> ok
[16:54] <dimitern> ah, well.. perhaps it's because I'm over-complicating things as usual
[16:55] <dimitern> 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] <mup> Bug #1517258 changed: juju 1.24.7 precise: container failed to start and was destroyed <oil> <juju-core:Triaged> <https://launchpad.net/bugs/1517258>
[16:57] <dimitern> 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] <voidspace> dimitern: http://stackoverflow.com/questions/28183109/dealing-with-mongodb-unique-sparse-compound-indexes
[16:58] <voidspace> it seems like unique and sparse don't work together well for compound indices
[16:58] <voidspace> so it's probably currently broken for subnetsC
[16:58] <dimitern> voidspace, yeah, that's what I've (re)discovered I guess
[16:59] <dimitern> voidspace, not necessarily, as both spaces and subnets + provider id act similarly; but it's definitely broken for network interfaces docs
[17:00] <dimitern> (I mean there are no compound indices effectively, as env-uuid+field_name is always set)
[17:00] <voidspace> ah, subnetsC isn't compound
[17:01] <voidspace> dimitern: I was trying to make spacesC compound on env-uuid
[17:01] <voidspace> I'll have to leave that as a TODO
[17:01] <dimitern> 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] <voidspace> dimitern: yeah, I tried it too and saw no failure
[17:02] <dimitern> so rebase might wait
[17:02] <voidspace> I think most of my failures were actually caused by the index problem
[17:02] <voidspace> about to find out
[17:02] <dimitern> voidspace, yeah, sorry for steering you down that rat hole :(
[17:03] <voidspace> well, it's what we *should* do
[17:03] <voidspace> not your fault mongodb is broken
[17:03] <dimitern> :) cheers
[17:11] <dimitern> 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] <dimitern> voidspace, when I run go test -check.f in state/
[17:12] <natefinch> 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] <voidspace> that is odd
[17:13] <dimitern> voidspace, however I suspect it's different for go test github.com/juju/juju/state -check.v
[17:13] <natefinch> ericsnow: it also makes the function you have to write for every command completely trivial, which is nice.  Just a little adapter
[17:15] <ericsnow> natefinch: looking
[17:16] <natefinch> ericsnow: I haven't updated tests yet, obviously.
[17:19] <dimitern> voidspace, same result with go test github.com/juju/juju/state -check.v and unpatched package_test
[17:20] <dimitern> (albeit without any output)
[17:20] <voidspace> dimitern: I wonder if we have some black box state tests then
[17:20] <voidspace> and we need both
[17:21] <voidspace> dimitern: e.g. compat_test.go is in the state package
[17:21] <voidspace> dimitern: allwatcher_internal_test is as well
[17:23] <dimitern> voidspace, yeah, same for the upgrades
[17:26] <beisner> hi mgz, cherylj - is 1.25.2 avail in a ppa anywhere atm?
[17:26] <cherylj> beisner: no, not yet
[17:28] <dimitern> heh what do you know.. go test ./... -check.list almost managed to bring the quad core i7 to its knees
[17:28] <voidspace> dimitern: PR updated, all those issues addressed by the way
[17:28] <dimitern> voidspace, awesome! having a look now..
[17:29] <voidspace> dimitern: small change, touches 25 files...
[17:31] <dimitern> 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] <voidspace> dimitern: no
[17:31] <voidspace> dimitern: causes failures
[17:31] <voidspace> dimitern: the sparse is then ignored
[17:32] <dimitern> voidspace, won't we have the issue where you can't have a space with no provider id in 2 different environments?
[17:32] <dimitern> voidspace, or with the same provider id for that matter
[17:32] <voidspace> dimitern: yes
[17:32] <voidspace> dimitern: but we already have that with subnets and a TODO to fix it...
[17:32] <voidspace> not good enough?
[17:33] <dimitern> voidspace, ok, fair enough
[17:33] <voidspace> how about we add a card for fixing both to the iteration backlog
[17:33] <dimitern> voidspace, just checking the options ;)
[17:33] <voidspace> cool
[17:33] <dimitern> voidspace, +1
[17:34] <dimitern> voidspace, lgtm
[17:35] <voidspace> thanks
[17:35] <voidspace> I thought that would take an hour at the start of the day
[17:35] <voidspace> took a bit longer...
[17:36] <dimitern> voidspace, gotta love mongo, right? :D
[17:36] <voidspace> right, back to the api
[17:36] <voidspace> dimitern: yeah... and our testing infrastructure
[17:36] <dimitern> ok time to call it a day
[17:37] <voidspace> dimitern: o/
[17:38] <dimitern> voidspace, :)
[17:41] <frobware> voidspace, dooferlad, dimitern: Strike 2 - http://reviews.vapour.ws/r/3311/ - this is the correct branch for the change I reverted earlier.
[17:43] <voidspace> frobware: as it's just a forward port, ShipIt!
[17:43] <frobware> voidspace, ty
[17:58] <frobware> rick_h_, hadn't forgotten your HA question - just got a little sidetracked with a broken desktop...
[17:58] <rick_h_> frobware: I forgot the question now heh
[17:59] <frobware> 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] <frobware> rick_h_, if so think I'll enter the h/w business. :)
[17:59] <rick_h_> frobware: :/ ok I think this was more can we do HA on Juju vs openstack on guimaas
[18:02] <frobware> rick_h_, my 28 came from: https://wiki.ubuntu.com/ServerTeam/OpenStackHA
[18:02] <rick_h_> frobware: right, I don't think I was asking about openstack HA
[18:02] <rick_h_> frobware: but "can I deploy openstack (6? 8?) nodes and have Juju be HA there
[18:02] <frobware> rick_h_, so not being at the beginning of the call I think I've missed the context.
[18:02] <rick_h_> frobware: to test upgrades of that deployment
[18:03] <frobware> rick_h_, ok gotcha
[18:03] <rick_h_> frobware: how small can I get a functioning OS and have Juju HA state servers is what I'd like to see
[18:03] <rick_h_> frobware: and then investigate growth of the test case from there
[19:12] <mup> Bug #1522544 opened: workers restart endlessly <juju-core:New> <https://launchpad.net/bugs/1522544>
[20:00] <thumper> morning folks
[20:04] <natefinch> morning thumper.  Happy friday
[20:09] <lazypower> o/ thumper
[20:24] <natefinch> 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] <alexisb> thumper, when do you head to the airport?
[20:29] <thumper> alexisb: tomorrow lunch time
[20:30] <alexisb> thumper, aw ok
[20:35] <natefinch> back later
[20:47] <thumper> ok, I have a fix for this 1.21 upgrade step
[20:52] <thumper> why do we have no reviewers today?
[20:52] <thumper> http://reviews.vapour.ws/r/3313/diff/#
[20:52] <thumper> someone plz
[20:53] <thumper> cherylj, waigani, or davecheney? ^^^
[20:57] <cherylj> thumper: tal now
[20:57] <thumper> ta
[22:05] <thumper> ok, time for coffee... again
[23:15] <wallyworld> axw: perrito666: a minute late
[23:15] <perrito666> k