[00:07] is there a juju dev mailing list? [02:57] *yawn* === gary_poster is now known as gary_poster|away === rogpeppe1 is now known as rogpeppe [12:09] morning frankban. i've gotten one review on my quickstart branch but thought you might be interested: https://codereview.appspot.com/28520044/ [12:12] bac: morning, already reviewed [12:12] frankban: oh, thanks. i didn't see the email [12:13] np\ [12:23] frankban: thanks for the QA and tips on how to streamline quickstart commands. landing now. [12:24] frankban: i didn't know you could launch an environment without deploying a bundle. [12:25] bac: yeah the bundle parameter is optional [12:26] jujugui battling a migraine this morning. Taking meds and going into blackout mode. Will check in later. [12:26] rick_h_: oh, sorry. i didn't know you suffered from those. i luckily don't but i know how tough they are. === gary_poster|away is now known as gary_poster [13:10] sorry rick_h_. feel better. [13:10] thanks for great review frankban. following up on both suggestions and then will land. [13:13] gary_poster: cool thanks [13:50] bac: this looks like something you might be able to tell me more about: http://paste.ubuntu.com/6442849/ [13:51] benji: is that failing in trunk too? [13:52] bac: I'm checking now. I don't see how my branches changes could make it fail, so I though I'd ask if it was a known issue. [13:52] benji: i'm running against trunk. haven't seen it before [13:52] hrm, might be me then [14:01] morning all [14:02] benji: i don't see any failures in trunk [14:02] bac: I just got the failure in trunk [14:02] huh [14:05] benji: if you run that test in isolation does it fail every time? [14:06] bac: running the test file failes every time, I'll try just the test [14:06] guihelp: in the last GUI trunk, trying to deploy a bundle dragging a file gives me: Uncaught TypeError: Object # has no method 'sendToDeployer' [14:07] bac: yep, the test run by itself fails [14:07] benji: dunno. works here. worked in CI. not sure how to help. [14:07] bac: I'll see if I can run it down. [14:08] frankban: that sounds like rick_h_ may have missed a method name when he refactored that bundle import code [14:10] hatch: yeah, sendToDeployer does not appear elsewhere in the code [14:10] frankban: see if you rename that method call to be 'deployBundleFiles' [14:10] to match what I believe is the new method name in app/assets/javascripts/bundle-import-helpers.js [14:11] hatch: the signature is the same, trying [14:18] hatch: it worked [14:18] great, now we gota figure out how to test that :) [14:19] or pass it off to rick :P [14:30] gary_poster: I am investigating the guiserver problems reported by rick: 1) error without messages: the dpeloyer can exit with "raise ErrorExit()". quick fix: we can check if the message exists and return something like "no further details can be provided". 2) subsequent deployments fail with no error messages: see http://bazaar.launchpad.net/~juju-deployers/juju-deployer/trunk/view/head:/deployer/env/go.py#L213 i.e. if a unit is in an error state, th [14:30] e deployer refuses to proceed. No quick fixes for this one :-/ [14:32] frankban, ack on #1. #2, thinking. [14:33] when a relation fails in juju-core it returns a relation-id which is simply a single digit and a 'remote-unit' which is -always- the other services unit/0 . [14:33] 1) should we be keeping a mapping of these core->gui relation id's? [14:33] frankban, #2 is for *any* units, right? Our code could certainly do the same check, yeah? [14:34] 2) is cores representation of the 'remote-unit' incorrect? and should instead mention remote-service? [14:38] hatch, I don't have confident answers on those. #1: it sounds like a nice to have at the moment, since it currently doesn't give us any new information, right? But eventually I suspect this will not always be unit/0. Did you check the juju core code that it is always unit/0? even in less usual cases like, say peer relations? It sounds like something for a GUI bug but not immediate action. #2: I bet that eventu [14:38] ally being able to specify a unit will come in handy, even if it does not now. We can certainly trivially deduce the service from the unit. You probably will need to ask core about it, like maybe Wm, because I doubt any of us know. [14:39] gary_poster: it surely can, and I was also thinking about adding a step in the validate method. on the other hand it seems more a deployer bug. it's not transactional, it starts deploying the service and the eventually exit, e.g. before adding relations etc... [14:40] brb sorry [14:40] gary_poster: and I am not sure about the reason to avoid deploying a bundle if a pre-existing unit is in an error state... [14:41] gary_poster: ok sounds good - I am just finishing up the simulator upgrades to match the real-world error messages and these are two issues which show themselves when there is a relation error between two services. I'll ask around in core land [14:44] seriously why the heck does core use so many single character variables with no documentation [14:44] * hatch rages [14:55] hatch, yeah, Tim Penhey has raged, and required book reviews etc. [14:58] yay :) [14:58] and yay it's snowing! [14:58] it seems a community stylism.. [14:59] hey frankban, there's hazmat! ask him about http://bazaar.launchpad.net/~juju-deployers/juju-deployer/trunk/view/head:/deployer/env/go.py#L213 ! [14:59] hazmat: yeah I've noticed that, and it's horrible [14:59] sorry outbound to a meeting.. [14:59] oh ok [14:59] :-) [14:59] gary_poster, which i was wondering if you might interested in.. as it might touch the gui [14:59] frankban, topic? bundles -> stacks? [14:59] sorry, hazmat [15:01] frankban, re wait_for_units? [15:01] frankban, needs a test? [15:02] hazmat, no we wonder why UnitErrors should cause an abort. If it does, we need better messaging through system. [15:03] but ISTU that, for instance, we might as well go ahead and make relations after unit errors [15:03] humans can go and address unit errors, but deployer did its thing [15:05] hey frankban I need to make this unit test change in order to get the rsync /test thing to pass tests. OK? http://paste.ubuntu.com/6443185/ [15:07] gary_poster: seems good [15:07] k thx [15:19] jujugui FYI if you see a warning in Chrome from YUI -> https://github.com/yui/yui3/issues/1417 [15:45] jujugui could I get a quick review/qa on https://codereview.appspot.com/29070043/ thanks [15:45] hatch: sure [15:46] thanks [15:51] jujugui call in 9 [15:53] oops [15:57] man I just CAN NOT figure out how to create a project on launchpad [15:57] I must be missing something obvious [15:57] found it@ [15:57] lol wow that was difficult [15:58] jujugui call in 1 [16:06] https://jujucharms.com/fullscreen/search/~hatch/precise/failtester-5/?text=failtester [16:18] gary_poster: what design bits have we launched in the last month/ [16:19] luca__, everything to do with bundles is biggie [16:19] gary_poster: yeah, was trying to get other stuff too [16:20] ok 1 sec [16:20] then need to go to another call [16:20] * The inspector tries to get out of your way when you are making a relation. [16:20] * The masthead’s UX is improved, notably giving a bit more room for the rest of the application. [16:21] aparently this disables hangout's typing mute for OSX folks: http://www.craigkerstiens.com/2013/09/12/disabling-muting-while-typing-in-hangouts/ [16:21] * Relations now display the names of both endpoints in the environment. (maybe design?) [16:21] * Add the ability to deploy straight from quicksearch results. [16:21] bac: hey hows that review coming? :) I'm trying to decide if I should merge it in to my current branch or wait for trunk [16:21] * Remove footer from the UI and improve the header design providing more room for the environment. [16:22] luca__, see five above additional to bundles. taken from charm notes [16:22] hatch: it is going [16:23] gary_poster: brilliant, thanks :) [16:23] bac: oh I figured out why it said we were still in a hangout, because I closed the window with (x) instead of pressing 'hangup' ...odd [16:30] hatch: in your QA instructions you mention "launchpad states". what does that mean? [16:30] there are purple ones which come up along with the pending and starting [16:30] oh...I meant landscape [16:30] sorry :) [16:33] bac: the % that they appear is pretty low, so that's why 100 units was requested...you may want to try more if it's taking too long [16:33] oh, that makes more sense [16:33] :) [16:33] i have a mix of red, yellow, green, and two purples, hatch. [16:34] sweet [16:34] that's what we need [16:34] equal opportunity unit statuses [16:36] hatch: i requested 100 but got 102 [16:36] that's fine [16:36] the simulator also creates and destroys units [16:36] the R/G/Y add up to 102 and the purple are both 50ish [16:37] ok, if that's what you expect [16:37] bac: thanks, had them since I was a kid. Normally not an issue but every once in a while ugh. [16:37] hatch: doh, missed one? Damn I thought I had gotten all those deployer paths and qa'd forever [16:38] oh man now I'm confused [16:38] frankban: do you have that in your branch then? card or anything? [16:38] hatch: confused? [16:39] rick_h_: some context? :-) [16:39] bac: sorry I thought rick_h_ was gary_poster because they are the same colour so his comment didn't make any sense :) [16:39] frankban: the miscalled method from earlier [16:39] in that case /me -> lunch [16:39] frankban: sorry, catching up on back scroll for today. The deploy method name change? [16:39] rick_h_: created a card in urgent [16:40] hatch: heh, gary and arosales were chatting and they were the same color and I thought gary was talking to himself for a minute [16:40] frankban: k, thanks [16:40] rick_h_: np, are you feeling better? [16:40] haha [16:41] frankban: bit, I can see light now :) Not sure how long computer screen will last but wanted to check in. Of course I'm gone and I broke things :P [16:41] never fails [16:42] haha - rick_h_ I'm just wondering how we didn't catch that in qa or testing [16:42] kind of an important piece to have broken and not noticed haha [16:42] hatch: yea, no freaking idea. Was qa'ing it for 3 days straight [16:42] and I also qa'd :) [16:43] guess we need some kind of integration test [16:43] good, you can take the fall for me :) [16:43] crap [16:47] * arosales guesses rick_h_ may have not been referring to me. [16:48] arosales: sorry, only in a drive by way. [16:49] rick_h_, ah. I must need more coffee :-) [16:52] bac: this change fixes the test for me; is it a sane thing to do? http://paste.ubuntu.com/6443708/ [16:55] guihelp: anyone available for a quick review of a charm branch? https://codereview.appspot.com/27560044 thank you [17:05] hatch: care to peek at https://codereview.appspot.com/29120043/ ? short/sweet [17:06] sure [17:07] frankban: looking, will take my time with it atm and if someone else wants it they can feel free [17:07] rick_h_: thanks [17:11] rick_h_: done - qa failed, see review for stacktrace [17:12] hatch: bah, rgr. [17:12] hatch: oh, that's my current branch. [17:12] hatch: so will have to get them up together [17:13] hatch: qa in a live env and it should work [17:13] blarg [17:13] ok give me 30 [17:14] hatch: lxc should be ok [17:15] yeah the gui takes forever to pull down from lp though I've found [17:15] it's running now [17:15] will report back [17:35] jujugui...will report tomorrow on call. Summary: it's *even bigger* and we didn't have a chance to even begin talking about planning and resourcing. [17:35] impressive [17:36] ._. [17:37] * hatch cheers [17:37] Also, everyone but hatch is being moved off to other teams. Good luck, hatch. [17:37] by default that makes me team lead [17:37] sweet! [17:38] :-) [17:39] * hatch sets up a mirror so he has someone to talk to on his new team of two [17:40] new employee may need to be canned, he is duplicating ALL the work I do :/ [17:40] Start all your own hangouts and make sure you go around at the end :) [17:40] Hahaha [17:40] lol [17:40] heh [17:41] rick_h_: qa ok on real env [17:44] hatch: rgr, thanks. [17:50] gary_poster: do we have any direction as to where we may want to put the StatusData information on the unit view? Right now the StatusInfo is in the header with the IP, Status, etc but the StatusData could be a few lines worth... [17:50] I can come up with something [17:50] but I can't find anything on any mockups [17:50] hatch, we had tabs on the unit view [17:50] I'd make a tab [17:50] If that makes sense for this kind of data? [17:51] well this data is only valuable on an error [17:51] else it's pretty much empty [17:51] mm [17:51] so I was thinking that it would just show in that case [17:51] so there would be a few extra lines [17:51] that could possibly be a first-cut as well [17:51] yeah, put it in header when it exists, and if that doesn't look good enough we can worry about it later. [17:51] good? [17:52] yep sounds like a plan [17:52] cool. [17:52] * gary_poster lunches [18:08] bac: if you get a chance can you review my branch: https://codereview.appspot.com/29210043 It includes a fix for the test failure I'm getting on trunk. [18:08] benji: sure [18:10] benji: did you find out why it wasn't seen elsewhere? [18:10] bac: no idea [18:13] benji: does justOne=True do what i'd expect? if so, is that what you want since you're removing all revisions? [18:13] remove.py line 65 [18:14] * benji looks [18:14] er, remove_charm.py [18:18] bac: I know why that's there (it is flotsom from an earlier version) but I don't know why it still removes them all. I'll take that argument out, nonetheless [18:26] benji: did you add ~ to BAD_CHARS to fix the odd test failure or did it cause it? [18:26] bac: yep [18:26] which? [18:26] bac: heh, I added it to fix it [18:26] bac: if I add this http://paste.ubuntu.com/6443708/ to trunk it fixes the failure on trunk for me [18:26] gah, it seems to me it would break the test [18:27] i'm really confused [18:27] the ~ will now be stripped from the search 'fo~o' so it should return results [18:27] making the test fail [18:35] I have no idea. [18:37] bac: oh, it replaces the tilda with a space, making the search string "fo o" [18:38] i think i went to school with a girl named tilda [18:39] benji: do i need to qa this or have you beaten it up well? [18:39] bac: a QA from a dispassionate observer would be appreciated [18:40] bac: but just the search bit, the deleting bit is solid [18:41] huh my mongo process has gone all wonky. rebooting vm. [18:45] hey benji what port is mongo running on your machine? ps will tell you [18:46] bac: ps no tell me, netstat say 28017 and 27017 [18:47] benji: odd, mine is on 37017 and i get failures b/c pymongo looks for it on 27017 [18:47] not sure how this has happened [19:05] benji: i cannot get mongodb to launch on my system. you may want to get someone else to do your qa [19:06] rick_h_: do you have time to QA a branch real quick; specifically to make sure I haven't broken searching with this branch: https://code.launchpad.net/~benji/charmworld/remove-charm/+merge/195839 [19:08] benji: Sure thing, I'll take a look. Give me a couple of min. [19:11] rick_h_: thanks, I'll grab a bite while you do that [19:34] benji: ping me when you return [19:34] bac: I have returned [19:36] benji: would you have time for a quick chat to help me diagnose wth happened to my mongo? [19:36] bac: sure [19:36] your hangout or mine? [19:45] benji: qa notes? a basic search works I guess. Am I to qa removing a charm then? make sure it doesn't come back? [19:47] rick_h_: just search itself, i.e., search works just as in production, in particular I'm concerned with this change from that branch http://paste.ubuntu.com/6443708/ [19:48] so ~ is a bad char so I should test a ~XXX search then [19:48] benji: so ~charmers search gets me a "Search string not parseable" error [19:49] benji: charmers works fine [19:49] oh wait, heh this is trunk still, was resetting the db and such in there [19:49] sec [19:50] benji: ok, so ~charmers search does work vs the old error message [19:50] benji: it's just the same as charmers then, same count/etc [19:51] rick_h_: ok, sounds like it's at least not worse [19:52] benji: rgr, just ignores the ~ [19:53] rick_h_: thanks for the QA [19:53] benji: so qa'ing the removal then? [19:53] rick_h_: you can if you feel froggy, but I feel good about that bit [19:54] benji: k, how do we not re-ingest it next time? [19:55] benji: should this be storing a blacklist then to mark on ingest? [19:55] or is that follow up/etc [19:56] rick_h_: I think the follow-up will be making a script for the charm store that does the same thing [19:56] benji: and do we re-run setup.py to pick up the new entry point on a production upgrade? Would be the other ? as far as making this work ootb for IS [19:57] benji: rgr, so then it needs to track the backlist, or document the order "Remove the LP branch, remove the juju core store record, remove the charmworld record" [19:57] benji: wonder if we can get that removal script in the core store to be an api callable that this script can hit at the same time [20:01] benji: anyway, qa ok'd the search issues. [20:01] rick_h_: thanks! [20:07] benji: do you have both /etc/init/mongodb and /etc/init.d/mongodb? [20:08] bac: only /etc/init.d/mongodb, not the other [20:08] huh [20:08] i shall remove it and reboot [20:08] no upstart script? [20:08] bac: ooh, I wonder if there is some sort of "shadowing" going on there [20:09] yeah. the one in /etc/init.d is owned by mongo-server. the other has no package owner [20:09] I've only got /etc/init/mongodb.conf [20:09] and then init.d/mongodb is mongodb -> /lib/init/upstart-job [20:10] rick_h_: saucy? [20:11] (such an odd question out of context) [20:11] bac: no, this is my lxc, probably precise. /me dbl checks [20:11] bac: oh raring in my lxc [20:15] Makyo: ever since you told me why the Ubuntu font is so hard to read, I notice that 'line' everywhere [20:15] I'm starting to think ignorance is bliss [20:16] Never, ever, ever live with a graphic designer. [20:16] Ignorance is bliss in SO MANY THINGS. [20:16] lol [20:17] There's a font, Papyrus, that used to bug me just because it was overused until my roommate explained the exact ways in which it was problematic, and now it infuriates me. [20:21] haha [20:25] weeee http://fromanegg.com/post/67488243238/a-juju-charm-designed-to-fail [20:25] the GUI is so awesome I just include pictures of it now to make the blog posts look better [20:38] gary_poster: blog posts made and email sent for the fail charm just fyi [20:40] I guess I wasn't a member when I sent the message though so it's awaiting approval [20:41] fwereade: still here around? [20:42] benji, rick_h_: i uninstalled mongodb-server, removed the init files by hand that it left around, reinstalled the mongodb metapackage. upon boot it wasn't running but now i can start it with '/etc/init.d/mongodb start' and it'll run. very weird. [20:42] * bac walk [20:48] awesome thank you hatch! Looks very good [20:50] thanks [20:59] hatch: http://discourse.ubuntu.com/t/failtester-a-juju-charm-designed-to-fail-test-tool/1223 [20:59] :) thanks I forgot about this one [20:59] :-) it's a novelty atm [21:40] I'm pretty sure unit.handlebars is not used anywhere, can anyone else verify? [21:40] I'd like someone else's confirmation before I go deleting it :) [21:44] gary_poster, did the gui drop showing testing status for charms? [21:44] arosales, not intentionally. looking [21:45] arosales: no, it's on https://jujucharms.com/fullscreen/search/precise/jenkins-8/?text=jenkins on the left side [21:45] under providers, but it's been talked about a lot [21:45] arosales: maybe looking at a non-promulgated charm? [21:45] I wasn't finding it for mysql [21:45] I think only the promulgated ones load test data? /me doesn't recall specifics off the top of his head [21:46] arosales, I confirm what rick_h_ says [21:46] I see jenkins, but it was missing for mysql [21:46] * arosales reloading . . . [21:46] arosales: hmm, check with testing upstream? If we don't have the data we don't show it [21:46] arosales, agreed, not there for mysql [21:48] arosales: moved to cloud-dev [21:50] rick_h_, I am pinging marco in #juju [21:51] rick_h_, gary_poster thanks. Seems this is a result of charm testing not giving you the correct info [21:51] we'll investigate [21:51] thanks arosales [21:51] arosales: rgr, I'm out for now, but will keep an eye out ofr updates. Please file a bug on charmworld if we need to adjust things [21:51] rick_h_, ok I think it is with our charm testing atm