[00:12] <hatch> interesting bug https://bugs.launchpad.net/juju-gui/+bug/1331248
[00:12] <_mup_> Bug #1331248: Uploading a local charm hangs when uploading to ec2 <juju-gui:New> <https://launchpad.net/bugs/1331248>
[00:13] <rick_h_> hatch: yea, I'm guessing it's more sync waiting for juju response
[00:13] <rick_h_> since your upload speed to juju probably stinks
[00:13] <hatch> rick_h_ yeah we need to show some kind of inspector...or spinner...or something :)
[00:14] <rick_h_> hatch: yea
[00:15] <hatch> damn to I like the GUI though
[00:15] <hatch> :)
[00:15] <hatch> using the CLI is for suckers :P
[00:15] <rick_h_> :)
[00:15] <rick_h_> cli4lif 
[00:15] <hatch> lol
[00:20] <hatch> rick_h_ there was a bug about the inspector staying around when you destroy the service.....any idea where that bug is?
[00:21] <rick_h_> hatch: thought it was corrected in the last release
[00:22] <hatch> I was able to reproduce it in the latest release so I can re-create it if it was destroyed
[00:22] <hatch> yeah I'll remake it, I can't find the bug
[00:22] <rick_h_> I thought it was just marked fix released
[00:22]  * rick_h_ looks
[00:22] <rick_h_> hatch: so are you getting that bug?
[00:22] <hatch> yep
[00:23] <rick_h_> https://bugs.launchpad.net/juju-gui/+bug/1321558
[00:23] <_mup_> Bug #1321558: Destroying a service leaves inspector visible <juju-gui:Fix Released by hatch> <https://launchpad.net/bugs/1321558>
[00:23] <hatch> on the latest GUI release on precise 
[00:23] <hatch> ahh ok my issue is slightly different
[00:23] <hatch> I'll create a new bug
[00:26] <hatch> aaaaa voila https://bugs.launchpad.net/juju-gui/+bug/1331250
[00:26] <_mup_> Bug #1331250: Clicking to view the inspector of a dying service keeps it around after the service is destroyed <juju-gui:New> <https://launchpad.net/bugs/1331250>
[00:28] <hatch> ^ rick_h_  so it's different, definitely an edge case, but something that we should address sometime :)
[00:29] <rick_h_> hatch: rgr, add it to the backlog and we'll get it up sometime. 
[00:32] <hatch> sounds good
[00:40] <hatch> hmm changing the port to 80 breaks the ghost charm
[00:40] <hatch> vewwwwwy intewwesting
[07:55] <rogpeppe> huwshimi: hiya
[07:56] <huwshimi> rogpeppe: Morning
[07:56] <rogpeppe> huwshimi: you're good at Javascript, right?
[07:57] <rogpeppe> huwshimi: i just saw a (quite amusing - he's always quite amusing) random question about javascript from a mate on facebook and wondered if you might be able to provide the answer...
[07:57] <rogpeppe> huwshimi: http://paste.ubuntu.com/7662476/
[07:58] <rogpeppe> huwshimi: any idea?
[07:58] <huwshimi> rogpeppe: Maybe, I'll take a look in a sec, just on a call :)
[07:59] <rogpeppe> huwshimi: ah, np, ta!
[08:21] <huwshimi> rogpeppe: Instead of doing the substring he could try ".replace('£', '')"
[08:22] <huwshimi> rogpeppe: So, var origprice = parseInt($(this).find(".origprice").text().replace('£', ''));
[08:22] <huwshimi> rogpeppe: Would that work?
[08:23] <rogpeppe> huwshimi: it may do. on further looking at the issue, i reckon it's probably something before that statement
[08:23] <rogpeppe> huwshimi: if it was me, i'd probably just use a regex to replace everything except trailing \ds
[08:24] <rogpeppe> huwshimi: apparently (reading further) there was possibly a nbsp there too
[08:25] <rogpeppe> huwshimi: perhaps it was getting treated as white space and stripped automatically at some point
[08:26] <rogpeppe> huwshimi: it seems he's now solved the issue by not producing the £ in the first place... which seems like a better solution
[08:26] <rogpeppe> huwshimi: ta for looking!
[08:27] <huwshimi> no problems!
[09:35] <frankban> rogpeppe: morning, how are you doing?
[09:36] <rogpeppe> frankban: hiya
[09:36] <rogpeppe> frankban: not bad, thanks
[09:36] <rogpeppe> frankban: you?
[09:37] <frankban> rogpeppe: fine thanks. how is the bundle stuff going?
[09:38] <rogpeppe> frankban: i've just been familiarising myself with the store code, mostly
[09:38] <frankban> rogpeppe: impressions?
[09:38] <rogpeppe> frankban: seems fine
[09:39] <rogpeppe> frankban: shall we have a chat about what features we want for bundles?
[09:39] <frankban> rogpeppe: sure
[09:39] <rogpeppe> frankban: standup hangout?
[09:40] <frankban> rogpeppe: sounds good, joining
[10:56] <rick_h_> morning all
[11:05] <rick_h_> rogpeppe: frankban can you guys bring up in the standup today to find a volunteer to attend the cloud cross team call tomorrow?
[11:05] <rick_h_> rogpeppe: frankban there's an email to canonical-tech that you can reply to do get invited in. 
[11:19] <marcoceppi> have you guys seen this? It's coming in the Google Chrome release (running dev atm)
[11:19] <marcoceppi> http://i.imgur.com/PW29H2W.png
[11:20] <marcoceppi> this is 37.0.2041.4 dev
[11:20] <marcoceppi> There's no way to get around it at the moment
[11:21] <marcoceppi> Oh, just kidding
[11:21] <marcoceppi> there's a link
[11:24] <rick_h_> frankban: did you get travel auth?
[11:25] <frankban> rick_h_: yes, already booked the flight
[11:25] <rick_h_> frankban: ok awesome 
[11:41]  * frankban lunches
[12:37] <frankban> rogpeppe: I am back
[12:40] <frankban> rogpeppe: please ping me when you are ready
[13:16] <rogpeppe> frankban: ping
[13:16] <jcastro> https://news.ycombinator.com/item?id=7909286
[13:17] <jcastro> check it out folks ^^ 
[13:32] <bac> nice jcastro
[13:34] <frankban> rick_h_: time for a quick hangout?
[13:35] <frankban> bac: ^^^
[13:35] <rick_h_> frankban: sure thing
[13:35] <frankban> rick_h_, bac: we are on the daily standup hangout
[13:57] <rogpeppe> bac: cs:bundle/mediawiki-3
[13:58] <rogpeppe> bac: cs:~someone/bundle/mediawiki-4/scalable
[14:28] <hatch> morning all
[14:31] <lazyPower> o/ hatch
[14:32] <lazyPower> Guess who's got 2 thumbs and aced his Ubuntu Membership exam this morning? this guy!
[14:32] <hatch> w000t congrats! 
[14:34] <hatch> arosales hey I worked a bit on the ghost charm last night and ran into an issue putting the charm on port 80 by default - I haven't solved it yet, just FYI in case you try to set it to port 80 :)
[14:34] <lazyPower> hatch: are you rying to serve over port 80 as a normal user?
[14:35] <hatch> umm I'm not sure what user it's running as, one sec
[14:35] <Makyo> hatch, we tried that in Vegas, remember?  Have to run it behind a proxy (either charm or local)
[14:36] <hatch> lazyPower ubuntu user
[14:36] <hatch> Makyo right, but why doesn't it work....it doesn't make much sense 
[14:36] <hatch> it should work without proxy
[14:36] <Makyo> hatch, ports <1024 are privileged, can only run as root.
[14:36] <hatch> but the GUI can be served over 80?
[14:36] <Makyo> Behind a privileged proxy.
[14:37] <hatch> ohh
[14:37] <hatch> well what the deuce
[14:37] <Makyo> You can proxy it behind nginx in the charm, maybe?
[14:37] <hatch> so the review made us change the owner off root then wants us to put it on port 80
[14:37] <hatch> lol
[14:37] <Makyo> Or lighttpd or something small.
[14:37]  * hatch shakes fist
[14:38] <hatch> I'm confused as to why we can put nginx as root but not the blog?
[14:39] <Makyo> Because a lot of very seriously smart people put a lot of thought into how to write something that can run on a privileged port.
[14:39] <Makyo> I believe the only privileged part  of most webservers is the listener, everything else runs as an unprivileged user and communicates with that process.
[14:40] <hatch> ohhhhh so you're calling the ghost authors stupid
[14:40] <hatch> now I see
[14:40] <hatch> :P
[14:40] <Makyo> :P
[14:40] <Makyo> There's just a difference between the type of dev work you do for a web app and the type of dev work you do for a server.
[14:40] <hatch> ok well I guess I'll update the review notes to this effect (I'm not setting up nginx off the bat) to get this in the store
[14:41] <hatch> that's what they said about crypto and openssl and look at what happened there 
[14:41] <Makyo> It'll run behind a haproxy charm on 80, that's what I did for the demo.
[14:42] <hatch> yeah I'm fine with that - I was just trying to address the review notes
[14:42] <hatch> I wish there was an external nginx charm
[14:43] <hatch> https://jujucharms.com/~hp-discover/trusty/nginx-4/?text=nginx
[14:43] <hatch> there is this one but it's not promoted for some reason
[14:44] <hatch> marcoceppi ^ why don't we have a promoted nginx charm? Is there something wrong with this one?
[14:44] <marcoceppi> hatch: I just wrote that charm last week and it still needs some work
[14:44] <hatch> ohhh well then you rock
[14:45] <marcoceppi> hatch: it also requires you to use subordinates (website, php-website) and it's currently not working wiht more than one sub deployed becauseeeeeee dns is a mythical being in the land of juju deployments
[14:46]  * marcoceppi should update the readme
[14:46] <hatch> haha - yeah I looked into writing an nginx charm and realized that it was outside of my expertise :)
[14:46] <hatch> if you need any help testing I'd be happy to give it a go
[14:46] <hatch> but unfortunately I'm not very well versed in the nginx networking stuffs
[14:47] <marcoceppi> hatch: you can deploy this and cs:~hp-discover/trusty/website if want to see it working together
[14:47] <hatch> cool
[14:50] <Makyo> jujugui call in 10
[14:50] <hatch> wow it's that time already
[15:00]  * bac trying.  will be there shortly i hope
[15:00] <hatch> jujugui call now
[15:07] <arosales> hatch, thanks for the fyi :-)
[15:07] <hatch> np!
[15:08] <hatch> Makyo heh now you have a good consistent 1-2s lag :)
[15:09] <bac> jujugui: did everyone get their travel auth
[15:09] <Makyo> I knowww.  Makes me sad.  I may coffeeshop in the mornings.
[15:09] <kadams54> bac: yup.
[15:09] <Makyo> bac, yep
[15:09] <jcsackett> bac: yup.
[15:09] <bac> i guess i should've asked the inverser
[15:09] <bac> s/inverser/inverse/
[15:09] <jcsackett> Makyo: the 1-2s lag is charming. makes me feel like we're all on the evening news.
[15:09] <hatch> haha
[15:09] <bac> Makyo: your lag makes me self-conscious
[15:10] <hatch> no, if that was the case Makyo  would be talking about Justin Beiber or something
[15:10] <bac> about my crap internet, even though i was using the maligned LTE
[15:11] <hatch> we need FTL packet transfer
[15:11] <Makyo> This satellite is actually faster than our old cable, but with much higher ping times.
[15:11] <bac> jcsackett: if that's the case i want to be Sylvia Poggioli reporting from Rome
[15:11] <Makyo> Hahah
[15:11]  * bac admits having consulted wikipedia for spelling...wasn't close
[15:11] <kadams54> lol
[15:13] <jcsackett> hatch: re ghost review--i'm actually ok with us killing sqlite support based on the "opinionated deployment" idea of charms, and by that same token we shouldn't run on 80 by default b/c you should be deploying a front end proxy with it.
[15:14] <jcsackett> hatch: but if it's a super insistent requirement i can probably get the charm to setup nginx on the same machine to work with 80.
[15:14] <jcsackett> not sure *when* i'll have time for that, but it's not actually that hard to do.
[15:14] <hatch> jcsackett yeah it's "possible" I'm just going to give some push back and see where they let me land
[15:15] <hatch> jcsackett can you comment on the "being ok with dropping sqlite" in the bug so that in the future we know where the convo left off? :)
[15:18] <jcsackett> hatch: already did.
[15:18] <jcsackett> (i assume you mean the issue you filed on github?)
[15:18] <hatch> oh haha
[15:18] <hatch> yes
[15:51] <hatch> so I bought these crystal stout beer glasses - one broke when I put it in the sink to wash it :/ quality
[16:08] <bac> frankban: can you have a look at this doc-only quickstart branch? https://codereview.appspot.com/106120043
[16:08] <frankban> bac sure
[16:08] <bac> frankban: i 'cleaned up' the rst so it renders better.
[16:09] <bac> ymmv
[16:09] <bac> frankban: restview from pypi is nice-ish
[16:09] <frankban> yeah
[16:17] <frankban> bac: done
[16:50] <hatch> nottrobin no longer a prodigy? :)
[16:51] <nottrobin> rofl
[16:52] <nottrobin> hatch: that was a misunderstanding
[16:52] <hatch> haha
[16:55] <hatch> Makyo here is my final version - I think this will work the best https://gist.github.com/hatched/02ac1b0650ed87877655 keeping it all in ECS
[16:59] <Makyo> hatch, that looks like it'll work, yeah.
[16:59] <hatch> it's about 10% of the lines I HAD writen
[16:59] <hatch> lol
[17:00] <hatch> less is always more in code haha
[17:00] <rogpeppe> frankban: i'm very nearly done for the day now. i will try to put an email together summarising the stuff we've put together tomorrow morning
[17:01] <frankban> rogpeppe: EOD for me too. yeah thanks, I'll ping you tomorrow, have a great evening
[17:06] <jcsackett> juju-gui: is there an easy way to get the gui in a deployed environment to update to the most recent commit of your repo/branch?
[17:07] <jcsackett> ...or even better, with a local environment, make it use your working directory...
[17:09] <frankban> jcsackett: there is no way to use the working directory. For the first question, you can use the juju-gui-source option, e.g. juju set juju-gui juju-gui-source="https://github.com/frankban/juju-gui.git BRANCHNAME"
[17:09] <jcsackett> frankban: yeah, i did that to set it in the first place, but then if i make changes i can't update it. and i can't hack on the source in the lxc, b/c the changes don't get picked up/loaded into the server.
[17:11] <frankban> jcsackett: I did not try if that works only with git revisions rather than branch names. To be able to hack directly the GUI from inside the LXC, you can "juju set juju-gui juju-gui-debug=true juju-gui-console-enabled=true" and then go to something like /usr/lib/juju-gui/juju-gui/build-debug" or similar
[17:11] <hatch> jcsackett set it to develop then back to your repo right away
[17:11] <hatch> then wait
[17:11] <hatch> :)
[17:11] <frankban> s/only/also
[17:11] <jcsackett> so, basically, there's no easy way. :)
[17:12] <hatch> although I would also be interested if there was a way to put a hash there
[17:12] <jcsackett> console-enabled is a good tip, thanks frankban 
[17:12] <hatch> or if it requires the branch name
[17:12] <hatch> but yes frankban's method of hacking the gui in place is the best :)
[17:13] <jcsackett> so, i move that we never say a "real env" bug is small. the development process is somewhat cumbersome. :p
[17:15] <frankban> jcsackett: yes we need to improve that, it would be great to investigate connecting a "make devel" GUI to an existing LXC guiserver
[17:18] <hatch> frankban YES!!!
[17:18] <hatch> :)
[17:44] <hatch> jujugui looking for a review (no qa needed) https://github.com/juju/juju-gui/pull/392
[17:44] <hatch> Makyo ^
[17:46] <kadams54> hatch: I can take a look at it if you can answer a YUI question :-)
[17:47] <hatch> sure shoot
[17:49] <kadams54> Is there a way, when simulating a change event on a <select>, to specify what the new value should be?
[17:49] <hatch> selectNode.fire('change', { dataz... });
[17:49] <hatch> like that?
[17:54] <kadams54> Maybe. I think I need to change the actual value reported by mySelect.get('value')
[17:55] <hatch> have some code for me to see?
[17:55] <hatch> create a wip pr
[17:56] <kadams54> hatch: will do, after I get done reviewing your PR.
[17:57] <hatch> cool
[17:57] <kadams54> hatch: are these changes so that we can edit values in the inspector and then have them committed/deployed with the rest of the change set?
[17:59] <hatch> yep
[17:59] <hatch> its so that the inspector displays the ecs'd values even though they aren't actually saved to the env yet
[18:03] <kadams54> hatch: OK, review done. Getting WIP branch up.
[18:03] <hatch> thanks
[18:06] <kadams54> hatch: https://github.com/juju/juju-gui/pull/393
[18:29] <hatch> kadams54 why aren't you using e.newVal and deferring instead to touching the DOM again?
[18:29] <kadams54> I figured you'd mention that :-)(
[18:30] <kadams54> I've already made the change locally
[18:31] <kadams54> Unfortunately e.newVal only applies for line 97; doesn't get me off the hook for line 80.
[18:39] <hatch> looking
[18:40] <hatch> ok I'll make some comments in the code
[18:42] <hatch> kadams54 ok replied
[18:49] <jcastro> rick_h_, for quickstart for the docs for osx
[18:49] <hatch> jcastro he is out today/tomorrow
[18:49] <hatch> kadams54 do my comments make sense?
[18:49] <jcastro> ok
[18:50] <jcastro> hatch, do you know anything wrt. quickstart for osx?
[18:51] <hatch> I've seen the discussions in the channel :) What did you need?
[18:51] <jcastro> do you know if it's in brew?
[18:51] <hatch> it is!
[18:51] <jcastro> so is this legit, changing "brew install juju" to "brew install juju juju-quickstart"?
[18:52] <jcastro> I have no idea what the syntax is
[18:52] <hatch> http://bazaar.launchpad.net/~juju-gui/juju-quickstart/trunk/view/head:/README.rst#L58
[18:52] <hatch> :)
[18:53] <jcastro> ack
[18:59] <hatch> jcastro are you working on adding the docs to the docs.u.c ?
[18:59] <hatch> er juju.u.c/docs
[18:59] <hatch> :)
[19:00] <jcastro> for quickstart?
[19:00] <jcastro> yes, in progress
[19:00] <hatch> yeah
[19:00] <hatch> awesome
[19:00] <jcastro> I'll have them done by EOD
[19:08] <hatch> nice
[19:15] <kadams54> hatch: Yeah, they make sense: this.set('containerType', e.newVal) then just do this.get('containerType') at line 80, right?
[19:15] <hatch> yep
[19:15] <hatch> small improvement, but I think it's better
[19:15] <hatch> er...small change I mean
[19:18] <hatch> I wonder if we increased the size of our CI vm's if they would be speed up at a reasonable rate
[19:18] <hatch> moar power
[19:18] <hatch> I suppose doing the tests in parallel would give the most improvement
[20:39] <hatch> jujugui how do I get changes that show up in the deployer bar to also show up in the summary? 
[20:40] <hatch> I am getting set_config calls in the deployer bar, but they are absent from the summary and clicking deploy does not remove them
[20:40] <hatch> kadams54 ^ any idea where I should be looking for this?
[20:41] <kadams54> hatch: no, sorry…
[20:43] <hatch> hmm
[20:43] <hatch> ok i'll bench for now, revisit in a bit
[20:49] <hatch> ok now I need to get back to that
[20:49] <hatch> heh
[20:51] <hatch> ahh found it
[21:01] <hatch> jcsackett how goes the battle with your bug?
[21:05] <jcsackett> hatch: having finally been able to get in a groove with my local env, good.
[21:06] <jcsackett> hatch: i ditched the loading circle b/c even in the "there's no service" thing you don't see it for long, and the indicator just doesn't slot into the browser at all.
[21:06] <jcsackett> hatch: once this lands, we can file a follow up to see about fixing the inspector view to do it right, with spinny circle, but i want this fixed sooner rather than later.
[21:07] <hatch> I don't even remember what the problem was anymore :D
[21:07] <hatch> ohh now I remember
[21:07] <hatch> :)
[21:07] <jcsackett> hatch: that's alright, i'll ping you for review and it'll all come back to you. :)
[21:07] <hatch> lol
[21:07] <bac> hatch: damn you're fast
[21:07] <bac> on the twitter
[21:08] <hatch> bac haha, I have Tweetdeck running with some choice streams :)
[21:08] <bac> i keep forgetting dumb tumblr autotweets
[21:09] <jcsackett> hatch: unfortunately, bug 1331202 makes QA of this difficult.
[21:09] <_mup_> Bug #1331202: Incomplete Charm data causes artifacting in the GUI <juju-gui:New> <https://launchpad.net/bugs/1331202>
[21:09] <jcsackett> we're going to want to schedule that bug for the next cycle, i think.
[21:10] <hatch> yeah...
[21:10] <hatch> agreed
[21:10] <bac> bbiab
[21:10] <hatch> I also filed a couple bugs last night which I found doing some ghost hacking
[21:10] <jcsackett> whatever caused it happened in the last three days, b/c it wasn't doing that when i first investigated.
[21:10] <hatch> yay for dog fooding
[21:11] <hatch> jcsackett well there shouldn't be incomplete data in the store
[21:11] <hatch> but the gui should handle it gracefully regardless
[21:15] <jcsackett> hatch: it treats nonexistant services as incomplete--produces the same artifact during the error condition i'm handling.
[21:15] <hatch> ahh yeah it should definitely degrade nicefully 
[21:16] <hatch> Makyo these methods to fetch the deployer bar summary are a little funky, is there a reason why we don't loop through the changeset once to build the summary instead of for each record type?
[21:17] <Makyo> Rushing it out the door for the demo?  They can go if there's a simpler way.
[21:17] <hatch> nah it's a follow-up I was jsut wondering if there was a major reason for this
[21:17] <hatch> cya
[21:17] <hatch> oh nm
[21:17] <hatch> I read that wrong lol
[21:18] <Makyo> I think it just piled up before ODS :)
[21:18] <hatch> ok I'll create a follow-up card but in the mean time I'll follow the trend 
[22:33] <Makyo> 285 failures, could be worse...
[22:33] <Makyo> Whoops, 335.  So yeah, I guess that is worse.
[22:37] <hatch> haha
[22:37] <hatch> party...on
[22:37] <hatch> Makyo I hope we don't conflict too much :O
[22:38] <Makyo> I don't think we did at all, but we'll see.
[22:40] <hatch> travel agent put me in the wrong seats.....hold time at Air Canada.....45m-1:08  - I think I'll try later
[22:40] <hatch> lol
[22:40] <hatch> I really like places that do the call-you-back stuff
[22:52] <bac_> hatch do you see the post I made on G+ about quickstart?
[22:53] <hatch> not yet
[22:53] <hatch> looking
[22:53] <bac_> it was over an hour ago. both on my personal and work accts
[22:54] <hatch> shared!
[22:56] <bac_> annoying that it is so hidey.
[22:56] <bac_> thanks
[22:56] <hatch> add a photo to your post so that G+ can pick it up, then it'll stand out more :)
[22:57] <hatch> you can even (somehow) add a special photo which makes G+ show it as a huge image
[22:57] <hatch> not sure how to do that - yet
[22:58] <hatch> https://plus.google.com/+JorgeCastro/posts/fc6dZSvjBLs vs https://plus.google.com/+JeffPihach/posts/8v5Xw4uf2FN 
[22:58] <hatch> the first one has the special image
[23:06] <huwshimi> Morning
[23:09] <hatch> morning huwshimi  hows it going?
[23:10] <huwshimi> hatch: Good thanks, yourself?
[23:10] <hatch> good good good
[23:12] <huwshimi> good
[23:40] <huwshimi> hatch: So in my new dragenter function can I just do e.preventDefault(); to solve that problem?
[23:41] <hatch> huwshimi yes but you could probably call the _ignore method....just to keep all the preventing stuff in the same place
[23:41] <huwshimi> hatch: Ah yes
[23:41] <huwshimi> hatch: Incidentally, it does seem to work fine at the moment.
[23:42] <hatch> really? heh
[23:42] <hatch> probably not cross browserly 
[23:42] <huwshimi> yeah, maybe not