[00:08] hatch: Is the "Consolidate deployer bar summary generation functions" card something you're doing or did you want me to take that? [00:09] huwshimi it can't start until the branch I'm working on lands because I used the current approach [00:09] so I can leave it for you for tomorrow if you like [00:09] I likely wont get time to do it by tomorrow [00:09] hatch: Ah no problems. I can take a look tomorrow then. [00:12] hatch: I might have to take a card out of the backlog unless you've got anything you need doing? [00:12] hmm lemme take a peek [00:13] huwshimi what about https://launchpad.net/bugs/1328981 ? [00:13] <_mup_> Bug #1328981: Reloading the inspector on upgrade of a charm creates blank sidebar [00:14] or the card "wire the new container header/actions" I have no idea what that even means lol [00:16] hatch: That's the link in the containers header column that says "Add container" [00:16] ohh, do you want to do that? [00:16] or is it blocked by something [00:16] hatch: kyle has a card that says "wire up new container (both link and drop target) to work properly" [00:16] ohh ok [00:16] so I assume that is covering part of the work, or at least blocking it [00:17] ok in Maintenance backlog https://bugs.launchpad.net/juju-gui/+bug/1331061 [00:17] <_mup_> Bug #1331061: bundle deployment delay in drag/dropping a bundle in live environments [00:17] er On Deck [00:17] should be really small one heh [00:18] but yeah looks like you can pull something from On Deck [00:18] ugh, my tests failed again [00:21] hatch: Any ideas? http://ci.jujugui.org:8080/job/juju-gui/1253/console [00:26] looking [00:26] huwshimi https://saucelabs.com/jobs/828b4d0f1c7645bfbb79ace92314af50 [00:27] oh so that's the same issue [00:27] I think [00:27] uh no [00:28] well it appears to be an IE only issue so you will probably want to view up an IE vm [00:30] hatch: yeah, it's because pointerEvents aren't supported in IE10 [00:31] well that sucks [00:51] I don't know how to do this :( [00:52] I could do it through CSS instead of JS and not test for it, but that seems less than ideal [00:52] And IE10 would just not have working hovered drop areas [00:52] (visually, they wouldn't have the background appear) [01:27] huwshimi sorry I had to step away - did you end up figuring out a solution? [01:27] hatch: Yeah, and it fixed an intermittent bug too :) [01:28] coolio, push it up whenever you're all done and I'll review it [01:28] hatch: Thanks, just fighting a really strange css linting bug and then I'll push [01:32] no rush I'm going to be having supper soon [01:33] hatch: Apparently we can't use the '*' selector? [01:36] oh...it's considered bad practice [01:36] hatch: How would you feel about allowing that in our lint? [01:36] but you should be able to override it [01:36] I'm ok with it [01:36] there -are- valid use cases for it [01:37] hatch: Well, in this case we want to make sure all children get applied the pointer-events: none for our drop targets [01:38] yeah sounds god [01:38] good [01:42] hatch: OK, changes up. [01:48] hatch: Oh, just need to fix a little bug [02:58] huwshimi hey I'm back - it's all ready to go? [02:58] hatch: Yeah, it's up, but I got this error from the safari tests: https://saucelabs.com/jobs/72a85e524b55401a82bd55338029394f [02:58] looking [02:59] huwshimi that's the intermittent issue - it can be ignored [02:59] ah ok [02:59] ...well it shouldn't be [02:59] heh [02:59] :) [02:59] but we have a card to figure out wth is going on [03:08] hatch: Are we having an aus call tomorrow? [03:09] well rick is not around tomorrow but if I hear of anything of interest to you I can fill you in [03:09] I suppose I could fill you in on the personas call that we had with design yesterday [03:10] you can probably get most of the information from looking at the slides though [03:12] hatch: Luca actually took me through the slides last night [03:12] ohh, well then, nope nothing new so far :) [03:23] huwshimi review done, just going to QA now [03:23] hatch: Thanks! [03:27] and qa done [03:27] I'm pretty confident that I don't like the jarring UI change when dragging [03:28] but it makes it's intentions known thats for sure [03:28] maybe that's a good thing [03:30] huwshimi ok both PR's reviewed and qa'd so you should be all good to go [03:31] hatch: Thanks! [03:31] np, now I'm going to try and catch up on my blogs [03:32] way too much content added to the internet every day for me to keep up with [03:33] haha [03:36] huwshimi is there any UI for the config changes in the deployer bar? ATM I just say 'configuration values changed in ' [03:36] but I'm wondering if we should show which values somehow... [03:36] hatch: Not that I know of. I think we need an updated set of visuals for the deployer bar [03:37] ok I'll fire off an email to UX [03:37] hatch: Thanks [03:39] email sent [04:05] hatch: oh, this is broken. When I drop the unit on an existing machine or container it wants to create a new machine [04:06] huwshimi yeah [04:06] can you file a bug for that - I'm pretty sure there already is one, but I can't find it [04:10] hatch: I think that's something I broke in my branch right? [04:10] no I'm pretty sure it's broken on trunk [04:10] lemme see [04:11] comingsoon does other weirdness [04:12] heh yeah it's broken there too [04:13] hatch: With different results though. I think I have broken something here [04:14] I don't think so - I mean, it may be different broken from comingsoon, but it still doesn't work on comingsoon [04:19] hatch: Actually, it appears to be working for me on coming soon now. [04:19] yeah? Odd I can't get it to work [04:19] hatch: What happens for you? [04:20] it gives me a notification error that it can't find the container that I'm trying to deploy to [04:21] hatch: Oh, that's not what I've been getting [04:23] hatch: On my branch, when I drop a unit onto a container or machine it acts as if I'd dropped it on "Create new machine" [04:23] yeah I remember that bug used to happen [04:23] maybe as early as last week [04:24] huwshimi are you dropping on the machine or on the container on the machine? [04:26] hatch: on the machine [04:26] hatch: The container will sometimes work [04:26] hatch: Not sure why though [04:26] ok now it's working on comingsoon [04:26] lol [04:27] must have had some wako caching here [04:28] huwshimi sorry I've got to run, good luck :) [04:28] hatch: No problems, have a good one :) [04:36] hey all [04:47] rick_h_: Morning? [04:47] oh, it's just very late [04:49] huwshimi: yea, late day [04:49] finally seeing email for the first time in about 12hrs [04:49] heh [08:23] morning rogpeppe1: I have a dentist apt in 50 mins :-/ Do you want to have a chat? [08:23] frankban: sure [11:04] rogpeppe1: back and alive, this dentist was fracking accurate, which is good but also bad... [11:05] frankban: hangout? (or perhaps you can't speak... :-]) [11:05] rogpeppe1: joining [11:55] frankban: http://paste.ubuntu.com/7668667/ [12:01] frankban: https://docs.google.com/a/canonical.com/document/d/1SF8hTBi6oVbki8V__beNij6wnQU-5cm6PZsy5gf0j_Y/edit?usp=sharing [12:08] rick_h_, bac: ping [12:09] hi rogpeppe1 [12:09] bac: fancy having a look at our bundles proposal document? [12:09] bac: link just above [12:09] rogpeppe1: sure [12:13] bac: feel free to join us in the standup hangout if you want to chat about it [12:13] rogpeppe1: let me read first then i will [12:13] bac: cool [12:38] rogpeppe1: you still in the hangout? [12:38] bac: yup [12:38] rogpeppe1: normal daily standup? [13:43] rogpeppe1: ooh docs thanks. [13:43] rick_h_: np. would be good to have your feedback. [13:50] * bac is utterly utopic [13:51] bac: whoa, brave man [13:51] bac: doesn't juju not work right on utopic still? [13:51] rick_h_: just embarking [13:51] fwiw, update-manger -d hangs but do-release-upgrade works great [14:00] rogpeppe1: commented in the doc [14:00] rogpeppe1: thanks for that, good stuff [14:01] frankban: bac going to add a card to the backlog for this https://github.com/juju/juju/pull/77 [14:01] just a heads up [14:02] rick_h_: ok [14:29] rick_h_: i've replied to most of your comments [14:31] rick_h_, thanks for the doc review, I've made and pushed all those changes. <3 [14:43] hehe very cool http://gizmodo.com/this-audio-illusion-will-make-you-never-trust-your-ears-1593113324 [14:46] hatch: when you get the chance I have more questions about simulate [14:46] yeah shoot [14:47] It looks like the second arg for simulate lets you decorate the event object [14:47] yep [14:48] But in my case, I want to override the e.target attribute [14:48] you can hang some streamers, and such [14:48] aren't you simulating the event on the select which is the target? [14:48] Such that e.target.get('value') returns something [14:48] why would you want to override it? [14:48] oh you want the target to be the option [14:48] Because I want to simulate the select being changed to something other than the default value [14:49] why not loop through the options to find out which one is selected then get the value from that? [14:49] that's the 'proper' way to deal with selects cross browser [14:49] YUI tries to normalize it but it doesn't always work out as plannd [14:49] Not sure how that would help in the test? [14:49] set an option as selected [14:50] then simulate the change event [14:50] Ah, so container.one('option[value=foo]').setAttr('selected')? [14:50] well you'll have to remove any previous selected ones [14:54] jujugui call in 6 [14:54] That audio illusion did not work for me. Not sure what that says about my brain. [14:54] uh oh! [14:54] kadams54: worked for me [14:54] kadams54 maybe try again [14:54] I listened to the real sentence and the scrambled one three times [14:55] It kinda seemed like the beginning of the scrambled one sounded like the real one, but then it just sounded like r2d2 by the end. [14:55] Nothing ever really "popped" or seemed very different [14:56] hmm interesting [14:56] worked first try for me [14:56] kadams54: i listened to the real sentence twice [14:56] kadams54: ('cos i didn't understand it first :-]) [14:58] maybe it depends on how much time you spent with 8bit games: https://www.youtube.com/watch?v=i1_fDwX1VVY [14:59] frankban haha [15:00] jujugui call now [15:11] hatch: pushed lint fixes. [15:11] cool - could you put your qa instructions in the PR description instead of in a comment from now on :) [15:12] makes it easier to find :) [15:13] rogpeppe1: did you send email about the bundles doc? i'm looking but don't see anything. if so, which list? [15:13] bac: #juju-dev [15:14] bac: juju-dev@lists.ubuntu.com [15:14] rogpeppe1: thanks. [15:18] jcastro so the video is unlisted but not locked so if you have the url you can see the stream [15:18] just fyi [15:22] jcsackett wow this diff is all over the place lol [15:22] thanks rogpeppe1. turns out i wasn't subscribed to that one. am now. [15:23] hatch: QA in a comment seems better--it's kind of bizarre to have the QA instructions become part of the commit log, don't you think? [15:23] b/c i need more email [15:23] hatch: and yeah, for what is actually a simple bit of breaking out logic, git diffed it *really* oddly. [15:23] jcsackett: i often put QA in with the lbox propose but try to edit them out when i do lbox submit [15:24] jcsackett the PR description doesn't get merged into the repo [15:24] jcsackett: never mind. you're talking github and i'm just butting in with irrelevant comments. [15:24] I suppose it makes it into the merge commit [15:25] hatch: yup https://github.com/juju/juju-gui/commit/26ecc89e1e34152947d9ea71f12a6cb537a36a7f [15:25] bac: the same idea could work--just feels weird to edit the PR description after review. [15:25] well then! [15:26] hatch: i *agree* that the description shouldn't, mind you. :) [15:26] GH does some weird stuff [15:26] it's almost like they do the absolute minimum amount of work lol [15:26] yup. [15:31] jcsackett damn you updating while I'm still reviewing [15:31] lol [15:31] hatch: i'm not rebasing though. [15:32] just addressing your comments as i see them--you want me to hold off altogether? [15:32] if you could - it removes the comments associated with any changed lines [15:32] (which I just learnt) [15:32] :) [15:32] hatch: sure, no problem. [15:33] (as a note, it only removes them if that part of the diff goes away or is altered--which usually means your comment was just addressed) [15:33] but i need more coffee anyway, so i'll hold off. :) [15:50] hatch: re the 500ms, in my testing it needed only one round of 100ms, but i wasn't sure if we wanted to cut it that close. 5 really short retries seemed like a good guess, but i wonder if you have any thoughts? [15:50] jcsackett nope I'm good with whatever you found I was just more concerned about a comment to tell future us why the retries were as they were [15:50] hatch: ok. [15:52] jcsackett I've found over the past year we end up going back and are like 'what the....why....huh?....(1h later)...ohhhhhh now I get it' [15:52] lol [15:55] jcsackett your test failure was the intermittent one [15:56] hatch: well, i'll be pushing up changes shortly, so we'll get another run. [16:35] jcsackett so I get the bug mentioned in your PR when trying to view /inspector/juju-gui [16:35] is it supposed to do that? Or something else? [16:35] hatch: right. it's a separate issue, as it popped up while i was investigating this. [16:35] but "no model" is also "partial model". [16:35] ok so the 'not an inspector' mode works [16:35] but I get that bug when trying to view the juju-gui inspector [16:36] hatch: normally? or after reload? [16:36] after reload [16:36] hatch: ok, that's expected. [16:36] visiting /inspector/juju-gui gives me the bug mentioned [16:36] ok cool [16:36] hatch: that started happening after i rebased develop. [16:36] i'm actually going to see if i can find the cause and update the bug today. [16:36] ok qa ok [16:36] but our fix doens't fix that, sadly. :( [16:36] after you fix the comments plz rebase :) [16:37] hatch: will do. [17:01] jujugui looking for a review/qa on https://github.com/juju/juju-gui/pull/396 [17:03] jcsackett re my comment on property vs attribute http://jsperf.com/yui-attribute-vs-property/7 it's a monstrous difference but I figure we are ok with 3.8M ops/s :D [17:05] jcsackett you'll also notice I used your approach and put the QA notes in a comment :) [17:14] hatch: looking. [17:18] thanks [17:38] kadams54 how goes the battle? Would you like to pair to get that thing landed? [17:39] it's blocking Huw so would definitely like to get it landed today [17:40] hatch: two questions on your PR, just on stuff i'm not following--qa is good, if you can sort me on those i'll +1 now. [17:40] yup replied [17:41] hatch: Got it. Let me wrap up work on this test and then I'll be at a good spot for pairing [17:43] jcsackett comments replied to [17:44] hatch: in retrospect, the answer to my second question was obvious. :p [17:44] thanks, you're good to :shipit: whenevs. [17:45] haha np :) [17:56] hmm this ecs ghost config is going to be interesting [17:56] Makyo what about things like constraints, unit counts, etc? [17:57] atm you can't deploy more than 1 unit [17:57] Isn't that part of the deploy args? [17:57] right - but there is no way to 'submit' changes to a ghost inspector [17:57] there is no 'save' button [17:58] so you can't actually set anything [17:58] Isn't that in the plans, though? [17:58] no idea - I don't recall seeing any mockups with one [17:59] there is an issue here because if we allow the user to increase their units here, and define the constraints then that's going to much with the MV stuff [18:00] Maybe it's purely a mv thing [18:00] it's like auto-placing a unit [18:00] Yeah. [18:00] I'd just focus on the current iteration until we get more direction. [18:00] yeah there isn't much I can do until we figure this out - because atm I'd have to save on blur in the config or something [18:00] which is a litle odd [18:00] or add a save button [18:01] crud I wish design was still awake [18:01] :) [18:01] We've been talking about a save button for a while now. [18:01] So whatever. Can you search for a stopping point that's landable? [18:02] Like, even if it doesn't actually use the ECS config stuff, have that in there, etc. [18:02] I'm not sure I should even start on the ghost config ecs stuff until this is ironed out [18:02] Sure [18:02] the deployed service ecs is done [18:02] but the ghost stuff just doesn't quite make sense heh [18:03] My own task is turning out to be impossible without doing the whole thing at once, so I'm doubling or tripling LoC. If you want to snag another ECS card, no need to wait on me [18:03] the remove relation one? [18:04] oh the inspector double call thing [18:04] got it [18:04] I'm going to stew on this a bit longer then fire off an email [18:42] hatch: I may actually be ready to land this sucker. Waiting to see what happens in CI, as well as doing manual testing… I've updated the PR to reflect the not-a-WIP-any-more status. [18:43] cool I'll check it out [18:43] hatch: That said, I'm somewhat concerned that my work may conflict with Huw's stuff that's in review. [18:43] hatch: I'd be more comfortable if that stuff was shipped and I could rebase off it. [18:44] ok that's possible I suppose - he hopefully will solve his bug and get it landed tonight [18:44] then tomorrow you can rebase and go [18:46] hatch: so now that all automated tests pass, I'm running into problems doing manual testing. Time to write more tests. [18:46] hatch: feel free to hold off until I've sorted through these problems. [18:57] ok will do [19:53] kadams54 hthere is a card "wire the new container header/actions" is that taken care of in your branch? [19:55] Makyo so it's ok if I hop on the remove relation ecs card? [19:56] Sure. [20:09] Makyo any idea why lazyAddMachine and lazyAddUnit aren't private (_) ? [20:10] typos? [20:10] hatch, yeah, I think so. [20:10] alrighty [20:41] hatch: yes. [20:41] kadams54 ok cool, can you look at the ready to code cards and delete the ones which are already done in your branch [20:41] hatch: So I got everything working again, the CI build was passing, life was great. I squashed the commits down to one, pushed, and all hell broke loose. [20:42] hatch: manual testing and test-server still pass just fine. test-prod is totally borked. [20:42] So that's awesome. [20:42] Are you missing a dependency? That's usually the cause of test-prod going [20:42] I don't think so [20:42] test-prod passed just fine before I squashed [20:43] Squashing was the only diff between build #1268, which passed, and #1269, which didn't. [20:44] ok lemme see [20:45] kadams54 does test-prod run locally? [20:45] No [20:45] I can dup the same errors I see in CI in local test-prod. [20:45] But test-server runs just fine. [20:46] try test-prod-server [20:47] finished reviewing for dupe cards - only deleted the one you found. [20:47] ok [20:52] test-prod-server is fine. Just re-ran test-prod, errors galore. [20:52] whee! [20:52] look in the network tab [20:52] see what it's requesting [20:52] it is likely making additional requests [20:52] Time for a make clean [20:55] wellllll CI runs in a clean env all the time [20:56] So I'm running test-prod-server and I've got the network tab open - what am I looking for? [20:56] I'm pulling down your branch to see if I can reproduce [21:00] ok I can reproduce [21:01] when you rebased, did you rebase against develop again? [21:01] I'm just not sure how flattening could have caused this heh [21:05] I did "git rebase -i develop" [21:05] But there also weren't any changes in develop since the last time I'd rebase'd [21:06] I've narrowed it down to test_machine_view_panel.js, line 375 [21:06] kadams54 trying a hunch [21:07] hunch was not correct [21:08] :-( [21:08] Wow, I really hate this. Now test-prod is failing with out of memory exception before it even gets into the testing… really?!? [21:11] kadams54 here http://stackoverflow.com/questions/134882/undoing-a-git-rebase [21:11] undo your rebase so we can get it back to a passing state [21:12] I'll give it a whirl in just a moment… [21:26] kadams54 yeah I have no idea why lastArguments would return undefined but only in test-prod [21:26] I'd have to step through it which would take a while heh [21:27] I'm undoing rebase right now [21:27] Confirmed that skipping that one test fixes things [21:27] yeah, the callCount on addMachines is 0 [21:27] but only in test-prod [21:28] I'm guessing it's a race condition because of your simulates [21:28] trying that fix [21:29] Oh hey [21:29] One thing that puzzled me [21:29] When I setup the test to run with .only [21:29] There were two failures in one test [21:29] Which seems like there are extra instances being created and getting into a race condition with each other [21:30] yeah so it looks like the simulates are causing the issues [21:30] you're executing this synchronously but it's executing asynchronously [21:31] just seeing if I can hack it into passing [21:31] to confirm [21:31] TypeError: 'null' is not an object (evaluating 'e.target.one("option:checked").get') (http://0.0.0.0:8888/juju-ui/assets/modules.js:13) [21:38] kadams54 ok I fixed it [21:38] but you'll need to fix it properly heh [21:40] lol [21:40] I'm just cleaning it up and getting you the diff [21:42] kadams54 https://gist.github.com/d12e15eb80c894d7b2cb here you go [21:42] so two issues [21:42] the option:selected for whatever reason doesn't want to work properly in test-prod [21:42] and the simulates need to happen after the previous event is finished [21:42] * kadams54 shakes his fist at PhantomJS [21:43] I hacked it using some setTimeouts but that's just a hack, you'll need to listen for the events and then simulate the events in the proper order [21:43] Your code doesn't work :-) [21:43] whaaaa [21:43] I tried looping through the options in a similar manner [21:43] Which works for the automated tests [21:43] But doesn't work in real life [21:44] why not? [21:44] When you select a new item in the browser, it doesn't update the selected attribute in the DOM [21:44] So you end up getting the option that was originally specified as selected, instead of the new one [21:44] That's when I switched to option:checked [21:45] I must not have pushed that change for the build that passed - only got pushed post-squash [21:45] ohhh [21:45] hmm [21:46] * kadams54 has a healthy loathing of dealing with selects in JS [21:46] I must have known that at some point haha [21:46] LOL [21:46] hmm ok well then [21:47] how r we guna do this! [21:48] oh duh [21:49] use selectedIndex [21:49] heh man I just failed hard [21:55] And it all comes back. [21:55] OK, selectedIndex fix on the way [21:55] But seriously, why are we still doing this? [21:56] Why oh why can't the pseudo selector just work?!? [21:56] standards bodies are more interested in making 'new' features like arrow functions instead of providing better ones that actually solve problems? [21:58] Well :checked is well supported by all the "real" browsers [21:58] true true [21:58] Apparently it's just PhantomJS that has issues [21:58] Regardless, I think manipulating selectedIndex will be a better approach for the test [21:59] we are a few releases back on the phantomjs so maybe we should update [21:59]