#juju-gui 2013-04-22
<gary_poster> frankban, teknico, approved all days off.  good timing for those national holidays :-)
<frankban> gary_poster: thanks, and yes, really :-)
<gary_poster> frankban: Firefox: test_gui_unit_tests (__main__.TestBasics) ... ok
<gary_poster> YAY!  Rock! :-)
<gary_poster> Finished: SUCCESS
<bac> :0
<bac> er, :)
<gary_poster> :-)
<bac> hazmat: i'm investigating bug 1170468 -- you have insight?
<frankban> cool, and weird, but cool...
<hazmat> bac, i filed a separate bug.. the nutshell was that setting config/deploying from the gui lead to invalid yaml somehow
<hazmat> bac, a user tried to deploy haproxy from the gui
<hazmat> the backend server does yaml validation, so its not clear why it didn't result in an error
<hazmat> instead it lead to a relation error on the broken yaml
<hazmat> deploying from the cli worked
<bac> hazmat: do you have that bug number?
<hazmat> bac, hmm.. no i might have seen jorge's and stopped.
<bac> ok
<hatch> gooood morning
<gary_poster> morning hatch.
<hatch> thanks for the review
<hatch> sorry there were so many steps to reproduce :)
<gary_poster> welcome, np :-)
<hatch> how was camping?
<gary_poster> great! and exhausting :-)
<gary_poster> frankban, I was thinking of testing the gui against go (monday qa), and then making a release.  does that duplicate anything you've done or are doing?
<hatch> frankban: haha, awesome fix for the CI failures :D
<frankban> gary_poster: no, and I am available if you need help, e.g., setting up the env or similar
<gary_poster> cool thanks frankban.
<frankban> hatch: heh, one loc to fix them all... something in the firefox/selenium/yui ecosystem seems very opaque
<jcsackett> sinzui, hatch: can i get a review on https://codereview.appspot.com/8910043 ?
<hazmat> bac, just to be clear for reproduce.. bootstrap/deploy gui/deploy haproxy from gui
<bac> hazmat: yep
<hatch> jcsackett: ....well I dont' start for another 15minutes....
<hatch> sooooooo joking....I'm on it :P
<jcsackett> hatch: if you want to wait 15 min, that's fine. :-)
<hatch> lol
<hatch> I am going to grab my coffee first though
 * sinzui looks
<jcsackett> hatch: very reasonable. :-)
<jcsackett> actually, i'm going to get some coffee as well.
<gary_poster> frankban, if you are interested in finding a card I have one that might be of interest to you.  "Investigare adding SetUnits to Go API (replacing AddUnits and RemoveUnits in the GUI)."  Whoever starts this would want to talk to Roger first, of course
<gary_poster> *Investigate
<gary_poster> It is in Maintenance
<gary_poster> other options are fine too :-)
<frankban> gary_poster: sounds good. so SetUnits takes a service name and a number of units?
<gary_poster> frankban, exactly.  And delats + GetService would report not only how many services a unit has but how many it is supposed to have
<gary_poster> *how many units a service has
 * gary_poster had three nights of bad sleep in a row :-)
<gary_poster> sigh, delats == deltas :-)
<frankban> gary_poster: but what happens when a service has more units than the ones specified? do we remove random units?
<gary_poster> frankban, this is something to discuss with Roger.  When talking about it with Kapil for pyJuju, he suggested removing the newest instances.  I think arguments could be made for either direction (oldest or newest).
<gary_poster> Maybe a default policy for flags for other policies would be nice, but also maybe not necessary initially
<gary_poster> ...a default policy *and* flags for other policies...
<frankban> gary_poster: :-) doesn't the delta already include pending units in the count? 
<frankban> (I think I have to check for this) gary_poster: last question, following the checklist: why do we want this? :-)
<gary_poster> frankban, delta has pending units: yes, but that's different that the target.  The target should be a single number with transactional semantics.  pending units can easily have race conditions.  Imagine having 5 units, then setting count to 8 (three pending), then *immediately* (before pending units resolve) setting the unit count to 3.  removing units is not instantaneous.  At this point we want to be able to say "
<gary_poster> the target is 3" but if we don't explicitly keep track of the target there are a lot of confusing intermediate states we can see.
<gary_poster> frankban, thank you for asking why, and why now. :-) that might clarify the previous answer
<gary_poster> I actually think there's an old bug for this, come to think of it.  1 sec...
<gary_poster> frankban, #1052675 and #1052676
<gary_poster> https://bugs.launchpad.net/juju-gui/+bug/1052676
<gary_poster> https://bugs.launchpad.net/juju-gui/+bug/1052675
 * gary_poster misses _mup_
<benji> I hate to admit it, but I miss mup a little.
<gary_poster> :-)
<gary_poster> frankban, those are all in reference to the unit count widget on the service page, if that is not clear
<gary_poster> frankban, lemme know if that makes sense--stopping until you ask more
<frankban> gary_poster: yes it does. And I think we also want to maintain the old AddUnits/RemoveUnits, event if they will be no longer used by the GUI
<gary_poster> frankban, +1.  A complication will be that we need to use the old API for pyJuju.
<gary_poster> and try not to make it more broken than it already is
<gary_poster> frankban, an additional complication is that this is the first time we will need to be backwards compatible in the Go API as well!
<gary_poster> I think
<gary_poster> we should discuss with them what we all think is a reasonable support strategy for these sorts of things
 * teknico 's mental state aligned with nation's one: thoroughly befuddled
<gary_poster> :-)
<gary_poster> teknico, about what I've said, or about your current card, or generally?
<teknico> gary_poster, second thing you said
<frankban> gary_poster: yes. so setunits set a target number (on the service doc I guess). if another client (not the GUI) calls addunits/removeunits I suppose we might want to increase/decrease that number accordingly. 
<gary_poster> teknico, ack.  
<gary_poster> frankban, yes.  And Roger said that this will involve a new agent IIRC
<gary_poster> To handle converting the number to a reality
<frankban> gary_poster: ok thanks
<frankban> rogpeppe2: could you please ping me when you have time for a call on the SetServiceUnit functionality?
<Makyo> gary_poster, ping
<gary_poster> Makyo, pong (though I have call in 4)
<Makyo> gary_poster, quick ? then.   Was looking at starting upgrade-charm, but that's not in either juju api. Are we making any changes to pyjuju anymore?
<gary_poster> Makyo, no more changes to pyjuju AFAIK
<Makyo> gary_poster, alright.  Will come up with a list of other questions for call.
<gary_poster> Makyo, cool.  Also maybe worth convening a call with luca and myself when you are ready to have a plan for integration within the current transient UX.  It is not in the 13.10 UX either, but I want the functionality in sooner
<hatch> does anyone know (before I go looking) why the environment fires a 'login' event again 5s or so after the environment is fully loaded
<Makyo> gary_poster, alright.
<gary_poster> hatch, not exactly but I've seen stuff like that caused by...on call.  maybe needs flag
<gary_poster> frankban, maybe try rogpeppe again?
<frankban> gary_poster: talking with him
<gary_poster> oh cool
<hatch> i have noticed that sometimes I get a favicon which is bright orange and sometimes it's kind of a washed out orange...anyone ever seen this before?
<hatch> rick_h_: I saw your post on G+ about the yui2 removal....yay!
<gary_poster> bcsaller, hey.  Could you please add categories metadata to your charm branch?  http://pastebin.ubuntu.com/5592852/
<bcsaller> gary_poster: certainly
<gary_poster> thank you!
<hatch> bcsaller: when you have a second could you take a look at my multi dispatch branch https://codereview.appspot.com/8883043/
<bcsaller> hatch: I'll do it now, I've already glanced at it
<hatch> ok great thanks
<jcsackett> hatch: to make sure i understand your suggestion about the utils thing being an extension. do you mean just create like apiFailingView, which extends view with the apiFailure method? and have other views use that as an extension?
<jcsackett> or something more like rick's event tracker?
<jcsackett> (e.g. a whole new object)
<hatch> jcsackett: can't remember the event tracker...one second
<hatch> yep just like that
<frankban> gary_poster: time for a call?
<gary_poster> frankban, still on another call.  will ping when off
<frankban> gary_poster: thanks
<hatch> jcsackett: do you see why I don't think it is a utility method?
<hatch> an utility method?
<hatch> that just doesn't sound right...
<hatch> a utility method
<hatch> :)
<jcsackett> hatch: yeah, i'm fine with that--i'm just talking about implementing it as an extension.
<hatch> ahh yeah - you can look at the event tracker or the subapp extension
<jcsackett> ok.
<hatch> basically you have to create a constructor so that the mixin methods know how to mix them together
 * hatch wonders if we have a problem when you needmore lines of documentation than the code is long to explain why it's there :)
<Makyo> Explain your spooky action from a distance. :)
<hatch> maybe I'll start commenting // because multi-dispatch
<hatch> and everyone will just know
<hatch> lol
<Makyo> HAh
<hatch> I'm very confused about this extra 'login' event, I don't even know where it's being fired from...
<gary_poster> jujugui please update kanban
<hatch> benji: as soon as I get the email i'll qa
<hatch> email has been very slow for me today though...
<benji> thanks hatch
<benji> hatch: here is the URL: https://codereview.appspot.com/8909044
<hatch> bcsaller: thanks for the review!
<hatch> benji: thanks
<gary_poster> jujugui call in 1
<Makyo> hatch, you can branch from your local repo, then lbox submit -for=lp:juju-gui; one way to do it.
<hatch> oh ok cool, then it will have a proper diff?
<Makyo> hatch, I believe so, but someone correct me if I'm wrong. the diff is part of the merge proposal, which only takes into account the submit branch.
<hatch> ahh ok
<Makyo> hatch, sorry, that should be lbox propose -for=lp:juju-gui, not submit.
<hatch> alrighty, notes
<hatch> noted*
<bac> gary_poster: i've figured out the problem.  would like to chat about solution.
<gary_poster> bac ack will ping
<hatch> bcsaller: just FYI - yes I could just return the _navigate call but it's return value is pretty hidden under a number of levels of abstraction so if it's ok I'd like to leave as-is. I did remove the navigate() overwite though as it's no longer needed
<bac> gary_poster: bug 1170468 is updated.  perhaps we can talk after lunch?
<gary_poster> bac +1
<gary_poster> Makyo, are you blocked?  If you are not I will ping you in about an hour
<Makyo> gary_poster, blocked on the GUI side, but I can start the core branch.
<gary_poster> Makyo, would five min now help, or just wait till a bit later?
<Makyo> gary_poster, the core branch is pretty clear-cut (as much as it can be), can wait.
<gary_poster> cool Makyo thanks.  will ping
<Makyo> It's snowing again >:E 
<Makyo> Everything just melted over the weekend.
<arosales> gary_poster, do you have your staging URL handy?
<gary_poster> arosales, what do you mean?  http://uistage.jujucharms.com:8080/
<arosales> gary_poster, yes, it looks like this is just specific to the gui, thanks.
<arosales> I guess the other URLs are for feature flags turned off/on.
<arosales> gary_poster, thanks.
<gary_poster> arosales, exactly.  welcome
 * benji remembers to do the pre-branch checklist.
 * hatch thanks benji for saving lives
<hatch> bzr question - is there a way to find out which trunk revision I branched my current branch off of?
<benji> is anyone familiar with this test failure on the charm trunk? http://paste.ubuntu.com/5593324/
<hatch> benji: sorry never seen that one before
<gary_poster> bcsaller, see benji ^^^
<gary_poster> Makyo, guichat
<gary_poster> ?
<Makyo> gary_poster, sure.
<gary_poster> cool
<bcsaller> benji: uncertain how that happened, but I can check it in the branch I have going
<hatch> taking lunch
<gary_poster> bac, can talk whenever you are ready
<bac> gary_poster: ok
<bac> now is good
<gary_poster> bac ok guichat!
<gary_poster> bac, fwiw in juju-core/charm/config.go:
<gary_poster> http://pastebin.ubuntu.com/5593455/
<gary_poster> bac ^^
<bac> gary_poster: so it would be trivial to support 'text' in the future
<Makyo> Running to coffee shop to leave dogs alone.
<benji> bcsaller: (I'm back from lunch) I would appreciate it if you can check that failure.
<bcsaller> benji: I suspect my review changes went in w/o running the suite 
<gary_poster> benji, are you blocked by that charm problem?  It looked like teknico was blocked by some issues in the charm right now
<benji> gary_poster: nope, I'm pretending the tests pass; seems to be working ;)
<gary_poster> benji :-P ok
<hatch> is uistage broken?
<hatch> oh someone must have just deleted everything
<hatch> http://uistage.jujucharms.com:8080/:gui:/service/wordpress/constraints/
<hatch> has that entry point always been broken?
<hatch> is there a way I can check from a view if Landscape is enabled?
<hatch> jujugui ^
<Makyo> hatch, var env = this.db.environment.get('annotations'); if (env['landscape-url'])...
<Makyo> app/views/landscape.js:113
<gary_poster> hatch, that entry point works for me--it just shows the environ first.  benji might have filed a related bug, not sure
<hatch> but that will only happen if a delta is fired though no?
<gary_poster> Makyo, doesn't the landscape object offer some kind of abstraction for that as well?
<benji> hatch: topo.get('landscape') looks like the easiest way to see if landscape is enabled
<hatch> and topo would be env?
<benji> hatch, gary_poster: yep, I filed a bug about it
<gary_poster> thx
<Makyo> topo is the topology in the environment view.
<benji> it is caused by bug 1170031
<Makyo> and topo.get('landscape') returns the landscape view.
<hatch> ok so if I go env.get('topology').get('landscape') it will be undefined if landscape isn't enabled?
<Makyo> The topology belongs only to the environment view.
<hatch> benji: gary_poster: ok I am rewriting a bunch of this stuff - it appears to solve the console errors on that entry point, and the flash of env
<gary_poster> great hatch!
<Makyo> get the environment model from the db and see if it has a landscape-url annotation.
<gary_poster> sort of like "great scott!" except that it's your nick, not Mako's last name
<hatch> haha
<hatch> ahhh back to the future, what a great show
<gary_poster> :-)
<Makyo> Oh, the amount of that I got in high school... :)
<gary_poster> lol
<hatch> Makyo: making that check doesn't work
<hatch> the landscape-url annotation appears to always be there
<hatch> i'll try this.get('landscape') as benji mentioned
<Makyo> Then line 423 of app/views/utils.js is not valid, which I don't believe is the case.
<hatch> by default is it enabled then? on devel
<Makyo> hatch, are you running improv or sandbox?
<hatch> improv
<Makyo> hatch, It is enabled if you're passing -l to improv
<hatch> ok here is a little more info...
<hatch> on the root service view we call
<hatch>       views.utils.updateLandscapeBottomBar(this.get('landscape'),
<hatch>           env, service, container);
<hatch> which has the check you said
<hatch> when I add the same line to the constraints view
<hatch> I get an error Uncaught TypeError: Cannot call method 'hide' of null
<hatch> which is fine...
<hatch> but the issue is that `this.get('landscape')`
<hatch> is an object, and the url annotation is there
<Makyo> So the attribute landscape is overloaded with an annotations object instead of being the landscape extension?
<hatch> the attribute landscape is an instance of views/topology/landscape.js
<Makyo> I guess I'm a little confused.  You just said it was an object with the URL annotation.
<hatch> sorry, what I meant was the env.get('annotations')['landscape-url'] property exists and there is an instance of the landscape d3module even though landscape is not enabled
<hatch> so both mentioned techniques don't give me a way to reliably check if landscape is enabled
<Makyo> hatch, I broke on the render function for service constraints view and: this.get('db').environment.get('annotations')['landscape-url'] === undefined
 * gary_poster thinks we ought to have a shared abstraction (like a function) for that
<Makyo> That could be part of the landscape extension, yeah
<hatch> Makyo: that's so odd because the updateLandscapeBottomBar method is throwing an error from within that if check
<hatch> ohh, I figured it out
<hatch> heh
 * hatch bows head and sulks into a corner
<hatch> thanks for dealing with my stupidity Makyo :)
<Makyo> hatch, What was it?  Curious, because now I'm thinking of ways to improve he landscape handling.
<gary_poster> Makyo, I'm having another instance of that crazy jumping service (when you start to drag) :-/
<Makyo> D:
<hatch> container.one('.landscape-controls').hide() was throwing an error and I am apparently dislexic and read the wrong line number
<Makyo> gary_poster, sandbox in chrome?
<gary_poster> Makyo, no, Go environment in chrome.  Was trying to qa for release :-/
<gary_poster> Makyo, reloaded and can't dupe now.  Wonder if it is related to ghost -> drag -> confirm -> drag...
<Makyo> gary_poster, Oooh, I didn't try that when I tested.
<gary_poster> Makyo, yes!  I made one without the ghost drag and it is fine, and then made one with a ghost drag and it is hosed...
<Makyo> gary_poster, A good starting point, then!
<Makyo> gary_poster, Maybe reopen that bug with ac omment?
<hatch> ok I think I can FINALLY push up this service stuff
<hatch> famous last words I'm sure
<gary_poster> Makyo, db attrs from bad and good service: see lines 22 and 23 from bad service
<gary_poster> http://pastebin.ubuntu.com/5593706/
<gary_poster> Makyo, the x and y are being copied over
<hatch> yup
<hatch> famous last words
<hatch> :/
<Makyo> gary_poster, http://pastebin.ubuntu.com/5593719/
<gary_poster> Makyo, !! cool!  Thanks!
<Makyo> gary_poster, I'm not actually running it, but I think that should work?  Does it?
<gary_poster> Trying...
<Makyo>  Oh, that makes it jump back to the default location.  Hmm.
<Makyo> But just temporarily.  Let me see if there's a better way to do it.
<gary_poster> Makyo, fwiw, the attrs are copied over when the model is set on the bounding box.  app/views/utils.js line 756
<gary_poster> So in theory we could exclude x and y
<gary_poster> there
<gary_poster> but would be nicer to actually fix it earlier
<Makyo> gary_poster, yeah.
<Makyo> gary_poster, http://pastebin.ubuntu.com/5593738/ worked for me.
<Makyo> After reverting the previous patch
<gary_poster> ack trying
<gary_poster> Makyo did not work for me.  Digging.  x and y are still set. 
<gary_poster> Makyo, bah, code did not refresh
<gary_poster> Makyo, +1!
 * Makyo would dance, but is in a coffee shop :)
<gary_poster> lol
<Makyo> gary_poster, Should I make a trivial branch for that, or will it be part of your release stuff?
<gary_poster> Makyo, the only thing not necessarily trivial is the test.  Have not investigated yet.  wdyt?
<gary_poster> Makyo, reopening bug atm
<Makyo> gary_poster, quick check, may be fairly easy.
<gary_poster> Makyo, you up for pushing a branch with fix/test through?
<gary_poster> My EoD is soon
<Makyo> gary_poster, sure.
<gary_poster> Thanks Makyo.  Will put into Maintenace Active Code...
<Makyo> gary_poster, https://codereview.appspot.com/8750047 (may be past EOD, sorry)
<gary_poster> Makyo, looking!
<gary_poster> Makyo LGTM, with exclamation marks
<Makyo> \o/!
<gary_poster> :-)
<Makyo> Good to land?
<gary_poster> Makyo, sorely tempting, but we can probably get a quick +1 from hatch?
<hatch> looking
<Makyo> gary_poster, sure.  hatch, 'tis only a wafer thin mp...
<gary_poster> :-)
<hatch> dun
<Makyo> \o/
<Makyo> Going to run home once submit finishes.
<Makyo> Supid sideways snow.
<gary_poster> heh
<hatch> yikes - it's sunny and melting here
<gary_poster> thank you both
<hatch> no problemo, I'm going to propose my WIP branch to get some input but I can't land it until I, or someone fixes the multi login event issue
<Makyo> Alright, back in a few.
<hatch> I think the only thing worse than writing tests....is fixing tests
<hatch> :)
<hatch> what's the truck to get the console logging in the tests working again?
<rick_h_> huwshimi: howdy
<huwshimi> rick_h_: Hey there.
<rick_h_> huwshimi: I was out today, under the weather. I tried to keep tabs though
<rick_h_> huwshimi: so lots of bugs files from UX folks
<huwshimi> rick_h_: Yeah :)
<rick_h_> huwshimi: I started to go through a few. If you get a chance can you see about giving them a run through. Some need discussion/comments/clarifications
<rick_h_> huwshimi: so I'd like to get our questions/etc ready and lined up for calls tomorrow
<huwshimi> rick_h_: A lot were on my to do list anyway, but I'll have a look through them all
<rick_h_> huwshimi: yea, bugs make for handy todo list and a good way for them to know where we are so I say let them file away :)
<huwshimi> rick_h_: Yeah, it's good.
<rick_h_> huwshimi: as for new stuff, I didn't get anything new, but jcsackett was working on landing your branch and had one that started search out
<rick_h_> huwshimi: so have fun and let me know if you need anything.  Any bugs I should bring up in calls let me know and I'll make sure we get info.
<huwshimi> rick_h_: Yeah, looks like he landed my branch. I have a list of stuff to get through. I'll let you know if I have questions. Thanks Rick.
#juju-gui 2013-04-23
<frankban> morning rogpeppe1 
<rogpeppe1> frankban: hiya
<frankban> rogpeppe1: here is the new plan: http://pastebin.ubuntu.com/5594917/
 * rogpeppe1 looks
<rogpeppe1> frankban: hmm, nice idea, but i'm not sure it's guaranteed to work
<rogpeppe1> frankban: what if the ServiceInfo delta was correct (and different to the value that the user has selected), and there's no subsequent delta?
<rogpeppe1> frankban: ISTM that in that case you could show the wrong value for an arbitrary length of time
<rogpeppe1> frankban: i *think* that you'd be best off just living with the slowly updating unit count for now and listing it as a bug to be fixed in juju-core
<frankban> rogpeppe1: AFAICT, after the fact, the first delta can be 1) the one generated by the user changing the total count or 2) a previous one, no longer valid. 
<rogpeppe1> frankban: what if another user is changing the total count?
<frankban> rogpeppe1: I suppose a race is still possible, but we narrow the window, and, anyway, it only affects that user form (for the more important parts of the GUI we still use the unitInfo delta).
<rogpeppe1> frankban: there's another possibility too: the delta generated by the user changing the total count might arrive *before* the reply to the AddServiceUnits call
<frankban> rogpeppe1: we can start ignoring the first delta right after the call to AddServiceUnits
<frankban> rogpeppe1: http://pastebin.ubuntu.com/5594974/
<frankban> rogpeppe1: I see the wrong state in the line 13-14 window, but I think that's acceptable from a UX perspective
 * rogpeppe1 is thinking
<rogpeppe1> frankban: there are other problems too
<rogpeppe1> frankban: for example, if there are 5 units, and two clients both type "20", both clients will add 15 units, and there will eventually be 35 units, even though neither wanted that
<rogpeppe1> frankban: i still think that the best thing to do is not to write partially-correct client code to try and paper over the problem
<rogpeppe1> frankban: but to actually fix the underlying problem
<rogpeppe1> frankban: or... for the time being, change the user interface to add an explicit "add units" dialog, so we don't try to pretend to the user that they're setting the total number of units
<rogpeppe1> s/or.../and, perhaps, /
<frankban> rogpeppe1: that's an UX change, and I don't know if it's doable, I have to ask. Re the problem you are describing, we already have that problem, and we are trying to solve another one (having the form updated with units as they arrives generates confusion and can lead the user to re-type the number he wants in the form.
<frankban> rogpeppe1: and that story ends up with a lot more units to be created
<rogpeppe1> frankban: here's a simpler solution, i think: don't update the displayed unit count while the call is in progress; start displaying the current unit count (from the deltas) immediately afterwards
<rogpeppe1> frankban: no need for any changes to the current API, i think, if you do that
<rogpeppe1> frankban: it doesn't work well with concurrent clients, but i think that's inherent to the current setup, and will be fixed when we fix juju-core in this respect
<frankban> rogpeppe1: but when you restart displaying the unit count, that can be wrong, e.g. you have 5 units and asked for 100. you display 100 till you have a response and then you switch to the number in the delta. at this point you could have 50 units, then 60, etc... we want to avoid precisely that behavior
<rogpeppe1> frankban: i think the unit count at that point will only be wrong for a maximum duration of the poll interval
<frankban> rogpeppe1: so, do you think that right after the response to add/remove units arrives, the next delta is always correct?
<rogpeppe1> frankban: the deltas are always correct :-)
<rogpeppe1> frankban: for some value of correct...
<frankban> rogpeppe1: :-) I mean, when addUnits returns we can be reasonably sure that the delta already sent all the added/removed units events?
<rogpeppe1> frankban: ah, i have another idea
<rogpeppe1> frankban: the deltas are returned in response to a Next API call, right?
<frankban> yes
<rogpeppe1> frankban: so, while you're waiting for the result of the AddServiceUnits call, you don't call Next; when the AddServiceUnits call returns, you call Next immediately.
<rogpeppe1> hmm, that's wrong too, both it
<rogpeppe1> bother it
<rogpeppe1> ah, no, i think it might make sense
<rogpeppe1> nope
<frankban> that's, more or less, the same as not updating the count in the form while waiting for the addUnits response.
<rogpeppe1> frankban: yeah
<rogpeppe1> frankban: ok, another idea :-)
<frankban> and that idea (the old) is better IMHO: more easier to implement, and it does not prevent the rest of the GUI to react to deltas and update itself
<rogpeppe1> frankban: only start updating the form from the deltas from 5 seconds after the AddServiceUnits call has returned
<rogpeppe1> frankban: thus we reduce the window where the user might see an incorrect count, but we run no risk of showing an incorrect value indefinitely
<frankban> rogpeppe1: sounds good, that way we ensure the GUI db already has the correct number of units, correct? because the mongodb is watched every 5 seconds
<rogpeppe1> frankban: yup. maybe make it 6 seconds to account for network delay etc
<rogpeppe1> frankban: and a big TODO to remove this hack when juju-core is changed to fix the issue
<frankban> rogpeppe1: so, this could be the new story: http://pastebin.ubuntu.com/5595088/ with no changes to juju-core, right?
<rogpeppe1> frankban: that seems good. you'll need to make sure that the number of units to add or remove is calculated with respect to the currently displayed value, not the value from the deltas
<frankban> rogpeppe1: yes
<frankban> rogpeppe1: I still think it could be valuable to return unitCount from ServiceGet, so that we can update that number when the user visits the service detail view. I am thinking about the user refreshing that view: we lose the state (and the 6sec sleep), we wrongly display the value from the delta. 
<rogpeppe1> frankban: if the user refreshes the view, the websocket connection is made again and everything is fetched again, right?
<frankban> yes
<frankban> rogpeppe1: the user adds 100 units and then refresh: the form is updated from deltas, and deltas didn't already send all the new units
<rogpeppe1> frankban: the first delta that arrives will have all the units in
<frankban> rogpeppe1: really? so if you add 1000 units they are all send in the same delta?
<rogpeppe1> frankban: yup, that is true currently.
<rogpeppe1> frankban: in the future, we may split the responses, but i think we'll always provide an indication that there's more to come.
<rogpeppe1> frankban: otherwise you can't know when you've seen the whole environment.
<frankban> rogpeppe1: but that delta can arrive after 6 seconds, right? so, if the user refreshes we could display the wrong value for that amount of time
<rogpeppe1> frankban: no, that delta will arrive immediately
<rogpeppe1> frankban: the first delta is always sent immediately
<frankban> rogpeppe1: so, if the user does not refresh, there can be a 5 seconds delay, otherwise the delta is sent immediately. 
<rogpeppe1> frankban: yes
<frankban> rogpeppe1: so, is this correct? http://pastebin.ubuntu.com/5595128/
<rogpeppe1> frankban: yup, looks good
<frankban> rogpeppe1: cool, thanks a lot
<gary_poster> hey rick_h_ you feeling better?
<rick_h_> gary_poster: yea, thanks
<rick_h_> gary_poster: tried to check in yesterday. wonder if we can setup some time to chat about the url/itegration bits sometime soon.
<gary_poster> cool rick_h_, glad.  benji got the add button integration in.  he had it in landing but I just moved it to done because it worked for me, at least for a trivial experiment.  Is it good for you?
<rick_h_> gary_poster: haven't looked yet, giong through huw's stuff from last night. I'll check it out. Thanks for getting that going. 
<benji> Telecommute awsomeness 23: Can't catch coworker crud. ;P
<rick_h_> yea, no kidding
<gary_poster> benji :-)
<gary_poster> cool rick_h_ 
<rick_h_> having kid/dr wife suckiness #1 - they're constantly trying to kill you
<benji> gary_poster: when you have a chance I'd like to discuss the charm build-speeding task I'm on
<rick_h_> and of course I work from home so I don't expose to all that stuff
<gary_poster> rick_h_, time to chat: sounds good.  let me re-review the current UX bugs and then we can talk any time.  I'll ping when I think I have a good overview
<gary_poster> benji, cool.  now, or in 30/45 min?
<rick_h_> gary_poster: benji add buttons seems cool. Thanks again. First integration point check!
<benji> gary_poster: now would be best for me, if you have the time
<gary_poster> yay rick_h_ :-)
<gary_poster> ok benji, to guichat we go
<benji> k
<frankban> gary_poster: morning, Roger and I ended up with this solution: http://pastebin.ubuntu.com/5595128/ Could you please take a look?
<gary_poster> frankban, yeah I saw the conversation and that pastebin.  I was a bit concerned about it but was going to let it go and check in with you later.  I'm on a call now.  ping you later?
<frankban> gary_poster: sure
<gary_poster> thx
<bac> gary_poster: i propose that i fix bug 1170468 by keying off the default value to determine whether to render a simple input field or a textarea.  i'm going to get styling help from the design guys.  follow on work will provide the expansion control you want.  The work needs to be duplicated on the service settings page, too.  are you ok with this incremental approach?
<_mup_> Bug #1170468: Allow multi-line text input for charm configuration in the GUI <juju-gui:In Progress by bac> <https://launchpad.net/bugs/1170468>
<bac> \o/ mup, welcome back
<gary_poster> :-)
<gary_poster> bac, yes, as long as you discuss the expansion control with design guys now too to make sure they are on board with the expected end story
<bac> yeppers.  writing email now.  that's what prompted this running up the flag pole
<gary_poster> cool thanks bac
<hatch> gary_poster: thanks for the review - sorry that prefetch_service code is just old prototype code left in for the units, that will be going away in favour of the promise stuff
<gary_poster> oh cool hatch great
<bac> hi jovan2 and luca____ -- just sent you an email.  would love to discuss when you have time.
<rick_h_> hatch: you in? got a quick question for you. My medicated brain is confused
<luca____> bac: Hi Brad, we'll read it through and get back to you asap.
<jovan2> tiheum ping
<bac> thanks luca____
<hatch> rick_h yup back, just went and spent a few minutes outside - so nice out, frost, -6 sunny,,,,ahhhh
<rick_h_> woot!
<rick_h_> hatch: guichat for a sec? should be fast but easier to say than write
<hatch> sure
<rick_h_> oops, nvm. Diff one
<rick_h_> looks like it's occupied
<hatch> https://plus.google.com/hangouts/_/e7b58b173b15be49a7f0bc948e75d2521b03e375?authuser=0&hl=en
<rick_h_> hatch: https://plus.google.com/hangouts/_/29e068e60e2b16c671698550d1e55971a6091ae3?authuser=0&hl=en
<hatch> lol
<hatch> ok joining yours
<hatch> I figure you pythonites would enjoy this http://www.skulpt.org/
<rick_h_> pythonistas :P
<rick_h_> and no, use the right tool for the job. If you want to do client side then use JS. But I'm a pythonista that can write a few lines of JS when required :)
<hatch> gary_poster: did you have a few moments to chat about the promises stuff?
<gary_poster> hatch soon 
<gary_poster> frankban, guichat?
<hatch> np, lemme know
<gary_poster> thanks will do
<frankban> gary_poster: joining
<gary_poster> thx
<gary_poster> rick_h_, you available for guichat?
<rick_h_> gary_poster: sure thing
<gary_poster> cool
<rick_h_> umm, if my browser will let me
<teknico> bcsaller, I'd like a quick hangout when you're around
<frankban> rogpeppe3: do we already have a bug for the SetServiceUnits functionality? If not, do you want me to file one, so that we can track its progress?
<rogpeppe3> frankban: i think there probably is one; let me check
<bac> jovan2: bigger screenshot sent.  sorry about that.
<rogpeppe3> frankban: i can't find one actually
<jovan2> bac: thanks!
<rogpeppe3> frankban: could you file one please. and please describe your particular scenario too in the report.
<frankban> rogpeppe3: sure
<frankban> rogpeppe3: filed bug 1171899
<_mup_> Bug #1171899: Allow for setting a specific number of units (as opposed to add or remove them) <juju-core:New> <juju-gui:Triaged> <https://launchpad.net/bugs/1171899>
<rogpeppe3> frankban: thanks!
<hatch> oh hey mup, welcome back
<frankban> mup is back, you only love him when he's not around
<hatch> yeah - I wonder if he has any new tricks or if he is a one trick pony
<bcsaller>  teknico: whats up?
<teknico> bcsaller, I'm working on #1171508 and I'd like your opinion
<_mup_> Bug #1171508: install-error when deploying charm <juju-gui:Triaged> <https://launchpad.net/bugs/1171508>
<bcsaller> teknico: I have that fixed in a branch I'm about to propose
<bcsaller> config_get needs --format json
<bcsaller> and then parse using json.loads
<teknico> bcsaller, right
<teknico> exacgtly
<teknico> bcsaller, why are we working on the same thing?
<bcsaller> teknico: I ran into it testing the apache support in the charm just just hit it as a fly by
<bcsaller> didn't know there was a bug for it
<teknico> bcsaller, ok, while we're at it, did you also happen to fix #1171512?
<_mup_> Bug #1171512: Failure in charm unit test <juju-gui:Triaged> <https://launchpad.net/bugs/1171512>
<bcsaller> teknico: I had all the tests passing last night, I'll try to confirm they work with the revs since then, one sec
<bcsaller> teknico: Ran 43 tests in 1.587s, seems good
<teknico> bcsaller, great. how about #1171516?
<_mup_> Bug #1171516: Charm needs more backend tests <juju-gui:Triaged> <https://launchpad.net/bugs/1171516>
<bcsaller> teknico: I changed some of the existing tests, but haven't added more to the backend suite
<teknico> bcsaller, ok, so I guess that one's still standing
<bcsaller> teknico: the existing tests have been updated to work properly like I said. I also changed one of the mechanisms in test utils to be more flexible, I can push what I have now if you want to look at it
<teknico> bcsaller, yes, please. I'll also review your branch once you propose it
<bcsaller> teknico: awesome
<bcsaller> teknico: lp:~bcsaller/charms/precise/juju-gui/apache-version/
<teknico> bcsaller, getting it
<bcsaller> teknico: https://codereview.appspot.com/8640044
<teknico> bcsaller, the related card (no rietveld link in it though) seems to be back  in the Code lane
<bcsaller> I did paste the link in the desc (which I see) and moved it (but it seems to have moved back)
<teknico> weird
<teknico> bcsaller, you want to put that link in the "Add external link" -> "URL" field, rather than in the description (I've done it already)
<bcsaller> teknico: ahh, thanks
<bac> gary_poster: i've got the first branch done.  the textarea looks a little funny wrt inner scrollbar and rounded corners.  i'd like to put it up for a code review now and do styling when the design guys can give me feedback.
<gary_poster> bac ok, UX feedback during review?
<bac> gary_poster: yeah
<gary_poster> jujugui kanban update pls
<gary_poster> bac cool
<gary_poster> hatch didn't forget about you :-) talk after daily call?
<hatch> who are you again?
<hatch> :P
<hatch> haha yeah sure np
<gary_poster> :-)
<rick_h_> hatch: https://codereview.appspot.com/8920043/ if you get some spare time :)
<hatch> viewing
<gary_poster> bcsaller, ping
<hatch> rick will do the review now
<rick_h_> hatch: thanks, I see ther's a small conflict in there I'm lokoing at. but just assume I can get my }, in the right place :)
<rick_h_> hatch: oh, nvm. Doesn't show in reitveld, just LP it looks like
<bac> benji: i found my problem that killed the beautifier
<benji> what was it?
<bac> if you use a bare "default:" (or any other keyword i suspect) as a key without quoting it, the beautifier crashes
<bac> var x = {default: 'something'};
<bac> the linter finds it but the beautifier crashes
<teknico> when there's only the juju-gui service, maybe we should disable the "Build Relation" menu entry :-)
<Makyo> Heading home, back in a few.
<gary_poster> hatch ole buddy ole pal!
<gary_poster> guichat?
<hatch> sure thing
<hazmat> gary_poster, is there a gui staging instance running against go?
<gary_poster> no hazmat
<hazmat> gary_poster, k, i'm trying out the api from python, and doing some of the same things that the gui is doing, but getting errors, wasn't sure if perhaps something bitrotted.
<hazmat> this is just on EnvironmentInfo post login. result. u'Error': u'unexpected end of JSON input'
<gary_poster> hazmat, was working last night, and was going to send announcement today.  Possibly bug 1160971
<gary_poster> ?
<_mup_> Bug #1160971: WebSocket disconnects when an invalid request is sent <juju-core:New> <juju-gui:Triaged> <https://launchpad.net/bugs/1160971>
<gary_poster> hazmat, I mean, GUI plus Go was working last night
<hazmat> gary_poster, cool, it could very well be my client lib doing something silly
<hazmat> rogpeppe, around?
<hazmat> oh.. nevermind.. empty Params struct is required
<bac> anyone have time for a second review of https://codereview.appspot.com/8922043 ?
<bcsaller> bac: I can look it over
<bac> thanks bcsaller
<rick_h_> hatch: jcsackett sinzui any of you guys up for reviews take 2 please? https://codereview.appspot.com/8923044
<bcsaller> oh good, the CI is working on the new charm now
<gary_poster> yay!
<sinzui> rick_h_, I can
<gary_poster> great job bcsaller.  Did you verify that internal links still work--apache will serve up the index.html if you go to /some/url/that/has/no/associated/file ?
<gary_poster> I was going to check that
<rick_h_> in a world all alone among the grey masses...is the juju gui http://uploads.mitechie.com/lp/jujugui_svg.png
<rick_h_> bah, sorry, bet that ping'd everyone :(
 * rick_h_ thinks about filenames better
<gary_poster> yay!  orange!
<bcsaller> gary_poster: I think at this time, no :( I think a 404 handler might do it though
<benji> I've already written a 45 page guide to project-wide IRC pings that will be followed on the next project.
<gary_poster> bcsaller, yeah, that would work.  I think the nginx thing did that--looking how...
<rick_h_> benji: but does it have a simple to use checklist I can use to verify "should I sent this message to irc"?
<gary_poster> rick_h_, when do we get to see the icon at http://uistage.jujucharms.com:8080/bws/sidebar/~juju-gui/precise/juju-gui-43/ ?
<benji> rick_h_: that's coming in Volume II
<rick_h_> gary_poster: when this branch I've put up for review lands
<bac> cool rick_h_.  we should stand out like a beautiful orange flower growing in the asphalt
<rick_h_> gary_poster: that's from my dev instance where I had to fix a bug
<gary_poster> yay rick_h_ :-)
<rick_h_> gary_poster: so the faster it's reviewed the faster you get it *hint hint* lol
<gary_poster> lol
<gary_poster> bcsaller, nginx just did it with a url rewrite (lines 31-33 of https://codereview.appspot.com/8640044/diff/1/config/nginx-site.template?context=10&column_width=80 ).  Probably a better approach, that could be duped in apache
<bcsaller> gary_poster: I initially had mod_rewrite configured in, might have to add it back in then
<gary_poster> yeah
<bcsaller> gary_poster: however all the CI test pass w/o it, do we really need it?
<gary_poster> bcsaller, yeah.  without it you can't pass urls to other people
<gary_poster> bcsaller, we should add a test
<bcsaller> fair enough
<gary_poster> bcsaller, which you don't have to write for this fix :-)
<gary_poster> a bug/card would be sufficient
<benji> gary_poster: I have lots of interesting data to discuss when you get a minute
<gary_poster> cool benji, will ping soon
<benji> k
<hatch> someone ding me? Sorry irc client screwed up
<rick_h_> hatch: did here, https://codereview.appspot.com/8923044
<hatch> alright will do
<bac> bcsaller: regarding your comment about px vs em, i think you've got a good point but since i was just moving an existing value to another place i would like to keep it at 15px.  doesn't make sense to tackle it in just this one place IMO.
<rick_h_> hatch: appreciate it. Nice to end the day on a landing
<bcsaller> bac: yeah, I meant it to sound like I was fine with that happening another time 
<bac> cool
<hatch> rick_h_: I hope you don't expect me to review that json doc :P
<rick_h_> hatch: no, I'm expecting you to ignore it and carry on :)
<hatch> haha
<hatch> what does the svg+xml do?
<hatch> never seen that before
<rick_h_> hatch: fix the svg. It won't right right without it. 
<hatch> interesting
<rick_h_> hatch: since we've not had any charms with icons until just recently didnt' realize it
<hatch> I always thought it was just image/svg
<rick_h_> hatch: you/me both :/ 
<hatch> haha
<rick_h_> hatch: but +xml makes it all worky worky
<gary_poster> benji guichat?
<benji> gary_poster: sure
<hatch> rick_h_: done
<rick_h_> hatch: ty sir
<hatch> no problem
 * hatch is attempting to use sublime only by keystrokes
<gary_poster> Our charm's quality is 0/38!
 * gary_poster is crushed
<rick_h_> hah, need to get reviewed
<gary_poster> :-)
<rick_h_> http://uistage.jujucharms.com:8080/bws/sidebar/~juju-gui/precise/juju-gui-43/ icon is up
<rick_h_> http://uistage.jujucharms.com:8080/bws/fullscreen/~juju-gui/precise/juju-gui-43/ as well :)
<rick_h_> ok, 4 bugs is a good day. Time to run while I'm ahead. 
<gary_poster> cool, ttyl rick_h_ 
<hatch> I wonder if I can dual boot this mac mini into 13.04
<hatch> switching from osx to ubuntu is driving my finger memory nuts hah
<bcsaller> gary_poster: turned out there was a 'new' apache directive for the 404ish thing, much simpler than it used to be.  http://httpd.apache.org/docs/2.2/mod/mod_dir.html#fallbackresource if curious
<hatch> gary_poster: you still around?
<benji> gary_poster: http://jujugui.wordpress.com/2013/04/23/ive-been-investigating-the-speed-of-various-things/
<hatch> nice finds benji
<benji> the S3 speed variability surprised me
<hazmat> s3 is known to be variable..  cloudfront is better for this use case (s3 origin). i'd also check out google storage  as a low latency object store, boto works with it
<benji> yeah, I figured cloudfront would smooth it out quite a bit
<hatch> taking lunch
<gary_poster> hatch around
<gary_poster> bcsaller, FallbackResource: awesome
<bcsaller> yeah, and it all still passes CI
<gary_poster> benji, nice blog, thanks
<gary_poster> bcsaller, heh, awesome
<bcsaller> http://uistage.jujucharms.com:8080/bws/fullscreen/~juju-gui/precise/juju-gui-44/ picks up the icon now, sweet
<gary_poster> Hey Makyo, if this is a quick fix, I made a card for the fact that the scroll wheel behavior is broken in Firefox (try going to http://uistage.jujucharms.com:8080/ and using the scroll wheel to zoom)
<gary_poster> I'll file a bug
<Makyo> gary_poster, About to head out for dogwalk, but will take a look. Hopefully it's something on our side.
<gary_poster> cool Makyo thanks
<rick_h_> bcsaller: :)
<hatch> gary_poster: sorry I missed that you said you were back
<hatch> https://code.launchpad.net/~hatch/juju-gui/set-loaded good middle branch?
<hazmat> afaics constraints in the go api are broken, set followed by get shows no change
<hazmat> or i can spel the key correctly and it works ..
<hazmat> nm
<benji> heh, I did the same thing the other day
<gary_poster> hatch, wow, that still works?  yay for deleting code! :-)
<gary_poster> hatch, then a later branch will move loadService and other db-related bits to the models module?
<gary_poster> +1 so far
#juju-gui 2013-04-24
<rick_h_> hatch: still around?
<hatch> rick_h_: back
<rick_h_> hatch: nvm, thanks. I'm still getting multi-dispatch or something but some of it is my own fault. 
<rick_h_> hatch: and I wasn't sure if your multi-dispatch killer landed for sure
<hatch> rick_h_:  ohh - well it only killed one instance that was causing the multi dispatch
<hatch> :)
<rick_h_> hatch: ah ok. Then I won't raise a flag then
<hatch> current branch kills another....but still doesn't kill the primary culprit
<rick_h_> hatch: cool, thought it might be done/gone. 
<hatch> heh - it's pretty well integrated into the app so it will probably be a while
<hatch> I have a branch which fixes it....albeit very hackily and the app is so fast haha
<rick_h_> yea, I was thinking today you had mentioned a speed improvement and I was thinking "man, I don't notice it"
<hatch> your computer is also 2x as fast as mine though :P
<rick_h_> heh, but still I should get faster too
<huwshimi> rick_h_: Any ideas why the gui might not be loading on a fresh branch today? It hangs on "Connecting to the Juju environment" and it's not spitting out any errors.
<rick_h_> huwshimi: only time it does that is if I don't have the rapi runningin the background
<huwshimi> ugh
<huwshimi> rick_h_: Nevermind :)
<rick_h_> :)
<rick_h_> been there done that
<huwshimi> :)
<hatch> haha
<hatch> yeah it should really have a timeout error
<hatch> :)
<rick_h_> at least make devel should just dump out "hey dude...you're missing a step"
<rick_h_> or even just start it for you
<rick_h_> I've got a make run command that starts my webapp, a combo loader, and celery so you can use/test things
<hatch> ahh that's cool
<hatch> I have a node server installed called `lactate` so I type lactate in any dir and it's a webserver
<hatch> works great for dev
<hatch> https://npmjs.org/package/lactate
<rick_h_> hatch: http://www.linuxjournal.com/content/tech-tip-really-simple-http-server-python :)
<rick_h_> no extra install req'd :P
<hatch> ahh cool - I actually prefer node's limited core install :)
<hatch> but I should have guessed python would have something similar
<rick_h_> ok, I can sleep at night now. Figured out wtf was going on.
<rick_h_> and yay, NAS backup to usb drive is 29/36 hrs done
<hatch> haha wow large NAS
<rick_h_> 1.2TB out of the 2TB. Going to upgrade it to 3TB disks and take the 2TB out and put them in the desktop later on.
<rick_h_> but it's only usb2 and an atom model so taking FOREVER to back it up before I can swap the disks and grow the raid
<hatch> ahh yeah that would be slow
<hatch> :)
<rick_h_> oh well, only have to do it once in a blue moon
<hatch> yeah true true
<hatch> YUI 3.10 will likely go live tomorrow so we should investigate upgrading
<hatch> gary_poster: thanks, sorry I missed your mention earlier. Yeah I wanted to make sure this worked first before moving it to the db code
 * benji rubs the sleep from his eyes.
<rick_h_> benji: +1
<rick_h_> jcsackett: ping when you get in. Think I messed up :/
<benji> :)
<rick_h_> gary_poster: when you say we should be looking at them on OSX do we have a system for that? /me has no apple in the house. 
<gary_poster> rick_h_, I have a mac I can dual boot into.  Also, if it is simply a missing font because the browser is not in Ubuntu, we should be able to see that on IE 10, which we want to test on anyway
<gary_poster> rick_h_, do you have a win machine or vm?
<rick_h_> gary_poster: yea, I have a win vm. I'll admit I probably wouldn't notice the font in that section itself. 
<gary_poster> :-)
<gary_poster> bac I looked at jovan's suggestion to see how G+ did it.  Did you look at that already?
<bac> i just noticed that when running the test-server the URL produced by clicking on a 'describes' heading is now correct and doesn't have to be manually edited.  big thumbs up to whoever fixed that.
<bac> gary_poster: no, i was trying to wrap up my other branch
<gary_poster> makes sense bac.  I'll play with it for a sec and see what I find.  They are using a div with content editable, not a textarea.
<rick_h_> bac: heh, url was correct but the file wasn't loaded. That was hatch and gary_poster :)
<bac> rick_h_: i will buy them a beverage of their choice in oakland
<gary_poster> :-)
<bac> preferably at breakfast
<bac> offer limited to hotel-provided breakfast.  not combinable with other offers.  some restrictions apply.  not valid in nevada or california.
<gary_poster> :-P
<rick_h_> "here's your bagel, don't ask for any cream cheese...enjoy"
<gary_poster> heh
<bac> i do hope the hotel has an omelet station.  it's the only thing that makes work travel bearable.
<gary_poster> bac, http://paste.ubuntu.com/5598238/ is a mostly minimal approach that seems to have the behavior we want.  Did not know how to do that so wanted to figure it out
<gary_poster> Nice that it is pure css
<rick_h_> luca__: morning, do you guys have an icon for the second 'state' of the fullscreen/sidebar toggle button? Huw's asking for it.
<gary_poster> bac, hmm. does not seem to work in ff :-/
<bac> gary_poster: cool.  will look in a bit
<rick_h_> gary_poster: http://caniuse.com/#feat=contenteditable should?
<luca__> rick_h_: We do, I'm checking with Greg now to see if he can find/send you the asset.
<gary_poster> rick_h_, contenteditable does, not that specific page :-)
<rick_h_> luca__: appreciate it. see bug https://bugs.launchpad.net/juju-gui/+bug/1171533
<_mup_> Bug #1171533: There is no "minimised" icon state for the state of canvas icon <charmbrowser> <juju-gui:In Progress by huwshimi> <https://launchpad.net/bugs/1171533>
<rick_h_> gary_poster: ah, gotcha. 
<luca__> rick_h_: Greg has pointed me towards this folder: https://drive.google.com/a/canonical.com/?usp=chrome_app#folders/0B7yNWRv_QU7WVnF2MGktY00wUEE
<gary_poster> works in FF and Chrome: http://paste.ubuntu.com/5598256/
<gary_poster> trying ie
<luca__> rick_h_: however its quite clear that he hasn't completed all of the assets, I'll raise this as a priority task and get them out to you guys asap.
<rick_h_> luca__: ah cool. I don't recall seeing this folder in there before. Was this recently shared?
<rick_h_> luca__: ok, well I'll pass this along to Huw and yea, the ones he's asking for are missing to help complete the bug brought up. 
<hatch> mornin
<rick_h_> gary_poster: we're co-opting our hangout for the ux call https://plus.google.com/hangouts/_/cf491220dfb7736cee2876baf29110eeb52f5997
<rick_h_> morn hatch 
<rick_h_> hatch: since you just redid a bunch of work around interfaces. Are the peer relations used in the gui? I see some code in the environs, but not actually hitting model.get('peers')?
<hatch> peer relations are not used in the gui right now
<rick_h_> hatch: awesome
<hatch> agreed - i hate relations lol
<gary_poster> rick_h_, ack, thx
<gary_poster> rick_h_, hatch, we should support peers, so please don't make that harder :-)
<rick_h_> gary_poster: ok, well right now the backend (charmworld) doesn't present the info in the api so we were looking at if it needs to be implemented/not atm
<rick_h_> gary_poster: so not 'harder' but 'delayed'?
<hatch> noooooooooo
<hatch> I'll be sick the day we need to implement peer relations mkay? ;)
<gary_poster> heh ok
<hatch> haha
<hatch> last night I went to a flooring auction
<hatch> came hom ewith nothing :(
<benji> flooring auction eh?  big night at the hatch household
<hatch> hah - well we decided that we would renovate instead of move so over the next year I'm trying to collect all the supplies :)
<hatch> I figure if I do it right I can probably save 30%
<bac> anyone itching to do a review?  https://codereview.appspot.com/8935043
 * hatch raises hand
<bac> hatch: you practicing for the next auction?
<hatch> I think to practice for that I'll need to warm my wallet up
<hatch> the prices were nuts
<bac> did every item end with "sold to the guy in flannel?"
<hatch> a number of them did....
 * hatch wonders if bac is actually a Saskatchewanian
<bac> i just can't envision a flooring auction in saskatchewan playing out any differently
<hatch> there was one guy in a suit
<hatch> possibly a flooring mobster
<bac> one of the hunt brothers, cornering the market no doubt
<benji> hatch: yep, you should be able to save 30% over having the work done, if you're super frugal you can probably get to 50%.  I do a lot of my own work and would be glad to help out however I can.
 * hatch flys benji here to work
<hatch> :)
<hatch> bac: review done
<bac> thanks
<benji> :)
<hatch> any rap/hiphop fans?
<hatch> how about electronica?
<Makyo> Electronica?
<hatch> trance, techno, house, dubstep
<Makyo> Heh, I spend most evenings getting my ear talked off (in a good way) about all the different genres that fall under that umbrella, but I've not really heard the word in forever.
<benji> hatch: I like some of those, but not enough to purchase much or know many of the artists
<hatch> Makyo: heh yeah there are a lot so I usually start with electronica then drill down from there :)
<benji> http://techno.org/electronic-music-guide/music.swf
<hatch> haha di.fm, I have a subscription to there
<Makyo> benji, , yeah, that's pretty awesome.  Showed that to my professor and we talked about that in studio for two weeks.
<hatch> benji: I forgot about this swf :) thanks....bookmarked
<hatch> I pretty much listen to trance all day long
<benji> oldie but a goodie
<hatch> 140bpm is good for coding :P
<hatch> Trance > Dutch
<Makyo> Hah
<hatch> lol they have some funny names on here
<hatch> buttrock goa
<hatch> and the comment is hilarious
<Makyo> Ishkur's got some opinions :)
<hatch> it needs to be updated!
<hatch> it's missing dubstep!
<bac> gary_poster: did your little html test actually do word breaks in chromium?
<Makyo> Do it in D3.
<Makyo> With HTML5 audio
<bac> gary_poster: nm
<hatch> who has that kind of time?
<gary_poster> bac http://jsfiddle.net/nzHKE/ was hacking this
<hatch> maybe a slack task? ;)
<gary_poster> bac on call
<Makyo> Haha
<hatch> Makyo: actually it could probably be done in a weekend with a couple guys
<Makyo> hatch, digraphs are pretty easy with some of the layout, and now there's http://trifacta.github.io/vega/ which could make it faster.
<Makyo> s/layout/layouts
<hatch> ahh cool cool
<hatch> reviews and qa plz https://codereview.appspot.com/8837049/
<jcsackett> hatch: so, i like things named dubstep, but i'm still trying to figure out what really distinguishes it as anything more than a subtype of DnB.
<hatch> well imho there is real dubstep and then skrillex dubstep
<hatch> :)
<Makyo> Brostep.
<hatch> yeah that
<hatch> hahaha
<jcsackett> hatch: so you've introduced yet more subcategories, but still no real distinction from DnB. :-P
<Makyo> And then there's chipstep: http://chibitech.bandcamp.com/track/moe-moe-kyunstep-part-ii
<Makyo> More impressive for being done entirely on NES hardware :P
<hatch> jcsackett: everything in electronica is a subcategory :)
<jcsackett> that's fair. :-P
<hatch> Makyo: HAHAHAHAHA
<jcsackett> Makyo: interesting. i do like chiptunes...
<Makyo> jcsackett, Me too :)  This is one of my favorites recently: https://soundcloud.com/henryhomesweet/sets/enter-5d
<hatch> and even with all this talk I'm listening to Def Leopard right now haha
<Makyo> jcsackett, Henry Homesweet's pretty neat, since his music's all hardware, most of the time.  http://www.youtube.com/watch?v=CV2hslJjs9U
<jcsackett> oh nice.
<hatch> this is pretty chill
<jcsackett> so, actual chips in the chiptunes. :-P
<Makyo> Heh, yeah :)
<hatch> current podcasts here Above&Beyond Group Therapy, Corstens Countdown, Hardwell On Air, Paul van Dyk's VONYC Sessions, The Sound Of Trance, A State Of Trance, Thrillseekers Nightmusic Podcast
 * Makyo adds https://itunes.apple.com/us/podcast/turn-it-around-electronic/id563798064 to that list.
<hatch> found this cool track last night https://itunes.apple.com/ca/album/lose-sight-feat.-ane-brun/id624001460?i=624001717
<hatch> thanks for the podcast, I'll add it to the list :)
<Makyo> hatch, Whoa, I was just pointed at that yesterday.  Good stuff.
<hatch> haha yeah? I am a fan of Andrew Bayer
<Makyo> Might like http://www.youtube.com/watch?v=ADBKdSCbmiM too, hatch.
<Makyo> If you like Royksopp.
<Makyo> Though it's mostly similar in the video.
<hatch> ahh yeah great song
<hatch> messed up video
<Makyo> Hah, yeah,
<gary_poster> bac did you see how that worked and didn't work?  I didn't get the extraction to work the way we wanted
<gary_poster> that will be the annoying bit of this I think
<gary_poster> Because people can also paste in arbitrary stuff too!
<bac> gary_poster: i haven't had much success with it.  does the box auto grow in height for you?
<gary_poster> bac, yes
<bac> hm, doesn't for me in chromium on quantal
<bac> gary_poster: oh, it does with new lines...which is what we want.  duh.  i was expecting auto-wrap like the g+ example
<gary_poster> right
<jcsackett> Makyo: this is a really nice set.
<Makyo> jcsackett, yeah, I like a lot of his stuff.  
<rick_h_> jcsackett: can you peek at https://codereview.appspot.com/8593050/ please?
<jcsackett> rick_h_: looking.
<hatch> https://codereview.appspot.com/8837049/
<bac> gary_poster: care to look at https://codereview.appspot.com/8935043 ? should be quick.
<gary_poster> wil try bac.  on call
<rick_h_> thanks jcsackett 
<jcsackett> rick_h_: lgtm.
<bac> hatch: on it
<hatch> thanks
<hatch> qa if you could please
<hatch> :)
<hatch> I'm always scared of a net negative diff
<hatch> :)
<rick_h_> those are the best kinds!
<hatch> frankban: yay! Thanks for working on that login bug :)
<frankban> hatch: almost ready for review
<hatch> oh right on u rock
<bac> hatch: so you ripped out all of the prefetch service bits. that was redundant now that handleServiceEvent is doing it when a service is added, no?
<hatch> bac: correct - as soon as the service is added it pulls in the extra data
<hatch> so it's always available when needed
<bac> endpoint.js is becoming a worse name by the day
<hatch> well all of that code will be moved into the db, likely this week
<hatch> it was just the logical place to put it in a multi step process
<gary_poster> jujugui please update kanban
<rick_h_> gary_poster: I've got another call and will be out. 
<gary_poster> ack rick_h_ thanks for heads up
<gary_poster> jujugui call in 2
<hatch> frankban: review done, running make for QA
<frankban> hatch: cool, thanks
<gary_poster> benji call now
<bac> hatch: neither, san juan
<hatch> ahh ok I was just looking at expedia and those are the only two airports it had :)
<bac> hatch: SJU
<bac> hatch: your branch is LGTM pending QA
<frankban> hum... charm install-error in CI
<hatch> ahh I missed SJU
<hatch> yowzas flights are expensive to SJU
<bac> it varies wildly by season.  my flight to SFO was pretty cheap
<bac> guihelp: so juju-core doesn't have debug-hooks.  is there a work around?  what does one do when the service doesn't start?
<hazmat> bac, log into machine (not with juju) examine log files
<hazmat> bac, debug-log is present although it doesn't properly qualify all output by unit
<hazmat> bac, and then juju resolved --retry unit_name
<hazmat> to have it go again
<hatch> frankban: your branch is way more responsive thanks for that fix
<bac> hazmat: ok.  i just liked the ability to run the hooks interactively
<hatch> frankban: if I visit http://192.168.2.119:8888/:gui:/service/memcached/ on `make prod` after logging out, I only get a blank crosshatch
<hatch> well substitute that ip for localhost
<hatch> :)
<frankban> hatch: is this different in trunk? AFAICT make prod does not support fallback resources
<hatch> I'll check trunk
<frankban> thnaks
<frankban> thanks even
<hatch> ok same on trunk
<rick_h_> hatch: 3.10 is out!!
<rick_h_> hatch: speed speed speed!
<rick_h_> hatch: ruh roh: youâll need to change your code to use the new static modifyAttrs() method. 
<hatch> rick_h_: I want to see how fast the tests run using 3.9.1 vs 3.10 to see if the speed differences make any real world impact
<rick_h_> hatch: well I'll let you do it then to see the biggest diff :P
<hatch> haha
<hatch> bcsaller: db means db.service yes
<bcsaller> hatch: thanks
<hatch> the idea is that when you request a service from the db it will always return a promise with a fully populated service
<hatch> no more half data garbage
<hatch> :)
<bcsaller> agreed
<bac> hatch: i was trying to qa your branch on ec2 but the juju-gui charm is failing.
<bac> not your branch's fault
<hatch> bac: oh you can do it locally with rapi no?
<bac> hatch: yeah, i did that and it looked good.  just thought i'd be more paranoid.  i'll approve it now.
<hatch> haha well thanks - if there are any errors I'm sure they will come up soon, although the code will be gone very soon
<jcsackett> Makyo and hatch: can you review https://codereview.appspot.com/8940043 for rick_h_ and me?
<Makyo> jcsackett, Sure thing.
<hatch> I can yep
<jcsackett> thanks!
<hatch> jcsackett: I am pretty sure that we decided for /** and */ with no *'s
<jcsackett> hatch: that's *wildly* inconsistent throughout the code then, and the majority of code i have seen has been with *
<rick_h_> jcsackett: yea, recent style decision 
<rick_h_> jcsackett: that's my fault. I still mix it up sometimes and didn't really share that back with you.
<hatch> it is inconsistent but you went through only one file in your diff and changed it...making it even more inconsistent lol
<jcsackett> hatch: it's the only file i've seen it in without recently.
<jcsackett> since within the subapp it's almost entirely *
<jcsackett> also: i *believe* the linter notices commenting errors only with *. after i added those in, it yelled about a param comment not ending with a period, but skipped it before.
<rick_h_> jcsackett: yea, it's just because no one wants to do the big diff to change them all
<rick_h_> jcsackett: but it's the agreed standard going forward and we're trying to retrain that way
<jcsackett> rick_h_: i mean, i suppose i can uncommit that revision.
<jcsackett> why the recent decision?
<rick_h_> jcsackett: it was brought up on a friday call and agreed to. 
<jcsackett> sure, why? what's the argument for/against?
<rick_h_> because maintaining the *'s is a pita for some. 
<jcsackett> fair.
<rick_h_> and readability can be better without the * I think 
<jcsackett> i disagree, actually. :-P
<jcsackett> but if i'm alone on that, i don't see a need to fight it.
<rick_h_> heh, I tried :)
<rick_h_> but it was a fiar '+1, 0, -1' vote and the *'s lost :)
<hatch> damn democracy
<hatch> it was really the ones who abstained who are causing the issues
<hatch> :P
<rick_h_> lol
<rick_h_> well it's my fault. I didn't make sure to tell jcsackett sorry :(
<hatch> frankban: now that you have 2x reviews can you merge with trunk so that I can merge it into my current branch :)
<frankban> hatch: I am on it
<hatch> thanks sir
<frankban> hatch: and thanks for your review
 * benji lunches/travels to work site number 2.
<hatch> cd ..
<hatch> oops
<hatch> at least it wasn't an admin password
<hatch> :)
<hatch> jujugui do we know why CI is failing with install-error? Or should someone investigate
<bcsaller> It ran fine yesterday, is it possible the npm ppa change broke it?
<hatch> ok, just booting up the laptop to log into it
<gary_poster> hatch we don't know why, and I just asked wedgwood to merge it.  yeah, teknico escaped just in time :-)
<hatch> haha
<hatch> man I really wish the console showed *'s for passwords
<hatch> I have no idea what window I'm typing them into half the time lol
<frankban> hatch: landed
<hatch> thanks
<frankban> have a great week all!
<gary_poster> you too frankban!  have fun!
<gary_poster> hatch, discover anything?  bcsaller, I tried to deploy juju-gui in pyJuju and got this: http://pastebin.ubuntu.com/5598870/.  Is that indicative of a problem in the charm store?
<hatch> gary_poster: it restarted so I need to wait for it to fail agian
<gary_poster> ok hatch
<hatch> that definitely looks like a charm store error to me
<hatch> I've never seen it before
<gary_poster> I'll get Ben's opinion before throwing it to orange squad (or whoever looks at this stuff?)
<hatch> write it on a piece of paper and slide it under their door then quickly walk away
<hatch> ;)
<gary_poster> :-)
<gary_poster> hatch do you have pyjuju installed?
<hatch> rapi?
<gary_poster> no hatch, the real one, installed from pyjuju PPA.
<gary_poster> sinzui, I'm getting http://pastebin.ubuntu.com/5598870/ when I try to deploy in pyjuju on quantal.  Do you happen to know if that is a charm store issue?  I'm trying to see if I can get someone to dupe
<hatch> umm I'm not sure let me see
<gary_poster> bac you around, and do you still have a pyjuju you can use??
<hatch> doesn't look like it
<gary_poster> (sorry, only one question mark intended)
<hatch> I can install it
<gary_poster> s'ok hatch, thanks
<hatch> alrighty
<gary_poster> hatch, unless I can't get anyone else to look at it ;-) then you are on the hook
<hatch> haha booo
<sinzui> gary_poster, I haven't seen that. I am on raring
 * sinzui runs the command
<gary_poster> sinzui, I have the go version on raring and they appear to be incompatible :-/
<gary_poster> they both want to own /usr/bin/juju
<sinzui> ah
<gary_poster> sinzui, you don't dupe?
<sinzui> gary_poster, no. deployed without error
<sinzui> and the service is started
<gary_poster> sinzui, ok thanks.  digging locally
<hatch> hmm I can't ssh into the box
<hatch> it keeps timing out :/
<hatch> now I'm not even sure how to debug it
<hatch> maybe trigger it again and hope that the debug-log catches it
<gary_poster> well
<gary_poster> we should be able to deploy it within our own local juju
<gary_poster> and dupe
<gary_poster> if it is a problem with the charm itself
<hatch> ok is there hacking docs for that? I don't think I've ever done that
<gary_poster> hatch for pyjuju. https://juju.ubuntu.com/docs/getting-started.html
<hatch> oh - yeah I have that up and running, but only for EC2
<hatch> haven't done it with LXC, sorry I misunderstood
<gary_poster> hatch, yeah EC2 is fine for this.  I discovered that I was running into https://bugs.launchpad.net/juju/+bug/1050741
<_mup_> Bug #1050741: juju bootstrap: ERROR [('PEM routines', 'PEM_read_bio', 'no start line')] <juju:Triaged> <txAWS:In Progress by chihchun> <https://launchpad.net/bugs/1050741>
<gary_poster> so easy work around
<hatch> ahh ok - and you figure that's the same bug that the CI is running into?
<hatch> or would you like me to go through the EC2 deployment
<gary_poster> no hatch
<gary_poster> I mean not the same bug
<gary_poster> hatch I'll dig for a bit
<hatch> ok lemme know if you want me to fire off the EC2 deployment
<hatch> using juju 0.6.0.1
<gary_poster> hatch that's very old.  You probably want to install the ppa as that doc describes
<gary_poster> hatch charm works fine for me on ec2, at least with basic deploy :-/
<rick_h_> gary_poster: this on canonistack? abentley was seeing some issues on that today
<gary_poster> rick_h_, yes.  unable to install charm?
<rick_h_> not sure, abentley any notes from the issues this morning? Or since staging is up now it just fixed itself?
<hatch> gary_poster: oh sorry that's the one that is on the canonistack deployment
<abentley> rick_h_, hatch: IS fixed canonistack and then staging came back.
<abentley> rick_h_: It looks fine right now.
<gary_poster> hatch what are are you apologizing for? :-)  ok thanks abentley.  how long ago was that fix, roughly? less than an hour ago?
<gary_poster> canonistack fix, I mean
<hatch> cuz I'm Canadian I guess :P
<gary_poster> hatch :-)
<hatch> I fired off another build
<hatch> maybe it'll work with the fix that abentley mentioned
<abentley> hatch: I mean that all of canonistack was broken, and then IS fixed all of canonistack.  Right now, canonistack does not look broken to me.
<hatch> lunching....I'll monitor this test as close as I can
<hatch> yeah I think canonistack is broken again
<hatch> the last 3 have failed with canonistack type errors
<gary_poster> bac, fwiw http://jsfiddle.net/Pegsa/ .  Fiddles with it while doing other things.  Note dependency in "External resources."  Kinda gross, but I like the UX effect, and I think everything else I'm doing is necessary.
<gary_poster> but possibly not sufficient
<bac_> gary_poster: i'll have a look in a sec
<bac_> landing the second branch now
<gary_poster> np, no rush
<gary_poster> awesome
 * benji remembers to start his IRC client.
<rick_h_> benji: quiet day eh?
<benji> heh, well, for the last hour at least; I relocated during lunch
<benji> for very time-geeky reasons you shouldn't make a npm cache file on back to back seconds if one of those seconds is a leap second; I don't think that'll be much of a problem
<gary_poster> wow, how did you think of that benji? :-)
<hatch> lol!
<benji> I needed an easy to generate "version number" and used seconds since the epoch, which almost monotonically increasing, except at the end of a leap second it ticks forward and then back again
<benji> it means you could get two cache files with the same version if it takes less than a second to generate a file and you generate it on the second before and the second during a leap second
<gary_poster> thanks for explaining benji.  my worry is low. :-)
<benji> lol
<benji> I wonder if I can make a career as a vim/time consultant.
<hatch> you could....but you would probably be broke
<hatch> ;)
<benji> heh
<gary_poster> heh
<hatch> well maybe you're independently wealthy?
<benji> I'm independently broke.  That's almost the same.
<hatch> lol, that seams like a much bigger clu
<hatch> b
<hatch> I've been a member for a long time
<benji> better than being dependently broke, I guess
<hatch> isn't that what happens when you have kids?
<hatch> at least that's what my parents kept telling me
<benji> heh
<hatch> can someone point me to the entry point where the new services get added into the database?
<gary_poster> hatch what new services?
<hatch> well on initial load of the application
<hatch> where does that delta get parsed
<hatch> I can't seem to find the place where the new models get pushed into the ml
<gary_poster> hatch it comes through the py environment, which fires a delta event, which is consumed by the onDelta method in models/models.js
<hatch> ahh that's why I coudln't find it....it's using each and not add :)
<hatch> thanks
<gary_poster> welcome
<bac_> Makyo: drag your branch got a late red card
<hatch> I don't think I've ever been this deep down the rabbit hole
<hatch> who knows what I'll come up with!
<gary_poster> :-)
<Makyo> bac_, sorry.
<bac_> Makyo: not your fault
<bac_> bac_: and i'm not aggrieved
<Makyo> Put it in landing until we figure out whether to revert or fix on top.
<bac> gary_poster: what about this?  am i missing something?  http://jsfiddle.net/EBhpS/
<gary_poster> bac, you're referring to fewer replacements than http://jsfiddle.net/Pegsa/ ?
<bac> gary_poster: no, i pasted the wrong thing
<gary_poster> bac, a few things are different, if so.
<bac> ignore that
<gary_poster> ok
<bac> gary_poster: i forgot to click 'update'
<bac> gary_poster: http://jsfiddle.net/EBhpS/1/
<bac> gary_poster: why can't we just get the innerText?  is it more complicated?
<bac> gary_poster: oh, i see it only works on webkit
<bac> :(
<gary_poster> bac, I tried ctl.get('text').  That did not preserve whitespace properly
<gary_poster> largely because preserving the whitespace cross-browser is a bit of a heuristic, it seems. :-/
<gary_poster> bac textContent is FF equivalent, but does not behave as we want
<gary_poster> equivalent to innerText
<bac> yeah, textContent is pretty worthless
<bac> here
<hatch> where can I guarantee that charm data is available in the db?
<hatch> it almost appears to be transient but I'm sure I'm just missing the magic entry point
 * bac walks dog, waves to disney ship
<hatch> oh nm I was doing it wrong
 * Makyo dogwalks.
#juju-gui 2013-04-25
<hatch> rick_h_: are you around?
<rick_h_> hatch: yea, what's up?
<hatch> questions about your proposed branch
<hatch> is that for the little tab to open the store?
<rick_h_> hatch: shoot
<rick_h_> right
<rick_h_> that opens/closes
<hatch> so why couldn't you have a simple css based tab with a open/close method on the subapp ?
<hatch> it looks like that's all it's doing but with way more code
<rick_h_> hatch: no, because it needs to be state, back button enabled, urlable, etc
<hatch> well doesn't it only have two states? shown and not?
<hatch> and it's shown if the other two are closed
<rick_h_> hatch: maybe I'm not following. So there's three 'states' to the browser. minmized, fullscreen, or sidebar view. And tomorrow I have ot add a hidden state as well
<hatch> wana guichat it?
<rick_h_> hatch: and I was going to ask to pair up on that because whenever we're on the juju-gui interior views, we have to get the sidebar to go to a hidden state and make sure the back button pops it back to the old state/etc
<rick_h_> hatch: can we setup first thing tomorrow? I've only got 20min left here at the coffee shop
<hatch> oh yeah sure np
<rick_h_> hatch: cool, let me konw when you get in tomorrow morning and we can chat as I wanted to grab your time on the hidden state stuff as well.
<hatch> going out tonight so it definitely wont' be before my usual time (8am) :)
<rick_h_> hatch: rgr, have fun
<hatch> currently 7:40pm
<rick_h_> yea, add 2hrs here
<huwshimi> rick_h_: In fact the minimised sidebar needs to remember its state so that when you open it again it remains the same as it was before you minimised it
<rick_h_> huwshimi: right, so it should. It pushes a new state and doesn't change anything like charmids, search input, etc
<rick_h_> huwshimi: so when you open it, it reloads. When we get the cache into place it'll avoid that reload as well
<rick_h_> huwshimi: but that cache state stuff will be later on. For insance we can cache the interesting charm list and search results from fullscreen/sidebar and such
<huwshimi> rick_h_: Ah I see your branch actually does that, but shouldn't it just be the real sidebar there that is just moved over?
<huwshimi> (Although I don't know how that should be handled when you were in full-screen mode)
<rick_h_> huwshimi: so yes/no. Yes, but that'll be harder since we'll have this state change but moving it over while this took me 2hrs tonight to add
<rick_h_> huwshimi: so going with this for a first pass that does what it should and we can look closer at how to do it with sidebar/fullscreen/animation/etc as a later improvement
<huwshimi> rick_h_: Yeah, fair enough, that makes sense
<hatch> rick_h_: btw- 3.10 doesn't make any apreciable difference in speed in the tests :(
<hatch> appreciable
<rick_h_> hatch: :(
<hatch> yeah....oh well
<hatch> here's hoping 3.11
<hatch> :)
 * hatch out!
<rick_h_> hatch: we'll just have to fix our crap and make it faster :P
<hatch> haha
 * hatch really out!
<gary_poster> uh-oh, new version of nodejs....
<rick_h_> lol, run for the hills!
<gary_poster> :-)
<gary_poster> ugh, that's a lot of fonts to download.  Did you do a comparison on the download size rick_h_ ?  I'm fine with that landing, but I may want to negotiate with UX if this is a big increase
<rick_h_> gary_poster: yea, I'm looking at it qa'ing it now
<gary_poster> cool thanks
<rick_h_> gary_poster: 482B gzip
<rick_h_> gary_poster: well that's the css
<gary_poster> B?
<rick_h_> gary_poster: there we go, 164KB in fonts
<gary_poster> heh
<rick_h_> for the woff font in chrome
<gary_poster> what was it before do you know?
<rick_h_> I'm checking aganist uistage
<gary_poster> cool
<rick_h_> gary_poster: 164? what it says but wtf
<gary_poster> uh
<gary_poster> ooooh kay
<gary_poster> :-)
<gary_poster> maybe the different weights are done programmatically?
<rick_h_> checking in FF. Havnig a hard time buying it
<gary_poster> thx
<bac> oops, i forgot to wear my raring t-shirt today.  /me changes
<gary_poster> :-)
<rick_h_> gary_poster: oh, so that's the old value. my local instance didn't pick up the change to index.html so it's still loading the old size
 * bac much better
<rick_h_> gary_poster: so the update isn't much bigger 205KB, but it's 5 files :/
<gary_poster> :-/
<gary_poster> rick_h_, was how many before? 1?
<rick_h_> gary_poster: yea, one request out. Trying to see why it changed to 5. Not used the google webfonts much beyond "I want this font, load"
<gary_poster> yeah, me too.
<rick_h_> ah, css at least seems to have a diff url for each font/weight
<gary_poster> ah that makes sense
<rick_h_> well, but had hoped google would combine. Almost wonder if it'll to all of the ubuntu font in one request but larger size that's cached
<rick_h_> gary_poster: ok, so I dropped the Book 300. Not sure if we need that one. Got it down to 4 requests. but yea, I'm not sure how to drop it down more without getting UX to agree to limit fonts combo/italics
<rick_h_> http://www.google.com/fonts/#UsePlace:use/Collection:Ubuntu+Mono:400,700,400italic,700italic|Ubuntu:400,500,700,400italic,500italic,700italic
<gary_poster> rick_h_, ok, thank you.  I'd love to have your research saved someplace for later discussion...
 * gary_poster thinks
<gary_poster> jujugui blog?  I can put it there or give you posting privs
<rick_h_> gary_poster: yea, I'll put this up for review if that's ok and move forward, but file a bug/card to talk with UX on it. 
<gary_poster> ok perfect thanks rick_h_ 
<rick_h_> gary_poster: sure, I can post something there. 
<gary_poster> your choice rick_h_ .  I'll go ahead and give you privs, and then you do whichever you prefer
<rick_h_> gary_poster: ok, changed my mind. Did some more tweaking, posted to the blog. Thanks for access
<rick_h_> gary_poster: if you get a sec, can you +1 the changes since you've peeked at it and we've had the chat?
<gary_poster> rick_h_, will do.  thanks for blog post and for the further imporvements you talk about
<gary_poster> rick_h_, LGTM done
<rick_h_> ty much
<hatch> morning!
<rick_h_> morn
<hatch> rick_h_: looks like I made it an hour early
<hatch> lol
 * hatch isn't here
<rick_h_> hatch: :P yea, I need a sec to swap out hard drives so come back later 
 * gary_poster looks around, sure he just heard hatch somewhere,,,
<hatch> haha
<rick_h_> my backup of my backup of my NAS finished after I started work so finally can swap the second drive out
 * benji sees a hatch-shaped ghost fly through the wall.
 * rick_h_ sees some green goo left behind on the wall and hopes he doesn't have to clean it up :)
<hatch> do we have any beer connoisseurs?
<rick_h_> wine?
<hatch> http://www.ratebeer.com/beer/westmalle-dubbel/2205/
<hatch> taists like cherry chocolate :)
<gary_poster> ugh
<gary_poster> anyone remember where the pyjuju logs are?
<gary_poster> on the machines
<gary_poster> jujugui ^^
<bac> gary_poster: /var/lib/juju/units/.../charm.log ?
<bac> i'm not sure about the exact path but you should be able to follow from /var/lib/juju
<gary_poster> bac that's it! thank you
<gary_poster> hatch, probelm in CI is that make distfile is failing with this: http://pastebin.ubuntu.com/5601096/
<hatch> oh awesome you were able to log in
<hatch> looking...
<gary_poster> I assume we can dupe after a make clean-all
<hatch> ugh not that again
<gary_poster> hatch, what is that?
<hatch> it's a versioning issue
<hatch> something between imagemagik and spritegen if I remember correctly
<gary_poster> ah
<hatch> this happened right after we switched node to 10.x right?
<gary_poster> so what was the resolution before?  (and why is it failing only in Canonistack, I wonder?)
<gary_poster> yes hatch
<hatch> can you do a version check on node, npm and the depdendencies so we can compare them to the working local versions
<hatch> maybe for some reason it's getting a different version?
<rick_h_> hatch: ready to chat whenever you are
<hatch> I can help look through the dependency list if you like as it's pretty large
<rick_h_> luca_: so I'm using https://chrome.google.com/webstore/detail/whatfont/jabopobgcpjmedljpbcaablpmlmfcogm?hl=en to check the fonts and only the readme is incorrect. One suggestion would be to launch a private browsing session so that it should break appcache/js cache and view the page? http://uistage.jujucharms.com:8080/bws/fullscreen/precise/cassandra-2/
<gary_poster> hatch, http://pastebin.ubuntu.com/5601114/ .  Shouldn't the dependencies be the same because of the shrinkwrap?
<hatch> yeah they should be
<hatch> but outside of the versioning I don't know what else could cause this error
<gary_poster> I'm looking to see what version of ImageMagick is on a working precise instance
<gary_poster> I'm also thereby running make distfile there
<gary_poster> it may be that we don't see this normally because we don't normally start the charm form a branch, and we are just broken on Precise
<hatch> ohh that's possible
<hatch> let me know if you want me to look into it more
<hatch> rick_h_: guichat?
<rick_h_> hatch: sure
<abentley> rick_h_, alejandraobregon, luca_, jovan2: I've fixed staging, so uistage should also be fixed.
<rick_h_> abentley: thanks! what was up? some charm bomb things out?
<abentley> rick_h_: mongodb and elasticsearch had config-changed errors, but I don't know why because the debug logs are jammed up back to April 19.
<luca_> rick_h_: I sent you an email of what I see in my chrome
<luca_> rick_h_: the Ubuntu font isn't showing on the headers
<luca_> rick_h_: but it shows in the body copy
<rick_h_> luca_: k, otp
<hatch> gary_poster: I'm going to get back on this service details stuff, but before I do that did you want me to look into this error or do you have it?
<rick_h_> luca_: after this call can we do a hangout on your machine and try to use screen sharing/etc to walk through checking it out?
<gary_poster> hatch, problem is in charm making distfile
<gary_poster> hatch, if you change juju-gui-source=lp:juju-gui
<gary_poster> then you can dupe
<gary_poster> hatch, so simplest solution is to just revert the change
<gary_poster> hatch I'd like to keep teknico's doc changes
<hatch> yeah reverting to node 8.x is a quick fix - just need to change to the legacy ppa
<hatch> although that's not going to be available forever
<rick_h_> hatch: can you look over that branch please?
<hatch> sure
<rick_h_> hatch: ty much kind sir
<gary_poster> hatch we can make our own PPA, as I proposed (on call, sorry)
<hatch> oh right - yeah that should really help solve a lot of our issues....assuming that making our own PPA isn't a huge PITA (I have no idea how that's done)
<gary_poster> very easy
<hatch> ohh ok well in that case....maybe I Should do it so I can learn how ;)
<Makyo> Black magic going on in this dumb zoom code.
<hatch> rick_h_: after I reviewed your branch I had an idea about the url stuff re minimized, lemme know when you have a second
<rick_h_> hatch: yea, I need a few please. Trying to multi task around calls has me in cirlces atm
<hatch> no rush whenever you have time
<hatch> but I would really like some starbucks
<hatch> hmmm.....
<rick_h_> hatch: guichat?
<hatch> sure
<gary_poster> hatch I'd like to get the charm fixed up ASAP so I can send a juju-core announcement
<gary_poster> hatch, talk through it when you are available?  you may be on another call now
<hatch> sorry on call with rick_h_
<gary_poster> ack
<gary_poster> bcsaller, hey.  I'd like to talk over your current card with you when you get a chance, please
<hatch> gary_poster: done - did you want to chat?
<gary_poster> hatch sure
<gary_poster> guichat
<bcsaller> gary_poster: I'm around to chat after that 
<gary_poster> thanks bcsaller 
<gary_poster> will ping
<rick_h_> luca_: ping, still around? 
<gary_poster> jujugui please update kanban
<luca_> rick_h_: I'm available now, are you?
<gary_poster> jujugui call in 2
<luca_> rick_h_: https://plus.google.com/hangouts/_/cf491220dfb7736cee2876baf29110eeb52f5997
<rick_h_> luca_: one sec
<luca_> rick_h_: np
<hatch> oh yay they dropped off our curbside recycling bin.....just what I always wanted...to pay for things I already do now for free
<hatch> crap, I pushed to the wrong branch and now lbox thinks that's the one it should push to
<hatch> anyone run into this before?
<benji> hatch: I think you can do a bzr push with --remember to the right branch and lbox will use it from then on
<hatch> ahh ok - I just deleted it and started over
<hatch> but I'll remember that next time
<hatch> gary_poster: bcsaller https://codereview.appspot.com/8631048/ plz
<hatch> rick_h_: is the router approach working?
<rick_h_> hatch:  no idea yet. Been sidetracked in calls for a bit
<hatch> gotcha np
<hatch> oh I gota push this to a trunk branch for it to be able to work
<hatch> poop
<hatch> I forgot about that issue
<rick_h_> jovan2: looks like luca ran away. Can you verify that the fonts are all ubuntu for you on staging now please? http://uistage.jujucharms.com:8080/bws/sidebar/precise/ceph-7/
<jovan2> rick_h_ will do
<jovan2> rick_h_ looking good :)
<rick_h_> jovan2: yay!
<benji> gary_poster: did you ever figure out where pyjuju puts the logs?  I'd like to look at the gui charm log output.
<gary_poster> benji /var/lib/juju/units/.../charm.log.
<rick_h_> jovan2: questions posted on https://bugs.launchpad.net/juju-gui/+bug/1172790
<_mup_> Bug #1172790: Lots of empty space below charm details <charmbrowser> <juju-gui:New> <https://launchpad.net/bugs/1172790>
<jovan2> rick_h_ will send charm icons to you in a mo...
<benji> thanks
<rick_h_> jovan2: cool, for the featured charms? Those really go to jcastro and arosales 
<rick_h_> jovan2: I can't get those in
<jovan2> rick_h_ yeah but you're being copied in ;)
<rick_h_> jovan2: ah ok thanks
<arosales> rick_h_, I'll work with my team on getting some merge requests for the icons into charms if I don't have time myself today.
<rick_h_> arosales: thanks! I'm working on getting manage.jujucharms.com up and to the latest release so we can get them marked as featured and add QA to somem of them as well
<rick_h_> arosales: that'll probably be tomorrow
<arosales> rick_h_, sounds good
<rick_h_> oh yay, the browser toggle branch landed on staging as well jovan...who left
 * rick_h_ hits toggle over and over bwuhahaha
<hatch> lol
<hatch> the node downgrade appears to be deploying properly on EC2 once it completes all the tests I'll land that branch and get our CI back on track
<hatch> but for now I'm going to grab lunch
<rick_h_> does JS regex not support /^\/(charms|unit)/ ? for matching a set?
<gary_poster> rick_h_, yeah, that would match /charms or /unit or /charmskumquat or /charms/kumquat and so on. :-)
<rick_h_> gary_poster: hmm, regex tester fails only matching charms. I'll mess with it some more
<rick_h_> I think I'm doomed anyway since I see there's no way to negate that in JS
<gary_poster> rick_h_, http://pastebin.ubuntu.com/5601849/ wfm <shrug>
<rick_h_> gary_poster: cool thanks
<hatch> rick_h_: oh yeah regex tester has some odd issues, it claims to work with everything js regexy but I've found a number of issues, I usually just try it in the console
<hatch> gary_poster: I read charmskumquat as charmsqat lol
<gary_poster> :-)
<hatch> tests all passed and the branch has been submitted
<hatch> so CI should be back on track now
<rick_h_> hatch: so I've got a working prototype here but I'm worried if this will always hold true: http://paste.mitechie.com/show/949/
<hatch> ok looking
<hatch> why would it always hold true?
<rick_h_> I'm worried will :gui: always be in the url?
<hatch> unless it's on /
<hatch> at which point that should be false, and then show the browser
<rick_h_> hatch: not that i'll always be true, but that this regex will always catch the internal views. Does :gui: every go out of the url?
<rick_h_> hatch: ok, cool then
<hatch> if /service /unit or /charms are in the url, it will be under the :gui: namespace
<hatch> at least unless something else changes of course
<hatch> anyone have any idea why `this.get('env')` in serviceList will return an array of undefined values equal to the number of services in the environment?
<hatch> I'm pretty baffled, the envChange event is being fired with an undefined event facade
<hatch> O K now I'm bonified confused because it's working now lol
<rick_h_> hatch: hmm, login/logout view?
<hatch> imho it should be hidden and so should the little toggle button
<hatch> but I don't know how much say I have in that decision :D
<rick_h_> hatch: yea, but there's no url to check on those
<rick_h_> it's determined mid-request processing it looks like?
<hatch> { path: '/logout/', callbacks: 'logout'}
<hatch> ?
<rick_h_> hatch: oh hmm, didn't see it in the browser when I did it
<rick_h_> and was checknig for login :)
<hatch> but you are right there is no login
<hatch> see check_user_credentials
<hatch> method
<hatch> so we might need manual fn calls in there
<hatch> darn!
<rick_h_> hatch: checking, so logout I do have a url. And logout shows the login at the same time without another request
<rick_h_> so that just works as is, check for that in the url as well
<rick_h_> can you get to just login? there's no url for it
<gary_poster> benji, would 40 minutes from now work for you?
<hatch> if there are no credentials then it shows the login page
<hatch> it should redirect to /login
<hatch> I've been meaning to bring that up
 * hatch creates card
<hatch> rick_h_: in the meantime you'll need to call the callback manually in the check_user_credentials method
<rick_h_> hatch: does it auto log you in though? I'm logging myself out and then I see a login screen. When I reload, I get the main site
<rick_h_> hatch: k, looking for that method
<hatch> yeah that's in the config.js
<hatch> config-debug.js
<hatch> has user: and password: properties
<hatch> set those to undefined to land on a login page
<rick_h_> hmm, but if I check user credentials it shows the login. I don't want to check it again
<rick_h_> ah, but it cancels any other routes so I should be good
<rick_h_> it'll show the login and kill dispatch so never hit my stuff
<hatch> you want to put your callback call on line 682, right after this.show_login();
<hatch> that way if there are no credentials and it's showing the login then hide ths browser
<hatch> at least it makes sense in my head
<hatch> which has been wrong from time to time ;)
<rick_h_> it seems dirty and another edge case for me to cover. Shouldn't subapps get killed on the login?
<rick_h_> it seems crazy to need to call another method to force hidden in another corner case. 
<hatch> well your routes shouldn't be called if there are no credentials
<hatch> so....
<hatch> yeah
<hatch> ignore me
<rick_h_> right, that's what I was thinking
<rick_h_> cool, I'm happier now
<hatch> and I feel dumber
<hatch> THANKS!!!
<hatch> haha
<rick_h_> :P
<benji> gary_poster: my internet connection is back from its brief hiatus
<gary_poster> hey benji cool.  I asked earlier when I didn't realize that you were gone of we could postpone a half hour from the usual time.  that work?
<gary_poster> *if
<benji> gary_poster: yep, that's fine
<gary_poster> ok thanks benji
<rick_h_> hatch: https://codereview.appspot.com/8937046
<gary_poster> bac I lost you
<hatch> rick_h_: cool, does it work? ;)
<rick_h_> hatch: :)
<rick_h_> hatch: seems to work fine. Do wish multi-dispatch would run away as it hits it 10 times but works
<hatch> lol.....working on it
<rick_h_> hatch: if you get a sec for review appreciate it. 
<hatch> yup doing it right now
<rick_h_> hatch: ty
<rick_h_> gary_poster: did you email luca over the landscape stuff from https://bugs.launchpad.net/juju-gui/+bug/1171531 ?
<_mup_> Bug #1171531: Zoom control <charmbrowser> <juju-gui:New> <https://launchpad.net/bugs/1171531>
<gary_poster> rick_h_, I talked to jovan about it.  He said to put the zoom control in the center.  sorry for not updating bug.  would you mind? :-P
<rick_h_> not at all, will add note about moving zoom control to the center then. Thanks
<hatch> rick_h_: review done
<rick_h_> hatch: thanks, looking. 
<Makyo> jujugui: can I get one more review on https://codereview.appspot.com/8961044/ to help clear a card?
 * hatch will do it
<Makyo> \o/
<hatch> Makyo: done like dinnah
<gary_poster> ok benji, sorry, joining
<bac> hi hatch can i chat with you for a bit?
 * benji looks up the URL
<hatch> bac: sure, couple mins, just need to get the dogs in
<bac> ok
<hatch> ok guichat
<hatch> ^ bac
<hatch> gary_poster: bac: here was the tiny RTE I was talking about http://mindmup.github.io/bootstrap-wysiwyg/
<hatch> I/we could likely convert that to YUI pretty easily
<hatch> gary_poster: bac: There is also https://github.com/smugmug/yui-gallery/tree/master/src/sm-editor which is based on Y.Editor
<hatch> demo if it http://jsbin.com/abaqiq/2
<rick_h_> hatch: some replies sent your way. Will work on adding a functional test. Was having a hard time finding a good home for it/how to get at it but working on it
<hatch> thanks - yeah functional tests are hard but I wanted to avoid the case where we release the app and noone noticed that breaking :)
<rick_h_> hatch: no, you're right. I did look around but test_app seemed bare and tried to sneak by :P
<hatch> haha - nobody lets me sneak by so I'm just passing on the love rofl
<rick_h_> hatch: ok, actually found an easy way to test yay. So code going through lbox now :)
<hatch> awesome
<hatch> !
<rick_h_> hatch: if you can get a second to look over before EOD so I can get it through that'd be great please
<hatch> yep as soon as it updates I'll do it
<rick_h_> doh, linter fail
<rick_h_> thanks, clears the way for me to work on making it the default after this :)
<hatch> haha - I have started to lint and make all tests pass before final commit so I don't get the last commit being "f'n linter" ;)
<hatch> rick_h_: you're gona be irritated but you forgot to destroy app in your new test :)
<rick_h_> hatch: lol, well crap. I was trying to use makeApp at first which auto destroyed
<rick_h_> but it's nto in this closure so swapped out but missed that my bad
<rick_h_> oh wtf, the tests before it app.destroy first?
<hatch> afterEach has an app.destroy()
<rick_h_> oh hatch there's an ap.destroy in afterEach
<hatch> but you created it with var
<hatch> :)
<rick_h_> ok, I can remove that :P
<hatch> haha - it's been LGTM'd
<hatch> charmstore is sure gona look good once it has some icons with some color
<hatch> like in the mockups
<rick_h_> hatch: yea, they got some 10 icons in today but not through injest yet
<rick_h_> hopefully tomorrow they'll start to show up
<rick_h_> thanks for helping me out with this one today hatch 
<hatch> anytime
<hatch> thanks for the implementation :)
<rick_h_> ah crap, test-prod failure now? wtf
<hatch> can anyone tell me why charm provides and requires would be undefined in a charm = db.charms.add()
<hatch> ahh nm got it....newly introduced byg
<hatch> bug
<hatch> arg so close to finishing this
<gary_poster> hey hatch.  we explicitly don't want a RTE AFAIK, but I imagine bac already said that to you.  
<gary_poster> Is Rick's recent branch supposed to fix the CI failure?
#juju-gui 2013-04-26
<rick_h_> gary_poster: no, not that I'm aware of. Looknig at the CI thing now. Looked it over since it was failing most of the day. 
<gary_poster> understood rick_h_.  Yeah, we got a single success after the other problem before we dipped back down into the red. :-) and :-/
<gary_poster> rick_h_, passes locally on IE 10 but same failure on CI :-(
<rick_h_> gary_poster: hmm, the video shows it passing
<rick_h_> gary_poster: I've not poked at the CI really, but went to the saucelabs results and trying to figure out 'what' failed. some timeout, but the video shows all tests run/passed
<gary_poster> rick_h_, I wonder if it is simply a timeout thing, now that we have so many tests.  Leme see if I can remember how to increase that
<rick_h_> gary_poster: k
<gary_poster> rick_h_, that is the timeout error.  I'll double the tmeout, from 90 sec to 180 sec, and we'll see how it goes.
<rick_h_> gary_poster: ok cool. Yea noticing that I used to be able to run the tsets in some 30s of seconds and these days it's a chunk more than that
<rick_h_> gary_poster: thanks for poking at that. 
<gary_poster> :-) sure
<rick_h_> http://uistage.jujucharms.com:8080/bws/sidebar/ click on the service view of a charm :)
<gary_poster> looking nice! You mean, just click on a charm?
<rick_h_> no, the environment, "view" so that the browser hides away
<gary_poster> oh!
<gary_poster> nice rick_h_ ! :-) looks good
<rick_h_> ok, running away until tomorrow. Thanks again. CI is good. Let's do more of that. :)
<gary_poster> :-) I agree rick_h_ .  ttyl, & have a good night
<hatch> gary_poster: yeah he did mention not wanting an RTE however using just the core functionality of one will give you all of the user input stuff that you need. Then you only have to deal with parsing out the html
<hatch> I switched to feedly tonight - really nice looking and pretty good UI, I wish it had a search feature though for searching through my feeds
<bac> gary_poster: yesterday how did you eventually get firebug to show you the console?
<gary_poster> yes bac
<gary_poster> oh
<gary_poster> bac I reset the options and then I turned on the console tab
<gary_poster> then it worked in the source tab
<bac> gary_poster: nm.  it is behaving very oddly.  the first time i had one newly styled UI.  i've since reloaded the page and now have the old firebug UI.
<gary_poster> cool
<rick_h_> jcsackett: if you get a sec can you second the huw reviews. Pretty small ones but three of them. https://codereview.appspot.com/8972043/ (8653049|8973043)
<rick_h_> gary_poster: https://bugs.launchpad.net/juju-gui/+bug/1110832 can be closed as fix released right?
<_mup_> Bug #1110832: Charm browser story needs in-browser environment <charmbrowser> <juju-gui:Triaged> <https://launchpad.net/bugs/1110832>
<gary_poster> yes rick_h_ thanks
<gary_poster> I need to go through bugs
<gary_poster> not my favorite activity
<rick_h_> gary_poster: I'm with you. Just trying to keep up with the UX folks myself
<gary_poster> +1 thanks
<rick_h_> gary_poster: I'm looking at this change to get rid of 'dummy' on the header. I don't see that as something in the GUI. Is that coming from juju itself?
<gary_poster> yes rick_h_ .  The "dummy" comes from improv.  Other environments report other data--for instance, "Environment on ec2"
<rick_h_> gary_poster: ah, the same improv in the gui tree?
<rick_h_> gary_poster: e.g. if I can get it changed there it might just work?
<rick_h_> ok, yea seeing it in the rapi-rollup thing. 
<gary_poster> rick_h_, the in-memory juju reports "demonstration," improv (from rapi-rollup) reports "dummy"
<rick_h_> gary_poster: oh, so that'll be changing soon then when it goes to the in memory one?
<gary_poster> rick_h_, but I thnk they just want the whole cloud-icon-plus-environment-on-X thing gone
<gary_poster> remind me of that bug number
<gary_poster> ?
<rick_h_> gary_poster: #1172734
<_mup_> Bug #1172734: Environment on Dummy <blocker> <charmbrowser> <juju-gui:Triaged> <https://launchpad.net/bugs/1172734>
<rick_h_> gary_poster: yea, this is just a blocker for UX so it's the 'smallest change' without doing the whole header
<rick_h_> I had hoped it'd be a drive by in a small branch of tiny fixes :)
<rick_h_> s/dummy/demo or something but stepped on something bigger
<gary_poster> I see rick_h_ .  If they just want "dummy" to go then yeah, that is probably already done.  Start the GUI locally with staging: true in your config.  I'll do as well. You should see "Environment on demonstration"
<rick_h_> gary_poster: cool, thanks. 
<gary_poster> rick_h_, " Environment on demonstration"
<gary_poster> that nay not be ideal still
<gary_poster> may
<rick_h_> gary_poster: cool, works for me. marking the bug as fix committed, but not released since staging shows the old atm. 
<gary_poster> rick_h_, ok, though....1 sec...
<rick_h_> gary_poster: well, in our call they took offense to the word 'dummy' on the site
<gary_poster> rick_h_, fix released: https://91.189.92.38/
<gary_poster> rick_h_, that's the prodstack site
<rick_h_> ah ok very cool then
<gary_poster> bac, did hatch steer you towards another RTE?  not convinced by that from the outside
<bac> gary_poster: we're going to explore using the YUI EditorBase
<bac> gary_poster: he thinks it is lightweight enough that having lots of them on a page won't be a problem
<gary_poster> bac, that does not produce raw text but html, so you are going down the road of what you and I had prototyped: nasty heuristics to convert html to text.  I hope I'm wrong, but I don't think I am. :-)
<bac> gary_poster: understood
<rick_h_> lol, well removing the /bws/ and making the browser always show only broke 167 tests. lol
<gary_poster> heh
<gary_poster> hopefully that's easier than it sounds
<rick_h_> yea, I'm guessing a giant cascade
<rick_h_> but was fun to go "let'r rip!"
<gary_poster> :-)
<rick_h_> luca____: hangout?
<luca____> rick_h_: I'm in a meeting for the next hour or so
<rick_h_> luca____: ok cool
<gary_poster> bac another question is whether http://www.jacklmoore.com/autosize/ can look like a single line when you start. :-/
<luca____> rick_h_: our visual designer is working to tight deadlines today to get everything out to you guys asap :)
<rick_h_> luca____: cool, have a couple of questions for you guys when you get a sec
<luca____> rick_h_: ok, I'll let you know when were out
<gary_poster> rogpeppe1, is it possible to remove a subordinate relation in juju core?  was not possible in pyjuju, and IIRC the reason was that proper behavior was unclear and/or difficult to implement.
<rogpeppe1> gary_poster: i haven't tried. perhaps :-)
<gary_poster> rogpeppe1, :-) k
 * gary_poster switches off to try raring on the desktop.  back soon, hopefully...
<hatch> I have a very odd test failure that I'd like some help on.....test_app.js 'should be able to route objects to internal URLs'
<hatch> in that test it tries to get a url of a charm....but I can't see where the charm data is populated
<rick_h_> down to 1 failing test woot
<hatch> right on
<hatch> my failing tests are so confusing
<hatch> add that to the console not working
<hatch> can anyone tell me how to turn the console logs on during the tests?
<hatch> I get the loader logs but nothing inside of a test or the application
<hatch> well that's not entirely true....console logs in 'before' work
<hatch> ahah found it...wow that has to be the most irritating thing
<Makyo> hatch, Set a breakpoint and check the value of console?
<Makyo> Oh, excellent.
<hatch> that's not very efficient when you're in a fn that's called a number of times
<hatch> know what I mean?
<Makyo> I just meant in one test to investigate is all.
<rick_h_> hatch: I've been known to "window.one = true"... if(window.one) { debugger } on some occassions
<rick_h_> just to add hacks to hacks :)
<hatch> do two hacks make a right?
<rick_h_> make for not clicking 'play' 50 times to get to the one iteration you care about :)
<hatch> ^that
<rick_h_> say...to drop a debugger in the afterEach when there are 50 tests in the suite. You could comment them all out, but hook a var in your test to window and all set
<hatch> oh fyi if you set 'consoleEnabled' to true in the config of an app instance then it will log properly
 * hatch contemplates deleting the console clobbering code ;)
<Makyo> Alright.  I mean, if console.log isn't working in any test because it's being turned off, iterations shouldn't matter :)
<Makyo> Glad you found it, though.
<hatch> now I'm so confused as to why these tests are failing...
<hatch> ohh now I see why they are failing
<hatch> because the test is wrong now
<bac> hatch: ping me when you've got some time
<hatch> well I'm at a good stopping point, wana chat?
<luca____> rick_h_: are you free?
<rick_h_> luca____: sure thing
<luca____> rick_h_: https://plus.google.com/hangouts/_/59f6e27697d7873463bc542eb1fd68f2d79b98c4?authuser=1&hl=en
<rick_h_> luca____: https://plus.google.com/hangouts/_/8afa3721f4844e71152262d259b9f7ed6c5b76d7?authuser=0&hl=en
<rick_h_> lol
<rick_h_> luca____: omw
<hatch> hey gary_poster hows raring?
<gary_poster> hatch, mostly good.  graphics driver is working on desktop now.  need to get webcam working...
<bac> hatch: sure
<hatch> to guichat
<hatch> or not
<hatch> https://plus.google.com/hangouts/_/cd713a9d85f41b965a8d3f0ab9189dc8a2fce870?authuser=0&hl=en
<hatch> ^bac
<bac> hatch: i saw you there briefly.  now it is just gary and he's non-repsonsive
 * bac joins other
<gary_poster> jujugui please update kanban.  hopefully I can join in 8 :-P
<Makyo> jujugui call in 1
<gary_poster> sigh thanks.  maybe from other machine...
<luca____> rick_h_: query: we sent you the assets yesterday and saw that they weren't implemented, are they ok?
<rick_h_> luca____: yea, they're in review. Should land in next hr
<luca____> rick_h_: fantastic! just checking in case we needed to re-supply
<luca____> rick_h_: tagging all "nice to have" improvement as: Charmbrowser Enhancement in launchpad. Is that ok?
<rick_h_> luca____: rgr
<luca____> rick_h_: hey
<rick_h_> luca____: yep, otp but what's up?
<luca____> rick_h_: nm! Just realised what was going on :)
<luca____> rick_h_: are you free for a very quick call?
<rick_h_> luca____: give me 10?
<luca____> rick_h_: sure, let me know when
<rick_h_> luca____: k
<rick_h_> luca____: I'm avail
<luca____> rick_h_: sweet
<luca____> rick_h_: https://plus.google.com/hangouts/_/cca38ee039e87fba24828491149b9f7f76e17f54?authuser=1&hl=en
<rick_h_> luca____: so the video, assets, and search results styling from huw are on uistage
<rick_h_> http://uistage.jujucharms.com:8080/bws/fullscreen/search/?text=hadoop
<rick_h_>  and http://uistage.jujucharms.com:8080/bws/fullscreen for instance
<rick_h_> Makyo: hatch bcsaller can a pair of you guys look over this sometime? https://codereview.appspot.com/8977043 to bring the browser into the default view. QA it, break it as hard as you can :)
<rick_h_> this almost seems too easy of a branch after all the fight to get this far. 
<bcsaller> rick_h_: I'll look at it soon
<rick_h_> bcsaller: thanks
<rick_h_> I'm going to duck and look for food.
<rick_h_> note that removing the old stuff is a second follow up branch
<bcsaller> rick_h_: ahh, ok, I was commenting on that
<rick_h_> bcsaller: yea, didn't want to cross the streams and I like all-delete branches
 * gary_poster restarting...
<hatch> bcsaller: can you tell me where the charm data is being populated in this test http://bazaar.launchpad.net/~juju-gui/juju-gui/trunk/view/head:/test/test_app.js#L125
<hatch> it's failing in my branch and for all purposes I can't find why it would ever pass...
<bcsaller> hatch: in beforeEach it calls injectData which simulates a delta with charm info in it (at a glance)
<hatch> there is charm info there? I only see services with charm attributes
<bcsaller> hatch: I think it then pulls that out of band
<bcsaller> its like when the server tells you on the inital connect whats in the environment
<hatch> sure but nothing is saying 'hey create a charm instance'
<hatch> unless it was happening as an obscure side effect
<hatch> which I suppose is possible
<hatch> I did remove a ton of the endpoint.js code
<hatch> so it may have been passing by accident heh
<hatch> nice looking chrome devtools theme http://devthemez.com/themes/zero-dark-matrix
<hatch> bcsaller: ahh it was happening by a side effect in code I removed in endpoints.js
<hatch> which only matters in the tests and not in the real application
<rick_h_> bcsaller: thanks for the review. I'll s/nop/noop :)
<bcsaller> rick_h_: thanks
<gary_poster> Hey, anyone  available to try guichat to see if everything is working for me now?
<rick_h_> gary_poster: sure
<gary_poster> rick_h_, already handled thank you
<gary_poster> :-)
<rick_h_> oh heh, nvm
<gary_poster> much appreciated though
<bcsaller> hatch: have you reworked endpoints::handleServiceEvent recently (or currently). I'm seeing an error there where db.charms.add fails because the id already exists. I think there is a real race wrt the env.get_service call above and it shows up with the sandbox.
<bcsaller> Uncaught TypeError: Cannot call method 'load' of undefined 
<hatch> bcsaller: it's been entirely reworked in the current branch
<hatch> no race condition possible anymore
<hatch> :)
<hatch> I'd like to show you the diff but I don't think bzr can diff from 'parent'
<bcsaller> ok, its killing my testing now, but I won't do my own fix
<bcsaller> hatch: bzr diff -r ancestor:../trunk or similar
<hatch> well my trunk branch is updated
<hatch> so I need to diff from whatever revision it was branched at....
<hatch> whatever that is
<gary_poster> hm.  we don't seem to build in raring...
<hatch> no?
<bcsaller> gary_poster: I'm on raring and its working for me
<gary_poster> bcsaller, yeah?  hung here after a make clean-all && make:
<gary_poster> npm WARN engine cryptiles@0.1.3: wanted: {"node":"0.8.x"} (current: {"node":"v0.10.5","npm":"1.2.18"})
<bcsaller> hmm, maybe I didn't do it from clean
<gary_poster> mm, I may need to redo the installation instructions
<gary_poster> I mean, do them on raring
<hatch> gary_poster: no other error messages?
<bcsaller> I saw some warnings in the npm output, but it works fine and will put up the devel server
<hatch> that's just a warning, I get those all the time
<gary_poster> bcsaller, nothing else, but then I did a clean-all again and it pointed out I didn't have ImageMagick.  Trying that and all other bits and bobs
<gary_poster> made it past that part...
<gary_poster> rick_h_, manage.jujucharms.com does not work ATM with gui, right?
<rick_h_> gary_poster: right, not all of it does
<rick_h_> staging does work ok now though
<rick_h_> http://staging.jujucharms.com/
<hatch> bcsaller: clearly the lbox knows how to properly diff so I'll have to look into that to figure out how it does it
<gary_poster> rick_h_, cool.  looking at your branch.  I suggest switching app/config-prod.json to staging for now
<rick_h_> gary_poster: ok
<gary_poster> rick_h_, also, before this lands, we will need to either set up working defaults for those values in the app, or update the charm to provide them.  Otherwise trunk will fall over in charm.  Also important for prodstack
<gary_poster> rick_h_, one more piece of feedback: would be great if we could have loading circle (same, but possibly scaled down, to the one we have when loading the GUI) in the charm browser when it is just loading
<gary_poster> Since UX guys are gone I'd suggest adding and then verifying with them
<rick_h_> gary_poster: yes, we've got the indicator widget that needs to be applied liberally along with some caching to prevent reloading the interesting/etc
<rick_h_> gary_poster: it's part of that that work 
<gary_poster> cool
<gary_poster> rick_h_, I search for juju-gui (in prod but with the staging site set in config) and got an error initially
<gary_poster> Failed to load charm details
<gary_poster> Charm API error if type: no_such_charm
<rick_h_> gary_poster: yes, I'm looking at that right now actually. 
<gary_poster> ok cool
<rick_h_> gary_poster: there's a corner/multi route case I'm seeing in qa'ing some more where /fullscreen also matches the new /*id
<rick_h_> so it hits twice and does the right thing but also tries to load a charm called /fullscreen
<gary_poster> ah :-/ yeah.  another argument for that to be in its namespace.  Kinda serious.
<gary_poster> Other solutions available too of course
<rick_h_> yea, I've already defined the list of possible 'viewmodes' and they can't match the start of an id, which is a release name so working on stripping it out before figuring out state
<gary_poster> rick_h_, k
<rick_h_> gary_poster: where are 'set a default'?
<rick_h_> for the config? 
 * rick_h_ didn't realize there was something outside of config-
<hatch> rick_h: I have noticed an issue in our tests - we need a way to turn off subapps
<gary_poster> rick_h_, that would just be in your own initialization.  putting it in charm would be better.  can do that
<rick_h_> hatch: heh, that's what I had to noop to work around
<rick_h_> gary_poster: ah ok
<hatch> oh lol
<rick_h_> so tests pass with it, but required a little hack
<rick_h_> but it's why I blew up 160+ tests at first pass
<gary_poster> rick_h_, when will the juju definition of an official charm (which is supposed to make ~juju-gui the official charm) match the charm browser's (which shows the ~charmers branch as the official charm)?  This will become pretty important because, for instance, the ~charmers charm will not work with this branch (and there may be other incompatibilities)
<rick_h_> gary_poster: I don't know. I know abentley and sinzui worked on a temp state, but don't know when the final resolution will come.
<gary_poster> rick_h_, ack thanks.  abentley, do you know?  This could become a blocker
<gary_poster> rick_h_, are we going to mark official charms with a badge or other indication before release?
<abentley> gary_poster: No, I don't know.  Why might it be a blocker?
<rick_h_> gary_poster: we're trying to. It's on the UX work to try to fit in next week.
<gary_poster> abentley, because from a user perspective, it will encourage people to use old charms.  In the concrete case of the GUI, it will encourage people to use old charms that will be broken
<gary_poster> rick_h_, ack cool
<abentley> gary_poster: AIUI, promulgated charms not owned by charmers are very uncommon.
<gary_poster> rick_h_, when browser is minimized I see it a bit hanging off to the left.  Is that to spec?
<rick_h_> gary_poster: yes
<rick_h_> gary_poster: they want a hint that 'there's something there'
<abentley> gary_poster: And can't we work around it by getting a ~charmers branch in place?
<gary_poster> rick_h_, cool.  might be nice if it were clickable with same effect as clicking button.  rick_h_, that's my qa feedback for the branch.  have not looked at code.  from qa perspective, I'm ok with this landing when (1) that bug you are looking at is fixed (it happens a lot), and (2) the charm can deploy this branch.  Yellow can help with #2.  
<rick_h_> gary_poster: ok, adding a test for #1 right now and will have that pushed up shortly and will look around for a second code review
<rick_h_> gary_poster: thanks for qa'ing
<gary_poster> Once those are addressed, I'd like to see a follow on branch fix the right hand charm panel.  could be from yellow.  The spinner also seems like a high priority
<bac> hi hatch
<rick_h_> gary_poster: if yellow could help with removing the old charm panel that would help free me up to work on things like the spinner/caching. 
<gary_poster> abentley, promulgated charms not owned by charmers uncommon: probably. OTOH, they are the ones that are being maintained most diligently in the view of ~charmers (so diligently that the ~charmers are willing to step aside) so they are presumably fairly important to some people
<rick_h_> gary_poster: I've got providers and search filters in front of it atm
<hatch> bac: hey, I'm just finishing my lunch
<hatch> few mins
<gary_poster> abentley, get ~charmers to replace it: fine, but then identifying those charms and coordinating with people needs to be part of the project plan
<abentley> gary_poster: No one disagrees about whether this should be fixed, but I don't think it's appropriate to start calling it a blocker today, with less than a week to go.
<rick_h_> gary_poster: fix for the extra loading of an invalid charm pushed up.
<rick_h_> gary_poster: going to add a card then to the yellow board for removing the sidebar browser
<gary_poster> thx on call
<hatch> bac: ok ready?
<bac> hatch: sure
<hatch> guichat is open
<rick_h_> Makyo: any chance I can bribe a review on https://codereview.appspot.com/8977043 from you? Updates per gary's notes included
<Makyo> rick_h_, Sure, it's lunch, good time to switch gears.
<rick_h_> bcsaller: ^^ had to add a couple of calls to fix the qa issue if you want to second look it. 
<rick_h_> Makyo: ty kind sir :)
<Makyo> rick_h_, looking good from QA, assuming the 'charm API error of type: no_such_charm' is something else :)
<Makyo> rick_h_, read up, I see (been buried in go, sorry!)
<Makyo> Just was getting a lot of resource not found on URLs like http://staging.jujucharms.com/api/0/charm//search/precise/puppet-3
<rick_h_> Makyo: what's the url right now?
<rick_h_> Makyo: maybe I missed a case. looking. search...hmm. 
<Makyo> http://localhost:8888/sidebar/search/precise/puppet-3/?text=puppet
<rick_h_> Makyo: sec, let me try one thing. 
<rick_h_> Makyo: yea, give me a few. I missed search when I got sidebar/fullscreen/etc
<Makyo> rick_h_, no worries, will keep poking around.
<rick_h_> Makyo: cool, got it. Just need to add another test case for it.
<rick_h_> Makyo: pushed up the code fix if you want to pull/dbl check. I'll get the test case added here
<gary_poster> sandbox is very broken
<gary_poster> jujugui ^^^ big problem
<benji> :(
<Makyo> ?
<bcsaller> whats the issue?
<gary_poster> example: (1) search for mysql. (2) add mysql.  (3) search for wordpress.  mysql disappears
<gary_poster> another example:
<gary_poster> (1) search for mysql (2) add mysql (3) open charm panel. still stuck on mysql page
<gary_poster> no way to escape except searching
<bcsaller> gary_poster: if a link is triggered outside of the viewContainer it won't delegate to navigate, if it reloads the url it will clear the sandbox, that is my guess
<Makyo> gary_poster, are you breaking on errors? I'm getting a problem in load.
<gary_poster> Makyo, no, will look.
<bcsaller> there is the race in the charm load I was talking to hatch about before as well
<bcsaller> but he said his branch reworks that 
<gary_poster> we need to do some serious qa of that stuff then
<gary_poster> Makyo console shows no errors for me when I load env
<gary_poster> ah!
<gary_poster> I see
<Makyo> When you deploy, endpoints.js:147
<gary_poster> endpoints.js is broken
<gary_poster> yup
<Makyo> I don't get that from the new stuff, which is good :o)
<Makyo> From rick_h_ 's branch, I mean
<gary_poster> Makyo, you mean hatch's new branch?  Is that up for review?
<gary_poster> oh
<hatch> looking
<hatch> is this something that my last branch broke?
<gary_poster> may be
<hatch> shall bac and I stop this so I can investigate?
<gary_poster> yes, please, hatch.
<gary_poster> benji, how is your branch going?
<rick_h_> Makyo: code review and branch updated with fix + test cases for search
<bac> BigRedButton.depress()
<gary_poster> exactly
<Makyo> rick_h_, cool, thanks
<rick_h_> lol
<benji> gary_poster: I'm having trouble verifying that it is helping real charm deployment speed.
<hatch> ok pulling trunk and building
<hatch> and this is only using sandbox?
<hatch> it works fine in rapi?
<gary_poster> hatch sandbox is where we saw it
<hatch> Uncaught TypeError: Cannot call method 'load' of undefined
<gary_poster> yes
<gary_poster> on second call
<gary_poster> first one works
<hatch> ok it's trying to add the same charm again
<gary_poster> that's what bcsaller was talking about before
<gary_poster> I think
<gary_poster> that you said your charm fixed
<hatch> checking on rapi
<gary_poster> but still not clear why it would fail second time through
<hatch> it's because you can't add two of the same id's
<gary_poster> no
<gary_poster> line before is
<gary_poster> charm = db.charms.getById(charm_id)
<bcsaller> then the env call which I think pulls the charm as a side-effect, no?
<bcsaller> and then the add fails
<bcsaller> and maybe we see that because the sandbox is very fast
<hatch> I'll try this on my local promise branch on sandbox
<gary_poster> bcsaller, forwarded you an email about the fact that we are supposed to use an image on your branch
<gary_poster> I don;t think you have the image
<hatch> jujugui - this works as expected on my branch
<hatch> oops, autocomplete fail
<gary_poster> and I can't get to the image on linux, oddly enough
<hatch> bcsaller: I think that this is indeed a race condition
<gary_poster> trying on os x
<hatch> because it's impossible to do a race condition in my branch and it doesn't break
<bcsaller> gary_poster: I don't think I do, but I render the help from a template, easy to modify 
<gary_poster> cool
<hatch> gary_poster: so bench the textarea stuff and get my branch landed? :)
<gary_poster> hatch, assuming it fixes everything else, yes
<gary_poster> hatch, otherwise, bench them both and fix trunk
<hatch> what was issue #2?
<hatch> here is my branch - feel free to check it out and try https://code.launchpad.net/~hatch/juju-gui/load-srv-db
<gary_poster> hatch, documented above
<gary_poster> <gary_poster> example: (1) search for mysql. (2) add mysql.  (3) search for wordpress.  mysql disappears
<gary_poster> <gary_poster> another example:
<gary_poster> <gary_poster> (1) search for mysql (2) add mysql (3) open charm panel. still stuck on mysql page
<gary_poster> <gary_poster> no way to escape except searching
<hatch> ok trying
<gary_poster> bcsaller, just sent you images. 
<bcsaller> gary_poster: thanks
<hatch> neither of those bugs show on my branch in sandbox
<hatch> trying rapi
<hatch> yeah fixed in my branch
<gary_poster> ok hatch how far are you from landing?  would pairing help?
<hatch> I'd feel comfortable landing after getting the 3 failing tests fixed then I can do a followup to add additional tests
<hatch> probably an hour?
<hatch> pairing probably wouldn't help as it's just fixing these tests to add the charm data first before trying to get it
<hatch> 'just' heh
 * hatch goes dark to fix tests
<rick_h_> Makyo: I'm headnig off for a bit. Will be back tonight if you find anything else. Thanks again!
<gary_poster> ok rick_h_ we need to add the change to the charm for your branch.  benji this should not conflict with you because we are adding 
<Makyo> rick_h_, QA is LGTM, will have the code done before you get back.
<gary_poster> something to the template, and a new option
<rick_h_> gary_poster: "add the change to the charm"?
<rick_h_> gary_poster: oh right, the juju gui charm
<rick_h_> sorry, charm is kind of loaded these days
<gary_poster> rick_h_, as I said, your branch will break the charm unless we add the option
<gary_poster> yeah understood
<gary_poster> benji, I'm sorry I'm having family issues I need to address immediately as well.  I need to ask you to stop work on your branch.
<rick_h_> gary_poster: added a card to the board for that
<gary_poster> thanks rick_h_ 
<gary_poster> benji, new task is small but important
<hatch> I think that the promises are causing the tests to fail
<gary_poster> benji, card is "Add default value for charmworldURL to the charm"
<gary_poster> ugh this sucks
<hatch> because I think the promises are throwing which is causing the test to complete
<hatch> basically the promises are never resolving or erroring which is.....impossible?
<gary_poster> benji, task is to add charmworldURL to template
<gary_poster> for config.js
<gary_poster> make it configurable
<gary_poster> in charm
<gary_poster> default should be the default in config-debug.js in juju-gui
<gary_poster> charmworldURL: 'http://staging.jujucharms.com/'
<gary_poster> because manage is not working, even though it should be the default :-(
<hatch> ok maybe pairing won't be such a bad idea...
<hatch> maybe someone else can lend a hand as to a way around this promise issue
<hatch> https://npmjs.org/package/mocha-as-promised
<hatch> http://stackoverflow.com/questions/15058847/unit-testing-promise-a-rsvp-js-promises
<bcsaller> hatch: can't you just call done() in callback and done(err) in the error back?
<bcsaller> hatch: when I worked with it that was working well enough
<hatch> I don't think that applies here....guichat?
<bcsaller> hatch: sure
<gary_poster> hatch, bcsaller, I'd like to pair with hatch to let bcsaller finish his task.  That also needs to be done ASAP.  Let me know when it makes sense to switch.
<bcsaller> gary_poster: I'm a little blocked on testing because of this as well, its currently failing in this same spot
<gary_poster> I see :-(
<bcsaller> other than that it basically works
<gary_poster> bcsaller, revert hatch's previous branch locally?
<bcsaller> gary_poster: you can join the chat if you want
<gary_poster> I have updated cards to clarify priority
<gary_poster> benji, you EoD yeah?
<benji> I'm just about done with the branch, verifying that it actually works by deploying the charm.  Trying to figure out where it hides the generated config file now.
<gary_poster> benji awesome, thank you. I suggest trying it out with rick_h_ 's branch, since that's the one that I'm worried about.  
<gary_poster> Finding
<benji> gary_poster: if you want to pair real quick to hand-off, that would be fine
<gary_poster> ok benji guichat
 * Makyo dgwalks quick
<rick_h_> gary_poster: benji let me know if there's anything I can do to help. 
<gary_poster> ack thanks rick_h_ 
<hatch> gary_poster: I can't think of any workaround beyond a timeout for that first test....at least without added an 'else' which fires an event
<hatch> not sure which is worse :)
<gary_poster> hatch that's what I thought too
<hatch> I am leaning towards prefering a timeout
<gary_poster> +1 sadly
<hatch> 0 failures
<gary_poster> great hatch.
<hatch> gary_poster: would you prefer I land this branch with passing tests and then a followup with additional tests? or hold off until the additional tests are done?
<gary_poster> hatch, what are the additional tests you have in mind
<hatch> I'd like to make unit tests to test the charm, service, db changes individuallt
<hatch> these tests test them indirectly
<hatch> so we can be assured it works with this
<hatch> but more tests would be easier to debug later
<gary_poster> hatch ok.  land as is then follow up. thanks.  also make a card for CI selenium tests of sandbox please
<hatch> will do!
<gary_poster> thank you
<hatch> jujugui - would love a couple reviews plz https://codereview.appspot.com/8839050/
<gary_poster> rick_h_, update: I have benji's charm branch starting up with your ~rharding/juju-gui/browser-default branch.  Hopefully will work.  If so, can get one review and land
<gary_poster> (I already reviewed it :-) )
<gary_poster> hatch on it
<hatch> gary_poster: if you have the time it would be great to get a QA as well
<gary_poster> ok hatch
<gary_poster> ooh, the db has to know the env? That's understandable but I don't like it. :-/
<hatch> yeah I don't much like it either - I'm open for alternatives :)
<hatch> to*
<gary_poster> pass env to getFullCharm and getFullService?
<hatch> I thought of that, but I wanted the db to be a source of information - so if I have to pass it in then it's no longer the source
<hatch> it requires external stuff to work
<rick_h_> gary_poster: cool on the charm. 
<gary_poster> it's not a source, but a repo I would argue
<gary_poster> the source is juju
<gary_poster> the environment
<gary_poster> that's why we have to pass a source to charm.load
<hatch> hmmmmm
<gary_poster> I agree that it is a "hmmm" argument :-) but not crazy either
<hatch> I accept your alternative view and substitute my own for it
<hatch> yeah feel free to comment that and I'll change it
<gary_poster> :-) k
<hatch> are there any instances in the app where we don't have env but still want service/charm I wonder
<gary_poster> hatch that would be a great counter argument :-)
<rick_h_> hatch: that's coming soon
<rick_h_> https://bugs.launchpad.net/juju-gui/+bug/1173274 the argument today came up of browser sans environment
<_mup_> Bug #1173274: "Connecting to environment" spinner should not block charm browser <charmbrowser> <juju-gui:Triaged> <https://launchpad.net/bugs/1173274>
<gary_poster> different, rick_h_ 
<rick_h_> gary_poster: ah nvm then
<gary_poster> thsi is code env, not visual env
<rick_h_> gary_poster: ah, looking now. Thought this was replacing the model/charm.load() stuff 
<gary_poster> rick_h_, it is...maybe I misunderstand your point?
<rick_h_> gary_poster: hmm, don't see in the MP the change on model/charm? just charmlist?
<gary_poster> crap start-error in charm
 * gary_poster was really hoping to relax :-(
<rick_h_> gary_poster: well, can wait until monday. I've got enough other bits that aren't directly tied to this to do
<gary_poster> rick_h_, not sure I agree :-/
<rick_h_> providers/caching/etc. 
<gary_poster> we need to have a decent set of code up for IS to review
<gary_poster> working
<rick_h_> gary_poster: true, but if we're shooting for thurs would hope tues would work for that?
<rick_h_> never felt so on the tail end of timezones before this project
<gary_poster> rick_h_, no.  this schedule makes me mad.  don't scratch the wound. :-)
<rick_h_> gary_poster: k, then no relaxing for you :) 
<gary_poster> :-)
<hatch> anything I can help with for this?
<rick_h_> hatch: guichat for a sec? I'd like to understand this
<hatch> sure
<rick_h_> I feel like there's a connection in the future 
<hatch> ohhhh so lonelllly
<gary_poster> rick_h_, what is your schedule.  you in guichat
<rick_h_> gary_poster: yea, in there now
#juju-gui 2013-04-27
<gary_poster> rick_h_, you around?
<rick_h_> gary_poster: yep
<gary_poster> hey
<gary_poster> got a problem
 * rick_h_ runs away
<gary_poster> staging.jujucharms.com is not available over https
<rick_h_> yea, manage. is supposed to be :(
<gary_poster> that means we can't make connections to...ah. :-(
<rick_h_> https://manage.jujucharms.com/ but it's in a broken deploy state atm
<gary_poster> rick_h_, ok...we are kinda hosed then :-(
<rick_h_> sec
<gary_poster> fwiw, https://ec2-54-224-193-110.compute-1.amazonaws.com/
<rick_h_> gary_poster: never mind. There was talk this morning of a manage.staging.jujucharms.com but it's not available from what I can tell
<gary_poster> ok
<gary_poster> so...
<gary_poster> so....
<gary_poster> um
<rick_h_> gary_poster: damn sorry. Didn't think about it. The upgrade is throwing errors and evidently in a way our charm isn't logging atm so we don't know why. 
<rick_h_> we'll supposedly update to start logging monday
<rick_h_> gary_poster: so I'll send an email to mthaddon I think. Or maybe there's an RT I can hook up with. To see if we can magically have a working https manage. instance by the time we start monday morning?
<gary_poster> rick_h_, that would be sweet if possible.  arosales' email said we would deliver Monday, not *when* on Monday.  I can actually land this change to the charm so it is ready for you, and maybe we just tweak the default to point to the working https data source monday.  the only thing that block is you landing the branch I was trying to get you open for. 
<rick_h_> gary_poster: yea, I can hold onto it for a minute. The trouble is landing it with a broken endpoitn means lots of error notifications about failed api calls
<gary_poster> right
<rick_h_> gary_poster: my other work I need to do isn't dependant on the browser by default work
<rick_h_> so it'll just be one more landing on monday hopefully
<gary_poster> I guess we could have a branch based on your branch to hide the right hand stuff
<rick_h_> gary_poster: yea, it sounds like that'd be by wed based on the last email that went around?
<rick_h_> so it could be done waiting in the wings for gonig in on wed at the latest
<gary_poster> no the intent is that monday EoD we have fully functional experience that could go live, other than bugs.  Think of it like beta, maybe?  wed is RC.
<gary_poster> thurs is chance for RC2 if necessary
<rick_h_> gary_poster: ok, sounds like a plan to me. /me liked when everyone was talking about thurs better :P
<gary_poster> fri is release
<rick_h_> gary_poster: +1
<rick_h_> writing email now to you, arosales, sinzui, mthaddon on manage. and we'll cross our fingers.
<gary_poster> cool rick_h_ .  Thursday: Yeah, but from hints and conversations I am pretty sure you agree with me that this jujucharms.com project would have been at lot nicer at this stage if it had been gradualy live the whole time.  I didn't want to be the PM, because I had enough on my plate.  But now that I'm involved, I want to do things the way we wanted them to have been done, even if it is within a very compressed timeli
<gary_poster> ne.
<rick_h_> gary_poster: understood. We can have a post-mort. sometime, but I don't know that having live bits the whole time would have helped either. It's just too much work that we've run out of time tbh. I've not been blocked or twiddling my fingers a single day for the last 2+ months. 
<rick_h_> gary_poster: thanks though. I'm on board for monday. It'll be a busy day, but should be good once we get through it
<gary_poster> cool rick_h_ .  No, you were certainly not twiddling your thumbs--you've done great work, and I mean it.
 * rick_h_ can't wait for vaca post-oakland :)
<gary_poster> I think a lot of coordination would have been better with what I described though.
<gary_poster> yeah :-/
<rick_h_> thanks, and can't say enough about the help you guys have done. wouldn't be close without it
<gary_poster> cool
<rick_h_> k, email away. let's hope it gets us a rebuild on monday
<gary_poster> :-) here's hoping
<rick_h_> boom! it works! bwuhahahahahaha
<gary_poster> what, rick_h_ ?
<rick_h_> heh, with a bunch of missing tests and 12 undocumented methods. 
<gary_poster> :-)
<rick_h_> gary_poster: filtering/searching
<gary_poster> yay!
<rick_h_> gary_poster: took up jcsackett branch and got it synced up into the app state and such so been working on getting it working all day
<rick_h_> pita to do since they're two diff widgets for filters, search input, spread across multiple views (sidebar, fullscreen, etc)
<rick_h_> but think I licked it finally
<gary_poster> awesome!
<gary_poster> rick_h_, I think I have the charm working with new necessary features, and charm tests passing--apparently they haven't been run for the last few commits :-( :-(
<rick_h_> sorry, just wanted to scream out loud :)
<gary_poster> heh
<gary_poster> I hear ya
<rick_h_> gary_poster: very cool, glad to hear. 
<rick_h_> passing that is :)
<gary_poster> I also found a sandbox inifinite loop that I see how to fix
<gary_poster> iloop in Y.mix: yuck
<rick_h_> ooh, very good. I tried that out today to see if it was faster
<rick_h_> <3 sandbox :)
<gary_poster> :-) cool, yeah
<rick_h_> makes all these reloads to check "given a pasted url do we parse/setup search state correctly"
<rick_h_> much better
<gary_poster> lol yeah I bet
<rick_h_> running out of time for today though so will try to get tests/docs and such going tomorrow some. Might have some known bugs on search/filter on monday to fix still
<rick_h_> there's still some confusion on handling a filter checkbox checked vs a default
<gary_poster> cool.  we should check when tom needs a new version of the gui in order to push it.  I think mews is in our timezone?
<gary_poster> so maybe we can have at least some of the day for debugging
<rick_h_> oh hmm, think he's west CO maybe? 
<gary_poster> that would be great :-)
<rick_h_> yea, that'd be cool. I figure most of the day will be reviewing/landing/etc
<gary_poster> yeah
<rick_h_> ah, he's in TX
<rick_h_> if we can get mthaddon to show him how it's done :)
<gary_poster> :-) I think mews has been doing the setup for the gui
<rick_h_> ah, ok cool then
<gary_poster> one charm review needed: https://codereview.appspot.com/8999043
<gary_poster> on board as well
<benji> gary_poster: I reviewed it.
#juju-gui 2013-04-28
<rick_h_> so staging.jujucharms.com blew up again. We seem to lose zookeeper on canonistack so bringing up a ec2 environment for dev atm. Will see if this works better and will share the url if it works out
<rick_h_> and striking out :/
<rick_h_> branch of doom!
<gary_poster> :-/
<rick_h_> ok, filters up...barely. 
 * rick_h_ ducks
<rick_h_> so now the question is...how many conflicts will these three diff branches force me to suffer through :/
<rick_h_> ok http://ec2-75-101-184-138.compute-1.amazonaws.com:6543/api/0/charms/interesting is up and running for now. sucks it takes 5 machines to run things
<bcsaller> gary_poster: I'll look over what you've done but I'm fine with anything that works. 
<bcsaller> gary_poster: that looks fine to me
<bcsaller> I was trying to facilitate supporting different help depending on env/staging/etc but that gets the job done for now
<rick_h_> huwshimi: morning. Some emails yours way. Let me know when you get your coffee/etc
<rick_h_> huwshimi: basically have 3 branches to get to feature complete atm. Two I'd love if you could look at today. 
<huwshimi> rick_h_: sure thing
<rick_h_> huwshimi: cool, no rush. Monday monday... :)
<rick_h_> huwshimi: do you know what spec is on the icons here? https://bugs.launchpad.net/juju-gui/+bug/1173255
<_mup_> Bug #1173255: Charm icon is the wrong size on the charm details page. <charmbrowser> <juju-gui:Incomplete> <https://launchpad.net/bugs/1173255>
<huwshimi> rick_h_: Checking...
<rick_h_> huwshimi: thanks, I just left it the default svg size of 96x96 but wonder if they're wanting us to increse it a bit over the orig size
<huwshimi> rick_h_: Yeah, the larges size they've been giving us is 96, but the size in that spot is larger
<huwshimi> rick_h_: The size there is 160x160
<rick_h_> huwshimi: wow, ok cool. I'll drive by that in one of my branches
<huwshimi> rick_h_: OK, what would you like me to take a look at today?
<rick_h_> huwshimi: want to hangout?
#juju-gui 2014-04-21
<rick_h_> morning party people
<rick_h_> well, non-holiday'ing people
<rick_h_> jujugui off to take wife to work (her car is kaput) back in a few minutes
<bac> ack
 * rick_h_ is back
<jcsackett> morning all.
<bac> hi jcsackett
<bac> welcome
<rick_h_> woo! and today the team is back to full strength for the first time since Feb. Well, aside from everyone being out this week
<bac> rick_h_: don't you have a fleet of fancy cars?  "kaput" seems to happen a lot.
<bac> or does michigan do that to them?
<rick_h_> bac: oh really? the wife's subaru is leaking something. So we're just not driving it until we take it in tomorrow
<jcsackett> rick_h_: i have a subaru. leaking something is its perpetual state.
<rick_h_> they don't really go kaput, but we do take them in for regular maintanece, new tires, winter/summer tire swap
<bac> ah, gotcha.
<rick_h_> so I guess it might seem that way, but actually we're pretty trouble free
<rick_h_> oh her battery died this winter, but that's just fun
<bac> our new-to-us car was kaputting but a new battery this weekend should do the trick
<bac> most expensive cost-to-volume car battery i've ever bought
<jcsackett> rick_h_: you free to chat this AM? about the card i pinged about friday or other things?
<rick_h_> jcsackett: yep, in a few min
<jcsackett> cool.
<bac> hey jcsackett could you look at this charmworld exodus branch when you get a chance? https://codereview.appspot.com/89770044/
<jcsackett> bac: looking now.
<rick_h_> jcsackett: k, free link me up to a hangout when you're ready
<jcsackett> rick_h_: ok.
<jcsackett> bac: so, i'll actually review right after chatting with rick_h_ 
<bac> ok
<jcsackett> rick_h_: link is https://plus.google.com/hangouts/_/76cpjte2d4j5v28msijuvbb2tg?hl=en
<rick_h_> jcsackett: "this party is over"
<jcsackett> i freaking hate google.
<jcsackett> rick_h_: you're on plus now?
<rick_h_> jcsackett: https://plus.google.com/hangouts/_/7ecpi051hcetihavdvas78pick?hl=en
<jcsackett> bac: ok, looking at your branch now.
<jcsackett> bac: did you sort out logging weirdness?
<bac> no, not yet
<bac> i improved it in another branch but we still just pretend to have hiearchical logs
<jcsackett> bac: ok. i saw use of the charm.NAME system and dared to hope you had figured it out. :p
<bac> jcsackett: no, i just perpetuating the fraud
<bac> s/i j/i am j/
<jcsackett> bac: comments on the diff.
<rick_h_> jcsackett: some fyi https://github.com/juju/juju-gui/blob/develop/HACKING.rst#typical-github-workflow 
<rick_h_> jcsackett: and the section under there for helpful aliases/etc
<jcsackett> rick_h_: thanks--i read the workflow bit earlier, i'll check out the aliases.
<rick_h_> jcsackett: cool
<jcsackett> oh my lord. i've somehow made xchat notify me on all messages in any channel. this cannot stand.
<bac> jcsackett: changes made to https://codereview.appspot.com/89770044/
<Makyo> jujugui call in 10
<rick_h_> hey, one minute to go still 
<Makyo> I'm going by my phone alarm, so t-mo says it's time!
<jcsackett> bac: looking.
<jcsackett> bac: LGTM. Thanks!
<Makyo> jujugui call in 2
<Makyo> Today's house: http://www.zillow.com/homedetails/6216-Becker-Ln-Loveland-CO-80538/13881778_zpid/ Excited, but worried about the lack of bathroom pics.
<jcsackett> nice.
<rick_h_> yummy wood floors
<rick_h_> ok, the moon pic is a bit of a sales job
<Makyo> Totally, haha.
<Makyo> Ditto the elk.  That's across the road
<jcsackett> that kitchen, though. that's awesome.
<rick_h_> kadams54: is this rebased on develop?
<Makyo> Right? Granite countertops with glass-tile backsplash.
<kadams54> rick_h_: Yes, rebased on develop as of Friday morning.
<kadams54> Give me a moment and I'll make sure it's got the absolute latest.
<rick_h_> kadams54: all good, monday readings I confused myself
<jcsackett> Makyo: if you end up w/ that kitchen, ima be jealous.
<Makyo> I'm already excited. Only problem is going to be brewing, that'll have to be all outside, since that stovetop won't work for it.
<kadams54> rick_h_: Confirmed: my deployed-unit-tokens is rebased on the latest from develop.
<rick_h_> kadams54: k, feedback done
<rick_h_> jujugui quick mechanical review please https://github.com/juju/juju-gui/pull/247
<bac> rick_h_: ok
<rick_h_> thanks bac
<bac> rick_h_: done
<bac> rick_h_: that's a boar
<rick_h_> thanks bac, it's too monday to trust my eyeballs
<bac> as in boaring
<rick_h_> oh lol, just seeing the comment
<hatch> rick_h_ your flags branch is missing all of the css flag changes
 * rick_h_ goes to look
<rick_h_> :qa
<rick_h_> bah
<hatch> see what I mean?
<rick_h_> hatch: yea, there was one that was state. Updated 
<rick_h_> the others are all mv and that's the same
<rick_h_> and no ecs related ones I see
<hatch> oh right - I spent some time merging the li and state ones before
<rick_h_> thanks for the catch
<hatch> so does your branch remove ecs entirely?
<rick_h_> hatch: yes, it's all mv
<rick_h_> hatch: they need each other so making it all part of that work. qa and such should all be done together
<hatch> yeah ok cool, just wondering so when I load it up in the future I know what flags to use
<rick_h_> yep, il/mv and by thurs only mv is the plan
<hatch> was `state` too long to type? lol
<Makyo> *weekly iteration of  "I hate promises."*
<hatch> haha Makyo we still have promises? 
<Makyo> Yep.
<hatch> lemme guess.....syntax error without any information as to where the error is occuring? 
<hatch> occurring 
<Makyo> Close.  Env trying to access non-existent property with no indication on where that call to the env is being made.
<rick_h_> hatch: no, il was what I told everyone to use. It was what design is testing as, what they've shared with Mark S during demos, etc
<rick_h_> hatch: so state was just not what was agreed among a bunch of people and made up and made state stuff hidden during qa/testing of other branches of code
<kadams54> guihelp: quick YUI question: Node.append() seems to only take a single element (string, Node, or HTMLElement); what if you have an array of Nodes (Node[]) that you want to append?
<hatch> Makyo ugh that's even worse....YUI will -not- be adding in anything for proper stack traces either unfortunately - they are keeping it exactly to A+ :(
<rick_h_> I thought append would take a nodelist as well as a node?
<hatch> kadams54 it'll take a string
<hatch> if it's a nodelist then it'll loop over it
<hatch> not very performant
<kadams54> Not a NodeList
<rick_h_> yea, the point is to make it fast
<kadams54> Though I suppose it could be
<hatch> kadams54 can you create a string and append the string?
<kadams54> Yeah, that was going to be my ugly hack fallback
<rick_h_> kadams54: what about making the <ul> a var form Y.Node.create and then in each loop iteration add to that node
<kadams54> nodes.join('')
<rick_h_> kadams54: and at the end put that UL into the dom
<rick_h_> kadams54: so you're just appending one node to a container in the dom, and building the whole UL programatically outside of the DOM
<kadams54> Ah yeah, that would work
<hatch> just an FYI datatable does everything as string templates unless it's forced not too which gives it like a 75% boost in performance
<kadams54> *sob*
<rick_h_> kadams54: ?
<kadams54> It just seems wrong to have this tree API (DOM) but instead fallback to string manipulations
<rick_h_> ah, gotcha
<kadams54> It makes me sad
 * rick_h_ was worried you hit another issue 
<rick_h_> meh, react shows you don't have to go to pure strings for performance. 
 * rick_h_ wants YUI widgets on top of a react backend badly
<hatch> I can't really comment, I don't know the context of what you're doing
<rick_h_> hatch: generating tokens (Views) to put into a div in a loop
<hatch> react works a little differently, if it's calculated diff required it to generate a ton of elements in the DOM its performance would likely also suffer
<hatch> ohh, is this regarding generating containers for the token views?
<rick_h_> right, but the point is that the calculations happen outside of in the DOM tree, but in a pure memory tree and thus is fast
<rick_h_> hatch: rgr
<rick_h_> hatch: well, kind of, but that area of the code yet
<hatch> oh....well I gave Huw the information to make his branch work properly
<hatch> to the 'convention' that is
<hatch> https://github.com/juju/juju-gui/pull/233/files#diff-947e688a9f9e23383a48af542be63bbfR142
<hatch> ^ kadams54 
<hatch> and then you pass the 'parent' node into the render method as a param
<rick_h_> hatch: but kadams54 and I disagree withthe container being a LI
<rick_h_> so you test that with a container that's not a normal div? That seems broken
<hatch> I'm not sure I understand?
<hatch> each token isn't a li>
<rick_h_> it is in the use case of the panel, but if that token were reused anywhere else? Or just want to create atest of the token. Why an IL is a specific detail in one use case and we disagee it should be a View's container template. 
<hatch> https://gist.github.com/hatched/533588638633a831a291
<kadams54> The goal is to keep the Token object as stupid as possible
<jcsackett> jujugui, i am routinely having the gui hang at the loading screen. i've got the gui running in an LXC, and accessing via browser on my main machine. any gotchas y'all can think of?
<hatch> jcsackett open the network tab
<rick_h_> jcsackett: check the console?
<hatch> is it hanging on loading YUI
<hatch> ?
<rick_h_> jcsackett: if it's handing at loading it should be dumping something out to you
<rick_h_> hanging that is
<kadams54> So making the token handle a "containerTemplate" seems like the wrong place for that logic.
<kadams54> I'd rather the code using the token (MachineViewPanelView in this case) handle that.
<jcsackett> i have no errors in console, and everything is actually pulled down. just sitting at the spinner.
<hatch> jcsackett odd.....usually it hangs on loading YUI 
<hatch> jcsackett maybe `make clean-all && make devel` 
<hatch> kadams54 I'm skeptical of making it 'too dumb' imho
<hatch> now that means that it requires extra setup for testing and whatnot 
<hatch> especially if there isn't a use case that you can think of where it's container would be different
<rick_h_> hatch: disagree, it just needs to be rendered. Put it in a container div. 
<rick_h_> what testing bootstrapping does it add to?
<kadams54> Yeah, seems like dumber object == less testing bootstrap
<hatch> then why supply a container at all?
<hatch> just let it create it's own div and be done with it
<hatch> I was under the impression that the <li> was an important element to the view
<jcsackett> hrm. make clean-all etc seems to have fixed it. i am suspicious of my setup now.
<jcsackett> is lxc still a way people work on this? i note vagrant is now documented.
<hatch> jcsackett it's ok, it happens
<hatch> jcsackett a bunch of use use vagrant
<rick_h_> to the panel and only for css purposes.
<rick_h_> jcsackett: yes, I work in lxc
<jcsackett> cool.
<hatch> jcsackett the makefile is kind of like a magic script
<hatch> you can't read it
<hatch> you just hope it works
<hatch> :P
<hatch> lol
<rick_h_> because merge-files is so much better :P
<rick_h_> magic that sucks to no end when it breaks. 
<hatch> oh yeah but I've got that figured out now
 * rick_h_ hates looking up how to debugger into a nodejs script every time that damn file has to be touched
<hatch> I know why merge-files breaks
<hatch> lol
<kadams54> OK, heading out for my dr appt
<hatch> rick_h_ maybe one of the next week tasks can be to rewrite our makefile in grunt :)
<rick_h_> hatch: heh, I just got 10 people to buy the makefile book after a talk on grunt at pycon because I ranted on how it's just reinventing the wheel poorly
<hatch> clearly they haven't seen our makefile....
<hatch> :P
<rick_h_> oh if only other people didn't write things we don't ourselves agree with or follow...oh wait. :P
<hatch> grunt, gulp, etc etc etc are 'task runners' 
<rick_h_> funny that, Make is a build tool. I don't need tasks run, I need things built
<rick_h_> if I want to go ssh into a box and run a command I'll use juju actions (coming to an environment near you)
<hatch> right, but it's impossible to follow at a glance
<rick_h_> hatch: so we have a complicated one, sorry. https://github.com/bookieio/breadability/blob/master/Makefile start there :)
<hatch> that's the exact issue....as the complexity increases it becomes less and less manageable 
<hatch> it's like writing a js app in a single jquery file
<hatch> :)
<rick_h_> anyway, refactoring of the makefile is welcome. grunt/etc aren't magic bullets of complexity management either and it's another tool/etc we don't need. Everyone (almost) in the company speaks makefile and it's the standard and we've not hit anything it's not capable of doing. 
<rick_h_> education + refactoring > buying into another tool of doom 
<hatch> I'm not sure it can be refactored to be legible....hope I can be proved wrong :)
<hatch> oh....btw my containerTemplate proposal would still allow you to render the view in tests as a div and in the app as a li
<rick_h_> hatch: right, by passing the arg in to override
<rick_h_> hatch: understand
<hatch> maybe what you're looking for then is to have the view generate a string which then gets appended outside of the view
<hatch> so the view is kind of like a template generator
<hatch> oh that won't work
<hatch> well, it would
<rick_h_> hatch: yea, I've done it both ways before. Where render returned the html, and where you specify the 'renderTo', and it just renders itself
<hatch> but probably wouldn't be worth the extra work
<hatch> yeah I've never liked that approach, it's confusing
<hatch> better to stick to conventions whenever possible
<rick_h_> exactly, let's get this landed and move forward. We can chat about it at vegas if required. 
<rick_h_> but I think the root of it is that kadams54 and I get an icky feeling when a View is anything but a div. 
<hatch> poor poor back end devs
<hatch> :P
<rick_h_> ok, time to get some real work done. 
<hatch> we should maybe re-evaluate huws branch then
<hatch> to align the two
<rick_h_> hatch: +1
<hatch> Makyo as a general rule do you use pointers in Go or assign return values to variables instead? I prefer the latter
<Makyo> hatch, the latter, I believe, and you can return multiple values, so it's usually retVal, err = fn(params)
<hatch> Makyo yeah that's what I prefer too but I've seen the other way in others code and I can't see why they would do it that way
<Makyo> hatch, just different backgrounds, probably. That's more C/C++ish
<Makyo> Took a lot of getting used to working with Qt/.
<hatch> yeah that's what I was thinking
<hatch> I remember doing that back in the C++ days
<rick_h_> jujugui quick review + QA please. One line fix + bunch of lines of test. https://github.com/juju/juju-gui/pull/248 
<rick_h_> hatch: what's viewNavigate now?
<hatch> changeState
<rick_h_> hatch: ty
<jcsackett> ah, changeState. my good friend.
<hatch> np, yeah, everywhere that fires viewNavigate atm should fire a changeState
<hatch> the handler is also in the same place in browser.js
<jcsackett> hatch, do you have a moment to chat, or are you actually taking today off but hanging in the channel?
<hatch> jcsackett I'm working on some Go stuff but I can context switch for you :)
<hatch> fire me a hangout link
<rick_h_> me too, want to bug hatch as well :)
 * hatch knew he shoud have started his house work already
<jcsackett> so...the section of plus that lets me fire up a hangout isn't loading.
<jcsackett> rick_h_, you want to try?
<rick_h_> jcsackett: yep, inviting
<rick_h_> hatch: do we have anything that tests the dispatching in browser.js for the new state stuff?
<hatch> rick_h_ I think the charmbrowser and inspector methods are unit tested but the state instantiation isn't 
<rick_h_> hatch: yea, I've added the dispatch stuff to the machine method in the browser.js but not seeing a good place to test it. Will tack it into the existing browser_app tests for the moment.
<hatch> it's probably stable enough now that they could be added
<hatch> there is a dispatcher describe in the browser.js test file
<rick_h_> ah, describe('state dispatchers', looks like what I want
<hatch> tests so need refactoring heh
<rick_h_> yea
<hatch> ya know, I'm not convinced the go ecosystem is ready to be a webserver
<hatch> I mean, sure it works and all that, but node/python have so many more libs
<rick_h_> jujugui looking for two reviews now please https://github.com/juju/juju-gui/pull/249 and https://github.com/juju/juju-gui/pull/248
<rick_h_> nothing huge, QA required
<rick_h_> kadams54: make sure to rebase, I had the one landing that changed the flag names this morning
<rick_h_> kadams54: was going to ping but you were afk for a chunk there
<kadams54> Yeah, will do
<rick_h_> or af-irc
<rick_h_> kadams54: if you get a second before your next branch a couple of reviews ^ appreciated
<kadams54> Sure
<kadams54> I'll dig into both
<rick_h_> ty much, hopefully small/quick
<kadams54> rick_h_: both look good and ready to merge.
<rick_h_> kadams54: ty much sir
<rick_h_> woot! landing 3 branches in one day. Take that management school! 
 * rick_h_ stops taking another card because it's meeting time coming, doh!
<Makyo> jujugui time to split my day. Will be back and have this card proposed later tonight.
<Makyo> Putting laptop away because contractor's here for a bit longer.  Email or phone is best.
<rick_h_> Makyo: rgr, I'll be around post 5:30 your time if you need anything (think you're 3hr behind)
<Makyo> It's 1:13 now.
<rick_h_> Makyo: ok, 6:30 your time then
<Makyo> Will be back 5:30 my time if commute goes well.
<Makyo> Cheers, thanks rick_h_ 
<BradCrittenden> hey rick_h_ i'm looking at bug 1309678 -- i'm not sure why juju-gui even cares about the control-bucket.  you have any ideas?
<_mup_> Bug #1309678: a value is required for the control bucket field <juju-quickstart:In Progress by bac> <https://launchpad.net/bugs/1309678>
<bac> rick_h_: it could be that previously juju would fail if it weren't there but now it generates one
<bac> rick_h_: oops s/juju-gui/juju-quickstart/ above
<jcastro> does anyone have the gui working in trusty/power?
<jcastro> http://pastebin.ubuntu.com/7301778/
<jcastro> I get this still
<jcastro> rick_h_, ping
<rick_h_> jcastro: this is the trusty charm?
<rick_h_> jcastro: can you verify that those packages are packaged for power then? Do we have a bad dep?
<jcastro> no
<jcastro> but it worked for matt on another machine
<jcastro> odd, investigating
<rick_h_> jcastro: is there someone that has access to a power machien to test the apt-get command? apt-get install libapt-pkg-dev python-apt python-launchpadlib python-tempita python-yaml
<jcastro> sec, I am pulling the charm pristine
<rick_h_> jcastro: k
<jcastro> sorry it's a long pull
<rick_h_> jcastro: np, standing by
<jcastro> rick_h_, is there a trick for a lightweight checkout?
<rick_h_> jcastro: looking if we have a release of the charm sans history
<jcastro> rick_h_, can I clone from github directly? 
<jcastro> is that fine?
<rick_h_> jcastro: the charm isn't on github, only the gui itself
<rick_h_> jcastro: the charm includes the gui release tarball in it
<rick_h_> jcastro: so it works 100% offline
<jcastro> ack
<jcastro> where's the charm
<jcastro> lp:juju-gui?
<jcastro> I need to grab it locally and then tarball it to the machine because it's timing out
<rick_h_> https://code.launchpad.net/~juju-gui-charmers/charms/trusty/juju-gui/trunk
<jcsackett> rick_h_, i've started creating a test suite for service-inspector b/c it doesn't have one at all. is this actually worth while, or do we assume service inspector is safely tested implicitly?
<jcsackett> asking b/c i realize i'm delaying just landing a one line fix for not much added value.
<jcsackett> s/landing/reviewing and landing/
<rick_h_> jcsackett: huh? it should have some tests. Maybe looking in the wrong place?
<rick_h_> jcsackett: it's a viewlet and part of the viewlet-mananger
<rick_h_> jcsackett: for your issue of hte close button I'd not worry about it atm. As we've said the goal is to remove that all together by thurs
<rick_h_> if you can add it cheaply awesome, otherwise let's deprecate it asap
<jcsackett> rick_h_, it's increasingly obvious that it's not super cheap. i'll get the fix up for review.
<rick_h_> jcsackett: rgr
<jcsackett> rick_h_, also, the viewlet manager test stuff has no actual mention of the service-inspector, as it stands.
<rick_h_> jcsackett: k, I know there's some test gaps (we've got a sprint goal to get a code coverage tool into place) but I know there are some tests. 
<jcsackett> rick_h_, like i said, it may well be tested implicitly. and there are lots of tests, so i'll be the first to admit i could've missed them, but ack shows no use of any of the module names, objects, etc anywhere in tests.
<jcsackett> anyway, something for another day.
<rick_h_> jcsackett: k, yea can look around later. 
<rick_h_> jcastro: any luck? Want me to build a tarball?
<rick_h_> or zip I guess
<jcastro> almost ready
<rick_h_> jcastro: k
<jcastro> rick_h_, deploying now
 * rick_h_ crosses fingers I guess
<jcastro>   agent-state-info: 'hook failed: "install"' again
<rick_h_> k, so question is if it's the same point and if so what's the actual failure in that apt-get command
<jcastro> yeah
<jcastro> so the packages are all there on ppc
<jcastro> rick_h_, I think I found the issue
<rick_h_> jcastro: what can we do to help?
<jcastro> I think you need to do an apt-get update first
<jcastro> when I ran it it 404'ed all the debs
<rick_h_> jcastro: ah, ok
 * rick_h_ checks out the code for the charm
<rick_h_> doesn't juju do that when you bring up a new machine?
<jcastro> no idea
<jcastro> hey how do I do an apt-get update in python?
<jcastro> so I can just fix it for the demo?
<rick_h_> sec, looking at the code
<rick_h_> jcastro: I think you can just add 
<rick_h_> run('apt-get', 'update') 
<rick_h_> before the install in line 36ish
<jcastro> rick_h_, I can confirm that fixes the issue!
<rick_h_> jcastro: rockit, I've added a card and we'll try to get that updated. 
<rick_h_> jcastro: you unblocked for the demo for now then?
<jcastro> yes
<jcastro> we need this fixed by EOW btw
<rick_h_> jcastro: ok cool, thanks for calling to get me on it
<rick_h_> jcastro: k, will do. 
<jcsackett> jujugui: super short pr, can i get a review?
<jcsackett> https://github.com/juju/juju-gui/pull/250
<rick_h_> jcsackett: will do
<jcsackett> thanks rick_h_ 
<jcsackett> rick_h_, just discovered on a make check i have a test failure. not sure why it didn't show on test-debug, but it answers my earlier testing question.
<jcsackett> updating and pushing in a moment.
<rick_h_> jcsackett: k
<jcsackett> hrm. i'm going to need find a way to get juju-gui email to go to my work email, not my personal.
<rick_h_> there's a trick to it
<rick_h_> can look it up later
<jcsackett> that would be awesome.
<jcsackett> Is there a way to squash/cleanup commits once you've got PR up?
<rick_h_> git rebase -i
<rick_h_> clean up
<rick_h_> git push origin XXX:XXX --force
<jcsackett> Ah. And that doesn't monkey up the PR? Or we just don't care?
<rick_h_> we don't care
<jcsackett> Cool. 
<jcsackett> Thanks.
<rick_h_> jcsackett: https://github.com/settings/emails and add the other address
<rick_h_> jcsackett: so I added my canonical address there as an additional and it's picked up from my commits in github
<rick_h_> ok, EOD for now all check you later!
<bac> jujugui: quickstart review at https://codereview.appspot.com/90060043 , though it may make more sense to let frankban look tomorrow
<rick_h_> jcsackett: once you're cool with your branch you have to enter :shipit: into a comment
<rick_h_> jcsackett: and the lander will pick it up
<jcsackett> rick_h_ saw that.
<jcsackett> just waiting for the CI to finish.
<rick_h_> jcsackett: cool
<rick_h_> jcsackett: the windows.flag.state should all be windows.flag.il now as well
<rick_h_> jcsackett: my branch earilier changed them all
<jcsackett> rick_h_, well, guess i'll have another squashed commit and another wait for CI. :p
<rick_h_> :)
<rick_h_> if you're confident about it you can :shipit: before the test run goes
<jcsackett> ah well. at least i got dev stuff sorted today and a minor bug addressed. i'll call it a win.
<rick_h_> landing will run all the same tests, it's just generally good to wait so it doesn't hold up anyone else but you're good
<rick_h_> all good :)
<jcsackett> eh, it's not blocking me and i'm unlikely to do more work today, so we'll see everything go green this time.
<jcsackett> i may not be as patient in the future. :P
<rick_h_> k
<jcsackett> well, more coding. i have lots of emails to sort out--still on all the qa team lists.
<rick_h_> wheeee
<marcoceppi> rick_h_: you around?
<marcoceppi> or anyone, how do I view the import errors on charmworld?
<rick_h_> marcoceppi: I'm cooking dinner but around. 
<rick_h_> marcoceppi: we request a log from webops and look at it :/
<marcoceppi> rick_h_: so, vsm is in charmstore but not in charmworld - promulgated on Friday
<rick_h_> marcoceppi: what are you looking at
<marcoceppi> https://manage.jujucharms.com/api/3/charm/precise/vsm
<marcoceppi> https://store.juju.ubuntu.com/charm-info?charms=cs:precise/vsm
<rick_h_> marcoceppi: https://store.juju.ubuntu.com/charm-info?charms=cs:precise/vsm ?
<rick_h_> ok, looking
<rick_h_> marcoceppi: k, file a bug please and we'll try to get the logs for it. 
<rick_h_> marcoceppi: it proof's but yes it's not in the mjc at all. 
<marcoceppi> rick_h_: right, I'll open a bug
<rick_h_> marcoceppi: ty
<lazyPower> https://bugs.launchpad.net/charmworld/+bug/1310825 - bug deployed
<_mup_> Bug #1310825: VSM charm not listed in charmworld <charmworld:New> <https://launchpad.net/bugs/1310825>
<rick_h_> cool, requested logs from webops, will have more info by tomorrow morning hopefully
<lazyPower> thanks a million rick
<rick_h_> strange it won't ingest. I wonder if there's some strange bzr history thing going on
<rick_h_> marcoceppi: lazyPower logs don't show anything...seems to have fallen into a black hole. I see errors for a couple of vsm branches, but nadda for the promulgated charm
<rick_h_> marcoceppi: lazyPower any chance of doing something small to get a second revision out of it?
<marcoceppi> \o/ rick_h_ all hail the glory of the black hole
<marcoceppi> rick_h_: lazyPower pushed a change to the branch recently
<rick_h_> marcoceppi: ok, the store only shows rev 1 
<rick_h_> marcoceppi: will see if it picks up a rev 2 and if we get any info
<marcoceppi> rick_h_: ack, thanks again for taking a look
 * rick_h_ hates tihs kind of invisible issue
<rick_h_> the only feedback is on other versions Hook not found ~springfield-team/charms/precise/vsm/trunk common.sh
#juju-gui 2014-04-22
<Makyo> lp, put in an offer
<Makyo> That was most of what I typed.  Thanks xchat.
<rick_h_> Makyo: lol
<rick_h_> Makyo: so you put in an offer on the houes you saw?
<rick_h_> jcsackett: recorded myself with that headset. Crazy that noise. Doesn't do it on the air running ubuntu. My other headsets haven't been an issue. 
<frankban> morning rick_h_: do you have a minute for a quick look at https://codereview.appspot.com/90220043 (charm)?
<rick_h_> frankban: will do
<frankban> rick_h_: thanks
<rick_h_> frankban: I've got to take the wife's car into the shop, will be in/out but will be working through it and do qa from there
<frankban> rick_h_: ack
 * frankban lunches
<bac> frankban: thanks for the review.  i think your idea is good.
<rick_h_> geeze this is why I <3 working from home
<rick_h_> stupid rush hour
<bac> rick_h_: at the subaru dealer all morning?
<rick_h_> bac: yea,verified her car is leaking oil in the driveway. She just had an oil change done so I htink they munged up something
<rick_h_> trying to be the good husband and get it handled for her
<bac> well hopefully it is just a small leak.  i've had friends go to jiffy lube and drive away only to get a mile or two before the engine seized since the plug fell out
<rick_h_> yea, I had that happen when I was a kid
<rick_h_> plug fell on the highway in a construction zone
<rick_h_> had to go 4 miles by the time I could pull over
<rick_h_> new engines for me!
<bac> then JL wanted to pay her a pro-rated amount for her dead engine.
<rick_h_> lol
<rick_h_> I only got mine 'rebuilt' but as a college kid I was happy
<bac> oh no, LP hates me
<bac> error: Failed to load data for member "bac": Get https://api.launchpad.net/devel/~bac: EOF
<rick_h_> oops
<rick_h_> you've been cut off
<bac> frankban: i've proposed changes back to error: Failed to load data for member "bac": Get https://api.launchpad.net/devel/~bac: EOF
<bac> let's try that again
<bac> frankban: i've proposed changes back to https://codereview.appspot.com/90060043
<bac> i kept the change s/get_admin_secret/get_value_from_jenv/ as it is more generic and may be useful in the future.  but it may be YAGNI.  let's discuss.
<bac> rick_h_: the deploy of the migration to staging on prodstack failed yesterday.  i had to run a full ingest on my laptop last night so i can try to reproduce the problem
<rick_h_> bac: :(
<rick_h_> bac: good to know thanks. Yay for staging doing its job I guess
<rick_h_> bac: there was an ingestion issue yesterday as well. I filed a bug on there 
<bac> yeah, but having the other we control would've been nicer
<frankban> bac: cool, taking a look
<rick_h_> bac: I tried to look into it but something in charmworld hates that charm. 
<bac> rick_h_: is it on the board?
<rick_h_> bac: yes, the vsm charm
<bac> cool
<frankban> rick_h_: thanks for the review, I already created a card to update docs while making a release, my next thing after this branch lands
<rick_h_> frankban: awesome, thanks. I need to rename my code reviews to "rick thinks out louad" :)
<frankban> :-)
<rick_h_> bah, can't type on this air
<frankban> guihelp: charmworld shows that Last ingest job "finished at 2014-04-18 17:34:37Z". 
<rick_h_> frankban: oh hmm, well that may be the ticket. Oh, and the queues are where I saw them yesterday
<bac> frankban: looking
<rick_h_> lol, I just saw the queues and missed the numbers didn't change
<rick_h_> frankban: does this not need a functional test run?
<frankban> rick_h_: I run the suite, and I'll run it again for the release, so it's not required now
<rick_h_> frankban: rgr
<rick_h_> frankban: LGTM then, after the release please ping jcastro so he knows his fix is out. 
<frankban> rick_h_: sure, thanks
<rick_h_> luca: morning
<jcsackett> morning all.
<frankban> bac: your branch LGTM
<bac> frankban: thanks
<rick_h_> jcsackett: party
<frankban> jujugui: heads up email to peeps re: charm development environment
<rick_h_> frankban: ty much kind sir
<luca> morning rick_h_ 
<rick_h_> luca: hey, any chance of bumping up our catchup?
<rick_h_> luca: or are you guys busy? :)
<luca> rick_h_: you want to have it sooner than later?
<rick_h_> luca: yep
<luca> rick_h_: I can do it in 10 mins if thats ok
<rick_h_> luca: sounds good thanks!
<luca> rick_h_: no worries
<jcsackett> rick_h_, given the MV priority, should i be looking at that stack of cards for today's work? and follow up question: if yes, what should i take a look at to get up to speed on said project? :p
<rick_h_> jcsackett: stick in project A if possible
<jcsackett> rick_h_, you got it.
<rick_h_> jcsackett: either the charm search card or the charm browser home button with kadam's face on it
<rick_h_> just take him off
<jcsackett> dig.
<rick_h_> lazyPower: marcoceppi https://jujucharms.com/precise/vsm
<bac> jujugui: m.j.c is ingesting charms again.
<bac> looking at log files and keeping an eye on it
<jcsackett> bac: what was preventing vsm from being ingested?
<rick_h_> bac	ty
<bac> jcsackett: nothing was being ingested and i haven't looked at that one specifically yet
<rick_h_> bac: it's all good
<rick_h_> clsoing the bug
<jcsackett> bac: ah, ok.
<rick_h_> it was due to no ingestion at all happening
<bac> rick_h_: that's what i assumed
<rick_h_> luca: no hangout on that calendar entry to please invite me to whatever you guys set up. 
<bac> rick_h_, jcsackett: weird, it looks like ingest just gave up a few days ago. https://pastebin.canonical.com/108930/
<bac> i assume the two github attempts right after midnight are due to it being kicked by logrotate or something
<bac> the IngestErrors for "charm contains no files" are handled and aren't fatal to the process
<jcsackett> bac, yeah, i think i recall no files being handled back in the orangesquad days.
<bac> jcsackett: but then it just went on strike
<bac> servicectl status showed it was alive.
<jcsackett> bac: eh, ingest is a tetchy beast. it probably just wanted a holiday.
<rick_h_> bac: rgr, we should add a low maint task to add a nagios check for that last run stuff
<rick_h_> bac: so at least if it gives up the ghost for a day we know about it 
<rick_h_> or at least make that RED on heartbeat
<rick_h_> so blind people like me can see what's up :)
<bac> sure
<jcsackett> jujugui: i'm finding that `make clean-all test-debug` is requiring my password for sudo rights. any idea what i goofed?
<rick_h_> jcsackett: check perms on ~/tmp and ~/.npm
<rick_h_> jcsackett: the instructions should have had you chown those during the setup
<rick_h_> jcsackett: but you shouldn't need to run make clean-all much
<bac> jcsackett: oddly enough it did shut down right on good friday.
<rick_h_> as well
<jcsackett> rick_h_, it just tells you to make them, which shouldn't be a problem since they should default correctly.
<jcsackett> and indeed, i am owner &c.
<rick_h_> jujugui on the road back home, biab
<jcsackett> ha! i love that it died on good friday.
<jcsackett> ...oh, bad word choice on my part...i love that it took good friday off.
<lazyPower> rick_h_: thanks for looking into that.
<bac> jcsackett: the exodus branch from yesterday failed when deployed to staging.  this branch is the fix.  could you take a look at it?  https://codereview.appspot.com/90300043
<jcsackett> bac, lgtm
<bac> ty jcsackett.  now to try to deploy to staging and make it happy again
 * rick_h_ is back
<rick_h_> jcsackett: not sure then on the sudo thing.
<jcsackett> rick_h_, no worries, i'll poke at it later. it's doing something with /usr/local/src, but it's an LXC so meh.
<jcsackett> rick_h_, got a quick sec for g+?
<rick_h_> jcsackett: sure thing
<rick_h_> shoot me a link
<jcsackett> rick_h_ https://plus.google.com/hangouts/_/7acpj4cuggoppve90pnm3v27hs?hl=en
<jcsackett> jujugui: can someone take a look at a short PR for me? https://github.com/juju/juju-gui/pull/252
<bac> jcsackett: i will after the meeting
<jcsackett> bac, thanks.
<bac> jujugui: meeting at :00
 * jcsackett needs coffee for meetings
<frankban> jcastro: new precise and trusty charms released/ingested with the apt-update fix
<kadams54> Question about testing and flags: I see a slew of tests in test_browser_app.js that check to make sure various routing situations are handled correctly. It seems like they're all run sans flags. Is there a way to easily control flag values for a test?
<jcastro> frankban, thank you sir!
<jcastro> rick_h_, man I can't believe I found a bug and a fix!
<rick_h_> jcastro: :)
<jcastro> rick_h_, and you were probably bored at some meeting
<frankban> :-)
<rick_h_> jcastro: someone has to plan for everyone else to be bored in vegas :P
<Makyo> jujugui call in 1
<jcsackett> kadams54, you'll see many a test set window.flags = $flag_you_need
<jcsackett> just make sure there's cleanup as well.
<rick_h_> Makyo: join the hangout again?
<bac> jcsackett: i'm looking at your branch.  i'm trying to see the broken behavior on jujucharms.com
<bac> jcsackett: i searched for mysql and then clicked on the home icon.  seemed to work.  what am i missing?
<jcsackett> bac: with il?
<bac> OH ff
<jcsackett> yup
<bac> jcsackett: like so?  https://jujucharms.com/sidebar/search/:flags:il/?text=mysql
<bac> jcsackett: or is there another slash after :flags:
<bac> either way i don't see it misbehaving
<rick_h_> bac :flags:/il/?
<jcsackett> huh, it isn't misbehaving on jujucharms; it does on develop locally tho.
<rick_h_> jujucharms is old
<rick_h_> use comingsoon
<bac> ahhhh.  doh.
<rick_h_> it's stuff that's broken in code since the last release
<bac> ok, that is def broken: http://comingsoon.jujucharms.com/:flags:/il/?text=mysql
<rick_h_> :)
<rick_h_> and now hopefully fixed 
<jcsackett> rick_h_, responded to your comment with updated branch. bac, you still looking?
<bac> jcsackett: done
<bac> jcsackett: now, really done
<jcsackett> bac: the test is just for metadata being safely reset--component resets are already tested.
<bac> ok
<jcsackett> rick_h_, the other card you told me to look at was the one about updating charm-search.js to use new state? just confirming what "charm search card" meant.
<rick_h_> jcsackett: that one and the one that kadams54 is working on are closely related. That one needs to bring the filters object back into the state code
<rick_h_> kadams54: sorry, I mixed up this card and yours this morning
<rick_h_> jcsackett: yes that's the card I mean and it's updating the charm-search.js and bringing the filters back for managing the query string/search api call
<jcsackett> rick_h_, dig. i'll start looking into it post lunch.
<jcsackett> oh, wait, missed what you just said.
<jcsackett> shall i leave that one to kadams54 then, post his work?
<rick_h_> jcsackett: I think you can get started, but will have to incorporate his work. Maybe sync with him on it. 
<rick_h_> jcsackett: he's not touching things like charm-search.js but he is in the state code dealing with filters/query string changes
<jcsackett> rick_h_, dig. i reiterate my post-lunch remark then. :p
<jcsackett> kadams54, you likely to be around to chat a bit past 1?
<kadams54> Yes
<jcsackett> cool beans. i'll ping you around then and we can make sure i don't wreck anything. :)
<jcsackett> kadams54, free to chat at 1:30?
<kadams54> jcsackett: let me ping you when I'm ready. Just got a call from my son's school that he's had an accident and I need to run out a fresh change of clothes :-(
<jcsackett> kadams54, dig. that is def a priority situation.
<Makyo> jujugui review/qa of relations+ecs stuff https://github.com/juju/juju-gui/pull/253
<Makyo> Lost my pre-push hook, so lint may be bad.
<jcsackett> makyo: i can look, but please tell me what does ECS stand for?
<Makyo> jcsackett, Environment Change Set.  Local transaction that will be tied to a deploy button, so that you can work locally, then deploy all changes at once.
<jcsackett> ah, so set up the whole set of relations and go rather than just one service at a time.
<jcsackett> cool. looking now, makyo.
<Makyo> It's all hatch 's fault, jcsackett 
<Makyo> (well, okay, 90%)
 * jcsackett laughs
<hatch> lol
<jcsackett> Makyo, i've finished looking at code, QAing now--none of my comments are major.
<jcsackett> looks like hatch is reviewing it too.
<Makyo> Good.
<Makyo> Thanks guys
<jcsackett> Makyo, looks like your QA directions got cut off? "ensure that the relation"
<Makyo> jcsackett, oops, sorry.  Ensure that the relation is in the changeset by investigating app.ecs.changeSet in the javascript console.
<Makyo> Updated.
<jcsackett> Makyo, thanks. it passes your QA instructions--ping me when you address rick_h_'s comments about flags and i'll double check QA again.
<Makyo> jcastro, will do.  Thanks!
<Makyo> jcsackett, Sorry, thanks.
<Makyo> jcastro, Lazy fingers, don't mind me
<kadams54> jcsackett: ready to talk when you are
<jcsackett> kadams54, awesome, i'll pass your a URL momentarily.
<jcsackett> kadams54, https://plus.google.com/hangouts/_/7acpj3384g52o10sitntlhkh3s
<kadams54> Says the party is over :-/
<jcsackett> ...bloody hell.
<jcsackett> kadams54, are you signed in as your @canonical.com self?
<jcsackett> what is your email?
<kadams54> kyle.adams@canonical.com
<jcsackett> kadams54, give it a try now.
<rick_h_> Makyo: comments added, I'm curious on the ecs as an arg vs communicating with the env 
<Makyo> rick_h_, Every time I bring up events, I get in trouble, so I avoided it.  If that's the path we're heading down, I'm all for it.
<Makyo> In particular, hatch__ has been a pretty big opponent of event-based work such as the topology.
<Makyo> Not quite sure who to make happy here :)
<jcsackett> rick_h_, you got a second to chat? 
<rick_h_> Makyo: k
<rick_h_> Makyo: I'm just curious if there was a big reason
<hatch> who said what in the where now?
<rick_h_> Makyo: I think it makes the topology simpler and keeps it cleaner especially as it's nuts for it to deal with the ecs everywhere
<rick_h_> jcsackett: sure thing
<rick_h_> jcsackett: linky?
<Makyo> rick_h_, sure, makes sense.
<jcsackett> rick_h_, https://plus.google.com/hangouts/_/7acpj3384g52o10sitntlhkh3s
<Makyo> hatch, using events to communicate between layers of the application.
<rick_h_> jcsackett: is that from your url in the browser?
<jcsackett> rick_h_, nope, that's from the share window, where i just invited your canonical address.
<rick_h_> jcsackett: no worky, invite me?
<hatch> ahh yeah
<rick_h_> jcsackett: oh you've got to start it first then give me the live hangout url
<jcsackett> rick_h_, it's started. i'm sitting in it.
<rick_h_> jcsackett: invite again please. 
<jcsackett> rick_h_, hang on, i'm just going to start a new one.
<rick_h_> Makyo: well I appreciate your thoughts on the two paths. 
<jcsackett> rick_h_, invite sent.
<rick_h_> Makyo: we can mute hatch if we have to, he's on vacation and we can do what we want :P
<jcsackett> rick_h_, https://plus.google.com/hangouts/_/7acpifdroro7ler4og7bqoom8k
<Makyo> Hahaha
 * hatch is wondering if he should join this hangout
<rick_h_> hatch: not yet
<Makyo> + like a million
<rick_h_> Makyo: k, then we can chat with hatch if he has issues but I like the simpler use of events in this case
<hatch> I'm not done going through the review yet
<Makyo> rick_h_, sure, I think it's a good direction to move in.  I'll investigate heading in that direction.  Thanks for the multiple reviews
<hatch> I'll hold off until then
<Makyo> hatch, go ahead and finish if you find anything outstanding.
<Makyo> I'll get them all in one go.
<Makyo> the asynchronicity was something we agreed on, hatch. Wait until each layer of the hierarchy came back before starting the next so that we were sure the entities existed in the state machine.
<Makyo> As in, can't create a relation between services that don't exist in the state machine yet.
<rick_h_> Makyo: yea, and my comments on that I realize are more wide ranging than this branch
<rick_h_> Makyo: so you hatch and I should chat about the long term usage of this in real life use cases
<hatch> Makyo ok right, I'm just trying to see if I see a better way for that
<hatch> I don't like using Y.soon just to pop things to the top of the stack
<Makyo> hatch, ah, okay.  More than happy to change it, I don;'t like it either.
<Makyo> Though it does show up elsewhere in our code.
<rick_h_> Makyo: big one at https://github.com/juju/juju-gui/pull/253/files#diff-2396c727b78bbe8c6ff20dc9a231ee2aR935 though
<hatch> yeah it does....but it's pretty much a hack everywhere 
<rick_h_> bah, never mind
<rick_h_> Makyo: ok, so env has an add_relation method? 
<Makyo> rick_h_, yes, though you're right that could do with a test.
<rick_h_> can we not just ecs or not ecs it there in the env then and forget events or passing it in?
<rick_h_> then the topo code doens't need to be changed at all in this branch
<Makyo> Oh, does the env have ecs?
<rick_h_> the env is passing the ecs into topo I thought?
<rick_h_> maybe I'm not following stuff /me looks again
<hatch> the environment view is passing ecs into the topology when it creates the topology
<hatch> not the env
<rick_h_> oh ok
<hatch> confusing name clash :)
<Makyo> Yeah, yikes
<rick_h_> bah, this is nuts
<rick_h_> :)
<rick_h_> ok, so then is there value is giving the env the ecs and making everyone work with him
<rick_h_> vs passing hte ecs into topo/etc?
<rick_h_> the inspector/config changes will want access right? 
<rick_h_> what else?
<hatch> think of the env as a bunch of utilities that the ecs controls in the proper order
<hatch> so the ecs is what other things need to make requests of
<rick_h_> ok, if we swap the env for the ecs I'm ok, but adding to feels like we're muddying things up even more
<hatch> well keep in mind that this is a wip, the ecs never used to exist so everything was calling the env
<hatch> it'll take time for things to move over
<rick_h_> I know but I want to make sure we're thinking/planning for the future and trying to lay down a cleaner path as we go
<rick_h_> if you're saying that all things should talk to the ecs vs the env, then let's do that. 
<rick_h_> I mean if the flag is set pass the ecs into the topology and if not, then pass in the env. Then we have an XXX that when the flag is removed to rename the var or something. 
<rick_h_> but this doesn't plan does a life without env atm 
<rick_h_> it just adds more code and more required setup and more things to keep in your head in the end
<bac> jcsackett: yet another... https://codereview.appspot.com/90420043
<rick_h_> so in looking at this, if we moved the ecs into the env, then we could simplify things. The env is already passed around and is on the environment View. hatch Makyo 
<rick_h_> Makyo: hatch the ecs could be setup with different options as required for sandbox vs go
<rick_h_> Makyo: hatch and things like add_relation could just be 'ecs' enabled?
<Makyo> I can see that working, yeah
<rick_h_> hatch: have time for a call? 
<rick_h_> maybe worth a chat?
<hatch> sec just otp
<rick_h_> hatch: np, appreciate your thoughts while you're away. 
<jcsackett> bac, so we're just losing any bundles that got grandfathered? will those be reingested eventually if they're updated to pass proof?
<bac> jcsackett: yeah, if they are fixed
<bac> jcsackett: it is no loss, they cannot be deployed
<bac> as is
<bac> we've just never had a process to do any housekeeping.
<jcsackett> bac, dig.
<jcsackett> lgtm.
<hatch> ok off the phone
<rick_h_> hatch: k, setting up a call
<rick_h_> hatch: Makyo https://plus.google.com/hangouts/_/76cpik3in0rjn0urt22rbvjpo8?authuser=1&hl=en 
<bac> jcsackett: your approve comment in RV needs to include the magic string LGTM somewhere in it.
<jcsackett> bac: duh, of course. sorry.
<jcsackett> bac, done.
<bac> thx
<jcsackett> jujugui: i believe CI is stuck. is there a means of terminating a build?
<rick_h_> jcsackett: yea second
<hatch> rick_h_ yeah this will be a good change, will make it easier to follow when some things use/don't use the ecs
<rick_h_> hatch: cool
<rick_h_> hatch: thanks for taking the time to chat about it. 
<rick_h_> now go have fun!
<rick_h_> :)
<hatch> annnnnd my flight out of YXE is delayed 3H
<hatch> how the heck....
<hatch> it's not until tomorrow
<rick_h_> ouch!
<hatch> how can it be delayed so bad already lol
<rick_h_> 3hr is quite the delayed
<hatch> I guess I get to sleep in more
<rick_h_> well I'd make sure to watch it. Might move back :P
<hatch> haha yeah wouldn't doubt it 
<hatch> the new google transit maps are pretty cool
<hatch> it was just delayed another 20 mins.... umm
<hatch> maybe I'm driving to Denver
<hatch> lol
<rick_h_> lol
<jcsackett> we only filter on categories now, right? there's no UI to say "just recommended" or "just aws" is there?
<rick_h_> jcsackett: no, there is not
<rick_h_> jcsackett: there's talk of a future "tag based" search UI that we'd detect words as things like that 
<rick_h_> but no current UI 
<jcsackett> rick_h_, awesome. so we don't need to maintain the FILTER_SERIES &c bits? just the categories.
<rick_h_> jcsackett: yes
<jcsackett> alright, i'm not going to delete those bits in this branch, but i'll put a card saying once we remove the il flag they can be whacked.
<jcsackett> s/card/note/
<jcsackett> though, maybe a card as well?
<rick_h_> stick a card in the backlog for it
<rick_h_> and we'll try to get a big cleanup phase into the plans at some point
<jcsackett> "pool" vs "on deck"? i'm guessing pool, but the meaning isn't inherently obvious.
<rick_h_> yes, pool
<rick_h_> on deck is what we planning poker and has a chance to be in the next 2wk iteration
<rick_h_> pool is long term
<jcastro> hey rick_h_
<jcastro> I have an awesome idea
<jcastro> "awesome"
<jcastro> for demo mode
<rick_h_> jcsackett: otp, but love ideas
<jcsackett> he meant jcastro. :p
<jcastro> hey so
<jcastro> https://github.com/chjj/tty.js/
<jcastro> remember how the old old old gui stuff had an idea for a terminal in the webui
<rick_h_> jcastro: but that would have to run on each machine right?
<rick_h_> jcastro: in the environment
<rick_h_> jcastro: we've got tasks for debug-log and juju run to try to do next cycle, should help with some of it
<jcsackett> rick_h_, just a reminder, there's a build stuck on CI.
<rick_h_> jcsackett: ah thanks 
<jcsackett> it's based off my branch, which is a tad alarming, but it doesn't hang locally on a make test or make check
<rick_h_> jcsackett: looks like you've got a login
<rick_h_> jcsackett: so you have to login and then stop it
<jcsackett> i have a login? that's news to me.
<rick_h_> you're in the list :)
<jcsackett> huh. i wonder what my login info is.
<rick_h_> guihelp anyone seen ERROR no such request - method Client.PrivateAddress is not implemented
<hatch> that's new to me, where are you getting that?
<rick_h_> hatch: juju ssh jenkins/0
<hatch> oh that's very odd
 * Makyo returns from house.
<Makyo> Signed my half of the contract, woo
<rick_h_> Makyo: wooo! 
<hatch> oo whats woo?
<hatch> rick_h_ so I'm on test coverage/improvements with kadams54 next wk?
<Makyo> Signed my half of the contract on the house.  Need to get James to sign, then the offer's official.
<hatch> right on!!!!
<rick_h_> hatch: if he's interested
<rick_h_> or Makyo if he is, or jcsackett if he is
<rick_h_> hatch: you just need a programming buddy 
 * hatch brings a rubber ducky 
<kadams54> hatch: sure, test coverage it is
<kadams54> Makyo: congrats!
<Makyo> Thanks :)  Going heads down again to get this branch up ASAP.
<hatch> oh Makyo  the lazyAddRelation is a little confusing around the 'if deploy' block, can you add some comments there?
<Makyo> Yep
<jcsackett> hatch: i may be very interested in test coverage next week. i have concerns about things that are only implicitly tested.
<hatch> jcsackett we need a refactor of our entire test suite so maybe the three of us can chip away at it in the down time
<rick_h_> let's try to get coverage without a rewrite though 
<hatch> just want to make sure we end the week with a 'shippable' project
<rick_h_> something we can accomplish, a rewrite will be a stuck branch
<rick_h_> :)
<jcsackett> i'll accept all parts of state being explicitly tested. :p
<jcsackett> also, maybe we can just kill those 13 pending tests that have been around for ever.
<hatch> haha, they are....you see all those url tests?
<hatch> NEVA!!!!
<jcsackett> hatch, i just changed the new ui state object to load a filter object into metadata.search instead of a string. *nothing* broke.
<jcsackett> i don't for a second believe that means everything is just working. :p
<rick_h_> lol
<hatch> sure - that means it's working exactly as intended 
<hatch> :)
<rick_h_> admittingly search is already broken per kadams54's branch but not a good sign
 * jcsackett laughs
<hatch> honestly though, search is just a key, if you put the wrong stuff in it, that's not the state systems fault
<rick_h_> hatch: but the url generation stuff should go boom
<rick_h_> hatch: I'd expect at least
<rick_h_> hatch: then again I guess the tests put a string in there
<rick_h_> so it's still passing 
<jcsackett> ah, that's true
<hatch> this isn't "enterprise" software, it can only be SO resilient lol
<rick_h_> it's not perfect, but gets better every day
<hatch> oh man I saw some .NET the other day....instead of whitelisting a specific kind of input, it blacklisted......EVERYTHING
<hatch> honestly, it was like 2000 lines 
<hatch> "enterprise yo"
<jcsackett> wow.
<jcsackett> that's both entirely unsurprising and sort of horrendous.
<hatch> haha true true
<Makyo> rick_h_, hatch did we agree to postpone possible changes re ecs/env to a future branch, or should I work in that direction with a comment?
<hatch> future branch
<rick_h_> Makyo: yes, let's do a future branch. Feel free to note any XXX so we can remember what we talked about
<rick_h_> Makyo: but yes, let's get this landed and get the deploy button triggering to this for demo at least 
<Makyo> Sounds good.
<rick_h_> Makyo: I'm 100% ok with a hack for the deploy button. Then we can come back around on this env thing and refactor that up
 * rick_h_ is tempted to just make 'onclick=xxx.commit()'
<hatch> ERMAHGERD
<rick_h_> does that have an english translation?
<hatch> google it
<hatch> lol
<rick_h_> OMG
<hatch> rofl
<hatch> I'm probably using it wrong.....oh well, I live in a bubble
<rick_h_> kadams54: any luck? I was looking at the code on that and I don't see how the code uses the renderSearchResults or anything at all
<rick_h_> kadams54: so it looks like there's a chunk of wiring to make that work on page load
<rick_h_> the dispatch stuff runs sidebar.showSearch but nothing actually makes sure the view is there with any content. 
<rick_h_> in the il flagged dispatch work
<hatch> cool, I have a broken, but working, code coverage implementation working already
<hatch> rick_h_ kadams54 jcsackett - it's ALLLLLIVEEEE (sortof) https://www.evernote.com/shard/s219/sh/12455d7f-3ed4-4884-ba5c-e7fbedcac294/2103b2b738982a28bebe7df94ee63219 
<hatch> this is as far as I'm taking it :)
<hatch> before the sprint that is
<huwshimi> Morning
<kadams54> hatch: Nice.
<kadams54> rick_h_: Yeah, that tracks with what I was finding. Two options: 1) re-jigger routeDefault to somehow get the search into sidebar rendering, likely by taking it from the request rather than from state or 2) re-jigger routeView to render the sidebar if it's not present, likely similar to how routeDefault does it.
<kadams54> huwshimi: Morning :-)
<huwshimi> kadams54: Hey!
<rick_h_> kadams54: have time to chat or want to do it first thing in the morning?
<rick_h_> huwshimi: morning, welcome back
<rick_h_> huwshimi: I've got a mission for you if you're looking for something to do?
<huwshimi> rick_h_: Thanks.
<huwshimi> rick_h_: Sure!
<huwshimi> (was taking a look at the minimize removal)
<rick_h_> huwshimi: invite inbound
<hatch> kadams54 I spent a bunch of time looking at how to do the search within the same code....mind running the issue past me?
<hatch> I may have already explored some routes you're going down :)
<rick_h_> hatch: the thing is that if you have a search in the initial page load /?text=apache then in the old code it would call this.renderSearchResults(req, resp, next)
<rick_h_> hatch: and the new dispatch stuff only calls this._sidebar.showSearch()
<rick_h_> which is the show/hide bit, but not creating the instance of the View for results and such
<rick_h_> hatch: at least that's my cursory look over it atm
<hatch> right, when the sidebar is created it instantiates the search view so it's always rendered
<hatch> just hidden when the inspector is rendered
<rick_h_> hmm, I missed that connection then
<hatch> so where is the problem with that? I'm guessing search + inspector is causing issues?
<rick_h_> no
<rick_h_> just /?text=apache
<hatch> oh, that should work just fine
<rick_h_> the query string search never gets to the dispatched work that I can see
<hatch> hmm that's definitely not right
<hatch> lemme check real quick
<rick_h_> kadams54: the trick is that when the flag is set you shouldn't be hitting defaulrRoute or routeView. 
<rick_h_> hatch: if you can note out the dispatch path on a fresh request maybe that would help. 
<hatch> http://comingsoon.jujucharms.com/:flags:/il/?text=apache
<hatch> that works....?
<hatch> ohhh
<hatch> without the flag is broken
<rick_h_> http://comingsoon.jujucharms.com/:flags:/il/?text=apache doesn't
<hatch> ^ that is the same link that I had working :)
<hatch> did you mean to have that without the il flag?
<rick_h_> oh it's the stupid slash thing
<rick_h_> take that last slash out
<rick_h_> and the url updates to with, but no search is dispatched
<rick_h_> http://comingsoon.jujucharms.com/:flags:/il?text=apache
<hatch> ohh right
<hatch> I think that's an issue with the namespacing
<hatch> that's technically an invalid url 
<hatch> as far as the namespacing is concerned 
<hatch> if I remember correctly
<rick_h_> ok, so have to look at how the dispatch to sidebar to search results works
<rick_h_> and how to get the metadata.search down into the widget
<rick_h_> which is probably expecting a filter object to be sent in
<hatch> yeah, check the state object going to the dispatcher to make sure it has the proper data in it
<rick_h_> which jcsackett is working on adding
<hatch> debugging this is very trivial now
<rick_h_> kadams54: is confused in routeDefault vs routeView vs what is called with the flag
<rick_h_> which is just _sidebar right?
<hatch> I can run you through the execution order if you like
<rick_h_> oh, no wonder kadams54 was confused.
<hatch> the -only- route which gets hit when it's under the il flag is the { path: '*', callbacks: 'routeDefault'},
<rick_h_> that was not clear
<rick_h_> kadams54: man I lead you so wrong. I'm sorry
<rick_h_> ok, will have to pull the code down and debugger through after the boy goes to bed. 
<hatch> rick_h_ when You have a moment I can give you the tour through the execution order
<hatch> I gave it to kadams54 but it's a lot to digest in one sitting :)
<rick_h_> hatch: I'll walk it. So that calls sidebar, but the thing is that what is this.state at that point? Does it have the query in it? It's not loaded in routeDefault until after sidebar() is callled
<rick_h_> it might be as simple as moving the loadRequest to before sidebar, but there's a race because it's doing one call
<hatch> so sidebar's job is just to render the 'dumb' container then the loadRequest is what parses the url and dispatches stuff to render into the sidebar view
<hatch> to fix the search results....
<hatch> sec
<rick_h_> right, but sidebar() does a bunch of stuff
<kadams54> Back, though only temporarilyâ¦ getting the kiddos settled into bed and then I'll have more time.
<hatch> yeah only when it's not under il, under il, sidebar() is never called
<hatch> the issue is likely with the filter
<rick_h_> kadams54: understood, it's past EOD so we can punt until tomorrow. Just trying to understand better and apologize early/often for leading you wrong
<kadams54> Yeah, it's not as simple as switching loadRequest and sidebarâ¦ I tried that already :-)
<rick_h_> right, the search widget expects that filter object I think. 
<kadams54> I've been down about 5 rabbit holes so far with this bug
<hatch> basically rick_h_ when it's not under il, it should be running the same path as it did before
<rick_h_> I think we need jcsackett's branch + a tweak to make this work
<rick_h_> hatch: right, but the il flag at the start of sidebar doesn't put the rest of the work in an 'else' 
<rick_h_> hatch: so it's still run
<rick_h_> kadams54: :(
<hatch> oh right right, so my guess is that the filter parsing got busted somehow....
<hatch> although won't all of this be moot come Fridayish?
<kadams54> I'm not sure anything's busted
<huwshimi> rick_h_: There is code that minimises the sidebar so that other things can use the space on the screen. Should I stop that happening as well?
<kadams54> We just need to settle on *one* spot for storing filter/querystring info
<kadams54> Right now it's in state.sectionA.metadata.search and state.filter
<rick_h_> huwshimi: oh crap! that's the missing bit 
<rick_h_> huwshimi: we haven't updated the inspector charm details/unit details to pop out right yet
<hatch> oops, I forgot about that too
<rick_h_> huwshimi: yes, that should stop and go away though
 * hatch blames rick_h_ 
<hatch> lol
 * rick_h_ checks schedule for code-time available tomorrow
<kadams54> Right now state.filter is fed into the pipeline that eventually renders the sidebar
<kadams54> See line 133 in browser.js
<kadams54> So that's the first problemâ¦
<huwshimi> rick_h_: So should I remove it in my branch and someone will fix up the details panels?
<rick_h_> huwshimi: yes
<kadams54> The second problem is straightening out sidebar() and loadRequest()
<huwshimi> rick_h_: Thanks :)
<kadams54> Seems like we ought to be able to render the sidebar, then call loadRequest
<kadams54> And calling loadRequest should populate the empty search input with the search string
<hatch> nonono, the problem is that the filter class was ignored
<kadams54> Which would resolve the current race condition
<hatch> the filter class needs to be updated with the information from state
<hatch> so that when it's passed in all of the rquired data is available
<rick_h_> kadams54: let's catch up in the morning on it. Go tuck in the kids
<kadams54> OK :-)
<rick_h_> it's past EOD everyone needs some wine time :)
<kadams54> But I can definitively say hatch is incorrect ;-)
<kadams54> hatch: In my branch filter is updated with info from state
<kadams54> But it still doesn't work
<kadams54> Because state doesn't exist when sidebar() is called
<hatch> that's fine
<hatch> it doesn't need to be
<kadams54> And there's nothing in loadRequest to trigger a re-render of the sidebar if the querystring is present
<hatch> the search view needs to be updated with the _charmbrowser dispatcher
<hatch> right now the search view was always re-rendered
<hatch> but the new implementation just hides it
<hatch> I'm not available tomorrow but If you'd like we can chat about it tonight
#juju-gui 2014-04-23
<hatch> I'd just hate for you to go down the wrong hole 
<rick_h_> got it :) now to make it all actually work out
<hatch> nice
<hatch> got a diff?
<hatch> oh, on gh
<hatch> :)
<rick_h_> https://github.com/juju/juju-gui/pull/254/files
<rick_h_> yea
<rick_h_> working through it, I know I just blew up a TON of tests
<rick_h_> so let that roll and generate a big giant number for mw
<rick_h_> for me that is
<rick_h_>   â 27 of 1694 tests failed:
<rick_h_> not bad actually
<hatch> ahh you moved the search view out of the sidebar
<hatch> nice
<hatch> good move
<rick_h_> right, we're working around the sidebar having the single search UI stuff
<rick_h_> so this kicks the workaround and just makes it work *right*
<hatch> yup good call
<rick_h_> then the card fix is the one line   â 27 of 1694 tests failed:
<rick_h_>         viewCfg.filters.text = metadata.search;
<rick_h_> that line ^
<rick_h_> is the actual card issue
<hatch> yep
<hatch> much nicer without all of the workarounds to keep it in the sidebar
<rick_h_> right
<rick_h_> and seems to work ok here in a quick dev/test run of it
<rick_h_> makes the home button work out fine, etc
<hatch> sidebar is doing less and less :) pretty soon it'll just be a div haha
<rick_h_> hey, I always said it should be
<rick_h_> just a single container to style and clear/etc
<rick_h_> anyway, now on to problem two for the night
<hatch> good so looks like you fixed that the proper way so I'm happy
<rick_h_> I try to do things right :)
<hatch> lol, I mean, instead of introducing another workaround
<hatch> so does the state workflow make sense now? 
<rick_h_> yea, little bit. The "it ONLY goes through routeDefault" was really easy to miss
<rick_h_> it'll need some comments and some others to grok it and it'll be cool
<rick_h_> we had talked about it in principle, but I'd missed the actually talking to code
<rick_h_> and it calling the same sidebar() threw me as it does a ton of work that clearly wasn't meant to be done in the routeDefault
<hatch> ahh yes yes, there is going to be so much code that will be removed
<hatch> I'm sure it'll be sad to see all that code you wrote go away :)
<rick_h_> not at all
<rick_h_> this is stuff I always knew/hoped would get cleaned up
<rick_h_> it's not like fullscreen where I STILL think it's the only decent way to search charms/bundles
<rick_h_> oh bah bah bah, stupid breakout panels
<hatch> lol - yeah they will add it back in
<hatch> I know it
<rick_h_> no, it's going into the new project so not our problem
<hatch> ohh gotcha
<rick_h_> but it will be a fullscreen experience, so at least I can feel like I was right
<hatch> sounds good
<hatch> haha
<rick_h_> :P
<hatch> well I'm going to pop off, see some of you in DEN, the others in LAS 
<hatch> have a good night
<rick_h_> have a good night and safe travels
<hatch> thanks you too
<huwshimi> hatch: See you in a few days!
<rick_h_> huwshimi: make sure to block out thurs during sprints for hte team dinner
<huwshimi> rick_h_: Sure thing.
 * frankban lunches
<jcsackett> rick_h_: my parents dropped in to stay with us last night. i can come to the call at 9 but i may have to hop off in the middle for a few moments to see them off.
<rick_h_> jcsackett: all good thanks for the heads up
<rick_h_> jcsackett: I can run through it early/later if it works better
<rick_h_> just wanted to get the word out
<jcsackett> how long a call do you figure?
<rick_h_> 20min?
<jcsackett> you want to push it to 9:30? they claim they'll be gone then, so no interruptions. :p
<rick_h_> jcsackett: ok, will see if kadams can
<jcsackett> ok
<bac> rick_h_: update on charmworld deploy.  it has been bumpy due to obsolete bundles on production that never got updated.  data on the new staging was fresh as it came from ingest with current proof rules.  some bundles on production do not pass proof rules so it took a few iterations to get the migration right.
<bac> rick_h_: thedac worked out the procedure to copy the prod database to staging and the latest code drop did the exodus cleanly.  so now we just have to apply it to production.  waiting on him to handle it so i don't have to bring the vanguard up to speed.  he's vancouver-based so it'll be a few hours.
<rick_h_> bac: since bundles are one revision and reimportable can we blow them away and then migrate?
<rick_h_> bac: do we have the code in place to convert the strings on reingest?
<bac> rick_h_: as i said, the exodus works cleanly now on a copy of the production db.  so it should apply to production ok.  i'd rather let it run when thedac gets in.
<rick_h_> bac: sorry, read that as it applies on a clean db
<bac> rick_h_: yes, ingest does the convert
<rick_h_> bac: ok cool
<rick_h_> bac: thanks for the heads up. Let me know what we need in case you need to head out before things complete
<bac> ok.  RT 69701 (noted in card) has the details
<hatch> morning all
<bac> ugh.  just realized i have to pack for cold/rainy and hot/dry.
<bac> hi hatch
<hatch> bac cold/rainy? Where are you going?
<rick_h_> bac: heh, I hate that. 
<rick_h_> packing for montreal sucked, but looking forward to just vegas
<hatch> flight delayed 3h, sitting at airport....awww yeah
<rick_h_> lol
 * hatch puts on sunglasses like CSI
<hatch> free wifi at the airport though
<hatch> slow....so hotspotting instead
<jcsackett> hotspots always seem better than airport wifi.
<hatch> LTE hotspot will definitely be better than airport wifi lol
<hatch> and I don't have to worry about anyone wiresharking me
<hatch> haha
<jcsackett> rick_h_: i'm guessing 9 is still go time, which works for me.
<rick_h_> jcsackett: ok
<rick_h_> jcsackett: yea, not seen kadams yet this morning
<jcsackett> rick_h_: yeah. i'm guessing his hours start at 9 like mine, but he has less of an email addiction. :P
<rick_h_> heh, he accepted late last night :P
<hatch> and kids
<hatch> :)
<jcsackett> i take it all back. we'll just blame the kids.
<jcsackett> :p
<rick_h_> +1
<hatch> our new airport has plugins at each seat.....everyone here is on a laptop
<jcsackett> rick_h_: i think, given you assigned me to a card i thought i was already assigned to, that i wasn't connected to the internet when i was manipulating kanban yesterday evening. and now i find that to move my card goes over lane limits. should i do so? don't think we have time for me to do slack while waiting.
<rick_h_> jcsackett: over limit is ok. we'll clear it out today and priority is prepping for release
<rick_h_> jcsackett: if you were really motivated you could review/land huw's branch to make room
<rick_h_> but I can try to look at that after our call 
<jcsackett> if you don't have time for that i can certainly review it, but also post call for me.
<rick_h_> but Makyo's card should be landing, it was in review and commented on yesterday
<hatch> rick_h_ http://www.engadget.com/2014/04/22/air-berlin-pebble/?ncid=rss_truncated :-)
<rick_h_> hatch: nice
<hatch> thought you'd like that....being a pebble user and all
<rick_h_> the ios part sucks but oh well :P
<hatch> haha yeah
<rick_h_> hatch: heh you wanted deleting https://github.com/juju/juju-gui/pull/255/files
<hatch> noice!! almost 1k lines
<hatch> where we're going, we don't need code!
<rick_h_> jcsackett: if you're available let's do this sans kadams then. Not sure where he is
<jcsackett> rick_h_: there he is, and i'm in the hangout.
<rick_h_> jcsackett: in https://plus.google.com/hangouts/_/canonical.com/go-over-search?authuser=1
<jcsackett> rick_h_: it was attached to the appt, i'm already there.
<rick_h_> jcsackett: try again, that's the one attached to the calendar 
<rick_h_> kadams54: and I are there
<jcastro> hey guys, did the gui stop showing icons for local deployments recently?
<jcastro> I moved a demo over to a new box and no icons
<rick_h_> jcastro: no
<rick_h_> jcastro: nothing changed recently, no releases done though hoping for one tomorrow
<jcastro> rick_h_, how can I force the icons on again?
<rick_h_> jcastro: you can't at the moment
<jcastro> any idea why icons would show up on some machines but not others?
<kadams54> jcsackett, rick_h_: Google Hangouts is now crashing immediately on meâ¦ gonna restart the browser.
<jcastro> rick_h_, is there a bug for linking to the service's page from the gui?
<rick_h_> services page?
<jcastro> so like I fire up say, hadoop
<jcastro> and I want to see the hadoop page
<jcastro> I have to URL mangle/guess
<rick_h_> which hadoop page? 
<rick_h_> I need more info, we've got a lot of hadoop pages
<jcastro> I deploy hadoop in the gui
<jcastro> then I click on the box
<rick_h_> ok, yes, you deployed it
<jcastro> then I find the unit
<jcastro> click, then I find the IP
<jcastro> then I click on it
<jcastro> but like, it takes me "x.x.x.x" and not "x.x.x.x:xxx/hadoop" or whatever it is supposed to be
<rick_h_> ok, we don't know what hte url is in the charms
<rick_h_> do they expose "available urls"?
<jcastro> right, I winder if that's a good idea
<rick_h_> that's not something we can do. 
<jcastro> like, it should be right, if you're in the gui
<jcastro> you should be able to hit any page on any service
<rick_h_> ah ok, it's been talked about but we'd need the charms to expose it. I forget what it was talked about
<jcastro> rick_h_, I mean "we" as in all of juju, not just you
<jcastro> hmm, I'm going to ask
<rick_h_> ok cool
<rick_h_> yea, we can look at it
<jcastro> do any of you have time to help debug our gui?
<jcastro> we need the icons for mark's demo
<rick_h_> jcastro: ok, otp give me 2
<kadams54> Apparently the browser restart was not sufficient
<rick_h_> kadams54: all good, I think we're set
<kadams54> Great
<kadams54> I shall go forth and codeâ¦ erâ¦ testâ¦ erâ¦ fix broken testsâ¦ by coding.
<jcsackett> kadams54: only question left was do i need to sync with your other branch, or just the one rick has put up?
<rick_h_> kadams54: jcsackett let me know if you hit any issues that delay. We're squeezing in for release tomorrow
<rick_h_> jcastro: sure thihng
<kadams54> jcsackett: my other branch is crap, so I suspect not :-)
<jcsackett> kadams54: dig. :)
<rick_h_> jcastro: is the gui up where I can hit it?
<jcastro> one sec
<kadams54> Too many rabbit holes with no results
<jcastro> rick_h_, do you have access to the lab?
<rick_h_> jcastro: not that I'm aware of
<kadams54> rick_h_: hey, what would be the best way to take over your branch/PR?
<kadams54> I could use the `git qa-pr` alias to pull down a local copyâ¦
<rick_h_> kadams54: you could use the qa-pr tool to pull it down and wokr on it, rebase it, and then push to your own as git push origin xxx:xxx
<kadams54> (y)
<Makyo> jujugui did we ever figure out why mocha sometimes fails with no difference between actual and expected?
<frankban> Makyo: because useless failure output is one of the mocha design goals?
<Makyo> frankban, +1000
<bac> it is a wildly successful program, then
<Makyo> jujugui call in 10
<bac> jcsackett: here are the logs from staging.  https://pastebin.canonical.com/108999/plain/
<bac> jcsackett: the beaker exceptions in app-exception.log have been seen for a while and thought to be innocuous
<jcsackett> bac: the same errors are seen on production?
<bac> yes
<jcsackett> huh.
<jcsackett> that is a damn shame.
<jcsackett> yeah, i don't see anything in here that explains the login behavior.
<rick_h_> jcsackett: hangout time
<rick_h_> frankban: ^
<kadams54> Bah, Google Hangouts is crashing on me againâ¦
<Makyo> So.  assert.deepEqual(actual, expected) fails, but assert.equal(JSON.stringify(actual), JSON.stringify(result)) passes.  Nice.
<rick_h_> lol
<rick_h_> I'm going to print this 100 times and ship it in a box to hatch's house http://hadihariri.com/2014/04/21/build-make-no-more/ :)
<Makyo> HAhaha
<Makyo> Once per day for a year?
<rick_h_> that sounds good
<bac> rick_h_: charmworld updated and seems happy
<rick_h_> bac: woot thanks!
<rick_h_> bac: have a good trip, see you on the other side
 * bac bye
<Makyo> jujugui ready for re-review  - I've confirmed that the tests pass in IE10, but will be looking at the saucelabs video just to be sure.
<jcastro> rick_h_, icons still broken
<jcastro> and also it seems that when we deploy it forgets where the boxes are supposed to go in the bundle
<Makyo> jujugui forgot the link: https://github.com/juju/juju-gui/pull/253 (confirmed it was a timeout on saucelabs' side, too)
<rick_h_> jcastro: k, bringing up a test environment
<rick_h_> jcastro: will figure out how to build the url manually
<Makyo> Holy crap, they accepted our offer!
<frankban> guihelp: I need two reviews for https://codereview.appspot.com/90570044 (quickstart/python, high priority) with my apologies for the long diff. Anyone available? Thanks!
<rick_h_> Makyo: woot! party in vegas to celebrate!
<rick_h_> jcastro: frankban can help look into it. Can you pm him the info from juju status and the environment admin secret so he can look at how to build a url to check if the files are in juju or not?
<jcastro> sure
<Makyo> https://www.flickr.com/photos/ranna/sets/72157644219100342/ 1.09 acres, 2362 sqft., hickory floors, quartz counters, glass backsplash tile...
<rick_h_> go hickory, that's what I put in. <3 those floors
<rick_h_> frankban: so if you're helping jcastro I'm going to go back to working on the inspector release blocker stuff. Let me know if you need a hand
<frankban> rick_h_: sure thanks
<jcastro> rick_h_, all fixed, I owe frankban more beer
<jcastro> thanks!
<frankban> :-)
<rick_h_> jcastro: cool, what was it frankban ?
<frankban> outdated charm branch
<rick_h_> oh lol
<rick_h_> nice and easy then cool
<Makyo> jujugui running out to pick up hatch from the airport.  Will be back from the hotel.
<rick_h_> Makyo: rgr, give him the grand tour and maybe find him some chicken and waffles :P
<Makyo> Hahaha
<rick_h_> jujugui need a review and qa for a small branch please https://github.com/juju/juju-gui/pull/257
<rick_h_> kadams54: jcsackett either of you have a chance to review https://github.com/juju/juju-gui/pull/257 please? Tests pass now :0
<rick_h_> kadams54: jcsackett going afk. I'll be back tonight. If you need anything important ping me on hangouts
<jcsackett> rick_h_: i may have time to look at it later today.
<kadams54> rick_h_: Taking a lookâ¦
<hazmat> rick_h_, can we make gui use the same trick it does for local charms on store charms?
<hazmat> rick_h_, re icons
<hazmat> rick_h_, ie. always get charm icons from the backend on deployed charms
<hazmat> guihelp /juju-gui ^ 
<rick_h_> hazmat: https://plus.google.com/hangouts/_/72cpi460salmu56blakp9rmtes?authuser=1&hl=en
<rick_h_> hazmat: app/views/utils.js getCharmIconUrl has the if local condition you want
<hatch> hi all
<rick_h_> hey hatch 
<rick_h_> hazmat: testing it out on ec2 with https://github.com/mitechie/juju-gui/tree/always-store-icons
<hatch> hazmat are you in DEN yet?
<rick_h_> hatch: yea, he just ping'd from the hotel there. I think most folks are there based on earlier irc
<hatch> oh cool, I got the sim card updated but had to pay the $10 for hotel wifi....ugh
<hatch> charging for internet must be a North American hotel thing
<rick_h_> yea, it sucks
<rick_h_> was $25 when I was in chicago once
<hatch> holy crap! 
<hatch> I think I'll hot spot for the rest of the time 
<hatch> man npm issues galore in CI
<hatch> :/
<jcsackett> kadams54: did your branch land yet?
<kadams54> No, net yet
<kadams54> hatch: for you: https://github.com/juju/juju-gui/pull/257/files#r11924124
<kadams54> ;-)
<hatch> lol ^5
 * hatch ducks and covers
<jcsackett> jujugui: can i get a review of https://github.com/juju/juju-gui/pull/258/files
<rick_h_> kadams54: hatch what's the goal of the preventDefault vs halt?
<hatch> rick_h_ halt stops the propagation of the event whereas preventDefault only prevents the default event for that handler
<hatch> so you won't be able to listen on a container for that event and there will be no way to debug it
<kadams54> I view halt as a bit of a nuclear option
<hatch> it burnt me hard earlier in the gui and in past projects
<hatch> so I really try to avoid it
<rick_h_> hatch: ok, but it's used on a close button. It's already on a container, and it's own html/template of control. No one else should be listening to that things events. 
<rick_h_> it's like having code across the page looking in case someone does some raw JS event on some temporary node used in a widget
<rick_h_> you bind to events on the widget, not click events in the widgets html
<rick_h_> otherwise it's fragile as can be
<hatch> well say you wanted to capture all click events in a element for whatever reason
<hatch> this click event would never reach your handler if halt is used
<rick_h_> hatch: right, I'd scream to high heaven you can't do that :)
<hatch> that's how pjax works
<rick_h_> so no, I prefer my nuclear option in my widget :)
<rick_h_> ok, will look at the scope but not sure this is an 'always good' rule and that it's appropriate here
<hatch> the only reason halt is 'required' here is because of pjax, else prevent Default would work just fine
<hatch> jcsackett I can review your branch
<jcsackett> hatch: cool, thanks.
<hatch> oh crud, I can't QA
<hatch> I can't connect to my vagrant for whatever reason
<hatch> probably this network
<hatch> jcsackett done
<hatch> you just need someone to qa
<rick_h_> I can qa tonight at the coffee shop
<jcsackett> hatch: how strongly do you feel about that personal preference noted? b/c it runs entirely counter to my personal preference. :p
<jcsackett> rick_h_: thanks.
<hatch> jcsackett haha, tbh I'll be voted down on it so up to you
<hatch> I think it looks more like python style indentation
<hatch> so I figured you python guys would prefer it
<hatch> but doesn't look like it :)
<rick_h_> hatch: multiple lines is per our code convention docs
<jcsackett> on short constructs, yeah. on large blocks like that it makes it way harder to keep track of what's where, imo.
<rick_h_> hatch: with any complex objects as their own var = line
<rick_h_> hatch: we had a friday retro on this
<hatch> jcsackett but in python you don't have that problem.... :)
<rick_h_> we can revisit, but I'm with jcsackett. Seeing vars vs hiding vars. I hate we don't use the rule on out tests and don't force them to be alphabetical
<hatch> rick_h_ yeah - I'm talking about the curlies
<rick_h_> oh, that one
<hatch> I think smushing all the curlies up on the end of the last line is cleaner
<rick_h_> meh, I'm still with jcsackett. Lines up and easy to see. 
<rick_h_> the fact that you call it "smushing" is hurting your case :P
<hatch> lol!
<rick_h_> I don't ever think "boy that's some great smuching code. Much more readable smushed like that"
<rick_h_> smushing
<hatch> I really wish github had syntax highlighting in diffs
<jcsackett> does anyone have that?
<hatch> jcsackett I dont' think so, I think they all just colour the diffs
<jcsackett> yeah.
<jcsackett> hm. i find myself missing `bzr shelve`.
<hatch> git stash :)
<hatch> and it's cousin, git pop
<hatch> hmm I really have no idea how to debug/fix this network issue....
<hatch> guess I won't be fixing it today :)
<jcsackett> git stash doesn't do quite the same thing.
<hatch> oh? 
<hatch> I thought they were almost identical
<hatch> what is the difference?
<jcsackett> if i have several chunks of changes in one file, bzr shelve lets me shelve them selectively.
<jcsackett> stash is just "what's the WIP? let's stash it" -- or at least appears to be that.
<hatch> ahh yeah, I didn't know bzr shelve did that. How does it determine where the chunks are?
<rick_h_> bzr diff, grab each chunk
<hatch> ok so basically wherever there is a line which isn't changed is a divider 
<hatch> I could see that being useful
<hatch> there has to be a way to do that with git
<hatch> ....you can do everything with git somehow :)
<hatch> so you can git stash only a single file if you have edited multiple
<hatch> but I can't find any way to stash parts of a diff
<hatch> oh wait
<hatch> `git stash --patch --no-keep-index`
<hatch> ^ jcsackett  you can try that
<jcsackett> hatch: alright, i'll give that a go.
<hatch> you might need to use `save --patch` 
<hatch> but maybe not
<hatch> https://www.kernel.org/pub/software/scm/git/docs/git-stash.html grep for --patch for more info
<hatch> I knew there had to be a way haha
<hatch> apparently `git stash -p` works exactly like what you're asking....but I can't find any docs to back that up
<Makyo> jujugui quick code review for demo-able deployer button - https://github.com/juju/juju-gui/pull/259
<Makyo> jujugui also, confirmed the CI failure was an unrelated timeout on https://github.com/juju/juju-gui/pull/253
<hatch> Makyo review done - I can't QA unfortunately
<hatch> ahah fixed the network issue
<hatch> Makyo I can QA now
<rick_h_> anyone recall the guiserver url?
<rick_h_> guihelp ^
<hatch> hmmm
<hatch> mind.....is......blank
<hatch> rick_h_ like you want to access the guiserver not the gui?
<rick_h_> hatch: nvm, I think I'm close now
<hatch> ok cool
<rick_h_> hazmat: I don't think it'll work. I don't know the core internals to tell but trying to force the icons to the store is easy, but the data isn't there in the api
<hatch> hazmat Makyo I'm going to start walking to the meetup at about 4:30
<Makyo> Sounds good.
<rick_h_> hazmat: pita, but think https://docs.google.com/a/canonical.com/document/d/1Y8Uhomr4_6L3nFXLXPZY2V-tFjl5KjOIknQLuXdzU_A/edit might be the best bet for the demo so that you can ingest the charms in that local store and provide the icons
<rick_h_> hazmat: unless there's something in the core api for the files that will allow this to work for non-local charms
<rick_h_> hazmat: https://ec2-54-87-142-1.compute-1.amazonaws.com/juju-core/charms?url=cs:precise/juju-gui-90&file= is the url for getting a list of the files
<hatch> fixed the network issue now only to have other stuff break....bleh
<rick_h_> hazmat: obviously change to your url/etc
<rick_h_> Makyo: jcsackett so both of you need qa?
<hatch> looks like it
<Makyo> Yes please.
<hatch> I'll try and get mine up and running when we get back
<hatch> Makyo meet you in the lobby?
<Makyo> Yep, down in a few.
<hatch> ok cya all
<Makyo> Ducking out too.  Will catch up later, possibly while there.
<mbruzek> Hi rick_h_ Can I have a minute of your time?
<huwshimi> Morning
<mbruzek> I am doing a charm review, and Jose added defaults to the config.yaml for juju-gui.  https://code.launchpad.net/~jose/charms/precise/juju-gui/add-blank-defaults/+merge/212885
<mbruzek> Normally this is not a problem, but I have encountered charm authors who counted on some parameters to be "unset" and I was wondering if anyone in the juju-gui would like to weigh in on this?
<mbruzek> Specifically the config options that he now defaults to "" are:  ssl-cert-contents, ssl-key-contents, login-help.  Does anyone know if the juju-gui depends on those 3 being unset rather than empty string?
<mbruzek> also password 
<rick_h_> mbruzek: sure thing
<rick_h_> mbruzek: we've got a task to look at unset itself. The defaults should be ok as "". I don't recall if we'll send them as "" or not
<rick_h_> mbruzek: honestly, I'd try it out and see. I think the unset we need to do is to reset a config where they expect it to be unset
<rick_h_> if he's defaulting to "" then he's expecting that?
#juju-gui 2014-04-24
<huwshimi> rick_h_: Any specific cards you'd like me to take a look at today?
<rick_h_> huwshimi: the big thing I'm going to try to QA and land the stuff from jcsackett and Makyo
<rick_h_> huwshimi: and so the big thing is QA of the changes
<huwshimi> rick_h_: OK, I can do some QA.
<rick_h_> if you want to help QA those that's cool and once I can get them in we want to QA and see if we're good for release tomorrow
<mbruzek> rick_h_, Thanks for responding.  I have deployed the charm with the "" values in there, it starts up on its own.  There is not a way to unset a variable (that I know of at least).
<mbruzek> rick_h_, There was no other code changes other than config.yaml, so I am looking through the code to see if the config-changed hook uses None or empty string on any of those variables.
<rick_h_> mbruzek: ok
<mbruzek> rick_h_, So far I see a comment on the password configuration option # Normalize empty string passwords to None.
<mbruzek> So setting password to "" looks safe, the other ones seem to be related to ssh keys which are harder to track down but I am on it.
<mbruzek> Do you know of a way to unset a value?
<rick_h_> mbruzek: https://juju.ubuntu.com/docs/commands.html
<rick_h_> there's unset in there
<rick_h_> mbruzek: but we don't support that in the gui
<mbruzek> unset: set service config options back to their default
<rick_h_> mbruzek: right
<mbruzek> OK let me rephrase that, I don't know of a way to set a config value to None.
<rick_h_> mbruzek: oh ok
<rick_h_> right
<mbruzek> I will get to the bottom of this.  I was just looking for any red flags from the GUI team if they KNOW this is an unsafe option.
<mbruzek> When I was still green I reviewed the rabbitmq-server charm and it has some values that did not have defaults, so I defaulted them to "" and James Page noticed that was wrong because the code handles None differently than "" so I actually had to change them back.
<rick_h_> mbruzek: yea, there was a giant thread about it before
<mbruzek> That is what I am trying to avoid here... I will review this as normal 
<huwshimi> rick_h_: With the mv flag I am unable to deploy a charm. Are you able to?
<huwshimi> hmm... doesn't work on comingsoon for me either.
<rick_h_> huwshimi: you need Makyo's branch that hooks up the button
<rick_h_> huwshimi: that uses the state control stuff and you have to enter a magic command into the console to 'deploy'
<huwshimi> rick_h_: I was just trying with the button in the inspector. Does that not work either?
<rick_h_> huwshimi: right, so that just 'queues' up the deploy
<huwshimi> ah right
<rick_h_> huwshimi: that's the work that the deployer bar is doing
<rick_h_> huwshimi: so it's in a middle state right now
<huwshimi> rick_h_: I see. That branch is landing now I see.
<rick_h_> huwshimi: yea, hoping to get that going so we can demo the working flow of inpsector on the left, going through deployer bar, and then into machine view
<huwshimi> Nice
<rick_h_> it's not complete, but we can demo that we've got all the ideas in place and we just need more time to finish stringing the wires to everything
<rick_h_> huwshimi: can you qa this one from me as well please? https://github.com/juju/juju-gui/pull/261
<huwshimi> Sure
<rick_h_> thanks
<rick_h_> heh, lovely WebDriverException: Message: None ; Stacktrace: 
<rick_h_> yay for no messages
<rick_h_> huwshimi: any luck qa'ing https://github.com/juju/juju-gui/pull/261 ?
<huwshimi> rick_h_: Just started :)
<huwshimi> (was having lunch)
<rick_h_> ah gotcha thanks
<huwshimi> rick_h_: This branch is just repositioning the inspector panel, not reusing the existing browser details panel?
<rick_h_> huwshimi: it's using the same container space
<huwshimi> rick_h_: Ah, ok.
<rick_h_> huwshimi: so the inspector popout panels are going into the same container the charm details uses
<rick_h_> the bws-view-data or whatever
<huwshimi> rick_h_: Great!
<huwshimi> rick_h_: The animations seem to have broken
<rick_h_> huwshimi: on which ones? 
<huwshimi> rick_h_: The details panel sliding in for the browser or the inspector
<rick_h_> the inspector ones don't animate 
<rick_h_> I'll look if I broke the details one as well
<huwshimi> rick_h_: Well, they should if they re-use the same node though right?
<rick_h_> it might be a follow up to make the details from the inspector animate like the service ones. 
<rick_h_> they need more work
<rick_h_> well, they use the same container, but don't use the same code path yet
<rick_h_> I've kind of hacked them in for now with a follow up card to make them true views vs just viewlets 
<rick_h_> the css chain is probably a bit different. It might be an easy fix, not sure
<rick_h_> ok, so the charm details animations work ok
<huwshimi> rick_h_: That's strange, I don't see them.
<rick_h_> oh, no they don't with the feature flag in please
<rick_h_> place
<rick_h_> bah
<rick_h_> that's broken on trunk as well http://comingsoon.jujucharms.com/:flags:/il/
<rick_h_> so this branch did not break it, it's the new navigation stuff
<huwshimi> oh I see
<huwshimi> rick_h_: There are lots of places that if a url doesn't exist then the gui breaks instead of handling them (e.g. http://localhost:8888/inspector/service_29/:flags:/il/)
<huwshimi> (I know that's unrelated)
<huwshimi> (To this branch)
<rick_h_> huwshimi: yes, that's due to the inspector stuff. I'm trying to think about it. In a live environment we want those to work. 
<rick_h_> for the demo environment we want to just skip them I think
<rick_h_> but we'll have to tackle that and figure out a good path. The idea is that you'll be able to link me to the inspector of a service in our shared live environment
<huwshimi> rick_h_: I found another bug, but it happens on comingsoon as well. With the 'il' flag, if you click a charm in the sidebar and it opens the details panel and then you click 'deploy' the console shows an error: Cannot read property 'setStyle' of null
<rick_h_> looking
<rick_h_> huwshimi: ok, something in the sticky heading stuff blowing up there
<rick_h_> huwshimi: will add a card
<huwshimi> rick_h_: It's a really strange place to have an error. Doesn't seem related.
<rick_h_> huwshimi: yea, I think there's some scroll event between the view getting killed for the inspector 
<rick_h_> and when the charm search/etc goes away
<huwshimi> Ah you could be
<huwshimi> *yeah
<rick_h_> and when the scroll event tries to figure out the size/etc the nodes are gone
<rick_h_> and it bombs
<huwshimi> yeah that makes sense
<rick_h_> yea, that event isn't setup using addEvent() 
<rick_h_> so it's not destroyed with the view
<rick_h_> https://github.com/juju/juju-gui/blob/develop/app/subapps/browser/views/charmresults.js#L154
<rick_h_> so changing it to use the event tracker/addEvent should fix it hopefuly
<rick_h_> oh hmm, it's in the destructor though
<huwshimi> rick_h_: I've finished the QA. Anything else you'd particularly like me to take a look at?
<rick_h_> huwshimi: if you want to look at that error that'd be cool
<huwshimi> rick_h_: Sure.
<rick_h_> huwshimi: one other thing in qa'ing stuff here myself. The scrollbar fix actually messed up the inspector view a little bit in the :flags:/il
<rick_h_> huwshimi: since it has a scrolling body it has a scroll bar in a diff location
<huwshimi> oh
<rick_h_> huwshimi: so that scrollbar showing fix is only when it's a charm result (editorial or search)
<rick_h_> huwshimi: I missed that in qa originally, my bad
<rick_h_> anyway, doesn't look like we'll be able to release tomorrow. Thanks for the qa in helping to point out issues out there. 
<rick_h_> huwshimi: have a good day
<huwshimi> rick_h_: OK no problems. Night!
<rick_h_> huwshimi: can you put yourself on the card for today please?
<huwshimi> rick_h_: Done.
<rick_h_> ty much. You leave tomorrow? 
<huwshimi> rick_h_: I leave on Sunday, and then get to the US on Sunday :)
<rick_h_> lol oh ok hten
<huwshimi> Tomorrow is a public holiday here.
<rick_h_> ah ok
<rick_h_> well if I don't run into you before vegas safe travels. Looking forward to getting together
<huwshimi> rick_h_: Thanks, will be good to see you too. Have a good trip down.
<rick_h_> frankban: was the git checkout stuff broken in the precise version of the charm?
<frankban> rick_h_: trying the same on precise charm
<rick_h_> frankban: also, the little guy wants to sleep in today. Is it ok to push back out 1-1 a little bit this morning?
<rick_h_> frankban: I'm working on replicating it here. I hit it trying to put together a demo branch for kapil yesterday. 
<rick_h_> deploying to ec2, and I have precise as the default series in my ec2 env
<frankban> rick_h_: ok
<frankban> rick_h_: I need to go out for lunch in 24 mins, other than that I am available nay time
<frankban> any even
<rick_h_> frankban: ok cool. Let's try after lunch then. bac is out so I don't have anything else until our stand up
<rick_h_> and I'll see about duping this. I need to update my envs and switch my default series. bye bye precise! :)
<frankban> :-)
<frankban> rick_h_: also trying with a local env: juju bootstrap --upload-tools --series precise shoudl work around the bug
<rick_h_> frankban: cool, yea I hit this because i wanted a real env so wondering if there's something in the version of git I hit. It had a strange error trying to do the clone of the new repo from git. 
<rick_h_> frankban: verified the trusty charm does not fail on this issue. So another case of just use the latest charm silly
<rick_h_> frankban: my hard coded default-series in the environments.yaml bit me
<frankban> rick_h_: but it should work with the precise charm too, we test both scenarios on ec2
<frankban> rick_h_: have to go, will ping you later
<rick_h_> frankban: have fun, thanks for checking up on it
<rick_h_> frankban: I'm back from taking the boy to day care. Let me know when you're back from lunch and we can do our call
<frankban> rick_h_: I am back, joining the call
 * rick_h_ goes to make coffee and breakfast
<jcsackett> Morning, all. 
<rick_h_> party
<mbruzek> Good morning
<rick_h_> mbruzek: hey, I saw the emails about the charm stuff from jose. I missed you were talking about our charm lol
<mbruzek> frankban, Thanks for commenting on the juju-gui merge proposal.  I have a follow up question. If this next review passes should I not merge it with the charm in precise/juju-gui ?
<rick_h_> mbruzek: no, we run our own promulgated charm. 
<mbruzek> Sorry I didn't make that more clear rick_h_ 
<rick_h_> mbruzek: it's not a ~charmers root charm and all changes should go through the team
<rick_h_> mbruzek: it's the one charm you guys shouldn't have to worry about :)
<mbruzek> rick_h_, so what should I do with Jose's MP?
<rick_h_> http://bazaar.launchpad.net/~juju-gui-charmers/charms/precise/juju-gui/trunk/files
<rick_h_> mbruzek: so I think he replied to frankban that he'd update in the right place
<frankban> mbruzek: as I mentioned to him, he should repropose the branch against our development branch: lp:~juju-gui/charms/trusty/juju-gui/trunk
<mbruzek> The way I read it, he would do that "later"
<frankban> mbruzek: yeah, so I think we can safely close this MP
<mbruzek> OK I will do that then.
<frankban> mbruzek: thanks
<frankban> rick_h_: what do you think about removing lp:~juju-gui/charms/precise/juju-gui/trunk and lp:~charmers/charms/precise/juju-gui/trunk? those branch will be no longer updated and can generate confusion
<rick_h_> frankban: sounds good to me. 
<frankban> rick_h_: no luck: This branch cannot be deleted as it has 22 branches sharing revisions.
<hazmat> rick_h_, i don't see any 'local' charm specificity in the apis on the state server for charm file retrival
<rick_h_> frankban: maybe pushed a MOVED file like we did with the gui when we moved to github?
<mbruzek> frankban, What is the preferred fix here?  Leave login-help without a default?  If we do that then that allows users to set login-help to "" when they don't want anything displayed there.  Or change the if statement to generate the default text when login_help is None or empty string?
<rick_h_> hazmat: hmm, talked with frankban about that this morning and we've added a card to make it non-local charm specific in the core api
<mbruzek> frankban utils.py line 366
<rick_h_> hazmat: I'll look for his patch there. The gui branch tries to load the files from juju but it responded that the charm couldn't be found so all the icons were just broken. So something is in there. 
<hazmat> rick_h_, k, i'll try exploring with it a bit more.. i was just reviewing apiserver/charms.go
<frankban> mbruzek: I don't have a strong opinion, and I don't know the story behind the decision to make proof warn when there is no default. A None default makes sense for the login-help, as you mentioned. On the other side I don't see so much value in having an empty login help. So I guess implementer choice?
<mbruzek> frankban, I am OK with that one option exist without default.  I just wanted to see if that was OK with the gui team
<rick_h_> hazmat: looking https://code.launchpad.net/~frankban/juju-core/get-charm-api/+merge/207994
<frankban> mbruzek: +1 from me, let's leave login-help as is
<rick_h_> hazmat: maybe only local charms are in the storage location we're looking in? Does juju store those in a different path or naming convention? I also don't see anything 'local' specific/filtering there. 
<hazmat> rick_h_, different naming convention
<hazmat> in provider storage for store charms
<rick_h_> hazmat: ok, so that might be the issue. we're using the url local:precise/charm and if it's not cs:precise/charm then we'll have to tweak that to find it in juju land
<hazmat> rick_h_, found the issue
<hazmat> rick_h_, that code should be using the state api to get its download url of a charm
<hazmat> rick_h_, at the moment its just using its own notion of the storage name/key 
<rick_h_> hazmat: k, can you file a bug to that effect and assign it to yellow squad and I'll update our card on the board with a link to that
<jcsackett> rick_h_: i'm thinking of taking on the new state inspector issues for local charms on project a--there an easier way to look into that than bootstrapping an environment with local charms?
<rick_h_> jcsackett: yes, the code should work for sandbox as well. So the issue is pre environment work
<rick_h_> jcsackett: let me know if you want to walk through any of the cards. 
<jcsackett> rick_h_: how does one setup a local charm in sandbox mode?
<jcsackett> rick_h_: i'm happy to chat via hangout if you prefer.
<frankban> hazmat: interesting, re state api, where are you looking at?
<frankban> jcsackett: you can just drag and drop a zipped charm to the canvas
<jcsackett> frankban: oh, nice. i didn't know that.
<rick_h_> jcsackett: yea, we use hatch's ghost charm to test :)
<rick_h_> jcsackett: so you download the zip from github (download zip button) and drag it onto the environment and it should popup an inspector asking you to choose a series and upload it
<hazmat> frankban,  state/charm.go  -> BundleURL()
<hazmat> frankban, name := charm.Quote(curl) ; storage.get(name) only works with local charms.. it should really be using the charm state api to retrieve the url and just download it direct from that instead of using storage apis at all.
<jcsackett> rick_h_: ah, i see, and that upload inspector is not loading. ok, easy enough to reproduce.
<rick_h_> jcsackett: right, I've not looked to know what the root issue is. It's definitely due to the state stuff so need to see how it used to work and port it over to the new world order
<rick_h_> jcsackett: which may be easy/pita depending on how it works currently
<rick_h_> jcsackett: but let me know if you hit any questions
<jcsackett> rick_h_: well, i've looked into a bunch of the new state handling stuff, so i'm in the right headspace. i'll ping you as i hit stumbling blocks.
<frankban> hazmat: so charm, err := state.Charm(curl) and the using an http client to retrieve charm.BundleURL()?
<hazmat> frankban, yes.. or juju-core/downloader
<frankban> cool
<rick_h_> jujugui going to push back the standup 30min if that's ok. Want to check in on the #is call at the top of the hour
<jcsackett> fine by me.
<kadams54>  Ditto
<frankban> np
<rick_h_> ty 
<rick_h_> frankban: you need reviews right? I'll do one after the calls. We need a second?
<frankban> rick_h_ thanks, jujugui: yes I need a second one
<jcsackett> frankban: i can be the other. link?
<frankban> jcsackett: https://codereview.appspot.com/90570044
<jcsackett> frankban: cool, looking.
<frankban> thanks
<kadams54> guihelp Currently getting this error when running tests in browser: "No juju config to fetch charmworld store url"
<kadams54> I suspect it's due to networking issues (not on my usual network) and vagrant. Was wondering if anyone had ever seen it before.
<rick_h_> kadams54: that's failing something? It shoulnd't be an issue. 
<kadams54> The test runner aborts when it hits that.
<rick_h_> I think it's just dumped as a warning/message
<kadams54> OK, well then it dumps and then the test runner just stops running
<kadams54> Oh wait
<kadams54> Hah
<rick_h_> yea, that's just a warning error and is normal/fine
<kadams54> Apparently the test runner did not stop running
<kadams54> It just took minutes for a test to run
<rick_h_> gotcha
<rick_h_> cool
<kadams54> I'd always hit reload or whatnot after 30 seconds of nothing going on
<kadams54> But since I'm complaining about it in IRC, it had enough unmolested time to get through the hangup and move onâ¦
<rick_h_> lol yay irc
<kadams54> I think there may be some sort of leak in our tests (or maybe mocha)â¦ I've noticed that when I re-run the suite multiple times in a particular tab, it gets slower and slower. Opening up a new tab seems to fix the problem.
<kadams54> Error: timeout of 100000ms exceeded
<rick_h_> kadams54: ok, so taht's an async test that did not complete 
<rick_h_> kadams54: look for a missing done() in the async bit
<rick_h_> kadams54: or check that the async/etc got hit/fired
<rick_h_> kadams54: push/paste the test if you need another set of eyeballs
<jcsackett> kadams54: i've experienced a similar issue (leak-like slowdown) when running tests in the browser; when running them via test-{debug,prod} everything's a lot speedier.
<kadams54> Yeah, everything is speedier, but there's some issue with phantomjs and vagrant where they bomb out.
<kadams54> :-(
<jcsackett> just use an LXC instead of vagrant. :p
<rick_h_> jcsackett: those osx users don't have lxc
<rick_h_> jcsackett: though that's an interesting question of does the issue exist when lxc in a vm is used as the environment
<jcsackett> rick_h_: lxc...in a vm...on your main laptop. that may be too many turtles.
<rick_h_> moar turtles!
<kadams54> jcsackett: http://the.taoofmac.com/space/HOWTO/Vagrant
<kadams54> I'd actually like to get this up and running :-)
<jcsackett> wow.
<kadams54> rick_h_: https://gist.github.com/kadams54/a3268988a82c8e9e089c
<kadams54> I suspect the problem is in line 40
<kadams54> But with that said, I'm wondering if any of the tested stuff in here is relevant anymore
<rick_h_> kadams54: hmm so setting withHome on the view needs to trigger something that hits the showHome method
<rick_h_> I'm not sure that's automatic. I can look after this call to look at that
<kadams54> Since sidebar is now a much more dumb container and the home stuff has moved
<rick_h_> kadams54: right, so this is an example of a test that does't matter to sidebar, but does to search.js and editorial.js now
<kadams54> Yeah, I'd been trying to move over just some of the assertions, but on review, the entire test needs moving.
<rick_h_> kadams54: rgr sounds good
<rick_h_> kadams54: right so that test it checking https://github.com/juju/juju-gui/blob/develop/app/subapps/browser/views/view.js#L91 is bound correctly
<rick_h_> kadams54: so this is part of the MainView that is injested into search.js and editorial.js via the charmresults.js
<jcsackett> frankban: am i just seeing what i want to see, or is the 'bad wolf' stuff in quickstart a dr. who reference?
<frankban> jcsackett: it is
<jcsackett> \o/
<frankban> :-)
<frankban> jcsackett: so you understand it's a really bad error message
<jcsackett> indeed, end of the world type stuff. :p
<jcsackett> frankban: lgtm on your code with one comment, i'm starting qa now but probably won't finish until after the standup.
<frankban> jcsackett: cool thanks
<rick_h_> jujugui call in 5
<rick_h_> jujugui call in 2 ... 1 ... where's makyo to do this for me :P
<jcsackett> rick_h_: be there momentarily, fighting with G+.
<rick_h_> kadams54: ^
<kadams54> Yeah, sorry, I spaced the 11:30 time and left to run an errand
<rick_h_> kadams54: ok, let us know if there's anything we can do to help with your branch. 
<kadams54> Will do
<rick_h_> kadams54: only news is no release today obviously, qa last night brought out a few more cards of work 
<kadams54> ok
<kadams54> jujugui: the main thing I had for standup is that there's a family emergency I need to take care of before Vegas, so I may be in and out more on Friday.
<rick_h_> kadams54: ok
<kadams54> Nothing too big, just needed to setup some appointments
<jcsackett> frankban: i'm having issues qaing b/c my network is playing poorly with repositories and the juju pkgs ppa won't install/update. i'll try again later today from another network. it's not your branch tho.
<jcsackett> or rick_h_, if you can handle qa ^
<rick_h_> jcsackett: k, can look at that after review
<hatch> so I've found out that sublime text is a huge power hog
<hatch> it could be some of the plugins but it big time drags the battery down
<rick_h_> hatch: welcome back to vim :P
<rick_h_> hatch: heads up, we need to noddle on viewlets in a inspector-left world. 
<hatch> haha, it seems every sprint I hop back into vim land
<rick_h_> hatch: and if viewlets and the manager make sense any more
<hatch> maybe it'll stick one of these days
<rick_h_> hatch: we've got a training crew ready to meet you in vegas
<hatch> lol
<hatch> I don't see how the inspector-left has any impact on viewlets/viewlet-manager.....it could probably be renamed though
<hatch> we still need a view manager I think
<hatch> there was a bunch of stuff added into viewlet-manager for the inspector which can probably be refactored out
<rick_h_> hatch: I'm having to work the popup viewlets out of the view manger because they're not a sub dom child element
<hatch> so sure, we can chat about it, there is definitely room for improvment
<rick_h_> hatch: so all rendering, event bubbling, etc don't work
<hatch> oh for the left (now right) breakout?
<rick_h_> hatch: right
<rick_h_> all of that breaks becaus the inspector is the root element all delegation goes from (container, etc)
<hatch> ahhh ok ok yeah that has always been tacked on - we can definitely improve that
<rick_h_> so the viewlet-manager/etc isn't helping much, I'm more having to work around the system. 
<hatch> chat in Vegas or sooner?
<rick_h_> and then we need to figure out the routing straight to a popup stuff
<hatch> right right
<rick_h_> hatch: vegas is fine, just a heads up to ponder it
<hatch> cool will do, I'll look at it
<rick_h_> hatch: I've worked around it for now, but I've got a card to think of a better long term solution and would appreciate your feedback/input
<hatch> oops heh
<rick_h_> wrong button :P
<hatch> yep haha
<hatch> yeah it definitely needs some work to do right
<rick_h_> hatch: cool, so speaking of pondering I'm going to go ponder my lunch choices. Thinking I'll leave my bat-cave today
<hatch> enjoy!
 * rick_h_ goes to find foods and biab
<rick_h_> kadams54: hangout?
<kadams54> Yup
<kadams54> Will be there shortly
 * rick_h_ heads out, have a good nigth all
<rick_h_> err night
<Makyo> jujugui having trouble getting juju to play with LXC, machine one never provisions.  I seem to remember something about clearing mongo caches; is that what I'm missing?
<rick_h_> Makyo: there's a known but where a trusty host can't bring up precise machines or something atm
<rick_h_> Makyo: make sure you've got a default series and that it's trusty for the bootstrap node I think
<Makyo> Okay, thanks
<rick_h_> Makyo: frankban was working around this bug in https://launchpad.net/bugs/1309455 today
<_mup_> Bug #1309455: The auto-generated local env does not work in trusty <juju-quickstart:In Progress> <https://launchpad.net/bugs/1309455>
<Makyo> Aha!  Thanks rick_h_ 
<jcsackett> rick_h_: i've sorted the issue--apparently my debugger wasn't working right when i thought render didn't pop up--it's just rendering beneath the charmbrowser so it's invisible (unless you zoom out via browser controls rather than app). do we want this to render where it used to, or are all inspectors supposed to be on the left?
<jcsackett> assuming all on the left, we can either set it to push the charmbrowser down so it's visible? or replace the browser a la the service inspector? the latter is, i think, considerably more work.
<rick_h_> jcsackett: all on the left
<jcsackett> right, like i assumed. so then appearance wise, should it take up all the space of the sidebar like the service inspector?
<rick_h_> jcsackett: so we should remove the browser instance, and put the inspectot in its place
<rick_h_> yep
<rick_h_> the interesting question is that it's not really a routable item...
<jcsackett> rick_h_: right.
<rick_h_> so ssoi
<rick_h_> bah
<rick_h_> lag
<rick_h_> so, we might need to do something where we hide/restore the browser stuff in there
<rick_h_> as part of working around this
<jcsackett> yeah.
<rick_h_> jcsackett: so will have to look at where it gets created and determine the best path forward on it
<jcsackett> "it" being the request-series inspector?
<rick_h_> I'm not sure off the top of my head, for the ghost inspector we do "route"
<rick_h_> jcsackett: yes
<rick_h_> jcsackett: thinking it through,the normal process is to drop the charm, select the series, and then you get a ghost inspector, which is routed
<rick_h_> jcsackett: so if we just hide the browser, then once you pick a series it needs to get destroyed, along with the browser stuff
<rick_h_> if you close out, and choose not to complete the process we need to show back the browser 
<rick_h_> jcsackett: want to point me where in the code the inspector is created and we can see if there's a sane way to hide the browser?
 * rick_h_ will brb going to start a movie for the little guy. 
<jcsackett> rick_h_: ok. 
<jcsackett> so, it's created in service.js, which sets up the drag/drop handler for zip files. it has a method which calls the create/render code for the request-series thing, so that could handle hiding the charm browser at the same time.
<rick_h_> looking, just want to make sure it's got easy enough access to the browser bits
<rick_h_> ok, so it looks like it destroys the existing service inspector with the topo.fire('destroyServiceInspector')
<rick_h_> but that may/may not be open. It really does need to set something in the state. Like component: "inspector", metadata: { services: services, file: file}
<jcsackett> rick_h_: that was my thought and my fear.
<jcsackett> :p
<rick_h_> jcsackett: call?
<jcsackett> s'why i wanted you to tell me to just make it work the way it used to.
<jcsackett> rick_h_: migrated to a coffee shop that may be less than ideal, but let's give it a go.
<rick_h_> yea, but that's no good. The topo.fire() needs to be a "destroy anything that's sticking around right now, but restore it if I close the dippy deployment inspector" which is basically what state does
<rick_h_> https://plus.google.com/hangouts/_/7ecpj54iefa352n1pbj99t88eg?hl=en
<jcsackett> rick_h_: i dropped, reconnected, and now i can't hear you.
<jcsackett> do you even see me in the call?
<rick_h_> byeok, I dropped 
<jcsackett> well, i can hear you typing.
<rick_h_> heh, ok
<rick_h_> well I'm out now. Something hung on my end as well
<jcsackett> rick_h_: ok, let me try again, calling you from the hangout app on my phone.
<jcsackett> i think the wifi at the shop may not be up to this. :p
<rick_h_> k
<jcsackett> it's calling you on G+...i can't send a url, b/c iphone.
<jcsackett> your canonical account.
<jcsackett> ...or this is just a bust. i can sprint home and we can try in a few?
<jcsackett> didn't think it would be *this* hangout hostile.
<rick_h_> jcsackett: ok, no biggie
<rick_h_> it's close to EOD and such
<rick_h_> jcsackett: we can catch up in the morning and plot a path
<jcsackett> rick_h_: fair. i'll figure this out a bit more, talk early AM tomorrow?
<jcsackett> and you just said basically the same thing. so yeah, i'll ping you tomorrow morning.
<rick_h_> jcsackett: rgr, take a peek at the state stuff. We'll need a new url test in the state code that builds an inspector component with metadata that says "this is a local charm deploy"
<rick_h_> so poke around the new ui, test_ui_state.js, etc
<jcsackett> and *doesn't* make it a component of the URL.
<rick_h_> well the component is still inspector
<rick_h_> but the metadata will have to instruct it which 'type' to build. We've got a few now
<rick_h_> there's the normal service inspector, the local charm deploy, and the upgrade one I think. 
<rick_h_> anyway, poke around and we'll chat in the morn
<jcsackett> Dig. 
#juju-gui 2014-04-25
<jcsackett> morning all.
<rick_h_> morning
<jcsackett> rick_h_: want to chat about local inspectors?
<rick_h_> jcsackett: sure thing
<jcsackett> rick_h_: https://plus.google.com/hangouts/_/76cpij86oaqmt8r5e9lg691r88?hl=en
<jcsackett> jujugui: call now, i guess? all, what, three of us?
<rick_h_> jcsackett: ah sorry
<rick_h_> jcsackett: kadams can't make it 
<rick_h_> jcsackett: so going to pull the plug
<jcsackett> rick_h_: works for me. :)
<kadams54> Hey all, back in the saddle here.
<rick_h_> woot
<kadams54> jcsackett, rick_h_ Give me a moment to spin things up and I'll be ready for some pairing
<rick_h_> kadams54: awesome, heading to the desktop
<rick_h_> kadams54: setup a hangout when you get a sec and a pull request of WIP to pull down and poke at
<kadams54> kk
<kadams54> https://plus.google.com/hangouts/_/76cpjv0pjdnrfmdg99cmtm9k5c
<rick_h_> hmm, chrome is unhappy sec
<rick_h_> this party is over
<kadams54> :-(
<rick_h_> kadams54: https://plus.google.com/hangouts/_/72cpicrq2pbtqk329ri2577nug
<rick_h_> kadams54: yay, pull request passed ci. Is that ready for review or are you cleaning?
<rick_h_> kadams jcsackett out for a bit. Will be around tonight. Safe travels and catch up in vegas
<kadams54> rick_h_: Cleaning. Well, cleaned. Now I'm fixing the tests that cleaning broke.
<jcsackett> rick_h_: cool beans. see you in vegas!
<kadams54> rick_h_: Hmm, I was running through QA and I'm seeing problems with il flag
<kadams54> Charm API error of type: parameter_not_supported
<rick_h_> kadams54: k, what was the request made?
<rick_h_> kadams54: the ajax url that was built?
<kadams54> Checkingâ¦
<rick_h_> kadams54: and can you reproduce it on comingsoon?
<kadams54> https://manage.jujucharms.com/api/3/search?text%5Btext%5D=apache
<kadams54> When requesting http://192.168.33.10:8888/:flags:/il/?text=apache
<rick_h_> hmm, yea that is messed up
<rick_h_> the text=text stuff is all wrong
<rick_h_> jcsackett: if you get a sec to peek at ^ 
<kadams54> Not reproducible on comingsoon, but that's not that surprising
<kadams54> All this work originally started (IIRC) with the card about search info in the URL not being populated into the search box
<rick_h_> kadams54: ok, so it is something from your branch then. I'll see if I can replicate 
<kadams54> Which is what I was testing when I ran into thisâ¦
<rick_h_> kadams54: off to pick up the boy from day care. Push up the latest and I can try to reproduce and debug tonight
<kadams54> Yeah, latest is pushed
<rick_h_> ok, cool thanks
<rick_h_> will peek after his bed time. Wife is away tonight
<kadams54> Alright
<kadams54> I need to make up my morning hours, so I'll also be up late.
<jcsackett> kadams54: url for this branch? i have some notion what might be going on, but need to see your code.
<rick_h_> kadams54: k, there should be something in jcsackett's branch involving state and your work that's mixed up generating the poor api url
<kadams54> https://github.com/kadams54/juju-gui/tree/search-widget
<kadams54> jcsackett: ^
<jcsackett> kadams54: so, https://github.com/kadams54/juju-gui/commit/2bab254d773a270de6ec43e6ac39b066c26696d1
<jcsackett> line 651 in the diff
<kadams54> Yeah
<kadams54> Yup
<jcsackett> where you have viewCfg.filters.text = metadata.search, that doesn't account for the updates from my branch--switch that to either metadata.search.text, or see if you can just use state.get('filter)
<jcsackett> sorry, i was syncing with your branch, and never saw that break.
<arosales> rick_h_,  what's the trick to use the console to update the environment name / type? 
<jcsackett> but that should fix your issue.
<jcsackett> kadams54: if you can use state.get('filter') you should be doing view.Cfg.filters = state.get('filter')
<kadams54> (y)
<jcsackett> kadams54: or rather viewCfg.filters = state.get('filter').getFilterData() -- double check the actual name of that method.
<jcsackett> "(y)" ? that's an IRC shorthand i haven't seen before. :p
<kadams54> Yeah, that looks right
<kadams54> I think it's actually Facebook/iOS/Skype shorthand :-)
<jcsackett> oh, like (ninja)
<kadams54> (y) == thumbs up
<kadams54> Yeah
<jcsackett> cool. good to know. :)
<kadams54> (y)
<kadams54> ;-)
<kadams54> guihelp: https://github.com/juju/juju-gui/pull/262 ready for review and QA
<rick_h_> arosales: second, I'll have to look it up. 
<arosales> rick_h_, ok thanks
<rick_h_> arosales: pm'd to you
<arosales> rick_h_, thanks
#juju-gui 2014-04-26
<kadams54> rick_h_: You around?
<rick_h_> kadams54: howdy
#juju-gui 2015-04-20
<lazyPower> rick_h_: syn
<rick_h_> lazyPower: ack
<lazyPower> heyo o/
<rick_h_> howdy
<lazyPower> i hear we have new toys to pilot?
<lazyPower> will you have time to sync with us over that in the next couple days?
<rick_h_> is this public toys or private toys? e.g. should we chat elsewhere?
<lazyPower> us being new-workloads
<lazyPower> i dont know...
 * rick_h_ pms you
 * lazyPower is claiming mushroom treatment
<rbasak> rick_h_: about?
<rick_h_> rbasak: yes, how goes?
<rbasak> I'm drafting an email to the TB to request a stable release exception for juju-quickstart.
<rick_h_> rbasak: ok, this is to get the current release into vivid?
<rbasak> Thought I'd just check with you. They like to see some commitment from the upstream team to help with QA etc. Is this OK with you?
<rbasak> rick_h_: not just Vivid, but also Trusty.
<rbasak> rick_h_: as we're already pushing new Juju releases into Trusty, I think it makes sense to push corresponding juju-quickstart releases also.
<rick_h_> rbasak: definitely, let us know what we can do to help. frankban is out today but will be back in the AM and can work with you on anything as he's more your TZ
<rick_h_> rbasak: +1
<rick_h_> rbasak: please copy us on anything and let us know what we can do to help and we're happy to help prove out some QA and such. 
<rbasak> rick_h_: OK great! I'll Cc you in the TB email. I think the only commitment we really need from you is just for you to help the QA - as you're the experts juju-quickstart's function so having that with you makes sense.
<rbasak> rick_h_: we (server team) will just want a QA ack from you in the bug when we have something in trusty-proposed before we push it to enter trusty-updates.
<rbasak> rick_h_: does that sound OK to you?
<rbasak> (each time)
<rbasak> rick_h_: in general we're driven by the Juju team as to what Juju version they want to push into Trusty. I guess we'll work the same way for quickstart.
<rick_h_> rbasak: +1, happy to help and follow up on the bugs
<rbasak> Great. Thanks!
#juju-gui 2015-04-21
<lazyPower> rick_h_: ping
<rick_h_> lazyPower: pong
<lazyPower> Greetings, are we doing some post processing on bundle ingests? I see a big diff between whats in repo vs whats in the store:  https://api.jujucharms.com/charmstore/v4/~kubernetes/bundle/kubernetes-cluster-2/archive/bundle.yaml http://bazaar.launchpad.net/~kubernetes/charms/bundles/kubernetes-cluster/bundle/view/head:/bundles.yaml   
<lazyPower> namely the num_units on subordinates which will cause a failed deployment :(
<rick_h_> lazyPower: looking
<rick_h_> lazyPower: how's the deployment being done? 
<lazyPower> rick_h_: clicking "add to canvas" on the demo site
<rick_h_> lazyPower: right...ok. filing bugs. when the bundle is transposed to the new format that's getting added and it shouldn't. 
<rick_h_> rogpeppe: urulama ^
<lazyPower> ack. I figured it was something new - thanks for taking a look
<rick_h_> urulama: that came up during the roadshow with sabdfl, breaking the demos. 
<rick_h_> urulama: It appears to be that transpose of .orig to bundle.yaml
<urulama> rick_h_: great!
<rick_h_> urulama: filing a bug on the charmstore atm, will be high priority since all the tools were updated to use the bundle.yaml vs the orig so it's broken by default for everyone
<rick_h_> lazyPower: https://github.com/juju/charmstore/issues/358 will track there
<lazyPower> Thanks rick! Appreciate the hustle 
<rick_h_> lazyPower: sorry we broke that on you. We'll try to get it right asap but will probably be a bit. 
<rick_h_> lazyPower: for now, the work around is to get the yaml file https://api.jujucharms.com/charmstore/v4/~kubernetes/bundle/kubernetes-cluster-2/archive/bundles.yaml.orig
<rick_h_> lazyPower: and use that directly as it's the correct format/file
<lazyPower> i dont think we have a mechanism to do that on the demo site 
<rick_h_> lazyPower: not sure if we can go the old drag/drop route or somethin to twist the demo to work asap
<rick_h_> lazyPower: right, I mean download the yaml file and go the drag/drop route vs the search/add to demo button. 
<urulama_> lazyPower: so, the num_units = 1 is not supposed to be there, right
<lazyPower> urulama_: correct
<lazyPower> num_units should be blank, as teh charm is a subordinate. Subordinate charms do not allocate machines
<rick_h_> urulama: correct, subordinates can't have a num_units as the number is determined by the service they're related to
<urulama> lazyPower: do we have a list of bundles that are demoed and need to be fixed?
<lazyPower> urulama: i dont, but let me follow up and try to get a list for you
<urulama> lazyPower: ty!
<rogpeppe> rick_h_: interesting bug, thanks
<rogpeppe> rick_h_: i'll just check, but i'm not entirely sure whether the bundle translation code is in a position to know if the charms are subordinates or not
<rogpeppe> rick_h_: actually, the better solution is just to not add num_units if it's 1
<rick_h_> rogpeppe: true, but we have to find a way. 
<rick_h_> rogpeppe: +1
<rogpeppe> rick_h_: i think this means we'll need to move to charm.v6
<rogpeppe> urulama, mhilton: ^
<rick_h_> rogpeppe: wheeeeee
<rick_h_> rogpeppe: but why charm if it's doing it in bundle ingestion?
<rogpeppe> rick_h_: the charm package does bundles too
<rick_h_> rogpeppe: I guess I had hoped it was something in the ingestion/translation code that could be adjusted
<rick_h_> rogpeppe: ah, gotcha
<rogpeppe> rick_h_: the problem is that the current bundle code treats a missing num_units field as meaning 0
<rick_h_> rogpeppe: k
<rogpeppe> rick_h_: we *could* interpret 0 as meaning 1, but there's no way to do that and still allow a service with 0 units
<rick_h_> rogpeppe: right, and that's a good thing to have 
<rogpeppe> rick_h_: yup
<rogpeppe> rick_h_: i think this probably also means we need to reingest all bundles
<rick_h_> rogpeppe: we'll need some form of migration. Now the migration could check is_subordiante over the api though
<rick_h_> rogpeppe: to self-heal vs reingest, but we can see if reingestion has any side effects we don't like
<rick_h_> have to think it through
<rogpeppe> rick_h_: the migration has to happen inside the charm store.
<rick_h_> rogpeppe: it could be an external function? api to just update the bundle.yaml once the charm page upgrade is through.
<rick_h_> I don't see why the migration has to happen in the CS?
<rogpeppe> rick_h_: i guess if we're happy with it updating the latest revision of the bundle only
<urulama> rick_h_: was thinking the same thing ... but then sha is not correct
<urulama> rick_h_, rogpeppe: we bump bundle revision
<urulama> which should be ok
<rick_h_> since the bundle.yaml is not in the source tree we can just bump it
<rick_h_> without caring it's not in sync with the original bzr tree
<rogpeppe> rick_h_: as a temporary fix, could we just change the deployer to ignore num_units on subordinates?
<rick_h_> rogpeppe: deployer, gui, quickstart...
<rick_h_> update all the tools vs 1
<rick_h_> rogpeppe: we have a work around atm, but the bug remains/needs to be corrected longer term
<urulama> +1
<lazyPower> https://bugs.launchpad.net/juju-gui/+bug/1446789
<mup> Bug #1446789: Exporting an un-committed bundle results in broken bundle <juju-gui:New> <https://launchpad.net/bugs/1446789>
<lazyPower> https://bugs.launchpad.net/juju-gui/+bug/1446788
<mup> Bug #1446788: Build-a-bundle appears broken in firefox on jujucharms.com <juju-gui:New> <https://launchpad.net/bugs/1446788>
<lazyPower> found a couple corner cases
<rick_h_> lazyPower: they both seemed to be related to exporting uncomitted?
<rick_h_> lazyPower: ok if I combine them?
<lazyPower> sure
<lazyPower> i dont think one is related to the other though - beleive the behavior of exporting an uncommitted bundle = that format
<lazyPower> and the commit button is a side-effect of some recent change according to the console
<lazyPower> but i'll follow along in any case and offer re-testing for validation :)
<rick_h_> lazyPower: oic, one is pressing the export button and one is hitting the commit button?
<lazyPower> correct
<mbruzek> rick_h_: correct
<lazyPower> i probably worded them poorly - sorry
<rick_h_> lazyPower: what's the subordinate?
<lazyPower> rick_h_: kubernetes in this case
<rick_h_> and the other one is the -master one?
<mbruzek> kubernetes-master is a regular one
<rick_h_> ok
<rick_h_> lazyPower: mbruzek is there a relatoin on the subordinate?
<mbruzek> rick_h_: yes
<rick_h_> mbruzek: ah ok, had to zoom in ty
<rick_h_> mbruzek: lazyPower can you guys add which relations are made so we can dupe/test it out please? I see a couple of options
<lazyPower> rick_h_: on 1446788
<lazyPower> ?
<rick_h_> lazyPower: yes please. something is broken as the changes roll out, and trying to dupe it I see a few diff relations options as I link across
<lazyPower> ack, i'm goign to paste a reference bundle that has everything we were attempting in the gui
<rick_h_> lazyPower: rgr that'll work ty
<lazyPower> updated
<rick_h_> <3 ty lazyPower 
<mbruzek> Hey rick_h_ we just were able to import that bundle in the GUI demo
<mbruzek> But we were not able to "build" that bundle from the GUI demo 
<mbruzek> charm by charm
<mbruzek> in firefox
<rick_h_> mbruzek: right, so when you build a bundle we have to turn things from temp names 'new machine 1' into a real juju name/reference 'machine 13'
<rick_h_> and so my guess is that something raced or didn't update properly as the list of changes rolled out
<rick_h_> so duping to find out where the service reference got lost
<mbruzek> OK
<rick_h_> mbruzek: while deploying the bundle bypasses that uncomitted/list of changes work 
<mbruzek> rick_h_: When I imported a bundle with series == trusty, when I exported it, all is as expected, EXCEPT the series got converted to precise.
<mbruzek> rick_h_: bug or no?
<rick_h_> mbruzek: because the demo defaults to being precise for the purpose of the demo
<mbruzek> rick_h_: OK
<mbruzek> no bug it is, just seems fishy, like the GUI knows better than I do!
<rick_h_> it's the fun of riding the fine line of a tool that lives in an environment and one that can be run without
<rick_h_> if it was deployed into a real env it would look at what your juju env default is
<mbruzek> rick_h_: I was just kidding, understand it is just a demo
<rick_h_> mbruzek: all good
#juju-gui 2015-04-23
<mhilton> one
<mhilton> sorry my irc client jumped
