#juju-gui 2013-04-29
<huwshimi> rick_h_: sure
<rick_h_> huwshimi: https://plus.google.com/hangouts/_/21324660ffbef8901b7665922ca8fd083514e628?authuser=0&hl=en
<huwshimi> rick_h_: on way
<rick_h_> are you ready for some football! ... I mean landing!
<rick_h_> luca_: morning
<luca_> Hi rick_h_ how are you?
<rick_h_> luca_: tired :)
<luca_> rick_h_: hehe
<rick_h_> luca_: sorry for the asking around for stuff that's still coming. We're basically hitting feature freeze today and trying to squeeze every last bit we can
<rick_h_> luca_: do you guys have an asset for the reviewed charm graphic?
<luca_> rick_h_: interesting!
<luca_> rick_h_: you mean the star in the circle?
<rick_h_> luca_: I asked huw about it and he didn't see one last night and didn't get a chance to look at it last night. 
<rick_h_> luca_: correct
<rick_h_> luca_: I'd like to try to see if I can get something that 'works' in this morning asap
<luca_> rick_h_: do you need it as an svg?
<rick_h_> luca_: svg or png would be perfect I think. 
<rick_h_> actually, png would probably be best so we can sprite it with the rest
<luca_> rick_h_: ok, no problem, Jovan is on the case
<rick_h_> luca_: ty much!
<luca_> rick_h_: If its feature freeze today then if I supply enhancements tomorrow is there still a possibility to get those implemented? or is today the cut-off?
<rick_h_> luca_: so if they're bug fixes/tweaks there's a chance. but the goal will be to stop adding stuff and make what we have work smoothly
<luca_> rick_h_: right, ok
<rick_h_> luca_: so no promises. All depends on how much time we need to spend on polishing the stuff we do have. Why I wanted to get filters ready this morning so they get into the set of features to spend time polishing
<rick_h_> same with the provider failing indicators, etc
<luca_> rick_h_: I see
<luca_> rick_h_: thank you :)
<luca_> rick_h_: Has there been any conversation of when the next release is/could be?
<rick_h_> luca_: the goal is to get everything running today
<rick_h_> luca_: I've got 3 branches from the weekend that need to be reviewed and landed and we can't seem to keep charmworld (the backend) up and running atm so hopefully get all that in and by my EOD have things running
<rick_h_> gui default, provider notification in place, and search filtering working
<rick_h_> sorry, gui default == browser by default as some.ip.address/
<rick_h_> we'll polish and have another update release wed and then thursday change over jujucharms.com to point to the production setup we get going today
<rick_h_> is my understanding at least
<luca_> rick_h_: ok, that sounds good but also sounds like your gonna be super busy
<rick_h_> luca_: nothing different ;)
<rick_h_> come on the weekend!
<luca_> rick_h_: hehe, when are you flying to SF?
<rick_h_> luca_: sunday sometime
<luca_> rick_h_: ah, cool, looking forward to my 9 hour flight!
<rick_h_> luca_: heh, yea as much as I enjoy some of the europe visits, nice to just have a few hours in the air
<luca_> rick_h_: yea, its nice to be able to fly for a short time and get somewhere different.
<benji> yay, I got my internet working again <grumble>
<rick_h_> working internet > *
<benji> heh
<bac> what was the problem benji with your internets?
<benji> I wish I knew.  Ever 24 to 48 hours my router and/or laptop decide that they are no longer on speaking terms.  Rebooting just one or the other doesn't help, both have to be rebooted.
<benji> all the other devices in the house stay connected just fine
<rick_h_> jovan2: ping, can you help me with this badge? I'm trying to get things like up per the presentation but don't have exact numbers so winging it a bit.
<rick_h_> jovan2: http://uploads.mitechie.com/lp/approved-badge.png is what I've got working but the badge looks too big. You gave me a 40x40 svg that I saved to a .png for spriting. What size is that supposed to be?
<rick_h_> jovan2: and it looks like it's the same sized on the larger icon when viewing details? Is that correct?
<gary_poster> rick_h_, hi.  any word from Tom on schedule?
<rick_h_> gary_poster: no, I started to talk with him this morning but he ran to a meeting
<rick_h_> not heard back yet
<gary_poster> ok rick_h_ , please let me know how that turns out.  Maybe include me if you like.  I want two pieces of info: the answer to your request and the answer to arosales Friday request (the Monday/Wed/(Thurs)/Fri schedule
<gary_poster> )
<gary_poster> If I get that info without being involved, big +1 ;-)
<rick_h_> gary_poster: k
<gary_poster> but happy to be involved as well
<rick_h_> understood
<rick_h_> honestly, we've got our stand up in an hour and hoped to put sinzui on it since they've been working on this up to this point
<gary_poster> ok rick_h_.  makes sense (as long as it works out :-P )
<gary_poster> rick_h_, do you have any time to talk about a strategy for today--specifcally about a branch I am trying to land that you reviewed, and about spinners, and about how you want to work reviewing/landing the other branches you have pending?
<rick_h_> gary_poster: sure thing
<gary_poster> thanks rick_h_ guichat
<rick_h_> loading
<luca_> rick_h_: is there an ETA when the api will be up again?
<rick_h_> luca_: working on it
<luca_> rick_h_: ok
<rick_h_> luca ping, can you help me with this badge? I'm trying to get things like up per the presentation but don't have  exact numbers so winging it a bit
<rick_h_> luca_: http://uploads.mitechie.com/lp/approved-badge.png is what I've got working but the badge looks too big. You  gave me a 40x40 svg that I saved to a .png for spriting. What size is that supposed to be?
<luca_> rick_h_: 40px should be correct
<luca_> rick_h_: as far as I can tell from looking at the PSD's it is 40x40px
<rick_h_> luca_: ok, looks big from the use
<luca_> rick_h_: if you get it up today then we can take a look and tweak if need be
<rick_h_> luca_: yea, see the screenshot
<luca_> rick_h_: that screenshot seems to be zoomed in
<gary_poster> luca_, my understanding from Friday
<gary_poster> 's call was that we agreed that search filters are a very nice to have for this deployment, not a requirement
<gary_poster> was that your understanding, or did I mishear?
<rick_h_> luca_: it's not :)
<rick_h_> luca_: it's on a window that's only 960px wide, but it's not zoomed in
<rick_h_> luca_: putting it up for review and will try to have it for you guys to look at. That's an easy tweak we can do any time so if it's big now it's not killer
<luca_> gary_poster: filters were a requirement, categories were a nice to have.
<gary_poster> rick_h_, fwiw the whole image looks zoomed in to me too, just comparing service box sizes--you on a RMBP maybe?
<gary_poster> luca_, ah :-(
<rick_h_> gary_poster: no, just normal HD 21" display. Ok, I'll get it up and we'll go from there. 
<gary_poster> luca_, still don't agree that it is a blocker, but hopefully we don't have to have that discussion further.  :-) I am going to suggest/request that we prioritize fixes/polish to other parts of the UX first, and be able to hide the search filters if necessary.  Happy to have a call about this with you/ale/jovan to clear up my misunderstanding if desired
<luca_> gary_poster: the reason its classed as a blocker is that information has been streamlined in certain views which are prohibitive to use, and show less information than what jujucharms.com currently shows, the filters are used a validators for decisions and therefore are prioritised as a blocker. Categories are not seen in the same light. For example the Ubuntu series is not shown on the charm token and was instead highlighted by the 
<luca_> filters. It doesn't stop the use of the product and therefore can be classed as a NTH but the UX is degraded.
<gary_poster> rick_h_, I'm toying with idea of spinning up an EC2 GUI instance that we (1) turn sandbox on, (2) point to your ec2 charm thing, (3) use your "left hand default" branch with merges & conflict resolution from trunk
<gary_poster> managed in a shared separate branch, perhaps
<gary_poster> luca_, full ack that it is a very degraded experience without the filters.  full ack that we want them, and if we can have them by rollout, we should..  Moreover, because rick_h_ worked all weekend, we might.  However, I have two basic opinions about it in regards to schedule:
<gary_poster> (1) it is better to have this deployed this week without filters than to not have it deployed.
<gary_poster> (therefore it is not a blocker, technically)
<gary_poster> (2) As a corollary, polish on other elements should come first, and we should make sure we have an escape hatch if we decide that the search filters can't make the cut
<gary_poster> luca_, FWIW, if we agreed on the above, I would still say the chances are better than 60% that the filters will make it in this week.
<gary_poster> hey hatch, you start in half hour, right?
<rick_h_> luca_: staging is back up http://uistage.jujucharms.com:8080/bws/sidebar /cc gary_poster 
<luca_> gary_poster: I agree, there are higher priorities than filters but it has a huge knock on to the layout esp to the full screen charm browser. It's ok if you prioritise them below other stuff, we need to know as soon as possible if they don't make it in to figure out how to fix the layout in that case.
<luca_> rick_h_: thank rick :)
<gary_poster> luca_, understood and will do.  thank you.
<gary_poster> rick_h_, one more quick strategy call when you have a chance.
<gary_poster> I will be happy to put a timer on it for < 2 minutes :-)
<rick_h_> gary_poster: on standup[
<gary_poster> figured
<gary_poster> rick_h_, link?
<gary_poster> standup link
<rick_h_> https://plus.google.com/hangouts/_/cf491220dfb7736cee2876baf29110eeb52f5997?authuser=1
<gary_poster> wuld like to join
<luca_> rick_h_: API down again
<gary_poster> :-(
<hatch> gary_poster: yup I'm just finishing up breakfast and going through emails
<gary_poster> cool hatch.  let's talk/plan in 13 min or so ("so" being up to 30 minutes as you wish :-) )
<hatch> sounds good - might take me a bit to go through 50 emails :)
<hatch> apparently someone was working over the weekend :P
<gary_poster> :-)
<hatch> oh they ported a yaml parser from c to go and took a 37% hit in speed....ouch heh
<hatch> it only takes 0.3 seconds to build gojuju? wow
<hatch> the past two days were +16-20C and lastnight it snowed....
<hatch> gary_poster: ok guichat?
<gary_poster> hatch, on it.
<gary_poster> https://bugs.launchpad.net/charmworld/+bug/1170099
<_mup_> Bug #1170099: Promulgated branches not owned by charmers are not considered "reviewed". <charmworld:Triaged> <https://launchpad.net/bugs/1170099>
<rick_h_> thanks gary_poster 
<gary_poster> welcome rick_h_ (actually from sinzui on other channel :-) )
<gary_poster> rick_h_, I am going to work on getting the staging instance up rather than the filter review.  Is that ok?
<rick_h_> gary_poster: rgr
<gary_poster> or should I do filter review first?
<gary_poster> really up to you
<rick_h_> gary_poster: no, let's get it up. I'll try to create a new root branch from the first one that makse the browser default
<rick_h_> gary_poster: and pull the other two bugs, provider failures, reviewed icons on top of that
<rick_h_> if we can get 3/4 branches up and in front of UX that's a win imo
<gary_poster> ok cool rick_h_ .  Lemme know when you have that.  Maybe put that in a lp:~juju-gui branch so we can all manage if needed?
<rick_h_> gary_poster: I will say thuogh the bug found in current staging is something that will blow up a staging instance fo r us
<rick_h_> gary_poster: the test results threw out a new un-expected value and that caused some code to go boom
<rick_h_> abentley: is lokoing at it right now
<rick_h_> gary_poster: sure thing, I'll make sure to push them up there as a series of branches keyed off the browser default
<gary_poster> rick_h_, should I change gui ec2 config to point to manage ec2 config?
<gary_poster> I mean, point to your manage ec2 instance?
<gary_poster> We can switch it out easily enough
<gary_poster> later
<rick_h_> gary_poster: cool, sure we can http://ec2-54-224-248-114.compute-1.amazonaws.com/ is my instance running now
<gary_poster> cool rick_h_ will do
<bac> hey hatch
<gary_poster> bac hey.  quick call?
<bac> gary_poster: sure
<gary_poster> bac cool guichat
<hatch> fyi http://jsfiddle.net/ericf/FGu9G/ <- yahooapis.com on https ----- it's a secret ;)
<gary_poster> cool :-)
<gary_poster> benji, quick call?
<benji> gary_poster: sure
<gary_poster> thx guichat
<gary_poster> hatch do you have experience debugging JS memory leaks?
<hatch> yep
<gary_poster> hatch cool
 * hatch goes to newegg.com and buys more ram
<hatch> there fixed
<hatch> ;)
<benji> gary_poster: I lost you
<gary_poster> hatch, heh ok thx
<hatch> gary_poster: but seriously, I have done it quite a few times so I can take a look if you need
<gary_poster> hatch cool.  may ask benji to talk with you
<rick_h_> chrome heap snapshots ftw
<hatch> yeah it kind of sucks with YUI because it hides a lot of the sources
<hatch> but such is life
<rick_h_> gary_poster: ok, lp:~juju-gui/juju-gui/default-all-the-things is the merge of all three branches. Merged fine and qa'ing some. 
<hatch> 826 tests....wow I am sure we had less than half that when I started
<gary_poster> heh
<rick_h_> hatch: yea, and still need a bunch more
<gary_poster> thx hatch 
<hatch> oh I didn't write them all
<hatch> I was just using it as a time reference point
<hatch> :D
<hatch> gary_poster: I'm not sure that it's ever ok to use `verisimilitude` .....just saying ;)
<rick_h_> gary_poster: heads up that staging is up and enables QA of the branch you reviewed https://codereview.appspot.com/8651046/  [http://127.0.0.1:8888/bws/fullscreen/precise/varnish-2]
<gary_poster> hatch :-P
<gary_poster> rick_h_, great.  on  call will look asap
<rick_h_> gary_poster: np, cool
<rick_h_> hatch: Makyo bcsaller any of you able to do a second review on https://codereview.appspot.com/8797047/ please?
<Makyo> rick_h_, sure
<rick_h_> Makyo: ty much
<Makyo> rick_h_, hmm, quick question.  The icon looks fine but doesn't hold too much meaning on its own.  Are there plans for adding title texts to some of these down the road?
<rick_h_> Makyo: ah, probably should put a title on it. I missed it
<rick_h_> just means "Reviewed charms"
<Makyo> rick_h_, yeah.  Easy enough to tell from the source, but that won't be handy.
<rick_h_> Makyo: well on hover it'll come up
<Makyo> rick_h_, Sorry, I meant at the moment. I'm fine with hover.
<hatch> cool there is a Not LGTM as well as LGTM with the reviews
<gary_poster> jujugui call in 10; please update kanban
 * gary_poster sighs with relief
<gary_poster> jujugui call in 1
<hazmat> what's the hangout link?
<hazmat> nm
<hatch> there is  flash of 'add your new charms here' on trunk with rapi....is that expected or a bug with my code?
<hatch> http://xkcd.com/303/ "tests are running"
<hatch> http://xkcd.com/303/ "lbox is lboxing"
<hatch> ;)
<hatch> gary_poster: if you have a few minutes... https://codereview.appspot.com/8686047/
<hatch> I am pretty sure this is what you had in mind
<hatch> bac: how are things going with that conversion?
<gary_poster> hatch, cool looking
<benji> hmm, I've been waiting for an ec2 instance in "agent-state: not-started" state for 25 minutes.  I think it's not happy.
<rick_h_> doh, all the UX folks are gone. 
<hatch> look on the bright side....
<hatch> ...now you can do whatever you want!
<hatch> ;)
<hatch> big purple dinosaur as the new juju gui background coming up!
<hatch> does anyone know how to get db.charms.add({id: charmId}).load() to respond properly in the tests? I can't seam to find that being tested anywhere
<hatch> ^ jujugui
<gary_poster> hatch, I think there are tests of the load method itself, aren't there?
<hatch> that's a yui method
<gary_poster> I know hatch
<gary_poster> looking
<hatch> I was hoping some kind of a shim on the connection or something
<hatch> I may be totally missing it too :)
<gary_poster> hatch, test_model.js  it('must send request to juju environment for local charms') ?
<gary_poster> (and following)
<hatch> gary_poster: yep found that - I guess I could listen for that and then respond with the proper data
<hatch> I think...
<hazmat> gary_poster, diff for read-only mode server enforced.. http://paste.ubuntu.com/5616764/
<gary_poster> looking
<gary_poster> hazmat, short and sweet.  funny that filter can be .startswith('get') but looks right :-)
<gary_poster> hatch, LGTM with trivials, finally
<hatch> haha np - I figured you were busy and started on the tests :)
<gary_poster> :-) cool
<hazmat> gary_poster, if we were using 'status' it would be the exception, but we're not.
<gary_poster> right
<hatch> so how would I go about responding from stocketstub?
<gary_poster> hatch, there are lots of examples of that, I think
<gary_poster> looking
<hatch> hmm I haven't found any yet...but still looking
<gary_poster> hatch msg: conn.msg({op: 'login', result: true});
<hatch> hmm lemme try that - the socketstub code makes it look like that does nothing
<hatch> because onmessage is empty
<gary_poster> hatch, onmessage is the websocket api
<gary_poster> if you want to listen to a websocket message then you mockeypatch onmessage
<hatch> sure but conn.msg calls this.onmessage() which is empty, so I need to return that to the .load() method somehow
<hatch> maybe I'm just not getting it...
<hatch> :)
<gary_poster> hatch, look at app/env/base.js
<gary_poster> connect function
<gary_poster> this.ws.onmessage = Y.bind(this.on_message, this);
<gary_poster> in many tests, this.ws == SocketStub instance
<hatch> ahh ok so it's firing a msg event with the data
<gary_poster> right
<hatch> ok I'll setup a logger in there to find out the format of the response
<hatch> thanks
<gary_poster> benji is charm broken for branches or something?
<benji> gary_poster: not that I know of.  
<gary_poster> benji cool (you've been using it that way a lot I assume).  I got a start error that didn't look good
<benji> nope, it works fine for me
<gary_poster> great
<hatch> yeah ok I don't get it....for me to be able to fire an event from the socketStub i need it to be augmented with the yui event code
<fwereade_> gary_poster, who should I speak to about the impact of a change to ServiceDeploy.ConfigYAML handling?
<gary_poster> bac, do you have brain state from the above ^^^ or should I take it?
<hatch> I guess I could just overwrite the modelLists load method
<hatch> that would probably be the best
<gary_poster> fwereade_, try me. :-) I can spread the word if needed
 * bac looks
<fwereade_> gary_poster, bac: we're not compatible with python and the fix got lost in the noise, but we're doing it now -- in short it needs to be a map with the service name as a top-level key and the config map as a value
<fwereade_> gary_poster, bac: https://bugs.launchpad.net/juju-core/+bug/1167465
<_mup_> Bug #1167465: service set (and deploy) uses wrong YAML config syntax <juju-core:Confirmed for fwereade> <https://launchpad.net/bugs/1167465>
<gary_poster> fwereade_, ah right.  so how is that interpreted if the yaml has one name and ServiceName is another?
<fwereade_> gary_poster, bac: I think the use case is "single config file for your whole environment", but it was originally implemented before my time
<fwereade_> gary_poster, so if the service name is not present as a key, I think we would barf
<gary_poster> ah ok
<gary_poster> so ConfigYAML takes precedence over Config
<gary_poster> and nonsensical ConfigYAML == barf
<fwereade_> gary_poster, (given that use case, it's clearly crying out for a set-many-service-configs, butI derail)
<gary_poster> :-)
<gary_poster> fwereade_, happily atm that should not affect us: if we receive a yaml file we currently pass it to juju to handle
<bac> gary_poster: i can take this one next if you make a card
<fwereade_> gary_poster, honestly I will probably cause Config and ConfigYAML to be mutually exclusive if I'm not given a really good reason not to
<gary_poster> fwereade_, works for us.  We treat them that way.
<fwereade_> gary_poster, great, thanks
<gary_poster> bac, do we actually need to make a change?
<bac> fwereade_: the gui tests and throws an error if they are both presented
<fwereade_> bac, <3
<gary_poster> :-)
<bac> gary_poster: i'm not sure
<gary_poster> bac, I don't think we do.  We transparently send the file over
<fwereade_> bac, you shouldn't need to change anything unless you know of people depending on broken-style ConfigYAML usage
<gary_poster> right
<bac> gary_poster: ok.  there was an inconsistency that i just handled in the gui and i couldn't tell if this was it
<bac> clearly i misread
<gary_poster> ah.  bac, I think this is all there is to it: http://pastebin.ubuntu.com/5616924/
<gary_poster> we pass through config_raw transparently
<gary_poster> thank you for the heads up, fwereade_ !
<fwereade_> gary_poster, np, take care :)
<gary_poster> :-)
<benji> I have two reviews up that are related to one-another.  Both are small: https://code.launchpad.net/~benji/charms/precise/juju-gui/use-npm-cache/+merge/161477 and https://codereview.appspot.com/8686048
<gary_poster> benji, how much time do we save?
<benji> gary_poster: 1 and a half minutes
<rick_h_> benji: ooh, that's sweet to have it push new versions up. 
<benji> pretty much dead-on what we expected from the testing
<rick_h_> we just end up having to keep a secnod branch, add the file, commit, push, etc
<gary_poster> benji, cool.  so 4 minutes -> 2.5 minutes?
<hatch> gary_poster: do you feel that this test is a good enough way to determine that it's successful? https://gist.github.com/hatched/1556b19e5929742a846b
<gary_poster> looking
<benji> gary_poster: in my testing the baseline was 11.5 minutes (so 10 minutes after); this was using an m1.small 
<hatch> woah email flood
<benji> I tried testing with an hs1.8xlarge instance (which has an SSD) but juju doesn't understand that instance type.
<rick_h_> sorry hatch 
<rick_h_> :)
<hatch> lol it's ok it was just like 'ddddddddddddding'
<rick_h_> fancy email clients kill ya every time 
<rick_h_> notifications and such :P
<hatch> yeah - honestly I don't think I can switch to linux fully until it gets a nice email client
<benji> turning off email notifications is one of the best things I have ever done
<rick_h_> hatch: it's got a great one. mutt
<gary_poster> benji is that from deploy, or after juju-gui-source-stable -> juju-gui-source=lp:juju-gui and look at logs?  the former, I'm guessing/hoping?
<rick_h_> runs in a tmux session just peachy, never bothers me. 
<hatch> I use postbox
<benji> gary_poster: yep, that is from the moment the deploy command returns until the moment agent-state is "started"
<gary_poster> cool
<gary_poster> I suspect the second option would be closer to the 4->2.5
<benji> I really wanted to know what it would do with that mega instance (over 3 bucks an hour!) but since juju didn't grok it I decided to move on
<rick_h_> benji: does npm have the same issue as pip though? Serial installations of deps?
<hatch> rick_h_: postbox is great - it does threading, hiding 'quoted' emails, and it looks great to boot :)
<hatch> oh and it has google, linkedin, and evernote integration
<rick_h_> benji: I found that the d/l cache didn't help at all really over local pip mirror because most of the time was in running one setup.py install after another
<rick_h_> hatch: the only thing I wish I could do in mutt is mute a thread. One day I'll break down and write some script that'll add that thread to my imapfilters or something
<hatch> ahh yeah that is a great feature
<hatch> especially for things like google groups which send an email every time a thread is updated
<gary_poster> hatch, that looks good.  (1) undo your .load monkeypatch when you clean up!
<gary_poster> (2) assert that the charm doesn't exist before you wait on your promise
<hatch> definitely :)
<hatch> alright good idea
<gary_poster> hatch, you *could* assert in the load callback that env strictEqual env
<gary_poster> that would test a bit more of your code
<gary_poster> That came from thinking of other approaches than the load monkeypatch
<gary_poster> I can think of others, but that's the only real advantage I can see
<gary_poster> rick_h_, lp:~juju-gui/juju-gui/default-all-the-things doesn't exist afaict! :-)
<gary_poster> that's why my charm was puking
<rick_h_> gary_poster: oh, sorry I thought we weren't using it so cleaned up the branched 
<rick_h_> branches that is
<gary_poster> rick_h_, heh oh ok
<hatch> gary_poster: good idea, added
<gary_poster> cool hatch
<rick_h_> gary_poster: once I get qa on the provider UX that'll land and the only two left are browser by default (not happening) and the filters which needs review still
<rick_h_> gary_poster: the reviewed icons landed on uistage 
<hatch> alright taking lunch bbl
<gary_poster> rick_h_, I thought you didn't need qa on provider UX?  I can look if you want
<rick_h_> gary_poster: oh, your last note was you wanted to qa so figured I'd wait :)
<benji> rick_h_: I'm not sure SSDs would help, but going from an m1.small to an m1.xlarge helped quite a bit (the m1.xlarge has "High" disk performance and the m1.small has "Moderate")
<rick_h_> gary_poster: no, I think it's safe
<rick_h_> gary_poster: so nvm, I'll land that as well so 2/4 for UX then
 * benji resumes reviewing Rick's branch.
<gary_poster> :-)
<rick_h_> gary_poster: if you want the browser default back I can put something up. Sorry, kind of thought with the re-schedule things were changing
<gary_poster> 2/4: cool rick_h_ .  Yeah, sorry about miscommunication on qa.  I said I wanted to do it this weekend, but you said today that you thought it was fine.  I meant to let you land without waiting for me.
<gary_poster> rick_h_, sure let's put it up--or I can, assuming the merge is trivial
<rick_h_> gary_poster: yep, so far the merge has gone clean 
<gary_poster> cool
<gary_poster> rick_h_, remind me what the url is of your ec2 manage instance?
<rick_h_> gary_poster: just shut it down as staging and manage. are fixed
<rick_h_> paying for 5 running boxes :(
<gary_poster> rick_h_, oh, for good!!!
<rick_h_> http://manage.jujucharms.com/api/0/charms/interesting
<gary_poster> rick_h_, I mean, curtis thinks staging and manage are reliable now?
<rick_h_> so they're up and the bugs are in progress to prevent from happening again. 
<rick_h_> gary_poster: so they should be stable in the next day/two. For now we're fragile on upstream changes to data we'll be protected against. So my ec2 won't be any more stable than them it appears
<rick_h_> except I still swear canonistack if chaos-monkey'ing our staging instance
<rick_h_> gary_poster: so why I suggest going with manage.
<gary_poster> rick_h_, so manage works well enough for us?
<rick_h_> gary_poster: yes
<gary_poster> yay!
<rick_h_> gary_poster: so I'll probably update config-prod to point to it at some point in the future here this week. 
<gary_poster> great.  I will change charm too
 * rick_h_ taps keyboard waiting for uistage to update...
<hatch> gary_poster: you suggested moving endpoint.js handleServiceEvent into the modelController...but then we would need to pass along reference to the addServiceToEndpointsMap method as that should probably stay in endpoints.js so I'm not sure what we would gain by doing so....thoughts?
<gary_poster> hatch, I personally would like that last bit to be handled with an event or something
<gary_poster> to keep it separate
<hatch> ok so once the charm is available, fire an event, which the endpoints.js would listen to
<hatch> and then add it's endpoints
<hatch> I like it
<hatch> thanks for clearing that up
<gary_poster> cool, thank you
 * hatch didn't end up leaving to take lunch heh
<gary_poster> :-P
<gary_poster> "RETRY THIS TEST RUN!"
<hatch> http://xkcd.com/303/ "ITS TESTING"
<rick_h_> thanks benji, appreciate you bearing through it
<benji> my pleasure
<gary_poster> hatch, :-)
<gary_poster> benji, reviewed both of yours.  Did the tests pass?  Would you like me to qa it?
<gary_poster> sorry benji, my last two questions were re the charm
<benji> gary_poster: the tests passed recently, but I was so excited to have it working I forgot to run them on the most recent incarnation; I'll do that now
<gary_poster> cool benji thx
<hatch> gary_poster: so I wrote the stuff to do it via the event...but then I just noticed/realized that once the charm data is available we don't know what service that corresponds to
<hatch> if just going off of the charm populated attribute
<benji> gary_poster: I responded to your review comments.  I'll be happy to discuss synchonously or via the review.
<gary_poster> hatch, I'd make a closure
<gary_poster> benji, looking
 * gary_poster looked at the wrong one first apparently ;-)
 * gary_poster is concerned that our chat room name is NSFW if you type too slowly in Google
<gary_poster> benji guichat briefly?
<benji> sure
<hatch> could I get another review
<hatch> https://codereview.appspot.com/8686047/
<gary_poster> hatch fine with pushing to another branch, but you agree closure would solve trivially?
<hatch> gary_poster: well not really - I only have the service with a charm name - and from that comes a populated charm so the only way I can listen for it is with CharmList.on('*.populatedChange') at which point any state is gone
<gary_poster> hatch, but you have the service, so if you do an on with a function defined inline then the service will be in the function's enclosing scope
<hatch> oh I see where you're coming from - I'm not sure I like that as much
<hatch> then it's really avoiding everything that was setup with promises
<hatch> and we could just go with callbacks
<gary_poster> but a .then is a callback...
 * gary_poster doesn't understand objection :-)
<hatch> ok I clearly don't understand the comment then - I dont' see how it's any different than the current setup
<hatch> wana guichat?
<gary_poster> sure hatch, joining
<benji> gary_poster: changes done but I really need to take the trash off before they close so I'll land it in the morning :)
<gary_poster> heh ok thanks benji ttyl
<rick_h_> gary_poster: pushing up a branch for browser-default: lp:~juju-gui/juju-gui/browser-default
<rick_h_> gary_poster: the other three are landed and in trunk so included
<gary_poster> rick_h_, awesome! thanks.  Will switch to that in a few
<rick_h_> and with that, I run away and hide for the rest of the day
<hazmat> gary_poster, charm diff http://paste.ubuntu.com/5617460/
<hazmat> for read only support
<gary_poster> hazmat, great thanks!  are you landing rapi changes, or shall I?  I will prb do tomorrow--need to go
<rick_h_> and filters landed http://uistage.jujucharms.com:8080/bws/fullscreen/search/?series=precise&text=apache woot
<hazmat> gary_poster, rapi changes landed
<gary_poster> hazmat, awesome
<gary_poster> will get the charm in tomorrow then.  :-) thanks!
<hazmat> gary_poster, just wanted to get a review on the charm changes, its pretty innocous..
<hazmat> cool
<hatch> anyone available for a review? https://codereview.appspot.com/8686047/
<gary_poster> hazmat, I'm fine with you landing if you wish.  looks fine to me.  I'm mildly concerned that the behavior will be different between go and python, but we'll document
<rick_h_> hatch: not atm, but I can give it a look over tonight/tomorrow morning before you get going. 
<hazmat> gary_poster, sounds good, i'm giving it an end2end test atm.
<hatch> rick_h_: alrighty - check the kanban first just ot make sure someone else didn't already
<hatch> I just want to get this thing landed heh
<hatch> are these CI failures something we did? It looks to be happening a lot
<rick_h_> hatch it looked like failed calls to juju? i meant to ask earlier about it.
<hatch> yeah - I'm not really sure - will have to look tomorrow
<hatch> was thinking of getting started with https://play.google.com/store/apps/details?id=com.trello&feature=nav_result#?t=W251bGwsMSwyLDNd
<hatch> would like to just use evernote but they don't really have a good 'task list' sort of feature
<rick_h_> yea i like trello
<hatch> I'm really digging feedly so now I want something pretty for my notes haha
<hatch> I'm a sucker for a pretty UI :)
<rick_h_> lol
#juju-gui 2013-04-30
<rick_h_> benji: I'm trying to see via kanban if someone picked up hatch's review. How is that indicated?
<benji> rick_h_: we add a "tag" with our name on the "Advanced Settings" page
<benji> (double-click on the card)
<rick_h_> ah, gotcha
<rick_h_> thanks
<gary_poster> benji, rick_h_ fwiw you can also just hover over the tag icon for a quick look
<rick_h_> gary_poster: yea, I didn't think to look at the tag
<benji> cool
<rick_h_> I was expecting to see people put their faces on the card but none had them
<rick_h_> so was trying to think maybe notes, but nadda there and then decided to just ask 
<rick_h_> since benji's email just came by and I knew he was around :P
<rick_h_> luca_: can you make sure to run through the bugs marked 'incomplete' for the stand up today? I'd like to make sure we go through any questions and such.
<gary_poster> jujugui, today is my daughter's birthday so I'm using some of my accumulated extra hours today to spend some time with her.  Going with her to gymnastics in 10 or 15 and back in an hour or so.  probably long early lunch.  which is a long way of saying...anything I can do for people right now, quickly?
<rick_h_> luca_: https://bugs.launchpad.net/juju-gui/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.tag=charmbrowser+&field.tags_combinator=ANY&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_m
<luca_> rick_h_: will do
<rick_h_> oh, that was bigger than it looked
<rick_h_> sorry
<gary_poster> heh
<rick_h_> gary_poster: have fun!
<luca_> rick_h_: also, is there a known issue of the GUI being down?
<gary_poster> thanks :-)
<rick_h_> luca_: ah, was going to ask about that this morning. Figured it was to do with everything going down last night
<rick_h_> jujugui anyone know if we need to reset the charm/etc? The gui hangs on connecting to env
<bac> gary_poster: get pictures of her on the parallel bars
<gary_poster> rick_h_, will investigate.  bac, heh ok  will do 
<gary_poster> hey hazmat, the readonly stuff has broken improv. looks trivial.  could you make a quick fix?  not really here.  http://pastebin.ubuntu.com/5619066/
<gary_poster> I mean, I'm not really here. :-) daughter's bday, taking a few hours away in morning
<gary_poster> rick_h_, luca_ temporarily up.
<gary_poster> hazmat, we just need improv to have line 21 of http://pastebin.ubuntu.com/5619098/
<gary_poster> hazmat maybe we should put rapi-rollup in a shared place
<gary_poster> rather than ~hazmat :-)
<gary_poster> also, could you ping bac and me when this is fixed so we can make sure uistage is OK?\
 * gary_poster runs
<gary_poster> ttyl
<luca_> rick_h_: thanks :)
<rick_h_> luca_: heh, thanks gary_poster 
<luca_> rick_h_: did you want to screen share to see this bug while its up? https://bugs.launchpad.net/juju-gui/+bug/1174392
<hazmat> gary_poster, noted, fix in progress. will need to coordinate  a charm fix as well
<hazmat> for the branch move
 * hazmat notes improv should have a unit test
<bac> so in my raring VM, if i resize a terminal window it jumps back to its original size when i give focus to another window.  anyone seeing that on raring on metal?
<rick_h_> luca_: sinzui had that and was looking at it. Check with him at the stand up if he's found it and fixed it. Maybe just not released yet.
<luca_> rick_h_: kk, will do
<hazmat> rick_h_, fixed btw 
<rick_h_> hazmat: awesome thanks
<rick_h_> hazmat: do we need to get the charm updated them as well or is the uistage setup all set 100% ?
<hazmat> rick_h_, uistage auto refreshes, its sans charm
<hazmat> it does pulls from both branches on a reset
<hatch> we had a slush blizzard last night :/ I was driving home down the freeway and it was so icy that the wind was pushing the car into the other lane lol
<hatch> and this morning they look like a curling rink
<hatch> good thing my commute isn't that far
<rick_h_> hazmat: hmm, seems it updated and is down again. 
<hazmat> rick_h_, conflict error.. fixing
<rick_h_> thanks hazmat 
<hazmat> wtf.. bzr diff -> http://pastebin.ubuntu.com/5619274/
<hatch> time to switch to git? ;)
<rick_h_> hazmat: sssh, you'll get my hopes up
<rick_h_> oops, meant hatch 
<rick_h_> damn autocomplete with people matching first two cahrs
<hazmat> oh. somebody else logged in to hotfix the code hence the conflict
<rick_h_> hazmat: ah, sorry right. Gary did a cowboy before he ran. 
<hatch> rick_h_: lol - I'm sure the functionality is pretty close, but it's almost impossible to find out how to do things in bzr compared to the 1000s of git 'how do I do X' posts
<hazmat> rick_h_, working now
<rick_h_> hazmat: thanks
<rick_h_> luca_: alejandraobregon http://uistage.jujucharms.com:8080/bws/sidebar is back up and should be ok. 
<luca_> rick_h_: cheers
<hatch> rick_h_: has your phone updated to the new google play?
<rick_h_> hatch: yea, noticed it today. Well my N10 did. Haven't chceked my phone
<hatch> ahh - my n7 didn't but my phone did, it's almost unusable on my phone
<rick_h_> works well on the tablet, but that green on the app store side is fugly
<hatch> yeah - and the icon/title at the top when viewing an app takes up the top 1/3 of my phone screen
<hatch> google seems to have a thing for taking up usable space with chrome for no reason
<hatch> ' see google docs on a small screen' heh
<hatch> the old store had these fancy banner images and whatnot...this one is just a ton of ungodly slow loading icons
<hatch> I have a 3.75" screen though so maybe they didn't test it on anything smaller than a 4.5" screen haha
<hatch> rick_h_: FYI - that comment is confusing to me also....oops :)
<bac> morning hatch.  when you're free i'd like to pair with you for a bit to get this plugin properly moved into the tree
<hatch> alright couple minutes and I should be gtg
<hatch> bac: ok - lets do it
<bac> hatch: cool.  let me get arranged.  guichat?
<hatch> sure
<teknico> grunt, can't make charm deploy tests work, jitsu watch always failing to connect :-/
<hatch> do we know if gary will be back for the call?
<rick_h_> hatch: not sure. Sounded like it but maybe not
<Makyo> jujugui - call in 10, update kanban.  We'll run with it if gary_poster isn't back for the call.
<hatch> Makyo: what's been up with you rinternet lately? someone cut a fiber line during construction or something?
<Makyo> hatch, New router.  Will be switching back to the old before the call, if I have time.
<hatch> ahh - yeah that happened to me before - funny how such a 'simple' thing can cause so many issues
<hatch> benji: how did you end up with a 10G memory leak? lol my computer would have long since crashed by then :D
<benji> heh
<benji> I wasn't the original reporter, but I assume swap had something to do with it
<gary_poster> thank you Makyo! :-) I'm here, though I was thinking I asked for volunteers to run the meeting.  You up for it today Makyo ?
<Makyo> gary_poster, Sure.
<gary_poster> Thanks Makyo :-)
<Makyo> Swapping router real quick.  Fingers crossed...
<gary_poster> heh
<Makyo> \o/
<hatch> what was the old one so I know never to buy one :)
<Makyo> jujugui call in 2
<Makyo> hatch, Old one was a WRT54g, which works great, unless I put my phone on my desk, in which case it drops.  Also, it was time to switch to N.  New one was a Cisco E3200 which seems to have some problems running dd-wrt. 
<hatch> haha wow wrt54g that's a classic
<gary_poster> http://tinyurl.com/jujucharms
<bac> gary_poster: remind me the pw
<gary_poster> bac password is "password"
<gary_poster> bac that will go away
<bac> thx
<bac> benji you just need the hat.  http://assets.rollingstone.com/assets/images/artists/304x304/zz-top.jpg
<gary_poster> http://pastebin.ubuntu.com/5619568/
<gary_poster> LOL
 * gary_poster wants to get benji a beard extension
<hatch> hahahahaha
<Makyo> gary_poster, lost you :/
 * benji gets back to the hangout too late.
<benji> darn firefox crashed my computer
<rick_h_> doh
<rick_h_> gary_poster: will we have apache-like log tracking for metrics on the juju-gui to help us determine what *real* use patterns end up being?
<gary_poster> rick_h_, great question.  apache is our front end in the prodstack configuration, I know.  I'll ask news
<gary_poster> mew
<rick_h_> gary_poster: cool thanks. 
<rick_h_> jcsackett: hatch Makyo review request if anyone has time please. https://codereview.appspot.com/9052043
<Makyo> rick_h_, I'll take a look
<rick_h_> thanks Makyo 
<gary_poster> rick_h_, confirmed that we can get access to apache logs
<rick_h_> gary_poster: cool. Maybe an interesting oakland discussion might be analytics/metrics on things. Given xx charms in the intereste/featured which charms end up used more/less and such. What path people tend to use, etc. 
 * rick_h_ wonders if there's overlap in things done like in the software center
<ahasenack> gary_poster: hi, I just tried to install juju-gui using juju-core, basically just juju bootstrap + juju deploy juju-gui, and got this backtrace in the install hook, wondering if you saw that, before I start debugging: 
<ahasenack> gary_poster: http://pastebin.ubuntu.com/5619768/
<gary_poster> rick_h_, cool.  those analytics are going to come from the manage.jujucharms.com and charmstore logs, yeah?
<rick_h_> gary_poster: some, I imagined some would be the urls hit on the gui as well. Kind of correlated together. 
<gary_poster> benji, looking at ahasenack's report.  might be tied to your branch, or Kapil's.  ahasenack looking and will report back
 * benji looks
<ahasenack> gary_poster: ok
<benji> gary_poster: that's me
<gary_poster> benji, you on it?
<benji> Let me look at fixing it.
<benji> yep
<ahasenack> what is the branch, I tried lp:~charmers/charms/precise/juju-gui/trunk but it doesn't even have that file
<gary_poster> thanks benji.  if it is slow in the slightest please revert.
<benji> k
<gary_poster> ahasenack, lp:~juju-gui/charms/precise/juju-gui/trunk is true trunk.  We are the first experiment towards giving autonomy to blessed charm authors.  We need to not break the charm to have the experiment work out. :-/
<ahasenack> ah, right
<ahasenack> the default from the config
<ahasenack> no, wait
<ahasenack> that's the charm branch
<ahasenack> gary_poster: so for some charms it's taken from somewhere else? I thought all charms were in ~charmers/charms/
<benji> gary_poster: I'm testing the fix now by deploying the charm to EC2
<gary_poster> ahasenack, right, that's the way it has been, and that's the way jujucharms.com reports it, but it's not true for the charm store, and this not true for juju itself.  Like I said, this is an experiment to give trusted charm owners who (appear to? :-/) have a good quality landing process the ability to be masters of the official charm.
<gary_poster> thanks benji
<ahasenack> ok
 * gary_poster wants tarmac
 * benji too.
 * bac <3 tarmac
<benji> gary_poster: working charm verified, trunk has fix
<ahasenack> gary_poster: got something else now after i switched to juju-gui from ~charmers:
<benji> ahasenack: feel free to give it another tr
<ahasenack> gary_poster: http://pastebin.ubuntu.com/5619848/
<gary_poster> thanks benji.  ahasenack. should work now.  thank you for the report.  don't use the charmers one.
<ahasenack> gary_poster: bzr is not installed, is it normally installed when using pyjuju?
<gary_poster> ahasenack, we will be pushing the ~juju-gui charm to charmers while we are in this transition period. In fact I'll ask m+3 to do so now.
<ahasenack> gary_poster: is that a juju-core incompatibility? Just curious, will try the one from the charm store now
<gary_poster> hey m_3.  When you get a chance, could you push the ~juju-gui juju-gui charm to the ~charmers?  I'll make an MP if you need it.  My concern is that people are going to be confused until jujucharms.com points to the right charm, which may not be for awhile.
<gary_poster> ahasenack, I don't know why bzr is not around in that traceback, but what it is trying to do will absolutely not work in juju-core.  The ~charmers branch doesn't support juju-core (until we push the ~juju-gui one over)
<ahasenack> ok
<ahasenack> bzr is not installed in the instance, fwiw
<ahasenack> at least not in PATH, I didn't actually check dpkg, and I took it down now
<gary_poster> ahasenack, understood.  Thank you, and sorry you ran into this.  We'll improve our process some more.
<ahasenack> np
<gary_poster> rick_h_, gave you a quick LGTM fwiw
<rick_h_> gary_poster: thanks
<ahasenack> gary_poster: deploying juju-gui with juju-core worked now
<gary_poster> yay, ahasenack!  It should, we worked hard enough for that to happen. :-)
<ahasenack> :)
<ahasenack> gary_poster: the gui user is now called user-admin? Or was that just a ui hint?
<gary_poster> ahasenack, it's a juju core change.  I think we will probably want to hide the user- prefix in the future.
<gary_poster> it will matter when juju grows authentication
<gary_poster> real authentication :-)
<gary_poster> benji, out of curiosity, have you been able to dupe memory leak?
<gary_poster> AIUI the chrome tools are the best
<benji> not yet, I've hacked up an improv script that continuously sends huge deltas but no leaks yet
<gary_poster> huh
<benji> the chrome tools do seem to be the best
<gary_poster> benji how many services/units?
<benji> I'm starting to think that the kind of delta might be the issue
<benji> 5
<gary_poster> hm
<benji> the deltas are annotations
<gary_poster> benji 5 services, 1 unit each?
<benji> yep
<bac> hey gary_poster, in my testing i need to show that the textarea heights are being computed correctly.
<bac> gary_poster: but i'm getting different values when running test-server vs test-debug
<benji> for testing my current hypothesis, the number of services doesn't matter
<bac> i assume this has been dealt with before...  any pointers?
<gary_poster> benji, dunno, but he had N services/2000 units
<benji> right
<gary_poster> bac, um.  the closest tests I know of are the hairy ones for the help text
<bac> pointers that is for writing a robust test that deals with varying sizes across test environments
<gary_poster> bac, and sadly they are not the most robust.  they are not horrible, but they are one of the offenders
<bac> i can easily show that the textarea grows or shrinks as expected but fuzzily
<gary_poster> bac, that doesn't sound too bad...?  :-D
<bac> if its good enough for my rice cooker...
<ahasenack> gary_poster: I have a feeling I reported this already, but I don't remember. Can easily file a bug if needed: http://pastebin.ubuntu.com/5620058/
<ahasenack> happened when taking down the unit
<ahasenack> gary_poster: pyjuju doesn't run the stop hook iirc
<gary_poster> ahasenack, ah!  thank you, sure, bug would be great.  was not aware of that myself
<ahasenack> ok
<ahasenack> gary_poster: ah, found the original report: https://bugs.launchpad.net/charms/+source/juju-gui/+bug/1171490
<_mup_> Bug #1171490: "stop" hook fails <juju-gui (Juju Charms Collection):New> <https://launchpad.net/bugs/1171490>
<gary_poster> ahasenack, thanks!
<ahasenack> gary_poster: can I mark this one as fixed? The branch is merged, but bug is open: #1152631
<_mup_> Bug #1152631: Juju-gui installation fails from lp:juju-gui <juju-gui (Juju Charms Collection):Confirmed for gz> <https://launchpad.net/bugs/1152631>
<ahasenack> s/fixed/committed/
<ahasenack> I don't know how you guys handle "Released"
<gary_poster> ahasenack, it's released thank you.  I haven't been bug gardening lately
<gary_poster> will get to it soon
<ahasenack> np, I saw it by accident, I'm not stalking you :)
<gary_poster> ahasenack, lol, np
<benji> heh
<hatch> hav there been no proposals or anything all day?
<hatch> I haven't had any emails in a while...
<hatch> there they all come....
<rick_h_> bwuhahahaha
<rick_h_> email overload
<hatch> haha oh well
 * hatch pushes them off till later
<hatch> does anyone have any tips as to how to respond to env.get_service calls from within the application?
<fwereade> gary_poster, bac: would you consider it a good thing or a bad thing if I were to change Options on ServiceSet (hm, why not Config?) and Config on ServiceDeploy to map[string]interface{} (from map[string]string)?
<fwereade> brb
<bac> gary_poster: i've got a branch that adds the resizing plugin.  i'm going to get it reviewed and landed and then wire it up with our config ui
<bac> gary_poster: why do you need the change to the sig?  i guess going from specific to general is ok if there is a reason
<gary_poster> fwereade, I'm guessing this is to be able to get bools, ints and floats?  if we clearly know what to send you for each type, I think we can adjust.  we probably need a period of backward compatibility.
<gary_poster> bac I think you meant fwereade for the second one yeah?
<bac> oh
<gary_poster> bac for resizing sounds great
<hatch> oh I should pass the fakebackend stuff into my environment
<bac> fwereade: yeah, what gary_poster said.  we can adjust if the change is needed for internal purposes
<m_3> gary_poster: sure... sorry for the imcomplete changeover
<gary_poster> m_3, thanks, np
<fwereade> bac, gary_poster: well, the issue is just that untyped service config data is kinda... wrong -- it's not how we store it and it's not how we return it -- but the actual wrongness is in fact relatively low-impact: I *can* just fix state and leave the API untouched, and I should probably just do that
<fwereade> gary_poster, bac: I was only really asking in the hope that you'd say "oh god it's such a mess at the moment yes please" ;p
<fwereade> gary_poster, bac: and in the absence of that, I think it's best to keep compatible
<gary_poster> fwereade, heh.  The only related thing we'd say  "oh god it's such a mess at the moment yes please" is to divide up text lines and text multi-lines in the schema.  The fact that "string" can be either has consumed a sad number of days of development to produce an attractive UX that can look like a text line but expand to a text area.  It's just about done, but clarifying that would still be fabulous.  The other thin
<gary_poster> g you describe would be nice theoretically but is not causing us practical problems.
<m_3> gary_poster: they match now... I'll automate that until jujucharms.com is updated (requires sitdown in oakland evidently)
<gary_poster> cool, thanks m_3!
<fwereade> gary_poster, heh, I can imagine the hassle, but I can't see an obvious way to resolve it
<gary_poster> fwereade, cool, then at least we already have almost solved it. ;-)
<rick_h_> bac: might want to check out http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/lib/lp/app/javascript/formwidgets/resizing_textarea.js for any corner cases 
<rick_h_> bac: didn't look close but worth a run through. 
<bac> rick_h_: well, isn't that interesting!
<rick_h_> bac: sorry, thought it was tied to the editor stuff in LP and then you guys were going RTE and such so thought you were doing html -> plain text. 
<rick_h_> but seeing your Y.Plug looked famaliar :)
<gary_poster> boo hoo
<gary_poster> rick_h_, does that one have tests?
<bac> rick_h_: it should've been packaged as a YUI utility and open sourced.  then we would've found it
<rick_h_> gary_poster: definitely. 
<rick_h_> http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/lib/lp/app/javascript/formwidgets/tests/test_resizing_textarea.js
<gary_poster> rick_h_, bac, boo hoo.  talk it out among y'selves and figure out what to do?  I'll join if desired, and leave it to you to decide otherwise.
<rick_h_> gary_poster: sorry, just maybe run through mine and see if I covered any corner cases you didn't consider. Maybe check tests for ideas of tests missing
<gary_poster> rick_h_, well, yours is battle tested, yeah?  My default thought would be
<rick_h_> gary_poster: well been on LP for 6mo? so not aware of any bugs filed against it. 
<gary_poster> "Does the LP one behave the way we need it to?  Can we import it directly?  If so, let's use it."
<gary_poster> but bac, I'm leaving that decision to you, with me to help out or make a decision if you want me to.
<rick_h_> quoted from?
<gary_poster> sorry rick_h_ , I meant, that would be my default thought
<rick_h_> ah, gotcha. Thought I missed an email/convo I should have seen
<gary_poster> I was quoting my imaginary self ;-)
<bac> gary_poster, rick_h_: sure, i'd prefer to just use the one in production.
<rick_h_> bac :( so sorry I didn't come forward sooner. 
<gary_poster> bac, assuming it meets all our needs
<rick_h_> bac: really did think you guys were doing more html stuff
<bac> rick_h_: well, we didn't put out a group-wide call for ideas
<gary_poster> rick_h_, if you weren't here then we wouldn't even know now
<bac> gary_poster: yes, after verifying it works for us
<bac> gary_poster: if we use it, do we need to port the tests over or just treat it as 3rd party code?
<gary_poster> ok bac.  I'll hold off on reviewing the rest of your branch then.  FWIW, the only comment I had so far was that AFAIK we put files like this javascripts/assets and don't need a plugins dir
<gary_poster> bac, port tests: I would prefer so, yes.  LP is being maintained admirably, but...
<rick_h_> so bac, first glance I don't copy over all the font attrs, but I don't see you watching for window resize events that might effect the text input. 
<gary_poster> bac, alternatively you can release it separately :-P
<bac> gary_poster: we discussed that and thought assets was for 3rd party stuff.  since the plugin was home grown i treated it as such
<bac> gary_poster: if we use LP's then i'd put it in assets
<rick_h_> bac: I'd probably have done it in widgets even though it's not technically a Y.Widget 
<bac> yeah, well...
<bac> directories are cheap
<rick_h_> bac: true
<gary_poster> bac, ack. FBOW, ns-routing-extension, reconnecting-web-socket, d3-components, and app-subapp-extension are all precedent for our general-purpose code going in assets/javascripts
<rick_h_> ok, well let me know if I can be of any help bac. The tests and such are in that dir. To check it's use file a bug and on the bug entry it auto resizes. 
<bac> rick_h_: thanks!
<gary_poster> rick_h_, does it start at essentially a single line, or is it easy to make it do that?  bac, does yours work that way?
<rick_h_> gary_poster: it takes a min-height setting
<gary_poster> ok
<bac> ditto
<rick_h_> gary_poster: so filing bugs it starts out at some 50 lines ish
<gary_poster> cool
<gary_poster> cool thanks
<bac> wth FBOW?
<gary_poster> for better or worse :-P
<rick_h_> https://bugs.launchpad.net/juju-gui/+bug/1157138 and click edit icon on the bug description box
<_mup_> Bug #1157138: deploying a new service does not update service name in environment view <juju-gui:Fix Committed by gary> <https://launchpad.net/bugs/1157138>
<bac> ohs
<rick_h_> bac: FBOW?
 * gary_poster used it
<gary_poster> above
<gary_poster> my fault
 * rick_h_ is slow EOD :P
<gary_poster> I was overcome with a lack of desire to type "for better or worse"
<gary_poster> in punishment, I have now typed it twice :-P
<gary_poster> rick_h_, I'm going to try updating the demo site...
<rick_h_> gary_poster: k
<bac> rick_h_: yeah, that seems to be what we want, at least from playing with the bug entry box
<rick_h_> bac: :/ cool. 
<bac> rick_h_: i may bug you later.  let me pull it in and see what happens
<rick_h_> bac: definitely. anything I can do to help
<benji> ok, I have reproduced one delta-related leak: service annotations cause memory usage growth over time
<hatch> u go girl!
<hatch> gota love debugging those memory leaks
<hatch> usually when you find the cause you're like 'oh duh...no wonder this is causing a leak' heh
<gary_poster> rick_h_, OPTIONS from manage.jujucharms.com...interesting is not working from the GUI, at least over https
<gary_poster> rick_h_, see tinyurl.com/jujugui
<rick_h_> gary_poster: 'not working'? as in no response?
<rick_h_> looking
<gary_poster> rick_h_, I meant tinyurl.com/jujucharms sorry
<rick_h_> gary_poster: yea, fighting the app cache or something atm
<gary_poster> rick_h_, it loaded for me on one machine now
<gary_poster> trying first one again.  rick_h_ the https aspect appears to be a big issue
<gary_poster> because a lot faster over http
<rick_h_> gary_poster: k, the bug fix for the OPTIONS loading is on staging. but not manage. yet
<gary_poster> rick_h_, ah ok.  you want me to switch the jujucharms thing to staging?  Maybe just for a second, to see the difference?
<rick_h_> gary_poster: sure, but it'll be non-https so won't show the https overhead as well I guess
<gary_poster> rick_h_, oh right then it won't work
<rick_h_> gary_poster: mthaddon is past EOD but can see if mew can set it?
<gary_poster> nm
<rick_h_> bah, why won't the app cache load? but going straight to it laods
<gary_poster> rick_h_, you mean change it on manage.jujucharms.com?
<rick_h_> gary_poster: can see if mew can upgrade the rev on manage.jujucharms.com
<gary_poster> rick_h_, that would be cool
<rick_h_> we didn't update because the apache side isn't ready and mthaddon is EOD
<gary_poster> ah, gotcha
<rick_h_> coming empty for mew in #is 
<rick_h_> coming up empty that is
<gary_poster> k
<rick_h_> gary_poster: so yea, OPTIONS tooks 12s for me 11.5 of that receiving the 1.1MB payload
<gary_poster> rick_h_, ack
<rick_h_> gary_poster: that's fixed, so the first one will turn into a 200ms request
<rick_h_> the second one will still suck. I did some research today and it's the svg in the charms killing it. So have a card to re-thjink that. a single charm json dump goes frmo 3k to 48k with the icon
<rick_h_> since interesting is all the charms we've picked to have pretty svg icons it's all the charms that are giant and just makes it all worse
<gary_poster> rick_h_, ack, svg makes sense.
<rick_h_> gary_poster: ok, will hopefully have apache update tomorrow, will get a manage. deploy, and should help make a noticeable differnce with the long term plan to redo how svg/icons work.
<gary_poster> rick_h_, cool.  if we can svgs separately--and maybe only get the ones we see?--then that sounds good to me to keep the rest as is, at least for now
<rick_h_> gary_poster: yea, I'm thinking if we ship the visible ones, say 5 by default on sidebar, but do links servied from manage.jujucharms.com for the rest, they'll only load in small batches but be immediate for the first load
<rick_h_> gary_poster: but that's off the top of my head, will see about a real fix/get more opinions. 
<gary_poster> rick_h_, +1, though why don't we go for simplicity first and just load svgs as individual assets and see how that fares?
<gary_poster> less code, better than what we have now, might be good enough
<rick_h_> gary_poster: true, go all the way the other direction and see if we need to meet in the middle at all
<gary_poster> yeah, at least with the images
<rick_h_> gary_poster: right, agree
<gary_poster> cool
<gary_poster> trunk now hides the help text but I'm doing something wrong with a manual charm update...
<hatch> LFR https://codereview.appspot.com/9035045/ plz :D
<rick_h_> gary_poster: ok, abentley_ and I will work together to get a test of using links for svgs tomorrow and maybe we can revisit the staging site with some changes EOD tomorrow and re-evaluate
<gary_poster> cool thanks rick_h_ .  any word on how stability of manage is going?
<rick_h_> gary_poster: so we've got one *known* blocker where updates to the fulltext schema will break it. We have a card to get it into the data migration process to prevent it
<rick_h_> gary_poster: so should be stable except when we do the ont thing we know that breaks it :)
<gary_poster> heh
<gary_poster> ok
<gary_poster> have there been thoughts on how to make it more robust in general--isolation of some sort?
<rick_h_> gary_poster: but we also need a migration story for when upstream changes how they present test data which has bit us before. They're going to file a bug from now on, but we don't have a good way to sync the changes
<rick_h_> gary_poster: honestly, not a ton. Fire-fighting atm. 
<gary_poster> gotcha.  I wonder if that kind of change is what we really need before we say we are ready. :-/
<rick_h_> gary_poster: yea, but also we pull so much data from other places, bzr, juju gui stats, jenkins testing, we don't really know how fluid/etc those are yet because it's not been used. 
<rick_h_> gary_poster: we're learning, and catching up. 
<rick_h_> plus new tech to us like elasticsearch/mongo makes for fun learning and learning how to make it robust as well
<gary_poster> rick_h_, ack.  the last one (new tech) is just hard, no question.  I was thinking more of the first kind of thing, but granted that you want to trust data sources because it is a lot harder not to.
<rick_h_> ok, time to run away. have a good night all
<gary_poster> you too, night
<hatch> ok now I can finally get onto what I was working on last week wrt this service/charm stuff haha
<hatch> talk about a refactor
<benji> I hate consuming fundimentally non-visual technical information via video.  Write things down people.
<hatch> ^ that!
<jcsackett> rick_h_, hatch: can you think of any reason why calling .empty() would work in debugger, but not in regular execution? is "empty" timing sensitive?
<hatch> jcsackett: no it's syncronous
<hatch> the only thing I can think of is that the element is being re-rendered into the hole
<jcsackett> hatch: well, something should be rendered into the whole right after i call .empty. but with debugger right after .empty() everything renders as i expect afterwards. without, not so much.
<jcsackett> s/whole/hole/
<hatch> hmm without any more context I can't really say
<hatch> empty as far as I can tell will either error or work because all it's doing is calling remove and destroy on each child element
<jcsackett> hatch: so, what i need is to completely reset a node; like it's overflow etc, because just calling setHTML doesn't then have the node scrolled at the top.
<jcsackett> e.g. we render something that has overflow, we get scrollbars, but at render we're a few steps down.
<hatch> node.set('scrollTo', 0);
<gary_poster> hatch LGTM with small comments for test branch.  nice.
<hatch> thanks
<jcsackett> hatch: nope; it already shows scrollTo at 0, and setting it doesn't change it.
<jcsackett> like i said, this worked in tests, but the actual ui not so much.
<hatch> gary_poster: the reason why those clobberings aren't done in the beforeEach is because in the tests that don't clobber - if the code screws up it will cause the test to fail - which is what we want.
<jcsackett> unless i pause with debugger.
<gary_poster> hatch ok cool.  then go with my second suggestion :-()
<gary_poster> :-) I mean
<gary_poster> not blubber lips
<hatch> haha - can do!
 * Makyo dogwalks
<hatch> benji: are there any docs/email about how to use the npm caching stuff you did?
<hatch> jcsackett: does the content get deleted with empty?
<hatch> it just doesn't scroll to the top?
<benji> hatch: yep, docs/process.rst describes how to use it
<jcsackett> hatch: if i pause via debugger, i see it get deleted. then on resume the new stuff renders as we would like.
<jcsackett> if i don't pause, i don't see any evidence that empty was ever called, and the render problem is there.
<hatch> benji: thanks - the docs are kind of all over the place haha so I wasn't sure where to look
<hatch> the render problem being the lack of scrolling to the top?
<jcsackett> hatch: correct.
<hatch> hmm
 * hatch puts thinking cap on
<jcsackett> hatch: if it's not a simple thing, don't worry about it. i have just been reminded i have a dinner thing to get to today. i was just thinking there might be something simple about empty i didn't know.
<jcsackett> but if it's just a synchronous destroy as i thought, then alas, there is no such luck. :-P
<hatch> nope that sounds like some odd edge case thing to me
<hatch> does it do the same cross browser?
<jcsackett> hatch: yeah.
<jcsackett> confirmed on FF and Chrome.
<jcsackett> i'll pick it back up tomorrow, probably bug you more then. thanks for validating my fear, at least. :-)
<hatch> haha np have a good night
<jcsackett> you too.
<gary_poster> night all
<hatch> have a good night
<hatch> anyone around for a quick review? https://codereview.appspot.com/9035045/
<bac> rick_h_: your code went into our tree nicely and the tests seem easy to adapt
<hatch> he had already written the same thing?
<bac> thanks for the review Makyo.  that branch is being abandoned, though, for a better solution.
<bac> hatch: yeah.  very nice too.
<bac> hatch: part of an obscure skunkwerks project called "launchpad" :)  http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/lib/lp/app/javascript/formwidgets/resizing_textarea.js
<hatch> lol looking
<bac> about a zillion times better than the crap i was writing
 * bac walks dog to avoid face removal
<hatch> lol
<hatch> this looks good
<hatch> gona take a while to convert it all to camelCase
<hatch> ......KIDDING
<hatch> :P
<rick_h_> hatch: stay away! :P
<hatch> lol
<rick_h_> bac: cool, glad it works for what we need then. 
<huwshimi> rick_h_: I wouldn't start work on that icon sizes bug as it might be that Luca is mistaking the sizes with the featured icons which are larger (in both sidebar and fullscreen mode), unless of course things have changed. I was going to fix that up today anyway, but I might just reply to the bug with this note and see what he says...
<rick_h_> huwshimi: not following
<rick_h_> huwshimi: I know they said today they'll give us 3 dimensions to use for the badge later 
<rick_h_> huwshimi: since the badge is always 40x40 and is too big on the sidebar and not big enough on the charm details
<rick_h_> huwshimi: but my understanding is that if the url is /bws/fullscreen the charm-token icon should be 96x96 vs 64x64
<huwshimi> rick_h_: Right, that's what the bug says, but that's not what the visuals have, I just wanted clarification...
<rick_h_> yea, that's what I was telling them. They verified that's what they want
<rick_h_> huwshimi: so I think this one falls into the outdated visuals category :/
<huwshimi> rick_h_: I'm not convinced it's not an oversight... :)
<huwshimi> rick_h_: We need to clarify that they no longer want the sidebar "Featured charms" section at 96px now anyway, so I'll add a note to the bug
<rick_h_> huwshimi: ok, I'm missing something. WHen was featured 96x96
<huwshimi> rick_h_: Oh, actually the new WIP visual we got in that email thread the other day has 96px for everything. So you're right, it looks like it will change
<rick_h_> except sidebar, which is 64 right?
<huwshimi> rick_h_: There's no sidebar in that mockup, but I assume it'll be 64. No idea about the Featured Charms section though.
<rick_h_> k
#juju-gui 2013-05-01
<gary_poster> rick_h_, you want any huwshimi second reviews, or are you good to go?
<rick_h_> gary_poster: I'm waffling, all of these are trivial few liners
<gary_poster> rick_h_, :-) if I can help ping me
<rick_h_> gary_poster: so was thinking I'd just land and run, but feels dirty to land 5 branches sans second review :)
<gary_poster> lol
<gary_poster> rick_h_, I'll try to zoom through them.  Have you qa'd all of them?
<rick_h_> gary_poster: no, I haven't. I might build a super branch locally and run through them. 
<gary_poster> rick_h_, sounds perfect
<rick_h_> pastebin.canonical.com/90338/ for the quick run through list
<jcsackett> rick_h_: what's the url for the ec2 version?
<rick_h_> tinyurl.com/jujucharms
<rick_h_> jcsackett: ^
<jcsackett> thanks.
<gary_poster> rick_h_, https://codereview.appspot.com/9069043/ is not LGTM but I suggested a possible solution
<gary_poster> rick_h_, everything else is LGTM
<rick_h_> gary_poster: thanks 
<gary_poster> welcome
<gary_poster> rick_h_, did you try the z-index of 2 thing?  Do you want me to try it, to get that moving along?
<rogpeppe> gary_poster: you might be interested in this: it's an automatically generated description of the API, represented as JSON: http://paste.ubuntu.com/5622552/
<rogpeppe> gary_poster: in this particular case it happens to include the read-only client object too, as i'd just been hacking on that.
<gary_poster> rogpeppe, very cool!  :-)
<gary_poster> rogpeppe, are you hoping to process that for some automatic human docs?
<rogpeppe> gary_poster: that's part of the idea, yes
<gary_poster> rogpeppe, this might be nice also to have as an API call, even
<rogpeppe> gary_poster: that's what i'm thinking
<gary_poster> cool, yeah
<gary_poster> big +1 rogpeppe :-)
<rogpeppe> gary_poster: obviously it has limits (it can't know about the EntityInfo types, for example) but i think it's useful nonetheless
<rick_h_> gary_poster: I pulled it aside to clear the rest atm
<gary_poster> rogpeppe, definitely.  We'd be able to conditionally add upgrade charm, for instance.  this would immediately help that effort
<rick_h_> gary_poster: honestly, if it's a shadow thing I'd rather work on the api issues we've got and such at the moment. If you or someone wants to check with that I'd appreciate it
<rick_h_> trying to fry the biggest fish I can for today
<gary_poster> rick_h_, +1
<rogpeppe> gary_poster: i'm not sure i quite understand what you mean by that
<gary_poster> rogpeppe, sorry, yes, realized it was unclear as I sent it.  put more clearly, this would be a way for us to know whether to expose an upgrade charm interface in the GUI, which we are working on right now
<rogpeppe> gary_poster: ah, you mean have the GUI introspect the available methods and only allow some things if the API actually provides them?
<gary_poster> exactly
<rogpeppe> gary_poster: nice idea, yeah
<rogpeppe> gary_poster: it's potentially an interesting style of versioning
<gary_poster> agreed rogpeppe.  A declarative, fine-grained-but-seemingly-not-to-fine-grained approach that would allow  an unambiguous way of asking "hey local juju env, can you do X?" (assuming meanings of methods don't change, which they shouldn't)
<rogpeppe> gary_poster: yes.
<gary_poster> s/-to-/-too-/ :-P
<rogpeppe> gary_poster: and also "does the information for X contain Y"
<gary_poster> ooh, true
<gary_poster> that would be nice too
<gary_poster> jcsackett, big +1 on #1175150.  May I mark that high?
<_mup_> Bug #1175150: Fullscreen landing content should vary with sandbox setting <charmbrowser> <juju-gui:Triaged> <https://launchpad.net/bugs/1175150>
<gary_poster> from GUI perspective
<rogpeppe> gary_poster: pity it doesn't work for the delta info though
<jcsackett> gary_poster: i have no objection, but give your +1 to rick_h_. i was just making a bug for his card. :-)
<gary_poster> jcsackett, heh, ok cool :-)
<gary_poster> rogpeppe, deltas: nothing in the data structure here preventing that though, yes?  For example, you appear to have data characteristics as keys ("_nullable" and "_map").  You could have some kind of similar story for describing "a list of 1 or more of any of the following."  I suspect it is farther from the existing data structure than the code you have atm though
<gary_poster> re _nullable and _map, what happens if you have something that is both _nullable and a _map?
<gary_poster> nested structs?
<rogpeppe> gary_poster: it's a different issue than that - i'm generating the info from the Go data types, but the Go data type in this case is an interface - there's no way of knowing what objects it might hold
<rogpeppe> gary_poster: yeah
<rogpeppe> *map[string]int would look like {"_nullable": {"_map": "number"}}
<rogpeppe> gary_poster: it should be more intelligent about pointers actually.
<rogpeppe> gary_poster: 'cos a map is naturally nullable anyway
<rogpeppe> gary_poster: and json treats ***int the same as *int
<gary_poster> rogpeppe, nested structs: gotcha. different issue: yeah, I can see, but my point was that you can assemble the data structure from multiple sources--if the end goal is something consumable then having it be pure interface analysis is unnecessary. domain knowledge is AOK
<gary_poster> as long as the multiple sources don't potentially stomp on one another, which is the (slightly?) tricky bit I see atm
<rogpeppe> gary_poster: yeah, it needs a bit of thinking about. i think that it's good that the generation is as automatic as possible though.
<rogpeppe> gary_poster: otherwise description will rapidly lose sight of reality
<gary_poster> rogpeppe, strongly agreed generally.  But the delta structure really ought to be in there, I think, for the goals we want out of this.  OTOH, I'd be a big +1 for getting this general pattern in the code base without the delta information, as long as we knew we could slide the delta information in later.
<bac> gary_poster, rick_h_: textarea resizer and tests now in our tree and happy.  ready for review at https://codereview.appspot.com/9077043
<gary_poster> bac, looking, great.  rick_h_ is it a bg deal to get these in the YUI gallery or something?  Never done that
<rogpeppe> gary_poster: perhaps in addition to the method descriptions, we could include a map from interface (or custom marshaller) type name to a set of possible actual types
<gary_poster> bac LGTM
<gary_poster> rogpeppe, that would be nice.  So, completely separate data structure, IIUC?
<rogpeppe> gary_poster: then the API server would be responsible for filling in the set of types (it would know the set of possible delta types, for example) but everything else would still be automatic
<gary_poster> right
<rogpeppe> gary_poster: yeah; perhaps at the top level, to avoid another level. "_types": { .... }
<rogpeppe> gary_poster: alongside Client and Admin etc
<rick_h_> gary_poster: it's a little bit of work. The format/tests have to be in a certain way and they were changing that tooling. hatch might be up on it more. I got one into the gallery under the old tooling and it took a few days.
<gary_poster> sounds very good to me rogpeppe.  
<bac> gary_poster: thanks.  process-wise, i guess we could've explicitly reached out to the local JS experts, rick and sinzui, and they would've certainly pointed us in the right direction.  also, a more detailed discussion of the work we're each doing during the daily call.  i think you and i spoke in very vague terms b/c *we* knew the task but we didn't broadcast it so no one had a chance to contribute ideas.
<gary_poster> rogpeppe, do you have any idea on whether this might land soonish?  It would be nice for Makyo to rely on.
<gary_poster> rogpeppe, don't need the types for his use case FWIW
<gary_poster> rick_h_, urgh, a few days is a long time. :-/ ok, thanks
<rogpeppe> gary_poster: i've no idea tbh. i just remembered it this morning and it wasn't what i was meant to be doing at all :-)
<rogpeppe> gary_poster: i'd need to run the idea past william, who wasn't that keen last time i mentioned it, but we'll see
<gary_poster> rogpeppe, lol ok.  We do need an answer for "do we show the upgrade charm UI or not?" so we'd like this or some other solution soon.  Would it be worth me asking for some of William's time in this regard, or do you have another suggestion?
<gary_poster> bac, the "local" JS experts might include some U1 people too, as well as deryck, depending on our definition of local.  mm.
<rogpeppe> gary_poster: one possibility would be to actually try to make an upgrade-charm call (with invalid args). if you get a "no such request" error, you know it's not implemented
<gary_poster> rogpeppe, #1160971
<gary_poster> come on _mup_...
<gary_poster> https://bugs.launchpad.net/juju-gui/+bug/1160971
<_mup_> Bug #1160971: WebSocket disconnects when an invalid request is sent <juju-core:New> <juju-gui:Triaged> <https://launchpad.net/bugs/1160971>
 * rogpeppe was waiting for mup too
<rogpeppe> gary_poster: hmm, i thought i'd fixed that
<gary_poster> oh, that would be great!  we were just going by the bug :-)
<rogpeppe> aargh, why does pastebin.ubuntu.com discard its pastes?
<gary_poster> bac, I'll make a retrospective card with your notes.  thank you
<rogpeppe> that makes it a really terrible medium for attaching data to bug reports
<gary_poster> ah, argh, good point
<bac> thanks gary_poster
<rogpeppe> lunch time
<gary_poster> :-) ttyl
<rick_h_> gary_poster: yea, I knew you guys were working on something but I kept hearing about html. rte/YUI editor and you mentioned trouble of parsing down html to plain text or something. So I thought you guys were doing something more complex related to html edit
<rick_h_> gary_poster: and I didn't get too nosy about it until I saw bac's branch come by my email
<gary_poster> rick_h_, completely understandable.  We appreciate you looking at the branch when you did.
<hatch> morning
<gary_poster> morning hatch
<bac> rick_h_: could you do a review of my branch.  should look mighty familiar!  :)
<hatch> still lf one more review https://codereview.appspot.com/9035045/  plz :)
<bac> hatch: i will
<hatch> thank yas
<bac> hatch: done
<hatch> awesome
<hatch> gary_poster: new _buildServiceView thoughts? http://bazaar.launchpad.net/~hatch/juju-gui/view-promises/view/head:/app/app.js#L528
<hatch> I'm not sold so that's why I'm asking now :)
<gary_poster> :-) trying to regain context...
<hatch> that method is called anytime you visit a /service url to render the various service views
<hatch> this branch now uses promises for the service views and throws a notification if it's deleted while you're viewing it
<gary_poster> hatch, I suggest always using a promise.  I don't think the flash will be too bad.  From a UX perspective do you disagree?  Should I give it a try myself?  (To be clear, I mean http://pastebin.ubuntu.com/5622712/or similar)
<hatch> yeah the flash is pretty irritating
<gary_poster> ok, lemme look.
<hatch> you can see it by just removing the model param
<hatch> to really get the full annoyance change between the service views
<gary_poster> ack, getting branch
<gary_poster> heh, commenting out model param alone means it never renders.  trying fulling change...
<gary_poster> fuller
<hatch> er sorry
<hatch> comment out the ifblock leaving only the promise being assigned
<gary_poster> yeah np I see it.  looking further
<rick_h_> bac: can look at it. I was avoiding it as I was worried I'd be biased :P
<bac> i don't think bias will be a problem
<bac> thanks
 * gary_poster agrees
<hatch> rick_h_: I frequently look at old code I've written and go "what is this sh*t, who wrote this???"
<hatch> lol
<rick_h_> hatch: yea, I was feeling good when bac thought my old code was ok. Usually it's  more "who can I kill for this...oh right..."
<hatch> haha
<gary_poster> hatch brainstorm with me in guichat?
<hatch> sure
<rick_h_> bac: r=me, one comment
<bac> rick_h_: thx
<bac> rick_h_: i think i'll just modify the comment to be more generic.  the file is not a pristine copy as i had to change the namespace to juju.plugins.  i'll update the initial comment to reflect that as well.
<rick_h_> bac: cool thanks
<hatch> gary_poster: using showView we can set render: false at which point we can control the render cycle from within the view....ala problem solved
<hatch> we can move that 100ms uglyness into the view
<gary_poster> jujugui kanban now, call in 10
<gary_poster> bcsaller_, call now
<bac> was my camera working on that call?
<gary_poster> bac yes
<bac> huh, it showed my 404 icon to me
<bac> hope i didn't do anything rude
<gary_poster> :-) not that I saw
<rick_h_> doh, bac ran now
<rick_h_> bac: did you still want to chat?
<bac> rick_h_: i don't think so.
<rick_h_> bac: cool
<bac> thanks though.  i may bug you if i run into integration probs
<rick_h_> bac: sure thing, just say the word
<bac> grease?
<rick_h_> got that
<rick_h_> lithium ok?
<bac> "Grease is the word.
<rick_h_> ah, thought it was bird
<bac> or so says john travolta and olivia newton john
<hatch> the bird is the word
<hatch> the bird is the word
<hatch> the bird is the word
<hatch> the bird is the word
<hatch> the bird is the word
<bac> ok, googling "is the word" the first two hits are "bird is the word" and "grease is the word", in that order
<rick_h_> lol
<bac> so, you crowd followers can go with bird if you want
<bac> i'm sticking with grease
<hatch> I've never heard 'grease is the word'
<rick_h_> hatch is to young for grease 
<hatch> I think I've seen it once
<hatch> I have a very hard time seeing our local gangsters breaking out into song
<jcsackett> the local gangsters here don't sing; but they do occasionally snap their fingers in time and break out into complex street dances.
<hatch> and I bet those bastards interrupt traffic while they are doing it too.....ugh....youths!
<bac> i have yet to see any dancing thugs here in puerto rico.  false advertising if you ask me.
<hatch> gary_poster: fixes the env rendering and adds the promises into the buildserviceview http://bazaar.launchpad.net/~hatch/juju-gui/view-promises/revision/635
<jcsackett> hatch, rick_h_: can i get a review on the this very short branch? https://codereview.appspot.com/9088043
<rick_h_> jcsackett: sure thing
<jcsackett> thanks!
<hatch> yup
<hatch> jcsackett: so this fixes the scrolltop issue you were saying before?
<rick_h_> jcsackett: just one note. I'm assuming I know why you did it but small request. 
<rick_h_> gary_poster: I've got the ec2 setup with the test branches from abentley and I here: https://pastebin.canonical.com/90353/
<rick_h_> gary_poster: let me know when you get a chance and we can test things out.
<rick_h_> abentley: looks like /interseting goes down to around 180kb before gzip. icons are all sub 100ms here. Probably longer when it's on prodstack in london but cool
<abentley> rick_h_: Nice.  And we should get some caching from Apache too in production.
 * benji takes lunch.
<gary_poster> rick_h_, lemme get a review done and then I will hack on the demo to get that set up
<gary_poster> actually two reviews done :-)
<rick_h_> gary_poster: cool, giong to lunch it up myself
<gary_poster> great
<rick_h_> wow, 2pm where did today go? 
<gary_poster> hatch, checkShowEnvOrBrowser feels kinda hacky but fine as intermediate step/working with existing code.
<gary_poster> hatch otherwise looks really nice to me
<hatch> gary_poster: yeah I figure we need some type of a controller method for there
<gary_poster> hatch, why can't we just use a slash route for env view, as you said on call?
<hatch> because / still fires on /:gui: routes :)
<gary_poster> hatch, so?  env view would be registered for :gui:/ .  Probably missing something, but want know know what it is :-)
<hatch> well /:gui:/service/memcache still fires the / route because / is charmstore
<hatch> so if we put env on / then it's always rendered
<hatch> just like with *
<gary_poster> hatch does /:gui:/service/memvcache fire /:gui:/ ?
<hatch> not sure....sec i'll cehck
<hatch> doesn't appear to
<hatch> nor does path: '/', namespace 'gui'
<gary_poster> hatch, so can we register env view for that?
<hatch> that's exactly when we don't want it to render though
<gary_poster> huh? :-)
<hatch> we only want to env to render when it's not /service /charm/ or /logout
<gary_poster> hatch, but...guichat  :-)
<hatch> haha ok
<bcsaller_> hatch: by render you mean call topo.update()?
<hatch> nope, bcsaller_ can you join guichat?
<jcsackett> rick_h_: just played around and i cannot tell you how much better things feel with the spinner overlay. :-)
<rick_h_> jcsackett: :)
<jcsackett> hatch: sorry i missed your earlier message, yeah, this sorts what i was talking about.
<rick_h_> small touches, trick the user's mind. Love those kinds of things
<jcsackett> hatch: just scrolls an element that wasn't in the visible region to the visible rather than figuring out how to reset the scroll value for the view's node.
<jcsackett> rick_h_: i hear that. :-)
<jcsackett> and clearly my mind is happy to be tricked. :-P
<hatch> jcsackett: yeah that's very odd
<hatch> I have no idea why it wasn't scrolling to the top
<hatch> ok review is done /me going back to finish eating :)
<benji> hazmat: do model objects keep any kind of history or log of previous attribute values?
<bcsaller_> benji: model change events will have the old and the new values I believe but I also think that when that event has fired the info is gone
<benji> yeah I saw that, that's what made me wonder about them keeping more (I'm tracking down a memory leak)
<hazmat> benji, in py.  go. or js.  in js per ben's comments
<hazmat> have a look at  yui app model changed event
<hazmat> http://yuilibrary.com/yui/docs/api/files/app_js_model.js.html#l30
<benji> hazmat: are you saying that they do keep all previous values, or that if they do that would be where to find out?
<hazmat> benji, in js. its transiently.. the previous value is attached to the event, its not kept, as the soon event is gc'd its gone. if something is capturing/saving model change events, that would be an issue
<benji> gotcha
<hatch> benji: are you doing snapshots in chrome?
<hatch> benji: you can also watch the timeline for memory
<benji> I've played with them a little, but not used them in anger yet.  If you have experience with them a consult would be welcome.
<hatch> it can give you an indication of what's growing
<benji> I can't get the timeline to work.
<hatch> you have to hit the record button :)
<benji> hatch: you're psychic!
<hatch> lol yeah? why's that?
<gary_poster> bcsaller_, prelim review done.  call now.  will qa after.  at least one important note I think though
<rick_h_> benji: hatch there's also the speed tracer exention that's awesome
<bcsaller_> gary_poster: cool, thank you, reading now
 * rick_h_ tries to recall if that does memory
<rick_h_> nvm, don't see real memory usage there, just kind of UX slowness indicators
<hatch> yeah I think all of that stuff might be in the native tools now
<hatch> benji: really the first step to debugging a memory leak in js is the profiler and timeline
<hatch> so I can give you a hand to get started there if you need
<rick_h_> hatch: jcsackett review time if you get a sec please? https://codereview.appspot.com/9099043
<benji> hatch: I'm up for a hangout any time
<hatch> ok just going to commit this code I'm working on now
<hatch> couple minutes
<benji> sounds good
<hatch> benji: ok guichat?
<benji> hatch: sure, I'll be there in a second
<benji> hatch: that was a long second :) there now
<jcsackett> rick_h_: lgtm; this branch resolves both of your cards, right?
<rick_h_> jcsackett: right
<rick_h_> jcsackett: hatch or anyone else around to just peek at a small review/check? https://codereview.appspot.com/9101043
<rick_h_> extremely weak shot in the dark :)
<benji> gary_poster: I can give you the latest on memory leaks any time
<gary_poster> ack on calls thanks
<bac> hi rick_h_
<rick_h_> bac: howdy
<bac> rick_h_: hey, i think i'm ok.  i was surprised to see two hidden clones created by the resizingtextarea.  now i see there is a separate one for single_line
<bac> rick_h_: http://paste.ubuntu.com/5623854/plain/
<rick_h_> bac: hmmm, thinking
<bac> note they both have opacity:0 but one has a width and the other doesn't
<rick_h_> bac: could there be something where it's run twice and Y.all(textarea) grabs the mirror?
<bac> it's ok, i was just surprised
<rick_h_> bac: yea, so am I
<bac> perhaps.  this is in a test.
<rick_h_> bac: checking LP to see if that's true there. 
<rick_h_> bac: yea, in LP there's only the two
<rick_h_> https://bugs.launchpad.net/juju-gui/+filebug for instance
<rick_h_> bac: so I'd expect that to be left over test cruft or something 
<bac> ok
<rick_h_> bac: any chance I can rope you into a second review? https://codereview.appspot.com/9099043/
<bac> rick_h_: in a sec, yes
<rick_h_> bac: ty 
<bac> rick_h_: looking now.
<gary_poster> must run benji
<gary_poster> sorry
<benji> gary_poster: no worries, I'll catch you tomorrow
<bac> rick_h_: done
<rick_h_> bac: thanks
<bac> rick_h_: your LP example regarding the textarea does not have any that are marked 'single_line' i don't think.  it may be that either the test is creating an extra or the use of 'single_line' is doing it
<bac> rick_h_: is there any good way to write a CSS selector that would just get the real one?  i don't see how, as currently written.
<rick_h_> bac: lokoing
<rick_h_> hmm, can't find your review url in my list
<rick_h_> bac: do you have the review url handy? Or just an easy way to view source?
<bac> rick_h_: https://codereview.appspot.com/9077043 ... it was linked from the card on the kanban board.  (not always true, though)
<rick_h_> bac:  ah thanks
<bac> rick_h_: one of my tests does this, and pulls in the clones
<bac>  textareaControls = container.all('.control-group textarea.config-field');
<rick_h_> bac: so couple of ways. originally you do a Y.all('textarea').plug...?
<rick_h_> bac: so you can store that Y.all result list for a reference to the non-clones
<bac> rick_h_: something like that
<bac> could do
<rick_h_> bac: maybe the better thnig would be to stick a class on the clone node that's something like .juju-clone-xx
<bac> yeah, i think so
<rick_h_> bac: or better yet, set an attribute. data-text-area-clone="yuid of original node"
<rick_h_> than you can select Y.all('textarea["data-text-area-clone"])
<rick_h_> as well as match the clone to the originally
<rick_h_> bac: but yea, looking at the code you're right. 
<rick_h_> bac: the _get_single_line_height does another clone
<bac> ah, ok
<rick_h_> bac: maybe a better fix would be that it would destroy the single line clone once it got the height value? 
<rick_h_> bac: so submitted a comment to that MP with a potential/suggested fix for this specific issue. Though I think the class stuff might be helpful one day, but might be YANGNI for now
<bac> rick_h_: ok, but that branch is landed.  i may port your comment over to my next MP
<rick_h_> bac: right sorry just used it more like a pastebin pointed at the right place in the file :)
<bac> cool
<hatch> before I go looking does anyone know why unit views are called 8 times?
<rick_h_> hatch: still around?
#juju-gui 2013-05-02
<bac> hey rick_h_
<rick_h_> bac: howdy
<bac> i've gotten most things integrated and working.  may need to bug you in the morning to work out why the heights aren't what i expect.
<rick_h_> bac: sure thing
<bac> the charm panel has very tight specs for those sizings
<rick_h_> ping me when you get in and we can run through it. 
<rick_h_> bac: k
<bac> rick_h_: it is here if you're curious lp:~bac/juju-gui/hookup-resizing-textarea
<bac> the single line inputs in the charm panel have to be 28px tall.  it took some weird tweaking to get them there
<rick_h_> bac: yea, I think that's what that single input height was for. To kind of 'check' how tall each line of text should be
<rick_h_> bac: I'll try to look at it in the morning and see 
<bac> rick_h_: i changed single_line to be either falsy or to take a height.  the LP version used 1em hard coded
<bac> rick_h_: have a good night.
<rick_h_> bac: you too
 * hazmat watches gary_poster fill up the inbox in real time
<gary_poster> :-)
<hazmat> thanks
<gary_poster> welcome (glad it is a good thing; was a bit worried about subscribing juju-gui but thought it was appropriate)
<rick_h_> oh, is that why I'm getting dupes? 
<rick_h_> ok, thought I had done it wrong when I sub'd to everything 
<gary_poster> sorry rick_h_ 
<rick_h_> gary_poster: no, all good. Was curious checking if they were new ones I missed/etc
<gary_poster> :-)
<gary_poster> I added three
<gary_poster> added juju-gui for those
<rick_h_> cool
<frankban> morning rogpeppe
<rogpeppe> frankban: hiya
<frankban> bug 1160971 seems fixed, I attached the script used to dupe it, now it works well, do you want me to mark it as fix release in juju-core? 
<_mup_> Bug #1160971: WebSocket disconnects when an invalid request is sent <juju-core:New> <juju-gui:Fix Committed> <https://launchpad.net/bugs/1160971>
<rogpeppe> frankban: cool. i thought it probably was but your pastebin has disappeared so wanted to check with you
<rogpeppe> frankban: it's incredibly annoying that pastebin has lost everything
<frankban> rogpeppe: yes, it's not a reliable tool for this kind of things
<rogpeppe> frankban: tbh i think they have a responsibility to keep all the pastes around
<rogpeppe> frankban: they're a specific kind of history and really quite important
<frankban> rogpeppe: I agree, IIRC there was some discussion in some ml about this issue.
<frankban> rogpeppe: anyway, marking it as "fix released" if you agree.
<rogpeppe> frankban: in particular a lot of IRC discussion logs will be less useful without the pastes
<rogpeppe> frankban: sgtm
<frankban> rogpeppe: cool. oh, and congrats for your spotlight award, you deserved it! :-)
<rogpeppe> frankban: thanks!
<rogpeppe> frankban: you guys have been awesome too
<frankban> :-)
<rick_h_> anyone know what the config is on the charm to not have it ask for the password? I'm not seeing a config option for that. 
<benji> rick_h_: as far as I can tell if you deploy to py-juju and set "staging" to true in the config, then it shouldn't request a password
<rick_h_> benji: cool, /me goes to try
<rick_h_> cool though, first time I've deployed juju-gui and into an environment with our charmworld stuff 
<rick_h_> sweet https://ec2-54-224-200-253.compute-1.amazonaws.com/bws/fullscreen
<rick_h_> gary_poster: so this is a juju-gui using svg image links back to charmworld serving the svg image files working. 
<rick_h_> gary_poster: still no gzip, but I think it works out well
<rick_h_> thanks benji, worked
<benji> cool
<rick_h_> <3 using uistage to look up charm config options and descriptions lol
<rick_h_> dogfooding!
<benji> :)
<gary_poster> rick_h_, yeah, way better!
<rick_h_> gary_poster: I think so. I'll bring it up in our stand up for review from others and then we'll see about breaking the work down into backend/front end cards
<gary_poster> cool
<rick_h_> and this has the charmworld server doing the correct trimmed OPTION request, so 231B pre-flight with 158K of data 
<rick_h_> so much better than over 1M
<gary_poster> cool, rick_h_.  If you cache for switch between full and sidepanel then I think that will be a pretty good resolution
<gary_poster> I mean, the combined package
<rick_h_> gary_poster: right
<gary_poster> rick_h_, so is that instance trunk, or a custom branch of yours?  I could update the sandbox version and then we could have this behavior on the demo if you want--and the sandbox will make it feel asnappier also
<rick_h_> gary_poster: it's a custom branch of charmworld and juju-gui that just implemented a quick hack to proof it out
<gary_poster> rick_h_, ok cool
<rick_h_> gary_poster: so we have to go back and add the feature to charmworld, with tests, etc. and the front end
<rick_h_> I actually really like this 'create a branch, hack feature in, launch charms, point at hack branches...test'
<rick_h_> really kind of cool to A/B ish feature test
<gary_poster> add feature and tests: yeah, understood rick_h_ .  Is that a "by the end of this week" thing, if it were prioritized, do you think rick_h_ (understanding that it might not be prioritized and your estimate might be wrong and la la la la) ;-)
<gary_poster> rick_h_, cool to test with: agree.  lightweight deployment is very nice.  makes me want it even more lighter weight :-) particularly for iterative development and testing
<rick_h_> gary_poster: I'll ask in the stand up. I think since it can make the demo better it will be my/abentley's goal for today, but not sure
<gary_poster> cool
<rick_h_> gary_poster: I do need a hand from someone in debugging an issue I've got that only shows in prod mode. however, when I try to run make prod I get 404's vs the app
<gary_poster> huh
<rick_h_> gary_poster: just at some point today if someone is experienced in how prodmode is setup/diff
<gary_poster> rick_h_, yeah I know that.  now's about as good time as I'll get.  If we can't figure it out quickly I can hand it off
<rick_h_> https://bugs.launchpad.net/juju-gui/+bug/1175183 only happens in production mode, but running that locally would 404 when I go to 127.../bws/fullscreen and such
<_mup_> Bug #1175183: Filters checkboxes should not act as radio buttons <charmbrowser> <juju-gui:In Progress by rharding> <https://launchpad.net/bugs/1175183>
<gary_poster> I mean, I know about that
<gary_poster> ah
<gary_poster> yeah
<gary_poster> prod mode is simply dumber atm, in that the backing webserver can't serve index.html from arbitrary urls
<gary_poster> so quick hack: 
<gary_poster> merge your "charmbrowser defaul" branch and debug
<rick_h_> ah, gotcha. makes sense. 
<gary_poster> alternative, maybe quick hack:
<rick_h_> thanks, will do
<gary_poster> look at devel and try to switch that to serve prod temporarily
<gary_poster> cool
<gary_poster> benji, if you want to talk about memory, I have about 10 or 15
<benji> gary_poster: sounds good.  the regular place?
<gary_poster> sure benji
<bac> hi rick_h_, thanks for your email and explanation
<bac> rick_h_: upon further investigation i did see that the <input> fields on the charm panel have a line-height and height of 18px, so it is working just fine
<rick_h_> bac: np, thinking it's the generic css rules from input -> textarea getting in the way if I'm lokoing at the right spot
<bac> rick_h_: and those are the ones we're trying to match
<rick_h_> bac: yep, that's what I was going to add today. I missed putting line-height in those css notes
<rick_h_> so font-size, line-height, padding, border all come into the combined height you end up getting
<bac> rick_h_: there is a problem with the service settings page, though.  if you still have my branch could you add haproxy and then look at http://localhost:8888/:gui:/service/haproxy/config/  when you have time?
<rick_h_> bac: I can pull it back down. give me a few. 
<rick_h_> bac: ok, loaded and on that url
<bac> so if you look down at service, one of the last ones
<rick_h_> k
<rick_h_> bac: ok, so this should be opened up?
<bac> rick_h_: you'll see it is a single line, though it is populated with multi-line data.  a keypress in there will cause it to expand
<bac> righto
<rick_h_> k, /me goes and looks at code/etc for a bit
<bac> i'm stepping through the resize() method called at the end of the initializer now.  that is where it is supposed to get expanded
<rick_h_> bac: right, but in resize it checks for single_line and trumps the height in that first if condition I'd expect
<bac> rick_h_: ah, i think maybe _prev_scroll_height should not be initialized to 0
<bac> rick_h_: i see this behavior whether using single_line or now
<bac> not
<rick_h_> bac: so this was built to work with the inline editor such as the bug title, so that a single line would expand only when you were editing
<bac> rick_h_: funny thing is it works in charm panel when using single_line
<bac> in this view it does not work either way
<rick_h_> bac: k, looking
<rick_h_> ugh, multi dispatch FML. Goes through this debug code so many times
<rick_h_> bac, what view is doing the initial work here? loading plugging the textareas?
<rick_h_> bac: actually, want to chat for a second?
<bac> sure
<rick_h_> bac: looks like the normal hangout is taken, sec 
<bac> k
<rick_h_> bac:  https://plus.google.com/hangouts/_/439096b6bd109b21f6137274b06438e42739fdb0?authuser=0&hl=en
<gary_poster> rick_h_, I think I LGTM'd everything from Huw
<rick_h_> thanks gary_poster 
<gary_poster> welcome
<bac> hi gary_poster -- the integration with the resizing textarea is going well.  it works in the charm panel but is not happy in the service settings view.  rick and i know what's going on and i'm chasing it down.
<gary_poster> awesome bac!
<gary_poster> thanks for heads up
<rick_h_> bac: after I cleared my browser 100x I did get it to hit those debuggers but the Y.Array.each wasn't seeming to get hit. 
<bac> rick_h_: similar here
<rick_h_> bac: bah, you don't need to Y.Array.each a nodelist, you should be able to just do view.tareas.each(...
<bac> rick_h_: i'm confused.  when the break point hits, view.tareas is an array with 12 elements.  the breakpoint inside the .each never hits, though
<rick_h_> bac: if you get a sec try that. If not I'll give it a go after I get this stuff landed for huw
<bac> rick_h_: that works if you do  tarea.resizingTextarea.resize(); -- the plugin must be included
<rick_h_> bac: ah! awesome
<rick_h_> bac: so at least a hack can make it work then. Might check with hatch or someone more up on showView() to see if there's a better place to hook into. A 'rendered' event or something. Otherwise, this gets around the issue at least
<hatch> whaaaadauuupppp
<bac> hey hatch
<rick_h_> beetlejuice ... beetlejuice ...
<hatch> BEETLEJUICE!!!!!!
<bac> so in services.js views.service_config there is a container that i'm using to add the resizing textarea plugin
<bac> hatch: all well and good, but that container has not yet been added to the DOM, so the initial size computations are all zero
<rick_h_> hatch: I couldn't figure out how/when showView() from _buildServiceView() actually put the thing in the DOM
<rick_h_> hatch: in app.js, so we put some hack code into the callback for post-showView() but feels hacky
<bac> hatch: http://paste.ubuntu.com/5625996/
 * hatch creates a card for everyone to use gist.github.com so we can have editing and syntax highlighting
<hatch> ;)
<rick_h_> hatch: replies!
<rick_h_> paste.mitechie.com :) lodgeit ftw
<hatch> sorry I had to run and take the garbage out....not that it mattered I missed the damn truck
<hatch> gists are mini git repos, nothing beats that :)
<hatch> bac: rick_h_ so that's how you're supposed to do it - th eonly change I would do is have a method you call in the view to do that each()
<rick_h_> hatch: yea, makes sense. view.fixTextAreas()
<hatch> haha - well....instantitateTextAreas :P
<rick_h_> view.inTheDippyDomNow()
<rick_h_> :P
<hatch> view.lickyBoomBoomDown
<hatch> view.informer
<hatch> view.blam
<hatch> name that song! first person wins 1 internet
<benji> no, not Snow, anyone but Snow
<rick_h_> lol
<rick_h_> that just makes me want to start 'ice ice baby'ing around the house 
<bac> rick_h_, hatch: yeah perhaps we should not attach the plugin until after showview
<benji> I'll take two Vanilla Ices (Icies?) over Snow
<rick_h_> bac: or that. 
<hatch> http://www.youtube.com/watch?v=NtILxBszyf8
<benji> Especially now that he is a general contractor with a renovation TV show
<hatch> I want those sunglasses
<hatch> lol
<hatch> benji: haha really?
<benji> yep
<benji> who saw that career change coming?
<benji> hatch: https://www.youtube.com/watch?v=IrNiiNRCvYo
<hatch> vanilla ice !== snow :)
<hatch> oh
<hatch> sorry too early
<hatch> missed the convo changing tracks
<hatch> :)
<hatch> jujugui - has anyone looked into these CI failures? I think this one is fixable
<gary_poster> hatch, I tried yesterday.  sent email.
<hatch> 2013-05-02 14:27:27,704 DEBUG openstack: 400 '{"badRequest": {"message": "Can not find requested image", "code": 400}}'
<hatch> oh woops sorry I'm 100+ behind in my emails
<gary_poster> hatch, we must fix it.  make distfile might be broken?
<hatch> possible, I'll grab my laptop and log into it
<hatch> see what I can do to fix it
<gary_poster> hatch make distfile works on trunk.  this is on charm apparently.  do you know where to find the right image numbers offhand?
<gary_poster> if you can fix CI, teknico is looking at broken charm
<hatch> isn't that euca-describe-images or something
<hatch> was just looking it up
<gary_poster> hatch something like that but then you have to know which one to choose of a zillion
<hatch> I'll pick the one with the coolest name
<gary_poster> heh
<hatch> honestly I was going to see what the old one was and try and find something similar
<frankban> gary_poster, hatch, teknico: it seems that make distfile is broken in trunk: http://pastebin.ubuntu.com/5626062/
<hatch> oh ok
<gary_poster> frankban, worked for me after make clean.  maybe make clean-all is necessary to trigger
<frankban> gary_poster: oh, trying
<hatch> ok well if you guys are on it i'll get back to gui stuff
<frankban> gary_poster: still an error
<gary_poster> hatch, multiple problems
<gary_poster> hatch if you can fix image name that would be fanulous
<gary_poster> fabulous even
<frankban> (make clean-all && make distfile)
<hatch> ohh ok
<gary_poster> frankban, weird.  I got a fresh branch and WFM.  Raring, yeah?
<rick_h_> gary_poster: FYI manage.j.c is updated with fixes to the OPTIONS request and gzip is now enabled so tinyurl.com/jujucharms should hurt less. 
<frankban> gary_poster: yes, trying on a branch
<gary_poster> frankban, and the failure was the same as before ?  " bin/py: File removed before we read it" is weird error
<frankban> gary_poster: yes
<gary_poster> rick_h_, awesome thanks.  once fires are out I'll also update tinyurl.com/jujucharms
<hatch> hmm I cannot remember how we specify the image to use
<gary_poster> hatch in ~/.juju/environments.yaml
<hatch> ohh right right
<hatch> umm....image id's are in the format aXi-XXXXXXXX - the one in the env.yaml looks like a hash of some type
<hatch> or am I missing something here?
<frankban> gary_poster: it was a local problem: bin/py broken symbolic link in my trunk branch, not removed by make clean-all
<gary_poster> frankban, ah ok cool.
<hatch> so as far as images go - do we want 64bit raring?
<gary_poster> hatch no
<gary_poster> we want 64 bit precise
<hatch> or stay with 12.04?
<hatch> does anyone have any idea how that id got changed?
<gary_poster> hatch 12.04
<gary_poster> hatch the id changed probably because they have improvements to the image
<gary_poster> newer sources
<gary_poster> that sort of thing
<hatch> no I mean they aren't even in the same format
<hatch> the one in our env.yaml is a huge hash
<hatch> not the format of the image id's
<hatch> hmph who knows I'll keep it just in case
<gary_poster> hatch, sorry, trying to get over at the machine to look.  have a call in 3
<gary_poster> and was just off another call
<hatch> sure np - I am just looking through the list of images
<hatch> I think we want ubuntu-released image?
<hatch> sounds like it would make the most sense :)
<gary_poster> yes hatch I think so.  Although if it has "smoser" in the name it is fine too I think
<hatch> there are those too but they are further down - I'll try this one for now
<gary_poster> ok
<hatch> ok id updated and new build kicked off
<hatch> really wondering how that id got changed
<hatch> hmm now it's saying invalid image ref provided
<gary_poster> hatch http://10.189.74.2:8080/job/jujugui-test-charm/385/console
<hatch> I'm confused...
<gary_poster> not good image
<hatch> ok will try the smore one
<teknico> here are some charm changes, I'd like a few eyes on it, possibly frankban's, and bcsaller_'s when he's around: https://codereview.appspot.com/9121043/
<teknico> I even did a pre-review of sorts to help you out :-)
<hatch> kicked off build again
<frankban> teknico: will do
<teknico> frankban, thanks
<hatch> ok invalid image ref again...it must not like the id format
<hatch> so I need to somehow associate the id in the euca list to some hash?
<hatch> according to the canonistack documentation it's the proper ID format
<hatch> checking in #canonical-support
<hatch> orr..... matsubara you around?
<matsubara> hatch, yep
<hatch> so we started getting these errors last week
<hatch> DEBUG openstack: 400 '{"badRequest": {"message": "Can not find requested image", "code": 400}}'
<hatch> and when I view the environments.yaml file the ID is a large hash
<hatch> but when I change it to a proper ID it gives me an invalid ref id
<hatch> ERROR Unexpected 400: '{"badRequest": {"message": "Invalid imageRef provided.", "code": 400}}'
<matsubara> hatch, deploying on canonistack?
<hatch> yeah
<hatch> so it's like it's expecting a large hash ID not the one that's in euca-describe-images
<matsubara> hatch, can you deploy locally from your laptop?
<hatch> I can try
<hatch> but I'm going to guess no
<hatch> heh
<hatch> that also has the large hash i'd
<hatch> ids
<hatch> I can't remember where those came from
<hatch> but no - can't find the requested image
<matsubara> hatch, sorry, got disconnected. I think smoser knows the id to use. maybe ask on #is?
<hatch> ok so it doesn't follow the canonistack documentation on wiki any more?
<hatch> the id's from euca-describe-images aren't valid?
<hatch> ok I asked him
<matsubara> hatch, this is in the env.yaml file for the charmworld project:  default-image-id: bb636e4f-79d7-4d6b-b13b-c7d53419fd5a
<hatch> yeah same we have
<hatch> which doesn't work
<gary_poster> hey hazmat.  https://blueprints.launchpad.net/juju-gui/+spec/servercloud-s-juju-gui-read-only-for-is is the blueprint.  It is for juju-gui.  I think you need a juju-core blueprint.  That will be one that GUI follows
<gary_poster> I think I should try to delet the gui one
<gary_poster> e
<hazmat> gary_poster, ack, thanks
<matsubara> hatch, might be a problem on canonistack itself
<hatch> just got an id - and an explanation as to what's up
<hatch> so /me happy
<matsubara> cool
<rick_h_> noooooooooo bug in yui makes me sad...well at least lack of support 
<hatch> which bug?
<gary_poster> hazmat, I was wrong: https://blueprints.launchpad.net/juju-core/+spec/servercloud-s-juju-core-role-based-access-control
<gary_poster> have at it :-)
<hatch> gary_poster: jenkins is about to shut down so when it's back we'll see if this new ID works...and I also found out why there is a discrepecy and will update the documentation
<rick_h_> hatch: working on it. Looks like it has two query string parsers. One in http://yuilibrary.com/yui/docs/api/files/app_js_router.js.html#l994
<rick_h_> hatch: and the query string module itself
<gary_poster> hatch, and can you also document what to do in the future when this happens? :-)
<hatch> rick_h_: keep in mind we have totally bastardized that router code :)
<rick_h_> hatch: the one in the router code is dumb and can't handle  querystring: "category=databases&category=file_servers&
<hatch> gary_poster: definitely - I was getting frustrated hah
<rick_h_> where a key is in there twice to turn into an []
<gary_poster> :-) cool
<hatch> rick_h_: that's because query strings with multiple of the same keys are technically invalid :)
<rick_h_> hatch: but but but 
<rick_h_> hatch: it works in dev mode :P
<hatch> haha no I agree it's a commonly used feature
<rick_h_> hatch: only fails in production so building tests against Y.QueryString and Y.Route atm
<hatch> oh really? that's interesting
<rick_h_> hatch: http://jsbin.com/efofol/1/
<rick_h_> hatch: so for some reason in dev it's using Y.QueryString but in production using Y.Router._parseQuery and thus breaking my filters
<rick_h_> hatch: anyway, will ahve to find some way to cheat it when I get back from lunch. bbl
<hatch> ohhhhh
<hatch> now I see what's going on
<gary_poster> juju kanban now please
<gary_poster> jujugui I mean
<gary_poster> bcsaller, any idea when your branch might land?  if soon I will wait to update tinyurl.com/jujucharms
<bcsaller_> gary_poster: I pushed a number of updates a minute ago, I think I if I could get a second review on https://codereview.appspot.com/9070043/ I'm ok with it as an intermediate step
<gary_poster> bcsaller_, cool, let's rustle someone up on the call
<bcsaller_> redoing the propose now
<bcsaller_> gary_poster: did you ever get it to work in practice?
<gary_poster> bcsaller_, aigh! no!  doing now.
<gary_poster> bcsaller, lol that's *awesome*
<bcsaller_> heh :)
<gary_poster> bcsaller_, I will have to do a live demo on call :-P
<gary_poster> bcsaller_, qa: cannot add or remove relations to imported bits
<gary_poster> maybe fixed
<gary_poster> but just pulled
<gary_poster> oops
<gary_poster> jujugui call nowq
<bcsaller_> gary_poster: yeah, should work now
<bac> jovan2: i'd like you to look at the expanding textareas.  i have an instance coming up at http://ec2-50-19-207-147.compute-1.amazonaws.com and it will be available soon
<bcsaller_> https://codereview.appspot.com/9070043/
<jovan2> bac: sure
<jovan2> bac: pwd?
<frankban> Makyo: congrats!
<Makyo> Thanks :)
<Makyo> I found out this morning we made a couple of the local papers, too, since it was the first day. :P
<bac> jovan2: trying to get it
<teknico> bcsaller_, frankban, thanks for the reviews!
<hatch> LF review for doc update https://codereview.appspot.com/9124043/
<gary_poster> hatch, maybe mention how to choose the ids?  look for precise, and...?
<hatch> now that the CI is back up we have failures in IE
<gary_poster> :-(
<hatch> gary_poster: adding
<gary_poster> thanks
<hatch> gary_poster: proposing
<bac> hey rick_h_, could you look at the above ec2 url?
<hatch> updated
 * bac lunches
<rogpeppe> gary_poster: "the Juju API cannot accept a websocket directly (it expects to have to upgrade it)"
<rogpeppe> gary_poster: what does that mean?
<gary_poster> rogpeppe, it may be no longer relevant,  Where is that? on call
<rogpeppe> gary_poster: it's from servercloud-s-juju-core-role-based-access-control
<gary_poster> rogpeppe, could you delete? not relevant
<rogpeppe> gary_poster: ah actually - i'd missed the fact that that comment was talking specifically about py juju
<rogpeppe> gary_poster: so probably still relevant
<gary_poster> yes
<hatch> bac: did you test your textarea stuff in IE? it looks like it's breaking the CI
<hatch> sorry... :)
<Makyo> hatch, It hasn't landed yet, has it?
<hatch> the video shows a 'textarea' suite failing
<Makyo> Was it landed as separate branches, then?
<hatch> I can't seem to stop the video to see what the title actually says
<hatch> I have no idea
<gary_poster> hatch, some of it landed a while ago
<gary_poster> specifically some standalone plugin tests
<gary_poster> IIRC
<gary_poster> the new branch actually integrates it
<hatch> ohh ok - looks like it's those tests which are failing in IE
<gary_poster> bac, LGTM with comments plus fixing the IE tests from previous checkin
<gary_poster> benji did you run the charm tests when you landed?  teknico reported that tests were broken in trunk
<gary_poster> frankban, LGTM.  Did deploy tests also fail for you?
<frankban> gary_poster: not tried, teknico said they were failing in trunk, I suggested to handle that in another card. I can check it tomorrow
<gary_poster> ok thanks frankban.  have a good evening
<frankban> gary_poster: you too!
<gary_poster> bcsaller_, I still cannot add or remove relations on imported services with tip of your branch
<bcsaller_> gary_poster: yeah, I loaded the charms so I thought it would work, I'm looking at that now, very odd error
<bcsaller_> this.db.charms.get('id')
<bcsaller_> ["cs:precise/memcached-6", "cs:precise/wordpress-14", "cs:precise/mysql-19", "cs:precise/mediawiki-8", "cs:precise/haproxy-17"]
<bcsaller_> app.db.charms.get('id')
<bcsaller_> ["cs:precise/memcached-6", "cs:precise/wordpress-10", "cs:precise/mysql-16", "cs:precise/mediawiki-6", "cs:precise/haproxy-16"]
<bcsaller_> where 'this' is the fakebackend
<hatch> that's a lot of smiley faces
<bcsaller_> hatch: you have a very expressive IRC client
<hatch> yeah it even does inline pastebins, images, and autoresolves tinyurls
<gary_poster> bcsaller_, weird...so fakebackend is not honoring the service revision
<gary_poster> bcsaller_, maybe it can't honor it?
<bcsaller_> gary_poster: or they are pulling from the old and the new sources
<gary_poster> bcsaller_, because the charm store only offers current versions?  and so the solution is to reconcile?
<gary_poster> on the service
<gary_poster> bcsaller_, I think that is it: line 325 of fakebackend
<gary_poster> this.get('charmStore').loadByPath(
<gary_poster>             charmIdParts.charm_store_path
<gary_poster> if you go get that json...
<bcsaller_> I suspect you're correct
<gary_poster> bcsaller_, yup: http://jujucharms.com/charms/precise/wordpress-10/json (look for store_revision and compare with url)
<gary_poster> or store_url for that matter
<bcsaller_> the the imports are not going be the current version much of the time anyway
<gary_poster> yeah
<gary_poster> arguably would be more reliable if they were
<bcsaller_> but its not quite like pinning a package version
<gary_poster> in terms of backwards compatibility
<gary_poster> it kind of should be
<bcsaller_> within a series the assumption has been that current == best
<gary_poster> no guarantee that config will be the same across revisions, or relations, or...
<gary_poster> but that's not an option right now anyway
<gary_poster> I think we ought to continue to ask for what the import specifies, but update the service to the charm we actually get and hope for the best
<bcsaller_> yeah, npm styled specs in the charm for revisions might be nice some day, an export format that could say charm: "cs:precise/wordpress >= 10"
<gary_poster> yeah
<bcsaller_> I can do an inplace upgrade for now, yeah
<gary_poster> cool
<gary_poster> bcsaller_, the new promise code is not working in fakebackend.  charms are being loaded because of the GUI side endpoints code
<gary_poster> bcsaller_, to demonstrate put breakpoint in line 1253 (if (s.name && !s.id)) in fakebackend
<gary_poster> bcsaller_, s.id is always set
<gary_poster> so _promiseCharm never called
<gary_poster> at least with sample-fakebackend.json
<hatch> is this something I did?
<bcsaller_> hmm, sounds like I've got some digging to do
<hatch> I saw promise and charm
<gary_poster> hatch no, all's good
<hatch> alright
<bcsaller_> hatch: no :)
 * hatch goes back to his cave :)
<gary_poster> heh
<bcsaller_> gary_poster: I've updated the tests to check that the charms are loading, and those are passing, not sure how much of that I changed since the last push, but I'll verify what you're seeing 
<gary_poster> ok cool
<bcsaller_> ha, well, the initial demo is cool anyway ;)
<gary_poster> :-) only small bugs bcsaller_ , no biggie
<benji> gary_poster: (back from lunch) I can't say I specifically remember running the tests, but I would hope I did.
<gary_poster> heh
<gary_poster> benji, looks like it was bad and it may be worse: just got a report that the charm is now broken, possibly after teknico's commit.  Could you join me on guichat and we can work together for a bit?  This is an emergency (and our process surrounding the charm is a big lose, obviously :-( )
<benji> gary_poster: sure, be right there
<gary_poster> thx
<hatch> gary_poster: whenever you have a moment if you could QA and review https://codereview.appspot.com/9132043/  that would be awesome :)
<hatch> sorry it's a rather large diff
<hatch> well....lots of files
<hatch> oh poo
<hatch> for some reason it didn't diff against the most recen't trunk
<hatch> ill try again
<gary_poster> hatch ok ping when ready
<hatch> gary_poster: ok it's done
<rick_h_> hatch: jcsackett or sinzui can I get some +1s on a 1 line change that took a day to figure out please? https://codereview.appspot.com/9101043
<rick_h_> oops
<rick_h_> well I guess it still works
<hatch> woah woah woah....false advertising
<hatch> that's clearly a 6line change
<rick_h_> comments don't count :P
<hatch> haha
<rick_h_> I should get bonus points for avoiding explitives in my comments :)
<hatch> I don't think the description matches the fix though?
<sinzui> rick_h_, Thank you for the explanation for the zaniness
<rick_h_> ? querysting listed before juju-gui in the use() block?
<rick_h_> hatch: how so?
<hatch> maybe I'm missunderstanding them "it looks like perhaps there is some extra render going on..."
<hatch> should the description not reflect the fix?
<rick_h_> hatch: ah, right forget that
<rick_h_> that was the "oops'
<hatch> ohhh
<rick_h_> I had taken a first stab at the fix the other day
<rick_h_> and used the same branch name on accident
<hatch> ahhh
<hatch> ok lgtm'd
<rick_h_> thanks
<sinzui> rick_h_, I added my LGTM. I think you are free to land
<rick_h_> sinzui: thanks
<benji> gary_poster: I'm getting test failures, but I think they are a local problem:
<benji> WebDriverException: Message: 'Can\'t load the profile. Profile Dir: /tmp/tmpR9aoJc Firefox output: Xlib:  extension "RANDR" missing on display ":1015".\n*** LOG addons.xpi: startup\n*** LOG addons.xpi: checkForChanges\n*** LOG addons.xpi: No changes found\n' 
<gary_poster> benji http://jujugui.wordpress.com/2013/04/27/rarings-selenium-doesnt-like-rarings-firefox-my-solution/
<bac> bcsaller_: i've got to go figure out how i've broken CI.  i'm not going to be able to review your branch very soon.  you may want to scare up someone else.  sorry.
<bcsaller_> bac: np, thank you
 * benji looks.
<jcsackett> hatch: can i get you to look at https://codereview.appspot.com/9131043/
<jcsackett> dammit.
<jcsackett> buffer error, that's ricks.
<jcsackett> or never mind, those are just *very* similar IDs.
<rick_h_> jcsackett: yea, that's the one I reviewed so all good
<jcsackett> rick_h_: yeah. hatch, can you give it the other look?
<hatch> yu[
<hatch> on it now
<rick_h_> man I <3 usb3 
<rick_h_> "i'd like to backup ~ ... ok good"
<hatch> gary_poster: for some reason it's picking up that test_model_controller.js is  anew file when in fact it's in trunk but I merged it in from it's branch before it was landed...so you can disregard that one if you like
<gary_poster> ok
<hatch> benji: you're reviewing bcsaller_'s branch?
<benji> hatch: nope, but I can if need-be
<hatch> oh no I ust saw you say 'looks'
<hatch> I can do it if one is still needed
<benji> hatch: have at it
<hatch> bcsaller_: what's the link?
<bcsaller_> https://codereview.appspot.com/9070043/
<bcsaller_> and thanks
<hatch> holy poo that's a large diff
<hatch> :P
<bcsaller_> its not actually that big, mostly new charm data for the tests I think
<bcsaller_> and you'll get to see what all that charm/promise talk was about
<gary_poster> hatch, your code is good but your diff is bad: A fix for /:gui:/ will come in a later branch?
<benji> gary_poster: I'm getting this error after doing the virtualenv thing, does it ring any bells?
<hatch> oh wow it's a lot worse than I thought...
<benji> Traceback (most recent call last):
<benji>   File "./deploy.test", line 9, in <module>
<benji>     from selenium.webdriver import Firefox
<hatch> gary_poster: any thoughts on how to fix this diff?
<hatch> it's like it's not diffing from trunk
<hatch> info shows that it's parent is /trunk though
<gary_poster> hatch, in your shoes I'd re branch master, merge your existing branch, and repropose from that.  That's lazy but I don't have tim eto figure anything else out atm :-)
<hatch> so branch trunk, merge my branch into that?
<hatch> I can try that
<gary_poster> hatch y
<gary_poster> benji, no.
<gary_poster> benji more info from reporter
<benji> hmm
<benji> <eyebrows raised>
<gary_poster> benji, you saw on #webops?
<benji> nope, looking now
<benji> gary_poster: I'm not in #webops
<gary_poster> benji, oh because of eyebrows I thought maybe so
<gary_poster> benji: 
<gary_poster> <wedgwood> gary_poster: https://pastebin.canonical.com/90418/ to prepare the charm, then https://pastebin.canonical.com/90419/ as the config
<benji> my eyebrows are easily misunderstood
<gary_poster> :-)
<gary_poster> benji, he's doing something weird.  I'll handle it. :-)  you see if you can wrap up something on your other work
<benji> gary_poster: ok.  do you want me to abandon trying to run the jitsu tests for the charm?
<gary_poster> benji, um.  up to you.  We must be able to run tests.  So that needs to be done.  OTOH, if you might have something actionable from your memory work in the remaining time it would be great to do that too.
<benji> ok,  I don't know what the odds of actionable results are, but keeping doing what I was doing seems like the best route
<hatch> gary_poster: ok this diff is much better https://codereview.appspot.com/9119044/ I can apply your changes to this branch so you don't have to do another review/qa
<gary_poster> cool hatch, apply the changes then ping me and I will look
<gary_poster> benji ack, go for it
<hatch> sounds good
<hatch> bcsaller_: review done
<bcsaller_> hatch: thanks
<gary_poster> hatch are changes applied or should I go to next call?
<hatch> gary_poster: continue on - I just started after doing ben's review
<gary_poster> cool hatch thx
<hatch> gary_poster: changes are made and pushed to https://codereview.appspot.com/9119044/ I'm going to take lunch now
<Makyo> Got a confirmation that I'll be working from a local co-working place tomorrow in the AM.  During the final few minutes of our meeting time , so I'll try to get there early.
<Makyo> At least one other Canonical-er there, figure it's worth a try.
<Makyo> Three, looks like.
<hatch> Id have a 20minute drive to get to a co-working place here....not gona happen
<hatch> :D
<hatch> bac: did you see that your latest commit failed CI? Was that one from before the IE fixes?
<bac> hatch: there are no ie fixes yet
<hatch> ahh ok cool
<bac> so it is expected
<gary_poster> hatch looking now.  what's the story for :gui:/ environment registration: follow-on branch?  apologies if you already responded, but I didn't see it
<gary_poster> nm hatch I see in code :-)
<hatch> alright :)
<jcsackett> rick_h_: you still around?
<rick_h_> jcsackett: kinda, what's up?
<jcsackett> i was an idiot and submitted that filter-string fix branch, which is blocked on aaron's code. i have a branch that reverts it, but my lxc won't load, which means i can't propose/submit.
<jcsackett> was wondering if i could get you to help me get it through.
<jcsackett> but if you're EoDing, perhaps hatch can help.
<rick_h_> jcsackett: so, I'd ask if abentley's branch is going to land tomorrow. It landing isn't an issue atm since the browser is 'feature flag'd' behind the urls
<jcsackett> rick_h_: ah, there is that.
<rick_h_> jcsackett: the issue is only that searches will fail with categories due to upstream
<rick_h_> nothing really 'breaks'
<rick_h_> we just have to watch for the demo and if abentley will have a migration/final update to manage. tomorrow then all is good
<rick_h_> jcsackett: but if you'd like to revert, shoot me the revert branch and I'll put it down and lbox it up
<jcsackett> rick_h_: given what you've very sensibly pointed out, it's not a rush.
<jcsackett> if aaron can't land his changes tomorrow, i'll land the revert then.
<abentley> rick_h_, jcsackett: The charmworld change is nearly done.  Then I have to do the charm change, which should be fast.
<rick_h_> jcsackett: rgr 
<rick_h_> abentley: awesome, good to hear. 
<jcsackett> abentley: you're a hero. :-)
 * jcsackett totally forgot abentley was in this channel. :-P
<jcsackett> rick_h_: have a nice evening, and good luck with raring upgrade tomorrow. my LXC woes are part of my upgrade. :-P
<rick_h_> jcsackett: was just about to reboot to my usb device when you ping'd. Why I said I was 'kinda' around :)
<jcsackett> rick_h_: i will delay you no more. :-)
<rick_h_> jcsackett: good news is I've not lxc'd on this to date so hopefully avoid some of that
<rick_h_> but definitely hoping to lxc/local juju it up on the new desktop when I get back 
<rick_h_> so :/
<jcsackett> i think it's upgrade borked my setup. if you don't have a setup yet, maybe no problems.
<rick_h_> jcsackett: yea, I'm a reinstall fan myself. backed up to NAS, external portable usb3, and boom goes the OS
<jcsackett> rick_h_: yeah, i'm worried i'll need to reinstall now. but i'll spend some time seeing if i can figure out what's broken.
 * Makyo -> dogwalk
<gary_poster> hatch trying to qa. two conflicts with trunk; resolution is not entirely trivial. I'll share.
<hatch> that's interesting - I merged it into trunk to get that diff and didn't get a conflict
<gary_poster> hatch, new textarea integration code is conflict.  help me resolve this quickly on guichat?
<hatch> ok sure thing
<bac> gary_poster: CI "fix" is at https://codereview.appspot.com/9128044
<bac> gary_poster: need any help with conflict?
<gary_poster> bac, nah was pretty easy thank you
<bac> gary_poster: cool.  ping me if you get to that review
<gary_poster> bac review done
<hatch> bac: lol "fix"
<hatch> *sigh* back to the file watching errors
<hatch> I thought those were behind me
<hatch> :/
 * Makyo back.
<hatch> gary_poster: I can't reproduce the same bug - but when I try I get console errors....so that's almost better :)
<hatch> oh
<hatch> lol
<hatch> gary_poster: did you var attachPlugins = function(view) { <----- pass the view into this function?
<gary_poster> hazmat, one more move of that blueprint fwiw, to match rules: now https://blueprints.launchpad.net/juju-core/+spec/s-cloud-juju-role-based-access-control
<hatch> I think we both missed that ;)
<hazmat> gary_poster, thanks for the update
<gary_poster> welcome
<gary_poster> hatch, http://pastebin.ubuntu.com/5627317/ I think it is right
<hatch> oh yeah - when I do that it works fine
<hatch> heh
 * hatch closes bug - unable to reproduce
<gary_poster> ok
<hatch> I'll try in chrome ubuntu
<hatch> hmm
<gary_poster> back later
<hatch> gary_poster: yeah I can't reproduce...I am wondering if it's a race condition
<hatch> wth same jenkins error?
<hatch> investigating
<hatch> fixed image id and set another build
<hatch> we'll need to keep an eye on CI error messages - if we notice the image id error any more we might need to create our own image so that it's not changed.
<hatch> bcsaller_: thanks for the review
<bcsaller_> np
<hatch> bcsaller_: mind doing me a favour and building this branch and then visiting a url? https://code.launchpad.net/~hatch/juju-gui/promise-conflict
<hatch> the url is /:gui:/unit/mysql-5/  and it should dump you to the service view with 3x notifications
<hatch> gary gets a loading screen and it works fine for me on all my devices
<hatch> so I'm wondering if it's a race condition that I'm not seeing
<bcsaller_> hatch: doing it now
<hatch> thanks
<hatch> yay CI passed IE tests again
<bcsaller_> hatch:  I fired up improv while the server was running and it connected and then bounced to the service view. After that I re-entered the url, pressed enter, got the three notifications and sit on the loading screen, it might depend on if the 1st delta has happened or not at the time of the view resolution
<hatch> hmm
<hatch> well I definitely can't land it as it is
<bcsaller_> because the db will be empty initially 
<hatch> ahhh I think I know why
<hatch> even though we have promises we are still relying on the db change event
<hatch> to re-fire them
<hatch> poop
<bcsaller_> async promise resolution + url management does sound error prone, unless the ui model is to block with a spinner waiting on the promises
<hatch> are you able to reproduce it reliably?
<hatch> I am wondering if removing the { update: true } from line 600 in app.js will be enough to fix it
<hatch> I am hoping that that will cause a full re-render fixing the problem
<bcsaller_> this time it gave me three notifications and then the proper service view, so it is a racce
<hatch> thoughts on what to do?
<hatch> wait something is really wrong here
<hatch> ohh
<hatch> maybe adding options.model = db.services.getById(req.params.id) on line 590 before the showview will fix
<hatch> either that or removing the { update: true } on 600
<hatch> ok I was finally able to reproduce the error
<hatch> oh bac is gona be mad....the autosize widget tests fail in FF now
<hatch> bcsaller_: whenever you get a moment if you could pull down the latest changes in the promise-conflict branch and see if you can get the error or if my hack has resolved it
<bcsaller_> hatch: I was still poking at it so I can do it now
<hatch> oh ok great
<bcsaller_> hatch: I still get three error notifications, but it seems to redirect to the service page after 3 sucessful tries
<hatch> yeah the error notifications will happen until we don't dispatch 3 times on load
<hatch> so right now I'm hoping this fixes the race condition
<hatch> I reloaded about 20x tmes and couldn't get the loading screen hang with this fix
<bcsaller_> yeah, seems better to me as well
<hatch> excellent
<hatch> that's a relief
<bcsaller_> the notifications might be excessive though :)
<bcsaller_> hatch: maybe another timeout to spawn that?
<hatch> hey....they are the ones trying to access an invalid unit/service :P
<hatch> but yeah I suppose that's a reasonable workaround :)
#juju-gui 2013-05-03
<gary_poster> bcsaller_, if I qa and give you a LGTM can you land now? :-)
<bcsaller_> gary_poster: I think so
<gary_poster> yay!  ok 1 sec
<gary_poster> bcsaller_, "Assuming you clean up review notes, LGTM!  Yay, thanks!"
<hatch> gary_poster: still around?
<gary_poster> hatch, y
<hatch> http://bazaar.launchpad.net/~hatch/juju-gui/promise-conflict/revision/646 mind trying this out whenever you get a chance to see if it fixes the loading screen issue
<hatch> it solved it for ben and I
<gary_poster> huh, weird
<gary_poster> ok
<hatch> yeah right?
<hatch> heh...
<gary_poster> hatch solves it.  don't love the solution ;-) looking for a sec...
<gary_poster> hatch, "firing "update" is
<gary_poster>                   // unnecessary, and potentially even mildly harmful.
<gary_poster> "
<gary_poster> My current suspicion is that this is the problem
<gary_poster> It gets the service
<gary_poster> then gets the charm
<gary_poster> fires update...
<gary_poster> and we redispatch
<gary_poster> meanwhile we've been loading haproxy because of the delta stream
<gary_poster> which *also causes a redispatch
<gary_poster> *
<gary_poster> which then interrupts the connection of the promise and the view  (actually it already did that; but the first time it was ok...)
<gary_poster> so this is the third time through
<gary_poster> (the update causes the three-alarm fire, at the very least)
<hatch> hmm interesting
<hatch> taking that fire out still causes it to render the three notifications but.... it looks like it's solved the hangup...
<gary_poster> hatch, eh, I dunno, I should have kept it to myself.  There's something unpleasant happening because of that update, but it's not the only problem; commenting it out...
<gary_poster> right
<hatch> ahh nope that didn't fix it
<hatch> just got the loading screen
<gary_poster> yeah not surprised :-/
<gary_poster> the update is not right, where it is, but not the problem
<hatch> yeah it looks like it can be safely removed now
<gary_poster> not sure about that
<hatch> no?
<gary_poster> we need to double check that the endpoint stuff still works in particular
<gary_poster> that's where it came from
<hatch> it appears to
<hatch> at least as far as the ui interactions are concerned
<gary_poster> hatch, huh.  that would be cool to remove.  since it doesn't seem to solve anything concrete atm, could you run that change past bac tomorrow and see if he has any qa ideas?
<gary_poster> but does not need to be in this branch
<hatch> sure - and thoughts on the 'fix' ? leave it in and create a follow-up ticket?
<gary_poster> gimme another minute on it, but probably
<gary_poster> the fact that we are loading the services/charms because of the delta stream at the same time as the unit view traversal code makes it confusing
<gary_poster> the promise code is being called all over the place
<gary_poster> the modelController stuff
<gary_poster> mostly for deltas
<hatch> yeah - it's going to take quite a bit of work to remove the dispatches entirely
<gary_poster> and then three times for the view
<hatch> but it's definitely doable
<gary_poster> would you wait to dispatch until...what?
<gary_poster> the delta has been processed and we have all models and charms?
<gary_poster> oh, wait a second
<gary_poster> I suggested a caching mechanism
<gary_poster> not there
<gary_poster> lemme hack that in, for the heck of it
<gary_poster> well, lemme review the "then" docs again...
<gary_poster> I turn into a pumpkin in 4 minutes
<hatch> haha no problem
<gary_poster> yeah you can call then multiple times on the same promise, as long as they return what you want the next "then" to have
<gary_poster> aigh! turning...into...a...pumpkin!
<gary_poster> hatch! go...ahead...and...land...
<gary_poster> (||)
<gary_poster> ^^^ pumpkin
<hatch> lol nice pumpkin
<gary_poster> not good ascii art, sorry
<gary_poster> night! :-)
<hatch> night
<rick_h_> hey huwshimi, how goes?
<huwshimi> rick_h_: Hey. Pretty good. Trying to get through these bugs
<rick_h_> huwshimi: cool, just wanted to check in if you need anything 
<huwshimi> rick_h_: I don't think so at the moment. Thanks for landing all my branches.
<rick_h_> huwshimi: np, thanks for the update. Looks nice with the diff sizes/etc now
<huwshimi> rick_h_: Yeah, much better :)
<huwshimi> rick_h_: Things going OK at your end?
<rick_h_> huwshimi: we'll see. I'm out tomorrow so just working on getting the laptop setup on raring 
<huwshimi> rick_h_: OK cool, success?
<rick_h_> it's installed, still need to re-setup my environments for charmworld/juju-gui for working on stuff
<huwshimi> Fun!
<rick_h_> party party
<huwshimi> :)
<rick_h_> let me know if you need anything and I'll look out for any branches or at list ping others in the morning
<huwshimi> rick_h_: Thanks, will do. Enjoy your evening :)
<rick_h_> hopefully we'll get the demo stuff all wrapped up
<gary_poster> hatch, when you are around, http://paste.ubuntu.com/5629085/ is another way of addressing the redraw problem we saw (ignoring lines 56-59, and lines 87++).  It is still a bit of a band-aid, but it is a good change IMO that happens to fix the immediate problem.  Preventing the three-times dispatch will be the better fix later, but we'll still want this.
<gary_poster> teknico, LGTM thanks
<teknico> gary_poster, I'd do anything to make Sublime happy, you know ;-)
<gary_poster> teknico, lol
<rick_h_> luca_: replied to your comments on the badges. If there's an issue please open a new bug to address how the .png should be updated.
<frankban> gary_poster: morning. "Make selenium CI tests for sandbox". Is this switching to sandbox=true and then, e.g. deploying a charm?
<luca_> rick_h_: Ah, I wasn't sure what to do :)
<gary_poster> frankban, yeah, that would be a good start :-)
<rick_h_> luca_: yea, it's all good. Since the change has landed/etc it's a new change to adjust it going forward. 
<frankban> gary_poster: cool
<gary_poster> frankban, did you get a chance to look at charm tests?
<frankban> gary_poster: yes, they passed locally two times in a row
<gary_poster> frankban, ok cool, good enough.  Thank you very much.  I think it would be great to have an effort to see what needs to happen to make them reliable for everyone.  I wish they weren't so expensive to work on. :-/
<gary_poster> We can talk about that next week
<frankban> gary_poster: sounds good
<gary_poster> cool
<frankban> gary_poster: I see you also have a retrospective card re charm regression. less fragile tests and setting up a CI for the charm (including lint/pep8) could improve the situation IMHO
<frankban> https://pypi.python.org/pypi/flake8 is interesting
<gary_poster> frankban, +1.  I think there's a discussion, and maybe a tough decision, about CI vs. tarmac also though.  The issue with the charm is that when you push to trunk, it is *released*.  We don't have a release mechanism like with the GUI itself.  CI is really too late.  Alternatively, maybe we set up a different trunk, or a different release branch, and release to it after CI and QA.  That might work with other things 
<gary_poster> we need to do.
<frankban> gary_poster: got it. I wonder if this could also be the right time to make deploy tests use juju-core
<gary_poster> frankban, I think we need both. Which will make the tests even slower. :-/
<gary_poster> possibly also more difficult to arrange.
<frankban> gary_poster: do you know if jitsu test is compatible with juju-core?
<gary_poster> frankban, I don't know.  However you are cordially invited to the meeting for this blueprint ;-) https://blueprints.launchpad.net/ubuntu/+spec/servercloud-s-juju-charm-testing
<frankban> :-) 
<gary_poster> that will be sometime next week
 * frankban thinks our own custom test runner could not be a bad idea [spoiler]
<gary_poster> heh
<gary_poster> might be interested in that
<hatch> gary_poster: thanks lookin gat diff
<gary_poster> cool
<sinzui> hatch, jcsackett, someone? Huw has a branch that needs another review https://codereview.appspot.com/9159044/
<gary_poster> sinzui, done
<gary_poster> sinzui, is there a test deployment I should look for today?  I got an impression from Rick that you might want me to update the demo site today?
<sinzui> gary_poster, we are still evaluating that. We have a branch that will unblock a lot of work. I suppose it will be in the afternoon when we decide if we have something to show off
<gary_poster> sinzui, ok.  I'm hoping to take the afternoon off, but I can sneak in and see if you want an update
<sinzui> okay. understood
<hatch> I like your diff, couple questions...
<gary_poster> sure
<hatch> well just one
<hatch> how does this solve the problem? heh
<gary_poster> :-)
<hatch> I like how we don't create new instances
<hatch> but isnt' the execution the same?
<gary_poster> hatch, first, tbh, this was a cleanup that I thought would solve another issue.  It didn't.  Then I noticed that this was cleaned up.  bonus! ;-)  That admission made, now you know I'm kinda guessing, but...
<gary_poster> My hypothesis is that the fact that the "then"s are called synchronously makes the difference
<gary_poster> So, old code:
<gary_poster> promise 1: showView
<gary_poster> [stuff happens]
<gary_poster> promise 2: showView
<gary_poster> [stuff happens]
<gary_poster> promise 3: showView
<gary_poster> New code:
<gary_poster> promise: showView, showView, showView!
<gary_poster> [stuff didn't get a chance to happen]
<gary_poster> hatch I realize that's lame
<gary_poster> but that's what I got ;-)
<hatch> haha - well it's a hypothesis that fits
<hatch> so I'll take it!
<gary_poster> :-)
<gary_poster> hey jujugui.  I propose that we postpone our weekly retrospective until we see each other next week face to face.  However, let's have our daily call in 9 minutes at the usual Friday time.  please update kanban
<Makyo> gary_poster, +1
<gary_poster> cool
<hatch> I vote that we stop using paste.ubuntu.com in favour of something with syntax highlighting :)
<gary_poster> it has syntax highlighting!  you just have to select it...
<hatch> ohhhh so it's allyalls fault LO
<hatch> :P
<Makyo> Pff.
<gary_poster> jujgui call now
<gary_poster> sorry
<gary_poster> jujugui :-P
 * gary_poster signed up for Selenium for Pythonistas.  Thanks bcsaller_ :-)
<bcsaller_> cool :)
<gary_poster> oops
<hatch> there are a number of javascript meetups but they are all in SF
<gary_poster> bcsaller_, fwiw landscape is working fine with improv.  yay!  so, no worries.
<bcsaller_> gary_poster: ha, cool, I'll check what I didn't set up properly 
<gary_poster> cool
<Makyo> Back in a little bit.  Getting a tour since it's the first day.
<bcsaller_> gary_poster:  (and anyone else) if there are any mutations you'd like to see let me know
<gary_poster> bcsaller_, just to screw with people we could move the services around the screen ;-)
<gary_poster> *note that was not a suggestion ;-)
<bcsaller_> gary_poster: already started, I have one that should occasionally flip/mirror the setup
<gary_poster> heh
<gary_poster> cool
<hatch> bcsaller_: any chance you could make one of your little simulators that could simulate a slow back end?
<hatch> so we can test for race conditions and the like
<bcsaller_> hatch: that would maybe be something else. This creates mutations, we could add somethign at the sandbox layer that delayed outoing responses, but I'm not really sure how useful that is
<hatch> well right now with rapi and fakebackend everything returns really fast
<hatch> I'd like to see what happens if there is a hangup somewhere
<bcsaller_> hatch: but you'd want that relative to user-generated events, the stuff coming out of simulator is random and acts as though another use made remote changes to the env
<bcsaller_> so the delay would be unknowable
<bcsaller_> but a delay slider relative to sandbox replies is do-able outside this effort
<hatch> ahh I see what you're saying
<hatch> bcsaller_: are you here today?
<bcsaller_> hatch: yes
<hatch> ok great, I am just fixing the tests from garys patch to that race condition and then I'm going to propose this so I'd like another QA just to be safe
<bcsaller_> hatch: let me know
<hatch> just finished the fixes so now running the suites again it'll probably be 10-15
<gary_poster> jujugui, stepping away for afternoon.  Will occasionally check back.  I have a lot of work to do before Monday, so if you want to get in touch, I will be around eventually. :-)  I look forward to seeing everyone soon!
<hatch> enjoy! see you Tuesday
<bcsaller_> gary_poster: have a good one
<gary_poster> thanks :-)
<hatch> bcsaller_ if you could also plz qa this https://codereview.appspot.com/9178043/
<hatch> we can say gary and I paired so I'll land after one review :)
 * hatch is a rebel with a cause
<Makyo> Oops, reboot.
<hatch> bcsaller_: if I could bug ya to qa that that would be awesome :) I'd like to finally drag that card into landed :)
<bcsaller_> hatch: sorry I didn't say something, I've been working on it
<bcsaller_> hatch: still get the 3+ notifications, you didn't want to add the timer around that?
<hatch> I do....but I'm a little worried that it will then hide the real problem
<bcsaller_> hatch: The simulator aggressively  shows refresh 'opportunities' , but doing a plugin that forces semi-random traversals might be fun
<hatch> haha oh boy
<hatch> alllright finally merged that in!
<hatch> bcsaller_, it looks like the CI failure in IE was from your branch... for the sandbox import...IE probably doesn't support the same methods
<bcsaller_> nothing should touch the html5 codepaths
<bcsaller_> I can test my current stuff on ie soon though
<hatch> alright thanks - it just looks like that's when the latest failures started
<hatch> or it could be something entirely unrelated of curse :)
<hatch> bcsaller_, fakebackend.importEnvironment successfully imports v0 data - timeout exceeded
<hatch> so it probably just takes too long 
<bcsaller_> hatch: thats possible, I'm seeing errors in BrowserCharm test on IE, but I'll up the timeout on import
<hatch> hmm those aren't showing up in the CI video
<hatch>  /join #yui
<hatch>  /join #yui
<hatch> ...
<Makyo> Oh nooooo.  Working in the precise container broke lbox D:
<rick_h_> gary_poster: sinzui pushed up a working fix to the ~juju-gui/browser-default branch
<hatch> bcsaller_, the other day I picked up FTL - I haven't been able to get more than 1/2 way on normal haha
<bcsaller_> hatch: yeah, that one has a steep learning curve 
<hatch> I got to the end on easy and got the final boss down to about 1/4 but that's it
<hatch> I never have any money so my ship always sucks
<bcsaller_> hatch: I bet you clear zones too fast then 
<hatch> yeah? I've tried  but maybe I need to keep the fleet RIGHT behind me
<hatch> I'm guessing that you have been more successful?
<bcsaller_> hatch: yeah, I don't play much now, but I do have all the ships
<hatch> heh I have 3 :)
<hatch> I have been looking at Kerbal Space Program game
<hatch> looks pretty cool
<hatch> http://store.steampowered.com/app/220200/
#juju-gui 2013-05-04
<gary_poster> thank you rick_h_ 
<rick_h_> gary_poster: work ok?
<rick_h_> I didn't qa, should have 
<gary_poster> rick_h_, trying now...
<gary_poster> rick_h_, https://ec2-23-20-230-72.compute-1.amazonaws.com/ has updates
<gary_poster> rick_h_, deploy from charm browser works ok.  charm browser still not as fast as your demo. shoulkd I still connect to master.jujucharms.com?
<rick_h_> gary_poster: so we did not make the change to not include the svgs in the api stream
<gary_poster> rick_h_, ok
<rick_h_> gary_poster: that's work that was deemed post oakland
<gary_poster> ok
<rick_h_> gary_poster: so it won't be as fast as the demo, but will be promised
<gary_poster> wildly faster than it was, at least, rick_h_ 
<rick_h_> gary_poster: yea, hopefuly more useful as a demo with the promise to still have good room to go
<rick_h_> thanks for the update gary. Appreciate the last minute pull. Hmm, looks like they didn't update manage. for searching as hoped :( 
<rick_h_> maybe they'll get that when we get there
#juju-gui 2014-04-28
<Makyo> bac, https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AgF6NYIOVngmdGFNdjQ3dlFEb3c4VmNfY3hjeVYyT1E&usp=sharing#gid=1
<Makyo> ccccccdiltnnffldhrubrbvjdvecendreuhnjivhuvtu
<Makyo> :S
<Makyo> rick_h_, https://bugs.launchpad.net/charmworld/+bug/1313880
<_mup_> Bug #1313880: Bundle search results do not include service annotations. <charmworld:New> <https://launchpad.net/bugs/1313880>
#juju-gui 2014-04-29
<bac> redir: http://paste.ubuntu.com/7360387/
<jcsackett> hatch: https://bugs.launchpad.net/charms/+bug/1229377/comments/2
<_mup_> Bug #1229377: Charm needed: Ghost blogging platform <Juju Charms Collection:Incomplete by hatch> <https://launchpad.net/bugs/1229377>
<hatch> https://gist.github.com/20f3901a8cf6219a2d25
<rick_h_> bac abentley has verified that subversion line was from when I first created the makefile
<rick_h_> bac so I'm just a moron and there's no good reason it's there I can ever think of
<bac> hello redir
<rick_h_> bac so I'm just a moron and there's no good reason it's there I can ever think of
<rick_h_> bac abentley has verified that subversion line was from when I first created the makefile
<bac> rick_h_: yeah, we discovered it was in version 1 of the makefile.  so that means we inherited it from kapil
<kadams54> guihelp: anyone around to review https://github.com/juju/juju-gui/pull/265 ?
#juju-gui 2014-04-30
<bac> jcsackett: ping
<bac> jujugui can someone near jcsackett poke him?
<lazyPower> jcsackett: I'm silly. I pulled my workspace from home and re-deployed and I must have remembered incorrectly. I saw the same behavior peter demonstrated.
<lazyPower> so, apologies for the false positive. 
<jcsackett> lazyPower: all good. i'm actually a little relieved that it doesn't work, since that at least comports with my notion of reality. :p
<bac> jcsackett: cw review? https://code.launchpad.net/~bac/charmworld/add-annotations-back/+merge/217823  old school.
<jcsackett> hiya.
<jcsackett> bac: lgtm, with one idea for a slightly cleaner approach to checking extra_data.
<bac> thanks jcsackett. nice suggestion
<jcsackett> yw
<bac> jcsackett: https://docs.google.com/a/canonical.com/document/d/1BenQuD_mN-OotNE84_Axt_mWuCS76no1EsuFwvuZE-M/edit#
#juju-gui 2014-05-01
<Makyo> jcsackett, https://github.com/makyo/ghost-charm/tree/config-port-80
<Makyo> https://github.com/hatched/ghost-charm/pull/21
#juju-gui 2014-05-02
<kadams54> The Silver Searcher: https://github.com/ggreer/the_silver_searcher
<rick_h_> jujugui can someone send peter to Mark's room please. Ale needs him
<hatch> rick_h_ peter isn't here
<rick_h_> hatch: can someone do a quick look around please?
<hatch> sure
<rick_h_> thanks appreciate it
<hatch> rumor has it he went to the lobby
<huwshimi> (to check out)
<huwshimi> (he's coming back)
<rick_h_> huwshimi: hatch ah ok thanks
<rick_h_> just toss him this way he can please
<huwshimi> sure
<huwshimi> bac: http://comingsoon.jujucharms.com/trusty/uwsgi-0/:flags:/il/
<redir> bac: ttp://goo.gl/46a6uU
<bac> redir: got it, thanks
<redir> np
#juju-gui 2015-04-27
<rogpeppe1> uiteam: trying hard to work out how to configure my irc client again... :)
<mhilton> rogpeppe1, well you've got somewhere :) what do you want to know
<mhilton> rogpeppe1, please bear in mind I don't seem to be connecting to canonical either.
<rogpeppe1> mhilton: it's just working out where the right pop up box is buried. think i may be getting somewhere now.
<rogpeppe1> mhilton: i *thought* it was just a matter of working out where the right pop up box is buried...
<huwshimi> mhilton: I had to try to connect a couple of times before it worked.
<rogpeppe1> mhilton: but it appears that i can't connect even when i put in the right password
<rogpeppe1> mhilton: i've tried it with and without the text preceding the colon
<mhilton> rogpeppe1, mine isn't even getting that far now. I think I've been banned for dossing the server in some way. I'm going to try again later.
<rogpeppe1> mhilton: looks like i've finally got in
<rogpeppe1> mhilton: i got lots of connection failures and finally it worked
<rogpeppe1> mhilton: is frankban out today as well?
<mhilton> rogpeppe1, there's nothing on the calendar about it
<rogpeppe1> mhilton: guess i'm not gonna get that PR landed then...
<rogpeppe1> mhilton: still can't get it?
<rogpeppe1> s/it/in/
<mhilton> rogpeppe1, I thought I'd let it cool down a bit, but I've just tried and not just yet. I'll leave it going for a bit and hopw
<mhilton> s/hopw/hope/
<mhilton> rogpeppe1, I upgraded my machine over the weekend, most things were happy, but my juju local environement is not in a good state
<rogpeppe1> mhilton: you left it going?
<rogpeppe1> mhilton: what did you upgrade to?
<mhilton> rogpeppe1, I didn't leave it going deliberately, I more forgot it was going. I've upgraded to 15.04 vitriolic velocoraptor (or whatever it is)
<rogpeppe1> mhilton: ah, i think that uses systemd
<rogpeppe1> mhilton: so i'm not surprised
 * rogpeppe1 likes vitriolic velociraptor
<rogpeppe1> as a name...
<mhilton> rogpeppe1, as a pet it wouldn't be so good.
<rogpeppe> mhilton: do you fancy chatting through some of the cyclic dependency issues?
<mhilton> rogpeppe: yeah why not, gogogo?
<rogpeppe> mhilton: gogogoing
<rick_h_> morning folks
<rick_h_> rogpeppe: mhilton any luck with irc?
<rogpeppe> rick_h_: it worked for me (eventually)
<rick_h_> rogpeppe: cool good to hear
<rick_h_> rogpeppe: mhilton are you all in the other channel?
<rick_h_> it feels quite alone in there unless I typo'd something
<mhilton> rick_h_: I just keep getting kicked off before it even tries to log in
<rick_h_> mhilton: what irc client?
<mhilton> rick_h_, gnome xchat2 I think
<rick_h_> mhilton: and the video isn't helping? /me didn't look at it but kept seeing it as the way to go
<mhilton> rick_h_: I followed the video, (although I think I have a different version) It has a good soundtrack. I think the server just decided I was DOSing it and has banned me.
<rick_h_> mhilton: how rude of it
<bac> morning
<rick_h_> morning bac 
<rick_h_> rogpeppe: if you get a sec can you share my way the JEM api/etc doc please?
 * mhilton lunches
<rogpeppe> rick_h_: this is as far as it got (still very much WIP) https://docs.google.com/document/d/1EKn65kW08ZyH4kOqvhI9A190tlBSSM7KOvmBMoqcPzg/edit
 * rogpeppe lunches too
<rick_h_> rogpeppe: rgr ty much
<rick_h_> bac: are you able to join the other channel?
<bac> rick_h_: yes, just got in
<rick_h_> ok, I must be in the wrong room then. 
<rick_h_> empty for me atm
<bac> yep, there are about a dozen in our channel
<rick_h_> yea, I was off in no where land evidently
<jrwren> you found the hidden level
<rick_h_> uiteam I'm out to the airport, hopefully back by standup but don't wait up for me
<bac> jcsackett: ping
<jcsackett> bac: pong.
<bac> jcsackett: are you coming to the call?
<jcsackett> bac: i need the link.
<bac> jcsackett: on your calendar
<jcsackett> mhilton: hi. i understand you upgraded to vivid. are you doing your development work directly on your computer, or do you isolate it in vm/lxc/etc?
<mhilton> directly currently, when that doesn't work I tend to use Vagrant, why are there known issues?
<mhilton> jcsackett, ^
<rogpeppe1> this is potentially interesting for stress-testing our APIs: https://github.com/dvyukov/go-fuzz
<jcsackett> mhilton: some the ppas etc for storefront don't work on vivid. i'm figuring out how much that blocks us.
<mhilton> jcsackett: If you want me to test anything for you just ask.
<jrwren> oh right, no nodejs for vivid in the ppa we use :(
<mhilton> uiteam: I'm finishing for the day, have a good evening
<rick_h_> mhilton: night
#juju-gui 2015-04-28
<rick_h_> lazyPower: fyi https://bugs.launchpad.net/juju-gui/+bug/1446788 unable to dupe it atm. We did a release last week and wonder if we accidently corrected something
<mup> Bug #1446788: Build-a-bundle appears broken in firefox on jujucharms.com <juju-gui:Invalid> <https://launchpad.net/bugs/1446788>
<rick_h_> lazyPower: please let us know if you can still dupe and we can try to figure out what we're missing
#juju-gui 2015-05-01
<jcastro> hey rick_h_
<redelmann> Hi, is juju-gui ready for actions?, need to upgrade from agent:1.22.0 to 1.23.0?
#juju-gui 2016-05-04
<frankban> uiteam does canonical irc work for you?
<fabrice> yep
<rogpeppe1> frankban: yup, fine for me
<frankban> ok thanks
#juju-gui 2016-05-06
<rogpeppe2> uiteam: i can't connect to canonical IRC - is that true of others too?
<huwshimi> rogpeppe: It appears to be fine here
<mhilton> I'm connected
<testfbf2> frankban: test
<testfbf2> frankban: test2 
<rick_h_> frankban: pie
<frankban> rick_h_: thanks :-)
<rick_h_> :) I'm helpful like that
<testfbf2> frankban test3
<testfbf2> last test
<testfbf2> frankban: last test
<Node_849> prova 1
<Node_849> prova 2 - fatto
