[00:03] <rick_h_> hatch: rgr will look
[00:09] <rick_h_> hatch: don't worry about the search branch. It's just a WIP to go through
[01:58] <kadams54> hatch: I am now :-)
[02:00] <rick_h_> heh, timing is everything
[02:01] <rick_h_> time for me to head home...
[02:15] <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
[02:57] <hatch> huwshimi sounds good, mind firing me an email at your EOD and let me know what still needs/has been done?
[03:06] <huwshimi> hatch: Will do.
[03:07] <hatch> thanks, we r in crunch time :)
[03:07] <huwshimi> yeah
[03:07] <hatch> any questions or anything so far?
[03:13] <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.
[03:13] <hatch> change
[03:14] <hatch> if you change the contents of one of the machines there should be a *:change event that bubbles up to the modellist
[03:14] <huwshimi> hatch: But how do I change the contents of a machine?
[03:15] <hatch> well you can use the getById() method on the modellist if you have the id
[03:15] <hatch> to fetch the model
[03:15] <hatch> or item(n) to grab it by index
[03:16] <hatch> or each(function(machine) { ... })
[03:16] <hatch> to loop through
[03:17] <hatch> then you just change the contents like you would any model
[03:18] <hatch> did that answer the question
[03:19] <huwshimi> hatch: Oh, I was trying to do a .set(..) on the object, but I can just set the parameter directly (foo.id = '1')
[03:19] <hatch> if the machines modellist is a lazyModelList then yes each model is actually just an object
[03:19] <hatch> that's the primary difference between a modelList and a lazyModelList
[03:20] <huwshimi> Hmm... the change event doesn't fire though.
[03:20] <hatch> no, you'll need to promote it to a real model
[03:20] <hatch> http://yuilibrary.com/yui/docs/api/classes/LazyModelList.html#method_revive
[03:21] <hatch> but this is a problem that we will need to think about...
[03:21] <hatch> brb need to dc for a second
[03:22] <hatch__> back
[03:22] <huwshimi> hatch__: So when I do the revive the change event should fire?
[03:23] <hatch__> it 'should'
[03:23] <hatch__> it's been a while since I've used it
[03:23] <hatch__> then you'll want to call `free` on it
[03:23] <hatch__> http://yuilibrary.com/yui/docs/api/classes/LazyModelList.html#method_free
[03:24] <hatch__> I 'think' this is the interaction we'll want to use for this type of thing
[03:25] <huwshimi> hatch__: Hmm... nothing is getting fired
[03:25] <hatch__> how are you listening for the event?
[03:25] <huwshimi> hatch__: https://github.com/huwshimi/juju-gui/compare/machine-view-render-changes#diff-947e688a9f9e23383a48af542be63bbfR65
[03:26] <hatch__> hmm that 'should' work....
[03:26] <rick_h_> hatch: I added a card in 'on deck' in Maint. for the password thing fyi
[03:26] <rick_h_> hatch: actually two, one for core and one for gui
[03:27] <hatch> kewlio
[03:27] <huwshimi> hatch: And in a console I'm doing: foo = app.db.machines.getById(14); foo.displayName = 'new'; app.db.machines.revive(foo);
[03:28] <hatch> ohh
[03:28] <hatch> you need to revive first
[03:28] <hatch> then use `set()`
[03:28] <huwshimi> oh
[03:29] <hatch> basically it's converting an object into a real model
[03:29] <huwshimi> hatch: Yeah, that worked. Thanks
[03:29] <hatch> right on
[03:30] <hatch> make sure you use 'free' afterwards
[03:30] <huwshimi> hatch: Even in the chrome console?
[03:30] <hatch> ohh you're just hacking?
[03:30] <hatch> then it's fine
[03:31] <huwshimi> hatch: Yeah, I'm just simulating the events in the browser at the moment
[03:31] <hatch> oh ok cool yeah then np
[03:31] <huwshimi> hatch: I'll free in the test
[03:32] <hatch> basically you use a LML to save memory and whatnot because then it's just objects instead of model instances
[03:39] <huwshimi> hatch: Any suggestions for how to do the update? I don't want to have to compare the contents of every token...
[03:40] <hatch> I think i need more context
[03:42] <huwshimi> hatch: Do you know what can change on a machine? Can the displayName change for example?
[03:42] <hatch> hmm, I don't think anything tbh
[03:42] <hatch> I would assume that any changes would require a new machine
[03:43] <hatch> ^ rick_h_  have any idea?
[03:43] <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
[03:43] <rick_h_> huwshimi: but we're ok for the moment
[03:43] <huwshimi> hatch: The units can, but I assume we'll handle that differently (it's not something tied to the machine model)
[03:44] <hatch> yeah the units definitely can
[03:44] <hatch> I didn't know you could name machines
[03:44] <hatch> that's interesting
[03:44] <rick_h_> hatch: I don't recall if that's planned or does work atm
[03:44] <huwshimi> hatch: Should I leave updating until we know what will change then?
[03:45] <hatch> I'd say so
[03:45] <huwshimi> hatch: OK, that might be a follow up branch then.
[03:45] <hatch> yeah it should be ok to add on later on
[03:45] <hatch> cool
[03:45] <huwshimi> hatch: I have to dash out for lunch. bbs.
[03:46] <hatch> sure thing, cya later
[03:57] <rick_h_> man this is going to be a big diff lol
[03:57] <rick_h_> I'll have to ask hatch to review it :P
[03:58] <hatch> haha shouldn't you be in bed?
[03:58] <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 :/
[03:59] <hatch> oo boy
[04:04] <rick_h_> this.state.getCurrent('charmID');
[04:04] <rick_h_> that seems like it's broken?
[04:06] <rick_h_> hmm, looks like it's custom mapped just for editorial ugh
[04:13] <hatch> rick_h_ that is no longer the valid syntax for the new state class
[04:15] <rick_h_> hatch: yea, gotcha. It looks legacy for non flagged editorial stuff
[04:15] <rick_h_> will add an XXX
[04:15] <hatch> yeah - the new getCurrent syntax is pretty clunky, I've been wanting to add dot-notation support but haven't yet
[04:50] <rick_h_> huwshimi: around?
[05:45] <huwshimi> rick_h_: Oh, sorry I missed your message
[05:50] <rick_h_> huwshimi: all good
[05:50] <rick_h_> huwshimi: have much time left in your day?
[05:50] <huwshimi> rick_h_: A couple of hours, but I'll try and work until this is done.
[05:51] <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
[05:51] <huwshimi> rick_h_: You, on the other hand, should be in bed :)
[05:51] <rick_h_> about to call it a night
[05:51] <rick_h_> well soon
[05:51] <rick_h_> almost have it working
[05:51] <huwshimi> rick_h_: Want me to take a look?
[05:51] <rick_h_> well, it works w/o the flag, now to make it work with
[05:52] <rick_h_> https://github.com/juju/juju-gui/pull/279 is the WIP
[05:52] <rick_h_> lots of crapped moved around and such, try not to look at the diff
[05:52] <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
[05:56] <huwshimi> rick_h_: I don't get any sidebar content and an undefined is not a function error
[05:57] <rick_h_> huwshimi: with no flags?
[05:57] <huwshimi> rick_h_: that's with flags
[05:57] <huwshimi> rick_h_: It's actually broken without flags too. It overlaps the headers instead of pushing
[05:57] <rick_h_> huwshimi: I just pushed a fix for making it work with flags
[05:58] <rick_h_> huwshimi: right, that's what I mean
[05:58] <rick_h_> my refactoring (without flags) has messed up the sticky headers
[05:58] <huwshimi> Ah
[05:58] <rick_h_> I think it's a div/css placement thingy
[05:59] <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
[05:59] <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
[06:00] <rick_h_> or well later today
[06:00] <huwshimi> rick_h_: I suspect it's not calculating the distance between headers correctly
[06:00] <huwshimi> might be an on('scroll' not firing
[06:02] <rick_h_> ah, me looks
[06:04] <rick_h_> hmm <div id="bws-editorial"> is the renderTo in the code for the target of that event
[06:04] <rick_h_> but yea, not firing
[06:05] <huwshimi> yeah, that's it
[06:05] <huwshimi> rick_h_: .bws-content is the element it should have the event on.
[06:06] <rick_h_> ah ok, updating 
[06:06] <huwshimi> rick_h_: We could possibly make #bws-editorial the element that scrolls if need be.
[06:07] <rick_h_> yea, that works
[06:07] <huwshimi> Oh good.
[06:07] <rick_h_> I just hard coded it to .bws-editorial for now
[06:07] <rick_h_> the structure is a bit different, but this will work for now
[06:07] <rick_h_> thanks!
[06:07] <huwshimi> rick_h_: No problems. Hope you get some sleep! :)
[06:10] <rick_h_> I will head off to bed now. Have it pretty close. 
[06:11] <rick_h_> night and thanks again!
[06:14] <huwshimi> rick_h_: Night
[10:49] <antdillon> rick_h_, Morning
[10:53] <rick_h_> antdillon: morning
[10:55] <antdillon> rick_h_, I have a few issues with the environment change set. Where is the best place to voice them?
[10:56] <antdillon> rick_h_, Also can I check I should be working from flag mv/li?
[10:56] <rick_h_> Just me for the moment. Want to chat? Or type out what's up?
[10:56] <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
[10:57] <antdillon> rick_h_, I got it all working its mainly missing info in the ecs like no time stamp
[10:57] <rick_h_> antdillon: oh? Ok, well I was just expecting the count to work
[10:57] <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
[10:58] <antdillon> rick_h_, I few events to bundled like deploying a server and subordinate fire the same deployed event
[10:58] <antdillon> rick_h_, Wont we need time stamps for the summary panel?
[10:58] <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
[10:59] <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
[10:59] <antdillon> Oh I see, I was using the command method to split the events
[11:01] <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. 
[11:03] <antdillon> rick_h_, Sure, just working through the last few changes and there messages then tests :)
[11:07] <rick_h_> antdillon: yay
[12:11] <rick_h_> frankban: sorry, completely missed the time
[12:11] <frankban> rick_h_: no worries, ready when you are
[12:31] <rick_h_> frankban: https://github.com/juju/juju-gui/pull/277
[12:36]  * frankban lunches
[12:41] <rick_h_> this test run isn't going to be pretty 
[13:05] <jcsackett> morning all.
[13:07] <rick_h_> morning
[13:20] <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.
[13:21] <rick_h_> jcsackett: thanks
[13:22] <rick_h_> it'll be quick, forgot to shorten from the google calendar 1hr default
[13:22] <jcsackett> cool.
[13:30] <bac> rick_h_: daily hangout?
[13:32] <rick_h_> bac: soryr, had a hangout in the meeting invite
[13:33] <rick_h_> https://plus.google.com/hangouts/_/canonical.com/charmworld?authuser=1&hceid=cmljay5oYXJkaW5nQGNhbm9uaWNhbC5jb20.7enijh4dvef97a4ifdu83bnoj4
[13:50] <rick_h_> I <3 it when a passing test comes together
[13:52] <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
[13:53] <redir>  bac do we have a target for the demo? trusty?
[13:53] <redir> I can do it from scratch in a container
[13:53] <bac> yes, i'd say trusty
[13:54] <bac> in an lxc would be great
[13:55] <redir> k
[14:08] <rick_h_> bac: want to catch up with 1-1 later on?
[14:09] <bac> rick_h_: what do you mean?  postpone?  i can do it now
[14:09] <rick_h_> bac: ok
[14:21] <antdillon> Hi guys, does anyone have a min to help me get my head around some tests for deployer bar?
[14:24] <rick_h_> Makyo: are you around to help antdillon?
[14:24] <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?
[14:24] <rick_h_> and I can help out between calls 
[14:25] <antdillon> rick_h_, Its mainly just trying to add a change to the ecs in the test
[14:25] <rick_h_> antdillon: ah, gotcha. sec, might be able to find an example
[14:26] <antdillon> rick_h_, I'm in the text_env_change.js
[14:26] <rick_h_> antdillon: oh ok, so in the ecs tests itself?
[14:27] <antdillon> rick_h_, Something like utils.makeStubMethod(envObj, '_deploy');
[14:30] <rick_h_> antdillon: you're looking to make a stub or to put something into that stub'd method?
[14:30] <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.
[14:31] <rick_h_> jcsackett: rgr
[14:32] <rick_h_> antdillon: maybe hatch can help you 1-1?
[14:32] <hatch> uh oh
[14:32]  * hatch runs away
[14:32] <hatch> :P
[14:33] <antdillon> hatch, come back
[14:33] <hatch> what's up?
[14:34] <antdillon> hatch, Getting errors trying to set changes to the ecs in the deploy bar tests
[14:34] <antdillon> hatch, Got any tricks?
[14:34] <hatch> can you push up the code?
[14:34] <hatch> so I can see what you're trying
[14:34] <hatch> and what the errors are
[14:34] <antdillon> hatch, Here is the test: https://pastebin.canonical.com/109870/
[14:35] <antdillon> Getting TypeError: 'undefined' is not an object (evaluating 'ecs.changeSet')
[14:36] <hatch> looking
[14:36] <antdillon> hatch, Not sure im initialising the ecs properly
[14:36] <hatch> blah 2fa, one sec
[14:38] <hatch> ok you're doing the stubbing incorrectly
[14:38] <hatch> one sec 
[14:38] <hatch> at least I think so
[14:38] <hatch> you're stubbing out the entire application 
[14:39] <antdillon> probably, seems slightly different test by test
[14:39] <hatch> so what is this test trying to do?
[14:40] <hatch> when you simulate a click on the deploy button the ecs commit method is called?
[14:40] <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
[14:40] <hatch> oh that test
[14:41] <hatch> woops :)
[14:41] <antdillon> I didnt write that one, im working on the one above and will move to that one
[14:41] <antdillon> hatch, But both are erroring
[14:43] <hatch> ok so first of all you're stubbing out a method and not resetting it
[14:44] <hatch> and then as far as the rest of the errors I'll need to run the code to see the actual error
[14:44] <antdillon> hatch, I'll push them up
[14:45] <hatch> thx
[14:45] <hatch> brb
[14:48] <redir> merge proposal submitted in lp. requested R=jcsackett to get different eyeballs on it.
[14:49] <redir> bac: ubuntu or ubuntu-cloud for the container?
[14:49] <redir> matter?
[14:49] <bac> redir: lxc?
[14:51] <antdillon> hatch, https://github.com/anthonydillon/juju-gui
[14:53] <hatch> antdillon which branch?
[14:53] <hatch> oh you pushed into develop
[14:53] <antdillon> Pushed to my fork
[14:53] <antdillon> git@github.com:anthonydillon/juju-gui.git
[14:53] <jcsackett> redir: ack, i'll take a look after standup.
[14:54] <jcsackett> redir, bac: we're using LP, not rietveld now?
[14:54] <hatch> antdillon yeah ok, give me a few minutes to pull this down and take a look
[14:54] <bac> jcsackett: new hires cannot use lbox
[14:55] <bac> something to do with the auth dance
[14:55] <bac> and unsupported tools
[14:55] <jcsackett> bac: lovely.
[14:55] <jcsackett> ok, no worries.
[14:55] <antdillon> hatch, Thank you very much
[14:57] <rick_h_> jujugui call in 4
[14:57] <bac> hey rick_h_ you're sending out gcal invites in pacific time.  perhaps you should tell google you're back home.  :)
[14:57] <bac> not that it matters...
[14:58] <rick_h_> bac: hah, awesome
[14:58] <rick_h_> bac: hmm, it says I'm in eastern
[14:59] <bac> our 1:1 came across as 7am, which caused me to panic a bit
[14:59] <hatch> antdillon assert.equal(view._getChangeCount(ecs), 1);
[14:59] <hatch> you didn't pass ecs into this method
[14:59] <kadams54> hatch: got a state question for you, maybe after standup?
[14:59] <hatch> sure
[15:00] <hatch> jujugui call now
[15:03] <antdillon> hatch, Isnt ecs a global?
[15:04] <antdillon> hatch, Ah got it :)
[15:04] <redir> jcsackett: bac's instructions for setting up juju-gui to connect to local charmstore with ngrams applies also.
[15:06] <hatch> antdillon :) rookie mistake :P
[15:06] <antdillon> hatch, :P
[15:09] <Makyo> jcsackett, shared the calendar with you.
[15:09] <jcsackett> Makyo: thanks.
[15:10] <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.
[15:11] <bac> jcsackett: i think that works just as well
[15:11] <bac> jcsackett: using juju-gui to see the autocomplete behavior is nice, too
[15:11] <antdillon> hatch, Is utils.makeStubMethod(envObj, '_deploy'); the correct way to trigger an event?
[15:12] <hatch> nope
[15:12] <redir> jcsackett: that is how I rolled. But hooked up the gui to make sure it didn't puke
[15:12] <jcsackett> redir, bac fair points.
[15:12] <hatch> that will make a stubed version of the _deploy method on the envObj
[15:12] <jcsackett> looking now.
[15:13] <hatch> you want to fire an event from envObj?
[15:13] <hatch> rick_h_ you said that you have an outline of the demo they want to do?
[15:13] <antdillon> Im copying from test_env_change.js
[15:14] <hatch> you're going to have to give me more information :)
[15:14] <rick_h_> hatch: yes, I've requested access for everyone, waiting on luca 
[15:14] <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.
[15:15] <bac> redir: i have no preference.  pick one and document it
[15:15] <redir> k
[15:15] <bac> and if it breaks, pick the other one
[15:15] <redir> hehe
[15:18] <hatch> frankban are you taking over huw's branch?
[15:19] <rick_h_> hatch: no, I was going to see if you would 
[15:19] <rick_h_> hatch: we need to get the service units stuff landed first before anything else really
[15:19] <hatch> yep I will, I just saw his comments, wasn't sure if he was on it
[15:19] <rick_h_> he was realy helpful to narrow it down <3
[15:20] <hatch> haha yes
[15:20] <hatch> ok I've got to run to the drug store to buy some drugs
[15:20] <rick_h_> yay drugs!
[15:20] <hatch> I've gone this long without any, but with all this coughing it's just too hard to do anything 
[15:20] <jcsackett> rick_h_, frankban: so, what branch should i be watching for service unit stuff? i thought just frankbans, but huw's too?
[15:20] <hatch> need some cough juice 
[15:20] <frankban> hatch: I am trying to proceed with this branch, so that wasn't a real review
[15:21] <hatch> frankban ok thanks
[15:21] <hatch> bbiab
[15:21] <jcsackett> hatch: just make sure it's not the *special* cough juice.
[15:21] <hatch> jcsackett maybe the code will be more interesting :P
[15:22] <jcsackett> yeah, b/c coding with full-strength robo-tussin is such a good idea. or is that like the balmer curve...
[15:22] <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
[15:22] <antdillon> hatch, Sorry I was using the code from test/test_env_change.js
[15:23] <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.
[15:23] <antdillon> hatch, All I need to do it trigger an event like _deploy or _relation
[15:23] <jcsackett> s/machines/machine-view/
[15:24] <frankban> jcsackett: yeah, at that point it should be something like db.units.filter(function(unit) {return unit.machine == $myMachine}) or similar
[15:25] <jcsackett> frankban: awesome. thanks.
[15:40] <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?
[15:41] <redir> jcsackett: yes. define an analyzer then use it
[15:41] <jcsackett> redir: just making sure. outside of a full understanding of ES it looks a little magical. :p
[15:41] <redir> agreed
[15:42] <redir> I don't claim to have a full understanding of ES:)
[15:43] <hatch> back
[15:44] <hatch> antdillon _deploy or _relation aren't events
[15:44] <antdillon> hatch, I mean't adding to the ecs
[15:45] <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?
[15:45] <antdillon> When I do ecs._createNewRecord('service');
[15:45] <antdillon> I get TypeError: 'undefined' is not an object (evaluating 'record.command.args')
[15:46] <jcsackett> redir: code is r=me, qa-ing now. can you please file a bug about the test you needed to comment out?
[15:46] <hatch> that means that record.command is undefined
[15:46] <kadams54> hatch: another question on the hasChanged stuff…
[15:46] <hatch> antdillon the ecs stuff requires a bunch of setup your best bet is to call one of the public methods
[15:46] <hatch> ecs.deploy for example
[15:46] <antdillon> hatch, Tried ecs._createNewRecord('service',{ foo: 'foo' }); with an undefined args.length
[15:47] <jcsackett> redir: qa may take awhile--i have no charms in my local charmworld, need to let ingest run for a bit.
[15:47] <hatch> kadams54 shoot
[15:47] <redir> jcsackett: and with that test commented out they won't get deleted when you run the suite
[15:47] <redir> :)
[15:47] <hatch> jcsackett why does charmwork injest take to long?
[15:47] <rick_h_> hatch: don't go there :P
[15:47] <hatch> oh
[15:47] <hatch> haha ok
[15:48]  * hatch steps back slowly
[15:50] <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
[15:51] <hatch> well that's stupid
[15:51] <kadams54> That's a problem for metadata, which, as things stand, will always return true.
[15:51] <hatch> what kind of idiot wrote that
[15:51] <hatch> :)
[15:51] <kadams54> I'm pretty sure it's Benji's fault ;-)
[15:51] <hatch> lol!
[15:51] <kadams54> So… how do you want to fix?
[15:51] <rick_h_> I had to do this for filters
[15:52] <hatch> the 'proper' way to do fix is to add dot notation to that method
[15:52] <hatch> but the easy way is ot manually compare for now
[15:52] <hatch> sorry
[15:52]  * kadams54 *sobs*
[15:52] <hatch> manually compare isn't too bad
[15:52] <hatch> one extra line
[15:52] <rick_h_> kadams54: hatch I just did JSON stringify compare to check if they were the same for the filter object data
[15:52] <rick_h_> fyi
[15:52] <kadams54> rick_h_: yeah, I was thinking of doing the same
[15:52] <hatch> ahh yeah that would work, but in this case that's overkill
[15:52] <kadams54> Couldn't remember if there were any caveats to that hack
[15:53] <hatch> imho
[15:53] <rick_h_> kadams54: determinism of the data
[15:53] <hatch> it's slow
[15:53] <hatch> "slow"
[15:55] <hatch> antdillon you can probably go ecs.changeSet.abc123 = { ... }
[15:56] <hatch> assuming that you don't have another key which is abc123 :)
[15:57] <antdillon> hatch, lol i thought that would be cheating
[15:57] <antdillon> hatch, wanted to try and push a true event in there using the right function
[15:57] <hatch> well it is, but you're testing the integration between two classes 
[15:57] <hatch> you don't need to test that the ecs is working, it already has tests for that
[15:57] <antdillon> i guess
[15:57] <antdillon> thanks
[15:58] <hatch> np :)
[15:58] <hatch> I don't know how the stuff in cough syrup works but daaaaaaamn it works fast
[15:58] <antdillon> on to the deploy :P
[16:00] <hatch> antdillon so how is the Object.observe stuff working out?
[16:01] <antdillon> hatch, Good! seems to be working for the changes that are supported
[16:01] <hatch> nice
[16:01] <hatch> glad to hear it
[16:01] <antdillon> should have a pull request in soon
[16:07] <redir> jcsackett: filed 1317567
[16:07] <jcsackett> redir: thanks.
[16:18] <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
[16:21] <kadams54> QAing
[16:21] <rick_h_> kadams54: ty
[16:22] <rick_h_> hah, and somehting is broken yay
[16:23] <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
[16:23] <hatch> but there IS a machine in the db
[16:23] <frankban> hatch: I explained what's going on in the mp comments
[16:24] <hatch> ohh woops I misread your comments
[16:24] <frankban> .filterByParent(null) does not return the machine because parentId is not set at the time the event is fired
[16:24] <frankban> hatch: ^^^
[16:24] <hatch> ok I can fix that, instead of overwriting add, listen to the the 'on' event and modify the machine before it's added
[16:24] <frankban> hatch: my current branch fixes the issue
[16:25] <rick_h_> bah, make test pass rebase and now it's broken
[16:25] <rick_h_> hold off kadams54 working on it
[16:25] <hatch> is there a reason why ^ wouldn't work frankban ?
[16:25] <frankban> hatch: interesting
[16:26] <kadams54> rick_h_: will do
[16:26] <hatch> it seems like it should
[16:26] <hatch> then we don't have to make custom events for fun :)
[16:28] <jcsackett> redir: so, qa may take a really long time. ingest blew up b/c of local network problems.
[16:28] <jcsackett> redir: do you have other things to work on, or is this blocking you?
[16:29] <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
[16:29] <redir> jcsackett: ^^
[16:29] <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.
[16:31] <hatch> ok I'm going to give it a try, see if the tests pass
[16:31] <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
[16:31] <redir> idk
[16:32] <frankban> hatch: to be clear, I am worried by the double pain of having 1) an object mutated 2) by a ninja subscriber
[16:32] <jcsackett> redir: if it's not blocking you, i'm content to just let it finish running properly.
[16:32] <redir> jcsackett: cool
[16:32] <jcsackett> redir: not that i think your branch could be at fault, but it's always good to make sure ingest still works. :p
[16:32] <hatch> frankban, yeah it's not very transparent with the ninja subscriber
[16:33] <jcsackett> is "ninja subscriber" an actual term of art, or just something y'all are going with?
[16:33] <hatch> I just feel that we should be modifying the machine BEFORE it's saved not after
[16:33] <hatch> jcsackett just running with it
[16:33] <hatch> :D
[16:33] <jcsackett> hatch: dig.
[16:33] <hatch> I see a tweet here somewhere
[16:34] <hatch> I need some program that tweets and G+'s at the same time
[16:34] <frankban> ninja subscribers can destroy your application very fast
[16:35] <hatch> see an attribute would handle this in the setter
[16:35] <hatch> I'll ask in #yui see if anyone has any input
[16:36] <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
[16:36] <hatch> frankban events aren't discoverable - and custom event's don't follow any convention
[16:37] <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
[16:38] <hatch> I suppose we could make the add event silent and then fire an add event ourselves
[16:38] <frankban> hatch: I tried to reuse the YUI one, but found that unfortunately an internal ninja subscriber is already in place in YUI :-/
[16:39] <hatch> something else is listening to the 'add' event?
[16:39] <frankban> hatch: yes
[16:39] <hatch> and our modifications break it?
[16:40] <frankban> https://yuilibrary.com/yui/docs/api/files/app_js_model-list.js.html#l189
[16:41] <hatch> that's just publishing that this will fire that event
[16:41] <hatch> but I see what you're saying
[16:42] <hatch> the lazy model list api is linking to the wrong file :/
[16:42] <frankban> hatch: that;s also adding a default subscriber: this._defAddFn
[16:42] <hatch> yeah
[16:43] <frankban> hatch: but perhaps we can fire add with preventDefault?
[16:43] <frankban> hatch: yeah, that could work
[16:43] <hatch> https://yuilibrary.com/yui/docs/api/files/app_js_lazy-model-list.js.html#l287
[16:43] <frankban> hatch: so we add with silent: true, we modify the object and then we fire "add" with preventDefault?
[16:44] <hatch> just an idea
[16:45] <antdillon> hatch, sorry one last thing
[16:45] <hatch> np, shoot
[16:45] <rick_h_> kadams54: pushing updated branch now. 
[16:45] <hatch> frankban I'll try that approach and see how it works out
[16:45] <rick_h_> jujugui so https://github.com/juju/juju-gui/pull/281 is updated and looking for eyeballs please. 
[16:46]  * rick_h_ goes out to get some lunch
[16:46] <antdillon> hatch, assert.isTrue(stubApp.ecs.commit.calledOnce()); is false but it should defo be being hit
[16:47] <hatch> how are you stubbing it?
[16:48] <antdillon> hatch, http://paste.ubuntu.com/7417088/
[16:49] <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
[16:50] <hatch> and don't use isTrue (it doesn't give proper tracebacks) use equal() instead
[16:50] <antdillon> hatch, Ok thanks
[16:53] <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?
[16:54] <hatch> frankban yeah - I'll let you know if this works, atm I'm having trouble preventing the default soon enough
[17:00] <hatch> frankban looks like this technique won't work without a bunch of hackyness 
[17:00] <hatch> so we'll have to use your technique 
[17:01] <frankban> hatch: fullAdd?
[17:01] <hatch> yeah
[17:02] <hatch> frankban what if we modified the model BEFORE calling var result = MachineList.superclass.add.apply(this, args);
[17:02] <hatch> is that possible?
[17:02] <hatch> so invert how the new add method executes
[17:02] <frankban> hatch: that can be possible
[17:03] <frankban> hatch: especially because we are using lazy model lists, so we should not require calling instance methods
[17:03] <antdillon> hatch, Ah so I had to call stubApp.ecs.commit() to get true for stubApp.ecs.commit.calledOnce() 
[17:03] <hatch> frankban that's what I was thinking....ok I'll try that 
[17:03] <hatch> that makes sense
[17:04] <hatch> ^ antdillon 
[17:04] <antdillon> hatch, Is there a way to calledOnce on the none stubbed function?
[17:04] <hatch> no but you can call the original method
[17:05] <antdillon> The original method is called by the button click
[17:05] <hatch> https://github.com/juju/juju-gui/blob/develop/test/utils.js#L89
[17:05] <hatch> well if the original method is called by the button click then clicking the button should trigger the stub to be called
[17:06] <antdillon> hatch, Its not for some reason
[17:07] <rick_h_> antdillon: is the code up? Remember that button clicks are events and async
[17:07] <antdillon> hatch, But by debuggering and calling stubApp.ecs.commit()
[17:07] <rick_h_> antdillon: so you have to find a way to watch for that click
[17:07] <antdillon> the calledOnce returns true
[17:07] <hatch> my guess is you're running into an async issue
[17:07] <hatch> so what you need to do is listen to 'after' that click event
[17:07] <antdillon> hatch, I thought it might be a race :(
[17:07] <hatch> then test for the once() in there
[17:08] <hatch> so yeah....like rick_h_  said :)
[17:08] <antdillon> but with the debugger i ran calledOnce a while after the click and its still false
[17:09] <rick_h_> antdillon: right, so you created a mock, then you manually called the mock
[17:09] <rick_h_> what you want to do is create the stub, and watch it, and see who ELSE talks to it
[17:09] <rick_h_> antdillon: let me know if you want to hangout and I can help look at it. I'm free atm
[17:09] <antdillon> rick_h_, Ok that would be good. This is the final bit of tests for now
[17:10] <rick_h_> antdillon: hangout invite on the way
[17:11] <rick_h_> antdillon: https://plus.google.com/hangouts/_/grvtyzyt53dbgg2c4lkx6elfwya?authuser=1&hl=en
[17:12] <hatch> frankban inverting the execution order of add() fixed it :) yay
[17:13] <frankban> hatch: very cool
[17:13] <hatch> much happier
[17:13] <hatch> :)
[17:13] <frankban> yeah
[17:15] <hatch> frankban https://gist.github.com/hatched/84a65398d22fc3753ef6 here is the new method
[17:16] <frankban> hatch: cool, could you please change also the unitList one?
[17:17] <hatch> I could, that might be out of scope of this branch though
[17:17] <hatch> this branch already breaks the environment switcher 
[17:17] <hatch> lol
[17:22] <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
[17:26] <rick_h_> sure thing
[17:26] <rick_h_> hatch: will ping once done with antdillon 
[17:26] <antdillon> rick_h_, git@github.com:anthonydillon/juju-gui.git
[17:27] <hatch> yeah no rush
[17:32] <jcsackett> redir, bac: https://pastebin.canonical.com/109893/
[17:32] <jcsackett> post ingest, trying to start up charmworld.
[17:33] <redir> jcsackett: dude you broke i
[17:33] <redir> t
[17:33]  * jcsackett laughs
[17:33] <jcsackett> sorry, dude.
[17:34] <jcsackett> i didn't want to. :)
[17:34] <jcsackett> redir: i'm running tests now to see if we get something informative locally to help you debug.
[17:34] <jcsackett> `make check`, to be specific. could always clobber something bad in my environment and make your code work.
[17:39] <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
[17:39] <Makyo> hatch, boo.  Oh well, easy fix.
[17:40] <Makyo> Let me do that real quick.
[17:40] <hatch> thanks, sorry about that - I'm not sure how I didn't notice that in QA
[17:42] <rick_h_> hatch: time to chat?
[17:42] <rick_h_> looks like kadams54 found I missed the cleanup point whoops
[17:42] <hatch> rick_h_ maybe you should fix kadams54's issues he found in QA first :)
[17:43] <rick_h_> :P
[17:43] <hatch> welcome back to the dark side
[17:43] <hatch> mohohahaha
[17:43] <kadams54> I hate to say this, but huw suffered through multiple rounds of QA when I was working this branch
[17:43] <kadams54> He might be good to pull in for a second set of QA ees.
[17:43] <kadams54> eyes even
[17:44] <kadams54> He had a good knack for breaking this in increasingly complex ways
[17:44] <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 
[17:44] <antdillon> rick_h_, Branch up updated git@github.com:anthonydillon/juju-gui.git
[17:45] <antdillon> rick_h_, Heading home will be online in an hour
[17:45] <rick_h_> antdillon: do a pull request please
[17:45] <rick_h_> antdillon: it's easier then you can see the diff of what changes 
[17:45] <antdillon> rick_h_, Sure
[17:45] <rick_h_> thanks
[17:47] <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
[17:47] <hatch> frankban I'll take one
[17:47] <hatch> thanks for the hard work on it
[17:47] <jcsackett> frankban: i'll take the other.
[17:47] <frankban> thank you both!
[17:48] <jcsackett> frankban: no no, thank *you* for doing the work. my code needs it. :)
[17:48] <hatch> haha :)
[17:48] <frankban> heh
[17:49] <antdillon> rick_h_, https://github.com/juju/juju-gui/pull/283
[17:53] <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
[17:53] <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. :(
[17:54] <hatch> what version are you on?
[17:54] <hatch> 10.04? lol
[17:54] <jcsackett> 1.18.1-trusty. and i see no updates.
[17:54] <jcsackett> i get endless connection failures trying to bootstrap on local.
[17:55] <hatch> ohh is there a bug?
[17:56] <redir> I installed juju-local from ppa and then deleted /usr/bin/juju to get local provider
[17:56]  * jcsackett raises eyebrow.
[17:56] <jcsackett> redir: can you juju deploy to other providers, having done that?
[17:56] <redir> jcsackett: rebuilding cw/ngrams from scratch to ensure it works here
[17:56] <redir> jcsackett: havne't tried
[17:57] <redir> but I have a build in ~/go/
[17:57] <jcsackett> redir: yeah, i think i'll have to do the source build and figure out what i did wrong yesterday.
[17:57] <redir> and it requires the 'package' to be installed 
[17:57] <jcsackett> 'package'?
[17:57] <hatch> yeah there is a local package that needs to be installed separate
[17:57] <hatch> but usually it says so
[17:57] <Makyo> hatch, https://github.com/juju/juju-gui/pull/284
[17:58] <hatch> thanks, I'll qa  now
[18:00] <hatch> Makyo +1'd
[18:01] <Makyo> \o/
[18:01] <redir> jcsackett: a fresh checkout/branch from lp:~reedobrien/charmworld/ngrams "works for me"
[18:01] <Makyo> Realized all of my QA took place with an inspector URL already in place.
[18:01] <redir> jcsackett: 'package' == apt-get install juju-local
[18:02] <redir> which also installs juju-core
[18:03] <rick_h_> kadams54: call?
[18:05] <redir> bac: you ever resolve that npm conflict?
[18:05] <bac> redir: i did not but noticed nodejs installed /usr/bin/npm so my system is in working order
[18:07] <jcsackett> guihelp: we need someone else to qa redirs charmworld branch. anyone able?
[18:08] <rick_h_> hatch: got a sec?
[18:09] <hatch> I do
[18:09] <rick_h_> https://plus.google.com/hangouts/_/canonical.com/kyle-rick?authuser=1
[18:18] <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
[18:19] <redir> on trusty
[18:21] <jcsackett> bac ^ is this sort of thing likely necessary for a deploy, then?
[18:21] <jcsackett> redir: that also blows away the entire database...so have you done an ingest to see if it works once there's data?
[18:21] <redir> jcsackett: running now
[18:21] <jcsackett> redir: ok.
[18:22] <jcsackett> sorry this is such a pain. just be glad eventually all of this is going to be something better.
[18:22] <bac> jcsackett: we're deploying on precise.  the node/npm issues are not new to this branch.
[18:22] <redir> jcsackett: but I did this more than once yesterday
[18:22] <redir> better
[18:22] <bac> i mean, the issues are new but the requirements aren't.  i'm inelegantly trying to say i think it works on precise.
[18:22] <redir> bac: should I be developing on precise? I was doing it locally
[18:22] <redir> on trusty
[18:23] <redir> was/am
[18:23] <bac> i think we need to be on trusty
[18:23] <jcsackett> bac: i'm not having a node/npm issue, and my lxc is precise.
[18:23] <jcsackett> nonetheless, bin/es-update crashes on me with the ngram branch.
[18:23] <bac> jcsackett: oh
[18:23] <bac> how does it crash?
[18:24] <jcsackett> bac: https://pastebin.canonical.com/109893/
[18:24] <redir> bac: jcsackett sent this https://pastebin.canonical.com/109893/
[18:24] <bac> jcsackett: i thought the node/npm thing was the only issue, so i apologize for being uninformed
[18:24] <redir> jynx
[18:24]  * jcsackett laughs
[18:27] <rick_h_> hatch: ok, got it thanks
[18:27] <hatch> awesome
[18:28] <rick_h_> hatch: ok, I'm ready for qa and such, well after my call in 3
[18:28] <hatch> sure, I'm going to grab lunch now
[18:28] <hatch> so in a while :)
[18:30] <bac> jcsackett, redir: i'm perplexed
[18:31] <redir> jcsackett: bac: building a precise container to build in now
[18:31] <jcsackett> bac: so am i.
[18:32] <bac> that looks more like a coding error than an environmental one.  unless you're dealing with a different version of ES package.
[18:43] <redir> jcsackett: bac: es-0.90.0 here
[18:48] <jcsackett> bac: i don't actually know how to check es version.
[18:49] <rick_h_> dpkg -l | grep elasticsearch
[18:49] <bac> yeah, that
[18:50] <bac> but i think there's only the one version curtis packaged
[18:50] <redir> curl localhost:9200
[18:50] <bac> i've got 0.90.0.release+201305241158+repack8~precise1
[18:54] <jcsackett> i've got 0.90.0
[19:05] <jcsackett> bac, redir ^
[19:13] <redir> and you are on precise, jcsackett?
[19:13] <jcsackett> redir: yup.
[19:14] <redir> building precise now to test on 
[19:19] <rick_h_> woot, the NUCs have arrived. Now to wait a week to have time to play with getting them setup
[19:21] <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
[19:21] <rick_h_> hatch: heh, I'll try
[19:22] <hatch> All of the juju questions on askubuntu seem to be around maas
[19:22] <hatch> hardware must be hard
[19:28] <hatch> rick_h_ ok I'm done frankban's branch, did you want to run through your branch now?
[19:29] <rick_h_> hatch: sure, I blew up tests in this last batch but can run through it
[19:29] <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?
[19:30] <Makyo> I'm wondering if an interstitial branch fixed it by accident.
[19:30] <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
[19:31] <rick_h_> then went back to the service view after a reload, this was in a live env
[19:31] <rick_h_> when I was qa'ing against lxc
[19:31] <Makyo> Aha, that's the difference.  My bad.
[19:31] <rick_h_> hatch: did you want to call to walk through it?
[19:31] <rick_h_> hatch: or you good for now?
[19:33] <hatch> rick_h_ ok well lemme qa it
[19:33] <hatch> and i'll get back to you
[19:36] <redir> stil building
[19:38] <redir> I think the net is slow:/
[19:40] <redir> or maybe that is just archive.ubuntu.com that is slow
[19:41] <jcsackett> hatch: were you able to QA frankban's branch on a real env?
[19:41] <hatch> jcsackett I haven't yet 
[19:41] <hatch> I actually have an architectural change in the comments
[19:41] <hatch> so I wasn't sure if I was going to
[19:42] <redir> on precise it built and is now ingesting jcsackett bac
[19:42] <jcsackett> redir: cool. i look forwards (in an hour or so) hearing if bin/es-update crashes for you. :)
[19:43] <redir> bin/es-update is called when you run make run
[19:43] <hatch> rick_h_ QA'd
[19:43] <hatch> three issues, one meh, 2 need to be fixed
[19:44] <rick_h_> hatch: all good thanks for the qa
[19:44] <hatch> oh those issues were using il
[19:44] <hatch> I forgot to mention that in the comment
[19:45] <jcsackett> redir: yes.
[19:45] <redir> so wouldn't it crash when I do make run?
[19:45] <redir> jcsackett: it didn't
[19:45] <jcsackett> redir: but you hadn't ingested yet, right?
[19:46] <redir> not sure how that would differ.
[19:46] <redir> except if you had data that was already indexed with the old mapping and tried applying the new mapping over it
[19:47] <rick_h_> jujugui going afk, will finish up fixes and tests on my branches later on. 
[19:47] <hatch> cya
[19:47] <bac> ta
[19:47] <jcsackett> redir: i had no data at all before ingesting.
[19:47] <redir> caio
[19:47] <hatch> jcsackett take a look at my big comment in frankbans pr when you get a chance and let me know what you think
[19:47] <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.
[19:48] <jcsackett> hatch: changeUnits?
[19:48] <redir> OK
[19:48] <hatch> jcsackett yeah that comment
[19:49] <redir> I may not have done things in that order
[19:50] <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?
[19:50] <hatch> exactly
[19:50] <jcsackett> hatch: yeah, i don't like that. :P
[19:50] <hatch> because how it is right now, he needs to add a changeUnits method too
[19:51] <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?
[19:51] <jcsackett> i agree changeUnits should be added, but i like the interface he's suggesting here for working with the dual lists.
[19:53] <jcsackett> hatch: i feel like using events would make this interaction more opaque.
[19:53] <redir> bac have you been able to reproduce jcsackett's problem?
[19:54] <bac> redir: i have not tried.  i'm working on the demo issue
[19:54] <redir> bac right OK
[19:56] <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
[19:58] <hatch> I'm just trying to stick to conventions as much as possible
[20:01] <jcsackett> hatch: i don't know that we really gain anything in this instance by following convention.
[20:01] <jcsackett> we're doing something very specific to this collection--having modifications to it also sync other bits.
[20:02] <hatch> well we will never run into an issue where someone updates the unit list directly breaking the synchronization 
[20:02] <hatch> right now - if someone goes unitList.add() it's immediately out of sync
[20:02] <hatch> and it relies on codereview for people to 'know' that's incorrect
[20:02] <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.
[20:03] <jcsackett> the other way relies on reviewing the code to know that it has side effects, though, right?
[20:03] <jcsackett> either way people are going to have to read the code.
[20:03] <jcsackett> here at least you're only having to review one thing to see what is going on.
[20:04] <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
[20:04] <jcsackett> which we do. there's a big comment saying "don't do that".
[20:04] <hatch> only if you're reading the model
[20:04] <hatch> in 5/6 modellists you interact with it one way, 1/6 you need to use special methods
[20:05] <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?
[20:05] <hatch> that's not intuitive, and will likely silently fail
[20:05] <hatch> thats' fine if you don't know it's updating something else
[20:05] <jcsackett> 5/6 modellists don't keep two lists in sync, do they?
[20:05] <hatch> because that updating must happen
[20:05] <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.
[20:06] <hatch> yeah, but you know about this special unit update method
[20:06] <hatch> think 6mo down the line with some other devs
[20:07] <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.
[20:07] <hatch> haha
[20:07] <jcsackett> hatch: you are *not* suggesting he get rid of {add,change,remove}Units
[20:07] <jcsackett> hatch: you are suggesting a different way for them to work?
[20:08] <hatch> well, in that you don't call them directly, they are called by events on the master unit list
[20:08] <hatch> maybe we should have a quick hangout :)
[20:08] <jcsackett> give me 10 minutes to finish chasing something down in my code, then i'll ping you?
[20:09] <hatch> ok sure
[20:09] <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
[20:19] <redir> jcsackett: es-update works fine on trusty after insgesting. precise still ingesting.
[20:19] <jcsackett> redir: ok.
[20:20] <jcsackett> hatch: i can chat now, if you like.
[20:20] <hatch> cool one sec
[20:20] <hatch> jcsackett https://plus.google.com/hangouts/_/7acpi4pk3ossnove1b1upqgskk?hl=en
[20:26] <redir> bac juju local-provider apparently doesnt' work (out of the box) on lxc (nested lxc) so I am just doing it locally.
[20:48] <redir> jcsackett: bac http://pastebin.ubuntu.com/7418220/ works on lxc:precise  for me too
[20:50] <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.
[20:50] <jcsackett> i'll approve the MP.
[20:50] <bac> ftr, i have not tried precise.
[20:51] <redir> would be nice to have someone else get it owrkking besides me
[20:51] <redir> new guy
[20:52] <jcsackett> redir: agreed, we're just starved for time. :p
[20:53] <jcsackett> rick_h_: do you have time/capacity to QA redir's branch on precise?
[20:53] <redir> jcsackett: OK I'd ask rick_h_ how important landing it is then
[20:53] <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.
[20:53] <jcsackett> or find someone else who can.
[20:53] <redir> ack
[20:55] <jcsackett> of course, he's gone AFK
[20:55] <jcsackett> :p
[20:55] <jcsackett> redir: are you at EoD?
[20:57] <redir> jcsackett: close
[20:57] <redir> but will be online for a while
[20:59] <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.
[20:59] <jcsackett> or at least not anymore than it already has. :p
[21:00] <redir> building the local provider thing for bac & rick_h_ now
[21:20] <hatch> jujugui anyone available for a review for the machine view re-rendering bug fix https://github.com/juju/juju-gui/pull/285
[21:20] <Makyo> hatch, on it
[21:20] <hatch> thanks sir
[21:21] <hatch> hey huwshimi 
[21:21] <huwshimi> Morning
[21:21] <hatch> you're here early :)
[21:21] <hatch> I JUST proposed your branch
[21:21] <hatch> except it works now :PPPP
[21:21] <hatch> kehehe
[21:22] <huwshimi> hatch: Thanks very much!
[21:22] <hatch> you were very very close
[21:22] <hatch> gw
[21:23] <hatch> feel free to take a look at the diff between our two branches if you'd like to see the changes I made
[21:23] <huwshimi> hatch: It's also a pity that my branch on github doesn't have all the changes I made in it :(
[21:24] <hatch> uh oh....what do you mean? You forgot to push some stuff up? :)
[21:24] <huwshimi> hatch: Maybe :)
[21:24] <hatch> haha I hate you
[21:24] <hatch> can you do it as a follow-up after this one lands?
[21:25] <huwshimi> Yeah...
[21:25] <hatch> phew
[21:25] <hatch> github doesn't really do collaborative branches very well
[21:27] <hatch> huwshimi https://github.com/hatched/juju-gui/commit/1ca283b93fa9e33cbe37d7906dd365bd9960166d here is my diff
[21:27] <huwshimi> hatch: Actually, it looks like a rebase might have killed a bunch of my changes :(
[21:27] <hatch> aww boo
[21:27] <hatch> what were they?
[21:30] <huwshimi> hatch: I think it was mostly to do with setting the header labels correctly. I'll have to fix that all up.
[21:31] <huwshimi> hatch: It's also missing all my code comments and a bunch of other stuff.
[21:33] <huwshimi> hatch: I'm surprised the code worked at all.
[21:33] <hatch> lol
[21:33] <hatch> it works well actually with only some small fixes
[21:34] <huwshimi> hatch: I could have knocked off an hour or two earlier :(
[21:34] <hatch> haha 
[21:34] <hatch> darn
[21:37] <hatch> rick_h_ is there a next card you would prefer I hop on?
[21:38] <huwshimi> rick_h_: ^ let me know if there's a particular card for me today too.
[21:40] <hatch> he was stepping away a bit ago so he must not be back yet
[21:40] <hatch> huwshimi if you could do a qa on your branch that would be awesome
[21:40] <huwshimi> hatch: OK, will
[21:40] <hatch> thanks
[21:41] <huwshimi> hatch: No way to undo that rebase is there?
[21:41] <huwshimi> I know that's probably a stupid question
[21:42] <hatch> you can :) http://stackoverflow.com/questions/134882/undoing-a-git-rebase
[21:42] <jcsackett> hatch: where did you find icon data on the service?
[21:43] <hatch> jcsackett service.icon ;)
[21:43] <hatch> oh I mean service.get('icon')
[21:43] <hatch> :)
[21:44] <rick_h_> huwshimi: adding some uncommitted state would be cool if the machine view stuff is working. 
[21:44] <hatch> jcsackett https://github.com/juju/juju-gui/pull/277/files#diff-a52e5f6257113ed57354e9aaca710a65R61
[21:45] <hatch> rick_h_ oo do me next, do me next!!
[21:45] <rick_h_> hatch: where are we with frankban's branch? We need to get the unplaced tokens showing off that db info
[21:45] <huwshimi> rick_h_: OK, I'll take a look
[21:45] <rick_h_> hatch: so any of them around the inspector not showing but getting unplaced unit tokens
[21:45] <hatch> his branch isn't 'quite' done 
[21:46] <hatch> it's missing a change unit method and a safety net console.error on the native methods
[21:46] <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. 
[21:46] <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?
[21:46] <huwshimi> oh, exit the reflog and then 'git reset --hard HEAD@{21}'?
[21:47] <hatch> yeah
[21:47] <hatch> that
[21:47] <jcsackett> huwshimi: awesome.
[21:47] <huwshimi> scary!
[21:47] <hatch> (i was typing that) haha
[21:47] <jcsackett> er, hatch: awesome.
[21:47] <jcsackett> huwshimi: i'm sure you're awesome too.
[21:47] <huwshimi> :)
[21:47] <hatch> huwshimi basically you never want to commit passwords into git because git remembers EVERYTHING lol
[21:47] <huwshimi> :)
[21:48] <rick_h_> hatch: so if you can get me unplaced unit tokens when you drag/drop a service that'd rock. 
[21:48] <hatch> you 'can' delete commits but its lengthy
[21:48] <rick_h_> hatch: or the card where when you hit deploy you don't get an inspector popping upo
[21:48] <jcsackett> rick_h_: frankban's branch needs a changeUnits method and some protection around methods on the unitlist we should never ever use.
[21:48] <hatch> ^ that
[21:48] <rick_h_> hatch: we need drag/drop of the unplaced token into the other parts
[21:48] <rick_h_> ok, well if it's something you can do/add then let's run with it
[21:49] <rick_h_> everything we need to do to make this happen centers around interacting with the unplaced unit tokens
[21:49] <hatch> I won't be able to finish what needs to be done in his branch in an hour
[21:49] <rick_h_> hatch: k
[21:49] <rick_h_> well then one of the others mentioned ^
[21:49] <rick_h_> just assigned one :P
[21:50] <hatch> ok hit deploy, not opening the inspector
[21:50] <hatch> if we have an inspector open it needs to switch to a real inspector though, correct?
[21:51] <hatch> ohh I see the card
[21:51] <hatch> rick_h_ so luca is stuck on this 'no-inspector' thing hey?
[21:54] <rick_h_> hatch: yep
[21:54] <rick_h_> well Mark S is
[21:54] <hatch> ugh
[21:54] <hatch> *muted ugh*
[21:54] <hatch> lol
[21:54] <rick_h_> hatch: yea, it does need to switch, but if we don't have it open it sholdn't open on deploy 
[21:55] <hatch> yeah that's definitely a bug
[21:55] <huwshimi> hatch: So this branch has the changes the rebase lost: https://github.com/huwshimi/juju-gui/tree/bad-rebase
[21:55] <huwshimi> for some reason I can't get a diff against my other branch that doesn't have all the changes.
[21:56] <hatch> huwshimi ok once my PR lands then rebase this branch and PR with it
[21:56] <hatch> rebase this branch from develop that is
[21:56] <hatch> now that you got this code back you love git don't you?
[21:56] <hatch> :)
[21:57] <huwshimi> hatch: I think you know how much I love it.
[21:57] <jcsackett> i never thought i would say this, but i miss bzr.
[21:57] <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
[21:58] <hatch> huwshimi lol
[21:58] <hatch> jcsackett git has too much power for you? :P
[21:58] <hatch> you can't handle it!
[21:59] <rick_h_> hatch: right
[22:00] <hatch> ok on it
[22:01] <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.
[22:02] <rick_h_> redir: we'll have to put it on ice until post-demo time monday
[22:02] <redir> ack
[22:02] <rick_h_> redir: the other stuff is priority at the moment then I cna help QA or etc
[22:02] <redir> ack
[22:13] <huwshimi> hatch: I've added a couple of comments to the PR
[22:14] <hatch> thanks, looking
[22:19] <hatch> huwshimi so after I make these changes it's good to land?
[22:20] <huwshimi> hatch: Maybe, I wrote most of the code, so I don't think I can give it a proper review :)
[22:20] <hatch> haha, well did ou QA it?
[22:21] <huwshimi> hatch: Yeah, it seems to QA ok
[22:21] <hatch> sounds good, so I'll make these changes and then landed
[22:21] <hatch> land it
[22:21] <huwshimi> hatch: But again, as the author of the code, I'm only testing what I know :)
[22:23] <hatch> huwshimi so if there are no machines then the container column should be cleared as well
[22:23] <huwshimi> hatch: Yes.
[22:24] <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.
[22:25] <hatch> sounds good
[22:31] <huwshimi> rick_h_: What do we currently have in the machine view panel that can get into an uncommitted state?
[22:33] <jcsackett> i would just like to take this moment to point out we have both container-token.handlebars and token-container.handlebars
[22:34] <huwshimi> jcsackett: That's because we have a token-container.js widget and a container-token.js widget :)
[22:35] <jcsackett> right. so two moments, then, so we can all savor that.
[22:35] <hatch> huwshimi I'm landing the branch so you should be able to PR yours soon
[22:35] <huwshimi> hatch: Thanks!
[22:36] <hatch> jcsackett lol
[22:36] <hatch> no confusing at all
[22:44] <jcsackett> and then we just throw in the notion of 'container' as an html node...
[22:44]  * jcsackett segfaults
[22:46] <hatch> jcsackett I thought youw ere the one who made the token stuff
[22:46] <hatch> no?
[22:46] <jcsackett> hatch: i made the charm token.
[22:46] <jcsackett> which became the token.
[22:46] <jcsackett> and then was bisected, to become the bundle token.
[22:46] <jcsackett> and then...dear god.
[22:47] <jcsackett> but all i did was make the charm token.
[22:47] <huwshimi> hatch: I made container-token and macine-token
[22:47] <hatch> haha "token all the things!"
[22:53] <hatch> is there an aus meeting today?
[22:55] <huwshimi> hatch: Not sure...
[22:55] <hatch> rick_h_ ^
[22:56] <huwshimi> hatch: Do you know if there is anything in the machine view that can be in an uncommitted state?
[22:57] <hatch> new machines and containers
[22:57] <hatch> I also think that assigning a unit to a machine can also be uncommitted 
[22:58] <huwshimi> hatch: But we don't have any of that functionality now though do we?
[22:59] <hatch> lemme take a look
[23:00] <hatch> no we only have deploy, set config, and add relation
[23:00] <hatch> so far
[23:24] <redir> amionline
[23:25] <hatch> yes u r
[23:26] <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.
[23:26] <redir> thanks hatch 
[23:26] <hatch> :)
[23:33] <huwshimi> hatch: Here is the final set of changes: https://github.com/juju/juju-gui/pull/286
[23:38] <hatch> cool I'll take a look in a few
[23:40] <huwshimi> np
[23:43] <huwshimi> Need to fix tests anyway
[23:57] <huwshimi> Fixed.
[23:59] <jcsackett> Everyone celebrate. I have service units showing in all tokens.