[12:57] rick_h_: ping [12:57] frankban: pong [12:58] rick_h_: could you please take a look at my comments on https://codereview.appspot.com/52080044/ ? [12:58] rick_h_: (and thanks for your great QA) [12:58] frankban: looking [12:58] sorry, slow start this morning [12:59] rick_h_: np, just re-proposed [13:02] frankban: sounds good for the most part. I'm a very cli heavy person so I often found the quickstart very chatty overall which I ack is a personal preference kind of thing. [13:03] frankban: I'll try to dupe the one where I created reran quickstart and went to 'use' an environment and it went back through the install ppa, etc process [13:03] and very cool on "f you accidentally removed a [13:03] bootstrapped environment from the envs.yaml file [13:03] you can still destroy it passing its name to [13:03] `juju destroy-environment`. " [13:03] I wasn't aware of that [13:03] rick_h_: heh, I believe we are not exactly the target for quickstart ;-) or at least, it is intended to be used also by others [13:04] frankban: understood...but but but :) [13:04] frankban: on the plus side I asked jcastro and lazypower looked at it as well to try to get some more QA [13:04] and they had nothing but "Awesome!" and "shipit!" to say about it [13:04] rick_h_: awesome, good move! thanks! [13:04] and I was trying to be hyper critical due to 1.0 and such [13:05] rick_h_: could you please run the interactive session again to check UI changes (after pulling the branch)? [13:05] frankban: so let me get my coffee going and I'll try to reproduce the one issue, then update and rerun some QA on the updates. And thanks for those. [13:05] cool [13:05] thank you [13:41] frankban: ok, I can't dupe my thing with the ppa now. I'm not sure how I hit that. I did end up hanging quickstart because my lxc launch errored and quickstart hung with bringing up the gui [13:42] morning [13:42] frankban: not sure if we care or if this is just a corner case http://paste.ubuntu.com/6762128/ [13:42] rick_h_: what's the last message from quickstart? [13:43] frankban: sorry, terminal is cleared when I ctrl-c'd quickstart. It was about 'bringing up juju-gui' [13:43] during the deploy the gui step [13:43] but it seemed to hang [13:44] I'm having some issues in QA as lxc and trusty have some issues atm [13:45] rick_h_: ok, does this happen also in a fresh lxc install? [13:45] rick_h_: I mean trusty + lxc [13:50] frankban: I'm not sure. I've got a few different kinds of errors I'm working around atm [13:51] rick_h_: could you please reproduce the error running quickstart with --debug? [13:51] rick_h_: and paste the output (warning: password is in the debug output)? [13:52] rick_h_: if that error is included in the megawatcher data it could be trivial to avoid quickstart to hang [13:53] frankban: sure thing. Let me try to set it up again [13:53] rick_h_: thanks [13:57] frankban: yea, looks like there is some api stuff. This is a slightly different error. I've so confused my local lxc with all this testing. https://pastebin.canonical.com/103053/ [14:04] rick_h_: I see. So the machine is in an error state. Quickstart only watches the unit. This is not related to this branch, but it maybe should be handled by another branch before 1.0. What do you think? [14:04] frankban: sounds ok to me. Seems like this might get us too many chasing error reports. [14:06] rick_h_: this should not happen, but when it does, quickstart effectively hangs, because the unit will be forever in an "pending" state [14:06] frankban: right, and I've done it in two ways in an admittingly broken ways [14:08] rick_h_: ok, so 1.0 can wait for this to be handled, and it will be my next card. if you agree, I;ll ask you to reproduce the machine error again later, to check quickstart no longer hangs. [14:09] frankban: cool [14:09] I live to fail for you :) [14:09] rick_h_: :-) other comments? [14:10] frankban: going back through the email [14:12] frankban: looks good. the newline from the initial landing UI before the first bullet isn't there, but that's a tiny thing. [14:12] rick_h_: I see it [14:13] rick_h_: I mean, I see the new line here [14:13] rick_h_: before "automatically create and bootstrap a local environment" [14:14] frankban: correct [14:14] oh hmm, maybe terminal differences then [14:15] rick_h_: do you see "new Amazon EC2 environment" below? [14:15] (just to check I correctly pushed all the changes) [14:17] frankban: nvm, ignore me [14:17] I see it [14:17] rick_h_: ok [14:34] oo boy I love bugs that only show up on prod [14:36] wheee [14:36] the nice thing is that with the charm now you can run 'prod' but uncompressed files I think. [14:37] well I can dupe locally so that's nice [14:51] rick_h_ https://codereview.appspot.com/52790043/diff/60001/hooks/utils.py isn't git available already on juju instances? [14:52] hatch: doing reviewer comments atm [14:52] hatch: if so then it should be fine, but not 100% sure [14:52] if you create an lxc container env is it? [14:53] well I was pretty sure that juju used git to keep track of something-or-other [14:53] I didn't realize that at all [14:56] so including it probably doesn't hurt anything either :) [14:56] explicit > implicit says the Python heroes of old [14:58] jujugui so I've got the charm supporting git branch up for rewview with qa instructions and reviewer comments. https://codereview.appspot.com/52790043/ [14:58] any takers? /me looks at hatch [14:58] Python....Python....that's the language they replaced with Ruby right? [14:58] :P [14:58] rick_h_: you need one or two? i'll do one. [14:59] bac: I think I just need one. [14:59] rick_h_: well i'll be glad to unless you want hatch.rb to do it [15:00] if bac can take it that would be awesome, I'm trying to track down a bug in browser.js [15:00] in compressed files [15:00] bac: I appreciate a true developers insight into the review [15:00] lol [15:00] rick_h_: i thought you might [15:01] rick_h_: let me get this proposal written first (warning) [15:01] bac: np, thanks [15:03] ugh consolemanager code can die in a fire [15:08] benji: is your bundle branch likely to be finished today? i'd like to do a release of charmworld this afternoon to avoid the friday disappointment. [15:09] hey rick_h_ [15:10] do you know the tldr on charm store pages? [15:10] like how you guys were going to bust them out to be separate from the gui? [15:10] 'charm store pages'? [15:10] jcastro: tldr is that it's back burnered and possibly part of other things that will solve the problem in different ways [15:10] ok [15:10] from people way high up [15:10] any word on SEO/URL fixes then? [15:10] here's our problem [15:10] no [15:11] we're doing a charm audit, and we can't find our charms [15:11] so, I end up on an out of date github imported page [15:11] understood [15:11] I think it's been thought that the cleaned up pages on manage.jujucharms.com are a 'good enough' stop [15:11] hmm, should I whine to escalate? If we can't find our own charms how are users going to find them [15:12] if that's not true, you can bring it up and such, but there's nothing planned atm [15:12] at least that I'm aware of, I don't know if some other team/etc is thinking or looking into it. [15:12] ok [15:12] I'll bring it up at the cross team [15:13] sounds good [15:13] which I think is today? [15:13] no idea, gary is out until tomorrow so if it's today he won't be there from us [15:13] yeah [15:13] in about an hour and a half [15:13] ok no worries, it's in an hour and 15 [15:13] oh, benji isn't here today is he? [15:13] rick_h_, is URL-niceness part of that work or is that a different thing? [15:13] bac: oh right, he's out until monday [15:14] i guess his work won't land. pfft. [15:14] jcastro: quick call? [15:14] bac: yea, sorry. he chatted with me about handing it off, but since everyone is out we thought it could wait [15:14] sorry to mess up the deploy [15:14] rick_h_, yeah fire it up! [15:14] rick_h_: not messed up. i'll go ahead with my stuff. [15:15] rick_h_: or i can pick up his branch this afternoon. [15:45] rick_h_: when you have time could you review https://codereview.appspot.com/51010046/ ? [15:45] oh man this bug that I'm working on has existed forever [15:45] heh oops [15:45] bac: sure thing [15:50] jujugui call in 10 [15:56] ugh yet another double dispatch bug [15:56] can we just start over? [15:56] lol [15:58] jujugui call in 2 [16:00] hmm apparently hangouts hates me [16:22] hatch: hah, but we managed to keep you connected the whole time [16:22] your interwebs are strange up there in canada [16:23] lol [16:23] I just rebooted my router, running on hotspot now [16:23] hopefully the reboot fixes it [16:51] rick_h_: before I proceed, could you please check that lxc/trusty error using lp:~frankban/juju-quickstart/handle-machine-errors (it's just a prototype). [16:52] frankban: sec, yep [16:52] rick_h_: thanks [16:57] frankban: ever seen ERROR TLS handshake failed: x509: certificate signed by unknown authority ? [16:59] rick_h_ you've been h4z0r3d [17:01] rick_h_: never [17:01] bah, I can't fail the same way twice wheeeee [17:02] lol [17:04] rick_h_: was that handled by quickstart? [17:05] frankban: no, I had this before but got around it somehow [17:05] now I can't seem to get around it [17:05] asking in #juju about it. [17:06] rick_h_: maybe removing the jenv file? [17:08] juju-quickstart: error: machine 1 is in an error state: error: container "rharding-test2-machine-1" is already created [17:08] frankban: ^ [17:08] looks good to me [17:08] rick_h_: great [17:09] thanks [17:18] rick_h_, now that I have seen [17:18] juju leaving containers around [17:18] jcastro: yep [17:18] frankban: is making quickstart watch for stuff like that so it doesn't hang for the user [17:18] but errors out properly [17:18] jcastro hey I have had a request for bundle level configuration options.... say you have a bundle and you want to deploy it in devel/debug/prod modes [17:19] anyone brought anything like that up yet? [17:19] right now you would need 3 bundles [17:19] bundle inheritance? [17:19] bac and benji were getting that working in proof/charmworld [17:19] imho it sounds like it could be doen with 'stacks' [17:20] how were they planning on doing it now? [17:20] ping a configuration server? [17:20] hatch: it works now on staging [17:20] no, but I mean if you create a bundles.yaml with 3 bundles [17:20] and defined a base set of charms/config [17:20] hatch: no, you have three different stanza, each inheriting from a base with mods [17:20] and override it using inheritance [17:21] so you'd have name-debug, name-devel, name-prod bundles [17:21] and pick the one you want to deploy [17:21] hmm I didn't know that was possible [17:21] to have a 'base' dundle [17:21] the bundles.yaml file can contain several bundles in there. Just have to name them differently [17:21] any bundle can inherit from any other in a deployer config file (basket) [17:22] ohh cool, what's the syntax for that? [17:22] rick_h_: is that why it is bundles.yaml and bundle.yaml? [17:22] inherits: other [17:22] bac: I *guess*? [17:22] oh, no idea. I thought it was always bundles.yaml [17:22] when it is bundle.yaml? [17:22] no,never [17:22] hatch, wouldn't you deploy the same bundle to 3 environments? devel/debug/prod? [17:22] i'm just saying that's why that name was picked [17:22] jcastro: but in debug there'd only be one unit, and different config [17:23] oh I see [17:23] jcastro: bug in devel it's scale out, maybe use a cache layer not in debug [17:23] it would be neat to arbritrarily pass along config and units to parts of a bundle [17:23] "deploy this bundle but only one of each" [17:23] right, there's a pre-deployment config story that's on the radar currently [17:23] but it's done on each bundle deploy and not part of the file itself [17:24] so not quite the same use case, but should be handy [17:24] but at the same time, forking/cloning a bundle is cheap [17:24] and they don't contain _too_ much logic [17:24] right, but you'd want them in the same file [17:24] fix a config bug and find all the forks fml [17:24] so like myapp-prod, myapp-dev and -debug isn't too bad [17:24] right [17:24] oh right [17:24] yeah that does sound nice [17:25] bac can you link me to the bundles.yaml file which has this inherit feature? [17:25] sure [17:26] hatch: https://code.launchpad.net/~bac/charms/bundles/complicated/bundle [17:26] bac oh cool thanks I'll pass this on [17:27] man, that is brutal [17:27] lol [17:27] rick_h_: not to be pushy, but are you going to be able to get to my review soonish? [17:27] jcastro: it is a cleaned up version from kapil [17:27] bac: looking at it now [17:27] the "if you can ingest this, then ingest works" bundle [17:27] I did not know about overrides [17:27] bac: yep, in progress [17:27] ty [17:35] bac: feedback in, qa'ing now [17:35] thanks [17:38] bac: qa-ok [17:38] rick_h_: cool. looking at your review now. qa started [17:39] jujugui: in case i forget tomorrow, i will not be able to make the noon meeting. apologies. [17:39] bac: ack, thanks for the heads up [17:39] we have a noon meeting? ;) [17:39] sure we do [17:39] * rick_h_ didn't realize noon meeting and looks at the calendar [17:39] for exactly one of us [17:39] lol [17:39] you're ahead of eastern? [17:39] would you people please get on AST [17:40] for some reason I thought you were in eastern [17:40] hah [17:40] rick_h_: no daylight savings [17:40] bac: ah [17:40] so US/East half teh time [17:40] that's right, we talked about that [17:40] you're just trying to be complicated [17:40] gah, i wish we'd all ditch DST [17:40] +1 [17:41] and the goofballs here are now talking about starting up with DST! geez, one of the best things they do they want to mess up [17:48] oh bisect...you rule [17:48] hatch: hah! awesome! [17:48] unfortunately it was me that caused the bug [17:48] yea, there are days when I go "All this moving to git stuff is paying off." [17:48] so I'm conflicted [17:48] double hah! [17:48] lol [17:49] try to tell me you need to break my feature will you [17:49] I'll shove that crap right back at you :P [17:49] j/k and all that, but glad to see we hopefully don't need to break things [17:49] oh sweet, I didn't CAUSE the problem, I exposed it [17:49] lol [17:49] hah, off the hook [17:49] kinhda [17:49] kinda [17:49] lol yeah kinds [17:50] "I didn't break it, I just proved it was broken" [17:50] haha, in math that would be the time to write a paper [17:50] in code it's time to write a pull request, same diff [17:50] :) [17:53] haha [17:55] rick_h_: our dependencies branch will still be on launchpad, right? [17:56] rick_h_ ok another fix....enable the simulator so the next delta comes in :P [17:56] no? no? lol [17:57] rick_h_: i think deploy.py setup_repository might need some fixing [17:58] bac: yea bzr is still installed [17:58] bac: looking, never seen/used that [17:59] bac: I updated the functional tests and they pass 20-functional [17:59] looking into deploy.py [17:59] but all tests pass currently [17:59] including the ec2 live functional ones [18:02] bac: ok, I've updated the rsync in there to ignore .git as well which is the only thing I can see to fix there. [18:02] rick_h_: my 'make deploy' has been stuck at DEBUG:root:waiting for the unit to be ready [18:02] for a long time. i haven't run this lately. any idea how long it should take? [18:02] pushing a new -cr [18:02] bac: 10min? [18:02] bac: can you juju status and see if something broken? [18:02] eek [18:03] gui is pending but all else looks fine [18:03] bac: ok cool. You can log in and check the unit log if you think there's an issue but it should get to an error if it fails [18:04] so sounds like it just needs more time [18:04] it's been 30 minutes.... [18:05] oh, then check out the unit log please [18:05] ugh test tracebacks that are only on chai.js [18:05] juju ssh juju-gui/0 [18:05] and then tail -f -n 100 /var/log/juju/unit [18:05] bac: ^ [18:05] ok [18:06] hatch: web components! and the font thing seems cool http://blog.chromium.org/2014/01/chrome-33-beta-custom-elements-web.html [18:10] will look in a bit [18:11] rick_h_: can't do that yet. no public address assigned at this point [18:11] bac: you can't ssh to the machine? are you using ec2 or something else? [18:11] local [18:11] you can't ssh until it gets an address [18:12] bac: oh it doesn't work on local I didn't think because it requires sudo [18:12] or can you? /me didn't try I guess [18:12] rick_h_: /home/bac/charms/precise/juju-gui> sudo juju ssh juju-gui/0 [18:12] ERROR unit "juju-gui/0" has no public address [18:12] right, I think quickstart works on local but make deploy doesn't [18:13] rick_h_: i'll restart with ec2 [18:13] bac: thanks, sorry for not specifying. It should work on any of the public clouds hp, ec2, azure [18:13] rick_h_: i'm just frugal. and i thought it'd be faster [18:13] rick_h_: are you sure? IIRC make deploy shoudl work correctly on LXC [18:14] rick_h_: make test/ftest does not [18:14] frankban: I thought I hit an issue and you said it wouldn't work because it required sudo? [18:14] oh, maybe that was the functional tests I'm thinking of [18:14] bah, ok. /me goes to try local lxc then with make deploy [18:14] rick_h_: yes, "make deploy" sould not require to bootstrap the environment, and that's the only operation requiring sudo [18:16] frankban: k, testing local out now [18:16] bac, rick_h_ : when using lxc, you can find info in ~/.juju/local/log (or similar) ssh is often not required [18:17] frankban: ah, I've got trusty issues with local lxc and this [18:17] agent-state-info: '(error: symlink /var/lib/lxc/rharding-local-machine-1/config [18:17] /etc/lxc/auto/rharding-local-machine-1.conf: no such file or directory)' [18:17] rick_h_: trying make deploy on trunk [18:18] agent-state-info: '(error: container "rharding-local-machine-1" is already created)' [18:18] bah, see, issues. /me goes to tear that down manually [18:20] frankban: same thing agent-state-info: '(error: symlink /var/lib/lxc/rharding-local-machine-1/config /etc/lxc/auto/rharding-local-machine-1.conf: no such file or directory)' [18:20] on trunk [18:22] rick_h_: you can try lxc-destroying your containers, and then manually removing juju related stuff in /var/lib/lxc/ [18:22] rick_h_: and in /etc/lxc/auto/ [18:22] frankban: yea, its clean. It's that to write to /var/lib/lxc it needs root perms [18:23] rick_h_: I think that's ok [18:23] I need to try to set the alt path. It's not writing to .juju/local :/ [18:23] because that machine it starts is ending up in /var/lib/lxc I think [18:25] rick_h_, bac: make deploy just worked here with trunk + lxc, and now I need to go, have a nice evening [18:25] frankban: cool, good to know it's just me/trusty [18:25] thanks frankban [18:25] rick_h_: and me [18:25] frankban: will try on my laptop I think to see if my branch is causing bac grief [18:26] bac: worked on trunk? [18:26] cool [18:26] bac: not sure what the 'and me' is to? [18:26] rick_h_: it isn't working for me [18:26] right, ok [18:26] bac: so make deploy on ec2 is or is not working either? [18:27] rick_h_: yes, it has come up on ec2 [18:27] ok cool, I'll test lxc on my laptop with trunk and my branch and see if I can dupe any local issues or not [18:28] rick_h_ https://github.com/hatched/juju-gui/commit/527027fbbda1fb712e62e8b8e795cbee84587700 this fixes the issue, I can't find any issues in qa but looking for input on any potential problems I may have overlooked [18:29] hatch: looking at that how are we sure that doesn't introduce another level of dispatch on 'working' cases? [18:29] hatch: I'd expect it to set/check something before and after navigate to see if it fired or not? [18:30] and if not, then check hash and force a dispatch [18:31] that path is only hit when the user logs in and if there is a hash in the url so it shouldn't get hit during any other case [18:33] onLogin is only triggered once per visit to the site pinky swear? [18:34] it's triggered when the env fires a login event [18:34] this.env.after('login', this.onLogin, this); [18:34] so it should only happen once :) [18:34] ummm, ok then. if you say so [18:34] * rick_h_ doesn't trust anything happening only when it's supposed to [18:35] haha, I'm going to try it on lxc right away [18:35] did you push your charm update up? [18:35] the pull-from-git one [18:36] yea, it's pushed. lp:~rharding/charms/precise/juju-gui/git-ify [18:36] bah, my laptop has juju .07 [18:36] wow that's an old one [18:37] yep [18:37] go raring go [18:43] :/ my juju env is corrupted or something [18:44] hah! at least I'm not the only one having issues with it [18:44] RROR destroying environment: remove /etc/lxc/auto/hatch-local-machine-1.conf: no such file or directory [18:44] but it thinks it's running [18:44] any ideas on how to get around that? [18:44] nope, kill everything. Destroy the environment. Re-bootstrap? [18:45] it is killed [18:45] make sure all the old machines are gone and removed from lxc [18:45] it just thinks it's up [18:45] sudo lxc-ls [18:45] nothing [18:45] no machines [18:45] juju status shows them though [18:46] wipe the .juju/environments/xxxx? [18:46] I'm not sure there [18:47] I'll ask in #juju [18:51] rick_h_: where do i find the hash for 'network-prototype', your second QA step? [18:52] bac: that is the name of a branch [18:52] okey doke [18:52] how do i verify version.js is correct? [18:52] bac: oh right, so to check the version in github go to that branch in the drop dow [18:52] https://github.com/juju/juju-gui/tree/network-prototype [18:52] and click on commits [18:52] to see the list and their hashes [18:52] rick_h_: thanks, i didn't see the drop down [18:53] notice in the upper left next to the "juju-gui/+" is a drop down for branches available [18:53] cool [18:54] bac: so I got make deploy to work with local lxc. It took a bit and I tracked it was running by cat .juju/local/logs/unit..... [18:54] rick_h_: cool [18:57] just plz dont merge network-prototype into develop....it will break the world [18:57] ;) [18:57] hatch: we're not, it's just the qa case of can you set that branch in the charm [18:58] cool [18:58] some guy kept squatting on my username until one of the others in London told me about nickserv's `enforce` option [18:58] now I don't have to ghost anymore [18:58] woot [18:59] I got all excited we had random github forkers [18:59] and then saw they worked for cisco in their user bios [18:59] doh! [18:59] haha, well they aren't RANDOM but they hopefully will be contributing [18:59] crud, no vanguard in #webops [19:00] ugh why can't I `juju deploy lp:~rharding/charms/precise/juju-gui/git-ify` LIKE FOR SERIOUS!!!! [19:00] because it's not in the story, non-trunk branches aren't deployed [19:00]