[08:01] morning rogpeppe1 [08:01] frankban: hiya [08:02] rogpeppe1: here is the new plan: http://pastebin.ubuntu.com/5594917/ [08:02] * rogpeppe1 looks [08:04] frankban: hmm, nice idea, but i'm not sure it's guaranteed to work [08:05] frankban: what if the ServiceInfo delta was correct (and different to the value that the user has selected), and there's no subsequent delta? [08:06] frankban: ISTM that in that case you could show the wrong value for an arbitrary length of time [08:07] frankban: i *think* that you'd be best off just living with the slowly updating unit count for now and listing it as a bug to be fixed in juju-core [08:13] rogpeppe1: AFAICT, after the fact, the first delta can be 1) the one generated by the user changing the total count or 2) a previous one, no longer valid. [08:14] frankban: what if another user is changing the total count? [08:16] rogpeppe1: I suppose a race is still possible, but we narrow the window, and, anyway, it only affects that user form (for the more important parts of the GUI we still use the unitInfo delta). [08:18] frankban: there's another possibility too: the delta generated by the user changing the total count might arrive *before* the reply to the AddServiceUnits call [08:20] rogpeppe1: we can start ignoring the first delta right after the call to AddServiceUnits [08:22] rogpeppe1: http://pastebin.ubuntu.com/5594974/ [08:23] rogpeppe1: I see the wrong state in the line 13-14 window, but I think that's acceptable from a UX perspective [08:25] * rogpeppe1 is thinking [08:52] frankban: there are other problems too [08:53] frankban: for example, if there are 5 units, and two clients both type "20", both clients will add 15 units, and there will eventually be 35 units, even though neither wanted that [08:54] frankban: i still think that the best thing to do is not to write partially-correct client code to try and paper over the problem [08:54] frankban: but to actually fix the underlying problem [08:55] frankban: or... for the time being, change the user interface to add an explicit "add units" dialog, so we don't try to pretend to the user that they're setting the total number of units [08:55] s/or.../and, perhaps, / [08:58] rogpeppe1: that's an UX change, and I don't know if it's doable, I have to ask. Re the problem you are describing, we already have that problem, and we are trying to solve another one (having the form updated with units as they arrives generates confusion and can lead the user to re-type the number he wants in the form. [08:58] rogpeppe1: and that story ends up with a lot more units to be created [09:09] frankban: here's a simpler solution, i think: don't update the displayed unit count while the call is in progress; start displaying the current unit count (from the deltas) immediately afterwards [09:10] frankban: no need for any changes to the current API, i think, if you do that [09:10] frankban: it doesn't work well with concurrent clients, but i think that's inherent to the current setup, and will be fixed when we fix juju-core in this respect [09:12] rogpeppe1: but when you restart displaying the unit count, that can be wrong, e.g. you have 5 units and asked for 100. you display 100 till you have a response and then you switch to the number in the delta. at this point you could have 50 units, then 60, etc... we want to avoid precisely that behavior [09:13] frankban: i think the unit count at that point will only be wrong for a maximum duration of the poll interval [09:15] rogpeppe1: so, do you think that right after the response to add/remove units arrives, the next delta is always correct? [09:15] frankban: the deltas are always correct :-) [09:15] frankban: for some value of correct... [09:16] rogpeppe1: :-) I mean, when addUnits returns we can be reasonably sure that the delta already sent all the added/removed units events? [09:17] frankban: ah, i have another idea [09:18] frankban: the deltas are returned in response to a Next API call, right? [09:18] yes [09:20] frankban: so, while you're waiting for the result of the AddServiceUnits call, you don't call Next; when the AddServiceUnits call returns, you call Next immediately. [09:20] hmm, that's wrong too, both it [09:20] bother it [09:21] ah, no, i think it might make sense [09:22] nope [09:22] that's, more or less, the same as not updating the count in the form while waiting for the addUnits response. [09:22] frankban: yeah [09:22] frankban: ok, another idea :-) [09:23] and that idea (the old) is better IMHO: more easier to implement, and it does not prevent the rest of the GUI to react to deltas and update itself [09:23] frankban: only start updating the form from the deltas from 5 seconds after the AddServiceUnits call has returned [09:25] frankban: thus we reduce the window where the user might see an incorrect count, but we run no risk of showing an incorrect value indefinitely [09:25] rogpeppe1: sounds good, that way we ensure the GUI db already has the correct number of units, correct? because the mongodb is watched every 5 seconds [09:26] frankban: yup. maybe make it 6 seconds to account for network delay etc [09:26] frankban: and a big TODO to remove this hack when juju-core is changed to fix the issue [09:31] rogpeppe1: so, this could be the new story: http://pastebin.ubuntu.com/5595088/ with no changes to juju-core, right? [09:34] frankban: that seems good. you'll need to make sure that the number of units to add or remove is calculated with respect to the currently displayed value, not the value from the deltas [09:34] rogpeppe1: yes [09:38] rogpeppe1: I still think it could be valuable to return unitCount from ServiceGet, so that we can update that number when the user visits the service detail view. I am thinking about the user refreshing that view: we lose the state (and the 6sec sleep), we wrongly display the value from the delta. [09:40] frankban: if the user refreshes the view, the websocket connection is made again and everything is fetched again, right? [09:41] yes [09:43] rogpeppe1: the user adds 100 units and then refresh: the form is updated from deltas, and deltas didn't already send all the new units [09:43] frankban: the first delta that arrives will have all the units in [09:44] rogpeppe1: really? so if you add 1000 units they are all send in the same delta? [09:45] frankban: yup, that is true currently. [09:45] frankban: in the future, we may split the responses, but i think we'll always provide an indication that there's more to come. [09:46] frankban: otherwise you can't know when you've seen the whole environment. [09:46] rogpeppe1: but that delta can arrive after 6 seconds, right? so, if the user refreshes we could display the wrong value for that amount of time [09:47] frankban: no, that delta will arrive immediately [09:47] frankban: the first delta is always sent immediately [09:48] rogpeppe1: so, if the user does not refresh, there can be a 5 seconds delay, otherwise the delta is sent immediately. [09:48] frankban: yes [09:52] rogpeppe1: so, is this correct? http://pastebin.ubuntu.com/5595128/ [09:53] frankban: yup, looks good [09:53] rogpeppe1: cool, thanks a lot [12:14] hey rick_h_ you feeling better? [12:14] gary_poster: yea, thanks [12:15] gary_poster: tried to check in yesterday. wonder if we can setup some time to chat about the url/itegration bits sometime soon. [12:15] cool rick_h_, glad. benji got the add button integration in. he had it in landing but I just moved it to done because it worked for me, at least for a trivial experiment. Is it good for you? [12:16] gary_poster: haven't looked yet, giong through huw's stuff from last night. I'll check it out. Thanks for getting that going. [12:16] Telecommute awsomeness 23: Can't catch coworker crud. ;P [12:16] yea, no kidding [12:16] benji :-) [12:16] cool rick_h_ [12:16] having kid/dr wife suckiness #1 - they're constantly trying to kill you [12:16] gary_poster: when you have a chance I'd like to discuss the charm build-speeding task I'm on [12:17] and of course I work from home so I don't expose to all that stuff [12:17] rick_h_, time to chat: sounds good. let me re-review the current UX bugs and then we can talk any time. I'll ping when I think I have a good overview [12:17] benji, cool. now, or in 30/45 min? [12:17] gary_poster: benji add buttons seems cool. Thanks again. First integration point check! [12:17] gary_poster: now would be best for me, if you have the time [12:17] yay rick_h_ :-) [12:18] ok benji, to guichat we go [12:18] k [12:51] gary_poster: morning, Roger and I ended up with this solution: http://pastebin.ubuntu.com/5595128/ Could you please take a look? [12:52] frankban, yeah I saw the conversation and that pastebin. I was a bit concerned about it but was going to let it go and check in with you later. I'm on a call now. ping you later? [12:52] gary_poster: sure [12:52] thx [13:16] gary_poster: i propose that i fix bug 1170468 by keying off the default value to determine whether to render a simple input field or a textarea. i'm going to get styling help from the design guys. follow on work will provide the expansion control you want. The work needs to be duplicated on the service settings page, too. are you ok with this incremental approach? [13:16] <_mup_> Bug #1170468: Allow multi-line text input for charm configuration in the GUI [13:16] \o/ mup, welcome back [13:16] :-) [13:17] bac, yes, as long as you discuss the expansion control with design guys now too to make sure they are on board with the expected end story [13:17] yeppers. writing email now. that's what prompted this running up the flag pole [13:17] cool thanks bac [13:53] gary_poster: thanks for the review - sorry that prefetch_service code is just old prototype code left in for the units, that will be going away in favour of the promise stuff [13:53] oh cool hatch great [13:53] hi jovan2 and luca____ -- just sent you an email. would love to discuss when you have time. [13:54] hatch: you in? got a quick question for you. My medicated brain is confused [13:54] bac: Hi Brad, we'll read it through and get back to you asap. [13:54] tiheum ping [13:54] thanks luca____ [13:58] rick_h yup back, just went and spent a few minutes outside - so nice out, frost, -6 sunny,,,,ahhhh [13:59] woot! [13:59] hatch: guichat for a sec? should be fast but easier to say than write [13:59] sure [13:59] oops, nvm. Diff one [13:59] looks like it's occupied [14:00] https://plus.google.com/hangouts/_/e7b58b173b15be49a7f0bc948e75d2521b03e375?authuser=0&hl=en [14:00] hatch: https://plus.google.com/hangouts/_/29e068e60e2b16c671698550d1e55971a6091ae3?authuser=0&hl=en [14:00] lol [14:00] ok joining yours [14:10] I figure you pythonites would enjoy this http://www.skulpt.org/ [14:11] pythonistas :P [14:11] and no, use the right tool for the job. If you want to do client side then use JS. But I'm a pythonista that can write a few lines of JS when required :) [14:21] gary_poster: did you have a few moments to chat about the promises stuff? [14:25] hatch soon [14:25] frankban, guichat? [14:25] np, lemme know [14:25] thanks will do [14:25] gary_poster: joining [14:25] thx [14:42] rick_h_, you available for guichat? [14:42] gary_poster: sure thing [14:42] cool [14:43] umm, if my browser will let me [14:56] bcsaller, I'd like a quick hangout when you're around [14:57] rogpeppe3: do we already have a bug for the SetServiceUnits functionality? If not, do you want me to file one, so that we can track its progress? [14:57] frankban: i think there probably is one; let me check [15:01] jovan2: bigger screenshot sent. sorry about that. [15:02] frankban: i can't find one actually [15:02] bac: thanks! [15:02] frankban: could you file one please. and please describe your particular scenario too in the report. [15:02] rogpeppe3: sure [15:11] rogpeppe3: filed bug 1171899 [15:11] <_mup_> Bug #1171899: Allow for setting a specific number of units (as opposed to add or remove them)

[15:12] frankban: thanks! [15:12] oh hey mup, welcome back [15:12] mup is back, you only love him when he's not around [15:13] yeah - I wonder if he has any new tricks or if he is a one trick pony [15:15] teknico: whats up? [15:16] bcsaller, I'm working on #1171508 and I'd like your opinion [15:16] <_mup_> Bug #1171508: install-error when deploying charm [15:16] teknico: I have that fixed in a branch I'm about to propose [15:16] config_get needs --format json [15:17] and then parse using json.loads [15:17] bcsaller, right [15:17] exacgtly [15:17] bcsaller, why are we working on the same thing? [15:18] teknico: I ran into it testing the apache support in the charm just just hit it as a fly by [15:18] didn't know there was a bug for it [15:19] bcsaller, ok, while we're at it, did you also happen to fix #1171512? [15:19] <_mup_> Bug #1171512: Failure in charm unit test [15:20] teknico: I had all the tests passing last night, I'll try to confirm they work with the revs since then, one sec [15:20] teknico: Ran 43 tests in 1.587s, seems good [15:21] bcsaller, great. how about #1171516? [15:21] <_mup_> Bug #1171516: Charm needs more backend tests [15:22] teknico: I changed some of the existing tests, but haven't added more to the backend suite [15:22] bcsaller, ok, so I guess that one's still standing [15:25] teknico: the existing tests have been updated to work properly like I said. I also changed one of the mechanisms in test utils to be more flexible, I can push what I have now if you want to look at it === rogpeppe3 is now known as rogpeppe [15:26] bcsaller, yes, please. I'll also review your branch once you propose it [15:26] teknico: awesome [15:28] teknico: lp:~bcsaller/charms/precise/juju-gui/apache-version/ [15:28] bcsaller, getting it [15:41] teknico: https://codereview.appspot.com/8640044 [15:42] bcsaller, the related card (no rietveld link in it though) seems to be back in the Code lane [15:43] I did paste the link in the desc (which I see) and moved it (but it seems to have moved back) [15:43] weird [15:46] bcsaller, you want to put that link in the "Add external link" -> "URL" field, rather than in the description (I've done it already) [15:46] teknico: ahh, thanks [15:51] gary_poster: i've got the first branch done. the textarea looks a little funny wrt inner scrollbar and rounded corners. i'd like to put it up for a code review now and do styling when the design guys can give me feedback. [15:55] bac ok, UX feedback during review? [15:55] gary_poster: yeah [15:55] jujugui kanban update pls [15:55] bac cool [15:55] hatch didn't forget about you :-) talk after daily call? [15:56] who are you again? [15:56] :P [15:56] haha yeah sure np [15:57] :-) [15:59] hatch: https://codereview.appspot.com/8920043/ if you get some spare time :) [16:01] viewing [16:02] bcsaller, ping [16:17] rick will do the review now [16:17] hatch: thanks, I see ther's a small conflict in there I'm lokoing at. but just assume I can get my }, in the right place :) [16:18] hatch: oh, nvm. Doesn't show in reitveld, just LP it looks like [16:39] benji: i found my problem that killed the beautifier [16:39] what was it? [16:40] if you use a bare "default:" (or any other keyword i suspect) as a key without quoting it, the beautifier crashes [16:40] var x = {default: 'something'}; [16:40] the linter finds it but the beautifier crashes [16:41] when there's only the juju-gui service, maybe we should disable the "Build Relation" menu entry :-) [16:41] Heading home, back in a few. [16:42] hatch ole buddy ole pal! [16:42] guichat? [16:42] sure thing [17:39] gary_poster, is there a gui staging instance running against go? [17:40] no hazmat [17:41] gary_poster, k, i'm trying out the api from python, and doing some of the same things that the gui is doing, but getting errors, wasn't sure if perhaps something bitrotted. [17:41] this is just on EnvironmentInfo post login. result. u'Error': u'unexpected end of JSON input' [17:42] hazmat, was working last night, and was going to send announcement today. Possibly bug 1160971 [17:42] ? [17:42] <_mup_> Bug #1160971: WebSocket disconnects when an invalid request is sent

[17:42] hazmat, I mean, GUI plus Go was working last night [17:42] gary_poster, cool, it could very well be my client lib doing something silly [17:44] rogpeppe, around? [17:47] oh.. nevermind.. empty Params struct is required [18:44] anyone have time for a second review of https://codereview.appspot.com/8922043 ? [18:49] bac: I can look it over [18:49] thanks bcsaller [19:07] hatch: jcsackett sinzui any of you guys up for reviews take 2 please? https://codereview.appspot.com/8923044 [19:07] oh good, the CI is working on the new charm now [19:07] yay! [19:07] rick_h_, I can [19:09] great job bcsaller. Did you verify that internal links still work--apache will serve up the index.html if you go to /some/url/that/has/no/associated/file ? [19:09] I was going to check that [19:09] in a world all alone among the grey masses...is the juju gui http://uploads.mitechie.com/lp/jujugui_svg.png [19:09] bah, sorry, bet that ping'd everyone :( [19:09] * rick_h_ thinks about filenames better [19:09] yay! orange! [19:09] gary_poster: I think at this time, no :( I think a 404 handler might do it though [19:10] I've already written a 45 page guide to project-wide IRC pings that will be followed on the next project. [19:10] bcsaller, yeah, that would work. I think the nginx thing did that--looking how... [19:10] benji: but does it have a simple to use checklist I can use to verify "should I sent this message to irc"? [19:10] rick_h_, when do we get to see the icon at http://uistage.jujucharms.com:8080/bws/sidebar/~juju-gui/precise/juju-gui-43/ ? [19:11] rick_h_: that's coming in Volume II [19:11] gary_poster: when this branch I've put up for review lands [19:11] cool rick_h_. we should stand out like a beautiful orange flower growing in the asphalt [19:11] gary_poster: that's from my dev instance where I had to fix a bug [19:11] yay rick_h_ :-) [19:11] gary_poster: so the faster it's reviewed the faster you get it *hint hint* lol [19:11] lol [19:12] bcsaller, nginx just did it with a url rewrite (lines 31-33 of https://codereview.appspot.com/8640044/diff/1/config/nginx-site.template?context=10&column_width=80 ). Probably a better approach, that could be duped in apache [19:13] gary_poster: I initially had mod_rewrite configured in, might have to add it back in then [19:13] yeah [19:13] gary_poster: however all the CI test pass w/o it, do we really need it? [19:13] bcsaller, yeah. without it you can't pass urls to other people [19:14] bcsaller, we should add a test [19:14] fair enough [19:14] bcsaller, which you don't have to write for this fix :-) [19:14] a bug/card would be sufficient [19:16] gary_poster: I have lots of interesting data to discuss when you get a minute [19:17] cool benji, will ping soon [19:17] k [19:19] someone ding me? Sorry irc client screwed up [19:19] hatch: did here, https://codereview.appspot.com/8923044 [19:19] alright will do [19:20] bcsaller: regarding your comment about px vs em, i think you've got a good point but since i was just moving an existing value to another place i would like to keep it at 15px. doesn't make sense to tackle it in just this one place IMO. [19:20] hatch: appreciate it. Nice to end the day on a landing [19:20] bac: yeah, I meant it to sound like I was fine with that happening another time [19:20] cool [19:21] rick_h_: I hope you don't expect me to review that json doc :P [19:21] hatch: no, I'm expecting you to ignore it and carry on :) [19:21] haha [19:21] what does the svg+xml do? [19:21] never seen that before [19:22] hatch: fix the svg. It won't right right without it. [19:22] interesting [19:22] hatch: since we've not had any charms with icons until just recently didnt' realize it [19:22] I always thought it was just image/svg [19:22] hatch: you/me both :/ [19:22] haha [19:22] hatch: but +xml makes it all worky worky [19:26] benji guichat? [19:26] gary_poster: sure [19:27] rick_h_: done [19:28] hatch: ty sir [19:36] no problem [19:53] * hatch is attempting to use sublime only by keystrokes [20:01] Our charm's quality is 0/38! [20:01] * gary_poster is crushed [20:02] hah, need to get reviewed [20:02] :-) [20:02] http://uistage.jujucharms.com:8080/bws/sidebar/~juju-gui/precise/juju-gui-43/ icon is up [20:02] http://uistage.jujucharms.com:8080/bws/fullscreen/~juju-gui/precise/juju-gui-43/ as well :) [20:02] ok, 4 bugs is a good day. Time to run while I'm ahead. [20:03] cool, ttyl rick_h_ [20:08] I wonder if I can dual boot this mac mini into 13.04 [20:08] switching from osx to ubuntu is driving my finger memory nuts hah [20:20] gary_poster: turned out there was a 'new' apache directive for the 404ish thing, much simpler than it used to be. http://httpd.apache.org/docs/2.2/mod/mod_dir.html#fallbackresource if curious [20:39] gary_poster: you still around? [20:41] gary_poster: http://jujugui.wordpress.com/2013/04/23/ive-been-investigating-the-speed-of-various-things/ [20:43] nice finds benji [20:43] the S3 speed variability surprised me [20:44] s3 is known to be variable.. cloudfront is better for this use case (s3 origin). i'd also check out google storage as a low latency object store, boto works with it [20:46] yeah, I figured cloudfront would smooth it out quite a bit [20:49] taking lunch [20:58] hatch around [20:59] bcsaller, FallbackResource: awesome [20:59] yeah, and it all still passes CI [21:00] benji, nice blog, thanks [21:00] bcsaller, heh, awesome [21:07] http://uistage.jujucharms.com:8080/bws/fullscreen/~juju-gui/precise/juju-gui-44/ picks up the icon now, sweet [21:13] Hey Makyo, if this is a quick fix, I made a card for the fact that the scroll wheel behavior is broken in Firefox (try going to http://uistage.jujucharms.com:8080/ and using the scroll wheel to zoom) [21:13] I'll file a bug [21:14] gary_poster, About to head out for dogwalk, but will take a look. Hopefully it's something on our side. [21:14] cool Makyo thanks [21:39] bcsaller: :) [22:16] gary_poster: sorry I missed that you said you were back [22:16] https://code.launchpad.net/~hatch/juju-gui/set-loaded good middle branch? [22:35] afaics constraints in the go api are broken, set followed by get shows no change [22:36] or i can spel the key correctly and it works .. [22:36] nm [22:41] heh, I did the same thing the other day [23:21] hatch, wow, that still works? yay for deleting code! :-) [23:22] hatch, then a later branch will move loadService and other db-related bits to the models module? [23:22] +1 so far