[00:19] hatch: kinda, fish tank cleaning [00:19] while we were chatting my son dumped all the fish food into the tank [00:19] emergency cleaning in progress :/ [00:19] hatch: what solution is this? [00:21] lol, well it's pretty trivial tbh heh https://gist.github.com/hatched/2dd9628d46be512cc753 [00:21] ^ rick_h but it comes with an odd bug, if I click 'browse' after viewing the inspector it shows the sidebar opened with only the categories....not the fullscreen [00:24] looking [00:26] yae, not sure what it's doing. Will have to debug the viewState and see what's getting set [00:26] this seems strange imo [00:26] we don't need the 67-70 stuff I thought, just left over from debuggin? [00:27] had to add it back in because it wasn't being set properly [00:27] ah, if things are minimized, the old viewmode is never set to _XXXX [00:27] makes sense [00:27] yea, die hidden stuff die [00:27] I'm glad you understand it because I sure don't heh [00:28] so can i push this up and then email it you to to take over in the am? [00:28] well, if we're updating the viewState to sidebar, then the next request we try to remove _sidebar.destroy() [00:28] but we never set this._sidebar because it was hidden [00:28] hatch: sure thing, I think I understand the issues enough to get it going. [00:29] ok great - I really want to use every available hour to try and get this release out tomorrow and there are still the two other bugs [00:29] thanks - I'll push and email to you [00:29] hatch: rgr === schwuk_away is now known as schwuk === schwuk is now known as schwuk_away [11:09] luca__: morning, so with your email, the goal is to setup an collapsable accordian effect then? With the three headings always visible and the content of them scrollable? [11:13] morning rick_h [11:14] sort of, Jeff knows what we are after, are you working on it now or can you wait to talk to him? [11:14] rick_h: because he did it wrong to start with and Gary got a bit annoyed over the wasted effort [11:14] luca__: we can wait. not a problem. I'll be getting back to it soon (late today/tomorrow?) and wanted to clarify what the goals were. [11:14] luca__: ah, this is the sticky header business? [11:15] rick_h: yes :) [11:15] luca__: nvm, I got it then. I took a stab at it at one point so I gotcha. [12:07] hey hazmat: when you have time, could you please take a look at https://code.launchpad.net/~frankban/juju-deployer/guiserver-changes/+merge/182369 ? [12:13] jujugui small review please for when people get in and need something to read with their coffee https://codereview.appspot.com/13276043/ [12:15] rick_h, did you resolve with Jeff or Ben why it used to be a databinding? The ony value I can see to the databinding is if the charm is updated and the icon changes, I guess? [12:17] gary_poster: the issue before was that there wasn't the store doing icon stuff and I think it started out hoping we could generate the paths/logic in there [12:17] gary_poster: but no, I didn't check on why databinding. I remeber talking with bcsaller when he added it and it was a 'show something' because the store integration wasn't ready yet [12:18] ok cool. if it is not clear how to do it with databinding then the win seems relatively small and I'm fine with the nice-n-simple approach you have here [12:19] gary_poster: yea, I was going to do data binding thinking it was a case of "if the user opens another charm we can reuse the rendered html and update the data displayed with data binding" [12:19] however, the *only* attribute data bound was the icon [12:19] so I think it was a case of 'let's just hack this in' gone wild :) [12:19] lol [12:20] oh so that code is *only* for the ghost? the post-deploy is different code? [12:21] gary_poster: no, I think that it's shared. However, the post-deploy can generate the icon the same way [12:22] or I just broke the normal way...so take that review request back :/ [12:26] rick_h, I dunno, I could go either way. I assumed it was shared when I said "if it is not clear how to do it with databinding then the win seems relatively small and I'm fine with the nice-n-simple approach you have here." OTOH if you are fairly convinced of the win for the post-deploy scenario, I'll leave you to it [12:26] gary_poster: yea, so I'm not sure how it fits atm. Basically I've found that from the store the charm model has a charmId field to generate the icon. [12:26] from the already deployed charm that attribute isn't in the model there. [12:27] however, charmUrl is in both, and that works to generate the right icon url [12:27] gary_poster: so working on adding a test to both cases so that if this breaks it shows up [12:27] gary_poster: e.g. I broke the icon in the non-ghost case and so adding a test to say it's fixed. [12:28] rick_h, ok cool. I'll leave the branch alone for now then. === schwuk_away is now known as schwuk [12:55] gary_poster: got it figured out. Missed the service vs charm model case handling in there. Updated with an extra test to catch. [12:55] cool rick_h, looking again [13:06] Morning gary_poster, welcome back [13:06] sinzui: Could we do a catch-up chat this morning? [13:08] bac: in r362, it looks like you've changed use_context so that __exit__ is run even if __enter__ fails. Is that intentional? [13:12] hey luca__, thank you :-) [13:14] abentley: it was my intent to register the cleanup early but didn't take into consideration what happens if __enter__ failed. [13:14] bac: Why did you want to do that? [13:15] abentley: i was working on the problem that adeuring now has with spurious test failures and it looked like the test index was not properly being cleaned up [13:16] abentley, sure. I can telling about how charmworld tip is incompatible with 2 migrations and It is time to upgrade pyelasticsearch [13:17] bac: Ah. I think we should change it back, though. It was registering the cleanup as soon as it was safe to do so. [13:17] abentley: i can do that in my current branch [13:17] sinzui: Now? [13:18] abentley, sure [13:58] hey luca__ I just got to your "Juju business assumptions" email. I'm guessing I should not bother to reply since the deadline is long past now? :-) [13:58] gary_poster: Heya, no need now, but thanks anyway :D [13:58] luca__, cool :-) [13:59] bac, benji, rick_h, The charmworld deployment failed because r363+ is incompatible with two migrations in earlier revisions [13:59] hatch: when you're around have a fix for the issue from yesterday. http://paste.mitechie.com/show/1007/ is the diff and lp:~rharding/juju-gui/browser-fix-1217060 is the branch. Adding some tests and will have it up for review later. [13:59] darn [13:59] hatch: then I'll be taking a strong bath for the evils committed [13:59] sinzui: :( [13:59] I will ask for 3 deployments today to deploy each migration at the point it has code. [14:00] that was compatible [14:00] migrations are fun! :) [14:00] well maybe to because I think one migration was a correction for m16 [14:00] we should think about how to avoid this problem in the future [14:00] sinzui: time to rollup and redeploy on -core? :) [14:01] Not today [14:01] right, benji. one approach is that we should treat a migration file as a migration in production, and devs have to deal with figuring out how to test re-migrations [14:02] that seems simplest to me, and every other idea I have is a more complex approach for questionable benefit [14:02] gary_poster: I'm trying to remember how we ended up dealing with migrations (or "generations" back then) in the Z4M project. We ended up in a place that worked really well, but I'll have to remember the details. [14:03] benji, IIRC it was the open source zope generations. the trick was that ZODB would remember the generation it had, and then run through *all* generations [14:03] from last run to current [14:04] but that is still potentially riskier in a DB/env not as flexible as ZODB [14:04] reasonable but not sufficient, I'd suggest, IOW [14:04] that might be how the mechanism worked, but we came up with a set of procedures that actually avoided most of the mechanism but still worked well; it'll take a while for me to remember [14:04] ok [14:06] rick_h: ahh you went with the controls binding approach [14:06] hatch: yea, I think that contains the 'evil' the most [14:06] hatch: I didn't follow where you were headed with the removing of the whole check entirely and such tbh [14:07] ohh, all I was doing was minimizing the sidebar when the user opened the full inspector [14:07] hatch: yea, but then you still have the button to un-minimize visible and such [14:07] so the check was no longer needed becasue the browser was still on top of the inspector [14:07] hatch: so there's UX conflict [14:07] benji could you add Friday card about topic pls? [14:08] shhhh [14:08] they wouldn't know [14:08] jujugui for the later morning coffee crowd, some light reading https://codereview.appspot.com/13276043/ [14:08] rick_h, ugh, I got lost [14:08] gary_poster: I'm sory you get lost? [14:09] give review to someone else rick_h [14:09] ah, you mean review stuff. All good. [14:09] gary_poster: yea, I'll but the western peeps :) [14:09] cool [14:09] or jcsackettcif he's aroud today [14:09] grrr mobile internet lag [14:09] rick_h: i'll take one of the reviews [14:09] hatch: ty much [14:10] hatch: note this is a diff card than the one we've been going over. [14:10] just fyi to avoid crossing the streams [14:12] gary_poster: card added [14:12] thx [14:36] morning antdillon [14:36] Morning hatch [14:50] mark uds keynote talking about cloud-ish now. http://summit.ubuntu.com/uds-1308/meeting/21887/intro-and-keynote/ [14:51] thx [14:55] hey it's the GUI! [14:56] bac, benji, your revisions are now in production. I think we want a branch to remove the migrations since we know they are not all compatible with tip [14:57] yeah, I think so [14:57] sinzui: I'll make a card [15:01] "our less-fortunate brethren" Hah. [15:01] haha yeah I laughed [15:02] antdillon: do you have any idea what cellular frequencies are available there? [15:02] my google fu is returning conflicting details [15:06] hatch, GSM 900 or 1800 [15:06] hatch, http://www.ofcom.org.uk/static/archive/ra/topics/pmc/document/licencetypes/cellularinfo.htm#4 [15:07] ahh nice the HTC One's in Canada have 850/900/1800/1900 GSM [15:08] antdillon: is this rumor of sims in vending machines at the airport true? [15:08] antdillon: it seems like a candy land of mobile connectivity [15:09] rick_h, Almost, there is all way a booth selling sim cards [15:09] awww right on [15:09] guess I'll be going to get the new phone at lunch and unlocking at night haha [15:09] rick_h, Or giving them away as long as you put some credit it on it [15:10] antdillon: cool, yea I'll have a gsm mifi that'll need some sim love [15:10] since I don't have a GSM phone :( [15:10] stupid verizon [15:10] * hatch steals the wifi from rick_h [15:10] hatch: sure thing. It's what I did before. Wifi'd my phone to the mifi and used it to get directions to dinner! [15:10] I can see some wifi wars coming up [15:11] hah [15:11] haha nice! [15:11] I'm going to get the HTC One because there are awesome Android 4.3 roms for it, ANNND Ubuntu Touch port :D [15:11] cool, I'm still holding out for nexus 5. I'm not due up for a couple more months. [15:11] but then I'll be switching to t-mobile and I'll have gsm [15:11] so less of an issue with this traveling [15:11] hatch: i recall last time i was there one of the good deals on pre-paid sims was at tesco, the grocery chain [15:12] rick_h: yeah I'm sick of waiting, which means a new better phone will come out next week [15:12] lol [15:12] bac: when I tested out the mifi here on ATT to make sure it worked it cost me $30 for 300mb good for 7 days. I've got low expectations. [15:12] benji: would you have time to look at https://code.launchpad.net/~bac/charmworld/link-to-basket-on-lp/+merge/182415 [15:12] bac: sure [15:13] bac: in copenhagen I got 1gb of data for 12months for $13 [15:13] hahaha [15:13] rick_h: yeah, we are ripped off and don't realize it [15:13] bac: oh we realize it, but lack of options [15:14] rick_h: in VN i could go 3 weeks with heavy data use (i get lost a lot) on a $2.50 top-off [15:18] bac: your branch looks good [15:19] thanks benji [15:21] jujugui and hatch in particular, review #2 please for giant hacky bug. Please look away while reading. https://codereview.appspot.com/13282043/ [15:22] and time to head back from the coffee shop, back in a minute [15:24] thanks rick_h [15:47] Makyo: thanks for the review. Do you have time to look at smaller/more sane other one? https://codereview.appspot.com/13276043/ [15:48] rick_h sure [15:49] thanks Makyo, appreciate it [15:49] jujugui guichat in 10 [15:53] jujugui and the charmworld folks, might be interseted in https://pypi.python.org/pypi/nose-selecttests/0.4 [15:54] looks nice. funny that functionality is not part of nose generally, but yay for plugins I guess [15:56] rick_h: after your branches land can you let me know so I can re-qa the remaining two bugs in Urgent to see if those fixes fix those bugs [15:56] gary_poster, nostalgic for zope.testrunner ? ;-) [15:56] hatch: rgr [15:56] hazmat, exactly :-) [15:58] jujugui guichat in 2min [16:01] frankban, you around for call? [16:01] jujugui: i appear to be the only one on the call...did the appointment hangout get borked, as i can't imagine that's right. [16:02] jcsackett, try guichat [16:02] gary_poster: oh, duh. of course. [16:02] thanks. [16:02] np [16:02] <--- needs more coffee [16:02] jcsackett: i think the link in the calendar is broken [16:03] bac: yeah, it is. i don't know why i was trying to use it instead of guichat. [16:11] rick_h: https://codereview.appspot.com/12741051 [16:11] thank you [16:12] frankban: thanks [16:24] adeuring: We may want to change our pattern so that instead of creating an index and then putting the mapping, we supply the mapping at index creation time: http://www.elasticsearch.org/guide/reference/api/admin-indices-create-index/ [16:25] abentley: ah, very intersting. Let me try that. It would most likely fix a problem with temp_index_client() [16:26] adeuring: Doing a refresh may also give us a way to wait until the index is present: http://www.elasticsearch.org/guide/reference/api/admin-indices-refresh/ [16:26] right [16:28] rick_h: the branch fixed the two outstanding urgent bugs [16:28] * hatch goes back to QA'ing [16:28] hatch: woot! [16:28] hatch: had hoped so. [16:28] must have been the state update and some odd race condition [16:29] hatch: I think it was the same thing. The viewmode controls weren't bound right in the non-browser state [16:38] Inbox zero! kinda sorta. I have a few emails tagged I have to deal with. But anyway, I'm taking a lunch break in celebration. [16:39] woot! only two days, email master! [16:40] rick_h: found another bug [16:40] hatch: stop doing that [16:41] rick_h: haha sorry :) https://bugs.launchpad.net/juju-gui/+bug/1217449 [16:41] <_mup_> Bug #1217449: Sidebar won't minimize after viewing unit list [16:41] can you look at it now? [16:41] hatch: reviewing right now, can afterwards [16:42] ok assigning to you [16:42] rgr [16:42] guihelp: anyone available for reviewing a js branch? https://codereview.appspot.com/13286043 This should land asap, before further env/ws tests are added. [16:43] frankban: I'll take one if no one else does (just want to finish this QA pass) [16:43] hatch: thank you [16:45] rick_h: probably related https://bugs.launchpad.net/juju-gui/+bug/1217450 [16:45] <_mup_> Bug #1217450: Browse button shows empty sidebar after clicking Juju logo [16:47] frankban: looking [16:47] rick_h: thanks [16:48] frankban: do we have tests for the Go portion of these tests which you set the default to be 'python' ? [16:52] hatch: yes, I believe so, everything is more directly tested in the test_env_* files. [16:52] great [16:57] hatch: re (actual, expected), is it a JS guideline? [16:57] frankban: it's the syntax for the nodejs assertion library [16:57] http://nodejs.org/api/assert.html [16:57] for the full api [16:57] it doesn't cause any issues, just creates confusing error messages when the tests fail :) [16:59] hatch: interesting, I am used to expected first, and I am pretty sure I always did that in all my js branches :-) the error messages are usually confused by default, especially when you use deepEqual :-) [16:59] oh I know...I also think that expected should be first [17:00] that's why I left the decision to switch it to you :D [17:01] thanks hatch, perhaps we can clean up this stuff later with a mechanical branch [17:01] sure thing [17:08] rick_h: I'm taking off for an early lunch I believe the two tickets in urgent are related [17:08] but I* [17:08] hatch yea, looking at them now [17:08] great thanks a lot! === schwuk is now known as schwuk_away [17:08] bbl [17:18] abentley: do you have a few minutes to review my "respect charm versions in APIv3" branch? https://code.launchpad.net/~benji/charmworld/versioned-charm-api/+merge/182450 [17:40] benji: looking... [17:58] rick_h: back [17:58] need any help with that stuff now? [17:59] hatch: no, think I've got it. Just sanity checking and debating on testing/etc [17:59] hatch: fixes both of them [17:59] awesome thanks [17:59] * hatch picked up the HTC One [17:59] chose a new store this time and was in and out in 10mins [18:00] hatch: very cool, jealous. You'll have to let me check in out next week ;) [18:00] yep, now I'm stuck in a 3 year [18:00] haha [18:00] 3yr?! ouch! [18:00] I get ancy before 2yrs [18:02] it's not like i'm going to go with another provider so it's just picking the option that made the phone the cheapest [18:02] it was $100 [18:03] I'm pumped that I am able to disable apps now [18:04] bye bye Facebook [18:04] although after I get back it'll likely be getting a rom anyways [18:07] hatch: I've got one issue I'm not able to see wtf atm [18:07] hatch: got a second? [18:07] yup [18:08] in guichat [18:38] rick_h: about to test [18:38] sorry make hung [18:38] hatch: ok, I've got a couple test failures from it working out [18:39] rick_h: I got it to fail but then if I let it sit, the gui portion goes away [18:39] lol [18:39] it's like a few second delay [18:39] *UGH* [18:39] hatch: make sure to clear cache and such [18:39] I don't know...just trying to find some excuse it could be something else [18:41] now I can't repro :/ [18:43] repro'd [18:43] now how... [18:44] it's like there is a race condition [18:44] sometimes I can see a 'flash' of the inspector as the sidebar comes up [18:45] hatch: k, well hack inbound. Give me a few min [18:46] alright thanks [18:59] benji: sorry for the delay. Was ambushed by a UDS session. [19:00] CRIKEY! Isn't she a beauty?! [19:00] * benji watches abently wrestle with the wild UDS session. [19:08] hatch: guichat? [19:08] there [19:31] rick_h: :( [19:31] dbl click > Build > Juju (...and repeat) still happens [19:34] rick_h: does that not have an issue for you still? [19:34] hatch: looking [19:35] the dbl click is on the service of course [19:36] hatch: ok, something is setting renderEnvironment to false. Looking [19:38] hatch: ok, so when I navigate with clearAllNameSpaces, it's hitting back into the toggleStaticViews with a url :gui;/service... [19:39] then I get the message 'waiting on service data' and that causes anothewr dispatch to go through that clears it [19:39] hatch: so my navigate() command isn't 'die gui die' enough [19:40] lol [19:40] hatch: so how would I generate a _navigate that manually set :gui:/ [19:40] vs :gui:/service... [19:40] ? [19:42] there is a url method on the nsrouter [19:42] which you pass a config object to [19:42] and it generates a url for you [19:42] see line 1307 in app.js as an example [19:43] looking [19:48] benji: "Featured bundle UI" looks redundant with "User innterface to (un)set a bundle as featured". [19:49] abentley: it does, are those card titles? [19:49] benji: Yes. [19:49] benji: You're assigned to one, but not the other. [19:49] abentley: will you kill one of them for me? [19:49] hatch: I don't get this...I navigate to a fresh url but the url in req.url in toggleStaticViews is still :gui:/service... [19:50] benji: Done. [19:50] thanks [19:50] sinzui: Do you know what "charmworld should serve README in same pattern as charm" means? [19:51] rick_h: so the url in the address bar is empty? [19:51] minus the hostname [19:51] hatch: no, it's got :gui:/service/mongodb [19:51] abentley, not immediately [19:51] oh ok, so then that makes sense? [19:52] abentley, and not after a few moments of thought [19:52] hatch: no, so I run this.navigate(new_url); [19:52] hatch: and in the views the url is the old url [19:52] bac: What does your card "charmworld should serve README in same pattern as charm" mean? [19:52] hatch: guichat again? sorry [19:52] sure [19:53] abentley, bundles need a readme, and the cw page should render it? [19:53] abentley: better? "(nice to have) charmworld should serve README for bundle in same manner as for charms" [19:54] bac: Much better. I didn't understand that it was about bundles. [19:54] abentley: i am going to mark it blocked on my current branch, though [19:54] bac: Okay. [20:27] bcsaller: kickin around? [20:27] hatch: yeah [20:27] whats up? [20:27] mind poping into guichat? [20:28] with rick and i [20:45] abentley: thanks for the good review; I've made all the requested changes -- I think ;) [20:48] benji: looking... [21:11] bcsaller: rick_h gg :P [21:12] hatch: heh, let me know how far you get. I can finish up/clean up in the morning. A simple test on the initState should work to make sure it's cleaning [21:12] hatch: that's really the only *change* that's needed is that stupid initState method [21:12] haha right [21:12] I'm outta here... [21:12] I'll send you an email with as far as I get [21:12] have a good night [21:13] hatch: sorry to delay the release :( [21:13] * hatch shakes fist [21:13] lol np [21:13] hatch: or feel free to leave it, Probably not getting 2 reviewd and such to release today anyway [21:13] I'll have it up ready to go before you start tomorrow [21:13] oh ok can do that too [21:14] I can move onto other things [21:14] ok so I'll leave it then [21:14] yea, up to you. I know I'm blocking you and don't want to, but not sure how much you'll get anyway :/ [21:14] cool, thanks for the help/talk throughs [21:56] bac: your revisions are on staging