#juju-gui 2013-06-10
<benji> interesting, it looks like the Ubuntu One team is working on a statsd client and server: https://launchpad.net/pystatsd (project registered 11 hours ago)
<rick_h__> benji: fork/copy of https://github.com/sivy/py-statsd it looks like
<rick_h__> peeked at that before
<benji> thanks for the link, rick_h__ 
<gary_poster> Is there an Ubuntu One team at this point?  Or is just Sidnei?
<bac> Sidnei is a Team of One, like the US Army.
<bac> frankban: i'm available to QA your branch if it is still needed
<gary_poster> :-)
<bac> i need two reviews of https://codereview.appspot.com/10024046 if anyone has some time.
<rick_h__> bac:  done
<bac> thx
<benji> bac: I'll do a review
 * benji tags the card.
<gary_poster> hey luca__, you have a good visit?
<luca__> gary_poster: I did thanks, how are things?
<gary_poster> luca__, I'm glad.  had a good weekend, but would be nice if it were longer.  also somewhat worried for my wife's sanity starting tomorrow, because our boys will then be out of school for the summer. :-P
<gary_poster> luca__, call about scenarios looks good.  I assume you mean right after the standup?
<luca__> gary_poster: hehe that doesn't sound too good :P
<luca__> gary_poster: yeah
<gary_poster> cool
<luca__> gary_poster: I'm not sure how long we need to discuss them but we can talk more tomorrow if needed, just wanted to start working through them as soon as.
<gary_poster> luca__, I started on doc on Thursday to brainstorm stories.  I never got it to where I wanted it
<gary_poster> luca__, https://docs.google.com/a/canonical.com/document/d/1YTOmCCwSGMpZSXCQ_aRZz5UHXx6Tm4hr8X32Zz9iogw/edit#heading=h.y144flj0cwx4
<bac> rick_h__: making the GA id configurable is interesting but seems counter to our goals.
<luca__> gary_poster: fantastic, I'll give it a read over and we can talk about it later :)
<bac> rick_h__: the point, as i understand it, is for us to be able to gather usage patterns for anyone deploying the gui.  giving an easy way to subvert that seems counterproductive.
<bac> but it is an interesting thing for us to discuss
<gary_poster> luca__, cool.  I forget where I was going to take the last "Building an environment" discussion right now, but I know part of it was going to be that I like what you had in your story.  I think I was going to brainstorm different users/scenarios for when you might build from charms (experimenting, small use case, or building a bundle for the future) and when you might build from a deployer file/bundle (duplicating d
<gary_poster> ev or prod environment, deploying known good config from charm store and then tweaking, ...)
<luca__> gary_poster: I see, sound good :)
<frankban> bac: I am back. It would be great if we can take a look at the error you reported. It's weird. The usual chat seems open.
<gary_poster> rick_h__, hey.  When does sinzui usually start his day?
<gary_poster> bac benji frankban teknico, any of you interested in attending a call about grid units/making the gui friendly to mobile/responsive web design (I used to know this as "flexible web design" but now it seems to also refer to different form factors)?  It is in 4 minutes.  I'll attend.  It's not a good time for Ben Matt or Jeff or I would have invited them.
<gary_poster> 3 minutes :-P
<benji> not especially, but I'll be glad to drop in if no one else will take the bullet
<teknico> gary_poster: yep, pass the link
<gary_poster> teknico, priv msg
<rick_h__> gary_poster: usually between now and our 9:30 standup
<gary_poster> ok rick_h__.  I would have asked him to ask you the question above :-)
<gary_poster> jcsackett, too
<rick_h__> gary_poster: heh, responsive means using media queries in the css, so just an extra layer on flexible
<rick_h__> gary_poster: sure, I'll attend 
<gary_poster> rick_h__, gotcha. cool, will privmsg
<gary_poster> luca__, responsive call is now, yeah?  Rick and I are here.
<luca__> gary_poster: coming!
<rick_h__> bac: yea, but will most production deploys agree to share that info? and it solves the jujucharms.cmo case for my needs :)
<gary_poster> :-)
<bac> rick_h__: on a call so i can't think.  :)
<rick_h__> bac: I think a cool default would help but allow people to use it as they might find handy :)
<bac> benji: i like this "The looks good."  i think i'll adopt it as a reviewer catch phrase.
<benji> The looks, they are good, yes?
<bac> Time to fail for the "As seen on TV" self-shrinking garden hose I got for my birthday:  10 days.
<BradCrittenden> frankban: tests finished.  http://paste.ubuntu.com/5751661/
<frankban> bac: intersting, does that file exist?
<bac_> frankban: you mean /dev/null?
<frankban> bac: /home/bac/charms/precise/juju-gui/tests/.venv/local/lib/python2.7/site-packages/xvfbwrapper/xvfbwrapper.py
<Makyo> Anyone up for another review/QA? https://codereview.appspot.com/10048043/
<rick_h__> bac_: my call is done if you want to continue discussion of the GA id as config?
<Makyo> Note that that includes a comment WRT a deferred task.  Card is already created and assigned.
 * gary_poster had to actually google to discover what bac's hose could possibly be.  http://windo.en.alibaba.com/product/636728871-214175883/2012_Shrinking_Garden_Hose_As_Seen_On_TV.html for those with similar interest
<bac_> gary_poster: it wasn't really an endorsement
<bac_> although those were some of the most fun 10 days of watering
<bac_> hi rick_h__
<bac_> sure
<Makyo> Man, I love watering.
<hatch> morning all
<rick_h__> bac_: so I'm not up on the back story of the feature. I assume that it's defaulted to on, allow users to turn it off, and used mainly for helpful reporting of usage to make life better for all users
<rick_h__> bac_: my argument is that, allowing users to do their own reporting is a nice cool feature that our team would love to have in the charm, and doesn't adversely effect the original goal since most users won't change the default config
<rick_h__> the users that go into the config to chage the GA id are likely to be the same that would just turn it off anyway. 
<bac_> rick_h__: which deployment are you specifically talking about?
<bac_> uistage?
<bac_> rick_h__: wanna chat?
<rick_h__> bac_: sure
<gary_poster> luca__, thank you for organizing that mtg. was great to have.  would be thrilled to share more across teams
<luca__> gary_poster: thanks Gary :) I was really hoping it would be worth everyones time.
<sinzui> orangesquad: I created an mp for a mid-implementation review: My branch is 2 days old, now and there are a few issues I am not sure about: https://code.launchpad.net/~sinzui/charmworld/charm-model-fixes-views/+merge/168175
<abentley> sinzui: Oh, good grief.  I assumed "optional" mean "may be none", but it appears to mean "may not be present": http://docs.mongodb.org/manual/reference/gridfs/#gridfs-files-collection
<sinzui> abentley, If you mean "aliases" then I too think the value is None.
<sinzui> abentley, This is the dict problem  we have with charms isn't it?
<abentley> sinzui: I meant files.contentType
<sinzui> yep, it is listed about aliases as optional. We both think the value can be None, but the apparent use is the key may not be present
<abentley> sinzui: That's okay with a dict, but optional attributes on an instance are a PITA.
<rick_h__> luca__: yea, thanks. I'm bouncing off walls at the idea of a shared CSS lib. 
<abentley> orangesquad: could you please review https://code.launchpad.net/~abentley/charmworld/same-name-related/+merge/168190
 * sinzui looks
<luca__> rick_h__: haha, glad it was helpful :)
 * rick_h__ looks forward to the day when he doesn't have to look up the #-code for "ubuntu orange"
<gary_poster> rick_h__, sinzui in prep for meeting, https://bugs.launchpad.net/juju-gui/+bug/1186299 is done right?
<_mup_> Bug #1186299: The charm browser quality tab does not have data <charmbrowser> <juju-gui:In Progress by rharding> <https://launchpad.net/bugs/1186299>
<rick_h__> gary_poster: yes, I'll close up and link to the branch. Sorry I missed it
<rick_h__> gary_poster: reminds me, luca__ did you see my email about the quality tab and get a chance to peek at it?
<rick_h__> luca__: kind of a 'proposed' solution and would love feedback. 
<gary_poster> rick_h__, great thank you.  when will charm browser default land?  that was another goal for today
<rick_h__> gary_poster: jcsackett is working on it now I believe
<gary_poster> cool rick_h__  thanks
<abentley> sinzui: Is anyone chasing down the Tarmac issue today?
<sinzui> abentley, r=me, matsubara fell out of the channel the moment I tab completed him
<rick_h__> fastest review evar! on that branch 
<abentley> sinzui: !
<sinzui> abentley, we are thinking the same I think :)
<sinzui> I will follow up with matsubara
<hatch> rick_h__: can I set up some sort of config to open a tmux window with a certain window split every time?
<rick_h__> hatch: see pm
<hatch> thx
<bac_> gary_poster: rick_h__ makes the good point that until the GA opt in/out is easily available via the charm we should have the default for useAnalytics set to false.   i agree and would like to land this initial branch with it turned off.  a-ok?
<gary_poster> bac +1
<bac_> gary_poster: he also suggests a chat with jcastro to brief from a community perspective, which i'm also +1 and will be happy to do
<gary_poster> thank you bac_ , cool
<jcastro> we have a sync call in 2 minutes anyway!
<gary_poster> :-)
<gary_poster> y
<rick_h__> sinzui: can we ask for an update to mjc to get v2 api available on there?
<sinzui> I will after this meeting, you you can ask
<rick_h__> sinzui: k, I'll bug you post-meeting. I thuoght we needed to file an RT and wanted to check on the process. 
<sinzui> rick_h__, we do, and then we prod webops. We know the deploy will fail so hand holding is needed
<hatch> man I can never remember the syntax for linking with rst
<rick_h__> .. _something: google.com
<hatch> ...something something something....dark side
<rick_h__> lol
<hatch> rick_h__:  https://twitter.com/FromAnEgg/status/344111810431049728 :)
<rick_h__> hatch: :P http://www.webupd8.org/2012/03/retext-30-released-text-editor-for.html
<hatch> sure but that's another app :)
<hatch> maybe there is a sublime plugin
<rick_h__> I think there's a few editors that do live viewing
<rick_h__> hatch: yea, but it's live so you don't have to type/save/type/save/etc
<hatch> oh kewl
<hatch> rick_h__: why did you say // THIS IS BAD!!!!!!!!! on ln 1000 of app.js?
<hatch> it's not bad, the router is just broken :)
<hatch> although Ben fixed it this weekend I think
<rick_h__> hatch: oh crap was that in there?
<hatch> lol
<rick_h__> hatch: I was walking through the issue with jcsackett in a call and just marked out the line as we talked
<rick_h__> completely missed that in the diff, thought I reverted when I switched colo-branch
<rick_h__> hatch: lmao, thanks for catching. Mechanical whatever I guess...
<hatch> store/charm.js ln 164 "charmworldj"
<rick_h__> wtf, it's not in my local branch
<hatch> man it's a good thing I'm going through this :P
 * rick_h__ is so confused
<hatch> bad merge?
<rick_h__> must be, both of those aren't in my local code
 * rick_h__ does a re-propose
<hatch> doesn't look like codereview lets you do a self review - it doesn't turn your comment green
<hatch> this made me laugh this morning http://xkcd.com/742/
<rick_h__> hatch: cool, thanks for peeking at it. Yea, looks like a mess up from when I did a bzr switch between branches 
<hatch> is that a bzr issue when switching branches like that? Or did you mess something up? (curious)
<rick_h__> so I don't know exactly what I typed/did but I had uncommitted changes in a branch I didn't want. I created a new one and went to work and it carried over the uncommitted changes I think
<hatch> ahhh yeah I noticed it does that
<hatch> found that odd
<hatch> but I suppose git does something similar
<sinzui> orangesquad. We want to deploy, but we know migrations will fail. I propose landing a branch that makes migration 7 a no-op so that the deploy works without intervention. I am preparing a script that walks through the charms and generate a report to discover which charms have circular references.
<abentley> sinzui: Makes sense.
<gary_poster> jujugui call in 10. kanban now
<sinzui> abentley, matsubara is working on the ssh-to-Lp problem. I don't expect tarmac to work today
<abentley> sinzui: Okay.
<gary_poster> jujugui call now
<Makyo> Welp.
<sinzui> abentley, do you have a moment to bless or curse this merge: https://code.launchpad.net/~sinzui/charmworld/disable-migration/+merge/168482
<abentley> sinzui: I am confused about whether we still follow Launchpad policies.  If so, https://dev.launchpad.net/PolicyandProcess/XXXPolicy would dictate a bug number.
<sinzui> abentley, yeah, I sould have one since I have a card on the board for it
<sinzui> abentley, I updated the comment and reported bug 1189531
<abentley> sinzui: r=me
<sinzui> thank you
<gary_poster> luca__, alejandraobregon shall we meet in guichat or somewhere else?
<luca__> guichat is fine gary_poster 
 * hatch needs a break from docs
<benji> is there some reason errors are thrown with this format? "INVALID_STATE_ERR : Connection is open to another client."
<benji> specifically, the space before the colon; that seems like a weird thing to do in English
<hatch> English has consistent grammar rules?
<hatch> since when?
<hatch> :P
<hatch> gary_poster: I'm at a place with the documentation where I'd like to get some input from Ben before moving forward so should I move on to the ghost config with the view controller or did you have something else in mind?
<gary_poster> hatch, ...could you (a) land bcsaller's nsrouter branch and (b) work on replacing the alerts dropdown bootstrap stuff?
<rick_h__> hatch: on the ns-router lines I've changed it in my local copy, just have getHash do return window.location.hash;
<rick_h__> hatch: please take a peek before landing it as it is still broken for our needs in getting the active tab support landed
<hatch> gary_poster: can do
<gary_poster> thank you hatch
<hatch> no problemo
<hatch> rick_h__: guichat?
<rick_h__> hatch: sure thing
<abentley> orangesquad: could you please review https://code.launchpad.net/~abentley/charmworld/file-etags/+merge/168497
 * sinzui looks
 * hatch lunching
<bac> first they steal 'launchpad' and now 'mavericks' (sic)
<hatch> pourquoi?
 * hatch used the wrong word
<rick_h__> hatch: you're not up on your apple-fu
<hatch> sorry I've been WORKING today instead of reading blogs :P
<rick_h__> hatch: you need more screens :P
<hatch> I know!
<rick_h__> maybe now you can upgrade that laptop and get 3 thunderbolt displays on it so you can work with news on the side and know what bac knows :)
<hatch> damn shared video ram on a mac mini
<rick_h__> lol
<hatch> damn rights!
<bac> man i wish i had an external monitor
<hatch> xbox one $500? small price to pay for an invasion of privacy!
<rick_h__> hatch: come on, you get that for free with your gmail, twitter account, and ISP
<hatch> what is lacking with that is a camera and microphone in my livingroom
<hatch> glad MS is planning on filling that void
<sinzui> abentley, r=me
<abentley> sinzui: Thanks!
<Makyo> jujugui Another call for reviews: https://codereview.appspot.com/10048043/ Just need one more :)
<hatch> rick_h__: sorry I just don't trust MS enough to place an always-on video camera and microphone into my livingroom
<jcsackett> s/MS/anyone/
<jcsackett> jujugui: i too must ask for reviews https://codereview.appspot.com/10156043
<rick_h__> jcsackett: I'll peek in a second
<hatch> jcsackett: hah truth! Although if it was OSS then at least people could look into the source to find the inevitable bugs
<Makyo> jcsackett, on it.
<rick_h__> jcsackett: couple of notes while I look into the test regex part
<hatch> rick_h__: the sad thing is that I actually want the new xbox but not with the kinect
<rick_h__> jcsackett: I see what's up with the test issue, I'm working on some code to help it out. Will be a few min.
<Makyo> How long until people figure out you can just put the xbox in a well-lit diorama of your livingroom with the proper number of people painted on the couch?
<rick_h__> jcsackett: check out  lp:~rharding/juju-gui/sanity-check-default please and let me know how that looks
<sinzui> abentley, This is the script to look for errors in charm data. Dev and staging are fine as I expect. Do you have any additions to the script? http://pastebin.ubuntu.com/5752622/
<abentley> sinzui: No, it looks good to me.
<sinzui> fab
<hatch> Makyo: lol!
<gary_poster> hey hazmat.  May I schedule 30 minutes with you tomorrow to talk about bundles/deployer stuff?  Almost certainly will need more later, and with other people, but this can get things rolling again
<gary_poster> arosales, hey.  In https://docs.google.com/a/canonical.com/document/d/1FU29PCI2I2a-PUKCMHvt9jK6Jr1TcfyvUFDypHOQ_ic/edit# does ecosystems need to do anything to have test results ready on time or are they already ready to go?
<gary_poster> on the ecosystems side I mean
<hatch> Makyo: do I have to re-review your branch?
<Makyo> hatch, Don't think so, though you're welcome to.
<arosales> gary_poster, they should be ready to go
<hatch> Makyo: didn't we decide that we weren't going to fire events on other classes? re topology/panzoom.js ln 181
<arosales> if orange run into any issues on the parsing of test results though please let me and marco know
<gary_poster> great thanks arosales, so that deliverable is all on UX and GUI (Orange).  I'll call that out explicitly on list
<Makyo> hatch, I don't remember any such decision, but I do recall us deciding that Topology was it's on special sort of madness.
<hatch> yeah I remember that part haha
<hazmat> gary_poster, sure
<hatch> Maybe we just discussed it but didn't make any decisions
<hatch> anyways, my LGTM stands :)
<arosales> gary_poster, aiui that testing data from jenkins was in a consumable form. So yes next actions for testing are on orange and UI.
<arosales> s/ui/design
<gary_poster> thanks hazmat .  created event.  gave you edit power if you need to move it, but it worked with your calendar as it is now
<gary_poster> arosales, cool, thanks.  sinzui, do you all already have a plan for slurping up the jenkins data?  does it go in m.j.c and then the GUI gets it from there?
<sinzui> We have been slurping data since before orange took control
<gary_poster> cool sinzui, so this is entirely simply a matter of exposing something in the GUI?  The data already is moving to the GUI?
<sinzui> we also know know then data format changes because it breaks staging and production 15 minutes later
<sinzui> that's right
<arosales> gary_poster, np.
<hazmat> gary_poster, thanks, done.
<arosales> sinzui, let us (me and marco) know if you run into any issues slupring the testing jenkins data
<gary_poster> sinzui, data format changes: ok.  what's the status of that for long term m.j.c happiness?
<gary_poster> is that call-worthy?
<sinzui> arosales, we will :). All has been good for that last 6 weeks.
<arosales> sinzui, thanks, and good to know :-)
<sinzui> gary_poster, Its in the long-term charmworld stability blueprint
<gary_poster> ok sinzui thanks will see that when I get there then
<abentley> sinzui: I would like to discuss bug #1176452 with you.
<_mup_> Bug #1176452: ElasticHttpError:NumberFormatException[For input string: "yes" <elasticsearch> <ingest> <oops> <charmworld:Triaged> <https://launchpad.net/bugs/1176452>
<sinzui> in a few minutes abentley, otp with dan
<abentley> sinzui: ack
<hatch> I always thought otp = on the potty
<hatch> but it makes a lot more sense thaat it means on the phone
<hatch> lol
<BradCrittenden> benji: do you need to re-review the test i added?  'lbox propose' is running now and 'lbox submit' is on hit heels.
 * BradCrittenden hates his droppy internet
<benji> bac: nah, if you're happy with it then I'm fine
<bac> benji: i'm ecstatic
 * benji throws confetti
<sinzui> orangesquad, tarmac is back. We were blacklisted for hammering bazaar.lp.net
<abentley> sinzui: Ah.
<bac> hatch: did you qa teknico's branch?
<hatch> bac: I did - I didn't LGTM it though
<bac> hatch: i changed useAnalytics to true and ran it but don't see the banner.  am i missing something obvious?
<hatch> I think you need to be on sandbox: false with rapi running
<bac> really?  huh.
<hatch> oh wait - no that was just for prod
<hatch> nm
<hatch> bac: I think app.js line 1217 is the issue
<sinzui> abentley, sorry for the delay. I an talk now
<hatch> I am not sure if that is being set
<abentley> sinzui: Cool.
<sinzui> abentley, I can talk now
<abentley> sinzui: Your microwave may not be wi-fi compatible :-)
<sinzui> abentley, i just got kicked out
<abentley> sinzui: I have reinvited you, but it's just ringing and ringing and finally said "It looks like Curtis Hovey isn't available."
<bac> gary_poster: thoughts on GA on uistage?  leave it in or rip it out for now?
<hatch> bac: oh nm it appears to be being set
<bac> hatch: well i can't get it to work
<hatch> hmm sorry I'm not sure - I can look into it further if you would like but I have a few other things in front of it atm
<bac> hatch: nope, don't bother
<gary_poster> bac we have to have it as the cornerstone of everywhere else for GA to work, I thought.  wrong?
<gary_poster> s/of/for/
<hatch> bac: alright - imho it needs a bit more work before it's landable anyways
<gary_poster> or something...
<bac> gary_poster: on uistage i manually inserted the snippet into index.html.  my branch has now landed that has it for real, but with the config turned off.
<bac> gary_poster: i propose reverting uistage to not be divergent
<gary_poster> oic.  +1 bac
<bac> gary_poster: but that will disable GA for now
<gary_poster> bac will that screw up GA for other sites?
<bac> gary_poster: other sites?  other deployments will not have it turned on by default and i assume no one is going to hack it in
<gary_poster> bac, if so, I suggest reverting index.html but changing config to turn it on
<bac> er....
<gary_poster> bac, :-)
<bac> gary_poster: what other sites are you referring to?
<gary_poster> bac, I mean for when we turn this on in the charm
<bac> oh
<gary_poster> if we turn this on in the charm, GA needs to already be happy 
<bac> the jujucharms must be on stuff
<bac> yeah, well, i don't know how that'll work since it has been seen once.
<gary_poster> bac, I vote to leave it turned on in uistage, assuming that the cookies warning is working
<gary_poster> wdyt
<bac> gary_poster: so for uistage, revert index.html to the branch version and then set config-prod: useAnalytics true.  seems like a good plan
<gary_poster> exactly
<gary_poster> cool, thank you
<bac> the cookie warning will not land until tomorrow at earliest
<gary_poster> oh
<gary_poster> ok
<bac> lots of work from review
<gary_poster> mm
<gary_poster> then useAnalytics false bac, till that lands
<bac> ok
<hatch> no new MBP yet :( guess that's good for my credit card balance :)
<bac> gary_poster: done
<gary_poster> thanks bac.
<gary_poster> yeah hatch, was disappointed too :-)
<hatch> other sites are claming September which is quite a ways away for those who are in the market..
 * hatch <---- this guy
<gary_poster> huh.  it's 364 days since last update, which is most in their history (http://buyersguide.macrumors.com/#MacBook_Pro)
<gary_poster> oh wait
<gary_poster> never mind
<gary_poster> http://buyersguide.macrumors.com/#Retina_MacBook_Pro
<hatch> yeah it's definitely not been a long time....but haswell!
<gary_poster> I know
<gary_poster> completely with you
<bac> to make up for my negative review this morning, i heartily endorse this product: http://www.amazon.com/dp/B00008GS96/ref=tsm_1_fb_lk
<hatch> bac: lol nice comment in the review :P
<hatch> bac: here the bugs aren't big enough for those :( but what they lack in size they make up for in quantity
<bac> we have one upstairs and down
<bac> they make up by transmitting deadly disease
<bac> i mean, ours are tiny but awful
<hatch> that's unfortunate - ours are mostly disease free (as far as I know) but the ticks apparently aren't the cleanest
 * bac walks dogs, jojo + 2 little white things who spend 90% of the time tangled up in the leash
<hatch> lol
<Makyo> Dogwalk.  Eyes need a break;.
<rick_h__> jcsackett: still around?
<jcsackett> rick_h__: yup.
<rick_h__> jcsackett: so looking at the changes, was there something to not moving the browser subapp up into the original subApplications def vs a push in init?
<jcsackett> rick_h__: i don't follow.
<rick_h__> jcsackett: and the problem is that when the browser isn't FF'd it always tries to run and at least show the sidebar. There's no store though. 
<jcsackett> rick_h__: i know that part; but the phantom parsing of "test" is still not sorted.
<rick_h__> jcsackett: line 55 can have the subapp vs line 355
<jcsackett> as to the push, i have no preference. i whacked the flag and then hunted down test errors.
<rick_h__> jcsackett: ok, right, my first pass I mentioned that there's no need to have the subapp in the init and the extra call to push it
<jcsackett> rick_h__: i don't think i saw that.
 * jcsackett looks
<rick_h__> jcsackett: so the 'test' is that someone is testing urls that are just /something/test and it caused the code in the subapp browser to check it as an id
<rick_h__> jcsackett: so adding it to the id ignore was just a lucky 'ignore what someone decided to use in a test' vs a real fix to not try to run browser code when it's not intended
<rick_h__> jcsackett: so LGTM after moving the browser subapp def back to the top of the class per https://codereview.appspot.com/10156043/diff/1/app/app.js#newcode355
<jcsackett> rick_h__: huh; i grepped for that in the test file but didn't see anything to that effect.
<rick_h__> jcsackett: it was in other tests
<jcsackett> ah, and we have nothing for test isolation. right.
 * rick_h__ goes to look if he has the failures 
<rick_h__> jcsackett: right, all tests around the App() will hit browser the subapp since it's part of it now that it's not FF'd
<rick_h__> jcsackett: so the 'hack' is that other tests won't set a charmworld.url as part of their setup. 
<rick_h__> jcsackett: so the browser subapp just ignores things if there's not a valid store. Browsing makes no sense without it. 
<jcsackett> right; i like the store check as a fix.
<jcsackett> it was the phantom url that was irking me.
<rick_h__> might as well be a "isTesting" flag, but it's a bit more specific
<rick_h__> test/test_charm_running.py:        self.load('/test/')
<rick_h__> might have been teh cause
<rick_h__> just a quick grep, but anyway. Changes look good to me
<rick_h__> jcsackett: thanks for the update and un-FF'ing the browser. Look forward to not needed :flags:/ :)
<hatch> rick_h__: I think I have it     #.[^?/]*[$]?
<rick_h__> hatch: why the [$]?
<rick_h__> hatch: you should be able to remove that part
<hatch> ahh yes I can
<hatch> thx
<rick_h__> hatch: np
<hatch> turns out to be exactly what you said all along
<hatch> I was thrown by the wako results in regexpal
<rick_h__> once in a while I get lucky :)
<hatch> needed to revert to the console
<rick_h__> yea, tests or bust!
<hatch> regex pal for some reason highlights http: as well
<rick_h__> oh hmm, strange. 
<hatch> the console results are correct though
<hatch> ohh the regex is slightly off
<hatch> it should drop the first #
<rick_h__> hatch: ah, well the regex is only matching. In the match you can split/slice/trim to get rid of it. 
<rick_h__> hatch: I think there's some rtrim/etc functions available in there /me isn't at his desktop atm
<hatch> yep but the regex should only return the proper data
<hatch> why take another step when you don't have to
<rick_h__> hatch: well, you're asking it to match. It's going to match the character. I tried once to do a #(xxx) type of things but didn't see a good way to get at the () part
<hatch> ahh ok
<rick_h__> hatch: well, if you find a good way let me know, but I've manually trimmed/etc in my use. You know it'll be there because it's part of the match so it'll always be there
<hatch> rick_h__: ([#])(.[^?/]*)?
<hatch> use this url: http://gui:8888/sidebar/precise/ceph-9/:flags:/browser_enabled/#bws-configuration=foobar&stuff=awesome?query=charms
<hatch> the 3rd match....
<hatch> pretty sure this isn't ideal
<hatch> haha
<hatch> can drop the [] in the first parens I guess
<rick_h__> hatch: this is nicer than just url.match(/#[^?/]/).replace('#', ''); ?
<rick_h__> sorry
<rick_h__> hatch: this is nicer than just url.match(/#.[^?/]*/).replace('#', ''); ?
<hatch> it's a lot harder to understand so yes
<hatch> :P
<rick_h__> lol
<hatch> rick_h__: did you want to pull down my branch to test?
<rick_h__> hatch: not atm, I'm EOD and on the tablet. 
<hatch> ahh ok jcsackett still around?
<rick_h__> hatch: my branch if up if you want to test it out 100%, but if that urls passes I'm good
<rick_h__> hatch: go ahead with it and I'll pull the update down into my branch tomorrow
<hatch> here is the diff, look good? http://bazaar.launchpad.net/~hatch/juju-gui/routing-hash-query/revision/714
<rick_h__> https://code.launchpad.net/~rharding/juju-gui/direct-2-tab  is my branch
<rick_h__> hatch: looks ok from here
<hatch> I figured you could just see the tests to see that it appears to cover all of the use cases we need
<hatch> urls are the epitome of edge cases
<rick_h__> hatch: yea, don't need to get 100% atm, but having tests and getting the - we know we need will help :)
<hatch> rick_h__: so I can't propose this because lint is giving me an odd error
<hatch> var match = url.match(/(#)(.[^?\/]*)?/);
<rick_h__> hatch: is it because of the /?
<hatch> line 111, col 34, Insecure '.'
<rick_h__> ah, yea
<rick_h__> hatch so change the start and end / to "
<hatch> quote a regex? I thought that was a nono
<rick_h__> the start/end chars can be anything I believe
<rick_h__> making them " makes the liter shush
<rick_h__> so actually ' since the litner will fuss over " vs '
<hatch> yah - that's odd
<hatch> I wonder it's reasoning
<rick_h__> hatch: yea, I gave up trying to understand and just bend to the will of the linter
<hatch> hehe
<rick_h__> trying to change it in the case of a regex like that just seems like it'd be a pita to detect the exception 
<rick_h__> hatch: I think the warning is that . matches any character and can be a case of 'getting more than you wish for' when it comes to regex
<rick_h__> hatch: so I *think* it's a warning because of that, but it's messier to add ignore/etc clauses around the code than to just ' vs /
<hatch> true true
<hatch> I really need to figure out why phantomjs keeps crashing
<hatch> it crashes probably 50% of the time :/
<rick_h__> :/
<rick_h__> that sucks, not here
<rick_h__> trying to use it more and more since it's a chunk faster than even chrome in test runs
<hatch> oh yeah it should be way faster because it doesn't have to do any DOM updates
<hatch> and I think they are both V8 aren't they?
<rick_h__> yea
<rick_h__> hah, did bcsaller just submit an update while you've been working on this :(
<rick_h__> hatch: heh, so bcsaller updated the branch, but I think the regex is a little nicer and fewer calls. Compare notes I guess with each other and I'll pull down which ever survives the night for my needs
<hatch> heh
<hatch> clearly you should pick mine
<bcsaller> yeah, sorry about that
<bcsaller> just trying to help
<hatch> pfft
<hatch> ;)
<hatch> so how will we settle this?
<hatch> put both branches in a url parsing test to see who's wins?
<hatch> :P
<bcsaller> well, I didn't add a test for the new case so if you have that you win :)
<rick_h__> implementation fight! go go go!
<hatch> I did!
<hatch> yusss
<rick_h__> I want to see timeit results!
<hatch> lol
<hatch> regex vs two indexof and a slice call
<hatch> oo it would be a close one
<hatch> micro optomization ftw
<rick_h__> thanks bcsaller, appreciate the update 
 * hatch is going to land his branch if he can get some reviews
<hatch>  https://codereview.appspot.com/10176043/
<hatch> as soon as I ask for a review it goes quiet in here.....
<hatch> lol
<rick_h__> hatch: heh, well it's hard to multi-task and use the code review site on a tablet
<rick_h__> every touch to the screen brings up a comment box and moves code around, most annoying
<hatch> haha yeah it's probably not under active development
<hatch> not really sure what to do re your comment rick_h__
<rick_h__> hatch: yea, me either, but if we're going to add a TODO seems there should be something to make sure it does get done one day, be it bug, card, etc
<hatch> yeah a bug probably
<hatch> I don't really understand what it's saying though so maybe we can leave that one for bcsaller to make
<bcsaller> hatch: already resolved by line 314
<hatch> bcsaller: so that comment can be removed?
<bcsaller> yes
<hatch> kewl
<hatch> I'm going to land after removing that comment as it's like a pair programming at this point :)
<bcsaller> otherwise those could appear as namespaces, but they are non-enum props on Routes objects
<hatch> ahh I understand now
<hatch> ok changing and submitting
#juju-gui 2013-06-11
 * frankban lunches
<gary_poster> ugh
<gary_poster> if we could actually land Makyo's zoom-to-service branch that would be fab.  uistage still has silly people
<rick_h__> review request bribing time: https://codereview.appspot.com/10140047 please orangesquad or hatch who's not here yet or anyone else that loves tabs in the browser. 
<tekNico> gary_poster: thanks for assigning that card to me, I got distracted
<gary_poster> tekNico, np :-)
<jcsackett> rick_h__: looking.
<tekNico> gary_poster: I'm assuming that adding the AGPL to the charm means adding the license file itself, and the header to all source files. Anything else?
<gary_poster> tekNico, there's a Canonical-specific list to follow.  that might be everything. Let me try to find it again...
<gary_poster> tekNico, see https://sites.google.com/a/canonical.com/legal-services/software-ip
<tekNico> gary_poster: thanks
<gary_poster> Makyo, hi.  If you are around and can make it, I scheduled you on Tuesdays for the Juju core kanban review (check your calendar). If you can't make it today because of the short notice, np
<gary_poster> frankban, hi. I saw that jcsackett's branch failed in jenkins only on the two test_charm_deploy tests.  It doesn't look like the error tells us much, but do you have any deep suggestions?
<gary_poster> non-deep suggestions: jcsackett runs the tests locally and sees how they do :-)
<jcsackett> gary_poster: they pass.
<gary_poster> jcsackett, that's the charm deploy tests too?
<gary_poster> I figured the unit tests did :-)
<jcsackett> gary_poster that's test-misc, right?
<gary_poster> uh.  I don't *think* so.  looking.
<frankban> jcsackett: no, that's bin/test-charm
<jcsackett> frankban: ah.
<gary_poster> yeah, that's what I thought :-)
<frankban> jcsackett: instructions on how to run local ci tests are in docs/continuous-integration.rst
<jcsackett> frankban, gary_poster: Invalid environment 'juju-gui-testing'
<frankban> jcsackett: see docs/continuous-integration.rst ^^^
<gary_poster> jcsackett, yeah frankban gave you the doc to try.  FWIW, this is entirely something that jenkins is supposed to catch, and that you didn't need to run beforehand.  May I ask this?  (1) you try to get the local ci tests running.  Assuming you do, (2) verify that they pass for you.  Assuming they do, (3) toss it to me and forget about it yourself.
<gary_poster> jcsackett, you may skip to step 3 at any point if you get too fed up :-)
<frankban> jcsackett, gary_poster: it seems selenium wants to click the deploy button while it's still not visible, taking a look locally seems reasonable. oh... is the charm panel still there? if not, we have to rewrite the deploy tests
<jcsackett> gary_poster: sure, i can poke at them locally.
<gary_poster> thanks jcsackett .  frankban charm panel still there I think
<gary_poster> upcoming branch removes it
<hatch> rick_h__: still need that review?
<hatch> and morning
<rick_h__> hatch: yes please, and morning to you to
<hatch> tekNico: sorry I didn't realize that the cookie code was given to you :)
<tekNico> hatch: yeah, I changed it anyway, can change it some more :-)
<frankban> gary_poster: this is probably unrelated, but I am not able to deploy appflower (and other charms) in uistage
<jcsackett> gary_poster: to make sure i am understanding this right, "local" is a bit of misnomer, as i need to run this out to canonistack or ec2?
 * jcsackett is reading docs, as this is all new.
<gary_poster> frankban, it works if you give it a unique name
<tekNico> hatch: what's the best time for a follow-up hangout for you?
<gary_poster> frankban, some people think it is amusing to drag everything off to the right
<gary_poster> I think they might even have scripted it
<frankban> gary_poster: oh :-(
<tekNico> it's a weird kind of QA :-)
<hatch> tekNico: pretty soon, I'm just reviewing ricks' branch first
<tekNico> hatch: ok, thanks
<hatch> rick_h__: can you pull in the hash branch I landed last night and use the parsed hash?
<rick_h__> hatch: it should have it since it landed in trunk
 * rick_h__ goes to check diff...
<hatch> I'm just asking because in browser.js you use window.location.hash
<gary_poster> jujugui I just switch uistage to sandbox.  Too annoyed at the script kiddies
<hatch> yay
<frankban> cool
<rick_h__> hatch: heh, yea I've pulled your changes in the routing code, but in the browser subapp I just grab it from the browser. 
<hatch> :)
<rick_h__> hatch: is the router adding the hash to the req in the app callables?
<rick_h__> hatch: the router updates keep it from losing the hash and re-routing, but didn't see it provide it down into the app somewhere. 
<hatch> I thought that the hash was available in there
<hatch> regardless
<hatch> just booting one up to check
<rick_h__> hatch: I don't think it's part of the yui parsed request object passed in
<hatch> hmm looks like you are right, maybe you should use nsRouter.parse(url).hash
<hatch> not entirely sure it's necessary however
<rick_h__> hatch: yea, the goal was just to not have the router blow the hash away from window.location.hash. I don't see any harm in me reading it from there in the actual request handling bit. 
<hatch> yeah
<rick_h__> hatch: it's r/o 
<hatch> r/o ?
<rick_h__> read-only
<abentley> orangesquad: could you please review https://code.launchpad.net/~abentley/charmworld/missing-content-type/+merge/168672 ?
<rick_h__> abentley: looking
<rick_h__> abentley: r=me
<abentley> rick_h__: Thanks!
<hatch> rick_h__: review done
<rick_h__> hatch: reply inbound
<rick_h__> jcsackett: if you get a second can you peek at my reply/update for the second +1 please
<hatch> rick_h__: cool
<hatch> tekNico: guichat?
<tekNico> hatch: I'm doing a review myself now :-) a few minutes and I'm done, ok
<hatch> okee sure np
<tekNico> hatch: don't start another review yourself though ;-)
<hatch> haha nope
<jcsackett> hatch: do you have a second to chat?
<hatch> lets do it
<hatch> guichat
<jcsackett> }"?cccccc
<hatch> lol wth
<jcsackett> dog knocked over my computer, yubikey hit couch.
<hatch> haha
<jcsackett> hey, this is better than it was a week ago; then i would just accidentally whack it myself.
<gary_poster> orangesquad, hey.  hazmat pointed out that if you go to http://uistage.jujucharms.com:8080/fullscreen/ and click on a category on right you get an error
<gary_poster> known?
<gary_poster> known fix?
<rick_h__> gary_poster: looking. We had another bug with that fixed. Looks like a new one was hiding underneath
<gary_poster> thx
<rick_h__> gary_poster: filing a bug now and will get it on the board to look at.
<abentley> rick_h__: The URL is wacky-- it has ? where it should have &
<rick_h__> abentley: yea, and series is in there several times
<rick_h__> abentley: will look into it right now as I've not gotten into the other card much yet, landing yesterday's stuff
<tekNico> hatch: hangout? https://plus.google.com/hangouts/_/02bb45411739e441fe107c9f66e2a8cc36ba4ba7?authuser=0&hl=en
<hatch> tekNico: sorry in a hangout now :)
<tekNico> oh wow :-)
<jcsackett> frankban: so, i've read through the docs, i'm unsure how to debug this test locally. how does one do that?
<hatch> we need to update the CI docs with instructions on how to do it locally from start to finish
<hatch> tekNico: guichat?
<tekNico> hatch: yep!
<jcsackett> gary_poster: i think i may be jumping to option 3 here, as i cannot see how to do this locally on my machine, and if local actually means "running on ec2" i don't have any of that setup since having to reinstall and probably don't have the time/bandwidth to get that set up today.
<gary_poster> jcsackett, ack but on call
<jcsackett> dig.
<frankban> jcsackett: I suggest configuring the juju-gui-testing env with the ec2 provider and then running  NO_DESTROY=1 JUJU_GUI_TEST_BROWSERS="local-firefox" bin/test-charm. 
<frankban> jcsackett: later you can repeat the tests without boostrapping the env again with APP_URL="http://ec2-xxx-yyy.example.com" bin/test-charm
<frankban> this way the tests will be run in your local firefox, and you can debug/pdb as usual
<abentley> rick_h__: To properly fix bug #1176452, we think we need to change the JSON stored by mongo and elasticsearch.  That will change the json emitted by the original API (e.g. http://staging.jujucharms.com/charms/precise/mysql/json).  Do we know of anything still using that API?
<_mup_> Bug #1176452: ElasticHttpError:NumberFormatException[For input string: "yes" <elasticsearch> <ingest> <oops> <charmworld:Triaged> <https://launchpad.net/bugs/1176452>
<rick_h__> abentley: looking
<rick_h__> abentley: yes, until the branch that removes the old browser lands it's using and calling that and might throw errors since it auto loads results on init
<rick_h__> abentley: we should chat with sinzui about getting the old browser code out of there soon now that we're landing browser by default. 
<abentley> sinzui, rick_h__: I'm up for a chat anytime.
<rick_h__> gary_poster: you had mentioned there was a branch for removing the old browser already? Or did I mis-read that?
<gary_poster> rick_h__, misread
<rick_h__> gary_poster: ok, cool. 
<sinzui> abentley, jcsackett and are about to have our our weekly call. We will be done about 30 minutes from now
<rick_h__> sinzui: rgr
<abentley> sinzui: Cool.
<gary_poster> jcsackett, are you trying frankban's instructions or do you still want step 3?
<hatch> I don't think he had juju environments and ec2 set up
<hatch> and I wasn't sure how to run it all locally
<gary_poster> jujugui ci is failing.  could someone volunteer to investigate as critical task please?
<hatch> gary_poster: sure
<hatch> if the alert can wait :)
<gary_poster> hatch alert is high priority too.  frankban do you have half hour to investigate first?
<gary_poster> or tekNico 
<tekNico> gary_poster: I'm juggling two things already...
<gary_poster> tekNico, then not you :-)
<gary_poster> tekNico, what's your non-GPL thing?
<tekNico> gary_poster: the cookies warning, hatch just revolutionized it :-)
<gary_poster> tekNico, heh oh ok
<tekNico> (is that a verb?)
<hatch> it can be :)
<gary_poster> uh, not sure
<gary_poster> yeah
<gary_poster> it is
<tekNico> ok, thanks :-)
<hatch> the rules of English were made to be broken
<gary_poster> hatch revolutionized the cookies industry!
<hatch> lol
<gary_poster> we're Americans.  We like verbing things.
<hatch> and forgetting u's
<hatch> ie) colour
<gary_poster> yeah.  Canadians do that too, yeah?
<hatch> nope we love our u's
<gary_poster> oh.  stinky u's. :-)
<hatch> favour
<hatch> lol
<tekNico> (actually three things, I'm also qa'ing a branch by frankban)
<hatch> is there a UX bug for the width of the sidebar?
<hatch> ^ luca__
<jcsackett> gary_poster: sorry, was OTP. looks like you've already implemented step 3?
<frankban> gary_poster: taking a look with local firefox.
<gary_poster> jcsackett, frankban is looking.  maybe worth working with his instructions for the future though?
<gary_poster> thank you frankban 
<hatch> rick_h__: is the browser sidebar set to min-width 350px on purpose? It should probably be max-width?
<luca__> hatch: what is the bug with the side bar?
<rick_h__> hatch: yea, it's on purpose
<jcsackett> gary_poster: i've copied his instructions and when i next have slack i'll make sure i can follow them.
<hatch> luca__: oh - well it looks 'wrong' on my monitor because it has a min-width of 350px not a max-width
<gary_poster> ack thanks jcsackett 
<hatch> so there is just a bunch of whitespace beside everything that looks off
<rick_h__> hatch: screenshot?
<hatch> one moment
<luca__> hatch: screenshot! :D
<hatch> lol
<hatch> https://www.evernote.com/shard/s219/sh/073fa338-306e-4fca-bb80-8f954e549add/f6d7b3c935bd8b66934bf7506262f081/res/e4ba1ae1-0155-4c09-af8e-5b15dff3b7a7/skitch.png
<hatch> ^ rick_h__ luca__
<rick_h__> hatch: heh, well don't view it fullscreen on 1920px :P
<rick_h__> hatch: there's talk about making things more responsive and dealing with 'grid units' but it's not in the immediate future
<hatch> hah I'm nowhere near fullscreen on my monitor :)
<luca__> rick_h__: can you explain what the issue is? o.O
<hatch> it looks proper if we change the min-width to max-width
<rick_h__> hatch: well I did say 1920px
<gary_poster> rogpeppe, gentle reminder to reply to the two gui-related emails from william :-)
<hatch> well...really just 'width' :)
<rick_h__> luca__: so he's complaining about the wasted space to the right of the charm-tokens because it's seto to 25% and he's viewing it on a giant screen
<hatch> that
<luca__> rick_h__: I see, good spot hatch :P
<rogpeppe> gary_poster: will do, thanks for the poke
<hatch> if you're ok with it being set to a fixed width of 350px instead of a min width it's a one line and 4character fix :)
<gary_poster> thanks rogpeppe :-)
<hatch> are failures in the simulator not supposed to trigger alerts?
<hatch> jujugui call in 3 ;)
<gary_poster> ugh thanks hatch
<hatch> haha np
<Makyo> ---> https://codereview.appspot.com/10048043/ <---
<jcsackett> frankban: link?
<frankban> jcsackett: https://codereview.appspot.com/9714047
<abentley> orangesquad: Could you please review https://code.launchpad.net/~abentley/charmworld/factory-uses-process-charm/+merge/168724 ?
 * sinzui looks
<tekNico> Makyo: don't you have two reviews already for your "zoom to service" branch?
<sinzui> abentley, r=me
<Makyo> tekNico, no second LGTM, and Ben's out this week.
<tekNico> Makyo: ok, I'll do it
<Makyo> tekNico, thanks!
<frankban> guihelp: does anyone have info about the "failed to load editorial content" notification?
<gary_poster> rick_h__, ^^^
<hatch> frankban: I could be wrong with this - but I think that happens when the request to the jujucharms.com fails
<frankban> hatch: ok thanks
<rick_h__> frankban: looking
<rick_h__> frankban: yea, I'll need the network info from the debug tools. Right now we know we've got a problem with the new routing code and searches which use query strings
<rick_h__> frankban: I'm not aware of anything ootb right now on interesting loading
<frankban> rick_h__: ack, just investigating CI failures, and that notification captured my attention
<rick_h__> hatch: so yea, but the question would be what failed and why
<rick_h__> frankban: definitely. If it's just in tests then it should be ok, but if you see it in use we need to figure out why it's failing. 
<hatch> rick_h__: there is no why, there is only do
<hatch> *hatchisms*
<rick_h__> hah
<frankban> rick_h__: I am actually seeing those in a ec2 deployed GUI (used by CI tests) -> http://ec2-107-20-106-2.compute-1.amazonaws.com/
<rick_h__> frankban: ok, config issue. The url needs to end in a trailing /
<rick_h__> frankban: both config-debug and config-prod have it, not sure where the config is from in the charm where it doesn't have it
<frankban> rick_h__: you mean charmworldURL: "https://manage.jujucharms.com" ?
<rick_h__> frankban: rgr
<hatch> removing bootstrap from the page actually breaks damn near everything :/
<rick_h__> frankban: I mean 'roger' or yes
<rick_h__> hatch: yea, why we left it for you :P
<rick_h__> hatch: we took a peek at that back when we first started with design/huw in march
<hatch> it's not just the alert button that huw had mentioned but everything
<frankban> rick_h__: so the default value in the charm config is invalid. however, since this is something the user can change (providing a customized juju --config) I'd prefer the trailing slash to be handled by the GUI code... thoughts?
<rick_h__> frankban: yes, we can add a bug to check for a /$ and add it if it's not there. 
<rick_h__> frankban: I'll add it now
<frankban> rick_h__: thank you
<frankban> rick_h__: in the meanwhile, I'll quickly fix the default value in the charm
<rick_h__> frankban: thanks
<hatch> gary_poster: so I have now extracted and replaced all of the bootstrap styles effecting the alerts button and made steps to gradually move away from bootstrap. But bootstrap still cannot be removed as other parts of the app rely on it
<hatch> how far down this rabbit hole should I go?
<hatch> frankban: was the CI failure caused by a missing trailing / ?
<frankban> hatch: still investigating
<hatch> ohh, I saw your commit and wondered if that was the fix
<frankban> hatch: it can be related
<rick_h__> hatch: jcsackett have any opinions on this tiny patch? https://codereview.appspot.com/10193043
<rick_h__> honestly about to self-review, but give you all a chance at it :)
<rick_h__> hmm, actually yea I'm missing a line of removal still. doh!
<hatch> combine now handles that, yes?
<rick_h__> hatch: right
<rick_h__> hatch: so it was double adding the qs and cauing issues later down the pipe
<hatch> well then....guess you know what I'm going to ask for next :P
<rick_h__> hatch: a pie?
<hatch> a test!!!
<hatch> weeeee tests!
<rick_h__> hah, thought about it. but I'm testing that code that's no longer there no longer functions 
<rick_h__> :/
<hatch> hahaha
<hatch> is there a test that checks to make sure the combine works properly?
<rick_h__> hatch: correct, what was missing was a test that navigate had a query string on it, but now that navigate doesn't add a query string that test makes no sense
<rick_h__> and by navigate I mean _navigate
<hatch> sure okee
<hatch> LGTM
<sinzui> abentley, I think search is broken/missing from staging? Any insights
<rick_h__> ty
<hatch> once you remove the line creating qes
<rick_h__> hatch: yea, that's pushed up. Hit refresh
<hatch> qa I mean
<hatch> ARG
<rick_h__> lol
<hatch> qs
 * sinzui can see that the staging logs are dominated by KeyError: 'branch_deleted'
<rick_h__> log domination ftw!
<rick_h__> ...or not
<jcsackett> rick_h__: if i'm understanding this, you've found a path wherein the QS was preserved, and then parsed out and added again, yes?
<abentley> sinzui: Oh, that sounds like a problem.
<rick_h__> jcsackett: no, I found a path that had a url witha valid query string, and then...reappended a query string again 
<jcsackett> you just said what i said with different words. or at least what i was intending to say.
<jcsackett> :-P
<rick_h__> if it had removed it, it might have worked :)
<rick_h__> "parsed out" or whatever
<jcsackett> e.g. the nsRouter stuff now preserves QS, the code you deleted parsed the QS from the URL, then appended...but it was already there.
<jcsackett> right.
<jcsackett> anyway, kill it.
<rick_h__> jcsackett: I follow ya, yea. 
<jcsackett> i can LGTM if you want, or you can self review.
<rick_h__> jcsackett: LGTM please so I can say I was all official and people looked over my shoulders :)
<abentley> sinzui: I believe abel's branch is broken and only works for new charms that have branch_deleted set.
<abentley> sinzui: IOW a catch-22
<sinzui> abentley, yep
<sinzui> I reported the bug. easy fix.
<abentley> sinzui: Sorry I didn't notice this in the review.
<abentley> sinzui: I can take it if you like.  Just started on another bug.
<sinzui> abentley, okay. https://bugs.launchpad.net/charmworld/+bug/1190002
<_mup_> Bug #1190002: KeyError branch_deleted <ingest> <charmworld:Triaged> <https://launchpad.net/bugs/1190002>
<sinzui> your choice of defensive coding or update and use the model.
<rick_h__> gary_poster: so heads up, bug on the categories link that hazmat brought up is landing now. Small regression from last night to today so hopefully short lived and no pain.
<gary_poster> cool thank you very much rick_h__ 
<rick_h__> next bug! /me is declaring it bug fixing day
<gary_poster> :_)
<hatch> gary_poster: did you see my q above?
<gary_poster> hatch, no looking
<gary_poster> hatch, only as far as we need today for header.  thank you.  if you've done any extra, great, but no need for more
<hatch> honestly I'm not exactly sure what needs to be done - this is to change things for the grey header?
<abentley> sinzui: Odd, branch_deleted gets set by the lp scan.  I don't know how it's missing.
<gary_poster> sorry hatch I meant the notifications thing
<abentley> sinzui: Unless the branch *just* landed.
<gary_poster> hatch, huw doesn't want to have to  deal with bootstrap AIUI.  I think he also wants to have YUI style css control over the notifications panel
<sinzui> abentley, ~zulcss/oneiric/nagios looks very old
<hatch> well that's simply not going to happen without a new UI, the bootstrap styles controlling the notifications is ~150lns
<frankban> gary_poster: retrying a CI run now. This is just to test if the problem was the error notification appearing due to an invalid config option in the charm defaults, and preventing the charm panel link to be clicked. If that's not the case, I'll continue tomorrow morning if not solved before. Created a critical card in Maintenance.
<hatch> but I separated them out for him so they are easy to modify now at least
<abentley> sinzui: No, I mean unless abel's branch *just* landed.  Which I can see it didn't.
<gary_poster> thank you frankban 
<sinzui> abentley, right, it was merge by tarmac about 24 hours ago
<sinzui> abentley, the first error is 2013-06-11 08:58:07
<gary_poster> frankban I will ask someone else to run with it this afternoon if not fixed
<gary_poster> hatch, uh.
<frankban> gary_poster: cool, thanks
<abentley> sinzui: But the last error is 2013-06-11 09:00:05
<gary_poster> hatch, I honestly have no idea what Huw's concern is tbh.  I don't see why he can't change the top header without changing the notifications panel
<sinzui> ah
<gary_poster> rick_h__, do you have any insight into above, maybe?
<hatch> gary_poster: yeah - I'll propose my branch so you can see what I have done for him - see if it's what you had in mind
<gary_poster> ok thanks hatch 
<abentley> sinzui: I think the problem was that the queued data didn't match the new code.
<abentley> sinzui: And therefore it's no longer an issue.  Which leaves the other problem mysterious.
<gary_poster> hatch, how trivial is it to disable and remove the top search?
<gary_poster> do you know off hand?
<sinzui> abentley, I see that ingest errors is current and nasty
<hatch> umm - if I remember fairly trivial
<hatch> not sure what the side effects would ne
<hatch> be*
<hatch> we could remove the html though really easy :)
<abentley> sinzui: Where do you see it?  I can't see a recent example in app.log or ingest-errors.log
<sinzui> abentley, ingest-lp.log
<gary_poster> hatch, heh
<abentley> sinzui: AttributeError: 'MongoQueue' object has no attribute 'charms'?  Yes, that looks bad.
<hatch> we would also need to remove the charms dropdown button
<gary_poster> yes
<hatch> one minute I'll look deeper
<gary_poster> thank you
<abentley> sinzui: bin/enqueue exhibits the error locally.
<hatch> gary_poster: so I'd like to say that it would simply be removing things from the instance creation constructor but should probably allow......4h? JIC
<gary_poster> hatch ok
<gary_poster> hatch, are you up for this or would you like me to find someone else?  This is more immediately pressing than the inspector work, but I really want that to proceed as well.  If you'd rather not do this right now, lemme know
<hatch> sure I can
<sinzui> abentley, shall we consider the script to remove ObjectId charms? Ot was run on staging 4 hours ago, and production in the last 15 minutes
<hatch> this will definitely be a - diff :)
<abentley> sinzui: What should we consider about the script?
<gary_poster> :-) thanks hatch
<sinzui> abentley, I don't think the remove() call could cause the queue to loose charms, but maybe on second glance it is bad...http://pastebin.ubuntu.com/5755316/
<hatch> gary_poster: np! I'm going to move bens controller card into daily to free up space if that's alright?
<sinzui> abentley, this is the report from the production run...look good to me: https://pastebin.canonical.com/92568/
<abentley> sinzui: I don't think the script is implicated.
<abentley> sinzui: I think that ingest is broken, and all the current charms are in a bad state because of the last ingest.
<sinzui> fab, then production probably wont go blank
<gary_poster> hatch, how 'bout this
<abentley> sinzui: For example, http://staging.jujucharms.com/charms/precise/apache2/json has an 'errors' member.  I bet all branches do.
<gary_poster> (1) propose your/ben's current branch.  use Ben's card for that 
<abentley> s/branches/charms
<sinzui> abentley, yes, that is what I thought at first when I saw the branch_deleted, but the 
<sinzui> AttributeError: 'MongoQueue' object has no attribute 'charms'
<gary_poster> (2) hopefully you 'll have reviews for your alerts dropdown by then and can land
<sinzui> confuses me
<gary_poster> (3) then you'll have room :-)
<abentley> sinzui: I get that locally when I run bin/enqueue.  I've never run  your script.  I think abel never tested locally.
<hatch> hah sure - `recess` is throwing an error but doesn't tell me what the error is :/
<sinzui> abentley, we have two branches found by interfaces...and one is ~chilicuil that we discussed before
<abentley> sinzui: Also, the API lists only two charms.
<abentley> http://staging.jujucharms.com/api/2/charms
<sinzui> abentley, yep, those two. We can added a defensive check to the code.
<abentley> sinzui: Sorry, I forget what context they were relevant to.  Are they potentially deleted?
<hatch> hmm
<abentley> sinzui: bzr certainly thinks they aren't branches.
<sinzui> abentley, ~chilicuil is my Cthulhu example form a few days about charms without branches that dominate the error logs
<sinzui> the recent change inverts the case where good charms error and dominate the logs
<abentley> sinzui: It
<abentley> sinzui: It is the charm that had no contentType earlier, suggesting a deleted branch.
<sinzui> yeah
<abentley> sinzui: Anyhow, once we fix this MongoQueue error, I expect the non-missing branches to be fixed.
 * hatch wants to remove recess from our build
<abentley> sinzui: It appears to be a one-line fix: http://pastebin.ubuntu.com/5755825/
<sinzui> :)
<abentley> sinzui: Could you please review https://code.launchpad.net/~abentley/charmworld/enqueue-broken/+merge/168788 ?
<abentley> sinzui: I've successfully run enque and ingest-queued.
<sinzui> r=me
<abentley> sinzui: I wonder whether we should drain the queues as part of a source code upgrade?
<sinzui> abentley, I think we should.
<sinzui> abentley, do you have time for https://code.launchpad.net/~sinzui/charmworld/enable-migration/+merge/168791
<abentley> sinzui: looking.
<abentley> sinzui: I think production thinks it's already on version 7, so you need to rename version 7 to version 8.
<sinzui> abentley, production is not on 7, it failed to migrate
<abentley> sinzui: Even after you made the 7 migration a no-op?  Are you sure?
<sinzui> oh!
<sinzui> abentley, you are correct.
 * sinzui copies and renames
<gary_poster> benji hijacked you into call tomorrow of potential juju core task.  let me know if you'd rather have a tooth pulled :-)
<benji> heh
<benji> what time?
<gary_poster> benji 1500 utc.  on your calendar
 * benji takes out his UTC to Faux-Eastern slide rule.
<gary_poster> heh, 11 for me benji
<rick_h__> hatch: can you give me a ping when you get a sec?
<rick_h__> I need someone to second my build issue isn't just me
<hatch> what's up? just eating lunch
<rick_h__> hatch: so can you check out trunk, make clean-all && make
<rick_h__> and try to run the tests?
<rick_h__> in a browser, test-server, not test-debug
<hatch> sure,
<sinzui> abentley, I push my update: https://code.launchpad.net/~sinzui/charmworld/enable-migration/+merge/168791
<abentley> sinzui: Also rename TestMigration007 to TestMigration008 and you're good to land.
<sinzui> doh
<hatch> rick_h__: broke broke
<rick_h__> hatch: k
<rick_h__> hatch: now do me another favor
<hatch> browser_charm_view "does not blow up when the scores from the api is null"
<hatch> does blow up :)
<rick_h__> hatch: yea, I've fixed that but now hitting other stuff :(
<rick_h__> cascade fail
<hatch> it takes forever to run the build when kerbal is also running haha
<abentley> sinzui: I am in the middle of a forced ingest, and things seem to be returning to normal.
<sinzui> abentley, rock!
<Makyo> Swapping routers again :S
<hatch> wow throttle control makes a huge difference in how much bang for your buck you get in kerbal
<rick_h__> hatch: I'm trying to manually fire an event in a test but having trouble. any hints for me? http://paste.mitechie.com/show/964/
<abentley> sinzui: ingest complete.
<hatch> rick_h__: I"m assuming that tabview is the proper object?
<hatch> you don't need to pass in a new eventfacade you can just fire it with an object
<hatch> {newVal: 'Quality'}
<rick_h__> hatch: yes, verified tab == view.tabview
<rick_h__> hatch: the trouble is that it's not getting into the 'after' callback at all
<hatch> oh
<hatch> that's because selection is an attribute?
<rick_h__> ah! gotcha
<rick_h__> hatch: still fail, anything else jump out at you from this then? http://paste.mitechie.com/show/965/
<hatch> checking
<rick_h__> hatch: nvm, hmm the selection isn't the link but the tab content. So I'm mixing it up a bit
<hatch> alrighty
<rick_h__> it should still fire the event though, the attr was changed but it didn't take. ugh this is annoying
<hatch> the event will only fire if the value is different
<rick_h__> yea, so now the wonder why it didn't take
<hatch> try just setting it to 'foo'
<hatch> so it's totally different
<sinzui> thank you very much abentley
<hatch> rick_h__: oh
<abentley> sinzui: You're welcome.
<hatch> rick_h__: selection is readonly
<rick_h__> hatch: bah!
<rick_h__> screw it, bye bye test. 
<rick_h__> this is so much fun, now that routing is fixed to not ignore QS and anchor tags the tests won't pass
<rick_h__> frankban was doomed from the start
<rick_h__> it's alive!
<hatch> :)
<rick_h__> guess what standup I'll be on tomorrow :P
<hatch> what was the issue?
<rick_h__> so now that routing is un-borked any test that adds a #hash to the url causes everyone else's json loads to fail since they're relative
<hatch> ahhh
<hatch> yeah that's not good testing to modify the url at all
<rick_h__> yea, so I removed my one test that did it because it had so since I can't simulate the underlying selectionChange event to clean up the test
<rick_h__> all the stuff in test_service_view that does it I just moved to the last tests to run period
<hatch> well you could change the selection :)
<rick_h__> someone that knows how that works will have to adjust the test to not mess withthe url
<rick_h__> hatch: right, but I can't seem to force it other than clicking on the link...that triggers the url change
<hatch> tabview.selectChild()
<rick_h__> oh wtf...now test errors in test-debug when it didn't fail on this anyway
<hatch> I think selectChild does
<hatch> I could be wrong though
<rick_h__> selectChild is about the widget child I believe
<hatch> ahhh
<hatch> ok ok
<hatch> ugh this recess thing is irritating me
<rick_h__> what was recess? the css minification stuff?
 * rick_h__ had to look it up before and is refusing to again :P
<hatch> it's a css linter that fails on bootstrap code
<rick_h__> ah, that's right
<hatch> (made by twitter)
<hatch> there is absolutely nothing wrong with the style in question
<hatch> and it doesn't give me a way to turn it off for a block of css
<hatch> as far as I can find in the source or docs
<rick_h__> oh crap, ran the wrong command *sigh*
<rick_h__> what a freaking day
<hatch> haha
<hatch> anyone available for a review? https://codereview.appspot.com/10197043/
<rick_h__> hatch: jcsackett can I get an emergency call please?
<hatch> it's a simple css restructuring one
<hatch> sure
<hatch> loading guichat
<rick_h__> guichat please
<gary_poster> Makyo do you have time for quick review of hatch's https://codereview.appspot.com/10197043/ ?
<gary_poster> it's fast :-)
<Makyo> Sure.
<gary_poster> ty
<hatch> thanks
<jcsackett> ccccccbljtrvvbvviujehkvllefelhuffjgggvjnvgve
<gary_poster> uh-huh, sure
<hatch> jcsackett: lol
<hatch> again
<gary_poster> sorry, my comment was ambiguous but intended to be directed at Jon
<hatch> gary_poster: sorry I committed the config :/
<gary_poster> hatch np, easy to fix :-)
<rick_h__> jcsackett: https://code.launchpad.net/~rharding/juju-gui/trailing-slash-1189973/+merge/168803
<jcsackett> man...i'm building a little cover that hooks onto the yubikey.
<hatch> lol
<gary_poster> rick_h__, jcsackett fwiw the only big usability issue I have in charm browser right now is the lack of a back arrow sort of thing, or at least the ability to get back to the home page.  true back arrow doesn't work reliably either.  Is any of that slated to come up soon?
<gary_poster> (navigating to categories are example of true back arrow not working)
<jcsackett> gary_poster: i don't know that any of that is scheduled; back arrows are sporadically included in design, and i think true back not working is a new bug.
<gary_poster> jcsackett, ok thanks, I will raise to UX then
<jcsackett> true back arrow not working sounds like something we can bring up in standup tomorrow as a high priority, but i'll have more info for you post-standup.
<gary_poster> cool thanks jcsackett 
<jcsackett> sinzui: ^
<jcsackett> i've added a card to the next lane. probably worth more discussion tomorrow, since everyone is EoDing or close to doing so now.
<rick_h__> gary_poster: so back button shuold work. The 'return to home' is a known UX issue that luca's had on their plate for a while tbh
<gary_poster> rick_h__, ack, thanks.  I'll send something casual to him then
<sinzui> gary_poster, rick_h__ speaks the truth
<gary_poster> :-)
<gary_poster> should I file a bug for category back arror thing?
<gary_poster> arrow
<rick_h__> gary_poster: did you see ^^ about tests and CI?
<sinzui> I would love a 'return to home' feature
<rick_h__> gary_poster: I'll come on the stand up tomorrow, but the browser based tests are a bit fubar with the routing changes recently I think. I've landed a branch that should help, but does dirty tricks
<gary_poster> rick_h__, I saw that there was a crazy slash thing that broke things somehow, and frankban fixed it in charm and you fixed it gui.  I haven't seen test runs since
<gary_poster> ok thanks rick_h__, sounds good (or sending an email would be good, but verbal is faster)
<rick_h__> sorry, EOD and juggling sick toddler. 
<gary_poster> hope toddler feels better soon
<gary_poster> for the sake of all involved :-)
<rick_h__> gary_poster: ok, I guess there's some question as to the right way to fix permanently, but wanted to toss a heads up. phantomjs let things pass that FF/chrome would not have
<gary_poster> ah-hah :-/
<rick_h__> so just a general heads up that the / wasn't even close to CI's big issue, but hopefully it's better now than this morning
<gary_poster> CI's big issue being the diff between phantom and FF/chrome?
<gary_poster> or something you will discuss tomorrow?
<rick_h__> gary_poster: yea, it was either hitting that or about to once the other issue was unblocked
<rick_h__> I had hatch verify that tsets failed for him in trunk big time before my branch
<gary_poster> ugh, wow
<gary_poster> ok
<hatch> yeah....gota love FE development :)
<gary_poster> well, on the bright side tarmac will make that better
<gary_poster> where's matsubara, anyway! :-)
<Makyo> Dogwalkination.  Back in a bit.
<gary_poster> k
<gary_poster> uh, hatch?  I think something fell over: http://uistage.jujucharms.com/
<hatch> i'd say
<hatch> that's what happens when bootstrap isn't on the page
<hatch> now why isn't it...
<gary_poster> I'm trying make
<gary_poster> on uistage
<hatch> hmm it is loaded
<hatch> the bootstrap styles aren't being replied
<hatch> applied
<gary_poster> hatch, do you want me to do anthing on uistage
<hatch> yeah...
<hatch> the bootstrap and juju-bootstrap files are returning the index file
<gary_poster> well, this  is on prod
<gary_poster> so it should be compressed, yeah?
<hatch> can't compress it, recess throws an error
<hatch> and there is no way to tell it to ignore the line
<hatch> oh but I suppose we could merge them
<hatch> ok going to go do that - I explicitly removed them from the merge so that they would stand out
<hatch> but that's not working :)
<gary_poster> Lesson: reviewers should always qa :-/
<gary_poster> on prod
<hatch> should be fixed soon
<gary_poster> thanks
<hatch> sorry :*)
<gary_poster> s'ok, was my fault too
<hatch> Yeah!! that's right it was!
<hatch> lol
<gary_poster> :-)
<hatch> proposing
<hatch> gary_poster: https://codereview.appspot.com/10197043 mind a qa please :)
<gary_poster> hatch :-) on it
<gary_poster> LGTM ship it!
<hatch> submitting!
<gary_poster> hatch, go ahead and submit, but then, in charm browser, was change log broken in charms before you landed the bootstrap change?
<gary_poster> will try reverting to check
<gary_poster> right now it takes up all vertical space even when collapsed
<gary_poster> which pushes tabs down down down way down
<hatch> gary_poster: yeah it's because it's using the .hidden class which sets visibility to hidden
<gary_poster> hatch, ok, you on it?  
<hatch> I'm not sure what other side effects there are with that change though
<gary_poster> hatch, so...this is a bootstrap thing though, right?
<hatch> stylesheet.less line 115
<hatch> nope
<gary_poster> oh
<gary_poster> so not introduced by you hatch?
<hatch> i'll revert trunk to see but I am almost certain no
<hatch> will report in 5
<gary_poster> ok thanks
<hatch> ahh
<hatch> yes it was caused by me
<gary_poster> easy to fix?
<hatch> one liner yup
<hatch> will fix and submit
<gary_poster> cool thanks
<hatch> gary_poster: can you make on uistage plz?
<gary_poster> on it
<gary_poster> lib/views/stylesheet.less is not working in Makefile to trigger css rebuild. did make clean && make.
<gary_poster> fixed.  thanks hatch!
<hatch> awesome
<hatch> our css is a mess
<hatch> hopfully with huw we can now clean it up
<gary_poster> yup
<hatch> ok now to merge ben and my branch
<hatch> Makyo: thought you might like this song http://www.youtube.com/watch?v=4ZYm0anhvLg it sounds better if you change the quality to 1080HD :)
<hatch> yuidoc linter is throwing an error but I have no idea what it means....who added this?
<hatch> looks like I got it
<hatch> arg
<hatch> gary_poster: https://codereview.appspot.com/10019050/ the databinding branch
#juju-gui 2013-06-12
<hatch> rick_h__: you around?
<rick_h__> hatch: heh, yea
<rick_h__> hatch: but barely
<hatch> heh sucker
<hatch> :P
<hatch> https://codereview.appspot.com/10019050/diff/1/app/views/databinding.js I don't know what you meant with the top comment
<rick_h__> loading
<rick_h__> hatch: just spacing around the {
<rick_h__> you have { return
<rick_h__> but );}
<rick_h__> the asymetrical-ness of it got my attention :P
<hatch> ohh - yeah ben wrote that, that might be his style, I've noticed it a few places :)
<rick_h__> hatch: so yea, let me know if we need to do a hangout or something on my comments tomorrow
<rick_h__> hatch: I wasn't clear on some parts and maybe I'm not getting it. 
<hatch> sure - this is still under development so it's very likely some will change
<hatch> it's gone through a few iterations already
<rick_h__> cool, yea. After going through it maybe I just need to get told to hold on and wait and put my LGTM on there for now
<rick_h__> but figured I'd do my best to bring 'fresh' eyes to it
<rick_h__> since I'm not in all the meetings/discussions and just approaching it as a dude that can read some JS
<rick_h__> and with that it's way past my bedtime after a LUG meeting night. Check ya tomorrow
<hatch> :) have a good night thx for the review
<gary_poster> If anyone is interested in leading the charge of switching us from canonistack to ec2, please do.  this is not cool, and will be untenable with tarmac
<rick_h__> gary_poster: so I'm looking at hatch's branch he put up and some of the things I comment on are "yea, that's not ideal and will get worked on more in the future". So should reviews kind of be "well, point this out" and let it ride as things shake out then?
<rick_h__> gary_poster: I don't want to hold up things, but wonder which things to say "yea this should be tweaked" vs 'ok, pinky promise this won't hang around forever'
<gary_poster> rick_h__, for this effort, behind a feature flag, yes.  For instance, it would be fine to say "please mark this with an XXX and a bug.  I'm fine with it landing behind the feature flag, but not with it staying."  Other variants/ideas welcome.  I want them to feel like they can merge incremental work to trunk for larger efforts like this.
<gary_poster> larger exploratory efforts
<rick_h__> gary_poster: k, cool.
<gary_poster> thanks
<gary_poster> rick_h__, I can't get the serviceInspector flag to work, can you?
<rick_h__> gary_poster: not tried, sec
<gary_poster> k
<rick_h__> gary_poster: yea, works here
<gary_poster> huh
<gary_poster> ok
<rick_h__> http://127.0.0.1:8888/sidebar/:flags:/serviceInspector/ is the final url after I added a service and confirmed it
<gary_poster> rick_h__, using sandbox?
<rick_h__> gary_poster: yea
<gary_poster> k trying again
<gary_poster> still not
<gary_poster> will try make clean?
<gary_poster> nope
<rick_h__> gary_poster: yea, not sure. I just grabbed trunk, updated it, colo-branches, merged jeff's branch and make devel and it worked
<gary_poster> sounds exactly the same
<gary_poster> rick_h__, and you add a service (I added mysql), confirm (ugh I keep forgetting to ask someone to fix the cancel button css), and then click on the service, click view, and...get taken to the old page
<gary_poster> no, you get the right thing at the end :-)
<gary_poster> http://localhost:8888/sidebar/:flags:/serviceInspector/ is my final url..
<rick_h__> gary_poster: right, I added ceph, top of my sidebar list. Added it, confirmed, clicked on it and hit 'view' and got this floating panel up
<gary_poster> :-/ ok thanks rick_h__ .  bztr status shows all the right stuff too.
<gary_poster> I have call soon so will return to that later
<frankban> gary_poster: it seems that suddenly ie is not able to click on DOM elements without disconnecting the webdriver :-/
<gary_poster> frankban, :-( so not canonistack?
<gary_poster> frankban, on call will check in with you after
<frankban> gary_poster: I see that behavior in ec2. thanks
<benji> Has anyone else seen this?  I'm getting this error on a full test run, but not when the set of tests is run on its own: http://paste.ubuntu.com/5758147/
<rick_h__> benji: is this updated trunk?
<benji> rick_h__: it is on a branch, which hasn't been updated recently
<rick_h__> benji: I fixed up some failing tests in trunk yesterday in browsers that didn't show in phantomjs. This looks like phantomjs though
<benji> this is Chromium
<rick_h__> benji: ah, check out trunk. With CI not going we had things land that broke tests in FF/chrome but ran in phantomjs so they landed
<benji> thanks, I'll take a look
<benji> rick_h__: no change in test; thanks for the hint though
<rick_h__> benji: :( ok nvm then. Not seen that directly then. 
<benji> I really wish we had a decent test runner; doing things like running a subset of the tests is painful.
<rick_h__> benji: +1
<rick_h__> benji: so looking at your error again I see it's in browser_charm_view and with us removing the browser subapp feature flag I wonder if this is a side effect? I thought I had gotten all that squared away with yesterday's tests updates though. 
<rick_h__> benji: so let me know if it doesn't clear up and I can help look at hte branch and peek at it
<benji> maybe, but the tests pass on trunk and that set of tests pass when run independently; I suspect dirty global state
<benji> thanks
<rick_h__> benji: completely possible. There's still fun with that these days. since the browser subapp isn't FF'd it's always in every App() instance and causes side effects sometimes. We've been working on minimizing that. 
<gary_poster> frankban, hi.  off call.
<gary_poster> so...yuck.
<gary_poster> frankban, so that means IE CI is completely broken until this is fixed, which is completely out of our control?  Maybe we simply need to move it to the end of the CI list?  That would mean that we would still see the effects
<gary_poster> and tests would still fail :-(
<gary_poster> but FF and chrome would still have a chance to run
<gary_poster> and hopefully pass
<sinzui> orangesquad: Do you have a few minutes to review https://code.launchpad.net/~sinzui/charmworld/charm-model-updates/+merge/168812
<frankban> gary_poster: I might have a workaround, testing now. Anyway, I was not able to find a specific ie driver bug, only a number of people complaining about weird behaviors in ie click(), more or less similar to this one
<gary_poster> huh
<gary_poster> ok thanks frankban 
<abentley> sinzui: sure.
<frankban> gary_poster: I also saw that the tests output in Jenkins is confusing, maybe stderr is printed before stdout? I am thinking about printing our messages (e.g. restarting API backend, etc..) to stderr
<gary_poster> huh
<gary_poster> probably fine
<frankban> ok, I'll try that
<hatch> morning
<gary_poster> morning hatch.  trying to finish up the rollup review.  can't get the demo to work, but rick did, so it's PEBKAC somehow
<hatch> hmm that's concerning
<hatch> any errors?
<rick_h__> hatch: morning, thanks for some of the updates. I noticed that some of them in https://codereview.appspot.com/10019050/diff/1/app/views/service.js didn't have a reply so not sure if we're set or want to chat more?
<gary_poster> no errors hatch
<hatch> rick_h__: oh right sorry - I didn't comment on those other ones because that whole block is a prototype and will change a lot
<rick_h__> hatch: gotcha, ok. 
<rick_h__> sinzui: invite on the way
<hatch> gary_poster: hmm that's very odd I'll have to step through it to see if there is somewhere where something could happen
 * gary_poster liked that code
<gary_poster> hatch will ping in a few and we can try it out together in hangout?
<abentley> sinzui: r=me with some suggestions in the comment.
<hatch> gary_poster: sure can you give me 10? morning routine around here is still going on so it's a little hectic :)
<gary_poster> hatch, np, still reviewing :-)
<hatch> looking at the comments
<gary_poster> hatch, I have another call in 29.  Will try to get your demo working again for a few.  if you are up for hangout lemme know, but no pressure.
<hatch> sure just replying to the last comment
<gary_poster> cool
<hatch> ok done that
<hatch> guichat?
<gary_poster> ok
<gary_poster> thx
<hatch> rick_h__: I'll add XXX's to the codebase
<rick_h__> hatch: yea cool. I know it's all balancing between moving forward with ideas vs making sure we don't leave things that could be better behind for later people to fix up/complain about :)
<rick_h__> hatch: so take my feedback with a grain of salt and all that. 
<rick_h__> this is kind of cool, missed this annoucement. https://plus.google.com/+GoogleChromeDevelopers/posts/644qQuBKZeL
<rick_h__> editing files directly from the chrome dev tools should be kind of neat, especially with css/etc
<frankban> guihelp: could you please review https://codereview.appspot.com/10049046 ? This is my attempt to fix CI failures, thanks
<rick_h__> http://opensas.wordpress.com/2013/06/12/live-hot-code-reloading-with-chromium-browser-on-linux/ for chromium notes on enabling it
<Makyo> frankban, taking a look.
<frankban> thanks
<adeuring> orangesquad: could one of you have a look at this MP: https://code.launchpad.net/~adeuring/charmworld/1163544-es-error-monkey-search/+merge/168971 ?
 * sinzui looks
<hatch> rick_h__: definitely thanks for the review - normally I would want everything perfect before landing but in this case it's still a WIP
<hatch> :)
<hatch> rick_h__: there is also a regression when deploying services from the browser - the ghost config doesn't show all the options
<hatch> can you get to this this morning?
<rick_h__> hatch: looking
<sinzui> adeuring, I replied with a question? I don't see the unbalanced quote case tested
<rick_h__> hatch: did that get fixed before? /me doesn't remember what ever happened with that.
<adeuring> sinzui: it is tested like the other characters: 'foo %s bar' % '"'
<hatch> rick_h__: yeah I was sure someone fixed it before
<rick_h__> hatch: k, filing a new bug/card. Will see.
<sinzui> ah!
<hatch> it must have gotten overridden in a merge or something
<sinzui> sorry adeuring
<adeuring> sinzui: no problem ;)
<sinzui> adeuring, r=m with my suggestion to represent the the special chars as all-caps constants.
<adeuring> sinzui: thanks
<rick_h__> hatch: files as #1190265
<_mup_> Bug #1190265: adding a service does not load all config <charmbrowser> <juju-gui:Triaged> <https://launchpad.net/bugs/1190265>
<hatch> thanks rick_h__
<hatch> I have a spare (rather powerful) server hanging around doing nothing, I wonder if I can instlal openstack on it and run local juju instances
<hatch> can I run openstack on a single machine?
<rick_h__> hatch: I think they're working on that but it's not there yet
<rick_h__> hatch: but don't quote me on it
<hatch> I don't really want to spend to much time on it, so if I can't `apt-get install openstack` I'm not really interested :)
<gary_poster> benji oops!
<gary_poster> coming back :-)
<benji> control-shift-T
<sinzui> adeuring, did you manually merge? I am looking at jenkins
<adeuring> sinzui: no, I did not.
<sinzui> okay, thank you. We are going to wait and see if tarmac does its job
<gary_poster> jujugui call in 6
<gary_poster> kanban now
<gary_poster> frankban gave you a second LGTM
<frankban> gary_poster: thanks, submitting
<gary_poster> jujugui call in 1
<gary_poster> benji starting without you (teknico got your message)
<sinzui> adeuring, I QAed your fix while verifying tarmac was up
<adeuring> sinzui: thank you
<rick_h__> orangesquad, hatch, Makyo anyone up for some review of a nice small one please? https://codereview.appspot.com/10227045
<rick_h__> orangesquad: heads up that kanban is acting nuts. I'm taking the bug #1190063 card next but kanban won't shot it atm. 
<_mup_> Bug #1190063: going into a category and then hitting back does not re-render the editorial <charmbrowser> <juju-gui:In Progress by rharding> <https://launchpad.net/bugs/1190063>
<rick_h__>  /shot/show
<Makyo> rick_h__, looking.
<rick_h__> Makyo: ty
<hatch> rick_h__: looking
 * gary_poster feels embarrassed he didn't know about bitnami
<hatch> rick_h__: done, just one q
<hatch> I didn't know about it either :)
<hatch> looks pretty cool on the surface
<gary_poster> and like the primary closed source and pre-existing competitor to juju
<hatch> yeah although it appears to be taking a different approach
<hatch> to the same problem
<gary_poster> yeah
<hatch> once we have bundles done I think our approach is better
<gary_poster> stacks in particular
<hatch> er yeah, stacks
<hatch> I get the two mixed up :)
<gary_poster> :-) yeah
 * gary_poster runs to lunch for a bit...
<rick_h__> hatch: replied
<rick_h__> hatch: basically hasStateChanged is a question, not mutating
<hatch> gotcha thx
<teknico> hatch: fixed tests in devel and debug, still the same "not a constructor" error in prod :-/ lp:~teknico/juju-gui/add-cookies-usage-banner
<hatch> but it works in devel?
<teknico> yes, under "make test-server" and " make debug"
<hatch> ok looking
<teknico> thanks
<rick_h__> so something isn't making it into the combined js file :/
<teknico> yeah
<hatch> teknico: ahh it's missing from the bin/merge-files ln89
<teknico> hatch: ooh, right
<hatch> try that out - if that doesn't work then I'll dig further
<teknico> too many moving parts :-P
<hatch> ""jenkins is back to normal"" yay!
<hatch> yeah our build process is too complex
<teknico> hatch: now it doesn't find Y.Cookie?!?
<hatch> looking
<teknico> hatch: does it have to be added to the list on line 74?
<teknico> yeah, that did it :-P
<hatch> :/ I really don't understand that
<teknico> me neither :-/
<hatch> those scripts should not need to be manually added into the reqs
<hatch> what if you add 'cookies' into app.js as a requires
<hatch> (curious to see if that works)
<teknico> hatch: do you mean "cookie", and without adding the line "reqs.push('cookie');" to merge-files?
<hatch> yeah
<hatch> sorry
<teknico> hatch: yep, it works
<teknico> which one is better?
<hatch> the latter (in app.js) imho
<teknico> deal
<hatch> that means that our parsing script is not working properly
<gary_poster> I think those problems are because the YUI loader isn't designed to be used this way
<gary_poster> Maybe we could find some nice improvements if we reviewed it though
<gary_poster> frankban, thank you very much for Jenkins fix! yay!
<frankban> \o/
<teknico> lint fixes, merge from trunk, test again, propose, yadda yadda :-)
<teknico> hatch: proposed again, how about another review? :-) https://codereview.appspot.com/9967044
<teknico> thanks for all the fish, btw :-)
<hatch> sure give me a few minutes and I can get on it
<teknico> no hurry
<hatch> jcastro: is the idea to replace askubuntu with discourse?
<jcastro> no
<jcastro> AU is for q+a
<jcastro> discourse is for watercooling
<jcastro> "How do I configure Juju to do foo?" goes on AU. "I like Juju let's talk about it." goes on Discourse
<jcastro> theoretically
<hatch> ahh gotcha - I wonder if the two can be integrated at all
<hatch> link from one to the other for example
<jcastro> yeah I have some ideas
<jcastro> for oneboxing and making it more seamless, as I'm sure there will/is confusion
<hatch> discourse confuses me to start with but I'm sure I'll get used to it :)
<jcastro> it's a fresh start. Brave new world.
<jcastro> burning of ships.
<hatch> I don't like new things...
 * hatch goes back to sit on his porch yelling at the neighbour kids
<hatch> lol
<jcastro> <rick_h> Even I like it, and I hate everything
<hatch> jk
<hatch> hahahaha
<teknico> burning of RAM and CPU, more than anything...
<rick_h__> jcastro: :P
<hatch> btw rick_h__ what's with all the underscores?
<rick_h__> hatch: must have been reconnecting at some point
<jcastro> rick_h: we should finish up your blog post
<rick_h> jcastro: yea, good call. I'll poke at it tonight at CHC
<hatch> teknico: review done with a few comments (LGTM'd)
<sinzui> Does anyone on orangesquad have time to review https://code.launchpad.net/~sinzui/charmworld/charm-model-fixes-views/+merge/168175
<sinzui> I think kanban is on read-only mode
<rick_h> sinzui: yea, it's borked. Yellow had issues on their call today as well
<gary_poster> I don't even get that far
<sinzui> yeah, I get loading errors sometimes
<rick_h> ah, loads but as soon as I *do* something it undoes it and yells at me
<hatch> gary_poster: so is your only issue with trello that it doesn't do wip limits?
<rick_h> hatch: and you've not written lp-trello to replace lp-kanban
 * rick_h does use trello for outside of work stuff though heh
<hatch> do we need lp-kanban? It was down for the longest time and I didn't even notice :)
<gary_poster> hatch, no, I also want greater flexibility in arranging the swim lanes than trello provides.  
<hatch> rick_h: yeah so do I haha
<gary_poster> lp2kanban is less important as we use fewer LP bugs
<hatch> gary_poster: ahh ok - I'm a +0 in the matter anyways but just curious
<gary_poster> hatch I looked up WIP limits in trello earlier.  whatzizname the big blogger who is part of the company that makes it says that wip should be social anyway.  It is social, but don't agree that this means that visually highlighting WIP is unimportant
<gary_poster> somebody has a chrome plugin I think
<hatch> https://chrome.google.com/webstore/detail/kanban-wip-for-trello/oekefjibcnongmmmmkdiofgeppfkmdii
<hatch> that one? :)
<hatch> yeah - that response sounds like an arrogant one
<gary_poster> probably.  didn't look closely
<hatch> "we aren't going to add a counter.....because I don't believe in it....yeah that's it"
<hatch> https://trello.com/card/wip-limits/50e0afbecc2e335d2e000da3/23
<hatch> according to this it's done?
<gary_poster> hatch stared at that but couldn't make much sense of it.  Looked for wip before.  https://trello.com/board/trello-development/4d5ea62fd76aa1136000000c is trello dev board
<hatch> yeah the comments are....out there... but it was in the 'done' category heh
<sinzui> hatch, I agree with gary_poster that WIP limits are fundamental to the intent of kanban. I am glad to see a rival to leankanban though
<gary_poster> but of what board, hatch?  does that actually have anything to do with trello dev?  I don't see any wip-style config in "list actions"
<hatch> on the trello-development board under 'Live' there is (5/31) possible WIP limit?
<hatch> I agree, I don't see it in the config either
<hatch> oh that's probably a date
<hatch> haha
<hatch> gary_poster: I think here is the feed you were taking about https://twitter.com/spolsky/status/306719908245417984
<gary_poster> hatch, yup, that's it.
<gary_poster> hatch, where's that "possible WIP limit" thing?  don't see it in https://trello.com/board/trello-development/4d5ea62fd76aa1136000000c
<hatch> yeah I don't either
<hatch> I'm not sure what that other thing was from then
<gary_poster> ah ok
<hatch> I'm going to take off for lunch, bbl
<jcsackett> sinzui: got a moment to chat?
<sinzui> I do
<sinzui> jcsackett, ^
<jcsackett> cool.
<jcsackett> ccccccbljtrvgrbjhhhbvihigrddbeglevvfgnevhttk
<gary_poster> OTOH, if leankit doesn't get their act together, I will be tempted to find other alternatives :-/
<benji> debug prints (that raise exceptions) left in tests make Benji cry
<jcastro> gary_poster: I am in the process of rating a bunch of charms
<gary_poster> yay! thanks jcastro :-)
<gary_poster> jujugui, orangesquad, ding dong the witch is dead, or something.  leankit appears to be back.
<sinzui> \o/
<Makyo> Undead..?
<gary_poster> :-)
<sinzui> thank you for your diligence gary_poster
<rick_h> jcastro: comming on your MP, I think there's a wire crossed
<gary_poster> lol, I can reload web pages with the best of 'em
<jcastro> rick_h: what do you mean?
<rick_h> sorry, jcsackett ^^ not jcastro 
<rick_h> jcastro: you carry on, rate away kthx :)(
<gary_poster> heh
<jcastro> I like how you guys made you guys not landing ratings now blocking on us instead of you guys
<jcastro> well done sir.
 * rick_h goes to look for anything else we can shove off on someone else
<jcsackett> rick_h: my understanding was we used icon internally, and had the link used by clients of the API.
<gary_poster> jcastro, :-P :-)
<rick_h> jcsackett: I thought icon was gone. it's no longer an attribute
<rick_h> or was going away, abentley can you verify? 
 * benji read that as "shave off of"
<rick_h> jcsackett: I thought sinzui was removing it from the model because it had no use
<jcsackett> rick_h: could be; i missed that, if that's the case.
<rick_h> benji: I've got my merkur safety razor ready and willing
<sinzui> icon is gone from staging charm data and will be gone from production data in the next deploy
<benji> :)
<rick_h> jcsackett: ^^
<jcsackett> sinzui: i'm running off a fresh ingest, so icon is still being brought in somewhere.
<sinzui> jcsackett, migration 7 cleanup devs and staging, migration 8 cleans up production
<jcsackett> and by fresh, i mean: i had no data before running this ingest this morning.
 * gary_poster crosses fingers and toes on Makyo's behalf
<Makyo> Crossing everything, over here.  Fingers, toes, the dogs' tails..
<jcastro> rick_h: hey something to think about wrt. bundles
<jcastro> so I want to rate "logstash"
<jcastro> but it's a series of like 4 charms
<jcastro> maybe we should think about rating the entire thing as a whole
<jcastro> I think people will want a general view of quality of the entire service, not just the indexer, the webfront end, etc.
<rick_h> jcastro: hmm, not sure what's up with bundles at this point. I know we talked about forming a 'meta charm' format and getting it into the store like others and you'd just rat the 'meta charm' 
<jcastro> oh ok
<rick_h> jcastro: so it would work just like it does now for you if that goes through, but I don't think we're doing that any more so not sure what the story is
<jcastro> well whatever we call them
<rick_h> jcastro: maybe gary_poster or sinzui  can better fill you in what checklist to toss that onto
<sinzui> jcsackett, charmworld/charmworld/ingest only knows two things about icons. 1 ICON_FILENAME which can be removed (it is unused) and a test verifying icon is not in the charm data
<gary_poster> jcastro I'll be sending an email out to juju-dev about bundles in the next few days
<gary_poster> jcastro, I'll include that use case
<benji> the beginings of Go sandbox branch is up for review: https://codereview.appspot.com/10235045
<gary_poster> and you can follow on as you think makes sense.  Does that sound good?
<jcastro> gary_poster: excellent, I will chime in as necessary
<gary_poster> thanks jcastro 
<jcastro> I hadn't thought about it until I started rating
<jcastro> then it's like, who cares about the logstash-indexer charm outside of it's stack
<gary_poster> yeah
<rick_h> jcastro: yea, I know we talked about it from a charmworld POV in oakland
<benji> I should have taken a vacation day tomorrow.  I'm getting a new mixing board and I can't wait to play with it.
<rick_h> benji: woot, what did you get?
<gary_poster> heh
<benji> Behringer x32 (http://www.youtube.com/watch?v=A5v-JnAvipw)
<rick_h> whoa, nice
<Makyo> I have a Behringer Xenyx 1222.  Love it :)
<Makyo> Boy howdy is that one nice, though, benji 
<rick_h> yea, I was thinking like a little 8input board but that's crazy
<abentley> jcsackett: by "icon is still being brought in", you mean the base64-encoded contents of the icon?  That should be impossible.  We don't even import base64 anymore.
<benji> I have 22 inputs but only a 16 channel board now, so the 40 inputs of that guy will be very nice to have; plus I get compression and a nice parametric EQ on each channel and 8 FX slots, so I can stop using over half of the stuff in my rack
<jcsackett> abentley: i mean right now, i can do img src="data+xml/svg,{$charm ... }" to get an image in a template. 
<jcsackett> abentley: but it doesn't matter. i'll take it on faith that i've got something unusual going on and i'm going to change the branch.
<abentley> jcsackett: You can look at the contents of the charm by accessing /charms/precise/wordpress/json .  If there's a member named "icon" in there, I don't believe that was fresh ingest.
<abentley> at least not with trunk r245 or a descendant.
<hatch> benji: cool mixer :) I just got back from lunch....bought a new kiteboard lol
<hatch> went out for lunch, forgot about lunch, bought a kiteboard....how does that work?
<benji> distracting hobbies are distracting
<gary_poster> heh
<hatch> haha yup
<hatch> r u in a band?
<gary_poster> you've heard of zz top?
<gary_poster> he has a beard wig
<hatch> lol
<hatch> it's called 'benji top' and it's a cover band?
<benji> heh
<benji> hatch: I am the tech director (and primary mixer) for my church: 2 guitarists, keys, piano, drummer, and five vocalists
<hatch> coolio!
<benji> (the base player will be back in the fall; mission trips, the bane of church music programs ;P)
<hatch> haha
<benji> [wow, misspelling "bass" is a new low, even for me]
<gary_poster> ba-dum-dum
<hatch> it's alright I figured he wasn't the guy everyone stood on :P
<gary_poster> "bass," "new low," get it?  get it?
<hatch> lol!
<hatch> *rimshot*
<gary_poster> :-)
<benji> heh
<hatch> interesting email on ubuntu tech about git
<hatch> and I mean't canonical tech
<gary_poster> benji lgtm with questions
<hatch> :)
 * benji looks at questions.
<hatch> oo I think I have finished this panel removal
<hatch> annnnnd I spoke to soon
<hatch> who needs tests anyways!
<hatch> these tests are driving me bonkers
<rick_h> jcsackett: ping, just a double check. Did you make sure that hasIcon isn't dumped in the API and might cause front end issues?
<hatch> does anyone know off the top of their head what causes the ghost services to be removed on cancel?
<hatch> oh hmm
<hatch> with my new iteration on canceling a deployment the ghost sticks around until the next delta
<gary_poster> hatch, I think I knew at one point.  Makyo should know.
<Makyo> One sec.
<hatch> thanks
<Makyo> hatch, When the charm configuration panel is removed.
<hatch> ohhh I forgot to fire 'update'
<Makyo> Okay.
<hatch> thanks :)
<hatch> I just needed that 'click' I guess heh
<hatch> Makyo: the ghost placement is a little odd though
<hatch> once deployed it bounces to the proper place though
<hatch> known issue?
<Makyo> hatch, That was a content-free statement :)  What's 'odd' mean?
<sinzui> orangesquad I have another branch of for review. This one is a drive-by fix: https://code.launchpad.net/~sinzui/charmworld/complete-promulgated-queries/+merge/169052
<hatch> it's about 6" to the right of where it 'bounces' to after deploying
<Makyo> hatch, new as of yesterday *shrug*  Was fine when I landed my branch.
<gary_poster> I've seen it for awhile actually
<gary_poster> didn't bother me too much
<abentley> sinzui: looking
<gary_poster> happy to have a bug, but bigger fish to fry atm
<Makyo> ??
<Makyo> Will look.  Maybe it's quick.
<hatch> Makyo: it does it on uistage
<Makyo> That code hasn't changed since it was written, really.
<hatch> when deploying from the charm browser
<hatch> yeah it may have done this forever, I just noticed it today though :)
<Makyo> Works locally, will check uistage.
<Makyo> Works on uistage, too.
<Makyo> So...I don't know?
<hatch> lol that's odd...so it doesn't jump to a different place than the ghost on deploy?
<gary_poster> Makyo, to be clear, it works but it jumps briefly.  So, you make a ghost, you drag it somewhere, and then you press confirm.  After that, placement changes briefly but it bounces back
<gary_poster> to where you had dragged it
<gary_poster> hatch or I can demo
<gary_poster> but also, I didn't raise it because it was not a high priority for me.  basic behavior is good enough for now
<abentley> sinzui: r=me.  Maybe we don't need to worry about searchTasks, if as you say, being subscribed is enough.
<Makyo> Oh, that's from turning on transitions.
<Makyo> gary_poster, ^^^
<gary_poster> ah!
<gary_poster> ok
<Makyo> The x/y coords aren't set until it gets the annotations.
<Makyo> And when they're set, it jumps.
<gary_poster> Can we manually set x/y, maybe?
<gary_poster> before annotations really come in?
<gary_poster> so, manually set annotations?
<Makyo> Maybe?  I mean, the code is the same code that moves the service if another client drags it, so that you have a visual cue to see that something moved.
<Makyo> I can poke around at it sometime, I'm sure.  We have the pending flag, so we can have conditional code.
<gary_poster> right cool.  also my idea was that we already know what the annotations are supposed to be
<gary_poster> Makyo, somewhat relatedly, at some point if you have any thoughts on this, we will need multiple ghosts simultaneously soon, for bundles as well as other use cases.  If you had any deep thoughts on that I'd love to pick your brain.  If not np.  We will figure it out
<hatch> sorry I wasn't bringing this up to have it fixed now... :) it was more of a 'didjaknow?' :D
<Makyo> gary_poster, Sure, I'll think about it, though I'm sure it'll be trivial; they're stored in the DB with the same data that will be stored server-side, so multiple services can have pending flags.
<sinzui> thank you abentley
<Makyo> hatch, no worries, I was just missing the drag part.
<Makyo> If you start with one service, it looks okay :D
<gary_poster> cool Makyo thx
<hatch> removal of the right charm search panel is proposing now
<gary_poster> thx hatch, lemme know when ready and I'll jump on it.  Would be great to have for Huw.
<hatch> I've noticed that proposing/submitting seems to be taking longer than usual
<hatch> I wonder if our tests are hitting that critial mass where my mini is just not fast enough :)
<Makyo> It's the new usual, hatch \o/
<hatch> haha ok so it's not just me then?
<Makyo> I dunno, I was mostly joking.  last propose was in core-land.
<hatch> oh I bet those take forever
<Makyo> They're reasonably fast, since they don't depend on tests running, but the tests do take quite a while, and lock up my ocmputer in the process.
<hatch> I bet they use a multi threaded test system don't they? :)
<hatch> gary_poster: https://codereview.appspot.com/10241043/  qa please :)
<Makyo> Hah, I have no idea.  I joked before that testing was "go build ./... && go test ./... && go get a cup of coffee and maybe a snack"
<hatch> -1000ln diff!! w000t
<hatch> haha
<hatch> Makyo: if you wouldn't mind I'll need another review of the above link :)
<Makyo> hatch, sure.
<hatch> thank yas
<hatch> rick_h: I see you are working on the configuration issue - It's past your EOD now?
<gary_poster> oh
<gary_poster> the jump to place does not work with improv at all anymore
<gary_poster> at least with large
<gary_poster> hatch, placement of the service is broken in improv in your branch
<gary_poster> IOW, 
<hatch> hmm
<gary_poster> if you start with improv (I used large fwiw)
<gary_poster> and then deploy a charm
<hatch> ok let me see
<gary_poster> the ghost will go one place
<gary_poster> but the new confirmed service will go someplace else
<gary_poster> (works properly in trunk)
<gary_poster> notifications work well
<gary_poster> so that's the only qa issue I found
<gary_poster> (I'm a bit worried about the configuration issue in this context; I hope this does not confuse rick's issue too much)
<gary_poster> Hopefully it will be easy enough to work out
<hatch> yeah...
<hatch> hmm this placement thing is a little odd
<hatch> I'm not sure how my removal of code could have messed that up
<hatch> will look into it
<gary_poster> thank you
<hatch> benji: review done see comments :)
<Makyo> hatch, The notifications icon is now white with white text.  Is that a known thing?
<hatch> Makyo: yeah it's only like that when there are no alerts
<gary_poster> hatch, that's only if there are no errors, right?
<hatch> yup
<gary_poster> :-)
<hatch> it turns red when there are
<Makyo> hatch, alright.  Doesn't show connection status anymore?
<hatch> I didn't know that it did...
<Makyo> Blue was connected, yellow disconnected.
<gary_poster> ah yes
<hatch> yes....that's a bug
<hatch> nice catch!
<gary_poster> that is a regression, but not from this branch
<gary_poster> but also
<hatch> inadvertent issue caused by my bootstrap changes
<hatch> I can fix that
<gary_poster> the next branch in this path is to re-style the top
<gary_poster> but cool, if it is easy that is great
<hatch> yeah it should be
<Makyo> Yeah, it can go wherever!  Just a useful indication sometimes.
<hatch> honestly I had no idea haha
<hatch> I've never seen it yellow
<Makyo> LGTM with Gary's positioning item, though.
<hatch> hmm It acts the same on uistage for me (positioning)
<hatch> it bounces to the 'middle' then back again after deploy
<Makyo> uistage isn't running improv though, right?
<hatch> oh I thought it was
<gary_poster> hatch, I would try trunk with large.  I can probably dupe with uistage with enough instructions
<gary_poster> it used to be running improv
<gary_poster> I disabled it because of the script kiddies
<gary_poster> yesterday, I think
<hatch> I get identical 'bouncing' but because the deltas are longer on improv it takes longer
<hatch> sure this is caused by my branch?
<hatch> will try on trunk
<gary_poster> hatch, I don't think you see what I'm trying to show.  one sec, getting different instructions
<hatch> ok sorry :)
<gary_poster> np!  was not clear
<hatch> oh I don't get the bouncyness on trunk
<hatch> it deploys right to where I drop the ghost
<hatch> umm
<hatch> ok something is right messed up :/
<gary_poster> yeah
<hatch> the layout is different on trunk than on my branch
<hatch> with identical rapi setup
<gary_poster> on trunk it is different but also messed up :-(
<gary_poster> ah ok
<gary_poster> that's not good
<gary_poster> I have a different problem
<gary_poster> ah!  but it is not in your branch.  some kind of horrible race condition
 * Makyo dogwalks quickly.
<hatch> guichat?
<hatch> I'm a little confused here
<gary_poster> let me see if it happens using the old charm adder
<hatch> I don't understand how the layouts could be different
<gary_poster> ok
<gary_poster> nope still hosed in old adder
<gary_poster> Makyo, when you get back, I see a problem in trunk (can dupe on uistage) that you can dupe by adding four services in a row
<Makyo> gary_poster, just got back.
<gary_poster> cool thanks
<gary_poster> the first three go to the right place
<gary_poster> the fourth ghost never appears
<gary_poster> and then when you confirm it goes in the center of the canvas rather than where the ghost would have gone
<Makyo> Can't reproduce in hatch's current branch.  Which browser and any speed requirements?
<Makyo> Got it on uistage.
<hatch> in trunk on sandbox, can't reproduce the 4th ghost issue now....
<gary_poster> I did have race conditiony experiences in here somewhere
<hatch> ahah
<hatch> Uncaught TypeError: Cannot read property 'index' of undefined d3.v2.min.js:4
<hatch> when it doesn't show....that error is in the console
<gary_poster> ah ok
<hatch> traceback https://gist.github.com/hatched/0bdebc1a94512730c54e
<Makyo> I hate having minimized code in development.
<Makyo> Minified, whatever.
<hatch> gary_poster: when I use my branch on rapi-large I get an error in the rapi console logs on reploying the new wordpress
<hatch> CharmStateNotFound
<gary_poster> hatch...no idea.  sure this is not trunk?
<hatch> then when I delete I get another error
<hatch> 2013-06-12 16:03:54,828 juju.rapi.delta:ERROR An error occurred 'result'
<hatch> I'll compare with trunk
<hatch> oh I get the same failurs in trunk they just don't make the same representation in the UI
<Makyo> d3.geom.hull fails when vertices form a line.
<gary_poster> heh
<gary_poster> silly geometry
<gary_poster> hey hazmat, could you make ~juju-gui a member of https://launchpad.net/~charming-devs, and whatever else is necessary so that I can be an editor and approver of https://blueprints.launchpad.net/charmworld/+spec/s-cloud-jujucharms-site-authors-api please?
<Makyo> gary_poster, hatch http://pastebin.ubuntu.com/5759656/ fixes it
<hatch> the 4th ghost bug?
<Makyo> yeah
<gary_poster> cool Makyo thanks.  hatch, can you fit that in?
<hatch> certainly thanks
<gary_poster> cool thank you
<hatch> I still can't figure out what my other bug is caused by
<hatch> wht is 'defaultSeries' ?
<hatch> what*
<hatch> this.charmPanel.setDefaultSeries(this.env.get('defaultSeries'));
<Makyo> hatch, ie: precise, quantal, etc.
<hatch> ohh
<hatch> ok nope that's not it
<rick_h> hatch: yes, past my EOD. Will try to get a fix in tomorrow. 
<gary_poster> how goes it hatch
<hatch> oh I gave up
<hatch> I'll be back at it later on
<gary_poster> :-) ok
<hatch> fresh mind, fresh eyes :)
<gary_poster> hey huwshimi.  I might have a chance to talk briefly later, or might not
<gary_poster> hatch has a branch that rips out the right hand side
<gary_poster> it has one qa issue that he is trying to resolve
<huwshimi> gary_poster: Ah great
<gary_poster> but it would not affect the header
<huwshimi> gary_poster: Should I base my branch off that then?
<gary_poster> so you could in theory use it as a base for your work if you had time and you thought that would work
<gary_poster> yeah
<gary_poster> finding
<huwshimi> cheers
<gary_poster> huwshimi, lp:~hatch/juju-gui/remove-charmsearch
<gary_poster> we discovered two qa issues
<gary_poster> first, on trunk and in the branch, if you add four services in a row and don't drag them, the fourth ghost doesn't show up.  http://pastebin.ubuntu.com/5759656/ from Matt fixes, and Jeff will include it in his branch
<gary_poster> second, when you add a new ghost and confirm, the real service position is wrong
<gary_poster> until the annotation comes back
<gary_poster> that's what he is going to fix later
<gary_poster> otherwise, the alerts are still as broken as before
<gary_poster> but the unneeded stuff on the right is gone
<gary_poster> ok, need to go read books to children
<gary_poster> maybe back later :-)
<huwshimi> gary_poster: OK thanks. What do you mean by alerts are still broken?
<huwshimi> (I'm guessing you mean that you can't open the alerts panel...)
#juju-gui 2013-06-13
<hatch> it opens
<hatch> you can't open it?
<hatch> ^ huwshimi
<huwshimi> hatch: I had to add a charm first
<hatch> huwshimi: so how's it going? Are you wroking now? I have no idea what your hours are :)
<huwshimi> hatch: Hey, yeah I start my day at the end of yours (well, depending on what hours you work :))
<hatch> i'm UTC-6
<huwshimi> hatch: I'm UTC+10
<hatch> 16h difference?
<hatch> crazy
<gary_poster> matsubara, hey!  how goes tarmac?
<gary_poster> hey hazmat, could you make ~juju-gui a member of https://launchpad.net/~charming-devs, and/or whatever else is necessary so that I can be an editor and approver of https://blueprints.launchpad.net/charmworld/+spec/s-cloud-jujucharms-site-authors-api (and add my own blueprints there) please?
<matsubara> gary_poster, hey I think it's ready to switch on. I'd like to make a test run. do you have a mp ready so I can test?
<gary_poster> matsubara, awesome!  lemme see
<gary_poster> matsubara, benji's mp looks like it will be ready Real Soon Now
<gary_poster> yeah benji?
 * benji frantically hits ctrl-c
<benji> I was submitting it.
<gary_poster> lol
<gary_poster> matsubara, https://code.launchpad.net/~benji/juju-gui/go-sandbox/+merge/169036 if benji was able to stop the submission in time :-)
<benji> https://code.launchpad.net/~benji/juju-gui/go-sandbox/+merge/169036
<benji> yep
<gary_poster> cool!
<benji> thank goodness for long test runs
<matsubara> haha
<gary_poster> thanks benji.  have at it with our thanks matsubara :-)
<benji> The best thing I've read this week: "On FedEx vehicle for delivery" 
<gary_poster> heh
<gary_poster> I never looked at that video
<gary_poster> I'll go look
<gary_poster> heh, wow
<gary_poster> very nice benji :-)
<benji> I'm very excited. :)
<rick_h> jcsackett: ping, got a sec?
<gary_poster> morning sinzui.  If you have some time in the next hour to talk blueprints, I'd like to run some things past you and ask some questions
<sinzui> gary_poster, I do after 10.
<gary_poster> sinzui, you mean 10 minutes or 10AM?
<sinzui> 10AM
<gary_poster> sinzui, ack.  I'm booked after 10 until the afternoon, and was hoping to catch up with you in the morning.  If I have a free moment I'll check with you, and otherwise will try you in the afternoon.  thanks
<matsubara> gary_poster, benji: that MP is still in needs review and no commit message set
<benji> oh, I guess that's something the new lpsubmit will do; I'll hand-edit the MP now
<gary_poster> thanks benji
<gary_poster> (and yes, it does that)
<benji> matsubara: you should be good to go
<matsubara> benji, looks like it picked the MP while you're still editing the commit message but had changed the status to approved
<matsubara> it's a good sign that tarmac is working heh
<benji> heh
<gary_poster> :-)
<benji> yeah, I guess I should have done that in the other order
<matsubara> I'm re-running it. Tarmac picked it up and should start the jenkins job soon
<teknico> gary_poster: we can move our call up if it helps
<matsubara> gary_poster, benji: voting criteria not met. A member of juju-gui hackers needs to approve the MP (I claimed the review and approved it and am re-running the tests)
<benji> matsubara: I approved it, is self-approval not allowed?
<gary_poster> teknico, thank you, great idea.  maybe in 14?  sinzui, then we'd be able to talk at 10
<matsubara> benji, yes, it's allowed. the thing tarmac complained is that there were no review approvals 
<teknico> gary_poster: deal
<benji> ah
<gary_poster> thanks teknico 
<gary_poster> matsubara, we need >= 0
<matsubara> benji, it needs the reviewer approval and the global status approved
<matsubara> ah ok
<matsubara> I'll change that
<gary_poster> thanks
<gary_poster> otherwise the rietveld workflow doesn't work, unfortunately
<matsubara> gary_poster, well I guess then it's just a matter of disabling the voting plugin from tarmac, right?
<rick_h> gary_poster: I thought abentley's tool would copy the LGTM as 'approved' and would make that work
<matsubara> since once there's a MP on LP, means it's approved from the rietveld side
<gary_poster> matsubara, makes sense.  we might want it later but not now
<matsubara> cool
<abentley> rick_h: No, my tool ignores reitveldt entirely, since all the necessary info is on Launchpad.
<rick_h> abentley: ok, so it doesn't make the LGTM comments copied into LP a "approve" state?
<abentley> rick_h: No.  It's a user script.  You'd have to be an admin to change someone else's vote.
<rick_h> abentley: ah, nvm then. oh well
<matsubara> gary_poster, benji: http://10.189.74.2:8080/view/CE/job/jujugui-merger-trunk/7/console
<gary_poster> rick_h, abentley's script looks at reitveld LGTM and adds that to the commit message
<matsubara> it's running the tests, could you look at the output and see if looks sane?
<gary_poster> matsubara, so far so good!
<rick_h> gary_poster: gotcha, I misunderstood. I thought it would change the type of comment to an approval as well
<benji> it wouldn't be too hard to make it do so.  All rietveld does is look for the string "LGTM"
<gary_poster> benji, per Aaron's comment, the problem there is that the script is running as a user
<abentley> benji: It wouldn't be hard to impersonate someone else on Launchpad and change their vote?
<gary_poster> rt
<benji> ah, foiled by security
<gary_poster> matsubara, where is the merge of benji's branch in there?
<matsubara> gary_poster, take a look at: http://10.189.74.2:8080/view/CE/job/jujugui-merger-trunk/configure I had to change slightly the command so tarmac can work. 
<matsubara> gary_poster, tarmac merges benji's branch on /tmp/tmpOz9IkX/ then the builder machine copies that dir over and runs the tests on top of it.
<matsubara> gary_poster, one thing though, when jenkins run: bin/test-charm --origin $JUJU_BRANCH --charm $JUJU_CHARM, what does the --origin mean in that context?
<abentley> orangesquad: Could you please review https://code.launchpad.net/~abentley/charmworld/no-docs/+merge/169202 ?
<rick_h> abentley: looking
<gary_poster> benji, any chance you could help matsubara on the above?  I need to do some other call-y bits, and I know you knew a previous incarnation of test-charm :-)
<gary_poster> benji, hatch will also know where bodies are buried when he is around
 * benji looks
<matsubara> let me get a diff of the changes, it'll be easier
<benji> matsubara: "origin" is where to get the source code
<matsubara> benji, https://pastebin.canonical.com/92720/
<matsubara> err
<matsubara> clearly pasted the wrong thing
<benji> and I don't have my phone on me to log into that thing anyway
 * benji goes to find his phone.
<matsubara> https://pastebin.canonical.com/92721/
<matsubara> benji, http://pastebin.ubuntu.com/5761464/
<benji> thanks matsubara.  what am I looking at?
<matsubara> benji, so these are the changes to make tarmac work. Tarmac creates a tmp dir with lp:juju-gui + the approved MP branch. The jenkins jobs then copies that tmp dir from tarmac machine and runs the test on top of it. I think what's missing is tarmac to send $JUJU_BRANCH to the job and use that as the --origin
<benji> matsubara: cool; I still don't quite understand what (if anything) you're asking me to do though :)
<sinzui> orangesquad, gary_poster, all the charms are being re-indexed...search has not charms at this time
<sinzui> I expect them to be back in 15 minutes
<abentley> sinzui: Hmm.  Shouldn't work that way.  The new index is supposed to become active after the copy is complete.
<sinzui> abentley, isn't this the stale queue issue with branch_deleted?
<abentley> sinzui: Are we talking about reindexing or ingest?
<sinzui> abentley, ingest really
<abentley> sinzui: Oh, then yes we probably hit the same branch_deleted issue.
<sinzui> I see charms re-appearing now
<sinzui> I see 75% of the charms now
<hatch> morning
<hatch> gary_poster: benji no bodies in CI , it's stable as a rock...
<hatch> bahahaha
<gary_poster> hatch, :-)
 * benji doesn't understand but guesses that is a good thing.
<gary_poster> sinzui, is this something that might need to happen again?
<hatch> gary_poster: last night I fixed the jumping service issue, waiting for Makyo to tell me why it's doing what it's doing (hoping he knows)
<Makyo> Yoooou raaaaaang?
<gary_poster> lol!
<hatch> oh haha, I thought you didn't start for another hour
<gary_poster> hatch, great!  huwshimi has lp:~huwshimi/juju-gui/header-design
<gary_poster> based on your branch
<gary_poster> I've been trying to catch a few minutes to look at it
<Makyo> Nah, 8 my time.
<Makyo> So 2 minutes.  Let me make another coffee.
<sinzui> gary_poster, yes....We think we want to empty the ingest queue after each deploy of code to ensure the ingest/indexing process is knows exactly what it will find in the queue
<hatch> Makyo: oh so we must be on the same tz right now
<gary_poster> sinzui, ah ok.  this strikes me as a significant usability issue if it means that no-one can search for charms from jujucharms.com and the GUI everytime we roll out
<hatch> gary_poster: cool, am I supposed to merge it into my branch?
<sinzui> gary_poster, It dosen't happen every time, but I think the next time we change the definition of charm data, we must ensure there is a mechanism to clear the queue
<gary_poster> hatch, not supposed to.  Would be nice to have it land today.   Separately probably makes sense
<gary_poster> hatch, you or I can try to get it reviewed and landed once your branch is in
<sinzui> gary_poster, I take the loss of search as down-time and we don't ever want to be down more than a few seconds
<hatch> alrighty
 * hatch grabs coffee
<gary_poster> sinzui, k.  you available now for call? can talk about this also then
<sinzui> 5 minutes? I need to find coffee
<gary_poster> cool sinzui 
<gary_poster> benji, hatch, matsubara goal of conversation with matsubara is to review what he has set up with tarmac so we can sanity check it.  Also matsubara had one specific question: 
<gary_poster> matsubara> gary_poster, one thing though, when jenkins run: bin/test-charm --origin $JUJU_BRANCH --charm $JUJU_CHARM, what does the --origin mean in that context?
<hatch> matsubara: gary_poster it's the origin to pull the gui source from
<gary_poster> hatch, so does that mean the branch that is being tested?
<hatch> correct
<gary_poster> I am afraid that the config that matsubara has might still be testing the trunk, rather than the merged branch from tarmac
<gary_poster> so that's what I'd review
<gary_poster> in particular
<hatch> see lib/deploy_charm_for_testing.py:188
<matsubara> gary_poster, hatch, I think I have enough to continue. I'll have to change the jenkins tarmac plugin to send the $JUJU_BRANCH  as well.
<matsubara> while bin/test-charm is being run from trunk + mp's approved branch
<sinzui> gary_poster, ready
<Makyo> Alright, hatch.  What's up?
<gary_poster> cool matsubara thanks
<hatch> Makyo: ok in onCharmDeployClicked in views/charm-panel.js there is a call to env.update_annotations()
<hatch> in that call it updates the gui-x and gui-y which work as planned
<hatch> then in the callback it removes the x and y attributes from the ghost
<hatch> it's this removal which is causing the jumping in my branch and not in trunk
<hatch> it appears to have no side effect if I comment those out
<hatch> so the issue is that when, in the following lines, it setAttrs() there is no x, y so it places it in the middle
<Makyo> Alright, I see what you mean.  I think that's left over from there potentially not being annotations to set, which changed when we added the branch for new service placement.
<Makyo> I think those are safe to remove, now.
<hatch> excellent - I really dont know why it breaks in my branch and not in trunk however
<hatch> I just found the sollution, around 1am I called it quits hah
<Makyo> Yeah.  I don't necessarily know why, either, but I don't see a problem with the solution.
<Makyo> Would take some digging.  Worth QAing extra.
<hatch> cool - will work on cleaning up the mess I made of this branch tracking that down then land this
<hatch> thanks for the sanity check
<Makyo> Oh, hey, neat: http://www.google.com/trends/hottrends/visualize?nrow=15&ncol=15
<sinzui> adeuring, Let's consider https://bugs.launchpad.net/charmworld/+bug/1190627 as a part of the feature you are working on. We don't want charms to disappear temporarily. In this case, the unavailable service is our queue because it contains stale data
<_mup_> Bug #1190627: Charms can disappear when code is deployed with a stale queue <deployment> <ingest> <charmworld:Triaged> <https://launchpad.net/bugs/1190627>
<adeuring> sinzui: right
<hatch> Makyo: what am I looking at?
<Makyo> Search trends in real time.
<hatch> ohh - I thought it was Google making fun of Windows 8 tiles
<hatch> lol
<Makyo> Hah :D
<hatch> ohhh Makyo one other thing
<Makyo> Shoot.
<hatch> trunk is broken wrt service layout
<hatch> on rapi large, take note of the layout
<hatch> add a service, wait for it to become 'alive'
<hatch> then refresh
<hatch> your other services will have moved
<hatch> sometimes only a little, sometimes a lot depending on their orientation
<Makyo> hatch, that's by design because default layout doesn't imply annotations have been set, nor does it set them.  They are set when a new service is added, though.
<hatch> ok so if I move all services then that shouldn't happen?
<Makyo> Correct.  In reality, it will likely be one of two cases: the IS case, in which annotations will never be set because the GUI is effectively read-only, and the deploying case, where annotations will always be set because they were deployed from the GUI.  The intermediate case you're dealing with is possible, but the default layout encourages dragging; if we come up with a more intelligent default layout scheme, we can start setting annotati
<Makyo> ons by default.
<abentley> sinzui: pre-imp re: 1176901 ?
<hatch> kewl I see that now, thanks for clearing that up
<sinzui> abentley, in a few minutes, just finishing a meeting
<sinzui> abentley, I am ready
<benji> matsubara: are you still working with my branch or should I land it the old-fashioned way?
<matsubara> benji, sorry, running tarmac again. If it doesn't work this time, I'll re-enable the old jenkins job and you can land in the old way
<benji> cool, thanks
<abentley> sinzui: We could avoid spamming the store in the case of multiple jobs for a charm using rate-limiting.  We could store the last-updated-from-store time, and skip retrieving that data if we used the store too recently.
<hatch> orangesquad: do you already have a bug for a request to https://manage.jujucharms.com/api/2/charm/login when logging out of the GUI ?
<rick_h> hatch: not that I know of. Can you file something with instructions for duplicating?
<hatch> definitely, do the bugs just go on juju-gui? Do I tag it with anything for you guys?
<rick_h> hatch: yes, tag it charmbrowser
<hatch> cando!
<rick_h> hatch: though I'm confused, is this on manage.jujucharms.com?
 * rick_h is confused, what logout did you hit to get an api url?
<hatch> on trunk running rapi
<hatch> clicked the logout button
<rick_h> hatch: k, yea then tag charmbrowser under the juju-gui I guess
<hatch> actually it does it on sandbox as well
<hatch> ok making ticket
<hatch> hey it looks like the tarmac is working
<hatch> matsubara: any way we can get the codereview link in the comment like before?
<benji> nice: "Status: Approved => Merged"
<matsubara> hatch, what do you mean?
<hatch> matsubara: https://code.launchpad.net/~juju-gui/juju-gui/trunk see 728 vs 727
<benji> hatch: right now the commit message is hand-rafted
<hatch> it's not a huge deal, I have just found myself using it before
<benji> or "crafted" even
 * benji invents the new sport of "hand rafting"; very dangerous.
<benji> in other words, I didn't copy that bit into the text box
<hatch> benji: well I think it was inserted into there by something automatically
<hatch> I like having that and the reviewers in there so when something breaks you know who to talk to and any review comments easily at hand
<benji> hatch: lbox submit does it, but since I wasn't using lbox to land the MP, I had to do it
<hatch> ohh ok so it's something we can add back in at a later time
<hatch> ?
<benji> right, I assume lpsubmit will do the same thing
<hatch> rick_h: here you go https://bugs.launchpad.net/juju-gui/+bug/1190653
<_mup_> Bug #1190653: Clicking logout makes request to manage.jujucharms.com <charmbrowser> <juju-gui:Triaged> <https://launchpad.net/bugs/1190653>
<hatch> benji: ahh cool
<rick_h> hatch: thanks, adding to the board
<hatch> it's a pretty odd issue
<gary_poster> jujugui call in 8
<abentley> hatch: you can look up a merge proposal with lp-find-proposal, e.g. bzr lp-find-proposal -r 728:lp:~juju-gui/juju-gui/trunk
<gary_poster> kanban now
<hatch> abentley: lol I can't even remember the proper bzr diff syntax half the time I'll definitely never remember that ;)
<abentley> hatch: If you're in a trunk branch, lp-find-proposal -r 728 will work.
<hatch> oh that I can remember :)
<abentley> hatch: In fact, after you run log, any revno you see will work as long as you don't switch branches.
<hatch> bzr has much saner defaults than git I find but I have no idea why I can't remember the syntax
<gary_poster> jujgui call in 2
<teknico> jujugui ^^ :-)
<gary_poster> heh thanks
<gary_poster> matsubara, is tarmac ready to go for us, then?
<gary_poster> luca__, hey.  any news on google docs form and user form link design?
<luca__> gary_poster: it's in progress, I imagine It'll be finished tomorrow
<gary_poster> great thanks luca__ !
<luca__> gary_poster: no problem :)
<matsubara> gary_poster, nope. it can land stuff but still needs to be modified to send the JUJU_BRANCH
<gary_poster> ok thanks matsubara let us know
<matsubara> gary_poster, I'll re-enable the old job for now and let you know when I can test again
<gary_poster> thanks :-)
<benji> gary_poster: sent to juju-gui-peeps (I hope that is still active)
<gary_poster> it is thanks benji
<hatch> I got it
<hatch> thanks
<hatch> gary_poster: the remove-charmsearch branch is re-proposing now
<gary_poster> hatch, cool.  you need re-review or re-qa
<gary_poster> ?
<hatch> re-review probably isn't necessary but feel free to take a peek at the changes https://codereview.appspot.com/10241043 but I would like a fairly indepth qa if possible :)
<gary_poster> heh
<hatch> Haswell, 16GB ram, SSD mini pc :) http://www.engadget.com/2013/06/12/asus-vivopc-specs/
<rick_h> orangesquad hatch review help please? short/sweet in the end https://codereview.appspot.com/10246044/
<hatch> on it
<hatch> done
<rick_h> hatch: ty much sir
<gary_poster> rick_h, hatch, code looks good.  hatch did you do qa on rick's branch?  if so will lgtm myself
<hatch> gary_poster: not yet,
<gary_poster> k
<hatch> was just about to pull it down
<gary_poster> thanks
<gary_poster> hatch, looks like the panel config scroll is broken again.  also fixed in  rick's branch?
<rick_h> gary_poster: no, actually now that I look on a charm with enough config that's not fixed here
<gary_poster> darn
<gary_poster> can do it separately
<gary_poster> but needs to be done urgently also
<hatch> huw's changes make the ui look awesome - a little...chrome heavy imho but awesome :)
<rick_h> is that something we broke or is that bootstrap related?
<gary_poster> hatch, rick_h one of you look at that?
<gary_poster> rick_h, not you I don't think
<gary_poster> hatch agreed
<rick_h> gary_poster: ah ok. I'm going to look at the logout issue that's us. If hatch can follow up on the config panel that'd be great
<gary_poster> on awesome and a bit chrome heavy
<gary_poster> rick_h, +1 thx
<hatch> gary_poster: I have that fixed in one of my proto branches, so I can dig that fix up in a followup
<gary_poster> yay!
<gary_poster> thanks
<hatch> gary_poster: just qa'd ricks branch and it shows all of the config properties now
<gary_poster> yay!
<hatch> will just test to make sure it saves them
<hatch> heh
<rick_h> hatch: heh, I just have to get your a model, not save it :P
<hatch> the ;tooltips cover the inputs :/
<hatch> oh nm
<hatch> screwup with my browser plugins
<rick_h> hatch: ok yea I'm not seeing that
<gary_poster> hatch your branch is looking great so far--that change even fixed the jumpy bit
<hatch> rick_h: +1 on a QA, gtg :)
<hatch> gary_poster: yeah it's pretty awesome :)
<rick_h> hatch: gary_poster ty much for the reviews. Will hop into the logout next and see if I can't clean up our last little bits of trouble
<gary_poster> great!
<gary_poster> hatch, found another weird issue with logout but not related to your changes
<gary_poster> and not as urgent
<gary_poster> at least with sandbox if you create services, log out, and log in
<gary_poster> then services don't show
<gary_poster> but exist (you can't add services with same name)
<hatch> oh yeah I thought ben and I fixed that
<hatch> in fact, I know we did
<hatch> *regression*
<gary_poster> hatch, not your problem, so can make a card, but if you have another fix in your bag of tricks then yay
<gary_poster> hatch your branch LGTM in qa and code
<hatch> eggcelent
<teknico> rick_h: I'm working on the card "loadFixture should be able to exclude/ignore hashes when it generates urls"
<teknico> rick_h: I can't reproduce the problem, do you know how to make it show up?
<rick_h> teknico: move the test_service_view.js and test_service_config_view in test/index.html back up into the middle of the test suite
<rick_h> teknico: I moved them to the very end to work around the issue for the moment
<rick_h> teknico: if you still can't dupe let me know and we can hangout and I can shot you what's going on exactly
<teknico> rick_h: thanks, I'll better dupe it by myself, I don't want to be shot ;-)
<rick_h> teknico: the actual error ends up showing up as something about invalid chars or something because it's trying to json parse something it can't. 
<rick_h> bah, /shot/show
<teknico> of course :-)
<hatch> damnit rick_h you submitted at the same time I did and now I have to restart lol
<rick_h> bwuhahaha my computer is faster :-P 
<hatch> lol
<hatch> I'm just glad that it was smart enough to reject the merge instead of just forcing it haha
<hatch> that would have been a mess
<rick_h> how much conflict could there have been?
<hatch> well it would have just been missing code without any reasoning as to why
<hatch> I worked on a project that used some custom svn workflow that you would have to notify everyone you were committing so you didn't do that
<teknico> rick_h: weird, if I place those two tests right before test_model_controller.js, then I have an error in the latter
<hatch> that was irritating
<teknico> rick_h: where were they placed exactly?
<rick_h> teknico: hmm, don't recall where they were. I think just alphabetically
<gary_poster> jcsackett, gave you second LGTM on showIcon, with trivial/ignorable suggestion
<rick_h> teknico: https://code.launchpad.net/~rharding/juju-gui/trailing-slash-1189973/+merge/168803
<teknico> rick_h: right
<hatch> ugh mosquito bite on my foot....the worst!
<hatch> alllright merged
<teknico> rick_h: ok, got it, thanks
<rick_h> teknico: yay! ...well not really 
<teknico> :-)
<hatch> gary_poster: so huw's branch looks great, but the UX for the right panel does not match at all heh
<hatch> gary_poster: oh, and when I add services/log out/in  on sandbox, the services stay there on the (new) trunk
<benji> I expect you're on a call, gary_poster.  If so, say nothing for 60 seconds.  GO!
<gary_poster> benji boo
<benji> heh
<benji> gary_poster: so, either this card was very easy or I misunderstood; guichat?
<gary_poster> hatch: (A) I know.  if you want to try a quick CSS to the old inspector you are welcome, but otherwise oh well, it's incremental, and I think we can have the new inspector no later than end of next week
<gary_poster> (B) great!
<gary_poster> dunno what I saw then
<gary_poster> benji, ok joining
<benji> hatch: hi, I'm trying to recall/understand the motivation behind the "Propose download-cache style solution for our node files using existing machinery" card we created during last Friday's meeting.
<benji> hatch: I think you were one of the progenitors of it so I wanted to check with you about what problem(s) you were hoping would be addressed.
<hatch> benji: well there are two things 1) npm can and does go down causing work on new branches to stop and 2) making 100 http requests takes a lot longer than if we could just cache/extract a single file
<benji> hatch: will you try something for me?  apply this diff http://paste.ubuntu.com/5762093/ and do a "make clean-all" and then a "make" and you should get no HTTP requests 
<gary_poster> hatch, the jenkins failure is real and reasonable: the tests use the old load panel
<rick_h> benji: that originally started with me there. 
<gary_poster> if this were tarmac, your branch would have been kicked out. :-P so...looking at that for a sec...
<benji> rick_h: maybe you will test it out for me too then :)
<rick_h> benji: yep, peeking at the diff as well :)
<benji> don't blink or you'll miss it
<rick_h> yea, I see that
<hatch> gary_poster: ok so that's a python test failure? Sorry I didn't even think of looking in the selenium tests
<gary_poster> hatch no apologies needed.  we are supposed to have tarmac for this
<gary_poster> hatch, yeah, so we need to rewrite that deploy function.  are you up for that, or would you prefer to call "Python!" and I'll ask benji to switch and/or pair with you?
<hatch> this is deploy on 109 of test_charm_running.py?
<hatch> ahh yes this needs to point to the charmbrowser now
<gary_poster> 112 for me but yes (me does another pull)
<gary_poster> still 112 for me <shrug> :-)
<hatch> I 'think' I can do this
<gary_poster> :-) cool
<hatch> is ther a way I can test it locally?
<gary_poster> if you change your mind call for help
<gary_poster> yes
<gary_poster> hatch, open your hymnal to docs/continuous-integration.rst and read with me...as I try to remember the details.
<rick_h> lol, read that as "open your hy-yaml" and went wtf?
<gary_poster> lol
<hatch> I don't even know what a hymnal is
<hatch> to google!
<hatch> ohh
 * rick_h is rolling on the floor
<hatch> hym-nal
<hatch> now I get it
<hatch> :)
<gary_poster> lol
<gary_poster> ...so anyway...
<hatch> haha
<hatch> doesn't look like the CI docs contain instructions on running selenium locally
<gary_poster> hatch, look for the section that begins here
<gary_poster> Combining NO_DESTROY and APP_URL could help while debugging CI tests, and it
<gary_poster> allows for running the suite multiple times using the same Juju environment.
<gary_poster> A typical workflow follows::
<hatch> ohh yeah that part
<hatch> but I still need EC2 for that
<gary_poster> mm
<hatch> I know about doing THAT much ;)
<hatch> I assumed frankban didn't hammer on EC2 when fixing things and ran it locally somehow
<gary_poster> well, one other thing to check, one sec
<hatch> I could have been assuming incorrectly
<gary_poster> hatch, yeah ec2.  fwiw, http://irclogs.ubuntu.com/2013/06/11/%23juju-gui.html and look for "I suggest configuring the juju-gui-testing env with the ec2 provider"
<hatch> yup already have that setup
<hatch> ok to ec2 it is!
<gary_poster> k
<gary_poster> :-)
<hatch> sorry for the confusion
<gary_poster> I'm sorry for the confusion about the confusion.  Can we have a third?
<hatch> haha
<hatch>     def deploy(self, charm_name): is `self` a special param? all calls are simply self.deploy('appflower') which is the charm_name
<benji> hatch: yep, the object itself is added as the first argument in any method calls
<gary_poster> hatch, self == js this.  in python it is exlicit
<gary_poster> you could call in kumquat too.  not advised.
<hatch> not sure if typo was 'elicit' or 'explicit' ;)
<gary_poster> explicit :-)
<hatch> got it thanks
<gary_poster> hatch, have trivial css suggestion for right hand side.  will pastebin in a sec
<hatch> already done
<gary_poster> re huw's branch
<gary_poster> hatch ok cool nm then :-)
<hatch> haha well I 'll see yours too
<gary_poster> heh, ok
<hatch> I will have a feeling our changes will be similar :)
 * gary_poster agrees
 * hatch not sure if like python or think stupid
<hatch> it's actually pretty easy to read :)
<gary_poster> heh
<gary_poster> @charm-panel-configure-color: #404040;
<gary_poster> @charm-panel-configure-title-color: #FFFFFF;
<gary_poster> @charm-panel-configure-name-color: #FFFFFF;
<gary_poster> hatch ^^
<hatch> oo we actually did it differently!
<gary_poster> lol
<gary_poster> choose whichever you prefer hatch
<hatch> yeah I'll throw these in after I finish this ci error
<hatch> probably end up combining
<gary_poster> k
<hatch> I use indentation to make prototyping code stand out....that technique does NOT work in python
<hatch> heh
<rick_h> hatch: lol, use comments
<rick_h> """ PROTOTYPE HERE """ and make that a macro :P
<hatch> and 'remove all semicolons on save'
<hatch> lol!!
<rick_h> yea, that one gets me all the time these days
<rick_h> orangesquad and hatch review request please? Small one to fix the last bug before I can get back to working on related charms! https://codereview.appspot.com/10253049
<rick_h> stop finding bugs now :P
 * sinzui looks
<hatch> on it
<sinzui> rick_h, you have my LGTM
<rick_h> sinzui: ty much
 * benji takes a late lunch while screaming "it's here!  it's here!"
<hatch> haha
<hatch> rick_h: donezos
<gary_poster> lol
 * rick_h wonders if benji's internet is about to get yanked out of the wall
<hatch> then tommorow he says "sorry I coudln't work, no internet"
<hatch> any pythonites want to look at this before I fire up EC2? https://gist.github.com/hatched/f2f5ba90519d126c8328
<hatch> just want to make sure it's syntax is correct
 * gary_poster looks
<gary_poster> hatch, charm_panel_loaded is called repeatedly.  is the click there really what you want?
<hatch> oh that's what the wait_for does
<gary_poster> I think you want to click outside of that function, and then wait for (whatever it is) to show up
<hatch> then no
<hatch> yes
<hatch> thanks
<gary_poster> sure
<gary_poster> silly Python niggle: only one space after return on line 10
<gary_poster> hatch, you may need two wait_fors
<gary_poster> one waits for the charm_token
<gary_poster> then you click
<hatch> yeah rewriting that method now
<gary_poster> then the other wait_fors the add_button, and you click
<gary_poster> iok
<gary_poster> ok
<gary_poster> hatch line 19, charm_panel is not defined
<gary_poster> may want to wait_for that too, dunno
<gary_poster> hatch otherwise looks good
<hatch> aww darn the wait_for function doesn't look like it'll accept extra params
<gary_poster> doesn't need to
<hatch> sok I'll just make extra methods
<gary_poster> if you are defining functions as you go then you are writing closures
<gary_poster> so previous vars are available
<hatch> gary_poster:  updated gist https://gist.github.com/hatched/f2f5ba90519d126c8328
 * gary_poster looks
<gary_poster> hatch, trivial but lines 19, 23 and 27 should ideally be < 80 chars.  I suggest a newline after the open paren.  Otherwise good
<hatch> oh yeah woops, I just did that to make it easier to follow for my needing curly bracket js eyes :)
<hatch> ok running, see how this goes
<hatch> is it meta to be writing python in sublime ....that's written in python
<gary_poster> if it is, it's old hat meta. :-) lisp in emacs has us beat by decades
<hatch> haha
<hatch> the new macbook air gets 12:51 battery life....wow!!  http://www.engadget.com/2013/06/13/macbook-air-review
<benji> hatch: did you have a chance to try that diff?
<hatch> sorry I haven't
<hatch> won't that only help with make clean-all ?
<hatch> so won't keep the cache cross branches
<benji> hatch: npm keeps a cache in ~/.npm.  That cache is always used, the new setting just says not to try to see if there is a newer version of the cached file available
<benji> so we save time by not making lots of (not very wise) HTTP requests but we don't save any time installing packages (each new branch will have to install them)
<hatch> ahhhh ok, then in that case I have always missunderstood that cache
<hatch> hah woops
 * hatch fail
<hatch> ok trying that diff
<hatch> benji: muuuuuch better
<hatch> wish people would update their pacakges for the new npm though
<hatch> benji: we should also include with that a way to update the cache
<benji> hatch: "npm cache clean" will kill them all
<benji> or you could just run "npm install" if you wanted to check to see if a new version of a file is available
<benji> but really, that should never happen; uploading a new archive for version X of a library is evil
<hatch> yeah true true
<hatch> well while my new ci tests run I'm going to grab some lunch
 * benji plays while he waits.
<hatch> hmm I can't seem to get the tests to pass
<hatch> all of the selenium tests fail with an error BadStatusLine: ''
<hatch> has anyone seen that before?
<hatch> all selenium tests fail with that error
<hatch> but I can't see how my changes caused it
<gary_poster> BadStatusLine IME is usually indicative of insanity around you hatch, yeah.  It blame it on canonistack I think.  THis is on ec2, though?
<hatch> yeah EC2
<hatch> should I not be able to run the selenium tests by running test_charm_running.py from the source dir on the charm?
<hatch> it's saying selenium doesn't exist
<hatch> I suppose that makes sense
<hatch> will fire off another run maybe that was a glitch
<gary_poster> hatch, if you are waiting on something or other, +1 on releasing frustration by just getting Huw's branch out there for reviews :-P  I can also try to dupe what you are doing if you like, though I need to go soon
<hatch> ahh yes I can do that
<hatch> yeah no point in wasting your time. If I get that error again I will need some help however
<hatch> so will wait and see
<gary_poster> ok understood
<gary_poster> hazmat, hi.  you around?  if so, could you give me privs in charmworld so I can do blueprint work there, please?
<hatch> man ec2 feels slower than it used to be
<benji> hmm: "Failed to start mocha: Init timeout"
<hatch> yeahok the TestAuthentication tests are failing on my branch
<hatch> I must be doing something wrong, I don't see how they could fail from my changes
<hatch> benji: ming taking a peek http://bazaar.launchpad.net/~hatch/juju-gui/remove-charmsearch/revision/728
<hatch> is there anything wrong with that ?
 * benji becomes Ming the Merciless and looks.
<benji> hatch: the indentation goes wonky on line 126
<benji> oh, wait!  it doesn't 
<benji> it's just functions being defined inside a method
<hatch> I'm allowed to indent after the paren like that right?
<hatch> 128, 132, 138
<benji> yep
<benji> hatch: it looks good to me (other than the extra newline on line 124 :)  one newline is enough inside a function
<hatch> 124 isn't in a function
<hatch> at least it's not supposed to be
<hatch> does that mean that 127 is too?
<hatch> 127 should be in deploy()
<gary_poster> hatch, your whitespace is fine functionally.  124 is inside the deploy method, as is 127.  one newline is enough inside a function or method.
<gary_poster> so you can delete one of lines 124 and 125
<gary_poster> hatch, once things are working on ec2, and it sounds like they are now, you can change your tests and rerun them, at least, yeah?
<hatch> ohh I see what you're saying
<hatch> nope the TestAuthentication tests ERROR
<gary_poster> but other tests pass right hatch?
<hatch> the deploy tests fail with the badstatusline error
<gary_poster> so you can do the trick to make things go faster from the doc
<gary_poster> without restarting ec2
<hatch> the testauthentication tests fail by just sitting there for ....5min each?
<hatch> I'm going to guess that it's the same error that gets involved with the process_path() method
<hatch> ARG now I can't propose the huw branch + changes because of the stupid json error in phantom
<hatch> there is little more frustrating than build tool failures impeding productivity
<gary_poster> what is the json error in phantom hatch?
<hatch>  TypeError: JSON.stringify cannot serialize cyclic structures.
<gary_poster> huh, have not seen
<hatch> and the branch which broke it...has nothing to do with json
<hatch> s/branch/commit
<hatch> FINALLY found the cause
<hatch> Victory!
<gary_poster> yay!
<hatch> ok now to blog this...
<gary_poster> that's for the phantom thing?
<hatch> if you see (above error) look for console logs of complex objects
<hatch> or instances
<gary_poster> I think we ought to land Huw's branch immediately.  I'll give it the fastest LGTM ever, and you already blessed it.
<gary_poster> I mean, assuming you killed the wabbit. :-)
<hatch> that thing is dead
<gary_poster> yay :-)
<hatch> it's proposing now *crosses fingers*
<hatch> oh I fixed the height issue too
<gary_poster> great!
<hatch> but it's kind of a kludge
<hatch> I didn't fix the cause, just put a bandaid on it
<hatch> :)
<gary_poster> heh
<gary_poster> ok
<hatch> oh and I ended up using your css changes plus mine :)
<gary_poster> if you want to give me the branch with the CI issue, I can try to look at it
<gary_poster> maybe
<gary_poster> or I can at least pass it to Nicola for him to look at in the morning
<gary_poster> :-)
<gary_poster> heh ok cool hatch
<hatch> https://code.launchpad.net/~hatch/juju-gui/remove-charmsearch
<gary_poster> on it
<gary_poster> oh merged already lol
<hatch> the original is merged
<gary_poster> oh right
<hatch> not the selenium changes
<hatch> huw's branch plus my changes https://codereview.appspot.com/10241046
<gary_poster> I will qa :-) then approve
<hatch> great - let me know what you think of the right panel styles
<gary_poster> hatch you included your incremental work on the test_charm_running.  conflicts. not sure what you want to do.  Probably not making it worse? :-)
<hatch> where?
<gary_poster> oh, um. good question.  how did I get this?  not in your MP....
<gary_poster> oh nm. I merged the wrong branch.  On irc you said remove-charmsearch but you meant header-design
<hatch> umm sorry remove-charmsearch has the CI work
<hatch> header-design has the header and right panel styles
<gary_poster> hey huwshimi! thanks for changes.  hatch had a crazy day trying to get everything to land (sorry hatch) but it is about to land :-)
<huwshimi> gary_poster: Great!
<huwshimi> hatch: Hope I didn't cause you too much trouble
<gary_poster> hatch, LGTM
<hatch> I wish it was you so I could blame someone ;)
<gary_poster> good changes hatch
<hatch> gary_poster: thanks
<huwshimi> hatch: :)
<hatch> gary_poster: I have....finally...created a wordpress account :)
<gary_poster> hatch, lol
<hatch> gary_poster: so is it ok that I land this branch? Considering I kind of reviewed it too?
<gary_poster> hatch, yes :-)
<hatch> she's goin!
<hatch> huwshimi: i'll ping when this is all submitted for you to pull
<huwshimi> hatch: Cheers.
<gary_poster> hatch, should I send an email to Nicola asking him to look at the CI issue, or do you want to give it a bit more of a try and then send him the email when/if you stop?
<hatch> I'd like to keep at it but I don't think I'll get anywhere
<gary_poster> ack
<hatch> I'm pretty much at an impass with my limited python knoweldge
<gary_poster> will send email
<gary_poster> np
<gary_poster> thank you@!
<hatch> I hope at least my deploy method points him in the right direction :)
<hatch> huwshimi: she is ready to go
<huwshimi> hatch: Great, thanks!
<gary_poster> thanks hatch, huwshimi.  g'night
<hatch> night
<hatch> o
<huwshimi> gary_poster: Thanks, talk to you next week
<hatch> oh yeah, it's tomorrow there
#juju-gui 2013-06-14
<hazmat> gary_poster, done
<matsubara> gary_poster, hi there!
<gary_poster> hey matsubara :-)
<gary_poster> thanks hazmat :-)
<matsubara> gary_poster, do you have a MP that I can test the tarmac setup?
<gary_poster> mm
<gary_poster> looking
<gary_poster> teknico, hi.  you around, and do you have an MP for the CI test failures?
<gary_poster> matsubara, to add to the fun, some tests were failing last night :-P :-)
<teknico> gary_poster: I sent you what I had via email
<gary_poster> teknico, ok looking
<matsubara> gary_poster, yeah, I saw that. that's why I waited to check with you first. once there's a MP available I can run tarmac manually to check it will do the right thing this time
<gary_poster> matsubara, do you want a stub MP that can't land because tests will fail?
<matsubara> gary_poster, could be. if you're sure the tests will fail, then it should be ok
<gary_poster> teknico, before I start investigating myself, was there a reason you chose to delete the tests other than expedience?
<gary_poster> matsubara, ok one sec.  I'll make a doc fix of some sort and put it up.
<matsubara> thansk gary_poster 
<teknico> gary_poster: no, just that I did not know right away how to fix them to use the charm browser instead
<gary_poster> teknico, did you look at Jeff's branch?
<teknico> gary_poster: I did
<gary_poster> were there problems in that approach, or do you think I should pursue it?
<teknico> gary_poster: what approach? that branch is merged, it removes the charm panel for deployment
<teknico> gary_poster: I'm missing something here
<gary_poster> teknico, no, Jeff had changes in a newer version of that branch that looked like they should have fixed the problem.  Go to branch and click on most recent revision https://code.launchpad.net/~hatch/juju-gui/remove-charmsearch
<teknico> gary_poster: oh wow, that was unexpected :-)
<gary_poster> ok, teknico.  I can see how my email was not clear enough.  sorry about that.  I'll take over from here.
<teknico> gary_poster: yes, the changes in that revision seem reasonable
<gary_poster> cool
<teknico> gary_poster: do you have time for a quick hangout?
<gary_poster> teknico, in 20?
<teknico> gary_poster: sure, thanks
<gary_poster> teknico, fighting lbox etc.  almost, will ping
<teknico> gary_poster: ok
<rick_h> gary_poster: teknico let me know if there's anything we can do to help as well. Haven't peeked at it yet, but maybe help find a good replacement for whatever check was made
<gary_poster> thanks rick_h.  if it's fast for you, you could take a look at http://bazaar.launchpad.net/~hatch/juju-gui/remove-charmsearch/revision/728 and see if it looks right to you
<rick_h> gary_poster: ok, so the plan is load the sidebar, click on a charm, click on the add button and make sure things render at each step?
<gary_poster> rick_h, yeah.\
<gary_poster> rick_h, note that this is supposed to be a utility
<gary_poster> that deploys a charm
<rick_h> gary_poster: k
<gary_poster> we do this for a number of tests
<gary_poster> https://code.launchpad.net/~gary/juju-gui/restanalytics/+merge/169407
<gary_poster> matsubara, ^^
<gary_poster> matsubara, will be fine if it lands :-)
<gary_poster> teknico, guichat?
<gary_poster> ugh I need to restart soon.  chrome is unhappy
<teknico> gary_poster: yep
<rick_h> gary_poster: so yea, the approach looks good. I'd make sure to add notes in this that it's all depending on manage.jujucharms.com and any issues getting to that will cause the charms to not load. I'd also probably put notes in the specific templates that these values are used for CI and changes must include syncing the CI deploy method. 
<gary_poster> rick_h, good idea. thank you for the review!
<matsubara> gary_poster, sorry, was on a call
<gary_poster> np matsubara 
<gary_poster> teknico, hatch fwiw I will be working with a variant of Jeff's branch that has some changes per Rick.  lp:~gary/juju-gui/fix-charm-panel-tests
<teknico> gary_poster: ack
<matsubara> gary_poster, did you see the error in the MP?
<gary_poster> matsubara, looking
<gary_poster> matsubara, that's canonistack insanity
<gary_poster> matsubara, look at bottom of https://jenkins.qa.ubuntu.com/job/jujugui-merger-trunk/11/console
<gary_poster> matsubara, "RETRY THIS TEST RUN!"
<matsubara> the next one failed too
<matsubara> https://jenkins.qa.ubuntu.com/job/jujugui-merger-trunk/12/console
<gary_poster> matsubara, another canonistack insanity :-(
<matsubara> I'm retrying anyway
<gary_poster> matsubara, tarmac will force us to switch to ec2 or hp cloud :-)
<matsubara> gary_poster, looks like it's going to work this time
<matsubara> http://10.189.74.2:8080/view/CE/job/jujugui-merger-trunk/13/console
<gary_poster> matsubara, yay!  matsubara what is diff between http://10.189.74.2:8080 and https://jenkins.qa.ubuntu.com/ ?  I can log into first, but not second
<matsubara> internal instance and the public instance. they have different log ins (the public one you don't need to log in)
<matsubara> and it's just the published result, all the job config is in the internal one
<gary_poster> ah cool
<hatch> morning
<hatch> gary_poster: ahh so that error was real, it can't get to manage.jujucharms ?
<gary_poster> teknico, hatch on call but Jeff's work seems to almost work.  watching it on browser, the only problem is seeing that thing has deployed
<gary_poster> on call will contonue soon
<gary_poster> matsubara, that error is good!
<gary_poster> matsubara, the only thing is that we don't have proof that the right branch was tested...oh interesting.  We set origin to my branch
<gary_poster> matsubara, that's the only problem I think
<matsubara> yes, that's what I fixed. now the tarmac jenkins plugin sets the juju_branch before the test
<gary_poster> matsubara, because that means we are not testing merge though?
<jcsackett> rick_h: updated the charmworld icons MP. care to take another look? https://code.launchpad.net/~jcsackett/charmworld/reviewed-icons/+merge/169031
<matsubara> what do you mean? tarmac merges your branch into lp:juju-gui, uses that to start bin/test-charm with your branch as the origin
<rick_h> jcsackett: sure thing
<teknico> gary_poster: the error when deploying the charm with juju-core and the options set for CI tests was about staging, not sandbox, sorry: http://pastebin.ubuntu.com/5764804/
<rick_h> abentley: got a sec to chat?
<abentley> rick_h: sure.
<benji> is anyone else seeing test failures on trunk; specifically a timeout in 'application hotkeys "before all" hook'
<gary_poster> I have success locally on unit tests (still on call)
<teknico> benji: I've seen that to sometimes
<teknico> *too
<hatch> woah a new system 76 laptop that isn't massive
<hatch> little on the heavy side though for an 'ultrabook'
<hatch> buuuut you can get it with 16GB of ram
<hatch> hmmm
<rick_h> jcsackett: feedback on the way
<teknico> hatch: 1080p on a 14"? wow. if only it was from somebody else... ;-)
<hatch> lol, not a system76 fan?
<hatch> I don't really know anything about them
<rick_h> <3 my system76 desktop :) but I'd not buy their laptops personally. 
<benji> I've never owned one but at a former place of employment we had endless problems with a half dozen or so of them.
<rick_h> great guys, did an interview with their CEO at PyOhio a few years ago
<hatch> it looks a little plasticy
<rick_h> yea, the laptops just aren't the things of legend. 
<hatch> the price is right though...
<rick_h> I do <3 that they're colohugging all the displays that they ship though
<rick_h> great move, wish all laptops did that
<hatch> I "need" a new laptop heh so I'm definitely looking at everything :)
<hatch> colohugging?
<rick_h> https://plus.google.com/104919222657565747428/posts/7TxBM96MZYX
<rick_h> http://www.hughski.com/
<rick_h> have one and love it for my various displays. 
<gary_poster> ok sorry back
<hatch> ahhh cool
<hatch> my monitor was calibrated out of the factory like that too
<gary_poster> matsubara, you said "tarmac merges your branch into lp:juju-gui, uses that to start bin/test-charm with your branch as the origin"
<gary_poster> my concern is that the behavior is this:
<gary_poster> tarmac merges brancg into juju-gui *locally*
<gary_poster> then tells the test-charm sccript to run tests on *original* branch (not merged)
<gary_poster> In order to do the right thing, AFAIK, given the current code, we would need to do something like this:
<gary_poster> tarmac merges branch into juju-gui locally
<gary_poster> *tarmac pushes merged branch with --force to standard branch that it controls*
<gary_poster> tarmac uses --origin=*that standard branch that has the merge*
<gary_poster> Because tarmac is effectively single threaded
<gary_poster> that is safe
<Makyo> jujugui call in 9 kanban now
<gary_poster> thanks Makyo 
<gary_poster> teknico, I think there's some other way to start these tests that makes the problem go away
<gary_poster> I'm not sure what it is
<gary_poster> but if you could send a note to juju-gui with the problem I bet someone, possibly frankban, will give the answer between now and when you return :-)
<teknico> gary_poster: right, will do
<gary_poster> thx
<gary_poster> hatch did you catch what I said about what you had done?  it all works except for the part you didn't change, afaict :-)  maybe can pair on it briefly; I think we are almost there
<teknico> hatch: IIRC, both frankban and Makyo have system76 notebooks and neither is very pleased with them
<gary_poster> I had one and returned it.  I thought frankban was reasonably happy except size
<Makyo> Mine had a bad stick of ram and a color calibration issue fixed in 13.04.  Other than that, yeah, it's big, and the battery isn't great, but I like it well enough.
<teknico> gary_poster: nope, it overheats and turns off under not very heavy usage
<gary_poster> jujugui call in 2
<gary_poster> teknico, oh :-(
<Makyo> Not sure I'd get another, though.
<hatch> gary_poster: haha that's...good? So the auth failures were?
<gary_poster> no idea hatch.  did not dupe here
<gary_poster> luca___, hi.  where is the user data form effort?
<luca___> gary_poster: Peter is currently working on it, I'll check in with him soon.
<gary_poster> thank luca___ 
<luca___> gary_poster: going to send you wireframes in a few mins for a proof before they go to the team
<gary_poster> yay!
<matsubara> gary_poster, I see what you mean
<luca___> gary_poster: https://docs.google.com/forms/d/1Me4macMBX6KydCYyCC6YEjKnpCKakQCYlGlGxIB6Z0w/viewform
<gary_poster> luca___, still on call.  form looks like it has a lot of good stuff.  Can we have edit power on it?  I need to fix a few things and also add the legal language at the bottom
<jcsackett> sinzui: displaying icons in a non-brittle fashion on charmworld is starting to look like it may consume more time than expected; is it worth continuing, or should we drop it in favor of other work?
<hatch> there is 3" of rain in my wheelbarrel since yesterday and the forecast is for rain until Monday
<teknico> so, I'm still not clear on the problem, much less on a solution, and I'm about to EOW (and EONW too :-) ), so I need to delegate this loadFixture thing to someone. rick_h, hatch, any takers? some details in the card in Maintenance
<hatch> teknico: I should probably stick with the story I'm working on for now
<rick_h> teknico: yea, can't move off atm and the problem is temporarily worked around. I can chat with you on Monday if you want as I think there's an easy but semi-fragile fix we can try. 
<rick_h> teknico: but toss it out to see if it's 'better' than what we have now
<teknico> rick_h: the thing is, I'm off next week :-) that's why I' trying to get it reassigned
<rick_h> teknico: ah, well in that case...
<benji> grr, the 50 character lbox commit message limit is irritating
<teknico> ok, it's email then
<hatch> benji: you said it- it woudln't be so bad if it had a counter :)
<rick_h> hatch: use a real ide :P
<rick_h> hatch: well editor, vim position display ftw
<benji> s/ide/editor/ ;P
<rick_h> yea, got myself. I've got a bad case of friday's today letting things slip
<benji> I like my development environments disintegrated, thank you.
<hatch> lol
<hatch> I have been looking at webstorm for a long time
<hatch> can't really see it would gain me anything over sublime though
<gary_poster> hatch auth tests pass fine on saucelabs for me on IE 10 so far...
<hatch> hmph intersting, it failed multiple times for me
<hatch> If they pass then that's all that matters :)
<gary_poster> hatch, others: reviews pls https://codereview.appspot.com/10253055 :-)
<gary_poster> rick_h, maybe? ^ it is what you looked at this morning, with changes from you and to get it working
<rick_h> gary_poster: looking
<gary_poster> thanks
<benji> I figured out my timeout issue.  It was a combination of my own forgetfulness and the crazy world of web development: I had arbitrarily slowed down my network to better see the results of my branch, but of course the test runner does a bunch of HTTP, so it timed out.
<gary_poster> heh
<gary_poster> glad its resolved
<gary_poster> it's
<benji> I'm taking Nicola's card.
<rick_h> jcsackett: http://paste.mitechie.com/show/966/ for the record. Manual url building ftw I guess :(
<benji> I'm also wondering why his email went to my personal account.
<rick_h> jcsackett: pushed to  bzr push lp:~rharding/charmworld/reviewed-icons
<gary_poster> benji, I checked the mailing list and you are subscribed to your canonical account.  I am disinclined to suspect mailman, so I wonder if it is something google's side?
<benji> hmm, that's a possibility
<benji> this is an odd bit from the headers of that message: "Delivered-To: benji.york@gapps.canonical.com"
<rick_h> gary_poster: LGTM + notes on the way
<gary_poster> cool thanks rick_h 
<sinzui> jcsackett, how is it brittle? I thought the cases were: A is_approved and has icon,,  use it. B. Fall back to icon for category. C. Use misc if category is not one we know.
<rick_h> sinzui: I've got a fix going up that cheats and should work lp:~rharding/charmworld/reviewed-icons
<rick_h> tests pass and should be able to just go from there. 
<sinzui> fab
<hatch> gary_poster: on it, sorry I missed the ping
<jcsackett> sinzui: brittleness was in generating the image url.
<jcsackett> i was building manually, which will break on the next API upgrade, but the routing stuff was mangling things. rick_h solved the mangling.
<sinzui> oh, understood. Thank you jcsackett
 * hatch lunching
<gary_poster> sinzui, have you all done any load testing on charmworld?
<sinzui> gary_poster, not on production.
<sinzui> gary_poster, On staging, I crawled it to find all the 500 and 404 and saw it never failed.
<sinzui> gary_poster, we started discussing how to load test charmworld this week
<gary_poster> sinzui, fantastic.  would love to see load test, focused on interesting and search results.  I'm occasionally seeing missing editorial errors on gui, but not wure what it means
<sinzui> oh, yes. I see that two
<rick_h> gary_poster: is that true as of this week? 
<gary_poster> rick_h, yes, saw today
<rick_h> gary_poster: we made a change this week to help with that on editorial at least. 
<rick_h> gary_poster: k
<sinzui> gary_poster, and when I reload it is there. There is a 3 second timeout between squid and the app/db/search.
<gary_poster> hm
<gary_poster> well, it sounds like you guys are on the trail of it.  thank you.
<sinzui> we want to make search faster, introduce etags on the results.
<gary_poster> cool.  reliability of the sort we are talking about might be higher priority now, though.  search speed is not a problem for me IME, though faster is nice
<sinzui> understood
<rick_h> gary_poster: if you get it again. Please check the network tab in the browser and look at the return code and the time of the request. We were thinking of chasing some middle layer issue in the squid/nginx/etc that seemed to pop at the 3s interval and I'm curious if you're seeing that or not. 
<rick_h> interesting should really never take 3s any more though :/
<gary_poster> ack rick_h will do.  last time was in the middle of automated tests so I didn't get a chance to analyze
<sinzui> rick_h, there is no nginx...and I think its smart caching was helping us.
<rick_h> sinzui: sorry, apache. You're right. 
<rick_h> gary_poster: understand. appreciate keeping an eye out for it.
<sinzui> I had to configure apache to force http 1.0 because pyramid is vulnerable to long request. The other option was to switch to gevent
<gary_poster> matsubara, hey.  so, more tarmac next week?  I think CI tests should be working again
<gary_poster> should I re-enable the old jenkins project
<gary_poster> so we at least have post-commit style CI for now?
<matsubara> gary_poster, yes, I'll re-enable. just a sec
<gary_poster> thank you
<matsubara> gary_poster, done. 
<gary_poster> thanks matsubara  :-) have a great weekend
<matsubara> thanks you too!
<abentley> sinzui: mid-imp?
<sinzui> abentley, I can in 30 minutes. I am just leaving to get children
<abentley> sinzui: okay.
<hatch> yay jenkins is back to normal
<sinzui> Hi abentley, I am ready to chat
<sinzui> rick_h, jcsackett, are one of you testing staging and icons?
<sinzui> Do either of you want to see the error?
<jcsackett> sinzui: i am, and i would love to.
<sinzui> jcsackett, http://pastebin.ubuntu.com/5765889/
<sinzui> jcsackett, That is the only error. I have 3 occurrences in my inbox.
<jcsackett> sinzui: yeah, and i just accidentally triggered another when meaning to open the same path on manage instead of staging.
<jcsackett> oddly, going to the generated url locally or on manage causes no problems.
<gary_poster> orangesquad, jujugui, we have +1 from Robbie on sprint for North American team members in Raleigh, NC July 15-19.  I am filling out the paperwork to make official, so it is not time to buy tickets, but it is time to check dates and let me know if there are any issues.
<jcsackett> gary_poster: i'
<jcsackett> gary_poster: i'm just not sure i'll be able to get to that location.
<benji> heh
<gary_poster> jcsackett, :-P
<benji> I'm just glad it will be a short flight.
<hatch> gary_poster: LGTM if I can bring my kiteboarding gear and take a day off if it's nice to goto Jordan or Falls ;)
<jcsackett> hatch: i don't think kiteboarding is allowed at Jordan Lake.
<hatch> no? is it too awesome for it?
<hatch> the lake can't handle that much awesome in one spot?
<gary_poster> heh, maybe so.  There are a couple of decent sized lakes within 30-45 minutes.  Worth exploring at least.
<gary_poster> Weekend would be good ;-)
<abentley> gary_poster: I have stuff on Saturday the 13 and Saturday the 20, but during the week, all I have scheduled is taking out the recycling.
<gary_poster> heh ok :-)
<hatch> rick_h: there is a Lake Michie in NC....coincience?
<sinzui> thank you gary_poster. oh. and I will be 30 minutes closer to tRaleigh, this time
<gary_poster> :-) cool
<hatch> the sprawl around Raleigh is pretty crazy
<hatch> must be lots of 'bedroom communities'
<jcsackett> sinzui: i cannot figure out what combination of things has caused this. shall i rollback for now?
<sinzui> let me look before recommending rollback
<hatch> jcsackett: do you live in raleigh as well?
<jcsackett> hatch: i live in durham, which is another city in the same metropolitan area.
<hatch> ahh one of those bedroom communities I was talking about
<gary_poster> hatch, that's part of the sprawl.  it's not really bedroom communities.  they have those too
<jcsackett> hatch: i'm not sure what you mean by bedroom communities. if you mean like "suburbs", not so much.
<gary_poster> but Raleigh Durham Chapel Hill are full fledged places which come together into "the Triangle"
<hatch> oh - here a bedroom community is another city...say within a 30min drive of the city where people live but don't work
<hatch> I mean there are some places to work usually but not many
<gary_poster> Bedroom communities and/or suburbs would be Cary, Wake Forest, Apex, and so on
<gary_poster> no kind of more confused than that here :-)
<jcsackett> hatch: ah, i see. still not quite accurate; each one has quite a lot of live/work. :-)
<hatch> ahh gotcha - well here there is 1M people in the whole prov so that's to be expected I suppose :)
<hatch> holy smokes that's a long ways from me
<hatch> 8+h flight times haha
<gary_poster> and when you get here everyone'll probably melt
<jcsackett> it is *very* warm.
<jcsackett> though today has been nice, post-storm.
<hatch> well I was in NOLA for a while and survived ;)
<gary_poster> Yeah, spring or fall would show off the area to better advantage
<jcsackett> you are sort of picking the worst season for people to come, given the group has canadians. :-P
<hatch> Canadian....single :P
<hatch> or is someone else one too?
<jcsackett> hatch: abentley is also from canada.
<gary_poster> Aaron
<hatch> ohhh right I forgot he is on our team now
<gary_poster> well
<gary_poster> he is orange
<gary_poster> and orange is helping us for as long as I can keep them
<jcsackett> and rick is very, very close to y'all's border.
<hatch> abentley: is from the east though
<hatch> ...the east...
<hatch> they think Canada ends at the Quebec border :P
<sinzui> jcsackett, I think you should rollback. There is some interesting rearrangement of data happening between you route additions and views.api.API2.{__call__, _handle}. I don't think the path is being unpacked.
<sinzui> jcsackett, I am going to put a pdb in .charm() and make the same request to see what was really passed to the method
<abentley> hatch: My mom's from Edmonton and my sister lives in Vancouver.  It's not like we're disconnected from the rest of Canada.
<hatch> abentley: so do your friends think that your family lives in another country?
<hatch> :P
<abentley> hatch: No, at least half of my friends weren't born here either.
<hatch> haha
<hatch> a couple guys/girls i know moved to TO and they said everyone they ran into thought we were all farmers
<jcsackett> sinzui: yeah, i think the route stuff is wrong; need to talk with rick_h about that on monday.
<hatch> jcsackett: after deploying a charm the url shows /sidebar/ even though / is the default to show the sidebar and /minimized/ means it's hidden is this a bug?
<jcsackett> hatch: on uistage?
<jcsackett> i see '/'. '/sidebar/' is still a valid url, just not the default.
<hatch> right, click a charm, click 'add' the url is now /sidebar/
<hatch> should it not be /
<hatch> ?
<jcsackett> hatch: well, it's not invalid. what it should be i don't actually know.
<jcsackett> but yeah, probably just '/' -- file a bug for it, would you?
 * Makyo dogwalkify.
<hatch> sure thing - I wanted to just check with someone who might know before I did :)
<rick_h> jcsackett: sinzui ah, I see the error. Please rollback
<gary_poster> hatch, jcsackett it actually needs to be configurable IIRC
<jcsackett> rick_h: in the process.
<gary_poster> when juju gui is used as tool, sidebar should be root
<rick_h> jcsackett: sinzui the tests passed but yea, most tests hit the direct method call :/ I'm sorry. Did a very basic QA 
<jcsackett> rick_h: i swear it worked locally, but i must have been looking at my branch pre-merge.
<gary_poster> when used as jujucharms.com it should be fullscreen
<rick_h> jcsackett: sinzui I thought the route diff was ok, but now see that I was mistaken. Sorry for the trouble :(
<sinzui> rick_h, is it config.add_route('api_2', '/api/2/{endpoint}/*remainder')
<gary_poster> at least that's what I think we want/said
<jcsackett> rick_h: all good. we can rollback now, and make the fix monday morning.
<rick_h> sinzui: yea, I did that to make the route_path method work correctly. 
<rick_h> sinzui: because it can't handle a route like the original
<rick_h> jcsackett: thanks, apologize again for the trouble at the end of a friday. 
<jcsackett> rick_h: as long as it happens before I EOD, all good. :-P
<jcsackett> sinzui: MP up for you to glance over.
<rick_h> heh, well I just finished mowing the lawn so ugh to walk into I broke it 
<jcsackett> sinzui: https://code.launchpad.net/~jcsackett/charmworld/rollback-266/+merge/169546
<sinzui> r=me, we can wait for tarmac
<jcsackett> whoo.
<hatch> gary_poster: ahh so....this isn't really a bug per-se it's just a not fully developed feature? :)
<rick_h> jcsackett: I bet it's because *reminder returns a list while remainder:.* is a single entity. 
<rick_h> jcsackett: a string
<gary_poster> hatch, eh file it, but include my notes?
<jcsackett> that seems reasonable.
<rick_h> jcsackett: I flipped that while tweaking it and it swapped things around
<hatch> gary_poster: sure can do
<gary_poster> thank you
<rick_h> jcsackett: do me a favor, can you put my face on that card and I'll peek at it when I get a chance. If that's all I need to do I can re-apply and make sure to add a better functional test a layer up to catch that stuff
<jcsackett> rick_h: your mug is on it too now. :-P
<hatch> gary_poster: if you wouldn't mind reviewing just to make sure I have your comment correct https://bugs.launchpad.net/juju-gui/+bug/1191160
<_mup_> Bug #1191160: url shows /sidebar/ after deploying charm <charmbrowser> <juju-gui:Triaged> <https://launchpad.net/bugs/1191160>
<gary_poster> that's it hatch, thanks. 
<hatch> gary_poster: thanks for the grammar fixes :)
<hatch> English never was my strong suit ;)
<gary_poster> hatch, lol, I was just trying to make it easier for me to parse
<gary_poster> I missed at least one comma in there, and maybe put in an extra :-P
<hatch> haha
<rick_h> hatch: picky :P (re url bug)
<rick_h> hatch: the trouble is that it's the url state, without doing an additional dispatch not sure we can get rid of it. 
<hatch> rick_h: lol, hey I just want the app to be perfect :)
<rick_h> hatch: hmm, maybe there's a way...anyway :P on the whole thing
<hatch> where there's a will...there's a way!
<hatch> mama always said, life is like a box of chocolates
<hatch> oh wait...wrong quote
<hatch> :P
#juju-gui 2014-06-09
<rogpeppe> mornin' all
<frankban> morning rogpeppe: how are you doing? when you have time, could you please take a look at https://github.com/juju/juju/pull/48 ?
<frankban> rogpeppe1: hi, when you have time, could you please take a look at https://github.com/juju/juju/pull/48 ?
<rogpeppe1> frankban: looking
<frankban> thanks
<rogpeppe1> frankban: reviewed
<frankban> rogpeppe1: thanks
<frankban> rogpeppe1: so, the rule is to not rebase changes after the review, right?
<rogpeppe1> frankban: i think so
<frankban> rogpeppe1: ok
<rogpeppe1> frankban: i don't know what the rules are any more :-)
<frankban> rogpeppe1: yeah, I am also a bit confused
<frankban> rogpeppe1: I'll take a look at removing testing dependencies from store
<rogpeppe1> frankban: cool
<frankban> rogpeppe1: didn't you have a branch for moving testing/charms.go to charm/testing?
<rogpeppe1> frankban: yeah
<frankban> rogpeppe1: is it ready to be proposed?
<rogpeppe1> frankban: it's already been LGTM'd
<rogpeppe1> frankban: i thought it had landed
<frankban> rogpeppe1: it does not seem so
<rogpeppe1> frankban: ah, tests failed
<frankban> rogpeppe1: could you please get that landed? store depends on testing.Charm right now, I'd like to change that
<rogpeppe1> frankban: yeah, just looking now
<rogpeppe1> frankban: one of those sporadic test failures. i'll re-merge and re-propose.
<frankban> cool thanks
<rogpeppe1> ok, trying to land again
<rick_h_> morning
<frankban> morning rick_h_
<frankban> rogpeppe1: it seems we have to move testing/mgo.go to github/juju/testing. The only internal dep is cert.ParseCert. we can either 1) move cert to its own repo (it does not depend on anything internal) or 2) dupe ParseCert in github.com/juju/testing
<rogpeppe1> frankban: hmm, is that for the mongo that the store tests need?
<frankban> rogpeppe1: yes
<frankban> rogpeppe1: store_test.go
<frankban> rogpeppe1: perhaps cert can be moved into utils?
<frankban> rogpeppe1: it's just a single file and a test file
<rogpeppe1> frankban: i'm a bit dubious about that
<rogpeppe1> frankban: it's really very juju-specific
<frankban> rogpeppe1: so github.com/juju/cert?
<frankban> (option 1)
<rogpeppe1> frankban: i'm having to think quite hard abut whether mgo.go should go into github.com/juju/testing
<rogpeppe1> frankban: there's quite a lot of logic in there that's there mostly because of the way we do things in juju
<frankban> rogpeppe1: uhm, is that logic still valid for the future store?
<rogpeppe1> frankban: and at the moment, I can't quite see how it's working, given that store calls mgo.Dial directly. Ah, I see, it calls MgoTestPackagSsl with ssl=false
<rogpeppe1> frankban: so the charm store doesn't actually use any of the cert stuff
<rogpeppe1> frankban: my main concern is that the way mongo is configured in MgoSuite must be an exact mirror of how the state server sets up mongo
<rogpeppe1> frankban: so keeping the two in sync, in the same repo, seems like a Good Thing
 * rogpeppe1 tries to think of a way of factoring out the juju-nonspecific pieces
 * frankban bbiab
<frankban> rogpeppe1: re juju logic: do you mean the ssl stuff? I am thinking about making MgoTestPackageSsl accept a pem string instead of a ssl bool. That way the ssl logic can still be placed in juju, while the suite itself can be moved
<frankban> rogpeppe1: istm that, even if we want to decouple MgoSuite from the juju certs, it is still interesting to have a generic MgoSuite that handles tls. in that case, even if, e.g. we change MgoTestPackage so that it receives the certs, we still need the cert stuff to be in an external repo.
<frankban> rogpeppe1: and I am not sure I fully understand why cert stuff should be considered so specific to core
<rogpeppe> frankban: the details of the generated certificates are very juju specific
<frankban> rogpeppe: ^^^
<rogpeppe> frankban: for example, look at the CommonName in cert.NewCA
<rogpeppe> frankban: and the Organisation, etc
<frankban> rogpeppe: IC, you pass the env name, etc...
<rogpeppe> frankban: if we change MgoTestPackage so that it receives the certs, we don't necessarily need the cert stuff to be in an external repo
<rogpeppe> frankban: because you'll generally only want that stuff if you're part of juju
<frankban> rogpeppe: that's true if we duplicate the code in cert.ParseCert
<rogpeppe> frankban: ParseCert is a fairly trivial wrapper function
<rogpeppe> frankban: I don't mind duplicating that code if we need to
<rogpeppe> frankban: alternatively we might be able to make it take *x509.Certificate and *rsa.PrivateKey as args
<rogpeppe> frankban: which would probably be just as easy to use
<frankban> rogpeppe: ok, that seems to work. So we need to decouple testing/mgo.go from the stuff in testing/cert.go, right? 
<rogpeppe> frankban: yeah
<frankban> rogpeppe: and MgoTestPackage receives *x509.Certificate and *rsa.PrivateKey: if they are both nil tls is disabled
<rogpeppe> frankban: if the cert is nil, tls is disabled, i think
<rogpeppe> frankban: if there's a cert and no private key, i think we can panic
<frankban> rogpeppe: coo, and MgoTestPackageSsl is just a juju shortcut which takes nothing and uses stuff defined in testing/cert.go, right?
<rogpeppe> frankban: sgtm
<bac> frankban: update: i got the python-websocket-client backported to precise and saucy in juju-quickstart-beta ppa.  doing the final QA on precise.  will get it moved to juju-stable ppa soon.  then do the release of 1.3.3.
<frankban> bac: sounds good, was it difficult to change the package name?
<bac> frankban: it required i do everything by hand.  couldn't use the backportpackage tools
<bac> so, none of it hard, just requires figuring out the six incantations.
<frankban> bac: :-/ thanks a lot for that, do you have notes about the incantation process?
<bac> frankban: i do.  will clean them up and stick somewhere shortly
<frankban> bac: great thanks
<hatch> morning all
<hatch> I have no internet....yay! 
<rick_h_> wheee
<hatch> rick_h_ want to take a look at the new cache stuff while I write the tests https://github.com/juju/juju-gui/pull/372
<rick_h_> hatch: looking
<rick_h_> hatch: feedback done
<hatch> cool looking
<hatch> I'm also calling around trying to get my internet fixed 
<hatch> ugh, apparently our area is subbed out to a contracting company to get fixed
<rick_h_> some sort of community internet?
<hatch> I think it's that the telco doesn't have enough staff
<hatch> so they have to sub out jobs sometimes
<hatch> brb hopping on the phone again
<makyo_> jujugui call in 10
<hatch> rick_h_ replies made
<rick_h_> jujugui call now rogpeppe jcsackett 
<rick_h_> antdillon: ^
<jcsackett> rick_h_: voice plugin crashing, be there soon.
<rick_h_> jcsackett: rgr
<bac> makyo_: don't say PTO</rant>
<Makyo> ??
<bac> PTO is a movement to steal your sick time and roll it in with vacation.
<bac> rick_h_: stop saying PTO
<bac> :)
<bac> HR has agreed to change the wording
<hatch> what's wrong with PTO?
<hatch> too union for ya? lol
<rick_h_> bac: oh, sorry. It's my old job everything was PTO
<hatch> EDO's.....now that's what we need
<hatch> EDO's
<hatch> lol
<bac> PTO means you can never really plan, as you must keep an allotment for the off chance you get sick.
<rick_h_> bac: yea, always hated that, but also hated having XX sick days never not using them
<bac> anyway, the PTO language on the HR site is inherited from salesforce and not a new company policy.
<bac> rick_h_: but our current sick policy takes into account your previous use.  so if you never use it, then when you do have the need you are given allowance.
<hatch> I actually had no idea there was such a issue with the naming
<Makyo> rick_h_, requests in
<bac> hatch: you wouldn't.  us of a specific silliness
<hatch> bac I mean that I didn't know PTO had a certain definition where it specifically lumped things together like that
<rick_h_> hatch: replied
<rick_h_> hatch: overall seems like a good path. 
<hatch> I STILL can't get a hold of anyone to come fix the internet....ugh
<hatch> rick_h_ cool thx
<bac> rick_h_: when i last looked at IPv6 interoperability testing the only tools were a mess of Perl written at a Japanese university.  it was terribly painful.
<bac> hopefully things are better now
<rogpeppe> frankban: sorry, just saw my branch failed to land again (clashes with other branches which had been pushed in the meantime)
<rogpeppe> frankban: am trying again
<frankban> rogpeppe: thanks, no worries
<hatch> hmm I wish I could put the hotspot on my network....
<rick_h_> hatch: <3 http://www.amazon.com/gp/product/B007GFYHPG/ref=wms_ohs_product?ie=UTF8&psc=1
<rogpeppe> frankban: oh, darn it, i think i forgot to commit the relevant changes before merging
<rick_h_> hatch: I've used that to share out my mifi network, and think it can run the wifi network through the wired end
<hatch> rick_h_ so this thing youd plug in place of the modem and connect it to your switch?
<rick_h_> hatch: well the mifi would do wireless and you'd plug the wire end into your current router outside
<rick_h_> so your existing router would this this thing is the internet
<rick_h_> would think that is
<hatch> ahh yeah that's definitely what I need
<rick_h_> I *think* it can work that way. Normally it's for taking a wired connection and sharing it out over wifi (hotel with wired but no wifi signal) or resharing/extending an existing wifi network (5 devices on my mifi my $#@$#@, I'll connect as many as I want)
<hatch> lol
<hatch> why does your mifi have a limit?
<rick_h_> they do in the US here. Most do 5 or 10 devices
<rick_h_> I share with my coffee house coders group so I use that to get aroudn the limits
<hatch> I'm wondering what the thought is behind that
<hatch> # of devices does not increase the bandwidth or anything heh
<rogpeppe> hatch: before i get totally lost in the git log help page again, do you know how to get git log to show the files that have changed in each commit?
<hatch> git log --name-only or something
<rick_h_> rogpeppe: I use lf = log --stat
<rick_h_> so git lf
<hatch> maybe git log --stat would be better
<rick_h_> will give me file/diff info
<hatch> heh you and your aliases :)
<rick_h_> ld = log -p 
<lazyPower> rick_h_: do we know if juju-actions are going to be exposed in juju-gui
<rick_h_> is good as well, for the diff
<rogpeppe> hatch: ah, that looks good thanks. line 1139 out of 1850 of the help page.
<rick_h_> lazyPower: the hope is to. We've got a guy that's been waiting on stuff to implement it. He's not contract, so not sure how far he'll get 
<rogpeppe> hatch: not surprising i hadn't found it yet
<lazyPower> ok ty
<hatch> rogpeppe unlike bzr there is a HUGE amount of information online for "how do I do x" so you don't need to read the man pages
<rogpeppe> hatch: yeah, i guess. rtfm is a bad habit i need to get out of :-)
<hatch> haha - well, it's a good habit, but with big communities usually come faster ways to do things :D
<rogpeppe> hatch: once upon a time, man pages were simple :-)
<hatch> rogpeppe haha I suppose thought git would have been 100 different commands back then too
<lazyPower> rick_h_: if that work starts can you ping me? Our big data efforts would benefit from this and asanjar is practically offering me money to give him information on it.
<rick_h_> lazyPower: so I sent an email today to him about looking over the documentation that bodie sent out in irc 
<rogpeppe> hatch: it *is* 100 different commands :-)
<lazyPower> thats excellent.w e want to be early adopters :)
<rick_h_> lazyPower: and I've asked him to start looking at the front end and meet in the middle with the back end as the api finalized
<hatch> rogpeppe lol!!
<rick_h_> lazyPower: so I guess it's "kind of" in progress
<lazyPower> excellent. as soon as we have a branch / etc to look at I'm game to get my hands dirty
<rogpeppe> hatch: actually, 146 different commands...
<rick_h_> lazyPower: definitely. Because he's not paid/contractor I'm not sure how it'll go, he has another job, but we're trying to enable him to be involved and move things forward from the GUI end. 
<rick_h_> lazyPower: but we'll definitely be reaching out to you guys as things firm up because actions need to go through charm proof, we'll need to get those ingested/part of the charmworld api, etc
<lazyPower> marcoceppi: ^
<lazyPower> pinging you preemptively so you're aware of whats coming at us
<rick_h_> lazyPower: marcoceppi make sure you see https://github.com/johnweldon/juju-docs/commit/cb7a4709e9a5fed5c885cd3e5e2ecc1cd34da181#commitcomment-6594689 and respond
<marcoceppi> lazyPower: cool, I told the core guys to let me know when it lands in trunk too so we can start playing with it
 * rick_h_ goes to get lunchables
<hatch> rick_h_ I replied to one of your comments about the bundle/charm path id url stuffs
<rick_h_> hatch: looking
<rick_h_> hatch: why can we not use the permanent/url? 
<hatch> rick_h_ the data I have is in the first paragraph the perm url requires that I parse the username out of the entityId to reconstruct it
<hatch> so it's the least amount of work to do what I did
<hatch> we could maybe create a entityId > charmUrl method
<rick_h_> hatch: call? I'm having a slow monday and not following
<hatch> sure one sec just grabbing my coffee
<hatch> be in standup
<rick_h_> rgr
<bac> hey frankban, my qa of 1.3.3 is good.  i'm going to copy the packages over to juju/stable now and do the pypi release after i eat lunch.  any objections?
<rick_h_> woot!
<frankban> bac: please go ahead and thanks!
<bac> np
<frankban> rogpeppe: review done
<rogpeppe> frankban: thanks!
<rick_h_> rogpeppe: https://plus.google.com/hangouts/_/canonical.com/jaas-work?authuser=1
<Makyo> rick_h_, hatch I figured out where the call stack is on the profiler.  Looks like it's all in YUI land on a few calls from the token widget (setHTML and _setBox, both of which parse the string they're given as HTML). Not sure of next steps - any ideas?
<hatch> Makyo ok that's where I got too as well, glad we're in the same place :)
<hatch> now as far as ideas.....that's also as far as I got
 * hatch thinks
<Makyo> Best I could think of is to deal with it only as strings until the last step and only parse it once, but I think that goes against the Widget Wayâ¢
<hatch> Makyo yeah....but why didn't we have this problem before with the old code?
<Makyo> hatch, we did, but it was hidden by the long load times.
<hatch> but we don't on jujucharms.com
<Makyo> Checked on an old checkout.
<hatch> on jujucharms.com going from a search back to curated is instant
<Makyo> I get exactly the same profile on jujucharms.com
<hatch> really....interesting
<hatch> hmm ok then
<hatch> that settles that debate haha
<hatch> Makyo what if....after each 'section' is rendered we append it to the dom
<hatch> instead of all at once
<hatch> so add the append() into the loop isntead of out of it
<hatch> maybe we can start showing 'something' sooner
<Makyo> Hmm, let me play around with that.
<hatch> this of course being an alternative to re-writing it
<hatch> I mean....
<hatch> :)
 * Makyo gets out the squirt bottle.
<Makyo> Works on the dogs...
<hatch> haha
 * rick_h_ runs errand biab
<hatch> alllright, I finally talked to someone who MAY be able to fix my internet
<hatch> lol
<hatch> so much fail today
<hatch> yay! It's getting fixed this afternoon
 * rogpeppe has reached eod
<rogpeppe> frankban: that branch finally landed, BTW
<frankban> rogpeppe: \o/ looking at your cp branch
<hatch> I'm going to run grab a bite before the tech gets here to fix this net
<frankban> rogpeppe: done
<hatch__> oh great the internet started working again before the tech got here....
<rick_h_> lol
<rick_h_> now you've done it
<hatch__> yeah now this thing is never getting fixedx
<Makyo> hatch, That change doubled the FPS (read: halved the amount of time blocking on render) from ~7fps to ~15fps.
<Makyo> Still takes the same amount of time, ofc.
<Makyo> Which would help with the spinner.
<hatch> Makyo ok so that's likely why we didn't notice it before
<hatch> alright then
<rick_h_> yea, with the spinner and less time
<rick_h_> blocked up taht is
<rick_h_> I did notice the spinner hang some, but not enough that it felt broken
<hatch> Makyo with a spinner would it now be acceptable? 
<Makyo> I think so
<Makyo> It would feel better, at least.
<rick_h_> yay
<hatch> and we can put off the conversion to a view for some time later
<rick_h_> +1
<Makyo> +1
<rick_h_> thank you Makyo for chasing that down and testing it out
<hatch> it's interesting just how much slower widgets truly are
<Makyo> I wonder if the views would have much in the way of improvement, since the slowness shows up in some of the base node manip stuff, like setHTML.
<rick_h_> yea, I guess I wonder how much is parents vs just widgets/etc
<Makyo> But yeah, I'm still learning the whole widget thing.
<hatch> well we dump considerably more dom nodes into tho dom with the inspector unit list on a big environment
<hatch> that uses append()
<hatch> so I'm guessing that it has to do with some html parsing or something that's being done with the widgets
<hatch> because there is some progressive enhancement stuff tha'ts built in
<hatch> maybe we are hitting that
<hatch> this is totally speculation though
<Makyo> Okay, yeah, that makes sense. I think it's come to bite us more recently because of the addition of bundles, too, which have more elements in the dom (some of which are SVGs, which chrome is parsing) 
<hatch> ahhh
<hatch> darn svg's
<hatch> I noticed that we request the same svg a lot
<hatch> even though it has the same request path
<Makyo> That is how img elements, work, yes :)
<Makyo> Ditto svg image elements.
<hatch__> I never thought i'd be happy that the internet broke again....lol
<bac> hey rick_h_, got a sec for a chat?
<rick_h_> bac: 2min?
<bac> sure
<rick_h_> bac: k, standup hangout?
<bac> k
<hatch> tech is here, bbiab
<rick_h_> good luck
<hatch> heh it's not looking good
<hatch> rick_h_ btw doing the id bits in the bundle model was pretty small loc's
<hatch> so i'll leave it in
<rick_h_> hatch: woot
<rick_h_> had hoped so
<hatch> rick_h_ so regarding the search caching.....I don't think it's going to be an issue because modellists don't add multiple models with the same id's
<hatch> so the charm models won't grow exponentially, only linearly 
<rick_h_> hatch: ok, but QA it with a bundle: and charm: and "" search
<hatch> right now when I do a bundle: search I only get a single bundle
<rick_h_> if it qa's ok and not deadly with the large basis then cool
<hatch> is charmworld broken that it only returns 1?
<rick_h_> hmm, maybe not
<hatch> i'll try jujucharms
<hatch> yeah only one....
<hatch> odd...I was sure that returned a massive json 
<rick_h_> ok, then yea oh well
<rick_h_> we fixed a lot of that
<hatch> but broke bundle: ? :)
<rick_h_> heh, well not sure that was supposed to work
<rick_h_> bundle:apache should
<hatch> checking
<rick_h_> hmm, yea bundle: was supposed to work for all bundles
<rick_h_> how about just bundle
<rick_h_> w/o the :
<hatch> bundle:apache doesn't
<hatch> trying without the : for bundle
<hatch> yeah it's hanging
<hatch> that must be it
<rick_h_> heh there you go
<hatch> hmm it only returned 52 bundles
<hatch> but took fo eva!
<rick_h_> hah, well bundles take a while to build since htey include charm info
<hatch> but ok cool I'll check that out with the caching
<hatch> ohhhh right 
<hatch> looks good even with a big data set
<rick_h_> woot
<hatch> memory footprint of course goes up according to the size of the huge dataset
<hatch> so we should still see what we can do about reducing the data sent at some point
<rick_h_> yep yep
<rick_h_> but that's on the api end side to do 
<hatch> right now our box for the gui should say "requires a minimum of 200MB of ram" ;)
<rick_h_> :P
<Makyo> hatch, mind taking a look?  Trying to figure out how to test. https://github.com/juju/juju-gui/pull/373
<hatch> sure 
<hatch> heh hmm
<hatch> Makyo maybe adding some comments around the render() call for future devs and for the tests make sure it's called with the proper string in the tests using a stub
<Makyo> Hmm, alright.
<hatch> I'm also not sure container is used any longer
<Makyo> This is gonna be finnicky.
<Makyo> charmList = container.one...
<hatch> oh duh
<hatch> heh
<Makyo> It's basically the same exact functionality, just in a slightly different order.
<rick_h_> Makyo: yea, I think you can do that with a big QA and comments around that
<hatch> well render is being called with a different string
<hatch> er elements
<hatch> I know it's pretty basic but that's all I can see here without doing any selenium stuff
<rick_h_> hatch: yea, true
<rick_h_> but even selenium stuff is hard to catch
<hatch> oh yeah for sure - I've been doing some research on performance testing in CI
<hatch> would be pretty cool if we could somehow get a more stable CI machine
<hatch> stable being performance wise
<hatch> uh oh internet is looking like it's going to be a bit
<hatch> the lines going into the house are bad
<hatch> rick_h_ did you see someone picked up the a Review Board charm
<rick_h_> hatch: yea, saw that. I can't seem to find a good way to work reviewboard into the workflow though to be honest
<rick_h_> everything I find really doesn't even try to work with the pull request system in github. A lot of it is pre-pull request review style stuff
<rick_h_> all diff based, which doesn't help our lander/etc systems
<hatch> that was my reviewing as well - I was hoping to get some time more time this week to dig in and see if we could write a hook or something
<hatch> s/hook/plugin
<hatch> although tbh I think that GH is working pretty well for us
<hatch> it has some warts, but what doesn't heh
<rick_h_> yea, but it definitely has some scale issues imo. The side by side review plugin is :( compared to a real side by side tool
<hatch> right - but since I've been doing the inline stuff I miss side-by-side less and less
<hatch> maybe it's just the type of work I've been doing
<rick_h_> yea, maybe it won't work out, but had high hopes for it
<hatch> I think with GH not showing the whitespace changes like reitveld did, side-by-side isn't as important because diffs are typically less than 20 lines
<hatch> per block
<hatch> more than enough that can fit on the screen
<hatch> yes, side-by-side IS better, but inline isn't horrible imho
<rick_h_> yea, I mean there's the email flood, the lack of diff's in rebased stuff, etc. 
<rick_h_> more to it I guess, but yea, if it can't fit into the workflow in a sane way I don't want to write another app to do it
<hatch> yeah the email is crazy but if you use the email threads or whatever you can easily delete the whole thread
<hatch> the lack of diffs in rebased kind-of sucks....but I can't think of once where I actually needed it since we switched over
<rick_h_> "if you use" :P
<hatch> well use a real client :P
<rick_h_> you're getting very much into your use vs the team as a whole tbh
<hatch> wait, even mutt does threads
<rick_h_> yes it does 
<rick_h_> just mean that you're projecting "it's not an issue if you do XXX" is not the best argument for stuff like this
<rick_h_> as  you fall deep into assumptions
<hatch> oh right - well got to adapt to the tools sometimes unfortunately 
<hatch> good thing we all got into web dev, nothing ever changes here :P
<rick_h_> :)
<hatch> installing that tree file system plugin for GH has saved so much time
<hatch> that sort of stuff should be installed by default hah
<hatch> well looks like I might be going to pick up one of those things you mentioned rick_h_  because if they need to run a new line it might be a bit before I get internet again :/
<hatch> see everyone tomorrow 
<huwshimi> Morning
#juju-gui 2014-06-10
<hatch> huwshimi hey I'm looking at your comment re the bubbling issue
<huwshimi> hatch: Hey
<hatch> huwshimi see the new units added here: https://github.com/juju/juju-gui/blob/develop/app%2Fwidgets%2Fmachine-view-panel.js#L173 add it as a bubble target, but when a unit is added here https://github.com/juju/juju-gui/blob/develop/app%2Fwidgets%2Fmachine-view-panel.js#L78 it's not
<hatch> Makyo this question is illegible but it's using your openstack bundle http://askubuntu.com/questions/481105/juju-openstack-bundle-cant-launch-an-instance I'm not sure if that bundle deploys any more? 
<huwshimi> hatch: That doesn't seem to help things.
<huwshimi> hatch: It still breaks on that .destroy line
<hatch> ok looking
<hatch> huwshimi can you try this: wrap that destroy in a setTimeout with a 5s timeout or something long to see if that works - I think it's destroying the token before the event gets fired/bubbles
<hatch> sorry I can't test atm
<Makyo> hatch, correct, that bundle was for demonstration purposes only.
<hatch> Makyo might want to comment on that question to that effect :)
<rick_h_> Makyo: remove the branch and we can remove the4 bundle from charmworld
<rick_h_> Makyo: or maybe you can as well
<rick_h_> Makyo: http://manage.jujucharms.com/bundle/~makyo/openstack/openstack/delete
<huwshimi> hatch: Yep, that works with the timeout
<hatch> huwshimi ok so the addTarget IS still missing but the real issue is that it's being destroyed before it can fire the event
<hatch> so....hmm
<Makyo> rick_h_, no luck.  Also, getting no stylesheets on m.jc.
<hatch> vat to do
 * hatch says in his best Ukrainian accent 
<Makyo> Oh, there's the login, nevermind.
<rick_h_> Makyo: I removed it
<Makyo> Oh, thanks
<rick_h_> Makyo: oh yea, sorry you have to auth first as it's a manage thing
<Makyo> There we go.  Thanks rick_h_ 
<hatch> eventful night :)
<rick_h_> party
<hatch> huwshimi using settimeout is not a valid solution either :PPP
<huwshimi> hatch: haha
<hatch> I used 600MB of data today.....doing nothing
<hatch> man I hope they fix my internet soon
<hatch> hah
<rick_h_> lol
<rick_h_> night all, see you same bat-place tomorrow
<huwshimi> rick_h_: Night
<hatch> night 
<rick_h_> I've done my git/github lecturing to core for the night :P 
<hatch> :D
<hatch> huwshimi I'm going to hop back offline for the night - hope I got things back on track for ya :)
<hatch> I'll probably check back in a little later
<frankban> rogpeppe: hi
<rogpeppe> frankban: hi. am looking at your review...
<frankban> rogpeppe: could you please take a look at https://github.com/juju/testing/pull/16 ?
<rogpeppe> frankban: yup :-)
<frankban> rogpeppe: cool thanks. did not rebase so that you can look at changes on the third commit: Changes to MgoSuite.
<rogpeppe> frankban: am doing, thanks
<rogpeppe> frankban: rather than putting the server cert generation code into mgo.go, couldn't we just pass the server cert in along with the CA cert?
<rogpeppe> frankban: (which means that the juju-core testing code can use the actual code from the cert package that will be used for real)
<frankban> rogpeppe: uhm... yes we can do that, so something like MgoTestPackageSsl(t *testing.T, srvCert, caCert *x509.Certificate, caKey *rsa.PrivateKey) ?
<rogpeppe> frankban: yeah. or put 'em in a struct.
<frankban> rogpeppe: is three args enough to put them in a struct?
<rogpeppe> frankban: e.g. MgoTestPackage(t *testing.T, certs *Certs)
<rogpeppe> frankban: i think it might make sense, given that they all need to specified at once
<rogpeppe> frankban: it makes the test simpler as well (if certs != nil { .... })
<frankban> rogpeppe: oh, and at that point we no longer need caKey, right?
<rogpeppe> frankban: yeah
<rogpeppe> frankban: but we do need the server key
<frankban> rogpeppe: for the &key.PublicKey bit?
<rogpeppe> frankban: for the key that gets written to the PEM file
<frankban> rogpeppe: yes
<frankban> rogpeppe: so something like http://pastebin.ubuntu.com/7622839/ in mgo.go?
<rogpeppe> frankban: pretty close. i'd do http://paste.ubuntu.com/7622851/
<frankban> rogpeppe: ah, sure the fields need to be exported
<rogpeppe> frankban: yeah
<frankban> rogpeppe: we also need the ca key for x509.CreateCertificate
<rogpeppe> frankban: we don't need to call CreateCertificate, do we?
<frankban> rogpeppe: nt sure, how do we create the pem file? we need bytes to write it
<rogpeppe> frankban: the PEM file doesn't have the CA key in it
<rogpeppe> frankban: you can get the DER bytes from the Certificate and PrivateKey
<rogpeppe> frankban: the cert bytes are in cert.Raw
<frankban> rogpeppe: trying
<frankban> rogpeppe: updated
<rogpeppe> frankban: looking
<frankban> thanks
<rick_h_> morning
<rogpeppe> frankban: reviewed
<frankban> rogpeppe: thanks!
<frankban> rogpeppe: I've found this recent commit in mgo.go, I gues I'll reproduce that (remove mgo.SetDebug(true)) in my current branch
<rogpeppe> frankban: sgtm
 * rogpeppe goes for lunch
 * frankban lunches
<rbasak> o/
 * rbasak didn't know this channel existed!
<bac> ha, it's *the* place to hang out
<rick_h_> we party in our own little world
 * bac -> tea.  brb
<rbasak> bac: AIUI, the issue is because you're trying to maintain a PPA for multiple series with a single packaging branch?
<rbasak> This is tricky since the packaging tooling doesn't really accomodate that use case, since they've grown out of distribution tooling which focuses only on one series at once.
<rbasak> I suggest that you maintain a "trunk" packaging branch, and for past series that cannot use that, use more packaging branches branched from that trunk packaging branch.
<rbasak> Does that help at all?
<rick_h_> rbasak: do you keep a seperate packaging branch from the source then? So you pull down the source branch, marge the changes in that into a 'trunk packaging branch' and then have branches of that for different series?
<rbasak> rick_h_: I don't, no. I've not hit this particular issue before, since most of my work is directly in the archive and there we don't need to update older releases much.
<rick_h_> rbasak: ah ok
<rick_h_> rbasak: yea, I guess we're just trying to find a workflow that's not nuts and this is the first time the simplest hasn't worked out for us
<rbasak> We do try in some cases to try and keep packaging in the development release more easily backportable. There's certainly value in that.
<rbasak> In this case though, I can't see how that is easily doable.
<bac> rbasak: ok, so a different packaging branch and different build recipes for the different sets of series with like rules.
<bac> rbasak: i think in our case, the packaging for trusty would just have the pydist-files override and the other would not
<bac> i was hoping to avoid that fork but it isn't a big deal and it is good to know you consider it best practice not lunacy
<rbasak> otp brb
<rbasak> bac: sorry, that was a long call. Yes - I think it's the best option. A better option would be to try and find a way to support both series in the same packaging but it sounds like that's not possible here.
<rbasak> So a branch is the next best option I think.
<bac> rbasak: thanks
<rbasak> bac: no problem. On a separate note, it might be an idea to reduce the packaging delta between your PPA and the Ubuntu archive. I noticed it varied a bit on my last upload.
<bac> rbasak: do you have a link to the one for the ubuntu archive?
<bac> i never can find those things
<rbasak> looking
<rbasak> bac: https://code.launchpad.net/~ubuntu-branches/ubuntu/utopic/juju-quickstart/utopic
<rbasak> bac: note that the UDD importer is a little broken and this branch is not always kept up-to-date.
<rbasak> So it's best to manually check. It looks good to me right now at least.
<bac> rbasak: i've created a packaging-trunk and a novel packaging branch for before trusty.  however when i try to specify the pre-trusty branch in the build recipe, the merge rule gets changed to 'merge lp:juju-quickstart' without my branch specifier.  have you seen this behavior before?
<bac> rbasak: the recipe is at https://code.launchpad.net/~juju-gui-charmers/+recipe/juju-quickstart-pre-trusty-daily
<rick_h_> hatch: have interwebs today?
<frankban> rogpeppe: could you please review https://github.com/juju/juju/pull/61 ?
<rogpeppe> frankban: looking
<frankban> rogpeppe: thanks!
<hatch> rick_h_ still hotspotting :)
<rick_h_> hatch: :(
<hatch> they probably have to run new lines the guy said
<bac> rbasak: is 'packaging' a special name?
<rick_h_> ouch, what did you do? Let the gophers at your house?
<bac> hatch: catv or fiber?
<hatch> bac, probably cat3, apparently the neighbourhood doesn't have fiber yet
<hatch> I'm just hoping the line is broken in someone elses yard
<frankban> bac: the recipe should include something like "merge packaging lp:juju-quickstart/packaging" where lp:juju-quickstart/packaging is the branch containing the pre-trusty debian stuff
<rogpeppe> frankban: reviewed
<bac> frankban: yes, but i need two branches, one for pre-trusty and one for trusty and beyond
<bac> frankban i have named those branches "packaging-pre-trusty" and "packaging-trunk"
<bac> frankban: if i specify them in the recipe they are rejected and replaced with lp:juju-quickstart
<frankban> bac: so we need two recipes
<bac> frankban: yes, i have two recipes
<rogpeppe> frankban: do you remember what we decided to do about HTTPSuite?
<bac> frankban: what i am describing is the recipe editor javascript is not accepting the branch name
<frankban> rogpeppe: I believe that suite has been already movet to testing, and we need to remove http.go in juju, right?
<bac> frankban: if i enter 'merge packaging lp:juju-quickstart/packaging-pre-trusty' it becomes 'merge packaging lp:juju-quickstart'
<frankban> bac: weird...
<rogpeppe> frankban: oh, cool
<rogpeppe> frankban: so it has
<bac> abentley: do you know the internals of launchpad build recipes?
<frankban> bac: so maybe we need to put packaging branches in a different series? https://code.launchpad.net/juju-quickstart
<abentley> bac: Once I did, but it's been a long time.
<bac> abentley: when i try to enter my packaging branch into the recipe editor, it rejects my packaging branch name and replaces it with just the project path.
<abentley> bac: paste me what you're trying to enter.
<bac> abentley: http://paste.ubuntu.com/7623848/
<bac> abentley: i think i see the problem.  the branch i'm specifying is incorrect. nm.
<abentley> Ah, that makes some sense.
<bac> abentley: the previous version used lp:juju-quickstart/packaging where 'packaging' was a series not a branch.
<rick_h_> jujugui call in 10 kanban please
<frankban> bac: once packages are built with the new configuration, could you please update the HACKING file to reflect the new PPA release process?
<rick_h_> jujugui call in 2
<bac> frankban: yes, once it is settled.
<rick_h_> kadams54: ^
<kadams54> on my way
<rick_h_> jujugui updated doc to propose two date ranges. 21-25 would be the whole team. If you've got time off planned please submit it and let me know
<rick_h_> jujugui also note I'm not getting emails from the new hr system so if you file time off ping me to approve please. I see Makyo's stuff in there right now but got no email
<hatch> rick_h_ I checked the flights, look like there is one which gets me back in time and I don't have to miss any of Friday 
<hatch> so as long as that flight stays available
<hatch> ya know....because I'm sure you were just super concerned and all that 
<rick_h_> :) 
<rick_h_> hatch: hey, I'm looking out for all my buddies 
<hatch> yay!
<hatch> heh rick_h_  did you see they changed the ES6 module spec again lol
<rick_h_> hatch: :) yea noticed that
<hatch> I think they are for the better....so that's good, but still funny
<rick_h_> yea, the joys of following stuff in progress
 * rick_h_ goes for lunchables
 * rogpeppe is done for the day
<rogpeppe> g'night all
<rick_h_> night rogpeppe 
<rick_h_> kadams54: ping, got a sec?
<kadams54> rick_h_: sure, what's up?
<rick_h_> kadams54: can you do me a favor, I need to get the list of categories from the charms. We can get all the data via http://manage.jujucharms.com/api/3/search/?text=charm&min_score=0&limit=5000
<rick_h_> kadams54: just need to loop it, find and unique the categories values please
<kadams54> Will do
<rick_h_> kadams54: ty much
<hatch> "call stack exceeded" -  no you're just not trying hard enough
<rick_h_> :P
<hatch> :D
<hatch> debugging recursive functions is a lot of work
<Makyo> jujugui I'm not having any luck with tests on this branch, any thoughts? https://github.com/juju/juju-gui/pull/373
<Makyo> I changed the order in which things were added to the DOM, but since everything's selected within the method, finding what to stub is hard.
<rick_h_> Makyo: honestly, I still think it's a comment/qa and we go along. It's going to be darn near impossible to really have a good test that directs back to this
<Makyo> rick_h_, alright, that makse sense.  I'll flesh out comments.
<rick_h_> Makyo: thansk
<rick_h_> bac: ping
<bac> hey rick_h_
<rick_h_> bac: quick charmworld ? for you. I'm trying to get a lsit of all the categories that any charm declares. The api results only show the normal set and I bet it's because we ignore the ones we don't recognize. Can you verify that?
<bac> ok
<rick_h_> ty bac 
<bac> rick_h_: yep, if the category is not in the OFFICIAL_CATEGORIES list we toss it: http://paste.ubuntu.com/7624639/
<bac> that is from the Charm model class
<rick_h_> bac: :( ok thanks
<rick_h_> kadams54: ok, next step please
<kadams54> rick_h_: ready
<rick_h_> kadams54: so to get this info we'll have to loop through that charm list, build the file api call to the metadata.yaml, and then find the categories out of it 
<rick_h_> kadams54: example: http://manage.jujucharms.com/api/3/charm/precise/apache2/file/metadata.yaml
<rick_h_> kadams54: so loop, get metadata.yaml, load, output categories, next 
<hatch> well they have started running new cable
<kadams54> rick_h_: got it
 * hatch hopes all the conduits are clear
<rick_h_> hatch: trencher time!
<rick_h_> kadams54: ty much
<hatch> nah they run conduits here 
<hatch> they think ahead lol
<rick_h_> I <3 api
<hatch> rick_h_ now if the conduit is collapsed or plugged....well then we have problems
<hatch> brb rebooting
<Makyo> Going to run last night's carload to the new house over lunch, back in a few.
<hatch> anyone know what would cause a git push to fail with 
<hatch> Permission denied (publickey).
<hatch> fatal: Could not read from remote repository.
<hatch> it doesn't even ask for the password to unlock the keychain
<rick_h_> hatch: wrong .git/config ?
<hatch> rick_h_ well nothing has changed since yesterday...
<rick_h_> hatch: I'd argue something has :)
<rick_h_> hatch: push is going where you don't think it is or something?
<hatch> I can't even show the origin details
<hatch> github is last showing my key used today
<hatch> so the 'fix' was to go and delete old unused keys from GH
<hatch> umm thanks GH?
<rick_h_> hah
<hatch> jujugui looking for a review and qa on the cache branch https://github.com/juju/juju-gui/pull/372
<bac> rick_h_: did you reply to my comment above? (internet dropped briefly right after i sent them.)
<rick_h_> bac: which comment above?
<bac> the one where i said all was ok with juju-qs 1.3.4.b1 on a variety of platforms and i'd like to release 1.3.4
<hatch> that didn't make it  :)
<rick_h_> bac: yea, didn't make it to the channel
<bac> well, hell
<rick_h_> bac: ok, so then this is the official release of quickstart with OSX support?
<bac> rick_h_: it looks like our brute force packaging approach is working.  i have 1.3.4.b1 working via pip, brew, pre-trusty PPA and trusty-and-beyond PPA.  i did not do full QA on all of those but everywhere i've tested it works.
<bac> 14:08
<bac> rick_h_: i'd like to release 1.3.4 on all of those mechanisms now
<hatch> kadams54 will you be around in an hour? I'm going to take lunch then look at huw's bug so I'll probably have some q's
<kadams54> Yeah, I'l be here.
<bac> rick_h_: yes, it will have OS X support and is a pre-cursor to actually getting the brew formula accepted into their ecosystem
<hatch> while I'm gone https://github.com/juju/juju-gui/pull/372 :)
<rick_h_> bac: +1 then on release. You've got QA from others?
<rick_h_> hatch: will try, kadams54 or Makyo ? ^
<kadams54> hatch: will take a look at it shortly.
<bac> nope.  as i said, i did a full QA on 1.3.3 and have done spot checks on the different types of systems (pip, brew, pre-trusty PPA, trusty PPA)
<bac> rick_h_:  ^^
<bac> QA from others would be swell
<rick_h_> bac: ok, let's get another QA then before release. Target it for tomorrow? 
<rick_h_> I'll try to QA after this bit here and maybe get hatch or Makyo to do another as well as other OSX users
<rick_h_> bac: I saw a branch go by with the qa docs in there? Is there a branch we should use to QA off of? 
<bac> i'll be kadams54 would love to
<rick_h_> lol
<bac> rick_h_: trunk/HACKING.rst has a QA section
<rick_h_> well kadam's volunteer to look at hatch's so spread the love 
<rick_h_> bac: cool
<bac> OS X will have to be via pip
<kadams54> bac: I presume this is around juju-quickstart for OS X?
<bac> kadams54: yep
<kadams54> bac: I can dive into it after I finish working with hatch.
<rick_h_> bac: yep, that's not an issue
<bac> thanks
<kadams54> bac: Are there QA instructions somewhere?
<rick_h_> kadams54:  trunk/HACKING.rst has a QA section
<bac> kadams54: yeah, let me grab an URL
<rick_h_> I can copy/paste fast :) 
<rick_h_> bac: just link him to the branch as he'll have to bzr branch it anyway right?
<bac> kadams54: http://bazaar.launchpad.net/~juju-gui/juju-quickstart/trunk/view/head:/HACKING.rst
<kadams54> OK, will take a look
<bac> rick_h_: no.  this QA should be done via our install providers, i.e. pip, apt, brew (except not brew)
<bac> i made that up.  should've said 'our many and varied package management systems'
<rick_h_> bac: ah ok, so your branch is up then on pypi as the b1 package and use that to test?
<kadams54> hatch: I also have https://github.com/juju/juju-gui/pull/375 for you to look over
<bac> rick_h_: yes, it is on pypi and the juju-quickstart BETA PPA
<rick_h_> bac: gotcha ok cool then
<rick_h_> kadams54: CI failure looks like some sort of cleanup/race
<rick_h_> jujugui I'm stepping out, will do quickstart qa tonight bac. 
<rick_h_> kadams54: thanks for the help with the research today. 
<kadams54> rick_h_ np
<bac> rick_h_: ok.  have fun.
<hatch> kadams54 thanks for the qa - any review notes?
<hatch> hmm github must be having some issues or something
<hatch> my profile pictire is gone now too
<hatch> wth
<hatch> Makyo's and huw's are gone too
<hatch> odd
<hatch> annnd my tests aren't running
<hatch> jujugui does anyone know why CI wouldn't run an update to a PR?
<hatch> or how I would even go and debug it?
<hatch> kadams54 your branch has a test failure, I'll wait until that's resolved to take a look at it
<kadams54> hatch: I believe that's a race condition
<kadams54> I haven't had a chance to rebuild but rick_h_ mentioned that earlier
<kadams54> So ignore it :-)
<hatch> no this is different than the spurious failure
<kadams54> You looking at build #1194?
<hatch> 1193
<hatch> https://github.com/juju/juju-gui/pull/375
<hatch> Oo the new lines didn't fix the internet....awesomer!
<kadams54> 1193 does not seem like a legit failure to me
<hatch> ok I'll queue up to re-run it
<kadams54> I already re-queued
<hatch> oh woops we both did heh
<hatch> kadams54 if you use /origin/pr/375/merge then it'll do the PR not just the single commit
<hatch> just fyi
<kadams54> Ah, good to know
<hatch> so is my branch good to land if it passes the tests?
<hatch> oh look at all those failures in IE that my branch caused
<hatch> party on
<hatch> and they pass locally
<hatch> awesomer
<hatch> kadams54 your failure happened again
<kadams54> Yeah, get them to pass in IE and I'm good with it landing. I didn't review it since rick_h_ seemed to have that covered.
<hatch> identical
<hatch> http://ci.jujugui.org:8080/job/juju-gui/1195/console
<hatch> ok cool, thanks
<kadams54> Yeah, I see it.
<kadams54> Doesn't mean I understand it or think it's legit :-)
<hatch> haha well try and reproduce it locally
<hatch> I can give it a go in a bit
<hatch> looks like I might have internet again
<kadams54> All tests pass locally
<hatch> ok I'll give it a try in a bit
<hatch> and the CI isn't picking up my shipit
 * kadams54 thinks CI needs a good swift kick
<hatch> I'm with you there
<hatch__> hmm I'm on real internet now
<hatch__> lets see if this lasts lol
<hatch__> kadams54 when is your EOD? I'd like to get this chat in before, it's looking like they will be done here in about 20
<hatch> kadams54 ok I'm ready whenever you are
<kadams54> hatch: you still around?
<hatch> of course!
<kadams54> OK, I'm available to chat
<hatch> ok gimme a couple mins to get the dogs in
<kadams54> woof
<hatch> kadams54 ok I'm in the standup room
<kadams54> OK
<rick_h_> hatch: I wonder if your issue was due to github's issues this afternoon
<hatch> github had issues?
<rick_h_> hatch: the CI stuff is pushed via github hooks and if they flake out they no worky
<hatch> ohh
<hatch> gotcha
<rick_h_> yea, github was down for a chunk of time today. Didn't you see twitter make all the jokes about it? :P
<hatch> haha no I was on limited bandwidth so I didn't check it often
<hatch> I am now back up to full bw :)
<rick_h_> woot
<rick_h_> wait..now I'll have to see you in hangouts! :P
<hatch> haha sucker!!
<rick_h_> hatch: did you get back with huw about his question?
<hatch> kadams54 and I are arguing about it now
<rick_h_> hatch: lol
<Makyo> Well this is neat: https://github.com/dspinellis/unix-history-repo
<rick_h_> hatch: ok
<hatch> we are on the same side so this is a shitty argument
<hatch> lol
<Makyo> Never thought I'd see "34 years ago" on github.
<rick_h_> Makyo: is your branch up for landing? I'm trying to take stock of our odds of doing the release this week
<Makyo> rick_h_, It should be good to land, want me toshipit?
<rick_h_> Makyo: yea, sounds good to me
<rick_h_> hatch: so tomorrow then let's chat about were we stand for IL flag release and make sure we've got everything unblocked to kill that off. We can move the cleanup cards to after the release as maint and do them as thurs/friday cards
<hatch> rick_h_ yeah, atm I'm just trying to get the cards in review unblocked and commented on and whatnot - but as far as I know the only real blockers are the two reds after the il green
<hatch> I can look more and qa in the morning
<hatch> rick_h_ huws branch is landing now
<hatch> kadams54 and I couldn't argue with ourselves enough to make us change our mind :D
<kadams54> Or we just dismissed ourselves as crotchety purists who would never be able to ship something.
<rick_h_> hatch: heh ok I won't ask
<hatch> lol!!!
<rick_h_> hatch: the one about the two inspector calls isn't a blocker correct? I mean it did that back before the inspector was moved
<rick_h_> hatch: so the only blocker I consider is the bug with the home action by clicking the icon 
<rick_h_> hatch: so I'd suggest that as the next card for someone for tomorrow then?
<hatch> rick_h_ I'm ok with that - we can probably release Thursday if we can get some good QA in tomorrow afternoon and Thursday morning
<rick_h_> hatch: I'd like to hopefully start the release process tomorrow if we can. I thin the one bug is a small state change one
<rick_h_> hatch: I'm worried starting thurs will have something push us to friday 
<hatch> rick_h_ I'm not convinced that there has been enough dedicated QA'ing to do a release tomorrow
<rick_h_> hatch: ok, let's ask huw tonight and have our MV friends pause and help with QA tomorrow
<hatch> sounds excellent
<rick_h_> kadams54: ^
<kadams54> got it
<rick_h_> kadams54: thanks, so the plan is to pause WIP and QA with no flags tomorrow as much as we can do. Different browsers, live environments, sandbox, etc. 
<kadams54> ok
<rick_h_> if we can get both the quickstart release and gui release out this week I'll be doing a happy dance 
<hatch> kadams54 +1 btw just doing QA now
<hatch> oops qa failure
<kadams54> rick_h_: Ah that reminds me, I need to look at quickstart tonight.
<kadams54> hatch: what did you run into?
<rick_h_> kadams54: yea, same here. That'll be after the boy goes to bed though
<hatch> kadams54 commented in the PR
<kadams54> The kids are at the grandparents this week and next, so I have oodles of free time.
<hatch> ooooooeeeee
<hatch> shouldn't have said that!!!
<hatch> lol
<kadams54> :-)
<kadams54> The QA error is because I made the change to listen to *:createMachine events at a higher level, where all header events will bubble up
<kadams54> But I haven't yet implemented adding new containers
<kadams54> That's my WIP card
<kadams54> So it'll be addressed in that branch.
<hatch> ohh ok, can you reply in kind in the PR
<kadams54> Yeah
<rick_h_> hatch: sent an email to peeps, if you see huw please mention it
<kadams54> LOL
<kadams54> Nice work hatch ;-)
<hatch> IT"S BACK OPEN!!!!
<hatch> lol
<hatch> rick_h_ ok will do thanks
<huwshimi> Morning
<hatch> morning huwshimi 
<huwshimi> hatch: Hey
<hatch> huwshimi some developments today - your branch was landed, and we'd love it if you could do a good qa without any flags so we can get a release out 
<huwshimi> hatch: OK, I can do that. This is releasing the il etc? but not mv?
<hatch> right, so qa with no flags
<hatch> new state and il stuff is not flagged any longer
<huwshimi> OK will do!
<hatch> jujugui looking for a review/qa on a super trivial fix https://github.com/juju/juju-gui/pull/376
<kadams54> Looking
<hatch> thanks
<kadams54> hatch: looks good, replied in PR.
<hatch> thanks, and shippped
<hatch> now lets just hope qa comes back clean :)
<hatch> ok going to sit down....been standing all day, damn standing desk setup
<hatch> hah!
#juju-gui 2014-06-11
<huwshimi> hatch: This bug still exists: https://bugs.launchpad.net/juju-gui/+bug/1321558
<_mup_> Bug #1321558: Destroying a service leaves inspector visible <juju-gui:Triaged> <https://launchpad.net/bugs/1321558>
<huwshimi> hatch: Also, your caching branch is lovely!
<rick_h_> huwshimi: hmm, that was marked as fixed. The card for that was done by Makyo 
<huwshimi> rick_h_: Was the one for hiding the ghost inspector on deploy?
<huwshimi> *that the
<rick_h_> huwshimi: no, that bug you linked above on the destroying leave the inspector open
<rick_h_> huwshimi: moved the card into urgent maint. 
<rick_h_> Makyo: ^ 
<huwshimi> rick_h_: Oh, I mean, didn't Makyo do the one about hiding the ghost inspector on deploy
<rick_h_> huwshimi: not sure, I just did a search on the bug number in the kanban board and found the card
<huwshimi> oh I see
<rick_h_> I'll have to chase down the branch that was submitted and see what is up
<rick_h_> huwshimi: but please make sure to note that one and the card in an email summary of the QA results please
<hatch> huwshimi thanks :)
<huwshimi> rick_h_: Will do, I have some small visual cleanups that I'll do myself today
<rick_h_> huwshimi: awesome thanks
<hatch> is comingsoon very slow for you guys?
<hatch> oh maybe it's just me
<rick_h_> hatch: no
<hatch> huwshimi in your bug, how do you reproduce it?
<hatch> can you add steps because I am not able to reproduce on comingsoon
<huwshimi> hatch: I've added them to the bug: https://bugs.launchpad.net/juju-gui/+bug/1321558
<_mup_> Bug #1321558: Destroying a service leaves inspector visible <juju-gui:Triaged> <https://launchpad.net/bugs/1321558>
<hatch> huwshimi thanks, the bug only happens with ghost services not deployed ones
<hatch> should be an easy fix the url isn't changing so just needs to fire a changestate event
<hatch> good catch though
<huwshimi> hatch: Ah yes, you are right. I thought I had reproduced it on a deployed service, but can't seem to now.
<hatch> yeah, just looked, huwshimi  if you have time today you could probably bang out a fix for it real quick-like :)
<hatch> think you might have time?
<hatch> if not I can probably do it while watching some tv tonight heh
<hatch> huwshimi here is the fix (sans tests) https://gist.github.com/b85f7d0ebdbf05ee0632
<hatch> :)
<huwshimi> hatch: It's ok I'll do it
<rick_h_> hah! just used the chrome dev tools "copy a cURL" feature. sweetness
<huwshimi> hatch: Unless you get to it first :)
<hatch> rick_h_ haha cool, I've always wanted to use that :)
<hatch> huwshimi true, although I have to start cooking supper right away so it won't be for a few hours for sure
<rick_h_> needed a QA bundle file so went to the gui, went to code, loaded the bundle file and copied the curl command from the network tab to download it :)
<hatch> keep me posted if you do tackle it
<hatch> haha nice nice
<huwshimi> hatch: Yep, I'll let you know if I start
<rick_h_> bwuhahaha BradCrittenden you rule. <3 this
<rick_h_> 920563
<hatch> huwshimi I'm going to fix that bug now
<huwshimi> hatch: OK :)
<hatch> just watched some House of Cards and Orange is the new Black
<hatch> need a break
<hatch> lol
<rick_h_> lol
<hatch> huwshimi bug is fixed if you want to take a look for review/qa if you find some time
<huwshimi> hatch: Ah sure, let me take a look
<hatch> huwshimi I'm hopping offline, if alls good feel free to shipit
<huwshimi> hatch: Sure
<hatch> thanks, have a good night
<huwshimi> hatch: You too
<frankban> morning rogpeppe1: is juju/charm ready to be used?
<rogpeppe1> frankban: yeah
<rogpeppe1> frankban: i'm just about to push a branch that changes juju-core to use it
<frankban> rogpeppe1: cool
<frankban> rogpeppe1: could you please review https://github.com/juju/juju/pull/73 ?
<rogpeppe1> frankban: looking
<frankban> thanks
<rogpeppe1> frankban: the PR doesn't seem to update dependencies.tsv - is that because it's been done in a previous PR?
<frankban> rogpeppe1: yes, http.go was moved to external testing some days ago
<rogpeppe1> frankban: LGTM then
<frankban> rogpeppe1: thanks
<frankban> rogpeppe1: I'll start the store migration right after you merge your current branch
<rogpeppe1> frankban: cool. am currrently running the tests.
<rogpeppe1> frankban: https://github.com/juju/juju/pull/74
<frankban> rogpeppe1: looking
<frankban> rogpeppe1: could you please create a juju/store repo and give me permissions?
<rogpeppe1> frankban: sure
<rogpeppe1> frankban: i wonder if the repo should be named "charmstore". what do you think?
<frankban> rogpeppe1: it will also be a bundle store in the future. So I guess store can be ok, but that's not a strong opinion
<rogpeppe1> frankban: bundles are bundles of charms, really
<rogpeppe1> frankban: i'll raise it in #juju-dev
<frankban> rogpeppe1: yeah
<frankban> rogpeppe1: what about github.com/bmizerany/assert and deps? were they missing?
<rogpeppe1> frankban: yup
<frankban> rogpeppe1: LGTM
<rogpeppe> frankban: i've created the repo and added juju-hackers as collaborators
<rogpeppe> frankban: github.com/juju/charmstore
<frankban> rogpeppe: cool, thanks. I'll wait for your branch to land and then start mgrating the store
<frankban> rogpeppe: you have a conflict
<rogpeppe> frankban: oh, darn
<frankban> rogpeppe: how is it going?
<rogpeppe> frankban: running tests again after merging
<rogpeppe> frankban: worker/uniter/debug just timed out
<frankban> rogpeppe: :-/
<frankban> rogpeppe: some of the tests seems to have some weakness
<rogpeppe> frankban: but just passed when i ran it again
<rogpeppe> frankban: yeah
<rogpeppe> frankban: it took 0.2s to run the second time
<frankban> rogpeppe: heh
<rogpeppe> frankban: my computer just decided to reboot randomly
<frankban> :-/
<rogpeppe> once upon a time if the kernel panicked, you'd see some kind of a message
<frankban> rogpeppe: so what do you think about this plan: I will 1) migrate store 2) add README etc... 3) change core to use external store in the few places it is imported. You a) wait for 2 (add README etc) b) add to charmstore the server entry points (e.g. cmd/charmd/main.go), including README updates on how to start the charmstore server and c) remove those bits from core
<frankban> rogpeppe1: ^^^
<rogpeppe1> frankban: i haven't seen anything, sorry
<frankban> rogpeppe1: so what do you think about this plan: I will 1) migrate store 2) add README etc... 3) change core to use external store in the few places it is imported. You a) wait for 2 (add README etc) b) add to charmstore the server entry points (e.g. cmd/charmd/main.go), including README updates on how to start the charmstore server and c) remove those bits from core
 * rogpeppe1 thinks
<rogpeppe1> frankban: how about, instead, migrating store and cmd/{charmd,charmload,charm-admin} all together. then there's nothing in core that imports store
<rogpeppe1> frankban: because those commands feel like they're more part of the charm store than juju-core itself
<rogpeppe1> frankban: i will suggest that in #juju-dev
<frankban> rogpeppe1: charm-admin depends on juju/cmd. That said, the result is the same, b) and c) are about doing that move. My proposal is just to proceed with incremental steps, so that mechanical branches are really mechanical
<frankban> rogpeppe1: so, focus on the goal of having an external store, and then move the commands where they belong
<rogpeppe1> frankban: ah, i see
<rogpeppe1> frankban: yeah, your approach seems fine
<frankban> rogpeppe1: cool
<frankban> rogpeppe1: uhm: your merge failed: godeps: cannot parse "/mnt/jenkinshome/jobs/github-merge-juju/workspace/tmp.o7sFxEIu8x/RELEASE/src/github.com/juju/juju/dependencies.tsv": cannot find directory for "github.com/bmizerany/assert": not found in GOPATH
<rogpeppe1> frankban: oh frick
<rogpeppe1> frankban: thanks
<rogpeppe1> frankban: i'll remove that dependency for the time being
<frankban> rogpeppe1: +1
<BradCrittenden> morning rick_h_
<frankban> rogpeppe1: created the cards for the plan above
<rogpeppe1> frankban: lovely, ta
<rick_h_> bac: morning
<bac> hi rick_h_.  what was your message from last night about?  the discussing in vague terms my awesomeness.
<rick_h_> bac: QA went well for me yesterday. Had one note where if the terminal window is small, and you go in to 'use' one of the environments, you have to scroll down with the down arrow before you can select buttons
<rick_h_> bac: oh, just was so cool to deploy a bundle and such from OSX. 
<bac> yeah, pretty sweet
<bac> rick_h_: is that term size issue os x specific or would that be the case on linux too?
<rick_h_> bac: I think it'll be any terminal. I don't notice it because of the bigger display/terminals I use on linux vs OSX the default is so small
<rick_h_> bac: so I was debating about filing a bug and wanted to see if anyone else ran across it during qa
<bac> rick_h_: i tested the interactive stuff when i first started the process but have not made it a part of general QA as the interactive piece has been static.  so i'm glad you saw this issue.
<rick_h_> bac: just tried it out here on linux and yep, it's just a general thing with the UI. I happened to have a terminal of *just* the right height where I could seee the buttons, but there was a small amount of scoll available
<rick_h_> bac: so definitely nothing block about and not even sure it's something we can do something about
<frankban> rick_h_: we can make the buttons always visible (like the status bar): I would consider this a minor/nice to have and not a release blocker.
<rick_h_> frankban: cool, I'll file a bug then for now.
<rick_h_> bac: but QA went well for me and was very exciting to try out after writing docs and emails all day :)
<bac> rick_h_: cool.  i'll wait for kyle to have a go and then do the release if all is good.
<rick_h_> bac: sounds good
<bac> frankban: if you have a moment could you review https://codereview.appspot.com/103310043  -- it has updates to the HACKING doc for new release procedures.  You may want to read the whole section carefully, not just the changes in this branch.  I've landed a few mods there self-reviewed.
<frankban> bac: I will
<frankban> rogpeppe1: could you please take a look at https://github.com/juju/charmstore/pull/1 ?
<rogpeppe1> frankban: looking
<rogpeppe1> frankban: LGTM
<frankban> rogpeppe1: thanks
<frankban> rogpeppe1: another one? https://github.com/juju/charmstore/pull/2
<rogpeppe1> frankban: looking
<rogpeppe1> frankban: LGTM
<frankban> rogpeppe1: thank you!
<jcsackett> morning all.
<rick_h_> morning jcsackett 
<rick_h_> jcsackett: can you assis with release today? QA/review Huw's branch and do some QA please. 
<rick_h_> assist that is
<jcsackett> rick_h_: was already planning on it--saw your email.
<rick_h_> jcsackett: ty much
<jcsackett> i'll start with Huw's branch and then start whacking the GUI. we have specific areas we're worried about?
<rick_h_> jcsackett: we're just making the inspector left release. So with no flags, just does anything in the GUI have an issue before we release and update jujucharms.com with it
<jcsackett> no flags, got it.
<frankban> rogpeppe1: last one for the store: https://github.com/juju/juju/pull/76
<rogpeppe1> frankban: cool
<rogpeppe1> frankban: looking
<frankban> thnaks
<frankban> bac: review done
<bac> ty
<rogpeppe1> frankban: LGTM
<frankban> rogpeppe1: thank you, merging
<jcsackett> rick_h_: huw's branch is good; there's no reason to hold off on shipping it, is there?
<rick_h_> jcsackett: nope thanks
<frankban> bac: replied
<hatch> github added a 'jump to file' button
<hatch> kadams54 did you see my comment on your PR?
<kadams54> I did.
 * rogpeppe1 lunches
<bac> frankban: yeah, that step was attempting to do two things: use pre-booted env and remote bundle.  i'll beef up the description.
<kadams54> Here's what I think is happening: the machine view panelâ¦ erâ¦ view has at least one child view, which means the child view's container is connected to a child node.
<kadams54> So when container.empty() is called, the child node is removed
<kadams54> And when the destructor is called on the child view, it attempts to empty its container and throws an error because there's no longer an associated DOM node.
<bac> rick_h_: the date in the first sentence of https://docs.google.com/a/canonical.com/document/d/1PI4XPNxVUP3mXqce-jxtT5KgqdZoTuvJZ71W-mSiCZg/edit  does not match the later date
<kadams54> getDOMNode returns null
<hatch> kadams54 right, but there should be no child view rendered into the createMachine view
<hatch> if there is then something is wrong
<hatch> create machine view should be managing it's own child views (if there are any)
<kadams54> I think there are quite a few child viewsâ¦ machine headers, service scale up, create machine, etc.
<kadams54> The one that started erroring when I changed to container.empty() was service-scale-up-view.js
<hatch> yeah....but create machine and scale up are siblings
<hatch> not parent/child
<kadams54> Maybe, but not in the DOM
<hatch> well then the DOM structure is incorrect
<hatch> you can't have sibling views that require one to be rendered into the other
<kadams54> machine-view-panel.js, line 848 - the view passes a node as the container for ServiceScaleUpView
<kadams54> That node is a child of MV's container
<hatch> right
<hatch> so why does another child of machine-view-panel destroy that node?
<kadams54> Another child doesn't destroy it
<kadams54> machine-view-panel itself destroys it, when container.empty() is called in machine-view-panel's destructor
<bac> kadams54: you still willing/have time to do the quickstart QA this morning?
<kadams54> bac: Yeah, I started on that last night
<bac> oh, cool
<hatch> kadams54 no the empty() is called in 'createMachineView' not 'machineViewPanel'
<hatch> kadams54 https://github.com/juju/juju-gui/pull/375/files#r13618728
<rick_h_> bac: ty, updated
<kadams54> hatch: Ah, that's my problem :-) For some reason I changed line 901 in machine-view-panel.js :-)
<hatch> lol oh boy
<jcsackett> rick_h_: one minor bug that i believe is linked to inspector left https://bugs.launchpad.net/juju-gui/+bug/1328932
<_mup_> Bug #1328932: "tutorial" link under "help & feedback" sends you to /sidebar and does nothing <juju-gui:New> <https://launchpad.net/bugs/1328932>
<jcsackett> not remotely done looking yet.
<rick_h_> jcsackett: rgr, ty looking
<hatch> rick_h_ jcsackett I'll take it
<rick_h_> hatch: rgr ty
<bac> frankban: here is a new section http://paste.ubuntu.com/7628821/  - i've tested that the steps work.
<hatch> hmm looks like onboarding can never BE rendered any longer, good catch jc
<frankban> bac: looks good
<hatch> rick_h_ low priority but should probably get some new assets from UX https://bugs.launchpad.net/juju-gui/+bug/1328936
<_mup_> Bug #1328936: onboarding now puts the inspector in the incorrect location <juju-gui:New> <https://launchpad.net/bugs/1328936>
<rick_h_> hatch: oh ouch, yea. Not sure I agree on low priority though
<rick_h_> luca: ^
<luca> rick_h_: ah yeah
<rick_h_> luca: I feel like that should block our release today. 
<luca> rick_h_: if I remember right, they are just images that Spencer made.
<rick_h_> hatch: what's the file name? 
<luca> rick_h_:  is that correct?
<rick_h_> luca: correct
<rick_h_> I'm trying to find the one we're using right now
<hatch> umm, I broke it, lemme get it back working and grab the file name :)
<hatch> juju-ui/assets/images/non-sprites/onboarding/3-inspector.png
<hatch> rick_h_ luca  the issue we will have though is that the charmbrowser will be rendered underneath the new inspector image
<hatch> so it's more work than simply changing the image
<rick_h_> hatch: oh, but we can work with this image
<rick_h_> hatch: we just have to relocate it and cover the sidebar
<hatch> it'll only cover part of it
<hatch> which may look worse :)
<luca> rick_h_: Spencer can create a new image of the inspector
<rick_h_> right, but I mean cover the sidebar (entirely) and then put this image on there
<luca> rick_h_: heâs busy doing the google mocks but once heâs done he can send one over
<rick_h_> luca: ok, but we'll have a height issue regardless
<rick_h_> We have to solve this better than updating the image
<hatch> the sidebar is 100% height, so that image will need to be like 3000px tall to accommodate all screens 
<luca> hatch: I see :)
<rick_h_> right, thus we use a smaller image that's the 'top part' of a demo inspector, cover all of the sidebar and have that kindn of floating in place
<hatch> heh, a mask in a mask
<rick_h_> :)
<hatch> I foresee problems in out future
<hatch> our!
<rick_h_> huw can do it :)
<hatch> well we could create a fake service and show the inspector for that service
<hatch> that's probably going to be the end goal
<luca> rick_h_: hatch do you need me to action anything?
<hatch> rick_h_ I'm not sure we want to try and do this pre-release
<hatch> I think there will be dragons here which may end up causing us to push release
<hatch> jujugui call in dos
<hatch> jujugui call in Un
<jcsackett> rick_h_, hatch: i've got another one: https://bugs.launchpad.net/juju-gui/+bug/1328941
<_mup_> Bug #1328941: Deploying a local charm shows a compacted inspector <juju-gui:New> <https://launchpad.net/bugs/1328941>
<rick_h_> jujugui on the phone with ramm at the moment, might be late
<hatch> ok I can run it
<hatch> jcsackett ok can you make a card in urgent plx
<jcsackett> hatch: yup, marking the bug as high too. unless we feel "critical" is better.
<hatch> jcsackett high is fine, we'll do it right away either way
<hatch> jujugui call now
<rick_h_> jcsackett: ^ antdillon 
<bac> kadams54: thanks for your help doing the QA.  please ping me when you're done.
<kadams54> bac: will do
<hatch> the tow truck drivers are driving around and honking the horn in front of peoples cars to get them to move it before they tow it....that's pretty nice
<hatch> I mean...the big yellow signs have only been here for 5 days....
<hatch> but still nice :)
<hatch> jujugui lf a review/qa for https://github.com/juju/juju-gui/pull/379 plz and thx
<frankban> hatch: looking
<hatch> thanks
<hatch> jcsackett looking at your screen shots remind me of what internet was like in the 90s :P
<jcsackett> hatch: yeah; it's something weird with shutter.
<jcsackett> i get great screenshots, and then the moment shutter does anything with them, they turn into horribly compressed jpegs without any chance of recovering them.
<frankban> hatch: when I visit a charm details page and then close the panel, the onboarding is shown. Is that the expected behavior?
<jcsackett> i haven't figured out what's going on--it didn't used to have this issue.
<hatch> frankban if you dismiss it once then that doesn't happen, correct?
<frankban> hatch: yes
<hatch> frankban tough to say.... luca ^
<hatch> frankban I'm pretty confident that that is how it should stay...
<frankban> hatch: ok
<hatch> you don't want to necessarily miss out on the onboarding just because you clicked a link to view some charm details
<hatch> at least thats my reasoning
<luca> hatch: frankban you mean that when you visit Juju for the first time and youâve been linked to a charm details and you close the details the onboarding shows?
<hatch> luca no if you click a link to charm details
<hatch> but you've never been to juju before
<hatch> we show the details w/o the onboarding
<hatch> but when you then close those details, we show the onboarding
<frankban> luca, hatch: I think you are describing the same path...
<hatch> oh.....yeah, I read it wrong
<frankban> and you are both right
<hatch> English is hard...
<hatch> lol
<luca> hatch: rofl
<luca> frankban: hatch that is expected behaviour
<hatch> haha yay
<frankban> cool
<frankban> hatch: then QA is good
<hatch> sweet shippin!
<hatch> frankban actually, can you comment on the PR THEN i'll ship :)
<hatch> there it is!
<frankban> hatch: done
<hatch> hmm this local inspector business is probably gona be some work
<hatch> poo
<jcastro> https://bugs.launchpad.net/ubuntu/+source/juju-quickstart/+bug/1317939
<_mup_> Bug #1317939: New upstream release 1.3.2 is available <upgrade-software-version> <juju-quickstart (Ubuntu):Triaged> <https://launchpad.net/bugs/1317939>
<jcastro> can I get some eyeballs here so we can get this fixed in utopic so we can get it backported to trusty?
<rbasak> jcastro: I'm your guy. I've been working on this for a while.
<rbasak> jcastro: there have been process issues getting in the way, and I've been working on resolving them permanently.
<rbasak> jcastro: right now the blocker is that juju-core ftbfs on utopic on powerpc, and I need this to land in utopic to fix juju-quickstart in utopic, and with that I'll be able to SRU to Trusty.
<jcastro> rick_h_, <patrick-uds> QUESTION: do you plan to make it possible to deploy a bundle with containing local charms in juju-gui?
<jcastro> rick_h_, I will ask you during the wrap up
<hatch> luca do the local charm inspectors also go 100% height in the left column? (thinking so, just want to confirm)
<luca> hatch: they do
<jcsackett> juju-gui: anyone QAing on safari?
<hatch> luca thanks
<hatch> jcsackett giver'
<jcsackett> hatch: huh?
<hatch> jus' giver' ?
<jcsackett> i have no idea what you're saying.
<jcsackett> dialects written in text tend to fail hard. :p
<hatch> go hard?
<hatch> you can do it?
<jcsackett> ok. thanks.
<jcsackett> :)
<hatch> it's all yours
<hatch> please sir, may  you do the safari qa
 * jcsackett laughs
<hatch> :D
<jcsackett> i've never heard "giver'" before...is that "go for it", i'm guessing?
<hatch> yeah - we say it all the time when doing something stupid
<hatch> "ok dude giver'"
<rick_h_> hatch: yea, that's pure canadian nonsense :P
<hatch> haha
<hatch> I looked up the urban dictionary definition....yeah there is some messed up stuff in there
<jcsackett> juju-gui: if someone else has safari, can they please open the gui in coming soon and verify that scrollbars on the sidebar work? i'm almost certain this is my machine sucking, but we should double check.
<hatch> looking
<hatch> jcsackett working good here
<jcsackett> hatch: awesome. well, downside, i can't QA on safari b/c my macbook is *oooold*. plusside, at least the GUI isn't completely hosed on safari. :p
<hatch> haha, s'ok we have other osx'rs kadams54 bac frankban rick_h_  :D
<jcsackett> hatch: if you've deployed an older version of a service, the upgrade section in the inspector should show the newer version, right? i'm not grossly misunderstanding 'upgrade' in this context, am i?
<hatch> rick_h_ I propose we make a spreadsheet of our supported browsers/platforms and sandbox/real env and then people can put their name beside it when it qa's ok
<hatch> jcsackett no, atm it now shows every version of the charm (And some which don't exist)
<hatch> no, you're not misunderstanding it, it's just broken
<hatch> :)
<jcsackett> hatch: well, no, it seems to show every older version of the charm.
<jcsackett> hatch: ok, as long as know that's broken.
<hatch> yeah there are existing cards
<jcsackett> hatch: is the upgrade path one then not something we're QAing? b/c there seems to be an inspector left issue in it as well if you actually click upgrade.
<hatch> hmm.....
<jcsackett> though triggering it is hard, since most of the time clicking "upgrade" doesn't seem to do anything.
<hatch> I'm pretty sure that should still work. But it does list charms which don't exist
<hatch> so the error may be caused by that
<hatch> jcsackett it wouldn't hurt to create new bugs though then rick_h_  can go through and mark as duplicates if need be
<rick_h_> oh sure :P
<hatch> haha, well 2 bugs is better than 0 :)
<rick_h_> hatch: all good, happy to help garden
<jcsackett> destroying services leaving machines around is a juju-core issue, right?
<rick_h_> hatch: I think the spreadsheet thing is something of formalizing the QA process we should do. I'm going to create a task for that. 
<hatch> cool
<rick_h_> jcsackett: yes, and there's a branch up for review that changes that
<jcsackett> rick_h_: cool.
<rick_h_> hatch: but I think that's a bit much for the moment 
<hatch> s'ok!
<rick_h_> ok, UOS session is done and out woot
<rick_h_> jujugui UOS session if interested https://plus.google.com/116120911388966791792/posts/aLNHXFMW5DC
<kadams54> UOS?
<jcsackett> ubuntu online summit, i think.
<hatch> rick_h_ thanks, watching
<rick_h_> what jcsackett said
<rick_h_> I'm trying to train myself to not use UDS 
<hatch> we need to do a lot better marketing of these things, I only noticed it yesterday haha
<jcsackett> hatch: i'm making a card in urgent for the upgrade bug i've found; if we decide we don't care for release feel free to alter bug and delete card.
<jcsackett> ok, i need food.
<rick_h_> jcsackett: ok, make sure you've got reproduction steps please
<rick_h_> and I also need to find food now. Phew, busy morning
<jcsackett> rick_h_: yup.
 * rick_h_ runs away for a few min
<jcsackett> rick_h_: i try to never file a bug without reproduction steps if i can avoid it.
 * jcsackett runs away in the opposite direction
 * rogpeppe1 is done for the day
<rogpeppe1> g'night all
<rick_h_> night rogpeppe1
<rogpeppe1> rick_h_: see ya
<rick_h_> jujugui wife is comandeering the mifi for part of tomorrow for dr home visits...I might be up no-net creek without a paddle. Cannot coffee shop as I have to be here during install
<rick_h_> gah! imagine a world without internet access! The horror!
<hatch> lol
<rick_h_> I'll get someone to be a meeting backup for the cross team call in case I have no net tomorrow
<rick_h_> anyway, really off to lunch
<hatch> enjoy
<bac> rick_h_: where's your real internet?
<hatch> bac it's being upgraded to add more ips
<hatch> business line or something
<bac> oh, yeah, that
<bac> i tune out people with their first-world internet woes
<hatch> lol
<kadams54> bac: sent you a PMâ¦ going to break for lunch but wanted to chat about some things I was seeing.
<bac> kadams54: sorry i was at lunch and didn't see that on my return
<kadams54> np
<bac> kadams54: do you want to do a hangout?
<kadams54> Sure
<bac> kadams54: going into daily standup
<kadams54> bac: I'm thereâ¦
<rick_h_> bac: :P definitely first world
<bac> kadams54: got kicked.  trying again
<bac> jujugui: i forked the homebrew project into https://github.com/CanonicalJS/homebrew instead of jujugui.  how do i delete the fork?  (i'm sure there is a button i'm just not seeing.)
<rick_h_> bac: sec, I might be able to move it. 
<hatch> bac go into the settings for the repo and click delete
<hatch> your fork of the repo that is
<rick_h_> bac: where do you want it to be under? /juju/homebrew?
<bac> rick_h_: jujugui/homebrew, no?
<rick_h_> do we have a jujugui user/org? 
<bac> rick_h_: yes
<bac> rick_h_: is this not a thing: https://github.com/jujugui
<rick_h_> bac: ah, that's the bot user. I'd just move it under /juju I think. We don't have any repos there. 
<bac> rick_h_: ok, that works
<rick_h_> bac: it's just a dummy user for CI interactions
<rick_h_> bac: moved
<bac> that's not unconfusing
<rick_h_> https://github.com/juju/homebrew
<bac> thanks
<rick_h_> np
<bac> rick_h_: my branch is juju-quickstart-formula
<bac> rick_h_: so this would work:
<bac> #git push git@github.com:juju/homebrew.git juju-quickstart-formula
<rick_h_> bac: is your branch a fork of that juju/homebrew.git repo?
<jcsackett> juju-gui: I have been knocked offline by a storm and my poor phone seems to not be up to the task of hot spotting today. 
<jcsackett> I go in search of internet elsewhere. 
<rick_h_> jcsackett: thanks for the heads up
<bac> rick_h_: i think brew created a branch of the original.  i'm following the directions at https://github.com/Homebrew/homebrew/wiki/Formula-Cookbook after the 'Commit' heading
<rick_h_> bac: looking
<hatch> jcsackett darn I JUST needed to have a chat with you too :)
<hatch> are you ok for ircing?
<rick_h_> bac: looks ok then
<bac> rick_h_: i get access denied.  should i be able to push there?
<rick_h_> bac: hmm, I'd expect you to as you can to the gui, /me checks
<bac> or my ssh keys are not set up
<jcsackett> hatch: yeah, i can IRC from my phone, and i'm not in the car yet. what's up?
<hatch> local charm drops use /local in the url and then convert to localType
<hatch> but there is an issue with localType being converted to /local
<hatch> so I CAN fix that
<rick_h_> bac: updated
<hatch> but is there a reason why you picked localType and not local?
<hatch> I'd really prefer to have a single name instead of a odd rename just for the url
<rick_h_> bac: they did some gardening now that core is on github. They don't follow our 'let everyone ahve admin' process
<bac> rick_h_: i had not ssh-add my novel github key
<bac> now it worked
<rick_h_> bac: awesome
<jcsackett> hatch: I think I was opposed to "local" as a variable name, since that sounds like a bool to me. 
<jcsackett> But localType is a crap URL fragment. 
<hatch> ok so are you ok with the rename just for the url?
<jcsackett> If you want to s/localType/local I'm good. 
<hatch> ok lemme think about it :)
<hatch> just wanted to see if there was some other reason
<jcsackett> No good ones, no. :p
<hatch> haha ok lemme think about it
<pitti> hello
<rick_h_> howdy pitti 
<pitti> so I was watching jcastro's UOS talk today and wanted to try juju-local again (a month or so ago it failed for me due to bug)
<rick_h_> pitti: very cool
<pitti> so I'm trying "juju quickstart" as in that tutorial; I get http://paste.ubuntu.com/7630057/ and now it's just hanging, and no running wget or similar
<jcastro> rick_h_, we're mid session so marco and I can't help right now, but if you could help point him in the right direction that would be <3
<pitti> any idea how I can check what's going on?
<rick_h_> jcastro: k
<rick_h_> pitti: what version of ubuntu are you on?
<pitti> no container was created, and strace on the jujud bootstrap is just futex-waiting
<pitti> rick_h_: utopic du jour
<rick_h_> pitti: oh, bleeding edge. We're aware of some juju/quickstart bugs that we're working on getting landed. https://bugs.launchpad.net/ubuntu/+source/juju-quickstart/+bug/1317939
<_mup_> Bug #1317939: New upstream release 1.3.2 is available <upgrade-software-version> <juju-quickstart (Ubuntu):Triaged> <https://launchpad.net/bugs/1317939>
<rick_h_> pitti: and if you look in the comment there's a bug in getting juju updated in utopic holding that up right now
<pitti> rick_h_: right, exactly that bug
<rick_h_> pitti: so I'm not sure it will work properly
<rick_h_> pitti: we're hoping juju gets updated soon and we can get our quickstart package updated and get it going
<rick_h_> pitti: you can try the quickstart beta ppa
<rick_h_> https://launchpad.net/~juju-gui/+archive/quickstart-beta
<pitti> rick_h_: ack, thanks! so I didn't just screw up :)
<rick_h_> that can get you the pending release ahead of time
<rick_h_> pitti: no, I don't think so
<pitti> I mean, not that there's a whole lot to screw up on a single command :)
<rick_h_> pitti: I think you're smacking into the stuff we're all trying to get fixed up
<rick_h_> lucky luck you :)
 * pitti installs the PPA
<rick_h_> pitti: note that I'm not sure it'll help you as the juju bug is still there, but I don't recall if that worked around the bug but our release is blocked
<pitti> rick_h_: for testing I'd be ok to create trusty containers; I hope that's what the LXC bug is about? (container release, not host release)
<rick_h_> pitti: I know the original issue was trusty containers, but the relaese is blocked on utopic builds. series series everywhere. 
<rick_h_> but the beta package should get you around the original precise container issue
<bac> rick_h_: the brew pull request has been submitted.  that project has 33 pull requests pending, dating back one week.  so i'm going to declare victory on my card, create a tracking card, and be done.
<pitti> still hanging :/ and nothing in .juju/local/log/
<rick_h_> bac: sounds good
<rick_h_> pitti: :(
<pitti> rick_h_: I suppose I'll re-try my luck with juju bootstrap etc.
<pitti> I'm mostly interested in this for working on the CI airline wrt. autopkgtest, so trusty containers are totally fine for me
<rick_h_> pitti: let me know if that works for you. My understanding is that it's a juju/utopic issue. The bug linked in https://bugs.launchpad.net/ubuntu/+source/juju-quickstart/+bug/1317939 leads through a few other bugs in juju. 
<_mup_> Bug #1317939: New upstream release 1.3.2 is available <upgrade-software-version> <juju-quickstart (Ubuntu):Triaged> <https://launchpad.net/bugs/1317939>
<rick_h_> pitti: so quickstart shouldn't be causing any issues
<rick_h_> pitti: but definitely adding a card to our board to look at qa'ing what we do have under utopic, none of us have upgraded and checked it out yet
<pitti> rick_h_: ah; I usually upgrade on day 1, dogfooding :)
<rick_h_> pitti: <3 just sorry for the complications you hit. 
<pitti> rick_h_: but I didn't see any log file etc. in .juju to see what's going on; hence my thought to call bootstrap directly, that might be a little more verbose?
<pitti> rick_h_: no worries :)
<rick_h_> pitti: --debug
<rick_h_> pitti: I think that turns on verbose bootstraping
<pitti> rick_h_: how would I manually bootstrap a "local" environment?
<rick_h_> pitti: did you create one using quickstart? 
<rick_h_> pitti: then just 'juju switch local && juju bootstrap'
<pitti> ah, right, that already creates the yaml
<pitti> hm, endless series of "juju.state open.go:101 connection failed, will retry: dial tcp 127.0.0.1:37017: connection refused" in .juju/local/cloud-init-output.log, and no lxc process or otherwise busy process
<pitti> so I guess I'll just subscribe to these bugs and wait until they get fixed :)
<pitti> thanks rick_h_ 
<rick_h_> pitti: yea, that's the juju mongo bug
<rick_h_> pitti: sorry, I think they're up for the next release next week
<pitti> sounds nice
<pitti> or I'll try it in a trusty VM
<rick_h_> pitti: +1
<pitti> rick_h_: oh, I just saw that juju-local/juju-core 1.18.4 claim to fix much of this, but are stuck in -proposed
<rick_h_> pitti: right
<rick_h_> pitti: there's some other blockers 
<pitti> powerpc build failure apparently
<rick_h_> pitti: they're working through it but not out yet
<pitti> *nod*, thanks
 * rick_h_ isn't 100% on top of it but watching it to unblock our juju-quickstart release
<pitti> rick_h_: much much better with the proposed version :)
<rick_h_> pitti: woot
<rick_h_> jujugui approval for july 21 set, will have details and such tomorrow but feel free to start planning 
<pitti> juju quickstart still defaults to building stuff for precise, but *shrug*, details :)
<pitti> and it now fails with juju-quickstart: error: machine 1 is in an error state: error: open /var/lib/lxc/martin-local-machine-1/config: no such file or directory
<rick_h_> pitti: well it uses your env for the default env
<rick_h_> bah that came out wrong
<pitti> so we have some hardcoded /var/lib/lxc/ somewhere (I have them in /scratch/lxc), but that's now much easier to tackle
<rick_h_> the default series is defined in your environments.yaml
<rick_h_> pitti: orly that one is interesting
<pitti> rick_h_: right, I wiped .juju and restarted quickstart, that wrote a new yaml
<rick_h_> pitti: ah, and that yaml uses lts as default series 
<rick_h_> ok, I'm out for the day all. I'll do my best to be available online tomorrow as much as I can. 
<pitti> filed as bug 1329049
<_mup_> Bug #1329049: quickstart fails, hardcodes /var/lib/lxc/ somewhere <amd64> <apport-bug> <utopic> <juju-quickstart (Ubuntu):New> <https://launchpad.net/bugs/1329049>
<pitti> rick_h_: good night!
<hatch> rick_h_ so I'm going to split this bug into two cards, one for the styling and one for the technical bugs
<hatch> I've fixed the technical bugs but the styling still needs work
<hatch> huw can then do that one
<bac> rick_h_: i'm having troubles with the builds for the PPA.  it is clinging to the 1.3.4.b1 name, not recognizing 1.3.4 is more current.  may have to bump to 1.3.5 if i cannot get it to update.  feels like i'm missing something.
<rick_h_> bac: oh hmm, I know pypi should treat the b1, guess that might not work in debian packaging world
<bac> yeah, pypi definitely did, requiring the --pre install flag
<rick_h_> bac: honestly, if 1.3.5 works call it. I think I might have led your wrong on that sorry
<bac> np
<hatch> jujugui I need a review/qa for https://github.com/juju/juju-gui/pull/380 before Huw starts so he can take on the second part of this card.
<kadams54> hatch: I can take a look
<hatch> ahh crap I need to remove a comment
<hatch> sec
<hatch> kadams54 ok it's ready now
<hatch> thanks
<kadams54> yup
<hatch> jujugui does anyone have a real env up?
<hatch> rick_h_ I think that we can push the other ticket from jcsackett
<hatch> the upgrade one
<hatch> oh CI, go home, you're drunk
<jcsackett> hatch: +1, upgrade is already hella broken.
<hatch> jcsackett cool, moving it out of urgent
<kadams54> hatch: what exactly should be fixed in this PR? I'm still seeing the empty sidebar after deploying the local charm.
<hatch> you sure you have cleared your cache?
<hatch> any errors in the console?
<kadams54> OK, caching issue
<kadams54> Now the only problem is the squashed inspector, which I take it is what Huw will be fixing.
<hatch> well it's just not 100% height
<hatch> it's no longer squashed
<kadams54> True
<hatch> it WAS way squashed :)
<kadams54> Alright, looks ready to ship, commented as such in the PR.
<hatch> cool - I'm going to wait for CI to pass 
<kadams54> Assuming the build gets straightened out
<hatch> it passes fine here
<hatch> so hoping it's just being it stupid self
<kadams54> EOD for me
<kadams54> See everyone later
<hatch> lata
<hatch> rick_h_ anything you want me to start on before release?
<rick_h_> hatch: can you QA/check out jcsackett's branch?
<rick_h_> hatch: and any idea on kyle/huw's branch in review? I'm guessing he didn't get that updated due to the qa/etc work today
<hatch> oh look at that
<hatch> for sure
<hatch> I THINK that one has landed
<hatch> ....
<hatch> he has nothing in the PR queue
<rick_h_> hatch: oh hmm ok coolio then
<jcastro> hey fellas
<jcastro> wrt. "we should export bundle.yaml"
<rick_h_> jcastro: disagree?
<jcastro> yeah
<jcastro> but it's only step 1
<jcastro> I wonder if there's a bug for
<jcastro> "envExport" 
<jcastro> like, ideally
<rick_h_> yes, there's a bug to allow the user to select a name on export
<jcastro> I would click the button to export, and it would ask me "name this bundle"
<jcastro> and then it would use that
<jcastro> AND bundle.yaml
<rick_h_> but this is just a drive by for the filename part
<jcastro> rick_h_, excellent, <3
<hatch> jcastro I saw you signed up for keybase
<jcastro> yessir
<hatch> https://keybase.io/hatch
<jcastro> I need to figure out how to sign my new key with my old one
<hatch> I'm trying to find a use for this
<hatch> lol
<rick_h_> lol
<hatch> I uploaded the generated private key so I can do in browser decrypting
<jcastro> gpg pokemon
<jcastro> hah no you didn't
<jcastro> you fell for that?
<hatch> without doing that, what's the point in the service?
<hatch> if you must have your computer then why do this at all
<jcastro> the CLI is much nicer than gpg
<jcastro> it's like, easy to use
<hatch> well ok theres that
<hatch> but yeah, if I ever come up with a real use for it then maybe I'll gen another key and not push it up
<hatch> I don't use the key I pushed up for anything
<hatch> maybe I just don't encrypt enough stuff lol
<hatch> ok now I need another task... hmm
<jcastro> yeah, pokemon
<hatch> lol what
<jcastro> collecting signatures, it's like pokemon
<hatch> ohhh
<hatch> pokekey
<jcsackett> hatch: don't think i was online when i pinged you about this: looking at reload in service-inspector.js i see this https://pastebin.canonical.com/111543/
<jcsackett> looks like a bit of flags.il leftover?
<hatch> 2 secs need 2fa
<jcsackett> kk.
<hatch> jcsackett yep looks like that should have been switched over
<hatch> although, I am wondering why I get it auto-reloaded
<jcsackett> hatch: my power blew out, so I'm EoDing. Let's look at it tomorrow. 
<hatch> yeah no problem - it's pretty low on the priorty list :)
<hatch> enjoy lack of power
<jcsackett> Thanks. :p
<huwshimi> Morning
<hatch> hey huwshimi 
<hatch> I gots works fors yous
<huwshimi> hatch: Hey
<huwshimi> hatch: I saw that card
<hatch> cool, so it's the last one blocking release 
<hatch> I wasn't sure if you're familiar with how those inspectors are rendered so I figured I'd stick around
<huwshimi> ah :)
<huwshimi> hatch: I just need a local charm right?
<hatch> yeah you can download the zip from my ghost charm one
<hatch> https://github.com/hatched/ghost-charm
<hatch> the big Download Zip button on the right
<huwshimi> hatch: Ah yes, got it working
<huwshimi> hatch: Anything else I need to take a look at?
<hatch> https://github.com/juju/juju-gui/blob/master/app%2Fviews%2Finspectors%2Flocal-new-upgrade.js
<hatch> https://github.com/juju/juju-gui/blob/master/app%2Fviews%2Finspectors%2Frequest-series.js
<hatch> those are the two inspectors which need updating
<huwshimi> Ah ok
<hatch> I don't think so, maybe just do a once over, see if you can break it in any other way
<huwshimi> ok :)
<huwshimi> hatch: Aiming for release tomorrow?
<hatch> unless we find some huge blocker :)
<hatch> but so far so good
<huwshimi> yay!
<huwshimi> hatch: This is the problem with doing so much between releases :)
<hatch> yeah yeah
<huwshimi> hehe
<huwshimi> Just changing locations, back in a minute.
<hatch> huwshimi I'm going to take off for a couple hours - but I'll be back later if you run into any issues with the js portion of the local charm inspectors
<huwshimi> hatch: Yep, np
#juju-gui 2014-06-12
<bac> hi huwshimi, how're things?
<huwshimi> bac: Hey, good thanks. Yourself?
<bac> good!
<huwshimi> Does anyone know how to make the "Upgrade Services" inspector appear?
<rick_h_> huwshimi: you have to deploy the local charm once
<rick_h_> huwshimi: and then drag/drop it a second time
<huwshimi> Ah
<rick_h_> huwshimi: the GUI thinks you might be trying to upgrade the existing local service
<rick_h_> and gives you the option to deploy again or to upgrade existing services
<huwshimi> rick_h_: Thanks that worked
<hatch> huwshimi thanks :)
<huwshimi> hatch: np :)
<hatch> I was thinking of doing a similar route but ended up with some unexpected issues when I was upgrading with a local charm
<rick_h_> hatch: you going to get to QA that tonight? 
<hatch> rick_h_ yeah, just starting to cook supper so afterwards
<rick_h_> hatch: if that lands tonight then I'll start the release process i nthe morning
<rick_h_> hatch: rgr, well I'll call it a night then and try to make sure to get up early to get that going before the ATT man cuts my interwebs
<rick_h_> thanks guys, appreicate the work on getting the release ready
<hatch> rick_h_ ok sounds good, I'll make sure to do a final QA as well so you're GTG in the am
<hatch> thanks
<rick_h_> hatch: heh, if we've got more stuff we're doomed. We threw a lot of people at it
<hatch> lol true true
<hatch> ok running to make suppa
<hatch> bbiab
<rick_h_> hatch: but like I said onthe call today, I'm not expecting it to be bug free
<hatch> right
<hatch> right
<rick_h_> hatch: so don't stay up too late with it, thanks
<hatch> gnt
<rick_h_> night
<huwshimi> night
<hatch> huwshimi the upgrade local charm UI is broken
<huwshimi> hatch: Uh oh, what did I break?
<hatch> it only shows the Upgrade Services without the Deploy Local Charm on top
<hatch> the Upgrade Services looks like it pushes the Deploy Local Charm view up off the page
<hatch> the two views should be stacked
<hatch> I can send a screenshot if you can't reproduce
<hatch> this was a similar problem that I ran into when doing this heh
<huwshimi> hatch: Oh, I see it's supposed to display both at once.
<hatch> yesm
<huwshimi> hatch: I guess it's actually supposed to look like this: https://drive.google.com/a/canonical.com/?usp=folder#folders/0B7XG_QBXNwY1R0Z6OUJpZXBTa28
<hatch> huwshimi atm we only care that it fills up the left column
<hatch> the Deploy Local Charm is good, but when both are combined it's not
<huwshimi> hatch: Can we not have the controls at the bottom?
<huwshimi> hatch: I'm not sure how it would work otherwise..
<hatch> huwshimi i dew not care :)
<huwshimi> hehe
<hatch> honestly though we can and likely will revisit this in the next release but atm we just need it to fill up the sidebar with black so it doesn't look empty
<hatch> if the buttons are at the top with the content or not then that's ok
<huwshimi> hatch: OK, new version up
<hatch> cool trying
<hatch> huwshimi looks good :) nice 
<huwshimi> hatch: yay
<hatch> you can shipit whenever
<huwshimi> hatch: Have done.
<hatch> noice
<huwshimi> brb, lunch
<huwshimi> hatch: Doing some QA, but let me know if there's anything you need me to look at.
<hatch> huwshimi looks like that's all
<hatch> thanks for getting all these things done for the release
<huwshimi> np
<huwshimi> if only our selenium wasn't so broken
<hatch> huwshimi this looks pretty cool using sass and json http://viget.com/extend/sharing-data-between-sass-and-javascript-with-json
<hatch> thought you might be interested
<huwshimi> nice
<hatch> huwshimi last one :) http://thesassway.com/advanced/inverse-trigonometric-functions-with-sass
<huwshimi> woah
<hatch> haha yep
<hatch> huwshimi looks like you have some failures with your branch
<hatch> IE10 failures
<hatch> I'll re-run it as the failures shouldn't have been affected by your changes
<huwshimi> hatch: It's already re-running
<hatch> oh lookie that
<hatch> :)
<huwshimi> just about to finish
<huwshimi> hatch: Merged.
<hatch> rock on
<frankban> hi rogpeppe1, how it is going?
<rogpeppe1> frankban: hiya
<rogpeppe1> frankban: i'm still contemplating the cmd package
<rogpeppe1> frankban: and trying to grok how it works
<rogpeppe1> frankban: the problem is that it currently depends on the version package
<rogpeppe1> frankban: we need to remove that dependency, but it's not quite clear what the best way to do it is
<frankban> rogpeppe1: also on osenv AFAICT
<rogpeppe1> frankban: hmm, i thought that would be easily removed, but it's not quite so straightforward
<rogpeppe1> frankban: at the moment, my current inclination is just to add global variables for both the current version and the logging config environment variable (or the default logging config)
<frankban> rogpeppe1: not sure how to handle version. maybe put arch in utils and break version into a separate repo? version itself does not seem to be so much tangled with juju
<rogpeppe1> frankban: i don't think it's right to put version in another repo
<rogpeppe1> frankban: it really is juju-core specific, as it's the juju-core version
<frankban> rogpeppe1: yeah, I see now const version = "1.19.4"
<rogpeppe1> frankban: if i could think of a good name, i'd split the version package
<rogpeppe1> frankban: one part would just be the versioning logic
<rogpeppe1> frankban: the other would hold the current version
<frankban> rogpeppe1: yes, that's what I was thinking. you mean, the external part for version parsing, OS versions etc. the juju part with just the juju bits
<frankban> ?
<rogpeppe1> frankban: yup
<frankban> rogpeppe1: juju/versionutils? versiontools?
<rogpeppe1> frankban: i was more thinking of github.com/juju/juju/currentversion or even perhaps putting the current version in github.com/juju/juju/juju
<rogpeppe1> frankban: because i'm quite attached to the current names (version.Number etc) for the primitives
<rogpeppe1> juju.CurrentVersion
<frankban> rogpeppe1: what if instead we change cmd so that it can receive a version? e.g. add a Version string field to SuperCommandParams?
<rogpeppe1> frankban: that's my current thought. except that rather than doing that, i was just planning on adding a global variable
<rogpeppe1> frankban: otherwise the version needs to be provided to the VersionCommand constructor too
<frankban> rogpeppe1: otherwise maybe versionCommand can be a special case, like help: help := &helpCommand{
<frankban> 		super: c,
<frankban> 	}
<rogpeppe1> frankban: yes, perhaps
<frankban> rogpeppe1: that way the command has access to the supercommand, and can retrieve c.Version
<rogpeppe1> frankban: but VersionCommand is also referenced directly by cmd/juju and cmd/jujud
<rogpeppe1> frankban: tbh i don't like the way it's such a special case
<rogpeppe1> frankban: i would much prefer if there was nothing mentioning version in cmd
<rogpeppe1> frankban: but the logic is twisty enough that i haven't managed to work out how to do that
<frankban> rogpeppe1: I mean something like http://pastebin.ubuntu.com/7633106/
<rogpeppe1> frankban: how does that fit with ./juju/cmd/juju/main.go:151: 	r.Register(&cmd.VersionCommand{})
<frankban> rogpeppe1: I just removed that line in the diff
<frankban> rogpeppe1: so basically commands no longer need to register a version subcommand
<frankban> rogpeppe1: and we can also change that so that a version subcommand is registered only if c.Version is not an empty string
<rogpeppe1> frankban: that looks pretty good actually
<rogpeppe1> frankban: do the tests pass with that?
<rogpeppe1> frankban: yeah, i was going to suggest that
<frankban> rogpeppe1: did not try tests, that's just a sketch, but the code compiles
<frankban> rogpeppe1: we'll need to refactor tests so that they pass version when creating a command
<rogpeppe1> frankban: a supercommand, yes
<frankban> rogpeppe1: yes
<frankban> rogpeppe1: the logging bits becomes: logger.Infof("running %s [%s %s]", c.Name, c.Version, runtime.Compiler)
<frankban> rogpeppe1: and version is no longer a dep
<rogpeppe1> frankban: yeah
<frankban> rogpeppe1: FWIW I like this solution, it seems coherent enough. do you wnat me to work on this further on a real branch or do yo want to tackle this?
<rogpeppe1> frankban: i'm happy to do it
<frankban> rogpeppe1: cool thanks
<rogpeppe1> frankban: sorry, i've been reviewing a juju-core branch for a little while
<frankban> rogpeppe1: no worries, will lunch now, do you have other tasks I can proceed with?
 * rogpeppe1 thinks
<rogpeppe1> frankban: i'll think while you have lunch...
<frankban> rogpeppe1: cool thanks
<rick_h_> morning all
<frankban> morning rick_h_ 
<frankban> rick_h_: is MRamm our travel authorizer?
<rick_h_> frankban: yes
<frankban> rick_h_: cool thanks
<bac> jujugui: hey git question: in my brew branch i needed to do a squash, so i did a 'git rebase -i HEAD~2', marked my pick and squash, exited the editor and now things are hosed.  the rebase didn't happen and now i'm unsure of the state or how to recover.
<rick_h_> bac: what is 'git status'?
<bac> rick_h_: rebase in progress
<rick_h_> bac: ok, so there was probably a conflict. Any files listed in that status with a U marker?
<bac> no, no conflicts: https://pastebin.canonical.com/111573/
<rick_h_> bac: try 'git rebase--continue'
<bac> [bac@sol local]$ git rebase --continue
<bac> cat: /usr/local/.git/rebase-merge/stopped-sha: No such file or directory
<bac> Cannot 'squash' without a previous commit
<bac> so 'commit --amend'?
<bac> fist
<bac> s/fist/first/
<rick_h_> bac git rebase --abort, not sure what's up tbh
<rick_h_> bac: but you can abort and start over
<bac> rick_h_: ok, started over.  i mark 's' and 'p' and exit emacs and then it should happen, right?
<rick_h_> save and then exit?
<rick_h_> bac they should all have a p, and then you change the one to s and save/quit the editor
<bac> do you have to pick the first one and squash the later ones?
<rick_h_> bac: and then it should bring up the commit log in the editor
<rick_h_> bac: yes
<rick_h_> bac: and you get a file with all the commit messages to garden up
<rick_h_> and then when you save that, it does the rebase and completes
<bac> rick_h_: ok, i tried to keep the later one b/c it had the commit message i wanted.
<rick_h_> bac: ah yea. No, keep the first, rebase the later, and then edit the messages all at once
<rick_h_> squash the later sorry
<bac> rick_h_: great, commited as desired.  now cannot push as the repo on github has new changes.  'git pull' says it is up-to-date.  i'm not specifying the pull source correctly i guess
<rick_h_> bac: so you're pushing to your own branch?
<rick_h_> bac: since you rebased, there's fewer commits. You have to push back up to your branch with --force to make git update the other location, but make 100% sure you're doing this to your branch that no one else is using
<bac> i want to push to  juju/homebrew
<bac> git push git@github.com:juju/homebrew.git juju-quickstart-formula
<rick_h_> bac: right, add --force to that
<bac> so when it says
<bac> hint: Updates were rejected because a pushed branch tip is behind its remote
<bac> hint: counterpart. Check out this branch and integrate the remote changes
<bac> that is simply caused by the rebase?
<rick_h_> it's simply because the other branch has more/different commits
<bac> the remote hasn't changed
<rick_h_> your rebase changed that
<rick_h_> no, but if you compare your local branch to the remote, it has the rebased away commits. 
<bac> oh, e.g. it has the 1.3.4 commit, i commited 1.3.5 and squashed 1.3.4, so remote no longer has 1.3.4 and git lies saying the remote has new commits
<rick_h_> so one branch says "after commit xxxx, here's 3 more commits. And your local one says "after commit xxxx here's one more commit"
<rick_h_> bac: right, s/newer/different
<bac> ok, so the hint is misleading
 * bac goes to amazon for o'reilly book
<rick_h_> crash course!
<rick_h_> bac: pro git is supposed to be the git bible these days. I haven't read it, but it's available free online
<rick_h_> http://git-scm.com/book
<bac> i just need to use git more frequently than once a quarter
<rick_h_> heh, yea that helps
<rick_h_> did that work out then?
<bac> yes.  i may have just done the thing we as a project said we didn't want: rebase during a pull request cycle.
<bac> my pull request title now references 1.3.4 but i just commited 1.3.5.
<bac> they are insistent on squashing, though.
<bac> hey but the brew guys commented on the PR, which is a good sign
<frankban> bac: PR link?
<bac> frankban: https://github.com/Homebrew/homebrew/pull/30070
<frankban> ty
<rick_h_> kadams54: or jcsackett can one of you please look at the bug in urgent please? It's the last known issue blocking release
<rick_h_> coordinate with hatch or makyo if required as one of them worked on that recently I believe. 
<rick_h_> heh, the card has mayko's head on it but the bug has hatch assigned https://launchpad.net/bugs/1326401
<_mup_> Bug #1326401: Charm details link in the Inspector on the left doesn't work <juju-gui:Triaged by hatch> <https://launchpad.net/bugs/1326401>
<jcsackett> rick_h_: looking.
<jcsackett> and good morning, all.
<rick_h_> jcsackett: ty much
<frankban> bac: not sure if this is related to the failure, but I remember I looked at other formulas and the install section usually looks like http://pastebin.ubuntu.com/7633583/
<jcsackett> rick_h_: huh, that worked yesterday when i looked at it. 
<rick_h_> jcsackett: I've got the steps to reproduce in the bug there from luca https://bugs.launchpad.net/juju-gui/+bug/1329236
<_mup_> Bug #1329236: Click on "cs:/precise...." does nothing <juju-gui:Triaged> <https://launchpad.net/bugs/1329236>
<bac> frankban: the failure is i tried to use 'juju quickstart' in the test, not 'juju-quickstart'.  it turns out #{bin} is not what i expected, but a bin with only the package executables, thus 'juju' is not there.
<kadams54> rick_h_, jcsackett: Yeah, interesting. I remember testing that when Huw moved the link from "Charm details" to the charm IDâ¦
<jcsackett> kadams54, rick_h_: ah, it's in the ghost inspector.
<rick_h_> jcsackett: the error I hit was in the real inspector
<rick_h_> not the ghost
<jcsackett> i'm not getting that, following exactly his steps.
<rick_h_> jcsackett: huh?
<rick_h_> jcsackett: you mean my steps?
<jcsackett> rick_h_: yes, thought it was his comment, misread.
<rick_h_> jcsackett: I get it using those instructions in both FF and chrome
<kadams54> jcsackett, rick_h_ : I also run into the problem.
 * jcsackett ponders caching...
<kadams54> The first click works to open the details, but subsequent clicks do not.
<kadams54> I'm in Chrome Canary, incognito
<kadams54> Checking other browsersâ¦
<rick_h_> kadams54: cool, yea it's the JS errors and I bet something is cleaned up/not cleaned up that breaks next attempts
<jcsackett> aaah.
<kadams54> It looks like something is being overly aggressive in cleaning up
<kadams54> Which means something else is unexpectedly null on the second click
<rick_h_> kadams54: right, I wonder if the work done in updating the inspector styling yesterday moved something
<rick_h_> jcsackett: ^
<rick_h_> so you might try pre-hatch's commit yesterday 
<rick_h_> and see if it repeats
<jcsackett> i've reproduced. the instructions and description didn't mention it being subsequent clicks.
<rick_h_> Now the next time you click you get another error:
<rick_h_> :P
<rick_h_> https://github.com/juju/juju-gui/commit/88a49f4a7a7da60ecf1757f90bccf4cb1131a867
<jcsackett> <--under caffeinated brain
<rick_h_> might be the issue
<rick_h_> jujugui att guy is here. I'm going dark. I'm available via hangouts on the phone of you need anything. Please get help/etc move this bug through and have someone go through the release process. 
<jcsackett> rick_h_: dig.
<kadams54>  Yup, will do
<rick_h_> ty much
<jcsackett> kadams54: bad news, that change is not responsible--it's only on local charm inspector dispatching, which doesn't come into play on this error path. i'm going to keep digging.
<kadams54> jcsackett: OK, I'll stand by to QA and review.
<jcsackett> thanks.
<bac> frankban: would you like to pull the brew formula try to install?
<frankban> bac: sure
<bac> frankban: and 'brew test --verbose juju-quickstart'
<frankban> bac: how do I pull the formula?
<kadams54> bac: Oh nice, good progress on getting quickstart brew-ified?
<bac> frankban: it is on github as juju/homebrew
<bac> frankban: i guess you'd cd to `brew --repository` and pull it there?
<frankban> bac: installing quickstart
<frankban> bac http://pastebin.ubuntu.com/7633692/
<bac> frankban: cool.  as it should be.
<jcsackett> kadams54: so...this fixes the bug, but it doesn't feel like the right fix, and i'm still not sure what the real root cause is. https://github.com/juju/juju-gui/pull/384/files
<jcsackett> thoughts?
<kadams54> Lookingâ¦
<jcsackett> viewlet management &c is still a bit opaque to me.
<kadams54> What happens if you still did the destroy, but without passing in remove: true?
<hatch> what's the problem?
<kadams54> hatch: see https://bugs.launchpad.net/juju-gui/+bug/1329236 - currently a blocker
<_mup_> Bug #1329236: Click on "cs:precise...." does nothing in the inspector on subsequent clicks <juju-gui:Triaged> <https://launchpad.net/bugs/1329236>
<kadams54> jcsackett, hatch: I find it odd that container.empty() is called after invoking the viewlet's destructor. Seems like that should be done within the destructorâ¦
<kadams54> Which likely has nothing to do with this bug, but more general code smell.
<hatch> yeah the charm details stuff is definitely not done correctly
<hatch> but one sec lemme look
<bac> frankban: huh, a new mysterious failure: https://github.com/Homebrew/homebrew/pull/30070
<bac> frankban: not sure how this is related to my branch
<hatch> jcsackett so if you remove the container.empty and the remove: true does it work?
<kadams54> Just bisected those lines back to a change I made: https://github.com/juju/juju-gui/commit/06a905da55efdd7d45ba9bd80ec7fd5a65e3f39e#diff-18e27830e6c8815b6d3e6caa66636597R55
<kadams54> I suspect the cleanup is still needed. It just needs to happen in a better, more intelligent way :-) Still not sure why this bug is only just now popping upâ¦
<jcsackett> hatch, kadams54: checking remove: true and empty now--had to let the dogs out.
<kadams54> Guess that answers the question.
<kadams54> We now know who let the dogs out.
<kadams54> Thank you, thank you, I'll be here all day long.
 * jcsackett groans
<jcsackett> nice, kadams54. very nice.
<jcsackett> kadams54, hatch: yeah, if i keep destroy but get rid of remove: true it works.
<jcsackett> it actually works independently of whether or not container.empty is there.
<kadams54> We're going to need to make sure we're not creating multiple charm detail DOM nodes on subsequent clicks
<hatch> yeah this whole section is a little broken - the view shouldn't need to do this, it should be destroyed/rendered by the viewlet manager
<hatch> did anyone bisect to see when this bug was introduced?
<hatch> because it wasn't throwing any errors yesterday I'm pretty sure
<kadams54> hatch: not yet, but working on it right now.
<hatch> kadams54 cool thx
<hatch> I don't remember anything landing that could cause this...
<jcsackett> hatch: i'm not sure this path was QAed; i never clicked the link, closed it, and reclicked it.
<jcsackett> so it could have been broken yesterday.
<jcsackett> hatch: so, the container close thing is already calling hideSlot--doesn't hideslot kill the viewlet?
<hatch> heh the bug report is pretty horrible :P
<hatch> jcsackett it should yep
<hatch> it should detach the event binding and then call the viewlets destroy method
<jcsackett> hatch: it does.
<jcsackett> ok, so i've removed all the this.destroy and container.empty stuff in the .close function. the viewlet still goes away, and i'm not seeing dom nodes hanging around.
<hatch> jcsackett oh the destructor for that view has none of this business in it....I wonder why this extra delegate was created
<hatch> it seems to me like all of that should be moved to the destructor
<jcsackett> hatch: i think just for url and animation cleanup--if i keep both of those and then call viewletManager.hideslot everything seems to be groovy.
<jcsackett> tests all pass this way too.
<jcsackett> (which doesn't necessarily mean anything, but hey)
<hatch> (all the tests passed before)
<hatch> :P
<kadams54> +1 for moving all that to the destructor
<hatch> the service inspector calls hideSlot when the X is clicked
<hatch> so that delegate shouldn't be needed
<hatch> so all of those bits should be able to be moved into the destructor
<hatch> brb
<jcsackett> hatch, kadams54: so, the bind is there b/c the "x" in question is a different one--it's the one on charm-details, not the one on the service inspector, and there's no event bound to it w/o the container delegate block.
<jcsackett> i can move all the other logic into the destructor, but the delegate seems to be necessary for clicking the x to actually call hideSlot.
<jcsackett> the WIP pr is updated so you can see what i mean.
<rogpeppe1> lunch
<hatch> jcsackett ahhhh
<kadams54> jcsackett, hatch: Hmm, when I +1 stuff moving to the destructor, it was container.empty()â¦ I think closing (whether in the delegate or in closeSlot) still ought to remove the "animate-in" class, remove the URL hash, and invoke the destructor.
<jcsackett> kadams54: well, we don't actually need container.empty at all, do we?
<Makyo> Averaging 3k/s, don't think hangouts are going to work for me this morning.
<jcsackett> since hideSlot is supposed to handle everything.
<hatch> Makyo lol
<jcsackett> Makyo: broadband not installed yet, eh?
<bac> hey frankban, for juju-quickstart on PyPI the description seems to just be the README.rst.  does PyPI read that in automatically or was it cut-n-pasted there?
<Makyo> jcsackett, they're coming this morning.  Until then, I'm tethering on Edge.
<kadams54> jcsackett: I'm skeptical of hideSlotâ¦ when I added those lines of code, it was because the charm details weren't being fully destroyed, so subsequent clicks would end up creating multiple detail panels.
<hatch> jcsackett so I think the proper way to fix this is to add an event (this is just a view) to call the destructor when .close-slot is clicked
<frankban> bac: PyPi shows the long_description passed in setup.py
<kadams54> jcsackett, hatch: It may be that hideSlot's doing more now to ensure proper cleanup, but I don't want to just assume that.
<hatch> then move everything from within that delegate into the destructor
<jcsackett> hatch: and continue not having remove: true, yeah?
<hatch> yeah we don't want it to remove its container
<frankban> bac: we dynamically pass the contents of README.rst
<bac> frankban: ah, thanks.
<kadams54> hatch: I still think things like removing "animate-in" class needs to happen outside the destructor. Is that also what you're proposing?
<bac> frankban: but you can also edit it in place on pypi.
<hatch> kadams54 why?
<kadams54> Because it has nothing to do with destroying the class
<kadams54> And everything to do with the visual effects that happen when a close action occurs
<bac> frankban: if i do edit in place, i assume it will pick it up on the next release from the long description.
<kadams54> There may be other situations where you want to destroy the class but you don't give a fig about making sure the panel slides in nicely.
<frankban> bac: at that point I guess new releases override the description
<bac> frankban: yeah, i'd expect so.  i'd like to update the info now without having to do a release.
<jcsackett> hatch: should the destructor be calling hideSlot...since hideSlot calls the views destructor...?
<frankban> bac: so you want to change both README and the description on the current release?
<hatch> jcsackett good point
<jcsackett> maybe we want the fn called for the close-slot click event to do the anim cleanup, then call hideSlot?
<hatch> blah this stuff is so broke heh 
<bac> frankban: i want to change what is seen on pypi now via editing on the site.  i also want to update the README in the branch.
<hatch> jcsackett imho, make it work for release - this needs to be broken out of the inspector anyways
<jcsackett> hatch: so, my proposal:
<jcsackett> have events include click on close-slot; that calls a method which deals with the anim stuff, and calls hideSlot.
<jcsackett> hideSlot, i've verified, calls view.remove and view.destroy.
<kadams54> jcsackett, hatch: Yeah, that seems like the best/cleanest separation of concerns.
<jcsackett> we can add container.empty to the close-slot method to address kadams54 concerns.
<jcsackett> and then i'll put in a test to make sure that the close slot method actually gets rid of stuff so we don't keep generating extra details nodes.
<jcsackett> you both +1?
<hatch> yep go for it
<kadams54> yep +1
<jcsackett> cool.
<hatch> after this release is gtg?
<frankban> bac: how do you want to change the README?
<jcsackett> i believe so; unless we want the s/export.yaml/bundle.yaml/ drive by i did to be part of the release.
<bac> frankban: using emacs, i guess
<jcsackett> jcsackett: i haven't had a chance to add a test for that--for some reason i thought i had already landed when i picked this up.
<bac> frankban: sorry.  no, i want to add OS X to the supported systems and mention pip and brew install
<frankban> bac: I am not sure we want to advertise osx support now. It's not complete, and it deserves a minor version change. I'd be inclined to do that a part of the 1.4.0 release
<bac> frankban: what is incomplete?
<bac> from a pip install?
<bac> well, there is the local environment stuff in the interactive session
<jcsackett> hatch: see comment above. i highlighted myself instead of you.
<frankban> bac: exactly
<hatch> oh heh
<hatch> jcsackett yeah we can probably wait for that to land
<frankban> bac: and from the perspective of a brew user who does not have an env.yaml file, the really first impact with quickstart is a broken option right now
<bac> frankban: i hadn't seen you were working on that card
<frankban> bac: the other one (handle brew not installed) is also a blocker IMHO
<bac> frankban: ok.  that's a good plan to get all of these and target for 1.4.0.
<frankban> bac: cool
<hatch> jujugui call in 10
<frankban> bac: added two cards in maint/high: update readme, release 1.4.0
<rick_h_> jujugui call in < 1
<hatch> found yourself some interwebs?
<rick_h_> just on the wifi of the new router
<rick_h_> lots of rewiring to do :)
<hatch> ohhhhhhhh
<rick_h_> but the new one is smaller yay! more room in the rack
<rick_h_> jcsackett: &
<rick_h_> jcsackett: ^
<bac> jcsackett: it should be plural:  bundles.yaml
<jcsackett> bac: yeah? 
<jcsackett> but it only holds one bundle.
<bac> jcsackett: http://bazaar.launchpad.net/~charmers/charms/bundles/rails/bundle/files
<bac> no, it can have many bundles
<bac> jcsackett: it is really a deployer file, and can have lots of bundles in it.
<jcsackett> bac: so the file in a bundle is always bundles.yaml. ok.
<bac> jcsackett: i guess we could've exposed the basket nomenclature...but, no.
<jcsackett> bac: i'm fine making a one character addition while i'm adding a test.
<jcsackett> :p
<jcsackett> hatch: got a second to chat?
<hatch> yeah sure
<hatch> standup room?
<hatch> ^ jcsackett 
<hatch> rick_h_ who is the travel authorizinator? 
<jcsackett> hatch: sure.
<frankban> hatch: MRamm
<kadams54> jcsackett, hatch: heading out to lunch shortly. Will be back in an hour.
<rick_h_> hatch: yep, ramm
<hatch> thx
<hatch> jcsackett hey how goes the battle?
<jcsackett> hatch: just about done.
<jcsackett> double checking our assumptions re hideSlot are correct and then submitting.
<hatch> cool, lemme know when you are and I'll get it QA's and whatnot
<hatch> holy smokes it's been a long time since we released heh
<jcsackett> hatch: so...the destructor is only called the *first* time.
<hatch> ugh so the delegate stuff is needed...
 * jcsackett hates this code
<jcsackett> it's become personal.
<jcsackett> hatch: i think we revert all changes and just remove the "remove: true"
<jcsackett> we can't fix the rest of this until we can kill all the current slot goofiness.
<hatch> jcsackett whatever gets this landed :)
<jcsackett> hatch: yeah, just now i have to write an entirely new test. :(
<hatch> ugh
<hatch> sorry
<jcsackett> ...actually, i'm not even sure how to test it; i guess event simulate...?
<jcsackett> except i have to stub out *everything* so i'm not sure what i'm even testing...
<hatch> well
<hatch> on click we want to see that it calls to do the specific things
<jcsackett> yeah, i'm just concerned, since we're still in slot land, that i'm not really testing the issue kadams54 encountered that led to this code in the first place.
 * jcsackett really doesn't want to re-introduce the bug he was fixing.
<hatch> yeah this is true
<hatch> but it's so much work to properly test
<hatch> heh
<hatch> and we'll throw it all away soon
<hatch> maybe just a good qa and a basic test will be enough
<hatch> and a card to go back and fix it properly
<jcsackett> hatch: FYI hideSlot doesn't call the view destructor.
<jcsackett> i've instrumented both, and the first time hideSlot is called, the view destructor is called.
<hatch> ohhhh boy I can't wait to delete that stuff
<jcsackett> subsequent times hideSlot is called, the destructor is not.
<jcsackett> so i'm going to keep this.destroy in the delegated function.
<hatch> jcsackett ok I'm ready for the release once we land these branches, anything I can help with to get these moving?
<hatch> if not, no biggy I can move to something else for now
<jcsackett> hatch: you can review this https://github.com/juju/juju-gui/pull/384
<hatch> on it
<jcsackett> and QA the holy hell out of the charm details inspector so we can be sure it doesn't break something else. :)
<hatch> haha ok
<hatch> jcsackett when I navigate between the tabs the little red thing lags
<hatch> does it do that on yours as well?
<hatch> rick_h_ I was wondering if we could prioritize the perf issue when going from inspector to charmbrowser - the inspector kind of just hangs there for a while then snaps to the cb
<hatch> jcsackett review done and qa ok
<hatch> just one small comment re a comment
<jcsackett> hatch: the red thing lags for me even on develop
<hatch> jcsackett yeah I was just confirming 
<hatch> I didn't think they were caused by this branch heh
<jcsackett> hatch: yeah, i just wanted to be sure.
<jcsackett> the comment does not apply. i'm changing it now and pushing up a rebase, and we can shipit.
<hatch> aweseome thx
<jcsackett> np.
<jcsackett> hatch: meanwhile, you know how to test that saveAs gets 'bundles.yaml' as an arg for the export branch?
<hatch> hmm
<hatch> thinking
<hatch> i''mmmmmm thinking
<hatch> jcsackett yup, greate a global saveAs stub and test that the right data is sent to it
<jcsackett> can you do that? i don't see where saveAs is defined to override it? or i guess i can just assign a stub to it anyway, can't it?
<hatch> the first param will be something like     assert.equal(arg1 instanceof Blob, true)
<jcsackett> s/can't it/cant i
<hatch> jcsackett it's defined in FileSaver
<hatch> .js
<hatch> but you can just create a global stub....make sure to null it out and whatnot afterwards
 * jcsackett nods
<jcsackett> ok, changes are up, waiting on testrun.
<hatch> for which?
<hatch> the bundles one you forgot to add the test
<hatch> heh
<hatch> jcsackett you don't need to wait for the tests to finish for the charm-details branch....the lander will run them anyways before it merges
<hatch> so you can shipit now
<hatch> unless of course you think they won't pass for whatever reason :)
<hatch> did they pass locally?
<jcsackett> they did; i've shipped it.
<jcsackett> i'm just always leery of doing that.
<hatch> heh, it's ok, it'll bomb out if it doesn't pass
<hatch> I mean, don't do that if you haven't had a passing run locally or whatever, just in case, but if you have and it's just a touchup branch then let'r'rip imho
<jcsackett> hatch: how do you make a global stub? i can't just assign a stub to "saveAs" b/c it's failing as a readonly.
<hatch> *sigh* of course it is....
<hatch> unos momentos
<jcsackett> thanks.
<hatch> jcsackett ok you can't
<hatch> damn strict mode
<hatch> we'll have to create an abstraction at some point like we did with the web handler stuff
<hatch> in the env
<hatch> son of a...
<hatch> I'm still looking for an alternative
<rick_h_> hatch: jcsackett sorry, lost internet and didn't realize I wans't connected
<rick_h_> hatch: let's talk after the release on the perf issue stuff.
<hatch> rick_h_ yeah no problem
 * rick_h_ runs for foods 
<hatch> jcsackett yeah doesn't look like there is a way around it - I thought that filesaver was providing a wrapper already but it turns out it's just passing the real saveAs method through
<jcsackett> hatch: so...just leave this untested, since my branch is a one word change?
<hatch> so no test for now - follow-up card to create an abstraction
<hatch> right
<jcsackett> hatch: dig. i'll throw a card in the backlog pool.
<hatch> thanks sir
<jcsackett> gah, ci/selenium...
<hatch> ugh
<hatch> re-run it
<jcsackett> i just remove the merge request accepted comment, right?
<hatch> correct
<rogpeppe1> done for the day
<rogpeppe1> g'night all
<rogpeppe1> a collaborative effort with frankban: https://github.com/juju/cmd/pull/1
<hatch> night rogpeppe1 
<hatch> jcsackett are you going to shipit your bundles branch? Or are you waiting for something
<jcsackett> hatch: thought i already had.
<hatch> :)
<hatch> jujugui by the power vested in me by myself I now declare develop frozen from any more shipit's 
<kadams54> hatch: are you cutting the release?
<hatch> once the two PR's that are landing land on develop
<hatch> so it wont be released for probably a couple hours
<hatch> I'm going to grab some lunch soon to let those land
<kadams54> hatch: OK, I'm going to proceed with the card I have in progress then. Ping me once you're ready to proceed.
<hatch> sounds good
<hatch> ugh this darn CI
<hatch> I'm blaming ci when it's more than likely our test suite 
<hatch> :)
<hatch> lots of interesting talks at I/O unfortunately most aren't being streamed - I hope they are still recorded and put up afterwards 
<rick_h_> hatch: yea, I'm sure they will be
<rick_h_> hatch: how goes CI? is it hating?
<hatch> it just keeps getting that intermittent failure for some reason
<hatch> looks like this last run is going to work though
<rick_h_> hmm, yea that notificatoin one in IE is normal. Odd to see them so grouped together. 
<hatch> rick_h_ anything else you'd like to see in the release notes? https://gist.github.com/hatched/05547f6ca921c580996e
<rick_h_> hatch: looking
<rick_h_> hatch: don't think (FIX) SSL handshake fails in OSX Safari is part of gui release
<hatch> removed
<rick_h_> hatch: doing a quick search through bugs
<hatch> I'm having an issue getting make docs working....hope this time it works
<rick_h_> hatch: I'd mention the export filename
<hatch> done
<rick_h_> hatch: https://bugs.launchpad.net/juju-gui/+bug/1295264 and https://bugs.launchpad.net/juju-gui/+bug/1249039 should probably be called out as well
<_mup_> Bug #1295264: jujugui allows iframing and can be clickjacked in this way <netcraft> <juju-gui:In Progress by frankban> <https://launchpad.net/bugs/1295264>
<_mup_> Bug #1249039: Exporting from real environment exports juju-gui as well <juju-gui:Fix Committed by frankban> <juju-quickstart:Invalid> <https://launchpad.net/bugs/1249039>
<rick_h_> as they change behavior
<rick_h_> hatch: but other than that that's good
<rick_h_> and kind of sad really :/
<hatch> the exports gui one was done last release
<rick_h_> was expecting it to be a huge changelog
<hatch> :) lots of loc's changed heh
<rick_h_> hatch: oh, then I fail at keeping that up to date
<hatch> I'll add the clickjacking though
<rick_h_> ty
<hatch> rick_h_ updated https://gist.github.com/hatched/05547f6ca921c580996e
<rick_h_> hatch: LGTM 
<bac> hey hatch, do you have a moment for a quick hangout?
<hatch> just doing the release but sure
<hatch> link?
<bac> hatch: nm, if you're busy
<bac> hatch: but i'm in daily standup if you're not
<hatch> sure it's making right now
<hatch> MAN safari is fast running these tests compared to chrome
<hatch> 362 commits since last release
<hatch> hey rick_h_ I made a bad tag :/
<hatch> oh phew it's an easy fix
<hatch> heh
<kadams54> Bad hatch, bad!
<hatch> I know!
<hatch> rick_h_ I'm getting gpg errors when trying to upload the final release - this is going to lp right?
<rick_h_> hatch: yes
<hatch> ok I'll have to look there
<rick_h_> can anynoe hit http://maas.jujugui.org/MAAS ?
<hatch> negative
<rick_h_> hmm, try sans MAAS 
<hatch> I get to hoover with just jujugui.org
<hatch> but nothing else works
<rick_h_> sorry, meant the end one
<rick_h_> http://maas.jujugui.org
<bac> nope
<rick_h_> hm, ok
<hatch> nope
<bac> rick_h_: maas.jujugui.org.	861	IN	A	162.230.177.140  <- that right?
<rick_h_> bac: rgr
<rick_h_> hatch: worst case make sure all your stuff is pushed up to the main repo and I'll pull it down and do the upload if that's what's left
<hatch> rick_h_ that's the only thing that's left
<hatch> for some reason it's not accepting my key even after moving it over
<hatch> gimme a few more mins
<rick_h_> hatch: ok, cloning down while you do that
<hatch> rick_h_ yeah I'm not sure what's going on here
<hatch> I might need to get in touch with the is guys
<rick_h_> hatch: ok, testing a make distfile here
<rick_h_> hatch: this is 1.1.0?
<hatch> it is
<hatch> master should have the 1.1.0 tag
<rick_h_> okie cool
<rick_h_> ok, uploading
<rick_h_> hatch: ok, release uploaded, please carry on from there. https://api.launchpad.net/1.0/juju-gui/stable/1.1.0/+file/juju-gui-1.1.0.xz
<hatch> thanks
<hatch> annnnnd done
<hatch> just waiting for CI to clear out so I can run it again
<rick_h_> hatch: wow, that was fast. charm is updated?
<hatch> ohh I didn't know there were any changes to the charm heh
<rick_h_> oh, you mean the git/repo release part cool
<rick_h_> hatch: well we need to copy the new release file to the charm and update it
<hatch> annnd I don't have bzr installed
<hatch> ggreeeaaattt
<rick_h_> lol
<hatch> it's clearly been a while since I've done this
<hatch> bzr is downloading the charm repo, see ya'll in a week
<rick_h_> good thing you're on real interwebs today
<hatch> haha, so true
<hatch> rick_h_ how do I know what to tag the trusty charm release at?
<hatch> it says `bzr tag 0.11.0` but.... that doesn't match the revno
<rick_h_> hatch: that's just the charm source tag. It doesn't matter for the charm itself in the juju store
<hatch> well the current tags are in three different formats lol
<hatch> the most recent appears to be 1.0.2
<hatch> so it must now match the gui release?
<rick_h_> hatch: yea, I think we were marking them that way
<hatch> ok cool
<hatch> rick_h_ ok and are we not updating the precise charm any longer?
<hatch> Or are the docs missing a step?
<rick_h_> hatch: right, the precise charm is left behind due to packages and deps used in the charm
<rick_h_> hatch: I believe...
<hatch> ok cool
<hatch> haha
<hatch> rick_h_ they are killing the yui gallery 
<rick_h_> hatch: not surprised
<rick_h_> hatch: without a true ssl gallery on the cdn and such we never could use it either. and managing it was a mess
<hatch> yeah true true
<hatch> rick_h_ so I am having a heck of a time here - I can't get make-lint to run
<rick_h_> hatch: ok
<hatch> https://gist.github.com/hatched/aed7e6f1ae2d85a436a0
<hatch> that's the error
<rick_h_> hatch: want to hangout and share the errors? Or I can look at updating the charm tomorrow in the morning
<rick_h_> hatch: make sysdeps
<rick_h_> oh! I don't think that's in there, sudo apt-get install python-dev
<hatch> ohh ok installing
<hatch> oh now I need pip
<hatch> lol
<hatch> maybe....
<hatch> or does make lint not have any output?
<hatch> https://gist.github.com/hatched/f8cbc4ee1452467036d5
<hatch> does that mean lint passed?
<rick_h_> hatch: so you need to run make sysdeps
<rick_h_> and make deps
<rick_h_> and then make lint
<hatch> make: Nothing to be done for `deps'.
<rick_h_> ok, sysdeps?
<rick_h_> maybe try this
<hatch> just ran, trying again
<hatch> nope that's good
<rick_h_> make sysdeps && make deps && make unittest
<rick_h_> does that run/pass?
<hatch> yep
<hatch> OK
<hatch> [I 140612 21:25:27 testing:609] PASS
<hatch> so make lint must not have any output
<hatch> successful or not
<hatch> er - when it's successful
<rick_h_> hmm, getting that here as well
<rick_h_> yea, most lint shouldn't say anything if it's ok
<rick_h_> carry on! :)
<hatch> well I guess I will continue on for the real env tests
<hatch> oh ok
<hatch> :)
<rick_h_> that pip thing looks bad though but it's working 
<hatch> now lets see if this machine has juju...lol
<rick_h_> lol
<hatch> it does it does
<rick_h_> going afk for a few min, hit me up on hangouts chat on my phone if you hit another wall, biaf
<hatch> juju-test is missing....hmm
<hatch> ahh charmtools not installed 
<hatch> well hello Makyo 
<Makyo> Hey!  Finally got net.
<hatch> rock on!
<hatch> done a speed test yet?
<Makyo> Not yet.  Literally just turned on, IRC was still running on a stale connection.
<rick_h_> Makyo: woot
<rick_h_> ok, I've got to go. Wife is leaving and the boy is in my hands
<rick_h_> hatch: I'll try to keep an eye on irc from the kitchen
<hatch> rick_h_ cool, it's running the ec2 tests
<hatch> brb while this test runs
<rick_h_> hatch: yea, those will take a while
<Makyo> hatch, 10 down, 1 up
<rick_h_> Makyo: that's the microwave?
<Makyo> rick_h_, no, they told me "it's not you, it's us" and broke up with me.  This is satellite.
<rick_h_> wow
<rick_h_> curious how your hangouts go
<rick_h_> what's the ping times?
<Makyo> Yeah, me too :/
<rick_h_> move out to the woods?
<Makyo> 500-1000ms :/
<Makyo> I didn't think so, but apparently.
<Makyo> Event Centurylink told me no.
<rick_h_> wow
<hatch> ykes
<hatch> annnnd now one more ec2 test
<hatch> I think it's closer to 40mins per test run :)
<hatch> maybe depending on the instance spin up time on ec2
<huwshimi> Morning
<hatch> hey huwshimi 
<huwshimi> hatch: Hey
<huwshimi> hatch: No call I guess this morning then?
<rick_h_> huwshimi: is it time? /me looks at calendar
<rick_h_> wtf why did my alarm not go off
<rick_h_> huwshimi: sorry, call if you're able
<huwshimi> :)
<huwshimi> rick_h_: Sure!
<rick_h_> hatch: jcsackett welcome to join
<hatch> jujugui anyone remember what the path was for the juju gui charm on launchpad?
<rick_h_> hatch: use the links in the web ui
<huwshimi> http://bazaar.launchpad.net/~juju-gui-charmers/charms/precise/juju-gui/trunk/files
<huwshimi> hatch: USE THE GUI
<hatch> hah thanks - lp still confuses me
<bac> TEH GUI
<hatch> lol
<hatch> and charms have been pushed up
<hatch> now I'm going to mow the lawn
<hatch> :) bbl
#juju-gui 2014-06-13
<rick_h_> wheee bug spam 
<rick_h_> but with that I think I'm spent. party on 
<rick_h_> huwshimi: though can you update your card? I thought I saw a pull request for your card that's in branch start
 * rick_h_ runs away
<huwshimi> Ah yes
<frankban> rogpeppe1: morning and LGTM. If you agree, we can proceed like the following: you remove cmd stuff from core and I move the store commands from core to store. How does it sound?
<rogpeppe1> frankban: sgtm
<frankban> rogpeppe1: cool, I just found a typo on the cmd branch
<rogpeppe1> frankban: oh yes?
<frankban> rogpeppe1: yes, in a comment, so nothing bad
<frankban> rogpeppe1: what's the idiomatic way to add a command to a package? creating a cmd dir and subdirs for each command, each one including a main package?
<rogpeppe1> frankban: yup
<frankban> rogpeppe1: cool thanks
<frankban> rogpeppe1: I encountered code like this: http://pastebin.ubuntu.com/7638321/ . Do we have any conventional meaning for those kind of blocks?
<rogpeppe1> frankban: looks a bit weird to me - it doesn't seem like there's any purpose to the extra scope
<rogpeppe1> frankban: where's the code?
<frankban> rogpeppe1: you can found those additional scopes in both cmd/charm-admin test files
<rogpeppe1> frankban: ha
<rogpeppe1> frankban: i found three almost identical places
<rogpeppe1> frankban: definite copypasta
<frankban> rogpeppe1: ok I'll fix those in charmstore
<rogpeppe1> frankban: i see no reason for the block at all
<frankban> rogpeppe1: are there cases where blocks like them are not meaningless?
<rogpeppe1> frankban: ah, i *think* i see what they were trying to do
<rogpeppe1> frankban: i think they thought that defer is block-scoped
<frankban> rogpeppe1: yes, each block has its own defer
<frankban> rogpeppe1: AFAICT there is no need to do that, and also defer should come right after the error check
<rogpeppe1> frankban: they should do the close (not deferred) just after the Fprintf
<rogpeppe1> frankban: but this would be a better way to do it:
<rogpeppe1> frankban: http://paste.ubuntu.com/7638340/
<frankban> rogpeppe1: right ioutil.WriteFile
<frankban> rogpeppe1: ok I'll change all the occurrences
<rogpeppe1> actually, it needs configPath to be saved: http://paste.ubuntu.com/7638343/
<frankban> rogpeppe1: could you please take a look at https://github.com/juju/charmstore/pull/3 ?
<rogpeppe1> frankban: looking
<bac> frankban: thanks for the review
<frankban> bac: yw, what do you think?
<bac> frankban: still digesting.  i think it is probably a good idea.
<rogpeppe1> frankban: reviewed
<frankban> rogpeppe1: thanks
<frankban> rogpeppe1: do you want to remove those commands from core as part of your cmd removal branch?
<bac> frankban: one issue, is in setup we need the platform before calling _get_packaging_info, which is needed to create the parser.  so there is a chicken-egg thing to sort out
<rogpeppe1> frankban: feel free to do it independently if you like
<bac> frankban: your suggestion has a parser before determining the platform
<rogpeppe1> anyone know how to do in git the equivalent of "bzr revert somefile.go otherfile.go" ?
<rick_h_> frankban: were we able to keep updating the older precise charm? I thought we had something that didn't work so we were only updating precise. 
<rick_h_> rogpeppe1: git checkout file.go 
<rick_h_> rogpeppe1: will return it back to the original state
<rogpeppe1> rick_h_: and that doesn't affect HEAD ?
<rogpeppe1> rick_h_: thanks
<rogpeppe1> rick_h_: that worked beautifully and extracted me from a nasty situation...
<frankban> bac: IC. In this case let's keep retrieving the platform at the beginning of setup, and then call _validate_platform(platform, parser) near the end
<bac> frankban: yeah, that's doable and avoids the program exit
<bac> sounds good
<frankban> rick_h_: trusty and precise charms share the same development codebase. We just need to push to both cs locations when releasing. IIRC the only broken bit in the precise charm is juju-gui-source={some git branch}
<frankban> bac: great
<frankban> rogpeppe1: ok, I'll do that after lunch
<rick_h_> frankban: ah, maybe that's what I was thinking. I thought it was something in changes in git. 
<rick_h_> frankban: thanks, we'll get the precise one updated today as well
<frankban> rogpeppe1: I see your point re VCS history, but at this point I'd be inclined to just merge it. Sounds good?
<rogpeppe1> frankban: yeah, sgtm
<frankban> rogpeppe1: thanks
<rogpeppe1> frankban: the history that gets imported is all mangled anyway.
<rogpeppe1> frankban: i just go back to lp...
 * frankban lunches
<rick_h_> bac: frankban should we wait on a release blog post for quickstart until 1.4? 
<bac> rick_h_: yes, i think so
<rick_h_> bac: frankban I was going to write up a small blurb for the blog for 1.3.5 but notice the 1.4 card 
<rick_h_> bac: ok cool, will hold off
<rick_h_> jujugui very small docs branch for review please. https://github.com/juju/juju-gui/pull/387
<frankban> rick_h_: done
<rick_h_> frankban: ty much
<frankban> rogpeppe1: could you please review https://github.com/juju/juju/pull/92 ?
<rogpeppe1> frankban: looking
<rogpeppe1> frankban: reviewed
<frankban> rogpeppe1: thanks +1 on adding a dependencies.tsv to charmstore
<frankban> rogpeppe1: and here it is: https://github.com/juju/charmstore/pull/4
<bac> frankban: changes made, so please have a look when you can: https://codereview.appspot.com/108930045
<bac> frankban: the changes did simplify the tests somewhat, which is always a good sign
<frankban> bac: I'll look in a minute
<frankban> bac: great
<rogpeppe1> frankban: LGTM
<frankban> rogpeppe1: thanks
<rick_h_> hatch: morning, happen to still have the charm files downloaded? 
<rick_h_> hatch: I was mistaken in not doing the precise charm
<hatch> I do yep
<hatch> oh ok
<rick_h_> luca: heads up, shot down on a deploy on friday by IS so I'm on the schedule for a deploy first thing monday morning
<rick_h_> hatch: cool, if you can merge/update the precise one as well and let me know I'd appreciate it. I want to hold off on the blog post until that gets ingested. 
<luca> rick_h_: bloody IS! jk no problem, monday might be a better day to do it
<rick_h_> luca: yea, sorry for the delay. We didn't quite get things wrapped up in time yesterday
<frankban> bac: review done, thanks for the changes
<luca> rick_h_: did we solve the onboarding issue?
<rick_h_> luca: well after looking at it it's not a total mishap. It doesn't show in the right place, but the image is still good/sound so we decided we could release as is and update it
<luca> rick_h_: ok, can I see it on comingsoon/mv?
<rick_h_> luca: no mv needed. Just go to comingsoon, click in the "Help and feedback" and click on tutorial
<rick_h_> luca: then go next/next until you see the inspector one
<luca> ok, thanks. Will check it out
<rick_h_> yea, appreciate the look and we'll be bugging you to find out how you want to handle moving/adjusting it. 
<rick_h_> luca: then again, with the MV and other onboarding stuff on the schedule not sure if it's worth the time to update. 
<luca> rick_h_: yeah
<luca> rick_h_: in the onboarding the inspector is still on the right hand side
<rick_h_> luca: right, that's what we're talking about. It's kind of tossed up there like a headless ghost
<rick_h_> luca: but to move it over to the left doens't quite work out as a static image since the height is 'whatever the user's browser is'
<rick_h_> luca: but as for a tutorial of "here's what a cool inspector looks like' the image is accurate and recognizable so left it for now
<hatch> I am inspector, hear me roar 
<hatch> rick_h_ ok the precise charm has been updated - so I'm guessing 30mins or so and it should be live
<rick_h_> hatch: rgr, thanks. I'll keep an eye on ingestion
<hatch> rick_h_ after the call today did you want to chat about that rendering perf stuff? Or beore?
<hatch> before
<rick_h_> hatch: either or works for me
<hatch> sure, I'll hop in the friday room now
<rick_h_> k, /me finds headphones
<luca> rick_h_: itâs looking all good to me and Ale, lets launch. Weâll change it soon.
<rick_h_> luca: sounds good, will launch it monday
<rick_h_> I'll have a release blog post up in a bit here once the charms are loaded into charmworld
<luca> rick_h_: thanks rick + team :)
<rick_h_> jujugui team rocks :) and call in 12 so kanban it up please. 
<hatch> for those who use w=1 on github....are you still able to comment on the code with w=1? the commenting functionality doesn't work for me
<bac> jujugui: i cannot get to the calendar so i don't have the URL.  can someone paste it please?
<rick_h_> sure thing
<rick_h_> bac: https://plus.google.com/hangouts/_/calendar/cmljay5oYXJkaW5nQGNhbm9uaWNhbC5jb20.t3m5giuddiv9epub48d9skdaso?authuser=1
<rick_h_> jujugui call about now
<rick_h_> jcsackett: ^
<rick_h_> kadams54: ^
<jcsackett> rick_h_: freaking google is saying i don't have the plugin *again*.
<jcsackett> working on it.
 * jcsackett is growing to loathe google.
<kadams54> having problems connecting as well
<kadams54> The little green quotes icon just keeps jiggling away
<rick_h_> kadams54: chrome did that to me yesterday had to use FF
<hatch> rick_h_ hey when you get a chance I need a set of tasks for focus on
<hatch> shall I do the cleanup now?
<rick_h_> hatch: yea, I think if you don't mind I'd like to move forward on those
<rick_h_> and then we'll pull makyo back over from IL to MV 
<hatch> sure, sounds like a plan
<hatch> woah I'm working on something that's not unsched
<rick_h_> hatch: but let me know if you want a break and work on something else. Nothing in there is required this week kind of stuff
<rick_h_> :)
<hatch> nah it's ok - unless you want me to go work on some three.js for fun today....
<hatch> no?...
<hatch> :P
<rick_h_> hah
<hatch> I swear it has implications for the GUI!
<hatch> haha
<rick_h_> hey, you were all happy to be working on sched work for a change. Why mess it up? :P
<hatch> haha
<hatch> living closeish to the airport is kind of cool, there are so many cool planes 
<bac> frankban: hey, got a second to look at jenkins for brew? http://bot.brew.sh/job/Homebrew%20Pull%20Requests/11953/version=mavericks/console
<bac> frankban: it looks like even calling '--version' is pulling in urwid that is failing on their test platform, likely due to being headless
<frankban> bac: sure
<frankban> bac: looking
<bac> frankban: it is in manage/_create_save_callable.  i wonder if we moved the import of cli.views locally if it would go away
<frankban> bac: importing views should not run anything at module level
<frankban> bac: _start_interactive_session is explicitly cvalled in the traceback
<bac> frankban: yeah, i see that now
<frankban> bac: this smells: pkg_resources.run_script('juju-quickstart==1.3.5', u'juju-quickstart')
<frankban> bac: it seems quickstart is run without --version for some reasons
<bac> frankban: i think that is ok b/c sys.argv is being set prior
<frankban> bac: yeah
<bac> frankban: this works for me:
<bac> [bac@sol ~]$ /usr/local/Cellar/juju-quickstart/1.3.5/libexec/bin/juju-quickstart  --version
<bac> juju-quickstart 1.3.5
<bac> frankban: i think the problem is we're deciding whether it is interactive or not before processing the command line args
<bac> so we see it is interactive even though --version won't take advantage of it
<frankban> bac: if --version is set, parser.parse_args() should call sys.exit before even caling _setup_env
<bac> frankban: yep, verified
<frankban> bac: so something in their environment is preventing argparse to exit
<bac> frankban: or it isn't getting the argument
<frankban> bac: yes
<bac> frankban: shifting gears, any thoughts on the precise / mock version issue?  we rely on mock >= 1.0.1 pretty heavily.  seems like a backport is in order.
<frankban> bac: to launch tests on precise?
<bac> frankban: yes, the tests fail on precise.  let me grab the log
<frankban> bac: don't we install mock with pip? 
<bac> frankban: https://launchpadlibrarian.net/177510623/buildlog_ubuntu-precise-i386.juju-quickstart_1.3.5%2Bbzr80%2Bppa23%7Eubuntu12.04.1_FAILEDTOBUILD.txt.gz
<bac> frankban: the build farm doesn't appear to use pip.  only installs ubuntu packages
<bac> makes sens
<bac> s/sens/sense/
<frankban> bac: so I guess you updated the packaging repo to run the tests before building 
<frankban> bac: and that's really good
<bac> frankban: i did not consciously do that
<frankban> bac: :-) but it is there (in debian/rules) I think we have two options: 1) as you mentioned, backport mock, and put it on the PPAs (it should be easy) or 2) change debian/rules so that tests are run with make check
<frankban> bac: if the current packaging setup reflects the one used by the distro release, then I'd vote 1)
<bac> frankban: oh, ok, that was part of the reconciling with the ubuntu package that robie requested
<bac> frankban: yes, that is the case
<bac> frankban: yeah, backport seems the way to go
<frankban> bac: yes, the brew stuff instead is weird
<bac> frankban: back to the brew issue, i've got no ideas.  testing is pretty heavy weight, too
<bac> frankban: going to grab lunch.  if you have any bright ideas before your EoD i'm all ears! :)
<frankban> bac:  I see a problem
<frankban> bac: "JUJU_HOME=/tmp/frack juju-quickstart --version" works
<frankban> bac: "JUJU_HOME=/tmp/frack juju quickstart --version" starts the interactive session
<frankban> spot the difference
<rick_h_> dashes are important? :)
<hatch> rick_h_ fyi - I have an env spinning up to test that latest bug report
<rick_h_> hatch: ok cool. I replied and added a card for that. Kind of floored. 
<hatch> I'm guessing that I won't be able to reproduce :)
<hatch> it's a little sparse on the details but who knows, maybe Ill get luky haha
<rick_h_> heh, yea it is a bit vague but sounds like "gaaahhhh the horror everyone is dead!"
<hatch> lol!!
<hatch> "I'm not dead yet"
<rick_h_> and you can't help but want to ask "it's ok now...tell us what happened out there?"
<hatch> haha
<frankban> bac: I've found the problem: it is a juju-core bug: in juju/cmd/envcmd/environmentcommand.go:environCommandWrapper.Init, if the default environment cannot be retrieved, the wrapped EnvironCommand.Init is not called. For this reason, without a juju environment, basically juju does not pass the arguments to the plugin
<frankban> rogpeppe1: ^^^
<kadams54> guihelp: any of the US/CA folks know if we need to stay a Saturday night for the sprint?
<frankban> bac: so, a solution for brew could be testing juju-quickstart --version and not "juju   quickstart"
<hatch> kadams54 why?
<rick_h_> kadams54: I found if I flew out sat I was ok. 
<hatch> oh I see
<kadams54> I was initially planning on flying out Sunday, 7/20 and coming back Friday, 7/25
<rogpeppe1> frankban: hmm, i don't understand how this is a bug
<rick_h_> kadams54: the price diff for the extra day wans't that much
<hatch> kadams54 I find it best if you pick a flight that gets there in the MORNING on sunday
<rogpeppe1> frankban: if Init fails, surely things should progress no further?
<kadams54> Is the price diff just in flights, or does it have to do with the hotel as well?
<rick_h_> kadams54: yea, I'd plan on flying out sat and arriving sunday on the overnight flights. At least what I tend to do. 
<hatch> then you stay up until about 9pm, and you're minimally jet lagged on monday
<frankban> rogpeppe1: IMHO Init should not fail if there is no default env
<hatch> yep same here
<kadams54> OK, will do.
<rogpeppe1> frankban: it only fails if there's no default env and no environment has been explicitly specified
<hatch> it was considerably cheaper for me to stay an extra day on the front
<hatch> like $400 
<rick_h_> right
<frankban> rogpeppe1: no default env, and even no juju home can be an expected use case for plugins. e.g. that's the exact case for quickstart
<hatch> but I haven't booked the flights yet so will see :)
<hatch> but as it stands right now I'll be landing there Sat morning
<rogpeppe1> frankban: so how is an environment command supposed to know what environment to operate on?
<rogpeppe1> frankban: if there's no default env and no env specified
<frankban> rogpeppe1: right now juju still calls the external plugin but doesn't pass arguments, and that seems broken
<hatch> kadams54 the hotel rooms are about $200USD/night so you can take that into consideration
<kadams54> Are we flying into Heathrow?
<hatch> yes
<hatch> LHR
<hatch> there are some tricks to getting around too which we can fill you in on
<hatch> I've spent a bunch of time exploring :)
<rick_h_> lol, don't walk there :O
<hatch> why noT!!!!
<hatch> lol
<frankban> rogpeppe1: quickstart is a plugin, and handles the fact there is no default env pretty well
<rogpeppe1> frankban: ha, so all plugins have to be env commands
<rogpeppe1> frankban: i'd missed that
<frankban> rogpeppe1: in general, I think finding the environment to work with should be plugins' business
<rogpeppe1> frankban: yeah, i'm not sure why RunPlugin is doing what it's doing
<kadams54> I've heard the Jack the Ripper Walking Tour is not to be missed.
<frankban> rogpeppe1: that's not an urgent bug, we can work around that: bac: I am +1 on avoid testing both juju and quickstart in brew. we are interested in quickstart, and I assume juju is tested as well when installed by brew. so just adding the dash hopefully will fix the problem
<rogpeppe1> frankban: ah, it's just so that the juju env can be passed in an env var rather than as a flag. i guess it saves the plugin doing all the JUJU_ENV magic
<rogpeppe1> frankban: ha, and extractJujuArgs is horribly bogus
<rogpeppe1> frankban: it won't work if you do juju someplugin -e=foo
<rogpeppe1> frankban: or (assuming there's another single-letter flag, say -z) -ze foo
<frankban> rogpeppe1: yeah, there is area for improvements in that part of the code: silently removing arguments is not good
<rogpeppe1> frankban: silently *perhaps* removing the *possibly wrong* arguments is even worse
<frankban> rogpeppe1: :-)
<rogpeppe1> anyway, it's trivial to work around
<rogpeppe1> for the time being
<rogpeppe1> just set JUJU_ENV=xxx
<hatch> rick_h_ on the latest Safari even accepting the self signed cert isn't making the GUI load
<hatch> invalid certificate chain on the websocket it's saying
<rick_h_> hatch: there's a trick to it
<rick_h_> hatch: you have to hit an extra button and accept. 
<rick_h_> hatch: let me get my laptop, sec
<hatch> ohh lol
<rick_h_> hatch: is there an env you have up and running?
<hatch> yep
<rick_h_> sec, let's hangout and I can show it, easier that way
<rick_h_> hatch: standup?
<hatch> sure sec
<kadams54> US peeps: am I correct in thinking that I don't need a visa?
<hatch> are you a criminal?
<kadams54> Nope
<hatch> then you should be ok lol
<rick_h_> lol
<hatch> sorry that was phrased wrong
<hatch> have you ever been CAUGHT 
<kadams54> British Embassy web site is telling me I don't need one, so I think I'm good :-)
<hatch> :P
<kadams54> lol
 * rick_h_ goes to get lunchables. 
<hatch> I'm in the common wealth - I walk in, fist bump the guards and carry on
<kadams54> Ha!
<hatch> rofl
<kadams54> In my head you said "G'day mate" while doing that.
<kadams54> So a lovely mismash from across the commonwealth.
<bac> going through customs to enter montreal was one of the most pleasant of those experiences
<bac> dude was bored, i guess, wanted to talk about agile development, etc.  was very odd.
<bac> well, bored and nerdy
<hatch> kadams54 lol!!
<hatch> bac haha cool
 * rogpeppe1 is done for the day
<rogpeppe1> happy weekends all
<hatch> enjoy your weekend rogpeppe1 
<bac> wow, backportpackage is the world's best thing ever!
<bac> backportpackage -d precise -s trusty -u ppa:juju-gui/quickstart-beta python-mock
<bac> done
<rick_h_> bac: you don't say...that looks kind of cool
<bac> easy and worked.  usually you don't get both.
<rick_h_> ok, I'm outta here. Time to pack the camper. Everyone have a great weekend!
<hatch> cya lata rick_h_  have a good one
<jcsackett> juju-gui: can someone tell me where existing services get loaded into the db?
<jcsackett> my ack and grep fu is weak.
<kadams54> jcsackett: ugh, I'm pretty sure frankban told me this onceâ¦
<kadams54> jcsackett: â¦but I've slept since then!
 * jcsackett laughs
<kadams54> Lookingâ¦
<kadams54> I think in models/handlers.js
<kadams54> Beginning on line 217
<kadams54> https://github.com/juju/juju-gui/blob/develop/app/models/handlers.js#L217
<jcsackett> kadams54: thanks.
<hatch> stepping away for lunch
<hatch> jcsackett if you're looking from via the delta path then the handlers.js is correct
<hatch> you can also grep for db.services to find places where it's interacted with
<bac> jujugui: anyone got travel auth from teh ramm yet?
<kadams54> Nope.
<hatch> bac yep and purchased
<bac> huh
<bac> what'd it cost?
<hatch> maybe I just got lucky
<hatch> or maybe I bought him a doughnut 
<hatch> ok now I'm really leaving for lunch :) 
<rick_h_> bac: not gotten anything either
<rick_h_> bac: on either of my trips
<bac> ok.
<hatch> holy smokes I almost forgot my juju env running
<hatch> jujugui do we know if an orange box can be hooked up to the interwebs for us to play with remotely for testing the gui?
<rick_h_> hatch: yes, they have a network attached to them
<hatch> rick_h_ ok cool thanks - I was hoping so, so maybe we could hook into an orange box to try and repro that bug
<rick_h_> hatch: removing luca from the sidebar bug. We've had the chat and the decision was to make hiding the sidebar a keyboard shutcut for pro users that don't need the show/hide handholding
<rick_h_> hatch: there's a card to work on it, I've added the bug number to the card
<hatch> ohh ok cool I didn't know about that - that's a good idea though
<rick_h_> yea, decent compromise and I think we can make machine view flexible enough to runwithout the widebar (hopefully)
<hatch> yeah I am pretty sure it's good to go css wise
<hatch> are you camping now?
<hatch> :)
<rick_h_> not yet, just finished loading up
<rick_h_> waiting for the wife to get home in 5
<rick_h_> and getting the boy prepped
<rick_h_> will probably be 'camping' in 2hrs ish
<hatch> ahh :)
<hatch> so much for 5pm camping :)
<rick_h_> yea, took a bit extra time to get everything ready. Really have to do some prep during hte week. 
<rick_h_> ok, well going to get finish up .
<rick_h_> have a good weekend!
<hatch> you too cya
#juju-gui 2014-06-15
<huwshimi> Morning
<rick_h_> morning huwshimi 
<huwshimi> rick_h_: Hey :)
<rick_h_> good weekend huwshimi? You guys do father's day yesterday?
<huwshimi> rick_h_: Yeah, busy. Mostly hanging out with people busy though. We do Father's day in September :)
<huwshimi> rick_h_: How was your weekend?
<rick_h_> good, got some camping in so fun
<rick_h_> have the in-laws over for father's day atm
<rick_h_> so hiding in the basement :)
<huwshimi> haha
#juju-gui 2015-06-08
<frankban_> bac_: ping
<bac_> hi frankban_
<frankban_> morning bac_: did you have time to QA quickstart?
<frankban_> bac_: https://code.launchpad.net/~frankban/juju-quickstart/uncommitted-bundles/+merge/261200
<bac_> frankban_: i didn't.  i'll be home from PT in 30 minutes and will do so then.
<frankban_> bac_: sure thanks!
<jcastro> https://github.com/CanonicalLtd/jujucharms.com/issues/103
<jcastro> rick_h_: ^^ which URL are the blogs curated to?
<rick_h_> jcastro: the blogs we pull into jujucharms.com come from https://juju.ubuntu.com/feed/?tags=juju I think that's some form of insights feed? I'm not honestly sure. We got that url from the web team. 
<rick_h_> antdillon: can you speak to ^ please?
<rick_h_> ant will make it all make sense/awesome
<jcastro> yeah I just want to know where the end user consumable URL is
<rick_h_> jcastro: https://jujucharms.com/community/blog
<rick_h_> linked off the 'see more' on the front page and the community page
<jcastro> nice!
<jcastro> huh, the events show an expired one but missing one of the new ones
<rick_h_> that's pulled from https://insights.ubuntu.com/category/events/feed/?tag=juju
<antdillon> rick_h_, jcastro thats right it pulls from the juju.ubuntu.com
<antdillon> jcastro, events are from insights, ill check on the old one and missing event
<jcastro> aha, I was missing a juju tag
<jcastro> noted
<rick_h_> jcastro: ah cool ty
<stokachu> rick_h_: you around?
<rick_h_> stokachu: howdy
#juju-gui 2015-06-09
<urulama> jujucharms.com currently down
* urulama changed the topic of #juju-gui to: jujucharms.com is down ... Juju GUI - Mailing List  https://lists.ubuntu.com/mailman/listinfo/juju-gui
* urulama changed the topic of #juju-gui to: Juju GUI - Mailing List  https://lists.ubuntu.com/mailman/listinfo/juju-gui
#juju-gui 2015-06-11
<marcoceppi> hey guys, this is really cool btw: http://i.imgur.com/4Rz6OU6.png
#juju-gui 2015-06-12
<rogpeppe1> uiteam: FYI I can't connect to the canonical IRC server
<frankban> rogpeppe1: :-( no problems here
<rogpeppe1> frankban: i can't connect to github either
<urulama> rogpeppe1: hm. it is your ISP?
<rogpeppe1> urulama: probablu
<rogpeppe1> urulama: mattyw is having issues too
<frankban> rogpeppe1: yeah I think ISP problems
<urulama> rogpeppe1: oh, ok, UK hickups ... it'll resolve soon i hope
<urulama> rogpeppe1: does CS require PR397 to work properly? i reached the limit of mongo sessions, but then it did not bounce back, even if there were no cliets anymore, it states that mac mongo sessions reached
<urulama> rogpeppe1, mhilton: https://pastebin.canonical.com/133083/
<urulama> connections to db (entity) works fine, blobstore fails
<urulama> rogpeppe1, mhilton: ok, verified. these panics are caused by ingestion. we seem to close sessions for blobstore.
<mhilton> rogpeppe1, urulama: have we changed the blobstore dependency to the new version?
<rogpeppe1> mhilton: good question
<urulama> yes, new blobstore was required
<rogpeppe1> mhilton: it shouldn't matter actually
<urulama> blobstore 3e9b30af648f96e85d8f41f946ae4a1ce0ce588b
<urulama> which is latest
<rogpeppe1> urulama: interesting.
<rogpeppe1> mhilton: wanna investigate? i don't want to get too distracted right now
<mhilton> rogpeppe1: sure
<rogpeppe1> mhilton: thanks!
#juju-gui 2016-06-17
<arosales> hello 
<arosales> just as an fyi we continue to see these issues when trying to demo the gui at conferences:
<arosales> https://github.com/juju/juju-gui/issues/1685
<arosales> https://github.com/juju/juju-gui/issues/1765
<arosales> we will be sponsoring DevOp Days in Amsterdam next week and I am still seeing these issues in beta 9, reported a month ago
<arosales> I love showing the Juju GUI goodness, but this is a large blocker and pie in the face looking to show case the gui.
<arosales> As an fyi a lot of field folks deploy bundles via the gui and are currently working around this by memorizing bundle URLs, but that fails when they can't load bundle details into the gui :-(
<arosales> any help or thoughts on it would be appreciated
#juju-gui 2017-06-13
<dakj> hello everyone, someone can help to understand how to deploy Landscape-Client on a virtual server via juju gui? thanks in advance
#juju-gui 2017-06-16
<dakj> hello guy, i need a support with juju and its model. can anyone help me? how do i've to do for adding a new node on a model already present and deploy Landscape-client via gui? thanks in advance
