#juju-gui 2013-07-29
<gary_poster> teknico, bcsaller could you please make sure that you have your London tickets approved, purchased, and entered on https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AtC9etoysSQldFRfYU0zZjE5WThuNUVWRXlEVmQwOVE#gid=8 by EoD today?  (Same goes for me)
<bac> hi benji, i landed my branch that borrowed from yours and then made some changes.  you may see mild conflicts.
<benji> bac: ok, thanks for the heads-up
<teknico> gary_poster: will do. got a sec for a quick call re: vacation?
<gary_poster> teknico, sure, come on by guichat
<teknico> gary_poster: travel request submitted, waiting for approval and booking code
<gary_poster> teknico, approved
<teknico> gary_poster: got the code, thank you
<teknico> ehi jujugui! tired of all that javascript? there's a nice and long python diff waiting for you at https://codereview.appspot.com/12022044 but hurry, only two seats left! ;-)
<gary_poster> jujugui, we have one critical task that I'd like someone to focus on: try to figure out why redeploys of the jujugui charm to jujucharms do not successfully inform browsers to clear their caches, and fix it.  this is a "drop what you are doing" sort of task unless you are near tying something up, that should be wrapped up tomorrow so we can deploy Wed.
<gary_poster> jujugui, meanwhile, in addition to Nicola's review request (https://codereview.appspot.com/12022044) we also have Kapil's (https://codereview.appspot.com/11966044/) and Huw's (https://codereview.appspot.com/11999043/)
<benji> gary_poster: I'm merging a branch now and could take this up.  I'm also annoyed at the cache issue, so there's anger I can harness ;)
<gary_poster> jujugui, finally, another urgent task is that IE 10 unit tests are failing, .
<gary_poster> benji, cool thanks :-)
<gary_poster> I'll put your head in the card benji
<gary_poster> on
<benji> k
<bac> teknico: i'll do your review.  have an orange stand up in a few minutes though
<gary_poster> bac, I don't think you do.  combined standups start today
<rick_h> bac: do we? Are we trying the joint standups this week?
<bac> gary_poster: oh, right. cool!
 * bac fixes calendar
<teknico> bac: thank you
<teknico> hazmat: looking at your proposal, unclear on how to review it :-) (also, I cannot find its card, is there one?)
<gary_poster> teknico, no card, please create in maintenance
<gary_poster> teknico, you should try finding a charm with a bool
<gary_poster> in the congig, make an environment with it, export it
<gary_poster> old version should have issue described by related bug, new should not. extra credit if you try running it through the deployer
<teknico> gary_poster: yeah, but even before QAing it, I was wondering how to understand the change by looking at it :-)
<teknico> it'd be nice to be able to look at a diff on non-minimized code
<gary_poster> teknico, first line of the compressed file should tell you where to find the diff source, and related yaml parser issue.  if it is insufficiently clear, that's something for the review.  after you've tried to figure it out, if you are still unclear let me know and I'll try to clarify.  I don't want to spoil your blank-slate impressions though: we should be aiming for clarity for someone in your shoes
<teknico> gary_poster: oh, right, thanks, I'll try to put together the change
<gary_poster> cool teknico 
<adeuring> gary_poster: when/where is the standup? I don't see it in my google calendar
<gary_poster> adeuring, thank you for reminding me.  I just invited orange squad to the meetings.  Friday is a different time than the others.  we always meet in http://tinyurl.com/guichat .  Look good?
<hatch> morning all
<gary_poster> morning hatch
<adeuring> gary_poster: sure
<gary_poster> cool adeuring 
<hatch> gary_poster: in a few minutes I can start on huw's review
<gary_poster> thanks hatch
<gary_poster> trying to disconnect/reconnect for better network; back in a sec, hopefully
<gary_poster> nope, no real improvement
<gary_poster> :-/
<hatch> it didn't show you dc/rc :)
<hatch> it got to 10C last night....summer is over :(
 * hatch straps his snowboard on and sits on the stairs waiting
<gary_poster> heh
<gary_poster> teknico, doing your second review
<teknico> gary_poster: thank you
<bac> teknico: your branch looked good.  doing a QA deploy now.
<hatch> rick_h: saw your q in #yui, any progress?
<rick_h> hatch: yea, some progress. I'm buried into the ns-routing code atm
<rick_h> wheee! lucky monday!
<hatch> oh alright - keep in mind that the majority of that code is the yui router code with some stuff injected into it
<rick_h> hatch: yea, but I'm into how we parse/split/combine urls atm
<rick_h> hatch: so all our own doing :)
<hatch> ahh -
<rick_h> have the bug fixed now but getting #bws-configuration#bws-configuration in the url :)
<rick_h> hatch: but thanks for checking in
<hatch> np - I may be able to lend a hand with the routing stuff if you run into any 'wtf' areas :)
<rick_h> hatch: just hard to trace. still have double dispatch along with a couple of passes through the code for the orig url vs incoming and such. #needmoarcoffee
<hatch> my coffee is watered down for some reason....not impressed - might have to take a walk to a coffee shop
<hatch> gary_poster: as far as QA'ing Huw's branch goes - is this supposed to be an incremental branch? I have found a few 'bugs' but they aren't critical
<gary_poster> hatch, not sure it is supposed to be incremental, but we can treat it as such.  +1 on getting this landed and then either shooting Huw/list an email with qa issues, or if they are trivial putting something together quickly yourself
<hatch> gary_poster: we should have a "sprite all the things" card so that we don't forget in the future :) because all of these new icons are being added un-sprited
<gary_poster> hatch, oh suck. :-/  ok, will do.  I assume you'll mention that to Huw as well, so that in future branches he does these with sprites
<gary_poster> done fwiw, in maintenance: high
<adeuring> sinzui: could you have another at my MP from friday?
<hatch> yup will do
<sinzui> adeuring, I am just giving your my r=me
<adeuring> sinzui: coll, thanks!
<rick_h> woooooooooooo! it works!
<sinzui> adeuring, you can approve the review to merge it.
<adeuring> sinzui: ack
<sinzui> orangesquad. I think we need to build a new staging env
<gary_poster> rick_h, yay!!! :-)
<gary_poster> teknico, LveryGTM with comments
<teknico> gary_poster: thanks, replying
<sinzui> adeuring, I would like you to work on https://bugs.launchpad.net/charmworld/+bug/1199780
<_mup_> Bug #1199780: search requests errors when a charm has no last_change <charmworld:Triaged> <https://launchpad.net/bugs/1199780>
<adeuring> sinzui: I started already ;)
<sinzui> :)
<sinzui> adeuring, I am moving the card to the juju-gui board
<adeuring> sinzui: ok
<hatch> gary_poster: reviewed/replied to huw's branch - I can fix the code issues and take a stab at the qa ones to get it landed if you like
<hatch> I could also investigate the IE10 failures
<gary_poster> hatch, big +1 on landing Huw's branch with fixes, thank you.  IE10: you ok with that, or would you rather someone else look at it?  You've certainly paid your dues there :-)
<hatch> haha well there looks like there is a CI failure and an intermitant IE failure
<hatch> I don't know how long the fixes in huw's branch will take (shouldn't be too long though) so if someone else can pick it up first that'll be fine :)
<Makyo> I just started the IE10 stuff, but haven't gotten much farther than turning on the VM
<gary_poster> hatch cool, thanks.  Makyo, awesome, thanks.
<Makyo> Mocha desperately needs a stop button.
<gary_poster> heh
<gary_poster> yes
 * rick_h runs make test-debug and ducks
<hatch> rick_h: so in your new branch the #'s will be gone?
<hatch> from the tabview
<rick_h> hatch: no
<rick_h> hatch: they'll be there still since we need them for the charm browser side
<hatch> ahh, hmm
<rick_h> hatch: but the big lesson here is that the tabview doesn't add the #, the Y.App does
<rick_h> which took me a LONG time to figure out and quit blaming the wrong code
<hatch> ohh from the <a>'s?
<rick_h> hatch: riiiiight
<rick_h> which is why all of this is a routing issue, not a tabview/browser subapp issue
<hatch> see a's are bad
<hatch> :P
<rick_h> oh hush
<hatch> lol
<hatch> sorry coudln't resist
<hatch> rick_h: I'm guessing that has something to do with the pjax stuff
<rick_h> hatch: well, it's the Y.App wanting to update the url without a reload
<rick_h> hatch: ah, yea...that might be part of it as well I guess. using hash for content/page id
<hatch> yeah - pjax listens to all a's and then updates the url directly without clicking
<hatch> without redirecting i mean
<rick_h> right
<hatch> so i'd say first place to start would be monkey patching pjax out of there
<hatch> I remember we left it in because it didn't appear to cause us issues
<hatch> we were wrong :)
<rick_h> heh, no. The fix is actually not bad. I've got it all working just needs tests. 
<hatch> oh cool
<rick_h> https://code.launchpad.net/~rharding/juju-gui/routing-issues/+merge/177401 for diff
<rick_h> that and hash comes after QS in a url
<rick_h> doing it the other way is un-good
<hatch> while this is a good fix its really just bandaiding the real problem
<rick_h> Hmmm, I'm not 100% sold ont hat
<rick_h> err that
<hatch> because that hash shouldn't be added to the url at all
<hatch> we don't use pjax
<rick_h> yes it should!
<rick_h> we want to generate a unique url so you can link directly to the readme of a charm
<rick_h> it's part of the UX design.
<hatch> ohh, hmm that should probably be /precise/ceph-13/readme then
<hatch> at least imho
<rick_h> that we can debate perhaps, but it's not a different resource to view the readme
<rick_h> only a small section of content changes
<rick_h> which is what anchor tags are for
<hatch> that's arguable because webapp not website
<rick_h> I agree it's arguable
<rick_h> just don't agree with your side :)
<hatch> lol
<bac> teknico: i tried to deploy the charm with your changes and got an install error. investigating still.
<hatch> this is the url from the inspector though :8888/#bws-readme  which is no good
<rick_h> hatch: agree, and it's an easy fix. 
<rick_h> we just have to catch the click event when deployed via the inspector and halt
<rick_h> hatch: but only when done through the inspector, so we need an init flag for it
<teknico> bac: uhm, I run "make ftest" before proposing without errors...
<hatch> sure - so why wouldn't we remove the pjax and then enable it, instead of disable it
<hatch> it's a side effect that we just happen to be using in a single place in the app
<rick_h> hatch: either we disable it and add it for browser or leave it and disable it for inspector. 
<rick_h> either way we have to work around this stuff. 
<hatch> I'm saying we manually add the hash when we need to
<hatch> look how long it took you to find the source and you wrote the code haha
<rick_h> and none of that is the router code's fault? That is improperly parsed QS and hashes?
<rick_h> and I didn't write the router code :P
<hatch> well when I 5why it I get to pjax
<rick_h> because the hash is added via pjax. Then we improperly hanled hashes in our routing
<teknico> bac, gary_poster: reproposed with changes that address your remarks
<rick_h> if you remove pjax, we're still handling them wrong in routing. 
<hatch> that's not how 5why's works
<hatch> lol
<rick_h> I thought 5why was a typo :/
<hatch> I'm not saying we handle them properly (although I don't know what the issue in router is)
 * rick_h hits the web for wtf 5why is
<hatch> oh hahaha
<hatch> 5why's is a technique for determining the root cause of a problem
<hatch> it also exposes issues along the way
<rick_h> yea, I see. I'll write up my 5why's later after I get these tests in
<hatch> on a different angle....should we pass the viewlets container to the render method?
<hatch> https://codereview.appspot.com/11999043/diff/1/app/views/viewlets/charm-details.js
<hatch> see that as to why I think so...
<rick_h> hatch: so isn't that the slot name? Or is it not?
<rick_h> the viewletManager should handle this I'd think when you show/hide a slot
<rick_h> and not the viewlet itself
<rick_h> though the way things work 'render' !== 'show'
<rick_h> :/
<hatch> yeah hmm ok this method should be slightly refactored then
<rick_h> hatch: +1
<hatch> render should handle generating the content
<hatch> should only*
<rick_h> hatch: yea, I'd look to the viewletManager for controlling the slot visibility imo if possible
<rick_h> as part of the showSlot() stuff
<hatch> yep and it does
<rick_h> hideSlot
<rick_h> oh, then why is this necessary?
 * rick_h isn't caught up. 
<hatch> not sure
<hatch> haha
<rick_h> but agrees with refactor of it
 * hatch looks further
<adeuring> rick_h: about bug 1199780: How is charm['code_source'] dictionary used? Can we simply drop charm['code_source']['revision'] and charm['code_source']['last_log'] if it is not avaliable, should we set it to None/null? (Note that this can also happen with the data for related charms)
<_mup_> Bug #1199780: search requests errors when a charm has no last_change <charmworld:Triaged> <https://launchpad.net/bugs/1199780>
<rick_h> adeuring: sec, looking to be sure
<rick_h> adeuring: so we'd have to refactor to add sanity checks it exists. We don't have a 'if model.get('code_source') as it seemed you'd have to have source to have a branch/pushed/etc. 
<adeuring> rick_h: right, but we can have charms whose LP brnach is deleted. And then we have this situation
<hatch> rick_h: if you're going to leave pjax in can you put a comment in the tabview code which explains where the hashes are coming from
<hatch> I figure that's the logical place someone might look in the future
<rick_h> adeuring: right, so we'd have to update the front end to handle it being option. Right now it doesn't. 
<rick_h> hatch: sure
<adeuring> rick_h: OK... What about js using the text "not available"?
<rick_h> adeuring: it's expecting a nested object. So no matter what it's changed to we need to adjust
<rick_h> adeuring: if we don't have it then I'd say we leave the value out. 
<Makyo> jujugui: IE10-able folks, need some reviews/test runs for a fix https://codereview.appspot.com/12033043/
<rick_h> then we can look if we can provide a decent default that prevents too much work
<adeuring> rick_h: OK
<bac> Makyo: i can review.  can run tests with some pain if really necessary.
<hatch> Makyo: I can run the tests
<hatch> .....and are you serious? this was the cause....ugh IE
<Makyo> bac, how about hatch runs the tests, and you sanity check? :)
<bac> sure
<hatch> Makyo: is the flags fix because window.flags was undefined at that part?
<Makyo> hatch, yeah, for running that suite in isolation.
<hazmat> for folks working on charmworld.. with elastic search.. came across this library this weekend, made working with elasticsearch much more pleasant and pythonic. http://elasticutils.readthedocs.org/en/latest/
<hazmat> builds on top of the py connector library we're already using.
<hatch> Makyo: I wonder if we should have a follow-up branch which adds window.flags to every suite and then cleans it up after every suite
<Makyo> hatch, I put that in the MP.
<hatch> oh.... /me learns to read
<bac> Makyo: nm my comment about the same.
 * bac learns to read too
<hatch> Makyo: sorry, windows 8 keeps crashing
<hatch> I just did an update so,.....ya know
<Makyo> hatch, I feel your pain, yeah
<hatch> hey Windows....nice of you to boot up
<hatch> I used to be afraid to do Linux updates, now I'm afraid to do Windows ones, my how the times have changed
<hatch> make test-server
<hatch> blarg
<sinzui> jcsackett, I am looking at the charmworld board. I think card 3.1 is done and card 3.2 is coding and already represented on the juju gui board.
<jcsackett> sinzui: you're right; i've moved 3.1 to the done-done.
<jcsackett> sinzui: do you want us updating this board as well?
<sinzui> jcsackett,  thank. you. I am dismantling the board. moving work to jujugui when it isn't already there
<hatch> Makyo: lgtm'd
<Makyo> hatch, thanks
<jcsackett> sinzui: dig.
<jcastro> how long after I feature/unfeature should it show up on the site?
<rick_h> jcastro: pretty quick. We might hit a cache on the production site but the 'change' is instant as far as the data is concerned
<sinzui> jcastro, I think the squid cache is the factor in play
<jcastro> ok
<gary_poster> jujugui, orangesquad, call in 8.  please update kanban now for a quick overview call.
<gary_poster> 7, that is :-P
<hatch> woah....new board
<hatch> gary's been workin
<gary_poster> heh
<gary_poster> jujugui orangesquad call in 2
<gary_poster> in guichat
<rick_h> jujugui I can haz critical review please? https://codereview.appspot.com/12036043
<gary_poster> Makyo, you here?
<hatch> rick_h: critical as in negative? :P
<rick_h> critical as it bugs are marked critical
<hatch> yup I'll take one
<hatch> teknico: I heard that there is no Alfredo sauce in Italy? And that you don't put chicken in pasta.....true?
<rick_h> jcsackett: can you link the branch? I tried to click the bug in the card to get to the review but failed 
<bac> jcsackett: where is your mp for that card?
<jcsackett> rick_h: yeah, i haven't been good about linking to bugs.
<bac> :)
<jcsackett> rick_h: one sec, i'll go find it.
<rick_h> jcsackett: ty
<jcsackett> rick_h: https://codereview.appspot.com/12031043/
<teknico> hatch: what?!? and, what?!?
<hatch> a friend of a friend has a friend from Italy and they claim that there is no 'Alfredo' sauce and that you don't put chicken in your pasta
<jcsackett> 10 minutes on a call with that many people. nice!
<hatch> we pro!
<hatch> bcsaller: rick_h making hangout
<bac> jcsackett: done, thx
<hatch> that's so odd - the camera was reversed during that call compared to the guichat ones
<teknico> hatch: I know of no "Alfredo" sauce and of no recipe for putting chicken in pasta
<hatch> crazystuffs
<hatch> here - Italian pasta has Alfredo sauce and chicken lol
<rick_h> sinzui: gary_poster any preference on next task priority? Pick a bug any bug?
<teknico> hatch: I'm not a food tradition purist, and I've been eating no pasta for years now, so I'm not offended
<hatch> rick_h: issue with the QA
<hatch> when I follow https://bugs.launchpad.net/juju-gui/+bug/1205468
<_mup_> Bug #1205468: fullscreen charmbrowser tabs are broken <charmbrowser> <juju-gui:In Progress by rharding> <https://launchpad.net/bugs/1205468>
<hatch> and then hit the back button
<hatch> it stays in the same page
<hatch> because it puts a history entry for the hash
<rick_h> ah crap...double dispatch fml
<rick_h> oh wait, back just removes the hash?
<hatch> yeah
<hatch> trying on serviceInspector which has no double dispatch
<hatch> same
<rick_h> right, that's kind of 'working as intended' because it does dispatch when you click a tab
<hatch> pjax must also add a browser entry
 * rick_h is thinking
<hatch> so when it's removed it should dispatch then and go back to summary
<rick_h> hatch: so I'd propose this is a low priority follow up bug to worry about the back button history atm. It fixes 4 bugs in the system currently. 
<rick_h> one critical and one high
<hatch> I'd tend to agree
<rick_h> hatch: because fixnig that isn't easy as the hash is part of the app 'state' and the state comes from the App dispatching. The fix is to not 'dispatch' but then we dont' get our app state change atm
<rick_h> so it'll take some thought/testing 
<rick_h> and jcsackett :P
<jcsackett> wait,what?
<rick_h> jcsackett: your comment in your LGTM
<jcsackett> aaaah.
<jcsackett> i was suddenly concerned you were throwing work at me, and i couldn't figure out how. e.g. "it'll take some thought, testing, and jcsackett".
<rick_h> lol, +1!
<jcsackett> this is not me endorsing the plan that work should be thrown at me. :-P
<hatch> rick_h: found a real bug
<hatch> shall I reply with repo steps on the commit?
<rick_h> stop doing that
<rick_h> hatch: yes please
<hatch> just finding the quickest repro
<rick_h> ok, well food fetching while you do that and will look back
<hatch> ok replied
<rick_h> hatch: thanks, easy fix. Appreciate it
<hatch> excellent
 * hatch wishes for a parent css selector
<hatch> bcsaller: so...any ideas for anything better than this._slots[viewlet.slot].container.ancestor('.slot')
<hatch> i'd add a slot class to the slot
<hatch> or could make it an attribute
<hatch> which would probably be nicer
<hatch> but container.ancestor() still sucks
<bcsaller> yeah, thats not great
<hatch> I could go container.get('parentElement')
<hatch> but that isn't very robust
<bcsaller> chat real quick?
<hatch> sure
<hatch> in guichat
<gary_poster> hey rick_h, you still looking for something to do?  I've got ideas if so
<gary_poster> sorry was lunching
<rick_h> gary_poster: I will be. Working on a last bug/issue in getting the other branch landed
<hatch> rick_h: so in this branch of huw's when I close the left panel after viewing some of the tabs it leaves the #'s in the url
<gary_poster> rick_h, cool.  Looking for choices.  First one is this.  Trivial but important: https://bugs.launchpad.net/juju-gui/+bug/1202636
<_mup_> Bug #1202636: Charm Details Page Under Providers Change Openstack to HP Cloud <juju-gui:Triaged> <https://launchpad.net/bugs/1202636>
<hatch> rick_h: interestingly enough, when I realod the page, that hash gets stripped lol
<rick_h> hatch: yea, it's not what I thought it was. 
<rick_h> hatch: when I dupe it works when I click the juju, but then fails when I change viewmode. There's some hidden bit somewhere I'm missing
<hatch> re the QA bug?
<rick_h> hatch: yea
<hatch> hmm I can't really be of any help there
<rick_h> hatch: yea, all good. 
<rick_h> thought that's what you were talking about
<hatch> I haven't spent much time in your homebrew routing code ;)
<hatch> oh no sorry
<rick_h> there's an existing bug for chrome that clears the url out when manually hitting a url :(
<rick_h> that's not part of this fix
<hatch> ohhhhhh
<hatch> ok that must be waht I'm hitting now
<hatch> no prob doesn't effect this branch negatively
<hatch> the status bar plays tricks on my eyes
<hatch> the red/green bars look different heights
<hatch> even though I know they can't be :)
<rick_h> hatch https://launchpad.net/bugs/1199392
<_mup_> Bug #1199392: can't view fullscreen charm details from url <charmbrowser> <juju-gui:Triaged> <https://launchpad.net/bugs/1199392>
<hatch> we have too many router technologies acting in one place
<hatch> :)
<gary_poster> sinzui, I'd like to triage https://bugs.launchpad.net/charmworld/+bug/1206158 as high.  We're having multiple questions about this on sales calls, so this would be a (presumably easy?) thing to add for good sales win.  Is that ok with you?  Am I badly underestimating the effort involved?  I hoped it would be a day or two max for one engineer.
<_mup_> Bug #1206158: On manage.jujucharms.com show download breakdown by last 30 days, last week <charmworld:Triaged> <https://launchpad.net/bugs/1206158>
<sinzui> gary_poster, okay
<gary_poster> sinzui, what do you think about effort?
<sinzui> gary_poster, a single branch that adds the model properties and and template presentation
<gary_poster> sinzui, so day or two max?
<sinzui> yep
<hatch> taking off for lunch, call cell is ya need me
<rick_h> gary_poster: so in reading that bug does that maen that we're going to start testing on 'openstack' somewhere? Or just not going to have that visible?
<gary_poster> rick_h, we're not going to have it visible.  apparently, according to mramm and others, openstack installations are too different
<gary_poster> so in the futrue
<gary_poster> we may have results for HPCloud
<gary_poster> and some other OpenStack provider
<rick_h> k
<gary_poster> and we will not be at all surprised when they have different results
<gary_poster> hatch, when you are back, no rush, but is this inspector card/task no longer valid? "Add mutation observer to viewlet to rebind viewlets when updated out of band"
<bcsaller> gary_poster: That one was from me, its still an option but its an optimization not a requirement 
<rick_h> hatch: also when you're back, branch updated for a second run through QA. 
<gary_poster> bcsaller, ok cool, thanks.  clean uptask, then?
<rick_h> hatch: think I've caught it all there. One other QA point found during this was to sidebar, open a charm, click a tab, then minimize the browser, and bring it back up. 
<bcsaller> yeah, pretty much
<rick_h> and now my head hurts...ugh routing/state FML
<benji> is anyone else having problems building (NPM downloads failing)
<gary_poster> benji, I had to make clean; didn't look closely
<gary_poster> rick_h, playing around with your branch.  lots of fixes, cool.  this one is not supposed the query string related bugs, right?  for instance, http://localhost:8888/fullscreen/search/precise/ceph-13/?series=precise&text=ceph&type=approved#bws-readme does not load properly.  I already saw  you say that back arrow bugs were for later, I think, which I agree with.
<gary_poster> "this one is not supposed the query string related bugs, right" -> this branch is not supposed to fix the query string related bugs, right?
<gary_poster> rick_h, those are the only bugs I can find.  Way better.  thank you!
<rick_h> gary_poster: looking
<rick_h> gary_poster: right, it doesn't fix the chrome removing the query string bug
<rick_h> gary_poster: I did not run into that cause in my list. 
<rick_h> oh hmm, that happened to me on FF as well. Thought it was a chrome-only bug. 
<rick_h> gary_poster: but yea, that's still out there on our board. 
<gary_poster> rick_h, cool, thanks!
<rick_h> gary_poster: but it should hit 4 bugs currently in the tracker. 
<gary_poster> rick_h, I saw, sweet :-) maybe even more
<rick_h> the back button I think we could chat on. I keep going back/forth on how that 'should' work since we're treating tabs as unique urls, vs 'back button, ignore tabs'
<gary_poster> I see
<jcsackett> rick_h: qs is removed in both ff and chrome,but in ff the correct view is shown
<jcsackett> so it's partially an FF bug.
<rick_h> jcsackett: ah, in nightly it went back to search just like chrome
<rick_h> jcsackett: in FF nightly that is. 
<jcsackett> rick_h: interesting.
<jcsackett> rick_h: i'm not sure what that suggests,but it certainly suggests something. :P
<rick_h> jcsackett: but yea, that's a routing/double dispatch bug I think. 
<rick_h> jcsackett: yea, suggests there's work to be done to fix that bug...for someone...
<jcsackett> if it's still around when i get done with charmstore-apocalypse i'll be happy to look.
<hatch> back
<hatch> rick_h: ok will re-qa
<gary_poster> bcsaller, hey.  did you see my September/London flight request?  please get that done today (which means, you propose via form, I approve, you go to travel provider, they get you flight, and you enter details on spreadsheet)
<bcsaller> gary_poster: yeah, I saw it, I have it on my calendar to do it today as well.
<gary_poster> cool bcsaller  thanks
<gary_poster> hazmat what I was trying to say in last reply to review is that I'm happy for you to give this to us to land if you want.  we appreciate very much the work you've already done
<hatch> gary_poster: CI is broken....can't deploy charm
<gary_poster> hatch, may be because canonistack is broken. :-/ sinzui did you say that you can't get a juju env on canonistack any more?
<sinzui> gary_poster, hatch. I am in #is now diagnosing why we cannot build a new env. If CI was in, or use anything in, canonistack, then it is dead
<gary_poster> ack sinzui thanks.  hatch ^^^ :-/
<hatch> ahh darn, alright
<hazmat> gary_poster, ack
<hatch> rick_h: when changing tabs and then hitting back, the hash changes but the tabs never do
<rick_h> hatch: rgr, duplicates here
<hatch> rick_h: you fixing now?
<rick_h> hatch: back isn't hitting the subapp at all. It's not dispatching to the subapp so not sure how to fix that atm
<benji> ok, that's weird; I changed all the "https" to "http" in npm-shrinkwrap.json and now npm install works
<hatch> rick_h: well all of the routes get collapsed into the parent app, so my guess is it's something to do with your custom routing stuff
<rick_h> hatch: custom routing stuff?
<hatch> like how everything goes into routeDefault and routeView
<hatch> it's possible something in there is clobbering it up
<hatch> because every time the url changes it should dispatch
<rick_h> hatch: no, I'm saying is that none of the subapp routes get touched. Right now it doesn't appear ns-routing is hit during a back button right now
<hatch> oh really?
<hatch> so routeDefault isn't called? (it's a * so it should be called no matter what)
<rick_h> hatch: yes, ns router.parse() isn't getting hit (put a debugger in there) on back, but it is on every click/forward call
<rick_h> hatch: checking routeDefault
<rick_h> hatch: correct, routeDefault is not touched 
<rick_h> hatch: so calling this one bigger than subapp at the moment. 
<hatch> well that's just friggen weird
<rick_h> hatch: not if something in Y.App or something isn't re-dipatching on anchor change from back?
<rick_h> I'm not sure what to say without doing a lot more looking and hitting EOD soon
<hatch> so the pjax stuff is not causing a re-dispatch on back
<hatch> because the navigate stuff triggers the re-dispatch (as it should)
<rick_h> well someone is not, I'm not clear enough to say who
<rick_h> hatch: but yea, something up. Back works on non-#hash changes
<hatch> well it's pjax that's adding the hash right?
<hatch> oh I bet I know why
<hatch> checking...
<hatch> ok I 'think' that becuase we use html5: true in the app, it only dispatches on real paths, not hashes
<rick_h> hatch: so calling it not related to this branch. Up for a secondary bug :)
<hatch> ok simply switching that flag didn't do it
<rick_h> hatch: yea, worst case we'd have to detect and manuall fire a navigate event to force it if there's not a good 'natural' fix for that. 
<hatch> or we switch to using a /path for it :)
<gary_poster> +1 if that's easy fwiw
<rick_h> hatch: or stop tracking the tab, in the url, or 100 other things. However, I'd really like to land this as it fixes a real 'cannot use the gui' issue while the back is slightly annoying but not as big
<gary_poster> +1 also
<rick_h> The bug I'm on will be quick, I can get back to 'back button' issues later tomorrrow. 
<hatch> yeah I'm pretty sure everything is qa'ing ok
<rick_h> cool
<hatch> few more things to check
<hatch> and yeah I still want this landed, that fix can be pushed to later
<rick_h> ok, I was trying to pick up the irc vibe on if this was heading towards blocker for your vote to land. Sorry. 
<rick_h> :)
<hatch> each irc line needs a body language colour
<gary_poster> or smell!
<hatch> lol
<hatch> I thought someone made something that could make smells in your computer
<gary_poster> yeah I saw something like that.  didn't click through :-)
<gary_poster> ah leankitkanban...you make me want to write a kanban board sometimes...
<rick_h> lol
<hatch> rick_h: curious as to why you relocated the initState method
<rick_h> hatch: it's no longer private
<hatch> ohh
<hatch> gotcha
<rick_h> grouped with the non-private methods alphabetically
<hatch> rick_h: just typing out the lgtm, did you want me to create a card for the hash-no-dispatchy ?
<rick_h> hatch: sure thing, thanks
 * Makyo de-net-problems.
<hatch> rick_h: letr-rip
<hatch> Makyo: .NET?
<hatch> :)
<hatch> rick_h: I tagged the bug charmbrowser because of the approach I think we should take to resolve it not because of the cause just FYI
<Makyo> Pff.
<rick_h> hatch: all good
<hatch> now I have to figure out how to propose huw's branch to the same reitveld
<rick_h> gary_poster: so landing this now. I'm not sure what the release schedule and such is for things right now. 
<rick_h> hatch: don't. I just push to my branches and re-submit it
<rick_h> then in the comments link/note the original reitveld for tracking purposes
<hatch> ahh ok
<rick_h> because reitveld is per google account you can't update his
<hatch> ahh unfortunate
<hatch> but understandable
<rick_h> yea, we tested a way to try to use group owned branches in LP but still fell short. 
<gary_poster> rick_h, planning on wednesday.  minimally we want this, we want Kapil's export branch, and we need benji's charm cache fix.  everything else is gravy
<rick_h> gary_poster: ok cool then. 
<gary_poster> benji, have you been able to dupe?
<benji> gary_poster: not yet
<benji> are there any more details about the problem somewhere?
<benji> I didn't see a bug linked to the card.
<gary_poster> benji, :-( boo hoo.  when you can let me know and I will be happy, because I bet a solution will not be far behind.  Did you start with 0.8.0 and then go to 0.8.1?  no bug,  want to chat in 10 minutes?
<benji> gary_poster: chat in 10 sounds good
<gary_poster> cool talk to you soon
<hatch> shadowrun returns is now available on steam http://store.steampowered.com/app/234650/ but no Linux unfortunately
<hatch> I'll probably be picking up Expeditions: Conquistador tonight though http://store.steampowered.com/app/237430
<hatch> which is avail for all 3 platforms
<bcsaller> hatch: dota2 ;)
<hatch> oh crud I didn't think it was avail for Linux
<hatch> did you pick it up?
<hatch> free to play eh
 * hatch is skeptical
<hatch> :)
<hatch> bcsaller: can you review https://codereview.appspot.com/12054043/  (it's Huws with the mods we discussed)
<bcsaller> hatch: yes, I'll start shortly
<hatch> thank yas
<hatch> gary_poster: is there anything specific you would like me to jump on now?
<gary_poster> hatch, hi.  mm...no.  I have been adding cards on board.  any of those are good.  hook up retry/resolve/replace?  fix small issues I identify in ghost inspector?
<gary_poster> hatch, hideous yellow cards are kind of mini-story markers that have sub-cards following them
<gary_poster> benji, come on by guichat?
<benji> sure
<gary_poster> hatch do you need another review of Huw's baranch or are you good to go
<hatch> ahh ok, nope, I reviewed his so one more should be fine
<hatch> my changes were fairly small but somewhat of a refactor
<hatch> gary_poster: you say those ugly yellow ones have sub-cards....am I totally missing how to view those cards from the ugly-yellow ones?
<hatch> or are you just using the title as the 'marker'
<hatch> I think I'll work on the ghost inspector
<hatch> bcsaller: replies made
<gary_poster> benji #1206260
<_mup_> Bug #1206260: GUI charm does not handle browser cache properly <juju-gui:In Progress by benji> <https://launchpad.net/bugs/1206260>
<benji> thanks
<gary_poster> welcome
<gary_poster> on kanban too
<gary_poster> hatch, sorry, ugly yellow card is supposed to precede associated cards, going left to right, top to bottom
<hatch> ahh got it
<hatch> bzr diff | vim -  has changed my life
<hatch> yay for sprints
<hatch> lol
<gary_poster> heh
<gary_poster> Makyo big +1 on the thrust of your flags-cleanup branch.  I guess you decided to postpone the post-test flag cleanup to another day?
<gary_poster> (because your branch exposes some tests for not being very hygenic with their flags
<gary_poster> )
<Makyo> gary_poster, yeah, I just want a direction to aim in, for the most part.
<Makyo> Running into LP problems, reproposing.
<gary_poster> Makyo, cool.  direction is good.  I don't think you'll have any detractors.
<hatch> Makyo: so this is a codereview for discussion not to land?
<Makyo> hatch, to land, as an incremental step.
<hatch> bcsaller: because codereview is slow - if fillslot is a impl detail under showviewlet then it should be _fillSlot :)
<Makyo> LP fixed itself \o/
<gary_poster> heh
<bcsaller> hatch: I'm fine with that 
<hatch> bcsaller: I'm re-proposing right now with the test fixed and other code left the same - but we can definitely open up discussion later on
<hatch> or in a follow-up?
<bcsaller> yes, later is fine for the rest, the slots change doesn't belong in that branch at all and was just a possible cleanup
<hatch> alright - it's updated now
<sinzui> jujugui, orangesquad. http://staging.jujucharms.com is coming up.
<bac> yay
<jcsackett> sinzui: hoo-ray
<gary_poster> great sinzui!  is there anything we need to know to be able to have healthy use of canonistack for jujugui jenkins tests?
<sinzui> jujugui, orangesquad. anyone who wants to access the server will need to update their .ssh/config per the new lcy02 rules
<gary_poster> sinzui, ah! ok thanks.  we will need to do that fo jujugui then
<hatch> icy what?
<hatch> :)
<gary_poster> do you have alink for those, sinzui?
<bac> sinzui: if using sshebang it should just work
<bac> well, after pulling new one
<sinzui> bac, sshbang destroyed by last config I wont be using it.
<sinzui> It was easier to past the rule into my config.
<sinzui> https://pastebin.canonical.com/95172/
<hatch> ugh I can't get our make to use the npm cache on osx
<bac> sinzui: i have heard such stories.  i've been lucky, i guess (and backed up my config dir first)
<sinzui> Now I will return to nrpe in juju-gui. I am diligently avoiding the many levels of indirection used by other charms to make it work in prodstack
<sinzui> gary_poster, ^ my pastbin link was all that I need. just change the YOU part
<hatch> are the canonistack docs going to be updated with these details?
<hatch> s/docs/wiki
<gary_poster> thank you sinzui!
<hatch> benji: where did you happen to find the docs for npm install --cache-min ?
 * bac walks dog.  returns a sweaty mess.
<benji> hatch: https://npmjs.org/doc/config.html
<hatch> benji: so since it's no longer there am I to assume that it's no longer supported?
<benji> hatch: could be
<gary_poster> Makyo, LGTM with a lot of small-ish repetitive comments and requests
<hatch> benji: I'm just asking because on my desktop it doesn't appear to be working
<benji> it would be unfortunate for them to have removed it; maybe there is another way to achieve the same effect
<gary_poster> hatch how much work is #1206239? deciding how to triage
<_mup_> Bug #1206239: Router does not dispatch url hash changes <charmbrowser> <juju-gui:New> <https://launchpad.net/bugs/1206239>
<hatch> gary_poster: TWAG 1-1.5day
<gary_poster> ack thanks hatch
<Makyo> gary_poster, I don't necessarily see your point about before/after vs. after/afterEach.  Is the concern that the tests may modify flags?  Judging by the tests we have, an entire suite would need the flags.  However, I'm a solid 0 on that, so I can go ahead and move them to the *Each methods if you want :)
<hatch> benji: found it https://npmjs.org/doc/misc/npm-config.html#cache-min :)
<benji> good
<hatch> doesn't explain why it doesn't work haha
<gary_poster> Makyo, as a general rule, we want test isolation, not test suite isolation.  so, yes, in many cases, it seems tests are modifying flags.  That's step one in my argument: we actually need it there in some cases.  A second step is that this is the most paranoid, and the most likely-to-be-correct, place to reset flags generally.  The last step in my argument is that I'd rather have us follow the same rule every time, s
<gary_poster> o we get in a good habit. 
<Makyo> gary_poster, thus the disagreement with me removing the resetting flags in suites where neither the suite nor the code touch flags?  If that's the case, then -1 on setting window.flags to {} in index.html - it's pointless and offers a false sense of security.
<gary_poster> Makyo, it never had any security. I thought you were doing it so that tests read better, basically.
<Makyo> That does raise the question of when should we ever use before/after, but maybe that's a debate for another day :)
<gary_poster> Makyo, if the suite never touches flags, then that's just legacy
<gary_poster> fine with removing that
<gary_poster> if that's what some of those, were, sorry for the misunderstanding
<Makyo> gary_poster, misleading, then.  Putting it there gives a new test author the false sense of security that window.flags will always equal {} rather than undefined.
<gary_poster> ah.
<gary_poster> mm
<Makyo> gary_poster, they were legacy, yes, but it just sounds like we're arguing for putting that in every suite's *Each.
<gary_poster> Makyo, only if they use flags
<gary_poster> I'm not worried about it otherwise
<Makyo> gary_poster, Alright, sounds good!  The legacy ones will remain, but the others will be moved to *Each methods.  That closer to what you were asking?
<Makyo> Sorry.  Rephrase..
<Makyo> The diff on the legacy ones will remain: suites that don't use flags will no longer reference flags.
<gary_poster> yes, +1
<Makyo> Cool, on it.
<gary_poster> cool thanks Makyo
 * gary_poster running
<gary_poster> ttyl, guys!  have a great evening!
<hatch> you too
<hatch> *when lbox fails AFTER lbox.check*
<hatch> arg!
<hatch> 3rd time is the charm
<hatch> jujugui looking for some reviews on http://bazaar.launchpad.net/~hatch/juju-gui/remove-extra-buttons/revision/907 the codereview link is https://codereview.appspot.com/12071043 but it doesn't appear to have any diff
<hatch> jujugui ok the diff has appeared on https://codereview.appspot.com/12071043 for review
<huwshimi> Morning
<hatch> hey huwshimi, got a few things for ya
<hatch> s/things/tasks :)
<huwshimi> hatch: Hey
<hatch> huwshimi: I landed your branch with a few changes https://codereview.appspot.com/12054043
<hatch> in the description there are a couple outstanding issues
<hatch> I gota run for about an hour or so. I can answer any q's you have about those issues when I get back
<huwshimi> hatch: Thanks, just taking a look
#juju-gui 2013-07-30
<hatch> huwshimi: back - so any q's?
<huwshimi> hatch: Hey
<huwshimi> hatch: I was wondering why you removed the "Y.one('.left-breakout').addClass('with-charm');"
<hatch> I removed the style too and put the width on the container
<hatch> but the root of the reasoning is
<hatch> ...
<hatch> the 'render' method of the viewlet is responsible for generating it's own markup, not to influence things outside
<huwshimi> hatch: Ah, I see the width was cached, I just refreshed and it works now :)
<hatch> excellent :)
<jcastro> hey guys
<jcastro> I am having a hard time finding the URL for the juju-gui
<jcastro> https://jujucharms.com/charms/precise/juju-gui/ doesn't work
<bac> morning jcastro.  try http://manage.jujucharms.com/charms/precise/juju-gui
<jcastro> no I mean for normal people
<jcastro> like, the results from google URLs don't seem to work for me
<jcastro> https://jujucharms.com/precise/juju-gui-HEAD/ seems to work?
<jcastro> https://jujucharms.com/precise/juju-gui takes me to the wrong charm?
<bac> jcastro: yeah, you're right.  that last URL takes you to juju.  i wonder if there is an error in the parsing where the '-' is throwing it off
<rick_h> you always have to have a versio number
<rick_h> there's a bug in truncating juju-gui without a version number because it wants to think that juju is the charm with a version of -gui
<jcastro> every single URL I'm clicking from google is broken
<jcastro> if I can even find it
<jcastro> I still don't understand why we broke every single URL
<jcastro> I mentioned at least 1000000 times that we can't break URLs
<rick_h> because we didn't get around to fixing them all. 
<rick_h> we fixed most of them with redirects recently, this one didn't make it. It's still in the 'we need a url for HEAD and what's that to be' mode
<jcastro> I was assured over and over that these weren't going to break
<jcastro> and NOW if you search for any service + charm you can think of the #1 hit is github
<jcastro> except for wordpress, which returns the oneiric version the charm. :-/
<rick_h> yea, we've got a task to work on making the gui crawlable by google in a proper way but it's not been worked on
<rick_h> there's a bunch of work to try to make the JS driven site indexable
<jcastro> I am giving a class today for people to deploy the GUI
<jcastro> and I don't have a way to link to the instructions
<rick_h> https://jujucharms.com/fullscreen/precise/juju-gui-1/#readme
<frankban> rick_h: thanks for your review. IIUC you are suggesting to just add the is_subordinate field to the json file, correct?
<rick_h> frankban: correct, I know we were doing some ampping of that field but I think that was old charm model stuff
<rick_h> frankban: but for that kind of purpose. Just a sanity check that the json -> model is correct while it's doing this
<rick_h> frankban: the field should be in the current json, just has to be swapped to true vs false
<frankban> rick_h: aha!, so, rather than changing the charm attr, change the value in data before creating the charm, right?
<rick_h> frankban: correct, I think that's a slightly 'better' test in case something in the model/json changes
<frankban> rick_h: sounds good, thanks
<rick_h> but completely optional/suggestion
 * frankban lunches
<gary_poster> jcastro, (1) the link for the juju-gui readme is https://jujucharms.com/fullscreen/precise/juju-gui-head/#bws-readme . (2) we agree that the links were not handled well.  this was something I cared about a lot as well.  my take is that we did not clearly identify qa and acceptance tests as we should have, but ths is a discussion that the team will have.  we will talk about this friday as a failure that we need to im
<gary_poster> prove with process for the future.  we are fixing the links, and we fixed a large chunk of them last week.  (3) the search issue has been known for some time, and there's been a blueprint to fix it that was and is scheduled to be addressed in August.  https://blueprints.launchpad.net/juju-gui/+spec/servercloud-s-juju-gui-charmbrowser-search-rankings
<gary_poster> benji, any progress on #1206260?
<_mup_> Bug #1206260: GUI charm does not handle browser cache properly <juju-gui:In Progress by benji> <https://launchpad.net/bugs/1206260>
<benji> I'm redeploying now to try again
<gary_poster> benji ok.  using ~juju-gui-charmers this time?
<benji> yep
<gary_poster> cool thanks benji.
<benji> gary_poster: wait, let me verify: that is the one you get if you don't use a local charm, right?
<gary_poster> frankban something to consider with charm server is that we need to support upgrade
<gary_poster> benji, depends on how you deployed.  if you said juju deploy juju-gui you are fine. what deploy spelling did you use?
<benji> yep, that was it: "juju deploy juju-gui"
<gary_poster> benji, cool, s'good
<benji> k
<gary_poster> bcsaller, this is your London sprint spreadsheet reminder :-)
<jcastro> gary_poster: the thing is we already have google juice for the "pretty" URLs, the /charms/precise/wordpress ones
<gary_poster> jcastro, I've been checking.  we had (thought we had?) a fix for this deployed last Friday.  I'm looking at in in prodstack configs right now.  I'll ask curtis about it when he gets in (hopefully 17 minutes) and hopefully he can figure out what went wrong, and get it fixed very soon, possibly within the hour if we get IS attention/resources.
<rick_h> gary_poster: the /charms fix didn't go in because the apache rewrite rule would interfere with the jujugui routing
<rick_h> gary_poster: that fix has to be made to charmworld itself
<rick_h> to support the /charms route and lack of a version number
<gary_poster> rick, this one?
<gary_poster> RewriteRule ^/charms/(oneiric|precise|quantal|raring|saucy)/([^/-]+)$ /$1/$2-HEAD [L,R=301]
<rick_h> gary_poster: oh hmm, they had one more general than that I had thought. 
<rick_h> gary_poster: so nvm
<gary_poster> rick_h, cool, ack
<gary_poster> jcastro, rick_h the redirect is deployed.  it works great for wordpress and mysql (e.g. https://jujucharms.com/charms/precise/mysql and https://jujucharms.com/~hazmat/precise/mysql).  trailing slashes and hyphens confuse the redirect.  we will address.  But for now, this is only broken for charms that have hyphens in their names
<jcastro> gary_poster: I had checked last week too, it just wasn't until I tried to google the readme for the gui this morning when I realized I couldn't find it
<gary_poster> sorry hazmat :-P
<gary_poster> jcastro, yup, hyphen
<gary_poster> apache redirects are great for bandaids but are not conducive to automated tests
<rick_h> gary_poster: ah, makes ense. the rule has ([^/-]+) 
<frankban> gary_poster: morning. re charm server and upgrade, do you mean changing the gui source option or upgrading the charm? how do we want to handle that?
<gary_poster> rick_h, yup.  we need to add a /? at the end and figure out a lookahead way to spell "not -\d+"
<rick_h> gary_poster: yea, was just thinking on that and my brain started hurting with lookaheads :)
<gary_poster> frankban, upgrading the charm.  changing the gui source is the same as always, I'd guess.
<rick_h> jujugui tiny review plaese for bug #1202636 https://codereview.appspot.com/12102043
<_mup_> Bug #1202636: Charm Details Page Under Providers Change Openstack to HP Cloud <juju-gui:Triaged> <https://launchpad.net/bugs/1202636>
<bac> rick_h: ok
<rick_h> thanks bac
<gary_poster> frankban, so, if someone upgrades from a charm pre-our-server then everything should still work hen they go from apache to tornado.
<gary_poster> frankban, important for jujucharms.com
<gary_poster> and for long-running gui charms
<gary_poster> rick_h, I looked and code looked good.  however was worried: test and code showed openstack + hp, but that's not what we are seeing in actual app.  any idea why?
<frankban> gary_poster: ack. so we will need extra-care when switching from the legacy servers to the experimental one
<gary_poster> rick_h, sorry I meant in the branch before your changes
<gary_poster> frankban, exactly
<bac> rick_h: code looks good.  i did not QA
<rick_h> gary_poster: sorry, which test?
<rick_h> gary_poster: not following. before my changes we showed both openstack and hp? That's correct. That's what we were doing. If openstack tests failed we showed the user that both openstack and HP would not work. 
<rick_h> gary_poster: now the user will never see 'openstack' in any provider info. 
<gary_poster> rick_h, if I go to https://jujucharms.com/precise/glance-18/
<gary_poster> I only see openstack
<gary_poster> not hp
<gary_poster> that's my concern rick_h 
<rick_h> gary_poster: ah, that's because there was a bug from when huw redid to show passing providers
<rick_h> the code previously only showed failing providers
<rick_h> so the hack to 'make openstack mean both hp and openstack' was only in the model code for failing cases
<rick_h> gary_poster: that's part of my branch to make it consistent on both passing/failing
<rick_h> gary_poster: peek at https://codereview.appspot.com/12102043/patch/1/1004 and notice that only the !== SUCCESS did the openstack check before
<gary_poster> rick_h, cool thanks.  will make trivial suggestion but otherwise cool
<gary_poster> yeah saw thanks
<rick_h> gary_poster: rgr, thanks
<benji> gary_poster: I have reproduced the cache problem and at first blush it looks like the problem simply is that we do not provide any cache control at all.
<gary_poster> benji, duped: great!! no cache control: I thought we had ETags?
<gary_poster> I saw them
<rick_h> are they just timestamp generated by something in the stack and not actually content generated?
<gary_poster> we have ETags in the apache charm config, pretty sure
<benji> gary_poster: we have etags, but I don't think they imply a cache directive.
<gary_poster> benji ok.  sounds like an easy fix then, as I had hoped.  yay!  thanks
<gary_poster> rick_h, doing qa now
<benji> gary_poster: I propose we add no-cache headers to the world; shall I create a branch to do so?  How will that interact with the new server?
<gary_poster> benji, how does a no-cache header interact with etags?  I want files to be cached but I'm ok with ETag checks.
<gary_poster> benji, branch: yes.
<benji> no-cache means not to ever cache :)
<gary_poster> benji, I thought so.  don't want that if we can help it.
<gary_poster> benji, new server: let frankban know what we settle on here so he can mimic
<benji> gary_poster: we can add a must-revalidate instead which I am pretty sure will give us the desired effect now, but I don't know how much work it will take to support in the new server
<gary_poster> benji, I know ETags are essentially free in new server
<frankban> gary_poster, benji: that's also my understanding
<gary_poster> benji, +1 on must-revalidate.  should we test for downsides, or consider any?
<benji> other than testing to see if it works as expected, I can't think of anything.  I'll do a little research.
<gary_poster> rick_h, qa bad.  getting you details and suggestions.
<gary_poster> benji, perfect thanks!
<rick_h> gary_poster: ok, thanks for the catch. 
<benji> btw: a no-cache across the board doesn't look that bad; we load all resources while the WS is connecting, which takes so long that everything is loaded by the time we connect to the environment (on chrome, on my machine, with an empty cache at least)
<rick_h> the problem there is users on slower bandwidth. I demo'd jujucharms.com from a coffee shop and it hung for a nice time. 
<gary_poster> benji, also there is no WS on jujucharms.com
<rick_h> I thought it was broken at first it was so much slower
<benji> hmm, we might want to have a card about evaluating low bandwidth (or more likely high latency) performance
<gary_poster> benji, +1
<benji> I'll add one.
<gary_poster> benji, thanks.  meanwhile, let's keep our cache!  we have some relatively big files
<benji> k
<gary_poster> rick_h, gave you details in review.  the changes I give in diff fix qa exprience but, as I'm sure you'll see, will certainly break tests
<gary_poster> rick_h, feel free to discard, as I said
<rick_h> ah, the links. Doh, and I knew the mismatch would bite us on the back side. 
<rick_h> gary_poster: thanks, I did a similiar thing just now with the filters as I had msised that those would need to be updated.
<gary_poster> rick_h, ah cool
<rick_h> keep forgetting they're still there :/
<sinzui> abentley, bac: I need a mid-implementation review of nagios branch. I'd like some direction about the nagios checks and tests: https://code.launchpad.net/~sinzui/charms/precise/juju-gui/nagios/+merge/177588
<bac> sinzui: ok
<sinzui> bac: if you are not familiar with the nagos situation in prodstack, be prepared for a shock
<bac> sinzui: i know only what you described in raleigh.
 * bac dons helmet
<gary_poster> sinzui, we need to adjust our jujucharms redirect regex, ideally this morning--so, asap, but not unduly interrupting anything.  lemme know when you are available to discuss
<sinzui> gary_poster, I expect to be free in 45 minutes. I foresee any issues updating apache. We just need to know the rules to verify locally and in production
<gary_poster> sinzui, cool.  working on them and will give them to you for verification.  thanks
<sinzui> I don't foresee an issues I mean
<hatch> morning all, still lf 2 reviews https://codereview.appspot.com/12071043/
<gary_poster> hatch,  morning, was looking at that back ages ago :-P sorry.  best to find someone else now--booked for next 2.5 hours
<hatch> no problem :)
<gary_poster> sinzui, I have a call now, so I will describe problem here so you can look at it.  charm names with hyphens do not work properly with the current redirect rules.  this breaks the juju-gui redirect, for instance.  Also, charm names with trailing slashes do not work, but these do not work in m.j.c so less of a priority.  Examples of urls:
<gary_poster> https://jujucharms.com/charms/precise/juju-gui
<gary_poster> https://jujucharms.com/~juju-gui/precise/juju-gui
<gary_poster> https://jujucharms.com/charms/precise/wordpress/
<gary_poster> we will need a lookahead assertion for the first problem
<gary_poster> this seems to work for me:
<gary_poster> re.match(r'^/charms/(oneiric|precise|quantal|raring|saucy)/((?![^/]+-(\d+|head|HEAD)/?$)[^/]+)/?$', '/charms/precise/juju-head-57/')
<gary_poster> I tested that with a variety of options.
<gary_poster> I think it might mess up the $3 though
<sinzui> thank you gary_poster
<gary_poster> thanks sinzui!
<gary_poster> re.match(r'^/charms/(oneiric|precise|quantal|raring|saucy)/((?![^/]+-(?:\d+|head|HEAD)/?$)[^/]+)/?$', '/charms/precise/juju-gui/') better for groups fwiw
<rick_h> gary_poster: bac updated the branch per the QA issue gary brought up. Redid the solution a bit. It's both simpler and more complex. https://codereview.appspot.com/12102043 
<rick_h> appreciate another look when you get time.
<hatch> so I was looking at some of the juju-core code - can you not run Go statements on multiple lines? 8 space indentations?
<gary_poster> rick_h, if you can get someone else would be great.  busy for 2 hours
<rick_h> hatch: care to swap some review time please? ^^
<rick_h> hatch: see the history as gary brought up some issues on the first go-round
<hatch> mine is shorter - you have to do mine twice
<hatch> :P
<rick_h> hah!
<BradCrittenden> sinzui: where is check_ingest.sh?  or is such a check the thing you'd like to discuss?
<rick_h> hatch: link me up 
<hatch> https://codereview.appspot.com/12071043/
<rick_h> old chunk mismatch? boooo now you owe me back since mine at least loads :P
<hatch> lol
<hatch> rick_h: little odd that openstack == hp no?
<rick_h> hatch: no, we run charm tests against three platforms. lxc, ec2, hp cloud. hp cloud is called 'openstack' in testing because that's what hp cloud is running.
<hatch> ohh and ec2 doesn't run openstack?
<hatch> i thought they did
<rick_h> no
<hatch> they must run closedstack
<hatch> it's closed source brother
<abentley> benji: Morning.
<benji> good morning
<hatch> man I really wish npm cache worked on my desktop
<hatch> make takes for friggen everrrrrrrrrr
<abentley> benji: re: https://code.launchpad.net/~benji/charmworld/bundle-indexing/+merge/176956 you don't need more than one "approve vote".  Those rejections about unapproved revisions were about the "Approved revision", which is set by twiddling "Status".
<benji> hatch: have you tried setting it globally: npm set cache-min=9999999
<hatch> benji: I can try
<benji> abentley: good to know; I was very tired of fighting the bot there
<hatch> benji: still no luck :(
<abentley> benji: It kinda looked that way ;-)
<benji> :)
<bac> hey rick_h, in the template you call like {{prettyProvider . }} -- how's that work?  '.' is passed as the id?
<rick_h> bac: yea, it's the current scope atm. You'll see that the before was that already. 
<rick_h> . == current scoped object which is the provider 
<benji> hatch: you might look at the results of "npm config list" and see if there is anything odd there
<hatch> yeah nothing out of the ordinary there either
<hatch> rick_h: so as long as the providers show up with proper names and are clickable that's a successful QA?
<rick_h> hatch: yes, the failing qa last time was the broken links on the provider names
<rick_h> hatch: in qa'ing your branch clicking cancel still puts a service icon on the canvas?
<hatch> sure it's still not a ghost?
<rick_h> hatch: but it does that on jujucharms.com so LGTM'ing it I guess. Known bug?
<rick_h> hatch: yea, but I'd expect a clean canvas as it works now w/o the inspector flag
<bac> rick_h: sorry, i got dropped out of irc after asking that question.  if you'd answered please do so again
<rick_h> bac:  . == current scoped object which is the provider
<hatch> rick_h: yeah it's still a ghost - there will be a 'destroy' button on here somewhere to remove it
<rick_h> bac: there's some notes on scope in the handlebars docs http://handlebarsjs.com/ search for 'scope'
<bac> cool
<rick_h> hatch: but why is it there anyway? I cancled the deploy?
<rick_h> bac: I'm not a fan of using . but just kept it since it was used there already
<rick_h> the UX makes no sense to me hatch especially when it's a change from non-inspector behavior
<hatch> rick_h: ahh according to the wireframe 'cancel' should read 'save'
<hatch> see V11
<rick_h> hatch: huh? drag a charm to my canvas and get save/confirm?
<hatch> save/next
<rick_h> wtf does save/next mean on a deploy step. now I'm really confused
<hatch> although that section has changed in almost every revision of the mockups so who knows what it'll be in the end
<rick_h> ok, well LGTM'd and noted with a wtf carry on :)
<hatch> :)
<hatch> yours as well
<abentley> sinzui: I'm thinking maybe we should disable dynamic mappings for elasticsearch.  Since we specify which fields to search on, indexing an unexpected field does us no good (unless we later decide to expect it).  And it could seriously simplify our mapping (currently 457K, pretty-printed).
<sinzui> abentley, +1
<adeuring> sinzui, abentley I added a comment to bug 1199780 -- could you tell me your opinion?
<_mup_> Bug #1199780: search requests errors when a charm has no last_change <charmworld:Triaged> <https://launchpad.net/bugs/1199780>
<sinzui> jcsackett, hangout?
<jcsackett> sinzui: invite on the way.
<gary_poster> jujugui will come by bundle call asap.  almost done
<bac> sinzui, abentley: coming to bundle call now?
<abentley> bac: Trying.  Google hangouts wants me to install the latest version of the plugin.
<hatch> is this in guichat?
<Makyo> hatch, oops, didn't see your review on Huw's branch.  3 LGTMs is better than 2, I guess.  gary_poster, want me to land that?
<gary_poster> Makyo, +1 thank you
<hatch> already landing
<hatch> Makyo: gary_poster
<Makyo> Oh
<hatch> in fact....it's landed
<Makyo> Good luck.  We're all counting on you.
<Makyo> \o/
<hatch> lbox submit -v -adopt
<hatch> awww yeah
 * hatch read the help file
<Makyo> Haha
 * hatch pokes his head in all of the offices trying to find the deployer hangout
<Makyo> hatch, wasn't it part of the invite?
<Makyo> https://plus.google.com/hangouts/_/calendar/Z2FyeS5wb3N0ZXJAY2Fub25pY2FsLmNvbQ.ckc3m4182f9qqffjqh2p259d6k?authuser=1
<sinzui> bac, sorry, 1 script, 2 names. I need to delete/replace one of the scripts. either the hook or the file in scripts
<Makyo> hatch ^^^
<hatch> thanks
<hatch> jujugui - lf one more review https://codereview.appspot.com/12071043/
<hatch> rick_h: fyi - I'm working on the destroying the ghost part now
<rick_h> hatch: all good
<Makyo> jujugui one more review, please https://codereview.appspot.com/12060044/ Mostly mechanical/policy wrt flags in tests
<rick_h> Makyo: looking
<Makyo> rick_h, thanks.
<hatch> Makyo: while you're waiting you can review mine :)
<rick_h> Makyo: card?
 * rick_h is trying to be a good card tagger
<Makyo> rick_h, Down in slack, help tests run in isolation.
<alove> Experiencing problems installing juju-gui charm (unit.hook.api INFO: Retrieving Juju GUI release). Get connection timeout to Launchpad
<rick_h> Makyo: ah, cool to drag to review then?
<Makyo> rick_h, oh, yeah, sorry!
<Makyo> jujugui ^^^  Is there a way to get that to run again?  Maybe upgrade-charm?
<alove> will try. using juju v0.7 if that makes a difference. couldn't get juju-core to work (CA certificate error).
<alove> when issuing any juju command
<alove> Is there only a cs:precise/juju-gui charm?
<Makyo> alove, that's the promulgated one, yes.
<alove> ok. will continue to try with that one.
<rick_h> Makyo: what was the aversion to after() reasoning? 
<rick_h> I see comments asking for it but I'm not seeing the thought behind it. 
<Makyo> alove, you can juju set juju-gui-source=0.8.1 to try to get the GUI release again.
<alove> Makyo, thanks for the config tip
<Makyo> rick_h, my understanding was that it maintains hygiene between tests, rather than just between suites.
<rick_h> Makyo: yea, the hygiene phrasing I don't follow I guess. We don't reset namespaces or modules/etc. 
<rick_h> Makyo: but cool, just curious
<Makyo> rick_h, yeah, I'm curious about that as well, added a card for discussion, 
<rick_h> ah cool
<Makyo> jujugui call in 10 kanban now
<Makyo> hatch, lgtmd
<Makyo> Which sounds like a service.  sudo service lgtmd restart
<hatch> typical unix name
<hatch> abreviate all the things!
<hatch> jujugui guichat in 3
<Makyo> LGTMSE~1.EXE?
<hatch> ohhh DOS
<hatch> file to long...I'll just truncate it for you mkay?
<hatch> I suppose that's better than linux alowing you to rename files to an empty tring lol
<hatch> jujugui guichat call now
<gary_poster> hazmat we need your yaml fix landed today.  want us to do last changes and land it for you?
<alove> Makyo, Done - juju set juju-gui juju-gui-source=0.8.1
<alove> foloowed by - juju upgrade-charm juju-gui
<Makyo> alove, did that work this time?  No LP troubles?
<alove> got - ERROR Charm 'cs:precise/juju-gui-68' is the latest revision known
<Makyo> alove, okay.  The second step doesn't sound like it'll be necessary in the future, since you're already up to date.  Did the config changed hook work
<Makyo> ?
<alove> Makyo, yes. when I do a juju get juju-gui I see  value: 0.8.1
<gary_poster> jcastro, you around?
<hatch> frankban: is that your typical daily view? out that big window?
<Makyo> alove, alright.  Does juju status still show the unit in error?
<frankban> hatch: no, I am not in the usual place
<hazmat> gary_poster, working on it now
<alove> Makyo, yes. agent-state: install-error
<gary_poster> hazmat, awesome thanks
<hatch> frankban: ahh too bad, looks like it's a nice view....
<frankban> hatch: indeed!
<jcastro> gary_poster: yo
<gary_poster> jcastro, hey can you join http://tinyurl.com/guichat for 5 min or less?
<jcastro> yeah
<gary_poster> jcastro about all category
<gary_poster> thanks
<adeuring> sinzui: when/where is the ornage call?
<jcsackett> adeuring: not sure about where, but when is after rick_h finishes his call, i think.
<adeuring> ok
<alove> Makyo: Just some context. Running MAAS master on Raring, Juju boostrap unit on Raring, Juju-gui unit on Precise. Juju 0.7
<Makyo> alove, I think you should be able to retry the failed hook with juju resolved --retry juju-gui/0
<Makyo> jujugui please check me on this.
<hatch> jcsackett: to QA this branch everything should appear to work as normal?
<sinzui> adeuring, https://plus.google.com/hangouts/_/614754f01c23d91c52a3c1bfea258b7f9f8fdc0d?hl=en
<gary_poster> Makyo, alove yes that would retry.  however, alove it sounds like you are working behand a firewall?
<gary_poster> behind
<jcastro> hey rick_h or gary
<gary_poster> jcastro, yo
<jcastro> those URL rewrites, those are 301 redirects?
<gary_poster> jcastro,  yes.
<alove> gary_poster: I am behind FW however have installed packages on juju-gui unit manually from repos successfully. Doing a netstat I can see tcp        0      1 192-168-56-101.clouddomain:52515 launchpad-net.nutmeg.canonical.com:https SYN_SENT
<gary_poster> alove, yeah that looks like the problem.  you need to get the GUI tarball someplace that MAAS can reach it.  Here's one approach:
<gary_poster> 1) download tarball from https://launchpad.net/juju-gui/stable/0.8.1/+download/juju-gui-0.8.1.tgz to somewhere
<gary_poster> 2) put it somewhere on your network that your MAAS cluster can connect to
<gary_poster> that needs to be either accessible via a http or file
<gary_poster> so
<gary_poster> you could put it on the filesystem of the GUI service
<gary_poster> or you could put it somewhere with a static server accessible
<gary_poster> 3) if you used a url, "juju set juju-gui-soure=url:http://PATH TO TARBALL"
<gary_poster> if you used a file, change that to url:file:///PATH
<gary_poster> 4) do that retry Makyo gave you ("juju resolved --retry juju-gui/0")
<gary_poster> That should do the trick, if everything is connected properly
<gary_poster> alove, ^^^ done
<alove> gary_poster: Many thanks. I'll give that a go now using the filesystem method.
<Makyo> gary_poster, should I do a quick docs branch with that?
<gary_poster> alove, cool.  that should have been "juju-gui-source" not "juju-gui-soure"
<gary_poster> typo, sorry
<alove> np
<gary_poster> Makyo, yes, thank you.  Maybe we should bite the bullet and stick the GUI in the charm too :-/
<gary_poster> as the default source
<gary_poster> for these firewall situations
<Makyo> gary_poster, maybe when we hit 1.0?
<Makyo> Yeah
<gary_poster> Makyo, yeah, maybe so
<benji> gary_poster: I've verified that my tweaked charm correctly sends new css/js after an upgrade and it also sends 304 Not Modifieds when no upgrade has happened since the last browser request
<gary_poster> benji, yay, thanks!
<benji> we should have some sort of test to enforce this behavior, but I think I can add that to the charm tests pretty easily (especially considering that we're changing servers and my change is an Apache config tweak)
<jcsackett> hatch: sorry for delay, was OTP. yes, everything should work as before, and should work in rapi mode as well.
<gary_poster> benji, that would be great thanks
<gary_poster> benji, are you happy with this cache behavior as a sane choice?
<benji> gary_poster: yep, it should work very well; I am worried about the non-gui servers we depend on though; I believe they do not behave well (jujucharms.com, for example)
<gary_poster> benji, how so?  you are afraid that they will mess up our cache headers?
<gary_poster> benji fwiw, we still use our charm's apache, but it is fronted with another apache that provides the https
<gary_poster> on jujucharms
<benji> nope, I'm afraid their headers have the same problem as ours and changes, to e.g., default and category icons, won't be reflected in the gui
<gary_poster> benji, oh! I see, you meant manage.jujucharms.com
<benji> oh, right
<benji> and it wouldn't be the category and default icons it would be the charm icons
<gary_poster> benji, ack, I will add card.  actually both are pertinent: we changed default icons too lately (added color)
<alove> gary_poster: you are a star ... install is now progressing to retrieve Juju API source checkout ... but may have similar problem
<gary_poster> alove, yay!  but yes, may be an issue.  That's PyJuju, not Juju Core. :-/ um.  lemme know if it does turn out badly and I'll think about it then :-)
<alove> gary_poster: yep, same timeout problem
<gary_poster> ack, 1 sec
<gary_poster> ok, looking
<gary_poster> um
<rick_h> gary_poster: sinzui highest priority todo from here? some url cleaning? mjc download numbers? the routing querystring dumping bug? remove filters from the UX?
<gary_poster> alove soory, can pay attention after another 5
<gary_poster> sinzui, if you have suggestion for rick_h, +1.  otherwise CSS transitions would have big bang for buck for upcoming demo
<alove> no problem, appreciate any help but don't worry if you're focused elsewhere.
<gary_poster> rick_h, can help with desc later
<gary_poster> alove, four options, none of them particularly attractive. (1) use bzr to branch lp:~hazmat/juju/rapi-rollup locally ("bzr branch lp:~hazmat/juju/rapi-rollup") and copy directory on the gui service machine; "juju set juju-gui juju-api-branch=PATH_TO_LOCAL_BZR_BRANCH"
<gary_poster> (that's the best one; the rest get bad very fast :-P )
<gary_poster> 2) switch to juju core
<gary_poster> 3) ...I forgot...
<gary_poster> 4) hack charm to make it so that you can have the source embedded and give us the diff :-)
<gary_poster> rick_h, are you good on goals?  can talk through those.  then going to go get some lunch and talk a walk :-)
 * gary_poster hungry.
<gary_poster> biab: walk and lunch
<rick_h> gary_poster: I'm goign to grab food as well. Ping me when you get a sec then as I thought huw was doing animations and had some WiP. Happy to help move that forward though. 
<alove> gary_poster: I'll try 1) ... tomorrow. Bailing out now (UK!). Thanks to you and Makyo.
<alove> quit
<Makyo> jujugui docs update for charm re: discussion with alove https://codereview.appspot.com/12120043
<hatch> gary_poster: we should get some of these for when people can't join us for the sprints http://romotive.com/
<hatch> when a ghost is destroyed should we throw up a confirmation?
<jcsackett> hatch: i don't think so--the ghost disappearing from the canvas should be sufficient, don't you think?
<hatch> my concern is that you go to click 'save' and accidentilly hit 'destroy service'
<hatch> after you have spent x time setting your config
<hatch> but the ux puts the 'are you sure' message at the top of the inspector...
<hatch> the complete opposite side of the button
<hatch> fyi node-inspector has new authors and is now being updated again https://github.com/node-inspector/node-inspector yay!
<rick_h> hatch: ah, that's cool. Using chrome remote debugging to hook into a node script?
<hatch> yup it's been stagnant for so long
<hatch> finally been picked up again
<hatch> I think I'm going to take some developer license and make my own confirmation popup
<hatch> maybe that should be in a follow-up though
<hatch> yeah
<hatch> oh we have a destroy template already
<hatch> maybe I'l use that
<gary_poster> hatch, romotive, heh +1
<rick_h> I talked with a guy at PyOhio that worked for bump and they got him a tele-robot for a few months to try out. 
<rick_h> said it was more akward than anything, ended up sending it back
<gary_poster> rick_h, maybe you are right about transitions.  hatch, was Huw going to go back to transitions after you talked with him, or is that something for someone else now?  I thought it was for someone else
<rick_h> gary_poster: yea, I've been hunting for some docs on animations and coming up empty. I know hatch and I had a chat at one point regarding huw's work on them and a demo someone else had. 
<hatch> gary_poster: for someone else to tackle - it will require markup/styling/scripting changes to how the browser functions to achieve the desired effect that UX wants cc/ rick_h
<rick_h> maybe my google-doc-fu is weak 
<gary_poster> rick_h, I just think it would be funny :-P .  no guidance on practical
<gary_poster> rick_h, ack.  looking for firefox demo
<gary_poster> rick_h, https://dl.dropboxusercontent.com/u/10004366/juju-gui/index.html# has annimations
<gary_poster> -n
<rick_h> loading
<gary_poster> rick_h, animations include:
<gary_poster> - hovering over tab
<gary_poster> - clicking on tab (in both sidebar and sidebar + charm positions)
<rick_h> hmm, no worky here
<gary_poster> rick_h, FF only
<rick_h> ah, the mixed content was blocked so FF didn't load it
<gary_poster> - clicking on charm (opens charm panel)
<gary_poster> - orange bar slide (build/browse)
<gary_poster> note that the orange bar slide is also used in the inspector so building that one generically would be nice
<gary_poster> espcially because browse/build might die :-P
<rick_h> ah, ok
<gary_poster> rick_h, hatch might have more insight.  also if this is not interesting, tell me so.  plenty of other things to do
<rick_h> gary_poster: it's cool, just peeking over demo. 
<gary_poster> rick_h, great
<rick_h> gary_poster: ok to land incrementally? 
<hatch> the cool thing about the tabbed slide results is that we can get rid of that tabview....mohohahahaha
 * hatch ducks
<rick_h> tabbed slide?
<gary_poster> rick_h, big +1 on incrementally
<rick_h> gary_poster: k cool then
<rick_h> hatch: shush
<rick_h> gary_poster: I would like to bring up hatch's concerns on that tab vs the previous policies of making the tabs url/direct loadable
<rick_h> as it's costing us in maint. time/effort a bunch lately 
<rick_h> and wondering how worth it it really is 
 * rick_h needs to find a way to avoid 'it it' in the future
<gary_poster> heh
<gary_poster> rick_h, unclear on what you are advocating discarding
<rick_h> right now when you click a tab in charm details the url adds the hash attribute #bws-readme
<rick_h> that's caused us to complicate routing and this back button behavior bug that hatch filed
<rick_h> we're trying to do two different things. On one hand, each tab is it's own url/resource. On the other, we want to back button and not treat it as so. 
<rick_h> and now we have to kill that feature in the shared code in the inspector charm details
<rick_h> the 'work arounds' are adding up and I wanted to see if we could sit down at some point and re-evaluate it.
<gary_poster> "we want to back button and not treat it as so": you mean we don't want to back button across tabs?
<gary_poster> I would guess we do
<rick_h> gary_poster: correct
<hatch> I'll be available for a chat whenever if you guys want to discuss
<rick_h> and we don't want it on the inspector version 
<gary_poster> well, the inspector simply can't mutate the url; I'd argue that's a reasonable difference.  but...why did we decide that tabs should not participate in back-arrow?  FWIW, here's my expected behavior:
<gary_poster> each tab is another url, with an actual url element
<gary_poster> they are handled as usual in both back arrow history and everywhere else.  so "/bws_readme" not "#bws_readme"
<gary_poster> to be clear,
<gary_poster> I'm not saying that we have to do that now
<rick_h> gary_poster: ok cool
<gary_poster> but if doing that is as easy as other options then that would be great
<gary_poster> IIUC,
<rick_h> well the animatino for the tabs would involve getting dirty in that code
<rick_h> which is why I bring it up 
<rick_h> because we'd probably ditch the YUI TabView we're using and go another route. 
<hatch> it'll be 100x easier without that tabview
<rick_h> right
<hatch> it's just not built for that interaction
<gary_poster> is the tabview buying us much? relatedly, will replacing it be expensive?
<rick_h> agreed, ok. Well that helps clear it up. hatch can you update your bug with those notes then? More that tabs should be /tabname vs #tabname and not about back button?
<rick_h> gary_poster: well it's doing the 'fold content into tab defined, click, fire event on change' stuff for them. 
<rick_h> gary_poster: so it'd have to be replaced with some sort of more carousel-like widget with the animations but same click/change of display events we use for tabs.
<gary_poster> rick_h, ack. that sounds pretty basic on the face of it
<gary_poster> ?
<rick_h> gary_poster: sure thing. We actually had a carousel widget we dropped at the start of the project we could start with. 
<rick_h> but ok cool, hatch updates his bug, I'll start poking at the animations. Thanks for the walk through. 
<rick_h> and the animations demo works under chrome once you ditch https on the demo url :)
<jcsackett> hurray, the carousel we worked on might not be useless after all.
<rick_h> jcsackett: woot, now to find it :/
<gary_poster> rick_h, ok, thanks.  go for relatively quick wins--if something looks doable in a day (start to land), it's worth it.  Otherwise, if something looks not quick, hold off, and maybe file a bug with details?
<hatch> jujugui does anyone know how I access topology ServiceModule methods from app.views.environment.instance.topo ?
<rick_h> gary_poster: rgr
<gary_poster> hatch, I believe's bcsaller's intent is events, or refactor
<bcsaller> hatch:  what are you trying to do?
<Makyo> hatch, events.
<hatch> HULK SAYS EVENTS BAD!
<gary_poster> lol
<hatch> ok but for real :)
<Makyo> Oh for Pete's sake.
<Makyo> Events.
<rick_h> hatch: shush with your lies
<hatch> the serviceInspector destroy service needs to hide the service context menu in the environment
<gary_poster> Pete's my neighbor.  he's a history teacher.  He likes events.
<rick_h> events good! just need to use events responsibly
<Makyo> hatch, fire the clear events.  Just a sec, Ill get the spe
<Makyo> c
<rick_h> hatch: so who's above both the serviceInspector and the context menu?
<rick_h> it's his job to handle it
<Makyo> clearState
<hatch> there is clearState
<hatch> ahh :)
<hatch> so fire that from topo?
<Makyo> Yep
<hatch> werd
<hatch> sawlid
<Makyo> Choice.
<hatch> way to proper
<Makyo> Tops.
<hatch> choice
<hatch> no caps, no period
<hatch> tops lol
<Makyo> Nah, pass.
<Makyo> I just really, really like my shift key :)
 * rick_h shakes head at oddness of canadians
<rick_h> hatch: but when I was getting my car worked on in canada I got to watch canadian news and saw some singer didn't want to tribute your area man
<hatch> oh yeah don't even get me started on that
<rick_h> hatch: I yelled at the TV "Hey, I've heard of that sack-a-toon place before!"
<Makyo> Hahahah
<hatch> I only have expletives and derogatory comments to say about her
<rick_h> and canadian news should stop hiring so many vampires for their broadcasts. It was spooky
<hatch> you were probably watching east coast news
<rick_h> CBC
<rick_h> ?
<hatch> national?
<rick_h> yea, think it was national CBC. They did weather coast to coast
 * rick_h was there a while 
<hatch> ahh yeah I think that's broadcast from Toronto
<rick_h> they were talking about "The premiers on lake on niagra" and I thought they were talking about a mo-town band
<hatch> lol
<rick_h> ends up you guys have "The Premiers"...who knew?
<hatch> shit now you got me all riled up about her
<hatch> haha u suck
<rick_h> lol
<rick_h> if it makes you feel better I thought they were talking about a "He". Can't recall the name
<hatch> http://www.torontosun.com/2013/07/26/joni-mitchell-calls-saskatoon-bigoted
<gary_poster> Makyo, LGTM doc branch with comments.  I say review my changes, adjust as desired, and land.
<Makyo> gary_poster, cool, thanks.
<gary_poster> bcsaller, hey. sorry for bugging you on the London flight, but we are near deadline.  you on that for today?
<bcsaller> yeah, I'll finish that up today
<abentley> sinzui: chat?
<gary_poster> thanks
<sinzui> abentley, sure
<abentley> sinzui: https://plus.google.com/hangouts/_/60b018b674fa86d972e739a8ffd245d09b882bbf?hl=en-GB
<hatch> Makyo: bcsaller so the linter doesn't like me using app.views.environment.... from the inspector or from service.js because app isn't defined meaning I have to do a hack like `var app = app;` any ideas of non hacky workarounds?
<bcsaller> you pass it down either the method you need or the object
<Makyo> hatch, bcsaller +1  app being global is a hack for debugging that we should, frankly, get rid of.  Ditto yui, I think.
<hatch> well we should keep it for debugging heh
<hatch> ok can do that
<Makyo> Well, alrght.  I think it's easier to debug in the standard breakpoint/callstack way, but that's me, maybe it's easier to have that around for debugging.
<hatch> hmm nowhere that creates this stuff has easy access to the various components either
<hatch> pooey
<bcsaller> what is the object that needs access to the topo, its not created under the env view?
<hatch> I'm pretty sure I have it
<hatch> I just like to blab
<hatch> ok so there is one issue
<benji> these charm tests sure do take a while to run
<sinzui> gary_poster, the redirects are live
<gary_poster> awesome, thanks sinzui!  what did you add?
<sinzui> gary_poster, this MP has the links we checked https://code.launchpad.net/~sinzui/canonical-is-charm-configs/hyphened-charm-redirects/+merge/177665
<sinzui> gary_poster, your re + a variant to support users.
<gary_poster> cool sinzui.  the last 2 examples from qa list are not working for me.  Trying all...
<gary_poster> sinzui, yeah they all work except for last two
<gary_poster> do you see the same?
<sinzui> I got a redirect for both
<sinzui> I was directed to https://jujucharms.com/precise/juju-gui-HEAD/
<gary_poster> sinzui, confirmed, thanks!  I think I was hitting the cacheing bug that benji is fixing.
<gary_poster> I just had to reload
<sinzui> :)
<gary_poster> sinzui, I saw https://rt.admin.canonical.com/Ticket/Display.html?id=63590 .  is this a big problem or a quick fix or we don't know yet?
<hatch> gary_poster: can you pull my branch down and create/delete some ghosts/services to see if you agree with my engineering-license wrt the destroy service alerts lp:~hatch/juju-gui/deletable-ghost
<gary_poster> lol yes hatch on it
<hatch> :) thanks
<gary_poster> hatch +1 pretty scroll.  I don't care for the UX they gave for this but let's run with it for now and see where it goes.
<gary_poster> thank you!
<gary_poster> s/scroll/animation/
<hatch> excellent thanks - I'll now fix the tests
<hatch> and propose
<sinzui> gary_poster, I have a fix, but it introduces a fault I need to chase down
<gary_poster> sinzui, ack.  would be curious about details sometime.  maybe discuss at IoM.
<sinzui> gary_poster, This is the my MP with with m_3's report of failure: https://code.launchpad.net/~sinzui/charms/precise/mongodb/restore-from-dump/+merge/165408
<gary_poster> sinzui, :-/ gotcha
 * hatch lunching
<gary_poster> bcsaller, my EoD is coming soon.  lest I forget, if you get the conflict resolution code landed today, could you send an email to Huw to get him to style it?
<bcsaller> yes, I will do that 
<gary_poster> bcsaller, alternatively, if it is not landed but you don't expect big changes, you could send him the branch
<gary_poster> cool tjank you
<gary_poster> thank
<bcsaller> thanks
<hatch> jujugui Looking for two reviews and a QA on https://codereview.appspot.com/12050049 plz and thanks
<hatch> Bueller..........Bueller......
<bcsaller> hatch: taking a look now
<hatch> :D thanks
<huwshimi> Morning
<hatch> morning huwshimi
<hatch> I landed your branch this morning
<huwshimi> hatch: Oh thanks
#juju-gui 2013-07-31
<gary_poster> hatch you still around?  should I bother with a review?
<gary_poster> hatch gave you a quick LGTM with small comment anyway. :-) thx
<gary_poster> night
<gary_poster> all
<benji> frankban: have you succesfully run the charm functional tests recently?  I can't get past "agent-state: pending" 
<frankban> benji: no, not recently, maybe teknico run them for his last branch?
<frankban> benji: are you using pyjuju? if so, you can try to run them with juju-core. what's the status of the juju-gui machine?
<benji> yep, I'm using pyjuju; I guess I could try that
<gary_poster> frankban, does marco's test framework treat pyjuju as a first class supported environment, or is it second class, after juju core?
<frankban> gary_poster: I believe they are both supported at the same level; juju-test automatically retrieves the version in use and reacts accordingly.
<gary_poster> ok cool, thanks frankban
<frankban> gary_poster, hazmat, teknico: I'll schedule a meeting in the calendar to talk about the deployer; does tomorrow at 1500 UTC work for you?
<gary_poster> frankban, not for me.  Thursdays are horrible for me :-) s'ok can meet without me and summarize if you want to
<frankban> gary_poster: Friday would work as well, perhaps at 1400 UTC
<gary_poster> frankban, that works well for me
<gary_poster> oh frankban I am taking Friday off :-P
<gary_poster> frankban, btw, and maybe relatedly, would you and teknico mind permanently moving our weekly calls one hour earlier?  frankban's would be 1300 UTC and teknico's would be 1330 UTC.  Is that lunch time?  if it doesn't work, np
<frankban> gary_poster: isn't our call at 1300 UTC already? anyway, no problem for me with moving the call one hour earlier. starting from tomorrow?
<gary_poster> our call is currently 1400 UTC, if google can be trusted
<frankban> heh, it's 15:00 â 15:30 in my calendar, and we are currently in CEST time (utc+2)
<gary_poster> heh
<teknico> gary_poster: our call is currently 16:00 local, 14:00 UTC. the new time would be half an hour earlier for me
<teknico> gary_poster: it's not lunch time now, it will be once DST is off and local is back to UTC+1, in November, but it would still be ok for me
<teknico> benji: I did repeatedly run "make ftest" on the charm successfully recently, but only with juju-core, I'm having problems bootstrapping with pyjuju
<benji> thanks for the info, teknico 
<gary_poster> teknico, frankban, I am utterly confused, particularly with what teknico said :-P, but will make the adjustments in Google calendar and hope they all work out all right :-)
<teknico> gary_poster: sorry about that :-)
<frankban> gary_poster: they will work, and I'll set up a possible deployer meeting after talking with you tomorrow
<gary_poster> frankban, teknico, cool, thanks :-)
<gary_poster> hey bac, it's 8:56 for you right now, right?
<bac> 8:57
<bac> :)
<gary_poster> :-P
<gary_poster> :-)
<bac> fwiw, and you needn't bother remembering, PR is ATC which is always UTC-4
<bac> AST
<gary_poster> cool
<gary_poster> thanks
<bac> +1 for consistency.
<gary_poster> yeah
<teknico> gary_poster: Google Calendar now says that our call tomorrow is at 14:30 local, which means 12:30 UTC, is that intended? if it is, it's ok for me
<gary_poster> so, anyway, sorry was going to ask you to move meeting time but nm
<bac> my campaign: dump daylight savings time.  buy all dairy farmers Tivos
<teknico> bac: yeah, DST is madness
<gary_poster> teknico, yeah.  I think my issue is that Google says that my timezone is UTC -5, but they really mean I'm UTC-5+1DST
<teknico> gary_poster: right, ok
<gary_poster> benji! hi.  you may be noticing a pattern here :-P .  May I move your call to the morning, UTC 1300 (now but tomorrow)?
<benji> gary_poster: sure
<gary_poster> thank you
<benji> gary_poster: is that perminent?
<gary_poster> benji yes
<benji> k
<gary_poster> still ok?
<gary_poster> k
<gary_poster> thanks
<benji> yep
<gary_poster> cool
<sinzui> orangesquad. I will be distracted by charmworld's prodstack mongodb
<rick_h> sinzui: rgr
<abentley> sinzui: ACK
<gary_poster> thank you sinzui.  if you want anyone from GUI to pair, lemme know
<rick_h> hatch: when you're around wonder if you have time to chat. 
<sinzui> abentley, rick_h. production mongo shows evidence that mongodb has grown beyond our intent
<abentley> sinzui: Do we have an idea what collections are eating the space?
<gary_poster> hatch, Makyo, bcsaller I adjusted our one on ones permanently.  My Thursdays were unpleasantly insane, plus I had a new conflict with Matt and Jeff's time.  lemme know if these times are ok for you please
<sinzui> abentley, rick_h: there are two more dotted collections in production than we have in staging and the are 2 and 4 x larger than the collection we use: 513M juju.3, 1.1G juju.4
 * benji weeps softly into his keyboard.
<rick_h> sinzui: well that's interesting. :/
<benji> Why is getting juju-core to run so hard.
<gary_poster> heh
<gary_poster> benji, dunno.  we've got two resources to help ready now, at least, and Matt later
<abentley> sinzui: Are those databases, not collections?
<sinzui> abentley, rick_h: I would like to rm them, but I know little of mongodb operations.
<benji> gary_poster: who would be the best person to ask?
<sinzui> abentley, right, db backups/something
<gary_poster> benji, frankban probably.  teknico and Makyo also have a working juju core installation.
<abentley> sinzui: I don't know much about this either.  So these are files, not db names?
<sinzui> abentley, nm, I see. mongodb scales its used from 64 to 128 to ... It has scaled up twice beyond staging
 * benji waits for one to volunteer... before choosing a victim.
<frankban> benji: what's the problem? :-)
<sinzui> abentley, they are named juju.x so I think they are the db, but I believe mongodb is preallocating storage in the files.
<benji> frankban: the problem is I don't know where these things are written down, but the immediate problem is "error: no tools available"
<rick_h> sinzui: have you tried to run a mongo db compact on the db?
<sinzui> rick_h, that takes the db offline (I thnk)
<rick_h> sinzui: I'm curious if it's pre-allocating and messing with things if a compact would correct 
<rick_h> sinzui: true, can we test on staging to get an idea of the length of time?
<sinzui> rick_h, I think you are right
<frankban> benji: that's a new one... does it occur running juju bootstrap --upload-tools?
<rick_h> sinzui: if we have to bring up a new instance we'd have to go offline as well. 
<benji> frankban: nope, that's a bare bootstrap; I'll try with --upload-tools
<rick_h> sinzui: but this is something we've known we'd have to figure out at some point. I'm not sure if we can backup, bring up a new mongodb instance, and swap the front end over to it
<sinzui> rick_h,  you mean bring up a new unit, compact the old.
<rick_h> sinzui: if we can, maybe we can get an idea of the size of the same data, but on a fresh mongo, and at least tell if this is a compaction issue vs a "you have too much data" issue
<rick_h> sinzui: on the newly brought up instance, while leaving things running, for now, on the old
<sinzui> actually, if we bring up a new unit, we will see if the juju db was given gigs instead of megs
<rick_h> sinzui: rgr
<rick_h> sinzui: that's my only thought atm. I don't know enough mongodb to help much beyond exploring things a bit. sorry
<abentley> sinzui, rick_h: running compact will not delete any files and apparently temporarily increases disk space.
<sinzui> well we don't want to do that on this unit then
<rick_h> sinzui: right, but does backup/restore on a new instance shrink the size down to closer to what we expect?
<rick_h> abentley: :(
<benji> frankban: --upload-tools appears to have helped
<abentley> sinzui: kapil seems very knowledgeable about mongodb disk usage.
<frankban> benji: are you running juju-core from the compiled trunk?
<benji> frankban: yep (although I can't be sure it is up to date, as I am not sure I did the right thing to update it)
<sinzui> abentley, yes
<benji> frankban: if by "compiled trunk" you mean a trunk checkout that I compiled
<sinzui> I am going to query collection sizes and ask for the same from production to verify if the data is about the same
<sinzui> damn, this is a new unit. my mongo query history is gone
<abentley> sinzui: This page has some queries: http://docs.mongodb.org/manual/faq/storage/
<sinzui> abentley, I had queries in my history that iterated over our collections and gave me the counts
<abentley> sinzui: That page has queries that iterate over collections and give you counts.
<frankban> benji: yes, I was trying to understand that error. anyway, when you compile and run juju from trunk, it makes sense to always use --upload-tools
<benji> frankban: thanks for the help, I appear to have the tests running succesfully now.  We'll know for sure when the first test finishes.  How long do they normally take?  (I
<benji> (I'm running them in EC2.)
<frankban> 30min IIRC
<frankban> benji: ^^
<benji> yay! passing tests!  Thanks much frankban.
<frankban> great
<frankban> I wonder if pyjuju is having intermittent machine provisioning problems.
<gary_poster> luca__, hey,  guichat?
<luca__> gary_poster: give me 2 mins! :D
<gary_poster> luca__, cool :-)
<hatch> morning
<jcsackett> rick_h: do you have a moment to chat?
<rick_h> jcsackett: sure thing
<hatch> brb
<abentley> benji, bac: Remember to run "make lint" before landing on charmworld.  I just fixed a bunch.
<adeuring> orangesquad: could one of your review this mp: https://code.launchpad.net/~adeuring/charmworld/1199790-last-change-error/+merge/177865 ?
<benji> abentley: I'll certainly try.  We should add that to the CI.
<abentley> adeuring: looking.
<bac> abentley: will do.  thanks.
<hatch> bak
<abentley> benji: I am hesitant to add something to CI that will prevent working code from landing.
<abentley> benji: For example, we lived for a long time with a lint error because one file was doing "from x import *".
<benji> It seems to me that the only way to get something we want is to enforce it.  Automatic enforcemnt would appear cheaper.
<abentley> benji: I think social pressure is sufficient here and avoids the inflexibility of automatic enforcement.
<benji> It comes down to how we weigh the costs, benefits, and probabilities.  I weight the cost of someone having to resubmit a branch because of a lint error low (partially because I would propose a make target that would lint and propose), the cost of someone else having to deal with my lint errors high, and the probability of "trying harder" to materially increase compliance as low.  I can understand others having different weights/probab
<hatch> also the possibility of a lint error causing an obscure issue...... +1 benji....sorry abentley :)
<hatch> luca__: you're back! wb
<abentley> benji: How about we start with the make target?
<benji> sounds good to me
<abentley> sinzui: The Kanban card "Implement new primary key for charms" should not have gone into Archive.  It's unlanded work (that I'm about to land).
<sinzui> abentley, yes, but oh
<sinzui> I believed you were done with that card, you were going to land the branch merged into another branch...tracking the other card all the way to the end of the board
<hatch> rick_h: sorry I missed in the backscroll that you wanted to chat?
<rick_h> hatch: yea, guichat?
<hatch> ypup there
<abentley> sinzui: Oh.  I thought we would handle that situation by moving the card when the follow-on branch landed.
<sinzui> abentley, I had planned that originally, but since we were vacating the board, I decided to treat the issue as "the work is done because any developer can build of the branch".
<sinzui> abentley, sorry, you were off when I made the decision. I talked to everyone by you.
<sinzui> I suck
<abentley> sinzui: Nah, I understand what happened now.
<abentley> sinzui: All good.
<abentley> sinzui: No need for a 1x1 today, right?
<sinzui> abentley, +1
<luca__> hey hatch, thanks :)
<jcsackett> jujugui: can i get two reviews on https://codereview.appspot.com/12029045 ?
<benji> jcsackett: I'll do one.
<jcsackett> benji: thanks!
<bac> jcsackett: yep
<jcsackett> bac: thanks. :-)
<Makyo> jujugui calli n 8 kanban now
<bac> jcsackett: done but i haven't qa'd yet
<Makyo> jujugui call in 1
<Makyo> jcsackett, Starting now
<hatch> gary_poster: comingsoon is 13 versions behind trunk
<sinzui> mongodb people, this is a summary of what I know about manage.jujucharm.com's db https://pastebin.canonical.com/95291/
<jcsackett> no one be alarmed if you heard a crashing noise as i signed off. my dog just discovered the side table is rickety and falls over if you nose it. :-P
<hatch> lol
<abentley> sinzui: Our canonistack instances have /dev/vdb mounted at /mnt, giving us 10 GB of space.  Are the prodstack instances similar?
<bac> gary_poster, hatch: comingsoon is now r914.  the cronjob step 'make build-prod' was failing due to the switch to the new version of d3.  it needed a 'make clean' to get the cruft out.
<hatch> ahh great thanks bac
<hatch> hey luca__
<sinzui> abentley, I am asking. I know production has 10G but logs are on a another disk
<luca__> hatch: heya
<gary_poster> bac, awesome thanks
<gary_poster> jcsackett, if you want me somewhere I'll come by, otherwise will go back to planning world domination, or something
<jcsackett> gary_poster: i think we're good for now.
<gary_poster> cool jcastro 
<jcsackett> wrong name, dude. :-P
<gary_poster> sorry tab completio n :-P
<gary_poster> cool jcsackett :-P
<hatch> crap
<hatch> guess I'm taking my engineer-license again
<hatch> :P
<hatch> gary_poster: if you change something and then hit the toggle it'll reset the values and that's what they will stay
<hatch> oh he's back
<hatch> and he's gone
<hatch> lol
<gary_poster> hatch, +1
<gary_poster> debug hooks in juju core: https://codereview.appspot.com/12019043/
<gary_poster> someone working on core for 2 weeks :-)
<hatch> check out this css rule `input#use-default-toggle:checked ~ label .handle`
<hatch> OOOOOeeeeee
<sinzui> jujugui, I moved my notes to a gdoc so that we can all comment and edit. https://docs.google.com/a/canonical.com/document/d/1AoMhTdrominYLBS8iHbZLW_Ji2OH3mNhUzoHjetnD9w/edit#
<rick_h> jcsackett: got a sec for a chat?
<hatch> gary_poster: I think this is completed https://bugs.launchpad.net/juju-gui/+bug/1201023
<_mup_> Bug #1201023: Charmbrowser sidebar elements all have scroll bars in IE10 <charmbrowser> <juju-gui:In Progress by huwshimi> <https://launchpad.net/bugs/1201023>
<jcsackett> rick_h: sure. was grabbing lunch.
<jcsackett> rick_h: still need to chat?
<rick_h> jcsackett: no, I'm ok now. I follow what's up. Got confused by the jujucharms browser view setup
<jcsackett> rick_h: ah, yeah. i could see that.
<jcsackett> rick_h: i *think* maybe we can kill that? since we've launched, and i've heard nothing about doing a proper landing.
<rick_h> jcsackett: yea, I was tempted to but I can work around it for now
<rick_h> was the basis of the conversation request
<jcsackett> rick_h: dig.
<hatch> ugh handlebars drives me friggen bonkers sometimes
<hatch> rick_h: you might be able to help me out here
<rick_h> hatch: what's up?
<hatch> service-configuration.partial has a {{#settings}} loop
<hatch> and within that loop I need to access a parent property
<rick_h> ../
<hatch> I tried ../ghost (ghost being the property)
<hatch> but no luck
<hatch> {{#if ../ghost}}disabled{{/if}}
<rick_h> hmm, app/templates/unit.handlebars uses it
<rick_h> are you sure that there's a ghost one scope level up?
<hatch> yup, logged it out
<rick_h> heh {{debugger}} ftw?
<rick_h> hmm, I wonder if it's because of the scope block of an #if
<hatch> yeah checking that now
<hatch> I upgraded the debugger fn
<hatch> ok the #if must have busted scoping?
<hatch> to #YUI!
<rick_h> hatch: so yea, I'd drop a debugger in the YUI handlebars code in the if block helper and see wtf 'this' is in there. I'm betting it's not the loop scope any more?
<rick_h> hatch: otherwise, I'd go about it a different way and try to get the var into the loop scope. Sucks, but that's why we have some buildTemplateData type helpers lying around. 
<hatch> if that was the case then `ghost` would work, but it doesn't either
<rick_h> yea, the only way to tell is to break in the if block helper and look
<hatch> http://stackoverflow.com/questions/11562612/handlebar-context-lost-after-passing-handler
<rick_h> I don't recall using a block with a ../ up scope variable reference. 
<rick_h> hatch: yea, that makes sense 
<rick_h> so does ../../ghost help you out?
<hatch> nope, maybe I need three
<rick_h> or ../../this.ghost
<hatch> yup three
<rick_h> but yea, basically a bunch of wheee to figure out how to get out of the context in the block helper
<hatch> ugh...
<rick_h> yea
<hatch> handlebars totally does not follow the path of least astonishment
<hatch> haha
<rick_h> well, you're in the base context, then the loop context, then the if context
<hatch> then the wtf am I doing context
<rick_h> yea, I'm a 'give me my code or give me death' camp on templates myself. Unfortunately Mako hasn't been ported to JS yet :)
<rick_h> lol
<rick_h> time for a doc to explain wtf ../../../ is for :P
<hatch> :) thanks for the help
<hatch> lol
<rick_h> hah, np. "Keep adding ../ until it works darn it!" coaching is here for you
<hatch> hahaha
<rick_h> ugh, that damn showView made some stuff magically work. 
<hatch> rick_h: so depending on how many if blocks your in, you need more or less ../'s
<hatch> oy vey
<rick_h> hatch: but of course, each is another context
<rick_h> you need good tests on those. If someone moves the if blocks around then things will go nuts
<rick_h> hatch: but if it's getting too crazy maybe it's time to rethink?
<hatch> rick_h: Yeah I think I'll switch it to a helper
<hatch> but helpers don't have access to the full stack though I don't think
<hatch> so maybe just some comments
<hatch> lunching
<gary_poster> hey bac, you actually here, or juts pretending to be?  I've got wedgwood in webops saying that he wants to rip out some of our old stuff from charm-helpers
<gary_poster> my memory is that we tried to get some stuff approved
<bac> hi gary_poster
<gary_poster> but he didn't like test helpers or something like that
<gary_poster> hey
<gary_poster> you don't have to be here if it is past EoD  :-)
<bac> yeah, he didn't promote the test helper stuff, saying it was client code
<bac> gary_poster: no, it is just 16:30
<bac> same as you
<gary_poster> yeah I know but don't know when your start time is anymore :-P
<bac> gary_poster: i've been starting at 8
<gary_poster> cool
<bac> gary_poster: anyway he wants to remove the non-promoted stuff?
<gary_poster> bac, yeah
<gary_poster> we still are not using it anyway, right?  I didn't see it anywhere
<bac> i think that code is useful and deserves to live some place
<bac> gary_poster: huh, i thought our tests used it
<bac> gary_poster: or was it just from buildbot?
<gary_poster> bac no I meant we are not using wedgwood's library yet
<bac> gary_poster: that is true
<hatch> bcsaller: can you think of a way to reset all of the settings fields to their defaults using current code? I was thinking something in the databinding maybe to reset to the default model values?
<bac> gary_poster: if it is the OneTrueWay we'll need to spend some time converting our charm
<bac> but that is tech debt for us now, so i'm not sure when we'll carve out the time
<bcsaller> hatch: off the top of my head, viewlet.model.set(viewlet.model.getAttrs())
<bcsaller> oh, defaults
<hatch> oo good idea lemme try that
<bcsaller> not prev value though
<bcsaller> defaults come from the charm, not the values in the service
<bcsaller> model.set('config', charm.options)
<bcsaller> should work though
<bac> rick_h: why would 'make testid' produce non-contiguous numbers?  i'm seeing things like 1..16, 420, 17, 18, 421
<hatch> bcsaller: ahh actually we aren't databinding the ghost config so that approach wont' work :(
<hatch> will need to just loop through I guess, oh well
<bcsaller> hatch: I thought we changed it to db everything now though?
<hatch> ohh hmm lemme look further maybe I broke something
<hatch> bcsaller: do I have something wrong here https://gist.github.com/hatched/beee9956434d9ff6be5f the update fn is never being called when I update options
<bcsaller> hatch: you're sure its options and not config now, I'm not sure the current state of that 
<bcsaller> but the structure looks right
<hatch> well regardless of what it is - changing that object 'should' fire that update method
<bcsaller> no, update in bindings is called when that binding changes 
<bcsaller> so if the name is wrong it doesn't happen
<hatch> ok but there is an attribute called 'options'
<hatch> which I am setting
<bcsaller> we have options, config, settings, depending on which model you have I'd guess the name was wrong but I don't know how far you've gotten tracking it down 
<hatch> I'm just going to loop through the default values
<hatch> I think this is a bug, I'll document it later and see if we can resolve sometime
<bcsaller> is the model is question a POJO? it might be that observe isn't triggering change on a nested complex object
<hatch> ohh wait a second
<hatch> I think this is a bug from the charm model stuff
<hatch> charm model changeover
<hatch> all of the fields are undefined
 * hatch shakes fist at jcsackett
<hatch> lol :P
<jcsackett> hatch: i qa'ed against service inspector and didn't see anything.
<jcsackett> options.options seems weird, if options is charm...the charm attr should be get('options')
<rick_h> bac:  not sure, just how it works. I've not looked at the implementation
<rick_h> bac: the test runner usually loads tests and runs them alphabetically and such. SO maybe something with loading/running
<hatch> bcsaller: jcsackett ahh I found the bug....the fields have been renamed in the charm model and now the template bings on the wrong object
<hatch> easy overlook
 * bcsaller coughs
<bcsaller> thats what I said
<hatch> yeah well I had no idea what you were trying to say
 * hatch blames internet
<hatch> lol
 * bcsaller blames unicode
 * hatch blames timezones
<hatch> (all developers can agree timezones are to blame so it's an easy scapegoat)
<bcsaller> yeah, we should get rid of those
<hatch> aww man I got up so early. Yeah what time? oh like 5pm
<hatch> hehe
<jcsackett> hatch: which fields were renamed? i was trying to avoid doing that where possible and am concerned something may have been landed that shouldn't.
<hatch> jcsackett: it's no big deal it's just a discrepency between the ghost and service models and their resulting structure
<hatch> I think it's done properly now so I'm taking another approach
<hatch> I was just blaming you because your current task sucks
<hatch> ;)
<jcsackett> hatch: :-P
<gary_poster> :-)
<gary_poster> go jcsackett! sis boom bah! :-)
<gary_poster> sinzui, how goes the MongoDB war?
<sinzui> webops are considering my recommendations to move the db files to a larger mounted partition. This suggest means 0 down time
<hatch> bcsaller: so I don't think that setting an object to the same value as it is triggers the databinding
<hatch> it's ok, I'm looping through the fields
<hatch> but just thought I'd point that out
<gary_poster> sinzui, cool.  do we know why the data is more than we expected?
<sinzui> mongodb perallocates ever increasing files when there is lots of activity
<sinzui> gary_poster, This is the summary: https://docs.google.com/a/canonical.com/document/d/1AoMhTdrominYLBS8iHbZLW_Ji2OH3mNhUzoHjetnD9w/edit#
<gary_poster> sinzui, ugh.  thank you.
<hatch> Jeff Pihach has been assigned to the Card [(1201024) IE 10 drag and drop bug] by Gary Poster.   NOOOOOOooOOOOoooooooooo
 * hatch curls up under the desk
<hatch> :D
<gary_poster> hatch lol, that was the one you fixed before
<gary_poster> hatch, I moved that to archive and gave you credit
<gary_poster> there is still the new one :-)
<hatch> ohh haha ok well then that's better :D
<gary_poster> which I have not assigned to you...yet...
<hatch> lol
<gary_poster> who displeases me, among you?!! mwa ha ha ha.  etc.
<hatch> hahah
<gary_poster> benji, where is the charm branch?
<gary_poster> was hoping we could have that ready today
<gary_poster> by "where is"  I  mean "what's going on with the."  By "benji" I mean "benji, who is past EoD,"
<hatch> :D
<hatch> gary_poster: have a second to try out my toggle branch? lp:~hatch/juju-gui/use-def-config
<gary_poster> hatch, I think so, unless pulled away suddenly :-P one sec
<hatch> cool thanks!
<gary_poster> hatch, pulled away :-P will look asap after
<hatch> haha np
<benji> gary_poster: https://code.launchpad.net/~benji/charms/precise/juju-gui/fix-cache-headers/+merge/177958
<benji> darn, I'm in the right channel
 * benji goes to a channel far, far away
<Makyo> hatch, (new Array(3)).map(function(d) { return 0; }) === [undefined, undefined, undefined]; // what's happening here?
<Makyo> Or anyone, really.
<hatch> magic!
<hatch> wait
<hatch> that's gota be d3 code
<hatch> because it's impossible to read
<hatch> I think I know what's happening
<Makyo> hatch, From a friend, just asking around.
<hatch> it creates a new array with 3 empty slots
<Makyo> Just curious because [undefined, undefined, undefined].map(function(a) { return 0; }) === [0, 0, 0]
<hatch> it then loops through each one returning 0
<hatch> so each one will be [0,0,0]
<hatch> Makyo: it's probably some wako way to test for map functionality
<hatch> or proper functioning map functionality
<Makyo> The result should be [0, 0, 0] since (new Array(3)) === [undefined, undefined, undefined]
<hatch> I would love to know the real reason behind the code
<Makyo> hatch, not from an open source project, friend works elsewhere.
<hatch> right, but if map wasn't working properly then it 'could' be an indicator
<Makyo> So I'm assuming there's some more intermediary stuff, probably conditional.
<hatch> right....still odd
<Makyo> Well, those results are from my console.
<Makyo> Oh, huh.  (new Array(3)).map(function(a) { return typeof a; }) === [undefined, undefined, undefined]
<Makyo> but [undefined, undefined, undefined].map(function(a) { return typeof a; }) === ["undefined", "undefined", "undefined"]
<Makyo> So the constructor is just sort of...doubly undefined :P
<hatch> [undefined, undefined, undefined].map(function(d) { return 0; })
<hatch> gives what one would expect
<Makyo> returns [0, 0, 0]
<hatch> right
<hatch> as it should
<hatch> my guess is this is some edge case from using the array constructor
<hatch> which they say never to use :)
<Makyo> Hahaha
<Makyo> Yeah
<hatch> I'm intrigued now
<Makyo> Ohhh, he found it: http://stackoverflow.com/questions/5501581/javascript-new-arrayn-and-array-prototype-map-weirdness
<hatch> ahhhhh
<Makyo> There's a difference between undefined pointers and pointers to undefined.
<hatch> makes sense
<hatch> well, sortof
<hatch> lol
<hatch> I mean, I accept the reasoning :)
<Makyo> Hah, yeah.
<hatch> thats probably why devtools shows it as [undefined x3] in a different style when using new Array(3)
<gary_poster> hatch looking at your branch quickly...
<hatch> thanks
<gary_poster> hatch branch looks great.  only problem from UX perspective to me is that the "Use the default configuration" slider doesn't clearly show on/off to me.  Could we remove the checkmark when it is off?  I also wonder about turning it gray but I think that actually doesn't follow the intended design language
<hatch> yeah grey feels like it woudl be 'disabled'
<hatch> I can remove the check though
<gary_poster> awesome thanks
<hatch> no prob, thanks for looking,
<hatch> i'll propose after that change
<benji> hatch: it's because the function passed to .map is only called on array elements that have a value and (new Array(3)) creates an array with pre-alocated space for three elements, not a three element array
<benji> oops, Makyo I mean ^^^
<hatch> benji: welcome to 10 minutes ago
<hatch> oooburn
<hatch> :P
<Makyo> It's well put though.  Thanks benji 
<benji> heh
<benji> that's what I get for being in the right channel
<gary_poster> lol
<hatch> lol
<hatch> I wonder the purpose of the two methods
<hatch> using the constructor doesn't restrict pushing more information into it
<gary_poster> looking at your branch fwiw benji.  will ask west coast or frankban/teknico to review in an email so you can hopefully land tomorrow morning.  then we can make a release, test, and hopefully launch jujucharms in afternoon
<gary_poster> s/launch/update/
<benji> gary_poster: thanks, that's what I was hoping for
<gary_poster> hatch, I've seen that approach used in other languages as a micro-optimization opportunity.  I would assume it is the same here.
<gary_poster> in a fast inner loop that kind of thing can make a diff
<hatch> gary_poster: yeah I suppose - I could see if it was in a typed language where you would create an array of a specific size to reserve memory
<gary_poster> also used in clojure, which is untyped.  you are reserving space for pointers.
<hatch> does clojure allow you to alter the size of the array as well?
<gary_poster> if elements of pointers already exist (flyweights like numbers or strings, or existing objects)...
<gary_poster> then can still make a big diff
<huwshimi> Morning
<gary_poster> yes, hatch
<gary_poster> morning, huwshimi!
<hatch> interesting
<hatch> morning huwshimi
<gary_poster> strings are typically flyweights not numbers; whatever :-P
<gary_poster> huwshimi, I assigned you bugs.  They are for first half of August not urgent, though if you are looking for something to do, or comment on, cool.  also feel free to decline assignment :-)
<gary_poster> huwshimi, I know you have plenty to do thogh anyway
<gary_poster> though
<huwshimi> gary_poster: OK, I'll take a look
<hatch> *disclamer* declining the assignments may also decline checks
<hatch> guess noone gets checks
<gary_poster> :-P
<gary_poster> benji approved with no changes, but with follow-on warning about where/how to land.  very nice, thanks!
<benji> gary_poster: I was unsure about that bit; I proposed to the ~charmers branch because I figured that's where we would land it first
<benji> ok, dinner time; I'll see y'all tomorrow
<gary_poster> benji wait
<gary_poster> benji wrong brancgh
<gary_poster> not lp:~charmers/charms/precise/juju-gui/trunk
<gary_poster> lp:~juju-gui-charmers/charms/precise/juju-gui/trunk
 * gary_poster sends another message
<hatch> gary_poster: the top right card in Inspector Ready to Code is no longer valid - at least it appears to work as expected
<hatch> Collapsed inspector does not...
<hatch> properly set its maximum...
<gary_poster> hatch checking
<gary_poster> weird...bac said that he fixed comingsoon update mechanism but it is still old
<hatch> refresh
<hatch> I just thought the same thing
<hatch> lol
<gary_poster> heh
<gary_poster> ok thanks
<gary_poster> hatch agree, great!  you fix that?
<hatch> jujugui lf two reviews and a QA on https://codereview.appspot.com/12205043/ plz and thx
<hatch> I did yup
<gary_poster> hatch, moved with credit given :-) thanks
<hatch> :)
<hatch> it's past my EOD Now but anything specific you want me on tommorow morning?
<hatch> I was thinking the ghost config importer? as it's red
<gary_poster> red just means defect: claims to work but doesn't.  still not a bad idea...header images would be cool too.  I'll see if huwshimi has time for that.  hatch I vote for sticky headers before that :-P
<gary_poster> hey huwshimi, one probably easy thing to do...if you start up serviceInspector and add a service
<gary_poster> We have these five controls
<gary_poster> â S C E D
<gary_poster> We need to remove "E" and "D" and then replace the other three with icons
<huwshimi> gary_poster: OK
<hatch> sticky headers.....uuuuugh
<hatch> ooooo kkkkaaayyyy
<hatch> :)
<gary_poster> hatch use the hack from ant
<gary_poster> easy, yeah?
<hatch> I don't think his technique will work with dynamic content
<gary_poster> huwshimi, finding icons one sec
<hatch> I'll have to test
<gary_poster> hatch oh :-( ok timebox it to an hour
<gary_poster> huwshimi, https://drive.google.com/a/canonical.com/?tab=co#folders/0B7XG_QBXNwY1Zm8ya3NIcENyZnM
<hatch> gary_poster: ok can do - it might work alright but every time we update we'll need to recalc the header positioning....so I'll timebox the hour to see how difficult it'll be and then we can revisit
<gary_poster> hatch resolve retry replace instead, if you want?  that's one of the few remaining bigger tasks
<gary_poster> hatch we can push the sticky header to the end I guess.  It's not awful without it :-P
<huwshimi> gary_poster: Do you want these icons in today?
<hatch> ok resolve retry replace it is then!
<gary_poster> thanks hatch
<gary_poster> huwshimi, if easy and doesn't take much time, yes.  what are you on now?  I know I am supposed to know but have forgotten
<huwshimi> gary_poster: Just checking the sass builder with the files from ant and then moving onto something new... which can be the icons.
<gary_poster> huwshimi, cool thanks.  if ant's files work, land the sass thing, if I wasn't clear.  forgot what I said :-P
<huwshimi> gary_poster: No problems.
<gary_poster> thanks :-)
<hatch> huwshimi: if you have time add the icons to the spriting so that we can reduce our http requests
<hatch> then we don't have to go back and do it later
<gary_poster> oh yeah that would be cool
<hatch> not sure if you were aware of that or not
<gary_poster> if not clear how to do, just ask
<hatch> (the spriter)
<gary_poster> huwshimi, after all that continue on the sass
<huwshimi> hatch: Can we have dynamic sprites (hover, active etc)?
<huwshimi> hatch: That's the one thing I haven't been able to figure out
<gary_poster> huwshimi, just change class, yeah?
<gary_poster> oh that doesn't work I see
<hatch> huwshimi: yeah, you would specify a different background position for the :hover :active psudo class parts
<gary_poster> you break out of css
<gary_poster> oh yeah
<huwshimi> hatch: But how do I know what those positions are supposed to be?
<hatch> in the sprite.css file
<huwshimi> hatch: As in, if the sprite image changes (which it frequently does) then the hovers etc. have to be manually calculated and updated
<hatch> hmm
<huwshimi> hatch: One approach is to have all the different sprite images inside the node and on hover/active use CSS to hide/show the correct image...
<hatch> well the sprite is only a single image
<hatch> which is made up of a bunch of smaller ones
<huwshimi> hatch: Oh, I mean have something like <a href=""><i class="image-one sprite"></i><i class="image-two sprite hidden"></i><i class="image-three sprite hidden"></i></a>
<hatch> ohh then you would go a:hover .image-one { display: none } a:hover .image-two { display: block; }
<hatch> ?
<huwshimi> hatch: Yeah
<hatch> hmm
<hatch> it works.....feels hacky
<hatch> can't think of a better alternative
<hatch> SHIP IT!
<huwshimi> hatch: Yeah...
<hatch> my actual alternative is to patch node-spritesheet to add :hover classes :)
<hatch> but who has the time!
<hatch> although
<huwshimi> hatch: It's built dynamically, so you'd have to have another script to modify it after it was built
<hatch> well I was also thinking looping through the sprites twice
<hatch> once like normal, then another config to generate the hovers
<hatch> https://github.com/richardbutler/node-spritesheet#simple-example
<hatch> thinking maybe the `selector` property could be .selector:hover on this second pass
<hatch> or
<hatch> could be
<hatch> yeah....that's it
<hatch> I don't know if it's even possible without patching it
<hatch> image1.png image1-hover.png image1-active.png could then be turned into psudo's
<huwshimi> hatch: Well it would have to be customisable depending on what you want to do. The selector depth might be .something li.active a {}
<huwshimi> hatch: Not necessarily just the standard :hovers
<hatch> oh I suppose yeah becuase you wouldn't always be hovering over just the icon
<huwshimi> hatch: Yeah exactly
<hatch> alright so yeah your approach works the best then with the dynamic generated styles
<hatch> else it'll be to fragile
<huwshimi> hatch: Exactly
<hatch> oh well...I tried :P
#juju-gui 2013-08-01
<gary_poster> hey huwshimi, another thing to put after icons but before SASS is to style the settings page, if you could.  The ghost styles are perfect, and the same code is producing the html for post-deployed settings, so I suspect there's something fairly simple to do to get it working there.  It might be a re-fix for you--ISTR you might have already done this. If so, sorry about us missing that :-(
 * gary_poster runs away into the night
<huwshimi> gary_poster: I'll take a look, I haven't touched this at all.
<hatch> huwshimi: just to elaborate on the settings stuff a bit - there is also a IE10 bug ticket about the settings layout issue
<hatch> so if you are going to tackle that might as well keep that in mind
<huwshimi> hatch: OK thank
<huwshimi> s
<teknico> gary_poster: one on one now, right?
<gary_poster> teknico, yes, almost
<bac> rick_h: have you ever seen the charmworld test suite get wedged where things ran very slowly and known good tests started failing with elasticsearch errors like (paraphrasing) ShardNotAvailableError?  i rebooted, blew away the fake HOME directory and all tests pass now.
 * frankban lunches
<gary_poster> benji, will be late.  I have extra time at end so we will have time :-)
<benji> gary_poster: that
<benji> 's fine
<gary_poster> lol
<gary_poster> ok thanks
<benji> the enter key and ' key are closer together this morning
<rick_h> bac: yes, I've seen that. I didn't have ES running
<rick_h> ends up I had to update the ppa and install it
<rick_h> I *thuoght* I had ES, but figured maybe I'd missed an upgrade or something after doing what you did.
<bac> rick_h: thx
<sinzui> abentley, bac: do either of your have time to review https://code.launchpad.net/~sinzui/charms/precise/juju-gui/nagios/+merge/177588
<bac> sinzui: i will in a bit
<sinzui> Excellent news. A train has derailed and if I smell ammonia I am too turn off the air conditioners
<jcsackett> sinzui: eeee.
<hatch> yesterday wasps, today ammonia....might be time to move if  the danger level keeps increasing at this rate
<hatch> :)
<teknico> on a positive (?) note, the ammonia might kill the wasps
<hatch> and flys
<jcsackett> ...what keeps setting me as away...
<jcsackett> hatch: danger follows sinzui whereever he goes.
<hatch> lol
<sinzui> We've kept the shootings to a minimum since I had children
 * jcsackett laughs
<sinzui> Little does jcsackett know that I was held under suspicion of attempted murder
<jcsackett> eh, i've always suspected.
<jcsackett> you're a suspicious character, sinzui. :-)
<jcsackett> no one with that many tie-tacks could be an innocent.
<sinzui> Little do people realise that I am a geek in disguise. Paving the way for all geeks to look good and get dates
<hatch> all geeks can get dates it just takes us longer....like 10 years
<hatch> lol
<sinzui> See, I beat that by 5 years
<sinzui> or maybe 9
<hatch> haha
<sinzui> or 1 
<jcastro> rick_h: click-results thing fix today? 
<sinzui> I cannot think which what this works
<rick_h> jcastro: coming, waiting on one other branch to get through. Last I heard an update was planned to get out this afternoon under an updated release
 * jcastro nods
<jcastro> thanks man
<rick_h> bac: is comingsoon all fixed up? 
<jcastro> that's really my only "kicks me in the face" bug. 
<rick_h> jcastro: yea :/
<jcastro> rick_h: after this I promise to not bother you for at least another 24 hours. heh.
<bac> rick_h: it was yesterday
<rick_h> jcastro: :P yea you can see it fixed on comingsoon
<rick_h> bac: cool, I missed what was up with that. 
<jcastro> rick_h: oh indeed.
<bac> rick_h: upgrade to d3 caused 'make build-prod' to fail.  cleaned out the old and it was happy again
<rick_h> bac: ah, good stuff. 
<jcastro> rick_h: generally speaking if I see something fixed on comingsoon it hits prod __X__ days after? What's X usually?
<rick_h> jcastro: hmm, only recently had this going and so far it's 4-6 days?
<jcastro> ok
<rick_h> jcastro: so working that out I think. 
<hatch> jujugui looking for two reviews and a qa https://codereview.appspot.com/12205043/
<hatch> gary_poster: what do we do with the Needs Reboot and Security Upgrades Available? Should there be a link to landscape?
<hatch> hey luca how was your time off?
<gary_poster> hatch, yes.  luca could we have inspector icons for that, btw?
<gary_poster> hatch open in new window
<gary_poster> hatchj oh no
<gary_poster> don't open in new window :-P
<luca> hatch: gary_poster hey guys, It was good thanks :)
<hatch> gary_poster: no? Won't they have to log in separately anyways?
<gary_poster> y, though they can stay logged in on gui and landscape.  last time we said it would be in same window.  don't remember why, but was just sticking with past decision.  obv I still kinda agree with you :-)
<gary_poster> hatch, luca, if you want to make a different decision together +1 :-)
<luca> gary_poster: hatch they link to landscape but I was going to email you a request to make them open in a new window
<gary_poster> yay :-)
<hatch> excellent
<gary_poster> I wish I remember the argument to have it in the same window
<gary_poster> just so we would know
<hatch> so a single button 'go to landscape' or some icon of some sort
<gary_poster> but...yeah.  prefer new window
<hatch> gary_poster: I 'think' it had something to do with the session storage
<hatch> being window specific
<gary_poster> hatch, ah right
<gary_poster> so if you go from LS back to GUI
<gary_poster> then you have to log in again
<gary_poster> let's try this instead :-P
<hatch> yep new winder is is
<gary_poster> cool
<jcastro> rick_h: I was pointing out mysql as one that works
<rick_h> jcastro: ah, read it as another example of fail. 
<rick_h> jcastro: cool, so yea, simple file extension issue
<gary_poster> hatch, please ask me about css name changes on noon call.  rick_h has to do with deployment, you might care too.
<gary_poster> hatch sorry I mean on weekly call (@ my noon ;-) )
<rick_h> has to do with deployment? ok
<luca> gary_poster: I think I remember a conversation on changing Hooks to Source but is there any document for it
<rick_h> luca: I thought gary_poster did that at the sprints
<rick_h> luca: yea, the tab is already called Source and the description/info at the top of that tab updated
<gary_poster> luca there was a bug about it filed by Nick Veitch.  I decided that it was nicer to rename the tab to "Source" rather than remove all files that were no a hook
<gary_poster> so addressed the bug in that way
<luca> gary_poster: that's right, I remember seeing the bug. We can discuss it next week :)
<gary_poster> luca, cool, thanks, look forward to it.
<benji> gary_poster: I swear.... The juju-gui-charmers charm trunk appears broken.
<benji>         agent-state: error
<benji>         agent-state-info: 'hook failed: "start"'
<benji> I'll diagnose but this will likely cause a delay in landing my branch.
<gary_poster> benji :-( :-(
<gary_poster> benji please give me more details when you have them.  pyjuju or juju core?
<benji> gary_poster: juju-core; I'll keep you apprised.
<gary_poster> thanks
<hatch> gary_poster: created a card in the second row of inspector for the viewlet docs
<gary_poster> benji, seesm like the change would be in juju core if so.  we haven't changed lately
<gary_poster> thanks hatch
<gary_poster> benji, I mean, in a way that should affect that
<hatch> our webserver is based on tornado right?
<rick_h> hatch: rgr
<hatch> thx
<benji> gary_poster: we did this to ourselves: http://paste.ubuntu.com/5936817/
<gary_poster> benji...yes but if so... :-( been that way a looong time and nobody told us
<benji> that's because they can't start the gui to click on the feedback tab
<gary_poster> benji and it was definitely working relatively recently
<gary_poster> 2013-07-18
<benji> we just made this change yesterday I think; I reviewed the branch that removed the charm world URL config setting (I didn't think it would have this side-effect of course)
<gary_poster> benji did you deploy with any special options
<benji> juju bootstrap --upload-tools && juju deploy --repository ~/juju-charms local:juju-gui -u
<gary_poster> benji this change would not cause that key error: http://bazaar.launchpad.net/~juju-gui-charmers/charms/precise/juju-gui/trunk/revision/69
<hatch> rick_h: have a second for another hbs q?
<gary_poster> of course the fact that this happened yesterday makes me sad.  I though we had done that a long time ago--was sure of it in fact, because we had used this for jujucharms.com
<rick_h> hatch: sure
<benji> gary_poster: I think this was a change in the gui, not the charm; this is just an initial reaction at this point though, I'm trying to confirm
<hatch> rick_h: thx ok here is what I'm trying to do https://gist.github.com/hatched/7bbbc76b881fa20d7b92 which obviously is not supported
<gary_poster> benji, but we haven't made a release since 0.8.1
<benji> that's a good point; I wonder why this is happening
<hatch> rick_h: basically i need it to parse an array to see what buttons are to be shown, and if it's in that array then show it
<bac> sinzui: branch for review when you have a moment.  https://code.launchpad.net/~bac/charmworld/bundle-search/+merge/178107
<rick_h> hatch: so you have to build it in the View layer before you pass it to the template. See  _buildQAData in the subapp browser charm.js view
<gary_poster> benji fwiw I'm trying to dupe with pyJuju now
<bac> abentley: would like for you to look at it too.  ^^
<rick_h> hatch: it sucks, but it's the best way to do it and that way you can test it as well. 
<benji> k
<hatch> rick_h: ahh - yeah that's exactly what I was trying to avoid :)
<hatch> thanks for sanity checking
<rick_h> hatch: yea, try as you might. I've had to break down and do it in several places. 
<Makyo> jujugui call in 5 kanbaaaaaan
<gary_poster> hatch I am in guichat if you want to talk early about css thing
<gary_poster> Makyo, thanks :-)
<sinzui> bac: I wont be able to get to it today
<bac> sinzui: ok
<gary_poster> jujugui weekly call in 2
<gary_poster> orangesquad weekly call in 2
<hatch> luca: in the unit lists in the new inspector the resolve/retry/replace section....
<hatch> not all sections need all buttons
<hatch> should they be left or center justified?
<hatch> aligned*
<luca> hatch: centered please :)
<hatch> sounds good....and for the landscape statuses
<hatch> what do you want the 'go to landscape' button to say?
<hatch> or look like....
<bac> gary_poster: after lunch i'd like just a few minutes to nail down exactly what you want for IoM bundle deploy demo.
<gary_poster> ack thanks bac
 * benji lunches.
<gary_poster> hatch, rick_h wanna talk now, in 15 min, or 1 hr? :-)
<hatch> I'm good whenever
<rick_h> gary_poster: just cooking up lunch, 1hr?
<rick_h> or you guys can watch me eat on google-cam :)
<hatch> what are you having?
<rick_h> skillet meal 
<hatch> yeah I have no idea what that is
<rick_h> lol, frozen meal in a bag you stick on the stove for 10min and then eat
<hatch> ohh haha
<hatch> I'll probably have a sandwitch
<hatch> although a grilled sandwitch also sounds good
<gary_poster> hatch, rick_h cool thanks :-) talk to you in 1 hr
<rick_h> hatch: had grilled cheese/ham earlier in the week :P
<Makyo> "This version of SublimeText 2 has expired"?   Boo >:/
<rick_h> :P vim never expires
<Makyo> rick_h, +1000
<hatch> Makyo: expired?
<hatch> using a demo?
<Makyo> hatch https://twitter.com/bzr_pull_makyo/status/362988795529940992/photo/1
<Makyo> hatch, their demos don't expire, per their website.  I think it's just "please please use the most recent"
<hatch> ohhh right
<hatch> vim needs a paid version
<rick_h> they do, it's called vim. Just pay to their selected charity
<hatch> I mean so that they can develop the product to make it more user friendly :)
<rick_h> there are two sets of tools in the world. consumer grade and pro grade. Consumers can't easily use pro grade. (camera, sound equipment, ... editors) :P
<hatch> things aren't "discoverable"
<Makyo> gVim is prosumer
<hatch> and editing the config is....well.....heh
<Makyo> Sigh.
<hatch> I thought I found somewhere that had a config manager
<hatch> for vim
<Makyo> There's a few.
<Makyo> There's https://github.com/spf13/spf13-vim which sits on top of a manager thing, I think.
<Makyo> That had too many features for me, though.
<Makyo> I couldn't see the code for all of the extra STUFF in there.
<hatch> haha
<Makyo> I just use stock vim, my vimrc, and ctrlp.
<rick_h> jujugui review time please. ï»¿ï»¿https://codereview.appspot.com/12272043
<rick_h> and hatch sorry, I forgot I said I'd do your review. Looking for it now
<hatch> yeah...that's right!
<rick_h> hatch: linky?
<hatch> https://codereview.appspot.com/12205043/
<hatch> Makyo: the time to setup the vimrc I think is what ultimately drove me away from it
<rick_h> hatch: booo, that's back to back "error old chunk mismatch" 
<hatch> seriously??
<hatch> ugh
<rick_h> hatch: next sprint, we'll take care of you
<hatch> I'll repropose
<rick_h> hatch: I'm on 3rd generation of my vimrc setup
<Makyo> hatch, I've not had a single one of your reviews work, tbh, been going off MPs.
<rick_h> hatch: k, thanks
<Makyo> hatch, but yeah, vimrc is something you can build off others; I think both rick_h and I have good ones you could maybe crib from.
<rick_h> yea, but don't ever copy anything you don't understand wtf it is. That lead from gen 1 to gen 2
<hatch> haha
<rick_h> "my vim's not working, wtf...it must be one of these 200+ lines of crap I copied from some dude"
 * rick_h deletes all
<hatch> rick_h: Makyo missmatch fixed
<rick_h> hatch: thanks, looking now
<hatch> tons of results about the chunk missmatch error, must be a reitveld error
<hatch> rietveld
<hatch> whatever
<hatch> I was actually considering webstorm ide
<hatch> has some really cool api docs parsing stuff
<hatch> rick_h: btw I'm reviewing your branch, will also qa
<rick_h> hatch: ty
<hatch> lol nice test file diff
<rick_h> yea, warning in the description
<rick_h> had hoped reitveld would just show the indentation change, but nope :(
<hatch> I bet the bzr diff shows it as all new
<rick_h> yea
<rick_h> bzr hates indentation changes
<jcsackett> rick_h: looking at your MP now.
<rick_h> jcsackett: ty
<jcsackett> rick_h: making sure i understand, the important bits of the test changes are the setup/teardowns for the display tree suite?
<rick_h> jcsackett: correct, the browser dom create method is shared among all suites in the new closure. The setup/teardown is adjusted to take care of things that showView auto did before. 
<hatch> Chrome has an update....50 tabs open....not updating :P
<rick_h> hatch: no tests?
<hatch> rick_h: where we are going....we don't neeeeed tests
<hatch> but really though there is a card to write the ghost tests
<hatch> it's still a little to much in flux imho
<rick_h> hatch: up for a chat on the branch then. I'm missing some changes and really ugh about a no-test branch that goes into modifying form elements/config data
<hatch> sure
<hatch> your branch also failed qa....dun dun dunnnnn
<rick_h> gary_poster: we up to chat ?
<rick_h> hatch: doh! I qa'd. Curious what was found. Did you hit a back button again? /me always forgets to test that part
<hatch> just getting repro
<hatch> rick_h: ok updated the review
<rick_h> hatch: rgr, thanks
<hatch> guichat about my branch?
<rick_h> sure thing
<gary_poster> hatch, rick_h 
<gary_poster> yeah, guichat
<rick_h> gary_poster: rgr
 * Makyo has to go take the dogs to dogcamp.  Back in a little bit.
<gary_poster> Makyo, bac either of you ready/able to talk?
<bac> gary_poster: i am
<gary_poster> bac cool.  guichat is busy let me make a hangout
<gary_poster> Makyo, you're the only one left.  :-) I saw you are out; np.  ping on your return.
<gary_poster> benji, what's the status?
<rick_h> gary_poster: guichat empty
<benji> gary_poster: I've been successful in deploying the juju-gui-charmers trunk against pyJuju, but goJuju gives me the same error; I'm going to chalk it up to my goJuju being broken somehow and am moving forward QAing against pyJuju.
<gary_poster> rick_h, :-) thanks
<gary_poster> benji, super weird since that looks like such a bltant python error.  but glad you can move forward
<Makyo> gary_poster, back.
<hatch> benji: kind of like your termbeamer but for sublime, vim and emacs https://floobits.com/
<benji> I saw that the other day.  It looks really cool.
<hatch> also found http://codeshare.io
<rick_h> benji: mentioned termbeamer 3 times at PyOhio
<rick_h> I should have done an open space demo'ing it. 
<rick_h> benji: one question came up I wasn't sure about, can you use it with your own jabber server? (mozilla folk wanted to know)
<benji> did it appear and offer to help you get back to the land of the living?
<benji> yep, it only needs xmpp, it doesn't do anything google-specific (AFAIK)
<rick_h> benji: cool, told them I thought so but only used it with my google account
<benji> and there's a new option to use a purpose-built server; one runs on termbeamer.com or they can run their own
<rick_h> yea, had mentioned you were working on that. You need a blog post we can reshare around the inter-webs :)
<hatch> http://finalterm.org/
<benji> finalterm looks cool, especially the context-sensitive menus; I haven't given it a try yet though
<hatch> so many things to try out, who has the time
<hatch> this is why I have so many tabs open
<hatch> because I also have 100s of bookmarks so things just get lost haha
<hatch> one of these days I'll put them into evernote or something
<Makyo> There are probably better solutions for bookmarking.  Just a guess, though ^^
<Makyo> Er, hatch ^^^
<rick_h> *cough* bmark.us *cough*
<Makyo> Was gonna say :)
<abentley> sinzui: chat?
<hatch> haha
<sinzui> abentley, in 2 minutes?
<abentley> sinzui: okay
<hatch> I have a lot of stuff in evernote
<hatch> but I know the featureset rick_h has in bmark is pretty darn close :)
<hatch> even if it is in python :P
<rick_h> hey, I updated YUI for you :P
<hatch> haha I saw that
<rick_h> it's nearly 50% JS 
<hatch> is there a bmark.ca?
<hatch> :P
<rick_h> no, but you can deploy your own
<hatch> should modernize the styles of it, put it on bmark.io or something and then charge /yr :P
<hatch> use bootstrap 3 even!!!
<hatch> lol
<rick_h> nevar! die bootstrap
<rick_h> I should update to pure though. Using older responsive YUI grids
<hatch> can't....stop....sneezing
<hatch> man I wish I could open up the rietveld comments in my code
<hatch> unlikely they have an api though
<rick_h> very simple api https://code.google.com/p/rietveld/wiki/APIs
<rick_h> would have to fetch the issue metadata, with messages, and then parse those out I think. 
<hatch> ehh too much work
<gary_poster> benji, please keep me up to date on charm progress.  I should be stopping now but I need to make sure we have a release in progress
<benji> gary_poster: I am doing what I hope is the last test now... we'll see.
<gary_poster> cool
<gary_poster> thanks
<jcastro> gary_poster: I have no problem making the README file a documentation thing, I just need to know which ones are valid?
<jcastro> README, README.md and ... ?
<bac> abentley, benji: i have changed my plans to work tomorrow so i'll be around to help with the demo
<abentley> bac: Cool.
<bac> abentley: changes per review have been made.  diff is updating now
<jcastro> hey sinzui 
<abentley> sinzui: I haven't figured out how to make juju-deployer export an environment.
<sinzui> hi jcastro
<jcastro> sinzui: is there a way we can generate a list of charms in the store that have READMEs that either are .rst or .markdown?
<jcastro> I can go through and fix em all up
 * sinzui thinks
<sinzui> jcastro, I can run a query on staging to do that. I can do that tomorrow.
<jcastro> rock and roll
<jcastro> sinzui: hey so, actually
<jcastro> remember how we wanted to do a charm audit anyway?
<sinzui> jcastro, I think you mean all charms owned by charmers
<jcastro> maybe start seeding the queue with stuff like that?
 * sinzui copies scrollback to keep the task
<jcastro> yeah so now that we're not smoked from OSCON maybe we should chat like tomorrow about how to seed the queue with audit tasks, etc?
<sinzui> abentley, :(
 * sinzui tries to remember what he did
<hatch> bcsaller: kickin around?
<bcsaller> hatch: yeah
<hatch> return view.createServiceInspector(service, {databinding: {interval: 0}});
<hatch> what does the interval effect?
<bcsaller> we delay the updateDOM unless interval is 0 so its needed to test sync style
<bcsaller> otherwise updateDOM will fire only after some period w/o calling, 150ms I think
<sinzui> abentley, jitsu export > staging.jc.com.deployer
<sinzui> abentley, https://pastebin.canonical.com/95362/
<hatch> ahh ok thanks
<abentley> sinzui: thanks.
<sinzui> abentley, so I think there might be version issues between what I did lat May and today's deployer
<bac> abentley: what does a deployer file branch look like?  does it just have a single .yaml or .cfg file in it?  special naming?
<gary_poster> thanks jcastro.
<abentley> bac: Yes, it's a single file named "bundles.yaml".
<bac> thanks abentley
<abentley> sinzui: Yes, there has been skew.  In current configs, there is an outer dict of bundles, and services is a dict, not a list.
<sinzui> yeah, services is what looked wrong
<abentley> sinzui: Also, relations looks wrong.
<abentley> bac: Have you run "make lint"?  Some of the indentation looks like it would be rejected.
<abentley> bac: r=me aside from that.
<hatch> rick_h: do you happen to still be around?
<rick_h> hatch: kinda, booking a flight for the wife but EOD. I know your branch needs a look. I'll try to peek here in the next 20ish
<hatch> thanks, it's proposing now
<hatch> issues are fixed and I added ghost-inspector tests and the outline of what is to be followed once this lands
<BradCrittenden> thanks abentley for the re-review.  it is lintfree.
<hatch> I also moved the ghost inspector test card onto the board under me
<hatch> so I'll be on it right after this lands
<benji> gary_poster: QA looks good; I'm doing a gui upgrade (from 0.8.0 or 0.8.1) now to QA my change specificially, but I think we'll be in the clear
<gary_poster> great thanks benji!
<hatch> rick_h: updated
<hatch> gary_poster: this will be 0.8.2 right?
<gary_poster> hatch, I guess so, yeah
<hatch> save 0.9 for the inspector :)
<hatch> OR should 0.10 be the inspector
<gary_poster> :-)
<hatch> oooOOo
<gary_poster> lol
<hatch> it's so much work that we jumped 2 spots
<gary_poster> heh
<gary_poster> I'm trying out lp:~gary/juju-gui/hackreleasefiles now
<benji> gary_poster: QA looks good (no style or sprite issues)
<benji> I'll do the merge in the morning (deployments near EOD being a bad idea)
<hatch> are Friday morning deployments better than Thursday night?
<hatch> debate! :P
<benji> Yes.  Debate over.
<benji> Tuesday morning deployments being the holy grail.  After all, who wants to create problems on a Monday.
<hatch> true true
<bac> sinzui: do you have a deployer file for deploying jujucharms?  i hear you do.
<sinzui> bac. I do.
<bac> sinzui: would it be compelling for an IoM demo?  if so, can you share it with me?
<sinzui> bac, the file is from IS and I think it is the old format though
<bac> sinzui: ok.  wiki.yaml from the deployer configs looks serviceable
<gary_poster> benji, ok thank you.  
<gary_poster> it appears building a branch now requires that g++ be available
<gary_poster> so the charm is broekn for that use case atm afaict
<rick_h> hatch: I've got to head to swim class in a minute. I don't have time to go back over the branch, sorry. Please rope someone else in to help get it in for huw
<gary_poster> hey hatch, seen this node error before
<gary_poster> http://pastebin.ubuntu.com/5937801/
<rick_h> as temping as code review on the lake beach might seem
<hatch> rick_h: haha ok
<hatch> gary_poster:  looking
<hatch> gary_poster: what version of node are you running?
<gary_poster> hatch this is on the charm.  0.8.23
<hatch> ok one sec lemme check out node-sass
<gary_poster> hatch fwiw that came from bin/generateTemplates
<hatch> engines: { node: '>=0.10.0' },
<gary_poster> hatch, ah :-(
<gary_poster> hatch I have that on raring but in charm...
<gary_poster> looking at PPA...
<gary_poster> yup https://launchpad.net/~juju-gui-charmers/+archive/stable
<gary_poster>  	0.8.23-1chl1~precise1 
<hatch> we should really try to upgrade node again
<hatch> do we have time?
<gary_poster> pfft, not before Friday morning :-P
<hatch> what's odd is that I run the most recent 'stable' node on my desktop/laptop and can deploy just fine
<hatch> s/deploy/buil
<hatch> d
<hatch> maybe the error we ran into has been resolved
<hatch> of course the easiest thing to do would be to comment out node-sass
<hatch> :)
<gary_poster> hatch, that's what I was thinking. :-/ are we using it for anything?
<hatch> looking
<hatch> nope
<hatch> it was a setup branch for the following sass changes
<gary_poster> right
<hatch> so in lib/templates.js you can comment out the require('node-sass')
<gary_poster> hatch, could you tell me the least invasive way to disable it?  I need to go help with dinner and will investigate afterwards
<gary_poster> oh
<gary_poster> :-) thanks
<hatch> and one more
<hatch> remove the node-sass line from the package.json
<hatch> then you'll need to remove the shrinkrap file and regenerate it
<hatch> which is simply `npm shrinkwrap`
<gary_poster> hatch shrinkwrap not available in my local npm :-/
<gary_poster> must run will be back iab
<hatch> jujugui anyone around able to do areview https://codereview.appspot.com/12205043/
<bcsaller> sure
<hatch> thanks
<hatch> bcsaller: the tests are coming up right after this lands, card is already in active coding :) just FYI
<Makyo> Heading down to the hotel, back to work after check-in.
<hatch> bcsaller: lol "scary scoping, and it get worse."
<huwshimi> Morning
<hatch> morning huwshimi
<gary_poster> morning
<gary_poster> huwshimi, hatch, bcsaller, call in 1 in guichat
<hatch> huwshimi: I'll probably be hangin around cleaning up some stuff and reading blogs so ping me if ya run into any issues
<huwshimi> hatch: Thanks.
<hatch> oh huwshimi also if you're working on the inspector be sure to pull in trunk as I did a bunch of css stuff today
<hatch> must.....close....chrome....tabs
 * gary_poster restarts hoping that chrome will be ok again...
<gary_poster> back soon
#juju-gui 2013-08-02
<huwshimi> gary_poster: Are you around?
<gary_poster> huwshimi, unfortunately :-P
<gary_poster> not for your sake, for the sake of staring at my branch :-)
<huwshimi> :)
<gary_poster> hey hatch, if you are around could you give https://codereview.appspot.com/12306043 a once over?  I'm going to ask Francesco to review, land, qa and release the gui his tomorrow morning.  then I'll ask benji and curtis to coordinate testing the charm upgrade and the GUI upgrade.
<gary_poster> email sent
<gary_poster> I'm outta here.  Bye all.  I'll check email occasionally
<hatch> gary_poster|away: sorry I was out - I'll give it a review now. cya!
<rick_h> frankban: seen the emails. If there's anything I can help with please let me know. 
<frankban> rick_h: thank you. I just landed a branch that should fix the service menu bug. I am going to QA now for the release, more QA eyes can help
<rick_h> frankban: rgr, will pull it down. 
<frankban> rick_h: everything seems to work here, except for a bug also present in the current release: destroying a service from the service detail view does not work
<rick_h> frankban: hmm, works here. That's the popup menu when you click on a service?
<rick_h> frankban: ah, I see, when you click on it in details. My bad
<frankban> rick_h: no, double click a service, and then click the destroy button, yes
<rick_h> yea, the "are you sure" dialog pops up and the immediately closes
<frankban> rick_h: exactly, I don't think this is a release blocker
<rick_h> ok, I'll file a bug for the moment on that then. Looking into the reason right now
<frankban> rick_h: cool, please ping me if you think there is a really quick solution for the problem
<rick_h> frankban: yea, it's showing as -hidden so something in the code is running a .hide(). I'm not familiar with the detail view. Will go with a bug for now if it's not a blocker. 
<frankban> rick_h: I assume it's not a blocker b/c it's not a new bug
<rick_h> ah, interesting. I'd agree then. And there's a workaround to destroy from the service icon
<rick_h> frankban: one line fix
<frankban> rick_h: great!
<rick_h> frankban: http://paste.mitechie.com/show/986/
<rick_h> frankban: can you apply please? My trunk is a little messed up due to an accidental commit to trunk and I need to clean it up
<frankban> rick_h: sure, thank you
<frankban> rick_h: charmbrowser QA seems great to me, could you please confirm?
<rick_h> frankban: yes, I've not been able to break it. +1 
<frankban> rick_h: do you have time to write a quick changelog for this release, so that I can put that in the changes.yaml file? if not, no worries.
<rick_h> frankban: sec. /me looks 
<rick_h> frankban: should just be able to go through the releasable cards right?
<frankban> rick_h: yes, or here: http://bazaar.launchpad.net/~juju-gui/juju-gui/trunk/changes
<rick_h> frankban: k, working on it
<frankban> rick_h: thanks
<rick_h> frankban: http://paste.mitechie.com/show/987/ I think works going at it a little quickly. Rest of the cards are charmworld or not really 'changelog' items
<frankban> rick_h: nice, thanks!
<benji> frankban: how goes the release?
<frankban> benji: QA is done. Now starting the release process. I am also running the CI tests, just in case.
<benji> cool
<bac> benji: are you going to work on the iom demo today?  i've created cards and reference the google doc.
<benji> bac: I have some availability, but my main priority is upgrading the charm.  I should have some time but I don't know for how long.
<benji> I'll help any way I can.
<bac> benji: ok, i didn't know how far you'd gotten on the charm
<benji> it is ready to go; I'm waiting on the release now
<benji> well, my changes are ready to merge, that's what I'm doing now
 * bac loves the yaml.  deployer example config had one line missing an indentation space and it went nuts.
<benji> yeah, significant whitespace will never catch on
<bac> hey, that's different!  :)
<bac> benji: and the py interpreter gives a better error message than 'expected key missing'
<benji> there is that; I guess every good idea can be done badly
<frankban> guihelp: CI tests fail during the charm installation :-/ (make distfile): http://pastebin.ubuntu.com/5939960/
<frankban> guihelp: I assume there is an error in deploying the charm using a branch as juju-gui-source? Should we consider this a release blocker?
<teknico> frankban: uhm, no idea
<benji> frankban: I am not aware of that bug (but I haven't tried it recently either)
<adeuring> abentley: could you have a look at this mp? https://code.launchpad.net/~adeuring/charmworld/1206158-dl-count-by-week-half-year/+merge/178265
<abentley> adeuring: sure.
<abentley> adeuring: r=me.
<frankban> benji: I am trying to dupe using juju-core. I'll also check if this is a regression introduced after the last stable release. If so, I don't think we should go on, otherwise, I'll proceed with the release. Sounds good?
<rick_h> frankban: hmm, I just did a fresh checkout/build and didn't hit that. 
<frankban> rick_h: yeah. Build works locally here too. What nodejs version are you using?
<rick_h> frankban: 0.10.8
<benji> frankban: sounds good; note that I merged my changes to juju-gui-charmers trunk within the last hour so it is possible that I caused any problems with those changes (but I don't see how)
<rick_h> benji: gary_poster's branch yesterday updated a npm file with a bunch of 'mechanical' looking changes
<rick_h> I wonder if anything in there wasn't good
<adeuring> abentley: thanks
<frankban> benji: CI uses cs:~juju-gui/precise/juju-gui . That's a different charm, right?
<abentley> bac, benji: Can we do a hangout on bundles?
<benji> frankban: I don't know exactly how it works, but my understanding is that the juju-gui-charmers trunk is the source for the official gui charm.  My understanding is that within 15-20 minutes of landing to trunk the new charm should be in force
<rick_h> frankban: looking at https://codereview.appspot.com/12306043/patch/1/1004 some of the grunt items were version updated? contextify was updated from 0.1.5 to 0.1.6
<bac> abentley: sure
<benji> abentley: I'm consumed with release things at the moment
<frankban> rick_h: I have v0.10.5 locally. The charm (precise) installs v0.8.23. Perhaps this is relevant?
<rick_h> frankban: ouch!
<rick_h> frankban: yea, that's not good if it's that far behind. 
<frankban> yeah, I guessed so :-/
<rick_h> doesn't hacking still require going through a nodejs ppa?
<rick_h> I would have expected the charm to also pull the  sudo add-apt-repository ppa:chris-lea/node.js ppa
<rick_h> ?
<rick_h> as it's what we dev against
<rick_h> sinzui: around? did IS change/frown on this?
<sinzui> rick_h, that wont work
<abentley> rick_h: IS generally want to use only things in the main archive or the precise-cat archive (or whatever series is appropriate).
<rick_h> frankban: I'm going to guess we've got bigger issues then. I'm not sure how we released before tbh with a 0.8 nodejs
<sinzui> rick_h, frankban. I think all packages need to be installed in "cat" which is mad available via the exec.d hack
<frankban> rick_h: this can be a very old regression
<sinzui> we need an rt to place a package in cat.
<sinzui> PS there is 1 webops today. He has 2.5h before EOD. I hope to monopolise him to move charmworld's mongodb
<frankban> rick_h: I believe the charm takes npm from https://launchpad.net/~juju-gui-charmers/+archive/stable
<rick_h> ugh, friday release fail
<frankban> s/npm/nodejs/
<rick_h> frankban: oh hmm, and that's an old release from that ppa it appears. 
<rick_h> frankban: so yea, I've no idea how this works I guess :/ We're running 2 large versions ahead in dev, just updated the revisions of some deps, and things went boom on production. 
<sinzui> frankban, rick_h, webops make fat charms. they don't deploy the ones we give them. The can update their scripts to pull a branch of need dep, then add it to the charm.
<rick_h> sinzui: well at this point I'm confused. If we've been running an old version for a known reason for a while then I don't want to suggest updating it
<rick_h> I'm guessing we're on 0.8 for a reason then? However, it seems devs are all on 0.10 
<hatch> yes
<rick_h> I know hatch has tinkered with nodejs versions so we'll bug him
<rick_h> ...starting now
<hatch> lol
<frankban> sinzui, rick_h: I also believe webops deploy from releases. This bug only affects deployment using branches (e.g. juju-gui-source=lp:..). node/npm are only required to create releases from branches.
<sinzui> frankban, correct
<rick_h> frankban: ah, that's what you mean by 'old regression' then? Maybe deployment from branches has had issues for a while but only now seeing?
<hatch> reading backlog
<antdillon> rick_h, My branch is lp:~ya-bo-ng/juju-gui/typography-charm-details
<frankban> rick_h: exactly, especially considering the functional test in the charm uses a fake branch
<hatch> frankban: is g++ installed?
<sinzui> rick_h, the webops script retrieves the tarball from lp and places it in the charm,
<rick_h> frankban: k, then I guess it sounds like it's a non-blocker if we can get a release build?
<rick_h> antdillon: thanks, I'll create a card on the board for it and try to get some eyeballs on it after we get teh release issues worked through . 
<frankban> rick_h: yes, that's what I am checking with juju-core. Even like that, I am nervous making a release without being able to run the CI tests (and they are broken in canonistack for quite a while)
<antdillon> rick_h, Awesome thank you!
<rick_h> frankban: yes, agreed there
<frankban> rick_h: g++? is that a new requirement for the charm?
<frankban> sorry, hatch ^^^
<hatch> frankban: yes
<hatch> I'm not sure why though
<hatch> I just know that gary had an issue attempting to deploy when it wasn't installed
<frankban> http://nooooooooooooooo.com/
<rick_h> lol
<rick_h> npm dep requiring c-speedups? w..t..f 
<frankban> there is no mention of g++ in the charm sources, nor in our ppa (https://launchpad.net/~juju-gui-charmers/+archive/stable)
<hatch> can't we just add apt-get install g++ ?
<hatch> to see if that fixes it?
<frankban> I suppose we can
 * rick_h runs and gets more coffee...
<rick_h> I can't look
<hatch> hmm I think this shrinkwrap is busted
<hatch> it's changed a ton of versions
<hatch> on trunk I can no longer run make
<hatch> make: *** No rule to make target `app/assets/javascripts/d3.v2.js', needed by `build-shared/juju-ui/assets/modules.js'.  Stop.
<hatch> d3.v2 was removed....
<bac> hatch: make clean
<frankban> hatch: we switched to d3 v3
<hatch> yeah... I did a fresh checkout
<hatch> hoping that fixes it
<hatch> yeah must have had something hanging around
<hatch> frankban: is it attempting to build now with g++?
 * benji reboots
<bac> sinzui: staging.jujucharms.com is broken when trying to view a specific charm
<bac> sinzui: can i get login access to staging?
<frankban> hatch: right now I am trying to understand what revision introduced this regression. rick_h: this is not an old bug, juju set -e go juju-gui juju-gui-source=lp:juju-gui:897 worked well
<sinzui> bac, sure. It is just a special nova file to source
<rick_h> frankban: I'd assume it was gary's branch that changed the shinkwrap.json?
<bac> sinzui: i noticed staging was dead after i pushed my bundle branch.  sadly i didn't check it before so i don't know if that is the culprit
<sinzui> bac.  mongo is angry
<sinzui> OperationFailure: !loc.isNull()
<frankban> rick_h: I am testing revision 917. then I will go with 918, which is Gary's branches I merged this morning. 
<adeuring> abentley: seems that the mongodb on staging is badly broken. Try to access any charm deital page...
<adeuring>   File "/home/webops_deploy/charmworld/local/lib/python2.7/site-packages/pymongo/mongo_client.py", line 789, in __check_response_to_last_error
<adeuring>     raise OperationFailure(details["err"])
<adeuring> OperationFailure: !loc.isNull()
<rick_h> frankban: rgr
<frankban> "Friday, never hesitate..."
<abentley> adeuring: looking.
<rick_h> frankban: I thought it was "Friday, never again"?
<rick_h> oh well
<abentley> sinzui: adeuring says staging mongodb is badly broken.  I am investigating.
<sinzui> abentley, well that is bad, because I switched it last night
<abentley> sinzui: Right.
<sinzui> and production switched 10 minutes ago
<abentley> sinzui: it has a relation error.
<frankban> rick_h: 917 fails with the same error. That's not Gary's branch
 * sinzui not see that
<sinzui> ah, yes I do see that
 * rick_h goes to look at 917
 * rick_h looks at hatch 
<bac> abentley: not sure if you saw my message, but this seems to have happened after i pushed a bundle branch to launchpad.
<bac> abentley: trying to ingest locally i get http://paste.ubuntu.com/5940134/
<teknico> ha-ha, hatch broke the world ;-)
<rick_h> frankban: ok, so something between 897 and 917?
<frankban> rick_h: yes, trying to re-run the config-changed hook after installing g++
<abentley> bac: Weren't we going to test locally before pushing?
<rick_h> frankban: can you try 915? I wonder if the scss stuff which broke some things is still there
<teknico> (sorry hatch, just teasing you :-) )
<rick_h> frankban: I wonder if there's more deps than just the scss package still in the npm file that won't work. 
<adeuring> sinzui: well, managae.jujucharms.com does not seem to be affected: http://manage.jujucharms.com/charms/precise/apache2 works,m while http://staging.jujucharms.com/charms/precise/apache2 fails
<bac> abentley: we talked about testing the deployer file against the deployer locally, which i did, but not about ingesting a local file.  once it was pushed on LP staging found it.
<sinzui> adeuring, agreed. the staging errors do not appear until 5 hours ago. We have seen this happen 3 weeks ago
 * sinzui off to present
<abentley> bac: I thought getting a working deployer file was my responsibility.
<bac> abentley: if the staging errors happened 5 hours ago then it isn't related
<hatch> frankban: let me know if adding g++ fixes
<abentley> sinzui: I believe the error is due to a stale charm-- it's running scripts/worker, which was supplanted by ingest-queued.
<bac> abentley: afaik, we never assigned tasks until this morning when i made kanban cards.  i sent a message here about it.
<sinzui> abentley, oh dear.
<sinzui> orangesquad: per https://docs.google.com/a/canonical.com/document/d/1AoMhTdrominYLBS8iHbZLW_Ji2OH3mNhUzoHjetnD9w/edit , you can see I ran /srv/deploymgr/charmworld restart
<sinzui> ^ I left a copy of all the commands run
<frankban> hatch: sure. rick_h: I'll try 915 later. Anyway, the real bug here is that our devenvs and our production env are really different
<rick_h> frankban: +1, I'll add a discuss card I guess. 
<hatch> rick_h: the reason for the shrinkwrap updates is because those modules specify loose deps so when shrinkwrap was re-run it updated those loose versioned deps
<frankban> rick_h: yes, please, thanks
<rick_h> hatch: yea, gotcha. just trying to find something that 'changed' recenly and that's hitting close to home
<rick_h> only other recent npm change I can think of is the scss work
<hatch> well node-gyp requires gcc and g++ on OSX so I'm going to assume that it's also missing on 12.04
<hatch> and for some reason it's exposed itself now...
<rick_h> so what needs node-gyp
<rick_h> yea, node-gyp is a native build tool, so something wants to build a native package compiling on the target. Why do we need that now all of a sudden?
<hatch> one theory is that it included a bin in contextify@0.1.5 but removed in 0.1.6
<hatch> but that's all I got
<hatch> :)
<abentley> bac: I have concerns that we may not be adequately filtering out bundles for API 2 that I wanted to discuss before pushing a bundle.
<bac> abentley: shall i delete the branch?
<hatch> rick_h: also the reason we are using node sass and not pysass is because the node stuff is automatically hooked up to our watch system
<hatch> where the python stuff isn't
<abentley> bac: if it's older than 15 minutes, it doesn't matter.
<bac> abentley: let's talk when you get a chance
<rick_h> grrr, I can't find anything that 'deps' on node-gyp. Just that it's installed globally and deps on npm
<abentley> bac: sure.
<rick_h> hatch: ok, yuea. It's in the contextify build
<hatch> cool I was right
<hatch> lol
<hatch> my hypothesis has now been confirmed
<frankban> benji, hatch, rick_h : installing g++ seems to fix the problem, I'll add the dependency in the charmers charm, then I'll merge the charmers charm into our juju-gui charm, and then I'll try CI again...
 * hatch waits for his interviews
<hatch> frankban: sorry about my timezone, I could have told you that sooner ;)
<benji> frankban: I'm glad you figured it out.  Do be careful with the merge.  It is my understanding that the charmers charm is old an disused.
<abentley> sinzui: The charm is not stale; the "scripts/ingest" script is broken.
<abentley> sinzui: Other methods of ingesting should work.
<frankban> hatch: we encountered this problem right before you arrived. We spent the Friday morning fixing other things, so do not excuse yourself for being in Canada
<hatch> lol
<rick_h> hatch: ok, so that's the d3 update
<rick_h> hatch: d3 requires jsom which requires contextify
<rick_h> frankban: so it all comes down to our d3 upgrade which was recent and probably broke it
<frankban> rick_h: yes, it seems so, double checking with CI
<hatch> this is my biggest gripe with node/npm
<rick_h> hatch: so that would explain why gary ran into the issue
<hatch> packages are like the wild friggen west
<hatch> where we're going - we don't NEEED stability
<rick_h> hatch: well, you'd expect that to be in giant letters in a changelog or something for going from 2-3. That's a big req change
<hatch> that's what I mean
<hatch> authors update deps with no testing
<hatch> then claim it works with every version of node by using the >
<hatch> npm is awesome - but I think it needs less features to restrict people to do the right thing
<hatch> sooooo many packages broke when 0.10 came out simply because they said they worked in >=0.8.x
<rick_h> everyone fights it though. Even python/pypi just recently stopped serving beta/alpha packages out as the most recent package by default. 
<rick_h> hah, yea when you know that anything > 0.8 would be an api break. It's the point of using big version numbers
<hatch> right
<hatch> so many people in the community release things using 0.x forever
<hatch> things never hit 1.0 release
<hatch> I think it's so they don't have to provide a stable product lol
<rick_h> meh, just ignore the 0. 0.7 to 0.8 to 0.10 == breaks
<frankban> benji: charms updated (fix added to charmers, and then merged charmers into juju-gui)
<hatch> awesome
<hatch> rick_h: rumor has it 0.12 will be 1.0 so we can hope :)
<rick_h> hatch: fine, then 1.0 to 1.1 will break :P
<benji> frankban: great! let me know when the GUI release is done
<frankban> benji: I'll let you know IF the release will be done
<hatch> rick_h: nope it's a 1.0 release, no api breaking changes allowed!
<hatch> frankban: lol
<hatch> be optomistic :)
<benji> heh, I guess that will work too 
<hatch> optimistic even
<hatch> I really need to get an irc client with spell check
<rick_h> jujugui looking for a second person to help review/qa antdillon's changes https://codereview.appspot.com/12343044
<benji> rick_h: I'll take a look
<rick_h> thanks benji 
<antdillon> benji, rick_h Thank you
<abentley> sinzui: Could you please review https://code.launchpad.net/~abentley/charmworld/ingest-uses-ingest-queued/+merge/178310 ?
<hatch> what's going on with the typography.less file?
<hatch> the type class name has no relation to the contents within it
<benji> rick_h, antdillon: I don't see a diff, only "error: old chunk mismatch"
<abentley> bac: Let's chat.
<rick_h> benji: hmm, working for me :/
<antdillon> benji, Working for me
<benji> hmm
<sinzui> abentley, r=me
<antdillon> benji, This not working? https://codereview.appspot.com/12343044/patch/1/1005
<benji> rick_h, antdillon: apparently only the side-by-side diffs are broken; the stright-up diffs are fine; I'll look at those
<rick_h> benji: ah, reitveld fail
<benji> apparently
<hatch> rick_h: frankban on my tasklist is to attempt to update our packages and node to be up to date next week (re your card in discuss)
<rick_h> hatch: yea, but the larger issue is more the diff in dev vs production
<rick_h> we should have hit this issue when d3 was upgraded, not a week later during a deploy attempt
<hatch> oh well prod will then need to be updated as it'll fall over hard :)
<rick_h> hatch: and it sounds like this g++ issue was hit, but not brought up. 
<frankban> hatch: cool, thanks
<hatch> somehow I ended up working on two branches at once
<bac> abentley: ok, can you set up a hangout?  i need to move rooms.
<abentley> bac: https://plus.google.com/hangouts/_/b3e9170262ba4b41f761dee440dcbb9ac111cf3d?hl=en-GB
<rick_h> antdillon: landing your branch. It won't be in the release today, but will be on comingsoon later today. 
<frankban> guihelp: http://pastebin.ubuntu.com/5940316/ I presume this only means that the unit tests in ie are particularly slow... Please confirm my impression
<frankban> rick_h: please don't land GUI branches
<rick_h> frankban: :/ sorry. Figured it was -r locked. It just completed
<frankban> rick_h: no worries. Does antdillon change need to be QA'd?
<rick_h> frankban: as to the test run, yea it says they passed, there's the skipped. Not sure why it said it can't complete. 
<antdillon> rick_h, Cool thanks
<rick_h> frankban: no, it was qa'd as part of review. Small css font changes to the browser
<frankban> rick_h, antdillon: so it will be included in the release. guihelp: please don't land GUI branches
<hatch> frankban: yes we have a number of unit tests which are skipped - they shouldn't be causing it to be incomplete though
<abentley> bac: The URL structure is http://manage.jujucharms.com/api/3/bundle/~sinzui/mysql-5/tiny as described here: https://docs.google.com/a/canonical.com/document/d/1H1PH0q9Mr8pSvTmRnEgptrlC-OQZK7i-Le-1SzpJG5Y/edit
<frankban> hatch: that can be a problem in CI tests, but it does not block the release. unit tests passed in firefox
<hatch> ok great
<hatch> I have huw's branch to land so let me know when it's ok :)
<abentley> sinzui: r325 and later should not be deployed to production.
<sinzui> abentley, understood. Since webops are off in 1h and I am away next week. I think we have little opportunity to shoot ourselves in the foot
<abentley> sinzui: Tarmac is no longer setting the revno of charmworld after landing.  The value is currently -1.  Suspect it's related to the lcy02 changes.  diogo isn't around.
<benji> call today?  Maybe it is at 11 since we'll not be doing a retrospective since Gary is out.
<hatch> benji: I was thinking at 10
<hatch> in 1h
<hatch> just the standup
<hatch> the retro was yesterday
<hatch> :)
<benji> cool, 11 it is ;P
<hatch> haha
<sinzui> damn it abentley. I swear that lazy service goes on holiday every time Diogo takes off work
<sinzui> abentley, surely tarmac  needs it ssh config changed
<abentley> sinzui: Yes, I expect that's the problem.
<hatch> rick_h: do you use vim in multiple terminal panels (using tmux or the like) or use some vim pane manager?
<rick_h> hatch: I use a tiling window manager + vim
<rick_h> tmux and such is just gravy and kept seperate
<rick_h> hatch: vim comes with 'pane managers' called splits. http://lococast.net/archives/111
<rick_h> and buffers really
<jcastro> we do charm schools with both vim and tmux splits
<hatch> right now I work in tmux splits but each window is it's own terminal so I always forget to add my ssh key or osmething to one
<hatch> which just irritates me heh
<hatch> so that's why I was wondering :)
<rick_h> hatch: use an ssh-agent
<rick_h> hatch: then you init your ssh key on boot and never worry about it again
<hatch> there is some wakoness to osx > ubuntu sshing
<hatch> I have to run `exec ssh-agent bash` every time
<hatch> http://fromanegg.com/post/45733384142/nfs-between-ubuntu-vm-and-osx-host
<rick_h> https://help.github.com/articles/working-with-ssh-key-passphrases says that on OSX they can be saved in the keychain
<hatch> it's not the passphrase
<hatch> it's that the env variables for ssh-agent don't exist
<hatch> I haven't spent the time to track that down
<hatch> but I'd need to run some auto commands from tmux to fix
<hatch> or something
<benji> bac: I've done everything I can do and am in a holding pattern at the moment; is there anything I can do for you?
<hatch> jujugui lf one review of https://codereview.appspot.com/12320044/ re-propose of huws branch with minor change
<benji> hatch: on it
<bac> benji: quick chat?
<hatch> thanks benji
<benji> bac: sure
<benji> guichat?
<hatch> frankban: can I merge into trunk yet?
<frankban> hatch: no
<hatch> ccccmmmmoooooooonnnnnnn
<hatch> ;)
<frankban> guihelp, please do not land GUI branches, I'll ping you later
<hatch> frankban: is there anything I can help with?
<frankban> hatch: not at the moment, thanks
<hatch> alright well let me know if you run into something that needs another set of hands
<frankban> guihelp: juju-gui 0.8.2 released \o/ Please feel free to restart landing branches. I'll live test it with juju-core.
<hatch> yay
<hatch> thanks a lot frankban you rock!
<frankban> benji: release work done
<hatch> jujugui - submitting branch
<rick_h> frankban: yay! thanks for bearing through all that 
<rick_h> sinzui: so is there a chance of a jujucharms deploy or it sounds like nadda IS help available?
<frankban> thank you for the help
<benji> frankban: great!  I'll proceed with my work now.
<sinzui> rick_h, slim chance. .5 hours left
<rick_h> benji: ^
<rick_h> in case that effects your work on the next step
<benji> sinzui: .5 hours left until what?
<sinzui> No webops
<benji> arg!
<benji> I'll see what I can do quickly
<benji> (without making things worse)
<benji> frankban: what is the release's version number?
<rick_h> I did 0.8.2 in the changelog 
<hatch> awesome, I was hoping it wasn't 0.9.0 :)
<frankban> benji: 0.8.2
<benji> that doesn't sound right, but we can argue about that when we have more time ;)
<benji> thanks
<rick_h> hatch: inspector should be 0.9 imo :)
<hatch> yeah!
<frankban> reliable CI should be 0.9 imho ;-)
<hatch> lol!!
<hatch> rick_h: I was also thinking a double bump to 0.10 ;)
<hatch> haha
<rick_h> frankban: hah! what is that?
<frankban> heh
<benji> sinzui: we are go for upgrade
<sinzui> benji, 0.8.2?
<benji> sinzui: yep
<hatch> jujugui branch landed - anyone else is free to submit
<hatch> jujugui guichat in 10
<hatch> kanban it up!
<bcsaller> the anticipation grows
<hatch> just wait
<hatch> it'll be huge!
<hatch> jujugui guichat in 2
<sinzui> jujugui 0.8.2 is deployed
<benji> yay!
<rick_h> sinzui: rock on!
<rick_h> benji: http://hg.python.org/peps/rev/82e24ac40255
 * benji looks
<hatch> rick_h: you can probably hold off on reviewing bcsaller's branch
<rick_h> hatch: ok
<hatch> there is a QA failure
<bcsaller> ha, great :(
<rick_h> hatch: ok, will ignore then. bcsaller ping when you're ready
 * rick_h is just happy he finds the qa stuff in other people's branches too :P
<hatch> haha
<hatch> bcsaller: review and qa done - I'm guessing there is a merge issue from trunk or something
<bcsaller> hatch: I can merge trunk and test it local 
<hatch> bcsaller: were you able to reproduce?
<bcsaller> hatch: no, I have settings, thats working fine. The new branch throws the styles off though so the placement of the indicators is wrong now, cleaning that up
<hatch> hmm
<bcsaller> hatch: I did have to take trunks version of viewlet-manager.handlebars in the merge though
<bcsaller> does bzr status show a conflict for you?
<hatch> cleaned it out and trying again
<benji> rick_h: I'm still not happy with docstrings being 72 characters, but those changes dull most of the pain :)
<rick_h> benji: yea, I've not done that one myself. I don't think the pep8 tool complains
<rick_h> benji: but yea, I like that it's less of "pep8 encourages longer lines" and more "pep8 lets you be stupid if you want to be, but don't expect us to use it that way"
<hatch> bcsaller: ok it all qa's fine now....sorry I must have broken something somehow
<hatch> although the styling on the settings panel is a little broken for some reason
<bcsaller> hatch: yeah, thats what I'm fixing now, thats a merge conflict
<benji> it really makes no sense to me, especially for the first line of a docstring which often has to be carefully constructed to convey what a funciton/method/class is about and still be less than 80 chars, now having to be even shorter will be highly irritating
<benji> plus, line wrapping tools have to be smarter because different chunks of the files have different rules
<rick_h> benji: yea
<frankban> hatch, rick_h: latest jenkins failures seem different: now the tests are started, and there is the ie failure in unittests (added a card). so, it seems the charm fix (g++) has been relevant for CI.
<rick_h> frankban: looking, I honestly hit delete assuming it was more of the same
<hatch> lol so did I
<hatch> :D
<hatch> oops
<hatch> we are horrible
<frankban> haha
<frankban> hatch, rick_h: I believe CI was right and we ignored it pretending it was a canonistack failure. That confirms we are horrible people and that maybe we really need to switch to ec2 or hp...
<hatch> haha
<rick_h> frankban: yea, I thought we were getting permission to go to ec2 for it
<rick_h> frankban: not sure where that dropped off
<hatch> rick_h: frankban yeah EC2 is in the pipe but we need to figure out account details
<hatch> whos gota pay yo!
<hatch> for friday funnyness http://yuireactions.tumblr.com/post/55786097549/watching-yeti-run-unit-tests-chrome-safari
<hatch> bcsaller: have a minute to guichat about these retry/replace/resolve buttons?
<bcsaller> yes
<hatch> ok heading to guichat
<hatch> bcsaller: I'm still curious about the setTimeout in inspector.js
<hatch> rick_h: you can review now....everything looks merged in properly
<rick_h> hatch: bcsaller's branch? /me goes to look
<hatch> yup
<hatch> bcsaller: lgtm'd
<rick_h> hatch: bcsaller what was with the timeout?
<rick_h> bcsaller: no tests for this?
<hatch> not sure
<hatch> grabbing lunch
<bcsaller> rick_h: hatch, sorry was out for a minute, the idea with the timeout was to remove the style after the transition has run, its supposed to display a background and then fade it out, after its gone I didn't want the style to remain on the node
<bcsaller> I think properly a transition helper that binds the transitioned event as noted is proper
<bcsaller> but I know other work is being thought about wrt animations
<rick_h> bcsaller: yea, I'm looking at the Y module for it to help catch the event. 
<rick_h> bcsaller: but not gotten it all setup right atm. 
<bcsaller> rick_h: no, me either, I'm happy to look into a transition helper though
<rick_h> bcsaller: in that case can the animation be set with the style change? /me didn't qa since hatch was. Are the two classes incompatible?
<sinzui> jujugui, does anyone have time to review https://code.launchpad.net/~sinzui/charms/precise/juju-gui/nagios/+merge/177588
<bcsaller> rick_h: you add the class to trigger the transition, but I wanted the class off the node at the end, not sure I really understand the question though
<rick_h> bcsaller: so instead of using the class resolved, can the animation be between .conflict and without?
<rick_h> so that removing the .conflicted triggers the animation, I'm looking at the css closer trying ot see
<rick_h> bcsaller: is there any qa instructions to generate a conflict to look at this?
<bcsaller> rick_h: on the CR/MP
<bcsaller> console tricks
<rick_h> ah sorry got it
<rick_h> bcsaller: the instructions aren't working for me. I'm getting an error on line 324: Simulate a conflict from the console:
<rick_h> bah
<rick_h> Simulate a conflict from the console:
<rick_h> error is that the object has no method 'get' for getting the 'model'
<bcsaller> rick_h: you deployed glance?
<bcsaller> hmm
<rick_h> bcsaller: yea, trying again. I originally deployed ceph and then went back and added glance
<bcsaller> rick_h: I think you hit the 'expose' bug, thats long standing
<rick_h> bcsaller: ah, yea I did touch that 
<rick_h> ok, will start clean and go again
<bcsaller> rick_h: yeah, those instructions modify service[0] with a key in glances config
<bcsaller> I could change item(0) to getById('glance') but...
<rick_h> bcsaller: all good. working on it
<rick_h> bcsaller: I can't get the animation to go. It's when I select one value over the other right?
<rick_h> then the checkbox goes away and there's a background color animation?
<bcsaller> rick_h: no, its not working properly :(
<bcsaller> I tried a few things, but I didn't get it to work
<rick_h> bcsaller: ok, so should we pull that out then?
<rick_h> or did you want to give it a go to fix it before landing?
<bcsaller> I could take one more pass at it. I sort of figured we'll get a better general answer to doing that type of thing in the near term
<rick_h> bcsaller: well, everything I've got going is specific per location of use
<rick_h> there's not really an "import animation...go" module coming from what I've gotten to work
<bcsaller> maybe I'll take a stab at it then. node.transition('class', transitioned_cb) 
<bcsaller> the cb could be used to do chaining if needed
<rick_h> bcsaller: well I note using single classes and duping them up
<rick_h> what I had hoped to test was that if we could add the transition to the .xxx.conflict
<rick_h> and then when .conflict was removed it would animate the background change
<rick_h> but having a hard time setting it up/getting that tested. 
<bcsaller> yeah, I'll poke at it again and write some tests since the general UX seems ok to people at this point
<rick_h> basically use .conflict as a base css and then add a .pending .resolved or something to help with the tweaks. 
<bcsaller> you got me thinking, I think I have something that might work
<rick_h> bcsaller: cool, does this work for all field types as well? checkbox and such?
<bcsaller> rick_h: input/text area are tested currently, haven't checked with checkboxes, I don't think we use them for config/constraints which is what this is for
<rick_h> bcsaller: ok, I know hatch had some stuff that dealt with boolean types and wanted to check if boolean config would come into play as a checkbox vs an input box for resolution UX
<bcsaller> rick_h: I think that was the 'use defaults or not' toggle and isn't part of the databinding
<rick_h> bcsaller: so in mediawiki for example, there's a 'debug' setting that's a checkbox in the config
<bcsaller> exposed is realtime, when you flip it, it sends the rpc and the delta will update it in place
 * bcsaller checks
<bcsaller> for me it says boolean -> false in the box, not a checkbox
<rick_h> bcsaller: ok, yea in the old UI it was a checkbox. 
<bcsaller> good line of questioning though
<rick_h> bcsaller: just checked it with the inspector and correct, there are only input boxes now. Hmm, so does that cast/work well? I'm wondering if that's a rabbit hole of 'FALSE' 'F', etc?
<rick_h> ugh, seems like a downgrade, but doesn't effect this then if everything's a text box. 
<bcsaller> looks like the template tries to do it properly with type=checkbox
<bcsaller> so some untested regression maybe
<bcsaller> and then I have to add support for this somehow
<bcsaller> the other issue is that a textarea with tons of content will give a bad UX with this design
<rick_h> bcsaller: yea, was going to ask about a textarea next. :/ 
<rick_h> I know we had some with the expanding textarea that were large config bits
<rick_h> bac: can you think of a good demo charm for a large bit of data in the config file?
<bcsaller> yeah, and it should work as it does now, but no max height it set or overflow: scroll-y or anything like that 
<rick_h> bcsaller: right
<rick_h> is it 'usable' I guess. 
<rick_h> at least to start
<bcsaller> the whole use case is pretty rare, so as a starting point I'm not that worried
<rick_h> right
<rick_h> ok, well I'm going to run away. Have a good weekend everyone. 
<hatch> bcsaller: mediawiki was a checkbox yesterday
<hatch> heh
<hatch> had*
<hatch> yeah on comingsoon
<hatch> too
<hatch> areyou guys saying that's a text input now?
<bcsaller> hatch: looks that way currently
<hatch> BUG WARNING
<hatch> :P
<bcsaller> hatch: ahh I see
<bcsaller> the ghost has it, the main doesn't
<bcsaller> isBool handling or whatever isn't common
<bac> rick_h: haproxy was the charm that initially had the problem with multi-line settings input
<hatch> bcsaller: ahh - they are using the same template so there is definitely a bug there somewhere
<hatch> I see that it's not your branch though
<hatch> filing bug
<hatch> https://bugs.launchpad.net/juju-gui/+bug/1207870
<_mup_> Bug #1207870: Boolean values aren't checkboxes on deployed services <juju-gui:New> <https://launchpad.net/bugs/1207870>
<hatch> bcsaller: I also noticed that the 'scale units' input value does not change as the simulator runs, known issue? (not caused by your branch)
<bcsaller> that used to work, for a long time
<jcastro> sinzui: thanks for that list
<bcsaller> hatch: I didn't know that no. sometimes I feel like our testing misses the mark
<jcastro> everything owned by charmers in precise is now README.md, I converted some from RST
<jcastro> I ignored personal branches and oneiric
<hatch> bcsaller: sometimes? ;)
<bcsaller> I was being nice
<hatch> bcsaller: https://gist.github.com/hatched/0ef6c3898dab4e3e1626 - don't shate the DOM tree ;)
<hatch> shake*
<hatch> no I'm not going to leave it like that :D
<bcsaller> hatch: no, thats bad, even an  _nodes in there, ha
<hatch> yeah I do what I can lol
<hatch> bcsaller: so should the simulator be able to react to these env commands?
<bcsaller> hatch: the simulator randomly sets unit agent states, it has nothing to do with resolving errors as hooks don't actually run in the sandbox
<hatch> oh right - so should we hook it up to react to them?
<bcsaller> its not the simulator that would matter. The result of resolved is just that the agent state should clear out of pending on core. So for example after the hook is retried the agent will update its state if it works
<bcsaller> resolve, means I resolved this async to the UI (gui or cli) and I'm telling the agent to try to continue with new hooks
<bcsaller> retry mean basically the same thing + run the hook that failed putting the unit into error
<bcsaller> the states coming from the simulator don't mean anything and there are no transitions happening relative to a given unit
<hatch> so the way to test this is to make sure that if I click on the button it ends up being sent to fakebackend
<hatch> for testing purposes
<abentley> orangesquad or benji or bac: Could you please review https://code.launchpad.net/~abentley/charmworld/polish-ingest-bundle/+merge/178376 ?
<benji> abentley: I'll take a look
<abentley> benji: How's the review going?
<benji> abentley: sorry, I was talking to Brad about his branch.  I'm looking though.
<benji> abentley: it looks good to me
<abentley> benji: thanks.
<abentley> bac, benji: I think bundle ingest might now be working.  I'm pushing a bundle branch to find out.
<benji> cool
<bac> benji: this one?
<benji> this one works :)
<bac> abentley: turns out since the URL we're serving up on was /api/ we already had support from the work we did in raleigh
<bac> if you look in views/api.py there is a bundle() method.  it isn't listed in routes
<abentley> bac: Oh, and that gives the bundle text, not metadata?
<bac> abentley: it does now.  :)
<benji> bac: the output is missing the outer mapping
<benji> bac: see http://paste.ubuntu.com/5941515/
<benji> the first is the output from the app, the second was the input
<bac> benji: yeah i saw that
<benji> oh, and _id shouldn't be in the output
<bac> benji: trying the deployer on http://paste.ubuntu.com/5941555/
<bac> benji: it seems happy.  :)
<benji> yay!
<benji> do all the relations get added and everything?
<bac> benji: don't know yet.  it ate the config without burping and is doing it's business now
<bac> benji: i think it parses it at the beginning so if it were going to be unhappy it would've complained early
<bac> may take about 30 minutes since i have to fetch the charms locally and then push to ec2
<benji> yeah, I would think so
<bac> benji, abentley: i've updated my branch at lp:~bac/charmworld/jam-bundle
<bac> i suggest replicating what i've done with the canonistack instance
<bac> benji: we also need to get gary to run it beforehand so charm fetching will not be necessary
<benji> that's a good point
<benji> so if this all works out the next thing we should do is write up a script for Gary to follow 
<abentley> bac: I'm not sure what you mean, but the canonistack instance is already fetching charms.
<benji> and include prep notes like that one
<bac> abentley: when you run juju-deployer it has to fetch all of the necessary charms
<bac> it may not be a big deal for him but it is for me since my ISP is so slow
<benji> we might also include usage instructions so he can build his own, I'm thinking he might want to make a more impressive bundle to deploy
<bac> benji: well, perhaps one with the gui in it
<abentley> benji: I think that's gravy.
<benji> If I were demoing it I would have the gui-pre-deployed so the audience can watch the bundle deploy 
<abentley> bac: So are you saying you'd like me to install your branch on the canonistack instance?
<benji> abentley: tasty, tasty gravy
<bac> abentley: yes and then run 'jam' on whatever bundle y'all decide upon
<bac> benji: yes, good point about having the gui up first
<bac> remember the bundle filename will be the basket name in the URL so make it meaningful
<abentley> bac: Your branch is in place.
<bac> abentley: great.  can you grab the bundle, rename it, and then run 'jam'?
<abentley> bac: I've already run jam on that instance.
<bac> oh, so what is the basket and bundle name?
<bac> abentley:  can you see the json at /api/2/bundle/<basket>/<bundle> ?
<abentley> bac: Yes.  http://162.213.34.16/api/2/bundle/mediawiki/intranet
<bac> so, we should be able to run 'juju-deployer -e ENV -c http://162.213.34.16/api/2/bundle/mediawiki/intranet'
<abentley> bac: Yes, I think so.
<bac> i've just done it locally and it seems to have worked.  would like to see someone else try
<bac> make sure you have lp:juju-deployer/darwin
<abentley> bac: I can't because that would dump it into the same env as 162.213.34.1
<benji> bac: I'll run it
<bac> benji: to ec2?
<benji> yep
<benji> is that ok?
<bac> yeah, great
<bac> that's what i did
<abentley> bac, benji: We've successfully ingested a bundle on staging: http://staging.jujucharms.com/api/2/bundle/~abentley/wiki-bundle-1/wiki
<benji> first I'll deploy the GUI so I can watch it work
<benji> abentley: cool!
<bac> abentley: from launchpad?
<abentley> bac: Yes.
<bac> cool
<bac> abentley: is that my latest branch running?  i see _id in the output but it should be stripped
<bac> oh, that's on staging
<bac> oi
<bac> man, i'm surprised it works at all
<abentley> bac: revno 336
<abentley> bac: 336 is what's on 162.213.34.16
<bac> abentley: ok, that makes more sense.  thanks
<bac> abentley: i'm confused by that data representation.  it doesn't match the code in r336 and won't work with the deployer
<bac> abentley: i see a problem.  i didn't properly delete '_id'.  i just pushed r337 which does
<bac> having it in there doesn't seem to hurt anything
<abentley> bac: Updated.
<bac> but the json shown on staging does not have the bundle name as the outer key
<bac> and it is showing the bundle representation not just the ['data'] portion
<abentley> bac: AFAIK you have not landed your code on trunk, so it is not running your code.
<bac> abentley: ok, that makes sense.  i thought you said staging had been manually updated to 336
<abentley> bac: No, I meant the other instance.
<bac> gotcha
<bac> benji: any progress?
<bac> benji: i need to step out for 30-40 minutes.  that ok?
<benji> I have the GUI up and am running deployer now
<benji> bac: yep, I have to go get the smallest York right now anyway
<bac> benji: url for the gui?
<benji> bac: https://ec2-54-227-91-238.compute-1.amazonaws.com/
<bac> thanks.  bbiab
<abentley> bac: In theory, I could force your code onto staging.  I was actually surprised you weren't targetting trunk.
<bac> abentley: it hasn't been reviewed
<bac> it is a bit hacky
<benji> bac: I'm running "deployer/bin/juju-deployer -e ENV -c http://162.213.34.16/api/2/bundle/mediawiki/intranet" now
<benji> (I had to put the path on the command to get it to work.)
<benji> bac: 2013-08-02 16:47:01 Deployment name must be specified. available: ('intranet',)
<benji> now running "deployer/bin/juju-deployer -e ENV -c http://162.213.34.16/api/2/bundle/mediawiki/intranet intranet"
<benji> bac: error 2013-08-02 16:48:02 Error getting status, is it bootstrapped?
<benji> I have ot go now, back in 30 or so minutes
<hatch> does the GUI know about the landscape URL?
<hatch> hmm the env commands are getting to rapi but the updates aren't updating the UI
<benji> heh, I trusted the copy-paste too much "-e ENV" bit me.  Trying again with no -e option
<hatch> benji: do you know if rapi is supposed to react to resolve commands?
<hatch> it receives them and says it responds
<hatch> but the resulting dataset never changes
<benji> I'm afraid I don't know.
<hatch> alright - I'm just trying to figure out if my code is broken or rapi :)
#juju-gui 2013-08-04
<huwshimi> Morning
<rick_h> morning huwshimi 
<huwshimi> rick_h: Hey
#juju-gui 2014-07-28
<huwshimi> Morning
<rick_h__> morning huwshimi 
<rick_h__> good flight?
<huwshimi> rick_h__: Yeah, not bad. Get home ok?
<rick_h__> oh yea
<rick_h__> nice direct single flight :)
<huwshimi> Nice!
<huwshimi> rick_h__: It's nice to return to see that change to connections :)
<rick_h__> huwshimi: :) 
<rick_h__> huwshimi: yea, I ping'd tim and said "Hey, I want to give you the FYI that we're going to make some waves about this up through Mark Ramm and up to Mark S if necessary"
<rick_h__> and his reply "already gone"
<huwshimi> hehe
<rogpeppe1> urulama: mornin'
<urulama> rogpeppe1: morning
<rogpeppe1> urulama: how did your trip back go?
<urulama> rogpeppe1: fine, thanks, came back to a rainy and foggy home :D 
<rogpeppe1> urulama: still quite nice up here :-)
<rogpeppe1> urulama: here's a review to brighten your day :-) https://github.com/juju/charmstore/pull/34
<urulama> rogpeppe1: looking at it 
<rogpeppe1> urulama: ta
<urulama> rogpeppe1: so you are not using your swap day?
<rogpeppe1> urulama: i think i'll take it tomorrow
<rogpeppe1> urulama: or... perhaps i might take it in two halves - this afternoon and tomorrow morning
<rogpeppe1> urulama: i did this PR on the train north
<urulama> rogpeppe1: great :D
<urulama> rogpeppe1: my kids are at home this week (kindergarden closed for their vacations) - so I'll probably work in the morning till 3PM and than continue at 8PM (our time), just to let you know
<rogpeppe1> urulama: (and i also have nearly done a signficant refactoring of the meta include stuff; i decided that the GetItem stuff was going to be too complex and inefficient.
<rogpeppe1> urulama: ok, good to know
<rick_h__> morning party people
<jrwren_> morning
<rick_h__> morning jrwren_, good trip?
<jrwren_> very good.
<rick_h__> awesome
<jrwren_> and you?
<rick_h__> tired, great sprint though. 
<frankban> rick_h__: do you have a minute to chat about bug 1348192 ?
<_mup_> Bug #1348192: series should not be determined to create machine until a charm is placed upon it <juju-gui:Triaged> <https://launchpad.net/bugs/1348192>
<rick_h__> frankban: sure thing
<rick_h__> frankban: invite me in and I'll join in
<frankban> rick_h__: https://plus.google.com/hangouts/_/canonical.com/gui
<urulama> hi there jrwren_, welcome back
<jrwren_> thanks urulama.
<rick_h__> jrwren_: so catch up on emails and we'll get a sprint summary email out in a bit 
<rick_h__> jrwren_: once you're caught up let's chat and see where to head this week?
<jrwren_> sounds great.
<rick_h__> luca: call today?
<rick_h__> or skipping?
<luca> rick_h__: oh!
<luca> rick_h__: I really wasnât watching my calendar
<luca> rick_h__: Iâll jump on, sorry
<urulama> hi there hatch
<hatch> hey urulama hows it going?
<urulama> hatch: great, thanks ... had a good way back?
<hatch> flight was delayed out of LHR so I had to spend the night in YYZ before getting back home
<hatch> at which point I rolled my ankle 
<hatch> lo
<hatch> l
<hatch> so no
<hatch> haha
<urulama> auch
<hatch> how was yours?
<urulama> nothing as drastic as yours ... taxi, bus, writing some docs at the airport while eating "great" food, landing in a rainy and foggy Slovenia ... and all the English complaining that they should of stayed at home :D
<hatch> haha
<urulama> hope your ankle is better now, otherwise your 1% of life in your work-life balance could be endangered!
<hatch> haha right
<rick_h__> hatch: are you on the search bug this morning?
<hatch> rick_h__ yeah I will be
<rick_h__> hatch: ok cool thanks
<frankban> rick_h__: it seems the API allows for hulk-smashing two different units in the same top level machine
<rick_h__> frankban: it works? I talked with someone on core about it and everything. I hope I'm not crazy
<hatch> I can't seem to be able to make g+ turn my London photo album into a story :(
<rick_h__> hatch: sometimes takes a few days
<hatch> oh ok I'll give it a wait 
<rick_h__> over 400 emails down to 280 go go go
<urulama> rick_h__: ctrl+a, mark as read :P
<rick_h__> :P
<rick_h__> frankban: sorry for the bug mail span
<rick_h__> I fail at tab mgt today
<luca> rick_h__: The summary is all good
<rick_h__> luca ty much
<luca> rick_h__: no probs
<frankban> rick_h__: I confirm juju stable allows co-locating two units. Do we still want to enforce one unit per container?
<frankban> (tried also on ec2)
<frankban> rick_h__: I'd suggest not to. And we can just add those checks: 1) on an existing machine/container, no services with a different series are allowed. 2) on a ghost machine/container, dropped units must share the same series
<frankban> juju-gui: are we aware of this bug? 1) go to http://comingsoon.jujucharms.com/ 2) drag/drop the mediawiki/single bundle 3) double click mediawiki to open the inspector 4) start zooming the canvas in/out and notice the mysql service box icon does not scale
<hatch> looking
<hatch> frankban working fine on OSX Chome 36.0
<frankban> hatch: chrome on linux here
<hatch> frankban chrome has a number of svg rendering bugs, on linux even more so, I wouldn't doubt that it happens :)
<frankban> hatch: works ok with firefox
<kadams54> frankban: I've seen problems with the SVG icons in Canary/Mac for awhile now. Like hatch says, seems to be something in Chrome/Canary.
<frankban> hatch: I can dupe it with OSX chrome 36  :-/
<kadams54> I don't know what, but it isn't fixed by switching Chrome versions or re-installing.
<hatch> really? any errors? I really can't repro
<frankban> hatch: no errors
<rick_h__> frankban: yea that sounds like a plan I guess. 
<rick_h__> frankban: and yea, we'll need to make sure the UX makes it make sense and help guide the user
<rick_h__> frankban: I hit that during my demo to mark and not sure what's up. Haven't investigated farther
<hatch> frankban so the label for creating a relation doesn't scale (as intended) but the icons both scale without issue here...
<hatch> frankban rick_h__  so we are allowing multiple units to be placed on the 'base container' via the GUI? 
<rick_h__> hatch: yea, something must have chnged since the demo and it seems it's possible now
<rick_h__> hatch: so the reason we killed it was the api didn't let us do it, but seems that's changed or I had a dream about it all back in the demo days
<hatch> hmm ok then - I am pretty sure there is still a bug somewhere in there because that's how kadams54 got into his broken state
<rick_h__> hatch: oh definitely, this is a bit outside of that stuff
<rick_h__> there's issues around series matching and container types allowed and more
<hatch> gotcha ok cool, just trying to stay in the loop :)
<rick_h__> heh, you and me both :)
<hatch> haha
<hatch> so it took me just over 1.5H to get from the office and through security in LHR and there wasn't a single delay
<rick_h__> yea, I know huw and I planned on 2hrs to get through airport and be there 2hrs early so left at 9am for a 1pm flight
<hatch> crazy how long it takes 
<rick_h__> hatch: jcsackett did we get anywhere with this 'major/minor uncomitted' stuff?
<rick_h__> I feel like we brought it up but can't find any notes/bugs/updates on that
<hatch> rick_h__ yeah the only 'minor' thing has been fixed
<jcsackett> rick_h__: it was referenced, but i don't recall serious discussion about it.
<jcsackett> rick_h__: i *think* hatch saw some stuff about it in one of the mockups.
<hatch> it was just setting of a config moved into the other list
<rick_h__> hatch: ok, I see your email to luca, you're set then? We have a bug/card to work on it?
<rick_h__> e.g. I can delete this email :)
<hatch> I did what needed to be done already - the new UI has a nicer implementation so we'll probably wait until that's done
<rick_h__> ok cool
<hatch> autocompleteDataFormatter is apparently undocumented everywhere wrt the autocomplete widget...heh
<rick_h__> woot
<hatch> do you remember where you found it?
<rick_h__> the source probably
<hatch> well it doesn't exist 
<hatch> heh
<rick_h__> jujugui call in 8
<rick_h__> jujugui kanban please
<rick_h__> hatch: oh, is that something I wrote then?
<hatch> haha yup
<hatch> bah clearly still jet lagged
<rick_h__> jujugui call now jcsackett 
<jcsackett> rick_h__: whoops, coming now.
<urulama> jrwren_: after you're done with reading docs, we could have a chat about that tomorrow morning (your time) ... rick_h__ want to join?
<jcastro> rick_h__, heya
<jcastro> rick_h__, so any progress on searching? 
<jcastro> I still can't find anything
<rick_h__> jcastro: yes and yes?
<rick_h__> jcastro: what's up?
<rick_h__> urulama: sure, happy to help
<rick_h__> jcastro: hatch is working on the bug for the autocomplete that came out, but not sure what you mean 'I still can't find anything'
<jrwren_> urulama: whenever you wish. I don't need to be done reading, I don't think :)
<jcastro> rick_h__, do you know if quickstart/deployer will work if bundles are in github?
<Makyo> REstart for updates, back in a sec
<frankban> urulama: created the card: add a command to start the server...
<rick_h__> jcastro: if you give it the raw bundle file (http://.....) it should work
<urulama> frankban: thanks
<rick_h__> jcastro: not sure on deployer, I know quickstart will use a url
<rick_h__> at least I believe it will
<urulama> frankban: i've moved it at the top, 1st card
<hatch> jcastro what are you searching for that you're unable to find?
<jcastro> https://bugs.launchpad.net/charmworld/+bug/1348290
<_mup_> Bug #1348290: charm searching returns odd results at times <landscape> <charmworld:Invalid by bac> <juju-gui:In Progress by hatch> <https://launchpad.net/bugs/1348290>
<jcastro> if you search for "hadoop" you get a bunch of crap
<rick_h__> jcastro: right, that's in progress right now
<hatch> yeah I'm working on that one right now
<rick_h__> jcastro: hopefully have a fix later today/tomorrow and we'll do a new release this week
<hazmat> jcastro,  rick_h__, deployer supports a bundle  url on the cli and also for internal imports
<rick_h__> hazmat: awesome
<jcastro> ugh, this sidebar is killing me
<jcastro> I totally don't understand
<rick_h__> jcastro: ? 
<jcastro> can we get the fullscreen search back?
<jcastro> rick_h__, I still can't use the gui to search for bundles and charms I want
<rick_h__> jcastro: rgr, went to PM
<urulama> jujugui: going afk for 3h ... see you later
<hatch> rick_h__ it seems that a number of people are using the autocomplete results instead of the real search results, maybe we should drop the autocomplete and put the autocomplete results in the sidebar...to avoid confusion 
<rick_h__> hatch: I think we can make the autocomplete better. I mean we're hearing a lot from a set of people using autocomplete because it comes up first. 
<rick_h__> I'm not sure the best answer is 'remove the feature' vs improving it
<hatch> right - but it's super confusing, even with it working properly you could get three mysql's (for example) all with icons all called 'mysql'
<rick_h__> hatch: otp but let's chat and see what we can do to make it better. 
<hatch> yeah sure
<hatch> I'm just thinking ahead
<hatch> ping whenever
<rick_h__> hatch: nothing says we can't not do that. show one mysql named service and move up other options
<hatch> maybe the issue is that we have never defined what AC was supposed to do, atm it's just a poor version of the real search results
<rick_h__> rgr
 * rick_h__ goes to get lunch
 * rick_h__ is back and such
<hatch> holy smokes qa'ing this bug is painful
<hatch> I mean...it's AMAZING
<hatch> ;)
<jrwren_> painfully amazing or amazingly painful or both?
<hatch> definitely amazingly painful
<hatch> ;)
<hatch> bbiab lunching
<rick_h__> hatch: let me know when you're back
<hatch> rick_h__ backattack 
<rick_h__> hatch: sorry, next call here. Will try to find a chance
<hatch> haha np 
<hatch> jcsackett are you around?
<jcsackett> hatch: what's up.
<hatch> jcsackett didn't you land a branch which fixed the /inspector/serviceName bug which caused it to lock up the charmbrowser?
<hatch> I know there was some issues but I thought we just ignored the /inspector urls for now
<jcsackett> hatch: i dealt with a couple dispatch issues around inspector, but i don't remember anything about locking up the charmbrowser.
<hatch> when I access a /inspector url the charmbrowser is blank and the charm details breakout is shown and blank
<hatch> on a real env of course
<hatch> this isn't ringing any bells?
<rick_h__> hatch: I've got 10min
<rick_h__> hatch: in the standup url
<hatch> ok joining
<hatch> it's taking a while to connect
<jcsackett> hatch: no bells have rung, but if it's only in a real env my guess is the retry loop is blowing its stack.
<hatch> jcsackett right - but there was some reason why you didn't fix it before
<hatch> I remember you started to fix it then quit for some reason
<hatch> but I wasn't sure where you quit at 
<hatch> because right now if you get handed a /inspector url the GUI  is useless because it errors out
<urulama> jujugui good night all
<hatch> jcsackett well I wasn't sure if this existed or not so I created another bug report https://bugs.launchpad.net/juju-gui/+bug/1349565
<_mup_> Bug #1349565: visiting a /inspector url in a real env causes the charmbrowser to be blank <juju-gui:New> <https://launchpad.net/bugs/1349565>
<jcsackett> jujugui: can someone take a look at https://github.com/juju/juju-gui/pull/459
<jcsackett> i guess two someone's per standup.
<kadams54> Lookingâ¦
<kadams54> jcsackett: comments added; let me know if I'm talking crazy talk.
<hatch> jujugui when addressing review comments wrt this new 2-review policy we should not rebase until the final merge in so that we can keep the comment history alive
<jcsackett> hatch: +1
<kadams54> hatch: +1, though I thought that's what we were already doing?
<jcsackett> kadams54: i think hatch means don't rebase between the two reviewers.
<hatch> yeah that
<kadams54> jcsackett: Oh yeahâ¦ I tend not to rebase until the very last step before shipit.
<kadams54> It scales nicely with N+1 reviewers ;-)
<jcsackett> kadams54: me too.
<kadams54> Definitely good to discuss thoughâ¦ that's one of the hard things as a newbie is the things that the team decided on in retros that's not documented anywhere.
<jcsackett> we should probably update the hacking docs with this stuff.
 * jcsackett calls "not it"
<rick_h__> jcsackett: hatch friday card?
 * rick_h__ runs away for to get the boy until later tonight
<rick_h__> have a good day all
<jcsackett> kadams54: you were not talking nonsense, for the most part--i'm going to look into the not using the DOM suggestion. see my response about the boolean parameter for finding things.
<jcsackett> kadams54: pushed the change.
<kadams54> jcsackett: cool, looking...
<huwshimi> Morning
#juju-gui 2014-07-29
<rick_h__> huwshimi: morning
<hatch> morning huwshimi 
<rick_h__> huwshimi: we went through notes from the sprint and instituted a 2 review policy for branches
<rick_h__> huwshimi: in order to build a bit of mentorship 
<huwshimi> rick_h__, hatch: Hey
<huwshimi> rick_h__: Ah great!
<rick_h__> huwshimi: also please make sure to add tags ot the cards to note who the reviewers are
<hatch> huwshimi saw this and thought of you https://www.facebook.com/1025thebull/photos/a.116850054996026.20819.116054921742206/753390941341931/?type=1&theater
<huwshimi> rick_h__: OK, what exactly do I add for the tags?
<hatch> huwshimi just your name
<hatch> er the reviewersname
<huwshimi> Ah sure
<huwshimi> hatch: Also, bears
<hatch> lol!
<rick_h__> huwshimi: the irc nick usually
<huwshimi> OK np
 * urulama changes location
<urulama> morning frankban
<frankban> morning urulama 
<urulama> frankban: do you know if actions are actually supported in core or are they just part of charm.v2 for now?
<frankban> urulama: not sure
 * urulama just got yubikey delivered ... 2FA SSO works as a charm now :D
<fwereade> urulama, frankban: fwiw, actions support in core is ongoing -- a bunch of the model is in place, the charm tools and the CLI/API bits are still in progress
<frankban> fwereade: good to know, thanks
<fwereade> urulama, frankban: bodie_ and jcw4 in #juju-dev are the guys with the most up-to-date info because they're the ones doing it :)
<urulama> fwereade: thanks. which schema are used? yaml or json or both even?
<fwereade> urulama, iirc it's using json-schema for validation, but it's represented in the charm as yaml -- but only things that can be represented as json and conform to the schema will be acceptd -- if that makes sense?
<urulama> fwereade: it does, tnx
<urulama> hi rogpeppe1
<urulama> rogpeppe1: just heading for lunch
 * urulama lunches
<rick_h__> morning
<rogpeppe1> rick_h__: hiya
<rogpeppe1> mornin' all
<frankban> guihelp: I need two reviews + QA for https://github.com/juju/juju-gui/pull/462 anyone available? thanks
<bac> morning
<rick_h__> morning bac
<rick_h__> safe travels home?
<bac> yes, safe. long but safe.
 * bac hides from huw
<rick_h__> heh
<bac> i'm really looking forward to the direct flight to FRA!
<rick_h__> bac: let's chat before the hangout to sync up. I wanted to catch you up on events from yesterday/today and then see what cleanup from the sprint you've got and such
<bac> 8 << 20
<rick_h__> lol
<rick_h__> bac: if you get bored and caught up before my call this morning ends (10:30 ish) a live env test of frankban's branch would be +++1 
<bac> rick_h__: sure, just holler
<rick_h__> https://github.com/juju/juju-gui/pull/462
<bac> will do, bored or not
<frankban> thanks bac 
<rick_h__> frankban: and we'll poke at the US JS folks for the review side
<rick_h__> maybe jcsackett and hatch or Makyo 
<frankban> rick_h__: +1
<bac> frankban: the vmware display checkbox you showed me has changed my life, or at least my vision. ty!
<jrwren_> urulama: the action commands aren't exposed at all in 1.20.1, so while some stuff might be there, its practically useless
<jrwren_> good morning ya'll
<urulama> jrwren_: and morning :)
<rick_h__> morning
<rick_h__> jujugui added cards for expenses. For the first time expenser people let me know if you've got questions. 
<rick_h__> remember to file per diem, except for the team dinner night
<jcsackett> rick_h__, frankban: i'm looking at the PR now.
<jcsackett> jujugui: i need a second review on https://github.com/juju/juju-gui/pull/459
<hatch> jcsackett on it
<jcsackett> hatch: thanks.
<hatch> rick_h__ expenses filed
<hatch> crap I forgot a day
<hatch> lol
<hatch> jcsackett done
<hatch> kadams54 I added your nick to the tags for jc's card
<kadams54> Ah yes, sorry
<hatch> hmm github created a new PR UI
<kadams54> hatch: yeah, seems like there's also some funkiness with avatars not showing up
<bac> frankban: i'm doing qa of your branch on ec2.  in mv if i select 'move unit' i get two drop downs.  one has '1' in it and the other 'kvm'.  if i click on the dropdown i get a blank popup rectangle that never renders.  is this due to your branch or another issue?  i'm using chrome on trusty.
<hatch> the tabs in the review now update the UI and change the addres bar but don't put history records in so the back button now FINALLY goes back to the pr list....yay!
<jcsackett> frankban: some comments (mostly questions) on your PR.
<jcsackett> bac: are you also reviewing frankban's branch, or just doing the QA?
<bac> jcsackett: i was asked to just qa
<bac> on a live env
<jcsackett> bac: dig.
<jcsackett> in that case...
<bac> frankban: you can see it here: ec2-54-187-78-196.us-west-2.compute.amazonaws.com
<jcsackett> hm, actually, probably should hold off on calling for a follow up review until i'm actually completely done.
<frankban> bac: not sure if that's my branch, never tried that path... I'll spin up an ec2 to check trunk
<hatch> jcsackett lol, didn't agree with kadams54  and I? ;)
<bac> kadams54: never heard, did your laptop survive the water mishap ok?
<kadams54> Thus far
<kadams54> Typing on it right now :-)
<hatch> niiiiiice
<hatch> I forgot about that actually
<hatch> that's good to hear
<hatch> thems is pricey
<hatch> frankban I'm a little curious about the `prepare` method - while I think it's a good idea to have something along these lines - could this not have been accomplished by setting the series on any parent when adding the unit? I think that follows how we have typically done things like this in the past. 
<kadams54> I was pretty worried that my laptop was going to explode somewhere over the Atlantic, setting luggage on fire. The plane would make an emergency landing, I'd be whisked away to a CIA secret prison somewhere to interrogate me on my devious plot, and the rest of you would never hear from me again.
<bac> frankban: will you ping me when your branch lands?  i want to check for that blank pop-up on comingsoon.
<frankban> hatch: that's another way to do that. I ended up with prepare so that we can avoid the clean up dances in the case the unit is unplaced. It seems to me more maintainable if we reduce the times/places where a record is mutated.
<jcsackett> hatch: huh?
<frankban> bac: sure, now I am in the middle of a review, will look at my branch later
<hatch> frankban good idea, we should revisit the other places where using this prepare strategy will make it a little nicer as well
<hatch> jcsackett oh you didn't make the change that kadams54 and I requested, just landed it without comment :P
<jcsackett> hatch: i did make those changes. 
<jcsackett> hatch: sorry, it seemed trivial so i made the change, rebased into clean commit, and landed.
<rick_h__> jujugui call in 10, kanban please
<hatch> jcsackett ohh odd, the diff didn't show it
<hatch> maybe GH is just being wonky
<jcsackett> hatch: it's the line below your comment (the @return) if you look at the files changed.
<jcsackett> hatch: oh hell, your other comment didn't show until just now.
<jcsackett> ...i *really* have issues with github comments showing up.
<hatch> lol
<jcsackett> hatch: and i don't agree, though.
<jcsackett> there's not identical paths.
<jcsackett> _selectMachineToken and _selectContainerToken are entirely different fn's.
<hatch> son of a
<hatch> ok you win this one eyes
 * jcsackett laughs
<jcsackett> i'll spot you not seeing that if you spot me not seeing your comment. :p
<hatch> haha ok deal
<rick_h__> jujugui call in 2
<rogpeppe1> frankban: your comment arrived *just* after i'd entered :shipit: ...
<rogpeppe1> frankban: will fix in next branch
<rick_h__> frankban: jcsackett bac jrwren_ call
<bac> rick_h__: did you want to catch up as you mentioned earlier?
<rick_h__> bac: definitely, I've got a marketing meeting in 7, after that?
<bac> rick_h__: sure
<bac> rick_h__: how long is that?
<rick_h__> bac: 30min but usually pretty fast as we've got nothing to report atm
<bac> ok
<rick_h__> bac: if you want to agree to meet post-lunc or something feel free
<rick_h__> even put somtehing on the calendar, after this I'm free for the day
<rick_h__> busy morning, open afternoon
<bac> 1pm would be better
<rick_h__> k, sounds good
<bac> i'll create a calendare
<rick_h__> ty much
<bac> s/e//
<rogpeppe1> rick_h__: still no movement on the PR, FYI
<rick_h__> rogpeppe1: ok, after this next call I'll look.
<rogpeppe1> rick_h__: ta
<rick_h__> maybe jrwren_ or jcsackett or bac can help poke at it in the meantime
<rick_h__> wtf, the last charmstore ci run was July 2?
<bac> rick_h__, rogpeppe1 i'll look at jenkins
<rick_h__> bac: ty
<rick_h__> ah ok, the merge one though has run a day ago
<bac> rick_h__: is there a hook on github that has to be enabled? i'm not an admin on juju/juju-gui nor juju/charmstore so i cannot investigate.
<bac> rogpeppe1: can you make me an admin on github for juju/charmstore?
<rick_h__> bac: looking, yea juju core turned everyone off but leads 
<rick_h__> I was adding our team back in second
<bac> rick_h__: but there is some hook that needs to be setup, right?
<rick_h__> bac: right, a webhook or it can be configured to do polling via cron
<rick_h__> but that's sub optimal
<bac> rick_h__: i'd prefer the hook
<bac> but that's why its just sitting there
<rick_h__> bac: ok, updated uiengineering perms
<rick_h__> see if you can see now
<rogpeppe1> bac: sure
<rogpeppe1> bac: what's your github username?
<rick_h__> rogpeppe1: he should have it now
<bac> bac
<bac> rogpeppe1: bac
<bac> yes, i do
<bac> rick_h__: is the same payload URL used for all projects on that jenkins instance?
<rick_h__> bac: I think so, it's got a key in it to match the github project name to tell them apart
<rick_h__> bac: but not 100% on that one
<bac> ok
<frankban> rogpeppe1: FWIW review done
<rogpeppe1> frankban: thanks a lot
<frankban> mp
<rogpeppe1> frankban: i'll introduce some more comments
<frankban> rogpeppe1: it would be great
<rogpeppe1> urulama can't make up his mind whether to join or leave :-)
<urulama> rogpeppe1: just joined ... did it sign me on and off all the time? 
<rogpeppe1> urulama: you joined then left, then joined again
<rogpeppe1> anyone know if it's possible to get github to email copies of my own comments as well as other peoples' ?
<rogpeppe1> it's awkward having the email thread without being able to see exactly what people are responding to
<hatch> rogpeppe1 not I have found
<rogpeppe1> hatch: ok, ta
<hatch> in the same vein however launchpad also desn't send those emails
<hatch> or include links to the branch/pr in question lol
<rogpeppe1> hatch: yeah, but codereview did
<hatch> ahh right
<hatch> gh could do so much better than they are doing
<hatch> it's sad really
<bac> rogpeppe1: i see your pr 34 from yesterday was picked up and merged properly.
<rogpeppe1> bac: yup, that worked fine
<bac> rogpeppe1: i'm running the jenkins tester manually.  the one that should've been run when you submitted the PR.  when it finishes i'll run the merge one manually too.
<rogpeppe1> bac: thanks
<bac> rogpeppe1: on github should we change the default branch to v4?
<rogpeppe1> bac: do you think the problem will have gone away now?
<bac> rogpeppe1: no reason to suspect that for the merge job
<rogpeppe1> bac: i'm not sure. it's still broken from the point of view of someone that actually wants a charm store
<bac> rogpeppe1: i don't understand
<rogpeppe1> bac: also we're going to rename the branch to v2
<rogpeppe1> bac: if someone types "go get github.com/juju/charmstore/cmd/charmd" it should currently work
<frankban> jcsackett: could you please ping me when my review is done?
<rogpeppe1> bac: but if we change the default branch, i don't think it will
<bac> rogpeppe1: ok
<bac> rogpeppe1: are you going to push again with frankban's suggestions?  if so, why don't you delete your :shipit: comment, push, and then add :shipit: back
<rogpeppe1> bac: i was going to add the comments at my leisure. i'd like to get it pushed before then.
<rogpeppe1> bac: but if it would make life easier for you, i can easily do what you suggest
<bac> rogpeppe1: if you did as i suggested i could watch to see if it triggered and if not, i would start a manual build.  but if your code is ready to land now i can trigger a manual build with that revision
<rogpeppe1> bac: i've re-added the :shipit:
<rogpeppe1> urulama: i'm considering changing things so that GET /$id/meta/$something just returns nil if $something is not relevant to $id (for example when trying to get bundle metadata from a charm)
<rogpeppe1> urulama: that would make it more consistent with the any anypoint
<rogpeppe1> urulama: but might be unpalatable to some
<rogpeppe1> urulama, rick_h__, bac, frankban: what do you think?
<rick_h__> rogpeppe1: hmm, I'd prefer to look if we can make the payload a common key and let the client decipher. Rather than bundle metadata, it's just metadata and you can get the same key from charm/bundle but with different contents clients can easily pick up on
<rick_h__> rogpeppe1: but that's top of the head response
<rogpeppe1> rick_h__: i'm not quite following you there
<bac> rogpeppe1: i'd think the client would want to know an irrelevant request had been made as it would indicate it was in error.
<bac> a nil response would mask the error on the client side
<rick_h__> rogpeppe1: sorry, was thinking more in a group response (search result, multiple ids, etc)
<rogpeppe1> bac: it's not necessarily an error - it just indicates that the requested metadata isn't relevant for that id (which is not necessarily something you can tell from the id)
<rick_h__> right, because of the flat namespace
<rick_h__> rogpeppe1: so my question is what bits of data to not apply?
 * rick_h__ loads up spec
<rogpeppe1> bac: and we specifically allow something like: GET meta/any?id=wordpress&id=somebundle&include=charm-metadata&include=bundle-metadata
<rick_h__> rogpeppe1: and I'd propose not to have charm-metadata and bundle-metadata, but a single metadata
<rogpeppe1> bac: (the irrelevant results are just omitted from each id as appropriate)
<bac> rogpeppe1: ok
<rick_h__> so that you'd say 'any/id=xxxxx&id=yyyyy&include=metadata
<rick_h__> and you'd have that key in all results
<rogpeppe1> rick_h__: i don't think that works so well
<rogpeppe1> rick_h__: because then you don't know what type you're expecting
<rick_h__> rogpeppe1: they specified an id, they have some clue. And it's easily decernable on the client end
<rogpeppe1> rick_h__: the rule is (currently) given a metadata endpoint, you know exactly what type you're going to get
<rogpeppe1> rick_h__: and that works really well with Go
<rogpeppe1> rick_h__: it means you don't have to any dynamic shenanigans to try to duck-type the response
<frankban> rogpeppe1: IIRC in the any endpoint it's easy for the client to understand if the requested key is not relevant, the corresponding meta field is missing. I'd be +1 on doing the same with the single call it's clear when the data is not relevant (nil?) vs the data is empty
<rick_h__> rogpeppe1: well implementation language aside, it seems crazy to me to have to specify the charm- and bundle- in that request. Not only did I tell you I want the metadata for bundle1234 but that I want bundle-metadat vs charm-metadata? They're mutaully exclusive
<rogpeppe1> rick_h__: metadata isn't the only field that is bundle- or charm-specific
 * frankban bbiab
<rogpeppe1> rick_h__: for instance, bundles-containing is only relevant to charms
<rick_h__> rogpeppe1: ok, so it's an implementation simplicafication vs a user experience simplification that we're disagreeing on. Which to prioritize it seems?
<rick_h__> rogpeppe1: ok
<rick_h__> but then we'd allow a bundle id to be passed to that end point without any notification to the user that it's not a valid argument?
<rogpeppe1> rick_h__: which is simpler is somewhat subjective, i think
<rick_h__> rogpeppe1: I agree it's subjective. 
<rogpeppe1> rick_h__: currently we have a strong invariant in the API that the client knows exactly what data to expect back for a given endpoint
<rick_h__> when the json data is cast to mongo models is the metadata not able to be determined/created at parse time? I mean you're either going to have a lot of checks in the code for 'xxx.bundle-metadata is not nil' or 'xxx isBundle' either way?
<rogpeppe1> rick_h__: i *think* returning nil is reasonable - a valid bundle will never have nil metadata, so it's easy for the client to determine what it means
<rick_h__> a charm will have nil metadata?
<rogpeppe1> rick_h__: a charm has a nil *charm.BundleData but a non-nil *charm.Meta
<rogpeppe1> rick_h__: in the entity doc
<rogpeppe1> rick_h__: there are no "is-not-nil" checks necessary.
<rick_h__> ok, so if uros and frankban are on board I will defer. I'm not a fan and it seems like Go leaking into ideal functionality of the api, but oh well I suppose if everyone else agrees.
<rogpeppe1> rick_h__: another one: should we return an error if the client asks for a charm's actions but there are none?
<rick_h__> so the api is http. If you ask for something and it's part of the main url, you'd get a 404 I'd imagine
<rick_h__> however, an a bulk call the request was successful, however, some recoreds might not have that data
<rick_h__> so an empty set
<rogpeppe1> rick_h__: yeah, it's the conflict between bulk api calls and normal calls that i'm trying to reconcile
<rick_h__> rogpeppe1: understood
<rogpeppe1> rick_h__: it would actually be easier for me to consistently return a 404 error for any data that happens to be nil.
<rogpeppe1> rick_h__: but i *think* it's nicer not to
<rogpeppe1> rick_h__: as the endpoint is really found - it just doesn't have any data stored there
<rick_h__> but this is what I mean. If the user is passing a list of mixed ids, and asking for an array of metadata in a single call, 404'ing because one item doesn't have data X seems broken
<rogpeppe1> rick_h__: definitely
<rogpeppe1> rick_h__: that's why the API specifies that irrelevant results are omitted
<rick_h__> however, if I ask you for the field X on id Y and it's not there, 404 is the standard 
<rick_h__> so I'd never expect a bulk call to return a 404, but a single I would. 
<rick_h__> what else would you send back, just a {} 
<rogpeppe1> rick_h__: just null.
<rick_h__> you'd not have an idea if the id wasn't found, or there was no metadata, or that it's there but nothing
<rick_h__> it needs more context in a single call imo
<rick_h__> if we were to go against http and always return a value, we'd need to return a message as to what happened
<rogpeppe1> rick_h__: if you get null, you know that the id was found and the metadata endpoint was recognised, but there was no metadata
<rick_h__> and if the id was not found you get a 404? 
<rogpeppe1> rick_h__: yup.
<rick_h__> and if there was metadata, but it was defined to be an empty set, you'd get {}}
<rick_h__> ?
<rogpeppe1> rick_h__: and if the endpoint wasn't found, you get an error
<rogpeppe1> rick_h__: (currently a 500, but that will change)
<rick_h__> well if the endpoint wasn't found the router would 404?
<rogpeppe1> rick_h__: not currently
<rick_h__> e.g. unroutable request, a 500 implies server side issue
<rogpeppe1> rick_h__: but it will
<rick_h__> ok, well I think it'd be good to define these cases and write out the suggested path for each
<rick_h__> make sure they're no conflating (one response type could be X or Y) and then review with the team?
<rogpeppe1> rick_h__: yes, this should definitely be better specified in the API doc
<rick_h__> rogpeppe1: thanks, I think I see where you're headed and it's probably the path, apologies for not being a huge fan and getting difficult. :) 
<rick_h__> sometimes takes some convincing
<hatch> frankban I have finally finished reviewing your branch - take a look and feel free to comment whererever necessary
<rogpeppe1> rick_h__: that's fine - i see where you're coming from too :-)
<jcsackett> frankban: sorry, hadn't seen that you had replied to my points. +1 from me, looks like hatch has some points still unaddressed.
<rogpeppe1> rick_h__: at the moment, i'm leaning towards returning 404 with a "no data found" message for any metadata that == null; and defining bulk endpoints to omit all null entries.
<rogpeppe1> rick_h__: that way, if a client cares, they can at least distinguish the 404 errors, but there's a clear and defined correspondence between single endpoints and bulk endpoints
<rick_h__> rogpeppe1: rgr
<rogpeppe1> rick_h__: rgr?
<rick_h__> sorry, that's probably not a term to use with a guy named roger
<rogpeppe1> rick_h__: lol
<rick_h__> rgr == 'roger' 
<rick_h__> sorry, grew up military
<rogpeppe1> rick_h__: not an abbreviation i've seen before
<rogpeppe1> rick_h__: which is strange, really
<rick_h__> I used to use it a lot more, but tried to stop since you've started 
<rick_h__> but once in a while leaks out of my brain 
<rogpeppe1> rick_h__: i don't mind - "roger" has a few meanings :-)
<rogpeppe1> rick_h__: how did you put those red "awaiting approval" sections in the bundle specification document?
<rick_h__> rogpeppe1: not sure I see the same thing. Nothing red
<rick_h__> there's some 'awaiting approval' because I don't have edit rights
<rick_h__> I can only 'suggest' 
<rick_h__> rogpeppe1: which shows to me as green
<rogpeppe1> rick_h__: ah, i see
<rogpeppe1> rick_h__: i see it as red
<rogpeppe1> rick_h__: but i'd quite like to do the same with the API proposal, so that you and others can see the proposed changes
<rick_h__> so in the upper right
<rick_h__> there's a drop down to swich modes
<rick_h__> switch modes
<rick_h__> "editing, suggesting, viewing"
<rick_h__> you can use that to 'suggest' I believe
<jrwren_> can you give example where you are thinking of returning 404?
<jrwren_> oh... e.g. such as GET ubuntu/meta/nope
<jrwren_> yes, that makes good sense
<rick_h__> right
<rick_h__> /mysql-13/meta/bundle-metadata
<rick_h__> is that a nil, {}, or 404?
<rick_h__> is part of the idea
<jrwren_> yeah... tough call.
<rick_h__> and /meta/any?id=mysql-13&include=bundle-metaadata
<rick_h__> how does that differ?
<jrwren_> i can see how that would differ
<jrwren_> /mysql-13/meta/bundle-metadata should 404 if /mysql-13/meta did not include "bundle-metadata" in the response
<rick_h__> right, that's what we're chatting about
<jrwren_> /meta/any should never 404 IMO, because that path exists. the query may not be valid, but that is not a 404 IMO
<rick_h__> right
<rick_h__> and I got sidetracked on helping not have nil's in the return bodies because charms/bundles have the same idea (metadata) but they're different sets of fields
<rick_h__> however I'm learning that my ideal duck-typing python ways might not be friendly to our work 
<rogpeppe1> bac: that PR still doesn't seem to have attracted any attention from the 'bot
<frankban> jcsackett, hatch, thanks for the reviews
<frankban> hatch: replied to your comments, do you want placeUnit to return (not raise) an error?
<hatch> frankban thanks
<hatch> frankban well we don't use the try/catch technique anywhere else in the GUI so it's not really a pattern we are used to
<hatch> I think I'd prefer it to return to follow some kind of convention
<frankban> hatch: no problem, I'll change it, and that's actually a good point
<hatch> great thanks
<hatch> frankban with all the Go you've been doing I'm surprised you went with the 'throw' vs a return by default ;)
<frankban> hatch: haha, you are right
<hatch> :D
<bac> rogpeppe1: ack.  will push it manually when i get off the phone
<rogpeppe1> bac: ta!
<frankban> hatch: anyway, more than once while writing this branch I tried to avoid using var by doing "x := value"... 
<hatch> frankban haha it is a nice syntax :) 
 * rogpeppe1 is done for the day
<rogpeppe1> g'night all
<frankban> night rogpeppe1 
<rick_h__> bac: another thing we might look at is duping the jobs and setting one up for master and another for v4/v2
<rick_h__> so that there's less cross contamination potential
<rick_h__> jujugui: going to step away for a walk. biab
<bac> rick_h__: ack.  i just discovered there is no develop.ini file...  that could be a big issue.
<rick_h__> bac: development.ini?
<bac> yes
<rick_h__> it can't work without one so must have been there. :/
<rick_h__> interesting
<bac> rick_h__: i'm surprised anything works.  especially if that file didn't get recreated when we brought the env back up
<rick_h__> bac: right, no idea how that works since it holds the keys
<rick_h__> and gui landing is working?
<bac> no, its there
<rick_h__> oh, but the charmstore isn't in the list of projects?
<rick_h__> in that ini file?
<bac> i was looking in the workspace version of the lander not /var/lib/jenkins/jenkins-github-lander
<rick_h__> ah ok
<bac> yes, charmstore is correctly in that file
<bac> rick_h__: sorry, go walk
<rick_h__> bac: heh all good thanks
<rick_h__> hatch: approved your holiday. In the future please not the name of the holiday in question
<rick_h__> Makyo: also got yours
<rick_h__> and now I run away for a bit
<hatch> rick_h__ ok will do thanks
<frankban> bac: FYI, I just :shipit: the GUI branch, hopefully it will get merged soon. done for the day, have a good evening!
<bac> urulama: still around?
<bac> jujugui: found the jenkins problem.  this PR https://github.com/juju/charmstore/pull/23 has an unknown source repository, which breaks jenkins.
<bac> jujugui: anyone know how this happened?  just deleted the repo on github?
<bac> hatch: ^^
<hatch> yeah the source repo was probably deleted but the pr was left
<hatch> although the jenkins thing should probably be resilient enough to handle that :)
<bac> yeah
<urulama> bac: hi, around somewhere ... yes ... my fault for doing that early in the morning ... was trying to delete a branch that is not forked from charmstore, but ended up deleting the wrong one
<bac> urulama: ok, just gathering information for my bug report upstream
<urulama> bac: didn't think it will break up CI :(
<bac> urulama: not your fault
 * urulama puts on a "dunce" hat for today
 * Makyo -> appointment 
<urulama> bac: i'll probably close 40 as well, as 39 completely breaks how tests are done ...
<bac> huh, looks like rick_h__ *is* the upstream...
<jrwren> this is me grumbling about being a go nube.  *grumble*
<bac> rogpeppe1: your pr/39 got merged.
<rick_h__> bac: yes, that's my tool from when we first did GH move
<rick_h__> bac: thanks for locating that
<bac> rick_h__: i've also installed mailutils and added a MAILTO to the cronjob so i'll get email when the cronjob fails
<bac> if it works
<rick_h__> bac: woot
 * rick_h__ goes off to get the boy for swim class. 
<jcastro> rick_h__, is there a way we can just blow away oneiric from the store?
<hatch> jcastro short answer is no
<hatch> it can be done but will require work to do so
<hatch> jcastro the branch which I'm about to propose puts the charms that match your environment first in the autocomplete list
<jcastro> I mean more for search results
<jcastro> though that does sound useful!
<jcastro> like, I search for phpmyadmin and I always end up one one-eyed-rick instead of precise/trusty
<hatch> lol one-eyed-rick
<hatch> but yeah so that will change soon but to remove the oneric ones from the store requires quite a bit of launchpad/charmworld work
<hatch> PR's accepted? ;-)
<bac> jujugui: charmstore and charmstore-merge CI are temporarily not pissy.
<bac> http://ci.jujugui.org:8080/job/charmstore/31/console
<bac> that one was run by magic
<bac> as it should be
<bac> jcsackett: is your ci happy?
<jcsackett> bac: it is, for the time being.
<jcsackett> bac: see other channel for some discussion of what was going on with it.
<hatch> jujugui lf a review and qa for https://github.com/juju/juju-gui/pull/463 plz and thanks
<jcsackett> hatch: so services have an attr called unit_count, which we manually update every time we add or remove a unit...what do you think about giving that a getter which just gets the count from the services unit list?
<hatch> jcsackett I thought we listen for change events on that?
<jcsackett> not to update unit_count. all the references to it have it being set when we add something. just did an ack across the code base to check.
<hatch> hmm that's odd I was sure we listen for changes on it, lemme take a quick peek as well
<hatch> oh right, unit_count is a property not an attr
<hatch> or at least it was
<hatch> there are a few places with d3 where we treat it was a property and others where it's an attr
<hatch> this is quite confusing
<hatch> update_service_unit_aggregates models.js:820 looks to be the place we set it
<rick_h__> bac: ty
<hatch> not sure we want to do that computation every time someone requests the unit_count?
<rick_h__> jcastro: I need to get stats to verify it's not used before we blow it away, but I'd like to. 
<rick_h__> jcastro: hatch is correct that the search issues will be fixed this week with his branch and the release we'll do this week
<rick_h__> jcastro: so it'll be more invisible, but they'll still be there. 
<jcastro> good enough (tm)
<jcastro> hatch, nice job pocket trains!
<hatch> jcsackett say there are 1000 units, and the user opens and closes the inspector a few times, that's going to incur a lot of overhead - is there a reason why you want to convert it to a getter?
<hatch> jcastro haha, I haven't opened that app in months :)
<hatch> my trains must be rusting by now
<hatch> I'm playing clash of clans now which involves even less work :)
<jcsackett> hatch: that method is nuts; why can't unit_count just always be service.get('units').count or whatever?
<jcsackett> what am i missing?
<hatch> hmm, there WAS a reason for this
<hatch> lemme do some quick testing
<hatch> see if I can remember
<hatch> bbias
<rick_h__> hatch: maybe related to when there was a dial showing unit counts on the service blocks?
<rick_h__> hatch: but just imagining
<rick_h__> I can't think of any case where we bug the heck out of services about unit counts. 
<rick_h__> en masse
<hatch> ahhh ok now I see why
<hatch> yeah this can now be dramatically simplified
<hatch> this was here because we didn't used to have a units model 
<hatch> so we tracked the statuses via the units state per service
<hatch> jcsackett so yeah if you wanted to big time simplify this then that should work - the only downside is I'm not sure we always want to show dying units in the count
<hatch> but maybe we do
<hatch> before we used to 'scale to a number' now we are 'scale by a number'
<jcsackett> hatch: dying units are still units; and we break those out in the service inspector.
<hatch> right - before you would say "I want to have 10 units" so we didn't want to count dying units because then we wouldn't scale enough up
<jcsackett> hatch: dig.
<hatch> now we say "give me 10 more units"
<hatch> so yeah you should be able to simplify that a bit 
<jcsackett> hatch: so you're +1 on unit_count being a return on the actual unit list count?
<hatch> curious why you want to do it at all though?
<jcsackett> hatch: otherwise i have to keep updating it when uncommitted units are added.
<hatch> ahh yeah
<hatch> there is a perf hit when having to count number of items
<hatch> but as long as we aren't doing it all the time
<hatch> like if unit_count is being called every s then that's obviously not going to be good
<hatch> 1s*
<jcsackett> near as i can see, it's called to fill out data on some renders.
<jcsackett> scale up UI shows the current count...overview shows the count...
<jcsackett> hm, what's this topology bit about.
<hatch> I have no idea
<hatch> not sure when Makyo  is back
<hatch> he would know what it's actually doing there
<hatch> I THINK that's doing the layout when you move something
<jcsackett> it's in "update" so that's a good guess.
<Makyo> I'm here.
<Makyo> Was at other computer, let me catch up
<hatch> ohh ok :) 
<hatch> Makyo https://github.com/juju/juju-gui/blob/develop/app/views/topology/service.js#L1214 
<Makyo> hatch, jcsackett It should be good as a getter - I think that's leftover from when we had separate views for services/services scaled by unit count
<Makyo> Yeah, we can get rid of that line.
<Makyo> Just a remnant of when service blocks were bigger for more units.
<hatch> Makyo so this can also go? https://github.com/juju/juju-gui/blob/develop/app/views/topology/bundle.js#L120
<Makyo> Yep
<Makyo> Value can basically always be 1, if it's required.
<hatch> then unscaledPack can also go because those were the only places it was used
<hatch> or is the unscaledPack required, just not the value?
<Makyo> unscaled pack is required, just not the value.
<Makyo> The built-in pack takes into account the canvas size, but all our canvases are infinitely large, so we have a hack around that.
<hatch> ahh ok 
<hatch> Makyo maybe at some point this should all be documented :D
<hatch> jcsackett so you got all of that stuff? ^
<hatch> jcsackett there are also two unit models, a "master" list and a "per-service" one
<Makyo> https://github.com/juju/juju-gui/blob/develop/app/assets/javascripts/unscaled-pack.js :P
<hatch> "interm fix"
<hatch> apparently circle jerking is the best technique 
<hatch> lol
<hatch> wow that was an unfortunate autocorrect
 * hatch hangs head in shame
<Makyo> I tried submitting a PR to D3 for that, and Bostock shot me down.
<hatch> circle PACKING
<hatch> ohh right I remember that discussion 
<Makyo> His response was "Just use GraphViz instead"
<hatch> lol hardly the solution 
<Makyo> Yeah :P
<hatch> I wonder if we could use react for this stuff instead of d3
<hatch> :)
<hatch> it might be simpler to understand 
<hatch> the dragging might be complicated though
 * Makyo rolls his eyes RIGHT out of his head, across the room, and out the door.
<hatch> hahahahaha
<hatch> well I mean because it can be treated as more of a black-box 
<hatch> pass data in, fancyness comes out
 * jcsackett laughs
<Makyo> Sounds like magic.
<jcsackett> hatch: yeah, unitcount is only going to work on the service's unit list.
<jcsackett> because its the service unit count.
<hatch> ahh right
<jcsackett> and i'll update the topology stuff to just use "1" there rather than unit_count, defaulting to 1.
<jcsackett> whee...deleting code we don't need...
<jcsackett> seriously, my favorite thing.
<jcsackett> (at least, my favorite code thing)
<hatch> haha yeah it's a nice thing to do
<hatch> now if we could just rewrite the GUI just imagine how much better we could do it.... :)
<hatch> hmm our coworking space is having an open house week next week....maybe I'll give it a go
<hatch> it's quite a drive though....
<jcsackett> we should totally rewrite the GUI. the entire GUI.
<jcsackett> that's an excellent idea. :p
 * rick_h__ threatens to send men in black suits to all your houses
<hatch> hahaha
<hatch> write it in Flash....that's the new tech...right? right guys??
<hatch> oo new nvidia driver release I wonder if there is also new Ubuntu nvidia drivers in the pipe
<urulama> hatch: hey ... wonna see smart lights all charmed up? amateur video at https://dl.dropboxusercontent.com/u/130538479/Juju-IoT.MOV :D
<hatch> say who what?
<urulama> was playing around and made a web service to control the lights in the house
<hatch> download no worky
<hatch> you should probably make the web service availabe online....I SWEAR I won't turn your lights on at 3am ;)
<urulama> of course, charmed up the service ... once actions hit juju-core, one can control the lights from juju-gui
<urulama> hatch: works on local net only ;)
<urulama> url is not working?
<urulama> https://dl.dropboxusercontent.com/u/130538479/Juju-IoT.MOV
<hatch> there it goes
<hatch> the first time it 404'd
<hatch> well, it's buffering now
<urulama> safari? it doesn't scale the video i think
<hatch> holy smokes it's still buffering
<hatch> lol
<hatch> there we go
<hatch> and it didn't work
<hatch> lol
<urulama> damn dropox
<hatch> hmm will try safari
<huwshimi> Morning
<urulama> morning huwshimi
<hatch> morning huwshimi 
<hatch> urulama so I just get a full screen image
<hatch> no play controls
<hatch> oh there they go
<hatch> must be just really slow
<urulama> seems like dropbox doesn't work well over continents
<urulama> i'll upload it on my server tomorrow
<hatch> it's sending the packets by a messange-in-a-bottle protocol
<urulama> :D
<hatch> oh it's speeding up
<urulama> now that huwshimi is online it really is a signal to go to sleep :D
<hatch> haha
<hatch> urulama it loaded
<hatch> really cool :)
<hatch> urulama it's got to be, 12am there by now? :)
<urulama> 1am to be exact
<urulama> but wanted to finish this today
<urulama> :D
<urulama> was on my mind from the first week i arrived, and, well, we can't let undone tasks slip by, do we :D
<hatch> haha well looks cool - do you have a blog? You should put up some vids on youtube and some blog posts
<hatch> spread the juju love
<urulama> khm, why not :D i'll do that
<hatch> :) 
<urulama> it'll be really cool once we have actions and can be done directly in gui 
<hatch> definitely, `juju deploy house-lighting`
<urulama> indeed ... ibeacons are next (the proximity sensors from apple) :D
<urulama> control your juju env by entering the room :D
<hatch> have you done any stuff with bluetooth dev?
<hatch> I've been looking at doing some stuff with TI's sensor tag
<hatch> but time....
<hatch> hah
<urulama> ibeacons are actually LE BT devices
<hatch> yeah but locked into apple
<hatch> I'm not to big on that
<hatch> :)
<urulama> i don't think they are ... 
<hatch> they start with "i" how could they not be?
<hatch> lol
<hatch> I'm pretty sure it's all closed source
<urulama> :D
<urulama> well, i got these ( http://estimote.com ) as a gift to play with ... 
<urulama> ok, time to go ... see you, well, today :D
<hatch> jinteresting...
<hatch> ok cya tomorrow 
<hatch> :)
<hatch> huwshimi when working on your branches keep in mind that we will be doing a non mv release this week so everything still has to look/work correctly without mv
<huwshimi> hatch: OK, np
#juju-gui 2014-07-30
<hatch> huwshimi you had some questions you sent in the email yesterday
<hatch> have you got those solved or do you still need a hand there?
<huwshimi> hatch: Not solved (no replies). I'm trying to figure out, in a machine/container token how I can tell if the machine/token has been deleted
<hatch> you can't, I'm not sure you can tell if anything has been deleted
<hatch> units, services etc
<huwshimi> hatch: Yeah...
<hatch> so when something gets deleted do we want to remove it form the db? probably not because then what if they change their minds
<huwshimi> yeah
<hatch> but with that said, that's how the units are done now
<hatch> see environmnt-change-set.js line 691
<hatch> relations are done the same way
<hatch> oh wait
<hatch> no that's only removing the ghost stuff
<hatch> hmm
<hatch> I have to finish cooking supper
<hatch> leave this with me and I'll get back to you when I'm done
<huwshimi> hatch: OK, thanks!
<Makyo> Supper or dinner?
<hatch> Makyo haha, supper
<hatch> :P
<hatch> huwshimi so unfortunately we have been pretty destry
<hatch> destructive when dealing with removing of relations
<hatch> and units so far
<hatch> so we'll have to go back and fix that
<huwshimi> hatch: Oh, so not going through ecs?
<hatch> but the only reasonable way I can think of is to have an 'ecs-destroyed' attr of some sort which we check when we decide to render things
<hatch> because what happens if we remove a service then the user decides to 'cancel' the ecs changes
<hatch> it needs to revert back as if nothing happened
<hatch> we can't do that if the service is gone
<hatch> but we need to signify it being gone in the canvas
<hatch> huwshimi so basically when a user destroys a deployed machine, it needs to mark on the model that it's in the queue to be destroyed
<hatch> but then if that ever gets canceled it needs to go in and set it back 
<huwshimi> hatch: So maybe I should land this branch with the correct states on the token and then once we have those flags we can hook it all up?
<hatch> yeah that's a good idea
<hatch> hmm
<hatch> huwshimi atm if you destroy a machine that's queued we just remove it from the db and it's gone
<hatch> so there will be no UI for that, but for real machines we have nothing to signify it's destruction
<hatch> huwshimi with that said you could pretty easily hack it into the ecs
<hatch> if you wanted to just play with it
<hatch> not sure if you want to tackle that task or if you want to push it off
<huwshimi> hatch: I'm a bit scared of that area. I might add the card to track the deleted state and then if no one gets to it I can take a look
<hatch> heh yeah there definitely be dragons there
<hatch> I have some ideas to clean it up but we aren't done adding features yet to know what we really need :)
<hatch> agile-yo
<hatch> huwshimi if you'd like to create a card and assign it to me I can do/start it tomorrow 
<huwshimi> hatch: Great, will do!
<hatch> and if you have some downtime today you could review my latest PR :) https://github.com/juju/juju-gui/pull/463
<hatch> tradezies 
<huwshimi> hatch: I'll take a look
<hatch> thanks
<urulama> morning all
<rogpeppe1> urulama: hiya
<urulama> rogpeppe1: morning
<rogpeppe1> urulama: here's a fairly trivial follow up to yesterday's PR, addressing frankban's comments: https://github.com/juju/charmstore/pull/43/files
<urulama> commenting the fieldinclude code?
<rogpeppe1> urulama: i didn't do very well there, in fact.
<urulama> rogpeppe1: those todo's about "return nil, err" ... did you find any conclusion yesterday?
<rogpeppe1> urulama: i'm just working on the spec about that actually
<urulama> rogpeppe1: excellent
<rogpeppe1> urulama: my current thoughts are these:
<rogpeppe1> urulama: any metadata that's not found will be defined to return null. In a single request, if null would be returned, a 404 "data not found" error is returned instead.
<rogpeppe1> urulama: in a bulk request, null entries are omitted from the returned map.
<urulama> rogpeppe1: without indication about error?
<urulama> rogpeppe1: what about these: return nil, fmt.Errorf("unrecognized metadata name %q", include)
<urulama> when handlers are not found
<rogpeppe1> urulama: that's considered a genuine error
<rogpeppe1> urulama: and will return an actual error accordingly
<rogpeppe1> urulama: the most significant change that implies to the current semantics is that if you ask for charm-actions and the charm has none, you'll get a 404 rather than null.
<rogpeppe1> urulama: i think that's kinda reasonable though
<rogpeppe1> urulama: what do you think?
<urulama> rogpeppe1: what if in that case {} is returned?
<urulama> rogpeppe1: what happens if you want charm-actions on bundle?
<rogpeppe1> urulama: if you want charm-actions on bundle, you'd get null too
<rogpeppe1> urulama: i *think* i'd prefer null rather than the empty object
<rogpeppe1> urulama: that way it's totally trivial for people to decide whether there's some data or not
<rogpeppe1> urulama: and in a way, there *are* no charm actions, so 404 is actually appropriate
<urulama> ok, so new semantics would be: return object if exists, return 404 if request is correct but object has no data and return nil if error occurs?
<rogpeppe1> urulama: the last isn't quite right - we'd return an error if an error occurs
<rogpeppe1> urulama: but otherwise that's right
<urulama> rogpeppe1: ? return nil, fmt.Errorf("unrecognized metadata name %q", include)
<rogpeppe1> urulama: that's returning an error
<rogpeppe1> urulama: (the nil is ignored if the error is set)
<urulama> and in bulk, they are just left out from the results, no messages
<rogpeppe1> urulama: yes
<urulama> ok, just that we add this to the Charmstore api doc
<rogpeppe1> urulama: i've added a paragraph to the doc. how does that look to you?
<urulama> rogpeppe1: i was just typing that i'm adding Entity struct to the Charm store API doc and i can add errors as well ... will look
<rogpeppe1> urulama: what's the Entity struct?
<urulama> doc.go
<rogpeppe1> urulama: you mean mongodoc.Entity?
<urulama> yes
<rogpeppe1> urulama: i think that's an implementation detail and as such doesn't really belong in that document
<rogpeppe1> urulama: (unless we add an "implementation" section)
<urulama> rogpeppe1: exactly, implementation details
<rogpeppe1> urulama: i *think* i'd prefer an entirely separate document to talk about implementation details
<rogpeppe1> urulama: the API doc is already quite long, and it's well scoped.
<urulama> rogpeppe1: ok, makes sense
<rogpeppe1> urulama: cool
<rogpeppe1> urulama: do we actually need an implementation document? i'd have thought that comments in the code might be better (and more likely to be updated when the implementation changes)
<urulama> rogpeppe1: maybe not implementation details but data handling doc ... i like it when it's documented which collections have what type of data ... more of a registry 
<rogpeppe1> urulama: i agree that it's great to have that stuff documented, but i think i'd prefer to document it in the code, so that anyone that reads the code will see it
<rogpeppe1> urulama: the mongodoc package seems like a potentially good place to add all those details
<urulama> rogpeppe1: that'll work too
<rogpeppe1> urulama: perhaps add a package-level comment in mongodoc?
<rogpeppe1> urulama: or...
<rogpeppe1> urulama: maybe a comment on Entity itself - we will in general have a single mongodoc type for each collection
<urulama> rogpeppe1: made a small task for latter, there's no hurry, just that we don't forget
<rogpeppe1> urulama: cool, thanks
<urulama> rogpeppe1: i've merged your versions and recoded charm actions ... do I create new PR and close #40?
<urulama> rogpeppe1: sorry, it seems as it is still #40
<rogpeppe1> urulama: it's up to you
<rogpeppe1> urulama: that's fine
<urulama> rogpeppe1: then pleas give a quick look at https://github.com/juju/charmstore/pull/40
<rogpeppe1> urulama: looking
<rogpeppe1> urulama: LGTM
<urulama> rogpeppe1: tnx, i'll wait for Jay to make a review as well (due to the 2people/review policy)
<rogpeppe1> urulama: ... or frankban, i guess
<urulama> rogpeppe1: we agreed that you and frankban are the final reviewer, paired with go "n000bs", so that we learn as much as possible
<urulama> s/reviewer/reviewers
<rogpeppe1> urulama: ok. i hope that won't impair velocity too much, given the time zone difference
<urulama> rogpeppe1: for mornings before US people arrive, it'll be us three, right ... i'll make the merge
<rogpeppe1> urulama: sgtm
<frankban> urulama: that's right. Jay or Brad, or JC I guess. anyway, you have my LGTM off the records ;-)
<urulama> i'll add a comment that dummy charm has actions in the charm.v2 repo implementation, just to make clear
<rogpeppe1> urulama, frankban: this PR implements the not-found-omitted logic as recently specified in the charm API doc: https://github.com/juju/charmstore/pull/44
<urulama> rogpeppe1: need to have a lunch now ... 
<urulama> (as we still have "stable" electricity ... strange weather)
<frankban> rogpeppe1: done
<rogpeppe1> frankban: thanks
 * frankban bbiab
<rogpeppe1> jrwren: any chance you could have a look at https://github.com/juju/charmstore/pull/44 please?
<rick_h__> morning
<rick_h__> rogpeppe1: he should be on in another 2hr
<rogpeppe1> rick_h__: ok.
<rick_h__> urulama: heads up, I added the 'changes' call to the api doc as well. 
<rick_h__> urulama: but didn't yet create a card for it and it's a bit undefined. I wanted to get other's opinions on if we could provide info on 'what' changed and such
<rick_h__> since you mention doc/spec editing
<urulama> rogpeppe1: looking at #44
<rogpeppe1> urulama: thanks
<urulama> rogpeppe1, rick_h__ ... if interested, yesterday i was playing around with the idea of "juju for home automation" and made a quick demo with smart lights. video here http://goo.gl/fh5rb2
 * rogpeppe1 downloads
<rogpeppe1> urulama: it's upsidedown for me
<urulama> argh
<rogpeppe1> urulama: cool though
<rogpeppe1> urulama: is that deployed locally?
<urulama> rogpeppe1: yes, it works on local net only
<rick_h__> urulama: cool, yea saw you and hatch talking about it last night. Juju fun time :)
<urulama> rick_h__: yes. had to get it out of my system :D
<urulama> rick_h__: there are some storms here and if i just disappear it's either net or electricity problems ... i moved to a house with a generator, however, better to let you know
<rick_h__> urulama: understood
<rick_h__> thanks for the heads up
<urulama> rogpeppe1: i like it how you've linked it to the doc
<rogpeppe1> urulama: cool
<urulama> rogpeppe1: the error handling that is
<urulama> rick_h__: thanks for changes call ... it looks like a general call, what about if we add bulk id handling to it as well? maybe people will be interested only in changes of few charms and bundles
<urulama> rogpeppe1: maybe a comment about nilHandler how it is used to simulate returned nil values by "real" handlers?
<urulama> rogpeppe1: or is it too obvious?
<rogpeppe1> urulama: i think it should be obvious enough
<rogpeppe1> urulama: in a subsequent branch i have actually deleted it
<rogpeppe1> urulama: and replaced it with constMetaHandler
<urulama> :)
<rick_h__> urulama: yep, open for debate/discussion there
<rogpeppe1> urulama, frankban: next up, the API test refactoring: https://github.com/juju/charmstore/pull/45
<urulama> rogpeppe1: in a sec, writing /changes api proposal
<rogpeppe1> urulama: np
<rogpeppe1> urulama: /changes ?
<rick_h__> rogpeppe1: do we have cards for each of these? I know there's a few reviews going on but nothing in review/kanban
<urulama> api test refactoring is on kandban
<urulama> rogpeppe1: https://docs.google.com/a/canonical.com/document/d/1TgRA7jW_mmXoKH3JiwBbtPvQu7WiM6XMrz1wSrhTMXw/edit#bookmark=id.i81dlcr3spp9
<rogpeppe1> rick_h__: i added one card after the fact
<rogpeppe1> rick_h__: the most recent one has a card already
<rick_h__> rogpeppe1: the one you're waiting for jrwren to review?
<rogpeppe1> rick_h__: we made a unilateral decision that delaying all branches for hours because of the time zone difference was not really a good thing
<rogpeppe1> rick_h__: so merged after just +1s from frankban and urulama
<urulama> rick_h__: #44 is already merged, frankban and i reviewed it ... the card is in landing
<rick_h__> rogpeppe1: urulama ok, we should chat then on methods to help bootstrap the less experienced devs without that then
<rick_h__> as I fear it'll leave a lot of code just landing before they get a chance to learn form it and be gone
<rogpeppe1> rick_h__: it's fine when everyone is online
<urulama> hangouts?
<rick_h__> the whole goal of spec'ing out a one month trial is to accept some pain for a limited time for the greater good
<rick_h__> urulama: I'm open for discussion, however monday we agreed to do this. Changing it up on the fly one day without discussion is disappointing from my POV
<rogpeppe1> rick_h__: but because github doesn't do prereq branches, it will really affect velocity badly if we can only merge when everyone's online
<rogpeppe1> rick_h__: i thought it was ok with two reviews in fact
<rogpeppe1> rick_h__: do we need reviews from all the new guys?
<rick_h__> rogpeppe1: right, I understand the pain point. 
<rick_h__> rogpeppe1: we've got matt, brad, jay all need to get up to speed from more senior go folks. They're all in US TZ and I know tha sucks, but if the branches are going up for review and landing before they see them it's not going to help them much.
<rogpeppe1> rick_h__: so what's the actual policy here on when i can land a branch?
<rick_h__> rogpeppe1: the policy is 2 reviews with a goal of trying to get a less experienced dev into one of those review
<rogpeppe1> rick_h__: does urulama count as less experienced?
<rick_h__> rogpeppe1: I understand not all will be possible, however I want to make sure it's the goal we're working towards and not only doing when 100% convienent
<rogpeppe1> rick_h__: i thought he did, hence i thought it was ok
<rick_h__> rogpeppe1: yes, sure. 
<rogpeppe1> rick_h__: ok, so all's good then, right?
<rick_h__> rogpeppe1: but your statement "we made a unilateral decision that delaying all branches for hours because of the time zone difference was not really a good thing" is what I'm speaking to
<rogpeppe1> rick_h__: ah, ok. that's actually not been the case.
<rick_h__> because 'unilateral' and 'not really a good thing' I'm not excited about here
<rogpeppe1> rick_h__: i would have liked to have roped jrwren in on the reviews too
<rick_h__> understand, you had a branch and got two reviews. That specific case is fine
<rogpeppe1> rick_h__: the "decided not to delay" remark was about that
<rick_h__> rogpeppe1: ok, as long as we're speaking to the single branch and not in general
<rick_h__> rogpeppe1: your comment seemed to imply a more broad policy shift
<rogpeppe1> rick_h__: i would have an issue if there were no new folks in roughly my time zone. i think it's important that we can land some branches before early afternoon.
<rick_h__> rogpeppe1: I agree and why it's nice having serveral folks in your timezone. However, if your next chunk of work is not immediately dependent on the previous branch, waiting a few hours on those to aid new devs would be ideal
<rogpeppe1> rick_h__: sure.
<urulama> rick_h__: i think that if it's early in the morning here for us, we should handle it, however, point it out to others, that these PRs have been reviewed (so that everyone is up to date - that's what i do first thing in the morning for example) and for our afternoon PRs, the policy from Monday holds as agreed. there might be some exceptions to the rule if two branches are really dependant on each other as one break the other 
<urulama> (as rogers API change and mine charms actions)
<rick_h__> rogpeppe1: and in that statement I'm ack'ing that if the next chunk of work is immediatly dependent that getting frankban and urulama as 2 reviews is peachy
<rick_h__> urulama: agreed
<rick_h__> I just want to all agree that " we made a unilateral decision that delaying all branches for hours because of the time zone difference was not really a good thing" is not in the spirit of our goal this month
<rogpeppe1> rick_h__: i agree with that
<rick_h__> ok, aplogies for the confusion
<rick_h__> bah, apologies
<rogpeppe1> rick_h__: although perhaps all new devs should try to look through (and comment on) all recent PRs, even if they have been merged before they looked.
<rick_h__> rogpeppe1: +1, and we'll do that. There's always a bit of a blocker on commenting on landing code as we chatted about in London. 
<rick_h__> but completely valid
<rogpeppe1> rick_h__: i'm not sure i remember that chat. is there an issue with commenting on code that's landing?
<rick_h__> rogpeppe1: ah sorry, other way around. I had that chat with someone else around your post-landed reviews. :)
<rogpeppe1> rick_h__: if i comment on something that's already landed, i'd hope that the remarks were taken into account in a subsequent PR (or replied to in place)
<rick_h__> rogpeppe1: yes, I defended the practice
<rogpeppe1> rick_h__: thanks :-)
<rick_h__> rogpeppe1: just ack'ing that for some folks it's more difficult as there's a feel of 'this is already ok'd and in the codebase'
<rick_h__> rogpeppe1: so making that the primary source of getting newer devs involved is less than ideal
<rick_h__> there's less 'communication' around those ime
<rogpeppe1> rick_h__: sure, review before landing is definitely better
<rick_h__> ok, <3 we're all happy agree'rs carry on kind sir. 
<rick_h__> and thanks for clarifying my mis-understanding of the board by noting the stuff I was looking for is landed. 
<BradCrittenden> rick_h__: you merged frankban's test-test branch on purpose, right?  caused me a little panic when i saw it had landed.
<rick_h__> BradCrittenden: yes, it seemed legit enough to add a year and harmless
<BradCrittenden> rick_h__: ok, great
<urulama> rogpeppe1: and we do not return strings (as another nil type)?
<rogpeppe1> urulama: strings cannot be nil
<BradCrittenden> dang, someone has stolen my nick.  must figure out how to get it back.
<urulama> rogpeppe: indeed. that's nice :)
<urulama> removing the comment
 * bac \o/.  take that ben a carson
<rick_h__> lol
<rogpeppe> bac: how did you get it back?
<jrwren> rick_h__: i took a look at https://github.com/juju/charmstore/pull/44 even though it landed. consider this less experienced go dev bootstrapped anyway :)
<rick_h__> jrwren: woot woot
<bac> rogpeppe: /msg NickServ RELEASE yournick yourpassword
<bac> rogpeppe: but you must have it registered
<rogpeppe> bac: ah, so he hadn't hacked your password, just taken the username when you weren't logged in
<bac> rogpeppe: yeah
<bac> my client dropped last night
<jrwren> I also tend to git/bzr log -p pretty much every checkout I checkout with git, as to see where the most recent activity is.
<rick_h__> jrwren: cool, yea just trying to look out for the new folks. The more effort put in the better for sure. 
<rick_h__> and we want to make it as easy as we can
<bac> rogpeppe: i'm looking at your pull request to see if i can get jenkins to kick off.  (again).  don't be alarmed.
<rogpeppe> bac: ok. jenkins seemed to work ok earlier, FWIW
<rogpeppe> q
<bac> rogpeppe: yeah, but when it adds the 'please test this' message it indicates it is unhappy
<bac> rogpeppe: so far i don't understand why it does that
<rogpeppe> bac: ah. i wondered what the significance of that was.
<urulama> rogpeppe: aaa, i see now what happened to nilMetaHandler :D
<rogpeppe> urulama: :-)
<rogpeppe> rick_h__: what column should i put branches that i've completed the coding on, but can't submit for review because of other outstanding unlanded prereqs?
<urulama> rogpeppe: probably in review
<rick_h__> rogpeppe: hmm, I'd put them in review and mark them blocked
<rogpeppe> rick_h__: ok, cool, will do
<rick_h__> rogpeppe: is there something we did to get into that pickle we need to address?
<rogpeppe> rick_h__: not really - just that since github doesn't do prereqs, it's not possible to have two reviews outstanding if one is branched from another
<rick_h__> rogpeppe: ok, yea then review/blocked I'd suggest. It notes the coding is done and we're trying to get it reviewed
<rogpeppe> rick_h__: sgtm. done.
<bac> rogpeppe: as an experiment would you add the comment "ok to test" to your PR please?
<rogpeppe> bac: which PR?
<bac> https://github.com/juju/charmstore/pull/45
<urulama> rogpeppe: i like how new api tests show which charms (bundles in future) we are using for tests and which calls are being made. actual testing code gets a bit more hidden than before, but still clear enough. like it
<rogpeppe> urulama: cool
<rogpeppe> urulama: it should make it trivial to add new metadata tests too without trying to remember all the contexts that the metadata can be returned in
<rogpeppe> bac: done
<bac> ty
<rogpeppe> jrwren: would you be able to take a look at the above branch, please?
<rogpeppe> frankban: too
<frankban> rogpeppe: on it
<rogpeppe> frankban: ta!
<urulama> rogpeppe: hope you don't have any plans to refactore these in near future :D
<rogpeppe> urulama: not currently :)
<jrwren> rogpeppe: looking at it now
<rogpeppe> jrwren: thanks
<urulama> rogpeppe: this errgo? https://github.com/jsimnz/errgo
<rogpeppe> urulama: no, github.com/juju/errgo
<urulama> rogpeppe: uu, nice
<urulama> rogpeppe: we should always use it probably
<rogpeppe> urulama: yeah.
<rogpeppe> urulama: my branch changes the whole code base to use it
<urulama> rogpeppe: whole charmstore?
<rogpeppe> urulama: yeah
<urulama> rogpeppe: that'll be fun to review :)
<rogpeppe> urulama: i have a tool to make the changes automatically
<rogpeppe> urulama: so it only took a few minutes to do it
<frankban> rogpeppe: done
<rogpeppe> frankban: ta
<frankban> guihelp are those cards in landing effectively landing? I just shipit before looking at the board and then I realized there is no space available
<rick_h__> rogpeppe: urulama your branches have landed correct?
<rogpeppe> rick_h__: not yet
<rick_h__> frankban: upping the total by one due to team size increase for the moment
<rick_h__> frankban: and looking into the cards.
<frankban> rick_h__: thanks
<rogpeppe> rick_h__: i need to add some more tests after frankban's review
<rick_h__> rogpeppe: ok, so the card should be back in review vs landing
<rogpeppe> rick_h__: oh, those branches
<rogpeppe> rick_h__: yes, those have landed
<rick_h__> ok, yea I thought they had
<frankban> rogpeppe: store: isn't efficient getter for router landed?
<rogpeppe> rick_h__: i moved the card
<rogpeppe> s
<rick_h__> ty
<frankban> oh ok
<frankban> rick_h__: any suggestion for my next card?
<rick_h__> frankban: looking
<rick_h__> frankban: I'd love to have you and hatch looking at the deleted/removed work 
<rick_h__> frankban: huw sent an email to the list about it on Monday night around trying to do the UI for it, but we don't keep the removed 'ghosts' around 
<rick_h__> frankban: hatch should be in soon and maybe we should do a quick call to sync up on it, but you can start to peek at the issue?
<frankban> rick_h__: sure, looking at the email
<rick_h__> frankban: and https://pastebin.canonical.com/114475/ is the irc convo from last night
<frankban> rick_h__: so, UI needs to knwo when a real machine/container has been marked for removal, right?
<frankban> know even
<rick_h__> frankban: rgr, so that we can show the user that it's an uncommitted change
<rick_h__> we have a UX for remove unit, but not container/machine/relation
<rick_h__> so this is to help enable that work
<frankban> rick_h__: uhm, so a model attribute? Or am I missing something?
<rick_h__> frankban: that's what I want to figure out. What people think is the best path forward. If we go a model route, then we need to make sure we don't remove the models from the db
<rick_h__> and update any code reading 'number of machines/etc' to be aware of the attribute
<rick_h__> or that we store them in another collection? Or something else?
<rick_h__> I just want to get more than hatch's brain on it and it might be interesting to implement given your other ECS work. 
<frankban> rick_h__: the more I think about the ecs stuff, the more I suspect a db based architecture (like the one we already have to maintain in parallel to the ecs records) is sufficient most of the times. In theory, we could resolve all the changes only inspecting the db. For the time being we also have the ecs machinery, but for new features most of the time it seems easy to me to just use the db to represent a state. config/constraints are different, and n
<frankban> eed more love, but for something like a "toBeRemoved" attribute I guess we can just mutate the existing db records
<frankban> rick_h__: but I also want to know what you/Jeff think
<urulama> rick_h__: what to do with misc card which is in tracking and is done? Just delete it?
<rick_h__> urulama: put it in daily call
<rick_h__> urulama: and we'll note that it's done/etc to the team and no longer tracking
<rick_h__> urulama: and then it'll just go to releaseable/archive like normal
<rick_h__> frankban: +1 on the db myself, but yea want to have a chat. 
<rick_h__> frankban: make sure we're not missing something better, and then we'll add the work to keep the db entries around, even in a remove where the models might normally be removed
<frankban> rick_h__: cool
<bac> rick_h__: did my email about expenses jibe with your understanding?  if so, could you approve it?
<rick_h__> bac: yes, will definitely go through folks expenses today
<rick_h__> bac: sorry I missed the date on the original email. 
<rick_h__> there's hatch 
<hatch> wasssuuuuuuuup
<rick_h__> hatch: when you get settled call on the ghost-removing items with ecs stuff?
<hatch> yeah sure, just got breakfast on the stove.....say, 10mins?
<rick_h__> hatch: rgr
<frankban> rick_h__: filed expenses and swap day
<rick_h__> frankban: ty for the heads up
<rick_h__> jujugui I've approved all expenses filed to date, jcsackett got your ec2 one as well I didn't know was there.
<rick_h__> oh and jcsackett is out today now that I look at HR heh
<jcsackett> i am?
<jcsackett> i shouldn't be.
<rick_h__> oh nvm
<jcsackett> i just filed for a half day on friday.
<rick_h__> well it says 8/30
<rick_h__> I have two things here
<jcsackett> ...
 * jcsackett opens hr connect, grumbling all the while.
<rick_h__> ok, so half day on friday?
<jcsackett> i have the one i just filed for friday, 8/1
<rick_h__> bah, I ok'd two things but I can't find them now that I hit approve
<jcsackett> and a swap day for 8/18
<jcsackett> (this being american dates, so it's probably the other way round in hr canonica)
<jcsackett> mind you, i totally believe it's saying the wrong thing, as there are myriad things it's telling me that aren't true at the moment. :p
<rick_h__> I've got the 15th of aug
<rick_h__> and the 18th of aug
<hatch> jcastro hey, I saw you upvoted a question on AU. I went to read the docs for his question and found them missing information on how to execute hook commands - is the hook commands api somewhere in these docs that I'm missing?
<rick_h__> are those both true?
<jcsackett> rick_h__: those are both true--the 15th was filed a while ago. i was just listing the recent ones.
<rick_h__> jcsackett: ok, think we're all good then
<jcsackett> hm. "awhile ago" might mean last week. my sense of time is a bit off. :p
<jcsackett> rick_h__: cool.
<rick_h__> I think I've approved everything everyone ever ... ran out of ever's ... wanted approved :)
<urulama> rick_h__: do expenses for "per diem" need to be added for each day? and if so, can lunch + dinner be just added as one entry?
<jcastro> hatch, https://juju.ubuntu.com/docs/authors-relations-in-depth.html and the next page I think
<rick_h__> urulama: so since not every day has each I prefer split, but people do add them for each day. They do need to be listed
<rick_h__> for instance, team dinner night you need to not claim dinner
<jcastro> hatch, I don't know if we have a list of things like getting the private and public address, I could have sworn we had one though
<hatch> jcastro right but neither of those says 'run this in  your hook script to access relation data'
<jcastro> marcoceppi, ^^^
<jcastro> yeah
<urulama> sure, but for other days, sould i write lunch+dinner or put two rows in?
<urulama> rick_h__: ^
<marcoceppi> jcastro: I'll use the answer I make to the AU question to update the docs
<jcastro> hah
<rick_h__> urulama: up to you. I prefer split, this goes to Mark so maybe he'll take the one row without issue. Do what you please. 
<hatch> marcoceppi :) thanks
<jcastro> hatch, real time docs
<hatch> marcoceppi maybe we need an 'api' section for these docs?
<bac> rick_h__: i've updated some of the git plugins on jenkins.  it requires a restart but the restart attempt is failing.  you ever restart jenkins and is there a trick?
<marcoceppi> hatch: we have that
<rick_h__> bac: no, not had issues restarting it. Just sudo service jenkins restart
<bac> rick_h__: fails
<rick_h__> bac: or using the restart button in the UI
<hatch> marcoceppi yeah? for hook commands?
<marcoceppi> after you sacrifice the chicken, you'll be enlightened with it's location hatch
<rick_h__> bac: will have to check the jenkins logs and see what's up then
<hatch> lol!!
<jcastro> marcoceppi, didn't we write up the mysql charm like this? 
<jcastro> I could have sworn we had a page where we documented the mysql charm and then were like "for the other ones, just derive what you've learned here."
<marcoceppi> when I have to run a grep on the md files, we're probably doing sometihng wrong
<marcoceppi> jcastro: vanilla
<marcoceppi> https://juju.ubuntu.com/docs/authors-charm-writing.html
<marcoceppi> oh
<marcoceppi> and the mysql interface
<hatch> marcoceppi haha 
<hatch> rick_h__ so did you want to have a chat?
<marcoceppi> https://juju.ubuntu.com/docs/interface-mysql.html
<rick_h__> hatch: yes please
<rick_h__> hatch: standup?
<jcastro> https://juju.ubuntu.com/docs/authors-charm-writing.html#writing-hooks
<rick_h__> frankban: ^
<hatch> yep joining
<jcastro> hatch, scroll down on that page
<hatch> jcastro I don't see a hook api?
<frankban> rick_h__: joining
<jcastro> I think we only have the one
<marcoceppi> jcastro hatch it was documented sometime
<marcoceppi> somewhere
<rogpeppe> frankban, urulama, jrwren, bac: trivial PR for review: https://github.com/juju/charm/pull/29
<jrwren> trivial ones are EASY
<urulama> rogpeppe: i liked this one :D
<rogpeppe> urulama, jrwren: :-)
<hatch> jujugui call in 1
<rick_h__> jcsackett: antdillon kadams &
<rick_h__> jrwren: ^
<hatch> great answer marcoceppi 
<frankban> hatch: PR url?
<hatch> https://github.com/juju/juju-gui/pull/463
<rick_h__> frankban: so you're ok creating a card for the flag/helpers on models as the first step from here?
<urulama> jrwren: sorry for putting such a card on, it was just a reminder not to forget this ... 
<frankban> rick_h__: +1
<jrwren> urulama: no no, its a good card.
<rick_h__> cool, thanks
<bac> rick_h__: on jenkins are we actualy using GitHub Pull Request Builder Plugin
<rick_h__> bac: it does the initial test run
<bac> rick_h__: i don't see it in the UI under plugins
<rick_h__> bac: so the non -merge jobs are that plugin I thought
<rick_h__> oh...then...huh?
<bac> but there is an error message that is coming from it.  so i'm confused
<jrwren> urulama: it should be trivial, but then its not once we look at certain features.
<rick_h__> bac: so maybe it's not in the UI because it's not loading properly?
<urulama> jrwren: need help splitting it in smaller tasks? otherwise feel free to do as rick_h__ suggested. 
<urulama> jrwren: which ones?
<urulama> jrwren: i meant which features?
<bac> rick_h__: there are several different github plugins and i'm not sure which are active
<jrwren> urulama: version config and mojo.
<rick_h__> so some require others to work if I recall
<rick_h__> bac: ^
<rick_h__> bac: can compare to the other insteance if that helps
<rick_h__> bac: can at least compare what it thinks is running and version check the two
<jrwren> urulama: its deceptive because version config doesn't make sense at the moment IMO.  Because v4 doesn't have a server. It probably will in a day or so.
<rick_h__> maybe see if we can downgrade it to match what's working there bac
<jrwren> urulama: so really only v2 makes sense IMO.
<bac> rick_h__: which other instance are you referring to?  curtis'?
<rick_h__> jrwren: feel free to add the server as a pre-req to a chunk of your card
<rick_h__> bac: moving to other channel
<jrwren> urulama: and mojo i'm still trying to grok its impact on the charm.
<jrwren> urulama: seems like what rick_h__ said makes good sense - do it in increments, just charm it up, then add these features.
<rick_h__> jrwren: urulama so how about we start with basic framing, repo, initial files/readme/etc
<rick_h__> jrwren: urulama and then start to look at any pre-implementation chats for each, etc
<urulama> rick_h__: yes. repo, skeleton, hooks, ...
<rick_h__> jrwren: urulama yep
<rick_h__> and we can work on iterating vs defining it all up front
<rick_h__> we know the big 'watch outs' as we go
<jrwren> ok
<rick_h__> jrwren: so feel free to add cards or if you're not sure let me know and we can create them together 
<jrwren> rick_h__: i'll add some.
<rick_h__> jrwren: realizing that at any time, if your chunk of work spins off new threads/pre-req's it's always ok to put one card back in the todo lane and build new ones as things because clear
<jrwren> rick_h__: urulama: is the focus here on the old version or new version or both?
<rick_h__> jrwren: new version only is the focus
<urulama> jrwren: charmstor branch v4
<jrwren> urulama: rick_h__:in that case, I need a server :)
<jrwren> urulama: rick_h__: i'll skeleton without for now.
<urulama> jrwren: what about if you play with local for a start?
<rick_h__> jrwren: urulama the server is in the 'old' code and a branch to add it to v4 would be ok as a first pre-req?
<jrwren> urulama: appserver.  equivalent of charmstored, I think it is.
<jrwren> err, charmd
<rick_h__> jrwren: the card for the server is at the top of the lane. 
<rick_h__> jrwren: feel free to move the charm card back, take the start command card, and move that foward. 
<frankban> hatch: why you changed envSeries to be a callable?
<rick_h__> jrwren: we'll break down the charm work and then be all set
<hatch> frankban because the envSeries isn't actually set until after the application is well-since loaded and operational 
<frankban> hatch: good, I suspected that, I'd suggest to add a comment explaining that
<hatch> so it would then need to be set again everywhere in the app when that changes
<hatch> ok can do
<jrwren> rick_h__: ok
<urulama> rick_h__, jujugui - I have to leave this plave as they are locking it down, hope internet at home is working already
<urulama> s/plave/place
<rogpeppe> urulama: ok
<rick_h__> urulama: best of luck
<urulama> there's always mobile data :D
<jrwren> rick_h__: alright, I made a few cards. You mentioned there was a specific place the charm repo should live?
<jrwren> rick_h: https://github.com/CanonicalLtd ?
<rick_h__> jrwren: yes, taking to the other channel
<hatch> rick_h__ if we are going to moveo to trusty being the default it should be done in a follow-up as it should be done whole hog throughout the app imho and there are a-lot of places where precise is being used :)
<rick_h__> hatch: understood
<hatch> sounds like a plan?
<rick_h__> hatch: and yea, I'm smitted with my idea of making the charm set the default. If I install the gui precise charm, it'd default to precise, etc
<rick_h__> hatch: but yea, that's outside of this current work scope, so carry on 
<hatch> :) sounds good
<rogpeppe>  cfrankban: i've updated https://github.com/juju/charmstore/pull/45 to add some sanity checking for the metaEndpoint.get functions
<rogpeppe> frankban: ^
<rogpeppe> and also updated the branch to use the gopkg.in/mgo.v2 (it was a hassle switching back and forth all the time)
<rogpeppe> frankban: PTAL
<frankban> rogpeppe: cool, I'll look in a minute
<rick_h__> what is PTAL? I keep seeing it but don't process it
<frankban> rick_h__: I suppose it is "please take a look"
<rick_h__> ah! that makes sense
<rogpeppe> rick_h__: actually, it's usually "please take another look"
<rogpeppe> rick_h__: at least, that's the way i use it
<frankban> heh
<rick_h__> gotcha
<rick_h__> that also makes sense
<hatch> it's also a guys name
<hatch> except there is an accent on the a
<hatch> :)
<frankban> hatch: review done
<hatch> frankban thanks for the qa, I'll have to look into that issue
<hatch> it's very puzzling 
<hatch> frankban ahh I see the issue
<hatch> bundles get returned in the autocomplete as well
<hatch> rick_h__ are we to show bundles in the autocomplete result set or just charms?
<hatch> they are shown atm
<bac> jenkins is now properly testing new pull requests for charmstore, e.g. http://ci.jujugui.org:8080/job/charmstore/33/
<frankban> bac: \o/
<rogpeppe> rick_h__: nothing can land on juju-core because it's blocked by critical bugs
<frankban> rogpeppe: lgtm
<rogpeppe> frankban: thanks
<rogpeppe> rick_h__: so despite having go ahead to merge that branch, i cannot...
<hatch> frankban branch has been updated with a fix - mind qa'ing again?
<frankban> hatch: sure
<rick_h__> rogpeppe: yea, their new policy. mark the card as blocked please
<hatch> thanks
<frankban> hatch: where can I see the code change?
<hatch> in the PR there is a commits tab
<hatch> it's the last commit
<frankban> hatch: ok
<hatch> frankban with our new review rules we have decided to not squash the commits until after the reviews are done and the branch is ready to land
<hatch> should help with reviewing and whatnot
<rick_h__> hatch: yes, bundles and charms
<rick_h__> bac: woot
<frankban> hatch: yes, I really appreciate the ability to just see what's changed after a review
<rick_h__> and rogpeppe :( sad but they needed to do that as core needs to get some unbroken love time. 
<rogpeppe> rick_h__: yeah, i think it's probably a good thing too
<bac> rick_h__: after lunch i'd like to fix the issue i opened against jenkins-github-lander.  it is a timebomb waiting for anyone using that tool.
<rogpeppe> rick_h__: but will probably cost another hour or two of bitrottedness updating
<rick_h__> bac: sounds like a plan. 
<bac> ty
 * bac lunches
<rick_h__> rogpeppe: understood, can't be helped. Thanks for the heads up
<rick_h__> urulama: ^
 * rick_h__ goes to get food
<hatch> frankban when a relation gets created in topology/relation.js it sets a 'pending' attribute to true just FYI https://github.com/juju/juju-gui/blob/develop/app%2Fviews%2Ftopology%2Frelation.js#L967
<frankban> hatch: so a ghost relation is called pending. I'd propose to use the isGhost attribute everywhere. Pending is a different concept, already in use in juju with a different meaning.
<frankban> hatch: isGhost and isRemoved
<hatch> frankban that's fine - I just wanted to point that out to you as it'll need to be renamed and the corresponding stuff which checks for it renamed as well
<frankban> hatch: yeah, ack
<rogpeppe> frankban, urulama, bac, jrwren: here's a branch to make us create more informative errors in the charm store: https://github.com/juju/charmstore/pull/47
<rogpeppe> it's also a prereq for generating sensible HTTP status codes
<frankban> rogpeppe: oh, the errgogeddon, on it
<rogpeppe> frankban: lol
<rogpeppe> frankban: thanks
<jrwren> why is this better?
<jrwren> ah, location updates by Mask. That is nice.
<frankban> hatch: local env is keeping ages to switch the gui to your branch :-/ It used to be faster...
<hatch> :(
<frankban> hatch: it seems blocked on "Retrieving Juju GUI source checkout from https://github.com/hatched/juju-gui.git (ac-result-sort-1348290)"
<hatch> that's odd, did you try switching it back to 'local' then to my branch again?
<urulama> now this was an hour well spent ... on the line with ISP and persuading the tech support that their routers have reveresed on factory settings during short electrical blackout ... he then realised he was checking my neighbour's router and not mine ... sheesh :D
<frankban> hatch: in the local LXC I see this: http://pastebin.ubuntu.com/7906321/
<frankban> git, go home, you're drunk
<hatch> heh weird 
<frankban> hatch: it made progress \o/ it just took half an hour to check out a branch :-/
<hatch> frankban that ocean is vast.....maybe it was using the message-in-a-bottle protocol :)
<frankban> heh
<rick_h__> frankban: it takes a long long time
<rick_h__> frankban: when I did some QA stuff in london it took a good 10-20min 
<frankban> hatch: QA ok, even if maybe we should do that in four groups: 1) recommended + series, 2) just recommended, 3) just series, 4) all the others. E.g. now when I type wordpress I get the oneiric non-recommended one as first result, the precise recommended as second
<hatch> hmm that is a good point
<hatch> I'm working on my other card right now, can you add that to the PR and I'll do it as soon as I get this one up
<frankban> hatch: done
<hatch> thanks! and thanks for putting up with the grueling qa procedure :)
<frankban> rick_h__: yeah, thanks for confirming
<jrwren> urulama: glad to hear that service there is the same as here.
<frankban> hatch: np
<hatch> ooo charmworld just changed which charms are popular
<hatch> now I have to search for mysql/wordpress lol
<rick_h__> hatch: huh?
<rick_h__> charmworld hasn't had a deploy in a couple of weeks, and that change was fixing ngram results in search
<hatch> rick_h__ https://www.evernote.com/shard/s219/sh/8d9cbeaf-6d5d-45da-9216-2e77f1feec86/ede9a6fe24b279b7dda4c712bdebbc3b
<hatch> it's no longer mysql and wordpress
<rick_h__> hatch: ah, you might be watching during an ingest
<hatch> oh it's changing again
<hatch> wth
<rick_h__> hatch: yea, ingest and such the index rebuilds 
<rick_h__> hatch: it'll settle in a sec
<hatch> wait, so it blows out the old one, rebuilds it live?
<rick_h__> hatch: and something we'll fix/make better in charmstore search
<rick_h__> :)
<hatch> shouldn't it rebuild on the side then swap?
<hatch> ohh ok :)
<frankban> done for the day, rick_h__ see you later at the call, have a good night all
<rick_h__> frankban: thanks for attending
<rick_h__> have a good night
<hatch> rick_h__ I guess as long as it's a known issue :)
<rick_h__> hatch: yep
<hatch> well it can't even find mysql
<hatch> I guess I'll wait
<hatch> lol
<hatch> https://github.com/facebook/immutable-js
<hatch> in the mean time....
<marcoceppi> hello gui and friends
<marcoceppi> charmworld issue
<marcoceppi> http://manage.jujucharms.com/api/3/charm//trusty/ceilometer
<marcoceppi> https://store.juju.ubuntu.com/charm-info?charms=ceilometer
<marcoceppi> one of these things is not like the other
<lazyPower> https://bugs.launchpad.net/charmworld/+bug/1350451
<_mup_> Bug #1350451: Missing charm in charmworld-api - ceilometer <charmworld:New> <https://launchpad.net/bugs/1350451>
<urulama> jrwren: there is a promise land far far away, where ISP do what they suppose to :D 
 * rogpeppe is done for the day
<rogpeppe> g'night all
<urulama> rogpeppe: g'night, see you tomorrow
<rick_h__> Makyo: call or were you afk this afternoon? 
<rick_h__> someone had a dr apt and now can't recall
<Makyo> rick_h__, sorry, lost track of time, 1 sec
<rick_h__> np
 * rick_h__ runs away for a little bit until my next meeting afk
<bac> jujugui: i want to 'git stash' a single file but that doesn't seem possible.  is there another command to do it?  equivalent of 'bzr shelve fn'?
<hatch> bac git add the files
<hatch> then git stash
<hatch> file(s)
<hatch> should work
<hatch> sec lemme google
<bac> hatch: oh, add the files i want to keep...
<hatch> yeah http://stackoverflow.com/questions/3040833/stash-only-one-file-out-of-multiple-files-that-have-changed
<hatch> there ya go
<hatch> it outlines it in more detail
<bac> hatch: somewhat easier: git stash -p
<bac> though it makes you pick each hunk
<hatch> oh cool
<hatch> thanks I didn't know abou that one
<bac> hey hatch in github when using 'issues' is there a way to associate a branch with the issue?
<bac> like in LP where you link the branch to the bug/s it fix/es
<hatch> in a commit message you can
<hatch> not sure about a branch though
<hatch> would a commit message be good enough? the issue would then have a link to the commit in the branch
<bac> hatch: i guess that is good enough.  do i just say -m "Fixes issue 16"?
<bac> i assume there is some special token it looks for
<hatch> yeah there is a bunch of them
<hatch> one sec
<hatch> here is closing issues via commit messages https://help.github.com/articles/closing-issues-via-commit-messages
<bac> cool, just found it
<hatch> https://help.github.com/articles/writing-on-github#references
<hatch> also ^ might be helpful 
<hatch> to link to branches
<hatch> er repositories 
<bac> rick_h__: when you have a second to review : https://github.com/juju/jenkins-github-lander/pull/17
<Makyo> jujugui #1350505
<_mup_> Bug #1350505: Relation inspector does not have actions attached properly <juju-gui:New> <https://launchpad.net/bugs/1350505>
<hatch> Makyo thx - my branch does some stuff around there so I'll make sure it lands before work on that one start
<hatch> s
<Makyo> hatch, cheers, thanks
<hatch> if I ever finish these tests
<hatch> that is....
<hatch> guys r working on our power again I may drop offline in a bit
<rick_h__> bac: looking
<hatch> jujugui lf two reviews and a qa for https://github.com/juju/juju-gui/pull/465
<hatch> don't everyone jump on it at once :)
<jrwren> if I knew anything about UI dev, I'd be all over it.
<rick_h__> BradCrittenden: got that crumpler bag, will be much nicer for the next trip me thinks. Though it's definitely not easy to get at. 
<rick_h__> BradCrittenden: thanks for pointing that out in london
<bac> rick_h__: yes, i love mine
<Makyo> jujugui #1350592
<_mup_> Bug #1350592: Destroy machine/container has HTML in deployer bar summary <juju-gui:New> <https://launchpad.net/bugs/1350592>
<hatch> jrwren it's like back-end dev but without all the nice tooling :P
<hatch> Makyo https://bugs.launchpad.net/juju-gui/+bug/1337404 did you ever get any input from UX about what is supposed to happen here? And are you working on it any longer?
<_mup_> Bug #1337404: Long service names go under ghost indicator and break out of service icon <juju-gui:Triaged by makyo> <https://launchpad.net/bugs/1337404>
<Makyo> hatch, never started. worked on Go vis instead.  Guidelines from UX were truncate names with ellipses, have the indicator at the end whether or not truncated.
<hatch> ok Ill update the bug thx
<huwshimi> Morning
<hatch> morning huwshimi 
<hatch> huwshimi did you see that your branches were reviewed ?
<rick_h__> morning huwshimi 
#juju-gui 2014-07-31
<rick_h__> woo! expenses filed. Only took 3 months
<huwshimi> hehe
<rick_h__> now that vegas is filed I feel less obligated to file london ones :)
<rick_h__> huwshimi: hey, how goes? Wanted to check up on your branches
<rick_h__> and let you know that hatch and frankban are working on the 'deleting things' problems in the back end
<huwshimi> rick_h__: I have a million things in progress :)
<rick_h__> so should be able to revisit that branch later on
<rick_h__> huwshimi: yea, seems like it. I wanted to see what was up, anything stuck you need a hand with, etc. 
<huwshimi> rick_h__: I talked to hatch about landing the deleted states (they just won't be visible) and then hooking them up when that's done (hence me moving the card back)
<huwshimi> If you'd prefer me to wait I can
<rick_h__> huwshimi: hmm, ok. I trust you on it. 
<huwshimi> :)
<rick_h__> hah, poor huw was a photo target a bit https://www.flickr.com/photos/7508761@N03/14730078876/in/photostream/
<huwshimi> It's almost as if I was being followed :)
<huwshimi> Nice photos!
<rick_h__> hah, yea I was following you around a lot
<urulama> morning all
<huwshimi> urulama: Morning
<urulama> huwshimi: anything particular regarding your cards on the board that need review or are in coding (to pass the message to the daily call)?
<huwshimi> urulama: Only that I need second reviews on a couple of them. Thanks!
<urulama> huwshimi: ok, np
<urulama> frankban: morning
<frankban> urulama: hi
<urulama> frankban: do you know if rogpeppe is out today?
<rogpeppe> urulama: i'm around
<urulama> rogpeppe: oh, hi, sorry :D
<rogpeppe> urulama: np :-)
<urulama> rogpeppe: any news regarding the change of core to charm.v2?
<rogpeppe> urulama: i've been around for hours :-)
<rogpeppe> urulama: core is blocked until its critical bugs are resolved
<rogpeppe> urulama: so no branches are landing that aren't fixing those bugs
<urulama> rogpeppe: ok, tnx for the info
<rogpeppe> urulama: i've got approval to land it though
<urulama> rogpeppe: \o/
<urulama> rogpeppe: didn't have time to ask before ... any sessions this week?
<rogpeppe> urulama: this week and every week :-)
<rogpeppe> urulama: tuesday night it was
<rogpeppe> urulama: and absolutely rockin'!
<urulama> rogpeppe: nice, glad to hear!
<rogpeppe> urulama: it was good on the friday night in london actually. i presume you didn't try and fail to find it.
<urulama> rogpeppe: we wanted to have a session today (with the gypsy swing band, and me cooking), but the weather is really bad :( well, after Nuremberg it is 
<rogpeppe> urulama: music and home cooking, the perfect combo :-)
<urulama> rogpeppe: no, i was in the museum for nearly 4h ... i guess the sms didn't get through :(
<rogpeppe> urulama: nope, i haven't got any sms messages from you since thursday
<rogpeppe> afk for 10 minutes
 * urulama lunches ... woke up early today 
<urulama> rogpeppe: what do you have in mind for the charm refactoring? 
<rogpeppe> urulama: i'd doing exactly as i suggested in my email to juju-dev
<rogpeppe> s/i'd/i'm.
<urulama> rogpeppe: aaa, the URL/ReferenceURL, cool
<rogpeppe> urulama: https://github.com/juju/charm/pull/31
<urulama> will take a look in 5min
<rogpeppe> urulama: thanks
<urulama> rogpeppe: found this work done by hazmat ... find it interesting https://github.com/kapilt/juju-tosca 
<rogpeppe> urulama: thanks for pointing to that
<rick_h__> morning
<urulama> rick_h__: morning
<frankban> rick_h__: morning
<frankban> guihelp: I need reviews/QA for https://github.com/juju/juju-gui/pull/469 . Thanks!
 * frankban lunches
<urulama> rogpeppe: i like how more uniform the code is now with new URL & referenceURL
<rogpeppe> urulama: cool
<urulama> rogpeppe: i see that you're already on the way to change the charmstore ... making charm.v2 obsolete (in a way)
<rogpeppe> urulama: well, who knows who is already using charm.v2? :-)
 * urulama makes a wild guess that all the users are mostly present here :D
<rogpeppe> urulama: i don't mind leaving v2 behind. we don't need to maintain it.
<rogpeppe> urulama: i do think it's important to change the version number though.
<rogpeppe> urulama: BTW i'm just investigating to see what the Resolve method does. There don't appear any tests for it, and it's only called once in the entire of juju-core
<urulama> rogpeppe: let's welcome our new charm.v3 :)
<rogpeppe> urulama: let's :-)
<urulama> rogpeppe: regarding core - makes sense, they do depend on full URLs
<bac> morning
<hazmat> urulama, context?.. that's an in progress oasis std thingy.. 
<urulama> hazmat: i've done the voting for ODS talks and noticed your OASIS and Juju ... just passed the git url to rogpeppe as a curiosity 
<bac> hey rick_h__ can you decipher http://ci.jujugui.org:8080/job/jenkins-github-lander-merge/27/console
<hazmat> urulama, oh.. nice
<urulama> hazmat: are you targeting to make juju bundles easy to integrate into heat with tosca support? 
<hazmat> urulama, that's a secondary goal.. first goal.. is tosca import into juju.. outbound, we'll be an embedded an orchestrator... re heat i'd prefer to embed directly
<urulama> hazmat: nice!
<rick_h__> bac: otp, looking
<rick_h__> bac: go into the workspace and do 'git fetch' and try to :shipit: again
<bac> rt
<rick_h__> bac: the workspace for that, not sure why it's empty, but I think that's the answer
<rick_h__> frankban: will be 2min late here sec
<frankban> rick_h__: np
<bac> rick_h__, jcsackett: new jenkins-github-lander has been installed on both of our jenkins instances.
<rick_h__> bac: ty much
<bac> rick_h__: it is not released anywhere, right?
<rick_h__> yay for safety
<rick_h__> bac: no, not currently
<bac> rick_h__: does curtis use it?
<rick_h__> bac: can you ping mgz and let him know about the bug/update
<bac> oh, ok
<rick_h__> bac: they're using it, but they've got a fork they're using
<rick_h__> with all the bug blocking landing/etc stuff
<rick_h__> I've not looked where they're keeping their fork
<rogpeppe> jrwren: i haven't seen any return type comment from you, FYI
<rogpeppe> jrwren: ha, it came in a different thread
<rogpeppe> jrwren: ignore me :-
<rogpeppe> )
<rogpeppe> jrwren: see http://godoc.org/labix.org/v2/mgo/bson#Getter
<rogpeppe> jrwren: to implement an interface, the methods must have exactly the same type signature
<rogpeppe> jrwren: so returning (string, error) would not work
<jrwren> rogpeppe: oh, you are implementing some interface there?
<jrwren> rogpeppe: I missed that bit. Is it a mgo interface?
<rogpeppe> jrwren: it's mentioned in the doc comment for the method
<rogpeppe> jrwren: bson.Getter
<rogpeppe> jrwren: it's understood by the marshaling code that mgo uses to talk to mongodb
<jrwren> ok.
<jrwren> new to go and lack of coffee. It makes complete sense now.  ty
<rogpeppe> jrwren: np
<urulama> rogpeppe: have you seen the comment from Casey about urls?
<rogpeppe> urulama: yeah
<rogpeppe> urulama: i've been chatting with him on #juju-dev about it
<urulama> rogpeppe: tnx
<rick_h__> jcsackett: kadams54 around? can you guys take some time this morning to go through huw's branches please?
<rick_h__> he's got 5 in review atm 
<urulama> rick_h__: ah, yes, i talked to huw this morning and he asked for second reviews on his branches
<rick_h__> urulama: yep, we'll get those cleared out today one way or another. 
<bac> rogpeppe: on the charmstore charm review you mentioned the bug with godeps doing things in parallel.  i thought you fixed that weeks ago.
<rogpeppe> bac: no, i didn't change the default
<bac> ah, ok.  i misremembered that you did
<rogpeppe> bac: (like a fool, i thought i'd have some time to investigate the actual issue :-])
<rick_h__> rogpeppe: if we need the time we need to create a card and have it as something to get scheduled
<rick_h__> rogpeppe: is this something we can file a bug for and then add the bug as a card to the board's backlog to get scheduled up?
<rogpeppe> rick_h__: given that there's a workaround, i'm not sure it's worth scheduling our time for
<rick_h__> rogpeppe: ok, is there a bug to document the issue/workaround?
<rogpeppe> rick_h__: i've pushed a fix. the workaround is now in place for anyone that uses a fresh version of godeps
<rogpeppe> rick_h__: (unless they explicitly use a -P flag)
<rick_h__> rogpeppe: oh gotcha
<jcsackett> rick_h__: on it.
<hazmat> the voting interface on ods is kinda of baroque
<urulama> hazmat: :)
<rick_h__> jcsackett: <3
<urulama> hazmat: i've searched using names, opened all links in different tabs ... that helped a bit
<hazmat> urulama, i just want a listing to scan titles.. seems obvious
<hazmat> paging through one at a time through 2500 submissions is inane
<hazmat> their basically encouraging author/company/topic specific voting by forcing search
<hazmat> instead of browsing
<urulama> hazmat: search for "at" or "of" ... you'll get list of all
<urulama> well, list of all that have these words ;)
<hazmat> urulama, nice trick 
<rogpeppe> frankban, bac, jrwren: here are the changes to make the charm store use the new charm.v3 API
<rogpeppe> https://github.com/juju/charmstore/pull/49
<urulama> rogpeppe: tests failed
<rogpeppe> urulama: yes, because charm.v3 hasn't landed yet
<urulama> rogpeppe: how come? :D :D (just kidding)
<urulama> jujugui: have to go now ... be back in 4h
<rogpeppe> urulama: i am hoping that someone might get around to deciding that it looks ok
<rick_h__> urulama: have fun
<urulama> rick_h__: tnx
<bac> rick_h__: joining 1:1 now
<hatch> frankban is the card you have in review the same as the one I have in starting?
<hatch> I thought you were on the pending removal changes
<frankban> hatch: it's not the same, but it's related: it handles the db and ecs name changes, not the deployment panle ones
<frankban> hatch: would you like to review it?
<hatch> sure - you should be able to add one line and do my card as well
<hatch> :)
<hatch> I'll look in a minute
<hatch> rick_h__ oh I see the email that's why you moved my old card back into coding
<hatch> I thought LK was broken again
<hatch> rick_h__ it was also my intention not to make those changes we had talked about on the front end, but on the back end
<hatch> that's going to be a lot of code to ship to the client for that usecase
<hatch> or should I just do it?
<rick_h__> hatch: I thought per our conversation that was the work your card was going to be doing
<rick_h__> hatch: that's why it was the target/blocker on release. It's a UX issue we need to fix right away, and the client has the abliity to do it in a pure autocomplete sense
<rick_h__> hatch: and doing it server side is special casing the search needs for a single widget/component. 
<hatch> well we already hit a different endpoint for it
<rick_h__> hatch: I'd like us to get the client side updated for the best UX
<rick_h__> hatch: no, we don't
<rick_h__> hatch: we add a query string flag to the search endpoint
<rick_h__> that basically turns on 'prefix matching'
<rick_h__> and does not filter/process results
<rick_h__> hatch: call?
<hatch> oh I thought it was a different endpoint because it had 'autocomplete' in the url
<rick_h__> it's just a query string flag onto the same endpoint
<rick_h__> and if we match on the start of a word is turned on/off based on that flag
<hatch> ahh - well then that's broken
<hatch> lol
<hatch> the cf-mysql is in the matching results
<rick_h__> so I'd prefer we try to get the client side widget fix in asap to fix the issue and make mark s happy and the fastest/best way to do that is in the client result
<rick_h__> hatch: right, heh that's true. I think we broke that with ngraming
<rick_h__> because we needed to match somethingCMS via searching for CMS
<frankban> jcsackett: can I have a second review from you for https://github.com/juju/juju-gui/pull/469 when you have time
<hatch> ok I'll fix this up
<frankban> ?
<rick_h__> hatch: ty
<rick_h__> hatch: Makyo kadams54 and jcsackett are helping with huw's reviews that are outstanding. I'd appreciate it if you guys could help as the seconds. 
<rick_h__> mark the cards with the tags to prevent doubling up, but between the 4 of you guys should hopefully be able to move those 5 branches forward
<rick_h__> oh, 4, one is in landing now
<hatch> yeah I just shipped one
<hatch> just doing the review on frankban's branch now
<hatch> frankban I don't think this technique is going to work
<hatch> the deployer bar results are built from the ecs
<hatch> if the ecs values dont' change until deploy then we can't update the deployer bar
<hatch> we need to use the 'old' method and loop through and update the appropriate records when it changes
<frankban> hatch: unless the deployer bar uses the db to retrieve the model starting from its id
<hatch> right but that's not how it's done now - right now the deployer bar listens for a 'changeSetModified' event then loops through the changeset 
<frankban> hatch: I am really trying to avoid these kind of ecs mutations
<rick_h__> frankban: hatch so sounds like we need a matching update to the changelog rendering?
<rick_h__> to pull from db at render time to go with this change?
<jcsackett> kadams54: you're looking at https://github.com/juju/juju-gui/pull/466 right? i'm trying to make sure the card and the PR are the same ones.
<hatch> frankban yeah I agree but it feels like we are doing it half way
<frankban> hatch: if we need to mutate the ecs as a consequence of a user input, than that seems to me a fail
<kadams54> jcsackett: correct
<hatch> and we'll never be able to remmeber if we need to poll the db or the ecs
<jcsackett> kadams54: awesome.
<hatch> bbiab
<kadams54> Ah crap, forgot about the two review thing and just shipped the onboarding PR.
<kadams54> rick_h__: ^ should I come to standup prepared for the stocks and humiliation galore?
<rick_h__> kadams54: you've been shamed, carry on 
<kadams54> :-)
<rick_h__> kadams54: if you had any questions or want feedback on your review bribe a friend to peek at the landing change please
 * kadams54 ponders which mentor would be the cheapest to bribe.
<frankban> hatch: from my perspective, the db should be the single source of truth, and the idea of "changing a change in the changeset" doesn't feel so natural... I feel like it's going to be difficult to debug.
<rick_h__> frankban: +1, but hatch's feedback is good that this branch will break rendering. This branch needs to update that to follow this convention in order to land. Am I understanding this correctly?
<frankban> rick_h__: rendering is already broken on trunk: name changes are not reflected on the panel
<frankban> rick_h__: my branch affects how you will solve that
<rick_h__> frankban: ok, so existing bug. /me looks for a card for that
<rick_h__> frankban: ah, that's why hatch is noticing, that's a card he's tryinug to do
<frankban> rick_h__: yes
<rick_h__> hatch: so why does frankban's changes not allow you to solve your cards with that in effect by repointing where the rendered names come from?
<hatch> so my problem is that if we are going this direction (which I agree is a good one) the ecs needs to drop the extranious data and use the db as the source of truth on commit. The deployer bar then needs to listen to any changes in the db and then determine if it needs to update anything in it's list, and so-on
<hatch> at the moment we are going only part-way there which is just going to get confusing and introduce potential bugs
<hatch> I'd much rather get MV out the door then go back and fix things
<rick_h__> hatch: frankban ok, let's chat post-standup and plan a path that will work for this
<frankban> rick_h__: sure
<rick_h__> otp atm and can't meet pre-call
<hatch> np
<jcsackett> frankban: safe to bet that you now don't need that second review? sounds like that PR may see some major changes.
<hatch> maybe...
<hatch> :)
<hatch> jujugui call in 10
<jcsackett> kadams54: i see you've got a card in review, but there's no pr up yet--is PR coming, or has this already been reviewed?
<kadams54> Which card?
<jcsackett> kadams54: "display services without machines ..."
<jcsackett> is LK just not updating for me?
<frankban> jcsackett: you are right I don't need that now. however, your I'd be interested in your opinion on the design decision if you want to take a look
<jcsackett> frankban: ack, i'll take a look then.
<kadams54> jcsackett: hmmâ¦ that should have a PRâ¦ one momentâ¦
<frankban> jcsackett: thanks
<rick_h__> makyo_: call please
 * makyo_ zooms back home
<bac> rick_h__: i just posted two vacation requests and a holiday for september.
<rick_h__> bac: cool loading
<hatch> jujugui lf another review on https://github.com/juju/juju-gui/pull/465
<rogpeppe> Makyo: reviewed
<frankban> hatch: why the change list shown when you click deploy and the one displayed when you click "X changes" are two different code paths?
<frankban> hatch: UX reasons?
<hatch> frankban I'm not sure I didn't write this
<frankban> hatch: ok
<rick_h__> hatch: frankban ask jcsackett 
<rick_h__> hatch: frankban there is some UX diff and such, I know there was some talk of reuse when it was added but don't recall the final fallout
<jcsackett> rick_h__: i think that was "sprint to demo" fallout.
<frankban> heh
<rick_h__> jcsackett: this is making the changes button work. That was after the sprint stuff
<frankban> rick_h__, jcsackett: fine thanks
<jcsackett> rick_h__: we've touched it since then, but i remember hitting the two paths before that.
<frankban> rick_h__, jcsackett: refactoring that is a separate task
<jcsackett> rick_h__: in any event, while there are some differences, you can probably extract that into something more common.
<jcsackett> frankban: +1, it can def wait.
<hatch> ok I just found this....live stream..... wowzers http://www.nasa.gov/multimedia/nasatv/index.html
<rick_h__> man, I want to chromecast that fullscreen
<hatch> right??!?!?!
 * rogpeppe pulls the $$merge$$ trigger on https://github.com/juju/juju/pull/253
<rogpeppe> fingers crossed
<jcsackett> kadams54: ping me when you've got a PR up for your card.
<rogpeppe> hatch: cool!
<kadams54> Yup, writing up QA instructions right now. FYI, it'll require a real env.
<hatch> rick_h__ people these days just don't seem to understand the amazeballsness of this stuff :)
<jcsackett> frankban, hatch: y'all still dicussing the ecs/deployer issue? fwiw looking at frankban's PR i dig the approach, but i can see where it trips us up. i would like us to move in that direction though.
<hatch> jcsackett sorry we already did
<hatch> ended up with a good way forward
<jcsackett> hatch: oh, i didn't want to be in the meeting, i just want to know the outcome. :p
<hatch> oh ok then in that case...
<hatch> when the deployer bar gets opened to list the tasks it will query the db when required for the real values instead of extracting them from the ecs
<hatch> that way it doesn't actually have to listen to the db for changes
<rick_h__> woot! phone upgrades ftw. 4.4.4 finally
<frankban> jcsackett: good to know, we will follow that approach, I will just add a commit to that branch to also handle the deployer panel
<hatch> and we aren't live updating the dom anyways
<jcsackett> hatch: so you are going to tackle that for your branch then?
<hatch> rick_h__ nice - on the Moto?
<hatch> jcsackett no frankban will add it to his
<rick_h__> hatch: yea, dev edition
<hatch> nice
<jcsackett> hatch: ah, ok. i'll take a look at frankban's PR when that commit hits then.
<hatch> I'm not sure what I'm on (goes to grab phone)
<jcsackett> well, take another look.
<frankban> jcsackett: thanks, appreciated
<rogpeppe> dammit, i missed my window of opportunity. juju-core is blocked again.
<hatch> 4.4.2 here :) on the HTC One m7 retail edition :)
<rick_h__> rogpeppe: saw that :(
<hatch> how does it get blocked?
<hatch> fialing CI?
<rick_h__> hatch: yea
<rick_h__> when you're big enough that stuff has to be landable before a CI run can complete. 
<rick_h__> may we never get that big :)
<hatch> haha - their CI runs must take a while
<rogpeppe> rick_h__: +1
<rick_h__> rogpeppe: if you get some break time could you do us a favor as a juju-core friendly person? We need to generate the list/chart of containers that are valid for different machines/environments. 
<rick_h__> rogpeppe: what does juju allow? Does it even know the rules? I know AMZ can only have an LXC, for instance. And an LXC (local) I think can only have a KVM, etc
<rogpeppe> rick_h__: jeeze, i have little idea. last i looked, the only place containers worked reliably was on maas (and perhaps openstack)
<rogpeppe> rick_h__: does networking now work between containers on ec2?
<rogpeppe> rick_h__: i know there's been lots of work in that direction, but i don't know what the current status is
<rick_h__> rogpeppe: understood. I believe lxc containers should work. I know there was work for nested lxc on local. There's an email thread around that going on currently. 
<rick_h__> rogpeppe: right, I assumed at some point juju would say yes/no when a request was made that the rules would be encoded there in core. 
<rick_h__> rogpeppe: and you'd be best able to know where that might lie
<rogpeppe> rick_h__: it's a rats' nest
<rick_h__> rogpeppe: oh yay
<rogpeppe> rick_h__: i'm not even sure it forbids you from starting containers that may not work
<rogpeppe> rick_h__: thumper's the man to speak to about this stuff
<rick_h__> rogpeppe: ok, my sadness levels are increasing. 
<rick_h__> rogpeppe: ok, will do. I'll add a card and will see what we can figure out. Thanks
<jcsackett> rick_h__: where should we create cards that are dependent on ditching the mv flag? that whole updated unit count thing we discussed can't be done until we can rip out all the old scaling stuff, which won't happen until mv is gone.
 * frankban bbiab
<jcsackett> is that on deck, or further off?
<hatch> frankban I updated your card on the board and deleted mine
<rick_h__> jcsackett: sorry, was looking elsewhere. What unit count thing?
<hatch> jujugui I still need one more review for https://github.com/juju/juju-gui/pull/465
<jcsackett> rick_h__: maybe i didn't talk with you about this, just hatch. once we only have the new scale out there's a bunch of unit count handling we don't need to do anymore; i was starting in on killing it in the branch i just put up for review, and then realized it screwed up the w/o MV path.
<jcsackett> basically: should refactors that depend on MV flag being gone go in on deck, or pool? that's the question. :p
<rick_h__> jcsackett: I've been moving them to on deck
<jcsackett> rick_h__: awesome, thanks.
<rick_h__> jcsackett: but you're right, they're post-release cleanup cards
 * jcsackett is excited to have that refactor done.
<hatch> jcsackett you forgot to run lint again
<hatch> :P
<jcsackett> i have a pre push hook that keeps telling me it's ok.
<jcsackett> but it seems to not run, or something.
<jcsackett> sure takes a long damn time for not running anything.
<hatch> lol
<hatch> jcsackett review done, I added a couple comments, I'll hold off on QA until you take a look
<jcsackett> hatch: responded.
<hatch> jcsackett annnnd replied
<hatch> :)
<hatch> *grumble grumble grumble* I think the cs is doing an ingestion again
<Makyo> rick_h__, I got two +1s from rogpeppe and jrwren on jujusvg.  Since we don't have CI hooked up, is that just a plain click-the-green-button merge, then?
<Makyo> Just making sure I've got the process down
<rogpeppe> Makyo: i'd say so
<rogpeppe> Makyo: i'm guessing you made the changes i suggested?
<Makyo> rogpeppe, yeah, and pushed.  Thanks for the suggestions - much simpler now.
<rogpeppe> Makyo: cool, thanks.
<rogpeppe> listening to some stuff I hadn't listend to in years. man, the start of mahler 1, 4th movement is quite something.
<Makyo> Mahler's dreamy~
<rogpeppe> Makyo: my grandmum gave me a tape of it when i was about 9; i don't think i've listened to it since the tape wore out about 10 years later :-)
<rogpeppe> Makyo: i recently threw out a large box of tapes, but not before i made a copy of them all as a Spotify playlist...
<Makyo> rogpeppe, yeah!  I did that with a bunch of CDs a while back (though some I had to buy off iTunes or the like if they weren't on spotify)
<jcsackett> hatch: so we can move it into addUnits, but we're going to have to call it once for every unit that's added, b/c it requires the service and there's no guarantee that we're adding units of just one service.
<jcsackett> which seems like a lot of churn.
<hatch> dont' we have to do that anyways now that we are manually updating the unit_count?
<jcsackett> hatch: no, we can do a bunch of addUnit ops and then sync once per service.
<hatch> hmm
<jcsackett> hatch: but nevermind, given we're going to kill this as soon as remove the mv flag i think it's temporarily fine.
<hatch> what I'm trying to avoid is the introduction of bugs because someone forgot to call some obscure method in another part of the app
<jcsackett> hatch: yeah.
<jcsackett> we run it for every call of onDelta--clearly it can't be hurting us that much.
<hatch> good point
<kadams54> jcsackett: https://github.com/juju/juju-gui/pull/471 ready for QA and review.
<jcsackett> hatch: of course now a ton of tests crap their pants.
<jcsackett> hatch: i'll continue pursuing this after i review kadams54 branch.
<hatch> jcsackett heh you should be able to just stub it out
<jcsackett> hatch: yes. in like 90 places.
<jcsackett> a *lot* of things deal with addUnits. :p
<hatch> hmm, and you're saying that we will be removing this call in the near future?
<jcsackett> hatch: ideally, but i can't guarantee a timeline.
<jcsackett> i think you're right about moving it so we don't have a landmine for someone else.
<jcsackett> and once we dig into this to remove it we may only be removing part of it.
<jcsackett> kadams54: lint.
<hatch> alright sounds good
<kadams54> jcsackett: yeah, fixing :-(
<jrwren> I don't know Mahler's 1st. I only know 5th, 9th, and 10th. 1st is good eh?
<jcsackett> kadams54: so, machineData.id is how we know if the machine has a service?
<jcsackett> the check seems a little obtuse to me, as it's written.
<kadams54> I would switch it aroundâ¦ machineData.id is how we know if a service has a machine associated with it.
<jcsackett> kadams54: no, it's fine, just making sure i understood.
<jcsackett> obtuse to me doesn't always imply wrong. :p
<kadams54> And yes, that's why the check has comments above it :-)
<jcsackett> kadams54: updating my live env to check yours QA could take a bit.
<jcsackett> in the meantime, juju-gui, https://github.com/juju/juju-gui/pull/471 needs a second review.
<jcsackett> er, jujugui ^
<rick_h__> Makyo: +1, just make sure that tests pass before hitting that button please
<rick_h__> yay, meeting break. /me goes to get lunchables
<jcsackett> kadams54: my local environment completely fubarred itself (nothing to do with your code)
<jcsackett> i'm having to start up a new one, so further delays on QA.
<kadams54> jcsackett: While I'm relieved that my changes didn't do it, sorry this QA is so painful.
<jcsackett> kadams54: i always have *really* bad luck setting the source for the gui charm.
<jcsackett> i'd say there's a 1 in 3 chance it'll crap out and never recover for me.
<kadams54> guihelp: anyone know why juju websocket requests aren't showing up in Chrome's dev tools (Network tab, websocket filter enabled) for me?
<rick_h__> kadams54: reload the page? The network tab must be open at the start of the page load to get them
<hatch> kadams54 quit using Canary?
<hatch> sorry - had to
<kadams54> hatch: Hah! THe latest and greatest web dev tools is *why* I use Canary :-)
<rick_h__> +1
<rick_h__> hatch: :P
<kadams54> rick_h__: I think that's likely the problem, thanks.
<rogpeppe> jrwren: 1st is awesome.
<rogpeppe> jrwren: but i might be biased 'cos it was the first i ever heard
<jrwren> Melborn, Sydney or BBC ?
<rick_h__> kadams54: call?
<kadams54> rick_h__: ah yes, sorry, be right there in a minute
<rogpeppe> bac, jrwren, urulama: https://github.com/juju/charmstore/pull/50
<rogpeppe> rick_h__: FYI i now have goahead on the charm.v3 changes.
<rogpeppe> rick_h__: will push tomorrow
<rogpeppe> g'night all
<urulama> rogpeppe: good night
<urulama> rogpeppe: excellent news on v3!
<urulama> rogpeppe: c u tomorrow
<rogpeppe> urulama: yup
<rogpeppe> urulama: ttfn
<rick_h__> rogpeppe: woot
<rick_h__> night rogpeppe
<jrwren> rogpeppe: i almost asked about params.Error in the last review. :)
<hatch> bac you're running Ubuntu in Fusion right? Which version are you using?
<bac> hatch: yes.  let me look
<bac> hatch: 6.0.4
<hatch> thanks, I have Parallels which runs windows 8 awesome but I'm hesitant to upgrade to support the latest Ubuntu because their current Ubuntu support is so poor
<hatch> are there any issues with it?
<bac> hatch: the ubikey does not work with it (though i haven't checked since the latest update)
<bac> hatch: other than that, i've had great success
<hatch> doesn't the ubikey just act as a keyboard? :)
<bac> no
<hatch> oh I thought tha'ts how it worked
<bac> ccccccdiltlgcvgvvfibkllgcjfiujkdkhtiucinnlcl
<hatch> case, point
<hatch> :P
<bac> hey, works here
<bac> :)
<hatch> haha
<hatch> hey it's even cheaper to buy fusion than parallels
<hatch> nice I'll try the demo
<hatch> er...trial as they call it
<hatch> :)
<hatch> I really tried to get Ubuntu working on metal on this thing but with the discrete gpu the battery life is like 20% what it is in OSX heh
<bac> hatch: according to this post, it should work again as of 6.0.3
<bac> https://communities.vmware.com/thread/462755?start=15&tstart=0
<hatch> ahh cool
<hatch> does hotplugging thunderbolt ports work?
<hatch> I guess I'll figure out myself tonight, but curious :)
<bac> hatch: and it isn't just being a keyboard, but accepting the SSO programming that was the issue, i think.  it was not being recognized.
<hatch> SSO?
<bac> hatch: ubuntu sso
<hatch> ohh
<bac> hatch: i don't have any thunderbolt devices i use within the VM
<hatch> oh ok, my monitor is display port 
<hatch> guess I'll find out
<bac> sadly i just stare at my laptop monitor
<hatch> I've been doing that for a while but just switched back
<hatch> need a 31" laptop monitor
<bac> hatch: there is a display setting that make vmware use the retina properly.  i didn't notice when the put it in and was looking at fuzzy display until frankban showed me last week.
<hatch> oh cool I'll be sure to remember to look for that
<urulama> hatch, bac: or just use parallels ... it's faster/better in all aspects, well, except the price tag ;)
<hatch> urulama that's the problem though, Parallels has caused me nothing but pain with Ubuntu 
<urulama> hatch: really? it works as a charm for me ;)
<hatch> and their support is absolute @#$%^
<bac> urulama: you charmed parallels?
<urulama> :D
<hatch> urulama what version of parallels are you on?
<urulama> hatch: a, that is the trick ... always use latest 
<hatch> urulama when 14.04 came out no version of Parallels supported it, both virtualbox and fusion did
<urulama> hatch: they did, all you had to do is rename some xorg.conf files coz compiz and parallels tools were out of sync
<urulama> after that (3min job) all was fine ... i do admit that they should have fixed that asap
<hatch> urulama if you have to hack xorg files when they had more than enough time to release a patch, even months after it was released, then something is wrong
<hatch> I'm not sure I trust them inotherwords
<urulama> hatch: i've been using them for 3 years, and i have to admit that version 9 is the worst one ... if the trend continues with v10, i'm also open for alternatives
<hatch> that's good to know because I'm using 8, I think I'll give fusion a go
<hatch> they are so focused on windows that they probably have one poor dev trying to make ubuntu work in their free time lol
 * urulama sees "slack and low priority" kanban board ;)
<rick_h__> jujugui going afk a bit until the AU calls. I'll be a bit late for those, swim class (if the rain stays away) please give huw the heads up later. We will have the AU calls though
<hatch> urulama exactly!! Except we don't charge $99 for the GUI :P
<hatch> rick_h__ sounds good
<urulama> rick_h__: enjoy
<bac> hatch: i got yubi to work in fusion
<bac> hatch: the only issue is doing the personalization.  to do that the VM has to recognize it as a USB device not a keyboard.  once it is personalized it works as a keyboard in both OSs
<hatch> interesting
<hatch> I'll have to remember that
<bac> hatch: and the key to that is adding a stanza to the .vmx file
<bac> usb.generic.allowHID = "TRUE"
<hatch> so you have to do that even running 6.0.4?
<bac> sadly yes
<bac> hatch: and doing that gives you the opportunity to steal laptop keyboard from os x.  yikes.
<bac> s/steal/steal the/
<hatch> not sure what you mean
<bac> when you add that config, it makes the yubikey visible as a usb device that you can pick and assign to the VM.  it *also* makes the in-built keyboard visible and assignable to the VM, blocking OS X from seeing the keyboard.  not advised.
<hatch> ohh yeah that wouldn't be advised heh
<jcsackett> kadams54: i think you should find someone else to QA your branch--i have ascertained my juju is hosed, as it cannot bring up juju-gui locally or on ec2.
<hatch> jcsackett you have the worst luck
<kadams54> jcsackett: ugh. Sorry man. Soâ¦ who's up for QA on the cursed branch?
<kadams54> ;-)
<kadams54> jujugui: ^
<kadams54> guihelp: how does the ECS send commands over to core when the deploy button is clicked? I'd assumed websocket to RPC, but I'm still seeing nothing in web inspector (and that's even in plain vanilla Chrome).
<hatch> kadams54 via the gui backend
<hatch> it just executes teh env calls
<hatch> but yes it is via websocket to a real env
<kadams54> And the env function (at least in the case of go.js) makes the call via websockets to RPC, right?
<hatch> correct
<kadams54> Grr.
<hatch> RPC calls via WS
<hatch__> jujugui does anyone object to me excluding Oneric results from the autocomplete result list?
<hatch__> they would still be in the search results, but not in the autocomplete
<bac> hatch__: +1
<hatch__> bac what in the case where it's only oneric charms?
<hatch__> should I show then? or show nothing
<hatch__> I'm thinking nothing
<hatch__> 11.10 was a long a$$ time ago :)
<hatch__> and not even an LTS
<hatch__> and it's eol'd 
<hatch__> so yeah, not even going to show oneric stuff
<hatch__> :)
<bac> as long as they are in the full results i think it's ok
<hatch__> ok done thx
<urulama> jrwren, rick_h__: added few cards for charmstore charm as suggested 
<urulama> g'night all
<rick_h__> kadams54: link me to what review you need
<rick_h__> kadams54: I can do it tonight and have it ready for you in the morning
<kadams54> rick_h__: https://github.com/juju/juju-gui/pull/471
<kadams54> rick_h__: thanks
<hatch__> one test to go then this new AC result list is done
<hatch__> it's bumpin!
<rick_h__> woot
<rick_h__> happy dance worthy?
<hatch__> definitely
<hatch> I think think there is something borked with the ngramming, maybe when I get a moment I'll try and take a look at it though, it's putting the wrong values on some fields I think
<hatch> jujugui I need two reviews and qa https://github.com/juju/juju-gui/pull/472 plz and thanks
<hatch> jcastro ^ I'm pretty sure you'll be happy with the autocomplete results from this branch 
<hatch> jcastro oneiric charms no longer show up in the autocomplete list and you only ever get the 'best possible' charms listed for what you're searching for - the full search results still contain all results of course too
<hatch> jujugui anyone available for a review ?
<jrwren> hatch: i'm afraid to review it.
<hatch> haha - have you had the GUI up and running locally yet?
<jrwren> no.
<jrwren> The most GUI that I've run is what juju-quickstart gives me.
<hatch> ahh then yeah this might be a bit of work for ya
<hatch> but the hacking guide should be good enough
<hatch> you should go through it and make notes of where it falls short
<huwshimi> Morning
<hatch> goooood morrow
<hatch> I have a good review for you huwshimi  https://github.com/juju/juju-gui/pull/472
<huwshimi> Ugh
<huwshimi> hatch: By good, I think you meant, eye melting
<hatch> lol, just hand wave over the algo bits
<hatch> and do the qa :D
<hatch> the qa is the important part anyways haha
<huwshimi> ok :)
<hatch> bac so I have a very odd problem, the background of the VM is only 1/5th the size of the screen, but everything else has good resolution....
<huwshimi> hatch, rick_h__: Are we doing an AUS call today?
<hatch> huwshimi yes but rick is delayed
<hatch> swimming lessons or something
<huwshimi> Ah np
<hatch> I plan on getting drunk at 5pm
<hatch> so better hurry
<hatch> lol jk
<huwshimi> that would make an interesting stand up
<huwshimi> or lean
<hatch> haa
<hatch> leanup
<hatch> https://www.youtube.com/watch?v=Ywgync45Eis <--- lol funny kiteboarding vid
<huwshimi> hatch: Weird we have a recommended mysql charm without an icon
<hatch> the oneric one?
<huwshimi> hatch: Nope precise
<huwshimi> http://localhost:8888/precise/cf-mysql-1/:flags:/mv/?text=cf-mysql
<hatch> ohh yeah
<huwshimi> hatch: So when I do that search for mysql it suggests that one before the mysql one, seems wrong
<hatch> yeah I think the ngramming is busted
<rick_h__> huwshimi: jujugui call in 2?
<huwshimi> rick_h__: sure
<huwshimi> hatch: So when I type "mysql" it shows cf-mysql then mysql and when I typ "cf-mysql" it shows the same (cf-mysql then mysql). That doesn't seem like a great ordering
<jrwren> hatch: lol @ your node charm hooks. :)
<hatch> whaaaat
<hatch> :)
<hatch> you can't handle their epicness?
<jrwren> Yes, I think that is what made me chuckle.
<hatch> they are really simple
<hatch> huwshimi let me know if you need any more reviews so we can get some of your branches landed
<jrwren> Yes, it was just a surprise. Probably, a reasonable node hook reference. Maybe could be used as a node template in charm-tools
<hatch> the only issue we had in writing it was that node doesn't provide synchronous shell-out methods
<hatch> so everything had to be in callbacks 
<hatch> it made things which required many shell-outs to get ugly
<hatch> those have since been changed
<hatch> this for example https://github.com/hatched/ghost-charm/blob/master/hooks/balancer-relation-changed
<hatch> it has to do it in order, but the code is not in order 
<jrwren> That is always the nature of node or really any CPS system.
<jrwren> you could make it in order by using inline functions everywhere. I'm sure it would get fun when you nest 10 deep. :)
<hatch> haha definitely an antipattern 
<huwshimi> hatch: A second review on https://github.com/juju/juju-gui/pull/467 might be good, unless you want to wait till I fix that QA issue
<hatch> huwshimi yeah I'll wait, I'll be around all night
<hatch> so just ping whwnever you need one
<huwshimi> hatch: Np
<huwshimi> hatch: Do you need a real env review for you pr https://github.com/juju/juju-gui/pull/472 ?
<huwshimi> (QA)
<hatch> huwshimi well you can also hack the default series if you like
<huwshimi> hatch: Ah that might be easier
<hatch> app.js getEnvDefaultSeries() change it to return 'trusty'
<hatch> hmm it doesn't look like I can install chrome in my new vm
<hatch> odd
<huwshimi> heh
<hatch> will try the 32 bit
#juju-gui 2014-08-01
<huwshimi> hatch: Also, if you have any ideas on how to test the expose option exist in the new "ghost" inspector I'd love some help with that
<huwshimi> https://github.com/juju/juju-gui/pull/461
<huwshimi> (see the last commit)
<hatch> looking
<hatch> don't like partials I see :)
<huwshimi> hatch: Oh, no, it's just it only gets included in one place now
<hatch> huwshimi well you can only test that the class is there
<hatch> not that it's actually doing what it is supposed to be doing
<huwshimi> hatch: My problem is that I don't actually know how to put the inspector into "ghost" mode. Then 'pending' variable doesn't actually do anything: https://github.com/juju/juju-gui/pull/461/files#diff-f05fb78d550f50174f5355a05130fa02R742
<hatch> huwshimi sorry my computer decided it didn't like my keyboard anylonger
<huwshimi> :)
<hatch> hmm that should work
<hatch> huwshimi oh the mix command is wrong
<hatch> huwshimi https://gist.github.com/hatched/b8b2d12bb6d4c6ad90a8
<hatch> this goes around line 90 of test_inspector_overview
<hatch> to replace what's there
<huwshimi> hatch: Ah great, I'll try that in a minute!
<huwshimi> Makyo: Are you around?
<huwshimi> Makyo: Just wondering if you actually started your card, I have inadvertently fixed it in the branch I'm working on...
<huwshimi> hatch: This branch is ready for review now too: https://github.com/juju/juju-gui/pull/467
<hatch> cool ill take a look
<hatch> maybe....if my internet stays up
<hatch> oh huwshimi  we now don't rebase until just before landing
<hatch> so reviewers can see the changes 
<hatch> like you can rebase before putting up for a PR
<hatch> just don't rebase between PR and landing until just before landing
<rick_h__> hatch: https://twitter.com/rwjblue/status/494992271235100672
<huwshimi> hatch: Sure, makes sense
<hatch> rick_h__ w000000t
<rick_h__> hatch: ember? for a blog? seems a bit extreme
<rick_h__> hatch: and upgrade time
<hatch> the admin panel
<huwshimi> hatch: In that pr I just sent you I fixed Matt's card he is in 'Branch start' should I steal that card off him?
<jrwren> wordpress is extreme for a blog too :)
<hatch> I'm not going to upgrade the charm to include the RC
<hatch> but this ight be time to provide the option to pull in the source from elsewhere
<hatch> huwshimi yes, and send him an email just to be safe :)
<huwshimi> hatch: Sure!
<hatch> huwshimi shipppppit
<huwshimi> hatch: Cheers mate
<hatch> rick_h__ can you put some input on what should be happening here https://bugs.launchpad.net/juju-gui/+bug/1351112 I think that it should add the unplaced unit back into the unplaced unit list.....buuuuuuut
<huwshimi> hatch: So with that new mix line should I just pass the 'pending' as I have done?
<_mup_> Bug #1351112: Deleting an ecs'd machine with placed service still shows service in change list <juju-gui:New> <https://launchpad.net/bugs/1351112>
<hatch> huwshimi yep
<rick_h__> hatch: looking
<rick_h__> hatch: remind me to look tomorrow
<rick_h__> hatch: brain is slow and trying to qa kadams54's stuff and no more capacity
<hatch> haha - too much thinking?
<hatch> :)
<jrwren> updated: https://github.com/CanonicalLtd/charmstore-charm/pull/1
<jrwren> its practically all new.
<jrwren> oops, private.
<huwshimi> jrwren: Hello, welcome!
<hatch> jrwren putting in some OT?
<hatch> :)
<jrwren> hi huwshimi, thanks for the welcome. good to be here.
<jrwren> hatch: yes, I guess so.
<jrwren> You know how it is when you just really want to get something done :)
<huwshimi> jrwren: Great, things going well so far?
<jrwren> good enough.
<hatch> yup I do
<jrwren> I'm funding bugs and warts and stuff. :)
<jrwren> And I'm learning tons. I'm still very new to pretty much everything.
<huwshimi> jrwren: Yeah, lots to learn
<hatch> jrwren yeah after a couple months you'll be right in the swing of things
<hatch> huwshimi be sure to update the board when your stuff lands
<huwshimi> hatch: Into daily call?
<hatch> yep
<huwshimi> np
<huwshimi> hatch: When I set pending to true it doesn't render the UI, any obvious ideas?
<huwshimi> Actually I think it's rendering the old ghost inspector
<hatch> oh u need to se the mv flag
<hatch> set
<hatch> huwshimi
<huwshimi> hatch: Yeah, I have!
<huwshimi> (well, in my local branch)
<hatch> hmm
<hatch> are you setting it before calling the setupInspector?
<huwshimi> yep
<hatch> well I have noooo idea
<hatch> you'll have to step through it I guess
<huwshimi> hatch: it's hitting this here: https://github.com/juju/juju-gui/blob/develop/app/views/environment.js#L97
<hatch> OHHHH
<hatch> ok that's why it's not working
<hatch> sec
<hatch> huwshimi so under mv we no longer hit that in the real code flow we now use the dispatcher https://github.com/juju/juju-gui/blob/develop/app/subapps/browser/browser.js#L586
<huwshimi> hatch: OK, so any ideas how I get it to call that instead?
<hatch> huwshimi well I can't believe we haven't tested any of this stuff being passed a ghost model yet
<huwshimi> hatch: Isn't this what you and jcsackett did in London?
<hatch> nope this was done pre-london
<hatch> I think by jc though
<huwshimi> oh ok
<huwshimi> hatch: pending must be set at a later point than where I'm doing  it if this works not in the test
<hatch> no that area is never called in a real app
<hatch> under mv
<hatch> it is instantiated in the browser.js file
<huwshimi> sure, but setting pending is what is making me hit this
<hatch> yeah so that's not going to work
<hatch> like we are hitting a branch of code that's going to be going bye bye once mv hits
<huwshimi> yeah
<huwshimi> hatch: Any brilliant ideas or should I head to lunch?
<hatch> huwshimi the only thing I can think of is to instantiate the view manually 
<hatch> the overview view
<huwshimi> hatch: OK, I'll try that
<hatch> but maybe dig in the closed PR's for when this stuff landed
<hatch> maybe use git blame to find it
<hatch> because we must have added tests around this stuff
<huwshimi> sure
<rogpeppe> urulama: mornin'
<urulama> rogpeppe: morning
<huwshimi> rogpeppe, urulama: morning
<rogpeppe> huwshimi: hiya
<urulama> hey there, huwshimi
<rogpeppe> urulama: the reason we don't use errgo.Any everywhere is that we want to have control over the error codes that are being generated (and that can be relied on)
<rogpeppe> urulama: the place to use errgo.Any is where there's a callback that we want to give control over the error codes
<rogpeppe> urulama: a classical example being when we have a general handler that has more specific handlers plug into it
<rogpeppe> urulama: in general, my view is that use of errgo.Any is to be avoided when possible. i am aware that this view has been the source of some contention in the past :-)
<urulama> rogpeppe: yeah, that errgo.Any is funny :)
<urulama> rogpeppe: ok, could we have a comment then for us non-errgo-experts, to know the reasoning ... just as a reminder not really comment on each Any call
<rogpeppe> urulama: the motivation comes from experience with large systems where there can be a lot of "action-at-a-distance" where something high up relies on specific error codes generated by something much lower level.
<rogpeppe> urulama: yes, that's a good idea. will do.
<urulama> rogpeppe: the comment would be exactly what you've written in the reply on the PR
<rogpeppe> urulama: the "see at a glance" comment?
<urulama> Because we don't want parseURL setting status codes. By omitting errgo.Any, we can see at a glance which are the possible places that could be returning an error with a Cause (the only kind of error that can end up setting an HTTP status code)
<rogpeppe> urulama: oops, just realised there was a file missing from my commit. i've just re-pushed (the file is params/error.go)
<urulama> rogpeppe: that's a problem with reviews on github ... it's PITA to see the whole code and then one just assumes that "it's there from before" :( 
<urulama> rogpeppe: regarding our morning call ... it's way too loud today at home, i'll have to move to another location
<rogpeppe> urulama: ok. let us know when.
 * urulama brunches
<rogpeppe> trivial PR: https://github.com/juju/charm/pull/32
 * rogpeppe grabs breakfast
<rogpeppe> urulama: i've made all those changes requested, i think (and having a clear policy now made it easy to find a couple more places where I omitted an errgo.Any) https://github.com/juju/charmstore/pull/50
<urulama> rogpeppe: looking
<rogpeppe> urulama: it's a pity that github doesn't make it easy to see what changes have been made since the last review comments were made
<urulama> indeed
<urulama> rogpeppe: thanks for the comments, i think that the code is much easier to read now. 
<rogpeppe> urulama: great, thanks
<rogpeppe> frankban, urulama, jrwren: fairly trivial fix to charm.v3: https://github.com/juju/charm/pull/33
<rogpeppe> review appreciated, because this is blocking the "user charm.v3" branch from landing
<urulama> rogpeppe: looking, see that you got lgtm from core for #32 and #31 as well ... nice
<urulama> rogpeppe: package version independent code :D
 * frankban lunches
<rogpeppe> bac, jrwren, frankban: i need a second review of this, please, before i can land it: https://github.com/juju/charmstore/pull/50
<rick_h__> morning all
<urulama> morning, rick_h__
<jrwren> morning all
<urulama> morning jrwren
<urulama> jrwren: just a quick notice to pay attention on the details of error handling in that PR #50 as we'll use that on all services (until replaced by something more new and shiny) ... if you haven't already that is
 * rick_h__ heads to the coffee shop for morning work
<jrwren> urulama: ok, thanks.
<rogpeppe> jrwren: hiysa
<rogpeppe> jrwren: hiya, even
<rogpeppe> jrwren: any chance you could review that branch too, please, as i can't land it without 2 reviews
<rogpeppe> ?
<jrwren> I thought I did.
<frankban> rogpeppe: review done
<rogpeppe> jrwren: ah, perhaps i just didn't refresh the page
<rogpeppe> jrwren, frankban: thanks!
<rick_h__> jrwren: make sure to leave a final 'comment' to help indicate the review is complete. (didn't look if you did there but just general fyi)
<kadams54> guihelp: yesterday I realized that the error message I was seeing was not the same as the one I was supposed to be seeing. I setup a trusty machine and was trying to deploy precise charms.
<kadams54> I think there have been discussions about this in the past, but are there any plans to filter charms based on series?
<kadams54> Also: should I setup my ec2 as precise for the time being?
<rick_h__> kadams54: is this in reference to your current card?
<kadams54> Yeah
<rick_h__> kadams54: frankban landed some work this week that has machine auto match the right 'series' based on what's placed on them
<rick_h__> kadams54: so there might be some other work effecting what you see atm
<rick_h__> kadams54: hmm, so what error are you seeing now? 
<rick_h__> kadams54: This might work now with frankban's changes actually
<kadams54> "Series does not match"
 * rick_h__ goes to get the bug
<kadams54> I checked the core codebase and it throws that when the unit's series does not match the machines
<kadams54> So yeah, frankban's work might have helped keep me from shooting my foot off :-)
<rick_h__> kadams54: ok, so you're getting that error out of core
<rick_h__> ?
<kadams54> Yes
<kadams54> GUI tries to deploy the unit to the container and gets an errorâ¦ which it should, according to the card.
<kadams54> I just didn't realize initially that the error I was getting back was the wrong one.
<kadams54> So even though I'm working in the GUI, the error is coming from core
<rick_h__> kadams54: ok, so the bug is that the error is machine doesn't exist, but that's "fixed" and what you're seeing is the wrong series error instead now
<rick_h__> kadams54: hangout please? I want to make 100% sure of the steps and such
<kadams54> I'm not sure if it's "fixed" or if I was just hitting the "wrong series" error first.
<kadams54> If it is fixed, I didn't do anything to fix it :-)
<kadams54> Sure
<kadams54> Standup hangout?
<rick_h__> kadams54: sorry, the friday one
<bac> gah, no rain here for six weeks and the tropical storm is due to arrive about the time i have to go to the airport tomorrow.
<rogpeppe> bac: ha, no rain here for ages either, and the downpours are just starting in time for a nice weekend out camping
<bac> rogpeppe: they aren't so good at periodic maintenance here.  the slightest rain causes the highway to flood since the stormwater system is clogged up.  makes getting to the airport hard.
<rogpeppe> bac: well at least we don't have that problem... unless it *really* rains
<bac> yes, because you're not 1 GDP in debt
<bac> :(
<rick_h__> kadams54: pr #171 can land correct?
<jrwren> bac: Where does it flood?
<bac> jrwren: mainly the roadways.  and parking lots. and low lying areas.  not our house, though.
<jrwren> We have some of that here, but only on a few select roads.
 * urulama sees the Sun for the first time since London ... happy to switch with people with no rain ;)
<rick_h__> jcsackett: kadams54 are either of you up for reviewing/qa'ing frankban's branch please? https://github.com/juju/juju-gui/pull/469
<jcsackett> rick_h__: i thought frankban had another commit he wanted to push up to that branch?
<jcsackett> i've been holding off waiting for changes; did i misunderstand?
<frankban> jcsackett: the branch is ready to be reviewd
<jcsackett> dig, well i'm sorry for holding it up. :p
 * jcsackett goes to review it.
<frankban> jcsackett: np and thanks
<bac> hatch: did your ac branch land?
<hatch> bac last I checked I needed one more review
<bac> oh
<bac> ok
<rick_h__> hatch: I reviewd it this morning
<rick_h__> hatch: one point in there please
<hatch> ohh ok
<hatch> will look
<hatch> sorry there is like 200 emails, haven't gotten through themall yet
<hatch> heh
<rick_h__> heh, np. Figured it was early for you yet
<hatch> rick_h__ replied
<hatch> yeah it's still only 7:20
<hatch> trying to buy a kite on ebay so had to get up early to check on it haha
<hatch> er get online early
<rick_h__> hah
<rick_h__> hatch: ty
<hatch> anyone here use duolingo?
<bac> hatch: i did for a while.  plan to start again
<rogpeppe> hatch: i thought about it recently, but didn't
<bac> hatch: it is really good
<rogpeppe> hatch: i know some friends that are really into it
<hatch> I just started on Spanish, prepping for a winter getaway (if we can ever get our S$%^ together) :)
<jcsackett> so, "e", "ev", "evt" for events? i see all three, and i see many diffs that switch them back and forth. can we just pick one? :p
<hatch> after one lesson I've already learnt more than I did before heh
<hatch> jcsackett I vote for e (ev is from benji, evt is from frankban) 
<hatch> lol
<frankban> :-)
<jcsackett> "evt" however gets "<3" from the boss man. :p
<frankban> hatch: evt is because I want t make you happy: I'd write that as "event" ;-)
<jcsackett> hatch: my pr is updated btw.
<hatch> haha
<bac> hatch: duolingo produces some silly things to say:  'the duck drinks milk'
<rick_h__> single letter var names are evil no matter what :P
<rick_h__> evt reads nice to me and love s/e/evt
<bac> how many letters have we saved, if you include this discussion?
<rick_h__> but it's personal preference. I think ev was me caving to hatch. 
<rick_h__> bac: 3, it's a fact
<rick_h__> :) 
 * jcsackett laughs
<hatch> lol
<jcsackett> do we have actual style guidelines written anywhere for jujugui? or is it just "whatever the reviewer and lint will let through"?
<rick_h__> come on, the linter hates on the rest of my party, have to find the points to chat about somewhere
<rick_h__> jcsackett: no, I don't know we'd ever get everything through a process
<hatch> lol
<bac> yeah, let's do that some friday i'm gone
<rick_h__> I've still resisted the urge to one weekend s/  /    /g
<hatch> we still can't agree on doc formatting
<bac> (or at least after lunch)
<rick_h__> lol
<hatch> Spanish is a wako language though bac, there is a male/female/adult/child version of everything
<hatch> and they say English is hard
<bac> hatch: yeah, uh, i've noticed that.
<hatch> haha 
<bac> no, English is insane.  gendered languages are stupid but English is insane if you're not 3
<hatch> there their they're 
<bac> i have a theory computer scientists have a harder time learning a natural language since the inconsistencies are so aesthetically offensive.
<hatch> hahaha
<urulama> hatch: most eu languages are gender specific, we also have the third option, for "it" :D
<frankban> English grammar is simpler than other languages, pronunciation is hard, due to the fact English is not a phonetic language
<kadams54> rick_h__: pr#171? You mean #471? That's the one that hasn't been QA'd yetâ¦
<urulama> hatch: and not just singular and plural forms, but also special dual form ... 
<rick_h__> kadams54: ah gotcha
<jrwren> surely there is a list of things you DO agree on which could be written.
<rick_h__> kadams54: did you find out how you did it locally?
<hatch> urulama haha damn....
<kadams54> rick_h__: no, I got distractedâ¦ looking now.
<rick_h__> jrwren: I thin kit's that code is good
<rick_h__> jrwren: that's about it
<urulama> hatch: so, try learning German (or slavic languages), then you'll consider Spanish simple :D 
<rick_h__> jrwren: so much history...I'm actually kind of floored that I asked teo join this team. The first 6mo was so rough. 
<jrwren> rick_h__: lol
<hatch> urulama well I know some Ukranian does that count?
<jrwren> rick_h__: how long has it been?
<rick_h__> jrwren: hmm, 1.5yr on this work? 
<rick_h__> the GUI stuff
<rick_h__> I remember after christmas working on charmworld/charm browsing in the GUI
<urulama> hatch: :)
<rick_h__> so little over
<hatch> jrwren no we don't agree, we just tolerate...
<hatch> it's like a supersaturate 
<jrwren> so sad.
<hatch> one of these days it's gona explode into extra comment styles and single char variables everywhere
 * jcsackett one day will work through the holidays to re format everything, update the linter, land a style guide, and pronounce it the law of the codebase...
<jrwren> sounded like flake8 was agreed upon.
<rick_h__> at some point you realize there's natural things that are purely opinion and try to do the best you can
<jcsackett> python is easier to agree on.
<jcsackett> javascript is a mess to begin with, so... :p
<rick_h__> the python 'everyone agrees' is a lie
<jrwren> GTK
<hatch> lol
<rick_h__> there's tools that half the people don't follow, the 'I pep8'd everything for you' pull request is a flame war in the making
<hatch> haha
<rick_h__> and then there's always the old fallback of "if the stdlib doesn't even follow..."
<jcsackett> rick_h__: never said everyone agrees, just that it's easier.
 * rick_h__ notes that as the guy that asked jrwren to add a make target to the charm linting the python
<rick_h__> but that's for another channel
<jrwren> i've always liked the policy that new code landing should follow the style guidelines, but you don't ONLY change style for style sake.
 * rick_h__ heads home from coffee shop, afk for a couple of min
<frankban> as a side note, the js linter we use sometimes goes crazy, e.g.: wrong indentation, this must be indented at 6, 9, 12.7 or 42 spaces... and I don't remember why we decided not to just indent everything with 2 spaces...
<jcsackett> frankban: +1 on your PR, QA OK.
<frankban> jcsackett: cool thanks
<jcsackett> frankban: i think when you can't find a logic to a style decision in GUI, the answer is there was no logic to it. :p
<jcsackett> jujugui: i need one more review for https://github.com/juju/juju-gui/pull/470 (hatch, you had a chance to look at the update?)
<jcsackett> jujugui: also, because my juju install is borked, kadams54 needs a QA on https://github.com/juju/juju-gui/pull/471 (it requires a live env)
<kadams54> jcsackett: yeah, rick_h__ volunteered but I need to find more QA info for him.
<jcsackett> kadams54: ah, cool.
<kadams54> jcsackett: out of curiosity, do you know the value you passed in as source when you were trying to QA that PR?
<jcsackett> kadams54: "repo branch-name"
<jcsackett> i've since had juju refuse to connect to any of my deployments for my hackerspace--not sure if they're related, but i've got a todo to reset my juju stuff sometime today.
<jcsackett> i've never cleaned up various ppas etc since i was on qa--figure there's a chance i'm working with bad stuff.
<jcsackett> kadams54: not literally "repo branch-name", of course--whatever copied from github for your repo and branch name. :p
<kadams54> jcsackett: Yeah, rick_h__ was having problems tooâ¦
<jcsackett> huh.
<rogpeppe> urulama, frankban, jrwren: here's the stats Store code imported from the old charm store: https://github.com/juju/charmstore/pull/51
<jcsackett> ...wonder if the two things are unrelated, and the gui charm is having issues...
 * rogpeppe loves it when code is that modular
<jrwren> its a good sign.
<kadams54> rick_h__, jcsackett: just figured out why I wasn't finding anything in my shell historyâ¦ I hacked up fakebackend.js to return errors so I could dev locally. (Which was when I asked about updating it to do some of the same error checking as the real thing.)
<rick_h__> kadams54: ah, cheater
<kadams54> Yup.
<kadams54> Soâ¦ still no closer to understanding why the gui charm isn't getting pointed to the right source.
<rick_h__> kadams54: yea, now that it's morning I'll try again and see what's up
<rick_h__> sorry for the delays
<frankban> jcsackett, rick_h__: do we really want to collapse var declarations when the definition is "simple"?
<rick_h__> frankban: it was agreed long ago that if they were simple one liners then it was ok to do
<rick_h__> frankban: and anything multi-line, objects, arrays, etc would be split out
<frankban> rick_h__: I know it's ok to do that, I am not sure if it's optional or not
<rick_h__> frankban: I take it as optional
<rick_h__> frankban: the only time I call out is like hatch's when he had more than one var per line
<rick_h__> as that hides potential vars
<frankban> rick_h__: cool thanks, are you QAing my branch?
<rick_h__> frankban: no, left that for jcsackett 
<frankban> rick_h__: cool, he did it, thanks, will submit soon
<rick_h__> frankban: ty much
<rick_h__> frankban: bac didn't we update the charm for the KeyError: u'NetworkScope' issue?
<frankban> rick_h__: we updated quickstart, not the charm. Is the charm affected?
<rick_h__> frankban: oh, maybe I've not updated quickstart /me goes to dbl check source
<rick_h__> hatch: buld failed email?
<hatch> yup got it re-running
<rick_h__> kadams54: hmm, no idea why this is failing. The apt-get install runs and then it gets to Processing triggers for libc-bin ...
<rick_h__> ldconfig deferred processing now taking place
<rick_h__> and then it hangs and config goes into a bad state
<rick_h__> before it ever hits git
<Makyo> jujugui call in 3
<rick_h__> kadams54: oh crap, all my issues were because I missed the s in your github username. 
<kadams54> hahahaha
<rick_h__> found where it logs out to, not the charm log :( but the all log
<rick_h__> anyway, finally getting somewhere with your qa, thanks for your patience
<kadams54> "I must've put a decimal point in the wrong place or something. shit, I always do that. I always mess up some mundane detail."
<bac> hatch that's a great look.  doesn't look dorky at all.
<rick_h__> jcsackett: ^
<hatch> bac? whowhatinthewhatnow?
<bac> hatch: :)
<bac> PR just cut back from 19 to 15 holidays, starting next year.  (i don't get them)
<kadams54> rick_h__: OK, I'm getting the right error now for my card, so venturing forthâ¦
<rick_h__> kadams54: woot
<rogpeppe> frankban: i'm off in 40 mins, BTW. 't'would be great if you could perhaps have a look at that PR before then, please. ta!
<rick_h__> ish
<frankban> rogpeppe: sure
<rogpeppe> frankban: thanks
<bac> rick_h__, rogpeppe, frankban: are we using github for the bug tracker for juju/charmstore ?  i see two issues are there.  jrwren has documented it as a TBD so i'm curious.
<rick_h__> curses! out of tape
<rick_h__> bac: yes, I think we should.
<rick_h__> bac: since we don't have a LP fallback project
<rogpeppe> bac: i think so, yes
<hatch> hmm internet isn't being too awesome today
<rick_h__> bac: but I think we did have issues in LP in core we might need to peek at
<rogpeppe> bac: i prefer associating the bugs directly with the repo, tbh
<bac> rogpeppe: what do you mean?
<rogpeppe> bac: well, since we're hosting on github, it makes sense to track bugs there, i think
<bac> rogpeppe: ok, agreed
<rogpeppe> rick_h__: those bugs would be more appropriately raised against github.com/juju/charm though, i think
<rick_h__> rogpeppe: ok
<frankban> rogpeppe: so, is your branch just moving stuff from _old?
<rogpeppe> frankban: yes
<rogpeppe> frankban: with a few tweaks to fit the old stuff with the new
<rogpeppe> frankban: (e.g. session becomes db)
<rogpeppe> frankban: i haven't changed any of the actual logic
<frankban> rogpeppe: ok
<rick_h__> kadams54: I think we fixed the error that you were working around and so QA isn't valid atm
<rick_h__> kadams54: but the change is small, I +1 to land
<frankban> rogpeppe: LGTM
<rogpeppe> frankban: ta!
<urulama> rogpeppe: by "i haven't changed any of the actual logic" you mean that it's original form is good enough to be just easily hooked with handlers?
<urulama> s/it's/its
<rogpeppe> urulama: yes
<rogpeppe> urulama: and there's already a handler in the old code that implements the actual stats/counter serving logic
<rogpeppe> urulama: which is what i'm porting over currently
<frankban> guihelp: I need reviews/QA for https://github.com/juju/juju-gui/pull/473 ? Anyone? thanks!
<urulama> rogpeppe: and the code covers /stats/counter use-cases? does it do more as well? 
<rogpeppe> urulama: i don't think so, but /stats/counter is fairly general
<hatch> frankban on it
<frankban> hatch: thanks
<hatch> frankban so machines and containers use the same model?
<frankban> hatch: yes
<hatch> frankban how did you find this out? trial and error? Or is it documented somewhere?
<hatch> the MANAGE_ENVIRON
<hatch> oh constants.go ?
<frankban> hatch: I don't know if it's documented, I saw that while implementing the mega-watcher for machines
<hatch> ohhh ok cool
<frankban> hatch: so server side
<frankban> hatch: I knew that sooner or later that jobs attr would be useful ;-)
<hatch> haha truth!
<urulama> jujugui have a great weekend and may the gods of CI be on your side next week
<frankban> urulama: :-) and you, have a good trip
<kadams54> rick_h__: What changed to fix the error?
<kadams54> rick_h__: Maybe I should clarifyâ¦ which error? As far as I know, there's still an error state that occurs when deploying to a ghost container. You'd mentioned earlier that frankban landed work that would fix deploying the series mismatch between charm and machineâ¦
<kadams54> rick_h__: just trying to figure out if I should continue working on the ghost container error.
<rick_h__> kadams54: the only error I hit was an install hook failed on mysql
<kadams54> And you were deploying mysql to a ghosted container?
<rick_h__> kadams54: I did "Drag and drop the unplaced unit on the bare metal container."
<rick_h__> which was a ghost, yes
<kadams54> Hmm.
<rick_h__> I then did the deploy, and the mysql install hook failed, but that was it
<kadams54> OK, sounds like my current card may already be fixed then.
<rick_h__> kadams54: so to deploy to a live env and switch up the source I just used juju-quickstart so the gui came up fast
<rick_h__> kadams54: and then did juju set juju-gui juju-gui-source="https://github.com/kadams54/juju-gui.git services-without-machines"
<rick_h__> kadams54: so you can also just set it to 'develop' to check current trunk
<kadams54> Yeah, will do, thanks
<rick_h__> kadams54: but yes, please verify the bug/card
<kadams54> Definitely
<kadams54> OK, lunching time
<frankban> hatch: re "state service": I just followed directions from luca: see bug 1348673
<frankban> mup you won't be missed
<frankban> hatch: https://bugs.launchpad.net/juju-gui/+bug/1348673
<hatch> frankban sure np
<hatch> thx
<frankban> hatch: FWIW I agree with you
<hatch> :) 
<hatch> doing qa, it'll take a bit to spin up an ec2 instance just fyi
<hatch> I have issues with a LXC right now unfortunately and haven't had time to fix/investigate
<frankban> hatch: thanks
<frankban> jcsackett, jrwren: do any of you have time for a second review (no QA) for https://github.com/juju/juju-gui/pull/473 ?
<jcsackett> frankban: sure.
<jcsackett> hatch: see? not just me with lxc issues. :p
<frankban> thanks
<hatch> jcsackett I'm running in a vm making more vm's - it's like vm inception here
<hatch> lol
<jcsackett> hatch: i'm not sure if that's awesome or awful. :)
<hatch> I blame us for not dedicating resources to get Ubuntu running perfect on Apple hardware lol
<bac> hatch: we should've all pitched in and bought a MBP for pitti, one of very productive ubuntu guys.
<hatch> not gona lie that's probably a good idea lol
<hatch> I'd put in $100 to get the darn camera working
<hatch> lol
 * rogpeppe is done for the week
<rogpeppe> happy weekends all
<jcsackett> and to you, rogpeppe.
<hatch> cya rogpeppe  enjoy
<hatch> frankban so I've got the GUI up and running now
<hatch> the "State service" is listed on the machine, but nothing on the container
<hatch> does that make sense? Should it also not be on the bare metal container?
<frankban> hatch: it makes sense if it's only on the machine IMHO
<hatch> the state service isn't in the root container?
<hatch> I know you're just following UX, this is more of a discussion :)
<frankban> hatch: jujud runs everywhere. What I think we are trying to communicate is which machine is a state server
<hatch> and that's not related in any way to the root container?
<frankban> hatch: I think the root container is a UI abstraction, from juju perspective the root container of machine X is machine X
<hatch> yeah good call
<frankban> hatch: we have machines and containers in the GUI, but in reality the relations is between nodes in a tree
<rick_h__> just a +1 to frankban there. The goal is to point out 2 things 
<rick_h__> 1. "why do I have a machine? I've not deployed anything yet."
<rick_h__> 2. "If you put stuff on this machine beware"
<rick_h__> and I guess #3 "We're not going to let you remove this machine, it's a state server"
<frankban> rick_h__: I think also 3. I want to know if this environment is HA
<hatch> yeah that sounds good
<hatch> rick_h__ frankban  it has the trash can still
<hatch> ^ should that be fixed in this branch?
<frankban> hatch: I don't think so, and in an HA env it's still ok to remove a state server if required
<rick_h__> hatch: I'd note it for follow up. It's under that big 'MV let's you do things you can't/shouldn't
<hatch> ok I'll add a note to the PR
<frankban> hatch: thanks
<hatch> ok commented, do with it what you will :)
 * rick_h__ goes to make up some lunch
<hatch> Makyo the bug #1350505 I know there are supposed to be a relation button but I can't get it to actually render
<_mup_> Bug #1350505: Relation inspector does not have actions attached properly <juju-gui:New> <https://launchpad.net/bugs/1350505>
<hatch> is there a trick or have I stumbled uppon another issue?
<hatch> ohh right they only pop up when there is a relation error
<hatch> deleting a relation using the popup when clicking the relation line doesn't ask you to confirm deleting the relation
<hatch> ^ rick_h__  this is a bug?
<rick_h__> hatch: because it's uncommitted now no
<rick_h__> hatch: because it's not confirming an action
<hatch> even on a deployed relation though too
<rick_h__> hatch: right, but when you remove it, you'll have to go commit
<hatch> I know relations are 'supposed' to be idempotent, but I'm nto sure if we want to encourage the use of that :)
<rick_h__> and see it in the summary/etc
<hatch> ohhh I get it
<rick_h__> hatch: it's a bit like asking you "are you sure you want to possibly do X"
<hatch> ok when you delete the relation from the service inspector it pops up a dialogue
<hatch> so I should remove that code now?
<hatch> er.....under mv that is
<rick_h__> hatch: ah, ok. Yea, welcome to clean that out if it's a small thing
<rick_h__> hatch: or create a post-mv release card
<rick_h__> but yea, the idea is that uncomitted state takes the place of 'are you sure'
<hatch> we will still need it if it's non mv unfortunately heh so I'll just wrap it with a mv flag check
<rick_h__> hatch: right, or just leave it for now and add a cleanup card
<rick_h__> hatch: as I'd like to see about this card landing to clear a release on monday?
<hatch> yeah I'll timebox at 30min
<rick_h__> k thx
<hatch> just writing tests now
<hatch> should have it up soonish
<hatch> ohh right the other thing in this bug is the unit name being a link https://bugs.launchpad.net/juju-gui/+bug/1350505 is this link supposed to open the unit details pane?
<_mup_> Bug #1350505: Relation inspector does not have actions attached properly <juju-gui:New> <https://launchpad.net/bugs/1350505>
<hatch> or should we remove the link
<hatch> I'm leaning towards the former
<hatch> rick_h__ ^
<hatch> I could easily just remove the <a> for now as well if you wanted this to land sooner
<hatch> Makyo thoughts on the unit link in the relations pane?
<Makyo> Not sure.  I could see removing it as a temporary thing until we have word from design.
<hatch> ok sounds good,
<hatch> dd
<hatch> fixed
<hatch> :P
<jrwren> Manchester United v. Real Madrid here tomorrow. So I'm off to the party downtown. Have a great weekend.
<hatch> jujugui looking for a review and qa on https://github.com/juju/juju-gui/pull/474 urgent bug required for release
<hatch> jrwren enjoy, try to not fall over and cry
<hatch> (little anti-soccer joke there)
<bac> hatch: new pycon web site up at https://us.pycon.org/2015/ -- shouldn't i be able to see that in french?
<hatch> it is...can't you see the accent on Montreal
<hatch> lol
<hatch> but yeah I'm pretty sure because it's in Quebec they have some rule about that
<hatch> bac you should review my branch :)
<bac> hatch: done, but i can't do QA atm
<bac> hatch: gotta dash.  have a good weekend/week.
<hatch> np thanks
<hatch> you too, safe travels
#juju-gui 2014-08-03
<huwshimi> Morning
#juju-gui 2015-07-28
<firl> hello all, anyone know of a good resource for an openstack install guide using the bundle for juju gui? I am having a hard time finding anything on it
<jcastro> the readme for the bundle?
<jcastro> have you seen this? https://jujucharms.com/openstack-base/
#juju-gui 2015-07-29
<lazyPower> seeing some weirdness out of quickstart, has anyone else seen this? https://gist.github.com/chuckbutler/4243f9fac13114e12c06
<firl> Hello all, anyone have experience with juju-gui, openstack bundle, and ceph? my drives from the config donât seem to be getting picked up. Just trying to chase the problem down to see if itâs user error
<rick_h_> lazyPower: looking
<rick_h_> firl: no, my understanding is that there's some config for some openstack components that have to happen once at install time or else it doesn't work as you can't change them
<rick_h_> firl: so we don't install openstack from the GUI for a working cloud atm
<firl> Just through landscape?
<firl> ( I did change the config values before committing them )
<rick_h_> firl: oh, that's interesting. Yea, the new uncomitted bundle support is new and we should try that now that you mention it
<firl> :)
<firl> Yeah Iâve been a proponent of it haha
<firl> I can open a ticket if you think that it is improper
<firl> iâve tried 3 deploys now just to make sure I wasnât crazy
<rick_h_> lazyPower: that looks like somehow there was a timeout or connection issue with the juju client asking juju to add_unit
<rick_h_> firl: oh no, you're not crazy, just in untested land since it wasn't ever possible before uncomitted bundles
<firl> very true
<lazyPower> rick_h_: seems to be new as of this week. This particular build was working last week :|
<firl> rick_h_: So is my best bet to get a non landscaped version of openstack running just making all the commands a script and config file and just use the CLI?
<lazyPower> i'll change the substrate and see if it changes bheavior
<rick_h_> lazyPower: so it's not a one off?
<lazyPower> its been consistent. to note: this is with the GCE provider
<rick_h_> firl: well there's the ubuntu installer? 
<lazyPower> i'll swap over to say aws and see.
<rick_h_> lazyPower: hmm, ok yes please let me know if there's an issue. 
<firl> rick_h: and just use the mutli node version? I was trying to specify where all the services went ( hence the bundler )
#juju-gui 2015-07-30
<firl> rick_h_ Just finished doing the openstack install via the gui only. I ended up having to remove the ceph services, re add them manually, commit the conifg, then add the machines then commit the units. 
<firl> rick_h_: If I could add a config file for a whole bundle, thatâd be awesome before placing the units
<rick_h_> firl: can you shoot an email summary to the juju list? I'd be curious to peek at what you did long form an expoose it to others.
<rick_h_> I'm afk at a sprint at the moment but want to check it out.
<firl> sure, I just need to figure out where the email distro subscription is
<rick_h_> https://lists.ubuntu.com/mailman/listinfo/juju
<firl> ty, I will summarize and send an email out
<rick_h_> ty much!
#juju-gui 2015-07-31
<firl> Anyone know of an easy way with juju-gui to enable a openstack-base deployment to accept juju configurations? I am looking through ( https://jujucharms.com/docs/1.24/howto-privatecloud )
#juju-gui 2017-08-01
<dakj> hello guy, from 2 weeks received that error each time I deploy openstack-base from juju-gui. the issue is on neutron-gateway (Status: error - hook failed: "config-changed") as reported the picture https://pasteboard.co/GDEmj8y.png
<rick_h> dakj: have to check what juju debug-log shows there when it fails. You can also juju ssh neutron-gateway/14 and look at /var/log/juju/unit-neutron-gatewayxxxxx.log and look at what failed?
<dakj> rick_h: here is it http://paste.ubuntu.com/25220561/
<dakj> rick_h: sorry I wrong!!!
<rick_h> dakj: ah ok. Yea looks like subprocess.CalledProcessError: Command '['ip', 'link', 'set', u'eth1', 'up']' returned non-zero exit status 1 is the error
<rick_h> but I don't know enough of the setup/charm to suggest how to work around/with that
<dakj> rick_h: it's strange because I made the same lab 2 weeks ago and it worked well. it's the fourth time I remade that and the issue is always the same
#juju-gui 2017-08-02
<dakj> hello guys, I've this issue about openstack bundle. from 2 weeks that I noted this error on neutron-gateway. I've opened also this post https://github.com/openstack-charmers/openstack-bundles/issues/28. thanks anyone has my same issue?
<dakj> anyone can help me about that issue? thanks
<dakj_> hello, I need your help. I deployed Openstack on my lab via juju but I noted an issue when try to create an new instance, the log section reports that: "Last exception: Profile is currently in use" code 500. I've opened also this post https://askubuntu.com/questions/942058/openstack-new-instance-error-profile-is-currently-in-use. thanks
<dakj_> someone can help me?
<rick_h> dakj_: you might try the openstack irc channel or their mailing list?
<rick_h> dakj_: unfortunately not a lot of OS experts idling in the juju-gui channel
<dakj_> rick_h: ok, I've already done that but any answer,yet!!! anyway I don't know if that issue is linked to that https://github.com/openstack-charmers/openstack-bundles/issues/28. 
