| thumper | hi davecheney | 00:21 |
|---|---|---|
| thumper | laptop is still upgrading, but I am around | 00:21 |
| thumper | and have skype available to me | 00:21 |
| === wedgwood is now known as wedgwood_away | ||
| davecheney | thumper: you said you had a race when X was starting | 00:24 |
| davecheney | I think my machine has developed that as well | 00:25 |
| thumper | what do you get? | 00:25 |
| davecheney | bootup | 00:25 |
| davecheney | some text on the screen | 00:25 |
| davecheney | have to alt-f1 and restart lightdm to get a login | 00:25 |
| * thumper nods | 00:25 | |
| thumper | that's it | 00:25 |
| davecheney | wonderful | 00:25 |
| thumper | do you have an ssd? | 00:25 |
| davecheney | yeah | 00:25 |
| davecheney | wasn't a problem with 4gb | 00:26 |
| davecheney | but with 8gb | 00:26 |
| davecheney | i must be slightlt faster | 00:26 |
| thumper | ah... I have 16 | 00:26 |
| davecheney | is there a bug that I can whine on ? | 00:26 |
| thumper | damn those high spec laptops | 00:26 |
| thumper | davecheney: poke robert_ancell in #ubuntu-desktop | 00:26 |
| davecheney | thumper: ok, can I say you told me to talk to him ? | 00:26 |
| thumper | sure | 00:27 |
| davecheney | kk | 00:27 |
| davecheney | thumper: i flashed my n7 to the phablet this morning | 00:28 |
| davecheney | that is why I was calling | 00:28 |
| thumper | oh? | 00:28 |
| davecheney | i wanted to get your feedback on it | 00:28 |
| thumper | I have some thoughts | 00:28 |
| thumper | but I haven't played with the tablet build | 00:28 |
| davecheney | lets try skype | 00:28 |
| thumper | kk | 00:28 |
| davecheney | hello | 00:59 |
| davecheney | i am still here | 00:59 |
| davecheney | i can hear you | 00:59 |
| davecheney | you cannot hear me | 00:59 |
| thumper | no | 00:59 |
| thumper | did you bump mute? | 00:59 |
| davecheney | this is becoming farcical | 00:59 |
| davecheney | lets call it a day | 00:59 |
| thumper | ok | 01:00 |
| thumper | I'm tempted to throw in the towel completely and get a beer | 01:00 |
| davecheney | ok, lets retire hurt to our respective corners | 01:00 |
| davecheney | nearly time for lunch in AU | 01:00 |
| thumper | heh | 01:00 |
| davecheney | i shall continue to watch you troll #ubunut-desktop | 01:01 |
| === _thumper_ is now known as thumper | ||
| === _thumper_ is now known as thumper | ||
| === thumper is now known as thumper-afk | ||
| davecheney | thumper-afk: i'm going to be working remotely from the city for the rest of the day | 02:05 |
| davecheney | meeting up with a bloke who is over here from Zurich | 02:05 |
| davecheney | if there is wifi in their offices, i'll be online | 02:05 |
| davecheney | if not, i won't | 02:05 |
| davecheney | i'll be online tomorrow for the usual release hoopla | 02:05 |
| thumper-afk | ok | 02:11 |
| === thumper-afk is now known as thumper | ||
| thumper | davecheney: have fun | 02:12 |
| thumper | poos | 02:54 |
| jtv | Anybody available to review some Makefile changes in pyjuju? MP is at https://code.launchpad.net/~jtv/juju/makefile-fixups/+merge/149907 | 04:16 |
| jtv | Thanks wallyworld_! | 06:16 |
| jtv | Your review seems to count as "(community)" for some reason. | 06:17 |
| jtv | Nobody else who can review https://code.launchpad.net/~jtv/juju/makefile-fixups/+merge/149907 ? | 07:02 |
| jtv | Also, nobody who knows how to get the test suite passing, or at least not hanging? | 07:08 |
| wallyworld_ | jtv: which test suite? py juju or go juju? | 07:33 |
| jtv | wallyworld_: py juju | 07:41 |
| wallyworld_ | i've not run those tests, only the juju-core ones | 07:42 |
| jtv | At least on Precise & Quantal, we get test errors and then things just lock up (and ctrl-C won't work). | 07:42 |
| wallyworld_ | that's not good :-( | 07:43 |
| wallyworld_ | with your review, mgz should be able to do it when he comes online | 07:43 |
| jtv | Our thoughts precisely. | 07:43 |
| fwereade | frankban, heyhey -- I presume the lxc compile got you unblocked for now? | 09:10 |
| fwereade | frankban, the bug remains somewhat rough but is at https://bugs.launchpad.net/juju-core/+bug/1131608 | 09:12 |
| _mup_ | Bug #1131608: deployed series is arbitrary <juju-core:New for fwereade> < https://launchpad.net/bugs/1131608 > | 09:12 |
| frankban | fwereade: hi, I switched to another, more urgent, card. I've seen the bug you filed, thank you. lxc should workaround that issue | 09:12 |
| frankban | fwereade: how many reviews are required for juju-core? and does "LGTM with changes" means we can just follow suggestions and the "lbox submit"? it's re https://codereview.appspot.com/7398044 | 09:15 |
| frankban | s/and the/and then/ | 09:15 |
| mgz | jtv: you want test suite run on that branch? | 09:17 |
| fwereade | frankban, please wait for two of those without dissenting opinions | 09:18 |
| frankban | fwereade: ack, thanks | 09:19 |
| fwereade | frankban, the second of which has just arrived, LGTM | 09:19 |
| frankban | fwereade: :-) great! | 09:19 |
| frankban | fwereade: submitted | 09:39 |
| fwereade | frankban, cheers | 09:43 |
| fwereade | dimitern, heyhey | 09:43 |
| dimitern | fwereade: hiya | 09:43 |
| dimitern | fwereade: I have 2 CLs for you :) | 09:54 |
| fwereade | dimitern, cool | 09:54 |
| dimitern | fwereade: https://codereview.appspot.com/7373046/ and https://codereview.appspot.com/7385049/ (WIP still, tests fail and I'm not sure what i'm doing wrong) | 09:55 |
| fwereade | dimitern, I have one too I'm about to push, then I need to finish up TheMue's (hmm, he has one that you could look at too) | 09:55 |
| dimitern | fwereade: I'll take a look | 09:55 |
| TheMue | fwereade: Thx for the +1 btw. Even if I'm after our talk yesterday not sure if we really should use it. | 09:59 |
| fwereade | TheMue, we've already paid for it, and there's no compelling reason not to use it IMO | 10:00 |
| TheMue | fwereade: Yeah, that's reasonable. | 10:01 |
| fwereade | TheMue, I hope we will be able to swap it out before too long, but I don't think it's a serious enough issue to be worth blocking on | 10:01 |
| fwereade | TheMue, dimitern: https://codereview.appspot.com/7399049 | 10:04 |
| TheMue | fwereade: *click* | 10:04 |
| dimitern | fwereade: on it, as soon as i finish with TheMue's | 10:04 |
| fwereade | TheMue, storage LGTM | 10:09 |
| TheMue | fwereade: Thx | 10:10 |
| fwereade | dimitern, dude, tests ;p | 10:17 |
| fwereade | dimitern, but I have a suggestion that might make the first a bit simpler | 10:18 |
| TheMue | fwereade: You've got a review. | 10:18 |
| dimitern | fwereade: that's what I was asking about yesterday before it was too late i guess | 10:18 |
| fwereade | dimitern, if we add an explicit WantAllRelationsEvents method to filter, that directly restarts relationsw, I think that maybe everything is easier to express | 10:19 |
| dimitern | fwereade: not sure how to check if the watcher is restarted (or better still, how to check if we handle the changes before/after the upgrade) | 10:19 |
| fwereade | dimitern, sorry, I must have been very unclear, I thought I was handwaving at the existing ones in a helpful way :) | 10:19 |
| dimitern | fwereade: :) still at a loss though.. how to inject a change in the chan and check i get it after the restart of the watcher | 10:21 |
| fwereade | dimitern, start a filter; add a couple of relations; check you get events for them; receive an upgrade event (or call WanttAllRelationsEvents or whatever we do); check we get the same relations again | 10:21 |
| fwereade | dimitern, I'm not sure what we need to inject | 10:21 |
| fwereade | dimitern, at the moment it's written so that when someone reads an upgrade event the magic happens; so, to test it, read an upgrade event and check the magic | 10:22 |
| dimitern | fwereade: aah - so we'll still get the same changes before/after restarting | 10:22 |
| fwereade | dimitern, I would favour decoupling the magic, though, so you can just tack a trivial WantAllRelationsEvents on | 10:22 |
| fwereade | dimitern, yeah, I think that's enough | 10:22 |
| dimitern | fwereade: ok, i'll look into it some more before bugging you :) | 10:22 |
| fwereade | dimitern, sure, but I am always happy to be bugged :) | 10:23 |
| fwereade | dimitern, I *think* the second one has failing tests because you do the wrong thing when handling events from relationsw... consider what happens when the chan is *not* closed | 10:24 |
| dimitern | fwereade: hmm.. I wasn't sure I'm handling the "does this rel implement the endpoint of the charm of this service" right | 10:25 |
| dimitern | TheMue: reviewed | 10:26 |
| TheMue | dimitern: Thx | 10:27 |
| dimitern | fwereade: reviewed yours | 10:31 |
| fwereade | dimitern, TheMue: thanks for the reviews | 10:33 |
| TheMue | fwereade: yw | 10:33 |
| fwereade | dimitern, "series" is a fundamental concept in juju that it seems like we didn't really bother to implement | 10:33 |
| fwereade | dimitern, charms are specific to series: they are tuned to run on particular operating systems | 10:33 |
| fwereade | dimitern, we are meant to guarantee that we run (say) precise charms on precise systems, and quantal charms on quantal systems | 10:34 |
| fwereade | dimitern, in practice, not so much | 10:34 |
| dimitern | I've never been called "Dear Constituent" before :D | 10:35 |
| fwereade | dimitern, our current approach is "force everything to run on the same arch/series as the provisioner" | 10:35 |
| fwereade | dimitern, I am not especially pleased by this discovery ;) | 10:35 |
| dimitern | fwereade: ok, got it, 10x :) | 10:36 |
| fwereade | dimitern, np, dear constituent | 10:36 |
| dimitern | fwereade: :) i got one of the junk election papers just now, before I threw it away I saw that | 10:37 |
| dimitern | fwereade: so, instead of restarting the watcher on outUpgrade <-, implement and call WantAllRelationsEvents as needed (not there) ? | 10:41 |
| fwereade | dimitern, yeah, I think so | 10:46 |
| fwereade | dimitern, use a want channel as we do for the other control methods | 10:46 |
| dimitern | fwereade: but still keep the restarting when x, ok <-Changes; !ok, right? | 10:46 |
| fwereade | dimitern, nah, just do the stop/start in response to the want channel I think -- you can keep the MustErr | 10:47 |
| dimitern | fwereade: ok | 10:47 |
| dimitern | fwereade: am I getting this right: (assuming WantAllRelationsEvents and wantAllRelations chan), when we get <-f.wantAllRelations, we log and restart relationsw ? | 10:54 |
| fwereade | dimitern, yeah, I think that gets us what we need | 10:54 |
| fwereade | dimitern, then you can just tack a couple of extra lines onto TestRelationsEvents and you're good | 10:55 |
| dimitern | fwereade: so we still need the modified defer and don't want MustErr | 10:55 |
| fwereade | dimitern, hmm, I think we keep the modified defer | 10:55 |
| fwereade | dimitern, but I'm not so sure about MustErr | 10:55 |
| fwereade | dimitern, when will we see it? | 10:55 |
| dimitern | fwereade: but MustErr will fire once we stop relationsw | 10:56 |
| fwereade | dimitern, only if we don't start them again | 10:56 |
| dimitern | fwereade: ah, I'll try it | 10:56 |
| dimitern | fwereade: got it :) because the MustErr and the restart happen in the same select, they won't interfere | 11:01 |
| dimitern | fwereade: fixed https://codereview.appspot.com/7373046/ | 11:23 |
| fwereade | dimitern, lovely, LGTM | 11:25 |
| dimitern | fwereade: tyvm | 11:25 |
| dimitern | fwereade: so I need one more LGTM to submit it now..\ | 11:26 |
| fwereade | TheMue, dimitern's got an easy review up | 11:26 |
| TheMue | *click* | 11:35 |
| dimitern | fwereade: wrt the other CL - u.charm is the currently installed charm or the charm just deployed and about to have its relations added? | 11:41 |
| TheMue | dimitern: 2nd LGTM is in. | 11:41 |
| fwereade | dimitern, u.charm is a uniter/charm.GitDir, but it has a Path() you can use to construct an actual *corecharm.Dir to pass into ImplementedBy | 11:42 |
| dimitern | fwereade: but how is this charm different from u.unit.Service().Charm() ? | 11:43 |
| fwereade | dimitern, that's the state charm we'd be upgrading to, which definitely always implements those endpoints, otherwise the relation couldn't have been created in the first place | 11:44 |
| fwereade | dimitern, the charm a unit is running is not necessarily the same as the charm the service wants it to run ;) | 11:44 |
| dimitern | fwereade: ah, so the u.charm is not yet in state? | 11:44 |
| fwereade | dimitern, mu | 11:44 |
| fwereade | dimitern, g+? | 11:44 |
| dimitern | fwereade: ok, just a sec | 11:45 |
| fwereade | dimitern, starting one now | 11:45 |
| fwereade | dimitern, https://plus.google.com/hangouts/_/b4c971e8d459c1b323cf87a088c920c785acb054?authuser=0&hl=en | 11:45 |
| dimitern | TheMue: thanks for the review, btw - is your comment about proper capitalization of the comment? | 11:45 |
| TheMue | dimitern: That and punctuation, yes. ;) | 11:46 |
| dimitern | TheMue: cheers | 12:08 |
| dimitern | fwereade: moving the dir.Ensure into PrepareHook seems to cause problems with not finding the dir | 12:54 |
| fwereade | dimitern, what's looking for it? | 12:54 |
| dimitern | fwereade: i'm having trouble pasting the log | 12:55 |
| fwereade | dimitern, interpretive dance? ;p | 12:56 |
| dimitern | fwereade: :) just a sec | 12:56 |
| fwereade | dimitern, brb | 12:56 |
| dimitern | fwereade: http://pastebin.com/1XfyiMFk | 12:57 |
| dimitern | fwereade: both p.u.c and pb.c.c do not work | 12:57 |
| fwereade | dimitern, ok here now | 13:06 |
| dimitern | fwereade: did you see it? | 13:09 |
| dimitern | fwereade: i'm trying to figure out why it happens | 13:09 |
| fwereade | dimitern, it doesn't look all that bad -- just that it's not following the path it takes when called by the uniter, so we don't get the PrepareHook calls | 13:10 |
| fwereade | dimitern, I'd probably be fine with Ensure()ing the dirs directly in the test | 13:11 |
| dimitern | fwereade: that somehow seems wrong | 13:12 |
| dimitern | fwereade: maybe because the test is doing things out of sequence as a shortcut? | 13:13 |
| fwereade | dimitern, Relationer is a weird type, it's the nexus that connects all the various representations of relations | 13:13 |
| fwereade | dimitern, the only reason it's doing a Write there in the first place is so that the Validate on write works -- it's a hack to maintain correct dir state anyway afair | 13:14 |
| dimitern | fwereade: i see, ok then I'll add Ensure in these 3 failing tests | 13:15 |
| dimitern | fwereade: 2 simple fixes really - in assertHook and the one that checks Join creates the dir (no longer so) | 13:39 |
| fwereade | dimitern, great | 13:39 |
| fwereade | dimitern, tyvm | 13:39 |
| === wedgwood_away is now known as wedgwood | ||
| fwereade | dimitern, I guess you're somewhat familiar with the whole livetests gubbins? | 13:40 |
| dimitern | fwereade: somewhat yes | 13:40 |
| fwereade | dimitern, is there some magic happening re bootstrap in those tests? like, we're running them without bootstrapping, or something? this is ec2 in particular... | 13:40 |
| dimitern | fwereade: i think most of them do BootstrapOnce and go with it | 13:41 |
| dimitern | fwereade: anyone in particular you have in mind? | 13:41 |
| fwereade | dimitern, TestGlobalPorts looks like it doesn't bother | 13:42 |
| dimitern | fwereade: lemme see | 13:42 |
| fwereade | dimitern, there are 4 calls in total to BootstrapOnce AFAICS | 13:42 |
| fwereade | oh what the FUCK | 13:42 |
| fwereade | who wrote TestGlobalPorts? | 13:43 |
| dimitern | fwereade: no idea :) | 13:43 |
| * fwereade sighs dramatically | 13:43 | |
| dimitern | fwereade: it seems TestGlobalPorts is one of those which do not bother bootstrapping - just uses the config | 13:43 |
| * fwereade does not approve of writing tests that depend on obvious bugs | 13:43 | |
| dimitern | fwereade: +1 :) | 13:43 |
| fwereade | dimitern, ok, it looks like I can probably just make all the tests bootstrap | 13:44 |
| * fwereade remains baffled as to how a test against an environment that doesn't exist is meaningful | 13:44 | |
| dimitern | fwereade: not all, some of them test behaviour at or before bootstrap | 13:45 |
| fwereade | dimitern, yeah, just the ones that start instances | 13:45 |
| fwereade | dimitern, I'm trying to hack as little as possible here ;p | 13:45 |
| dimitern | fwereade: yeah, makes sense | 13:45 |
| dimitern | fwereade: try openstack's after | 13:45 |
| fwereade | dimitern, I would avoid it if I could, but I can't | 13:46 |
| fwereade | dimitern, I'm having to change Environ :/ | 13:46 |
| fwereade | dimitern, apart from machineId, Environ.StartInstance's params are -- I think -- total crack | 13:47 |
| dimitern | fwereade: which ones? | 13:47 |
| fwereade | dimitern, tools, api info, state info | 13:47 |
| fwereade | dimitern, the env should choose the tools | 13:47 |
| fwereade | dimitern, and it already knows -- or should -- the state/api info | 13:47 |
| fwereade | dimitern, Environ has a frickin' `StateInfo() (*state.Info, *api.Info, error)` method | 13:48 |
| dimitern | fwereade: yeah it does | 13:48 |
| dimitern | fwereade: hmm seems a bit crackful indeed | 13:49 |
| fwereade | dimitern, behold the fruits of detailed academic discussion: the perfect API | 13:50 |
| dimitern | :) | 13:51 |
| dimitern | fwereade: assuming i check relationer.Join does not create the dir, I should check also PrepareHook does it, right? | 13:56 |
| fwereade | dimitern, +1 | 13:56 |
| fwereade | dimitern, after validating please :) | 13:57 |
| dimitern | fwereade: the problem is I have no access to the actual path from the uniter module (it's in uniter/relation) | 13:57 |
| dimitern | fwereade: preparehook already validates | 13:57 |
| fwereade | dimitern, yep, I'm just saying create the dir after the validation | 13:57 |
| dimitern | fwereade: yeah, sure - done that | 13:58 |
| fwereade | dimitern, you know the relations dir, though, and you know the relation id, you can probably figure something out ;p | 13:58 |
| dimitern | fwereade: but i need a way to access the private path of statedir | 13:58 |
| fwereade | dimitern, you had to create a state dir with a known id in a known relations dir to begin with, though, right? | 13:59 |
| dimitern | fwereade: or add a method on statedir Exists() or something? | 13:59 |
| fwereade | dimitern, -1 unless you can think of a non-test use case for it | 13:59 |
| dimitern | fwereade: ah, you mean in the suite, sure i can export that to the suite | 14:00 |
| fwereade | dimitern, sgtm | 14:00 |
| niemeyer | Hi all | 14:13 |
| TheMue | niemeyer: Heyhey | 14:13 |
| dimitern | niemeyer: hey | 14:13 |
| niemeyer | TheMue, dimitern: Hey folks! | 14:23 |
| niemeyer | Huh.. so wikimedia runs a public ganglia server.. that's quite awesome | 14:24 |
| niemeyer | http://ganglia.wikimedia.org/ | 14:24 |
| dimitern | niemeyer: really cool :) you can see the whole infrastructure | 14:25 |
| dimitern | fwereade: a bit of help with uniter tests? not sure where to test the changes to updateRelations - it's in the modeAbideAliveLoop only, and I suppose the test has to go somewhere around "steady state changes" steps | 14:27 |
| fwereade | dimitern, hmm, that is an interesting one | 14:27 |
| dimitern | fwereade: maybe even in upgrade scenarios | 14:28 |
| fwereade | dimitern, for now, I think it is sufficient to check that the uniter does not respond to relations it can't handle | 14:29 |
| dimitern | fwereade: like: quickstart, createcharm, upgradecharm(to a different, faulty one), wait the log message for ignoring the non implemented relation | 14:29 |
| fwereade | dimitern, please, no log checking | 14:30 |
| dimitern | fwereade: ok, how then? | 14:30 |
| fwereade | dimitern, the fact that we indulged it out of desperation does not mean the bar for it should be lowered ;) | 14:30 |
| dimitern | fwereade: :) sure | 14:31 |
| fwereade | dimitern, but, yeah, it is a tricky question, and I am still thinking | 14:31 |
| dimitern | fwereade: we can check the relation is not added | 14:32 |
| dimitern | fwereade: like no relationer for that relation or something? | 14:32 |
| fwereade | dimitern, yeah, we certainly can check that the unit doesn't enter scope in that relation | 14:33 |
| fwereade | dimitern, and that's something we can do now | 14:33 |
| fwereade | dimitern, g+ quickly? | 14:33 |
| dimitern | fwereade: ok, i'll send you a link this time\ | 14:34 |
| fwereade | dimitern, cheers :) | 14:34 |
| dimitern | fwereade: https://plus.google.com/hangouts/_/b8e9e83fe6e47838019383106994c2dcca14363f?authuser=0&hl=en | 14:34 |
| dimitern | fwereade: in order to add the incompatible relation to the wp charm, i have to overwrite the metadata, right? | 15:46 |
| dimitern | fwereade: in createCharm{customize:..} | 15:47 |
| fwereade | dimitern, yeah, think so | 16:14 |
| fwereade | dimitern, sorry I missed you | 16:15 |
| fwereade | dimitern, did you do bootstrappy stuff in openstack? | 16:15 |
| dimitern | fwereade: I'm half way there already - will paste what I got | 16:15 |
| dimitern | fwereade: yes | 16:15 |
| fwereade | dimitern, do you know if there's any distinction between the CACert in the environ config and the (cert, key) passed into Bootstrap> | 16:16 |
| fwereade | dimitern, sorry, the *cert* passed into bootstrap | 16:16 |
| dimitern | fwereade: not really | 16:17 |
| fwereade | dimitern, ah, wait, I think there is | 16:17 |
| fwereade | dimitern, the ones passed in are generated from the one in the config | 16:18 |
| dimitern | fwereade: I mean I don't really know :) | 16:18 |
| fwereade | dimitern, indeed, sorry, just thinking out loud | 16:19 |
| dimitern | fwereade: does this look ok to you http://paste.ubuntu.com/5555566/ | 16:23 |
| dimitern | fwereade: it works, i did a small test | 16:24 |
| fwereade | dimitern, nice, much neater than I would have done it :) | 16:24 |
| dimitern | fwereade: :) ty | 16:25 |
| dimitern | fwereade: not sure if i should use only quickStart{} or quickStartRelation{} to setup the test case initial conditions | 16:29 |
| fwereade | dimitern, quickStart I think | 16:29 |
| fwereade | dimitern, you want your own funky relation setup using the service's new charm | 16:29 |
| dimitern | fwereade: and add relation later, immediately after upgradeCharm (or before) | 16:29 |
| fwereade | dimitern, immediately after | 16:30 |
| dimitern | fwereade: ok. the funky setup will happen after quickstart in createcharm{customized} | 16:30 |
| dimitern | fwereade: I need a charm running already ok, then try the upgrade | 16:31 |
| fwereade | dimitern, yeah; create, add, serve, service.SetCharm() | 16:31 |
| fwereade | dimitern, and immediately addRelation{} | 16:31 |
| dimitern | fwereade: yeah, that's it | 16:31 |
| fwereade | dimitern, in the hope that the scheduler happens to handle the relation change before it does the upgrade | 16:32 |
| dimitern | fwereade: yeah | 16:33 |
| dimitern | fwereade: in addition to renameRelation (instead of replace*), I'll need something to call ctx.svc.SetCharm | 16:34 |
| fwereade | dimitern, I'm sure that already exists, there are other upgrade tests | 16:34 |
| dimitern | fwereade: yeah, upgradeCharm{} does that in fact | 16:35 |
| fwereade | dimitern, cool -- and if you need to slice and dice the available primitives, go for it, they arenot meant to be set in stone | 16:35 |
| dimitern | fwereade: ok, although as I get to know more what each one does they're pretty comprehensive already | 16:36 |
| fwereade | dimitern, cool | 16:37 |
| arosales | gary_poster: is there a " Juju GUI user guide" that briefly explains how to work with the GUI (ie what yellow circles on a service in the canvase mean. How to deploy, relate, etc. ? | 16:50 |
| arosales | perhaps that is all pretty straight forward though | 16:51 |
| dimitern | fwereade: hmm.. how to wait for a hook which shouldn't happen? | 16:52 |
| fwereade | dimitern, waitHooks{} | 16:52 |
| fwereade | dimitern, :) | 16:52 |
| fwereade | dimitern, but... when do you need to do that? | 16:53 |
| dimitern | fwereade: this is a positive check, i think I need a negative one | 16:53 |
| dimitern | fwereade: http://paste.ubuntu.com/5555636/ that's the test case so far | 16:53 |
| fwereade | dimitern, I *think* you need a single positive check for the appropriate joined hook running, don't you? | 16:53 |
| dimitern | fwereade: and it fails with "never got expected hooks" | 16:54 |
| fwereade | dimitern, I think verifyRunning may have tripped you up -- don;t think you need that one | 16:54 |
| dimitern | fwereade: ah, waitHooks{} (empty) ensures no hooks run | 16:55 |
| fwereade | dimitern, what happens if you just check the one hook and verifyCharm{revision:2} immediately afterwards? | 16:55 |
| dimitern | fwereade: i'm trying this now | 16:56 |
| dimitern | fwereade: so the new charm is created with rev 2, and then upgradeCharm{rev 2} as well, verifyCharm{rev 2} at the end | 16:58 |
| fwereade | dimitern, +1 | 16:58 |
| fwereade | dimitern, hey, even better | 16:58 |
| dimitern | fwereade: still fails with never got expected hooks, this time only with: waitHooks{"db-relation-joined mysql/1 db:0"} | 16:59 |
| fwereade | dimitern, add some stuff to the db2-relation-joined hook created by the charm to write something unambiguous to the charm dir | 16:59 |
| fwereade | dimitern, interesting, what's the actual? | 16:59 |
| fwereade | dimitern, actually paste me the log please | 17:00 |
| dimitern | fwereade: aw fuck - it should be wait for db2, right? | 17:00 |
| fwereade | dimitern, lol yes | 17:00 |
| dimitern | :D | 17:00 |
| fwereade | dimitern, well spotted | 17:00 |
| dimitern | fwereade: running now | 17:00 |
| dimitern | fwereade: even if it passes, would it be enough? | 17:01 |
| dimitern | fwereade: i mean that scheduler cases.. | 17:01 |
| fwereade | dimitern, well, the trouble is, I don't see a way to goose the scheduler into jumping the wrong way even if I were convinced I could force that particular loop to be in that particular state at a particular time | 17:02 |
| fwereade | dimitern, I think the best we can do is write the test that has the best possible change of inducing the race | 17:03 |
| fwereade | dimitern, and maybe tweak the summary so it's clear that failures here are to be taken v seriously | 17:03 |
| dimitern | fwereade: it didn't pass, but now I see the db2-relation-joined happens in the log before | 17:04 |
| dimitern | fwereade: the trouble with fmt.Printf and log.Printf is they're out of sync | 17:04 |
| fwereade | dimitern, use c.Logf() in tests | 17:05 |
| dimitern | fwereade: yeah, just did | 17:05 |
| dimitern | fwereade: wanna see the log? | 17:05 |
| fwereade | dimitern, yeah, please | 17:05 |
| dimitern | fwereade: running cleanly one more time, just a sec | 17:06 |
| dimitern | fwereade: http://paste.ubuntu.com/5555673/ | 17:09 |
| dimitern | fwereade: i suspect something might be wrong here again: waitHooks{"db2-relation-joined mysql/1 db:0"}, | 17:11 |
| fwereade | dimitern, ah-ha | 17:11 |
| fwereade | dimitern, db2:0 | 17:11 |
| dimitern | :) yeah | 17:11 |
| dimitern | it's getting late and I'm getting sloppy | 17:11 |
| dimitern | sorry | 17:11 |
| fwereade | dimitern, sorry, createCharm is more subtle than I made clear | 17:12 |
| dimitern | fwereade: how? | 17:13 |
| fwereade | dimitern, actually not that | 17:14 |
| fwereade | dimitern, well kinda | 17:14 |
| fwereade | dimitern, it creates the hook files that dump to the log for detection later | 17:14 |
| fwereade | dimitern, they're still called db-relation-joined | 17:14 |
| dimitern | fwereade: aha! | 17:14 |
| dimitern | fwereade: so var goodHook2 or something inline in customize? | 17:15 |
| dimitern | fwereade: no, actually I just need to call writeHook again | 17:16 |
| fwereade | dimitern, can yu just call writeHook in cus... yeah :) | 17:16 |
| dimitern | :) | 17:16 |
| gary_poster | arosales there is not | 17:19 |
| dimitern | fwereade: to do that though, I have to change createCharm's customize to accept ctx *context instead of path string | 17:20 |
| fwereade | dimitern, sounds sane | 17:21 |
| arosales | gary_poster: ok, thanks | 17:21 |
| dimitern | fwereade: btw it would be nice to have some extra \n\n between each ut() case in the verbose log somehow :) | 17:26 |
| fwereade | dimitern, sorry, I should have said, ffs comment out the earlier tests when you're developing | 17:27 |
| fwereade | dimitern, while the steps are quite nice it really should not be a table-based test IMO | 17:27 |
| fwereade | dimitern, hindsight, eh | 17:27 |
| dimitern | fwereade: or at least a bit more granular perhaps, while still benefiting from tbt | 17:28 |
| dimitern | fwereade: [LOG] 6.56912 JUJU u/0 db2:0: UniterSuite-29 db2-relation-joined mysql/0 | 17:30 |
| * fwereade cheers | 17:31 | |
| dimitern | fwereade: this tells me that I should probably wait for "db2-relation-joined mysql/0 db2:0" | 17:31 |
| fwereade | dimitern, +1 | 17:31 |
| dimitern | fwereade: alright :) the logs now seem less cryptic indeed | 17:32 |
| fwereade | dimitern, cool :) | 17:32 |
| dimitern | fwereade: once I start understanding the state/watcher and collections stuff.. who knows :) | 17:32 |
| fwereade | dimitern, heh, I really ought to turn of the logspam in the watchers | 17:33 |
| dimitern | fwereade: still no cigar though | 17:35 |
| dimitern | fwereade: same error | 17:35 |
| fwereade | dimitern, bah | 17:35 |
| fwereade | dimitern, paste again maybe? | 17:35 |
| dimitern | fwereade: http://paste.ubuntu.com/5555744/ - tail of the log, and the test case http://paste.ubuntu.com/5555746/ | 17:36 |
| fwereade | dimitern, d'oh | 17:41 |
| fwereade | dimitern, wait for upgrade-charm and config-changed before the relation one | 17:41 |
| fwereade | dimitern, this makes the followup step redundant | 17:41 |
| dimitern | fwereade: aha | 17:41 |
| fwereade | dimitern, however it doesn't explain why the hook is apparantly not being found | 17:42 |
| fwereade | dimitern, it's clearly being run, but it's not showing up in the log | 17:42 |
| dimitern | fwereade: so 2 waitHooks in a row - there's also verifyWaiting but i think it's not related | 17:43 |
| dimitern | fwereade: :) this time the earlier waitHooks bailed with error | 17:46 |
| dimitern | fwereade: something's fishy here | 17:47 |
| dimitern | fwereade: because upgrade-charm and config-changed definitely happened | 17:47 |
| fwereade | dimitern, sorry, I'm confused | 17:47 |
| dimitern | fwereade: I added waitHooks{"upgrade-charm", "config-changed"}, before waitHooks("db2-relation-changed mysql/0 db2:0"}, and it failed on the first one | 17:48 |
| dimitern | fwereade: you know, i think it's best to leave it for now - i'll lbox propose -wip | 17:49 |
| dimitern | fwereade: and start fresh on monday | 17:50 |
| fwereade | dimitern, sgtm :) | 17:50 |
| dimitern | fwereade: thanks for all the help, really | 17:53 |
| dimitern | fwereade: learned a lot today :) | 17:53 |
| fwereade | dimitern, a pleasure :) | 17:53 |
| dimitern | i'm off then | 17:53 |
| dimitern | have a good evening and weekend everyone | 17:53 |
| TheMue | So, I'm off too. Have a nice weekend everyone. | 17:57 |
| fwereade | TheMue, hapy weekend | 17:57 |
| TheMue | fwereade: Thx, also for you. | 17:58 |
| TheMue | fwereade: Environ w/o Bootstrap looks good so far, Monday morning I'll add the tests. | 17:59 |
| fss | niemeyer: ping | 19:10 |
| niemeyer | fss: Hey | 19:10 |
| fss | niemeyer: can we get those iam patches merged? :-) | 19:12 |
| niemeyer | fss: Definitely | 19:12 |
| niemeyer | fss: It is in the queue, promisse | 19:12 |
| niemeyer | promise | 19:12 |
| fss | niemeyer: thanks | 19:12 |
| niemeyer | fss: It isn't the only thing, unfortunately, but it is there | 19:12 |
| fss | niemeyer: i'm just revisiting some code and noticed the github.com/fsouza/go-iam import path :-( | 19:13 |
| niemeyer | fss: AW | 19:14 |
| niemeyer | Aw, that is | 19:14 |
| niemeyer | :) | 19:14 |
| fss | niemeyer: regarding the queue, is there anything I could help? :-) | 19:23 |
| niemeyer | fss: Thanks for the offer, but I'm afraid not.. it's just stuff on my plate | 20:09 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!