[13:09] <jcsackett> morning, all.
[13:09] <rick_h_> party
[13:11] <rick_h_> jujugui please update the kanban board with what got done (even if not on the board) and where things are at today
[13:26] <jcsackett> how many of us are actually working today?
[13:31] <rick_h_> jcsackett: well the only request for swap day I got was from frankban
[13:31] <rick_h_> jcsackett: so I have no idea 
[13:36] <jcsackett> rick_h_: dig.
[14:21] <kadams54> rick_h_: for this new search header view that I'm working on, should I keep it in the subapp/browser space?
[14:21] <rick_h_> kadams54: yes
[14:21] <kadams54> Or do we want that to go away?
[14:22] <kadams54> kk
[14:24] <rick_h_> 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] <rick_h_> ccccccbtujivddegtrcuebbulfrhrjkfngkbjireglbe
[14:30] <redir> cat
[14:30] <hatch> dog
[14:31]  * hatch is sick
[14:31] <rick_h_> doh
[14:31] <hatch> stupid sick people traveling
[14:31] <rick_h_> double doh
[14:31] <rick_h_> redir: did you get the leankit email?
[14:32] <rick_h_> redir: looks like you did. You should have full access to the board now https://canonical.leankit.com/Boards/View/102529849 
[14:32] <redir> rick_h_: yup. but no permissions on the boards yet
[14:32] <rick_h_> redir: let me know if you want to hangout pre call to get a run down of the board
[14:33] <redir> OK. Just tried creating a card but didn't have permissions.
[14:33] <rick_h_> yea, just updated it
[14:33] <rick_h_> you should be full user now
[14:34] <redir> k
[14:39] <redir> card created
[14:39] <redir> rick_h_: can I get a rundown of the board tomorrow morning?
[14:39] <rick_h_> redir: sure thing
[14:39] <rick_h_> redir: it uses gravatar for the head pics on the cards
[14:41] <redir> OK. I'll find a good headshot
[14:42] <hatch> 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] <rick_h_> hatch: k, will do
[14:56] <jcsackett> juju-gui: call in 4 minutes, i suppose.
[14:56] <jcsackett> (hope i'm not stepping on toes there, but hadn't seen a warning)
[14:56] <rick_h_> oh yea, jujugui call in 4 :)
[14:56] <rick_h_> no -
[14:57]  * rick_h_ is heads down atm and missed it and makyo normally catches it
[14:57] <rick_h_> speaking of which
[14:58] <Makyo> Sorry, late morning.
[14:59] <rick_h_> hah it's all good. I think all of us are moving a bit slow today
[14:59] <rick_h_> I'm still recovering form that 2.5mi hike to the sharks on friday
[14:59] <rick_h_>  /form/from
[14:59] <hatch> haha
[15:00] <jcsackett> jujugui: going to be a moment late, i've misplaced my earphones when unpacking.
[15:01] <rick_h_> redir: joining or are you on the train? 
[15:01] <rick_h_> https://plus.google.com/hangouts/_/canonical.com/daily-standup?authuser=1
[15:25] <rick_h_> jcsackett: I don't see you at all 
[15:25] <jcsackett> rick_h_: you don't see me at all, like in canonicaladmin? b/c i can verify curtis is getting my expenses.
[15:26] <rick_h_> jcsackett: right, you're not listed on my team in canonical admin
[15:26] <jcsackett> rick_h_: right...so do i need to complain to P&C, or do you?
[15:27] <rick_h_> jcsackett: writing the email now. don't worry about it
[15:27] <jcsackett> rick_h_: cool, thanks.
[15:27] <hatch> P&C sounds like a big corporate conglomerate 
[15:29] <rick_h_> 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] <Makyo> 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] <jcsackett> 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] <rick_h_> 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] <rick_h_> jcsackett: ok, well just saying we've had conversations so there's some background
[15:32] <jcsackett> rick_h_: dig. just didn't want there to be any false hope of work already done. :)
[15:32] <rick_h_> lol
[15:33] <Makyo> Sounds good, I'll head in that direction.
[15:40] <hatch> 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] <rick_h_> hatch: yes, that's the idea. 
[15:41] <hatch> oh, and having a section validator pre dispatching is not going to work?
[15:41] <rick_h_> I think that's kind of the idea. To whitelist first before trying to do a bunch of stuff and then failing
[15:43] <hatch> ahh - I was thinking that because each section had such different requirements that it would validate each section individually
[15:43] <rick_h_> yea, but then it's hard to maintain and find out why something failed imo
[15:43] <rick_h_> 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] <hatch> so you're thinking: URL parse to state > validate parsed state > dispatch ?
[15:45] <rick_h_> hatch: yep
[15:45] <rick_h_> hatch: at least it's the discussion I'd like to have :)
[15:46] <hatch> 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] <hatch> and then dealing with them 1:1
[15:48] <rick_h_> hatch: right but there's a point where state is parsed before dispatch right?
[15:48] <rick_h_> so a single call through some validation bits to say "oh, a charmbrowser state with metadata XX is invalid in this case"
[15:48] <hatch> no it goes from the url into state, then the state is only parsed in the dispatchers
[15:48] <hatch> it's "dumb" until the dispatchers
[15:48] <rick_h_> ah well then sucky. Maybe we can at least force a common api?
[15:49] <rick_h_> all dispatchers have a single parse/validate the state bit?
[15:49] <rick_h_> 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] <hatch> 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] <rick_h_> it's too spread out how you get from url to called views
[15:50] <rick_h_> hatch: right
[15:50] <jcsackett> 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] <rick_h_> jcsackett: k, yea I had hoped to make it state's job
[15:50] <rick_h_> but sounds like it's not possible
[15:50] <rick_h_> because at the state time, it could be changed quickly and easily
[15:50] <hatch> well this wuld be in state
[15:50] <jcsackett> rick_h_: not sure what you mean--validate/dispatch is in state. 
[15:51] <rick_h_> then the state is only parsed in the dispatcher
[15:51] <rick_h_> is the quote hatch said
[15:51] <hatch> the url is parsed into sections, which make up the state, then the dispatcher runs through those sections and calls the handlers
[15:52] <hatch> the validation needs to happen pre dispaching
[15:52] <rick_h_> ok, sounds perfect then
[15:52] <jcsackett> "the dispatcher" here being a dispatch method.
[15:52] <hatch> yes
[15:52] <hatch> jcsackett so sounds like the original plan is still the right direction.....agree?
[15:52] <jcsackett> hatch: sounds very similar, yeah.
[15:52] <hatch> col
[15:52] <rick_h_> 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] <hatch> cool
[15:53] <hatch> rick_h_ yes in the state module for sure
[15:53] <rick_h_> hatch: cool, then /me gets out of the way and carries on :)
[15:53] <jcsackett> 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] <Makyo> ccccccdiltnnfvenndnvnrcddkedfhlebjlnvernfcge
[15:54] <hatch> 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] <Makyo> By which I mean thanks, jcsackett 
[15:55] <rick_h_> hatch: yes
[15:55] <hatch> Makyo lol
[15:55] <jcsackett> Makyo: i figured that's what you meant. :)
[15:55] <rick_h_> 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] <hatch> that would be awesome
[15:56] <rick_h_> 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] <jcsackett> 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] <jcsackett> it's not much, but it's code towards the long spiel rick_h_, hatch and i just had. :p
[15:56] <hatch> rick_h_ gl :)
[15:57] <jcsackett> hatch: i think i've addressed all your comments etc in my PR.
[15:57] <hatch> cool I'll take a look and QA
[15:57] <hatch> most were pretty trivial
[15:59] <hatch> jcsackett tests are failing fyi
[16:01] <jcsackett> hatch: well, test-server is blowing up--i can't reproduce anything locally. :/
[16:01] <hatch> jcsackett doh
[16:02] <hatch> jcsackett when rick_h_  returns we will need to get him to killall the process
[16:02] <hatch> it'll be broken until then
[16:02] <jcsackett> hatch: fun times. well, are you happy with the PR, tests aside?
[16:03] <hatch> very likely, just going through still
[16:04] <hatch> jcsackett somewhat related - do we ever want to explicitly clear out the `flash` ATTR as well as the state one?
[16:04] <hatch> or do you think it's ok for the ATTR to hang around populated
[16:08] <jcsackett> hatch: i don't follow..."as well as the state one"
[16:08] <jcsackett> there's only a state ATTR.
[16:09] <jcsackett> or do you mean on metadata as well?
[16:09] <jcsackett> or am i just completely misreading you? :p
[16:11] <hatch> haha
[16:11] <hatch> ok so you reset the `flash` property on the state object
[16:12] <hatch> but there is also a `flash` ATTR on the state instance
[16:12] <hatch> which is only ever overwritten 
[16:12] <hatch> never reset
[16:13] <hatch> jcsackett oh wait NM
[16:13] <hatch> ignore everything I Just said
[16:14] <hatch> I thought this https://github.com/juju/juju-gui/pull/271/files#diff-49f77193fff0d5a96b555595ed918791R126 was resetting the state object's property
[16:21] <hatch> jcsackett I created a few more comments for the tests. I'm QA'ing now
[16:28] <hatch> jcsackett you might want to hold off pushing the final version to the PR until CI is reset
[16:28] <hatch> else you'll have to trigger it all manually
[16:35] <hatch> http://store.steampowered.com/app/244830/ python IDE on steam?
[16:37] <Makyo> Oh, that's kinda neat!
[16:40] <redir> what is the bzr equiv of git pull upstream?
[16:43] <Makyo> jujugui ^^^
[16:43] <Makyo> (I don't remember, unfortunately)
[16:44] <hatch> hmm - I always just pulled to update that branch then merged in
[16:44] <hatch> sorry I'm no help either
[16:44] <hatch> redir btw - in your irc client add `jujugui` and `guihelp` as notification targets
[16:44] <Makyo> I mean, you can bzr merge lp:<project>/trunk, I think, but don't know if that's best practice
[16:44] <hatch> sorry for dinging everyone :)
[16:45] <hatch> Makyo yeah that's what I always did heh
[16:48] <redir> thanks
[16:53] <redir> Cory Booker is sitting across the aisle from me on the train...foranyone who follwos that kind of stuff
[16:54] <Makyo> Sometimes, I forget that I have the xkcd substitution extension running in Chrome...
[16:55] <redir> Makyo: there's probably an appropriate strip for that
[16:55] <Makyo> "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] <hatch> I also had to google him
[16:55] <redir> awesome
[16:55] <hatch> and rofl Makyo 
[16:55] <hatch> haha
[16:56] <hatch> I didn't think anyone cared about politics until someone does something that's ok unless a politician does it
[16:56] <Makyo> https://chrome.google.com/webstore/detail/xkcd-substitutions/jkgogmboalmaijfgfhfepckdgjeopfhk
[17:03] <rick_h_> hatch: jcsackett looking at ci
[17:04] <hatch> thx
[17:04] <hatch> what was the result of the burningoilness ?
[17:04] <rick_h_> hatch: jcsackett process killed
[17:04] <rick_h_> hatch: just took it in, sitting here waiting now
[17:04] <rick_h_> hatch: I expressed my displeasure
[17:05] <hatch> ahhh - what kind of car?
[17:05] <rick_h_> hatch: outback
[17:05] <hatch> bugatti veyron ?
[17:05] <hatch> :P
[17:06] <hatch> ahh, does it only puff the smoke on startup?
[17:06] <rick_h_> 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] <rick_h_> this time I think they believe me
[17:07] <hatch> ahh
[17:07] <hatch> good thing is that subies are easy to fix
[17:08] <hatch> I used to have an 01 WRX 
[17:08] <hatch> with like 250,000km on it haha
[17:09] <rick_h_> yea, I'm bummed we're having this at 65k mi
[17:09] <rick_h_> my last one didn't have issues until closer to 100k mi
[17:10] <hatch> 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] <hatch> hopefully
[17:11] <rick_h_> yep
[17:14] <hatch> http://varianto25.com/ <--- yes yes yes
[17:15] <redir> highlights set, thanks hatch 
[17:15] <hatch> np
[17:45] <hatch> rick_h_ do we have any code atm which takes an unplaced-unit and makes it a placed-unit ?
[17:45] <hatch> ^ jujugui
[17:46] <rick_h_> hatch: the api calls are there to create machines and containers. 
[17:46] <hatch> right, but it looks like everything just creates a new unit via add_unit
[17:46] <rick_h_> 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] <rick_h_> hatch: so no, this is the glue stuff we need to start now that we can show tokens at all three levels
[17:47] <rick_h_> unplaced, machine, and container
[17:47] <hatch> hmm ok
[17:47] <rick_h_> we should have UI and such for all three now
[17:47] <hatch> 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] <rick_h_> well placed means a machine or container
[17:48] <rick_h_> so the code is two fold, one to create a changeset to add machine or container
[17:48] <rick_h_> and two, to remove the unplaced unit token and create a new machine/container token
[17:48] <rick_h_> or am I missing your point on this slow minded monday of mine?
[17:48] <hatch> well a unit != machine/container token
[17:48] <rick_h_> it does once placed?
[17:49] <rick_h_> well, it'll either update a machine or container token
[17:49] <rick_h_> or become one
[17:49] <hatch> I think you're mixing UI state with env state
[17:49] <hatch> for example
[17:49] <hatch> say I create 10 unplaced units
[17:49] <rick_h_> hatch: right, but env state should be a ghost machine/container, ghost service, ghost unit
[17:50] <hatch> those units are now in the db without a 'machine' value
[17:50] <hatch> now once the user drags that unit to a machine/container
[17:50] <hatch> we need to update that model....or delete it and create a new one
[17:50] <hatch> I'm wondering if that code exists
[17:51] <rick_h_> no, that code does not exist
[17:52] <hatch> 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] <rick_h_> hatch: ok
[17:52] <hatch> I'll fire an email to frankban as he will certainly have some input on the 'placement' implementation
[17:53] <rick_h_> yea, I want to sit down a group to go through the db talk we started in vegas
[17:53] <rick_h_> the whole tracking units through both machines/containers and services
[17:53] <hatch> yeah...can we do that....say wednesday hopefully I'll be better by then :)
[17:54] <rick_h_> yea, all good
[17:54] <rick_h_> I think that fits into your question a bit though
[17:54] <rick_h_> because placing a unit it sticking it in the right part of the db referenced by the other super objects
[17:55] <hatch> 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] <rick_h_> right
[17:59] <rick_h_> rogpeppe: you around today or swap day-ing it?
[17:59] <jcsackett> rick_h_: i see a card about browser.js needing to instantiate inspector views--i think we're already doing that now?
[18:00] <jcsackett> rick_h_: see various create*InspectorView functions.
[18:00] <rick_h_> jcsackett: yes
[18:00] <rick_h_> jcsackett: I didn't move it as the work is in progress like the local ones
[18:00] <jcsackett> ah, so i can move it along with my local card?
[18:00] <rick_h_> jcsackett: sure thing, sounds ok to me
[18:00] <jcsackett> since i think that's the only WIP regarding that.
[18:00] <jcsackett> ok.
[18:01] <jcsackett> hatch: that sound right? all inspectors now being done in browser? ^
[18:01] <hatch> reading back...
[18:01] <hatch> correct
[18:01] <jcsackett> awesome.
[18:01] <hatch> after your card they are all moved
[18:06] <rogpeppe> rick_h_: today is a public holiday
[18:06] <rick_h_> rogpeppe: ah, cool then
[18:06] <rogpeppe> rick_h_: tomorrow i'm swap daying it
[18:06] <rogpeppe> rick_h_: then i'm on holiday :-)
[18:07] <rick_h_> oh right cool
[18:07] <rogpeppe> rick_h_: will be back on 22nd May
[18:08] <rick_h_> 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] <rogpeppe> rick_h_: great, that will be useful
[18:09] <rogpeppe> rick_h_: really looking forward to getting going on all of this stuff.
[18:10] <rick_h_> 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] <rick_h_> enjoy!
[18:14] <hatch> rick_h_ I've finished my shutdown holidays and expenses 
[18:15] <rick_h_> hatch: k, got the holidays in. Will go through expenses. 
[18:17] <hatch> cool
[18:18] <rick_h_> jcsackett: if you get yours into landing can you peek at huw's pull request and QA please?
[18:18] <hatch> is May 19th a holiday in the US? National Patriots Day?
[18:18] <hatch> rick_h_ jcsackett  I already did, he needs some slight refactoring first
[18:18] <rick_h_> hatch: ah ok thanks
[18:18] <hatch> when he gets in tonight I'll guide him through the implementation
[18:18] <rick_h_> hatch: no, there's memorial day the 26th
[18:18] <rick_h_> for the US
[18:19] <hatch> ahh one week later
[18:19] <rick_h_> hatch: rgr
[18:19] <hatch> jcsackett lint error failure in your branch
[18:19] <hatch> :)
[18:19] <rick_h_> hatch: he might not be around tonight
[18:19] <rick_h_> travel and all that
[18:19] <hatch> ohh ok, np, well when he does
[18:25] <hatch> I'm going to take lunch
[18:26] <rick_h_> hatch: have fun
[18:27] <rick_h_> 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] <hatch> rick_h_ which seal
[19:19] <hatch> ?
[19:19] <rick_h_> some front engine seal
[19:19] <rick_h_> looks like it was coming down into the oil pan
[19:20] <hatch> ahh yeah - that one might be pricy to fix
[19:20] <rick_h_> showed me the leak but don't know enough about cards to name the bits
[19:20] <rick_h_> yea, $1k
[19:20] <rick_h_> new timing belt along for the ride wheee
[19:20] <hatch> yeah sounds about right
[19:20] <hatch> :/ cars
[19:21] <rick_h_> hey, I wanted to pay it off before major work, mission accomplished
[19:21] <rick_h_> $1k is like 2 car payments so if it goes a year after this we're all good :)
[19:22] <hatch> 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] <Makyo> Excellent use of canvas: http://www.georgeandjonathan.com/
[19:22] <rick_h_> yea, that was cool
[19:24] <hatch> heh vwry cool
[19:26] <jcsackett> rick_h_: can you kick CI again? it's still doing the server death thing.
[19:27] <hatch> jcsackett was there a hanging run?
[19:27] <rick_h_> jcsackett: well, it's a different error
[19:28] <hatch> that you killed manually
[19:28] <rick_h_> jcsackett: I'm looking now
[19:28] <rick_h_> ReferenceError: Can't find variable: YUI
[19:28] <rick_h_> and connect.multipart() will be removed in connect 3.0 connect.limit() will be removed in connect 3.0
[19:28] <hatch> Error: listen EADDRINUSE
[19:28] <hatch> it's the same....looks like it just got further before crashing
[19:28] <rick_h_> hatch: in the latest? #859?
[19:28] <hatch> http://ci.jujugui.org:8080/job/juju-gui/859/console
[19:28] <rick_h_> oh it is, wtf
[19:28] <hatch> yup
[19:29] <hatch> I don't see any manually killed runs, so I'm not sure how that got broken
[19:29] <hatch> maybe we should add a killall in the start of our script?
[19:29] <rick_h_> hatch: yea, there's supposed to be a catch 
[19:29] <rick_h_> hatch: jcsackett ok, try again killed
[19:29] <rick_h_> I think I missed a process last itme I ssh'd my bad
[19:29] <rick_h_> there were two I needed to kill I think
[19:30] <rick_h_> only got the one
[19:30] <rick_h_> 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] <rick_h_> dimitern: hey, do you know what you were ordered for nuc/switch? 
[19:55] <rick_h_> dimitern: I want to get a setup here as well and haven't heard back yet on what the standard is
[19:56] <dimitern> rick_h_, hey
[19:56] <dimitern> rick_h_, i'm yet to see dustin and take the nucs + switch
[19:57] <dimitern> rick_h_, i'll let you know when i have them
[19:57] <rick_h_> dimitern: ok cool. If you think about it, would love to see what models and such
[19:57] <rick_h_> dimitern: ty much
[19:57] <hatch> rick_h_ thinking for a home test box?
[19:57] <dimitern> rick_h_, not quite sure about the models as dustin had them ordered - for the nucs
[19:57] <rick_h_> hatch: yea, I want to setup a MAAS test env here at the house
[19:58] <rick_h_> 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] <hatch> coolio
[19:58] <dimitern> 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] <hatch> oh that would be sollllid
[19:58] <rick_h_> 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] <rick_h_> 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] <robbiew> huh?
[20:09] <robbiew> rick_h_: 
[20:09] <robbiew> what bug?
[20:09] <rick_h_> robbiew: http://jujugui.wordpress.com/2014/04/30/juju-quickstart-1-3-2-released/
[20:09] <rick_h_> robbiew: looking for the number
[20:10] <rick_h_> https://bugs.launchpad.net/juju-quickstart/+bug/1309455 robbiew 
[20:10] <_mup_> Bug #1309455: The auto-generated local env does not work in trusty <juju-quickstart:Fix Released> <https://launchpad.net/bugs/1309455>
[20:10] <robbiew> ooohhhhh
[20:10] <rick_h_> robbiew: we just fixed quickstart during the sprint and just got back
[20:10] <rick_h_> we were going to ping soon to work on seeing about 1.3.2 into trusty as a bugfix update 
[20:11] <rick_h_> frankban is out today as swap but should be back tomorrow. We fixed a couple of bugs
[20:11] <rick_h_> 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] <robbiew> rick_h_: sorry...this isn't my bug
[20:12] <robbiew> oh...nevermind
[20:12] <robbiew> now I remember
[20:13] <rick_h_> 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] <robbiew> sounds good
[20:14] <rick_h_> 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 <deploy> <local-provider> <lxc> <juju-core:Fix Released by wallyworld> <juju-core 1.18:In Progress by jameinel> <juju-quickstart:Fix Released by frankban> <https://launchpad.net/bugs/1306537>
[20:14] <robbiew> ack
[20:15] <rick_h_> 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] <robbiew> I have no idea
[20:17] <robbiew> rick_h_: lol
[20:17] <rick_h_> robbiew: oh :) nvm then. 
[20:17] <robbiew> rick_h_: just ask marco
[20:17] <rick_h_> lol wrong robbie my bad
[20:18] <robbiew> yeah...that's what I quickly figured
[20:18]  * rick_h_ remembers robie has one b
[20:18] <rick_h_> sorry about the confusion
[20:18] <rick_h_> so yea, use 1.3.2 for the moment and we'll work with rbasak to get trusty updated asap
[20:18] <robbiew> 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] <rick_h_> 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] <robbiew> ack
[20:20] <hatch> jujugui who wrote the machine-token.js file?
[20:20] <hatch> originally that is
[20:20] <rick_h_> hatch: huw maybe
[20:20] <rick_h_> hatch: either huw or kadams, I can't recall atm
[20:21] <rick_h_> hatch: any reason you're hunting?
[20:21] <hatch> it's expecting a hardware object in the render cycle and it fails if that's not provided
[20:21] <hatch> I was wondering if that was intentional or if it's a bug
[20:22] <rick_h_> hatch: probably a bug in that it was written aroud current data 
[20:22] <hatch> 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] <rick_h_> so it was probably just a way to get it working and viewable vs thorough
[20:22] <hatch> ok I'll put in a || for now 
[20:22] <rick_h_> hatch: yea, I mean the tokens are just UI starts to build on, all of them
[20:22] <hatch> ok sounds good
[20:39] <rick_h_> woot, nuc, drives, and ram ordered with gigabit vlan switch
[20:40] <hatch> haha nice
[20:41]  * rick_h_ wonders if he can get a second IP from ATT Uverse
[20:43] <hatch> it'll probably be $100/mo
[20:43] <hatch> lol
[20:48] <rick_h_> doh, bit by CC thinking it's fraud
[20:49] <hatch> you're such a criminal
[20:49] <hatch> kehehe
[20:54] <hatch> yay jcsackett 's branch finally landed heh
[20:54] <hatch> poor CI
[21:01] <hatch> I'm going to go lie down for a bit, I'll finish up the day later
[21:22] <Makyo> 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] <Makyo> rick_h_, what NUC did you get?
[21:44] <rick_h_> Makyo: http://www.newegg.com/Product/Product.aspx?Item=N82E16856102052 
[21:44] <rick_h_> Makyo: right now working with ATT to get multiple IP addresses on my account
[21:45] <rick_h_> goal is to setup the 3 nuc and switch on their own network for folks to use
[21:45] <Makyo> Oh, rock on
[21:46] <rick_h_> 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] <rick_h_> as maas is the first network target especially
[21:48] <Makyo> Yeah, for sure
[22:05] <Makyo> Ducking out to get the dog to the vet.  She cut her paw on something.
[22:08] <rick_h_> ruh roh, good luck!
[23:08] <huwshimi> Morning
[23:14] <hatch> morning huw
[23:14] <hatch> I see you're still alive :)
[23:15] <hatch> I made a comment on your branch, let me know if you have any questions about it
[23:17] <huwshimi> hatch: Thanks! Makes sense :)
[23:17] <hatch> excellent