[12:42] hi frankban, you on trusty yet? [12:42] bac: no, but I have a vm running trusty [12:44] frankban: yeah, me too. have you seen any problems with juju reporting errors about bootstrap tools? [12:44] on trusty [12:44] frankban: like http://paste.ubuntu.com/6791381/ [12:45] bac: yes, I described this (and a workaround) in my email announcing quickstart [12:45] (sent to gui-peeps) [12:45] All these issues are making me reconsider my desire to upgrade to trusty. [12:45] frankban: doh. sorry to bother you [12:46] bac: np [12:47] frankban: so juju on trusty cannot use lxc or ec2. that's mighty limiting. [12:47] bac: IIRC you run juju on ec2 using --upload-tools [12:47] oh [12:48] frankban: well, my handbuilt version also seems to work [12:48] will try the latter [12:48] bac: cool [12:49] benji: yeah, i'd wait for sure before upgrading metal. i kept my saucy vm, so if i have to mothball trusty for a while its not big deal [12:49] s/not/no/ [12:50] frankban: fyi, the latest code for juju-deployer has not problem handling my bundles that have constraints like mem=1G. i notice on pypi there is a 0.3.0 but our charm is using 0.2.9. will test our charm now using the new version. [12:50] s/not/no/ [12:52] bac: sounds good, the last branch merged in the deployer is "merge jjo subordinate and constraint diff fixes and unicode yaml repr issue". so it seems that fixed the problem [12:53] righto [12:55] jcsackett: http://staging.jujucharms.com/heartbeat shows no charm-queue and basket-queue. is that due to your indexing investigation? [12:57] jujugui you might find this useful (vcs branch name in the prompt): http://pastebin.ubuntu.com/6790927/ [12:58] cool [13:25] morning [13:26] gary_poster|away I'll take a look at huw's branch [13:31] hatch: I was going to write up the debugging technique for thatone [13:31] hatch: where you comment out the test files, then the tests, to help narrow down what is conflicting [13:31] oh ok I thought he just wanted it done [13:32] hatch: yea, but he's had some tests failures he's punted like that before. I figure teach a man to fish and all that [13:32] but understand [13:33] well there is an event cleanup issue [13:35] rick_h_ do did you want to get the branch landed or would you like me to? [13:35] hatch: you go ahead [13:35] ok cool [13:35] you've been much father into it :) [13:36] man my internet is really slow today for whatever reason [13:37] pipes are cold [13:38] it's actualy been unnaturally warm [13:38] -10C right now, but will warm up quite a bit by mid day [13:46] rick_h_ so to work on huw's branch is it best that I clone his fork then work directly on his branch so that I can rebase it? Or do you have another technique? [13:47] hatch: I'd just create a branch in my workspace, pull his changes into it straight from his fork, and then work on it and submit it [13:47] hatch: git pull git@github.com:fitztrev/Bookie.git anon-bmark-get [13:47] yeah? That won't cause any odd ordering issues with the revase? [13:47] rebase [13:48] and the merges etc [13:48] hatch: for example is how I pulled a pull request over and then worked on it to finish it/submit it [13:48] and then I had to go to his pull request and manually close it [13:48] hatch: worth a try. if it messes up just remove your branch and try something else [13:48] ok I can give that a go [13:49] sure beats cloning the entire repo on my slow connection this am [13:49] :) [13:52] some days devel and debug are too close together [13:54] haha yup === gary_poster|away is now known as gary_poster [14:14] * gary_poster had call and forgot to join, sorry [14:14] thanks hatch [14:14] frankban: didn't you fix this? I thought I remember qa'ing it. https://bugs.launchpad.net/charms/+source/juju-gui/+bug/1252295 [14:14] <_mup_> Bug #1252295: guiserver bundle deployment error is empty [14:15] * rick_h_ goes to load up an env and test it out [14:16] rick_h_: yes, that can be considered fixed, but right now we have no feedback on what went wrong, just an "unknown error" or similar. we need some changes to land on the deployer to really fix that bug [14:16] hey rick_h_. Should GUI release wait on your 1257878-2 branch? [14:17] gary_poster: landing it now, yea I was trying to sneak it in [14:17] I'm consistently getting this error from an lbox submit: [14:17] bzr: ERROR: Cannot lock LockDir(chroot-65979408:///%2Bbranch/charmworld/.bzr/branch/lock): Transport operation not possible: readonly transport [14:17] wow huw was not kidding when he said he got errors haha [14:17] rick_h_: awesome, thx [14:18] yeah....this might take a while [14:18] hatch: :-/ ok [14:20] benji, might impoy that you are working in a place where you have not authenticated yourself with lp? if you run bzr lp-login in that context does it know who you are? https://bugs.launchpad.net/qbzr/+bug/1094810 [14:20] <_mup_> Bug #1094810: bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/~over-garcia/openacademy/trunk/.bzr/branch/lock): Transport operation not possible: http does not support mkdir() [14:20] gary_poster: this is my normal place, but I'll try lp-login anyway [14:21] ack [14:21] gary_poster: no dice, it already knows who I am (also, pushing and other bzr operations work) [14:22] benji: ack. skimmed through other options and didn't see anything obvious. Sorry. Maybe make new co and merge across or something? :-/ [14:23] benji: https://lists.ubuntu.com/archives/juju-dev/2013-March/000612.html looks awfully similar fwiw [14:23] * benji reads [14:24] gary_poster: if you get a sec wanted to check if I should start the release process after that 404 fix lands? [14:24] so IOW benji, check if your team membership has changed or if you generally have the privs you expect [14:24] rick_h_: +1 thank you! [14:26] frankban: hi. Do you think you need anything to make the quickstart release official? Did you get any testing feedback from external folks, like Jorge? [14:27] * jcastro votes for "do it!" [14:27] :-) cool [14:27] gary_poster: not yet. oh wait... [14:27] I'll debut it tomorrow at the PTS sprint during my charm school [14:27] awesome! [14:28] gary_poster: I think after that we only need to copy quickstart+urwid packages to the juju stable ppa [14:28] it irritates me that lbox keeps asking me to edit the commit message; I've resorted to "EDITOR=true lbox submit" and am now happy. [14:28] jcastro: great thank you! [14:28] benji lol in a 10% sad way :-) [14:29] jcastro: woo! Look forward to hearing how that goes [14:29] benji: we can move it to github and ditch lbox ;) [14:29] frankban: "after that": after what? We need just a bit more QA? [14:29] "I hear you've got a hammer problem, here's a saw" [14:30] heh [14:31] gary_poster: I meant after jcastro debugging session. I did some QA and it seems to work well, so, if you prefer to just ship it, I am ok with it [14:32] frankban: ack. jcastro, you had a debugging session with the new release, at least to verify that your plans tomorrow work nicely? If not, do you have any time for it? [14:32] frankban: +1 on shipping. We had some qa when lazypower and jcastro tested out the 1.0rc1 and I spent some time trying to break it. [14:32] cool [14:32] I can spend more time auditing quickstart if requried [14:32] poke me when required and I'll put it in my priority queue [14:32] gary_poster, I am getting on a plane today and out of the loop for 2 days but maybe lazypower can dive in? [14:33] ack jcastro, thx. I think I'm OK with shipit, frankban [14:33] gary_poster: +1 [14:34] yay :-) [14:35] gary_poster: seeing if I can copy the packages [14:35] frankban: cool. you should be able to. if not, lemme know, and I'll see what I can do to make that possible, [14:38] gary_poster: it seems I was able to do that. publication pending [14:39] frankban: exxxxxxcellent. muahaha. etc. [14:39] lol [14:40] lol, /me can see Gary doing the hand motions all too easily [14:40] :-) [14:52] gary_poster: quickstart published \o/ [14:53] Congratulations on shipping today! [14:54] thanks! [14:54] gary_poster: for the release. We're calling this 0.15 with a note on the "no more pyjuju support" in the changelog? [14:54] gary_poster: or are we ok calling it 1.0? [15:00] awesome frankban! congrats! Send out your email from yesterday to juju list? [15:01] rick_h_: I'm afraid we are calling it 0.15. To assuage some concerns with theoretical nothings: the GUI technically still supports pyjuju [15:01] it is only the charm that has changed [15:01] so if someone want to use the new gui with pyjuju they could [15:01] using an older charm [15:01] I think :-) [15:02] maybe worth calling out in release notes. can use that as excuse for the official 1.0 later when we rip out pyjuju in gui itself [15:02] gary_poster: ok, so I'm calling out that this is the last release? or just leave it out in the notes of the gui itself? [15:02] gary_poster: sure [15:03] rick_h_: no, leave it out of the GUI. At most say that this is likely to be the last release of the GUI with pyjuju support [15:03] gary_poster: silence sounds golden to me then. Thanks [15:03] cool ty [15:03] thanks frankban, great [15:08] in other news: my dogs like bacon [15:10] sky is blue still, as well, then, in Canada? [15:11] not sure, overcast with a low ceiling [15:12] it MAY be! [15:13] :-) [15:15] man these have to be the most obscure test failures ever [15:19] gary_poster: email sent, do you have any suggestions for my next card? [15:22] frankban: did you see my earlier query about the bugs around the errors and bundles? [15:22] frankban: I thought at least one of the two in the high lane were fixed? [15:23] rick_h_: pasting from above: yes, that can be considered fixed, but right now we have no feedback on what went wrong, just an "unknown error" or similar. we need some changes to land on the deployer to really fix that bug [15:23] frankban: oh heh, I missed the reply. /me needs to get his mentions split back in irssi. [15:23] rick_h_: the WatchDebugLog API does not seem to be ready on core side, right? [15:24] frankban: oic, so this isn't the original swallowing of errors then. [15:24] frankban: correct, a new revision was pushed up today in the code review [15:25] frankban: after this release I was going to look at maybe poking at the front end bits, but was going to check with the gary_poster first. Maybe something else would make more sense. [15:25] frankban: can you post your email to the gui blog? [15:25] * rick_h_ wants to share with the world via pretty html links [15:26] rick_h_: sounds good, I can help implementing the client API in the GUI when we know better how the API looks like [15:26] rick_h_: re blog post, sure [15:27] frankban: would love the help on that. https://codereview.appspot.com/44540043/ is the commit I've been tracking if you want to peek at it. [15:27] I wonder if there is some way to make phantom cache assets [15:28] cache bad [15:28] bad cache! bad! [15:28] I'll take < performance over "impossible to debug wtf" [15:29] rick_h_: yeah I saw that, the EntityLogRequest parameters with Lines and Tag seems great. Still not sure how a user-admin will access that Debugger API [15:29] rick_h_ I was thinking caching the YUI stuff not our code :) [15:30] * hatch does a little dance after solving the huw's test issues [15:30] frankban: cool, happy to chat on what I know once I get through the release stuff. So maybe tomorrow lol [15:31] :-) [15:32] frankban: next card: you are blocked by hazmat on those two with your head right? [15:32] gary_poster: yes [15:35] frankban: ok. I know some of the "high" cards are not exciting. jujucharms ETags, 1230410, or "add link from unit link..." are reasonable. [15:35] gary_poster: should I take the "make releases" card? (or perhaps split it into multiple cards and take one to start) [15:35] rick_h_: debug log is blocked on TheMue getting that landed, right? [15:35] gary_poster: yes [15:36] rick_h_: :-( [15:36] gary_poster: though I thought some of the UI stuff could 'start' [15:36] making sure the tabs are ok, prepping the idea of storage layer, etc [15:36] rick_h_: coudl you suggest those with a high priority marker on the board please? [15:36] gary_poster: but it's got a short runway until that lands [15:36] Hey TheMue, any estimate on when debug log will be ready for us? [15:37] benji: rick_h_made another card it looks like [15:37] I'll change that one to "jujucharms" release and mark it blocked [15:37] ok [15:38] benji, frankbanif one of you were to identify the jujucharms etag issue that would be fab [15:38] brb [15:39] gary_poster: I'll be glad to look at it. Is there more detail somewhere? [15:39] benji: yeah, looking, 1 sec [15:39] (I'm a big fan of "borked" as an adjective, but as a problem description it lacks something.) [15:40] gary_poster: API side is in review, I'm currently n the command side, but got troubles with the watcher logic there [15:40] :-) [15:40] gary_poster: seems to be the first command using a watcher [15:40] TheMue: API side almost ready for landing, as far as you can tell? command side watcher logic: it is not an issue with the API, just an issue with how to *use* a watcher API from CLI? [15:40] gary_poster: but you're more interested on the server side of the API, don't you? [15:41] yes [15:42] gary_poster: I have to detect if the server returns the error or if it is generated by wrong handling on the client side [15:42] gary_poster: dimitern already helped me so that I get further step by step [15:42] benji, simply if you reload static resources from jujugui you will see that you get different etags for the same resource. [15:42] getting example [15:43] hmm [15:43] are there multiple back-end servers? [15:44] benji, yup. you know where this is going. however, we thought we had the right config to have ETags set by...whatever is stable. I forget. Either we are doing that wrong, or something in front of our own serving is getting that wrong. [15:44] my bet is on "something in front" [15:45] yeah. this task will probably be (1) prove that we are doing the right thing on our side (frankban can probably help do this very quickly) and then (2) work with webops to figure out what else is going on [15:46] benji, hm [15:46] it may be that they fixed this for us magically [15:46] trying to dupe [15:47] fixing is good, communication would be good too :) [15:47] by reloading https://jujucharms.com/juju-ui/assets/all-yui.js and seeing if I can get a non-304 [15:47] though I might have both ETags cached? [15:48] wget --no-cache might be helpful [15:49] benji, I can't dupe. Maybe this is a quick "demonstrate that the problem doesn't exist any more" card? :-) [15:50] TheMue: ack, thank you. [15:50] rick_h_ so are you going to put a dark stain over the green? [15:50] jujugui call in 10 [15:51] gary_poster: ok, I'll hack together a test script that will try to get inconsistent etags; if we don't get any after many requests we'll consider it fixed [15:51] +1 thanks benji [15:51] gary_poster: yw, I hope I can solve this last mystery of mankind to get the watcher in for you asap [15:51] :-) cool TheMue [15:53] gary_poster would you like me to fix some of the remaining small issues with huw's branch and then land it? [15:53] the remaining issues are trivials [15:53] hatch: yes please, thank you. I'd also like to talk to you after call about planning out local charm stuff [15:53] sounds good [15:53] ty [15:54] rick_h_: http://jujugui.wordpress.com/2014/01/21/juju-quickstart-1-0/ [15:54] woohoo! [15:54] frankban is there a 'what is quickstart' blogpost somewhere? It should probably be linked from that post :) [15:55] actually we should work with evilnickveitch on this [15:55] hey evilnickveitch, do you have any time today or tomorrow to talk with us about incorporating quickstart into juju docs? [15:55] gary_poster, yeah, i saw the announcement [15:56] I should add it to my list [15:56] :-) [15:56] ok evilnickveitch, how would you like to prioritize it? or should I get some feedback from mramm & arosales about that? [15:58] jujugui call in 2 [15:58] gary_poster, I will put it next I think. I was working on simplestreams, but as quickstart is actually released... [15:58] evilnickveitch: :-) cool [15:58] :-) [15:58] it makes sense to do it sooner. I will take a look at get back to you if I need anything! [15:58] thank you evilnickveitch! [16:23] gary_poster: when is SA? [16:24] bac, 1.5 weeks; first week of Feb [16:24] frankban: i've looked for mramm's reply you mentioned but don't see it? what list was it? [16:25] bac: you are not CC'd [16:25] frankban: oh, ok [16:55] hey frankban, moved quickstart announce cards to maintenance lane. Will clear out quickstart cards [16:55] i will move them to backlog just in case we want to look at them [16:55] gary_poster: cool thanks [17:00] gary_poster, evilnickveitch ack on getting quick start documented ahead of simple steams [17:00] awesome thanks arosales [17:00] we just need simple streams by 1.18, and the good stuff in quick start we need to let users know about [17:01] gary_poster, time wise looking like a day or two given you can provide evilnickveitch with the technical bits needed. Is this correct? [17:01] arosales: sounds good to me, yes. [17:02] evilnickveitch, arosales, frankban should be the tech contact on this. His timezone should align well with Nick's [17:03] gary_poster, evilnickveitch, arosales: sounds good [17:03] cool thank you [17:04] arosales, frankban gary_poster, cool with me. I have started to have a look [17:04] great [17:11] gary_poster: I have verified that the etag problem still exists: [17:11] % cat out | sort | uniq -c [17:11] 63 ETag: "48b97-3dfd-4eb136e395640" [17:11] 37 ETag: "4aa32-3dfd-4eb136e395640" [17:17] benji: suck [17:17] benji: but thank you [17:17] benji: confer with frankban before his EoD to get his braindump on this, please? [17:18] gary_poster: sure [17:18] thanks [17:18] evilnickveitch, thanks [17:18] oh, frankban! what up with etags? [17:19] benji, gary_poster: IIRC jc.com is deployed with the legacy haproxy+apache configuration, right? [17:19] frankban: yes [17:19] ok cool [17:23] benji: so AFAIK the only piece of code where we handle etags is the apache template, i.e. lines 30-31 of http://bazaar.launchpad.net/~juju-gui-charmers/charms/precise/juju-gui/trunk/view/head:/config/apache-site.template [17:24] frankban: are etags settings inferred from the cache control settings? I don't see etags mentioned in that file. [17:24] frankban: when you get a chance, could you please add some comments to https://bugs.launchpad.net/juju-core/+bug/1271248 ? [17:24] <_mup_> Bug #1271248: LXC local has issues in trusty [17:25] gary_poster: sure [17:25] ty [17:33] gary_poster: we wanted to push an updated juju-gui trunk branch that has a moved note right? Is the thought to remove all the files and leave a MOVED which notes the github url and notes? [17:33] rick_h_: yes, precisely [17:34] and thank you for remebering [17:34] +m [17:35] benji: you are right, that directive seems to just tell the clients that they should revalidate [17:41] benji: http://httpd.apache.org/docs/2.2/mod/core.html#fileetag IIUC, the Apache default for etags is not sane if you use multiple nodes [17:41] frankban: that sounds like out situation :) [17:41] * benji reads [17:41] benji: INode MTime Size is the default. I guess the first one is different for each node [17:43] frankban: that matches what I've seen in how the etags vary (the first bit changes while the rest is the same) [17:43] benji: so if it makes sense to you, we could try adding "FileETag MTime Size" to the template [17:44] yep, that sounds like a winner [17:44] (assuming the modification time and the file size are the same in each apache instance) [17:47] gary_poster: care to play editor or just ack good 'nough https://pastebin.canonical.com/103326/ [17:52] rick_h_: +1 thank you. suggest you also include link to lp bugs for gui [17:52] gary_poster: rgr, will add [17:52] otherwise fire away [17:52] * gary_poster goes to lunch [17:52] back in a while [17:53] frankban: I'll work up a branch that tweaks the apache config [17:54] benji: sounds good thanks [18:01] * rick_h_ starts playing taps http://bazaar.launchpad.net/~juju-gui/juju-gui/trunk/files [18:05] rick_h_ are we using github releases for the gui releases? [18:05] hatch: lmao please tell me you mean my other left in this card? https://canonical.leankit.com/Boards/View/102529849 [18:05] hatch: no, not at this time. I'm all for it though. It has an api to do it [18:05] hatch: for now they're staying in LP [18:06] :) leankit direct to card linking is broken [18:06] bah, well the unit dying UI stuff [18:06] wel dying service that is I guess [18:06] I think I did that already.... [18:06] ok, well card in high for that [18:07] oh yeah I am pretty sure it does that already [18:07] if you want to test you can spin up a lxc instance and spin up, say, wordpress [18:07] then destroy it [18:07] I am pretty sure it goes into a dying state list [18:08] right, but if you look in the *right* image there's a block under the service name that says "this service is ... " [18:09] ohhh [18:09] right that's not there [18:09] ok, I'll replace left with right in that card [18:24] I really gota stop trying to run virtualbox and parallels at the same time [18:25] it crashes hard [18:25] hah [18:36] and it apparently totally borks my networking hah [18:37] boom! [18:37] I can't wait till 14.04 so I can install it on metal [18:43] rebase conflicts have to be the worst [18:44] hatch: :/ I think the thing is you don't get them that often if things are going smoothly so not used to dealing with them [18:44] yeah, and now I'm trying to rebase something like 28 commits [18:44] lol [18:56] yay think I got it [18:56] not entirely sure how there were conflicts when merging in order [18:56] but oh well [18:57] of course we'll see when the lint and tests pass hah [19:04] leankit direct card linking works fine fwiw: https://canonical.leankit.com/Boards/View/102529849/108600813 for example [19:04] you have to use the link on the bottom right of the card details [19:05] and once you click on it, the card itself is removed from the url (that seems like a mistake on their part) [19:05] yeah exactly [19:05] If you put a link to a PR in a comment the PR gets a new line in it saying that it's been referenced elsewhere [19:05] ^ on github [19:06] nice [19:06] jujugui could I get a review/qa on https://github.com/juju/juju-gui/pull/81 plz, it's a long one (huw's branch) [19:06] hatch, on it [19:06] thanks [19:06] it'll be nice to finally get this in there [19:07] definitely [19:08] rick_h_: if bac doesn't have the charm fix soon, maybe get this one in [19:08] with a new gui release [19:08] gary_poster: rgr [19:08] not a request, jst an idea [19:08] gary_poster: yea, it's np. The gui part isn't that bad actually. Spent most of the time trying to dbl check docs [19:08] gary_poster: it won't be today. it doesn't look like the change to juju-deployer 0.3.0 solves the problem and i haven't tracked it down yet [19:09] bac ok. we need to cut pait sometime soon and make a gui release. been way too long [19:09] cut bait [19:09] sorry [19:09] gary_poster: I've got a fix in progress for a deployer UI bug as well. So maybe tomorrow we can see where we are and re-start release process [19:09] gary_poster: ok. perhaps we just do two in short order [19:09] ok [19:09] well, bundle UI bug [19:10] cool [19:13] hatch: qa: SWEEET! :-) [19:14] haha, that should be our new QA OK [19:14] :-) [19:33] hatch: got a quick sec to look a mini-bug fix https://github.com/juju/juju-gui/pull/82 please? [19:33] sure [19:34] hatch, done. +1 with a few very trivial bits [19:34] great thanks, I'll get on those after rick's branch [19:35] cool [19:36] it's lookin' pretty snazzy on chrome [19:46] bug spam alert! [19:53] heh, what with you and curtis, it's almost like people are gardening bugs! ;-) Thank you! [19:54] heh, figured fullscreen is dead, bye bye any bugs dealing with that [19:54] and then... [19:59] gary_poster: I have an Apache configuration tweak that should make etag generation consistent: https://codereview.appspot.com/55210044 [19:59] looking [20:00] benji, cool. yeah, I thought we had something like that already. so the mtime should be on the basis of the time the gzip was made, not the time it was decompressed? [20:01] if you follow my question? [20:01] gary_poster: right. I'm deploying a second time the charm right now so as to verify that the etags generated by the second machine match those from the first [20:02] benji, perfect. thank you! [20:02] my pleasure [20:06] newHeight = this.panelsHeight > [20:06] tabHeight ? this.panelsHeight : tabHeight; [20:06] gary_poster is this indentation better? [20:07] well the tabHeight lines up on 'e' on the previous line's Height in panelsHeight [20:08] hatch, better, but can we break lines somewhere else? If not, the indentation is at least improved [20:08] newHeight = ( [20:08] this.panelsHeight > tabHeight ? ...) [20:08] ? [20:08] actually [20:09] I could make it use smaller var names and put it on a single line [20:09] isn't this just max [20:09] newHeight = panelsHeight > tabHeight ? panelsHeight : tabHeight; [20:09] there :) [20:09] oooor [20:09] hatch: newHeight = Math.max(this.panelsHeight, tabHeight) [20:10] yeah hah that just came to me [20:10] conveys intent better and shorter, for the win, IMO ;-) [20:10] agreed [20:10] changing [20:10] cool thanks [20:15] oh yay now there are conflicts [20:15] * hatch blames rick_h_ 's branch [20:15] bwuhahaha, first to land, first to skate [20:15] lol [20:15] u suck [20:15] that is all [20:16] my 2 line branch must have killed you [20:16] pretty much [20:18] ok, can't believe after all that there's still > 150 bugs in there [20:21] poop [20:22] it's merge has totally put the code in the wrong spot [20:23] etag match verified, we have a lock, awaiting firing command [20:23] woot! [20:26] *FIRE* [20:27] .....what are we firing? [20:27] P [20:27] ok, done with bugs. It's reached depressing point. /me runs away [20:34] benji, merge away [20:34] gary_poster: alreday done [20:35] benji awesome thanks [20:35] rick_h_: don't be depressed :-) [20:35]