[00:26] Makyo, hey. It might be reasonable to try to land the fixes you have now. That will make it easier for us all to know where we stand, and keep us from discovering and/or solving the same bugs repeatedly. If you'd like me to help with that, send me a branch and I'll tackle it tomorrow morning. [00:26] * gary_poster steps away [00:27] gary_poster, Will do, they're a minimal mix of what you had and trunk, now that bcsaller landed. Little else I tried worked. Will keep poking at locations, but push first. [00:29] cool thanks Makyo [01:51] <3 my job. Working from the campground tomorrow. Had to run out at the last minute tonight when I called and they said "We've got 8 spots left" and only had 3 to pick from when I got here. [11:19] morning ranger rick_h_, you around? [11:40] bac: around [11:40] hi rick_h_, get the good camp spot? [11:40] adeuring: did your branch land? [11:41] bac: meh, right by the zone entrance so lots of traffic and dust, but the wife is exstatic as it's 'boo bash' weekend with trick or treating and such [11:41] rick_h_: i've taken the card for updating manage.jujucharms.com to r416, which includes my icon fix. [11:41] bac: ok, I wanted to check on adeuring's branch. There was talk in a call of something that broke something and might need to be fixed? [11:42] rick_h_: sounds vaguely familiar. [11:42] * rick_h_ is checking changelog [11:42] rick_h_: i also saw one spurious test failure in trunk locally. looking at that. [11:43] bac: ok cool, looks like adeuring's branch landed and was related to an issue we ran into setting up the new charmworld instance [11:43] bac: so r416 looks peachy to me [11:43] +1 [11:44] thanks for taking the upgrade [11:55] bac: did you check with gary_poster on the icon fix? I was told that bundles will not support icons right now and we'll not show them. [11:55] rick_h_: it is showing the default icon. before the path was broken and showing a broken link in charmworld [11:55] bac: the gui will never show them, even for promulgated. I guess showing on charmworld could be different. [11:55] rick_h_: now it correctly shows the default icon for all bundles [11:56] bac: oh showing bundle.png? [11:56] ah, gotcha [11:56] rick_h_: default.svg or whatever [11:56] it's calling /file/icon.svg which will show bundle.svg so ok cool All good [11:56] bac: gotcha, thanks for the clarification. [11:57] np [12:18] guihelp: could anyone please review https://codereview.appspot.com/14531051 ? It's just a documentation branch. [12:20] frankban: sure thing [12:20] rick_h_: thanks! [12:21] gah, that's just a few steps. [12:22] geez frankban, i'm exhausted just glancing at those steps. you need to end with 'have a beer, cigarrette, or mountain dew' [12:24] heh... I agree. Otherwise we can add "drink a glass of wine each time you type `bzr`" at the beginning... [12:25] missed the step "move card from monday to done done now that it's friday" [12:25] it must be friday, that's taken from granted [12:26] oh right! [12:27] thanks rick_h_ [12:44] :-P :-) [12:59] gary_poster: morning! I am inclined to move my card in landing to done after reading Kent's email. Do you agree? [13:00] frankban, agree, thank you. I was going to ask benji if he had experience in mimicking firewalls for us to explore the bug he filed. That seems like a benji sort of thing to know. :-) [13:00] heh [13:00] the bug Kent filed, I mean [13:00] cool [13:00] well... [13:02] I was thinking that it wouldn't be too hard to set up iptables to give us the effect we're looking for. [13:05] benji, cool. Maybe something to explore end of next week if we have time. Would be cool to have that documented so we all can set it up and tear it down. Meanwhile, Kent didn't give the info I was asking for in the bug report, probably because he doesn't know the JS tools. If I have time I might try to hangout with him and look at the JS console. I wouldn't be surprised if this is a "duh" moment once we see the [13:05] console. [13:06] sounds good [13:21] gary_poster: re your quickstart email, it's all good, and I created the cards. Unfortunately I don't have an better story for the password, and I guess we don't want the password to be set on the charm. A not-so-good idea could be pre-filling the form once the page is opened... meh. I am not sure about tornado for the CLI. If the story is "the user waits for something to happen, and there is only one thing that can happen at the tim [13:21] e" I guess we can block and still have gradual feedback. But surely I am missing something, and I'd also be happy to be proved wrong. [13:21] benji, bac, abentley: could one of you have a look at this MP: https://code.launchpad.net/~adeuring/charmworld/bump-charmtools-version/+merge/190648 ? [13:22] adeuring: sure [13:22] thanks! [13:36] frankban, cards: thank you! look good on first scan, and I'll look closer in a few minutes. password: yeah. If we could prefill the form locally somehow...sending stuff on the query string is the only approach that the python webbrowser module supports & would technically be safe IIRC because we are using https, but it seems a bit ugly. Thinking about it some more, there probably is some kind of SSO-like token [13:36] story available. Example: quickstart generates a one time pair of openssh keys. It sends the private key to the gui server over https API call and the gui server agrees to remember it for 1 minute only. We encrypt the admin secret with public key and then that is included in query string, and the browser logs in with that value. gui charm decrypts password with private key, authenticates against juju, and we're [13:36] off. There's probably a simpler version of that, but that would work, I think. WDYT? tornado: ok, I trust your hunch. If we can move faster without it and still have a good experience, then cool, I'll trust your hunch. I just thought it would be nice to be able to show progress. [13:37] gui could be responsible for generating the public/private key, actually, and then it would send the public key back. That would be less weird [13:38] quickstart to gui: Please generate a onetime public key for me [13:38] gui to quickstart: ok, here you go. I will remember it for one minute [13:38] quickstart to browser: here, I encrypted the admin secret with the public key. [13:39] browser to gui charm: hey , here's the encrypted key [13:39] hey benji do you have a second to talk about bug 1234780 [13:39] <_mup_> Bug #1234780: Dict has no attribute series [13:39] bac: sure [13:39] i'll start a hangout [13:39] This is arguably super paranoid. https really should be sufficient. This way the URLs are a a poor attack vector, at least, though. [13:39] [13:41] benji: https://plus.google.com/hangouts/_/98f14bc332fe7144160604ebfa68d0ee12c35566?hl=en [13:41] bac: with that bug, as far as ingest is concerned, it's only optional if we can find the charm without it [13:41] gary_poster: that's interesting! I was only thinking about some sort of selenium-like "i'll put your password in the form ad then click login for you", but your story is definitely better :-) re tornado: I am still not sure, I guess we can start with tornado and then quickly step back if we realize it's giving as nothing but "yields" [13:41] bac: it's kind of related to what I'm tring to do to add proof checks for finding the charm and using series is one way to do that [13:41] bac: in case it relates to anything [13:42] s/giving as/giving us [13:42] frankban, tornado: ok cool. Or should we start with the simplest story, without tornado, and only add it if we start to feel pain? simple is good. [13:43] bac benji when you get done, I've pulled trunk and can no longer run things as it can't find the python charmtools module. I've installed the package, but not seeing where there's a python lib for it? [13:46] rick_h_: we moved charmtools into the included dependencies, so the system charmtools isn't used any more [13:46] we had an issue yesterday with the packaged dependencies being updated, but I thought that was fixed [13:47] benji: into the download-cache? [13:49] benji: ok, got it. For some reason my bzr up didn't up I guess [13:49] gary_poster: heh, ok, I'll wait and think about it. the weekend is there for this kind of implementation details illuminations ;-) [13:49] frankban, lol ok [13:50] ri [13:50] back in a few [13:50] rick_h_: did you run make after updating? That should have updated the download cache. [13:50] oh, I was running make sysdeps vs make deps and it didn't get updated since I was looking in the wrong place. [13:50] benji: so we can remove the charm-tools from the sysdeps line now then? [13:50] rick_h_: yep [13:51] benji: no, I looked for charm-tools in the makefile and foud it in sysdeps and so ran sysdeps manually [13:51] also, just "make" will be all you should need now (other than if you need sysdeps) [13:51] benji: right, since it was listed I thought I was missing something from sysdeps [13:51] yep [13:52] * frankban biab [13:54] adeuring: your branch looks good. i'm just running tests now. [13:54] bac: thanks! [14:04] yay I could finally connect [14:06] benji, rick_h_, adeuring: could one of you look at https://code.launchpad.net/~bac/charmworld/bug-1234780/+merge/190676 [14:06] bac: I'll take a look. [14:06] benji: got a sec to chat after that? [14:06] rick_h_: sure [14:08] rick_h_: I'm available. [14:09] benji: k, your webrtc link then? [14:09] rick_h_: sure (benjiyork.com/chat) [14:10] benji: http://paste.mitechie.com/show/1039/ [14:21] Makyo, proposing my change now [14:22] gary_poster, okay, cool [14:26] jujugui, looking for 1 review and qa of small branch: https://codereview.appspot.com/14548050 [14:26] On it. [14:29] gary_poster, LGTM (been QAing w/ this change this morning, go for it) [14:43] there's a bit of an antipattern going on in charmworld: several places pass around dictionaries (charm info mostly) and different callees assume different things are in the dict. It makes understanding the code harder than it would be if we passed the individual bits of data each function needed. [14:49] benji: yea, so that came to be an issue from the whole mongodb flexible document thing. The answer to some of that was supposed to be "Charm(dict)" and then we had a more stable 'model' to use [14:50] jujugui call in 10 [14:50] \o/ [14:51] Makyo: 4, gary_poster 1 - this weeks "closest to his meeting reminder and keyboard" winner is Makyo! [14:52] benji: it's why we've got all the Charm(charm) calls around if I recall correctly [14:52] I'll have you know I heard my phone buzz while I was making coffee and ran over to ping. [14:52] rick_h_: the model helps quite a bit; unfortunately for the thing I'm doing we don't have all the charm data, just bits and pieces [14:53] benji: heh yea I was just typing "though in principal I'm with you on ...provide data required" kind of thing. [14:53] yep [14:53] benji: though I'm not looking where you're looking so kind of not 100% sure [14:53] e.g. if the method name is "do_some_for_charm" then a charm model seems legit [14:53] vs bits [14:54] I see the same problem with objects a lot too, some deep chain of function calls operate on an object and you never know which attributes are touched along the way [14:54] jcsackett: Did you push add-github-job up directly instead of letting the jenkins lander handle it? [14:55] :-) [14:56] hey Makyo, thank you very much for review. I'd suggest using trunk now, rather than your branch: there's one part of what I gave you that you should discard, because Ben fixed it better. trunk has only the good bit [14:56] abentley: this failure appears to be spurious. thought you might like to see it. http://162.213.35.27:8080/job/charmworld-autoland-lxc/36/ [14:56] bac: Thanks. [14:56] gary_poster, that's the part I pulled out yesterday, but I think trunk and my branch are now equal except for my changes. Just to be safe, though, I'll pull my changes out and move them to trunk. [14:57] (mostly just tracing coordinate stuff, granted) [14:57] cool thanks Makyo. [14:58] bac: Do you have any idea why it failed to install ycssmin.tar.gz ? [14:58] jujugui call in 2 [15:00] bac call now :-) [15:07] bac: The file /var/lib/jenkins/jobs/charmworld-autoland-lxc/workspace/npm-debug.log mentioned in the build does not exist. Without it, there's not much I can do to debug this. [15:07] abentley: ok. the next attempt was successful. [15:27] Hi, what is the best way to store a user setting in the gui? [15:28] antdillon: I think we were thinking of using localstorage to detect if you've seen it before/not [15:29] rick_h_, Ok, is there a plan to have a localstorage class to getting and setting? [15:31] antdillon: not sure, wait to see what others thik [15:31] think [15:34] rick_h_, Cool thanks [15:44] antdillon, two approaches. (1) we have some sessionStorage code in app/store/env/base.js. You could try extracting that. Important note: gui should work with cookies turned off! you'll see there's a bit of code for this case. [15:44] gary_poster, re positions: I'm going to work on a fix for release, bcsaller is working on simplification to help prevent (or at least ease debugging of) this sort of thing in the future. [15:44] Makyo, sounds great, thank you. [15:46] antdillon, (2) app/assets/javascripts/app-cookies-extension.js [15:46] not sure what to do with that one :-) [15:47] gary_poster, Ok I'll check them out, base.js seems like it has good stuff [15:47] cool antdillon [15:48] gary_poster, Thanks [15:48] welcome [15:48] so do the people who turn cookies off also turn off local storage? or is that ok? [15:48] lol [15:48] * hatch doesn't get it [15:48] can you turn of local storage? /me doesn't remember a setting [15:49] hatch: well localstorage isn't sent on every request in the headers so things like invisible gifs won't ping/send data [15:49] hatch: you actually have to download a file, and get access. and can't cross domain bounds. [15:49] well tracking gifs work by just being downloaded [15:49] hatch: but then there's the "turn off JS" folks I still don't understand [15:50] hatch: right, but the request can return any cookie headers [15:50] /can/will [15:50] oh right [15:50] e.g. you can set a cookie from a gif request [15:50] anyway, the cookie thing is all EU, crazy people :P [15:51] maybe it's a knee jerk reaction to the surveillance state :D [15:52] adeuring: charmworld is complaining that "string" is not a valid value for "type", http://staging.jujucharms.com/~juju-jitsu/precise/charmworld but according to the docs, it is: https://juju.ubuntu.com/docs/authors-charm-config.html [15:53] rick_h_: enjoying working from the camper? :) [15:54] abentley: interesting.... That page is new; I assumed that "str" is correct based on an older version. Seems that another update of charmworld is needed... [15:56] 65" 4K Sony TV $6000 - that seems like a good deal [15:56] abentley: sorry for delay in response, and yes, i forgot you had jenkins set up for our charm as well now. :-( [15:56] (no I'm not buying one) [15:56] :) [15:57] jcsackett: No, I don't actually. I missed the fact that it was on the charm. Carry on. [15:57] abentley: fantastic. misunderstandings both ways. :-P [15:58] glad i didn't eff anything up. :-) [16:26] gary_poster: do the users have the ability to alter any of the bundle settings before deploying? [16:27] it looks like the DD just calls deployerImport() [16:27] is this the same interaction we want for the details view 'add' button? [16:45] anyone else use the chrome devtools 'watch expressions' section when in a loop? makes things so easy to debug [16:52] hatch, no they do not, until we develop that functonality (I am calling it bundle v2 in the slides and such) [16:52] and yes, I use watch expressions [16:52] ok cool [16:52] and I am returning to lunch :-) [16:52] so this is going to be a little more work than just 'hooking up the button' [16:52] just FYI [16:53] hatch, oh? why? [16:53] right now the 'deploy charm' button calls the deployCharm method which is bound to the App [16:53] er deployService [16:53] (can hangout if you want) [16:53] sure tha'll be faster [16:53] k [16:53] hatch https://plus.google.com/hangouts/_/10fe9c48d75b9ebbe273219cb03f4e53869ce4f7 [17:16] is there a known bug where you deploy a bundle and pan/zoom no longer work on the canvas in sandbox? [17:16] actually all canvas events appear to be broken [17:16] gary_poster: webops is pushing back on a friday charmworld deployment. worth pressing? [17:16] well not all [17:18] annnnd done [17:18] gary_poster: good thing we had that chat lol [17:21] gary_poster: nm, i have overwhelmed them with my rhetorical skillz [17:25] hey rick_h_, i'm a bit confused. this record looks good in production http://manage.jujucharms.com/charms/precise/juju-gui/json [17:25] rick_h_: but the fix (r412) has not yet been deployed. can you see what i'm missing? [17:27] bac: lol [17:28] hatch: what you laughing at? [17:28] ""nm, i have overwhelmed them with my rhetorical skillz"" [17:28] oh, not my unbrokenforunknownreasons code [17:29] rick_h_: now we'll never know as the patch has been applied [17:36] bac, lol [17:37] hatch, cool :-) [17:38] hatch, if you are looking for something to do next, feel free to steal my bug 1236427. I still suspect it will be easy but have not gotten to it yet. [17:38] <_mup_> Bug #1236427: Scale up input stops working after units are added/removed [17:38] I'm just workign on the notifications now [17:38] and they are being...odd [17:38] oh ok [17:38] bad odd but good that you are working on them :-) [17:39] * gary_poster steps away for just a couple more minutes, then will tackle that bug [17:39] jujugui: manage.jc.com is now on 416 [17:39] bac, awesome thank you [17:40] Going to step away to grab food for lunch, we're out. Back in a few. [17:40] m.j.c looks healthy to me [17:41] ohh sandbox doesn't call the rpc callbacks does it? [17:42] bac: yea, not sure. I wonder if it's some sort of 'recovers itself on successive' runs thing [17:42] bac: yay for upgrade [17:42] rick_h_: don't see how it could've given that code structure. dunno. [17:43] rick_h_: maybe the upgrade and ingest just happened so fast i was looking at new data [17:43] bac: yea, me either. :/ [17:43] possible I guess [17:43] i'm not going to lose sleep over it working properly [17:43] can anyone confirm that the sandbox does not call the rpc callbacks? I always thought that it did [17:44] bac: :) [17:44] I think I broke something [17:44] hatch: stop doing that [17:45] fixed [17:45] syntax error the linter didn't catch [17:45] lies! [17:45] * hatch shakes fist at linter [17:45] the linter is all knowing! [17:46] or all-dumbing! [17:46] yeah....I went there [17:47] i love the new RT feedback form [17:47] you rate the effort by picking :( :| or :) [17:49] I would hack the form to submit :P [17:51] so...hungry... [18:00] ok proposing now going to grab some lunch [18:00] gary_poster: when I get back I can look at your bug if you aren't on it already [18:02] hatch, cool. I'll see if I make progress [18:02] jujugui lf review https://codereview.appspot.com/14419062 [18:02] annnnd I'm out [18:02] on it [18:02] thanks [18:04] "error: old chunk mismatch" [18:04] wonder what does that [18:22] hatch LGTM [18:34] hi guys, is [45133532 bytes] the size of the juju-gui charm in this verbose output? http://pastebin.ubuntu.com/6223679/ [18:39] ahasenack, don't know the log messages, but quite possibly. the charm now includes the gui, rather than downloading it separately from LP, so once the charm is downloaded, the rest should go very quickly--and the total time should be as good or better than before. This change supports deployments behind a firewall. be no slower than before, and arguably faster. [18:40] that's a 40Mb+ upload [18:40] not even landscape is that big [18:40] and it's still not finished [18:40] (the upload, not landscape ;) [18:41] well, I don't know what it's doing now [18:42] gary_poster: are you saying the charm contains the juju-gui release tarball? [18:42] ahasenack, yes [18:43] tarball includes build tools. does not need to. but not a new issue. should not be a problem, unless downloading charms is slower than downloading from LP? how long has this taken, ahasenack? [18:44] it hasn't finished yet [18:44] "writing charm to storage [45133532 bytes]" took 10min [18:44] and that finished 12min ago [18:44] ahasenack, huh. what env? [18:44] canonistack [18:44] ah :-( [18:44] so, before this would all happen remotely [18:45] 45M . [18:45] now it's actually a roundtrip? I download from jujucharms (UK -> BR), and then upload back to the UK? [18:45] oops [18:45] /home/bac/charms/precise/juju-gui> du -sh . [18:45] 45M . [18:45] so, yeah, the size you see is right [18:46] how about versions? Before I could select trunk, release, etc. Now with the tarball inside the charm, how is that handled? [18:46] ahasenack, charms are always a roundtrip. [18:46] gary_poster: yes, but not a 45Mb one :) [18:46] but yes, if connection is slow, that's pretty painful [18:46] ahasenack, yeah you can do all of that as before. The default juju-gui-source is now "local" [18:47] but if you choose something else behavior is still there [18:47] ahasenack, we will prioritize two relatd bugs. should get size to less than 80% of current [18:47] I mean [18:48] should get it smaller than 20% of current size [18:48] that helps :) [18:48] I can deploy landscape several times over while I'm waiting for "juju deploy juju-gui" to finish :) [18:48] I'll leave it running just for curiosity [18:49] ahasenack, yeah, that's pretty bad. We've had happy reports from this change, but yours is the first sad one :-) [18:49] I don't get what's wrong with a package in a source url, like ppa (you could open it up in a firewall), or even pointing to a local mirror [18:50] but ok, people with big pipes win [18:52] ahasenack, opening it up in a firewall leads to sucky directions. setting up a local mirror leads to sucky directions. this was prioritized because we repeatedly had enterprise situations in which this was a big annoyance, and then someone documented what was necessary to use the gui behind a firewall in preparation for publishing it, and it was horrible. We wanted the story to be way better than that. The thing [18:52] is, it would be good if we didn't cause huge pain for people with smaller pipes too. [18:53] So hopefully shring to <20% will be enough of a win that it will work for both [18:53] shrinking [18:53] ahasenack: are you using pyjuju? [18:53] these guys seill need to be able to reach the charm store anyway [18:53] bac: no, core 1.16 [18:53] and I think the icons are also fetched from the store at runtime [18:54] ahasenack: with juju-core it doesn't download locally, it goes straight from the charm store to the environment, iirc [18:54] bac: well, I don't know what's happening here, I could start some tcpdumps [18:54] but this is my console right now: [18:55] http://pastebin.ubuntu.com/6223751/ [18:55] so a deploy to canonistack should be pretty fast regardless of where you're sitting (he says sitting behind crap isp) [18:55] and now would be 18:55 according to that timezone (it's using utc for some reason) [18:56] I think it's uploading, because my irc lag is 3.6s [18:56] meaning upload link saturated [18:56] right, just not the behavior i'd expect [18:57] yeah, it's talking to bootstrap [18:57] finished [18:58] 34min51s for "juju deploy juju-gui" to finish [18:58] :-( [18:58] ahasenack, (1) we'll prioritize those bugs. Hopefully that helps. (2) We'll ask juju core about this behavior, since we apparently don't expect it. [18:58] http://pastebin.ubuntu.com/6223761/ [18:59] ok [18:59] ah, since the juju-gui-source is local, it is our charm downloading it and then uploading again. the charm went straight to canonistack but the juju-gui tgz did not. [18:59] gary_poster: ^^ [19:00] bac, ? why? [19:01] bac, when "local", it uses the juju-gui tgz that is part of the charm [19:01] gary_poster: no, i think i got it wrong. i'm back to not understanding [19:01] k [19:04] * bac afk for a bit [19:10] gary_poster: why was juju-gui the only charm with firewall problems? All charms before this one need to apt-get install something, so why were they not impacted? [19:11] because the ubuntu archive is a "known" variable, and the admins have it open in the firewall/proxy? [19:11] yes ahasenack [19:11] and you don't have debian packages for juju-gui I presume [19:11] ahasenack, bug 1238931; subscribed you. [19:11] <_mup_> Bug #1238931: Juju GUI charm takes an inordinately long time to deploy over small connections [19:12] ok [19:12] no, it's a pile of static files [19:12] ok [19:22] gary_poster: re your comment - I'm pretty sure the topology doesn't have access to the app outside of the global 'app' pointer [19:23] hatch, no? I'm pretty sure it has access to env, though, in which case this could be a helper that takes an env and a bundle? [19:24] hatch, just trying to reduce duplication [19:25] well...we 'could' modify the deployerImport method to take a 'db' param so that it could deal with the notifications internally [19:25] but that doesn't feel right [19:25] no [19:25] I meant [19:25] a separate helper [19:26] that takes, say, db, env, and the bundle [19:26] and handles it [19:27] ohh, hmm we could.... [19:27] topology is kind of 'odd' [19:27] we could pass it in [19:27] I suppose we are doing that already [19:27] environment.js:354 [19:28] hatch I was thinking we could define it in a utils [19:28] because it would need a context [19:28] if you passed enough of one in [19:29] ok how about this - I add a method in utils which is simply the callback for the env call [19:29] +1 I buy it [19:29] deal! [19:29] :-) thanks hatch [19:29] no problemo [19:31] gary_poster: I have backfilling working, but there are a few issues: [19:32] * gary_poster listens [19:32] 1) my changes are completely untested (but they aren't huge changes, so I don't think that's too bad) [19:33] 2) because of the way ingest works, the elastic search index briefly contains *older* versions of the charms (because everything that comes in is indexed, there was no consideration that the things enqueued might not be the most recent version) [19:33] 3) the code needs to be spiffed up a little (lint, comments, etc.) [19:34] * gary_poster does not yet understand #2 yet [19:34] 4) the way I got it working isn't the best in the world; once the above are fixed, it would be landable, IMO, but some deep thought ane refactoring of the injest mechanism is in our future [19:35] gary_poster: call? [19:35] sure. can try your magic url again if you want, or https://plus.google.com/hangouts/_/10fe9c48d75b9ebbe273219cb03f4e53869ce4f7 [19:35] the hangout is fine [19:36] jujugui quick review/qa request for https://codereview.appspot.com/14512056 [19:36] gary_poster, on it [19:36] on it [19:36] damn [19:36] :-) [19:36] up to you hatch [19:37] thank you both [19:37] I'll take a look, either way. want to QA hatch ? [19:37] sure [19:38] do we know why it was set to disabled on line 200 to begin with? [19:38] Because that was yanked from old code. [19:38] I was wondering if it might be something like that. [19:38] Cheers to finding it, +1 gary_poster [19:39] thanks Makyo [19:39] Those mixins are mostly view functions from old internal views, hatch [19:39] ahh [19:39] coolio [19:39] that would explain the lack of docs as well :P [19:39] Perhaps. [19:39] One of these sleepless nights I'll go on a docs binge. [19:40] (well, I'll probably watch a movie, but one can hope) [19:40] haha [19:40] I think about project ideas and then write them down [19:40] if I dont' write them down I'm up all night [19:43] qa ok [19:43] does the constraints element do a wierd jittery jump for everyone else too? [19:44] at first I thought it was just on my laptop but now I noticed it on my desktop [19:55] bac: I need to do some knowledge transfer with you about my current card, but I don't have time now; how long will you be around today / are you going to be here Monday? [20:01] benji: i will be in monday [20:01] bac: ok, I'll get you early Monday then [20:02] ok. benji did you get my email about that old branch of yours? [20:02] bac: I hadn't seen it but I'll look as soon as I get back from my appointment. [20:03] ok. have a good weekend [20:11] gary_poster: created the utils method, qa'd ok, wrote tests for it - I'm just going to submit if that's ok? [20:11] hatch +1 thanks! [20:13] cool - I open a new tab and chrome says google has updated their policies - I click the link, and it gives me a plain text version of what's changing and a direct link on how to fix it [20:14] I'm so used to 'our terms have changed, here are 300 pages of legal BS, try and figure out what changed' [20:16] gary_poster: so what now? mojitos? [20:32] I'm going to tidy up the SUmmary page [20:38] oh turns out it's already hooked u [20:38] p [20:38] heh [20:40] hatch, :-) [20:41] can you think of anything for a 2h job? [20:41] else I'd like to write a cache for the json load requests for our tests [20:42] hatch, "if bundle does not have x, y annotations we handle it gracefully (example: don't show visualization)" is good. just marked it high. what's the json load? you mean from the local server? [20:43] ok that'll work [20:43] yeah - so we aren't hitting IO every test :) [20:43] hatch, either one is fine. do whichever you wish. [20:43] If you want me to make up my mind, I'll choose the bundle one, but happy for you to choose. [20:44] nah I'll do the bundle one [20:44] real work comes first :) [20:44] :-) k [20:53] gary_poster: just fyi after this branch lands we won't ever see a bundle env again :) [20:53] because none of them have xy's hah [20:54] hatch I know :-( . Maybe make a feature flag? [20:55] yeah that's kind of what I was thinking too [21:28] ugh apache hates me [21:37] don't feel bad, apache hates everyone [21:38] it's all like "don't act like we're friends....you don't know me!" [21:39] :-) [21:41] hatch btw your fancy ghost inspector name checker no longer works. if you are still looking for something to do at some point you could fix that up :-) but no rush [21:41] Is Upgrade not supposed to work in sandbox? [21:42] gary_poster, I was just thinking about that. In sandbox, there's no juju backend to provide the older charms. [21:43] gary_poster: hmm, which fancy namechecker is that? [21:43] * hatch pleeds the 5th [21:43] Makyo, ah ok. Sounds like something we could build eventually, but for now we ought to say "if sandbox hide"? Which I bet would be annoying, since you just ripped out the featureflag code :-/ [21:43] hatch, for instance, deploy mediawiki twice [21:43] gary_poster, that's what I was thinking. It's not too big of a deal, though, since a lot of those checks were in other if statements. [21:44] hatch o i c [21:44] hatch it works but it doesn't initialize properly [21:44] oh I see [21:44] so for instance if you deploy a mediawiki without changing the name [21:44] yeah soemthing must have changed there [21:44] and then try it again [21:44] it should have an x [21:44] right [21:44] So this position thing is a race condition with removing annotations, which finally showed up in FF because I left the debugger on a breakpoint while talking to roommate. :P [21:44] but if you change it and change it back the x appears [21:45] Makyo, heh [21:45] hatch oh but now x does not get removed either. I'll file bug later [21:46] gary_poster: ok - I can look at it right away, just lboxing the graceful failing code right now [21:46] great thanks hatch [21:47] I have a nice change that reduces our distribution tarfile by >80%. [21:47] But I can't figure out how to test it in apache other than symlinking build-prod contents in /var/www :-( [21:47] by enabled custom site is ignored [21:47] my [21:48] and I need to include instructions for how to test it in a release [21:48] Maybe I should try nginx :-P [21:49] hmm I did know how to do that [21:50] I copied everything out of our charm; I have permissions right on files and in config file; no errors; it is enabled, because when I make a deliberate error, it throws up; but I always only ever get the /var/www content [21:50] hmm [21:51] I just looked through my httpd.conf file and it's all giberish to me now :/ [21:51] sorry [21:51] lol np thanks. trying nginx [21:58] jujugui lf a review and qa of https://codereview.appspot.com/14502061/ plz [21:58] on it [21:59] thanks [22:04] hatch made a small test request; otherwise LGTM. Doing qa now [22:04] thanks [22:06] bcsaller, hey. what do we need to do to produce exports with x y annotations? really would be great to have those asap. I think you have this figured out? [22:10] * gary_poster curses at xchat internally yet again [22:11] hatch, qa ok as intended. Feel free to land with my thanks. Am I right that it would not be a trivial task to make the Bundle tab hide instead, or to default to Summary if the xy coords are not there? [22:12] yup - we could just delete the elements from the template then they won't get PE'd when we render the tabview [22:12] would you prefer I do that instead? [22:15] FYI according to the tests it takes 50ms to render the bundle topology off screen :) [22:15] that's actually pretty substancial [22:16] hatch, I think that would be better to delete but welcome your opinion [22:17] hatch, re: rendering time, is there something to do? [22:17] probably not [22:17] at least not without looking into the actual topology code [22:17] to see what's happening there [22:18] ok [22:18] I don't see a danger there yet [22:18] as far as deleting the tab goes a) the user is none the wiser and it looks better for it b) the user wonders why it doesn't have the topology while others do [22:18] so won't do anything [22:18] nah I wouldn't waste time on it now [22:18] ok [22:18] a: yes [22:18] b: arguably similar to the default icon story? [22:19] oh there is a c) [22:19] c) we autolayout the bundle [22:19] :) [22:19] (always need a c) [22:20] heh [22:20] yeah c is alright but no time :-P [22:20] I'm sure Makyo is just looking for new layout features to add right now [22:20] and results are not good [22:20] lol [22:20] heh [22:20] alright a) it is [22:21] d) it could delete the tab and land on the charm tab so it has the charm details [22:21] :) [22:22] hatch, that's actually even better :-) [22:22] if you get around to it [22:22] must run [22:23] have a great vacation hatch! enjoy! [22:23] thanks, have a good weekend! [22:23] thanks :-) [22:38] gary_poster: sorry missed your question before, I can extract that patch now, its very small [22:40] gary_poster: http://paste.ubuntu.com/6224554/ [22:41] oh, too late [22:49] :) [22:52] oh crap I proposed instead of submitted [22:52] oh well [22:52] heh