perrito666anyone in this shift has a decent idea of ha and peergrouper?00:31
thumperdavecheney: \o/00:37
thumperperrito666: only that the peergrouper is doing it wrong00:37
perrito666thumper: yeah, I meant other than the obvious part :p00:37
perrito666ok brain out of service, EOD01:05
axwwallyworld: be there in a minute02:00
davecheneyThe next person that creates a file called state.go, that is not a. in the state package, and b. related to the act of getting stuff in and out of mongodb will have 500 points subtracted from Griffendor02:09
davecheneythumper: yaml.v2 returns errors who's .Error() string representation contains newlines02:12
davecheneyso, fu if you were expecting to use regex to match on those02:12
davecheneythumper: and the error text contains backticks02:15
blahdeblahOK - trying here since Canonical is quiet: Anyone able to point me to a source for juju 1.24.7 for trusty? It's gone from the stable PPA already, and we need to backrev to test something that might be a regression.02:17
anastasiamacdavecheney: since my affiliation with slytherin is stronger, it's perfectly fine for u to substract points from Gryffindor for my doing \o/02:18
blahdeblahAh, found it in http://nova.clouds.archive.ubuntu.com/02:19
blahdeblahSorry for the noise02:19
anastasiamacblahdeblah: glad we helped \o/02:20
blahdeblahanastasiamac: Well, now that you've mentioned it, any ideas about my question re: http://juju-ci.vapour.ws:8080/job/charm-bundle-test-lxc/1392/console in #juju? :-)02:20
anastasiamacblahdeblah: no ideas from me :D02:23
anastasiamacblahdeblah: but it does feel like testing infrastructure... mayb?02:24
blahdeblahWhen the log says "DEBUG:runner:The ntp deploy test completed successfully" and "DEBUG:runner:Exit Code: 0", I'm not even sure what all the rest of it is about...02:25
cheryljHey axw, could you get the 1.25 fix in for bug 1483492 in the next couple days?  We're wanting to do the 1.25.1 release soon02:32
mupBug #1483492: worker/storageprovisioner: machine agents attempting to attach environ-scoped volumes <juju-core:Fix Committed by axwalk> <juju-core 1.25:Triaged by axwalk> <https://launchpad.net/bugs/1483492>02:32
axwcherylj: sorry was on hangout. will do, didn't realise you were waiting on me, sorry02:36
cheryljaxw: no worries.  And you're not blocking things.  I just figured we could include it if it was an easy fix to backport02:37
axwcherylj: I'll take a look now, shouldn't take long02:37
cheryljaxw: cool, thanks much!02:38
bradmwe just had something odd with juju 1.25.0, when doing a destroy environment we see requests to cinder being done over https, when the endpoint is http?03:09
bradmwhen we drop back to 1.24.7, it goes back to being http03:10
blahdeblahLooks like it's https://bugs.launchpad.net/juju-core/+bug/151239903:16
mupBug #1512399: ERROR environment destruction failed: destroying storage: listing volumes: Get https://x.x.x.x:8776/v2/<UUID>/volumes/detail: local error: record overflow <amulet> <bug-squad> <openstack> <sts> <uosci> <Go OpenStack Exchange:In Progress by gz> <juju-core:Triaged> <juju-core03:16
mup1.25:Triaged> <https://launchpad.net/bugs/1512399>03:16
davecheneythumper: sayonara juju/juju/utils, https://github.com/juju/juju/pull/372403:28
natefinchdavecheney: ship it!03:36
natefinchgah, I hate local provider.  I can't ever get trusty containers to start up on my vivid machine04:07
wallyworldaxw: both your PR's should have +1. if you could ptal at the facade one again that would be great04:31
axwwallyworld: sure, thanks04:42
axwbad record mac strikes again04:52
wallyworldaxw: sorry, i missed a commit, i just pushed as you were reviewing04:52
axwwallyworld: ok, looking04:52
wallyworldwas only for rename to scheme04:52
axwoh ok, cool04:53
davecheneyaxw: as your doctor if BAD RECORD MAC is right for you.05:35
natefinchhmm... just had juju's CLI autocomplete print out an error when I tried to autocomplete while not bootstrapped... repro'd it several times05:47
natefinchone time even managed to have it print out a panic, that was fun05:47
axwwtf is up with CI today?06:05
davecheneyaxw: ci has taken 53 minutes to get to godeps -u06:30
axwgood times06:31
* axw does something that doesn't involve merging06:31
wallyworldaxw: a small one http://reviews.vapour.ws/r/3131/07:56
axwwallyworld: looking07:56
wallyworldaxw: next step is to add a collection to record remote add-relation requests. a worker will process those using the stuff in the PR above.07:57
wallyworldie look up offer etc07:57
wallyworldand write out relation if the url can be resolved07:57
axwwallyworld: hrm, I would've thought clients would always go through the API to the local API server, and the API server might proxy requests to a remote environment08:01
wallyworldaxw: they will08:02
wallyworldjuju add-relation will08:02
axwwallyworld: so why is the factory on the client side then?08:02
wallyworldfor the worker08:02
axwwallyworld: by client, I mean any client of the api08:02
wallyworlda worker will listen to remote relation requests08:02
axwwallyworld: workers, CLI, GUI, everything08:02
wallyworldthe api later defines an interface that can be implemennted by a api facade or http facade to a remote controller08:03
axwwallyworld: I can see that, I'm just not seeing why we would do that, instead of making that decision in the API server08:03
wallyworldbecause add-relatio will record the request; the worker only has api layer08:04
=== mup_ is now known as mup
dooferladvoidspace: darn it! Forgot about the feature branch. At least my proposed change seemed exactly the same as what has landed and it it didn't take long to do.09:35
voidspacedooferlad: yep09:36
voidspacedooferlad: although the apiserver calls (called) SupportsSpaces and only checked the error result not the bool!09:36
voidspacedooferlad: something I also fixed09:36
voidspacedooferlad: the new subnets implementation is proving a bit more fiddly than I expected09:37
voidspacedooferlad: the new maas subnets api is easy enough to call - but it doesn't do node filtering nor include the static range information we need (there's a separate api for that)09:38
voidspacedooferlad: so we first call subnets then once per subnet ask for the addresses so we can match the node id09:38
dooferladvoidspace: That's unfortunate. Maybe we should submit a patch against maas.09:38
voidspacedooferlad: then for every subnet that matches we call the reserved_ranges api09:39
voidspacedooferlad: and the maas test server needs extending to support all this09:39
voidspacedooferlad: it wouldn't be hard, not so sure they'd want it though09:39
voidspacedooferlad: might be worth talking to them about it09:39
voidspacedooferlad: they've made a definite decision to make the range information separate09:39
dooferladvoidspace: OK, well, talking won't hurt.09:40
dooferladvoidspace, dimitern, frobware: hangout? https://plus.google.com/hangouts/_/canonical.com/sapphire10:02
frobwaredimitern, dooferlad, voidspace: self-inflicted apt-get upgrade problems here... limited desktop capabilities10:05
frobwaredimitern, dooferlad, voidspace: I also have to run to the dentist in 10 mins.10:06
mgzfrobware: `apt-get purge teeth`?10:07
mgzmight be awkward before reinstalling though10:08
frobwaremgz: I'll just wait for the next version10:08
dimiternfrobware, good luck with both :)10:24
voidspacedooferlad: email sent10:28
dooferladvoidspace: great, thanks!10:28
voidspacedooferlad: let me know when you have gomaasapi - I'm just going to update my version and we can spelunk the test code10:29
voidspacedooferlad: it's pretty straightforward adding and testing new methods, just tedious10:29
voidspacedooferlad: adding the endpoints to the test server is trivial, but you also need to manage state on the test server (so the results are consistent)10:29
voidspacedooferlad: and provide a way of populating some test data10:29
dooferladvoidspace: at this point I am going to refresh my coffee supply, then get onto that. Was just tidying up a script10:30
voidspacedooferlad: cool10:30
voidspacedooferlad: let me know when you want to HO10:30
voidspacedimitern: problem with unreserved ranges :-/10:39
voidspacedimitern: if there are allocated ip addresses then that breaks the allocatable range10:39
voidspacedimitern: so maas reports several smaller ranges10:39
voidspacedimitern: full cidr minus dynamic range might be the way to go :-/10:40
dimiternvoidspace, yeah, it breaks the unused range around the allocated IPs10:41
voidspacedimitern: which isn't good for us10:41
dimiternvoidspace, we can merge them10:41
voidspacedimitern: well10:42
dimiternvoidspace, but since roaksoax confirmed the static range effectively is cidr-dhcp - let's go with that10:42
voidspacedimitern: suppose you have a dynamic range in the middle - and an unused range at the start and at the end10:42
voidspacedimitern: how do we merge that?10:42
voidspacedimitern: what merge algorithm are you suggesting?10:42
voidspacedimitern: we could just take the low bounds of any unused and the high bounds of any unused portion10:43
voidspacedimitern: and if there's an unallocatable portion in the middle - ah well10:43
dimiternvoidspace, right, it might be non-contiguous10:48
voidspacedimitern: but our allocation strategy can handle attempting to pick an address that isn't available10:48
voidspacedimitern: it will just try a new one10:48
voidspacedimitern: and for the common case of a contiguous block it will work fine10:48
dimiternvoidspace, however, since there's no way to configure that via the API or CLI, this must mean "just ignore unused range before or after the dhcp range"10:49
dimiternvoidspace, but for now, let's go with cidr-dhcp range and leave the address picking to handle unavailable addresses10:49
voidspacecidr - dynamic range10:50
dimiternvoidspace, yeah10:50
voidspaceif the dynamic range is in the middle I'll pick the bigger of the two blocks (above dynamic or below dynamic)10:50
dimiternvoidspace, that sounds good10:52
dimiternvoidspace, and matches what maas hearsay claims - use a bigger static than dynamic range :)10:53
dimiternFYI, fwereade texted me he won't be around today (scheduled power outage + working till late yesterday)11:03
mgzdimitern: is there are a config option to say really-don't-use-ipv6?11:17
mgzdns-name: 2001:4800:7818:104:be76:4eff:fe05:c186 <- not useful address for state server11:17
mgz(this is on nearly-master)11:17
dimiternmgz, is this from a unit test or when prefer-ipv6 is enabled in envs.yaml?11:19
mgzit's a CI test, I do not have prefer-ipv6 set for the environment in the yaml11:19
mgzbut I don't see why that address would ever make sense to select as dns-name11:20
voidspacedns-name really just means "address" to juju11:20
voidspaceit doesn't distinguish11:20
dimiternmgz, yeah, dns-name is a damn lie in status11:21
dimiternmgz, I'd like to look at some logs to figure out why11:21
mgzdimitern: bootstrapping again, I can give you whatever11:24
mgzopenstack says it has a 23. a 10. and a 2001: address11:26
dimiternmgz, bootstrap --debug log should be useful, if not that then /v/l/c-i-output.log and /v/l/j/machine-0.log11:26
mgzdimitern: hm, this time it picked the 23. one11:27
dimiternmgz, hmm11:29
dimiternmgz, it might be nova-to-instance addresses in provider/openstack is acting funny11:29
dooferladvoidspace: are you OK to hangout?11:37
voidspacedooferlad: just grabbing coffee11:38
dooferladvoidspace: ack11:38
voidspacedooferlad: right11:50
voidspacedooferlad: team hangout?11:50
dooferladvoidspace: https://plus.google.com/hangouts/_/canonical.com/sapphire11:50
mgzdimitern: here's one where it picked the ipv6 address and got upset https://chinstrap.canonical.com/~gz/bootstrap.log12:53
dimiternmgz, ok, how about machine-0.log?13:16
mgzdimitern: ignore unrelated panic,13:26
mgzhm, this is not from the same bootstrap, but equiv I think13:26
mgzdimitern: https://chinstrap.canonical.com/~gz/rackspace-bad-machine-0.log13:37
mgztried and failed to make chinstrap apache2 sane13:37
dimiternmgz, weird... it seems at the agent side it uses the 10. address13:51
dimiternmgz, but then in status the ipv6 one ends up eventually13:52
mgzdimitern: there's not way I can just force ipv6 not to be selected at all? it used to be the default behaviour14:12
mgzbut now this test is only pot-luck to pass, as everything dies if only an ipv6 address is exposed14:12
abentleysinzui: I've disabled build-revision because I promised wallyworld I'd re-run the series-in-metadata branch.14:16
sinzuiabentley: He merged it (I thought)14:17
abentleysinzui: When?14:17
sinzuiabentley: the branch merged 14 hours ago14:17
abentleysinzui: IOW, he merged it when it was not blessed?  Not cool.14:18
sinzuiabentley: I told him to after retesting his one failed job14:18
abentleysinzui: Oh, okay then.14:19
mupBug #1516023 opened: HAProxie: KeyError: 'services' <blocker> <charm> <ci> <quickstart> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1516023>14:22
frobwarevoidspace, mgz: did we come to any conclusion why this was failing?  http://juju-ci.vapour.ws:8080/job/github-merge-juju/5435/14:25
abentleysinzui: I'd like to chat when you have some time.14:26
dimiternmgz, there's no way to ignore ipv6 addresses14:28
voidspacefrobware: no :-/14:28
mgznah, looks like a real error though14:29
dimiternmgz, you might want to try ignore-machine-addresses, as the ipv6 one seems to be coming from the machine14:29
mgzI can try that.14:29
voidspacemgz: it calls AddMachine which creates a machine document with a principals field, and then immediately checks that field and its not there14:30
voidspacemgz: and it only happens on CI infrastructure...14:30
voidspacemgz: not on anyone else's machine14:31
voidspacemgz: so "genuine" for some value of genuine...14:31
frobwarevoidspace, mgz: for the record, does not happen on my desktop14:31
voidspacevery weird, because all the things I can think of that would make it happen would also cause a load of other stuff to fail14:31
voidspaceand it's at least consistent14:31
voidspacefrobware: same test fails on master as well as 1.25 for CI14:35
voidspacefrobware: I'm going to have to spend some  time looking at it14:36
voidspacethe definition does not have omitempty on it14:39
frobwarevoidspace, but only on CI infra?14:39
voidspacefrobware: yeah, could be different version of go or different version of mongo14:39
voidspacefrobware: although that would still be weird for just that test to fail14:39
frobwaredooferlad, please could we close/move/update bugs & cards related to https://github.com/juju/utils/pull/16414:54
mupBug #1516036 opened: provider/maas: test failure because of test isolation failure <juju-core:New> <https://launchpad.net/bugs/1516036>14:58
frobwarerogpeppe, what's interesting (for me at least) is that "testing.invalid" is quite pervasive through juju's code base.15:06
rogpeppefrobware: yeah15:12
frobwaredoes 'a-b-.com' resolve for you?15:12
rogpeppefrobware: yes15:13
frobwarerogpeppe, and @
rogpeppefrobware: this is why we started using as an invalid ip address everywherre15:13
rogpeppefrobware: 'cos it stops immediately in the network stack15:13
mgz.invalid *should* fail to resolve rapidly15:14
mgzbut people do have odd dns settings15:14
frobwarerogpeppe, does 'dig @ testing.invalid' resolve?15:14
rogpeppefrobware: no15:14
frobwareno further questions your honour15:15
rogpeppefrobware: but it doesn't look much like a DNS name either15:15
rogpeppemgz: my IP provider happily resolves anything15:15
frobwarerogpeppe, which bit doesn't look like a DNS name?15:16
rogpeppefrobware: "@" is allowed in DNS names?15:16
frobwarerogpeppe, ah, no. that forces dig to use as its revolver, not whatever your host would normally use15:16
rogpeppefrobware: "nslookup @ testing.invalid" takes 15 seconds to fail, saying ";; connection timed out; no servers could be reached"15:17
rogpeppefrobware: basically, we should not be relying on user's actual network15:17
frobwarerogpeppe, agreed. but that comes back to my original observation that testing.invalid is already used a lot15:18
rogpeppefrobware: interestingly "invalid" (no dots) fails swiftly on my machine15:19
rogpeppefrobware: hopefully most of those places aren't actually hitting the network stack15:19
frobwarerogpeppe, btw, I don't think nslookup is using the @syntax like dig will.15:19
frobwarerogpeppe, as I see the same timeout.15:19
frobwarerogpeppe, whereas dig replies with 'no name'15:20
rogpeppefrobware: i always find dig output too verbose15:20
rogpeppefrobware: i can't see if it has a result or not15:20
frobwarerogpeppe, add +short to the end15:20
rogpeppefrobware: ah, useful15:21
frobware$ dig ubuntu.com +short15:21
rogpeppefrobware: in that case, it returns immediately, printing nothing (with a zero exit code)15:21
frobwarerogpeppe, for testing.invalid (i.e., unresolvable)15:22
rogpeppefrobware: yeah15:22
frobwareho hum15:22
frobwareblessed be the ISPs15:22
mgzanyway, our tests really shouldn't exercise the machine's DNS15:22
mgzthe point of those bogus-looking addresses was to make the test15:23
mgzactually fail if it reached the resolver15:23
rogpeppemgz: indeed15:23
rogpeppemgz: so it would be better to use
mgzif the test actually tries to get it to resolve then expects or chucks an error to that effect, the test needs changing15:23
lazypowergsamfira_ o/15:23
voidspacemgz: do you know who did the principals stuff? I think it was fwereade15:39
voidspacefwereade: ping if you're around...15:39
fwereadevoidspace, heyhey15:39
voidspacefwereade: hey, hi15:40
voidspacefwereade: I have a very mysterious failing test15:40
voidspacefwereade: only fails on CI machines and I'm struggling to see how it's possible for it to fail at all15:40
voidspacefwereade: and I wondered if you had any insight15:40
fwereadevoidspace, interesting, I will try to sound wise -- pastebin?15:41
voidspacefwereade: failure here15:41
voidspacefwereade: http://pastebin.ubuntu.com/13248028/15:41
voidspacethat's the relevant bit15:41
fwereadevoidspace, yeah, just got there, that's a tad baffling15:42
voidspacefwereade: the test starts with AddMachine which definitely creates a machine with a principals field15:42
voidspacefwereade: and it doesn't fail on my machine or frobware's15:42
voidspaceonly on CI...15:42
voidspaceif we had a timing/session issue with mongo I could understand maybe it being empty (unless the whole doc is empty - maybe I should just log what we do get back)15:43
voidspacebut being *missing* is weird15:43
voidspacefwereade: that test is ignoring the error from FindId().One()15:44
voidspacemaybe there's an error there15:45
fwereadevoidspace, so it is, and, yes, most likely15:45
voidspacefwereade: I'll check the error and log what we do get (likely nothing if there's an error)15:45
voidspace(unless you can think of anything else)15:46
fwereadevoidspace, when the machine gets created does it definitely have a princpals field? I suspect it starts as nil so it might not15:46
voidspacefwereade: hmmm... template.principals is copied in15:47
voidspacefwereade: if that's nil will mongo ignore the field?15:47
voidspacefwereade: it's *not* omitempty15:47
voidspaceso I assumed it would always be there15:47
fwereadevoidspace, in which case is it possible that the s.machines session is out of date? handwave handwave -- if it's never been written to it might be returning old data?15:48
frobwarerogpeppe, do you time/bandwidth to verify my change/patch?15:48
voidspacefwereade: in which case finding the machine should fail - I'll add the checking for the error and we'll see15:48
fwereadevoidspace, omitempty on []string{} preserves it -- not sure how it plays with nil15:48
fwereadevoidspace, yeah15:48
voidspaceit fails consistently and only on CI, so not timing related I don't think15:48
voidspacecould be a mongo version / go version issue15:49
fwereadevoidspace, I *would* say that it's kinda evil anyway15:49
fwereadevoidspace, do we know why we don't just Refresh() or state.Machine(id) it?15:49
voidspaceheh, no15:49
voidspaceI thought you wrote the test ;-) obviously not15:50
fwereadevoidspace, I might have done?15:50
rogpeppefrobware: sorry, i'm just off for the weekend15:50
fwereadevoidspace, I usually try to avoid that sort of thing, but who knows :)15:51
frobwarerogpeppe, ack; I'll add it to the bug anyway15:51
voidspacefwereade: the function definition was touched by rogpeppe in August15:51
voidspaceAugust 2013!15:51
fwereadevoidspace, ahh, rogpeppe broke it then ;p15:51
fwereadevoidspace, crikey15:52
fwereadevoidspace, yeah, that was early days for mongo, our best practices were... evolving15:52
voidspacefwereade: that code specifically (checking the principals field like that) was menno15:52
voidspaceI can ask him15:52
voidspacea year ago, and that was early days for menno15:53
fwereadevoidspace, hmm, worth dropping him a note but I think he's off for a day or two?15:53
voidspacefwereade: if he can't think of a reason not to do it by refreshing the machine I'll switch the test to doing that15:53
voidspacefwereade: ok, I'll email him and ask15:53
voidspacea couple of days won't hurt desperately so long as we don't miss a release cut fof15:53
fwereadevoidspace, ok, cool15:53
fwereadevoidspace, (if that makes that collection unused by the tests, would be nice to drop it)15:54
voidspaceaccording to the calendar he's back in on Monday15:54
fwereadevoidspace, excellent15:54
voidspaceooh, the collection is defined by ConnSuite - I wonder if it is a stale session15:55
voidspaces/defined/lives on/15:55
voidspacefwereade: great, a few avenues of attack anyway15:56
frobwaredimitern, voidspace, dooferlad, mgz: http://reviews.vapour.ws/r/3137/16:23
dimiternvoidspace, dooferlad, frobware, please have a look at http://reviews.vapour.ws/r/3136/ (fixes bug 1483879)16:23
mupBug #1483879: MAAS provider: terminate-machine --force or destroy-environment don't DHCP release container IPs <bug-squad> <destroy-machine> <landscape> <maas-provider> <sts> <juju-core:Triaged> <juju-core 1.24:Won't Fix> <juju-core 1.25:In Progress by dimitern> <https://launchpad.net/bugs/1483879>16:23
dimiternfrobware, ha! :) you were faster16:23
dimiternfrobware, looking16:23
dimiternfrobware, LGTM16:25
mupBug #1516077 opened: CLI autocomplete prints errors/panics when not bootstrapped <juju-core:New> <https://launchpad.net/bugs/1516077>16:31
mupBug #1516077 changed: CLI autocomplete prints errors/panics when not bootstrapped <juju-core:New> <https://launchpad.net/bugs/1516077>16:37
mupBug #1516077 opened: CLI autocomplete prints errors/panics when not bootstrapped <juju-core:New> <https://launchpad.net/bugs/1516077>16:43
natefinchsinzui: where does the landscape_scalable.yaml bundle come from that CI deploys?16:54
dpb1ya, natefinch, you need to use an updated bundle.  the latest charm can't deploy with that old bundle16:59
natefinchyay, not my fault! :)17:00
natefinchactually, the bug says that the bundle deploys ok in 1.25, but not using master: https://bugs.launchpad.net/juju-core/+bug/151602317:01
mupBug #1516023: HAProxie: KeyError: 'services' <blocker> <charm> <ci> <quickstart> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1516023>17:01
sinzuinatefinch: it is in lp:juju-ci-tools/repository. Re froze the landscape-scalable.yaml bundle to prevent it from changing behind our backs17:02
natefinchsinzui: dpb1 says the old bundle doesn't work with the new charm... though that doesn't seem to mesh with what the CI tests are seeing17:03
sinzuinatefinch: I don't think the charm and the bundle have changed.17:04
natefinchsinzui: honestly, my initial assessment was that the haproxy charm just wasn't written carefully enough to account for config-changed getting fired before some of the config data exists.17:05
sinzuinatefinch: http://bazaar.launchpad.net/~juju-qa/juju-ci-tools/repository/view/head:/landscape-scalable.yaml does not let any charm run and if 1.25 liks he bundle and maser doesn't I am not sure the bundle can be blamed17:07
sinzuinatefinch: sorry that isn't english.17:07
natefinchsinzui: lol, I can decipher :)17:07
sinzuinatefinch: the bundle controls the version of the charms.17:08
natefinchhmm... services is getting passed as an empty string...  this all seems familiar17:08
dpb1that bundle is out of date17:08
sinzuinatefinch: I really want to bame the charm for not handling all conditions17:09
dpb1can you not store it locally?17:09
dpb1just grab from the store?17:09
sinzuidpb1: we use this old version to guarantee consistency in the versions of juju we test17:09
natefinchsinzui: I want to blame the charm, too... but it almost seems like we're deserializing the data in a different way than we were before17:09
natefinchdpb1: as long as both the bundle and the charm are version-locked, it should be ok, right?17:10
dpb1guys, you need to update the bundle17:10
dpb1we don't support 'services' key anymore.17:10
natefinchis this a change in quickstart, then?17:10
sinzuinatefinch: let me check. there are 4 machines involved17:11
dpb1Here is the bundle we now upload to the store: https://api.jujucharms.com/charmstore/v4/~landscape/bundle/landscape-scalable-10/archive/bundles.yaml.orig17:11
dpb1You'll notice that apache2 isn't a part of it anymore, landscape-msg is gone, landscape has changed to landscape-server, etc.17:12
sinzuidpb1: I think had to make a local copy of the bundle that worked with older quickstart17:12
dpb1this should work with latest stuff in the stable ppa: juju quickstart u/landscape/landscape-scalable17:13
dpb1which will pull bundle version 10, and coicedently, charm version 1017:14
sinzuinatefinch: dpb1 CI is using 2.2.2+bzr142+ppa39~ubuntu14.04.1 on all machines, that version was released last week. CI tested the bundle and the quickstart many times with many jujus and passed.17:30
dpb1your bundle is out of date.  Look at the charm store.  I don't know what this stored copy gains you, but I would recommend not storing it.17:33
dpb1If you need to store it, you'll need to look at the history to see when you started using charm version 1017:33
sinzuidpb1: it is intentionally out of date to allow continuity in testing17:33
dpb1charm version 10 is not compatable with that bundle.17:33
sinzuidpb1: I am in meeting. I will replay the test with the current bundle when soon.17:35
sinzuioh I see the services: ""17:37
sinzuithere is a bug in juju from time to time where empty strings are dropped17:37
natefinchsinzui: I thought I'd seen that before17:38
sinzuinatefinch: I am retesting several combinations. I suspect someone fixed the bug where config keys are dropped/ignored with they are set to an empty string. I believe thei bug is fixed...and master is doing exactly what it was told to do and the charm errors. 1.25 is dropping data (for wrong reasons) and the test passes.17:42
cheryljfrobware: are you still around?17:43
natefinchsinzui: cool. I was pretty sure there was no way my code could cause data to be missing in the charm's config.17:44
natefinchthanks for changing tabs into spaces in a tsv, vim18:08
natefinchsinzui: do we use godeps for charmrepo in master?18:10
natefinchsinzui: I'm getting weird compile issues after a rebase on master  that look like they're using the wrong version of the code.  either wrong version of charmrepo, or juju/juju and charmrepo disagree on the version of juju/charm to use18:11
sinzuinatefinch: We appear to be.18:12
natefinchI remember roger talking about using godeps for some charm stuff, and I said at the time it was going to be a disaster to have more than one source of truth for what the right version of the code is.18:13
sinzuinatefinch: yes, godeps was called18:13
natefinchwow that is going to be a huge pain in the ass.  1.) update juju/charm, 2.) update charmrepo deps to point to new charm, 3.) update juju/juju deps to point to new charmrepo AND new juju/charm18:14
sinzuinatefinch: yeah. omnibus is is a similar situation, when we test it against the current juju, there is a rule to emit the conflicting deps to help reconcile them, but it is still many steps18:16
natefinchactually, both charmrepo and charmstore have a dependencies.tsv now, and bothe reference charm18:16
natefinchhmm... this may be my fault.  I rebased against "master" on a gopkg.in branch....18:37
natefincheyah, I think that18:38
natefinchthat's the problem18:38
cmarsnatefinch, ouch, been there. gopkg + godeps = :S18:39
natefinchcmars: yeah, it's really just gopkg.in's fault that "master" of charm.v6-unstable is actually "v6-unstable", not "master".  Just a mental mapping problem on my part.18:41
cmarsnatefinch, it's kind of weird that you can say "use this branch" with the gopkg path, but then "nah not really, use this commit hash from another branch" with godeps18:42
natefinchcmars: yeah, really, godeps overrides gopkg.in18:42
cmarsthat's what's tripped me up before18:42
cmarsi bet godeps could be made to be gopkg-aware... check if the commit hash is a parent of the named branch? hmm18:43
mupBug #1516023 changed: HAProxie: KeyError: 'services' <blocker> <charm> <ci> <quickstart> <regression> <juju-ci-tools:In Progress by sinzui> <juju-core:Invalid> <https://launchpad.net/bugs/1516023>18:49
=== BradCrittenden is now known as Guest54329
natefinchrogpeppe: are you here?19:49
rogpeppenatefinch: kinda19:50
rogpeppenatefinch: i'm in a car travelling up to scotland19:50
rogpeppenatefinch: connectivity may be patchy :)19:50
natefinchrogpeppe: I rebased changes onto head of charm.v6-unstable and I'm getting  undefined: charm.Reference19:50
perrito666where will you be when omnipresence attacks19:50
rogpeppenatefinch: yeah19:51
rogpeppenatefinch: i wanted to get the latest changes into juju core today but failed19:51
rogpeppenatefinch: i've removed the Reference type19:51
rogpeppenatefinch: i've made the changes in core but haven't got rid of the test failures yet19:52
rogpeppenatefinch: what are you trying to land in charm ?19:52
* perrito666 suddenly wonders if rogpeppe is driving19:52
natefinchrogpeppe: min juju version19:52
rogpeppeperrito666: no, self-driving car19:52
rogpeppenatefinch: can it wait for a day or two?19:53
natefinchrogpeppe: yeah19:53
natefinchrogpeppe: just making sure things weren't fundamentally broken19:53
rogpeppenatefinch: no, it's all broken by design :)19:53
rogpeppenatefinch: the reason for charm.Reference going is that we're going to have multi-series charms19:54
rogpeppenatefinch: so a fully resolved URL no longer requires a series19:54
natefinchrogpeppe: yeah, that's awesome19:54
rogpeppenatefinch: and that was the sole reason for the existence of the Reference type19:54
rogpeppenatefinch: so most of the failures i'm seeing are from juju-core tests that are expecting an error when creating a URL without a series19:55
natefinchrogpeppe: ok, yeah, I think I just hit a problem because the head of charm.v6 doesn't compile with the head of juju master currently19:56
rogpeppenatefinch: yeah, that's right19:56
natefinchrogpeppe: so when I rebased my code on top of head of both, everything broke19:56
rogpeppenatefinch: yup19:57
rogpeppenatefinch: sorry 'bout that19:57
natefinchrogpeppe: no problem, I can re-rebase onto the old known good version of charm.v6 for now19:57
rogpeppenatefinch: thanks19:57
rogpeppenatefinch: do you know, by any chance, if the transaction log increases in size forever still?19:57
natefinchrogpeppe: I forget if we fixed that or not.19:58
perrito666does any of you know where can I get one of those? https://pbs.twimg.com/media/CTsqRyPWIAEVKRj.jpg19:59
natefinchperrito666: can't19:59
perrito666natefinch: you are no fun20:00
natefinchperrito666: they were sold from the google store way back in the day, IIRC, but they're not being made anymore20:00
perrito666well, it seems that ill just need a very detailed set of pictures and convince a plastic artist20:00
natefinchor a 3D printer20:01
natefinchif you can reproduce them, I'm sure there's a market for them20:01
rogpeppeperrito666: i've got one20:01
natefinchI'd buy one20:01
perrito666natefinch: I am pretty sure a 3d printer will get me very far from that20:01
rogpeppeperrito666: for a suitable price i could probably be persuaded to part with it :)20:01
perrito666rogpeppe: :p can your price be expressed within the realm of real numers? :p20:02
rogpeppeperrito666: sure :)20:02
perrito666if so, does it at least fit an int64? :p20:02
rogpeppeperrito666: that's a substantial realm20:02
perrito666rogpeppe: people have asked things like unicorns20:03
rogpeppeperrito666: i should think so20:03
rogpeppeperrito666: probably even within an int1620:03
rogpeppeperrito666: yes20:04
rogpeppeperrito666: (by me :-])20:04
perrito666I meant the int20:04
rogpeppeperrito666: did i say uint16 ?20:08
natefinchgah... I can't remember how to push up a new charm to launchpad20:31
natefinch$ bzr push lp:~natefinch/charms/vivid/ducksay20:33
natefinchbzr: ERROR: Permission denied: "~natefinch/charms/vivid/ducksay/": : Cannot create branch at '/~natefinch/charms/vivid/ducksay'20:34
natefinch$ bzr push lp:~natefinch/charms/vivid/ducksay/trunk20:34
natefinchCreated new branch.20:34
mupBug #1516144 opened: Cannot deploy charms in jes envs <blocker> <charms> <ci> <regression> <juju-core:Triaged by natefinch> <https://launchpad.net/bugs/1516144>20:41
mupBug #1516144 changed: Cannot deploy charms in jes envs <blocker> <charms> <ci> <regression> <juju-core:Triaged by natefinch> <https://launchpad.net/bugs/1516144>20:44
mupBug #1516144 opened: Cannot deploy charms in jes envs <blocker> <charms> <ci> <regression> <juju-core:Triaged by natefinch> <https://launchpad.net/bugs/1516144>20:47
mupBug #1516144 changed: Cannot deploy charms in jes envs <blocker> <charms> <ci> <regression> <juju-core:Triaged by natefinch> <https://launchpad.net/bugs/1516144>20:53
mupBug #1516144 opened: Cannot deploy charms in jes envs <blocker> <charms> <ci> <regression> <juju-core:Triaged by natefinch> <https://launchpad.net/bugs/1516144>20:56
fwereadeif anyone's around, reviews.vapour.ws/r/3138/diff/ is pretty small20:59
perrito666if no one is around the review grows?21:00
* cherylj sighs....21:01
cheryljwhy must maas be so difficult?21:01
cheryljI just want to work on my feature, but NO, I can't bootstrap my virtual maas.  At all.21:01
cheryljon 1.25 or 1.2621:01
perrito666cherylj: ah that used to happen to me too21:02
perrito666I end up throwing my vmaas21:02
perrito666and sold the computer running it21:02
perrito666I am an extremist21:02
cheryljI'm getting the same "cannot get replica set status: can't get local.system.replset config from self or any seed (EMPTYCONFIG)" errors21:02
cheryljeven with frobware's fix.21:02
cheryljbut now I'm also getting these: DEBUG juju.mongo open.go:122 TLS handshake failed: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "juju-generated CA for environment \"maas\"")21:02
mupBug #1516144 changed: Cannot deploy charms in jes envs <blocker> <charms> <ci> <regression> <juju-core:Triaged by natefinch> <https://launchpad.net/bugs/1516144>21:05
perrito666you made me google what is a manifold21:06
mgz_when I'm merging a turnk-merge to a feature branch21:07
mgz_should I just do that, rather than put up a pr? or should I pr and self approve?21:07
mupBug #1516144 opened: Cannot deploy charms in jes envs <blocker> <charms> <ci> <regression> <juju-core:Triaged by natefinch> <https://launchpad.net/bugs/1516144>21:08
perrito666deppends on the desired result21:08
perrito666I prefer just do the merge21:08
cheryljfwereade: since you're still around, did you get my email about SetInstanceStatus for containers?21:09
fwereadecherylj, just read it21:11
fwereadecherylj, not completely sure I follow: attempted restate:21:11
fwereadecherylj, "the problem with setting instance status is that it's stored in the instanceData doc for the machine, let's change instanceData"?21:12
natefinchmgz_: the nice thing about a PR and approve is that the bot runs, so you ensure it passes tests etc21:12
mgz_that is a reasonable point.21:13
cheryljfwereade: not quite.  more like, we can't set the instance status until we've associated an instance with a machine, which happens after a complete call to StartInstance21:14
cheryljfwereade: and then, "how about for containers, we associate an instance with a machine before StartInstance"21:14
fwereadecherylj, ok, but the reason we can't set it is only because, AFAIAA, there's currently no place to store it that isn't the instance data21:15
fwereadecherylj, and I contend that it shouldn't be in instancedata in the first place21:15
cheryljfwereade: wait, I thought that was where you wanted it.  That's where instancepoller puts it21:16
fwereadecherylj, it should be a proper status like all the others, and that dooc can be keyed on `m#<id>#instance` or something21:16
fwereadecherylj, I have evidently been failing to communicate that I think we have lots of awesome infrastructure for statuses that instance statuses should also use21:16
fwereadecherylj, and that it would be super-nice to get the status out of the instanceData which is otherwise immutable hardware stuff21:17
cheryljso, don't use SetInstanceStatus21:17
fwereadecherylj, state/status.go has getStatus and setStatus helpers21:18
mgz_simple-ish review please: http://reviews.vapour.ws/r/313921:18
fwereadecherylj, you'll want to make sure you create/destroy the instance status docs alongside the machine status ones21:19
cheryljok, I see now21:20
fwereadecherylj, and either put the instance-status validation near all the other status validation in state -- or, if you have time/inclination, extract all the status validation stuff to its own package that doesn't know about mongo and call it from there21:20
fwereadecherylj, cool21:20
fwereadecherylj, that should get you some stuff like free status-history tracking which it might be nice to work out how to expose cleanly21:21
fwereademgz_, LGTM21:23
mgz_fwereade: thanks!21:24
mupBug #1516150 opened: LXC containers getting HA VIP addresses after reboot <canonical-bootstack> <juju-core:New> <https://launchpad.net/bugs/1516150>21:26
cheryljhey, that sounds familiar!  ^^21:26
mupBug #1516150 changed: LXC containers getting HA VIP addresses after reboot <canonical-bootstack> <juju-core:New> <https://launchpad.net/bugs/1516150>21:35
mupBug #1516150 opened: LXC containers getting HA VIP addresses after reboot <canonical-bootstack> <juju-core:New> <https://launchpad.net/bugs/1516150>21:41
perrito666mmmpf, anyone ever found state servers permannently on adding vote?22:39

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!