#juju-gui 2013-08-19
<rick_h> morning huwshimi 
<hatch> morning huwshimi
<hatch> guess it's afternoon now :)
<huwshimi> hatch: Well and truly :)
<hatch> huwshimi: :) did you see the new IE10 bugs?
<hatch> there are a few which fall into your ballpark I think
<hatch> https://bugs.launchpad.net/juju-gui/+bugs?field.tag=ie10
<huwshimi> hatch: I did. It's strange that I didn't notice some of them. I just need to finish getting my IE vm working again and I'll take a look
<hatch> huwshimi: well a number of branches landed so it's entirely possible they were introduced there
<huwshimi> hatch: That's true
<hatch> in our retrospective we made up a rule that any branch that gets landed now needs to be qa'd in IE as well
<hatch> so get that VM up ;)
<huwshimi> That's fine, I've been QAing in IE for a while now
<hatch> oh awesome - well you are ahead of the curve
<hatch> :)
<hatch> morning
<hatch> I'm still looking for one more review/qa on https://codereview.appspot.com/13072043/ plz and thanks
<frankban> guihelp: anyone available for a python review? https://codereview.appspot.com/13106043 (I need another one)
<jcsackett> hatch: i'm looking at the card about closing the ghost inspector and opening the service inspector on deploy, and wondering if it's really as simple as it sounds. and you sem like the person to poke about that.
<hatch> yeah lets have a chat
<hatch> one sec just grabbing my coffee
<hatch> ^ jcsackett
<jcsackett> hatch: ok, be in guichat in a second.
<hatch> ok there
 * hatch wonders if there are only the three of us in today :)
<bac> hatch: i've been here all day.  just haven't had anything to say.  so, hello.
<hatch> well hello bac want to do a review/qa? https://codereview.appspot.com/13072043/ just need to check the branch out and run `make && make lint` and if there is no errors it qa's ok
<bac> hatch: writing a MP atm.  will do it in a second.
<hatch> thanks! would love to get this landed....the new jshint is so fast
<hatch> it takes longer to query the files than to lint them
<hatch> haha
<bac> hatch: there is a conflict in databinding.js
<bac> hatch: when merging your branch into trunk
<hatch> not surprising considering the time between branching and today :)
<hatch> I'll merge
<hatch> one minute
<hatch> bac: re-proposing - it was actually only a trivial conflict
<bac> hatch: yeah
<hatch> I'll ping when it's done proposing
<hatch> Makyo: you can probably just land your IE fix, it's pretty trivial
<hatch> bac: done proposing
<Makyo> hatch, Alright.
 * Makyo will take that as an LGTM
 * hatch did lgtm :)
<Makyo> Well, bonus.
<hatch> Makyo: do you know if we have any way of pulling the real constraints into the gui for the ghost inspector?
<hatch> I'm trying to figure out if this is broken or if we simply don't have the functionality
<Makyo> hatch, don't know what you mean by real constraints.
<hatch> well like say we are on EC2, how do we pull in what machines they can deploy to?
<hatch> those are the constraints no?
<bac> hatch: done
<bac> hi benji, could you review https://code.launchpad.net/~bac/charmworld/bundle-page/+merge/180891 at your leisure?
<benji> bac: sure
<hatch> bac: you are correct in that you need to specify which jshint flag to turn off
<hatch> it's no longer a 'ignore all' type of flag
<hatch> I actually prefer this approach
<bac> hatch: no, i mean we went from /* jshint: foo=true */ to /* jshint -W99 */
<hatch> then it still checks for other errors
<bac> hatch: that's what i meant.
<hatch> validthis:true is just a 'everything is ok' flag
<hatch> whereas W99 (which I'll add docs for)
<hatch> only disables that one error
<bac> hatch: oh.  so you can just tell it to stfu for now.
<hatch> right
<bac> hatch: ok, i like the granularity but don't like the obscurity.
<hatch> yeah I agree I'll be adding the comments as to what error it gets around
<hatch> although js pro's should know by looking at the code ;)
<bac> perfecto
<hatch> maybe that's a good interview question lol
<hatch> "why do we need to tell jshint to ignore this"
<Makyo> jujugui call in 10
<Makyo> hatch, sorry, got distracted.  Constraints are fuzzy, not absolute.  If you say mem=2G, any machine with at least 2G matches.
<Makyo> hatch, and this isn't pulled in from EC2, we'd have to go through the machines we have.
<Makyo> hatch, Also, I was inexact.  Some constraints are fuzzy, some, like arch, are not.
<hatch> Makyo: I guess I'm confused how it works with input boxes because the user can really input whatever they want and I don't really know what happens afterwards
<hatch> maybe we chat after the call and you can get me up to speed?
<Makyo> hatch, sure.
<hatch> thanks
<Makyo> jujugui call in 2
<hatch> the websocket tests now save logs to the browser when running in make test-server :)
<hatch> jcsackett: wow huge diff ;)
<jcsackett> hatch: :-P
<hatch> I'm QA'ing in IE
<jcsackett> hatch: cool, thanks.
<jcsackett> Makyo: could i trouble you for the second review on https://codereview.appspot.com/12852045/ ? 
<Makyo> jcsackett, sure, on it
<jcsackett> thanks. :-)
<hatch> blarg Win 8 is going black again
<jcsackett> win8 is terrible.
<jcsackett> and i say this as a person who is not anti-windows per se. win8 is terrible.
<hatch> good news is that your branch appears to be fixed
<hatch> bad news is I found another bug :/
<hatch> jcsackett: next ticket? https://bugs.launchpad.net/juju-gui/+bug/1214058 :)
<_mup_> Bug #1214058: Cannot open Browse if sidebar is minimized  <charmbrowser> <juju-gui:New> <https://launchpad.net/bugs/1214058>
<jcsackett> hatch: sounds good to me.
<hatch> thank you very much :)
 * hatch is trying to get these bugs squashed early to make for an easy release
<bac> benji: i'm getting those json decode messages too.  i'll try it in trunk.  my branch should not have affected that area.
<bac> benji: jsondecode errors on trunk too.
<benji> bac: ok, "good" 
<benji> :)
<benji> we should really convert those to INFO or something similar
<benji> they look scary when they shouldn't
<bac> yeah, "good" in near-team
<bac> benji: those failures are getting 503 fetching the charm
<bac> benji: actually it is fetching the jenkins results.  jenkins is dead.
<bac> https://jenkins.qa.ubuntu.com/job/precise-ec2-charm-apache2-passenger/lastBuild/api/json
<benji> interesting; in that case a more descriptive error would seem to be in order
<bac> benji: we print an error message and proceed if the code == 404.  i'm going to change that to != 200
<benji> +1
<bac> benji: IS says they had a jenkins upgrade that went awry.  they are poking at it.
<benji> cool
<hatch> jujugui lf two reviews and a qa for https://codereview.appspot.com/12956045/ plz
<hatch> bueller.....bueller
<jcastro>  hey rick_h 
<hatch> jcastro: he is off today
<jcastro> ack
<hatch> anything i can help with?
<jcastro> https://bugs.launchpad.net/juju-gui/+bug/1214087
<_mup_> Bug #1214087: GUI fails to deploy keystone <juju-gui:New> <https://launchpad.net/bugs/1214087>
<jcastro> ran into this today
<jcastro> I _think_ this is the same issue we ran into during OSCON
<jcastro> where some config options break deployment
<hatch> ok so it deploys fine on the sandbox
<hatch> so will have to take a peek a little later deploying to ec2
<hatch> do you know what the error was?
<jcastro> but not in his MAAS
<jcastro> let me ask
<hatch> thanks - just want to get as much info as possible for when someone goes in to take a look
<bac> benji: would you do a quick review of my jenkins fixing one line branch?
<bac> benji: https://code.launchpad.net/~bac/charmworld/schmenkins/+merge/180930
<benji> bac: sure
<benji> bac: looks good
<bac> thx
<jcastro> hatch: added the log info to the bug report
<hatch> thanks!
<hatch> looking
<hatch> hehe
<hatch> paramter
<hatch> jcastro: thanks for doing the legwork on that
<Makyo> My elegant idea causes a memory leak in tests \o/
<hatch> best....fix....ever
<hatch> :P
<hatch> jujugui still looking for some reviews on https://codereview.appspot.com/12956045/
<bac> hatch: looking
<hatch> thanks bac
<benji> hatch: I'll take one.
<hatch> thanks to you too :)
<bac> hatch: done.
<hatch> thanks!
<hatch> looking
<bac> fearless canadians: http://www.piratejoes.ca
<hatch> lol!
 * hatch looks up trader joes
<hatch> it's a grocery store?
<hatch> Makyo: I'm also running into an IE10 bug where it ignores the Cascading part of CSS
<hatch> :/
<Makyo> Siiiigh.
<hatch> benji: would you be agaist hanging those constraints configs off of utils ?
<hatch> then they won't need to be mocked
<benji> hatch: sounds good to me
 * benji thinks (almost) to himself: "mock" doesn't sound like the right word for that...
<hatch> stub?
<hatch> "fragile code structure" ?
<hatch> ;)
<benji> :)
<hatch> I have two computers lboxing right now
<hatch> I think we need to speed that process up somehow :D
<hatch> jujugui looking for a quick review/qa in IE for this one (4line diff) https://codereview.appspot.com/13094044/
<huwshimi> Morning
 * bcsaller takes off for a bit but back tonight.
#juju-gui 2013-08-20
<hatch> hey huwshimi how are you doing?
<hatch> huwshimi: are you working on any of the gui stuff yesterday/today?
<huwshimi> hatch: Yep, getting some of this IE stuff done.
<hatch> oh ok cool, can you put your head on the cards so that we aren't duplicating work
<huwshimi> hatch: I had a question for you, let me see if I can remember
<hatch> sure, I'll be here all night
<huwshimi> hatch: Oh yeah, I haven't been able to reproduce bug #1213260
<_mup_> Bug #1213260: DDing a charm renders service icon under sidebar <ie10> <juju-gui:New> <https://launchpad.net/bugs/1213260>
<hatch> huwshimi: ok, umm does it render exactly where you drop it?
<hatch> or is it rendered slightly off?
<hatch> my laptop (which has IE10) has a low res screen
<huwshimi> hatch: It's been rendering fine for me this morning, but I just went to double check and my VM died again.
<hatch> crap, so what happens when it dies?
<hatch> just crashes?
<huwshimi> hatch: Yeah, this time it's complaining about having run out of disk space, but it has plenty
<huwshimi> hatch: Now can't boot into it
<hatch> :/ is there a 'free disk space' command?
<hatch> I know parallels has that and has to be run from time to time
<hatch> http://askubuntu.com/questions/219286/virtualbox-dynamic-disk-not-expanding-to-virtual-size
<hatch> possibly related?
<huwshimi> Oh it has actually run out of space, somehow it has taken up 12gb...
<huwshimi> Not sure how to free that up...
<hatch> huwshimi: maybe just increase the size of your vm
<huwshimi> hatch: I run it off a disk and the vm has used up all the space on that disk. I'm just temporarily deleting some vm files so that I can boot the vm, clean up and then restore...
<hatch> ohh
<huwshimi> hatch: It's a new thing every other day that goes wrong :)
<hatch> welcome to windows lol
<hatch> huwshimi: any luck?
<huwshimi> hatch: Not yet, it's repairing
<huwshimi> well, it was, no feedback at the moment
<hatch> oh boy - sounds like you might need to give it more space
<hatch> I think mine has 32gigs
<huwshimi> hatch: It has a few gb free at the moment
<hatch> maybe it's paging things because it doesnt' have enough ram
<huwshimi> hatch: It has heaps of ram
<huwshimi> hatch: It's works!
<huwshimi> Now to figure out what I can delete
<huwshimi> hatch: The service block always appears with the top left point under the mouse
<hatch> really...
<hatch> hmm on a fresh trunk checkout?
<huwshimi> hatch: Yes
<huwshimi> hatch: I haven't seen it do anything else
<hatch> pulling new trunk
<hatch> gota 'make' then I'll test
<hatch> ohh
<hatch> you gota drop it on the big square in the middle
<hatch> the thing below 'start adding charms'
<hatch> actually it doesn't matter where I drop it, it's always off
<huwshimi> hatch: Where does it up it?
<hatch> wha?
<huwshimi> hatch: put it?
<hatch> ~40px from the left of the canvas under the sidebar about mid screen
<hatch> I can demo it
<hatch> if you want to hop into a hangout
<hatch> I'm in guichat
<hatch> http://bazaar.launchpad.net/~juju-gui/juju-gui/trunk/view/head:/app/views/topology/service.js#L426 is the method which handles the drop and the positioning
<huwshimi> hatch: I'm not seeing that at all, on a fresh branch. Windows 8 IE10
<hatch> odd
<hatch> checking the code
<huwshimi> hatch: What's your screen res?
<hatch> 1366x768
<huwshimi> hatch: Even changing my browser size doesn't change it
<hatch> on this line http://bazaar.launchpad.net/~juju-gui/juju-gui/trunk/view/head:/app/views/topology/service.js#L443 put console.log(ghostAttributes.coordinates[index]);
<hatch> and let me know what the two numbers are
<huwshimi> hatch: Trying, but I think doing a disk cleanup and running IE were too much for the vm
<hatch> jeesh and I thought I had hardware issues :)
<huwshimi> hatch: 8 cores, 16gb ram is not the problem... 4gb ram and 4 cores are dedicated to the vm. Not sure why it runs so poorly.
<huwshimi> hatch: I'm going to finish getting this VM back to normal and then I'll get back to you about the drag and drop
<hatch> sure thing
<hatch> huwshimi: just FYI I'm running it in a vm with 3GB of ram and 1 core
<huwshimi> hatch: Virtualbox?
<hatch> yup
<hatch> V4.2.16
<huwshimi> I have .10
<huwshimi> (4.2.10
<huwshimi> )
<hatch> might be worth an upgrade
<huwshimi> hatch: Did you change settings for the VM?
<hatch> what do you mean?
<hatch> the hard drive is 25GB
<hatch> well what it thinks it's hard drive is
<huwshimi> hatch: There are lots of little checkboxes that do things, but I don't know if I need to change any of them...
<hatch> heh yeah there are
<hatch> I fiddled with it long enough when I first started with it I remember
<hatch> but I can't tell you what I changed and what was there
<hatch> I know I had to do some command line trickery to think it had a resolution higher than like 400x600
<hatch> or something crazy
<huwshimi> hatch: 137, 101. And it placed where I expected it to.
<hatch> huwshimi: interesting - I get only negative numbers
<hatch> in the am I'll have to try and get someone else to see if they can repro
<hatch> huwshimi: are you in the 'Desktop' version of IE? or the Metro version?
<huwshimi> hatch: Desktop
<hatch> well what the heck hah
<hatch> I suppose it's entirely possible mine is caching something wrong
<hatch> :/
<hatch> I think you're lie'n to me so you don't have to fix it lol
<huwshimi> heh
<huwshimi> hatch: It's possible it's broken, I just can't reproduce it here
<hatch> yeah but how's that possible haha
<hatch> both on trunk same version of ie
<huwshimi> hatch: Do you get the same thing in rev 940?
<hatch> huwshimi: let me check
<hatch> huwshimi: not exactly - that revno was before the fix for dropping the service on the center message
<hatch> they are positioned incorrectly still however
<hatch> I'm guessing it works correctly there?
<huwshimi> hatch: You changed some positioning stuff the revision after that so I was hoping it might have worked back then...
<hatch> yeah doesn't look like it - I'll get someone else to test it out, it could jsut be that mine is broken for whatever reason
<hatch> I'm going to take off but if you could push up/email me with whatever you get done so we can merge it in that would be awesome
<huwshimi> hatch: Sure. Night.
<frankban> bac, benji: when you have time, could you please review https://codereview.appspot.com/12927049 ?
<benji> sure
<rick_h> jcsackett: ping
<bac> frankban: sure.  hey sorry i didn't get to your review yesterday before your EOD
<frankban> bac: no problem and thanks
<frankban> benji: thank you
<rick_h> jcsackett: fyi, not sure where you are on the bug, but updated it with notes since I thought it might be my fault (though kind of an accidently worked thing) #1214058
<_mup_> Bug #1214058: Cannot open Browse if sidebar is minimized  <charmbrowser> <juju-gui:Triaged by jcsackett> <https://launchpad.net/bugs/1214058>
<rick_h> hatch: ping when you get in. Want to chat about where we left off last week if you've got the time. 
<frankban> bac, benji: thanks for your reviews!
<hatch> hey I gota run and take the car into the shop so I'll probably be back in 30-45 mins
<hatch> rick_h: I normalized the constraints stuff so you're free to go on the ghost constraints
<rick_h> hatch: k, will unblock the card then
<rick_h> hatch: thanks and have fun at the dealer
<hatch> lol dealer
<hatch> ppl take their cars to the dealer?
<hatch> :P
<rick_h> hatch: yea, under warranty and all :P
<jcsackett> rick_h: saw your notes, had come to the same conclusion yesterday, but thanks for the validation. :-)
<hatch> riiiiight, my cars are too old haha
<jcsackett> (not so much about what had happened, but about what was going on)
<hatch> ok gota run be back in a few
<rick_h> jcsackett: cool, wasn't sure where you were with it but I was curious as it seemed really strange any changes recently broke that :/
<jcsackett> rick_h: yeah, and the truth is it never really should have worked. :-P
<rick_h> jcsackett: right, that made more sense :)
<rick_h> in a ...strange...kind of way
<jcsackett> rick_h: i'm glad you updated me though. i could see what was wrong but my update at standup was def going to be "i have no idea why this ever worked".
<rick_h> jcsackett: sorry my z-index stuff borked a couple of other things on you
<rick_h> jcsackett: it's the one line 'fixes' that kill
 * jcsackett laughs
<jcsackett> you mean that floating sidebar icon thing?
<jcsackett> at least it was an easy fix too.
<rick_h> yea, as a drive IE fix I had to bump the z-index and then saw the bugs come out of it
<jcsackett> ...of course another one-line, so we'll see what that borks. :-P
<rick_h> but since it was a one-liner and I TRIVIAL'd it...WCPGR
<jcsackett> ...i have no idea what that last acronym means. :-P
<rick_h> jcsackett: that's SteveK's famous "What Could Possibly Go Wrong" /me misses that
<jcsackett> aaaah.
<jcsackett> yeah, we need to bring that back.
<hatch> back
<hatch> rick_h: on the weekend I installed cruise and a stereo into the mrs car and now it's off to get a new windshield - I typically do all of my own repairs but it's cheaper to have someone else install the windshield :)
<rick_h> hatch: defintely. special tool to pull the gasket around there and such
<rick_h> hatch: was blown away by how fast a pro could do it
<hatch> yep!
<hatch> so who has IE running?
<hatch> huw said he couldn't repro this bug https://bugs.launchpad.net/juju-gui/+bug/1213260 and was looking to see if it's fixed for anyone else too
<_mup_> Bug #1213260: DDing a charm renders service icon under sidebar <ie10> <juju-gui:New> <https://launchpad.net/bugs/1213260>
<rick_h> hatch: looking
<rick_h> hatch: yea, not doing it here
<rick_h> hatch: even if I just drop it 'right' past the edge of the sidebar, the left side of the service block is a few px east of the sidebar edge
<hatch> well I'm glad....but slightly irritated because that means there is something wrong with my IE :/
<rick_h> hatch: updating the bug with my screenshot of a tiny IE window working right. Re-open if you can dupe or find something. 
<hatch> rick_h: mind closing the ticket as cannot reproduce? Just so we have a record of it
<hatch> oh I can dupe the issue for sure
<hatch> but noone else can lol
<rick_h> hatch: well, marked it invalid with the notes about 'cannot reproduce' 
<hatch> oh right...that's how it works
<hatch> did anyone get an email from huw about what he was working on?
 * rick_h didn't see anything
<hatch> allllright then
<sinzui> jcsackett, 1x1?
<hatch> rick_h: so the constraints util method should all be gtg now, and all you need to do is create another wrapper around the constraints partial to loop through the fields
<rick_h> hatch: looking
<jcsackett> sinzui: yes.
<jcsackett> sinzui: i'm in the hangout attached to the appt
<hatch> rick_h: remember the performance discussion we had about etags and mobile? You should watch these talks it outlines the issues in detail in the first video https://plus.google.com/118445028821328031751/posts/hz2XpU76xzN
<rick_h> hatch: will put it on for lunch time viewing. thanks
<hatch> it has some really great information in it - there is like 3.5h of talks in the playlist hah
<hatch> Makyo: as far as core is concerned what happens if the constraints aren't specified?
<Makyo> hatch, Aren't specified?  As in, you send a set-constraints with no constraints, or as in you deploy without specifying?
<hatch> both I suppose - assuming the constraints object is empty
<hatch> right now there are no errors it appears?
<hatch> doe stha tmeans it picks the lowest possible?
<hatch> wow I can't type
<Makyo> hatch, Don't know off the top of my head, I'd assume it just allocates whatever size is specified in your ~/.juju/environments.yaml, which is a machine class, like tiny, small, etc.
<hatch> alright so with none specified in the gui a good name would be 'Default' ?
<Makyo> I'd make sure with luca.  That makes sense to me, but others might not know where that default is specified - I've been using Juju for a year, so I've got that advantage.
<hatch> good point
<hatch> luca: are you there?
<hatch> *poke poke*
<luca> Makyo: hatch heya
<hatch> when 'scaling up' the dialogue shows you the current constraints
<hatch> if none are specified....what shoudl be shown?
<luca> hatch: the defaults
<hatch> we can't get the defaults
<hatch> all the info we have is that there isn't anything specified
<Makyo> luca, if you deploy without constraints, it uses what's specified in your environments.yaml file, which we don't have access to.
<hatch> right now I have Default Ghz Default GB ..... etc
<luca> Makyo: hatch right. What do you think we should show?
<hatch> I like 'Default'
<hatch> although then people won't know what those are
<hatch> but it's kind of a chicken/egg issue there
<Makyo> I suppose I'd expect a 'use defaults from environment.yaml' checkbox that disables fields, maybe?  But yeah, I have experience with juju
<hatch> I'd say that could be in the 'set constraints' section
<hatch> but in the 'these are your current settings' section
<hatch> maybe we just have Default for now, and then when we add 'help bubbles' they can say where the defaults are set
<Makyo> Yeah, prowling through the machine and unit objects in the db from improv, we don't have any specs.
<Makyo> Don't know how meaningful improv is, not checking against core yet.
<hatch> jujugui lf two quick reviews and an IE QA on https://codereview.appspot.com/12987045/ plz
<Makyo> hatch, on it
<Makyo> Got the IE bit.
<rick_h> hatch: looking
<hatch> right arm!
<hatch> I needed to get these landed so that I can finish the upgrade ux heh
<hatch> darn IE
<rick_h> hatch: what do I need to do to see the original bug?
<hatch> scale up the units without editing the constraints so it'll say 'Default CPU Default GB ...
<hatch> if it doesn't wrap then you're good
<hatch> and as far as the X's  just focus an input, if there is no X in the post deployment inspector then you are good
<rick_h> hatch: ok, the bug states on 'inputs' and so I was checking on the config inputs
<hatch> yeah I left the X on ones which aren't databound
<rick_h> I didn't realize IE did the X clear on non type="search" inputs
<hatch> just incase IE ppl like that X for some reason...
<rick_h> and yea, the config ones are actually textareas so bad check
<hatch> shift + cmd + left is so much faster than trying to find the damn X with the mouse :)
<hatch> rick_h: did you want me to comment in the css why the part I removed is no longer required?
<hatch> I'm a little confused by the comment
<Makyo> jujugui call in 9, kanban now
<Makyo> hatch, want to run it today, then I'll get W/Th, you get F?
<hatch> sounds like a plan
 * hatch gets out the whip
 * hatch just pulling  alittle stewie there
<bac> benji: after the call a review of https://code.launchpad.net/~bac/charmworld/json-for-deployer/+merge/181087 ?
<benji> bac: sure
<luca> Makyo: hatch got called away, did you get a solution hehe?
<Makyo> luca, Don't have anything atm, was hatch's task.
<Makyo> jujugui call in 1
<Makyo> luca, will poke around more after the call.
<luca> Makyo: cool
<hatch> luca: I just ended up going with 'Default' instead of undefined when it's not specified
<luca> hatch: nice, ok
<hatch> luca: if you decide you want it changed in the future it's pretty easy to change
<benji> bac: your branch looks good.  I had a question though: do we need URLs without user names for promulgated bundles?
<rick_h> benji: yes, the jujugui charm is an example
<bac> benji: last week we discussed that and decided that the deployer will always want a versioned basket
<rick_h> err, ignore me
<bac> benji: that decision is open to be revisited but that's what i went o
<bac> n
<bac> benji: btw, this branch was very easy to do based on the nice stuff you added recently
<benji> bac: right, I think we always want a version, but don't we want to be able to say "I want the official big mysql cluster bundle, regargless of who is its current manager"?
<benji> I'm glad to hear I made the code a bit better.
<hatch> jujugui does anyone know the status/details of the card in Inspector 'Inspector does not work with core: cannot iterate over undefined WRT units' ?
<bcsaller> no, sorry, sounds like that one needs testing with a real core deployment
<hatch> yeah there is no ticket attached :/
<Makyo> I created it in a rush, sorry.
<Makyo> Will try again.
<Makyo> Just wasn't listing units.
<bac> benji:  yeah, perhaps.  sinzui do you have an argument against what benji says?
<hatch> Makyo: ohh, so that really needs to be fixed then before we unflag?
<Makyo> If it's still an issue.
<bac> benji: it'll be trivial to add...
<benji> yeah; if we aren't sure one way or the other we can land it as-is and add this later
<hatch> Makyo: if you have time today/tomorrow it would be awesome if you could test it out again :)
<Makyo> hatch, doing it now; need a juju environment up anyway.
<hatch> oh awesome thanks!
<hatch> I got my first SMS spam this morning at 5am - I have finally made it!
<Makyo> hatch, looks good, trashing the card.
<hatch> *phew* thanks for looking into that Makyo
<sinzui> bac: We do want to support  short url. the GUI will always use the full url. But from the command line, I might want to type just:fast-wordpress
<sinzui> bac, remember search will only return tip and reviewed bundles have a higher score,. The GUI will always suggest the user use the latest official charm.
<hatch> rick_h: I'm just going through the tickets and came across this one https://bugs.launchpad.net/juju-gui/+bug/1209016 I know you fixed it but it appears that the + sign doesnt turn orange on hover...is this a css or image issue?
<_mup_> Bug #1209016: Right hand zoom slider handles sprited improperly <juju-gui:Triaged by rharding> <https://launchpad.net/bugs/1209016>
<sinzui> bac: benji: do either of you have time to review https://code.launchpad.net/~sinzui/charmworld/api3-search/+merge/181092 ? I have an implementation question and am open to discuss net steps.
<adeuring> sinzui: could you have a look a this MP: https://code.launchpad.net/~adeuring/charmworld/1206659-simpler-es-mapping/+merge/181100 ?
 * sinzui looks
<rick_h> hatch: looking
<rick_h> hatch: looks like a JS issue. The hover class is added, but the sprite css doesn't change the icon. If you hard edit the css the image will show
<rick_h> hatch: so rather than adding a css class it needs to add and remove 
<hatch> right looks like the old class is still taking precident
<hatch> I'll make a card for this ticket
<rick_h> hatch: comment added with the details https://bugs.launchpad.net/juju-gui/+bug/1209016/comments/1
<_mup_> Bug #1209016: Right hand zoom slider handles sprited improperly <juju-gui:Triaged by rharding> <https://launchpad.net/bugs/1209016>
<hatch> cool thanks
<rick_h> jcsackett: did you need a second pair of eyes on the event stuff?
<rick_h> jujugui I'm having a hard time concentrating through the meds. Going afk. 
<Makyo> Alright, good luck
<sinzui> adeuring, r=me with comments
<adeuring> sinzui: thanks!
<adeuring> sinzui: Making the two lists "constants" is fine, but I don't understand your suggestion to add an XXX: Do you mean line 230 of the diff? I don't think that an XXX is needed there
<sinzui> adeuring, okay. I wont press you to make the change.
<sinzui> jujugui. Note that https://jenkins.qa.ubuntu.com/ is not responding. So charmworld is not collecting charm test results at the moment.
<hazmat> hmm
<hazmat> sinzui, raising to webops
<bac> hazmat, sinzui: i got booted off-line.  m_3 and i raised the jenkins issue on #is yesterday
<m_3> bac: they're still working it too it looks like
<sinzui> thank you bac
<bac> m_3, even more dead than yesterday
<bac> benji: thanks for the review.  i'm going to land it now and do the promulgated as another branch
<benji> cool
<bac> sinzui, benji: do we think this is the URL to get JSON for the deployer use for promulgated branches:  http://manage.jujucharms.com/bundles/mysql/tiny/json
<benji> bac: I /think/ so.  I don't remember exactly.
<bac> benji: i've added it to the doc and will proceed.  having an optional version right in the middle is not pretty
<benji> mmm
<bac> or maybe the version is only there if there is an owner
<sinzui> bac, I think so. There is no version and no owner in it
<sinzui> bac: I shared "Deploying Charmworld and Juju-GUI to Prodstack" with jujugui and orangesquad so that everyone knows the fastest way to get things deployed
<bac> sinzui: yay
<bac> sinzui: i have given it a gold star so i'll always have it with me.
<hatch> rick_h: back yet?
<rick_h> hatch: what's up?
<hatch> rick_h: oops sorry didn't see you replied
<hatch> I'm going to be changing the template that the constraints use a little
<rick_h> hatch: rgr
<hatch> feelin better?
<rick_h> hatch: little bit, took a half day sick and a nap
<rick_h> now nap-groggy, but wheeeee
<jcsackett> hey hatch, since updating your jshint i'm getting complaints about the 2 line indents on all files. any idea what i need to change?
<hatch> jcsackett: you merged trunk?
<jcsackett> that's how i got your jshint update.
<jcsackett> should there no longer be 2 space indents?
 * jcsackett goes to see if there's more trunk to merge
<hatch> hmm well no there should be
<hatch> guichat real quick?
<jcsackett> hatch: sure, one sec.
<sinzui> bac, do you have time to give me some feedback on https://code.launchpad.net/~sinzui/charmworld/api3-search/+merge/181092
<bac> sinzui: sure
<Makyo> jujugui (hatch, bcsaller?) - the saveAs noop is what's causing the memory leak for me in the websocket_logging tests.  Am I behind on a version or something?  Have clean-all'
<Makyo> Have run clean-all etc.
<bcsaller> afaik that code hasn't been touched in quite some time, this is the export saveAs you're referencing?
<Makyo> It's just the line "saveAs = function() {};", I think.  In the browser, as hatch  says, I get a save as dialog, but Phantom just dies, then I get a message that it's used all available system memory.
<hatch> oh THAT's why phantom always dies for me now
<jcsackett> hatch: threw node_modules/jshint/bin into my path and now all is well.
<hatch> jcsackett: awesome :)
<hatch> Makyo: looking at the test
<Makyo> hatch, it
<Makyo> It's test/test_websocket_logging.js:59
<Makyo> That test.
<hatch> oh em gee who wrote FileSaver.js
<hatch> lol
<bcsaller> FileSaver.js is a polyfill we pulled in
<bac> sinzui: are you asking for a full review?  or a mid-imp discussion?
<hatch> bcsaller: yeah I know, :)
<hatch> Makyo: what if you change those to websocketLogging.prototype.saveLog = ... ?
<sinzui> bac. I hope the former, but the later is not unreasonable since I think the metadata issue should be solved in this branch
<jcsackett> jujugui: can i get two reviews for https://codereview.appspot.com/13092044
<hatch> on it
<jcsackett> thanks, hatch.
<Makyo> No luck, hatch 
<hatch> darn - ok I'll have to look into the memory profile in a few
<Makyo> Will poke around too
<rick_h> jcsackett: reviewing
<rick_h> jcsackett: sanity check on the test method there please. 
<rick_h> jcsackett: but other than that ok. Heading out. 
<rick_h> grrr, reviewboard is timing out 
<hatch> Makyo: hmm I can't reproduce the memory leak in the browser
<hatch> does it happen in the browser for you too or just in phantom?
<Makyo> hatch, just phantom, the browser shows the save dialog.
<hatch> ok I don't get any save dialogue
<hatch> and I shouldn't because the saveLog method was monkeypatched
<bac> sinzui: is the metadata currently used?  i think your suggestion is a good one.
<hatch> it.only('responds to the saveWebsocketLog event', function(done) {
<Makyo> hatch, the memory bug seems to be a phantom thing, closing uncleanly because of a crash with the file saving.
<hatch> that's the proper test right?
<Makyo> That appears to be it.
<hatch> ok trying phantom
<jcsackett> rick_h: ack. 
<hatch> no issues
<hatch> Makyo: maybe I need your branch
<Makyo> That's why I was wondering about versions. 
<hatch> ok well trunk as far as this morning was A O K
<hatch> if you push up your branch I can take a look
<sinzui> bac: it is not used for bundles. Aaron and rick introduced it to charms to describe things we add to the charm, like related_charms. I think adding to metadata is keeping with the grand plan, but you or benji might know of changes to the plan while I was in IoM
<Makyo> hatch, I haven't touched that test, nor anything that test touches.  I'm currently checking trunk, so give me a sec.  if it is my branch, I'll push it and send it your way.
<hatch> alrighty
<bac> sinzui: i don't know anything about it.  it looks good to me.
<hatch> maybe it's just in your head ;)
 * hatch waves his hand "this is not the test you are looking for"
<Makyo> Nnnnnnno.
<Makyo> hatch, dies in trunk, too.
<hatch> hmm
<hatch> that's very odd
<hatch> phantomjs --version ?
<hatch> I'm showing 1.9.1
<sinzui> Okay. then I will add doctype to meta data to charm and bundle in API3. bac I intended to look at the index_client.api_search() I discovered. Do you agree? Or should I work on the interesting endpoint?
<hatch> Makyo: the thing that's intersting is that you said you get a save dialog - I do not...
<Makyo> 1.8.0 - let me try updating.
<hatch> yeah that version is pretty old
<hatch> Dec 2012
 * hatch crosses fingers
<bac> sinzui: api_search
<Makyo> That's what I was thinking, s'why I asked.  Hope it works!
<sinzui> bac, thank you for the direction.
 * sinzui cleans up metadata rules
<Makyo> hatch, It crashes faster this time :)
<hatch> lol
<hatch> and it works perfectly fine here...
<hatch> 11MB of ram usage
<Makyo> Fffff.
<Makyo> It's no longer memory-leaking, thankfully.
<Makyo> Just crashing.
<hatch> ohh ok
<hatch> phantomjs always crashes on me for no reason
<hatch> I just restart the test
<hatch> but with the .only on that test it's fast
<hatch> and no crashy
<hatch> running the .only on the describe
<hatch> ahah!
 * hatch made it crash
<hatch> it's actually crashing in it('can save a log', function() {
<hatch> because saveAs isn't actually a global
<hatch>  ReferenceError: Can't find variable: saveAs
<hatch> see it's defined on line 24 of test_websotkcet
<hatch> or whatever my fingers meant to type
<hatch> holy crap this FileSaver.js file is hard to read
<hatch> Makyo: https://gist.github.com/hatched/919583b63f7d9c336c0d
<hatch> fixed
<Makyo> hatch, oh!
<Makyo> Linter runs on tests, are we okay with removing 'use strict'?
<hatch> probably not
<hatch> :)
<hatch> Makyo: var saveAs = saveAs; outside of the closure with a flag to tell jshint it's OK
<hatch>  /* jshint: -W079*/ for example
<hatch> I'm actually wondering how the heck that EVER ran
<hatch> lol
<hatch> Makyo: did that work for you as well?
<Makyo> hatch, started raining and I was hang-drying stuff outside.  Let me try.
<hatch> shoot I gota run pick the car up from the glass place before they close
<hatch> will bbiab
<Makyo> \o/
<Makyo> Thanks hatch 
<hatch> w00t w00t!
<hatch> no problem :)
<hatch> back
 * bac dogwalk
<Makyo> bac, http://imgur.com/gallery/DLXSjcS
<huwshimi> Morning
<bac> hi huwshimi
<huwshimi> bac: Hey
<bac> huwshimi: i'm working on charmworld.  and we've got some pages that needs some styling love.  any chance you'd be able to look at them?
<huwshimi> bac: Sure, what needs to be done?
<bac> huwshimi: i just created a page to display the info for bundles and just laid it out as tables.  so, it could be re-arranged to be more pleasant.  and the charm display page is ugly with overlapping text: http://manage.jujucharms.com/charms/precise/etherpad-lite
<bac> huwshimi: if you can look i'll send you an email tomorrow with details.
<huwshimi> bac: Sure, that's fine. Let me know!
<bac> huwshimi: the bundle page is at http://staging.jujucharms.com/~abentley/bundles/wiki-bundle/wiki
<bac> huwshimi: have you ever worked on charmworld before?  if not i'll embellish my email with how to get up and running.  it is a pretty simple process.
<huwshimi> bac: I have done, but it was last year I think, so might be worth putting in some instructions just in case :)
<bac> will do.  thanks for the help!
<huwshimi> bac: No problems.
<bac> huwshimi: email sent.  it is pretty minimal but i think its enough.  let me know if you need more detail.
<huwshimi> bac: Thanks, that looks fine for me to get started/
#juju-gui 2013-08-21
<hatch> huwshimi: hey in your proposal for the ie scrollbar you changed the height to auto
<hatch> that won't work with the animation
<huwshimi> hatch: Oh, let me take a look
<hatch> if you want to do that you will have to use the max-height trick
<huwshimi> hatch: Actually, I fixed the issue that required the height to be auto anyway
<hatch> oh haha ok then!
<huwshimi> hatch: The buttons were cut off in Firefox, but the other spacing stuff I did fixed that.
<huwshimi> (I originally fixed it by setting the height to auto
<huwshimi> )
<huwshimi> hatch: I'll push up the revert
<hatch> cool, I'll review/qa once that lands
<hatch> other than that how has your day been?
<huwshimi> hatch: Going a lot better than yesterday :)
<hatch> haha fixed the VM?
<huwshimi> hatch: Yeah finally, but it look like it'll expire tonight which means setting it up again tomorrow.
<huwshimi> hatch: Are there any more IE10 issues you'd like me to take a look at?
<hatch> that's actually all of them that I know of
<hatch> maybe do a once over to see if you can catch any?
<huwshimi> hatch: Sure.
<huwshimi> hatch: Change has landed
<hatch> awesome thanks
<rick_h> jcsackett: did you figure out hte indent thing from yesterday?
<frankban> morning bac and benji: when you have time, there is anothe guiserver branch ready to review: https://codereview.appspot.com/13153043 Could you please take a look?
<bac> frankban: i'll be glad to in a little while.
<frankban> bac: thanks, no rush
 * benji sips his coffee and looks at frankban's branch.
<frankban> thank you
<jcsackett> rick_h: yeah, i was using a different jshint binary for syntastic than our project.
<jcsackett> so i just switched which jshint is on the path in my LXC.
<rick_h> jcsackett: ah, yea I'm doing the same thing but it was working so :/
<jcsackett> jujugui: can someone point me at a design doc that shows how the search bar should exist when the charmbrowser is completely minimized?
<rick_h> jcsackett: sec, looking
<rick_h> jcsackett: http://dl.dropboxusercontent.com/u/10004366/juju-gui/index.html is the idea from a demo I was looking at for animations
<jcsackett> rick_h: huh. we have two separate cards for "search on canvas" and "keep search bar available", but this makes it look like that sort of needs to be done as one thing.
<jcsackett> since there's no option for "search for charms in browser while minimized".
<rick_h> jcsackett: well, my understanding is the idea that the search box is always visible. And if you use it while minimized, you end up in /sidebar/search
<rick_h> e.g. it un-minimizes to show results
<jcsackett> rick_h: except that animation shows "Search in canvas" when we minimize.
<jcsackett> ...not even really sure why, though i guess that's vaguely useful when you have an environ with a lot of charms.
<rick_h> jcsackett: oh right, yea that's a second feature
<rick_h> to be able to search and load things from the environment
<rick_h> it kind of goes with versioned charms though so that we can load the data for the version deployed? I'm not sure if we want that incrementally or what
<jcsackett> rick_h: but we do want to be able to search for things in the browser from minimized, and just load the sidebar when we have results?
<rick_h> luca...who's afk would know 
<jcsackett> rick_h: ah. well ok then. :-P
<rick_h> jcsackett: so I'd start with removing categories from the two viewmodes. then removing filters/updating the results output/charm containers, before going to the search deployed charms or search bar
<rick_h> as the 'how search works/is displayed' will be effected in all cases
<jcsackett> rick_h: works for me.
<jcsackett> rick_h: we're just removing the filter widget from those views, right? and any other bits of interacting code. filters themselves stay for AC.
<rick_h> so we're removing the filter UI, and we're not checking for approved results by default. Then we're changing how the search results are displayed. First reviewd in a container and then the rest in another container
<rick_h> jcsackett: sec, there's a good bug to look at
<jcsackett> rick_h: ok.
<rick_h> jcsackett: https://bugs.launchpad.net/juju-gui/+bug/1202306 though I thought abentley had a post in there that had notes. 
<_mup_> Bug #1202306: We need an "all" category <juju-gui:Triaged by lucapaulina> <https://launchpad.net/bugs/1202306>
<rick_h> jcsackett: of course the end of that is waiting on UX. 
<rick_h> jcsackett: but the work still stands to remove the filters, group the results in two sets/containers
<jcsackett> rick_h: right, so i'll start a branch that kills the filter widget from the views.
<rick_h> jcsackett: k, but the display has to go along with it so that we can use the results. 
<rick_h> because as soon as we remove the default filters the results go to crap
<jcsackett> rick_h: i'm not sure i'm following. this bug conversation is all over the place, and i'm only sort of following how it links to what you and i are talking about.
 * jcsackett may be having problems because he's not fully awake yet.
<rick_h> jcsackett: k, hangout?
<jcsackett> rick_h: sure, one sec.
<jcsackett> rick_h: hangouts seem to be not so good?
<jcsackett> i'm disconnecting b/c i'm getting truly horrid static.
<rick_h> jcsackett: died on me, one try
<rick_h> jcsackett: one more try 
<rick_h> luca: ping, do we have any UX updates on the search UI including the "all" category notes
<rick_h> jcsackett: oh, and did my test concern pan out? Or is it working peachy the way it is?
<rick_h> jcsackett: because that's more of a 'before this first branch lands' concern
<jcsackett> rick_h: i put in the dones, and everything still passes.
<jcsackett> so we're good.
<rick_h> jcsackett: ok cool. Yea they should pass, just wanted to make sure the asserts were getting hit
 * jcsackett nods
<rick_h> thanks
<jcsackett> yeah, that was a good catch.
<rick_h> I did that before where they passed, but never asserted :/
<jcsackett> rick_h: i suspect we have several tests like that.
<rick_h> jcsackett: so for the record, I just had to update my local jshint as well. Guessing there was some .jshintrc config differences between what I had installed vs the updated one from the repo
<rick_h> hatch: let me know when you get a sec. Want to talk this through. 
<hatch> sure umm lemme grab a coffee first
<rick_h> hatch: definitely, going to need your head unclogged :)
<bac> benji: i'm seeing failures in charmworld trunk.  can you pull trunk and run 'make test' and see if you get them?
<benji> bac: sure, one sec
<hatch> rick_h: guichat?
<rick_h> hatch: sure
<sinzui> bac: do you have a few minutes to talk about the fix for https://bugs.launchpad.net/charmworld/+bug/1214627
<_mup_> Bug #1214627: AttributeError when searching for "precise" <elasticsearch> <oops> <charmworld:Triaged> <https://launchpad.net/bugs/1214627>
<bac> sinzui: yes
<sinzui> bac, guichat is available
<benji> bac: I forgot about my test run until now; everything passed.
<bac> benji: ok.  i did a make clean, removing crusty old pyc files and the one problem test passed in isolation.  running them all again
<hatch> I see the order of the Featured charms have changed :)
<Makyo> jujugui reviews pleeeaase. https://codereview.appspot.com/12744049/
<rick_h> Makyo: looking
<Makyo> rick_h, thanks.
<hatch> Makyo: sure I'll take one
<hatch> hey luca could you check out https://comingsoon.jujucharms.com/:flags:/serviceInspector to make sure the inspector passes UX?
<Makyo> jujugui call in 10
<Makyo> kanban now.
<luca> hatch: sure, but won't have time to do it today, is it ok if I do it tomorrow morning (my time)?
<hatch> you bet
<hatch> do you have IE?
<luca> hatch: internet explorer?
<hatch> yeah
<luca> hatch: I don't, do I need it?
<hatch> guess not - we'll just make sure it looks the same in IE as it does in Chrome/FF
<rick_h> Makyo: got time after the call to hang on the call and chat about the MP?
<luca> hatch: ok
<sinzui> bac, .short_url -> .basket_name -> .basket.split() fails because .basket is None. There is a invalid charm in the system without a name, owner, or basket.
<Makyo> rick_h, sure.
<hatch> luca: thanks, any issues plz email - I want to get it unflagged by the end of the week
<bac> sinzui: ahhhh.  so can you delete that bundle?
<bac> and provide some defense?
<sinzui> bac. I can. I am preparing a query to see if the bad data is also in production
<bac> sinzui: i suspect it is
<Makyo> jujugui call in 1.
<sinzui> bac, The error cannot happen in production because the early ingest error was never in production. I will fix the class, prove it works on staging, then delete the bad bundle from the staging db
<bac> sinzui: great
<bac> hi adeuring, as i mentioned i'm seeing spurious failures unrelated (famous last words) to the work i'm doing.  they are all tests you added recently in r357.  could you have a look at http://paste.ubuntu.com/6010830/
<adeuring> bac: sure
<adeuring> bac: where can I find your branch?
<bac> adeuring: lp:charmworld/official-bundle-json
<bac> adeuring: lp:~bac/charmworld/official-bundle-json
<adeuring> thanks
<bac> second is correct
 * bac grabs lunch
<bac> adeuring: how long until your eod?
<adeuring> bac: officially, 30 minutes or so
<bac> adeuring: ok,ping me if you have any ideas.  thanks.
<hatch> Makyo: so how does your branch signify to the user that the charm can be upgraded?
<hatch> I'm on rapi with serviceInspector and upgradeCharm
<Makyo> hatch, that's the next branch.  This branch's whole point is to check for available upgrades.
<hatch> gotcha
<hatch> lgtm qa ok
<hatch> jujugui CI is down
<hatch> unable to deploy charm
<hatch> were there any changes made to the charm yesterday?
<rick_h> hatch: https://code.launchpad.net/~juju-gui/charms/precise/juju-gui/trunk landed today it looks like
<hatch> it had failed when huw landed his branch early this morning
<hatch> ahh crap, gota run for a few
<rick_h> hatch: ok, well #93 landed yesterday
<hatch> I'll look into it when i get back
<rick_h> #92 as well
<benji> BradCrittenden: do you know if we have any actual bundles in the production DB?
<frankban> hatch: yes, but only the guiserver bits, and the error seems unrelated (KeyError: 'instance-state' when trying to parse juju status, wird)
<frankban> weird even
<BradCrittenden> benji: i do not.  sinzui might as he just looked into it
<sinzui> benji, yes I do know.
<benji> sinzui: are there any bundles in the production db?
<sinzui> benji, bac, There is exactly one. Most likely the abentley won we are testing
<benji> darn
<bac> sinzui: that would've been my guess
<sinzui> benji, staging has 2, one is bogus and I will remove it after I have a fix in place for a bug
<benji> I guess I'll have to write a migration script then
<sinzui> benji, do you want to remove the production one?
<benji> it would be nice :)
<sinzui> benji, you could just remove() the one bundle, If you are updating the structure you could just make sure you are compatible during the period it is not reingested
<benji> hmm, yeah I think just removing all bundle data from ES and waiting for a re-ingest is the way to go; thanks
<adeuring> bac: I can't reproduce these failures :(
<bac> adeuring: thanks for looking.  very odd.
<bac> adeuring: are you working within an LXC?
<adeuring> bac: no, do you?
<bac> adeuring: no.  but i have seen spurious test failures in the past linked to using a "real" environment vs an lxc.  those were timezone based, though.
<adeuring> bac: another odditiy: you started with trunk r358 -- and that revision already contains most of my recent work...
<bac> adeuring: well, i didn't run the full suite until recently
<adeuring> ah, ok
<bac> adeuring: anyway, have a good evening.  thanks for your help.
<adeuring> bac: thanks. I'll look a bit more tomoroorw morning
<bac> adeuring: ok.  i'll email you if i solve it
<adeuring> bac: cool, thanks
<hatch> totally just cut my finger open on a PowerAde bottle.....awesome!
<hatch> does anyone know the euca command to destroy an instance?
<hatch> ^ jujugui
<hatch> oh terminate-instances
<hatch> ok another build kicked off
<hatch> looked like it couldn't start up the new instance
<hatch> will see what happens now
<hatch> bcsaller: is there any way to QA your branch?
<sinzui> bac, benji: do either of you have time to review https://code.launchpad.net/~sinzui/charmworld/basket-name-none/+merge/181362
<benji> sinzui: I can take it.
<bcsaller> hatch: you can drag test/data/blog.yaml onto the canvas
<hatch> ok and if no errors and the services are there then it's a o k ?
<rick_h> hatch: guichat when you get a sec please?
<hatch> bcsaller: I think there were some things changed in your branch which will effect Makyo's re the charm promise
<hatch> rick_h: omw
<bcsaller> hatch: that is a wrapper around the normal call, that shouldn't be a problem. The id normalization could impact something else but shouldn't 
<bcsaller> hatch: yes, it should work, services and relations from the deployer file as you'd expect.
<bcsaller> hmmm... though actually that won't work in the extracted version for the reason listed in the mp, ugh
<bcsaller> when a deployer file includes more than one target we'd need a disambiguation UI which isn't there 
<bcsaller> so w/o a change, no, it won't import, it will throw the error saying more than one possible target
<bcsaller> a deployer with one target will work though, an export for example
<hatch> ok so....stop reviewing and qaing?
<bcsaller> or just export something and re-import it
<bcsaller> that didn't work before
<bcsaller> when we unsynced the format
<hatch> lol
 * hatch is glad he isn't doing this
<rick_h> Makyo: if I wanted to confirm that the python environment .deploy() method would allow setting constraints in the 3rd argument (config) where would I look for the websocket docs/code? I see the send_rpc call, but want to keep following the code to determine what's valid for that config param for the 'deploy' call?
<rick_h> yay jenkins has been appeased!
<Makyo> rick_h, app/store/env/python.js:257 - Not seeing constraints :/
<rick_h> Makyo: right, hatch thought perhaps the 'config' could container constraints
<rick_h> but the code doesn't read like it
<rick_h> Makyo: so I was going to go looking at the 'thing' that this ends up calling but not sure where to head from here. juju-core source?
<hatch> jujugui I got CI back up, canonistack was holding on to an errored machine and wouldn't terminate it
<rick_h> Makyo: I don't see any tests that work like that either, but the tests are specific
<benji> cool
<Makyo> rick_h, Yeah, I'm not seeing it in fakebackend, either.  It just uses an empty constraints object.
<bcsaller> thats so classic canonistack, love that guy
<rick_h> Makyo: the goal is to deploy a charm from the ghost inspector with charm config + constraints. Seems like it *should* be possible but trying to find the right way to build that
<Makyo> rick_h, looking in core real quick.
<rick_h> thanks Makyo 
<hatch> bcsaller: lol
 * rick_h is looking at core for the first time ever...duh duh duh
<hatch> we have to be able to deploy a service with constraints :( That seems like such an oversight if it's missing
<rick_h> hatch: yea, in following the code there now it's not tested or something I am seeing. 
<Makyo> rick_h, In core (haven't checked pyjuju), ServiceDeploy's params takes a Constraints argument: http://bazaar.launchpad.net/~go-bot/juju-core/trunk/view/head:/state/api/params/params.go#L58
<rick_h> Makyo: ah, thank you sir!
<Makyo> rick_h, The constraints.Value shooould be a dict with very specific keys.
<Makyo> Will look.
<rick_h> Makyo: cool, yea I was looking at DeployServiceParams in conn.go which seems similiar, but not quite it
<Makyo> rick_h, http://bazaar.launchpad.net/~go-bot/juju-core/trunk/view/head:/constraints/constraints.go#L19
<Makyo> rick_h, I hope this hasn't changed and I'm not leading you down the wrong path.
<rick_h> Makyo: ok, so looks like a little more work to do to get this able to work. 
<rick_h> Makyo: cool, thanks. This helps a bunch and gives me something work towards. 
<Makyo> rick_h, Yeah.  Want me to check pyjuju too?  Just got back from lunch, so I'm not on anything quite yet.
<rick_h> Makyo: sure, I want to peek as well to understand how this stuff fits
<rick_h> but appreciate a sanity check
<Makyo> rick_h, http://bazaar.launchpad.net/~hazmat/juju/rapi-rollup/view/head:/juju/rapi/cmd/deploy.py#L15 has a constraints_strs
<Makyo> I'm not quite sure how that works, but it does look like it's there.
<rick_h> Makyo: so for the config, the Go is caps, the python is not?
<rick_h> Makyo: yea, was looking at the constraints.py file 
<rick_h> Makyo: actually guichat for a sec? Maybe easier?
<Makyo> rick_h, Correct; that should be taken care of in app/store/env/{python,go}.js, so the calls remain the same, as does the data passed to the callbacks.
<Makyo> rick_h, sure, be right there.
<hazmat> Makyo, its mem=4 cpu=2 instance-type=m1.medium
<Makyo> hazmat, cool, thanks.  rick_h ^^^
<hazmat> Makyo, w/ juju-core s/cpu/cpu-cores and instance-type doesn't exist
<hazmat> er.. mem=4G
<benji> sinzui/bac: can I get a review of https://code.launchpad.net/~benji/charmworld/bundle-heads/+merge/181385 ?
 * sinzui looks
<hatch> jujugui is there a way to get the env calls to follow their callbacks in tests?
<hatch> the overview constraints page needs to send the new constraints, wait for it to return, then send it's new unit number
<bcsaller> wrap it in a promise
<hatch> but the callback is never being called in the tests
<hatch> ehh, that's a lot of overhead just to make it pass the tests :)
<bcsaller> and you're sure it not failing before that? or you think nothing is responding?
<hatch> well the env constraints call is being made
<hatch> but the callback isn't getting called
<bcsaller> hatch: I can look at it with you but offhand I don't know what to tell you
<hatch> guichat real quick?
<sinzui> benji, I replied with a question of sorts.
<benji> cool, looking
<benji> sinzui: I am inclined to say that bad bundles (or more correctly, bad baskets) are not ingested at all, that way we don't have to have a bunch of defensive code against bad data.  How does that sound?
<sinzui> benji, how do we communicate to the basket author that their basket is invalid?
<sinzui> we have a report for charms. you cannot search for them, but the report shows what we know about them
<sinzui> benji, but in general I am fine to not save insane bundles for the moment.
 * sinzui is writing an incantation to get the insane one out of staging ES right now
<benji> ah, good point.  In that case I would save the basket data but none of the bundles.  That way we can show a bad basket but none of the bundles will foul anything up.
<benji> we'll still have to be defensive against bad baskets, but that is a smaller battle front to defent
<benji> sinzui: how about that? ^^^
<sinzui> benji, works for me. r=me. I'll let you work out the graceful exit from the situation
<benji> sinzui: "graceful exit"?
<sinzui> benji, adding the defensive guards for bad baskets
<benji> ah, gotcha
<sinzui> There won't be any in a few minutes I hope
<hatch> bcsaller: is there an example in a current test about setting up the env with the real fakebackend?
<hatch> I can't seem to find one
<bcsaller> hatch: test_sandbox_python and look for integration, I think that does what you want
<hatch> ahh got it thx
<bcsaller> Then I think you pass that sort of a setup as env
<hatch> oh jeeze I need to load up a fakestore too
<hatch> bcsaller: ok so now that i Have it all set up and are monkeypatching onmessage I still only get a single call
<hatch> I'm guessing onmessage needs to return something?
<benji> I really wish the testrunner didn't make me work to hard to craft the description of the subset of tests I want to run.  I bet there is a plug-in somewhere that I'd like.
<bcsaller> hatch: when you're env is using the sandbox connected to a fakebackend it should work
<bcsaller> benji: nested describe blocks?
<bcsaller> I use those to collect tests
<hatch> bcsaller: got a second for a guichat?
<benji> bcsaller: this is the nose python test runner; it's not so bad, but it wants filename:classname.methodname.  I'd prefer to just do methodname and let it figure out the rest
<bcsaller> benji: ahh, different test runner, I've used tags for that with nose iirc, there is a plugin for that 
<bcsaller> hatch: missed you I guess
<hatch> going to grab some lunch
<bac> sinzui: i've narrowed the problem to a small set of tests as seen at https://code.launchpad.net/~bac/charmworld/spurious-test-failures/+merge/181418
 * sinzui looks
<bac> i've listed abel as a reviewer so perhaps he can figure something out tomorrow
<bac> if not i'll land it so i can proceed with my work
 * bac walks unusually patient dog
<huwshimi> Morning
<Makyo> So this stuff is pretty good: https://twitter.com/bzr_pull_makyo/status/370264178293886977/photo/1  Nicely gingery without being too weird for a beer.
<Makyo> Plus, it's called Good Juju.
#juju-gui 2013-08-22
<bcsaller> Makyo: I had that shortly after the name changed from ensemble. Before that we just had to drink many beers to make an ensemble.
<huwshimi> bac: If you are around I have some questions about charmworld
<rick_h> huwshimi: what's up, might be able to offer tip if needed as well. 
<huwshimi> rick_h: Just wondering about setup. Did you set up with LXC or local?
<rick_h> huwshimi: definitely lxc. Needs things like mongo and don't want to always run it
<huwshimi> rick_h: Ah ok. Which instructions should I use for getting that set up then. The hacking doc assumes you're already in an LXC container and I couldn't see anything in https://juju.ubuntu.com/docs/ about getting and LXC container set up....
<rick_h> huwshimi: yea, sorry, assumes the lxc is good to go. It's normally just sudo lxc-create -t ubuntu -n charmworld -- -b $your_username
<rick_h> and then you'll hit needing to install the python-software-properties package to get the add ppa command to work
<huwshimi> rick_h: "lxc-create: failed to execute template 'ubuntu'"
<rick_h> https://help.ubuntu.com/12.04/serverguide/lxc.html has some helpful
<rick_h> huwshimi: ls /usr/share/lxc/templates ?
<huwshimi> rick_h: There is a "lxc-ubuntu" in there
<rick_h> huwshimi: hmm, then should work :/ 
<rick_h> huwshimi: quick google shows https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1166841 ?
<_mup_> Bug #1166841: lxc-create fails if LANG is not valid <lxc (Ubuntu):Triaged> <https://launchpad.net/bugs/1166841>
<huwshimi> rick_h: Well, that doesn't look fun...
<rick_h> huwshimi: heh...so um...
<huwshimi> rick_h: I'll ask other australians if they have the issue...
<huwshimi> rick_h: I think it's working now. Should the LXC creation take ages?
<rick_h> huwshimi: the first time yes
<huwshimi> rick_h: "juju generate-config -w" is correct for setting up Juju the first time?
<huwshimi> "juju: error: invalid choice: 'generate-config'"
 * rick_h doesn't recall running that
<rick_h> huwshimi: oh, don't you need the new tools to do that?
<rick_h> huwshimi: ping in #juju, I've not used that before
<huwshimi> rick_h: I don't know, I'm just trying to follow the docs
<huwshimi> rick_h: It used to be juju init, but that doesn't exist either
<rick_h> huwshimi: the hacking docs? You shouldn't need a juju config for dev'ing it
<huwshimi> rick_h: Well, I tried without any setup and it complains about not having an AWS key
<rick_h> huwshimi: you want http://bazaar.launchpad.net/~juju-jitsu/charmworld/trunk/view/head:/docs/hacking.rst#L96
<rick_h> huwshimi: in your lxc just create a dir for hte code, bzr branch lp:charmworld && cd charmworld && make sysdeps && make install
<huwshimi> rick_h: Oh, so do the local setup instruction inside the LXC?
<huwshimi> not the hacking with lxc instructions?
<rick_h> huwshimi: right
<rick_h> huwshimi: the other ones is more for working with the charm and such
<huwshimi> rick_h: Ah
<rick_h> huwshimi: you just want to run the code/hack on it locally
<huwshimi> rick_h: yeah
<huwshimi> rick_h: There is a lot of setup to do in the container just to install stuff etc. :(
<rick_h> huwshimi: feel free to skip, you asked what I thought. I set it up in lxc. 
<rick_h> huwshimi: installing it is the three commands, bzr branch && make sysdeps && makeinstall
<huwshimi> rick_h: It's ok, I'm getting there :)
<huwshimi> rick_h: I remember the pain of having it installed locally in the past.
<huwshimi> rick_h: Seen anything like this? http://paste.ubuntu.com/6012441/
<rick_h> looking
<rick_h> huwshimi: no, do you have either of those bin? /usr/bin/nodejs /usr/bin/node ?
<huwshimi> rick_h: I have /usr/bin/nodejs
<rick_h> huwshimi: then I'd try to run that command and see if goes through/gives an error
<rick_h> huwshimi: the issue is that the name of the bin changed at one point and this helps cover it 
<huwshimi> rick_h: Well the symlink is created now :)
<huwshimi> (worked fine doing it manually)
<rick_h> huwshimi: yea, so re-run make sysdeps
<rick_h> it's safe to re-run
<rick_h> and see if it bombs again, hopefully not :)
<huwshimi> rick_h: I think it was fine this time
<rick_h> huwshimi: yay!
<rick_h> huwshimi: coffee shop is closing in a couple of min and going to be afk. Just heads up, not ignoring you
<huwshimi> rick_h: Sure, thanks. I think I'm getting there now :)
<huwshimi> rick_h: make run failing with "pymongo.errors.ConnectionFailure: could not connect to localhost:27017: [Errno 111] Connection refused"
<rick_h> huwshimi: sudo service mongodb start ?
<huwshimi> rick_h: "<4>init: mongodb main process (10631) terminated with status 100"
<rick_h> https://jira.mongodb.org/browse/SERVER-5808 ?
<rick_h> huwshimi: or http://randsubrosa.blogspot.com/2013/02/mongodb-main-process-terminated-with.html
<huwshimi> rick_h: Wait a second. If I'm creating folders/branching etc. inside the container should those folders be appearing in my regular home directory?
<huwshimi> rick_h: My terminal says: huw@charmworld
<rick_h> huwshimi: yes, the lxc create with the -b binds your home dir so you get your .vimrc and you can edit the files with an editor on your host system while running in the lxc
<huwshimi> rick_h: Ah I see
<rick_h> off to bed, best of luck!
<huwshimi> rick_h: OK, thanks for all your help
<anthonydillon> Hi guys, just setting up a demo of the juju gui. Does each employee get AWS?
<bac> hi adeuring
<adeuring> hi bac, i can meanwhile reproduce these errors
<bac> adeuring: oh, excellent
<adeuring> though not as reliable as i'd like.
<bac> well, in that case, i'd like to land the branch with the tests disabled so i can proceed with my other branch.  had it been restricted to me i would not want to disable them in trunk.
<adeuring> My guess is that ElasticSearch is simply queired too early after some data has been inserted.
<bac> adeuring: can you review the disable branch for me?
<adeuring> sure
<adeuring> bac: sorry -- i missed your MP when i read mails this morning...
<adeuring> r=me
<bac> adeuring: np
<hatch> morning
<sinzui> bac, can you run juju status for staging. I am now locked out. I am getting Invalid SSH key for everything on canonistack
<sinzui> adeuring, did you ever sort out the SSH error you were getting when you used juju on canonistack?
<adeuring> sinzui: no, did not take the time to look closer...
<bac> sinzui: yes i will
<sinzui> adeuring, bac, not only cannot I not use juju to see staging. I bootstrapped a new env and though I can see it via nova, I cannot access via juju
<bac> sinzui: yes, 'status' worked.  do you want the output or was it just a test?
<sinzui> bac, no need. Until I have access again, I think you will be responsible for calling
<sinzui> juju set charmworld revno=XXX
<sinzui> for everything tarmac merges
<bac> sinzui: ok, my branch is scheduled to merge soonish.  i'll update when that happens
<sinzui> I don't think my issue is about saucy since adeuring is also affected
<sinzui> bac, adeuring: I can see staging again after a reboot.
<bac> yay
<bac> sinzui: i'm updating the revno, even though it is a silly branch.  just an exercise.
<rick_h> ugh for positional argument changes
<sinzui> bac, benji. I just got a staging error that might be a 404 being presented as a 500?
 * sinzui reports bug
<jcastro> heya rick_h 
<jcastro> are you going to ohio linux?
<rick_h> jcastro: nope :(
<jcastro> I had a crazy idea for a juju gui demo
<rick_h> jcastro: it's the only weekend in Sept I don't have something going on. 
<sinzui> bac, benji: This is the error I saw on staging: https://bugs.launchpad.net/charmworld/+bug/1215473
<_mup_> Bug #1215473: Not found bundles cause 500 errors <oops> <charmworld:Triaged> <https://launchpad.net/bugs/1215473>
<jcastro> rick_h: ok so let me just validate my idea then, and you tell me if it's possible.
<rick_h> jcastro: sure thing, happy to help
<jcastro> rick_h: there's no internet there ...
<benji> yep, definately a bug
<jcastro> is it possible to cache enough stuff on my laptop to run a gui demo, with say .... importing a bundle on a mock environment?
<rick_h> jcastro: I can set you up with an offline setup of charmworld/gui you can run from lxc containers. It's how we do dev
<rick_h> jcastro: we'd need to get together some time to walk through it, ingest, etc
<jcastro> rick_h: I want bang for the buck though, like if it takes you 2 days to prep me then that's not acceptable. 
<rick_h> jcastro: naw, the long part is waiting for ingest to run. 
<jcastro> rick_h: or I can use hotspot is probably better
<rick_h> jcastro: that might have to sit and spin for a while, but the setup part is pretty ootb. Longest part is setting up lxc containers aside from ingest. 
<rick_h> jcastro: or that if you can keep a connection for sure
<jcastro> ok I'll investigate connectivity options and get back to you
<bac> sinzui: yeah, i triggered that error and am looking into it
<rick_h> jcastro: let me know what you want to do. 
<hatch> jcsackett: did your changes to the view change stuff make it to comingsoon ?
<hatch> I'm still seeing the bug in IE :/
<hatch> jcsackett: looked like it was some super stubborn caching
<rick_h> 'we cache 'cause we care'
<hatch> 'we know you said you want to clear the cache, but we know you dont really want to'
<hatch> does anyone know of a really awesome backpack for air travel?
<rick_h> I <3 mine. Got it for just that purpose when I joined. http://www.tombihn.com/backpacks/TB0111.html
<bcsaller> for air travel I recommend the one with the parachute 
<rick_h> small, fits under the air plane seats well, trim
<rick_h> ooh, good point. Mine fails on that count. :(
<bcsaller> I suppose it depends on what you have in mind
<hatch> lots of pockets, easy to get my laptop out at security
<Makyo> jujugui call in 10 kanban now
<jcsackett> jujugui: anyone else finding that tests aren't completing locally? on trunk, running test-debug, i don't get failures but it quits without giving the usual little "done" summary.
<hatch> jcsackett: did you pull in trunk?
<hatch> there was a bug with the websocket tests and phantom
<jcsackett> i did this morning, but didn't see anything landed against that. i'll pull again.
<hatch> http://www.everki.com/products1/backpacks/flight-checkpoint-friendly-laptop-backpack-fits-up-to-16-detail
<hatch> that backpack looks cool
<Makyo> jcsackett, pull again.
<Makyo> jcsackett, I think the branch I just landed should fix that.
<jcsackett> hatch, Makyo: \o/ indeed it does
<hatch> awesome
<hatch> tbh I'm not sure how those websocket tests ever passed
<hatch> maybe the failure was sending a false positive?
<jcsackett> hatch: i'm alarmed by our trend of "well, this never should have worked".
<jcsackett> seems to have come up several times of late. :-P
<rick_h> jcsackett: means we're getting better at finding and fixing them :)
<jcsackett> rick_h: that's a good way to spin it. :-)
<rick_h> hatch: that backpack is huge
<rick_h> jcsackett: thanks, I'll be here all week, try the veal
<hatch> rick_h: lol it is!
<Makyo> jujugui call in 2
<rick_h> smaller is better when traveling imo
<hatch> rick_h: how goes the ghost constraints?
<rick_h> hatch: good, just sucks that .deploy has positino args so I've got to go through every instance of *.deploy( and check if it's a deploy and add a bunch of 'null', before the callback
<rick_h> hatch: https://code.launchpad.net/~rharding/juju-gui/deploy-constraints/+merge/181610 is what I've got so far
<rick_h> still going through things
<jcsackett> rick_h: actually, think i/we conflated remove filter with remove categories...removing the category stuff from non-ac places shouldn't screw anything up, should it?
<rick_h> jcsackett: nope, the only thing will be to check on UX fallout like a giant empty div that we should remove
<jcsackett> rick_h: right. so i'll do this one and *then* move on to the likely painful process of filters.
<jcsackett> oh lord, i'm going to have to fire up IE again for this...those categories are placed with wonky css rules.
<rick_h> jcsackett: right
<rick_h> jcsackett: on both counts
<hatch> rick_h: ahh I see - that should almost just take a configuration object or use `arguments` to find the callback
<hatch> deploy() that is
<hatch> oh well that's probably more work than necessary :)
<rick_h> hatch: yea, I thought about that, but as it's my first foray into here I'd rather not go rewritting as I go
<rick_h> hatch: as you say, perfect case for a followup if time permits
<rick_h> hatch: especially since this is blocking the original goal
<hatch> a lot more work than originally thoought
<rick_h> hatch: yea, pretty much. Moving forward, will get there. 
<bac> benji: can we chat for a second about your last branch?
<benji> bac: sure
<benji> bac: guichat is free
<hatch> for a limited time
<hatch> then it goes up to $9.99/mo
<rick_h> jcsackett: didn't see the reitveld go through so commented on the LP MP
<jcsackett> rick_h: dig. reitveld is https://codereview.appspot.com/12935046
<jcsackett> but comment on LP is fine.
<jcsackett> jujugui: can i get one more on https://codereview.appspot.com/12935046 ?
<rick_h> jcsackett: ah, interesting. Took it a while to load
<Makyo> jcsackett,  on it.
<jcsackett> rick_h: my lbox is full of wonders.
<rick_h> no kidding
<jcsackett> where wonders == bugs.
<rick_h> jcsackett: will transpose the feedback then
<jcsackett> rick_h: i agree with your review, but am annoyed by your making me more work. :-P
<rick_h> jcsackett: sorry, thought I mentioned the overlay-indicator model to go by :( 
<rick_h> jcsackett: but it'll be pretty after :)
<hatch> jujugui also looking for two reviews and an IE QA https://codereview.appspot.com/12808048/
<Makyo> hatch, on it.
<Makyo> Will do the IE.
<hatch> thanks
 * rick_h runs and hides...someone said IE
<hatch> Makyo, there should be no more wako scroll bars - this branch landed that fix as well
<hatch> bcsaller: are you going to repropose your branch with the fix to that issue you mentioned yesterday or is that to be done in a followup?
<benji> sinzui: If you have a few minutes today, I would like to enact your plan to kill the bundles in the staging ES and update the staging code
<bcsaller> hatch: thats not a fix, thats additional UI work that can happen down the road, we don't need it for store bundles or import/export, only for complex deployer files with multiple targets, there is a card for it
<hatch> bcsaller: got it thanks
<sinzui> benji, sure. Do you want to talk or just raise a flag to deploy the latest rev
<sinzui> oh, are we behind again?
<hatch> rick_h: did you want to work on the ghost save button after this branch?
<hatch> it can't really be done until your current one lands
<rick_h> hatch: I was going to go back to my in-progress branch with the constraints on the ghost inspector
<benji> sinzui: I think deploying the head to staging will be fine (fine from my recent branch's perspective at least)
<rick_h> hatch: I'm hoping to put up the current branch that adds constraints to deploy soon. 
<hatch> rick_h: ahh ok your landing them in 2 stages
<sinzui> benji, we are still waiting for staging to comeback
<benji> there's no rush
<sinzui> benji, I usually cannot tell staging is down during a update
<benji> sinzui: in other words we started an upgrade and it is now down for longer than expected?
<sinzui> yes
 * sinzui visits charmworld/0
<benji> darn
<rick_h> hatch: yea, two step process
<sinzui> benji, es-update failed: https://pastebin.canonical.com/96243/
 * benji looks
<benji> sinzui: did we delete the bundles from the DB?
<sinzui> benji, I am going to check for the bogus bundle again. I am certain I deleted it from mongo and es yesterday
<hatch> jcsackett: landed right? https://bugs.launchpad.net/juju-gui/+bug/1214058
<_mup_> Bug #1214058: Cannot open Browse if sidebar is minimized  <charmbrowser> <juju-gui:Triaged by jcsackett> <https://launchpad.net/bugs/1214058>
<sinzui> benji, there is only 1 bundle is es and the owner is abentley as we expect.
<benji> sinzui: I thought we were going to remove all bundles (from ES and mongo) and let them be re-populated
<jcsackett> hatch: yes.
<sinzui> benji, we can with a migration. Though I can remove bundles from staging, only migrations can remove them from production
<benji> sinzui: oh, I was under the impression that you removed all the bundles from migration yesterday
<sinzui> benji, if we as webops to remove a bundle, they have to prevent ingest from putting it back 
<hatch> bac: https://bugs.launchpad.net/juju-gui/+bug/1202409 no longer an issue? I cannot repro
<_mup_> Bug #1202409: Firefox 22 on OS X shows service blocks with icon misplaced <juju-gui:New> <https://launchpad.net/bugs/1202409>
<jcsackett> jujugui: we have had a release since the charm model was unified, correct?
<benji> in that case I need to write a kill-all-the-bundles migration
<sinzui> benji, sorry no, I removed the bundle that had no owner, name, or basket
<Makyo> hatch, I think the icon fix got that.
<rick_h> jcsackett: not yet I don't think
<benji> ok, I know what I'll be doing after lunch then
<hatch> Makyo: that's what I thought, thanks
<sinzui> benji, I can intervene and get staging running now.
<rick_h> jujugui review/point out where rick_h is missing things time please. https://codereview.appspot.com/13084045
<jcsackett> rick_h: yeah, you're right. the cards are all still in releasable.
<benji> sinzui: sounds good; by "intervene" do you mean remove the bundles or fall back to the earlier code?
<jcsackett> rick_h: looking.
<sinzui> benji, This is what I am going to do: https://docs.google.com/a/canonical.com/document/d/190xKLPpEPSrlVix4D9eX_aTciiKFo12h0u7MpzqI28I/edit#heading=h.clph5b1k1cd5
<jcsackett> rick_h: a description of what your trying to do beyond TBD would be good, though. :-)
<benji> k
<rick_h> jcsackett: thanks, I'd like to get backend people to poke at it and find the holes I'm missing
<rick_h> jcsackett: doh! -edit coming on the way
<sinzui> well no, I am just going to pass the remove all flags
<jcsackett> rick_h: aaah, yeah. ima leave this alone.
<jcsackett> but still, more than TBD would probably help the backendy folks.
<rick_h> jcsackett: yea, accident. I forgot I did a WIP to look things over earlier
<hatch> jcsackett: rick_h doesn't really know what he's doing, he just starts coding then writes his intent after it's done....kind of a savant like that
<rick_h> hatch: :P
<rick_h> hatch: never claim to know wtf I'm doing. I'm just along for the riiiiidddddeeeee!
<hatch> lol
 * rick_h flips the 'lboxing' light 
<sinzui> benji, staging is happy again: the db was fixed thusly:
<sinzui> db.bundles.remove({}, false)
<sinzui> ^ remove everything found and do not stop at one
<benji> cool, that's what I'll put in my migration
<sinzui> I am not sure how to translate the DELETE http command to es
<rick_h> hatch: ok fine, comments added https://codereview.appspot.com/13084045
<rick_h> Makyo: also appreciate it if you can take a look and poke giant holes in what's there/missing. ^
<Makyo> rick_h, sure.
<hatch> rick_h:  :P
<sinzui> benji, I think es can be sorted with
<sinzui> delete_all(index, BUNDLE)
<sinzui> ^ delete all document of type bundle
<hatch> rick_h: I'll take a review
<rick_h> hatch: thanks!
<rick_h> Makyo: so I was looking, the names of the constraints match the names on the pyjuju side so they don't need to be mapped. 
<rick_h> Makyo: and the _handle... method was on the callback side
<rick_h> Makyo: it looked likt for taking the juju-core response and converting it into the JS code
<rick_h> Makyo: and so didn't fit with me converting 'before' sending the rpc call out to juju-core
<Makyo> rick_h, ah, yeah, makes sense.
<Makyo> It looked good, just missing the data.Params.Constraints or whatever in the go sandbox.
<rick_h> hatch: on the safety catch, I was hoping to leave it in. Getting a strange "cannot call undefined" or something error on any cases I missed will suck to debug. 
<rick_h> Makyo: k, will look there. Thanks for the catch.
<Makyo> rick_h, Since that's calling state.deploy(), you may have to translate -back- to the python-style constraints :/  I had to do similar with get charm somewhere around there.
<rick_h> Makyo: yea, that was what I had mentinoed wanted to chat about. However, we don't do that currently do we? I didn't see us doing that and we support constraints, just not on deploy?
<rick_h> or maybe I'm missing smoething
<rick_h> errr something
<rick_h> Makyo: oh wait, ok state.deploy. I noticed those calls but didn't know what 'state' was and the call sig was different so I ignored it. 
<Makyo> rick_h, Yeah, that should be deploy() in fakebackend.js
<rick_h> ok cool. So some more poking around to do. 
<Makyo> Looking at it, handleClientServiceSetConstraints() should be doing the mapping, as well.  Could be a quick branch down the line, though
<rick_h> looking
<rick_h> Makyo: ok, so this is where I'm not sure on things. That method isn't 'called' anywhere I can see. However it's used by some backend something calling back?
<rick_h> e.g. bzr grep handleClientSetServiceConstraints 
<Makyo> rick_h, It's called by receive() at line ~790
<rick_h> ah, gotcha
<rick_h> Makyo: so if I was looking for a test of this to check how it works/fits together it would be under the different backend sandbox tests? the test_sandbox just seemed to be connection tests. 
<Makyo> rick_h, yeah, test_sandbox_{go,python}.js
<rick_h> nvm, so this is more about the set_constraints operation
<Makyo> rick_h, yeah, sorry. 
<hatch> rick_h: ok np
<rick_h> Makyo: guichat for a sec please?
<Makyo> rick_h, sure.
<rick_h> Makyo: ah, nvm. I missed adding the test into test_sandbox_go like I did in test_sandbox_python. 
<rick_h> wheee lots of files
<hatch> rick_h: here is another great perf vid http://www.youtube.com/watch?v=YV1nKLWoARQ
<hatch> stepping out for lunch
<rick_h> Makyo: sorry, one more time please
<rick_h> ok, so I lied about leaving right at 3, but headnig out now. Thanks for the help today. 
<bac> sinzui: i keep going in circles regarding URLs and bundle rev numbers.  it's not just me, either, as most of our google docs aren't consistent.  that said, for a bundle short_url would you argue to include the revision or not?
<sinzui> bac: no for short url
<sinzui> bac: charms don't have one yet
<sinzui> I think we can solve revs with the SEO and version work later
<bac> sinzui: then i need to support routes for with and without
<bac> which is ok
<sinzui> bac, I don't think we do today.
<sinzui> bac, remember that for seo, charmworld must support juju-gui urls, so we can solve the issue later
<bac> sinzui: right now i only have routes that include the rev number
<sinzui> bac: I wont stop you from implementing it, 
<bac> thanks!  :)
<bac> benji: have a moment to talk?
<benji> bac: sure, but I left my camera outside (and hangouts will only use my camera mic now) so I'll have to go get it real quick; jujugui?
<bac> benji: 'guichat', please!  yes.
<hatch> so hows everyones afternoon?
<benji> bac: wait a second, the bundle ID in mongo doesn't have the basket version in it
<bac> benji: does too
<bac> benji: make_bundle_doc calls construct_id with implicit use_revision=True
<benji> bac: darn, you're right
<bac> benji: you know, i *could* just construct an elasticsearch query and it'll point to the latest...
<benji> yep, that might be the best way to do it
<sinzui> bac, benji: do either of you have time to review https://code.launchpad.net/~sinzui/charmworld/provide-type-from-api-search/+merge/181661
<hatch> bcsaller and/or Makyo: able to do a preimp on removing the inspector flag?
<bcsaller> I can 
<Makyo> hatch, sure.
<hatch> cool in guichat
<hatch> oh bcsaller I found this, thought you might be interested in it http://blog.trevnorris.com/2013/08/long-live-callbacks.html
 * Makyo whipcracks at hatch, "Get to work, you got a big task ahead of you."
<hatch> lol
<hatch> Makyo: to that I say http://xkcd.com/303/
<jcsackett> hatch: there are days where lbox or tests definitely feel that way.
<jcsackett> "lbox propose -cr" ok, time to make coffee and play with the dogs.
<hatch> jcsackett: no that's `lbox submit`  ;)
<jcsackett> hatch: they both are, for me.
<jcsackett> submit i actually have to pay attention, b/c it wants my password part way through.
<hatch> yeah I suppose
<hatch> sooo....yeah our featureflag tests are broken.....they can't be .only'd
<hatch> we should fix that at some point
<Makyo> hatch, yeah, that's on the table.
<hatch> :)
<hatch> Makyo:  bcsaller this ones big! https://codereview.appspot.com/12815047/
<Makyo> I hit ctrl+enter on a review, like you would in gmail, and tabbed away.  Sorry hatch, lgtm.
<hatch> thanks :)
<huwshimi> Morning
<huwshimi> rick_h: Have you seen something like this? http://paste.ubuntu.com/6015818/
<huwshimi> rick_h: I didn't get that yesterday. Seems to be related to bug #1099155
<_mup_> Bug #1099155: [raring] No ip assigned to bridge and no routes added for virtual networks <amd64> <apport-bug> <raring> <running-unity> <libvirt (Ubuntu):Invalid> <lxc (Ubuntu):Invalid> <network-manager (Ubuntu):Fix Released by mathieu-tl> <https://launchpad.net/bugs/1099155>
<rick_h> huwshimi: no :(
<huwshimi> rick_h: Give up and install locally?
<rick_h> huwshimi: sorry, dinner and such here. Don't have much to offer
<rick_h> whatever you want to do
<huwshimi> rick_h: I know, I just don't want to have to build the whole thing again :)
<huwshimi> What a waste of a week
#juju-gui 2013-08-23
<benji> BradCrittenden: you can't seem to settle on a name here lately
<benji> I have a small review up that could use your attention: https://code.launchpad.net/~benji/charmworld/migration-018-delete-bundles/+merge/181807
<BradCrittenden> benji: yeah, i got the dropouts.
<benji> ooh, I hear that can be fatal
<BradCrittenden> the nick retention period is much longer than the time it takes me to reconnect so it won't let me have 'bac'
 * InigoMontoya prepare to die
<benji> InigoMontoya: you can /release the nick by talking to NickServ and he'll let you have it back
<InigoMontoya> benji: no, it isn't a problem, i can usually get it back quickly.  but i have to notice the problem after my client reconnects
<benji> why does your client choose the wrong nick?
<InigoMontoya> benji: b/c when it reconnects freenode has not yet released 'bac' and i guess i have the longer one as my alternate.
<benji> ah; I have some purge-all-past-incarnations commands that my client runs when I connect.  That helps a bit with that.
<InigoMontoya> benji: moving on to other topics:  i'm about ready to break out 'rev' as a separate field in the mongo doc.  it seems crazy to go to all of the trouble i'm having just for this issue.
<InigoMontoya> benji: it can still be part of the _id as needed
<InigoMontoya> benji: reality-based objections?
<benji> makes sense; will you also have the search_id as part of the document, so you can search on it?
<benji> no, but Falcor isn't a fan of the idea
<benji> ah, who am I kidding, Falcor loves everyone
<InigoMontoya> unsure about search_id
<benji> I figured that since you want to search on everything but the revision, the search ID would be the way to go (since that's what it is)
 * sinzui sets charmworld to benji's 264
<sinzui> 364 I mean
<jcsackett> rick_h: if you can look at https://codereview.appspot.com/12935046/ again i updated it yesterday.
<rick_h> jcsackett: cool looking
<rick_h> jcsackett: ah, I saw jeff gave you a lgtm so I didn't go back to it
<jcsackett> rick_h: it's LGTM with your proposed changes; figured i would make sure you were happy with those changes.
<jcsackett> if you want to hand wave it i'm happy to go ahead and land it. :-P
<rick_h> ok, looking now
<sinzui> benji, I see from the log the migration was run. I still see the wiki bundle. This might be a timing issue because ingest starts *before* the website is brought back up
<rick_h> jcsackett: replied. 
<jcsackett> rick_h: dig, thanks.
<jcsackett> jujugui: i need two reviews on https://codereview.appspot.com/12741050 and someone with IE to QA. it's an easy one--just a bunch of deletions.
<benji> sinzui: I would suspect timing.  The migration is simple and its tests seem to be representative.  If the bad bundle doesn't cause any errors, I would suspect re-ingestion.
<sinzui> benji, The ES data is different. The search that worked yesterday doesn't work. I think all is well.
<benji> cool!
<sinzui> benji, are bundles ingested first?
<benji> thanks for working on it
<benji> I don't know the order off the top of my head.
 * benji looks
<sinzui> I think they are, meaning the first bundles will always be place before the website restarts
<benji> sinzui: it depends on the hash order of a dictionary, so it should be consistent, but is unspecified
<sinzui> benji, bac: do either of you have time to review  https://code.launchpad.net/~sinzui/charmworld/provide-type-from-api-search
<frankban> bac, benji: when you have time, could you please review https://codereview.appspot.com/12802045 ?
<benji> sinzui: sure
<benji> frankban: sure
<InigoMontoya> frankban: sure
<frankban> thank you both
<rick_h> kind of short notice http://www.yuiblog.com/blog/2013/08/23/save-the-date-yuiconf-nov-6-7
<rick_h> hatch:  ^
<rick_h> hatch: Makyo updated the branch from yesterday with the bi-directional go constraint conversersion, refactoring, added the sandbox tests/adjustments. https://codereview.appspot.com/13084045
<rick_h> hatch: Makyo appreciate a second look though I know I got LGTM yesterday. Feel like a lot's changed, but part of that is in my head
<Makyo> rick_h, on it
<jcsackett> jujugui: can i get two reviews on https://codereview.appspot.com/12741050, please?
<rick_h> jcsackett: will look in a sec
<jcsackett> rick_h: thanks.
<Makyo> jcsackett, on it.
<jcsackett> Makyo: thanks!
<sinzui> jcsackett, admin thinks you are on holiday today. Did you forget?
<jcsackett> sinzui: it's a half day, PM.
<jcsackett> leaving at noon.
<sinzui> jcsackett, sorry, I thought you had extended it to the whole day.
<sinzui> I think I am the only member of Orange working on Monday.
<sinzui> benji, about the access to _representation. I too was hoping that we would have solved this by now for bundles and charms. maybe both classes should have a property that returns dict(self._representation)
<benji> sinzui: that would be fine with me; I do worry a little about non-canonical key/values sneaking in, plus it would be nice to have the properies get a chance to return things.  How about returning dict((key, getattr(self, key)) for key in self._COMMON_REPRESENTATION)
<rick_h> Makyo: did you do the IE QA on jcsackett's branch?
<sinzui> benji, yes, that is better. Maybe we want a guard in the class that ensures unwanted keys are always rejected. __init__ looks flawed. if it was ensured a sane dict, calling @representation or dict(Bundle(data)) could be trusted
<benji> sinzui: yep, I like putting the gate earlier too (dict(Bundle(data)) can actually be trusted now because it does its own filtering, but I get your point)
<sinzui> benji, okay. I will report a bug for this because I think we want to fix this bad pattern for charms and bundles.
<benji> sounds good
<Makyo> rick_h, ah, will do that now.
<rick_h> Makyo: that's ok, was wondering. My lbox submit finished so I can pull it into my colo now
<rick_h> I'll poke at it
<Makyo> rick_h, oh, alright.
<adeuring> bac, sinzui: could you trying the branch: lp:~adeuring/charmworld/1206659-spurious-errors ? it should fix a number of spurious failures, even some in tests that were not disabled in r362, but I'd like some independent test runs before I claim that everything is fixed...
<bac> adeuring: sure!
<sinzui> thank you adeuring
<bac> adeuring: how long does 'make test' take to run on your slow and fast machines?
<Makyo> luca, ping
<luca> Makyo: heya
<Makyo> luca, the upgrade service ux appears in two different places in the mockup.  I like the second one better - after all of the unit management stuff - because this is by service, not by units, and having it mixed in confused even me for a bit.  Can I go with that one?
<Makyo> luca, on https://www.dropbox.com/s/d6sc200adk2dszs/juju-gui-2-inspector-09.jpg
<luca> Makyo: they are the same but different :D
<luca> Makyo: There is 2 use cases going on here
<luca> Makyo: #1 I need to upgrade my servicer
<luca> Makyo: #2 I need to revert my service
<Makyo> luca, Why is it mixed in with units?
<luca> Makyo: When there is a new upgrade that the user hasn't seen yet, the "A new upgrade is available" populates near the top
<luca> Makyo: there isn't really a "mixed in with units" thing, they are just notifications, it's all about hierarchy
<Makyo> luca, I keep getting wireframes with no explanation and being told to implement.  I'd appreciate a call.
<Makyo> jujugui call in 10 kanban now.
<luca> Makyo: Ah, thats fine. We actually worked with gary on this and most of this way his idea, I would of thought he would of briefed you guys on it before delegating it out.
<Makyo> luca, nope.
<luca> Makyo: right, when are you available?
<Makyo> luca, now for 9 minutes, and in an hour and nine minutes for several hours.
<adeuring> bac: the slow one needs ca 100 seconds (...and I just noticed another test failure...)
<bac> adeuring: i'm running the tests but they are taking forever to run
<adeuring> ..and the fast machine now show a ton of errors even for trunk...
<bac> adeuring: in past 'make test' took about 74 seconds for me.  this one is taking minutes
<adeuring> bac: interesting. I changed a status check when a temporary index is created for a test. Could be related.
<bac> adeuring: still on the first line of dots of test output
<adeuring> bac: Then just abort it...
<bac> adeuring: even if all tests pass, this is too painful
<adeuring> right
<Makyo> jujugui call in 1
<bac> adeuring: try scripts/reset-db?
<bac> adeuring: in a bind, i've rm /var/lib/elasticsearch too
<adeuring> bac:  yes
<adeuring> i tried both, but i did not restart mongodb, as suggested by sinzui
<Makyo> rick_h, constraints are passed from pyjuju in the get_service call, and are hooked up, at least in the inspector.
<Makyo> rick_h, will check go too.
<rick_h> Makyo: k, cool. Yea I figure pyjuju worked and maybe we never got around to checking/working on -core?
<Makyo> rick_h, yeah, will do that now.
<bac> sinzui: you said "it is not in saucy".  were you referring to pyjuju or core?  that is, what is in saucy?
<sinzui> pyjuju is not in saucy
<rick_h> sinzui: ah, that makes sense
<rick_h> sinzui: I heard it the other way as well
<sinzui> sorry for speaking in curtisese
<hatch> rick_h: I'm going to revert the inspector and then I can help you out
<rick_h> hatch: k, all good. 
<Makyo> Bleh, debug-log no longer uses newlines, nearly impossible o read.
<rick_h> joy
<hatch> matt I crested a card in urgent and put our heads on it for the IE10 QA
<Makyo> hatch, Cool, thanks/
<hatch> crested a card
<hatch> hmm
<hatch> lol
<Makyo> rick_h, I am getting constraints from core, too, but they're showing up strangely.  It looks like core responds only in MB, but GUI expects GB for memory, so it says I created a machine with 2048GB of memory.  I hope that's not the case :)
<rick_h> Makyo: hah, ok. Good to know. Maybe that follow up card isn't much work then. 
<rick_h> Makyo: curious to trace how it was getting the data format and fitting it to the UX
<hatch> 2048GB of ram....that must be rick_h's new desktop
<rick_h> hah, I'm about 2012 short
<hatch> lol
<rick_h> err, 2016 that is. /me can't do match on fridays
<Makyo> rick_h, It looks like it's just populated in the service model's attrs and bound in the inspector from there.
<rick_h> Makyo: cool
<rick_h> Makyo: yea, I saw some stuff in the utils that generates titles and such for the UX so maybe it's doing it there. 
<Makyo> luca, ping; I'm free if you've got some time before your end of day.
<luca> Makyo: ok, I'm in a meeting with Mark S at the moment but I'll join guichat when I'm out.
<Makyo> luca, alright, thanks.
<benji> frankban: I finally finished looking at your branch, it looks good
<frankban> benji: great, thanks
<luca> Makyo: I'm on GUI chat
<Makyo> bcsaller, in guichat if you want to join
<rick_h> Makyo: after your call, was that -core constraint working done via the gui? e.g. you deployed and set a constraint from the gui and then when you opened it back up it was loaded ok, just off as far as units?
<Makyo> rick_h, deployed from command line in a real env.  `juju deploy --constraints mem=2G cs:precise/mysql`
<rick_h> Makyo: ok, I'd be curious then if settnig via the gui does work since that's where I was looking for us to translate the names of the constraints to the Go format. 
<rick_h> hatch: running out to grab some food. Looks like my last branch had the wrong 'structure' for constraints and so needing to clean that back up. Latest work is in lp:~rharding/juju-gui/ghost-constraints-1125352 if you want to poke and if you wanted to pair on it in a bit. 
<hatch> rick_h: ok sure - I have a few emails to write then I'll be on it
<rick_h> hatch: np, biab
<hatch> hmm
<hatch> fresh trunk test failures....
<hatch> I'm always confused how this happens
<hatch> oh it did fail in CI too
<hatch> it was just masked by the selenium failures
<rick_h> hatch: details on what I broke?
<bac> frankban: review done
<hatch> rick_h: I think it was a bad merge
<rick_h> hatch: hmm, yea that sucks. I mean it has to merge/pass tests to land so confused
<hatch> rick_h:  https://gist.github.com/hatched/13dd112c33c1263476f4
<frankban> bac: thanks!
<hatch> oh woops
<hatch> heh
<hatch> the 'expected' is the Constraints object
<hatch> ^ rick_h
<rick_h> hatch: yea, looking
<rick_h> hmm, those are tests I changed and such but not seeing the /actual/expected 
<rick_h> hatch: but I can pull down trunk again and see if I can replicate it locally. Sec
<hatch> thanks
<rick_h> hatch: ok, I have the same error here. Will hack a branch to see what's up/fix it.
 * rick_h wonders how the $@#$@# it landed then. 
<hatch> yeah right!?!?
<hatch> maybe you had an old test server running :D
<hatch> that caught bcsaller once hehe
<rick_h> oh, and the lbox hit that vs its own?
<hatch> yup
<rick_h> hmm, guess that's possible. I was running tests. 
<rick_h> hatch: cool, easy fixes. Must have done that I guess. Sorry about that :/
<hatch> yeah....you'll pay for this....
<hatch> with your cpu.....mohohahahahahaha
<hatch> I figure that would be from Futurama
<rick_h> haven't I already suffered enough on this card? plus more lboxing...the punishment!
<hatch> pssht lboxing for you is what....20s? :P
<rick_h> no, stupid bzr/launchpad/branching :/
<hatch> ahhh right right
<hatch> rick_h: gave you an lgtm
<rick_h> hatch: cool thanks. 
<rick_h> hatch: ok, fix heading down for that. 
<hatch> great - once it lands I can then revert the flag branch
<rick_h> it's in trunk at least. bzr pull will have it and you can start
<hatch> cool proposing
<hatch> jujugui fyi I'm putting bugs which will block the release in maintenance/urgent
<rick_h> hatch: k
<hatch> jujugui review for reverting the inspector as the default https://codereview.appspot.com/12739049/
<hatch> Makyo: I can't find any IE10 specific bugs \o/ lemme know what your result is whenever you get a chance
<rick_h> hatch:  looking
<hatch> landing thanks for the reviews Makyo rick_h
<Makyo> My IE is so small :S  I should see if I can get VB to pretend like I have a bigger monitor.  The unit details view goes off the edge of the screen.
<Makyo> Happens in all browsers, ditto with fullscreen.  I think I  just have it smaller than our minimum size is all
<Makyo> hatch, maybe worth a card, but I don't think I'd consider it a blocker.  Looks fine once I get above something like 1024x768 :P
<hatch> haha that's pretty small
<Makyo> hatch, yeah. vbox just picked up a small default.
<Makyo> hatch, also, relation labels are too high.  Also small.  Probably defaulting to a baseline at the bottom rather than the middle.
<Makyo> hatch, no blockers, though.  Everything looks/works fine otherwise.
<hatch> awesome! :D
<hatch> thanks for that
<rick_h> man, almost have my own charmworld/juju-gui running in lxc containers but can't configure the juju-gui to set the charmworld url away from manage.jujucharms.com
<hatch> rick_h: sounds like a bug to me :)
<rick_h> hatch: trying to set via cli and see if it works
<rick_h> hatch: yea, worked via cli. hmmm, need a release to check if it works via the inspecgtor
<rick_h> http://uploads.mitechie.com/lp/lxc-jujugui.png so that's all in lxc containers. Charmworld hadn't finished ingesting and such. However cool to run it all locally. 
<rick_h> pretty quick overall
<rick_h> so thanks for the charm-school jcastro ^ 
<hatch> that is awesome :) I need to do that at some point
<rick_h> 20GB of ram left, time to try to run 100 juju-guis
<hatch> very odd issue with the CI failures this time
<hatch> I guess I'll retrigger it and see what happens
<hatch> rick_h: so where are we with the ghost constraints stuff? Anything i can help with?
<rick_h> hatch: sorry, took a break to watch the charm school on lxc stuff to test things coming up. 
<rick_h> hatch: so we're doing ok. Fixing the constraints object conversion to work
<rick_h> python works, go api fails. 
<hatch> who needs Go anyways
<rick_h> heh, my branch is going to leave the api set to go in the config-debug per our discussion today
<hatch> I think I missed that discussion
<hatch> guichat to bring me up to speed?
<rick_h> sure
<hatch> awesome HTC is going to fix the mrs phone - now I can go get a new phone haha
<hatch> canceled CI trying again...
<rick_h> hatch: ok, might need a chat after all. Data seems to go in, won't come back out
<hatch> rick_h: ok in a few minutes just eating a sandwitch :)
<rick_h> hatch: rgr
<hatch> arg I don't know what's up with this CI
<hatch> rick_h: ok sandwitch done ....guichat?
<rick_h> hatch: rg
<rick_h> rg
<rick_h> damn rgr
<bac> benji, sinzui: in our google doc, we agreed the api endpoint should be plural "bundles" but it is still "bundle".  any objections to me fixing it?
<benji> bac: are we going to change "charm" to "charms"?
<benji> wait, there already is a "charms"
<benji> bac: we changed it the other way, API2 had "charms" but API3 has "charm"
<sinzui> bac, charms/ is a searchable collection, charm/ is an individual charm
<sinzui> bac /search is a collection of all bundles and charms and it replaces charms/
<bac> sinzui, benji: looky here: https://docs.google.com/a/canonical.com/document/d/17bgbReU6JJMoUHSJeo8egG5zoSM0fpPIs7U8F1-Piyk/edit#heading=h.u3246vho9aig
<sinzui> bundle/ would provide a single bundle I think
<bac> fourth bullet point
<bac> http://staging.jujucharms.com/api/3/bundles/~abentley/wiki-bundle/1/wiki
<sinzui> bac, I know.bundles/ is fine because we moved charms/ to search/
<benji> bac: I don't really care much one way or the other, just making the current state known
<sinzui> bac, benji. I don't have an opinion about the plural of bundle(s)/, but I want it to be consistent with charm/ which is what we have now
<benji> +1
<sinzui> we can rename charm to charms/ in api3
<bac> sinzui: well it is easier to fix the google doc than the code
 * sinzui is dizzy from seeing all his work not come to fruition today
<bac> actually, no because we have:
<bac> http://manage.jujucharms.com/~sinzui/bundles/mysql/5/tiny/json
<bac> http://manage.jujucharms.com/bundles/mysql/tiny/json
<bac> so, in the branch i'm about to propose they are all going to be 'bundles'
<bac> if we want to change them to 'bundle' we can do that, after updating the doc
<bac> i gotta land this thing!
<sinzui> bac, sure. We will revisit all the URLs in SEO soon anyway
<sinzui> bac, I can review your branch if you want https://code.launchpad.net/~bac/charmworld/official-bundle-json/+merge/181909
 * sinzui needs a break from failing to show interesting bundles
<bac> sinzui: it has conflicts.  i'll let you know when it is fixed -- thanks!
<bac> sinzui: conflicts fixed
<bac> sinzui: sorry the diff is so long
<sinzui> bac: np
<sinzui> bac, can you review https://code.launchpad.net/~sinzui/charmworld/api3-interesting/+merge/181910 ? It is very short because I got lost
<bac> sure
<sinzui> bac, I replied with 2 questions
<bac> sinzui: ok
<bac> sinzui: thanks for the mongo sort reminder.  i'd tried that yesterday, before i made basket_revision a field.  i'll make that change now.
<bac> sinzui: as to the other, yes basket_with_revision is a better name
<sinzui> bac okay. I was only asking questions. Make changes as you like; r=me
<bac> sinzui: would you update https://docs.google.com/a/canonical.com/document/d/17bgbReU6JJMoUHSJeo8egG5zoSM0fpPIs7U8F1-Piyk/edit# with check marks?
<sinzui> bac, The 3 interesting parts aren't done-done
<sinzui> I did verify routing with versions is good
<bac> sinzui: 4b and 4c aren't done?
<sinzui> bac, api supports them, but until we change ingest and views to collect the data, no one will see which is new or popular
<sinzui> well...considering how new bundles are, we might not ever see popular bundles
<bac> good point sinzui.
 * bac dog walk
<sinzui> bac, I deployed your changes to staging. They work for the most part, but I think there is something amiss with the basket-name: http://staging.jujucharms.com/~abentley/bundles/wiki-bundle/1/wiki/json is not found  and a search for abentley finds a bundle without a basket.
<sinzui> bac, I need to make dinner so will sign off. I think we need to update ingest or the model to handle the / in the basket. I see this in the DB: { "_id" : "~abentley/wiki-bundle/1/wiki", "owner" : "abentley", "basket" : "wiki-bundle/1"}
<sinzui> well, before I go I will delete the bundle from staging so that we can check with a fresh ingest.
<hatch> man there has to be something wrong with canonistack
<sinzui> hatch, how do you mean
<hatch> the ci just hangs after loading in the selenium deps
<hatch> and I can't find anything wrong with it
<hatch> it's like it can't create a new instance or something
<sinzui> hatch, are the deps enormous?
<hatch> I don't think so it always gets to "FInished processing dependencies for selenium==2.33.0"
<hatch> then sits there for 45mins until it times out
<sinzui> hatch, I wonder if there is a network issue. I thought this might be an issue with the charm payload. which is bug 1156649
<_mup_> Bug #1156649: pyJu fails to deploy/upgrade charm with 32MB payload <juju:New> <https://launchpad.net/bugs/1156649>
<hatch> hmm nope it's not even getting that far
<hatch> I think I'll bench this and make a card
<hatch> start on it again on monday
<sinzui> hatch, I think you are getting much farther since you have an instance doing an install
<sinzui> have a nice weekend
<hatch> you too!
<sinzui> bac: I have good news and bad news. Since I did not go away as I claimed I was, I was here fir the reingest of the bundle. It works! this means we need a migration to purge all bundles before your changes are activated. Oh, but since I happen to know benji landed just such a migration 9 hours ago, we can just pretend you have. I am confident that no bundles will be in the db when we restart production.
<sinzui> bac have a nice weekend.
 * benji is glad to be part of the good news for once.
 * bac missed the bad news
<bac> it sounded like good news & good news
#juju-gui 2013-08-24
<MACscr> ok, i just installed juju inside an lxc instance. now how do i install the juju gui?
<MACscr> ah, looks like i might have to install it on the actual host
<rick_h> MACscr: right, you have to juju deploy juju-gui
#juju-gui 2013-08-25
<huwshimi> Morning
<rick_h> morning huwshimi 
#juju-gui 2014-08-18
<huwshimi> hatch: Any idea what is going on here? http://ci.jujugui.org:8080/job/juju-gui-merge/575/console
<hatch> just re-run it
<huwshimi> ok
<hatch> assuming you have the conflicts fixed
<huwshimi> yeah
<hatch> huwshimi looks like thse 2 landed well
<huwshimi> hatch: Yeah, I had to fix the tests and merge conflicts for both. I was prepared for that as all my branches are touching the same code
<hatch> ahh - well this mv is coming together quite nicely
<hatch> I found a really simple way to do the new inspector tests heh
<hatch> well a simple way to conver it
<huwshimi> Ah nice!
<hatch> yeah I'll put it up tomorrow
<huwshimi> Great
<hatch> now the card I've been working on is going to be quite interesting...
<hatch> the one where we delete the machine token before the delta comes in
<huwshimi> hatch: oh yeah, it'll be a nice change, but tricky to handle
<huwshimi> hatch: Any ideas how you'll do it?
<hatch> heh still investigating....it's probably going to be a multi step process, the model will be updated with the appropriate data when juju sends it's ACK but then when the detla comes in, it swaps it then...
<hatch> well I'm out, have a good day
<rick_h__> morning party people
<urulama> rick_h__: morning
<frankban> rick_h__: morning
 * frankban lunches
 * urulama lunches
<bac> ahoy
<rick_h__> welcome back bac
<bac> you too, though a day late
<rick_h__> bac: spent 3hrs watching youtube videos on landscape photography for my yosemite trip
<rick_h__> bac: watch out, here comes hdr I think, I don't have all the ND filter extra 10lbs of stuff on my lens gear :/
<bac> fun
<bac> we took a day trip on friday and i took some crap fotos, but it was fun
<rick_h__> party
 * urulama checks bac.photo ... no Yosemite :(
<bac> jujugui: just had failures bootstrapping to ec2:us-west-2.  changed to us-east-1 and all was good.  ymmv.
<bac> urulama: never been to yosemite.  :(
<frankban> urulama, guihelp: I need two reviews for https://github.com/juju/charmstore/pull/75 (charmstore/golang). anyone available? thanks!
<urulama> frankban: be on it in 5min
<frankban> urulama: thanks
<hatch> jujugui need one more review on huws branch https://github.com/juju/juju-gui/pull/500
<urulama_> hatch: internal server error ...
<hatch> hah hah haaaaaa
<rick_h__> hatch: looking
<hatch> thx
<hatch> jujugui call in 10
<hatch> jujugui call in 2
<rick_h__> jujugui call time antdillon urulama_ ^
 * bac trying...
 * bac reboots
<hatch> Makyo:  https://github.com/juju/juju-gui/pull/501
<Makyo> Thanks
<hatch> really trivial, heh
<hatch> jrwren: so they don't have overnight camp there? 
<hatch> or do I have a different idea of camp :)
<jrwren> hatch: she is a little young for that. She would probably be fine.
<jrwren> hatch: no kids eh?
<jrwren> hatch: once kids get to elementary school, instead of going to day care all day in the summer, they go to day camps.
<jrwren> hatch: a lot of our kids friends are at day camp all day every day of all of summer vacation.
<rick_h__> luca: ! the guys brought up something important
<jrwren> hatch: it makes for a very different childhood than I had. 
<rick_h__> luca: how does one delete a unit on a machine/container?
<hatch> jrwren:  nope no kids, one big d.i.n.k, here
<hatch> ahh yeah we don't have day camps, just day care for summer
<jrwren> hatch: stop, you'll make me jealous.
<hatch> although I was different because I went to the lake for most of the summer
<hatch> lol
<luca> rick_h__: each unit has a destroy button found in a more menu
<rick_h__> luca: ok, /me goes to look for that screenshot
<rick_h__> luca: and anything on the inspector list for the units?
<hatch> day camps actually sounds like a really great idea
<luca> rick_h__: https://drive.google.com/file/d/0B7XG_QBXNwY1RXozODVyeU5QMUU/edit?usp=sharing
<luca> rick_h__: thats right, at the moment scaling down can only be done manually
<rick_h__> luca: that's destroy machine, but what about a single unit on that machine?
<luca> rick_h__: itâs the same
<luca> rick_h__: there should be a more menu associated with every unit available on hover
<luca> rick_h__: inside that more menu you can find destrou
<luca> rick_h__: destroy^
<rick_h__> luca: oh? there's a more menu for every unit in a machine/container?
 * rick_h__ missed that
<luca> rick_h__: I just check the states file and itâs missing from thatâ¦
<luca> rick_h__: somewhere down the MV iterations Spencer and I have forgotten to include it in the states file
<rick_h__> luca: ok, so we're not completely nuts to not have it 
<luca> rick_h__: but weâve had a destroy button on units since the button
<rick_h__> luca: thanks 
<luca> rick_h__: no worries
<luca> rick_h__: I donât have Spencer available to make a new mock-up though
<luca> rick_h__: https://docs.google.com/a/canonical.com/file/d/0B7XG_QBXNwY1YjNQajhsMUNHOFE/edit
<rick_h__> luca: all good
<rick_h__> we can work it out
<luca> rick_h__: ok, thanks
<rick_h__> anything else in there besides the destroy?
<rick_h__> luca: maybe we'd put the web view stuff in there if we get that feature in
<luca> rick_h__: I was thinking of âView on the webâ
<rick_h__> right
<luca> rick_h__: yeah
<rick_h__> ok cool
<luca> rick_h__: weâre in sync :P
 * rick_h__ is scared now
<luca> rick_h__: lol
<kadams54> jujugui: Sorry about missing standup. Lost my internet connection and then my phone tethering failed me, so ended up relocating.
<rick_h__> kadams54: all good
<rick_h__> kadams54: any notes on your current card?
<rick_h__> kadams54: I wasn't sure what 'all classes' meant
<kadams54> rick_h__: we need autodeploy functionality now in both the MachineViewPanelView and DeployerBar classes.
<rick_h__> kadams54: right, and it's in the MV panel currently?
<rick_h__> kadams54: at least the UX is there, /me hasn't tried it out
<kadams54> rick_h__: Yup. Got that refactored into a class extension and all tests are passing, but there aren't any unit tests touching those methods specificially.
<hatch> frankban:  rick_h__ Makyo was there a reason why we originally went with removing ghost models of machines/containers/units instead of updating them on the delta to begin with? 
<kadams54> rick_h__: So I'm writing up some new tests before landing it.
<rick_h__> hatch: I can't recall any reason. Just easy? Maybe some connection point issue between the delta coming back?
<rick_h__> kadams54: ok awesome thanks
<frankban> hatch: I don't remember: does the ghost model share the same id as the real one that will come?
<hatch> frankban:  no their id's will be different, but that doesn't necessarily mean we can't update it
<hatch> I am just devising a plan and wasn't sure if there was some reason why we didn't do that originally 
<urulama_> frankban: been on a call, continue your PR
<frankban> hatch: so are you planning to update the models in handlers.js?
<rick_h__> hatch: I think the main thing is to make sure we don't couple too much stuff together doing that
<hatch> so my plan (still to be determined if this will work) when juju responds with ACK we update the ghost model with the 'real' ids - then when the delta comes in, we search for the id supplied in the detla and update the model accordingly
<hatch> right now the issue is that when juju sends the ACK we destroy the ghost model
<hatch> so we don't have any UI until the delta comes in
<rick_h__> right
<kadams54> hatch: what card are you working on?
<rick_h__> I think your plan seems sane 
<hatch> kadams54:  in Project 1
<kadams54> hatch: yeah, this is the uncommitted state not being removed until we get the ACK, right?
<frankban> hatch: that would work fine, assuming we have the real id for each call at juju ACK time
<hatch> frankban:  right, do you know if that's the case? 
<hatch> I am assuming so, but have no data to back that up yet
<frankban> hatch: no, we need to check, and it can be done easily by looking at go.js
<frankban> hatch: if that's the case, then +1 on your plan
<hatch> great thanks all, I'll dig deeper
<kadams54> hatch: just a heads up: this may impact the stuff I just landed in the onParentResults handler specified in lazyAddUnits.
<hatch> kadams54: it shouldn't, this is all happening in the callback after the juju ACK so it's all one layer up from where that's happening
<hatch> onParentResults is called well before this stuff
<kadams54> hatch: cool
 * rick_h__ runs to get food stuffs
<hatch> kadams54:  with that said, your changes makes this work properly though :)
<kadams54> yay
<hatch> jujugui does anyone have any tricks to working on the gui in a real env? 
<frankban> hatch: you know mine, mostly for hacking. if you mean being able to have a branch in the lxc, then no, but I always wanted to investigate something like that
<frankban> hatch: anyway, mine is: juju set juju-gui juju-gui-debug=true juju-gui-console-enabled=true juju-gui-source="https://github.com/frankban/juju-gui.git BRANCHNAME"
<hatch> frankban:  well I want to work on the gui in the local env without having to push it up all the time
<hatch> frankban:  using juju-gui-debug=true does that allow me to modify the source in the charm and have it reflected in the real env?
<frankban> hatch: and then hack on /var/lib/juju-gui/juju-gui/build-debug (or something like that)
<hatch> ok I'll try that thanks
<hatch> huh it appears that local isnt' working for me, it's not spinning up an lxc instance
<hatch> 1.20.1
<hatch> hmmmmmmmmm
<rick_h__> hatch: any luck?
<hatch> rick_h__:  yeah got it deployed, changes in the dir frankban mentioned don't appear to show up though
<frankban> hatch: did config-changed complete its execution? are you in the build-debug directory? are you refreshing your browser hard?
<hatch> frankban:  yeah I'm on the develop branch, and modifying in the same dir you mentioned
<hatch> no amount of refreshes seem to help
<frankban> hatch: what's the content of /etc/init/guiserver.conf?
<hatch> --guiroot="/var/lib/juju-gui/juju-gui/build-debug" \
<hatch> assuming that's the line you're interested
<hatch> that's where I'm modifying but nothings changing in the browser....
<frankban> hatch: yes, so those are the file served
<frankban> being served
<frankban> hatch: in var/log/upstart/guiserver.log you should see what files are served for each request
<hatch> frankban:  yeah so it turns out it was a really bad cache
<hatch> :/ sorry
<frankban> hatch: np
<hatch> the good news is that the machine view actually creates machines
<hatch> :)
<frankban> hatch: :-) I supposed that, shouldn't I ?
<hatch> haha - you never know :)
<hatch> looks like the callbacks are passed the new 'real' ids
<hatch> so this will work
<hatch> it's only passed the new id though
<hatch> but that's enough
<hatch> *sigh* one of my thunderbolt ports is loose...apple quality....
<marcoceppi> who owns charmworld? is it you guys or is it still sinzui & co>
<rick_h__> marcoceppi: it's us still
<rick_h__> marcoceppi: what's up?
<marcoceppi> rick_h__: nm, just been building a new review queue, doesn't affect you guys much but I'll cc your list as a heads up
<rick_h__> marcoceppi: cool thanks. 
<rick_h__> marcoceppi: also, we'd love to chat. I'm not sure how much jcastro/arosales told you about our upcoming plans to deprecate charmworld
<marcoceppi> I got the low down from you guys last sprint
<marcoceppi> which is why I started the new review queue
<rick_h__> marcoceppi: so would like to chat with you and tvansteenburgh around a migration path from charmworldlib in the nearish future
<rick_h__> marcoceppi: cool
<marcoceppi> rick_h__: yeah, that too
<rick_h__> marcoceppi: and curious how the review queue stuff is to work in a 'juju publish' world (sans LP)
<hatch> oo new review queue nice
<marcoceppi> rick_h__: I'm building a login system using Ubuntu/Launchpad SSO, when taht happens you'll just submit a new request for review there and we'll build plugins to map wherethe soruce for that charm is held to monitor merge req
<marcoceppi> but it's going to need some thinking/work
<marcoceppi> already building in gh support to monitor the mirrors
<rick_h__> marcoceppi: yea, that's what we need to sync up on. In a publish world there's no promise of vcs info there
<marcoceppi> yeah, now that it's sinking in, I can already see a glaring hole-in-the-head for how we maintain promulgated charms :)
<rick_h__> marcoceppi: yea, we want to sync up and solve those issues ahead of the game if possible
 * marcoceppi nods
<marcoceppi> want to do that sometime this week?
<rick_h__> marcoceppi: sounds good, /me checks calendar
<rick_h__> marcoceppi: pretty open Tues/Wed or Friday here
<marcoceppi> Tues work well for me
<rick_h__> marcoceppi: k, added a meeting with you and tim
<hatch> rick_h__:  I sent an email to luca and peeps, I forgot to add that I think it should be pre-MV 1.0, thoughts?
<rick_h__> hatch: looking
<rick_h__> hatch: yea, there's some thoughts on onboarding from back when MV was designed. 
<rick_h__> hatch: and it's a known thing they're looking at as the notifications are too transient and we talked about them during the sprint
<rick_h__> hatch: so I don't think your email is a surprise or anything. 
<hatch> ahh ok good - I was just sitting there, going "umm this change should be instant" heh
<rick_h__> hatch: and it's something to get right before launch for sure
<hatch> then "oh duh"
<hatch> TIL getById uses an internal id map which doesn't get updated in lazy model lists when you update the id in the model and there are no util methods to do so
<rick_h__> heh, good lesson to know :)
<hatch> looks like I'll have to write a util method to fix that
<hatch> time to patch YUI
<hatch> I was stepping through the delta stuff going ....umm why is this id not being picked up by getById.... heh
<hatch> ok taking lunch bbl
<urulama> good night, jujugui, have a great rest of the day
<bac> see ya urulama-afk
<kadams54> guihelp: need a code review only (no QA) for: https://github.com/juju/juju-gui/pull/503
<Makyo> On it.
<kadams54> Makyo: thanks!
<Makyo> kadams54, mind taking a look at PR 502 in exchange?  It's tiny.
<kadams54> Makyo: yeah, will do.
<kadams54> Makyo: comment added.
<rick_h__> kadams54: looking
<Makyo> kadams54, thanks.  We don't have direction on what to do with the add container link, since that will be moving to the more menu soon; once there, we'll have direction on whether to remove or show as disabled.
<kadams54> Makyo: yeah, in reviewing the bug, it seemed ambiguous. rick_h__: do you know if the "more" menu is pre- or post-1.0?
<Makyo> kadams54, yeah, sorry, forgot to link the bug.
<kadams54> If it's post-1.0, it seems like we ought to get clarification.
<rick_h__> kadams54: pre
<kadams54> Ah good.
<rick_h__> kadams54: it's what we got the delay points for
<rick_h__> kadams54: the more menu and some other UX enhancements
<kadams54> rick_h__: basically the revamped MV design they showed us in London, right?
<rick_h__> kadams54: yep
<rick_h__> we want to release with the cleaner better UX out of the gate vs waiting to update it
<kadams54> Makyo: I'm fine with landing PR#502 then.
<kadams54> I'll add a comment to that effect in the PR.
<kadams54> Looks like huw's all over the more menus :-)
<rick_h__> yea, need to check on their status tonight
<hatch> bac:  so I just chatted with the local apple store (not a real apple store) and he said after they run a diagnostic on it, about 2 days to order the new logic board then 2-3h install - so not horrible, maybe you should look into it as well if you're having the same problem
<hatch> assuming of course you have a local apple repair shop heh
<bac> hatch: did they mention if there was a design change?
<hatch> there are reports of people with new machines with the same problem (he wasn't even surprised that this happened) so my guess is no
<hatch> guess logic boards are cheap for apple lol
<bac> seems like a pita if there is no reason to think it'll really fix the problem
<bac> i think your eraser solution is pretty elegant...
<hatch> lol - my warranty is up in December so I want to make sure it's fixed before that :)
<bac> yeah, mine is long gone
<hatch> applecare is really expensive, I wonder how much a logic board costs 
<hatch> $379 for 3 years....maybe it's worth it if it costs a lot to fix heh
<hatch> logic board from ifixit is almost $1k lol ouch
<hatch> I hope that's not the regular price haha
<hatch> ohh it's 3 years total, so only an additional 2 years for the extra $379.... almost $200/yr
<hatch> jujugui when trying to update an id of a lazy model object and the id already exists, would you expect it to throw? return false? return the object at that id?
<hatch> I'm thinking throw....but we don't really throw anywhere else...
<hatch> I'm thinking return false or return the new id if it was successful
<rick_h__> undefined vs false?
<hatch> does undefined signify that it didn't work? I'm thinking no because js fn's return undefined by default
<rick_h__> hatch: hmm, true
<rick_h__> I guess I like throw then tbh. You asked for something it cannot/will not do
<rick_h__> right?
<hatch> right, but I don't think YUI throws anywhere
<hatch> it just returns some value
<hatch> so you don't have to try/catch everywhere 
<hatch> I'd prefer throwing also :)
<hatch> but doesn't really follow a convention 
<rick_h__> meh, it's clear as day, error in the console, I'm +1 on throw if it's for our use anyway
<hatch> ok throw it is
<rick_h__> and if we want to upstream it I'd suggest we get feedback on upstream
<rick_h__>  /on/from
<hatch> nah - they will want tests and everything
<hatch> too much work to upstream it lol
 * rick_h__ leaves for the day before he starts anything :P
<hatch> (ok maybe that's just lazy) :P
<rick_h__> have a good night all
<hatch> hahaha
<hatch> cya, enjoy your night
<hatch> I'll ask huw about the widget
<rick_h__> yea, I'll be online sometime tnoight to bug him on that and his expenses
<hatch> oh ok cool
<rick_h__> thanks for the help
<Makyo> jujugui can I get another quick review on https://github.com/juju/juju-gui/pull/502 ?
<hatch> done
<hatch> ^ Makyo
<Makyo> Thanks hatch 
<Makyo> hatch,  do you have Privacy Badger installed?
<Makyo> It's blocking some github avatar URLs for me.
<bac> Makyo: i use ghostery.  is the badger newer, shinier, better?
<hatch> Makyo:  I don't 
<hatch> oo boy do I hate errors from within YUI
<hatch> wow....ok do not use Object.create(null) if you're going to ever use that object in YUI
<hatch> heh
<Makyo> jujugui anyone have the latest MV design handy?  I lost my tab :(
<hatch> sorry not here - I can't keep all their designs straight lol
<Makyo> It's a real problem
<Makyo> I'll do a temporary version, then fix it up tomorrow.
<hatch> I don't think the setCommitted and setUnCommitted methods are used in the tokens any longer
<rick_h__> Makyo: it's in the "Juju Gui" folder I think. THey keep the latest designs in the drive folder
<rick_h__> Makyo: https://drive.google.com/drive/u/1/#folders/0Bzj8yHKHrx6pNkVUTkNPd3RWNTQ/0BwDPGKe0SiMbU0RfOXZIXzJlODg/0B7XG_QBXNwY1V3B3dDNvYXJGRE0/0B7XG_QBXNwY1NEtGaHJYZGM4enM
<hatch> awww yeah got this working
<hatch> oh and look at that, just at EOD
<huwshimi> Morning
<hatch> ohhh look who decided to show up!
<hatch> :P morning
<huwshimi> :)
<huwshimi> hatch: How's the delta stuff coming along?
<hatch> good I just finished it - functionally complete anyways
<hatch> needs cleanup and tests now
<hatch> how we set the committed and uncommitted stuff needs to change into the models....not sure why it's a token level property
<huwshimi> Nice!
<hatch> yeah but now tokens stay uncommitted for a while while we wait for juju to ack the changeover haha
<hatch> so will need another ui state
<huwshimi> hatch: I guess that might be helped somewhat if there is a progress bar at the bottom, so you know things are happening
<hatch> yeah there are a few different approaches for sure
<hatch> I sent off an email to peeps about it
<hatch> well I'm stepping away for a bit
<hatch> huwshimi:  rick_h__ wanted to talk to you about where you were at with the widget
<hatch> just a heads up he'll be popping back in sometime tonight
<hatch> bbl
<huwshimi> hatch: I'm trying to figure out how to render the dummy element before it gets render for real
<hatch> not sure I understand?
<hatch> wana have a quick call?
<huwshimi> hatch: Well, I have to display a button, that turns into the real menu on hover, so I have to have some dummy elements that exist outside the widget
<hatch> that's not what I was suggesting 
<hatch> I was suggesting that each token had a ... which was visible when hovered
<hatch> when the user clicked the ... it would render the widget for the menu
<huwshimi> hatch: I know but rick said to do the init first, so I'm trying to get it to replace the elements rather than appending a new bouding box container
<huwshimi> Also, the ... menu is visible before hover
<hatch> ohh noo the ... is just a dumb dom element
<hatch> you don't need to render the widget
<hatch> you can instantiate it without rendering it
<hatch> then when someone clicks the .. it renders the widge
<hatch> t
<huwshimi> I know, but, I have to then get the inited widget to listen for the clikc on the dummy elemnt, but I can't because it creates it's own bounding box
<huwshimi> it's ok, I have it under control, it's just a pain :)
<huwshimi> Actually, you're correct, the more menu does appear on hover (despite what the mockups show)
<hatch> nooooooooo you put a delegate handler on the machine view container which then calls the tokens 'rendermenuwidget' method
<hatch> then you only have one event handler for infinite tokens
<huwshimi> Ah sure, that's a good idea
<hatch> :) 
<hatch> ok I'm really leaving for a bit now
<hatch> :) be back in like 45mins
<huwshimi> bye
#juju-gui 2014-08-19
<rick_h__> huwshimi: +1 to wht hatch said. Make the parent token deal with show/hide of the widget
<rick_h__> huwshimi: also heads up, I added a card, there's supposed to be a 'more menu' on each unit on hover as well. 
<rick_h__> huwshimi: I'm not sure how that works with this 'hover' thing though. it seems a bit messy
<rick_h__> huwshimi: but the idea is that's how we expose the 'destroy unit' control for each unit in a machine/container.
<huwshimi> rick_h__: OK, np
<rick_h__> huwshimi: also wanted to poke you about expenses
<huwshimi> rick_h__: Oh yes, thanks, I need to do that :)
<rick_h__> :)
<hatch> huwshimi:  if you'd like I can take a look at what you've got so far
<huwshimi> hatch, rick_h__: So, if the click handler is on the machine view, how do I figure out what object to attach the more menu to? Just do a bunch of dom queries? The parent could be an unplaced unit, a machine token, a container token, a unit on a container token, a column header etc.
<huwshimi> I guess on the dots icon I could attach a data-type="unplaced-unit" data-id='wordpress/0'
<hatch> huwshimi:  hey sorry I was outside
<hatch> yep you're correct
<hatch> that information will go along for the ride with the click event so you'll have it all available in the handler
<huwshimi> yuck
<huwshimi> ok :)
<hatch> huwshimi:  you can also query the parent
<hatch> e.currentTarget.ancestor('.token')
<hatch> for example
<hatch> but the former is much more performant
<hatch> because you don't need to do any additional queries 
<huwshimi> hatch: That's true, but I'd have to run through a bunch of different DOM queries till it matched the correct type
<hatch> the tokens aren't all identical?
<huwshimi>  The parent could be an unplaced unit, a machine token, a container token, a unit on a container token, a column header etc
<huwshimi> It's not just tokens ^
<hatch> right, but can't you tell what it is by querying the container of it? They don't all share a common class?
<huwshimi> Why would they?
<hatch> in any effect the 'best' is to include the metadata on the element being clicked
<huwshimi> yeah
<hatch> it's not yuck, it's really the most performant way of doing it
<hatch> at that point you can even instantiate the widget and render it all at once instead of instantiating when we render the machine view
<huwshimi> hatch: Well, it's going to require making sure we copy and paste the correct html all over the place
<huwshimi> (can't even use a partial as we need to set the data attributes)
<hatch> partials can have fields
<hatch> handlebar properties that is
<huwshimi> Oh
<huwshimi> Like a 'with foo=bar' kind of thing?
<hatch> no just like normal handlebars templates
<hatch> it would also be super easy to figure out if you forgot to add it to your respective template in the handler ` if (e.currentTarget.getAttribute('data-type') === '') { console.error('yo messed up dude'); }
<hatch> huwshimi:  http://yuilibrary.com/yui/docs/handlebars/#partials
<huwshimi> hatch: I guess on each view that will contain a more menu we could pass some standard attrs, 'more-menu-id' and 'more-menu-type' or something
<hatch> I don't understand
<hatch> the ... will be rendered in the token
<hatch> the token knows what kind it is
<hatch> and what it's id is
<hatch> so it can pass that into it's template when it generates the ...
<huwshimi> hatch: Yes, but it's not always a token!
<hatch> ok so the only special case is the headers?
<huwshimi> no
<hatch> what are the other areas where it needs to be shown that's not a token?
<huwshimi> well, there are three types of token to begin with
<hatch> ok that doesn't matter 
<hatch> each token will know what it is and what it's id is
<huwshimi> I know, but what I'm saying is we need to pass parameters with standard names so the partial can use them
<huwshimi> It's not a problem, it's just something we have to do
<hatch> oh right - but that can be within the token though
<hatch> nothing special needs to be passed around
<hatch> just data it already has
<huwshimi> I didn
<hatch> the header menus though could have individual listeners if that makes it easier
<hatch> there is only 2(3?) of them
<huwshimi> I'm not talking about passing that around, I'm just saying when we render the html we have to set the params, that's all
<hatch> ohh right
<hatch> we keep a reference to the token collections in the MV, right?
<huwshimi> yes
<huwshimi> so a trivial lookup once you have all the data
<hatch> excellent
<rick_h__> huwshimi: you can setup data on the init
<hatch> rick_h__:  thought you'd be interested to know I'm looking at typescript for the gui...ooooooo...... :) I ran into some type related issues doing this stuff today, would have been nice if we had them defined
<hatch> :)
<rick_h__> want types, do Go :P
<huwshimi> rick_h__: Differently to have them set through data-id data-type?
<hatch> rick_h__:  haha, go2js :D
<rick_h__> huwshimi: sorry, was thinking that the widget is init from the View and it knows who it is. 
<huwshimi> yeah :(
<rick_h__> huwshimi: but sounds like you guys had a long chat about things
<huwshimi> :)
<rick_h__> I'd have each token deal with it's own responsbiilty myself (until we hit a scale issue)
<hatch> I still think it should have a single menu which it just renders into the different spots so we only have to instantiate one :)
<rick_h__> though I'm very nervous on all this 'hover' stuff
<rick_h__> hatch: :(
<hatch> but I think I'm losing that battle lol
<rick_h__> hatch: but now you've basically got a global
 * hatch hands out flyers 
<hatch> well in the mv, yes, but there will only ever be a single tooltip window open at once
<rick_h__> hatch: I'm all for trying to cheat performance but I'm +1 on making it work in a clean way first and then optimize
<rick_h__> hatch: yea, but the complexity of it having to know about all 'types' it could be/etc is just so messy to me
 * huwshimi has no idea what to do now :)
<rick_h__> I'm going to talk with Luca about this hover stuff
<rick_h__> I think that's going to be a disaster, click is the way to go
<hatch> lol
<hatch> huwshimi:  do what you were already doing
<rick_h__> just have to figure out something for units
<huwshimi> hatch: Except that you and rick have different opinions :)
<rick_h__> huwshimi: sorry, don't mean to complicate this for you. 
<hatch> I had already stepped down on my idea in favour of meeting in the middle on having 1M click event handlers 
<rick_h__> heh, when we have the 1M machines/units we'll have other issues :P
<hatch> lol
<rick_h__> seriously though, we know how we'd optimize this stuff. It moves the same code up the stack one layer from token, to column, to MV itself. 
<rick_h__> but each one gives us a trade off of debugging/complexity it seems to me
<hatch> huwshimi:  each token instantiates its own menu, one click handler for all ...'s, render the menu when the handler says so
<huwshimi> OK, I'm going to abandon this for now and move onto something else
<rick_h__> huwshimi: hatch call?
<rick_h__> huwshimi: sorry, don't get frustrated with it :)
<hatch> :) sorry huwshimi it was a discussion, didn't mean to change your mind
<rick_h__> +1
<hatch> you were doing the right way
<huwshimi> rick_h__: It's not a problem, I just don't want to keep re-coding it :)
<rick_h__> this is just hatch and I going back/forth
<rick_h__> huwshimi: understood
<rick_h__> huwshimi: what are you implementing?
<huwshimi> rick_h__: I have not idea any more :)
<rick_h__> huwshimi: I didn't make out the final decision in the back trace
<rick_h__> https://plus.google.com/hangouts/_/gym44xuoo2zqrcqjpb2hdgfmhaa?authuser=1
<huwshimi> rick_h__: Maybe I should leave it for today and tomorrow you and hatch can make a plan, and then I'll implement that
<hatch> joining
<hatch> it was so nice and sunny there huwshimi
<hatch> haha
<huwshimi> :)
<huwshimi> hatch: This is a webcam of the city: http://www.rosebay.tased.edu.au/webcam/medium.jpg
<huwshimi> hatch: Most of the snow has melted
<hatch> huwshimi:  you have green grass.....there was no snow
<hatch> lol
<huwshimi> hatch: We really only have snow at the top of the mountain
<hatch> and wow, maybe I'll move there, I bet the kiteboarding on that lake would be awesome
<hatch> lake....ocean whichever :)
<huwshimi> that's actually a river up from the sea :)
<hatch> quite the river :)
<huwshimi> hatch: I live about the center of that shot
<huwshimi> You can kind of see my hosue
<hatch> better watch out, come winter I may just show up at your house :D
<hatch> I'll be on the news "some strange Canadian is going door to door asking for a huwshimi"
<huwshimi> :)
<huwshimi> hatch: It's winter here now, about 12C
<hatch> 22 here now, but you can feel winter is coming in the mornings
<hatch> the crisp morning air is starting
<huwshimi> pleasant
<hatch> yeah it's really nice, it's fly season though
<hatch> bleh 
<hatch> I think I prefer mosquitos 
<hatch> mosquitoes 
<huwshimi> hatch: Are they mexican mosquitoes?
<hatch> ours are the size of your spiders....
<hatch> lol
<hatch> not sure if that makes them mexican or not :)
<huwshimi> hatch: Every menu has a close-on-click-outside event, should I only attach this when the menu is opened and detached when it is closed?
<hatch> huwshimi:  yeah that would be best
<huwshimi> ok
<hatch> huwshimi:  since you're using widgets there is a bindUI method which you can call that you can use to attach your events, then you'll need to create an unBindUI method to do the opposite :)
<hatch> it would normally be done on destroy but we aren't destroying them
<huwshimi> yeah
<hatch> huwshimi:  I'm going to head out now, any q's or anything before I do?
<huwshimi> hatch: All good, Thanks for all your help!
<hatch> np, sorry to get you side tracked for a bit there :)
<hatch> have a good night
<hatch> cya
<urulama> frankban: morning
<frankban> urulama: hi
<frankban> urulama: I replied to your last review comment, thanks for the review!
<urulama> frankban: the archive size is ok then. and URL.Reference is to be resolved on the API level?
<frankban> urulama: we expect the url to be already resolved at the time meta endpoints are invoked
<urulama> frankban: thought so, just checking. thanks for the PR.
<frankban> urulama: cool, landing it
<urulama> frankban: the /meta/bundles-containing is probably similar to this one
<urulama> rogpeppe1: morning, sir :)
<rogpeppe1> urulama: yo!
<frankban> urulama: yeah, it has some similarities, and I think it could live in relations.go as well
<urulama> rogpeppe1: how was your extended weekend? 
<rogpeppe1> frankban: hiya
<rogpeppe1> urulama: very fine, thank you
<frankban> morning rogpeppe1 
<urulama> frankban: exactly, i think it could go there as well
<frankban> urulama: cool
<rogpeppe1> urulama: i'm in Whitby and there's a folk festival going on...
<urulama> rogpeppe1: uuuuu, sounds nice! doing any performaces?
<rogpeppe1> urulama: not really, a bit of playing for some sword dancers with one spot at the late night extra on friday night, but not too much
<urulama> rogpeppe1: i would love to get a picture of that, if possible :) i'll tell my boy, he'll love it (huge Zelda game fan and fan of swords)
<rogpeppe1> urulama: they're kinda strange swords
<rogpeppe1> urulama: they've got a handle at each end
 * urulama automatically associates UK with knights (of the round table) :)
<rogpeppe1> urulama: this kind of thing: https://www.youtube.com/watch?v=3WJKiMe-Czk
<urulama> rogpeppe1: wow, so many hands!
<rogpeppe1> urulama: it works well in small spaces - perfect for english pubs
<rogpeppe1> urulama, frankban: i'm updating the charm API document to cover PUT to the bulk request endpoints
<urulama> rogpeppe1: this one? PUT meta/$endpoint[$otherflags] 
<rogpeppe1> urulama: yup
<rogpeppe1> urulama: and the $id/any endpoint too
<urulama> rogpeppe1: if we update meta enpoint, the revision should bump up automatically, right? 
<rogpeppe1> urulama: my current thought is that is does not
<rogpeppe1> urulama: i think the revision should pertain to the archive, not the metadata
<urulama> rogpeppe1: but with changing the meta, one can change the interfaces that are required and exposed, which probably is a new version
<urulama> rogpeppe1: or config
<rogpeppe1> urulama: no, a PUT to the metadata cannot change any of the charm or bundle metadata
<rogpeppe1> urulama: the only thing we're going to allow a PUT to, for the moment, is extra-info
<urulama> rogpeppe1: aaaa, ok. then it makes sense
<rogpeppe1> urulama: if you want to update the charm or bundle metadata, you will need to upload a new archive
<urulama> jujugui: i'll be unavailable next hour as we have an induction session
<rogpeppe1> urulama: ok
<frankban> rogpeppe1: for expand-id, I am not sure by reading the spec if we want to return a 404 in the case the given URL cannot be resolved
<rogpeppe1> frankban: what do you think we should do?
<frankban> rogpeppe1: if we want to avoid changing the URL resolving in the router, then we can keep returning a 404. but we must change the second example in the spec
<frankban> (wordpress-34)
 * rogpeppe1 looks
<frankban> rogpeppe1: if we return a 404, when you provide a fully qualified URL I'd expect that URL to be included in the results
<rogpeppe1> frankban: interesting question
<rogpeppe1> frankban: currently, that would work ok
<rogpeppe1> frankban: as when the URL is fully specified, we don't make a round-trip to check that it's actually there
<frankban> rogpeppe1: yeah, so we have an inconsistency. precise/no-such-42 would return a 200-empty-list result, while just "no-such" a 404 not found error
<rogpeppe1> frankban: i wonder if we should return a 404 for any expand-id request that expands to no ids
<frankban> rogpeppe1: one solution could be returning a 404 if the list is empty
<frankban> heh
<frankban> rogpeppe1: here is the result: https://github.com/juju/charmstore/pull/76 I need to be afk for a while, see you later
<rogpeppe1> frankban: brilliant, thanks.
<rogpeppe1> frankban: looking
<urulama> rogpeppe1, frankban: wouldn't it make sense for expand-id on a fully qualified charm url to return 200 and the same url? why 404?
<urulama> rogpeppe1, frankban: and for any "no-such-charm", either with series or without, would result in 404
<rogpeppe1> urulama: what if the id is fully qualified, but there is no charm with that id?
<urulama> rogpeppe1: what sense does it make to expand-id on an id that does not exist?
<urulama> get non-exitising-name should return 404, get non-exiting-name/expand-id as well
<rogpeppe1> urulama: we need to define the API's behaviour in that case
<rogpeppe1> urulama: so expand-id on a fully qualified charm url might return 404 when there are no results, right?
<urulama> rogpeppe1: i would say so, because the ID itself in that url is not valid
<rogpeppe1> urulama: ok. i think that was the plan, so i'm not quite sure what you're suggesting.
<urulama> rogpeppe1: just jumping late into the conversation :) (and as i saw returning 200 on precise/no-such-42)
<rogpeppe1> urulama: that was frankban talking about previous behaviour, i think.
<urulama> rogpeppe1: regarding bson.M vs bson.D ... it is always better to use bson.M?
<rogpeppe1> urulama: I always use bson.D except when I actually need the map-like capabilities of bson.M
<rogpeppe1> urulama: creating a slice is cheaper than creating a map
<urulama> rogpeppe1: ok, tnx, noted ;)
<rick_h__> morning party people
<rick_h__> urulama: rogpeppe1 but with extra-info can we update that sans-upload?
<rogpeppe1> rick_h__: yes
<rick_h__> urulama: rogpeppe1 we're looking at using that mechanism to update charms with test results, etc
<rick_h__> ok cool 
<rogpeppe1> rick_h__: that's the raison d'etre of extra-info
<rick_h__> oh heh, needed to keep reading the history there you guys cover that :)
<frankban> rogpeppe1: should we use bson.D eve in the cases bson.M is more representative of the concept we are expressing? e.g. we need to map keys to values
<frankban> rogpeppe1: e.g. bson.M{"baseurl": id}
<rogpeppe1> frankban: if bson.M is providing some actual program-construction value, then by all means use it.
<rogpeppe1> frankban: but in general, bson.D is exactly equivalent in representation
<rogpeppe1> frankban: it represents a mapping of keys to values just like bson.M does
<rogpeppe1> frankban: but it's a little more efficient, so i prefer to use it, all other things being equal
<frankban> rogpeppe1: I read bson.M{"baseurl": id} slightly better than bson.D{{"baseurl", id}}, but perhaps it's just because I am used to express this kind of queries as a key/value, rather thank i[0]/i[1]
<rogpeppe1> frankban: yeah, bson.M is cognitively closer to what we're trying to represent, but i don't think that means we have to use it.
<frankban> rogpeppe1: in this case the query is really easy to read anyway, so I'll just make the change for efficiancy
<rogpeppe1> frankban: thanks
<frankban> efficiency even
<urulama> rogpeppe1, frankban: would this apply to the PR75 as well? I guess bson.M and bson.D are properly used there, but maybe take another look
 * rogpeppe1 looks at PR75
<rogpeppe1> frankban, urulama: yeah, i'd use bson.D there
<frankban> urulama: would you like to take a look at https://github.com/juju/charmstore/pull/76?
<rogpeppe1> frankban, urulama: in a very quick-and-dirty benchmark, bson.D is about twice as quick as bson.M: http://paste.ubuntu.com/8088225/
<urulama> frankban: i think that you and rogpeppe1 already covered it, so, i think its +1
<frankban> urulama: cool thanks
<frankban> rogpeppe1: I'd be interested in the meaning of "twice as quick" in the context of a full request/db query/response
<rogpeppe1> frankban: sure, it's probably lost in the noiser
<rogpeppe1> frankban: but it's nice to be efficient when there's no cost in doing so
<rogpeppe1> s/noiser/noise/
<frankban> rogpeppe1: +1 except in the cases there is some other cost, like readability. but perhaps it's just me, perhaps I am just not used to things like "}}}}," ;-)
<rogpeppe1> frankban: :-)
<rogpeppe1> frankban: i don't think it's too bad.
<rick_h__> frankban: can't you tell at a glance that's 5, no I mean 4 closing braces? :P
<frankban> heh
<rick_h__> frankban: if you get some downtime, think you can help jrwren_ out and peek at his merge proposals on quickstart this week?
<rick_h__> frankban: help clear out the slack stuff pending and might be good to see if it can land and make sure we get a final quickstart release for the cycle in the near future. 
 * urulama needs to grab some food
 * rick_h__ sends some leftovers to urulama 
<frankban> rick_h__: I remember I reviewed all those slack cards
<rick_h__> frankban: oh did you? awesome, I'll maybe bug jrwren_ about them then. 
<urulama> rick_h__: :D :D
<frankban> rick_h__: I did it before London. I did not receive other emails re those branches
<rick_h__> frankban: ok, I was just looking at the board and figured it might be cool to move those forward. I'll check up on it thanks.
<frankban> rick_h__: thank you
 * rogpeppe1 grabs some lunch too
<jrwren_> frankban: did you review them a second time? I've been delaying nagging you about them. I did address all 3.
<jrwren_> but since rick_h__ is nagging for me, I should probably nag.
<jrwren_> err, I mean asking ;]
<frankban> jrwren_: I reviewed them once, then did not receive any signal they are ready for re-review. If they are ready, I'll take another look at them asap
<jrwren_> frankban: Yes, please do.
<frankban> jrwren_: ok
<rick_h__> oh luca, o'buddy o'pal
<luca> rick_h__: heya :)
<rick_h__> luca: got time for a quick chat?
<luca> rick_h__: in a meeting for the next 2 hours
<rick_h__> I want to get your brain on it asap :)
<rick_h__> luca: ok, if you get free ping me otherwise we can chat tomorrow
<luca> rick_h__: will do
<rick_h__> ty much
<jcsackett> rick_h__: i see a bunch of cards in tracking for GUI, but they seem to be defects in our code (e.g we're not tracking another project) what's up with those?
<kadams54> rick_h__: got a question for you when you have a moment.
<rick_h__> jcsackett: I pulled them aside as I think they were worked on but not verified yet
<rick_h__> jcsackett: working on the board, will update htem
<rick_h__> kadams54: otp, will ping when off
<jcsackett> rick_h__: so i can tell you the one for "dispatched urls" had some investigation done, but we concluded it's blocked until we release MV 1.0, so we're rid of the ghost inspector. happy to chat with you about details if you want.
<rick_h__> jcsackett: ok cool, will move it back into the on deck
<rick_h__> jcsackett: can you update the bug with any notes to help getting it started and the MV 1.0 reasons/etc?
<rick_h__> kadams54: free, what's up?
<jcsackett> rick_h__: sure.
<frankban> rick_h__, bac: I'd like your opinion on https://code.launchpad.net/~evarlast/juju-quickstart/which-juju/+merge/227238 . Do you have a minute to take a look? thanks
<rick_h__> frankban: looking
<rick_h__> frankban: oh hmm, interesting. *thinking*
<rick_h__> frankban: jrwren_ so the issue is sudo $JUJU, so I'd just stop that. Don't allow it. It's an older scenario and we can say the feature isn't backwards compatible. 
<jrwren_> frankban: I completely missed that first comment.
<rick_h__> frankban: jrwren_ so if a user has $JUJU set and we need to 'sudo $JUJU' we output a warning and don't use it
<rick_h__> frankban: jrwren_ bac thoughts?
<frankban> rick_h__: sounds reasonable, given we have a use case for this feature. use a compiled version of juju? I am still worried about point 2) in my comments
<rick_h__> frankban: yea, I think with the call for testing and such we'll have to get past #2. For CI for instance, we'd easily use $JUJU=xxxx to test against upcoming Juju versions
<rick_h__> frankban: I'd not shout the feature from the hill tops, but I think it makes sense to support it
<jrwren_> I want the sudo feature for myself :)
<frankban> rick_h__, jrwren_, coll then +1
<jrwren_> I'd rather doc it with a giant warning or something.
<rick_h__> jrwren_: what for? We don't need sudo in modern lxc, this will be released in utopic quickstart, not any earlier versions
<jrwren_> rick_h__: quickstart local?
<jrwren_> rick_h__: err, just bootstrap local.
<rick_h__> jrwren_: yea, isn't the sudo requirement for local bootstrap gone?
<rick_h__> well, at least quickstart doing it
<rick_h__> juju deals with sudo now, we don't have to
<jrwren_> rick_h__: oh, but I see. yes, that is the difference.
<jrwren_> in that case I agree with all the concerns and I should update the PR.
<rick_h__> jrwren_: ok, let me know if I'm off in my thinking. 
<rick_h__> jrwren_: frankban ok, so we're +1 on ignore $JUJU on any sudo call paths, respecting it otherwise, and making sure we hide it from non-test users )
<rick_h__> :)
<jrwren_> rick_h__: No, I think the two points in frankban's initial comment are still important and shall be addressed.
<jrwren_> rick_h__: s/No/Yes/ :)
<frankban> rick_h__, jrwren_: added a new comment summarizing this chat
<rick_h__> ty frankban 
<rick_h__> thanks for the updates jrwren_, sorry for the complication. 
<rick_h__> and thanks for the good call/catch on sudo frankban!
<hatch> I just used local yesterday and needed to enter my pw
<hatch> on 1.20.1
<jrwren_> hatch: right. juju invoked sudo on your behalf. you didn't have to invoke juju with sudo, did you?
<hatch> jrwren_:  no, but I did have to type my pw
<hatch> so it still rquired sudo
<rick_h__> hatch: yes, but it's not quickstart's issue so it's not an attack vector
<hatch> every time i see "attack vector" I think of a top down airplane game
<hatch> pew pew
<rick_h__> pew!
<frankban> :-)
<frankban> jrwren_: https://code.launchpad.net/~evarlast/juju-quickstart/support-lxc-clone/+merge/227250 done
<jrwren_> frankban: thanks!
<rick_h__> jujugui call in 10, please update kanban
<luca> rick_h__: Iâm free for a call
<rick_h__> luca: standup time
<rick_h__> luca: can ping afterwards
<luca> rick_h__: ok
<rick_h__> jujugui call time in 2
<rick_h__> Makyo: kadams54 frankban ^
<rick_h__> antdillon: ^
<kadams54> joining
<rick_h__> doh!
<rick_h__> come on chrome, go go go
<rick_h__> geeze, what's a guy have to do to run a meeting around here?
<urulama> rick_h__: the FX are great :)
<rick_h__> man, I wish I had a recording of how I sounded :P
<kadams54> My inlaws had a problem with their landline phone awhile back. It would make them sound like a chipmunk, but only the person on the other end could hear it. It was also sporadic, so one minute you'd be having a normal conversation, the next, Alvin and the chipmunks.
<kadams54> It was awesome.
<rick_h__> hah
<jcsackett> so, if we have a machine with the only uncommitted unit of an uncommitted service, and we delete that machine, should we just reset the unit as an unplaced unit, or should we clear the service?
<rick_h__> jcsackett: I'd reset it as an unplaced unit
<rick_h__> and then they can remove it from there if they like
<jcsackett> rick_h__: ok, that was the way i was headed.
<frankban> jrwren_: reviewed the third branch, it looks good with minor changes, thank you
<hatch> luca:  hey the svg rendering bug you reported - was the image you had stitched together? The only way I can reproduce it is if one icon straddles the bottom of the browser so that only part of it is rendered
<hatch> so I can't get two icons to not render properly 
<luca> hatch: I didnât stitch them together, that just how they appear in the listing
<luca> hatch: Iâll send you another pic of the same bug
<luca> hatch: check you email
<hatch> thx
<luca> hatch: sent another too
<hatch> woah I haven't seen that one 
<luca> hatch: it might show it a little better
<luca> hatch: yeah, it all happened at the same time
<luca> hatch: it started during the London sprint
<hatch> *sigh* I've been researching chrome svg rendering bugs but I can't reproduce anything like this using any svg's that aren't ours
<jrwren_> frankban: thanks again.
<hatch> but they also don't happen in any other browser....
<luca> hatch: It seemed to happen when my browser updated
<luca> hatch: and it can be consistently reproduced on other peoples browsers in the web team
<hatch> luca:  yeah it's definitely a chrome bug, but nothing that matches this has been filed (and not subsequently fixed) and any other svg's but our icons don't exhibit the same problem
<luca> hatch: ok
<luca> hatch: so we canât fix it?
<hatch> luca it also seems to only happen with certain icons
<hatch> the wordpress icon for example is really bad, but the icon for ubuntu-repository-cache doesn't appear to exhibit the issue
<luca> hatch: yeah, I couldnât work out why it would effect some and not others
<hatch> I'll put my notes in the bug and we can revisit, I'm guessing there is something wrong with how some of the svg's are created
<hatch> and with how chrome's new rendering works
<luca> hatch: the MySQL icon on the service block doesnât respond the zoom, thats why it looks wrong
<luca> hatch: sent you another img
<hatch> odd I can't reproduce that one
<hatch> luca can you add these images to the bug?
<luca> sure
<hatch> thanks, it's very odd, even in osx with the same version of chrome i can't reproduce what you see
<hatch> I wonder if you have some extension which may be making it worse heh
<hatch> oops, I ate too many nibs
<rick_h__> hatch: I get it based on zoom levels sometimes. 
<rick_h__> hatch: it's not an extension, it seems something in chrome/svg resizing or something
<hatch> rick_h__:  right, I just can't reproduce the same issues so was just trying to find some reasoning behind that
<hatch> you'd think identical os's and browser versions would do the same thing haha
<rick_h__> hatch: heh
<rick_h__> I get it on linux in the dev edition
<hatch> Chrome in Ubuntu is such a mess
<rick_h__> :)
<hatch> when I drag a window it goes transparent
<urulama> jujugui: have a nice evening
<hatch> cya urulama
<hatch> u 2
<frankban> and you
 * rogpeppe1 is done for the day too.
<rogpeppe1> g'night all
<rick_h__> BradCrittenden: ?
<rick_h__> BradCrittenden: I bailed out, going to get lunch. 
<BradCrittenden> ok
<rick_h__> BradCrittenden: I think we should try to get some time with someone from #is
<bac> rt
<rick_h__> bac: I think you're right that the config and test fails, not sure if it ever passed tbh
<kadams54> hatch: Soâ¦ I need to query whether a radio button is selected. I know we *just* went through this a few months back, but I'm having a senior moment on the details.
<hatch> kadams54:  you have to loop through each one
<hatch> because phantomjs lameness
<bac> rick_h__: in the bug i see tom has added: the application topology is apache2 -> squid -> haproxy -> charmworld-app
<kadams54> hatch: Yeah, but it wasn't enough to check for the "checked" attribute because that doesn't change from what's set in the HTML.
<hatch> kadams54:  not the attribute, the js property
<hatch> input.get('checked')
<kadams54> Yeah, OK, that worksâ¦
<kadams54> Seems like last time things weren't that clean, but for this case :-)
 * hatch hangs head
<hatch> kadams54:  your modularization branch totally destroys my work from yesterday lol
<kadams54> Yay!
<kadams54> ;-)
<kadams54> What happened?
<hatch> I rewrote the methods you moved
<hatch> I just have to manually re-apply my commits
<hatch> kadams54:  did you make any changes to these methods or just moved them?
<kadams54> Just moved
<hatch> phew
<hatch> :)
<kadams54> hatch: just did a diff to make sure. I made one change for readability: https://pastebin.canonical.com/115591/
<hatch> ahh ok thanks, well that space doesn't exist anymore :)
<hatch> ok taking lunch, I'll fix this later
<hatch> bbl
<kadams54> hatch: ping me when you're back.
<rick_h__> bac: ok, that makes sense except that haproxy was exposed
<rick_h__> bac: oh, but you exposed that right?
<bac> rick_h__: yeah, i exposed haproxy myself which was a mistake
<rick_h__> bac: gotcha
<rick_h__> fabrice: !
<rick_h__> fabrice: who let you around here :P
<fabrice> it's public :)
<rick_h__> fabrice: hey, you still coming over here the 15th right?
<fabrice> yep !
<rick_h__> urulama: isn't around right now but need to introduce you guys :)
<rick_h__> fabrice: cool, you're the last one to join the party
<urulama> rick_h__: i am :)
<rick_h__> oh, he is 
<fabrice> yes I wish I could joined early but french laws are a pain !
<rick_h__> urulama: fabrice starts the 15 :P
<rick_h__> fabrice: gotcha, all good. Nice to see you hanging around
<urulama> fabrice: nice to meet you, and i understand you, i'm also from EU :)
<fabrice> where ?
<urulama> fabrice: slovenia
<rick_h__> heh, solvenia, france, UK, italy. The team's gone all internation
<rick_h__> hatch: and canada don't count :P
<rick_h__> international that is
<fabrice> you mean that american think Canada is a US state !
<rick_h__> the 51st! we've just not claimed it yet
<rick_h__> at least the good parts :P
<urulama> :)
<rick_h__> I hear toronto is kind of cool
<fabrice> I lived there 3 years and it is 
<urulama> fabrice: where in France do you live?
<fabrice> French Riviera in Grasse 
<rick_h__> man, france and italy. I need to get some wine shipments started from you and frankban :)
<rick_h__> be the impartial comparison to see what is better!
<hatch> rick_h__:  fabrice used to live in Canada :P so THERE!
<jrwren_> as lone mercan in that group,I'm aiming for a good cowboy nickname.
<rick_h__> hatch: he knew enough to get out!
<hatch> rick_h__:  yeah and he sure didn't go south :P
<rick_h__> jrwren_: I'm thinking something with john wayne in it
<jrwren_> rick_h__: yee haw!
<hatch> lol
<fabrice> I really like Canadians really nice people
<hatch> kadams54:  I'm back
<hatch> *snicker* 
<fabrice> urulama: Ljubljana?
<hatch> that can't be a real name
<urulama> fabrice: close (as everything is close here), Novo mesto
<urulama> hatch: it is, it's simple to say :)
<hatch> urulama:  lol suuuuure
<fabrice> tell the name of your town :)
<rick_h__> lol
<rick_h__> here we go
<hatch> Saskatoon Saskatchewan
<rick_h__> he makes up this place
<hatch> bahaha
<hatch> lol
<rick_h__> it's from a kids book, we're sure
<kadams54> guihelp: what's the right way to trigger a nav event? I did some grepping but didn't find any obvious examplesâ¦
<hatch> what's a nav event?
<hatch> like changeState?
<fabrice> Saskatchewan vs Ljubljana who will win the pronounciation game ?
<hatch> haha
<kadams54> In my cardâ¦ clicking on "View machines" needs to navigate to the machine view panel.
<hatch> yeah that's changeState
<hatch> kadams54:  in the inspector there is a changeState call in the scale up to show the mv
<hatch> look there
<urulama> fabrice: had to look up Grasse. I spent two weeks close, in the Sophia Antipolis Sciecnce Park, on a visit ... but was aaaages ago ... 
<hatch> looks beautiful there
<hatch> I vote there for the next sprint in the summer :)
<fabrice> great idea !
<urulama> hatch: remember, we had Lisbon, Budapest and Dublin, but ended up in Brussels. Don't suggest French riviera, we'll end up somewhere in Belarus :)
<fabrice> rick_h can take back some wine
<hatch> urulama:  hahahaha
<kadams54> Hmm, most of the changeState examples are setting stuff in sectionAâ¦ I'm guessing I need to set something for sectionB?
<rick_h__> urulama: :/ you're making the idea of 2wks there hard to get my head around
<hatch> kadams54: I wasn't kidding, it's right there :) https://github.com/juju/juju-gui/blob/develop/app/views/viewlets/scale-up.js#L155
<kadams54> hatch: hah, OK, I found it just about the same time.
<kadams54> Was temporarily put off by changeState stuff in service-inspector.jsâ¦
<kadams54> Excellent, thanks
<hatch> https://www.google.ca/maps/place/Grasse,+France/@43.523504,6.943188,3a,75y,90t/data=!3m5!1e2!3m3!1s7429787!2e1!3e10!4m2!3m1!1s0x12cc25fe3958edfb:0x117727988cf82e2d
<hatch> it's a little far away from Grasse, but we should have our sprint right here
<hatch> at this exact spot
 * hatch starts packing tent 
<kadams54> As long as there's power and wifi.
<bac> rick_h__: if you've got two weeks in brussels at least go to amsterdam for the weekend.  easy train ride.
<hatch> kadams54:  who needs either of those, pen and paper - planning spring! ;)
<hatch> sprint*
<urulama> rick_h__: you sure it's two weeks and that the coding/lead stuff don't overlap?
<kadams54> What's this about Brussels?
<kadams54> Is that the October sprint?
<rick_h__> urulama: so it's possible for me and maybe you it's two weeks, but TBD
<rick_h__> kadams54: it's not 100% yet, but looking likely
 * urulama starts to shiver on the thought of being in Brussels for 14 days ... 
<rick_h__> kadams54: working with 3 places to get space
<hatch> urulama:  what's wrong with brussels?
<urulama> hatch: you'll see :)
<rick_h__> hatch: your branch up for review? Seems to have went boom?
<urulama> hatch: or maybe you'll like it
<hatch> rick_h__:  huge conflict with the code kyle landed
<hatch> fixing now
<rick_h__> hatch: cool lty
<urulama> fabrice: anyway, happy that you'll join, fun times ahead
<kadams54> I live my life according to HTCWJâ¦
<kadams54> How To Conflict With Jeff
<fabrice> urulama: Thanks ! I am quite eager now to start
<fabrice> fun is always better
<hatch> kadams54:  it's clear you've been working with rick_h__ for too long then :P
<rick_h__> I like to lead by example 
<hatch> hahaha
<kadams54> Michiganders have always had aâ¦ specialâ¦ relationship with Canadians.
<hatch> it's an 18h travel time for me to get to brussels .....oh boy
<hatch> hopefully some better flights become available when it gets ironed out
<rick_h__> hatch: time to get a tablet
<hatch> rick_h__:  yeah - although Air Canada provides power plugs in their planes
<hatch> so keeps the laptop all charged up
<fabrice> Brussels is good I can speak French 
<hatch> I speak enough French to introduce myself to everyone
<hatch> then walk away 
<hatch> because that's all I have
<hatch> :D
<hatch> urulama: from a travel site """Wherever else you go in Belgium, allow at least a little time for BRUSSELS, which is undoubtedly one of Europeâs premier cities. Certainly, donât let its unjustified reputation as a dull, faceless centre of EU bureaucracy deter you:"""
<hatch> lol
<urulama> :)
<urulama> hatch: there are good sides of Brussels
<urulama> hatch: this one http://deliriumcafe.be
<urulama> :)
<fabrice> good beer too !
<urulama> jujugui: gn
<urulama> fabrice: see you around, and on 15.9. latest :)
<fabrice> have a nice evening/night
<fabrice> ttyt
<rick_h__> jujugui I'm out. Have a good night all.
<hatch> cya rick_h__ you too
<bac> later rick_h__
<hatch> jujugui they are working on the power again, and they said I will lose power soonish
<bac> hatch: don't you have a monster UPS?
<hatch> jujugui I'll need two reviews for https://github.com/juju/juju-gui/pull/504 plz and thanks
<kadams54> hatch: looking
<hatch> thanks
<kadams54> hatch: Oh this requires a real env. Sorry, myâ¦ umâ¦ keyboad is bustedâ¦ yeah, that's it. Totally does not work.
<kadams54> ;-)
<hatch> haha
<hatch> kadams54:  lxc env's are pretty fast
<kadams54> Yeahâ¦
<kadams54> This will be less painful once I get around to setting up a dedicated Ubuntu desktop.
<kadams54> But for now I have to run lxc within a VM
<kadams54> Or go ec2
<hatch> so we r going to lose power again here so I'm just going to call it quits for a couple hours until these guys are done, I'll be back on later to pick up the hours
<hatch> kadams54:  feel free to send me an email or just comment in the pr if you have any q's or anything
<kadams54> OK
<kadams54> Why are you losing power?
<hatch> kadams54:  they are installing fiber into our neighbourhood
<hatch> and the people drilled through all of the power lines when doing the directional drilling
<hatch> so the power company is going bit by bit fixing them 
<kadams54> Ah. This is what our area looks like right now: http://cl.ly/image/382F1E2v432O
<kadams54> So I'm not sure if we're going to keep power either :-)
<hatch> haha
<hatch> well best of luck to you :)
<hatch> bbl, cya
<huwshimi> Morning
#juju-gui 2014-08-20
<rick_h__> morning huwshimi 
<huwshimi> rick_h__: Hi :)
<hatch> huwshimi:  hey
<huwshimi> hatch: Hello!
<hatch> so did you end up figuring out your issue or do u want me to take a look?
<huwshimi> hatch: I haven't figured it out. It appears that when I attach the event it then gets triggered by the event's method that created it!
<hatch> clickoutside is a complicated and resource intensive event because it is a 'fake' event
<hatch> lemme pull down your code and take a look
<huwshimi> thanks!
<hatch> huwshimi:  do you guys get the show 'The Dome' there?
<huwshimi> hatch: Not that I know of
<hatch> count yourself lucky, it's horrible 
<hatch> some tv version of a steven king book - somehow it keeps getting renewed 
<huwshimi> :)
<hatch> huwshimi:  quite the issue we have here heh
<huwshimi> hatch: Yeah, fun times!
<hatch> so I have a fix, but it sucks
<hatch> if you wrap the clickoutside binding in a settimeout then it's ok 
<hatch> ohh I think I know how to fix it
<hatch> ok I was wrong lol
<huwshimi> hatch: oh :(
<hatch> the problem is how the clickoutside event handler works....
<hatch> it's a synthetic event 
<huwshimi> hatch: This is only an issue because the button that triggers the open is outside the menu
<huwshimi> (That's not something that we can change, however)
<huwshimi> hatch: Any other ideas?
<hatch> huwshimi:  yeah so I'm thinking that's what will have to be done
<huwshimi> hatch: The timeout?
<hatch> the clickoutside handler is just not written properly 
<hatch> well that was the wrong thing
<hatch> it's not written to be used as we are using it
<huwshimi> hatch: OK, well thanks for taking a look.
<hatch> huwshimi:  I guess right now in the interest of getting this landed is to render the menu for each token 
<hatch> er
<hatch> render the ... in the menu 
<hatch> then when it gets clicked, show the real menu
<hatch> it's a big performance smack but the real fix is going to take too much time
<huwshimi> hatch: swap out button with the real one?
<huwshimi> the
<hatch> no I mean the ... is part of the menu
<hatch> widget
<huwshimi> hatch: Oh, so just render everything all the time?
<hatch> when it's clicked then show the tooltip portion of the menu
<hatch> yeah I think that's going to be the only way this will work, because the clickoutside will capture everything on the various up, down, bubble event phases
<hatch> it doesn't filter them to only catch one way unfortunately
<huwshimi> :(
<hatch> it can be written to work as intended
<hatch> unfortunately it'll take too long and I think we'd like to get this landed heh
<huwshimi> hatch: Oh, I have a solution.
<huwshimi> let me push this up
<huwshimi> hatch: https://github.com/huwshimi/juju-gui/commit/370e1510bb44d483da21d36f82e9e477d09a578f
<hatch> looking
<huwshimi> actually that 'all' could be 'one'
<hatch> so I was thinking something like that, but it's touching the DOM x number of times 'just incase' 
<hatch> hmm
<hatch> huwshimi:  you know that's probably an alright idea if it uses a .one
<huwshimi> hatch: Yeah, so this: https://github.com/huwshimi/juju-gui/commit/afd157fe01fc39488f0727335cb69b457bbb4d53
<hatch> but it's a little bandaidie
<huwshimi> yeah
<huwshimi> hatch: Is it better than rendering all the widgets?
<hatch> much :)
<hatch> like orders of magnitude haha
<hatch> good work
<huwshimi> hatch: OK, I'm going to have some lunch and then add tests. This could probably do with another review tomorrow
<hatch> yep for sure I'll review it in the am
<hatch> thanks for staying on this :)
<huwshimi> hatch: Thanks for that!
<huwshimi> np
<huwshimi> thank you
<hatch> no problem
<rogpeppe1> urulama: morning!
<urulama> rogpeppe1: heya
<urulama> rogpeppe1: how are we doing today, sir?
<rogpeppe1> urulama: good thanks
<rogpeppe1> urulama: and you?
<urulama> rogpeppe1: a bit sleepy, but nothing that proper indian tea could not solve :) 
<rogpeppe1> urulama: :-)
<urulama> rogpeppe1: could you take a look at Jay's PR, please ... https://github.com/juju/charmstore/pull/77
<rogpeppe1> urulama: i'm just looking at it already
<rogpeppe1> urulama: reviewed
<urulama> rogpeppe1: thanks
<urulama> rogpeppe1: i've set him towards the baseURL yesterday, but it was too late in the night to actually review the code
 * urulama goes make some tea
<urulama> rogpeppe1: ping, when you are ready
<rogpeppe1> urulama: ok, one mo
<rogpeppe1> urulama: ping :-)
<urulama> https://plus.google.com/hangouts/_/canonical.com/roger-uros
<urulama> frankban, rogpeppe1: give me 5min please, there's a post-man at the door
<rogpeppe1> urulama: ok
<urulama> frankban: wonna join for a blobstore talk?
<frankban> urulama: sure
<frankban> urulama: link?
<urulama> https://plus.google.com/hangouts/_/canonical.com/roger-uros?hceid=dXJvcy5qb3Zhbm92aWNAY2Fub25pY2FsLmNvbQ.r0oegfsr6b313oqhn3br43ltqs
<urulama> oh, sorry
<urulama> frankban: https://plus.google.com/hangouts/_/canonical.com/blobstore?hceid=dXJvcy5qb3Zhbm92aWNAY2Fub25pY2FsLmNvbQ.i8ktli6o0tbmsbe5qmtk62eaik
<urulama> frankban, rogpeppe1: google does not like us :)
<rogpeppe1> urulama: we're back in...
<frankban> rogpeppe1: is it better to compare two *charm.Reference by value (e.g. *id1 == *id2) or by str repr (id1.String() == id2.Strng())?
<rogpeppe1> frankban: value
<frankban> rogpeppe1: cool thanks
<rick_h__> morning
<frankban> morning rick_h__ 
 * frankban lunches
<urulama> morning rick_h
<bac> morning
<rick_h__> morning bac
<urulama> rogpeppe1, frankban: wrote minutes about blobstore. please take a look if anything is missing, lots of topics were covered :)
<urulama> rick_h__: you have a minute to chat?
<rick_h__> bac: this was funny last night. https://twitter.com/chcholman/status/501906093136969729
<rick_h__> urulama: sure thing
<rogpeppe1> urulama: looking
<urulama> rick_h__: daily standup? https://plus.google.com/hangouts/_/canonical.com/daily-standup?hceid=cmljay5oYXJkaW5nQGNhbm9uaWNhbC5jb20.j0rk5d371ph8331ijtf48t2uj0
<rick_h__> loading
<urulama> rick_h__: https://plus.google.com/hangouts/_/g4sy3treomztkk367qiounpbg4a
<bac> rick_h__: so you know that person on twitter?
<urulama> rick_h__: the first one was "borked", hope the second one works
<rick_h__> urulama: trying
<rick_h__> bac: so she's in a city nearby and we 'know' each other by knowing some of the same tech people
<rick_h__> bac: never met
<rogpeppe1> urulama: i hadn't heard of CADF before
<urulama> rogpeppe1: ah, its just some standard for auditing in clouds
<rogpeppe1> urulama: have you got a good overview link by any chance?
 * rogpeppe1 is wary of standards
<frankban> urulama, rogpeppe1, guihelp: I need two reviews for https://github.com/juju/charmstore/pull/78 . anyone? thanks
<rogpeppe1> frankban: on it
<frankban> thanks
<urulama> frankban: will be on it after a short lunch
<frankban> urulama: thank you
<hatch> morning all
<rick_h__> morning hatch 
<hatch> kadams54:  so we also had a monstrous storm last night :) took the power out :)
<kadams54> yippee
<hatch> http://www.quora.com/How-good-is-YUI-as-an-open-source-JavaScript-library-compared-to-current-alternatives-2014?srid=dOo&share=1
<rick_h__> " But now that JavaScript itself will soon have a built in module system and loader, the way forward is to embrace ES6 modules.
<rick_h__> "
<rick_h__> "will soon" bothers me
<rick_h__> :( on the lack of noting the niceities of a deep event system, common api across code, etc. 
<rick_h__> but yea, it's running its course
<hatch> heh there is no way we'll be able to use es6 modules/loader any time soon
<hatch> maybe 1yr
<rick_h__> maybe
<hatch> My next personal project whatever that may be will not use YUI so I can try and find a good collection of modules to provide a similar functionality 
<hatch> so far I can't find anything that has the event stack :/
<hatch> those darn events.....
<hatch> maybe I could write something
<rick_h__> yea, I bet you still end up writing a lot more code
<rick_h__> it's kind of sad that there's not more of a desire to modernize YUI vs deprecate
<hatch> Y! is too busy buying mobile companies....lol
<luca> rick_h__: just rebooting
 * rick_h__ heads back to the house
<hatch> kadams54:  did you end up doing the review of my branch yet?
<kadams54> hatch: in progress. I'm also having problems with changeState in my branch.
<kadams54> So I'll finish off QAing yours and then pester you with state questions ;-)
<hatch> yeah sure np
<hatch> changeState is really easy to understand and debug once you wrap your head around how it works
<luca> hatch: jcastro kadams54 btw is the uncommitted progress icon just the yellow triangle? The yellow triangle technically means pending...
<hatch> luca:  right now there is no uncommitted progress icon
<hatch> there is the pending icon but that's after juju has ACK'd it and it's really pending
<hatch> but there is this odd place between uncommitted and the ACK
<hatch> which I have seen be up to 30s 
<hatch> where it's not pending or not uncommitted 
<rick_h__> jujugui call in 5
<rick_h__> or 4
<rick_h__> kanban away please
<urulama> rick_h__: i get "this party is over" :(
<rick_h__> jujgui https://plus.google.com/hangouts/_/gw35roelf4huu6vmyvyl3z6rgea?authuser=1 
<luca> hatch: I see, thanks
<rick_h__> see if this works
<hatch> I'm in the normal standup room
<hatch> with ant and matt
<rick_h__> ok, it's working now
<rick_h__> just doens't like me
<rick_h__> jujugui standup time!
<urulama> rick_h__: https://plus.google.com/hangouts/_/canonical.com/daily-standup?hceid=cmljay5oYXJkaW5nQGNhbm9uaWNhbC5jb20.j0rk5d371ph8331ijtf48t2uj0
<urulama> rick_h__: try this one
<rick_h__> bac: ^
<bac> oops
<bac> joining
<bac> having trouble
<hatch> rick_h__:  are all of the cards in the ready to code of equal priority? It seems like some of these may be able to be pushed to post 1.0 
<bac> jujugui: sorry, i cannot get into the hangout
<hatch> it's over
<hatch> :)
<bac> hatch: miss anything good
<bac> ?
<hatch> rick_h__:  did some break dancing to lady had a little lam
<hatch> lamb
<kadams54> guihelp: where is views.Templates originally defined/setup?
<rick_h__> hatch: we can debate over them
<rick_h__> hatch: but they all seemed 1.0 stuff when I looked monday
<rick_h__> kadams54: it's built from the /lib/templates or something, /me pulls up a browser to look
<rick_h__> kadams54: sorry, the things in app/templates is built into lib/templates.js as compiled handlebars
<rick_h__> kadams54: what are you trying to do?
<urulama> jujugui: bye, see you later
 * rick_h__ goes to get lunch
<hatch> jujugui do we have any assets or mockups for ""handle changes from the delta stream and alert with conflicts in ecs"" ?
<kadams54> not that I've seen
<rick_h__> hatch: no
<hatch> I can work on the backend of it np, but I'll send something to luca about it I guess
<rick_h__> hatch: yea, I think that card is one that breaks into smaller. we need to plan out where/how to keep the 3 results (current, ghost, delta) and how to resolve that
<hatch> yep ok on it
<rick_h__> hatch: thanks for the great qa notes on huw's branch!
<hatch> :) np
<Makyo> jujugui it appears we can't clear config changes, because we don't retain the old ones, just a list of what has changed.  Any thoughts?
<rick_h__> Makyo: chat with hatch as I think we need it for that as well
<hatch> hmm
<rick_h__> Makyo: hatch quick chat?
<hatch> yeah.....standup?
 * rick_h__ will try again wheee
<hatch> if it says it has ended just click refresh a couple times
<rick_h__> went to FF
<frankban> rogpeppe1: so, should we return nil, nil in a meta endpoint if, for instance, it makes sense only for charms and a bundle is passed?
<frankban> rogpeppe1: IIUC, if the meta result is nill, then the result is not included in meta when include is used
<rogpeppe1> frankban: yes, that's right.
 * rogpeppe1 needs to stop now. wedding anniversary requires prompt stopping :)
<rogpeppe1> g'night all
<frankban> rogpeppe1: good night
<rick_h__> happy anniv rogpeppe1 !
<hatch> jcsackett:  thnks for the review, I replied
<hatch> kadams54:  review?
<kadams54> hatch: yeah, still wrestling with a local env
<hatch> hmm, what issues are you having? I've probably had it before haha
<kadams54> hatch: the behavior was funky when I ran through, so I wanted to verify and make sure it wasn't just my setup.
<hatch> oh ok, what was happening?
<kadams54> hatch: the machine would go through OK, but the bare metal container would be left as uncommitted state. I had to force a re-render on the container token before it properly displayed the state.
<hatch> oh ok that's possibly a real bug
<hatch> actually probably is
<kadams54> hatch: So I ran through the QA instructions, deployed, confirmed, waited, then saw the machine change from uncommitted to deployed. But the container stayed as uncommitted.
<hatch> the uncommitted state rendering is kind of implemented funky
<hatch> the bare metal cannot be uncommitted so that's definitely a bug
<kadams54> As far as my local env woesâ¦ I think it's the same thing jcsackett's seen. I've run the juju set command, it seems to run successfully, then I refresh in the web browser and nothing is running anymore.
<kadams54> Annnnnddd now it works fine. Of course.
<hatch> are you juju setting the source?
<jcsackett> kadams54: on precise you have to use sha to set the source. 
<jcsackett> On trusty you can use branch. 
<hatch> it takes time to pull down and build the source
<kadams54> Hmm, I'm on precise, but it just worked with the branchâ¦
<hatch> and what jcsackett just said
<hatch> ( which I also learnt just recently)
<kadams54> hatch: yeah, I gave it 10 minutes :-)
<jcsackett> hatch, I'm not sure I'm +1 with your reply; you say it's overkill to put update id on the machine list, but that's the only place you use the method. 
<jcsackett> Seems like overkill to patch, to me. 
<hatch> I just figure because it's a limitation of the library and not of our code it should go to the lib
<hatch> kadams54:  can you write that bug in the PR and I'll look into it after lunch
<jcsackett> I agree it's unnecessary to create our own extension, but can't you just add update I'd for the machine list? We already have one as an object, right?
<kadams54> hatch: Yeah, now that I've finally managed to confirm it :-)
<kadams54> hatch: FYI, I added the changeState code pretty much as it is in scale-up.js, for navigating to machine viewâ¦ but it seems to do nothing. That is, if you're in service view when you click on the link, you'll still be in service view.
<hatch> jcsackett:  no LML has an internal ID map which is only updated on add and remove so you cannot update the id of a LML object and still have it functional 
<jcsackett> Aaaah. 
<jcsackett> That's the missing part of info. 
<hatch> kadams54: does the service view bubble the change up to the browser.js?
<hatch> jcsackett:  oh sorry :) 
<hatch> I'll add that to the PR
<kadams54> Ah, good question. I'll make sure it does.
<hatch> kadams54:  typically you will include the steps to reproduce the QA failure
<hatch> even though I know how....just for good measure
<jcsackett> ok. hatch, knowing that, I'm good. Can you add a test for the patch's added method, though?
<hatch> jcsackett:  I can
<hatch> plz add to the PR
<kadams54> hatch: done.
<jcsackett> Will do. Thanks, hatch. 
<hatch> thanks - I'll get on that right after lunch
<hatch> I'm trying to figure out a good strategy to port the gui to Dart without rewriting :D
 * rick_h__ runs away night all!
<hatch> cya rick_h__
<hatch> oh that was like 25mins ago
<hatch> heh
<lazyPower> heyyyyyy hatch
<hatch> wassup boi!
<lazyPower> Wanna be a peach and proof something for me? (rough video cut, but almost done)
<hatch> yeah sure 
<hatch> I'm just finishing up a review
<lazyPower> https://www.youtube.com/watch?v=CEfFy6tODrQ knew I could count count on ya! ty ty
<lazyPower> oooo you're doing a charm review?
<hatch> haha no, js review
<hatch> lazyPower:  I'll start looking at it in about 5
<lazyPower> no rush :) and ooohhh yeah. i almost got excited there for a second.
<hatch> lazyPower:  your quiet...
<hatch> can you preamp the audio?
<lazyPower> that has been preamped
<lazyPower> Whats your youtube volume at perchance?
<lazyPower> i preamped it and ran it through a compressor
<hatch> 100% heh
<lazyPower> wow
<hatch> and my laptop is also at 100%
<lazyPower> really?
<lazyPower> oi
<hatch> :) maybe it's just my computer
<hatch> I'm running in a vm
<lazyPower> let me solicit additional feedback - you're on mac right?
<hatch> I'm on a mac, in Ubuntu
<hatch> lol
<hatch> maybe my soundcard default volume is set to low :)
<hatch> anyways, continuing
<lazyPower> hatch: ty for the feedback though - if i need to up the amps on the audio i'll try to do that on teh final copy
<lazyPower> s/amps/decibels/
<hatch> lazyPower:  notes pm'd
<lazyPower> Thanks man! Much appreciated.
<hatch> anytime :)
<hatch> When it's done let me know so I can spread it among my network too
<hatch> anything to get the juju love out there
<jcsackett> hatch: how does one turn the simulator off in gui?
<jcsackett> it's massively mucking me up.
<hatch> ctrl s
<jcsackett> thank you.
<hatch> "One does not simply....turn the simulator off"
 * jcsackett sort of wants the simulator off by default
<hatch> jcsackett:  you can also set it to off in the config-debug.js file
<jcsackett> yes, but then i have to fix that before i commit.
<hatch> I've been asking for that but always get voted down
<jcsackett> i might bring it up on friday (again)
<hatch> come to the dark siiiide
 * hatch hands you a pin
<jcsackett> it is *so* annoying when you're dealing with machine creation/unit creation etc.
<hatch> yop
<hatch> I'll +1 your vote to banish
<hatch> now and convince others behind closed doors like a good politician and make it look like a true democracy when we vote
<hatch> lol
<hatch> rofl
<hatch> oh I crack myself up
 * jcsackett laughs
<huwshimi> Morning
<hatch> morning huwshimi
<hatch> lots of comments on your branch but good to land once those are taken care of (they are all tidy up things)
<rick_h__> morning hju
<rick_h__> mornin huwshimi 
<rick_h__> tab completion works better when you type correctly :/
<huwshimi> haha
<hatch> :D
<huwshimi> rick_h__: If you happen to have the time, I'd love another review of the more menu: https://github.com/juju/juju-gui/pull/498
<rick_h__> huwshimi: will look in a sec here. 
<hatch> huwshimi:  thanks for making those fixes
<hatch> be sure to rebase before landing :)
<huwshimi> hatch: Thanks for the review, yeah, lots of changes in there :)
<hatch> heh mine is the same, I'm going to have to have fun rebasing that one
#juju-gui 2014-08-21
<rick_h__> huwshimi: reviewed
<rick_h__> huwshimi: thanks!
<huwshimi> rick_h__: Thankyou
 * huwshimi looking
<rick_h__> urulama: go to bed!
<rick_h__> :P
<frankban> rogpeppe1: monring, I updated the branch with your (great) suggestions, would you like to take anothe rlook?
<frankban> another even
<rogpeppe1> frankban: looking
<rogpeppe1> frankban: morning too, BTW!
<frankban> thanks
<urulama> oh, hey there frankban, rogpeppe1
<frankban> morning urulama 
<rogpeppe1> frankban, urulama: is your Go install from a PPA? I'd like to sort out the godeps problem that was mentioned on the list last night.
<rogpeppe1> urulama: hiya!
<frankban> looking
<urulama> rogpeppe1: i can create new VM with go from PPA if needed
<rogpeppe1> urulama: i'd be interested to see what happens when you do that, so yes please
<urulama> rogpeppe1: made a note for the task, will do after lunch. if needed sooner, np
<frankban> rogpeppe1: 2:1.2.1-2ubuntu1 from trusty
<frankban> is there a ppa for 1.3>
<frankban> ?
<urulama> frankban: btw, Go on homebrew was bumped to 1.3.1 ...
<rogpeppe1> frankban: have you run gofmt on your branch?
<frankban> rogpeppe1: sublime usually gofmt each time I save
<rogpeppe1> frankban: hmm, i guess that comments mean that fields don't line up. interesting.
<frankban> rogpeppe1: comments in a struct definition? yeah 
<urulama> frankban: gosublime package?
<frankban> urulama: yes
<frankban> urulama: it's pretty cool, the only downside is that I started not caring about indentation/white spaces also when writing python or javascript, feeling sad each time I realize saving does not fix everything for me
<urulama> frankban: good to know, tnx. I use the same package.
<rogpeppe1> frankban: re-reviewed. thanks for making the changes.
<frankban> rogpeppe1: thanks for the re-review
<rogpeppe1> frankban: np
<urulama> rogpeppe1, frankban: we can make a search query on a name for a charm over Charm.Meta.Name, but there is no such equivalent with bundles like Bundle.BundleData.Name, only through BaseURL
<urulama> rogpeppe1, frankban: the question is - did i miss something with the bundle name?
<urulama> rogpeppe1, frankban: or we actually don't have one?
<frankban> urulama: we don't have a bundle name as a separate concept, we have the bundle URL
<rogpeppe1> urulama: frankly, having the charm name inside its metadata was a mistake
<rogpeppe1> urulama: but that's what we've got, so we leave it there
<rogpeppe1> urulama: the actual name of the charm is defined by its id, as frankban says
<urulama> rogpeppe1: ok, so the proper way would be to not use Charm.Meta.name at all, but just IDs in both cases
<rogpeppe1> urulama: yes
<urulama> rogpeppe1: got my answer, tnx
<urulama> rogpeppe1: so, if i upload a charm trusty/mywordpress, but that has a name theirWordpress, and when i search for myWordpress, the resulting charm would show the name theirWordpress in the GUI?
<rogpeppe1> urulama: i'm not sure. it depends on the GUI logic
<rogpeppe1> urulama: it *shouldn't* do
<urulama> rogpeppe1: :D
<rogpeppe1> urulama: one possibility is that we could refuse uploads of charms where the metadata name doesn't match the actual name
<urulama> rogpeppe1: was thinking the same thing, but then, it would be better for not requiring the name at all and just add it in code
<urulama> if we need to have Charm.Meta.Name nonempty
<rogpeppe1> urulama: i don't think we can fill in Charm.Meta.Name ourselves, unfortunately
<rogpeppe1> urulama: because i think it's important to have the charm metadata be an exact reflection of what you get if you fetch the metadata.yaml file from the archive
<rogpeppe1> urulama: and we can't change that
<rick_h__> morning wheee
 * urulama lunches
<frankban> jrwren_: morning, how is it going with the quickstart branches?
<jrwren_> frankban: on the back burner.
<frankban> jrwren_: ok
<rick_h__> frankban: jrwren_ let's check with urulama if it's ok to make that the goal for friday though please. 
<rick_h__> frankban: jrwren_ urulama actually feature freeze is today
<rick_h__> frankban: jrwren_ urulama can we get those done up and a release out?
<rick_h__> sorry, I should have looked at that earlier this week
<jrwren_> rick_h__: quickstart?  sure.
<rick_h__> urulama: is that ok with you if I steal jrwren_ to get that updated today and out?
 * urulama starts singing "Aaaaall by myseeeeeelf ...."
<jrwren_> lol
<urulama> rick_h__, jrwren_: sure, np
<rick_h__> urulama: ty much
<urulama> rick_h__: frankban as well, right. So with rogpeppe1 out tomorrow, i'll go back to QA part of the story. It's all fine.
<rick_h__> urulama: it's all good, I think getting the search docs/etc together is +1 and it sounds like there's some back/forth going on
<rick_h__> urulama: so I'd not change up plans really on that front?
<rick_h__> or maybe I'm misunderstanding. 
<urulama> rick_h__: i'm always an optimist that i'll have time to code :D
<rick_h__> hah
<frankban> rick_h__: I was thinking about white listing: are we still ok with the plan given that 1) it does not prevent people to use the hooks/ dir as a mp3 repo and 2) in the future, we possibly have the same problem with resources?
<rick_h__> frankban: let's punt on whitelisting until we know how the zip access holds up under pressure
<rick_h__> frankban: I think that's the main driver we had before that we don't have now, disk space of uncompressed files laying around
<rick_h__> frankban: we can reevaluate it as a whole closer to release time once we've used it more.
<frankban> rick_h__: so, IIUC no white listing for now?
<rick_h__> frankban: correct
<frankban> rick_h__: +1 cool
<rick_h__> you've convinved me :)
<rick_h__> well you and urulama 
<frankban> :-)
<jrwren_> :( whitelist sounded so fun.
 * rick_h__ goes to start the morning now that morning calls are through. biab
<jrwren_> I'm not sure what to do with this: https://code.launchpad.net/~evarlast/juju-quickstart/support-lxc-clone/+merge/227250
<jrwren_> frankban: ^
<frankban> jrwren_: what's the problem?
<jrwren_> nevermind. launchpad is foreign.
<jrwren_> frankban: updated: https://code.launchpad.net/~evarlast/juju-quickstart/support-lxc-clone/+merge/227250  its marked approve already. I don't know what next step is.
<frankban> jrwren_: looking
<frankban> jrwren_: looking at https://juju.ubuntu.com/docs/config-LXC.html#fast-lxc-creation it seems that on certain platforms lxc-clone defaults to true
<jrwren_> frankban: which is why I didn't specify originally.
<frankban> jrwren_: can't we just provide that information in quickstart? "LXC clone is enabled by default for Trusty and above, and disabled for earlier Ubuntu releases."
<jrwren_> frankban: whatever you want.
<frankban> jrwren_: thank you
<frankban> jrwren_: other than that, you can go ahead and land it. we use lbox for quickstart, so I'd suggest to just "lbox propose" and then "lbox submit" the branch
<jrwren_> ok
<bac> rick_h__: i'm in 1:1 hangout
<rick_h__> bac: doh sorry
<hatch> lazyPower: hey do you have a link to the talk by Jamie Windsor?
<jcsackett> jujugui: can someone confirm a bug for me? want to make sure i haven't got something weirdly local going on.
<hatch> sure
<lazyPower> hatch: https://www.youtube.com/watch?v=hYt0E84kYUI
<jcsackett> hatch: cool. on develop, with mv flag, deploy a service and immediately commit (so autodeploy).
<rick_h__> it shouldn't do that now, kadams updated to stop it
<rick_h__> jcsackett: we need to do the follow up to block the 'confirm' and add a UI there
<rick_h__> jcsackett: I think that's what he's working on currently
<jcsackett> rick_h__: ok, so we know we have an issue?
<hatch> lazyPower:  cool thanks
<jcsackett> b/c right now i see an uncommitted unit hang around.
<rick_h__> jcsackett: sorry, I guess what's the issue? 
<rick_h__> jcsackett: we know and kadams has a card in progress around completing work there
<hatch> haha I was waiting for the actual issue description (and it never game :'( )
<jcsackett> rick_h__: ok, didn't realize summary and UX changes included that.
<rick_h__> jcsackett: so yes, after trying it I see that it doesn't deploy 
<rick_h__> jcsackett: so this is expected
<jcsackett> rick_h__: dig.
<hatch> ohh 
<hatch> yeah
<rick_h__> jcsackett: it's WIP I guess
<hatch> expected
<hatch> :)
<jcsackett> rick_h__: all good, just making sure. it complicated QA locally for my branch, and then i saw it on develop, and then i was like "huh"?
<rick_h__> jcsackett: understood
<rick_h__> sorry for the distraction :)
<rick_h__> distraction around your QA that is
<jcsackett> rick_h__: all good. i'm just happy i didn't a) cause a bug and b) somehow screw up my develop branch.
<jcsackett> since, y'know, it wouldn't *remotely* be the first time i'd done that.
<rick_h__> jujugui call in 10 please kanban
<hatch> rick_h__:  can huws branch land?
<rick_h__> hatch: I don't think so, the callback of the items seems broken?
<rick_h__> hatch: I wanted to chat with you about that this morning, after the standup?:
<bac> jujugui: regrets, i have another meeting and won't make the standup
<rick_h__> bac: summary of your stuff, is you came, you saw, you debugged?
<rick_h__> bac: what's the progress of the slack update?
<hatch> rick_h__:  oh ok, it worked perfect after he made the changes from my review
<bac> rick_h__: i have submitted it for review but gotten no bites yet.  will ping tom.
<rick_h__> hatch: yea, I'm :/ on the way it's working but maybe I'm not following something
<hatch> I'll pull it down and take a look
<rick_h__> bac: rgr ty for the update
<rick_h__> jujugui call in 1 or now, go go go
<rick_h__> antdillon: around for call?
<rick_h__> kadams54: there he is
<kadams54> joiningâ¦
<kadams54> Chrome apparently needs a restart
<hatch> urulama: Parallels 10 is now available :)
<urulama> hatch: already in use ;)
<hatch> urulama:  haha nice - I'm skeptical, I'll wait a bit lol
<hatch> although the upgrade from 8 to 9 was painless
<urulama> jujugui: the inital search doc was shared with everyone. it's a live doc. jrwren_ and bac please take a look next week, as we might start working on search part
 * bac looks
<urulama> hatch: at least 14.04 works out of the box now :D
<bac> jujugui: azure sent out email about rolling reboots tomorrow and the next day.  may affect our CI. (not sure if everyone gets those mails.)
<urulama> hatch: and it does fill slightly faster
<bac> let me know if it goes wonky
<urulama> hatch: feel even
<hatch> urulama: the only real problem I'm having with 14.04 is that the audio is really quiet - also I can't quite get my keybindings correct but that's probably just me being crazy
<jrwren_> frankban: updated: https://code.launchpad.net/~evarlast/juju-quickstart/which-juju/+merge/227238 & https://codereview.appspot.com/132770043
<frankban> jrwren_: looking
<urulama> hatch: +1 on keybindings
<urulama> jujgui: cu tomorrow
<frankban> jrwren_: reviewed, https://codereview.appspot.com/132770043/ . please ping me if something is not clear. I am trying to proceed with the quickstart release so I did not have time to further investigate
<jrwren_> frankban: thanks.
<frankban> jrwren_: also note that Rietveld allows you to reply in line and/or mark requested changes as done while working on the branch. This really helps keeping track of what's done
<frankban> jrwren_: then, when you are ready, you can just "lbox propose" again
 * rick_h__ takes lunch time
<hatch> kadams54:  you have the worst internet :)
<kadams54> ?
<hatch> might be time to upgrade to dialup
<hatch> you ping timeout all the time
<kadams54> Ah
<hatch> lazyPower:  is there a juju plugin to allow `juju export` to work on lxc?
<hatch> say I want to run juju-gui in a local deployment but allow someone external on the net to access it (assuming they can access my primary machine)
<rick_h__> hatch: you'd have to map that IP out to the internet
<hatch> rick_h__:  yeah I was hoping for a juju plugin to do it for me - and assume that the outside could access a specified port on my machine
<rick_h__> hatch: it has to do your router/etc so not sure how it would do that
<hatch> rick_h__:  well assume my router will allow acces to my machine on port 8888 
<hatch> I need to get the gui from the lxc instance to be available on my host machines port 8888
<hatch> that should be scritable 
<frankban> guihelp, I just noticed we no longer support saucy, is it correct
<frankban> ?
<rick_h__> frankban: yes
<hatch> heh that will cause an issue for our dev vagrant image :)
<hatch> which I'm pretty sure is saucy 
<rick_h__> EOL July 17, 2014
<frankban> rick_h__: are we supposed to QA quickstrat on utopic?
<rick_h__> https://wiki.ubuntu.com/Releases
<frankban> quickstart even
<rick_h__> frankban: hmm, we should as this is what we're heading to
<rick_h__> frankban: and OSC
<rick_h__> OSX
<rick_h__> anyone running utopic? BradCrittenden?
<frankban> rick_h__: yeah, osx is on the list. we should change the QA instructions and readme for quickstart: we need to remove saucy and add utopic
<rick_h__> frankban: adding a card for it now
<frankban> rick_h__: I prepared quickstart for release with two quick branches and packages for v1.4.2 are being built now. It's my EOD so I'd like to pass the release to someone else (in the case it's not ok for me to continue tomorrow morning).
<rick_h__> frankban: rgr, are the release process docs there? I'll get BradCrittenden and jrwren_ to help track things up. 
<rick_h__> frankban: thanks for getting that going and have a good night!
<frankban> rick_h__: what we need to do is 1) wait for the packages to be published (https://code.launchpad.net/~juju-gui/+archive/ubuntu/quickstart-beta/+packages)
<frankban> 2) QA on trusty and utopic (pre release QA is described in the HACKING file)
<frankban> 3) copy the PPA packages to juju/stable PPA 4) "make release" -> PyPI
<frankban> 5) make and test the homebrew release
<frankban> 6) add a release tag to trunk and have a drink
<frankban> rick_h__: ^^^
<rick_h__> woot thanks frankban 
<lazyPower> hatch: its possible but not with teh default setup
<lazyPower> i wrote a blog post about this
<frankban> rick_h__: thank you
<lazyPower> hatch: http://blog.dasroot.net/making-juju-visible-on-your-lan/
<hatch> lazyPower:  thanks 
<hatch> kind of sucks
<hatch> :)
<lazyPower> yes, yes it does
<hatch> I.....hate......networking
<lazyPower> and that article was written against 12.04 - so it may have changed a bit. 
<lazyPower> I haven't revisited using LXC as my primary since i setup a VMAAS cluster
<lazyPower> but the networking was similar.  1 ETH device for my communication, 1 ETH device as a bridge adapter for the VMAAS cluster. same basic concept being applied.
 * rogpeppe1 is done for the day.
<rogpeppe1> happy weekends all, see y'all on tuesday!
<hatch> jcsackett:  ok, lots of comments heh,
<hatch> mind responding then I'll take another look 
<hatch> lazyPower: couldn't a juju plugin just use sshuttle to forward the services ip and port to some supplied port on the host?
<hatch> I know that's not probably how plugins are supposed to work, buuuuuut
<lazyPower> hatch: contributions are welcome ;)
<hatch> does that sound like it's a valid solution though?
<lazyPower> i dont think sshuttle works like that
<lazyPower> it might, but i'm not terriblyf amiliar with using it as a proxy binding for services like that - i'd think you'd have better luck using UFW rulesets
<lazyPower> er, IPTables rather
<lazyPower> but in any case, that gets hairy, and its not going to work 100% of the time, as networking is a complicated monkey to just assume a particular use case and run with.
<hatch> hmm, I used to frequently use `ssh` to create a tunnel between an lxc instance and the host machine for testing
<hatch> I never tried to get that out of the host machine though...
<lazyPower> the only good way i can see to do it, is to create a bridge adapter and handle host routing that way.
<lazyPower> and its not bullet proof
<hatch> *sigh* networking shouldn't be this hard heh
<BradCrittenden> rick_h__: i have a utopic vm but don't run it daily.  can spin up for testing
<rick_h__> bac: appreciate it, qa'ing the quickstart packages on trusty now
<rick_h__> bac: even just a quick lxc setup for utopic might work
<bac> rick_h__: perhaps, but i've got this vm just sitting here...
<rick_h__> bac: ok cool
<jcsackett> hatch: was grabbing lunch. looking at your comments now.
<kadams54> hatch: https://github.com/kadams54/juju-gui/blob/develop/app/views/viewlets/service-overview.js#L467
<kadams54> I'm guessing this is why my changeState event isn't bubbling up to browser.js?
<hatch> kadams54:  looking
<hatch> kadams54:  does it look like events fired from the deployer bar would hit the browser?
<hatch> browser.js
<hatch> I'm not familiar with where it's instantiated 
<kadams54> The DeployerBarView is created by app.js
<kadams54> Which would make it a peer to browser.js?
<hatch> no 
<kadams54> Not really sure how subapps work
<hatch> browser.js is a totally different app 
<hatch> lemme take alook
<jcsackett> do we actually need to maintain the subapps idea? are we ever going to have more, and do we gain much by having browser separated like that anymore?
<hatch> jcsackett:  yeah - we don't have to rewrite it now :) in fact I was going to propose an idea where we have more 'subapps' but at a much higher level
<hatch> haven't thought it through yet
<rick_h__> jcsackett: the reasons on that were a couple fold I can tell you about in our call later
<jcsackett> rick_h__: cool.
<hatch> kadams54:  in _renderDeployerBarView, after we instantiate the deployer bar add `this.deployerBar.addTarget(this);` 
<hatch> that 'might' make it work
<hatch> at least give it a try
<kadams54> k
<hatch> if not I can guide you through a real fix
<hatch> why is the machine-view-panel in /widgets? lol
<rick_h__> because we agreed Y.Widget does not == Widget in a generic sense :P
<hatch> if mv is a widget then......daayyyyymmmmnnnn
<rick_h__> well, it didn't start out like this :P
<rick_h__> you forget this stuff started 5 months ago 
<rick_h__> it's bee a long long ride
<rick_h__> patches welcome hah
<hatch> lol
<hatch> oh man bare metal tokens are so messed up
<hatch> kadams54:  this is quite the bug you found....
<kadams54> *sigh*
<hatch> I might have to defer
<hatch> it's actually an issue with how bare metal containers are rendered
<hatch> it wasn't an issue before because we just cleared out the model
<hatch> so it was all re-rendered
<rick_h__> huh? I thought this was around 'auto place' in the summary?
<rick_h__> what's it got to do with bare metal containers?
<hatch> rick_h__:  I'm referring to the bug he found in my branch
<rick_h__> oh
<hatch> kadams54:  would you be ok if I punted on that bug, landed this and then fixed it as an immediate follow-up?  Because it's actually an existing condition
<kadams54> Sure.
<hatch> thanks I'll update the PR accordingly
<hatch> card created
<rick_h__> kadams54: call time
<hatch> Makyo:  because of this issue I created two cards at the bottom of Project 1 wrt the config changed stuff, feel free to take them as I will be pre-disposed for today likely
<hatch> kadams54:  did that fix work?
<kadams54> hatch: Yeah, it worked, thanks.
<hatch> great
<hatch> jcsackett:  replies to your replies :)
<hatch> I'm going to grab some lunch now
<jcsackett> hatch: so, i see it modifying the model to set the deleted flat, but otherwise just creating records.
<jcsackett> hatch: i can maybe see an argument about the `delete unit.machine` bit, but not the whole method.
 * bac afk for a bit
<hatch> back
<rick_h__> go get him jcsackett!
 * jcsackett laughs
<jcsackett> hatch: you up for a quick chat?
<rick_h__> guihelp anyone know how to 'copy packages' to another ppa?
<hatch> jcsackett:  so anywhere in the application which decides it wants to delete a machine has to then duplicate the code in that method elsewhere? 
<hatch> yeah sure, just lemme get the dogs inside
<jcsackett> hatch: cool.
<jcsackett> hatch: standup room, when you're ready. :)
<hatch> omw
<jcsackett> i will confess, when rick_h__ jumped in i was worried i was about to be huwed. :p
<hatch> hahahahaha
<hatch> huwed
<rick_h__> lol
<hatch> that's so a thing new
<hatch> now*
 * kadams54 feels clueless
<kadams54> What's a "huwing"?
<hatch> when you do your branch
<hatch> get it reviewed and make changes
<hatch> then rick_h__ comes in and changes the implementation 
<hatch> so maybe "huwing" should be rewriting code
<hatch> lol
<rick_h__> :P
<hatch> kadams54: is your card in review the one in coding?
<rick_h__> I can't help it I have opinions that occassionly are useful
<kadams54> Not any more :-)
<hatch> haha thx
<kadams54> guihelp: Looking for reviews on https://github.com/juju/juju-gui/pull/506
<hatch> kadams54:  doing it
<kadams54> Awesome
<jcsackett> kadams54: i'll be your second review if i can put you as the second for mine (once i get done with being reviewed by hatch)
<kadams54> jcsackett: Deal.
<jcsackett> awesome. :)
<hatch> kadams54:  done - one comment you can look into 
<jcsackett> hatch: so, unhappy moment--if i remove the units in the ECS, i have no way of getting at them to add them to unplaced units in the machine view. :/
<hatch> jcsackett:  shouldn't you be able to call the 'render unplaced units' method and it'll update the list?
<jcsackett> ...maybe.
<jcsackett> i'm dubious, but that might work.
<hatch> _renderUnplacedUnits is what it's called
<hatch> it might need to be upgraded to check if it's already rendered it though...
<hatch> agile......
<hatch> lol
 * jcsackett groans
<rick_h__> ruh roh
<jcsackett> well, it seems to need some sort of magic to let a unittoken be back in it once it's palced.
<jcsackett> so, the problem is that once you assign the unit, it's no longer in this.get(unitTokens), which is what the renderUnplaced thing uses.
<hatch> http://i.dailymail.co.uk/i/pix/2012/10/27/article-0-15B4ABD0000005DC-0_634x376.jpg
<jcsackett>  /me laughs
<hatch> lol love that pic
<jcsackett> yeah, when we place a unit, we remove it from unit tokens; so i'm going to need to a) figure out why delete unit.machine isn't picked up as a change to a unit for that event, and b, wire that handler up to add it back to the unitTokens.
<jcsackett> so...this is probably not landing today.
<hatch> jcsackett:  well....
<hatch> so maybe what you do is leave it the way you had it, with a bug about this functionality - because that should really be rendering the unplaced units by parsing the model
<rick_h__> jcsackett: sounds like you're on a good path there.
<jcsackett> rick_h__: the "not landing today" path or the "fuck it, land it this way with a bug" path? :p
<rick_h__> if you need to pause a card to fix something first there's nothing wrong with that
<rick_h__> I sometimes think we need to do that more than the 'land with issues and I pinky swear to make it better next' thing
<jcsackett> rick_h__: i don't know that this is really fixing something else, per se. i think its within scope for this card.
<jcsackett> as long as we're all comfortable with this card hanging out for another day.
<jcsackett> :p
<rick_h__> jcsackett: right, I meant you're on the right path with the event wiring
<jcsackett> i am, to be clear, b/c this does seem better.
<jcsackett> yeah.
<rick_h__> jcsackett: +1, good fix using the right model ftw
<jcsackett> but, i need to not look at it for a bit. :p kadams54, your PR ready for a second review?
<kadams54> jcsackett: yup, have at it. And yours?
<rick_h__> jcsackett: it's close to EOD, put it away for the night
<hatch> jcsackett:  ok awesome....thanks
<rick_h__> speaking of, going to step away until calls start back up in an hour
<rick_h__> biab
<jcsackett> kadams54: tomorrow for mine. :p
<hatch> ok now what was I doing before all these reviews....
<hatch> besides jammin to Hardwell 
<jcsackett> hatch: it's always fun to regain state after reviews, isn't it? :p
<bac> rick_h__: i'm doing the quickstart QA on utopic now.  sorry for the delay
<hatch> jcsackett:  haha yep
<rick_h__> bac: ok, let me know if you find anything asap.
<hatch> You know you live in the prairies when this tweet is a thing....... https://twitter.com/SKGov/status/502545556389236737
<kadams54> I've been waiting for that crop report!
<kadams54> Good to hear the farmers are busy desiccating.
<hatch> haha
<hatch> there is actually a 'crop report' on one of the radio stations as a show
<hatch> I mean.....99% of the land here that's not covered by trees is farm land sooooo it stands to reason it would be an important part of the economy
<hatch> still comical 
<hatch> I think I'm going to become an ophthalmologist - one is in the news for billing $2.2M last year......
<hatch> average is $1.02M/year
<jrwren_> hatch: what kind of crops over there?
<hatch> what's your poison? ;)
<hatch> mostly grains
<jrwren_> hatch: barley. Can you get me a deal?
<hatch> lol maybe
<hatch> barley is hardcore
<jrwren_> I'm hoping for like $20/bushel
<hatch> umm I think it's like $3 right now.....
<hatch> so yeah....$20...deal!
<jrwren_> $3/bushel?!?!
<hatch> Oct Barley: unchanged at $2.683 USD or $2.975 CDN
<jrwren_> zomg, I should so buy.
<jrwren_> do you know what they charge at the brew store?
<jrwren_> its like $50!!!
<hatch> haha, bagging it into a fancy bag is expensive! 
<jrwren_> so is malting
<hatch> probably not $47 expensive mind you
<hatch> you can buy a metric tonne for $140 lol
<jrwren_> this is going to be me, but with barley: http://thedailywtf.com/Articles/Special-Delivery.aspx
<hatch> hahaha
<hatch>  instead of virtually trading 28,000 tons of coal, Brad had somehow ended up with 28,000 tons of real coal.
<hatch> hahahahaha
<bac> that story does look fishy
<bac> Brad may be a doofus, but "1".lower() != "true"
<bac> what am i missing?
<jcsackett> bac: the story was debunked a few years ago along with a bunch of other dailywtf stories.
<bac> jcsackett: but but but, they could've at least made it internally consistent
<jcsackett> bac, actually, i think it is.
<bac> how's that?
<bac> so the confirm for physical delivery came back as a '1'
<jcsackett> right, and that .lower() doesn't equal "true".
<jcsackett> so if you're setting a flag to stop, you'll se false, and go "ok, no physical delivery, we're good"
<jcsackett> right?
<bac> right, so on the originator's side physicalDelivery is False, so ... so they think it is consistent.  gotcha
<jcsackett> i mean, it's still a load of crap, but it's consistent crap. :p
<bac> :)
<bac> and, once again, brad is the butt of the joke.  it all started with "Rocky Horror"
<urulama> rick_h__: ping?
<rick_h__> urulama: pong
<urulama> rick_h__: hey there
<bac> rick_h__: i'm still working my way through the QA.  everything is fine so far.
<rick_h__> bac: ty
<bac> rick_h__: i declare quickstar 1.4.2 yar on utopic
<rick_h__> bac: cool because I got it released and smoser uploaded it a while ago. Thanks for safety checking it out
<rick_h__> I really appreciate the check
<bac> np
 * rick_h__ needs to start to add these release milestones to his calendar
<huwshimi> Morning
<rick_h__> morning huwshimi 
<hatch> morning huwshimi
<huwshimi> hatch: Call?
<huwshimi> rick_h__, hatch: How do I pass the correct 'this' to a callback? http://paste.ubuntu.com/8110037/
<hatch> huwshimi:  you want the context from the token?
<hatch> myFunction.bind(this)
<huwshimi> hatch: Yeah
<hatch> function() {}.bind(this)
<huwshimi> hatch: So this would work? this._handleMoveIconClick.bind(this)
<hatch> that will create a bound version of that function and return it
<hatch> yep
<hatch> if you want to stub that method however for tests
<hatch> you'll have to do it BEFORE that bind is called
<hatch> because bind() actually returns another method which is bound to a specific context
<huwshimi> hatch: Brilliant, that worked :)
<hatch> if that makes sense....
<hatch> :)
<huwshimi> makes sense
#juju-gui 2014-08-22
<huwshimi> rick_h__, hatch: Changes are up! https://github.com/juju/juju-gui/pull/498
<rick_h__> huwshimi: you split on -, but the template doesn't have a - in the class?
<rick_h__> huwshimi: commented to be more clear
<huwshimi> rick_h__: The class gets prebuilt in the render step: https://github.com/juju/juju-gui/pull/498/files#diff-9dcc1a3a6fc72b434afc0c7c14ec9556R108
<huwshimi> rick_h__: So you end up with classes such as moreMenuItem-0, moreMenuItem-1 etc.
<rick_h__> huwshimi: ah, gotcha
<rick_h__> huwshimi: cool, missed it thanks
<huwshimi> np
<rick_h__> huwshimi: comment on a test but looks good apart from that
<huwshimi> rick_h__: Great, I'll take a look
<rick_h__> huwshimi: thanks for the updates!
<huwshimi> rick_h__: No problems!
<huwshimi> rick_h__: Like this? https://github.com/huwshimi/juju-gui/commit/f252894d6ce4c2763444f7ae4242b8e1a32380e0
<huwshimi> rick_h__: I have to duck out for a minute to do my tax, but if that last change is all good is it time for a rebase and a shipit?
<hatch> huwshimi:  I'm back, did you need any reviews or anything?
<huwshimi> hatch: You could do a final check over the changes I made this morning ( the callback stuff)
<hatch> sure I'm just doing homework now heh
<huwshimi> :)
<hatch> huwshimi:  one comment
<hatch> I was going to comment on some of the label stuff as a joke but I thought you might throw your computer across the room
<hatch> :P
<huwshimi> hatch: I would have gone over to your house
<huwshimi> hatch: shipit?
<hatch> yup
<huwshimi> yay!
<hatch> haha
<huwshimi> Merged!
<rick_h__> luca: <3 nice round of bugs thanks
<luca> rick_h__: hehe no problem.
 * frankban lunches
<hatch> mornin all
<rick_h__> sssshhhhhh hatch :P
<hatch> oh did I break the silence? 
<hatch> well serves ya'll right!!!! Should be all millin about n'such
<hatch> luca:  you were busy :) 
<hatch> good bug reports
<luca> hehe, morning hatch 
<hatch> the inspector health bar was interesting
<hatch> I'm not sure where that went
<luca> hatch: lol
<hatch> I created a card, it must be a styling issue
<luca> hatch: nice
 * hatch starts countdown until kadams54 timesout 
<kadams54> I'm actually at a friend's house today :-)
<jrwren_> I just loled at 'bad wolf' in the quickstart tests.
<jcsackett> jrwren_: "bad wolf" is all over.
<jcsackett> as it should be. :p
<jrwren_> this scares me.
<hatch> I feel left out, I've never understood "Bad wolf"
<jrwren_> hatch: its a Doctor Who thing.
<jrwren_> hatch: its really very silly.
<hatch> Ohh I've never watched enough DW to really catch the jokes
<hatch> I've been meaning to
<hatch> buuuuut such is life
<jrwren_> hatch: Its television.
<urulama> hatch: yes, you have to exterminate all free time.
<urulama> (doing it Dalek voice)
<hatch> my problem with tv is that I now have sports and activities for all kinds of weather, and hacking for times when I am feeling lazy....sooooo yeah
<hatch> lol
<jrwren_> that does not sound like a problem with tv... a solution maybe.
<hatch> haha true
<hatch> but I still pay that damn $60/mo for basic cable 
<hatch> because wasting money is fun!
<jrwren_> So cancel?
<kadams54> That's the great myth about cutting the cordâ¦
<kadams54> Who needs TV? We've got Netflix! Except Netflix comes via cableâ¦
<hatch> yeah we could save about $50 but cutting out cable but there is always the one show...
<hatch> I just wish I could buy them online for a reasonable price
<hatch> some are available on itunes and some are available on streaming from the proviers....but neither of those are very attractive when it costs you 50% of the monthly fee for one show
<frankban> guihelp: I need two reviews for https://github.com/juju/charmstore/pull/79 (charmstore/golang). Anyone? thanks!
<hatch> I'll review it but my review probably counts as a -1 :) I should really get more involved in that side
<frankban> hatch: appreciated
<frankban> urulama, jrwren_ ^^
<urulama> frankban: looking
<urulama> frankban: but i'll probably finish in the evening
<hatch> I have to say I am not a fan of the no-line-limit in golang scripts
<frankban> hatch: +1
<frankban> hatch: but when in Rome...
<hatch> ...visit the Panthenon?
<hatch> :P
<jrwren_> no-line-limit?
<hatch> jrwren_:  yeah like requiring a newline at 80char or 120char
<jrwren_> I follow 79 columns in any language in which I write.
<jrwren_> hatch: I'm not a fan either.
<jrwren_> sometimes gofmt makes it difficult to wrap where I want :(
<frankban> hatch: :-)
<hatch> yeah gofmt makes my code look like garbage lol, I'm THAT guy who disagrees with gofmt :D
<rick_h__> hatch: +1
<jrwren_> I feel you just have to learn to get along with go fmt
<hatch> jrwren_:  well, with any linter really :)
<hatch> gofmt is just.....well.....
<Makyo> jujugui call in 2
<frankban> hatch: it's still better than our js linter IMHO
<hatch> frankban:  haha, well as long as you stay away from chaining it's ok
<frankban> hatch: I only hate column indentation in structs, which makes me also unhappy when reviewing code
<hatch> ohh I like that :)
<rick_h__> antdillon: jcsackett standup
<jcsackett> already on. :p
<jcsackett> was on before you were, dude. :p
<bac> sorry rick_h__ i missed all of the license management discussion
<hatch> https://www.youtube.com/watch?v=kfVsfOSbJY0
<hatch> w00t http://ariya.ofilabs.com/2014/08/phantomjs-2-and-javascript-goodies.html
<hatch> mobile in Belgum http://www.belgacom.be/en/id_t_px_max/personal/products-and-services/proximus-telephony/paygo-max.html?tabnav=1
<urulama> hatch: wth! my ears!
<urulama> hatch: add WARNING to such links, please :)
<rick_h__> bac: let me know if you get a good connection and want the low-down
<rick_h__> bac: basically: make sure any new 3rd party libs have a license, look for those during reviews where someone adds a 3rd party dep
<hatch> urulama:  hahaha that's rick_h__'s friday theme song
<bac> rick_h__: yeah, i figured that would be the outcome.  thanks.
<rick_h__> what is my friday theme song?
<hatch> see the youtube link
<rick_h__> wtf, how did you get to this from me?
<rick_h__> or anything I said
<jrwren_> I prefer the starcraft 2 spoof.
<rick_h__> OMG this is awful
<rick_h__> maybe that's the comparison you were looking for
<hatch> I vote that you find a wig and a convertible 
<bac> hatch: wow the belgian pay/go is uncheap
<jrwren_> rick_h__: https://www.youtube.com/watch?v=jzq2O54LLIw  much better.
<hatch> bac only marginally more than three I think
<hatch> in the uk
<rick_h__> hatch: unlimited data on three though
<bac> hatch: but with three you got unlimited data.  is there a plan on that site i missed?
<bac> yeah, what rick_h__ siad
<bac> s/siad/said/
<hatch> jrwren_:  hahahaha this is awesome
<jrwren_> hatch: you follow sc2?
<hatch> jrwren_:  I used to be into it but it's been a while 
<hatch> after a while I hit my skill limit and would just get owned in every match
<jrwren_> hatch: big even in Detroit this weekend. I have tix. I'm going this evening :)
<hatch> so I kind of lost interest 
<hatch> oh cool :)
<hatch> jrwren_:  I've always thought the APM's were a little ridiculous, you don't need to click every damn tile on the way to where you want it to go just to get your APM up :) 
<jrwren_> hatch: I never bothered with that. I've been told its a means of practice so that you can micro at those speeds when needed.
<hatch> also a means to carpel tunnel
<hatch> lol
<jrwren_> frankban: updated https://code.launchpad.net/~evarlast/juju-quickstart/which-juju/+merge/227238 and https://codereview.appspot.com/132770043
 * rick_h__ runs for lunch
<kadams54> We've got a CI build that's been running for 16 hoursâ¦ http://ci.jujugui.org:8080/job/juju-gui/1668/
<hatch> heh nice
<hatch> kill it
<kadams54> I can kill it, but I suspect subsequent builds will fail
<kadams54> And they are
<kadams54> There's a hung thread that's hanging onto a port
<hatch> say what?
<kadams54> strike thatâ¦ the last two failures seem to be legit
<hatch> :)
<hatch> that's not to say it WONT break heh
<kadams54> We'll seeâ¦ if this build makes it to the selenium tests, I bet it fails.
<kadams54> Same thing happened to me earlier in the week and Rick had to kick something on the server.
<hatch> yeah it doesn't kill the pending server
<hatch> yup
<hatch> addrinuse
<hatch> rick_h__: can you kill the server in ci?
<hatch> kadams54:  you might as well kill all the runs
<rick_h__> hatch: sure thing
<hatch> rick_h__:  before you run away could you put instructions on what to do in this case?
<hatch> I'll set up my machine for it, I just don't want to end up with CI down for a week heh
<rick_h__> hatch: killed
<hatch> thanks ^ kadams54 
<rick_h__> who has ssh on there, jcsackett ?
<rick_h__> bac: but he's out next week as well I think
<rick_h__> oh, bac is around yay
<hatch> rick_h__:  I thought the keys were in the wiki? 
<rick_h__> hatch: not the ssh keys, those have to be added
<rick_h__> bac: and jcsackett I think can add keys and ssh in
<hatch> oh ok sounds good
<rick_h__> but all I do is 'ssh ubuntu@ci.jujugui.org' and then run 'ps' and look for the server and 'sudo kill XXXXX'
<hatch> oh ok simple enough thanks
<hatch> jcsackett:  hey are you around?
<frankban> jrwren_: reviewed
<frankban> done for the day, have a great weekend all!
<rick_h__> have fun frankban 
<jrwren_> frankban: thanks. Have a great weekend.
<rick_h__> ok, I'm out jujugui, have a good time and catch you all later
<kadams54> Have a good time rick_h__!
<hatch> cya rick_h__ enjoy your holiday
<jcsackett> hatch: i am around now.
<jcsackett> hatch: have been for a bit, actually, but i am bad about checking for hilights when i get back from lunch. :p
<hatch> jcsackett:  hey sorry
<hatch> the area I'm working on will likely conflict with the stuff you are doing
<hatch> do you have anything I can look at yet?
<hatch> if not no problem I'll just bench what I have until yours lands
<jcsackett> hatch: what are you poking at?
<jcsackett> i can push up one thing, and then the only other thing to beware of is not touching _onUnitChange in machine view panel.
<jcsackett> i *think*
#juju-gui 2014-08-24
<huwshimi> Morning
#juju-gui 2015-08-17
<marcoceppi> How do I get bundles from the charm store
<marcoceppi> api*
<marcoceppi> https://api.jujucharms.com/v4/openstack-telemetry/31/archive/bundle.yaml doesn't seem to work?
<marcoceppi> no alterations seemt to work either
<marcoceppi> go damnit
<marcoceppi> https://api.jujucharms.com/v4/bundle/openstack-telemetry-31/archive/bundle.yaml
<marcoceppi> why is this `juju quickstart openstack-telemetry/31` not `juju quickstart openstack-telemetry-31`
<rick_h_> marcoceppi: because we're working on making the commands match the urls. We can't do it fully with juju deploy until juju 2.0
<rick_h_> marcoceppi: so there's a mix of -rev vs /rev in things that are 'old juju' vs 'future juju'
<marcoceppi> rick_h_: so which URL will be the one we use?
<rick_h_> marcoceppi: /revision
<rick_h_> marcoceppi: the direction we have is name
<rick_h_> name/series
<rick_h_> name/series/revision
<marcoceppi> because this seems like an API thing, I'd expect openstack-telemetry/31/acrhi/..
<rick_h_> the revision will be diff for series
<rick_h_> e.g. only 5th one in ubuntu but 10th one in windows
<rick_h_> marcoceppi: so it's restful resource where each /segment/ adds another layer of specificity
<marcoceppi> well series is a charm notion, not really a bundle issue
<rick_h_> marcoceppi: true enough, sorry I read "acrhi/" as 'architecture' 
<marcoceppi> right, but the URL in quickstart is a / but the api is a -
<rick_h_> marcoceppi: yes, the api was made to work with current juju, quickstart is trying to set the tone for the forward looking when we moved to new bundles. 
<rick_h_> marcoceppi: honestly, if I had my way the api would be / as well
<rick_h_> marcoceppi: but I lost that battle and it'll change in v5 when we get juju 2.0
<marcoceppi> wish it was the same as the /
<marcoceppi> I've got to write a lot of additional code to support this now :(
<rick_h_> marcoceppi: how so?
<rick_h_> marcoceppi: what are you up to, maybe there's an easier way to handle it?
<marcoceppi> well there's like 20 diffrent bundle urls that could exist
<rick_h_> marcoceppi: from where? 
<marcoceppi> bundle: was used at one point, then cs:bundle/name-rev now there's just bundlename/rev
<marcoceppi> We're adding support to Google's PerfKit to be able to deploy benchmark bases with Juju
<rick_h_> marcoceppi: what are you testing/checking this in?
<rick_h_> marcoceppi: so you're checking for a user input to see if that's a bundle string?
<marcoceppi> yes
 * rick_h_ looks at code real quick
<marcoceppi> I've got a few bugs to file against the store page, if I try to highlight just the URL portions it highlights the entire quickstart string which is annoying from a user perspective, but that's just a ux papercut
<rick_h_> marcoceppi: k, what you're doing is done here: http://bazaar.launchpad.net/~juju-gui/juju-quickstart/trunk/view/head:/quickstart/models/bundles.py#L121
<rick_h_> marcoceppi: not sure if it's feasible to reuse that or not directly, but that handles the different cases for users in our use
<marcoceppi> rick_h_: thanks
<rick_h_> marcoceppi: https://github.com/juju/juju-bundlelib/blob/master/jujubundlelib/references.py#L47 might be a better more reusable thing 
<rick_h_> marcoceppi: you can see that quickstart is using that to help figure stuff out based on hints in the string
<rick_h_> marcoceppi: but I see you pain point there and agree, but the goal is trying to get to just 'juju deploy xxx' and xxx could be openstack-base
<rick_h_> marcoceppi: and everything 'just works' and we're on the road there but we're not able to shift it all at once without juju 2.0 and yet don't want to hold up and stick to the older urls until we get there. 
<rick_h_> marcoceppi: if there's somedthing we can do to help make it less painful please let us konw
<marcoceppi> rick_h_: having a consistent URL until everything switches would be my +1, tbh
<marcoceppi> "this state until juju 2.0" might as well be forever
<rick_h_> marcoceppi: right, but we had to make some changes to get jujucharms.com out the door, and having qujickstart match the site you copied the quickstart command from made sense
<rick_h_> marcoceppi: it's getting closer, we're working on bundles into core right now and by Oct should have juju deploy $quickstart value in there before EOY
<marcoceppi> I disagree, but it's subjective
<marcoceppi> cool, that's exciting to hear
<rick_h_> marcoceppi: understand
<marcoceppi> as soon as bundles can be deployed from juju API, the better
<rick_h_> marcoceppi: yea, the juju-bundlelib is getting prepped for core integration by getting ported to core here: https://github.com/juju/bundlechanges
<rick_h_> marcoceppi: so what we'll be working on is to embed the gui in juju core itself, we need juju core to know how to do a bundle deployment, so juju-bundlelib is going to get integrated into the juju api
<rick_h_> marcoceppi: so I understand your pain, but we are moving forward as best we can. 
<marcoceppi> rick_h_: are you guys rewriting juju-gui to golang?
<rick_h_> marcoceppi: no, but the juju-gui will be only html/JS/css and all the extra bits will be moved into juju core
<marcoceppi> rick_h_: AH, cool, very neat
<rick_h_> marcoceppi: right now the juju gui charm does some things in python (like handle bundles) and those have to diaf
<rick_h_> marcoceppi: so when there's a juju release, it'll have a gui JS that the juju state server can serve out
<rick_h_> marcoceppi: so every juju bootstrap, will have a 'juju gui' cli command that will open the gui on that state server
<marcoceppi> sweet, hot, action
<rick_h_> marcoceppi: so honestly, juju-quickstart will probably get deprecated along the way, or at least do a heck of a lot less
<rick_h_> marcoceppi: but fyi, all this will only be v4 bundles so we'll be working on a v3 bundle deprecation notice in the next week here. 
<rick_h_> as updating core to support multiple formats/etc is going to be out of scope so we can get it moved forward faster. 
<rick_h_> see http://blog.jujugui.org/2015/08/13/bundles-bundles-bundles/
<marcoceppi> rick_h_: sure, we're pretty cool with v4 format. However, what about storage and networking in bundles?
<rick_h_> marcoceppi: good question. No one's currently stepped up to update the format and we're working on porting existing work. Once that's good we can look at expanding it
<rick_h_> marcoceppi: but it'll have to be after we get current stuff working and integrated.
<rick_h_> marcoceppi: once we get it in place I could see getting more core folks involved and maybe making it a requirement for landing new features, but it's not been brought up/etc as we've just started the owrk since annecy
<marcoceppi> rick_h_: ack, our team is going to have a big requirement for at least storage soon, as soon as it goes GA
<rick_h_> marcoceppi: yea, understand. Just a case of only so much at a time can be done with the stuff on everyone's plate :/
#juju-gui 2015-08-20
<tvansteenburgh> rick_h_: v3 bundle files were supposed to be named `bundles.yaml` - does that change with v4?
<rick_h_> tvansteenburgh: yes, since there's only one bundle per file it's bundle.yaml
<tvansteenburgh> rick_h_: ta
<rick_h_> tvansteenburgh: thanks, searching the doc that's never specified. We'll get a patch to that. 
<tvansteenburgh> rick_h_: cheers, was about to submit a bug but i'll leave you to it
<rick_h_> tvansteenburgh: yea, we've been trying to get the docs updated but missed that. Apologies.
