| === revagomes_ is now known as revagomes | ||
| bodie_ | nice, got my gojsonreference reimplementation built and passing tests | 00:20 |
|---|---|---|
| bodie_ | now need to get tests on gojsonschema passing again | 00:21 |
| jcw4 | bodie_: o/ | 00:24 |
| === thumper-otp is now known as thumper | ||
| * thumper takes a big breath | 00:35 | |
| * thumper exhales | 00:35 | |
| waigani | thumper: davecheney: are we just using the standup channel? | 01:00 |
| thumper | waigani: sure | 01:00 |
| davecheney | yup, see you back in the hangout | 01:01 |
| axw | morning all | 01:04 |
| wallyworld_ | morning | 01:07 |
| perrito666 | man looking at all the discussions that include menn0 and thumper in mailing lists is like reading a webcomic, we need to wait 12 hs between each episode | 01:48 |
| davecheney | perrito666: welcome to canonical | 01:49 |
| waigani | I've added some user docs and apparently I need to let evilnick know about them. What is the best way to do that? | 01:51 |
| waigani | thumper: $ juju user detail foobar; #output: username: foobar | 01:54 |
| waigani | that is one useful cmd! | 01:54 |
| thumper | waigani: exactly, which is why we want display name :) | 01:54 |
| thumper | and later... groups and stuff | 01:55 |
| thumper | waigani: we probably also want 'date created' etc, and other items not yet in the document | 01:55 |
| waigani | thumper: i'll throw in anything i can find and we can then cut back | 01:55 |
| waigani | except maybe password ;) | 01:55 |
| thumper | waigani: add in some TODOs for when we modify the doc | 01:56 |
| sinzui | thumper, I have deployed with the last built juju twice. | 02:03 |
| thumper | and? | 02:03 |
| sinzui | thumper, I don't see the issue universally reported by ci's tests | 02:03 |
| sinzui | I also know that there were no stale jenv files because I reset all the JUJU_HOMEs a hour before | 02:04 |
| thumper | sinzui: using upload tools? | 02:04 |
| sinzui | never for cloud tests. only local host is allowed to use upload tool | 02:05 |
| sinzui | thumper, I am reading all the shell env hoping to find a 1.18 invocation of juju that could cause the problem | 02:06 |
| thumper | sinzui: gee, wouldn't it have been useful to have a stack trace there... | 02:12 |
| sinzui | yes it would. I wish I could trust juju not to reveal keys when in --debug | 02:13 |
| sinzui | thumper, I was trying to get you such a stack trace when the bugger succeeded | 02:13 |
| wallyworld_ | davecheney: this makes me happy. http://juju-ci.vapour.ws:8080/job/walk-unit-tests-ppc64el-trusty-devel/ ppc tests more reliable than amd64 right now | 02:22 |
| davecheney | wallyworld_: it makes me happy as well :) | 02:23 |
| wallyworld_ | amd64 failures are down to random io timeouts etc | 02:24 |
| thumper | \o/ | 02:27 |
| thumper | congrats davecheney and wallyworld_ | 02:27 |
| davecheney | thumper: and axw | 02:28 |
| davecheney | he saved our bacon | 02:28 |
| wallyworld_ | thumper: axw as well | 02:28 |
| thumper | and axw :-) | 02:28 |
| wallyworld_ | he did a lot | 02:28 |
| axw | winning | 02:30 |
| axw | the bot is way happier lately too | 02:30 |
| axw | glad the work has been useful | 02:30 |
| davecheney | i noticed | 02:30 |
| axw | every time I see a merge attempt email I have a heart attack, thinking there's going to be a new intermittent failure | 02:31 |
| davecheney | axw: same | 02:31 |
| davecheney | negative conditioning | 02:31 |
| axw | just need to make sure everyone does this once in a while ;) | 02:31 |
| thumper | axw: it has been incredibly valuable, kudos | 02:33 |
| axw | davecheney wallyworld_: the ppc64 test instance is nailed up right? I wonder if that has anything to do with stability | 02:33 |
| axw | as opposed to amd64 which is spun up/down each time | 02:33 |
| wallyworld_ | axw: yeah | 02:33 |
| davecheney | axw: well, when maas works on ppc then maybe we can introduce that element of randomness | 02:34 |
| davecheney | i can't say it's high on my list | 02:34 |
| axw | heh :) | 02:34 |
| sinzui | thumper, I am convinced there is a bug test code that ensures the right version of juju is bootstrapped. | 02:50 |
| sinzui | thumper, please don't revert | 02:50 |
| thumper | kk | 02:50 |
| sinzui | thumper, I found the problem. I don't know how ti fix it yet, but I was able to feed 1.20-beta1 into the test suite and find the bad method | 02:57 |
| thumper | oh? | 02:58 |
| davecheney | thumper: https://github.com/juju/testing/pull/4 | 03:20 |
| davecheney | *cough* when you have a sec | 03:21 |
| * thumper looks | 03:21 | |
| wallyworld_ | axw: was otp before. if i can get juju tests passing with mongo 2.6, initially that will be on a nailed up ec2 instance but then we could switch to an ephemeral instance and see how well it works | 03:24 |
| axw | wallyworld_: okey dokey, sounds good | 03:25 |
| wallyworld_ | got some fundamental test failures to sort out. once root cause found, should then just work | 03:26 |
| wallyworld_ | i can bootstrap an env with mongo 2.6, just not get passing tests | 03:26 |
| davecheney | wallyworld_: did it build properly with TLS | 03:27 |
| davecheney | ? | 03:27 |
| wallyworld_ | yeah | 03:27 |
| axw | bbs, school run | 03:27 |
| davecheney | i've heard you have to sacrifice a newborn to make that happen | 03:27 |
| wallyworld_ | seemed to work ok | 03:28 |
| davecheney | maybe you need to add more children | 03:28 |
| wallyworld_ | could bootstrap a system | 03:28 |
| wallyworld_ | test failure related to a permission problem with listDatabase() ops and such | 03:28 |
| wallyworld_ | bitch to debug remotely so building locally | 03:29 |
| thumper | davecheney: I'm just about to go and have a coffee... but I'm curious, what was the problem with the code matching yesterday? | 03:30 |
| menn0 | thumper: it's pretty funny, in a not funny kind of way :) | 03:32 |
| sinzui | thumper, I have a success. I will attempt to erase CI's recent memory of this revision to restart all the tests | 03:39 |
| davecheney | thumper: SimpleMessage, the message isn't a string, it's a regex | 04:20 |
| davecheney | because i had included parethesis in the mathcing text | 04:20 |
| davecheney | sadface | 04:20 |
| thumper | davecheney: https://github.com/juju/errors/pull/2 | 04:21 |
| thumper | davecheney: ahh.. | 04:21 |
| thumper | axw: reflect.DeepEqual does work | 04:22 |
| thumper | axw: it really just isn't what I tend to think of when wanting identity | 04:22 |
| davecheney | thumper: if you are happy then I am happy | 04:22 |
| thumper | perhaps I just have to accept it | 04:22 |
| davecheney | i know you've explained to me a bunch of times | 04:22 |
| davecheney | but I still don't understand what you need | 04:22 |
| davecheney | or what it does | 04:22 |
| davecheney | so if you're happy | 04:22 |
| davecheney | then i'm happy | 04:22 |
| thumper | davecheney: the tests pass, so I'm happy | 04:22 |
| davecheney | case closed | 04:23 |
| davecheney | thumper: i'll take quick peek at what reflect.DE does for interface types | 04:23 |
| thumper | davecheney: if there is a short circuit success pass then I'm extra happy | 04:23 |
| thumper | but in reality, this function isn't called all that often | 04:24 |
| thumper | so it will never be any form of bottle-neck | 04:24 |
| sinzui | thumper, deploy is fixed, bug upgrade has a panic https://bugs.launchpad.net/juju-core/+bug/1323937 | 04:24 |
| davecheney | thumper: it's even nicer than that | 04:24 |
| davecheney | teo secs | 04:24 |
| thumper | sinzui: upgrade panics? | 04:24 |
| thumper | sinzui: ah... new version | 04:24 |
| thumper | arse | 04:24 |
| thumper | damn... | 04:25 |
| davecheney | http://golang.org/src/pkg/reflect/deepequal.go?s=3380:3419#L128 | 04:25 |
| thumper | sinzui: ok, I have a plan | 04:25 |
| thumper | sinzui: we keep the code, but revert the version number to 1.19.3 | 04:25 |
| davecheney | reflect.ValueOf returns a reflect.Value that represents the concrete type of the interface value | 04:25 |
| sinzui | thumper, the details imply simple streams...because 1.18.1 canno even bootstrap when it discovers that version exists | 04:25 |
| thumper | sinzui: we keep the behaviour of the numbers until 1.20.0 has been released | 04:25 |
| sinzui | thumper, yeah. I was thinking the same | 04:25 |
| thumper | sinzui: really? hmm... | 04:26 |
| thumper | wallyworld_: thoughts? | 04:26 |
| sinzui | thumper, I can only guess. I am tired | 04:26 |
| thumper | wallyworld_: finding tools versions where versions aren't parsable by old code? | 04:26 |
| wallyworld_ | hmmm | 04:26 |
| thumper | sinzui: I'll submit a patch to make the current version go back | 04:26 |
| thumper | sinzui: because otherwise 1.18 clients will panic when getting a new version number it can't handle | 04:27 |
| davecheney | so reflect.DE gets the underlying values, and comparest their types, | 04:27 |
| wallyworld_ | thumper: i think we need current-1 to be able to find tools fir current to allow upgrades | 04:27 |
| sinzui | thumper, could the - be the issue? could 1.20beta1 be acceptable? | 04:27 |
| davecheney | which is what we were doing by snarfing in the first word of the interface struct | 04:27 |
| thumper | sinzui: this will be the cause of the upgrade failure | 04:28 |
| thumper | sinzui: let me fix it | 04:28 |
| jimmiebtlr | It looks like any writes to command context (Infof, Verbosef) go to stderr, is this expeceted? | 04:30 |
| thumper | jimmiebtlr: yes | 04:32 |
| thumper | jimmiebtlr: some commands have strict format output that goes to stdout | 04:32 |
| thumper | jimmiebtlr: we wanted to make sure that stdout says parsable by tools expecting that strictness | 04:32 |
| thumper | jimmiebtlr: so extra info goes to stderr | 04:32 |
| jimmiebtlr | ok | 04:33 |
| thumper | and to be consistent, we always send to stderr | 04:33 |
| jimmiebtlr | so for instance from the add-machine command would the output "created machine X" be expected to output to stderr or stdout? | 04:34 |
| thumper | jimmiebtlr: I'd expect it to go to stderr for the above reason | 04:35 |
| jimmiebtlr | ok, thanks | 04:35 |
| thumper | Rietveld: https://codereview.appspot.com/93570046 | 04:41 |
| thumper | wallyworld_, axw, sinzui, anyone... ^^^^ | 04:41 |
| thumper | fixes the broken upgrades of trunk | 04:41 |
| wallyworld_ | ok | 04:41 |
| thumper | by reverting version from 1.20-beta1 back to 1.19.3 | 04:41 |
| axw | doh | 04:42 |
| thumper | yeah... | 04:42 |
| thumper | the 1.18 agents need to be able to parse the new version updated in config without dying :-) | 04:43 |
| thumper | my boo-boo | 04:43 |
| sinzui | thumper, when I release 1.20.0 next month. I will then set the version to 1.21-alpha1? | 04:44 |
| thumper | sinzui: yes, or 1.21-dev1 | 04:45 |
| thumper | what ever flicks your switch | 04:45 |
| thumper | alpha, bravo, charlie, delta, echo, ... | 04:45 |
| thumper | finish with a foxtrot | 04:45 |
| sinzui | albatros | 04:46 |
| thumper | sinzui: you could change the naming scheme with every release :-) | 04:46 |
| thumper | 1.21 - birds | 04:46 |
| sinzui | I am off to bed. CI is actually just finished the last revision. the 1.18.x upgrade tests were true failure. canonisatacks failure was swift related | 04:47 |
| thumper | sinzui: thanks | 04:47 |
| sinzui | oh, wallyworld_ I think I need to revert the ppc64el deb -> ppc64 tgz tool. This failure happen after to remove support for the ppc64el tool http://juju-ci.vapour.ws:8080/job/local-deploy-trusty-ppc64/10/console | 04:49 |
| wallyworld_ | looking | 04:50 |
| wallyworld_ | sinzui: what's inside the deb? ++ wget -q http://juju-ci.vapour.ws:8080/job/publish-revision/lastSuccessfulBuild/artifact/juju-core_1.20-beta1-0ubuntu1~14.04.1~juju1_ppc64el.deb | 04:53 |
| wallyworld_ | ppc64el.tar.gz or ppc64.tar.gz | 04:54 |
| wallyworld_ | should be the latter for juju to find it | 04:54 |
| wallyworld_ | if i understand the issue correctly | 04:54 |
| * bigjools wonders what thumper has been doing to get an icky taste in his mouth | 05:02 | |
| thumper | :P | 05:02 |
| davecheney | bigjools: management | 05:17 |
| bigjools | +1 | 05:17 |
| davecheney | bigjools: sorry, you set that one up, I just needed to take a run up | 05:29 |
| bigjools | davecheney: quite all right | 05:29 |
| menn0 | i've been deep diving in to how upgrades work and I've got a handle on most things | 05:45 |
| menn0 | there's just one bit I'm not sure of | 05:46 |
| menn0 | has anyone got 5 mins to help? | 05:46 |
| jam | fwereade: axw: are we meeting to discuss bug #1215579 ? | 06:02 |
| _mup_ | Bug #1215579: Address changes should be propagated to relations <addressability> <reliability> <juju-core:In Progress by axwalk> <https://launchpad.net/bugs/1215579> | 06:02 |
| jam | I don't see dimitern yet | 06:02 |
| axw | jam: I was about to join, but I guess we should wait for dimiter | 06:02 |
| jam | I'm there, but just to be around if someone joins | 06:07 |
| jam | axw: fwereade is here now | 06:09 |
| axw | okey dokey | 06:09 |
| === Ursinha-afk is now known as Ursinha | ||
| === vladk|offline is now known as vladk | ||
| wwitzel3 | fwereade: ping | 08:08 |
| fwereade | wwitzel3, pong | 08:08 |
| wwitzel3 | fwereade: you have some time to discuss presence things? | 08:09 |
| fwereade | wwitzel3, sure :) | 08:09 |
| fwereade | wwitzel3, moonstone? | 08:09 |
| wwitzel3 | fwereade: k, let me grab my coffee and I'll be in moonstone. | 08:09 |
| * fwereade does same | 08:10 | |
| vladk | jam, fwereade: networker API facade: https://codereview.appspot.com/98600047 | 08:16 |
| voidspace | morning all | 08:18 |
| rogpeppe | voidspace: hiya | 08:19 |
| voidspace | rogpeppe: hey roger | 08:22 |
| rogpeppe | voidspace: how's tricks? | 08:22 |
| voidspace | rogpeppe: not bad, although today's task is working out why turning on replica set for tests makes the "no reachable servers" problem about a million times worse | 08:23 |
| voidspace | rogpeppe: so not much fun :-) | 08:23 |
| voidspace | rogpeppe: how's jazz-land? | 08:23 |
| wwitzel3 | voidspace: morning | 08:25 |
| voidspace | wwitzel3: hey, morning | 08:26 |
| voidspace | wwitzel3: sleep any better? | 08:26 |
| wwitzel3 | voidspace: sadly no | 08:26 |
| voidspace | wwitzel3: :-( | 08:27 |
| voidspace | I thought being around this early wasn't a good sign | 08:27 |
| voidspace | grabbing coffee, back in a minute | 08:28 |
| wwitzel3 | voidspace: I was able to get a nap in the afternoon yesterday for about an hour and I tossed and turned for about 5 hours this evening for maybe 2 hours of total sleep. | 08:29 |
| wwitzel3 | voidspace: I'll probably take a sleep aid tonight, so I don't become a zombie. | 08:30 |
| voidspace | wwitzel3: yeah, sounds like a good idea :-/ | 08:35 |
| jam | fwereade: wrt https://code.launchpad.net/~jimmiebtlr/juju-core/add_machines_tag/+merge/221013 are we wanting to expose things as tags to the CLI? | 09:19 |
| fwereade | jam, certainly not | 09:25 |
| fwereade | jam, not sure where that came from | 09:25 |
| jam | yeah, I didn't see an associated bug, and you've mentioned to me that we didn't want it | 09:25 |
| fwereade | jam, we have a bug that debug-log uses tags (grarrrr) | 09:25 |
| fwereade | jam, I assigned it to thumper but forgot to mention it to him, I should do that | 09:25 |
| jam | I'm not personally all that happy with bare numbers for machines, but if we want to not use tags, then we shouldn't | 09:25 |
| jam | vladk: I have some feedback for https://codereview.appspot.com/98600047/ | 09:27 |
| jam | I haven't reviewed everything, but I did give a bit of a "here are some stuff that we need to iterate one" | 09:28 |
| jam | on | 09:28 |
| jam | fwereade: for changing Login so that it goes via "https://host:port/ENVUID/api" sort of URLs. Would you be averse to using a different Mux? One that was path aware? (like github.com/gorilla/pat) ? | 09:31 |
| jam | I'm not sure I like Pat, as it looks to be doing a separate global hash map for extra data | 09:32 |
| jam | (It at least pulls in gorilla/context which does that exact thing) | 09:32 |
| fwereade | jam, I don't have an opinion; am happy to follow your judgment on that | 09:32 |
| jam | but it seems a bit of "we could roll our own" that would be less flexible in the long term | 09:32 |
| jam | though our needs today are very modest | 09:33 |
| === luca__ is now known as luca | ||
| fwereade | jam, I'm all for pulling in well-defined battle-tested solutions from elsewhere | 09:37 |
| fwereade | jam, hand-hacking the perfect tool with zero fat is a beguiling approach but by no means necessarily optimal | 09:37 |
| jam | fwereade: bringing in tons of dependencies and their own cruft isn't always great, either. but Mux seems like something there are a few possible solutions around. | 09:38 |
| fwereade | jam, sure, some degree of taste and sanity needs to inform these decisions | 09:39 |
| jam | fwereade: I found http://www.alexedwards.net/blog/a-mux-showdown though it is interesting that now Pat is gorilla/pat and imports gorilla/mux, so I'm not sure why to use Pat over Mux if we go that route | 09:41 |
| jam | weird, apparently there is also https://github.com/bmizerany/pat | 09:43 |
| jam | which seams a bit lighter | 09:43 |
| jam | fwereade: for URLs, should it be UUID or Tag ? | 09:59 |
| jam | eg: /environ-dead-beef/api/ | 09:59 |
| jam | or | 09:59 |
| jam | eg: /dead-beef/api/ | 09:59 |
| jam | or possibly | 09:59 |
| jam | eg: /environ/dead-beef/api/ | 09:59 |
| jam | it feels a bit like putting the environment- prefix in the URL isn't needed. | 10:00 |
| jam | (I should be clear that the tag has the full environment- prefix, I always want to spell it with the short name) | 10:01 |
| === vladk is now known as vladk|offline | ||
| voidspace | axw: ping | 10:06 |
| voidspace | if you're still around | 10:06 |
| axw | voidspace: heya | 10:06 |
| axw | I may disappear soon, but I am here now | 10:06 |
| voidspace | axw: hey, you wrote the code in this CL | 10:06 |
| voidspace | https://codereview.appspot.com/88350043/patch/40001/50005 | 10:06 |
| * axw hides | 10:06 | |
| voidspace | haha | 10:06 |
| voidspace | no, it's all good | 10:06 |
| voidspace | it includes the code that *doesn't* enable HA for local provider | 10:07 |
| axw | right | 10:07 |
| voidspace | the problem that necessitated that appears to have disappeared | 10:07 |
| voidspace | so I'd like to just enable HA for local provider | 10:07 |
| voidspace | shouldEnableHA includes the following comment | 10:07 |
| voidspace | +// Eventually this should always be true, and ideally | 10:07 |
| voidspace | +// it should be true before 1.20 is released or we'll | 10:07 |
| voidspace | +// have more upgrade scenarios on our hands. | 10:07 |
| voidspace | axw: as I'm going to remove shouldEnableHA *before* 1.20 (i.e. now) | 10:08 |
| voidspace | is it correct that I don't have to consider any *additional* upgrade scenarios - the existing code will handle everything | 10:08 |
| axw | voidspace: correct | 10:08 |
| voidspace | axw: awesome :-) | 10:08 |
| voidspace | thanks | 10:08 |
| axw | voidspace: I assume you were able to reproduce the bug before, but can't now? | 10:08 |
| voidspace | axw: wallyworld was able to reproduce before and can't now | 10:09 |
| axw | ah great | 10:09 |
| axw | sweeeet | 10:09 |
| natefinch | voidspace: nice! | 10:09 |
| voidspace | axw: so we'll enable it - and then I'll email juju list and warn people to try it | 10:09 |
| voidspace | natefinch: yep, morning :-) | 10:09 |
| natefinch | voidspace: morning :) | 10:09 |
| axw | thanks, SGTM | 10:09 |
| axw | very much | 10:09 |
| voidspace | natefinch: enabling replica sets for tests seems to be more problematic, but I'll start digging into that once this mp is ready | 10:10 |
| natefinch | voidspace: we might have to punt on that if it gets too big, but we should at least give it the old college try before giving up. | 10:11 |
| voidspace | natefinch: yep | 10:11 |
| voidspace | natefinch: although it will be annoying to have a production check for replica sets merely to accomodate the test environment | 10:11 |
| natefinch | voidspace: well, I think we can do it a different way. Just mock out a function in test or something. | 10:12 |
| voidspace | natefinch: ah yes | 10:13 |
| fwereade | jam, I think the API can just be uuid | 10:15 |
| fwereade | jam, sorry, the *URL* can just have the UUID | 10:15 |
| jam | right | 10:16 |
| jam | I understood you | 10:16 |
| === vladk|offline is now known as vladk | ||
| jam | dimitern: are you back ? | 10:45 |
| jam | standup ? | 10:45 |
| dimitern | jam, yes, brt | 10:46 |
| === Ursinha is now known as Ursinha-afk | ||
| jam | fwereade: are you coming to our standup today ? | 10:46 |
| fwereade | jam, why not :) | 10:47 |
| wwitzel3 | fwereade: do you know the distinction between agent-state and agent-state-info? in both the cases of ensure-availability and status .. agent-state-info seems to have the correct information, even though agent-state is reporting "down". | 10:48 |
| fwereade | wwitzel3, the SetStatus has a status "enum", and an info string, and we tacked on a map for more info later | 10:49 |
| wwitzel3 | fwereade: I'm wondering if having the AgentPresence check inspect agent-state-info for hints about the status (ie is it really down?) might be ok? | 10:49 |
| fwereade | wwitzel3, the difficulty is that agent-state: down is hacked in in the status api, and we don't send the real value of agent-state-info down in status | 10:50 |
| fwereade | wwitzel3, I don't *think* it would help | 10:50 |
| wwitzel3 | fwereade: ahh ok | 10:50 |
| fwereade | wwitzel3, agent-state might be a better bet, though | 10:50 |
| fwereade | wwitzel3, if it's never yet set a value, it's probably not there yet | 10:51 |
| wwitzel3 | fwereade: right, makes sense | 10:51 |
| fwereade | wwitzel3, although even that is imperfect, because the pinger will start a bit before the machiner gets round to setting started | 10:51 |
| wwitzel3 | fwereade: good news is the rename worked just fine, compiled and tests pass | 10:51 |
| fwereade | wwitzel3, *and* we should expect that the set of statuses, and when they're set, will change as well | 10:51 |
| fwereade | wwitzel3, cool | 10:52 |
| === vladk is now known as vladk|offline | ||
| === vladk|offline is now known as vladk | ||
| axw | fwereade: it's in a bit of a shoddy state, but I've got addresses flowing end to end now | 11:15 |
| axw | fwereade: I modified AliveHookQueue to do something similar to changedPending- does that sound terrible? | 11:16 |
| axw | fwereade: AliveHookQueue selects on another channel, and then sets a flag to say that it wants to send a relation-address-changed hook next | 11:16 |
| voidspace | axw: that was quick! Thanks. | 11:20 |
| axw | no worries | 11:20 |
| voidspace | Nice when a CL is mostly code removal. | 11:21 |
| axw | deleting code is one of my favourite things | 11:21 |
| voidspace | :-) | 11:21 |
| voidspace | "if you think writing code is awesome you should try deleting code!" | 11:22 |
| axw | heh :) | 11:22 |
| bodie_ | :) | 11:23 |
| bodie_ | I deleted a bunch of code yesterday... felt great | 11:23 |
| bodie_ | I kind of get the appeal of dentistry now, too... | 11:23 |
| voidspace | hah | 11:23 |
| voidspace | I kinda like my teeth | 11:24 |
| perrito666 | morning | 11:25 |
| voidspace | perrito666: morning | 11:26 |
| wwitzel3 | perrito666: morning | 11:26 |
| === vladk is now known as vladk|offline | ||
| === Ursinha-afk is now known as Ursinha | ||
| === vladk|offline is now known as vladk | ||
| === vladk is now known as vladk|offline | ||
| voidspace | rebooting to get local provider working again :-/ | 11:48 |
| voidspace | ERROR cannot use 37017 as state port, already in use | 11:48 |
| hazmat | voidspace, ps aux | grep mongo | 11:54 |
| voidspace | hazmat: I had this yesterday, killed mongo - still got the same error | 11:55 |
| hazmat | voidspace, do see port 37017 in output of sudo netstat -tulpn | 11:56 |
| voidspace | hazmat: not after rebooting :-) | 11:57 |
| voidspace | hazmat: I'll try next time, happened yesterday too | 11:57 |
| hazmat | voidspace, i'd try juju destroy-environment --force on it | 11:57 |
| voidspace | thanks | 11:59 |
| natefinch | yeah, there's a few things that aren't always cleaned up perfectly in the local provider.... we should probably do some work to try to make it more reliable, because it does tend to get stuck like that, whether it's mongo or lxc or whatever. You know, when we have spare time ;) | 12:02 |
| voidspace | natefinch: local provider still seems to work with my changes, and I have an LGTM | 12:04 |
| voidspace | natefinch: so merging and switching to looking at tests after lunch | 12:04 |
| natefinch | voidspace: awesome | 12:05 |
| === vladk|offline is now known as vladk | ||
| hazmat | voidspace, if its not working for you yet, i'm up for doing a g+ screenshare to debug | 12:09 |
| * hazmat reads backlog and realizes its already working | 12:09 | |
| hazmat | cool | 12:09 |
| hazmat | rogpeppe, do you still have that api parser code handy? the one that extracted an api listing from the src? | 12:17 |
| rogpeppe | hazmat: yes | 12:17 |
| rogpeppe | hazmat: but recent changes mean that it's not going to work for much longer (assuming it does still) | 12:17 |
| hazmat | rogpeppe, bummer | 12:18 |
| rogpeppe | hazmat: the API is not longer statically determinable | 12:18 |
| rogpeppe | s/not/no/ | 12:18 |
| hazmat | the refactoring that's been going on in api makes it much harder to determine what the full api is and identify the delta for client construction | 12:20 |
| hazmat | i guess i should be using godoc instead of src.. ala http://godoc.org/launchpad.net/juju-core/state/api | 12:22 |
| sinzui | jam, natefinch fwereade Can someone look into this regression, bug 1324110 | 12:49 |
| _mup_ | Bug #1324110: go get cannot find github.com/juju/testing/logging <ci> <packaging> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1324110> | 12:49 |
| jam | sinzui: I see github.com/juju/testing just fine, are you sure you are "go get" ing all the new dependencies? | 12:51 |
| jam | people have been breaking out a lot of the core code into libs | 12:51 |
| jam | ah, hmm... lo testing/logging | 12:52 |
| jam | that I don't see | 12:52 |
| sinzui | jam, CI runs this | 12:52 |
| sinzui | go get -v -d launchpad.net/juju-core/... | 12:52 |
| jam | sinzui: I think the bug is that something was removed and we didn't notice because go build leaves the old artifacts around | 12:52 |
| sinzui | and it say github.com/juju/testing/logging is missing I see testing/ but mote testing/logging | 12:53 |
| frankban | sinzui, jam: this can be related to my current change in https://github.com/juju/testing/pull/5 . I am also waiting on a review for https://codereview.appspot.com/92660046 . After that, I can fix the dependencies on core | 12:53 |
| jam | sinzui: sure, I think it used to exist there, and it got moved, and some imports moved with it, but we missed this one because everyone running the test suite still had it from before it was moved | 12:53 |
| jam | frankban: the issue is that trunk is currently already broken | 12:53 |
| sinzui | jam, understood, | 12:53 |
| jam | because it imports a module | 12:54 |
| jam | and updated godeps | 12:54 |
| jam | to point to one that didn't have it anymore | 12:54 |
| jcw4 | fwereade, mgz, natefinch : on a whim inspired by natefinch I added an FAQ yesterday. Are 3 FAQ's worth including? I expect it to grow: https://codereview.appspot.com/98650043/ | 12:55 |
| bodie_ | morning john | 12:56 |
| jcw4 | bodie_: o/ | 12:56 |
| jcw4 | fwereade: I think this one is ready to go too: https://codereview.appspot.com/92630043/ | 12:57 |
| mgz | jcw4: well, that's useful info at least | 12:59 |
| jam | frankban: can you either fix the import or revert the godeps so that trunk can build again? | 12:59 |
| mgz | I kind of think it's stuff that should just be in HACKING rather than faq form | 12:59 |
| jcw4 | mgz: I'm open to whatever seems best | 13:00 |
| mgz | jcw4: landing as is seems best for now, as I'm also rewriting things | 13:01 |
| jam | 2783 Francesco Banconi2014-05-23 [merge] | 13:01 |
| jam | [r=gz] Update the github.com/juju/testing dependency. | 13:01 |
| jam | is probably the one that broke ups | 13:01 |
| mgz | easy to bring different bits together later | 13:01 |
| jcw4 | mgz: excellent | 13:01 |
| mgz | jam: yeah, I've seen that | 13:01 |
| mgz | I'll fix | 13:01 |
| jam | mgz: should we change the bot to always do a cleanroom build? so stuff like this can't land | 13:02 |
| mgz | maybe... I actually need the go get to work... which requires tip juju/testing to not be borked I think | 13:02 |
| jam | I don't think it would add huge amounts of compile time overhea | 13:02 |
| jam | d | 13:02 |
| mgz | jam, well, my bot-test just broke on it | 13:02 |
| jam | mgz: bzr merge -r 2783..2782 | 13:02 |
| mgz | so... EOW | 13:02 |
| jam | End of Week ? | 13:02 |
| mgz | Hopefully! | 13:02 |
| jam | mgz: its only Wednesday :) | 13:03 |
| jam | mgz: or you mean the github version will do cleanroom builds | 13:03 |
| mgz | jam: right, git on jenkins is from scratch each time at present | 13:03 |
| natefinch | jcw4: LGTM'd | 13:03 |
| jcw4 | natefinch: ta | 13:04 |
| mgz | hm, go get really screws things | 13:13 |
| mgz | if any import in any tip of a dep is changed, it will fail | 13:13 |
| frankban | jam, mgz so I am not sure how to dupe that problem, but there are two places in the code which still try to import testing/logging | 13:17 |
| frankban | one is golxc, and I have a fix here: https://codereview.appspot.com/92660046 | 13:18 |
| jam | frankban: rm -rf $GOPATH/pkg | 13:18 |
| jam | then when you build again, it should fail | 13:18 |
| frankban | the other is juju-core testing/testbase/log.go, which is easy to fix | 13:18 |
| mgz | frankban: I'm looking at the second | 13:18 |
| mgz | I guess we land the golxc one, then I can bump that dep as well | 13:19 |
| mgz | will review | 13:19 |
| mgz | currently I'm missing PatchEnvironment.. | 13:19 |
| frankban | mgz the second is something like http://pastebin.ubuntu.com/7536578/ | 13:20 |
| mgz | frankban: ta | 13:21 |
| frankban | mgz: Once the golxc land, we should update golxc and github/juju/testing dependencies in juju-core, aplly the patch and hopefully we are all using the new testing version | 13:21 |
| mgz | frankban: lgtm | 13:22 |
| frankban | mgz: landing it | 13:22 |
| mgz | yeah, I'm doing that, go ahead and land and give me the sha1 | 13:22 |
| mgz | oh, it's actually a lp branch | 13:24 |
| frankban | mgz: merged revno 9 | 13:25 |
| frankban | mgz: proposing a fix for juju-core | 13:28 |
| mgz | frankban: I've got it | 13:30 |
| mgz | ...when lbox responds, that is | 13:30 |
| frankban | mgz: ok | 13:30 |
| mgz | (I'll also need to fiddle with the landing bot anyway) | 13:30 |
| frankban | mgz: yeah, we need to update both golxc and github/juju/testing, correct? | 13:31 |
| mgz | frankban: yup. cr up... nearly, man I won't miss lbox | 13:36 |
| mgz | downloading all of juju-core each time just to make a diff for cr is insane | 13:37 |
| frankban | mgz: on the other hand, Rietveld is freaking good | 13:38 |
| mgz | frankban: 92600046 | 13:38 |
| frankban | mgz: looking | 13:39 |
| frankban | mgz: LGTM | 13:41 |
| mgz | frankban: bot deps done, marking approved | 13:43 |
| frankban | cool | 13:43 |
| mgz | bot has picked it up | 13:44 |
| natefinch | OMG, why does LibreOffice turn on line numbers by default on documents? | 13:52 |
| jam | natefinch: Tools - Line Numbering set your own options? | 13:55 |
| natefinch | jam: yeah, just seems like an insane default | 13:56 |
| natefinch | jam: at first I assumed the document was corrupt or something... | 13:57 |
| jam | natefinch: I just created a new Writer and it doesn't have line numbers on | 13:57 |
| jam | are you sure you didn't change your setting some time in the past? | 13:58 |
| natefinch | jam: possible I suppose.... though I honestly can't imagine ever turning on line numbers for a document like that. Anything's possible though | 13:58 |
| perrito666 | natefinch: I cant remember opening *office since google docs exist | 13:59 |
| natefinch | yeah, me either. but, the TOSCA stuff is in a docx you need to download :/ | 14:00 |
| natefinch | which.... pretty much tells you all you need to know about TOSCA | 14:00 |
| perrito666 | such as "we still use ms word" | 14:00 |
| natefinch | yep | 14:01 |
| jam | natefinch: its docx, though, isn't that the "open" XML standard, right? ..... right? | 14:03 |
| natefinch | it's a lot better than .doc yeah :) | 14:04 |
| perrito666 | yup, the one that has an open spec filled with references to closed specs :p | 14:04 |
| natefinch | haha | 14:04 |
| perrito666 | it was a fun read | 14:05 |
| mgz | wtf test failures | 14:05 |
| frankban | :-/ | 14:06 |
| mgz | these are new to me | 14:06 |
| mgz | why is it trying apt-get at all... | 14:06 |
| frankban | mgz: I guess there is something wrong with the new LoggingCleanupSuite | 14:08 |
| mgz | jam: any ideas on the failures for merge lp:~gz/juju-core/logging_dep_fixes ? | 14:08 |
| mgz | frankban: I guess, it seems isolationy | 14:08 |
| mgz | frankban: can you try to reproduce locally? | 14:09 |
| frankban | mgz: duped, lots of failures | 14:09 |
| mgz | k, poke me if you need help | 14:09 |
| jam | mgz: apt exit status 100 seems like "something got really screwed up" | 14:09 |
| jam | now I don't know why we are actually running apt-get anything on the bot, but you could just try again | 14:10 |
| jam | http://askubuntu.com/questions/347830/how-can-i-get-a-verbose-apt-get-exit-code | 14:10 |
| jam | mgz: "could not open lock file" | 14:10 |
| jam | we shouldn't be root anyway | 14:10 |
| mgz | jam: something bork-ish with isolation on the suite somehow I think, the log above shows it complaining about not being root | 14:10 |
| === vladk is now known as vladk|offline | ||
| mgz | (rightly, we don't run the tests as root as we're not insane) | 14:11 |
| mgz | how we end up on a "must run apt-get" path is mysterious | 14:11 |
| jam | mgz: are you reverting the version of juju/testing ? | 14:11 |
| * jam wonders if we were getting "correct" isolation with the right version of juju/testing | 14:11 | |
| mgz | jam: probably should now, I tried going forward (as otherwise go get is broken) | 14:11 |
| mgz | going backwards will at least unblock landings | 14:12 |
| === vladk|offline is now known as vladk | ||
| frankban | mgz: maybe I've found something | 14:21 |
| mattyw | natefinch, if you have more HA work I'm available | 14:24 |
| frankban | mgz: could you please try it again after applying this patch? http://pastebin.ubuntu.com/7536884/ | 14:24 |
| natefinch | mattyw: cool, in a meeting, talk to you in a bit | 14:25 |
| === alexisb_bbl is now known as alexisb | ||
| frankban | mgz: all this Logging* stuff can be confusing | 14:25 |
| === vladk is now known as vladk|offline | ||
| mattyw | natefinch, no problem, whenever is good | 14:26 |
| mgz | frankban: ha, I nearly did that, my bad, should have double checked when you posted the first one | 14:26 |
| === vladk|offline is now known as vladk | ||
| frankban | mgz: tests seems to work locally with that patch | 14:26 |
| mgz | frankban: trying on the bot again | 14:28 |
| frankban | finger crossed | 14:28 |
| frankban | mgz: merged \o/ | 14:44 |
| wwitzel3 | cargo culting something and then working backwards on actually understanding it is a totally valid approach right? | 14:45 |
| mgz | frankban: ace | 14:47 |
| mgz | wwitzel3: provided part #2 happens :) | 14:47 |
| frankban | mgz: thanks a lot for your help | 14:49 |
| wwitzel3 | mgz: right :) | 14:49 |
| mgz | everyone: stuff should now be landable, when pulling trunk you'll want new golxc and testing packages | 14:49 |
| wwitzel3 | nice | 14:50 |
| natefinch | wwitzel3, perrito666: finishing up last meeting, be there in a couple minutes | 15:01 |
| perrito666 | natefinch: ack | 15:01 |
| wwitzel3 | natefinch: sounds good, no one else is here yet anyway :P | 15:01 |
| perrito666 | wwitzel3: michael and I are | 15:01 |
| perrito666 | you might want to check where you are | 15:01 |
| wwitzel3 | moonstone? | 15:01 |
| perrito666 | wwitzel3: yup | 15:02 |
| wwitzel3 | perrito666: had to restart it, standard issue hangout | 15:02 |
| voidspace | natefinch: you still in a meeting? | 15:06 |
| natefinch | voidspace: coming | 15:06 |
| dimitern | anyone willing to review a trivial fix for bug 1323263 ? https://codereview.appspot.com/101820044/ | 15:16 |
| _mup_ | Bug #1323263: remove --exclude-network from deploy <deploy> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1323263> | 15:16 |
| dimitern | natefinch, perrito666, wwitzel3, voidspace, ^^ ? | 15:20 |
| voidspace | dimitern: looking | 15:22 |
| dimitern | voidspace, cheers! | 15:23 |
| perrito666 | voidspace: natefinch ping me on irc if you need a hand loving mongo, bbiab going to lunch | 15:23 |
| voidspace | dimitern: yep, looks good to me | 15:25 |
| dimitern | voidspace, thanks | 15:26 |
| voidspace | hmmm... the mgoDialTimeout is 60 seconds so I don't think it's that we're not waiting long enough | 15:46 |
| === vladk is now known as vladk|offline | ||
| === psivaa-sprint is now known as psivaa | ||
| perrito666 | fwereade: the warning message is very fun | 15:58 |
| fwereade | perrito666, :D | 15:58 |
| perrito666 | voidspace: any luck? | 16:00 |
| voidspace | perrito666: specifying an explicit logpath seems to cause a tls connection failure! | 16:01 |
| voidspace | ERROR: cannot read certificate file: /tmp/test-mgo234085341/server.pem error:02001002:system library:fopen:No such file or directory | 16:01 |
| voidspace | which is new :-) | 16:01 |
| perrito666 | voidspace: yay | 16:01 |
| voidspace | perrito666: I can tell the problem because it *does* create the logfile | 16:02 |
| perrito666 | race? permissions? | 16:03 |
| voidspace | perrito666: it creates the log file fine so it can't be permissions I don't think | 16:03 |
| voidspace | I'm going to remove the logfile options to see if those are *really* the cause | 16:04 |
| voidspace | I suspect not | 16:04 |
| jcw4 | fwereade: thx | 16:05 |
| voidspace | maybe they really are. seems to be back to failing for the old reasons. | 16:05 |
| natefinch | back | 16:06 |
| voidspace | natefinch: hey, hi | 16:06 |
| voidspace | natefinch: so adding a "--logpath" parameter to mongod causes it to fail to start with "ERROR: cannot read certificate file" | 16:07 |
| voidspace | I guess it logs to syslog by default | 16:10 |
| voidspace | hmmm... maybe not | 16:10 |
| perrito666 | voidspace: grep on /var/log :p it must be there somewhere | 16:12 |
| voidspace | perrito666: we're starting it without logging options - I think it logs to stdout by default | 16:13 |
| voidspace | perrito666: so not necessarily | 16:13 |
| perrito666 | really? | 16:13 |
| voidspace | well, not sure :-) | 16:15 |
| natefinch | sorry, that back was premature. Back now. | 16:15 |
| voidspace | perrito666: but there are options to set logging to syslog and options to set it to a file | 16:15 |
| voidspace | perrito666: there is no option to set it to standard out - but it's mentioned several times | 16:16 |
| voidspace | perrito666: the implication being that it's the default if you don't specify a logpath or syslog | 16:16 |
| voidspace | natefinch: I'm grabbing coffee | 16:18 |
| === Ursinha is now known as Ursinha-afk | ||
| voidspace | logging to syslog causes the tests to hang | 16:38 |
| voidspace | this time logging to a file caused the error: | 16:38 |
| voidspace | ERROR: dbpath (/tmp/test-mgo975498476) does not exist. | 16:38 |
| voidspace | ah, however maybe we *use* the standard output to tell when mongo has started | 16:39 |
| voidspace | so diverting logging causes the tests to not know when mongo has started | 16:39 |
| voidspace | yeah, we're capturing output | 16:40 |
| sinzui | voidspace, I am watching this test. I failed, but I see a new set of debs being published that will run this test again http://juju-ci.vapour.ws:8080/job/local-deploy-precise-amd64/ | 16:58 |
| sinzui | voidspace, mongodb replication set issue on precise localhost http://juju-ci.vapour.ws:8080/job/local-deploy-precise-amd64/1349/console | 16:58 |
| voidspace | sinzui: oh dear | 16:59 |
| sinzui | voidspace, the test used mongodb-server 1:2.4.6-0ubuntu5~ctools1 | 17:00 |
| voidspace | dammit | 17:00 |
| voidspace | I have to leave now | 17:00 |
| sinzui | damn, voidspace The newest revision fails the same way http://juju-ci.vapour.ws:8080/job/local-deploy-precise-amd64/1350/console | 17:00 |
| voidspace | I'm going out with wife and friends so can't postpone | 17:01 |
| sinzui | voidspace, I will talk to the other devs | 17:01 |
| voidspace | but that looks like a problem | 17:01 |
| natefinch | voidspace: go go, we'll figure it out | 17:01 |
| natefinch | (or not) | 17:01 |
| voidspace | maybe we need to back out the local provider change :-/ | 17:01 |
| voidspace | needs testing with precise | 17:01 |
| voidspace | natefinch: thanks, :-( | 17:02 |
| voidspace | I have to go, so EOD | 17:03 |
| voidspace | natefinch: if there's anything I need to do for the morning email me | 17:03 |
| natefinch | voidspace: will do | 17:03 |
| voidspace | natefinch: I could setup a precise VM to try it (in fact I probably have one) | 17:03 |
| sinzui | natefinch, note that this issue happened first in 2804, which passed on trusty ppc64. It will retested with 2806 soon | 17:05 |
| alexisb | awesome, thanks cmars for the doc | 17:50 |
| === vladk|offline is now known as vladk | ||
| perrito666 | mm launchpad just emailed me saying it could not email me a code review comment | 19:10 |
| perrito666 | anyone got one of those before? | 19:10 |
| perrito666 | btw, https://codereview.appspot.com/100810045 I will especially appreciate comments on how to improve tests | 19:12 |
| perrito666 | bbiab | 19:12 |
| bodie_ | fwereade, https://codereview.appspot.com/94540044/ | 19:56 |
| perrito666 | fwereade: you overbritished me :p what is pointification | 20:49 |
| fwereade | perrito666, speaking as if one were the pope :) | 20:49 |
| perrito666 | fwereade: well, the pope speaks spanish :p | 20:50 |
| fwereade | perrito666, ("to speak in a pompous or dogmatic manner", anyway) | 20:50 |
| perrito666 | altough I would definitely drop my jaw if I got such network savvy comment | 20:50 |
| fwereade | haha | 20:50 |
| fwereade | perrito666, that's not how VLANs work, my child | 20:51 |
| perrito666 | 22/TCP in "thow shall not pass" | 20:51 |
| === Ursinha-afk is now known as Ursinha | ||
| perrito666 | fwereade: anyway I like your approach better | 21:00 |
| fwereade | perrito666, I'm not quite sure I really like either of my suggestions -- I have a nasty feeling that the "best" one is an untractably tedious hassle to actually implement | 21:01 |
| perrito666 | fwereade: 2 is better than current | 21:01 |
| fwereade | perrito666, the two-part one might be viable, but get someone else's input, it's late and I'm a bit tired | 21:01 |
| perrito666 | fwereade: well lat night shift is about to kick in | 21:01 |
| perrito666 | and apparently I have a meeting tonight at 11PM | 21:02 |
| fwereade | perrito666, yeah, I won;t be at that one I'm afraid | 21:02 |
| fwereade | perrito666, all I'm really good for is reading devops borat, I should probably just go to bed | 21:03 |
| perrito666 | well, my current time zone makes me feel guilty to miss any f the 3 meeting shifts :p | 21:03 |
| perrito666 | oh man, now you just made me hook with devop borat | 21:06 |
| fwereade | When you are run DROP DATABASE you are have of many problem but Big Data is not of one of them. | 21:07 |
| bodie_ | lol | 21:11 |
| bodie_ | that was eminently quotable | 21:11 |
| fwereade | menn0, waigani, thumper: was there anything I needed to talk to any of you about? | 21:26 |
| thumper | fwereade: not entirely sure | 21:26 |
| waigani | fwereade: just getting through emails now. Did we reach agreement on a flag? | 21:26 |
| menn0 | fwereade: I'm waiting a tiny bit of review feedback ... | 21:27 |
| * menn0 looks up review | 21:27 | |
| fwereade | waigani, I like thumper's idea: make it a cmd-specific format | 21:27 |
| waigani | so just $ juju switch --format | 21:27 |
| fwereade | waigani, sill not sure if it should be called "smart" or something else, but the default output format can be the original behaviour and we can get json/yaml as usual | 21:28 |
| waigani | fwereade: ^ | 21:28 |
| fwereade | waigani, yeah | 21:28 |
| waigani | okay, done | 21:28 |
| fwereade | waigani, cool | 21:28 |
| menn0 | fwereade: never mind me. I just saw that you have responded (still getting through email) | 21:28 |
| fwereade | menn0, cool, I thought I had :) | 21:28 |
| waigani | menn0 I know the feeling - tooo many emails! | 21:29 |
| * perrito666 notices fwereade setting the terrain to flee | 21:29 | |
| menn0 | fwereade: I also have a tiny question about how one aspect of upgrades work but I don't know if you're the person for that | 21:29 |
| menn0 | waigani: the email volume here is tiny compared to my last job (500-1000 per day). working here has been a relief in that regard. | 21:30 |
| waigani | yikes! | 21:30 |
| perrito666 | menn0: wow, that is so much mail to ignore | 21:30 |
| waigani | did you work at a spam company? | 21:30 |
| waigani | menn0: I think wallyworld knows a bit about upgrades | 21:31 |
| perrito666 | waigani: he worked at a company that processed dbus calls, by hand | 21:31 |
| fwereade | menn0, I was just looking at them and I'm worried about the order in which we run the upgrade steps, so I might be able to answer | 21:31 |
| menn0 | no, just a company with a lot of automated systems that squawked via email when unhappy and a company culture where you got included in every email discussion | 21:31 |
| menn0 | fwereade: hangout? | 21:31 |
| fwereade | menn0, sure, would you start one please? just grabbing a drink :) | 21:32 |
| menn0 | fwereade: sure. I think this will be quick if that helps :) | 21:32 |
| perrito666 | fwereade: I see you are setting the example | 21:32 |
| fwereade | perrito666, ehh, not sure how laudable it is really ;p | 21:33 |
| perrito666 | fwereade: I said example, the word good was never involved | 21:33 |
| menn0 | fwereade: https://plus.google.com/hangouts/_/gutacrivw5fqrtq2mojvs5qjxma?authuser=1&hl=en-GB | 21:33 |
| perrito666 | fwereade: can I steal tomorrow a moment from you so we think trough the options for apiworker host? I like option 2 but I am not sure how much work is involved vs how much does it add against 1 | 21:40 |
| === Ursinha is now known as Ursinha-afk | ||
| fwereade | perrito666, the big question is how easy it is to extract information about what machines the addresses are associated with from the doc in state, and I've completely forgotten its content | 21:41 |
| fwereade | perrito666, if it's easy to get that info back, it's easy for the API server to tell that machine X wants to know state server addresses, hey machine X is a state server, let's tell it local host | 21:41 |
| fwereade | perrito666, if it's hard, it might not be worth doing... but, hmm, even if it's not in that doc it should be pretty trivial to craft a query to reassemble that data with machine ids as part of it | 21:42 |
| perrito666 | fwereade: I am a bit sleepy, cold medicine has been doing that to me a lot, tomorrow I will definitely re-ping you regarding this | 21:47 |
| fwereade | perrito666, ok, be prepared for a bit of spitting with rage -- not at you, but at the common.APIAddresser code, which is not set up for bulk calls | 21:50 |
| fwereade | perrito666, because "who would ever need them" | 21:50 |
| fwereade | perrito666, and yet it fucks us because we don't know who's asking without fiddling inappropriately with the auth object | 21:51 |
| perrito666 | fwereade: I noticed, I tried to reproduce it for the thing that keeps track of state instances and it really is... interesting | 21:51 |
| fwereade | perrito666, it's not "what are the api servers" -- it is "what are the api servers we want to expose for entity X" | 21:51 |
| perrito666 | yep | 21:52 |
| fwereade | perrito666, every time we make that assumption it leads to a fuckup | 21:52 |
| perrito666 | fwereade: I must admit it was a pretty large thing to swallow and I still am not entirely sure to understand how it fully works | 21:53 |
| fwereade | perrito666, and it's always for the same fucking stupid reason, that we can't possibly imagine when we'd want to discriminate according to the recipient of the information | 21:53 |
| fwereade | perrito666, sorry, I'm ranting at you and you don't deserve it | 21:53 |
| fwereade | perrito666, it's a definite candidate for immediate unfucking once we have api versions, though | 21:54 |
| fwereade | perrito666, ok, I will be off, and let you go | 21:54 |
| * fwereade does a bit of crazy-person handwaving and eyerolling on his way out | 21:55 | |
| menn0 | given that today is github conversion day do we need to hold off merging anything until it's done? | 21:55 |
| fwereade | menn0, if you can slip it in before wallyworld wakes up I think you're ok -- but I'm not sure if he actually sleeps | 21:56 |
| wallyworld | wot | 21:56 |
| perrito666 | fwereade: lol, rant away, I dont mind | 21:56 |
| perrito666 | I would mind less if I had a beer | 21:56 |
| wallyworld | fwereade: menn0: i am delaying the cut over | 21:56 |
| wallyworld | email not sent yet | 21:56 |
| wallyworld | but soon will be | 21:56 |
| fwereade | oh, yeah, curtis isn't ready? | 21:56 |
| fwereade | anyway, really off now | 21:57 |
| perrito666 | fwereade: bye | 21:57 |
| menn0 | fwereade: bye, thanks for the help | 21:57 |
| wallyworld | fwereade: a few reasons, but given CI is currently unhappy, we really need to get that sorted out first | 21:59 |
| wallyworld | thumper: can we reschedule our 1:1 to after the core meeting today? | 22:10 |
| waigani | thumper: my calender tells me we have a core meeting from 2pm to 3pm today. Is that correct? | 22:16 |
| perrito666 | waigani: if that is in like 4 hs yes | 22:17 |
| waigani | perrito666: sounds about right | 22:17 |
| waigani | yay, I'm actually going to be away for a meeting | 22:17 |
| waigani | AND have my voice! | 22:17 |
| waigani | now if only I had something to say... | 22:18 |
| waigani | s/away/awake | 22:18 |
| perrito666 | waigani: we are now doing shifting meetings | 22:18 |
| perrito666 | so everyone has the chance to go to at least 2 iirc | 22:18 |
| waigani | yeah I saw that, hard to keep track of | 22:18 |
| waigani | but i'm sure I'll get use to it | 22:19 |
| thumper | waigani: yes... | 22:19 |
| perrito666 | waigani: not really | 22:19 |
| thumper | waigani: this is the attempt to have a rolling meeting schedule | 22:19 |
| thumper | waigani: so it isn't terrible for some people all the time | 22:19 |
| perrito666 | this one its outside of my tz but if I am awake I will most likely be there | 22:19 |
| thumper | waigani: but instead terrible for everyone some of the time | 22:19 |
| thumper | waigani: also we don't have to go to them all now... | 22:19 |
| waigani | hehe, true | 22:19 |
| thumper | like the ones at 4am or whatever | 22:19 |
| waigani | that is good | 22:20 |
| === vladk is now known as vladk|offline | ||
| waigani | okay, time to code | 22:20 |
| thumper | wallyworld: yeah, sure | 22:23 |
| wallyworld | ok | 22:23 |
| thumper | menn0, waigani: rick_h_ had me thinking in the meeting we just had where he said we were making a terrible user experience, and I think he is right | 22:30 |
| thumper | this is with respect to sharing environments | 22:30 |
| thumper | how about 'juju login username@api-endpoint' | 22:30 |
| thumper | prompts for password | 22:30 |
| thumper | hmm... needs a name | 22:31 |
| thumper | juju login env-name username@api-endpoint | 22:31 |
| thumper | makes env-name.jenv file | 22:31 |
| thumper | errors out if env-name already in the environments store | 22:31 |
| thumper | juju logout could remove the jenv file | 22:31 |
| thumper | with obvious warnings like "this doesn't destroy the environment" | 22:32 |
| waigani | so if there where two environs with the same name, they would be disambiguated by the endpoint? Oh, not with a multi tenant state | 22:33 |
| waigani | thumper: would this replace switch? | 22:34 |
| thumper | waigani: no... it replaces the "here is a jenv file, put it in the right place" | 22:35 |
| thumper | waigani: we may well implicitly switch when they login | 22:35 |
| waigani | right I get you | 22:35 |
| thumper | waigani: the env-name is just what I call it | 22:35 |
| thumper | waigani: obviously when we have multi-env state servers, we will need a way to identify the environment within the state server | 22:36 |
| waigani | yeah - and THAT should be the environ-name (or id) | 22:36 |
| thumper | probably uuid | 22:36 |
| waigani | actually, we already have that | 22:37 |
| thumper | we do, but in a state server where there is only one environment, we can leave it out | 22:37 |
| thumper | but we could write the code now to specify it | 22:37 |
| thumper | I think that is a good plan | 22:37 |
| thumper | so... | 22:38 |
| waigani | So we have the UUID field in environmentDoc, but we currently don't use it? | 22:38 |
| thumper | juju login <local-name> <user@endpoint> [<env-uuid>] | 22:38 |
| thumper | waigani: right | 22:38 |
| thumper | or we don't use it for much :) | 22:39 |
| * thumper thinks... | 22:39 | |
| thumper | consider this: | 22:39 |
| waigani | and the usecase is: environ exists, has been bootstrapped, has default .jenv file. Then you want to give a new user access to this environ? | 22:39 |
| thumper | juju login prod-foo thumper@jaas.io paste-uuid-from-email | 22:40 |
| thumper | waigani: yes | 22:40 |
| thumper | I think this is better than the 'generate jenv' option | 22:41 |
| waigani | why do you need the prod-foo? | 22:41 |
| thumper | it is the name of the environment for me | 22:41 |
| thumper | ~/.juju/environments/prod-foo.jenv is created | 22:41 |
| thumper | otherwise, what do we call it? | 22:42 |
| waigani | hmm, does the user really need to name that? I suppose for switching later? | 22:42 |
| thumper | right... | 22:42 |
| thumper | although, interestingly... | 22:42 |
| thumper | we could default to try to use the name that is identified by the environment itself | 22:42 |
| waigani | I'm just wondering if we can automate it in the background | 22:42 |
| thumper | as the environment has a 'name' | 22:43 |
| waigani | right, appended with the user's name/id? | 22:43 |
| thumper | ick | 22:43 |
| waigani | then the .jenv just becomes a background implementation detail | 22:43 |
| thumper | it needs to be something that the user can switch to easily | 22:44 |
| waigani | I'm missing where authentication is happening? | 22:44 |
| thumper | I don't want all my environments named with my name at the end | 22:44 |
| thumper | we authenticate as part of the login, what the login does is create the .jenv file for us | 22:44 |
| waigani | so the user will get prompted for a password? | 22:45 |
| thumper | yes | 22:45 |
| waigani | why not also propt them for a .jenv name? | 22:45 |
| waigani | with a default | 22:45 |
| thumper | we could... if they don't specify a name on the command line | 22:45 |
| waigani | $ juju login thumper@jaas.io paste-uuid-from-email | 22:45 |
| waigani | password: | 22:45 |
| waigani | env-name [default]: | 22:46 |
| thumper | sure | 22:46 |
| waigani | we have to stop calling it environ-name | 22:47 |
| thumper | well... maybe | 22:48 |
| waigani | are we storing the user's uuid in the .jenv? | 22:49 |
| waigani | if .jenv is deleted on logout, do we need it in the first place? Is it just playing the role of keeping user session? | 22:51 |
| perrito666 | ok I am going to get dinner, I might be back for the team meeting if I dont fall sleep before cheers | 22:54 |
| waigani | the other way to approach this with a different workflow: 1. authenticate to a state server 2. be presented with environs you are allowed to access 3. once an environ is chosen, be presented with users that you can login as | 22:54 |
| waigani | thumper: ^ | 22:54 |
| thumper | waigani: that doesn't really make sense | 22:55 |
| thumper | waigani: as step 1 and step 3 don't really work together | 22:55 |
| thumper | waigani: I do see where you are getting at, but it doesn't scale | 22:55 |
| thumper | waigani: consider jaas.io where I have access to 1500 environments | 22:55 |
| waigani | right | 22:56 |
| waigani | so which part does not scale? | 22:57 |
| thumper | be presented with environs I can access to choose the one | 22:58 |
| waigani | well, that can be handled in the ux - e.g. apt-get | 22:59 |
| thumper | except which of the 1500 uuids do I choose? | 23:00 |
| thumper | I understand where you are coming from, I just disagree in the approach | 23:00 |
| waigani | I have some gaps in my understanding of the user workflow and what role .jenv is playing | 23:00 |
| waigani | standup time! | 23:01 |
| sinzui | I think mongo killed stilson-06. I killed the proc, but juju cannot bootstrap anymore. And the disk is full, but I cannot find what is taking up 4G+ of space | 23:44 |
| sinzui | reboot at least restored 2G | 23:52 |
| sinzui | no, 7G | 23:52 |
| * sinzui tries stable juju again | 23:53 | |
| sinzui | yeah | 23:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!