[02:25] davechen1y: hey, as ocr, could you please look at https://codereview.appspot.com/10858043/ and https://codereview.appspot.com/10854043/. With the latter, thumper and I both would like to keep both assignment policies fwiw [02:28] wallyworld: /me looks [02:28] ty [02:34] wallyworld: i take no position on two policies or one [02:34] as you and thumper are the ones doing the work, i think you get final say [02:35] the rest is between you and your maker [02:35] ta [02:35] * thumper defers continued work, and goes back to land and fix [02:35] local provider pipeline is currently eight branches [02:36] although the last one is empty [02:36] time to bring that down a little. [02:36] a reason not to use iOS: https://twitter.com/satefan/status/354046461383688193 [02:37] * thumper wonders which trusted roots we have in ubuntu [02:37] about 150 at last count [02:37] holy shit [02:37] * thumper wonders how many are NSA plants [02:37] fucktonnes [02:38] heh [02:38] prety sure the china post office one is in there [02:38] haha [02:38] * thumper sighs [02:38] wow MITM attacks all round [02:50] https://code.launchpad.net/~thumper/juju-core/move-cert-gen-to-config/+merge/173117/comments/387671 ?!?! [02:54] out of disk space ? [03:01] dunno, awaiting jam [03:05] davechen1y: how do I find the OS that we are running on using go? [03:06] runtime.GOOS [03:06] runtime.GOARCH as well [03:15] ta [03:15] wallyworld: do we have existing storage smoke tests? [03:15] somewhere? [03:15] um. maybe in jujucore tests, or individually in each provider. can't recall [03:16] if there are some in jujucore tests, then perhaps none are explicitly needed [03:18] thumper: Testpersistence exists [03:18] i think your provider will be run with that test if you have plugged in the common env tests [03:19] wallyworld: where is that? [03:20] environs/jujutest/tests.go [03:22] davechen1y: thanks for the review [03:24] wallyworld: don't thank me, i didn't doa very good job [03:24] davechen1y: with the checkers import, the discussion about it happened after i made the code change [03:24] i left it as is so it could be changed all in one go [03:24] you gave a +1 which is what i needed to unblock, so it was a good job :-) [03:38] thumper: if policy is clean and/or empty and constraint is lxc, and no clean/empty container found, do you think it should create the required new container on an existing instance, or go to the trouble of creating a whole new instance to host the container? [03:40] wallyworld: that is an interesting question [03:40] and one i need to answer :-) [03:40] me thinks by default it should shive the new container on an existing instance [03:41] and we maybe provide a way to alter that behaviour [03:41] how would you tell it not to? [03:41] I think here we are hitting the limit of shit we should care about [03:41] yes [03:42] and that we should move from there into the world of letting the user decide with their custom deployment script [03:42] i think if the user wants a new instance, they should use that assignment pokicy [03:42] AssignNewMachine [03:42] if they use AssignClean(Empty), it will create a new container if required on an existing instance [03:43] perhaps we can have a max containers per instance setting? [03:43] that may make sense [03:43] or just rely on hardware characteristics to help us control it [03:43] can we defined the assignment policy as a deploy time constraint yet? [03:43] if when an instance is "full", don't add more to it [03:43] not yet. soon :-) [03:43] next branch i think [03:44] yeah, hardware characteristics I think [03:44] until we add magic++ [03:44] i do like the max containers idea though [03:44] we may want to limit it even if hardware allows it [03:44] s/we/users [03:46] thumper: wtf. got all these cannot find package errors from the go bot [03:47] wallyworld: me too [03:47] :-( [03:57] wallyworld: waiting for jam [03:57] yep. if he weren't online in a bit, i'd ssh in to have a look [03:57] might be a known issue perhaps === thumper is now known as thumper-afk [04:45] thumper-afk: fixed [04:45] wallyworld: Hopefully I fixed it. It looks like jujud stopped being able to talk to the master server, and when it came back online, it reinstalled the charm [04:46] ok, will try again, thanks [06:24] morning all! [07:14] jam: Hi, could you please update gwacl in the landing environment? (No backward-incompatible changes have landed.) === thumper-afk is now known as thumper [07:33] fwereade: ping [07:37] fwereade: I'm going to go organise dinner, will check back later === thumper is now known as thumper-afk === JoseAntonioR is now known as JoseeAntonioR [08:16] rvba: sorry about the delay, will do [08:16] jam: no worries, ta! [08:19] rvba: from r146 => r166 [08:19] jam: great, thanks again. [08:44] hey dimitern, I hope you enjoyed Euro Pycon [08:44] jam: hey, yeah it was useful and interesting [08:44] jam: and it would've been even better if I didn't try upgrading to saucy and bricked my laptop [08:45] jam: had to reinstall raring, and now what mongodb did I need to install - which ppa was it? [08:46] dimitern: I still use the tarball, but there is: https://launchpad.net/~juju/+archive/experimental [08:46] ouch on the Laptop. I'm a bit surprised. [08:46] The quality stuff has generally been a lot better for running beta [08:47] jam: thanks [08:47] dimitern: I have quite a few infrastruture-y patches related to API and consumers of the API. I'd be happy to get some feedback and go over them with you. [08:48] jam: well, it turned out I choose a really bad time to do it - there were problems with video drivers (i'm using the fglrx proprietary ones) and some mixup with proposed packages breaking unity [08:48] I'm hoping some of them will make new workers easier to bring up. [08:49] jam: cool, i'd like to know these [08:49] dimitern: yeah, I use proprietary drivers as well, If you don't need 3D then the "radeon" driver is often pretty stable. [08:49] jam: btw - I did add-apt-repository ppa:juju/experimental and now I install mongodb - will it get it from there? [08:50] dimitern: so probably the biggest change is doing a bit more standardizing on NotifyWatcher connected to the API, which can then use a api.NotifyWatcher on the client side, and a worker/NotifyWorker which is designed around workers that trigger based on that watcher. [08:50] jam: well the thing is - after the upgrade everything went black - even ttys ctrl+alt+f1 didn't respond [08:50] dimitern: for mongodb, you need to 'apt-get update' frist [08:50] first [08:50] so it sees the new PPA [08:50] then it should, provided the PPA is "newer" [08:50] dimitern: ouch [08:50] jam: ok [08:52] jam: i'm thinking of continuing with the deployer stuff - i didn't see progress on that [08:53] dimitern: We want to focus on getting one agent fully into the API, which deployer works for that. [08:53] I think deployer is NotifyWatcher based as well. [08:53] (old EntityWatcher) [08:53] dimitern: also, this is particularly trivial, and dfc has LGTM'd it on Launchpad: https://codereview.appspot.com/10871045/ [08:54] jam: yeah, probably, will take a look [08:54] dimitern: I realize william is in UK, but have you seen him around this morning? [08:55] I wanted to get fwereade's feedback on the basic design I've been doing, to see if it matches what he and I talked about. [08:55] jam, dimitern, heyhey [08:55] jam: no i haven't [08:55] fwereade: hey [08:55] fwereade: took the car for a ride on sunday btw :) [08:56] I'm going to restart IRC real quick, as notifications aren't working. bbiab [08:56] dimitern, cool, thanks [08:57] fwereade: I trust the wedding was beautiful and your weather is pleasant? [08:58] jam, it indeed was, and... yeah, the weather's still ok too :) that's nice [08:58] jam, sorry, hadn't looked [08:59] fwereade: so probably the big one as far as design goes is: https://codereview.appspot.com/10978043/ [08:59] which is creating a NotifyWorker structure [08:59] to match the NotifyWatcher [09:01] jam, cool, I'm just going through https://codereview.appspot.com/10939043/ now [09:01] fwereade: great. Certainly needed before the other one. [09:01] I did end up consuming the initial event in the API Server, and then triggering a local event in the client Watcher [09:02] jam: just reviewing it [09:02] jam: already seen the usage inside the cleaner and i lie it [09:04] TheMue: thanks. I'm quite happy with how it shaped up. [09:04] The workers had a lot of "interact with the system" logic tied up with "do my actual work", and I'm hoping this decouples it nicely. [09:10] fwereade: by the way, you still have https://code.launchpad.net/~fwereade/juju-core/errors-cleanup/+merge/168928 sitting around. Is it bitrotten/landed in trunk but not in "old trunk", ? [09:10] jam: so now (3.5h from now) is the combined blue+core standup, right? [09:10] jam, that branch is somewhat bitrotten I'm afraid :/ [09:11] dimitern: my clock says 2.5 hours [09:12] jam: oh, right, yes [09:15] mgz: also, just a quick status check on https://code.launchpad.net/~danilo/juju-core/python-env-fails/+merge/171997 [09:15] ISTR it was failing while running on the bot (lovely hangs causing 600+s timeouts. === thumper-afk is now known as thumper [09:23] jam: you've got a review for the 10978043 [09:25] TheMue: thanks [09:25] guys, i'm getting multiple test failures on trunk - http://paste.ubuntu.com/5854870/ [09:25] dimitern: have you updated gwacl? [09:26] i think it had work recently [09:26] thumper: yes, all of the 3rd parties [09:26] thumper: they just had me update it on the bot today, but the compat one was a while ago. [09:26] dimitern: "Bad record MAC" is what happens when you use a packaged mongo, IIRC. [09:27] You can try putting the tarball mongo in your path, and see if that fixes it. [09:27] i had to reinstall raring after a failed upgrade to saucy (but /home was unaffected), so I may still need some packages installed (I already installed what was obvious, like git, mongodb from the ppa) [09:27] dimitern: the env is already bootstrapped is a follow-on failure because the previous test didn't clean itself up. [09:28] jam: I did add the ppa, then update, then install mongodb, but it sill got the wrong one (the one in the archive is 2.2.4, which is newer than the ppa one - 2.2.3+ssl2) [09:28] ha it seems I didn't manage to uninstall the 2.2.4 mongo properly [09:29] how can I install the ppa version of mongo? it has the same name, different version [09:30] dimitern: there is some way to force it something like "apt-get install mongodb==2.2.3+ssl2" but I'm not 100% sure on that bit. [09:32] jam: hmm apt-get is too strict, I had to specify it as sudo apt-get install 'mongodb=1:2.2.3-0ubuntu2+ssl2' [09:32] fwereade: A Watch call returns the initial event.... Is a bit confusing when an event doesn't have any actual content. To *me* the fact that we are doing "out := w.out" in the loop means we are generating an event locally which wasn't explicitly sent from remote. [09:33] jam, I think the viewpoints are basically equivalent [09:33] jam, I see it as "empty event sent, nothing actually regenerated" [09:34] jam, but it's academic really [09:38] fwereade: you're right that it makes more sense on watchers that actually transmit content, as you would have a field and have to save the content for a while until someone polled for it. [09:39] (the Result object has to hold that state, which gets cached a bit on the client Watcher object until it can get rid of it with the out <- content statement. [09:39] jam, yeah, the only reason I'm pushing that viewpoint is to make the similarity clear [09:41] fwereade: I tweaked the comments. Now who can we get to follow up review it ? :) [09:41] jam, dimitern's back :) [09:41] dimitern: https://codereview.appspot.com/10939043/ looks more imposing than I think it really is. It moves some code around so that we can pull out Watcher [09:41] as an API object [09:43] jam: will look once I resolve my issue with mongo - it seems the ppa doesn't have amd64 deb for raring (only - other series have both i386 and am64 available) - there is an option to retry the build on LP, but it says it'll destroy history etc. - should I do it? wish davecheney was around to ask [09:46] dimitern: go ahead and retry, it kills the failure log, etc. But since it failed to build, I think we can just retryi it. [09:46] nobody is actively debugging the failure [09:46] it is claimed it was "Cancelled Build" [09:46] dimitern: it is a bit concerning that it took "Finished on 2013-04-19 (took 2 days, 13 hours, 40 minutes, 24.0 seconds)" [09:46] jam: scheduled for retry in 16 minutes [09:46] and was cancelled. [09:46] so there may be an explicit problem with that build [09:47] jam: probably wasn't "finished" but canceled instead [09:48] dimitern: right. I just mean it sat in the building state for 2 days before someone had to manually notice and cancell it. [09:48] We should try to keep an eye on it. [09:48] jam: yeah [09:48] jam: will look at your branch now, while waiting [09:49] jam: ah, it's william's actually [09:49] jam: ah, no - the sidebar or rietveld is confusing sometimes [10:07] jam: reviewed [10:17] TheMue: fwereade: I've responded to both of your feedback on https://codereview.appspot.com/10978043/ [10:18] jam: i'll take a look at that as well [10:18] (while still waiting for the mongodb build) [10:19] fwereade: for 'tools' package. I would be fine calling the top level thing 'agent'. The key bits I care about are: [10:19] a) it is environ agnostic [10:19] b) it hides more of the details from callers, so they don't have to track something like 'dataDir'. [10:20] dimitern: to quote William, "EnvironConfigWatcher should never have been implemented" [10:20] it exposes too many secrets [10:20] that shouldn't be exposed in the API [10:20] things might to think about stuff that is *in* the environ config [10:20] but they shouldn't get the whole thing out. (AIUI) [10:21] jam: ah, i see [10:24] jam, responded [10:24] jam, and I'm +1 on your (a) and (b), I absolutely think it's a good change [10:25] jam, just quibbling about package placement [10:25] jam, dimitern: so, on thursday I tried about 3 times to impose some consistency on the params package and every time it felt like it was running away with me [10:26] fwereade: :) [10:27] jam, dimitern: but I'm going to try again today [10:27] fwereade: +1 [10:27] jam, dimitern: and if it ends up a huge ugly conflicty change I can at least get it in front of you for sanity checking [10:27] fwereade: sgtm [10:28] jam, dimitern: and if I do it ~right then I hope we'll be able to share stuff like the underlying code for machiner.Life and deployer.Life (and for more facades in the future) [10:29] dimitern, since you weren't there, one important bit I thought I should run by you is... [10:29] dimitern, ...implementing the API in terms of Tag where possible rather than name/id/whatever's relevant to the particular entity [10:30] dimitern, is there anything obviously stupid about that? [10:31] fwereade: well, it has advantages, but the main thing is we'll need to slightly modify the code that uses the api to accomodate that - not terribly high a price though [10:31] dimitern, there's enough dancing back and forth between id and tag in jujud already that I think it might work out a win in the end [10:32] dimitern, it's more crap over the wire that we don't really need though [10:32] fwereade: and it's still not too late to impose this api-wide change i think [10:32] dimitern, yeah, and there STM to be a bunch of things api-wide that don't really look consistent, and I'd like to force a bit of that before we fossilize [10:33] fwereade: sounds good [10:33] fwereade: what happened with the magical bulk ops at the rpc layer? [10:34] dimitern, when rog proposed those I rejected them because it forced domain-object-style at the rpc layer [10:34] fwereade: are we still doing the bulk ops as originally agreed: array-of-structs as args, arrays-of-structs as results (incl. errors and results at the same place)? [10:34] dimitern, yes, I think so [10:34] dimitern, haven't seen any controversy there [10:35] fwereade: cool! [10:38] fwereade: well I'm on board with it, and rogpeppe is on vacation :) [10:38] fwereade, dimitern: I would clarify that it is a struct-of-array-of-structs as args and struct-of-array-of-structs as results. [10:38] So it is ApiFunction(args params.Type) (params.ResultType, error) [10:38] not [10:39] jam: yes [10:39] ApiFunction(args []params.Type) ([]params.ResultType, error) [10:39] jam: of course [10:39] dimitern: well, there have been times when wrapping the array in a struct seemed silly [10:39] but fwereade and I discussed it and it does make sense. [10:39] Since it gives us nice wiggle room if we want to extend the api at all. [10:42] jam: and in addition, the rpc layer supports that only - you cannot have (args []type) as it is now [10:43] jam: please wait for my review before landing https://codereview.appspot.com/10978043/ [10:44] * fwereade bbiab [10:46] dimitern: I responded to https://codereview.appspot.com/10939043/ [10:46] I'll do fwereade's requests and then wait for your review. [10:46] jam: cheers! [10:51] jam: reviewed [10:57] Reviewers needed, hopefully for a "trivial" vote: https://codereview.appspot.com/10858049 [10:57] jtv: looking [10:57] thanks [10:58] jtv: LGTM, trivial [10:58] jtv: make simplify does that? seems pretty smart :) [11:03] Thanks dimitern, for your vote and your compliment. :) [11:03] It's not particularly smart, but it does free you from the distraction. [11:04] jtv: i might give it a go [11:04] Do it regularly. :) It won't find much, but that makes it all the easier. [11:04] jtv: are you familiar with lp-propose and lp-submit aaron did? [11:04] Or "make format" for a regular formatting run. We may choose to integrate them. [11:04] Yes, I used to use those... but it's been a while. [11:05] jtv: there was a talk in oakland that these two now support rietveld as well, so can be used instead of lbox [11:05] jtv: which i'd acclaim [11:05] A step in the right direction, yes... It may save us some work on the Tarmac integration. [11:06] Also, I haven't seen those bzr plugins ignore errors like I have lbox. :) [11:06] jtv: exactly, and better integration with LP [11:07] fwereade, dimitern: Is this actually better? https://codereview.appspot.com/10858049/patch/1/1003 [11:07] double nesting of brackets tends to be more confusing for me. [11:08] I guess it is more apparent when they are on separate lines. [11:08] jam: i think so yes - no need to repeat the type when the slice has it explicitly anyway [11:10] jam, yeah, +1 [11:11] dimitern: responded [11:12] I think that means enough LGTMs for both api-watchers and notify-worker to land [11:14] jam: thanks [11:16] mongodb in the ppa for raring/amd64 built successfully [11:17] dimitern: nice... now will it pass the test suite. [11:17] jam: hopefully - trying now :) [11:20] dimitern: standup in 10 min, just in case the clock sync wasn't working. [11:21] jam: yep, will be there - hangout from the link in the calendar, right? [11:21] yep [11:21] making a coffee myself, should be there on time, thougd. [11:21] though [11:27] fwereade: re: "tools" as a package. I'm happy to have the ToolsManager as an interface in an agent package. The big concern is having it outside of "environs/". Do you feel it is better just to move environs/agent to a top level package? [11:27] jam, +100 [11:27] fwereade: also, now that my queue has been flushed, I'm reminded of the patch I'm having trouble with. [11:27] jam, oh yes? [11:27] specifically, trying to test the client side of an Upgrader.WatchAPIVersion() [11:28] afaict, I'm setting up the test identically to the one on the server-side of the api, and the state side [11:28] but afaict the lowest level watcher isn't firing [11:28] (the one with the actual watch on the DB) [11:28] jam, is it possible you're using a different *state.State, and so not seeing the effect of a sync? [11:28] jam, what if you set the timeout to 6s? [11:33] mgz: poke [11:35] fwereade: I thought JujuConnSuite shares the state [11:35] between the two sides [11:35] I'll have to look into that [11:35] because yes, after 5s the test passes. [11:36] mgz: In case you're just not seeing it: https://plus.google.com/hangouts/_/f497381ca4d154890227b3b35a85a985b894b471 [11:59] mramm: ping [12:04] TheMue: pong [12:06] i think this might be an actual bug: http://paste.ubuntu.com/5855203/ (i updated goamz and there were changes) [12:06] mramm: Germanys interest in Juju grows. I've been asked if I want to talk at the http://webtechcon.de (German) about Juju [12:07] mramm: and maybe also write about it in one of the magazines of the publisher behind this conference [12:07] installed mongo 2.2.0 from the tarball, as specified in the readme and all other tests pass [12:07] cool [12:07] TheMue: sounds awesome [12:08] mramm: yep, cloud and devops is a trending topic [12:08] mramm: so we'll see how we can get our part of this cake :D [12:09] also, anybody seen this? 2013-07-08 12:03:21 WARNING juju.environs.config config.go:429 unknown config field "future" [12:11] dimitern: so far not seen, can you isolate the test? [12:13] TheMue: trying now [12:14] it seems to be related to danilos branch about py-juju and juju-core compatibility checks about the environment config [12:15] dimitern: I've seen a fair number of WARNINGs while the test suite is running. nothing that fails the suite, though. [12:15] jam: all these warnings are valid, but I think we need to be able to suppress them for tests [12:15] jam: the tests themselves are about checking unknown keys [12:18] dimitern: agreed, I don't think the test suite should put stuff onto stdout/stderr [12:19] aha! found it [12:20] wallyworld: changed goamz in r37 to support EC2_ env vars as fallbacks for AWS_ ones, and the test sets both AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY to "", but does not set the fallbacks [12:21] and i have both set because of openstack tests [12:21] i'll file a bug and propose a fix === tasdomas` is now known as tasdomas_afk === tasdomas_afk is now known as tasdomas [12:33] dimitern, whoops, "future" was my branch [12:33] dimitern, didn't realise it pooed to stderr [12:33] fwereade: it does only when there's a failure [12:33] fwereade: or when you run with -gocheck.v actually [12:55] jtv: ping [13:01] dimitern: wrt https://code.launchpad.net/~dimitern/juju-core/062-fix-bug-1198936/+merge/173486 [13:01] Do we need to update other bits of the test suite infrastructure? [13:01] Or do we clear those out elsewhere already? [13:02] jam: well, this is the only test that uses this behavior that i can see - all the others pass [13:03] i'm having issues with lbox now.. panics on "redirect blocked" after login to rietveld. I had a patch that fixed this, but alas after the reinstall got lost [13:04] dimitern: I thought that was one of wallyworld's patches to lbox ? [13:04] might also be a go version. [13:04] jam: it's a go version issue definitely, still using 1.0.3, but I might need to switch to 1.1.1 just to build lbox [13:05] dimitern: I'm using go 1.0.3 for lbox [13:05] jam: haven't seen any patches by wallyworld to lbox in the commit log === teknico1 is now known as tekNico [13:05] dimitern: it didn't land, but he had proposed it, IIRC [13:06] dimitern: most likely it was a patch to goetveld [13:07] dimitern: https://code.launchpad.net/~wallyworld/goetveld/auth-cookie-fix perhaps? [13:07] but that one is merged, so maybe not. [13:08] jam: i'll just re-get lbox and its reqs to see if it solves it [13:09] fwereade: worker/resumer/resumer.go . Is it worth implementing time.After as a watcher so that it can re-use the NotifyWatcher code? time.After can make a pretty trivial NotifyWatcher if we want to go that route. [13:10] though it is arguably the same amount of code we would be saving [13:41] fwereade: http://bazaar.launchpad.net/~jameinel/juju-core/upgrader-api-client-watcher/revision/1400# is my answer to make testing not have to wait 5s for the Sync to occur. [13:41] It exposes a helper on DummyEnviron that allows you to trigger e.state.apiState.Sync() [13:41] which is then exposed to JujuConnSuite. [13:41] fwereade: is it terrible to do? [13:42] I felt it was slightly better than giving you raw access to e.state.apiState object. [13:42] (you can click on expand all) [13:43] dimitern: what's up? [13:44] jam, sorry, back from lunch [13:44] jtv: can you send me the patch I gave you for lbox to fix the error I got (you got it too) [13:44] fwereade: no rush, I'm done for tonight. [13:44] dimitern: where is it? [13:45] jtv: i think if you do bzr diff in $GOPATH/src/launchpad.net/lbox/ you should see it (if you haven't committed) [13:45] jam, offhand it's no worse than anything else in the dummy environ ;p [13:45] jam, and at least it's in the service of saner testing :) [13:46] dimitern: no diff... I'm on r57, last committer is Roger. Not sure what patch you're talking about. [13:46] jtv: maybe geotveld then? [13:46] geotveld [13:47] goetveld [13:47] yep [13:47] Never messed with that [13:48] dimitern: is this a conversation you had with someone else maybe? [13:48] jtv: what go version are you using? [13:49] jtv: could be, it was some months ago [13:51] dimitern: go 1.0.2 . [13:51] jtv: I see [14:02] mramm: can you send me the kanban link please? [14:03] (for the hangout) [14:04] TheMue: or you? ^^ [14:09] fwereade: ^^ ? [14:10] are we doing the kanban meeting now? [14:12] dimitern: no kanban now [14:12] dimitern: only the one at 1:30pm [14:12] TheMue: ah, ok, thanks [14:12] dimitern: we've consolidated it ;) [14:13] TheMue: nice! about time :) [14:13] dimitern: yep, I like it too [14:18] https://codereview.appspot.com/11002043 [14:18] so I managed to fix my broken lbox by compiling it under 1.1.1 [14:19] jam: can you please LGTM it in rietveld now? sorry for the trouble [14:27] TheMue: can you take a look as well ? ^^ [14:29] dimitern: sure [14:30] dimitern: lgtm [14:30] TheMue: thanks [15:21] Hey, I just wanted to point out an e-mail thread that needs a response: Chris.Frantz is trying to get juju working [15:22] https://bugs.launchpad.net/juju-core/+bug/1178328 [15:22] <_mup_> Bug #1178328: error: cannot log in to admin database: auth fails

=== tasdomas is now known as tasdomas_afk [15:56] hi, counld anyone please have a look at https://code.launchpad.net/~ack/juju-core/uuid-in-environment-info/+merge/173485 ? it's a pretty trivial change [16:17] ackk, reviewed, LGTM; dimitern, would you take a quick look please? [16:18] fwereade, thanks! [16:18] ackk, just hold off until there's a second review, then set commit message and approve (or ping one of us if you can't) [16:19] fwereade, cool, thanks, will it be merged automatically? [16:19] ackk, yeah [16:19] fwereade: looking [16:20] ackk, fwereade: reviewed [16:20] dimitern, thanks [16:21] dimitern, fwereade I can't set "approved", could you please do it? [16:21] ackk: will do [16:21] ackk, done [16:21] :) [16:22] tnx [16:46] ackk: have you tried running the full test suite before proposing that change? [16:47] ackk: i mean like "go build ./... && go test ./..." in juju-core/ ? [16:49] dimitern, oh I think I ran a different command, let me try to reproduce the failure [17:04] ackk: it was a temporary failure, it's merged now once I reapproved it [17:08] anyone willing to look at a really trivial review? https://codereview.appspot.com/10858050/ [17:09] will have a look dimitern [17:09] mgz: hey, cheers [17:16] dimitern, LGTM [17:17] fwereade: cheers, landing then [17:21] dimitern, thanks [17:22] dimitern, I got the same error in trunk before the merge, fwiw [17:24] ackk: we have occasionally these intermittent test failures - if you happen across one of them after running the full tests multiple times and it occurs more than once, please file a bug and tag it as "intermittent-failure" (but search first if it's already reported) [17:25] dimitern, ok [17:55] hmm [20:06]