#juju-gui 2012-12-10
<benji___> bcsaller: I had a couple questions about your review of https://codereview.appspot.com/6909046; I put them in comments
<BradCrittenden> gary_poster: ping
<gary_poster> yo, BradCrittenden 
<bac> gary_poster: could you have a look at my review at your leisure?
<gary_poster> sure bac, I'll do it now.
<bac> gary_poster: leave added to c.a.
<gary_poster> bac I just gave you an approve but I meant to wait to approve until after I tried it out
<gary_poster> ok will look bac
<bac> gary_poster: i'll wait
<bac> just let me know when the branch is ok
<gary_poster> ok
<gary_poster> bac, I accepted Dec 19
<bac> ok
<bac> thanks
<benji> I am going to assume that bcsaller is not in this morning and that we can clear up any remaining issues with his review of https://codereview.appspot.com/6909046/ later and land my branch.
<bcsaller>  benji: I'm here, but its fine if you want to land it, nothing would prevent that 
<benji> bcsaller: oh, did you see my message at 13:14 (UTC)
<bcsaller> yeah, just got in, in time for the second message
<bcsaller> benji: the jist was I thought we either needed more detail to track revno's in CHANGES or less and just record the current revno in a single file w/o the need to parse it, but I don't feel strongly 
<benji> to what use would we put the current revno stored in a file?
<bcsaller> benji: to what use is the description? I think they both honor the same intent, to help recover a significant point in time
<bcsaller> oh, the current on
<bcsaller> only
<bcsaller> can't type today
<bcsaller> umm, that would be the only thing that makes it onto the version page
<bcsaller> w/o the need to grep and so on
<benji> the description is so end users can see what (materially) changed between releases
<bcsaller> benji: and I was thinking in that case that being able to pull the associated revno would help in testing vs a particular revision 
<bcsaller> they are tearing down the scaffolding on the building across the street today, its pretty distracting, sorry
<benji> bcsaller: I think tags would be an easier way to handle that; we can accosiate the release version number with a particular revision directly and not have to worry about keeping up with revnos (and the race involved in doing that)
<bcsaller> benji: agreed, if we switch to that its better all around
<benji> cook, I will make a card to "Add instructions on tagging releases to the release procedure"
<benji> s/k/l
<teknico> hi all, I'm trying to make tests run under the production environment, per #1087107
<_mup_> Bug #1087107: Tests should be runnable on the production build of the code <juju-gui:In Progress by teknico> < https://launchpad.net/bugs/1087107 >
<teknico> there are 78 failures, apparently caused by incorrect test setup
<teknico> I need some help from someone who's familiar with the way tests run, and what they need
<bcsaller> w/o knowing any details I suspect that the deps are not being included in the proper order so some modules fail to resolve
<bcsaller> that should show up in the dev console though
<teknico> bcsaller, when I run "make test-prod" there are no errors in the Makefile output, and then none in the node server log
<bcsaller> teknico: no, it would be in the browsers console
<teknico> except for the usual 404 on favicon.ico (which is weird), and another one on /juju-ui/assets/slider-base/assets/skins/sam/thumb-x.png
<teknico> oh, ok
<bcsaller> if I'm correct its not that the work failed, its that it failed to do the right work
<teknico> bcsaller, yes, there are hundreds of messages in the browser console, and the failures in the page itself also seem to hint to problems with test setup
<bcsaller> teknico: yeah, I think the dep ordering was never right in prod, and thats what we needed to test was working properly 
<teknico> bcsaller, oh well, at least we have failing tests now :-)
<bcsaller> indeed 
<teknico> I wonder whether I can land a branch with 78 test failures, though :-)
<bac> gary_poster: for some reason my emacs config went nuts recently wrt to tabs.  i've tamed it now.
<gary_poster> cool bac
<teknico> gary_poster, hi, so you're there? you look away
<gary_poster> I am here teknico
<gary_poster> I see holiday requersts :-)
<teknico> gary_poster, yes, all the end of year stuff
<teknico> gary_poster, I'm kind of stuck wrt to ^^, what do you suggest?
<teknico> gary_poster, namely, I enabled tests on the production environment, and there are 78 failures
<teknico> they run though :-) shall I land that branch?
<gary_poster> bcsaller or hazmat, goodspud asks "Can the GUI charm automatically run a script to launch the GUI in a browser?"  My answer would be "AFAIK it would be difficult to do this productively, and quite surprising to a juju user."  Would you agree?
<hazmat> gary_poster, we can do a jitsu command.. jitsu gui which does the write thing
<hazmat> right even..
<gary_poster> teknico, right, I saw that.  I think you could land it, because our existing test command still passes, right?  I wouldn't mark the bug as fixed
<gary_poster> hazmat, yes.  goodspud replied to your comment about that in this way: "Tom Haddon (IS) has indicated they won't be using Jitsu because they can't rely on any of it's features being supported"
<teknico> gary_poster, yes, "make test" passes (equals to "make test-debug")
<gary_poster> hazmat (https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AlIM--9A1RkTdFFyZ0JHZ2R2LTVoZFhidHpvYldIc1E&disco=AAAAAFJ5Z1g&pli=1#gid=0)
<gary_poster> teknico, yeah, I think it is OK to land, but the bug won't be fixed until we actually have the tests passing.
<teknico> gary_poster, well, the bug says "Tests should be *runnable* on the production build of the code", not "Tests should *pass* on..." :-)
<gary_poster> teknico, :-P
<gary_poster> teknico, next you will be sending me a printout of the production build of the code, with you running on top of them and holding a printout of the tests
<teknico> gary_poster, :-D
<teknico> gary_poster, isn't the idea to compartimentalize things? separation of concerns? divide and conquer? :-)
<teknico> gary_poster, seriously, I do think it's a valuable distinction, even if it was not completely intended :-)
<teknico> gary_poster, but ok, I'll leave the bug open
<gary_poster> teknico, compartmentalize, yes!  that's why I said it is good to land.  I'm also ok with you filing a separate bug for the passing and marking this bug fixed.  It brings some value--the value to work on the next bug. ;-)
<teknico> gary_poster, ok, I'll do that then
<gary_poster> cool
<goodspud> gary_poster, hazmat - I'm trying to find an easy way to launch the GUI and thought automating that process would be the nicer experience, but open to thoughts and suggestions. Tom said they couldn't rely on features in jitsu always being supported so they would find other ways to do things that it could do
<gary_poster> ack goodspud. we could provide the jitsu command as a standalone script, I guess, but that is a first step towards recreating jitsu
<hazmat> goodspud, there will likely be juju implementation agnostic subset of jitsu supported in the future. but in the abesnce of that, .. introducing a new command to juju-core is possible, but no guarantees till core signs off and gives a timeline.
<hazmat> possibly a juju open unit_name command
<hazmat> or juju go unit_name
<gary_poster> teknico, approved all your holidays, thank you.  You get Jan 1 off too, right?  That was not in your approval list FWIW
<teknico> gary_poster, oh right, it's a national holiday, I'll input that too
<gary_poster> thanks
<goodspud> hazmat, gary_poster - are the juju-core team open to bribes? :)   I do quite like the "sound" of "juju go..."
<gary_poster> :-)
<gary_poster> I haven't actually heard of that approach tried yet...
<goodspud> bac, are you free after today's meeting to talk through the process of setting up juju/juju-gui  on machines here with an up to date branch so we can help with testing and feedback?
<bac> goodspud: sure
<goodspud> Awesome
<bac> goodspud: how long until your EOD?
<goodspud> 2.5 hours, although I have a meeting in my diary for the last hour of that
<goodspud> Happy to talk now if you are free too
<bac> goodspud: ok.  i may take 15 minutes after our meeting to grab a bite to eat before chatting with you.  would that be ok?
<goodspud> bac, certainly would be
<hazmat> goodspud, sent an email to juju-dev requesting it.. tbd
<goodspud> hazmat, cheers!
<Makyo> Call now?
<bac> i'm there!
<gary_poster> bah sorry
<gary_poster> bac bcsaller benji goodspud hazmat Makyo teknico call now
<teknico> let's all jump in GvR's time machine!
<hazmat> bac, can you do ssh-import-id hazmat
<hazmat> bac, on uistage
<bac> hazmat: done
<hazmat> bac, thanks
<teknico> benji, can you please move your mic out of your breathing flow? thanks :-)
<benji> teknico: thanks for the heads-up; the world needs a solution to open mics on video calls
<teknico> benji, indeed, as long as it is not from apple :-P
<benji> heh
<benji> I will be buying one of these at some point: http://whirlwindusa.com/catalog/black-boxes-effects-and-dis/miclineinst-switchers/mic-mute
<bac> goodspud: do a G+ hangout at the top of the hour?
<teknico> benji, wow, pro footswitch :-)
<goodspud> bac. yes. 
<benji> the PP model looks good; but what I would *really* like is a hybrid with a push-to-talk button for large groups and a latching switch for times when you are doing one-on-one talks with people
<teknico> benji, nice, it's also latching, just like the switch on your average $20 chinese headset ;-)
<teknico> benji, yes, using the headset latching switch as push-to-talk takes some state-managing attention :-)
<benji> yep :)
<hazmat> bac, the uistage stuff should be fast again with nginx i suspect
<hazmat> python simple http server was never meant for this use case imo
<hazmat> its pretty slow
<benji> bcsaller: where is the review for 1077067?  No review is linked from the card and no branch is linked to the bug.
<bcsaller> benji: https://codereview.appspot.com/6867072/
<benji> thanks
<hazmat> bac, should be faster now.. just switched simplehttpserver for nginx
<bac> goodspud: hi
<goodspud> bac, 2 secs....
<bac> goodspud: ok, spinning up the hangout
<bac> goodspud: https://plus.google.com/hangouts/_/2917c88c62c0938e080426c3ee1a2280dea330c1?authuser=0&hl=en
<bac> goodspud: you went away
<bac> goodspud: you went away, again
<bac> goodspud: hello...london...you there?
<goodspud> bac. sorry about that - computer said "no" and crashed.
<bac> oy
<bac> goodspud: https://plus.google.com/hangouts/_/2917c88c62c0938e080426c3ee1a2280dea330c1?authuser=0&hl=en
<goodspud> bac, hmmm, now you are invisible
<bac> goodspud: still there?
<goodspud> bac, apologies for the interruption. VMware keeps crashing my machine. I'll get that sorted then come back to you another time to get things up and running
<bac> goodspud: ok.  you may be able to make progress on your own following the README
<goodspud> bac, I'll go through the instructions and let you know if I have any issues
<bac> goodspud: just let me know when you'd like to try again.  tomorrow would be good sometime after your lunch
<goodspud> bac, will do
<gary_poster> teknico, bac and I are trying to quickly review your branch so you can land before your EoD
<teknico> gary_poster, great, thanks
<teknico> gary_poster, re: the standard review markers we recently discussed, are they documented somewhere? I don't remember what they are :-)
<bac> teknico: done
<teknico> bac, gary_poster, applying and landing, thanks
<gary_poster> teknico, we should document them in docs/process.rst .  They are currently recorded in https://canonical.leankitkanban.com/Boards/View/102529849 .  I am on the hook for writing them up on a blog post or similar.
<teknico> gary_poster, that's the kanban board, where within it? :-)
<bac> gary_poster: lp2kanban is currently down
<teknico> Makyo, I wanted to list myself as reviewer of https://codereview.appspot.com/6905059/ , but cannot find the card
<Makyo> teknico, It's 'build-prod overwrites juju_config'
<teknico> oh wow, that one, right there :-)
<Makyo> I figured a puzzle in the name of the bug would help...uh...something. Heh
<gary_poster> teknico, sorry https://canonical.leankitkanban.com/Boards/View/102529849/103215444
<gary_poster> bac, ok. you working on it?
<gary_poster> otherwise we can get someone soon
<bac> gary_poster: i don't understand.  are you talking about teknico's branch?  i approved it a while back
<bac> 13:20 to be exact
<bac> gary_poster: oh, you mean lp2kanban?
<bac> yes, i'm working on it after i get my branch landed.
<gary_poster> bac, lp2kanban, cool thx
<hazmat> teknico, gary_poster, so uglify2 supports source maps.. ie. it could enable debug prod story
<hazmat> http://lisperator.net/blog/uglifyjs-v2-news/
<teknico> hazmat, does it have source maps for both js and less/css?
<hazmat> teknico, just js i'd imagine
<teknico> hazmat, here's a nice survey of available source maps tools: https://github.com/ryanseddon/source-map/wiki/Source-maps:-languages,-tools-and-other-info
<hazmat> teknico, cool
<teknico> hazmat, gary_poster, in order to do QA on uistage, how do I check the currently deployed revision?
<bac> teknico: not a satisfying answer but it is 274
<teknico> bac, yeah, thanks for the fish anyway :-)
<bac> teknico: is that the rev you wanted?
<teknico> bac, yes, my branch is on 273
<bac> excellent
<hazmat> possibly we could do some for of bzr var properties for revno.  needs a plugin i assume
<hazmat> ala cvs or svn  rev id substitution in a file
<hazmat> not sure if such a thing exists
<hazmat> we could just add it to the makefile to generate
<gary_poster> teknico, hazmat, I think something exists now, thanks to benji's make dist branch.  looking...
<gary_poster> teknico, hazmat, benji, there's a build/juju-ui/version.js target which would include what teknico wants, but benji, it is no longer hooked up to anything.  I think the base build ought to make that file and hook it into both debug and prod
<gary_poster> hazmat, uglify2/source maps: sounds great
 * benji returns from lunch and reads the backlog.
<benji> I guess we need tests for the Makefile
<BradCrittenden> gary_poster: the green kanban board is causing an exception because there is no default card type.  where is that set?
<gary_poster> BradCrittenden, click the gear on the top right to configure the board.  Click "Card Types" in the new window.  look in the right column for a "default" checkbox
<bac> gary_poster: i don't see 'card types'.  perhaps i don't have permission
<gary_poster> bac on our board or theirs?
<bac> ours
<gary_poster> oh, weird.  looking
<gary_poster> you should have the same powers as I...
<bac> gary_poster: what is our default card type set to?
<gary_poster> bac, we are both Managers.  Want to hang out on juju-ui for a sec and screenshare? our default type is "Task" (yellow)
<bac> gary_poster: sure
<bac> gary_poster: you making a hangout?
<gary_poster> bac, juju-ui
 * bac dogwalk
 * Makyo dogwalk, also.
<goodspud> gary_poster, hazmat - if you have any comments or thoughts on the visuals for the login screen, add them to the image and I'll get Matt C to work through them in the morning. If all is good then I'll get him to provide assets
#juju-gui 2012-12-11
<emilsoman> Hi there , are we using a library to connect the blocks in the juju gui ?
<bac> hi goodspud, any progress with your setup?
<goodspud> Morning bac. Not yet. I'm in meetings for most of the morning but i'll catch up with Evan soon. Tried the commands again this morning but still receiving errors.
<goodspud> Fixed the VMWare issue though
<bac> goodspud: you may need to blow away your apt cache and try again.  someone in blue fin is best to help, still.
<gary_poster> teknico, I'm making notes as to what I see about holidays, both so that I can keep track of what I see and so that you can confirm my understanding once I've finished digging.  So...
<gary_poster> you have an unaccepted request for a half day on Dec 14...
<gary_poster> and another for Dec 21...
<gary_poster> (half day again)
<teknico> gary_poster, yes, as mentioned in an email I sent you, those two requests are mistaken, can you please cancel them?
<teknico> sorry for the bother
<gary_poster> teknico, I was confused because in the email you said that you filed them "a while ago."  That sounded like some previous day, while I just got the notifications today.  those are the two you meant?
<teknico> I'll probably request them again when dates and times are slightly firmer :-)
<gary_poster> :-) ok
<teknico> oh no, I just meant "a couple of hours ago", sorry
<gary_poster> ok cool
<teknico> yes, those two
<gary_poster> teknico, confirmation: I just rejected those two.  you're all set
<teknico> gary_poster, great, thanks again
<frankban_> morning gary_poster: just filed a leave (the last one left this year) for next Monday
<gary_poster> afternoon frankban.  Cool, approved.  thanks for the heads up
<hazmat> random but fun http://www.fullstackoptimization.com/box2d-jquery/
<bac> https://juju.ubuntu.com/get-started/  -- under a 90 minute video is the text "Using Juju is easy!" .  mixed message.
<frankban> hazmat: it reminded me of google gravity: http://mrdoob.com/projects/chromeexperiments/google-gravity/
<hazmat> frankban, neat
<hazmat> ah there both box 2d
<teknico> that stuff's a riot :-D
<teknico> ok, I'm getting close to the 800 hundred lines diff limit, I might as well stop there for now :-)
<gary_poster> :-)
<teknico> gary_poster, I shamelessly "borrowed" some text from your blog post :-)
<gary_poster> teknico, excellent, glad it could be put to use :-)
<teknico> who wants to live forev... ehm, who wants to review some docs? ;-)
<gary_poster> teknico, :-) I think you might have another doc opportunity in your future: I thought the intent was to change the charm, not the GUI.  what you did was excellent too though
<gary_poster> welcome back frankban, btw.  did you have a nice few days off?
<gary_poster> hazmat in particular, but everyone also, I'd appreciate a review of https://docs.google.com/a/canonical.com/document/d/1YPZ511DQLJV7xWsWh7rp_dvz-8bSHnPBXHLNYcyJ8bI/edit# before I send it to the design team
<frankban> gary_poster: yes thanks, spent the whole morning reading emails and docs
<gary_poster> heh, frankban, was that a relaxing way to return, or overwhelming? :-)
<frankban> gary_poster: well, kind of relaxing ;-) 
<teknico> gary_poster, oh gosh, "the *charm* README.txt" :-o
<teknico> I cannot read anymore :-/
<gary_poster> teknico, :-) make another bug for what you did, and revise history
<hazmat> standup time?
<hazmat> gary_poster, looking
<teknico> gary_poster, "revise history"?
<gary_poster> bac bcsaller benji frankban goodspud hazmat jovan2 Makyo teknico call in 2
<gary_poster> teknico, the branch was for a different task than the given bug/card.  revise history so that it all makes sense, connecting the branch to the proper bug or redefining the bug ors something
<teknico> gary_poster, ok, sorry for ruining your attempt at conciseness :-)
<gary_poster> :-) np
<hazmat> gary_poster, looks good, comments in.
<gary_poster> awesome, thanks hazmat
<gary_poster> benji, I was about to reply with "yes"
<benji> :)
<benji> I guess I should do the proper way of commenting on a paper: read it through once and then go back to comment
<gary_poster> goodspud, I sent doc link to you and Alejandra
<goodspud> gary_poster - cheers!
<gary_poster> :-)
<teknico> "Multiple users can simultaneously move different services within the same shared Juju environment." then we only need collision detection and, presto! it's a multiplayer game. ;-)
<gary_poster> :-)
<benji> heh
<gary_poster> If we do that, I want a force-feedback mouse
<goodspud> bac, I've managed to get to the same place we where at yesterday - no errors
<bac> goodspud: excellent
<bac> goodspud: want to do a hangout?
<goodspud> bac, yep
<goodspud> bac - https://plus.google.com/hangouts/_/1dffb708bdf85ebb00839f55669013ea68b8a641?authuser=0&hl=en
<bac> goodspud now can run the server on his vm and is a bzr expert!
<goodspud> Full credit to bac for going through that process
<gary_poster> Makyo, would it be conceivably helpful for me to join you for a bit?  My next task is in about an hour
<Makyo> gary_poster, Sure, that'd be fine.
<gary_poster> cool
<gary_poster> make a hangout (or juju-ui) when you are ready Makyo 
<Makyo> gary_poster, Now's fine, juju-ui's open.
<benji> one unfortunate side effect of the recent URL change is that I can no longer copy the last bit of a URL (e.g., "app/views/foo.js") and open it directly in my editor.
 * bac bbiab
<bac> b
#juju-gui 2012-12-12
<teknico> uh oh, uistage is broken
<teknico> I just landed a branch, but it's only doc changes, it shouldn't have broken it
<frankban> teknico: working on it, it's not your branch 
<teknico> frankban, great, thanks
<teknico> frankban, it worked :-)
<frankban> teknico: yes indeed, it was just a missing reference in modules.js
<teknico> yep
<gary_poster> thank you for fixing uistage et al, frankban 
<frankban> gary_poster: welcome
<frankban> gary_poster: is "needs retrospective" the right tag for when you want to discuss some details of that card during our Friday's call?
<frankban> I mean: "class of service" -> "needs retrospective"
<gary_poster> goodspud, hi.  I have a local lunch meeting at the time of the unit and service view meeting.  mm, benji or bac, you have experience with those pages.  Are you willing and able to attend a meeting at 1630-1700UTC and then report back to the group with minutes as I describe in "Engineer responsibilities" at the end of https://docs.google.com/a/canonical.com/document/d/1GevzPVClAJaGX7YHG6SmdX2geGvR7uXc4xnuc7VY3t4/edit
<gary_poster> # ?
<gary_poster> Specifically:
<gary_poster> Engineer keeps minutes of the questions received, the input given, the decisions made, and the outstanding engineer-related questions and action items.
<gary_poster> Engineer sends minutes to Juju GUI team and design team.
<gary_poster> Engineer is responsible for getting the answers to each outstanding question from the meeting, or explicitly getting someone else to take over for that question.  If someone else takes responsibility, this hand-off is sent to the Juju GUI team and the design team.  The same goes for action items.
<gary_poster> If an engineer is still on the hook for an answer or action item when a new meeting is called, they should consider themselves volunteered for the next meeting.
<gary_poster> frankban, yes
<frankban> gary_poster: cool thanks
<bac> gary_poster: yes
<gary_poster> welcome
<gary_poster> thanks bac, I'll add you to the invitation
<bac> i like the coercion of that last point.
<bac> way to light a fire
<benji> heh
<goodspud> I'll bring snacks along to the meeting
<goodspud> :)
<gary_poster> :-)
<gary_poster> benji, out of pur nosy curiosity, any progress on getting the production tests to pass?  I'm very curious as to what the resolution will be
<benji> yep, I am down from approximately eight billion failures to 2
<gary_poster> benji, lol, excellent
<benji> they both appear to be of different classes of failures, so they will probably require different fixes, but I feel pretty good about it
<gary_poster> cool, benji, thanks for overview.  once you get it working I'm thing that the default test target ought to test the production story, so we all are testing the end result by default.  we'd keep the previous test target as a way to debug.  wdyt?
<gary_poster> teknico, approved Friday, no worries
<benji> that's reasonable; if the tests were not so slow I would suggest running them both (or all three?), but that is not the case
<gary_poster> right
<gary_poster> I know!  we could parallelize them with lxc!
<gary_poster> wait, no...
<frankban> lol
<gary_poster> bcsaller, could you update kanban board to reflect your current progress please?
<bcsaller> gary_poster: done
<gary_poster> thanks bcsaller 
<hazmat> bcsaller, what's next after ultra-mega?
<bcsaller> hazmat: panzoom is in progress, put it on the board
<bcsaller> one of the smaller ones to sort out remaining issues
<bcsaller> part way through it after yesterday
<teknico> gary_poster, thanks
<gary_poster> welcome
<teknico> in the code we have README and HACKING files, while in the charm we have README.txt , does anyone care about the extension?
<gary_poster> I usually add it, but don't care a lot.  teknico, you available for a quick call on another topic (Makefile fun)?
<teknico> gary_poster, in five minutes?
<gary_poster> teknico, I have another meeting in 5 minutes :-) can do it in 35
<teknico> gary_poster, ok, I'll hop on right away then
<gary_poster> ok thanks
<teknico> bac, what happens if the kanban active lanes are full and lp2kanban needs to put a card there?
<bac> teknico: i'd be really surprised if that is handled gracefully.
<teknico> bac, I guess we'll find out soon enough ;-)
<bac> teknico: yes, should be interesting.  put on your eye protection!
<teknico> bac, and earplugs too, for good measure!
<teknico> uhm, nothing happened
<gary_poster> bac bcsaller benji frankban goodspud hazmat jovan2 Makyo teknico call in 1
<gary_poster> bac goodspud starting
<bac> coming right there
<goodspud> hazmat, bac - use the team hangout for the meeting
<bac> goodspud: ok
<frankban> could anyone please review https://codereview.appspot.com/6929057 ? no rush, I am near my EOD. Anyway, charm tests work again.
<Makyo> frankban, taking a look.
<frankban> thanks Makyo 
<hazmat> gary_poster, login stuff fwiw in lp:~hazmat/juju/rapi-login
 * hazmat moves on to annotation support
<gary_poster> hazmat awesome thanks.  we should switch to that from rollup?
<hazmat> gary_poster, no.. i need to do some testing, i'll merge it into rollup after i get annotation support going
<gary_poster> cool
<hazmat> gary_poster, there are a couple of unit tests, but i'd like to do an end to end test with the gui & charm
<gary_poster> sounds good
<gary_poster> bac, benji, bcsaller, I'm reviewing all three cards up for review (only one left).  teknico's and Makyo's still need a second review, if you are willing and able.
<benji> k
<bcsaller> I can take one as well, tell me which you want benji and I'll take the other 
<bac> gary_poster: ok.  i will in a bit.  i just put my shoes on so the dogwalk cannot wait.
<gary_poster> benji bcsaller bac I suggest you coordinate using the tags on the kanban cards.  put your nick on the one you plan to do or are doing
<benji> I don't especially want one (or any), bcsaller; have at it
<gary_poster> thanks all
<gary_poster> :-)
<gary_poster> Makyo, I take it the target-specific variables didn't have the characteristics we were hoping for?  Maybe they were evaluated anyway?
<gary_poster> (lloking at https://codereview.appspot.com/6873071/diff/1/Makefile)
<gary_poster> looking
<Makyo> gary_poster, Correct.  Additionally, the variable containing the target name contained the current target (which changed as make worked through the dependency tree)
<gary_poster> Makyo, yeah I saw that second one.  Too bad target specific variables are not lazy, but I guess that makes sense
<gary_poster> in the context of other make decisions, I mean
<Makyo> gary_poster, yeah.  Additionally the env var solution fits with the other release patterns, i.e.: PROD=1 make tarball
<gary_poster> yeah, I thought of that.  I'm mostly just going to be asking for comments explaining why we have to do this stuff.
<Makyo> gary_poster, okay.
<Makyo> gary_poster, additionally, found out that bzr ls without the -V option lists all files in the directory (but still contacts the parent branch to do so), so the later instances of that translated neatly to find commands.
<gary_poster> Makyo, cool, though we need to exclude editor effluvia from them at the least
<Makyo> gary_poster, okay.  Wasn't before, but that's a good addition.
<gary_poster> Makyo, it did, because we were using bzr ls
<gary_poster> and we don't commit editor effluvia
<Makyo> gary_poster, bzr ls without the -V option would include those files.  -V wasn't used in those latter two instances.
<gary_poster> ah!
<gary_poster> suck
<Makyo> But that is a good addition for omitting.
<gary_poster> well, then yes, please make it better :-)
<Makyo> \o/
<gary_poster> :-)
<gary_poster> benji, for the charm, I'd like to be able to make a release file without uploading it.  you removed the phony target to do so.  Am I correct in assuming that you don't object to adding it back as long as we have a use case?
<benji> gary_poster: ah, I hadn't reallized that was a use case; sure add it back
<gary_poster> cool thanks
<benji> I would love for us to have tests of the Makefile; I claim that we need a card to that end
<gary_poster> benji, make a slack card to show us how we coudl do it please
<gary_poster> we could do that in the charm too fwiw
<gary_poster> though granted it would be nicer and more appropriate in the code itself
<gary_poster> Makyo, reviewed: "Land with changes" :-)
<gary_poster> running to get son from acting class...
<Makyo> gary_poster, thanks :)
<bac> gary_poster: i'm back but looks like all the reviews are taken
<Makyo> Going to lay down for a bit.
#juju-gui 2012-12-13
<gary_poster> bac, fwiw, matt's card never got a review.  tomorrow.
<gary_poster> I mean, didn't get a review other than mine
<swebb> Is there a howto to bring up a juju-gui instance?  Can I just 'juju deploy juju-gui'?
<bac> swebb: we are working on a charm that will allow you to do just that.  it's not quite ready yet.
<gary_poster> teknico, in regards to title capitalization, a few things.  First, I don't want to talk about this topic. It is too trivial. :-) I think we can all agree that we should be consistent, at least.  Second, In American English the commonly preferred approach is title case, as your quote also showed. However, unbeknownst to me, apparently the sentence case is at least more common in British English, and we are technicall
<gary_poster> y supposed to be writing that, despite not having any British people on our team, so that's a start on an argument.  The "sentence case is more appropriate for open source documentation" argument is not very compelling to me--I don't see any kind of correlation myself--but I recognize that not everyone shares my opinions.  Lastly, I'm not fond of dictating much of anything.  If I can't persuade, maybe I'm wrong.  If
<gary_poster>  you would like to raise this with the team and get a consensus so we never have to talk about this again, that would be fine with me. :-)
<teknico> gary_poster, we don't have to talk about it if you don't want to
<gary_poster> teknico, let's talk about it on our call in an hour :-)
<teknico> gary_poster, ok
 * bradc is having issues
 * teknico is back in a few minutes
<bac> gary_poster: that was not me
<gary_poster> ok bac
<bac> this is me
<gary_poster> :-) good
<gary_poster> bac bcsaller benji frankban goodspud jovan2 Makyo teknico call in 1
 * gary_poster restarts computer
<gary_poster> bac I keep on meaning to tell you that the notes you made for yesterday's meeting with goodspud, hazmat, and greg rocked.  thank you.
<goodspud> If you want to see Mark's vision... it's here... in the middle of the whiteboard.
<goodspud> https://docs.google.com/a/canonical.com/file/d/0B1IM--9A1RkTX1hyOUQ5YUlzenc/edit
<goodspud> interpret it how you want to 
<gary_poster> Things are IN THE CLOUD!
<goodspud> Everything is in the could... except the stick figures
<gary_poster> is that a cookie in the top right?
<gary_poster> mm, chocolate chip
<gary_poster> being cooked by demon fires beneath it
<goodspud> It's a sea sponge
<gary_poster> lol
<goodspud> Believe it or not they are all different sorts of branches leading to collections of charms
<goodspud> Launchpad related
<gary_poster> I like the chocolate chip cookie interpretation better, myself, but I'm partial to chocolate chip cookies
<goodspud> I'm with you on that
<gary_poster> :-)
<goodspud> My friend in Aus sends me some every so often... they are the most AMAZING
<goodspud> She makes them herslef
<goodspud> *herselft
<gary_poster> heh
<teknico> believe it or not, on Italian TV these days there's an ad
<teknico> by a shitty hosting provider advertising www.cloud.it
<gary_poster> My wife made began chocolate chip cookies this week.  except for the chocoloate chips--she had to have a bit of milk chocolate there.  but anyway, they were um, surprisingly awesome.  I'm not supposed to be surprised that the vegan recipes are awesome, right?
<teknico> and it displays a stick figure throwing itself into a cloud :-)
<gary_poster> ugh, s/made began/made vegan/
<gary_poster> heh
<goodspud> Probably awesome because of the oh so tasty non-vegan bit
<goodspud> Hmmm... chocolate
<goodspud> teknico, so they little video basically says, "life is too busy and complicated so it's probably best to go to heaven?"
<teknico> goodspud, that may be the subliminal implication, I guess :-)
<gary_poster> :-)
<goodspud> :)
<benji> I don't think it would be too hard to find vegan chocolate.
<gary_poster> no, there is vegan chocolate
<gary_poster> the chips we've found don't taste as good
<gary_poster> there's a local chocolate place that makes chocolate direct from cocoa beans
<gary_poster> they are vegan and really yummy
<gary_poster> but don't make chips
<gary_poster> (and if they did I suspect they would be prohibitively expensive)
 * teknico is rebooting a couple more times, just for fun
<benji> individually gold foil wrapped chocolate chips, delivered by unicorn
<gary_poster> :-)
<bac> gary_poster: re: the notes yesterday, i just set up the template and hazmat went nuts.  i did try to repackage it a bit to be more understandable
<bac> i'm curious if mark's classification of "the future" includes kapils categories of "science fiction" and "fantasy"
<bac> and then some, probably
<gary_poster> bac, heh, cool. :-) sometimes getting the ball rolling is the hard part.  and it is understandable, so success there as well. 
<gary_poster> scifi/fantasy: yeah, I suspect you are right
<frankban> gary_poster: the doc refers to the `tarball` make target, which does not exist, i guess it should be something like ``tarball: $(RELEASE_FILE)``. Also, `make release` seems to be now called `make dist`. I think this is a WIP.
<gary_poster> bac, you have a card on the board in "Needs Specification" titled "staging deploy: add 'make clean' and 'appcache-force' to cronjob"
<gary_poster> can we remove that, bac?
<bac> gary_poster: yes.
<gary_poster> done thanks bac
<gary_poster> frankban, looks like doc was not updated.  State is as follows, afaik:
<gary_poster> - doc should be updated to change "make release" to "make dist"
<gary_poster> - Makyo's branch will hopefully re-add a "distfile" target, which will be equivalent to the "tarball" target.  Hopefully he will update the docs for that too.
<gary_poster> If Makyo's branch has those changes, you could start from it as a precursor
<Makyo> Ah. hm.  Can do!
<Makyo> Almost ready to push, if not submit.
<frankban> gary_poster: ack, cool.
<gary_poster> Thanks Makyo :-)
<gary_poster> frankban, I suppose you could make a release from trunk as is even without those changes, if everything else looks ok
<gary_poster> you would only need the make distfile target when you get to that part f the charm
<gary_poster> I bet it will be ready for you tomorrow morning in trunk
<frankban> gary_poster: I agree, I was just following the steps in the docs, just to get used to it. Also, IIRC, launchpadlib si installed by default in all our OS targets, right?
<gary_poster> frankban, pretty sure but not 100%.  A lot of Ubuntu relies on it
<gary_poster> indirectly at least :-)
<frankban> gary_poster: ok thanks
<goodspud> OK, fess up... who broke the demo?
<goodspud> https://docs.google.com/a/canonical.com/file/d/0B1IM--9A1RkTM2ZfS3RSalZQODQ/edit
<goodspud> I have vays ov making you talk
<goodspud> Actually, should I file this as a bug or should we not worry about it?
<goodspud> ... for the time being anyway
<bac> goodspud: that is hideous.  how did all of those arrows get in there?
<goodspud> bac, :)  The evil red arrow monster
<bac> goodspud: with your new found powers you just need to 'bzr pull' and 'bzr log  | more' and you can figure out the likely culprit
<bac> goodspud: btw, i don't see the same thing.  it looks good from here.
<goodspud> bac, I'm not used to these powers. 
<goodspud> bac, only happens when I resize the browser. 
<Makyo> With great power comes great responsibility, etc, etc.
<goodspud> :)
<bac> goodspud: oh, now that is good info
<bac> goodspud: ok i can replicate the bottom.
<bac> i don't see the artifact at the top of your screenshot, though
<goodspud> bac, that's the background... the canvas isn't resizing
<goodspud> I'll log it as a bug and then you can all fight over it. I'm not necessarily concerned about it at the moment but it's not pretty.
<bac> benji, gary_poster: either of you used debug-hooks lately?
<benji> bac: a little last week; but I couldn't remember half of it
<bac> the charm has an install error.  i ssh via debug-hooks but when i manually try to run install i get an error from juju-log b/c the JUJU_SOCKET_AGENT isn't available
<bac> it is as though the environment isn't there....but that's what debug-hooks *did* i thought, as opposed to just ssh-ing in
<benji> that matches my understanding
<gary_poster> bac, not exactly
<gary_poster> wehn you have debug hooks on then you can look around
<gary_poster> but when a hook is called by juju, it dumps you into the environment then
<gary_poster> and you have all the expected variables
<bac> gary_poster: but can you re-run the hook?  i
<gary_poster> bcsaller, I wonder if the test you loosened actually was catching this regression or not
<gary_poster> https://bugs.launchpad.net/juju-gui/+bug/1090046
<_mup_> Bug #1090046: Resizing the browser causes the GUI to break <regression> <juju-gui:Triaged> < https://launchpad.net/bugs/1090046 >
<gary_poster> I'll add the card to the secondary story
<gary_poster> bac, yes
<gary_poster> looking
<bac> gary_poster: that's when i see failures when the hook calls juju-log
<gary_poster> bac juju resolved --retry 
<bac> gary_poster: that bug looks to be related to the charm store filter picker.  but i'm pretty sure browser resizing worked when i landed it
<gary_poster> is that what you wanted?  that's what we used
<bac> gary_poster: gah!  that's what i'm missing
<gary_poster> cool
<bac> so you do that before debug-hooks, right?
<bac> or inside?
<gary_poster> bac, before, on your local machine
<bac> righto
<bac> gary_poster: no difference.  :(
<gary_poster> bac, it didn't retry and dump you into the hook in a separate session? weird.  supposed to, pretty sure.  hunting around...
<bac> gary_poster: actually this page https://juju.ubuntu.com/docs/write-charm.html says you do d-h and then from another shell resolved --retry
<gary_poster> bac, right, on your host machine
<gary_poster> ohm, sorry, I mislead
<bac> np
<bac> https://juju.ubuntu.com/docs/hook-debugging.html should definitely mention resolved --retry
<bac> and the dance
<bac> Makyo: around?
<bac> i'm seeing juju-gui charm failing on make due to app/assets/javascripts/d3.v2.min.js being missing again.  shouldn't that be fixed?
<gary_poster> things have been changing in the Makefile bac, so it may be broken again :-/
<gary_poster> bac, maybe see if teknico's branch fixes it, by chance?
<gary_poster> getting...
<gary_poster> bac lp:~teknico/juju-gui/improve-makefile any better?
<gary_poster> or worse :-P
 * gary_poster will be glad when we are done with Makefile
<bac> gary_poster: i'll try it now
<Makyo> Looking.  Sorry.  Not quite 100% :P
 * gary_poster also sympathetic to benji's call for Makefile tests, even though he is worried about what those would look like
<bac> Makyo: nm, i've got a lead.
<Makyo> bac, okay.  make all in a lightweight checkout ran okay..
<Makyo> But that was just local.
<gary_poster> don't see why it should be diff :-/
<bcsaller> gary_poster: just got back from grabbing lunch, the regression might have been caught by the test or caused by other changes in the refactor, I imagine a few minors will crop up and then again as we move things to modules
<gary_poster> agreed bcsaller, no worries, just something to address
<bac> one problem we have is none of our clean targets don't get rid of the links in app/assets/javascripts so initial builds look different from subsequent ones
<bac> s/don't//
<bac>  s/don't//
<gary_poster> ah
<gary_poster> yes
<gary_poster> that should be fixed
<gary_poster> mm
<gary_poster> bac, if you develop a target for that in anger that you think would be reasonable, let me know.  I have an evil plan in that case: if teknico's branch helps for you, get your review of it, branch it, add your change, and land it.  I will be happy to do this evil if so desired.
<bac> gary_poster: ok.  haven't yet gotten teknico's branch to try
<gary_poster> bac, is that likely to happen, or should I go ahead and make a branch/card?
<gary_poster> ok
<gary_poster> I'll make a bug/card then
<bac> gary_poster: where do we chat?
<gary_poster> benji, *probably* not pertinent to the problem you are trying to debug, but just in case, https://bugs.launchpad.net/juju-gui/+bug/1090046
<_mup_> Bug #1090046: Resizing the browser causes the GUI to break <regression> <juju-gui:Triaged> < https://launchpad.net/bugs/1090046 >
<gary_poster> IOW there might be a real problem that the pixely things are complaining about
 * benji looks
<gary_poster> I know I tried to write pixely tests about this
<gary_poster> they were nasty but better than nothing, i thought
<gary_poster> not good enough though :-)
<benji> :)
<benji> I am pretty sure the problem was two fold: the test that fails in prod is just a bad test (it doesn't test exactly what it thinks it tests) plus there is /some/ difference in CSS between dev and prod
<gary_poster> ah
<gary_poster> ok
<benji> I can demonstrate an unrelated style difference between test and prod, but I am not certain what is causing the difference that exposed the bad test
<gary_poster> weird
<benji> I am reworking the test to just test the pixel calculation instead of the accedental details and will call it done, but there is still something broken somewhere
<benji> I will file a bug with what I have on that front.
<gary_poster> thanks
<benji> gary_poster: ready when you are
<Makyo> Going to take the dog to the vet, then lay down, will be on email.
<swebb> Q: I got the juju gui going, but it doesn't seem to know about my juju cluster (or environment).  How do I point the GUI at my env?
#juju-gui 2012-12-14
<gary_poster> swebb, there's a painful manual answer, and an incomplete automatic answer.  I'm not going to bother with the manual answer because it is too annoying, and I don't want to describe or support it.  For the automatic answer, we're working on a charm, currently in https://code.launchpad.net/~juju-gui/charms/precise/juju-gui/trunk .  It is nominally usable now.  The biggest problem is that there is zero security: if som
<gary_poster> eone knows your gui box address, they can connect and do anything they want (in terms of starting, stopping, and modifying services via the charms) over the web socket.  There are numerous other small problems--the next biggest one is that the charm should be working with gui releases, and not with the gui trunk.  We are working on all of those.  We should have decent answers for both of them by the end of the next 
<gary_poster> week, before Christmas break, and then we will polish and announce in early January.
<swebb> I tried the juju-gui-4 charm last night and I got it running, but I couldn't connect to it for some reason.
<gary_poster> swebb, did you expose it?
<swebb> I 'exposed' it (and double-checked my security groups) and it was open.
<gary_poster> hm
<swebb> I logged onto the machine too and found it running on port 8080, but when hitting the port, I got some weird error.  I'll see if I can find the error again.
<gary_poster> swebb, one of the problems with not using gui releases is that we can change something in the gui that breaks the charm
<gary_poster> our tests in the gui don't run the charm
<gary_poster> charm tests run the charm :-P
<gary_poster> that's why we are switching default behavior to use qa'd releases
<swebb> Yea, when I run it locally, I do a 'make prod'.
<swebb> and it runs.
<swebb> but it doesn't know about my environment, so it doesn't show anything.
<gary_poster> right
<swebb> When I use the juju-gui-4 charm, it fired up, but when connecting to it, the error was "no such resource"
<gary_poster> locally, you need to run a custom juju that connects to the main juju zookeeper
<swebb> (on port 8080
<gary_poster> swebb, did you try port 80?  
<swebb> Are there docs somewhere that will allow me to do that?
<swebb> Yea, I tried port 80 too.  That hung.
<gary_poster> IIRC that's the expected port now
<swebb> ok.
<swebb> I'm going to get it all up and running like at the BoF last night when I get back to work and wow my coworkers.
<swebb> :)
<gary_poster> docs: no, we don't want to support the zookeeper story.  you can look at the charm, in the install hook, and get an idea of what is necessary
<gary_poster> :-)
<swebb> ok, so if I install the charm, which hook do I look for to get it to see my active environment?
<swebb> zookeeper?
<swebb> oh, the install hook.  My bad.
<swebb> So the install instructions should be: juju bootstrap ; edit juju-gui install hook, juju deploy juju-gui ; http://hostname:80/ to do the rest.
<gary_poster> swebb, about to be afk, but install instructions are dev oriented at http://jujucharms.com/~juju-gui/precise/juju-gui *but* the last three paras are for you, starting with, "Deploying parameters may be configured by creating a configuration file"
<gary_poster> (everything above that should be ignorable, assuming you are using version 14/revno 12)
<gary_poster> but no guarantees until we get the tests running with real GUI releases!
<gary_poster> good luck, and we'll be stable for you very soon
<gary_poster> ttyl
<swebb> Thanks for the info.  I'll keep listening to this channel.
<swebb> ok, thanks!
<dguerri> i all, is there a working juju web-UI for real (not dummy) providers? 
<dguerri> I'm using rapi-delta
<teknico> dguerri, hi, I'm not sure what you mean
<dguerri> I'm trying to integrate the juju web-hi with our openstack installation
<dguerri> *web-ui (sorry)
<teknico> web-hi is rather nice too :-)
<dguerri> hehe :)
<dguerri> damn autocorrection :)
<dguerri> moreover I'm from Italy my english is not the best 
<gary_poster> dguerri, yes.  https://code.launchpad.net/~juju-gui/charms/precise/juju-gui/trunk is the charm we are working on to make it easy.  It is in flux right now, with two main limitations, but it works.  I expect us to be at a state that we can encourage people to give it a try by the end of next week, just before the break; and we intent to polish it and announce it during the first two weeks of Jan
<gary_poster> intend
<dguerri> gary_poster: thanks, it includes the restful service needed by the gui ?
<gary_poster> yes dguerri 
<dguerri> great!
<dguerri> i'll try it asap
<gary_poster> dguerri, two big limitations that we are fixing: (1) there is no security, so anyone who can connect to your web socket can control your juju; (2) charm is based on trunk rather than releases, so our automated tests can still fail us and give us a branch of the GUI that doesn't work well with the charm.  Fixes for both are in progress, as I said
<gary_poster> To mitigate risk of #1, if you are on ec2, change your security connection to only allow a connection to your IP
<gary_poster> but more reasonable fix on the way (HTTPS, password)
<dguerri> yes I'm aware of the #1â¦ however it is more related to the guy itself and not to the charm, isn't it? 
<dguerri> btw I'm going to try it on openstack in a protected environment
<gary_poster> yes dguerri, thought the charm has to play along too, of course
<gary_poster> cool
<gary_poster> s/thought/though/
<dguerri> <adv>www.unicloud.it</adv>
<dguerri> :)
<dguerri> thanks for all the info
<gary_poster> heh, cool :-)
<gary_poster> np
<frankban> gary_poster: do you have time for a quick hangout?
<gary_poster> sure frankban 
<frankban> gary_poster: juju-ui?
<gary_poster> sure frankban.  checking to see if it is open
<gary_poster> yes
<gary_poster> bcsaller, hi.  I have an embarrassingly inexperienced question: how do you deploy a non-official charm from the charm store?  I've only ever done that locally.  Neither "juju deploy ~juju-gui:precise/juju-gui" nor " juju deploy lp:~juju-gui/charms/precise/juju-gui/trunk" work.  My next try would be bzr+ssh or https, but I decided asking might be a nice idea. :-)
<gary_poster> docs don't seem to address this clearly
<bcsaller> gary_poster: you'll be best with a local charm, there is --repository and local:series/charm
<gary_poster> bcsaller, I am getting a lot of support questions for people wanting to give a try to the charm itself.  I was rewriting our charm's README to give them a big warning about where we are, and then tell them how to try the charm out.  I'd rather not tell them to use a local charm.  Is there no easy way for them to just give the charm a try?
<gary_poster> a lot == 2 in 12 hours :-)
<bcsaller> gary_poster: let me check, there is a way, I think its just with the lp: but I'll check
<gary_poster> thanks
<goodspud> gary_poster, as an admin for the juju-gui list, can you alter my settings so I don't just get the digest?
<bcsaller> gary_poster: ahh, its like juju-deploy cs:~gandelman-a/quantal/mysql
<gary_poster> goodspud, yes, will do
<goodspud> gary_poster, cheers!
<gary_poster> ah bcsaller cool thanks!  seems to have worked
<bcsaller> gary_poster: it was odd enough that I forgot how that worked
<gary_poster> :-)
<bcsaller> I always did devel with local charms
<frankban> bcsaller: re d3 components framework: do you think Module.events.yui is the right place for synthetic events (like 'windowresize')?
<bcsaller> frankban: that is the intent, do you disagree?
<frankban> bcsaller: no I don't. My next branch will contain a little patch to how the event is handled by the framework, so I just wanted to be sure of it.
<bcsaller> frankban: I have some minor pending changes as well, I'd be happy to talk about it at any point
<frankban> bcsaller: sure, whenever you want
<bcsaller> frankban: I can hop on g+, in public now if you want to chat
<gary_poster> bcsaller, want to talk to frankban now and ping me when you are done?
<bcsaller> gary_poster: sounds good
<gary_poster> cool
<frankban> bcsaller: juju-ui?
<bcsaller> frankban: yeah
<bcsaller> gary_poster: all done
<goodspud> Quick thought re my last email to the list, if the gui charm forms part of the infrastructure for an environment can it be deployed to the bootstrap node?
<bac> goodspud: i think that is the plan but juju core doesn't allow it yet.
<goodspud> damn you juju core... damn you to hell!
<goodspud> bac, then I stick with my suggestion of ensuring we write the warnings into the readme file for the charm and sort out stuff later once juju core can handle co-location
<bac> what does the '|' do in makefile dependency lists?
<bac> e.g. in the $(BUILD_FILES) target
<bac> hmm, 'order-only-prerequisites'
<gary_poster> yes bac can explain if desired
<bac> gary_poster: no, i'm good now
<gary_poster> bac benji bcsaller frankban goodspud hazmat (?) Makyo call in 1
<bac> and its Meeting Time
<gary_poster> Makyo ping
<Makyo> Was sitting on the join screen, oy.
<arosales> gary_poster: Unfortunately I won't be able to make today's restorspective I have a conflict. :-(
<gary_poster> ok thanks arosales 
<dguerri> gary_poster: sorry to bother again but so far I can't understand the restful api services architecture for juju. For instance, why are you using "improv.py" ?
<dguerri>  "improv.py" seems to be only a demo since is using fictional data
<gary_poster> dguerri, yes, it is fictional.  In the charm, you only use improv when "staging" is true
<gary_poster> otherwise you are connecting to a juju instance that is connecting to the shared zookeeper and providing the restful interface
<gary_poster> dguerri, I'm writing a better user help doc ATM.  We're still not quite ready for you--end of next week should be much better--but it can work now
<dguerri> ok, thanks
<gary_poster> (dguerri, fwiw, also we've been saying "RESTful" but it is a bit of a misnomer.  It's a websocket connection that has communication that roughly follows RESTful best practices in how its communications are spelled)
<dguerri> now is more clear to meâ¦ so this (REST or whatever) interface feeds a zookeeper instance, right?  (please be patient, I'm a newbie for juju, zookeeper and pythonâ¦ however I'm a developer)
<gary_poster> dguerri, zookeeper is an implementation detail that I probably shouldn't have mentioned.  It is replaced in Go Juju.  Our current story is something like this:
<dguerri> good to hear thatâ¦ zookeeper seems a.. beast to me :D
<gary_poster> GUI connects to a websocket.  websocket is provided by a custom Juju instance that connects to a shared state (which happens to be implemented with zookeeper) that the main Juju instance also uses.
<gary_poster> In the future, Go Juju will simply provide the websocket directly
<gary_poster> Big picture, that's the way to think of it
<gary_poster> the GUI connects to a websocket from Juju, and the websocket exposes all of the standard Juju commands
<dguerri> wowâ¦ now i understand the big pictureâ¦ thanks!
<gary_poster> np dguerri 
<dguerri> thanks a lot! great
<dguerri> btw, I really love juju.. it's a pity is wasn't developed with ruby :P
<gary_poster> :-) well, I doubt we'll have a third rewrite--certainly hope not ;-)
<dguerri> first one was  javaâ¦ ?
<gary_poster> Python
<gary_poster> Upcoming one (13.04) is Go
<dguerri> ah 
<dguerri> :)
<gary_poster> hey frankban, I'm updating the charm README to better describe how to use it.  Do you have a second to help me document the jitsu deploy-to variant?
<frankban> gary_poster: sure
<gary_poster> thanks
<gary_poster> trying juju-ui frankban ...
<gary_poster> empty
<frankban> could anyone please review https://codereview.appspot.com/6941053 ? thanks!
<gary_poster> bcsaller, ^^ :-)
<bcsaller> yeah, I can do that 
<frankban> bcsaller: thank you
<gary_poster> frankban, I'll review yours if you review mine :-) https://codereview.appspot.com/6945058
<frankban> gary_poster: agreed
<gary_poster> :-) thx
<gary_poster> approved frankban 
<frankban> :-) thanks gary_poster 
<gary_poster> and I like your QA instructions, but unfortunately I'm still doing them......
<gary_poster> :-)
<frankban> :-)
<gary_poster> Makyo, approved your branch
<Makyo> gary_poster, Thanks, should I land before lunch?  It's minor.
<gary_poster> Makyo, shrug. :-)
<gary_poster> do what works for you
<gary_poster> landing is good for the kanban board 
<gary_poster> so I lean towards doing it sooner
<gary_poster> but if you are hungry...
<gary_poster> ...nobody likes a hungry Makyo 
<gary_poster> :-)
<Makyo> Haha, well, alright :)  Was thinking of second review, but I'll land.
<gary_poster> Makyo, oh I see.  bac, wanna review Makyo's branch?  it fixes the clean issue you found, and is teeny tiny
<bac> yes
 * bac he said with much self-interest
<gary_poster> :-)
<bac> Makyo: it looks fine.  what would you think about adding this to it?  http://paste.ubuntu.com/1439028/
<Makyo> bac, looks fine.
<Makyo> Land with that?
<bac> Makyo: if you don't mind.
<bac> i don't know that it will actually fix anything but it is more correct and this part of the makefile is error prone
<Makyo> Yeah
<Makyo> Et voila.  Will be back after lunch.
<frankban> time to go, have a nice weekend!
<bac> gary_poster: you said you launched the charm recently.  did you see it populated with the normal test services from improv?
<gary_poster> bac, no, that is only if you turn staging on now
<gary_poster> by default it connects to the real juju
<bac> ah, so it is
<bac> a perfect test, then, for config-changed
<gary_poster> :-)
<gary_poster> bac, I found that right now the charm does not correctly set up the config file
<bac> how so?
<gary_poster> that is, config.js says socket_url: 'ws://localhost:8081/ws'
<gary_poster> which doesn't work out so well
<gary_poster> did you see that or fix it?  I was about to dig into it for a second, since I had time before next call
<bac> i had not seen it
<gary_poster> bac, when you go to your default charm deployment, does it connect?
<bac> i only just now got the charm to deploy without error, partly due to fixes i made and maturity of the the gui code
<bac> no
<bac> i think not
<gary_poster> ok
<gary_poster> that's the problem then--or at least your experience does not contradict mine
<bac> how would you tell
<bac> charm search works but the default charm list is empty
<gary_poster> bac, you can tell because the alerts box is orange
<gary_poster> http://ec2-204-236-250-8.compute-1.amazonaws.com/
<gary_poster> and because the svg panel has not expanded beyond 800x600, but that's a bug
<bac> yes my alert box is orange but i didn't know why
<bac> or the significance, i mean
<gary_poster> rght
<gary_poster> hm, my diagnosis is wrong
<gary_poster> http://ec2-204-236-250-8.compute-1.amazonaws.com/juju-ui/assets/config.js
<gary_poster> except that the requests are in fact going to localhost...
<gary_poster> oh I bet config.js is rolled up now maybe
<gary_poster> yup
<gary_poster> and I broke it unwittingly by changing config.js into config-prod.js :-/
<gary_poster> benji I see the regression of the missing thumb-x.png; the fix is in your branch, reinstating what was there before, right?  
<gary_poster> Just making sure I remember correctly
<benji> right
<benji> I am very close (I hope) to proposing the branch with the fix in it, or I can give you a diff
<gary_poster> cool thanks. is that gonna be in review today benji?  no, that's what I wanted--didn't want it broken over the weekend because it can be pretty noticeable
<gary_poster> so, all's good, thank you
<benji> cool
<bac> gary_poster: i see build-prod/juju-ui/assets/config.js as http://paste.ubuntu.com/1440053/
<bac> but it still is not connecting
<gary_poster> bac the problem is that the file is being included in the rollup
<gary_poster> and that is overriding the file we see
<gary_poster> I have a fix bac
<gary_poster> trying it out on my instance
<gary_poster> bac, I have a fix
<gary_poster> yay >> http://ec2-204-236-250-8.compute-1.amazonaws.com/
<bac> excellent
<bac> gary_poster: great.  you want to share?
<gary_poster> y, one sec
<gary_poster> bac http://pastebin.ubuntu.com/1440086/ and lp:~gary/juju-gui/fix-deploy .  I think I am going to propose as is: this would be another test of our build process IMO
<gary_poster> bac, quick review? https://codereview.appspot.com/6948055
<bac> yes, looking
<gary_poster> thank you
<benji___> gary_poster: the branch is up for review at https://codereview.appspot.com/6947057/; I am going to take a break for a few minutes.
<benji___> After I kill "benji"
<gary_poster> cool benji___ .  Growing a tail that long is probably exhausting
<gary_poster> :-)
<bac> gary_poster: who builds config-prod.js and config-debug.js?
<gary_poster> bac, they are in our source tree
<gary_poster> so...we do?
<bac> i see the charm writing out build-prod/juju-ui/assets/config.js
<gary_poster> right
<bac> so it is copied over at some point?
<gary_poster> symlinked
<benji> I guess my Animagus form is something with a tail.  Probably a cat.
<gary_poster> :-)
<bac> gary_poster: they are not symlinked in my ec2 instance
<bac> i don't think i'm handling them properly.  it sounds like if the api port changes i need to not just write out those files but call bin/merge-files too
<gary_poster> bac 
<gary_poster> # ls -l build-prod/juju-ui/assets/config.js 
<gary_poster> lrwxrwxrwx 1 ubuntu ubuntu 64 Dec 14 14:38 build-prod/juju-ui/assets/config.js -> /var/lib/juju/units/juju-gui-0/charm/juju-gui/app/config-prod.js
<gary_poster> bac, no you do not need to rerun merge-files, as long as you have my patch
<bac> right, because your patch is excluding them from the min.  gotcha.
<gary_poster> right
<gary_poster> benji, out of curiosity (it looks good to me), is https://codereview.appspot.com/6947057/diff/1/app/views/charm-panel.js?column_width=80 for readability and testablity or just one of those? And...
<bac> gary_poster: ok, i'm going to merge your branch now
<gary_poster> bac, with trunk or with your branch?
<bac> gary_poster: into my branch
<gary_poster> bac cool
<bac> don't want to wait on your review/land
<benji> gary_poster: that change was so I could remove the test that tested the pixel position of DOM elements (tooltips) and instead test the underlying calculations
<gary_poster> benji, I know you are just following a pattern, but why is line 50 a push, rather than part of the list in lines 43-46, of https://codereview.appspot.com/6947057/diff/1/bin/merge-files?column_width=80 ?
 * benji looks
<gary_poster> (and then do you know why line 49 is that way?)
<gary_poster> benji, cool
<gary_poster> (for tooltips)
<benji> gary_poster: oh, that should be a push, for the same reason templates.js shouldn't be (or rather, needn't be); the function above is collecting dependencies and if app/models/charm.js had any that the other modules did not, they would be missed, so I would think that app/models/charm.js should be moved to the list above (assuming that really works, which I will test now)
<gary_poster> benji, oh!
<gary_poster> benji, that is an exclude list
<benji> gary_poster: change "should" to "shouldn't" and "shouldn't" to "should" in the above, but I tthink you get the point
<gary_poster> and we should add those two files, not exclude them
<benji> nope, templates.js is included, but it can never have dependencies
<gary_poster> IOW, it is correct as it is now...oh...confused
<benji> there are no exclusions there
<gary_poster> especially given that I just touched that list in my branch
 * benji waves hand
<gary_poster> bah :-)
<benji> :)
<gary_poster> benji you confused me enough that you have to come explain it to me in juju-ui now :-P
<benji> heh, ok
<bac> gentlemens, i am EOD and EOW.  i'll be back later to check on things but i'm being summoned for a walk.  have a good weekend.
<gary_poster> bye bac
<gary_poster> have a great weekend
<gary_poster> Makyo, if you are available for a review, benji could use a second one on https://codereview.appspot.com/6947057/
<dguerri> gary_poster: it works! :)
<gary_poster> dguerri, great :-)
#juju-gui 2012-12-15
<bac> yay, this worked: juju set juju-gui staging=true
<dguerri> gary_poster: http://twitter.yfrog.com/z/nwq2igmj Thanks!
<gary_poster> cool dguerri, thanks for sharing the success  :-)
#juju-gui 2013-12-09
<hatch> busy here today!
<rick_h__> wheeee
<hatch> rick_h__ any idea what the best way is to pull down a branch from a merge request for qa?
<rick_h__> hatch: git checkout -b qa-something
<hatch> right, except the pr page doesn't include the full paths anywhere does it?
<rick_h__> actually it's in the pull request notes
<rick_h__> look at the block with the "Merge pull request" button
<rick_h__> there's a not about "on the command line"
<rick_h__> skip step 1, just go to develop, create a new branch to qa into
<hatch> ahhh, I totally missed that link
<rick_h__> and do step 2
<rick_h__> qa, and then comment on the pull request
<rick_h__> obvious skip step 3 since that's a landing step
<hatch> yup, I just didn't want to go and get the url myself :)
<hatch> <--- lazy today
<rick_h__> there's another way
<rick_h__> if you do a git fetch, and you've got pull reqests in your refspec
<rick_h__> it'll note them and you can git pull origin/$huwsbranch I think
<rick_h__> sec
<hatch> hmm right but I have uncommitted changes in my active branch and have to stash them
<hatch> I will make a qa'ing repo
<rick_h__> hatch: k, so git stash
<rick_h__> hatch: and then git co develop
<hatch> right
<rick_h__> git co -b qz
<rick_h__> qa 
<hatch> git stash makes sublime over ssh go crazy
<hatch> it like loses track of the file references or something
<rick_h__> hatch: looks like really good http://www.somethingorothersoft.com/2012/05/22/pulling-github-pull-requests-with-git/
<gary_poster> rick_h__, git make distfile conversation after standup?
<rick_h__> gary_poster: sure thing
<gary_poster> ok thanks
<hatch> our repo is large
<hatch> the qa of huws branch is pretty cool
<frankban> wow, new kanban... it has card subtasks, seems interesting
<hatch> looks the same to me :(
<rick_h__> heh yea. It took me a while to find the external card id this weekend
<frankban> guihelp: I need two review for https://codereview.appspot.com/39380043 (python/quickstart). Anyone available? Thanks!
<rick_h__> frankban: I've got a call, but can look later in the day
<hatch> maybe I've got to log out and log back in
 * gary_poster on calls till a lot later
<frankban> rick_h__: thanks
 * bac hi
<bac> frankban: i'll look
<frankban> bac: thank you
 * frankban bbiab
<hatch> wow...so Microsoft is issuing takedown notices for Ubuntu now...
 * benji issues a takedown notice to Mondays
<rick_h__> hatch: so I tried out the shortcut in that blog post and you can git checkout pr/6
<rick_h__> hatch: works nice
<hatch> rick_h__ so `git clone <juju-gui-repo>` then `git checkout pr/6` ?
<rick_h__> hatch: hmm, actually no. Well it adds a fetch-pr command
<hatch> rick_h__ so I made a new folder called qa
<hatch> cloned juju-gui into that
<hatch> made a branch for his stuff
<hatch> then pulled his branch into that
<hatch> took a while, but future branches should be faster
<rick_h__> ah there we go
<rick_h__> hatch: ok, so with that fetch-pr the process would be http://paste.ubuntu.com/6546053/
<rick_h__> oh wait, that final checkout should be a merge
 * rick_h__ starts over with a fresh repo
<hatch> is co 'checkout' ?
<hatch> ok that's more steps than I did
<hatch> :)
<rick_h__> hatch: yes, but fast
<hatch> it looks like a good candidate for an alias method
<hatch> :)
<rick_h__> hatch: yes, although you need names for the branch and the pull request number
<hatch> I was sure you could create methods in git
<rick_h__> but git qa-pr 6 qa-sticky-headers would work
<hatch> yeah
<rick_h__> hatch: definitely, it's what this link is doing
<rick_h__> the fetch-pr is a new helper as an alias
<rick_h__> hah alias = "!sh -c '[ $# = 2 ] && git config --global alias.\"$1\" \"$2\" && exit 0 || echo \"usage: git alias <new alias> <original command>\" >&2 && exit 1' -"
<rick_h__> hatch: http://paste.ubuntu.com/6546113/
<rick_h__> hatch: changes it to be 
<rick_h__> git qa-pr juju 6 qa-stick-headers
<rick_h__> juju is the remote of the official juju repository (vs your fork since the pr is there) and 6 is the pr number and finally the name of the qa branch to create
<hatch> marcoceppi so does it usually take a couple weeks to get a charm approved for the store? Anything I can do to speed up the process of getting that Ghost charm in there? 
<marcoceppi> hatch: do my work for me
<hatch> haha well you can just approve it
<hatch> it passes proof
<marcoceppi> I'm the only reviewing charmer atm
<hatch> ohh
<marcoceppi> hatch: proof != passing review
<marcoceppi> hatch I'll review tonight
<hatch> ok cool - I'm more concerned that outsiders are in the same boat
<hatch> I'm not blaming you btw
<hatch> just that we may need to figure out a more streamlined process 
<hatch> marcoceppi I know - make me a reviewer, I'll review it :D
<marcoceppi> hatch: feel free to apply :)
<hatch> oh man I gotta apply? 
<hatch> :P
<marcoceppi> yeah, I know right? Such barrier
<hatch> â¯â¡ï¼â¯ï¸µ-â»ââ»
<hatch> rick_h__ curious - when I make edits to posts do you get emails of each edit? 
<rick_h__> hatch: yea, I've been getting double emails
<hatch> sorry :)
<hatch> I'll remember that
<rick_h__> hatch: all good, "delete thread" :)
<hatch> haha
<hatch> now that I've done that, back to fighting with d3
<rick_h__> hatch: did you try the alias? ^
<hatch> negative
<hatch> I have it open though
<rick_h__> note it for next one?
<hatch> I'll set it up for the next time
<hatch> yep
<rick_h__> paste the two commands into your .gitconfig :)
<hatch> this weekend I wrote a js solution to the Secret Santa Dart Dare https://gist.github.com/hatched/7873759 I think it's the most performant way, maybe someone else has a better solution 
<bac> review done frankban
<hatch> rick_h__ get your light installed this weekend?
<rick_h__> hatch: yep
<hatch> so you found the right breaker then? :)
<rick_h__> kitchen looks nice. Now the only issue is that I've gone with the 53k daylight led bulbs and the other areas are looking odd with their yellow-ish tint
<rick_h__> hatch: hah, I flipped a few off. Never can be too safe :)
<rick_h__> sorry, 5300 not 53k
<hatch> yeah my house is like that too, half the lights are white and the rest are yellow...I'm slowly converting them to LED's but damn they are pricey 
<rick_h__> yea, I've gotten 20 of these white leds in the last month. :/ 
<hatch> a few years ago I picked up one of these http://www.fluke.com/fluke/caen/digital-multimeters/Fluke-170.htm?PID=56027 
<rick_h__> heh, I've got the Fluke 117 
<hatch> and one of those circuit breaker tester things
<hatch> trying to find a link but I can't :/
<rick_h__> ah, cool
<hatch> the ones where you attach things to the wires and then the tool thing tells you which breaker it's hooked too
<rick_h__> yep
<hatch> my house wiring wasn't labeled -at-all-
<hatch> there wasn't a SINGLE label on the panel lol
<bac> hatch: i had them run all of the phone/data to a central closet so i could hook it all up to a router/panel.  none of it was labeled.  infuriating.
<hatch> lol ugh that's the worst! I don't even know of a way to test those....trial and error?
<rick_h__> they make tone tools to check
<hatch> oh cool
<hatch> the more I work on d3, the more I'm convinced it was not designed for our usecase lol
<hatch> academically, it's approach to problems is pretty interesting.....
<frankban> bac: thanks
<Makyo> jujugui call in 10, kanban now.
<hatch> Makyo after the call mind pairing on this perf branch? I'm running into some d3 funnyness that I'm at a total loss on what's going on
<Makyo> hatch, sure.
<hatch> thx
<Makyo> jujugui call in 2
<bac> coming
<bac> gary_poster: if you have a suggested next card speak now.  :)
<gary_poster> bac, :-) any non-blocked card is good.  you could take point on jujucharms or you could fix that new charm bug or you could fixthe charmworld bug, or...lotsa things
<bac> gary_poster: ok, cool
<bac> gary_poster: forgot to mention i'll probably have to go about 4 to retrieve post-op jojo
<Makyo> hatch, https://plus.google.com/hangouts/_/7acpibqvsna48s50l5ibn5eci0?hl=en
<gary_poster> bac, ok.  hope he is ok
<bac> gary_poster: should be.  "just" quilting his ear to get rid of a hematoma.  not like a lung transplant or anything.
<gary_poster> ok cool-ish
<bac> he probably isn't so cavalier about it, since it is his ear
<gary_poster> :-) yeah
<hatch> gary_poster Makyo figures he knows what the problem is but isn't sure of a workaround so I'm going to pass it off in hopes that it's a trivial fix
<gary_poster> ack thanks hatch & Makyo
<Makyo> gary_poster, hatch going to land current SSH keys branch first, + call with rick_h__ when free.
<hatch> yeah that
<gary_poster> sounds good
<hatch> Makyo https://github.com/hatched/juju-gui/tree/inspector-performance thanks
<hatch> here is the commit of this branch https://github.com/hatched/juju-gui/commit/8a9b79b36da3a39b7dd6f7dccdc882ad4712416a
<hatch> gary_poster any preference for cards for me? Shall I start on the fullscreen removal?
<gary_poster> sure hatch sounds good :-)
<hatch> rick_h__ there appears to be an issue with our gitignore.... it throws an error when I try and use `git add *` instead of adding the changed files not in the .gitignore it fails with a 'fatal' error
<hatch> not sure if you have seen the same
<rick_h__> hatch: otp, sec
<Makyo> rick_h__, http://pastebin.ubuntu.com/6546619/ for later.
<hazmat> why did branch commits make it over on the gh migration? as opposed to mainline..
<rick_h__> hazmat: it's what bzr fastimport did. I didn't see a lot of material on exporting from bzr into git and getting to tweak it. 
<rick_h__> hazmat: there's a *~ in there already?
<rick_h__> sorry, hatch ^
<rick_h__> hatch: maybe that's throwing it off? I don't know tbh. I just moved the bzr one over and it 'worked' by trial so left it alone
<rick_h__> Makyo: thanks for the paste. 
<hatch> rick_h__ yeah ok cool something to take a look at sometime
<rick_h__> hatch: k, works here so have fun :)
<rick_h__> hatch: why did you want to ignore *?
<hatch> I want to add *
<hatch> say I have 10 changed files
<hatch> I want to add all of them to the commit
<rick_h__> hatch: oic, git add -A :)
<rick_h__> or --all
<hatch> oh crap right
<hatch> that was bzr that had `add *`
<Makyo> hatch, https://twitter.com/horse_js/status/410094798062628864
<hatch> HAHAHAHA
 * hatch looks around
<hatch> is the horse in here???
<Makyo> Hah, well, it's not me!
<hatch> wow I really forgot a lot of git stuff in the past year
<hatch> jujugui could I get a really quick review of a doc update branch https://github.com/juju/juju-gui/pull/8
<bac> hatch: sure
<hatch> thanks
<bac> hatch: your branch, the words flow together and seem to form something akin to English. but for the life of me i'm not sure what i would do with them.  this coming from a total git-dummy.
<bac> so that package, i download it and put it somewhere?
<bac> and the aliases, they go somewhere too?
<bac> i wonder where
<hatch> bac lol, so you're saying you want documentation on how to add aliases? the Git Remote Branch has installation instructions on their repo
<bac> oh, ok
<hatch> sorry it's not really clear that the code is aliases
<hatch> I can clean that up
<bac> yeah, maybe just "stuff the following aliases in your ~/.git/aliases file"  (i made that up.  was i close?)
<hatch> ~/.gitconfig
<hatch> :)
<hatch> close
<bac> hatch: ok, so i added two comments in-line and wrote a top-level comment that said everything was good.  is that all we're doing for reviews in github?
<rick_h__> bac: so once you've reviewed it and you're ok, add a LGTM comment
<bac> ok
<bac> oops, i guess closing it is bad
<hatch> bac https://gist.github.com/hatched/7876600 here are the new changes.....look good?
<rick_h__> bac: hah! close all hatch's pull requests
<rick_h__> bac: yea, he can re-open it I think
<bac> lovely
<hatch> lol
<bac> hatch: yes those changes are fine
<hatch> we'll get this figured eventually :D
<hatch> I for one think that this new process is pretty darn cool
<hatch> just need to figure out all the proper commands :D
<hatch> I'm going to need a shortcut for 'refresh folders' in sublime if I keep switching between branches heh
<hatch> Makyo if you have any questions about my changes on my branch just lemme know 
<Makyo> hatch, will do; trying to find a better test for SSH keys now.
<hatch> Dolla Dolla MERGE YO!
<Makyo> jujugui researching, but in the meantime, if anyone has suggestions for checking for valid ssh keys that does not rely on a) find, or b) ssh-agent, I'd be interested to hear :)
<hatch> rick_h__ If I click this HUGE green 'Merge pull request' button, does that bypass our CI?
<Makyo> jujugui (or uses ssh-agent atomically)
 * gary_poster does not; sorry
<frankban> Makyo: what's wrong with just searching for an id_rsa.pub?
<hatch> probably slow
<hatch> TWAG though
<bac> i wonder if landscape would accept our browser sniffer/intercept code?  they only support firefox but happily let you have a diminished experience if you don't know that.
<Makyo> frankban, that leaves out id_dsa.pub and id_ecdsa.pub, and identity files can be specified in other locations using ssh config.  I'm fine with that as a last resort, but would like something that actually checks for ssh identity availability.
<frankban> Makyo: ack
<Makyo> frankban, want to just go with that for now and land this, then see if we need to investigate further?
<Makyo> Up to you Â¯ï¼¼(Âº_o)/Â¯
<rick_h__> hatch: your branch failed to land. You have to delete the comment about it being 'merge request accepted' to get another run
<hatch> rick_h__ hmm how did you know that it failed?
<rick_h__> hatch: was looking
<rick_h__> hatch: eventually it should add a new comment on failure, but it's not hooked up yet
<frankban> Makyo: +1
<Makyo> frankban, ack, on it.
<frankban> Makyo: thanks
<hatch> rick_h__ ohh ok so the issue here is that it commented after I typed $$merge$$ ?
<rick_h__> hatch: right, the system adds a comment saying the merge request has been accepted, so that it won't run it more than 1 time in case it takes a while to get to your merge
<rick_h__> hatch: say 3 branches all get the request to merge at once, the cron job runs every 2min, so it has to be able to know "these 3 are already queued, don't add them again"
<rick_h__> hatch: so remove that comment and the system will re-queue on the next 2min cron run
<hatch> ok so saying $$merge$$ again won't help?
<Makyo> frankban, worth another quick look just for completeness' sake? https://codereview.appspot.com/36080044/diff/20001/quickstart/app.py
<rick_h__> hatch: no
<frankban> Makyo: on it
<rick_h__> hatch: it's looping and looking for the command once. 
<hatch> ohh ok
<rick_h__> the one cancels the other out
<rick_h__> hatch: cool worked
<hatch> yup - so that was just an unfortunate race condition there then?
<frankban> Makyo: looks good, even if I hoped we were able to use python to check for ssh keys (e.g. os.walk, glob.glob etc) <shrug>. Perhaps you can follow up in another card?
<rick_h__> hatch: right, and I'm proposing a branch right now to get around that. Will be looking for review shortly
<hatch> cool - and about the butt
<hatch> on
<hatch> if I press the merge button will it bypass the CI?
<rick_h__> hatch: yes, and I get angry with you
<Makyo> frankban, understood; it just still seems fragile, as we're not checking on actual identities , just whether or not files following a certain name exist.  If someone snags a public key to add to authorized_keys and forgets to clean up after themselves, this will false-positive.
<hatch> rick_h__ haha, can we disable that somehow?
<rick_h__> hatch: not that I know of atm
<Makyo> That's why  I went with ssh-add at first.
<Makyo> I thought `ssh-agent ssh-add -l` might work, but that just always fails :P
<frankban> Makyo: ok right, you intend this as a temporary solution. ok then, added a new LGTM. please create another card to investigate further
<Makyo> frankban, Yep, thank you.
<rick_h__> hatch: care to peek at https://github.com/juju/juju-gui/pull/7 please?
<hatch> sure
<hatch> I love how github keeps the diffs up to date
<hatch> rick_h__ lgtm'd with some notes
<rick_h__> hatch: rgr, replied to one
<rick_h__> hatch: well, replied to both in the end
<hatch> cool - yeah I figured the caching would be a followup
<rick_h__> well, post-ci stuff :)
<hatch> right
<hatch> yeah
<hatch> so the 'failure' stuff is going to be done soonish?
<hatch> the 'bug' which I ran into previously? Or do we need to keep our eye on the merges for now?
<rick_h__> hatch: yea, I've got to find a post-build plugin and figure out how to wire it up. jenking-github-lander supports posting the failure notices already
<rick_h__> hatch: keep an eye on merges for now
<hatch> cool gotcha
<hatch> oh cool github gives the option to delete merged branches
<rick_h__> yea, button to help keep things clenaed
<hatch> rick_h__ possible idea for disabling the 'merge' green button - allow only the jujugui user to merge stuff in then the button should be hidden?
<rick_h__> hatch: yea, but we're all in the org
<rick_h__> so it gets into tricky perms of "you can do stuff, but not this one thing" and haven't looked too closely at it
<rick_h__> just trusting out devs
<hatch> ahh ok 
<rick_h__> e.g. the idea to do a release is you checkout just the juju project, merge develop into master, push up the updated master as a release
<rick_h__> so if you can't do the merge button, you can't do a release
<hatch> ok wtf google, I said "about" into hangouts, and it typed "a boot" lol!!!!
<hatch> damnit I'm not THAT Canadian
<hatch> lol
<bac> rick_h__: trusting devs may be dangerous at least until we're all up to speed
<bac> big green buttons are so tempting
<hatch> bac the good thing about git is you can always roll back from anyones repo
<rick_h__> bac: understand. Like I said though, there's not a ton I can do about it for now
<hatch> there is nothing 'special' about the github repo vs anyones local one
<hatch> well that's a lie
<hatch> but on face value :)
<bac> i'm just apologizing in advance...  :)
<hatch> haha
<hatch> bac feel free to ask
<rick_h__> bac: let me konw if you'd like a walk through or anything. I'm not aware of everyone's git levels so I left 'training' out to some notes/docs but happy to help walk anyone through things
<hatch> just don't push upstream with -f :D
<bac> rick_h__: did you write a getting started guide?  if so i missed it but would like to read if available
<hatch> rick_h__ it might be best to also add `git remote add upstream ...` and `git fetch upstream` for updating the local fork
<rick_h__> bac: in the email linked the repo with a README
<rick_h__> hatch: it's in the notes
<hatch> ohh ok 
<hatch> I mised that line I guess heh
<rick_h__> hatch: the notes have you add a remote juju, and git pull juju origin when starting a new branch
<rick_h__> bac: sec, will PM you think linke
<rick_h__> link
<hatch> ugh my email is a mess
<hatch> I need to set up filters
<hatch> I am the antitheses of inbox-0 
<hatch> haha
<hatch> so for our christmas party do we just sit in-front of our computers in a hangout drinking rum and eggnog? 
<hatch> playing virtual beer pong
<gary_poster> antithesis: inbox infinity?
<Makyo> CO-Canonicalites have a party next Thursday, so there.
<bac> hatch: i can see the bacardi distillery from my patio.  :)
<hatch> gary_poster I'm working towards it...haha
<Makyo> !
<hatch> Makyo lol lucky
<gary_poster> :-)
<rick_h__> Makyo: MI-Canonicalites always party! right jcastro?
<hatch> bac haha nice
<Makyo> HP used to have their open source lab here, so there's a few of us (and a few RH folk, too)
<hatch> do you shun them when you get together?
<hatch> they need to execute a proper apt-get command to get in the door
<hatch> lol
<hatch> its the shibboleth 
<Makyo> Pff.
<Makyo> We just don't invite them :)
<hatch> hahaha
<Makyo> It's a company holiday party, after all.
 * bac recalls the one Canonical-NC party that was a huge success
<hatch> I'm going to host the biggest Canonical-SK party EVER this year
<bac> working remotely makes company parties actually fun.
<bac> the brick-and-mortar company parties just seemed like a continuation of the work day
<hatch> http://deadlygeek.myshopify.com/
<hatch> bac - sounds like a lame party to me
<Makyo> :/
<bac> hatch: the existence of that belt buckle is why i am opposed to any gift giving.  :)
<hatch> lol damnit I'm buying myself one!
<hatch> rick_h__ do you have time for a discussion on removing fullscreen and followup direction?
<rick_h__> hatch: yea, second
<hatch> https://plus.google.com/hangouts/_/7ecpj8dfhvb68a9eaplojbk1bg?hl=en
<hatch> crap it crashed
<hatch> I'll try inviting you directly
<jcastro> I can't find my own bundles in the store
<jcastro> I am trying to find the cloudfoundry bundle
<rick_h__> https://jujucharms.com/fullscreen/search/?text=jorge don't see cloudfoundry atm though
<rick_h__> jcastro: did you update it recently and maybe it failed proof?
<jcastro> http://manage.jujucharms.com/bundle/~jorge/cloudfoundry/cloudfoundry
<jcastro> it's just not in jujucharms.com the non-manage part afaict
<rick_h__> looking
<rick_h__> jcastro: hmm, it's showing on staging so something is up between staging/production http://staging.jujucharms.com/search?search_text=cloudfoundry&op=
<rick_h__> jcastro: will have to look into it
<jcastro> oh cool, so I found a real bug?
<rick_h__> jcastro: or a mis-configure or something. 
<rick_h__> jcastro: updating my local env and doing a fresh pull of data. I'll have to chase it down, will get back to you tomorrow
<jcastro> no worries
<jcastro> I wonder how long it's been broken
<jcastro> I don't suppose we can add a "bundles" category?
<rick_h__> yea, not sure. I only seem to see it missing. Others look fine. So something is up with that one bundle
<rick_h__> jcastro: yea, there's a todo to figure out something, but not sure where it's at. 
 * bac -> vet
<hatch> bug #1217383
<_mup_> Bug #1217383: inspector should be the default <juju-gui:Triaged> <https://launchpad.net/bugs/1217383>
<hatch> thanks mup
<hatch> rick_h__ ""This is horrible and we know it"" lol
<rick_h__> :)
<hatch> Makyo hey, curious if you're making any headway on that d3 stuff? 
 * hatch is curious what the solution (if any) there is :)
<Makyo> hatch, git problems, just getting started, have an idea.
<hatch> ahh ok cool np
<hatch> git is a problem until you understand how it works hah
 * hatch does not understand it
<hatch> :P
<Makyo> I just had some weirdness left over from setting up 2fa.  Helped to switch to ssh urls.
<hatch> jujugui looking for a smallish review/qa https://github.com/juju/juju-gui/pull/9
<hatch> I still can't decide what kind of laptop to get so my whole setup is a mess - I feel your pain haha
<hatch> doh
<hatch> jujugui remember to make lint && make test-debug before issuing a PR :)
<Makyo> How about make check?
<hatch> yeah that's fine too I SUPPOSE :P
<Makyo> It's almost like it's there for a reason... :)
<hatch> I know right?
<hatch> crazyyyyy
<hatch> woah, apple.com has a huge picture of Nelson Mandela
<hatch> unfortunately the apple.ca financing deals aren't nearly as good as the US ones :(
<hatch> US financing is always so much better than in Canada :(
<gary_poster> hatch, you still want review?
<hatch> yup I do
<gary_poster> k on it
<hatch> I'm trying to remove this in as many atomic pieces as possible
<hatch> it's very.....connected heh
<gary_poster> :-) I believe it
<gary_poster> ok, this is really I time for me to set up a decent git qa pattern...
<hatch> gary_poster I created a new clone of the repo then run the two aliases that I added to the HACKING docs
<hatch> the aliases were thanks to rick_h__ 
<gary_poster> yeah was just stealing those myself :-)
<hatch> man I REALLY want to buy a MBP with 18mo 0% interest financing
<hatch> anyone want to buy it for me and trust that I'll pay you back? ;)
<gary_poster> ai-yai-yai, I need a cheat sheet
<hatch> haha yeah
<huwshimi> Morning
<gary_poster> hey huwshimi 
<huwshimi> gary_poster: Hey
<hatch> hey huwshimi 
 * Makyo dogwalks before it gets too cold.
<hatch> huwshimi if you need some help moving forward with your sticky branch lemme know
<huwshimi> hatch: heh, yeah, I'm not quite sure what to do with that branch
<hatch> you just want it to die don't you?
<gary_poster> hatch, LGTM etc
<hatch> thanks
<huwshimi> hatch: Yes, please
<hatch> lol
<huwshimi> hatch: it or me
<huwshimi> either would be acceptable at this point
<hatch> hey at least we are using your code haha
<gary_poster> huwshimi, :-) and :-P
<huwshimi> hatch: And your browser test is not so promising either
<gary_poster> hatch, huwshimi is it worth strategizing together about next steps?
<gary_poster> huwshimi, I mean, deep unhappiness is always valuable, but...
<hatch> lol!
<huwshimi> haha
<hatch> I'm sure any of us JS peeps could take over to resolve the issues
<hatch> I'm a little deep in fullscreen removal land right now however
<huwshimi> gary_poster: We can, I'm in a land of uncertainty right now so it might be good to figure out what to do with it
<huwshimi> hatch: Ooh, nice!
<gary_poster> ok.  hatch, you available for a hangout as well?  
<hatch> sure lemme turn on my anti-bark machine
<gary_poster> huwshimi, hatch https://plus.google.com/hangouts/_/72cpi8bsiur2s17hpkf800rcfg?hl=en
<rick_h__> gary_poster: let me konw if there's any specific set of cribs for workflows you'd like written up
<rick_h__> hatch: woot for landing on first try
<gary_poster> thanks rick_h__ .  want more of proposed process from https://gist.github.com/mitechie/c0183e567d81aa92b5e3in hacking doc.  we have some of that
<gary_poster> but not all
<gary_poster> and I want all :-P
<rick_h__> gary_poster: want more as in more types of that? Or more details written in to flesh that out?
<gary_poster> rick_h__, I want all of that in hacking doc
<gary_poster> I don't want to have to keep link to gist :-)
<gary_poster> and then maybe could elaborate on it
<gary_poster> but even as is would make me happy
<rick_h__> gary_poster: ah, gotcha. Ok yea I figured it would pollute the hacking doc a bit, but happy to move it over
<gary_poster> +1
<rick_h__> gary_poster: ok cool, works for me
<gary_poster> rick_h__, or process
<gary_poster> divided up by tasks
<gary_poster> as you think
<rick_h__> gary_poster: yea, as hatch hit the qa stuff today I was thinking of adding a qa process
<gary_poster> +1
<rick_h__> but beyond qa and submitting a branch wasn't sure what other processes to make sure to cover 
<rick_h__> release, but that's in the works and in the process doc
<huwshimi> gary_poster, hatch: Thanks!
<gary_poster> thank you huwshimi !  will be great to have
<hatch> huwshimi http://www.git-tower.com/blog/git-cheat-sheet/ :)
<hatch> rick_h__ yup the process worked well
<hatch> it's darn fast too
<hatch> the QA must not be running any python tests :P
<hatch> WOAH
<hatch> new MDN
<rick_h__> not yet, the hope is that we'll get that in soon from benji's branch/work
<hatch> and then sauce labs
<hatch> and there goes our fast CI
<hatch> lol
<rick_h__> yea, it's doomed to go, but at least we could bring it up on a faster machine if that helps :)
<hatch> haha truth
<hatch> it would be nice if we could spin up multiple sauce labs instances and run them in parallel 
#juju-gui 2013-12-10
<frankban> hazmat: did you have a chance to take a look at https://code.launchpad.net/~hazmat/juju-deployer/refactor-placement-and-validate-feedback/+merge/195903 ?
<rick_h__> morning frankban 
<frankban> hi rick_h__ 
<rick_h__> frankban: free for a hangout in a second? 
<frankban> rick_h__: sure
<rick_h__> frankban: https://plus.google.com/hangouts/_/76cpi22pojjntaagcr9vbpnl0s?authuser=1&hl=en
<gary_poster> rick_h__, re: quickstart review and your comments, I think both you and frankban know that I generally offer my suggestions as only suggestions.  If that's only true in my imagination, please let me know. ;-)  Anyway, I do think that it's very much worth exploring significantly reducing OOP.  Go, Scala, Clojure, and even books like Functional JavaScript (http://shop.oreilly.com/product/0636920028857.do) all are goin
<gary_poster> g in that direction to varying degrees.  All of those examples except Go are further advocating functional paradigms as a way to simplify reasoning about code.  I've been reading and playing with a functional style for years on my own time now, and I really think there's value to it.  In this particular example, re-introducing some OOP now that the basic pattern has been established won't kill kittens, as benji woul
<gary_poster> d say.  If that's where the team wants to take stuff, cool.  I can be the crazy guy muttering in the corner. :-)
 * benji watches the world-wide kitten-count as it holds steady.
<gary_poster> lol
<gary_poster> In other news YAY! jujucharms apparently is no longer borked!!
<rick_h__> gary_poster: yea, I was just tossing my opinion reading through things. I talked to frankban about it. I had no background to it, but read the MP as "provide model layer" and it required tracking 3 different dicts of data. I was missing the abstraction/simplification. I tend to think of models as hiding some implmentation details and I had to know in my head the implementation more than I was expecting based on my reading of th
<gary_poster> rick_h__, output was cut off after "I had to know in my head the implementation more than I was expecting based on my reading of th"
<rick_h__> bah
<frankban> gary_poster: we had a call this morning with rick_h__, we agreed on proceeding with the functional approach and see how it works. It should be easy to introduce some OOP/higher abstraction if we then find the view code to be too much ugly. As rick_h__ suggested, I'll change some name and above all I will try to get rid of the envs_meta datastructure, that can be retrieved directly by the functions that require it
<frankban>  (e.g. normalize/validate). 
<rick_h__> gary_poster: https://pastebin.canonical.com/101724/plain/
<gary_poster> proceeding for now: cool.  Agreed it will be easy to add higher abstraction if desired (I'd argue that the fact that we agree it will be easy is suggestive that the current approach does have at least some aspects of simplicity). global envs_meta: not my preference, but cool if that's where we want to go.
<rick_h__> gary_poster: yes, it's simple once you read the large comment blocks to understand what data ends up where. I just found the 'api' created as a dev a little more manual than I was expecting. 
<rick_h__> it's fine and I LGTM'd, just was curious to discuss it. I didn't know the backstory of your pre-imp when I did the review
<gary_poster> To be clear, hidden envs_meta is not my preference because (1) you have to know that there's a data structure guiding the behavior, while the current approach makes that quite explicit (maybe better names would help); and (2) testing the functions means you have to either stub the global data source or actually test the effect of the data source.
<frankban> gary_poster: interesting. 1) makes sense, people reading the code immediately understand that envs_meta is something they have to deal with. and maybe some of the confusion is generated by the names, in which case... ideas for better names? :-)
<frankban> gary_poster: envs_meta will include at least two pieces of information: the list of fields (welcome back OO) and a description for each provider type
<gary_poster> rick_h__, I'm confident that someone with more functional experience would have some beautiful refactoring suggestions to offer.  Similarly, I think this point from your pastebin has merit: "Go has interfaces/types to help provide mental mapping of what to expect within the app and keeping track of 3 diff dicts didn't strike me as aiding in simplifying the model of what was going on."  Some Clojure programmers would
<gary_poster>  disagree with you, I think, but others have expressed something like "ok, we made everything data, and now it's super easy to see how everything flows through the system, but harder to see what's flowing."  IMHO (I usually don't add the H because I'm already acknowledging that it is an O, but in this case I'm aslo acknowledging that I don't have as much experience here as I would like, though I have a decent amount
<gary_poster>  of reading) that can very often be addressed by having good names and good keys in the data structure.  That's most of what an object provides here anyway--and in fact, in a dynamically-typed language like Python, arguably that's almost all of what it provides.
<gary_poster> frankban, yeah cool, lemme go look and see if I have any name ideas.
<frankban> gary_poster: thanks
<rick_h__> gary_poster: yea, that fits what my thought process was. It was 'easy' but not 'simple' since it moved some complexity to tracking more parts. 
<gary_poster> rick_h__, have you ever seen http://www.infoq.com/presentations/Simple-Made-Easy ?
<rick_h__> gary_poster: yes, I think I watched that a while ago. 
<gary_poster> rick_h__, right.  by his definitions, I think maybe we've done a decent job with simple, but you're arguing that we haven't managed easy.  probably unimportant semantics.
<gary_poster> I mean
<gary_poster> unimportant whether we say simple or easy: I understand your objection, whichever the word we use
<rick_h__> sorry, yea I think it's flipped here. I tend to think "It's easy to just expose your database as your api, it's hard to make the api simple for people to use to perform tasks"
<gary_poster> functional programming precisely argues that you shoudl be manipulating your data
<gary_poster> I think
<gary_poster> so if I'm right
<gary_poster> this is just a mindset difference
<rick_h__> yea
<frankban> rick_h__, gary_poster : IMHO there is only one more piece of information you have to deal with with this functional approach (envs_meta). env_data is an environment (i.e. the instance. __dict__ in a OO approach), envs_dict is the YAML, and in a way or the other you have to deal with it. I think the effort here was to give developers an unsurprising datastructure and not an OO API
<gary_poster> (I agree, but that's not surprising :-)
<rick_h__> frankban: yes, that's cool. I was just not going into the review thinking "Let's do this in a functional approach and take this different mindset"
<rick_h__> I'm not completely against these things, just that my mindset during review was "Let's providel models (and maybe I think too SQL Models off the bat) for dealing with envs"
<rick_h__> and that implies, in my mindset, an api, or set of abstractions on the idea of an env from juju
<frankban> rick_h__: yeah, sorry for the missing info in the MP description, and as I mentioned to you, the "alchemy" models pattern was my first approach as well
<rick_h__> frankban: cool, yea carry on! :) Just leave the comments since they made it reasonable. 
<gary_poster> frankban, rushing to call (late) but shared ideas in rv
<gary_poster> oh bah
<gary_poster> nevermind
<gary_poster> call with mramm cancelled :-/
<frankban> gary_poster: cool thanks, so in your suggestion env_type_db is envs_meta and you introduced a new get_env_metadata function to get the metadata for that env type, right?
<gary_poster> frankban, exactly.
<gary_poster> if you were doing this a lot, you could easily compose this with a partial.
<gary_poster> import functools
<gary_poster> get_environment = functools.partial(get_env_data, env_db)
<gary_poster> get_metadata = functools.partial(get_env_metadata, env_type_db)
<frankban> gary_poster: sounds good
<gary_poster> cool
<gary_poster> hatch, did you take a look at "Chosen Implementation" in https://docs.google.com/a/canonical.com/document/d/1TxnOCLPDqG6y3kCzmUGIkDr0tywXk1XQnHx7G6gO5tI/edit?disco=AAAAAHiLwwE# ?  It looks good to me, but I'd appreciate your review
<hatch> gary_poster yeah he told me about it last night, just reading through the doc now
<gary_poster> cool
<gary_poster> abentley's reply to the charm download metric thread falls under the "bummer" category :-)
<abentley> gary_poster: Sorry :-(
<gary_poster> abentley, never apologize for the truth, or something, yeah? :-)
<gary_poster> IOW, not your fault, but it is a bummer
<abentley> gary_poster: Sorry for inflating the numbers in the first place.
<benji> we have a mechanism to not count certain charmstore downloads, we should probably make use of it for CI downloads
<gary_poster> yeah
<gary_poster> we have enough of that going on from different quarters that it would be probably wise to build generically
<gary_poster> benji, what is that mechanism?  is it in the charm store or in charmworld?  IIUC charm store is the sorce of truth here
<benji> I'm pretty sure the store has a "don't count this download" option.
<gary_poster> benji, cool.  we ought to use that for our own tests as well
<gary_poster> though that may equally be a bummer :-P
<hatch> yay odd hanging bug when loading the GUI is fixed
<hatch> how weird was that one :/
<gary_poster> yeah
<gary_poster> makes sense in retrospect
<gary_poster> as is often the case
<hatch> well a 1s timeout is crazy long though heh
<frankban> gary_poster: https://codereview.appspot.com/39380043/diff2/20001:40001/quickstart/models/envs.py
<gary_poster> hatch, you tackling huw's sticky header branch per the call last night, or should we make a call for help?
<gary_poster> looking
<hatch> gary_poster well is his last few commits in the PR where he is leaving off? 
<hatch> I can get to it after my current branch of rewriting fullscreen > sidebar 
<hatch> just doing the tests now
<gary_poster> hatch, not exactly super clear, but that was my assumption, since that's what we agreed yesterday on the call
<gary_poster> frankban, looks pretty to me. you like it?
<rick_h__> gary_poster: if you get a sec can you peek at https://github.com/juju/juju-gui/pull/10 and see if that helps with the process/notes.
<gary_poster> on it
<frankban> gary_poster: yes I do, because the resulting functions should be very short and simple, but this assumption can be confirmed only by my next branch
<gary_poster> frankban, cool. good luck.:-)
<hatch> rick_h__ so I've been using a slightly different flow that you have outlined there
<rick_h__> hatch: that's cool. Using your tool?
<hatch> after I've added the upstream I go into develop  then `git fetch upstream`
<hatch> then branch from develop on my machine
<frankban> :-) next branch with tail-recursion generated metaclasses, so that everyone is (un)happy 
<rick_h__> hatch: upstream is your remote for the 'juju' repo?
<hatch> oh you put the wrong repo in the docs heh
<hatch> git remote add juju git@github.com:juju/jenkins-github-lander.git
<rick_h__> hatch: bah, thanks for the catch
<hatch> so I add the juju repo there, then add it as the upstream for my local develop
<hatch> then in my local forked develop branch I `fetch upstream` which pulls in the updates
<hatch> then I branch from my local develop
<hatch> the outcome is the same just a different sequence I suppose
<rick_h__> hatch: right, but that's the example same steps from what I can tell. Just /juju/upstream 
<hatch> oh I thought you had it merging upstream into the new branch not the local develop
<hatch> maybe I misread
<rick_h__> hatch: no, it pulls upstream into develop and then forks from develop to a feature branch
<rick_h__> at least that's what it's supposed to say, /me re-reads
<hatch> rick_h__ oh the docs are missing the fetch I think
<rick_h__> hatch: ah, well I have pull vs fetch
<rick_h__> http://stackoverflow.com/questions/292357/whats-the-difference-between-git-pull-and-git-fetch
<hatch> OHHHH now I see why I was so confused....you called `upstream` `juju`
<rick_h__> hatch: right
<hatch> clearly I need to have my morning coffee haha
<rick_h__> hatch: I went with teh clarity that this was the "juju repo"
<rick_h__> if upstream is more clean then I can change it. 
<rick_h__> but juju was "definitely not mine" where upstream could be read as "you mean my branch up on github right?"
<rick_h__> which is a fork of juju
<hatch> personally I think of 'upstream' because it's a direct upstream from our fork not a secondary repo - but I could see the confusion
<hatch> because you -can- add other unrelated remotes 
<rick_h__> k, yea I mean you can call it 'borky' or whatever you want :)
<hatch> right lol
<rick_h__> hatch: right, but there's only one 'juju' remote. The github/juju/ fork
<hatch> yeah
<rick_h__> anyway, tomato...tomato...crap that doesn't work so well in typing :)
<hatch> haha
<hatch> tomaeto tomaato
<rick_h__> man, I have to say, I'm loving having my tab complete in zsh all worky worky again. 
<rick_h__> completing my aliases, branch names, remotes, wheeee
<rick_h__> gary_poster: updated if you want to look again. 
<gary_poster> rick_h__, cool.  still commenting on old one :-P  will refresh in a sec
<rick_h__> gary_poster: oh sorry. 
<gary_poster> np!
<hatch> rick_h__ git rebase; git push -f :P
 * gary_poster proposes github :+1: == LGTM
<gary_poster> Because the thumb is so cute.
<hatch> lol
<rick_h__> hah
<hatch> only if we can use the pile of poo one for -1 
<gary_poster> heh, they don't have an auto-image for that do they?
<hatch> ð©
<hatch> in my font, it has eyes and a mouth
<hatch> lol
<gary_poster> ah yes, that is :poop:
<hatch> use :poop:
<hatch> right haha
<gary_poster> we can also use :water_buffalo:
<hatch> haha
<gary_poster> http://www.emoji-cheat-sheet.com/
<gary_poster> lol
<gary_poster> Campfire also supports a few sounds
<gary_poster>  /play trombone
 * gary_poster assumes this is sad trombone
<hatch> :shipit:
<hatch> we must use that, its like a hamster with a hat
<gary_poster> lol
<gary_poster> I could get behind that
<hatch> haha 
<hatch> :shipit:
<gary_poster> although I also like including things that make no sense and seem to require deep interpretation
<gary_poster> :moyai:
<gary_poster> easter island statue!  has t mean something important, right?
<hatch> lol
<hatch> ok and if it's so bad that there is no saving it :ambulance: 
<gary_poster> That implies that paramedics might do something.  I was also thinking :recycle: could be the last word.
<hatch> ok and for "your code is slowly killing me" :smoking:
<gary_poster> lol
<gary_poster> :no_good: goes back into cute territory, as does :person_with_pouting_face:
<hatch> haha
 * gary_poster departs land of emoji with :nail_care:
<gary_poster> rick_h__, oops, you kept my suggested comment explaining qa-pr's usage but dropped the example that it explained
<rick_h__> gary_poster: hmm, looking
<rick_h__> oh doh
<gary_poster> Looks good rick_h__ .  Thank you very much!
<rick_h__> thanks for the proofing and providing the 'average team expectation' 
<gary_poster> perhaps below average for the git stuff :-P but happy to help :-)
<rick_h__> well the "not in rick's automatic assuming head" space
<gary_poster> heh
<rick_h__> bah, quit sending your cold air down here hatch. It's too early for -19C wind chills. That's late Jan stuff. 
<hatch> heh it's -22C here right now w/o a wind chill so it must be warming up on the way down lol
 * rick_h__ holds back comments about the hot air as it passes hatch's house :)
<rick_h__> yea, only -12 here sans-wind chill
<gary_poster> lol
<hatch> haha
<hatch> -12 is still pretty cold if you aren't acclimatized for it
<bac> +1 on your s/LGTM/+1 gary_poster
 * bac dude applying sealant on roof is messing with my internet
<gary_poster> jujugui call in 10
<benji> jujugui: I have a branch up for review at https://codereview.appspot.com/40190043/
<benji> it has nice pre-review comments and everything.
<gary_poster> everything?  dancing reindeer?
<rick_h__> benji: but how for do we mrege this then? 
<rick_h__> merge that is
<benji> rick_h__: you tell me
<gary_poster> heh
<gary_poster> uh oh
<benji> I don't know nuthing 'bout merging no github.
<bac> rick_h__: ESL much?
<gary_poster> lol
<rick_h__> benji: by making a branch from your github fork and following the HACKING/process docs
<rick_h__> bac: :)
<benji> I must have missed the memo on the new process.
<bac> rick_h__: was there a git for bzr-tards doc?  i vaguely recall mention of one
<gary_poster> rick_h__, how would he do the bzr conversion?  export the diff from bzr and repply?
<rick_h__> benji: I'd be happy to walk you through the process
<gary_poster> reapply?
<rick_h__> gary_poster: yes, maybe generate a patch and then apply it to a feature branch from the git repo
<benji> rick_h__: I'll give it a shot and see if I have any questions.
<rick_h__> benji: rgr
<gary_poster> bac, HACKING doc is now pretty close to that because of my requests and rick's help
<hatch> jujugui lf a review/qa https://github.com/juju/juju-gui/pull/11
<bac> gary_poster: ok, great
<hatch> gary_poster I'll work on huw's branch right now 
<gary_poster> thanks hatch
<rick_h__> hatch: looking
<hatch> thanks
<hatch> http://www.git-tower.com/blog/git-cheat-sheet-detail/
<hatch> jujugui ^ 
<frankban> hatch: cool thanks
<gary_poster> I liked this one a lot
<gary_poster> http://ndpsoftware.com/git-cheatsheet.html
<gary_poster> keeps the info down
<gary_poster> and organizes it in a way that was helpful to me, at least
<hatch> that's pretty cool
<hatch> shows the flow
<gary_poster> right
<rick_h__> that's interesting
<Makyo> jujugui call in 2
<gary_poster> ty
<jcastro> hey rick_h__
<rick_h__> jcastro: yep
<jcastro> are you still "in charge" of the rating page on manage.?
<rick_h__> jcastro: not really, it's not on the immediate map atm so not sure who's 'in charge' of it
<jcastro> ok
<jcastro> gary_poster, https://bugs.launchpad.net/juju-gui/+bug/1257878
<_mup_> Bug #1257878: Revise charm feature bullets <juju-gui:New> <https://launchpad.net/bugs/1257878>
<jcastro> can we put that on some map somewhere?
<gary_poster> jcastro, will look soon still on call
<jcastro> yeah no rush.
<jcastro> I will keep track of the ratings for each charm in the audit by hand for now, it's not a rush thing
<jcastro> so like, doesn't need to be this year, but april would suck. :p
<gary_poster> heh ack
<gary_poster> btw jcastro we are trying to treat your cloudfoundry issue--not coming up in searches on mjc--as urgent.  Is that correct from your perspective?  That is, it is very important that it be fixed within the next few days?
<gary_poster> we think it is probably urgent anyway because it makes us nervous :-P but just wanted to check in with you
<jcastro> well, considering we're in beta
<jcastro> it's not that bad
<gary_poster> ok
<jcastro> really we're the only ones using bundles
<gary_poster> ok cool
<gary_poster> we'll hopefully get it fixed in a few days anyway
<gary_poster> benji, is this a trivial change? https://bugs.launchpad.net/juju-gui/+bug/1257878 .  AIUI we can simply trash the existing data on charm features, and then reset the schema to the given one
<_mup_> Bug #1257878: Revise charm feature bullets <juju-gui:New> <https://launchpad.net/bugs/1257878>
 * benji looks
<gary_poster> IIUC this is entirely in charmworld
<rick_h__> gary_poster: benji we have to watch the form generation stuff. It expects a specific format and then a migratino to clear/reset the data in the charms themselves. 
<gary_poster> vague ack :-P
<benji> gary_poster: it will at least be non-hurculean, it will likely be not too bad
<gary_poster> benji, heh ok.  I'll add that to the "high" list, jcastro.  Hopefully done before winter break
<hatch> rick, does dolla-dolla-merge need to be the only thing in the message? 
<hatch> rick_h__ ^
<hatch> very cool WestJet video https://www.youtube.com/watch?v=zIEIvi2MuEk
<gary_poster> hatch, no it does not
<hatch> jujugui 792 views so far of my chat with the YUI guys
<gary_poster> cool!
<hatch> apparently that's double the most viewed other round table so far
<hatch> and it's not even a week old haha
<bac> hatch: i was out last week when you did it.  url?
<rick_h__> hatch: no, just in the message
<benji> ooh, git status --porcelain where have you been all my last-20-minutes
<hatch> bac http://www.youtube.com/watch?v=lJPdH8xmOWg
<jcastro> hatch, hey this video is cool
<jcastro> I am going to share it
<jcastro> hatch, also. Pocket Trains. 
<hatch> jcastro :) thanks!
<hatch> lol!
<hatch> still playing that hey?
<hatch> jcastro you must have all of the continents now?
<jcastro> no, still in europe
<hatch> whaaa? How is that possible lol
<jcastro> I am not travelling enough to be on my phone that often
<hatch> ohh haha
<hatch> someone wake huw up
<rick_h__> hatch: lol
<rick_h__> call his butler for an early morning wake-up all?
<rick_h__> "you need to get the president up, it's important"
<hatch> yeah!
<hatch> there is some uncommented funkyness in the code which when I 'fix' it it breaks
<hatch> so /me is confused
<Makyo> Oh man, this unit list thing is so broken :/
<dimitern> hatch, fyi here's the CL with charm upload support https://codereview.appspot.com/40290044/
<hatch> dimitern cool I'll take a peek
<hatch> thanks
<hatch> Makyo uh oh....details?
<dimitern> hatch, i'll land it tomorrow though, i'm already +18h in today
<dimitern> :)
<hatch> haha you go!, what time is it there?
<dimitern> it's 8.14 pm and i started like 4.30 am
<hatch> oh so that's why you were up when I was just going to bed :D
<Makyo> hatch, when we build up the categories of units, we're passing references to units into the lists; we then add category information to each unit.  When a unit is in multiple categories (as with landscape + running/etc), the category information is overwritten when it's added, since the unit is a reference, not a value.
<Makyo> Going to see about storing the unit as a member of an object along with the category information, rather than injecting it in like that.
<hatch> *facepalm*
<rick_h__> lol
<dimitern> hatch, yep
<hatch> I have to admit, huw's technique is pretty darn smart
<hatch> now if I could just figure out why it won't work on the search results
 * hatch shakes fist at rick_h__  for making them different views
<rick_h__> hatch: huh? they share a common base. 
<rick_h__> only difference is one has two containers and interesting has 3
<rick_h__> hatch: let me know if you need some eyeballs
<hatch> right - they are separate views instead of the same view with different content
<hatch> it's actually the 'home' button causing the issues
<hatch> but it's easier to blame the whole stack :P
<rick_h__> ah, well yea the home button is a tacked on thing due to keeping state in order
<rick_h__> hatch: branch up to peek at?
<hatch> ahh it's just fixing css stuff
<rick_h__> selectors just a hair off?
<benji> jujugui: after a little work and a break for lunch I have my branch up for review on github: https://github.com/juju/juju-gui/pull/12
<rick_h__> benji: looking
<benji> thanks
<hatch> rick_h__ the odd positioning in the sidebar to make the scrollbars work is causing the calculations in the sticky headers to be way off when there is the home button
<rick_h__> hatch: oh, yea, gotcha
<rick_h__> hatch: so nothing to do with different views at all, it's with UX changes that are legit :P
<hatch> rick_h__ except if they were a single view, it would be done already lol
<rick_h__> carry on blaming something else
<hatch> haha
<rick_h__> hatch: except that then it wouldn't work because it'd have this conditional home button thing to deal with
<hatch> that's fine - huw would have figured that out first :P
<rick_h__> hah
<rick_h__> benji: does the repeated setting of PYTHONPATH actually append? 
<rick_h__> benji: I see it was that way before I guess, but I'd have assumed each would overwrite the others
<rick_h__> bah, it's making a call on each one, ignore me
<benji> :)
<rick_h__> benji: LGTM with a note on the firefox dep. Ideally it could use phantom for that maybe?
<benji> rick_h__: I replied about the firefox dependency.  Do those go to email?
<rick_h__> benji: yes, and I replied again
<rick_h__> :)
<benji> ah, cool
<rick_h__> hah, thanks benji, /me goes to re-uninstall firefox
<benji> :)
<rick_h__> I missed the updated commit coming in as I was looking at it
<hatch> annnd fixed
<hatch> I'm still going to wait to commit it until I can document some of these weird sections from huw
<Makyo> Alright.  Down to 1.5s to open inspector with 2000 units, no delays in update..
<benji> rick_h__: do I literally write "$$merge$$" as a comment on the pull request?
<rick_h__> benji: yes
<rick_h__> benji: anywhere in the comment will do
 * benji prepairs a wall of text with "$$merge$$" hidden in the middle.
<rick_h__> :)
<hatch> Makyo right on! 
<rick_h__> if settings.get('jenkins.merge.trigger') in message: 
<hatch> I'm very intersted to see the code now
<hatch> oh Firefox you irritate me
<Makyo> It's the same filter, but on object attributes instead of DOM nodes, which I gather is the preferred way to filter; however, pushIntoUnitList now uses the unit as an attribute, rather than as the base object.  
<hatch> ahh
<hatch> so was there something wrong with what I did? or was it just the way we were passing the data in did not allow it to work?
<Makyo> Your solution was okay given the way the data was being passed in, but I think that structure was wrong for d3, and also wrong because of pass-by-reference.  Better to let the framework do what it's good at then try and force it to do something it's not.
<hatch> true good point, thanks for making it work :)
<gary_poster> Makyo, "no delays in update" is huge.  cool.
<Makyo> Yeah.  Now just to make tests work :T
<hatch> crap forgot to rebase before pushing
<hatch> oh well, next time
<hatch> jujugui lf review/qa on the refactor of huws sticky header branch https://github.com/juju/juju-gui/pull/13 
<hatch> ya know what....I'm going to try and rebase this...
<hatch> yeah rebase isn't gona happen
<hatch> to many intermixed commits :/
<gary_poster> hatch, looking
<hatch> thanks
<jcastro> hey gary_poster
<jcastro> so don't hate me, but I upgraded to trusty today
<gary_poster> hey on call
<jcastro> and all the good stuff in the PPA is missing on trusty, just FYI
<jcastro> no worries, I like just typing in the channel, that way I can assume you are agreeing
<gary_poster> lol
<gary_poster> ack
<hatch> haha
<gary_poster> will investigate
<jcastro> marco just updated the charm tools PPA
<jcastro> I figure, we'll have to do it anyway
<jcastro> and also, FYI, we kicked off the charm audit today though it won't affect you
<jcastro> but you should start seeing updates to charms, READMEs, and a bunch of little things
<Makyo> Dogwalk, then pull request adventures.
<huwshimi> Morning
<arosales> gary_poster, et all should I see a relation line between wordpress and nagios for a "juju-info" relation?
<gary_poster> arosales, that's typically a subordinate
<arosales> I see a relation line for mysql and nagios for a "monitors" relation
<gary_poster> you see those by hovering over the wiggle thingon the subordinate
<gary_poster> or by clicking on it
<arosales> gary_poster, it doesn't looks like its being deployed by the gui as a sub
<gary_poster> arosales, I thought nrpe was the subordinate for that case?
<arosales> gary_poster, nrpe can be a sub to a service
<arosales> that nagios can connect to, I think
<arosales> but I don't see a clear way to make nagios a sub of wordpress, at least from the gui
<gary_poster> arosales, I don't think you are supposed to.  I think you are supposed to make nrpe a sub of worspress and then connect nrpe to nagios
<gary_poster> arosales, I have to go.  if you can confirm, then please file a bug and we will investigate.  AFAIK we are doing the right thing here, so please give me details if we are not
<gary_poster> hatch, I ended up with calls :-(
<gary_poster> and I have to go now
<hatch> ok no problem
<arosales> gary_poster, ok thanks
<arosales> I see nagios looks to be a sub of mysql, but it isn't displayed in the canvas . . .
<gary_poster> hatch I was going to look at consider whether we should do any of the operations on headings in aggregate before doing the calculations.  a probably wrong hunch, but that's been necessary for correct calculations in the past.  Otherwise I like how you structured the code.  Please consider you and Huw as reviewers: if Huw approves what you've done and can qa and branch is < 400 then :+1: :-)
<hatch> thanks, I'll take a look at your notes
<hatch> huwshimi here is the refactored branch https://github.com/juju/juju-gui/pull/13
<gary_poster> arosales, nagios has a "monitors" relationship with mysql, not a subordinate
<hatch> it's been cleaned up a bit but you'll notice that the functionality is still identical
<huwshimi> hatch: Thanks so much for taking that on!
<arosales> gary_poster, ack with mysql, but sub with wordpress
<arosales> which isn't shown in the canvas
<arosales> gary_poster, I'll let you go
<gary_poster> ok ttyl
<arosales> perhaps I can bother hatch or someone else willing to confirm.
<hatch> arosales sorry I haven't been following....one sec
<arosales> hatch basically
<arosales> from the canvas
<arosales> jujucharms.com
<arosales> drag in wordpress
<arosales> drag in nagios
<arosales> relate the two
<hatch> ok
<arosales> ~should~ I see a subordinate relationship between the two?
<arosales> right now I see nothing in chrome and firefox
<arosales> wondering what is the expected behavior
<hatch> hmm that's a good questioin
<hatch> give me a minute here to take a look
<arosales> hatch, I would have expected to see the "squiggle-line" subordinate relation
<arosales> if in fact the relation between wordpress and nagios is a sub
<arosales> hatch, thanks
<hatch> I'm going to agree with you that there should be 'some' type of relation line there
<hatch> as far as the GUI can see it's related as a subordinate on juju-info
<hatch> however I'm not sure if this is how nagios is supposed to work
<hatch> but I suppose that's beside this issue
<hatch> there 'should' be some indication that there is a relation there
<arosales> I am indeed may be using it incorrectly, but as you said from juju there is a valid relation between the two which I am not seeing
<arosales> hatch, are you saying I probably should not be able to build that relation?
<hatch> arosales if you deploy nrpe-external-master and relate it to wordpress you will see the line when you hover over the little squiggle thing
<hatch> well you should be able to, but I'm not sure if it will actually work
<hatch> I'm just looking at the charms metadata right now
<arosales> hatch, ok different scenerio
<arosales> hatch, https://jujucharms.com/sidebar/search/precise/nagios-4/?text=nagios#bws-readme
<hatch> ahh ok I see the issue
<arosales> in this case you can add a relation between an microblog (statusnet) and nagios
<arosales> per the readme
<arosales> *but* the relation is not shown on the canvas
<hatch> the nagios charm doesn't specify the `scope` as `container` so we have no idea that it's a subordinate relation 
<arosales> I can inspect the service and se there is a relation, but that is the only way
<hatch> so this is definitely a bug in the GUI
<hatch> one which I'm not sure we have a UX story for however :)
<arosales> when I click on wordpress
<arosales> and I look at the relation to nagios
<hatch> the relation between wordpress and nagios is 'valid' but it's on juju-info which we don't show
<arosales> i see the scope as "container"
<arosales> interface "juju-info"
<hatch> it's not showing as a subordinate because nagios doesn't say its a subordinate
<hatch> right....so actually....there are a few issues here
<hatch> 1) no relation line is showed because we don't show juju-info relations
<hatch> 2) nagios is connecting to wordpress using juju-info which is specified as a container scope....but this is not a subordinate relation
<hatch> s/few/couple :)
<arosales> per 1) the relation line would be shown _if_ it were a sub correct?
<hatch> right 
<arosales> hatch, note the statusnet and nagios have the same relationtype
<arosales> per the readme
<hatch> so should we be showing juju-info relations?
<arosales> I guess that is the fundamental question
<arosales> there is a relationship
<arosales> and it has to be made
<hatch> I THINK the issue is with the nagios charm in this case
<hatch> it's specifying a juju-info relationship for other nagios clients
<hatch> and we are connecting wordpress to it
<arosales> I would think if someone linked up the service and it is shown in the inspector it should be represented somehow on the canvas
<hatch> at least as far as I understand how this is supposed to operate
<arosales> hatch,  check the statusnet readme
<hatch> checking
<hatch> statusnet charms don't have a readme
<arosales> hatch, sorry the nagios readme references statusnet
<arosales> https://jujucharms.com/sidebar/search/precise/nagios-4/?text=nagios#bws-readme
<hatch> ok checking
<arosales> to connect it up to via a juju-info relation
<hatch> it can only have a single juju-info relation
<hatch> funny those two lines lined up exactly....
<hatch> heh anyways!
<arosales> ok
<arosales> but still not shown on the canvas 
<hatch> if we are allowing the relation to be made we should be showing it
<hatch> I'm not sure 'how' we want to show it though....
<hatch> it IS a real relation I suppose
<hatch> so that would be my guess
<arosales> if I just deploy statusnet
<arosales> and nagios
<arosales> and relate them
<hatch> you should see a line
<arosales> I see now indication on the canvas they are related
<hatch> oh I don't
<hatch> haha
<arosales> only via the inspector do I see an indication of a relation
<hatch> oh s/now/no
<hatch> right
<hatch> we should show a line
<arosales> or something to signal a relationship has been made
<hatch> I THINK it's supposed to be nagios > nrpe > wordpress
<hatch> but that's not up to us as the tool
<hatch> we should just show what's happening and leave it up to the user to know not to relate things incorrectly
<hatch> so to answer your question....yes this is a bug :)
<arosales> ok
<hatch> are you going to create the ticket or would you like me to?
<arosales> I can create it later tonight
<arosales> I was actually preping for a demo tonight on showing the bundle to our user group
<hatch> ohh, sorry :)
<arosales> over 100 folks planning on being there and I was wondering why I didn't see these relations.
<arosales> no worries I am probabaly just not connecting them up right ;-)
<arosales> all the other bits are there
<arosales> hatch, ping me if get the ticket created. If not  I will create one.
<hatch> ok sounds good - you probably want to deploy nrpe, relate it to wordpress (the squiggly thing will show the relation lines) and then relate nrpe to nagios
<hatch> but what do I know lol
<arosales> we should update the nagios readme if that relation build between nagios and blog is indeed incorrect, or better recommend via nrpe
<arosales> hatch, thanks for the help.
<hatch> no problem, anytime
<hatch> arosales here is the bug https://bugs.launchpad.net/juju-gui/+bug/1259720 feel free to expand with any thoughts or feelings on the matter cc gary_poster 
<_mup_> Bug #1259720: Services related on juju-info don't show relation lines <juju-gui:New> <https://launchpad.net/bugs/1259720>
<arosales> hatch, thanks
<hatch> huwshimi do you have IE on your new machine yet? for qaing the sticky header branch?
<huwshimi> hatch: Yep, just moved my vm over
<hatch> cool, gota love that :)
<huwshimi> hatch: Is that ready for me to review now?
<hatch> yep ready to go
<huwshimi> hatch: How do I get the branch for QA?
<hatch> in your current repo type
<hatch> git checkout -b hatched-sticky-header-redux develop
<hatch> then
<hatch> git pull https://github.com/hatched/juju-gui.git sticky-header-redux
<hatch> then you are gtg
<hatch> I gota take off for a bit
<hatch> I'll check back in later
<huwshimi> thanks
<hatch> back huwshimi were you able to get it pulled down?
<huwshimi> hatch: Yep, thanks!
#juju-gui 2013-12-11
<Makyo> Rebase hates me.  Anyway.  jujugui lf review/qa (sandbox, 2000 units, watch the inspector for delays) https://github.com/juju/juju-gui/pull/14
<hatch> i'll take it
<gary_poster> thank you.  also looking at it but won't have time for review
<hatch> heh this diff is very confusing
<hatch> hmm Makyo  very intersting
<gary_poster> Makyo, hatch, I'm seeing maybe a half second shaved off of the pauses as I scroll with 2000 units if I compare local repo with comingsoon.  Is that what I should expect to see, or do you expect the change to be more dramatic?  Maybe I did something wrong
<Makyo> gary_poster, not seeing any pauses, here..
<gary_poster> Makyo, ack. :-/ I looked at app/views/viewlets/service-overview.js and saw changes you have in the diff
<gary_poster> so I do have your changes
<gary_poster> I can try make clean
<gary_poster> nope, no change
<Makyo> Takes 10s for 2000 units to render on comingsoon for me,  1.5s locally.  No delays scrolling in either, though.
<gary_poster> ah, weirdness: filesystem says one code, but browser says another
<gary_poster> trying something
<gary_poster> no
<gary_poster> weird!  Makyo good news is that it's something on my system :-/
<gary_poster> Makyo, awesome!  weird cache issue on my side; has not happened in a long while.  had to clear cache.  Sorry for false alarm.  Looks great!
<gary_poster> I need to grok the branch tomorrow so I can see what you mean by your comments
<Makyo> Oh!  Cool :)
<Makyo> Yeah, np
<gary_poster> Makyo would you mind explaining what you did to the team on the Friday call, as a way of giving us all d3 insight?
<Makyo> Definitely.  Will make a card with notes for myself.
<gary_poster> thank you
<gary_poster> made card.  please feel free to take over :-)
<gary_poster> running away.  have a good night!
<bac> hi frankban
<frankban> morning bac 
<bac> frankban: since you are the world's expert on using Mock and MagicMock could you give me a hand with mocking 'open'?
<frankban> :-)
<bac> frankban: i've got this test:  http://paste.ubuntu.com/6555806/ -- the MagicMock that is returned by the mocked open is not being called.
<bac> if i step into the function, the fd returned from the mocked open is a MagicMock and it is being called, but the  object accessible in the calling context is not.
<frankban> bac: does it work using '__builtin__.open'?
<bac> i've tried using michael's instructions here: http://www.voidspace.org.uk/python/weblog/arch_d7_2010_10_02.shtml#e1188
<bac> i've not tried builtin.  good idea
<gary_poster> frankban, fwiw I am reviewing your branch
<frankban> gary_poster: thank you!, Brad will start the second review in minutes
 * frankban lunches
<dimitern> gary_poster, hatch, hey guys
<gary_poster> hey dimitern .  thanks for work on charm upload: looking cool
<dimitern> gary_poster, hatch, we had a bit of discussion about the charm upload implementation
 * gary_poster listens
<gary_poster> hatch is probably still sleeping in his timezone
<gary_poster> or at least not started yet
<dimitern> gary_poster, hatch, and some concerns were raised that using multipart/form-data, while being more standard-based is less efficient for bandwidth due to the encoding required
<gary_poster> so this POST vs PUT?
<dimitern> no matter, at leas he'll be pinged and see the conversation later if i include him :)
<gary_poster> :-) cool
<dimitern> so, encoding a sub-10MB charm inside a multipart form is not a big deal (some 25% increase in size)
<rogpeppe> gary_poster: the question is: is it hard for you to generate a POST with an application/octet-stream body containing the zip file?
<dimitern> but I'm told we expect much bigger charms
<dimitern> i.e. a binary, non-encoded body
<dimitern> ^ re rogpeppe's question
<dimitern> gary_poster, the content-type is not a big deal, but 'd prefer it to be application/zip, so we can bail out earlier with a nicer message
<gary_poster> dimitern, rogpeppe needs research.  trying to do it quickly.
<dimitern> gary_poster, otherwise we're still extracting the archive and reporting any errors, but in a more generic fashion (i.e. "invalid charm format: zip: no header found" or something like it)
<rick_h__> compressing client side will be tough
<dimitern> rick_h__, I thought we already have the zip packaged before the upload?
<gary_poster> rick_h__, this is about octet
<rick_h__> gary_poster: oh, ok nvm. 
<gary_poster> rick_h__, we will be provided zip *and* there appears to be nice JS zip lib for converting floders to zips
<gary_poster> rick_h__, http://stuk.github.io/jszip/
<dimitern> also one thing to keep in mind is that we'll be respecting the revision specified in the charm, if possible - i.e. non-conflicting with another charm in state
<dimitern> otherwise we'll bump it to the highest in state +1
<dimitern> the bumping also occurs if the revision in the charm is lower than the highest in state for the same charm
<gary_poster> I like that bit dimitern; I assume the API will give us feedback as to what revision was actually used, so we can report back
<dimitern> gary_poster, yes, if you look at the specs https://docs.google.com/a/canonical.com/document/d/1TxnOCLPDqG6y3kCzmUGIkDr0tywXk1XQnHx7G6gO5tI/edit#heading=h.t7svtxl846ha 
<dimitern> brb doorbell
<rogpeppe> gary_poster: yes, the return from the POST is the charm url which includes the new revision number
<gary_poster> great
<dimitern> yes
<gary_poster> dimitern, rogpeppe I *think* we can do application/zip and application/octet-stream.  We will need to test it on supported browsers, I think, because I don't find a clear cut answer in my searches.  Worst case, though, would be that you have two or three mini-paths, one for zip, one for form-data, and maybe one for octet-stream.  That doesn't sound too bad?  We can give you concrete answer be EoD today as to the res
<gary_poster> t?
<rogpeppe> gary_poster: it would be nicer if we could avoid the multipart stuff entirely
<gary_poster> rogpeppe, of course
<gary_poster> rogpeppe, dimitern, so, we will research and give you concrete answers first investigating application/zip (your pref); and then application/octet-stream if we run into trouble with the first.  We will report back today.  Sound good?
<rogpeppe> gary_poster: sounds good to me. personally, i'd be more than happy with just application/octet-stream - i can't really see much added benefit from checking the content type, as filesystems don't usually store that.
<gary_poster> ack
<dimitern> gary_poster, great
<gary_poster> cool thanks for update dimitern and rogpeppe.  talk to you soon
<dimitern> gary_poster, so, just that you know - I changed the specs to reflect the final version which will be implemented
<gary_poster> dimitern, I saw, and also shared it with rest of gui team
<dimitern> gary_poster, the most important change is that the body needs to be binary, the Content-Type is not crucial, pending your verification
<gary_poster> ack
<dimitern> gary_poster, cheers
<gary_poster> :-)
<hatch> morning
<gary_poster> hey hatch.  read backlog for me and I bet you can figure out what I'd like you to answer/research ;-)
<hatch> on it!
<gary_poster> thanks hatch
<hatch> gary_poster so the question is, can we upload uses an octect-stream?
<hatch> answer is yes
<gary_poster> hatch, on POST as well?
<hatch> yep
<gary_poster> hatch, great.  includes Safari?
<hatch> just confirming safari
<gary_poster> cool
<gary_poster> hatch also do you want a review of the sticky headers thing?  looks like huwshimi gave you an unofficial +1
<hatch> sure, somehow I ended up with over 100 emails lastnight, still going through them
<gary_poster> :-) k.  and are you in the middle of a review of Matt's performance branch, or should I take that too?
<hatch> going through it 
<hatch> another bug with someone using the autocomplete as search results
<hatch> heh
<hatch> man there is like 0 documentation on safari
<bac> gary_poster, frankban: sorry for the vague zope reference, i was thinking instead of the auto-ui generation aspect.  that said, my lack of understanding of the roadmap shouldn't reflect negatively on the work.
<rick_h__> hatch: yea, at least we've got a plan on that one, just not done it yet
<gary_poster> bac, cool
<bac> gary_poster: and i did use a smiley, which covers many sins.
<gary_poster> bac :-) <- sins covered
<frankban> bac, gary_poster: the reports of me rewriting zope have been greatly exaggerated
<gary_poster> lol
<bac> :)
<bac> frankban: it did seem to come from an unlikely corner
<hatch> gary_poster so I can't find anything to confirm/deny the support for octect-stream in safari post - I can hack together a quick node script to test today if you would like
<gary_poster> hatch +1 please thank you
<gary_poster> hatch, for my own knowledge, where did you confirm octet-stream for chrome et al?
<hatch> I just read a few stackoverflow posts where people were having issues with it
<gary_poster> heh ok
<gary_poster> my google fu was merely insufficient :-)
<hatch> it's ok, it happens :D
<gary_poster> hatch qa of sticky headers is good.  one idea: the only mildly annoying flickers I see on Ubuntu are chrome, for the top header.  Can we apply the sticky CSS to the top header as soon as the box is drawn?
<frankban> bac: yeah, no. the goal is to have a something to describe fields: gary_poster is right we could do that without classes (a namedtuple seems a good candidate). in this case classes seemed to me more natural: they provide a namespace and a factory (__init__). re auto-ui generation: yes those fields will be eventually used to render/validate the urwid env edit form. AFAIK this can be considered similar to zope schem
<frankban> as, and to a variety of other python libraries (django.form, wtform etc.)
<hatch> I think that should work
<hatch> there is also a very odd bug that huw found 
<hatch> I'll work on those, did you want to take Makyo 's branch? :)
<gary_poster> hatch, sure :-)
<bac> frankban: sure, thanks for the explanation
<gary_poster> hatch lots of comments and suggestions, but +1.  happy to re-review if desired,
<gary_poster> but not necessary.
<hatch> thanks
<hatch> I fixed the flash in chrome
<gary_poster> awesome
<hatch> I think that this sticky header code nowhas more lines of comments than code
<hatch> hah
<gary_poster> +1 :-)
<hatch> so much for self documenting code lol
<gary_poster> maybe my scrollOffset comment was too much.  <shrug>
<hatch> thats only 1 line 
<hatch> haha
<hatch> the comment that broke the developers back?
<gary_poster> :-P
<frankban> gary_poster: what do you think about required=False, readonly=False, and then required must be explicitly passed when creating fields?
<gary_poster> frankban, I like it.
<frankban> gary_poster: the validation is not completely duplicated between the Int and the base fields: the base would complain about 0, but I see your point
<gary_poster> cool
<hatch> gary_poster when qa'ing Makyo's branch you said that you didn't feel it was more performant? If you want something to compare it to, my branch removes the filters entirely - albeit it has bugs but it'll give you something to compare to.
<benji> rick_h__: is the staging charmworld supposed to ingest regularly?  http://staging.jujucharms.com/heartbeat shows that it hasn't since the 8th
<rick_h__> benji: hmm, yes I believe so. I'ts using the same cron from the charm as production unless someone turned off the cron job. 
<benji> k
<Makyo> hatch, it sounds like gary_poster ran into a cache issue, was better after clearing.
<hatch> ohh ok 
<gary_poster> hatch, thank you.  it turned out to be a caching issue in my browser.  not sure why it triggered.  once I cleared out cache, the code really had a huge & impressive speed increase.  Seems like only slowdown is in simulator
<gary_poster> now
<hatch> awesomer!
<gary_poster> on the order of a fraction of a second, and barely noticeable
<gary_poster> yeah definitely
<hatch> little bummed that I don't get to write a new implementation
<Makyo> :T
<hatch> but maybe we'll have to support 10,000 at some point
<hatch> :P
<gary_poster> :-P
 * gary_poster kinda loves seeing pr tests and $$merge$$ work
<hatch> yeah I just wish $$merge$$ wasn't so ugly to look at lol
<Makyo> jujugui call in 10
<gary_poster> ty
<gary_poster> hatch, heh, yeah, I suspect patches welcome if we all agree on something
<hatch> I'd even go for ::merge:: tbh 
<hatch> :D
<gary_poster> <shrug> not huge imporovement to my eyes, but fine with it if team wants
 * gary_poster wishes he remembered ins and outs of Y.merge better
<hatch> merge is the easy one, it's mix() that's the impossible one :)
<hatch> Y.merge(object[,object]) 
<gary_poster> ah right
<hatch> Y.mix(who-the-heck-knows)
<gary_poster> in merge, which wins?
<hatch> last in the line wins
<gary_poster> right
<gary_poster> thx
<hatch> nooooo problem
<rick_h__> gary_poster: hatch it's a .ini config key + a doc change. Just say what you want it to be.
<gary_poster> :poo:
<hatch> +1
<Makyo> jujugui call in 2
<Makyo> +1
<gary_poster> ty
<Makyo> I'm glad github comments support both :shipit: and :shit:
<Makyo> benji, starting
<benji> coming
<gary_poster> frankban, https://plus.google.com/hangouts/_/calendar/Z2FyeS5wb3N0ZXJAY2Fub25pY2FsLmNvbQ.j0rk5d371ph8331ijtf48t2uj0
<gary_poster> benji rick_h__ https://plus.google.com/hangouts/_/calendar/Z2FyeS5wb3N0ZXJAY2Fub25pY2FsLmNvbQ.j0rk5d371ph8331ijtf48t2uj0 ?
<benji> yep
<hatch> hey benji, why chiropractor and not massage? 
<Makyo> It's rare enough that a webpage has an Esperanto translation that I'm always surprised by it, and remember that Chrome thinks that's my language for some reason.
<Makyo> In other news, our Jenkins install has an Esperanto translation :P
<hatch> haha oh Esperanto
<hatch> I remember the Esperanto bug
<Makyo> gary_poster, hatch okay with one review/qa, or should I request another?
<hatch> I can do another if you need but the code looked good to me with gary's suggestions
<hatch> another qa that is
<Makyo> hatch, I'd appreciate it.
<hatch> ok on it
<Makyo> Sorry, was doing canonicaladmin stuff
<hatch> best UX ever in that app
<Makyo> Hope I did the end-of-year closure thing right.
<Makyo> Hah
<hatch> lgtm'd
<Makyo> Thanks.
<hatch> gary_poster octet is supported across all of our browsers
<hatch> on post
<gary_poster> awesome, thank you
<gary_poster> hatch, I will send a note to dimiter and rogpeppe cc'ing you
<hatch> sure thanks, I'll upload the repo so anyone can test if they like
<rogpeppe> gary_poster: cool
<rogpeppe> hatch: so it's not a problem to upload a zip file as an octet stream with content-type of application/zip ?
<hatch> well we can set whatever as a content type
<hatch> I just tried streaming a file via post from all of our supported browsers
<hatch> I used application/octet-stream
<hatch> looks good here with application/zip
<hatch> I'll push this repo up so you can see
<hatch> https://github.com/hatched/octot-test rogpeppe  gary_poster 
<gary_poster> octot?
 * rogpeppe likes "octot"
<gary_poster> :-)
<gary_poster> thanks hatch
<hatch> lol typo and I didn't care to change it haha
<gary_poster> hatch, reply to my mail with link pls?
<hatch> will do
<gary_poster> ty
<Makyo> Hahah
<Makyo> I'm keeping octot. It's perfect.
<hatch> lol perfect for what?
<Makyo> I dunno, but it beats out octet at whatever it is.
<Makyo> Probably perfect for GitHub, actually.
<hatch> haha
<Makyo> Octotcat.
<hatch> Github no longer restricts repo names
<hatch> they are namespaced now
<hatch> so multiple people can have the same repo name
<Makyo> It's been that way since I started using it, at least.
<hatch> ohh, maybe I'm remembering some very legacy stuff
<hatch> and it just stuck
<hatch> ok now what to do....what to do.... *closes eyes and spins around*
<hatch> looks like I'm removing more full browser
<rick_h__> hatch: there's the search bug 
<hatch> search bug?
<hatch> you mean that it doens't work like anyone expects it to?
<hatch> lol
<rick_h__> hatch: yea, quicksearch filting to only showing one result per charm name with importance weighed in like search results
<hatch> was that triaged as higher priority than the browser stuff?
<rick_h__> hatch: well, at first I thought you were asking
<rick_h__> hatch: and it bugs me so if you fix it I get to :) 
<hatch> haha
<hatch> well I should probably continue on my path of browser stuff
<hatch> gary_poster in the hangout, whenever you're ready
<bac> oh, yay, the charmworld charm is all bash.
<bac> hey benji, if you have a moment could you see if you can successfully 'juju status' to staging.jujucharms.com after 'source orangify'?  i'm getting TLS handshake errors.
<benji> bac: sure, let me try
<bac> ty
<benji> bac: "source orangify" is generating an exception for me
<benji> and I have to go to an appointement, like 5 minutes ago :)
<benji> sorry I couldn't help
<bac> np
<hatch> holy so much code removal
<hatch> and only 3 test failures
<hatch> w00t
<hatch> rick_h__ hey are you around?
<hatch> jujugui looking for two reviews and qas on the fullscreen code removal branch (1242ln diff)
<hatch> 99% removals
<Makyo> hatch, on it \o/
<hatch> thank yas!
<Makyo> Have a PR?
<hatch> oops
<hatch> https://github.com/juju/juju-gui/pull/15
<hatch> :)
<hatch> forgot to paste
<gary_poster> will look soon after bug triage, if no one else has taken
<gary_poster> hatch, still triaging, but 1,173 deletions: awesome :-)
<hatch> yeah, that was a lot of code haha
<hatch> the paths are still overly complex but we can now work on simplifying them 
<gary_poster> cool
<gary_poster> Makyo, in a shocking move, I accepted your Christmas holiday vacation request
<hatch> lol
<gary_poster> thanks for filing :-)
<Makyo> !!!
<Makyo> Thanks :_
<Makyo> :)
<hatch> what we get Christmas holidays? 
<hatch> NO WAY!
<Makyo> I needed to see how many days would roll over for the convention trip in January.
<hatch> oh what convention?
<rick_h__> hatch: howdy
<Makyo> Sci-fi/furry :P  Giving a talk on data collection and visualization.
<hatch> http://www.scififur.net/forum/forum.php ?
<Makyo> http://www.furtherconfusion.org/2014/
<hatch> coolio, are you dressing up?
<Makyo> At some point, sure, but not during the talk.  Too much to deal with.
<Makyo> Want to tool around the bay area a bit, too, eat at all the neat places we don't have here in town.  I know it's basically fast food there, but we don't have any ramen shops here :T
<hatch> haha - I buy ramen in dry plastic wrapped cubes
<hatch> aka ichiban!
<hatch> lol
<Makyo> Pff!  I do too, but after going to a few real ramen places out there, I'm hooked on that.
<hatch> we are starting to get a lot of 'foodie' type restaurants here but none really have the level of quality i've come to expect from places on my travels which is unfortunate
<Makyo> Yeah, for sure.  There are a few cropping up in town, thankfully, but some stuff is underrepresented.  Korean food, notably: we have a pretty big Korean population, but the restaurant that's owned by a Korean family mostly just serves sushi.
<hatch> that's...odd...heh
<hatch> you can tell the best asian restaurants here really easily
<hatch> if they are full of white people, it's probably not very good :D
<hatch> it's like "ohh this is WESTERN Chinese food"
<hatch> haha
<Makyo> There's a place here that helps with work visas for people, so their food is amazing.
<Makyo> It's pretty cool, from what I've heard.  They help a family with work visas, find housing, and so on.
<rick_h__> man hatch you're killing me. Realizing just how much code and tests went into making fullscreen happen. 
<hatch> rick_h__ yeah only like 1200 lines worth :P
<rick_h__> is that what the diff is? ugh
<rick_h__> I'm happy to see it go, but painful as well
<hatch> haha yeah, sorry :) but I must admit, it was was easy to remove
<hatch> so you did a good job modularizing everything
<rick_h__> :)
<gary_poster> rick_h__, when you get a chance, could you comment as to whether you think https://bugs.launchpad.net/juju-gui/+bug/1259704 should be addressed in charmworld or gui?  If gui, would like to ask huw to fix it quickly.
<_mup_> Bug #1259704: Bundle branch command incorrect. <juju-gui:Triaged> <https://launchpad.net/bugs/1259704>
<rick_h__> gary_poster: rgr
<gary_poster> rick_h__, thank you (tomorrow is great!)
<gary_poster> hatch, I won't be reviewing; have to go
<gary_poster> bye all
<rick_h__> have fun
<hatch> gary_poster no problem, cya
<Makyo> hatch, code's good, going to walk dogs then QA
<hatch> great thanks
<hatch> morning huw
<huwshimi> Mornign
<huwshimi> *Morning
<rick_h__> hatch: the reroute or something is breaking onboarding
<hatch> rick_h__ repro steps?
<rick_h__> hatch: clear your localStorage, go to /
<rick_h__> hatch: to see it work, clear your localStorage go to /sidebar
<rick_h__> hatch: this is in trunk, not your branch atm
<hatch> ohh ok 
<hatch> so a separate card then
<rick_h__> hatch: I'm guessing it's part of the redirect/etc work
<hatch> nice catch though, I never thought of checking that
<rick_h__> hatch: can you duplicate? I was going to check comingsoon but that's not updating off of git trunk atm
<hatch> checking
<hatch> rick_h__ what was the chrome command to clear localstorage?
<hatch>  I just always did localStorage.clear()
<hatch> but I want to make sure it's out of the list
<hatch> but my google fu is failing me
<hatch> rick_h__ I can confirm
<hatch> definitely a bug
<rick_h__> hatch: oh sorry, I go to the resources tab in dev tools and look at the list
<rick_h__> then click/delete the itmes
<hatch> yup it's definitely broken
<hatch> localStorage.clear() does work too, which is pretty cool :)
<rick_h__> hatch: k, I'll file a bug/add a card for it
<rick_h__> hatch: posted QA issues
<rick_h__> hatch: some of them might be related so will hold off on more QA until tomorrow and will go through it again
<hatch> rick_h__ do you think these happen on trunk too
<hatch> as part of the redirect not the code removal?
<rick_h__> hatch: no, some are pure fullscreen
<rick_h__> the sidebar issue might, not sure. 
<hatch> well I mean there is no /fullscreen as far as the code is concerned
<hatch> it gets redirected
<hatch> and never touches the other code
<rick_h__> hatch: right, but it's not redirecting cleanly
<hatch> right, so these issues should happen on trunk?
<rick_h__> some of the urls are possible user bookmarked urls that need to map cleanly
<rick_h__> hatch: ah, ic 
<hatch> the search results one is interesting though
<hatch> will look into that
<rick_h__> heh, they're worse on trunk as you don't even get a sidebar at all
<rick_h__> you just get the canvas sans-browser
<hatch> eek
<rick_h__> hatch: yea, I think the redirect should detect the requested viewmode and rather than just navigate, change the viewmode and do a browser viewNavigate so that the rest of the viewstate is kept in place
<hatch> I can reproduce your sidebar issue, so I'll take a deeper look into that
<hatch> and maybe at the same time try and fix the redirect stuff
<rick_h__> the sidebar issue is on trunk as well
<hatch> oh? hmm
<hatch> maybe land as is then and roll another branch?
<rick_h__> hatch: so maybe that's fallout from sticky headers?
<rick_h__> well, I think it kind of sucks to keep going removing fullscreen (and hints on what's changed) with the broken url/search/state stuff
<hatch> my guess is it's fallout from the browse/build removal stuff
<rick_h__> I know your branch isn't 100% at fault, but it's related and think those urls should 'work' as part of removing this stuff
<hatch> yeah that's true
<hatch> ok I'll look into it
<rick_h__> thanks
#juju-gui 2013-12-12
<hatch> huwshimi hey you there?
<huwshimi> hatch: Hey
<hatch> hey check out my msg on your PR
<huwshimi> hatch: Oh, strange... why would they be there?
<hatch> I have no idea...
<hatch> maybe your fork of juju-gui is out of date
<huwshimi> $ git pull juju develop
<huwshimi> From github.com:juju/juju-gui
<huwshimi>  * branch            develop    -> FETCH_HEAD
<huwshimi> Already up-to-date.
<hatch> then run git push
<hatch> to update your fork
<hatch> I really don't know why those old commits would be there anyways
<hatch> it should have diff'd them out as far as I know
<huwshimi> yeah, quite strange.
<huwshimi> brb, lunch
<hatch> Thanks for fixing that huwshimi  but it looks like it's still pushing all of those commits in, maybe it needs a new PR? 
<huwshimi> hatch: Yeah, I'll delete and start again :)
<hatch> sorry I wish I knew what the issue was so that we could avoid it in the future hah
<hatch> huwshimi I was wondering if you play any games on your new machine?
<huwshimi> hatch: Nah
<hatch> You should go buy some and let me know how they run so I can decide on the computer to buy haha
<huwshimi> :)
<huwshimi> hatch: By the time you're ready the new Airs will be out anyway
<hatch> lol!
<huwshimi> hatch: https://github.com/juju/juju-gui/pull/17
<huwshimi> hatch: Lots of strangeness
 * rick_h__ goes to doc office. bbl
 * gary_poster goes to son's prospective middle school. bbl
<benji> bac: Spads is asking me if the prod charmworld charm is "jc-charmworld/0"; do you know if that is right?
<benji> bac: he may mean "service name" instead of "charm"
<bac> benji: oh, the charm lives at bzr+ssh://bazaar.launchpad.net/~juju-jitsu/charms/precise/charmworld/trunk/
<benji> bac: do you know the service name is for the production charmwolrd?
<bac> no.  on staging it is just 'charmworld'
<bac> charmworld/0
<frankban> hazmat: ping re: the deployer MP
<bac> benji: if he has access to prod, a juju status should show.  should only be one similar to charmworld
<bac> benji: but webops grab everything and deploy locally so it could be there is a renaming
<bac> let me look at the docs
<benji> bac: do we run ES as its own charm in prod?
<benji> s/charm/service/
<bac> benji: looking at https://wiki.canonical.com/InformationInfrastructure/WebOps/CDO/Charmworld it looks like jc-charmworld is correct
<bac> benji: yes, i would think ES is its own service.  can't see how it'd be otherwise.
<bac> benji: the problem with understanding production is that page refers to scripts that we don't have access to, so it's kind of hard to see what's happening.
<benji> yeah, really
<benji> bac: it seems the staging.jujucharms.com environment is in a bad way: 2013-12-12 14:17:53,234 ERROR juju environment not found: is the environment bootstrapped?
<benji> have you seen that before?  Should I nuke it from orbit and rebuild from scratch?
<bac> benji: but, but, it seems happy http://staging.jujucharms.com/heartbeat
<bac> benji: where did that terrifying message come from?
<benji> bac: happy except that it hasn't ingested since 2013-12-08
<benji> bac: from Spads in #webops
<bac> benji: oh, well
<bac> benji: huh.  well it is definitely bootstrapped
<benji> bac: I guess I need to figure out why my orangify script isn't working so I can poke on the staging env myself
<bac> benji: i found some subdirectories in that branch that were created at some point and were messing up the connection.  once i deleted them i could connect.  if 'bzr st' shows anything weird (local, charms, etc) you may try the same.
<bac> weird = unknown
<benji> bac: staging.jujucharms.com is running on go-juju, right?
<bac> yes
<bac> benji: you may want to manually copy over the ssh credentials.  the install script is broken in that it doesn't copy if they exist even though new ones may be available
<bac> i've fixed it but haven't yet merged
<bac> benji: i'm look at the staging charmworld/0 logs and don't see where that message from spads comes from.  i wonder if his env is not right.  there definitely is a problem with ingesting, and it looks like the job hasn't even tried to run since 9-Dec
<bac> s/look/looking/
<benji> bac: I have determined that he was running py-juju
<bac> oh
<bac> that'll do it
<benji> heh
<bac> so, one red herring down
<benji> bac: I almost have orangify working, when I run "nova list" I get juju-staging-machine-0 through juju-staging-machine-5, is that expected?
<bac> curtis did fix a problem with mongo the other day
<bac> benji: sounds about right
<bac> benji: what does juju status do?
<benji> bac: orangify still fails, this time with "client: fatal: failed to establish ssh session (2)"
<benji> that is after printing:
<benji> Found a compatible Juju.
<benji> Orange credientials loaded
<benji> JUJU_HOME set to /home/benji/workspace/staging-tools/staging-tools
<benji> State server is at 10.55.32.48
<bac> benji: there's the problem
<bac> credentials is misspelled
<benji> heh
<bac> benji: prob won't help but try pulling a new version of that branch
 * benji tries
<bac> benji: so there are lots of problems from 9-Dec and before.  that was when curtis got mongo working again
<bac> but it doesn't look like ingest has run since then.  it hasn't generated any errors since that date
<benji> bac: the main thing I'm interested in is getting ingest to run again; my hypothesis is that it will then make the search results on staging match prod (which are wrong, but at least we'll have an idea of what is going on)
<bac> right
<benji> bac: same error after pull
<bac> but no typo?
<frankban> guihelp: I need two reviews for https://codereview.appspot.com/41350043 (quickstart). Is anyone available? 
<sinzui> hi bac
<bac> sinzui: when mongo failed on staging it caused ingest to fail repeatedly and supervisord marked it as FATAL. do you know how to get it going again?
<bac> sinzui: we're engaging spads in #webops on the issue though he isn't sure
<sinzui> for staging?
<sinzui> bac, he doesn't have access
<sinzui> bac https://docs.google.com/a/canonical.com/document/d/190xKLPpEPSrlVix4D9eX_aTciiKFo12h0u7MpzqI28I/edit#heading=h.g8pxm6cjaq69
<sinzui> ^ we need to add a section about restarting the service, which I know but cannot type without doing it.
<sinzui> per canonistack guidelines, there is a script in /srv that allows webops/devops to restart the services
<bac> sinzui: can i just stop and restart supervisord?
<sinzui> bac: I did this http://paste.ubuntu.com/6561801/
<sinzui> sudo /srv/deploymgr/charmworld restart
<bac> sinzui: could we have just used the 'start_worker' target in the makefile?
<bac> which i just found
<bac> sinzui: i'll update the doc unless you want to
<sinzui> bac: please do update the doc.
<bac> thanks sinzui
<rogpeppe> bac: sorry, was at lunch
<bac> rogpeppe: ?
<bac> rogpeppe: i didn't ping you, perhaps someone else did
<bac> but i hope you had a good lunch
<rogpeppe> bac: oh, sorry, i misread a remark of yours
<rogpeppe> bac: it was just below one addressed to me
<rogpeppe> bac: ignore :-)
<bac> rogpeppe: np
<bac> rogpeppe: was that a really late lunch or a really long one?  :)
<rogpeppe> bac: late
<rogpeppe> bac: i often forget to have lunch until hunger prompts me :-)
<benji> bac: the queue size is increasing, so it looks like a queue-clearing is in the future
<bac> benji: ok
<bac> benji: should be able to do: db['charm-queue'].remove()
<bac> though it is kinda scary
<benji> heh, yeah
<bac> and db['basket-queue']
 * benji wonders if it is about team call time.
<hatch> jujugui call in 1
<hatch> benji are you actually going to make it on time today? :P
<benji> I changed my reminder so I can't snooze it.  That seem to help.
<gary_poster> rick_h__, assuming you are still at dr
<hazmat> hatch, Makyo how'd the rest of the meeting go
<hatch> hazmat pretty good, hangout after standup to fill you in?
<hazmat> sure
<hazmat> hatch, sounds good
<hatch> cool I'll ping when we're done
<hatch> hazmat https://plus.google.com/hangouts/_/calendar/Z2FyeS5wb3N0ZXJAY2Fub25pY2FsLmNvbQ.j0rk5d371ph8331ijtf48t2uj0?authuser=1 just finishing up 
<bac> benji: so shall we do the cleanup?
<benji> bac: yeah, we don't have a choice at this point, and since I haven't gotten orangify to work I need to enlist you if you can help
<bac> benji: hangout?
<benji> bac: sure, I'll create one
<Makyo> hazmat, do we have a sprint authorisation number?
<rick_h__> gary_poster: back now, sorry for the delay. 
<gary_poster> np rick_h__ .  how are you feeling?  dr give you any meds?
<rick_h__> gary_poster: yep, shot in the $#@$ and meds to take. Wheeeeeee
<gary_poster> heh, hope it gets you well fast
<rick_h__> gary_poster: rgr, working on it. Will be afk today. Sorry for the MIA
<gary_poster> np at all.  good, go rest
<frankban> gary_poster: book expensed :-)
<gary_poster> frankban, :-) cool
<hatch> ll
<hatch> bah
<hazmat> Makyo  sent via msg
<Makyo> hazmat, ty
<hatch> Makyo did you ever qa my fullscreen removal branch?
<Makyo> hatch, Was going to wait on your verdict re: stuff in trunk fixed in this branch or another, but I can now.
<hatch> well....the issues are in trunk
<hatch> so just trying to fix anything small now
<Makyo> hatch, okay, will in a sec; let me finish code review of frankban's branch
<hatch> yeah sure, no rush
<hatch> Makyo so it looks like the issues rick_h__  raised are more serious than a few cleanup lines in this branch unfortunately so I'll have to do them as a follow-up
<Makyo> hatch, np, will QA in a sec with that in mind
<hatch> just so you are aware, for whatever reason the browser is being dispatched twice which is causing the issues...heh, more double dispatch....lol
<Makyo> Siiiigh~
<hatch> this issue may have always been there we just never noticed it for whatever reason
<hatch> I can't really see how any of the changes that have been made would cause this
<Makyo> hatch, lgtm
<hatch> thanks
<bac> hi benji, did the charms get ingested?
<benji> bac: yep; I'm now curious about a bundle potentially "stuck" in the bundle queue on prod
<benji> every round now staging has one fewer baskets queue than prod and after the queue is drained there is still one basket in the basket queue; I'm wondering if the stuck one is Jorge's
<bac> benji: what have the queues on prod looked like?  1164/22 now -- have then been going down?
<bac> s/then/they
<bac> s/then/they/
<bac> gah
<benji> bac: yep they are occasionally drained to 0/1
<bac> oh, i bet that 1 is the problem!  :)
<benji> yep
<bac> benji: oh, with orangify you can now say 'source orangify stop'.  pretty darn neat.
<bac> no more fumbling around looking for that pid file
<benji> I saw that, nice addition
<bac> my proudest moment of the morning
<benji> :)
<hatch> has anyone flown Delta internationally? 
<BradCrittenden> hatch: yes
<bac> gary_poster: call
<bac> i meant, gary_poster call?
<hatch> bac and?
<gary_poster> bac almost
<bac> hatch: and it was fine
<bac> hatch: i think delta is a fine U.S. carrier.  i mean they don't do long hauls like the good asian carriers.
<bac> hatch: i've flown delta on detroit-tokyo and survived.  where you going?
<hatch> Makyo so those issues that rick_h__  found are actually in release :/
<hatch> I -think- it has to do with the new token stuff
<hatch> just going to bisect to try and roll back to find it
<Makyo> I thought we knew that b/c it was in trunk? 
<hatch> well trunk has a lot of other stuff in it too
<hatch> could have been from anything really
<Makyo> Yeah.
<Makyo> Maybe come up with a test that fails for one of them to make it easier to bisect?
<hatch> somehow I broke my repo, trying again, doesn't look like it was the token code though
<hatch> hypothesis, incorrect
<hatch> :)
<gary_poster> older, hatch?
<gary_poster> jujugui, looking for small but important review and qa https://github.com/juju/juju-gui/pull/18
<Makyo> gary_poster, on it
<gary_poster> thanks Makyo 
<gary_poster> hatch, I mean, the problem is older than the token code?
<hatch> it appears so, still bisecting
<gary_poster> k
<hatch> the double dispatch is caused by the app routing, then the login comes in as successful and then it routes again
<hatch> double dispatching, but that doesn't appear to be the root cause
<hatch> just another bug which we haven't noticed
<gary_poster> ack
<hatch> having to keep killing and restarting the app sure slows down bisection hah
 * hatch crosses fingers it wasn't him
<hatch> gary_poster according to bisect this is the culprit which broke the onboarding stuff....oops we should qa that :)
<hatch> https://github.com/juju/juju-gui/commit/dec7617b378034fd93e41b1c382bb075c8b4978a
<hatch> not entirely sure what the issue is
<hatch> but at least we know where it is
<gary_poster> hatch, so that is the token stuff
<gary_poster> I just sent a note to rick that the git history is flatted rather than collapsed
<gary_poster> which obscures the fact that this is part of the token commit
<hatch> ohhh that's why these old ones are confusing
<gary_poster> yup
<gary_poster> I asked him if we can fix that
<gary_poster> we'll see
<gary_poster> flattened
<hatch> ok cool, well hey, we just moved to git, and just used bisect to find an issue.....yay for the conversion :D
<gary_poster> :-)
<gary_poster> hatch, would it be helpful for me to look at that with you, or don't bother?
<hatch> umm I think I'll be ok - I'm going to see if this is also the cause of the other redirection issues that just didn't happen to be noticed until I tried to muck with it recently
<Makyo> Whoa.
<hatch> it's very odd though that this commit is the culprit I don't see anything on face value that would cause the onboarding issue
<Makyo> gary_poster, +1
<gary_poster> hatch, currentUrl and onLogin seem most likely culprit in there to me.  It does affect the post-login redirect.
<gary_poster> Makyo, thanks.  A bit scary, eh?
<Makyo> gary_poster, yeah, thus the 'whoa' :T  Good catch, thanks for the fix!
<gary_poster> thank you
<hatch> gary_poster haha nice catch with #18 :)
<hatch> *phew*
<gary_poster> hatch, yeah, we kinda need that out soon. :-(
<hatch> gary_poster fyi - here is the issue https://github.com/juju/juju-gui/commit/dec7617b378034fd93e41b1c382bb075c8b4978a#diff-2de9eda1655d499e934e7465e87ca0bdL951
<hatch> super trivial fix 
<hatch> or maybe not....I haven't used the token stuff
<hatch> wana have a quick chat?
<gary_poster> hatch, how so?  you don't have originalPath anymore
<gary_poster> yeah sure
<rick_h__> hatch: the double dispatch I think is from the url replace and re-dispath. It'll hit that twice
<rick_h__> hatch: by bybassing the viewstate, nothing in subapp is watching/protecting against double dispatch
<rick_h__> hatch: let me know if a hangout to chat will help, and maybe I'm wrong on this, but I think it's a simple fix.
<hatch> rick_h__ hey we found the issue, it was actually located in a race condition in the login system that has been there......forever
<rick_h__> hatch: oh well crap
<hatch> yeah - it's a pretty odd edge case that has just been slowly exposed as we refactored code over the past month
<hatch> jshint for chrome: http://mrpotes.github.io/jshint-extension/
 * Makyo dogwalks, getting stomped.
<huwshimi> Morning
<rick_h__> hatch: ok cool. Never mind then. 
<rick_h__> glad you got it figured out
<gary_poster> morning huwshimi.  you have time to talk for 15 min now?  I have family obligations now
<gary_poster> I mean later
<gary_poster> bah
<huwshimi> gary_poster: Sure, happy to talk anytime
<gary_poster> reboot: morning huwshimi.  you have time to talk for 15 min now?  I have family obligations later :-P
<huwshimi> gary_poster: OK!
<gary_poster> ok thanks huwshimi .  https://plus.google.com/hangouts/_/calendar/Z2FyeS5wb3N0ZXJAY2Fub25pY2FsLmNvbQ.87augjtfc2pm1q1ilfuhencae0
<huwshimi> gary_poster: Wait, did you need to reboot now, or in 15 minutes?
<gary_poster> huwshimi, neither, I am just exhibiting poor communication skillz :-P
<huwshimi> gary_poster: I know, I'm just teasing :)
<gary_poster> lol
<huwshimi> gary_poster: https://codereview.appspot.com/20120044/diff/1/bin/merge-files#newcode119
 * gary_poster runs
<gary_poster> bye all
#juju-gui 2013-12-13
<Makyo> jujugui lf quickstart review/qa https://codereview.appspot.com/39610049
<bac> hi benji
<gary_poster> I'm taking Makyo's quickstart review
<rick_h__> gary_poster: cool thanks. Let me know if you want to reschedule our chat today sometime. 
<gary_poster> cool rick_h__ .  definitely.  I'll drag something over on the calendar.  you're feeling much better, then?
<rick_h__> gary_poster: yea, working on it. Letting them medicate me to hopefully avoid rotten holidays
<gary_poster> heh, cool
<bac> hey benji
<bac> yoo whoo
<benji> bac: it's been a while since I've done that
<bac> benji: but its always amusing
<benji> heh
<bac> benji: i'm about to ask webops for an update to production for charmworld.  any reason i should wait, i.e. new code from you for the app?
<benji> I guess I need to write an IRC client over Christmas that will keep me from doing that.
<bac> s/i.e./e.g./
<benji> nope, but if you know where they keep the production .ini file, I would like to know
<benji> or we can ash whomever you get ahold of
<bac> benji: is it not in the charm?
<benji> that sounds like a question I should have asked myself
<benji> bac: any hints as to where the charm lives?
<benji> (the way charms are store in LP makes them hard for me to find)
<bac> yes, they are a mess.  but you can search for charmworld on manage.jujucharms.com and click on 'repository'
<bac> benji: otherwise you have to know who owns the given charm.
<benji> how meta
<benji> I suppose the ~juju-jitsu version is the official one.
<bac> benji: i just happened to have it opne: https://code.launchpad.net/~juju-jitsu/charms/precise/charmworld/trunk
<benji> thanks
<hatch> so hows everyone doing this fine fine morning
<bac> benji: charmworld upgrade deferred to monday.  i forgot the friday rule.
<bac> and nothing is on fire
<hatch> last night I decided to start learning lisp
<hatch> not sure why...
<frankban> hey benji: morning, any problems with my review?
<benji> frankban: the only problem is that I forgot to do it, very sorry.  Can you send me a link?
<frankban> benji: np, and thanks: https://codereview.appspot.com/41350043
<benji> I'll look now.
<frankban> cool
<benji> rick_h__: I found what appears to generate the INI but it didn't answer my question.  I'm trying to figure out why a script I had run in production generated this error: https://pastebin.canonical.com/101921/
<rick_h__> benji: so you have to set an INI= env var with the path to the INI file to use
<rick_h__> benji: so I'd expect your command to be INI=/path/to/production.ini bin/python /tmp/xxxx
<benji> could be, I'll try that next
<rick_h__> benji: in the charmworld utils is a get_ini() function that tries to find a default or ENV specified ini file to work
<benji> I'll observe that requiring carefully set environment variables for forware to run isn't such a great thing.
<rick_h__> well, I think it defaults to a charmworld.ini if none is specified
<rick_h__> and production uses production.ini vs charmword.ini which is why it needs the override
<rick_h__> patches/ideas on improvement welcome. 
<rick_h__> personally I wish it just overwrote charmworld.ini
<rick_h__> but it makes it more difficult to test production vs dev locally
<gary_poster> bac, thanks for looking at bug 1259704.  After you do that, or as a break if it is easy, could you look at updating comingsoon to use git?  There's a high priority card for that down in the CI swim lane.  +1 on doing it as cheaply as we've done the bzr integration, for now.
<_mup_> Bug #1259704: Bundle branch command incorrect. <juju-gui:Triaged by bac> <https://launchpad.net/bugs/1259704>
<bac> gary_poster: ok, i missed that one.  i'll be glad to do it now
<gary_poster> thanks bac, either way
<hatch> so there is an issue with us switching to git
<hatch> we have to push our branches up to lp to test in a real environment
<hatch> haha
<rick_h__> hatch: just until the charm is updated
<rick_h__> hatch: which is a card to be done soon
<rick_h__> hatch: so hit me back next week
<hatch> psssshhhhht
<hatch> but I need it nooooooow
<rick_h__> then go fix the charm nooooooow :P
<rick_h__> you know how to hacky hack
<hatch> but....but....but....
<rick_h__> pssssssshhhht
<hatch> http://www.digitalblasphemy.com/preview.shtml?i=shadedpathwinternight1
<gary_poster> hatch, not true: http://jujugui.wordpress.com/2013/10/15/if-you-want-to-run-a-custom-gui/
<rick_h__> oh right! gary_poster ftw
<gary_poster> :-)
<hatch> oooo hacky hacky
<rick_h__> except then you might want my current branch that git-ifies that stuff. 
<gary_poster> now we have to say NO_BZR BRANCH_IS_GOOD make distfile I bet hatch
 * rick_h__ isn't sure
<gary_poster> sorry "NO_BZR=1 BRANCH_IS_GOOD=1 make distfile"
<gary_poster> yeah or get branch from rick_h__ 
<gary_poster> jujugui call in 10
<hatch> http://updates.html5rocks.com/2013/12/300ms-tap-delay-gone-away
<rick_h__> hatch: yea, coolio
<rick_h__> but watch out broken sites!
<gary_poster> looks like it only affects double tap to zoom
<gary_poster> negatively I mean
<hatch> yeah the whole reasoning for it was to enable double tap support in the first place
<gary_poster> jujugui call in 2
 * gary_poster heads to lunch.  back later
<gary_poster> fwiw http://jujugui.wordpress.com/2013/12/13/weekly-retrospective-notes-2/
<rick_h__> bac: http://alblue.bandlem.com/2011/07/git-tip-of-week-tracking-branches.html looks like it might be decent for the tracking in git
<rick_h__> jujugui ^ if you're interested in shortcutting the push/pull commands to not be as explicit and setup tracking branches kind of like Makyo was mentioning today
<rick_h__> jujugui and I setup http://paste.ubuntu.com/6567622/ as a quick way to get around Makyo's question. Use that to sync with upstream and it'll keep your fork's develop in sync as well
<rick_h__> I'll update the docs with that alias in a bit. 
<bac> jujugui: comingsoon now using the git repo
<gary_poster> yay! thanks
<rick_h__> woot! thanks bac 
<gary_poster> inspector is so much freaking faster.  yay
 * gary_poster runs for real
<rick_h__> I feel the need...for speed!
<rick_h__> http://stackoverflow.com/questions/520650/how-do-you-make-an-existing-git-branch-track-a-remote-branch is the copy paste tracking post
<rick_h__> hatch: k, free here. Let me know when you want to chat
<benji> frankban: I finished your long-awaited review.  Your branch looks good.
<benji> Lunch looks good too, so I'll do that next.
<frankban> benji: cool, thanks
<hatch> rick_h__ just grabbing something to eat, didn't have breakfast again hah - 15mins?
<rick_h__> hatch: no problem
<hatch> rick_h__ rdy?
<hatch> https://plus.google.com/hangouts/_/72cpj5h9np735l8cvrlk97jsfc?hl=en
<hatch> jujugui looking for a review/qa on the login system changes https://github.com/juju/juju-gui/pull/19
<rick_h__> hatch: will look in a sec, lunch is nuking
<hatch> rick_h__ ^ this branch also fixes the odd minimize issues
<hatch> so plz test that too
<rick_h__> hatch: ok coolio
<hatch> oh wait nm
<hatch> cache 
<hatch> it doesn't fix it
<hatch> lol
<rick_h__> lol
<rick_h__> ok, keep that card on the board then
<hatch> I'm pretty confident it's separate from the url one
<hatch> I'll have to do another bisect to find the offending diff
<hatch> I'll do that now
<rick_h__> cool, thanks
<rick_h__> hatch: close, question and a tweak to the logic please
<hatch> rick_h__ the featured issue has been here for -well- over a month and I still haven't found one which works properly so I'm going to create a real bug for it
<hatch> looking
<rick_h__> hatch: ?
<rick_h__> which featured issue?
<hatch> the minimize apache2 details one
<rick_h__> oh, that interesting/reload thing?
<rick_h__> wow, :/
<hatch> yeah
 * rick_h__ promises to do better at QA day
<rick_h__> sorry to assume/stick that on you
<hatch> no problem :)
<rick_h__> yay git bisect
<hatch> I'm not sure I agree with your comments on my branch
<hatch> but I'm sure I can be easily convinced 
<hatch> why would the credentials cookies be removed if the user hasn't logged out?
<rick_h__> well, it's not trivial for things to get out of sync, but isLogged in should respect your credentials right?
<rick_h__> hatch: well, my use case is manual dev testing. 
<hatch> ok you convinced me
<hatch> :)
<rick_h__> but browser goes boom, something goes wrong, I'm not sure. It's more a 'correctness' issue that's easy to fix. In the check credentials stuff, if they're not set, then also make sure isLogged in is set to false
<rick_h__> yay 
<hatch> running the tests again before pushing that 1line fix
<rick_h__> hatch: ty
<hatch> rick_h__ pushed
<rick_h__> hatch: so I don't get a login window
<rick_h__> hatch: if I remove the session cookie, or I go logout, and go back to /
<rick_h__> I get the onboarding and not a login screen
<hatch> hmm
<hatch> it's working fine here, lemme try clearing the cache again
<rick_h__> yea, if I clear the cache, go to / I get the environment. I hit logout, get redirected to /login. If I manually change the url to /
<rick_h__> I'm right back in
<hatch> well wth make prod is broken now?
<rick_h__> huh? I'm just using make devel
<hatch> ohh well you're reloading the page then if you're in make devel
<hatch> which will make you log back in
<rick_h__> I expect a login box but I can't get one unless I go to /login
<rick_h__> hatch: hangout/screenshare?
<hatch> https://plus.google.com/hangouts/_/72cpj5h9np735l8cvrlk97jsfc?hl=en
<hatch> bah
<hatch> https://plus.google.com/hangouts/_/7ecpi6darhr73v0qj8gn8hhi9g?hl=en
<gary_poster> rick_h__, replied to git update email.  Lemme know if you want me to send.
<rick_h__> gary_poster: rgr
<rick_h__> otp, sec
<gary_poster> np
<rick_h__> gary_poster: did we want to send it to anyone besides john?
<gary_poster> rick_h__, minimally John, Curtis, and mramm.  If you feeling excited, cc canonical-juju, but that might be more expensive than we want. :-P
<rick_h__> gary_poster: rgr, sounds good. 
<gary_poster> thank you
<hatch> rick_h__ https://bugs.launchpad.net/juju-gui/+bug/1260831
<_mup_> Bug #1260831: Featured browser results shown instead of search results <juju-gui:New> <https://launchpad.net/bugs/1260831>
<hatch> rick_h__ did you want that one? You're probably better suited to it
<rick_h__> hatch: I can, not sure when I'll get to it atm as I'm trying to get CI finished up. 
<rick_h__> hatch: but feel free to stick it on me for now
<hatch> cool, card assigned
<rick_h__> thanks
<hatch> it's been there for a long time just want to get as many bugs fixed before 1.0 :)
<rick_h__> hatch: rgr, I'll get to it next week for sure. It might even be an easy fix once it's traced
<rick_h__> the tracing is the pita part
<hatch> imagine how simple all that will be once double dispatch is gone
<rick_h__> shush, you want to talk about a lot of code to work around something
 * Makyo sneaks to car+shop thing
<rick_h__> you've already kidded hours of my worklife :P
<hatch> haha 
<rick_h__> "I don't get why rick complained about this stuff...it's super easy now"
<rick_h__> - fullscreen, - double dispatch
<gary_poster> "kidded" -> "killed" ?
<rick_h__> umm yea
<rick_h__> drugs!
<rick_h__> :)
<gary_poster> heh
<gary_poster> My 100th jujugui blog post celebrate the speed improvements from Makyo: http://jujugui.wordpress.com/2013/12/13/great-speed-improvements/
<rick_h__> woot! nice
<benji> cool
<hatch> yay!!
<gary_poster> I'll make a git post after the release stuff has landed
<gary_poster> And looking forward to a "feature complete" post for quickstart next week :-)
<hatch> I tried to go buy a MBP yesterday, noone had the model I wanted in stock :(
<hatch> a sign?
<gary_poster> heh
<gary_poster> yeah, a sign to order online
<hatch> I want to buy local so if there is an issue I can return local :D
<hatch> it's expensive enough I want to be able to.....talk.....to someone face to face if there is an issue
<hatch> :P
<rick_h__> running for coffee to try to go a bit long today. brb
<hatch> if it exists, it will be written in javascript http://coolwanglu.github.io/vim.js/web/vim.html
<hatch> ^ rick_h__  benji 
<benji> hatch: heh, yeah I saw that earlier, strange days
<hatch> it opens up some cool opportunities though
<hatch> not sure how they are worth the work over just ssh'ing into the machine...buuuut
<hatch> haha
<bac> jujugui: what's the equiv of 'bzr info'?  i'm looking for the name of my feature branch.
<bac> (which i found in my bash history.  but how does one find it via git?)
<gary_poster> git branch
<bac> well, isn't that easy
<hatch> bac PS1 config to show it in your prompt https://gist.github.com/hatched/7826871
<hatch> hatch@beep:~/canonical/juju/juju-gui (fix-login-redirect) :
<hatch> for example
<bac> hatch: cool.  too many \ though
<hatch> bac yeah? I know almost thing about sed - I made it by merging a number of PS1 examples :)
<rick_h__> bac: git branch will show you the branch you're on with a *
<rick_h__> and you already got told that...finish reading the scrollback rick
<hatch> yeah rick!
<gary_poster> uh oh, he's getting cranky with himself now!
<rick_h__> lol
<bac> so, what's the diff between 'git checkout' vs 'git branch' if they both create branches?
<marcoceppi> hey party people, can I get some help in #juju?
<hatch> bac oh so you need to 'make check' before pushing
<rick_h__> bac: heads up, lint failure on your pull request. 
<hatch> that's why your ci failed
<rick_h__> marcoceppi: maybe
<marcoceppi> rick_h__: it's about charmworld, and ingesting, and fun stuff like that
<gary_poster> benji, #juju looks like it is related to what you are looking at
<gary_poster> marcoceppi, rick_h__ ^^^
<rick_h__> bac: http://stackoverflow.com/questions/7987687/what-is-the-difference-between-git-branch-and-git-checkout-b
 * benji looks
<rick_h__> oh, have we ever added trusty to the gui or api for support?
<marcoceppi> rick_h__: well it seems to be in the API
<rick_h__> marcoceppi: k, it might not be all the way through the UX. There's a few places where it's filtered in charmworld and in the gui I believe. 
<gary_poster> app/models/browser.js does not have saucy or trusty but that's the only places where those strings are & I haven't seen how we use it yet...
<gary_poster> app/widgets/filter.js ...
<rick_h__> gary_poster: yea, but charmworld might need some <3 there as well. It doesn't show trust charms by default. Though they're indexed for search as a couple do pull up via search. http://manage.jujucharms.com/~xnox/trusty
<hatch> bac I can do the review/qa once you get ci passing
<gary_poster> which is in a widget we don't use AFAIK
<gary_poster> rick_h__, yeah, my first guess would be in charmworld
<rick_h__> gary_poster: but yea, we should make cards to audit trusty all the way through charmworld -> gui
<gary_poster> ack.  on it
<rick_h__> there's a filter object in the browser.js models that we use for doing api calls
<rick_h__> so it might need a small one liner in there to add trusty 
<gary_poster> rick_h__, see the scrollback, luke ;-)
<rick_h__> gary_poster: yea, I'm just agreeing with it :)
<gary_poster> ah ok
<gary_poster> ]but that is only used in that filter widget which is hidden at best
<rick_h__> gary_poster: no, the filter is used in the main browser I believe and passed to the store for making calls
<gary_poster> rick_h__, btw good progress with Antonio and team account
<rick_h__> it's how categories work and such
<gary_poster> oh ok
<rick_h__> woot, oh boy, I get to recreate jenkins! 
<gary_poster> :-P
<gary_poster> we can make someone else to do it to try out your instructions!
<gary_poster> valuable
<rick_h__> hah, they're not that step by step tbh
<gary_poster> :-)
<bac> hatch: ok, i fixed lint and pushed a new revision.  did that update the pull request?  i don't see the diff anymore on the pull request page.
<rick_h__> I'm trying to avoid getting others to hate me remember 
<rick_h__> bac: yep updated and tests are marked as passing now
<bac> thx
<gary_poster> heh
<rick_h__> bac: just make sure before you submit for $$merge$$ you git rebase --autosqaush and squash the lint commit
<rick_h__> bac: let me know if you need a walk through on it for the first time
<rick_h__> it's the one doc I've not added yet. 
<bac> i will
<gary_poster> oh, didn't know that was necessary
<hatch> bac on it
<hatch> might take me a bit, lunch just arrived
<gary_poster> https://jujucharms.com/fullscreen/search/~xnox/trusty/sbuild-0/?text=sbuild but not in search
<gary_poster> https://jujucharms.com/fullscreen/search/?text=sbuild
<rick_h__> gary_poster: yea, sounds like charmworld needs something added to the search api to pick up the extra series
<gary_poster> trying the filter thing really quick beofre I write email #500076889758
<rick_h__> https://manage.jujucharms.com/api/3/search?text=trusty returns them, so it's clearly not checking the series field
<rick_h__> oh wait, they are in the sbuild search. Yep, we're filtering them heh, sucky me. https://manage.jujucharms.com/api/3/search?text=sbuild
<bac> rick_h__: so if i do a review i can just say "looks nice $$merge$$" and bob's your uncle?
<rick_h__> bac: rgr
<rick_h__> then 4min later it should show up in trunk/develop
<bac> well that sure seems nice
<rick_h__> hopefully :)
<gary_poster> rick_h__, no I think this was more ingestion time
<gary_poster> http://comingsoon.jujucharms.com/sidebar/search/?text=sbuild
<gary_poster> it is there now
<rick_h__> gary_poster: oh, cool then
<gary_poster> elasticsearch was the last to hear about it, I suspect
<rick_h__> even better
<gary_poster> yeah
<rick_h__> gary_poster: got a sec?
<gary_poster> sure rick_h__ .  hangout?
<rick_h__> gary_poster: sure
<gary_poster> https://plus.google.com/hangouts/_/72cpis84sht2ofk1388nj78i4k?hl=en
<hatch> bac all done lgtm'd
<bac> hatch:
<bac> hatch: ok, so i need to rebase and then do my own $$merge$$ comment?
<hatch> well first I'd like to see some changes made :P
<hatch> but yes you would then rebase your local branch, push the changes up
<bac> wait, does $$merge$$ go in a pull request comment or a commit message?  latter, right?
<hatch> then add the $$merge$$ comment
<hatch> it goes as a comment in the pull request
<hatch> see https://github.com/juju/juju-gui/pull/18
<hatch> for example
<bac> rt.  thanks.
<hatch> rick_h__ have you had a chance to qa my branch on a real env yet?
<rick_h__> hatch: no, I was actually working on make distfile in my own branch and figured I'd see if I could get it to work from there but hit an issue
<hatch> ohh ok cool cool
<rick_h__> honestly, this is kind of complex and I want to stick through this before going off on the live qa. I'll try to get to it in a few
<rick_h__> if you can find someone else that's cool, but I don't want to lose track of this makefile stuff over the weekend if I can
<bac> wow, i like how github lets you delete reviewer comments you find annoying.  nice!
<rick_h__> lol
<hatch> hahaha
<hatch> bac has removed all of my comments
<bac> justSomeOfThem
 * rick_h__ chuckles
<gary_poster> lol
<hatch> rick_h__ if you git rebase --autosquash and then push up to the PR does it remove all of the previous commits? or do you need to force push?
<rick_h__> hatch: you have to force push or it won't push
<rick_h__> git push --force origin {branchname}
<hatch> is that a good idea to do? because then it gets rid of all of the PR history?
<hatch> shoudl we maybe say only PR after you have rebased, then after that we just deal with it?
<rick_h__> hatch: well, it's still there. If you look at the comments you can view the original context they were applied against
<rick_h__> hatch: meh, I don't see why. The branch goes away anyway
<rick_h__> and normally those changes are "fix lint"
<rick_h__> it's not that much of a history to lose imo
<rick_h__> and worth it for a cleaner reading develop line
<hatch> well if you force push the comments will have nothing to reference because you rewrote history
<rick_h__> hatch: right, but github gives you the option to look at the original history
<hatch> oh does it? cool
 * rick_h__ goes to find one, knows he saw it
<rick_h__> https://github.com/juju/juju-gui/pull/20
<rick_h__> hatch: go down to your comment with the 'show outdated diff' links
<hatch> right but the previous commits are still there
<hatch> they are just outdated
<rick_h__> I thought it did the same thing with force/squashed, I'll look for another example
<rick_h__> https://github.com/juju/juju-gui/pull/10
<rick_h__> hatch: ^^
<rick_h__> hatch: notice one commit, but there's an outdated diff reference
<rick_h__> hatch: I mean rebasing doesn't get rid of the commit. reflog ftw
 * gary_poster just sent a super, super, way important message to peeps.
<rick_h__> it just moves it out of the tree of commits that make up the history path
<hatch> rick_h__ ohh I see what's going on now
<hatch> I thought rebase in this context was actually destroying the commits
<hatch> gary_poster reading
<rick_h__> gary_poster: +1 on the :shipit:. I'll change the jenkins box if someone will change the docs
<gary_poster> rick_h__, awesome. :-) I'll do docs, since I'm the perpetrator
<gary_poster> rick_h__, we can wait to see if anyone throws things at me first though
<rick_h__> gary_poster: changed
<rick_h__> :)
<gary_poster> rick_h__, lol
<rick_h__> bac: ^^
<gary_poster> oh ok
 * gary_poster makes branch for docs
<hatch> lol!
<hatch> most superest importantest email eva
<gary_poster> :-)
<bac> hatch: did you do qa?  am i read to grey squirrel?
<gary_poster> lol
<hatch> haha gary_poster https://www.evernote.com/shard/s219/sh/1f0d13b7-e5bf-408a-8e41-f0b10aacd61f/9689e4b586a251a1b245ddf6105bb32a
<hatch> bac yep I said QA OK!
<gary_poster> hatch, oh yeah :-)
<bac> oh didn't see.  ty.
<hatch> bac did you autosquash?
<hatch> I'm curious to see that in action
<bac> i tried
<hatch> it doesn't work because you already pushed right?
<bac> hatch: sorry, i was looking on the files tab not the conversation tab so i didn't see it.
<bac> why does it not work?
<hatch> ohh nm I think we are just confusing eachother
<hatch> :)
<bac> hatch: i did this:
<bac> git rebase -i --autosquash
<bac> git push origin fix-branch-reference
<bac> should be right, no?
<rick_h__> bac: when you did the rebase you changed the lint/fixer-upper commits to s ?
<bac> s?
<rick_h__> yea, hangout?
<bac> ffs
<bac> sure
<gary_poster> fast review of https://github.com/juju/juju-gui/pull/21 ?
 * bac no steroids
<hatch> can I join too?
<gary_poster> no qa
<rick_h__> we can not hangout :/
<hatch> link me up!
<hatch> :/
<gary_poster> :\
<rick_h__> https://plus.google.com/hangouts/_/72cpjheea3948s8nfq85l9gh40?hl=en
<hatch> (â¯Â°â¡Â°ï¼â¯ï¸µ â»ââ»
<gary_poster> lol
<hatch> haha I love that
 * gary_poster inclined to shipit without review. trivial
<gary_poster> doing so.
<hatch> lgtm'd
<gary_poster> ty :-)
<gary_poster> jujugui, if you don't see email or HACKING doc change, use :shipit: now instead of $$merge$$
<rick_h__> jujugui release process branch for review please. Note the *disclaimers* in the notes. https://github.com/juju/juju-gui/pull/22
<hatch> oh it
<hatch> n
<gary_poster> I'll take it
<gary_poster> ok, two reviews probably wise
<rick_h__> yea, appreciate all the eyeballs on it please. Though I still ack that I'll probably want a tweak/two when we do the real release. I didn't want to go all the way atm
<gary_poster> rick_h__, do I understand correctly that the tag will be on master but not develop branch?
<rick_h__> gary_poster: it will be made from the sha of the commit on master after the merge from develop
<rick_h__> gary_poster: but it will be visible from anywhere via git tag
<gary_poster> ok, that sounds good, and hopefully I'll see how it works when I try it myself
<rick_h__> yep
<rick_h__> you must experience the joy...wheeeee
<gary_poster> heh
<Makyo> jujugui python question re: __future__.print_function
 * bac eod.  have a nice weekend.
<hatch> cya bac enjoy!
<rick_h__> bac: you need to publicize your juju membership before you can land
<rick_h__> bac: https://github.com/juju?tab=members and publicize 
<hatch> flyer person is driving door to door to deliver the flyers....
<bac> rick_h__: so now i just :shipit: again?
<bac> hatch: are the flyers for some environmental org?
<gary_poster> have a nice weekend bac
<bac> gary_poster: oh, hell, no.  not until this thing lands.
 * benji waits with bated breath for Makyo's question.
<hatch> bac haha no, they are for all of the big box stores in the city....very anti environment
<gary_poster> Makyo, you never said the question :-)
<hatch> lol
<Makyo> Sorry, was getting the gist ready: https://gist.github.com/makyo/7951503
<Makyo> gary_poster, benji ^^^
<Makyo> With the end kwarg, nothing gets printed until the loop breaks, then all the dots get printed at once.  Without, it prints one per second, but on new lines.
<benji> Makyo: flush
<Makyo> Aha!
<benji> (or run your python unbuffered (python -u))
<rick_h__> bac: it should pick it up on the next cron run
<rick_h__> we just don't allow anyone not in the org to merge
<Makyo> benji, cool, thanks.
<benji> (or reopen stdout as unbuffered, or use the PYTHONUNBUFFERED environment variable)
<rick_h__> bac: landed, thanks!
<rick_h__> no one's ever allowed to edit the hacking doc again. It'll never have a better line https://github.com/juju/juju-gui
<gary_poster> :-)
<benji> heh
<benji> this gives me so many ideas for commit messages
<gary_poster> rick_h__, changes lgtm with comments.  trying qa now.
<rick_h__> gary_poster: thanks
<hatch> rick_h__ you aren't allowed to EOD until you finish qa'ing my branch
<hatch> new rule
<hatch> house rules if you will
<hatch> :P
<rick_h__> hatch: :P drugs!
<hatch> lol
<rick_h__> sorry man, been crazy today. 
<hatch> yeah it's fine, I'd just like to land it before my EOD as well :)
<rick_h__> k, working on it
<hatch> wel tbh it could be any time, I'm not going anywhere
<rick_h__> well I want to get out of here. Running low today
<hatch> yeah that's understandable 
<rick_h__> running make deploy now
<gary_poster> so nice to not see the bzr complaints any more
<Makyo> jujugui quickstart re-review/qa: https://codereview.appspot.com/39610049 Have to use ssh-agent for juju-core to recognize the keys.
<Makyo> ^^^ includes changes to autogenerating keys.
<gary_poster> will look asap if no-one else does.  tryingto finish rick review
<Makyo> No worries.
<Makyo> I need to pick up a prescription now that I finally have my car back. Shouldn't be too long
<rick_h__> bah, error state...
<gary_poster> rick_h__, one ignorable qa bit so far: I expected "IS_TRUNK_BRANCH=1 make distfile" to work in dev branch.  Can't figure out why yet, because the other var is fine.  However, BRANCH_IS_GOOD=1 make distfile works great.  Oh!
<gary_poster> you changed the logic to check 0
<gary_poster> rather than definition
<rick_h__> gary_poster: yes, I couldn't get the length stuff to work right
<gary_poster> ok, that's alright
<rick_h__> and I hit that and it was confusing to me as well, I tried the same thing
<rick_h__> but this seemed a simpler check. did it return 0 or 1 where 0 is a good code and 1 is a bad return code
<gary_poster> rick_h__, IS_TRUNK_BRANCH=0 make distfile works :-) so if we cared we could say ifdef IS_TRUNK_BRANCH; IS_TRUNK_BRANCH=0; endif
<gary_poster> and same for BRANCH_IS_CLEAN
<gary_poster> but eh
<gary_poster> although
<gary_poster> if we don't do that
<gary_poster> we should fix up the HACKING doc
<gary_poster> rick_h__, I'd say the ifdef hack is the easier of the two
<rick_h__> gary_poster: oic, so map the 1 to a 0 for the sake of getting the UX consistent with the actual check
<gary_poster> right
<rick_h__> ok, I'm game
<gary_poster> rick_h__, or actually changing hacking might be better
<gary_poster> rick_h__, <shrug> you choose :-)
<rick_h__> hacking? or process.rst?
<gary_poster> hacking
<rick_h__> oh, missed it was in hacking
<rick_h__> k, yea that'll be easier I think and less confusing to parse
<gary_poster> cool +1
<gary_poster> rick_h__, I thnk given that your disclaimers, QA good.  the rubber will hit the road next week, but looks good so far
<rick_h__> and I'll change BRANCH_IS_GOOD to 0 as well
<gary_poster> heh
<gary_poster> ok
<rick_h__> just for the sake of it looking the same :)
<rick_h__> gary_poster: cool, thanks for walking through it. I think it's in the ballpark 
<gary_poster> definitely
<gary_poster> :+1: done
<rick_h__> hatch: did you get this release dir thing to work?
<hatch> having issues?
<rick_h__> hatch: yea, it keeps failing on install saying it can't find a release
<hatch> I used NO_BZR=1 or something
<hatch> I can't remember exactly
<hatch> umm
<rick_h__> ah, I missed that when I did the distfile
<gary_poster> oof, switch between bzr and git is going to make me dizzy
<rick_h__> +1
<rick_h__> I forsee us moving more stuff just to keep sanity
<gary_poster> the thing is that quickstart and charm both have to be in LP because of machinery (PPA and charm store, respectively) :-/
<gary_poster> we could do import
<gary_poster> if that's even working still
<gary_poster> so git is source of truth and LP regularly imports it
<rick_h__> I hear people do it, but not sure who is tbh. 
<rick_h__> but yea, another level of stuff to deal with
<rick_h__> hatch: I'm working on getting it to deploy, but I've got to get our of here and get the boy from day care. I'll keep working on this qa when I get back/tonight. 
<hatch> rick_h__ sure np just update the PR and I'll get back to it whenever
<rick_h__> hatch: if it's good I'll just shipit for you. I think you've addressed anything I had in code
<rick_h__> ah crap, it deployed to ec2
<rick_h__> heh, oh well
<hatch> ok cool that works too
<rick_h__> looks good, will land
<gary_poster> Makyo, got same error as before ("juju-quickstart: error: ERROR error parsing environment "ec2": no public ssh keys found").  I need to go soon.  do you want to do a quick hangout with me to diagnose, or get someone else to look at it?
<gary_poster> Mm, I think I know why.
<gary_poster> nope. :-/
<gary_poster> still think I might know
<hatch> oh ricks branch got landed
<hatch> lol
<hatch> WELL THEN
<hatch> lgtm
<hatch> :P
<gary_poster> Makyo, gave some hints.  Must run
<gary_poster> have a good weekend all!
<rick_h__> hatch: heh yea sorry. gary_poster|away went through it pretty well and I needed to get out
<Makyo> Damn.
<rick_h__> Makyo: hey, there has been a lot of agent/key mgt commits to juju-core lately I've seen go by
<rick_h__> any of those help you with how they're managing some of this stuff?
<Makyo> rick_h__, yeah, that's the next step - seeing how core does it.
<rick_h__> cool, yea there's been a bunch of commits over this week that seemed like it might be useful. 
<Makyo> rick_h__, The code I have is still valid, just for passphrase-less keys.
<rick_h__> gotcha
<Makyo> rick_h__, will check it out, thanks.
<rick_h__> good luck!
<Makyo> Damn again.  Compounding pharmacy didn't actually compound anything - same stupid prescription.  Waste :/
#juju-gui 2014-12-08
<hatch> morning
<fabrice> morning hatch
<hatch> jcsackett: do you still use weechat?
<jcsackett> hatch: periodically. depends on what wm i'm using.
<hatch> jcsackett: oh ok I was just hoping you had some experience with the 'beep' script. I can't seem to get it to work
<jcsackett> hatch: beep.pl?
<hatch> oui
<jcsackett> hatch: that just "works for me"...maybe a terminal issue?
<jcsackett> what issue are you seeing?
<hatch> well it doesn't ding
<hatch> like make sounds :)
<hatch> I need my train sound :P
<rick_h_> uiteam call in 2 kanban please
<hatch> jcsackett: I could try others but beep was the 'popular' one
<jcsackett> hatch: i believe all beep does is trigger the terminal bell.
<hatch> I wonder how I can test the terminal to see if it can make sounds
<jcsackett> hatch: if you're using e.g. iterm that just flashes on bell, no dice.
<hatch> jcsackett: I'm in Terminal
<hatch> ohh right you don't know - I'm now on UbuMini
<hatch> :) 
<jcsackett> UbuMini?
<hatch> ubuntuified mac mini
<jcsackett> ah. nifty.
<hatch> jcsackett: apparently `echo -e "\a"` should make a ding and it doesn't 
<hatch> so I must have something else wrong
<jcsackett> hatch: check your profile preferences and make sure "terminal bell" is checked.
<jcsackett> Edit -> Profile Preferences
<hatch> yep it is
<hatch> jcsackett: could be something funky with the apple hardware 
<hatch> will have to investigate further later 
<jcsackett> hatch: dig.
<hatch> hmm none of the quick fixes online work so I'll have to read the beep source to find out what's going on
<rick_h_> hatch: :P
<hatch> I also have to figure out how to add more strings to beep on
<hatch> for another day!
<hatch> rick_h_: I reviewed huws branch - it's going to need a little bit more work before it can land
<rick_h_> hatch: all good ty much
<rick_h_> hatch: if you seem him when he comes on line make sure to sync and make sure it's all clear please
<hatch> will do
<rick_h_> Makyo: woot!
<hatch> WHOO
<hatch> what are we chearing for?
<jrwren> life.
<hatch> woooo
<kadams54> yay.
<rick_h_> Makyo's branch landed which I take to mean he got the sauce/functional test stuff figured out and working
<hatch> awesome I'm very interested to know what the issue was
<hatch> ^ Makyo 
<jrwren> kadams54: how would you feel about a debian directory in https://github.com/switchboardpy/switchboard so I can put it into a PPA?
<kadams54> jrwren: Um, sure? What's a .deb get us over a normal python package (e.g., "pip install switchboard")?
<jrwren> kadams54: no need for a build environment or even pip itself when you deploy.
<kadams54> jrwren: I'm completely ignorant of our production setup, so if it needs to be in a PPA to get there, clue me in.
<rick_h_> jrwren: it'll be a offline-cache'd python package during install and won't be using a deb for our use
<jrwren> oh no. I'm sorry I didn't add context. I mean for non-workies stuff. 
<jrwren> I'd like to submit the PR to switchboardpy on my own time and not with the idea of using it for work.
<kadams54> Sounds find to me.
<jrwren> kadams54: excellent.
<hatch> yay open source :)
<jrwren> pypi packages are always better as debs :)
<hatch> iunno venvs are easier to use than lxc
<hatch> :)
<jrwren> hatch: for dev they are and for production not using venvs is much faster IME.
<hatch> yeah I suppose if you can install to the container then you don't care
<hatch> brb lunching
<Makyo> hatch, rick_h_ sorry, stepped away for a moment. Issue was there's a set of credentials in fakebackend.js, which was updated, but app.js replaces those with the creds in config.js, which wasn't updated. Wasn't caught in live env because those aren't used, wasn't caught in devel because I had creds in local storage.
<rick_h_> Makyo: ah, gotcha. Well glad it's sorted.
<Makyo> I KNEW we had tests for a reason...
<hatch> Makyo: interesting - so these were the sauce credentials?
<hatch> Anything we can do to make this failure more obvious in the future?
<Makyo> hatch, no, they were just only showing up in functional tests since they didn't have credentials in local storage.  The failure was pretty obvious once I tested !localhost.  That might be a good step for our QA days: clear your local storage cache.
<hatch> ahh 
<hatch> bahaha I love this headline http://www.cbc.ca/news/canada/saskatoon/man-tosses-snake-behind-tim-hortons-counter-over-diced-onions-dispute-1.2864389
<Makyo> Pff hahaha
<hatch> Makyo: could we replace the bundle vis in the gui with the svg generated thingy from jujucharms?
<hatch> would big time speed up the rendering of this details pane 
<Makyo> hatch, we'd lose interaction.
<Makyo> though I believe that's next on the plate for diagrams.
<hatch> Makyo: couldn't we just add the highlight stuff to the svg? 
<hatch> should be pretty trivial no?
<hatch> ok if it's on the plate somewhere :)
<hatch> would save a ton of code
<Makyo> hatch, I guess?  I mean, you'd have to fetch the SVG and embed it in the dom, rather than just including it with an img tag, but yeah, it'd probably work?
<Makyo> hatch, was asked to consider it, but I didn't go much further :)
<hatch> just right now we have to instatiate a whole new canvas with all the relation data etc etc etc
<hatch> so much code/data for that vis
<hatch> especially since we already have it
<Makyo> Yeah.
<Makyo> It's just slack until we absolutely need it.
<hatch> things go to slack to die faster than the backlog
<hatch> lol
<Makyo> :)
<hatch> Makyo: actually I'd really like to prioritize that because it's going to save a bunch of work and time because I'll have to make a separate request to pull down all of the charm data when viewing the bundle details page
<hatch> assuming we do a first step which is simply show a static image without the interactions - any idea how much work it would be?
<hatch> is it simply dropping a link to the page?
<Makyo> Yeah, first pass is <img src="diagram.svg" />
<Makyo> With some scaling, natch.
<Makyo> Have to position it over a crosshatch background, but that might already be there.
<hatch> hmm rick_h_ ^ any chance we could move this up? It'll save me a bunch of work implementing something which will ultimately be removed later anyways
<hatch> yeah tbh I'm not sure - probably though, the crosshatch has to be around there somewhere :)
<hatch> Makyo: would the scaling be just on the image element? 
<Makyo> Second pass is getting the SVG in JS land and embedding it in the dom, third pass is modifying jujusvg to identify serviceblocks, fourth pass is adding interactions back in.
<Makyo> hatch, yep, for first pass.
<hatch> yeah I'd be happy with this regression comparing it to the amount of work which needs to be done on the other side :)
<Makyo> So you're blocked on interactions on a CS release.
<hatch> assuming we care about that regression
<hatch> maybe we do?
<hatch> not sure really
<hatch> I don't think so
<Makyo> I defer to the will of the gods (check with UX and rick_h_ )
<hatch> lower case g ....nice
<hatch> lol
<Makyo> Hah
<hatch> Makyo: see that chlorine thing at the furry thing? 
<hatch> horrible
<hatch> just horrible
<Makyo> hatch, oh my goooosh, I woke up to 850 tweets yesterday.
<Makyo> Thankfully no one was seriously hurt.
<hatch> agreed
<hatch> lol nice tweet
<Makyo> There's definitely folk who feel they've been burned by the fandom enough to do something like that.
<Makyo> This story's making international headlines, apparently :P
<hatch> haha yep
<hatch> I just don't understand how people could make that kind of jump
<hatch> to do something like that
<Makyo> Yeah, it's nuts.
<Makyo> Folk are all sorts of angry, rightfully so
<hatch> definitely
<hatch> lol we have some get icon code which is in utils, which calls a hbs helper, which calls utils
<hatch> moar steps = better? :D
<huwshimi> Morning
<hatch> hey huwshimi 
<hatch> huwshimi: I added some comments to your branch I hope that they make sense
<huwshimi> hatch: Ah thanks, I'll take a look
<hatch> huwshimi: np I have to take off shortly to go pick the car up from the dealer (of course it's done during rush hour) 
<huwshimi> hatch: So instead of .substring(0, 4) you would like to see something like .split('.')[0] + .split('.')[1]?
#juju-gui 2014-12-09
<hatch> huwshimi: hey I'm bacl
<hatch> huwshimi: well we can provide version numbers with 0-3 periods so it needs to be able to parse it appropriately 
<hatch> and any number of digits inbetween
<hatch> and an 'extension' at the end
<hatch> huwshimi: so I'd parseFloat(version.split('.').slice(0,1).join('.')) > 1.21 
<hatch> I think (going from memory) :)
<huwshimi> Yep, that makes sense
<huwshimi> I wasn't thinking that the major version can be double digits
<huwshimi> I think my version would still work as it checks for < but this is probably a more correct way :)
<hatch> huwshimi: yeah it probably would work :) 
<huwshimi> hatch: New version up
<huwshimi> erm, let me just fix the merge conflict
<huwshimi> I knew it was coming
<huwshimi> OK pushed
<hatch> huwshimi: thanks I'll try and get to the review tonight
<huwshimi> hatch: Thanks a lot
<hatch> huwshimi: ok took a real quick look - could you add some tests for the _shouldLockAdmin method
<hatch> basically throw in a ton of different valid semver versions
<hatch> and make sure it returns the correct value
<hatch> you can probably just do one test with a map of version: boolean records that it loops through
<huwshimi> hatch: Sure
<hatch> ok stepping away again :)
<huwshimi> hatch: What do you want test really?
<huwshimi> (Other than what I've tested already?)
<huwshimi> Just full semver numbers?
<hatch> huwshimi: well right now you're only testing the format that we currently have
<hatch> nothing there is testing 3 sections, or with an extension
<hatch> or double digit starting characters etc
<huwshimi> hatch: Sure, any other variations?
<hatch> just looking for semver examples
<hatch> 1.0.0-beta.2
<hatch> that's a funky one
<hatch> lol wut 1.0.0-beta.2
<hatch> er
<hatch> damn 
<hatch> 1.0.0-x.7.z.92
<hatch> that would irritate me if someone actually made a GUI version like that
<hatch> lol
<huwshimi> :)
<hatch> anyways the idea is that we don't want something like the login button to fail because someone put in a 3 section semver 
<huwshimi> hatch: Does that look roughly like what you were thinking?
 * hatch does his best Italian
<hatch> magnifico
<hatch> *moah*
<hatch> that's a spicy meata balla
<hatch> probably wouldn't hurt to put the jujuCoreVersion in a var in the function to help with minification....buuut now I'm just getting picky :P
<hatch> feel free to shippit when it passes
 * hatch steps away again
<huwshimi> hatch: jujuCoreVersion in which function sorry?
<hatch> huwshimi: this is a really long name and repeated twice
<hatch> window.juju_config.jujuCoreVersion
<hatch> but whatever
<huwshimi> hatch: Sure, but if it is stored before this line 'window.juju_config && window.juju_config.jujuCoreVersion' and it doesn't exist it will give an error
<huwshimi> (that's what that line is for
<huwshimi> )
<hatch> right, duh
<hatch> sorry I got no sleep last night :) 
<hatch> about to hit the hay soon
<hatch> 9:30pm man I'm old
<hatch> lol
<huwshimi> haha
<huwshimi> So it's OK to leave as it is?
<hatch> yup
<huwshimi> hatch: Thanks a lot, have a nice evening!
<hatch> anytime, you too! 
<hatch> hows everyones morning?
<hatch> destiny expansion is released today
 * hatch feels a cold coming on
<hatch> ...
<hatch> :P
<hatch> jk
<hatch> uhh wut "Ubuntu Developer Tools Center Renamed To Ubuntu Make"
<hatch> cuz that's not going to be confusing at all
<hatch> *sigh* 
<teslanick> ~ $ ubuntu make
<hatch> make install android-editor
<hatch> wait
<hatch> that's not right
<hatch> :P
<whit> jujucharms is returning 503s
 * whit assumes this is known, but if not...
<rick_h_> whit: yes, in webops working on it as we speak
<rick_h_> ES bit the farm on us
<whit> deleted all if it's own data?
 * whit has heard of a couple big ES crashes lately
<rick_h_> elasticsearch just went red and the logs are confusing java tracebacks that are truncated
<whit> ugh
<rick_h_> so working on a fix and restoration atm
<hatch> rick_h_: did we have an eta on when the deployer will be able to support the new id syntax? I'm trying to decide what I should use as the instructions for the deployer url in the 'Deploy' tab
<hatch> since we can only generate valid ones part of the time :)
<hatch> I'd prefer to put the new id and we just 'hurry' to get the deployer to support the new syntax 
<hazmat> hatch, doc on new 'id' syntax.. i assume you mean bundle store url by that
<hazmat> ?
<hatch> hazmat: https://demo.jujucharms.com/bundle/mongodb/5/cluster/#deploy step 2 on this page
<rick_h_> hatch: not atm, working on production failure still
<rick_h_> hazmat: bundle ids without the basket since that's gone in the new charmstore api
<hatch> I'll leave it blank for now - want to keep moving forward on this
<hatch> this stuff is one step forward, 2 back :/
<hatch> fiddly data bits ;?
<hazmat> huh.. is that even valid
<hatch> no
<hatch> well, yes, but not anymore
<hazmat> deployer doesn't need a basket name anyways..
<hatch> the one in the GUI charm can handle the new bundle id format? Are you sure?
<hazmat> hatch, you just hand deployer a url to json or yaml.. 
<hatch> and it no longer needs the basket?
<hatch> or the name, or whatever we were calling that outer wrapper
<hazmat> hatch, it never did.. that's a hack done speculative reasons re baskets
<rick_h_> hatch: just pass it the url to the new api's bundles.yaml.orig I think
<hazmat> rick_h_, what is the new api.jujucharms.com url for a bundle?
<rick_h_> hatch: it'll look worse since it's not hte shorter url/name but should work
<hatch> ok now you 2 are saying two different things
<hatch> one says you need the orig yaml, the other not
<rick_h_> hazmat: https://api.staging.jujucharms.com/v4/mongodb-cluster/meta/any is the new id
<rick_h_> https://api.staging.jujucharms.com/v4/mongodb-cluster/archive/bundles.yaml.orig is the original bundle yaml
<rick_h_> https://api.staging.jujucharms.com/v4/mongodb-cluster/archive/bundle.yaml is the new bundle format
<hazmat> rick_h_, at least for that charm the new format is valid directly to pass in
<hazmat> er. bundle
<rick_h_> hazmat: ok, if that works even better and we don't have to do the original .orig file
<hatch> I know quickstart doesn't support the new id syntax
<rick_h_> hatch: so you can use that url for that
<rick_h_> hatch: if you give it a url it won't matter
<hatch> ok so the deployer DOES support the new yaml format?
<rick_h_> hatch: it only matters that quickstart is updated to know cs:mongodb-cluster
<hazmat> hmm
<hazmat> hatch, hmm
<rick_h_> hatch: not all of it, like the container syntax
<hazmat> rick_h_, hatch actually it should probably be .orig
<hatch> lol
<rick_h_> hazmat: yes, that should be 100% safe atm
<hazmat> rick_h_, hatch i think i'd need a patch for the flat namespace
<hatch> ok that's what I thought
<hazmat> i think deployer does expect at one top level name key in there
<hatch> ok using the .orig for quickstart and deployer docs
<rick_h_> hazmat: right, we've got on the plate patches for that and the container format
<hazmat> rick_h_, which new container syntax?
<rick_h_> hazmat: from that bundle format spec from a while ago. /me looks for file
<hazmat> rick_h_, the only i remember from that was machines: and a few other incompatible changes i argued against
<hazmat> like dropping vcs support
<hazmat> which don't matter to the store i suppose
<rick_h_> hazmat: https://docs.google.com/a/canonical.com/document/d/1SF8hTBi6oVbki8V__beNij6wnQU-5cm6PZsy5gf0j_Y/edit is the doc MachineSpec I think was the change? allowing them in allowing lxc:0 and such
<hatch> ok so I'm going to put the .orig url for quickstart and the deployer and then we can go back and update it later on whenever we get around to updating them
<hazmat> rick_h_, lxc:0 is already extant.. kvm:new is something new.
<rick_h_> https://github.com/juju/charm/blob/v4/bundledata.go
<rick_h_> I think is the real struct
<hazmat> rick_h_, that seems a little suspect given its also deviating from core syntax re new
<hazmat> seems reasonable though
<hazmat> hmm.. its a little strange though.. cause its almost like its being treated as a constraint
<hazmat> our placement language is in need of some better model definition language.. or rules
<hazmat> rick_h_, of concern is that syntax doesn't seem to support the extant syntaxes for co-location which is heavily used
<rick_h_> hazmat: ok, we should update then to do that while we're doing this then. 
<Makyo> uiteam small review/QA for fakebackend multiple users: https://github.com/juju/juju-gui/pull/675
<rick_h_> kadams54-away: around? missed you on standup
<rick_h_> or did you make it?
<hatch> lunching
<kadams54_> rick_h_: I made standup, but was hampered (delayed, then booted out after initially joining) by kanban board freezing my lappy twice.
<kadams54_> In the end, I was still able to give updates on the switchboard cards.
<kadams54_> Though that reminds me that I need to move those cardsâ¦ after two crashes I decided to wait a bit ;-)
<rick_h_> kadams54_: rgr ok cool
<rick_h_> kadams54_: is there a review for the memcache'd card? no external link listed atm
<kadams54_> The upshot is that switchboard 1.2 is released, which removes memcached dependency, so I'm now working on getting it integrated.
<rick_h_> oh awesome 
<kadams54_> Link added.
<hatch> this is the weirdest error
<hatch> trying to create a charm model
<hatch> Uncaught TypeError: Cannot use 'in' operator to search for 'bubbleTargets' in cs:precise/mongodb-28
<hatch> like-uh-who-what-now?
<rick_h_> lol
<hatch> it's been resolved...but still a very odd error
<kadams54_> Nice. A++ for user friendly error messages.
<jrwren> looks like a python error.
<hatch> ok bundle vis and getting files to go on the bundle details page
<hatch> holy moly this is slow going
<rick_h_> hatch: huh?
<hatch> the bundle details page I have to get it to load files and the bundle vis then it'll be done
<rick_h_> hatch: ok, well let me know if any of it gives you grief
<hatch> oh it most certainly will :P
<rick_h_> :P
<hatch> hmm getting it to pull files was a lot easier than I thought it was going to be :)
<hatch> maybe the pain is over
<hatch> hah!
<hatch> errors in promises
 * hatch throws chair through wall and goes home
 * hatch looks around
<hatch> damnit
<hatch> :P
<rick_h_> hah
 * hatch wonders if he can get Ben back to do this importDeployer stuff again
<hatch> oh github changed the colouring of the diffs
<hatch> woo hooo victory!
<rick_h_> hatch: woot
<hatch> now a few small bits of incorrectly alligned data then it's ready for test
<hatch> holy smoke is it fast lol
<hatch> it actually loads the data before the animation slides out
<hatch> :)
<rick_h_> :)
<hatch> bundle vis takes a bit though so it feels slower
<hatch> but the actual data is loaded and rendered before it's done animating
<rick_h_> wfm
<hatch> yep that can go in slack
<hatch> where tasks go to die
<rick_h_> well we'll see
<hatch> haha, whenever
<hatch> Showing  11 changed files  with 179 additions and 176 deletions.
<hatch> I need to find 3 more lines to delelte
<hatch> delete event
<hatch> DELETE EVEN
<rick_h_> lol, good enough
<hatch> haha I have tests to fix/write now so who knows where it'll end up after that
<hatch> honestly the new colouring on github diffs for js makes it pretty difficult to read
<hatch> orange, purple, light purple, on a pink background
<hatch> it's....so.....beautiful
<huwshimi> Morning
<hatch> I wasn't talking about you
<hatch> don't worry
<hatch> :P
<hatch> morning huwshimi 
<huwshimi> Hey is anyone around that could help with a bit of hacking on the juju charm?
<huwshimi> juju-gui charm that is
<Makyo> huwshimi, I can try, what's up?
<huwshimi> Makyo: I'm just trying to figure out how the 'write_gui_config' method can actually interact with juju
<huwshimi> Makyo: I need to get the output of the equivalent of $juju --version
<huwshimi> Makyo: I just don't know how to do that from inside the charm :)
<huwshimi> Makyo: From in here http://bazaar.launchpad.net/~juju-gui-charmers/charms/trusty/juju-gui/trunk/view/head:/hooks/utils.py#L347
<Makyo> huwshimi, ah, yeah.  Let me spin up an env real quick. Wondering if it's available in an env var like JUJU_ENV_NAME.  Will have to check by running debug-hooks
<huwshimi> Makyo: Ah yeah, possibly
<Makyo> There might also be juju agent information somewhere...
<Makyo> Hunting now
<huwshimi> Makyo: Where would you look for that kind of info?
<huwshimi> Makyo: Sorry I have no idea about this kind of stuff :)
<Makyo> huwshimi, I'm hunting through the docs now (without much luck).  Also, did `juju bootstrap; juju deploy cs:trusty/juju-gui` then `juju debug-log juju-gui/0 config-changed` when that unit was up.  Triggering a config-changed event with `juju set juju-gui juju-gui-debug=true`.  Waiting for that to go through.  When it does, it'll drop me in exactly the same environment the config-changed hook is run in, and I can check `env` and see what juju commands are avai
<Makyo> lable
<Makyo> huwshimi, it doesn't look like there's an env var for version, unfortunately.  However, units have `jujud` installed, and running `jujud --version` gives me "1.21-beta3-trusty-amd64"
<Makyo> huwshimi, so running jujud --version from the write_gui_config function should get us the version string for the unit
<huwshimi> Makyo: With run()?
<Makyo> huwshimi, I thiiink so?  I don't remember if we have a wrapper in the charm like we do in Quickstart
<Makyo> I'll keep digging.
<Makyo> huwshimi, oh, that is the wrapper. 
<Makyo> huwshimi, so yeah, juju_version = run('jujud', '--version') or something like that.
<huwshimi> Makyo: How do I test this?
<Makyo> huwshimi, Good question :P  
<rick_h_> huwshimi: frankban is back tomorrow and he's the charm testing master. 
<rick_h_> huwshimi: but one way is to just do it, spin up the charm, then check the file (config.js or whatever) has the right thing in it. 
<rick_h_> probably as a funtional test
<Makyo> huwshimi, rick_h_ there's also config-writing examples around here: http://bazaar.launchpad.net/~juju-gui-charmers/charms/trusty/juju-gui/trunk/view/head:/tests/test_utils.py#L954
<Makyo> Er, tests for those, I mean
<Makyo> But yeah, if nothing else, get a WIP branch up for frankban to look at
<huwshimi> Makyo: Yeah, so in those they do: with mock.patch('os.environ', {'JUJU_ENV_NAME': 'my-env'}):
<huwshimi> Makyo: could we do patch('jujud...'?
<Makyo> huwshimi, it would be patch('run') and then checking the arguments, but that's about the limits of my off-the-top-of-my-head knowledge of mock
<Makyo> Mock is impressive, but I don't really understand it yet
<huwshimi> Makyo: Ah ok
#juju-gui 2014-12-10
<frankban> uiteam: I need two reviews and QA for https://codereview.appspot.com/188890043 (GUI  charm). Anyone available? Thanks!
<rick_h_>  frankban ty for helping out huw. I'll look in a bit.
<frankban> rick_h_: thanks
<rick_h_> and welcome back :)
<frankban> :-)
<lazyPower> Is the jujucharms.com website in progress of an upgrade?
<rick_h_> lazyPower: yes
<rick_h_> lazyPower: back in a few min hopefully, misfire :(
<lazyPower> ack, i'll hold off on the panic button
<rick_h_> oh I'll panic enough for both of us :)
<rick_h_> uiteam call in 10 thought might be delayed if the production issues go on
<frankban> Makyo: FYI, the car about updating quickstart for new login is likely to involve work on the gui server in the charm. please feel free to ping me if you need help when tackling that
<frankban> card even
<rick_h_> lazyPower: should look better now
<lazyPower> rick_h_: sure does - and started looking that way about an hour ago
<rick_h_> lazyPower: cool well d/l numbers just finished so hopefully all good until next release
 * lazyPower fistbumps
<hatch> lunching
<jcastro> jrwren, rick_h_: proper numbers, <3 you guys
<rick_h_> jcastro: bundles will come next week, little more complicated there. 
<jrwren> jcastro: bundles are definitely coming. I'm finally happy with a solution :)
<jrwren> thanks for the praise jcastro 
<lazyPower> rick_h_: https://api.jujucharms.com/v4/trusty/hdp-pig-4/archive/config.yaml - i call schenanigans
<lazyPower> rick_h_: is this still pending a db refresh or has all that dust settled?
<rick_h_> lazyPower: otp look in a sec
<lazyPower> rick_h_: i stnd corrected - this is indeed in the repository
<lazyPower> disregard my callout
<jcastro> store folks, any idea what's up with this? http://askubuntu.com/questions/558832/juju-fails-to-download-the-charm-dial-tcp-lookup-store-juju-ubuntu-com-no-su
<jrwren> jcastro: that juju user is behind a firewall stopping from reaching store.juju.ubuntu.com?
<jrwren> jcastro: or doesn't have DNS configured, since its a "could not lookup store.juju.ubuntu.com"
<marcoceppi> how is the sorting done on this page? I can't make heads or tails of it
<marcoceppi> https://jujucharms.com/solutions
<jcastro> marcoceppi, looks like # of deploys
<marcoceppi> jcastro: false
<jcastro> oh wait
<jcastro> but that was correct earlier?
<marcoceppi> because wordpress outranks a whole lot of charms on that page and it's like at the bottom
<jcastro> I was just on this page
<marcoceppi> no idea
<jcastro> jrwren, he says he can wget the charm fine
<jrwren> jcastro: http_proxy or something?
<urulama> marcoceppi: trusty and bundles on top, sorted by dl numbers, precise then ... this was a requirement
<jrwren> jcastro: knowing what version of juju may help too
<marcoceppi> urulama: so juju-gui tops mysql but trusty mysql has more downloads than gui
<marcoceppi> urulama: something isn't adding up
<urulama> marcoceppi: bundles are somewhere out of order with 0 downloads, and there is one "precise" at the top ... we'll tweak them in time
<urulama> marcoceppi: that's precise, not trusty ... and ES somehow boosted that to #2 spot
<urulama> marcoceppi: elasticsearch is funny sometimes :)
<urulama> marcoceppi: we have to promote trusty charms over existing precise ones ... otherwise you'd see old charms on the top all the time
<marcoceppi> it seems really backwards that a trusty charm with 2 downloads will out weigh a precise charm with tens of thousands
<marcoceppi> seems it be better to sort by downloaded most since X weeks
<marcoceppi> what's hot now
<urulama> marcoceppi: the thing is, juju-core is not connected to this new charmstore, but the old charmstore, so we don't actually get "dowload events" direclty, but have to "process them" from the old one ... what you're saying will happen, there's just more to it. we need to switch to new charmstore first, and that happens once QA team does test on legacy compatibility with existing juju clients
<rick_h_> lazyPower: ok, glad it's not lying to you
<rick_h_> marcoceppi: jcastro so we're working out the search kinks. The goal is normally to rate based on matching your search term, then the series, then download numbers
<rick_h_> marcoceppi: jcastro so what you're seeing is that the series boost (because if you have two mysql you want the newer one to show up first regardless of download numbers) effecting the other results especially because there's no search term here
<rick_h_> but even that doesn't do great as shown here: https://jujucharms.com/q/apache that the boost didn't seem to get trusty apache2 over precise. 
<rick_h_> so we're still working on trying to tweak the boosts and get it right. 
<rick_h_> we'll have another release next week with more tweaks
<hatch> http://www.redbull.com/ca/en/snow/stories/1331693810256/red-bull-kite-farm-regina
<hatch> saweeeet
<hatch> jrwren: ^ here is a good picture of some kiting :)
<jrwren> redbull <3
<jrwren> that is SWEET.
<jrwren> i wonder why more people around here don't do that.
<hatch> It's learning curve is similar to VIM :P
<hatch> tbh that's why I've seen so many quit 
<hatch> and it's super dangerous if you don't learn slowly
<hatch> but if people can get past that then they usually fall in love
<hatch> nice down to 28 test failures
<hatch> it's especially awesome when something fails but doesn't tell you why 
<hatch> hah
<hatch> ugh mocha is doing it's stupid objects keys need to be in order failures again
<huwshimi> Morning
<hatch> morning huwshimi 
<hatch> rick_h_: hey have you looked at http://www.pivotaltracker.com/why-tracker/how-it-works ?
<hatch> expensive...but maybe better?
<hatch> oh hey in doing these tests I found a big
<hatch> bug
<hatch> yay test
<hatch> s
#juju-gui 2014-12-11
<hatch> hey Makyo you around?
<rick_h_> hatch: no, not looked at that
<hatch> alright
<hatch> I'm tracking down a failure who's traceback is in yui and mocha lol
<hatch> yep a test failure...getting caught by a promise :/
<rick_h_> hatch: you shouldn't be looking at that :P
<hatch> haha I want to try and start tomorrow with a clean slate 
<hatch> ok down to 14 failing tests
<hatch> clean enough slate
<hatch> unfortunately some metadata files needed to be changed - and even more will need to be changed to do the charm page 
<hatch> Showing  20 changed files  with 739 additions and 357 deletions.
<hatch> bleh
<huwshimi> ouch
<hatch> heh more tomorrow :)
<hatch> I might be done with debugging promises though
<hatch> so that's nice
<hatch> lol
<hatch> hmm looks like I have https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/969860 which has either been fixed or invalid :/
<mup> Bug #969860: fglrx uses 100% CPU when screen turns off (spinning in glXWaitVideoSyncSGI or glXSwapBuffers) <amd64> <apport-bug> <battery-power-consumption> <compiz-0.9> <precise> <qa-manual-testing> <quantal> <reproducible> <rls-mgr-p-tracking> <ubuntu> <Compiz:Invalid> <Compiz 0.9.8:Invalid>
<mup> <Compiz Core:Invalid> <fglrx:Confirmed> <The Ubuntu Power Consumption Project:Fix Released> <compiz (Ubuntu):Invalid by canonical-dx-team> <fglrx-installer (Ubuntu):Fix Released> <fglrx-installer-updates (Ubuntu):Fix Released> <gnome-shell (Ubuntu):Invalid> <https://launchpad.net/bugs/969860>
<urulama> hatch: on mac?
<hatch> urulama: mac hardware
<hatch> urulama: I'm running ubuntu on metal on the mini
<urulama> hatch: i know, that's why i'm asking. is it intel or radeon graphics card?
<hatch> the only other problem i've found is the bluetooth finds things but won't connect to them (the internal bluetooth) 
<hatch> urulama: it's the intel one
<hatch> I don't think you can get a mini with a discrete gpu
<hatch> at least you couldn't back when this was made
<urulama> hah, right, mixed it up with old macbooks 
<hatch> oh these test failures are here because they require a 'basket'
<hatch> maybe I should have just started with charms lol
<hatch> somehow I had 14 failing tests, fixed 3 and now I have 13
<hatch> what kind of black magic is this
<frankban> uiteam call in 7 kanban now
<hatch> now up to 19 failures
<hatch> lol
<Makyo> uiteam network problems again, trying to get in the call - if I can't make it in: nothing to note on my cards, nothing to note for the day
<frankban> Makyo: ok thanks
<hatch> google play does a pretty good job picking songs that I like
<hatch> need to save a large data structure for tests? JSON.stringify(results).replace(/\"/g, "'");
<hatch> save so much time :)
<hatch> Nirvana - Smells like teen spirit :)
<hatch> what a blast from the past
<urulama> hatch: followed by Enter Sandman? :)
<hatch> haha no another Nirvana song
<hatch> but I'm sure that's in the queue
<urulama> i had the same LOL moment yesterday with itunes "genious" ... during the "nothing works" part of release, it picked up jay-z's 99 problems :)
<urulama> sometimes i wish i had google glasses just to record those ...
<hatch> haha
<hatch> aww yeah 0 test failures
<hatch> now the question is...does the app still work :P
<urulama> hatch: the tests never lie! :D
<hatch> no - but they might not have all the correct information :D
<hatch> so this branch introduces some more regressions when not using search results because more things are converted to apiv4 from v3 
<hatch> which will mean that until this conversion is done we likely can't push another gui release
<urulama> so the search works, but the tests need to adapt fully, if i understand correctly?
<hatch> well tbh I'm not sure what's going on - the GUI is now getting featured results in the 'interesting' query which don't even exist
<hatch> so I have no idea if this is something broken from the conversion or broken because apiv3 is broken
<urulama> can you paste me the qeuries you're using?
<hatch> I've also had to modify the tokens so that they work with apiv4 so that's likely causing some issiues with apiv3 data
<hatch> ok one sec
<hatch> https://manage.jujucharms.com/api/3/charm/elasticsearch/15/cluster
<hatch> is one of the charms returned by the list
<hatch> returned by the v3 query
 * urulama starts listening Zelda music, feels like being on a quest :)
<hatch> I'd be ok with just saying we can't make a release but would like at least one more +1 :)
<urulama> ;)
<urulama> elasticsearch bundle does not exist in new CS due to clash in name
<hatch> ok sounds like we just can't get around this
<urulama> which i now think might be an error, as we can call it elasticsearch-cluster (looking at the name and bucket)
<hatch> oh ok
<urulama> but it is currently rejected by ingestion
<hatch> yeah and there are others - I don't htink that there is going to be any way around this
<hatch> the bundles detail pages use apiv4 but the non-search results are from apiv3
<hatch> so the id's are different, content is different
<hatch> etc
<hatch> next step is either to fix those results or do the charm details page - either one will have the cart/horse issue
<urulama> why not use details from v4 all the time?
<hatch> it took me 5 days to convert the bundle details page from apiv3 to 4
<hatch> :)
<hatch> that's why
<hatch> lol
<urulama> but you're an expert now, surely you can do it in 2 days now :D
<hatch> haha maybe
<hatch> actually I think I'm going to do the landing-page results first
<urulama> yeah, until you mix v3 and v4 there will be problems
<hatch> urulama: is there an api endpoint for 'most popular' or something like that?
<urulama> i believe that you'll spend more time patching the difference in bundle syntax then doing full v4 switch
<urulama> lemme check
<hatch> urulama: right - that's what I was doing the past 5 days
<hatch> but the default landing results are from v3 which is totally different than what the bundle details page expects
<hatch> so I'll do that next
<urulama> hatch: we order things by download (trusty & bundles first)
<hatch> the charms at least keep the id's the same
<urulama> so you can do https://api.jujucharms.com/v4/search?text=&owner=&limit=10 and get 10 most popular
<hatch> works for me thanks
<urulama> or https://api.jujucharms.com/v4/search?series=bundle&text=&owner=&limit=3 and get 3 top bundles
<hatch> honestly - atm I just want something to put there, we can tweak it later :)
<urulama> hatch: note that this is for latest series, if you want precise then  https://api.jujucharms.com/v4/search?series=precise&text=&owner=&limit=3
<hatch> we'll probably want some kind of a 'consolidated most popular' endpoint for this
<urulama> adding &include=stats would give you the numbers as well
<hatch> can eco feature things in apiv4?
<urulama> and that means ... ? :)
<hatch> https://demo.jujucharms.com/ the top section :)
<hatch> 5 featured
<urulama> ok, lemme try
<hatch> in last discussed we were going to only list the most popular or something along those lines but I figure that we should probably also maintain the ability to feature things
<urulama> https://api.jujucharms.com/v4/search?series=precise&text=&owner=&limit=3&sort=-downloads&include=stats
<urulama> there you go
<urulama> omit include=stats if numbers are not needed
<urulama> ah, sorry, wrong
<urulama> https://api.jujucharms.com/v4/search?text=&owner=&limit=3&sort=-downloads&include=stats
<urulama> this one
<urulama> sorts by downloads
<hatch> ok so no more 'featured' ?
<urulama> not for now
<hatch> ok no problem
<hatch> thanks for the help
<urulama> it's planned for v5
<urulama> np, just ask, i was just starting to get into "bring it on" zone :D
<hatch> haha nah I just want this conversion done then we can revisit stuff to add features back
<hatch> uiteam I need two reviews and qa's on https://github.com/juju/juju-gui/pull/676 plz and thx
<Makyo> hatch, looking.
<hatch> yes it's massive
<hatch> sorry
<hatch> :)
<hatch> I've got to step away for a big
<hatch> bit
<hatch> bbiab
<hatch> Makyo: how goes? Any issues so far?
<Makyo> hatch, just trying to pick what's just a name change and what's a functionality change.  Haven't QAd yet
<hatch> ok np - it did take me forever to do it so don't worry if it take some time to go through
<hatch> lemme know if you have any questions
<Makyo> damnit, running into CORS problems again.
<Makyo> Chrome seems to remember if there was EVER a CORS issue in the past, then NEVER fixes it.
<hatch> lol!
<Makyo> Er,  never allows from that domain.
<Makyo> Huh. Guess that means the GUI will never work for me outside an incognito window.
<hatch> that's very odd
<hatch> can't clear the cache or anything?
<Makyo> I have, no luck.
<Makyo> Haven't tried clearing all browser data, though.
<Makyo> Will do that in a bit.
<Makyo> hatch, QA looks okay, but I'm going to have to go back over the code at least once more.
<hatch> sure thanks
<hatch> uiteam, anyone else around for another review?
<rick_h_> hatch might look tomorrow we'll see 
#juju-gui 2014-12-12
<jrwren> kadams54: would you take py3 compat pr's on switchboardpy?  again, for my own time, not work time :)
<kadams54> jrwren: yup
<urulama> jrwren: why your own time? this helps, so it's UI time :)
<jrwren> urulama: *shrug* itty bitty side project. I don't think we run python3 in our web apps.
<hatch> uiteam need one more review and qa https://github.com/juju/juju-gui/pull/676
<kadams54> hatch: looking
<hatch> thanks - grab a coffee
<hatch> it's big
<hatch> :)
<hatch> uiteam call in 8
<urulama> frankban, jcsackett call
<hatch> urulama: I have a working version of the 'featured' results lists and it all works so it won't block release once this lands
<hatch> just fyi
<hatch> (even if the results are a little suspect :)
<urulama> hatch: big difference?
<hatch> huge heh
<hatch> speed is super nice though :)
<hatch> urulama: it'll be fine for now - but there are certain 'top' results that don't make any sense
<hatch> like why do you need to see the gui charm in the gui :)
<urulama> hatch: like?
<hatch> it'll always be on the top
<hatch> _always_
<hatch> :)
<urulama> shameless self-promotion?
<urulama> :)
<hatch> haha 
<urulama> but, yeah, it's not "featured"
<hatch> yeah, and some will always be on top so I'm not sure how much I like the results...but whatever it's fast and works for now
<urulama> i expect to have that solved by mid-January. and i guess that search is more important than just featured. we can do that if it is really really needed
<urulama> (the featured)
<hatch> yeah I think that sidebar is still in a bit of flux right now as to what should be the default view and whatnot so it'll be fine until we resolve what we want it to do
<hatch> urulama: do we have an eta on the removal of the duplicate results of promulgated charms/bundles? I just added the filter in the FE but would like to make a note as to when this may be removed
<urulama> hatch: same 2nd half of Jan
<hatch> got it thx
<hatch> urulama: featured results list is done, just writing/fixing tests now :) looks like I did something correct when writing the new api :D
<urulama> accidents happen :)
<hatch> lol
<hatch> got to reboot - something is holding on to ports
<rick_h_> hatch just manually filter the gui out. It's specific to the client in this case
<rick_h_> the client can be smart asbout stuff
<urulama> rick_h_: http://25.media.tumblr.com/tumblr_ly977cNcFM1qg6fobo1_500.jpg
<urulama> :)
<rick_h_> I cant get link out of mt tablet irc client :P
<hatch> urulama: lol!
<rick_h_> well ssh to irssi client I think it haytes either tmux or irssi
<rick_h_> so :P
<hatch> so pumped that this conversion of the featured list was so easy
<rick_h_> :)
<hatch> love it when things work out like planned
<hatch> stepping away for lunch 
<hatch> lazyPower: mbruzek looks like the version of Ghost with the email provider support has made it through review https://jujucharms.com/ghost/precise/2
<lazyPower> hatch: bazinga
<mbruzek> booyah
<mbruzek> Nice job hatch
<hatch> now I just have to get on that darn haproxy redirect 
<hatch> haproxy docs suck the big one lol
<mbruzek> rick_h_: Are you there?
<hatch> uiteam lf two reviews and a qa on https://github.com/juju/juju-gui/pull/677
<hatch> mbruzek: he is gone
<mbruzek> hatch: OK thanks
<hatch> anything I can help with?
<mbruzek> hatch: why does the juju-gui charm fail proof?
<mbruzek> not proof, automated testing
<kadams54> hatch: 677 is the one you wanted me to QA?
<hatch> kadams54: yup plz
<hatch> mbruzek: can you point me to the log?
<hatch> aiui it should pass
<mbruzek> http://reports.vapour.ws/charm-tests-by-charm 
<mbruzek> hatch http://reports.vapour.ws/charm-tests/charm-bundle-test-10545-results
<hatch> mbruzek: juju-test CRITICAL: /var/lib/jenkins/.juju/environments.yaml file does not exist
<hatch> and that one you linked looks like it was abandoned?
<mbruzek> hatch I can re-run the tests, but the critical one looks like the test is not compatible with the way CI runs tests
<hatch> hmm that's possible - if you wouldn't mind re-running just to be sure
<hatch> kadams54: lots of removed code in this branch to accomplish almost the identical functionality :)
<kadams54> yay
<kadams54> hatch: in the charmbrowser I see "Recommended" and "Other"
<kadams54> hatch: is that correct? I was expecting "Recommended" to be gone and "Other" to be "Popular" or something similar
<hatch> nope they are just ones which are promulgated and ones which aren't
<kadams54> hatch: here's the recommended I see: http://cl.ly/image/2c2P3b1G221Y
<hatch> yeah
<kadams54> And here are the others: http://cl.ly/image/0w0d351V1E0C
<kadams54> I realize mysql is precise for recommended and trusty for others, but it seems potentially confusing
<hatch> very
<hatch> :)
<hatch> not much else we can do until we get better endpoints to work with unfortunately
<kadams54> And juju-gui/precise is actually duplicated between recommended and others
<hatch> oh it is isn't it
<hatch> that's odd...
<hatch> ohh right
<hatch> gui isn't owned by charmers
<kadams54> I know there's some dupe removal code in thereâ¦ wasn't sure if it was supposed to be catching that
<hatch> ok that's a bug
<hatch> I'll remove the gui entirely from the search results
<hatch> well...
<hatch> nah 
<hatch> i'll just remove the duplication
<kadams54> OK, commented in the PR
<hatch> thank yas
<hatch> uiteam anyone else still around able to do the other review?
<kadams54> hatch: Gotta run now. Once that dupe bug is fixed, I'm fine with landing.
<hatch> thanks
<rick_h_> hatch: we have denormalized api data now right?
<rick_h_> hatch: and I vote we only pull the promulgated most popular, and we talked at one point of pulling extra so we could randomize them a bit?
<hatch> rick_h_: oh is there a promulgated flag?
<hatch> I guess I could do 'owner charmers'
<hatch> rick_h_: https://api.jujucharms.com/charmstore/v4/search?limit=10&sort=-downloads&owner=charmers&limit=30&include=charm-metadata&include=bundle-metadata&include=extra-info&include=stats
<hatch> that seems like a pretty reasonable result set
<rick_h_> hatch use owners=
<rick_h_> (blank)
<rick_h_> that'll only get promulgated
<hatch> oh?
<hatch> ahh
<rick_h_> it's what we use for the /solutions page
<rick_h_> hatch standup real quick?
<hatch> sure
<hatch> doing this will result in a little more work because I'll need a new template but no biggy
<rick_h_> daily ot friday?
<hatch> i'm in daily now
<rick_h_> k sec
#juju-gui 2014-12-13
<hatch> well after about 4 hours of docs and testing I have given in and posted my haproxy question to serverfault :)
<rick_h_> lol
<hatch> http://serverfault.com/questions/652428/redirect-rewritten-url-using-haproxy
<hatch> :)
<hatch> rick_h_: do you have any preference for a good point and shoot for traveling?
<hatch> gona be an xmas gift
<rick_h_> hatch love thge sony rx100 line
<rick_h_> its what i have my wife using
<hatch> can it be whiped out and take a picture faily quick?
<hatch> or does it have to 'expand' 
<hatch> that one does have very high reviews though
<hatch> maybe more than I want to spend though
<rick_h_> yea great but pricey. go back to the 2 or erven 1 to save a little bit
<hatch> they make a model for everything
<hatch> sheesh
<hatch> pretty much in $50 incrememtns
<rick_h_> yea
<hatch> too much choice!
<hatch> there has to be an economic lesson here somewher
<rick_h_> the olympus pen cameras are supposed to be good too
<hatch> sony cameras still require a 'special' usb cable?
<rick_h_> http://www.amazon.com/Olympus-Interchangeable-Digital-Camera-14-42mm/dp/B0096WDNZC/ref=sr_1_2?ie=UTF8&qid=1418512240&sr=8-2&keywords=olympus+camera+epl
<rick_h_> my sony is just microusb i thought
<rick_h_> so the rx i own and like. if anything else i'd go oly epl line
<hatch> yeah I'm thinking $300 would be max
<hatch> it'll probably only ever get used a few times a year
<hatch> cell phones are too convenient :)
<rick_h_> heh yea
<hatch> somehow the $300 sony gets 20x optical where the $800 one gets 2.9x
<hatch> umm
<hatch> one of them is lying
<hatch> :)
<rick_h_> heh well more than zoom in there
<hatch> no website allows you to filter by 'gps' feature
<hatch> bleh
<rick_h_> http://www.dpreview.com is a good review site
<rick_h_> tghough 300 is going to hit mostly the low end markets. 
<hatch> it seems the ones I want are all around that $400 mark heh damn
<rick_h_> who's it for?
<hatch> http://www.bestbuy.ca/en-CA/product/sony-sony-cyber-shot-tx30-18-2mp-waterproof-digital-camera-blue-dsctx30l/10244494.aspx?path=7f723491a5df1890f4c604bc0f7d30e7en02
<hatch> the mrs
<jrwren> hatch: the camera in the iphone6 is nice. :p
<hatch> lol we aren't taking our phones on our trip
<rick_h_> i've got an extra rx100 but no box and csuch
<rick_h_> wife forgot it when we went to va
<rick_h_> so bought the v2 while in va
<jrwren> *mind blown*
<hatch> yeah this cybersex one looks good
<hatch> all the sony cybersex ones are nice
<rick_h_> lmao
<hatch> haha
<hatch> ahh the reviews on these ones look good 
<hatch> does panos
<rick_h_> well let me know. i can ship it up and you can check it out if you want
<hatch> no GPS unfortunately
<hatch> thanks but I don't want to worry about it
<hatch> I'd rather have my own stuff wrecked/stolen
<rick_h_> if you ndon't like bring it in jan to sprint
<rick_h_> just sitting in a drawer since last fall
<hatch> that thing is like $500 :) I'll definitely get stolen 
<hatch> I'm not that lucky
<rick_h_> but yea all good
<rick_h_> heh i'm not worried. it's my fancy camera i worry about
<rick_h_> offer stands, will trade camera for sprint dinner :)
<hatch> bahaha
<hatch> that might work on the new-guy but not this-guy :P
<hatch> hmm can you still search flikr by camera?
<rick_h_> yea
<hatch> ah there it
<hatch> is
<hatch> heh rx100 is popular
<rick_h_> i've done some search by lens feature
<hatch> yeah this tx30 seems to get decent reviews and would probably be good for my activities as well ;)
<hatch> (actually cheape rlocally than on amazon)
<hatch> hmm the dp review of this camera isn't so good
#juju-gui 2015-12-10
<mattrae> hi i'm using juju 1.25.. i am seeing that 'juju status <service>' is hanging forever
<mattrae> juju status <service> used to work a few min ago.. 
<mattrae> now only 'juju status' works
<mattrae> any ideas what might be wrong?
<mattrae> i've also noticed that when 'juju status <service>' does work, its about 10 times longer than just running 'juju status', depending on how many units are deployed
<mattrae> oops wrong channel, meant to go to #juju
<jcastro_> https://github.com/CanonicalLtd/jujucharms.com/issues/178
<jcastro_> anyone have insight on this bug? did a release to prod happen? It appears it has not
<urulama> jcastro_: no, next week
#juju-gui 2015-12-11
<mhilton> morning all
<mhilton> morning rogpeppe
