thumper | davecheney: shipit | 00:09 |
---|---|---|
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:24 |
waigani | sinzui: okay, looking ... | 00:25 |
waigani | sinzui: fixed, repushing | 00:34 |
sinzui | waigani: great I will watch to be sure your branch gets a fair test | 00:35 |
waigani | sinzui: thanks :) | 00:35 |
davecheney | thumper: danka | 00:46 |
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:51 |
mwhudson | cool | 00:52 |
* mwhudson runs away, will look later on | 00:52 | |
=== ses is now known as Guest54267 | ||
thumper | poo | 02:07 |
davecheney | thumper: ? | 02:08 |
thumper | found a bug in the migration steps for 1.21 | 02:08 |
perrito666 | another one? | 02:18 |
thumper | perrito666: yeah | 02:41 |
* thumper goes to make coffee before he tears this apart | 02:42 | |
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:07 |
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:16 |
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:28 |
* thumper is not enjoying reading this code | 03:42 | |
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 | 03:45 |
wallyworld | thumper: can i pull master and run up a multi-env controller without a feature flag yet? | 04:24 |
=== Guest78115 is now known as jose | ||
thumper | wallyworld: no | 04:25 |
wallyworld | damn | 04:25 |
=== jose is now known as Guest38423 | ||
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:25 |
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:26 |
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:27 |
thumper | fuck fuck fuckity fuck | 04:28 |
* thumper digs deeper | 04:28 | |
=== Guest38423 is now known as jose | ||
wallyworld | davecheney: so about any reviews? | 04:31 |
thumper | well, I added a line to make the test fail | 04:32 |
wallyworld | which test? | 04:32 |
thumper | state upgradeSuite.TestMigrateUnitPortsToOpenedPorts | 04:40 |
wallyworld | thanks davecheney :-) | 06:31 |
wallyworld | axw: thanks for review, questions answered plus a couple of changes, ptal when you are free | 07:11 |
axw | wallyworld: thanks, looking | 07:11 |
axw | wallyworld: shipit | 07:18 |
wallyworld | axw: awesome, tyvm | 07:18 |
* frobware wonders why in late 2015 he has a /boot partition which is 100MB in size because that's just too damn small... | 09:52 | |
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:28 |
dimitern | frobware, oh sh*t :/ | 10:29 |
dimitern | frobware, best of luck fixing it then | 10:29 |
dooferlad | frobware: crumbs. Ask for help if you need it. | 10:30 |
frobware | dooferlad, trying to chroot of a usb boot ... | 10:30 |
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:32 |
frobware | dooferlad, my genuine /boot has no working kernel. do you know if a 'boot repair' disk will add one? | 10:36 |
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:38 |
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:39 |
frobware | I have working kernels | 10:41 |
frobware | correction: I have NO working kernels. | 10:41 |
dooferlad | dimitern: can I have another review of http://reviews.vapour.ws/r/3294/ please? | 10:57 |
dimitern | dooferlad, sure - looking | 11:01 |
dimitern | dooferlad, replied | 11:04 |
voidspace | frobware: oh, ouch | 11:11 |
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:16 |
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:18 |
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:25 |
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:30 |
voidspace | dimitern: a subsequent PR of mine will be adding SupportsSpaceDiscovery to NetworkingEnviron | 11:31 |
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:32 |
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:33 |
voidspace | time for a rename then :-) | 11:35 |
dimitern | voidspace, right - agreed about space import | 11:38 |
dimitern | voidspace, +1 for SupportsSpaceManagement instead FWIW | 11:38 |
dimitern | voidspace, reviewed btw | 11:39 |
voidspace | management means nothing | 11:40 |
voidspace | it's a weasel word | 11:40 |
voidspace | dimitern: thanks for the review | 11:41 |
dimitern | voidspace, well, "discovery" is a bit misleading as it implies we can't do discovery in other clouds *ever* | 11:42 |
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:44 |
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:45 |
dimitern | voidspace, well it doesn't but it should (and BackingSubnetInfo represents st.SubnetInfo) | 11:46 |
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:47 |
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:48 |
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:49 |
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:52 |
voidspace | dimitern: so state.SubnetInfo.ProviderId should also be network.Id | 11:57 |
dimitern | voidspace, yes | 11:57 |
voidspace | dimitern: cool | 11:57 |
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:58 |
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 | 11:59 |
voidspace | dimitern: thanks | 12:00 |
perrito666 | morning | 12:46 |
voidspace | perrito666: morning | 12:48 |
* frobware celebrates the restoration of /boot with lunch | 12:59 | |
voidspace | frobware: \o/ | 13:00 |
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:02 |
frobware | and during lunch I think we'll do a complete system backup. :) | 13:03 |
voidspace | cool | 13:04 |
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:13 |
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:14 |
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:15 |
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:16 |
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:17 |
=== Ursinha_ is now known as Ursinha | ||
mup | Bug #1522409 opened: juju machine 0 watcher unable to connect to units <sts> <juju-core:New> <https://launchpad.net/bugs/1522409> | 13:44 |
ericsnow | food for thought: state/State has 195 *exported* methods | 14:36 |
frobware | dimitern, voidspace, dooferlad: PTAL @ http://reviews.vapour.ws/r/3308/ | 14:40 |
dimitern | dooferlad, you've got another review btw | 14:40 |
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:41 |
dimitern | frobware, except - I'll add a comment | 14:42 |
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:43 |
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:45 |
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 :) | 14:48 |
dimitern | voidspace, ping | 15:56 |
voidspace | dimitern: pong | 15:58 |
dimitern | voidspace, in case you're having issues with the ProviderId index (as I'm discovering now) | 15:59 |
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:00 |
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:01 |
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:02 |
voidspace | dimitern: ok | 16:03 |
voidspace | I'm adding it to space - but just following what we did with subnets | 16:03 |
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:04 |
voidspace | dimitern: heh, fun | 16:05 |
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:06 |
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:07 |
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:08 |
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:10 |
voidspace | thanks | 16:11 |
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:13 |
dimitern | voidspace, wow - and here's davecheney who changed that recently :) | 16:15 |
voidspace | dimitern: that change means that most state tests don't run | 16:16 |
dimitern | voidspace, it's gets weirder - grep for MgoTestPackage in state/ | 16:18 |
dimitern | voidspace, uh, no actually no surprises there | 16:19 |
voidspace | heh | 16:19 |
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:20 |
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:21 |
alexisb | happy belated birthday wwitzel3 ! | 16:22 |
dimitern | I'm filing a bug | 16:22 |
voidspace | dimitern: thanks | 16:23 |
wwitzel3 | alexisb: thanks :) | 16:23 |
voidspace | dimitern: frobware: meeting? | 16:32 |
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:33 |
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:45 |
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:46 |
voidspace | we'll see | 16:47 |
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:48 |
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:49 |
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:50 |
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:51 |
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:52 |
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:53 |
dimitern | voidspace, yep | 16:54 |
voidspace | ok | 16:54 |
dimitern | ah, well.. perhaps it's because I'm over-complicating things as usual | 16:54 |
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:55 |
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:57 |
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:58 |
dimitern | voidspace, not necessarily, as both spaces and subnets + provider id act similarly; but it's definitely broken for network interfaces docs | 16:59 |
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:00 |
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:01 |
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:02 |
voidspace | well, it's what we *should* do | 17:03 |
voidspace | not your fault mongodb is broken | 17:03 |
dimitern | :) cheers | 17:03 |
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:11 |
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:12 |
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:13 |
=== ses is now known as Guest17653 | ||
ericsnow | natefinch: looking | 17:15 |
natefinch | ericsnow: I haven't updated tests yet, obviously. | 17:16 |
dimitern | voidspace, same result with go test github.com/juju/juju/state -check.v and unpatched package_test | 17:19 |
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:20 |
voidspace | dimitern: e.g. compat_test.go is in the state package | 17:21 |
voidspace | dimitern: allwatcher_internal_test is as well | 17:21 |
dimitern | voidspace, yeah, same for the upgrades | 17:23 |
beisner | hi mgz, cherylj - is 1.25.2 avail in a ppa anywhere atm? | 17:26 |
cherylj | beisner: no, not yet | 17:26 |
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:28 |
voidspace | dimitern: small change, touches 25 files... | 17:29 |
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:31 |
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:32 |
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:33 |
dimitern | voidspace, lgtm | 17:34 |
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:35 |
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:36 |
voidspace | dimitern: o/ | 17:37 |
dimitern | voidspace, :) | 17:38 |
frobware | voidspace, dooferlad, dimitern: Strike 2 - http://reviews.vapour.ws/r/3311/ - this is the correct branch for the change I reverted earlier. | 17:41 |
voidspace | frobware: as it's just a forward port, ShipIt! | 17:43 |
frobware | voidspace, ty | 17:43 |
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:58 |
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 | 17:59 |
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:02 |
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 | 18:03 |
mup | Bug #1522544 opened: workers restart endlessly <juju-core:New> <https://launchpad.net/bugs/1522544> | 19:12 |
=== ericsnow is now known as ericsnow_afk | ||
thumper | morning folks | 20:00 |
natefinch | morning thumper. Happy friday | 20:04 |
lazypower | o/ thumper | 20:09 |
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:24 |
alexisb | thumper, when do you head to the airport? | 20:28 |
thumper | alexisb: tomorrow lunch time | 20:29 |
alexisb | thumper, aw ok | 20:30 |
natefinch | back later | 20:35 |
=== natefinch is now known as natefinch-afk | ||
thumper | ok, I have a fix for this 1.21 upgrade step | 20:47 |
thumper | why do we have no reviewers today? | 20:52 |
thumper | http://reviews.vapour.ws/r/3313/diff/# | 20:52 |
thumper | someone plz | 20:52 |
thumper | cherylj, waigani, or davecheney? ^^^ | 20:53 |
cherylj | thumper: tal now | 20:57 |
thumper | ta | 20:57 |
thumper | ok, time for coffee... again | 22:05 |
wallyworld | axw: perrito666: a minute late | 23:15 |
perrito666 | k | 23:15 |
=== ericsnow_afk is now known as ericsnow |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!