=== arosales_ is now known as arosales [01:55] Makyo still around? [01:55] he ran away [01:55] I would :P [01:55] hatch, yeah [01:55] lhaha [01:55] Ohhhh no :S [01:55] huwshimi: did I get your card right? You're working on the container token? [01:55] Makyo I think that you borked up the commits [01:56] hatch, They look right to me on my other comp, gimme a sec [01:56] Oh, ffs. [01:56] I had a local conflict on my develop. Let me see what I can do. [01:56] :) sorry [01:57] rick_h_: Yep, that's right [01:57] huwshimi: k cool [01:57] rick_h_: We don't currently have that data available though right? [01:57] hatch, fixed [01:58] Makyo cool thanks :) [01:58] huwshimi: well you should have data for 'bare metal' if you deploy a service [01:58] hatch, did rebase develop, instead of rebase juju/develop [01:58] huwshimi: but I don't think we've got a way to build data for the lxc/etc containers [01:59] rick_h_: Ah ok, I'll have a poke around. [01:59] ahhh, that's a good idea, I always pull down and update develop then rebase develop [01:59] I'll have to remember that [01:59] don't have to switch branches that way [02:01] Makyo I'll review/qa tonight, looks good at first glance though [02:31] hmm [03:04] so can gui display the name of the environment instead of the type of environment? [03:06] hazmat rick_h_ is working on that card now [03:07] hatch, thanks [03:07] no problemo [03:07] Makyo sorry I found a QA issue [03:09] should be straightforward name comes back on env.Info() call [03:10] hazmat I think the card he was working on was to add the ability to set the env name to whatever you want for demo [03:10] hatch, um.. [03:10] hatch, setting the env name to the actual env name would be good and preferrable [03:10] as in what the gui should be doing anyways [03:11] I haven't been partial to all of the discussions...I think there were some issues with doing that right away [03:12] rick_h_, ^ can we talk about this tomorrow [03:12] it's 11 there, might be best to email [03:13] sorry, I've been pretty head down, so much going on atm hah [03:14] hatch, why does destroyed remain true when init is called agian? [03:14] hmm.. found a gui export bug.. always does series as precise. [03:14] Will just add my own attr, nevermind. [03:15] Makyo I don't think a class instance can be 'un-destroyed' [03:15] That's what we're doing with the inspector. [03:15] I'll just add my own attr. [03:16] well...shoudln't we be destroying and creating a new inspector entirely? [03:16] just sharing the model? [03:17] hatch, Apparently not :P [03:17] hmm ok we should look into that [03:18] It's too late here. Ping me tomorrow morning? I'm out of brain. [03:18] yeah I'm the same :) [03:18] yeah lets investigate in the am [03:18] +1 [03:19] hazmat hmm yep that's definitely a bug, please do file a bug thanks :) [03:19] done [03:20] thanks [11:29] hazmat: rgr let me know. I was told they wanted special strings for demo vs something real so just hacking a branch [11:34] * frankban lunches [11:42] frankban: when you get back ping me please [11:53] afk taking boy to day care [12:13] back [12:33] rick_h_: I am back [12:34] guihelp: I need two reviews + QA for https://github.com/juju/juju-gui/pull/228 (local charm icons). Thanks! [12:35] frankban: the only other icon I think we HAVE to have for local charms in this case is in the inspector [12:35] frankban: as they'll pull that up in demos, but probably not the details page and you won't see a charm icon for it right now [12:35] rick_h_: the branch includes the inspector header icon [12:35] frankban: oh, you rock. One step ahead of me thanks! [12:36] frankban: will look, bac kadams54 please help with a second. This is very high priority [12:36] frankban, rick_h_ : sure, I'll take a look. [12:36] rick_h_: thanks, where is the details icon? I don;t see that [12:36] thank you both [12:37] frankban: there's a second card for the charm details and the charm tokens for local charms [12:37] frankban: but upon reflection don't think we need it for the demo [12:38] rick_h_: what's the case when a local charm has a token? [12:38] frankban: machine view and such. We'll have tokens with local charms that will need the icon [12:38] rick_h_: OIC [12:38] frankban: and the token and details shares a common method in the charmworld store [12:39] frankban: so making it work in the charmworld store will make it work in all places anyway [12:39] rick_h_: I am still not sure about icons in the charm details panel, I am not able to find an icon even for cs scharms [12:39] frankban: this is from the juju environment? [12:40] * rick_h_ isn't following [12:40] rick_h_: I mean, maybe I am looking at the wrong place, but if I open the charm details of a cs charm deployed on a real env, I don't see icons in the details panel [12:41] frankban: oh, no you're right [12:41] but that might change as well, though I'm not sure I guess. It shares the same details view as the normal charm browser details but it gets cut down. [12:41] rick_h_: but I guess that's not so important for now, I am going to work on the follow up branch for fallback icons in the gui server, shoudl be able to propose later [12:41] frankban: right now the header is turned off because of space/the way it flies out from the inspector [12:41] frankban: yep, I'll move that other card down from urgent, thanks [12:50] rick_h_: can we move down also the card about non-icon files? [12:50] frankban: yes [12:52] rick_h_: thank you. also this morning I QAed the final trusty quickstart package, Robie uploaded it and it should be ready soon [12:52] frankban: awesome! [12:52] * rick_h_ will be glad to get trusty behind us [12:52] yeah [12:53] rick_h_: is 1.18 the final trusty core release? [12:53] frankban: I'm not 100% sure. There's talk of a 1.20, but I don't think it's making it. [12:54] frankban: but the changes shouldn't effect us. I'm trying hard to keep an eye on the code reviews and such of core. [12:54] some interesting stuff in the pipes, new constraint types/etc. But nothing jumpout out as worrisome to us [12:55] rick_h_: cool, ok [12:55] frankban: there's talk of a CME? or some new type of exception to get an HA juju into trusty, and it was mentioned we might be able to use the same to get joyent into quickstart [12:55] but that would be post-release [12:55] post-release of trusty that is [12:56] ack [12:58] bah, /me drinks more coffee [12:59] cursed toddlers and not sleeping right [13:29] rick_h_: so the ghost charm has a mysql icon? [13:29] frankban: it's just how I tested it [13:29] I stuck the mysql icon into my local zip of hatch's ghost local charm and uploaded it [13:29] rick_h_: oh, ok :-) [13:32] hazmat: ping, so to verify the desire is to not have the ProviderType but the Name in there correct? [13:44] rick_h_, g'morning.. sleep provided enlightenment. ideal is env annotation for name, with fallback to actual env name. actual env name is fixed at bootstrap. [13:45] hazmat: so I've got two things I can do for you at the moment. http://paste.ubuntu.com/7226275/ [13:48] rick_h_, hmmm okay [13:49] rick_h_, also if i'm using a branch.. i need the charm to be able to use a release tarball within itself [13:49] hazmat: so right now we're shooint for you able to use trunk [13:49] rick_h_, ie. lp and archive net access only. [13:49] hazmat: and maybe even a release [13:49] rick_h_, well.. having the charm support using a tarball within itself would be useful [13:49] frankban: has icons landing, he's updating the charm as well, if I can get something in shortly you can use we'll have a full release [13:49] ie.. build hook style. [13:49] hazmat: it does do that, it's part of releaase [13:50] well, we have a releases directory [13:50] it's all self contained [13:50] rick_h_, cool [13:50] thus the desire to just make a release today if we can [13:50] and find a quick solution for your naming issues so that can push forward [13:50] had hoped to do a release tomorrow anyway [14:06] jujugui need a review and qa please. Requires a live env to complete qa https://github.com/juju/juju-gui/pull/229 [14:06] rick_h_ I can do it [14:06] hatch: ty sir [14:06] kadams54: how goes the check of frankban's branch? [14:06] did you say my ghost charm has a mysql icon? I was pretty sure the svg I created used their real icon.... [14:06] hatch: I needed a live icon to test that it was picking it up [14:07] Working on getting a live env up and running for it. juju-quickstart is working its magic right now [14:07] so saved the mysql svg and stuck it in the zip to test with :P [14:07] kadams54: awesome thanks [14:07] rick_h_ ohh ok so it wasn't picking up the one in the actual charm [14:07] gotha :) [14:07] sorry to press, kadams54, just wnat to make sure we can start release process after standup [14:07] Yeah, no problem [14:08] should probably do heavy qa just in case some of our new flagged work broke anything else :) [14:08] reminds me, Makyo qa day gentle reminder [14:08] hatch: definitely, hopefully some recent qa days help some and trying to qa some more while I wait for review [14:09] hatch: but think a release before your next few branches go in will be a good point of safety :) [14:10] a----greed! [14:11] :P [14:14] So the QA instructions say to deploy a local charm. Is there someplace I can get my hands on a charm? Or do I need to create one? [14:14] kadams54 download my ghost charm [14:15] link? [14:15] hatch: maybe get one with a custom icon already? [14:15] https://github.com/hatched/ghost-charm [14:15] skip the update step I did [14:15] it has a custom icon [14:15] k [14:15] oh, /me must have had an old download then [14:15] rick_h_ https://github.com/hatched/ghost-charm/blob/master/icon.svg [14:15] it's been in there fo eva [14:15] 5 months ago [14:16] yours didn't have that file? === hatch__ is now known as hatch [14:17] it had a file but didn't show as custom [14:17] showed as grey default [14:17] so that's why I dropped the mysql one on there [14:17] to make sure it was in fact getting a custom icon from teh charm itself [14:17] hmm [14:18] hatch: oh hmm I do see it locally [14:18] I don't have anything that can open a svg right now [14:18] well 'in my file browser' [14:18] does that icon in there look like the ghost icon? [14:18] kadams54: so ignore me, go with hatch [14:18] hatch: no [14:18] Oh, I do that by default. [14:18] ruh roh [14:18] hatch: ok, well not sure what I did then. [14:19] rick_h_ yeah the icon in the downloaded zip is the proper ghost svg icon... just tested in Ubuntu [14:19] so not sure what happened there.... [14:19] hatch: yep [14:19] ^ kadams54 if you don't see the ghost icon then there is a bug in the branch [14:19] OK [14:20] my vagrant image somehow deleted my .juju folder [14:20] .... [14:20] or the gui hates hatch's charm [14:20] that's ungood [14:20] impressed I am not [14:20] well it passes proof so... that means there is a bug somewhere :) [14:21] rick_h_ looks like you forgot to update the selenium test for the environment [14:21] http://ci.jujugui.org:8080/job/juju-gui/694/console [14:22] that might be the only real thing the selenium tests are actually testing lol [14:22] brb [14:24] hatch: yea, already have another run going [14:35] rick_h_: this can be interesting: https://github.com/frankban/juju-git-deploy/issues/1 [14:36] frankban: yes, I've been following that conversation. I didn't worry about it right now because we force users to select a series on upload of local charms [14:36] frankban: and we'll have to support that on ingest in charmworld soon as charms start to define it [14:37] rick_h_: yes, for the GUI right now is a nice to have IMHO [14:37] frankban: yep, but definitely on the radar and we'll have to make some adjustments going forward [14:37] that just got landed in 1.18 so we're still reacting [14:50] jujugui call in 10 kanban please [14:58] jujugui call in 2 [15:08] frankban: wrapped up QA. Looks good. [15:08] kadams54: cool thanks [15:09] jujugui oh was supposed to bring up release after frankban and my branches land. Will start gui releaase with a charm release after frankban's current branch lands for the demo [15:09] rick_h_: I can take a look at 229 now, since I setup a full env for frankban's branch [15:09] kadams54: k [15:09] kadams54: yea, should be able to just change the source branch again and see it in action in a live env [15:10] rick_h_: charm branch almost done, it would be nice to include that in the release [15:10] frankban: yes, will do [15:11] rick_h_: great thanks [15:11] frankban: I'll just start the gui release once our branches land, and will get gui release after the WIP. [15:11] rick_h_: sounds good [15:11] frankban: we've got until noon est tomorrow I think? but will try to get it to hazmat by tonight sometime [15:12] rick_h_: yeah, if you don;t have time today, and the the GUI release is done, I can take care of the charm release tomorrow morning [15:14] frankban: rgr [15:19] rick_h_ sorry, for whatever reason this vagrant image has 0 juju bits so it's taking a bit to get set up then I'll finish the QA [15:26] hatch: k, I think kadams54 volunteered to do qa [15:26] hatch: so if you want to split review and qa with him I'd appreciate it [15:26] ok awesome [15:27] I'd like to get on to working heh [15:27] codereview done [15:27] hatch: rgr, have fun [15:27] thanks for the review [15:32] rick_h_ can we maybe remove the id then? It's just a little confusing [15:32] I prefer classes anyways :) [15:33] hatch: maybe, there's some login stuff that hits that specifically as an id [15:33] hatch: I'll add a note to the follow up card to generate better looking names [15:33] ahh ok cool np [15:36] QA is good [15:36] kadams54: awesome ty much. What did it read for you? [15:36] "test on ec2" [15:36] cool [15:37] That would've been really embarrassing if I'd named my environment something like "I'm a lumberjack and I'm OK" [15:37] :) [15:39] * hatch is changing his environment to be "the empire" [15:40] lol [15:40] "the empire on ec2" had a nice ring to it [15:53] right?! [16:04] guihelp: high priority branch ready for for review: https://codereview.appspot.com/86100043 (charm/python). Anyone available? thanks [16:05] frankban: i can review but not qa atm [16:05] nah, i can QA too [16:05] frankban: will look/qa [16:05] or bac has it [16:05] * bac has it [16:06] heh, thank you! [16:07] does anyone know if there are any side effects to comparing two objects by converting them to json? [16:07] hatch: potential ordering issue? [16:07] that's valid [16:07] bleh I really don't want to write a recursive object comparison method [16:07] maybe the internets have something [16:07] YUI is always missing something [16:08] hatch: what do we need to compare? [16:08] previous/parsed state [16:08] hatch: but typically we check a single thing right? not mass changes in nested objects? [16:09] when the url changes I need to know if the state object generated is different in order to dispatch or not [16:09] hatch: always dispatch and the dispatch methods are smart [16:10] the dispatch methods have to be anyway [16:10] so not saving any code on that end [16:10] the only case you're saving is if "nothing at all changed, don't do anything" you still need to check if 'this one thing changed, or that one thing did' [16:11] well I was only going to dispatch the changed items [16:11] but the decisions are more complicated than that [16:11] check out the existing stuff [16:11] you can't just dispatch the one thing, you have to know what did/didn't in concert, at least that's the experience so far [16:12] I thought the point was to dipatch to two controllers, one for each section, that then decided what to draw/render/destroy? [16:12] yeah I was trying to write something smarter than that [16:12] s/trying to write/writing/ [16:13] apparently my s/ stopped working [16:13] ok I can do a 'dumb' dispatch [16:13] maybe start dumb and look for refactoring chances as the patterns emerge? [16:14] but try not to think too far ahead of what we need to move forward [16:14] ? [16:14] it's that thinking that got us into all of our messes haha [16:15] ok question [16:15] if the state 'changes' to the exact same state, does previous still get set to current? then previous and current will be the same [16:15] I don't quite think that's fair. as the mess isn't to do with that pattern of code/refactor [16:15] inspector issue was lack of foresight for sure [16:16] hatch: how does the change end up the exact same state? [16:16] say you click on the machine view button again and again [16:16] ? [16:16] hatch, branch updated. [16:16] there's that...but if you say have a /fullscreen/ url and then navigate to the 'proper' url the outcome state will be identical [16:17] hatch: ok, exept you'll dispatch the new url which will have fullscreen removed [16:17] so I don't think I should update the previous state unless they truly are different [16:17] hatch: so the state is the same, but the url is updated for the user [16:17] exactly, the state didn't change....but the current code will update the previous state to the current state which is the same [16:17] Makyo thanks, I'll take a look in a bit [16:17] and in that case the prev/new state are the same, but who cares. If you hit the back button nothing changed because there was nothing to change to [16:18] hatch: right, but to what damage? the only way to get a fullscren url is to enter it or go to a bookmark [16:18] there's no prev state to mess with anyway [16:18] so there's no harm, no complication, or issue with updating the prev state [16:18] that I can see atm [16:22] i suppose if the user clicks back and the url changes but nothing in the UI changes that would be alright [16:22] they are old/invalid urls now anyways [16:24] I agree. It's not worth a primary concern/test case. It's deprecated behavior. It should 'work' but the odds of hitting it and the experience detriment to the user is minimal. [16:33] frankban: if you get a few min can we chat about guiserver? [16:34] rick_h_: sure, now is ok [16:34] frankban: https://plus.google.com/hangouts/_/72cpjuub3p0v5iljobcmvkevb8?hl=en thanks [16:49] bac: thanks for the review, are you QAing it? [16:49] frankban: yes [16:49] cool [16:50] * rick_h_ goes to make lunch before starting the release launch process [17:05] frankban: doing QA everthing is getting the default icon. i deployed a zip with mongodb which has an icon.svg but it gets the default as does a local charm with no icon. [17:05] bac: juju version? [17:06] frankban: hmm, handbuilt from 1.18 [17:06] r2262 [17:06] bac: should be ok, is develop correctly installed? [17:07] bac: I mean, the GUI trunk [17:07] correctly installed where? [17:07] juju-gui-source=develop, it takes some time [17:07] yes i did that [17:07] and that causes it to fetch it anew, correct? [17:08] bac: yes it builds a release from trunk [17:08] right. [17:08] jujugui could I get another set of eyes on this WIP https://github.com/juju/juju-gui/pull/230 before I write the tests....It's the dispatcher implementation for the state manager [17:09] hatch: Taking a look [17:09] kadams54 thx [17:09] My eyes! They burn! [17:09] bac: some browser cache? [17:09] Makyo ok looking at your branch now [17:10] kadams54 lol - hey this is a lot simpler than the original implementation I had planned :) [17:10] * frankban bbiab [17:12] frankban: that was it. cleared cache and then mongo got its icon [17:12] upon next deploy [17:12] QA-AOK. lunch commences. [17:14] hatch: am I correct in thinking that sectionA == sidebar and sectionB == content? [17:14] yup [17:17] So the dispatch stuff - is that pulled over from browser.js? [17:19] kadams54: some of it yes, the routeView and such turns into this state dispatch work [17:19] kadams54: the actually dispatch methods are app logic that can live in browser.js still I think, but not 100% sure on hatch's plan [17:19] hey rick_h_ [17:19] local bundles working and whatnot, that's EOD today still? [17:20] local bundles don't work, local icons getting shown is landed and I'm about to start a gui release that will include it [17:20] jcastro: I'll be on the 3:30pm call to update and with progress, but trying to get an updated gui release/charm with the changes required right now [17:20] rick_h_ yep you're dead on, I figured the view rendering logic should be in the browser not in the state manager cc kadams54 [17:20] * jcastro nods [17:21] send beers to frankban in quantity [17:21] yeah that was a solid branch frankban in such a quick time [17:21] ^5 [17:22] speaking of [17:22] jujugui release process is starting. Please no :shipit: until done [17:22] sorry for the blockage [17:22] roger [17:24] hatch: review doen [17:24] done even [17:24] cool thanks I'll take a look in a second [17:32] Makyo review and qa done [17:36] kadams54 I don't understand the context of your last comment [18:06] rick_h_: charm branch landed! have a nice evening [18:06] hatch: Sorry, review on https://github.com/juju/juju-gui/pull/230 is done [18:07] frankban: woot thanks, 1.0.2 is built so working on charm now [18:07] kadams54 I mean the context of your last review comment [18:07] rick_h_: cool [18:08] hatch: state used to be stored in raw objects (_current and _previous), now it looks like you've moved to a Model… was wondering what advantages prompted the change? [18:09] ohh I moved it to an attribute [18:09] we cna chat about it in a bit though [18:10] Hangout? [18:11] yeah just in a call now [18:11] OK, ping me when ready [18:21] kadams54 when r u back from pycon? [18:21] 4/17 [18:25] kadams54 https://plus.google.com/hangouts/_/72cpjpk8lfbqkkqmr8ram0gglc?hl=en [18:26] kadams54: make sure that if you cna't finsh your branch you get it handed off before you EOD so that it won't hang for the week away please [18:27] Yup [18:42] jujugui I have graze box invites if anyone wants. [18:42] i do! (what is it?) [18:42] oh, no i don't [18:42] Hahaha [18:42] No snack boxes? [18:43] ?? [18:43] https://www.graze.com/us/products [18:44] Makyo: they'd probably be stale and soggy by the time they got here [18:44] super paranoid? check out the chromebleed extension [18:44] Yeah, I'm curious to see how it works over the summer. [18:44] wow these order food online things are popping up everywhere, must be huge margins [18:44] hatch: yeah, like pets.com [18:45] hah yepp [18:45] those were the days. 50# of dog food delivered for free... [18:48] *dreamy sigh* [18:48] Two shepherds go through a lot of food. [18:49] Especially when one's a big chunk. [18:51] jujugui heads up release is done and safe to land again [18:51] yay [18:51] jujugui just working on the charm release part now [19:08] here we go...charm functional tests. [19:08] wheeee [19:08] blog post time I suppose [19:44] weeee [19:47] new roof this weekend...oooo boy [19:48] wheee [19:48] not going to enjoy THAT bill [19:49] but, gota be done I suppose [19:50] jujugui anyone recognize http://paste.ubuntu.com/7227836/ running charm tests? [19:50] I've got the ec2 env set to precise as default series [19:50] yikes [19:51] rick_h_: sure you aren't running local? [19:52] bac: yes, I can see the aws instance running [19:52] bac: now the tests are trying to colocate the unit on machine 0 in teh test env on ec2 [19:52] and I can verify a .juju/environments/ec2.jenv is created withthe default series set to precise [19:53] rick_h_: i believe you. just looks like what you get when you try to run functional tests on lxc [19:53] bac: yea [19:53] juju status shows 0 is precise? [19:54] agent-state: pending [19:54] instance-id: i-3eb9876f [19:54] series: precise [19:54] yep [19:59] Makyo wow people really liked my growth hacking tweet lol [19:59] some even say they ARE 'growth hackers'....I wonder if they missed the sarcasm.... [20:07] rick_h_ lastpass is so cool http://blog.lastpass.com/2014/04/lastpass-now-checks-if-your-sites-are.html [20:07] :) been there done that [20:08] it's just nice to see that they are actually doing stuff like that instead of just making a 'dumb' storage app [20:08] very cool [20:16] kadams54 it's nearing your EOD no? Need any help to get your branch ready by EOD? [20:17]