[00:03] Makyo: I had that shortly after the name changed from ensemble. Before that we just had to drink many beers to make an ensemble. [00:04] bac: If you are around I have some questions about charmworld [00:05] huwshimi: what's up, might be able to offer tip if needed as well. [00:05] rick_h: Just wondering about setup. Did you set up with LXC or local? [00:05] huwshimi: definitely lxc. Needs things like mongo and don't want to always run it [00:08] rick_h: Ah ok. Which instructions should I use for getting that set up then. The hacking doc assumes you're already in an LXC container and I couldn't see anything in https://juju.ubuntu.com/docs/ about getting and LXC container set up.... [00:09] huwshimi: yea, sorry, assumes the lxc is good to go. It's normally just sudo lxc-create -t ubuntu -n charmworld -- -b $your_username [00:09] and then you'll hit needing to install the python-software-properties package to get the add ppa command to work [00:11] rick_h: "lxc-create: failed to execute template 'ubuntu'" [00:11] https://help.ubuntu.com/12.04/serverguide/lxc.html has some helpful [00:12] huwshimi: ls /usr/share/lxc/templates ? [00:13] rick_h: There is a "lxc-ubuntu" in there [00:13] huwshimi: hmm, then should work :/ [00:13] huwshimi: quick google shows https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1166841 ? [00:13] <_mup_> Bug #1166841: lxc-create fails if LANG is not valid [00:15] rick_h: Well, that doesn't look fun... [00:16] huwshimi: heh...so um... [00:17] rick_h: I'll ask other australians if they have the issue... [00:45] rick_h: I think it's working now. Should the LXC creation take ages? [00:45] huwshimi: the first time yes [00:52] rick_h: "juju generate-config -w" is correct for setting up Juju the first time? [00:52] "juju: error: invalid choice: 'generate-config'" [00:53] * rick_h doesn't recall running that [00:53] huwshimi: oh, don't you need the new tools to do that? [00:53] huwshimi: ping in #juju, I've not used that before [00:53] rick_h: I don't know, I'm just trying to follow the docs [00:53] rick_h: It used to be juju init, but that doesn't exist either [00:54] huwshimi: the hacking docs? You shouldn't need a juju config for dev'ing it [00:54] rick_h: Well, I tried without any setup and it complains about not having an AWS key [00:55] huwshimi: you want http://bazaar.launchpad.net/~juju-jitsu/charmworld/trunk/view/head:/docs/hacking.rst#L96 [00:56] huwshimi: in your lxc just create a dir for hte code, bzr branch lp:charmworld && cd charmworld && make sysdeps && make install [00:56] rick_h: Oh, so do the local setup instruction inside the LXC? [00:57] not the hacking with lxc instructions? [00:57] huwshimi: right [00:57] huwshimi: the other ones is more for working with the charm and such [00:57] rick_h: Ah [00:57] huwshimi: you just want to run the code/hack on it locally [00:57] rick_h: yeah [01:11] rick_h: There is a lot of setup to do in the container just to install stuff etc. :( [01:12] huwshimi: feel free to skip, you asked what I thought. I set it up in lxc. [01:12] huwshimi: installing it is the three commands, bzr branch && make sysdeps && makeinstall [01:12] rick_h: It's ok, I'm getting there :) [01:12] rick_h: I remember the pain of having it installed locally in the past. [01:44] rick_h: Seen anything like this? http://paste.ubuntu.com/6012441/ [01:44] looking [01:45] huwshimi: no, do you have either of those bin? /usr/bin/nodejs /usr/bin/node ? [01:47] rick_h: I have /usr/bin/nodejs [01:48] huwshimi: then I'd try to run that command and see if goes through/gives an error [01:48] huwshimi: the issue is that the name of the bin changed at one point and this helps cover it [01:49] rick_h: Well the symlink is created now :) [01:49] (worked fine doing it manually) [01:49] huwshimi: yea, so re-run make sysdeps [01:49] it's safe to re-run [01:49] and see if it bombs again, hopefully not :) [01:50] rick_h: I think it was fine this time [01:51] huwshimi: yay! [01:54] huwshimi: coffee shop is closing in a couple of min and going to be afk. Just heads up, not ignoring you [01:56] rick_h: Sure, thanks. I think I'm getting there now :) [02:42] rick_h: make run failing with "pymongo.errors.ConnectionFailure: could not connect to localhost:27017: [Errno 111] Connection refused" [02:43] huwshimi: sudo service mongodb start ? [02:44] rick_h: "<4>init: mongodb main process (10631) terminated with status 100" [02:45] https://jira.mongodb.org/browse/SERVER-5808 ? [02:46] huwshimi: or http://randsubrosa.blogspot.com/2013/02/mongodb-main-process-terminated-with.html [02:49] rick_h: Wait a second. If I'm creating folders/branching etc. inside the container should those folders be appearing in my regular home directory? [02:49] rick_h: My terminal says: huw@charmworld [02:52] huwshimi: yes, the lxc create with the -b binds your home dir so you get your .vimrc and you can edit the files with an editor on your host system while running in the lxc [02:53] rick_h: Ah I see [02:53] off to bed, best of luck! [02:53] rick_h: OK, thanks for all your help [09:47] Hi guys, just setting up a demo of the juju gui. Does each employee get AWS? [13:14] hi adeuring [13:15] hi bac, i can meanwhile reproduce these errors [13:15] adeuring: oh, excellent [13:15] though not as reliable as i'd like. [13:15] well, in that case, i'd like to land the branch with the tests disabled so i can proceed with my other branch. had it been restricted to me i would not want to disable them in trunk. [13:16] My guess is that ElasticSearch is simply queired too early after some data has been inserted. [13:16] adeuring: can you review the disable branch for me? [13:16] sure [13:19] bac: sorry -- i missed your MP when i read mails this morning... [13:19] r=me [13:19] adeuring: np [13:22] morning [13:25] bac, can you run juju status for staging. I am now locked out. I am getting Invalid SSH key for everything on canonistack [13:26] adeuring, did you ever sort out the SSH error you were getting when you used juju on canonistack? [13:27] sinzui: no, did not take the time to look closer... [13:30] sinzui: yes i will [13:30] adeuring, bac, not only cannot I not use juju to see staging. I bootstrapped a new env and though I can see it via nova, I cannot access via juju [13:31] sinzui: yes, 'status' worked. do you want the output or was it just a test? [13:32] bac, no need. Until I have access again, I think you will be responsible for calling [13:32] juju set charmworld revno=XXX [13:32] for everything tarmac merges [13:33] sinzui: ok, my branch is scheduled to merge soonish. i'll update when that happens [13:33] I don't think my issue is about saucy since adeuring is also affected [13:54] bac, adeuring: I can see staging again after a reboot. [13:55] yay [13:55] sinzui: i'm updating the revno, even though it is a silly branch. just an exercise. [14:29] ugh for positional argument changes [14:38] bac, benji. I just got a staging error that might be a 404 being presented as a 500? [14:38] * sinzui reports bug [14:40] heya rick_h [14:41] are you going to ohio linux? [14:41] jcastro: nope :( [14:41] I had a crazy idea for a juju gui demo [14:41] jcastro: it's the only weekend in Sept I don't have something going on. [14:42] bac, benji: This is the error I saw on staging: https://bugs.launchpad.net/charmworld/+bug/1215473 [14:42] <_mup_> Bug #1215473: Not found bundles cause 500 errors [14:42] rick_h: ok so let me just validate my idea then, and you tell me if it's possible. [14:42] jcastro: sure thing, happy to help [14:42] rick_h: there's no internet there ... [14:42] yep, definately a bug [14:42] is it possible to cache enough stuff on my laptop to run a gui demo, with say .... importing a bundle on a mock environment? [14:43] jcastro: I can set you up with an offline setup of charmworld/gui you can run from lxc containers. It's how we do dev [14:43] jcastro: we'd need to get together some time to walk through it, ingest, etc [14:44] rick_h: I want bang for the buck though, like if it takes you 2 days to prep me then that's not acceptable. [14:44] jcastro: naw, the long part is waiting for ingest to run. [14:44] rick_h: or I can use hotspot is probably better [14:45] jcastro: that might have to sit and spin for a while, but the setup part is pretty ootb. Longest part is setting up lxc containers aside from ingest. [14:45] jcastro: or that if you can keep a connection for sure [14:45] ok I'll investigate connectivity options and get back to you [14:45] sinzui: yeah, i triggered that error and am looking into it [14:45] jcastro: let me know what you want to do. [15:34] jcsackett: did your changes to the view change stuff make it to comingsoon ? [15:34] I'm still seeing the bug in IE :/ [15:40] jcsackett: looked like it was some super stubborn caching [15:41] 'we cache 'cause we care' [15:41] 'we know you said you want to clear the cache, but we know you dont really want to' [15:46] does anyone know of a really awesome backpack for air travel? [15:47] I <3 mine. Got it for just that purpose when I joined. http://www.tombihn.com/backpacks/TB0111.html [15:47] for air travel I recommend the one with the parachute [15:47] small, fits under the air plane seats well, trim [15:47] ooh, good point. Mine fails on that count. :( [15:48] I suppose it depends on what you have in mind [15:51] lots of pockets, easy to get my laptop out at security [15:51] jujugui call in 10 kanban now [15:53] jujugui: anyone else finding that tests aren't completing locally? on trunk, running test-debug, i don't get failures but it quits without giving the usual little "done" summary. [15:53] jcsackett: did you pull in trunk? [15:54] there was a bug with the websocket tests and phantom [15:54] i did this morning, but didn't see anything landed against that. i'll pull again. [15:55] http://www.everki.com/products1/backpacks/flight-checkpoint-friendly-laptop-backpack-fits-up-to-16-detail [15:55] that backpack looks cool [15:55] jcsackett, pull again. [15:55] jcsackett, I think the branch I just landed should fix that. [15:55] hatch, Makyo: \o/ indeed it does [15:55] awesome [15:55] tbh I'm not sure how those websocket tests ever passed [15:56] maybe the failure was sending a false positive? [15:56] hatch: i'm alarmed by our trend of "well, this never should have worked". [15:56] seems to have come up several times of late. :-P [15:56] jcsackett: means we're getting better at finding and fixing them :) [15:57] rick_h: that's a good way to spin it. :-) [15:57] hatch: that backpack is huge [15:57] jcsackett: thanks, I'll be here all week, try the veal [15:58] rick_h: lol it is! [15:58] jujugui call in 2 [15:58] smaller is better when traveling imo [16:16] rick_h: how goes the ghost constraints? [16:17] hatch: good, just sucks that .deploy has positino args so I've got to go through every instance of *.deploy( and check if it's a deploy and add a bunch of 'null', before the callback [16:17] hatch: https://code.launchpad.net/~rharding/juju-gui/deploy-constraints/+merge/181610 is what I've got so far [16:18] still going through things [16:19] rick_h: actually, think i/we conflated remove filter with remove categories...removing the category stuff from non-ac places shouldn't screw anything up, should it? [16:19] jcsackett: nope, the only thing will be to check on UX fallout like a giant empty div that we should remove [16:19] rick_h: right. so i'll do this one and *then* move on to the likely painful process of filters. [16:20] oh lord, i'm going to have to fire up IE again for this...those categories are placed with wonky css rules. [16:20] jcsackett: right [16:20] jcsackett: on both counts [16:20] rick_h: ahh I see - that should almost just take a configuration object or use `arguments` to find the callback [16:20] deploy() that is [16:20] oh well that's probably more work than necessary :) [16:21] hatch: yea, I thought about that, but as it's my first foray into here I'd rather not go rewritting as I go [16:21] hatch: as you say, perfect case for a followup if time permits [16:21] hatch: especially since this is blocking the original goal [16:21] a lot more work than originally thoought [16:22] hatch: yea, pretty much. Moving forward, will get there. [16:35] benji: can we chat for a second about your last branch? [16:35] bac: sure [16:36] bac: guichat is free [16:40] for a limited time [16:40] then it goes up to $9.99/mo [16:44] jcsackett: didn't see the reitveld go through so commented on the LP MP [16:52] rick_h: dig. reitveld is https://codereview.appspot.com/12935046 [16:52] but comment on LP is fine. [16:52] jujugui: can i get one more on https://codereview.appspot.com/12935046 ? [16:52] jcsackett: ah, interesting. Took it a while to load [16:52] jcsackett, on it. [16:52] rick_h: my lbox is full of wonders. [16:52] no kidding [16:52] where wonders == bugs. [16:53] jcsackett: will transpose the feedback then [16:53] rick_h: i agree with your review, but am annoyed by your making me more work. :-P [16:54] jcsackett: sorry, thought I mentioned the overlay-indicator model to go by :( [16:54] jcsackett: but it'll be pretty after :) [16:56] jujugui also looking for two reviews and an IE QA https://codereview.appspot.com/12808048/ [16:56] hatch, on it. [16:56] Will do the IE. [16:56] thanks [16:56] * rick_h runs and hides...someone said IE [16:57] Makyo, there should be no more wako scroll bars - this branch landed that fix as well [16:58] bcsaller: are you going to repropose your branch with the fix to that issue you mentioned yesterday or is that to be done in a followup? [16:58] sinzui: If you have a few minutes today, I would like to enact your plan to kill the bundles in the staging ES and update the staging code [16:59] hatch: thats not a fix, thats additional UI work that can happen down the road, we don't need it for store bundles or import/export, only for complex deployer files with multiple targets, there is a card for it [16:59] bcsaller: got it thanks [17:00] benji, sure. Do you want to talk or just raise a flag to deploy the latest rev [17:00] oh, are we behind again? [17:00] rick_h: did you want to work on the ghost save button after this branch? [17:00] it can't really be done until your current one lands [17:00] hatch: I was going to go back to my in-progress branch with the constraints on the ghost inspector [17:01] sinzui: I think deploying the head to staging will be fine (fine from my recent branch's perspective at least) [17:01] hatch: I'm hoping to put up the current branch that adds constraints to deploy soon. [17:07] rick_h: ahh ok your landing them in 2 stages [17:08] benji, we are still waiting for staging to comeback [17:08] there's no rush [17:08] benji, I usually cannot tell staging is down during a update [17:09] sinzui: in other words we started an upgrade and it is now down for longer than expected? [17:09] yes [17:10] * sinzui visits charmworld/0 [17:10] darn [17:13] hatch: yea, two step process [17:16] benji, es-update failed: https://pastebin.canonical.com/96243/ [17:17] * benji looks [17:17] sinzui: did we delete the bundles from the DB? [17:17] benji, I am going to check for the bogus bundle again. I am certain I deleted it from mongo and es yesterday [17:20] jcsackett: landed right? https://bugs.launchpad.net/juju-gui/+bug/1214058 [17:20] <_mup_> Bug #1214058: Cannot open Browse if sidebar is minimized

[17:23] benji, there is only 1 bundle is es and the owner is abentley as we expect. [17:24] sinzui: I thought we were going to remove all bundles (from ES and mongo) and let them be re-populated [17:24] hatch: yes. [17:25] benji, we can with a migration. Though I can remove bundles from staging, only migrations can remove them from production [17:25] sinzui: oh, I was under the impression that you removed all the bundles from migration yesterday [17:25] benji, if we as webops to remove a bundle, they have to prevent ingest from putting it back [17:25] bac: https://bugs.launchpad.net/juju-gui/+bug/1202409 no longer an issue? I cannot repro [17:25] <_mup_> Bug #1202409: Firefox 22 on OS X shows service blocks with icon misplaced [17:25] jujugui: we have had a release since the charm model was unified, correct? [17:26] in that case I need to write a kill-all-the-bundles migration [17:26] benji, sorry no, I removed the bundle that had no owner, name, or basket [17:26] hatch, I think the icon fix got that. [17:26] jcsackett: not yet I don't think [17:26] ok, I know what I'll be doing after lunch then [17:26] Makyo: that's what I thought, thanks [17:27] benji, I can intervene and get staging running now. [17:27] jujugui review/point out where rick_h is missing things time please. https://codereview.appspot.com/13084045 [17:28] rick_h: yeah, you're right. the cards are all still in releasable. [17:28] sinzui: sounds good; by "intervene" do you mean remove the bundles or fall back to the earlier code? [17:28] rick_h: looking. [17:28] benji, This is what I am going to do: https://docs.google.com/a/canonical.com/document/d/190xKLPpEPSrlVix4D9eX_aTciiKFo12h0u7MpzqI28I/edit#heading=h.clph5b1k1cd5 [17:28] rick_h: a description of what your trying to do beyond TBD would be good, though. :-) [17:28] k [17:28] jcsackett: thanks, I'd like to get backend people to poke at it and find the holes I'm missing [17:28] jcsackett: doh! -edit coming on the way [17:28] well no, I am just going to pass the remove all flags [17:28] rick_h: aaah, yeah. ima leave this alone. [17:29] but still, more than TBD would probably help the backendy folks. [17:29] jcsackett: yea, accident. I forgot I did a WIP to look things over earlier [17:31] jcsackett: rick_h doesn't really know what he's doing, he just starts coding then writes his intent after it's done....kind of a savant like that [17:31] hatch: :P [17:31] hatch: never claim to know wtf I'm doing. I'm just along for the riiiiidddddeeeee! [17:31] lol [17:32] * rick_h flips the 'lboxing' light [17:37] benji, staging is happy again: the db was fixed thusly: [17:37] db.bundles.remove({}, false) [17:37] ^ remove everything found and do not stop at one [17:37] cool, that's what I'll put in my migration [17:38] I am not sure how to translate the DELETE http command to es [17:39] hatch: ok fine, comments added https://codereview.appspot.com/13084045 [17:39] Makyo: also appreciate it if you can take a look and poke giant holes in what's there/missing. ^ [17:39] rick_h, sure. [17:39] rick_h: :P [17:41] benji, I think es can be sorted with [17:41] delete_all(index, BUNDLE) [17:41] ^ delete all document of type bundle [17:45] rick_h: I'll take a review [17:45] hatch: thanks! [17:58] Makyo: so I was looking, the names of the constraints match the names on the pyjuju side so they don't need to be mapped. [17:58] Makyo: and the _handle... method was on the callback side [17:58] Makyo: it looked likt for taking the juju-core response and converting it into the JS code [17:59] Makyo: and so didn't fit with me converting 'before' sending the rpc call out to juju-core [17:59] rick_h, ah, yeah, makes sense. [17:59] It looked good, just missing the data.Params.Constraints or whatever in the go sandbox. [18:00] hatch: on the safety catch, I was hoping to leave it in. Getting a strange "cannot call undefined" or something error on any cases I missed will suck to debug. [18:00] Makyo: k, will look there. Thanks for the catch. [18:00] rick_h, Since that's calling state.deploy(), you may have to translate -back- to the python-style constraints :/ I had to do similar with get charm somewhere around there. [18:01] Makyo: yea, that was what I had mentinoed wanted to chat about. However, we don't do that currently do we? I didn't see us doing that and we support constraints, just not on deploy? [18:01] or maybe I'm missing smoething [18:01] errr something [18:02] Makyo: oh wait, ok state.deploy. I noticed those calls but didn't know what 'state' was and the call sig was different so I ignored it. [18:02] rick_h, Yeah, that should be deploy() in fakebackend.js [18:02] ok cool. So some more poking around to do. [18:03] Looking at it, handleClientServiceSetConstraints() should be doing the mapping, as well. Could be a quick branch down the line, though [18:03] looking [18:05] Makyo: ok, so this is where I'm not sure on things. That method isn't 'called' anywhere I can see. However it's used by some backend something calling back? [18:05] e.g. bzr grep handleClientSetServiceConstraints [18:06] rick_h, It's called by receive() at line ~790 [18:06] ah, gotcha [18:08] Makyo: so if I was looking for a test of this to check how it works/fits together it would be under the different backend sandbox tests? the test_sandbox just seemed to be connection tests. [18:08] rick_h, yeah, test_sandbox_{go,python}.js [18:09] nvm, so this is more about the set_constraints operation [18:10] rick_h, yeah, sorry. [18:13] rick_h: ok np [18:25] Makyo: guichat for a sec please? [18:26] rick_h, sure. [18:31] Makyo: ah, nvm. I missed adding the test into test_sandbox_go like I did in test_sandbox_python. [18:31] wheee lots of files [18:36] rick_h: here is another great perf vid http://www.youtube.com/watch?v=YV1nKLWoARQ [19:05] stepping out for lunch [19:09] Makyo: sorry, one more time please [19:20] ok, so I lied about leaving right at 3, but headnig out now. Thanks for the help today. [19:32] sinzui: i keep going in circles regarding URLs and bundle rev numbers. it's not just me, either, as most of our google docs aren't consistent. that said, for a bundle short_url would you argue to include the revision or not? [19:33] bac: no for short url [19:33] bac: charms don't have one yet [19:33] I think we can solve revs with the SEO and version work later [19:34] sinzui: then i need to support routes for with and without [19:34] which is ok [19:35] bac, I don't think we do today. [19:36] bac, remember that for seo, charmworld must support juju-gui urls, so we can solve the issue later [19:36] sinzui: right now i only have routes that include the rev number [19:37] bac: I wont stop you from implementing it, [19:37] thanks! :) [20:07] benji: have a moment to talk? [20:08] bac: sure, but I left my camera outside (and hangouts will only use my camera mic now) so I'll have to go get it real quick; jujugui? [20:08] benji: 'guichat', please! yes. [20:21] so hows everyones afternoon? [20:32] bac: wait a second, the bundle ID in mongo doesn't have the basket version in it [20:33] benji: does too [20:33] benji: make_bundle_doc calls construct_id with implicit use_revision=True [20:34] bac: darn, you're right [20:35] benji: you know, i *could* just construct an elasticsearch query and it'll point to the latest... [20:35] yep, that might be the best way to do it [21:17] bac, benji: do either of you have time to review https://code.launchpad.net/~sinzui/charmworld/provide-type-from-api-search/+merge/181661 [21:25] bcsaller and/or Makyo: able to do a preimp on removing the inspector flag? [21:25] I can [21:25] hatch, sure. [21:25] cool in guichat [21:31] oh bcsaller I found this, thought you might be interested in it http://blog.trevnorris.com/2013/08/long-live-callbacks.html [21:32] * Makyo whipcracks at hatch, "Get to work, you got a big task ahead of you." [21:34] lol [21:34] Makyo: to that I say http://xkcd.com/303/ [21:38] hatch: there are days where lbox or tests definitely feel that way. [21:38] "lbox propose -cr" ok, time to make coffee and play with the dogs. [21:39] jcsackett: no that's `lbox submit` ;) [21:39] hatch: they both are, for me. [21:39] submit i actually have to pay attention, b/c it wants my password part way through. [21:42] yeah I suppose [21:56] sooo....yeah our featureflag tests are broken.....they can't be .only'd [21:56] we should fix that at some point [21:57] hatch, yeah, that's on the table. [21:57] :) [22:12] Makyo: bcsaller this ones big! https://codereview.appspot.com/12815047/ [22:30] I hit ctrl+enter on a review, like you would in gmail, and tabbed away. Sorry hatch, lgtm. [22:31] thanks :) [23:02] Morning [23:23] rick_h: Have you seen something like this? http://paste.ubuntu.com/6015818/ [23:24] rick_h: I didn't get that yesterday. Seems to be related to bug #1099155 [23:24] <_mup_> Bug #1099155: [raring] No ip assigned to bridge and no routes added for virtual networks

[23:24] huwshimi: no :( [23:30] rick_h: Give up and install locally? [23:41] huwshimi: sorry, dinner and such here. Don't have much to offer [23:41] whatever you want to do [23:49] rick_h: I know, I just don't want to have to build the whole thing again :) [23:50] What a waste of a week