[11:35] morning party people [11:35] well, non-holiday'ing people [12:41] jujugui off to take wife to work (her car is kaput) back in a few minutes [12:41] ack [13:00] * rick_h_ is back [13:01] morning all. [13:01] hi jcsackett [13:01] welcome [13:01] woo! and today the team is back to full strength for the first time since Feb. Well, aside from everyone being out this week [13:02] rick_h_: don't you have a fleet of fancy cars? "kaput" seems to happen a lot. [13:02] or does michigan do that to them? [13:02] bac: oh really? the wife's subaru is leaking something. So we're just not driving it until we take it in tomorrow [13:02] rick_h_: i have a subaru. leaking something is its perpetual state. [13:02] they don't really go kaput, but we do take them in for regular maintanece, new tires, winter/summer tire swap [13:03] ah, gotcha. [13:03] so I guess it might seem that way, but actually we're pretty trouble free [13:03] oh her battery died this winter, but that's just fun [13:03] our new-to-us car was kaputting but a new battery this weekend should do the trick [13:03] most expensive cost-to-volume car battery i've ever bought [13:04] rick_h_: you free to chat this AM? about the card i pinged about friday or other things? [13:05] jcsackett: yep, in a few min [13:05] cool. [13:28] hey jcsackett could you look at this charmworld exodus branch when you get a chance? https://codereview.appspot.com/89770044/ [13:29] bac: looking now. [13:30] jcsackett: k, free link me up to a hangout when you're ready [13:30] rick_h_: ok. [13:31] bac: so, i'll actually review right after chatting with rick_h_ [13:31] ok [13:32] rick_h_: link is https://plus.google.com/hangouts/_/76cpjte2d4j5v28msijuvbb2tg?hl=en [13:32] jcsackett: "this party is over" [13:32] i freaking hate google. [13:32] rick_h_: you're on plus now? [13:33] jcsackett: https://plus.google.com/hangouts/_/7ecpi051hcetihavdvas78pick?hl=en [13:53] bac: ok, looking at your branch now. [13:53] bac: did you sort out logging weirdness? [13:54] no, not yet [13:54] i improved it in another branch but we still just pretend to have hiearchical logs [13:55] bac: ok. i saw use of the charm.NAME system and dared to hope you had figured it out. :p [13:55] jcsackett: no, i just perpetuating the fraud [13:56] s/i j/i am j/ [14:09] bac: comments on the diff. [14:10] jcsackett: some fyi https://github.com/juju/juju-gui/blob/develop/HACKING.rst#typical-github-workflow [14:10] jcsackett: and the section under there for helpful aliases/etc [14:11] rick_h_: thanks--i read the workflow bit earlier, i'll check out the aliases. [14:11] jcsackett: cool [14:39] oh my lord. i've somehow made xchat notify me on all messages in any channel. this cannot stand. [14:49] jcsackett: changes made to https://codereview.appspot.com/89770044/ [14:50] jujugui call in 10 [14:50] hey, one minute to go still [14:52] I'm going by my phone alarm, so t-mo says it's time! [14:54] bac: looking. [14:55] bac: LGTM. Thanks! [14:58] jujugui call in 2 [15:11] Today's house: http://www.zillow.com/homedetails/6216-Becker-Ln-Loveland-CO-80538/13881778_zpid/ Excited, but worried about the lack of bathroom pics. [15:12] nice. [15:12] yummy wood floors [15:13] ok, the moon pic is a bit of a sales job [15:15] Totally, haha. [15:15] Ditto the elk. That's across the road [15:16] that kitchen, though. that's awesome. [15:16] kadams54: is this rebased on develop? [15:16] Right? Granite countertops with glass-tile backsplash. [15:17] rick_h_: Yes, rebased on develop as of Friday morning. [15:17] Give me a moment and I'll make sure it's got the absolute latest. [15:17] kadams54: all good, monday readings I confused myself [15:17] Makyo: if you end up w/ that kitchen, ima be jealous. [15:18] I'm already excited. Only problem is going to be brewing, that'll have to be all outside, since that stovetop won't work for it. [15:18] rick_h_: Confirmed: my deployed-unit-tokens is rebased on the latest from develop. [15:19] kadams54: k, feedback done [15:39] jujugui quick mechanical review please https://github.com/juju/juju-gui/pull/247 [15:39] rick_h_: ok [15:40] thanks bac [15:44] rick_h_: done [15:44] rick_h_: that's a boar [15:45] thanks bac, it's too monday to trust my eyeballs [15:45] as in boaring [15:45] oh lol, just seeing the comment [15:54] rick_h_ your flags branch is missing all of the css flag changes [15:57] * rick_h_ goes to look [16:00] :qa [16:00] bah [16:01] see what I mean? [16:02] hatch: yea, there was one that was state. Updated [16:02] the others are all mv and that's the same [16:02] and no ecs related ones I see [16:02] oh right - I spent some time merging the li and state ones before [16:02] thanks for the catch [16:03] so does your branch remove ecs entirely? [16:03] hatch: yes, it's all mv [16:04] hatch: they need each other so making it all part of that work. qa and such should all be done together [16:04] yeah ok cool, just wondering so when I load it up in the future I know what flags to use [16:04] yep, il/mv and by thurs only mv is the plan [16:07] was `state` too long to type? lol [16:07] *weekly iteration of "I hate promises."* [16:07] haha Makyo we still have promises? [16:07] Yep. [16:08] lemme guess.....syntax error without any information as to where the error is occuring? [16:08] occurring [16:09] Close. Env trying to access non-existent property with no indication on where that call to the env is being made. [16:09] hatch: no, il was what I told everyone to use. It was what design is testing as, what they've shared with Mark S during demos, etc [16:10] hatch: so state was just not what was agreed among a bunch of people and made up and made state stuff hidden during qa/testing of other branches of code [16:10] guihelp: quick YUI question: Node.append() seems to only take a single element (string, Node, or HTMLElement); what if you have an array of Nodes (Node[]) that you want to append? [16:11] Makyo ugh that's even worse....YUI will -not- be adding in anything for proper stack traces either unfortunately - they are keeping it exactly to A+ :( [16:11] I thought append would take a nodelist as well as a node? [16:11] kadams54 it'll take a string [16:11] if it's a nodelist then it'll loop over it [16:11] not very performant [16:11] Not a NodeList [16:11] yea, the point is to make it fast [16:11] Though I suppose it could be [16:12] kadams54 can you create a string and append the string? [16:12] Yeah, that was going to be my ugly hack fallback [16:12] kadams54: what about making the

nodes.join('') [16:12] kadams54: and at the end put that UL into the dom [16:12] kadams54: so you're just appending one node to a container in the dom, and building the whole UL programatically outside of the DOM [16:13] Ah yeah, that would work [16:13] just an FYI datatable does everything as string templates unless it's forced not too which gives it like a 75% boost in performance [16:15] *sob* [16:15] kadams54: ? [16:16] It just seems wrong to have this tree API (DOM) but instead fallback to string manipulations [16:16] ah, gotcha [16:16] It makes me sad [16:16] * rick_h_ was worried you hit another issue [16:17] meh, react shows you don't have to go to pure strings for performance. [16:18] * rick_h_ wants YUI widgets on top of a react backend badly [16:18] I can't really comment, I don't know the context of what you're doing [16:19] hatch: generating tokens (Views) to put into a div in a loop [16:19] react works a little differently, if it's calculated diff required it to generate a ton of elements in the DOM its performance would likely also suffer [16:20] ohh, is this regarding generating containers for the token views? [16:20] right, but the point is that the calculations happen outside of in the DOM tree, but in a pure memory tree and thus is fast [16:20] hatch: rgr [16:20] hatch: well, kind of, but that area of the code yet [16:20] oh....well I gave Huw the information to make his branch work properly [16:20] to the 'convention' that is [16:21] https://github.com/juju/juju-gui/pull/233/files#diff-947e688a9f9e23383a48af542be63bbfR142 [16:21] ^ kadams54 [16:21] and then you pass the 'parent' node into the render method as a param [16:22] hatch: but kadams54 and I disagree withthe container being a LI [16:22] so you test that with a container that's not a normal div? That seems broken [16:22] I'm not sure I understand? [16:22] each token isn't a li> [16:23] it is in the use case of the panel, but if that token were reused anywhere else? Or just want to create atest of the token. Why an IL is a specific detail in one use case and we disagee it should be a View's container template. [16:25] https://gist.github.com/hatched/533588638633a831a291 [16:25] The goal is to keep the Token object as stupid as possible [16:25] jujugui, i am routinely having the gui hang at the loading screen. i've got the gui running in an LXC, and accessing via browser on my main machine. any gotchas y'all can think of? [16:25] jcsackett open the network tab [16:25] jcsackett: check the console? [16:25] is it hanging on loading YUI [16:25] ? [16:25] jcsackett: if it's handing at loading it should be dumping something out to you [16:26] hanging that is [16:26] So making the token handle a "containerTemplate" seems like the wrong place for that logic. [16:26] I'd rather the code using the token (MachineViewPanelView in this case) handle that. [16:26] i have no errors in console, and everything is actually pulled down. just sitting at the spinner. [16:27] jcsackett odd.....usually it hangs on loading YUI [16:27] jcsackett maybe `make clean-all && make devel` [16:28] kadams54 I'm skeptical of making it 'too dumb' imho [16:28] now that means that it requires extra setup for testing and whatnot [16:28] especially if there isn't a use case that you can think of where it's container would be different [16:28] hatch: disagree, it just needs to be rendered. Put it in a container div. [16:29] what testing bootstrapping does it add to? [16:29] Yeah, seems like dumber object == less testing bootstrap [16:29] then why supply a container at all? [16:29] just let it create it's own div and be done with it [16:30] I was under the impression that the

was an important element to the view [16:30] hrm. make clean-all etc seems to have fixed it. i am suspicious of my setup now. [16:30] is lxc still a way people work on this? i note vagrant is now documented. [16:30] jcsackett it's ok, it happens [16:30] jcsackett a bunch of use use vagrant [16:30] to the panel and only for css purposes. [16:30] jcsackett: yes, I work in lxc [16:31] cool. [16:31] jcsackett the makefile is kind of like a magic script [16:32] you can't read it [16:32] you just hope it works [16:32] :P [16:32] lol [16:32] because merge-files is so much better :P [16:32] magic that sucks to no end when it breaks. [16:32] oh yeah but I've got that figured out now [16:32] * rick_h_ hates looking up how to debugger into a nodejs script every time that damn file has to be touched [16:32] I know why merge-files breaks [16:32] lol [16:33] OK, heading out for my dr appt [16:33] rick_h_ maybe one of the next week tasks can be to rewrite our makefile in grunt :) [16:34] hatch: heh, I just got 10 people to buy the makefile book after a talk on grunt at pycon because I ranted on how it's just reinventing the wheel poorly [16:34] clearly they haven't seen our makefile.... [16:34] :P [16:35] oh if only other people didn't write things we don't ourselves agree with or follow...oh wait. :P [16:35] grunt, gulp, etc etc etc are 'task runners' [16:35] funny that, Make is a build tool. I don't need tasks run, I need things built [16:35] if I want to go ssh into a box and run a command I'll use juju actions (coming to an environment near you) [16:35] right, but it's impossible to follow at a glance [16:36] hatch: so we have a complicated one, sorry. https://github.com/bookieio/breadability/blob/master/Makefile start there :) [16:37] that's the exact issue....as the complexity increases it becomes less and less manageable [16:37] it's like writing a js app in a single jquery file [16:37] :) [16:38] anyway, refactoring of the makefile is welcome. grunt/etc aren't magic bullets of complexity management either and it's another tool/etc we don't need. Everyone (almost) in the company speaks makefile and it's the standard and we've not hit anything it's not capable of doing. [16:38] education + refactoring > buying into another tool of doom [16:38] I'm not sure it can be refactored to be legible....hope I can be proved wrong :) [16:39] oh....btw my containerTemplate proposal would still allow you to render the view in tests as a div and in the app as a li [16:39] hatch: right, by passing the arg in to override [16:39] hatch: understand [16:40] maybe what you're looking for then is to have the view generate a string which then gets appended outside of the view [16:40] so the view is kind of like a template generator [16:40] oh that won't work [16:40] well, it would [16:40] hatch: yea, I've done it both ways before. Where render returned the html, and where you specify the 'renderTo', and it just renders itself [16:41] but probably wouldn't be worth the extra work [16:41] yeah I've never liked that approach, it's confusing [16:41] better to stick to conventions whenever possible [16:41] exactly, let's get this landed and move forward. We can chat about it at vegas if required. [16:41] but I think the root of it is that kadams54 and I get an icky feeling when a View is anything but a div. [16:42] poor poor back end devs [16:42] :P [16:42] ok, time to get some real work done. [16:43] we should maybe re-evaluate huws branch then [16:43] to align the two [16:43] hatch: +1 [17:04] Makyo as a general rule do you use pointers in Go or assign return values to variables instead? I prefer the latter [17:06] hatch, the latter, I believe, and you can return multiple values, so it's usually retVal, err = fn(params) [17:11] Makyo yeah that's what I prefer too but I've seen the other way in others code and I can't see why they would do it that way [17:11] hatch, just different backgrounds, probably. That's more C/C++ish [17:11] Took a lot of getting used to working with Qt/. [17:11] yeah that's what I was thinking [17:12] I remember doing that back in the C++ days [17:13] jujugui quick review + QA please. One line fix + bunch of lines of test. https://github.com/juju/juju-gui/pull/248 [17:38] hatch: what's viewNavigate now? [17:38] changeState [17:38] hatch: ty [17:39] ah, changeState. my good friend. [17:41] np, yeah, everywhere that fires viewNavigate atm should fire a changeState [17:41] the handler is also in the same place in browser.js [17:45] hatch, do you have a moment to chat, or are you actually taking today off but hanging in the channel? [17:46] jcsackett I'm working on some Go stuff but I can context switch for you :) [17:46] fire me a hangout link [17:47] me too, want to bug hatch as well :) [17:47] * hatch knew he shoud have started his house work already [17:47] so...the section of plus that lets me fire up a hangout isn't loading. [17:47] rick_h_, you want to try? [17:48] jcsackett: yep, inviting [18:26] hatch: do we have anything that tests the dispatching in browser.js for the new state stuff? [18:28] rick_h_ I think the charmbrowser and inspector methods are unit tested but the state instantiation isn't [18:29] hatch: yea, I've added the dispatch stuff to the machine method in the browser.js but not seeing a good place to test it. Will tack it into the existing browser_app tests for the moment. [18:29] it's probably stable enough now that they could be added [18:30] there is a dispatcher describe in the browser.js test file [18:31] ah, describe('state dispatchers', looks like what I want [18:32] tests so need refactoring heh [18:32] yea [18:37] ya know, I'm not convinced the go ecosystem is ready to be a webserver [18:37] I mean, sure it works and all that, but node/python have so many more libs [18:44] jujugui looking for two reviews now please https://github.com/juju/juju-gui/pull/249 and https://github.com/juju/juju-gui/pull/248 [18:45] nothing huge, QA required [18:45] kadams54: make sure to rebase, I had the one landing that changed the flag names this morning [18:45] kadams54: was going to ping but you were afk for a chunk there [18:45] Yeah, will do [18:45] or af-irc [18:49] kadams54: if you get a second before your next branch a couple of reviews ^ appreciated [18:49] Sure [18:49] I'll dig into both [18:49] ty much, hopefully small/quick [18:56] rick_h_: both look good and ready to merge. [18:57] kadams54: ty much sir [18:59] woot! landing 3 branches in one day. Take that management school! [18:59] * rick_h_ stops taking another card because it's meeting time coming, doh! [19:12] jujugui time to split my day. Will be back and have this card proposed later tonight. [19:12] Putting laptop away because contractor's here for a bit longer. Email or phone is best. [19:12] Makyo: rgr, I'll be around post 5:30 your time if you need anything (think you're 3hr behind) [19:13] It's 1:13 now. [19:13] Makyo: ok, 6:30 your time then [19:13] Will be back 5:30 my time if commute goes well. [19:13] Cheers, thanks rick_h_ [19:33] hey rick_h_ i'm looking at bug 1309678 -- i'm not sure why juju-gui even cares about the control-bucket. you have any ideas? [19:33] <_mup_> Bug #1309678: a value is required for the control bucket field === BradCrittenden is now known as bac [19:33] rick_h_: it could be that previously juju would fail if it weren't there but now it generates one [19:34] rick_h_: oops s/juju-gui/juju-quickstart/ above [19:43] does anyone have the gui working in trusty/power? [19:43] http://pastebin.ubuntu.com/7301778/ [19:43] I get this still [19:51] rick_h_, ping [19:58] jcastro: this is the trusty charm? [19:58] jcastro: can you verify that those packages are packaged for power then? Do we have a bad dep? [19:59] no [19:59] but it worked for matt on another machine [19:59] odd, investigating [19:59] jcastro: is there someone that has access to a power machien to test the apt-get command? apt-get install libapt-pkg-dev python-apt python-launchpadlib python-tempita python-yaml [20:01] sec, I am pulling the charm pristine [20:01] jcastro: k [20:02] sorry it's a long pull [20:02] jcastro: np, standing by [20:03] rick_h_, is there a trick for a lightweight checkout? [20:04] jcastro: looking if we have a release of the charm sans history [20:05] rick_h_, can I clone from github directly? [20:05] is that fine? [20:06] jcastro: the charm isn't on github, only the gui itself [20:06] jcastro: the charm includes the gui release tarball in it [20:06] jcastro: so it works 100% offline [20:06] ack [20:06] where's the charm [20:06] lp:juju-gui? [20:06] I need to grab it locally and then tarball it to the machine because it's timing out [20:07] https://code.launchpad.net/~juju-gui-charmers/charms/trusty/juju-gui/trunk [20:10] rick_h_, i've started creating a test suite for service-inspector b/c it doesn't have one at all. is this actually worth while, or do we assume service inspector is safely tested implicitly? [20:11] asking b/c i realize i'm delaying just landing a one line fix for not much added value. [20:11] s/landing/reviewing and landing/ [20:11] jcsackett: huh? it should have some tests. Maybe looking in the wrong place? [20:11] jcsackett: it's a viewlet and part of the viewlet-mananger [20:12] jcsackett: for your issue of hte close button I'd not worry about it atm. As we've said the goal is to remove that all together by thurs [20:12] if you can add it cheaply awesome, otherwise let's deprecate it asap [20:12] rick_h_, it's increasingly obvious that it's not super cheap. i'll get the fix up for review. [20:12] jcsackett: rgr [20:13] rick_h_, also, the viewlet manager test stuff has no actual mention of the service-inspector, as it stands. [20:14] jcsackett: k, I know there's some test gaps (we've got a sprint goal to get a code coverage tool into place) but I know there are some tests. [20:15] rick_h_, like i said, it may well be tested implicitly. and there are lots of tests, so i'll be the first to admit i could've missed them, but ack shows no use of any of the module names, objects, etc anywhere in tests. [20:15] anyway, something for another day. [20:15] jcsackett: k, yea can look around later. [20:15] jcastro: any luck? Want me to build a tarball? [20:15] or zip I guess [20:15] almost ready [20:15] jcastro: k [20:16] rick_h_, deploying now [20:17] * rick_h_ crosses fingers I guess [20:17] agent-state-info: 'hook failed: "install"' again [20:17] k, so question is if it's the same point and if so what's the actual failure in that apt-get command [20:17] yeah [20:17] so the packages are all there on ppc [20:21] rick_h_, I think I found the issue [20:21] jcastro: what can we do to help? [20:22] I think you need to do an apt-get update first [20:22] when I ran it it 404'ed all the debs [20:22] jcastro: ah, ok [20:22] * rick_h_ checks out the code for the charm [20:22] doesn't juju do that when you bring up a new machine? [20:23] no idea [20:23] hey how do I do an apt-get update in python? [20:23] so I can just fix it for the demo? [20:23] sec, looking at the code [20:25] jcastro: I think you can just add [20:25] run('apt-get', 'update') [20:25] before the install in line 36ish [20:31] rick_h_, I can confirm that fixes the issue! [20:32] jcastro: rockit, I've added a card and we'll try to get that updated. [20:32] jcastro: you unblocked for the demo for now then? [20:32] yes [20:32] we need this fixed by EOW btw [20:32] jcastro: ok cool, thanks for calling to get me on it [20:32] jcastro: k, will do. [20:32] jujugui: super short pr, can i get a review? [20:32] https://github.com/juju/juju-gui/pull/250 [20:33] jcsackett: will do [20:33] thanks rick_h_ [20:37] rick_h_, just discovered on a make check i have a test failure. not sure why it didn't show on test-debug, but it answers my earlier testing question. [20:37] updating and pushing in a moment. [20:38] jcsackett: k [20:41] hrm. i'm going to need find a way to get juju-gui email to go to my work email, not my personal. [20:41] there's a trick to it [20:41] can look it up later [20:42] that would be awesome. [20:58] Is there a way to squash/cleanup commits once you've got PR up? [20:58] git rebase -i [20:58] clean up [20:58] git push origin XXX:XXX --force [20:59] Ah. And that doesn't monkey up the PR? Or we just don't care? [20:59] we don't care [20:59] Cool. [20:59] Thanks. [21:12] jcsackett: https://github.com/settings/emails and add the other address [21:13] jcsackett: so I added my canonical address there as an additional and it's picked up from my commits in github [21:14] ok, EOD for now all check you later! [21:16] jujugui: quickstart review at https://codereview.appspot.com/90060043 , though it may make more sense to let frankban look tomorrow [21:38] jcsackett: once you're cool with your branch you have to enter :shipit: into a comment [21:38] jcsackett: and the lander will pick it up [21:38] rick_h_ saw that. [21:39] just waiting for the CI to finish. [21:39] jcsackett: cool [21:40] jcsackett: the windows.flag.state should all be windows.flag.il now as well [21:40] jcsackett: my branch earilier changed them all [21:40] rick_h_, well, guess i'll have another squashed commit and another wait for CI. :p [21:40] :) [21:40] if you're confident about it you can :shipit: before the test run goes [21:40] ah well. at least i got dev stuff sorted today and a minor bug addressed. i'll call it a win. [21:41] landing will run all the same tests, it's just generally good to wait so it doesn't hold up anyone else but you're good [21:41] all good :) [21:41] eh, it's not blocking me and i'm unlikely to do more work today, so we'll see everything go green this time. [21:41] i may not be as patient in the future. :P [21:41] k [21:41] well, more coding. i have lots of emails to sort out--still on all the qa team lists. [21:42] wheeee [22:11] rick_h_: you around? [22:11] or anyone, how do I view the import errors on charmworld? [22:11] marcoceppi: I'm cooking dinner but around. [22:11] marcoceppi: we request a log from webops and look at it :/ [22:12] rick_h_: so, vsm is in charmstore but not in charmworld - promulgated on Friday [22:12] marcoceppi: what are you looking at [22:12] https://manage.jujucharms.com/api/3/charm/precise/vsm [22:12] https://store.juju.ubuntu.com/charm-info?charms=cs:precise/vsm [22:12] marcoceppi: https://store.juju.ubuntu.com/charm-info?charms=cs:precise/vsm ? [22:12] ok, looking [22:14] marcoceppi: k, file a bug please and we'll try to get the logs for it. [22:14] marcoceppi: it proof's but yes it's not in the mjc at all. [22:15] rick_h_: right, I'll open a bug [22:15] marcoceppi: ty [22:17] https://bugs.launchpad.net/charmworld/+bug/1310825 - bug deployed [22:17] <_mup_> Bug #1310825: VSM charm not listed in charmworld [22:18]