[03:13] <hatch> huwshimi: hey in your proposal for the ie scrollbar you changed the height to auto
[03:13] <hatch> that won't work with the animation
[03:16] <huwshimi> hatch: Oh, let me take a look
[03:16] <hatch> if you want to do that you will have to use the max-height trick
[03:19] <huwshimi> hatch: Actually, I fixed the issue that required the height to be auto anyway
[03:19] <hatch> oh haha ok then!
[03:19] <huwshimi> hatch: The buttons were cut off in Firefox, but the other spacing stuff I did fixed that.
[03:19] <huwshimi> (I originally fixed it by setting the height to auto
[03:19] <huwshimi> )
[03:20] <huwshimi> hatch: I'll push up the revert
[03:21] <hatch> cool, I'll review/qa once that lands
[03:21] <hatch> other than that how has your day been?
[03:22] <huwshimi> hatch: Going a lot better than yesterday :)
[03:22] <hatch> haha fixed the VM?
[03:22] <huwshimi> hatch: Yeah finally, but it look like it'll expire tonight which means setting it up again tomorrow.
[03:23] <huwshimi> hatch: Are there any more IE10 issues you'd like me to take a look at?
[03:24] <hatch> that's actually all of them that I know of
[03:24] <hatch> maybe do a once over to see if you can catch any?
[03:24] <huwshimi> hatch: Sure.
[03:24] <huwshimi> hatch: Change has landed
[03:26] <hatch> awesome thanks
[12:28] <rick_h> jcsackett: did you figure out hte indent thing from yesterday?
[12:42] <frankban> morning bac and benji: when you have time, there is anothe guiserver branch ready to review: https://codereview.appspot.com/13153043 Could you please take a look?
[12:42] <bac> frankban: i'll be glad to in a little while.
[12:42] <frankban> bac: thanks, no rush
[12:49]  * benji sips his coffee and looks at frankban's branch.
[12:50] <frankban> thank you
[12:53] <jcsackett> rick_h: yeah, i was using a different jshint binary for syntastic than our project.
[12:53] <jcsackett> so i just switched which jshint is on the path in my LXC.
[12:56] <rick_h> jcsackett: ah, yea I'm doing the same thing but it was working so :/
[13:00] <jcsackett> jujugui: can someone point me at a design doc that shows how the search bar should exist when the charmbrowser is completely minimized?
[13:02] <rick_h> jcsackett: sec, looking
[13:02] <rick_h> jcsackett: http://dl.dropboxusercontent.com/u/10004366/juju-gui/index.html is the idea from a demo I was looking at for animations
[13:03] <jcsackett> rick_h: huh. we have two separate cards for "search on canvas" and "keep search bar available", but this makes it look like that sort of needs to be done as one thing.
[13:03] <jcsackett> since there's no option for "search for charms in browser while minimized".
[13:04] <rick_h> jcsackett: well, my understanding is the idea that the search box is always visible. And if you use it while minimized, you end up in /sidebar/search
[13:04] <rick_h> e.g. it un-minimizes to show results
[13:05] <jcsackett> rick_h: except that animation shows "Search in canvas" when we minimize.
[13:05] <jcsackett> ...not even really sure why, though i guess that's vaguely useful when you have an environ with a lot of charms.
[13:05] <rick_h> jcsackett: oh right, yea that's a second feature
[13:05] <rick_h> to be able to search and load things from the environment
[13:06] <rick_h> it kind of goes with versioned charms though so that we can load the data for the version deployed? I'm not sure if we want that incrementally or what
[13:06] <jcsackett> rick_h: but we do want to be able to search for things in the browser from minimized, and just load the sidebar when we have results?
[13:07] <rick_h> luca...who's afk would know 
[13:11] <jcsackett> rick_h: ah. well ok then. :-P
[13:11] <rick_h> jcsackett: so I'd start with removing categories from the two viewmodes. then removing filters/updating the results output/charm containers, before going to the search deployed charms or search bar
[13:12] <rick_h> as the 'how search works/is displayed' will be effected in all cases
[13:12] <jcsackett> rick_h: works for me.
[13:13] <jcsackett> rick_h: we're just removing the filter widget from those views, right? and any other bits of interacting code. filters themselves stay for AC.
[13:13] <rick_h> so we're removing the filter UI, and we're not checking for approved results by default. Then we're changing how the search results are displayed. First reviewd in a container and then the rest in another container
[13:13] <rick_h> jcsackett: sec, there's a good bug to look at
[13:14] <jcsackett> rick_h: ok.
[13:15] <rick_h> jcsackett: https://bugs.launchpad.net/juju-gui/+bug/1202306 though I thought abentley had a post in there that had notes. 
[13:15] <_mup_> Bug #1202306: We need an "all" category <juju-gui:Triaged by lucapaulina> <https://launchpad.net/bugs/1202306>
[13:15] <rick_h> jcsackett: of course the end of that is waiting on UX. 
[13:16] <rick_h> jcsackett: but the work still stands to remove the filters, group the results in two sets/containers
[13:16] <jcsackett> rick_h: right, so i'll start a branch that kills the filter widget from the views.
[13:16] <rick_h> jcsackett: k, but the display has to go along with it so that we can use the results. 
[13:17] <rick_h> because as soon as we remove the default filters the results go to crap
[13:18] <jcsackett> rick_h: i'm not sure i'm following. this bug conversation is all over the place, and i'm only sort of following how it links to what you and i are talking about.
[13:18]  * jcsackett may be having problems because he's not fully awake yet.
[13:18] <rick_h> jcsackett: k, hangout?
[13:18] <jcsackett> rick_h: sure, one sec.
[13:22] <jcsackett> rick_h: hangouts seem to be not so good?
[13:23] <jcsackett> i'm disconnecting b/c i'm getting truly horrid static.
[13:23] <rick_h> jcsackett: died on me, one try
[13:23] <rick_h> jcsackett: one more try 
[13:24] <rick_h> luca: ping, do we have any UX updates on the search UI including the "all" category notes
[13:33] <rick_h> jcsackett: oh, and did my test concern pan out? Or is it working peachy the way it is?
[13:34] <rick_h> jcsackett: because that's more of a 'before this first branch lands' concern
[13:34] <jcsackett> rick_h: i put in the dones, and everything still passes.
[13:34] <jcsackett> so we're good.
[13:34] <rick_h> jcsackett: ok cool. Yea they should pass, just wanted to make sure the asserts were getting hit
[13:34]  * jcsackett nods
[13:34] <rick_h> thanks
[13:34] <jcsackett> yeah, that was a good catch.
[13:35] <rick_h> I did that before where they passed, but never asserted :/
[13:46] <jcsackett> rick_h: i suspect we have several tests like that.
[14:23] <rick_h> jcsackett: so for the record, I just had to update my local jshint as well. Guessing there was some .jshintrc config differences between what I had installed vs the updated one from the repo
[14:23] <rick_h> hatch: let me know when you get a sec. Want to talk this through. 
[14:23] <hatch> sure umm lemme grab a coffee first
[14:24] <rick_h> hatch: definitely, going to need your head unclogged :)
[14:26] <bac> benji: i'm seeing failures in charmworld trunk.  can you pull trunk and run 'make test' and see if you get them?
[14:26] <benji> bac: sure, one sec
[14:32] <hatch> rick_h: guichat?
[14:32] <rick_h> hatch: sure
[14:47] <sinzui> bac: do you have a few minutes to talk about the fix for https://bugs.launchpad.net/charmworld/+bug/1214627
[14:47] <_mup_> Bug #1214627: AttributeError when searching for "precise" <elasticsearch> <oops> <charmworld:Triaged> <https://launchpad.net/bugs/1214627>
[14:48] <bac> sinzui: yes
[14:49] <sinzui> bac, guichat is available
[15:14] <benji> bac: I forgot about my test run until now; everything passed.
[15:14] <bac> benji: ok.  i did a make clean, removing crusty old pyc files and the one problem test passed in isolation.  running them all again
[15:30] <hatch> I see the order of the Featured charms have changed :)
[15:35] <Makyo> jujugui reviews pleeeaase. https://codereview.appspot.com/12744049/
[15:35] <rick_h> Makyo: looking
[15:36] <Makyo> rick_h, thanks.
[15:43] <hatch> Makyo: sure I'll take one
[15:49] <hatch> hey luca could you check out https://comingsoon.jujucharms.com/:flags:/serviceInspector to make sure the inspector passes UX?
[15:50] <Makyo> jujugui call in 10
[15:50] <Makyo> kanban now.
[15:50] <luca> hatch: sure, but won't have time to do it today, is it ok if I do it tomorrow morning (my time)?
[15:51] <hatch> you bet
[15:51] <hatch> do you have IE?
[15:51] <luca> hatch: internet explorer?
[15:51] <hatch> yeah
[15:51] <luca> hatch: I don't, do I need it?
[15:52] <hatch> guess not - we'll just make sure it looks the same in IE as it does in Chrome/FF
[15:52] <rick_h> Makyo: got time after the call to hang on the call and chat about the MP?
[15:52] <luca> hatch: ok
[15:52] <sinzui> bac, .short_url -> .basket_name -> .basket.split() fails because .basket is None. There is a invalid charm in the system without a name, owner, or basket.
[15:52] <Makyo> rick_h, sure.
[15:52] <hatch> luca: thanks, any issues plz email - I want to get it unflagged by the end of the week
[15:53] <bac> sinzui: ahhhh.  so can you delete that bundle?
[15:53] <bac> and provide some defense?
[15:54] <sinzui> bac. I can. I am preparing a query to see if the bad data is also in production
[15:54] <bac> sinzui: i suspect it is
[15:59] <Makyo> jujugui call in 1.
[16:10] <sinzui> bac, The error cannot happen in production because the early ingest error was never in production. I will fix the class, prove it works on staging, then delete the bad bundle from the staging db
[16:11] <bac> sinzui: great
[16:22] <bac> hi adeuring, as i mentioned i'm seeing spurious failures unrelated (famous last words) to the work i'm doing.  they are all tests you added recently in r357.  could you have a look at http://paste.ubuntu.com/6010830/
[16:22] <adeuring> bac: sure
[16:28] <adeuring> bac: where can I find your branch?
[16:29] <bac> adeuring: lp:charmworld/official-bundle-json
[16:29] <bac> adeuring: lp:~bac/charmworld/official-bundle-json
[16:29] <adeuring> thanks
[16:29] <bac> second is correct
[16:31]  * bac grabs lunch
[16:31] <bac> adeuring: how long until your eod?
[16:32] <adeuring> bac: officially, 30 minutes or so
[16:32] <bac> adeuring: ok,ping me if you have any ideas.  thanks.
[16:38] <hatch> Makyo: so how does your branch signify to the user that the charm can be upgraded?
[16:38] <hatch> I'm on rapi with serviceInspector and upgradeCharm
[16:39] <Makyo> hatch, that's the next branch.  This branch's whole point is to check for available upgrades.
[16:40] <hatch> gotcha
[16:41] <hatch> lgtm qa ok
[16:52] <hatch> jujugui CI is down
[16:52] <hatch> unable to deploy charm
[16:52] <hatch> were there any changes made to the charm yesterday?
[16:54] <rick_h> hatch: https://code.launchpad.net/~juju-gui/charms/precise/juju-gui/trunk landed today it looks like
[16:55] <hatch> it had failed when huw landed his branch early this morning
[16:55] <hatch> ahh crap, gota run for a few
[16:55] <rick_h> hatch: ok, well #93 landed yesterday
[16:56] <hatch> I'll look into it when i get back
[16:56] <rick_h> #92 as well
[16:56] <benji> BradCrittenden: do you know if we have any actual bundles in the production DB?
[16:56] <frankban> hatch: yes, but only the guiserver bits, and the error seems unrelated (KeyError: 'instance-state' when trying to parse juju status, wird)
[16:56] <frankban> weird even
[16:57] <BradCrittenden> benji: i do not.  sinzui might as he just looked into it
[16:57] <sinzui> benji, yes I do know.
[16:58] <benji> sinzui: are there any bundles in the production db?
[16:58] <sinzui> benji, bac, There is exactly one. Most likely the abentley won we are testing
[16:58] <benji> darn
[16:58] <bac> sinzui: that would've been my guess
[16:58] <sinzui> benji, staging has 2, one is bogus and I will remove it after I have a fix in place for a bug
[16:59] <benji> I guess I'll have to write a migration script then
[16:59] <sinzui> benji, do you want to remove the production one?
[16:59] <benji> it would be nice :)
[17:01] <sinzui> benji, you could just remove() the one bundle, If you are updating the structure you could just make sure you are compatible during the period it is not reingested
[17:02] <benji> hmm, yeah I think just removing all bundle data from ES and waiting for a re-ingest is the way to go; thanks
[17:10] <adeuring> bac: I can't reproduce these failures :(
[17:11] <bac> adeuring: thanks for looking.  very odd.
[17:11] <bac> adeuring: are you working within an LXC?
[17:11] <adeuring> bac: no, do you?
[17:12] <bac> adeuring: no.  but i have seen spurious test failures in the past linked to using a "real" environment vs an lxc.  those were timezone based, though.
[17:12] <adeuring> bac: another odditiy: you started with trunk r358 -- and that revision already contains most of my recent work...
[17:13] <bac> adeuring: well, i didn't run the full suite until recently
[17:13] <adeuring> ah, ok
[17:13] <bac> adeuring: anyway, have a good evening.  thanks for your help.
[17:14] <adeuring> bac: thanks. I'll look a bit more tomoroorw morning
[17:14] <bac> adeuring: ok.  i'll email you if i solve it
[17:14] <adeuring> bac: cool, thanks
[17:39] <hatch> totally just cut my finger open on a PowerAde bottle.....awesome!
[17:50] <hatch> does anyone know the euca command to destroy an instance?
[17:50] <hatch> ^ jujugui
[17:50] <hatch> oh terminate-instances
[17:53] <hatch> ok another build kicked off
[17:53] <hatch> looked like it couldn't start up the new instance
[17:53] <hatch> will see what happens now
[17:54] <hatch> bcsaller: is there any way to QA your branch?
[17:57] <sinzui> bac, benji: do either of you have time to review https://code.launchpad.net/~sinzui/charmworld/basket-name-none/+merge/181362
[17:58] <benji> sinzui: I can take it.
[18:02] <bcsaller> hatch: you can drag test/data/blog.yaml onto the canvas
[18:03] <hatch> ok and if no errors and the services are there then it's a o k ?
[18:07] <rick_h> hatch: guichat when you get a sec please?
[18:07] <hatch> bcsaller: I think there were some things changed in your branch which will effect Makyo's re the charm promise
[18:07] <hatch> rick_h: omw
[18:08] <bcsaller> hatch: that is a wrapper around the normal call, that shouldn't be a problem. The id normalization could impact something else but shouldn't 
[18:12] <bcsaller> hatch: yes, it should work, services and relations from the deployer file as you'd expect.
[18:13] <bcsaller> hmmm... though actually that won't work in the extracted version for the reason listed in the mp, ugh
[18:13] <bcsaller> when a deployer file includes more than one target we'd need a disambiguation UI which isn't there 
[18:14] <bcsaller> so w/o a change, no, it won't import, it will throw the error saying more than one possible target
[18:14] <bcsaller> a deployer with one target will work though, an export for example
[18:14] <hatch> ok so....stop reviewing and qaing?
[18:19] <bcsaller> or just export something and re-import it
[18:19] <bcsaller> that didn't work before
[18:19] <bcsaller> when we unsynced the format
[18:21] <hatch> lol
[18:21]  * hatch is glad he isn't doing this
[18:28] <rick_h> Makyo: if I wanted to confirm that the python environment .deploy() method would allow setting constraints in the 3rd argument (config) where would I look for the websocket docs/code? I see the send_rpc call, but want to keep following the code to determine what's valid for that config param for the 'deploy' call?
[18:30] <rick_h> yay jenkins has been appeased!
[18:33] <Makyo> rick_h, app/store/env/python.js:257 - Not seeing constraints :/
[18:34] <rick_h> Makyo: right, hatch thought perhaps the 'config' could container constraints
[18:34] <rick_h> but the code doesn't read like it
[18:34] <rick_h> Makyo: so I was going to go looking at the 'thing' that this ends up calling but not sure where to head from here. juju-core source?
[18:35] <hatch> jujugui I got CI back up, canonistack was holding on to an errored machine and wouldn't terminate it
[18:35] <rick_h> Makyo: I don't see any tests that work like that either, but the tests are specific
[18:35] <benji> cool
[18:35] <Makyo> rick_h, Yeah, I'm not seeing it in fakebackend, either.  It just uses an empty constraints object.
[18:35] <bcsaller> thats so classic canonistack, love that guy
[18:35] <rick_h> Makyo: the goal is to deploy a charm from the ghost inspector with charm config + constraints. Seems like it *should* be possible but trying to find the right way to build that
[18:35] <Makyo> rick_h, looking in core real quick.
[18:36] <rick_h> thanks Makyo 
[18:36] <hatch> bcsaller: lol
[18:36]  * rick_h is looking at core for the first time ever...duh duh duh
[18:37] <hatch> we have to be able to deploy a service with constraints :( That seems like such an oversight if it's missing
[18:37] <rick_h> hatch: yea, in following the code there now it's not tested or something I am seeing. 
[18:43] <Makyo> rick_h, In core (haven't checked pyjuju), ServiceDeploy's params takes a Constraints argument: http://bazaar.launchpad.net/~go-bot/juju-core/trunk/view/head:/state/api/params/params.go#L58
[18:43] <rick_h> Makyo: ah, thank you sir!
[18:43] <Makyo> rick_h, The constraints.Value shooould be a dict with very specific keys.
[18:43] <Makyo> Will look.
[18:44] <rick_h> Makyo: cool, yea I was looking at DeployServiceParams in conn.go which seems similiar, but not quite it
[18:44] <Makyo> rick_h, http://bazaar.launchpad.net/~go-bot/juju-core/trunk/view/head:/constraints/constraints.go#L19
[18:45] <Makyo> rick_h, I hope this hasn't changed and I'm not leading you down the wrong path.
[18:45] <rick_h> Makyo: ok, so looks like a little more work to do to get this able to work. 
[18:45] <rick_h> Makyo: cool, thanks. This helps a bunch and gives me something work towards. 
[18:45] <Makyo> rick_h, Yeah.  Want me to check pyjuju too?  Just got back from lunch, so I'm not on anything quite yet.
[18:46] <rick_h> Makyo: sure, I want to peek as well to understand how this stuff fits
[18:46] <rick_h> but appreciate a sanity check
[18:48] <Makyo> rick_h, http://bazaar.launchpad.net/~hazmat/juju/rapi-rollup/view/head:/juju/rapi/cmd/deploy.py#L15 has a constraints_strs
[18:49] <Makyo> I'm not quite sure how that works, but it does look like it's there.
[18:49] <rick_h> Makyo: so for the config, the Go is caps, the python is not?
[18:49] <rick_h> Makyo: yea, was looking at the constraints.py file 
[18:50] <rick_h> Makyo: actually guichat for a sec? Maybe easier?
[18:50] <Makyo> rick_h, Correct; that should be taken care of in app/store/env/{python,go}.js, so the calls remain the same, as does the data passed to the callbacks.
[18:52] <Makyo> rick_h, sure, be right there.
[19:17] <hazmat> Makyo, its mem=4 cpu=2 instance-type=m1.medium
[19:17] <Makyo> hazmat, cool, thanks.  rick_h ^^^
[19:17] <hazmat> Makyo, w/ juju-core s/cpu/cpu-cores and instance-type doesn't exist
[19:17] <hazmat> er.. mem=4G
[19:25] <benji> sinzui/bac: can I get a review of https://code.launchpad.net/~benji/charmworld/bundle-heads/+merge/181385 ?
[19:26]  * sinzui looks
[19:53] <hatch> jujugui is there a way to get the env calls to follow their callbacks in tests?
[19:54] <hatch> the overview constraints page needs to send the new constraints, wait for it to return, then send it's new unit number
[19:54] <bcsaller> wrap it in a promise
[19:54] <hatch> but the callback is never being called in the tests
[19:55] <hatch> ehh, that's a lot of overhead just to make it pass the tests :)
[19:55] <bcsaller> and you're sure it not failing before that? or you think nothing is responding?
[19:55] <hatch> well the env constraints call is being made
[19:55] <hatch> but the callback isn't getting called
[19:56] <bcsaller> hatch: I can look at it with you but offhand I don't know what to tell you
[19:56] <hatch> guichat real quick?
[20:03] <sinzui> benji, I replied with a question of sorts.
[20:04] <benji> cool, looking
[20:07] <benji> sinzui: I am inclined to say that bad bundles (or more correctly, bad baskets) are not ingested at all, that way we don't have to have a bunch of defensive code against bad data.  How does that sound?
[20:09] <sinzui> benji, how do we communicate to the basket author that their basket is invalid?
[20:09] <sinzui> we have a report for charms. you cannot search for them, but the report shows what we know about them
[20:10] <sinzui> benji, but in general I am fine to not save insane bundles for the moment.
[20:10]  * sinzui is writing an incantation to get the insane one out of staging ES right now
[20:10] <benji> ah, good point.  In that case I would save the basket data but none of the bundles.  That way we can show a bad basket but none of the bundles will foul anything up.
[20:11] <benji> we'll still have to be defensive against bad baskets, but that is a smaller battle front to defent
[20:17] <benji> sinzui: how about that? ^^^
[20:18] <sinzui> benji, works for me. r=me. I'll let you work out the graceful exit from the situation
[20:18] <benji> sinzui: "graceful exit"?
[20:19] <sinzui> benji, adding the defensive guards for bad baskets
[20:19] <benji> ah, gotcha
[20:19] <sinzui> There won't be any in a few minutes I hope
[20:19] <hatch> bcsaller: is there an example in a current test about setting up the env with the real fakebackend?
[20:19] <hatch> I can't seem to find one
[20:21] <bcsaller> hatch: test_sandbox_python and look for integration, I think that does what you want
[20:22] <hatch> ahh got it thx
[20:23] <bcsaller> Then I think you pass that sort of a setup as env
[20:36] <hatch> oh jeeze I need to load up a fakestore too
[20:44] <hatch> bcsaller: ok so now that i Have it all set up and are monkeypatching onmessage I still only get a single call
[20:44] <hatch> I'm guessing onmessage needs to return something?
[20:54] <benji> I really wish the testrunner didn't make me work to hard to craft the description of the subset of tests I want to run.  I bet there is a plug-in somewhere that I'd like.
[20:54] <bcsaller> hatch: when you're env is using the sandbox connected to a fakebackend it should work
[20:54] <bcsaller> benji: nested describe blocks?
[20:54] <bcsaller> I use those to collect tests
[20:55] <hatch> bcsaller: got a second for a guichat?
[20:55] <benji> bcsaller: this is the nose python test runner; it's not so bad, but it wants filename:classname.methodname.  I'd prefer to just do methodname and let it figure out the rest
[20:56] <bcsaller> benji: ahh, different test runner, I've used tags for that with nose iirc, there is a plugin for that 
[20:56] <bcsaller> hatch: missed you I guess
[21:09] <hatch> going to grab some lunch
[21:42] <bac> sinzui: i've narrowed the problem to a small set of tests as seen at https://code.launchpad.net/~bac/charmworld/spurious-test-failures/+merge/181418
[21:42]  * sinzui looks
[21:42] <bac> i've listed abel as a reviewer so perhaps he can figure something out tomorrow
[21:42] <bac> if not i'll land it so i can proceed with my work
[21:43]  * bac walks unusually patient dog
[23:03] <huwshimi> Morning
[23:28] <Makyo> So this stuff is pretty good: https://twitter.com/bzr_pull_makyo/status/370264178293886977/photo/1  Nicely gingery without being too weird for a beer.
[23:29] <Makyo> Plus, it's called Good Juju.