[01:03] <hatch> 6/6 IE, 6/6 Firefox, 6/6 Chrome
[01:03]  * hatch drops mic and walks off stage
[01:04] <bcsaller> hatch: on ec2?
[01:04] <hatch> yup
[01:05] <bcsaller> that is very good, you should try re-enabling the deploy test on IE tomorrow and see if it works with the fixes
[01:05] <hatch> yeah will do - it's 7 and I'm pretty frustrated with it now so I think I'll end the day on a win
[01:05] <hatch> haha
[01:06] <bcsaller> hatch: I said tomorrow :)
[01:06] <hatch> yup I saw that :)
[01:07] <bcsaller> in that case, good job and have a good night
[01:07] <hatch> thanks, you too
[09:56] <frankban_> hi rogpeppe: I want to add to a charm the ability to check whether or not it is deployed by pyjuju or juju-core. One possibility is just checking that /var/lib/juju/agents exists. What do you think? Are there better approaches?
[10:02] <rogpeppe> frankban_: i think that's a reasonable approach
[10:08] <frankban_> rogpeppe: cool. IIRC, I can safely assume that inside that directory there is only one machine-X dir, containing and agent.conf file which includes the API address, right?
[10:09] <rogpeppe> frankban_: i think it would probably be better to use the unit agent directory
[10:10] <rogpeppe> frankban_: i can't remember if it's possible for a charm to find its unit name though
[10:10] <rogpeppe> frankban_: you could just choose an arbitrary agent.conf file from /var/lib/juju/agents/*.conf
[10:11] <frankban_> rogpeppe: AFAICT, the agent.conf file in the unit directory does not include the API address
[10:11] <rogpeppe> i mean /var/lib/juju/agents/*/agent.conf
[10:11] <rogpeppe> frankban_: it *should* do...
[10:12] <rogpeppe> frankban_: you're right, it doesn't
[10:13] <rogpeppe> frankban_: ok, for the time being you could use the machine agent.conf, but be aware that it will fail when we have a local provider and run it in that context.
[10:14] <frankban_> rogpeppe: re the unit name, if the hook is still executed from the charm root, i can obtain the unit name just getting the base name of ..
[10:14] <rogpeppe> frankban_: that's true. in fact that's a better way than hardcoding /var/lib/juju/agents
[10:15] <rogpeppe> frankban_: because you will be inside the agent dir already, i think
[10:16] <frankban_> rogpeppe: I need to hardcode that dir if I want to check juju-core vs pyjuju. Another possibility is checking that ../agent.conf exists.
[10:16] <rogpeppe> frankban_: +1 to the latter
[10:17] <rogpeppe> frankban_: there's no particular reason that the juju directory must live in /var/lib/juju
[10:18] <frankban_> rogpeppe: ... but the presence of an agent.conf is meaningful, and it did not exist in pyjuju, right?
[10:18] <rogpeppe> frankban_: exactly
[10:19] <frankban_> rogpeppe: cool. re the api address. so, is it a bug? is it supposed to be stored in the unit's agent.conf?
[10:19] <rogpeppe> frankban_: i'll make a change to add the API info to the uniter agent.conf - it will need to be there eventually anyway
[10:19] <rogpeppe> frankban_: currently the uniter doesn't communicate through the API
[10:20] <frankban_> rogpeppe: ok, I'll check in the machine for now, and switch to the uniter once ready
[10:20] <rogpeppe> frankban_: sounds good
[10:21] <rogpeppe> frankban_: i wonder if it might be nice to have an officially supported callback that gives the API server address
[10:21] <frankban_> rogpeppe: you mean, a hook command? it would be great
[10:22] <rogpeppe> frankban_: yeah. we'd have to think about the implications though
[10:22] <frankban_> rogpeppe: or an env var
[10:22] <rogpeppe> frankban_: yeah, that's a nice possibility too
[10:27] <frankban_> rogpeppe: cool, thanks
[12:19] <gary_poster> teknico, thanks for Monday national holiday submission
[12:25] <teknico> gary_poster, it's not an April Fool, I promise! :-)
[12:25] <gary_poster> :-)
[12:31] <gary_poster> hey benji your rietveld diff for landscape is geborken
[12:32] <benji> gary_poster: yeah, I'm trying to streighten it out
[12:32] <gary_poster> try reproposing, or merging trunk and reproposing?
[12:32] <gary_poster> k cool
[12:35] <gary_poster> hey benji, lock in bottom right should be replaced with triangle as well
[12:36] <gary_poster> need screenshot or screenshare?
[12:36] <benji> hmm, I thought I did that, checking
[12:36] <benji> aparently not, thanks!
[12:36] <gary_poster> welcome
[12:44] <benji> gary_poster: fixed: https://codereview.appspot.com/8038045
[12:44] <gary_poster> cool will look
[12:45] <benji> hatch: if you're still interested in reviewing https://codereview.appspot.com/8038045 I have fixed the diffs
[12:45] <benji> gary_poster: I did have to resize one of the graphics, but I think it turned out OK
[12:45] <gary_poster> ok
[12:49] <gary_poster> benji LGTM
[12:49] <gary_poster> ty
[12:49] <benji> cool
[12:52] <frankban_> behold the juju-core charm! https://ec2-54-224-95-37.compute-1.amazonaws.com/
[12:55] <gary_poster> frankban_, awesome! :-)
[12:55] <gary_poster> quantal?
[12:56] <frankban_> gary_poster: quantal bootstrap node, precise juju-gui
[12:56] <gary_poster> ah! makes sense
[12:56] <gary_poster> cool
[13:00] <gary_poster> frankban, try switching charm to trunk and see if we get minimal  service visibility thanks to benji's newly landed megawatcher support and the newly released juju core?
[13:00] <gary_poster> I mean, switch source to lp:juju-gui
[13:00] <frankban_> gary_poster: already did 1 minute ago :-)
[13:00] <frankban_> waiting
[13:00] <benji> note that you will have to use firefox and you will have to visit the websocket url via HTTPS first to accept the certificate
[13:00] <gary_poster> cool
[13:01] <gary_poster> benji, not in charm
[13:01] <benji> oh yeah, I forgot it is proxied there
[13:01] <gary_poster> \o/ :-)
[13:01] <gary_poster> \o/ for the charm good ness I mean
[13:11] <frankban_> gary_poster: charm transitioned to juju-gui trunk. still I cannot see any service deployed (I deployed wordpress from cli). The panel also freezes when I try to deploy, e.g. mysql from the GUI.
[13:11] <gary_poster> frankban, :-/ but that's why we have another week or two to iron things out
[13:12] <gary_poster> frankban, could you file those two obvious bugs and make cards please?
[13:12] <frankban> gary_poster: anyway, the prototype seems to work well :-). sure
[13:12] <gary_poster> yes frankban!  yay for charm :-)
[13:13] <frankban> gary_poster: could you please try to duplicate the second bug?
[13:16] <gary_poster> frankban, duplicated--and I see a flash in the alerts from blue to gold back to blue.  that means that we temporarily lost the websocket connection and rejoined.  in the past that has meant that Juju Core didn't understand us, and disconnected rather than giving us an error message. We ideally would improve that as well.  If you knew where the Go logs were we could confirm
[13:17] <gary_poster> rogpeppe, ^^^ good news is that we have a charm prototype that is beginning to work against juju core!  bad news is that practically we have some bugs to fix in the intercommunication before we even begin to see it working, but hopefully this will go quickly?
[13:17] <rogpeppe> gary_poster: cool!
[13:17] <rogpeppe> gary_poster: the bugs are in the js side?
[13:18] <gary_poster> rogpeppe, the only thing on the Go side is, *I suspect*, that Juju core API is still disconnecting when it falls over, without giving us an error message.  
[13:18] <gary_poster> rogpeppe, we will get confirmation
[13:19] <frankban> gary_poster: trying to find the logs
[13:19] <gary_poster> thanks frankban 
[13:19] <gary_poster> frankban, document it after you figure it out ;-) .  and maybe ask roger if you think it would go faster
[13:19] <gary_poster> but your call
[13:24] <rogpeppe> gary_poster: "when it falls over"... when the API server falls over?
[13:25] <gary_poster> rogpeppe, yes.  If you recall we had some behavior at the sprint in which we sent some kind of malformed request to the API server.  The API server disconnects and reconnects, rather than returning an error
[13:26] <frankban> gary_poster, rogpeppe: this is interesting: http://pastebin.ubuntu.com/5652266/
[13:27] <gary_poster> precisely
[13:27] <rogpeppe> frankban: yeah, that is interesting
[13:27]  * rogpeppe wishes json ave a little more context for its error messages.
[13:27] <rogpeppe> s/ave/gave/
[13:28] <rogpeppe> frankban: i see the problem
[13:28] <gary_poster> rogpeppe, so that's what I'd like fixed on the Go side: don't disconnect, and do give us a better idea of what to fix.  Meanwhile, we can probably work around
[13:29] <rogpeppe> frankban: well, the superficial problem anyway
[13:29] <rogpeppe> frankban: you're sending null for ConfigYAML, not ""
[13:30] <rogpeppe> frankban: but the API server shouldn't chuck out clients that produce badly formed requests, i think
[13:30] <gary_poster> rogpeppe, extra points if Go side can convert JSON null to type equivalent :-)
[13:30] <rogpeppe> frankban: i'll look into fixing that
[13:30] <gary_poster> thank you rogpeppe 
[13:30] <frankban> rogpeppe: that's a problem for sure. I think gary_poster was suggesting that we should no be disconnected after an invalid request
[13:31] <rogpeppe> gary_poster: in later versions of Go a null becomes an empty string
[13:31] <rogpeppe> gary_poster: unfortunately we're using an old version
[13:31] <gary_poster> rogpeppe, ok cool. :-/ but good that it will be better.  will that be changed for 13.04?
[13:32] <gary_poster> well...
[13:32] <rogpeppe> gary_poster: probably not. go 1.1 is due out soon, but i very much doubt it'll be there for 13.04
[13:33] <gary_poster> rogpeppe, I'm confused/interested, but don't spend much time on my request: I thought we could just change how we built Juju releases, using the newer version, and then it wouldn't matter what the host had?
[13:33] <gary_poster> if any version of go at all, in fact
[13:34] <rogpeppe> gary_poster: perhaps, but we tend to standardise on using the version of the language which is distributed as standard
[13:34] <frankban> gary_poster, rogpeppe : from that log, I suspect there is another error: after logging in again and obtained the watcher id, the "Next" request fails
[13:34] <rogpeppe> gary_poster: which is why we're using 1.0.2 not 1.0.3
[13:34] <rogpeppe> frankban: you'll need to call WatchAll again
[13:34] <rogpeppe> frankban: or perhaps you *are* doing that?
[13:35] <frankban> rogpeppe: ISTM that we do that, RequestId 8
[13:35] <gary_poster> rogpeppe, if that has negative effects on the Juju experience, maybe that's worth reconsidering, but conversation for later
[13:35] <rogpeppe> gary_poster: yeah. quite a lot of nice changes coming: http://tip.golang.org/doc/go1.1
[13:36] <rogpeppe> frankban: can you post a log of events? (how does the Next request fail?)
[13:36] <gary_poster> http://pastebin.ubuntu.com/5652266/
[13:36] <frankban> yes
[13:37] <rogpeppe> gary_poster: thanks. interrresting.
[13:39] <rogpeppe> gary_poster: i'll have an investigate after i've done what i'm currently doing
[13:39] <gary_poster> frankban, I wonder if GoEnvironment._send_rpc ought to strip out all nulls before sending?
[13:39] <gary_poster> rogpeppe, thanks
[13:39] <rogpeppe> gary_poster: that sounds like a reasonable approach
[13:40] <gary_poster> cool rogpeppe thanks
[13:41] <rogpeppe> gary_poster: assuming you can't just stem the nulls at source, of course
[13:41] <gary_poster> rogpeppe, we can, but idiomatically sending nulls in JS is quite reasonable
[13:41] <rogpeppe> gary_poster: right
[13:42] <rogpeppe> gary_poster: i think that's why they changed the behaviour in later Go versions.
[13:42] <gary_poster> yeah
[13:42] <gary_poster> rogpeppe, if I were going to stir up trouble about th1 1.1-for-releases thing, would I do it on the juju-dev list?
[13:43] <rogpeppe> gary_poster: well, i'd wait until 1.1 is actually released :-)
[13:43] <gary_poster> heh, ok, I'll hold horses :-)
[13:44] <frankban> rogpeppe: I confirm the "Next" call always fails with "unknown watcher id" 
[13:45] <rogpeppe> frankban: yeah, seems odd. there's something fishy going on :-)
[13:45]  * benji looks forlornly at https://codereview.appspot.com/8038045, hoping for a second review.
[13:46]  * gary_poster has done his duty
[13:47] <rick_h_> benji: I'll take a peek if that helps
[13:47] <benji> rick_h_: it would, thanks.  It's a simple branch.
[13:47] <frankban> gary_poster, rogpeppe: it seems we have three bugs: 1) gui: null sent by _send_rpc 2) core: disconnections on invalid requests 3) core: Next not working . do you want me to file these?
[13:47] <gary_poster> hatch, when you are around, good work on the login hack for the CI test.  I wish we had a better approach, but I'll take it. ;-) I encountered the stale cache issue this morning repeatedly in IE and investigated some more.  there is a driver.refresh() and I have tried incorporating it.  The next test run passed, but that's not necessarily correlated
[13:48] <rogpeppe> frankban: +1
[13:48] <gary_poster> frankban yes on 1, yes on 2.  For 3, it does work sometimes, yeah?
[13:48] <gary_poster> benji, did you see Next working? ^^
[13:48] <gary_poster> via the GUI
[13:48] <rogpeppe> frankban: if you could file 2 and 3 with some code that reliably reproduces the issues, that would be lovely.
[13:49] <gary_poster> rogpeppe, how about JSON API calls?
[13:49] <gary_poster> rather than code, per se
[13:49] <rogpeppe> gary_poster: that would be fine actually, yeah
[13:49] <benji> gary_poster: I got a service to show up in the gui, so I assume so, but I didn't check that in particular
[13:49] <gary_poster> cool
[13:49] <frankban> gary_poster: looking at the bootstrap node logs it seems it never works, and this could also explain why we don't see services in the env view.
[13:49] <gary_poster> benji, yeah it must have worked then
[13:50] <gary_poster> benji, what did you do to prepare for that test?
[13:50] <hatch> goooood morning
[13:50] <gary_poster> hey hatch
[13:51] <benji> gary_poster: I deployed go-juju and did the certificate dance
[13:51] <benji> and tweaked the GUI config to point to the right place
[13:52] <gary_poster> hatch, was also going to say that selenium exposes an application_cache object, but very under documented and we don't see a problem with it right now.  something to file away though
[13:52] <gary_poster> http://selenium.googlecode.com/svn/trunk/docs/api/py/webdriver_remote/selenium.webdriver.remote.webdriver.html#selenium.webdriver.remote.webdriver.WebDriver.application_cache
[13:52] <gary_poster> benji, did you have any services deployed?
[13:52] <benji> yep, I deployed mysql
[13:53] <gary_poster> via command line
[13:53] <gary_poster> on same series
[13:53] <benji> yep and I guess so... :)
[13:54] <gary_poster> benji did you deploy go juju from source (-update-whatever or something like that) or from release?
[13:54] <benji> from source
[13:54] <gary_poster> hm
[13:54] <benji> juju bootstrap -e ec2 --upload-tools
[13:54] <gary_poster> right
[13:54] <hatch> gary_poster: lol even the source doesn't show anything
[13:55] <gary_poster> yeah I know tried that too :-_)
[13:55] <gary_poster> :-)
[13:55] <gary_poster> I think it is exposed Java
[13:55] <hatch> print('hi') # prints hi
[13:55] <hatch> lol
[13:55] <benji> my trunk checkout is probably several days old, so it might have broken recently
[13:56] <hatch> gary_poster: if you log into the sauce labs account and watch the test as it happens - you can click on the video and take control of the browser
[13:56] <bac> gary_poster: can i ask you about service names, real vs ghost?  when a service is added to the services modellist it still has it's ghost name [i.e. "(haproxy-1)"] and that's all i've got to index into the endpoints map.  thoughts on how to get the deployed name?
[13:57] <hatch> not that that helped solve the issue - BUT it might help with the caching one
[13:58] <rick_h_> hatch: morning, can you look over https://codereview.appspot.com/7969043/ and help unblock that so he can start landing follow ups to get the ball rolling please?
[13:58] <gary_poster> benji thank you.  frankban, you're definitely using the most recent Juju release from today-ish, right?  mm...frankban, benji, here's what I suggest.  frankban, please file #1 and #2. I think you have enough details to be clear and reproducible.  For #3, benji would you be willing to take over exploring/filing that bug?  frankban and I can give you any background necessary, and then you can figure out API repro inst
[13:58] <gary_poster> ructions
[13:58] <hatch> rick_h_ yup
[13:58] <gary_poster> frankban, unless you are already digging into #3 and are interested :-)
[13:59] <gary_poster> I don't mean to rip it away from you but want to let you get back to the charm
[13:59] <rick_h_> hatch: thanks, appreciate it. He's got a second branch in the chain I'll push up shortly but he had issues using lbox with the 'req' option doh
[13:59] <gary_poster> hatch, cool!  good to know, thanks
[13:59] <benji> gary_poster: sure.  I'll even read the scroll back to figure out what y'all are talking about. ;)
[13:59] <gary_poster> benji :-) thanks
[13:59] <gary_poster> bac, um. thinking
[14:00] <gary_poster> bac, can you just ignore the ghosts?
[14:00] <gary_poster> and then pay attention when they become real?
[14:00] <gary_poster> because they will change their charm urls when they become real
[14:00] <benji> out of context quote for the day: "bac, can you just ignore the ghosts?"
[14:00] <bac> gary_poster: i don't think so because the actual deployment doesn't generate the modellist 'add' event i'm looking for
[14:00] <gary_poster> so that listener that you already need for charm changes will work
[14:01] <gary_poster> benji :-)
[14:01] <gary_poster> bac, you see what I mean?
[14:01] <gary_poster> oh
[14:01] <gary_poster> the charm won't change
[14:01] <gary_poster> hm
[14:01] <bac> gary_poster: hmm, listen for services 'add' to force the charm to load and then listen for another event to actually process it?
[14:02] <gary_poster> bac, it would be more like this in theory (not sure it would work):
[14:02] <gary_poster> services add: force charm to load.  
[14:02] <gary_poster> no try again
[14:03] <frankban> gary_poster: sounds good. I have a code snipped that reproduces the "Next" bug: http://pastebin.ubuntu.com/5652357/
[14:03] <gary_poster> bac, guichat in 5?
[14:03] <frankban> rogpeppe: ^^^
[14:03] <bac> ok
[14:03] <hatch> rick_h_ why are we converting to yui responsive but leaving the bootstrap responsive css in there?
[14:04] <rick_h_> hatch: because there's more bits using it that's he's diong in a series of branches vs an all in one :/
[14:04] <rick_h_> hatch: per my comments in there, not the way I'd prefer to see it, but that's how he'd like to go about it. part by part
[14:04] <hatch> but we have responsive and not responsive bootstrap loaded
[14:04] <hatch> we need both?
[14:04] <gary_poster> rock, thanks frankban.  benji, that pastebin would be for your bug.  You would see if it works when you try it for your deployment method.  If it doesn't work, yay, file a bug! if it does work, uh-oh, figure out when it fails! 
[14:04] <hatch> ok well I guess just to get this ball rolling
[14:04] <rick_h_> hatch: the idea was to remove bootstrap with the new redesign. Go YUI, and use the YUI bits in the new browser code
[14:04] <gary_poster> and then file a bug :-)
[14:05] <frankban> gary_poster, rogpeppe: you should be able to reproduce bug 3 by saving that script , setting up dependencies, and the running it passing the bootstrap node address, e.g.: right now you can use ec2-54-224-95-188.compute-1.amazonaws.com
[14:05] <bcsaller> bac: It seems like you can use http://yuilibrary.com/yui/docs/api/classes/AsyncQueue.html and add callbacks to load the charm and then update the endpoint map. Then run() the queue
[14:05] <_mup_> Bug #3: Custom information for each translation team <feature> <lp-translations> <Launchpad itself:Fix Released> <MTestZ:Invalid> <Ubuntu:Invalid> <mono (Ubuntu):Invalid> < https://launchpad.net/bugs/3 >
[14:05]  * benji looks
[14:05] <rick_h_> hatch: so yea, it looks strange from this MP, hopefully it'll get cleaner and we'll be sync'd with YUI releases css and js
[14:06] <hatch> alright done
[14:06] <rick_h_> hatch: https://codereview.appspot.com/8043043 is a follow up for instance that he didn't use a req= with so it's looking like both branches lol
[14:07] <bac> bcsaller: let me look at that
[14:11] <benji> Microsoft is now sending me spam about developing Windows phone apps to my @canonical.com email address.
[14:15] <hatch> rick_h_ so do I need to QA https://codereview.appspot.com/8043043 ? or is it still a WIP?
[14:15] <hatch> benji: well what are you waiting for? get coding!
[14:16]  * benji begins porting xterm to Windows phone.
[14:18] <bac> gary_poster: i'm in guichat
[14:21] <gary_poster> I'm not :-)
[14:21] <gary_poster> but will be there soon
[14:27] <goodspud_> Could you please send me the link to the gui hangout 
[14:28] <goodspud_> Currently stuck in a pub 
[14:28] <Makyo> http://tinyurl.com/guichat
[14:28] <bcsaller> *stuck*
[14:28] <gary_poster> jujugui call in 2, bring party hats for goodspud 
[14:28] <bac_> worse fates
[14:29] <rick_h_> hatch: I was going to resubmit it since it's a mix of the two branches. I'll ping you one I get it submitted.
[14:42] <teknico> grr, telecom broke both lines *again* :-P
[14:48] <teknico> rogpeppe, is it possible to debug while running juju-core tests? something like import pdb; pdb.set_trace() in python
[14:55] <goodspud> Hi all. Apologies about the pub meeting. I'm blaming Greg. 
[14:55] <rogpeppe> teknico_mobile: theoretically you can use gdb, although i haven't tried it when running tests.
[14:56] <rogpeppe> teknico_mobile: i've always found it easier to insert printfs :-)
[14:56] <teknico_mobile> rogpeppe, I need to get the info about a newly created relation from the API client
[14:56] <teknico_mobile> rogpeppe, when you get a chance can you please have a look at the diff and check if I'm doing it right? lp:~teknico/juju-core/support-add-relation-in-go-env-2
[14:56] <rick_h_> hatch: https://codereview.appspot.com/8055043 is the updated/resubmitted branch if you get time.
[14:57] <teknico_mobile> I'll need to get relation endpoints, interface and scope, even if I'm not totally sure what they are :-)
[15:01] <goodspud> bac_, bcsaller, benji, fankban, gary_poster, hatch, Makyo, rick_h_, teknico_mobile, hazmat,    I have really enjoyed working with all of you over the past months.
[15:01] <Makyo> goodspud, cheers, it's been great
[15:01] <bac_> me too goodspud
[15:01] <gary_poster> Best wishes and thanks goodspud 
[15:01] <rick_h_3> goodspud party on! 
[15:01] <bcsaller> goodspud: hopefully we'll see you again 
[15:01] <hatch> goodspud: likewise! Be sure to poke your head in here from time to time :)
[15:01] <benji> goodspud: I hate to see you go!  Have fun at your next stop.
[15:02] <teknico_mobile_> goodspud, it's been a pleasure, sad to see you go. Please come back soon! :-)
[15:02] <rogpeppe> teknico_mobile: what was the rationale for making juju add-relation print the resulting relation to stdout?
[15:03] <rogpeppe> teknico_mobile_: or did it do that before?
[15:03] <teknico_mobile_> rogpeppe, a likely mistaken attempt to get those values out, modeled on get.go :-)
[15:03] <teknico_mobile_> rogpeppe, no, it did not
[15:04] <teknico_mobile_> rogpeppe, stand by, switching net connections...
[15:04]  * rogpeppe stands well out of the way
[15:05] <teknico> that's better, I hope it lasts :-P
[15:06] <teknico> rogpeppe, is the rest of the diff vaguely reasonable?
[15:07] <rogpeppe> teknico: i'm wondering why you need to return interface and scope separately from endpoints
[15:07] <rogpeppe> teknico: i think both of those are derivable from the endpoints
[15:08] <teknico> rogpeppe, are they? we use to get those from pyjuju, and use them when adding a relation in the gui
[15:09] <teknico> I mean, we get those explicitly from pyjuju
[15:09] <rogpeppe> teknico: i guess it depends what you mean by an "endpoint"
[15:09] <rogpeppe> teknico: in the go state, it's a struct containing service name, interface, relation name, role and scope
[15:10] <rogpeppe> teknico: but it looks like you're expecting to return a simple string that specifies an endpoint.
[15:10] <rogpeppe> teknico: and in fact, i think that would be good, as we use a similar string elsewhere
[15:11] <rogpeppe> teknico: so the endpoint identifier would be service:relationname
[15:12] <teknico_> rogpeppe, this gui test shows what I expect: http://pastebin.ubuntu.com/5652518/
[15:12] <teknico_> oh, and I need the relation id too
[15:13] <rogpeppe> teknico: hmm, the "{'mysql': {'name': 'database'}}" thing seems a bit odd
[15:13] <rogpeppe> teknico_: can there be more than one thing in that outer map?
[15:14] <teknico__> rogpeppe, yeah, I guess it's a pyjuju thing, it's actually more like {'mysql': {'name': 'database', 'role': 'server'}}
[15:15] <teknico__> but I can massage that in the gui based on what I get from juju
[15:15] <rogpeppe> teknico_: i'd be tempted just to send back the endpoints as returned by Relation.Endpoint(svcName).
[15:16] <rogpeppe> teknico: unless there's a compelling reason to do otherwise.
[15:16] <rogpeppe> teknico: less work (on the Go side at any rate!) to do
[15:17] <teknico> rogpeppe, what shape would they have? and how do I get relation id, interface and scope from them?
[15:17] <rogpeppe> teknico: http://paste.ubuntu.com/5652527/
[15:21] <hatch> gary_poster: I wonder if the if/try/except in charm_panel_loaded is required anylonger now that we are destroying it
[15:22] <teknico_mobile> (sorry, landlines are still unstable, I'm back to mobile)
[15:22] <gary_poster> hatch try it :-)
[15:22] <teknico_mobile> rogpeppe, that's good, so I return two of those Endpoints and deal with the data on the GUI side
[15:23] <rogpeppe> teknico_mobile: yes, but there's a catch
[15:23] <teknico_mobile> rogpeppe, state.AddRelation returns a Relation, so I need to get the Endpoints from it
[15:24] <rogpeppe> teknico_mobile: that's not the catch :-)
[15:24] <hatch> gary_poster: can do
[15:24] <teknico_mobile> it was too easy, I guess :-)
[15:24] <hatch> `from retry import retry` is this a typo or some python mumbo jumbo? :)
[15:24] <hatch> ^ gary_poster
[15:24] <gary_poster> hatch, from [MODULE] retry import [FUNCTION] retry
[15:25] <hatch> ahh :)
[15:26] <rogpeppe> teknico_mobile: the catch is that you can't use state.Endpoint from api
[15:26] <benji> gary_poster: here is a tweaked vertion of the Next bug repro script that works: http://paste.ubuntu.com/5652551/
[15:26] <rogpeppe> teknico_mobile: so... me and fwereade have come up with a cunning plan
[15:26] <benji> I have no idea how the GUI is working, because it appears to do it the way the non-working repro script does, and not this way.
[15:27] <hatch> is Friday a holiday for everyone?
[15:28] <teknico_mobile> rogpeppe, yeah, (not really) following ;-) on #juju-dev
[15:30] <teknico_mobile> hatch, nope
[15:32] <hatch> hmm the calendar is confusing me
[15:32] <hatch> heh
[15:35] <hatch> gary_poster: have you seen success with the self.driver.refresh() ?
[15:38] <frankban> rogpeppe: filed bug 1160971
[15:38] <_mup_> Bug #1160971: WebSocket disconnects when an invalid request is sent <juju-core:New> <juju-gui:Triaged> < https://launchpad.net/bugs/1160971 >
[15:38] <rogpeppe> frankban: thanks
[16:03] <hatch> in python the exe() command does it concat items on each line?
[16:05] <frankban> hatch: exe? 
[16:05] <hatch> oh
[16:05] <hatch> self.driver.execute_script heh
[16:06] <hatch> ok...in python when you have strings across multiple lines
[16:06] <hatch> will it concat them without spaces?
[16:07] <frankban> hatch: yes, even if they are in the same line
[16:07] <hatch> ok thanks - I didn't want to make this change and then have it break 20mins into running hah
[16:09] <teknico_mobile> rogpeppe, what happens now? how can I help you to help me?
[16:09] <frankban> hatch: for multiple lines the strings must be inside round brackets
[16:09] <rogpeppe> teknico_mobile: i'm just doing the branch that will move this forward
[16:09] <rogpeppe> teknico_mobile: i've put Name into charm.Relation (tests now pass)
[16:14] <gary_poster> hatch I have seen success with refresh, but as I said this morning there's no proof of correlation that it helped, only that it didn't hurt
[16:15] <hatch> pfft -according to modern media "correlation [16:15] <hatch> ;)
[16:15] <gary_poster> :-)
[16:17] <teknico_mobile> rogpeppe, however statecmd.AddRelation calls state.AddRelation, which in turn returns state.Relation, not charm.Relation
[16:17] <teknico_mobile> rogpeppe, or are you changing that too?
[16:18] <gary_poster> benji, so your fixed script (the Id change) represents how the GUI needs to change
[16:18] <rogpeppe> teknico_mobile: that's fine. state.Relation.Endpoint will probably return charm.Relation
[16:18] <gary_poster> benji, see http://pastebin.ubuntu.com/5652266/
[16:18] <gary_poster> line 13
[16:18] <gary_poster> that's a log from the GUI talking with Go
[16:19] <benji> gary_poster: I believe so.  I'm working on a branch to make the GUI work properly.
[16:19] <gary_poster> benji, perfect thank you
[16:19] <benji> I need to make a card.
[16:19] <gary_poster> and a bug if you feel really excited but not required
[16:20] <benji> That would be the right thing to do, so I guess I will. :)
[16:21] <gary_poster> ok bac, sorry, can talk now.  when is good for you?  I have another scheduled call in 3 hours
[16:35] <hatch> gary_poster: bcsaller using EC2 during bootstrap have you ever seen an error saying that the DNS lookup failed for s3.amazonaws.com ?
[16:35] <gary_poster> no
[16:36] <gary_poster> unless my network was hosed :-)
[16:36] <hatch> hmm ok it happened a couple times last night and this morning
[16:37] <hatch> so it might just be my network
[16:40] <benji> I'm going insane or something.  I can not for the life of me get Firefox to send any console.log() messages to the JS console.
[16:40] <gary_poster> benji in what context
[16:40] <gary_poster> tests?
[16:41] <benji> just the app running
[16:41] <benji> this is the only error I see:
[16:41] <benji> Error: not well-formed
[16:41] <benji> Source File: http://jujucharms.com/search/json?search_text=series%3Aprecise%20owner%3Acharmers
[16:41] <benji> Line: 1, Column: 1
[16:41] <benji> Source Code:
[16:42] <benji> {
[16:42] <gary_poster> benji with make devel?  Anyway, in other contexts, this is a symptom of our console manager squelching, which we want in production
[16:42] <gary_poster> to try and see if that is the case...
[16:42] <benji> yep, make devel
[16:42] <gary_poster> and fix it...
[16:42] <gary_poster> 1 sec getting details
[16:42] <benji> hmm, that is a possibility, looking
[16:43] <gary_poster> benji, just type "console" in console
[16:43] <gary_poster> if it is JS object with noop methods then you are being squelched
[16:43] <benji> if only I could... my Firefox locks up if I start the dev tools
[16:44] <gary_poster> you can then type consoleManager.native()
[16:44] <gary_poster> oh you may have deeper problems :-P
[16:44] <benji> I haven't tried today.  Maybe it has turned over a new leaf.
[16:44] <benji> heh, that is a certainty
[16:45] <benji> yep, Firefox is broken.  It is totally locked up and at 106.8% CPU (good job on the multi-processing, guys)
[16:45] <gary_poster> heh
[16:46] <benji> I have started it in "safe mode" (which disables all extenstions) and have the same results.
[16:47] <benji> I guess I need to go down that rabbit hole before I can make progress on this bug.
[16:54] <hatch> gary_poster: looks like the IE test deploy passes :)
[16:54] <gary_poster> hatch, awesome!!
[16:55] <hatch> so all 6 tests pass on ec2 :)
[16:55] <gary_poster> hatch I have one other trivial change on my branch, to make juju failures give us more information.
[16:55] <gary_poster> Maybe merge, and I'm also going to merge yours
[16:55] <gary_poster> and test on canonistack
[16:55] <gary_poster> where it should work fine
[16:55] <hatch> sounds like a plan
[16:55] <gary_poster> assuming canonistack itself works
[16:55] <hatch> lol
[16:56] <hatch> with the back end going to go - I wonder if we shouldn't convert our selenium tests to use node.js to remove the dependency on python
[16:58] <gary_poster> hatch, propose it on Friday.  I don't think the back end switch is really relevant--Python is Canonical's preferred scripting language either way--but maybe you'll get enough buy-in
[16:58] <gary_poster> I'll recuse myself :-)
[16:58] <hatch> oh alright - I'm not really 'for' it just an idea
[16:59] <hatch> well that's a lie
[16:59] <gary_poster> lol
[16:59] <hatch> I am for it because I know node haha
[16:59] <hatch> but it's not that learning python is a bad thing :)
[16:59] <gary_poster> :-)
[17:05] <gary_poster> bac_, pinged you before, but repinging you in case you did not see
[17:05] <gary_poster> I may have pinged bac
[17:05] <bac_> gary_poster: ack
[17:06] <gary_poster> bac, can talk any time
[17:06] <gary_poster> till 3 
[17:06] <bac> gary_poster: ok.  let me re-up my beverage
[17:06] <gary_poster> k
[17:08] <bac> upped
[17:08] <hatch> gary_poster: I was just starting on this documentation and I'm thinking we should pair on it
[17:08] <hatch> if you have time later
[17:08] <gary_poster> hatch, can do
[17:08] <hatch> we'll probably produce better docs that way
[17:29] <rogpeppe> teknico: i've done a CL to make it feasible to return charm.Relation instead of state.Endpoint: https://codereview.appspot.com/8055044/
[17:29] <teknico> rogpeppe, thanks, looking
[17:30] <teknico> rogpeppe, wow, a bit on the big side :-)
[17:30] <rogpeppe> teknico: it's almost all mechanical changes
[17:31] <rogpeppe> teknico: it was a pain to do though
[17:32] <teknico> rogpeppe, hopefully it's going to be useful for more than my immediate problem
[17:32] <rogpeppe> teknico: yeah, it feels better actually
[17:33] <rogpeppe> teknico: and a lot of the changes are to use field names rather than unnamed fields in struct literals, which is a good change anyway
[17:35] <rogpeppe> teknico: the alternative was to define a parallel-universe Endpoint in params, and i really don't think that's worth doing.
[17:36] <teknico> rogpeppe, so, how about an example of how I use this? you mentioned calling state.Relation.Endpoint...
[17:36] <rogpeppe> teknico: so, you've just called AddRelation between two services, right?
[17:37] <rogpeppe> teknico: that gives you a Relation
[17:37] <rogpeppe> teknico: you can call r.Endpoint(svc1) and r.Endpoint(svc2)
[17:37] <teknico> rogpeppe, yes, in state/statecmd/addrelation.go
[17:37] <rogpeppe> teknico: which will give you the Relation values you want to return.
[17:38] <rogpeppe> teknico: i suggest returning Relations []charm.Relation
[17:38] <rogpeppe> teknico: where the first item is the relation for the first service, and the second is the relation for the second service
[17:38] <rogpeppe> teknico: oh yes, state.Endpoint now embeds charm.Relation
[17:39] <teknico> rogpeppe, however in that context I don't have the services, only args.Endpoints
[17:39] <rogpeppe> teknico: you've got the service names, right?
[17:39] <rogpeppe> teknico: and the Relation?
[17:39] <rogpeppe> teknico: state.Relation, that is
[17:40] <teknico> rogpeppe, yes, I have state.Relation returned by state.AddRelation
[17:40] <teknico> rogpeppe, how do I get the service names from the endpoint names?
[17:40] <rogpeppe> teknico: you've already got the service names, no?
[17:40] <teknico> (that's what is in args.Endpoints, right?)
[17:41] <rogpeppe> teknico: i guess so, one mo
[17:41] <teknico> rogpeppe, http://bazaar.launchpad.net/~teknico/juju-core/support-add-relation-in-go-env-2/view/head:/state/statecmd/addrelation.go
[17:41] <rogpeppe> teknico: ah yes.
[17:42] <rogpeppe> teknico: you can get the service names from the endpoints returned by InferEndpoints, i think
[17:46] <teknico> rogpeppe, yes, I see it now
[17:46] <rogpeppe> teknico: cool
[17:47] <rogpeppe> teknico: it's possible you might want to return map[serviceName]charm.Relation actually
[17:48] <teknico> rogpeppe, right
[17:49] <teknico> rogpeppe, thanks for all this
[17:49] <rogpeppe> teknico: no probs
[17:49] <teknico> rogpeppe, one more thing though :-)
[17:49] <teknico> is there any concept of a relation id? I can't see it anywhere
[17:49] <hatch> gary_poster: so that last jenkins test failed - but it actually passed
[17:49] <gary_poster> hatch wondered about that but on call will ping
[17:49] <hatch> it looks like it failed because some of the resources 404'd
[17:50] <hatch> oh alright
[18:00] <gary_poster> hatch guichat?
[18:00] <hatch> sure
[18:19] <rogpeppe> gary_poster: this should fix the rpc connection-dropping issue: https://codereview.appspot.com/7518052
[18:19] <rogpeppe> teknico: not really
[18:19] <rogpeppe> teknico: a relation id is just the concatenation of the two relation names
[18:20] <rogpeppe> teknico: sorry i didn't see your message earlier
[18:20] <teknico> rogpeppe, no problem
[18:20] <teknico> rogpeppe, I see. pyjuju returns stuff like relation-00000001
[18:21] <gary_poster> awesome thanks rogpeppe 
[18:21] <rogpeppe> teknico: yeah. we don't have relation ids like that
[18:21] <rogpeppe> gary_poster: np!
[18:21] <teknico> rogpeppe, I guess concatenating the relation names should still be unique and amenable to the same purpose
[18:21] <rogpeppe> teknico: that's the idea, yeah
[18:21] <rogpeppe> teknico: that's what you'll see in the RelationInfo too
[18:22] <rogpeppe> teknico: (as returned by the AllWatcher)
[18:22] <teknico> rogpeppe, ah, so the concept has already been explored, great
[18:23] <teknico>  great, tomorrow we'll see how this goes :-)
[18:24] <teknico> bye all, have a nice evening/afternoon/whatever!
[18:24] <rogpeppe> teknico: see ya!
[18:30] <rick_h_> hatch: did yuo get a sec to poke at qa on https://codereview.appspot.com/8055043/ ?
[18:31] <hatch> negative, I can do that now
[18:31] <rick_h_> hatch: appreciate it. If it's cool and I can land before huw starts for the day would be awesome and unblocking to him :)
[18:34] <hatch> rick_h_ should I check out your branch or his?
[18:34] <rick_h_> hatch: so I re-submitted his branch. So that one is safe to check
[18:34] <rick_h_> it's just a merge of his but sumitted with the -req so the diff is clean
[18:35] <hatch> ahh ok
[18:40] <hatch> rick_h_ done - it looks like you need to use LGTM instead of lgtm as it's not showing up green for yours
[18:40] <rick_h_droid> oh missed that all along 
[18:41] <hatch> :) I saw it a couple times and just brushed it off as something else - but that's all I can think of that it might be :)
[18:41] <rick_h_droid> I didn't put the green together with approval. 
[18:42] <hatch> oh that's ok - it's a fairly new development - you may not have been in that call
[18:42]  * hatch just opened up a new Wired ......mm the smell of a new magazine
[18:43] <rick_h_> magazine? what is this thing you speak of?
[18:44] <hatch> :) I prefer to read on dead trees
[18:44] <hatch> it's a much more fulfilling experience
[18:44] <benji> rick_h_: he's reloading his gun
[18:44] <rick_h_> yea, just don't read magazines
[18:44] <rick_h_> benji: ah, that explains it. Yea a fresh magazine is a wonderful thing. Hope it was larger than the one you had before
[18:45] <hatch> lol
[18:45] <benji> heh
[18:46] <hatch> aren't they banning large magazines in the US now?
[18:47] <hatch> I only catch bits of news so I could be totally missinformed
[19:07] <gary_poster> bac or benji are you available for a quick skype (!) call to check something out with Antonio and me?
[19:07] <bac> gary_poster: sure
[19:07] <gary_poster> thanks bac
[19:07] <bac> skype?
[19:08] <bac> hold on, let me queue up Flock of Seagulls
[19:08] <gary_poster> yes bac
[19:08] <gary_poster> lol
[19:08] <benji> gary_poster: I am taking a late lunch, but if you don't mind the occasional interruption to give Owen another bite, I'm up for it.
[19:09] <gary_poster> benji, we're good thank you
[19:09] <benji> cool
[19:10] <sinzui> oh happy days. Looks like lxc-ls broke again...sso is trying to make it run as a py2 script
[19:13]  * benji has lxc flashbacks from the last project.
[19:35] <benji> rick_h_: is there a way to fetch all subscribers to an event?
[19:36] <rick_h_> benji: hmmm, not something i know of but I guess there must be some way as chrome can list them
[19:36] <benji> ok, thanks
[19:37] <rick_h_> benji: I'd ask in #yui 
[19:38] <benji> that sounds like a fine idea
[19:39] <rick_h_> benji: is the code you're looking to test up? Normally you just test the two sides of a test and rely on the framework to make the connection as it's tested
[19:40] <rick_h_> heh, or just do what ln_s says. That sounds darn handy. /me writes that one down
[19:41] <benji> rick_h_: this is more about testing to see that the subscription is wired up right.  I am reacting to a self-inflicted bug in which I did it wrong and it bit me.
[19:41] <rick_h_> benji: ah, cool
[19:42] <hatch> benji: so you're testing that the .on() functioned properly?
[19:42] <benji> hatch: nope, I'm testing that I called it properly
[19:42] <hatch> ohh I gotcha
[20:00] <benji> new branch up for review: https://codereview.appspot.com/8058043
[20:03] <hatch> benji: looking now - so you're saying that there should only be a single listener on _rps_response ?
[20:04] <benji> hatch: that assertion is more along the lines of a non-test assertion.  In other words, the test assumes that there is only one.  If others are added the test should be updated as is appropriate.
[20:05] <benji> I will add a comment to that effect.
[20:05] <hatch> alright - and maybe add why that's necessary
[20:05] <hatch> adding extra events usually isn't a testable offence :)
[20:08] <benji> :)
[20:23] <gary_poster> bcsaller, I don't know how to dupe the problem you were fixing but code looks fine. :-P I guess that is a "LGTM"?  I'll mark it as such unless you want me to qa in a particular way
[20:23] <gary_poster> this is the ghost service one
[20:23] <gary_poster> bug 1112771
[20:23] <_mup_> Bug #1112771: Newly deployed service box not drawn <ie10> <juju-gui:In Progress by bcsaller> < https://launchpad.net/bugs/1112771 >
[20:25] <bcsaller> gary_poster: thanks for looking. I think with landscape annotations on you could see this by ghost deploying any new service before. What was being seen in IE was the result of it throwing an error during the draw process
[20:25] <gary_poster> ah gotcha.  cool, thank you
[20:26] <gary_poster> approved
[20:33] <gary_poster> hatch any brilliant thoughts on test failures?  it passed again most recently. :-/
[20:34] <hatch> gary_poster: I'm still waiting for their reply - I am wondering if it's always the last browser
[20:34] <hatch> I think when it was in IE it was also the last browser
[20:35] <gary_poster> hatch I don't think so.  it was the last we ran because we always stopped if theer were errors :-)
[20:35] <gary_poster> hatch, the thing I noticed is that the same tests failed, between the two failing tests
[20:36] <gary_poster> also for the reload thing: 
[20:36] <gary_poster> I mean the cacheing thing:
[20:36] <gary_poster> the big cache problem we have is the manifest cache/index.html
[20:36] <gary_poster> there's no reason for us to have cache problems with the unit test
[20:36] <gary_poster> and we don't see cache problems with index.html
[20:37] <gary_poster> we could verify this by changing index.html
[20:37] <gary_poster> and rerunning test
[20:37] <hatch> what if we concatted our test files?
[20:37] <hatch> I'm wondering if maybe there are too many
[20:37] <hatch> maybe it's trying to load too many things before the tests start across the wire
[20:38] <gary_poster> hatch, I was wondering about their vm memory size, but we rely on YUI loadr
[20:38] <gary_poster> and I haven't seen any issues with that
[20:38] <gary_poster> we don't proceed until the YUI loader is OK
[20:39] <gary_poster> hatch did you get our branch up for review yet?  we ought to get that merged
[20:39] <gary_poster> even with this annoyance
[20:39] <hatch> I'm attempting too :)
[20:40] <hatch> I am fighting with some nfs garbage
[20:40] <gary_poster> ah ok
[20:41] <hatch> ahah fixed
[20:41] <hatch> not sure what was up with that
[20:46] <benji> hmm, the latest YUI release 3.9.1 includes feature changes; tsk tsk
[20:46] <hatch> gary_poster: did you merge in my change adding back ie deployment stuff into your branch?
[20:46] <gary_poster> not sure hatch, will look in a sec
[20:48]  * Makyo walkdogs.
[20:48] <hatch> benji: yeah? I haven't looked yet, which ones
[20:48] <gary_poster> hatch, related to unit bugs, try this "./test-server.sh prod true"
[20:48] <gary_poster> I see bugs
[20:48] <gary_poster> failures I mean
[20:48] <benji> I'm just reading from the release announcement: "Ryan also added a feature to Y.Tree adding a src option to all methods that trigger events."
[20:49] <hatch> gary_poster: and after you clear cache?
[20:50] <hatch> oh yeah...and that's a bad thing? The API didn't change
[20:50] <gary_poster> hatch, same
[20:50] <gary_poster> oh, wait
[20:51]  * bac -> daily dog appeasement march
[20:51] <gary_poster> hatch, nm, forgot to run make build :-/
[20:53] <hatch> :D
[20:56] <hatch> gary_poster: so just to confirm you don't get errors in FF now?
[20:56] <gary_poster> hatch locally no
[20:56] <gary_poster> and most recent test run passed.  another running now...
[20:56] <hatch> ok and the last two which failed - idential failures happened
[20:56] <gary_poster> y
[20:57] <hatch> ok I'm going to pull up the vids and see if I can find out why
[20:57] <hatch> see if those rely on some common file
[20:57]  * hatch working on a hunch
[20:57] <gary_poster> hatch, was thinking: tests are against prod, compressed files
[20:57] <gary_poster> the only files not compressed are tests themselves
[20:58] <gary_poster> but the main app is running from compressed bits
[20:58] <gary_poster> equivalent to "make build && ./test-server.sh prod true"
[20:58] <gary_poster> if you want to see what I mean
[20:58] <hatch> yep - but that passes locally
[20:58] <hatch> so I'm wondering if there is a common file which the failing tests rely on
[20:59] <gary_poster> hatch, IE failed that time
[20:59] <gary_poster> on unit tests
[20:59] <hatch> arg
[20:59] <gary_poster> https://saucelabs.com/jobs/cfa9fd980c1946038da32d5dca518997
[21:02] <hatch> notice how in the video it's shows the tests
[21:02] <hatch> flashes, then starts running them?
[21:02] <hatch> I wonder if i'ts running two at the same time
[21:02] <gary_poster> hatch remember I put in a refresh
[21:03] <hatch> oh right
[21:03] <gary_poster> maybe making things worse.  I did have this crazy idea
[21:03] <gary_poster> run tests twice :-/
[21:03] <gary_poster> unit tests
[21:03] <gary_poster> will try
[21:05] <hatch> the errors look like they are a result of the app instance screwing up
[21:09] <hatch> ok I'm tracing back one of the errors
[21:09] <hatch> Unable to get property 'services' of undefined or null reference
[21:09] <hatch> which is in updateData in topology/services.js
[21:09] <gary_poster> on compressed code that will be interesting :-/
[21:09] <hatch> and it's trying to get services of topo.get('db')
[21:10] <hatch> so 'db' is undefined in topology/services.js
[21:11] <gary_poster> race?
[21:12] <hatch> that's my first thought
[21:12] <hatch> just tracing it back
[21:15] <hatch> yeah so it looks like Y.juju.models.Database is undefined
[21:15] <gary_poster> hatch you mean the class itself
[21:16] <hatch> yeah because it looks like db is set with a new instance of it
[21:16] <hatch> but I'm not sure how it could be undefined and not throw an error at 'new'
[21:16] <gary_poster> yeah that's what I was going to say
[21:17] <hatch> new undefined or null would both throw typeerrors
[21:17] <gary_poster> if it were possible then it could maybe be explained by poor dependencies
[21:17] <gary_poster> but new undefined makes no sense
[21:18] <gary_poster> hatch fwiw trying this crazyness: http://paste.ubuntu.com/5653490/
[21:18] <gary_poster> try running the tests
[21:18] <gary_poster> if they fail
[21:18] <gary_poster> refresh and try again
[21:18] <gary_poster> :-/
[21:18] <gary_poster> shrug
[21:18] <gary_poster> we fail fast
[21:18] <gary_poster> so shouldn't add much time
[21:18] <hatch> ahh
[21:19] <hatch> of course for the next 10 runs everything will run properly lol
[21:19] <gary_poster> no real reason to believe this will have diff behavior though
[21:19] <gary_poster> heh
[21:22] <gary_poster> hm idea: if it fails again, we can try running the /test/ url directly through saucelabs while charm is up
[21:23] <gary_poster> using their immediate feature
[21:23] <hatch> ok I'm getting somewhere
[21:24] <hatch> juju charmworld0 api tests fail
[21:24] <gary_poster> hatch what do you mean?
[21:24] <hatch> but one of the failing tests isn't even in that describe
[21:24] <gary_poster> oh
[21:25] <gary_poster> that does sound suspicious
[21:25] <hatch> I can show you - guichat?
[21:26] <gary_poster> syre
[21:26] <gary_poster> there now
[22:48] <hatch> lately I have been piping my diffs to colordiff
[22:48] <hatch> I attempted to put in a bzr alias to overwrite diff but that broke the reviews
[22:48] <hatch> do you guys do anything similar under a separate alias?
[22:57] <rick_h_> hatch: I just use a pipe to vim. 
[22:58] <hatch> ahh I would have guessed as much :P
[22:58] <rick_h_> hatch: I've got a zsh pip alias V that is `vim -` so I can bzr diff V
[22:58] <rick_h_> and it opens up vim and syntax higlights it nicely
[22:58] <rick_h_> and VV maps to gvim -
[22:58] <rick_h_> so if I want gui-ness
[22:59] <hatch> ah that's pretty cool
[22:59] <hatch> I really have to decide on an OS at some point
[23:00] <rick_h_> only one choice :)
[23:00] <hatch> unfortunately I can't purchase music without windows or mac
[23:00] <hatch> lol
[23:01] <hatch> no itunes on linux :P
[23:04] <rick_h_> heh, itunes if your problem there
[23:04] <rick_h_> Google/AMZ ftw
[23:04] <hatch> they won't sell to Canadians
[23:04] <hatch> our money is no good to them
[23:04] <hatch> :)
[23:04] <rick_h_> orly?
[23:05] <hatch> yep, we can't even get spotify, hulu, pandora etc
[23:05] <rick_h_> well...it's what VMs are for. Even with AMZ I have to download on a windows VM and transfer the files over to linux/google to upload
[23:05] <hatch> oh really? I thought it was all web based
[23:05] <rick_h_> sounds like you've got a bigger problem. We have houses here you know
[23:05] <hatch> lol
[23:05] <hatch> yeah and they are A LOT cheaper haha
[23:05] <rick_h_> you can buy/play but if you want to download from AMZ you have to use a client
[23:05] <hatch> ohhh
[23:05] <rick_h_> I'm just N of detroit. Lots of cheap houses down there
[23:06] <hatch> I would have to move to aspen or something
[23:06] <hatch> no snow, no go
[23:06] <hatch> ;)
[23:06] <rick_h_> well we get some snow. Nothing horrible
[23:08] <hatch> odly enough when I'm in the US my Google Play store points to the US store, but won't let me buy with my CAD credit card, and won't let me switch to the Canadian store
[23:08] <hatch> lol
[23:08] <hatch> I was bored waiting for my flight and wanted to buy a movie - I was like wth? haha
[23:30] <hatch> gary_poster: if the CI stuff hangs on the ADDRESS... part does that mean it's waiting for a machine?
[23:30] <hatch> it's been over an hour
[23:31] <gary_poster> hey hatch.  I saw that.  both instances say that they are running.  lemme look a little farther
[23:31] <hatch> oh it just dumped a ton of python errors
[23:31] <hatch> heh
[23:31] <gary_poster> hatch, there ya go :-)
[23:32] <gary_poster> I'd say the -v worked :-P
[23:32] <hatch> lol
[23:32] <hatch> I'm going to kill it and try again
[23:32] <hatch> nothing I changed from your branch should have done that
[23:32] <gary_poster> it's already dead
[23:32] <gary_poster> just rebuild
[23:33] <hatch> alright #182
[23:33] <gary_poster> :-)
[23:33] <gary_poster> If the retry functionality worked it would automatically retry
[23:33] <hatch> oh maybe it did and I stopped it
[23:33] <hatch> oops
[23:34] <gary_poster> no it didn't :-/
[23:34] <gary_poster> it ;s not working
[23:34] <gary_poster> oh!
[23:34] <gary_poster> yes
[23:34] <gary_poster> ooh!
[23:34] <gary_poster> you are right!
[23:34] <gary_poster> Started by Naginator!
[23:34] <hatch> nanananananananananaginator
[23:35] <gary_poster> :-) 
[23:35] <hatch> ok well I'll leave this run again I guess
[23:35] <hatch> I want a successful run before I push the code :)
[23:36] <gary_poster> that's awesome that the retry worked!  well, kind of sort of awesome within the larger context of non-awesomeness of canonistack flakiness!
[23:37] <hatch> yeah I just hope it stops polling when it's running
[23:38] <hatch> or - more imporatantly - continue poling and queue up those changes
[23:38] <hatch> I mean...it should ;)
[23:59] <gary_poster> hatch, canonistack is down for the count again.  I'm going to implement the health check for the juju commands.  meanwhile you can kill the run.