| mup | Bug #1493598 opened: dblogpruner uses *state.State <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1493598> | 00:26 |
|---|---|---|
| * thumper is filing bugs for the workers | 00:29 | |
| mup | Bug # opened: 1493600, 1493601, 1493602, 1493604 | 00:44 |
| mup | Bug # changed: 1493600, 1493601, 1493602, 1493604 | 00:47 |
| mup | Bug # opened: 1493600, 1493601, 1493602, 1493604 | 00:53 |
| mup | Bug #1493606 opened: envworkermanager uses *state.State <tech-debt> <juju-core:New> <https://launchpad.net/bugs/1493606> | 00:56 |
| mup | Bug #1493606 changed: envworkermanager uses *state.State <tech-debt> <juju-core:New> <https://launchpad.net/bugs/1493606> | 00:59 |
| sarnold | what's the deal with the n.mu mutex protecting assignment and reading tag_ in ./apiserver/apiserver.go ? are assignments not atomic operations in go? | 01:06 |
| mup | Bug #1493606 opened: envworkermanager uses *state.State <tech-debt> <juju-core:New> <https://launchpad.net/bugs/1493606> | 01:08 |
| === akhavr1 is now known as akhavr | ||
| === natefinch-afk is now known as natefinch | ||
| natefinch | sarnold: assignments aren't guaranteed to be atomic, no. There's sync/atomic if you need some specific atomic assignments, or for most things, there's locks. | 01:31 |
| sarnold | natefinch: can you aim me towards some documentation? that seems like it might be fairly subtle, and I'd like to know more | 01:34 |
| natefinch | sarnold: https://golang.org/ref/mem | 01:35 |
| sarnold | natefinch: thanks! | 01:35 |
| natefinch | sarnold: welcome. The tldr is right there at the top: If you must read the rest of this document to understand the behavior of your program, you are being too clever. Don't be clever. | 01:36 |
| sarnold | natefinch: indeed :) it's just that tag() and login() both look like they ought to work fine without the mutex, and the fact that it has one is surprising... | 01:36 |
| natefinch | sarnold: the string assignment isn't atomic. If you call login from one goroutine, which modifies the tag, and call tag() from another goroutine, it's possible that login could have only half-written the pointer inside the string, and tag() would return garbage | 01:39 |
| natefinch | sarnold: also, what's more likely is that the pointer gets updated but the length doesn't get updated... so you could read past the end of the string | 01:44 |
| davecheney | thumper: wallyworld did someone justa dd a worker/uniter/relations package ? | 02:00 |
| mwhudson | natefinch: writes to word sized quantities really should be atomic in the sense that another thread will either see all the write or none of it | 02:02 |
| mwhudson | *of | 02:02 |
| mwhudson | the thing about the pointer vs length write is 100% valid | 02:03 |
| natefinch | mwhudson: yeah, I was thinking that - it's not guaranteed, but it really should be | 02:03 |
| mwhudson | natefinch: ot | 02:03 |
| davecheney | natefinch: mwhudson word aligned writes are atomic | 02:03 |
| davecheney | another thread will not see a torn write | 02:03 |
| mwhudson | to be fair i've only read the arm64 manual closely on this | 02:03 |
| davecheney | but it is also true that another thread may not see the write at all | 02:03 |
| wallyworld | davecheney: yes, that was me i think when i merged in the uniter v2 work | 02:04 |
| davecheney | http://paste.ubuntu.com/12318103/ | 02:11 |
| davecheney | really unstable | 02:11 |
| davecheney | and there are data races | 02:11 |
| davecheney | sorry, i meant to say | 02:11 |
| davecheney | the tests are unstable and have races | 02:12 |
| natefinch | worst test failure output ever? http://pastebin.ubuntu.com/12318026/ | 02:13 |
| davecheney | s/worst/longest | 02:14 |
| natefinch | davecheney: I guess it's not actually incorrect or misleading... just useless and long | 02:14 |
| natefinch | more impressive with the line returns in my terminal | 02:14 |
| * natefinch wonders how hard it would be to embed some ascii art as a test failure output without making it too obvious in the code | 02:15 | |
| mwhudson | natefinch: i am still scarred by the fact that the mongodb package build logs have/had a line that is something like 120k long | 02:16 |
| natefinch | mwhudson: wow, winning. | 02:16 |
| mwhudson | totally | 02:16 |
| mwhudson | scons for the win, indeed | 02:16 |
| natefinch | I built mongodb from source... once. It was horrible. | 02:17 |
| davecheney | https://bugs.launchpad.net/juju-core/+bug/1493623 | 02:17 |
| mup | Bug #1493623: worker/uniter/relation: relationsSuite.TestCommitHook tests fail <juju-core:New> <https://launchpad.net/bugs/1493623> | 02:17 |
| mup | Bug #1493623 opened: worker/uniter/relation: relationsSuite.TestCommitHook tests fail <juju-core:New> <https://launchpad.net/bugs/1493623> | 02:17 |
| menn0 | thumper: you able to chat? | 02:24 |
| thumper | menn0: sure | 02:27 |
| menn0 | thumper: standup? | 02:29 |
| thumper | ah... yeah. | 02:29 |
| natefinch | gah, I hate it when rebase gives me a merge conflict that I know has nothing to do with the changes I made | 02:35 |
| wallyworld | don't use rebase :-) | 02:35 |
| wallyworld | rebase sucks | 02:35 |
| natefinch | wallyworld: I don't really have a choice. I pushed some code based off of what was evidently an old copy of master... it's either rebase or have a merge commit in my branch | 02:36 |
| natefinch | wallyworld: or create a new branch and cherry pick my changes. ... I mean, if anyone has a fix that is not rebase, I'm all ears. | 02:36 |
| wallyworld | merge commit isn't so bad is it? | 02:36 |
| wallyworld | it's just an extra commit | 02:36 |
| natefinch | wallyworld: sometimes it makes your branch look like it has changed everything in that merge commit. | 02:37 |
| wallyworld | gad, i wish we still used bzr | 02:37 |
| natefinch | wallyworld: sometimes it's fine and sometimes it screws me. I never really now which it'll end up being | 02:37 |
| wallyworld | that crap just doen't happen | 02:37 |
| natefinch | I hear betamax was pretty good too, but what can you do? | 02:38 |
| * natefinch goes with door #2 - new branch and cherry pick | 02:44 | |
| natefinch | dunno why git rebase master is different than making a new branch off master and cherry-picking my changes... but the latter works 100% of the time, whereas rebase is batting about 50% for me. | 02:49 |
| natefinch | ahh, I think the difference is git rebase vs. git pull --rebase | 02:52 |
| wallyworld | thumper: why mark that bug as a blocker? has CI failed? they need fixing sure, but not a blocker | 03:50 |
| thumper | wallyworld: it's a blocker if people can't get tests passing locally, surely? | 03:50 |
| wallyworld | this is the first i've hear dof them not passing for anyone, they passed for all of us on the sprint | 03:51 |
| wallyworld | and the bot | 03:51 |
| thumper | wallyworld: dave has them failing every time for him | 03:51 |
| wallyworld | hmmm, ok | 03:51 |
| thumper | a key question then would be "what's different?" | 03:51 |
| wallyworld | indeed | 03:51 |
| wallyworld | ppc maybe? | 03:52 |
| thumper | wallyworld: also, there are races in the code that landed | 03:52 |
| thumper | wallyworld: did you check with -race? | 03:52 |
| wallyworld | no :-( the races need fixing | 03:52 |
| natefinch | I have a few tests on master failing 100% | 03:52 |
| wallyworld | but just races is not a blocker, but if there's a genuine failure there... | 03:52 |
| wallyworld | natefinch: uniter/relations? | 03:53 |
| natefinch | wallyworld: no, weird random crap... /cmd/plugins/local and /mongo ... both seems to be some difference in quoting | 03:54 |
| wallyworld | ok, not related then i don't think | 03:54 |
| natefinch | ccd | 03:54 |
| thumper | damn... | 03:55 |
| thumper | I can't get the tests to run at all | 03:55 |
| natefinch | ahh, I'm dumb, didn't update godeps | 03:55 |
| thumper | davecheney: any ideas ? http://paste.ubuntu.com/12318539/ | 03:56 |
| wallyworld | thumper: i don't see the need to block people landing stuff for the sake of fixing tests in one package | 03:56 |
| wallyworld | especilly if CI is not broken | 03:56 |
| thumper | wallyworld: the alternative that was agreed on is reverting the revision | 03:56 |
| wallyworld | well i don't agree it's a blocker | 03:57 |
| natefinch | thumper: that looks like a difference in stdlib | 03:57 |
| wallyworld | bot passes, CI is not failed | 03:57 |
| thumper | wallyworld: if you want to make that call, change it, bit know that I'm grumpy | 03:57 |
| wallyworld | tests only fail in one instance for one person so far | 03:57 |
| wallyworld | you're always grumpy :-) | 03:58 |
| thumper | I can't get them to run either | 03:58 |
| wallyworld | oh, ok | 03:58 |
| wallyworld | damn | 03:58 |
| wallyworld | wtf did the bot pass then | 03:58 |
| * thumper shrugs | 03:58 | |
| wallyworld | and everyine else testing that branch | 03:58 |
| thumper | I have the lxd ppa | 03:58 |
| wallyworld | sigh | 03:58 |
| thumper | which brings in a later golang | 03:58 |
| wallyworld | ah | 03:59 |
| wallyworld | that could wee be it | 03:59 |
| wallyworld | i think we're still on 1.4 | 03:59 |
| natefinch | we're on 1.2.x last I heard | 03:59 |
| wallyworld | the ppa builder is | 03:59 |
| natefinch | working on upgrading to 1.5 | 03:59 |
| wallyworld | most devs are on 1.4 | 03:59 |
| thumper | 1.4.2 is my local version | 03:59 |
| natefinch | the official version we must build with is 1.2 | 04:00 |
| thumper | I wonder why my stdlib changed? | 04:00 |
| wallyworld | natefinch: "we" = ppa packager yes | 04:00 |
| wallyworld | for now | 04:01 |
| natefinch | yes, sorry.. I meant, juju is officially built with 1.2 | 04:01 |
| natefinch | we as devs can build with whatever we want, but may introduce problems if we rely on stuff that isn't in older versions of go | 04:01 |
| wallyworld | yep | 04:02 |
| natefinch | ....like references to stuff that isn't in older versions of the stdlib | 04:03 |
| natefinch | however, worker/uniter/relation builds fine with go 1.2.2 on my machine | 04:05 |
| natefinch | and evidently the bot | 04:05 |
| natefinch | thumper: what is really bizarre is that you're getting undefined symbols inside the standard library itself | 04:06 |
| natefinch | thumper: I'd say your standard library is hosed somehow | 04:06 |
| mwhudson | thumper: can you update loggo to import gopkg.in/check.v1 rather than launchpad.net/gocheck pls? | 04:10 |
| wallyworld | thumper: i see a data race in one place. maybe fixing that will solve your issue | 04:13 |
| thumper | mwhudson: sure | 04:13 |
| thumper | I may well reboot to see if it fixes the issues :) | 04:15 |
| thumper | works for windows right? | 04:15 |
| mwhudson | thumper: do you have GOROOT set? | 04:19 |
| mwhudson | doh | 04:19 |
| thumper | hmm.. rebooting didn't fix it | 04:20 |
| thumper | perhaps I need to reinstall golang? | 04:20 |
| natefinch | thumper: probably a good idea | 04:21 |
| natefinch | thumper: build from source, it's better | 04:22 |
| thumper | no, I'm not that kinda person | 04:22 |
| natefinch | it's really easy, but ok :) | 04:22 |
| thumper | hmm... | 04:23 |
| thumper | reinstall brought in 1.2.1 | 04:23 |
| thumper | which didn't fix the problem | 04:23 |
| thumper | natefinch: it is more a philisophical reason | 04:23 |
| thumper | not because I can't, but I shouldn't have to | 04:23 |
| mwhudson | thumper: do you have GOROOT set? | 04:24 |
| mwhudson | oops need to run | 04:24 |
| * thumper looks | 04:24 | |
| natefinch | it just makes it easier to switch between versions, for the most part... plus then you're not tied to whatever ubuntu ships | 04:25 |
| thumper | no just GOPATH | 04:25 |
| natefinch | thumper: that's good, you generally shouldn't set goroot | 04:25 |
| thumper | natefinch: I understand, and I was working more with Go and cared, I would | 04:25 |
| thumper | but Juju needs to use the version in the distro | 04:25 |
| thumper | so best to use the version in the distro to compile locally | 04:26 |
| natefinch | thumper: certainly | 04:26 |
| thumper | knowing that some are using later versions to test for incompatibility | 04:26 |
| thumper | I bet I have part of newer versions installed | 04:26 |
| thumper | ... | 04:26 |
| natefinch | yep | 04:26 |
| natefinch | if you installed from source you could do git status and see what was out of place ;) | 04:27 |
| natefinch | blow it away and reinstall | 04:27 |
| natefinch | it would be good to know how it got that way, though... if there's some package stomping on the go install, that's a really bad thing | 04:28 |
| wallyworld | thumper: works for me, but that doesn't mean it will work for you http://reviews.vapour.ws/r/2613/ | 04:29 |
| natefinch | ok, way past EOD for me (literally and figuratively) g'night all | 04:29 |
| thumper | yep... | 04:35 |
| * thumper now has golang 1.5 | 04:35 | |
| thumper | I had disabled the lxd ppa before | 04:35 |
| thumper | and that left me in a weird state | 04:35 |
| thumper | reenabled | 04:35 |
| thumper | upgraded, and now seems to be compiling at least | 04:36 |
| wallyworld | thumper: that fix eliminates the race (well test --race is happy) so maybe it will solve your problem with go 1.5 | 04:37 |
| wallyworld | i still can't reproduce | 04:37 |
| thumper | my build problem was a local issue | 04:38 |
| thumper | I've fixed my build problem | 04:38 |
| thumper | running all the tests now | 04:38 |
| wallyworld | thumper: could you take a look at the pr and i'll land if you're happy | 04:39 |
| thumper | wallyworld: one big problem, and one stylistic | 04:47 |
| wallyworld | ok | 04:47 |
| thumper | I think I must be going crazy | 04:48 |
| thumper | mwhudson: where are you looking? github.com/juju/loggo does use gocheck from gopkg.in | 04:50 |
| thumper | wallyworld: I get worker/uniter/relation tests failing every time too | 04:54 |
| thumper | wallyworld: when you have tweaked the load, I'll test your fix | 04:54 |
| wallyworld | thumper: pushed | 04:54 |
| thumper | wallyworld: is the int32 cast really needed? does golang complain? | 04:55 |
| wallyworld | thumper: sadly yes | 04:55 |
| wallyworld | i didn't have it at first | 04:56 |
| thumper | well, you could change the expected arg to be int32 instead of int | 04:56 |
| thumper | that would get the compiler doing the right thing | 04:56 |
| wallyworld | thumper: hang on, i removed it and it worked, ffs | 04:56 |
| wallyworld | ah no | 04:57 |
| wallyworld | it didn't, tests fail | 04:57 |
| wallyworld | gc.Equals complains | 04:57 |
| wallyworld | if one arg is int and oter is int32 | 04:57 |
| wallyworld | changing arg worked | 04:58 |
| thumper | still fails for me | 04:59 |
| wallyworld | wot | 04:59 |
| wallyworld | works for me with --race and without | 04:59 |
| thumper | why is the test running asynchronously? | 04:59 |
| thumper | it is checking in parallel | 04:59 |
| thumper | one is happening before the other | 05:00 |
| thumper | you can't guarantee synchronisation across go routines | 05:00 |
| thumper | unless you synchronise them | 05:00 |
| thumper | this is why it is failing | 05:00 |
| wallyworld | what's running aync? | 05:00 |
| thumper | http://paste.ubuntu.com/12318735/ | 05:01 |
| thumper | request 6 is being checked | 05:01 |
| thumper | and while it is saying it is failing | 05:01 |
| thumper | request 7 is being checked | 05:01 |
| thumper | and fails | 05:01 |
| thumper | both are expecting the other value | 05:01 |
| wallyworld | but the test just sts up a mich api caller and makes some api calls to it in order | 05:01 |
| wallyworld | there's no go routines in the tests | 05:02 |
| wallyworld | i'll dig into it | 05:02 |
| thumper | there are go routines somewhere | 05:02 |
| * thumper looks too | 05:02 | |
| thumper | wallyworld: btw, OOPS: 15 passed, 7 FAILED | 05:02 |
| thumper | for the relations package | 05:02 |
| wallyworld | and yet passes for me and other and bot | 05:03 |
| thumper | they aren't using golang 1.5 | 05:03 |
| thumper | so it is passing by accident | 05:03 |
| thumper | wallyworld: FWIW, `go test -check.f relationsSuite.TestHookRelationDeparted` I've had pass, and fail in two different ways | 05:07 |
| wallyworld | the tests are all synchronous so it must be in code somewhere | 05:07 |
| wallyworld | thumper: are the failures always Stop/Next ordering? | 05:08 |
| thumper | nope | 05:08 |
| wallyworld | how did you install go 1.5 i sthere appa? | 05:09 |
| thumper | http://paste.ubuntu.com/12318767/ | 05:09 |
| wallyworld | i looked for a ppa a while back and didn;t see one | 05:09 |
| davecheney | it's in wily now | 05:09 |
| thumper | add-apt-repository ppa:ubuntu-lxc/lxd-stable | 05:09 |
| thumper | apt-get update | 05:09 |
| thumper | apt-get dist-upgrade | 05:09 |
| thumper | get it if you want lxd :) | 05:09 |
| thumper | wallyworld: seems to be always ordering related | 05:10 |
| wallyworld | i could skip the tests on go 1.5 | 05:10 |
| thumper | but not always Stop/Next | 05:10 |
| wallyworld | and then fox | 05:10 |
| wallyworld | fix | 05:10 |
| thumper | nah | 05:10 |
| wallyworld | to unblock | 05:11 |
| thumper | that's terrible | 05:11 |
| wallyworld | i do want to remove the blocker tag | 05:11 |
| wallyworld | i'll get 1.5 and reproduce | 05:11 |
| wallyworld | thumper: if i get lxd, will it stuff up anything else in juju? | 05:12 |
| thumper | why not just get the deb out of the ppa by downloading directly and install? | 05:12 |
| wallyworld | sure, but lxd looks interesting :-) | 05:13 |
| === urulama_ is now known as urulama | ||
| thumper | wallyworld: if there aren't async calls, why would I get request 7 written to the test log before request 6? | 05:25 |
| thumper | the only way that would happen is if the active goroutine switched after incrementing the value but before writing to the test log | 05:26 |
| wallyworld | there must be in the underlying code, but no tthe tests which is what i thought you were referring to | 05:26 |
| thumper | I've not been able to find it | 05:26 |
| thumper | but I need to head out shortly | 05:26 |
| thumper | dinner date, anniversary | 05:27 |
| wallyworld | i just installed go 1.5 and now go is broken, so i'll look into that | 05:27 |
| thumper | sorry I couldn't be more help | 05:27 |
| davecheney | waigani: here is a simple one https://github.com/juju/juju/pull/3236 | 05:27 |
| davecheney | waigani: actaully scratch that | 05:32 |
| davecheney | no | 05:33 |
| davecheney | actually, i think this is ok | 05:33 |
| davecheney | waigani: http://reviews.vapour.ws/r/2615/ | 06:29 |
| davecheney | slightly larger change | 06:29 |
| wallyworld | fwereade: running a bit late | 07:30 |
| TheMue | dimitern: ping | 08:30 |
| dimitern | TheMue, pong | 08:31 |
| TheMue | dimitern: inside the space commands I wanted to differentiate between "not supported" and other API errors | 08:31 |
| TheMue | dimitern: today the API client simply passes the error through | 08:32 |
| dimitern | TheMue, yes | 08:32 |
| TheMue | dimitern: so also the params.NotSupported | 08:32 |
| dimitern | TheMue, you mean in the feature tests or? | 08:32 |
| TheMue | dimitern: a errors.IsNotSupported so doesn't match | 08:32 |
| TheMue | dimitern: the feature test is working, it only compares output | 08:32 |
| dimitern | TheMue, the equivalent of errors.IsNotSupported as a satisfier is params.IsCodeNotSupported (when testing an api error result) | 08:33 |
| TheMue | dimitern: but inside e.g. the list subcommand, here an API error could be this not support, but also a connection error or else | 08:33 |
| dimitern | TheMue, yes, that's true, but for the end user shouldn't matter - it's just an error we should display | 08:34 |
| TheMue | dimitern: yep, but I dislike the usage of params outside the API. so my proposal: check this inside the API client and in this case convert the error to a regular IsNotSupported | 08:34 |
| TheMue | dimitern: surely using params.IsNot... makes it more simple for me ;) | 08:35 |
| dimitern | TheMue, sorry, I'm not sure I follow you | 08:35 |
| dimitern | TheMue, let's discuss this at standup? | 08:36 |
| TheMue | dimitern: ok, we can do, it's better then | 08:36 |
| TheMue | dimitern: simply to describe my concerns, params to me is only a package to transfer data between api and apiserver and it shouldn't used outside (clean interfaces) | 08:37 |
| dimitern | TheMue, that's not entirely correct though - params types are used as well for anything that's returned from an api call (at the client-side), e.g. params.Life | 08:38 |
| === ashipika1 is now known as ashipika | ||
| TheMue | dimitern: I know, but exactly this is my concern :D it's not ... clean | 08:39 |
| dimitern | TheMue, the client-side api method (e.g. returning one result/error) that's calling the apiserver facade bulk method can return the result and an error, which can still effectively be a params.Error | 08:40 |
| TheMue | dimitern: yes, and so the user has to know, if an "errors" error or a "params" error is returned. my wish is that the API client always returns "errors" or own errors (phew, so many errors *lol*) | 08:42 |
| dimitern | TheMue, params.Error is just an error - you shouldn't expect the client-side api to hide its origin (a wrapped errors.NotSupported for examle) | 08:43 |
| dimitern | example* | 08:43 |
| dimitern | TheMue, so an error you get from the api is not the same as calling the respective state package method directly (which returns e.g. errors.NotSupported) | 08:44 |
| TheMue | dimitern: yes, exactly, that's why my errors.IsNotSupported failed and I wondered. a %#v then showed that it's a params and I looked into the API client | 08:48 |
| dimitern | TheMue, right :) - well, that's as expected; I don't consider it "unclean" :) - i.e. we shouldn't act like the API layer's not even there | 08:49 |
| TheMue | dimitern: yes, I think that's the way. but in my "optimal" world it would be kind of transparent *dream* | 08:50 |
| TheMue | dimitern: that's IMHO the task of the API client package, otherwise we could call the server directly like the UI does | 08:51 |
| dimitern | fwereade, jam, hey guys - are you joining standup? | 09:02 |
| jam | dimitern: I'm there | 09:02 |
| TheMue | dimitern: to get this one in before my vacation I'll add a card and TODOs and continue with params.IsNot... | 09:50 |
| TheMue | dimitern: will assign this card to me | 09:50 |
| dimitern | TheMue, TODOs about what? | 09:50 |
| TheMue | dimitern: as we discussed a help to convert params errors into their according counterparts (missed the word, unpacking?) | 09:51 |
| dimitern | TheMue, unwrapping :) | 09:52 |
| TheMue | dimitern: yeah, exactly, that's what I meant, thanks | 09:53 |
| dimitern | TheMue, well, it's a couple of lines of code for SupportSpaces, but ok I'm ok with a TODO+follow-up | 09:53 |
| TheMue | dimitern: for this one yes, it's small. thought about a more global approach later, that can be used elsewhere too | 09:54 |
| TheMue | dimitern: but I could start with the IsNotSupported as a first and only one *g* | 09:55 |
| dimitern | TheMue, I'm -1 on a global approach | 09:55 |
| dimitern | TheMue, as discussed - it's the api client-side method's job to do the conversion, if needed | 09:55 |
| dimitern | TheMue, doing it automagically sounds like opening a deep deep can of worms :) | 09:56 |
| TheMue | dimitern: yes,only thought about our generic errors we've got in juju/errors AND params | 09:56 |
| TheMue | dimitern: hehe, no, not automatically, only as a helper for inside the API client | 09:57 |
| TheMue | dimitern: kind of params.Unwrap(error) error | 09:57 |
| dimitern | TheMue, which will do something like if params.IsCodeXYZ(err) { return errors.NewXYZ(nil, err.Error()) ? | 09:58 |
| dimitern | TheMue, but it's simpler to do this as needed I think, rather than having a giant switch block in a helper like this | 09:59 |
| TheMue | dimitern: yeah, you may be right, feels better and more targeted. especially if there are also API specific errors that always have to be handled extra | 10:00 |
| TheMue | dimitern: so yes, will do it directly, no card, no todo. *lol* | 10:00 |
| dimitern | TheMue, cheers :) | 10:01 |
| frobware | dimitern: is there a standup on Thursdays? I don't see anything in my calendar. I have a conflict (P&C) so will skip either way. | 10:09 |
| dimitern | frobware, there is, I'll add you | 10:10 |
| dimitern | frobware, it was scheduled separately, because it used to overlap with the core leads call at some point | 10:10 |
| bogdanteleaga | fwereade, jam, so, about the retrying hooks on startup thing | 10:20 |
| bogdanteleaga | fwereade, jam, it seem it would be more productive to talk here | 10:20 |
| bogdanteleaga | fwereade, jam, does it sound like a good idea? | 10:20 |
| jam | sure | 10:21 |
| fwereade | bogdanteleaga, sure | 10:26 |
| rogpeppe | fwereade, jam: ping | 10:45 |
| jam | hi rogpeppe | 10:45 |
| rogpeppe | jam: hiya | 10:45 |
| rogpeppe | jam: we're just thinking of doing a reasonably wide-ranging change to juju/cmd/... | 10:46 |
| rogpeppe | jam: just thought i'd run the idea past you before we do the work | 10:46 |
| rogpeppe | jam: in fact, have you got a moment or two for a hangout? | 10:46 |
| jam | I can listen on a hangout, but I have a bit of a cough so I try not to talk too much. | 10:46 |
| rogpeppe | jam: ok, understood. https://plus.google.com/hangouts/_/canonical.com/gogogo?authuser=1 | 10:47 |
| rogpeppe | jam: or we can keep it here if you'd prefer | 10:47 |
| jam | joining, that way you can talk | 10:48 |
| fwereade | jam, rogpeppe, can't join you just now, will drop in when I can in case you're still there | 10:48 |
| fwereade | jam, rogpeppe: I presume you're not still there? conversations extended... | 11:41 |
| fwereade | jam, rogpeppe: would love to hear the high points | 11:41 |
| ashipika | fwereade: i can only try to recap | 11:44 |
| ashipika | fwereade: but the thing is that for the macaroon based login to work we need to persist macaroons and discharges in a cookiejar.. and to do that we placed the logic in the environCommandWrapper, which now has a Run method | 11:45 |
| ashipika | and that method loads the cookie jar, creates a httpbakery client and uses it to establish an API connection | 11:46 |
| ashipika | but now all commands need to be wrapped.. and test do not do that.. | 11:46 |
| ashipika | and that was the whole point of the debate.. whether to create a constructor for each command that would return a wrapped command and use wrapped commands in tests.. | 11:47 |
| ashipika | fwereade: ^ | 11:48 |
| fwereade | ashipika, my comfort level is proportional to how explicit we're being -- if all the commands are now constructed via funcs that accept explicit httpbakery clients -- so they can be tested by explicitly passing a mocked client -- then great | 11:52 |
| fwereade | ashipika, the more magic/globals/whatever is involved, the less I'll like it | 11:53 |
| rogpeppe | fwereade: it's no more magic that what's there already | 11:54 |
| rogpeppe | fwereade: we're putting the logic inside EnvCommandBase | 11:54 |
| * fwereade suddenly gets nervous because he can't remember how the magic is distributed ;p | 11:54 | |
| fwereade | rogpeppe, but I jest, that sounds like the right place for it | 11:55 |
| rogpeppe | fwereade: cool | 11:55 |
| perrito666 | ericsnow: ping me when you are back please | 12:10 |
| mup | Bug #1493850 opened: 1.22 cannot upgrade to 1.26-alpha1: run.socket: no such file or directory <1.22> <blocker> <ci> <regression> <run> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1493850> | 13:22 |
| mup | Bug #1493850 changed: 1.22 cannot upgrade to 1.26-alpha1: run.socket: no such file or directory <1.22> <blocker> <ci> <regression> <run> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1493850> | 13:25 |
| mup | Bug #1493850 opened: 1.22 cannot upgrade to 1.26-alpha1: run.socket: no such file or directory <1.22> <blocker> <ci> <regression> <run> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1493850> | 13:34 |
| natefinch | anyone else having trouble with the tests not passing on master? | 13:55 |
| ashipika | natefinch: go 1.5? | 13:56 |
| natefinch | ashipika: nope, running 1.2.2 like a good boy ;) | 13:56 |
| mgz | natefinch: the tests do not pass on master | 13:56 |
| natefinch | mgz: ok, good to know | 13:57 |
| natefinch | mgz: should I make bugs for the failing tests? | 13:57 |
| ashipika | natefinch: ack.. asking because there were some test failures with 1.5 | 13:57 |
| mgz | hm, one of the failing ones actually passed on a retest | 13:58 |
| mgz | natefinch: you should file bugs for any that CI does not have in the most recent run | 13:58 |
| frobware | dimitern, do you have time for a 5 minute HO, though probably more. :) | 14:22 |
| dimitern | frobware, sure :), i'll be in the standup HO in ~2m | 14:23 |
| mup | Bug #1493877 opened: TestImplicitRelationNoHooks fails intermittently <blocker> <ci> <intermittent-failure> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1493877> | 14:31 |
| === natefinch is now known as natefinch-afk | ||
| abentley | mgz: When you create an issue, remember to link the bug. | 14:35 |
| mgz | abentley: going back and doing it now | 14:37 |
| mup | Bug #1493887 opened: statusHistoryTestSuite teardown fails on windows <blocker> <ci> <regression> <test-failure> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1493887> | 14:46 |
| mup | Bug #1493887 changed: statusHistoryTestSuite teardown fails on windows <blocker> <ci> <regression> <test-failure> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1493887> | 14:49 |
| perrito666 | really? | 14:50 |
| mup | Bug #1493887 opened: statusHistoryTestSuite teardown fails on windows <blocker> <ci> <regression> <test-failure> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1493887> | 14:55 |
| mgz | mup likes rubbing it in. | 14:57 |
| mgz | I have done nothing but created the bug and subscribed ian, so how that comes out as three mup echos in channel I do not know | 14:58 |
| mgz | I am joining the standup ahngout now so I don't forget in 20 minutes | 15:07 |
| xwwt | jog: I am running a little late | 17:57 |
| jog | np... just ping me when you're ready | 17:58 |
| cmars | cherylj, i've got a fix for LP:#1493887 to unblock master if you have a moment, http://reviews.vapour.ws/r/2617/ | 18:00 |
| mup | Bug #1493887: statusHistoryTestSuite teardown fails on windows <blocker> <ci> <regression> <test-failure> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1493887> | 18:00 |
| cmars | um, i mean for LP:#1493850 | 18:01 |
| mup | Bug #1493850: 1.22 cannot upgrade to 1.26-alpha1: run.socket: no such file or directory <1.22> <blocker> <ci> <regression> <run> <upgrade-juju> <juju-core:In Progress by cmars> <https://launchpad.net/bugs/1493850> | 18:01 |
| cmars | wrong bug.. | 18:01 |
| perrito666 | cmars: you can fix 1493887 if you want to, not going to complain | 18:01 |
| cmars | :) | 18:02 |
| xwwt | jog: kk. I just got done. Thought it would run longer. Heading to hangout now. | 18:02 |
| === natefinch-afk is now known as natefinch | ||
| mgz | cmars: hmm, I don't see how the updatestatus stuff affects that, which is the only resolver change in the regerssion window | 18:08 |
| mgz | cmars: however, worker/uniter/upgrade126.go does to complex things with the Installed flag | 18:14 |
| cmars | mgz, so the updatestatus stuff is weird too. the "unit not found" is actually a not found on the status for that unit, http://pastebin.ubuntu.com/12322016/ | 18:15 |
| mgz | that function really does read... | 18:18 |
| mgz | return statefile.Write(state) | 18:18 |
| mgz | return nil | 18:18 |
| mgz | huh. | 18:18 |
| cmars | mgz, definitely going to continue investigating, but this PR should at least alleviate the CI failures until we can get to the bottom of it. the install hook shouldn't fire after an upgrade. | 18:21 |
| perrito666 | mm, set status should definitely not blow because of not finding the unit | 18:21 |
| mgz | cmars: so, I guess I don't see the point of unblocking trunk when we have problems with the uniter we don't understand yet | 18:24 |
| mgz | not to mention new test failures. | 18:25 |
| mgz | it might be interesting to rerun the test with your branch | 18:25 |
| mgz | but why do we want to add more code on top of a state we already know is broken? | 18:25 |
| mgz | cmars: my best theory at present is the AddInstalledToUniterState upgrade step is just wrong for the long hop, and the os-deployer failure is some other cause | 18:40 |
| mgz | so I probably should have filed that as a seperate bug | 18:41 |
| perrito666 | can I get some love in this? http://reviews.vapour.ws/r/2618/ | 18:50 |
| mgz | perrito666: test? | 18:51 |
| natefinch | fwereade: you around? | 19:44 |
| fwereade | natefinch, I am now | 20:00 |
| fwereade | natefinch, what can I do for you? | 20:01 |
| natefinch | fwereade: you talked to Wayne about AddService and making the AddUnit part of it into a worker, I'd like to get clarification on how you see that working | 20:01 |
| * fwereade scratches head furiously -- spot more context? | 20:02 | |
| fwereade | ah! | 20:02 |
| fwereade | natefinch, mitigating non-transactionality problems around deploy? | 20:02 |
| natefinch | fwereade: exactly | 20:03 |
| natefinch | fwereade: merging the setting of configuration on the service was trivial once I realized how to do it. But making the worker to add the unit(s).... just want to make sure I do it the right way. | 20:03 |
| fwereade | natefinch, ok, it needs a bit of investigation because I can't remember exactly what the difficult properties of assign-machine were | 20:03 |
| fwereade | natefinch, ah cool you've already done stuff | 20:03 |
| natefinch | fwereade: stuff has been done, yes :) | 20:04 |
| fwereade | natefinch, ok, let me think a sec to find the intersection of too-much-to-do and not-enough-to-accept | 20:04 |
| natefinch | fwereade: trying to figure out how I get the number of units etc from the Deploy function into the worker that presumably calls the API to add units (assuming the worker is not going to just use state directly, since we've been over that once or twice now ;) | 20:05 |
| fwereade | natefinch, so, there's sometimes deployment-related info that needs to be stored with the unit and carried through | 20:05 |
| fwereade | natefinch, :D | 20:05 |
| fwereade | natefinch, any placement directives, basically, which I *think* only apply when N=1 | 20:06 |
| natefinch | fmt.Errorf("cannot use --num-units with --to") | 20:07 |
| natefinch | seems that way :) | 20:07 |
| fwereade | natefinch, ok, cool | 20:07 |
| natefinch | fwereade: for reference: https://github.com/juju/juju/blob/master/juju/deploy.go#L44 | 20:07 |
| fwereade | natefinch, so, I *think* that what we should do is, for each unit we add, also add a document referencing the unit and any placement directives that apply | 20:10 |
| fwereade | natefinch, and write a watcher for that collection | 20:11 |
| fwereade | natefinch, that I *think* might want very similar characteristics to the queued-action watcher | 20:12 |
| fwereade | natefinch, although I need to come back to that | 20:12 |
| natefinch | fwereade: that seems sensible. So, in the same transaction that creates the service, we create docs for adding units... how do we ensure we don't have two workers creating the same unit? | 20:14 |
| fwereade | natefinch, ah, sorry | 20:14 |
| fwereade | natefinch, I didn't read properly | 20:14 |
| fwereade | natefinch, I *think* that adding the units is relatively doable in a single transaction | 20:15 |
| fwereade | natefinch, the bit that I really want to farm out to another worker is the machine assignment | 20:15 |
| fwereade | natefinch, so, iirc | 20:15 |
| natefinch | ahh ok | 20:15 |
| fwereade | natefinch, internally a deploy becomes add-service, add-unit, assign-unit, add-unit-assign-unit, ... | 20:16 |
| fwereade | and each of those is transactional | 20:16 |
| fwereade | natefinch, so we can fail between any one of those steps, and potentially get too few units and/or one unassigned unit | 20:16 |
| natefinch | fwereade: that was going to be my concern. That's part of the bug that we wanted to fix | 20:17 |
| fwereade | natefinch, so, I forget exactly why, but I have a firm conviction that it's the assignment that really messes with the transactionality | 20:17 |
| natefinch | the bug, for reference: https://bugs.launchpad.net/juju-core/+bug/1486553 | 20:17 |
| mup | Bug #1486553: i/o timeout errors can cause non-atomic service deploys <cisco> <landscape> <juju-core:Triaged> <juju-core 1.25:In Progress by natefinch> <https://launchpad.net/bugs/1486553> | 20:17 |
| fwereade | natefinch, often it creates new machines, often it causes the state server to chat to the provider about the plausibility of certain requests, it consumes machine sequence ids | 20:18 |
| fwereade | natefinch, but I think we can make add-service-and-N-units a transaction with *relative* ease | 20:19 |
| fwereade | natefinch, it's not quite just a matter of appending all the ops together -- the addUnitOps shouldn't assert anything about the service, and the service doc should get its unit refcount set to N immediately | 20:19 |
| fwereade | natefinch, but nor should it involve understanding and refactoring every part of state | 20:20 |
| natefinch | fwereade: glad to hear it :) | 20:20 |
| fwereade | natefinch, but for that to be useful, we also need the worker to handle the now-deferred assignments | 20:20 |
| fwereade | natefinch, I would prefer not to overload the unit doc any more, hence my preference for a fresh collection to store the assignment queue | 20:21 |
| fwereade | natefinch, each element of which I think is just unit-id + placement-directive | 20:21 |
| fwereade | natefinch, so that'd be the other change to the add-service transaction: add those docs | 20:22 |
| natefinch | sounds right | 20:22 |
| fwereade | natefinch, for each unit, I think the assignment-queue doc should be added *after* it in the []txn.Op (so that when the assignment watch triggers, we can be sure there's a document to go look at) | 20:24 |
| natefinch | noted. Good idea. | 20:24 |
| fwereade | natefinch, so, if we have a watcher for assignments, we can expose that over the api, via a new facade, to a new worker | 20:25 |
| fwereade | natefinch, that basically just does batch calls back up to "run all the assignments you just told me about" | 20:26 |
| fwereade | natefinch, and if the consequent *assignment* txn(s) were to just unconditionally delete the appropriate assignment docs | 20:26 |
| fwereade | natefinch, I think we'd cover most of the cases? | 20:27 |
| fwereade | natefinch, removeUnitOps should also unconditionally remove associated assignments, I think | 20:28 |
| fwereade | natefinch, we should be guaranteed to hit one or the other code path | 20:28 |
| natefinch | ok | 20:28 |
| fwereade | natefinch, and hitting both won't hurt | 20:28 |
| natefinch | yep | 20:28 |
| natefinch | fwereade: I gotta run in a minute, but I think I have enough to get started. Will you be on tomorrow? | 20:29 |
| fwereade | natefinch, yeah, absolutely | 20:29 |
| natefinch | fwereade: great, thanks for the clarification. | 20:29 |
| fwereade | natefinch, ping me when you come on and make me talk about the queued-action watcher and why it's good/bad and should be copied/not | 20:29 |
| natefinch | fwereade: heh, will do | 20:29 |
| fwereade | natefinch, hopefully I will have made up my mind by then :) | 20:29 |
| natefinch | fwereade: cool | 20:30 |
| natefinch | fwereade: see ya. | 20:30 |
| fwereade | natefinch, o/ | 20:30 |
| === natefinch is now known as natefinch-afk | ||
| lazyPower | fwereade: have a moment? | 20:46 |
| fwereade | lazyPower, sure | 20:46 |
| lazyPower | awesome, see: pm | 20:48 |
| mup | Bug #1494002 opened: azure deployment failure with mem constraints <juju-core:New> <https://launchpad.net/bugs/1494002> | 21:05 |
| wallyworld | thumper: i've made another change to that pr, but sadly test -race is broken in go 1.5 so i can't check that; bug 1487010 | 21:07 |
| mup | Bug #1487010: go1.5rc1: go test -race failing when building test exec on wily <golang (Ubuntu):In Progress by mwhudson> <https://launchpad.net/bugs/1487010> | 21:07 |
| mup | Bug #1494002 changed: azure deployment failure with mem constraints <juju-core:New> <https://launchpad.net/bugs/1494002> | 21:08 |
| mgz | wallyworld: does that also fix bug 1493877 | 21:10 |
| mup | Bug #1493877: TestImplicitRelationNoHooks fails intermittently <blocker> <ci> <intermittent-failure> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1493877> | 21:10 |
| wallyworld | mgz: should do, i think that bug would be a dup | 21:11 |
| wallyworld | of bug 1493623 | 21:11 |
| mup | Bug #1493623: worker/uniter/relation: relationsSuite.TestCommitHook tests fail <juju-core:In Progress by wallyworld> <https://launchpad.net/bugs/1493623> | 21:11 |
| mgz | yup. | 21:12 |
| mup | Bug #1494002 opened: azure deployment failure with mem constraints <juju-core:New> <https://launchpad.net/bugs/1494002> | 21:14 |
| mup | Bug #1494002 changed: azure deployment failure with mem constraints <juju-core:New> <https://launchpad.net/bugs/1494002> | 21:17 |
| perrito666 | mgz: tests added | 21:23 |
| mgz | perrito666: I see some Debugf in the change? | 21:24 |
| thumper | davechen1y: now? | 21:28 |
| thumper | davechen1y: I'm back in the standup hangout | 21:29 |
| davechen1y | thumper: ok | 21:29 |
| mup | Bug #1494002 opened: azure deployment failure with mem constraints <juju-core:New> <https://launchpad.net/bugs/1494002> | 21:29 |
| perrito666 | do you?? | 21:31 |
| perrito666 | in the test | 21:31 |
| * perrito666 eyes RB suspiciously | 21:33 | |
| mgz | perrito666: in the actual code | 21:35 |
| mgz | "This is wrong IIIIIIIII" | 21:35 |
| mup | Bug #1493877 changed: TestImplicitRelationNoHooks fails intermittently <blocker> <ci> <intermittent-failure> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1493877> | 21:35 |
| perrito666 | it is, my editor playing dumb | 21:35 |
| perrito666 | mgz: fixed | 21:38 |
| thumper | alexisb: got a few minutes? | 21:56 |
| alexisb | thumper, I will in an hour or so | 21:57 |
| thumper | alexisb: can you pencil me in and ping when you're free? | 21:57 |
| alexisb | thumper, yep | 21:57 |
| thumper | ta | 21:57 |
| thumper | wallyworld: mwhudson is aware of the race issue with the packaged go 1.5 and is looking to fix it today | 21:57 |
| thumper | waigani: can chat when ready | 21:58 |
| wallyworld | thumper: ty. that that mean there will be a go 1.5.1 or something packaged? | 21:58 |
| waigani | thumper: cool, standup? | 21:58 |
| mwhudson | wallyworld: it's a packaging thing, not related to upstream version | 21:58 |
| wallyworld | ah ok | 21:58 |
| thumper | waigani: ok | 21:58 |
| mwhudson | and it won't get fixed today i expect, at least not in the distro | 21:59 |
| mwhudson | wallyworld, thumper: https://bugs.launchpad.net/ubuntu/+source/golang/+bug/1487010 | 21:59 |
| mup | Bug #1487010: go1.5rc1: go test -race failing when building test exec on wily <golang (Ubuntu):In Progress by mwhudson> <https://launchpad.net/bugs/1487010> | 21:59 |
| wallyworld | mwhudson: yeah, i found that bug when i googled the error :-) | 22:00 |
| ericsnow | wallyworld: katco mentioned that you have some thoughts on #1493503 | 22:05 |
| mup | Bug #1493503: wily 1.24 cannot bootstrap local-provider: 127.0.0.1:37017: getsockopt: connection refused <blocker> <ci> <local-provider> <regression> <wily> <juju-core:Invalid> <juju-core 1.24:In Progress by ericsnowcurrently> <https://launchpad.net/bugs/1493503> | 22:05 |
| katco | ericsnow: menno :) | 22:05 |
| wallyworld | ericsnow: in a meeting, will look in a bit | 22:05 |
| ericsnow | katco: right, menno not wallyworld :) | 22:05 |
| alexisb | ericsnow, that is menn0 | 22:05 |
| perrito666 | ericsnow: hey, did you propose the fix for the agent version issue for master? | 22:12 |
| ericsnow | perrito666: you mean https://github.com/juju/juju/pull/3234? | 22:12 |
| ericsnow | perrito666: master has been blocked so I've had to wait (missed it by 30 minutes) | 22:12 |
| perrito666 | ericsnow: nop, not that one | 22:13 |
| perrito666 | the one I reviewed yesterday | 22:13 |
| perrito666 | but for master :) | 22:13 |
| ericsnow | perrito666: I landed that one in both | 22:13 |
| perrito666 | ericsnow: neat (I just noticed that thre breaking change for that landed today or lastnight) | 22:14 |
| * perrito666 is running a juju with mongo 2.6 | 22:39 | |
| alexisb | thumper, ping | 22:46 |
| alexisb | I am free, I will join our 1x1 hangout | 22:46 |
| thumper | alexisb: hey | 22:46 |
| thumper | k | 22:46 |
| cmars | wallyworld, workaround for LP:#1493850 ready for a review, http://reviews.vapour.ws/r/2620/ | 23:00 |
| mup | Bug #1493850: 1.22 cannot upgrade to 1.26-alpha1: run.socket: no such file or directory <1.22> <blocker> <ci> <regression> <run> <upgrade-juju> <juju-core:In Progress by cmars> <https://launchpad.net/bugs/1493850> | 23:00 |
| wallyworld | looking | 23:00 |
| wallyworld | cmars: let me know if the export_test comment is unclear | 23:09 |
| === sinzui_ is now known as sinzui | ||
| alexisb | waigani, ping | 23:40 |
| alexisb | waigani, it looks like you have committed a fix for this bug : https://bugs.launchpad.net/juju-core/+bug/1464679 | 23:41 |
| mup | Bug #1464679: juju status oneline format missing info <landscape> <status> <ui> <juju-core:In Progress by waigani> <https://launchpad.net/bugs/1464679> | 23:41 |
| alexisb | can you please confirm and update the bug | 23:41 |
| waigani | alexisb: looking | 23:42 |
| wallyworld | thumper: we have discovered 2 upgrade steps that were written to be run by a unit agent but only machine agents run upgrade steps. so these so called unit upgrade steps are never run. huzar | 23:45 |
| waigani | alexisb: sorry, lp wasn't loading. yep, fix merged. Updated bug. | 23:45 |
| alexisb | waigani, you rock thank you! | 23:45 |
| moqq | if i have an agent stuck with agent-status: executing (“running action update”), even though the update hook it was running has been killed/died, how can i “reset” it? | 23:57 |
| moqq | i tried to remove-unit and it added “life: dying” but it’s still stuck on executing | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!