[00:08] <bac> hey rick_h_
[00:09] <rick_h_> bac: howdy
[00:09] <bac> i've gotten most things integrated and working.  may need to bug you in the morning to work out why the heights aren't what i expect.
[00:09] <rick_h_> bac: sure thing
[00:09] <bac> the charm panel has very tight specs for those sizings
[00:09] <rick_h_> ping me when you get in and we can run through it. 
[00:09] <rick_h_> bac: k
[00:10] <bac> rick_h_: it is here if you're curious lp:~bac/juju-gui/hookup-resizing-textarea
[00:10] <bac> the single line inputs in the charm panel have to be 28px tall.  it took some weird tweaking to get them there
[00:11] <rick_h_> bac: yea, I think that's what that single input height was for. To kind of 'check' how tall each line of text should be
[00:11] <rick_h_> bac: I'll try to look at it in the morning and see 
[00:12] <bac> rick_h_: i changed single_line to be either falsy or to take a height.  the LP version used 1em hard coded
[00:12] <bac> rick_h_: have a good night.
[00:12] <rick_h_> bac: you too
[01:35]  * hazmat watches gary_poster fill up the inbox in real time
[01:35] <gary_poster> :-)
[01:36] <hazmat> thanks
[01:36] <gary_poster> welcome (glad it is a good thing; was a bit worried about subscribing juju-gui but thought it was appropriate)
[01:38] <rick_h_> oh, is that why I'm getting dupes? 
[01:38] <rick_h_> ok, thought I had done it wrong when I sub'd to everything 
[01:50] <gary_poster> sorry rick_h_ 
[01:50] <rick_h_> gary_poster: no, all good. Was curious checking if they were new ones I missed/etc
[01:50] <gary_poster> :-)
[01:50] <gary_poster> I added three
[01:51] <gary_poster> added juju-gui for those
[01:51] <rick_h_> cool
[09:31] <frankban> morning rogpeppe
[09:32] <rogpeppe> frankban: hiya
[09:32] <frankban> bug 1160971 seems fixed, I attached the script used to dupe it, now it works well, do you want me to mark it as fix release in juju-core? 
[09:32] <_mup_> Bug #1160971: WebSocket disconnects when an invalid request is sent <juju-core:New> <juju-gui:Fix Committed> <https://launchpad.net/bugs/1160971>
[09:33] <rogpeppe> frankban: cool. i thought it probably was but your pastebin has disappeared so wanted to check with you
[09:33] <rogpeppe> frankban: it's incredibly annoying that pastebin has lost everything
[09:33] <frankban> rogpeppe: yes, it's not a reliable tool for this kind of things
[09:34] <rogpeppe> frankban: tbh i think they have a responsibility to keep all the pastes around
[09:34] <rogpeppe> frankban: they're a specific kind of history and really quite important
[09:36] <frankban> rogpeppe: I agree, IIRC there was some discussion in some ml about this issue.
[09:37] <frankban> rogpeppe: anyway, marking it as "fix released" if you agree.
[09:37] <rogpeppe> frankban: in particular a lot of IRC discussion logs will be less useful without the pastes
[09:37] <rogpeppe> frankban: sgtm
[09:39] <frankban> rogpeppe: cool. oh, and congrats for your spotlight award, you deserved it! :-)
[09:39] <rogpeppe> frankban: thanks!
[09:39] <rogpeppe> frankban: you guys have been awesome too
[09:40] <frankban> :-)
[11:42] <rick_h_> anyone know what the config is on the charm to not have it ask for the password? I'm not seeing a config option for that. 
[11:46] <benji> rick_h_: as far as I can tell if you deploy to py-juju and set "staging" to true in the config, then it shouldn't request a password
[11:47] <rick_h_> benji: cool, /me goes to try
[11:48] <rick_h_> cool though, first time I've deployed juju-gui and into an environment with our charmworld stuff 
[11:49] <rick_h_> sweet https://ec2-54-224-200-253.compute-1.amazonaws.com/bws/fullscreen
[11:50] <rick_h_> gary_poster: so this is a juju-gui using svg image links back to charmworld serving the svg image files working. 
[11:50] <rick_h_> gary_poster: still no gzip, but I think it works out well
[11:52] <rick_h_> thanks benji, worked
[11:52] <benji> cool
[11:52] <rick_h_> <3 using uistage to look up charm config options and descriptions lol
[11:52] <rick_h_> dogfooding!
[11:52] <benji> :)
[12:09] <gary_poster> rick_h_, yeah, way better!
[12:10] <rick_h_> gary_poster: I think so. I'll bring it up in our stand up for review from others and then we'll see about breaking the work down into backend/front end cards
[12:10] <gary_poster> cool
[12:11] <rick_h_> and this has the charmworld server doing the correct trimmed OPTION request, so 231B pre-flight with 158K of data 
[12:11] <rick_h_> so much better than over 1M
[12:12] <gary_poster> cool, rick_h_.  If you cache for switch between full and sidepanel then I think that will be a pretty good resolution
[12:12] <gary_poster> I mean, the combined package
[12:12] <rick_h_> gary_poster: right
[12:14] <gary_poster> rick_h_, so is that instance trunk, or a custom branch of yours?  I could update the sandbox version and then we could have this behavior on the demo if you want--and the sandbox will make it feel asnappier also
[12:15] <rick_h_> gary_poster: it's a custom branch of charmworld and juju-gui that just implemented a quick hack to proof it out
[12:16] <gary_poster> rick_h_, ok cool
[12:16] <rick_h_> gary_poster: so we have to go back and add the feature to charmworld, with tests, etc. and the front end
[12:16] <rick_h_> I actually really like this 'create a branch, hack feature in, launch charms, point at hack branches...test'
[12:17] <rick_h_> really kind of cool to A/B ish feature test
[12:17] <gary_poster> add feature and tests: yeah, understood rick_h_ .  Is that a "by the end of this week" thing, if it were prioritized, do you think rick_h_ (understanding that it might not be prioritized and your estimate might be wrong and la la la la) ;-)
[12:18] <gary_poster> rick_h_, cool to test with: agree.  lightweight deployment is very nice.  makes me want it even more lighter weight :-) particularly for iterative development and testing
[12:18] <rick_h_> gary_poster: I'll ask in the stand up. I think since it can make the demo better it will be my/abentley's goal for today, but not sure
[12:18] <gary_poster> cool
[12:19] <rick_h_> gary_poster: I do need a hand from someone in debugging an issue I've got that only shows in prod mode. however, when I try to run make prod I get 404's vs the app
[12:19] <gary_poster> huh
[12:19] <rick_h_> gary_poster: just at some point today if someone is experienced in how prodmode is setup/diff
[12:19] <gary_poster> rick_h_, yeah I know that.  now's about as good time as I'll get.  If we can't figure it out quickly I can hand it off
[12:19] <rick_h_> https://bugs.launchpad.net/juju-gui/+bug/1175183 only happens in production mode, but running that locally would 404 when I go to 127.../bws/fullscreen and such
[12:19] <_mup_> Bug #1175183: Filters checkboxes should not act as radio buttons <charmbrowser> <juju-gui:In Progress by rharding> <https://launchpad.net/bugs/1175183>
[12:19] <gary_poster> I mean, I know about that
[12:20] <gary_poster> ah
[12:20] <gary_poster> yeah
[12:21] <gary_poster> prod mode is simply dumber atm, in that the backing webserver can't serve index.html from arbitrary urls
[12:21] <gary_poster> so quick hack: 
[12:21] <gary_poster> merge your "charmbrowser defaul" branch and debug
[12:21] <rick_h_> ah, gotcha. makes sense. 
[12:21] <gary_poster> alternative, maybe quick hack:
[12:21] <rick_h_> thanks, will do
[12:22] <gary_poster> look at devel and try to switch that to serve prod temporarily
[12:22] <gary_poster> cool
[12:36] <gary_poster> benji, if you want to talk about memory, I have about 10 or 15
[12:36] <benji> gary_poster: sounds good.  the regular place?
[12:36] <gary_poster> sure benji
[12:39] <bac> hi rick_h_, thanks for your email and explanation
[12:40] <bac> rick_h_: upon further investigation i did see that the <input> fields on the charm panel have a line-height and height of 18px, so it is working just fine
[12:40] <rick_h_> bac: np, thinking it's the generic css rules from input -> textarea getting in the way if I'm lokoing at the right spot
[12:40] <bac> rick_h_: and those are the ones we're trying to match
[12:40] <rick_h_> bac: yep, that's what I was going to add today. I missed putting line-height in those css notes
[12:40] <rick_h_> so font-size, line-height, padding, border all come into the combined height you end up getting
[12:41] <bac> rick_h_: there is a problem with the service settings page, though.  if you still have my branch could you add haproxy and then look at http://localhost:8888/:gui:/service/haproxy/config/  when you have time?
[12:41] <rick_h_> bac: I can pull it back down. give me a few. 
[12:48] <rick_h_> bac: ok, loaded and on that url
[12:48] <bac> so if you look down at service, one of the last ones
[12:49] <rick_h_> k
[12:49] <rick_h_> bac: ok, so this should be opened up?
[12:49] <bac> rick_h_: you'll see it is a single line, though it is populated with multi-line data.  a keypress in there will cause it to expand
[12:49] <bac> righto
[12:49] <rick_h_> k, /me goes and looks at code/etc for a bit
[12:50] <bac> i'm stepping through the resize() method called at the end of the initializer now.  that is where it is supposed to get expanded
[12:51] <rick_h_> bac: right, but in resize it checks for single_line and trumps the height in that first if condition I'd expect
[12:51] <bac> rick_h_: ah, i think maybe _prev_scroll_height should not be initialized to 0
[12:52] <bac> rick_h_: i see this behavior whether using single_line or now
[12:52] <bac> not
[12:52] <rick_h_> bac: so this was built to work with the inline editor such as the bug title, so that a single line would expand only when you were editing
[12:52] <bac> rick_h_: funny thing is it works in charm panel when using single_line
[12:52] <bac> in this view it does not work either way
[12:52] <rick_h_> bac: k, looking
[12:57] <rick_h_> ugh, multi dispatch FML. Goes through this debug code so many times
[12:58] <rick_h_> bac, what view is doing the initial work here? loading plugging the textareas?
[12:58] <rick_h_> bac: actually, want to chat for a second?
[12:59] <bac> sure
[12:59] <rick_h_> bac: looks like the normal hangout is taken, sec 
[12:59] <bac> k
[13:00] <rick_h_> bac:  https://plus.google.com/hangouts/_/439096b6bd109b21f6137274b06438e42739fdb0?authuser=0&hl=en
[13:38] <gary_poster> rick_h_, I think I LGTM'd everything from Huw
[13:38] <rick_h_> thanks gary_poster 
[13:39] <gary_poster> welcome
[13:44] <bac> hi gary_poster -- the integration with the resizing textarea is going well.  it works in the charm panel but is not happy in the service settings view.  rick and i know what's going on and i'm chasing it down.
[13:44] <gary_poster> awesome bac!
[13:44] <gary_poster> thanks for heads up
[13:55] <rick_h_> bac: after I cleared my browser 100x I did get it to hit those debuggers but the Y.Array.each wasn't seeming to get hit. 
[13:55] <bac> rick_h_: similar here
[14:02] <rick_h_> bac: bah, you don't need to Y.Array.each a nodelist, you should be able to just do view.tareas.each(...
[14:02] <bac> rick_h_: i'm confused.  when the break point hits, view.tareas is an array with 12 elements.  the breakpoint inside the .each never hits, though
[14:02] <rick_h_> bac: if you get a sec try that. If not I'll give it a go after I get this stuff landed for huw
[14:06] <bac> rick_h_: that works if you do  tarea.resizingTextarea.resize(); -- the plugin must be included
[14:06] <rick_h_> bac: ah! awesome
[14:07] <rick_h_> bac: so at least a hack can make it work then. Might check with hatch or someone more up on showView() to see if there's a better place to hook into. A 'rendered' event or something. Otherwise, this gets around the issue at least
[14:07] <hatch> whaaaadauuupppp
[14:08] <bac> hey hatch
[14:08] <rick_h_> beetlejuice ... beetlejuice ...
[14:08] <hatch> BEETLEJUICE!!!!!!
[14:09] <bac> so in services.js views.service_config there is a container that i'm using to add the resizing textarea plugin
[14:10] <bac> hatch: all well and good, but that container has not yet been added to the DOM, so the initial size computations are all zero
[14:11] <rick_h_> hatch: I couldn't figure out how/when showView() from _buildServiceView() actually put the thing in the DOM
[14:12] <rick_h_> hatch: in app.js, so we put some hack code into the callback for post-showView() but feels hacky
[14:12] <bac> hatch: http://paste.ubuntu.com/5625996/
[14:13]  * hatch creates a card for everyone to use gist.github.com so we can have editing and syntax highlighting
[14:13] <hatch> ;)
[14:13] <rick_h_> hatch: replies!
[14:14] <rick_h_> paste.mitechie.com :) lodgeit ftw
[14:14] <hatch> sorry I had to run and take the garbage out....not that it mattered I missed the damn truck
[14:14] <hatch> gists are mini git repos, nothing beats that :)
[14:15] <hatch> bac: rick_h_ so that's how you're supposed to do it - th eonly change I would do is have a method you call in the view to do that each()
[14:15] <rick_h_> hatch: yea, makes sense. view.fixTextAreas()
[14:15] <hatch> haha - well....instantitateTextAreas :P
[14:16] <rick_h_> view.inTheDippyDomNow()
[14:16] <rick_h_> :P
[14:16] <hatch> view.lickyBoomBoomDown
[14:16] <hatch> view.informer
[14:17] <hatch> view.blam
[14:17] <hatch> name that song! first person wins 1 internet
[14:20] <benji> no, not Snow, anyone but Snow
[14:20] <rick_h_> lol
[14:21] <rick_h_> that just makes me want to start 'ice ice baby'ing around the house 
[14:21] <bac> rick_h_, hatch: yeah perhaps we should not attach the plugin until after showview
[14:21] <benji> I'll take two Vanilla Ices (Icies?) over Snow
[14:21] <rick_h_> bac: or that. 
[14:21] <hatch> http://www.youtube.com/watch?v=NtILxBszyf8
[14:21] <benji> Especially now that he is a general contractor with a renovation TV show
[14:21] <hatch> I want those sunglasses
[14:21] <hatch> lol
[14:22] <hatch> benji: haha really?
[14:22] <benji> yep
[14:22] <benji> who saw that career change coming?
[14:23] <benji> hatch: https://www.youtube.com/watch?v=IrNiiNRCvYo
[14:23] <hatch> vanilla ice !== snow :)
[14:24] <hatch> oh
[14:24] <hatch> sorry too early
[14:24] <hatch> missed the convo changing tracks
[14:24] <hatch> :)
[14:28] <hatch> jujugui - has anyone looked into these CI failures? I think this one is fixable
[14:29] <gary_poster> hatch, I tried yesterday.  sent email.
[14:29] <hatch> 2013-05-02 14:27:27,704 DEBUG openstack: 400 '{"badRequest": {"message": "Can not find requested image", "code": 400}}'
[14:29] <hatch> oh woops sorry I'm 100+ behind in my emails
[14:29] <gary_poster> hatch, we must fix it.  make distfile might be broken?
[14:30] <hatch> possible, I'll grab my laptop and log into it
[14:30] <hatch> see what I can do to fix it
[14:32] <gary_poster> hatch make distfile works on trunk.  this is on charm apparently.  do you know where to find the right image numbers offhand?
[14:32] <gary_poster> if you can fix CI, teknico is looking at broken charm
[14:32] <hatch> isn't that euca-describe-images or something
[14:32] <hatch> was just looking it up
[14:32] <gary_poster> hatch something like that but then you have to know which one to choose of a zillion
[14:33] <hatch> I'll pick the one with the coolest name
[14:33] <gary_poster> heh
[14:33] <hatch> honestly I was going to see what the old one was and try and find something similar
[14:35] <frankban> gary_poster, hatch, teknico: it seems that make distfile is broken in trunk: http://pastebin.ubuntu.com/5626062/
[14:35] <hatch> oh ok
[14:35] <gary_poster> frankban, worked for me after make clean.  maybe make clean-all is necessary to trigger
[14:36] <frankban> gary_poster: oh, trying
[14:38] <hatch> ok well if you guys are on it i'll get back to gui stuff
[14:38] <frankban> gary_poster: still an error
[14:38] <gary_poster> hatch, multiple problems
[14:38] <gary_poster> hatch if you can fix image name that would be fanulous
[14:38] <gary_poster> fabulous even
[14:38] <frankban> (make clean-all && make distfile)
[14:39] <hatch> ohh ok
[14:39] <gary_poster> frankban, weird.  I got a fresh branch and WFM.  Raring, yeah?
[14:39] <rick_h_> gary_poster: FYI manage.j.c is updated with fixes to the OPTIONS request and gzip is now enabled so tinyurl.com/jujucharms should hurt less. 
[14:39] <frankban> gary_poster: yes, trying on a branch
[14:39] <gary_poster> frankban, and the failure was the same as before ?  " bin/py: File removed before we read it" is weird error
[14:40] <frankban> gary_poster: yes
[14:40] <gary_poster> rick_h_, awesome thanks.  once fires are out I'll also update tinyurl.com/jujucharms
[14:46] <hatch> hmm I cannot remember how we specify the image to use
[14:46] <gary_poster> hatch in ~/.juju/environments.yaml
[14:47] <hatch> ohh right right
[14:50] <hatch> umm....image id's are in the format aXi-XXXXXXXX - the one in the env.yaml looks like a hash of some type
[14:51] <hatch> or am I missing something here?
[14:51] <frankban> gary_poster: it was a local problem: bin/py broken symbolic link in my trunk branch, not removed by make clean-all
[14:51] <gary_poster> frankban, ah ok cool.
[14:52] <hatch> so as far as images go - do we want 64bit raring?
[14:52] <gary_poster> hatch no
[14:52] <gary_poster> we want 64 bit precise
[14:52] <hatch> or stay with 12.04?
[14:54] <hatch> does anyone have any idea how that id got changed?
[14:54] <gary_poster> hatch 12.04
[14:55] <gary_poster> hatch the id changed probably because they have improvements to the image
[14:55] <gary_poster> newer sources
[14:55] <gary_poster> that sort of thing
[14:55] <hatch> no I mean they aren't even in the same format
[14:55] <hatch> the one in our env.yaml is a huge hash
[14:55] <hatch> not the format of the image id's
[14:56] <hatch> hmph who knows I'll keep it just in case
[14:57] <gary_poster> hatch, sorry, trying to get over at the machine to look.  have a call in 3
[14:57] <gary_poster> and was just off another call
[14:57] <hatch> sure np - I am just looking through the list of images
[14:57] <hatch> I think we want ubuntu-released image?
[14:57] <hatch> sounds like it would make the most sense :)
[14:58] <gary_poster> yes hatch I think so.  Although if it has "smoser" in the name it is fine too I think
[14:58] <hatch> there are those too but they are further down - I'll try this one for now
[14:58] <gary_poster> ok
[15:00] <hatch> ok id updated and new build kicked off
[15:00] <hatch> really wondering how that id got changed
[15:05] <hatch> hmm now it's saying invalid image ref provided
[15:05] <gary_poster> hatch http://10.189.74.2:8080/job/jujugui-test-charm/385/console
[15:05] <hatch> I'm confused...
[15:05] <gary_poster> not good image
[15:06] <hatch> ok will try the smore one
[15:07] <teknico> here are some charm changes, I'd like a few eyes on it, possibly frankban's, and bcsaller_'s when he's around: https://codereview.appspot.com/9121043/
[15:07] <teknico> I even did a pre-review of sorts to help you out :-)
[15:07] <hatch> kicked off build again
[15:08] <frankban> teknico: will do
[15:08] <teknico> frankban, thanks
[15:09] <hatch> ok invalid image ref again...it must not like the id format
[15:09] <hatch> so I need to somehow associate the id in the euca list to some hash?
[15:10] <hatch> according to the canonistack documentation it's the proper ID format
[15:11] <hatch> checking in #canonical-support
[15:12] <hatch> orr..... matsubara you around?
[15:12] <matsubara> hatch, yep
[15:13] <hatch> so we started getting these errors last week
[15:13] <hatch> DEBUG openstack: 400 '{"badRequest": {"message": "Can not find requested image", "code": 400}}'
[15:13] <hatch> and when I view the environments.yaml file the ID is a large hash
[15:13] <hatch> but when I change it to a proper ID it gives me an invalid ref id
[15:13] <hatch> ERROR Unexpected 400: '{"badRequest": {"message": "Invalid imageRef provided.", "code": 400}}'
[15:13] <matsubara> hatch, deploying on canonistack?
[15:13] <hatch> yeah
[15:14] <hatch> so it's like it's expecting a large hash ID not the one that's in euca-describe-images
[15:18] <matsubara> hatch, can you deploy locally from your laptop?
[15:19] <hatch> I can try
[15:19] <hatch> but I'm going to guess no
[15:19] <hatch> heh
[15:21] <hatch> that also has the large hash i'd
[15:21] <hatch> ids
[15:21] <hatch> I can't remember where those came from
[15:21] <hatch> but no - can't find the requested image
[15:21] <matsubara> hatch, sorry, got disconnected. I think smoser knows the id to use. maybe ask on #is?
[15:22] <hatch> ok so it doesn't follow the canonistack documentation on wiki any more?
[15:22] <hatch> the id's from euca-describe-images aren't valid?
[15:23] <hatch> ok I asked him
[15:24] <matsubara> hatch, this is in the env.yaml file for the charmworld project:  default-image-id: bb636e4f-79d7-4d6b-b13b-c7d53419fd5a
[15:25] <hatch> yeah same we have
[15:25] <hatch> which doesn't work
[15:25] <gary_poster> hey hazmat.  https://blueprints.launchpad.net/juju-gui/+spec/servercloud-s-juju-gui-read-only-for-is is the blueprint.  It is for juju-gui.  I think you need a juju-core blueprint.  That will be one that GUI follows
[15:25] <gary_poster> I think I should try to delet the gui one
[15:25] <gary_poster> e
[15:25] <hazmat> gary_poster, ack, thanks
[15:28] <matsubara> hatch, might be a problem on canonistack itself
[15:28] <hatch> just got an id - and an explanation as to what's up
[15:28] <hatch> so /me happy
[15:28] <matsubara> cool
[15:28] <rick_h_> noooooooooo bug in yui makes me sad...well at least lack of support 
[15:29] <hatch> which bug?
[15:29] <gary_poster> hazmat, I was wrong: https://blueprints.launchpad.net/juju-core/+spec/servercloud-s-juju-core-role-based-access-control
[15:30] <gary_poster> have at it :-)
[15:30] <hatch> gary_poster: jenkins is about to shut down so when it's back we'll see if this new ID works...and I also found out why there is a discrepecy and will update the documentation
[15:30] <rick_h_> hatch: working on it. Looks like it has two query string parsers. One in http://yuilibrary.com/yui/docs/api/files/app_js_router.js.html#l994
[15:30] <rick_h_> hatch: and the query string module itself
[15:30] <gary_poster> hatch, and can you also document what to do in the future when this happens? :-)
[15:30] <hatch> rick_h_: keep in mind we have totally bastardized that router code :)
[15:30] <rick_h_> hatch: the one in the router code is dumb and can't handle  querystring: "category=databases&category=file_servers&
[15:30] <hatch> gary_poster: definitely - I was getting frustrated hah
[15:30] <rick_h_> where a key is in there twice to turn into an []
[15:30] <gary_poster> :-) cool
[15:43] <hatch> rick_h_: that's because query strings with multiple of the same keys are technically invalid :)
[15:44] <rick_h_> hatch: but but but 
[15:44] <rick_h_> hatch: it works in dev mode :P
[15:44] <hatch> haha no I agree it's a commonly used feature
[15:45] <rick_h_> hatch: only fails in production so building tests against Y.QueryString and Y.Route atm
[15:45] <hatch> oh really? that's interesting
[15:46] <rick_h_> hatch: http://jsbin.com/efofol/1/
[15:47] <rick_h_> hatch: so for some reason in dev it's using Y.QueryString but in production using Y.Router._parseQuery and thus breaking my filters
[15:47] <rick_h_> hatch: anyway, will ahve to find some way to cheat it when I get back from lunch. bbl
[15:48] <hatch> ohhhhh
[15:48] <hatch> now I see what's going on
[15:50] <gary_poster> juju kanban now please
[15:50] <gary_poster> jujugui I mean
[15:51] <gary_poster> bcsaller, any idea when your branch might land?  if soon I will wait to update tinyurl.com/jujucharms
[15:53] <bcsaller_> gary_poster: I pushed a number of updates a minute ago, I think I if I could get a second review on https://codereview.appspot.com/9070043/ I'm ok with it as an intermediate step
[15:54] <gary_poster> bcsaller_, cool, let's rustle someone up on the call
[15:54] <bcsaller_> redoing the propose now
[15:55] <bcsaller_> gary_poster: did you ever get it to work in practice?
[15:55] <gary_poster> bcsaller_, aigh! no!  doing now.
[15:58] <gary_poster> bcsaller, lol that's *awesome*
[15:58] <bcsaller_> heh :)
[15:58] <gary_poster> bcsaller_, I will have to do a live demo on call :-P
[15:59] <gary_poster> bcsaller_, qa: cannot add or remove relations to imported bits
[16:00] <gary_poster> maybe fixed
[16:00] <gary_poster> but just pulled
[16:00] <gary_poster> oops
[16:00] <gary_poster> jujugui call nowq
[16:00] <bcsaller_> gary_poster: yeah, should work now
[16:05] <bac> jovan2: i'd like you to look at the expanding textareas.  i have an instance coming up at http://ec2-50-19-207-147.compute-1.amazonaws.com and it will be available soon
[16:05] <bcsaller_> https://codereview.appspot.com/9070043/
[16:06] <jovan2> bac: sure
[16:12] <jovan2> bac: pwd?
[16:12] <frankban> Makyo: congrats!
[16:12] <Makyo> Thanks :)
[16:15] <Makyo> I found out this morning we made a couple of the local papers, too, since it was the first day. :P
[16:16] <bac> jovan2: trying to get it
[16:18] <teknico> bcsaller_, frankban, thanks for the reviews!
[16:23] <hatch> LF review for doc update https://codereview.appspot.com/9124043/
[16:24] <gary_poster> hatch, maybe mention how to choose the ids?  look for precise, and...?
[16:24] <hatch> now that the CI is back up we have failures in IE
[16:24] <gary_poster> :-(
[16:24] <hatch> gary_poster: adding
[16:24] <gary_poster> thanks
[16:27] <hatch> gary_poster: proposing
[16:28] <bac> hey rick_h_, could you look at the above ec2 url?
[16:29] <hatch> updated
[16:31]  * bac lunches
[16:33] <rogpeppe> gary_poster: "the Juju API cannot accept a websocket directly (it expects to have to upgrade it)"
[16:33] <rogpeppe> gary_poster: what does that mean?
[16:34] <gary_poster> rogpeppe, it may be no longer relevant,  Where is that? on call
[16:34] <rogpeppe> gary_poster: it's from servercloud-s-juju-core-role-based-access-control
[16:37] <gary_poster> rogpeppe, could you delete? not relevant
[16:39] <rogpeppe> gary_poster: ah actually - i'd missed the fact that that comment was talking specifically about py juju
[16:39] <rogpeppe> gary_poster: so probably still relevant
[16:39] <gary_poster> yes
[16:48] <hatch> bac: did you test your textarea stuff in IE? it looks like it's breaking the CI
[16:48] <hatch> sorry... :)
[16:57] <Makyo> hatch, It hasn't landed yet, has it?
[16:58] <hatch> the video shows a 'textarea' suite failing
[16:58] <Makyo> Was it landed as separate branches, then?
[16:58] <hatch> I can't seem to stop the video to see what the title actually says
[16:58] <hatch> I have no idea
[17:16] <gary_poster> hatch, some of it landed a while ago
[17:16] <gary_poster> specifically some standalone plugin tests
[17:16] <gary_poster> IIRC
[17:17] <gary_poster> the new branch actually integrates it
[17:17] <hatch> ohh ok - looks like it's those tests which are failing in IE
[17:18] <gary_poster> bac, LGTM with comments plus fixing the IE tests from previous checkin
[17:21] <gary_poster> benji did you run the charm tests when you landed?  teknico reported that tests were broken in trunk
[17:23] <gary_poster> frankban, LGTM.  Did deploy tests also fail for you?
[17:24] <frankban> gary_poster: not tried, teknico said they were failing in trunk, I suggested to handle that in another card. I can check it tomorrow
[17:24] <gary_poster> ok thanks frankban.  have a good evening
[17:24] <frankban> gary_poster: you too!
[17:30] <gary_poster> bcsaller_, I still cannot add or remove relations on imported services with tip of your branch
[17:31] <bcsaller_> gary_poster: yeah, I loaded the charms so I thought it would work, I'm looking at that now, very odd error
[17:31] <bcsaller_> this.db.charms.get('id')
[17:31] <bcsaller_> ["cs:precise/memcached-6", "cs:precise/wordpress-14", "cs:precise/mysql-19", "cs:precise/mediawiki-8", "cs:precise/haproxy-17"]
[17:31] <bcsaller_> app.db.charms.get('id')
[17:31] <bcsaller_> ["cs:precise/memcached-6", "cs:precise/wordpress-10", "cs:precise/mysql-16", "cs:precise/mediawiki-6", "cs:precise/haproxy-16"]
[17:31] <bcsaller_> where 'this' is the fakebackend
[17:31] <hatch> that's a lot of smiley faces
[17:32] <bcsaller_> hatch: you have a very expressive IRC client
[17:32] <hatch> yeah it even does inline pastebins, images, and autoresolves tinyurls
[17:34] <gary_poster> bcsaller_, weird...so fakebackend is not honoring the service revision
[17:34] <gary_poster> bcsaller_, maybe it can't honor it?
[17:35] <bcsaller_> gary_poster: or they are pulling from the old and the new sources
[17:35] <gary_poster> bcsaller_, because the charm store only offers current versions?  and so the solution is to reconcile?
[17:35] <gary_poster> on the service
[17:36] <gary_poster> bcsaller_, I think that is it: line 325 of fakebackend
[17:36] <gary_poster> this.get('charmStore').loadByPath(
[17:36] <gary_poster>             charmIdParts.charm_store_path
[17:37] <gary_poster> if you go get that json...
[17:37] <bcsaller_> I suspect you're correct
[17:40] <gary_poster> bcsaller_, yup: http://jujucharms.com/charms/precise/wordpress-10/json (look for store_revision and compare with url)
[17:40] <gary_poster> or store_url for that matter
[17:41] <bcsaller_> the the imports are not going be the current version much of the time anyway
[17:41] <gary_poster> yeah
[17:41] <gary_poster> arguably would be more reliable if they were
[17:41] <bcsaller_> but its not quite like pinning a package version
[17:41] <gary_poster> in terms of backwards compatibility
[17:42] <gary_poster> it kind of should be
[17:42] <bcsaller_> within a series the assumption has been that current == best
[17:42] <gary_poster> no guarantee that config will be the same across revisions, or relations, or...
[17:42] <gary_poster> but that's not an option right now anyway
[17:43] <gary_poster> I think we ought to continue to ask for what the import specifies, but update the service to the charm we actually get and hope for the best
[17:43] <bcsaller_> yeah, npm styled specs in the charm for revisions might be nice some day, an export format that could say charm: "cs:precise/wordpress >= 10"
[17:43] <gary_poster> yeah
[17:44] <bcsaller_> I can do an inplace upgrade for now, yeah
[17:44] <gary_poster> cool
[17:49] <gary_poster> bcsaller_, the new promise code is not working in fakebackend.  charms are being loaded because of the GUI side endpoints code
[17:50] <gary_poster> bcsaller_, to demonstrate put breakpoint in line 1253 (if (s.name && !s.id)) in fakebackend
[17:50] <gary_poster> bcsaller_, s.id is always set
[17:50] <gary_poster> so _promiseCharm never called
[17:50] <gary_poster> at least with sample-fakebackend.json
[17:51] <hatch> is this something I did?
[17:51] <bcsaller_> hmm, sounds like I've got some digging to do
[17:51] <hatch> I saw promise and charm
[17:51] <gary_poster> hatch no, all's good
[17:51] <hatch> alright
[17:51] <bcsaller_> hatch: no :)
[17:51]  * hatch goes back to his cave :)
[17:51] <gary_poster> heh
[17:52] <bcsaller_> gary_poster: I've updated the tests to check that the charms are loading, and those are passing, not sure how much of that I changed since the last push, but I'll verify what you're seeing 
[17:52] <gary_poster> ok cool
[17:53] <bcsaller_> ha, well, the initial demo is cool anyway ;)
[17:54] <gary_poster> :-) only small bugs bcsaller_ , no biggie
[18:00] <benji> gary_poster: (back from lunch) I can't say I specifically remember running the tests, but I would hope I did.
[18:02] <gary_poster> heh
[18:04] <gary_poster> benji, looks like it was bad and it may be worse: just got a report that the charm is now broken, possibly after teknico's commit.  Could you join me on guichat and we can work together for a bit?  This is an emergency (and our process surrounding the charm is a big lose, obviously :-( )
[18:05] <benji> gary_poster: sure, be right there
[18:05] <gary_poster> thx
[18:23] <hatch> gary_poster: whenever you have a moment if you could QA and review https://codereview.appspot.com/9132043/  that would be awesome :)
[18:23] <hatch> sorry it's a rather large diff
[18:24] <hatch> well....lots of files
[18:24] <hatch> oh poo
[18:25] <hatch> for some reason it didn't diff against the most recen't trunk
[18:25] <hatch> ill try again
[18:25] <gary_poster> hatch ok ping when ready
[18:29] <hatch> gary_poster: ok it's done
[18:33] <rick_h_> hatch: jcsackett or sinzui can I get some +1s on a 1 line change that took a day to figure out please? https://codereview.appspot.com/9101043
[18:33] <rick_h_> oops
[18:33] <rick_h_> well I guess it still works
[18:33] <hatch> woah woah woah....false advertising
[18:33] <hatch> that's clearly a 6line change
[18:34] <rick_h_> comments don't count :P
[18:34] <hatch> haha
[18:34] <rick_h_> I should get bonus points for avoiding explitives in my comments :)
[18:34] <hatch> I don't think the description matches the fix though?
[18:35] <sinzui> rick_h_, Thank you for the explanation for the zaniness
[18:35] <rick_h_> ? querysting listed before juju-gui in the use() block?
[18:35] <rick_h_> hatch: how so?
[18:36] <hatch> maybe I'm missunderstanding them "it looks like perhaps there is some extra render going on..."
[18:36] <hatch> should the description not reflect the fix?
[18:37] <rick_h_> hatch: ah, right forget that
[18:37] <rick_h_> that was the "oops'
[18:37] <hatch> ohhh
[18:37] <rick_h_> I had taken a first stab at the fix the other day
[18:37] <rick_h_> and used the same branch name on accident
[18:37] <hatch> ahhh
[18:37] <hatch> ok lgtm'd
[18:38] <rick_h_> thanks
[18:39] <sinzui> rick_h_, I added my LGTM. I think you are free to land
[18:39] <rick_h_> sinzui: thanks
[18:48] <benji> gary_poster: I'm getting test failures, but I think they are a local problem:
[18:48] <benji> WebDriverException: Message: 'Can\'t load the profile. Profile Dir: /tmp/tmpR9aoJc Firefox output: Xlib:  extension "RANDR" missing on display ":1015".\n*** LOG addons.xpi: startup\n*** LOG addons.xpi: checkForChanges\n*** LOG addons.xpi: No changes found\n' 
[18:49] <gary_poster> benji http://jujugui.wordpress.com/2013/04/27/rarings-selenium-doesnt-like-rarings-firefox-my-solution/
[18:49] <bac> bcsaller_: i've got to go figure out how i've broken CI.  i'm not going to be able to review your branch very soon.  you may want to scare up someone else.  sorry.
[18:50] <bcsaller_> bac: np, thank you
[18:50]  * benji looks.
[18:51] <jcsackett> hatch: can i get you to look at https://codereview.appspot.com/9131043/
[18:51] <jcsackett> dammit.
[18:52] <jcsackett> buffer error, that's ricks.
[18:52] <jcsackett> or never mind, those are just *very* similar IDs.
[18:52] <rick_h_> jcsackett: yea, that's the one I reviewed so all good
[18:53] <jcsackett> rick_h_: yeah. hatch, can you give it the other look?
[18:53] <hatch> yu[
[18:53] <hatch> on it now
[18:54] <rick_h_> man I <3 usb3 
[18:54] <rick_h_> "i'd like to backup ~ ... ok good"
[18:57] <hatch> gary_poster: for some reason it's picking up that test_model_controller.js is  anew file when in fact it's in trunk but I merged it in from it's branch before it was landed...so you can disregard that one if you like
[18:58] <gary_poster> ok
[19:05] <hatch> benji: you're reviewing bcsaller_'s branch?
[19:06] <benji> hatch: nope, but I can if need-be
[19:06] <hatch> oh no I ust saw you say 'looks'
[19:06] <hatch> I can do it if one is still needed
[19:07] <benji> hatch: have at it
[19:07] <hatch> bcsaller_: what's the link?
[19:07] <bcsaller_> https://codereview.appspot.com/9070043/
[19:07] <bcsaller_> and thanks
[19:08] <hatch> holy poo that's a large diff
[19:08] <hatch> :P
[19:08] <bcsaller_> its not actually that big, mostly new charm data for the tests I think
[19:08] <bcsaller_> and you'll get to see what all that charm/promise talk was about
[19:08] <gary_poster> hatch, your code is good but your diff is bad: A fix for /:gui:/ will come in a later branch?
[19:09] <benji> gary_poster: I'm getting this error after doing the virtualenv thing, does it ring any bells?
[19:09] <hatch> oh wow it's a lot worse than I thought...
[19:09] <benji> Traceback (most recent call last):
[19:09] <benji>   File "./deploy.test", line 9, in <module>
[19:09] <benji>     from selenium.webdriver import Firefox
[19:10] <hatch> gary_poster: any thoughts on how to fix this diff?
[19:10] <hatch> it's like it's not diffing from trunk
[19:11] <hatch> info shows that it's parent is /trunk though
[19:11] <gary_poster> hatch, in your shoes I'd re branch master, merge your existing branch, and repropose from that.  That's lazy but I don't have tim eto figure anything else out atm :-)
[19:12] <hatch> so branch trunk, merge my branch into that?
[19:12] <hatch> I can try that
[19:12] <gary_poster> hatch y
[19:12] <gary_poster> benji, no.
[19:12] <gary_poster> benji more info from reporter
[19:12] <benji> hmm
[19:12] <benji> <eyebrows raised>
[19:13] <gary_poster> benji, you saw on #webops?
[19:13] <benji> nope, looking now
[19:13] <benji> gary_poster: I'm not in #webops
[19:13] <gary_poster> benji, oh because of eyebrows I thought maybe so
[19:14] <gary_poster> benji: 
 gary_poster: https://pastebin.canonical.com/90418/ to prepare the charm, then https://pastebin.canonical.com/90419/ as the config
[19:14] <benji> my eyebrows are easily misunderstood
[19:15] <gary_poster> :-)
[19:15] <gary_poster> benji, he's doing something weird.  I'll handle it. :-)  you see if you can wrap up something on your other work
[19:16] <benji> gary_poster: ok.  do you want me to abandon trying to run the jitsu tests for the charm?
[19:18] <gary_poster> benji, um.  up to you.  We must be able to run tests.  So that needs to be done.  OTOH, if you might have something actionable from your memory work in the remaining time it would be great to do that too.
[19:18] <benji> ok,  I don't know what the odds of actionable results are, but keeping doing what I was doing seems like the best route
[19:19] <hatch> gary_poster: ok this diff is much better https://codereview.appspot.com/9119044/ I can apply your changes to this branch so you don't have to do another review/qa
[19:19] <gary_poster> cool hatch, apply the changes then ping me and I will look
[19:19] <gary_poster> benji ack, go for it
[19:23] <hatch> sounds good
[19:42] <hatch> bcsaller_: review done
[19:46] <bcsaller_> hatch: thanks
[19:46] <gary_poster> hatch are changes applied or should I go to next call?
[19:47] <hatch> gary_poster: continue on - I just started after doing ben's review
[19:47] <gary_poster> cool hatch thx
[20:01] <hatch> gary_poster: changes are made and pushed to https://codereview.appspot.com/9119044/ I'm going to take lunch now
[20:03] <Makyo> Got a confirmation that I'll be working from a local co-working place tomorrow in the AM.  During the final few minutes of our meeting time , so I'll try to get there early.
[20:04] <Makyo> At least one other Canonical-er there, figure it's worth a try.
[20:04] <Makyo> Three, looks like.
[20:13] <hatch> Id have a 20minute drive to get to a co-working place here....not gona happen
[20:13] <hatch> :D
[20:14] <hatch> bac: did you see that your latest commit failed CI? Was that one from before the IE fixes?
[20:15] <bac> hatch: there are no ie fixes yet
[20:15] <hatch> ahh ok cool
[20:15] <bac> so it is expected
[20:32] <gary_poster> hatch looking now.  what's the story for :gui:/ environment registration: follow-on branch?  apologies if you already responded, but I didn't see it
[20:35] <gary_poster> nm hatch I see in code :-)
[20:35] <hatch> alright :)
[20:41] <jcsackett> rick_h_: you still around?
[20:41] <rick_h_> jcsackett: kinda, what's up?
[20:42] <jcsackett> i was an idiot and submitted that filter-string fix branch, which is blocked on aaron's code. i have a branch that reverts it, but my lxc won't load, which means i can't propose/submit.
[20:43] <jcsackett> was wondering if i could get you to help me get it through.
[20:43] <jcsackett> but if you're EoDing, perhaps hatch can help.
[20:43] <rick_h_> jcsackett: so, I'd ask if abentley's branch is going to land tomorrow. It landing isn't an issue atm since the browser is 'feature flag'd' behind the urls
[20:43] <jcsackett> rick_h_: ah, there is that.
[20:43] <rick_h_> jcsackett: the issue is only that searches will fail with categories due to upstream
[20:43] <rick_h_> nothing really 'breaks'
[20:44] <rick_h_> we just have to watch for the demo and if abentley will have a migration/final update to manage. tomorrow then all is good
[20:44] <rick_h_> jcsackett: but if you'd like to revert, shoot me the revert branch and I'll put it down and lbox it up
[20:44] <jcsackett> rick_h_: given what you've very sensibly pointed out, it's not a rush.
[20:45] <jcsackett> if aaron can't land his changes tomorrow, i'll land the revert then.
[20:45] <abentley> rick_h_, jcsackett: The charmworld change is nearly done.  Then I have to do the charm change, which should be fast.
[20:45] <rick_h_> jcsackett: rgr 
[20:45] <rick_h_> abentley: awesome, good to hear. 
[20:45] <jcsackett> abentley: you're a hero. :-)
[20:45]  * jcsackett totally forgot abentley was in this channel. :-P
[20:46] <jcsackett> rick_h_: have a nice evening, and good luck with raring upgrade tomorrow. my LXC woes are part of my upgrade. :-P
[20:46] <rick_h_> jcsackett: was just about to reboot to my usb device when you ping'd. Why I said I was 'kinda' around :)
[20:46] <jcsackett> rick_h_: i will delay you no more. :-)
[20:47] <rick_h_> jcsackett: good news is I've not lxc'd on this to date so hopefully avoid some of that
[20:47] <rick_h_> but definitely hoping to lxc/local juju it up on the new desktop when I get back 
[20:47] <rick_h_> so :/
[20:47] <jcsackett> i think it's upgrade borked my setup. if you don't have a setup yet, maybe no problems.
[20:48] <rick_h_> jcsackett: yea, I'm a reinstall fan myself. backed up to NAS, external portable usb3, and boom goes the OS
[20:48] <jcsackett> rick_h_: yeah, i'm worried i'll need to reinstall now. but i'll spend some time seeing if i can figure out what's broken.
[20:56]  * Makyo -> dogwalk
[21:02] <gary_poster> hatch trying to qa. two conflicts with trunk; resolution is not entirely trivial. I'll share.
[21:02] <hatch> that's interesting - I merged it into trunk to get that diff and didn't get a conflict
[21:05] <gary_poster> hatch, new textarea integration code is conflict.  help me resolve this quickly on guichat?
[21:05] <hatch> ok sure thing
[21:20] <bac> gary_poster: CI "fix" is at https://codereview.appspot.com/9128044
[21:20] <bac> gary_poster: need any help with conflict?
[21:20] <gary_poster> bac, nah was pretty easy thank you
[21:21] <bac> gary_poster: cool.  ping me if you get to that review
[21:21] <gary_poster> bac review done
[21:27] <hatch> bac: lol "fix"
[21:30] <hatch> *sigh* back to the file watching errors
[21:31] <hatch> I thought those were behind me
[21:31] <hatch> :/
[21:31]  * Makyo back.
[21:32] <hatch> gary_poster: I can't reproduce the same bug - but when I try I get console errors....so that's almost better :)
[21:33] <hatch> oh
[21:33] <hatch> lol
[21:33] <hatch> gary_poster: did you var attachPlugins = function(view) { <----- pass the view into this function?
[21:34] <gary_poster> hazmat, one more move of that blueprint fwiw, to match rules: now https://blueprints.launchpad.net/juju-core/+spec/s-cloud-juju-role-based-access-control
[21:34] <hatch> I think we both missed that ;)
[21:34] <hazmat> gary_poster, thanks for the update
[21:34] <gary_poster> welcome
[21:34] <gary_poster> hatch, http://pastebin.ubuntu.com/5627317/ I think it is right
[21:35] <hatch> oh yeah - when I do that it works fine
[21:35] <hatch> heh
[21:35]  * hatch closes bug - unable to reproduce
[21:35] <gary_poster> ok
[21:35] <hatch> I'll try in chrome ubuntu
[21:36] <hatch> hmm
[21:36] <gary_poster> back later
[21:36] <hatch> gary_poster: yeah I can't reproduce...I am wondering if it's a race condition
[22:00] <hatch> wth same jenkins error?
[22:02] <hatch> investigating
[22:06] <hatch> fixed image id and set another build
[22:08] <hatch> we'll need to keep an eye on CI error messages - if we notice the image id error any more we might need to create our own image so that it's not changed.
[22:08] <hatch> bcsaller_: thanks for the review
[22:08] <bcsaller_> np
[22:11] <hatch> bcsaller_: mind doing me a favour and building this branch and then visiting a url? https://code.launchpad.net/~hatch/juju-gui/promise-conflict
[22:12] <hatch> the url is /:gui:/unit/mysql-5/  and it should dump you to the service view with 3x notifications
[22:13] <hatch> gary gets a loading screen and it works fine for me on all my devices
[22:14] <hatch> so I'm wondering if it's a race condition that I'm not seeing
[22:14] <bcsaller_> hatch: doing it now
[22:14] <hatch> thanks
[22:17] <hatch> yay CI passed IE tests again
[22:19] <bcsaller_> hatch:  I fired up improv while the server was running and it connected and then bounced to the service view. After that I re-entered the url, pressed enter, got the three notifications and sit on the loading screen, it might depend on if the 1st delta has happened or not at the time of the view resolution
[22:19] <hatch> hmm
[22:19] <hatch> well I definitely can't land it as it is
[22:20] <bcsaller_> because the db will be empty initially 
[22:20] <hatch> ahhh I think I know why
[22:20] <hatch> even though we have promises we are still relying on the db change event
[22:20] <hatch> to re-fire them
[22:20] <hatch> poop
[22:22] <bcsaller_> async promise resolution + url management does sound error prone, unless the ui model is to block with a spinner waiting on the promises
[22:22] <hatch> are you able to reproduce it reliably?
[22:24] <hatch> I am wondering if removing the { update: true } from line 600 in app.js will be enough to fix it
[22:25] <hatch> I am hoping that that will cause a full re-render fixing the problem
[22:26] <bcsaller_> this time it gave me three notifications and then the proper service view, so it is a racce
[22:27] <hatch> thoughts on what to do?
[22:28] <hatch> wait something is really wrong here
[22:28] <hatch> ohh
[22:29] <hatch> maybe adding options.model = db.services.getById(req.params.id) on line 590 before the showview will fix
[22:29] <hatch> either that or removing the { update: true } on 600
[22:31] <hatch> ok I was finally able to reproduce the error
[22:38] <hatch> oh bac is gona be mad....the autosize widget tests fail in FF now
[22:42] <hatch> bcsaller_: whenever you get a moment if you could pull down the latest changes in the promise-conflict branch and see if you can get the error or if my hack has resolved it
[22:42] <bcsaller_> hatch: I was still poking at it so I can do it now
[22:42] <hatch> oh ok great
[22:44] <bcsaller_> hatch: I still get three error notifications, but it seems to redirect to the service page after 3 sucessful tries
[22:44] <hatch> yeah the error notifications will happen until we don't dispatch 3 times on load
[22:45] <hatch> so right now I'm hoping this fixes the race condition
[22:46] <hatch> I reloaded about 20x tmes and couldn't get the loading screen hang with this fix
[22:47] <bcsaller_> yeah, seems better to me as well
[22:48] <hatch> excellent
[22:48] <hatch> that's a relief
[22:48] <bcsaller_> the notifications might be excessive though :)
[22:48] <bcsaller_> hatch: maybe another timeout to spawn that?
[22:49] <hatch> hey....they are the ones trying to access an invalid unit/service :P
[22:49] <hatch> but yeah I suppose that's a reasonable workaround :)