[00:02] jujugui looking for a quick review on https://github.com/juju/juju-gui/pull/138 to fix the ie test failures === hatch___ is now known as hatch [01:37] ls [01:45] grrrr [01:50] :) [01:55] this is an annoying damn thing [01:55] and vmware fusion is irritating, osx terminal is irritating [01:57] rick_h_ get iterm [01:57] yea? is it the thing to get [01:57] it's the best terminal app out there by far [01:57] iterm2 actually [01:58] k [01:58] http://www.iterm2.com/ [01:58] and I haven't used fusion before....but I think that's what bac uses [01:58] irc client...Textual (it's $2.50 or something in the app store) [01:59] PCKeyboard Hack (for remapping the caps lock) and KeyRemap4MacBook for key remappings [01:59] caps lock moved well enough [02:00] heh, irc is ssh to my server and irssi [02:00] I'm there :) [02:00] fusion says it's 'sharing' the drive but it's empty on the guest [02:00] BetterTouchTool for better gesture support [02:00] so :P lying software [02:00] haha [02:01] Caffeine so it doesn't go to sleep all the damn time [02:01] and umm [02:01] I think that's all the suggestions I have [02:01] k, thanks [02:02] Skitch for screenshots and sharing (Evernote companion app) [02:02] oh and go and get Xcode started downloading [02:02] you'll need it for things like `make` [02:02] yea, got xcode [02:04] oh and you'll probably want open pgp [02:04] but maybe not if you don't add email to osx [02:05] I use Postbox for email because it has pgp support as a plugin but it's $10 so if you don't plan on using osx a whole lot then might as well just stick with email in Ubuntu [02:05] yea, mutt cli ftw [02:06] eww lol [02:19] woot, finally figured out how to show hidden folders so I could install my fonts [02:19] ohh yeah that [02:19] pita [02:19] sorry I forgot about those things [02:20] there should be an off switch to the 'idiot mode' that they start in lol [02:20] now if I could just figure out how to share folders with this ubuntu instance I could get the gui up and running :/ [02:20] and review/qa your branches [02:20] nfs? [02:20] ohh wait [02:20] use vagrant [02:20] no, not that desperate [02:20] you'll be up and running in no time [02:20] but it blew up on you today [02:20] yeah but that's the first time in months [02:21] just DO NOT run two vm software at the same time...it'll kernel panic and crash :) [02:21] lol [02:22] I did that today haha [02:22] I probably do that once a week lol [02:22] but really the vagrant images are just so easy to use [02:22] hmm, ok might look at it if I can't figure it out I guess [02:23] when I get some free time I'll set up our vagrant images to use nfs [02:24] because the virtualbox fileshare is pretty slow [02:24] but it's good enough for now [02:25] I'm running #137 again to see if it passes CI because it's failure was the intermittent one [02:25] cool yea [02:25] it's nice to have a fix for that [02:25] make sure you've got a card for that [02:27] created friday card [02:28] k [02:46] rick_h_ given up yet and gone with vagrant? :) [02:46] heh, not yet [02:47] did a reboot, gotten the dock cleaned up, fonts better, and colors tweaked down [02:47] now if only I could get this drive share... [02:47] what font did you go with? [02:48] I'm a liberation mono fan myself [02:48] ok, ssh works to the vm so we're in business [02:48] rsync ftw [02:49] interesting...I use source code pro heh [02:49] yea, guy here is promoting that one [02:49] it's a well done font, easy to read [02:49] although sometimes having those serif's would be nice [02:50] meh serif [02:50] but it reads well even without them [02:50] Makyo wrecked me - he educated me why text has serifs [02:50] (don't look it up unless you also want to be wrecked) [02:50] been there done that [02:50] it's for print [02:50] I don't believe in serif for lcd/computer displays [02:51] well no it's so that your eye can move from one character to the other easily across a single line [02:51] right, but look into it. It's intended for a print medium. [02:52] https://github.com/blog/1778-webhooks-level-up [02:52] hmm interesting maybe I'll have to read further into it [02:54] oh quickstart you rock [02:54] * hatch would love it even more if he could provide git branch info for the gui :) [02:54] /juju-ui/version.js [02:55] done [02:55] hah wut? [02:55] http://gui.ip.address/juju-ui/version.js [02:55] that's the git hash info [02:55] and the git branch info is from the config [02:55] juju get juju-gui [02:56] `juju quickstart -e amazon -gui="github.com/hatched mybranch"` [02:56] is what I mean [02:56] oic [02:56] just save me a step in the future is all [09:31] frankban, ping [09:32] hey hazmat [09:33] frankban, two items.. first via time machine.. do you remember the openstack dashboard work you did? [09:33] that integrated juju gui [09:34] hazmat: yes I do [09:34] frankban, do you happen to have a screenshot of it? [09:35] * hazmat is digging through email from late 2012 [09:36] frankban, the other item, was the unit-errors branch.. i didn't really understand why the separate feedback mechanism... and the whole watcher handler functions returning callbacks on env seems a bit strange. [09:36] hazmat: looking, but I don't think I have a screenshot, code is here: https://bazaar.launchpad.net/~juju-gui-peeps/juju-gui/horizon/files [09:38] frankban, thanks [09:39] * hazmat looks for 2fa dev [09:39] hazmat: the watcher/API layer is still generic. it just allows for injecting semantic. We need a way to react to unit errors in different ways (e.g. just log them, or raise an exception as soon as a unit is found in an error state (which is precisely the current default behavior). That's just a functional approach (pass a function that is called on errors), allowing us to customize the watcher behavior: the importe [09:39] r layer seems still decoupled from the API to me, it just provides some logic [09:42] frankban, how is that different then the feedback mechanism on deployments? [09:42] which was put in place for this exact same reason (handle errors vs warnings differently) [09:43] depending on usage mode [09:47] hazmat: ISTM the feedback collects messages, errors and warnings, and then code can use the feedback to react to collected messages. here we have a slightly different use cases. we have unit errors, and we need to customize how those are handled. e.g. the default deployer behavior is to exit as soon as possible if a unit is in error, without waiting for all the other entities to be started. in that case the fact we [09:47] are logging errors is incidental, the goal is to exit the application asap. from he guiserver perspective, we instead want to log errors but still keep on watching the other units until they are started or in error. [09:51] hazmat: so we need a way to tell to the watcher: please keep watching, do not raise UnitErrors, just notify them to me an d I'll handle them in the way I like. in this scenario, the watcher is a middleware: it has access to the watch, and it is provided on_error logic (as a function) from the caller [09:53] frankban, that aspect is fine. [09:55] where things go strange to me is the defaults funcs in the watchers as callback generators on env, instead of just passing a feedback style object.. the env isn't really a place to handle that logic imo, its for env manipulation not policy. i'd like to keep the behavioral customization of handling feedback policy on the deployment. [10:02] hazmat: yes that's unfortunate, but it seemed required to me given the watcher data differences between go and python juju implementations. the log callbacks are closures storing a reference to the env because of that. even before the change that logging code was in the env.wait_for_units for the same reason IMHO. if we want to push that forward, we can just expose a units2errors method on the environment and have [10:02] the callback itself call logger.error on the messages returned by that method. it is doable, I ended up with just using the logger stored in the env for practicality. as I said, that code was already on the env, I just moved it in a separate method [10:04] frankban, the python env impl is going to be deleted, not supporting it would have been fine. [10:05] frankban, fair enough [10:05] frankban, is the usage code here juju-gui/server/guiserver/bundles ? [10:06] hazmat: cool, that would simplify things. we can simplify the callbacks once py support is removed [10:06] hazmat: yes. I need to add a small change to that code given the introduction of deployer.guiserver.get_default_guiserver_options [10:08] hazmat: bundles/base.py is where the deployer is imported and used [10:09] hmm.. yeah.. i don't see any feedback customization there [10:10] its still expecting errors [10:11] hazmat: deployer/guiserver.py customizes Deployment._handle_feedback [10:12] frankban, ic that but its still based on error passing which is fine, the base usage is guarding against impl [10:15] hazmat: no juju-horizon screenshot here, sorry [10:17] frankban, no worries. thanks for looking. still thinking through the branch and looking for 2fa [11:49] frankban, i guess merge as is is okay, would you mind fixing up the merge errors to trunk, the alternative i can find is adding config options to the watch class ie ignore_states, error_states etc, but i don't see anything in the mp that would cause issues for the gui on a refactor later. [11:51] hazmat: great, I'll merge trunk and push then [11:51] frankban, cool, thanks [11:56] hazmat: thank you for the review! are you in europe? [11:56] frankban, no.. just bad sleep schedule post capetown [11:56] hazmat: oh :-/ [11:57] well today actually it was toddler wake up call at 4am. it happens. [12:01] babby hours! :) [12:34] hazmat: branch pushed [12:36] rick_h_: http://jujugui.wordpress.com/2014/02/20/juju-quickstart-1-1-0-released/ [12:37] frankban: awesome thanks! Looks like it auto hit the twitter account as well [12:37] cool [12:45] frankban, merged and released 0.3.2 [12:46] hazmat: awesome! thanks [12:48] weird that launchpad does not show that [12:49] frankban, i push to pypi [12:50] hazmat: I know, I mean, https://code.launchpad.net/~juju-deployers/juju-deployer/trunk does not show the revision, and https://code.launchpad.net/~frankban/juju-deployer/unit-errors/+merge/206967 does not consider it merged... [12:51] frankban, oh.. i hadn't pushed master.. the rel is out on pypi though [12:51] hazmat: yeah I see, thanks [12:52] bac: morning, I'll be working on the charm to include deployer 0.3.2 and integrate guiserver changes. when you have time, could you please take a look at how to update juju-quickstart in trusty? [12:53] frankban: sure [12:53] thanks [12:53] frankban: so both j-deployer changes are merged? [12:53] bac: yes [12:53] frankban: excellent. no forky [12:53] bac: moved the cards, yeah exactly [12:54] ty [12:54] frankban: for clarification, the card about updating in trusty is only relevant for post-freeze changes, right? [12:54] post-freeze / post-release [12:55] bac: not sure, rick_h_ ? ^^^ [12:55] bac: well james handled getting us submitted into universe. I'm not sure how we make sure that updates [12:55] freeze is today, so we'd like to get this new 1.1 release as the frozen trusty version [12:55] bac: so maybe check with james page on if we need to do anything [12:56] bac: and then post-freeze I'd assume we'd fall under the juju ppa and keep updates in there unless they're security related. [12:56] rick_h_: will do. but my understanding of the card was to document what we do after release. [12:57] sure we can make PPA changes but other non-security changes could potentially be submitted [12:57] bac: ah ok. That sounds cool, we've also got the initial task of making sure we're in the release I guess [12:57] here is the Stable Release Update (SRU) explanation, in case you're interested. i'll summarize its affect on us somewhere: https://wiki.ubuntu.com/StableReleaseUpdates [12:57] bac: and jamespage was working on trying to shepard us into main vs universe [12:57] * rick_h_ loads [12:58] rick_h_: ok [12:59] bac: thanks for the link. This will definitely be useful over the 14.04 support cycle. [12:59] rick_h_: getting an SRU is, rightfully, a painful and frightening experience. let's try to avoid it. [13:00] bac: definitely, I don't think we've got anything that would jump out as a big security issue but that's about all I can think of atm. [13:11] only sudo usage. :-P [13:12] gary_poster: as an attack vector? [13:12] yeah [13:13] good point. And we shouldn't need it for trusty. Maybe it's worth a freeze exception to be able to go back and remove it once 1.18 hits for 14.04 [13:13] 1.18 seems required for 14.04 [13:13] yea [13:13] they were saying within 2ish weeks [13:14] if that's true we'd have the ability to drop sudo usage from quickstart for the lifetime there. [13:14] * rick_h_ notes to look into filing a freeze exception [13:14] +1 [13:14] frankban: up for 1-1 today? [13:15] rick_h_: sure [13:16] frankban: https://plus.google.com/hangouts/_/canonical.com/rick [13:25] * frankban lunches [14:00] rick_h_: there is a fly in the lower-case search ointment: the search corpus contents are returned via the charmworld API so if we lower case, e.g., the name of the charm then the search results in the GUI will include the improperly cased charm name [14:01] benji: ummm...suckiness [14:01] another field, I guess? [14:02] yea, we're back at the multi field setup [14:02] we /could/ look up each charm in the search results and substitute in the data in the mongo db [14:02] benji: but could we add two fields to ES, raw_name and name or something? [14:03] or the other way around I guess. name and indexed_name [14:03] yeah, we considered that at the outset but it looked a bit like the internal structure of charm world really wanted a one-to-one mapping from charm/bundle data to ES field. Not that it would be impossible to do, it may just take more refactoring than we initially thought [14:04] right, ok. So we can either expand that, or go back to ES having the multiple indexes on a single field you mentioned yesterday? [14:04] benji: any idea on which path seems most sane at this point? [14:04] benji: and do you think either are landable before the EOW and you leave next week? [14:05] (and MWC starts on monday) [14:06] benji: we can chat in hangout and do 1-1 when you've got a sec? [14:06] rick_h_: I am leaning slightly toward the {type: "multi_field"} appraoch right now mainly because it is the way the ES people suggest doing this (this being case insensitive search on otherwise unanylized fields) [14:07] benji: rgr, that sounds reasonable to me [14:07] rick_h_: I can hang out when you're ready [14:07] benji: https://plus.google.com/hangouts/_/canonical.com/rick [14:27] hatch: let me know when you get in and we can go over the qa on your branch [14:27] hatch: I've got the running env up and can get you access to peek at it [14:34] rick_h_ yeah please do, I can't reproduce your issue [14:37] jujugui a small hack I put together last weekend http://fromanegg.com/post/77277923553/juju-gui-google-hangouts-proof-of-concept [14:38] very cool hatch [14:38] :) thanks [14:38] I'm going to email it to canonical tech see if anyone else has any input on it [14:39] hatch: looks very cool === BradCrittenden is now known as bac [14:41] thanks bac [14:41] hatch: great, so, can you use the GUI/ change the environment from inside the hangout? [14:41] frankban you bet, it's a fully functional gui [14:41] hatch: cool [14:42] I had thought of something similar, but the other way around, instead of putting the GUI in hangouts I though of using twilio browser client to do in-app voice chat between users [14:44] benji cool, my first attempt was to integrate a Hangout into the GUI but their api doesn't allow that (at least yet) [14:44] interesting [14:44] integrated twilio would be cool though, I didn't know hey had a peer to peer api, I thought it was only phone [14:45] hatch: you might also be interested in https://togetherjs.com/ [14:46] yeah, they have iOS, Android, and browser integration now; pretty cheap too, 0.25 cents per minute [14:46] ahh cool [14:46] yeah I've seen togetherjs - it's kind of reproducing what we are doing with the gui heh [14:48] a bit, yeah; I was specifically thinking about the per-user mouse cursors. It would be very nice to be able to voice chat (integrated or not) and be able to see the other person's cursor [14:50] yeah that would be very cool [14:51] guihelp: is anyone available for reviewing/QAing https://codereview.appspot.com/63570048 (gui charm)? [14:56] bac: when doing the initial review of your branch yesterday I noticed a regex tweak you could do, but it is proably too late now, so for future reference: [14:56] the regex was '^\s*(bundle|charm)[s]{0,1}:(.*)'; the "[s]{0,1}" part could be replaced by "s?" [14:57] benji: thanks. [14:57] benji: i've got bigger fish to gore [14:57] heh [15:02] rick_h_ found the bug thanks - I'll have to also check in IE because it's a MIME issue (again) [15:02] hatch: rgr, thanks! [15:02] i was just complaining about the internet dropping out a lot here. my karmic reward? the water has gone out. [15:02] lol [15:03] I'd much rather have the internet go out than the water :) [15:03] bac: time to move? You know we could melt you enough snow to fill your water pot here [15:04] rick_h_: ship some down here. it'll melt on its own. [15:10] bac: let me know when you've got 1-1 time if your interwebs work [15:14] rick_h_ do you still have that env up? [15:14] hatch: yep [15:15] could you put a debugger in app.js:_determineFileType() and let me know what the dataTransfer.types object is? [15:15] plz and thanks [15:15] second, otp [15:15] every time I see that I think "On The Potty" :D [15:16] hey, that's still a good excuse [15:16] lol true, but in that case you should probably be concentrating on something other than IRC lol [15:20] rick_h_ Ie10 bug https://bugs.launchpad.net/juju-gui/+bug/1282633 prioritize as you will [15:20] <_mup_> Bug #1282633: Clicking service name on icon does not open inspector in IE19

[15:21] rick_h_: free now. you got a hangout space? [15:22] bac: yea, on the calendar link. Did you get the invite? [15:22] https://plus.google.com/hangouts/_/canonical.com/rick bac [15:22] rick_h_: no [15:36] http://python.org has a new look and an interactive shell, seems cool [15:36] kewl [15:36] every browser has an integrated shell for JS :P [15:38] lol, well... not all browsers IIRC [15:41] haha ok [15:49] rick_h_: re the "Improve jenv login message (subdivide; see description)" in the maintenance lane: isn't that already done? [15:49] frankban: so it notes a few parts. One of which is a change to juju-core. Was that completed already? [15:50] jujugui call in 10 [15:50] rick_h_: yes the fix is in core trunk [15:51] frankban: ok, yea if everying in the notes there then please move that off to releaseable. [15:51] rick_h_: ok cool I'll move the card [15:59] jujugui call in 2 [16:31] * hatch pokes rick_h_ for that object :) [16:33] hatch: redeploying the gui on the updated branch. Will be a sec [16:33] hatch: you pushed your update right? [16:33] nope [16:33] :) [16:33] I just need to know what it is so I can write the proper test [16:34] like what the chrome dev shows as the object [16:34] oh, well right now it's deploying the gui and about to get a juju set to your branch again [16:34] oh ok :) [16:34] right, heh will be a few min [16:47] biab: lunch and such. have a 1 PM call so will be back by then [17:01] hatch: what am I looking for? [17:01] rick_h_ could you put a debugger in app.js:_determineFileType() and let me know what the dataTransfer.types object is? [17:02] ["Files"] [17:02] perfect [17:02] thanks [17:02] ok, destroying [17:02] wait [17:03] wait [17:03] wait [17:03] oh...not [17:03] :) [17:03] okie [17:03] ok if it was ["Files"] then it should work... [17:03] what about... [17:03] dataTransfer.items [17:04] DataTransferItemList {0: DataTransferItem, length: 1, remove: function, clear: function, add: function} [17:04] kind: "file" [17:04] type: "application/zip" [17:04] hmm odd [17:04] it should definitely work then [17:04] working now [17:04] but this is on the apple :/ [17:04] doh [17:04] lol! [17:05] let me go back to my desktop [17:05] :D [17:06] bah, trying to sneak lunch in by working from the kitchen counter :) [17:06] haha sorry [17:07] dataTransfer.types [17:07] ["Files"] [17:07] DataTransferItemList {0: DataTransferItem, length: 1, remove: function, clear: function, add: function} [17:07] :/ [17:07] but it doesn't work? [17:07] kind: "file" [17:07] type: "application/zip" [17:07] right, it download [17:07] downloads [17:07] ok umm [17:08] this is linux on chrome-dev [17:08] Resource interpreted as Document but transferred with MIME type application/zip: "file:///home/rharding/Downloads/ghost-charm-master/ghost.zip". [17:08] in the console [17:08] can you put a debugger in showInspectorDropNotification() and see if that method gets called? [17:09] yes, it's hit [17:10] ok and one more [17:10] and completes successfully [17:10] though I don't see the mask [17:10] you won't, it's transparent [17:11] appDragOverHandler() fileType is 'zip' [17:11] can you put a debugger in the callback in _attachInspectorDropMaskEvents to see if the drop event is fired [17:11] loading [17:13] no, the drop event is not hit [17:13] it's a race there isn't it? to create the mask, watch for drop, while the user is dropping? [17:14] hatch: want a hangout with screenshare to help? [17:14] yeah sure [17:14] if you're done lunch [17:14] heh, for wimps [17:14] lol [17:15] https://plus.google.com/hangouts/_/7ecpj3q3mtp6andr7ra00j83es?hl=en [17:15] rick_h_ ^ [17:28] you left me :( [17:28] lol [17:28] heh, hangouts crashed hard [17:28] I'll fire up a vm with stable and see what I can do [17:28] now when I go back it says to install the plugin [17:28] hatch: cool thanks [17:28] yeah it does that sometimes when doing screenshares in Ubuntu [17:55] bac: email inbound if you get a few min to look through. [17:55] ok [18:23] hatch: Makyo wasn't there talk about not exporting the Gui when you do an export? [18:24] did we ditch that for some reason? or am I not remembering? [18:24] hmm [18:24] thre was talk [18:25] I can't remember now....I think it was decided that there shold be the option [18:25] should* [18:25] it's come up today and I'm trying to think if there's a reason not to. The one thing I can see if that if you use quickstart or deployer via cli on a new env you won't have a gui ootb [18:25] though quickstart will [18:26] yea, the option would be best, but is there a good reason to not default to not exporting it? [18:26] if you quickstart deploy you'd get a gui on node 0, otherwise you might already have a gui [18:26] depends if your exporting for a bundle or exporting your environment [18:26] your environment includes the gui [18:26] a bundle likely wouldn't [18:27] right, but even if you export your env is it a pain to not have the gui there? [18:27] in the export itself [18:27] maybe if you have it configured [18:27] * hatch is just being the devils advocate [18:27] definitely, please do [18:27] I'd say it's easier to remove it form a bundle [18:27] than to miss it from a env export [18:28] so the only config I can think of that'd be 'environment' required would be the charmworld url? [18:28] yeah probably right....but it's a lot easyer to remove something form the bundle than have to manually add it back in [18:29] easier even [18:29] man I can't type today [18:30] you may have subordinates on the gui maybe? [18:30] oh hmm, that's interesting [18:30] that would make it extra complex to re-create manually [18:30] the story of jujucharms where the gui is the environment center [18:32] I just feel like the 80/20 rule says 80% of the time leave it out [18:33] well it really depends what they are using the export button for [18:33] I'd almost say it's the other way around [18:33] * rick_h_ goes back to the email [18:33] because it goes back to that it's a lot easier to remove it from a bundle export than to add it back into an environment export [18:34] how so? because you have to know the syntax/charm path? [18:34] hmm, I guess I see. [18:34] because of the potential configurations [18:35] yeah....Iunno, I'm for leaving it in until we get a configuration option [18:36] k, thanks for talking me out of it :) [18:37] I'll check/create a bug. Something that's come up a couple of times now. [18:39] haha :) [18:40] ok back to work now from lunch [18:47] rick_h_: hey, what does http://www.cohesiveft.com/ do? [18:47] rick_h_: is it purely security and networks? [18:47] looking [18:48] rick_h_: thanks, the I'm at an event and the CTO is giving a talk, I'm not really following but wondering if there is some overlap with Cohesive and Juju, for possibly user testing. [18:49] luca__: possibly. It looks like they're layering and wrapping docker containers. [18:49] which juju is a level above docker and bcsaller_ was playing with wrapping docker in juju [18:49] rick_h_: ah [18:49] looks like some software networking bits in their image there [18:50] rick_h_: yeah, I was wondering if I should talk to him possibly for network view user testing [18:50] actually they look like a network tooling company [18:50] looks like they could be a competitor maybe? [18:50] rick_h_: done with the doc. i went ahead and made some small changes in place [18:51] man their website is confusing.... [18:51] hatch: yeah hehe [18:51] rick_h_: looks nice [18:51]