[00:00] <rick_h_> so in the sandbox with the simulator I've got two mysqls in one lxc container mysql/0 and mysql/5 
[00:01] <rick_h_> huwshimi: if you get a sec toss your card on the board please
[00:02] <huwshimi> rick_h_: Oh yes, sure.
[00:02] <rick_h_> huwshimi: thanks, will try to look after we settle this fire
[00:02] <huwshimi> rick_h_: It's all good. Let me know if I can help with anything.
[00:06] <hatch> running tests
[00:07] <rick_h_> hatch: rgr
[00:08] <Makyo> hatch, rick_h_ just curious, what's stopping us from using LXCs?  I've deployed to them on EC2 before; is this an openstack thing?
[00:08] <rick_h_> Makyo: yes, the demo hardware is openstack running on openstack
[00:08] <rick_h_> Makyo: not openstack on bare metal via maas like we thought
[00:08] <Makyo> Boo, so no containers?
[00:08] <Makyo> Ah, crap.
[00:08] <rick_h_> Makyo: yep, none at all, lxc or kvm
[00:08] <Makyo> That's where I was confused
[00:09] <rick_h_> so worst worst case we swap the drop target to the create new machine and just deploy a new service on a new machine via machine view, but if we can colocate on bare metal we can at least demo that as closer to what we want to show
[00:11] <hatch> ok rick_h_  it's up
[00:11] <rick_h_> hatch: rgr, updating my two envs
[00:14] <rick_h_> distfile building
[00:14] <rick_h_> dave in #juju think this won't work as --to is a hack and the api won't support it like we're trying to use it
[00:15] <hatch> lol 
[00:15] <Makyo> Can we just be pretty?
[00:15] <rick_h_> hatch: Makyo so probably be prepared to just try to create a new machine. I think we can move the drop target to the machine one, use the last commit, and just remove the machine parent? 
[00:16] <rick_h_> to deploy a new unit on a new machine (no parent machine id) and then after that machine bring up the unit
[00:16]  * rick_h_ is still holding out hope as these damn distfiles build
[00:16] <rick_h_> or what do you guys think?
[00:17] <hatch> so drop on the new machine header?
[00:17] <hatch> I thought the colo was the big deal?
[00:17] <Makyo> rick_h_, if that works, I'm all for it.  It sounds like a valid path, too.  "Let's deploy Nagios, just drag it onto a new machine..."
[00:17] <rick_h_> hatch: I did too until the last 30min
[00:18] <rick_h_> hatch: I'm cranky this isn't working out like we wanted, I'll be honest
[00:19] <rick_h_> Makyo: yea, that's my thought. It's a small step code-wise from where we were with lxc
[00:19] <hatch> good thing I saved that code 
[00:19] <hatch> lol
[00:19]  * hatch planned for this
[00:19] <hatch> haha
[00:19] <rick_h_> hatch: yea, thank you git
[00:19] <hatch> ok I'll make the machine header the droppable one
[00:19] <rick_h_> hatch: lol, plan for "the issue is going to be" 
[00:20] <hatch> haha
[00:20] <rick_h_> hatch: thanks, I'll still work on this qa here just to be sure
[00:20] <rick_h_> damn this distfile stuff is slow when you're watching it
[00:21] <rick_h_> oh npm wheee
[00:21] <rick_h_> I'm going to nuke that damn site one of these days
[00:21] <hatch> 'var container = db.machines.add({id: 'Hi Openstack!'});
[00:22] <hatch> kehehehe
[00:22] <rick_h_> lol
[00:22] <rick_h_> just don't makeit "Fuuuuuuuuuuuuuuuuuuuuuuuuuu"
[00:23] <hatch> do you know what the container type for bare metal is?
[00:23] <rick_h_> null? Makyo any idea?
[00:24] <hatch> I'll try undefined and see if it breaks
[00:24] <Makyo> no container type
[00:24] <Makyo> No parentId, no containerType
[00:24] <rick_h_> hatch: rm the attr?
[00:24] <hatch> coo
[00:24] <hatch> yeah
[00:24] <rick_h_> k
[00:25] <hatch> hehe apparenlty it doesn't like my machine name :D
[00:25] <rick_h_> lol
[00:27] <Makyo> Problem I'm getting now (probably fixed by having MS log in beforehand) is that on login, it displays a broken GUI rather than the login screen
[00:27] <Makyo> Until you refresh
[00:27] <Makyo> Then it offers the login screen
[00:27] <hatch> ok it's working but not showing the icon when it first creates the token
[00:27] <Makyo> Oh, flags.
[00:28] <Makyo> I had flags in the URL before loading login
[00:31] <Makyo> So, fwiw, everything works on EC2 if I just create a new machine with the unplaced unit
[00:31] <rick_h_> Makyo: ? 
[00:31] <Makyo> rick_h_, if I drag the unplaced unit to a new machine (what I'd guessed was the path, correct me if I'm wrong)
[00:31] <rick_h_> Makyo: ok, this is with hatch's latest?
[00:32] <Makyo> rick_h_, I think so, within the last 15 minutes.
[00:32] <hatch> that shouldn't work heh, maybe you're on the version HEAD~2 ?
[00:32] <rick_h_> Makyo: yea, what's version.js say?
[00:33] <rick_h_> hatch: Makyo let's hop in a hangout?
[00:33] <hatch> fire me a link, will be in in a min
[00:33] <hatch> just need to get the dogs in
[00:33] <rick_h_> k
[00:33] <Makyo> acb5d2a
[00:33] <rick_h_> https://plus.google.com/hangouts/_/g4qxjkx7wpe5uiwrl7eahe6fb4a?hl=en
[00:34] <rick_h_> Makyo: ok, so that's the latest "colocates on primary machine"
[00:35] <huwshimi> jcsackett: Did you implement the units on machines/containers? It might be our simulator, but it never shows more than one unit on a container/bare metal, even if there are more units showing for the machine than there are containers: https://dl.dropboxusercontent.com/u/1826926/units.png
[00:36] <huwshimi> If we're colocating, we might need to fix that if it's not a simulator issue
[00:40] <huwshimi> Oh, maybe our unit mapping is wrong, the extra units have a different machine id
[00:43] <rick_h_> huwshimi: yea, we'll have to look into it. Something's not right. I noticed it when doing the mongodb bundle
[00:54] <huwshimi> oh, it's matching the first part of the id, so a unit.machine = 12 will render on machine.id=1 and unit.machine = 25 will render to machine.id=2
[00:55] <rick_h_> huwshimi: heh, that seems ungood :)
[00:55] <huwshimi> Yeah... :)
[00:55] <rick_h_> good catch
[00:56] <rick_h_> ok, bootstrapped new lxc and ec2 envs on my desktop so I can throw moar power at the problem!
[01:04] <hatch> ok the machine token is being created before the unit is assigned
[01:04] <hatch> that's why it's not rendering properly
[01:05] <rick_h_> so when the machine is assigned we're unlazy-updating-relazying?
[01:05] <rick_h_> can the machine token watch the unit for changes?
[01:05] <rick_h_> and update accordingly?
[01:05] <hatch> the unfortunately named '_smartUpdateList' isn't very smart
[01:05] <rick_h_> lol
[01:05] <hatch> and falls over when called manually
[01:06] <hatch> I'm not sure why it fails
[01:06] <hatch> maybe I can manually clear it out
[01:07] <rick_h_> so updateMachines and smartUpdateList appear to only be for the unplaced unit list
[01:08] <rick_h_> oh never mind
[01:08] <rick_h_> misreading that
[01:08] <rick_h_> hatch: so if you call updateMachines it won't work?
[01:08] <rick_h_> _updateMachines that is
[01:08] <hatch> nope, just trying to look into why
[01:09] <rick_h_> hatch: what's _updateMachineWithUnitData for?
[01:09] <hatch> the unit doesn't yet know what machine it's being assigned to
[01:09] <hatch> so that doesn't help
[01:09] <hatch> so it's passed an empty list
[01:10] <rick_h_> hatch: when we place the unit we don't know the machine to updateMachineWithUnitData?
[01:11] <rick_h_> hatch: I'm getting at it's broken for a split second then updates
[01:18] <rick_h_> hatch: want to push up what you've got and I can pull down and help poke at it? 
[01:20] <hatch> yeah one sec
[01:20] <rick_h_> k thx
[01:23] <hatch> I'm pretty much back to https://github.com/hatched/juju-gui/commit/2f7a580bb5c0b81e154438422378b95d3adb2d7a
[01:23] <hatch> it's the closest I've gotten
[01:24] <rick_h_> hatch: cool, update the pr and I'll pull down and stab at it some
[01:25] <hatch> GOT IT
[01:26] <hatch> fffffuuuuuuuuuuuu
[01:26] <hatch> hah
[01:26] <hatch> rick_h_
[01:26] <hatch> I'll clean this mess up and push it up
[01:26] <rick_h_> huh?
[01:27] <hatch> I got it
[01:27] <hatch> it renders the icon
[01:28] <rick_h_> woot
[01:28] <hatch> it doesn't render the container though until after deploying
[01:29] <rick_h_> hatch: Makyo stand down, we've been bumped
[01:29] <hatch> But....I.....Just.....
[01:29] <hatch> I even just got the container to render
[01:29] <rick_h_> hatch: https://plus.google.com/hangouts/_/canonical.com/daily-standup?authuser=1
[01:30] <hatch> rick_h_ we r in
[01:35] <rick_h_> juju gui machine view demo killed, chat with me if you've got any questions. 
[01:36] <huwshimi> rick_h_: :(
[01:36] <rick_h_> huwshimi: acutally jump in ^ for a minute please
[01:37] <hatch> rick_h_ https://github.com/hatched/juju-gui/tree/unit-drop-n-place-machine
[01:38] <hatch> that one, when dropping the unplaced unit on the machine header creates a machine token and a container for the bare metal
[01:41] <rick_h_> hatch: thanks
[01:41] <rick_h_> hatch: make it a pr for me please
[01:41] <rick_h_> hatch: just mark it WIP so I can see the diff/qa-pr it easier
[01:42] <rick_h_> thanks man, see you all later in the week 
[01:42] <huwshimi> rick_h_: Cheers man, have a good one.
[01:42] <hatch> rick_h_ https://github.com/juju/juju-gui/pull/318
[02:27]  * huwshimi has lunch
[11:55] <rick_h_> morning
[11:57] <lazyPower> o/
[12:15] <redir> morning
[12:25]  * rick_h_ takes the boy off to day care, biab
[12:28] <redir> ooo, google chat has circle icons now
[12:49] <rick_h_> ooh, fancy
[12:49]  * rick_h_ is back
[12:53] <jcsackett> morning all.
[12:57] <rick_h_> jcsackett: can you check out huw's branches this morning please?
[12:57] <jcsackett> rick_h_: already looking.
[12:57] <rick_h_> jcsackett: and take over if necessary, he's out this week I believe
[12:57] <jcsackett> rick_h_: got it.
[12:57] <rick_h_> jcsackett: ty much, I'll take a peek at yours here. Jeff's will hold for a bit
[12:57] <jcsackett> rick_h_: thanks.
[12:58] <rick_h_> redir: let's setup a chat later today to go through your doc comments. Are you still going through the doc or set now?
[13:16] <redir> rick_h_: i'll go back through it some more. and will draw some pictures from my notes.
[13:16] <rick_h_> redir: ok cool
[13:16] <rick_h_> redir: when you're set and ready then let's setup a call to walk through it 
[13:16] <redir> reading the store code and setting up bzr branches under go -- which is new to me
[13:16] <redir> rick_h_: cool will do
[13:17] <rick_h_> redir: heh, yea welcome to the dual dvcs life :)
[13:21] <BradCrittenden> jcsackett: i'd like to get your feedback on my local charm ingestion branch when you have some time.  lp:~bac/charmworld/ingest-local-charms
[13:21] <jcsackett> bac: sure.
[13:21] <jcsackett> jujugui: i've just discovered i'm not part of ~juju-gui-peeps on launchpad anymore. assuming that's still the group to be in, can someone add me?
[13:21] <bac> jcsackett: ping me when you are free.  call it a mid-flight, pre-impy thing
[13:22] <jcsackett> bac: i'll ping you when i finish looking over huw's branch.
[13:22] <rick_h_> jcsackett: will do
[13:23] <rick_h_> jcsackett: added
[13:23] <jcsackett> rick_h_: thanks.
[13:23] <bac> go ~yellow
[13:23] <rick_h_> :)
[13:43] <jcsackett> bac: looking at a diff of yours now. you want to hangout when i've read it?
[13:44] <bac> yes, please
[13:47] <jcsackett> bac: this is incorporating the work you've been doing for the demo into the charmworld base, yeah?
[13:47] <bac> y
[13:48] <jcsackett> awesome.
[13:48] <jcsackett> one sec, lemme find a headset and i'll send you a hangout.
[13:53] <jcsackett> bac: https://plus.google.com/hangouts/_/gwcncgfm72mxid5ajoocxnc2cua?authuser=2&hl=en
[13:57] <bac> sorry jon, i'd gone to get a tea
[13:57] <bac> joining
[13:58] <bac> jcsackett: ^^
[13:59] <redir> bac: can I bug you about locations.conf and setting up bzr later? after your call
[14:00] <bac> redir: sure
[14:09] <bac> hi redir
[14:11] <redir> yo
[14:12] <redir> wanna hangout bac?
[14:13] <bac> redir: sure.  paste an url here
[14:13] <bac> redir: we have seven minutes before the keynote
[14:13] <redir> https://plus.google.com/hangouts/_/gshmjqp7flvrgad5bny2rybvwua?authuser=3&hl=en
[14:20] <rick_h_> reminder marks' keynote is coming up next
[14:20] <rick_h_> jujugui ^
[14:21] <rick_h_> jujugui no machine view, but should be cool
[14:21] <redir> where's the keynote?
[14:21] <redir> link...
[14:22] <rick_h_> https://www.openstack.org/home/Video/
[14:22] <redir> jujugui^
[14:22] <redir> tx
[14:22] <bac> so we're running a little late...
[14:22] <rick_h_> yea
[14:24] <bac> go solidfire!
[14:48] <kadams54> *fingers crossed*
[14:49] <bac> yay, the layout worked.
[14:50] <hatch> :-D
[14:54] <hatch> wow
[14:56] <redir> great work guys, you all rock
[14:56] <kadams54> Yeesh
[14:56] <bac> no spoilers.  i've got about a 20 second lag. :)
[14:56] <rick_h_> hah
[14:57] <kadams54> My "yeesh" was mostly the thought of using juju across centos, ubuntu, and windows. Craziness.
[14:57] <hatch> rofl
[14:58] <rick_h_> lol
[14:59] <kadams54> Anyone know if Mark's going to be demoing anything at the November 3rd summit in Paris?
[15:00] <bac> jujugui: standing up nowish?
[15:01] <rick_h_> bac: rgr, on my way
[15:16] <redir> what was that short lpad thing? lpad.in/something
[15:22] <rick_h_> hmm, not sure. 
[15:22] <rick_h_> I'd just stick the url in there, it's all good
[15:22] <redir> already done
[15:33] <bac> redir: for the lightweight co set up, this is all i need in my locations.conf: http://paste.ubuntu.com/7458051/
[15:43] <hatch> jcastro when I click the up button on HN the button just goes away, does that mean i've voted?
[15:43] <rick_h_> hatch: yep
[15:43] <rick_h_> you're good
[15:43] <jcastro> yes
[15:43] <hatch> (shitty UX)
[15:43] <hatch> :)
[15:43] <hatch> thx
[15:43] <jcastro> we were on the front page, now we're at the top of the 2nd page
[15:44] <hatch> must have moar clicks!
[15:44] <redir> hatch: that is hacker new not ui designer news
[15:44] <redir> s/new/news
[15:45] <jcastro> hatch, if it makes you feel better their search also sucks!
[15:45] <hatch> lol
[15:46] <redir> rick_h_: let me know if there is enough context in the merge request attached to that card
[15:46] <rick_h_> redir: rgr will do
[15:47] <rick_h_> my new amt ready intel nucs arrived so now trying to swap hardware so I can send back the first set :)
[17:03] <hatch> marcoceppi any progress on the GH to LP stuff for charms? I'd like to get the Ghost charm in the store
[17:19] <kadams54> jcsackett: Got some questions for you when have some time…
[17:23] <marcoceppi> hatch: I should be getting a proof of concept for my sync stuff by end of week
[17:24] <marcoceppi> got derailed getting more charms in to trusty
[17:28] <redir> thansk for the pointers bac, I have a working lightweight checkout now...forgot I had installed cobzr some time ago and had to  remove i t...
[17:33] <bac> redir: great.  stab cobzr.
[17:36] <kadams54> hatch: I caught up on some of last night's backlog when I came in this morning but was wondering: what's the latest with https://github.com/juju/juju-gui/pull/316 ?
[17:39] <kadams54> Awesome. I can consistently crash juju-gui:develop in Canary to the point of needing a kill -9.
[17:39] <kadams54> Tab won't even close
[17:49] <rick_h_> kadams54: hatch is out today. I'm going to work on mering the two branches and see if we can get them landable. 
[17:49] <rick_h_> kadams54: what's up?
[17:50] <kadams54> That branch has a lot of overlap with my stuff so I just want to make sure I coordinate
[17:52] <rick_h_> kadams54: ok. I'll be a bit. So just take a peek and we'll try to get yours in and update to match.
[17:53] <kadams54> Yeah… I'm actually working in Jeff's branch right now, so if you setup your own branch let me know so I can track the changes there.
[17:53] <rick_h_> k
[17:56] <rick_h_> redir: is qa still bin/enque followed by ingest?
[17:57] <redir> rick_h_: make run and in a diff window
[17:58] <redir> ./bin/es-ingest IIRC
[17:58] <redir> let me double check
[17:58] <rick_h_> bac: is bin/enque used any more? Looks like --debug got removed but the code using it didn't catch up
[17:58] <rick_h_> redir: es-update?
[17:58] <rick_h_> well that's just the fulltect update
[18:00] <redir> rick_h_: http://pastebin.ubuntu.com/7458731/
[18:01] <rick_h_> gotcha, yea I think bin/enqueue is gone and just hadn't been removed
[18:01] <bac> rick_h_: it may be used by the charm.  ingest-queued now does the big enqueue does as stand-alone
[18:01] <rick_h_> I've got too much old knowledge of how it used to work in my head
[18:01] <redir> rick_h_: I've got too much ignorance. 
[18:01] <rick_h_> bac: well bin/enque just fails because there's a if args.debug
[18:01] <rick_h_> but no debug
[18:01] <redir> It is bliss:)
[18:01] <rick_h_> arg is left
[18:02] <rick_h_> so guess the charm isn't using it either
[18:02] <redir> big report:)
[18:02] <redir> s/big/bug
[18:02] <rick_h_> bug even 
[18:03] <bac> rick_h_: no, charm isn't using it
[18:03] <rick_h_> bac: rgr, thanks for peeking
[18:07] <kadams54> rick_h_: when you get the chance, we should talk more about Jeff's branch and my card. I *think* my card may be resolved within the branch, but I can't verify in the current state.
[18:07] <rick_h_> kadams54: ok
[18:07] <rick_h_> shoot me a link
[18:08] <kadams54> https://plus.google.com/hangouts/_/gw7gremxriufe4kurfpnffyo3ya
[18:09] <redir> rick_h_: when are your comp/swap days
[18:09] <rick_h_> redir: when are mine? someday
[18:09] <rick_h_> not sure atm
[18:11] <redir> k
[18:24] <redir> how many charms are there?
[18:24] <hatch> ~200
[18:25] <rick_h_> 350 ish last I looked
[18:25] <hatch> but that number is a little odd because there are charms for different series which are the same, and then a lot that aren't in the store
[18:25] <hatch> oh wow that many? it's grown fast
[18:25] <redir> k. importing them in core-store to try reproducing a bug and up to 378...
[18:26] <redir> just wondering if it is near the end.
[18:26] <rick_h_> probably near it, but with trusty and such maybe not :)
[18:43] <rick_h_> redir bac: is there something to wipe the index? running es-update I get pyelasticsearch.exceptions.ElasticHttpError: (400, u'MapperParsingException[Analyzer [n3_20grams] not found for field [ngrams]]')
[18:44] <BradCrittenden> rick_h_: yes, let me look, though redir may have it handy
[18:45] <bac> rick_h: this should work: http DELETE 'http://localhost:9200/charms'
[18:45] <rick_h_> bac thx, retrying
[18:46] <jcsackett> bac: why do you keep becoming BradCrittenden?
[18:46] <bac> jcsackett: connection drops for a tiny bit, irc reconnects but sees 'bac' is already taken
[18:47] <bac> irc nick timeout is greater than my outage time
[18:47] <jcsackett> huh; i don't actually see you disconnecting/reconnecting.
[18:48] <rick_h_> bac has quit from #juju-gui ; Ping timeout: 252 seconds
[18:49] <bac> jcsackett: i can get momentarily booted when a large, norovirus incubator goes by
[18:50] <redir> 521 charms...
[18:50] <rick_h_> woot
[18:51] <jcsackett> bac: ... airplane?
[18:52] <redir> cruiseship
[18:56] <bac> jcsackett: i wouldn't want to be on that airplane
[18:56] <jcsackett> ah.
[18:56] <jcsackett> that makes more sense
[18:57] <rick_h_> redir: bac man I'm having all kinds of issues trying to ingest and get stuff loaded. http://paste.ubuntu.com/7458986/
[18:59] <rick_h_> I'm going to EOD soon, but just fyi, I'm trynig to get things down to QA and having a series of elasticsearch issues. 
[19:00] <rick_h_> hmm, bet that's from the clearing of the db
[19:01] <bac> rick_h_: that exception you pasted is in the 'save' method in the error handling section.  so saving threw an error and the corrective action is to delete the charm, which then errored b/c it did not exist.  i've never seen that before.
[19:01] <rick_h_> another restart going without errors 
[19:02] <rick_h_> bac: yea, I got impatient and tried to kill stuff and do qa without letting ingest finish
[19:02] <rick_h_> probably left stuff in a bad place
[19:02] <bac> oh
[19:02] <rick_h_> starting over again
[19:02] <bac> that error handling could be more robust
[19:02] <rick_h_> anyway, will let it run tonight while I'm out and hopefully be good tomorrow
[19:02]  * rick_h_ runs away a little bit early today. have a good night all
[19:03] <redir> rick_h_: k
[19:03] <redir> have a great eve
[19:32] <redir> what's a QA day?
[19:33] <redir> and what's an exploratory qa day
[19:33] <redir> ?
[19:33] <hatch> redir a day where it's your job to find a bug in the GUI
[19:33] <hatch> find & file 
[19:33] <hatch> we used to adhere to it pretty strictly, but lately it's been too much of a cram :)
[19:33] <jcsackett> oh shit, i was supposed to do that today.
[19:33] <redir> hmmm
[19:33]  * jcsackett makes note to find a bug tomorrow.
[19:34] <redir> like just take a day and use the gui looking for bugs?
[19:34] <redir> what is the diff btwn qa and exploratory qa?
[19:38] <hatch> redir exploratory qa means you have to go and try and break the app
[19:39] <hatch> do things in different ways, pretend you're a user who doesn't know what's going on etc
[19:39] <hatch> redir not really the day, just part of the day
[19:39] <redir> tx, hatch 
[19:40] <hatch> you'll be surprised what you find when you try and use the app in unintended ways :)
[19:40] <hatch> and with all the work that's been landing lately we no doubt created some bugs :)
[21:05] <rick_h_> oops, I had that on my stand up list to talk to jcsackett about and he wasn't there so missed it
[21:07] <BradCrittenden> hatch: who were you schooling on red velvet?  http://www.nytimes.com/2014/05/14/dining/red-velvet-cake-from-gimmick-to-american-classic.html
[21:07] <hatch> haha I don't remember
[21:07] <hatch> huw I think
[21:08] <hatch> oh man it needs to rain here
[21:08] <hatch> so dusty
[21:08] <bac> bah, take ours
[21:08] <hatch> gladly take some :)
[21:09] <bac> it comes with car-alarm-setting-off thunder too
[21:12] <hatch> hah sounds like your shock sensor is a litttle too sensitive
[21:13] <hatch> that landscape cloud builder thing is pretty darn cool
[21:13] <hatch> I'm re-watching the keynote heh
[21:21] <bac> hatch: not my car.  all of the other cars on the street...
[21:21]  * bac walkies
[21:21] <hatch> ahhh - is car crime bad there?
[21:22] <bac> ha, all crime is bad here
[21:22] <bac> not my little enclave, though
[21:23] <hatch> haha ok
[21:23] <bac> it also helps to not be a drug dealer or gang member.  for some reason they tend to be overrepresented in the statistics.
[21:27] <kadams54> guihelp https://github.com/juju/juju-gui/pull/320 is ready for a look-see. It's a WIP so not yet ready to land.
[21:28] <hatch> bac lol
[21:30] <hatch> kadams54 does it work?
[21:30] <kadams54> Yes
[21:30] <hatch> no units should fire a change event by default
[21:30] <hatch> because they are just objects
[21:30] <hatch> or did my wip branches land?
[21:31] <kadams54> No, your WIP branch did not land
[21:31] <kadams54> But I've seen it so I know placeUnit will revive the unit :-)
[21:31] <kadams54> env.placeUnit() that is
[21:31] <hatch> ohh ok so the placeUnit has the changes in it to revive
[21:32] <hatch> cool
[21:32] <hatch> :)
[21:32] <kadams54> QA instructions include console commands to grab a unit, revive it, and then set the machine ID.
[21:32] <hatch> I'm not really set up atm to do any qa/reviews 
[21:32] <hatch> just glanced through
[21:33] <hatch> what do you think of your smart updater stuff being able to diff the old list and new list and updating the tokens which need updating
[21:33] <hatch> that would be my preference....of course that's going to be more work to implement 
[21:33] <hatch> :)
[21:36] <kadams54> I agree that function needs to handle changes and not just the current additions/deletions
[21:36] <kadams54> But I think there's still a need for a function that can just hit a single machine in the list
[21:37] <hatch> you think so?
[21:37] <kadams54> Yeah, I was talking with rick_h_ earlier and there are going to be a lot of events that update/change a single machine
[21:37] <hatch> what I'm thinking is that at scale, we'll want to batch the changes in the UI
[21:39] <kadams54> Seems like, even if changes were batched, you'd still need a way to update a single token
[21:39] <hatch> I suppose this could actually be used by the smart renderer 
[21:39] <hatch> yeah