[12:29] <bac> hi gary_poster, i updated the machine image, as well as automating it though that isn't done yet, but CI is still failing.  i can't tell what is wrong from the console logs of the two runs i tried.  thoughts?
[13:03] <gary_poster> bac, hi, I am out today.
[13:03] <gary_poster> jujugui ^^^
[13:05] <bac> gary_poster: right, sorry
[13:09] <gary_poster> bac if I had to guess from output I would say image is wrong somehow, but yeah, output is not useful at all, and diff than before
[13:10] <bac> gary_poster: yep.  go away.  :)
[13:10] <gary_poster> :-)
[13:14] <hatch> morning
[13:32] <benji> hatch: I bet you're not quite in the office yet.
[13:38] <benji> rick_h_: I have a YUI event/subscriber question.  Do you have a minute to talk in the hangout?
[13:39] <hatch> benji, correct, should be in about 10 though
[13:40] <benji> hatch: cool; you and rick_h_ can race to see who gets to talk to me
[13:53] <hatch> lol ok I'm back
[13:53] <hatch> still need the hangout?
[13:54] <hatch> ^ benji 
[13:55] <benji> hatch: I'll meet you in the regular place.
[13:55] <hatch> cool be there in a sec just gota grab my headset
[13:58] <Makyo> hatch, sorry I didn't get to QA last night, doing it now.
[14:00] <hatch> benji, we have a bad connection
[14:00] <hatch> trying to rejoin
[14:26] <hatch> benji, is it all of the attr change facades are sticking around?
[14:26] <hatch> or just one?
[14:26] <hatch>  /some
[14:27] <benji> hatch: I don't know about all, but many, many are
[14:27] <hatch> alright thats fine
[14:27] <hatch> thx
[14:28] <hatch> benji, are there any other attribute facades sticking around?
[14:28] <hatch> others besides change?
[14:28] <hatch> Makyo, thanks :) 
[14:30] <abentley> sinzui: btw, the app-exception.log is tremendously useful.  Thanks for getting that working.
[14:31] <sinzui> yes it is isn't it. I ponder switching to oops tools instead of sending volleys of errors emails to me now
[14:32] <hatch> benji, sorry, did you see the previous message?
[14:33] <sinzui> abentley, do you want me to request a release of m.jc? I think this will be the first release of using the ES collection migration feature
[14:33] <abentley> sinzui: Please do.
[14:35] <bac> hi hatch
[14:35] <bac> hatch: jenkins is running again but still unhappy.  can we chat a bit to go over the failures?
[14:36] <hatch> I think that failure you want to talk to frankban about
[14:37] <hatch> he was having some issues with the deploy test failing
[14:37] <benji> hatch: there aren't enough to show promenently in the heap snapshots, but there may be
[14:37] <bac> hatch: previously there was a failure sending results to saucelabs.  perhaps that one was transient.  have you seen it before?
[14:40] <bac> hatch: thanks.  i think frankban is gone today.
[14:40] <frankban> hatch, bac: the failures I was seeing last week are caused by firefox not being able to reconnect the websocket after switching from sandbox to staging.  I think that's unrelated to the current errors. However, I am changing my branch so that the selenium driver is started for each testcase (not once for all tests). This should make our suite more reliable, and slightly slower...
[14:41] <frankban> bac: I am here
[14:41] <bac> but i was wrong!
[14:41] <bac> frankban: is that landing soon?
[14:42] <frankban> bac: I'd like to propose it today. Coding is done, testing takes time
[14:42] <bac> ok
[14:44] <Makyo> For future reference: lightweight checkouts suck for QAing.
[14:45] <frankban> one cool thing about having a separate driver for each testcase is that we have many separate saucelabs videos
[14:47] <Makyo> hatch, LGTM on QA.
[14:47] <hatch> thanks Makyo - landing
[14:48] <hatch> bac, still want to chat? 
[14:48] <bac> hatch: sure, briefly
[14:50] <bac> hatch: ready when you are
[14:50] <hatch> can you hear me?
[15:00] <hatch> benji, eric said that it's likely our app which is causing the issue 
[15:00] <benji> hatch: that's easy for him to say ;)
[15:00] <benji> meanwhile I have a workaround that stops the leak (and might break the app, but you can't have everything)
[15:02] <abentley> sinzui: One thing I can't help noticing is that even minutes after restarting elasticsearch, it's still eating a lot of CPU although no one's hitting it AFAIK.
[15:03] <abentley> It's bouncing around between 10%-70% CPU use and load average is .96
[15:04] <hatch> benji, lol any luck with the repro?
[15:04] <benji> hatch: I haven't tried yet, I had the idea for the workaround and wanted to try it first, repro is next
[15:05] <hatch> gotcha - I can help with the repro if you want to pass me your testing code
[15:05] <sinzui> abentley, wow. what is in play? it starts the Java vm, the lucene proc, and a web proc
[15:06] <frankban> bac: I duped the 'service not deployed' error locally, investigating
[15:06] <bac> frankban: ok, thanks
[15:07] <abentley> sinzui: It appears to be the elasticsearch binary.  http://pastebin.ubuntu.com/5667901/
[15:08] <hatch> oh awesome you can watch the uds videos live
[15:10] <abentley> sinzui: CPU is now reasonable and load average is dropping.
[15:14] <hatch> running the tests and streaming a uds video have put my laptop to a new high temperature!
[15:16] <hatch> 72.5C lol
[15:16] <sinzui> abentley, The current ES release has a number of fixes for hangs. It is probably worth us updating. Lp's imports failed though. I will kick, and if that fails, I will pull the source directly from github
[15:17] <abentley> sinzui: Great.
[15:19] <hatch> jujugui - new login/logout branch has been merged with trunk
[15:19] <hatch> let me know if you run into any issues
[15:24] <sinzui> abentley, m.jc is not r225. I an sadder note, I think I deleted your very important email that I was not to read until my head was clear. Please resend it...I will immediately move it a safe place so that it is not among the blueprint spam
[15:25] <abentley> sinzui: done.
[15:27] <sinzui> abentley, adeuring: I ponder the relationship between the short_url KeyError and promulgated charms. Every example I see is juju-gui, the only promulgated charm that is not owned by charmers.
[15:28] <adeuring> sinzui: thanks 
[15:28] <abentley> sinzui: Yes, that could be it.  The short-form URL I'm using is one of those places where we're forced to assume ~charmers.
[15:46] <frankban> may the ancient gods kill firefox because he's sick and suffering
[15:47] <hatch> frankban, lol
[15:48] <hatch> some things it does so well....others....not so much
[15:50] <frankban> bac, hatch: so it seems that in firefox the appflower deployment fails because the service block is not visible in the canvas at the default zoom level, and so, the corresponding element's text is just empty. :-O
[15:50] <Makyo> jujugui call in 10
[15:51] <hatch> frankban, possible issue from the layout changes Makyo did?
[15:51] <frankban> bac, hatch: fixing this in my branch and the fix will be... zooming out before checking for service names in the canvas.
[15:51] <hatch> lol 
[15:51] <bac> frankban: thx
[15:51] <hatch> I suppose that's the best fix as any
[15:51] <Makyo> What :|
[15:52] <Makyo> Zoom levels just act as a viewport.  Things that are outside the viewport are still on the canvas.
[15:52] <frankban> hatch: yes, Makyo's changes are great, firefox is cursed, firefox is the new ie. ok I said that...
[15:53] <hatch> Makyo, ahh ok - I wasn't sure exactly how your layout code handled that
[15:53] <hatch> frankban, lol! at least it auto updates so it CAN be fixed :)
[15:53] <Makyo> hatch, exactly like scrolling.  Elements at the bottom of the page are still within the dom.
[15:53] <Makyo> SVG being just a part of the DOM.
[15:53] <hatch> I don't think the test knows that it's in the dom, just that it's visible
[15:54] <hatch> so I was wondering if your new layout stuff put the new service off the page
[15:54] <hatch> (in the soucelabs tests)
[15:55] <frankban> hatch, Makyo: it's just a firefox issue AFAICT. The service block is found in the DOM, and the tests knows both that it's in the DOM and that it's not visible by the user. The problem is that selenium/firefox is not able to retrieve the .name element text if the service block is not made visible. that's really odd
[15:56] <hatch> oh boy...lol sounds like a firefox selenium driver issue
[15:57] <hatch> so maybe it's seleniums fault not firefox
[15:57] <hatch> ;)
[15:57] <Makyo> frankban, ah.  Yeah, browsers treat SVG a little strangely (HTMLElements vs SVGElement), and some of the attributes/methods are different.  Hopefully it's not that...
[15:57] <hatch> firefox does have issues with svg attributes
[15:57] <frankban> zooming out fixes that, and let's say it's also not horrible, b/c it lets you see the deployed service in the videos
[15:57] <Makyo> If so, though, just means involving D3 in tests, since they've already solved the cross-browser compatibility problem there.
[15:58] <Makyo> Huh
[15:58] <Makyo> That's weird.
[15:58] <Makyo> jujugui call in 2
[15:58] <hatch> I'm ok with zooming out as a solution
[15:58] <hatch> :)
[15:58] <frankban> seeing things from a wider perspective is always a good idea
[16:03] <Makyo> https://ec2-54-243-27-37.compute-1.amazonaws.com/
[16:10] <benji> by the way, my laptop's wi-fi has been crazy flakey for the last week or so, so if I'm not on IRC, I'll probably be back soon.  You can always text or call me if need be.
[16:12] <Makyo> Doing a few quick config change on the ec2 site I just mentioned, just to see if that messes with things at all.
[16:14] <Makyo> Seems fine.
[16:41] <jcsackett> hatch: looks like your login/logout stuff might be eating urls.
[16:42] <jcsackett> if i go to /bws/sidebar, that gets removed as the page loads. i can make the behavior stop by reverting your revision. :-/
[16:43] <bac> umm, tasty urls
[16:44] <jcsackett> bac: :-P
[16:46] <hatch> jcsackett, so when you type that url in manually it is just removed?
[16:47] <jcsackett> hatch: right; if i put in $guiurl/bws/sidebar, rather than getting the sidebar loaded, i get just the canvas and the "/bws/sidebar" bit is gone.
[16:47] <hatch> ok let me look into that thanks
[16:48] <jcsackett> hatch: not sure you should be thanking me, but thank you for looking into it. :-)
[16:54] <hatch> jcsackett, ok I can reproduce - the sidebar shows up still but the url is gone
[16:56] <jcsackett> ccccccbljtrvbcvtkeunclicukrirgefcjfkjcbtkcll
[16:56] <jcsackett> dammit.
[16:56] <hatch> lol
[16:57] <jcsackett> hatch: i don't reliably get the sidebar. sometimes it shows, sometimes it doesn't. the url is always eaten though.
[17:00] <hatch> ok it strips urls no matter what
[17:00] <hatch> I'll have to investigate this
[17:01] <hatch> it's not just on browser
[17:02] <jcsackett> dig.
[18:22] <hatch> jcsackett, just wanted to let you know I have found the issue and working on a proper workaround
[18:29] <hatch> Makyo, are you around?
[18:43] <Makyo> hatch, just got back.  What's up?
[18:45] <hatch> In order to fix the bug that jc found, to do a proper fix I should implement the redirect 
[18:45] <hatch> after logging in
[18:45] <hatch> so.... localstorage or hash?
[18:45] <hatch> I am thinking local
[18:45] <hatch> or another 'clean' experience I'm happy with too
[18:46] <hatch> storing with some other type of local var
[18:46] <Makyo> I say a var, or maybe local storage.  I think the full story has logging in as a step in a process, so we shouldn't need anything as complex as a storage mechanism.
[18:47] <hatch> sounds like a plan
[18:47] <hatch> alright I'll implement it with this fix
[18:51] <Makyo> hatch, cool.  Sounds good.  Want to just convert the discussion card to a task?
[18:52] <hatch> sure thing
[18:52] <hatch> doesn't look like I can
[18:52] <hatch> I can re-make one though
[19:03] <Makyo> Sure.
[19:30] <benji> why is the gui using jquery?  I didn't know we had that in there.
[20:34] <Makyo> Out for the afternoon, stuff fromn earlier turned into migraine.  Back 100% tomorrow
[20:37] <hatch> get better Makyo|out ! C U tommorow
[20:49] <bac> hatch: my ci branch is up for review if you'd like a diversion for your afternoon
[20:50] <hatch> certainly
[20:50] <bac> ✈✈✈
[20:50] <bac> i'm going to try to walk the dog between storms
[21:51] <hatch> bac, review has been completed, sorry I forgot to click 'submit' :)