[00:28] can anyone help me make the juju-core build recipe dependent on a ppa [00:28] is taht possible ? [00:40] arosales: did jamespage say we could use his PPA via a LP build recipe ? [00:40] first signs are that this is not possible [01:29] davecheney: looking [01:29] m_3: s'ok i figured it out [01:29] I think it's a separate [01:29] ah, cool [01:30] m_3: arosales bigjools is there a way to get this bumpedup ? [01:30] https://code.launchpad.net/~dave-cheney/+recipe/juju-core [01:30] 6-7 hour build delay before I find out if it worked [01:30] davecheney: I no longer have da powahs, go to the internal ops channel and ask nicely [01:31] * davecheney practices best asking for things smile [01:31] davecheney: also you get get a permanent boost on a nominated PPA by also asking nicely [01:31] davecheney: dunno [01:31] s/get get/can get/ [01:32] I approve of your LP avatar [01:32] davecheney: might be worth the time setting up pbuilder-dist... you'll at least know in short order for archs and series that you target [01:33] indeed, pbuilder should be used for build testing, NOT launchpad [01:33] bigjools: i need to move to having a proper source build, not lp build recipes [01:33] they are crutch [01:33] it's a piece of piss to do it all from a recipe locally [01:34] recipes make it easy [01:34] my fav is the 'merge-part'... ahem [01:35] sorry... s/merge-part/nest-part/ [01:35] that's the icky one [01:43] * bigjools imagines davecheney's "best asking for things smile" to look a bit like Sheldon Cooper's [01:44] bigjools: yes, but with more sincerity [03:26] wallyworld: do you have affinity group stuff in openstack? [03:27] not sure tbh [03:27] never had cause to use it [03:27] trying to work out whether the azure solution we're going with needs to worry about it [03:27] i'll ask martin tonight [03:28] the way juju works seems to assume your env is one group [03:28] if that's not the case then we have a problem [03:28] there's only one state server right now [03:28] yeah [03:28] but that will change with HA [03:29] when is that coming? [03:29] "soon" [03:29] i think it's next after API work [03:29] can't recall exactly [03:29] ok ta [03:29] should be ok... I think [03:31] actually, in sept [03:31] after manual provisioning [04:04] faaaaaaaaaaaaaaaark [04:04] 2013-07-10 04:00:46 ERROR juju supercommand.go:234 command failed: cannot start bootstrap instance: no "precise" images in ap-southeast-2 with arches [amd64 i386] [04:04] error: cannot start bootstrap instance: no "precise" images in ap-southeast-2 with arches [amd64 i386] [04:05] how the fuck did that happen [04:07] precise server release 20130502 ebs amd64 ap-southeast-2 ami-9d4bdba7 aki-31990e0b paravirtual [04:07] precise server release 20130502 ebs i386 ap-southeast-2 ami-9f4bdba5 aki-33990e09 paravirtual [04:07] precise server release 20130502 instance-store amd64 ap-southeast-2 ami-9b4bdba1 aki-31990e0b paravirtual [04:07] precise server release 20130502 instance-store i386 ap-southeast-2 ami-4f4bdb75 aki-33990e09 paravirtual [04:07] they really are there, I promise [04:30] wallyworld: is ec2/image.go used anymore [04:30] or has it been replaced byt he stuff in environs/instances ? [04:57] can anyone bootstrap at the moment ? [04:57] I keep getting 2013-07-10 04:56:52 ERROR juju supercommand.go:234 command failed: cannot start bootstrap instance: no "precise" images in us-west-1 with arches [amd64 i386] [04:57] error: cannot start bootstrap instance: no "precise" images in us-west-1 with arches [amd64 i386] [05:20] ffs, every time I go to use juju is broken [05:20] about to call instances.FindInstanceSpec with images [] [05:20] FindInstanceSpec: matchingTypes [{ m1.small [amd64 i386] 1 1740 80 0xe3bc50 0xc210000510} { m1.medium [amd64 i386] 1 3840 160 0xe3bc50 0xc210000518} { c1.medium [amd64 i386] 2 1740 183 0xe3bc50 0xc210000560} { m1.large [amd64] 2 7680 320 0xe3bc50 0xc210000520} { m2.xlarge [amd64] 2 17408 495 0xe3bc50 0xc210000548} { m1.xlarge [amd64] 4 15360 640 0xe3bc50 0xc210000528} { m3.xlarge [amd64] 4 15360 700 0xe3bc50 0xc210000530} { c1.xlarge [amd6 [05:20] FindInstanceSpec: possibleImages [] [05:20] 0 images are passed as candidates... [05:31] davecheney: it's used, but only as glue logic between ec2 provider and simplestreams [05:32] davecheney: sounds like the metadata that has been set up for ec2 is out of date [05:34] wallyworld: i think it is the cost data [05:34] ec2/image.go ~ line 60 [05:34] nothing is making it through that filer [05:34] let me look [05:36] wallyworld: http://paste.ubuntu.com/5860638/ [05:39] davecheney: at first look, it seems very weird since there's no constraints to exclude instance types [05:49] davecheney: it would be good to see some more tracing, especially the value of matchingImages around line 33 of ec2/image.go [05:50] and also images from line 38 [05:51] dialing connection 20 cloud-images.ubuntu.com:80 [05:51] findInstanceSpec: matchingImages [] [05:51] none === tasdomas_afk is now known as tasdomas [05:53] hmmmm [05:54] wallyworld: is it broken for you ? [05:54] i tried other series' and regions [05:54] davecheney: well, i bootstrapped an ec2 env this morning from source [05:54] different region though i think, let me check [05:55] ap-southeast-2 and us-west-1 at broken for me at least [05:55] i used the default, us-east-1 [05:56] trap for young players, us-east-1 always works [05:56] nope, us-east-1 doesn't work for me [05:56] davecheney: the fact that matchingImages is [] means that there is a mismatch between the simplestreams metadata and the hard coded regions and endpoints in the aws lib [05:57] well, that's my theory [05:57] goamz is up to date [05:58] since the metadata parsing process is to load up all simplestreams metadata and filter out the stuff that doesn't have the same region and endpoint as defined in goamz [05:58] i'll boot up an env again and see what happens [06:01] davecheney: fails for me now. worked this morning [06:01] bloody hell [06:02] davecheney: and it appears simplestreams metadata was recently updated [06:02] davecheney: http://cloud-images.ubuntu.com/releases/streams/v1/ [06:02] those timestamps would be UTC [06:02] so last update was 2 hours ago i think [06:03] davecheney: i'll dig into it have see what i find. i'm not blaming the metadata yet. need evidence first :-) [06:03] shit, 14:02 ws when I first noticed it [06:04] it must have _just_ broken then [06:04] actaully about 15 minutes before hand [06:04] but I spent that time facepalming [06:04] hmmm. i'll see what i can find [06:05] wallyworld: it *looks* like there is a ap-southeast-2 (and other) region defined in the streams data and index files [06:06] yes it dos [06:06] does [06:06] there's nothing obviously wrong that jumps out at me [06:11] 2013-07-10 06:11:01 WARNING juju.environs.ec2 image.go:43 no matching image meta data for constraints: &instances.InstanceConstraint{Region:"us-east-1", Series:"precise", Arches:[]string{"amd64", "i386"}, Constraints:constraints.Value{Arch:(*string)(nil), Container:(*instance.ContainerType)(nil), CpuCores:(*uint64)(nil), CpuPower:(*uint64)(0xc2100dad98), Mem:(*uint64)(nil)}, Storage:(*string)(0xc210280fd0)} [06:14] WHOA, loggo doesn't output warnings without -v [06:15] davecheney: some tracing shows that juju thinks the index file is missing some data [06:16] but to my eye, the data is there, so looking further [06:16] ╯°□°）╯︵ ┻━┻ [06:16] huh? [06:16] davecheney: 'juju' never output anything without '-v', that behavior was preserved when we switched to loggo. [06:16] jam: that sucks [06:17] In a "lets change one thing at a time" sort of way [06:17] that is a suckful experience [06:17] davecheney: agreed. [06:17] And it was intended to change [06:17] * davecheney writes a shitty gram to list [06:17] at least by a few of us [06:18] wallyworld: any chance we have an archive of the contents of simplestreams, so we can compare to what it used to be, and maybe seen an obvious way it was generated differently? [06:18] i wish :-) [06:18] that would be too easy [06:18] i don't think we have the previous copies [06:18] could be wrong [06:18] wallyworld: it is worrying that there is no fallback/archiving done for important info like this. [06:19] jam: there might be, *I* just am not aware of it [06:19] wallyworld: so given there is json sjson and json.gpg, is json.gpg just a --detach-sign, and sjson just an inline sign? [06:19] yes [06:20] wallyworld: it is clear that the archives aren't being put in an "old/" or a "$DATE/" sort of directory [06:20] which is probably what I would like to see. [06:20] agreed [06:20] wallyworld: I think in theory the history is in the file itself, right? With the problem that it gets regenerated from scratch with whatever the current logic is. [06:20] yes [06:23] jam: davecheney: the index file is wrong [06:23] wallyworld: \o/ [06:23] it doesn't contain an "index" map key [06:26] i'll email the relevant people [06:26] clearly our processes nd to be fixed [06:27] there should be a staging area where new metadata is vetted [06:27] using some acceptance tests [06:53] davecheney, you figure out the dependencies are between PPA's right? [06:54] jamespage: yes sir I did [06:54] hopefully it'll bake correctly this afternoon [06:54] also mgz copied those binaries to https://launchpad.net/~juju/+archive/golang [06:54] ahhhhhhhhhh [06:55] * davecheney shakes fist at LP for having *three* names for things [06:55] url, name and description [06:55] ffs [07:06] jamespage: from what I see in that page, it looks like 1.1.1 is officially in saucy's archive? [07:27] jam: it is indeed [07:27] (uploaded it yesterday) [07:28] jamespage: great! Did you get the multi-arch stuff sorted out? [07:28] (last I saw there was failures to build go on i386 or something) [07:28] jam: no - thats still pending - I just pushed a new version based on the packaging currently in saucy [07:29] jam: there are still some issues with CGO and the approach that the debian maintainer is taking re cross compiling [07:32] jamespage: so it is asking the amd64 builder to cross compile an i386 binary? [07:32] (or something to that effect) [07:32] jam: actually its the other way round - i386 builds the compilers and runtimes for all archs [07:32] not sure I'm 100% comfortable with that [07:33] jamespage: that sounds problematic for i386 to build an amd64 arch [07:35] wallyworld, the diff for https://codereview.appspot.com/10777044/ is very dirty, would you take a look at it please? [07:54] jam: maybe but cross compilation is a feature of golang [07:54] jam: so long as the required cross build headers are present it should work [08:01] good morning fwereade [08:01] jam, heyhey [08:34] hmm, the bootstrap_test in cmd/juju fails intermittent [08:39] TheMue, bug it please (and please fix it if it's reasonably easy to do so) [08:39] jam, just looking at SyncAPIServerState [08:40] jam, is that really the only way to get at the *State backing the api server? [08:41] fwereade: yep, will first propose my sync-tools and then investigate. seems to be only if my system is under load by parallel tasks. [08:42] TheMue, cheers [08:44] jam, I can believe it is, I was just not even aware that the api server was running in the dummy environment [08:44] jam, and it kinda feels like there's something rather surprising there [08:45] frankban, heyhey, reviewed, please let me know what you think [08:46] jam, (there are also perspectives from which it makes sense ofc) [08:46] fwereade: cool, thanks [08:56] jam, https://codereview.appspot.com/10890047/ reviewed [09:14] fwereade: I put off my StartInstance/Bootstrap refactoring to give Tim time to finish his, but I have another good one for you. Got a moment for a video chat? === jtv2 is now known as jtv [09:15] jtv, sure, would you start one please? [09:15] Coming right up. [09:15] fwereade: https://plus.google.com/hangouts/_/77dc830b0aa56248e9ccb3151e2e92e99cb4427c?hl=en-GB [09:42] fwereade: sorry about the delay, I was out getting groceries. But yes the actual server machine you are running is started as part of dummyenviron.Bootstrap() [09:43] Does that even work on the dummy provider!? [09:43] And that isn't returned anywhere that I could obviously see. [09:43] jtv: It is running in-process [09:43] jam, yeah, that makes some sort of sense... even though the fact that we're running hacked-up half bits and pieces of a bootstrap and a machine agent is really just crazy [09:43] fwereade: certainly it isn't what *I* expected. [09:44] jam, all I'd known about was the hacked-up bootstrap [09:44] I would have thought JujuConnSuite would have been starting it locally and retaining a reference to it, rather than indirectly via Bootstrap [09:45] jam, yeah, that would be the sane thing to do [09:45] fwereade: so, I'm perfectly happy to change the code so that the back-door exposes the full state.State object [09:46] and then we shove that on the test suite. [09:46] I'm not 100% sure what to do about the State connection we have, which is an independent connection to the mongodb [09:46] we could just replace it [09:46] so the lines in JujuConnSuite for "s.State = NewConn()" would be replaced with "s.State = ExtractStateConnFromEnvironment()" [09:46] or whatever we call that thing. [09:47] That means the tests for API Server also use the same State object [09:48] Anybody free to review a refactoring across the providers? Cleans up the interaction between environments and their storage: https://codereview.appspot.com/11087043 [09:48] fwereade: for https://codereview.appspot.com/10890047/diff/5001/state/apiserver/upgrader/upgrader_test.go?column_width=80 [09:49] Does defer AssertStop() interact if you directly call AssertStop() at the end of the test? [09:49] I like the "make sure it is stopped even if these assertions fail" [09:49] jam, AssertStop should be safe repeatedly, because Stop should also be [09:49] I'm worried about "AssertClosed" leaving us in a state where AssertStop fails accidentally. [09:49] jam, won't help in cases where we expect an error out of stop [09:49] I'll put it back, if it fails, I'll take it out. :) [09:49] jam, ok :) [09:50] jam, I think AssertClosed should be independent [09:50] jam, I'm not sure about smooshing all possible state conns together though [09:51] jam, we definitely need access to the API one but I'd prefer to extract that to a sensible place so we have a bit more clarity on what's in play before we make sweeping changes [09:55] fwereade: hey, can you take a look at this please? https://codereview.appspot.com/10944044 [09:56] dimitern, ack [09:58] jam: you too maybe? since it's watcher stuff ^^ [10:01] dimitern, LGTM with comment on the description [10:01] fwereade: thanks, I'll try to accomodate this at client-side on the next CL [10:01] dimitern, great [10:02] fwereade: the picture is somewhat unclear yet though [10:02] dimitern, the easy way to do it is to s/LifecycleWatcher/StringsWatcher/ on the client side and be done with it [10:02] fwereade: that's where the StringsWatcher (in params) interface will come into play (client-side), right? [10:02] dimitern, yeah, but it shouldn't be in params [10:03] fwereade: ah, so you're saying to have only one concrete implementation at client-side, rather than an interface and multiple implementations? [10:03] dimitern, and tbh... api/watcher.NotifyWatcher and api/watcher.StringsWatcher both seem to be like perfectly reasonable concrete types, no interface hackery required [10:03] dimitern, they'll still implement those interfaces just fine, but we don't need to declare them [10:04] fwereade: ok, then I can get rid of the NotifyWatcher interface in params and do the rename in this CL? [10:04] dimitern, sure, that works for me [10:04] fwereade: cool [10:04] * fwereade bbiab [10:04] fwereade: so one concern is how to lable the thing. "StateBeingUsedByAPIServer" is a bit long :) [10:05] jam, heh, and APIState is taken [10:05] jam, if api were called api maybe things would be saner, but that's a big change [10:07] jam, BackingState? at least it's compact [10:08] dimitern, fwereade: so for StringsWatcher, I'd certainly want to see something that looks a bit more like NotifyWatcher, where you pass in the *WatchResult and get back a running StringsWatcher [10:08] the existing code makes the Watch call for you [10:08] jam, but doesn't collide, and with a comment it'd make some sense [10:08] which means that the client side API is a bit tangled. [10:08] jam, agreed, as soon as we need an implementation, which is imminent [10:08] fwereade: StateInAPIServer ?, but BackingState is reasonable. [10:09] jam, dimitern: for the purposes of this CL I think the implementation should be left alone though [10:10] jam, your call [10:11] jam: should there be worker/stringswatcher as well for it? [10:12] fwereade: usually multiple threads in IRC can be resolved because you are talking to a different person. Hard when it is all the same. :) [10:12] dimitern: If you think there is commonality worker/stringsworker could be really nice, as it then lets you decouple the "I'm watching something from" "Here's what I do when it changes" [10:14] dimitern, I'm not sure yet [10:15] dimitern, would you mail thumper for an opinion on how well it'll fit with the provisioner? if that will really have to be tortured to make it fit, then no [10:16] dimitern, because deployer will be the only implementation for the forseeable... oh wait [10:16] dimitern, minunits handling [10:16] fwereade: yeah [10:16] dimitern, ok, that's a yes, and if the provisioner can fit it too it'll be a nice bonus [10:16] dimitern, thanks [10:16] Sorry to interrupt... anybody free to review a refactoring? It cleans up the interaction between providers and Storage: https://codereview.appspot.com/11087043 [10:17] and fwiw it is very nice, and simple to review :) [10:17] * fwereade really off for a bit now [10:20] jtv: looking [10:21] dimitern: so we had Cleaner and Machiner and a few of them that used the Notify pattern. I *like* splitting things out to separate concerns. But as William said, if it can't actually be reused it isn't worth writing. [10:21] Thanks dimitern! [10:21] I did develop NotifyWorker in tandem with changing Cleaner so I would know the design fit. [10:22] * jtv runs errand [10:27] jtv: is https://codereview.appspot.com/11087043/patch/6001/7023 actually being used? It looked like everything already had an implementation. [10:27] jtv: reviewed [10:32] jam: btw the :12345 - my bad :) I was testing and there were some failures and I don't actually remember why I did it, but it shouldn't have landed [10:32] jam: I think it was to be able to monitor the exact server that was launched [10:32] dimitern: interestingly enough, the Machiner one was already gone by the time we noticed the failures in UpgradeWatcher. It took me a bit to figure out where it came from. [10:33] jam: yep it came from there [10:33] dimitern: yeah, except it doesn't actually work, because the server that is launched is running inside the Environ. [10:33] which is what I'm working on exposing a bit now. [10:42] TheMue: can you include a paste of the failing test https://bugs.launchpad.net/juju-core/+bug/1199698 ? [10:42] <_mup_> Bug #1199698: intermittent test failure in BootstrapSuite [10:46] fwereade, jam: updated as discussed: https://codereview.appspot.com/10944044/ [10:52] dimitern: +1 [10:53] jam: good to land you think? [10:53] jam: sure [10:54] jam: moving that outside of params was fwereade's request and I like it as well [10:57] jam: I used them in the dummy provider, localstorage, or both — can't remember which. [10:58] Thanks for looking at my branch, people! [10:59] jam: right now I have no more test run without a failure :( [11:00] jtv: what I saw at least looked like you might have wrote that first and not realized we had implementations, but if it is used, its fine to keep it. [11:00] jam: the failing tests are the --upload-tools tests [11:00] TheMue: something to keep in mind for future reports. It is hard to see context in case someone else tried to pick up the failures. [11:00] TheMue: interesting. Might be a platform bug. [11:00] I think "--upload-tools" forces precise always [11:00] (recent change) [11:01] so if you are running on precise, you only upload 1 tool [11:01] if you are not [11:01] then you upload at least 2 [11:01] "recent" as in a month ago or so. [11:02] jtv: I need to teach you enough API so you can do some quid-pro-quo :) [11:02] jam: I'll check, because of course I can always have mis-remembered. :) IIRC the dummy and localstorage both lacked a deleteAll equivalent. [11:02] jam: but I already had runs where it is working [11:02] jtv: https://codereview.appspot.com/11036043/ is a pretty straightforward rename of a package if you want to give it a look. [11:02] jam: and the test case which is failing (8, 9 or 10) is changing from run to run [11:03] TheMue: that is very strange. [11:03] jam: exactly [11:03] jam: coming... But be warned: I'm a notorious nit-picker. :_ [11:03] :) [11:04] Oh, that's quite a lot — let me just polish off what I have in flight first. [11:04] jtv: it is big, but all mechanical [11:05] mv environs/agent => agent/ [11:05] Good, I'll put any heavy lifting for my branch's follow-up into its own branch, and review yours first. [11:05] dimitern, reviewed [11:05] fwereade: I responded to https://codereview.appspot.com/10890047/ [11:06] It now opens up BackingState [11:06] fwereade: cheers [11:06] fwereade: https://codereview.appspot.com/10944044/ ... I would *really* like to see things that are working on the API *not* import juju-core/state [11:07] so while we could use the interface from there [11:07] it means we also expose all the raw state stuff [11:07] vs just knowing "we don't import state in this module" [11:07] thoughts? [11:07] (it is why I created an interface rather than re-using the existing one) [11:07] jam, I'm only thinking of worker/cleaner really, that's still using state [11:07] fwereade: well, let me finish Upgrader, and Cleaner is quite tempting :) [11:08] but fair enough [11:08] jam, uniter is strictly higher priority I think [11:08] jam, I'm firmly +1 on keeping state imports out of packages that use the API though [11:08] jam, sorry if that wasn't clear [11:15] sure, but uniter is complex, Cleaner is like 1 API change :) [11:16] rv-submit is awesome! it makes using rietveld+lp+tarmac the same as lbox submit does! [11:16] I recommend all of you to try it out - no need to set commit message in LP, set the MP to approved, etc. it even updates the [r=reviewers line] correctly [11:16] dimitern, nice [11:17] fwereade: yeah, version_test.go was the first time I've ever seen: import "." anywhere. [11:17] install it just with: bzr branch lp:rvsubmit ~/.bazaar/plugins/rvsubmit [11:17] I didn't know it worked [11:17] but there was "version.*" in the test suite. [11:18] dimitern: well, sort of correctly: R=fwereade, fwereade, jameinel, jameinel [11:18] If we used Launchpad's "Approve" tarmac would be picking the R= line correctly as well [11:19] jam: that's because it counts all LGTMs [11:19] jam: that could be improved - but it's better than having [r=dimitern] only ;) [11:19] dimitern: right, it just needs to dedupe them. Though I'd rather put the time in fixing tarmac to understand LGTM as well. [11:23] jam: any idea what's this: https://code.launchpad.net/~dimitern/juju-core/066-apiserver-stringswatcher/+merge/173896/comments/389246 [11:24] fwereade: 2 design things about upgrader-api-worker. (1) I thought of a way to do the delayed shutdown with a LifesupportRunner. Since the goal is that an outside signal is delayed, but an inside signal is immediately shutdown. I won't implement it yet, but I think it can fit nicely if we want it. [11:24] fwereade: but (2) The Upgrader wants to wait on 2 channels, 1 for the new versions, and 1 for when the download completes. [11:24] I could re-implement all of the NotifyWorker locally just to get another channel [11:24] or I could expose a "Handlers may request 1 extra <-chan interface{} to wait on" [11:25] then Handlers can multiplex any waiting they want to do onto that channel [11:25] does that seem a reasonable design? [11:25] Or should I just go with "ignore NotifyWatcher for now" [11:25] jam, thinking [11:26] dimitern: I think it is that rv-submit is setting Approved state without setting the Approved revision field. [11:26] jam: hmm so I can see a patch to fix this [11:26] and the reviewers dedups [11:26] fwereade: with a WatchExtra() <-chan interface{} => HandleExtra(interface{}) [11:27] fwereade: then things based on NotifyWatcher can handle as many actual channels as they want, they just need to add context on in and out [11:27] alternatively, I'm not sure Upgrader would suffer terribly if it just blocked until it finished downloading the current thing. [11:28] jam, heh, that latter one feels like a nice gordian knot solution [11:29] jam, but I'm having some difficulty properly picturing the WatchExtra/HandleExtra in practice so I may just be dumb today [11:30] fwereade: right now, SetUp() returns a Watcher, we could have it also return a "<-chan interface{}" [11:30] or we could have inside the main loop [11:30] select { case <-watcher.Changes(): ... case <-handler.WatchExtra()) [11:32] jam, can you think of other use cases? feels a bit situational to me right now... [11:33] fwereade: Provisioner also has one primary watcher (I think) but then a few other side things going on. [11:33] jam: branch reviewed. [11:34] jam,yeah, but that's stringswatcher-based [11:34] jtv: thx [11:39] Hhello, just now I had an interesting case. A week ago my teammate used juju bootstrap in the same EC2 zone, but with different control-bucket and security credentials. Today I run juju bootstrap with my own control-bucket and security credentials. And when I run juju destroy-environment both bootstrap nodes were terminated. [11:40] We have separate credentials within one AWS account. [11:40] Is this correct behavior? [11:43] pavel: I *think* if you name your environments differently it won't step on eachother, but instances that get deployed are labeled by environment name, not by control bucket. [11:44] yeah... I thought that exactly this was the case [11:45] But it's frustrating I think [11:48] fwereade: your stream is frozen. [12:28] jam: how do I run a live test? [12:33] jtv: cd environs/ec2; source ~/.ec2creds; go test -amazon [12:33] Thanks. [12:33] for whatever values of ec2 credentials you want to use [12:33] or [12:33] cd environs/openstack [12:33] go test -live [12:33] though you also need your Canonistack credentials, etc. [12:33] Is there no way to do this against the local or dummy provider? [12:33] jtv: all the providers run them against the test doubles if you just do "go test ./..." [12:33] except azure doesn't implement a double [12:33] Ah OK, so then "make check" should be enough. [12:34] right [12:49] jam: prereq/bot question [12:50] I marked my branch that fixes tests on danilo's having his as a prereq [12:50] mgz: to avoid landing snafus, approve and wait for prereq, then approve post [12:50] if you can't do that [12:50] you can mark prereq as merged [12:50] and land the second [12:51] does this mean his needs to land first... in which case that was a mistake, because the bot will reject it as the tests don't pass without both... [12:51] ah, neat hack, will try that [12:51] mgz: right, you can set the MP status to Merged, and then the bot will let you land the second one. [13:09] abentley: hey, I found 2 issues while testing rvsubmit [13:09] Oh, what? [13:10] abentley: it seems it's not setting ApprovedRevision and also should remove duplicates in approvers list (e.g. if X has 2 LGTMs it appears twice) [13:10] ah, right, I also ran into both of those :) [13:10] dimitern is a better user than I for reporting [13:12] dimitern: I'm surprised I have to specify approved revision-- why doesn't it default to the current revision like the UI does? [13:13] abentley: it seems to be required by the go-bot (or tarmac) [13:13] abentley: see here https://code.launchpad.net/~dimitern/juju-core/066-apiserver-stringswatcher/+merge/173896/comments/389246 [13:14] dimitern: I'm not disagreeing, I'm just saying it's dumb that launchpad makes me do extra work to set the approved revision. [13:14] abentley: I'm guessing the GUI grabs the current revision from some data on the page when it submits the request [13:14] but it is explicitly sending it, rather than just setting approved. [13:14] abentley: because if your page is out of date [13:14] the approved revision is out of date [13:15] abentley: I've done 'bzr push' and then marked it approved on the page, and the bot tells me the wrong revision is approved. (Because I didn't reload the page after Launchpad noticed the updated branch) [13:15] ah, I scared him off :( [13:15] :) [13:17] abentley: https://launchpad.net/+apidoc/devel.html#branch_merge_proposal [13:17] It looks like "revid" is an optional field [13:17] to setStatus [13:17] and the webpage is grabbing reviewed_revid and passing it into queued_revid [13:18] I've certainly had cases where I had an old MP view, and didn't refresh after "bzr push" and then tarmac tells me "there are additional revisions that have not been reviewed" [13:18] jam: Do you have any thoughts about whether I should look at the local tip or just always use Launchpad's tip? [13:19] abentley: you mean the one on the review page, the one on lp:~branch-i-pushed; vs WT.revision? [13:19]