#juju-gui 2013-05-06
<hatch> jujugui hello all
<Makyo> bcsaller_, if it's any help, the subordinate indicator won't ever really be a problem because, outside of the simulator, subordinates are always reported with 0 units :P
<Makyo> bcsaller_, http://craftyjs.com/
#juju-gui 2013-05-07
<hatch> BradCrittenden, yes it's the chrome differences between the browsers is what is causing the differences
<Makyo> bac https://www.destroyallsoftware.com/talks/wat
<bcsaller> no one appears to be in 210 either, not sure where I should be
<m_3> sinzui: http://bazaar.launchpad.net/~charmers/charm-tools/trunk/view/head:/scripts/promulgate
<m_3> three methods...
<m_3> line 151
#juju-gui 2013-05-08
<rick_h_> luca: https://bugs.launchpad.net/juju-gui/+bug/1173259
<_mup_> Bug #1173259: Ubuntu font does not appear in chrome v21.x.x.x and Mac OSX 10.5.8 <charmbrowser> <juju-gui:In Progress by rharding> <https://launchpad.net/bugs/1173259>
#juju-gui 2013-05-09
<frankban> hatch: http://ec2-54-224-53-183.compute-1.amazonaws.com/
<kapil_> bcsaller, http://labs.umbrella.com/2013/03/06/announcing-sodium-a-new-cryptographic-library/
<Makyo> hatch, https://codereview.appspot.com/9153044/
<hatch> thanky
<Makyo> bcsaller, http://jujugui-code-docs.s3-website-us-east-1.amazonaws.com/openstack.json
#juju-gui 2013-05-10
<Makyo> James is sending me dog pictures.  They're pretty cute, so here: http://ubuntuone.com/gallery/56atUQ5IHr3CkOXeT605zL/baroomf.jpg
<Makyo> bcsaller, http://jujugui.wordpress.com/2013/05/10/cloud-sprint-13-05-work/ I really glossed over some stuff, maybe worth a comment or something?
<bcsaller> reading
<bcsaller> guess its too soon to talk about import/export
<bcsaller> snap to grid is working locally, we can backport that pretty easily
<Makyo> bcsaller, Yeah.  I think maybe a separate post/comment about prototyping.
<bcsaller> makes sense
<bcsaller> Makyo: IE support is too limitedfor what I was talking about before, need a plugin it looks like to really pull it off, so no
<Makyo> bcsaller, Ah, boo :/  At least we still can move forward on better modeling.
#juju-gui 2014-05-05
<jcsackett> morning, all.
<rick_h_> party
<rick_h_> jujugui please update the kanban board with what got done (even if not on the board) and where things are at today
<jcsackett> how many of us are actually working today?
<rick_h_> jcsackett: well the only request for swap day I got was from frankban
<rick_h_> jcsackett: so I have no idea 
<jcsackett> rick_h_: dig.
<kadams54> rick_h_: for this new search header view that I'm working on, should I keep it in the subapp/browser space?
<rick_h_> kadams54: yes
<kadams54> Or do we want that to go away?
<kadams54> kk
<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
<rick_h_> ccccccbtujivddegtrcuebbulfrhrjkfngkbjireglbe
<redir> cat
<hatch> dog
 * hatch is sick
<rick_h_> doh
<hatch> stupid sick people traveling
<rick_h_> double doh
<rick_h_> redir: did you get the leankit email?
<rick_h_> redir: looks like you did. You should have full access to the board now https://canonical.leankit.com/Boards/View/102529849 
<redir> rick_h_: yup. but no permissions on the boards yet
<rick_h_> redir: let me know if you want to hangout pre call to get a run down of the board
<redir> OK. Just tried creating a card but didn't have permissions.
<rick_h_> yea, just updated it
<rick_h_> you should be full user now
<redir> k
<redir> card created
<redir> rick_h_: can I get a rundown of the board tomorrow morning?
<rick_h_> redir: sure thing
<rick_h_> redir: it uses gravatar for the head pics on the cards
<redir> OK. I'll find a good headshot
<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
<rick_h_> hatch: k, will do
<jcsackett> juju-gui: call in 4 minutes, i suppose.
<jcsackett> (hope i'm not stepping on toes there, but hadn't seen a warning)
<rick_h_> oh yea, jujugui call in 4 :)
<rick_h_> no -
 * rick_h_ is heads down atm and missed it and makyo normally catches it
<rick_h_> speaking of which
<Makyo> Sorry, late morning.
<rick_h_> hah it's all good. I think all of us are moving a bit slow today
<rick_h_> I'm still recovering form that 2.5mi hike to the sharks on friday
<rick_h_>  /form/from
<hatch> haha
<jcsackett> jujugui: going to be a moment late, i've misplaced my earphones when unpacking.
<rick_h_> redir: joining or are you on the train? 
<rick_h_> https://plus.google.com/hangouts/_/canonical.com/daily-standup?authuser=1
<rick_h_> jcsackett: I don't see you at all 
<jcsackett> rick_h_: you don't see me at all, like in canonicaladmin? b/c i can verify curtis is getting my expenses.
<rick_h_> jcsackett: right, you're not listed on my team in canonical admin
<jcsackett> rick_h_: right...so do i need to complain to P&C, or do you?
<rick_h_> jcsackett: writing the email now. don't worry about it
<jcsackett> rick_h_: cool, thanks.
<hatch> P&C sounds like a big corporate conglomerate 
<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 
<Makyo> rick_h_, oh, okay.  I was going to see if a state was possible, then fall back, but that may be overthinking it.
<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.
<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) 
<rick_h_> jcsackett: ok, well just saying we've had conversations so there's some background
<jcsackett> rick_h_: dig. just didn't want there to be any false hope of work already done. :)
<rick_h_> lol
<Makyo> Sounds good, I'll head in that direction.
<hatch> is this the part where we need to check if the inspector urls are valid, if they aren't then show the charmbrowser/
<rick_h_> hatch: yes, that's the idea. 
<hatch> oh, and having a section validator pre dispatching is not going to work?
<rick_h_> I think that's kind of the idea. To whitelist first before trying to do a bunch of stuff and then failing
<hatch> ahh - I was thinking that because each section had such different requirements that it would validate each section individually
<rick_h_> yea, but then it's hard to maintain and find out why something failed imo
<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 
<hatch> so you're thinking: URL parse to state > validate parsed state > dispatch ?
<rick_h_> hatch: yep
<rick_h_> hatch: at least it's the discussion I'd like to have :)
<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.
<hatch> and then dealing with them 1:1
<rick_h_> hatch: right but there's a point where state is parsed before dispatch right?
<rick_h_> so a single call through some validation bits to say "oh, a charmbrowser state with metadata XX is invalid in this case"
<hatch> no it goes from the url into state, then the state is only parsed in the dispatchers
<hatch> it's "dumb" until the dispatchers
<rick_h_> ah well then sucky. Maybe we can at least force a common api?
<rick_h_> all dispatchers have a single parse/validate the state bit?
<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
<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 
<rick_h_> it's too spread out how you get from url to called views
<rick_h_> hatch: right
<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.
<rick_h_> jcsackett: k, yea I had hoped to make it state's job
<rick_h_> but sounds like it's not possible
<rick_h_> because at the state time, it could be changed quickly and easily
<hatch> well this wuld be in state
<jcsackett> rick_h_: not sure what you mean--validate/dispatch is in state. 
<rick_h_> then the state is only parsed in the dispatcher
<rick_h_> is the quote hatch said
<hatch> the url is parsed into sections, which make up the state, then the dispatcher runs through those sections and calls the handlers
<hatch> the validation needs to happen pre dispaching
<rick_h_> ok, sounds perfect then
<jcsackett> "the dispatcher" here being a dispatch method.
<hatch> yes
<hatch> jcsackett so sounds like the original plan is still the right direction.....agree?
<jcsackett> hatch: sounds very similar, yeah.
<hatch> col
<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 
<hatch> cool
<hatch> rick_h_ yes in the state module for sure
<rick_h_> hatch: cool, then /me gets out of the way and carries on :)
<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.
<Makyo> ccccccdiltnnfvenndnvnrcddkedfhlebjlnvernfcge
<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
<Makyo> By which I mean thanks, jcsackett 
<rick_h_> hatch: yes
<hatch> Makyo lol
<jcsackett> Makyo: i figured that's what you meant. :)
<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
<hatch> that would be awesome
<rick_h_> hatch: will do, added a card for me to do that today. 
 * rick_h_ is going to go afk to go yell at the car dealer
<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.
<jcsackett> it's not much, but it's code towards the long spiel rick_h_, hatch and i just had. :p
<hatch> rick_h_ gl :)
<jcsackett> hatch: i think i've addressed all your comments etc in my PR.
<hatch> cool I'll take a look and QA
<hatch> most were pretty trivial
<hatch> jcsackett tests are failing fyi
<jcsackett> hatch: well, test-server is blowing up--i can't reproduce anything locally. :/
<hatch> jcsackett doh
<hatch> jcsackett when rick_h_  returns we will need to get him to killall the process
<hatch> it'll be broken until then
<jcsackett> hatch: fun times. well, are you happy with the PR, tests aside?
<hatch> very likely, just going through still
<hatch> jcsackett somewhat related - do we ever want to explicitly clear out the `flash` ATTR as well as the state one?
<hatch> or do you think it's ok for the ATTR to hang around populated
<jcsackett> hatch: i don't follow..."as well as the state one"
<jcsackett> there's only a state ATTR.
<jcsackett> or do you mean on metadata as well?
<jcsackett> or am i just completely misreading you? :p
<hatch> haha
<hatch> ok so you reset the `flash` property on the state object
<hatch> but there is also a `flash` ATTR on the state instance
<hatch> which is only ever overwritten 
<hatch> never reset
<hatch> jcsackett oh wait NM
<hatch> ignore everything I Just said
<hatch> I thought this https://github.com/juju/juju-gui/pull/271/files#diff-49f77193fff0d5a96b555595ed918791R126 was resetting the state object's property
<hatch> jcsackett I created a few more comments for the tests. I'm QA'ing now
<hatch> jcsackett you might want to hold off pushing the final version to the PR until CI is reset
<hatch> else you'll have to trigger it all manually
<hatch> http://store.steampowered.com/app/244830/ python IDE on steam?
<Makyo> Oh, that's kinda neat!
<redir> what is the bzr equiv of git pull upstream?
<Makyo> jujugui ^^^
<Makyo> (I don't remember, unfortunately)
<hatch> hmm - I always just pulled to update that branch then merged in
<hatch> sorry I'm no help either
<hatch> redir btw - in your irc client add `jujugui` and `guihelp` as notification targets
<Makyo> I mean, you can bzr merge lp:<project>/trunk, I think, but don't know if that's best practice
<hatch> sorry for dinging everyone :)
<hatch> Makyo yeah that's what I always did heh
<redir> thanks
<redir> Cory Booker is sitting across the aisle from me on the train...foranyone who follwos that kind of stuff
<Makyo> Sometimes, I forget that I have the xkcd substitution extension running in Chrome...
<redir> Makyo: there's probably an appropriate strip for that
<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."
<hatch> I also had to google him
<redir> awesome
<hatch> and rofl Makyo 
<hatch> haha
<hatch> I didn't think anyone cared about politics until someone does something that's ok unless a politician does it
<Makyo> https://chrome.google.com/webstore/detail/xkcd-substitutions/jkgogmboalmaijfgfhfepckdgjeopfhk
<rick_h_> hatch: jcsackett looking at ci
<hatch> thx
<hatch> what was the result of the burningoilness ?
<rick_h_> hatch: jcsackett process killed
<rick_h_> hatch: just took it in, sitting here waiting now
<rick_h_> hatch: I expressed my displeasure
<hatch> ahhh - what kind of car?
<rick_h_> hatch: outback
<hatch> bugatti veyron ?
<hatch> :P
<hatch> ahh, does it only puff the smoke on startup?
<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
<rick_h_> this time I think they believe me
<hatch> ahh
<hatch> good thing is that subies are easy to fix
<hatch> I used to have an 01 WRX 
<hatch> with like 250,000km on it haha
<rick_h_> yea, I'm bummed we're having this at 65k mi
<rick_h_> my last one didn't have issues until closer to 100k mi
<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
<hatch> hopefully
<rick_h_> yep
<hatch> http://varianto25.com/ <--- yes yes yes
<redir> highlights set, thanks hatch 
<hatch> np
<hatch> rick_h_ do we have any code atm which takes an unplaced-unit and makes it a placed-unit ?
<hatch> ^ jujugui
<rick_h_> hatch: the api calls are there to create machines and containers. 
<hatch> right, but it looks like everything just creates a new unit via add_unit
<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)
<rick_h_> hatch: so no, this is the glue stuff we need to start now that we can show tokens at all three levels
<rick_h_> unplaced, machine, and container
<hatch> hmm ok
<rick_h_> we should have UI and such for all three now
<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
<rick_h_> well placed means a machine or container
<rick_h_> so the code is two fold, one to create a changeset to add machine or container
<rick_h_> and two, to remove the unplaced unit token and create a new machine/container token
<rick_h_> or am I missing your point on this slow minded monday of mine?
<hatch> well a unit != machine/container token
<rick_h_> it does once placed?
<rick_h_> well, it'll either update a machine or container token
<rick_h_> or become one
<hatch> I think you're mixing UI state with env state
<hatch> for example
<hatch> say I create 10 unplaced units
<rick_h_> hatch: right, but env state should be a ghost machine/container, ghost service, ghost unit
<hatch> those units are now in the db without a 'machine' value
<hatch> now once the user drags that unit to a machine/container
<hatch> we need to update that model....or delete it and create a new one
<hatch> I'm wondering if that code exists
<rick_h_> no, that code does not exist
<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
<rick_h_> hatch: ok
<hatch> I'll fire an email to frankban as he will certainly have some input on the 'placement' implementation
<rick_h_> yea, I want to sit down a group to go through the db talk we started in vegas
<rick_h_> the whole tracking units through both machines/containers and services
<hatch> yeah...can we do that....say wednesday hopefully I'll be better by then :)
<rick_h_> yea, all good
<rick_h_> I think that fits into your question a bit though
<rick_h_> because placing a unit it sticking it in the right part of the db referenced by the other super objects
<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
<rick_h_> right
<rick_h_> rogpeppe: you around today or swap day-ing it?
<jcsackett> rick_h_: i see a card about browser.js needing to instantiate inspector views--i think we're already doing that now?
<jcsackett> rick_h_: see various create*InspectorView functions.
<rick_h_> jcsackett: yes
<rick_h_> jcsackett: I didn't move it as the work is in progress like the local ones
<jcsackett> ah, so i can move it along with my local card?
<rick_h_> jcsackett: sure thing, sounds ok to me
<jcsackett> since i think that's the only WIP regarding that.
<jcsackett> ok.
<jcsackett> hatch: that sound right? all inspectors now being done in browser? ^
<hatch> reading back...
<hatch> correct
<jcsackett> awesome.
<hatch> after your card they are all moved
<rogpeppe> rick_h_: today is a public holiday
<rick_h_> rogpeppe: ah, cool then
<rogpeppe> rick_h_: tomorrow i'm swap daying it
<rogpeppe> rick_h_: then i'm on holiday :-)
<rick_h_> oh right cool
<rogpeppe> rick_h_: will be back on 22nd May
<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
<rogpeppe> rick_h_: great, that will be useful
<rogpeppe> rick_h_: really looking forward to getting going on all of this stuff.
<rick_h_> rogpeppe: same here :) I'll add you to the internal list for our stuff and send some notes there
 * rogpeppe goes back to his mojito
<rick_h_> enjoy!
<hatch> rick_h_ I've finished my shutdown holidays and expenses 
<rick_h_> hatch: k, got the holidays in. Will go through expenses. 
<hatch> cool
<rick_h_> jcsackett: if you get yours into landing can you peek at huw's pull request and QA please?
<hatch> is May 19th a holiday in the US? National Patriots Day?
<hatch> rick_h_ jcsackett  I already did, he needs some slight refactoring first
<rick_h_> hatch: ah ok thanks
<hatch> when he gets in tonight I'll guide him through the implementation
<rick_h_> hatch: no, there's memorial day the 26th
<rick_h_> for the US
<hatch> ahh one week later
<rick_h_> hatch: rgr
<hatch> jcsackett lint error failure in your branch
<hatch> :)
<rick_h_> hatch: he might not be around tonight
<rick_h_> travel and all that
<hatch> ohh ok, np, well when he does
<hatch> I'm going to take lunch
<rick_h_> hatch: have fun
<rick_h_> bah, car seal goes boom!
 * rick_h_ gets ready to get driven home from car dealer. back online later on
 * rick_h_ is back
<hatch> rick_h_ which seal
<hatch> ?
<rick_h_> some front engine seal
<rick_h_> looks like it was coming down into the oil pan
<hatch> ahh yeah - that one might be pricy to fix
<rick_h_> showed me the leak but don't know enough about cards to name the bits
<rick_h_> yea, $1k
<rick_h_> new timing belt along for the ride wheee
<hatch> yeah sounds about right
<hatch> :/ cars
<rick_h_> hey, I wanted to pay it off before major work, mission accomplished
<rick_h_> $1k is like 2 car payments so if it goes a year after this we're all good :)
<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
<Makyo> Excellent use of canvas: http://www.georgeandjonathan.com/
<rick_h_> yea, that was cool
<hatch> heh vwry cool
<jcsackett> rick_h_: can you kick CI again? it's still doing the server death thing.
<hatch> jcsackett was there a hanging run?
<rick_h_> jcsackett: well, it's a different error
<hatch> that you killed manually
<rick_h_> jcsackett: I'm looking now
<rick_h_> ReferenceError: Can't find variable: YUI
<rick_h_> and connect.multipart() will be removed in connect 3.0 connect.limit() will be removed in connect 3.0
<hatch> Error: listen EADDRINUSE
<hatch> it's the same....looks like it just got further before crashing
<rick_h_> hatch: in the latest? #859?
<hatch> http://ci.jujugui.org:8080/job/juju-gui/859/console
<rick_h_> oh it is, wtf
<hatch> yup
<hatch> I don't see any manually killed runs, so I'm not sure how that got broken
<hatch> maybe we should add a killall in the start of our script?
<rick_h_> hatch: yea, there's supposed to be a catch 
<rick_h_> hatch: jcsackett ok, try again killed
<rick_h_> I think I missed a process last itme I ssh'd my bad
<rick_h_> there were two I needed to kill I think
<rick_h_> only got the one
<rick_h_> jcsackett: if it runs ok on your end just :shipit:
 * rick_h_ makes a card in on deck to update to sauce connect 3.0
<rick_h_> dimitern: hey, do you know what you were ordered for nuc/switch? 
<rick_h_> dimitern: I want to get a setup here as well and haven't heard back yet on what the standard is
<dimitern> rick_h_, hey
<dimitern> rick_h_, i'm yet to see dustin and take the nucs + switch
<dimitern> rick_h_, i'll let you know when i have them
<rick_h_> dimitern: ok cool. If you think about it, would love to see what models and such
<rick_h_> dimitern: ty much
<hatch> rick_h_ thinking for a home test box?
<dimitern> rick_h_, not quite sure about the models as dustin had them ordered - for the nucs
<rick_h_> hatch: yea, I want to setup a MAAS test env here at the house
<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
<hatch> coolio
<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
<hatch> oh that would be sollllid
<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
<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
<robbiew> huh?
<robbiew> rick_h_: 
<robbiew> what bug?
<rick_h_> robbiew: http://jujugui.wordpress.com/2014/04/30/juju-quickstart-1-3-2-released/
<rick_h_> robbiew: looking for the number
<rick_h_> https://bugs.launchpad.net/juju-quickstart/+bug/1309455 robbiew 
<_mup_> Bug #1309455: The auto-generated local env does not work in trusty <juju-quickstart:Fix Released> <https://launchpad.net/bugs/1309455>
<robbiew> ooohhhhh
<rick_h_> robbiew: we just fixed quickstart during the sprint and just got back
<rick_h_> we were going to ping soon to work on seeing about 1.3.2 into trusty as a bugfix update 
<rick_h_> frankban is out today as swap but should be back tomorrow. We fixed a couple of bugs
<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
<robbiew> rick_h_: sorry...this isn't my bug
<robbiew> oh...nevermind
<robbiew> now I remember
<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
<robbiew> sounds good
<rick_h_> robbiew: https://bugs.launchpad.net/juju-quickstart/+bug/1306537 is the other one I think
<_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>
<robbiew> ack
<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?
<robbiew> I have no idea
<robbiew> rick_h_: lol
<rick_h_> robbiew: oh :) nvm then. 
<robbiew> rick_h_: just ask marco
<rick_h_> lol wrong robbie my bad
<robbiew> yeah...that's what I quickly figured
 * rick_h_ remembers robie has one b
<rick_h_> sorry about the confusion
<rick_h_> so yea, use 1.3.2 for the moment and we'll work with rbasak to get trusty updated asap
<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
<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
<robbiew> ack
<hatch> jujugui who wrote the machine-token.js file?
<hatch> originally that is
<rick_h_> hatch: huw maybe
<rick_h_> hatch: either huw or kadams, I can't recall atm
<rick_h_> hatch: any reason you're hunting?
<hatch> it's expecting a hardware object in the render cycle and it fails if that's not provided
<hatch> I was wondering if that was intentional or if it's a bug
<rick_h_> hatch: probably a bug in that it was written aroud current data 
<hatch> well, either way it's a bug, I'm just trying to figure out if it's the machine-token or the database
<rick_h_> so it was probably just a way to get it working and viewable vs thorough
<hatch> ok I'll put in a || for now 
<rick_h_> hatch: yea, I mean the tokens are just UI starts to build on, all of them
<hatch> ok sounds good
<rick_h_> woot, nuc, drives, and ram ordered with gigabit vlan switch
<hatch> haha nice
 * rick_h_ wonders if he can get a second IP from ATT Uverse
<hatch> it'll probably be $100/mo
<hatch> lol
<rick_h_> doh, bit by CC thinking it's fraud
<hatch> you're such a criminal
<hatch> kehehe
<hatch> yay jcsackett 's branch finally landed heh
<hatch> poor CI
<hatch> I'm going to go lie down for a bit, I'll finish up the day later
<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.
<Makyo> rick_h_, what NUC did you get?
<rick_h_> Makyo: http://www.newegg.com/Product/Product.aspx?Item=N82E16856102052 
<rick_h_> Makyo: right now working with ATT to get multiple IP addresses on my account
<rick_h_> goal is to setup the 3 nuc and switch on their own network for folks to use
<Makyo> Oh, rock on
<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
<rick_h_> as maas is the first network target especially
<Makyo> Yeah, for sure
<Makyo> Ducking out to get the dog to the vet.  She cut her paw on something.
<rick_h_> ruh roh, good luck!
<huwshimi> Morning
<hatch> morning huw
<hatch> I see you're still alive :)
<hatch> I made a comment on your branch, let me know if you have any questions about it
<huwshimi> hatch: Thanks! Makes sense :)
<hatch> excellent
#juju-gui 2014-05-06
<rick_h_> morning frankban 
<frankban> hi rick_h_, how are you doing
<rick_h_> frankban: good, sleepy 
<rick_h_> I've got a dr apt in 2hr but hopping in for a bit 
<frankban> rick_h_: yeah, me too, woke up at 5 this morning
<frankban> rick_h_: I filed the expenses
<rick_h_> frankban: saw that thanks. 
<rick_h_> frankban: I think rbasak started the bug stuff for quickstart. Robbie (big Robbie head of CDO) hit our quickstart issues and filed a new bug yesterday
<rick_h_> frankban: there's another person that wants to be notified once it lands I added to the card because he was trying to demo it to customers
<frankban> rick_h_: yes I saw bug 1306537 now has distro quickstart in it
<_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> <juju-quickstart (Ubuntu):New> <juju-quickstart (Ubuntu Trusty):New> <https://launchpad.net/bugs/1306537>
<rick_h_> frankban: cool, yea so if you can work with rbasak as far as what we need to do to get that uploaded that'd be great
<rick_h_> and we will spread the word once it's avaiable via an apt-get update for folks
<frankban> rick_h_: pinged him this morning, maybe he's not yet available, will ping him again after lunch
<rick_h_> frankban: gotcha very cool then thanks
<rick_h_> frankban: oh and heads up. I ordered a 3 NUC setup and getting a multi-ip address internet service setup next week. 
<frankban> rick_h_: for MAAS?
<rick_h_> frankban: the plan is to put the NUC stuff on one external IP on its own network for MAAS testing of everything
<frankban> \o/
<rick_h_> bundles, quickstart, and it's the first target for networks support
<rick_h_> so will take me a couple of weeks to get setup and try it out, but will make that network available to the team
<frankban> rick_h_: very cool!
<rick_h_> yea, I'm looking forward to playing with it. The more stuff I see on MAAS the more I want to try it out myself :)
<rick_h_> but yea, so we'll schedule the quickstart updates towards the start of the cycle but will wait until I get that setup to work on maas support
<frankban> sounds good
 * frankban lunches
<bac> morning jujugui
<rick_h_> morning bac
 * bac expenses
 * rick_h_ heads off to doc appt biab all
<bac> rick_h_: let me know if you don't get my expense email.  unclear whether it went out or not.
<jcsackett> morning all.
<frankban> guihelp: is anyone available for reviewing https://github.com/juju/juju-gui/pull/273 ? thanks!
<kadams54> frankban: I can take a look
<frankban> kadams54: thank you
<jcsackett> jujugui: anyone free to review https://github.com/juju/juju-gui/pull/274 ?
<rick_h_> luca: ping, around?
<luca> rick_h_: yup
<rick_h_> luca: got a sec to chat?
<luca> sure
<luca> rick_h_: send me a link
<rick_h_> https://plus.google.com/hangouts/_/gr4so7qqrt4gi2frkqwf6opspua?authuser=1&hl=en luca 
<redir> rick_h_: you back?
<rick_h_> redir: yes
<rick_h_> sorry, back from doc
<redir> np you are stil gone on the calendar:)
<redir> wanna walk me through the board at 1030?
<rick_h_> sure thing
<redir> cool
<rick_h_> jcsackett: did you get a taker?
<jcsackett> rick_h_: not yet.
<jcsackett> it's very short.
<rick_h_> jcsackett: k, will try to look shortly
<jcsackett> rick_h_: ok.
<rick_h_> jcsackett: done with one note
<jcsackett> rick_h_: sensible comment. :p
<rick_h_> on a monday? never!
<rick_h_> oh right...it's tues...carry on
 * jcsackett laughs
<jcsackett> so, i did that cause i knew what was broken and it was a short fix--you want me to prioritize finishing il stuff or move into mv? i'm happy either way, just double checking priorities.
<jcsackett> rick_h_: ^
 * rick_h_ looks at the board
<rick_h_> jcsackett: so yea, we should focus on demo bits. Looking
<rick_h_> jcsackett: with francesco's work on the simulator you should be able to do the listing of known containers with tokens card?
<jcsackett> rick_h_: works for me.
<rick_h_> jcsackett: cool, frankban's branch hasn't landed but think it got an ok. 
<frankban> rick_h_: yes, it's landing now
<rick_h_> oh, it it just got shipit
<rick_h_> frankban: cool thanks
<rick_h_> jcsackett: so yea, maybe get a coffee and then that'll help you with that
<jcsackett> i'm always good with a plan that involves me getting coffee. :p
 * redir slurps on coffee
<rick_h_> jujugui call in 7
<hatch> I have completely lost my voice so I'll just listen 
<rick_h_> hatch: ruh roh
<rick_h_> time to get all the things landed hatch doesn't like!
<hatch> lol
<kadams54> SWEET
<jcsackett> rick_h_: call?
<rick_h_> oops
<jcsackett> Makyo: ^
<Makyo> jcsackett, on swap today, but if you give me a sec, I can join up.
<jcsackett> oh, no worries, didn't know you were out Makyo 
<jcsackett> i was just pinging everyone who wasn't there. i should probably double check the holiday list first, huh? :p
<rick_h_> frankban: https://plus.google.com/hangouts/_/gtxixiet6ihca2aqkckzubxldma?hl=en
 * rick_h_ goes to long long call afk for a bit
 * rick_h_ is back
<rick_h_> Makyo: or hatch either of you guys have time to help me out with something?
<rick_h_> jcsackett: around?
<hatch> rick_h_ what do you need? Sorry I missed the ding
<rick_h_> hatch: copied you on an email as an FYI
<rick_h_> hatch: and wanted to ping a reminder on Huw's stuff so he can move forward today
<hatch> sounds good, looking...
<rick_h_> hatch: originally I was trying to find some way to figure out how to get ant to do drag/drop work but the DB stuff around units isn't ready yet. 
<hatch> ahh
<hatch> yeah we might actually want to use yui DD module
<hatch> so much spam on G+ today
<hatch> http://blog.atom.io/2014/05/06/atom-is-now-open-source.html
<hatch> unfortunately it can't be used for private projects as it reports back to the home base with the file names that are opened
<rick_h_> that's a bit nuts
<hatch> https://twitter.com/FromAnEgg/status/463759577843240960
<hatch> yep
<rick_h_> jujugui have to run down to get the key for the car, oil leak fixed now. I'm out for a while. 
<hatch> enjoy!
<jcsackett> bloody hell, i've been disconnected all afternoon. sorry for missed pings, all.
<hatch> it's ok, we knows us slackin
<jcsackett> :p
<jcsackett> rick_h_: just acking i got your email with ant, happy to help him tomorrow.
<hatch> jujugui have you noticed that github no longer gives you the notification to create a pr on newly pushed branches?
<jcsackett> hatch: i have, but i started using hub which lets me kick off pr's from the command line.
<hatch> oh? got a link?
<jcsackett> https://github.com/github/hub
<hatch> thanks
<hatch> It's a pita to have to go into the web ui to make a pr
<jcsackett> agreed.
<hatch> ugh i hate being sick!
<bac> yay, spontaneous os reboot.  man that hasn't happened in a very long time.  bad os x.
<hatch> bac uh oh
<hatch> kernel panic?
<bac> dunno.  just suddenly went to the tastefully grey screen of death
<hatch> ahh yes that's osx's kernel panic screen
<hatch> that happens to me when I try and run two different vm engines
<bac> so much more soothing than windows blue
<hatch> parallels + virtual box for example
<bac> i've done that via vagrant
<bac> i just had vmware, no vagrant
<hatch> ahh yeh I'd see that vmware and vagrant would cause that
<hatch> I don't know how vm engines work but it seems like you can only run one engine at a time
 * rick_h_ is back for a little bit
 * redir committed fixed tests and is going to add one for ngrams
<rick_h_> redir: woot woot
 * redir thinks he should get input for api changes before guessing though
<redir> but stepping away for a minute now
<rick_h_> kadams54: looking to chat today or if you're EOD we can chat tomorrow when you start please
<huwshimi> Morning
<hatch> morning
<hatch> gw on that branch
<hatch> huwshimi thx for the reply....odd UI for the service tab eh?
<huwshimi> hatch: Thanks, I can see what the idea is, I think it will make more sense when the bar goes all the way across the screen
<huwshimi> at the moment it's a bit hard to see that that first tab is part of the bar
<hatch> yeah you might be right
<huwshimi> hatch: Happy for me to land that then?
<hatch> yep you had a :+1: and a QA OK so you can shipit
#juju-gui 2014-05-07
<rick_h_> huwshimi: your card ok? I wasn't sure if it's something we could tweak yet until other stuff landed
<huwshimi> rick_h_: It's fine so far. I have the basics working, just need to get all the update/add/remove bits changing the correct elements.
<rick_h_> huwshimi: ok cool
<frankban> luca: morning, do you have a link to a ghost relation wireframe?
<luca> Hi frankban, it should look like this: https://docs.google.com/a/canonical.com/file/d/0B7XG_QBXNwY1cjhIZnZXS3pxZG8/edit
<luca> frankban: a grey line with no status indicator in the circle
<frankban> luca: thanks, that's what I was looking for
<luca> frankban: great. I can get Spencer to output the assets if you need.
<frankban> luca: it would be nice, I just need the circle svg
<luca> frankban: ok, Iâll get him to send it over as soon as he can
<frankban> luca: thanks
<frankban> luca: abort! I was able to create the svg starting from an existing one
<luca> frankban: ah, nice, no worries
<frankban> luca: #e2e2e2 is almost invisible given the current GUI background
<frankban> luca: at least with my crappy external monitor. much better using the macbook screen
<luca> frankban: ok, thats the Ubuntu grey but Iâll have a word with Spencer to see if we can get something with more contrast.
<frankban> guihelp: I need one review and QA for https://github.com/juju/juju-gui/pull/275 ? Anyone? thanks!
<rick_h_> frankban: sure thing
<frankban> rick_h_: thanks
<bac> jcsackett: around?
<jcsackett> bac: ish.
<jcsackett> what's up?
<bac> jcsackett: no rush, when you get in fully would you look at https://codereview.appspot.com/91140045 ?
<jcsackett> bac: sure.
<frankban> rick_h_: thanks for the review!
<rick_h_> antdillon: morning, how are you getting along with my email?
 * frankban lunches
<antdillon> rick_h_, Morning, I am. Getting back up to speed
<rick_h_> antdillon: cool, let me know if you get stuck or have any questions. 
<antdillon> rick_h_, Will do thanks
<jcsackett> bac: lgtm, with a minor question.
<bac> there are no minor questions
<bac> no, wait, there are no dumb questions
<bac> jcsackett: i think what happened here is in an earlier version i was using the 'extra_data' to fill out the expected results, so i wanted it squirreled away separately.
<bac> jcsackett: so i can make the change you request easily and it'll be more readable.
<jcsackett> bac: awesome.
<redir> guihelp how does one troubleshoot bzr connections? 
<bac> redir: what's the prob?
<redir> I can't seem to push anything -- it hangs -- and -v doesn't display any more information
<kadams54> With powerful incantations and blood sacrifice
<kadams54> That's how
 * redir gets blood bowl and starts chanting
<redir> idea
<redir> found it...
<jcsackett> see, the blood bowl totally works.
<redir> nm 
<redir> heh
<redir> stale .ssh ControlPath entry
<redir> bac got a minute to talk about the ngram search interface?
<rick_h_> jujugui added a card to urget, found a big issue while trying to see where we are with machine view in a real lxc env today
<rick_h_> urgent bah
<rick_h_> heads up for folks looking for a new card soon
<redir> rick_h_: I don't have permission to add comments/edit the docs you sent me
<rick_h_> redir: sorry, sec
<redir> np
<rick_h_> redir: updated
<rick_h_> ok, so maybe that bug is my machine
<redir> tx
<rick_h_> jujugui can anyone try to reproduce my bug in urgent please? Now I can't click on a google doc and tried in FF and chrome so maybe my computer hates me
<kadams54> Checking
<frankban> rick_h_: trying
 * rick_h_ feels like his computer is possessed
<frankban> rick_h_: I am able move service blocks in LXC, with and without flags
<bac> jcsackett: i did this instead: http://paste.ubuntu.com/7410490/
<frankban> able to move even
<jcsackett> bac: ok, i can see the value of that as a way to isolate expected value. thanks for the changes.
<bac> redir: sorry, didn't see your message.  let me get my branch landed then let's talk, whatever
<bac> jcsackett: it is a better test...
<redir> bac: np, ping me when you are free...
<rick_h_> frankban: thanks deleting the card
<bac> redir: want to chat on G+?
<redir> sure
<redir> bac: gimme 5 minutes?
<bac> ok
<redir> bac: ready
<bac> redir: https://plus.google.com/hangouts/_/canonical.com/daily-standup
<hatch> morning
<rick_h_> morning
<hatch> I can talk today
<hatch> yay
<kadams54> guihelp: I know I've seen this test failure before, but can't remember what it means: "Error: Uncaught SyntaxError: Unexpected token C (http://192.168.33.10:8888/test/index.html:1)"
<kadams54> That ring a bell for anyone else?
<hatch> kadams54 run make lint
<hatch> it also seems like it can't serve that file
<hatch> if you open that file in chrome devtools you'll see why it's broken
<hatch> assuming you're running test server right now
<rick_h_> kadams54: an unmocked api request
<rick_h_> hatch: can you chat to antdillon on watching for changes to the ecs stuff please?
<rick_h_> or Makyo ^
<hatch> sure
<kadams54> hatch: lint run, still having problems
<antdillon> hatch, Thanks
<kadams54> rick_h: it's happening in the after each hook
<rick_h_> kadams54: well that just means that's when the api call responds or something. 
<kadams54> Yeah, I think you're right, looking for API callsâ¦
<rick_h_> kadams54: but the issue is the api response code trying to json decode something that isn't valid json which is what that error is from
<hatch> ugh this test suite...
<kadams54> I can see the error is bubbling out of a json-parse-debug.js
<rick_h_> kadams54: yep
<hatch> antdillon ok you can't listen for changes to the changeset
<hatch> (that was easy)
<hatch> next!
<hatch> :P
<antdillon> hatch, So polling the changeset?
<rick_h_> hatch: boooo, no ATTR to watch?
<hatch> antdillon yeah this appears to be an oversight in the design
<rick_h_> :(
<antdillon> hatch, rick_h_ lol
<hatch> should be pretty trivial to fix though
<hatch> do you want to tackle that as a separate branch first?
<rick_h_> hatch: antdillon +1
<antdillon> hatch, I can try get it in this branch if you know of another example
<hatch> It's out of scope of that branch
<hatch> it's quite a bit of changes
<hatch> basically everything that references the changeSet property needs to instead access an attribute
<hatch> OR
<rick_h_> hatch: just need the ECS to fire a change event? 
<hatch> you hook up to the changeSet property using out object.observe polyfill
<hatch> less custom events the better
<rick_h_> ok
<hatch> imho
<rick_h_> sure
<hatch> so....hmm lemme take a look
<hatch> the code is so much cleaner not having to get/set an attribute
<hatch> antdillon ever done anything with Object.observe() ?
<antdillon> hatch, Not really, how hard could it be :/
<hatch> Object.observe(ecs.changeSet, callback)
<hatch> not very :P
<antdillon> hatch, Cool
<hatch> haha yeah....you want to look into databinding.js
<rick_h_> no, no he doesn't
<hatch> and grep for `observe` and `unobserve`
<hatch> but ignore everything else
<hatch> it's magic in there
<antdillon> hatch, Got it
<hatch> antdillon basically the pollyfill polls the object :) 
<jcsackett> jujugui: nine minutes to call, yada yada.
<hatch> antdillon app/assets/javascripts/Object.observe.poly.js
<hatch> it's pretty thick, not much to see, but incase you were interested
<hatch> we should probably update our polyfill
<rick_h_> hatch: it's a slack card already
<hatch> oh cool
<hatch> there has been a ton of work done to the Polymer one
<rick_h_> yep
<antdillon> hatch, Will take a look
<rick_h_> antdillon: you're welcome to join https://plus.google.com/hangouts/_/canonical.com/daily-standup?authuser=1
<rick_h_> at the top of the hour for stand up
<hatch> antdillon so this is just my preference because the code is so much cleaner not using attributes - if you run into any big issues feel free to let me know and we can revisit switching changeSet to an attribute
<rick_h_> jujugui call in 1 
<hatch> rick_h_ the blues docs that you shared are not editable fyi
<rick_h_> hatch: k, will look. Thought I gave edit there
<hatch> haha, blues... redir 
<rick_h_> oh, can edit folder but not docs boo google 
<hatch> heh, hyper specific ACL
<rick_h_> Makyo: hatch redir call time
<antdillon> hatch, You in the units in db call?
<hatch> I am 
<antdillon> hatch, Let me know when your free for a hand on this observe stuff please
<hatch> will do
<hatch> antdillon done
<antdillon> hatch, Think I got it
<hatch> nice
<rick_h_> kadams54: want to pair up now?
<kadams54> Yup
<kadams54> Working on a PR
<rick_h_> kadams54: cool, setup a hangout when you're ready and linky me
<rick_h_> jujugui marked the unit db list card as critical and top of the lane 
<kadams54> rick_h_: https://plus.google.com/hangouts/_/7acpjs4qa80af83u7shrgk05eg?authuser=2&hl=en
<hatch> jcsackett got what you need from that diff img?
<jcsackett> hatch: yup.
<rick_h_> guihelp in running tests I see a ton of "Error: Invalid value for <g> attribute transform="translate(NaN,NaN)" 
<rick_h_> this was related to the error I noticed in QA today
<rick_h_> anyone remember seeing or can dupe that?
<Makyo> Trying now..
<frankban> uhm, so this is confusing, it seems models.js:ServiceUnitList.process_delta already has the code to update both "this" (the units model list itself) and service.get('units')... 
<frankban> rick_h_: ^^^ so maybe something from the past. anyone remember if in the initial impl we had a top level unit list?
<rick_h_> frankban: so we already have a units list? I didn't see it inspecting the db
<Makyo> rick_h_, I'm seeing it in test-server. investigating quiickly.
<rick_h_> Makyo: hmm, I had it in test server. Maybe my system is possessed today
<rick_h_> Makyo: latest trunk?
<Makyo> rick_h_, yeah, that's where I'm seeing it.
<rick_h_> frankban: yea, no idea. I'm actually newer to the db and not sure of its history. 
<rick_h_> Makyo: oh sorry, you did see it
<rick_h_> Makyo: misreading, who put monday in my wed
<frankban> rick_h_: no, we don;t have a top level unit list, but the process delta seems to assume we have it. so basically we are calling _process_delta twice on the same model list. trying to confirm
<rick_h_> frankban: heh, well we're half way there then :)
<frankban> heh :-)
 * rick_h_ runs for food stuff before next meeting
<bac> redir: sorry, meant to ask that question over here.
 * bac lunches
<bac> redir: over here, over here!
<bac> redir: if it works, please 'bzr add' it to your branch
<bac> redir, ok if not this branch, then share it somehow
<redir> bac: I am in a maze of twisty little passages, all alike....
<redir> I didn't complete it. I got as far as importing a couple things and looking for the necessary bits. 
<redir> but decided that it wasn't trivial and was sorting socks instead of working on the actual card
<redir> bzr makes me feel like a ten left thumbed person
<hatch> anyone available for a review?
<rick_h_> hatch: I can in about 5 if you need
<hatch> ok just writing docs right now
<hatch> jujugui https://github.com/juju/juju-gui/pull/277 whoever is available for a review/qa
<rick_h_> hatch: hit a conflict against trunk, please make sure to rebase off develop
<hatch> doh
<rick_h_> small simple one
<hatch> rick_h_ fixed
<hatch> github thinks I did these commits 6 days ago heh
<hatch> I must have broken something in the rebase
<hatch> doh lint
<hatch> and I just ran it too
<hatch> so when I booted up my computer today, refind wasn't there, and neither was grub
<hatch> :/
<rick_h_> hatch: you did a osx upgrade?
<rick_h_> hatch: every time it upgrades I have to reinstall refind
<rick_h_> and then it's all back
<hatch> I did some updates 
<rick_h_> yea
<hatch> ohh
<hatch> sonofa
<rick_h_> rerun the refind install.sh and you'll be fine
<hatch> ahh cool cool
<hatch> osx is a tricky bugger
<rick_h_> it doesn't like the parasite os on there
<redir> refind?
<rick_h_> redir: let's you setup a boot manager to run ubuntu on apple hardware
<hatch> http://www.rodsbooks.com/refind/
<rick_h_> hatch: comments done, a few questions. Let me know if you want to chat on them. Will start QA
<hatch> cool looking
 * rick_h_ runs away before he can read them
<rick_h_> does qa from the camper in the driveway
<hatch> haha, it's still too cold here for normal camping
<hatch> does your camper have a heater?
<rick_h_> I think we've had our last frost warning to trying to get out for mother's day weekend
<rick_h_> oh yea, propane furnace
<rick_h_> and electric heating pads for the bunk ends
<rick_h_> since the tent ends get a bit chilly at night
<rick_h_> lol qa'ing this with the simulator turned on is nuts :P
<hatch> yeah it's super broken hah
<hatch> that's why I bolded that comment :)
<rick_h_> Uncaught TypeError: Cannot read property 'add_unit' of undefined
<rick_h_> I think my comments in there that hit on this are valid though. 
<hatch> hmm when did you get that?
<rick_h_> hatch: after the simulator reset the thing 5 or so times and I finally got the numbers input and hit add units
<hatch> oh....well yeah, you need to turn the simulator off, the machine view panel is just blowing it all away
<hatch> I'm surprised more doesn't break
<hatch> :)
<rick_h_> well, let's shoot for less breakage even with the simulator :P
<hatch> well it's not the simulator, it's the rerendering of the panel 
<hatch> if you hack the machine panel view code to stop re-rendering then you don't run into any issues
<rick_h_> I thought that was in here?
<hatch> no that's what huw is working on
<hatch> the machine panel view listens to any change in the machine model, then re-renders everything
<rick_h_> hatch: right but why does the scale up widget need to listen to those?
<rick_h_> hatch: I think having those move from under the user would be a bit not-good
<hatch> it doesn't
<hatch> it's in the machine view
<hatch> so when the machine view gets re-rendered it re-renders the scale up view
<rick_h_> app/widgets/service-scale-up-view.js - line #70 in the diff
<hatch> yeah that's where it listens to re-render the service list if it gets updated
<rick_h_> right, but that seems bad UX imo, a user is there typing and stuff moves on them
<hatch> it doesn't if the machine view doesn't re-render
<hatch> that's what the _updateUI method does
<hatch> and why it's so funky
<rick_h_> ok, let's forget the machine view panel and just look at the life cycle of this new View
<rick_h_> it's init'd and rendered, part of that is binding to change events on the db.services.on()
<rick_h_> and if that changes, adds, removes, it updates the service list, which updates the UI
<rick_h_> all while the user is trying to enter a 3 into the 4th box...
<rick_h_> which is now the 5th box, or doesn't exist any more because of the change event from within the scale up view itself
<hatch> well if the service goes away then they can't scale it up anyways
<hatch> if the service is still there, it doesn't modify the UI
<hatch> so you'll still be focused and typing in the input
<rick_h_> that's horrible to users, and order it promised to never move the list on you? 
<rick_h_> if I'm entering in the 4th box and the 2nd one goes away?
<rick_h_> I don't think we can treat this widget as live updating. 
<hatch> You thought the other way in Vegas :)
<rick_h_> heh, well I think when you click on the + is needs to be live
<rick_h_> and when you close it/reopen it it's updated
<rick_h_> but only at interaction points 
<hatch> so what if they scale up a service which doesn't exist anymore?
<rick_h_> then we'll have to be smart and bring up a service
<rick_h_> or throw an error during the deploy confirmation step
<hatch> so now adding a unit deploys a charm?
<rick_h_> we've got places to confront the user without moving their UI around on them as they try to type
<hatch> :)
<rick_h_> we'll probably have to start with the confirmation error, we need that anyway in case of conflicting names/etc
<rick_h_> but yea, I should be able to say "oh I wanted a unit of that, sorry rick blew it away, I want it back"
<rick_h_> "rick doesn't need mysql any more but I sure do"
<hatch> then you need to go deploy it again the usual way
<hatch> having a scale up UI deploy charms is a little crazy
<rick_h_> ok, still. Regardless of the 'how' I think that once you put the form in front of the user you can't go moving it
<rick_h_> if you're entering a username someone just took, I don't delete your data entry, or delete the field. 
<rick_h_> I show you an error/message to help you resolve the issue
<hatch> and if a new service is deployed you want to mass scale up you have to click the X then the + again to see it?
<rick_h_> and then this code gets a lot simpler. It doesn't need to watch the db and such
<rick_h_> if you click + and someone adds a service you weren't planning on scaling it already anyway
<hatch> Iunno, I disagree 
<rick_h_> it wasn't there when you started, you might want to go back and scale that one up before you hit deploy on the bar, but you weren't planning on touching it at the moment you started your interaction
<rick_h_> how could you know it was there?
<rick_h_> going to be there I guess
<hatch> it's just odd that it'll be the only place in the UI that doesn't maintain env state
<hatch> the inspector unit list jumps around while you may be working on ti
<rick_h_> does the inspector config auto reload if someone does a service upgrade?
<rick_h_> right, and everyone hates that darn jumping unit list thing
<rick_h_> it's so hostile to users
<hatch> well, it's accurate 
<rick_h_> and this is a small interaction with very very limited env interaction. It's only giving you an option to do something based on a list. 
<rick_h_> hatch: sure it's accurate, doesn't make it nice to use
<hatch> I'll remove the binding stuff - but maybe the X should turn to a refresh button or something if the db changes
<rick_h_> hatch: hey, I'm all for getting other opinions. 
<hatch> it's not very intuitive if the user is living in the machine view and wants to mass scale up and there are no services in the list anymore
<rick_h_> hatch: I'm just sharing mine, I think the code can be simpler and easier to use without the event watching
<hatch> oh for sure
<rick_h_> if the users live in machine view I think we've failed imo
<rick_h_> but that's a different discussion
<rick_h_> which we can have in our upcoming 1-1 :P
<hatch> hah, well I'm totally confused of the direction of the new no-inspector UI 
<hatch> which may mean people live in there
<rick_h_> you and me both. Had a chat with luca bout that yesterday
<Makyo> jujugui quick review/qa: https://github.com/juju/juju-gui/pull/278
<hatch> I'm hoping he changed his mind? :)
<hatch> Makyo I think that your branch needs to redirect the user to the default of sectionA
<hatch> thoughts?
<hatch> so their url actually changes I mean
<rick_h_> +1 redir like we do for /fullscreen and such
<Makyo> Okay.
<rick_h_> to end up in a good place
<redir> wha?
<hatch> Makyo that may mean that it'll need to be done in the 'validator' which is yet to be written
<hatch> redir I think rick_h_  meant to say me or Makyo  :)
<rick_h_> redir: huh?
<Makyo> hatch, +1 on redirecting, but if the validator has yet to be written, that's outside the scope of this branch.
<rick_h_> oh redir as in short for redirct
<hatch> haha
<redir> :) 
<rick_h_> sorry, poor naming choice there redir :P
<redir> long running joke
<hatch> Makyo yeah, definitely, so would that mean this branch needs to be benched?
<hatch> Or land as-is and fix later?
<rick_h_> I guess, now I'm wondering...give redir a task it ends up on Makyo. like a fine waxed car
<hatch> lol
<Makyo> hatch, Either or. I'm loathe to have wasted time on it while things diverge further.  Can we add an XXX comment and land?
<hatch> yeah that should be fine
<bac> if robbie *just discovered* juju.academy does that mean he slept through the lightning talks?
<hatch> bac haha
<Makyo> Oh, neat, we actually got that URL.
<Makyo> Have it up on the book site now: http://book.exploring-juju.com/
<hatch> nice :)
<hatch> look at all you guys, being good juju community peoples
<alexpilotti> hi guys, is there a way to have a password field in the charmâs properties on the gui?
<hatch> alexpilotti do you mean the password for the GUI/
<alexpilotti> hatch: in a new charm, we need to specify among the properties a password
<hatch> oh ok, well atm that's just a typical field
<hatch> I'm guessing you want it to be a *** while you type?
<alexpilotti> hatch: the âservice settingsâ in teh GUI
<alexpilotti> hatch: yep, typical password edit field
<hatch> yeah, at the moment that's not supported but there have been some mumblings. Would you be able to file a bug requesting this feature?
<hatch> https://bugs.launchpad.net/juju-gui
<alexpilotti> hatch: sure
<hatch> thanks
<redir> bac: test_search.py:TestReindex.test_reindexed_no_client_charms deletes the non text index from the ini. Is that intentional?
<bac> redir: don't know.  let me look.
<alexpilotti> hatch: done: https://bugs.launchpad.net/juju-gui/+bug/1317228
<_mup_> Bug #1317228: Passwords fields should be supported in the charm service settings <juju-gui:New> <https://launchpad.net/bugs/1317228>
<alexpilotti> hatch: is there a way to hack this in a quick and dirty way? We just need it for a demo
<hatch> hmm
<hatch> lemme take a look
<bac> redir: i don't understand that test.
<redir> bac: me either
<rick_h_> alexpilotti: hatch this should be on juju. They need to support the idea in their config.yaml 
<bac> redir: but this is why es data all disappear...
<rick_h_> I guess it can be on both
<redir> bac Yes, AFAICT.
<alexpilotti> rick_h_: I agree
<rick_h_> alexpilotti: what's the demo? Can you tweak the list of config values so the password is at the end/off the screen?
<hatch> rick_h_ I've also shown him where we render the config UI and the template in PM
<rick_h_> alexpilotti: or hard code the value in the fork of the charm and remove it from the config
<alexpilotti> rick_h_: weâll do that if we have no other chance :-) 
<bac> redir: if you have the cycles, would be nice to ingest some stuff, disable that test, run make test, and then ensure your index is still there.  if so, perhaps just leave that test disabled until we can re-write it sanely.
<rick_h_> alexpilotti: ok, we're up against a wall for ODS demo atm so not a lot of time until after next week to look at better solutions
<redir> bac affirmative
<rick_h_> those are the things I can think of off the top of my head to get by for the moment
<bac> redir: and if it solves the problem then i'll buy you a beer at our next meeting.
<hatch> ok stepping out for lunch
<hatch> bbl
<redir> bac was there a bug for that or just a general annoyance?
<bac> latter
<redir> merge problems:/
<redir> bac: I should be doing something like "bzr merge ../trunk" yes?
<bac> redir: do you have a current trunk branch?  if not: bzr merge lp:charmworld
<redir> I went to trunk and did bzr pull
<redir> but I'll try merge lp:charmworld
<bac> and it is on revno 508?
<bac> redir: what was the merge problem you saw?
<redir> yup
<redir> some conflicts that seemed easy enough, but I wind up with a mongo_services object that is undefined
<bac> redir: sounds like bad conflict resolution
<bac> compare api/__init__.py with trunk
<jcsackett> rick_h_: where are the docs on how to set up tmux like you have it, where it just auto starts with tabs?
<redir> bac yeah that doesnt' seem like it merged very well at all
<redir> and test failures. lemme try again
<bac> jujugui: http://qa.manage.jujucharms.com/heartbeat is alive again, after a long hiatus
<jcsackett> bac: \o/
<kadams54> rick_h_: let me know if you have a moment to talk about my branchâ¦ at a decision point here.
<bac> turns out, some services on canonistack using orangesquad credentials did not specify admin-secret or control-block in environments.yaml.  juju made up strings for those values, but used unicode values that swift could not handle.  thus swift went crazy for everything associated with orangesquad.  at least that's how i understand it from sinzui's telling.
<kadams54> bac: help me out hereâ¦ what's that do and what changes now that it's back up?
<bac> kadams54: for you, nothing.  :)
<kadams54> :-)
<rick_h_> kadams54: otp will ping after
<bac> kadams54: but for those working on charmworld dev, it is a canonistack-hosted qa machine that automatically gets updated with tip when changes land
<bac> kadams54: manage.jujucharms.com and staging.manage.jujucharms.com run in our production environment and can only be touched by webops and can't have auto-deploys
<kadams54> Ah, so no test/qa environment while this was down
<kadams54> Just push to production and cross fingers?>
<bac> kadams54: no, have webops deploy to staging but have no environment to investigate directly if things went wrong
<kadams54> (y)
<redir> bac: you have a second to pair up on these two failing tests? 
<bac> redir: give me a sec to grab a beverage.  will ping you.
<redir> k
<rick_h_> kadams54: pong, ready to chat?
<kadams54> Yup
<bac> redir: daily hangout room?
<bac> redir: oops.  i'll make on
<rick_h_> jcsackett: http://uploads.mitechie.com/books/tmux_p1_1.pdf
<redir> sure
<kadams54> Well, let me grab my headphones and take a quick bio break, but mostly yeah :-)
<bac> s/on/one/
<rick_h_> kadams54: k
<jcastro> rick_h_, http://lightswitch05.github.io/commit-cloud/#juju/juju-gui
 * redir waits
<rick_h_> jcastro: :)
<bac> redir: https://plus.google.com/hangouts/_/76cpi4tbcce7jf0nq4j7nufuq0?hl=en
<jcsackett> rick_h_: oh dear, a pdf.
<rick_h_> jcsackett: :P
<redir> bac: google says that party is over:)
<jcsackett> rick_h_: this appears to be actual documentation.
<jcsackett> i believe you just RTFMed me. :p
<jcsackett> thanks. :)
<rick_h_> jcsackett: I gave you a book on it
<rick_h_> it's a pragmatic prog book, it's short
<jcsackett> indeed. you have a book on make too, right? is that digital or physical?
<rick_h_> http://uploads.mitechie.com/books/Managing_Projects_with_GNU_Make_Third_Edition.pdf
<jcsackett> much obliged.
<kadams54> rick_h_: https://plus.google.com/hangouts/_/72cpigd0956186nv27ogmbtm10
<kadams54> rick_h_: gonna make sure CI builds are green and then https://github.com/juju/juju-gui/pull/276 will be ready for hand-off
<rick_h_> ok
<Makyo> hatch, +/-1 on my branch?
<hatch> Makyo oops sorry 
<Makyo> np, lunch ran a little long, had to get a new super on the beehive before the rain moved in.
<hatch> lettr' rip
<hatch> lol beehive
<hatch> your neighbours must hate you
<Makyo> We won't be around them long.  And besides, the problem here is hornets and yellowjackets, rather than honeybees, which mostly just leave you alone.
<Makyo> And paperwasps. Hate those.
<jcsackett> rick_h_: got a moment to chat?
<rick_h_> jcsackett: sure
<hatch> ahh yeah we have yellowhacket problems a lot
<hatch> paperwasps up north moreso
<hatch> those guys are agressive
<jcsackett> Makyo: you got a moment to chat?
<Makyo> Sure thing
<jcsackett> https://plus.google.com/hangouts/_/gv2j7meqfalczxf3ggmfbk236qa?authuser=2&hl=en
<Makyo> jcsackett, Sorry, left in the middle of you saying something, whoops :(
<hatch> rick_h_ so I'm going to remove that databinding-like support from the mass scale up UI. I'll email design and ask them to put together an interaction for 'the service list has changed, now what?' story
<rick_h_> hatch: sounds +1 to me 
<rick_h_> and blame me for everything :P then luca will disagree because it's me and you can get it back into place 
<hatch> lol!
<hatch> sent
<hatch> So what you're telling me is that Luca has a predisposition to hate every idea you have......good to know ;)
<rick_h_> pretty much, you guys should get along great :P
<jcsackett> Makyo: i was just saying "have a good evening".
<hatch> haha, I like to think we do!
<Makyo> Oh!  You too :)
<bac> redir: i'm back in the same hangout
<jcsackett> thanks. :)
<hatch> :'( I hate deleting good code
<hatch> wahhhhhh
<alexpilotti> hatch rick_h_: nailed it :-) https://github.com/cloudbase/juju-gui/commit/0ead46bdf2aa019e8a0b656ab797f52ce9515a82
<hatch> alexpilotti :D
<rick_h_> alexpilotti: so if you submit that to core it takes it?
<rick_h_> alexpilotti: that's my main concern
<hatch> I was pretty sure core would reject it though :)
<alexpilotti> rick_h_: testing now
<hatch> I hope it doesn't
<hatch> that would be pretty nice if it "just works"
<alexpilotti> in case either we hack core as well or we just go with a hack
<hatch> much hack, so hacky
<alexpilotti> hatch: everything is legal for putting a demo together :-) 
<bac> abentley: hi, do you have a couple of minutes to help redir and i get a bzr branch unconfused?
<abentley> otp.  back at you soon.
<hatch> so true, so true, tbh your changes to the front end aren't really hacky at all
 * rick_h_ goes afk for a few
<alexpilotti> hatch: looks like we have a wiiner by just adding it here: http://bazaar.launchpad.net/~go-bot/juju-core/trunk/view/head:/charm/config.go#L55
<alexpilotti> as in: âpasswordâ:  schema.String(),
<hatch> oh very cool - 
<hatch> I suppose a password field in the UI should be able to be toggled visisble
<hatch> so it's a bit more work for a real implementation
<abentley> bac: Okay, what's going on?
<hatch> but it's good to see that it's not a ton more work
<alexpilotti> yeah, but still very easy
<bac> abentley: can you join our hangout?  https://plus.google.com/hangouts/_/gqzq6ltup6vkgfnqieoltnr74aa?hl=en
<abentley> bac: It's says "This party is over.  But you can start a new one."
<bac> abentley: sorry, https://plus.google.com/hangouts/_/gqzq6ltup6vkgfnqieoltnr74aa?hl=en
<bac> oh, thats the same one.
<bac> hmmm
<abentley> bac: Can you just invite me?
<bac> abentley: done
<bac> abentley: reed invited you
<Makyo> Hail storm, may lose power.
<hatch> Makyo no underground powerlines there?
<hatch> or is the hail THAT big ;)
<Makyo> Underground in the neighborhood, but the main lines are above ground leading to the neighborhood.
<Makyo> And they're notoriously fragile
<hatch> ahh yeah that's what it's like here, although not super fragile (depends on the area)
<alexpilotti> hatch rick_h_: tx a lot guys! With your help this went really fast!
<hatch> alexpilotti happy to help!
<abentley> redir: My guess about how 510 happened is that you did "bzr merge ../trunk" and then "bzr revert .".  "revert ." will reset the files but not the merges.  You want "bzr revert" (no dot) for that.
<redir> abentley: thanks for your help
<hatch> abentley the bzr master
<hatch> I think he has a 9th degree bzr black belt somewhere
 * hatch whispers to redir "abentley wrote bzr"
<abentley> hatch: Well, not just me.  Martin Pool led the project, and I made major contributions like the merge/revert/pull filesystem manipulation.
<hatch> so you did all the hard stuff? ;)
<abentley> hatch: There was plenty of hard stuff to go around.  The current repository format, for example, uses a mind-melting compression technique by Robert Collins.
<hatch> :-) just can't take a compliment 
<hatch> hey rick_h_  are you back yet?
<hatch__> our test suite is so busted I put a .only on the machine panel view tests and it runs the browser _machine dispatch tests too
<hatch__> colour me confused!
<rick_h_> hatch: back what's up?
<hatch> rick_h_ hey, I'm just writing more tests now, but take a look at my new implementation of the scale up view. I left the DOM manipulation stuff in there so that when it re-renders when the user clicks the 'refresh' button all of their stuff will still be there
<rick_h_> hatch: k, sounds like a good plan. Saw the email go by. I like making it depend on the user asking for it
<hatch> yeah - I now only pass the serviceList in, and emit an event for adding units
<rick_h_> hatch: cool, that sounds nice
<hatch> I figured it would, it was your idea :P
<rick_h_> :P
<hatch> haha, but it was right
<rick_h_> hey, we're ending up nicely in the middle, that's a good answer to most problems
<hatch> design by committee 
<hatch> oh wait
<rick_h_> :P
<hatch> that's usually a bad thing
<hatch> lol
<rick_h_> once in a while multiple heads make one smart decision
 * rick_h_ runs away now 
<hatch> :) cya
<rick_h_> alexpilotti: did you end up patching the GUI? Do we need to get a patch in?
<rick_h_> alexpilotti: or you have something that works for you for now?
<rick_h_> ok, /me really runs now
<alexpilotti> rick_h_: for the demo is good, IMO it can also work as the base for a subsequent merge:
<alexpilotti> rick_h_: https://github.com/cloudbase/juju-gui/commit/0ead46bdf2aa019e8a0b656ab797f52ce9515a82
<rick_h_> alexpilotti: cool, let's make sure to work together on that then. I'd love to see some outside stuff head in and appreciate your willingness to poke through it
<alexpilotti> rick_h_: hereâs teh corresponding juju-core patch: http://bazaar.launchpad.net/~alexpilotti/juju-core/juju-core/revision/2706?start_revid=2706
<rick_h_> alexpilotti: ah cool, did need a small patch there then. Good to konw
<rick_h_> know
<rick_h_> alexpilotti: <3 you rock
<alexpilotti> rick_h_: tx! It was easier then expected! :-)
<hatch> it's good to hear the GUI is pretty easy to work on for external contributors 
<alexpilotti> itâs a very neat project, indeed
<hatch> thanks :) 
<hatch> it's come a long way
<hatch> rick_h_ if you get a moment the mass scale-up UI changes are done and pushed - if it passes review feel free to shipit
<hatch> kadams54 are you around?
<huwshimi> Morning
<hatch> morning huwshimi 
<hatch> huwshimi I'm curious how your branch is coming along and if you had any questions about it. I have to take off soon but would love to see that thing land in the am :)
<huwshimi> hatch: Sure, I'll see how I go :)
<hatch> shall I check back in later?
<huwshimi> hatch: There's still a bunch of work I need to do to get all the updates working correctly and test written.
<hatch> ahh ok, well I have to run out for supper for a few hours, so when I get back I'll check back in
<hatch> If you don't get it finished mind passing it off to me?
<hatch> maybe fire off an email with the details etc
<huwshimi> hatch: Sure, will do!
<hatch> awesome
<huwshimi> hatch: Did you want to merge my last set of changes into your unplaced-units branch?
<hatch> umm, which changes are those?
<hatch> I've got it up for the final review/qa
<hatch> huwshimi mind putting the diff up in a gist?
<huwshimi> hatch: Sure.
<huwshimi> hatch: It borrows a lot from you branch
<hatch> man I'm pissed, I can't find my Three sim card :/ 
<huwshimi> hatch: How do I get a diff of all changes in this branch, including uncommitted changes?
<hatch> `git diff develop`
<hatch> will diff it from develop
<hatch> I gota run
<hatch> I'll take a look when I get back
<huwshimi> hmm... that won't work as develop has changed. I'll figure it out.
#juju-gui 2014-05-08
<rick_h_> hatch: rgr will look
<rick_h_> hatch: don't worry about the search branch. It's just a WIP to go through
<kadams54> hatch: I am now :-)
<rick_h_> heh, timing is everything
<rick_h_> time for me to head home...
<huwshimi> hatch: I'll be pushing changes up here if you want to follow along: https://github.com/huwshimi/juju-gui/compare/machine-view-render-changes
<hatch> huwshimi sounds good, mind firing me an email at your EOD and let me know what still needs/has been done?
<huwshimi> hatch: Will do.
<hatch> thanks, we r in crunch time :)
<huwshimi> yeah
<hatch> any questions or anything so far?
<huwshimi> hatch: Do you know how to simulate an update on an object? In the console I've been using app.db.machines.add/remove etc. but don't know how to do update.
<hatch> change
<hatch> if you change the contents of one of the machines there should be a *:change event that bubbles up to the modellist
<huwshimi> hatch: But how do I change the contents of a machine?
<hatch> well you can use the getById() method on the modellist if you have the id
<hatch> to fetch the model
<hatch> or item(n) to grab it by index
<hatch> or each(function(machine) { ... })
<hatch> to loop through
<hatch> then you just change the contents like you would any model
<hatch> did that answer the question
<huwshimi> hatch: Oh, I was trying to do a .set(..) on the object, but I can just set the parameter directly (foo.id = '1')
<hatch> if the machines modellist is a lazyModelList then yes each model is actually just an object
<hatch> that's the primary difference between a modelList and a lazyModelList
<huwshimi> Hmm... the change event doesn't fire though.
<hatch> no, you'll need to promote it to a real model
<hatch> http://yuilibrary.com/yui/docs/api/classes/LazyModelList.html#method_revive
<hatch> but this is a problem that we will need to think about...
<hatch> brb need to dc for a second
<hatch__> back
<huwshimi> hatch__: So when I do the revive the change event should fire?
<hatch__> it 'should'
<hatch__> it's been a while since I've used it
<hatch__> then you'll want to call `free` on it
<hatch__> http://yuilibrary.com/yui/docs/api/classes/LazyModelList.html#method_free
<hatch__> I 'think' this is the interaction we'll want to use for this type of thing
<huwshimi> hatch__: Hmm... nothing is getting fired
<hatch__> how are you listening for the event?
<huwshimi> hatch__: https://github.com/huwshimi/juju-gui/compare/machine-view-render-changes#diff-947e688a9f9e23383a48af542be63bbfR65
<hatch__> hmm that 'should' work....
<rick_h_> hatch: I added a card in 'on deck' in Maint. for the password thing fyi
<rick_h_> hatch: actually two, one for core and one for gui
<hatch> kewlio
<huwshimi> hatch: And in a console I'm doing: foo = app.db.machines.getById(14); foo.displayName = 'new'; app.db.machines.revive(foo);
<hatch> ohh
<hatch> you need to revive first
<hatch> then use `set()`
<huwshimi> oh
<hatch> basically it's converting an object into a real model
<huwshimi> hatch: Yeah, that worked. Thanks
<hatch> right on
<hatch> make sure you use 'free' afterwards
<huwshimi> hatch: Even in the chrome console?
<hatch> ohh you're just hacking?
<hatch> then it's fine
<huwshimi> hatch: Yeah, I'm just simulating the events in the browser at the moment
<hatch> oh ok cool yeah then np
<huwshimi> hatch: I'll free in the test
<hatch> basically you use a LML to save memory and whatnot because then it's just objects instead of model instances
<huwshimi> hatch: Any suggestions for how to do the update? I don't want to have to compare the contents of every token...
<hatch> I think i need more context
<huwshimi> hatch: Do you know what can change on a machine? Can the displayName change for example?
<hatch> hmm, I don't think anything tbh
<hatch> I would assume that any changes would require a new machine
<hatch> ^ rick_h_  have any idea?
<rick_h_> huwshimi: it will be possible to name machines yes. It came up in Vegas and I've got a meeting on that tomorrow with Luca
<rick_h_> huwshimi: but we're ok for the moment
<huwshimi> hatch: The units can, but I assume we'll handle that differently (it's not something tied to the machine model)
<hatch> yeah the units definitely can
<hatch> I didn't know you could name machines
<hatch> that's interesting
<rick_h_> hatch: I don't recall if that's planned or does work atm
<huwshimi> hatch: Should I leave updating until we know what will change then?
<hatch> I'd say so
<huwshimi> hatch: OK, that might be a follow up branch then.
<hatch> yeah it should be ok to add on later on
<hatch> cool
<huwshimi> hatch: I have to dash out for lunch. bbs.
<hatch> sure thing, cya later
<rick_h_> man this is going to be a big diff lol
<rick_h_> I'll have to ask hatch to review it :P
<hatch> haha shouldn't you be in bed?
<rick_h_> I should, but need to make this work and been talking with another team about their custom gui/charmworld needs for their demo :/
<hatch> oo boy
<rick_h_> this.state.getCurrent('charmID');
<rick_h_> that seems like it's broken?
<rick_h_> hmm, looks like it's custom mapped just for editorial ugh
<hatch> rick_h_ that is no longer the valid syntax for the new state class
<rick_h_> hatch: yea, gotcha. It looks legacy for non flagged editorial stuff
<rick_h_> will add an XXX
<hatch> yeah - the new getCurrent syntax is pretty clunky, I've been wanting to add dot-notation support but haven't yet
<rick_h_> huwshimi: around?
<huwshimi> rick_h_: Oh, sorry I missed your message
<rick_h_> huwshimi: all good
<rick_h_> huwshimi: have much time left in your day?
<huwshimi> rick_h_: A couple of hours, but I'll try and work until this is done.
<rick_h_> ok, cool. I might need your help tomorrow. I've broken sticky headers, probably off a div somewhere, and not seeing it jump out at me
<huwshimi> rick_h_: You, on the other hand, should be in bed :)
<rick_h_> about to call it a night
<rick_h_> well soon
<rick_h_> almost have it working
<huwshimi> rick_h_: Want me to take a look?
<rick_h_> well, it works w/o the flag, now to make it work with
<rick_h_> https://github.com/juju/juju-gui/pull/279 is the WIP
<rick_h_> lots of crapped moved around and such, try not to look at the diff
<rick_h_> but if you get a sec to try it out and notice that the first header returns after scrolling down maybe the reason will jump out at you
<huwshimi> rick_h_: I don't get any sidebar content and an undefined is not a function error
<rick_h_> huwshimi: with no flags?
<huwshimi> rick_h_: that's with flags
<huwshimi> rick_h_: It's actually broken without flags too. It overlaps the headers instead of pushing
<rick_h_> huwshimi: I just pushed a fix for making it work with flags
<rick_h_> huwshimi: right, that's what I mean
<rick_h_> my refactoring (without flags) has messed up the sticky headers
<huwshimi> Ah
<rick_h_> I think it's a div/css placement thingy
<rick_h_> ok, well the event stuff works with and without a flag and search works. Home doesn't and the sticky headers are broken. I guess I'll call that half way there and call it a night
<rick_h_> huwshimi: if you see anything that jumps out let me know, otherwise I'll try to pick it back up with a clear head tomorrow
<rick_h_> or well later today
<huwshimi> rick_h_: I suspect it's not calculating the distance between headers correctly
<huwshimi> might be an on('scroll' not firing
<rick_h_> ah, me looks
<rick_h_> hmm <div id="bws-editorial"> is the renderTo in the code for the target of that event
<rick_h_> but yea, not firing
<huwshimi> yeah, that's it
<huwshimi> rick_h_: .bws-content is the element it should have the event on.
<rick_h_> ah ok, updating 
<huwshimi> rick_h_: We could possibly make #bws-editorial the element that scrolls if need be.
<rick_h_> yea, that works
<huwshimi> Oh good.
<rick_h_> I just hard coded it to .bws-editorial for now
<rick_h_> the structure is a bit different, but this will work for now
<rick_h_> thanks!
<huwshimi> rick_h_: No problems. Hope you get some sleep! :)
<rick_h_> I will head off to bed now. Have it pretty close. 
<rick_h_> night and thanks again!
<huwshimi> rick_h_: Night
<antdillon> rick_h_, Morning
<rick_h_> antdillon: morning
<antdillon> rick_h_, I have a few issues with the environment change set. Where is the best place to voice them?
<antdillon> rick_h_, Also can I check I should be working from flag mv/li?
<rick_h_> Just me for the moment. Want to chat? Or type out what's up?
<rick_h_> antdillon: yes, this is work under the two flags. It's really mv, but il is the soon to be released 'inspector left' flag
<antdillon> rick_h_, I got it all working its mainly missing info in the ecs like no time stamp
<rick_h_> antdillon: oh? Ok, well I was just expecting the count to work
<rick_h_> so if you've got more stuff working then why not push up your branch, start a pull request with notes, and we can start to look through the code and help fill in the last bits
<antdillon> rick_h_, I few events to bundled like deploying a server and subordinate fire the same deployed event
<antdillon> rick_h_, Wont we need time stamps for the summary panel?
<rick_h_> yes, well containers and machines are the same thing in juju land so that's not surprising. There should be some metadata to help us tell them apart
<rick_h_> antdillon: well, maybe. I'll look at the mocks. I'd consider that more for the changelog, which we're not doing right now since we can't get your previous commits
<antdillon> Oh I see, I was using the command method to split the events
<rick_h_> antdillon: cool, yea if you start a pull request we can start to go through and help hash over the last details and check it out. 
<antdillon> rick_h_, Sure, just working through the last few changes and there messages then tests :)
<rick_h_> antdillon: yay
<rick_h_> frankban: sorry, completely missed the time
<frankban> rick_h_: no worries, ready when you are
<rick_h_> frankban: https://github.com/juju/juju-gui/pull/277
 * frankban lunches
<rick_h_> this test run isn't going to be pretty 
<jcsackett> morning all.
<rick_h_> morning
<jcsackett> rick_h_: got your invite--i have a contractor swinging by the house sometime between now and 11, so i may be interrupted, but i'll be there.
<rick_h_> jcsackett: thanks
<rick_h_> it'll be quick, forgot to shorten from the google calendar 1hr default
<jcsackett> cool.
<bac> rick_h_: daily hangout?
<rick_h_> bac: soryr, had a hangout in the meeting invite
<rick_h_> https://plus.google.com/hangouts/_/canonical.com/charmworld?authuser=1&hceid=cmljay5oYXJkaW5nQGNhbm9uaWNhbC5jb20.7enijh4dvef97a4ifdu83bnoj4
<rick_h_> I <3 it when a passing test comes together
<bac> redir: when you finish your current work, could you look at the deploying local charmworld instructions and walk through them to ensure they still work?  you have fresh eyes.  https://docs.google.com/a/canonical.com/document/d/1Y8Uhomr4_6L3nFXLXPZY2V-tFjl5KjOIknQLuXdzU_A
<redir>  bac do we have a target for the demo? trusty?
<redir> I can do it from scratch in a container
<bac> yes, i'd say trusty
<bac> in an lxc would be great
<redir> k
<rick_h_> bac: want to catch up with 1-1 later on?
<bac> rick_h_: what do you mean?  postpone?  i can do it now
<rick_h_> bac: ok
<antdillon> Hi guys, does anyone have a min to help me get my head around some tests for deployer bar?
<rick_h_> Makyo: are you around to help antdillon?
<rick_h_> antdillon: I've got a call in 7, what's up? Maybe push a branch and create a pull request with notes/questions so we can see what's up?
<rick_h_> and I can help out between calls 
<antdillon> rick_h_, Its mainly just trying to add a change to the ecs in the test
<rick_h_> antdillon: ah, gotcha. sec, might be able to find an example
<antdillon> rick_h_, I'm in the text_env_change.js
<rick_h_> antdillon: oh ok, so in the ecs tests itself?
<antdillon> rick_h_, Something like utils.makeStubMethod(envObj, '_deploy');
<rick_h_> antdillon: you're looking to make a stub or to put something into that stub'd method?
<jcsackett> rick_h_: fyi, my contractor just called to say he's running late, so he's likely to arrive *during* standup. as with earlier meeting, i'll be there but may get interrupted.
<rick_h_> jcsackett: rgr
<rick_h_> antdillon: maybe hatch can help you 1-1?
<hatch> uh oh
 * hatch runs away
<hatch> :P
<antdillon> hatch, come back
<hatch> what's up?
<antdillon> hatch, Getting errors trying to set changes to the ecs in the deploy bar tests
<antdillon> hatch, Got any tricks?
<hatch> can you push up the code?
<hatch> so I can see what you're trying
<hatch> and what the errors are
<antdillon> hatch, Here is the test: https://pastebin.canonical.com/109870/
<antdillon> Getting TypeError: 'undefined' is not an object (evaluating 'ecs.changeSet')
<hatch> looking
<antdillon> hatch, Not sure im initialising the ecs properly
<hatch> blah 2fa, one sec
<hatch> ok you're doing the stubbing incorrectly
<hatch> one sec 
<hatch> at least I think so
<hatch> you're stubbing out the entire application 
<antdillon> probably, seems slightly different test by test
<hatch> so what is this test trying to do?
<hatch> when you simulate a click on the deploy button the ecs commit method is called?
<antdillon> The "should increase changes when a services is added" is trying to set a change then check the deployer bar is returns 1 changes
<hatch> oh that test
<hatch> woops :)
<antdillon> I didnt write that one, im working on the one above and will move to that one
<antdillon> hatch, But both are erroring
<hatch> ok so first of all you're stubbing out a method and not resetting it
<hatch> and then as far as the rest of the errors I'll need to run the code to see the actual error
<antdillon> hatch, I'll push them up
<hatch> thx
<hatch> brb
<redir> merge proposal submitted in lp. requested R=jcsackett to get different eyeballs on it.
<redir> bac: ubuntu or ubuntu-cloud for the container?
<redir> matter?
<bac> redir: lxc?
<antdillon> hatch, https://github.com/anthonydillon/juju-gui
<hatch> antdillon which branch?
<hatch> oh you pushed into develop
<antdillon> Pushed to my fork
<antdillon> git@github.com:anthonydillon/juju-gui.git
<jcsackett> redir: ack, i'll take a look after standup.
<jcsackett> redir, bac: we're using LP, not rietveld now?
<hatch> antdillon yeah ok, give me a few minutes to pull this down and take a look
<bac> jcsackett: new hires cannot use lbox
<bac> something to do with the auth dance
<bac> and unsupported tools
<jcsackett> bac: lovely.
<jcsackett> ok, no worries.
<antdillon> hatch, Thank you very much
<rick_h_> jujugui call in 4
<bac> hey rick_h_ you're sending out gcal invites in pacific time.  perhaps you should tell google you're back home.  :)
<bac> not that it matters...
<rick_h_> bac: hah, awesome
<rick_h_> bac: hmm, it says I'm in eastern
<bac> our 1:1 came across as 7am, which caused me to panic a bit
<hatch> antdillon assert.equal(view._getChangeCount(ecs), 1);
<hatch> you didn't pass ecs into this method
<kadams54> hatch: got a state question for you, maybe after standup?
<hatch> sure
<hatch> jujugui call now
<antdillon> hatch, Isnt ecs a global?
<antdillon> hatch, Ah got it :)
<redir> jcsackett: bac's instructions for setting up juju-gui to connect to local charmstore with ngrams applies also.
<hatch> antdillon :) rookie mistake :P
<antdillon> hatch, :P
<Makyo> jcsackett, shared the calendar with you.
<jcsackett> Makyo: thanks.
<jcsackett> redir, bac: do we have to set it up that way? shouldn't the search api endpoint reflect the changes? was planning on just poking at a local charmworld with httpie for qa.
<bac> jcsackett: i think that works just as well
<bac> jcsackett: using juju-gui to see the autocomplete behavior is nice, too
<antdillon> hatch, Is utils.makeStubMethod(envObj, '_deploy'); the correct way to trigger an event?
<hatch> nope
<redir> jcsackett: that is how I rolled. But hooked up the gui to make sure it didn't puke
<jcsackett> redir, bac fair points.
<hatch> that will make a stubed version of the _deploy method on the envObj
<jcsackett> looking now.
<hatch> you want to fire an event from envObj?
<hatch> rick_h_ you said that you have an outline of the demo they want to do?
<antdillon> Im copying from test_env_change.js
<hatch> you're going to have to give me more information :)
<rick_h_> hatch: yes, I've requested access for everyone, waiting on luca 
<redir> bac: yes re lxc, there are ubuntu and ubuntu-cloud images. Not sure which they will demo from butvalidating  on the same one would be ideal.
<bac> redir: i have no preference.  pick one and document it
<redir> k
<bac> and if it breaks, pick the other one
<redir> hehe
<hatch> frankban are you taking over huw's branch?
<rick_h_> hatch: no, I was going to see if you would 
<rick_h_> hatch: we need to get the service units stuff landed first before anything else really
<hatch> yep I will, I just saw his comments, wasn't sure if he was on it
<rick_h_> he was realy helpful to narrow it down <3
<hatch> haha yes
<hatch> ok I've got to run to the drug store to buy some drugs
<rick_h_> yay drugs!
<hatch> I've gone this long without any, but with all this coughing it's just too hard to do anything 
<jcsackett> rick_h_, frankban: so, what branch should i be watching for service unit stuff? i thought just frankbans, but huw's too?
<hatch> need some cough juice 
<frankban> hatch: I am trying to proceed with this branch, so that wasn't a real review
<hatch> frankban ok thanks
<hatch> bbiab
<jcsackett> hatch: just make sure it's not the *special* cough juice.
<hatch> jcsackett maybe the code will be more interesting :P
<jcsackett> yeah, b/c coding with full-strength robo-tussin is such a good idea. or is that like the balmer curve...
<frankban> jcsackett: that's my branch: we will have a db.units lazy model list, and new db.addUnits() / db.removeUnits() calls to use in order to keep the different model lists in sync
<antdillon> hatch, Sorry I was using the code from test/test_env_change.js
<jcsackett> frankban: awesome. you're not doing anything insofar as loading units onto machines, are you? i'm assuming i'll want to have the machine view code drop that onto tokens as appropriate from the lazylist you're making.
<antdillon> hatch, All I need to do it trigger an event like _deploy or _relation
<jcsackett> s/machines/machine-view/
<frankban> jcsackett: yeah, at that point it should be something like db.units.filter(function(unit) {return unit.machine == $myMachine}) or similar
<jcsackett> frankban: awesome. thanks.
<jcsackett> redir: to make sure i'm understanding, ngram stuff is available in ES, you've set up how you want ngram stuff done with n3_20 stuff in filter and analysis, so ES understands what is meant by that when you use it in the mapping?
<redir> jcsackett: yes. define an analyzer then use it
<jcsackett> redir: just making sure. outside of a full understanding of ES it looks a little magical. :p
<redir> agreed
<redir> I don't claim to have a full understanding of ES:)
<hatch> back
<hatch> antdillon _deploy or _relation aren't events
<antdillon> hatch, I mean't adding to the ecs
<hatch> ok so you need to add a record to the ecs so that you can test that the count goes up in the deployer bar?
<antdillon> When I do ecs._createNewRecord('service');
<antdillon> I get TypeError: 'undefined' is not an object (evaluating 'record.command.args')
<jcsackett> redir: code is r=me, qa-ing now. can you please file a bug about the test you needed to comment out?
<hatch> that means that record.command is undefined
<kadams54> hatch: another question on the hasChanged stuffâ¦
<hatch> antdillon the ecs stuff requires a bunch of setup your best bet is to call one of the public methods
<hatch> ecs.deploy for example
<antdillon> hatch, Tried ecs._createNewRecord('service',{ foo: 'foo' }); with an undefined args.length
<jcsackett> redir: qa may take awhile--i have no charms in my local charmworld, need to let ingest run for a bit.
<hatch> kadams54 shoot
<redir> jcsackett: and with that test commented out they won't get deleted when you run the suite
<redir> :)
<hatch> jcsackett why does charmwork injest take to long?
<rick_h_> hatch: don't go there :P
<hatch> oh
<hatch> haha ok
 * hatch steps back slowly
<kadams54> hatch: right now, the way things are coded up, it doesn't do a deep object comparison. https://github.com/juju/juju-gui/blob/develop/app/views/state.js#L70
<hatch> well that's stupid
<kadams54> That's a problem for metadata, which, as things stand, will always return true.
<hatch> what kind of idiot wrote that
<hatch> :)
<kadams54> I'm pretty sure it's Benji's fault ;-)
<hatch> lol!
<kadams54> Soâ¦ how do you want to fix?
<rick_h_> I had to do this for filters
<hatch> the 'proper' way to do fix is to add dot notation to that method
<hatch> but the easy way is ot manually compare for now
<hatch> sorry
 * kadams54 *sobs*
<hatch> manually compare isn't too bad
<hatch> one extra line
<rick_h_> kadams54: hatch I just did JSON stringify compare to check if they were the same for the filter object data
<rick_h_> fyi
<kadams54> rick_h_: yeah, I was thinking of doing the same
<hatch> ahh yeah that would work, but in this case that's overkill
<kadams54> Couldn't remember if there were any caveats to that hack
<hatch> imho
<rick_h_> kadams54: determinism of the data
<hatch> it's slow
<hatch> "slow"
<hatch> antdillon you can probably go ecs.changeSet.abc123 = { ... }
<hatch> assuming that you don't have another key which is abc123 :)
<antdillon> hatch, lol i thought that would be cheating
<antdillon> hatch, wanted to try and push a true event in there using the right function
<hatch> well it is, but you're testing the integration between two classes 
<hatch> you don't need to test that the ecs is working, it already has tests for that
<antdillon> i guess
<antdillon> thanks
<hatch> np :)
<hatch> I don't know how the stuff in cough syrup works but daaaaaaamn it works fast
<antdillon> on to the deploy :P
<hatch> antdillon so how is the Object.observe stuff working out?
<antdillon> hatch, Good! seems to be working for the changes that are supported
<hatch> nice
<hatch> glad to hear it
<antdillon> should have a pull request in soon
<redir> jcsackett: filed 1317567
<jcsackett> redir: thanks.
<rick_h_> jujugui need two reviews and would like two qa's of https://github.com/juju/juju-gui/pull/281 please. Apologies for the size up front. took 4 files down to 1 so lots of moving around
<kadams54> QAing
<rick_h_> kadams54: ty
<rick_h_> hah, and somehting is broken yay
<hatch> frankban so in huw's branch the proper add event is being fired but `this.get('db').machines.filterByParent(null);` is not returning the newly added machine
<hatch> but there IS a machine in the db
<frankban> hatch: I explained what's going on in the mp comments
<hatch> ohh woops I misread your comments
<frankban> .filterByParent(null) does not return the machine because parentId is not set at the time the event is fired
<frankban> hatch: ^^^
<hatch> ok I can fix that, instead of overwriting add, listen to the the 'on' event and modify the machine before it's added
<frankban> hatch: my current branch fixes the issue
<rick_h_> bah, make test pass rebase and now it's broken
<rick_h_> hold off kadams54 working on it
<hatch> is there a reason why ^ wouldn't work frankban ?
<frankban> hatch: interesting
<kadams54> rick_h_: will do
<hatch> it seems like it should
<hatch> then we don't have to make custom events for fun :)
<jcsackett> redir: so, qa may take a really long time. ingest blew up b/c of local network problems.
<jcsackett> redir: do you have other things to work on, or is this blocking you?
<redir> nope trying to review local demo instructions and have a bug in the lxc ubuntu image trying to figure out where to file that
<redir> jcsackett: ^^
<frankban> hatch: I am not sure, the add override has been there for a while, but if you think that works I agree it can be better, given we find a way to make it easy for people looking at the models what's going on (i.e. you add a machine, and then you have a different machine). This kind of jumping around can be dangerous when using events.
<hatch> ok I'm going to give it a try, see if the tests pass
<redir> jcsackett: I have a copy of the ES index I can put up for you to DL but you may also need the mongo stuff for CW to work right
<redir> idk
<frankban> hatch: to be clear, I am worried by the double pain of having 1) an object mutated 2) by a ninja subscriber
<jcsackett> redir: if it's not blocking you, i'm content to just let it finish running properly.
<redir> jcsackett: cool
<jcsackett> redir: not that i think your branch could be at fault, but it's always good to make sure ingest still works. :p
<hatch> frankban, yeah it's not very transparent with the ninja subscriber
<jcsackett> is "ninja subscriber" an actual term of art, or just something y'all are going with?
<hatch> I just feel that we should be modifying the machine BEFORE it's saved not after
<hatch> jcsackett just running with it
<hatch> :D
<jcsackett> hatch: dig.
<hatch> I see a tweet here somewhere
<hatch> I need some program that tweets and G+'s at the same time
<frankban> ninja subscribers can destroy your application very fast
<hatch> see an attribute would handle this in the setter
<hatch> I'll ask in #yui see if anyone has any input
<frankban> hatch: anyway, what's so wrong with the custom event? we can also avoid the original one to be fired, so the total event count can be maintained stable
<hatch> frankban events aren't discoverable - and custom event's don't follow any convention
<hatch> so anyone working with the code will have to somehow 'just know' that they should use this custom event instead of the YUI one
<hatch> I suppose we could make the add event silent and then fire an add event ourselves
<frankban> hatch: I tried to reuse the YUI one, but found that unfortunately an internal ninja subscriber is already in place in YUI :-/
<hatch> something else is listening to the 'add' event?
<frankban> hatch: yes
<hatch> and our modifications break it?
<frankban> https://yuilibrary.com/yui/docs/api/files/app_js_model-list.js.html#l189
<hatch> that's just publishing that this will fire that event
<hatch> but I see what you're saying
<hatch> the lazy model list api is linking to the wrong file :/
<frankban> hatch: that;s also adding a default subscriber: this._defAddFn
<hatch> yeah
<frankban> hatch: but perhaps we can fire add with preventDefault?
<frankban> hatch: yeah, that could work
<hatch> https://yuilibrary.com/yui/docs/api/files/app_js_lazy-model-list.js.html#l287
<frankban> hatch: so we add with silent: true, we modify the object and then we fire "add" with preventDefault?
<hatch> just an idea
<antdillon> hatch, sorry one last thing
<hatch> np, shoot
<rick_h_> kadams54: pushing updated branch now. 
<hatch> frankban I'll try that approach and see how it works out
<rick_h_> jujugui so https://github.com/juju/juju-gui/pull/281 is updated and looking for eyeballs please. 
 * rick_h_ goes out to get some lunch
<antdillon> hatch, assert.isTrue(stubApp.ecs.commit.calledOnce()); is false but it should defo be being hit
<hatch> how are you stubbing it?
<antdillon> hatch, http://paste.ubuntu.com/7417088/
<hatch> antdillon where you think it should be being called place a debugger right before that line. Then console.log the function and see if you get the stub function or the real commit function
<hatch> and don't use isTrue (it doesn't give proper tracebacks) use equal() instead
<antdillon> hatch, Ok thanks
<frankban> hatch: ok so I'll exclude that change from my current work, could you please inform Huw that you are working on that later?
<hatch> frankban yeah - I'll let you know if this works, atm I'm having trouble preventing the default soon enough
<hatch> frankban looks like this technique won't work without a bunch of hackyness 
<hatch> so we'll have to use your technique 
<frankban> hatch: fullAdd?
<hatch> yeah
<hatch> frankban what if we modified the model BEFORE calling var result = MachineList.superclass.add.apply(this, args);
<hatch> is that possible?
<hatch> so invert how the new add method executes
<frankban> hatch: that can be possible
<frankban> hatch: especially because we are using lazy model lists, so we should not require calling instance methods
<antdillon> hatch, Ah so I had to call stubApp.ecs.commit() to get true for stubApp.ecs.commit.calledOnce() 
<hatch> frankban that's what I was thinking....ok I'll try that 
<hatch> that makes sense
<hatch> ^ antdillon 
<antdillon> hatch, Is there a way to calledOnce on the none stubbed function?
<hatch> no but you can call the original method
<antdillon> The original method is called by the button click
<hatch> https://github.com/juju/juju-gui/blob/develop/test/utils.js#L89
<hatch> well if the original method is called by the button click then clicking the button should trigger the stub to be called
<antdillon> hatch, Its not for some reason
<rick_h_> antdillon: is the code up? Remember that button clicks are events and async
<antdillon> hatch, But by debuggering and calling stubApp.ecs.commit()
<rick_h_> antdillon: so you have to find a way to watch for that click
<antdillon> the calledOnce returns true
<hatch> my guess is you're running into an async issue
<hatch> so what you need to do is listen to 'after' that click event
<antdillon> hatch, I thought it might be a race :(
<hatch> then test for the once() in there
<hatch> so yeah....like rick_h_  said :)
<antdillon> but with the debugger i ran calledOnce a while after the click and its still false
<rick_h_> antdillon: right, so you created a mock, then you manually called the mock
<rick_h_> what you want to do is create the stub, and watch it, and see who ELSE talks to it
<rick_h_> antdillon: let me know if you want to hangout and I can help look at it. I'm free atm
<antdillon> rick_h_, Ok that would be good. This is the final bit of tests for now
<rick_h_> antdillon: hangout invite on the way
<rick_h_> antdillon: https://plus.google.com/hangouts/_/grvtyzyt53dbgg2c4lkx6elfwya?authuser=1&hl=en
<hatch> frankban inverting the execution order of add() fixed it :) yay
<frankban> hatch: very cool
<hatch> much happier
<hatch> :)
<frankban> yeah
<hatch> frankban https://gist.github.com/hatched/84a65398d22fc3753ef6 here is the new method
<frankban> hatch: cool, could you please change also the unitList one?
<hatch> I could, that might be out of scope of this branch though
<hatch> this branch already breaks the environment switcher 
<hatch> lol
<hatch> rick_h_ when you have a moment I'd like to pair on this review - there are so many lines moved around it would be nice to have some guidance as to what's new and what's not
<rick_h_> sure thing
<rick_h_> hatch: will ping once done with antdillon 
<antdillon> rick_h_, git@github.com:anthonydillon/juju-gui.git
<hatch> yeah no rush
<jcsackett> redir, bac: https://pastebin.canonical.com/109893/
<jcsackett> post ingest, trying to start up charmworld.
<redir> jcsackett: dude you broke i
<redir> t
 * jcsackett laughs
<jcsackett> sorry, dude.
<jcsackett> i didn't want to. :)
<jcsackett> redir: i'm running tests now to see if we get something informative locally to help you debug.
<jcsackett> `make check`, to be specific. could always clobber something bad in my environment and make your code work.
<hatch> Makyo I think I failed with your QA....dragging a service to the canvas on comingsoon doesn't open the inspector anymore....after you deploy one service though, it does
<Makyo> hatch, boo.  Oh well, easy fix.
<Makyo> Let me do that real quick.
<hatch> thanks, sorry about that - I'm not sure how I didn't notice that in QA
<rick_h_> hatch: time to chat?
<rick_h_> looks like kadams54 found I missed the cleanup point whoops
<hatch> rick_h_ maybe you should fix kadams54's issues he found in QA first :)
<rick_h_> :P
<hatch> welcome back to the dark side
<hatch> mohohahaha
<kadams54> I hate to say this, but huw suffered through multiple rounds of QA when I was working this branch
<kadams54> He might be good to pull in for a second set of QA ees.
<kadams54> eyes even
<kadams54> He had a good knack for breaking this in increasingly complex ways
<rick_h_> it's all good, it's close. I didn't test the inspector integration and it's some missing cleanup on close/change 
<antdillon> rick_h_, Branch up updated git@github.com:anthonydillon/juju-gui.git
<antdillon> rick_h_, Heading home will be online in an hour
<rick_h_> antdillon: do a pull request please
<rick_h_> antdillon: it's easier then you can see the diff of what changes 
<antdillon> rick_h_, Sure
<rick_h_> thanks
<frankban> guihelp: I need two reviews and possibly two QAs for https://github.com/juju/juju-gui/pull/282 (this is the db.units change). I have to go now, but I'll take a look later. Thanks a lot, that's a long diff but should unblock things a bit
<hatch> frankban I'll take one
<hatch> thanks for the hard work on it
<jcsackett> frankban: i'll take the other.
<frankban> thank you both!
<jcsackett> frankban: no no, thank *you* for doing the work. my code needs it. :)
<hatch> haha :)
<frankban> heh
<antdillon> rick_h_, https://github.com/juju/juju-gui/pull/283
<hatch> jcsackett can you do a QA on frankban's branch in a real env? I'm not setup atm for it - I could get setup though if you can't
<jcsackett> hatch: i don't have a version of juju that works with local provider, and aside from getting the one from source i'm unsure how to go about it. :(
<hatch> what version are you on?
<hatch> 10.04? lol
<jcsackett> 1.18.1-trusty. and i see no updates.
<jcsackett> i get endless connection failures trying to bootstrap on local.
<hatch> ohh is there a bug?
<redir> I installed juju-local from ppa and then deleted /usr/bin/juju to get local provider
 * jcsackett raises eyebrow.
<jcsackett> redir: can you juju deploy to other providers, having done that?
<redir> jcsackett: rebuilding cw/ngrams from scratch to ensure it works here
<redir> jcsackett: havne't tried
<redir> but I have a build in ~/go/
<jcsackett> redir: yeah, i think i'll have to do the source build and figure out what i did wrong yesterday.
<redir> and it requires the 'package' to be installed 
<jcsackett> 'package'?
<hatch> yeah there is a local package that needs to be installed separate
<hatch> but usually it says so
<Makyo> hatch, https://github.com/juju/juju-gui/pull/284
<hatch> thanks, I'll qa  now
<hatch> Makyo +1'd
<Makyo> \o/
<redir> jcsackett: a fresh checkout/branch from lp:~reedobrien/charmworld/ngrams "works for me"
<Makyo> Realized all of my QA took place with an inspector URL already in place.
<redir> jcsackett: 'package' == apt-get install juju-local
<redir> which also installs juju-core
<rick_h_> kadams54: call?
<redir> bac: you ever resolve that npm conflict?
<bac> redir: i did not but noticed nodejs installed /usr/bin/npm so my system is in working order
<jcsackett> guihelp: we need someone else to qa redirs charmworld branch. anyone able?
<rick_h_> hatch: got a sec?
<hatch> I do
<rick_h_> https://plus.google.com/hangouts/_/canonical.com/kyle-rick?authuser=1
<redir> jcsackett: http://pastebin.ubuntu.com/7417568/ works with the caveat that sysdeps fails to install npm so I run apt with out that and nodejs installs npm
<redir> on trusty
<jcsackett> bac ^ is this sort of thing likely necessary for a deploy, then?
<jcsackett> redir: that also blows away the entire database...so have you done an ingest to see if it works once there's data?
<redir> jcsackett: running now
<jcsackett> redir: ok.
<jcsackett> sorry this is such a pain. just be glad eventually all of this is going to be something better.
<bac> jcsackett: we're deploying on precise.  the node/npm issues are not new to this branch.
<redir> jcsackett: but I did this more than once yesterday
<redir> better
<bac> i mean, the issues are new but the requirements aren't.  i'm inelegantly trying to say i think it works on precise.
<redir> bac: should I be developing on precise? I was doing it locally
<redir> on trusty
<redir> was/am
<bac> i think we need to be on trusty
<jcsackett> bac: i'm not having a node/npm issue, and my lxc is precise.
<jcsackett> nonetheless, bin/es-update crashes on me with the ngram branch.
<bac> jcsackett: oh
<bac> how does it crash?
<jcsackett> bac: https://pastebin.canonical.com/109893/
<redir> bac: jcsackett sent this https://pastebin.canonical.com/109893/
<bac> jcsackett: i thought the node/npm thing was the only issue, so i apologize for being uninformed
<redir> jynx
 * jcsackett laughs
<rick_h_> hatch: ok, got it thanks
<hatch> awesome
<rick_h_> hatch: ok, I'm ready for qa and such, well after my call in 3
<hatch> sure, I'm going to grab lunch now
<hatch> so in a while :)
<bac> jcsackett, redir: i'm perplexed
<redir> jcsackett: bac: building a precise container to build in now
<jcsackett> bac: so am i.
<bac> that looks more like a coding error than an environmental one.  unless you're dealing with a different version of ES package.
<redir> jcsackett: bac: es-0.90.0 here
<jcsackett> bac: i don't actually know how to check es version.
<rick_h_> dpkg -l | grep elasticsearch
<bac> yeah, that
<bac> but i think there's only the one version curtis packaged
<redir> curl localhost:9200
<bac> i've got 0.90.0.release+201305241158+repack8~precise1
<jcsackett> i've got 0.90.0
<jcsackett> bac, redir ^
<redir> and you are on precise, jcsackett?
<jcsackett> redir: yup.
<redir> building precise now to test on 
<rick_h_> woot, the NUCs have arrived. Now to wait a week to have time to play with getting them setup
<hatch> rick_h_ when you do be sure to keep notes so you can write a blog post about how awesome MAAS and Juju are, and how they allowed you to create a cloud in your house
<rick_h_> hatch: heh, I'll try
<hatch> All of the juju questions on askubuntu seem to be around maas
<hatch> hardware must be hard
<hatch> rick_h_ ok I'm done frankban's branch, did you want to run through your branch now?
<rick_h_> hatch: sure, I blew up tests in this last batch but can run through it
<Makyo> rick_h_, I was able to reproduce this stacked service thing earlier, switched to the branch to fix hatch's QA issue, realized I couldn't reproduce it anymore on develop.  What were your steps again?
<Makyo> I'm wondering if an interstitial branch fixed it by accident.
<rick_h_> Makyo: I deployed some stuff with MV/IL on. Did a relation, had three services. I then went into machine view, used the deploy button from there to deploy
<rick_h_> then went back to the service view after a reload, this was in a live env
<rick_h_> when I was qa'ing against lxc
<Makyo> Aha, that's the difference.  My bad.
<rick_h_> hatch: did you want to call to walk through it?
<rick_h_> hatch: or you good for now?
<hatch> rick_h_ ok well lemme qa it
<hatch> and i'll get back to you
<redir> stil building
<redir> I think the net is slow:/
<redir> or maybe that is just archive.ubuntu.com that is slow
<jcsackett> hatch: were you able to QA frankban's branch on a real env?
<hatch> jcsackett I haven't yet 
<hatch> I actually have an architectural change in the comments
<hatch> so I wasn't sure if I was going to
<redir> on precise it built and is now ingesting jcsackett bac
<jcsackett> redir: cool. i look forwards (in an hour or so) hearing if bin/es-update crashes for you. :)
<redir> bin/es-update is called when you run make run
<hatch> rick_h_ QA'd
<hatch> three issues, one meh, 2 need to be fixed
<rick_h_> hatch: all good thanks for the qa
<hatch> oh those issues were using il
<hatch> I forgot to mention that in the comment
<jcsackett> redir: yes.
<redir> so wouldn't it crash when I do make run?
<redir> jcsackett: it didn't
<jcsackett> redir: but you hadn't ingested yet, right?
<redir> not sure how that would differ.
<redir> except if you had data that was already indexed with the old mapping and tried applying the new mapping over it
<rick_h_> jujugui going afk, will finish up fixes and tests on my branches later on. 
<hatch> cya
<bac> ta
<jcsackett> redir: i had no data at all before ingesting.
<redir> caio
<hatch> jcsackett take a look at my big comment in frankbans pr when you get a chance and let me know what you think
<jcsackett> redir: having now just killed all my data and done make run, i can confirm that bin/es-update only fails post-ingest for me.
<jcsackett> hatch: changeUnits?
<redir> OK
<hatch> jcsackett yeah that comment
<redir> I may not have done things in that order
<jcsackett> hatch: so are you suggesting that he redo things so that someone working units would do list.{add,remove,change}, and then events would be used to sync everything up?
<hatch> exactly
<jcsackett> hatch: yeah, i don't like that. :P
<hatch> because how it is right now, he needs to add a changeUnits method too
<jcsackett> hatch: but as it is now, won't he need to implement new stuff for list.change as well, *plus* the event listening stuff?
<jcsackett> i agree changeUnits should be added, but i like the interface he's suggesting here for working with the dual lists.
<jcsackett> hatch: i feel like using events would make this interaction more opaque.
<redir> bac have you been able to reproduce jcsackett's problem?
<bac> redir: i have not tried.  i'm working on the demo issue
<redir> bac right OK
<hatch> jcsackett well right now we are saying, any time you modify a unit you need to do it through these convenience methods. I'm proposing that any changes done to the main list and then propagated outwards instead
<hatch> I'm just trying to stick to conventions as much as possible
<jcsackett> hatch: i don't know that we really gain anything in this instance by following convention.
<jcsackett> we're doing something very specific to this collection--having modifications to it also sync other bits.
<hatch> well we will never run into an issue where someone updates the unit list directly breaking the synchronization 
<hatch> right now - if someone goes unitList.add() it's immediately out of sync
<hatch> and it relies on codereview for people to 'know' that's incorrect
<jcsackett> hatch: still, i don't think we gain much here by doing it as you suggest, beyond hiding the syncing so it's not clear when you're looking at say, `add` that it's also going to modify other things.
<jcsackett> the other way relies on reviewing the code to know that it has side effects, though, right?
<jcsackett> either way people are going to have to read the code.
<jcsackett> here at least you're only having to review one thing to see what is going on.
<hatch> well no, we need some way to signal to the dev that you shouldn't interact with the normal methods directly for this specific modellist
<jcsackett> which we do. there's a big comment saying "don't do that".
<hatch> only if you're reading the model
<hatch> in 5/6 modellists you interact with it one way, 1/6 you need to use special methods
<jcsackett> ...right, but if i don't read the model and see a note saying "hey, when you call `add` this other list will also update how am i going to know that happens?
<hatch> that's not intuitive, and will likely silently fail
<hatch> thats' fine if you don't know it's updating something else
<jcsackett> 5/6 modellists don't keep two lists in sync, do they?
<hatch> because that updating must happen
<jcsackett> i don't know that i agree--i like knowing "call this, both things update" then wondering how on earth this other thing keeps changing.
<hatch> yeah, but you know about this special unit update method
<hatch> think 6mo down the line with some other devs
<jcsackett> hatch: ah, see, we may not be having the conversation we think we're having--i was perhaps unclear in my initial restatement of what you were suggesting.
<hatch> haha
<jcsackett> hatch: you are *not* suggesting he get rid of {add,change,remove}Units
<jcsackett> hatch: you are suggesting a different way for them to work?
<hatch> well, in that you don't call them directly, they are called by events on the master unit list
<hatch> maybe we should have a quick hangout :)
<jcsackett> give me 10 minutes to finish chasing something down in my code, then i'll ping you?
<hatch> ok sure
<hatch> rick_h_ https://plus.google.com/111316263265570636863/posts/Ez97Lppto8v these guys made the skin I have on my phone, and now they are making them for the pebble :) thought you might be interested
<redir> jcsackett: es-update works fine on trusty after insgesting. precise still ingesting.
<jcsackett> redir: ok.
<jcsackett> hatch: i can chat now, if you like.
<hatch> cool one sec
<hatch> jcsackett https://plus.google.com/hangouts/_/7acpi4pk3ossnove1b1upqgskk?hl=en
<redir> bac juju local-provider apparently doesnt' work (out of the box) on lxc (nested lxc) so I am just doing it locally.
<redir> jcsackett: bac http://pastebin.ubuntu.com/7418220/ works on lxc:precise  for me too
<jcsackett> redir: ok, i don't have time to figure out why it's not working on mine--if you and bac can both get it charmworld working on precise with this branch, fair enough.
<jcsackett> i'll approve the MP.
<bac> ftr, i have not tried precise.
<redir> would be nice to have someone else get it owrkking besides me
<redir> new guy
<jcsackett> redir: agreed, we're just starved for time. :p
<jcsackett> rick_h_: do you have time/capacity to QA redir's branch on precise?
<redir> jcsackett: OK I'd ask rick_h_ how important landing it is then
<jcsackett> redir: i think it can probably be blocked on QA for the time being, but yeah let's see if rick_h_ agrees or can unblock it.
<jcsackett> or find someone else who can.
<redir> ack
<jcsackett> of course, he's gone AFK
<jcsackett> :p
<jcsackett> redir: are you at EoD?
<redir> jcsackett: close
<redir> but will be online for a while
<jcsackett> redir: ok. if he doesn't get back to you this evening then at least it's not languishing for a big part of your day.
<jcsackett> or at least not anymore than it already has. :p
<redir> building the local provider thing for bac & rick_h_ now
<hatch> jujugui anyone available for a review for the machine view re-rendering bug fix https://github.com/juju/juju-gui/pull/285
<Makyo> hatch, on it
<hatch> thanks sir
<hatch> hey huwshimi 
<huwshimi> Morning
<hatch> you're here early :)
<hatch> I JUST proposed your branch
<hatch> except it works now :PPPP
<hatch> kehehe
<huwshimi> hatch: Thanks very much!
<hatch> you were very very close
<hatch> gw
<hatch> feel free to take a look at the diff between our two branches if you'd like to see the changes I made
<huwshimi> hatch: It's also a pity that my branch on github doesn't have all the changes I made in it :(
<hatch> uh oh....what do you mean? You forgot to push some stuff up? :)
<huwshimi> hatch: Maybe :)
<hatch> haha I hate you
<hatch> can you do it as a follow-up after this one lands?
<huwshimi> Yeah...
<hatch> phew
<hatch> github doesn't really do collaborative branches very well
<hatch> huwshimi https://github.com/hatched/juju-gui/commit/1ca283b93fa9e33cbe37d7906dd365bd9960166d here is my diff
<huwshimi> hatch: Actually, it looks like a rebase might have killed a bunch of my changes :(
<hatch> aww boo
<hatch> what were they?
<huwshimi> hatch: I think it was mostly to do with setting the header labels correctly. I'll have to fix that all up.
<huwshimi> hatch: It's also missing all my code comments and a bunch of other stuff.
<huwshimi> hatch: I'm surprised the code worked at all.
<hatch> lol
<hatch> it works well actually with only some small fixes
<huwshimi> hatch: I could have knocked off an hour or two earlier :(
<hatch> haha 
<hatch> darn
<hatch> rick_h_ is there a next card you would prefer I hop on?
<huwshimi> rick_h_: ^ let me know if there's a particular card for me today too.
<hatch> he was stepping away a bit ago so he must not be back yet
<hatch> huwshimi if you could do a qa on your branch that would be awesome
<huwshimi> hatch: OK, will
<hatch> thanks
<huwshimi> hatch: No way to undo that rebase is there?
<huwshimi> I know that's probably a stupid question
<hatch> you can :) http://stackoverflow.com/questions/134882/undoing-a-git-rebase
<jcsackett> hatch: where did you find icon data on the service?
<hatch> jcsackett service.icon ;)
<hatch> oh I mean service.get('icon')
<hatch> :)
<rick_h_> huwshimi: adding some uncommitted state would be cool if the machine view stuff is working. 
<hatch> jcsackett https://github.com/juju/juju-gui/pull/277/files#diff-a52e5f6257113ed57354e9aaca710a65R61
<hatch> rick_h_ oo do me next, do me next!!
<rick_h_> hatch: where are we with frankban's branch? We need to get the unplaced tokens showing off that db info
<huwshimi> rick_h_: OK, I'll take a look
<rick_h_> hatch: so any of them around the inspector not showing but getting unplaced unit tokens
<hatch> his branch isn't 'quite' done 
<hatch> it's missing a change unit method and a safety net console.error on the native methods
<rick_h_> hatch: what do we need to get it done. It's holding up all the tokesn which we need to make them actually deploy as a machine/container. 
<huwshimi> hatch: so I did 'git reflog' and now I have a list of actions. I see the line I want to get back to "a3e8f9b HEAD@{21}: commit: Set headers correctly." how do I reset back to that?
<huwshimi> oh, exit the reflog and then 'git reset --hard HEAD@{21}'?
<hatch> yeah
<hatch> that
<jcsackett> huwshimi: awesome.
<huwshimi> scary!
<hatch> (i was typing that) haha
<jcsackett> er, hatch: awesome.
<jcsackett> huwshimi: i'm sure you're awesome too.
<huwshimi> :)
<hatch> huwshimi basically you never want to commit passwords into git because git remembers EVERYTHING lol
<huwshimi> :)
<rick_h_> hatch: so if you can get me unplaced unit tokens when you drag/drop a service that'd rock. 
<hatch> you 'can' delete commits but its lengthy
<rick_h_> hatch: or the card where when you hit deploy you don't get an inspector popping upo
<jcsackett> rick_h_: frankban's branch needs a changeUnits method and some protection around methods on the unitlist we should never ever use.
<hatch> ^ that
<rick_h_> hatch: we need drag/drop of the unplaced token into the other parts
<rick_h_> ok, well if it's something you can do/add then let's run with it
<rick_h_> everything we need to do to make this happen centers around interacting with the unplaced unit tokens
<hatch> I won't be able to finish what needs to be done in his branch in an hour
<rick_h_> hatch: k
<rick_h_> well then one of the others mentioned ^
<rick_h_> just assigned one :P
<hatch> ok hit deploy, not opening the inspector
<hatch> if we have an inspector open it needs to switch to a real inspector though, correct?
<hatch> ohh I see the card
<hatch> rick_h_ so luca is stuck on this 'no-inspector' thing hey?
<rick_h_> hatch: yep
<rick_h_> well Mark S is
<hatch> ugh
<hatch> *muted ugh*
<hatch> lol
<rick_h_> hatch: yea, it does need to switch, but if we don't have it open it sholdn't open on deploy 
<hatch> yeah that's definitely a bug
<huwshimi> hatch: So this branch has the changes the rebase lost: https://github.com/huwshimi/juju-gui/tree/bad-rebase
<huwshimi> for some reason I can't get a diff against my other branch that doesn't have all the changes.
<hatch> huwshimi ok once my PR lands then rebase this branch and PR with it
<hatch> rebase this branch from develop that is
<hatch> now that you got this code back you love git don't you?
<hatch> :)
<huwshimi> hatch: I think you know how much I love it.
<jcsackett> i never thought i would say this, but i miss bzr.
<hatch> rick_h_ ok so dragging a service to the canvas OR clicking the 'add to canvas' does NOT open an inspector......on deploy, don't open any inspectors unless one is already open....if it's open, switch to the service inspector
<hatch> huwshimi lol
<hatch> jcsackett git has too much power for you? :P
<hatch> you can't handle it!
<rick_h_> hatch: right
<hatch> ok on it
<redir> rick_h_: jcsackett couldn't qa ngrams. I can't reproduce his problems, and bac was doing the local demo stuff. Not sure what to do the with the branch.
<rick_h_> redir: we'll have to put it on ice until post-demo time monday
<redir> ack
<rick_h_> redir: the other stuff is priority at the moment then I cna help QA or etc
<redir> ack
<huwshimi> hatch: I've added a couple of comments to the PR
<hatch> thanks, looking
<hatch> huwshimi so after I make these changes it's good to land?
<huwshimi> hatch: Maybe, I wrote most of the code, so I don't think I can give it a proper review :)
<hatch> haha, well did ou QA it?
<huwshimi> hatch: Yeah, it seems to QA ok
<hatch> sounds good, so I'll make these changes and then landed
<hatch> land it
<huwshimi> hatch: But again, as the author of the code, I'm only testing what I know :)
<hatch> huwshimi so if there are no machines then the container column should be cleared as well
<huwshimi> hatch: Yes.
<huwshimi> hatch: The container column will show the containers inside the selected machine (if there is one). If there are no machines then there would be nothing to show.
<hatch> sounds good
<huwshimi> rick_h_: What do we currently have in the machine view panel that can get into an uncommitted state?
<jcsackett> i would just like to take this moment to point out we have both container-token.handlebars and token-container.handlebars
<huwshimi> jcsackett: That's because we have a token-container.js widget and a container-token.js widget :)
<jcsackett> right. so two moments, then, so we can all savor that.
<hatch> huwshimi I'm landing the branch so you should be able to PR yours soon
<huwshimi> hatch: Thanks!
<hatch> jcsackett lol
<hatch> no confusing at all
<jcsackett> and then we just throw in the notion of 'container' as an html node...
 * jcsackett segfaults
<hatch> jcsackett I thought youw ere the one who made the token stuff
<hatch> no?
<jcsackett> hatch: i made the charm token.
<jcsackett> which became the token.
<jcsackett> and then was bisected, to become the bundle token.
<jcsackett> and then...dear god.
<jcsackett> but all i did was make the charm token.
<huwshimi> hatch: I made container-token and macine-token
<hatch> haha "token all the things!"
<hatch> is there an aus meeting today?
<huwshimi> hatch: Not sure...
<hatch> rick_h_ ^
<huwshimi> hatch: Do you know if there is anything in the machine view that can be in an uncommitted state?
<hatch> new machines and containers
<hatch> I also think that assigning a unit to a machine can also be uncommitted 
<huwshimi> hatch: But we don't have any of that functionality now though do we?
<hatch> lemme take a look
<hatch> no we only have deploy, set config, and add relation
<hatch> so far
<redir> amionline
<hatch> yes u r
<redir> rick_h_: bac fwiw, http://bit.ly/1g0VJrw worked for me. It isn't done ingesting but I did manage to turn off wifi and find some charms that were already ingested.
<redir> thanks hatch 
<hatch> :)
<huwshimi> hatch: Here is the final set of changes: https://github.com/juju/juju-gui/pull/286
<hatch> cool I'll take a look in a few
<huwshimi> np
<huwshimi> Need to fix tests anyway
<huwshimi> Fixed.
<jcsackett> Everyone celebrate. I have service units showing in all tokens. 
#juju-gui 2014-05-09
<huwshimi> jcsackett: Yay!
<huwshimi> jcsackett: What's a service units?
<huwshimi> *unit
<huwshimi> jcsackett: Oh, I see what you're saying.
<huwshimi> rick_h_: If you return I have some questions...
<kadams54> Yay!
<jcsackett> evening kadams54.
<kadams54> So does this accomplishment include a PR that needs review/QA?
<jcsackett> kadams54: hopefully, momentarily.
<jcsackett> i'm figuring out how to test something.
<jcsackett> then, yes.
<jcsackett> kadams54: you going to be around for a bit?
<kadams54> As long as it takes to wrap up work on my card
 * jcsackett get zooming on tests
<rick_h_> huwshimi: howdy
<rick_h_> huwshimi: sorry, had a thing with the wife tonight. I meant to mention it when we talked earlier
<huwshimi> rick_h_: It's all good, you've been working a lot :)
<rick_h_> huwshimi: shoot me a hangout url if you want and I'll join in for questions
<huwshimi> rick_h_: I just wanted to ask with the uncommitted stuff if there's actually anything that can be in an uncommitted state currently?
<huwshimi> rick_h_: It doesn't look like we can add machines or containers yet...
<rick_h_> huwshimi: no, but it's next. So I wanted to have the asset and css class ready to add to the tokens
<rick_h_> huwshimi: so I figured we could look at styling the token and testing with it hard coded or something for the moment, so it's one less step one we can create them
<huwshimi> rick_h_: Ah sure, I'll add some uncommitted states then.
<huwshimi> rick_h_: Should I add another card just for the states then?
<rick_h_> huwshimi: yea, and it's kind of shared between the uncommited machine and container
<rick_h_> huwshimi: ? I thought I put your head on a card for the uncommitted state?
<rick_h_> huwshimi: or you mean add a card for making the new machine work?
<huwshimi> rick_h_: Oh, you did, but I thought I couldn't do it. I mean add a card just for the html/css work
<rick_h_> huwshimi: ah gotcha
<rick_h_> ok, that's fine
<rick_h_> huwshimi: do you follow the d3 stuff to look at the card you've got now? 
<huwshimi> rick_h_: It looks quite a simple fix, unless I'm missing something: https://github.com/juju/juju-gui/pull/287
<rick_h_> huwshimi: ooh, super awesome then
<rick_h_> huwshimi: I'll check it out shortly then and QA it
<huwshimi> rick_h_: Thanks.
<huwshimi> rick_h_: In the mockups there are two uncommitted states. One with a blue background and one with blue circles next to the properties. Do you know the difference?
<rick_h_> huwshimi: so they is supposed to be both that I'm aware of. /me goes to look at hte mockups
<rick_h_> ah, these are out of date. So The blue is the background for new machines and new containers
<rick_h_> the circle is used for a machine that exists, but contains an uncommitted service 
<rick_h_> so for the demo purposes we can get away with just the blue backgroud since both the machine and container will be new/uncomitted
<huwshimi> rick_h_: OK
<huwshimi> rick_h_: This isn't going to take long, anything in particular you'd like me to take a look at for this afternoon?
<rick_h_> huwshimi: well I'm going to look through your branches and ant's and then try to wrap up mine. if you get time to check out ant's branch and QA and see how that looks that'd be good
<rick_h_> there's some failing tests I'll help him get through
<rick_h_> after this level of stuff we need to get the drag/drop of unplaced unit tokens to create the machine/container for the demo
<rick_h_> but I think those have to wait until existing branches land
<rick_h_> huwshimi: check outu https://docs.google.com/a/canonical.com/file/d/0B7XG_QBXNwY1MmNDVXNoZDh3VFU/edit and see if we've got any missing UX bits you can see or point out
<rick_h_> it's starting to blur a bit for me
<huwshimi> rick_h_: I could create the 'new machine' and 'new container' forms ready to be hooked up?
<huwshimi> (create the base widget/view and html/css etc.)
<rick_h_> huwshimi: well so the demo is to drag over the header and the header will create the new uncommitted machine
<rick_h_> so I think we'll just have to spin up a token, I'm not sure if the constraint stuff is there atm
<huwshimi> rick_h_: Ah, so we'll by-pass those forms for now?
<rick_h_> It's hard to see in his doc there
<rick_h_> I think we'll drop, bring up a form to select constraints on the new machine and then go there
<rick_h_> so there might be a 'part' of the machine token that needs doing there along the lines you're seeing
<huwshimi> ok
<huwshimi> rick_h_: I guess I can create the header states for dropping too.
<rick_h_> huwshimi: cool
<rick_h_> huwshimi: can you put some notes in the other pull request for me to know what's up in that review? The final machine view rendering/etc.
<rick_h_> qa notes or anything I need for background
<huwshimi> sure
<huwshimi> rick_h_: Updated. Is that enough info?
<rick_h_> cool thanks huwshimi 
<rick_h_> huwshimi: note added 
 * huwshimi looks
<huwshimi> rick_h_: Card added.
<rick_h_> huwshimi: thanks, there may be an existing test but want to make sure we go back on it if not
<huwshimi> rick_h_: Yep, np. I don't remember there being any tests
<huwshimi> bbs lunch
<jcsackett> kadams54: don't know if you're still up, but you won't see a PR from me tonight. rebase just did something awful and i'm too tired to sort it.
<kadams54> Gah! Alright man, get a good night's sleep.
<kadams54> huwshimi: if you're interested, just put up https://github.com/juju/juju-gui/pull/289 which is the animation cleanup stuff that was started in the sprint.
<rick_h_> thanks kadams54 
<rick_h_> kadams54: can you rebase that down please?
<kadams54> Yeah, planning on it.
<rick_h_> kadams54: cool thanks
<huwshimi> kadams54: Great, I'll take a look
<huwshimi> kadams54: QA looks good.
<kadams54> woot
<huwshimi> Ugh, looks like selenium is killing our ci again.
<rick_h_> huwshimi: it's my fault
<rick_h_> huwshimi: there's a flaky test in ant's branch I'm trying to work around
<huwshimi> rick_h_: Oh, that's ok then :)
<rick_h_> yea, it's all my doing and I'm watching it closely 
<huwshimi> Ah good
<huwshimi> I only noticed it in that branch anyway
<rick_h_> finally!
<rick_h_> ok, off to bed for me. Thanks for the great work huwshimi. We're actually going to be closer than I thought we'd be. Might be able to make it with some weekend work
<huwshimi> rick_h_: Great!
<huwshimi> rick_h_: Goodnight :)
<huwshimi> rick_h_: I tried to figure out this bug, but not sure what's going on: https://bugs.launchpad.net/juju-gui/+bug/1317766
<_mup_> Bug #1317766: Hardware info not available when a machine is first added <machine-view> <juju-gui:New> <https://launchpad.net/bugs/1317766>
 * frankban lunches
<rick_h_> morning
<antdillon> rick_h_, morning
<rick_h_> howdy antdillon 
<antdillon> rick_h_, It seems like the summary panel should be its own view?
<rick_h_> antdillon: well, my first thought was that the deployer bar would launch it and watch it for the deploy button or cancel button and update itself based on that interaction
<rick_h_> antdillon: so I'm ok with it being a view on its own, but I think the deployer bar needs to create, watch it, and then handle it
<rick_h_> antdillon: but to start out with you could wire it into the deployer bar view, create a new template, a 'onDeployClick' handler that creates a new div floating with the template info rendered
<rick_h_> there's not a ton in that popup for this demo. Just a list of the two services and such
<antdillon> rick_h_, Yeah  sure
<rick_h_> so rather start small and iterate 
<antdillon> Cool
<rick_h_> so I'd rather start small/simple and iterate if that makes sense
<rick_h_> but tell me if I sound crazy, still waking up 
<antdillon> yeah, i'll get it working from the deployer bar. shouldnt be hard to split out later if we need
<rick_h_> frankban: starting qa, we'll try to round up one or two others to make sure we hit it all
<frankban> rick_h_: thanks
<rick_h_> morning luca 
<rick_h_> luca: is this meeting something we need to do today or can we bumb it post-demo on tues?
<luca> rick_h_: I was literally just about to cancel
<rick_h_> luca: <3
<luca> rick_h_: hehe
<jcsackett> morning all.
<rick_h_> morning jcsackett 
<rick_h_> frankban: qa ok and thanks for making me find a couple of other issues :)
<redir> morning
<frankban> rick_h_: thanks for QAing I also filed two new bugs related to the left inspector
<jcsackett> rick_h_: so, i seem to now only have "view" access to the juju ui calendar--it won't let me make or move an appointment. though it did let me delete it. very strange.
<rick_h_> frankban: yep, putting them on the board as well
<rick_h_> jcsackett: :/ ok will look
<frankban> rick_h_: mine are already on the board
<frankban> rick_h_: in backlock/deck
<rick_h_> frankban: oh ok cool then
<kadams54> guihelp Got a PR that needs review (and more QA wouldn't hurt either): https://github.com/juju/juju-gui/pull/289
<rick_h_> kadams54: yea, all branches need one review and one qa to start
<rick_h_> kadams54: I'll peek in a bit thanks for the ping. 
<kadams54> rick_h_: Looking for another card. Got any suggestions?
<rick_h_> antdillon: how are you doing? Need a hand with anything? kadams54 might be able to?
<antdillon> rick_h_, All good, styling up the panel now
<rick_h_> kadams54: some more qa on frankban's branch would be good, helping out antdillon on the summary view, or looking at the "do not load the real inspector after the deploy" card
<rick_h_> kadams54: are the top of the list atm
<kadams54> kk
<kadams54> frankban: https://github.com/juju/juju-gui/pull/282 right?
<frankban> kadams54: yes thanks
<rick_h_> kadams54: added another bug card that should be a nice one to look at around the missing hardware info.
<jcsackett> ...nothing like figuring out conflicts when all the code you were working on gets smashed by other code...
<rick_h_> jcsackett: that smashed/
<rick_h_> ?
<frankban> guihelp: I have three QA ok for my branch. Can I assume I also have a +1 to land the code?
<rick_h_> frankban: just did it
<rick_h_> frankban: so got you in line after huw's two
<frankban> rick_h_: :-) cool thanks
<redir> bac: yt?
<bac> redir: hib
<redir> bac: I had no problem getting the local demo going. heartbeat shows 3 fails: API* interesting and bundles collection. It is still ingesting though.
<rick_h_> redir: yea, bundles ingest last and part of insteresting is having featured which you don't get oootb
<redir> so it works
<bac> redir: that is good
<bac> redir: thanks for proofing that doc.  i thought things may have changed since it was written.
<redir> np
<redir> I did kill my net and verify that I could find charms too.
<redir> FWIW
<rick_h_> woot
<jcsackett> rick_h_: it's moderately awful. virtually every function i touched has been modified in landed branches. every step has non trivial conflicts.
<rick_h_> jcsackett: ok, let me know if you want to run through it in a pair for an extra set of eyes
<rick_h_> jcsackett: and :( that we managed to overlap that much
<jcsackett> rick_h_: looks like it's fallout from the "don't re-render the entire machine view" and the bit that gets units on machine tokens.
<jcsackett> so maybe once i'm done touching those bits the rebase will calm down.
<rick_h_> jcsackett: cool
<hatch> luca was our call to be rescheduled? 
<luca> hatch: I cancelled it because I didnât want to take up your time when your all so busy
<luca> hatch: itâs low priority for the time being so we can do it some other time
<hatch> alright no problem
<rick_h_> kadams54: heads up, that bad machine data shows up in a live lxc deploy as well. So we need to hit it from both a new server note deployed yet, and an existing lxc one without that data
<kadams54> ok
<kadams54> rick_h_: Would be good to have a pre-impl chat
<rick_h_> ugh, we need cleaner ghost names for services now. 6349192$:db â 63449111$:slave lol
<rick_h_> kadams54: k, shoot me a link
<kadams54> rick_h_: https://plus.google.com/hangouts/_/72cpikalb7ek14gkppcfots2so
<kadams54> I am hungry for lunch.
<kadams54> At 10 AM.
<kadams54> Clearly I am missing the Vegas brunch buffets.
<kadams54> ;-)
<rick_h_> frankban: do you have time to look at esc-enabling the add-unit call in the env ?
<hatch> kadams54 haha
<frankban> rick_h_, kadams54: FYI lxc containers only provide arch
<frankban> rick_h_: add_unit in ecs?
<rick_h_> frankban: yea, so we're just going to go with "Hardware characteristics unavailble"
<rick_h_> frankban: add_unit in the env needs to go through the ecs and then be added to your unit list as a ghost?
<frankban> rick_h_: is there a UX reason why we don't show machines' architetcure?
<rick_h_> frankban: just wasn't on the list from UX
<rick_h_> frankban: I think it's rare for them to vary a lot in an env so it's repeat info
<frankban> rick_h_: ok, so in mass scale when we add units we need 1) to create unplaced units in the db and 2) to register corresponding calls on ecs right?
<rick_h_> frankban: well, I'm thinking all around. When we drag/drop a service we'll create a new service (ghost) but it won't show up in machine view as an unplaced unit unless there's also a ghost-unit on that service
<rick_h_> frankban: so it would work for both the mass scale up, but also just for the demo path of drag/drop a service
<rick_h_> is what I'm thinking
<rick_h_> frankban: and then the machine view panel, watching that new unit list, would update the list of unplaced units in the UI
<frankban> rick_h_: sounds good, I'll tackle that once the units branch is landed. is there a card for that?
<rick_h_> frankban: there is now
<frankban> cool thanjks
<frankban> thanks even
<rick_h_> frankban: cool, your branch should land in about 15min
<rick_h_> it's running through now
<frankban> yeah
<hatch> luca maybe we should also add to this naming thing other 'required' settings too
<luca> hatch: ok will do
<hatch> luca, so if I drag a service to the canvas and then click the 'deploy' should it auto put the unplaced unit on a machine?
<hatch> I'm working on this interaction right now
<rick_h_> hatch: for the demo what we're doing is to create a ghost service with a single unit that frankban is going to make a ghost-unit
<rick_h_> hatch: using the add_unit call, like the mass scale up
<hatch> ok, and for the not-demo?
<rick_h_> hatch: we'll implement the scale up journey in the inspector for existing services and we're in talks with luca on the path for non-existing services
<rick_h_> hatch: probaly on the deployment confirmation page asking you to go and place those units or something
<rick_h_> hatch: but there's some workflow TBD there 
<hatch> oh...ok
<rick_h_> the 'no inspector' was new in vegas and we've not had time to chase the path all the way through yet
<hatch> ok, I've just removed the inspector opening from the charmbrowser right now and I've been finding all of these use cases which seem broken now
<hatch> so that's why Im' asking heh
<rick_h_> hatch: definitely
<rick_h_> hatch: and we'll be asking luca a lot...wed :)
 * hatch shakes fist like an 80s cartoon baddie....."and he better have answers"
<luca> rick_h_: hatch haha Weâll see how the no inspector thing works out
<luca> rick_h_: hatch I would like to test it and see how it feels
<rick_h_> luca: yep
<hatch> atm, not very good :P
<luca> hatch: f u :P
<hatch> lol!
<rick_h_> frankban: landed woot
<rick_h_> jcsackett: Makyo frankban's branch has hit for a nice rebase from develop
<frankban> rick_h_, hatch: thinking about add_unit: I guess we'll need an important change when under mv flag: currently when we deploy from the inspector we pass the provided units to env.deploy. this means right now with a single call we deploy the service, add machines and place units to those machines. we need to instead deploy with numUnits=0, then have the ecs calls reflect this dependency chain: deploy -> addMachines -
<frankban> > place units
<rick_h_> frankban: hmm, can we update the ecs deploy to add the ghost service we need using the existing path?
<rick_h_> frankban: I mean the add_unit needs to be ecs-able, but that's mainly for scaling exisint units which we can come back to if it's not in the line of sight we need for the demo
<rick_h_> existing
<hatch> from what I understand, the deploy will now do nothing but create an unplaced unit
<hatch> so the user will have to take 3 extra steps in this new UI
<rick_h_> hatch: right, but hte service needs to be there as well so that you see it in the service view and when you hit deploy you get the service info
<rick_h_> hatch: right, from the UI perspective right now yes
<jcsackett> rick_h_: whoo!
<frankban> rick_h_: if we need a ghost service that's doable, but when we click deploy we still need things to happen in a specific order
<hatch> yeah we still need the ghost
<rick_h_> frankban: right, which is why I'm wondering if we can work with the current chain 
<rick_h_> frankban: hatch hop on the standup call early?
<hatch> sure
<hatch> ecs supports this type of requirement
<frankban> sure
<hatch> so we can modify the ecs deploy to add a machine if it doesn't have one
<hatch> I think anyways....
<hatch> oh hmm
<hatch> maybe not...
<rick_h_> forget the machine part for now, it'll be manually done and its own ecs line item before services go onto it
<hatch> ok ecs doesn't support adding machines right now
<rick_h_> right, but the env has the call and it's next on the list
<rick_h_> hatch: coming on the call?
<hatch> oh, I wasn't sure HOW early
<hatch> haha omw
<jcsackett> jujugui: call in 2.
<rick_h_> jujugui call now 
<rick_h_> antdillon: you're welcome to join https://plus.google.com/hangouts/_/calendar/cmljay5oYXJkaW5nQGNhbm9uaWNhbC5jb20.t3m5giuddiv9epub48d9skdaso?authuser=1
<antdillon> rick_h_, Sure
<hatch> rick_h_ I was joking about it being Makyo's fault :) but you will probably want to start with the code in ghost-service-inspector.js line 185
<Makyo> Whew!
<hatch> that's where it determines if it should open an inspector or not after clicking deploy
<rick_h_> hatch: yep, will do. I was going to start hunint down anything that creates an inspector
<hatch> the odd part is that it also opens the machine view
<hatch> so there are some crossed wires there somewhere
<rick_h_> yea, will look
 * rick_h_ goes for a little walk for a breather. biab
<hatch> jujugui lf a really quick review/qa https://github.com/juju/juju-gui/pull/292
<hatch> kadams54 when you get a chance can you rebase your animation branch into logical commits plz
<kadams54> hatch: Well now, that's pretty subjective :-) Yeah, I'll rebase it down.
<hatch> haha - I consider a logical commit one that, when landing on in a bisect, doesn't break :)
<kadams54> Done
<kadams54> hatch: --^
<hatch> kadams54 thx, review done with trivial
<hatch> s
<hatch> jujugui so do we have unplaced units now on develop?
<frankban> hatch: we have a db.units model list. so if you use db.addUnits passing a unit with no machine field it is unplaced
<hatch> ok but the UI isn't hooked up to that yet
<hatch> correct?
<hatch> antdillon I just saw the work you did, gw thx
<frankban> hatch: in the machine view panel I see this.get('db').serviceUnits. it should be this.get('db').units;
<antdillon> antdillon, Thanks, little quick
<antdillon> antdillon, Should have the deply summary with you shortly
<frankban> hatch: we also have db.units.filterByMachine(null) which returns all unplaced units
<hatch> frankban yeah ok, I'll take that card to hook the UI up
<hatch> antdillon talking to yourself? ;)
<antdillon> hatch, long week
<hatch> lol
<rick_h_> hatch: you rerunning your tests? That's a spurious IE10 one that hit you
<rick_h_> hatch: do you have a reviewer for yours yet or still need one?
<frankban> rick_h_, hatch: maybe we have a conceptual problem here: to create a new container in the juju-core API we must call addMachines([{parentId: '1', containerType: 'lxc'}]). As you can see, we must know the parentId. Assume (like in the demo) we create a new machine and then a container in that machine. For the second call we must know the id of the machine in the first call. And we only know that when the first call 
<frankban> returns data.
<hatch> rick_h_ I don't think anyone stepped up yet
<hatch> I can re-run it
<rick_h_> hatch: k, will look
<hatch> thx
<rick_h_> frankban: :/ so we have this with services and relations right? We use the temp service name and update it?
<hatch> what he said
<hatch> :)
<jcsackett> rick_h_: ok, i've fixed up the merge of doom, but we have a problem that may or not be minor.
<frankban> rick_h_: for services we already know the service name at the time of the deploy call (we provide the service name)
<rick_h_> frankban: can the ghost machine (representing the container) have a ghost id that's 9999 or z1 or something?
<rick_h_> frankban: and have that updated when we get the parent call back with the new model data?
<rick_h_> jcsackett: heh, hit me. 
<rick_h_> frankban: if not, can we mold the demo so that he first creates the machine and then goes back to create hte container as as second step and be ok?
<jcsackett> rick_h_: so, the logic that now updates the machine tokens only fires when a machine is added--not when a container is.
<jcsackett> so we don't get new service icons on the machine tokens as they're added.
<jcsackett> you can  see them just fine if you click the machine and get the containers, but you'll only see the first service unit icon on the machine token.
<rick_h_> "Hey, let's go deploy mysql, create a new machine yay" hit deploy, go watch it come up in service view, "now let's deploy phpmyadmin, but in a container on that machine" frankban 
<rick_h_> jcsackett: a container is a machine
<rick_h_> jcsackett: so it should fire if I understand things correctly
<hatch> frankban There is a callback which is called after each task executes so we should be able to parse out the new machine names there.... Makyo  this is supported with your executioner right?
<jcsackett> rick_h_: nope. machine tokens are only updated when what the machine view sees as a machine is added.
<jcsackett> (or removed)
<rick_h_> jcsackett: right, but a container is just a machine with a parent id
<rick_h_> jcsackett: so can we not either listen more closely on machine update?
<jcsackett> shorter answer: containers being added to not update machine tokens.
<rick_h_> jcsackett: or something
<jcsackett> rick_h_: we can, i'm just updating you on the branch.
<rick_h_> jcsackett: ok thnking
<jcsackett> as it expands into endless changes. :p
<frankban> rick_h_, hatch looking at the ecs code
<rick_h_> jcsackett: ok, that's fine. It's a step forward and we can hit it up as follow up
<jcsackett> rick_h_: so put it up for review?
<rick_h_> jcsackett: yes
<rick_h_> let's keep the chunks moving
<jcsackett> rick_h_: got it.
<rick_h_> jcsackett: just add a card at the end of the line, but leave it in the ready to code in case we can get to it
<rick_h_> jcsackett: a quick test if a flash back to service view and back to machine view helps the situation?
<hatch> frankban thanks, Makyo did the execution stuff but I remember he built on the callback wrapper which I added already to progress each item in the graph
<rick_h_> jcsackett: e.g. "in the demo, go look at the new block here and back to machine view to get the updated UI"
<rick_h_> jcsackett: the old trick them by never keeping your hands still enough for them to track :)
<jcsackett> rick_h_: i'll check that.
<jcsackett> ...i think that should work, actually.
<rick_h_> hatch: qa issue with your branch, I can't add the relation
<rick_h_> hatch: it needs to also trigger the deploy button function in the inspector
<hatch> ohh ok
<hatch> my bad
<rick_h_> hatch: so the qa steps I'm trying is "drag/drop mysql, drag/drop mediawiki, relate them, go to machine view, hit deploy button, go back to service view"
<hatch> ahhh this UX is so messing with my head
<rick_h_> hatch: yea, undersstand
 * hatch whispers to himself, it's just a demo, it's just a demo
<hatch> :D
<rick_h_> yea, just a demo behind feature flags
<hatch> ok sorry I'll add that in
<rick_h_> thanks
<rick_h_> jcsackett: for the follow up tests add a card please and mark it high priority
<rick_h_> jcsackett: in the on deck lane in backlog
 * jcsackett nods
<jcsackett> rick_h_: for the next thing shall i go ahead and jump on the service units updating on machine token?
<rick_h_> jcsackett: no, hatch did you add the card for showing the unplaced units?
<Makyo> rick_h_, Man, ec2 is slow today.  Confirmed that services are now placed with annotations.
<hatch> rick_h_ I put my head on it, but I wont be able to start on it for a bit
<rick_h_> jcsackett: that card can wait if we've got the "flip views" workaround. We need to get unplaced units showing asap and then start the drag/drop work
<rick_h_> hatch: k, jcsackett can you start with ^
<rick_h_> jcsackett: notes that frankban noted how to update it in irc above ^
<hatch> oooo boy this is quite a bit more work than I had thought......
<jcsackett> hatch: everything on this is more work than we thought. :p
 * rick_h_ ponders evil evil ness
<hatch> haha
<rick_h_> hatch: so let's just say....
<jcsackett> rick_h_: i'm fixing some lint and goofiness on my PR, then i'll check the flip views workaround.
<rick_h_> hatch: that we render the inspector off screen, simulate click deploy button, simulate click close button, carry on
<rick_h_> bah, can't do that 
<rick_h_> when he clicks on the service to make the relation it'll blow up
<hatch> it should be ok, just more work than I thought
<hatch> because we parse the UI for the config options now
<rick_h_> hatch: ok
<frankban> rick_h_, hatch: assume you add two machines and then a container to the first one: from the environment perspective (go.js) we only see something like: addMachines([{}]); addMachines([{}]); addMachines([{containerType: 'lxc', parentId: ?????}]). I can surely add a change focused on the demo (assume the machine added will be the "1") but in general the current design should be improved in some way AFAICT
<rick_h_> hatch: yea, was worried about that. Can we jsut not pass for defaults
<hatch> I've got to compare the formatting but I think we can just pass in the defaults if everything maps correctly
<rick_h_> frankban: agreed, I think we could look at adding a new method like addContainer that can keep some metadata to help track things
<rick_h_> frankban: or update the ecs to start to tag items with a unique id and parentid turns into a ecs parent id?
<hatch> frankban yes the add machine ecs call should generate a uuid for the machine id when it's a 'ghost' machine which others can reference for it's parents
<hatch> uid? uuid? id? 
<rick_h_> so ecs adds machine one and gives it and id $@!# and then the second one gets *(U&& and when you add the container the parent is $@!#
<hatch> d?
<hatch> ?
<hatch>  
<kadams54> guihelp https://github.com/juju/juju-gui/pull/294 is a short QA/review
<rick_h_> kadams54: will look in a sec
<hatch> rick_h_ were you just swearing a lot there? :P
<rick_h_> hatch: :P
<Makyo> kadams54, rick_h_  on it - throw reviews my way.
<rick_h_> Makyo: k
<rick_h_> Makyo: so is your wip card jc's as well?
<rick_h_> they can both go to reviwe?
<rick_h_> review
<Makyo> rick_h_,  I believe the icons-in-tokens work is one branch, so the two have merged.
<rick_h_> Makyo: k
<jcsackett> rick_h_: that's correct--i was doing the exact same thing for both tokens so threw my head on it too.
<jcsackett> rick_h_: checking the "flip" now.
<Makyo> kadams54, +1
<kadams54> Sweet, thanks
<kadams54> Ah hahâ¦ poor Jenkins: http://cl.ly/image/2H0I2N3z1e19
<rick_h_> heh, scale scale!
<kadams54> Well then, I'm going to go get lunch. Hopefully I'll have two successfully built branches ready to ship when I get done.
<rick_h_> jcsackett: :1:'d
<jcsackett> rick_h_: is that thumbs up?
<rick_h_> jcsackett: yes
<jcsackett> rick_h_: flipping works.
<rick_h_> jcsackett: ok awesome, good to know
<rick_h_> we'll have to remember that when we get the script going 
 * jcsackett nods
<kadams54> rick_h_: any prefs on what card to tackle next? Looking at the two drag-n-drop ones right nowâ¦
<rick_h_> kadams54: well those need jc's to have tokens to drag/drop
<rick_h_> kadams54: go grab lunch and we'll organize around seeing tokens and drag/drop when you get back
<kadams54> OK
<jcsackett> hm. lunch. there's a good idea.
<jcsackett> rick_h_: so, last test run failed, make check passes, shall i just :shipit: so kadams54 and others can start work?
<rick_h_> jcsackett: why did it fail?
<rick_h_> jcsackett: I see lint issues
<jcsackett> rick_h_: right, which i fixed in a subsequent push, thus make check is working now. i'm happy to wait for CI to catch the new changes and update.
<rick_h_> jcsackett: oh, gotcha. Sure 
<jcsackett> ...we just seem to be in a sort of panicy hurry. :p
<rick_h_> well let's not panic. 
<rick_h_> but not waste any time :)
 * jcsackett laughs
<jcsackett> a *non-wasteful* hurry, then. :p
<Makyo> jujugui What's a good next card, or does anyone need a second set of eyes?
<frankban> Makyo: I am near my EOD, so if you want to continue my work we can have a quick call
<rick_h_> Makyo: frankban +1
<hatch> Makyo in your ghost relations did you ever run into an error "Charm not loaded" ?
<Makyo> frankban, sounds good.
<frankban> Makyo: cool
<Makyo> hatch, not really, no.
<hatch> ok np
<frankban> Makyo: the branch is in https://github.com/frankban/juju-gui/tree/more-ecs-calls .  I am in https://plus.google.com/hangouts/_/calendar/cmljay5oYXJkaW5nQGNhbm9uaWNhbC5jb20.t3m5giuddiv9epub48d9skdaso
<jcsackett> guihelp: ci is complaining about my branch in a way i cannot reproduce locally. http://ci.jujugui.org:8080/job/juju-gui/933/console
<hatch> oh that error
<hatch> jcsackett it's a sauce labs issue
<hatch> there is actually some poorly written code somewhere in python land
<rick_h_> jcsackett: yea, spurious sauce labs issue
<rick_h_> jcsackett: just kill the "merge request accepted" and let it pick it up again
<hatch> I traced it down at some point but wasn't sure the proper way to fix it
<rick_h_> we're hammering on CI and sauce hard today so spurious seems a bit not so spurious today
<hatch> I wonder if we paid for sauce if we would get better service
<hatch> or if it's the same for open source vs not
<rick_h_> possibly for sure
<rick_h_> jujugui I'm going to go pick up my camper from the dealer and bring it back. I'll be back in a bit. I've given up my card to take one to write out the demo. 
<rick_h_> jujugui the next things are getting the unplaced tokens and then drag/drop to call the add_machine calls in the env. 
<antdillon> rick_h_, I'm going to sumbit my branch now
<rick_h_> antdillon: awesome, kadams54 when you get back from lunch can you look that over, look at possible tests, and qa that ^  please?
<rick_h_> jujugui if anyone has a question or issue while I'm afk call me 248-956-1024 
<hatch> so trusting....so so trusting
<hatch> "for a good time call...."
<rick_h_> :P
<hatch> haha
<rick_h_> I <3 everyone here :P
<hatch> Makyo I can't seem to get add_relation to work on comingsoon via the ecs
<hatch> this did work at one point right? 
<hatch> I can probably bisect to find the issue
<rick_h_> hatch: it does work now. I tested it this morning
<hatch> on comingsoon?
<hatch> I drag mysql and wordpress, long click, relate, then click Deploy
<hatch> then I get Uncaught TypeError: Cannot read property 'command' of undefined
<rick_h_> bah, yea something broken just today
<hatch> poop
<hatch> ok I'll track this down
<rick_h_> oh, reloaded and it worked
<rick_h_> cache/js issue?
<rick_h_> so just worked for me on comingsoon
<rick_h_> http://comingsoon.jujucharms.com/:flags:/il/mv/ deploy and all
<hatch> yeah ok works now
<hatch> what the heck hah
<jcastro> rick_h_, rails bundles still missing for me on jujucharms.com
<hatch> ok I'll update my branch
<rick_h_> jcastro: ok
<jcastro> rick_h_, ok weird
<rick_h_> jcastro: if you get time try it as a differnet branch vs in the same. something is odd, but we keep working on it and then it shows up
<rick_h_> jcastro: but we're in pure demo mode through the weekend until Tues so no bandwidth to look until after Tues
<jcastro> ack, I am also in demo mode to make a bundle, lol
<rick_h_> :)
<rick_h_> we think there's something with the multiple bundles in a file but can't prove it
 * rick_h_ goes afk now for a few
<antdillon> rick_h_, kadams54 deploy summary branch https://github.com/juju/juju-gui/pull/295
<jcastro> does anyone know how I can deploy a personal branch from the gui to the canvas?
<jcastro> http://manage.jujucharms.com/~michael.nelson/precise/elasticsearch
<jcastro> I can't find that branch in the gui
<hatch> jcastro download the charm as a zip?
<jcastro> nm, I had "elastic search" in my terms instead of "elasticsearch"
<hatch> oh :)
<jcastro> - _ -
<kadams54> Back from lunch. Looking at antdillon PR.
<kadams54> guihelp Anyone else been experiencing flakiness with their icons? I've been seeing stuff like this since mid-sprint: http://cl.ly/image/452g3m461j2M
<hatch> can't say I've seen that
<jcsackett> kadams54: yeah, i don't have that happen.
<jcsackett> kadams54: local, on jujucharms.com, both?
<kadams54> localâ¦ haven't checked upcomingâ¦
<jcsackett> kadams54: i would guess than that it's something on your vagrant/host issue.
<kadams54> Probably
<hatch> sweet got the bug
<hatch> kadams54 time to install 14.04 on metal - on your machine there are lots of drivers for it
<hatch> so you won't run into the same issues I'm having
<kadams54> I wish JS had string substitutionâ¦
<hatch> it....does?
<hatch> kadams54 what are you trying to do?
<kadams54> https://github.com/juju/juju-gui/pull/295/files#diff-e6baa739d19ae967f00d894884a065acR265
<hatch> so you want to do something like a printf instead?
<kadams54> In python, I'd handle that like so:
<kadams54> url = 'https://manage.jujucharms.com/api/3/charm/precise/%s/file/icon.svg'
<kadams54> single = dict(icon=url % ecs.changeSet[key].command.args[1],
<kadams54>               name: ecs.changeSet[key].command.args[1])
<kadams54> Yes
<kadams54> Much nicer way of inserting vars into long strings
<hatch> http://yuilibrary.com/yui/docs/api/classes/Lang.html#method_sub
<hatch> it's not quite the same, but close
<hatch> enough
<kadams54> Oh sure, there are plenty of libraries that add the capability
<kadams54> I just wish it was baked in
<hatch> yeah....js is missing....everything
<hatch> lol
<kadams54> I wish python had JS' more flexible lambda function
<hatch> but at least the prototypal system is very flexible 
<kadams54> And I wish JS had python's list comprehensions, string substitutions, and syntactical succinctness
<kadams54> But they're just never going to hook up and make babies, so all I can do is hang my hopes on ECMAScript 6/7/8 :-)
<hatch> haha
<hatch> maybe by 2020 it'll be caught up
<hatch> but by then Dart will be in all the browsers and people will use it instead.....*snort*
<kadams54> I'm pretty sure that by 2020 we'll be mired in WW3
<kadams54> After which JS will be everywhere and dead at the same time
<hatch> yeah you're probably right on that
<kadams54> No, noâ¦ Bernhardt's right.
<hatch> I don't get the reference
<kadams54> https://us.pycon.org/2014/schedule/presentation/186/
<kadams54> Pretty sure you saw the video of this talk?
<hatch> oh yeah
<hatch> apparently deploying a service with 0 units is a nono
<kadams54> Were explosions involved?
<hatch> not sure, I walked away, cool guys don't look at explosions 
<hatch> Makyo you kickin around?
<hatch> Makyo when you get a chance do you remember what lines 39-45 are for? https://gist.github.com/hatched/cdc73083450dc0eaa02b I've rewritten this callback handler and it doesn't seem like they have any effect...
<Makyo> 1 sec.
<hatch> yeah no rush
<Makyo> The topo retains a list of wrapped services in service_boxes.  The ids of those are the <randomNumber>$ style, so on success, this replaces that object in topo.service_boxes with something the more closely matches what will be received in the delta.  Without it, in a real env, the box would disappear, then reappear on the delta, anything from a flicker to a disappearance.
<hatch> ahh ok cool I'll add a comment to that effect
<hatch> thx
<Makyo> np, sorry it wasn't well commented
<rick_h_> how goes?
<rick_h_> kadams54: so with ant's branch can you take that over, clean up the items you had questions on and work towards a landing
<rick_h_> kadams54: file a new card in the on deck land marked high priority for missing tests
<rick_h_> kadams54: and no not seen the icon issue
 * jcsackett hates CI.
<jcsackett> but is in a better mood, having finally had lunch.
<rick_h_> jcsackett: I kicked it for you
<jcsackett> rick_h_: it looks like there might be another damn merge conflict.
 * jcsackett is *never* getting this done.
<rick_h_> jcsackett: :(
<rick_h_> almsot there?
<rick_h_> happy happy
<jcsackett> yeah, i'm almost there.
<jcsackett> hating on tools, but almost there.
<jcsackett> does git have other merge patterns? b/c it's dying on *stupid* shit. :p
<kadams54> rick_h_: Yup, no problem. I'd already started on the tests.
<rick_h_> crap, I think I left my nice notebook at the grocery store doh
 * rick_h_ bangs head on wall
<kadams54> Notebook on aisle 5, notebook on aisle 5.
<jcsackett> that's a fine notebook, dude. my condolences.
<jcsackett> also: conflict fixed. let's try this *again*.
<rick_h_>  yay
<jcsackett> rick_h_: do i need to :shipit: again?
<rick_h_> hatch: how goes your branch?
<rick_h_> jcsackett: no, just remove the "merge accepted" message
<rick_h_> jcsackett: if that's not there it'll repick it up
<hatch> rick_h_ done, just need tests for this new setup now
<rick_h_> hatch: woot
<hatch> eating lunch now
<rick_h_> hatch: gotcha, cool thanks. 
<hatch> the only downside is that you must deploy a service with a single unit
<hatch> so I'm doing that part in a follow-up
<rick_h_> hatch: ok
<jcsackett> ok, i've completely lost mental state.
<hatch> to make a 'non attached' unit
<hatch> jcsackett spend too much time in Colorado? 
<hatch> kehehe
<jcsackett> i live in the south dude. we kill our brain cells with moonshine, not plants. :p
<hatch> haha
<rick_h_> ok, going to dare to run to the store and hope my notebook is there while I wait for a call :/
<rick_h_> wish me luck
<jcsackett> rick_h_: i know you said something about this earlier, but i've lost track. what should i throw myself at, kamikaze like, next?
<jcsackett> also: good luck.
 * jcsackett waits to see if the question was sent in time...
<jcsackett> guess not. jujugui, anyone need reviews or something?
<hatch> nothing here yet
<jcsackett> blast.
<rick_h_> jcsackett: ok so next is the unplaced unit tokens
<rick_h_> frankban had notes in irc easlier on the fix
<rick_h_> don't look at serviceUnits but just .units and something else
<rick_h_> and got my notebook back yay!
<jcsackett> rick_h_: ...while i recognize those as words that relate to machine view, they aren't coming up in a cogent form for me. chat?
<rick_h_> jcsackett: sure thing
<jcsackett> rick_h_: https://plus.google.com/hangouts/_/gzrh7sh4g3zbscs42oajucofsia?authuser=2&hl=en
<antdillon> kadams54, thanks for the review
<Makyo> jujugui Does anyone besides frankban know how the AddMachines API call works?
<Makyo> (specifically whether or not you can refer to a machine later on in the list of MachineParams, i.e.: [{create machine 1}, {create lxc on machine 1}] in the same API call.)
<rick_h_> Makyo: I'm not sure on that. Honestly, I'd just try it and see if it blew up or errored. Maybe ping someone in core?
<Makyo> rick_h_, doing that now.
<Makyo> Have a path forward for the moment, at least.
<rick_h_> Makyo: cool, looking for the code atm
<antdillon> kadams54, Added your QA things to the branch
<kadams54> OK, thanks
<antdillon> kadams54, Thanks
<antdillon> rick_h_, the deploy summary only supports deploys and add relations at the moment as it seems to be all the ecs records
<kadams54> What about the expand icons? Is that in scope, or to be implemented in a different card?
<antdillon> Oh sorry yea, they are placeholder at the moment
<kadams54> OK, thanks
<antdillon> kadams54, They jump to much different views
<kadams54> cool
<antdillon> Also click the number of changes in the bottom left doesnt open the small summary
<bac> ping rick_h_
<kadams54> Yeah, I noticed :-)
<antdillon> kadams54, Another branch for that stuff, I reckon
<Makyo> rick_h_, got an answer, adding it to our yuidocs
<rick_h_> bac: pong
<rick_h_> Makyo: cool
<rick_h_> antdillon: ok, we're working on getting add machine/container going right now
<rick_h_> antdillon: so we'll look if we get that working adding or whatever
<bac> rick_h_: do you have time for a quick update call?
<rick_h_> bac:  sure thing
<bac> ok, standup
<rick_h_> bac: can you invite me there please?
<rick_h_> jcsackett: landed yay
<bac> rick_h_: let me just call your cell
<jcsackett> rick_h_: oh hallelujah.
<jcsackett> rick_h_: so, we're getting unplaced units and generating tokens, but they're not rendering right. this is slightly more involved, but i'll keep digging.
<jcsackett> whereever i am by EoD i'll push up so someone else can grab and run if they're working over the weekend.
<jcsackett> s/rendering right/rendering at all/
<hatch> rick_h_ https://github.com/juju/juju-gui/pull/292 ok all ready not
<hatch> now
<hatch> you can now, deploy mysql/wordpress/relate them, click deploy
<hatch> all without the inspector
<hatch> rick_h_ are you no longer working on the inspector opening after deploy?
<hatch> rick_h_ well it appears that my branch has fixed that bug by bypassing that codepath entirely
<hatch> jcsackett how goes the battle? When is your EOD?
<huwshimi> rick_h_: Just wanted to check in and see how things are going?
<hatch> huwshimi well, some of us are going to be picking up some hours this weekend to try and get the board cleared
<hatch> for the demo
<jcsackett> hatch: EoD is at six. battle's is indeterminate. not yet sure why the service icons don't go poof.
<jcsackett> er, go poof.
<hatch> jcsackett what's that in UTC? 
<hatch> timezones are for suckers
<jcsackett> uh...22UTC, maybe?
<jcsackett> shit i dunno. i'm on EST.
<rick_h_> jcsackett: yea push and I can look
<hatch> ok in an hour then
<hatch> :)
<rick_h_> hatch: will check it out
<rick_h_> hatch: jcsackett yea, please push your stuff, with good notes in the pull requests
<rick_h_> it's time for me to take the camper to the campground (actuall 3hrs late)
<rick_h_> once we get setup I'll go through stuff tonight
<rick_h_> so will be afk for a few hours driving and setting up the trailer
<rick_h_> thanks!
 * rick_h_ runs away
<hatch> cya
<bac> redir: you around?
<redir> bac: yep
<bac> redir: i was having a mapping format exception issue with ES.  but now it looks like it may be working!
<redir> bac: not for much longer. we have out of town guests coming for a dinner party this eve
<bac> ohh, a dinner party!  will you be serving negronis?
 * redir blinks
<redir> heh
<jcsackett> oh ho, someone didn't put `this` into a loops scope.
<jcsackett> huzzah, this may be easy.
<redir> they don't drink
<bac> more negronis for you then
 * bac cannot stand camparai
 * bac cannot spell campari
<bac> sweet, i just ingested a directory full of local charms.
<huwshimi> hatch: That card you just picked up, how do you get a unit in the unplaced column?
<hatch> atm, you don't
<hatch> jcsackett is working on that right now
<huwshimi> Ah
<hatch> you can create unplaced units not but I'm pretty sure they don't show up in the UI yet
<hatch> I'm just going to make the headers drop targets
<huwshimi> hatch: In the header widget I've added the drop state to the headers (just the styling at this point)
<huwshimi> hatch: So you can do .setDroppable and it will switch to the correct state.
<jcsackett> hatch, huwshimi: to be clear, i'm just making sure they render in the UI.
<jcsackett> i'm doing nothing about placement etc into that unplaced thing.
<jcsackett> i'm about to push it up for PR, just doing some CSS tweaks now.
<hatch> jcsackett when you're done, unplaced units will be listed in the first column through right?
<redir> bac: you have local demo all tidy?
<bac> it looks pretty tidy
<bac> redir: you can play with it if you're intersted
<hatch> in your PR can you include the commands/process to get the units to show up there plz 
<hatch> ^ jcsackett 
<hatch> huwshimi I see, thanks
<huwshimi> hatch: Also, on the scale up UI, it seems that the form should close when you click "add units"
<hatch> PR's accepted
<jcsackett> hatch: planning on it.
<hatch> .....lol
<hatch> jcsackett thanks
<bac> redir: it is at ~bac/charmworld/ingest-local-charms
<bac> er, lp:~bac/charmworld/ingest-local-charms
<kadams54> Taking a break for family stuff. Will be back on after the kids are in bed tonight. Planning on landing ant's deployed changes summary panel work at that time.
<bac> redir: i simply introduced a new cmd-line option to ingest-queued:  --local-repo=<path>
 * Makyo -> dogwalk
<redir> bac I'll try it monday
<redir> I'll need to get a directory of charms from somewhere though
<bac> redir: 'charm-tools get'.  that may be more than you want...
 * bac walks dog
<jcsackett> hatch: take a look at https://github.com/juju/juju-gui/pull/296 ?
<hatch> jcsackett on it
<redir> bac: I have charm-tools which gives me charm-get, is that what you mean?
<redir> and download them one at a time/
 * redir goes to start making dinner RSN
<hatch> jcsackett it doesn't work
<jcsackett> zuh?
<hatch> when I run the cli command the inspector shows that there are more units
<hatch> but there are none in the unplaced units column
<hatch> I have to close/open it
<jcsackett> right, _renderServiceUnit only executes when the machineviewpanel is first rendered.
<hatch> or is that what branch was supposed to accomplish?
<jcsackett> that's all this does.
<hatch> ohh ok
<jcsackett> just gets the _render thing to work as it is now.
<jcsackett> there are still bugs.
<hatch> can you create a card for the databdinging units list
<hatch> plz
<jcsackett> sure.
<hatch> thanks
<hatch> looks like we'll need some styling on it too
<hatch> it being the unit tokens
<huwshimi> jcsackett: Feel free to give me a card to style them.
<jcsackett> huwshimi: okay.
<hatch> huwshimi it will be a bit, I need to do the review and then it needs to land, just fyi
<hatch> jcsackett how come there are no tests? 
<hatch> are they coming?
<jcsackett> hatch: b/c all i did was update existing code.
<jcsackett> and yeah, i'm adding high priority on deck cards.
<huwshimi> jcsackett: No problems. I'll have my Monday while you guys are sleeping too.
<hatch> that's a little creepy 
<hatch> lol
<hatch> jcsackett so are there no tests for this functionality then?
<jcsackett> hatch: only what tests were there before, and i can't imagine they were very good.
<jcsackett> hatch: i can try to get tests in the next 30 min, but we don't have much setup in the way of isolation for these bits right now.
<jcsackett> not sure i'll get anywhere.
<hatch> jcsackett see test_machine_view_panel.js
<hatch> lots of tests there
<jcsackett> hatch: yeah, i just realized i was running make test-debug on develop, which is why everything passed. :p
<hatch> haha
<hatch> I have it a +1 so once tests pass and there are new ones it can be landed
<hatch> if you don't get all the way finished I can take over
<jcsackett> hatch: do our tests not use our css in the less files?
<hatch> nop
<hatch> well
<hatch> that's a lie
<hatch> unless the module loads it in itself
<hatch> it's not there
<jcsackett> ah. how does the module load it?
<hatch> I don't think any do
<jcsackett> hm.
<hatch> not anymore anyways
<hatch> what did you need the css for?
<hatch> should be functional without?
<jcsackett> there's some stuff in the serviceunit token that had style="display: none" in the html, which i moved into the css.
<jcsackett> but there are tests making sure those bits don't start out visible.
<jcsackett> ...should that whole block just start with the hidden class, come to think of it?
<jcsackett> or is that only display: none by default for actual YUI widgets?
<huwshimi> jcsackett: It might be fine to just check the css class is applied
<huwshimi> (without knowing if that css applies the display: none)
<jcsackett> huwshimi: eh, i guess. but just checking "class=details" seems like an unnecessary test.
<hatch> all we got, until we start doing real renderings in the tests
<jcsackett> hatch: can you call "show" and "hide" on arbitrary nodes?
<hatch> if they are Y.Node instances yes  - http://yuilibrary.com/yui/docs/api/classes/Node.html#method_show
<jcsackett> hatch: and that just applies ".hidden" right, or does that actually set the style?
<hatch> both I think - sec
<hatch> http://yuilibrary.com/yui/docs/api/files/node_js_node-view.js.html#l34
<hatch> adds a hidden attribute
<hatch> and sets the style on the element
<jcsackett> yeah, i just found it too.
<jcsackett> ok, so i'll update the "style=None" to start with .hidden class and check for that in tests.
<hatch> so confused
<hatch> I'll take your word on it 
<jcsackett> hatch: it'll make sense when you see the updated PR.
<hatch> oh kay!
<jcsackett> hatch: i've pushed to the PR--the test isn't actually passing yet, but i'm going to have to let you run with it.
<jcsackett> i've got to EoD and get to a dinner.
<hatch> sure np
<hatch> enjoy
<jcsackett> thanks.
<jcsackett> have a good weekend, all.
<rick_h_> howdy
<rick_h_> from the campground
<rick_h_> 4g in the wood yay
<rick_h_> woodsd
<rick_h_> woods
<rick_h_> hatch: so you're running with jc's branch on the test side?
<hatch> yeah, just doing some house stuff now
<hatch> will try and get it in and landed tonight
<rick_h_> hatch: ok cool, going back to your branch now
#juju-gui 2014-05-10
<rick_h_> hatch: does jcsackett's branch work with yours then? e.g. can I qa them together and get a drag/drop with a ghost unit? 
<hatch> I think so, his branch doesn't auto update, you have to close then re-open the machine view for his to render the units
<hatch> there is a card on the board to databind that list
<rick_h_> k
<rick_h_> hatch: is the other one in review in kanban up on github? 
<rick_h_> going to get ice cream, will look at more soon
<antdillon> rick_h_, my deployer summary branch is ready for another review
<antdillon> rick_h_, Kyle QA'ed but not merged yet
<hatch> rick_h_ this branch does both of them
<hatch> unless you've found otherwise
<kadams54> antdillon: I'm currently working on tests for the branch; I'll merge once those tests are finished.
<antdillon> kadams54, Ah thanks, wasnt should if I needed to put in another pull request or not
<kadams54> antdillon: Nope, I'll take it from here. Thanks!
<antdillon> kadams54, Thanks man
<rick_h_> antdillon: cool, will look
<rick_h_> oh kadams54 is the case
<rick_h_> hatch: oh cool, yea didn't notice it tbh, but now that you mention it
<hatch> :)
<hatch> 2-birds
<hatch> I may end up doing the token drag and the dropping
<hatch> the tasks may end going hand in hand
<rick_h_> hatch: yea, I wasn't sure how much parallel we could get out of it
<rick_h_> and I figure once one is done, the other is almost a dupe to the same calls, just with a parent id
<hatch> yeah
<rick_h_> for the containre to know what machine it's in
<hatch> will play it by ear
<hatch> brb gota go bring the plants in
<hatch> supposed to get to -4 tonight
<rick_h_> ouch
<rick_h_> 10 here
<hatch> yeah it's a little odd it's getting so cold
<hatch> my guess is that it doesn't get that cold
<rick_h_> well we had a frost warning this week
<rick_h_> but think it'll be the last
<rick_h_> ok, emailed Mark S with a link to the latest on comingsoon. /me ducks
<huwshimi> :)
<rick_h_> how goes huwshimi? 
<huwshimi> rick_h_: Good thanks. Nice to have some family time :)
<huwshimi> (laptop next to me as we play with Lego)
<huwshimi> rick_h_: Sounds like your family time is interrupted by 4g :)
<rick_h_> huwshimi: well, I think I'm going to bed on time tonight
<rick_h_> but yea, told the wife I'd take her camping for mothers day so got the camper out here
<rick_h_> didn't say I'd stay off the laptop :P
<huwshimi> haha
<rick_h_> but about beat, crazy day today
<huwshimi> rick_h_: Make sure you assign anything you want to me for Monday. I'll see if I can pick up something over the weekend too.
<rick_h_> huwshimi: sure thing, thanks. I honestly think we're in good shape. If matt and frankban get the change set stuff working and the rest of us get drag/drop working it's demo-able
<rick_h_> huwshimi: so it'll probably be asking you to follow behind us and clean up any little things to help polish it up. 
<rick_h_> there's definitely some spacing things atm, I'll try to look at it with clear eyes tomorrow
<huwshimi> rick_h_: Yep, no problems. I'll try and do a bit of general QA once those bits are in.
<rick_h_> morning, phew crashed last night
<rick_h_> love a good sleep outdoors
<kadams54> rick_h_: Morning
<kadams54> rick_h_: Saw your comments on the testsâ¦ FYI, I have the problem narrowed down to one line of code, but I don't understand why that one line is problematic or how to fix it.
<kadams54> rick_h_: Looking for my next cardâ¦ as I understand, the drag/drop stuff is closely tied to Jeff's work. Maybe the card for databinding the unplaced units column?
<rick_h_> kadams54: +1
<kadams54> kk
<rick_h_> kadams54: I'm not sure if that needs to hook into databinding or just YUI events watching the db now
<rick_h_> he made the card to say databinding, but I think it's just db watching like other places in the machine panel view
<rick_h_> kadams54: a couple of QA things on the summary, I noted them in the card under polish in the description
<kadams54> ok
<rick_h_> ok, status email sent, couple cards added for polish/etc. Going to take a break an walk the dog
<rick_h_> biab
<hatch> hello fellow weekenders
<antdillon> hatch, Hey
<hatch> hows it going antdillon ? pulling some weekend hours too?
<antdillon> hatch, Na it official like, just checking all's good
<hatch> so far :) 
<hatch> rick commented that there were some qa issues with your branch
<hatch> not sure what they were yet
<hatch> I probably won't get a chance to look at it this wkend
<antdillon> hatch, I'll take a quick look
<antdillon> hatch, I fixed up Kyle QA last night. He's landed it all now
<hatch> oh cool
<hatch> jcsackett are you around?
<antdillon> hatch, I'll be around a bit tomorrow to help out if your guys have any styling stuff
<hatch> ok cool
<Makyo> hatch, ping
<hatch> hey 
<Makyo> Running into a weird JS problem.
<hatch> ok, shoot
<Makyo> this.changeSet has one property, addMachines-866, but this.changeSet['addMachines-866'] is undefined.  In the JS console, it shows as (...)
<Makyo> Have you run into this before?
<Makyo> I remember I have, but I can't remember the workaround
<hatch> try console.dir(this.changeSet['addMachines-866'])
<Makyo> console looks like https://gist.github.com/makyo/25153ef6db7b152dc8e5
<hatch> yeah, try using console.dir
<Makyo> Just says undefined.
<hatch> hmm
<Makyo> Trying to figure out where it's getting set to that.
<hatch> ohh, are these defined properties
<Makyo> Nope.
<antdillon> Makyo, I used the changeSet ok in the deployer-bar.js is that helps
<hatch> has antdillon's branch landed in yours? The one with the Object.observe pollyfill?
<hatch> I wonder if that's converting it to a defined property
<Makyo> Hmm, maybe.
<hatch> the getter and setter is throwing me off
<hatch> why would those be there if there wasn't a defined property
<Makyo> Ah, yep.
<Makyo> That's probably what's happening.
<Makyo> Alright, thanks.
<hatch> np, not sure what the solution is though :)
<Makyo> Me either, but it gets me on the right path as to why it's still in the object.
<Makyo> Or not, hah.  Well, I'll keep poking around for another few minutes.
<rick_h_> hey guys
<rick_h_> bah, missed ant
<rick_h_> if ant comes back we could use some info on what design he was doing the deployment summary to
<rick_h_> the qa issues were after it landed, so they're current issues
<rick_h_> hatch: let me take jc's card then you and you run with drag/drop stuff
<hatch> Makyo darn...well I'm about to land jc's branch
<rick_h_> hatch: ok, well never mind
<hatch> yeah the tokens are super broken though
<hatch> but they show up
<rick_h_> ok, well we can update them
<rick_h_> yea, that's good enough, to have divs to start to drag/drop
<rick_h_> I can look at them then and see if I can update them to less broken state
<hatch> yep got that :)
<hatch> just running local lint and tests
<rick_h_> coolio
<rick_h_> hatch: prioritize dropping on a container in an existing machine over new machine
<rick_h_> hatch: sounds like that's the demo, have an existing bnudle running, add nagios server, place it on an existing machine, hit deploy
<hatch> ok the demo wireframe has it dropping on a machine as well
<hatch> If you download the pdf you can zoom into it more
<Makyo> hatch, it's Object.observe's fault.  I have a workaround.
<rick_h_> hatch: yea, forget that wireframe
<rick_h_> hatch: new plan
<hatch> Makyo ahh, well that was a pretty good guess then :)
<hatch> rick_h_ lol oh boy
<rick_h_> jujugui just copied everyone on an email where I'm working with othres to get into the official demo plan on things
<rick_h_> hatch: well it's simpler tbh
<hatch> yeah - I'm happy with simpler :)
<rick_h_> hatch: no relations, no config, just place one service on an existing machine
<rick_h_> hit deploy, get the summary, confirm, done
<hatch> drag from unplaced to a container.....got it
<rick_h_> hatch: rgr
<rick_h_> Makyo: ^ I don't think it savesus anything on the ecs-machine end but fyi
<hatch> css shapes are pretty cool http://alistapart.com/article/css-shapes-101
<hatch> hehe python interpreter written in JS is faster than Cpython :P https://rfk.id.au/blog/entry/pypy-js-faster-than-cpython
<rick_h_> :P
<hatch> rick_h_ I've figured out what locks us in the machine view panel
<rick_h_> hatch: orly cool
<hatch> if you try and add units to a service which doesn't exist, then click machine view, you can't click back
<hatch> the addUnit code isn't resilient I guess
<rick_h_> gotcha, ok. Well we can avoid that thankfully for now and will add a card
<rick_h_> card added
<rick_h_> hatch: ok, so with JC's branch and yours we don't see tokens from undeployed units because creating a service doesn't create the one ghost unit yet right?
<hatch> correct
<hatch> you actually cannot deploy a service with 0 units
<hatch> it errors
<hatch> but that doesn't mean that that unit couldn't be unplaced I suppose
<hatch> I haven't looked into why it errors yet
<rick_h_> hatch: ok, I wonder if kadams's branch touches this at all
<hatch> umm
<hatch> no it wouldn't 
<hatch> but I'd like to chat with him about that branch because he can use the same code that's used in the machine list and mass scale up service list
<hatch> save him a bunch of time writing it himself
<hatch> rick_h_ was he putting in time this weekend?
<rick_h_> hatch: yea, he was around this morning
<rick_h_> hatch: k, use email then for now to send that out
<rick_h_> and I'll try to catch him and point him at it 
<hatch> ok cool, will do
<hatch> email sent, and cc'd u
<rick_h_> ok, so I'll start look at that getting a single unplaced service going. Then we can look at styling the token shown to be pretty
<rick_h_> hatch: cool thanks
<hatch> yeah that sounds good - have fun in environment land....there be dragons in there :)
<rick_h_> ruh roh
<hatch> ben wrote it, blame him
<hatch> lol
<rick_h_> lol, good to know
<hatch> this demo is nuts
<hatch> at least he made the bundle look pretty
<hatch> ish
<rick_h_> :)
<hatch> it would be cool if you clicked on a service if it would hide all services not related to that one
<hatch> in a complex env like that
<rick_h_> yea, that's the plan :P
<rick_h_> in the filter settings ui for the left panel
<hatch> rick_h_  Once the user starts to drag, the headers turn into their drop target UIs, The container/machine tokens stay the same UI. And if the user drops on a blank space the unplaced token being dragged snaps back to the original place and everything returns to normal 
<hatch> that all sounds like the proper UX?
<rick_h_> hatch: sounds good to me
<hatch> :+1:
<Makyo> Woo, only 233 failures.
<rick_h_> lol
<hatch> party on!
<hatch> :beer:
<hatch> Oo boy I forgot about IE testing....
<rick_h_> heh
<rick_h_> follow up card, we don't be using IE
<hatch> now the question is....how do I do testing in IE with vagrant running...
<hatch> hmm
<rick_h_> fire up a sauce IE session and point it at your home network
<rick_h_> or bring up an IE VM using anything else
<rick_h_> can't you run vbox/fusion/etc locally? 
<rick_h_> and point it at the vagrant ip
<hatch> vagrant uses virtual box, and my win 8 vm is on parallels
<hatch> opening up both vm engines causes a kernel panic
<hatch> parallels runs windows extremely well 
<rick_h_> oh, well that sucks
<rick_h_> so create an IE VM in virtualbox?
<hatch> the good news is that dragging and dropping a unit on a container token (third column) now works 
<hatch> rick_h_ when I drag and drop a charm then click deploy the deploy list shows a service to deploy then switches to 'no uncommitted changes' right away.....
<hatch> confirm still works....but did you know about this bug?
<rick_h_> no, I've not seen it
<rick_h_> oh now I do :/
<rick_h_> hmm, it was just working
<rick_h_> I added cards to fix broken icons and such on it
<rick_h_> actually it works in my fresh checkout
<rick_h_> hatch: try before your last landing of pr/298?
<rick_h_> hatch: hmm, only does it the first time the button is pressed
<hatch> yeah
<rick_h_> close and go back and it's there
<hatch> this was somehow caused by the changes from jc's branch you're saying?
<rick_h_> woot got a token to show up
<Makyo> Down to 2 failures, but now tests crash.,
<rick_h_> hatch: well I'm asking. I hadn't seen this behavior until you just mentioned it and I qa'd it several times today
<rick_h_> hatch: so pondering something changed
<rick_h_> Makyo: heh, comment out the deployer bar tests and see if it still happens
<rick_h_> Makyo: in the index.html, those were crashing for me though kadams thinks he got the one doing it
<hatch> oh, I've got a few too many changes right now to bisect back but I can in a while
<rick_h_> hatch: rgr, I'll add a card to look into it
<hatch> Makyo tests always crash for me, I have to use test-server
<Makyo> hatch, this is test server
<hatch> it's painfully slow, but.....such is life
<hatch> oh....
<hatch> :'(
<Makyo> Something's inflooping
<Makyo> Huh, must just be a browser thing.  All tests pass in test-debug; the two failures were about the cookies being set.
<Makyo> So...bonus!
<rick_h_> heh woot
<rick_h_> does it crash in both FF and chrome?
<Makyo> Haven't tried FF yet. Will now.
<Makyo> rick_h_, Everything's fine in FF.  Just some weirdness in chrome, I guess.
<rick_h_> Makyo: hmm, ok good to know
<Makyo> Oh, I had a another window of tabs open.  Wonder if something's stealing resources.
<hatch> nom nom resources
<rick_h_> bah, this is such a twisted bit of code
<rick_h_> was never meant to do this
<Makyo> Chrome works, but still has the two cookie banner failures.
<Makyo> Oh well.
<Makyo> Let me commit and push.  guihelp if anyone has a moment, I might ask for a test-run on chrome
<rick_h_> Makyo: rgr
<rick_h_> I might need a pre-imp or help with this branch
<rick_h_> I somehow got it to work once but now can't again and no idea how it worked the first time
<Makyo> guihelp: https://github.com/makyo/juju-gui/tree/more-ecs-calls
<rick_h_> Makyo: pulling down
<rick_h_> ty verizon for letting me know I've not hit 75% of my monthly bandwidth allotment
<rick_h_> Makyo: ran here, one failure but can't find it yet
<rick_h_> when I click on the 1 failure it opens "removes the drag handlers" test
<rick_h_> no cookie issues here
<Makyo> Hmm.
<hatch> rick_h_ how much data do you have on that hotspot?
<rick_h_> hatch: 10GB/mo
<hatch> oh haha that's tons
<rick_h_> crossed 7.5 with about 8 days left in the cycle
<hatch> lol netflix?
<rick_h_> well, with the sprint and such
<rick_h_> no, no movies
<hatch> I've only ever once gone over and that's from downloading hd movies on itunes
<rick_h_> did that once, downloaded a movie for the boy while camping, 3.3GB eats a ton of space
<rick_h_> I did get a new hotspot now that should work internationally so can only have one wheee
<hatch> oh rock on
<hatch> what's that plan cost? must be pricey 
<rick_h_> ok, well the 10G is shared between hotspot, my phone, wife's phone
<rick_h_> for all three it's aroud $200/mo
<rick_h_> my phone usually does 1-2GB and she does around 500MB and rest is for hotspot
<rick_h_> where the $#@$#@ does the ghost service get its unique id from?
<hatch> ouch your cellular service is such a ripoff
<rick_h_> woot!
<rick_h_> wow and I do get a machine with the service
<rick_h_> crazy
<Makyo> app/models/models.js:494
<rick_h_> Makyo: thanks, I realized I could just use the ghostService there. So I can drag/drop and get an unplaced unit token to show up 
<rick_h_> total hack but wheee
<rick_h_> hmm, wonder if you can deploy a 0 unit service to lxc
<hatch> ok tokens can now be dragged and dropped 
<hatch> jujugui should we destroy/re-create units when the user places an unplaced unit in a machine....or modify it the original
<hatch> ^ this will have to be ecs'able
<hatch> good morning huwshimi 
<huwshimi> hatch: Morning
<huwshimi> hatch: How's it all going?
<hatch> well I think
<huwshimi> Good :
<huwshimi> *:)
<hatch> I landed jc's branch so it can be styled now
<hatch> are you working today?
<hatch> it's like 730am there right?
<rick_h_> hatch: https://github.com/juju/juju-gui/pull/299 is what I've got working
<hatch> looking
<rick_h_> hatch: so I think the only thing we'd have to modify is the machine 
<rick_h_> though I'm still working through how this is going to work. 
<hatch> right, but the act of dragging an unplaced unit to a container still needs to be added to the ecs right?
<hatch> so we need a 'modify unit' in the ecs as well
<hatch> cool hack.....not sure that feels right though as an official implementation :)
<hatch> or maybe it does.....
<rick_h_> hatch: yea, no kidding. But if addUnits is ecs-ified...
<hatch> a service without a unit.....is kind of pointless.....
<hatch> so they need at least one
<rick_h_> hatch: though, what about our local charm story of adding a charm to the env without deploying it?
<hatch> well that's a charm, not a service
<rick_h_> and in this case you still end up with a unit, just not as part of env.deploy call
<rick_h_> true
<hatch> I'm wondering if a deploy call should, no matter what, create a unit, but be unplaced
<hatch> so revert your changes, but change what it does in the back end to mirror your changes
<rick_h_> I was looking in there but not all the data is there
<hatch> hmmm
<rick_h_> I'll look there, just working on how the parts fit atm
<rick_h_> I've tracked what's been going on but not actually been diving in here a ton :/
<rick_h_> hatch: anyway, I'd expect the drag/drop to just modify the machine info on the unplaced unit data in the db
<hatch> ok, but via the ecs
<rick_h_> hatch: 100%
<hatch> so ecs.modifyUnit('unitId', 'field', 'newVal')
<hatch> ish
<huwshimi> hatch: I'll try and get some stuff done a bit later. It's mother's day here so we're going out for breakfast and then I'll see what I can get done.
<huwshimi> hatch: (yeah, it's 7:30am)
<rick_h_> or maybe ecs.placeUnit() which would sync up the pending machine/container and the pending unit or what not
<hatch> huwshimi cool np, yeah mothers day here tomorrow too
<rick_h_> huwshimi: tell mom we say hello! 
<hatch> ahh placeUnit much better
<huwshimi> rick_h_: hehe, will do :)
<hatch> new card!
<rick_h_> hatch: lol
<hatch> ok back to writing tests *grumble grumble grumble*
<rick_h_> hmm, ok so we're getting crazy version numbers from somewhere and that's what caused it to not work in lxc
<hatch> crazy version numbers?
<rick_h_> it's part of the deploy stuff modifying the serviceName
<hatch> ohh, yeah I added a random number generated to the end of the serviceName
<hatch> without the inspector there is no way to modify it, so I didn't want it to blow up if people used two of the same charms
<rick_h_> right, but that looks like a service-version so it tries to deploy rev XXX of mysql charm
<rick_h_> gotcha
<rick_h_> yea, we'll have to figure that out
<hatch> ohhh heh, that can be fixed by removing the - then
<hatch> mysql1234
<hatch> for example
<hatch> oops, thats my bad
<hatch> I didn't realize that it would have just split on the -
<rick_h_> all good
<hatch> $500,000 for 1300sq/ft house....this city is going bonkers
<rick_h_> woo! my house will make me rich!
<rick_h_> except here it's 1/4 of that 
<rick_h_> so you should move down here
<rick_h_> ok, taking the boy to the park for a bit, biab
<hatch> haha, cya
<huwshimi> hmm... how do I get an unplaced unit?
<huwshimi> oh, I see we now have numbers as part of the service name
<rick_h_> huwshimi: check out the QA instrcutions for the branch
<rick_h_> huwshimi: https://github.com/juju/juju-gui/pull/296
<rick_h_> for instance
<huwshimi> rick_h_: Thanks
#juju-gui 2014-05-11
<rick_h_> alexpilotti: howdy, aroud?
<rick_h_> around that is
<alexpilotti> rick_h_: hi
<rick_h_> alexpilotti: hey, how goes?
<rick_h_> well, confirmed you can deploy a service with 0 units. 
<kadams54> Back in the saddle for 2nd shift
 * rick_h_ starts playing 'raw hide!"
<kadams54> Code wrangling
 * kadams54 suddenly feels the need for a 10 gallon hat and some spurs.
<kadams54> rick_h_: you available to chat some about this unplaced units card?
<rick_h_> hey, been on my AMZ wishlist for years :P
<rick_h_> kadams54: sure thing
<kadams54> LOL
<rick_h_> let me get the mac out 
<rick_h_> kadams54: link me whenever your want
<rick_h_> kadams54: https://github.com/juju/juju-gui/pull/296
<kadams54> http://cl.ly/image/3t1x3L2k1y2e
<huwshimi> kadams54_: Are you still around?
<kadams54_> Yup
<huwshimi> kadams54_: Actually, I need to duck out. If you happen to return, I was just looking in the serviceunit-token and there is a container '.icons' but I can't see from the mockups where there will be more the the token-move icon. Will the be issues if I rename that block?
<kadams54_> :-)
<kadams54_> Not that I know
<hatch> evening
<rick_h_> party
<hatch> yeah, I could use a good :beer"
<hatch> :
<hatch> bah
<hatch> rick_h_ out of data yet?
<rick_h_> hatch: almost, crossed 9gb 
<hatch> haha how did you use up 2 gigs this afternoon?
<rick_h_> I'll be getting a bill probably
<rick_h_> hatch: lots of clean-all I guess 
<rick_h_> and I was at 7.5
<hatch> ohh 1.5GB :)
<rick_h_> :)
<hatch> that's a lot of clean-all haha
<hatch> you sure you don't have some background process eating it up?
<rick_h_> something, I don't know. 
<rick_h_> I did do a hangout with kadams54_ 
<rick_h_> but yea, something is eating it up
<kadams54_> hatch: welcome to where all the cool people hang out
<hatch> if all the cool ppl are here should I expect a wedgie and have all my lunch money stolen soon?
<rick_h_> ok, EOD status email sent out to everyone
<rick_h_> give it a read and if anything is unclear let me know please
<kadams54_> http://constitutionconnectedyouth.files.wordpress.com/2011/04/moe.gif
<rick_h_> I'll check in in the morning, but will be afk until we get the camper back home and I can get unhooked/online again
<kadams54_> Have a good night
<rick_h_> kadams54_: you too
<hatch> This is the best test error Error: Script error. (:0)
<huwshimi> Brilliant.
<hatch> github is 503'ing for me
<hatch> https://status.github.com/
<hatch> heh 
<hatch> that availability graph sure tanked hard
<huwshimi> hatch: It's the weekend, there's not like anyone is doing any work anyway.
<hatch> haha - someone must have kicked a powercord or something :P
<hatch> although its been down for almost 30mins
<hatch> that's quite a long time for an entire site to be down
<kadams54_> Anyone still around?
<huwshimi> kadams54_: I am
<kadams54_> Working on having the list of unplaced service units update as the DB updatesâ¦
<huwshimi> Ah yes
<kadams54_> Do you know if that needs to update intelligently, similar to the machines, or can we just re-render the entire list?
<huwshimi> kadams54_: I would think intelligently, as when you've clicked the 'move' icon it will be displaying a form for that token, and you'll lose that if they all re-render.
<huwshimi> If that makes sense...
<kadams54_> Ah yes, I think you're right
<frankban> jujugui: is there anybody out there?
<frankban> sunday morning and I'm falling...
<rick_h_> frankban: morning
<frankban> hi rick
<frankban> hi rick_h_
<rick_h_> frankban: saw the pull request, will check it out when I get back. Thakns for picking up on that
<frankban> np
<rick_h_> will just have to coodinate that with hatch's branch of drag/drop and think we're about good for the demo. Will do some QA and such tonight
<rick_h_> and make sure we have any last notes out for you and huw monday morning
<frankban> sounds great
<rick_h_> we should be able to do a little walk through and then cut a charm release monday
<rick_h_> and then we'll just have the demo team update the charm they've got 
<frankban> rick_h_: I'll propose another branch for some small fixes on how the units in machine and sub-containers are retrieved
<rick_h_> frankban: awesome, thanks. 
<frankban> rick_h_: is Makyo working today?
<rick_h_> frankban: I'm not sure. He was in here yesterday with some test failures/etc
<rick_h_> frankban: but didn't hear anything after that
<frankban> rick_h_: ok thanks
 * rick_h_ goes offline to pack up camp. Back in a few hours. 
<hazmat`> rick_h_, any gotchas to be aware of re gui machine view/
<hatch> hazmat` yes quite a few still
<hazmat`> hatch, got a moment to review them re hangout?
<hatch> can you give me an idea of what you're trying to do and I can let you know where we should be by Monday night
<hazmat`> hatch, i'm gonna be dry running demos, and doing booth setup later today
<hatch> in a few I could, just running around getting ready for mothers day
<hazmat`> hatch, i was figuring we'd have machine view at the booth, but we can not enable the feature flag if its going to be problematic for self-directed exploration
<hazmat`> hatch, ack
<hatch> ahh ok, well gimme a few and I'll ping when I can 
<hazmat`> hatch, thanks
<hazmat`> i'm reading through rick_h_'s email from yesterday re current status, i guess that covers a good portion
<hatch> ohh cool, yeah I didn't think you were on peeps
<hatch> yeah that basically covers it
<hatch> a few of us have been working over the weekend to get to that point, so it's definitely not ready for self-driven exploration 
<hatch> but the good news is that everything is under flags
<hatch> hazmat` is there anything that's not in the email that you would like clarification on?
<hazmat`> hatch, i was skipping inbox on peeps.. re-reading.. saw everyone hacking yesterday.. just curious as to state.. machine view is still behind feature flag i assume?
<hazmat`> hatch, what's the url for enabling feature flag on comingsoon?
<hatch> yes, very much so :)
<hatch>  /:flags:/
<hatch> just append that to the url with the flags
<hatch> so for example
<hatch> comingsoon.jujucharms.com/:flags:/il/mv/
<hazmat`> hatch, thanks
 * hazmat` realizes half the people around him are talking about openstack at the airport
<hatch> lol
<hatch> nerd airport
<hatch> frankban I found a QA issue with your branch with the unplaced units
 * hatch is wearing his juju shirt for mothers day
<frankban> hatch: it should be related to the fact we add a unit but the ecs add_unit call is not yet there
<hatch> so you're suggesting we land it as-is with a follow-up?
<frankban> hatch: I confirm the error is due to the missing add_unit. Matt is working on that, and I guess he has a branch almost ready.
<hatch> ok I'll update the PR and then you can shipit
<frankban> hatch: so basically the unit in the db is not updated with the real name of the service
<hatch> Pr updated, thx
<frankban> hatch: as I described in the XXX comment, this can only be done when the ECS call is ready and we call env.add_unit with a callback
<hatch> yeah ok np
<frankban> hatch: I guess the callback could just delete the service unit and wait for it to be re-added by the mega-watcher, but this is just a supposition
<hatch> yeah there has been a bit of discussion around that - but I think the proper way to do it is the same we have always done - fake it, then update it when the deltas come in
<frankban> hatch: could you please take a look at https://github.com/juju/juju-gui/pull/302 too?
<hatch> on it
<frankban> thanks
<hatch> frankban test failure looks like the spurious one
<frankban> hatch: good to know
<hatch> you can re-run it manually
<hatch> just QA"ing now
<frankban> hatch: to re-run manually should I just delete the test failed comment?
<hatch> oh no you need to go into jenkins and flip some switches
<hatch> I can do it for you
<hatch> one sec
<frankban> hatch: thanks
<hatch> np, it's re-running, remind rick or I sometime and we can show you how to do this :)
<frankban> cool
<hatch> frankban here is the current job - you'll have to watch it to know when it's done, it won't update the PR http://ci.jujugui.org:8080/job/juju-gui/959/
<hatch> jujugui anyone available for a review? no qa https://github.com/juju/juju-gui/pull/303
<hatch> Makyo hey are you around?
<Makyo> Yep, just now.
<hatch> are you adding a 'placeUnit()' method to the ecs as well?
<rick_h_> hazmat`: you all set?
<Makyo> hatch, no, just add units and add machines
<rick_h_> hazmat`: can look in a bit, home and need a shower and lunch
<rick_h_> bah hatch ^
<hatch> alright - I have to run some errands then off to mothers day stuff - I'll pick up whatever is next in the queue when I get back
<rick_h_> hatch: where's the drag/drop branch?
<hatch> yep no rush, I'll be offline for a few hours
<rick_h_> hatch: is that the one there or close?
<hatch> rick_h_ that's #303
<rick_h_> hatch: gotcha
<hatch> took me forever to track down a stupid test failing with no information
<hatch> "Script Error" OH THX! lol
<rick_h_> :)
<rick_h_> yea, hit that. It was an old fashioned "comment out tests in index.html and start to narrow it down"
<hatch> rick_h_ basically once we have a 'placeUnit' method it'll be a single line to hook this drag and drop up to the ecs
<rick_h_> hatch: ok cool
<rick_h_> hatch: so we need placeUnit which no one is currently working on right?
<hatch> correct
<rick_h_> hatch: ok cool. Will finish catching up and see where we can get today
<rick_h_> hopefully we should be good for huw to clean up some thing his monday tonight
<hatch> yeah - I'll be gone for at least a few hours, but when I'm back I'll pick up whatever is next
<rick_h_> and we'll finish and get a charm release out tomorrow
<rick_h_> hatch: rgr, have a good time with mum :)
<hatch> yeah I think we are in a pretty reasonable spot
<hatch> go us
<hatch> :) th
<hatch> x
<rick_h_> <3
<hatch> lata
<rick_h_> hazmat`: if you've got any questions or need anything shoot me a call 248-956-1024 and I'll be back online in a bit. 
<Makyo> jujugui could use a second set of eyes on this https://github.com/juju/juju-gui/pull/304/files I think I'm about done, but I want to be sure.
<rick_h_> Makyo: looking
<rick_h_> Makyo: going to :shipit: is there anything you know of why I shouldn't?
<Makyo> rick_h_, I think everything that needs an XXX comment got one.
<Makyo> Only other note was switching away from object.observe
<rick_h_> Makyo: yea, we've got a slack card to update that. I wonder if there's known issues we need to move that up to a todo 
<rick_h_> ok, going to ship this to get it in front of hatch before his branch lands
<rick_h_> and try to convince him to integrate with the calls here 
<rick_h_> alexpilotti_: around?
<rick_h_> guess not lol
<rick_h_> Makyo: ok landed
<rick_h_> hey hazmat` 
<rick_h_> bah hatch 
<rick_h_> tab complete failing me so hard today
<hatch> hey, I am just replying to your comments
<rick_h_> hatch: cool, matt's branch landed and landing huw's now
<hatch> oh nice, did you fix up the line I commented about?
<rick_h_> hatch: no, just made a card for it
<rick_h_> you said it qa'd so added a card and moved it along
<hatch> oh yeah - I suppose I just try to not land tech debt :)
<hatch> usually haha
<rick_h_> you and me both
<rick_h_> but will declare next week tech debt week after the demo
<rick_h_> just want to keep the list documented
<hatch> ok so as per your comments about add machine you'd like me to update this branch with develop then make sure the add machine stuff works?
<hatch> I can also do that as a follow-up
<rick_h_> hatch: well just thinking while it's here waiting on landing we could do it and then the branch can be qa'd to an extext
<rick_h_> hatch: I get nervous of 'un-qa-able' branches 
<hatch> well if you want to edit the code you can add a debugger in the drop handler to inspector the arguments
<rick_h_> hatch: but it's one less moving part to get in a follow up. The follow up at this point needs to be placeUnit
<hatch> I just figured most don't want to edit the code to do a qa
<rick_h_> hatch: rgr
<rick_h_> hatch: I'm fine either way I guess. Just tossing it out
<rick_h_> hatch: I do think the UI updates should be added 
<hatch> yeah? Ok because that was left out for the demo
<hatch> I can add them in, just another thing to potentially break haha
<rick_h_> heh, but it should work
<rick_h_> I mean this whole thing is a house of cards and we'll do walk throughs
<hatch> alrighty
<rick_h_> at least it should give us some UI updates that draw audience attention away from other things that don't update
<rick_h_> hey kadams54, how goes?
<kadams54> Hi rick_h_ 
<hatch> I'll wait until huws branch lands so that we can QA with the styled stuff
<kadams54> Ready to move along more code doggies
<hatch> should be merged fairly soon
<rick_h_> kadams54: woot
<rick_h_> hatch: yea, it hit a strange error in the lander on the last run :/
<hatch> oh?
<rick_h_> hatch: yea, the lander itself died in a strange way. But it just landed matt's branch so not sure
<rick_h_> maybe an api issue with github
<hatch> ahh odd
<hatch> brb got to run and grab some propane 
<kadams54> You know, normally around this time most people head out to get food.
<kadams54> But not in Canada. Oh no. They get propane.
<rick_h_>  propane leads to food?
<hatch> look at that, just in time
<rick_h_> :)
<hatch> uh oh, rebasing blew up :/
<huwshimi> Morning
<hatch> yikes that was a rough rebase
<hatch> morning huwshimi 
<rick_h_> hey huwshimi 
<hatch> uh oh trunk is broken
<hatch> now my branch is broken
<hatch> lol
<huwshimi> Oh dear
<rick_h_> :(
<hatch> rick_h_ can you try and reproduce......
<hatch> on comingsoon with li, mv
<hatch> D&D mysql, click deploy
<hatch> click confirm
<hatch> switch to machine view
<rick_h_> food on the stove atm, can kadams54 or huwshimi help please?
<hatch> mass scale up UI is gone, and now you can't switch back to the service view
<huwshimi> rick_h_, hatch I'll take a look
<kadams54> Yeah, I'll checkâ¦
<hatch> thanks
<huwshimi> hatch: Yep, broken.
<hatch> :/
<huwshimi> This isn't working: unit.icon = db.services.getById(unit.service).get('icon');
<kadams54> Yeah
<kadams54> I actually fixed that in my branch
<hatch> yeah, looks like we can skip that - but the real fix is we need add_unit
<rick_h_> could it be that the css on comingsoon didn't kick over like happens sometimes
<kadams54> Which may be ready for QA
<huwshimi> it's because there are no services yet
<hatch> in ecs to be hooked up to deploying services
<hatch> er units
<huwshimi> oh wait, there is a service
<hatch> yeah this is because we need matt's fixes for frankbans branch
<kadams54> My fix
<kadams54> http://pastie.org/private/ew3cx7lr4tsjlsdwasog
<rick_h_> that landed hatch?
<hatch> yeah that's not the 'proper' fix I don't think
<huwshimi> rick_h_: The last set of CSS changes I made are on comingoon
<hatch> rick_h_ this is not a css issue
<huwshimi> *comingsoon
<kadams54> Oh wait, that's in a different place
<kadams54> I actually had to fix similar errors in two spots
<hatch> https://github.com/juju/juju-gui/pull/301/files#diff-f3e78957af1c877e1b8c3d58b0dfa03aR93
<hatch> comment in frankban's branch
<kadams54> http://pastie.org/private/ako9by4d7irehbidopc9qg
<hatch> kadams54 yeah that's a bandaid
<kadams54> Bandaid nothing!
<hatch> there should never be units added without a service
<kadams54> Defensive coding is never a bandaid
<hatch> lol, well then it should throw a console error :)
<kadams54> Bullocks on anyone who says "should never be" :-)
<hatch> haha, that just doesn't translate wekk
<hatch> well
<kadams54> "Bollocks" for you British Empire people.
<hatch> doing that 'defensive' coding just makes it fail further down
<hatch> haha
<kadams54> Anyhow, we should probably figure out a coordinated fix so that we don't have 4 different solutions landing in different branches.
<hatch> yeah - need to hook up the add unit stuff frankban mentioned
<hatch> that's the real fix
<rick_h_> ok, well that's next on the list
<kadams54> Au contraireâ¦ properly done, the system should fail gracefully, even when faced with "impossible" scenarios.
<kadams54> Missing icon < uncaught error that interrupts all code execution
<hatch> no there is much more wrong that just a missing icon
<kadams54> *sigh*
<hatch> now it just fails silently
<kadams54> All my tests pass
<kadams54> Works for me
<kadams54> ;-)
<hatch> hah
<hatch> rick_h_ ok so I can't land my branch until the add_unit stuff is hooked up
<rick_h_> hatch: :( ok, and you could before because?
<kadams54> I thought it was landed?
<hatch> because now it REALLY can't be QA'd
<hatch> it could before because you actually could create units and drag them to containers
<rick_h_> hatch: ok, sorry trying to keep up while making omlettes for the fam
<hatch> now you can't get containers or machines to render 
<rick_h_> hatch: they drag ot headers? Why do we care about rendering machinse/containers atm?
<hatch> no, they drag to the container
<rick_h_> oh, because you can't get a machine to get a container header
<hatch> that, and you wanted this to drag to the container token first
<hatch> :)
<kadams54> Man, whoever coded up the unplaced service units token was a dunderhead.
<rick_h_> https://www.dropbox.com/sh/lvdydgiu7jeuuso/7MlRX5-IPu#lh:null-06-machine.png
<rick_h_> kadams54: hey, let's keep it cool
<hatch> right, but you said you wanted it to land on the container token first heh
 * kadams54 heads back to fix his own mistakes.
<rick_h_> kadams54: everyone's worked hard on this stuff and it's all been done by our team. So calling out like that isn't cool
<hatch> rick_h_ it's ok it can sit for a bit, it's not going to go bad or anything - I'll work on hooking up the ecs add unit stuff
<rick_h_> kadams54: oh, well if it's you then ok cool :)
<rick_h_> hatch: ok
<kadams54> I'm just kidding of course :-)
<rick_h_> hatch: thanks, will try to catch up and try things out after I feed the fam
<hatch> yeah we have company coming over in an hour too, so I'll be back on after a few hours again
<hatch> heh, what a gong show today has been
<hatch> lol
<kadams54> I put {{ container }} in the handlebar template, which was intended to beâ¦ well, I'm not really sure? Since they're unplaced, they don't have containers yet. But regardless, the container attribute is actually set to the DOM container.
<kadams54> So that renders nicely.
<huwshimi> hatch, rick_h_: Anything I can do to help get things back on track?
<hatch> huwshimi are you familiar with the ecs stuff?
<hatch> :)
<huwshimi> hatch: I haven't touched it yet, but I can take a look...
<hatch> it's ok, I'm guessing there are going to be some dragons with this add unit stuff 
<rick_h_> huwshimi: I've got a few cards your way for polish I was hoping you could get to today
<huwshimi> hatch: OK sure
<huwshimi> rick_h_: Yep, I can take a look at those
<rick_h_> hatch: yea, the add unit/place unit stuff takes some background/etc
<hatch> I'm not entirely sure I even know haha
<hatch> I haven't done any of this stuff in a few weeks
 * hatch pokes Makyo 
<hatch> poke poke poke
<rick_h_> I had to run it on a live lxc env to watch wtf happened
<hatch> haha - yeah it's complicated
<hatch> wish core had it already
<hatch>             } // if
<hatch>           }, this); // foreach
<hatch>         } // for
<hatch>       } // if
<hatch> lol someone was lost
<rick_h_> yea, noticed that as well :)
<huwshimi> hatch: I haven't entirely followed the conversation about develop being broken, but is there a fix we can land to allow us to work a bit easier?
<hatch> haha, doesn't vim draw vertical lines on braces?
<hatch> huwshimi we can make it fail silently but then it just breaks further down the line
<rick_h_> huwshimi: not really, we're making the GUI do something it wasn't designed to, add a unit of a service before the service exists
<huwshimi> hatch: So how are we going to move forward?
<rick_h_> huwshimi: and before the machine/container does. So we're bending a lot of rules/laws internally to the GUI environment
<kadams54> There is no spoon.
<rick_h_> huwshimi: so we've got to finish the last step in adjusting the environment to accept these new laws of juju 
<hatch> huwshimi atm I'm getting caught up on the ecs stuff
<rick_h_> huwshimi: there's no 'quick fix' to make it work
<huwshimi> hmm... just wondering how to test stuff with this broken then...
<kadams54> rick_h_: I've got unplaced units updating automatically. Not sure I can land this branch though since I had to shim in temp fixes for the broken stuff.
<kadams54> Now that they're showing up, they need a lot of CSS love, so I could work on make them pretty next.
<kadams54> Or I could move on to something elseâ¦
<hatch> they look good on trunk
<rick_h_> kadams54: rebase on trunk and huw's work to clean up the CSS on them should help
<rick_h_> kadams54: if your branch works and is ready and can land go for it
<kadams54> k
<rick_h_> we know where we're headed next and have to do it regardless so let's keep the ball rolling forward
<rick_h_> kadams54: the next thing if you could look at is the bug card about the deployment summary switching to "no uncommitted changes"
<kadams54> kk
<rick_h_> kadams54: there's that, and adding support for "new machine/container" now that it's landed in that summary
<rick_h_> kadams54: check out the QA notes from Matt's branch that recently landed for how to manually add a machine into the ecs/db so that you can have it listed in the summary
<kadams54> Yeah, that came in handy for testing this branch
<rick_h_> kadams54: ok cool, thanks 
 * rick_h_ goes off to dinner with for 20ish
<kadams54> LOL
<kadams54> https://twitter.com/iamdevloper/status/450905958139834368/photo/1/large?utm_source=fb&utm_medium=fb&utm_campaign=phessler&utm_content=465613662468997121
<hatch> so if someone tries to deploy a service without any placed units, it should.....?
<huwshimi> hatch: All break horribly
<hatch> so we need something to check that they placed at least a single unit before letting them hit 'confirm' in the deployer bar
<hatch> :)
<hatch> so many edge cases
<Makyo> Was at dinner.  Sorry for the leftover comments, hatch.  Trust me, it used to be worse :P
<hatch> lol it's ok I was just poking fun
<hatch> Makyo do you have time to hook up the add_unit now? 
<hatch> I'm working on learning it now, but company is coming in 30
<hatch> if not I can get on it after everyone gets outa my house!!!!!
<hatch> :P
<Makyo> hatch, maybe later? just finished cooking, was about to sit down.
<hatch> with a laptop???? ;)
<hatch> lol jk it's ok
<hatch> odly when I follow your qa steps I only get one machine rendered but there are two in the db
<rick_h_> hatch: error on the summary page and make you go back and fix it
<rick_h_> hatch: but yea, all these edge cases are stuff that luca wants to sort out as he tries it
<rick_h_> hatch: behind the FF
<rick_h_> hatch: because the second one is a container on the first (reason why you only get one machine)
<hatch> it should show up in the container column then no?
<rick_h_> hatch: when you click on the machine
<rick_h_> hatch: the container column should be driven by the selection in the machine column
<hatch> yeah, that's what I thought too, lemme try again
<hatch> ohh, that's why, it's only adding a single machine
<rick_h_> right, one machine with one lxc
<hatch> now I see where I screwed up
<hatch> I 'might' have the add_unit thing figured out
<hatch> I lied
<rick_h_> lol
<hatch> a lazy added unit should probably still be created in the db right away
<hatch> then updated
<rick_h_> hatch: right, it needs to be updated when placed on the machine in the db/ecs
<hatch> well I have something that I think will allow people to get unblocked at least
<hatch> blah
<hatch> ok people are arriving, consider me having accomplished nothing if anyone else wants to start on this add_unit stuff
<hatch> ^ rick_h_ 
<rick_h_> hatch: rgr thanks
<rick_h_> hatch: I'll try to send an email summary and maybe frankban can look at it his morning
<rick_h_> thanks! have fun!
<hatch> haha, I'll try
<hatch> have a good night
<hatch> cya
<huwshimi> hatch: Night
#juju-gui 2015-05-04
<fabrice> morning everyone
<urulama> morning, fabrice
<duncan> Hey Guys I am having trouble getting the gui working (first time)  http://pastebin.com/80J8TdAS
#juju-gui 2015-05-05
<perrito666> rick_h_: ping
<rick_h_> perrito666: pong
#juju-gui 2015-05-06
<lazyPower_> hatch: hey hatch, i've run into a repeat bug that I seem to be unable to find the bug ref for. I know we  fixed this before but i dont recall how
<lazyPower_> http://i.imgur.com/XmuVt9M.png <-  FF reports odd socket behavior while chrome remains unaffected
<rick_h_> lazyPower_: that's because of the number of ssl certs for the domain
<rick_h_> lazyPower_: they found it in teh sprint, let me find the bug for you
<rick_h_> there's a fix in the charm I thought it was in 27 but maybe it's in the next release coming
<lazyPower_> i knew this was something that was already addressed - but a real chin scratcher trying to find it
<lazyPower_> loading it up by IP vs the domain should work right?
<rick_h_> https://bugs.launchpad.net/juju-gui/+bug/1397296
<mup> Bug #1397296: Juju GUI does not load in Firefox <hs-arm64> <landscape> <juju-gui:Confirmed for hatch> <https://launchpad.net/bugs/1397296>
<rick_h_> well the thing is that you accept so many ssl certs and they're for the same made up domain (self signed)
<lazyPower_> ah
<rick_h_> and so firefox takes 5+ minutes to get through them all and load
<lazyPower_> man, that seems like a big ole bug on firefox's part
<rick_h_> browsers...gotta love em
<lazyPower_> indeed. the VM of now.
<lazyPower_> *vm of the web - of now
<rick_h_> hatch: when you're about can we confirm that this is landed? it's marked confirmed but assigned to you and I thought a fix landed during the sprint but maybe it was just 'identified' and not actually landed. 
<lazyPower_> rick_h_: do you have a minute? I would like to run something past you - as a consumer of juju - to get your opinion
<hatch> rick_h_: lazyPower_ it was only confirmed, not fixed yet but the workaround is pretty easy
<rick_h_> hatch: k, can you add a card for that then and we can try to make sure it's updated in the charm release coming up please?
<hatch> yep
<rick_h_> hatch: ty much
#juju-gui 2016-05-10
<ejat> hi .. how to get juju-gui inside horizon?
<rick_h_> ejat: it's something that is in an alpha stage and not available for download at this time as it's not complete. 
<rick_h_> ejat: you can reach out to juju@canonical.com to express interest about it was a product going forward. 
<ejat> rick_h_: owh okie thanks for the info.
<ejat> bcoz i see someone presenting it at the openstack event 
<rick_h_> ejat: yes, it's been presented to gauge interest and demonstrate Juju in an openstack setup
<fabrice> ccdlntlttbcilufrjijkhbftkkettgnuechlnvcd
#juju-gui 2017-05-09
<MOHSIN> HELLO
#juju-gui 2018-05-09
<aaaaaaaaaaaaa> Ã§
