[00:53] <hatch> huwshimi ok the problem with web components isn't the technology, it's the people pushing it lol
[00:56] <huwshimi> uh oh
[01:09] <hatch> I'm out, cya tomorrow
[03:47] <hatch> hey huwshimi how goes the battle
[03:54] <huwshimi> hatch: Not bad. How's your evening going?
[03:54] <hatch> good good, trying to figure out if we can do web components in the gui
[03:54] <hatch> hah
[03:55] <huwshimi> Uh oh
[03:55]  * rick_h__ whispers no :P
[03:55] <rick_h__> about the only web component I'd see is our true/false toggle
[03:55] <hatch> lol! hey I'm trying to be open minded that web components are actually useful 
[03:55] <rick_h__> maybe the fany underlying tab ui stuff 
[03:56] <rick_h__> think small and they are
[03:56] <rick_h__> button, slider, etc
[03:56] <rick_h__> if you've gotten to one of our token widgets you went too big
[03:56] <hatch> right, but people seem to think they can roll whole sections and apps up into one element
[03:56] <rick_h__> yea, and that's where they're wrong
[03:56] <rick_h__> and why they'll fail
[03:56] <rick_h__> in my ever so humble opinion :)
[03:56] <hatch> heh yep , just like I said earlier :D
[03:57] <hatch> """hatch
[03:57] <hatch> huwshimi ok the problem with web components isn't the technology, it's the people pushing it lol"""
[03:57] <hatch> lol we agree on something, this must really be bad haha
[03:58] <rick_h__> it's the way of the web
[03:58] <rick_h__> something new comes out, people rush and push it beyond the useful limits
[03:58] <rick_h__> we all agree it's bad and we end up moving back a bit and then happy
[03:59] <rick_h__> see ajax, see client side apps, see web based mobile apps, see comet/server push, see ...
[04:01] <hatch> yup like kids with a new toy box
[04:01] <hatch> glad I'm a dev I don't have to grow up...always new toys to play with
[04:01] <hatch> :D
[06:23] <rogpeppe> mornin' all
[06:55] <rogpeppe> urulama: morning!
[06:55] <urulama> rogpeppe: morning
[06:56] <urulama> rogpeppe: you're early today, with mails at 7AM :D
[06:57] <rogpeppe> urulama: yeah, it's all buzzing around my head, couldn't sleep in...
[06:57] <rogpeppe> urulama: i've pushed a preliminary branch here, BTW: https://github.com/rogpeppe/charmstore/tree/003-router
[06:57] <rogpeppe> urulama: i'm just writing tests for the existing code before moving on
[07:00] <urulama> ok, the /internal stuff, right?
[07:03] <rogpeppe> urulama: well, it's all /internal so far...
[07:14] <rogpeppe> urulama: wanna try the hangout again?
[07:17] <urulama> rogpeppe: give me 15min, need to go through mail
[07:17] <rogpeppe> urulama: sure
[07:17] <urulama> rogpeppe: and i shut down the machine last night. case some hangouts driver got stuck in some strange state :S
[07:17] <rogpeppe> urulama: it seems odd that it happened to both of us
[07:28] <urulama> rogpeppe: how do i go get gopkg.in/juju/charm.v2 for the 003-router branch?
[07:28] <rogpeppe> urulama: go get it :-)
[07:28] <rogpeppe> urulama: i.e. go get gopkg.in/juju/charm.v2
[07:28] <urulama> i did, no /internal dir there :S
[07:28] <urulama> that's why i'm asking
[07:28] <rogpeppe> urulama: i don't quite understand
[07:29] <rogpeppe> urulama: the internal dir is in the charmstore package
[07:29] <rogpeppe> urulama: in the 003-router branch
[07:30] <urulama> i did go get -u -v -t github.com/juju/charmstore/... as well
[07:36] <rogpeppe> urulama: well, that will overwrite the 003-router branch if you had that downloaded
[07:37] <rogpeppe> urulama: this is what i usually do:
[07:37] <rogpeppe> urulama: go get github.com/juju/charmstore/...
[07:37] <rogpeppe> urulama: cd $GOPATH/src/github.com/juju/charmstore
[07:37] <rogpeppe> urulama: git remote add rogpeppe git@github.com:rogpeppe/charmstore
[07:38] <rogpeppe> urulama: git fetch rogpeppe
[07:38] <rogpeppe> urulama: git checkout rogpeppe/003-router
[07:38] <rogpeppe> urulama: git checkout -b 003-router
[07:38] <rogpeppe> urulama: then you can add your own remote (pointing to your own fork of charmstore) and push any of your own changes there
[07:42] <urulama> rogpeppe: fatal: Could not read from remote repository.
[07:42] <rogpeppe> urulama: hmm, what command printed that?
[07:43] <urulama> git fetch rogpeppe
[07:43] <rogpeppe> urulama: perhaps you haven't set up ssh. try this, perhaps:
[07:43] <rogpeppe>  git remote remove rogpeppe
[07:44] <rogpeppe> git remote add rogpeppe https://github.com/rogpeppe/charmstore.git
[07:44] <rogpeppe> urulama: then fetch rogpeppe again
[07:44] <urulama> fine now
[07:45] <rogpeppe> urulama: ok. perhaps i did some setup to make that work a while ago
[07:50] <urulama> yeey, 4 passed :D
[07:50] <urulama> rogpeppe: let's gogogo
[07:51] <rogpeppe> urulama: i am there
[08:27] <frankban> morning rogpeppe and urulama, how is it going?
[08:27] <rogpeppe> frankban: hiya!
[08:27] <urulama> frankban: morning 
[08:27] <rogpeppe> frankban: we're in https://plus.google.com/hangouts/_/canonical.com/gogogo?authuser=1
[08:27] <rogpeppe> frankban: if you care to join us...
[08:28] <frankban> gogogo!
[09:13] <rogpeppe> frankban, urulama: a quick hint for testing the metadata handlers: i'd populate the database with one or two collections containing some items, and register a collection type for each of them. then the tests can just be written assuming that data is there.
[09:13]  * rogpeppe goes back into the sunshine
[10:24]  * urulama lunches, will move to another place after
[11:07] <rick_h__> morning
[11:53] <BradCrittenden> morning rick_h__
[12:00] <rick_h__> frankban: morning, will be a couple min late 
[12:00] <frankban> rick_h__: hi, np
[12:05] <rick_h__> frankban: omw
[12:27] <rogpeppe> frankban, urulama: i'm back from the sunshine...
[12:27] <rogpeppe> frankban, urulama: how's it going?
[12:28] <urulama> rogpeppe: i did not continue, had to deal with mails and finally took time to look at the sprint docs and where the hell I'm going on Sunday :D
[12:29] <rogpeppe> urulama: :-)
[12:29] <rogpeppe> urulama: i guess it's time for our call now
[12:29] <rogpeppe> urulama, rick_h__, frankban: shall we use the standup hangout?
[12:29] <rick_h__> rogpeppe: urulama frankban missed adding a video call, updated the calendar item
[12:29] <urulama> rick_h__: morning ping :D
[12:29] <rick_h__> link on the calendaer
[12:29] <rick_h__> err calendar
[12:29] <rogpeppe> rick_h__: ta
[12:30] <rogpeppe> rick_h__: link? it's not showing for me
[12:30] <rick_h__> https://plus.google.com/hangouts/_/canonical.com/charmstore-sync?authuser=1
[12:56]  * rick_h__ fetches breakfast and coffee
[13:39] <rick_h__> kadams54: morning
[13:39] <kadams54> rick_h__: mornin
[13:40] <rick_h__> kadams54: looking at the WIP branch, it seems like it'd be a good idea to move the WIP forward sans the last item, and to get that qa'd landed and then work on that last point as a follow up.
[13:40] <rick_h__> kadams54: sound good?
[13:40] <jcastro> bac, thanks for fixing that rabbit searching bug
[13:41] <jcastro> that was downright embarrassing, heh
[13:41] <kadams54> rick_h__: yup. I had a good chat with hatch yesterday so the last point should be ready to land soon. I'll split it off into its own branch.
[13:41] <bac> jcastro: yeah, glad to have that out of the way.
[13:41] <rick_h__> kadams54: ah ok, if it's almost there and can be cleaned up today then it's cool
[13:41] <rick_h__> kadams54: but yea, on a but like that with lots of points I wanted to let you know it's a great plan to split them up as appropriate
[13:47] <kadams54> rick_h__: hatch and I talked about the supportedContainers attribute on the Machine model, which led to a discussion about containers nested within containers.
[13:47] <rick_h__> kadams54: right, it's a follow up 1.0 card as something we want to be able to show, but not create. And we show them flat
[13:47] <rick_h__> kadams54: we just want to not error for the 1.0 
[13:48] <kadams54> rick_h__: At some point I'm curious to see what happens in machine view with nested containers. There's currently no logic to filter them out, so I have no idea how they'll show up or possibly err out.
[13:48] <rick_h__> kadams54: hah, yea definitely a qa case to see if we can do. 
[13:49] <kadams54> rick_h__: we may also want to look at using supportedContainers on down the road, especially if ECS moves into juju-core.
[13:49] <kadams54> rick_h__: specifically for populating the list of possible containers when user drops an unplaced unit on a machine or the "create container" drop target.
[13:50] <rick_h__> ok, is supportedContainers from core?
[13:50] <rick_h__> as part of the api?
[13:50] <kadams54> Yeah.
[13:50] <rick_h__> Ok, and is it providing useful data currentlY?
[13:50] <kadams54> So right now it doesn't know about ghosts, which means that I still need to code up the logic we discussed.
[13:50] <rick_h__> right, ok
[13:51] <kadams54> rick_h__: not really useful right now.
[13:51] <rick_h__> kadams54: ok
[13:52] <kadams54> rick_h__: not useful because we don't support nested containers and juju-core doesn't know about ECS. But should those change…
[13:53] <rick_h__> kadams54: right, how that works will be a bit diff, but definitely good to keep in mind
[14:00] <bac> jujugui: ci has gone nuts.  out of disk.  seems to be a theme.
[14:01] <rick_h__> bac: :/ ok looking at the disk space available and seeing if we can bump it up
[14:01] <bac> rick_h__: 1:1 now or after?
[14:01] <rick_h__> bac: let's do now. I'm really booked and not sure when after would be
[14:41] <bac> rick_h__: if i wanted to manually restart https://github.com/juju/juju-gui/pull/445  which sha1 should i use?  i tried e2e9bcf but it did not look right as it showed a lot of unrelated changes in the jenkins build step.
[14:41] <rick_h__> bac looking
[14:41] <bac> as seen here: http://ci.jujugui.org:8080/job/juju-gui/1443/
[14:41] <rick_h__> bac the e2e9bcf should be it
[14:43] <rick_h__> bac: should be good with it as it is. gh is showing the right commit distance so this is a diff of the old/prev states of the test checkout
[14:43] <hatch> bac origin/pr/445/merge
[14:44] <bac> hatch: not sure what you mean.  i was asking about the sha1 to give jenkins to start the build
[14:45] <hatch> bac yes, put that in the 'build parameters' 'sha' input and clck go 
[14:45] <hatch> it'll run whatever is in the PR
[14:45] <hatch> so you don't need to mess around with sha's
[14:45] <bac> hatch: really?  so when it asks for a sha you give it a PR reference?
[14:46] <hatch> I do, yep
[14:46] <bac> damn
[14:46] <hatch> I always pick the wrong sha for the merge so this works 100% of the time heh
[14:48] <bac> hatch: almost makes me wish it took the PR number...
[14:48] <hatch> that would be ideal I always have to rely on the autocomplete to remind me of that syntax heh
[14:49] <bac> rick_h__: i changed nothing on CI machine and the next build is working, at least got past the npm issues.  glitch.
[14:49] <rick_h__> bac: k, yea npm is unhappy
[14:49] <rick_h__> or something
[14:50] <hatch> jujugui call in 10
[14:55] <rick_h__> jujugui call in 5
[14:55] <rick_h__> kanban please
[15:00] <rick_h__> kadams54: ^ 
[15:09] <bac> frankban: https://github.com/juju/juju-gui/pull/445
[15:10] <frankban> thanks
[15:11] <rogpeppe> urulama_: back in gogogo...
[15:11] <urulama_> rogpeppe: ok, after my next hangout
[15:11] <rogpeppe> frankban: we've integrated your tests and pushed the branch FYI
[15:12] <rick_h__> jrwren: you should have write access in your google calendar to a calendar called "Juju UI Engineering"
[15:12] <rick_h__> urulama_: I tend to stick things on there when I approve the time off requests of the gang
[15:13] <rick_h__> urulama_: ^
[15:13] <frankban> rogpeppe: cool, I'll be with you in a minute
[15:16]  * urulama_ brb
[15:16] <hatch> wb frankban  have a good vacation?
[15:17] <frankban> hatch: yes, very good one, thanks
[15:18] <hatch> excellent
[15:31] <hatch> I've got to step out for a few mins, bbiab
[16:03] <hatch> jcsackett have you listened to the Bad Voltage podcast, it's sort of open source based....
[16:03] <hatch> good production and entertaining at least :)
[16:15]  * rick_h__ goes to get lunch foods
[16:28] <urulama> jujugui enjoy the rest of the day, bye now
[16:28] <hatch> cya urulama 
[16:28] <rogpeppe> urulama: g'night!
[16:30] <hatch> http://www.meetup.com/DevOps-Exchange-London/events/194288152/
[16:39] <hatch> Makyo if I'm in a d3 text() is it acceptable to pass a bound fn as the callback so I can pass in reference to the db?
[16:51] <jrwren> why does availability sets prevent quickstart from relying on bootstrap node?
[16:52] <rick_h__> jrwren: forcing a machine to colocate isn't supported over the juju api when AS are enabled
[16:52] <jrwren> makes no senses to me.
[16:52] <rick_h__> if you colocate manually then juju can't help make sure that the units are allocated across areas of the AS so that it's safe 
[16:53] <jrwren> i see.
[16:54] <rick_h__> at least in the current implentation. With more work/effort we could eable things like highlighting services that are not 'safe' according to azure/AS rules, but it's not currently available
[16:54] <rick_h__> however the api changes hit juju and we found out after the fact upon release and so we had to remove colocation support
[16:54] <rick_h__> for azaure/AS
[16:55] <Makyo> hatch, I believe so, you'll just lose reference to the node.
[16:56] <Makyo> hatch, which ought to be fine.
[16:56] <jrwren> I see 1.20 has availability-sets-enabled: false as an option.
[16:56] <hatch> Makyo ok thx, just wanted to see if there was any oddity to doing it that might not be immediately apparent 
[16:58] <rick_h__> jrwren: right, but it's like turning off safe mode. It's not the default and not one we want to encourage through quickstart
[16:58] <jrwren> i see.
[16:59] <jrwren> makes good sense. a lot of these bugs reported are for features to make good demos and dev. It is important, just different.
[16:59] <rick_h__> right
[17:42] <hatch> Makyo is there a reason why interface and scope are undefined on ghost relations? 
[17:43] <Makyo> hatch, no.
[17:44] <hatch> heh ok I'll look deeper into that too while I'm in here
[17:44] <Makyo> hatch, ghost relations are a shoddy concept we only came up with in a rush to get demoware available.
[17:45] <hatch> ohh ok 
[17:45] <hatch> that darn demo is still coming back at us haha
[17:50] <kadams54> Makyo: can you give a +1 and QA OK to https://github.com/juju/juju-gui/pull/442 ?
[17:51] <Makyo> Oops, sorry kadams54 , sure
[17:53] <Makyo> jujugui realized I forgot to ping - quick review/QA for https://github.com/juju/juju-gui/pull/444
[18:03] <kadams54> Makyo: I can take a look.
[18:03] <Makyo> kadams54, thanks
[18:03] <rick_h__> kadams54: hangout?
[18:03] <kadams54> rick_h__: roger
[18:05] <kadams54> rick_h__: am I not in the right room?
[18:05] <rick_h__> https://plus.google.com/hangouts/_/canonical.com/kyle-rick?authuser=1
[18:05] <jcastro> hey for demos, what's the feature flag for the machine view?
[18:05] <rick_h__> jcastro: /:flags:/mv
[18:05] <rick_h__> http://comingsoon.jujucharms.com/:flags:/mv to be full
[18:07] <jcastro> ta
[18:07] <jcastro> hey so I'm showing this at OSCON
[18:07] <jcastro> :) 
[18:08] <rick_h__> jcastro: umm ok what day is that?
[18:08] <jcastro> tuesday
[18:11] <hatch> jcastro we are still heavily iterating on that comingsoon codebase...
[18:12] <rick_h__> but the good news is it'll get slow tomorrow
[18:12] <hatch> haha truth
[18:12] <rick_h__> jcastro: so the key is to make sure to test your setup before hand
[18:12] <rick_h__> jcastro: we'll be in london next week, so timezones apart
[18:12] <rick_h__> jcastro: in case you need something or the demo isn't working right
[18:19] <hatch> rick_h__ I still don't have my watch lol....
[18:21] <rick_h__> hatch: lmao
[18:23] <jcastro> rick_h__, don't worry, I'm going to pull from a known rev, not head
[18:24] <hatch> +1
[18:24] <rick_h__> jcastro: ok
[18:25] <hatch> head is pretty stable....because....well....we are awesome :P
[18:25] <hatch> haha
[18:28] <hatch> I just noticed my laptop no longer shuts off when I accidentally hit the power button....must have been an update of some sort
[18:29] <rick_h__> jrwren: chat in about 20-30?
[18:29] <rick_h__> instead of tomorrow?
[18:29] <jrwren> sure.
[18:29] <rick_h__> k, will ping when I'm free
[18:38] <bac> bye all.
[18:44] <jrwren> !np
[18:44] <jrwren> oops, misdir
[18:53] <rick_h__> jrwren: I'm free, the hangout room when you're ready?
[18:56] <jrwren> k
[19:00] <jrwren> jujugui: https://code.launchpad.net/~evarlast/juju-quickstart/upload-tools-constraints/+merge/227229
[19:01] <jrwren> oh... lbox.
[19:02] <jrwren> https://code.launchpad.net/~evarlast/juju-quickstart/which-juju/+merge/227238
[19:13] <rogpeppe> rick_h__, jrwren: it's up for review: https://github.com/juju/charmstore/pull/14
[19:15] <rick_h__> rogpeppe: cool thanks. Will peek at it. 
[19:15] <rick_h__> rogpeppe: rope francesco into it in the morning for an ok. 
[19:15] <rogpeppe> rick_h__: he's already reviewed it
[19:16] <rick_h__> jrwren: might have to bug francesco in the morning for quickstart as well. bac is out now
[19:16] <rogpeppe> rick_h__: made quite a few changes in response to his feedback
[19:16] <rick_h__> rogpeppe: ok awesome, will look tonight. 
[19:16] <rick_h__> going to go afk for a bit before the australia calls tonight
[19:16] <rick_h__> rogpeppe: thanks for the link/updates
[19:16] <rogpeppe> rick_h__: note: we're starting a new "v4" branch for the new charm store
[19:17] <rick_h__> v4 branch of the charmstore? what used v2? or is that just to sync the dep with the api version?
[19:17] <rogpeppe> rick_h__: yeah, i think having two out-of-sync package versions would be not great. then again, perhaps we don't want a new branch for v5. thinking...
[19:17] <rogpeppe> i could easily make it v2
[19:18] <rick_h__> rogpeppe: right, because the api is serving the old api still
[19:18] <rogpeppe> rick_h__: yes
[19:18] <rick_h__> rogpeppe: maybe we do something where the package is the min supported api?
[19:18] <rogpeppe> rick_h__: and from a Go perspective, the API will still be the same
[19:18] <rick_h__> rogpeppe: so if you've got charmstore v4, it might have v5, but v4 is supported in that package?
[19:18] <rogpeppe> rick_h__: that's an interesting idea
[19:18] <rogpeppe> rick_h__: still thinking...
[19:18] <rick_h__> rogpeppe: ok, well we can ponder it
[19:19] <rick_h__> rogpeppe: no rush on that end
[19:19] <rick_h__> have a good night man, past your EOD go relax
[19:19] <rogpeppe> rick_h__: aaaanyway, it's v4 for the time being :-)
[19:19] <rick_h__> :)
[19:19] <rogpeppe> rick_h__: i'm doing late today
[19:19] <rogpeppe> rick_h__: still 40 mins to go
[19:19] <rick_h__> ah, that's right. 
[19:29] <rogpeppe> anyone good at git rebase? http://paste.ubuntu.com/7810589/
[19:29] <rogpeppe> i've "git add"ed all the files with conflicts
[19:30] <rogpeppe> hatch: ^
[19:30] <hatch> rogpeppe looking
[19:31] <hatch> rogpeppe it looks like it's saying that you can skip the patch
[19:31] <hatch> if status shows nothing has changed
[19:31] <hatch> you can also stop the rebase if you think you messed something up
[19:31] <rogpeppe> hatch: wouldn't skipping the patch mean that i lose some of the changes in it?
[19:31] <hatch> using git rebase --abort
[19:31] <hatch> rogpeppe well it's saying that the changes were already made
[19:31] <rogpeppe> hatch: i don't really want to abort the rebase as i just spent 10 mins fixing the same conflicts over and over
[19:31] <hatch> ohh you're in one of those situations
[19:32] <hatch> yeah, so basically it's telling you that the changes for the commit you're trying to apply are already in the previous commit
[19:32]  * rogpeppe thinks he might go back and just make the changes manually
[19:32] <hatch> weather that's correct or not, I can't say for sure :)
[19:32] <rogpeppe> oh great, more conflicts
[19:33] <hatch> rogpeppe what was the rebase command you wrote?
[19:33] <rogpeppe> at this point i lose faith in whether git will have actually preserved the changes i've made...
[19:33] <rogpeppe> hatch: git rebase 003-router
[19:33] <rogpeppe> hatch: this was after 003-router had itself be heavily rebased
[19:33] <hatch> and was this branch branched from 003-router? 
[19:34] <rogpeppe> hatch: (for submitting for review)
[19:34] <rogpeppe> hatch: yup
[19:34] <rogpeppe> hatch: except git wouldn't know that
[19:34] <hatch> ok so what it's doing then is taking 003-router and applying your commits on top of it
[19:34] <rogpeppe> hatch: yup, probably including all the old 003-router commits themselves.
[19:34] <rogpeppe> hatch: hmm.
[19:34] <hatch> so if 003 had been modified from the original source that's why it's causing issues
[19:34] <rogpeppe> hatch: maybe patch is what i need here, not rebase
[19:34] <hatch> typically working on a 'source' branch is a bad idea if you plan on rebasing it into something else again
[19:35] <rogpeppe> hatch: what do you mean by a "source" branch?
[19:35] <hatch> well if B is branched from A, you then work on A, when you try and replay B's new commits on top of A there is a much higher probability of conflicts
[19:36] <hatch> that's what you're doing basically 
[19:36] <rogpeppe> hatch: yeah. unfortunately it's difficult to avoid that sometimes
[19:36] <hatch> yep
[19:36] <rogpeppe> hatch: it works much better if noone rebases
[19:36] <rogpeppe> hatch: but people like their clean histories
[19:36] <hatch> well rebase isn't the problem
[19:36] <hatch> the problem is that the branches have diverged 
[19:37] <rogpeppe> hatch: well, "replaying B's new commits" is rebasing, right?
[19:37] <hatch> right - but you could squash b's commits down so you have fewer to resolve the conflicts in
[19:37] <rogpeppe> hatch: in fact with these branches there were no actual conflicts at all AFAIK
[19:38]  * rogpeppe just goes and makes the changes again. there weren't so many.
[19:38] <rogpeppe> thank god for reflog
[19:39] <hatch> hmm a rebase should just work like butter if the B doesn't make changes to the same areas in the files as A
[19:39] <rogpeppe> hatch: unfortunately B was based off a branch of A that was later rebased into a much earlier branch of A
[19:40] <hatch> because it's simply taking A, creating a new temp branch C, applying B's commits to it in order, then changing C to be B and deleting B
[19:40] <rogpeppe> hatch: so, i *think* it was trying to replay A's own (rebased out of existence) commits onto itself
[19:40] <hatch> ahhh yes that's entirely possible
[19:40] <rogpeppe> i was foolish to think it could ever work
[19:42] <hatch> it's probably possible to 'rebase' using cherry-pick if you wanted to go that route
[19:42] <hatch> basically manually repeating the rebase steps that it does internally but only picking the pertinent commits 
[19:43] <rogpeppe> hatch: ah, i know what i should've done
[19:43] <hatch> you could also use -i to choose which commits to apply
[19:43] <rogpeppe> hatch: i should have rebased B in exactly the same way as A
[19:44] <hatch> sorry I can't say without actually seeing the repos :)
[19:44] <hatch> but....sure! :)
[19:44]  * rogpeppe tries it
[19:52] <hatch> bahaha this is a great small tweet thread https://twitter.com/SGItweets/status/489521012250140672 
[19:54] <hatch> rick_h__ ^ related to the previous chat about our new driving liquor laws :)
[19:55] <jcastro> hey, I've been pushing revs to my bundle
[19:55] <jcastro> but they don't appear in manage.
[19:56] <jcastro> can someone check the ingest? it's been over 15min
[19:57] <rogpeppe> hatch: patch(1) worked much better
[19:57] <hatch> rogpeppe ahh - so basically that will do the same as rebasing all the commits into one then applying that at the end :)
[19:57] <rogpeppe> hatch: except i tried that and it didn't work
[19:58] <hatch> hmm
[19:58] <hatch> well....glad you were able to get something to work!
[20:36]  * rogpeppe is done for the day
[20:36] <rogpeppe> g'night all
[20:48] <hatch> night rogpeppe 
[21:05] <arosales> hatch: sorry I have been traveling a bit and missed your message re: ghost.  But I did want to say \o/
[21:05] <hatch> arosales heh no problem :) 
[21:05] <hatch> now that that's out I need to figure out a way to port my tumblr posts to ghost
[21:06] <Makyo> jujugui quick review/QA for subordinate services in MV https://github.com/juju/juju-gui/pull/446
[21:07] <hatch> Makyo sure
[21:07] <hatch> Makyo so the interaction with subordinates with MV is a little funky eh?
[21:08] <hatch> they should probably be auto-placed on the same machine as it's host when related
[21:08] <hatch> thoughts?
[21:08] <Makyo> hatch, subordinates aren't "placed".  adding the juju-info relation places them alongside the unit that they're related to.  Machine view is almost not applicable to subordinates.
[21:09] <rick_h__> jcastro: more info? http://manage.jujucharms.com/heartbeat says ingest is running and processing
[21:09] <arosales> hatch: ya I need to figure out how to port my google blog over.
[21:09] <jcastro> https://code.launchpad.net/~jorge/charms/bundles/elasticsearch/bundle
[21:09] <jcastro> is the latest
[21:09] <jcastro> but doesn't show up on manage
[21:09] <jcastro> either that or I'm looking in the wrong place?
[21:10] <rick_h__> jcastro: looking
[21:12] <rick_h__> jcastro: the bundle doesn't proof
[21:12] <rick_h__> jcastro: it stopped ingesting after rev 2
[21:12] <jcastro> huh
[21:12] <rick_h__> jcastro: the indentation on the yaml is off
[21:13] <rick_h__> jcastro: so it can't parse
[21:13] <rick_h__> jcastro: if something doesn't ingest, proof is the first todo 
[21:13] <hatch> Makyo right, but I'm wondering if the user will be confused that they added a service and it's not in the machine view
[21:13] <jcastro> rick_h__, man I didn't even think of that, I just started revving after the first ingest, my bad
[21:13] <rick_h__> jcastro: all good
[21:14] <jcastro> oh dude, I see what I did
[21:14] <rick_h__> jcastro: let me know if it still has any issues after fixing that up
[21:14] <hatch> darn yaml
[21:14] <jcastro>       annotations:
[21:14] <jcastro>       expose: true
[21:14] <jcastro>         "gui-x": "1106"
[21:14] <jcastro>         "gui-y": "371"
[21:14] <rick_h__> right
[21:14] <jcastro> I put the expose line in the wrong part
[21:14] <rick_h__> proof blows up on there
[21:14] <rick_h__> gotcha
[21:14] <Makyo> hatch, right.
[21:14]  * jcastro repushes
[21:15] <Makyo> hatch, bring it up with UX, I suppose; that's what they're there for :)
[21:15] <rick_h__> jcastro: going to be afk, but will try to check on it when I come back for my australia calls tonight. 
[21:15] <rick_h__> Makyo: hatch yea, I'd ignore it for now
[21:15] <hatch> yeah - I'll fire off an email just wanted to bring it up to get some other input, I've been sending them a bunch of emails they probably hate me
[21:15] <rick_h__> Makyo: hatch it seems most folks want to hide them anyway
[21:15]  * Makyo sweeps subordinates under the rug. 
[21:16] <hatch> rick_h__ I suspect that's due to those darn lines all over the place
[21:16] <hatch> in mv it's saying 'this is on this container/machine'
[21:16] <rick_h__> hatch: right, and now it'll be the darn icon all over the place. 
[21:16] <rick_h__> so finding the nagios service vs the subordinates might be a pita
[21:17] <hatch> hmm that's true....
[21:17] <rick_h__> it'll be nicer with the show/hide in the deployment inspector
[21:17] <rick_h__> when you could toggle a sub. 
[21:17] <hatch> well I'll fire an email off to UX and you guys can reply with your thoughts too
[21:17] <rick_h__> so I'm all for sweeping for today, and bringing them back when we can provide a good UX with the deployed services inspector
[21:17] <hatch> oh yeah for sure
[21:17] <rick_h__> so I feel like we do have a long term answer
[21:17] <rick_h__> just need a next month answer
[21:18] <hatch> Makyo so is the only difference the conditional? I think so, just checking
[21:18] <Makyo> hatch, yep, plus a test and a comment.
[21:18] <hatch> ok cool
[21:18] <hatch> +1, qa'ing
[21:18] <hatch> Makyo and your branches still aren't being picked up by CI
[21:18] <hatch> heh
[21:18] <Makyo> I'm just busted :/
[21:22] <hatch> Makyo would you mind doing a driveby and adding the is_subordinate check to the scale-up UI rendering?
[21:22] <hatch> I thought I had it in there but it looks like it must have been rebased out or something
[21:23] <hatch> I can give you a diff if you like :)
[21:24] <Makyo> hatch, sure, diff would help
[21:26] <hatch> Makyo aweome thanks, diff added to PR
[22:13] <Makyo> jujugui got the recommendation for Franco Manca for Really Good Pizza™ in London: https://goo.gl/maps/pMfnE
[22:13] <hatch> cool
[22:17] <hatch> well it doesn't look like navigation works on this watch rick_h__ 
[22:18] <hatch> Makyo that's a long walk :)
[22:18] <hatch> thinking for supper?
[22:18] <Makyo> hatch, it's on the Northern line, though.
[22:18] <Makyo> Yeah
[22:20] <hatch> cool
[22:20] <hatch> maybe this watch requires Google Now for the navigation to work properly
[22:20] <Makyo> Also, some good Sichuan food near Leicester Square. :9
[22:22] <hatch> haha you can your sichuan food
[22:22] <hatch> and*
[22:22] <Makyo> I'm hooked! :)
[22:22] <Makyo> We don't have any in CO.
[22:24] <hatch> ok now I'm officially creeped the frig out - I added Google Now to my phone, which told me how to get to a store I searched for earlier today which I need to go to tonight, and it popped up on my computer to add Google Now to Chrome....
[22:25] <rick_h__> hatch: :)
[22:25] <rick_h__> hmm, is huw around tonight?
[22:25] <rick_h__> or is he starting traveling already?
[22:25] <hatch> he didn't mention yesterday anything about not being here today
[22:26] <rick_h__> yea
[22:26] <hatch> it's still pretty early there....7:25
[22:26] <rick_h__> ok, will give it another bit
[22:26] <hatch> sometimes his start time fluctuates :) probably with how much the baby cried 
[22:26] <hatch> haha
[22:28] <huwshimi> Morning
[22:28] <hatch> goood morrow my good sir
[23:12] <hatch> so....is there an AUS call?
[23:19] <huwshimi> hatch: Oh, we had one
[23:19] <hatch> oh lol
[23:19] <hatch> WELL THEN!
[23:51] <hatch> rick_h__ I figured out how to do make it turn on when moving it, I have to swing it from my side, all the way to about 8" from my mouth....
[23:52] <hatch> needs some tweaking me thinks :)
[23:52] <rick_h__> hatch: for me it's about the angle. If I rotate it so the watch face faces me
[23:52] <rick_h__> it lights up, and will accept an 'ok google' without needing to be touched
[23:52] <rick_h__> so when driving, I can point it at me, 'ok google, text erica....'
[23:53] <rick_h__> and not have to touch it at all
[23:53] <hatch> ohh, ok I have to over-rotate my wrist
[23:53] <hatch> my wrist doesn't turn far enough I guess lol
[23:53] <rick_h__> :P
[23:53] <hatch> is android wear open source?
[23:53] <hatch> I wonder if I can file a bug
[23:53] <rick_h__> I'll stop with the 'must not be built for canadian wrists' jokes :P
[23:53] <hatch> it's literally a few degrees too far 
[23:53] <hatch> haha
[23:54] <rick_h__> well, hopefully less hand waving to activate it
[23:54] <hatch> yeah
[23:54] <hatch> it;s still definitely very early