[00:29] morning huwshimi [00:30] "bold all the things!" [00:31] morning huwshimi :-) [00:32] http://orteil.dashnet.org/cookieclicker/ [00:32] * hatch is a pusher === gary_poster is now known as gary_poster|away [00:34] hmm, won't load here. Wifi is pretty bad [00:34] rick_h_: oh you're missing it, it's the perfect game for on vacation :D [00:35] playing with my moto x :P [00:35] OOooo you went with the x hey? [00:35] how is it? [00:35] nice, really quick. Love the small touches [00:35] does that run stock android? [00:35] pick it up and it goes to the unlock screen vs waiting for you to hit the power button [00:35] oh very cool [00:35] auto unlocks when my pebble is attached so no pin code [00:36] it's pretty stock. The notification thingy and the always listening for google now are non-stock currently [00:36] but I'd expect those to hit 4.4 tbh [00:36] picking up the DC metro/zoo apps for tomorow [00:37] we live in the future heh [00:37] heh always listening....ehhh [00:37] *caugh*no-privacy*caugh* :P [00:37] yea, getting the griffin car dock. Full hands free use with it [00:37] since you can wake it from sleep with you voice, tell it to write out a text, done [00:38] that is pretty cool [00:38] I'm paranoid though that it would be recording me :) [00:38] yea, oh well. They can hear me tell the wife I'm on my way :P [00:38] lol [00:39] good point [00:44] rick_h_: while I have you here, can you tell me what actually shows the Tokens? I see the token-container.js but I don't see what is actually showing each child [00:45] hatch: it uses the YUI parent/child widget relationship. [00:45] hatch: there are Views that create the TokenContainers based on a bunch of data [00:45] and the TokenContainers use YUI to create the Tokens since they're the child widget [00:46] hatch: so the container.items is the list of data for Tokens [00:46] so are they all shown by default? [00:46] and hideSomeChildren hides the specific ones? [00:46] hatch: no, the container gets called with a limit to show by default [00:47] hatch: well yea, they're all rendered and the container controls how many are visible (not display: none;) and the events for show/hide the rest [00:47] right, but I can't find what actually renders each child [00:47] ohh ok so they are all visible, then we hide the extras [00:47] hatch: right, it's behind the scenes in the container. Once the container is rendered, YUI renders the tokens [00:47] as the children of the parent widget [00:48] I didn't know that the parent auto-rendered the children [00:48] good to know [00:49] thanks [00:49] http://yuilibrary.com/yui/docs/api/files/widget-parent_js_Widget-Parent.js.html#l713 maybe? when the child is added it auto renders [00:49] I haven't used widgetparent/child in like....ohhhh 3 years [00:49] haha [00:50] hatch: yea, it was a really nice fit for our needs though [00:50] made a lot of sense and helped with the container/token split [00:51] some things do toksn on their own, related charms, autocomplete suggestions for instance [00:51] yeah I was actually thinking of a refactor for this area last night [00:51] was thinking about things like rendering just the markup and then enhancing it [00:51] wondering if we could do it simpler [00:51] careful, what's there is nice/works imo. I don't want to viewlet it :P [00:51] this is assuming fullscreen goes away of course [00:51] oh yeah I'm not actually proposing we do it [00:52] just thinking about it [00:52] :) [00:52] ok, well I'm all for chatting on things. I was hoping to be more involved when bundles came along but alas [00:52] did you see the email thread that huwshimi started about the animations? [00:53] I figured you would have some input on it and my response [00:53] I kind of saw it. I figure I don't have the ime to give a great response atm. Animations is involved. :/ and it seemed limited to the tabs themselves which should be easier to deal with [00:54] yeah basically it involved a refactor haha [00:55] animations anywhere will. Animations require both bits to be visible at once and nothing we've done works that way. tab widget, browser Y.Views, etc [00:55] right [00:55] it needs an overseer to handle all loading/unloading of bits [00:55] and that needs to get baked one layer above the things you want to animate [00:55] refactor time [00:55] you're not doing anything right now...get at it :P [00:55] hah, I'm planning a trip into washington DC right now :P [00:56] with your phone that listens to you no need - they will already know you're coming [00:56] haha [00:56] hah, well they're not going to give me a transit plan when I show up at the bus station tomorrow [00:56] even if they already know what I want to do [00:56] give it time....give it time [00:57] lol [01:01] night, time to head in and start locking things down. Getting chilly out here [01:02] alrighty, have a good one === gary_poster|away is now known as gary_poster [11:12] hey frankban. I struggled against local provider issues all afternoon when I was not on calls, so I never was able to qa. apparently local on saucy might have issues. I gave Tim details. I will try one more time this morning on local and then will go to ec2 while on calls. If you can find someone in a better position to qa then you are welcome to. :-) [11:12] But, sorry. :-/ [11:14] gary_poster: np, fwiw lxc works for me using revno 1750 of juju-core. but I am on raring [11:14] I also have problems with trunk, i.e. 1229286 [11:14] bug 1229286 [11:14] <_mup_> Bug #1229286: debug-log and boolean options are broken in trunk [11:17] frankban, I am on call with juju mgrs right now. I just raised that one to tim and william fwiw [11:17] gary_poster: cool thanks [11:25] frankban, config issue looks like bug. Wm is on it, I think. Tim says log issue is as designed. He will write email about it tomorow but he gave this summary: "effectively our logging is now more "productiony" [11:25] you can set the log level when you bootstrap, and that is used for the environment [11:25] or set it later using "juju set-env"" [11:27] gary_poster: yes, he explained the same in #juju-dev [11:28] frankban, oh! I see, cool :-) [12:02] frankban, with you soon--2 or 3 more minutes late, sorry [12:03] gary_poster: np [12:37] hey gary_poster, staging.jc.com is dead,dead,dead. there is no good reason for that, right? [12:38] correct bac [12:39] gary_poster: cool. i'll try go to get it alive again. its death looks somewhat premediated: http://paste.ubuntu.com/6158533/ [12:40] bac thank you [13:34] frankban: thanks a lot for the QA [13:35] hatch: welcome [13:39] hi abentley, do you know why staging would be shutdown? i've been trying to deploy it using the staging-tools scripts but not having any luck. [13:40] bac: Yes. See #is topic. OTP [13:41] thanks [13:41] abentley: please ping me when you are free. [13:46] hey hatch, you could merge/include huw's https://codereview.appspot.com/13954043/ in your bundle detail page work if you want, or we can do it separately later [13:47] hey luca__ . what's status of approved bundle token ux/visuals? if we can get ux at least no later than today that would be great. is that possible? [13:51] frankban: so I had no idea that services can go into an error state on destroy [13:51] ohh nm I missread your qa [13:52] hatch: the problem I highlighted is for services already in an error state, but I confirm a service can go in an error state also on destroy (i.e. if the stop hook exits with an error) [13:53] hatch: in both cases the service will be dying, but not removed [13:53] bac: free now. [13:54] gary_poster: mind taking a peek at frankban's QA of my branch when you have a second - I think we'll need to switch to the original plan [13:55] on call but will in a bit hatch [13:59] gary_poster: are you after the bundle token? [13:59] luca__, yeah [13:59] gary_poster: It's been signed off, I'll send it through in 10 mins [14:00] cool ty [14:18] guihelp: how do you dismiss a ghost service block? The cancel button in the ghost inspector doesn't work for me in https://jujucharms.com/sidebar/ : it closes the inspector but the service block is still there. [14:18] frankban: destroy the service [14:20] gary_poster: if you want me to try juju on my Saucy VM I can try and give it some more ram and see if it works [14:20] hatch cool. if you can unblock frankban by qa'ing his branch that would be fab [14:21] yeah I can do that [14:22] hatch: thanks [14:22] hatch: locally, with make devel, destroying a ghost gives me a weird error notification, and leaves the ghost block [14:22] with my branch? [14:23] hatch: no, in trunk [14:23] Error destroying service: Service name: 55274347$ [14:23] ok that makes sense.... [14:23] but it shouldn't be erroring [14:23] can you create a ticket plz [14:24] hatch: sure [14:24] and I'll see what's up after QA'ing your branch [14:25] hatch: is this something specific to the go sandbox, or to the go env in general? [14:25] frankban: it's a symptom of switching to a single service model - ghosts are given a random unique id so they -cannot- clash with anything potentially returned from juju-core [14:25] and so that you can have multiple ghosts with the same name [14:26] as to why it can't destroy it - I have no idea [14:26] hatch: ok, but it's a regression, in jujucharms works, in comingsoon is broken [14:26] yeah it was done after release [14:27] it's definitely not supposed to throw an error :) [14:27] cool [14:29] hatch: filed bug 1231487 [14:29] <_mup_> Bug #1231487: Error while trying to destroy a ghost service from the inspector [14:29] thanks! [14:37] gary_poster: just sent you the Bundle token [14:37] looking while on call luca__ ;-) thank you! [14:37] adeuring: hi, I have a question about charmworld's elastic search. Where in charmworld do we configure ES? Is there an initialization script or something similar? I ask because we're considering enabling n-gram tokenization to get better substring searching. [14:38] oh luca__ I had feedback on your email from yesterday that I didn't get around to sending :-( [14:38] not a big chagnge but will right it out, in short, only bundle yaml is pertinent for the functionality that you are describing [14:39] frankban: I can't seem to get your branch to save any config changes - do I need to be on a certain charm version? [14:40] hatch: what version of juju-core are you using? [14:40] cs:precise/juju-gui-76 [14:40] benji: We have right now just two config parameters: number of shards and number of replicas; that's defined in the .ini file- [14:40] umm sec [14:40] 1.14.1-precise-amd64 [14:40] benji: additionally, we should define the ES cluster name, but that's done vie "juju config" [14:41] hatch: weird. have you switched the charm to my branch? [14:41] yep it says it's your branch [14:42] oh wait a second.... [14:42] adeuring: ok, I saw those but wondered if there were more. If we were to want to enable n-gram tokenization how do you suggest that would work? I assume we would need both to set the configuration on a new deployment and a script to reindex the existing production ES. [14:42] frankban: ok when I change the setting 'juju-gui-console-enabled' in the GUI it clears out every config field [14:42] then on refresh it's now saved [14:42] so yes it works....but it breaks the GUI [14:43] I'll reply on the review [14:43] luca__, is that bundle icon finalized? if so, could we have the svg? [14:43] gary_poster: sure [14:43] thanks luca__ [14:43] hatch: I'm not sure I understood the problem [14:44] benji: I am not very familiar with ES myself, but I assume that you need to create a new index with the right parameters. That would probably be similar to the put_mapping() call, which is already a sort of configuration (in addition to the shards/replicas) too. [14:44] benji: and the best mechanism there is to run an "exodus" [14:44] ok, that makes sense [14:45] frankban: responded with repro steps in the review [14:45] hatch: pl [14:45] ok even [14:45] :) [14:45] gary_poster: sent it over [14:46] luca__, button states & bundle tokens look great. I thik we need one other bundle state for inspector notifications list button: "in progress" or something like that. If I click on "Resolve" or similar it may take a few (10?) seconds to actually complete [14:46] benji: migration 019 is an example -- that's a really trivial exodus (in the sense that the exodus machinery does all the tricky stuff but you don't have to care about it) [14:47] adeuring: I thought "migration" and "exodus" were different things. [14:47] luca__, thanks for icon! [14:47] luca__: we will need assets for those checkbox states FYI [14:48] gary_poster: can you email me about the "in progress" thing, then I can just pass it on the jamie. [14:48] the little ones for the unit list that is [14:48] luca__, will do thx [14:48] and nice bundle icon :) [14:48] icon/token [14:48] hatch do we have/need the orange "recommended" triangle, do you know? [14:49] we can do it in css [14:49] hatch: the checkboxes are in the document [14:49] luca__: document? [14:49] benji: the exodus is a migrations, where you can apply all changes to new mongoDB collections/ES indexes, while the old data is still in use. [14:50] hmm, I must not understand something about the mechanism [14:50] hatch: in the button states document [14:50] luca__, the doc is a png though [14:51] gary_poster: oh! right, assets, duh [14:51] gary_poster: haha [14:51] :-) [14:51] gary_poster: hatch sorry [14:51] :) gotcha [14:51] np [14:51] np :-) [14:51] hatch: how do you want them supplied? [14:51] hatch: I thought it was just code [14:51] silver platter [14:51] :P [14:51] :P [14:51] nah, we can't actually style checkboxes cross browser reliably [14:52] no cushion? [14:52] I MIGHT be able to re-create those with markup/css [14:52] hatch: could you please try to deploy another charm and check if the behavior you described happens also there? [14:53] hatch: ok, if you need them just email Jamie (cc me) [14:53] frankban: sure trying now [14:53] hatch: thanks [14:53] luca__: ok sure thanks [14:53] luca__: could we get some colour codes? [14:53] hatch: thanks [14:53] ops [14:53] hatch on calls calls calls, but saw frankban's qa of your branch. we talked about this case. I'll ping you asap to talk through. [14:53] gary_poster: yep np [14:53] I'm not -doing nothing- yet :D [14:53] at that point I'll get antsy [14:53] hatch: sure, we created the document to make it easy to catalogue all of this so we can expand it and improve it [14:53] haha [14:53] :-) k [14:54] frankban: deploying mediawiki - it'll be probably 10mins or so [14:54] luca__, yes, +1 and thank your that btw. the catalog is a great approach I think [14:54] yeah I really like the idea of the overview in a single place [14:54] "thank your that" == "thank you for that" :-P [14:54] hatch: but you can try changing options even when it's pending [14:55] frankban: yup, change the option and they dissapear [14:55] I can screenshare if you like? [14:55] hatch: I am trying to dupe [14:56] luca__: are my eyes playing tricks or is the 'Notificatios list button' pre-depressed? [14:57] man I really like the new tokens.... [14:57] hatch that's the suru style [14:57] you depress somethat's already depressed. you really hit em when they are down... [14:58] lol!! [15:05] hatch: reproduced, but I think it's not my branch. this is another bug, I guess we do not handle correctly delta streams in the inspector [15:05] well as soon as I click save it wipes the rest out [15:05] I'm pretty sure this didn't happen before [15:05] maybe because it was failing [15:05] haha [15:05] could you take a look to see if it was your branch which caused it? [15:06] or if it should be a follow-up [15:06] I'm ok if it's going to be a follow-up, I'd just like to not introduce a bug if possible :) [15:07] hatch: my branch just changes a parameter in an API call in the env layer: it does not interact with the form in any way [15:07] right - but I 'think' the form uses the old params to fetch the config options [15:07] so if they are empty - then the fields will be empty [15:07] the databinding would have updated causing it to wipe clean [15:08] hatch: juju sends back something like {"RequestId":5,"Response":{"Deltas":[["service","change",{"Name":"mediawiki","Exposed":false,"CharmURL":"cs:precise/mediawiki-10","Life":"alive","MinUnits":0,"Constraints":{},"Config":{"name":"asd"}}]]}} [15:11] hatch: so Config is just {"name":"asd"}, and my first impression is that the i the handler the other default settings are ignored. [15:12] You need to refresh the GUI to get the configs back [15:12] hatch: the machinery to fetch the settings is not changed in my branch [15:12] yeah - I'm saying it might need to be [15:13] if you wait long enough the settings come back [15:13] on the next delta i'd presume [15:16] frankban might be https://codereview.appspot.com/13917043/diff/1/app/store/env/go.js ln 1027 [15:18] because the bindings are listening on 'config' [15:19] hatch: hum, perhaps inspector.js line 755? [15:19] hatch: ISTM it sets service.config to only the new values [15:19] ahhh so it's responsing with only the changed values and then we are clearing out the model and setting it to only that [15:19] right [15:19] ok definitely not from your branch [15:19] then [15:19] :) [15:20] hatch: so, it was pre-existent, if you agree, I'll land this and work on a fix for this new bug [15:20] done and done [15:20] hatch: thanks [15:21] great QA, I missed that [15:43] frankban: re your review of my branch - if a user in the console destroys a service which then goes into an error state you would expect the inspector to stay open as long as the icon is on the canvas, correct? [15:43] so we need to listen to lifeChange and being removed and then check to see if it has any errors on its units [15:43] hatch: yes [15:43] poop [15:44] :) [15:44] thanks [15:44] hatch: speaking of poop, utils.removeUnchangedConfigOptions modifies the config in place [15:44] and then returns the config [15:45] leaving on you that oppressive sense of bitterness [15:46] lol [15:46] hatch: and that's the real emptied inputs problem. [15:46] should that method not only be called when sending the values to the server? [15:46] ohh I see what you're saying [15:47] hatch: yes, but it modifies an object in place, and that object is then propagated in the callback. [15:47] right right [15:47] should we maybe 'mix' the incoming deltas in as well? [15:48] this definitely needs to be fixed [15:48] but should we mix the two also? [15:50] jujugui call in 10 kanban now [15:50] hatch: I think we have 2 easy fixes: 1) do not modify in place the new config (so that the callback will receive the whole config object) or 2) mix the current config and the new values in the callback [15:50] 3) both [15:50] :P [15:50] honestly though 1) definitely needs to be done [15:51] 2) if you wanted [15:51] not sure if doing #2 will gain us anything after #1 is fixed [15:52] hatch: I am ok with modify objects in place if that's documented and the function returns undefined. I am confused instead when a function changes an object in place AND returns the changed object [15:52] hatch: and maybe there is some value in the callback receiving only the new values [15:53] frankban: yeah that happens a lot in javascript apps ive found [15:53] maybe [15:53] I'll leave the implementation up to you [15:53] hatch: ok thanks [15:54] ugh, I have meeting ennui :-) [15:56] I just googled it [15:56] you used that word wrong [15:56] lol [15:57] hatch, in what way? [15:58] ok maybe not [15:58] I found another example [15:58] dammmnnnn youuuuuuu [15:58] lol. meeting-induced ennui might be more accurate, but I think what I said is close enough [15:58] jujugui call in 2 [15:59] haha yes it is [16:06] benji: the charmworld new lander works just like the old lander [16:07] heh, k [16:10] Makyo: https://plus.google.com/hangouts/_/f3152089747387222abf5a2f310ec7fdf4473cb6?authuser=1 [16:17] I wonder if that's an android thing - if you use up 95% of the 'disk space' it gets very very slow [16:41] stepping out for about 20 [16:42] bbl [17:50] hi bcsaller, can i ask you about a change you made to makeFakeStore? [17:50] yeah, let me pull it up [17:51] ok, whats up? [17:51] you added the cache parameter, and it is used in one test suite. but, looking at it i don't see it ever used. [17:52] bcsaller: i'm not sure what you intended. removing it doesn't break any tests... [17:52] the actual store charm methods take a cache [17:52] bcsaller: what i wrote was confusing. i mean one call site passes in a cache but i don't see makeFakeStore using it [17:54] the idea is only to accumulate the charms into a model list, tests don't have such a list to keep things for the most part [17:55] it might be good to do all the imports on load though with a real model list and have fakestore resolve them from there to speed up the tests [17:55] yes!! [17:55] :) [17:56] bcsaller: yeah but in http://paste.ubuntu.com/6159694/ the cache in line 1 is not the same one used in 3-19. [17:56] so i think i see your intent but (unless i'm confused) don't think it got implemented correctly [17:58] bac: have you looked at app/store/charm.js:202? [17:59] bcsaller: yes [18:02] I think it was just to mimic the actual call, if we never use it we can remove it from the mock, but I'd have thought we did [18:02] bcsaller: if i rewrite makeFakeStore like http://paste.ubuntu.com/6159728/ i think it is clearer that the param is never used [18:03] bcsaller: i'm happy to fix it to do what you intended...but i'm not sure how. [18:05] ahh, I didn't see what you meant, I'm being dense, I see it now [18:08] yeah, I'm not sure what the best thing to do there is, if the top level cache was passed in we could update that (after changing that argument name) and adding it to that list as well [18:08] or just take it out [18:09] the real fix would be to reduce the IO in there when cached_charms are computed [18:16] bcsaller: ok, thanks [18:16] bac: sorry I wasn't more helpful. but I can make changes as a fly by on the branch I'm working on now if you'd rather [18:17] bcsaller: maybe just paste a snippet of what you're thinking. i need to change the signature too, so i'd rather do it in my branch [18:18] jujugui Anyone else (bac, I think?) having issues with `make check` running into a 404 trying to get /login/data/wordpress.json on the test-debug step? [18:18] If so, I think I found a solution but...I don't understand it. [18:18] I'm not, but interested to hear [18:18] bac: well for now removing the first unused cache should be enough based on what you said. [18:19] ok [18:21] check runs test-prod test-debug in that order. If I swap them, I can't reproduce the error. [18:23] prerequisite rules are run synchronously, correct? [18:24] correct [18:24] and shouldn't have any effect on eachother [18:27] Exactly. [18:27] benji: will the ngram tokenizer give us fuzzy style searching? [18:30] I don't get the error if I `make test-prod; make test-debug`. [18:32] hatch, you want fuzzy logic? buy a rice cooker. [18:33] bac: shroden cooker you mean - you don't know if it's done until you look at it [18:33] Now it's happening on test-prod. I hate everything. [18:35] hatch: [sorry, I was AFK] It depends on what you mean by "fuzzy". [18:35] benji: package name: foobarbaz search: bar [18:35] would match [18:36] yep [18:36] SHIP IT! [18:38] :) [18:44] bac: what is the status of v3 API bundle output? I'm looking for something to do and was considering one of the wire-it-up cards. [18:45] benji: coming along but i got sidetracked a bit. something end of day i hope. [18:45] k [18:48] I don't know who fixed 'make devel' but it's so fast now [18:48] +1 whoever that was [18:52] in huws notification branch he removed the events but didn't remove the methods which those events call [18:52] does anyone know if he plans to do that in a followup? [18:52] jujugui ^ [18:53] hatch, he added a card to high kanban group that looks pertinent [18:53] "Remove remaining notification page(s) and code" [18:53] ohh woops I missed that [18:53] thanks [18:53] qa'd ok so I'm going to land [19:02] anyone else getting a bunch of old RT emails? [19:04] not i [19:07] * Makyo fails at proposing for the umpteenth time, tries from other computer. [19:08] ok so my latest branch has failed on juju-core with a hook failed error [19:08] how should I debug this? [19:08] ssh into the machine and read the juju log? [19:11] got it [19:13] man I wish juju would tell you if it's doing something [19:14] There's debug-log for that, right? And a ticket in for hook logs in debug-log, I think... [19:15] well I was thinking status should tell you if there are any active hooks on a service [19:15] service/machine [19:18] somehow my gui instance is stuck on dying [19:18] juju pull-the-plug juju-gui --forceful [19:18] :D [19:21] :-) [19:26] Aaaargh, everything works from the branch dir, just not the lightweight checkout. [19:35] Makyo: I'll review your branch [19:35] waiting for core-y stuff [19:35] hatch, cool, thanks. [19:38] ok, I need to stop now. be back in 3 hours or so [19:39] Makyo: review done - have some q's before QA [19:40] hatch, first question - it does. Visibility is bound to charmChanged. [19:40] oh ok - I didn't see that, must have been from a previous branch? [19:40] hatch, second question - Good point. Will think about it. [19:41] cool thanks [19:49] hatch, What about the instance of someone clicking close right as the 'service was upgraded' message comes in? If they open the inspector again to read the message, it won't be there. Since, in this case, that link doesn't do anything but dismiss the message, it seems a small thing to just leave it there. [19:49]