[00:26] bcsaller, pong [00:26] bcsaller, qualified endpoints should work [00:27] ahh, ok, thanks [00:27] I can emit the proper thing then [00:30] bcsaller, cool, 'annotations' as dict key under service bag, and environment/stack/bundle annotations as top level 'annotations' key.. sound good?.. also a format key [00:31] hazmat: all good, and then charm name can be cs: prefixed, right? [00:33] bcsaller, how about just omitting the branch tag, cs: prefix optional [00:34] bcsaller, check email for all the ways to spell relations currently [00:34] hazmat: so charm: wordpress, branch: cs:precise/wordpress ? [00:34] hazmat: thanks [00:35] bcsaller, not quite.. charm: wordpress spells cs:/wordpress without the branch qualifier [00:35] ahh, ok, didn't realize it would combine series automatically [00:36] bcsaller, default series for resolution is already spelled above the service collection in the config [00:37] yeah, makes sense [00:38] bcsaller, are you exporting a whole env or subset? [00:39] hazmat: for now the whole, when we have a UI for selections I think allowing a subset will make sense [00:41] morning huwshimi [00:42] hatch: Hello [01:47] hows your day going huwshimi? [01:49] hatch: Not bad, yourself? Well, evening by now I guess :) [01:49] haha yeah - I spent too much time today reviewing stuff so I am putting in some OT to try and get back on track [02:24] Sticking with this from now on: http://loremgibson.com/ [02:25] what...the....heck? [02:26] Maaay require prior obsessive rereadings of William Gibson to find funny.. [02:27] I'm going to guess [02:28] Ah well :) [02:28] I'm working to an 8h Ferry Corsten set [02:28] heh [02:29] somehow I'm getting two services in the gui on deploy and it's irritating me [03:26] dogwalk, come back, solve in 30s heh [12:37] teknico: if you look at fakebackend.js:756 you'll see the error message contains backquotes so my test is just matching what is there. [12:38] teknico: do you find them so offensive that you want me to change the original? [12:40] gary_poster: started trunk CI tests in ec2 [12:40] thanks frankban :-) [12:47] hatch, if you have a quick second today to reply to ant's reply about your CSS/JS design guide concerns that would be great [12:56] bac: only mildly so, or I'd have noticed it earlier, so don't bother [12:56] bac: it looks out of place, like some kind of go-ism [12:56] teknico: too late! done. [12:57] bac: that's still good, thanks :-) [13:04] bac: You sent me "The configuration and constraints in Juju still do not support units." can you expand on that? [13:05] sorry Luca___, i meant numerical units, e.g. 4 Gb [13:05] bac: so, what does it relate to? [13:07] Luca___: the display of the constraints where you have 2.0 GHz and 8 GB [13:07] we'll have a 2 and an 8 but no idea of the units [13:45] hatch: ahoy? [13:46] Luca___: ping, can I get a 48x48px of the default charm icon? I'm looking and not finding the .svg for that only the pngs for 64/96/etc [14:02] sinzui: so setting a min-width on the whole thing is working. Please let me know when the deploy is looked at. I'll point things at staging for the moment. [14:03] morning [14:03] I am already on it [14:03] sinzui: thanks [14:15] hatch, howdy. Quick question once you're settled in. [14:17] Makyo: shoot [14:17] my damn coffee machine isn't working properly [14:17] hatch, boo, get that fixed ASAP! [14:17] yeah I might need to take a run to starbucks or something [14:18] hatch: let me know when you have a minute to discuss your review of my branch [14:19] ok Makyo your question? [14:20] hatch, I'm curious if I might be missing something. I can't deploy a charm with trunk and /:flags:/serviceInspector because I don't get a configuration panel. [14:21] Sorry, haven't tested trunk directly, after merging with trunk, I mean.. [14:21] hmm that's no good, checking trunk [14:22] I am too. If it works there, I can narrow it down to a conflict. [14:23] yeah it's working in trunk [14:23] when I merged trunk into my branch the code which handles the flag in app.js init got very munged up [14:23] It's not for me, but that might be a cache thing. [14:24] Hmm., [14:25] ohhh wait my trunk is right messed up [14:25] i'll delete and pull it down again [14:26] Makyo: ok I see the same issue [14:26] one sec for a fix [14:27] Makyo: in my local branch I fixed this but for a temporary fix... comment out app.js:584 [14:27] you won't get a ghost but a service will show up after deploy [14:29] rick_h, The revno 279 is now set in production and the page I was watching is correct [14:30] sinzui: looking [14:30] hatch, but your branch fixes that, yes? [14:30] Makyo: yeah I rewrote that whole section [14:30] sinzui: awesome, thanks [14:30] hatch, okay. [14:30] hatch, Will land mine with the comment so that it works for others, then yours will uncomment. [14:30] Sound good? [14:30] sure thing [14:31] I have an odd relation line bug in my branch which I'll need a hand solving but first to get benji going [14:31] benji: did you want to guichat? [14:31] sounds good [14:32] oh looks busy [14:32] hatch: it's occupied; I'll make a hangout [14:32] okee [14:33] post the link plz [14:34] hatch: https://plus.google.com/hangouts/_/79da42ca1e152d6421fc0cdec80ba437a18b0253?hl=en [14:42] woo 370 test failures! go me! [14:49] orangesquad: Could you please review https://code.launchpad.net/~abentley/charmworld/fix-update-charm-branch-call/+merge/171320 ? [14:50] abentley: r=me [14:50] rick_h: Thanks! [14:58] rick_h: you're a pro! [14:58] jujugui, call about inspector wireframes with Luca___ in 33 minutes in guichat. Please make sure you have reviewed them by then. I will send out an email [14:58] Makyo: have a second to chat about that relation line bug I mentioned? [14:59] hatch: what did I do now? [14:59] hatch: you have time to chat about starting inspector work? [14:59] hatch: oh, my tests. [14:59] 370 test failures [15:00] BradCrittenden: sure I'd just like to show Makyo a bug which I'm hoping he can point me to solve [15:00] hatch could I ask you to also prep to talk about how to build this stuff? Maybe you and I could talk beforehand soonish? [15:00] hatch: ok === BradCrittenden is now known as bac [15:01] jujugui: wireframe at http://ubuntuone.com/1eafCNZEU70nFW6mtZBipQ [15:01] hatch, yep [15:02] Makyo: guichat [15:02] plz [15:02] gary_poster: can do [15:02] thanks hatch. ping me when you are free. 10 min or less should do it, I hope [15:04] benji: thank you [15:04] hey sinzui. I will be out on Monday next week so I want to move the browser sync to Tuesday at same time. That conflicts with your call with jc. do you mind trying to rearrange that? [15:04] my pleasure [15:05] gary_poster, jcsackett and I can talk any time [15:05] thank you sinzui [15:05] hey jcsackett do you want to talk now? [15:05] (and jcsackett ;-) ) [15:05] sinzui: sure. we can decide when our new talk time should be. :-P [15:07] sinzui: sent you an invite, but it timed out. [15:07] gary_poster: so am I giving the "tutorial" to everyone or just bac? [15:08] * sinzui tries again [15:08] jcsackett, I found your invite [15:08] * sinzui wonders why phone and browser didn't make a noise [15:09] sinzui: i think you went there just as i got your invite. :-p [15:09] hatch, at 11:30, we will have an inspector kickoff, touching on both the wireframes and the engineering. Unless you think you can do the full tutorial in 10 minutes on the group call, I'd give the tutorial to bac, and give an overview to everyone else. [15:09] hatch, sorry, 1630 UTC :-P [15:09] * jcsackett is astonished at how many ways this can go wrong. [15:10] jcsackett, I have left all hangouts. You make/find one and I will join [15:11] isn't it 15:10 utc right now? [15:11] ok bac join me in guichat? [15:12] hatch yes 1512, so I meant 1530. Sorry, thought I was UTC+5 [15:13] ok good - no coffee makes head not my work to goodly [15:13] :-) [15:13] another processexecutionerror on CI [15:15] hatch: there [15:18] CI passed this time :-/ [15:20] hatch do we need to talk before meeting or are you goon on goals for your side? [15:20] good :-) [15:20] sinzui, abentley, jcsackett, rick_h, could one of you have a look at this MP: https://code.launchpad.net/~adeuring/charmworld/1192544-use-charm-class-1/+merge/171332 ? [15:20] gary_poster: nope alls good just chatting with bac [15:20] cool thanks hatch [15:20] thank you adeuring [15:29] jujgui, guichat in 1 [15:29] Luca___, you too if you can :-) [15:29] gary_poster: cheers coming [15:31] benji ping [15:31] it helps to hit "join" === jcsackett_ is now known as jcsackett [16:45] jujugui, could someone make another high prioriry card (maybe for today?) to create the skeleton of the left hand panel? [16:45] priority [16:45] * gary_poster has to go to lunch [16:46] Left hand panel? [16:46] * Makyo makes card, will fill in detail. [16:52] orangesquad hatch Makyo and company, can I get a pair of reviews on https://codereview.appspot.com/10554044 please? Ignore the updated .json test data file. [16:52] rick_h, sure [16:52] thanks Makyo [16:59] rick_h: on it [16:59] and you bet I'll ignore that file :P [16:59] hatch: :P you have to go through it line by line! [16:59] lol [16:59] I don't think I've typed a single line of code today [16:59] meetings meetings meetings [17:31] hatch: :P curse you reading the docs. I've always like expected, actual...but I suppose the docs do say it the other way around. [17:31] rick_h: oh I agree - I wrote so many tests with expected, actual until I had a failing test and was like 'wtf?' [17:32] thenagain node.js also says you should put commas first....................... [17:32] ................ [17:32] .......................... [17:32] yea, I honestly don't read and look straight at the two bits of info. I just have my brain wired for the other way [17:32] hah, I actually trained myself to do that when I did PHP [17:32] I kind of did get around to liking it. [17:32] except in python where I much prefer just leaving a stinking trailing comman and carry on [17:32] haha [17:34] I tried comma first but I found it just moves the problem [17:34] at least the problem is at the front of the line and more visible though [17:34] true true [17:34] maybe I don't really notice it anymore because I never leave a trailing comma, and use jshint [17:35] just like adding a semi-colon it's muscle memory :_ [17:35] We need a new metric for things. TimeToFubarIdentification-ness [17:35] :) [17:36] I wanted to buy a book yesterday but it was only available on kindle....I don't have a kindle....since when did BOOKS get locked behind closed walls :/ [17:37] oh you want to read.....NO!!!! buy our hardware! [17:37] hah, get a kindle. The nook is shutting down :P [17:37] * rick_h hates the idea in principal but loves his kindle too darn much to deal with anything else. [17:37] I read books on dead trees [17:37] it's a clean renewable resource [17:38] hah, e-ink doesn't need re-planting :P [17:38] books don't require lead circuit boards and lithium batteries :P [17:39] lol I really have no idea which is worse [17:40] yea, I just love the size/space of it all. The paperwhite is pretty darn awesome withthe light now as well. Camping best friend. [17:40] yeah we use kobo here and it's actually really nice to read on [17:41] but I don't think I'll ever truly switch away from the experience of a book [17:41] heh, /me used to say that same thing [17:41] yeah but I might be more stubborn than you [17:41] :P [17:41] hah! you've met me [17:42] hatch: Makyo thanks for the reviews! [17:43] lol [17:43] sinzui: In CharmTestCase, what does {'options': {'mode': 'fast'}} mean? [17:43] np [17:43] jcsackett: escapes! [17:43] hmm [17:44] sinzui: Normally, the value of 'mode' is a dict. [17:44] abentley, change {'mode': 'fast'} to {'foo': 'bar'} [17:45] sinzui: No, the problem is the contents. I don't think a string is a valid type for 'fast' (or 'foo') to have as its value. [17:45] abentley, I used an ambiguous example of an "opinionated" charm that allows the user to state they want a fast or stable or cleaver or dumb, or fired [17:45] abentley, since I didn't know when you asked (fried/dumb) I think key: value might better text [17:46] sinzui: Can I change it to {'key': {'default': 'value', 'type': 'string'}} ? [17:47] abentley, +1 [17:48] Makyo: do you have a second to take a look at my branch? lp:~hatch/juju-gui/ghost-inspector [17:48] hatch, for anything in particular? [17:49] views/ghost-inspector.js:237 [17:49] guessing that's where the issue is coming from....maybe? [17:49] Can you take a step back and explain, please? [17:49] this is the relationship thing [17:49] Oh, okay. [17:49] just to see if you can see any obvious reason why this branch exposes that error [17:49] but the original doesn't [17:50] hatch Makyo don't forget that "rip the menu out" might be a reasonable solution for now [17:50] yep for sure - I'm more concerned that I missed something 'else' which is causing this [17:51] cool [17:51] hatch, this looks fine. [17:51] rick_h: you didn't answer me about the charm-token widgets....I'm just wondering if there will be 100's of those tokens floating around eventually [17:52] hatch, will poke around in more relevant code, though. [17:52] hatch: sorry, I removed them. [17:52] hatch: good catch since they weren't in a container that auto cleaned them as per usual [17:52] great - thanks :) [17:57] CI is down unable to deploy charm [17:57] what did you do now rick_h :P [17:59] I was jk rick_h another one is running :) [17:59] hatch: ok, good then :P [18:03] hatch, I can reproduce this in trunk. I think we should remove the menus for now (probably in a quick separate branch), and re-open the relevant bug in case we bring menus back. [18:04] ohh ok I can't repro in trunk so that's a little comforting I suppose [18:04] ok I'll clean up this branch and get it landed [18:05] hatch, sounds good. I'll get to the bug/cards [18:05] thanks for putting in the time! [18:17] so the best way I have found to diff from trunk with bzr is to merge trunk in and then diff from trunk with trunk as old and the current branch as new [18:18] it doesn't appear to keep track of the revno it was branched at....at least that I can find [18:23] didn't teknico land a branch which cached the charm meta data for tests? [18:23] I am still seeing a lot of GET requests in the console [18:24] it's entirely possible I was mistaken [19:01] gary_poster: i'll reimburse the first round if you go and wear your bzr t-shirt: https://github.com/blog/1540-raleigh-nc-drinkup [19:02] bac, heh :-) [19:02] offer not good for bcsaller or hazmat [19:03] something I said? [19:04] bcsaller: nah, y'all would run up the tab! :) [19:05] heh [19:08] aww boo [19:08] no flights to get me there in time [19:08] :) [19:35] hatch: re. "The charm token instances should be destroyed and removed at the end of the tests": how does one do that? I can't find an example of that in the other CharmToken tests. [19:36] benji: create a top level var in your describe closure [19:36] assign the charm token to that [19:36] call destroy() on that var in afterEach [19:37] hatch: "destroy()" is what I was after, thanks. What does the "and removed" part reference? [19:37] bac but when else am i gonna wear my bzr t-shirt :-) [19:38] benji: I think I was referring to the container content [19:40] good point hazmat [19:46] jujugui: if you add your flight arrival and departure *times* it'll help with cab sharing. https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AtC9etoysSQldDZvazM5T3F2NmFOWUJYcHVfdUhnN1E#gid=8 [19:46] +1 [19:46] bac, Ah, good point. [19:46] hatch: re. https://codereview.appspot.com/10500044/diff/5001/test/test_charm_token_drag_and_drop.js?column_width=80; specifically "Should not be required if you call render() as mentioned below.": The faux _makeDraggable is there to collect data for assertions, so I don't understand the "Should not be required" part. [19:46] I thought Gary was picking us all up in his van (assuming he has a van because kids) :D [19:46] :) [19:47] yeah, we have a van :-) [19:47] soon minivans will be a thing of the past as each child will have a google-driven smart car. [19:48] benji: ahh sorry I missread that code [19:48] my bad [19:48] ok [19:48] what's flight WN? [19:49] never seen that one before [19:49] It's Charlie Sheen's airline: "WINNING" [19:50] lol [19:56] jujugui please two people review bcsaller's branch [19:56] I'll take one [19:56] thanks [19:56] * benji takes one. [19:56] thanks [19:57] bcsaller: is there a way to QA this? [19:57] hatch: the export hotkey [19:57] or app.db.exportDeployer() for the raw object [19:57] we are exporting in yaml now.....interesting.... [19:58] thats the deployer format [19:58] yaml doesn't travel over the wire very well :) [19:58] hatch: http://bazaar.launchpad.net/~hazmat/juju-deployer/refactor/view/head:/README [19:58] hatch: a blob is a blob on the wire [19:58] but this isn't about that [19:59] yeah I meant as a string [20:01] yaml seems like an odd format for this no? I can't see anyone ever typing this out [20:02] and with exports they don't have to ;) [20:02] at least I guess we don't have to write a yaml parser https://github.com/nodeca/js-yaml :) [20:03] already in use [20:03] oh we use that here already? [20:03] we used the parser for config options [20:03] this uses the serializer [20:04] oh look at that [20:04] heh [20:04] haden't gotten there in the review yet [20:05] I still think whitespace significant configuration files are a bad idea everywhere :P [20:05] bcsaller, fwiw, that's a stable branch atm, dev's on a different one [20:06] hazmat: I expect for what I can export its about the same [20:06] if not easy to fix [20:06] bcsaller, yeah [20:07] bcsaller, working on diff of env to config atm, might circle back to export within deployer as well, but gui export is still key [20:08] LGTM'd [20:24] the ghost config prototype is up for review [20:24] https://codereview.appspot.com/10565043/ [20:25] now im going to grab some lunch [20:37] jujgui please review branch from Jeff above ^^^ [20:37] bcsaller: review sent [20:37] jujugui [20:37] benji: thanks [20:38] i will [20:38] gary_poster, hatch on it. [20:38] thank you both [20:40] thanks guys [20:41] who wants to pitch in to buy lgtm.com and write a code review tool? lol [20:43] oh c'mon we'd make thousands....:P [20:52] it's too bad all four letter domains were snapped up years ago, that would be a good one [20:54] well, it looks like a domain squatter has it, so there is hope yet [20:55] yeah - I've bought some from squatters in the past - some hold out for the big money but some have taken $1000 [20:56] not bad [20:56] I can't remember what one was....it was some obscure acronym for a client and the squatter wanted $10k [20:57] just kind of laughed that off [20:57] i used to work for a small consulting firm with a three letter domain name. we joked (not inaccurately) that it was their most valuable asset. [20:57] lol! [20:58] they went from 25 to 2 and kept about the same revenue [20:58] benji: so you couldn't just use container.one('a') ? I actually tested that locally and it was almost identical drag target [20:58] hatch: nope, the charm icon image wouldn't participate in the dragging if I did it that way. [20:59] that's interesting because it worked here....I suppose another difference between chrome and chromium [20:59] This was on chromium. [20:59] yeah I'm on chrome in osx [21:00] That might be it. I made sure Firefox worked on the code as-is, but I didn't try it with just the container.one('a'), that would be interesting. (but not interesting enough for me to actually try it) [21:01] jujugui: I could use a second review on https://codereview.appspot.com/10500044; thanks! [21:01] hah yeah that's fine - was just looking at ways to improve that code because it's kind of ugly (not your fault) [21:01] benji: i'll do it [21:01] thanks [21:01] sorry, benji, I would have advertised it if I saw, but very happy you did so :-) [21:01] benji: I can relook later tonight [21:02] or bac can go then [21:03] benji: actually, i'd better not take it until i finish jeff's [21:03] hatch, code lgtm, QAing. [21:05] bcsaller, thank you for landing the deployer-format export. awesome. (A) is there anything arosales and jcastro should know in order to try it out? In particular, do you know what deployer branch they should use to import what's exported? Otherwise I guess we just need to tell them to use lp:juju-gui as juju-gui-source in the charm when they try it out. (B) Before we make a release, should we disable import for [21:05] now (or did you already)? [21:06] benji: what does the passing of the container get us that passing a boundingBox node on init of the charm doesn't? [21:06] and look, deploying failed in canonistack again! exciting. [21:06] rick_h: ooh, that's a good point; that's much nicer [21:06] I didn't put the total plumbing picture together until you mentioned it [21:06] benji: content box is created inside of boundingBox which you should be able to pass in on new CharmToken({boundBox: ...}) [21:07] benji: ah, ok cool [21:07] benji: but yea, that's why doing a .set(contentBox) failed. It's auto done based on boundingBox [21:07] I would still like to know why I couldn't .set('contentBox', xxx) [21:07] benji: ^^ [21:07] oh [21:07] gary_poster: import of the JSON format is still supported, I left it on. Its currently bound to the old 'export hotkey' so nothing special is needed to test. The subset of the deployer format should work with recent versions [21:08] rick_h: that makes sense, but still, why couldn't I set it? [21:08] (not that I should set it, I now realized) [21:08] s/realized/realize/ [21:09] benji: http://yuilibrary.com/yui/docs/api/files/widget_js_Widget.js.html#l199 it's a writeOne ATTR [21:09] benji: it's set as writeonce [21:09] annnnd rick_h beat me to it [21:09] with a link boom! [21:09] lol u powned me [21:09] and setting a write-once attribute doesn't raise an exception? that seems like a sadness maker [21:09] heh [21:09] ok, let me get the boy a snack and I'll try to finish the review. [21:09] bcsaller, cool. JSON format is not what we export anymore though, yeah? so it is temporarily a feature that is unlikely to do anything but disappoint people? "The subset of the deployer format should work with recent versions " even with charm store links? [21:09] benji: nope it's designed to fail silently [21:10] imho I disagree with their implementation [21:10] but it's not changing....ever :) [21:10] heh [21:10] gary_poster: no, not any more, though it still works for the DND case cross browser session in sandbox [21:10] I knew I was doomed to be sad forever. [21:10] woot export landing a day early :-) [21:10] it's ok, I may eventually convince everyone to switch to Dart at which point I think you'll be marginally happier [21:10] than you bcsaller :-) [21:11] that was a joke, I'm not actually going to push Dart.....or am I... [21:11] * benji switches to Dart. [21:11] bcsaller, ok. I guess it is not discoverable so I am ok with it. [21:11] victory! [21:11] lol [21:12] gary_poster: a one line comment around the importexport module would remove the UI for the other formats, but as you say not very discoverable [21:12] arosales: let me know if you hit any issues [21:12] I mean,thank you bcsaller :-) [21:12] arosales, start gui charm and juju set juju-gui-source=lp:juju-gui and you will have trunk [21:13] it will take just a bit longer to start up that way [21:13] gary_poster, you read my mind [21:13] :-) [21:13] so do we still need deployer to import? [21:13] yes [21:13] or is both export and importing handled via the gui [21:14] hazmat, I take it that yes is for the deployer to import [21:14] well.. gui could import, but i don't know that its going to ape the delays in the original deployer [21:14] hazmat, no worries [21:14] import was completely out of scope for the gui atm [21:15] just getting export to work with deployer on a live environment was a super plus the gui team made happen :-) [21:15] benji: lgtm then with the boundingBox note and the additional note on the node.remove(true) [21:15] hazmat, arosales, we still plan to run the deployer as a library for import (and maybe export!), but not in time for July 1 :-) [21:16] rick_h: thanks [21:16] ugh, someone shoot canonistack [21:16] gary_poster, ok, and thanks again for making the gui export work for live environments and with deployer by july 1st. [21:17] bcsaller, I owe you a beer [21:17] heh [21:18] welcome arosales. the last thing you'll want us to deliver this week is a GUI release, so your competitors get the new feature automatically. after you and jcastro verify that everything is working, and work through any kinks if necessary, then we can make a release [21:18] * benji fires an RPG at canonistack. [21:18] :-) [21:18] gary_poster: did luca say that we DID want the ghost inspector locked to the side or DID NOT? I thought he said to keep it floating? [21:18] * benji watches as canonistack is unphased. [21:18] bcsaller, so the old import works with the new export? [21:18] ^ bcsaller re your comment [21:18] gary_poster is it live on uistage? [21:18] COME WITH ME IF YOU WANT TO LIVE! [21:19] gary_poster, ok. we'll get on testing and report feedback [21:19] * hazmat catches up with benji [21:19] LOL [21:19] hatch, locked [21:19] * hazmat and gets swallowed up a dartvm exception [21:19] :-) [21:19] alright thanks [21:19] jcastro, quite possibly. will ive it a whirl, 1 sec [21:20] hazmat: the old JSON format can still be imported via the fakebackend or the rapi python branches. I don't handle import here, though I could if we want to put more time into this. My understanding is that this isn't the long term solution so I didn't bother [21:21] bcsaller, understood, just wanted to understand your earlier comment re [21:21] jcastro, arosales, live on http://uistage.jujucharms.com:8086/ [21:22] nice [21:22] man, I'm sorry, I'm just not used to things landing early [21:22] I am completely flat footed right now [21:22] jcastro, note the real nice thing here is to be able to export from a live environment not just from a sandbox [21:23] hazmat, and deployer works with this file? [21:23] arosales, not quite, either tomorrow or late tonight, i side-tracked on a feature [21:23] namely --diff option to see the delta between an env and the config file [21:24] hazmat, ok and by Friday is ok too [21:24] twas sitting around half-done in my working copy [21:24] we can get all the docs set less that bit [21:24] deployer working with it isn't as important to me as the workflow for people to submit the json [21:24] I will have instructions, etc. by tomorrow EOD [21:29] gary_poster: if we lock the panel to the right does that mean that we only want a single inspector instance open at once? [21:29] so multiple ghosts but every time you click one it changes the open inspector? [21:30] hatch yes [21:31] hatch until we implement the Mark S special version :-) [21:32] ok - I'd like to land this branch and then follow up with that restriction cc bcsaller Makyo [21:33] hatch: a third review [21:34] hatch good by me [21:37] bac: thanks I'll make those fixes and comment where necessary - as far as the interactions are concerned - yes those things need to be fixed - I'll be sure to document them to fix in the followup with the new single inspector restriction [21:51] hatch, sounds good. [22:02] Makyo: bcsaller bac changes made and re-proposed - will be following it up right after to implement the single inspector for multiple views functionality [22:16] the github event was postponed....maybe until we are there? hah [22:26] bcsaller: bac mind checking out my branch again to see if you will lgtm so I can get it landed [22:27] hatch: checking [22:27] thanks [22:29] hatch: I don't think you addressed my biggest concern which is that this more similar than different from the normal inspector panel wrt handling things like config, I'm not sure we need a new extension and separate code. It seems like we can conditionally assemble viewlets when the model is passed in and bound [22:30] so you want to use the controller in views/service.js ? [22:33] hatch: I think they will share more code than not, the template might differ but the logic is mostly the same [22:34] I disagree - I think that the service one will end up moving to be more like my version once we have to start adding in event handlers and various advanced functionality [22:35] hatch: that sounds like agreement to me [22:36] haha [22:36] thats my point though, you've taken it further than the prototype but they both need that code in the end [22:37] ok so you want some type of a shared controller between the two....I agree with that [22:37] the app extension is only the deploy method [22:37] yes, thats what I'm saying, both will need to update configs and constraints [22:38] and a deploy method on the existing controller makes sense to me as well, it would just check pending==true [22:39] hatch: ^ [22:40] *thinking* [22:41] * bcsaller goes to search for food [22:46] bcsaller: correct me if I"m wrong - you would instantiate a 'ServiceInspector' passing in a service and a complex config with all the events, viewlets, methods for the prototype etc etc etc [22:49] IMHO that's going to make that service inspector controller way to complex and huge trying to account for all the various methods each will need [22:49] this needs modularity so that we can instantiate simpler objects for testing and reading [22:51] hatch: if the viewlets had the methods again they would be that, no? [22:51] then they are views :) [22:52] wouldn't be the end of the world [22:52] they then need reference to the db, env etc [22:53] or just to the controller [22:53] brb [22:53] then the viewlet would need access to the controller [22:53] sure [22:55] back, sorry, had to get the door [22:55] np [22:56] ok how about this [22:56] I agree that we want more code sharing, I'm happy to talk about arrangements of code that get us there, if you'd rather chat about it we can do that too [22:56] yeah sure lets hop into guichat [22:56] I'm guessing we are close [23:01] Morning [23:24] morning huwshimi [23:28] OSCON looks like a conference I'd like to go to but dayyyyymnnnn it's expensive [23:31] export env working on aws for a few different bundles (I think that is what we are calling them now). I'll check hp cloud this evening [23:35] yeah I got way outvoted on that one [23:35] :) [23:36] latest gui is looking good to btw [23:37] bcsaller: your details are missing from the travel spreadsheet [23:38] hatch: ha, I'll see about fixing that [23:39] unless we can convince gary to drive us at 5am it's nice to know when others flights leave :D