[13:09] morning, all. [13:09] party [13:11] jujugui please update the kanban board with what got done (even if not on the board) and where things are at today [13:26] how many of us are actually working today? [13:31] jcsackett: well the only request for swap day I got was from frankban [13:31] jcsackett: so I have no idea [13:36] rick_h_: dig. [14:21] rick_h_: for this new search header view that I'm working on, should I keep it in the subapp/browser space? [14:21] kadams54: yes [14:21] Or do we want that to go away? [14:22] kk [14:24] jujugui (repeat for the folks joined recently) please update the kanban board with what got done (even if not on the board) and where things are at today [14:30] ccccccbtujivddegtrcuebbulfrhrjkfngkbjireglbe [14:30] cat [14:30] dog [14:31] * hatch is sick [14:31] doh [14:31] stupid sick people traveling [14:31] double doh [14:31] redir: did you get the leankit email? [14:32] redir: looks like you did. You should have full access to the board now https://canonical.leankit.com/Boards/View/102529849 [14:32] rick_h_: yup. but no permissions on the boards yet [14:32] redir: let me know if you want to hangout pre call to get a run down of the board [14:33] OK. Just tried creating a card but didn't have permissions. [14:33] yea, just updated it [14:33] you should be full user now [14:34] k [14:39] card created [14:39] rick_h_: can I get a rundown of the board tomorrow morning? [14:39] redir: sure thing [14:39] redir: it uses gravatar for the head pics on the cards [14:41] OK. I'll find a good headshot [14:42] rick_h_ kadams54 after the standup can you guys explain to me the email re the sidebar changes? I don't really see where the proposed changes are any different than what we have been doing [14:42] hatch: k, will do [14:56] juju-gui: call in 4 minutes, i suppose. [14:56] (hope i'm not stepping on toes there, but hadn't seen a warning) [14:56] oh yea, jujugui call in 4 :) [14:56] no - [14:57] * rick_h_ is heads down atm and missed it and makyo normally catches it [14:57] speaking of which [14:58] Sorry, late morning. [14:59] hah it's all good. I think all of us are moving a bit slow today [14:59] I'm still recovering form that 2.5mi hike to the sharks on friday [14:59] /form/from [14:59] haha [15:00] jujugui: going to be a moment late, i've misplaced my earphones when unpacking. [15:01] redir: joining or are you on the train? [15:01] https://plus.google.com/hangouts/_/canonical.com/daily-standup?authuser=1 [15:25] jcsackett: I don't see you at all [15:25] rick_h_: you don't see me at all, like in canonicaladmin? b/c i can verify curtis is getting my expenses. [15:26] jcsackett: right, you're not listed on my team in canonical admin [15:26] rick_h_: right...so do i need to complain to P&C, or do you? [15:27] jcsackett: writing the email now. don't worry about it [15:27] rick_h_: cool, thanks. [15:27] P&C sounds like a big corporate conglomerate [15:29] Makyo: on your branch, jcsackett I think did some initial ideas towards that. The idea being that we whitelist good states and if it's not a good state we fallback to a default [15:31] rick_h_, oh, okay. I was going to see if a state was possible, then fall back, but that may be overthinking it. [15:31] rick_h_: we don't actuallly have any work towards that idea--we had a verification step i took out of my current branch b/c it only checked for files in flash for local insepctor. [15:31] Makyo: yea, I guess the general idea is I think it'd be better to try to whitelist and control things (e.g. in sandbox a inspector/mysql view isn't valid) [15:32] jcsackett: ok, well just saying we've had conversations so there's some background [15:32] rick_h_: dig. just didn't want there to be any false hope of work already done. :) [15:32] lol [15:33] Sounds good, I'll head in that direction. [15:40] is this the part where we need to check if the inspector urls are valid, if they aren't then show the charmbrowser/ [15:40] hatch: yes, that's the idea. [15:41] oh, and having a section validator pre dispatching is not going to work? [15:41] I think that's kind of the idea. To whitelist first before trying to do a bunch of stuff and then failing [15:43] ahh - I was thinking that because each section had such different requirements that it would validate each section individually [15:43] yea, but then it's hard to maintain and find out why something failed imo [15:43] I'd be curious if people are willing to trade off maintaining a white list up front that's clear/easy to read vs debugging it at the failure point [15:45] so you're thinking: URL parse to state > validate parsed state > dispatch ? [15:45] hatch: yep [15:45] hatch: at least it's the discussion I'd like to have :) [15:46] I think that will be considerably more work because you'd have to have these complex methods for parsing the state out instead of splitting it up into the sections. [15:46] and then dealing with them 1:1 [15:48] hatch: right but there's a point where state is parsed before dispatch right? [15:48] so a single call through some validation bits to say "oh, a charmbrowser state with metadata XX is invalid in this case" [15:48] no it goes from the url into state, then the state is only parsed in the dispatchers [15:48] it's "dumb" until the dispatchers [15:48] ah well then sucky. Maybe we can at least force a common api? [15:49] all dispatchers have a single parse/validate the state bit? [15:49] I just worry that it's like we have now with browser.js. When something fails to draw correctly, you have to debug through 6 methods to figure out why [15:49] it'll need to be validated pre-dispatch because we'll need to change the url to the 'default' for that section then re-dispatch [15:49] it's too spread out how you get from url to called views [15:50] hatch: right [15:50] rick_h_: that does start to sound like the work hatch and i considered, we have a validate method that calls validateSectionXXX, and that chain starts before dispatching starts. [15:50] jcsackett: k, yea I had hoped to make it state's job [15:50] but sounds like it's not possible [15:50] because at the state time, it could be changed quickly and easily [15:50] well this wuld be in state [15:50] rick_h_: not sure what you mean--validate/dispatch is in state. [15:51] then the state is only parsed in the dispatcher [15:51] is the quote hatch said [15:51] the url is parsed into sections, which make up the state, then the dispatcher runs through those sections and calls the handlers [15:52] the validation needs to happen pre dispaching [15:52] ok, sounds perfect then [15:52] "the dispatcher" here being a dispatch method. [15:52] yes [15:52] jcsackett so sounds like the original plan is still the right direction.....agree? [15:52] hatch: sounds very similar, yeah. [15:52] col [15:52] I just want to make sure that the error "inspector/mysql is not valid for sandbox mode" is done somewhere high up and obvious vs in the View which then triggers a new change event [15:52] cool [15:53] rick_h_ yes in the state module for sure [15:53] hatch: cool, then /me gets out of the way and carries on :) [15:53] Makyo: if you're working on this (and have been following along) https://github.com/jaycee/juju-gui/tree/add-flash-memory-to-state has some work you can crib, re the _validateSection logic. [15:54] ccccccdiltnnfvenndnvnrcddkedfhlebjlnvernfcge [15:54] rick_h_ it would help in planning for the demo if we had a basic script outline of the UI actions mark will be running [15:55] By which I mean thanks, jcsackett [15:55] hatch: yes [15:55] Makyo lol [15:55] Makyo: i figured that's what you meant. :) [15:55] hatch: I'll try to write out something and maybe even see if we can get UX to use their wireframes to mock out the journey for us [15:55] that would be awesome [15:56] hatch: will do, added a card for me to do that today. [15:56] * rick_h_ is going to go afk to go yell at the car dealer [15:56] Makyo: you can ignore the "flash" parts--you're just interested in the _validate stuff from view/state.js in that branch. i can land a follow up after yours to make sure the flash bits are validated using whatever you land. [15:56] it's not much, but it's code towards the long spiel rick_h_, hatch and i just had. :p [15:56] rick_h_ gl :) [15:57] hatch: i think i've addressed all your comments etc in my PR. [15:57] cool I'll take a look and QA [15:57] most were pretty trivial [15:59] jcsackett tests are failing fyi [16:01] hatch: well, test-server is blowing up--i can't reproduce anything locally. :/ [16:01] jcsackett doh [16:02] jcsackett when rick_h_ returns we will need to get him to killall the process [16:02] it'll be broken until then [16:02] hatch: fun times. well, are you happy with the PR, tests aside? [16:03] very likely, just going through still [16:04] jcsackett somewhat related - do we ever want to explicitly clear out the `flash` ATTR as well as the state one? [16:04] or do you think it's ok for the ATTR to hang around populated [16:08] hatch: i don't follow..."as well as the state one" [16:08] there's only a state ATTR. [16:09] or do you mean on metadata as well? [16:09] or am i just completely misreading you? :p [16:11] haha [16:11] ok so you reset the `flash` property on the state object [16:12] but there is also a `flash` ATTR on the state instance [16:12] which is only ever overwritten [16:12] never reset [16:13] jcsackett oh wait NM [16:13] ignore everything I Just said [16:14] I thought this https://github.com/juju/juju-gui/pull/271/files#diff-49f77193fff0d5a96b555595ed918791R126 was resetting the state object's property [16:21] jcsackett I created a few more comments for the tests. I'm QA'ing now [16:28] jcsackett you might want to hold off pushing the final version to the PR until CI is reset [16:28] else you'll have to trigger it all manually [16:35] http://store.steampowered.com/app/244830/ python IDE on steam? [16:37] Oh, that's kinda neat! [16:40] what is the bzr equiv of git pull upstream? [16:43] jujugui ^^^ [16:43] (I don't remember, unfortunately) [16:44] hmm - I always just pulled to update that branch then merged in [16:44] sorry I'm no help either [16:44] redir btw - in your irc client add `jujugui` and `guihelp` as notification targets [16:44] I mean, you can bzr merge lp:/trunk, I think, but don't know if that's best practice [16:44] sorry for dinging everyone :) [16:45] Makyo yeah that's what I always did heh [16:48] thanks [16:53] Cory Booker is sitting across the aisle from me on the train...foranyone who follwos that kind of stuff [16:54] Sometimes, I forget that I have the xkcd substitution extension running in Chrome... [16:55] Makyo: there's probably an appropriate strip for that [16:55] "Cory Anthony Booker (born April 27, 1969) is an American politician and the junior United States Elf-Lord from New Jersey. At the time of his eating contest to the Senate, he was the Mayor of Newark." [16:55] I also had to google him [16:55] awesome [16:55] and rofl Makyo [16:55] haha [16:56] I didn't think anyone cared about politics until someone does something that's ok unless a politician does it [16:56] https://chrome.google.com/webstore/detail/xkcd-substitutions/jkgogmboalmaijfgfhfepckdgjeopfhk [17:03] hatch: jcsackett looking at ci [17:04] thx [17:04] what was the result of the burningoilness ? [17:04] hatch: jcsackett process killed [17:04] hatch: just took it in, sitting here waiting now [17:04] hatch: I expressed my displeasure [17:05] ahhh - what kind of car? [17:05] hatch: outback [17:05] bugatti veyron ? [17:05] :P [17:06] ahh, does it only puff the smoke on startup? [17:06] no, it leaks in the drive (carboard with pattern brought in this time) and when I pulled in their garage it was smoking lovely [17:06] this time I think they believe me [17:07] ahh [17:07] good thing is that subies are easy to fix [17:08] I used to have an 01 WRX [17:08] with like 250,000km on it haha [17:09] yea, I'm bummed we're having this at 65k mi [17:09] my last one didn't have issues until closer to 100k mi [17:10] If it's leaking oil it might simply be that the smoke is because it's burning the oil on the outside, not from the valves or rings [17:10] hopefully [17:11] yep [17:14] http://varianto25.com/ <--- yes yes yes [17:15] highlights set, thanks hatch [17:15] np [17:45] rick_h_ do we have any code atm which takes an unplaced-unit and makes it a placed-unit ? [17:45] ^ jujugui [17:46] hatch: the api calls are there to create machines and containers. [17:46] right, but it looks like everything just creates a new unit via add_unit [17:46] hatch: we need the UI events to turn one into the other (e.g. on button press/etc turn unit token to machine token) [17:46] hatch: so no, this is the glue stuff we need to start now that we can show tokens at all three levels [17:47] unplaced, machine, and container [17:47] hmm ok [17:47] we should have UI and such for all three now [17:47] right, we can create an unplaced unit....but I don't think we have any code in the back end to convert that to a placed unit [17:47] well placed means a machine or container [17:48] so the code is two fold, one to create a changeset to add machine or container [17:48] and two, to remove the unplaced unit token and create a new machine/container token [17:48] or am I missing your point on this slow minded monday of mine? [17:48] well a unit != machine/container token [17:48] it does once placed? [17:49] well, it'll either update a machine or container token [17:49] or become one [17:49] I think you're mixing UI state with env state [17:49] for example [17:49] say I create 10 unplaced units [17:49] hatch: right, but env state should be a ghost machine/container, ghost service, ghost unit [17:50] those units are now in the db without a 'machine' value [17:50] now once the user drags that unit to a machine/container [17:50] we need to update that model....or delete it and create a new one [17:50] I'm wondering if that code exists [17:51] no, that code does not exist [17:52] ok for this branch I'll just call the env's add_unit method on mass scale up, and we can deal with the rest later [17:52] hatch: ok [17:52] I'll fire an email to frankban as he will certainly have some input on the 'placement' implementation [17:53] yea, I want to sit down a group to go through the db talk we started in vegas [17:53] the whole tracking units through both machines/containers and services [17:53] yeah...can we do that....say wednesday hopefully I'll be better by then :) [17:54] yea, all good [17:54] I think that fits into your question a bit though [17:54] because placing a unit it sticking it in the right part of the db referenced by the other super objects [17:55] yeah atm we need to create a unit on the service, then pre-sending the 'real' add-unit call, we need to have the 'machine' property updated [17:55] right [17:59] rogpeppe: you around today or swap day-ing it? [17:59] rick_h_: i see a card about browser.js needing to instantiate inspector views--i think we're already doing that now? [18:00] rick_h_: see various create*InspectorView functions. [18:00] jcsackett: yes [18:00] jcsackett: I didn't move it as the work is in progress like the local ones [18:00] ah, so i can move it along with my local card? [18:00] jcsackett: sure thing, sounds ok to me [18:00] since i think that's the only WIP regarding that. [18:00] ok. [18:01] hatch: that sound right? all inspectors now being done in browser? ^ [18:01] reading back... [18:01] correct [18:01] awesome. [18:01] after your card they are all moved [18:06] rick_h_: today is a public holiday [18:06] rogpeppe: ah, cool then [18:06] rick_h_: tomorrow i'm swap daying it [18:06] rick_h_: then i'm on holiday :-) [18:07] oh right cool [18:07] rick_h_: will be back on 22nd May [18:08] rogpeppe: cool thanks. I'll look forward to getting started then. I'm working on getting out notes and such from the sprint loaded up into docs and things [18:08] rick_h_: great, that will be useful [18:09] rick_h_: really looking forward to getting going on all of this stuff. [18:10] rogpeppe: same here :) I'll add you to the internal list for our stuff and send some notes there [18:11] * rogpeppe goes back to his mojito [18:12] enjoy! [18:14] rick_h_ I've finished my shutdown holidays and expenses [18:15] hatch: k, got the holidays in. Will go through expenses. [18:17] cool [18:18] jcsackett: if you get yours into landing can you peek at huw's pull request and QA please? [18:18] is May 19th a holiday in the US? National Patriots Day? [18:18] rick_h_ jcsackett I already did, he needs some slight refactoring first [18:18] hatch: ah ok thanks [18:18] when he gets in tonight I'll guide him through the implementation [18:18] hatch: no, there's memorial day the 26th [18:18] for the US [18:19] ahh one week later [18:19] hatch: rgr [18:19] jcsackett lint error failure in your branch [18:19] :) [18:19] hatch: he might not be around tonight [18:19] travel and all that [18:19] ohh ok, np, well when he does [18:25] I'm going to take lunch [18:26] hatch: have fun [18:27] bah, car seal goes boom! [18:33] * rick_h_ gets ready to get driven home from car dealer. back online later on [19:17] * rick_h_ is back [19:19] rick_h_ which seal [19:19] ? [19:19] some front engine seal [19:19] looks like it was coming down into the oil pan [19:20] ahh yeah - that one might be pricy to fix [19:20] showed me the leak but don't know enough about cards to name the bits [19:20] yea, $1k [19:20] new timing belt along for the ride wheee [19:20] yeah sounds about right [19:20] :/ cars [19:21] hey, I wanted to pay it off before major work, mission accomplished [19:21] $1k is like 2 car payments so if it goes a year after this we're all good :) [19:22] haha yeah - that's where I'm at too, cars paid off....hard to justify the payments for the amount of k's I drive [19:22] Excellent use of canvas: http://www.georgeandjonathan.com/ [19:22] yea, that was cool [19:24] heh vwry cool [19:26] rick_h_: can you kick CI again? it's still doing the server death thing. [19:27] jcsackett was there a hanging run? [19:27] jcsackett: well, it's a different error [19:28] that you killed manually [19:28] jcsackett: I'm looking now [19:28] ReferenceError: Can't find variable: YUI [19:28] and connect.multipart() will be removed in connect 3.0 connect.limit() will be removed in connect 3.0 [19:28] Error: listen EADDRINUSE [19:28] it's the same....looks like it just got further before crashing [19:28] hatch: in the latest? #859? [19:28] http://ci.jujugui.org:8080/job/juju-gui/859/console [19:28] oh it is, wtf [19:28] yup [19:29] I don't see any manually killed runs, so I'm not sure how that got broken [19:29] maybe we should add a killall in the start of our script? [19:29] hatch: yea, there's supposed to be a catch [19:29] hatch: jcsackett ok, try again killed [19:29] I think I missed a process last itme I ssh'd my bad [19:29] there were two I needed to kill I think [19:30] only got the one [19:30] jcsackett: if it runs ok on your end just :shipit: [19:31] * rick_h_ makes a card in on deck to update to sauce connect 3.0 [19:55] dimitern: hey, do you know what you were ordered for nuc/switch? [19:55] dimitern: I want to get a setup here as well and haven't heard back yet on what the standard is [19:56] rick_h_, hey [19:56] rick_h_, i'm yet to see dustin and take the nucs + switch [19:57] rick_h_, i'll let you know when i have them [19:57] dimitern: ok cool. If you think about it, would love to see what models and such [19:57] dimitern: ty much [19:57] rick_h_ thinking for a home test box? [19:57] rick_h_, not quite sure about the models as dustin had them ordered - for the nucs [19:57] hatch: yea, I want to setup a MAAS test env here at the house [19:58] hatch: and maybe see about how to share it out to the team for maas setup/testing as we need to make sure our bundles, quickstart, etc work well [19:58] coolio [19:58] rick_h_, ... they are the ones supporting amt (more expensive), and the switch is some 8-port d-link with vlans support, but don't have the model [19:58] oh that would be sollllid [19:58] dimitern: yea, the switch I'm less worried about. I've got a dell that does vlans currently that's cool and not bad. It's more trying to find the right nuc model [20:08] robbiew: howdy, I notice your bug. Can you verify that 1.3.2 fixes it? We hit a Juju regression I believe and we've patched and are looking to get an update into trusty this week [20:09] huh? [20:09] rick_h_: [20:09] what bug? [20:09] robbiew: http://jujugui.wordpress.com/2014/04/30/juju-quickstart-1-3-2-released/ [20:09] robbiew: looking for the number [20:10] https://bugs.launchpad.net/juju-quickstart/+bug/1309455 robbiew [20:10] <_mup_> Bug #1309455: The auto-generated local env does not work in trusty [20:10] ooohhhhh [20:10] robbiew: we just fixed quickstart during the sprint and just got back [20:10] we were going to ping soon to work on seeing about 1.3.2 into trusty as a bugfix update [20:11] frankban is out today as swap but should be back tomorrow. We fixed a couple of bugs [20:11] robbiew: unless 1.3.2 does not in fact fix your issue. In which case we need to look at the issue asap [20:11] rick_h_: sorry...this isn't my bug [20:12] oh...nevermind [20:12] now I remember [20:13] robbiew: it's a mix of juju and quickstart bugs. We're working with QA team to get quickstart into the Juju CI runs [20:13] sounds good [20:14] robbiew: https://bugs.launchpad.net/juju-quickstart/+bug/1306537 is the other one I think [20:14] <_mup_> Bug #1306537: LXC local provider fails to provision precise instances from a trusty host

[20:14] ack [20:15] robbiew: to be able to get an update to quickstart in trusty should I file a bug on the package? Is there a format to make sure I meet? [20:17] I have no idea [20:17] rick_h_: lol [20:17] robbiew: oh :) nvm then. [20:17] rick_h_: just ask marco [20:17] lol wrong robbie my bad [20:18] yeah...that's what I quickly figured [20:18] * rick_h_ remembers robie has one b [20:18] sorry about the confusion [20:18] so yea, use 1.3.2 for the moment and we'll work with rbasak to get trusty updated asap [20:18] it's cool...I knew of the bug just because I had used juju from some demoes awhile back...but when you asked me how to file the bug...figured it out [20:19] I'll mark the bug as a dupe for now. If 1.3.2 doesn't fix it let me know as it's something else we're not aware of [20:19] ack [20:20] jujugui who wrote the machine-token.js file? [20:20] originally that is [20:20] hatch: huw maybe [20:20] hatch: either huw or kadams, I can't recall atm [20:21] hatch: any reason you're hunting? [20:21] it's expecting a hardware object in the render cycle and it fails if that's not provided [20:21] I was wondering if that was intentional or if it's a bug [20:22] hatch: probably a bug in that it was written aroud current data [20:22] well, either way it's a bug, I'm just trying to figure out if it's the machine-token or the database [20:22] so it was probably just a way to get it working and viewable vs thorough [20:22] ok I'll put in a || for now [20:22] hatch: yea, I mean the tokens are just UI starts to build on, all of them [20:22] ok sounds good [20:39] woot, nuc, drives, and ram ordered with gigabit vlan switch [20:40] haha nice [20:41] * rick_h_ wonders if he can get a second IP from ATT Uverse [20:43] it'll probably be $100/mo [20:43] lol [20:48] doh, bit by CC thinking it's fraud [20:49] you're such a criminal [20:49] kehehe [20:54] yay jcsackett 's branch finally landed heh [20:54] poor CI [21:01] I'm going to go lie down for a bit, I'll finish up the day later [21:22] I should get a few NUCs too. Kind of weird to think about, since James just got a nuc (as in nucleus colony of bees) this weekend. [21:30] rick_h_, what NUC did you get? [21:44] Makyo: http://www.newegg.com/Product/Product.aspx?Item=N82E16856102052 [21:44] Makyo: right now working with ATT to get multiple IP addresses on my account [21:45] goal is to setup the 3 nuc and switch on their own network for folks to use [21:45] Oh, rock on [21:46] so yea, will take a bit to get the bits in order but should help with bundle/quickstart/network testing in the future [21:46] as maas is the first network target especially [21:48] Yeah, for sure [22:05] Ducking out to get the dog to the vet. She cut her paw on something. [22:08] ruh roh, good luck! [23:08]