[00:53] huwshimi ok the problem with web components isn't the technology, it's the people pushing it lol [00:56] uh oh [01:09] I'm out, cya tomorrow [03:47] hey huwshimi how goes the battle [03:54] hatch: Not bad. How's your evening going? [03:54] good good, trying to figure out if we can do web components in the gui [03:54] hah [03:55] Uh oh [03:55] * rick_h__ whispers no :P [03:55] about the only web component I'd see is our true/false toggle [03:55] lol! hey I'm trying to be open minded that web components are actually useful [03:55] maybe the fany underlying tab ui stuff [03:56] think small and they are [03:56] button, slider, etc [03:56] if you've gotten to one of our token widgets you went too big [03:56] right, but people seem to think they can roll whole sections and apps up into one element [03:56] yea, and that's where they're wrong [03:56] and why they'll fail [03:56] in my ever so humble opinion :) [03:56] heh yep , just like I said earlier :D [03:57] """hatch [03:57] huwshimi ok the problem with web components isn't the technology, it's the people pushing it lol""" [03:57] lol we agree on something, this must really be bad haha [03:58] it's the way of the web [03:58] something new comes out, people rush and push it beyond the useful limits [03:58] we all agree it's bad and we end up moving back a bit and then happy [03:59] see ajax, see client side apps, see web based mobile apps, see comet/server push, see ... [04:01] yup like kids with a new toy box [04:01] glad I'm a dev I don't have to grow up...always new toys to play with [04:01] :D [06:23] mornin' all === uru_ is now known as urulama [06:55] urulama: morning! [06:55] rogpeppe: morning [06:56] rogpeppe: you're early today, with mails at 7AM :D [06:57] urulama: yeah, it's all buzzing around my head, couldn't sleep in... [06:57] urulama: i've pushed a preliminary branch here, BTW: https://github.com/rogpeppe/charmstore/tree/003-router [06:57] urulama: i'm just writing tests for the existing code before moving on [07:00] ok, the /internal stuff, right? [07:03] urulama: well, it's all /internal so far... [07:14] urulama: wanna try the hangout again? [07:17] rogpeppe: give me 15min, need to go through mail [07:17] urulama: sure [07:17] rogpeppe: and i shut down the machine last night. case some hangouts driver got stuck in some strange state :S [07:17] urulama: it seems odd that it happened to both of us [07:28] rogpeppe: how do i go get gopkg.in/juju/charm.v2 for the 003-router branch? [07:28] urulama: go get it :-) [07:28] urulama: i.e. go get gopkg.in/juju/charm.v2 [07:28] i did, no /internal dir there :S [07:28] that's why i'm asking [07:28] urulama: i don't quite understand [07:29] urulama: the internal dir is in the charmstore package [07:29] urulama: in the 003-router branch [07:30] i did go get -u -v -t github.com/juju/charmstore/... as well [07:36] urulama: well, that will overwrite the 003-router branch if you had that downloaded [07:37] urulama: this is what i usually do: [07:37] urulama: go get github.com/juju/charmstore/... [07:37] urulama: cd $GOPATH/src/github.com/juju/charmstore [07:37] urulama: git remote add rogpeppe git@github.com:rogpeppe/charmstore [07:38] urulama: git fetch rogpeppe [07:38] urulama: git checkout rogpeppe/003-router [07:38] urulama: git checkout -b 003-router [07:38] 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] rogpeppe: fatal: Could not read from remote repository. [07:42] urulama: hmm, what command printed that? [07:43] git fetch rogpeppe [07:43] urulama: perhaps you haven't set up ssh. try this, perhaps: [07:43] git remote remove rogpeppe [07:44] git remote add rogpeppe https://github.com/rogpeppe/charmstore.git [07:44] urulama: then fetch rogpeppe again [07:44] fine now [07:45] urulama: ok. perhaps i did some setup to make that work a while ago [07:50] yeey, 4 passed :D [07:50] rogpeppe: let's gogogo [07:51] urulama: i am there [08:27] morning rogpeppe and urulama, how is it going? [08:27] frankban: hiya! [08:27] frankban: morning [08:27] frankban: we're in https://plus.google.com/hangouts/_/canonical.com/gogogo?authuser=1 [08:27] frankban: if you care to join us... [08:28] gogogo! [09:13] 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] morning [11:53] morning rick_h__ === BradCrittenden is now known as bac [12:00] frankban: morning, will be a couple min late [12:00] rick_h__: hi, np [12:05] frankban: omw === rbasak_ is now known as rbasak [12:27] frankban, urulama: i'm back from the sunshine... [12:27] frankban, urulama: how's it going? [12:28] 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] urulama: :-) [12:29] urulama: i guess it's time for our call now [12:29] urulama, rick_h__, frankban: shall we use the standup hangout? [12:29] rogpeppe: urulama frankban missed adding a video call, updated the calendar item [12:29] rick_h__: morning ping :D [12:29] link on the calendaer [12:29] err calendar [12:29] rick_h__: ta [12:30] rick_h__: link? it's not showing for me [12:30] https://plus.google.com/hangouts/_/canonical.com/charmstore-sync?authuser=1 [12:56] * rick_h__ fetches breakfast and coffee [13:39] kadams54: morning [13:39] rick_h__: mornin [13:40] 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] kadams54: sound good? [13:40] bac, thanks for fixing that rabbit searching bug [13:41] that was downright embarrassing, heh [13:41] 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] jcastro: yeah, glad to have that out of the way. [13:41] kadams54: ah ok, if it's almost there and can be cleaned up today then it's cool [13:41] 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] 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] 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] kadams54: we just want to not error for the 1.0 [13:48] 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] kadams54: hah, yea definitely a qa case to see if we can do. [13:49] rick_h__: we may also want to look at using supportedContainers on down the road, especially if ECS moves into juju-core. [13:49] 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] ok, is supportedContainers from core? [13:50] as part of the api? [13:50] Yeah. [13:50] Ok, and is it providing useful data currentlY? [13:50] So right now it doesn't know about ghosts, which means that I still need to code up the logic we discussed. [13:50] right, ok [13:51] rick_h__: not really useful right now. [13:51] kadams54: ok [13:52] 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] kadams54: right, how that works will be a bit diff, but definitely good to keep in mind [14:00] jujugui: ci has gone nuts. out of disk. seems to be a theme. [14:01] bac: :/ ok looking at the disk space available and seeing if we can bump it up [14:01] rick_h__: 1:1 now or after? [14:01] bac: let's do now. I'm really booked and not sure when after would be [14:41] 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] bac looking [14:41] as seen here: http://ci.jujugui.org:8080/job/juju-gui/1443/ [14:41] bac the e2e9bcf should be it [14:43] 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] bac origin/pr/445/merge [14:44] hatch: not sure what you mean. i was asking about the sha1 to give jenkins to start the build [14:45] bac yes, put that in the 'build parameters' 'sha' input and clck go [14:45] it'll run whatever is in the PR [14:45] so you don't need to mess around with sha's [14:45] hatch: really? so when it asks for a sha you give it a PR reference? [14:46] I do, yep [14:46] damn [14:46] I always pick the wrong sha for the merge so this works 100% of the time heh [14:48] hatch: almost makes me wish it took the PR number... [14:48] that would be ideal I always have to rely on the autocomplete to remind me of that syntax heh [14:49] rick_h__: i changed nothing on CI machine and the next build is working, at least got past the npm issues. glitch. [14:49] bac: k, yea npm is unhappy [14:49] or something [14:50] jujugui call in 10 [14:55] jujugui call in 5 [14:55] kanban please [15:00] kadams54: ^ [15:09] frankban: https://github.com/juju/juju-gui/pull/445 [15:10] thanks [15:11] urulama_: back in gogogo... [15:11] rogpeppe: ok, after my next hangout [15:11] frankban: we've integrated your tests and pushed the branch FYI [15:12] jrwren: you should have write access in your google calendar to a calendar called "Juju UI Engineering" [15:12] urulama_: I tend to stick things on there when I approve the time off requests of the gang [15:13] urulama_: ^ [15:13] rogpeppe: cool, I'll be with you in a minute [15:16] * urulama_ brb [15:16] wb frankban have a good vacation? [15:17] hatch: yes, very good one, thanks [15:18] excellent === urulama_ is now known as urulama [15:31] I've got to step out for a few mins, bbiab [16:03] jcsackett have you listened to the Bad Voltage podcast, it's sort of open source based.... [16:03] good production and entertaining at least :) [16:15] * rick_h__ goes to get lunch foods [16:28] jujugui enjoy the rest of the day, bye now [16:28] cya urulama [16:28] urulama: g'night! [16:30] http://www.meetup.com/DevOps-Exchange-London/events/194288152/ [16:39] 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] why does availability sets prevent quickstart from relying on bootstrap node? [16:52] jrwren: forcing a machine to colocate isn't supported over the juju api when AS are enabled [16:52] makes no senses to me. [16:52] 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] i see. [16:54] 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] 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] for azaure/AS [16:55] hatch, I believe so, you'll just lose reference to the node. [16:56] hatch, which ought to be fine. [16:56] I see 1.20 has availability-sets-enabled: false as an option. [16:56] Makyo ok thx, just wanted to see if there was any oddity to doing it that might not be immediately apparent [16:58] 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] i see. [16:59] 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] right [17:42] Makyo is there a reason why interface and scope are undefined on ghost relations? [17:43] hatch, no. [17:44] heh ok I'll look deeper into that too while I'm in here [17:44] hatch, ghost relations are a shoddy concept we only came up with in a rush to get demoware available. [17:45] ohh ok [17:45] that darn demo is still coming back at us haha [17:50] Makyo: can you give a +1 and QA OK to https://github.com/juju/juju-gui/pull/442 ? [17:51] Oops, sorry kadams54 , sure [17:53] jujugui realized I forgot to ping - quick review/QA for https://github.com/juju/juju-gui/pull/444 [18:03] Makyo: I can take a look. [18:03] kadams54, thanks [18:03] kadams54: hangout? [18:03] rick_h__: roger [18:05] rick_h__: am I not in the right room? [18:05] https://plus.google.com/hangouts/_/canonical.com/kyle-rick?authuser=1 [18:05] hey for demos, what's the feature flag for the machine view? [18:05] jcastro: /:flags:/mv [18:05] http://comingsoon.jujucharms.com/:flags:/mv to be full [18:07] ta [18:07] hey so I'm showing this at OSCON [18:07] :) [18:08] jcastro: umm ok what day is that? [18:08] tuesday [18:11] jcastro we are still heavily iterating on that comingsoon codebase... [18:12] but the good news is it'll get slow tomorrow [18:12] haha truth [18:12] jcastro: so the key is to make sure to test your setup before hand [18:12] jcastro: we'll be in london next week, so timezones apart [18:12] jcastro: in case you need something or the demo isn't working right [18:19] rick_h__ I still don't have my watch lol.... [18:21] hatch: lmao [18:23] rick_h__, don't worry, I'm going to pull from a known rev, not head [18:24] +1 [18:24] jcastro: ok [18:25] head is pretty stable....because....well....we are awesome :P [18:25] haha [18:28] 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] jrwren: chat in about 20-30? [18:29] instead of tomorrow? [18:29] sure. [18:29] k, will ping when I'm free [18:38] bye all. [18:44] !np [18:44] oops, misdir [18:53] jrwren: I'm free, the hangout room when you're ready? [18:56] k [19:00] jujugui: https://code.launchpad.net/~evarlast/juju-quickstart/upload-tools-constraints/+merge/227229 [19:01] oh... lbox. [19:02] https://code.launchpad.net/~evarlast/juju-quickstart/which-juju/+merge/227238 [19:13] rick_h__, jrwren: it's up for review: https://github.com/juju/charmstore/pull/14 [19:15] rogpeppe: cool thanks. Will peek at it. [19:15] rogpeppe: rope francesco into it in the morning for an ok. [19:15] rick_h__: he's already reviewed it [19:16] jrwren: might have to bug francesco in the morning for quickstart as well. bac is out now [19:16] rick_h__: made quite a few changes in response to his feedback [19:16] rogpeppe: ok awesome, will look tonight. [19:16] going to go afk for a bit before the australia calls tonight [19:16] rogpeppe: thanks for the link/updates [19:16] rick_h__: note: we're starting a new "v4" branch for the new charm store [19:17] v4 branch of the charmstore? what used v2? or is that just to sync the dep with the api version? [19:17] 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] i could easily make it v2 [19:18] rogpeppe: right, because the api is serving the old api still [19:18] rick_h__: yes [19:18] rogpeppe: maybe we do something where the package is the min supported api? [19:18] rick_h__: and from a Go perspective, the API will still be the same [19:18] rogpeppe: so if you've got charmstore v4, it might have v5, but v4 is supported in that package? [19:18] rick_h__: that's an interesting idea [19:18] rick_h__: still thinking... [19:18] rogpeppe: ok, well we can ponder it [19:19] rogpeppe: no rush on that end [19:19] have a good night man, past your EOD go relax [19:19] rick_h__: aaaanyway, it's v4 for the time being :-) [19:19] :) [19:19] rick_h__: i'm doing late today [19:19] rick_h__: still 40 mins to go [19:19] ah, that's right. [19:29] anyone good at git rebase? http://paste.ubuntu.com/7810589/ [19:29] i've "git add"ed all the files with conflicts [19:30] hatch: ^ [19:30] rogpeppe looking [19:31] rogpeppe it looks like it's saying that you can skip the patch [19:31] if status shows nothing has changed [19:31] you can also stop the rebase if you think you messed something up [19:31] hatch: wouldn't skipping the patch mean that i lose some of the changes in it? [19:31] using git rebase --abort [19:31] rogpeppe well it's saying that the changes were already made [19:31] 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] ohh you're in one of those situations [19:32] 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] weather that's correct or not, I can't say for sure :) [19:32] oh great, more conflicts [19:33] rogpeppe what was the rebase command you wrote? [19:33] at this point i lose faith in whether git will have actually preserved the changes i've made... [19:33] hatch: git rebase 003-router [19:33] hatch: this was after 003-router had itself be heavily rebased [19:33] and was this branch branched from 003-router? [19:34] hatch: (for submitting for review) [19:34] hatch: yup [19:34] hatch: except git wouldn't know that [19:34] ok so what it's doing then is taking 003-router and applying your commits on top of it [19:34] hatch: yup, probably including all the old 003-router commits themselves. [19:34] hatch: hmm. [19:34] so if 003 had been modified from the original source that's why it's causing issues [19:34] hatch: maybe patch is what i need here, not rebase [19:34] typically working on a 'source' branch is a bad idea if you plan on rebasing it into something else again [19:35] hatch: what do you mean by a "source" branch? [19:35] 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] that's what you're doing basically [19:36] hatch: yeah. unfortunately it's difficult to avoid that sometimes [19:36] yep [19:36] hatch: it works much better if noone rebases [19:36] hatch: but people like their clean histories [19:36] well rebase isn't the problem [19:36] the problem is that the branches have diverged [19:37] hatch: well, "replaying B's new commits" is rebasing, right? [19:37] right - but you could squash b's commits down so you have fewer to resolve the conflicts in [19:37] 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] thank god for reflog [19:39] 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] hatch: unfortunately B was based off a branch of A that was later rebased into a much earlier branch of A [19:40] 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] hatch: so, i *think* it was trying to replay A's own (rebased out of existence) commits onto itself [19:40] ahhh yes that's entirely possible [19:40] i was foolish to think it could ever work [19:42] it's probably possible to 'rebase' using cherry-pick if you wanted to go that route [19:42] basically manually repeating the rebase steps that it does internally but only picking the pertinent commits [19:43] hatch: ah, i know what i should've done [19:43] you could also use -i to choose which commits to apply [19:43] hatch: i should have rebased B in exactly the same way as A [19:44] sorry I can't say without actually seeing the repos :) [19:44] but....sure! :) [19:44] * rogpeppe tries it [19:52] bahaha this is a great small tweet thread https://twitter.com/SGItweets/status/489521012250140672 [19:54] rick_h__ ^ related to the previous chat about our new driving liquor laws :) [19:55] hey, I've been pushing revs to my bundle [19:55] but they don't appear in manage. [19:56] can someone check the ingest? it's been over 15min [19:57] hatch: patch(1) worked much better [19:57] rogpeppe ahh - so basically that will do the same as rebasing all the commits into one then applying that at the end :) [19:57] hatch: except i tried that and it didn't work [19:58] hmm [19:58] well....glad you were able to get something to work! [20:36] * rogpeppe is done for the day [20:36] g'night all [20:48] night rogpeppe [21:05] hatch: sorry I have been traveling a bit and missed your message re: ghost. But I did want to say \o/ [21:05] arosales heh no problem :) [21:05] now that that's out I need to figure out a way to port my tumblr posts to ghost [21:06] jujugui quick review/QA for subordinate services in MV https://github.com/juju/juju-gui/pull/446 [21:07] Makyo sure [21:07] Makyo so the interaction with subordinates with MV is a little funky eh? [21:08] they should probably be auto-placed on the same machine as it's host when related [21:08] thoughts? [21:08] 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] jcastro: more info? http://manage.jujucharms.com/heartbeat says ingest is running and processing [21:09] hatch: ya I need to figure out how to port my google blog over. [21:09] https://code.launchpad.net/~jorge/charms/bundles/elasticsearch/bundle [21:09] is the latest [21:09] but doesn't show up on manage [21:09] either that or I'm looking in the wrong place? [21:10] jcastro: looking [21:12] jcastro: the bundle doesn't proof [21:12] jcastro: it stopped ingesting after rev 2 [21:12] huh [21:12] jcastro: the indentation on the yaml is off [21:13] jcastro: so it can't parse [21:13] jcastro: if something doesn't ingest, proof is the first todo [21:13] 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] rick_h__, man I didn't even think of that, I just started revving after the first ingest, my bad [21:13] jcastro: all good [21:14] oh dude, I see what I did [21:14] jcastro: let me know if it still has any issues after fixing that up [21:14] darn yaml [21:14] annotations: [21:14] expose: true [21:14] "gui-x": "1106" [21:14] "gui-y": "371" [21:14] right [21:14] I put the expose line in the wrong part [21:14] proof blows up on there [21:14] gotcha [21:14] hatch, right. [21:14] * jcastro repushes [21:15] hatch, bring it up with UX, I suppose; that's what they're there for :) [21:15] jcastro: going to be afk, but will try to check on it when I come back for my australia calls tonight. [21:15] Makyo: hatch yea, I'd ignore it for now [21:15] 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] Makyo: hatch it seems most folks want to hide them anyway [21:15] * Makyo sweeps subordinates under the rug. [21:16] rick_h__ I suspect that's due to those darn lines all over the place [21:16] in mv it's saying 'this is on this container/machine' [21:16] hatch: right, and now it'll be the darn icon all over the place. [21:16] so finding the nagios service vs the subordinates might be a pita [21:17] hmm that's true.... [21:17] it'll be nicer with the show/hide in the deployment inspector [21:17] when you could toggle a sub. [21:17] well I'll fire an email off to UX and you guys can reply with your thoughts too [21:17] 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] oh yeah for sure [21:17] so I feel like we do have a long term answer [21:17] just need a next month answer [21:18] Makyo so is the only difference the conditional? I think so, just checking [21:18] hatch, yep, plus a test and a comment. [21:18] ok cool [21:18] +1, qa'ing [21:18] Makyo and your branches still aren't being picked up by CI [21:18] heh [21:18] I'm just busted :/ [21:22] Makyo would you mind doing a driveby and adding the is_subordinate check to the scale-up UI rendering? [21:22] I thought I had it in there but it looks like it must have been rebased out or something [21:23] I can give you a diff if you like :) [21:24] hatch, sure, diff would help [21:26] Makyo aweome thanks, diff added to PR [22:13] jujugui got the recommendation for Franco Manca for Really Good Pizza™ in London: https://goo.gl/maps/pMfnE [22:13] cool [22:17]