[00:40] lp, put in an offer [00:40] That was most of what I typed. Thanks xchat. [00:46] Makyo: lol [00:46] Makyo: so you put in an offer on the houes you saw? [01:18] jcsackett: recorded myself with that headset. Crazy that noise. Doesn't do it on the air running ubuntu. My other headsets haven't been an issue. [10:57] morning rick_h_: do you have a minute for a quick look at https://codereview.appspot.com/90220043 (charm)? [11:11] frankban: will do [11:11] rick_h_: thanks [11:14] frankban: I've got to take the wife's car into the shop, will be in/out but will be working through it and do qa from there [11:14] rick_h_: ack [11:42] * frankban lunches [12:14] frankban: thanks for the review. i think your idea is good. [12:26] geeze this is why I <3 working from home [12:26] stupid rush hour [12:29] rick_h_: at the subaru dealer all morning? [12:29] bac: yea,verified her car is leaking oil in the driveway. She just had an oil change done so I htink they munged up something [12:30] trying to be the good husband and get it handled for her [12:30] well hopefully it is just a small leak. i've had friends go to jiffy lube and drive away only to get a mile or two before the engine seized since the plug fell out [12:30] yea, I had that happen when I was a kid [12:31] plug fell on the highway in a construction zone [12:31] had to go 4 miles by the time I could pull over [12:31] new engines for me! [12:31] then JL wanted to pay her a pro-rated amount for her dead engine. [12:31] lol [12:31] I only got mine 'rebuilt' but as a college kid I was happy [12:32] oh no, LP hates me [12:32] error: Failed to load data for member "bac": Get https://api.launchpad.net/devel/~bac: EOF [12:32] oops [12:32] you've been cut off [12:33] frankban: i've proposed changes back to error: Failed to load data for member "bac": Get https://api.launchpad.net/devel/~bac: EOF [12:33] let's try that again [12:33] frankban: i've proposed changes back to https://codereview.appspot.com/90060043 [12:34] i kept the change s/get_admin_secret/get_value_from_jenv/ as it is more generic and may be useful in the future. but it may be YAGNI. let's discuss. [12:35] rick_h_: the deploy of the migration to staging on prodstack failed yesterday. i had to run a full ingest on my laptop last night so i can try to reproduce the problem [12:35] bac: :( [12:36] bac: good to know thanks. Yay for staging doing its job I guess [12:36] bac: there was an ingestion issue yesterday as well. I filed a bug on there [12:36] yeah, but having the other we control would've been nicer [12:36] bac: cool, taking a look [12:36] bac: I tried to look into it but something in charmworld hates that charm. [12:36] rick_h_: is it on the board? [12:36] bac: yes, the vsm charm [12:36] cool [12:36] rick_h_: thanks for the review, I already created a card to update docs while making a release, my next thing after this branch lands [12:37] frankban: awesome, thanks. I need to rename my code reviews to "rick thinks out louad" :) [12:37] :-) [12:38] bah, can't type on this air [12:49] guihelp: charmworld shows that Last ingest job "finished at 2014-04-18 17:34:37Z". [12:50] frankban: oh hmm, well that may be the ticket. Oh, and the queues are where I saw them yesterday [12:51] frankban: looking [12:51] lol, I just saw the queues and missed the numbers didn't change [12:52] frankban: does this not need a functional test run? [12:53] rick_h_: I run the suite, and I'll run it again for the release, so it's not required now [12:53] frankban: rgr [12:55] frankban: LGTM then, after the release please ping jcastro so he knows his fix is out. [12:55] rick_h_: sure, thanks [13:07] luca: morning [13:07] morning all. [13:07] bac: your branch LGTM [13:07] frankban: thanks [13:08] jcsackett: party [13:08] jujugui: heads up email to peeps re: charm development environment [13:08] frankban: ty much kind sir [13:09] morning rick_h_ [13:09] luca: hey, any chance of bumping up our catchup? [13:09] luca: or are you guys busy? :) [13:09] rick_h_: you want to have it sooner than later? [13:10] luca: yep [13:10] rick_h_: I can do it in 10 mins if thats ok [13:10] luca: sounds good thanks! [13:11] rick_h_: no worries [13:11] rick_h_, given the MV priority, should i be looking at that stack of cards for today's work? and follow up question: if yes, what should i take a look at to get up to speed on said project? :p [13:12] jcsackett: stick in project A if possible [13:12] rick_h_, you got it. [13:12] jcsackett: either the charm search card or the charm browser home button with kadam's face on it [13:13] just take him off [13:13] dig. [13:19] lazyPower: marcoceppi https://jujucharms.com/precise/vsm [13:19] jujugui: m.j.c is ingesting charms again. [13:19] looking at log files and keeping an eye on it [13:19] bac: what was preventing vsm from being ingested? [13:19] bac ty [13:20] jcsackett: nothing was being ingested and i haven't looked at that one specifically yet [13:20] bac: it's all good [13:20] clsoing the bug [13:20] bac: ah, ok. [13:20] it was due to no ingestion at all happening [13:20] rick_h_: that's what i assumed [13:21] luca: no hangout on that calendar entry to please invite me to whatever you guys set up. [13:26] rick_h_, jcsackett: weird, it looks like ingest just gave up a few days ago. https://pastebin.canonical.com/108930/ [13:26] i assume the two github attempts right after midnight are due to it being kicked by logrotate or something [13:27] the IngestErrors for "charm contains no files" are handled and aren't fatal to the process [13:29] bac, yeah, i think i recall no files being handled back in the orangesquad days. [13:30] jcsackett: but then it just went on strike [13:30] servicectl status showed it was alive. [13:37] bac: eh, ingest is a tetchy beast. it probably just wanted a holiday. [13:39] bac: rgr, we should add a low maint task to add a nagios check for that last run stuff [13:39] bac: so at least if it gives up the ghost for a day we know about it [13:39] or at least make that RED on heartbeat [13:39] so blind people like me can see what's up :) [13:39] sure [13:44] jujugui: i'm finding that `make clean-all test-debug` is requiring my password for sudo rights. any idea what i goofed? [13:45] jcsackett: check perms on ~/tmp and ~/.npm [13:45] jcsackett: the instructions should have had you chown those during the setup [13:46] jcsackett: but you shouldn't need to run make clean-all much [13:46] jcsackett: oddly enough it did shut down right on good friday. [13:46] as well [13:46] rick_h_, it just tells you to make them, which shouldn't be a problem since they should default correctly. [13:46] and indeed, i am owner &c. [13:46] jujugui on the road back home, biab [13:46] ha! i love that it died on good friday. [13:47] ...oh, bad word choice on my part...i love that it took good friday off. [14:17] rick_h_: thanks for looking into that. [14:24] jcsackett: the exodus branch from yesterday failed when deployed to staging. this branch is the fix. could you take a look at it? https://codereview.appspot.com/90300043 [14:27] bac, lgtm [14:27] ty jcsackett. now to try to deploy to staging and make it happy again [14:31] * rick_h_ is back [14:31] jcsackett: not sure then on the sudo thing. [14:34] rick_h_, no worries, i'll poke at it later. it's doing something with /usr/local/src, but it's an LXC so meh. [14:34] rick_h_, got a quick sec for g+? [14:34] jcsackett: sure thing [14:35] shoot me a link [14:35] rick_h_ https://plus.google.com/hangouts/_/7acpj4cuggoppve90pnm3v27hs?hl=en [14:50] jujugui: can someone take a look at a short PR for me? https://github.com/juju/juju-gui/pull/252 [14:52] jcsackett: i will after the meeting [14:52] bac, thanks. [14:52] jujugui: meeting at :00 [14:54] * jcsackett needs coffee for meetings [14:54] jcastro: new precise and trusty charms released/ingested with the apt-update fix [14:57] Question about testing and flags: I see a slew of tests in test_browser_app.js that check to make sure various routing situations are handled correctly. It seems like they're all run sans flags. Is there a way to easily control flag values for a test? [14:58] frankban, thank you sir! [14:58] rick_h_, man I can't believe I found a bug and a fix! [14:58] jcastro: :) [14:58] rick_h_, and you were probably bored at some meeting [14:59] :-) [14:59] jcastro: someone has to plan for everyone else to be bored in vegas :P [14:59] jujugui call in 1 [15:00] kadams54, you'll see many a test set window.flags = $flag_you_need [15:00] just make sure there's cleanup as well. [15:20] Makyo: join the hangout again? [15:23] jcsackett: i'm looking at your branch. i'm trying to see the broken behavior on jujucharms.com [15:23] jcsackett: i searched for mysql and then clicked on the home icon. seemed to work. what am i missing? [15:24] bac: with il? [15:24] OH ff [15:24] yup [15:26] jcsackett: like so? https://jujucharms.com/sidebar/search/:flags:il/?text=mysql [15:26] jcsackett: or is there another slash after :flags: [15:27] either way i don't see it misbehaving [15:27] bac :flags:/il/? [15:27] huh, it isn't misbehaving on jujucharms; it does on develop locally tho. [15:28] jujucharms is old [15:28] use comingsoon [15:28] ahhhh. doh. [15:28] it's stuff that's broken in code since the last release [15:28] ok, that is def broken: http://comingsoon.jujucharms.com/:flags:/il/?text=mysql [15:28] :) [15:29] and now hopefully fixed [15:45] rick_h_, responded to your comment with updated branch. bac, you still looking? [15:46] jcsackett: done [15:47] jcsackett: now, really done [15:50] bac: the test is just for metadata being safely reset--component resets are already tested. [15:50] ok [15:51] rick_h_, the other card you told me to look at was the one about updating charm-search.js to use new state? just confirming what "charm search card" meant. [15:57] jcsackett: that one and the one that kadams54 is working on are closely related. That one needs to bring the filters object back into the state code [15:57] kadams54: sorry, I mixed up this card and yours this morning [15:57] jcsackett: yes that's the card I mean and it's updating the charm-search.js and bringing the filters back for managing the query string/search api call [15:58] rick_h_, dig. i'll start looking into it post lunch. [15:58] oh, wait, missed what you just said. [15:58] shall i leave that one to kadams54 then, post his work? [15:59] jcsackett: I think you can get started, but will have to incorporate his work. Maybe sync with him on it. [15:59] jcsackett: he's not touching things like charm-search.js but he is in the state code dealing with filters/query string changes [15:59] rick_h_, dig. i reiterate my post-lunch remark then. :p [16:00] kadams54, you likely to be around to chat a bit past 1? [16:00] Yes [16:10] cool beans. i'll ping you around then and we can make sure i don't wreck anything. :) [17:16] kadams54, free to chat at 1:30? [17:17] jcsackett: let me ping you when I'm ready. Just got a call from my son's school that he's had an accident and I need to run out a fresh change of clothes :-( [17:18] kadams54, dig. that is def a priority situation. [17:19] jujugui review/qa of relations+ecs stuff https://github.com/juju/juju-gui/pull/253 [17:19] Lost my pre-push hook, so lint may be bad. [17:20] makyo: i can look, but please tell me what does ECS stand for? [17:21] jcsackett, Environment Change Set. Local transaction that will be tied to a deploy button, so that you can work locally, then deploy all changes at once. [17:21] ah, so set up the whole set of relations and go rather than just one service at a time. [17:21] cool. looking now, makyo. [17:24] It's all hatch 's fault, jcsackett [17:24] (well, okay, 90%) [17:25] * jcsackett laughs [17:25] lol [17:50] Makyo, i've finished looking at code, QAing now--none of my comments are major. [17:50] looks like hatch is reviewing it too. [17:50] Good. [17:50] Thanks guys [17:54] Makyo, looks like your QA directions got cut off? "ensure that the relation" [17:54] jcsackett, oops, sorry. Ensure that the relation is in the changeset by investigating app.ecs.changeSet in the javascript console. [17:57] Updated. [17:57] Makyo, thanks. it passes your QA instructions--ping me when you address rick_h_'s comments about flags and i'll double check QA again. [17:57] jcastro, will do. Thanks! [17:58] jcsackett, Sorry, thanks. [17:58] jcastro, Lazy fingers, don't mind me [17:58] jcsackett: ready to talk when you are [17:59] kadams54, awesome, i'll pass your a URL momentarily. [18:00] kadams54, https://plus.google.com/hangouts/_/7acpj3384g52o10sitntlhkh3s [18:01] Says the party is over :-/ [18:02] ...bloody hell. [18:02] kadams54, are you signed in as your @canonical.com self? [18:02] what is your email? [18:02] kyle.adams@canonical.com [18:03] kadams54, give it a try now. [18:03] Makyo: comments added, I'm curious on the ecs as an arg vs communicating with the env [18:06] rick_h_, Every time I bring up events, I get in trouble, so I avoided it. If that's the path we're heading down, I'm all for it. [18:07] In particular, hatch__ has been a pretty big opponent of event-based work such as the topology. [18:07] Not quite sure who to make happy here :) [18:08] rick_h_, you got a second to chat? === hatch__ is now known as hatch [18:09] Makyo: k [18:09] Makyo: I'm just curious if there was a big reason [18:09] who said what in the where now? [18:09] Makyo: I think it makes the topology simpler and keeps it cleaner especially as it's nuts for it to deal with the ecs everywhere [18:10] jcsackett: sure thing [18:10] jcsackett: linky? [18:10] rick_h_, sure, makes sense. [18:10] rick_h_, https://plus.google.com/hangouts/_/7acpj3384g52o10sitntlhkh3s [18:10] hatch, using events to communicate between layers of the application. [18:10] jcsackett: is that from your url in the browser? [18:10] rick_h_, nope, that's from the share window, where i just invited your canonical address. [18:10] jcsackett: no worky, invite me? [18:10] ahh yeah [18:11] jcsackett: oh you've got to start it first then give me the live hangout url [18:11] rick_h_, it's started. i'm sitting in it. [18:11] jcsackett: invite again please. [18:11] rick_h_, hang on, i'm just going to start a new one. [18:11] Makyo: well I appreciate your thoughts on the two paths. [18:12] rick_h_, invite sent. [18:12] Makyo: we can mute hatch if we have to, he's on vacation and we can do what we want :P [18:12] rick_h_, https://plus.google.com/hangouts/_/7acpifdroro7ler4og7bqoom8k [18:12] Hahaha [18:12] * hatch is wondering if he should join this hangout [18:12] hatch: not yet [18:12] + like a million [18:13] Makyo: k, then we can chat with hatch if he has issues but I like the simpler use of events in this case [18:13] I'm not done going through the review yet [18:13] rick_h_, sure, I think it's a good direction to move in. I'll investigate heading in that direction. Thanks for the multiple reviews [18:13] I'll hold off until then [18:14] hatch, go ahead and finish if you find anything outstanding. [18:14] I'll get them all in one go. [18:15] the asynchronicity was something we agreed on, hatch. Wait until each layer of the hierarchy came back before starting the next so that we were sure the entities existed in the state machine. [18:15] As in, can't create a relation between services that don't exist in the state machine yet. [18:18] Makyo: yea, and my comments on that I realize are more wide ranging than this branch [18:18] Makyo: so you hatch and I should chat about the long term usage of this in real life use cases [18:23] Makyo ok right, I'm just trying to see if I see a better way for that [18:23] I don't like using Y.soon just to pop things to the top of the stack [18:24] hatch, ah, okay. More than happy to change it, I don;'t like it either. [18:24] Though it does show up elsewhere in our code. [18:24] Makyo: big one at https://github.com/juju/juju-gui/pull/253/files#diff-2396c727b78bbe8c6ff20dc9a231ee2aR935 though [18:24] yeah it does....but it's pretty much a hack everywhere [18:25] bah, never mind [18:25] Makyo: ok, so env has an add_relation method? [18:25] rick_h_, yes, though you're right that could do with a test. [18:25] can we not just ecs or not ecs it there in the env then and forget events or passing it in? [18:26] then the topo code doens't need to be changed at all in this branch [18:27] Oh, does the env have ecs? [18:27] the env is passing the ecs into topo I thought? [18:27] maybe I'm not following stuff /me looks again [18:28] the environment view is passing ecs into the topology when it creates the topology [18:28] not the env [18:28] oh ok [18:28] confusing name clash :) [18:28] Yeah, yikes [18:28] bah, this is nuts [18:28] :) [18:29] ok, so then is there value is giving the env the ecs and making everyone work with him [18:29] vs passing hte ecs into topo/etc? [18:29] the inspector/config changes will want access right? [18:29] what else? [18:30] think of the env as a bunch of utilities that the ecs controls in the proper order [18:30] so the ecs is what other things need to make requests of [18:30] ok, if we swap the env for the ecs I'm ok, but adding to feels like we're muddying things up even more [18:31] well keep in mind that this is a wip, the ecs never used to exist so everything was calling the env [18:31] it'll take time for things to move over [18:32] I know but I want to make sure we're thinking/planning for the future and trying to lay down a cleaner path as we go [18:32] if you're saying that all things should talk to the ecs vs the env, then let's do that. [18:33] I mean if the flag is set pass the ecs into the topology and if not, then pass in the env. Then we have an XXX that when the flag is removed to rename the var or something. [18:33] but this doesn't plan does a life without env atm [18:34] it just adds more code and more required setup and more things to keep in your head in the end [18:38] jcsackett: yet another... https://codereview.appspot.com/90420043 [18:38] so in looking at this, if we moved the ecs into the env, then we could simplify things. The env is already passed around and is on the environment View. hatch Makyo [18:38] Makyo: hatch the ecs could be setup with different options as required for sandbox vs go [18:39] Makyo: hatch and things like add_relation could just be 'ecs' enabled? [18:39] I can see that working, yeah [18:39] hatch: have time for a call? [18:39] maybe worth a chat? [18:42] sec just otp [18:42] hatch: np, appreciate your thoughts while you're away. [18:42] bac, so we're just losing any bundles that got grandfathered? will those be reingested eventually if they're updated to pass proof? [18:42] jcsackett: yeah, if they are fixed [18:43] jcsackett: it is no loss, they cannot be deployed [18:43] as is [18:43] we've just never had a process to do any housekeeping. [18:44] bac, dig. [18:44] lgtm. [18:45] ok off the phone [18:46] hatch: k, setting up a call [18:47] hatch: Makyo https://plus.google.com/hangouts/_/76cpik3in0rjn0urt22rbvjpo8?authuser=1&hl=en [18:47] jcsackett: your approve comment in RV needs to include the magic string LGTM somewhere in it. [18:49] bac: duh, of course. sorry. [18:50] bac, done. [18:50] thx [18:52] jujugui: i believe CI is stuck. is there a means of terminating a build? [18:52] jcsackett: yea second [19:08] rick_h_ yeah this will be a good change, will make it easier to follow when some things use/don't use the ecs [19:08] hatch: cool [19:08] hatch: thanks for taking the time to chat about it. [19:08] now go have fun! [19:08] :) [19:09] annnnnd my flight out of YXE is delayed 3H [19:09] how the heck.... [19:09] it's not until tomorrow [19:09] ouch! [19:09] how can it be delayed so bad already lol [19:09] 3hr is quite the delayed [19:10] I guess I get to sleep in more [19:10] well I'd make sure to watch it. Might move back :P [19:10] haha yeah wouldn't doubt it [19:11] the new google transit maps are pretty cool [19:11] it was just delayed another 20 mins.... umm [19:11] maybe I'm driving to Denver [19:11] lol [19:11] lol [19:21] we only filter on categories now, right? there's no UI to say "just recommended" or "just aws" is there? [19:21] jcsackett: no, there is not [19:21] jcsackett: there's talk of a future "tag based" search UI that we'd detect words as things like that [19:22] but no current UI [19:22] rick_h_, awesome. so we don't need to maintain the FILTER_SERIES &c bits? just the categories. [19:22] jcsackett: yes [19:23] alright, i'm not going to delete those bits in this branch, but i'll put a card saying once we remove the il flag they can be whacked. [19:23] s/card/note/ [19:23] though, maybe a card as well? [19:23] stick a card in the backlog for it [19:23] and we'll try to get a big cleanup phase into the plans at some point [19:26] "pool" vs "on deck"? i'm guessing pool, but the meaning isn't inherently obvious. [19:26] yes, pool [19:26] on deck is what we planning poker and has a chance to be in the next 2wk iteration [19:26] pool is long term [19:30] hey rick_h_ [19:30] I have an awesome idea [19:30] "awesome" [19:31] for demo mode [19:34] jcsackett: otp, but love ideas [19:35] he meant jcastro. :p [19:35] hey so [19:35] https://github.com/chjj/tty.js/ [19:35] remember how the old old old gui stuff had an idea for a terminal in the webui [19:52] jcastro: but that would have to run on each machine right? [19:52] jcastro: in the environment [19:53] jcastro: we've got tasks for debug-log and juju run to try to do next cycle, should help with some of it [20:15] rick_h_, just a reminder, there's a build stuck on CI. [20:15] jcsackett: ah thanks [20:16] it's based off my branch, which is a tad alarming, but it doesn't hang locally on a make test or make check [20:16] jcsackett: looks like you've got a login [20:16] jcsackett: so you have to login and then stop it [20:16] i have a login? that's news to me. [20:17] you're in the list :) [20:17] huh. i wonder what my login info is. [20:17] guihelp anyone seen ERROR no such request - method Client.PrivateAddress is not implemented [20:18] that's new to me, where are you getting that? [20:18] hatch: juju ssh jenkins/0 [20:19] oh that's very odd [21:06] * Makyo returns from house. [21:06] Signed my half of the contract, woo [21:09] Makyo: wooo! [21:11] oo whats woo? [21:11] rick_h_ so I'm on test coverage/improvements with kadams54 next wk? [21:11] Signed my half of the contract on the house. Need to get James to sign, then the offer's official. [21:11] right on!!!! [21:12] hatch: if he's interested [21:12] or Makyo if he is, or jcsackett if he is [21:12] hatch: you just need a programming buddy [21:13] * hatch brings a rubber ducky [21:13] hatch: sure, test coverage it is [21:14] Makyo: congrats! [21:15] Thanks :) Going heads down again to get this branch up ASAP. [21:15] oh Makyo the lazyAddRelation is a little confusing around the 'if deploy' block, can you add some comments there? [21:17] Yep [21:28] hatch: i may be very interested in test coverage next week. i have concerns about things that are only implicitly tested. [21:28] jcsackett we need a refactor of our entire test suite so maybe the three of us can chip away at it in the down time [21:29] let's try to get coverage without a rewrite though [21:29] just want to make sure we end the week with a 'shippable' project [21:29] something we can accomplish, a rewrite will be a stuck branch [21:29] :) [21:29] i'll accept all parts of state being explicitly tested. :p [21:29] also, maybe we can just kill those 13 pending tests that have been around for ever. [21:29] haha, they are....you see all those url tests? [21:30] NEVA!!!! [21:30] hatch, i just changed the new ui state object to load a filter object into metadata.search instead of a string. *nothing* broke. [21:30] i don't for a second believe that means everything is just working. :p [21:30] lol [21:31] sure - that means it's working exactly as intended [21:31] :) [21:31] admittingly search is already broken per kadams54's branch but not a good sign [21:31] * jcsackett laughs [21:31] honestly though, search is just a key, if you put the wrong stuff in it, that's not the state systems fault [21:32] hatch: but the url generation stuff should go boom [21:32] hatch: I'd expect at least [21:32] hatch: then again I guess the tests put a string in there [21:32] so it's still passing [21:32] ah, that's true [21:33] this isn't "enterprise" software, it can only be SO resilient lol [21:34] it's not perfect, but gets better every day [21:34] oh man I saw some .NET the other day....instead of whitelisting a specific kind of input, it blacklisted......EVERYTHING [21:35]