[00:22] gary_poster: blog post is up http://fromanegg.com/post/60978144670/juju-gui-0-9-0-released-now-with-ie10-support [00:23] awesome hatch, thanks! the new charm search doesn't suck either, btw, if you are looking for features. :-) [00:24] right I forgot about that oops :) logging in to add that [00:27] updated [00:28] OO boy saucy is fast compared to 12.04 [00:28] even in this vm, I wish I could run it on my laptop! === frankban__ is now known as frankban [11:16] hey frankban__ . welcome back for two days. :-) I approved expenses. [11:17] gary_poster: thanks! === frankban__ is now known as frankban [11:18] the connection here is not good at all :-/ [11:18] :-/ [12:26] * frankban lunches [12:35] morning [12:35] morning [12:51] have you guys been following the thread about the new email client? [12:51] hatch: somewhat [12:52] I think I have figured out why linux apps are ugly [12:52] :) [12:52] lol [12:52] haha [12:54] so I installed saucy - still getting everything up and running...... [12:54] but as far as styling goes [12:54] the top bar and the window controls don't match the rest of the UX [12:54] hatch: you using vmware? [12:54] parallels [12:55] bac: it pretty much worked 100% out of the box. I just had to install the parallels tools to get 3d acceleration and being able to move the mouse over the window to control it [12:56] hatch: are you able to have it start in the display size you want? mine boots into the highest res which is unusable. not a big issue since i don't reboot much but it is annoying [12:56] I run it in windowed mode [12:56] hatch: i'm using vwmare [12:56] oh, ok [12:57] lemme see what it does in fs mode [12:58] it is the highest res but looks proper [12:59] I am not sure what the ppi of my monitor is [13:01] bac has super duper high Mac res :-) [13:02] rietveld is giving me "error: old chunk mismatch" on my review [13:02] gary_poster: you can try running it again [13:02] what can I do to fix it? repropose? [13:02] sometimes that helps [13:02] gary_poster: i've never understood why that happens [13:02] ok trying, thanks [13:03] yeah I'm pretty sure my monitor isn't 'retina' 2560x1600@30" [13:04] gary_poster: I've had to ditch it and use a diff branch name before as well. So create a new colo-branch, merge in the old branch, push to a new branch name, repropose [13:05] I'm going to land huw's branch [13:05] it QA's ok [13:08] rick_h_, ack :-/ [13:08] hatch, awesome thanks [13:08] reproposing did not help [13:10] rick_h_ brought up http://www.reviewboard.org/ not sure if we want to switch but it does look pretty cool :) [13:10] hatch: heh, well we don't have the scripts/tools for it, a hosted instance, etc [13:10] we have the technology!!!! [13:10] at least I'd hope we could host an app :P [13:11] although -not- hosting/paying for something is pretty awesome [13:11] even if it does break all the time [13:11] gary_poster: we can just review on lp [13:12] hatch, ack thanks. Trying one more time: I made a change to comments, pushed to lp, and reproposed... [13:14] bac: hatch updates here https://codereview.appspot.com/13516044 [13:14] yay, that worked [13:14] hatch: with some comments on the conflictux stuff [13:17] cool i'll take a look in a second [13:17] cool, had to sync with trunk and resolve a conflict so pushing up again [13:18] rick_h_: so you don't think that we should add the ability to skip the conflict in databinding? My thoughts were that, because we were parsing the html to add the databinding, it could make sense to also use the html parsing to turn off features... [13:19] re skipconflictus [13:19] ux [13:19] hatch: no, databinding's job is to say "Hey, this changed". What you do on that change is someone else's job. [13:19] I don't feel strongly about this [13:19] hatch: in this case conflict says if classes/etc get added [13:19] yeah I suppose that's reasonable [13:19] hatch: and long term we might want to handle something but not all of the conflictux, so I feel that's up to conflictux to decide [13:20] yeah - it feels like it could be standardized somehow and moving it into the databinding would do that [13:20] so just 'don't fire change' seems like breaking twigs with an axe [13:20] hatch: I agree that it could use some cleanup. I'd prefer to move the databinding stuff to it's own module and try to see if we could pull apart some of the bits (say...events from databinding that conflict ux could watch for) [13:20] but that's not for here/now [13:20] sorry, the conflictux stuff to its own module [13:21] yeah....because really I could see use for databinding with no conflict [13:21] hatch: 100% [13:23] hatch: did your relations tab headings make it in? /me isn't seeing it in a sync'd with trunk [13:25] rick_h_: Huw was working on the styling and I was sure I mentioned to him to add it so I didn't [13:25] hatch: ah, gotcha [13:25] either I didn't or he forgot [13:25] :) [13:26] I will throw it in in the unit branch I'm working on now [13:26] all good, just was looking around and noticed it [13:26] don't have huw's changes yet so we'll see [13:26] oh ok, they should just be in trunk now [13:48] gary_poster: review/qa. One bug in there during qa [13:48] ack thanks rick_h_ will look soon [13:52] there is a hot air balloon above my house and my docs do not like it in their airspace [14:04] have to run up to Sec of State, brb [14:06] is the unit status bar supposed to be very thick now? [14:07] gary_poster: are we 1:1 now? [14:07] in the inspector [14:07] it's the same height as the inputs now [14:07] bac yeah almost [14:19] back [14:22] fwereade_: hey have you had a chance to think about the relation error reporting? [14:22] I'm working on aggregating unit errors and boy would it be nice to not have to do all of this computing on it :D [14:25] hatch, ha, not really [14:25] hatch, I'm basically as far as I was when we talked [14:25] haha alright - anything I can do to help move it forward? [14:27] hatch, well, IIRC, where we were was: setting some relation-and-unit-specific error state on a suitable hook failure, and resetting it when the hook completes properly, is all we really need; and that isn't actually very hard to do [14:28] right, basically now I have a unit agent_state in 'error' and a agent_state_info in 'hook failed: db-relation-changed' [14:28] it would be really nice if there was an additional object with a proper data set in it [14:29] agent_state_data - which could be an object of relevent data [14:29] like - what it's related to, the actual interface name [14:30] right now I am parsing the agent_state_info and then have to do a few queries to our local db to figure out what relation that is [14:31] hatch, ok, that basically works for me I think [14:31] hatch, I'm not even sure how you'd do that without the relation id available [14:31] can a unit be related to multiple other units on the same interface name? [14:32] could this `hook failed: db-relation-changed` relate to two different services ..... theoretically [14:32] if your charm declares a foo relation, you can be in N foo relations with N other services, and in each of those you might be related to M units [14:32] right that's what I thought [14:32] hatch, yes it could [14:32] hatch, so you need relation id in there [14:32] so there is no way - atm - for me to really determine what the relation is [14:33] hatch, correct [14:33] * hatch scraps current branch [14:33] :P [14:33] hatch, hell, sorry [14:33] haha it's ok [14:33] we can't have everything we want :) [14:33] so is it possible to include the relation id when the hook fails like that? [14:34] I haven't spent much time in core [14:34] possible/logical [14:34] hatch, yeah, that info should be available trivially, just a mo [14:35] hatch, worker/uniter/modes.go:337 [14:35] hatch, I would support improving the error message there [14:36] hatch, it actually looks like it's just "relation-changed", not even "db-relation-changed" [14:36] hatch, but I would be a little reluctant to recommend that anyone depend upon its precise form [14:36] yeah exactly :) [14:37] hatch, and would be happier with the ability to add agent-state-data in SetStatus et al [14:39] right that also allows us the ability to modify/expand on that data object as time goes on [14:39] without modifying the api [14:54] hey rick_h_, thank you for review and qa. I can't dupe problem you reported: qa is good for me. what browser? [14:54] gary_poster: chrome [14:54] gary_poster: will load it back up and check others [14:55] rick_h_, wfm on chrome. maybe a quick hangout so I can see if you are doing something different than I am doing? [14:55] gary_poster: when you have a second we should have a real quick chat about the relation status stuff [14:55] gary_poster: sure thing, [14:55] hatch, ack. have a call in 5, but hopefully will be short [14:55] ok no problem, ping when avail [14:56] rick_h_, real fast in https://plus.google.com/hangouts/_/919c85491c5ef7fdad3aa7c1cf805253ecec4fd2 ? [14:57] tiny.cc/guichat looks dead again :-/\ [14:58] booo google [15:03] gary_poster: so in poking at it more, it's only once I set the background model to be the same value as the current value from the user [15:03] gary_poster: so I think it's something to do with clearing away the conflict marker/hiding the save button [15:03] ah! ok thanks will try again when I get off call [15:03] gary_poster: rgr === frankban_ is now known as frankban [15:21] hatch, https://plus.google.com/hangouts/_/6817b2266c6d0aab3f53875991c2086f7f573f75 ? [15:21] gary_poster: omw [15:23] fwereade_: still around? [15:24] mind joining gary and I in this chat? ^ [15:25] hatch, yes, more or less [15:26] hatch, 2 mins [15:39] bac: couple of comments on the ga branch [15:39] thanks for the review rick_h. do you mean just fetch the current ip address and stuff it in there? i just wanted to mimic the output from charmworld b/c i used it all of the time. [15:40] bac: yea, on the server side I didn't know if there's an easy 'whatismyup' it could pull [15:40] bac: but that's wishful thinking. Just now it's *wrong* for some use cases, but I understand [15:40] bac: the second comment on the conditional though I think would be nice for less error/etc in the console === frankban_ is now known as frankban [15:43] rick_h_: yeah, getting the ip is easy. i'll make that change. it may still be wrong if there are multiple interfaces [15:43] bac: k, I think most virtualmachines would have one though? I guess on local devs with wireless/wired it would be off? [15:44] jujugui: review of changes to the charm? https://code.launchpad.net/~bac/charms/precise/juju-gui/ga-key/+merge/185294 [15:45] rick_h_: what is the second comment you referred? [15:45] bac: while doing a quick QA I wondered if we could just skip the GA loading in dev with a hard coded GA code of devel (vs brad) [15:45] rick_h_: on, nm, i see it now [15:46] rick_h_: oh, i didn't mean to have 'brad' be included in the diff. that was a mistake. [15:46] rick_h_: since useAnalytics is false, that ga_key can be '' [15:47] bac: looking [15:47] * bac busted for not reviewing my diff [15:49] bac: so I'm confused. why would it not be if (window.ga_id && juju_config.useAnalytics) ? [15:49] vs the check being down in window['ga-disable-...? [15:51] bac: so down in the bottom where we have the snippet to add the ga script, we could just not add it if useAnalytics is false? [15:53] rick_h_: we could probably just get rid of useAnalytics and treat the existence of the key as the sentinel [15:54] rick_h_: the old style was from when the key was hard-code and we just wanted to disable it [15:54] bac: k, gotcha [15:58] guichat call in 2 https://plus.google.com/hangouts/_/6817b2266c6d0aab3f53875991c2086f7f573f75 [16:00] jujugui ^^ [16:00] juju-gui, even [16:00] thanks :-) [16:15] bcsaller: [16:15] blarg [16:15] branch [16:15] ahhh [16:15] yeah [16:29] gary_poster: ping [16:30] Hey TheMue . Thank you for being willing to help us out! [16:30] gary_poster: sure, i filed a bug at https://bugs.launchpad.net/juju-core/+bug/1224568 [16:30] <_mup_> Bug #1224568: Improve hook error reporting [16:32] TheMue, looks good, thank you. May I add (6) make sure that we can correlate relation error identifiers with AllWatcher relation info? I think we are using the tag as the AllWatcher relation identifier, in which case your plan sounds like exactly what we need, but I'd like to verify that [16:33] hatch, frankban ^^^ in case you have any input [16:33] gary_poster: yep [16:33] thanks I'll take a look in a bit [16:33] TheMue: what timezone are you in? [16:35] Cool, added. [16:35] gary_poster: with (6) it seems a good plan [16:35] cool thanks frankban [16:39] hatch: european [16:40] alright just curious :) [16:40] hatch: why? [16:40] so I don't send you a message and expect a response this afternoon haha [16:41] hatch: hehe, yep [16:42] :) [16:43] gary_poster: any specific card you want me to get onto now? [16:53] TheMue: when you land this branch can you link it to the ticket so I can see the diff - I'll need to update our go sandbox to mirror the new format [16:58] hatch: yes, will do [16:58] hatch: will be several smaller branches [16:59] alright no problem thanks [17:13] new review up: https://code.launchpad.net/~benji/juju-gui/charmworld-api-3/+merge/185325 [17:14] benji: heading to reitveld? [17:23] benji: looked at anyway, thanks for the new tests [17:27] hatch, bug 1223864? or move expose from config to destroy section, as (I think?) we discussed [17:27] <_mup_> Bug #1223864: Conflict dropdown on constraints fields never shows in IE10

[17:28] gary_poster: sounds good [17:36] hey rick_h_ I still can't dupe the qa issues. could we hangout one more time and have you walk me through it from the beginning (including loading up the gui)? The only thing I can see is if you are overwriting existing config values when you change the model, in which case the behavior you describe is correct. [17:42] gary_poster: sure thing [17:42] rick_h_, https://plus.google.com/hangouts/_/7a006e48281d727daf2a759297722b00e3d9070d [17:42] thank you [17:55] gary_poster: cool, so then you need a second set of eyeballs right? hatch bcsaller [17:56] yeah thanks rick_h_ [17:56] https://codereview.appspot.com/13340047/ [18:00] jujugui, could someone give me a second review on that branch above ^^^ ? [18:00] checking it now [18:02] thanks bcsaller [18:02] sorry didn't notice the pings [18:04] rick_h_: on further review, i'm unsure how to get the local ip address in js. [18:04] bac: cool, nvm then. [18:05] bac: thanks for trying. [18:10] rick_h_: +1 on your QA technique. my script predates the 'deploy' target and i never updated [18:10] bac: cool, yea I like how easy it's gotten [18:13] * hatch feels left out [18:13] what's this technique? [18:13] so last night my fitbit told me i was short on my walking goal a distance about the same as a round-trip to ben & jerry's. [18:13] lol [18:14] hatch: just to use 'make deploy' with the charm instead of using a stone-age script [18:14] hatch: see https://code.launchpad.net/~bac/charms/precise/juju-gui/ga-key/+merge/185294 [18:14] hatch: I made a comment on the other QA method that I got from frankban's branches [18:14] ohh gotcha [18:14] possibly update the hacking docs with that? [18:16] rick_h_: thanks for the review (late reply because I was at lunch) [18:17] rick_h_: darn, lbox was waiting on my google credentials this whole time, that's why no rietveld was forthcoming [18:17] benji: ah, gotcha. [18:17] benji: well cool and thanks for the tests all the same [18:17] rick_h_: ooh, thanks for the config catch; I was testing against a local charmworld [18:18] benji: yea, do the same all the time (well sometimes) [18:19] we probably need a lint step to yell if the config changes, that seems like a common issue [18:22] yea, if only a 'are you sure you mean to change this' warning. but fortunately it usually sticks out in review [18:27] rick_h_, hatch: should be noted 'make deploy' requires the env be bootstrapped already [18:27] bac: ah true. Missed that step in the notes [18:53] rick_h_: where were your zindex rules? I want to make sure I follow them :) [18:53] hatch: top of stylesheet.less [18:53] got em thcx [18:53] hatch: if you would have thuoght to look in another place let me know, I went with what made more sense to my brain [18:53] hatch: but not married to the location [18:54] makes as much sense as any I suppose - we just haven't held docs in code before [18:54] do we have a place for 'dev rules' ? [18:55] somewhat, it might go into 'style guide' though that's more actual styule [18:55] but partly why I went with the code. I don't always look at the docs when I start going at something [18:57] I never do [18:57] lol [18:57] ok that's not true [18:57] heh, you just did [18:57] I am restructuring all of that work you did on the expose button [18:58] :( [18:58] ok, running away. Have to prepare for the wife's birthday tomorrow. [18:58] OOoo [18:58] hatch: works for me :P [18:58] enjoy! [18:58] haha, it just needs to be moved - nothing you did wrong [19:10] 2H on CSS and markup - now lets go see if IE will ruin my day [19:12] looks like we can keep our IE10 support for another day [19:12] :P [19:52] rick_h_: since your review i've pushed a new branch and the old diff is gone. what did you mean by "#16 double space in there" [20:05] jujugui lf a review and QA (IE, Chrome) https://codereview.appspot.com/13684043/ review notes added [20:06] is there anyone still around with an IE VM? [20:07] I'd like to get this branch landed before EOD so that Huw can merge the styling and markup changes [20:10] hatch, I think you can claim the IE qa [20:10] alright I'll accept that :) [20:12] hatch, I don't think rick_h_ is around, and I'm becoming very skeptical of the idea of a boolean conflict [20:12] hatch, you up for talking it through with me? [20:12] sure thing [20:12] thx. uh... [20:13] hatch https://plus.google.com/hangouts/_/30b2e694404bf3e9f509dc3a15c182908c780231 [20:18] man, the search autocomplete is pretty awesome [20:18] I can see now why ale was so adamant about getting it in asap [20:19] :-) [20:19] thanks jcastro [20:20] rick_h_: if you've got time before EOD I have some questions as far as what I can get away with offlining with the GUI for saturday [20:26] https://jujucharms.com/precise/mongodb-HEAD/ [20:26] this work for anyone? [20:26] the mongodb guys just reported it to me [20:30] gary_poster: ^^^ [20:30] sorry but the mongodb community manager has the finger on the tweet button and I need a sane URL [20:30] jcastro, https://jujucharms.com/precise/mongodb/ [20:30] huh [20:30] I tried that [20:30] ok ... [20:31] * jcastro doesn't look a gift horse in the mouth [20:31] :-) [20:31] having laura cz. as our mongo contact = awesome. [20:32] heh [20:32] but yeah [20:32] we now support better URLS, but the apache redirects are now broken :-( [20:33] hey sinzui, where/how do I tweak the jujucharms.com apache redirects? [20:39] hatch, in return for crushing my dreams and spirit, I mean helping me out to figure out what to do, I'm reviewing and qa'ing your branch. ;-) code LGTM so far... [20:39] hahaha [20:39] thanks [20:43] hatch qa good. fire when ready [20:43] thanks! [20:43] awesome thanks [20:51] * sinzui looks [20:53] gary_poster: is this what you're looking for? http://bazaar.launchpad.net/~juju-jitsu/charms/precise/charmworld/trunk/view/head:/scripts/configure-apache2 [20:57] jujugui somehow one of the branches landed today has a jslint error [20:58] hmm it was bac's branch [20:58] benji, no, but thank you [20:58] hatch, may I have one more call with you? can't be for long, but need to talk through [20:58] benji: curious as to why your branch didn't go through lbox? [20:58] and brads for that matter [20:58] sure [20:59] calling [20:59] hatch don't see you. https://plus.google.com/hangouts/_/2c5782db2cd9582405c9a6208c501f47f9663063 ? [21:00] hatch: mine went through lbox, just not rietveld. I went to lunch while lbox was asking me for google credentials, so that part timed out and by the time I got back it had already been reviewed in LP. I then used lbox to land it. [21:00] oh ok [21:00] I'm just trying to figure out why brads didn't get linted before landing [21:10] jcastro: what's up? [21:10] gary_poster: ruh roh... [21:11] rick_h_: hey so, there's no interwebs at OLF as you know. [21:11] but I was thinking ... [21:11] jcastro: rgr [21:11] deploy in the hotel room with everything I need [21:11] check everything [21:11] then walk downstairs ... should work? [21:12] jcastro: issue is that charmworld needs a bunch of time to ingest a ton of data [21:12] jcastro: as that needs to be offline with you in your lxc environment [21:12] not to live deploy [21:12] I mean have it running and "laid out" [21:12] but show example commands [21:12] and then be like "this is what it looks like" [21:12] so not going to touch the browser? [21:12] right [21:12] but running ... [21:13] if you're careful what you do I guess yea [21:13] like, the gui doesn't flip out in X secs/minutes if it doesn't hit something right? [21:13] jcastro: right [21:13] rick_h_: ok, so .... screenshots are probably better? [21:13] I want to show awesome stuff, but not risk showing something broken [21:13] so if you can do 4 lxc's I'd think an lxc environment with charmworld, elasticsearch, mongodb, and the gui would be awesome [21:14] yeah I thought about that [21:14] can't we shut down and reboot and get them abck up now? [21:14] but the thing is that workload is interesting to the people in this channel [21:14] and no one else, heh [21:14] right, but you can stick them off the screen I guess [21:14] yeah I can reboot, and I know it works, but man, I am too scared [21:14] hah, yea. yea. You should be good if you setup on wifi, deploy/etc. and then go offline [21:15] "don't worry man, reboot your laptop, all 25 cassandra nodes will come up, trust me." [21:15] just don't touch anything that'll hit the charmworld, so you might lose icons, no browser, etc. [21:15] search, autocomplete, etc [21:17] jcastro: but yea, try out what you want to do. Set it up, flip the wifi switch, try it out [21:17] if you hit something I can see if I can help work around it for you [21:27] rick_h_: jcastro we should create a virtual box image that can be used for demos like this [21:27] wouldn't be too much work either I wouldn't think [21:27] yeah [21:28] I am debating how much to push the GUIs intent [21:28] Like, I really want to say "You know what ... Opsworks looks awesome ... run your own, and _fuck that_." [21:32] lol [21:32] any status update on the node charm? [21:32] I'm going to write my own pretty soon [21:33] waiting to sign the deal with joyent last I heard? m_3 might have a better status [21:42] siik [21:42] hatch: just do it [21:43] ugh trunk is so crazy broken right now [21:44] guess I won't be merging this in tonight [21:58] sounds like a plan [22:24] hatch, you can just back out the offending branch if that makes sense [22:24] you don't need to be the one who has to fix it [22:24] that said...tests were passing for me in my branch when I merged trunk, except for 1, IIRC [22:25] was that after brads google analytics branch? [22:25] sorry I am trying to also get ready to go out for supper atm :) [22:26] hatch, np, if it's EoD it's EoD! :-) [22:27] Morning [22:28] hey huwshimi. guichat is dead. I added a video chat link to the calendar. we can use that [22:28] gary_poster: Ah cool. I'll join in a sec [22:28] cool [22:29] huwshimi: my branch (https://codereview.appspot.com/13684043/) moves around some markup and css [22:29] so you should keep that in mind if you're doing that sort of stuff today [22:29] hatch: No problems, I'll take a look [22:30] I can't land it because of trunk but if you're working in those areas you might want to merge it in [22:30] and now i'm off for real this time [22:31] :) [22:31] hatch ttyl [22:31] cya [23:12] gary_poster: Can I do anything to help unbreak trunk? [23:13] huwshimi, is it blocking you? [23:13] gary_poster: It's not, I'm just aware it's getting late over there for you :) [23:16] huwshimi, :-) ok thank you. how about I'll check in with you when I stop. If I haven't merged my branch (likely) then I'll ask you to do the unbreaking? [23:16] gary_poster: Sure! [23:17] thank you!