=== _mup__ is now known as _mup_ [13:45] gary_poster: ping [13:46] marcoceppi: pong [13:46] gary_poster: hey, we're sprinting and using maas + juju + gui [13:46] gary_poster: when deploying a simple mysql + mediawiki bundle relations aren't being created [13:46] repeated on multiple pieces of hardware for multiple bundles for multiple deployments [13:46] what do you need from me for debugging [13:47] and works on ec2 I assume [13:47] not tested against ec2 [13:47] just against various heaps of hardware, but the physical add-relation command works from the gui and juju [13:47] on juju 1.17.0 [13:48] k, thank you. frankban: can you direct marcoceppi to the bundle deploy log in the charm? (marcoceppi, looking for docs if he's not around) [13:48] using the bundle the relations are added by the deployer and not the gui. We'd have to trace/look at the websocket log [13:48] we have good logs on charm [13:48] heh or that sounds even better [13:49] gary_poster, marcoceppi: gui server logs can be found in /var/log/upstart/guiserver.log [13:50] logs to send: /var/lib/juju/units/[NAME OF UNIT] /var/log/upstart/guiserver.log [13:50] thanks frankban, and HACKING doc was perfect :-) [13:50] marcoceppi: also, if you are curious https:///gui-server-info might be interesting [13:51] gary_poster: yes: https://bazaar.launchpad.net/~juju-gui/charms/precise/juju-gui/trunk/view/head:/HACKING.md#L222 [13:51] marcoceppi: ^^^ [13:51] frankban: is it worth mentioning builtin-server-logging=debug also? [13:52] gary_poster: it is already mentioned in the HACKING file [13:52] line 233 [13:52] frankban: I know, that's where I was stealing it. I meant do you think it would help to ask marco to change that config for our debugging [13:53] gary_poster: frankban http://paste.ubuntu.com/6832109/ [13:54] nothing really interesting in guiserver.log [13:54] gary_poster: oic. it is useful to inspect the Websocket requests/response from the GUI to the guiserver [13:55] marcoceppi, gary_poster: lines 154-157 seem interesting [13:56] frankban: +1 seems Juju didn't like something in the data [13:56] OH I KNOW THIS BUG [13:56] marcoceppi: have the bundle file up? does it have any constraints in it? [13:56] we need 1.17.1 [13:56] it's the statewatcher bug [13:56] marcoceppi, gary_poster: line 158 also means you should see an error notification in the GUI [13:56] in 1.17.1 for jujuclinet/deployer [13:56] Interesting in a MY GOSH COULD WE PLEASE HAVE SOME DECENT INFO FROM THE DEPLOYER TO LOG ;-) [13:56] :-) [13:58] I thought we patched things to not send an "EnvError" like that? Didn't bac add that? [13:58] marcoceppi: yes I remember Kapil mentioned the watcher unexpectedly closed bug [13:59] rick_h_: 'Error': u'state watcher was stopped' looks like a good message to me [13:59] yeah that's the improved version, IIRC, rick_h_. we used to send a stringified json thing as the message, Now we send 'state watcher was stopped' [13:59] frankban: oh, duh. that's the 'type' [13:59] * rick_h_ hits more coffee [13:59] :-) [14:00] yay for logs go frankban [14:00] :-) [14:00] :-) [14:15] jujugui have to run up to the kids day care for a few min. afk. [14:15] ack [14:15] frankban, thats resolved [14:15] frankban, in trunk [14:15] marcoceppi: ^^^ [14:15] thanks hazmat [14:16] frankban, the py jujuclient isn't async, so if it was used for a little while, it wouldnt be able to process pings, rogpeppe2 yanked ping timeouts on the server. [14:16] frankban: how do I get trunk? [14:16] marcoceppi, go get launchpad.net/juju-core ? [14:16] -u -v [14:16] hazmat: oh, I know that, I thought he meant trunk of juju-gui [14:16] we're started compiling [14:17] cool [14:17] frankban, speaking of interesting info to log, any progress on feedback/validation errors branch? [14:17] marcoceppi: I don't *think* you want trunk of gui? [14:18] frankban, i'd like to push a new deployer release before friday, if not it can make the release after. [14:18] lots of goodies got merged last week [14:18] hazmat: working on the server side putcharm API now, improving feedback is likely to be my next card [14:19] I was confusing what frankban was suggesting [14:19] frankban, fwiw, i pushed a new jujuclient with those apis [14:19] hazmat: looking [14:21] hazmat: ic, add_local_charm right? seems great [14:21] yup, that's the one [14:21] frankban, the size param is required btw [14:21] for file objects [14:21] there's some broken code in stdlib httplib that looks like it would handle file objects, but doesn't correctly [14:22] hazmat: in our case, that request is generated by the GUI (javascript+xhr) and the server goal is to just act as a proxy to the real endpoint [14:23] understood [14:24] hey frankban and hazmat [14:24] can we talk about that bug where the deployer bails if a unit doesn't come up properly? [14:25] jcastro, sure... its actually intended behavior.. but i can see where that wouldn't be ideal for the gui. [14:25] really? [14:25] * jcastro is confused [14:25] so if a unit doesn't come up it's supposed to error out? [14:26] jcastro, well deployer's original use case was automated testing and hacking on ostack charms, if it didn't come up right, it was a fail... there's options on deployer to try and auto-resolve errors as well, per some lscape use cases around ha stack [14:26] oh I see! [14:26] jcastro, yeah [14:27] jcastro, but for the gui, that doesn't feel like its really appropriate [14:27] the bundle use case for bundler would be something like "19 out of 22 instances have come up" and the relationships and bundle would be deployed, but you'd have to manually resolve the issues [14:27] frankban, gary_poster, ^ any comment? [14:27] jcastro, agreed [14:27] I think it's more for "bundles" than just the gui [14:27] hazmat, jcastro : I'd suggest a deployer option to switch behavior, I don't remember how difficult it is [14:27] +1 [14:27] frankban, should be straightforward.. its a short-circuit to wait_for_units [14:28] I wonder if default should be behavior jcastro describes [14:28] if it's deploying a bundle do it the resilient way, and maybe if not doing a bundle it reverts to "test mode" [14:28] gary_poster, for gui, i think so. for cli.. a switch [14:28] non default switch that is [14:28] jcastro, there isn't a deployer distinction to bundle vs not bundle [14:28] yeah as long as the default is what the users want, which IMO would be "get the thing up and running" [14:29] hazmat: for cli, simply because of history [14:29] hazmat: that would be great, considering that the importer is instantiated with the defaults by the gui server [14:29] for everyone else --bundle-test-bail-out or whatever [14:29] jcastro, would you mind filing a bug? [14:29] yeah there's a bug, I can't find it right now, digging [14:29] hazmat: I think the "continue on error" case would be preferred for users, where "stop on error" should be opt in for devs [14:30] if we are moving the tool to be more user centric [14:30] but if the vision is for deployer to continue to be dev focused then I agree [14:30] gary_poster, well.. not entirely.. ops wants stop on error to [14:31] and qa as well [14:32] jcastro, not seeing the bug flipping through the open list [14:32] Well if I am deploying an HA bundle and some units don't come up but the service gets up, then I am up and running and just manually fire up more nodes [14:33] instead of being dead stop [14:33] hazmat: huh, ok [14:33] yeah, I am seeing jcastro's position, but [14:34] hazmat, so for example, the mongodb charm has a race (which yes, should be fixed) [14:34] rick_h_: I'm having a problem with a test, do you see any reason this assertion would fail? http://paste.ubuntu.com/6832325/ [14:34] but the entire bundle is undeployable because out of 13 upcoming units, one will bail [14:35] https://bugs.launchpad.net/charms/+source/juju-gui/+bug/1252301 [14:35] <_mup_> Bug #1252301: guiserver reports second bundle as failing after the first fails [14:35] here's the bug [14:36] rick_h_: the error is: AssertionError: expected null to equal 'sidebar' [14:36] benji: looking [14:37] hazmat, my other POV is that instances are disposable entities that may or may not come up depending on the provider so deployer should plan for failure [14:37] for example if a unit goes away juju won't die, it'll just fire up another one and relate it [14:38] frankban: mm, I added deployer as "also affects" to jorge's bug. was that right? [14:38] I did that yesterday but I might not have gui bug powers [14:40] gary_poster: it seems right to me. hazmat: IIUC that bug describes a side effect of what we are discussing: IIRC if a pre-existing unit is in an error state, wait_for_unit raises an error [14:40] benji: would have to find the code that app uses on fire [14:41] rick_h_: will you unpack that a bit? I don't quite understand. [14:41] benji: you're firing an even on app, which must be caught and then triggers a change event on subapp? the viewNavigate is getting no viewmode in the change object [14:41] benji: hangout? [14:41] rick_h_: sure; how about the daily hangout? [14:41] benji: rgr [14:44] frankban, quickstart -i is a thing of beauty by the way [14:45] jcastro: great! :-) [14:56] I wonder why my +1's on G+ never show up on the posts [14:57] hatch: it was an unworthy +1, Google has said so [14:58] haha, it's happened quite a bit in the past week or so, I get the notification that people have +1'd a post but then the post doesn't show it [14:59] 'eventually consistant' [14:59] tooth paste, coffee, oranges.....flavours that do not mix well [15:08] frankban, yeah. the wait_for_units should ideally be self-contained at least to services being deployed. [15:29] hazmat, is that bug sufficient or do you need anything else from me? [15:36] jcastro, its not quite the same, but i'll add a note [15:44] jcsackett: do you plan a deploy of your charmworld change to production? [15:46] bac: we're actually only interested in triggering tests for charms from staging right now, b/c charm testing has been completely sorted out and we can tweak things on staging easily. [15:46] jcsackett: perfect [15:46] bac: as long as charm_testing_* variables aren't set in the charm config, testing shouldn't be triggered on production at all. [15:47] once everything is locked down we'll turn it off on staging and file an RT to have those config vals set on prod. [15:50] jujugui call in 10 [15:50] sigh; I really wanted this done by the call [15:50] benji: no luck? [15:51] rick_h_: well, I did something that is not entirely evil, but I'd rather it have been simpler [15:51] now I just need a couple more tests and it should be reviewable [15:53] hatch: the hard part will be all the manual work to turn viewlets into views :P [15:53] curses, he ran away on me! [15:56] "did you turn it off and back on again" [15:56] looks like osx has the same issue resolution that windows xp has [15:57] * gary_poster has to switch computers [15:59] Oops, jujugui call in 1 [16:01] bac: stand up please [16:01] hatch: the hard part will be all the manual work to turn viewlets into views :P [16:01] jujugui: I am getting "You're not allowed to join this video call." [16:03] rick_h_ oh no that should be pretty mechanical [16:03] with some changes to the viewlet manager it can even be done in stages [16:09] rick_h_ lemme find that plugin example [16:10] gary_poster, want that I should be on that call? [16:10] (I see the invite, just missed the discussion around it) [16:10] hatch: yea, I mean I found people asking a bunch of questions and the usualy answer is the global before/after calls but nothning that could hoook/load into it [16:15] rick_h_ I think I was going to monkey patch the methods which call the before/after calls to allow middleware to be injected [16:16] I'm just looking at istanbul [16:16] it integrates with mocha, just want to see how they do it [16:20] hatch: rgr, ok. Yea that's my plan as well [16:20] and I'm looking at beforeEach/afterEach actually [16:22] why is everything they do documented so poorly lol [16:22] hatch: yea, I didn't come away from this search liking mocha any more than before tbh [16:22] you got my hopes up with a plugin architecture [16:22] there is a setup() method, but no documentation on what params it actually takes :/ === rogpeppe2 is now known as rogpeppe [16:24] hmm mocha actually works pretty interesting under the hood [16:25] rick_h_ ok here is probably the best place to inject https://github.com/visionmedia/mocha/blob/master/lib/suite.js [16:25] that modifies the actual test suite [16:26] it's where it defines the before/after etc methods [16:26] hatch: rgr [17:16] frankban have some time in a couple minutes to give me a run through of quickstart? [17:16] gary_poster, frankban: how does that discussion on the auth call affect the current quickstart effort? are the .jenv files not going to be named based on the local env name? [17:17] bac, they will continue to be named based on the local env name AIUI [17:18] gary_poster: ok, so quickstart has that info but the charm does not. that's the difficulty, correct? [17:18] bac, right [17:18] gary_poster: i feared they were tending to making the jenv files opaquely named [17:18] not aiui [17:18] gotcha [17:20] hatch: sure, ready when you want [17:24] frankban https://plus.google.com/hangouts/_/76cpiisbms6bilnp0eh9n94nuc?hl=en [17:32] rick_h_: I'm going to take lunch now; would you be able to pair with me some time after lunch on these tests? There are no tests for some of the code I am changing and building up enough state to get a simple test to run is killing me. [17:35] benji I wouldn't do what you're trying to do [17:36] I would implement a unit test for either side then a selenium test for the integration test [17:36] (assuming you're doing the minimize-charm-browser-when-inspector-charm-details-opens work) [17:36] hatch: that's what I'm trying to do. I want to call a function and test that it fires an event. [17:36] the function in question is not called in the test suite [17:37] hmm ok, well when you get back from lunch if rick_h_ isn't available I can also give you a hand with it [17:38] thanks [17:39] I may end up liking python after doing this quickstart work [17:39] shhh don't tell rick_h_ [17:40] heh [17:42] benji: sure thing [17:42] hatch: :P [17:43] haha [18:12] guihelp I need two reviews + QA for https://codereview.appspot.com/57820043 . Anyone available? Thank you! [18:12] it's the server side putcharm [18:13] New modem \o/ [18:17] frankban, out of curiosity what do you like tornado? [18:17] er.. s/what/how [18:20] it's good, a little windy and tough to control, but it clears a nice path [18:20] hazmat: yes I do, it worked pretty well for the charm needs [18:20] hatch, listen: no [18:20] Makyo lol [18:20] OH CMON that was funny [18:20] need to go now, see you! [18:20] frankban, more modern/better than twisted? more explicit than gevent? [18:21] frankban: will review/get reviews for that. ttyl [18:43] rick_h_ and hatch: you can play paper-rock-scissors now to decide who helps me [18:43] haha [18:43] benji sure I'll help [18:43] benji: I got it :) [18:43] got the code pushed up to gh? [18:43] :P [18:43] lol [18:44] benji: standup hangout? [18:44] rick_h_: sure [18:44] ok rick_h_ go ahead I'll cede....this time.... [18:44] hatch: you can come along but beware :P [18:44] I'll show you how the browser is setup to already deal with extra views while we're at it hah! [18:44] well maybe I'll listen in [18:45] haha, I'm actually thinking of a slight refactor to the side bar [18:45] so we would have two different approaches [18:45] think all you want, we'll meet and do battle [18:45] code wars! [18:45] http://i1.kym-cdn.com/photos/images/newsfeed/000/296/322/c6f.gif [18:46] benji: hatch https://plus.google.com/hangouts/_/calendar/Z2FyeS5wb3N0ZXJAY2Fub25pY2FsLmNvbQ.j0rk5d371ph8331ijtf48t2uj0?authuser=1 [18:46] benji lol [18:46] "You're not allowed to join this video call." [18:46] benji: :( [18:46] try again [18:46] ok, I'll create one [18:46] it's been doing that [18:46] or hatch got in [18:47] benji: ah, might be a work vs non-work account thing [18:47] I can create one for non-work accounts [18:47] hatch: benji https://plus.google.com/hangouts/_/76cpjjso2tiuhku81mmnp9md8g?hl=en === _mup__ is now known as _mup_ [19:25] does anyone have any favourite python learning resources? [19:26] I'm mostly interested in the ecosystem [19:27] hatch: hmm, I mean I went through a ton of books and such when learning python to get out of php. I don't know I've got a single/couple favs. [19:27] hatch: but more than happy to help answer any ecosystem questions/etc [19:29] well there is stuff like pip, virtual envs, __whatevers__ [19:29] so less about the syntax of the language and more about how applications are actually structured [19:33] hey arosales, we'd like to get quickstart in main in trusty. Is that possible? Who would you suggest we talk to? [19:34] hatch: yea, there's still some personal preference stuff in there that builds up with experience. There's a couple of books on 'good practices' [19:34] gary_poster, I would start with https://wiki.ubuntu.com/MainInclusionProcess [19:35] and get the bug filled out with the required points listed in the wiki [19:35] ok thank you arosales. [19:37] gary_poster, after that it is makeing sure the bug has ubuntu core devs subscribed and following up with the core devs if the bug isn't be reviwed in time for feature freeze. [19:37] arosales: do we have a juju and/or ecosystems contact for that in particular? [19:39] gary_poster, not specifically. Best bet is to subscribe ubunt-mir team to the bug so it shows up in the archive admins queue [19:39] ok [20:15] so is there a python api docs somewhere? [20:15] tried here http://docs.python.org/2/library/ [20:15] but it doesn't have the 'call' method for some reason [20:16] oh nm [20:16] I was using the docs wrong [20:16] heh [20:16] carrryon [20:24] brain....wants....to.....type.......'var' [20:25] hatch: lol [20:25] yea, and the ; and the function vs def [20:25] haha it's hard! [20:26] I wish you could indent one more time on def's [20:26] the fn name is hard to scan for [20:26] could maybe be my syntax highlighting though [20:33] rick_h_ which syntax is preferred in the python world? https://gist.github.com/hatched/8675743 [20:33] or does it really matter [20:36] hatch: replied [20:36] bah, lost my formatting [20:37] hatch: there we go [20:37] you guys are really functional eh? :) [20:37] testable :) [20:37] cool I like it better your way [20:38] so then if bootstrap_requires_sudo: cmd.insert(0, 'sudo') [20:38] thanks [20:38] np [20:40] rick_h_: how do you get github to not eat indentation? [20:40] benji: markdown, add 4 spaces first [20:40] ah! [20:40] so it's a code block [20:40] I think you can also do ``` ``` [20:40] maybe that depends on the md type though [20:40] * hatch dislikes that there are dif implementations of md [20:41] rick_h_ (and hatch): https://gist.github.com/hatched/8675743/#comment-995086 [20:41] benji: +1 [20:41] benji: wasn't sure on line length in there [20:41] python and js appear to have very similar operations [20:41] I'd rather have the if block vs dealing with newline in there [20:42] OMG I think it finally works! [20:42] * rick_h_ does a happy dance [20:42] ? [20:42] lol [20:43] hatch: https://github.com/juju/juju-gui/pull/89 [20:44] kewl lookin [20:45] and mocha can go choke on a carrot atm [20:45] pita to get this hacked into play the way they bootstrap everything for you on load so you can't intercept crap [20:47] ohh lol I Was reviewing it [20:47] till I saw the huge commented out section [20:47] haha /me fail [20:47] oh no man, it's WIP. I've got to find every instance of makeContainer and pass a this in as the first argument [20:47] and remove all the cleanup instances [20:47] and figure out how to clean it up with more comments/wtfs [20:48] you should probably land them as separate branches [20:48] or at least separate commits [20:49] definitely commits, but hard to do as different branches [20:49] if I don't remove the cleanup the container won't exist. If I don't update the context argument then the calls will all fail with wrong args [20:50] right [20:50] hmm [20:52] rick_h_ why the addCleanup method? can't they just push to jujuTestCleanup? [20:52] hatch: could, but I like the clean api better. [20:52] hatch: "call this function with a cleanup" and you dont' have to know jujuTestCleanup/etc [20:52] just addCleanup [20:52] frankban: (hoping you see this tomorrow morning): please review the admin-secret change https://codereview.appspot.com/57900043 [20:52] maybe _jujuTestCleanup = {} [20:52] er [20:52] meh, I guess it's nitpicking but I liked it better [20:52] [] [20:53] whichever implementers choice [20:53] defining the function is a perf hit is the only negative [20:53] originall it was _jujuTestCleanup as a hidden var and then realized wtf...no one's going to use _juju... [20:54] haha no the idea behind using _jujuTestCleanup is to signify to other devs that you shouldn't interact with it directly [20:54] :P it's been a long day [20:54] lol [20:55] also you don't need bind() as you have it in your WIP (although I suspect that's not staying anyways) [20:55] bind() returns a function that's bound to the context [20:55] yea, I was hitting some issues there. The scope changes around a bit [20:55] right [20:56] yeah with call() you have it right [20:56] bac, fwiw I think jenv files started in 1.16 (per your MP) [20:56] +1 [20:56] I like it [20:56] I was running into the various bits are in a context of mocha.suite, Hook, etc [20:56] getting it straight is a pita [20:56] yeah, this is pretty much exactly how I was going to do it so yay! lol [20:57] lol, ok well will clean it up and get it going up for review in the morning if I can get my sed/awk fu on to mass update the makeContainer calls [20:57] though I wonder what will happen to makeContainer calls not in the before hook but the test itself :/ [20:58] it should add to the cleanup and clean it up in the after [20:58] hatch: right, but will the context of 'this' have access [20:59] hatch: because the this in there is the Hook object, not the test fun [20:59] ohh...hmm [20:59] hatch: I'll get it worked out. anyway, small happpy dance [20:59] yeah - maybe we can assign a global context object that the utils methods can use [21:01] Makyo or hatch, either of you up for being the second reviewer of frankban's https://codereview.appspot.com/57820043 ? I'm trying to do qa and review [21:01] sure [21:01] ty hatch [21:01] Rushing on tests [21:01] thank you [21:01] gary_poster can you ping me after you're done yours so I can learn from the comments (if any) [21:02] sure hatch.right now I'm flailing at trying to update juju core :-P [21:02] haha, I'm failing at getting mine to stop using the custom built one lol [21:03] :-) [21:03] I borked my path, there needs to be a $PATH api [21:03] so you could splice into it and stuff haha [21:03] array methods on $PATH [21:04] rick_h_: here's my WIP if you have a minute to look and comment or formulate thoughts for a discussion tomarrow about how to split the events up plus anything else you see, I would appreciate it [21:04] benji: rgr [21:14] benji: link? or issue pushing? [21:15] rick_h_ you should just KNOW [21:15] lol [21:16] rick_h_: https://github.com/benji-york/juju-gui/compare/juju:develop...benji-york:auto-open-close?expand=1 [21:16] :) legit checkpoint commits [21:16] I dont' think I've ever seen someone write 'checkpoint' lol [21:26] benji: k, I'm a little confused will look at it. [21:39] rick_h_ it must be that app is a bubble target (somehow) of the topo [21:39] might have to grep for that one [21:53] hatch, that local charm DnD is looking pretty cool :-) [21:53] * gary_poster excited to see it hooked up [21:54] hatch, I completed review of https://codereview.appspot.com/57820043/ . Not the most scintillating review ever :-) [21:54] yeah it's pretty nice, and it looks like core will be fixing the folder in a zip issue too [21:54] haha ok thanks [21:55] I'm guessing @gen.coroutine is part of a lib? [21:55] I didn't think python had real coroutines [21:57] hatch: that's part of tornado I think [21:57] the @gen stuff [21:57] hatch: http://www.tornadoweb.org/en/branch2.4/gen.html [21:57] ahhh [21:58] async is hard :P [22:01] darn it, my pebble isn't in the first orders :( [22:01] the steeeel one? [22:01] Morning [22:02] hey huwshimi [22:02] huwshimi did you want us to prioritize upgrading the node dep? (if possible) are you able to do it? [22:03] hatch: I can give it a go, but I have no idea how to do it. [22:03] huwshimi do you know how to deploy a local charm and all that business? [22:03] hatch: yea, ordered day of annoucement but guess I'm still in a second batch [22:04] rick_h_ that's a good thing - everyone else gets the first broken run [22:04] :) [22:04] hatch: I've done it before (to LXC). [22:04] huwshimi yeah our issues were when it was uploaded to ec2 [22:05] so you pull it down, update the python deploy files, update the package.json, shrinkwrap, then push it up somewhere then deploy from that repo [22:09] hatch: Have you done it before? How long a task might it be? [22:10] huwshimi for you, probably a day, just because of learning the process, testing takes a while to spin up ec2 machines etc [22:11]