#juju-gui 2012-11-05
<bac> morning
<sepi> Hi all. Quick q.
<sepi> According to the readme I neet to access https://localhost:8081/ws
<sepi> But I have nothing running on that port
<sepi> afer doing a "make server"
<bac> hi sepi
<sepi> hi I think I know my problem
<sepi> I needed to use the rapi-delta branch?
<bac> sepi: yes, either it or rapi-rollup
<bac> sepi: also, the url you pasted is only for the web socket to use.  to actually access the juju gui you would use http://localhost:8888
<bac> sepi: reading the README i see we don't mention that explicitly.  i'll fix that now.
<sepi> bac: thanks :)
<bac> np.  have fun, file bugs!
<gary_poster> hiya (was upgrading quantal on the desktop)
<bac> morning
<gary_poster> mattuk1972, hi.  I got your question about the service detail page.  The box has the two-radius rounded corners, right?  I'm pretty sure I see that.  Because of that, I want to confer with Makyo and see if we want to do this with svg.  I'll do that and get back to you
 * bac tries to remember which days we had dinner paid.
<gary_poster> heh
<gary_poster> good question
<gary_poster> many of them
<gary_poster> esp. second week
<mattuk1972> gary_poster: ok ty
<gary_poster> bcsaller, hi.  are you in nyc area, or just awake *really* early on west coast? :-)
<mattuk1972> gary_poster: also kapil mentioned that theres a requirement to simplify the svg's overall?
<bcsaller> gary_poster: in NYC
<bcsaller> :)
<bcsaller> as of last night
<gary_poster> bcsaller, cool :-) hope everything is ok for you there
<frankban> bac: these are my notes, maybe they can help: http://pastebin.ubuntu.com/1334735/
<bcsaller> Seems mostly back together here but there is still alot to be done in other spots
<gary_poster> mattuk1972, yes.  Chrome and IE10 support the service box svgs on the environment mage well.  iPad 3 is pretty good.  FF is very bad.  Apparently the FF problem is largely because of the service assets
<gary_poster> s/mage/page
<gary_poster> mattuk1972, Makyo investigated and reported that FF team is not being very responsive about SVG rendering issues
<mattuk1972> gary_poster: weird i did a lot of testing in all the browsers to make sure they rendered well and firefox was one of the best...
<gary_poster> So we need to do something to make that better.  I believe I heard hazmat (who is out this week) talked to Ivo about it so he may know details.  
<gary_poster> mattuk1972, it's not a matter of rendering accuracy. The problem is that once you draw the boxes, when you try to drag them around it is extremely slow
<mattuk1972> ahh
<bcsaller> gary_poster: I can still try to reach out to some of the people I know at Mozilla and see if they can make it more of a priority 
<gary_poster> mattuk1972, easy comparison: try http://uistage.jujucharms.com:8080/ in chrome and in ff to see diff
<gary_poster> at least in Ubuntu
<mattuk1972> but simplifying the svgs will fix it? removing any transparency?
<gary_poster> haven't tried in os x
<gary_poster> bcsaller, that's worth a try
<gary_poster> thank you
<mattuk1972> hmm seems to be ok in osx
<bcsaller> mattuk1972: removing the filters and layers will help alot, yes
<mattuk1972> i don't know how much of that i can do before it just becomes a plain grey box
<gary_poster> mattuk1972, that's my understanding.  It's probably worth some experimentation coordinating with us to both verify (I think that's already been done, and bcsaller is confirming) and to see how far we can go
<bac> frankban: your records matched my recollection.  thanks.
<benji> we can replace all the fancy shading with a png that just says "Firefox is slow."
<gary_poster> ack mattuk1972.  Maybe there's a simple experiment we can run to see if it this avenue is even workable?
<mattuk1972> to take it right down with a really basic shape just to see if it helps?
<bac> my DSL connection is flaky today, dropping and reconnecting every now and then.
<mattuk1972> lol benji
<gary_poster> I.e., you quickly simplify it to a point that you think might be representative "the least detail that would work visually/professionally"
<gary_poster> :-)
<gary_poster> mattuk1972, I think we have already established that a basic shape helps, right bcsaller?  The question is, is FF good enough that we can still have something professional looking, or not
<gary_poster> I think
<gary_poster> Since FF is the default browser in Ubuntu, it's kind of important
<bcsaller> gary_poster, mattuk1972: Yeah, simplfying the service boxes helps, but it comes at visual cost. We have options to help make FF faster, make the svgs simpler, add a drag mode that on FF turns them into outlines,  or switch FF to use larger static image assests that don't scale as well and try shrinking those down as needed. 
<bcsaller> I think an outline on drag could fix our issue at low cost 
<bcsaller> like an old school WM 
<gary_poster> heh
<gary_poster> yeah, not a bad idea
<gary_poster> interesting that it is ok on os x
<gary_poster> in ff
<mattuk1972> yea it really smooth - can't see any dif between it and chrome
<bcsaller> FF uses different platform specific paths for accel
<bcsaller> I *think* its cairo on linux for this, but not sure
<bcsaller> pretty sure it was at one point, but don't know now
<bcsaller> so windows and osx can do very different things
<gary_poster> k
<gary_poster> right
<bcsaller> this is just a border cases that impacts very few sites on a smaller cross section of their browsers
<bcsaller> chrome wrote their own svg accel layer and use it everywhere iirc
<tveronezi> bcsaller: can we have a g+? I need to check with you the solution I have for the aggregation task I am working on.
<bcsaller> tveronezi: yeah, I need a few minutes though
<tveronezi> ok... ping me when you are ready. tkx!
<gary_poster> If anybody said anything to me in the past 15 min or so I probably missed it.  Had to switch computers for a few minutes
<gary_poster> So if I haven't replied to something or other, please try again :-)
<bac> gary_poster: standup is still at 12 EST i assume
<gary_poster> bac, yeah, for now that was what I was thinking, though I was going to clarify with everyone.  AFAIK we have all now gone through DST transition.  We might be able to move the call one hour earlier with Ben on the East Coast, but that's arguably a separate discussion.  Lemme ping everyone...
<bcsaller> tveronezi: ok, I can chat now, joining the hangout
<tveronezi> ok
<gary_poster> bac bcsaller benji frankban (hazmat not here) Makyo mattuk1972 teknico tveronezi I think we have all moved from DST now except bac, who will not.  bcsaller is now on East Coast USA. What do you say to moving the daily call an hour earlier, adjusted for DST changes, to 1600 UTC (11AM EST, 9AM MST, 12PM AST, 1700 CET)?
<gary_poster> (If I left anyone
<benji> sounds good to me
<bcsaller> gary_poster: I'm cool with that 
<gary_poster> 's timezone out I apologize :-) I tried)
<frankban> gary_poster: ok
<gary_poster> mm, I left benji's out because I still think he is Eastern sorry :-P
 * benji is livin' la vida UTC
<gary_poster> :-)
<bac> gary_poster: sounds good.  no change for me
<gary_poster> ok thx
<bcsaller> I am the man without a timezone. Europe to SF for 1 day to NYC, my body is sure I hate it.
<gary_poster> heh
<Makyo> gary_poster, Sounds fine.
<Makyo> gary_poster, Starting today?
<teknico> gary_poster, ok for me
<gary_poster> Makyo, that's the idea, but doesn't have to be
<Makyo> gary_poster, Just making sure :)
<gary_poster> cool :-)
<bcsaller> Makyo: got a sec to catch up on g+?
<gary_poster> frankban, mattuk1972, tveronezi let me/us know asap if the new mtg time I proposed above is OK for you. I'm hoping it is ok for jovan too, when he is back
<tveronezi> gary_poster: sounds good to me too.
<mattuk1972> jovan is in the office
<mattuk1972> is that 4 my time?
<frankban> gary_poster: sounds good
<gary_poster> mattuk1972, yes
<gary_poster> frankban, tveronezi cool thx
<mattuk1972> ok sounds good
<gary_poster> cool thanks
 * gary_poster is changing calendar
<mattuk1972> jovan says 4 is good too
<Makyo> bcsaller, Sure, was just replying to email, whenever's good.
<bcsaller> Makyo: I'll hop in the g+
<bcsaller> g+ is being strange
<bcsaller> hmm, going to restart the router here, it might be acting up
<Makyo> Alright.
<gary_poster> mattuk1972, fwiw and to be clear I invited you to all the meetings, but don't expect you to actually want to attend all of them.  You are invited to attend as makes sense for you. :-)
<mattuk1972> gary_poster: cool will do - ty
<gary_poster> cool
<gary_poster> bac, hey.  I just found the css spec for the two-radius border syntax.  It looks like it is supported.  Did you ad Huw try it and reject it, or is it broken for some reason that is not clear on this page? http://muddledramblings.com/table-of-css3-border-radius-compliance/
<bac> gary_poster: we did not try it
<gary_poster> bac ok.  maybe worth playing with.  we have more of those two-radii curves coming.
<bac> gary_poster: we didn't know about it.
<bac> gary_poster: i'll try it now
<gary_poster> cool
<gary_poster> thx
<bac> hi gary_poster, mattuk1972 says that cimi tried that two radii method and rejected it since the curve is a more complex bezier curve and cannot be replicated using that CSS approach.
<mattuk1972> i mean it might be worth just seeing what it looks like? but i think cimi spet a long time trying to emulate it before
<gary_poster> bac, but we can get a lot closer with it, yeah?  for buttons and smaller shapes in particular
<bac> gary_poster:  we can try but if they have investigated and rejected it then i'm not hopeful we'll be able to get them to accept a non-image approach
<bac> mattuk1972: does that sound accurate?
<gary_poster> bac, I thought we were hoping to get the buttons in all css, even with the simple rounded curves, and this would be a lot closer.  Did I misunderstand?
<mattuk1972> from what i can understand. would it be useful to talk to cimi?
<bac> gary_poster: yes, that was the goal
<bac> gary_poster: but if the designers won't allow any deviation it seems like the experiment is not a good use of time
<mattuk1972> if you use tat method then it won't be following the visual style of siri
<bac> i.e., i don't know if there is anything "close enough"
<mattuk1972> suru even lol
<gary_poster> :-)
<bac> siri, make me a button
<mattuk1972> hehe
<mattuk1972> if someone can show me how close we can get then it might be ok?
<gary_poster> bac, ^^
<gary_poster> bac, I can try or you
<mattuk1972> just warning that it may get some noise from this end if we don't have the curve right enough
<gary_poster> ack
<bac> gary_poster: if that is what you want i'm willing to try
<gary_poster> bac, I don't see how the attempt should take more than 15 minutes or so, yeah?
<mattuk1972> from what i can work out a nice multi radius to try would be 12 and 8
<gary_poster> cool
<gary_poster> thx
<mattuk1972> as thats where the curve start on the horizontal and then the virt 
<gary_poster> Makyo, thanks for reply.  I can imagine pretty easily what we'd want for the image slice css border approach.  If we did the svg approach, what resources/assets would we want?  We couldn't use an svg of the whole box; we'd want svgs of the four corners, I guess?  or what would you recommend?
<gary_poster> bac bcsaller benji frankban jovan2 Makyo mattuk1972 (if you want) teknico tveronezi call in 2
<gary_poster> in https://plus.google.com/hangouts/_/409819056ea1551523432ac63f4df4a6feaa5922?hl=en-US
 * gary_poster has to install google talk plugin and didn't realize...
<bac> reminder this is the last day to the the company survey
<tveronezi> lunch time... brb
<Makyo> Noticeable improvement in speed in FF with the new asset.  Still not great, but definitely better.
<teknico> gary_poster, so, I had a look at the pdf for #1074298, any pre-imp hints?
<_mup_> Bug #1074298: charm panel search results page should match visual design <juju-ui:Triaged> < https://launchpad.net/bugs/1074298 >
<gary_poster> teknico, first, leave out the drop-down, if that wasn't clear
<teknico> gary_poster, well, that part indeed was clear, yep ;-)
<gary_poster> cool :-)
<gary_poster> teknico, otherwise, for the buttons, instead of the image, I'd prefer it if you could use the button function that bac made and is tweaking now
<gary_poster> teknico, also the search part should already be done, if that's not clear--the searchbox_icon.png and so on
<gary_poster> I *think* this should just be CSS teknico 
<gary_poster> teknico, is all of that clear or would you like to discuss?
<teknico> gary_poster, yeah, I thought it would be CSS
<teknico> gary_poster, a few specific pointers in code and CSS would speed things up
<gary_poster> teknico, cool.  Gimme a sec and then we can have hangout?  Maybe set up a hangout and then I'll join?
<teknico> gary_poster, great, thanks. I'm sure frankban won't be offended if we employ the usual https://tinyurl.com/see-emily-code :-)
<gary_poster> :-) k
<frankban> :-)
<Makyo> Very, very simple branch up for review, lp:~makyo/juju-gui/replace-service-module  Just replacing assets.
<Makyo> Rietveld: https://codereview.appspot.com/6826057
<gary_poster> Reviewing...
<gary_poster> you've got one approval, Makyo 
<Makyo> gary_poster, Fanks :)  Easy, but hopefully helpful.
<gary_poster> cool
<bac> hi gary_poster -- i've messed with the border-radius and something like "border-radius 4px / 10px" seems close.  take a look?
<gary_poster> bac, love to.
<gary_poster> what should I do?
<gary_poster> just change css probably :-)
<bac> gary, just mess with it in your browser
<gary_poster> ack, on it
<bac> gary_poster: i discovered in LESS it has to be written: border-radius: ~"4 px / 10px"
<bac> or else it tries to do division.  :(
<gary_poster> huh
<gary_poster> heh
<bac> ~"..." tells it to not interpret
<gary_poster> that's a good weekly hint bac; or at least an email
<gary_poster> bac, cool.  my eye likes 4px/7px best but go withe what your eye tells you and show Matt.  You could offer to change it live over a hangout tomorrow even
<gary_poster> mm, I could be convinced bt 4px/10px bac
<gary_poster> by
<gary_poster> thanks for exploring bac
<bac> mm?
<gary_poster> bac maybe just land it?
<gary_poster> the "mm" was a sound of thought as I compared the two, side by side
<bac> gary_poster: ok, i'll land it.
<gary_poster> cool
<Makyo> Out to the vet.
<benji> Makyo: what is the difference between the buildingRelation and the clickAddRelation flags?
<bac> lbox hates me
<gary_poster> bac, gave you an approval despite lbox's displeasure with you
<bac> gary_poster: cool.  just on the MP i presume
<gary_poster> bac, y
<bac> it blows up trying to access google
<gary_poster> boom!
<bac> so 'lbox submit' ignores the reviewers from LP.  i should've guessed that.  no rv = no reviewers in the submit
 * bac -> dog walk
<Makyo> benji, buildingRelation is true if you did the click to add or the long click, clickAddRelation only in the former case.
<tveronezi> brb...
<bac> tveronezi: there is a conflict in your filter-buttons branch.  no big deal but please push a new branch when you get a chance
<tveronezi> bac: ok... tkx.
<bac> tveronezi: i'll have a full look at it tomorrow before you start.
 * Makyo dogwalks.
#juju-gui 2012-11-06
<tveronezi> bcsaller: good morning. When you have time, please ping me. I need to check with you about the aggregation card. It is already implemented, but I need to check about how it would we enable the debugging mode of this thing. Tkx.
<bac> morning
<teknico> bac, hi, did you already start work on #1074298?
<_mup_> Bug #1074298: charm panel search results page should match visual design <juju-ui:Triaged> < https://launchpad.net/bugs/1074298 >
<bac> teknico: no, last night there were no open spots
<teknico> bac, would you like to pair on it?
<bac> teknico: sure, but i warn you my internet has been really bad.  but we can try.
<bac> i'm doing a trivial branch to fix a problem in the Makefile but will be ready to start in a little bit, teknico
<teknico> bac, ok, great, I'll get something for lunch in the meantime
<tveronezi> bac: tkx for taking some time to review my branch. :)
<bac> tveronezi: np.  very nice work.
<gary_poster> Bring me your tired, your poor, your huddled masses yearning for reviews
 * benji stumbles in from the other room.
<gary_poster> lol
<gary_poster> bac, for your Makefile branch, trying to figure out how to dupe what you did.  I guess you manually cleaned out app/assets/sprite without running make clean?  Or is there another way to trigger the situation?
<gary_poster> dupe the initial problem I mean
<bac> make clean
<bac> make
<bac> touch some png
<bac> make
<bac> boom
<gary_poster> wfm.  will try again
<gary_poster> oh, touch some png.
<bac> did you do the touch?
<gary_poster> no will try that
<bac> yes, that triggers the target
<gary_poster> yeah makes sense
<bac> it seemed trivial enough to self review
<gary_poster> boom!
<gary_poster> agree bac
<gary_poster> I thought you didn't so I was looking at it
<gary_poster> if you were already merging it then I'll move on
<bac> oh, sorry.
<bac> it is merged
<gary_poster> oh cool
<gary_poster> moving on then :-)
<gary_poster> thanks
<bac> too bad we have this problem with claiming reviews
<gary_poster> y
<gary_poster> make
<gary_poster> oops
<gary_poster> anyway, irc is the best we have afaik
<frankban> gary_poster: do you have a min?
<gary_poster> frankban, yes
<bac> hi jovan2, mattuk1972: i landed a branch yesterday with the two radius button styling for 'deploy' and 'cancel' in the charm panel.  take a look please.
<frankban> gary_poster: I'm in juju-ui hangout
<gary_poster> ok
<jovan2> hi bac, will do.
<mattuk1972> bac: they don't really bear enough relation to the suru style imo -they almost look like a straight line edge
<bac> jovan2, mattuk1972: if you think it needs tweaking perhaps you can play with the values using the interactive CSS editor in chromium
<gary_poster> mattuk1972, bac, can also do that with you
<gary_poster> frankban, hangouts is unhappy...
<bac> gary_poster: i don't understand what you mean
<gary_poster> bac, do it in hangout.  share screen
<frankban> gary_poster: :-/
<bac> mattuk1972: i'm free to do a screen sharing hangout if you have a moment
<gary_poster> frankban, going to try restarting. after that will try reinstalling
<mattuk1972> bac: I'm in the hangout
<mattuk1972> hopefully in the right one
<bac> mattuk1972: ok, i'll join now
<bac> mattuk1972: you still there?  if so can you paste the url you're using
<mattuk1972> https://plus.google.com/hangouts/_/409819056ea1551523432ac63f4df4a6feaa5922?hl=en-US
<gary_poster> tveronezi, you have plenty of reviewers for the filter-buttons branch, right?  IOW, I can't help there?
<tveronezi> gary_poster: its done already. Mayko and bac did it. Thanks.
<gary_poster> awesome
<tveronezi> gary_poster: I will move the card to the ui review lane.
<gary_poster> great
 * gary_poster thinks that the html5 placeholder behavior is annoying
 * gary_poster thinks it is less confusing if the text disappears on focus
 * gary_poster came to this conclusion when using another site last night
 * gary_poster returns to regularly scheduled programming
<gary_poster> branches that need reviews:
<gary_poster> I need two reviews of this one: https://codereview.appspot.com/6814089/
<gary_poster> Makyo needs two of https://codereview.appspot.com/6782063/ .  I will do one.
<gary_poster> World ^^^
 * benji looks at https://codereview.appspot.com/6814089/
<gary_poster> ty :-)
<frankban> gary_poster: looking at Makyo branch
<gary_poster> thanks frankban .  When I merge trunk tests fail, fwiw.  Trying to remember which charms are subordinate also :-)
<gary_poster> http://jujucharms.com/charms?sub=1
<gary_poster> frankban, I think the branch has bitrotted enough (over a week in review queue) that we need Makyo to polish it up,  thngs are noty quite working for me
<gary_poster> I'm going to halt my review for now with that note
<frankban> gary_poster: makes sense, so, I won't proceed, and back to my branch after a launchpad review!
<gary_poster> frankban, sounds good.
<gary_poster> bac, can I move "Makefile broken" card to done done?
<bac> yes
<gary_poster> thx
<gary_poster> jovan2, mattuk1972 we have a goal of cards staying in one lane for no more than 24 hours.  I recommend that for the design cards, but I
<gary_poster> 'm thinking more of the UX review cards
<gary_poster> it would be great to have those resolved one way or the other by the time of our call in 1.5 hours
<gary_poster> We have five cards waiting for you, which actually fills up the WIP limit--which is arbitrary, but indicative of a blockage
<jovan2> hi gary_poster, will take a look at them in 2 ticks
<gary_poster> thanks much jovan2 
<jovan2> gary_poster can you confirm that this is what is what I should be looking at: http://15.185.168.174:8080/   if there is no other link in the kanban card?
<gary_poster> jovan2, correct (the more human friendly spelling for the same thing is http://uistage.jujucharms.com:8080/ )
<gary_poster> slightly more human-friendly, anyway :-)
<tveronezi> bcsaller: do you have a minute to g+?
<bcsaller> tveronezi: yeah, sorry I didn't get back right away
<bcsaller> I'll hop on g+ now
<tveronezi> ok... tkx.
<benji> gary_poster: I'm done with reviewing your branch.
<jovan2> gary_poster: Not sure what I should be looking at for the card Charm Panel Full Screen - it doesn't look any different to how it was before. I must be missing somethingâ¦
<mattuk1972> bac: i had a play with the css and ill mail you
<bac> mattuk1972: great
<bac> thanks mattuk1972
<gary_poster> thanks benji 
<benji> my pleasure
<gary_poster> jovan2, the charm panel used to be a popup
<gary_poster> before my branch
<gary_poster> now it fills the right hand side
<gary_poster> if you don't have any issues with it, I guess we can mark it as a victory :-)
<gary_poster> unless you object, I'll do so
<jovan2> gary_poster, yes, sure, that's a victory! For nowâ¦. I thought by Full Screen you might have meant the full charm store! Which would have been a really great advance since yesterday!
<gary_poster> lol
<gary_poster> especially without UX and visual design :-)
<gary_poster> thanks
<jovan2> gary_poster: I know you like to keep one step ahead if possible :)
<gary_poster> lol true
<gary_poster> benji, bac, lp2kanban needs to be taught about our two-review policy
<gary_poster> it is trying to drag cards from reviewing to UX review after a single review
<gary_poster> I guess I'll make a slack card
<benji> mmm
<mattuk1972> gary_poster: the card about indicator - can u shed some light? is that the "growl" type notification?
<gary_poster> looking
<gary_poster> mattuk1972, I think so.  bcsaller made that card (I looked at its "history").  bcsaller, could you elaborate on those two cards you made so that jovan2 and mattuk1972 have a better idea of what we are requesting?
<mattuk1972> I think it relates to the notification wireframes here -https://docs.google.com/a/canonical.com/file/d/0BwQq-CeM0YioZGV5TS1sU3hvaFU
<bcsaller> gary_poster, mattuk1972: Sure I can make some notes, the jist is the view all notification page isn't designed and I don't think we had final design for the menu now as it relates to the new charm panel, so both need to be discussed.
<mattuk1972> gary_poster: in regards to the charm panel -im not sure the fade out to close works that well?
<gary_poster> mattuk1972, maybe I don't have privileges but I get "Sorry, the page (or document) you have requested does not exist." from that link
<mattuk1972> bcsaller: cool - will get onto that next
<gary_poster> mattuk1972, cool, that's why we ask for your feedback. :-) slide up? slide right?
<gary_poster> (the fade out is easiest to code so it's a good starting point in case it is OK visually :-) )
<mattuk1972> gary_poster: seems some things in the visual design are no longer in the charm store? like the view sorter? show me all/recent/favourites?
<mattuk1972> things like the scroll bar design and font size/weight/colour and line spacing are all very different?
<mattuk1972> also the divider between cells and the cell colour? 
<mattuk1972> and the position of the button and where the text should wrap
<mattuk1972> is there something you want me to do for review of these?
<gary_poster> mattuk1972, depends on what it is.  Remember we do things bit by bit also.  Right now the only thing that is in that branch is converting it into a full right side panel instead of a popup.  So in the case of the view  sorter, I think you are talking about the drop-down.  We didn't do that initially both because of time and because of lack of confidence in direction. I made a bug for the second part and talked to Jo
<gary_poster> van about it yesterday.  Bug is 1074296.
<gary_poster> mattuk1972, since it is fresh on your mind, let's have a quick call
<mattuk1972> sure
<gary_poster> I think we have everything coming along, but if we missed something, I should make another bug
<gary_poster> mattuk1972, https://plus.google.com/hangouts/_/409819056ea1551523432ac63f4df4a6feaa5922?hl=en-US
<gary_poster> bac bcsaller benji frankban jovan2 Makyo teknico tveronezi call in 1
<tveronezi> jovan2: do you have a minute to talk about the filter buttons? https://plus.google.com/hangouts/_/47a7aab138b3ca13a291c18caa947ae158f3d995?authuser=0&hl=en-GB
<Makyo> Oops, restart for updates, back in a bit.
<tveronezi> lunch... brb.
<teknico> gary_poster, oh, there was actually one more thing:
<gary_poster> ok
<teknico> gary_poster, can you please move that card from backlog into prototyping for me?
<teknico> gary_poster, it's kind of hard finding it among the vast backlog sea :-)
<gary_poster> :-) teknico I moved it to "ready to code"
<gary_poster> I think we might be full even though it doesn't look like it
<teknico> gary_poster, uhm, I cannot see it, which one is it?
<gary_poster> teknico, bug 1074424
<_mup_> Bug #1074424: Make GUI charm able to configure user & password for the rapi-rollup branch <deploy-story> <juju-ui:Triaged> < https://launchpad.net/bugs/1074424 >
<frankban> gary_poster: my card was automatically moved to UX review... but I think the correct path is 'active reviewing' and then UX review, right?
<teknico> gary_poster, that one? user and password? something escapes me...
<gary_poster> frankban, right.  I'm hoping I might have just fixed it by renaming the columns
<gary_poster> moving those back
<gary_poster> teknico right sorry, was too quick, one sec
<frankban> gary_poster: for UX reviews, hangout + screen share with mattuk1972?
<gary_poster> teknico, bug 1074410
<_mup_> Bug #1074410: Need juju GUI charm that connects to improv <deploy-story> <juju-ui:Triaged> < https://launchpad.net/bugs/1074410 >
<gary_poster> where I said it would be, now
<gary_poster> :-)
<teknico> gary_poster, thanks (you may have it some kanban bug, it said you moved this one earlier too, but then moved the other one)
<teknico> s/have it/have hit/
<gary_poster> frankban, we are still shaking that out.  Jovan also does reviews then. Why don't you try what you said and report back if it seemed to work well.  The alternate approach is to just move the card to the UX lane and ask them to look at it without you
<gary_poster> but then you need to make sure you clarify what they need to do
<teknico> gary_poster, oh, and then I'll need the other card in misc for learning the tools, shall I make it?
<gary_poster> teknico, put it in slack please, and +1
<teknico> gary_poster, will do
<gary_poster> thank you
<frankban> gary_poster: doesn't the second option require the branch to be already merged? 
<gary_poster> frankban, it usually is
<gary_poster> that's why it is after "landing"
<frankban> gary_poster: aha! ;-)
<gary_poster> but I would prefer to have it earlier
<gary_poster> as you expected
<gary_poster> then our review period would require four reviews before landing though.  oof
<frankban> gary_poster: so, right now, if a fix is requested by UX we should 1) create another card, another branch, 2) hack 3) new review/UX review?
<gary_poster> frankban, yes.  if they specifically requested the branch, getting the review earlier probably makes sense.
<benji> new branch up for review: https://codereview.appspot.com/6821088
<benji> anyone remember which days we did not have dinner provided in Copenhagen?
<gary_poster> benji, frankban and bac both have notes on this
<gary_poster> benji, coudl you please make a bug for your branch under review?
<gary_poster> Makyo, I made bug for your firefox work and linked it to card
<gary_poster> benji, you can ask me to make your bug too if you want :-P
<benji> gary_poster: I thought I asked lbox to make one.  I will now ask you to make one.
<gary_poster> :-) ok
 * benji will soon be delegating all work to software or gary_poster 
<gary_poster> :-)
<gary_poster> maybe it is in MP but not card...
<gary_poster> nope
<frankban> benji: here are my notes: http://pastebin.ubuntu.com/1334735/
<benji> frankban: thanks
<gary_poster> benji, heh, your MP comments don't really help the reviewer figure out what the heck to do :-P  um...I'm copying over the text from Matt's original MP...
<benji> gary_poster: yeah, I felt bad writting that, but I didn't really know what else to say; I should have worked harder
<gary_poster> updated in MP; transferring to bug...
<benji> frankban: do you remember how much the 2 zoner to/from the airport was?
<benji> I seem to recall 45 DKK
<gary_poster> benji, you'll need a receipt for that I think
<gary_poster> (I was burned on that in Montreal, for a lot more $$)
<benji> gary_poster: I might have one; are they worried that we walked and pocketed the money instead?
<gary_poster> benji, or perhaps it is a business/legal requirement, since these reimbursements are not taxed?  Not sure
<gary_poster> but that was my guess
<frankban> benji: 2 zones -> 24, 3 zones -> 36 ... and unfortunately I pay taxes on these reimbursements :-(
<benji> frankban: they you should expense the taxes, and then expense the taxes on the tax expenses, and then expense those taxes
 * benji should start an international tax consultancy
<frankban> benji: :-)
<gary_poster> taxed on reimbursements: :-( I got concerned about that a while ago because of the high amount of money I was shelling out for ec2.  In America we are not being (double) taxed for that money, according to the tax consultant we used.
<benji> gary_poster: If I were expensing as much on EC2 as you were, I wouldn't be concerned with the taxes as much as the DEA thinking that I was laundering an entire south-american country's economy through EC2
<gary_poster> lol
<frankban> gary_poster: I need to change my consultant... and maybe my country :-) 
<gary_poster> :-)
<benji> gary_poster: expenses filed
<gary_poster> cool benji, thanks.  I will review all of those today
<tveronezi> bcsaller: https://codereview.appspot.com/6821090 please take a look when you have some time. 
<bcsaller> tveronezi: yeah
<teknico> frankban, I vote New Zealand (but you know that already)
<frankban> heh
 * benji downloads the Quantal ISO
<bac> benji: didn't you have one in your goody bag?
<benji> bac: ooh!  I do.  Thanks.
 * bac is looking at his on the desk
<Makyo> Did my upgrade through the updates center.  Took a while, and totally taxed the machine.  Ah well.
<bac> Makyo: i did too.  even found a bug, which i reported directly to mvo when i ran into him in the airport
<bac> turns out it doesn't like you plopping directories into /etc/apt/sources.d.  tries to open them as files.
<Makyo> Ah :/
 * benji starts to upgrade with fear and trepidation.
<tveronezi> brb...
 * benji restarts into Quantal.
<benji> as always, some of my settings have been reverted to the default, but things appear to be working
<bac> benji: is your machine ready and able to do a quick hangout?  i've got a layout problem i'd like some help on for just a bit.
<benji> bac: I think so
 * benji tries to figure out how to launch firefox.
<bac> gary_poster: hey, you have a moment?
<benji> gary_poster: your presense is requested at https://plus.google.com/hangouts/_/b2ccac118e89d6e06b6e85a0dca260988e8a8d98?pqs=1&hl=en&authuser=0#
<gary_poster> bac, y
<bac> gary_poster: could you join ^^
<benji> grr, why does alt-tab not work
<gary_poster> wfm
<Makyo> gary_poster, #1074336 has a card already, in Subdivide 7
<_mup_> Bug #1074336: Environment view service menu has non-functional "unit" option <juju-ui:Triaged> < https://launchpad.net/bugs/1074336 >
<Makyo> Want me to link?
<gary_poster> Makyo, mind if I just delete it in backlog?  I kind of regard the backlog as a big trash pit. :-) I think hazmat wants to garden it later though
<Makyo> gary_poster, Sure, whatever works :)
<gary_poster> (I actually don't care which one we delete, but it is ready to code)
<gary_poster> cool thanks
<gary_poster> benji, looking at your branch.  So...where are you on the goals of the yui doc work?  You and I are both diligently commenting on the option-type functions, like line 23 of https://codereview.appspot.com/6821088/diff/1/app/views/environment.js?column_width=80 
<gary_poster> We are using a yuidoc "trigger" of /**
<gary_poster> but yuidoc will never pick up on these
<gary_poster> we're doing them because the linter complains otherwise
<gary_poster> AIUI
<benji> gary_poster: I thought the yuidoc branch was merged
<gary_poster> it is, benji
<gary_poster> I must be talking past you
<gary_poster> alongside you
<gary_poster> in cross directions
<benji> gary_poster: hangout
<gary_poster> benji, I'm talking about the philosophy of commenting these things
<benji> ?
<gary_poster> k
<gary_poster> juju-ui if it is available
<gary_poster> it is
<gary_poster> hanging out
<benji> gary_poster: I hear treadmill but I don't see you
 * bac done.
<benji> gary_poster: I lost you.
<tveronezi> bcsaller: do you have a minute for another pre-implementation chat?
<bcsaller> tveronezi: yes, I'll hop on g+
<bcsaller> tveronezi: oops, occupied it looks like, we can open another 
<tveronezi> ok... on it... 
<Makyo> gary_poster, What was the bad behavior you were seeing from subordinate services? (That broken test took a while, sorry, will make a card)
<gary_poster> Makyo, on call
<Makyo> gary_poster, np
<gary_poster> Makyo, hey.  So, I added a subordinate, and it went to 0, 0 and never moved out.  Then when I tried to make relationships they were tied to 0, 0
<gary_poster> (relationships from the subordinate)
<gary_poster> if you can't dupe trivvially I'm happy to try and write up a recipe
<gary_poster> though I am at my EoD
<Makyo> gary_poster, Sorry, stepped away.  I can reproduce, but I get that in trunk.  Was just curious.  Will play around with it.  Have a good evening :)
<gary_poster> Makyo, oh ok
<gary_poster> wondered about that but did not check
<gary_poster> mm...
<gary_poster> so I guess you can reload the page after adding a subordinate to TEST YOUR
<gary_poster> oops, fun with caps lock etc
<gary_poster> ...to test your branch
<gary_poster> I'll look at it tomorry
<gary_poster> have a good evening
<Makyo> Yeah, it seems to be a event-not-binding  thing, but only for subordinates.  I'll keep poking.  Ciao
#juju-gui 2012-11-07
<mattuk1972> hey frankban:
<mattuk1972> Ive got a fair bit of feedback -all small little details - would you like me to talk you through it or make a document?
<frankban> mattuk1972: some notes would be great
<mattuk1972> okily
<frankban> mattuk1972: thanks
<bac> frankban: regarding colors, I used a color picker to look at the colors on the assets referenced on the visual design
<bac> they are similar but a bit different, which is why i mentioned it
<frankban> bac: ah! i have to re-check then... however, I am also waiting for the UX review, so I will fix things up all together. thanks Brad.
<bac> frankban: we've got too many specs to reference!
<frankban> bac: heh... and the borders in charm-store_detailview_preview.png are shadowed, that can explain the color picking mismatches.
<hazmat> frankban, pushed test fixes for rapi fwiw
<frankban> hazmat: cool
<mattuk1972> Frankban: bac: was just going to work though the screen grab and mark out the difference in colour,font weight size and colour and cell size - theres quite a lot of difference 
<bac> hazmat: welcome back.  you here for real?
<frankban> mattuk1972: thanks
<hazmat> bac, not yet, just dropping by, and going through emails
<hazmat> bac, back for real next week
<gary_poster> There is WIP room
<gary_poster> looking to give reviews...
<frankban> mattuk1972: awesome review, thanks!
<gary_poster> frankban, approved your branch with chatty comments
<frankban> cool gary_poster, thanks.
<gary_poster> np
<gary_poster> Makyo, hey.  Should I mark https://code.launchpad.net/~makyo/juju-gui/replace-service-module/+merge/132938 as rejected so we get it out of the review list?
<gary_poster> Also, I think you said you had tests fixed for https://codereview.appspot.com/6782063/ .  If you push those then I can review.  I'm OK with separating out the subordinate creation problems into a separate card
<gary_poster> bac, I dunno why LP didn't recognize https://code.launchpad.net/~bac/juju-gui/trunk/+merge/133060 as merged, but it is, so I am marking it as such
<BradCrittenden> thanks gary
<gary_poster> benji, tveronezi I will be reviewing your branches.  Could you also do some work to rustle up a second reviewer for your branches so we can move things along?
<gary_poster> I am working on benji's now then will move to tveronezi's two
<gary_poster> if anyone beats me to it that's fine by me ;-)
<benji> tveronezi: I'll review yours if you review mine
<gary_poster> :-)
<benji> (Is this some sort of iterated prisoner's dilemma?)
<gary_poster> heh
<tveronezi> hahah.
<tveronezi> :) ok.
<tveronezi> benji ^
<benji> :)
<Makyo> gary_poster, Sorry I left myself online last night!  Sounds good for rejecting that mp.  Let me make sure I'm good to push, I agree about the separate card for subordinate issues.
<gary_poster> cool thanks Makyo (and np, I do that all the time for better or worse)
<gary_poster> benji, approved your branch with comments & small requests
<benji> gary_poster: thanks
<gary_poster> welcome, thank you
<benji> after my upgrade to 12.10, when I visit some sites in Firefox asks me if I want to install NAME-OF-SITE.  I have said yes to some but I can't find anything in addons or anywhere else.
<bac> benji: i've seen that and said no.  wonder what it does
<bac> hi mattuk1972, can i ask you about charm search results styling?
<bac> namely the intent of list_one_div and list_two_div
<benji> on a positive note, I figured out how to kill the persistent tooltips of death
<frankban> mattuk1972: so, the border between elements in the charm panel is no longer one line dark gray and one line white. But it's one line dark gray and one line gray, right? With the exception of the first one after the "<- back" section
<gary_poster> I think the browser thing has different integration depending on the site.  The browser menu may get special options (which can be accessed with the HUD) in some cases; in other cases the site may install controls within the top-right sound menu, for instance, or other existing action menus
<benji> interesting; it would be nice if I could figure out what each site's special features are
<gary_poster> dunno, but yeah agreed
<Makyo> gary_poster, tveronezi: Events are bound in attachSceneEvents, line 338 of environment.js.  Since each event is bound in the same way with the same signature, we have to call them in the same way if we're to call them from other closures.  I don't know if this is something that might change with refactoring, though.
<Makyo> Not sure if that helps explain the pattern or not, bcsaller would probably be better at explaining :)
<gary_poster> Makyo, but foo.bar() is identical to bar.call(foo)
<gary_poster> so that at least can be simplified, right?
<gary_poster> (from the latter to the former)
<bcsaller> .call() supports chaining, foo.bar() doesn't by default
<gary_poster> bcsaller, that's good to remember, but irrelevant unless we are chaining, yeah?
<bcsaller> its useful in the sense that we say "if () {one line expression} because you'll often need it later and the cost is low
<bcsaller> the braces I mean
 * gary_poster not sold on this as a pattern we should therefore follow :-) (YAGNI in the small comes to mind) but maybe we ought to talk about it Friday
<Makyo> I have no stake in either.  If it changes, it changes :)
<gary_poster> :-)
<mattuk1972> frankban: the default divider is one grey one white - except on the ones I've marked - where there is suppose to be in inset shadow effect for example
<tveronezi> Makyo, gary_poster, bcsaller: It just seems strange to see "this.myFunction.call(this)" but does not break the application. I am good having it if you agree. But don't make it as standard. It should be used only if really need it.
<bcsaller> its not Method.call or Method.apply, its d3Selection.call() -> selection
<bcsaller> I don't feel strongly either, but the d3 style is chaining
<bcsaller> and remembering that something *doesn't* chain is more complex to me
<gary_poster> bac bcsaller benji frankban jovan2 Makyo teknico tveronezi call in 2
<frankban> mattuk1972: ok, so, e.g. between description and interfaces, and between interfaces and changelog, it's gray-white. and for all: can you suggest a nice ruler to use with chromium?
<bac> frankban: matt has left the building
<bac> just as i was about to ask something
<frankban> bac: yes... the ruler question is still valid
<gary_poster> bcsaller, ack.  maybe I don't know enough about context.  Good friday conversation maybe
<bac> frankban: yes, that would be handy
 * frankban stops counting pixels and joins the hangout
<gary_poster> jovan2, starting
<jovan2> gary_poster on my way
<hazmat> bac, jovan2 thanks, email sent
 * bac -> lunch
<benji> Makyo: to kill the tooltips you: launch the CompizConfig Settings Manager, enable the Opacity, Brightness, and Saturation plugin, open that plugin, under "Windows specific settings" click the "New" button and enter "type=tooltip" (no quotes) and a value of 0.
<Makyo> benji, does that kill all tooltips?
<benji> Makyo: yep
<benji> you can make the selector more specific to only kill some
<Makyo> benji, Cool, thanks.  Will try for a while, see if I miss anything
<benji> or you can make the opacity very low instead of zero so they will still be there, but be less bothersome
 * gary_poster lunches
<tveronezi> lunch...
<bac> gary_poster: the cursor in the charm search box is inially red.  mind if i make that gray?
<gary_poster> bac +1 thanks
<bac>  s/inially/initially
<gary_poster> it's the valid thing
<gary_poster> you probably know that already
<bac> gary_poster: it changes as soon as you type
<gary_poster> bac, right it is a bootstrap valid thing
<gary_poster> I
<bac> righto
<gary_poster> cool
<bac> jovan2:  can i ask you about charm search results styling?  namely the intent of list_one_div and list_two_div
<jovan2> bac: I'll take a look...
<jovan2> bac: are you referring to visual design files?
<bac> jovan2: yes
<Makyo> gary_poster, do you have time for a quick call in a bit?  I have a question re: this test.
<jovan2> bac: which zip or pdf file should I be looking at?
<bac> jovan2: trying to find it on g+
<gary_poster> Makyo, happy to do it.  IRC/email might be better in the short term, over next hour or two; after that call would be fine
<Makyo> IRC's fine.
<gary_poster> cool
<bac> jovan2: https://docs.google.com/a/canonical.com/file/d/0B6l8lFdCRvtqNEZ4bElfVjF0Tjg/edit
<bac> and the png files in charm_store_assets_1.zip
<jovan2> bac: it looks like a difference in background colour - white or grey
<bac> jovan2: right, so there are three backgrounds then.  one for selected and these other two
<bac> is list_one_div really to be applied to the first in the list and the other non-hovered ones to be different colors?  that is odd to me.
<bcsaller> Has anyone else seen a problem with `make lint` running on recent branches (or maybe since the upgrade to Q)?
<jovan2> bac: yes it looks a bit odd to me too. Matt has left already, so will ask him to clarify tomorrow if that's ok?
<bac> jovan2: sure.  for now i'm going to proceed ignoring list_two_div
<jovan2> bac: ok
<bac> frankban: is your charm panel description branch going to land today?  i need your orange scrollbar
<frankban> bac: yes, going to land asap
<bac> yay
<bac> hey gary, got a second for some pixel counting on stagin?
<bac> g
<frankban> bac: branch landed
<bac> cool, thanks
<tveronezi> benji: merge-files.js is entirely ours.  :)
<benji> tveronezi: ok, thanks; I'll finish the review here in a bit, then
<bac> gary_poster, has anyone noted the extra width on the content div, making it hang off 1 px to the right.  most visible when the charm panel is extended
<gary_poster> I have but I think it is intermittent :-/
<bac> i see it with my branch but noted it is also on trunk.  could not easily figure it out.
<gary_poster> bac if you resize http://uistage.jujucharms.com:8080/ oevr and over again sometimes it will be just right and sometimes not.  I was the last one to touch this code, and I made it  a lot more reliable (IMO) but there's still this issue
<bac> ok
<bac> i'll make a card
<gary_poster> ok thx
<gary_poster> tveronezi, your Makefile has the same kind of problem that I talked with you about before, with the sprite generation: it runs the compression every time.  This is one way to address it: http://pastebin.ubuntu.com/1340722/
<tveronezi> gary_poster: sweet... tkx. 
<gary_poster> welcome
<tveronezi> gary_poster: we dont want to use $(NODE_TARGETS) instead of the node_modules/yui and node_modules/d3/d3.v2.min.js modules. Sure we will download unnecessary stuff, but it would be just once. 
<gary_poster> tveronezi, that's a question?
<gary_poster> or a statement? :-)
<tveronezi> gary_poster: yeap... question. :)
<gary_poster> heh ok
<gary_poster> I originally used $(NODE_TARGETS).  I then wanted to be more specific about what this depends on.  The most proper approach IMO would be to add app/assets/javascripts/d3.v2.min.js and *all* of app/assets/javascripts/yui/* (recursive) to $(NODE_TARGETS) (which is true--we're making those too) and then depending on the d3 and the yui in app/assets/javascripts
<gary_poster> Listing yui was annoying
<gary_poster> So but it would be good because that's what the script *actually* depends on
<gary_poster> the combinejs script I mean
<gary_poster> So then I compromised and said I only depended on nodejs and d23
<gary_poster> d3
<gary_poster> it will still build *all* of the node_modeules
<gary_poster> there's no target for "only build these parts of node_modules"
<gary_poster> so it is really just documentation
<gary_poster> Specifying $(NODE_TARGETS) is *practically* exactly equivalent
<gary_poster> tveronezi, ^^
<tveronezi> ok.
<gary_poster> In sum, what I did was a documentation compromise.  What you propose would be acceptable, and practically equivalent, but not in my picture of how things are really supposed to work with a Makefile.  Since I'm only compromising, do whichever you prefer,.
<gary_poster> If I were *really* doing it right, I'd feel stronger about it :-)
<tveronezi> gary_poster: for some reason, using the $(NODE_TARGETS) does not work. The combinejs always runs three times if I use it. :/ I think I will stick with your first solution.
<gary_poster> tveronezi, that suggests to me that the files listed in NODE_TARGETS are not quite right
<gary_poster> so you could also try to to tackle it from that perspective
<gary_poster> but do what you wish
<tveronezi> gary_poster: thanks for your solution for the make files. I was struggling to get it working when I started the branch. I forgot to ask your help before submitting the branch. It works like a charm.
<gary_poster> cool tveronezi 
<tveronezi> gary_poster: do you mind if I create another card for the  $(NODE_TARGETS) issue? I mean, another card to pinpoint what is not supposed to be there?
<gary_poster> tveronezi, if you wish.  to be perfectly honest, I'd plan on forgetting about it until it bit me later :-P  Certainly you don't need to address it in this branch IMO
<tveronezi> gary_poster: ok... tkx.
 * bac being summoned to the fort.  bbiab.
<gary_poster> tveronezi, I submitted a preliminary review for the file aggregation branch; I'll have more later 
<tveronezi> gary_poster: ok... tkx.
<gary_poster> bac, if you are available to review https://codereview.appspot.com/6819104/ then maybe tveronezi and I can review https://codereview.appspot.com/6817101/
<Makyo> Woo, have FF almost as fast as Chrome now.
<gary_poster> Wow, Makyo cool
<bac> gary_poster: ok.
<bac> tveronezi: 2nd review done.  thanks.
<tveronezi> bac: tkx.
<bac> thanks for the review gary
<gary_poster> welcome
<bac> i set the spacing to 10px as stated.  perhaps something else is making it more.
<bac> as to the different backgrounds, I asked jovan about it and he was going to check with matt.  it didn't occur to either of us that it was alternating a la green-line
<bac> if that is their intent, i think they didn't get it quite right on the vis design.  makes sense, though.
<gary_poster> bac 10px: oh ok.  I didn't see the 10px directive, but agreed that this is what you have
<gary_poster> so nm
<bac> i wish the inspector gave a better way to measure
<gary_poster> Makyo, I gave your branch a +1.  You still need another look though
<Makyo> gary_poster, Why thank ya
<gary_poster> :-)
<gary_poster> jbye
#juju-gui 2012-11-08
<teknico> buongiorno
<bac> thanks for the review frankban
<frankban> bac: my pleasure
<bac> mattuk1972: i've landed your CSS button suggestions for deploy and cancel.  thanks for helping to get the colors right and spotting that text shadow.  have a look at http://uistage.jujucharms.com:8080/
<mattuk1972> bac: nice one -will take a look when i get a mo
<bac> mattuk1972: also, i talked to jovan yesterday about some question about the charm search results panel.  he was going to follow up with you.  let's chat about it when you have some time.
<mattuk1972> sure -ill have some lunch and ping you
<bac> i'll be here
<bac> just noticed the codereview bot has been sending me G+ chat messages.  has that been happening a long time?
 * benji fires up the coffee maker.
<tveronezi> bcsaller.... I am reviewing you code.
<gary_poster> tveronezi, bcsaller hi.  I was happy to see that tveronezi had a pre-imp on the code minification/aggregation branch.  It turns out benji and I had a shared observation/request that went against the pre-imp call discussion.  benji and I felt that the build tool belonged in the top-level bin directory, while tveronezi said that Ben asked to move the file into app/assets.  That seems like an odd choice to me, because 
<gary_poster> the app is what we are supposed to serve, and this file is a build tool.  I thought it might be a good idea to talk that through so we understand where we are all coming from.  We could do that on a hangout or here.
<gary_poster> I also was surprised to get pushback on trying to get the server simpler and the code tree we develop and debug more like what we intend to ship
<gary_poster> an old saying benji and I have referred to for years is "fly what you test and test what you fly"
<gary_poster> and if our goal is to ship static code, we should be moving ever closer to that in our dev environment, not farther
<gary_poster> IMO
<benji> +1
<gary_poster> So, bcsaller and tveronezi, maybe let me know when you are both available and we can have a hopefully quick hangout
<bcsaller> gary_poster: the build tool was supposed to go in lib and the assets in assets
<tveronezi> gary_poster, benji, bcsaller: Ok... moving file...
<gary_poster> bcsaller, ah!  ok.  I'd be much happier with that.  I'd still vote for bin more than lib, but I have much less of a philosophical concern with that :-)
<bcsaller> if it was to go in bin I'd remove the .js from the name and add #!/usr/bin/env node at the top. I don't recall if the file exported any methods nodejs style though so it might not have had any reuse potential as it last stood
<gary_poster> yeah that would make sense.  If it had reusable bits that would be fine.  In an ever more perfect world, I'd say have a bin file with a small shell that imports code from lib that has been tested nicely
<gary_poster> even if it is not reusable, the lib code would be more naturally testable, I think
<gary_poster> I'll say something like that in a follow-up review
<mattuk1972> Hi gui'ers - assets layout guide and preview for notifications indicator have been uploaded to g drive
<gary_poster> bcsaller, ^^^ thanks mattuk1972!  do you want review from us now?  Or what would be good now?
<mattuk1972> gary_poster: the style is lifted directly from suru notifications -so if you guys are happy with what I've delivered its good to go
<gary_poster> cool
<mattuk1972> let me know
<gary_poster> bcsaller, looks good to me for the growl-style notifications.  Is that all you were looking for, or were you also hoping for a design of the notifications drop-down?
<bcsaller> gary_poster, mattuk1972, looking at the previews now
<bcsaller> gary_poster: Yeah, the drop down and the 'view all page', The view all page has never seen any UX or design.
<gary_poster> frankban, I am in the hangout from the calendar.  no rush, join when you are ready.  
<gary_poster> bcsaller, cool.  So, we can make a card for growl notifications based on what mattuk1972 has provided, but we need to ask him for the designs of the other elements as well?
<mattuk1972> yea i just did the pop up now but was going to move onto the alert panel next
<bcsaller> The drop down doesn't include things like a limit on number to show or if we should include a scroll bar. I'm not even sure where we are with the growl style stuff. The design looks nice for growl, but I was never convinced it solved a problem at the UX level
<bcsaller> its not clear to me if those persist till the user sees them or what
<bcsaller> and what if many errors occur at once
<bcsaller> I appreciate the problem that the current red icon doesn't tell the user enough.
<bcsaller> If resolution around this was reached I might have forgotten, but I don't feel clear on it
<mattuk1972> as far as i can tell from the ux -they just appear for a set amount of tim and then fade away 
<mattuk1972> i think they serve a purpose - if you had a lot of units in a module and one more went wrong - it would not really be brought to your attention that another error had happened  without this kind of notification - also if an error happens outside of your field of view?
<mattuk1972> bac: hi - reviewed your layout and i noticed something that I missed I'm my layout (sorry) its just a single pixel line thats missing from under the cell with the button in it - it should echo the spec I sent to frank ban in that respect - that gives it a small drop shadow
<bac> mattuk1972: ok, i'll have a look
<mattuk1972> shout me if its not clear
<gary_poster> mattuk1972, bcsaller, sorry, was on call.  I think the growl notifications serve a purpose and are a significant improvement, particularly as a standard way to give mostly-immediate feedback.  If jovan and mattuk1972 are happy with them then I think we should proceed.  I can imagine a lot of polish we could talk about in the future--for instance, if there's no activity on the page then notifications might not start 
<gary_poster> to time out, and if you have more than N notifications at once then they are collapsed and turned into a link to the full notifications page.  However, we can add those, or other changes, if we get user feedback about them.  So bcsaller, unless you think Kapil is going to reject this for some reason, I think we ought to treat it as commissioned.
<gary_poster> TBH, I think this might be moot in the short term: we are going to switch to a deployment story next week. However, depending on what story we choose after that, we'll see.
<bcsaller> gary_poster: I think Kapil would approve it and the design does look good
<gary_poster> ok cool bcsaller, thank you.  I'll majke bug and card then
<bac> mattuk1972: i'm confused as to what you're referring to.  is it the charm configure panel with the cancel and deploy buttons that needs the extra line below it?
<mattuk1972> yes - ill send you some annotations -1 min
<bac> ok
<bac> mattuk1972: regarding the alternating colors, that's already done and on staging
<mattuk1972> bac: ok cool - jovan just told me you needed it
<bac> the alternating colors are very subtle.
<mattuk1972> it should be in tabular info - doesn't need to slap you in the face but just helps to scan cells
<gary_poster> teknico, in hangout from calendar
<gary_poster> no rush
<teknico> gary_poster, is it ok in half an hour?
<gary_poster> teknico, absolutely. My fault for changing time without checking with you.  (Wanted to make sure we had enough time given new daily call time)
<teknico> gary_poster, oh, did the time change? I got no email
<gary_poster> teknico, do you want me to ping you then? or you'll join when you are available?  
<gary_poster> yeah, sorry, I thought I asked for notifications to be sent but maybe did it wrong
<teknico> gary_poster, no need, thanks, I'll be there in a while
<gary_poster> cool
<frankban> I appreciate border-radii, (latin is an undead) even if I usually use plural names for lists (and I don't really know what ~"6px / 7px" means). What do you think about refactoring border-radius directives into a single mixin in the css? I am going to do that. 
<gary_poster> frankban, because we are having to do the same thing over and over again?
<frankban> gary_poster: yes, each time we want something rounded we have to add 3 css rules
<gary_poster> frankban, and for fun: ~"..." means "LESS! Don't touch this!" That's important because otherwise LESS thinks you want it to do math and so 3px / 6px would be converted to 2px.  We actually want the slash: it lets us make an ellipse (https://developer.mozilla.org/en-US/docs/CSS/border-radius is one explanation)
<gary_poster> frankban, single mixin: sounds great, thank you
<frankban> gary_poster: ah! cool.
<gary_poster> :-)
<gary_poster> tveronezi, you available for a hangout?
<tveronezi> yeap.
<mattuk1972> bac: sent you a little annotation of what i meant
<bac> thanks mattuk1972
<teknico> gary_poster, I'm there, no rush :-)
<bac> hi mattuk1972 i've made that changes and the branch is landing now.
<bac> mattuk1972: did you look at the Cancel and Deploy buttons?
<gary_poster> bac bcsaller benji frankban Makyo mattuk1972 teknico tveronezi call in 2
<mattuk1972> I'm going to duck out today
<gary_poster> cool
<bac> gary_poster, benji: could benji and i swap our 1:1 call times?  currently mine extends past my EOD
<benji> bac: hi
<gary_poster> bac, benji fine by me.  can also move everything back half an hour
<bac> benji: uh, it is 4:30 AST so that would be 3:30 EST
<bac> benji: when was your old one?  an hour before?
<gary_poster> or which is not even benji's time zone ;-)
<benji> I have transended time zones.
<bac> benji: you should switch to mars time
<benji> heh
<bac> they have a watch for that now
<benji> My kids already think I am crazy because my phone uses a 24 hour clock.
<bac> gary_poster: i changed our call on the calendar but it wouldn't let me move benji's
<gary_poster> bac, so you and benji switched?
<benji> yep
<bac> gary_poster: yeah,
<gary_poster> your call ok
<gary_poster> ok done
 * bac <- lunch
<Makyo>  /me <- vet
<Makyo> Dumb.
<Makyo> Well, whatever, you all get it :)
<frankban> gary_poster: re charm config panel: do you suggest leaving the "use config file" button inside service settings, and make the form disappear on upload? another option could be the button outside and the whole settings section disappearing on upload
<gary_poster> frankban, I like the button inside the section because they are equivalent but I'm happy to defer to your judgement
<frankban> gary_poster: ok thanks
<gary_poster> welcome
<tveronezi> lunch...
 * tveronezi now knows how to refers to himself in the third person :)
<benji> heh
<benji> UPS, USPS, and FedEx deliveries today.  I think that is a new record.
<gary_poster> benji, replied to your add-rel-improvements email.  Thank you!  I gave extremely detailed step-by-step action plan for your enjoyment
<benji> gary_poster: heh, thanks
<benji> gary_poster: re. updating rietveld, I did another "lbox propose" but it just created a new review.  What is the right way to send an update?
<gary_poster> I think you have to do -cr again benji
<bac> i thought you did propose -cr again
<bac> too
<benji> this is what I ran: lbox propose -cr -v -for=lp:juju-gui
<gary_poster> :-/
<bac> so on env view, it looks like the status bulls eye doesn't get redrawn when error states change
<gary_poster> dunno
<bac> mean to say, it deployed with lots of red and yellow, i removed all of the errored units, and the circle of doom is still red and yellow
<benji> gary_poster: re. step-by-step instructions: LOL
<gary_poster> :-)
<Makyo> bac, does the unit count in the center change?
<Makyo> Or is it still the old count?
<bac> no it changes
<Makyo> Weird...both of those are rendered at the same time.  Wonder if it's not redoing the aggregates or something.
<bac> Makyo: and two relations between the same services are overlaid -- which i'm sure you're aware of
<Makyo> bac, Yeah, that's still outstanding work..
 * Makyo lunches.
<gary_poster> tveronezi, I'm ready for a call follow-up whenever you are
<tveronezi> ok...
<gary_poster> and I only have 13 minutes actually so soon would be good :-P
<tveronezi> now. :)
<gary_poster> cool
<bac> gary_poster: ping
<gary_poster> yeah hey bac almost 2 or 3 more
<bac> gary_poster: 2 or 3 more what?
<gary_poster> bac, emus
<bac> how long is an emu?
<benji> gary_poster: call?
<benji> I /think/ this is the new time.
<gary_poster> benji, in a shocking turn of events, I am ready for you in the chat room as specified in the calendar, at approximately the correct time
 * benji looks for the URL.
<gary_poster> tveronezi, check in @ juju-ui?
<tveronezi> ok.
 * Makyo dogwalks
#juju-gui 2012-11-09
<bac> morning mattuk1972
<mattuk1972> hey
<mattuk1972> bac: hey
<bac> mattuk1972: did you ever get a chance to look at those cance/deploy buttons and decide if the latest tweaks are acceptable?
<mattuk1972> i need to try and grap head of visual
<mattuk1972> grap even
<mattuk1972> grab
<mattuk1972> !
<mattuk1972> because he's the one we have to get it past
<bac> mattuk1972: ok, cool.  i've got a card for it in UX review and get asked about it daily... :)
<mattuk1972> ill make sure i pass it by him
<mattuk1972> im sorry
<mattuk1972> he's hard to pin down
<bac> no prob.  gary bugs me.  i bug you.
<mattuk1972> :-)
<mattuk1972> was just going through the main charm store page and theres a bit of feedback (as usual)
<frankban> bac: if you have time, could you please take a look at https://codereview.appspot.com/6827066? mostly CSS stuff.
<frankban> mattuk1972: hi, I have a branch in review re charm confing panel, needing UX review. Do you want me to send screenshot, or do you prefer to wait for the branch to be landed and then review in staging?
<mattuk1972> frankban: screenshot should be fine
<frankban> mattuk1972: cool, thanks
<bac> frankban: yes
<frankban> bac: thanks
<bac> frankban: in your MP description you say you followed the wireframe.  is that accurate or did you use the visual design document?
<bac> charm-store-configure-layoutguide.pdf
<frankban> bac: both
<frankban> I used the png for measurements and the pdf for colors, sizes, etc...
<bac> frankban: cool
<mattuk1972> bac: store_front_review.pdf uploaded in char store folder of visual design
<bac> mattuk1972: ok
<gary_poster> mattuk1972, hi.  will you be around for today's retrospective call (right after the kanban call)?  we have a topic to discuss best ways to coordinate around designs and assets. If you can be there I'll put that first (after the kanban bits) so you can bow out after
<mattuk1972> sure
<gary_poster> ty
<bac> frankban: nice function documentation!
<mattuk1972> frankban: is that 16px text in the text fields? e.g. cassandra
<frankban> mattuk1972: yes
<mattuk1972> I think it should be 14. its just too huuuuuge? the text seems to line oddly in the vertical?  sometimes its really close to the top and sometimes to the bottom?
<mattuk1972> frankban: also the cancel and confirm buttons should be the same size really
<frankban> mattuk1972: for 14px, no problem, for the buttons, you mean the width?
<mattuk1972> frankban: ya
<frankban> ok, noted
<mattuk1972> frankban: also everything should left align to the same place - at the moment the title and buttons and content all align diferently
<mattuk1972> frankban: everything should be 10px in from the single grey pixel line div.
<frankban> mattuk1972: ok, everything with 10px left padding. ah! but in the charm detail panel the padding is 12px everywhere. mattuk1972: I think we should go one way or the other
<mattuk1972> frankban: its 12 pixel from my original design where the measurement was taken from the edge of the charm panel - it seems like the measurement here is being taken from the grey single pixel line. also in my original design this was a two pixel line anyway
<mattuk1972> frankban: so that makes it 10 px
<frankban> mattuk1972: ok
<mattuk1972> frankban: sorry to be a nitpicker
<bac> hi, i'm seeing this conversation late.  the charmstore_assets_guide.pdf has 11px on the left, mattuk1972 and frankban
<frankban> mattuk1972: :-) np
<bac> is that wrong or not taking a border into effect?
<bac> would be nice to see it standardized and abstracted into a LESS variable
<mattuk1972> i was just trying to give the measurement from how i thought it was being taken
<frankban> bac: less variable, agreed
<mattuk1972> in my original layout guide i gave it as 12px not taking border into effect
<mattuk1972> sorry for any confusion
<frankban> mattuk1972: so, I will change it to 10px border excluded
<mattuk1972> there is a slight issue in that the two px border isnt there - i was trying to give the panel an inset look that i think is lost now
<gary_poster> tveronezi, I just gave a follow-up review.  Things are looking good to me.  I only have one non-trivial suggestion, and hopefully it is pretty easy one way or the other.
<tveronezi> gary_poster: g+?
<gary_poster> sure
<frankban> mattuk1972: we should make another card for the 2 pixel border IMHO. I am going to do that if you agree.
<mattuk1972> frankban: sure
<frankban> bac: I am fixing the branch you are reviewing introducing the padding-left variable for the charm panel
<frankban> mattuk1972: cool
<bac> frankban: ok
<bac> frankban: review sent
<bac> nothing surprising in it
<frankban> bac: thanks. re: the config file... in my browser it is part of the vcollapsible, actually collapses and the chevron works well
<frankban> :-/
<bac> frankban: i'm using chrome on quantal
<frankban> bac: me too
<frankban> bac: cache?
<bac> frankban: so you collapse 'server settings' and the button goes away?
<bac> perhaps i described it poorly
<frankban> bac: yes
<bac> frankban: i will try clearing cache
<mattuk1972> bac: frankban: garyposter: the use config file ux has never been properly looked at imo. Jovan is going to take a look at it to figure it out correctly.
<bac> mattuk1972: that would be great
<mattuk1972> shall i ask him to make a card?
<benji> bcsaller: do you have any pointers on how the d3 world does testing?
<benji> I keep finding things about blood tests for vitamin levels.
<gary_poster> heh
<bcsaller> benji: ha, I'm not sure what to tell you, they have unit tests in the code base that are pretty good, but our more specific tests don't really translate to how those work
<bcsaller> for things like the env view I think we end up with lots of calls to simulate like we have now. At the unit test level I've tried to make the framework refactor a little more testable
<bcsaller> (and tested)
<bac> hi mattuk1972, i'm looking at store_front_review and have some questions.
<mattuk1972> yup
<mattuk1972> want to do a call?
<gary_poster> frankban, you still need a second review for charm-config-panel, yeah?  starting it, so stop me if not necessary :-)
<bac> the cell height comment is confusing.
<frankban> bac: pushed fixes per UX review, and also LESS variable to set all the charm panel views to 10px left padding. still seeing that ugly config file behavior?
<bac> 70px when a one line description?  what if there are multi-lines?  i'm not sure how that could even be handled in css
<frankban> gary_poster: yes I do, thanks!
<gary_poster> cool, wlecome
<frankban> gary_poster: and just pushed fixes per UX review
<gary_poster> got it, pulled
<mattuk1972> bad, a fixed cell height no matter what text - not nice to resize
<mattuk1972> the cell
<mattuk1972> bac not bad
<mattuk1972> ...
<bac> bad bac!
<mattuk1972> lol
<gary_poster> :-)
<bac> and what if there is a long description mattuk1972?  we have no control over it as it is provided by charm authors
<mattuk1972> two line and then â¦ i guess
<mattuk1972> much like my email prog
<bac> we can do a *minimum* of 70px, which will cover the one line case but i think it'd be nicer to see it grow than have text truncated.
<benji> we might, almost, be at the point where most browsers can do ellipsis correctly
<bac> let me play with it
<bac> benji: just automatically?  or does something need to be specified?
<benji> bac: it is automatic.  I know that recent FF and Chrome support it, I would hope IE does by now too
<benji> bac: text-overflow: ellipsis;
<bac> frankban: i'm seeing the proper collapsing now.  the animation is crazy slow
<mattuk1972> cell grow bad - a fixed structure helps to scan tabular info
<bac> benji: cool
<gary_poster> collapsing: weird, quite fast for me
<bac> gary_poster: ok.  must be my odd environment
<bac> chrome over x
<gary_poster> bac, that doesn't mean we should ignore it
<gary_poster> oh
<gary_poster> well maybe it does then :-P
<frankban> bac: fast for me too. maybe you are looking at the position, so you can not catch the speed, it's quantal mechanics 
<benji> bac: yep, it looks like all major browsers support ellipsis correctly now.  I have waited so long for this day.
<benji> I need to get out more.
<gary_poster> :-)
<mattuk1972> hehe
<bac> gary_poster: i think i am going to work on monday and take it as a swap day later.
<gary_poster> bac, cool.  (me too)
<gary_poster> day after Thanksgiving is just too convenient
<benji> gary_poster: how many days do we need to reserve for the Christmas shutdown?  I seem to recall it being four.
 * gary_poster looks
 * benji wonders where gary_poster looks for these things.
<bac> benji: it is only the canonical calendar
<gary_poster> benji, I search in myriad wonderful places until I find what I want :-P
<gary_poster> bac, to what do you refer?  I was just very proud to have found https://docs.google.com/a/canonical.com/file/d/0ByrI0-OYdkUEMzA4OTk2MWYtNmVhNC00ZTAxLWI1YTItNTg5ODQ1NWRlNTcx/edit?hl=en_US
<gary_poster> which shows what I suspected:
<gary_poster> we get Friday Dec 28 off generally
<gary_poster> so in the US we need to reserve three days for Christmas holidas, benji
<gary_poster> oh wait, no, 4
<gary_poster> 24, 26, 27, 31
<bac> gary_poster: launchpad team google cal shows the span.  but doesn't show the 28th as free
<bac> it also doesn't show the 24th as being closed
<gary_poster> right, that was the important part that I vaguely remembered
<bac> so yours wins!
<gary_poster> :-)
<mattuk1972> bac: the visual design manager he's says the buttons are good to go : -) he said marc s may pick up on the curve but as long as we have a good reason why they are this way it should be good
<gary_poster> yay!
<mattuk1972> woop
<gary_poster> :-)
<bac> excellent
<benji> Sanity prevails.
<gary_poster> frankban, approved as is.  looks great
<frankban> gary_poster: cool thanks
<gary_poster> teknico, no rush, but I'm in hangout from calendar
<teknico> gary_poster, getting there
<gary_poster> cool
<tveronezi> gary_poster: quick g+?
<gary_poster> tveronezi, on another call sorry :-0
<gary_poster> :-) I mean
<tveronezi> ok.
<tveronezi> gary_poster: I just want to discuss the "bootstrap" thing. Just want to let you know that if we use that, the "aliases" (the "use" key in "modules.js") wont work. I will need to specify the requirements one by one. I dont know what to do now.
<tveronezi> gary_poster: ping me when you have time.
<gary_poster> tveronezi, ok, will try to do it asap
<gary_poster> bac bcsaller benji frankban jovan2 Makyo mattuk1972 teknico tveronezi call in 2 in juju-ui
<gary_poster> tveronezi, sorry; I'm there now if you want to try and squeeze something in; otherwise maybe afterwards would be good
<gary_poster> Makyo starting
<bac> jovan2: the first 'Deploy' button could be re-labeled 'Configure' as it leads to the configure panel.
<Makyo> bcsaller, can I request you as a reviewer on the firefox thing, whenver's convenient?  I'm messing with drawing relations, figure you should be in on that,.
<bcsaller> Makyo: sounds good, I'll look at it after some food
<Makyo> Cool, thanks.
<gary_poster> OK, I might be back...
<tveronezi> gary_poster: g+?
<gary_poster> tveronezi, ok if you don't mind occasional distractions for me
<bac> benji: wrt to wrapping and ellipsis, i added text-overflow: ellipsis as you suggested
<benji> did we settle on tags or multiple review requests to keep up with who was reviewing what?
<bac> but it isn't overflowing and ellipsising.  it is just spilling into the next <li>
<benji> bac: what browser?
<bac> benji: tags separated by vertical space
<benji> heh
<bac> chrome
<bac> benji: and hunter suggested i remove the fan blades to see if it speeds up.
<bac> if it does, then they will replace the blades
<benji> bac: oh, you need "white-space: nowrap" too
<bac> rinse, repeat
<benji> that's... odd
<benji> do they occasionally make blades that are way too heavy?
<bac> the way i figure it, a bad motor could speed up if you remove perfectly good blades
<bac> so it seems to be a non-conclusive test
<bac> if the motor does not speed up then it is a bad motor
<benji> Makyo: I was going to review your branch, but I can't find it.  ("Cannot remove subordinate relations")
<bac> benji: do you have a sec for a call?
<benji> bac: sure
<Makyo> benji, lp:~makyo/juju-gui/remove-sub-rels
<benji> Makyo: thanks
<benji> Makyo: is there a reitveld review or MP?
<Makyo> Ah, sorry. https://codereview.appspot.com/6782063/
<bac> benji: http://danbeam.org/ellipsis/yui/
<benji> bac: cool
 * bac walkies.  bbiab.
<gary_poster> tveronezi, your branch has been fully blessed :-)
<tveronezi> tak! :)
<tveronezi> thanks! I mean! :)
<gary_poster> I thought you were turning Danish on us!
<gary_poster> Makyo, trying to quickly give you a review before a call in 11 minutes so you can land replace-service-module...
<Makyo> gary_poster, Thanks:)
<gary_poster> :-)
<gary_poster> Wow, Makyo, FF is now completely usable for me on both new desktop and 3 year old laptop: congrats!
<gary_poster> Chrome still faster
<gary_poster> but the difference in FF is huge
<gary_poster> approved Makyo, witgh trivial comments
<Makyo> gary_poster, Thanks.  I know there's still room to improve FF, but that may come with other branches.  Will take care of comments, etc.
<gary_poster> cool thx
 * tveronezi brb
 * tveronezi back
#juju-gui 2013-11-04
<rick_h_> hatch: cool, yea and we might have links from readme's and such that should work. Thanks for dbl checking/updating
<hatch> rick_h_: new (better) fix proposed....much simpler ;)
<rick_h_> hatch: cool, will look in a bit. link me please
<hatch> https://codereview.appspot.com/21430043/
<hatch> I'm at a conference tomorrow and Tuesday but I'll try and pop in if I have some downtime tomorrow to land it
<rick_h_> hatch: no tests? comments on why replacing the cs:?
<hatch> impossible to test
<hatch> at least in js
<rick_h_> at least verify that the urls output are fully qualitifed
<rick_h_> ?
<hatch> like the ones in the href?
<rick_h_> something has to be accessing or testing this serviceUpgradeLi
<rick_h_> ?
<hatch> hmm
<hatch> ahh looks like I might be able to stick a small assertion in the upgrade tests
<rick_h_> hatch: +1
<hatch> I can't believe that this bug in YUI hasn't been reported yet
<hatch> that just seems to me like a common thing haha
<hatch> rick_h_: ok I don't have enough time to get these tests done right now - but you can review/qa with a lgtm pending the tests if you lik
<hatch> e
<bac> hi evilnickveitch
<rick_h_> benji: bac I got a nice failure to land with what looks like some sort of lxc/python path error. Anything look obvious to you guys? 
<bac> rick_h_: paste?
<rick_h_> bac: sorry, meant to have the link in there http://162.213.35.27:8080/job/charmworld-autoland-lxc/54/console
<benji> that's a strange one; my first guess would be to look for recent Makefile changes in which someone fiddled with the PWD
<rick_h_> oh, /me missed that change
<gary_poster> hey alejandraobregon, Thursday jaas meeting doesn't work for me.  half hour later?
<benji> rick_h_: I'm not saying there was a recent change like that, I'm saying that looking for such a change would be the first thing I would do.
<rick_h_> benji: yea, hunted and found nadda
<benji> k
<bac> benji: are you suggesting the change is in charmworld or the lander?
<rick_h_> bac: managed to land just ahead of me by hours. So maybe something in my branch is the issue but not seeing
<benji> bac: charmworld
<benji> I would also suspect a dirty lander (sans evidence).
<rick_h_> I'm working on a branch of docs for all the api changes made and will try to get that reviewed/landed before abentley arrives to bug
<benji> Unfortunately we keep a dirty checkout around forever instead of getting a fresh one every time
<rick_h_> if that lands then I know it's my branch, if not, then it must be the lander/lxc stuff
<benji> sounds good
<gary_poster> thanks benji.  Should I go so far as to suggest that they run make devel & :-)
<bac> marcoceppi: i working on incorporating bundle proofing into the ingest job.  i'd thought charmtoolsv1.1.0 on pypi would have the bundles work but it doesn't.  do you plan a release soonish?
<bac> s/i work/i'm work/
<benji> gary_poster: closing the terminal would still kill it; they could run "nohup make devel"
<gary_poster> ah ok
<rick_h_> bac: it doesn't? It should. jcastro was using it on friday
<marcoceppi> bac: uh, it should
<marcoceppi> bac: make sure you're using charm-tools
<marcoceppi> not charmtools
 * bac looks
 * marcoceppi spins up a clean vm to test
<rick_h_> marcoceppi: did you not sdist upload the package? https://pypi.python.org/pypi/charm-tools/1.1.0
<marcoceppi> rick_h_: I'm pretty sure I did
<rick_h_> marcoceppi: there's no download there 
<marcoceppi> rick_h_: right, I see that now
<marcoceppi> pypi is a whole new world for me
<rick_h_> marcoceppi: cool, happy to help if you need anything. Once you get logged in and registered the project normally a python setup.py sdist upload
<rick_h_> is all you need
<marcoceppi> rick_h_: ah, never ran the upload
<marcoceppi> I did the publish though
<marcoceppi> figured that did it
<bac> thanks rick_h_ & marcoceppi.  i'm set now.
<rick_h_> bac: cool
<marcoceppi> rick_h_: upload: 
<marcoceppi> python setup.py upload
<marcoceppi> running upload
<marcoceppi> error: No dist file created in earlier command
<rick_h_> marcoceppi: yea, can you see if it'll let you switch your branch back to 1.1.0 and do an sdist upload?
<rick_h_> marcoceppi: yea, you need sdist and upload
<rick_h_> "make this sdist and upload it"
<marcoceppi> rick_h_: I did an sdist :\
<rick_h_> python setup.py sdist upload
<bac> marcoceppi: adding the steps to a hacking doc would be great!
<marcoceppi> oh
<marcoceppi> uploadede
<marcoceppi> bac: what hacking doc ;)
<rick_h_> marcoceppi: awesome, there we go. Pretty readme and all there
<marcoceppi> rick_h_: lame, no markdown support
<rick_h_> bac: cool, let me know if there's anything else we need to help. We'll have to check any deps that aren't updated/part of the download cache as it installs
<rick_h_> marcoceppi: yea, python is a rst world man
<marcoceppi> rick_h_: mega lame
<rick_h_> :P
<marcoceppi> anyways, that readme is out of date now that I read it
<marcoceppi> should probably update it
<rick_h_> time for a 1.1.1 release! :)
<marcoceppi> rick_h_: ehhhhhhhh, I think it can wait for 1.2
<marcoceppi> I hate patch releases
<rick_h_> marcoceppi: docs is backward compat :)
<rick_h_> but cool
<bac> marcoceppi: were you referring to this: https://pastebin.canonical.com/99786/
<marcoceppi> rick_h_: https://bugs.launchpad.net/charm-tools/+bug/1247839
<_mup_> Bug #1247839: README is out of date. Should also provide plaintext and RST version <Juju Charm Tools:Triaged by marcoceppi> <https://launchpad.net/bugs/1247839>
<rick_h_> bac: that looks like a missing dep in the package
<marcoceppi> damnit. Now I have to patch release
<marcoceppi> could have sworn I had markdown in there
<rick_h_> marcoceppi: locked version numbers too please :)
<marcoceppi> yeah, it's in the setup.py
 * marcoceppi is installing in vm
<rick_h_> marcoceppi: right, but they're not locked to a version number
<marcoceppi> rick_h_: so?
<marcoceppi> I mean that shouldn't stop it from installing
<rick_h_> bac: so this is what I mean on the deps. We need to download those and get them into the download cache. Any we don't already have in there
<marcoceppi> rick_h_: bah, this is actually making me like debian packaging
<rick_h_> marcoceppi: right, this is because of prodstack. We can't hit the interwebs due to egress filtering. So we keep a download-cache of the packages needed and we version lock them to keep pip from going and fetching
<bac> marcoceppi: paramiko too
<marcoceppi> rick_h_: why not just add the ppa?
<rick_h_> bac: right, those are new deps
<marcoceppi> it's packaged in the ppa
<rick_h_> marcoceppi: we can't hit LP either
<marcoceppi> prodstack should be able to, wtf!
<marcoceppi> bahhhhhhhhhhhhhhh
<rick_h_> marcoceppi: hmm, does a ppa count as LP?
<marcoceppi> rick_h_: check with #is
<rick_h_> marcoceppi: looking to see if we pull a ppa already. Thought we might have.
<bac> rick_h_: ok, so i needed markdown paramiko and cheetah
<rick_h_> marcoceppi: yea, we do add a ppa. We just can't pull LP branches down in prodstack
<marcoceppi> rick_h_ bac I recommend the package then
<marcoceppi> pypi is just a stop gap for brew stuff
<bac> ok
<rick_h_> bac: looks like it. 
<rick_h_> bac: but if ingest runs off our virtualenv it'll break
<rick_h_> bac: so hold on a sec, looking
<marcoceppi> rick_h_: is there an easy way to just say like "yo dawg, tell me what versions pip just dl'd" so I can add it to easy_install?
<rick_h_> marcoceppi: I've got a script that would fetching locked versions of things from a requirements.txt and build a download-cache. Normally I'd install your package, then pip freeze > requirements.txt and get the versions/etc
<rick_h_> bac: I guess it looks like ingest doesn't run from the virtualenv that I can tell so I guess the package from the ppa might work
<marcoceppi> rick_h_: so I should move the requirements out of setup.py and in to requirements.txt?
<rick_h_> marcoceppi: no, not for a library like this. Just saying normally you can generate it from a clean virtualenv with the package + deps installed
<marcoceppi> I'll let you guys figure out what's needed. Just let me know if/what you need me to change
<rick_h_> marcoceppi: thanks, uploading the pacakge was helpful
<bac> marcoceppi:  is there a ppa with a released version of charm-tools?
<marcoceppi> bac: ppa:juju/stable
<bac> ah, great
<rick_h_> marcoceppi: the LP landing page has sudo add-apt-repository ppa:juju/pkgs
<rick_h_> https://launchpad.net/charm-tools
<marcoceppi> rick_h_: thanks
<rick_h_> marcoceppi: is that still valid?
<marcoceppi> rick_h_: no
<marcoceppi> rick_h_: updated
<rick_h_> marcoceppi: thanks
<marcoceppi> rick_h_: still trying to get this project up-to-date
<rick_h_> marcoceppi: we, your users, are here to help :)
<rick_h_> appeciate it
<bac> rick_h_: so you agree on moving charm-tools to SYSTEM_DEPS in the Makefile and install from ppa?
<rick_h_> bac: sounds like a plan to me if that works. 
<bac> we'll lose version locking...
<rick_h_> bac: otherwise we'll have to manage his deps in the download-cache
<rick_h_> bac: ugh, yea. I mean we want to keep up to date, but managing things on several different versions would suck (when would be apt-get update/upgrade prodstack?)
<bac> rick_h_: but we can only hope things moved to juju/stable are, you know, stable
<benji> gary_poster: you might be interested that Maarten Ectors is using comingsoon in cold-call emails.  We might want something more stable than that.
<gary_poster> benji, I know about that, thanks :-).
<benji> k
<bac> benji: is he cold-calling you?  :)
<rick_h_> bac: right, but there's been what, 3 new releases this past month of juju? And so prodstack would be stuck at the one at deploy time, unless we make sysdeps on every deploy to charmworld?
<benji> bac: yes! he's trying to sell me leaf guards for my gutters
<bac> i hope he's got a better price than Chimneys Plus
 * bac is now worried about his clogged gutters 1500 miles away
<marcoceppi> bac: rick_h_: I subscribe to semantic versioning and do test backwards compat. Minor releases should not break and I have no plans for a 2.0 release at this time
 * marcoceppi introduces the "im only human" caveat though ;)
<bac> rick_h_: got a sec to chat?
<rick_h_> bac: sure thing
<gary_poster> bac, proof integration going smoothly?  rick_h_ , +1 on getting the quicksearch deploy button out the door via the cache fix, thank you. benji, bac, rick_h_, after those, getting "Add key to charmworld API linking to deployer file URL (see description)" in quickly would be fabulous; let me know if you can start that and I'd like to have a pre-imp discussion
<benji> k
<gary_poster> benji, do you remember james troup saying that getting encryption on postgres would be...much easier?  trivial?  I am about to ask on #webops but wanted to see if you remembered that part of the conversation
<gary_poster> (benji, 'cause I'm going to suggest "hey, postgres is fine" if so :-) )
<benji> gary_poster: he said that they were doing it at the filesystem level, that's what made it easy; I don't recall him stating a difference between postgres and mongodb
<gary_poster> benji, ok, thanks.  You saw jjo's RT reply, right?  My understanding from that is that he considered it to be a big job.
<gary_poster> I'll go talk on #webops
<benji> gary_poster: I saw it but didn't pay much attention.  I wonder if he knows we meant "deploy it on an encrypted FS" vs. "add encryption to mongodb"
<gary_poster> benji, it looks like he understands to me
<gary_poster> the expensive tasks are peripheral but reasonable
<benji> gary_poster: send james after him
<benji> PG would be OK I guess, but it means adding another technology to the system
<gary_poster> :-)
<gary_poster> yeah I know.  
<gary_poster> I still am in favor of something in front of it that only gives us the API we need
<rick_h_> gary_poster: heh, a little roughly, but moving forward. 
<rick_h_> gary_poster: yea, having a landing problem with my proof stuff so trying to do a docs branch to test if the issue is my branch or the lander until abentley is around
<abentley> rick_h_: hi.
<rick_h_> oh, abentley is around, morning. Can I still some time when you have a sec?
<abentley> rick_h_: Sure.  Haven't really got started yet.  What's up?
<gary_poster> rick_h_, ah ok.  so you are blocked on that; bac can make progress on the integration; but we don't know when we can land.  Is the integration looking theoretically landable today?  tomorrow?
<rick_h_> abentley: http://162.213.35.27:8080/job/charmworld-autoland-lxc/54/console is failing in a really strange way on pip install and python path issues. I've started a docs branch I'll try to land to try to tell if it's something my code introduces or a lander issue, but curious about your thoughts. 
<benji> gary_poster: yeah, I wouldn't change our proposed architechure
<gary_poster> cool benji
<abentley> rick_h_: looking...
<gary_poster> benji, I think you and I are talking about differnt things, maybe though.  we definitely need two pieces of software in front of the firewall and a DB behind the firewall.  I am talking about the DB behind the firewall that abstracts the DB operations only
<gary_poster> I mean software behind the firewall
<benji> gary_poster: right (I assumed there was some suggestion to change the software behind the firewall because PG has all kinds of security/mediation features)
<abentley> rick_h_: I've never seen anything like that before.  I guess the virtualenv is borked?  Maybe you should just delete the workspace and try again.
<rick_h_> abentley: can I log into it? Just SSO? 
<gary_poster> oh ok cool, yay for being on same page :-) ,.  Looks like Mongo is AOK with them though.  they think it is 1 IS engineer 1 week, roughly, to do all the various bits described, which sounds reasonable to me
<gary_poster> benji ^^
<abentley> rick_h_: No, you have to log in as "admin" with the password specified in the juju config.
<rick_h_> abentley: ah, ok. 
<benji> k
<rick_h_> bah, my offlineimap hung up. No wonder email seemed quiet this morning
<gary_poster> rick_h_, congratulations on successfully convincing the landing bot of your worthiness :-)
<rick_h_> gary_poster: yea, thankfully abentley applied a giant hammer of doom to it
<hatch> hello all
<gary_poster> lol cool
<gary_poster> hey hatch
<hatch> oops I forgot to mute my laptop
<hatch> that was embarrassing
<rick_h_> lmao
<hatch> haha
<hatch> hotel wifi here is so bad that I had to hotspot
<gary_poster> lol
<gary_poster> on the train sound
<rick_h_> benji: bac either of you have time for an api docs update sometime? https://codereview.appspot.com/18600046
<benji> rick_h_: I don't at the moment.
<rick_h_> benji: k, thanks. 
<bac> rick_h_: soon
<rick_h_> bac: cool, no rush. The landing issue is fixed so this is pure docs for some point in time
<bac> rick_h_: done
<rick_h_> bac: thanks
<benji> rick_h_: what was the landing issue?
<rick_h_> benji: the workspace got corrupt in some way. I was going to bring it up on the call
 * benji recruits rick_h_ into the clean builds for CI cabal
<rick_h_> :)
<rick_h_> benji: ftr I'm a fan of both ends. Prodstack isn't a clean env so we need to know on that end as well. So clean + upgrade-ish 
<gary_poster> benji, we are off the hook for now in #webops?
<gary_poster> LP bug?
<benji> gary_poster: I think it is at least partially a LP bug.  There is the open question of how CW is able to actually check out the branches in question.
<benji> gary_poster: There is at least enough fog of war that we can demote it to non-emergent status.
<gary_poster> benji, heh ok
<benji> I'll tell the webops such so we don't violate their expectations.
<gary_poster> thanks benji.  
<benji> np
<gary_poster> benji, bac, rick_h_ unrelated question for you .  If I look at https://manage.jujucharms.com/api/3/bundle/~benji/wiki/wiki/ , it says, near the bottom, "id": "~benji/wiki/5/wiki".  AFAICT, that
<gary_poster> 's a bug
<gary_poster> it should be ~benji/bundle/wiki/5/wiki
<gary_poster> (at which point we could simply tack on a "json" at the end to get the deployer file, and we wouldn't need a "deployer_file_url" added to the data)
<rick_h_> gary_poster: hmm, no, that's the id you use in the charm as the bundle-id. api/3/bundle/~benji/wiki/5wiki/
<gary_poster> rick_h_, ah ok
<rick_h_> gary_poster: the deployer file original json thing is why I'm not a fan. It's a special user facing url that's been created to send the json back
<rick_h_> gary_poster: and doesn't follow the same rules as apis
<gary_poster> rick_h_, but it does follow rules of charmworld page
<gary_poster> rick_h_, which is my concern about the id 
<rick_h_> gary_poster: right, I think there's a bug in there, but that id is "correct" 
<gary_poster> because I think the charm id does correspond to the charmworld user visible page
<gary_poster> :-/
<rick_h_> gary_poster: it just doesn't match the json url expectations which is probably more the bug
<gary_poster> rick_h_, but do you follow that it also does not follow the https://manage.jujucharms.com/~benji/bundle/wiki/5/wiki expectation?
<gary_poster> IOW...
<rick_h_> gary_poster: hmmm, yea. That's based off the branch you push to? since you could have ~user/charms and ~user/bundle?
 * benji regrets posting a bundle whos URL will make his IRC client beep
<gary_poster> rick_h_, a charm id is the charmworld user visible url
<gary_poster> so
<gary_poster> precise/haproxy-21
<gary_poster> becomes https://manage.jujucharms.com/precise/haproxy-21
<gary_poster> and works
<gary_poster> a bundle id does not have that characteristic
<rick_h_> gary_poster: right, so the bundle urls weren't done in a way to follow suit. I'd argue they should be /bundle/~hatch... with the $id being everything afgter /bundle
<rick_h_> the world "bundle" isn't part of any bundle id and I'd hate to see it become part of it
<gary_poster> rick_h_, I would buy that.  Pretty late in the game though. :-/
<gary_poster> rick_h_, that's a small routing change with big test ramifications, yeah?
<gary_poster> rick_h_, but if we did that then simply adding json after the url ought to work
<rick_h_> gary_poster: not sure? I'm not aware of why we can't change the routing to be bundle/~id vs ~user/bundle/..rest-of-id
<gary_poster> well it is not bundle/~id but bundle/id, for promulgated charms--do we have any of those yet?
<Makyo> jujugui call in10
<gary_poster> :-)
<gary_poster> thanks
 * Makyo whew, made it!
<gary_poster> bah I meant promulgated bundles
<rick_h_> gary_poster: not sure on promulgated bundles. There was all that controversy around policy on those last week
<marcoceppi> can someone confirm a bug in charmworld/the review queue for me?
<rick_h_> marcoceppi: maybe, crazy day. What's up?
<marcoceppi> http://manage.jujucharms.com/tools/review-queue proof error on appflower is still listed, but it doesn't have anything wrong in it's proof output. Does that list ever get re-generated or was it a one time thing?
<rick_h_> marcoceppi: not sure, that seems strange with all the N/A and such. Maybe jcsackett has an idea what's up there?
 * gary_poster changes computers/locations
<rick_h_> marcoceppi: I'm not up on the review queue, but it seems have N/A on those would be bad and needs attention. Would take some chasing down to figure out wtf. I say file a bug and we'll see what we can figure out
<marcoceppi> thanks
<gary_poster> jujugui call in 1
<evilnickveitch> bac, hi
<bac> hi evilnickveitch, otp right now
<bac> you be around in 20 min?
<evilnickveitch> ok
<evilnickveitch> bac, yes indeed
<jcastro> hey rick_h_
<jcastro> have you tried to deploy any of my bundles?
<jcastro> I can only get bootstrap up and the GUI
<jcastro> then it exits saying it's deploying the other services, but they actually don't fire up
<rick_h_> jcastro: no, on call atm but haven't tried them out
<jcastro> bcsaller was investigating it on friday, but I just want to confirm if other people are firing things up with qauickstart and it all works
<jcastro> ok
<jcsackett> marcoceppi, rick_h_: it should update with every proof run on ingest; if there are no errors, and it's in the queue, that's def a bug.
<rick_h_> jcsackett: what's with all the N/A in there?
<marcoceppi> jcsackett: cool, I'll open a bug
<jcsackett> N/A means no date.
<jcsackett> those are in the date fields.
<jcsackett> things like proof errors don't have dates, as we can't tell the first time a proof error existed, only that it exists now.
<jcsackett> so merge proposals, bugs, askubuntu questions &c have dates; proof errors, store errors, missing qa data don't.
<hatch> Learning a lot about Azure stuff
<hatch> no bash scripting
<hatch> lol
<rick_h_> jcastro: what bundles are failing? Hit me up witht he url please
<rick_h_> jcastro: we need to test if they can be dragged/dropped into the gui in a real env or not. To tell if it's a quickstart bug or something bigger
<marcoceppi> jcsackett: https://bugs.launchpad.net/charmworld/+bug/1247891
<_mup_> Bug #1247891: Proof list in review-queue does not get updated <charmworld:New> <https://launchpad.net/bugs/1247891>
<gary_poster> alejandraobregon, where are we meeting for jaas thing?
<gary_poster> luca__, ^^
<luca__> gary_poster: heya
<gary_poster> hey
<luca__> gary_poster: can we use gui chat?
<gary_poster> luca__, gui chat has died because google did not like us, but we can use 
<gary_poster> luca__, mm, nm :-) why don't you all start a hangout
<gary_poster> or I can
<gary_poster> adding it to calendar is easiest
<luca__> gary_poster: go ahead :)
<gary_poster> oh ok
<luca__> gary_poster: Ale isn't here at the moment
<luca__> gary_poster: so she can't add it
<luca__> gary_poster: She'll be joining in 2 mins
<gary_poster> luca__, no video from me but https://plus.google.com/hangouts/_/76cpjflh89tfksavch1qeigoj8?hl=en
<jcastro> rick_h_, http://manage.jujucharms.com/~jorge/bundle/wordpress/wordpress-simple
<jcastro> any of the ones I pushed
<rick_h_> jcastro: cool, but I know some worked some didn't so thanks for the sample. I'll try to see if it works via the gui on aws
<bac> hi marcoceppi, i'm trying to run the charm-tool test suite and i 1) get a failure and 2) don't see the test_proof.py suite being run.
<marcoceppi> bac: how are you trying to run the test suite?
<marcoceppi> I don't know if I include the tests in the package (or if I was supposed to)
<bac> marcoceppi: i've checked out a branch and ran 'make check
<marcoceppi> bac: that should work, I constantly run the tests here
<marcoceppi> yeah, they pass here
<bac> marcoceppi: it fails with http://paste.ubuntu.com/6359716/
<marcoceppi> bac: hum
<bac> marcoceppi: also can you verify test_proof.py is being run.  it doesn't look like it is and it fails due to code reorg if i run it by hand (% tests/proof/test_proof.py)
<marcoceppi> bac: doesn't look like it's being run
<bac> marcoceppi: unfortunately i've got to be afk now for an hour or so.
<marcoceppi> bac: that's fine, I've never liked the actual testing structure. I had plans to re-write it all in python unit tests but haven't gotte around to it
<marcoceppi> bac: test_proof will fail spectacularly because of the bundles re-org
<bac> yep
<marcoceppi> bac: I'll make sure it works again with re-org, not sure why your proof is failing. It looks like it's failing to make the metadata.yaml file, do you have python-markdown installed?
<luca__> gary_poster: In the simulator I can't see machine restart and security updates in the inspector, do you know why?
<gary_poster> luca__, not off hand.  will look
<gary_poster> rick_h_, do you know anything by chance?  Confirmed & investigating ^^^
<rick_h_> gary_poster: I thought that the simulator didn't simulate landscape stuff? 
<gary_poster> rick_h_, it does
<rick_h_> gary_poster: I remember that question coming up at the table during sprints and not sure what came of it
<gary_poster> ok cool
<luca__> gary_poster: I submitted a bug for it
<gary_poster> thanks luca__ 
<luca__> gary_poster: I think potentially this could be a problem from removing that bottom bar
<gary_poster> luca__, that's what I'm thinking as well.  no smoking gun yet though
<luca__> gary_poster: because the simulator shows the notifications in jujucharms.com
<luca__> gary_poster: but not coming soon
<gary_poster> luca__, sure; jujucharms is pretty old code now though :-P
<luca__> gary_poster: ah
<gary_poster> I have to run.  biab
<rick_h_> cursed npm...ugh
<bac> marcoceppi: i do
<bac> marcoceppi: i mean, yes i do have python-markdown
<marcoceppi> bac: I can't seem to replicate that failure :\
<bac> marcoceppi: the recent re-org makes proof not very friendly to be used as a lib.  i'm going to make a small patch and propose it.  if you agree with the change could you make a 1.1.1 very quickly?
<marcoceppi> bac: yeah, I can roll a patch quickly
<marcoceppi> bac: make sure you propose against lp:~charmers/charm-toosl/1.0
<marcoceppi> err
<marcoceppi> bac: make sure you propose against lp:~charmers/charm-toosl/1.1
<bac> ok
<rick_h_> gah, this is why we need to have a true offline npm cache. 20s requests if it completes at all and a cache does me no good when doing a charm rebuild because you changed the source branch. 
<bac> marcoceppi: here is the merge proposal: https://code.launchpad.net/~bac/charm-tools/proof-lib/+merge/193829
<marcoceppi> bac: this LGTM, let me test but I can cut a 1.1.1 within the hour (depending on lp builds)
<bac> marcoceppi: perfect
<marcoceppi> I'll take this opportunity to slide in a few other small changes
<rick_h_> grabbing coffee, brb. gary_poster landed the removing of the feature flag. Upon closer inspection it's how it works normally when you hit the deploy button. There's things to make nicer there, but it's all in the inspector itself. 
<marcoceppi> bac: are you on a windows machine?
<gary_poster> rick_h_, ok cool
 * benji fights with rv-submit
<jcastro> rick_h_, did you get the bundle to work?
<rick_h_> jcastro: no, having lxc issues and npm is hating me to test it on aws
<rick_h_> jcastro: so not been able to test it so far, hoping npm comes to its senses 
 * benji figures out rv-submit
<marcoceppi> bac: 1.1.1 submitted to the PPA, uploaded to pypi
<gary_poster> marcoceppi, bac does some of his work on OS X.  Not windows.
<gary_poster> and on his behalf, thank you :-)
<marcoceppi> np! Happy you guys are using the product :)
<gary_poster> :-)
 * benji lunches
<bac> marcoceppi: no, i am running on a saucy vm
<marcoceppi> bac: I was trying to figure out why your merge request removed +x on the proof file
<bac> huh, i didn't do that intentionally
<marcoceppi> I figured, so I assumed it was a system level thing
 * benji is back from lunch
<rick_h_> benji: gary_poster any ideas on what to name this url to the bundle json in the bundle response? we've got permanent url as the bundle: url. This is deployer_json_contents or something?
<gary_poster> rick_h_, thought 1: deployer_file_url ?  thought 2: if the id is correct, you could argue that we don't need this, but I agree it is nice.
<rick_h_> gary_poster: yea, I mean we could hard code the gui building the url but prefer to have mjc generate it and send it over the wire and keep the gui stupid about it
<benji> +1 on stupid
<gary_poster> ack rick_h_ .  If it is only "add /json to id" I think it is not too bad, but as I said, I agree it is nice
<rick_h_> gary_poster: hmmm, https://manage.jujucharms.com/api/3/bundle/~bac/wiki/wiki/file/bundles.yaml is the file url. 
<rick_h_> gary_poster: oh hmm, is that /json the bundle or the basket /me goes to dbl check
<gary_poster> rick_h_, no, that's the basket, or it better be :-)
<gary_poster> btw, the landscape issue is a bug in simulator, but fixing it exposes a bug in landscape-in-inspector changes
<rick_h_> gary_poster: wheee
<gary_poster> :-)
<rick_h_> benji: the way I'm reading this that url is just the json for that bundle. Does that sound right?
 * benji looks
<gary_poster> that's the file from the branch
<gary_poster> or should be
<rick_h_> gary_poster: right, but in this view it's generating a dict and then json'ing it back. No basket in there. 
<gary_poster> rick_h_, that's yaml
<rick_h_> gary_poster: so that url manage/bundle/~bac/xxx/yyy is just the bundle requested. Not a deployer file
<rick_h_> gary_poster: so for instance, that'll never have a series in it from what I can tell
<rick_h_> :/
<benji> rick_h_: that is a deployer file for the bundle in question; there are no basket files ("basket file" doesn't make sense in the current model of running inheritence at ingest time and storing bundles outside of baskets)
<bac> marcoceppi: darn, i've spotted some more problems.  i see sys.exit is being called a few places, both inside the proof method and in BundleLinter.  those will need to be excised and just return the appropriate error.
<gary_poster> benji, a basket file is conceptually an unprocessed deployer file--the deployer file from the branch
<gary_poster> agreed I'm making that name up
<rick_h_> benji: ok, I guess. It's a new deployer file than what went in. Does series get flattened somehow then? since that's in the outer file?
<marcoceppi> bac: bah, 1.1.2 it is then
<benji> gary_poster: sure, "conceptually", "for reals" we don't treat them as first-class entities and don't expose them
<marcoceppi> bac: I may have split the proof file a little too hastily
<gary_poster> benji +1
<marcoceppi> bac: can you open a bug while I patch?
<bac> marcoceppi: sure
<bac> marcoceppi: bug 1247951 filed
<_mup_> Bug #1247951: proof calls sys.exit <Juju Charm Tools:New for marcoceppi> <https://launchpad.net/bugs/1247951>
<marcoceppi> bac: thanks!
<benji> gary_poster: what does "Add version file in charmworld?" mean?
<gary_poster> benji, it means, "ask Gary!" Congratulations! ;-)
<benji> heh
 * benji jumps around as confetti falls down.
<gary_poster> heh.  benji, so...Kapil mentioned that he wanted the bundles to have a version file.  For charms, the charm store does that.  As long as we serve upindividual files and not zipfiles for bundles, I don't think we actually care about version files.
<gary_poster> but if we do, charmworld would supply them, ATM
<benji> k
<gary_poster> benji, so the question is, would a version file make any sense at all now?  Or should we postpone them till zipfile bundles?
<gary_poster> AFAIK the answer is #2, but I wanted to ask, since Kapil had mentioned it
<benji> gary_poster: what is the point of a version?  to just keep up with it in case you forget?
<rick_h_> why does it matter for zip files even. Just because the deployer needs to know to redo the work vs ignore it due to a cache or something? It's the only thing it's used for in charms in  deploying over and over the same charm 
<gary_poster> benji, uh-oh, koan territory.  If I knew, I might be more excited asking for it ;-)
<gary_poster> rick_h_, yeah, that's it
<bac> rick_h_: quick call?
<rick_h_> bac: sure thing
<gary_poster> benji ^^^ versions would let the deployer know "oh, it was version foo"
<rick_h_> gary_poster: so ftr I'm not a fan. It's a lie to the user. That revision is not respected anywhere.
<benji> heh, "koan territory"
<gary_poster> so it could upgrade
<gary_poster> rick_h_, ?
<benji> does the deployer do that?
<gary_poster> rick_h_, this would be so that the deployer could do that.
<gary_poster> benji ^^^
<gary_poster> it's a pre-requisite
<gary_poster> step 1: we provide a version
<gary_poster> step 2: deployer annotates version at deployment time
<gary_poster> step 3: <magic happens> bundles are upgradable!
<marcoceppi> bac: Does this look okay?
<marcoceppi> https://code.launchpad.net/~marcoceppi/charm-tools/fix-sys-exit/+merge/193844
<benji> gary_poster: we could do something I suppose, but this whole thing seems painfully underspecified
<rick_h_> +1 ^^
<marcoceppi> step 4: profit!
<rick_h_> gary_poster: what I was saying is that we've got this revision file, but any UI we show is either the store revision or bzr revision which are different
<rick_h_> gary_poster: and it bugs me we have it around, so duping that for bundles is just more itching to get annoyed with :)
 * marcoceppi chimes in
<marcoceppi> Could we just use revno for version?
 * marcoceppi uses the royal we, and means you guys
<rick_h_> marcoceppi: well I guess I'm with benji on getting the use case. Right now you can't deploy the same bundle twice in the gui because it'll fail that the charm is already deployed into the environment
<gary_poster> benji, uh-huh.  I guess that's another way at looking at my point.  (1) Kapil wants to support bundle upgrades.  To do that, he needs a concept of version.  (2) Kapil can't use the version until it is delivered to the deployer. At that point he can start annotating versions, which is a prerequisite for supporting upgrades.  (3) The deployer file currently has no way to specify a version. (4) He thinks it would be ni
<gary_poster> ce to have it in a separate file, to match the way it is done in charms.  (5) That solution only helps #2 if the deployer gets a zip file.  (6) There could be many other solutions, but Kapil is requesting a feature, not a design discussion. (7) we can say too bad. :-)
<rick_h_> marcoceppi: if the goal is to re-run your bundle at the time you write it, there's no bzr reno to update 
<marcoceppi> oh, good point :(
<gary_poster> benji, rick_h_ so, the card is to try and get your thoughts on this.  your thoughts have been kinda grumpy so far, tbh :-P but if I can cast them in a brighter color, they would be "we can implement versions or something similar, but we need to all agree on their utility, across the deployer, the GUI, and charmworld, and not have one part of the chain drive the other two."  Of course, Kapil can push back on that, si
<gary_poster> nce we've wanted to follow the deployer so far, but I think that's a reasonable position.  Is that how you'd suggest I cast it?
<bac> marcoceppi: what does proof return for exit_code when it successfully calls remote_proof?  is it 0 or 200?
<rick_h_> gary_poster: I'd suggest it get cast as "If the goal is to support bundle upgrading we should discuss how that would work and if we need to be able to diff the json configs and handle that. Versioning doesn't help with an upgrade. It just tells us to --force. If that's the only use case then let's find a way to add a --force flag to things vs versions that don't mean anything
<marcoceppi> bac: it doesn't return anything, it updates the Linter via calls to err, warn, info, etc
<marcoceppi> bac: ideally if all is peachy, it should be 0
<benji> gary_poster: +1 on the "we can implement versions or something similar"; re. the second part, I don't really care who drives what
<gary_poster> rick_h_, I think he believes that versioning can help with an upgrade, and I suspect he has a point.
<marcoceppi> ohhh, I think I see a bug bac
<rick_h_> gary_poster: right, but the only way I can see it helping is if you've got the old/new and know how to deal with the difference. Otherwise I think it's more of a --force-deploy new_bundle.yaml feature. 
<bac> marcoceppi: so if i want to reject the entire thing, i can rely on err_code != 0?
<marcoceppi> bac: which method are you running, proof?
<bac> marcoceppi: yes
<rick_h_> gary_poster: but yea, grumpy about it actually fitting the use case. It can be added just fine. We do it for charms, though we've worked hard to back out of it for most use cases. 
<marcoceppi> bac: cool, you should get err_code 0 for everything okay, error is 200, warn is 100
<marcoceppi> bac: I just realized it's not respecting the offline flag, which you guys will need
<benji> I can't see how a version number helps upgrades, other than to know when they aren't neccesary (equal version numbers).
<rick_h_> benji: right, and a --flag can do that
<rick_h_> how does an upgrade work? If a service is deployed, and the config values in the bundle are changed, how are those applied? Remove all old config and set new, merge the two overriding as necessary? 
<gary_poster> rick_h, benji, aiee, you guys are being grumpy. :-)  let's have a hangout.  https://plus.google.com/hangouts/_/calendar/Z2FyeS5wb3N0ZXJAY2Fub25pY2FsLmNvbQ.j0rk5d371ph8331ijtf48t2uj0 
<marcoceppi> bac: okay, offline checks added, but yes, after running proof you should get an list of messages and a code >= 0
<bac> marcoceppi: review done but i sprung a new issue on you.  :)
<marcoceppi> bac: that's fine, might as well get them out now before the new release :)
<marcoceppi> bac: so if you run proof with offline you'll get this: http://paste.ubuntu.com/6360893/
<marcoceppi> I'm guessing you're not going to want to show that message every single time
<benji> might aught to make that a warning at least
<benji> BTW, marcoceppi, have you been working on juju-core? those one letter abbreviations make me think you have
<marcoceppi> benji: no, these one letter messages have been around since before I was even a charmer
<marcoceppi> legacy code, and all that
<bac> marcoceppi: charmworld won't ever be running with --offline
<marcoceppi> bac: oh, might want to check with rick_h_ I put that in there for him
<rick_h_> marcoceppi: well that's for you in case people want to proof sans-network activity
<rick_h_> airplanes and all that
<marcoceppi> rick_h_: oh, I though you guys were going to do it to prevent another look up against your API endpoint
<bac> whee, we're going 'round and 'round
<marcoceppi> since it's pingin charmworld
<rick_h_> lol
<marcoceppi> ha, I don't always proof bundles on an airplane, but when I do, I do it from memory
<marcoceppi> bac: okay, updated the merge
<marcoceppi> fudge
<bac> great marcoceppi.  will that be 1.1.2?
<marcoceppi> bac: yeah, this will be 1.1.2
<bac> yay
<marcoceppi> bac: it's up on pypi and via tarbal https://launchpad.net/charm-tools/1.1/1.1.2 the ppa should have it built in about an hour
<benji> gary_poster: should I work on the charm killer next or something more pressing for the release?
<bac> marcoceppi: great
<rick_h_> go marcoceppi go!
<gary_poster> rick_h_, did you determine that Jorge's bundles work fine in the GUI on a real environment--it is just quickstart, for some reason?
<rick_h_> gary_poster: so it did not work from the gui, but I could not use anything but the default stable branch in the charm due to npm issues. It did work via a manual deployer call. 
<rick_h_> gary_poster: so it's either gui or quickstart, I can't be 100% sure if any changes to the version fo the gui since the last release help
<gary_poster> rick_h_, ack thanks.  benji, ok that is emergency status if it is the GUI.  hangout in https://plus.google.com/hangouts/_/calendar/Z2FyeS5wb3N0ZXJAY2Fub25pY2FsLmNvbQ.j0rk5d371ph8331ijtf48t2uj0 ?
<benji> gary_poster: on may way
<gary_poster> Hey Makyo do you have a few minutes to talk me through a basic d3-ism, so I can fix a bug, please?
<Makyo> gary_poster, yep
<gary_poster> thanks Makyo https://plus.google.com/hangouts/_/calendar/Z2FyeS5wb3N0ZXJAY2Fub25pY2FsLmNvbQ.j0rk5d371ph8331ijtf48t2uj0
<bac> jujugui: review of bundle proofing: https://codereview.appspot.com/21610044/
<bac> i've got to walk the dog but can respond later
 * bac -> out
<benji> gary_poster: the quickstart doesn't appear to take a bundle as a parameter (this is a branch of lp:juju-gui/juju-quickstart)
<gary_poster> benji it takes a file
<benji> % .venv/bin/python juju-quickstart -e ec2 --debug bundle.json
<benji> usage: juju-quickstart [-h] [-e ENV_NAME] [--environments-file ENV_FILE]
<benji>                        [--version] [--debug] [--description]
<benji> juju-quickstart: error: unrecognized arguments: bundle.json
<gary_poster> benji when you say juju-quickstart --help does it say that it takes a bundle?
<benji> gary_poster: nope
<benji> could this be the wrong branch
 * benji looks at frankban's recent branches
<Makyo> quickstart-bundle-file
<Makyo> Is the branch
<Makyo> benji,  ^^^
<benji> ah!  thanks
<gary_poster> benji, no
<Makyo> Should have been merged, though
<gary_poster> been merged
<gary_poster> benji http://pastebin.ubuntu.com/6361207/
<gary_poster> benji bzr branch lp:juju-quickstart should work
<gary_poster> I will try that too
<rick_h_> bac: done with notes
<gary_poster> benji, yup
<benji> gary_poster: ah, I was tricked by the decoy at lp:juju-gui/juju-quickstart
<gary_poster> benji, I dunno what you did but that is trunk.  can't worry about it now, glad it is working, doing something else
<rick_h_> jujugui need a charmworld review for the deployer_file_url please. https://codereview.appspot.com/21370044/ 
<rick_h_> and I'm outta here to get the boy from school. Let me know if there's anything I can pick up in the morning
<bac> thanks rick_h_
<bac> i should've been more specific about that node link.  the old version was actually a syntax error
<huwshimi> Morning
<gary_poster> morning huwshimi 
<gary_poster> benji, any news?  past your EoD, but if you have any info before you depart it might help me if I stare at it
<huwshimi> gary_poster: Hey
<huwshimi> rick_h_: Hey, if you happen to be around at some stage, I'm building the dropdown widget but I can't get it to load in app.js http://paste.ubuntu.com/6361408/
<benji> gary_poster: nothing useful; findings thus far: 1) the quckstart gives you cryptic error messages if you have python-juju installed instead of go-juju, 2) lxc won't create a saucy container for me complaining about 404s
<huwshimi> rick_h_: I've done a bunch of copy and paste to build the framework of that widget, but it's not giving me any errors, it's just not finding it...
<gary_poster> ack benji.  I saw lore local provider bugs flying around today.  I plan to stay away from it until it seems to settle down.  apparently broken in precise
<gary_poster> s/lore/more/
<benji> gary_poster: I wasn't using juju-local, I just wanted a way to install juju-core; the instructions on the web site don't work on "rabid" or whatever the R one is
<gary_poster> benji, ack, I think
<gary_poster> oh, you were trying to create an lxc container in which you would install juju
<gary_poster> and stuff
<benji> right
<gary_poster> gotcha
<huwshimi> rick_h_: Oh, modules-debug. I forgot to add it there :(
<rick_h_> huwshimi: yea, modules-debug
<rick_h_> huwshimi: and is widgets already the right place?
<rick_h_> new widgets.Dropdown (widgets = Y.juju.widgets?)
<rick_h_> looks like it
<rick_h_> huwshimi: I'd suggest doing juju-dropdown vs just dropdown
<rick_h_> but meh, it could be more reusable I guess. But then I'd ditch the rest of the juju namespace bits
<huwshimi> rick_h_: Yeah, it is, thanks. As soon as I wrote out the question to you it made me think that something external needed to be hooked up and a grep found modules-debug
<huwshimi> silly things
<rick_h_> huwshimi: all good, been there/done that
<huwshimi> :)
<huwshimi> rick_h_: Is there something I have to do to reference Y.namespace('juju.widgets').Templates? Templates is undefined...
<huwshimi> rick_h_: The widget requires 'juju-templates'
#juju-gui 2013-11-05
<rick_h_> huwshimi: it's not in widgets. All templates are in juju.templates? /me has to check
<rick_h_> var templates = Y.namespace('juju.views').Templates
<rick_h_> huwshimi: ^^
<rick_h_> it's part of the "build all the templates at once" that kind of makes it have to be in views.Templates to work
<huwshimi> rick_h_: Oh awesome. I copied and pasted but somehow got that wrong :)
<gary_poster> jujugui, https://codereview.appspot.com/21440044 needs one review.  Hopefully I won't be around to look at that review until tomorrow. :-)
<bac> rick_h_: morning
<rick_h_> bac: morning
<bac> hey rick_h_, nm, false alarm doing qa.  the correct version of the deployer didn't install for me.
<rick_h_> bac: oh, that's not good. Did deps not update?
<bac> rick_h_: i'm about to have to run to the vet.  i'm proposing a change to charmworld to do logging when baskets are rejected.
<bac> rick_h_: i don't know.  i removed the canary file and re-ran 'make deps' and then it was good
<rick_h_> bac: ok cool. thanks
<bac> rick_h_: when broking local/lib/python.../juju-deployer only had a deployer.py file
<bac> none of the rest of the package
<rick_h_> bac: hmm, ok. Yea that was the old 0.1.1 version I replaced in an earlier branch. 
<rick_h_> jujugui morning crowd, review request when the time opens up please https://codereview.appspot.com/21370044
<benji> rick_h_: I'll take a look
<rick_h_> benji: thanks
<benji> good morning gary_poster; re. YAML vs. JSON: JSON is a subset of YAML, so unless our YAML parser is broken it should work
<rick_h_> benji: that was my thought. I know the proof stuff 'just worked' that way. To inline the yaml it almost turns into json
<gary_poster> benji, ah ok, good to know, thanks
<gary_poster> benji, rick_h_ I was thinking we should review my notes and strategize in a few minutes?
<benji> +1
<rick_h_> gary_poster: sure thing, I've got the deployer code down and matching up email to source code atm
<gary_poster> cool.  will ping in about 5 or 10.  thank you
<gary_poster> benji, rick_h_ now ok?  If so, https://plus.google.com/hangouts/_/calendar/Z2FyeS5wb3N0ZXJAY2Fub25pY2FsLmNvbQ.j0rk5d371ph8331ijtf48t2uj0
<gary_poster> benji, rick_h_ forgot one other suspicious thing to keep an eye out for: when I first did a ps auxwww | grep python, there were three instances of the same server.  My guess/hope is that these were from the multiprocessing stuff, but another possible sharp corner to be aware of
<benji> hmm, ok
<bac> jujugui: question about patching. i need to do this:
<bac> with patch.object(job, 'proof') as proof:
<bac> but the method returns two things *and* i want to check calling args
<bac> the default object fails as it unpacks too few things and that form doesn't seem to allow a lambda
<benji> bac: you can provide your own double that will be called and can do whatever you want and return whatever you want
<bac> benji: so just forgo the loveliness of assert_called_with and hand-roll it?
<benji> bac: that's the only way I know to do what you want
<bac> ok, thanks
<benji> it is bad design, you have to opt out of the goodness to do something slightly unusual.  A better design would grow with you.
<bac> benji: mind looking at http://paste.ubuntu.com/6364840/ and see if you can suggest a way to make it work?
<bac> what i have doesn't work b/c the scope isn't the same when the mock machinery actually calls it.
<benji> bac: first you have to port the entire codebase to Python 3 and then replace the "global" keyword with the "nonlocal" keyword 
<benji> bac: if you don't have time to do that before lunch, you can make called_with a list and append the value to it to capture it
<bac> i bet that won't work.  it still won't be in scope.  /me tries
<benji> it will
<benji> trust the master
<benji> the problem isn't that it isn't in scope, it is that there is a new scope and your assignment is shadowing the outer scope's value instead of replacing it
<bac> you were right, i was wrong.
<bac> a blind man could tell you that
<bac> what the hell
<bac> benji: but when i break in the original there was no called_with
<benji> bac: I bet you had the "global" declaration in there, in which case it was grabbing called_with from the module namespace, but there wasn't one there
<bac> nope, i added the global later
<benji> hmm, I'm out of ideas then
<bac> benji: review? https://codereview.appspot.com/21880043/
<benji> bac: sorry, pairing with Rick right now
<bac> well, that's bad as rick_h_ was my next choice!
<rick_h_> lol
<bac> benji, rick_h_: this branch is blocking QA and release of charmworld.  it is very short.  if you can squeeze it in i'd really appreciate it.
<gary_poster> Can I review reasonably?
<benji> bac: ok, we'll take a look
<bac> gary_poster: oh, i thought you were gone.  you're all red in my client
<gary_poster> that scared everyone away ;-)
<bac> sure, anyone can do it
<gary_poster> ok cool
<bac> i'm not being pissy just anxious to move on
<gary_poster> sure, that's what they all say
<bac> i was pissy when they told me at 9am the vet wouldn't be coming in until 11.  that resulted in them agreeing to drive jojo home after the appointment.
<benji> bac: LGTM
<bac> ty
<bac> benji: when in rome
<benji> :)
<gary_poster> hey rick_h_ , has your deployer file url branch landed?  I don't see it in staging.  If it is there, I will try to use it in the GUI
<rick_h_> gary_poster: no, I was updating per review this mornign and haven't submitted it yet due to the burning barn
<gary_poster> rick_h_, oh ok.  mm.  wasted work though.  how much effort to get that in?  can bac take it, maybe?
<rick_h_> gary_poster: give me 3min to finish it up and hit rv-submit]
<gary_poster> rick_h_, awesome, given. :-) thanks
<rick_h_> gary_poster: submitting to the lander now. will take a min for it to run it through/merge it
<gary_poster> cool, thank you.
<rick_h_> gary_poster: ok, merged in successfully. Not sure how long it'll take staging to pick it up
<gary_poster> awesome, thanks
<rick_h_> gary_poster: so just using the deployer_file_url attribute in the api response should be good for that url
<gary_poster> cool
<gary_poster> on it
<hatch> hey all
<rick_h_> party
<hatch> how's things?
<rick_h_> on fire :)
<hatch> good on fire or bad on fire? haha
<hatch> when are our stand-up now that the time has changed 
<rick_h_> hatch: in 45min
<hatch> oh ok cool . I didn't want to be Kate tomorrow if it was earlier for me or something 
<hatch> great picture from Robbie on the twitters :) 
<rick_h_> hatch: linky
 * bac reboots charmworld staging due to memory issues
<hatch> rick_h I'm on my phone at this conf so I can't but it was within the past 24h
<rick_h_> hatch: cool, see it
<hatch> rick_h there is a typescript talk this afternoon...thought you'd enjoy that :P
<gary_poster> jujugui call in 10
<Makyo> jujugui call in 2
<Makyo> All throughout the call, the dogs play.  As soon as the call stops, they crash. Go figure. http://ubuntuone.com/gallery/56atUQ5IHr3CkOXeT605zL/IMG_20131105_091512.jpg
<gary_poster> Hey Makyo.  Feel like taking a break to make a video? :-)  We have a request from ODS
<Makyo> gary_poster, sure.  What for?
<gary_poster> Forwarding
<gary_poster> Makyo, sent
<Makyo> Got it, thanks!
<gary_poster> cool
<gary_poster> thank you
<Makyo> gary_poster, do they want a version of jcastro's talk in video form, then?  Drag the havana/swift bundle in simulator, while showing real deployments in EC2?
<jcastro> mark's talk you mean? he did that during the keynote
<jcastro> (that was very cool by the way)
<gary_poster> Makyo, yes
 * gary_poster is glad staging was not down at the time
<gary_poster> that appears to be the issue now
<jcastro> oh I thought you guys planned for all that
<jcastro> so basically he did it off the cuff?
<rick_h_> what did he do? /me hasn't managed to watch the video yet. He used comingsoon?
<gary_poster> yeah he did it off the cuff.
<gary_poster> rick_h_, will forward
<rick_h_> gary_poster: cool, setting up in the background to listen to while deploys run
<gary_poster> jujugui, small and easy: https://codereview.appspot.com/21980043
<gary_poster> (I hope :-P)
<Makyo> gary_poster, like https://docs.google.com/a/canonical.com/document/d/1mXcYaNHWP85o11UoiQZTXhgn5vt-5eU27fWgHFbIKGA/edit?usp=sharing  ?
<gary_poster> Makyo, sounds great!  Thank you
<Makyo> Cool, on it, then.
<gary_poster> rick_h_, you around?  Would like to verify two apiv2 -> apiv3 changes.  First, when searching, what was an api call with 'charms?text=foo' is now 'search?text=foo'.  Second, what was 'http://localhost/api/2/charm/mysql-1/icon.svg' is now 'http://localhost/api/3/charm/mysql-1/file/icon.svg'.  Does that look right?
<rick_h_> gary_poster: not sure on the search one. Looking
<gary_poster> thanks
<rick_h_> gary_poster: that looks correct
<gary_poster> awesome thanks rick_h_ 
<gary_poster> jujugui, I now have https://codereview.appspot.com/22000043 , which removes the charmworldv3 flag and APIv2 class.  That's in addition to https://codereview.appspot.com/21980043/ , which still needs some reviewing love.  I'm now going to try and get https://code.launchpad.net/~ya-bo-ng/juju-gui/linkify-charm-descriptions/+merge/192852tweaked and merged, and then I'm moving to changelog...
<rick_h_> gary_poster: k, looking at the first one
<gary_poster> thank you rick_h_ 
<rick_h_> gary_poster: should we decode jujucharms.com/bundle/%7Ejorge ?
<rick_h_> the ~
<gary_poster> rick_h_, oh yeah I was going to and forgot, thanks
<rick_h_> gary_poster: ok, LGTM on that one with that
<rick_h_> gary_poster: also we need to make sure we switch off staging back to manage soon (don't want to have that fall through the floor)
<gary_poster> rick_h_, +1.  Once bac gets charmworld trunk deployed to manage then I think we can
<bac> gary_poster: jcsackett found a problem with charmworld that got turned on yesterday in staging.  he's going to revert it.  having that done is a blocker for updating production.
<gary_poster> ack thanks for update bac
<hatch> rick_h_, hey once I add those tests to that IE fix branch can it be landed? Did you QA? 
<rick_h_> hatch: no
<hatch> oh ok, think you'll have time for that today? or are you swamped?
<rick_h_> on fire sorry
<hatch> alrighty np I wont rush to finish the tests today then :)
 * hatch hands you a bucket of water
<hatch> just in case you get too hot :)
<bac> jujugui: review por favor: https://codereview.appspot.com/21790045
<gary_poster> bac, would do it but I think one of the charmworld people would be better for those topics
<bac> abentley: i just wrote my first migration for charmworld.  would you mind taking a look?  https://codereview.appspot.com/21790045
<abentley> bac: Sorry, I'm gonna be a while.
<bac> abentley: ok.  let me see if sinzui is available
<abentley> bac: No, we're working on some stuff right now.
<bac> oh
<rick_h_> gary_poster: ping for 'wtf is going on' catchup? https://plus.google.com/hangouts/_/calendar/Z2FyeS5wb3N0ZXJAY2Fub25pY2FsLmNvbQ.j0rk5d371ph8331ijtf48t2uj0
<abentley> bac: I think when es-updates creates a new index, it uses an old index, not mongodb, as its source.  And it does this only when there is an incompatible schema change.
<bac> abentley: so you're saying the old data will remain in es?
<abentley> bac: Yes.
<bac> abentley: advice on the right way to proceed?
<abentley> bac: I think drop all the bundle entries from elasticsearch.
<abentley> bac: The bundles are going to disappear until the next ingest and that's okay, right?
<bac> yes, that's what we want
<abentley> bac: So yeah, I think that's the thing to do.  But do you need to delete the bundles at all?
<bac> abentley: many of the bundles that are in charmworld have errors so we'd like for them to be removed so that after the next ingest only error-free bundles are presented.  does that answer your question?
<abentley> bac: Just raises more questions, I'm afraid.  The policy with charms is that proof failures do not prevent them from being stored and displayed.
<abentley> bac: The store was what determined whether a charm was acceptable to display.
<abentley> bac: We did at one point hide charms with proof errors, but stopped doing that because proof errors did not mean that the charm was unusable.
<abentley> bac: I believe marco is changing it so that errors indicate that charms are unusable.
<bac> abentley: The store does not know about bundles.  It is our decision for the first release of bundles to reject those with errors.  At a later date, when we've had time to update the UI, we will store those in error and show the problems.
<abentley> bac: If it were me, I'd hide those with errors, rather than preventing them from entering the store.  What happens when proof changes and some of the bundles currently in the store start to fail proof?
<bac> abentley: that's a good point.
<abentley> bac: Anyhow, that's my 2 Â¢.  You do need to delete bundles from elasticsearch, but changing the way you handle errored bundles can wait.
<bac> abentley: thanks, i really appreciate your input.
<abentley> bac: np
<gary_poster> benji, hey.  I exported from comingsoon and got this: http://pastebin.ubuntu.com/6366975/
 * benji looks
<gary_poster> benji, it looks like it is right.  I wonder if this is because jujucharms.com is old
<benji> ooh, that's good
<gary_poster> or if people are exporting from pyjuju or something
<benji> might be, at least it means we are closer to a global fix than we though
<gary_poster> right
<gary_poster> so, you agree that we appear to already be in good shape here, right?
<gary_poster> in terms of our release goals
<rick_h_> gary_poster: replied to your email, but correct. So we're just on the charm and deployer bits to move forward 
<gary_poster> cool thanks Rick.  I'm writing a status email for the peeps list
<huwshimi> Morning
<bac> hi huwshimi
<gary_poster> hey huwshimi 
<gary_poster> benji, re your card "Not-quite-private-enough charms were loaded into charmworld.  People want them out.": that is in urgent already
<gary_poster> deleting
<benji> gary_poster: k
<benji> I searched for a card with that issue number and couldn't find one, so I made that one
<bac> gary_poster: aaron suggested some changes so could you do a final of https://codereview.appspot.com/21790045
<gary_poster> bac on it
<gary_poster> bac, sorry, oven fire and other excitement.  back and then must run. trying to finish...
<gary_poster> bac LGTM 
 * gary_poster running
<huwshimi> rick_h_: Would it be a bad idea to have custom templates per instance of the dropdown widget? As in do something like TEMPLATE: Y.namespace('juju.views').Templates[this.get('template')]; (which doesn't work as is... but you get the idea)
<huwshimi> Another option would be for the widget to not handle the template at all, but just handle the show/hide
<huwshimi> I guess that might work well with the need for rather different content for each dropdown...
#juju-gui 2013-11-06
<bac> rick_h_: you around?
<gary_poster> hey huwshimi, I'm running away, but I'd like your review of https://codereview.appspot.com/22200045 sometime today when you get a chance.  Would like your opinion of the effect in particular, but code thoughts are more than welcome as well.
<huwshimi> gary_poster: No problems, I'll take a look
<gary_poster> thanks!
<gary_poster> bye :-)
<huwshimi> gary_poster|away: Bye
<hatch> hey Makyo great video :D
<Makyo> hatch, thanks; working on finding a transcoding that doesn't artifact so much before I submit it proper.
<hatch> it sounds so 'official' :D
<Makyo> That maaaaay have been the goal? :P
<hatch> haha - well I'm glad to be back at work tomorrow - I'll try and put together my notes for everyone else
<Makyo> Rock on~
<rick_h_> huwshimi: sorry, been out
<rick_h_> huwshimi: I'd say that it can just have a very generic initial template.
<huwshimi> rick_h_: It's all good, I've made progress :)
<rick_h_> huwshimi: just a div container to stuff content into and other can deal with it/run with it
<rick_h_> huwshimi: ah, cool stuff then. Going ok then?
<huwshimi> rick_h_: Yeah, just writing tests at the moment.
<huwshimi> rick_h_: It'll need a good review as there is stuff that is probably wrong, but I wasn't sure how else to do it :)
<rick_h_> huwshimi: sure thing
<huwshimi> rick_h_:  One question however, to add a new test file do I just add the name to test/index.html? Do I need to do anything else to get the test runner to see them?
<rick_h_> huwshimi: yea, just add to the test/index.html
<huwshimi> hmmm...
<rick_h_> huwshimi: make sure there are no syntax errors or otherwise in the console or it'll look like the file just doesn't load
<huwshimi> Ah right, that could be it
<huwshimi> oh, lint is not happy :)
<rick_h_> lol
<huwshimi> Yep, that was it
<rick_h_> party
<BradCrittenden> hi frankban
<frankban> hi bac 
<bac> hi frankban. i was going to ask you for a charmworld review, but it was simple and urgent so i self-reviewed. bad me.
<frankban> bac: np
<rick_h_> bac: thanks for the link fix. I assumed urls would be generated with request.route_url and not need updating. Should have looked :/
<rick_h_> morning frankban, welcome back to the party :) if any of the cards don't make sense let me know. I wrote them up as we were hitting things yesterday so might not be all that clear headed. 
<frankban> rick_h_: cool, I have to go for a while now, I'll ask when back, thank you
<rick_h_> frankban: have fun
<rick_h_> benji: started making cards out of the todo list and marked our 'debug' card as done. I've got to run the boy to day care this morning so will be in/out for a sec this morning. 
<benji> rick_h_: k
<bac> rick_h_: i'm just glad that the fix was easy.  after applying my bundle proofing stuff i was paniced when i saw everything produce 404s
<bac> rick_h_: it occurs to me we should give jcastro and others a chance to fix their bundles before we roll the proofing onto production.  on staging only two bundles make it through proofing, none of jorge's
<rick_h_> bac: well, we need it in production so when he runs proof locally it finds all the issues to fix
<rick_h_> bac: imo, the only way to fix it all is to run charm proof on them and get the list of issues
<bac> rick_h_: i agree.  my thought was he'd want a chance before they all disappear on production
<rick_h_> bac: meh, I think with release pushed we'll just bribe him to push changes today/tomorrow :)
<rick_h_> doh, he's not around atm for me to bug him about bribery
<bac> rick_h_: i just don't want to get grief like "i had this big demo and there was nothing there".
<bac> like the recent demo mark did without warning us
<rick_h_> bac: ah, yea that I can get behind. 
<rick_h_> bac: good point
<rick_h_> luca___: I now feel like I have permission to reply to all questions with "Use the force luca"
<rick_h_> luca___: and why did that email make me very very afraid? lol
<luca___> rick_h_: lol
<luca___> rick_h_: you'll find out haha
 * rick_h_ goes to get his antacids
<luca___> rick_h_: a 4 hour meeting 1-2-1 meeting with Mark only leads to one thing
<rick_h_> CHANGE!
<luca___> rick_h_: bingo
 * rick_h_ is one smart cookie
<rick_h_> ok, so as long as I'm right to be afraid
<rick_h_> benji: lol, looks like I should read the comments more. See #3 in http://bazaar.launchpad.net/~hazmat/python-jujuclient/trunk/view/head:/jujuclient.py#L41
<benji> hmm
<frankban> rick_h_: ping
<rick_h_> frankban: pong
<gary_poster> frankban, welcome back :-)
<frankban> rick_h_: I see you are working on the python jujuclient. I was thinking that, while we are there, we could also add an easy fix to deploy() to support ToMachineSpec (required by quickstart), but that's not a blocker now
<frankban> rick_h_: (and currently quickstart just overrides deploy)
<rick_h_> frankban: ok, if it's not for the bundle release I say add a bug/card and happy to go back to it but right now it's release blockers or bust
<frankban> rick_h_: cool, ok
<rick_h_> there's all these lovely disclaimers that jujuclient is "pre-alpha software...use at your own risk" but it's kind of in our productin story now so I assume we'll have to be spending some time getting it out of pre-alpha stage :/
<bac> hi gary_poster.  staging looks good and i think it is ready to roll out to production.  but none of jorge's bundles pass the proof test.  so, should we give him a chance to fix them before rolling out to production and having them disappear?  (only two bundles are on staging, hatch's and my fake one.)
<frankban> rick_h_: yeah. do you have a minute to talk about those charm cards?
<rick_h_> frankban: sure thing
<bac> frankban: how's the new laptop?
<gary_poster> bac, no.  They are not a loss until they work. :-)
<gary_poster> bac, IOW, fire away
<rick_h_> frankban: https://plus.google.com/hangouts/_/7ecpihg9purkm4gn74bkdgttpg?hl=en
<bac> gary_poster: ok, i've already composed a message.  i'll just change the wording to be more "you're currently screwed, here's how to fix it."
<frankban> rick_h_: Charm tests do not install requirements.pip to be able to run make test. how to reproduce? it seems to me that test calls unitttest and ftest, and both depend on setup
<gary_poster> bac, lol ok
<gary_poster> bac, do you disagree with me?
<frankban> bac: the new laptop is enjoying its long trip from shangai, in venice now, hpefully it will arrive tomorrow
<bac> gary_poster: given the way high-level presentations are being done with no warning, i worry that someone will discover no bundles are available at an inopportune moment.
<gary_poster> :-)
<bac> gary_poster: i guess maarten is mostly at risk
<bac> sabdfl has already done his.
<gary_poster> bac, but they are already using comingsoon, which is tied to staging, which already has the characteristic you are worried about
<bac> ohhhh
<gary_poster> (and they were using the file dnd functionality)
<bac> ok, non-issue then
<bac> off to RT
<gary_poster> cool
<gary_poster> :-) thanks
<bac> will release r446
<gary_poster> yay!
<bac> rt filed, jjo ack'ed
<gary_poster> cool.  thank you very much for pushing this through (at all hours of the night), bac
<bac> was no problem.
<bac> gary_poster: there is another 'make jujucharms release' card.  if it is need could you add a description?
<gary_poster> bac, yeah.  the intent is "make [non-manage] jujucharms release"
<gary_poster> suggestion on spelling that? :-)
<gary_poster> rick_h_, do you have some time to review https://codereview.appspot.com/22200045/ ?  You would be obvious choice, but can ask others if you are putting out fires or otherwise busy
<rick_h_> gary_poster: sure thing. Looking now. I saw someone looking at it so moved on. 
<gary_poster> cool thanks
<gary_poster> rick_h_, would you like a liberal dosing of comments?  If so, can do.  Was just wondering about that myself.
<gary_poster> rick_h_, and thank you for review
<rick_h_> gary_poster: yea maybe. I mean it's pick-apartable just read dense. 
<rick_h_> gary_poster: I thought about trying to move the function out of linkify, but you're using the array in that scope so I guess you can't
<gary_poster> rick_h_, right.  ok cool.  I'll give a whirl with some comments and  then land it.
<rick_h_> gary_poster: maybe just whitespace around the inner function would help?
<gary_poster> rick_h_, lol ok
<rick_h_> gary_poster: cool, thanks. 
<hatch> morning all
<rick_h_> morning hatch 
<bac> wow, with 99.92% reporting the VA attorney general race is separated by 53 votes out of 2.2M cast.
<rick_h_> ouch
<hatch> wait for the recount....lol
<hatch> rick_h_: did you get the lastpass v3 update? It not longer looks like someone threw up it's UI
<rick_h_> hatch: yea, I went to ping you on it but you were afk
<rick_h_> hatch: figured you'd be happy
<hatch> yup, it's a little slow now but oh well
<rick_h_> hatch: meh, new release. I'm sure i'll pick up as they get it going
<hatch> I got the popup during my talk yesterday lol
<hatch> that was pretty comical
<rick_h_> nice
<rick_h_> incognito mode ftw
<rick_h_> I've tried to start using that for talks since the great 'google voice text has arrived' debacle :)
<hatch> haha
<gary_poster> rick_h_, beddah? thoughts? http://pastebin.ubuntu.com/6370735/ http://pastebin.ubuntu.com/6370754/
<rick_h_> gary_poster: lol, nice
<gary_poster> :-)
<rick_h_> gary_poster: hatch appreciate it when he gets sent in to fix something or add another bit of parsing :)
<gary_poster> :-) cool
 * hatch goes to look
<hatch> haha
<hatch> thems a lot of comments
<gary_poster> heh
<hatch> ugh so many emails
<gary_poster> jujugui if you hard reload you will see I changed comingsoon to point back to manage
<rick_h_> gary_poster: thanks!
<gary_poster> welcome
<hatch> I also learnt yesterday that you removed the charmworld flag during the demo....lol
<rick_h_> lol
<rick_h_> hatch: what? You didn't get a local running copy to demo with?!
<rick_h_> hatch: boy you leaned a lot of lessons in one talk
<hatch> "and as you can see here when I do a search for 'hatch' I don't get....oh I do....well looks like they removed that flag"
<hatch> haha
<gary_poster> heh
<gary_poster> sorry
<hatch> rick_h_: ahh it was totally fine
<gary_poster> hey rick_h_ I have to head out, but "home" link is missing from charm browser in comingsoon.  investigate
<hatch> I deployed to ec2 the trunk
<gary_poster> please?
<hatch> to demo how it worked
<rick_h_> gary_poster: ugh, looking. 
<gary_poster> rick_h_, wait I may be stupid
<rick_h_> gary_poster: hmm, I see it /me hard reloads
<jcastro> hey fellas
<bac> hi jcastro
<jcastro> so the errors on "blah blah is not a type of string" and stuff
<gary_poster> rick_h_, nevermind me.  sorry for the heart attack.  as you were. ;-)
<jcastro> are the only errors in my bundles
<rick_h_> gary_poster: ugh, but I'm hitting an issue where I can't get from browse to env and back :/
<rick_h_> ugh, and I'm out of it as well. Environment isn't a button oops
<gary_poster> rick_h_, that's a UX thing, yeah
<rick_h_> jcastro: also remove constraints for now please. 
<gary_poster> rick_h_, however, if you want to see a bug, try this. ;-)
<jcastro> I only have constraints in one
<rick_h_> ruh roh...
<jcastro> but the other ones, those aren't my fault right?
<rick_h_> jcastro: yea, we chased down a lot of bug fun with it. Appreciate it pointing out the issue
<rick_h_> jcastro: 'other ones'?
<jcastro> "blah blah is not a type of string" and stuff
<rick_h_> jcastro: yea, the config values must be of the right type. That should be good to go now
<jcastro> ok, so I need to update something then
<rick_h_> jcastro: so if it says it's an integer it has to be a interger not "9" or anything
<jcastro> also, if that's good to go then how come brad's tests came back with all of them flunking?
<rick_h_> jcastro: there was a bug in the gui exporting them all as strings, but should be fixed
<gary_poster> rick_h_, (1) in quicksearch, choose "applications" (2) in quicksearch again, type a string to search for and then press return to make it happen.  In query string you'll see you are now constrained by category.  not cool because you can't escape category anymore
<jcastro> rick_h_, ugh, so basically
<rick_h_> gary_poster: yea, we hit that at the sprints. 
<jcastro> I have to redo all my bundles
<rick_h_> jcastro: no, small tweaks. Remove quotes if the config is an int
<gary_poster> jujugui, need to head to do fam stuff for a bit (middle school thing I mentioned).  back in 1.5 hours hopefully
<rick_h_> jcastro: should be small/easy. Which one are you looking at?
<bac> jcastro: can you proof lp:~jorge/charms/bundles/mediawiki-scalable/bundle ?
<jcastro> wordpress
<jcastro> bac, ah, that one is crashing something
<bac> yeah, i'm looking at it
<bac> may just be indentation
<jcastro> rick_h_, constraints removed from discourse
<rick_h_> jcastro: and wordpress please
<jcastro> huh weird, that one had blank ones
<jcastro> done
<rick_h_> jcastro: yea, and they were of the wrong names to work 
<jcastro> oh they all do
<jcastro> ok so how do I fix these bundles
<jcastro> if it's a string it looks like this:
<jcastro> "binlog-format": MIXED
<rick_h_> jcastro: which fields are failing?
<jcastro> "block-size": 5 <-- and this one looks like an int
<rick_h_> jcastro: it shold list all the ones it doesn't like
<jcastro> a bunch
<rick_h_> dude, helpful, pastebin or something
<jcastro> working it!
<rick_h_> :)
<jcastro> http://paste.ubuntu.com/6370941/
<jcastro> http://paste.ubuntu.com/6370942/ for wordpress
<rick_h_> jcastro: kthx, will look into it. Looks like something is still borked
<jcastro> yeah
<jcastro> that's why I'm like wait a minute, it's not my fault I'm not passing tests! :p
<jcastro> bac, oppressor!
<bac> ha
<bac> rick_h_: is this an issue that should stop our release?
<rick_h_> bac: yes, the type checking in proof is bad still if that's the latest code on mjc
<rick_h_> bac: did the release with the type check fixes go out?
<bac> rick_h_: manage has not been updated.  i don't know what rev you're talking about, on staging i assume.
<rick_h_> bac: ah so maybe it's not an issue then
<bac> manage is very old
<rick_h_> bac: ah ok then. That would explain it. Ok, I thought I had fixed it. Will try to do a local test then
<bac> rick_h_: actually i say old but i mean it has not been updated as part of this effort.  not sure what version of proof is on it.
<rick_h_> bac: looking for the branch where I fixed the type checks
 * bac wishes heartbeat showed rev
<bac> rick_h_: i don't know how to tell what is running on manage
<rick_h_> bac: yea, well if heartbeat isn't showing rev then it's old enough I think. abel had that added I thought
<jcastro> hmm, should I update my charm tools now?
<rick_h_> jcastro: yea, need to do that. bac's email had notes on the rev, but it sounds like the server isn't updated with the latest atm either
 * jcastro nods
<bac> rick_h_: no, abel's follow-on branch for revno in heartbeat has not landed even in trunk yet
<jcastro> rick_h_, I was already in the car ready to drive over and kill you if you were going to make me remake every bundle
<rick_h_> jcastro: heh, trying not to man. Trying
<rick_h_> bac: I could have sworn I saw that go by with a LGTM, man I'm not keeping up today
 * rick_h_ isn't seeing the changes I expect to see
<rick_h_> bac: ok, I'm looking for changes in r437
<rick_h_> bac: I thought there was a deploy in progress yesterday after the rollback so had expected that to be on mjc?
<bac> no
<bac> mjc has not been touched.  an RT is waiting
<rick_h_> ok, so jcastro then ignore proof until the server gets updated sorry. 
<rick_h_> bac: rgr, thanks. Sorry for the confusion
<bac> rick_h_: i had a disconnect and thought charm-proof was hitting staging
<bac> actually i just didn't think too hard about it
<rick_h_> bac: no, I thought proof hit mjc once he released charm-tools 1.0
<rick_h_> err 1.1 that is
<bac> i'm sure you're right
<bac> i just tried changing my /etc/hosts to point mjc to sjc but get SSL errors
<rick_h_> yea, ugh
<rick_h_> best thing is to hit proof with curl or httpie
<rick_h_> err, the staging proof endpoint
<rick_h_> bac: http://paste.mitechie.com/show/1058/
<bac> cool
<rick_h_> that's it, going back to bed. I give up. "bzr shelve --all ... bzr: ERROR: bzrlib.errors.MalformedTransform: Tree transform is malformed [('missing parent', 'new-6')]"
<frankban> guihelp: I need two reviews and one QA for https://codereview.appspot.com/22300044 . Is anyone available? Thanks!
<Makyo> frankban, on it.
<frankban> (quickstart + python)
<frankban> thanks Makyo 
<Makyo> jujugui call in 10
<bac> jujugui: manage.jujucharms.com updated.  heartbeat shows failure on bundles but ingest just started at :45.  http://manage.jujucharms.com/heartbeat
<rick_h_> bac: cool, thanks!
<rick_h_> jcastro: re-run your proof please. When I charm proof your wordpress bundle I get no output
<bac> \o/
<bac> rick_h_: this one still has issues ~jorge/charms/bundles/mediawiki-scalable/bundle/
<jcastro> rick_h_, CONFIRMED! \o/
<bac> jcastro: ^^
<jcastro> ok
<rick_h_> bac: k, looking
<rick_h_> bac: oh, it's got like blow up and die kind of issues :/
<bac> rick_h_: did you say having 'constraints' with defaults causes problems?
<bac> yeahs
<rick_h_> bac: not with proof, but in the real world yes
<bac> oh, so worst case scenario
<bac> yay for false positives
<rick_h_> bac: well we don't proof constraints right now. and if they're not 100% correct for Go the deployer will die in a fire
<rick_h_> bac: this was the big result of yesterday's barn burning joy
<Makyo> jujugui call in 2
<rick_h_> bac: oh hmm, that json error is out of the remote proof call. So something isn't happy in our end after all perhaps
<benji> rick_h_: I'll look at your branch and then we can touch base as to what to do next.
<rick_h_> benji: did you want to catch up then and coordinate. Did you still have the diff we had going on in the charm stuff, the branch for the deployer and such?
<benji> rick_h_: yep, I have all those diffs around
<rick_h_> benji: cool, sorry about that. You had most of the other stuff so i took the 'easy' one right off. :/
<frankban> macbook users, any suggestion for installing saucy on a mac? I've found http://blog.kylebarlow.com/2013/05/installing-ubuntu-1304-raring-ringtail.html but each guide is different
<hatch> frankban: are you going to do it on metal or vm?
<bac> hi evilnickveitch did you see the comments jcastro made in the Google doc on bundles we delivered to you in SF?  i was wondering if that was something i needed to pursue or if you were adding the extra info.
<frankban> hatch: metal
<hatch> hmm sorry I don't have any input then :)
<bac> rick_h_: how shall we pursue the proof issue jcastro's branch raises?
<frankban> hatch: any reason to prefer fusion?
<hatch> frankban: I just find it removes any driver issues
<bac> frankban: i prefer fusion b/c managing vms is much easier and less stress when upgrading
<hatch> so things like the touchpad, camera, etc work as expected
<bac> and it just works
<hatch> bac: you're using fusion? I've been using parallels but it doesn't seem to support new Ubuntu well at all
<bac> snapshot the vm, upgrade to the next release, and if it doesn't work just rollback or restore from backup
<bac> yep, i'm running mavericks, fusion 6, and saucy
<bac> only issue is i have to manually set my display size when rebooting
<hatch> ahh
<bac> i like 1920x1200 and it doesn't stick and picks another
<hatch> my issue is that parallels doesn't release the parallels tools for Ubuntu very fast so the display drivers get corrupted
<frankban> bac: interesting, yeah, snapshots are cool
<hatch> it's kind of a mess
<hatch> so now I'm running it w/o X
<rick_h_> bac: sorry, drink refill. Need to trace what's going on. I'm debugging a local charm-proof instance to see what mjc is returning right now
<bac> frankban: when running metal i'd have to mentally clear the next four hours before upgrading in case something went crazy.
<bac> rick_h_: ok, let me know if i can help.
<rick_h_> bac: ok, mjc is throwing a 500 internal server error at that bundle
<rick_h_> bac: so the thing to do from here would be to toss it at a local charmworld instance like that pastebin I showed you and see what is failing
<bac> frankban: the touchpad is also a big issue.  everything works mac-like even when in fusion.  on metal i found it unusable as brushing it would jump the cursor.  may have improved by now.
<bac> rick_h_: i wish proof had a hidden option for specifying the server
<rick_h_> bac: +1 
<rick_h_> bac: so I pdb;d int the proof and this is the string it's sending up http://paste.mitechie.com/show/1063/
<rick_h_> bac: so I'll run charmworld locally and use that + httpie to test it and see what's up
<rick_h_> bac: strange, I get a "could not parse the yaml file" error returned when I test locally :/
<rick_h_> bac: ok, it passes on mjc as well
<bac> rick_h_: he has a 'services' option on one of his services that looks dubious to me.  removing it didnt' help though
<rick_h_> http://paste.mitechie.com/show/1064/ <- bac
<rick_h_> bac: so it must be something in how the charm proof is sending the values that it doesn't like ?
<bac> yep that's the unhelpful error i've seen
<rick_h_> bac: because if I pdb stop and print the bundle_file contents then I get the correct error message
<rick_h_> bac: well, it's what we've got to show though. It's unparseable yaml. It doesn't know why though. 
<rick_h_> bac: but the proof code is getting a 500 server error. I wonder if sinzui is still setup to get emails of those
<bac> rick_h_: yes
<rick_h_> bac: yea, then we should try to get a copy of that email then. I can't dupe it locally so would be helpful to see the traceback in the email
<rick_h_> bac: ooh, changed the url in the proof library to my localone and got the error
<rick_h_> bac: http://paste.mitechie.com/show/1065/
<rick_h_> bac: can you add type support in proof for float then?
<rick_h_> bac: looks like I just missed that as a valid type for a config value. I didn't see that in the docs. :/
<bac> oh
<bac> brb
<Makyo> Ffffffff
<Makyo> Forgot to destroy environment.
<Makyo> I'm so bad at this.
<hatch> lol
<hatch> Makyo:  maybe you should create a script to destroy the environment after a 24h timeout lol
<Makyo> I'm seriously pondering that, yeah, just a cron job that runs nightly with something like `juju destroy-environment -e aws-goju -y`
<hatch> haha
<bac> Makyo: i've found my little notification-based watcher very helpful.
<Makyo> Oh?
<bac> i put something on our blog ages ago
<bac> not super smart but gives me enough of a nudge to know when things are running
<bac> Makyo: http://jujugui.wordpress.com/2013/04/09/alerts-for-running-ec2-instances/
<Makyo> Oh!  Right!
<Makyo> Will look into that.  Thanks bac
<rick_h_> thanks benji 
<hatch> rick_h_: http://bgrins.github.io/devtools-snippets/#console-save
<rick_h_> bac: so added a card for the float type not supported in the bundles section. If you get a chance to grab it before me yay if not I'll try to get to it. It's not killer atm, because it'll fail to ingest, but needs fixing
<rick_h_> hatch: cool
<bac> rick_h_: ok. i'm doing a low priority feel good branch right now but will be free after my late lunch
<rick_h_> hatch: my console's been messed up a while actually. I need to look into it
<rick_h_> bac: rgr, thanks. 
<evilnickveitch> bac, its okay, i am taking care of it...
<bac> evilnickveitch: ok, that's wonderful
<benji> grr, I somehow destroyed my entire bzr config
<bac> rick_h_: when you have a moment i think you'll appreciate this:  https://codereview.appspot.com/21930046
<rick_h_> bac: just LGTM'd :)
<rick_h_> bac: ty!
<rick_h_> benji: :(
<bac> :)
<gary_poster> ok, so after consuming the backlog, this is my understanding.  Could people please confirm or correct?  (1) frankban has Makyo reviewing https://codereview.appspot.com/22300044 and needs a second reviewer. (2) bac got m.j.c updated.  It mostly works except we discovered that proof needs to bless floats, and this breaks one of jorge's bundles.  bac and/or rick_h_ are working to fix. (3) rick_h_ and bac are also worki
<gary_poster> ng with jorge to make his bindles ingestable otherwise. (4) benji is working alone on the constraint whitelist charm deployer integration work, and I'd love to know status & expected timeline.
<gary_poster> s/bindles/bundles
<gary_poster> sound right?
<rick_h_> gary_poster: somewhat. rick is trying to punt to bac to do the float fix and that should take care of jorge's bundles. Rick messed up and did the whitelist bit and it's up for review to hazmat and benjie has reviewed it. 
<gary_poster> ah cool
<rick_h_> gary_poster: and benji and rick are scheduled to sit down and go over what's next since rick grabbed the whitelist owrk on accident
<benji> gary_poster: I am working on getting all the branches squared away for proposing
<rick_h_> but benji seems to be having bzr issues atm
<gary_poster> benji, ok great
<benji> I am, but have decided to ignore it as much as possible for the moment.
<gary_poster> bac, are you, uh, catching rick_h_'s punt of the float issue?  I'm assuming that means a fix to proof, an upgrade to charmworld, and another deployment?
<rick_h_> gary_poster: yea, if benji and I are in good shape I can grab it, but since it's only blocking one charm atm figured it was lower priority. 
<gary_poster> rick_h_, agreed
<gary_poster> frankban, giveing you second review of branch.
<gary_poster> Makyo, how is video?
<gary_poster> giving
<Makyo> gary_poster, http://www.youtube.com/watch?v=vbRkfejThkk I'm investigating a way to get less artifacts in the video.
<hatch> Makyo: yeah I was wondering why the HD versions looked SD
<Makyo> The video capture is HD, but transcoding screwed it up.
<hatch> hmm interesting
<Makyo> RecordMyDesktop records at 15fps and kdenlive hates that :P
<hatch> can you upload the raw file to youtube?
<frankban> gary_poster: great thanks
<Makyo> hatch, the raw file has no sound.
<frankban> Makyo: thanks for the review, destroy the environment!
<Makyo> frankban, haha, thanks :D
<gary_poster> Makyo, cool!  Did you send to mramm?  Getting something sooner ratheer than later might be important
<hatch> Makyo: ahhh gotcha
<Makyo> gary_poster, will do, it's uploading to u1 now
<gary_poster> Makyo, awesome.  please cc me
<gary_poster> frankban, you have two LGTMs and a QAOK :-)
<frankban> gary_poster: thanks cool
<hatch> Makyo: ie link branch is proposing so fire-up-that-ie!!!!!!!!!
<Makyo> IE is NEVER worth nine exclamation points >:/
<hatch> but...but....
<Makyo> Gear down there, big rig.
<hatch> ERMAHGERD IE!!!!!!!!!
<frankban> gary_poster: nice suggestion thanks, I can include an example in the command line, but the charm version is required, e.g. cs:~juju-gui/precise/juju-gui-116. juju-core does not accept an unversioned CharmURL 
<gary_poster> frankban, ah ok, cool
<gary_poster> and lol hatch
<hatch> haha
 * Makyo boots ie
<hatch> hmm I'm getting a number of errors in IE on comingsoon
<hatch> 'all' is undefined and 'modules' is undefined
<gary_poster> :-( 
<hatch> investigating...
<hatch> oh they are the source map url errors
<hatch> Makyo: while you're in your IE can you also see if you can repro https://bugs.launchpad.net/juju-gui/+bug/1246971 (I cannot)
<_mup_> Bug #1246971: Connecting service fails the first time in IE10 <juju-gui:Triaged> <https://launchpad.net/bugs/1246971>
<hatch> ohh
<hatch> our source maps use //@ which looks like cause errors in IE10
<hatch> was this switched recently or has it always been like this and noone has noticed"
<rick_h_> hatch: I thought that came up before. /me is trying to recall. 
<rick_h_> hatch: does it only effect sourcemaps though? 
<rick_h_> didn't we turn off sourcemaps at one point because of this?
<gary_poster> hatch no change afaik
<benji> hatch: I don't know of any recent source map work (I did the original work but I don't remmeber if the //@ was there from the start)
<rick_h_> I remember the //@ 
<hatch> rick_h_: yes teh application works as expected
<rick_h_> hatch: ok, so maybe it was just ignored. I do recall the //@ causing IE issues though
<hatch> ok this must be a recent change in IE10 then
<hatch> we should create a high/urgent card to fix
<hatch> apparently it being in the source will break all debugging in IE11
<hatch> according to some of the VS blogs
<rick_h_> IE11? ugh
<hatch> I'm going to create an urgent card for this as it'll block release for ie10
<Makyo> hatch, can't repro.
<hatch> Makyo: thanks, closing
<rick_h_> hatch: I'm confused. App works as expected but blocks release?
<gary_poster> hatch, same q :-)
<hatch> rick_h_: gary_poster: IE10 pops up alerts() asking to debug the error if debugging is turned off
<hatch> but if you ignore those, it works fine :)
<gary_poster> hatch ugh :-(
<gary_poster> ok hatch, you tackling that? :-)
<hatch> yeah sure
<gary_poster> ok thanks.  hatch, would really like to release tomorrow.  if expedient solution is possible, lemme know.  For example, in theory, we don't serve sourcemaps for IE.  Probably not easy to do, but if it were, I'd be fine with it for tomorrow.
<gary_poster> Fix would be nicer, of course
<gary_poster> and something we'd need soon after
<hatch> oh yippee Makefile
<hatch> ;)
<gary_poster> heh
<gary_poster> hatch can pair if you'd like
<hatch> I should be ok - I was just in a talk yesterday about Grunt and how nice the Gruntfile was to read :D
<gary_poster> :-P
<rick_h_> hatch: http://uploads.mitechie.com/books/Managing_Projects_with_GNU_Make_Third_Edition.pdf enjoy
<gary_poster> lol
<hatch> haha yeah I have that already
<hatch> doesn't make Make any nicer to read :P
<rick_h_> come on, make shell your new language to learn this year :)
<hatch> ontop of Go and Python eh?
<rick_h_> sounds like a plan #moretolifethanjs
<hatch> pretty soon I'll have to forget how to speak English to fit any more languages in there
<rick_h_> benji: heads up, uploading a dist for the updated jujuclient here: http://uploads.mitechie.com/lp/dist/jujuclient-0.14.tar.gz so we can pull it down and test things out in the charm since it's a local dep. 
<benji> rick_h_: cool, I'll test it soon
<rick_h_> benji: ok, I'm going to go fix the charmworld bug then. Let me know if you need a hand with anything on the other side.
<benji> k
<hatch> oh nice the source map code is in node not bash
<hatch> haha
<hatch> go benji
<benji> I don't always write JS, but when I do it is to avoid writing shell script.
<hatch> hahaha ^5
<benji> ^5
<benji> we need an IRC symbol for a fist bump... or not
<hatch> =B áº=
<hatch> lol
<benji> heh
<hatch> Makyo: here is the link to the branch if you didn't already have it https://codereview.appspot.com/21430043/
<bac> rick_h_, benji: we seem to have a bit of a problem: http://manage.jujucharms.com/heartbeat  look at the charm/basket queue
 * benji looks
<benji> hmm
<rick_h_> bac: yea, was just going to ask on that.
<bac> i don't really know how to proceed.  we have no visibility into prodstack
<rick_h_> bac: yea, we've got to ask is for log files. 
<rick_h_> bac: and hope something jumps out from there. 
<rick_h_> bac: no vangaurd right now :/
<bac> hi sinzui.  we did a release to manage.jujucharms.com today.  it seemed to well but then i noticed on http://manage.jujucharms.com/heartbeat the charm queue has grown crazy
<sinzui> well is ingest running?
<sinzui> hmm, I think Abels unlanded branch would tell us a little more
<rick_h_> looks like no vanguard right now and it's not dead in the water to go emergency on it. 
<rick_h_> I've got a branch that needs a deploy up for review so we can watch it, get another deploy and get logs from it at that time?
<rick_h_> bac: have time to review https://codereview.appspot.com/22370044
<rick_h_> bac: for the float/config validation fix in proof
<bac> sinzui: i'm not sure if ingest is running
<sinzui> bac, how long has it been since the deploy?
<sinzui> and if someone did the deploy, do we know the heartbeat was sane afterwords
<bac> a good while.  let me look
<bac> sinzui: 15:27UTC.  no, the heartbeat page showed the two failures b/c the bundles were removed by the migration and are to be repopulated by ingest
<sinzui> yep, I expected that. Ingest takes about 15 minutes, but we are hours later
<bac> sinzui: so queue runs will just keep adding on?
<bac> if ingest were started now it may not be able to empty the queue
<bac> rick_h_: jjo is not the vanguard but he is around.
<bac> he did the deploy
<bac> i'm not sure what to ask for
<bac> rick_h_: i did your review but don't understand why an unknown type is not an error
<rick_h_> bac: we'd ask for the logs. There's app.log I think in the charm directory var/app.log (there's a few othersin there)
<rick_h_> bac: yea, I wasn't sure what to do on that so went with ignore, but updating it to throw an error. 
<bac> rick_h_: yeah, the log dir is a confusing jumble to me
<rick_h_> I think that's the best way to keep that up to date
<rick_h_> bac: yea, we'll figure it out though
 * bac looks at staging
<sinzui> bac, The last item in the heartbeat indicates we are queue work, but not ingesting, webops can empty queues easily enough 
<rick_h_> bac: sinzui ping'd jjo but looks like he ran away. 
<rick_h_> bac: sinzui will keep an eye on vanguard
<sinzui> baskets are going down
<bac> rick_h_: thanks
<bac> sinzui: you mean the basket count?
<sinzui> yes
<rick_h_> sinzui: oh, interesting
<bac> yes, berry berry
<rick_h_> crazy queue
<sinzui> We can see that something is pulling
<rick_h_> yea, we expect most bundles to fail so maybe it's got backed up and taking a few to get to one of the good ones :/
<bac> the count is going down but it hasn't found any valid bundles yet
<bac> meanwhile on staging there are 11 bundles that are valid
<sinzui> I saw
<rick_h_> ok, well keep an eye on the queue and see if we can get down to 0
<bac> the entire set is about 14 baskets so something more than 14 bundles
<rick_h_> bac: right, but I'm thinking the queue was already huge from something? The charms queue is a LOT larger than the number of charms in the store as well
<rick_h_> 32K ?
<bac> rick_h_: i don't have the initial numbers.  32k is nuts.
<rick_h_> bac: right, hmm the countvs just jumped up again
<bac> we should ask to have the queue process paused
<rick_h_> yea
<bac> there are 2410 charms.  queue has been run ~16 times since launch.  16 * 2410 = 38560
<rick_h_> bac: heh, well good to know we got through 500ish
<bac> well, ok, maybe it was only run 15 times
<sinzui> bac, rick_h_ I think this can help bring some sanity to the queue numbers http://pastebin.ubuntu.com/6372276/
<sinzui> rick_h_, bac: I timed ingest to take between 13 and 17 minutes last august. I think we want to watch the numbers to learn what the current time is
<rick_h_> sinzui: rgr, thanks. Will see if we can get a vanguard to take it up 
<rick_h_> sinzui: bac jjo is chatting now
<sinzui> rick_h_, bac: Note that http://manage.jujucharms.com/tools/store-missing says it has not completed a single charm ingest for 4 hours
<bac> interesting
<rick_h_> sinzui: yea, I think this might lead to getting logs and finding an issue
<sinzui> Did we do something mad like change ingest to get every history revision?
<bac> sinzui: queue finds the last 10 revisions
<rick_h_> sinzui: well there's the backfill that does 10 revisions back
<rick_h_> so not every, but 10
<bac> rick_h_: can jjo determine if ingest is running?
<rick_h_> bac: not asked. he's EOD'ing in 30min so get anything we need now
<bac> it may make sense to turn off the queue cron and run it once manually
<bac> rick_h_: he seems to be responding to your queries
<rick_h_> asking for the logs now
<sinzui> rick_h_, We discusses this last July and August. back history has to be done in a separate proc because we need to guarantee responsive ingestion. I think 10 rev is less that 150 minutes but certainly way to long the the 15 minute balance we setup
<bac> rick_h_, benji: is this deploy to production the first with 10 revision history turned on?
<rick_h_> bac: I didn't think so. :/ it's been a long while
<bac> rick_h_: i don't know the last rollout to prod
<rick_h_> bac: ok, so charm queue is 0
<bac> so ingest is running
<sinzui> bac, rick_h_ http://manage.jujucharms.com/tools/store-missing
<sinzui> ^ happy
<Makyo> gary_poster, ping
<bac> sinzui, rick_h_: is there anything about the proofing on production that would hang?  egress firewall rules?
<sinzui> let watch heartbeat for 15 minutes
<bac> wait, we're talking to ourselves so it can't be an issue
<rick_h_> bac: no, proofing doesn't hit the net. Just the db
<gary_poster> Makyo, sorry! was on phone with Jeff and lost track o' time.  coming
<Makyo> gary_poster, ah, okay!
<bac> rick_h_: well, ingest hits a cw url which hits the db
<bac> rick_h_: i'm just trying to think about differences with prod that could be hanging ingest
<sinzui> bac. I am not current with proof changes. I think the last change made in cw was to include the version of proof in the cache to ensure the right version is always installed
<rick_h_> bac: ah, understood
 * hatch sorry those of you who import your coke from Mexico http://gizmodo.com/mexican-coke-is-ditching-cane-sugar-for-high-fructose-c-1459437477
<sinzui> hatch, you have just ruined my day
 * sinzui goes back to steaming his brownies to make them soft again
<hatch> lol
<bac> sinzui, rick_h_: baskets just dropped from 16 to 13.  no bundles added though
<rick_h_> bac: cool. 
<sinzui> bac, why is basket ingestion so slow less than 1 a minute
<bac> sinzui: unclear
<bac> hatch: that makes no sense.  1 peso/liter isn't that much.  i think this is just another 'New Coke' moment to force a change to cheaper corn-based coke.  glad i don't drink the stuff anymore
<rick_h_> sinzui: not sure, you'd think it'd be faster. One file to process really
<hatch> bac: You're probably right
<sinzui> rick_h_, bac, given the immediate fix we saw in the missing list. It is clear that the queue must be drained to get updates to the db and es. I think we might need to slow down the supervisord proc enqueue less often
<rick_h_> bac: sinzui yea, just got the queue refilled, but didn't get through the bundles :/
<sinzui> rick_h_, I see the bug.
<bac> rick_h_: but it doesn't make complete sense.  the items are processed in order, right?  so it will eventually get to all of the bundles.  yet we see none being added
<bac> or is it not ordered?
<rick_h_> benji: so my jujuclient fix got shot down. He's prefer we band-aid it in the deployer middleware itself and not in the deployer/client. 
<benji> rick_h_: ooh
<bac> sinzui: and?
<sinzui> rick_h_, bac, we only queue charm tips, but the queue size indicates we are ingesting revisions. that is F*CKING crack
<rick_h_> bac: right, but there were 16? so we're at 27, so we've got through 5 of them so far. 
<benji> rick_h_: well, I guess we can resurect my branch, since that's what I was doing
<rick_h_> benji: +1 
<sinzui> production will is on crack and may die of complications in a few hours
<rick_h_> benji: he's not a fan of the limited 'approved' set of stuff and doesn't want the band-aid in the client
<bac> sinzui: but this scheme has been running on staging with no issues
<rick_h_> benji: and he's all on board for fixing the communication/deployer as a library issues
<benji> rick_h_: re. library: cool!
<bac> rick_h_: my point is since deployment hours ago no valid bundles have been ingested.  that makes no sense
<rick_h_> bac: understood
<sinzui> bac, I see staging trying to do that. At least it gets little cycles.
<bac> rick_h_: sinzui: do you want to move to a hangout in 10 minutes?
<rick_h_> bac: sure
<bac> feel free to fire one up now but i can't join for a few
<rick_h_> benji: let me know what you need to help move this forward then. gary_poster fyi ^^
<sinzui> bac. Nonetheless. There are only about 130 good charms and 600 bogus charms. The queue looks at those for new revisions. I think charmworld is asking if a revision ever changes, which is a violation of reality
<gary_poster> rick_h_, was following along as best I culd while on a call.  could you give me a quick hangout so I can make sure I understand, before you have the bigger powow?
<rick_h_> gary_poster: https://plus.google.com/hangouts/_/7acpjqjf6evpv7503n0uq4psjg?hl=en
<sinzui> rick_h_, bac, when the charm queue clear we got updates, since we cannot ever clear the bundle queue we don't get updates. I makes sense to me
<bac> rick_h_: ping when you're readu
<bac> s/readu/ready/
<rick_h_> bac: https://plus.google.com/hangouts/_/7acpjqjf6evpv7503n0uq4psjg?hl=en
<rick_h_> bac: you're right, sorry didn't think it through
<hatch> Makyo: another ie branch to qa :) sorry https://codereview.appspot.com/22450044/
<sinzui> bac, rick_h_ there are exactly 764 branches charms and bundles to process in Lp. Production might know about 20 more deleted charm branches. Any queuing greater than that is sign of insanity. I the db is corrupt with bogus charms. It might be fair to say that the queue/ingest is being feed revisions, not charms and bundles. It would be okay to queue revisions if the queue could just ask for changes since a last date, but I am
<sinzui>  sure that code was not written
<rick_h_> sinzui: we think bundles is hitting egress filtering and causing it to timeout/take long
<bac> rick_h_: https://rt.admin.canonical.com//Ticket/Display.html?id=65726&results=564596e05af8d34ac09865c9e1dfbc69
<rick_h_> bah
<bac> sinzui: i agree with your thoughts on queueing up revisions and we need to fix that.  as rick_h_ said, the immediate problem causing the delay is the bundle proofing is being blocked by an egress firewall and timing out on each proof request.
<rick_h_> bac: worse than that, it's not running the right version of charmtools!
<sinzui> rick_h_, charmtools in in the download cache. Are you saying the wrong cache was deployed to production?
<rick_h_> sinzui: so we tried to change the proof url since it was hard coded to manage.jujucharms.com. The version installed is 1.1
<rick_h_> sorry, 1.1.0 and it should be 1.1.2
 * rick_h_ is checking download-cache list right now
<rick_h_> bah, there's something bigger there. the wrong version is installed, why the runs aren't throwing errors/exceptions to the wind I don't know. 
<sinzui> Abel added charm-tools to the download cache to ensure the code we deploy has a matching proof. LTS was running ancient charm-tools
<rick_h_> sinzui: yes, and the download-cache and requirements.txt are updated to 1.1.2
<rick_h_> sinzui: somehow it's not updated on production. I asked for a change to bundles.py and there was no bundles.py on the machine because it was still at 1.1.0
<rick_h_> https://pastebin.canonical.com/100009/ was the result of looking for anything charmtools
<rick_h_> we lost our webops and waiting for a new person to torture. approx 2hrs according
<rick_h_> according to jjo
<hatch> I'm going to run and grab a bite/run an errand, be back in < 1h
<sinzui> rick_h_, I think this step in deploy is supposed to guarantee we get the download cache ./build-charmworldgo ${REVNO?}
<rick_h_> sinzui: ok, will look into that. thanks for the heads up
<rick_h_> sinzui: is that something in the webops add-on? I can't find that file in the charm/source?
<sinzui> rick_h_, yep
<rick_h_> sinzui: ah ok. Then definitely good to know since I can't see it atm
<sinzui> rick_h_, they make a fat charm: https://wiki.canonical.com/InformationInfrastructure/WebOps/CDO/Charmworld
<sinzui> They pull the revno we request and pull download-cache, then pack them into the charm for upgrade-charm to extract
<rick_h_> sinzui: rgr, thaniks
<sinzui> rick_h_, I need to get children from school. I am searching for a branch that might contain the script that makes the fat charm
<rick_h_> sinzui: ok, thanks. I'm sure we'll be able to move forward once the new vanguard arrives. 
<bac> rick_h_: proposed change to marco
<bac> rick_h_: we're in a lull so i'm going to step out for a bit before it rains again.  that ok with you?
<hatch> bak
<benji> rick_h_: I have to go to my appointment now, but here is a WIP branch: lp:~benji/+junk/sanitize-constraints-and-other-fun 
<benji> rick_h_: as best I can tell we just need to fill in the tests and implementation for the sanitize_constraints function and we'll be good to go
<benji> I invision the remaining tests to be in their own class and directly excersize the function
<benji> after that we just have to do some test deploys and we should be done
<hatch> Makyo: not sure what happened it didn't get the tests before https://codereview.appspot.com/21430043/ here is a proposal with the tests
<hatch> but thanks for both qa's
<rick_h_> benji: rgr, I'm working on broken charmworld deploy right now, but will see what I can do
<benji> rick_h_: thanks
<hatch> gary_poster: so looks like all of the urgents are done - shall I now switch to the spreadsheet?
<gary_poster> hatch, lemme take a look at the kanban...while you review this, please? :-D https://codereview.appspot.com/22500043
<hatch> it's on!
<Makyo> hatch, ah, cool, thanks
<gary_poster> hatch, hook up the import control?  That's on the spreadsheet *and* in the bundle lane *and* hopefully fast. :-)  After that, yeah, spreadsheet.
<hatch> got it!
<gary_poster> cool thank you
<hatch> gary_poster: in this branch I deleted the importexport.js file that confuses everyone
<gary_poster> hatch sounds good.  It had confused me too :-)
<gary_poster> benji, rick_h_, I need to go in 9.  Can be back later.  Where are we?  https://plus.google.com/hangouts/_/calendar/Z2FyeS5wb3N0ZXJAY2Fub25pY2FsLmNvbQ.vq3atlo18hgrrbfqbii5cgqch4 ?
 * gary_poster back in 2 hours or so
<huwshimi> Morning
<hatch> morning huwshimi
<huwshimi> hatch: Welcome back :)
<hatch> spanks - glad to be back
<hatch> albeit only for a couple days haha
<huwshimi> hatch: Are you off next week?
<hatch> huwshimi: only Friday and Monday, going snowboarding
<huwshimi> Oh nice!
<hatch> yeah I'm horribly addicted to it
<huwshimi> hehe
<hatch> huwshimi: this morning https://plus.google.com/118445028821328031751/posts/R5RRM1QRxNt
<huwshimi> hatch: Woah!
<huwshimi> hatch: Is that at your house?
<hatch> right beside
<huwshimi> wow
<hatch> yeah it's awesome here in the winter :)
<hatch> if you can handle the temperatures that is haha
<huwshimi> hatch: I think we had about two minutes of snowflakes amongst the rain this year
<hatch> haha - most would prefer that :)
#juju-gui 2013-11-07
<rick_h_> gary_poster: around?
<rick_h_> or do I start the email
<rick_h_> ok, well email replied to 
<bac> rick_h_: you still around?  i see  heartbeat is happy now.  thanks for getting it up again!
<bac> rick_h_: i read the backlog on webops but i'm not sure what happened
<bac> rick_h_: review done
<rick_h_> bac: thanks
<rick_h_> bac: yea, there was confusion. It was changing that url in the charmtools + restarting supervisord that runs the ingest process
<rick_h_> bac: but took a while to find someone and to debug that there's not an issue with the version of charmtools on the server
<rick_h_> bac: ok, I'm submitting the branch now. So in the morning we need to do another deploy to the rev after this lands (assuming the lander doesn't hate me)
<rick_h_> bac:  the tricky part is that the production-overrides should be used to build a new config, but config changes don't happen all that often so cross your fingers on that part
<bac> ok, i followed it all but that last part
<rick_h_> bac: so the production_overrides.ini
<rick_h_> bac: where the port number was added?
<bac> rick_h_:  if it lands do i need to do anything but request a deploy?
<rick_h_> bac: hopefully no. THe cowboy will be erased by upgrading charmtools and the deploy should go smoothly
<bac> rick_h_: thanks again for getting this figured out.  let's hope tomorrow goes smoother.
<rick_h_> bac: rgr, we're all good. If we can get the charm stuff into shape we'll be good to land this baby and have a long good weekend :)
<bac> rick_h_: rt.  good night.
<rick_h_> thanks for getting that branch going. I'm going to go turn the brain off for the night. See ya tomorrow
<gary_poster> thank you both rick_h_ and bac
<hatch> evening
<huwshimi> hatch: Hello
<hatch> hows it going?
<huwshimi> Good thanks, yourself?
<hatch> good good
<hatch> trying to fix my vm
<hatch> doesn't look like parallels supports ubuntu 13.10 no matter what
<huwshimi> Ouch
<huwshimi> hatch: Dual boot?
<hatch> I'll have to look into that on the mac mini
<huwshimi> hatch: Buy a new computer? :P
<hatch> haha - I willllll but I have pretty much convinced myself I need the 15" with the graphics card
<huwshimi> heh
<hatch> did you end up picking up a new one?
<huwshimi> Yeah, well, it's in the post
<huwshimi> Should arrive next week
<hatch> cool what did you go with?
<huwshimi> hatch: Air, i7, 8GB RAM, 256GB SSD
<hatch> oh cool that's the other option I was thinking of going with
<huwshimi> So couldn't just pick up in store
<hatch> that thing should fly :)
<huwshimi> Yeah, hopefully
<hatch> well this thing has the 2.3 I5 with the intel 3000 and 16GB of ram
<huwshimi> hatch: In one of the stores the guy was trying to convince me of the retina 13" MBP as for $100 more you get faster CPU plus retina, but it weights 400 grams more.
<huwshimi> hatch: Nice. How much?
<hatch> no idea I bought it in 2011
<hatch> haha
<hatch> it only supports 8GB of ram
<hatch> :)
<huwshimi> Oh right, your current computer
<hatch> yeah
<huwshimi> hatch: How much would the new MBP cost?
<hatch> so this thing -is- fast enough for everything i need it for, but no games
<hatch> lots.....lol
<huwshimi> heh
<hatch> sec
<hatch> $2600+tax
<hatch> assuming I don't upgrade the cpu or storage
<hatch> compared to the $1500 for the air (equipped like yours)
<hatch> so the question is....do I need to game for that $1100 more? :D
<huwshimi> hatch: haha
<hatch> it would cost me that for a gaming rig
<hatch> so really....
<huwshimi> hatch: Or a console
<hatch> true, but I can't take the console with me
<hatch> at least not very easily
<huwshimi> hatch: Although the CPU will mean running test faster etc.
<hatch> the single core speed isn't that much faster on the pro than the air
<hatch> it just has 2 more cores
<hatch> and our tests are single threaded right now
<huwshimi> true
<hatch> so it'll only be like 10% faster
<huwshimi> hatch: But you're running VMs etc. as well
<hatch> are you trying to convince me to buy the mbp?
<hatch> your a bad influence
<huwshimi> haha
<huwshimi> nope, I mean, I think, uh...
<hatch> ok when you get yours you can be my test monkey
<hatch> you can run the tests and maybe some games for me to see if they run :P
<huwshimi> heh
<huwshimi> hatch: I bought it through a local store which meant a saving of $140 vs the online Apple store, but it means I don't have an online tracker to refresh every five minutes
<hatch> haha
<hatch> small price to pay for the $140 discount :)
<huwshimi> yeah
<hatch> I'm going to try and hold out until a few weeks before the next sprint so I'll have some time to decide
<huwshimi> I actually didn't realise you could get them cheaper than the Apple store
<hatch> I didn't either
<huwshimi> heh
<rick_h_> morning
<rick_h_> howdy frankban, did you tinker with benji's branch at all?
<frankban> rick_h_: yes. I made some changes, trying now bootstrap + deploy
<rick_h_> frankban: ok cool, in looking at his branch I think the missing thing is that we need to send a dict to the deployer call vs the string from sanitize_constraints
<rick_h_> normally the deployer uses a string because it passes it to the cli as `juju deploy --constraints=""'
<rick_h_> frankban: ok, let me know how it goes and what I can do to help. I'll stop messing with his branch for now then. 
<rick_h_> and grab coffee...
<frankban> rick_h_: I added that and moved the sanitize logic from base to views, so that, if a constraint is passed but not supported, we can deny the bundle deployment and send to the GUI the error message
<frankban> I also created a new deployer tarball with the fix to the deploy() call, adding the missing parameter
<frankban> rick_h_: ^^^
<gary_poster> sounds great frankban
<gary_poster> thank you
<bac> gary_poster: staging has been updated with the changes rick landed last night.  it looks happy.
<gary_poster> awesome bac.  thanks
<bac> gary_poster: i shall now proceed with an RT to get production updated and less stupid
<gary_poster> heh, great
<bac> gary_poster: you're aware of our decision to temporarily fork charm-tools for expediency until we can remove it entirely?
<gary_poster> yes, bac.  I'd like to talk more about the "remove it entirely decision" once the heat of the moment has passed and see what other options we can pursue, but yes, I know we have a three-stage story of "hack production" (last night), "hack the branch with a fork" (last night and today), and "make it better" (ASAP, such as next week).
<rick_h_> frankban: awesome
<bac> gary_poster: yeah, that's a more rational statement.
<gary_poster> cool
<rick_h_> rational? are we still at rational? :P
<gary_poster> we have next week for that :-)
<frankban> gary_poster, rick_h_: it seems to work, writing some missing tests and proposing
<rick_h_> frankban: rgr, will look at the MP when it hits
<gary_poster> awesome!
<frankban> btw, new macbook arrived this morning, left ignored in its box
<bac> rick_h_: the new deploy produced https://pastebin.canonical.com/100054/
<rick_h_> frankban: we all appreciate the sacrifice
<bac> i think it is not a problem but causes the webops to be concerned
<rick_h_> bac: ?!
<rick_h_> bac: yea, I'm looking for the hook to see what it's doing
<bac> jujugui: post deploy charmworld is good: http://manage.jujucharms.com/heartbeat
<rick_h_> bac: cool, waiting to see if the bundles get processed vs blocked
<rick_h_> bac: yea, not sure on that migrate thing. I don't understand why it's doing that
<bac> ok
<rick_h_> bac: well, not sure what prepare-upgrade --init is 
<bac> rick_h_: i'm making a card about the queueing of multiple revisions per sinzui's comments yesterday
<rick_h_> ooh, let's see if my heartbeat auto reload worked
<rick_h_> bac: ok, I htink we're fine. In my testing last night we were around 8ish minutes to process the queue. 
<rick_h_> so we're well under the 15min window for now
<rick_h_> yay for auto reloading heartbeat page!
 * rick_h_ is facinated by the little things in life
<benji> cool bac
<rick_h_> gah, docstrings or bust 
<rick_h_> bac: all 0 so yay!
<bac> rick_h_: yes, not waiting to timeout due to egress rules speeds up the processing dramatically.  go us.
<rick_h_> :)
<rick_h_> bac: it's almost like...you called that one lol
<bac> gary_poster: webops wants us to move staging off canonistack so it is more production-like
<rick_h_> bac: I've got a card for that
<gary_poster> bac ack on call
<bac> oh good
<rick_h_> bac: it'll need to be a dupe since we won't be able to auto upgrade it from CI
<rick_h_> it'll be more a 'practice deploy' than anything from what I can tell
<bac> oh, ok
<bac> dearlordletitwork.jujucharms.com
<rick_h_> lol
<rick_h_> bac: oh, that whole output was just to test if the prepare-upgrade flag was available to the migrate script
<rick_h_> bac: I guess it's an artifact that on the first time you update the charm/code they need to be in sync. this protects them from being out of sync
<rick_h_> bac: since the charm doesn't want to run migrations prepare-upgrade if that's not a valid command
<bac> rick_h_: hmm, can it be squelched or a message saying "ignore the following non-error"
<rick_h_> bac: i bet -h goes to stdout or something. I think the best thing is to just remove the check from the charm
<rick_h_> we're past a point where it's a useful check
<bac> rick_h_: ok.  i made a card for it.
<rick_h_> bac: rgr
<benji> morning rick_h_, what's the constraint sanitization status?
<rick_h_> benji: frankban has a branch he's getting up for review
<benji> rick_h_: great!
 * gary_poster running.  back in 1.5 or 1.75 hours.  (what a week)
<frankban> gary_poster, rick_h_, benji: the branch is up for review and qa: https://codereview.appspot.com/22810043
<benji> frankban: I'll be glad to do one or both; I'll start on the review.
<rick_h_> frankban: looking
<frankban> benji, rick_h_: thank you both
<benji> frankban: I thought that we wanted to ignore invalid constraints, not generate an error.  Have I misunderstood the requirements or your code?
<rick_h_> benji: we were ignoring when it was in the jujuclient because we could not get errors out of it to the user
<rick_h_> benji: are these errors able to get to the user from the new location?
<rick_h_> frankban: ^
<frankban> rick_h_: all the bundle validation errors are immediately reported as a GUI notification
<rick_h_> frankban: ok cool then. 
<frankban> benji, rick_h_: I am not sure the GUI server is the right place for an extensive bundle validation (I also added an XXX), and we can change it later. however ISTM good to have at least a weak firewall before starting all the deployer/ProcessExecutor machinery
<rick_h_> frankban: yes, we've talked about trying to create a validation library re-used by all entry points for users. (charmtools for proof, deployer for a manual deploy of a bundle)
<rick_h_> frankban: so long term I think we'd piggy back off the deployer doing validation 
<rick_h_> frankban: since it's already doing some very limited validating currently
<benji> I'm QAing the branch now.
<frankban> rick_h_: such a bundle validation library could help also in quickstart
<rick_h_> frankban: +1
<bac> rick_h_: yes, please
<rick_h_> frankban: replied with a couple of comments, I didn't see the versions update in the hard coded places in the utils.py ?
<rick_h_> frankban: ignore me, I did see it. :)
<rick_h_> even commented on it. /me sips more coffee
<frankban> heh, thanks rick_h_, re deployer version, is it ok if instead I add a comment in the hardcoded versions in utils, also mentioning the source branch for that sdist? 
<rick_h_> frankban: yea, that's cool. Just something so we remember it's our fork 
<hatch> this morning I found out that you can stop g+ from showing posts from a community but still be part of the community
<rick_h_> frankban: since it's not obvious looking at things
<hatch> best feature ever
<frankban> rick_h_: great, and good point
<rick_h_> wooo, it's working!
<rick_h_> will check a failure here in a second. 
<hatch> hehe oh Chrome
<hatch> "C:\fakepath\maarten.yaml"
<hatch> that's one pretty crazy fakepath :D
<rick_h_> gary_poster: so the only QA thing is that the two services were stacked on each other. I thought mysql wasn't deployed. :/
<rick_h_> frankban: got the error when I had invalid constraints, deploy worked on jcastro's bundle 
<frankban> gary_poster: for when you are back, I think we are hitting this: http://bugs.python.org/issue1692335
<frankban> rick_h_: http://i.imgur.com/1skzJ3u.gif
<rick_h_> lol
<rick_h_> benji: did you also get the layout issue in qa?
<benji> rick_h_: I had some non-branch related QA issues; redeploying the charm now
<rick_h_> benji: ah ok
<rick_h_> benji: do me a favor and don't touch the layout as it comes up then and see if you get the same stacked service issue. I moved it before the relations where set so not sure if it'd do a redraw or anything later in the process
<benji> rick_h_: k
<rick_h_> frankban: ok' LGTM'd with qa ok and notes on the qa process. 
<frankban> cool
<benji> rick_h_: the services didn't pile up, but I think the canvas scrolled to make it look like they did
<rick_h_> benji: hmm, ok. 
<rick_h_> ok, so time to release the hounds?
<frankban> gary_poster: confirmed the problem is http://bugs.python.org/issue1692335 . easily fixable in more than one ways, let's have a quick call when you are back
<frankban> rick_h_: we can be able to add a quick fix to the charm/deployer error handling before releasing the charm. AFAIK the GUI is ready to be released
<rick_h_> frankban: k
<bac> uh-oh, searching on charmworld for '~bac' makes for some unpleasantness
<rick_h_> lol
<rick_h_> oops
<rick_h_> bac: requested the log file from webobs and we'll see what hte traceback is
<rick_h_> although should be able to dupe locally I guess
<bac> rick_h_: yeah.  i'll look at it.  we'll probably get hate mail from curtis soon.
<bac> rick_h_: my favorite part of the traceback:  Encountered " <FUZZY_SLOP> "~bac "
<bac> who writes an error message like that?
<rick_h_> bac: heh, not sure. I haven't gotten that far yet
<rick_h_> bac: I got https://pastebin.canonical.com/100094/ from webops. I don't see the search error, but seeing ingest errors, but things are working so confused. 
<rick_h_> bac: if you get a sec can you update your bundle and push and make sure it's getting ingested?
<rick_h_> heartbeat isn't hanging, but wtf is with the connection error in the logs?
<bac> connection refused
<rick_h_> yea, so it's not working. The url isn't good. 
<bac> port 2464?
<bac> i thought you had a different port for production
<rick_h_> yea, that's not legit. That's the wrong port. ok, hitting up webops
<rick_h_> bac: have that RT from the deploy?
<rick_h_> bac: just the # for it
<bac> it's in the card
 * bac looks
<bac> 65750
<rick_h_> bac: ah cool, I'll look then. I'll work with webops. If you can update your bundle as our canary in the coal mine it'd be great
<bac> oh, sure
<benji> the "parse string constraints into a dict in deployer" card is not correct -- right? -- and can be deleted
<gary_poster> frankban, great.  makes sense.  want to call?
<frankban> gary_poster: yes thanks
<frankban> gary_poster: https://plus.google.com/hangouts/_/7ecpir0k4g087sfq5aj9gfos3o?hl=en
<rick_h_> ugh fail
<Makyo> jujugui call in 10
<benji> for all those people who hunger for fewer clicks when attentding the standup, I present your salvation: http://tinyurl.com/gui-hangout-2
<rick_h_> benji: card was in the branch frankban just merged. So it's good and can go away
<benji> rick_h_: well, I suppose that's one way to look at it, but we didn't do what the card says needs to be done (as best I can tell)
<rick_h_> benji: ok, well something did it. maybe I'm mising the point, but strings go in, dicts go out to go. 
<bac> twitter up by $20 since opening.  this will be a "successful" ipo even though the company left all that money on the table.
<hatch> man I wish I could start a company that's losing money hand over fist and sell it for billions
<bac> yeah, that second step is the challeng
<bac> s/challeng/challenge/
<hatch> I think the steps are
<hatch> develop product
<hatch> hype hype hype hype
<hatch> ipo
<hatch> hype > profits
<bac> twitter was worse.  develop awful, crashy product.  hype.  crash more.  hype.  hire some decent engineer. hype. profit.
<Makyo> jujugui call in 1
<hatch> lol
<hatch> jcsackett: hey you around?
<Makyo> Running to get prescription. Bringing Air with, there's a coffee shop if it takes a while.
<hatch> rick_h_: the reason there is no tests in my branch is because it's already tested by other tests
<hatch> just fyi
<frankban> hatch: a live test in a real env deploying services and ingested bundles could really help. the development charm URL is cs:~juju-gui/precise/juju-gui
<hatch> frankban: ok cool - are we doing to be doing a charm release along side the gui release then?
<frankban> hatch: so basically is juju deploy + expose the charm above, and "juju set juju-gui juju-gui-source=lp:juju-gui"
<frankban> hatch: yes
<hatch> ok cool
<frankban> hatch: we always have to do that, because GUI releases are now included in the charm
<jcsackett> hatch: i am.
<rick_h_> hatch: hah, ok. Heading that one off at the pass 
<hatch> that's how I did the demo at the conf on Tuesday - worked well then haha
<frankban> hatch: next demo use quickstart ;-)
<hatch> jcsackett: so the apache front end has stalled, mostly because I Dont' have enough time
<hatch> that's what gary said haha
<jcsackett> hatch: dig.
<frankban> :-)
<jcsackett> hatch: i'm happy to explore that.
<hatch> jcsackett: tbh I'm more interested in a nginx front
<hatch> but I don't know if we have an nginx charm....
<hatch> well not a promoted one anyways
<rick_h_> damn chunk mismatch
<jcsackett> hatch: yeah, doesn't look like there's a reviewed one of those.
<hatch> but we could have both so nothing saying we coudln't do the apache one first then do nginx after
<jcsackett> hatch: i'm interested in apache b/c we *do* have a reviewed one of those, so that's a better story.
<hatch> right
<hatch> I'm going to be pretty swamped with life stuff at least until next weekend
<jcsackett> hatch: indeed, i totally think we can have both. there's an issue for supporting both.
<hatch> oh?
<jcsackett> yeah, this weekend is sort of booked for me, but i have some evenings free.
<jcsackett> hatch: https://github.com/hatched/ghost-charm/issues/11
<hatch> ohhh 'issue' meaninig 'ticket'
<hatch> I thought you meant there was a problem with supporting both :)
<rick_h_> hatch: come on man, you wrote a new module. How can 'there are already tests for this'?
<hatch> because the import code is already tested, all I did was move it out
<hatch> I could repurpose the tests to point to the module directly
<hatch> if you'd like
<jcsackett> hatch: no, just that the desired thing is already captured.
<hatch> is there a juju story for deploying services to a single machine then splitting them off that machine later?
<hatch> so we could have a bundle to deploy apache/ghost/mysql to a single machine then give them the ability to break one out if needed
<hatch> maybe the story there is simply to deploy another mysql/apache/ghost and then change the relationship
<luca> gary_poster: do you have a hangout?
<gary_poster> luca, alejandraobregon what hangout?
<gary_poster> :-)
<gary_poster> luca https://plus.google.com/hangouts/_/calendar/Z2FyeS5wb3N0ZXJAY2Fub25pY2FsLmNvbQ.t3m5giuddiv9epub48d9skdaso
<hatch> jcsackett: do you have a live site up with the ghost charm yet?
 * bac lunches
<jcsackett> hatch: no, but only for lack of time.
<hatch> frankban: so I `juju deploy cs:~juj-gui/precise/juju-gui` and it's taking forever to get back to the console...
<hatch> is this normal?
<hatch> I guess ec2 could be taking forever to respond
<hatch> yeah juju status is hanging too
<rick_h_> hatch: yea, welcome to the real cloud
<hatch> glad this didn't happen during my demo, that would have sucked haha
<rick_h_> hatch: it'll hang until bootstraping is done and a machine is brought up/setup
<rick_h_> hatch: ok, one qa feedback on your branch
<hatch> """ERROR cannot log in to admin database: unauthorized mongo access: auth fails"""
<hatch> that's an odd one
<rick_h_> hatch: :(
<hatch> rick_h_: re the merge files - for some reason the parser does not pick up those deps, I have it on my list to fix that parser but that's been on the list for 6 months :)
<rick_h_> hatch: rgr
<hatch> It's using the loader to generate the deps
<hatch> so it SHOULD pick those up
<hatch> but who knows
<rick_h_> hatch: all good, the only thing I'd love to see changed pre-land is the titles for tooltips
<hatch> I've spent all of 20s looking at it
<hatch> yeah that's a good idea
<hatch> oh rick_h_ the sollution to that error message was to use `sudo` ...
<hatch> I think I may have a bug on my system
<frankban> rick_h_: what shoudl I write in the tests requirements.pip to make it install the stuff in deps?
<rick_h_> frankban: it's inthe pip command not in the requirements.txt file
<rick_h_> err, requirements.pip
<rick_h_> frankban: it's that snippet I linked from charmworld's makefile
<frankban> we already have --find-links
<frankban> rick_h_: so, just the name of the packaged in the requirements
<rick_h_> frankban: right, but it'll still try to go online if it doesn't see it, or if the version is a > XXX ad such
<rick_h_> frankban: the name==version
<frankban> rick_h_: cool, I'll try
<rick_h_> frankban: --no-index --no-dependencies are the other two options to force it to use offline-only cache
<frankban> rick_h_: I don't think we want offline only cache. we want all the other packages (e.g. mock, selenium) to be retrieved from pypi
<hatch> nananananananananananananaannanana qa man.....qa man......qa man
<rick_h_> frankban: sure, but you were talking of splitting those into a different file and could be a different pip install command?
<rick_h_> frankban: but maybe that's step #2 I guess
<rick_h_> frankban: I just know that if you don't go full-offline-this-directory-only-dammit mode eventually you'll hit an inconsistent version between one and another
<frankban> rick_h_: yeah, what if the dependency is unversioned? who takes precedence?
<rick_h_> frankban: if it's not versioned then that's when it'll go to the net anyway. pip isn't really great at this 'no network' idea
<rick_h_> frankban: if I recall correctly that is. 
<frankban> rick_h_: hum? ok then, and FYI, we are going to also have a customized jujuclient tarball in the charm 
<rick_h_> frankban: so we use'd pip freeze to generate an initial list of deps + versions
<hatch> man our app rocks!
<rick_h_> hatch: lol
<rick_h_> yea, it's fun to see how excited martin is getting with this feature. A bit scary how everyone's handing out comingsoon urls to potential customers :/ but cool
<hatch> yeah - mark did that in his keynote haha
<hatch> maybe we should put a warning on comingsoon :)
<rick_h_> abentley: ping, working on an upgrade to the charm on production and jjo and I are trying to figure out if the lp_credentials change will bite us in any way. I see it's a config value, and a file is written, but not seeing anyone using that file?
<abentley> rick_h_: lp_credentials should be in use.  Looking...
<rick_h_> jcsackett: do you know about that? ^ I see it was your branch mentioning a job that needs it but greping for lp_cred or charmbot in charmworld brings up no hits
<hatch> gary_poster: https://bugs.launchpad.net/juju-gui/+bug/1249026 https://bugs.launchpad.net/juju-gui/+bug/1249028 and https://bugs.launchpad.net/juju-gui/+bug/1249030
<_mup_> Bug #1249026: On a real environment destroying a pending service throws console error <juju-gui:New> <https://launchpad.net/bugs/1249026>
<_mup_> Bug #1249028: Hovering over the service with your mouse should turn the cursor to a pointer <juju-gui:New> <https://launchpad.net/bugs/1249028>
<_mup_> Bug #1249030: After destroying a related service the GUI still shows the relation. <juju-gui:New> <https://launchpad.net/bugs/1249030>
<gary_poster> on call will see soon
<hatch> sure np https://bugs.launchpad.net/juju-gui/+bug/1249033
<_mup_> Bug #1249033: Long charm names cause the related charms layout to break in fullscreen <juju-gui:New> <https://launchpad.net/bugs/1249033>
<hatch> https://bugs.launchpad.net/juju-gui/+bug/1249039
<_mup_> Bug #1249039: Exporting from real environment exports juju-gui as well <juju-gui:New> <https://launchpad.net/bugs/1249039>
<hatch> https://bugs.launchpad.net/juju-gui/+bug/1249042
<_mup_> Bug #1249042: Destroying a service doesn't give any indication that the machine is sticking around <juju-gui:New> <https://launchpad.net/bugs/1249042>
<rick_h_> hatch: that one is a long running juju bug/discussion
<hatch> rick_h_: the gui bug is that we don't tell the user
<hatch> so if they are a gui user then they will never know
<hatch> we should say 'hey btw this machine is still there'
<hatch> but feel free to add input to the ticket
<rick_h_> *cough* machine view *cough* but yea, understood
<hatch> I'm just creating them - there may be duplicates
<hatch> :)
<gary_poster> ok looking now
<hatch> cool
<gary_poster> hatch ack thanks.  Please let me know what you think about the following.  #1 sounds nasty but I suspect it is longstanding and not a release blocker.  #2 Arguable (since you can drag the service) and not a blocker.  #3 same as #1.  #4 same as #1 but sounds easy to fix. :-P. #5 uh...working as designed?  :-) not a blocker IMO.  #6 yeah that's on the "wouldn't it be nice to fix this" tasklist
<gary_poster> So, so far, either known or non-blockers.  Agree?
<jcsackett> rick_h_: the code that rolled back uses that file.
<rick_h_> jcsackett: ah!
<hatch> yep I wouldn't consider any of these blockers unless of course someone already has an idea on how to fix #1/3
<jcsackett> the presence of that file however shouldn't cause any problems.
<gary_poster> yeah
<rick_h_> jcsackett: ok, so it's safe for me deploy the charm then it sounds like
<jcsackett> it's been running on staging safely.
<jcsackett> absent any code touching it.
<rick_h_> jcsackett: awesome
<rick_h_> jcsackett: so the charm was updated on staging just not production?
<hatch> I do like that I can go `juju destroy-machine 1 2 3 4 5 6 7` :D
<jcsackett> rick_h_: correct, as far as i knwo.
<jcsackett> s/knwo/know/
<rick_h_> jcsackett: cool, thanks
<hatch> gary_poster: I'm just going to run a real bundle import on a real env then It should be QAOK
<gary_poster> awesome!  thanks hatch
<gary_poster> I need a quick lunch (and to decompress :-P) and then will be right back
<hatch> :)
<hatch> Makyo: are you around?
<Makyo> Yis
<hatch> cool ok quick q
<hatch> I exported a bundle from my real env
<hatch> deleted the gui from it
<hatch> then re-imported it (after emptying out the old stuff)
<hatch> both services have x/y coords
<hatch> but they were placed ontop of eachother
<hatch> exactly ontop of eachother
<hatch> so you couldn't even tell they were there
<hatch> https://gist.github.com/hatched/7359271
<hatch> here is the resulting bundle that was imported
<hatch> is there anything wrong with that bundle?
<hatch> so my question is....is this a bundle import or export issue :)
<Makyo> Works for me?
<hatch> this is on a real env...
<hatch> I can destroy and try again see if I can reproduce
<rick_h_> hatch: I had this happen with one of jcastro's bundles in a real env as well. wordpress and mysql were stacked and couldn't see both
<hatch> ok so it's definitely a bug thanks
<Makyo> Import, then.
<hatch> ok cool
<hatch> will file
<hatch> gary_poster: one more https://bugs.launchpad.net/juju-gui/+bug/1249051 also not a blocker
<_mup_> Bug #1249051: Importing a bundle stacks services regardless of x/y annotations on real env <juju-gui:New> <https://launchpad.net/bugs/1249051>
<hatch> all-n-all I think this is a pretty darn stable release
<gary_poster> that's not ideal, but we can live with it for now
<gary_poster> thank you very much hatch
<hatch> no problemo
<frankban> guihelp, python revievers: I need one review + QA for a really really nice to have for the release: https://codereview.appspot.com/23000043
<gary_poster> rick_h_, you happen to be available ^^^? about to have my call with benji
<gary_poster> or bac?
<rick_h_> gary_poster: working with webops on charm upgrade atm. I can look in a few if all goes well
<gary_poster> ok thank you rick_h_ 
<frankban> rick_h_: thanks
<bac> frankban: i can now
<bac> rick_h_: ^^
<rick_h_> bac: thanks, mjc upgrade is process and wheee
<bac> i don't know what that means
<rick_h_> bac: upgrading the charm for prodstack mjc to fix the port/ini issue
<rick_h_> bac: so thanks for looking at frankban's branch
<rick_h_> abentley: jcsackett so charm is upgraded. Because that's a new config there's some hackery needed to get the initial value going. 
<rick_h_> abentley: jcsackett just a heads up for when that code comes back and things need to be updated
<hatch> stepping out for lunch, bbl
<bac> frankban: code looks good.  QA now
<frankban> bac: great thanks
<jcsackett> rick_h_: what hackery? the default value should be an empty string, which rights out to an empty file.
<jcsackett> s/rights/writes/
<rick_h_> jcsackett: so the first time it runs the default doesn't get written I guess? If another charm deploy happens between now/then it should be ok I think
<rick_h_> jcsackett: I was pointed at #1244841
<_mup_> Bug #1244841: support atomic upgrade-charm --config var=val ... <canonical-webops> <config> <upgrade-charm> <juju-core:Triaged> <https://launchpad.net/bugs/1244841>
<jcsackett> rick_h_: so just no file gets written?
<rick_h_> jcsackett: right, my understanding is that right now the file doesn't exist
<jcsackett> huh.
<rick_h_> jcsackett: I'll verify when I check the log in a sec
<rick_h_> jcsackett: but it's a limitation of juju upgrading a charm when the upgrade contains a config value that didn't exist before is my understanding
<jcsackett> well, if it's going to do something unexpected, "nothing" is one of the better options. :p
<rick_h_> :)
<jcsackett> rick_h_: oh, i see; this would have been hidden on staging b/c we did a juju set right after to load the credentials.
<jcsackett> and we haven't updated the IS docs b/c right now there's no need to set that option/write that file.
<rick_h_> jcsackett: hmm ok, well that didn't come up as an option in talking. I'm not following 100% I guess. Anyway, heads up there be dragons I guess. 
<jcsackett> rick_h_: there be no dragons.
<rick_h_> ok, then awesome ness
<jcsackett> to get the file to write out, you need to do `juju set charmworld lp_credentials=$BIG_DAMN_STRING`
<jcsackett> and then on config changed it'll write it out.
<jcsackett> but, like i said, IS documentation isn't updated b/c the failure mode is do nothing. so actually, this is everything running as expected. :-)
<rick_h_> gary_poster: charm is all set, charmworld all good. What's next for release I should look at?
<gary_poster> rick_h_, ack 1 sec
<gary_poster> rick_h_, I've been unable to make changelog because of calls etc.  you could take that over.  docs/process.rst has a recommeneded way to generate for a release.  This is what I have so far:
<gary_poster> rick_h_, http://pastebin.ubuntu.com/6377908/
<rick_h_> gary_poster: rgr, looking 
<gary_poster> rick_h_, thank you.  card is in maintenance but you can drag down to bundle and claim
<gary_poster> bac, in hangout
<jcsackett> rick_h_: what rev did you release for production charmworld? cleaning up our kanban.
<rick_h_> jcsackett: 84
<rick_h_> jcsackett: oh, charmworld was 450
<gary_poster> frankban, you are still here! are you landing "Improve bundle deployment error handling" or should we?
<frankban> gary_poster: waiting bac's QA, and then I'll land it
<gary_poster> oh cool.  thank yo ufr
<gary_poster> thank you frankban, that is ;-)
<gary_poster> tab completion on ufr did not work as expected
<frankban> :-)
<bac> frankban: done.  all good.
<frankban> bac: thanks, landing
<hatch> man our traffic is nuts
<frankban> done, have a nice evening, and a nice release!
<gary_poster> thanks frankban !
<gary_poster> rick_h_, we are ready for release, and you have the charm in.  you doing it, or shall we look for other volunteers?
 * hatch hides
<rick_h_> gary_poster: I'm working through the gui release notes. 
<gary_poster> awesome thanks rick_h_ !
<rick_h_> gary_poster: I've got the changelog, tests, xz and working on how to open it up to qa it
<hatch> *phew*
<gary_poster> I see  you hatch! :-)
<rick_h_> gary_poster: if someone wants to do the charm +1 from me :)
 * rick_h_ looks at hatch 
<hatch> is there release notes? I've never done the charm
<gary_poster> rick_h_, ack, we do that after the tarball release though
<rick_h_> gary_poster: rgr, ok. know off the top of your head the tar flags for xz files?
<rick_h_> ah, -J
<gary_poster> rick_h_, use tar xvaf
<hatch> rick_h_:  https://xkcd.com/1168/
<gary_poster> rick_h_, a means "use the file extension to figure it out, buster"
<hatch> lol
<rick_h_> gary_poster: ah, good stuff
<rick_h_> gary_poster: ok, plodding through notes. Man this is a looong list :)
<gary_poster> rick_h_, :-) on the bright side a lot of the qa has been done
<hatch> rick_h_: I found using the trunks commit notes to build the changelog
<hatch> is the best way
<rick_h_> hatch: yea, got that part. Wasn't that bad since it was only around 40 commits (thought it'd be bigger/longer)
<rick_h_> and most summarize as "Welcome to bundles"
<hatch> if it was on git it would be :) haha
<hatch> so I'm up for whatever right now...if anyone has any tasks they need completed
<rick_h_> oh bah, the charm is part of this. doh!
<gary_poster> you can pass that off rick_h_ .  :-)
<gary_poster> hatch, I suggest tackling one of the bugs you found, or working on one of https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AtC9etoysSQldDQxMVdmTDB4dm1XXzA0NFlLSUQ4Mmc#gid=0
 * rick_h_ looks at how far this list goes
<gary_poster> preferring ones near the top :-)
<hatch> gary_poster: alrighty
<rick_h_> gary_poster: got it, should go through this at some point and looks like I'm mostly through it so far
<gary_poster> rick_h_, yeah you are getting near-ish to the end. :-)
<gary_poster> We might be able to remove some of the more paranoid bits at some point
<rick_h_> running charm tests failed due to dep building. Missing apt-pgk/hashes.h file. Looking for missing system dep now
<hatch> that's an odd one
<hatch> I've never seen that before
<rick_h_> looks like libapt-pkg-dev
<rick_h_> re-running make lint from a clean charm env
<rick_h_> hmm, that's in the sysdeps make target. So it's a new step in the process.
<rick_h_> ok, take 3
<hatch> third time is the.....charm
<hatch> ...see what I did there...
<rick_h_> sorry, wasn't looking. What was that again?
<hatch> lol u suck
<hatch> so after next week's talk on Go/JS I can get started on learning Python well enough to contribute - any good resources for learning about the ecosystem?
<rick_h_> go to pycon, it's in CA :P
<hatch> California?
<hatch> ohh Canada
<hatch> Montreal
<rick_h_> nope, bit more north
<hatch> wow...it's 8 days long
<hatch> make that 9
<rick_h_> well tutorials, conference, and sprints. I go for the conference and sprints myself
<rick_h_> ok, make test now in progress
<rick_h_> bah, now it's making fun of my environments.yaml file
<hatch> so they make you sign up for an account before telling you how much it is.....fail
<rick_h_> wtf, it's complaining about a differnet environment
<hatch> oh I was looking at the wrong place
 * hatch failed
<rick_h_> yea, reminds me I need to sign up asap. Guess I'll be doing that tonight
<hatch> flights to Montreal cost me the same as it does to fly to SFO haha
<rick_h_> gary_poster: crap, getting functional test failures
<rick_h_> oh man, it wants FF in my lxc?
<rick_h_> grrrr
 * rick_h_ sees what happens when you try to run firefox in a headless lxc
<hatch> unicorns happen
<gary_poster> rick_h_, so you are addressing?  If not, and it is too difficult, we can find other options
<rick_h_> gary_poster: working on it
<gary_poster> k
<rick_h_> gary_poster: installing firefox now, pulling all of X and lovelyness so taking a few
<gary_poster> heh
<gary_poster> k
<rick_h_> will have to restart functional tests, destroying old env now
<rick_h_> now I know why hatch ducked for cover :P
<hatch> haha
<hatch> I've never actually done a charm release
<rick_h_> still running functional tests, running on test_branch_source forever
<rick_h_> or 10minish
<rick_h_> if forever is a bit vague :)
<hatch> hmm.....delete 100+ LOC, no test failures......win?
<rick_h_> heh, that's what we call 'test coverage time'
<hatch> ohh the ones which would have failed were already skipped
<hatch> *phew*
<hatch> I was a little scared there haha
<rick_h_> python /home/rharding/bin/juju-test --timeout=120m -v -e ec2 --upload-tools 20-functional.test
<rick_h_> 120minutes?!
<hatch> just incase lol
<rick_h_> well, 20/120 I guess
<rick_h_> this is the last step before I can merge/push stuff! grrr go go go ec2 go
<gary_poster> rick_h_, if you have to go, and you have manually qa'd the charm with the new release, I would be fine with you making the release.  Francesco ran the tests earlier today.  All you've done is change the tarball.
<rick_h_> gary_poster: working on it. Didn't try to deploy it as a local charm yet since I put it all in a tmp dir and I can't figure out how to get juju to deploy it unless it's in a directory named precise. 
<gary_poster> rick_h_, make deploy.  
<hatch> gary_poster: do you want me to mark tasks complete somehow on this spreadsheet?
<rick_h_> oh duh
<gary_poster> rick_h_, http://jujugui.wordpress.com/2013/10/15/if-you-want-to-run-a-custom-gui/
<gary_poster> except all you have to do is make deploy in this case :-)
<gary_poster> hatch, mark as Done in spreadsheet
<hatch> cool
<gary_poster> in status column hatch
<rick_h_> gary_poster: trying, getting an error out of make deploy about username/pass/project-name. 
<gary_poster> rick_h_, :-( worked for me last week
<rick_h_> gary_poster: ve to do is make deploy in this case :-)
<rick_h_> bah
<rick_h_> bad paste
<gary_poster> rick_h_, you can push charm to ~juju-gui
<rick_h_> http://paste.mitechie.com/show/1068/
<gary_poster> rick_h_, then test
<gary_poster> rick_h_, and if that is ok then merge to ~juju-gui-deployers
<gary_poster> does that make sense?
<hatch> woah lbox just exploded on me...
<rick_h_> gary_poster: yea, makes some sense. I'd like to not have this make deploy error before I go pushing. 
<gary_poster> rick_h_, never seen :-(
<gary_poster> that traceback I mean
<gary_poster> rick_h_, I will try locally
<rick_h_> gary_poster: rgr
<gary_poster> rick_h_, do you want to push up your charm somewhere or if I test juju-gui trunk is that sufficient?
<rick_h_> gary_poster: I'll push it up to my home I guess. I'd be curious to start with trunk
<hatch> has anyone seen this when lboxing? sphinx error? https://gist.github.com/hatched/ad0695b48078503825f7
<rick_h_> hatch: no, but something about getting version from release? Is that our own code? 
<hatch> fresh trunk with js and handlebars template removal
<gary_poster> rick_h_, running make deploy from ~juju-gui trunk
<rick_h_> bah, can I not push this without it going into the store and ingested? /me tries to recall how +junk worked
<gary_poster> I think bzr just blew up? np?
<gary_poster> no
<gary_poster> juju status
<hatch> gary_poster: was that to me?
<gary_poster> rick_h_, you push it but don't call it trunk and it will not be ingested
<gary_poster> hatch no sorry
<rick_h_> gary_poster: ah, ok. 
<gary_poster> hatch dupe on trunk.  investigating.  I think it has to do with CHANGES file...
<hatch> gary_poster: sorry landing a fix now
<hatch> I think
<rick_h_> gary_poster: pushed it to lp:~rharding/+junk/charmers-trunk as it is now. Tests are at 42min run time. 
<hatch> it's rick_h_'s fault
<hatch> :P
<gary_poster> oh cool hatch thanks.  fix in CHANGES, yeah?
<rick_h_> bah, did I mess up the changes? i tried to dupe the system
<hatch> gary_poster: yeah the 'unreleased' was missing the trailing :
<hatch> at least I THINK that's the issue
<gary_poster> hatch sounds right thanks
<rick_h_> ah, crap. thanks hatch. Sorry you hit that
<hatch> pretty fragile system
<hatch> rick_h_: ahh no problem :)
<hatch> at least I could do enough python to debug it haha
<hatch> rick_h_: If you have any ideas on how we can streamline our release process I'd be interested to hear/implement them
<rick_h_> hatch: taking notes now on the things I've hit along the way. As for streamlining, just tring to get it to work once before I do that. :)
<hatch> :)
<hatch> gary_poster: rick_h_ fyi the missing : was the culprit
<rick_h_> hatch: haha, with one character I can bring down your whole branch!
 * rick_h_ pockets that away
<hatch> lol - maybe that means that we should require an lbox on the 'CHANGES' changes ;)
<hatch> because that got into trunk because of the step that says 'push to trunk'
<gary_poster> we effectively do IIRC
<gary_poster> it's that the deployment instructions do not run lbox
<hatch> https://codereview.appspot.com/23240043/ if anyone is avail for a quick review/qa
<hatch> right
<gary_poster> rick_h_, I have trunk up with make deploy
<gary_poster> trying
<rick_h_> gary_poster: :( ok I guess. I can't find any reference to "project-name" that was in my traceback. 
<gary_poster> rick_h_, ok.  I will kill this one and merge your branch and do it again...
<rick_h_> gary_poster: k
<rick_h_> test run almost hitting an hour. Is that normal from previous deploys? 
<gary_poster> rick_h_, yes, think so
<rick_h_> ok
<gary_poster> charms are painful beasts
<gary_poster> to test
<rick_h_> yea, understood. /me does a s/test_/wait_ so it feels more natural :)
<gary_poster> :-)
<gary_poster> hatch, on it
<gary_poster> hatch, uh, I'm struggling to figure out what to do to qa. :-P
<gary_poster> the app seems to work? :-)
<hatch> gary_poster: deploy two services with the same name
<hatch> you should get a notification
<hatch> sorry :)
<gary_poster> oh ok
<hatch> I found if I removed too much - notifications would stop happening :)
<huwshimi> Morning
<hatch> mornin
<gary_poster> morning
<gary_poster> hatch QAOK
<hatch> thanks
<gary_poster> rick_h_, site is up; trying
<gary_poster> rick_h_, WFM :-)
<gary_poster> rick_h_, ship it (~_juju-gui and ~juju-gui-charmers)
<gary_poster> rick_h_, https://ec2-54-205-201-186.compute-1.amazonaws.com/
<rick_h_> gary_poster: ok, cool then
<huwshimi> gary_poster: I'm happy to have our calls anytime from now.
<gary_poster> thank you huwshimi!  maybe in a few minutes, then?  would be good
<huwshimi> gary_poster: It looks like we've both changed daylight savings recently...
<huwshimi> gary_poster: Sure!
<gary_poster> heh, that's right I forgot
<gary_poster> cool
<hatch> shall I join or is this just 1:1?
<rick_h_> ok, both branches of the charm pushed, waiting to check on the new revs hitting
<gary_poster> awesome thanks rick_h_ .  I have a blog post and email waiting in the wings.
<rick_h_> gary_poster: rgr
<rick_h_> gary_poster: http://paste.mitechie.com/show/1069/ are my notes for the deploy steps I hit. Done for today, but will look at tweaking those as follow up
<huwshimi> Are we releasing now!?
<rick_h_> huwshimi: yes
<huwshimi> woah! Nice.
<hatch> huwshimi: this way - if it breaks you can fix it while we are out drinking
<hatch> mohohahaha
<huwshimi> Boo
<gary_poster> :-)
<huwshimi> hatch: It's my Friday night before it's yours :P
<gary_poster> :-)
<hatch> darn....
<gary_poster> thank you rick_h_ !
<hatch> +1 internets to rick_h_
<rick_h_> thanks for hte patients. Waiting for ingest at top of the hour and then running away
<gary_poster> ah cool
<gary_poster> huwshimi, hatch, https://plus.google.com/hangouts/_/calendar/Z2FyeS5wb3N0ZXJAY2Fub25pY2FsLmNvbQ.dd77sn7kjl6unba21lutdr0p70 when ready?
<huwshimi> gary_poster: on way
<rick_h_> ok, ingested https://jujucharms.com/precise/juju-gui-78/
<rick_h_> night all
<gary_poster> congrats!  night!
<huwshimi> rick_h_: Night Rick, thanks!
<rick_h_> woot! and with the new juju fixing lxc deployed a bundle from the new charm in lxc. only issue is that stacked service block problem yay!
<rick_h_> <3 having lxc powers back
#juju-gui 2013-11-08
<luca___> rick_h_: are you there?
<rick_h_> luca___: party
<luca___> rick_h_: your at a party?
<rick_h_> luca___: I'm here aren't I? :)
<luca___> rick_h_: :P
<luca___> rick_h_: do you know if the demo is connected to a state server at the moment?
<rick_h_> luca___: comingsoon?
<luca___> rick_h_: yes
<rick_h_> luca___: no, it's in pure sandbox 'fake' mode
<luca___> rick_h_: all in the browser?
<rick_h_> luca___: to do a live demo connected to an environment you'd have to deploy to an environment using quickstart or manually
<rick_h_> luca___: yes, all in the browser
 * bac does ux contuing education by reading about teslas.  umm, teslas.  thanks luca.  http://uxmag.com/articles/teslaâs-groundbreaking-ux-an-interview-with-user-interface-manager-brennan-boblett
<bac> s/contuing/continuing/
<rick_h_> nice :)
<rick_h_> the ec2 server that runs my irssi/remote irc session is up for retirement so need to shut it down and bring it back up. Will be back in a bit. /me crosses fingers.
<gary_poster> hey rick_h_ if you are around, shooting you a mail
<rick_h_> gary_poster: rgr
<gary_poster> rick_h_, also, Huw is on vacation for next two weeks, so as team we need to try and move his branch forward
<rick_h_> gary_poster: yep, I was going to ask about that. Most of the stuff I'd be happy to tweak. I am curious ont he landscape link but sure I could figure it out
<rick_h_> gary_poster: k, see the email and looking into it. We do run the relation validations, but that's part of the code we're reusing from the deployer as well. 
<gary_poster> thank you rick_h_ .  I'm also checking with Maarten if he can proceed without ganglia, which reduce the need to worry about this today.
<gary_poster> which would
<rick_h_> gary_poster: ok, will take a bit to get my local instance to ingest enough to try it out. Working through that to replicate proof processing locally. 
<gary_poster> cool thanks
<rick_h_> gary_poster: ah, ganglia is still at 0 because 1 failed proof errors. That charm is in a borked state because it's hanging between versions I bet
<gary_poster> ah! ok
<rick_h_> http://manage.jujucharms.com/tools/proof-errors see cs:precise/ganglia-1
<gary_poster> gotcha
<rick_h_> oh, that's ganglia-1, not ganglia-node 
 * rick_h_ keeps looking while ingest runs
<gary_poster> ah, indeed
<rick_h_> but ganglia-4 is in his bundle as well. 
<rick_h_> must be an old error I guess then since the store has -4 and that looks good
<gary_poster> probably unintended side-effect og ingesting older charms
<gary_poster> of
 * bac reboots.  bbiab
<rick_h_> gary_poster: yea, I can duplicate the ganglia-node locally. It's name isn't matching the regex in place to check if a charm has a version or not so looking into why
<rick_h_> gary_poster: so that looks like a legit bug and working on it
<gary_poster> cool thanks rick_h_ .  Don't stress about it.  Maarten says I can remove it for next week if we have to
<gary_poster> But something we should fix
<rick_h_> gary_poster: yep, and the second one is definitely a blind spot. Had no idea about juju-info relations so will have to add support for that as an option
<rick_h_> pulled up the docs that mention it to see if there's any rules to be aware of on that
<gary_poster> cool.  yeah, dunno.
<rick_h_> gary_poster: ah! if int('0'): False doh!
<gary_poster> heh
 * rick_h_ changes all if revision to if revision is not None
<hatch> oh the standup isn't earlier today
<rick_h_> jujugui small charmworld review please. https://codereview.appspot.com/23600043/
<gary_poster> jujugui, has anyone ever seen x-y annotations honored by the real-world deployer?
<bac> nope, same bat time every day
<bac> rick_h_: ok
<gary_poster> luca___, alejandraobregon do you have a hangout?  if not we can use https://plus.google.com/hangouts/_/calendar/Z2FyeS5wb3N0ZXJAY2Fub25pY2FsLmNvbQ.t3m5giuddiv9epub48d9skdaso
<rick_h_> gary_poster: I did not, but I thought benji in qa said it didn't stack them for him
<Makyo> jujugui emergency appointment at 8:30 (in ~30), may be a little late to call. It's by phone, so I can join as soon as it's over, shouldn't take that long.
<gary_poster> Makyo, ack
<hatch> gary_poster: no I've never seen them working on a real env
<rick_h_> Makyo: rgr, thanks
<benji> gary_poster: I don't know if it was from the annotations or just the "natural" placement, but yesterday I deployed a bundle to ec2 and the (two) services had an arrangement (i.e., they weren't stacked on top of each other)
<hatch> ok stepping out for an hour until the meeting
<gary_poster> rick_h_, hatch, benji, ok thanks
<benji> rick_h_: I'll take a look at your branch
<gary_poster> interesting: https://micknelson.wordpress.com/2013/11/08/juju-ansible-simpler-charms/
<rick_h_> benji: cool, bac has it but more the merrier. Rick had a dumb boolean moment :)
<bac> benji: i'm already looking
<benji> bac: ah, ok
 * benji averts his eyes
<rick_h_> gary_poster: yea, not checked out ansible so not sure how much bootstrap is there but cool
<gary_poster> y
<bac> gary_poster: i deployed a bundle to ec2 doing frankban's qa yesterday and the two services were on top of one another.  annotations were in the bundle.
<gary_poster> bac ack thanks
<luca___> gary_poster: I'm trying to rally the troops :)
<gary_poster> luca___, heh ok cool
<rick_h_> lol, use the force luca___ !
<rick_h_> "this is the meeting you're looking for"
<luca___> rick_h_: rofl
<rick_h_> thanks bac 
<rick_h_> jujugui bug-fix-o-rama part two please https://codereview.appspot.com/23660043/
 * bac defers to benji if he wants
<benji> bac: sure, I'll take it
<bac> you seemed so disappointed last time
<rick_h_> lol, you guys work together so well
<rick_h_> "after you sir, no after you, no I insist" 
<hatch> jujugui call in 9
<gary_poster> jujugui call in 2
<gary_poster> or 1
<gary_poster> benji Makyo yo
<benji> gary_poster: hmm
<gary_poster> (Makyo on call will show up when he can)
<hatch> very bad net connection right now so I'm on my cell hangouts
<bac> frankban: how did you decide to do your laptop?  metal vs vm?
<frankban> bac: fusion for now, it seems to work very well
<bac> jujugui, sorry my network has dropped out and i can't get back into the hangout
<gary_poster> bac rick_h_ was I supposed to stay around and talk to you?
<Makyo> fading, layinf diwn fir a bit
<rick_h_> gary_poster: well, we're trying to figure out friday deploy of charmworld
<rick_h_> gary_poster: if the deploy happened monday would that hurt the planned stuff?
<gary_poster> rick_h_, ack.  it might.  don't do it.  ask bac to do it Monday morning.  I'll warn Maarten and he can choose what escape hatch he wants
<rick_h_> gary_poster: ok, sounds good then. I'll check staging and proof against it to verify the bundle here 
<gary_poster> cool thanks rick_h_ 
<hatch_> that call used up 33% of my battery on my phone lol
<hatch_> apparently decoding 7 video streams is battery intensive work
<rick_h_> gary_poster: http://paste.mitechie.com/show/1072/
<rick_h_> gary_poster: so looks good on staging
<rick_h_> bac: can you do a deploy on monday then please?
<gary_poster> rick_h_, awesome :-) thanks
<hatch_> gary_poster: If I don't end up driving I can also take a look at huw's branch pending I have decent LTE/3G on the highway
<rick_h_> hatch_: cool, if not I'll update it on tues 
<hatch_> no I will!
<gary_poster> hatch, you are a madman :-) thanks
<rick_h_> :PO
<hatch_> haha
<hatch_> well if I'm not driving it's either code or read a bood
<hatch_> book*
<bac> rick_h_, gary_poster: ok, monday deploy
<rick_h_> bac: thanks, I'll be around if you need anything. 
<gary_poster> awesome thanks
<gary_poster> I won't :-P text me if you need me
<rick_h_> gary_poster: so did you want me to reply to the email or are you?
<gary_poster> rick_h_, you mean one about maarten?  I can, unless you want to fastest ever
<gary_poster> why don't you go work undertime :-)
<rick_h_> gary_poster: umm, not sure what the fastest ever is. 
<rick_h_> gary_poster: ok, thanks. 
<hatch_> ok have a good weekend everyone
<hatch_> talk to you tuesday
<gary_poster> bye hatch_ have fun
<Makyo> Back, sorry about that.
<Makyo> Wow, bad typing :P
<jcastro> ugh
<jcastro> hey rick_h_
<jcastro> remember when you said "we don't support constraints" with quickstart
<jcastro> is that still the case?
<gary_poster> rick_h_ is not here jcastro.  we do, but they need to spelled like go constraints
<gary_poster> making example...
<gary_poster> jcastro, see these constraint names: http://pastebin.ubuntu.com/6383339/
<jcastro> got it
<gary_poster> hey bac, do you have log access to see why lp:~gary/charms/bundles/demo/bundle is not ingesting on staging?  Rick thought it was on its way after bug fixes, but I don't see it in staging search results
<jcastro> gary_poster, the constraints I am trying to map are mem=7G cpu-cores=2 arch=amd64
<jcastro> can I do those three or do I need to worry about this cpu-power one?
<gary_poster> jcastro, those three are fine
<jcastro> awesome, just waint for the CF charm to finish
<gary_poster> jcastro, IIRC go does not understand "7G" though
<jcastro> and then all I have to do is shift-D that bad boy
<jcastro> right, I'll have to do 7048 or whatever the real number is
<gary_poster> right
<jcastro> nod
<rick_h_> gary_poster: staging is still at the 11 original bundles pulled in. Notice manage is up to 13. I bet that the charm needs updating on staging for the charm fixes we did to production
<rick_h_> gary_poster: bac I'm not sure how the charm is managed on staging to know how to update that
<gary_poster> rick_h_, ack, thank you
<bac> rick_h_: i'll look at it
<gary_poster> thanks bac
<bac> rick_h_: just make sure the new charm is running?  never done that.
<benji> bac (or someone else): here is my add-metrics-api charmworld branch: https://codereview.appspot.com/23740043
<bac> benji: ok, i'll get to it in a bit
<bac> benji: thanks for the note about the merge failure.  i was just thinking it all looked familiar
<benji> bac: I wish I knew how that happend.  I'm thinking rv-submit doesn't push before merging
<bac> ohhh
<bac> ewww
<jcastro> gary_poster, aha! a pleasant surprise, the gui exported the constraints properly anyway
<jcastro> so basically I didn't even need to care about that
<gary_poster> jcastro, oh right, sorry, I thought you were talking about translating old ones.  Yeah, as far as we know, that bit is stomped for the future.
<jcastro> gary_poster, man, this is awesome
<jcastro> gary_poster, ok, so we want to give this bundle to CF/altoros immediately, I have pushed it to lp
<jcastro> so basically, the instructions from scratch are:
<jcastro> install the quickstart ppa
<jcastro> then `juju quickstart X` 
<jcastro> X being the url to the bundle right?
<gary_poster> right, that's in code now, or bundle:XXX  in the future
<bac> benji: done
<benji> bac: thanks!
<benji> bac: how in the world does that not-tuple code work!?
<benji> I've got to investigate that.
<bac> 's' in 's' is True
<bac> thanks gary_poster.  i was adding reviewer notes when i saw you were done!
<benji> right, but when did "str1 in str2" start meaning str2 contains str1
<bac> ignore them
<benji> that is something I didn't know Python did -- it surprises me that there is anything left like that :)
<bac> but in your cast str1 and str2 are the same, yes?
<bac> s/cast/case
<benji> bac: yep
<jcastro> juju quickstart lp:~jorge/charms/bundles/cloudfoundry/bundle
<jcastro> it's looking for the charm to be local on disk
<benji> but it means that any substring of "deployments" would have worked
<benji> bac: what does the comment "del" mean at the top of https://codereview.appspot.com/23740043/diff/1/charmworld/views/tests/test_metrics_api.py?column_width=80 ?
<jcastro> gary_poster, am I missing something wrt to the URL?
<bac> oh, you have a blank line for no reason
<bac> gary_poster: QA instructions sent
<bac> benji: ^^
<benji> bac: oh!
<bac> i could've been less cryptic
<jcastro> hey bac, can you help me figure out how to deploy a bundle from a remote URL?
<jcastro> we need to give the cloudfoundry guys this bundle asap
<jcastro> and I've got it all pushed
<bac> jcastro: from cli?
<jcastro> yeah
<bac> jcastro: lp url?
<bac> jcastro: sorry, what is the LP url for the branch?
<jcastro> https://code.launchpad.net/~jorge/charms/bundles/cloudfoundry/bundle
<jcastro> lp:~jorge/charms/bundles/cloudfoundry/bundle <-- I tried that too
<benji> bac: how do I install rv-submit?  (my bzr config broke badly recently)
<bac> bzr branch lp:rvsubmit ~/.bazaar/plugins/rvsubmit
<benji> ah, I was missing "plugins"
<benji> a README in that branch would be good
<bac> jcastro: sorry, i'm having to fetch the deployer
<jcastro> I am wondering if I am just missing the right syntax for the url?
<jcastro> gary_poster, any ideas?
<gary_poster> sorry on call will pay attention soon
<bac> jcastro: your bundle is not on manage.jujucharms.com or staging, right?
<jcastro> bac, I pushed it about 15 minutes ago
<jcastro> oh, so I can't have an arbritary URL?
<jcastro> it also needs to be ingested?
<bac> jcastro: what does your deployer -h say?  can you paste it?  i don't seem to have a working one atm
<rick_h_> jcastro: no local charms support
<rick_h_> jcastro: was in the email as a limitation righ tnow
<rick_h_> right now
<jcastro> http://pastebin.ubuntu.com/6383899/
<jcastro> rick_h_, I don't want a local charm I want from a remote URL
<jcastro> bac,  URL has the -h 
<rick_h_> jcastro: looking at the cloudfoundry one you linked at it has a charm: local:
<rick_h_> jcastro: this a different one?
<jcastro> oh!
<jcastro> crap, I can fix that
<jcastro> ok so I their charm is here: https://github.com/Altoros/cloudfoundry_charm
<jcastro> I don't suppose I can substitute that URL in the bundle can I?
<rick_h_> jcastro: can you just juju deploy url?
<jcastro> no, but we're supposed to
<rick_h_> jcastro: it won't get ingested as it'll fail proof. It only supports charms loaded in the store
<jcastro> ugh
<jcastro> so basically, there's no value for them to put this in a bundle
<rick_h_> jcastro: if you're calling the deployer itself, I'm not 100% sure what it does
<bac>  rick_h_: i thought the juju-deploy had an option to take a URL
<jcastro> it does
<rick_h_> bac: that url is the yaml file in the store
<bac> jcastro: what is the command line you tried/
<rick_h_> so juju quickstart http://manage.jujucharms.com/bundles/~jcastro/......
<rick_h_> bac: but that's juju quickstart and not the deployer
<rick_h_> jcastro: no, you'd have to get that charm out of github and into bzr/store
<bac> rick_h_: right.  we added it to the deployer a long time ago.
<jcastro> ugh
<rick_h_> bac: ok cool. 
<jcastro> ok but using the manage.jujucharms.com would work as the url?
<bac> rick_h_:  but now i don't see it
<rick_h_> jcastro: so maybe bac knows of a cli command to make it work from the deployer itself
<bac> rick_h_:  but now i don't see it
<jcastro> well it needs to work from quickstart
<jcastro> not the deployer
<rick_h_> jcastro: if you go to a bundle in the gui there's a 'deploy' tab that shows you how to deploy it via cli
<bac> yes, use the new goodness
<rick_h_> jcastro: http://comingsoon.jujucharms.com/sidebar/search/bundle/~jorge/wordpress/5/wordpress-simple/?text=wordpress#bws-deploy
<rick_h_> jcastro: walks through deploying via quickstart and deployer
<gary_poster> we might need to update the PPA
<gary_poster> for quickstart
<gary_poster> that slipped through the cracks
<gary_poster> jcastro, can this be ready Monday morning?  I can ask Francesco to update the PPA for you then.  I'm not set up for it and I have other things going on
<jcastro> no I'm just going to tell them to do it manually
<gary_poster> ok
<jcastro> it doesn't make sense for them to use quickstart if they have to migrate all their stuff over to bzr/lp anyway
<jcastro> that'll end up being the same length as just doing it by hand
<gary_poster> jcastro, they don't
<gary_poster> jcastro, quickstart can take any arbitrary url
<gary_poster> as long as the other end of it is a deployer file
<jcastro> what's the exact syntac?
<gary_poster> *in trunk*
<rick_h_> gary_poster: but his issue is finding a url to put into the deployer file to load a charm from github
<jcastro> ok so if my bundle is here: https://code.launchpad.net/~jorge/charms/bundles/cloudfoundry/bundle
<rick_h_> gary_poster: is my understanding of the issue
<jcastro> what's the syntax? because it's not taking that url
<gary_poster> rick_h_, doesn't github have a "raw file" url?
<jcastro> rick_h_, yeah but I can fix that by pushing the charm to lp in the meantime
<rick_h_> gary_poster: for a whole charm?
<gary_poster> what?  I thought jcastro was trying deploy a bundle
<rick_h_> gary_poster: that references a charm in github
<gary_poster> oh!
<gary_poster> sorry
<gary_poster> correct
<rick_h_> jcastro: try this url with quickstart http://bazaar.launchpad.net/~jorge/charms/bundles/cloudfoundry/bundle/download/head:/bundles.yaml-20131108185817-d8vxvhytvqmrpw43-2/bundles.yaml
 * rick_h_ ducks from url fussings
<jcastro> ok so to solve that, I can push the charm to lp in the meantime
<jcastro> man ...
<jcastro> *slow clap*
<gary_poster> that won't work and we haven't scheduled work for it
<rick_h_> jcastro: because it's not in the store you're getting a direct LP url
<gary_poster> "that won't work" == charm from github
<jcastro> rick_h_, oh because I'm failing proof, so first step is to get that charm in lp
<jcastro> and then fix the bundle
<jcastro> wait 15 ...
<jcastro> and then .... it should work?
<rick_h_> jcastro: if the charm is in the store and you pass proof and your bundle is ingested: http://manage.jujucharms.com/bundle/~jorge/liferay/liferay-simple/json
<jcastro> rick_h_, I am writing down that URL though, that is awesome.
<bac> jcastro: get it done in the next 9 minutes and you won't have to wait!  :)
<jcastro> juju quickstart http://manage.jujucharms.com/bundle/~jorge/liferay/liferay-simple/json
<jcastro> but with the right url 
<rick_h_> jcastro: and later on (not today) bundle:~jorge/liferay/3/liferay-simple  will work
<rick_h_> jcastro: right
<jcastro> why is there a 3 there?
<rick_h_> jcastro: and once it's ingested the deploy tab will show up
<jcastro> oh, nm, let me bust this out, then I can whine
<rick_h_> jcastro: version 3 of the bundle
<rick_h_> jcastro: well of the deployer file
<rick_h_> jcastro: yes, first get charm in lp, update bundle with real charm: url, then go to gui, go to deploy tab, and copy/paste
<bac> gary_poster: if quickstart will take an arbitrary URL why do our deploy instructions way to wget it locally?
<gary_poster> jcastro, this is trunk's --help.  It will tell you what you can have as bundle: http://pastebin.ubuntu.com/6383960/
<gary_poster> bac because it is not in the PPA
<bac> oh, the update to use urls.  gotcha
<jcastro> ok, so tldr, we need to update the PPA soon
<jcastro> that would have solved my first issue
<jcastro> the 2nd is, we still can't deploy charms from other URLs
<gary_poster> correct, and we won't be able to because that work is not scheduled
<gary_poster> bac, http://pastebin.ubuntu.com/6383970/ is the PPA's --help fwiw
<gary_poster> so, PPA: bundle                The path to the bundle file to deploy
<gary_poster> trunk: bundle                The optional bundle to be deployed. The bundle can be
<gary_poster>                         1) a path to a YAML/JSON file or 2) a path to a
<gary_poster>                         directory containing a bundles.yaml file or 3) a URL
<gary_poster>                         (starting with http:// or https://) to a YAML/JSON
<jcastro>      charm: "cs:~jorge/charms/precise/cloudfoundry/trunk"
<jcastro> does that line look right to you rick?
<jcastro> gary_poster, afaict that's juju's fault not yours?
<rick_h_> jcastro: yes, looks ok
<rick_h_> jcastro: make sure that the charm is in the store first though or the bundle won't pull it in because it won't be able to find that charm yet
<jcastro> I need to wait for the CS to ingest
<rick_h_> jcastro: and yea, juju's fault. :) Sounds good to me :)
<jcastro> which I think is 15 min
<rick_h_> jcastro: yep
<rick_h_> jcastro: they pull in every 15min starting at the top of the hour
<jcastro> 4 minutes and then both things should ingest
<bac> gary_poster: are you going to do my QA?  I've done it myself so i'm ok to land without you doing it.  (it's friday)
<gary_poster> jcastro, not really a fault: deployer is the thing that handles git charms, not juju.  we don't support it in gui because we would have to download charms to the GUI server, and that is a risky thing
<gary_poster> bac, do it, I'm slammed
<bac> thought so
<jcastro> wait so what happened to all the github first class citizen stuff?
<gary_poster> bac, https://codereview.appspot.com/23800044 please? pretty please?
<bac> on it
<rick_h_> jcastro: it got put in line
<gary_poster> jcastro, oh, yeah, sorry, you are right that if juju core supported github for charms (and charmworld did too) then gui wouldn't care
<bac> oh chunk mismatch my old friend
<jcastro> ok I just need to know who to whine to
<gary_poster> gui just wants to be able to talk to charmworld
<jcastro> and I just need to understand that your support of git (or anywhere URLs) is just a symptom of core not supporting it
<gary_poster> which itself wants to talk to charm store
<rick_h_> jcastro: I'm not sure tbh
<gary_poster> jcastro, gui does not support deploying charms that are not in charm store/charmworld.  bundles in the GUI have the same constraint.  Therefore you can whine in two directions
<gary_poster> (1) GUI doesn't support local charms! if they did it could maybe eventually support bundles pointing to arbitrary locations
<jcastro> I just don't get why we can't do `juju quickstart http://jorgecastro.org/my-kickass-wordpress.json" or whatever
<gary_poster> jcastro, we *can* for bundles
<gary_poster> we *can't* for charms\
<jcastro> yeah I just don't see anyone saying "sweet, I'll put my bundles on github and my charms on launchpad"
<gary_poster> happy to explain briefly on hangout if would help
<rick_h_> jcastro: right, the bundles.yaml can be anywhere. The charms defined in that bundle need to be in the store
<jcastro> they're going to say "I want everything in github"
<gary_poster> sure
<gary_poster> you never let me get to my #2
<gary_poster> (2) Core/Store/charmworld doesn't support github charms! if they did gui could immediately handle bundles with those charms
<gary_poster> #2 and #1 are unrelated: you could have one without the other
<gary_poster> does that make sense jcastro ?
<jcastro> nod
<gary_poster> k
<gary_poster> #1 is not planned on our side, and would be a lot of work.  I have no idea about the planning for #2, but if core does their part of it, somebody (like us) will need to do it in charmworld
<bac> gary_poster: with your branch, hatch's TestBundle deployed a-ok running against sandbox.  is that good QA?
<jcastro> rick_h_, ok closer now
<jcastro> http://pastebin.ubuntu.com/6384035/
<jcastro> E: cloudfoundry: Could not find charm: cf-release
<rick_h_> jcastro: looking to see if it got ingested
<jcastro> I've pushed the charm here: https://code.launchpad.net/~jorge/charms/precise/cloudfoundry/trunk
<jcastro> it didn't it seems
<rick_h_> jcastro: right, looking
<rick_h_> jcastro: no, proof the charm?
<gary_poster> bac, sent a set of 4.  maybe try one or two of them?
<jcastro> rick_h_, that could not find charm error cf-release is what proof tells me locally
<rick_h_> jcastro: right, but what about proofing the charm itself
<rick_h_> jcastro: so the charm didn't get into the store, the bundle won't be able to find it/land either
<rick_h_> jcastro: so now the focus is on why didn't the charm get into the store
<jcastro> rick_h_, oh! the charm itself
<rick_h_> jcastro: +1
<jcastro> oh yeah that's the issue
<rick_h_> jcastro: yea, and you pushed the whole directory and such
<rick_h_> jcastro: you needed to push just the charm, not the charms dir, ruby.md, etc
<rick_h_> jcastro: and the charm in charms/precise/cf-release has proof errors
<rick_h_> http://paste.mitechie.com/show/1073/
<jcastro> gotcha
<bac> gary_poster: all four deploy
<gary_poster> bac cool, with good positioning?
<jcastro> this is insane, no one is going to want to go through this
<rick_h_> jcastro: dude, what are we going to do. Search your whole directory tree to see if anything looks charm-like in here?
<bac> lovely positioning.  some of the best positioning i've seen in giant bundles.  pleasingly symmetric.
<rick_h_> "You pushed a blob of stuff, down four directories this might be charm-like"
<jcastro> no it's just the naming convention is totally non obvious
<rick_h_> jcastro: isn't there  a charm "publish" thing to help with that?
<jcastro> nope
<jcastro> it's the same place github integration is
<gary_poster> bac thank you!
<rick_h_> jcastro: heh, well one day it'll not suck then I guess 
<jcastro> https://code.launchpad.net/~jorge/charms/precise/cloudfoundry/trunk
<jcastro> how's that?
<jcastro> I have warnings and stuff, but it passes
<rick_h_> jcastro: awesome, see you in 14min
<jcastro> heh
<jcastro> 9 right?
<rick_h_> right, but then it takes a few min to process the queue. Usually 4 or 5 min
<rick_h_> when http://manage.jujucharms.com/heartbeat gets the queue filled and then empties again we can chat
<jcastro> ooh, that's a handy URL
<bac> gary_poster: while i plan to work on monday i just remembered the coast guard brings in helicopters for veterans day.  may take some strategic breaks to go to the fort.  :)
<gary_poster> bac, cool :-)
<bac> gary_poster: it looks like i need to replace the charmworld service on staging to update to the new version of the charm.  i'd like to wait until the morning as i need to take the dog now and then have a full evening
<gary_poster> bac, oh. um.  ok, will work around it.  thanks.
<rick_h_> jcastro: looking
<bac> gary_poster: if it is hurting us i can try to do it sooner.
<bac> i just assumed it was a minor inconvenience
<gary_poster> bac, I just need to be able to give maarten a way to deploy a bundle of his on comingsoon on his Monday morning.  the one he needs is not ingesting.  m.j.c and s.j.c both have their own respective issues, it seems
<rick_h_> gary_poster: I think a mjc deploy is the ligher weight work in that case
<gary_poster> bac, my work around will be to remove the parts that don't work from the bundle, and hope that ingests
<gary_poster> rick_h_, ok.  I think everyone needs to not do a deploy
<rick_h_> ok
<gary_poster> so either the bundle edit will work
<gary_poster> and maarten will be somewhat happy
<gary_poster> or it won't
<gary_poster> and he won't, but then don't give me a Friday to get something working on a Monday
<gary_poster> :-)
<rick_h_> jcastro: is http://comingsoon.jujucharms.com/sidebar/search/~jorge/precise/cloudfoundry-0/?text=cloudfoundry it?
<jcastro> yay!
<rick_h_> jcastro: so then your url for your bundle needs to be  cs:~jorge/precise/cloudfoundry-0
<rick_h_> which will fail because of the bug I fixed today :/
<jcastro> hah
<rick_h_> put another version please. Change a readme, don't care. Just needs to not in -0
<jcastro> excellent
<jcastro> ok
<jcastro> of the charm you mean
<rick_h_> jcastro: right, -0 version charms are broken. Fix landed today will be deployed on monday
<rick_h_> jcastro: aren't you so glad you wanted to do this now :)
<jcastro> heh
<jcastro> I'm posting to the internal list
<jcastro> we learned a bunch here today
<rick_h_> k
<jcastro> but I have some questions about what core is up to, etc.
<jcastro> rev pushed
<rick_h_> jcastro: yea, the joys of a 1.0 (beta) feature getting users
<rick_h_> jcastro: cool, next load is right now, not sure if it will have made it in or need to wait until top of the hour
<jcastro> k
<rick_h_> jcastro: looks like the answer is no, you missed the window. 
<jcastro> of course I did
<jcastro> it's Friday
<rick_h_> well the timestamps say you hit it in a 15s window :P
<jcastro> that's the kind of day I am having!
<rick_h_> jcastro: going to grab the boy from day care, be back in a few. Will check back in
<jcastro> rick_h_, I'll either be 100% working or half way through a bottle of rim
<jcastro> rum even. :p
<rick_h_> jcastro: :)
<jcastro> rick_h_, ok go get drunk
<jcastro> gary_poster, posted some feedback to the list, sorry I am coming across so whiny
<bac> gary_poster: i'm updating the staging charm now
<bac> gary_poster: done.  huh, that was easy.
<rick_h_> jcastro: woot, bundle get in to?
<rick_h_> jcastro: so the charm is cs:~jorge/precise/cloudfoundry-1, you've got cf-release in your bundle
<jcastro>  charm: "cs:~jorge/precise/cloudfoundry-1"
<jcastro> waiting for it to ingest too I guess?
<rick_h_> jcastro: ah, cool see it now
<rick_h_> jcastro: yes
<rick_h_> jcastro: then it'll show in the gui and everything should be all cool
<jcastro> what do you mean by show in the gui??
<jcastro> I was just going to do a `juju quickstart` cli as the example
<rick_h_> http://comingsoon.jujucharms.com/sidebar/search/?text=jorge
<rick_h_> jcastro: yea, that's cool. It'll work and all then. 
<rick_h_> jcastro: just saying once the bundle is ingetsed you'll see it in the gui and the deploy tab will walk through the cli steps
<rick_h_> just like http://comingsoon.jujucharms.com/bundle/~jorge/mediawiki-simple/2/mediawiki-simple/
<jcastro> OH!
<jcastro> dude that is way better
<jcastro> good idea
<rick_h_> jcastro: yea, getting into the store stuff sucks, that's the pita up front work. Once done though we're trying to take care of ya :)
<jcastro> oh ok
<jcastro> so the Deploy "tab"
<jcastro> it'll basically make one of those but with the right commands?
<rick_h_> jcastro: right, the deploy tab is your copy/paste way to do this via cli
<rick_h_> it loads the right urls, etc
<jcastro> man
<rick_h_> so you don't have to think about it
<jcastro> that is badass dude
 * jcastro high fives
<rick_h_> oh crap, comingsoon is using staging? 
<rick_h_> gary_poster: did we setup comingsoon to staging for marteen's stuff? 
<rick_h_> jcastro: ok, so you're fubar'd. The good news: http://manage.jujucharms.com/bundle/~jorge/cloudfoundry/cloudfoundry
<rick_h_> there's your bundle yay
<rick_h_> jcastro: now for the bad news, for something that maarten's demo'ing on monday it looks like we changed comingsoon to hit up staging.jujucharms.com which won't ingest your bundle right now because it's not up to date. 
 * rick_h_ sighs and runs away
<jcastro> ok so 
<jcastro> juju quickstart http://manage.jujucharms.com/bundle/~jorge/cloudfoundry/cloudfoundry
<jcastro> should work though?
<rick_h_> jcastro: yes!~
<jcastro> GOOD ENOUGH FOR A FRIDAY
<rick_h_> woot!
<rick_h_> jcastro: will get better/nicer next week
<rick_h_> jcastro: I don't see your email? 
<jcastro> internal juju list
<rick_h_>  jcastro oh, I must not be on that one.
<jcastro> oh hey
<jcastro> oh I know why
<jcastro> the bundle should work
<jcastro> but I need to be running trunk
<jcastro> so when the PPA lands that should Just Work
<rick_h_> running trunk of quickstart? oh right, I remember seeing that go by
<rick_h_> yea
<rick_h_> oh dude it did load on staging. http://comingsoon.jujucharms.com/sidebar/search/bundle/~jorge/cloudfoundry/3/cloudfoundry/?text=cloudfoundry
<jcastro> OMG
<jcastro> brilliant
<jcastro> I am sharing it with kirkland on G+ now if you wanna hangout
<rick_h_> why not, can answer any questions
<rick_h_> linky?
<jcastro> https://plus.google.com/hangouts/_/7ecpjuhi7oqg6echhll48cj70g?authuser=0&hl=en
<bac> gary_poster: are the bundles you need here: http://staging.jujucharms.com/search?search_text=precise&op=
<bac> rick_h_: staging looks to be happy now
<bac> rick_h_: since i upgraded the charm it has added 4 new bundles
<gary_poster> bac, yes, was just looking at that and writing to maarten.  did you do that?  If so, I'm sorry but thank you!
<gary_poster> awesome thank you very much
<bac> don't be sorry
<gary_poster> :-)
<bac> it was easy.  much easier than i thought.
<bac> juju upgrade-charm charmworld
<gary_poster> oh awesome
<gary_poster> rick_h_, bac, thank you both very much for helping with getting maarten's stuff up.  looks good.  http://comingsoon.jujucharms.com/bundle/~gary/demo/2/mixAndMatch/ and http://comingsoon.jujucharms.com/bundle/~gary/demo/2/instantBigDataNoSQL/ fwiw
<gary_poster> jcastro, you might like one or both of those
 * gary_poster running away
<gary_poster> have a great weekend everyone!
<marcoceppi> Hi GUI people, quick question about the "Import bundle" button
<marcoceppi> It expects a deployer yaml file, right? What if you have multiple deployments in it?
<gary_poster> marcoceppi, yaml or json.  ATM it will be unhappy.  sorry.  in the future it might ask you what you want.  For now, divide up the file by hand
<marcoceppi> gary_poster: that's cool, playing devil's advocate while I try to word this bug-for-discussion
<gary_poster> cool :-)
<gary_poster> ttyl
<marcoceppi> gary_poster: o/ have a good one!
<marcoceppi> 0.12 looks awesome
<rick_h_> bac: yep, thanks! I missed you had done that. 
<rick_h_> thanks marcoceppi, appreciate the bundle/proof help to get it out the door
<marcoceppi> rick_h_: np, to address some of jcastro's gripe I plan to add a `juju bundle get` command to charm tools for the 1.2 release
<rick_h_> marcoceppi: juju bundle get?
<rick_h_> which gripe was that? 
<marcoceppi> wget <some really long web address for quickstart deployments kind of sucks atm>
<jcastro> that's in trunk already
<jcastro> just not in the PPA
<rick_h_> right, but with the quickstart taking urls you won't need that
<marcoceppi> yesss, one less thing to do
<jcastro> that will just be `juju quickstart url`
<rick_h_> yea, it's in trunk and we'll support bundle: urls next
<rick_h_> so soon it'll be just juju quickstart bundle:~gary/demo/2/mixAndMatch
<marcoceppi> rick_h_: why not just cs:~gary/demo/2/mixAndMatch ?
<marcoceppi> too ambiguous with charm store charms?
<rick_h_> marcoceppi: cs urls are tied to charms
<rick_h_> yea
<rick_h_> so bundle: == cs: for bundles
<marcoceppi> why not bs:
<rick_h_> har har
 * marcoceppi giggles
<marcoceppi> They're still technically in the charmstore, I think it's a valid URL, but I can argue that later when I have time
<rick_h_> technically they're not in the charm store :)
<marcoceppi> well, in what the user knows of hte charm store
<rick_h_> they're in charmworld, will pulls data from the juju charm store
<marcoceppi> jujucharms.com, for all purposes to the user, is the "charm store"
<marcoceppi> anyways, those can all be updated later, I just love being able to juju quickstart <3
<marcoceppi> I actually wrote a plugin to do this a while ago, called juju-guistrap, since I tend to tear down and setup all the time, but this is way faster and servces so much more purpose in life
<marcoceppi> it was just a three line bash script that ran the bootstrap then deploy --to
#juju-gui 2014-11-03
<hatch> of course I just updated ghost in my charm lastnight and then they release a new version haha
<rick_h_> lol
<hatch> rick_h_: was it windy there this weekend? https://plus.google.com/117915091655057728378/posts/LoANxm9gF8x?pid=6077064898626396242&oid=117915091655057728378
<hatch> :)
<rick_h_> hatch: heh, little bit but not too bad. wasn't windy enough to get all these leaves out of my yard https://www.flickr.com/photos/7508761@N03/15075217444/
<hatch> haha oh wow - burn em all!!!!
<rick_h_> too wet and smoky
<rick_h_> we had snow on halloween
<hatch> fire isn't big enough ;)
<hatch> ohh haha nice
<hatch> there is snow on the ground here now but on haloween it was all gone
<hatch> this stuff also probably won't stay
<hatch> jujugui call in 7
<jcsackett> hatch: think your clock is probably wrong.
<rick_h_> hatch: :) sorry we finally moved TZ so in 67 min
<hatch> oh the meeting moved too? 
<jcsackett> hatch: it appears to be pinned to EST/EDT. :p
<hatch> well look at you commies and your TZ changes
<rick_h_> :)
<bac> i'm with you hatch
<bac> meetings should be UTC
<hatch> ooorah
 * bac has a snack
<jcsackett> there's certainly an argument for that.
<bac> jaasteam: speaking of timezones, i stayed at UTC-4, so i will begin and end an hour ahead of US/East
<hatch> I'm also always -6 
<bac> well, it wasn't a personal decision, but my locale does not switch
<frankban> bac: other channel
<kadams54> hatch: how are things going?
<hatch> kadams54: good - added services was pushed in favour of fixing this bug I'm on atm 
<hatch> unfortunately there were 0 tests for ambiguous relations :/ so I need to write those
<kadams54> rick_h_: any suggestions on what I should be working on?
<hatch> kadams54: probably either updating the More menu (ask luca) 
<hatch> or updating the icons (also ask Luca)
<kadams54> luca__: ^
<rick_h_> kadams54: +1 to hatch's stuff. The icons might not be ready until later in the day so I'd suggest the masthead 
<rick_h_> kadams54: https://bugs.launchpad.net/bugs/1388856
<mup> Bug #1388856: The "more" tab in the masthead needs to be updated <juju-gui:New> <https://launchpad.net/bugs/1388856>
<kadams54> OK, will do.
<luca__> hatch: kadams54 I filed a but for the masthead and Spencer has just finished the icons for AS
<kadams54> Great.
<hatch> http://cdn.instructables.com/F7Z/J9CH/HJKC61PL/F7ZJ9CHHJKC61PL.LARGE.jpg
<hatch> rick_h_:  new bug wrt ambiguous relations https://bugs.launchpad.net/juju-gui/+bug/1388877 just a styling issue though
<mup> Bug #1388877: ambiguous relation menu not styled properly  <juju-gui:New> <https://launchpad.net/bugs/1388877>
<rick_h_> hatch: looking
<rick_h_> hatch: ok, adding the bug. 
<hatch> I am not sure we have any designs for it - but I figure anything would be better ;)
<rick_h_> hatch: yea
<kadams54> guihelp: Looking for reviews and QA on a small change (all HTML, no JS/CSS): https://github.com/juju/juju-gui/pull/634
<hatch> kadams54: so the tooltop positioning issue can be fixed with .notifier-box.bundle { margin: -5px 0 0 227px; } (from ant__) 
<kadams54> Great. I'll get that in next.
<kadams54> Looks like it's going to be a slew of small branches for me today :-)
<hatch> no mo survey? :(
<rick_h_> hatch: no
<hatch> we did get some valuable input from there in the past
<hatch> I'm guessing nothing has come in a long time?
<rick_h_> hatch: to be honest, I'm not sure how to look in there :)
<hatch> lol!!! 
<hatch> might be worth an email to the g-man :)
<hatch> gary, not the fbi
<rick_h_> I think I might have it in a handoff note. I'll look some day when I have a little bandwidth
<hatch> haha
<hatch> :)
<hatch> kadams54: is it Jujucharms or JujuCharms? Juju Charms? also http://www. or just http:// ?
<rick_h_> hatch: kadams54 I vote just jujucharms.com for now. 
<rick_h_> and it's https
 * rick_h_ adds that to the pr
<hatch> if it's https then the top right button also needs to be updated
<hatch> it's only http
<kadams54> I just followed what the bug specified as far as "Jujucharms". That said, "Juju Charms" makes more sense to me.
<rick_h_> jujugui call in 7 kanban please
<kadams54> guihelp: Another small QA/review: https://github.com/juju/juju-gui/pull/635
<kadams54> hatch: tooltip offset ^
<kadams54> rick_h_, hatch: So to clarify, the link should be: <a href="https://jujucharms.com/docs" target="_blank">jujucharms.com</a> ?
<rick_h_> kadams54: there's two links in that menu, jujucharms and the juju docs
<rick_h_> kadams54: the first should be https://jujucharms.com and named "jujucharms.com" I think
<kadams54> OK
<rick_h_> kadams54: the second should be https://jujucharms.com/docs and called "Juju Docs"
<kadams54> Got it
<kadams54> rick_h_: OK, changes pushed. One last check before shipping?
<rick_h_> kadams54: looking
<kadams54> Bah, missed the change of "Read the documentation" to "Juju Docs"
<rick_h_> kadams54: :+1:
<rick_h_> that's ok
<rick_h_> was that from luca?
<kadams54> No, that was from you, just now :-)
<rick_h_> sorry, I was going off memory and might have steered you wrong :)
<rick_h_> kadams54: so ignore that one :)
<kadams54> OK :-)
<kadams54> Shipping
<hatch> 4 more!
<hatch> its no wonder there were no tests for this before it was split up heh
<hatch> Clicking the icon in the launcher bar on Ubuntu so that it shows all the windows tiled is awesome - I use it so that I can watch both the console and tests run at the same time :)
<hatch> one...last....test
<hatch> Makyo: u around?
<Makyo> hatch, sure
<hatch> Makyo:  any idea how the heck I'm supposed to unit test this method? https://gist.github.com/hatched/e58e95a9aa5c6fe234f5
<hatch> I of course could just stub the methods out and 'fake it'
<hatch> not sure if that's the best way though
<Makyo> That might be the only way, unless you want to do it in test_environment_view and have the whole canvas stubbed out.
<hatch> yeah..no
<hatch> :) ok thanks
<hatch> jujugui I need qa and reviews for https://github.com/juju/juju-gui/pull/636 plz and thanks
<hatch> rick_h_: want to chat about the card in tracking? Should I hop on the other bug in urgent? Added Services? 
<rick_h_> hatch: let's start with the release. Getting the charms sync'd up. The production ones have changes that need to be bzr merged into the dev ones and might be a conflict in there
<rick_h_> hatch: because I screwed up landing changes from eco
<hatch> oh jeeze I don't even know if this vm has bzr on it 
<hatch> well...it does now
<hatch> apt ftw
<rick_h_> hatch: :)
<rick_h_> ty
<hatch> now the question is - do I remember how the heck to use it
<hatch> actually - the first problem is....where are the charms even located?
<hatch> it's been 2 years and I still don't understand launchpads organizational structure 
<rick_h_> hatch: look at docs/process and copy/paste
<rick_h_> hatch: with some reading/understanding before hitting <enter>
<hatch> I'm not sure about the charm changes though
<hatch> there are the ones under juju-gui then there is others somewhere too right?
<rick_h_> hatch: it's in the process doc
<rick_h_> hatch: copy/paste bzr branch commands for both charms
<hatch> ok I'll read it closer :)
<rick_h_> hatch: Make a new release of the juju-gui charm by doing the following.
<rick_h_> start there
<hatch> so why does production have changes that devel doesn't?
<hatch> isn't that...backwards? :)
<rick_h_> because I screwed up :)
<rick_h_> per the previous comment :)
<hatch> ohhhhh
<rick_h_> the eco guys pulled against production, I accepted and merge it. Then realized I should have retargetd the pulls against our dev branches but too late
<rick_h_> I fail
<hatch> tis ok - I'll figure this setup out
<hatch> is there a reason why we didn't move the charm to github?
<hatch> obviously prod needs to be in bzr
<hatch> but the devel ones
<rick_h_> because syncing is a pita and it's new work we don't have bandwidth for 
<rick_h_> as we're learning with the charms elsewhere
<hatch> yeah syncing my ghost charm to bzr is a pain
<hatch> might be able to write a script though
<rick_h_> one day
<hatch> ermahgerd this is still downloading
<hatch> I think we need to truncate this repo lol
<rick_h_> :)
<rick_h_> jujugui http://techcrunch.com/2014/11/03/microsoft-now-lets-developers-run-ie-on-android-ios-and-os-x/?ncid=rss even easier :)
<hatch> oh nice
<hatch> its...still...downloading
<hatch> how big IS this repo
<hatch> it must be over 1GB
<rick_h_> couple hundred mb I think last time I looked?
<rick_h_> no, that's nuts
<hatch> 1363010kB
<rick_h_> which repo is this?
<rick_h_> bzr branch lp:?
<hatch> bzr branch lp:~juju-gui/charms/trusty/juju-gui/trunk/ develop-trunk
<rick_h_> du -hs                                                                             (rharding@hulk:~/tmp/develop-trunk/)
<rick_h_> 209M    
<hatch> when I run it on the dir it only give me 56k
<hatch> er 52k
<hatch> I guess I'll just let it keep going?!?
<hatch> 1471711kB   618kB/s - Fetching revisions:Inserting stream:Estimate 4137/12102
<hatch> it's pulling down almost 1.5GB so far
<hatch> pulled*
 * rick_h_ thinks you broke it
<hatch> into the ether I guess though
<hatch> rick_h_:  https://gist.github.com/hatched/eb87714557aca49d6c02
<hatch> think I should just cancel it then?
<rick_h_> hatch: :/ I guess, rm'ing and retrying it here
<hatch> ok canceling
<hazmat> major gui bundle bug found
<hazmat> its stripping charm config
<rick_h_> hazmat: what's up? 
<rick_h_> hazmat: that's not different from the charm default?
<hatch> rick_h_:  I'll take lunch while we wait for the result from your re-download
<hazmat> rick_h_, i have a charm with a default value, the bundle changes that
<rick_h_> hazmat: rgr
<rick_h_> hatch rgr that is
<hazmat> rick_h_, the gui or charm store.. strips that .. and breaks the bundle..
<rick_h_> hatch: you mean on the bundle export that?
<hatch> hazmat: so when deploying a bundle it doesn't respect the charm config options? Or when exporting?
<rick_h_> bah, tab completion fail today
<hazmat> nothing to do with bundle export this is hand crafted
<hazmat> hatch, on deploy
<hazmat> hatch, my specific examples of this is the kubernetes bundle
<rick_h_> hazmat: ok, can you get me the bundle file and I'll file a bug and we'll look into it
<hazmat> rick_h_, i have to fix it more immediately
<hazmat> rick_h_, by changing the charm defaults
<rick_h_> hazmat: understood, trying to see what's up. this is the kubernetes that's loaded in charmworld then?
<rick_h_> or when you drag/drop deploy the bundle the gui is stripping it?
<rick_h_> hazmat: here to help debug/fix just trying to narrow down what's going on. 
<hazmat> rick_h_, yes kubernetes bundle in store
<hazmat> rick_h_, using gui to deploy
<hazmat> rick_h_, gui search, gui deploy
<rick_h_> hazmat: ok, lookins
<rick_h_> looking
<hatch> I am unable to reproduce - my bundles here are respected by the GUI
<hatch> on import
<rick_h_> hazmat: which config item on which charm?
<hazmat> rick_h_, flannel  options on container type
<rick_h_> hazmat: ok, so they're on the bundle after ingestion. checking what gui sends to the guiserver
<hazmat> rick_h_, k, thanks
<rick_h_> will have to bring up a quick env will be a couple of mins
<hazmat> k
<hazmat> rick_h_, fwiw my sample size is one, but my orangebox has already been reclaimed in terms of further testing here
<rick_h_> hazmat: ok, np. I'm waiting on lxc to come up with the gui to try it out
<rick_h_> hazmat: will let you know what I find. I know on export we limit options that are set to the charm default, but can't think of anything on deploy that would strip them. 
<hazmat> .. yeah seems wierd to me.. also on export i think you mean limit to those that are not set to default
<rick_h_> correct, if the values is the default we filter it from output to the exported yaml file
<rick_h_> hazmat: so the gui sent yaml that includes \"config\":{\"container_type\":\"docker\",\"docker_origin\":\"distro\"}
<hazmat> hmm
<rick_h_> now the yaml is options, I can't recall if that's really config at the api level
 * rick_h_ always gets it mixed up
<hazmat> rick_h_, it should be sending config as options to deployer.. i agree its confusing.. and legacy compatibility is the only reason its like that at all
<rick_h_> what went across the websocket: http://paste.ubuntu.com/8807178/
<hazmat> ie. that's the issue
<hazmat> 'config' instead of 'options'
<hatch> I just tested a bundle I had here and config options were sent properly
<hazmat> hatch, you mean verified they were set on deployed services?
<hatch> yep
<hatch> hazmat:  here is the bundle https://gist.github.com/hatched/42791a6cec26ca6e5493
<hazmat> hatch, that's interesting given we've identified the breakage point
<rick_h_> hatch: how did you deploy that?
<hatch> clicked 'import'
<rick_h_> hatch: via drag/drop?
<rick_h_> hatch: right, this is saying is that when the gui sends the bundle 'model' with the yaml to the back end it's using 'config' instead of 'options'
<rick_h_> hatch: so your test case is a bit different and not hitting the bug hazmat is
<rick_h_> hatch: e.g. the deploy event is causing us to use the wrong string for the options key in the services block
<hatch> I guess I'm confused - this bundle was exported from the GUi and then imported correctly
<hatch> so the issue is?
<rick_h_> hatch: when you click in the browser to deploy, or drag/drop from the sidebar, the event is sending the wrong data
<hatch> ohh 
<rick_h_> hatch: we turn options into config to have the models match and be reusable....that's then sent to the deployer incorrectly
<hatch> well that's no good
<rick_h_> right :)
<hatch> they should be using the same codepath
<rick_h_> hatch: right but in one case the yaml is uploaded, in the other it's the json-ification of the model I think
<rick_h_> will have to chase it down, filing a bug now
<hatch> got it, now I understand :)
<hatch> ok now I'm really going for lunch
<rick_h_> hatch: assigning the bug your way. Don't worry about hte release. I'll do it tonight. I think that should be a small bug fix if you can get it in before your EOD yay
<rick_h_> hazmat: so the work around for the moment is to use a drag/drop or import of the bundle. We're due to get a release out the door today/tomorrow so I'll try to get hatch to fix it up and have a new release out by then with the fix 
<rick_h_> thanks for reporting the issue
<hazmat> dustin and i've hit a few more bugs the last few days of using the gui
<hazmat> deploying some services, try to change the config, can't commit, can't clear.. end just reloading the page to get gui in a sane state
<rick_h_> hazmat: ok, happy to get those knocked out if we can reproduce them. Appreciate you beating on the gui in anger. 
<rick_h_> hazmat: ok, happy to get those knocked out if we can reproduce them. Appreciate you beating on the gui in anger. 
<hazmat> rick_h_, you mean using it;-)
<hazmat> rick_h_, so... the other question that came up is when personal charms can get their icons displayed?
<rick_h_> :)
<rick_h_> hazmat: that's part of the new back end. We've turned off the filter there and when we update the gui to the new api it'll add that feature. 
<rick_h_> hazmat: so in about 3wks should have a release with that as a checkbox option in the gui
<hazmat> k
<kadams54> guihelp: https://github.com/juju/juju-gui/pull/637 is ready for reviews and QA. Also a very small PR, for an icon update.
<Makyo>  On it
<kadams54> rick_h_: let me know what I should work on next. Otherwise I can start looking at some of the high priority maintenance bugs.
<rick_h_> kadams54: where's added services?
<rick_h_> kadams54: once we have the release blockers out I'd like to go back and get that wrapped up. 
<rick_h_> kadams54: did/can you review/qa hatch's card in review?
<kadams54> Yeah, will do.
<rick_h_> kadams54: if there's nothing to do to move things forward there then yes, please look at maint. 
<kadams54> I think I've done all I can on added services ATM, so once I QA I'll start in on maint.
<rick_h_> grrr google "Leaves warehouse by November 3."
<hatch> rick_h_:  ok I'll hop on that
<hatch> how big was the download?
<hatch> rick_h_: added services is waiting on my last branch before it can land don't think there is anything kadams54-away can do on it until that lands
<rick_h_> hatch: 134M
<rick_h_> hatch: ok 
<hatch> 134M? wth was it downloading for me then?
<hatch> lol
<rick_h_> hatch: the world
<rick_h_> to /dev/null
<hatch> rofl 
<hatch> it did seem that way
<hatch> rick_h_: ok starting on hazmat's bug 
<hatch> jujugui I still need two reviews and a qa on #636
<hatch> it's blocking release 
<rick_h_> hatch: Makyo was looking? https://github.com/juju/juju-gui/pull/636 and will try to get another one in a bit
<rick_h_> or kadams54-away when he's back
<hatch> ohh ok I just didn't see any comments
<hatch> or tags on the card
<kadams54> I'm back, looking at 636
<kadams54> hatch: ^
<hatch> thanks
<rick_h_> kadams54: did you see Makyo's qa note on your icon branch as well?
<kadams54> rick_h_: yeah, will take a look after I finish with hatch's branch.
<Makyo> I didn't know we didn't fade un-relate-able ghosts, though I don't remember us ever having done so.
<Makyo> I guess since they're already faded slightly
<rick_h_> Makyo: it could probably use some polish there. 
<hatch> Makyo: the current canvas reactions are all busted
<hatch> you would have to merge in my branch for the real ones
<Makyo> Ah, alright
<hatch> so I'll be sure to get you to QA it once it gets finished
<hatch> :P
<Makyo> \o/
<kadams54> Makyo: spriting issue on https://github.com/juju/juju-gui/pull/637 fixed.
<Makyo> kadams54, +1, thanks!
 * hatch punches non native promises right in the neck
<hatch> rick_h_:  from 2013 :) https://github.com/juju/juju-gui/blob/develop/app/store/env/fakebackend.js#L1824-L1827
<hatch> any idea why?
<hatch> Gary was the last to touch
<hatch> I know why it needed to be changed to config, but why delete options...
 * hatch runs the tests and hope it has them
<hatch> ;)
<hatch> hazmat: did you have a running gui instance to test a fix?
<hatch> (I also am booting up an env)
<hazmat> hatch, nothing i can experiment with on atm
<hazmat> changing locations
<hazmat> bbiab
<hatch> ok I'll report back if this indeed fixes it
<rick_h_> hatch: I can bring back up my local env, shoot me the branch url for the gui charm config
<hatch> rick_h_: thanks but I'm almost there (the branch is https://github.com/hatched/juju-gui/tree/fix-bundle-1388953 if you are interested)
<rick_h_> hatch: ok cool, will still QA 
<hatch> rick_h_:  see "Last Saskatchewan Pirate" https://play.google.com/store/music/album?id=Bkeqoycogjsra3xvap2dydii3pi&tid=song-Tcbllehpxcy4vmjkdoipcwz7h4u 
<hatch> :D
<rick_h_> :P
<hatch> Here is the original https://play.google.com/store/music/album/Captain_Tractor_East_of_Edson?id=Bcfl5tonv5a2gxiaxy3mjsje7em
<hatch> haha
<hatch> The title is an Alberta in-joke, and one of the key tracks on the album is a cover of the Arrogant Worms' humorous "Last Saskatchewan Pirate."
<hatch> guess I was wrong even that wasn't the original 
<hatch> ok it appears to have worked 
<rick_h_> hatch: that didn't change for me, the yaml passed is still config
<hatch> https://gist.github.com/hatched/1ba6ee63e31b9afb95d2
<hatch> is that not correct?
<rick_h_> hatch: this is different
<hatch> I don't get it, I deployed his charm from the charmbrowser and it set the proper config options
<hatch> I thought that was the bug?
<rick_h_> hatch: standup
<hatch> ok one minute need to grab headset
<rick_h_> rgr
<rick_h_> hatch: oh, now that looks right. 
<rick_h_> huwshimi: wow early isn't it?
<huwshimi> Morning
<huwshimi> rick_h_: 9am
<rick_h_> TZ gotta love em
<huwshimi> :)
<huwshimi> rick_h_: I have change to DST recently :)
<rick_h_> huwshimi: and we just fell back an hour this weekend
<huwshimi> rick_h_: Ah :)
<hatch> got to love different countries choosing to change DST's at different time of year
<huwshimi> hatch: We don't even change DST at the same time within the same country :)
<hatch> lol thats horrible
<hatch> we have some :30 timezones but nothing quite that crazy
<hatch> :)
<rick_h_> hatch: did you still need review/QA?
<rick_h_> hatch: is there a branch up huwshimi can look over for you?
<hatch> umm I'm just finishing up the last test for this fix
<hatch> then that will need a look
<hatch> I can't remember about the other heh
<hatch> lemme look
<hatch> looks good on that one, will ship
<rick_h_> k
<hatch> jujugui lf a qa and reviews on https://github.com/juju/juju-gui/pull/638 ciritical fix blocking release
<kadams54> hatch: Looking
<hatch> hazmat:  ^ this is the fix to your bug
<hazmat> hatch, k, thanks for the quick turnaround.. 
<hatch> we aim to please 
<hatch> (sometimes we miss) ;P
<rick_h_> hatch: review in
<kadams54> +1'd
<hatch> and shipped
<hatch> thanks
<hatch> rick_h_: ok so tomorrow I'll finish up the added services branch?
<hazmat> rick_h_, is there a way to refer to a non frozen bundle revision ?
<hazmat> ie. current kubernetes bundle points to bundle:~hazmat/kubernetes/7/kubernetes and i'd like to document it in a readme
<hazmat> but thats going to be stale if i have to ref it with a hardcoded revision
<hatch> hazmat: https://jujucharms.com/bundle/~hazmat/kubernetes/kubernetes/ works
<hazmat> hatch, for pointing to quickstart ?
<hazmat> ie. i can't run quickstart that url afaik
<hatch> oh I have no idea - I just know that the GUI supports it
<hatch> oh :/
<hazmat> quickstart wants either url to bundle content or bundle: .. but the bundle: url embeds the rev
<hazmat> trying to understand if bundle url has syntax to not do that
<hatch> hazmat: https://manage.jujucharms.com/api/3/bundle/~hazmat/kubernetes/kubernetes
<hatch> so it SHOULD work via quickstart?
<hazmat> hatch, perfect thanks
<rick_h_> hazmat: just remove the 7
<hatch> thats what I did yeah - he said that wasn't working
<rick_h_> hazmat: all revisions are always optional
<rick_h_> :/ oh hmm
<rick_h_> while that runs, yes hatch the next goal is to get the AS stuff out the door
<rick_h_> hazmat: so I did juju quickstart bundle:~hazmat/kubernetes/kubernetes
<hazmat> rick_h_, cool, thanks i'll update the readme to do that much nicer url
<rick_h_> hazmat: and got http://paste.ubuntu.com/8809936/
<rick_h_> so should be working, if not let me know and we'll find out what's up
#juju-gui 2014-11-04
<rick_h_> jujugui new release is out
<rick_h_> http://jujugui.wordpress.com/2014/11/04/juju-gui-1-2-3-released/
<rick_h_> urulama: you really here?
<huwshimi> rick_h_: Nice!
<rick_h_> hazmat: bug fix release out, hopefully helps. ^
<huwshimi> rick_h_: Is there a flag to view the added services panel?
<rick_h_> huwshimi: /:flags:/as
<rick_h_> huwshimi: it's still a couple of cards from landing, hopefully done later this week
<huwshimi> rick_h_: Oh, I should have looked at the full changelog :)
<rick_h_> :)
<huwshimi> rick_h_: And how do you actually show the add services panel? :)
<rick_h_> huwshimi: deploy something so you have added services? 
<rick_h_> huwshimi: and then under the search bar is a button that opens it
<rick_h_> huwshimi: find it?
<huwshimi> rick_h_: Oh, I was trying on jujucharms.com
<rick_h_> huwshimi: oh yea, comingsoon
<rick_h_> huwshimi: since we're trying to bring up the new site didn't bother updating that url yet
<huwshimi> yeah :)
<huwshimi> I'm not a person
<rick_h_> not a person?
<huwshimi> rick_h_: I have no brain? I am not functioning :)
<huwshimi> wait, that wasn't a question
<huwshimi> or was it?
<rick_h_> it was, I didn't follow the 'I'm not a person' line
<rick_h_> but gotcha now, some funky saying :P
<hazmat> rick_h_, sweet
<hazmat> so another gui bug, resolve/retry doesn't go through commit
<rick_h_> hazmat: hmm, yea that was intentional. The thought was that doing a resolve/retry isn't really a part of a 'changeset' you'd be trying to put together
<rick_h_> hazmat: more of a debugging command that you want to happen
<hatch> Makyo: u in yet?
<hatch> kadams54: so could you do the added services ui buttons respecting the service visibility state?
<kadams54> hatch: yeah.
<hatch> I don't think that will conflict with my stuff
<hatch> right now I'm trying to figure out why ghost services get selected differently by d3
<hatch> :/
<kadams54> hatch: I don't see a card for that?
<hatch> hmm I was wrong they are getting selected the same...
<hatch> oh I don't know if there is one
<hatch> lookin
<kadams54> If not, I can create one
<hatch> now there is
<kadams54> guihelp: anyone know what the diff is between the agent_state_info and agent_state_data fields on a unit?
<hatch> ahh now I see the issue - css properties override the dom attributes with svg's
<hatch> kadams54: it might be left overs from the pyjuju > juju-core conversion
<hatch> why u ask?
<kadams54> I'd grabbed a card from the maintenance bugs. The GUI is falling over (uncaught exception) when dealing with endpoint errors.
<hatch> oh - no reproduction steps
<hatch> hah
<kadams54> The code currently checks unit.agent_state_data when, at least in this situation, that field is not set. From reading code comments, it seems like it should actually check unit.agent_state_info.
<hatch> I don't think that's the case
<hatch> without repro steps how are we to know if the bug is fixed?
<hatch> I'd reply asking for steps on repro
<rick_h_> hatch: it's not that simple
<kadams54> That's fine, but there's enough info that I can write a test to reproduce the error condition.
<rick_h_> hatch: that bug was from a running env without real steps. There was something when a unit was removed was the comment
<rick_h_> It'll be a 'try to catch this known error by being more defensive'
<hatch> well it appears that there was a failure with a unit being removed causing it's agent data to be cleared out
<hatch> that shouldn't happen - so the issue is somewhere up the stack
<rick_h_> hatch: right, and that broke the gui
<kadams54> agent_state_info was still set
<rick_h_> hatch: sure, juju probably did something bad
<kadams54> We could have looked in there to see that there was an error in the relation
<rick_h_> but we need to try not to break if we can help it.
<kadams54> Which is what this code is trying to do
<hatch> what I'm concerned about is just covering over the issue instead of resolving the root cause
<rick_h_> hatch: understood, but it's not a simple reprdocing issue and there was no work around to help debug further
<kadams54> *Our* issue is bad error handling.
<kadams54> We can address that, which may help in uncovering/addressing the root cause.
<rick_h_> +1
<hatch> sure - but lets step back through the sequence of events which would have caused agent_state_data to be undefined 
<kadams54> So I'm reasonably confident that 1) I can write a unit test that reproduces the error condition and will allow us to say that the bug is fixed and 2) that we ought to be checking both agent_state_data AND agent_state_info fields for the name of the relation.
<rick_h_> hatch: sure, walk the code and see what could have emptied it
<hatch> what I'd first like to do is figure out the difference between info and data
<hatch> I am pretty sure that data is the new field added in juju-core
<hatch> for things like relation issues and the like
<kadams54> Except in this case data isn't there. And info is. And info has the relation issue reported in it.
<hatch> right
<hatch> but they were different formats
<hatch> data was added (I believe) to give us more detailed easier to parse information about the units
<kadams54> Which is great, if it's there.
<kadams54> What I'm saying is that our error handling code ought to check data, and if it's not there, fall back to info.
<kadams54> Instead of just making assumptions that data will always be there.
<hatch> that's fine to do, but before you do that first understand what info and data are and why data was removed when info wasn't
<kadams54> I don't think that's necessary to write good error handling code.
<kadams54> I think it would be good as a follow-up task.
<hatch> so you know that info contains the exact same information as data is checking for?
<kadams54> But good error handling code ought not make any assumptions. Check data first, then info, and if neither is there, do the best you canâ¦ but don't trigger a null error.
<kadams54> unit.agent_state_data.hook.indexOf(endpoint[1].name + '-' + 'relation') === 0;
<kadams54> It's checking to see if the relation name is in the hook
<kadams54> We already know agent_state is "error"
<kadams54> We also know, from juju status, that this is what was in info: 'hook failed: "homer-relation-joined"'
<kadams54> So if that bit of code had just checked for the relation name in both fields (in a manner that didn't assume either field existed), it would've worked fine.
<hatch> right - but there was a reason why we didn't use that and instead added the data attribute
<hatch> I'm just saying - do all the error checking you want, but make sure you understand why data was no longer available 
 * hatch pinging Makyo hatch to Makyo, calling all Makyo's
<kadams54> hatch: as best I can tell, we don't directly set or clear data in our code, which means that it was likely cleared/not set in juju-core.
<hatch> ok if that's the case then we need to file a bug with juju-core
<hatch> it's removing the data prematurely 
<kadams54> I agree, but we also need to not fall down when juju-core does something wrong.
<hatch> we just need to pop this image up http://i0.kym-cdn.com/photos/images/newsfeed/000/774/489/829.jpg
<kadams54> :-)
<hatch> ok I'm going to ignore the not fading ghost services thing and get what I have ready to land - getting ghost services to fade/hide requires changing the d3 fade bits to use css instead
<hatch> ^ rick_h_
<hatch> I fixed it so that it no longer throws an error, but it still doesn't fade/hide (ghosts)
<rick_h_> hatch: rgr
<hatch> follow-up can do that stuff - but got to get this thing landed so it can be qa'd really hard by peeps :)
<rick_h_> :)
<rick_h_> jujugui call in 10 kanban please
<rick_h_> Makyo: call
<rick_h_> jcsackett: call
<kadams54> rogpeppe, fabrice: that's interesting about the lack of options. I'm always hearing about how Europeans have more options because they don't have the duopoly we have here. In the US, for the most part, you can get your internet from the phone company or the cable company (if you can get it at all). There's very little competition.
<fabrice> same here except in big towns
<rogpeppe> kadams54: i have provider options but the only connectivity is copper around here
<rogpeppe> kadams54: http://www.speedtest.net/my-result/3883355136
<fabrice> kadams54: I have a few provider but they all go to the same physical lines
<rogpeppe> http://www.speedtest.net/result/3883355136.png
<fabrice> kadams54: tehy don't bring a lot of different cable to individual house in France
<kadams54> rogpeppe: Yeah, copper is also the only option for a lot of places in the US. Not sure if fiber would be an option where I live, but it's moot because I already know it's out of my price range.
<rogpeppe> that is quite a bit crapper than usual
 * rogpeppe goes to complain to the ISP
<fabrice> kadams54: but if I was on fiber it will be the same price 30 euros
<hatch> kadams54: did I mention fiber is cheaper than copper here? ;)
<hatch> (because it damn well should be)
<kadams54> hatch: yeah, I kinda hate you.
<kadams54> Every time you complain about the fiber being put in.
<hatch> well it's slow as crap right now 
<hatch> 600kbps
<hatch> :P
<hatch> they say they are fixing it, but I'm just glad they aren't digging in my yard anymore
<hatch> I am actualy surprised that more places don't have crown owned telco's
<hatch> crown being govt (not sure if that terminology crosses borders) :)
<kadams54> Why's that?
<kadams54> As an American, the only thing worse (to me) than the current duopoly would be a government-owned monopoly.
<hatch> because a crown corp can run at a low margin because it's goal is to provide a quality service, not fatten the wallets of some billionares 
<hatch> so (in theory) you would get better service for less $
<kadams54> You have a high opinion of the ethics of bureaucrats and politicians.
<kadams54> ;-)
<hatch> our telco is run as it's own company (owned by the govt)
<hatch> and it's hugely profitable
<hatch> and we have 2 other competitors here
<hatch> which basically means the 'big corps' are screwing everyone
<hatch> because this is proof that you can provide a quality service with low population over large distances
<hatch> I think we barely have 1M people 
 * kadams54 scratches his head.
<kadams54> I like how you say everyone's being screwed but then turn around and say "quality service" in the next statement :-)
<Makyo> hatch, standup?
<hatch> right - I am not on a big corp telco
<hatch> Makyo: sure joining
<rogpeppe> interesting, it might bit my wi-fi playing up. i tried plugging in directly and got a much better result http://www.speedtest.net/result/3883389667.png
<kadams54> wow, indeed
<kadams54> Though that up is still painful
<rogpeppe> it's supposed to be 802.11n too.
<kadams54> You know what that meansâ¦
<kadams54> Time to go get an 802.11ac access point :-)
<rogpeppe> there's definitely something playing up in one of my ether switches recently - one my two wi-fi networks refuses to a NAS box in the attic that's attached to the other
<hatch> Makyo: so that got it to work, unfortunately it exposed another bug :/ lol
<Makyo> hatch, sigh, programming 9.9
<hatch> Makyo: I don't understand your new-age-emoji
<hatch> what ever happened to the classics???????
<Makyo> It's eye-rolling.  Come on :P
<hatch> really??
<hatch> I thought it was crying
<Makyo> Yeah, like the . is the nose and the 9s are the eyes
<hatch> man I would suck as a teen now
<Makyo> 9.6
<Makyo> Hahaha
<hatch> stoned
<hatch> that one is stoned right?
<Makyo> Haha, sure :)
<hatch> henceforth be known as The Denver
<Makyo> Which makes a "Denver omelet" kind of spectacular
<hatch> haha
<hatch> kadams54: after merging in develop again I'm having issues with the unhighlight event order of events for making sureonly one thing can be highlighted at a time
<hatch> I think it will need to be changed to work as a method instead of an event - or the event will need to carry with it the token that it's supposed to skip
<hatch> I swear this code never ends
<hatch> it appears to only be out of sync with ghost services?!? 
<hatch> yeah - looks like the time it takes to parse the service list is enough to cause the events to get out of order
<kadams54> hatch: I'd like to try a patch
<kadams54> hatch: http://pastie.org/private/spwbpol1p5aqbjovclha
<kadams54> That will eliminate all of the unecessary events.
<hatch> kadams54: cool Ill give it a go
<hatch> thx
<kadams54> hatch: did that patch help?
<hatch> not sure - had started lunch, broke for a qa, now lunching again :)
<Makyo> jujugui tiny branch for review/qa https://github.com/juju/juju-gui/pull/639
<kadams54> Makyo: looking
<kadams54> Makyo: looks good
<hatch> kadams54: unfortunately that patch didn't work - the service highlights but the token unhighlights leaving the service highlighted
<hatch> very odd
<kadams54> OKâ¦ give me a few minutes and then maybe we can pair?
<hatch> I was just going to leave it until I can get this branch landed
<hatch> need to get this branch in then we can follow it up with fixes 
<hatch> get people using it and such
<kadams54> Yeah, that works too
<kadams54> Can you be sure to include that patch in your branch?
<kadams54> Even if it doesn't address this issue, it still needs to be in there.
 * Makyo zoom to appointment, back in a bit
<hatch> yep can do
<kadams54> jujugui: looking for reviews on https://github.com/juju/juju-gui/pull/640 - not sure how possible QA is.
<kadams54> hatch: thanks
<hatch> well THAT was a violent crash
<kadams54> Eh?
<hatch> vm took down the whole computer
<hatch> http://www.codingame.com/home/platinum-rift coding challenge battle heh
<hatch> mhall119: hey can employees of Canonical participate in the scopes callenge? 
<mhall119> hatch: not this time, no
<hatch> mhall119: booo
<mhall119> hatch: but don't let that stop you from writing a scope :)
<hatch> haha
<hatch> I just wish it opened faster
<hatch> Makyo: I'm investigating the outline issue you noticed. turns out something was changed in this branch that's causing this line to not work
<hatch> curr_node.attr({'xlink:href': new_href});
<hatch> new_href is the proper path but the icon isn't being updated
<hatch> oh I think I found it
<hatch> Makyo:  d3 question https://github.com/hatched/juju-gui/blob/canvas-fade/app/views/topology/service.js#L1494
<hatch> I need to determine while looping through these selections what to set the icon to
<hatch> so I was thinking selection.each(function(d) ... ) buuut it doesn't look like I can get from the object 'd' to the element to set it 
<hatch> I'm sure I'm missing something obvious though
<hatch> ohhh `this` is the element
<hatch> I knew it was something obvious :)
<hatch> selection.each(function(d) { d3.select(this).select('.service-block-image'); });
<huwshimi> Morning
<hatch> mornin!
<huwshimi> hatch: Hey :)
<hatch> jeesh playing wakamole with these tests
<hatch> I've literally had 5 failing tets for 4 hours and been fixing them constantly 
 * Makyo returns. 
<Makyo> Problem solved, hatch ?
<hatch> yeah that one was 2 problems ago
<hatch> :/
<hatch> these d3 tests use so many kludges that it's trying to figure out wth is going on first
<Makyo> Yeah :/
<hatch> can a subordinate relation not go bad?
<hatch> right now I'm working on https://github.com/juju/juju-gui/blob/develop/test/test_environment_view.js#L1165
<hatch> this is failing because iRemainUnchanged isn't in the path
<hatch> but the path is correct without that
<hatch> so I think that this test is just wrong
<hatch> but I am not sure what it's actually testing :/
<hatch> Makyo: maybe you can shed some light on this one ^
<hatch> Makyo: it was actually you who added it in response to some review comments c858ac02
<hatch> https://github.com/juju/juju-gui/commit/c858ac02
<hatch> not entirely sure why that change was made
<hatch> https://github.com/juju/juju-gui/commit/f37d4787a1675d13e9dc4cc4cd42e206b04a9c6b
<hatch> not sure how to get to the PR from there (unless this was a reitveld one) ?
<hatch> after a bunch of testing it doesn't appear to be necessary any longer
<hatch> removing
<hatch> holy I'm now down to 4 tests failing lol
<kadams54> jujugui: still looking for reviews on https://github.com/juju/juju-gui/pull/640
<Makyo> Wooo~
#juju-gui 2014-11-05
<hatch> jujugui call in 4
<rick_h_> hatch: yea!
<hatch> 3 failures.....sigh
<hatch> holy down to 2!
<hatch> kadams54: Did we never write any tests for the setmvvisibitlity method that was moved from the servicelist to the db?
<kadams54> No?
<hatch> ohh it was tested as a side effect
<hatch> ignore me :)
<hatch> I was so distraught I had to close the irc window 
<rick_h_> kadams54: have a question on your branch
<kadams54> What's that?
<rick_h_> kadams54: so trying to follow, in the tests there's an assumption that agent_state == error
<rick_h_> kadams54: but I'm not seeing that as part of the conditional?
<rick_h_> kadams54: oh hmm, I guess it's in a function 'endpointHasError
<rick_h_> https://github.com/juju/juju-gui/pull/640/files#diff-41da19c331704f9c770c1bcad9d31715R1411
<kadams54> Line 1430 includes agent_state === 'error'
<kadams54> Does that answer the question?
<rick_h_> kadams54: ah right ok
<rick_h_> kadams54: yea, I'm cool ty
<kadams54> Going to comment about it in the PR, for posterity.
<rick_h_> kadams54: rgr, also added a request on the bug update so it's clear we're hoping to fix, but could not replicate to 100% validate.
<rick_h_> just ask them to reopen if they hit the issue again 
<hatch> jujugui impromptu poll irissi or weechat? 
<jcsackett> weechat
<hatch> jcsackett: do you just use it within Terminal + tmux?
<jcsackett> hatch: not even in tmux.
<jcsackett> i mean, right now i'm using xchat, but when i use terminal irc it's weechat.
<hatch> I'm getting sick of having to switch windows between editor irc and terminal
<hatch> so hoping to remove one of them
<rick_h_> irssi
 * jcsackett knew that would be rick_h_'s rec.
<rick_h_> with tmux
<rick_h_> I keep meaning to try weechat, it's supopsed to be nice but irssi just works 
<jcsackett> hatch: truthfully, having used both i see little difference. i like weechat b/c i can script it in python instead of perl.
<hatch> hmm that's definitely an advantage :)
<jcsackett> rick_h_: weechat is nice. scripting in python (or ruby or perl but sssh) is nice.
<hatch> I really wish Ubuntu had a terminal client like iTerm2
<jcsackett> what in iterm2 do you miss?
<hatch> it's prettier :P
<rick_h_> I don't scriptit so never bothered. I got irssi setup once long ago and just limp along like someone using windows 95
<hatch> easier to apply colours
<hatch> profiles are easier to manage
<hatch> it's just a better UX really
<hatch> jcsackett: what does weechat use as a bouncer? znc?
<jcsackett> hatch: gnome-terminal, while slow and somewhat bloated, has never struck me as that much weaker vs iterm2, tbh.
<jcsackett> i hear konsole is really nice too, if you don't mind mix and matching your kde and gtk bits.
<jcsackett> hatch: it can use any bouncer.
<hatch> oh nice ok that's good
<jcsackett> hatch: it does have some nice integration with znc--it can parse timestamps and logs sent by it and display them properly.
<jcsackett> i don't remember the details; like rick_h_ once i got things working for the most part i stopped poking.
<hatch> and I definitely don't want to mix display engine bits - I have a personal vendetta against multiple display engines :P
<jcsackett> hatch: don't you already? you're using quassel right. pretty sure that's kde.
<hatch> yeah and it ends up looking like garbage :P
<hatch> I like consistency whenever possible
<hatch> having apps which can use different engines is a little funky
<hatch> ok so I guess I don't have a vendetta against different display engines, just mixing and matching :)
<hatch> good thing open source people (myself included) don't have opinions :P
 * jcsackett laughs
<jcsackett> yes, our total impartiality and lack of opinions is really a defining feature. :p
<hatch> haha
<rick_h_> best tool for the job...so long as it's ruby on rails...for scripting my irc client
<hatch> lol
<hatch> jcsackett: do you use this ppa? https://launchpad.net/~nesthib/+archive/ubuntu/weechat-stable
<jcsackett> hatch: no.
<jcsackett> i just install from the repos.
<hatch> ahh - I like the ppa's, auto keeping things up to date :)
<rick_h_> woot! release is out, get a present
<hatch> jujugui lf a review and qa on the latest added services updates https://github.com/juju/juju-gui/pull/641
<hatch> make that two
<hatch> there will be a few more follow-up branches so requested changes/bugs from reviews may end up being fixed in those
<hatch> kadams54: ^ mind taking a look 
<kadams54> hatch: yeah, digging in.
<hatch> thanks
<kadams54> jujugui: Another PR to review and QA: https://github.com/juju/juju-gui/pull/642
<kadams54> hatch: ^
<hatch> will do
<hatch> kadams54: comment made
<hatch> grabbing lunch
<lazyPower> Greetings juju-gui - question: we seem to have a missing recommended charm from the list on jujucharms: https://demo.jujucharms.com/trusty/hdp-tez-3/?text=tez --  https://jujucharms.com/solutions?type=charm
<rick_h_> lazyPower: looking
<lazyPower> rick_h_: additionally, the hdp-tez charm was updated with the rest of the big data stack, the individual charm view shows old information.  https://jujucharms.com/hdp-tez/trusty -- this may be related.
<rick_h_> lazyPower: ok, so it's there https://jujucharms.com/hdp-tez/, we're working on speeding up the solutions page and atm cut results at 150 and guessing it missed the cut
<rick_h_> lazyPower: looking
<lazyPower> ok, what has me confused is the old icon, and its not showing revision 3
<lazyPower> it may be stuck in ingest somewhere
<rick_h_> lazyPower: so this was ingested yesterday around midnight
<rick_h_> lazyPower: well the first ingest ran then, running every 15 after
<lazyPower> they were updated ~ 1.5 hours ago
<lazyPower> looks right in the gui, not on jujucharms.com - so im' thinking there's just something wonky going on with the websites meta
<rick_h_> lazyPower: rgr, checking
<rick_h_> lazyPower: were there others updated so I can narrow down if it's this one or any?
<lazyPower> rick_h_: the entire big-data suite was updated. reference the updates here: https://code.launchpad.net/~bigdata-charmers
<rick_h_> lazyPower: ok thanks 
<rick_h_> lazyPower: ok, so the rest of the suite loaded it appears. I'm filing a bug on the ingestion code and we'll check if it loads in QA and try to get logs from production. 
<lazyPower> thanks rick_h_ -  sorry to be a complainer :)
<rick_h_> lazyPower: hah broken isn't complaining
<lazyPower> <3
<hatch> Makyo: thanks a lot for the review and qa - those two ghost bugs are known and will be tackled in the immediate follow-up
<Makyo> hatch, rock on :+1:
<hatch> thanks sir
<hatch> kadams54: +1?
<kadams54> hatch: I'm looking at a cross-interaction bug right now
<hatch> does it block landing? Could it be fixed as the follow-up? I'd like to get moving on the next fixes
<kadams54> hatch: http://cl.ly/image/222F3s1O252N
<kadams54> I'll leave it up to you as to whether or not this blocks landing
<hatch> oh that is odd
<hatch> lemme  see if I can repro
<hatch> there are also some relation lines that should be hidden that are only faded
<kadams54> Deploy the mongodb cluster, hide mongos and shard1, highlight configsvr, unhighlight configsvr.
<hatch> ugh
 * hatch crys "Why won't this end"
<hatch> yeah this needs to be fixed in this branch
<kadams54> Then there's this, which is also fun: http://cl.ly/image/3w01042X1n2S
<hatch> yeah looking at the relation stuff now
<hatch> ahh I had if elses
<hatch> you can be faded AND hidden
<hatch> need if's without the elses
<hatch> maybe
<hatch> :P
<hatch> ugh
<kadams54> I do not relish making hatch cry
<rick_h_> hatch: need a second set of eyes/pair?
<kadams54> Last interaction thing I found: highlight shard1, then hide shard2. That puts things in bad state #1. Unhide shard2. Instead of fixing things somewat, that puts them in bad state #2.
<kadams54> Having problems uploading a screen recording right now
<hatch> rick_h_: just stepping through it, my idea on how to fix does indeed fix it, but then it pops back to a broken state afterwards 
<hatch> it's very confusing...
<rick_h_> hatch: let me know if talking it out/etc can help. Happy to jump on and peek
<hatch> yeah gimme 15
<hatch> then we'll see 
<kadams54> Gotta run to pick up the kids. Will be back in about 30.
<hatch> rick_h_: fixed it - looks like it was caused by d3's async fading - can we ditch the fade-in/out animations for now?
<hatch> add them back in later via css?
<hatch> well that fixes one of the bugs
<hatch> :)
<rick_h_> hatch: sounds ok to me
<hatch> great - I've already added a previous card where I removed something similar so that card can now include this too
<hatch> sweet
<hatch> fixed them all
<hatch> trivial fixes too, boy am I happy I did this correctly
<hatch> lol
<hatch> was so worried I made a mistake in the architecture somewhere
<hatch> kadams54-away: just fixing up the tests here then I'll push up a fixed version. Those screen recordings were immensely helpful 
<rick_h_> :( nexus 9 is a movie playing disappointment ouch. 
<hatch> oh really? How come?
<rick_h_> the screen size, it letter boxes the movies so half the screen is wasted
<rick_h_> aspect ratio fail for hd movies
<hatch> oh weird that seams like a huge oversight
<hatch> are you sure it's not just the movie you're watching?
<hatch> I know some movies have weird ratios too
<rick_h_> hmm, yea it's a bit less bad on another movie
<rick_h_> but still :(
<hatch> kadams54-away: ok fixes are pushed, plz try again :)
<hatch> rick_h_: I'm sure you have nothing but free time right now - but the releasable lane still has cards in it ;)
 * hatch runs away snickering
<kadams54> hatch: re-checking
<hatch> thanks
<hatch> now you better not find anymore bugs... :P
<hatch> at least not ones that happen on deployed services :D
<kadams54> Wellâ¦ if canvas looks all clear, I'm going to do regression testing on MV ;-)
<hatch> haha if there are any mv issues they can go in a follow-up :P
<kadams54> Still seeing this: http://cl.ly/image/2c1v2J2P361p
<kadams54> It's better than it was before, but still not what I expect.
<kadams54> (What I expect is for nothing to happen when I "hide" shard2.)
<kadams54> (But maybe that's not right.)
<kadams54> hatch: the other interactions look good, so that's a win.
<hatch> damnit
<hatch> kadams54: ok I'll get back on that shortly - will you be around tonight to take another look? (assuming I can get it fixed in the next 1.5h :) )
<kadams54> Yes, though not until after 8 PM Eastern.
<kadams54> hatch: is it 2:38 local time for you?
<hatch> 3:38
<hatch> GMT -6 always
<hatch> ok well I'll get as far as I can on it then push up if I solve it
<hatch> kadams54: yeah your latest bug is in the code which determines what attributes get set on the models
<hatch> this will take some more time to figure out I think
<hatch> kadams54: what if we disabled the fade button when it is already hidden/faded ?
<kadams54> hatch: yeah, I was thinking through options like that, butâ¦ I'm not sure it would be any simpler to code up.
<hatch> that might just introduce another level of complexity
<kadams54> Yup.
<hatch> ok I might have a solution 
<hatch> maybe
<hatch> heh 
<huwshimi> Morning
<hatch> shit I think I fixed it
<hatch> morning huwshimi
<hatch> kadams54: when is your eod?
<hatch> now?
<kadams54> hatch: 13 minutes and counting
<hatch> lol start a little late?
<kadams54> Well, it's only a little after 5 here, so I won't be working that late.
<kadams54> I generally try to work later since I usually lose some time in the middle of the afternoon to pick the kids up.
<hatch> oh ok :) so you're 1h ahead of me
<kadams54> Yes. We were 2 hours ahead until this past weekend.
<hatch> I appear to have fixed the bug and maintained the other fixes
<kadams54> Super.
<hatch> just need to figure out how to make sure we have a test for this now
<kadams54> I'll give it another whirl
<kadams54> Have you pushed the fix>
<kadams54> ?
<hatch> I haven't 
<hatch> one sec
<lazyPower> rick_h_: as afollow up to earlier with a missing unit, i have untis that have been removed that should no longer be displaying. 
<hatch> kadams54: pushed - do you know where the event extension tests are? 
<lazyPower> for example: https://jujucharms.com/hdp-hadoop-hive-mysql/0 - was removed
<kadams54> test_browser_events.js
<hatch> ermahgerd that page is so pretty
<hatch> kadams54: thanks iunno why I couldn't find it :) brain probably slowing down haha
<hatch> ok writing the test - I REALLLLLY hope you don't find any more bugs
<kadams54> Me too.
<hatch> no bugs so far? Man this must be good news - or there are so many it's taking you a while to catalogue them 
<hatch> lol
<hatch> ok tests pushed 
<kadams54> hatch: looks good
<kadams54> +1
<kadams54> I'll add to PR as well
<hatch> ZONG
<hatch> ZOMG even
<hatch> shippin that ish
<kadams54> hatch: MV looks good even
<kadams54> OK, gotta run, will check in later.
<hatch> awesome - cya
<rick_h_> lazyPower: ping around?
<rick_h_> hatch: :P
<lazyPower> rick_h_: i am
<rick_h_> lazyPower: ok, how was it removed? It's there in the page you linked? Or was something else removed?
<rick_h_> lazyPower: now the try in demo button is disabled because of an ssl issue where browser is blocking an ajax request. We've got a fix landed for that and will be doing a deploy tomorrow with webops
<lazyPower> the bzr repository was removed, as aiui that should remove it from the charm store *but only when talking about bundles*
<lazyPower> s/as/and/
<rick_h_> lazyPower: oh it *needs* to be removed?
<lazyPower> yessir, the hdp-hadoop-hive-mysql, hdp-hadoop-pig, and hdp-hadoop-cluster bundles - as they have serial names that mean nothing to anyone.
<lazyPower> this is part of a cleanup that the new launch shed light upon - to keep things tidy and looking nice.
<lazyPower> tehy were mirrored in the newer bundles you see above, that mirror teh big-data-feature page nomenclature
<rick_h_> lazyPower: ok, will file a ticket to get them removed. Can you shoot me an email with the list?
<lazyPower> sure can, incoming
<rick_h_> lazyPower: thanks, will get it out of there
<rick_h_> lazyPower: copy uros on the email please
<lazyPower> rick_h_: email deployed
<huwshimi> hatch: Are you still around?
#juju-gui 2014-11-06
<huwshimi> hatch: Just wondering if you know how the ambiguous relation menu is supposed to look?
<hatch> huwshimi: hey - it's supposed to look better
<hatch> :)
<huwshimi> hatch: OK, better :)
<hatch> yeah there are no mockups so just better :)
<huwshimi> alrighty then
<kadams54> hatch: I saw the PR of all PRs finally landed.
<hatch> jujugui lf a review and qa on removing the as flag https://github.com/juju/juju-gui/pull/643 
<jcsackett> hatch: looking now.
<hatch> thanks
<hatch> jujugui need one more review for ^
<kadams54> hatch: looking
<hatch> thanks
<hatch> rick_h_: are you ok with the flag removal landing? 
<rick_h_> hatch: is it ready? :)
<rick_h_> hatch: yea, I need to find time to get over to the GUI side and QA and such. Will try to do that once we get the release going today
<hatch> well there is one known bug - so i'd like to get the flag removed so we can catch any related bugs while doing the remaining work
<rick_h_> hatch: rgr
<hatch> there were so many mv related bugs after removing the flag that I want to avoid that
<kadams54> hatch: what's the one known bug?
 * kadams54 really hopes it's the card he's working on.
<hatch> kadams54:  it's theorange card in this project
<hatch> about the toggling of the highlight button
<hatch> kadams54: is that the one you are working on? I was just about to grab it
<kadams54> No
<hatch> ok taking
<kadams54> But I disagree  with the card that unhighlight needs to be changed to method calls
<hatch> Huw did a great job styling the ambiguous relation dialog last night
<kadams54> Or rather, I'm highly skeptical ;-)
<rick_h_> because huw is awesome :)
<hatch> haha he is
<hatch> kadams54: yeah first I need to figure out why it only is an issue with ghost services and not deployed ones
<hatch> then will figure out an appropriate fix
<kadams54> Good stuff - looking forward to seeing it in action
<marcoceppi> for manage.jujucharms.com, I only get 20 results back everytime I search which makes queries like type=approved&series=trusty worthless
<rick_h_> marcoceppi: &limit=1000?
<marcoceppi> changes nothing
<hatch> kadams54: fixed it 
<hatch> without changing it to a method
<hatch> just going to write the test now and then I'll have it up
<kadams54> hatch: sweet. What needed fixing?
<rick_h_> marcoceppi: looking
<kadams54> Sign me up for QA and review :-)
<hatch> heh will do
<hatch> you were on the right track with your fix but looking the wrong direction ;)
<hatch> now the question is...does it work with relations
<kadams54> And does it work with machine view
<hatch> *snif* it does *snif* it's...so....beautiful
<kadams54> And does it work when you turn highlight on for one service and hide 3 other services, two of which aren't related at all to the highlighted one.
<kadams54> And does it work when you go in the reverse direction
<kadams54> kadams54: snap out of it! *slap*
<kadams54> kadams54: Thanks, I needed that.
<hatch> yep everything is good - but ghosted services don't hide properly in the machine views
<hatch> I'll make a card for that for you
<kadams54> *sob*
<kadams54> It took us a week to implement 90% of added services.
<hatch> hah - well you know the mv stuff the best
<kadams54> And then someone *ahem* said, "hey, could we tweak how this works?" And bam, three weeks later.
<hatch> yeah but it's stable now 
<hatch> :)
<rick_h_> marcoceppi: ugh, not sure man. We've not landed any new code there in forever but yes, all queries are maxing out at 20 results. 
<marcoceppi> \o/
<marcoceppi> cool, well that's fine for now I just won't mess with charm-tools for a bit
<rick_h_> marcoceppi: https://api.jujucharms.com/v4/search?series=trusty&limit=600 
<marcoceppi> :OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOo
<rick_h_> if you need some info right now the new api has it working
<marcoceppi> ITS SO FAST
<rick_h_> :) only the ids returned
<rick_h_> but yea, much faster 
<rick_h_> marcoceppi: but don't rely on this yet. It's still early and the url is going to change/etc
<marcoceppi> also, whats the way to get just approved
<marcoceppi> or promulgated or whatever
<marcoceppi> too late, already dependant on it
<rick_h_> marcoceppi: but can help https://api.jujucharms.com/v4/search?series=trusty&owner=&limit=600
<rick_h_> marcoceppi: setting owner= (empty) will show approved
<marcoceppi> \o/
<hatch> kadams54: are there no tests for the onHighlightToggle methods?
<rick_h_> marcoceppi: raising a bug on charmworld and will see. For now let me konw and we can help get you the info needed from the new api endpoint to unblock.
<marcoceppi> that unblocks me for now
<kadams54> hatch: There should be. One momentâ¦
<hatch> ahh they are tested as side effects
<marcoceppi> won't put it in the charmtools stuff
<kadams54> hatch: test_added_services_view.js, around line 304
<kadams54> That tests directly.
<hatch> well it doesnt' send any service names
<hatch> looks like I'll have to modify the suite so I can test with a ghost service id too
<marcoceppi> rick_h_: thanks, here's the bug whenever you guys get time https://bugs.launchpad.net/charmworld/+bug/1390127 no real rush
<mup> Bug #1390127: All queries are limited to 20 results regardless of limit parameter <charmworld:New> <https://launchpad.net/bugs/1390127>
<rick_h_> marcoceppi: ty
<rick_h_> jujugui call in 8 please kanban
<hatch> jujugui lf a review and qa https://github.com/juju/juju-gui/pull/645
<hatch> kadams54: ^
<kadams54> Will look after standup
<hatch> hows your branch coming along?
<hatch> jcsackett: I'll do the other review on huws branch
<hatch> kadams54: your card in the maintenance lane - is it landed?
<kadams54> hatch: ah, yeah, missed that
<hatch> jcsackett: I'm not able to reproduce this bug any longer - could you give it a try on comingsoon to see if it's indeed fixed? https://bugs.launchpad.net/juju-gui/+bug/1339093
<mup> Bug #1339093: Drag and drop failing with syntax error <juju-gui:Triaged> <https://launchpad.net/bugs/1339093>
<jcsackett> hatch: looks fixed to me.
<hatch> thanks, closing
<hatch> jujugui anyone need any reviews?
<kadams54> hatch, Makyo: https://github.com/juju/juju-gui/pull/642 is ready for reviews and QA.
<hatch> kadams54: you didn't reply to my comment
<hatch> actually I'm pretty confused by the override thing too
<kadams54> hatch: I just replied to your comment.
<kadams54> And I addressed the override thing.
<hatch> kadams54: ok so your reply should be in a comment in the code - github is being odd and not showing replies in the code for some reason :/ 
<kadams54> I did put a comment in the codeâ¦ the XXX bit.
<hatch> I do't see any comment about the override
<kadams54> Oh, by "comment in the code", do you mean on the PR?
<kadams54> Or in the code in the code?
<hatch> right but that doesn't say why you couldn't use the real property in the template
<kadams54> Ah, OK
<hatch> and I still don't understand override 
<hatch> that api seems very....fragile
<kadams54> It is
<kadams54> And it's all temporary
<kadams54> There needs to be some way to distinguish between renders that happen after a button click and those that happen on initial view render.
<kadams54> The override flag does that job.
<kadams54> We need to be able to tell, because in one situation (initial render) we want to override the local attributes with the service attributes. In the other (after a button click) we don't want to override.
<kadams54> We don't want to override because the service attributes are being set to their new values asynchronously and may actually still be the old values at render time.
<kadams54> Which would result in the just-clicked button being rendered as inactive.
<kadams54> All of this is way too much for code that is intended to be very short-lived, so I'd rather just stick with the current XXX comment and get a card in for the long-term fix.
<hatch> kadams54: ok review done
<hatch> rick_h_: I'm going to work on https://bugs.launchpad.net/juju-gui/+bug/1375918 - it might take a while, I have no idea :)
<mup> Bug #1375918: units can be created without a service causing cascading failures <juju-gui:Triaged> <https://launchpad.net/bugs/1375918>
<hatch> kadams54: maybe I'm doing something wrong but I can't get your branch to qa properly
<kadams54> hatch: how so?
<hatch> it doesn't work heh
<hatch> even after clearing cache and all that
<hatch> it's like nothing has changed wrt the button statuses 
<hatch> maybe could you try rebasing your branch with develop and checking locally
<hatch> possible something landed that broke it?
<hatch> frankban: hey are you still in?
<frankban> hatch: yes on call
<hatch> np ping when you have a moment
<kadams54> hatch: Bah, no, I broke it myself in the last commit, the one called "review feedback"
<hatch> :) ok lemme know when it's fixed
<kadams54> Fixed.
<hatch> testing
<hatch> kadams54: +1
<hatch> does demo.jujucharms.com use a different font than when deployed locally?
<hatch> they appear to be the same
<hatch> https://bugs.launchpad.net/juju-gui/+bug/1390161
<mup> Bug #1390161: demo.jujucharms.com and locally deployed GUI has different weighted fonts <juju-gui:New> <https://launchpad.net/bugs/1390161>
<frankban> hatch: what's up?
<hatch> frankban: well I'm going to be working on  https://bugs.launchpad.net/juju-gui/+bug/1375918
<mup> Bug #1375918: units can be created without a service causing cascading failures <juju-gui:Triaged by hatch> <https://launchpad.net/bugs/1375918>
<hatch> so this is the one about creating units using 'new' instead of trying to guess the id
<frankban> hatch: ok
<hatch> I was just wondering if there were any issues you could forsee using this approach
<hatch> I can't htink of anything - the machine view seems to work well with it
 * frankban thinks
<frankban> hatch: the more I think about it, the more I feel that units and machines are very similar on that perspective. so I don't see problems (excluding the required changes on the ecs)
<hatch> yeah this change is going to be substantial for sure
<hatch> what I don't want to do is implement it then think of a better approach
<hatch> either for units or machins
<hatch> machines
<hatch> newX is certainly prettier than some random id string
<frankban> hatch: we can never know what's the next id assigned to new entities in juju
<frankban> hatch: that's why the new prefix succeeded in putting ghost machines under a different namespace, avoiding the clashes we have for units
<frankban> hatch: so mysql/new1, wordpress/new2 sounds reasonable and also does not look bad
<hatch> true true
<hatch> this will all fall apart if juju gets ecs in core
<hatch> so I suppose that's not a concern either
<frankban> hatch: exactly, once we have more state from juju we can avoid pretending to have a state in the browser
<hatch> frankban: ok thanks - I'm now more confident that I can emulate the same approach with units :)
<frankban> hatch: yes np
<hatch> rick_h_: I think this is a critical regression https://bugs.launchpad.net/juju-gui/+bug/1390165
<mup> Bug #1390165: container tokens are not rendered <juju-gui:New> <https://launchpad.net/bugs/1390165>
<hatch> it exists in the released version
<rick_h_> hatch: rgr, then please start that, I'm afk for a little bit
<hatch> will do
<hatch> kadams54: I see you have picked up the card I created - were you able to reproduce the issue or do you need more details
<hatch> re the ghost service machine token hiding
<kadams54> Yeah, I reproduced it
<hatch> ok great
<hatch> I'm going to grab some lunch
<kadams54> hatch: I know why ghost machines aren't being highlighted properly. I just don't know how to fix it.
<kadams54> Well, maybe I do.
<kadams54> Seems that I do. Yay.
<hatch> haha yay
<hatch> jujugui need one more review on https://github.com/juju/juju-gui/pull/645
<Makyo> jujugui trivial 1 review/qa for https://github.com/juju/juju-gui/pull/646
<hatch> sure
<kadams54> I'll look at both.
<kadams54> Or hatch and I will split.
<kadams54> Either way.
<hatch> kadams54: he still needs 2
<hatch> and I need one that's not him :)
<hatch> so yep you'll do both ;)
<hatch> +1 Makyo
<kadams54> Makyo, hatch: For the trifecta: https://github.com/juju/juju-gui/pull/647
<Makyo> On it
<hatch> kadams54: interesting...
<hatch> kadams54: needs tests
<hatch> :)
<hatch> might as well start on that now :P
<kadams54> hatch: got a merge conflict when trying to pull in your #645
<hatch> ahh probably in the tests?
<hatch> ok fixing
<kadams54> hatch: IIRC, setMVVisibility was tested indirectly. I did verify that all tests passed. That said, having some direct tests would not be a bad idea, but I'd prefer to handle it in a separate card.
<hatch> kadams54: right - but there was a bug
<hatch> you fixed it
<hatch> the tests didn't change
<hatch> so the tests were insufficient 
<kadams54> Not my fault the original author didn't write any direct tests :-)
<hatch> well even the indirect tests are likely insufficient then
<kadams54> I agree, I just think that's outside the scope of this card.
<hatch> how do you figure?
<hatch> you didn't update the tests to test for the failure
<hatch> so how can we be sure that the next branch that lands doesn't break it again?
<kadams54> It would be one thing if there had been tests originally and I just needed to update them. But since they need to be written from scratch, I feel like it's a big enough chunk of work to justify a separate card.
<kadams54> Which I will tackle next.
<hatch> I'm pretty sure it's just an extra couple assertions in the browser events test file
<hatch> in an existing test
<hatch> but if you would like to create a new test suite for the unit tests I suppose that would be more thorough 
<kadams54> I'd like to get something pretty thorough wrapped around it.
<kadams54> It's a pretty important bit of logic.
<kadams54> Especially with that crazy nested looping going on.
<hatch> conflict resolved on #645
<kadams54> hatch: commented on #645. I'll get to work on a test suite for setMVVisibility.
<hatch> kadams54: so I had thought of that initially but was concerned about people modifying the ghost display name then playing with the added services stuff
<hatch> tbh I'm not sure it's an issue 
<hatch> actually it shouldn't matter because it's in a blocking loop
<hatch> will make the change
<hatch> afp is a frustrating protocol, if it's not being used it closes the connection
<hatch> then doesn't reopen when you try to access
<hatch> and unfortunately there is no --keep-alive
<kadams54> Why are you dealing with AFP?!?
<kadams54> (Unless you mean something other than Apple Filing Protocol.)
<hatch> lol
<hatch> kadams54: my host os is OSX so in order to properly mount my NAS into OSX I need to use AFP
<kadams54> You can't use SMB?
<hatch> OSX has huge issues with mounting anything using 'normal' prototcols
<kadams54> Apple has had AFP deprecated for years now, though they only started migrating away from it in Mavericks.
<kadams54> But still, you're on Yosemite, so you ought to be able to use SMB.
<hatch> are you sure you'r enot mixing it up?
<kadams54> Pretty sure.
<hatch> I moved to AFP in mavericks because other techniques woudln't work
<kadams54> And you're sure the problem wasn't PIBKAC?
<hatch> I was originally using SSHFS I believe
<hatch> which was poorly supported
<hatch> NFS etc
<hatch> maybe that's fixed and I can stop using this horrible bs
<hatch> hah
<kadams54> http://appleinsider.com/articles/13/06/11/apple-shifts-from-afp-file-sharing-to-smb2-in-os-x-109-mavericks
<hatch> lemme check if my synology supports smb
<kadams54> What file system are you using on your NAS?
<hatch> ahh just updated it and there is a smb2
<hatch> option 
<hatch> it's under Windows though
<hatch> very odd haha
<hatch> well I know what I'm going to be doing later
<hatch> kadams54: ok updated
<kadams54> +1'd
<kadams54> hatch: ^
<hatch> word
<hatch> Linkin Park is coming to Stoon
<hatch> w00t
<hatch> too bad they likely won't be playing their first two albums wholesale :)
<hatch> kadams54: looks like you can land #647
<hatch> then hopefully rick_h_ can do a real deep qa on it all :)
<kadams54> I've got this test suite half written, so I'll get that included, just to make you happy hatch :-)
<hatch> lol
<hatch> I think we have all the functionality hammered out now
<hatch> I haven't noticed any bugs since these most recent branches
<rick_h_> wheee
 * rick_h_ crush qa boom
<hatch> haha
<hatch> rick_h_: it's going to be probably an hour before all the pending branches land then i'll be ready for qa
<hatch> or you could merge them into your local branch if you feel like you want to do it now :)
<rick_h_> hatch: all good, I've got broken kid at home so won't be able to go through it well until after he goes to bed
<hatch> hah ok np
<kadams54> Heading out to grab an early dinner with the family. Will be back in about an hour to land #647.
<hatch> coolio
<hatch> hmm for some reason the container tokens have a hidden class applid
<hatch> applied even
<hatch> crap I found another bug
<hatch> ok - container bug fixed and pushed to PR
<hatch> and new bug created
<hatch> https://bugs.launchpad.net/juju-gui/+bug/1390228
<mup> Bug #1390228: Hiding services should update container column machine <juju-gui:New> <https://launchpad.net/bugs/1390228>
<huwshimi> Morning
<rick_h_> hatch: we're going to skip the AU call tonight if that's cool
<hatch> yeah np
<hatch> sorry i missed the ding
<huwshimi> hatch: You didn't miss it, we just started very early :)
<rick_h_> go luca go 
<huwshimi> :)
#juju-gui 2014-11-07
<kadams54> hatch: https://github.com/kadams54/juju-gui/commit/252f24ad38649027e64aff7e2252968a0b37fabc#diff-8d19084702f50f400641361a9cb78591
<kadams54> hatch: tests for setMVVisibility
<hatch> hmm is that enough?
<hatch> there are 4 conditionals in the code so shouldn't there be a test for each path
<hatch> it's definitly missing adding a key to the _highlightedServices prop
<hatch> does one of the tests test the !machine.units story? (sorry I'm pre coffee but I don't see it)
<hatch> speaking of which.....running real quick to grab a coffee :)
<hatch> 1H 9M until I can buy linkin park tickets - I may miss our standup :P 
<hatch> the ticketmaster experience *refresh* *cuss* *refresh* *cuss* *get seat assignment* *website crash* *cuss* *refresh* *sold out* *wait 2 minutes* *refresh* *get same seat assignment* *cuss* 
<rick_h_> surely something better to do with your time :P
<rick_h_> hatch: no link for the branch you've got in review 
<hatch> nah I almost booked a half day for this
<hatch> :P jk
<hatch> https://github.com/juju/juju-gui/pull/648
<hatch> that one?
<rick_h_> hatch: yea, got it thanks
<hatch> rick_h_: that thing you tweeted about would make for a cool charm for people who wanted to host it in their own env
<hatch> jujugui need one more review https://github.com/juju/juju-gui/pull/648
<kadams54> hatch: looking
<rick_h_> hatch: right, like us or other properties in canonical
<rick_h_> hatch: I want to look more but ran across it in my rss feed last night
<hatch> it's a pretty cool idea if it works :)
<rick_h_> yea
<hatch> need actions so people can click 'update dictionary' :)
<rick_h_> heh yea
<hatch> was thinking they should go in the inspector
<hatch> under another tab
<rick_h_> unit and service details is the first thought, maybe running actions in the inspector for results?
<rick_h_> because it's unit level as well the inspector is a bit harder
<hatch> there is no service level?
<rick_h_> there is, service + unit
<hatch> well that's a pretty big oversight no?
<hatch> if I wanted to update the internal dictionary from a remote location for all units I'd have to manually loop through them all?
<kadams54> hatch: missing key added to _highlightedServices prop is tested implicitly in both "highlights XXX properly" tests. Ditto for !machine.units, since none of the machines setup in beforeEach have units set.
<rick_h_> huh? you can trigger actions at the service and unit level
<hatch> ohh ok then that's good - sorry I missunderstood
<rick_h_> hatch: so yes, you can do what you want, and with leader elections there's more power to them as well
<hatch> perfect
<rick_h_> where the service level trigger can get a single unit nominated to do the action/etc
<hatch> yeah that will be nice - we've needed this functionality for a long time
<rick_h_> yea
<kadams54> Alright, this is getting ridiculous. Just had my third merge build fail. Two failures due to NPM errors, one due to a failed notification test.
<hatch> really would like an 'upgrade ghost' button which just goes and pulls the latest version 
<hatch> not sure how one would do a rolling update
<hatch> but....yeah
<hatch> :)
<rick_h_> there was talk in brussels of apis to upgrade single units
<hatch> oh?
<rick_h_> yea, not sure when but the idea is out there
<hatch> *notes that ticketmaster is down again*
<hatch> well that's good to hear at least
<hatch> kadams54: ok now I see how the tests work
<hatch> could you maybe add some comments to that effect
<hatch> it's not really clear that it's hitting those conditionals
<kadams54> Will do
<hatch> kadams54: working on this latest branch I've noticed that there is a LOT of noise around the machine and unit events
<hatch> easily a 5x multiplier on thenumber of machines/units per highlight
<kadams54> Yeah.
<kadams54> I noticed that we fire off change events for every machine in setMVVisibility
<kadams54> When in reality we should be checking for machines that actually change their hide attribute and only trigger events for those
<kadams54> I think re-doing things so that the service token modifies service flags directly, instead of firing an event, will also help quiet things down
<kadams54> I'll be creating some cards once I get this branch to land
<rick_h_> kadams54: let's chat and walk through it before hand. I'm nervous of tokens making model changes. 
<kadams54> Sure. I can chat whenever. tldr version is that changing the attributes directly would simplify a great deal.
<hatch> kadams54: did you review 648?
<kadams54> hatch: No, no I did not. I forgot about it and made a breakfast sandwich instead. Lo siento.
<kadams54> Looking now.
<hatch> do you? do you feeeeeeel it?
<hatch> I think lo siento literally translated means "feel it"
<hatch> :)
<kadams54> "Siento" is also the I form of "sentar", which means "to sit"
<kadams54> hatch: I'm worried about 648.
<hatch> why?
<kadams54> hatch: the lines that you removed were put in by Makyo as part of the added services work
<hatch> yeah, but they don't fit the spec
<kadams54> I tested highlighting and showing and they still seem to work, but I'm not entirely sure why.
<hatch> because the code I removed was only for hiding container tokens
<kadams54> Specifically I'm worried about highlighting
<rick_h_> right, what lines are we talking about in 648? there's no lines there really, just MV tokens?
<kadams54> Deleting lines 206-213 in container-token.js
<kadams54> What's supposed to happen if you have multiple containers on a machine and only one has the service that is highlighted?
<kadams54> Should the other containers be hidden (as we do with other machines)?
<kadams54> Or should they be shown, just without their units?
<kadams54> I don't think the specs we have cover that.
<hatch> kadams54: according to the spec it doesn't say - but it says it should represent the environment
<hatch> so keeping them visible makes sense
<kadams54> Why?
<rick_h_> jujugui call in 6 kanban please
<kadams54> We hide other machines on highlight.
<hatch> this is true
<hatch> but I also think that's weird :)
<rick_h_> no sense highlighting if the one you're highlighting is 3 scrolls down the page
<kadams54> I think showing a bunch of machines with nothing on them is pretty useless in highlighting.
<hatch> I would sort them to the top
<kadams54> Yeah, what rick_h_ said :-)
<rick_h_> so we either remove machines not highlighted or sort and redorder but now you're doing another evil thing and a pita to do :)
<hatch> because hiding them when trying to be a representation of the hardware doesn't make sense 
<rick_h_> hatch: it's tough because there's not an easy 'grey it out' like in services
<kadams54> FWIW: both develop and this branch behave the same way when you have multiple containers and only one has a highlighted service:
<rick_h_> hatch: let's try it one way and get user feedback and update
<rick_h_> I'm with kadams54 on containers acting like machines for the first pass if it's not in the spec
<kadams54> They both display all containers and all services on those containers, even the ones that aren't highlighted.
<kadams54> As long as one service on the machine is the highlighted one.
<hatch> ok it'll be considerably more difficult to do it the other way than I did
<hatch> kadams54: did you want to start on that then while I continue on what I'm on?
<kadams54> hatch: No, not really. I'd like to talk with rick_h_ about having the tokens update the service flags directly and then work on that :-)
<hatch> well this one is blocking release, that isn't
<kadams54> Given that this branch doesn't actually change behavior currently on develop wrt containers being hidden on highlight, I'm fine with landing it and will +1 after standup.
<kadams54> We can then bike shed about correct container behavior separately :-)
<hatch> well it does change it - it makes it so it's not broken lol
<hatch> atm containers with no units are hidden
<kadams54> Which has nothing to do with highlight.
<kadams54> So it doesn't change highlight behavior and it DOES fix brokeness elsewhere
<kadams54> Which is why I'm in favor of landing it.
<hatch> yeah ok cool
<hatch> you make a good point about it matching the machines column
<hatch> see the issue is that there is no way (from within the token) to know if a container should be hidden based on some other service being hidden 
<hatch> it just knows that it has no units 
<hatch> kadams54: so can  you +1 with your comment on the PR so I can land it?
<kadams54> Yeah.
<hatch> uiteam
<hatch> #first
<hatch> kadams54: when on Monday did you want to start pairing on that stuff?
<kadams54> Right away?
<hatch> so.....your 9:30 ?
 * rick_h_ goes and takes a deep breath after thinking hatch was going to blame us for using views as widgets :P
<hatch> lol!
<kadams54> hatch: whenever you get in. 7:30 seems awfully early to me especially on a Monday.
<hatch> events sent
<hatch> we are only 1H apart now remember :)
<rick_h_> TZ party!
<kadams54> Ah yet
<kadams54> yes
<hatch> rick_h_: I invited you as well but it'll probably be a bunch of fumbling around for the first little while :)
<rick_h_> uiteam make sure you put the pr urls in the kanban cards please? I've trained myself now but been a few missing today/yesterday
<rick_h_> hatch: yea, all good. I can let you guys get a plan together without me being nosy :)
<rick_h_> hatch: I think you know where I'm coming from and have been deeply involved in the lessons of the past so :)
<hatch> yeah we've had some.....discussions.....before
<hatch> :P
<rick_h_> I think as much as we go back/forth together we've put some good stuff in place. 
<hatch> rick_h_: kadams54 so once I finish this current branch I THINK that's all that's necessary for the AS release 
<hatch> yup I agree
<rick_h_> hatch: rgr, will do QA today. Going to deploy to guimaas later on and put it to good use with real env
<rick_h_> someone say uiteam
<urulama> uiteam
<hatch> uiteam
 * rick_h_ wonders if /reload works or if I have to close/reopen irssi to pick up the higlight
<rick_h_> ooh yay ty
<rick_h_>  /reload ftw
<urulama> say ui ... uuuuiiii ... say team ... teeeeeaaaam
<rick_h_> lol
<hatch> haha
<hatch> I can't find where I change the highlights
 * rick_h_ will like one highlight to rule them all
<hatch> yeah that was a good idea
<kadams54> rick_h_, hatch: I'd like to look into getting bundle icons to show up in machine view when you first deploy. https://launchpad.net/bugs/1364493
<hatch> ok there we go
<mup> Bug #1364493: Machine token charm icons do not show when you add a bundle <juju-gui:Triaged> <https://launchpad.net/bugs/1364493>
<hatch> kadams54: heh that's a deep one
<hatch> pre-imp?
<kadams54> Yeah, but it annoys the crap out of me.
<rick_h_> kadams54: hmm, I'd hold off on that. I've got a chunk of work this cycle to get first page loads to work without data and I think that falls into this? 
<rick_h_> kadams54: if there's a temp quick fix (1-2days) ok, but we knowwe've got a bigger problem and it's on the schedule for later this cycle
<kadams54> Yeah, sure
<rick_h_> k
<hatch> I'm pretty sure there isn't
<hatch> at least not a clean one
<hatch> someone say ui team :)
<kadams54> What about this one? https://bugs.launchpad.net/juju-gui/+bug/1379653
<mup> Bug #1379653: Health bar in the inspector is in the wrong position <juju-gui:Triaged> <https://launchpad.net/bugs/1379653>
<rick_h_> hatch: yea, that's my fear and why I've got a multi week chunk of work on the schedule for the cycle
<rick_h_> uiteam
<hatch> woot
<hatch> thanks
<rick_h_> kadams54: sounds good to me
<hatch> and yeahgood idea with the time block
<kadams54> +1
<rick_h_> kadams54: the notification count one would be good pre-release
<rick_h_> kadams54: as that's a bit of a regression
<kadams54> On it
<rick_h_> kadams54: ty
 * frankban removes juju-gui, jujugui and guihelp from the alerts
<hatch> frankban: heh I think you were the last remaining guihelp user
<rick_h_> heh still have that one
<kadams54> I still have guihelp
<kadams54> as well as jujugui
<hatch> right, but who used it :)
<kadams54> I used it all the time!
<kadams54> Maybe that explains why I could never get anyone to do code reviewsâ¦ ;-)
<frankban> hatch: I suspected that
<rick_h_> yea I never got two highlights that hit the same people
<hatch> haha
<rick_h_> it seemed like giving me two different cell phone numbers to call you on the same phone
<hatch> did you guys ever have 'identicall' where you had multiple numbers that rang differently on the same phone?
<hatch> this would have been back in the late 90s early 2k?
<rick_h_> yea, when we got our second line when I was a teenager I had that a little bit
<hatch> heh and the caller id separate box
<hatch> ahh people have it too easy today
<hatch> "back when I was your age"
<kadams54> afk - going to take the dog for a short walk and enjoy some rare sunshine.
<urulama> hatch: if you think yosemite looks bad on non-retina display, imagine how yosemite looks on a hdtm tv!
<urulama> hatch: that thing is horrible!
<hatch> urulama: lol!
<hatch> sigh got to reboot again, vm is being wako
#juju-gui 2014-11-09
<huwshimi> Morning
#juju-gui 2015-11-06
<stokachu> rick_h__: you mind looking at https://github.com/CanonicalLtd/jujucharms.com/issues/176 and seeing if I've done something incorrectly?
<stokachu> im still not seeing my bundle show up
#juju-gui 2016-11-08
<fabrice> good morning everyone
#juju-gui 2016-11-10
<arosales> Hello, any folks noticing any odd charm store API responses
<arosales> we are seeing this more that once in our charm testing:
<arosales> http://paste.ubuntu.com/23456776/
<arosales> I also tried to just load jujucharms.com/openstack-base and got a 404. I retried and got the page, but it did 404 on initial load.
<rick_h> uiteam ^
<hatch> arosales: hmm I haven't noticed any issues
<hatch> but will keep an eye on it
<hatch> it's working well here
<arosales> hatch seeing quite a few of them
<arosales> hatch: if you click through on any "yellow triangles" at http://data.vapour.ws/cwr-tests/results/index.html
<arosales> you'll see the juju charm store api time'ing out
<arosales> hatch: is there any web logs that log these ?
<hatch> there are, yeah there are quite a few triangles there
<hatch> hmm
<arosales> well most "yellow triangles" are for time outs
<arosales> some are ssh errors
<hatch> sure no problem, I'll get in touch with the right people to investigate, thanks for bringing this up
#juju-gui 2017-11-06
<bdx> yoooo
<bdx> heyyy
<bdx> when I export a bundle from the gui, it doesn't include zone information
<bdx> is zone info excluded for a reason when exporting a bundle from the gui?
<bdx> for example, I just deployed this http://paste.ubuntu.com/25905242/
<bdx> and the resultant bundle exported from the gui looks like this http://paste.ubuntu.com/25905249/
<bdx> see what I'm saying?
<bdx> no zones
<bdx> idk
<bdx> bug?
<rick_h> bdx: since zones are auto selected and not the same from region to region I don't think they're kept
<rick_h> bdx: can you deploy with those same zones into a eu region or the like?
<bdx> rick_h: thats a maas
<bdx> see the --to zone deploy commands in the first link
<rick_h> bdx: oh fine, prove I didn't open your pastebins :P
<bdx> :)
<rick_h> bdx: yea, file a bug please. I think my above reason is the "why" but as you note doesn't make sense everywhere
<bdx> rick_h: where do bugs go for that
<rick_h> bdx: the gui is good, github.com/juju/juju-gui/issues
<bdx> thx
