#juju-gui 2013-08-05
<frankban> hi rogpeppe: is statecmd still the preferred package where to put API calls logic? or is it preferred to put everything in apiserver/client/client.go?
<rogpeppe> frankban: statecmd is the place to put logic which is called by both cmd/juju and the API server
<rogpeppe> frankban: the aim is to eliminate it eventually, when we make the command line tools use the API
<frankban> rogpeppe: ack, I guessed so. So, if I need to implement several helper functions called by an API call, is it ok to put them in client.go?
<rogpeppe> frankban: yes
<frankban> cool
<frankban> thank you
<rogpeppe> frankban: which API call are you implementing, BTW?
<frankban> This week (maybe to day) I'd like to start working on ServiceUpdate. It will include the MinUnits parameters.
<frankban> rogpeppe: ^^^
<frankban> s/to day/today/
<rogpeppe> frankban: what else will it include?
<rogpeppe> frankban: i guess i'd naively expect a ServiceSetMinUnits call
<frankban> rogpeppe: as discussed with William, some weeks ago, everything: charmulr, settings(yaml), constraints
<rogpeppe> frankban: ah, seems reasonable
<frankban> rogpeppe: he mentioned that an API like this could help in the process of making this kind of calls transactional, IIRC
<frankban> rogpeppe: so, maybe a good strategy could be implementing some helper functions that will be call by the new ServiceUpdate and by the other API call that share the same functionality (e.g.ServiceSetCharm). does it make sense?
<rogpeppe> frankban: that seems reasonable. presumably this new call is going to overlap in functionality with some existing calls.
<frankban> s/will be call/will be called/: writing today is particularly difficult...
<frankban> rogpeppe: yes, as I said, ServiceSetCharm is one example, and others are ServiceSet/ServiceSetYAML
<rogpeppe> frankban: is the aim that the GUI actually changes several of these things in the same call?
<frankban> rogpeppe: the only difference is that in ServiceUpdate every parameter is optional. This seems easily achievable for strings and structs. For ints, perhaps pointers can help.
<frankban> rogpeppe: I am not aware the GUI needs this (it only needs a way for setting MinUnits atm), but in the future hopefully can take advantage of this new unified call. 
<rogpeppe> frankban: yeah, i'm just wondering what thing we're aiming to making transactional. if we never want to change a service's charm URL in the same transaction as setting its constraints, i'm not really sure i see the point of conflating the two calls
<frankban> rogpeppe: maybe I am wrong, and I misunderstood what William told me some weeks ago: maybe the goal was to prevent partial successes?. anyway, I am pretty sure that he requested the new ServiceUpdate API to be implemented, and this will allow the GUI to set the MinUnits for a service. I believe I will also need to take care of including service.MinUnits to the megawatcher for the service.
<rogpeppe> frankban: ok. i'm concerned about the fact that this means we'll want to deprecate the old calls, and i'm really wanting to keep the client api as stable as possible, but i guess that's just a hit we'll have to take
<frankban> rogpeppe: yeah. I guess ServiceSetMinUnits would work for us as well, but I was clearly pointed to this other direction
<rogpeppe> frankban: yeah, i'd like to bring this up with william but he's incommunicado. you'd better go with what he said.
<frankban> rogpeppe: cool, thank you
<gary_poster> antdillon, hi
<antdillon> Hi gary_poster 
<gary_poster> antdillon, I have a few options for you
<gary_poster> 1) style the zoom widget
<gary_poster> 2) fix the export widget in the inspector (it doesn't upgrade; haven't checked out why)
<antdillon> gary_poster, Sure I'll grab the zoom widget. That shouldnt take me long
<gary_poster> 3) put the purple circle in for landscape issues in the inspector
 * frankban biab
<rick_h> gary_poster: do you know who can answer gnuoy's question on the deployer in #juju? 
<rick_h> gary_poster: http://paste.mitechie.com/raw/993/
<gary_poster> (luca can tell you where that is :-) )
<gary_poster> 4) thanks rick_h 
<gary_poster> heh that was not 4
<gary_poster> rick_h, on freenode #juju?
<rick_h> gary_poster: yes, that's where he asked it. I figure it's an IS thing? 
<gary_poster> thanks rick_h replied there
<rick_h> gary_poster: yep, thanks. 
<gary_poster> antdillon, #4 was "see if something else is broken and tell me about it and fix it if no one else is working on it" ;-)
<antdillon> gary_poster, Awesome, I'll work through them in that order I think, seems to make sense
<gary_poster> cool antdillon thanks
<sinzui> jujugui webops are urging us to provide nagios integration to the juju-gui charm. Does someone have time to review my branch? https://code.launchpad.net/~sinzui/charms/precise/juju-gui/nagios/+merge/177588
<benji> sinzui: I'll be glad to take a look.
<benji> sinzui: in way of quid pro quo I would like to know who the best person to talk about the jujucharms.com charm would be
<sinzui> benji, I and abentley are the most familiar in both authorship and deployments
<benji> sinzui: I was thinking more on the ops side.  I need to verify (through some means that I have yet to devise) that the charm ops used for the GUI includes our latest changes (cache headers)
<teknico> benji: fyi, when I run "apache2ctl configtest" on a charm deployment, I get this output: http://pastebin.ubuntu.com/5950894/
<benji> teknico: that's something I should look into; thanks!
<benji> teknico: hmm, when I run it on a box with a deployed GUI charm I get "Syntax OK"
<teknico> benji: also, the config/apache-site.template file uses both tabs and spaces for indentation :-)
<benji> ok, now THAT is a problem 
<sinzui> benji, gunoy and thedac are best. gnunoy is online now in fact.
<teknico> :-)
<benji> sinzui: cool, thanks
<teknico> benji: there might be some problem with my deployment then
<benji> teknico: I added a "a2emod" call to the dependencies setup step that should have added mod_headers
<teknico> benji: I have not seen that, are your cache changes in trunk already?
<benji> teknico: yep: http://bazaar.launchpad.net/~juju-gui-charmers/charms/precise/juju-gui/trunk/revision/71
<frankban> it's interesting that in Italy we use "quid pro quo" in a different way, meaning "misunderstanding". and we express the "exchange of services" meaning using another latin sentence: "do ut des"
<benji> frankban: interesting; it seems that the "substituting one thing for the other" (i.e., misunderstanding) meaning is closer to the original usage
<abentley> benji: I am thinking of going back to versioning, but before I do, is there anything left from Friday that we still need to put to bed?
<benji> abentley: not that I am aware of.  You might ask Gary if he needs anything for the demo [it may be done now, for all I know]
<abentley> gary_poster: Is there anything you need for the demo (or is it over)?
<gary_poster> abentley, it is over.  server was down again but it was ok.  people still very happy with progress.
<abentley> gary_poster: That's a shame.  It's surprising it's so tempermental-- it's deployed exactly the same way as staging.
<abentley> gary_poster: I'll rip it down now unless you want to keep it around for some reason.  I expect we'll have staging updated to work similarly soon.
<gary_poster> jujugui, orangesquad, busy now but wanted to say generally that people (including MS ;-) were very pleased with the demo.  Juju group has a meeting this evening so may get more details this evening, but so far so very good.  Thank you!
<sinzui> frankban, :) In British English we use "to table" to mean lets talk now, but in America English the phrase means talk later.
<abentley> gary_poster: Great to hear.
<rick_h> gary_poster: woot!
<gary_poster> abentley, yeah, rip it down.  sorry it didn't work out but glad for progress nonetheless
<frankban> :-)
<benji> sinzui: where is the best place to contact gunoy, I don't see him anywhere I normally /join
<rick_h> benji: he was in #juju eariler today
<rick_h> earlier ugh
<sinzui> benji, #webops
<hatch> morning all
<antdillon> Hi, is there a way to clean the css its appending the new styles?
<hatch> say what?
<rick_h> lol
<antdillon> When I refresh a local juju gui it add's the combined css from the less to the end of the existing css
<antdillon> Does that not happen for everybody else?
<hatch> so you're getting *.less content at the end of the css file?
<rick_h> antdillon: I think you need to go a little deeper. 
<rick_h> antdillon: yes, normal build is to process the less styles and build a combined stylesheet out of them
<rick_h> antdillon: I don't think we have an 'unprocessed' version of it in single files available right now
<antdillon> hatch, rick_h Not less content, this combining the css and adding it to the end of the css file
<antdillon> rick_h, My juju-gui.css file is 27000+ line long at the moment
<rick_h> antdillon: hmm, 16,221 here
<antdillon> I guess just deleting the contents of juju-gui.css and re-running would do the trick
<rick_h> antdillon: right, I understand what you're saying, but we're not following what you're asking. You want to rebuild the file? You want to not combine the file?
<hatch> antdillon: maybe run `make clean`
<hatch> rick_h: I 'think' that it's concatenating the contents to the file instead of remaking it
<hatch> is what he is saying
<antdillon> rick_h, Yes sorry I want to combine but it retaining the css from before the change
<rick_h> hatch: oh hmmm, antdillon what commands are you running to 'rebuild' the css?
<antdillon> hatch, Yes appending to new combined styles to the end
<antdillon> rick_h, Just refreshing the localhost
<rick_h> antdillon: if yuo wanted to try to keep your new stuff isolated I'd add a css file to index.html and hack on it. Then combine it into the right places in the less world. Any less file changes should auto-rebuild the css file for you. 
<antdillon> hatch, So every refresh is adding over a 1k of lines to the css
<rick_h> antdillon: want to chat on a hangout? maybe easier to follow/suggest something?
<hatch> well that's not possible hehe
<hatch> so something is broken :)
<antdillon> rick_h, Oh ok, I can split it off to its own. Just wondered if instead of concatenating the new combined styles it could replace
<rick_h> antdillon: well that's why I ask what commands you're running? It should auto rebuild on its own as you edit the existing files.
<hatch> i'm still curious as to how refreshing the browser is adding to the css file
<rick_h> antdillon: if you manually run some less command, it might act strange
<rick_h> hatch: yea, it can't be. So there's some step we're missing. Why I suggest a hangout at this point
<rick_h> to see what's up
<antdillon> rick_h, hatch No commands at all, I had a few changes to stylesheet.less and refreshed a few times and its combining the styles on each refresh but not replacing the content in juju-gui.css but appending it to the end
<antdillon> rick_h, So If I give something some styles and then remove them it keeps that on earlier lines.
<antdillon> rick_h, I have to set them back to defaults
<hatch> antdillon: and if you run `make clean` and then `make devel` again?
<rick_h> antdillon: ok, I see it. It's broken. 
<rick_h> antdillon: it should not be doing that. 
<rick_h> antdillon: so you found a bug :)
<antdillon> rick_h, Woop lol
<antdillon> hatch, Running them now
<rick_h> filing and will see what we can do about it. 
<rick_h> antdillon: we'll get you a short command to use for the moment. Sec
<antdillon> rick_h, Cool, are you not moving over to SASS?
<rick_h> antdillon: trying to, but not today
<antdillon> rick_h, COol
<antdillon> rick_h, Oh by the way not sure if you've seen emails yet but I set up a frontend mailing list for canonical if your interested
<antdillon> hatch, Worked a treat, thanks
<hatch> antdillon: np - that's the goto 'fixall' :D there is also `make clean-all` which will also remove all of the node modules
<hatch> antdillon: I joined your mailing list...do I get a grab bag or something now? :)
<rick_h> antdillon: this will 'reset' faster than a make clean will. 
<rick_h> rm build-shared/juju-ui/assets/juju-gui.css build-shared/juju-ui/templates.js  && make build-shared/juju-ui/templates.js
<rick_h> antdillon: just keep that in your command history for doing a 'reset' on the css and should help. Filing a bug now
<hatch> rick_h: do we know how to repro the bug?
<rick_h> hatch: yea
<hatch> oh ok cool
<rick_h> hatch: #1208503
<_mup_> Bug #1208503: juju-gui.css rebuilds over itself improperly <juju-gui:Triaged> <https://launchpad.net/bugs/1208503>
<hatch> rick_h: so you're telling me this has been happening for almost a year and noone has noticed?
<rick_h> hatch: looks like the less build command in templates.js is doing a "appendFileSync" which I assume means it's appending vs rebuilding the file
<rick_h> hatch: well think about it. cascading CSS
<hatch> lol
<rick_h> it appends the new rules, which cascade over the old ones
<rick_h> so it didn't 'effect' the layout/etc
<hatch> that would be 'cascading cascading style sheet'
<rick_h> n + 1
<hatch> haha
<rick_h> hatch: so since it's in the node stuff I'll assign it to you :P
<hatch> sure thing :)
<antdillon> hatch, Thanks, yes its in the post!
<antdillon> rick_h, Thanks
<hatch> well all of the stump grinders in the city are rented so I gota get back to digging this damn thing out :/
<rick_h> grinder!
<Makyo> jujugui meeting in 10 according to calendar, kanban now
<rick_h> <3 those things. 
<hatch> oh standing up is in a couple minutes
<Makyo> 9 now.
<rick_h> yep
<hatch> maybe I'll hang around then
<Makyo> jujugui call in 1
<bcsaller> how did I miss this change? :-(
<rick_h> trying to get in but no load on the page :(
<teknico> does anyone fancy reviewing some more charm refactoring? :-) https://codereview.appspot.com/12467044
<gary_poster> jujugui, orangesquad, hi.  I'm afraid I have a meeting with MS in conflict.  However...
<gary_poster> I just forwarded an email to peeps
<gary_poster> Could you start the next hour by reading its content? :-)
<rick_h> gary_poster: so hangout is not taking place now?
<gary_poster> rick_h, not with me, no
<rick_h> hah "It's better to have something like 'the number of commits in the last month'"
<rick_h> so what were they acutally using in this? Was it some sort of mockup?
<gary_poster> rick_h, in part
<rick_h> gary_poster: ok, I guess it says it used the 'prototype' in two states but assumed it was a juju-gui install
<gary_poster> y
<gary_poster> used juju-gui for part
<Makyo> Some of these run counter to goals expressed to us as a team in Oakland.  Would be interested to discuss after IoM. 
 * gary_poster has not read yet; will do so tonight.  We can hopefully talk about it this week, even.
<rick_h> gary_poster: gotcha. Yea some of these confuse me and I assume it's how the mockup version worked. Not sure how they 'changed the tab' 2/3 way down. The back button works for going back to the charm after clicking a related one, hooks is gone, ti's source. 
<rick_h> very cool to read though. Some good info in here
<rick_h> always fun to have testing back up things that have been said/brought up. 
<gary_poster> cool
<gary_poster> jujugui, orangesquad, please be welcome to send comments to the mail
<abentley> gary_poster: I don't know which mail you mean.  After you mentioned it, I looked at the juju-gui ML and didn't see anything.
<rick_h> abentley: PM
<gary_poster> abentley, juju-gui-peeps
<gary_poster> abentley, private
 * benji reboots to do a little post-lunch RAM upgrade.
<benji> abentley: I'll be ready to join up in a couple of minutes if I'm not too late to the versioning party
<abentley> benji: Okay, let's hang out whenever you're ready.
<benji> abentley: guichat is open
<hatch> hey all
<huwshimi> Morning
<hatch> morning huwshimi
<hatch> thanks for the update on the build script
<huwshimi> hatch: Hey
<huwshimi> hatch: I was going to push a branch up for that today
<huwshimi> hatch: It's a tiny fix
#juju-gui 2013-08-06
<hatch>  figured as much but haven't looked yet
<huwshimi> hatch: https://codereview.appspot.com/12494043/ if you want to review
<hatch> done
<huwshimi> hatch: Thanks!
<hatch> no probs
<hatch> huwshimi: being a css guy I figured you might be interested in my latest blog post http://fromanegg.com/post/57464448123/css-selectors-the-next-level
<hatch> lemme know what you think (or if I have any errors ;) )
<huwshimi> hatch: Nice.
<huwshimi> hatch: I think the second code example should be ".dog::first-letter"
<hatch> checking
<hatch> yup
<hatch> :) thanks
<huwshimi> :)
<huwshimi> Other than that it's a handy guide
<hatch> thanks, glad you like it :)
<antdillon> gary_poster, Morning just landed a branch with updated zoom slider styles: lp:~ya-bo-ng/juju-gui/zoom-slider-update
<rick_h> antdillon: do you need help getting this into review and such then?
<antdillon> rick_h, Not sure Gary wanted me sending stuff for review
<antdillon> rick_h, But I just do  lbox propose -cr right?
<rick_h> ant-lunch: ï»¿ï»¿ï»¿ https://codereview.appspot.com/12523043
<rick_h> ant-lunch: added a card to the board. Will get it reviewed and such.
<rick_h> ant-lunch: comment/question on the images in the code review for you https://codereview.appspot.com/12523043/
<antdillon> rick_h, Will sprite them now
<rick_h> antdillon: thanks
<antdillon> rick_h, Done, want me to do a mp?
<rick_h> antdillon: do just push an update to your branch and I'll pull it down and resync it with the code review in progress 
<antdillon> rick_h, Thanks
<rick_h> orangesquad, is there a way to check for errors on a charm? https://jujucharms.com/sidebar/~pavel-pachkovskij/precise/rack-4/ shows no readme but there is one in the source. 
<abentley> rick_h: You can look at the ingest logs.
<abentley> orangesqad, bac or benji: Could you please review https://code.launchpad.net/~abentley/charmworld/restore-questions/+merge/178753 ?
<bac> abentley: sure
<benji> abentley: I'll take a look.
<benji> or not if bac is dying to do it (abently: do you need one or two reviews?)
<abentley> bac: Thanks.  benji, I don't need two reviews.
<abentley> benji: But thanks anyway.
 * benji and bac thumb wrestle; bac wins.
<bac> \o/
 * bac hops up and down, rocky style
<bac> abentley, benji: how did gary's demo go yesterday?
<abentley> bac: The server was down, but he said it went well anyway.
<benji> non-esistent; the server was down so he did the "demo" with hand waves
<bac> darn
<rick_h> antdillon: sorry, think we had a miscommunication there
<rick_h> antdillon: any png in the assets/images directory is turned into a sprite automatically. we can use that with the css "sprite filename". 
<rick_h> antdillon: if you look around you can see it used in a bunch of places
<rick_h> antdillon: so I was more just looking for the css styles to be onthe divs you used vs the image links themselves. 
<antdillon> rick_h, Ah ok, on it
<rick_h> antdillon: sorry, didn't mean to make you sprite up the images you added on their own. 
<antdillon> rick_h, I've put the images as backgrounds of the divs instead of images
<rick_h> antdillon: it's why we've got that 'non-sprites' directory. For images that don't need ot go into the auto-sprite
<rick_h> antdillon: right, and that's what the sprite tooling in place does
<bac> abentley: the text in iter_categories() is user-visible i assume.  did you grab that from somewhere else or make it up?  i ask because there are some grammar issues but i don' t want to spend a lot of time on them if they are not user visible nor under our control.
<abentley> bac: I grabbed it from the original migration that produced the questions.  It is user-visible.
<abentley> bac: The original: http://bazaar.launchpad.net/~juju-jitsu/charmworld/trunk/view/243/migrations/versions/001_load_qa_questions.py
<bac> abentley: ok, some just look clunky but perhaps read correctly in context.
<bac> abentley: and 'user' is only members of ~charmers, right?
<bac> as in 'user visible'
<abentley> bac: The user is anyone who looks at the QA ratings.
<bac> oh, ok
<abentley> bac: There are definitely grammar problems.  Some questions refer to the subject as singular "passes tests...", while others refer to it as plural "Contain a suite..."
<bac> abentley: done
<bac> abentley: if you could make a pass at those it would be nice.
<antdillon> rick_h, Ok to keep the button and hover images together? Or should I separate them all and change the background image
<rick_h> antdillon: no, split them up back like they were. Just don't link directly to them. Use the sprite css classes to load them into the backgroud of your divs
<antdillon> rick_h, Got ya
<abentley> bac: The content of those questions is the ~charmers' choice AIUI.  We can certainly point out the issues.
<rick_h> antdillon: run  `bzr grep "sprite "` to get an idea of uses there
<antdillon> rick_h, Cheers
<hatch> morning
<hatch> frankban: looks like you fixed CI :)
<hatch> yay!
<frankban> guihelp: we ignored that poor jenkins guy for so long... but (for) now he's back to sanity!
<hatch> thanks for doing that :)
<bac> yay, frankban
<frankban> :-)
<teknico> frankban: he's such a jenk, you know ;-)
<gary_poster> yay, frankban, thanks!
<gary_poster> jujugui, fwiw, I'm going to work on Huw's proposed branch for a break. :-)
<hatch> gary_poster: this one https://codereview.appspot.com/12506044/ ?
<gary_poster> hatch yeah
<hatch> ok I'm also in the process of reviewing
<bac> teknico: doing your 2nd review
<gary_poster> hatch oh ok.  you do it then.  did you already fix the destroy service duplication and the expose issues?
<gary_poster> hatch, if not I'll do it :-)
<hatch> negative
<teknico> bac: thanks, you may want to hold off qa though, I'll fix the problem frankban pointed out first
<bac> ok
<hatch> gary_poster: so far the main issue I've found is that he moves the viewlet-manager-footer into the service-configuration.partial
<gary_poster> hatch, that's per request
<hatch> which isn't really semantically correct
<gary_poster> hatch oh
<hatch> I know the button should move...just that we should keep the footer class in the wrapper :)
<rick_h> abentley: got a sec to help me debug what's up with this charm please?
<gary_poster> got it.  hatch, may I work on the expose issues and the destroy issue duplication?  :-) I need a little fun
<hatch> haha you bet
<abentley> rick_h: Sure.  Is it the one you mentioned earlier?
<gary_poster> :-) thanks
<hatch> how was the flight?
<gary_poster> very long hatch, three legs. :-/
<gary_poster> but fine otherwise
<hatch> I suppose that's the best you can hope for :)
<rick_h> abentley: yea, I finally setup my ssh to get into staging. On staging I'm seeing http://paste.mitechie.com/show/994/ in the logs a ton in app.log
<rick_h> abentley: but having a hard time seeing where this error comes from. The log line says "update_charm" but update_charm doesn't do a warning, and the error format has "error" in the name so it's from elsewhere and trying to chase it. 
<abentley> rick_h: The exception is being raised by Bazaar.
<rick_h> abentley: greeping for part of that message comes up with no results so guessing it's coming out of something else? 
<abentley> rick_h: It looks like the user uncommitted that revision, because I can't see it on the Launchpad branch.
<rick_h> abentley: ah, ok. /me didn't realize you could uncommit a revision
<rick_h> abentley: what's the way I can suggest he moves forward? Can he get back the uncommitted revision and move forward from there? 
<abentley> rick_h: So, the uncommitted revision is actually on Launchpad, but because it's not part of the current history, it's not being fetched.  He's just committed a new revision, so we should stop caring about the old one soon if we haven't already.
<rick_h> abentley: yea, I thought maybe he was hitting the proof error of no revision file so he pushed an updated version with a revision file and we waited for ingest to pick it up
<abentley> rick_h: The new revision is from 48 minutes ago.  Do you have any errors more recently than 30 minutes ago?
<rick_h> abentley: m.j.c. pulled the revision enough that the changelog is updated, but the config/readme and other files seem stuck pre this issue http://manage.jujucharms.com/~pavel-pachkovskij/precise/rack
<rick_h> abentley: yes, latest is from 3min ago
<rick_h> abentley: looks like this error is hit every ingest cycle
<abentley> rick_h: m.j.c is on revno 5.
<rick_h> log files is spammed to death
<rick_h> abentley: well app.log
<abentley> rick_h: Okay, so I guess the charm store is slow.
<rick_h> abentley: yea, that's the latest rev in bzr. he went from r4 to r5 today as part of working this out
<teknico> bac: bug fixed, qa may proceed, thanks again :-)
<antdillon> rick_h, Do you need to use js to add the hovered class to display the hovered image?
<rick_h> antdillon: I'd assume we could use a :hover css selector?
<rick_h> antdillon: oh wait, so there's a hover on the sprite image?
<rick_h> antdillon: if so then yes, we'd need to change the css class on mouse in/out
<antdillon> rick_h, I think I will because changing the background pos isnt working
<abentley> rick_h: So, the charm store still is using pavel.pachkovskij@altoros.com-20130301074156-vkto1nnhg3pujiyq.  Once it updates, we'll update: https://store.juju.ubuntu.com/charm-info?charms=cs:~pavel-pachkovskij/precise/rack-4
<rick_h> abentley: ok, will tell him to hold on and keep an eye on it. Thanks for the help
<rick_h> abentley: and I'll check with him about the uncommit usage to verify that's what caused it to become a mess
<abentley> rick_h: Technically, that URL should be https://store.juju.ubuntu.com/charm-info?charms=cs:~pavel-pachkovskij/precise/rack so it tracks head.
<rick_h> abentley: ok
<antdillon> rick_h, Unless I can plus or minus from current bk pos :)
<rick_h> antdillon: huh? I'm not following. 
<rick_h> antdillon: what are we hovering?
<antdillon> rick_h, So the sprite system is putting the sprites in the middle sprite sheet so I can't use hover to move the bk to the corrent hover pos. I'll add classes with js
<antdillon> rick_h, Hovering the plus and minus buttons on the zoom
<rick_h> antdillon: ok, right. We'd have to use js to change the css class to the hover image title 
<rick_h> antdillon: it's a good idea anyway to avoid flicker while the hover image is loaded on the first runs
<hatch> gary_poster: there is one other issue in https://codereview.appspot.com/12506044/ that you could also fix ;) The inspector height is always the full allowable height regardless of the content
<gary_poster> ack hatch, thanks, will discuss with luca et al. Wondering about interaction with charm panel.
<rick_h> gary_poster: I *thought* we set both the height of the left breakout along with the inspector height in the 'recalculateHeight' method 
<rick_h> gary_poster: so they should be kept in sync 
 * rick_h reads link to catch up
<gary_poster> rick_h, right.  the question is whether the desire to have a nice full charm side panel overrides the desire to have a short charm panel when needed.
<hatch> gary_poster: ahh right I forgot about that change
<hatch> frankban: teknico do either of you live here? https://plus.google.com/u/0/103804991882843552936/posts/5SANwPcSYrG :D
<hatch> gary_poster: how do we respond to the jujugui documentation doc?
<frankban> hatch: no we don't. that's near Naples, there are beautiful places in that area.
<hatch> yeah - I would imagine expensive to live there too?
<bcsaller> anyone have a few minutes to help me diagnose some test failures, it looks like I have a crossed wire. lp:~bcsaller/juju-gui/conflict-ux/
<hatch> bcsaller: you bet
<frankban> hatch: well, I guess buying an house there is more expensive than the average in Itay, and the average here is ... expensive.
<bcsaller> thank you, this thing is driving me crazy, hopefully shallow with another set of eyes
<hatch> bcsaller: it's because you're up to early
<hatch> you should sleep in for another hour
<hatch> :)
<bcsaller> oh, this is from yesterday too though
<hatch> frankban: haha yeah? what's the avg per square foot?
<gary_poster> hatch, jujugui documentation doc: could comment on it?
<hatch> gary_poster: ok can do - I just wasn't sure if there was a discussion thread somewhere or not
<frankban> hatch: you are asking too many unit conversions here ;-)
<hatch> frankban: oh right...sorry per sq/m :)
<gary_poster> hatch, nope.  some verbal discussions here, but nick is out this week
<hatch> ahh
<hatch> bcsaller: first issue.... :8084/test/test_conflict_ux.js 404 (Not Found)
<hatch> :)
<bcsaller> hatch: added, sorry and pushed
<hatch> :D
<bcsaller> those tests are not the one with the issue though
<bcsaller> wait till you see this one... :-/
<hatch> waiting.........
 * hatch needs faster computer
 * hatch starts indigogo campaign for new MBP
<bcsaller> http://0.0.0.0:8084/test/index.html?grep=Inspector%20Constraints is the short cut in this case
<hatch> 5 failures so far
<bcsaller> oh, I only get 4 in that module
<hatch> allllmost doneeee
<hatch> alllllmmmoooossssttttt
<hatch> and done
<hatch> 75s
<hatch> oh man haha
<hatch> it's 50s slower in the console
<hatch> er faster
<hatch> ok investigating now
<hatch> I get the 4 errors you speak of, and an error in Inspector Conflict UX
<hatch> should indicate conflict and allow resolution of constraints
<hatch> if you were wondering what the other error was
<frankban> hatch: http://www.immobiliare.it/Salerno/casa-Positano.html it's in italian but you can easily find the important bits of info, e.g. â¬ 680.000  | 85 mÂ² ;-)
<bcsaller> hatch: oh, that last test is new, I'll add a skip, was trying to figure out what happened with the rest
<hatch> bcsaller: oh ok cool
<hatch> frankban: haha yep that's expensive :D
<hatch> bcsaller: your asserts are backwards
<hatch> just fyi
<bcsaller> hatch: I didn't write those, but I agree
<hatch> expected is the second param
<hatch> confusing...I know
<hatch> ohh
<bcsaller> existing tests that now break 
<bcsaller> but in such a strange way
<hatch> yeah I see that
<bcsaller> subscribers seem to be getting crossed
<hatch> ok grabbing my coffee then I'll dig in deeper
<bcsaller> oh me too, me too
<rick_h> bcsaller: so I got failures on that section when I had left over dom elements from an earlier test
<rick_h> bcsaller: when I did proper html cleanup it went away
<rick_h> bcsaller: so I'd start out with debugger; in there before those tests run and peek at Y.one('body').get('innerHTML')
<bcsaller> rick_h: thats good to know, but even running them in isolation seems to cause it
<bcsaller> rick_h: container seems to populate alright and I made selection of the nodes in the callbacks goto the viewlet container rather than the viewlet-manager container (its ancestor)
<rick_h> bcsaller: by isolation you mean with a .only? or by commenting out the rest of the test files?
<bcsaller> rick_h: with only/grep
<rick_h> bcsaller: I only figured this out after commenting out the actual index.html references and going through them debugging. 
<rick_h> bcsaller: ah ok
<teknico> hatch: I've been there, it's as steep as it looks like :-)
<bcsaller> rick_h: maybe I'll give that a quick try
<Makyo> jujugui call in 10, kanban now
<hatch> oh yeah it's Tuesday thanks Makyo
<hatch> :)
 * hatch goes to review board
 * Makyo on autopilot
<hatch> haha
<Makyo> jujugui call in 1
<hatch> teknico: guichat now
<hatch> bcsaller: so somehow button.save-constraints was hitting button.confirm ....I'm a little concerned here :)
<rick_h> ugh, bug trackers, where idea go to die. 
<hatch> rick_h: heh not ALL bug trackers
<bcsaller> hatch: yeah, me too, we should have that talk at some point, the distance is definition and invocation of callbacks is all messed up
<hatch> sure - can we bench it until after the chat with Gary?
<bcsaller> absolutely, thats why I said at some point
<hatch> bcsaller: do you need another review?
<bcsaller> hatch: you have looked at this branch before, but if you have bandwidth another look would be good
<rick_h> antdillon: how are we doing? Need a hand with it?
<antdillon> rick_h, Almost there, just trying to workout how to get the sprites.css to have the hover styles after the normal style
<rick_h> antdillon: k, going to do this user testing call and afterwards I'll ping you and we can do a hangout and get it straightened out if that's cool?
<antdillon> rick_h, Cool, let me know
<adeuring> abentley: could you please have a look here https://code.launchpad.net/~adeuring/charmworld/etag-for-charm-api-view/+merge/178792 ?
<abentley> adeuring: Sure thing.
<hatch> gary_poster: call now?
<antdillon> rick_h, Done it, just updated my branch
<rick_h> antdillon: ok, will pull down after this call and check it out. Thanks for working through it
<antdillon> rick_h, Thanks
<bac> gary_poster: meeting?
<abentley> adeuring: This approach to hashing doesn't seem to distinguish between a list with ['a', 'b'] and a dict with {'a': 'b'}.
<adeuring> abentley: oh, good catch.
<abentley> adeuring: Maybe just serialize to json and hash that?
<adeuring> abentley: nice idea, simple and reliable. I'll do this
<abentley> adeuring: Cool.  You'll want to specify sort_keys=True.  Other than that, I think it's a stable representation.
<adeuring> abentley: right
<abentley> adeuring: Also, you can simplfy "if x in y: del[x]" as "y.pop(x, None)"
<adeuring> abentley: ah, right
<gary_poster> jujugui, sorry I was pulled away.  can we start the call in 5 minutes, at 25 after the hour?
<hatch> we are already in it haha
<gary_poster> :-) ok cool.  will join then
<abentley> adeuring: I think it's reasonable to call _charm_result(Charm(charm_data)) rather than _charm_results([charm_data])[0]
<adeuring> abentley: yeah, I thought too that thisa bit more complicated than necessary, but did not want to change existing stuuf...
<abentley> adeuring: Cool.
<hatch> gary_poster: so it looks like your laptop has a very directional mic - when luca was talking we could barely hear him if it wasn't pointed at him
<hatch> that's pretty cool
<bcsaller> hatch: we still need to have that other event selector call but I could use a break from video for a bit
<hatch> a-greed
<hatch> 20mins?
<bcsaller> hatch: sounds good
<benji> abentley: any hints as to why "bin/migrations upgrade --init" would generate this exception?  migrations.migrate.MissingExodusIndex: Exodus index "charms_pending_010" does not exist.
<rick_h> benji: pyc file left around?
<benji> rick_h: It's a fresh branch (I don't colocate dev branches, they are all unique snowflakes that deserve their own HD space)
<gary_poster> hatch, ack will try to remember
<hatch> gary_poster: oh and one more thing - are you going to be landing huw's branch or am I taking over at some point (just because it's getting late there already)
<rick_h> jujugui can I help get a second review for ant's branch? https://codereview.appspot.com/12523043
<hatch> sure
<hatch> you forgot a G in your lgtm :)
<rick_h> hatch: hah
<rick_h> ugh, and he's gone
<hatch> rick_h: so now that we are pulling the CSS into our own stylesheet we can drop the yui3-skin-sam and just go with the .yui3-slider-y
<rick_h> hatch: but I thought the sam skin was put on a container of the slider
<rick_h> so we need to match the specific-ness to override the default 
<rick_h> hatch: oh hmm, not on the slider then. 
<hatch> well yeah we could now stop loading the yui css and then just rely on our own styling
<hatch> rick_h: done - w/QA
<rick_h> hatch: cool
<bcsaller> hatch: whenever you want to have that chat
<hatch> rick_h: with all of those styles being overridden it probably isn't much of a stretch to copy over the remaining required styles and then stop loading the yui css for the slider
<hatch> bcsaller: ok guichat?
<rick_h> hatch: yes, we've had this discussion. However, I've lost my day to helping land this branch and chasing a charm bug. At this point, I'm letting this go, not making anything worse in the current app, and letting there remain the todo to clean up skin-sam to another day. 
<abentley> benji: Sounds like you didn't run prepare-upgrade first.
<benji> ahh; let me try that
<benji> abentley: that worked.  Thanks!
<abentley> benji: np
<hatch> rick_h: alright - I'd like to create a task/card to go through the app and remove all of the yui css entirely
<hatch> rick_h: you landed the branch without the user select classes :/
<hatch> rules*
<rick_h> hatch: ? /me goes to look again
<hatch> unless I'm on the wrong diff
<rick_h> hatch: it's here, /me checks the diff
<hatch> oh woops
<hatch> sorry
<hatch> I was on the wrong diff
<hatch> my bad
<rick_h> hatch: ah ok. cool. Had me nervous I was editing and submitting two different things :/
<rick_h> hatch: card added
<hatch> thanks
 * benji takes a really late lunch.
<hatch> rick_h: bcsaller jcsackett thought you guys would find this interesting https://github.com/yui/yui3/pull/1063
<jcsackett> hatch: that is fantastic.
<hatch> yeah could really help simplify some of our routing
<bcsaller> yeah, not bad, function or regex makes sense to me there, but regex is a good start
<hatch> bcsaller: yeah - his argument against supporting functions was that at that point you should use middleware
<hatch> which I suppose is valid
<rick_h> hmm, I guess it can help clean up our 3 different view route points, but at the expense of complicating up the routes themselves
<rick_h> so 1/2 one and 1/2 another imo
<hatch> yeah I actually think that the subapp routes can be distilled into a cascading series of routes instead of how it's currently done
<hatch> (which is how they are supposed to work)
<hatch> even a bunch of our primary routes could do the same
<hatch> well I suppose we are removing like 90% of our primary routes haha
<rick_h> yea, if we could verify we hit once and only hit the first matching route we'd be in good shape, but those aren't the rules
<hatch> well how routes are 'supposed' to work is that they are supposed to cascade
<hatch> so you 'build up' your data set as you step through routes and then show the UI on the final one
<hatch> I've never successfully developed that system from the start of an app
<hatch> but always ends up being where they logically progress to in the end
<bac> abentley: on friday you had a bundle ingested to staging from launchpad, correct?  i'm trying to view the json but get no_such_bundle
<bac> abentley: is it still there?  shouldn't this be the url:
<bac> http://staging.jujucharms.com/api/2/bundle/wiki-bundle/wiki
<abentley> bac: Yes.  You are missing the revision.  http://staging.jujucharms.com/api/2/bundle/~abentley/wiki-bundle-1/wiki
<bac> worse, i was missing the fact it wasn't promulgated!
<hatch> bcsaller: so it appears that nested describes execute the code in their parents even when run in .only() mode.....very interesting
 * hatch is trying to organize tests like you do
<abentley> orangesquad, bac or benji: Could you please review https://code.launchpad.net/~abentley/charmworld/separate-qa/+merge/178841 ?
<benji> abentley: I'll take a look
<abentley> benji: Thanks.
<bcsaller> hatch: I tend to do that to reuse test code where I think it makes sense, but I like the simple hierarchy  by itself
<hatch> yeah I like how it can say these are the ghosts tests and these are the sections to which it's testing
<hatch> make them easier to find/organize
<benji> abentley: your branch looks good
<abentley> benji: Thanks.
<bac> benji or abentley: Branch for review for bug 1208035 -- should be quick.  https://code.launchpad.net/~bac/charmworld/bug-1208035/+merge/178849
<_mup_> Bug #1208035: TypeError Bundle takes exactly 2 arguments <charmworld:In Progress by bac> <https://launchpad.net/bugs/1208035>
<abentley> bac: I'll get it.
<bac> abentley: thanks for the help earlier.  i am able to access staging now.
<abentley> Woot.
<abentley> bac: Why are there two test_no_paths?
<bac> one charms one bundles
<abentley> bac: r=me.
<bac> thanks abentley
<hatch> I get nervous when a tests doesn't fail
<hatch> rick_h: somehow the slider sprites got broked http://comingsoon.jujucharms.com/
<hatch> just realized it's past your EOD too :)
<hatch> jujugui anyone available for a review? https://codereview.appspot.com/12567043/
<bcsaller> hatch: I'll look
<hatch> thanks!
<hatch> wb gary_poster
<hatch> isn't it reeeaaaal late there? :)
<gary_poster> hey hatch :-)
<gary_poster> 10:37 :-)
<hatch> oh ok so not too bad
<hatch> bcsaller: the ghost_inspector file changes only add a describe wrapper
<hatch> but bzr doesn't handle indentation changes well
<hatch> bcsaller: thanks for the review - re-sending the commands at scale - did you mean env should throttle these or core should accept a list?
<bcsaller> hatch: it could take a list, which at scale is still a race, or it could support things like 'retry units in state x' as a server side operation
<bcsaller> I think that style API makes more sense when you have 1k units that need replacing for example
<hatch> yeah I'd like to offload the list to the server, but we can batch the requests to the server right now to get around that in the mean time
<hatch> if you think it's necessary
<hatch> I think I'll make a ticket regardless
<gary_poster> bcsaller, hatch, +1 on fixing the bug you emailed me about.  However, I'd like it to happen after the conflict resolution and scale up/down work.  We could then carve out a few days with a strong expectation that tests and docs for these things would be significantly improved during that time.  Then bcsaller and/or Makyo could work on the charmbrowser bundle code (or prototype) and then bcsaller could help luca prototype the dragging thing.
<hatch> that sounds like a plan - today ended up getting bogged down with some reviews/discussions and whatnot so I'm behind anyways :/
<gary_poster> ack hatch
<hatch> gary_poster: you may also have input on this https://bugs.launchpad.net/juju-gui/+bug/1209015
<_mup_> Bug #1209015: Unit action buttons could lock up the UI at scale <juju-gui:New> <https://launchpad.net/bugs/1209015>
<bcsaller> gary_poster: that sounds like what we expected, thanks 
<gary_poster> hatch, thanks.  I don't think it is a burning issue, but will be one to chip away at in the coming months.  Thanks for highlighting it.
<hatch> bcsaller: actually caught it :)
<bcsaller> nick complete made that read funny :)
<hatch> haha woops
<hatch> I have filed 26 bugs since I started....look at me go
<hatch> about to be 27
<hatch> https://bugs.launchpad.net/juju-gui/+bug/1209016
<_mup_> Bug #1209016: Right hand zoom slider handles sprited improperly <juju-gui:Triaged by rharding> <https://launchpad.net/bugs/1209016>
<hatch> boom
<hatch> jujugui need one more review on https://codereview.appspot.com/12567043/
<gary_poster> hey hatch, what should I do to fix viewlet-manager-footer in huwshimi's branch?  Can you give me a quick patch?
<hatch> umm
<hatch> one sec
<gary_poster> hatch should I just dupe the style and give it a new class name?  that looks like the heart of your issue IIUC
<hatch> yeah the footer style should be reverted and it moved back to where it was in the wrapper
<hatch> then a new styles on that element
<hatch> s/a//
<gary_poster> cool, on it hatch, thanks
<benji> later all
<hatch> np
<hatch> asd
<hatch> a
<hatch> sorry I broke my client
<hatch> did you get my last msg about reverting the style?
<hatch> oh valuechange event why won't you fire for me
<bcsaller>  hatch I had to deal with that as well
<bcsaller> hatch: there is a work-around on the tests of my branch
<bcsaller> that took me a while to figure out as well
<hatch> well it works fine in chrome but not in phantom for some reason
<hatch> looking at your branch
<hatch> ahhhh simulate focus
<hatch> niiice
<hatch> I was .focus()
<hatch> that has to be a bug with YUI
<hatch> thanks for figuring that out
<gary_poster> hatch, https://codereview.appspot.com/12506044/ has my comments to Huw.  review if you get a chance, otherwise np.  I want to review your branch, but it needs qa, and I really should get to bed.
<gary_poster> so will leave it for someone tomorrow. Sorry :-/
<hatch> sure np :) have a good night
<gary_poster> ttyl, all
<gary_poster> thanks :-)
<hatch> bcsaller: so setting the id of the ghost automatically updates the element in the DOM in the app, but it's not updating the DOM in the tests
<hatch> the callback is being called
<hatch> the value is being set on the ghost inspector
<hatch> ghostService
<hatch> i mean
<bcsaller> hatch: is it in a textarea?
<hatch> nope it's an input but the change callback is being called and setting the id on the ghostService instance
<hatch> so whatever is listening to that change event isn't connecting
<hatch> do you know where that's listening?
<huwshimi> Morning
<hatch> morning huw
#juju-gui 2013-08-07
<hatch> huwshimi: have you had a chance to look at the comments on your branch from yesterday?
<huwshimi> hatch: Was just reviewing Gary's changes
<rick_h> hatch: did you peek if the images on the zoom was correct in trunk? /me is wondering if this is a case of broken build step?
<hatch> rick_h: sorry I haven't I just noticed it in passing and created a ticket
<rick_h> hatch: k
<hatch> I also rage quit at EOD today sooooo probably won't go back at it until tomorrow
<rick_h> hatch: k, np. I'll check it out later when I'm properly pc bound
<hatch> rick_h: so I think that changing the path or hash of a file is better than etags because etags still require a get request
<hatch> thoughts?
<rick_h> hatch: so the thing is that caching layers in the middle work properly with etags nicely. It's based on the content of a file and doesn't pollute the url. 
<rick_h> so you want to create a hash of a file, that's what an etag is
<rick_h> it's just in the header vs the url
<rick_h> so you don't have to see it
<rick_h> browsers and web servers have spent a lot of brain power making these work really well
<hatch> right but that still requires a request whereas the other approach <filehash>-main.js for example can be infinitely cached so will never request a new file
<hatch> it's almost like an etag is for a sysadmin to implement caching whereas the hash approach is for the developer to do it :)
<rick_h> hatch: hmmm, I guess that works. Man it seems fugly. It's true it's a request, but it's only going to make the request if the cache time has expired, and then it'll only be a HEAD request. 
<rick_h> hatch: yea, but the thing is that because it's in the sysadmin side, it's fully supported by things like squid/varnish, CDNs, etc
<hatch> I wonder if it's a big hit on mobile because each http request can be a huge delay
<rick_h> I guess in our case where we've only got a few files it's not as bad, we still need etags for the images and other things we load
<hatch> i've seen http requests over 10s long...so does it block loading of the page until that req comes back?
<hatch> (I have no idea)
<rick_h> hatch: well, I'd say look at our server logs and see if we've got 10s requests
<hatch> it's not the server, it's the network
<hatch> so for example
<rick_h> this thing is deployed by admins into a environment on a cloud service. I doubt they're 10s from it. 
<rick_h> not to mention the lack of mobile right now
<hatch> client makes request -> it gets lost in internet land for 10s (what is the browser doing now?)
<rick_h> hatch: yea, I gotcha
<hatch> is it waiting? or is it displaying the out of date code
<hatch> 'potentially' out of date code
<rick_h> hatch: but we can tell stuff like that by looking at the request times for a user across the files fetched on load
<rick_h> we 'have' the data
<hatch> I'm not talking about us specificially
<hatch> just about the technology
<hatch> if the http request gets stuck somewhere....what is the browser doing
<rick_h> well, the technology works, it tested, and works for all files. images, static js, dynamic content, etc. 
<hatch> I think you're missing what I'm saying
<rick_h> if the http gets stuck somewhere a user is going to reload the browser. they're an impatient lot
<rick_h> if someone pulls the internet plug mid-request it's pulled. 
<rick_h> so what?
<hatch> well using the hash approach the browser (after getting the index.html) can start to render the content (assuming everything is the same) using the etag approach it has to make those extra http requests and wait for them to return to start rendering
<hatch> (at least I would assume that's what it does)
<hatch> so on a connection with slow http round trips it would be a large performance gain to use the hash approach
<rick_h> well, first time it fetches the files regardless. Then the next time you request it, the browser checks the TTL and if that's passed up it makes a HEAD request saying "I'm looking for this content, with this etag"
<rick_h> and the server says to either re-submit a GET request or carry on, your copy is fine
<hatch> right....at which point it's waiting
<rick_h> hatch: right, if the latency is 1s round trip it would suck. Now show me 1s round trip times from people using our tool :P
<rick_h> hatch: and the hash solution works for files that you hash. What about the rest of them?
<rick_h> so it works with our 3 js files, 2 css files?
<hatch> I wasn't talking about our tool - just the technology in general
<rick_h> we've got 50+ requests on a page load?
<hatch> right - you probably wouldn't want to generate hash filenames for images
<hatch> at least unless your on huge scale
<rick_h> at that point you CDN so that no one has 1s round trips. 
<rick_h> the files are close to them at all times
<rick_h> unless you're in the artic on a science study
<rick_h> then suck it 
<hatch> oh man I wish, my http requests from my phone are constantly 1s+
<hatch> more if it's unprimed
<rick_h> that's total request
<rick_h> with transfer
<hatch> nope just round trip
<rick_h> run speedtest on it and tell me what the ping time is
<rick_h> sorry, but having a hard time buying that using your phone you've broken down ping times and page load time due to transfer
<hatch> ok loading speedtest
<hatch> http://blog.hipchat.com/2012/10/26/performance-tuning-ios-making-mobile-fast/ see point 1 on this page though
<rick_h> hatch: yes, but a HEAD request isn't 1.5s, or 3s
<rick_h> that was the time for his api request. Which was latency + time to build response + time to transfer the actual payload + latency again
<hatch> 755ms ping time
<hatch> 62ms ping time
<hatch> i'll try once more
<hatch> 140ms ping time
<rick_h> yea, that's a *little* variance
<rick_h> so 62ms ping time means a check for an updated file if the etag is expired (only after the TTL is already passed anyway) is 130ms round trip
<rick_h> 140, it's 1/4 of a second round trip
<rick_h> now, if it's 755, then right...you just wasted a second and a half
<hatch> 655ms
<hatch> they are all over the map
<hatch> so the 'perfect' world would have every file with a hash type name, next step would be hashed js/css and then etagged images, next would be etagged everything, next (far behind) no cache headers
<hatch> :D
<hatch> ncie fix btw :D
<rick_h> heh, somehow I screwed up removing the pressed version and got rid of the original version :/
<rick_h> and a make devel didn't rebuild the sprite so didn't notice :(
<rick_h> thanks for the catch now 
<hatch> well it was pretty hard to miss when I pulled in trunk and was qa'ing my latest branch haha
<hatch> I was like 'how did I break that??'
<rick_h> ugh, was that kind of day I guess. Finished with a bang
<hatch> check this out http://www.docker.io/
<rick_h> yea, been there done that. api wrapper over lxc containers yay
<hatch> that's what I was thinking it was
<rick_h> I'd rather fix lxc container api and use juju on it
<rick_h> but it's getting a lot of attention even from people inside canonical
<rick_h> but all the mac-heads that <3 it hate it can't run on their machines since they don't have lxc
<hatch> haha
<hatch> so once the lxc api is fixed in juju then this won't be necessary any longer?
<hatch> if I'm understanding it correctly
<rick_h> no, the lxc api is part 1
<rick_h> automating installs and bit is part 2 and that's juju
<hatch> hehe ""Mac, Windows and some Linux distributions cannot natively run Docker at this time so we help you setup a Ubuntu virtual machine and run Docker inside of that.""
<antdillon> I have added a new branch does anyone have a min to review? lp:~ya-bo-ng/juju-gui/inspector-icons
<abentley> rick_h: So, it looks like the charm store still hasn't updated cs:~pavel-pachkovskij/precise/rack to revision 5.  Have you been in touch with anyone about it?
<rick_h> abentley: hazmat ping'd me back in irc saying it's "out of devs hands" so I need to figure out who in IS runs it I guess and go from there? I think basically it's hung up on the uncommit or what not and not updating at this point. 
<abentley> rick_h: Yes, that sounds right.  I bet the logs will show that the update is failing because the store branch's tip isn't an ancestor of launchpad's branch's tip.
<bac> abentley: i see you have a card in review but can't find the MP.  is it there?
<abentley> bac: It's this, but why do you ask? https://code.launchpad.net/~abentley/charmworld/separate-qa/+merge/178841
<bac> abentley: b/c i assumed you needed a review
<hazmat> rick_h, mthaddon had it last i asked about an upgrade
<adeuring> abentley: could you take another look at https://code.launchpad.net/~adeuring/charmworld/etag-for-charm-api-view/+merge/178792 ?
<hazmat> rick_h, but its probably in a pool rotation
<bac> abentley: i see you don't.  move your card?
<hazmat> rick_h, rt basically.. the charm you mentioned was published last i looked
<rick_h> hazmat: ah ok cool. Strange one. 
<abentley> bac: Sure.
<abentley> adeuring: sure.
<rick_h> hazmat: https://store.juju.ubuntu.com/charm-info?charms=cs:~pavel-pachkovskij/precise/rack should be r5 
<rick_h> hazmat: so guessing it's not getting processed by the store code because of the strange bzr path. The user hasn't come back on irc so I've not verified he did uncommit and why. 
<abentley> rick_h, hazmat: I'm comfortable asserting that whatever he did looks like an uncommit, and we need to ensure we handle them correctly.
<abentley> adeuring: r=me
<hazmat> i'm poking at the branch to understand it better
<adeuring> abentley: thanks
<hazmat> the store won't look at a charm again till its changed, its doing a fresh checkout when branchtips spells the change for it, there are errors it tracks but their not exposed unfortunately
<hazmat> though they are stored in mongo
<abentley> hazmat: If you do "bzr log -r revid:pavel.pachkovskij@altoros.com-20130301074156-vkto1nnhg3pujiyq lp:~pavel-pachkovskij/charms/precise/rack/trunk" you'll see that the revision is recorded in the branch.  But if you do "bzr log lp:~pavel-pachkovskij/charms/precise/rack/trunk" you'll see that revision isn't part of the branch's current revision history.
<hazmat> abentley, right, but the charm store doesn't care about valid past revid.. still investigating, but in middle of meeting, eta 10m
<abentley> hazmat: In fact, it looks like he started from scratch.
<frankban> hazmat: hey, I need to implement an API version of env.deploy() to be used in the guiserver.  Is there a reason for the GoEnvironemnt.deploy() in the deployer not using the API?  If so, perhaps I will use a subclass. If not, it seems quite easy to me to implement the method.
<hazmat> frankban, yeah.. no local charm support, which is a major use case for deployer
<abentley> hazmat: I don't know if the charm store is doing update or pull, but my guess is it's not doing --overwrite, to ensure it always gets the branch tip even in this sitation.
<hazmat> abentley, its doing a fresh checkout every time
<frankban> hazmat: ack, so I'll just use a subclass for the guiserver
<abentley> hazmat: Then I guess the cause is something to do with the store itself.
<abentley> hazmat: re: "the store won't look a charm again until its changed", new revisions were added today, yesterday, the day before yesterday.
<hazmat> abentley, yeah.. looks its a store issue what exactly i don't know
<hazmat> abentley, incidentally charmworld should be passing in a since last date to getBranchTips
<hazmat> abentley, just verified getBranchTips has the correct/latest output
<abentley> hazmat: How would passing since into getBranchTips help us?
<hazmat> abentley, less processing of redundant data, less load on lp
<hazmat> ie instead of fetching 1k every time, it fetches what's actually changed, so typically 10 a or less day at our current rate.
<abentley> hazmat: I don't think the load on lp to query all branches vs recently-modified branches is significant, and we want to use other means to determine what's redundant.
<hazmat> abentley, yes, we've evolved redundant code, that doesn't make it good, or make fetching only what's changed bad.
<abentley> hazmat: If we made the change naively, it would be bad because it would cause us to falsely mark branches as deleted that were not.  If it were done carefully, it would be more work, and without equivalent benefits, that's bad too.
<abentley> I wasn't talking about redundant code.
<hazmat> abentley, so how does deletion work, its based on presence in the getBranchTips output?
<abentley> hazmat: Yes, we compare the mongodb content with the getBranchTips output, and anything in mongo not in the getBranchTips output is considered deleted.
<hazmat> ic, except its never actually deleted from the store
<adeuring> abentley: can you remember the reason why you removed the parameter http_cache from the .ini file? Adding them again would be a cheap way to add caching again for most of charmworld
<adeuring> (it's r123)
<abentley> adeuring: I believe the problem is that you get over-caching, because it doesn't vary on user.  If you add Vary: cookie, then the Google Analytics cookies break the caching.
<adeuring> abentley: ok. so, adding etags to affected views still makes sense.
<hatch> gary_poster: good afternoon :)
<gary_poster> hey hatch :-)
<gary_poster> hey frankban.  I had a good conversation with noodles about deployer integration.  you probably have thoughts as well.  Maybe we can squeeze in a quick call to coordinate later this afternoon?  maybe half hour or hour from now?
<antdillon> gary_poster, Hi, I have some small tweaks in a branch, want me to do a mp?
<gary_poster> antdillon, would be great.  hatch or Makyo you around to help?
<gary_poster> or anyone in jujugui to help antdillon land the branch?  :-)
<frankban> gary_poster: sounds good. I have a plan now indeed.
<gary_poster> cool thanks frankban 
<hatch> yeah I can land the branch antdillon
<rick_h> gary_poster: I can in a bit. I'm trying to keep my head down today. antdillon can you push it up like yesterday and I'll try to pull/submit it and get it reviewed later on today?
<rick_h> or hatch can have at it 
<abentley> hazmat: right, the branches are marked deleted, the charms are not.
<gary_poster> thank you rick_h or hatch.
<hatch> don't want rick_h to forget any icons or anything this time :P
<rick_h> hatch: :P you better handle it then 
<hatch> lol
<hatch> gary_poster: are you going to continue on with huws branch or would you like me to?
<antdillon> rick_h, Its up, been up a for hours
<antdillon> lp:~ya-bo-ng/juju-gui/inspector-icons
<antdillon> hatch, rick_h Thank you
<hatch> pulling
<hatch> what's this one supposed to be doing?
<antdillon> hatch, Added landscape icons to landscape errors in the inspector and set the width of textareas in the inspector so there is no y-scroll bar
<antdillon> hatch, Small CSS changes
<hatch> cool, did you check in IE?
<antdillon> hatch, Thought you were supporting Chrome and FF?
<hatch> http://cdn.memegenerator.net/instances/400x/19013337.jpg
<antdillon> hatch, Lol IE6
<hatch> haha no
<hatch> antdillon: the icons are missing from beside the unit names in the landscape section
<antdillon>  hatch Is there an easy was to invoke landscape errors?
<hatch> add 100 units and wait a second the simulator will generate them pretty quick
<hatch> or 1000 units
<hatch> it can handle it :)
<antdillon> hatch, Weird, there were there in the local version, might have missed an add. Hang on
<hatch> I'm like jshint for qa - i'll hurt your feelings
<hatch> (if you don't know what jshint/lint is that joke won't make any sense)
<antdillon> hatch, I get it, you sue the icons are'nt there?
<hatch> reloading, clearing cache...all that jaz
<antdillon> hatch, Well icon (inspector-charm-landscape.png) as they both use the same
<hatch> nope, I don't even see a style to apply them
<hatch> style/element
<hatch> forget to save the less file?
<antdillon> hatch, Mmm did you get rev 930?
<antdillon> http://bazaar.launchpad.net/~ya-bo-ng/juju-gui/inspector-icons/revision/930
<hatch> yup 930, the background style isn't being applied....
<hatch> second
<hatch> oh that's right
<hatch> this doesn't have the style set
<hatch> antdillon: look for .status-unit-content
<hatch> it's missing the landscape ones
<antdillon> hatch, Odd there in the diff
<hatch> no it's not
<hatch> unless we are looking at two totally separate branches haha
<hatch> you added two classes both of which are under .status-unit-header
<antdillon> hatch, Here is the changes, is this the branch you are pulling? http://bazaar.launchpad.net/~ya-bo-ng/juju-gui/inspector-icons/revision/930
<hatch> lol does your diff really show new classes under .status-unit-content or are you just messing with me? :)
<antdillon> hatch, Totally does, do you not see them on launchpad?
<hatch> thats so weird
<hatch> they are definitely not there
<hatch> there is only a 10line diff
<hatch> antdillon: https://www.evernote.com/shard/s219/sh/45e433c8-7a8b-426a-afe0-aadbf0ba5f57/78a8e174510f9b91138e1753ece8871b/res/be3c1c1a-2abe-4ab8-9eff-0e0b8232c007/skitch.png
<antdillon> hatch, I'll push a white space change and push again
<antdillon> hatch, They are there, .status-unit-header.landscape-needs-reboot and .status-unit-header.landscape-security-upgrades
<hatch> hatch: antdillon: look for .status-unit-content
<hatch> :)
<hatch> http://bazaar.launchpad.net/~ya-bo-ng/juju-gui/inspector-icons/view/head:/lib/views/juju-inspector.less#L748
<antdillon> hatch, Ah ...
<antdillon> hatch, My bad, sorry doing 3 things at once
<hatch> now u owe me a beer
<hatch> lol
<antdillon> hatch, Yes I do! fix it there
<antdillon> hatch, Sorry about that
<bcsaller> still need one more review on, https://codereview.appspot.com/12323043/ rick_h you looked at this before, maybe you have time to check again?
<hatch> antdillon: haha np
<hatch> make devel
<hatch> ahh crap
<rick_h> bcsaller: sure thing
<bcsaller> thanks
<gary_poster> hatch, devel is made
<hatch> thanks bot gary
<hatch> :)
<gary_poster> :-)
<gary_poster> frankban, you available for guichat for a sec?
<frankban> gary_poster: sure, joining
<teknico> guihelp: today I'm seeing these selenium errors when running functional tests in charm trunk, yesterday they were ok, did anything related change in the gui code recently? http://pastebin.ubuntu.com/5959156/
<antdillon> hatch, Sorry man, 932 is my last touch
<hatch> antdillon:  :) qaing now
<hatch> antdillon: do you have IE10?
<antdillon> hatch, Not on this machine, I'll sign up for browserstack again
<hatch> antdillon: it's ok I'll spin up a vm
<rick_h> bcsaller: did this update then handle the type=checkbox?
<bcsaller> rick_h: no, but afaik that still isn't fixed
<rick_h> bcsaller: ok, so this will have to be revisited and updated once the bug is corrected? And test cases added to help make sure we don't break checkbox suport then?
<bcsaller> yes, but I'm not sure what the UX should even be for checkboxes, "True/False", "Yes/No"?  Maybe the conflict icon alone implies that the other state is selected
<hatch> wasn't it my branch that broke the checkbox support?
<hatch> which was then fixed?
<bcsaller> hatch: was it? I'll check again
<hatch> gary_poster: DD in IE is working today....I'd like to take credit but.....
<rick_h>  bcsaller ok, I'm LGTM'ing but it feels like it's incomplete with known issues hanging around. 
<rick_h> bcsaller: I don't want to keep holding things up.
<hatch> antdillon: looks good thanks
<rick_h> bcsaller: if we need UX guidence maybe we can send an email for now to the -peeps list and get some feedback when the UX folks get back from IoM
<bcsaller> rick_h: yeah
<bcsaller> hatch: I still see an input for debug on mediawiki, with trunk merged
<bcsaller> hatch: still works in ghost though
<hatch> bcsaller: ohh ok, so my branch had it broken in the ghost
<antdillon> hatch, Sorry for messing with ya, testing your link brain. Thanks
<hatch> thanks
<hatch> antdillon: haha np
<antdillon> lint*
<hatch> antdillon: what do you dev on?
<hatch> bcsaller: rick_h we should create a ticket/card to followup about that checkbox issue because that will hold up releasing
<antdillon> hatch, As in OS?
<rick_h> hatch: I thoght there was already a bug and in my review I asked that it get updated to note this code tie-in. 
<hatch> antdillon: yeah
<rick_h> hatch: bcsaller #1207870
<_mup_> Bug #1207870: Boolean values aren't checkboxes on deployed services <juju-gui:Triaged> <https://launchpad.net/bugs/1207870>
<antdillon> hatch, Ubuntu ... of course
<bcsaller> thanks
<gary_poster> hatch, lol, ok, I'll share.  thx
<hatch> antdillon: http://www.modern.ie/en-us/virtualization-tools#downloads this might help ya
<antdillon> hatch, Awesome thanks
<hatch> jujugui looking for a single very quick review for ants branch https://codereview.appspot.com/12602044/patch/1/1002
<benji> hatch: I'll take a look
<benji> hatch: LGTM
<hatch> thanks ben-jai
<hatch> I decided how I want to pronounce abel too with a long a like apple
<hatch> not sure if that's right though :D
<hatch> gary_poster: I'd still lke to leave the DD card and ticket for now, just because it's odd that it works all of a sudden
<hatch> jujugui looking for one more review and QA of https://codereview.appspot.com/12567043/
<Makyo> jujugui call in 10, kanban now
 * hatch thinks Makyo has a macro for that now
<Makyo> Seriously considering it.  Mostly it's just the alerts on my phone :)
<teknico> guihelp: can someone please run the functional tests in charm trunk? "make ftest" they're broken for me: http://pastebin.ubuntu.com/5959156/
<teknico> gary_poster: ^^
<gary_poster> hatch +1
<bac> teknico: running them
<teknico> bac: thank you
<gary_poster> teknico, ack
<Makyo> jujugui call in 2
<hatch> I see the mutany is live and well
<bac> teknico: i got 1 error
<teknico> bac: pastebin?
<hatch> bcsaller: you broke CI ....mohohahahaha
<bcsaller> me?
<hatch> yeah looks like a failure in IE
<hatch> does anyone here use zsh in their terminal?
<rick_h> hatch: yes!!!
<hatch> I figured you would be against it
<hatch> lol
<rick_h> against it? I preach it!
<hatch> WELL THEN!
<rick_h> https://github.com/mitechie/zshrc for my lightning talk material and 'starter' config I hand out :)
<hatch> http://remysharp.com/2013/07/25/my-terminal-setup
<rick_h> not a 2-line prompt fan myself, but ok
<bac> teknico: i'll run again and capture the output.  my problems looked more environmental, the tests didn't start, installation problems.
<hatch> rick_h: I haven't been either but I have found instances where it would be nice
<rick_h> 15pt font?! I only run 10 or less on anything
<hatch> I coudln't read that on my monitor lol
<hatch> my laptop uses 10pt though
<rick_h> I was bummed when I moved from 8pt to 10pt :/
<hatch> I think my desktop is 14ish
<hatch> lemme see
<rick_h> desktop is 10, laptop is 8
<hatch> oh I lied
<hatch> it's 12pt
<hatch> laptop 10, desktop 12
<rick_h> anyway, zsh ftw. Pipe aliases, better vim mode, and rm **/*.pyc ftw
<hatch> when I work in git it shows me the branch and status in my PS1
<rick_h> yea, does that in bzr, git, hg
<hatch> but it gets pretty long
<hatch> so that's why I was entertaining the idea of a 2 liner
<rick_h> I go short. I just use branch name
<rick_h> I don't need to know how many changes/etc
<hatch> do you display the full path name in it?
<rick_h> no, only the last directory
<hatch> ohh ok I show the full path
<rick_h> [fix-zoom-sprite:929//juju-gui I ] for instance from last night. [branch:revno//dirname insert_mode ]
<hatch> ahh that's nice
<hatch> some people claim zsh is slow
<hatch> I didn't buy it
<rick_h> so the only perf issue is across nfs shares for some reason
<rick_h> and if you run custom functions that are slow. 
<hatch> bcsaller: lemme know when you wana have that chat
<rick_h> but it's dead simple to write your own completion functions which is nice
<hatch> ahh yeah
<hatch> nfs shares are slow period, I just ssh into now haha
<hatch> and use rsync
<rick_h> zsh tab complete wins all
<bcsaller> hatch: after the next call I can look into it with you
<hatch> I've been trying to go more and more terminal based but on the IDE front Webstorm is looking pretty good
<hatch> gary_poster: do we have the call in 8mins?
<gary_poster> hatch yes
<gary_poster> sinzui, the jujucharm redirects appear to all be gone :-(
 * Makyo looks over rick_h's zsh stuff.  The extension aliases are cool; currently has 'alias jfdi="xdg-open"' for some of that.
<rick_h> Makyo: yea I mainly <3 the pipe aliases. cat file.txt G word
<rick_h> or cat file.txt L
<rick_h> autopushd, better history sync
 * sinzui asks webops
<Makyo> Yeah!
<abentley> benji: So, the apache2 charm's JSON is 15K or 3K gzipped.
<benji> abentley: interesting
<sinzui> gary_poster, recheck and confirm?
<sinzui> Before I could complete my request It appears that have started working for me
<gary_poster> sinzui, https://jujucharms.com/charms/precise/wordpress-HEAD/ not working for me
<sinzui> it was definitely broken a few minutes for me
<sinzui> the short works, the long does not
<sinzui> I wonder if the redirect rules were reverted with the charm release
<Makyo> jcsackett, is there a rv link for your branch?
<sinzui> gary_poster, does https://jujucharms.com/charms/precise/wordpress
<sinzui> work
<Makyo> May have lost it in scrollback.
<gary_poster> sinzui, yes.  
<sinzui> https://jujucharms.com/charms/precise/juju-gui just worked for me too
<sinzui> Nice looking page too
<bcsaller> hatch: you want to do that call now/soon?
<hatch> yeah now is good
<hatch> back in guichat
<frankban> bcsaller: I am not sure I will be able to submit the last MinUnits branch today. Anyway, here is the new API call signature: http://pastebin.ubuntu.com/5959504/ . I expect that to land tomorrow.
<bcsaller> frankban: thank you 
<frankban> bcsaller: mp, here is a python script I used to test the functionality: http://pastebin.ubuntu.com/5959514/
<sinzui> gary_poster, the rule to redirect was for the long URL to the short URL. eg, /charms/ is dropped the from the url if it exists and the charm does not have a version. The example URL you have contains old-style  roots and the version hack to satisfy the GUI. That URL only exists if someone URL hacks
<rick_h> yay, my sprint t-shirts arrived! just in time for me to wear them over this Google Chrome dust-up!
<rick_h> thanks jcsackett :)
<abentley> benji: I'm up for more chat if you are.
<benji> abentley: I'm about half way through lunch so I'll ping you in 30
<abentley> benji: Cool.
<jcsackett> Makyo: sorry, no, i never posted. and was out to lunch. :-P https://codereview.appspot.com/12608043/
<hatch> bcsaller: in these tests 'this.ws' in python.js should be conn (new utils.socketstub) right?
<hatch> looks that way
<bcsaller> hatch: I believe so, I always have to check that as well 
<hatch> it's like one of those roads which changes names as you drive down it
<hatch> :)
<hatch> I forgot env.connect()
<benji> abentley: guichat is open
<benji> abentley: this illustrates how I was suggesting using itertools.groupby: http://paste.ubuntu.com/5959750/
<abentley> benji: The other place "featured" is used is the page where you can set it for a charm.  I forgot to mention that.
<benji> ok, that should be easy to deal with
 * Makyo zooms to coffee shop to give dogs alonetime.
<hatch> sooo hows everyones afternoon
<hatch> jujugui looking for two quick reviews on https://codereview.appspot.com/12623043/ plz and thx
<jcsackett> hatch: sure.
<hatch> thanks
<hatch> added to board
<hatch> anyone else......onee more for the points?
<hatch> jcsackett: did you need another review on your branch? I see only Makyo on the tag
<jcsackett> hatch: rick got it as well; i've just not been able to lbox it away yet. :-)
<hatch> ok added him to the board
<hatch> sauce labs videos are broken?
<hatch> boo urns
<hatch> bcsaller: the CI is failing because the two Inspector Conflict UX tests are timing out
<hatch> would you like me to investigate or do you want it?
<hatch> ahh it doesn't appear valueChange is firing
<hatch> I seem to remember writing about that somewhere
<hatch> bcsaller: probably related https://github.com/yui/yui3/issues/489 and my workaround http://jsbin.com/azohuq/2/edit I'll see if this solves the issue here as well
<bcsaller> fun stuff :(
<hatch> although we are running an old version of YUI
<hatch> where this might be resolved...
<hatch> I'll try upgrading that
<hatch> ok who wants to bet this will 'just work'
<hatch> any takers? ;)
<bcsaller> it should work
<hatch> holy smokes
<hatch> no errors
<hatch> with the exception of the 'expose bug' that was already there
<hatch> one test failure
<hatch> hmm except the test action works fine in the real world
<abentley> benji: I've had more thoughts about versioning and elasticsearch.  Do you have a minute to chat?
<benji> abentley: sure, guichat is open
<Makyo> jujugui can I get a quick gut-check on the direction I'm heading with deltas in go-sandbox?  Just want to make sure I'm not totally nuts.  WIP, not a real review.  https://codereview.appspot.com/12596044/diff/1/app/store/env/sandbox.js
<bcsaller> Makyo: looking
<Makyo> bcsaller, thanks
<bcsaller> Makyo: how did we end up with 'currentNextRequestId', funny name :)
<Makyo> bcsaller, haha, yeah.  It's the current RequestId for the Next RPC call.
<bcsaller> Makyo: yeah, it could be nextRequestId though, or currentRequestId, or something, its the both that got me
<Makyo> bcsaller, Yeah, that's fine
<bcsaller> Makyo: the code for sendDelta and all that looks about the same, shouldn't that be moved to a common prototype rather than duplicated or am I reading the diff wrong?
<bcsaller> the delta interval handling, etc, looks like they have more in common than not. I expect up to the perform_xxx methods they are more alike than different
<Makyo> bcsaller, The delta object is different, but much of it can be moved out, I think, so long as the correct _getDeltaAttrs  object is called and it builds the correct data.
<Makyo> so much of that can be abstracted.
<bcsaller> that sounds good
<Makyo> sendDelta should be just building a list of deltas, the internals of which are determined from getDeltaAttrs.
<bcsaller> looks like getDeltaAttrs is even the same, just driven off a different table
<hatch> bcsaller: when you're done with Makyo I'd like to pick your brain a sec about these keybindings
<bcsaller> but to answer your main question, with more code reuse, yes, this looks good. I expect the structural differences are minimal, only the wire data (and the fact that GoJu needs an additional stream) seem to change. I like that
<Makyo> bcsaller, cool, thanks. 
<bcsaller> hatch: yeah, did you want to chat?
<hatch> yeah real quick hangout....umm lemme fire one up
<bcsaller> yeah, saw it was full
<hatch> ring ring
<hatch> bcsaller: what the..... https://github.com/yui/yui3/blob/v3.9.1/src/transition/js/transition-native.js
<hatch> it's identical
<hatch> so I have no idea how this worked in the first place....
<hatch> bcsaller: unfortunately the simulate bug is not fixed in YUI 3.11 :(
<hatch> I'ma propose this update anyways
<bcsaller> better to have than not
<hatch> jujugui update to yui 3.11 https://codereview.appspot.com/12627043 looking for two thorough QA's plz
<hatch> also looking for one more review here https://codereview.appspot.com/12623043/
<hatch> good evening gary_poster
<hatch> jcsackett: you around?
<jcsackett> for various definitions of around.
<hatch> Unable to obtain lock  held by jcsackett@bazaar.launchpad.net on taotie (process #13696), acquired 13 seconds ago.
<_mup_> Bug #13696: White border appears around kwifimanager system tray icon <kdenetwork (Ubuntu):Fix Released by kubuntu-members> <https://launchpad.net/bugs/13696>
<hatch> when I tried to merge
<hatch> er submit
<jcsackett> hatch: huh.
<hatch> yeah right?
<jcsackett> my submit finished; there shouldn't be a lock.
<hatch> I'll try again
<jcsackett> hatch: you can also bzr break-lock
<hatch> is it safe to do that? heh
<jcsackett> it should be; i can't think of any reason i would have a lock.
<jcsackett> hatch: i have no pending bzr operations running.
<jcsackett> 13 seconds feels suspect...
<hatch> well I'll see what happens
<hatch> this time
<hatch> but as long as you aren't running anything then I'll break the lock if it happens again
<jcsackett> ok..
<jcsackett> i'll postpone my EoD a bit out of curiosity.
<hatch> sorry my lboxing is slow
<hatch> :)
<hatch> jcsackett: all good now
<jcsackett> hatch: good stuff.
<hatch> enjoy your eod
<hatch> :)
<jcsackett> later. :-)
<hatch> bcsaller: will you approve     if (Y.UA.ie === 10) { done(); } to get CI passing agin for your tests?
<hatch> else simulate will need to be properly patched....which looks like a lot of work for the valuechange event
<hatch> I also need to do it to get the ghost test that relies on the valuechange event to work
<gary_poster> hey hatch, could you help Huw out with a re-review of https://codereview.appspot.com/12506044/ ?
<hatch> on it
<gary_poster> jujugui (Makyo, bcsaller?) could one of you review Francesco's charm branch please?  https://codereview.appspot.com/12612043/
<gary_poster> Nicola can provide the other one tomorrow morning
<gary_poster> Thanks, hatch!
<hatch> gary_poster: if you're looking for some late night testing fun you could QA this branch :) https://codereview.appspot.com/12627043/
<gary_poster> hatch, I saw that, awesome!  I would like to, but about to have a call with fam now before bed.  Just worked through 300-some-odd emails :-P
<hatch> haha, it's ok it requires a pretty deep QA :)
<gary_poster> I figured :-)
<hatch> I also have a really huge hack to get CI back up and running if (Y.UA.ie === 10) { done(); } :/
<hatch> https://github.com/yui/yui3/issues/489
<hatch> unfortunately the workaround doesn't work for the 'special' valuechange event :/
<gary_poster> hatch, ugh.  So...ugh. You'd just disable the one test?
<hatch> 3 tests
<gary_poster> :-/
<hatch> I looked at the yui simulate code and it looks like it'll be a large amount of work
<gary_poster> ack hatch.  did you at least file it additionally?  issue 489 doesn't mention valuechange
<gary_poster> hatch, fwiw under circumstances I am OK with it
<hatch> I haven't - I'll file another once I have some free time to make a repro
<hatch> 5mo old and still no fix though....that's not very nice
<gary_poster> :-/
<hatch> gary_poster: reviewed and qa'd huws branch found one qa issue that can probably be pushed
 * Makyo runs home, will look at charm branch there.
<hatch> cya Makyo
<huwshimi> Morning
<hatch> morning huwshimi
<gary_poster> hey huwshimi.  I'm about to go to bed.  Look forward to talking to you later today.  Does my comment about the side panel make sense?
<huwshimi> gary_poster: Hey, was just replying :)
<huwshimi> gary_poster: "Inspector charm details must be the same size as the inspector panel. (think drawer)"
<huwshimi> gary_poster: I thought that comment meant they should always be the same height?
<huwshimi> (A drawer is never bigger than the chest it is in)
<gary_poster> huwshimi, it sounds like my brain wrote down what I secretly thought and not what Luca and Jaime actually told me ;-) sorry!!  is it a quick fix?
<huwshimi> gary_poster: I can just revert my change. You want the side panel to be a fixed height (full height of the page)?
<huwshimi> page/screen
<hatch> huwshimi: haven't you ever seen that movie where the kids go into the closet and go into a new world?
<hatch> he meant that kinda drawer :D
<huwshimi> :)
<hatch> narnia
<hatch> that's the one
<hatch> jujugui could I get a quick review to get CI back up and running https://codereview.appspot.com/12620044
<bcsaller> checking
<hatch> thanks
#juju-gui 2013-08-08
<hatch> ok well past EOD
<hatch> cya in the am
<hatch> friggen CI failures
<rick_h> valuechange sucks for CI
<hatch> well IE passed but now FF is failing on two different tests
<hatch> well ok not two totally different
<hatch> but different none the less
<hatch> some which shouldn't have even been changed...
<hatch> like the textarea autosize plugin??
<hatch> wth
<rick_h> timing sensitive based since it's based on valuechange
<rick_h> remember when we were tinkering with the 50ms poll time?
<hatch> remember when I jsut deleted the tests from VC history like they never existed....
<hatch> oh I wish
<rick_h> lol
<hatch> bzr branch trunk friggen-damn-ci-failures
<hatch> umm what
<hatch> TypeError: can't convert undefined to object
<hatch> bcsaller: still around?
<bcsaller> hatch: yes
<hatch> so in inspector.js you had created a wrapper for handlers.push called watch
<hatch> yeah....firefox didn't like that...
<hatch> lol wth
<bcsaller> hatch: is watch a reserved word in 'future js'?
<hatch> negative
<hatch> I'll try and create a repro
<bcsaller> I guess that is the type of thing CI should catch, but why would we expect that to fail
<hatch> see if it's something else in our code
<hatch> or FF just being wako
<bcsaller> that was just an alias IIRC, I guess just call the push directly when its used
<hatch> yup that's what I did
<hatch> yeah it was just an alias
<hatch> probably to save chars
<hatch> bcsaller: http://jsbin.com/ipehec/1/edit
<hatch> updating FF to see if it fixes it
<hatch> nope 23 does the same
<bcsaller> handlers.push is fine
<bcsaller> not sure that even works in chrome
<bcsaller> console.log(handlers)
<bcsaller> hatch: ^
<hatch> whatabout it?
<bcsaller> its empty in the jsbin
<hatch> right
<hatch> console.dir(handlers)
<hatch> shows you the prototype
<hatch> you can't alias any protoype methods on an array in FF
<hatch> http://jsbin.com/ipehec/2/edit
<bcsaller> not working in chrome for me either, I think it was failing silently 
<hatch> odly enough it works just fine with objects
<hatch> http://jsbin.com/ipehec/4/edit
<hatch> interesting
<hatch> ignore the comments
<hatch> i just forgot to remove them
<bcsaller> the sad part is I didn't really need the alias 
<hatch> haha right
<hatch> that's some interesting stuffs
<bcsaller> handlers.push it is
<hatch> yup
<hatch> I've already got it fixed and proposing
<hatch> wana give it a review once it's done so I can get it in tonight? :)
<hatch> probably be a few minutes before lbox is done
<hatch> bcsaller: https://codereview.appspot.com/12640043
<bcsaller> hatch: LGTM, thanks
<hatch> great thanks
<hatch> CI back to normal....awww yeahh
<rick_h> hah
<hatch> huwshimi: you around?
<huwshimi> hatch: Yeah, I was, sorry I missed your message. Guessing you're gone now?
<gary_poster> hey frankban. :-) good news: we do not need to support pyjuju for bundles.
<teknico> gary_poster: good news indeed :-)
<gary_poster> teknico, :-) .  Also, mramm expects that we can stop supporting pyjuju at 13.10
<gary_poster> but that's not official yet
<teknico> mourning its untimely demise already ;-)
<gary_poster> :-)
<frankban> gary_poster: great! so, IIUC, we don't need to add a pyAPIenv to the deployer, correct?
<adeuring> abentley: could you please have a look here: https://code.launchpad.net/~adeuring/charmworld/1204899-report-json-value-error/+merge/179181 ?
<abentley> adeuring: sure.
<abentley> adeuring: Are you planning to update the staging revno so that you can QA your previous branch?
<adeuring> abentley: can you helpme to set up the juju environment?
<abentley> adeuring: Okay, how can I help?
<adeuring> abentley: for a start: what do I need to put into environments.yaml?
<abentley> adeuring: You should have a mail from me called "Accessing staging".  That has the environments.yaml that you need.
<adeuring> abentley: ah, thanks, need to look again...
<hatch> jujugui looking for 2 more reviews/qa's on this branch https://codereview.appspot.com/12627043/
<benji> hatch: looking
<hatch> thanks!
<hatch> it'll need a deep qa
<hatch> in fact I'll merge trunk into it again
<hatch> proposing with the newest trunk merged in now
<abentley> adeuring: Is it possible for start_date or end_date to be bogus?  If so, what happens?
<adeuring> abentley: that should be set by our code. The worst I can imagine is that the end date is in the past..
<abentley> adeuring: What if the start date is after all the subsequent dates?
<adeuring> abentley: without looking too close, I'd say that we get an empty report. but let me check...
<hatch> benji: updated
<benji> k
<adeuring> abentley: yes, we get an empty report. Basically, it boils down to a call of range(-3) or similar to generate the "buckets"
<abentley> adeuring: However, IIUC, the start_date and end_date is typically not supplied, so we should get a range of 2011/05/1 to now.
<adeuring> abentley: right, and that looks reasonable
<abentley> adeuring: I thought it might come from user-supplied data, in which case we'd need another bug report.
<benji> hatch: the code changes look fine, doing QA now
<abentley> adeuring: r=me.
<adeuring> abentley: thanks
<rick_h> jujugui review time. qa instructions are included. ï»¿ï»¿https://codereview.appspot.com/12621043
<rick_h> hatch: I'll peek. 
<hatch> thanks
<hatch> I'd really like to get it landed asap
<hatch> so we can start working with the new yui finally
<rick_h> ugh, I get nervous when shrinkwrap updates things
<hatch> rick_h: you can thank module authors for not locking down their dependencies for that :/
<gary_poster> jujugui, we can stop supporting pyjuju as soon as we stop testing it in CI :-)
<hatch> for reals?
<hatch> wow!
<frankban> gary_poster: let's fix CI! ;-)
<hatch> oh c'mon I just got it working again last night
<hatch> lol
<frankban> heh
<gary_poster> hatch, for IE 10 drag target bug, sinzui suggested making the "drag a charm here" thing in the middle disappear when you start a drag
<gary_poster> I like that
<hatch> gary_poster: yeah - I was also going to look into why it's not a drop target
<hatch> also, are you ok with the odd drag proxy?
<hatch> it may not be supported in IE10 like in chrome
<frankban> bcsaller: ServiceUpdate is in juju-core trunk
<gary_poster> hatch, yes
<gary_poster> frankban, did you see me (try to) tell you that you don't need to support pyjuju in deployer at all?
<frankban> gary_poster: yes, a good news
<gary_poster> cool frankban 
<rick_h> hatch: the confirm button in the service inspector (after editing a config setting) isn't working? known issue?
<rick_h> hatch: also saw the expose button one, but you said that was expected. 
<hatch> rick_h: yeah I think it was introduced by huws branch
<hatch> I made a comment in his review but he must have left it
<rick_h> hatch: hmm, yea neither cancel/confirm work
<hatch> https://codereview.appspot.com/12506044/#msg8
<rick_h> hatch: ok, but sounds like we don't have a card/anyone on it then? Should I add a card to inspector?
<hatch> rick_h: I'll create a ticket and a card
<rick_h> hatch: cool thanks
<hatch> qaing your branch now
<rick_h> hatch: thanks
<hatch> rick_h: I see the options requests are still slow :)
<adeuring> abentley: I'm getting the error "exceptions.ValueError: Missing config 'username', 'password', 'project-name' required for userpass auth
<rick_h> hatch: yes, bug is still out on that
<abentley> adeuring: It sounds like you might not have sourced the openstack config-- the novarc in the credentials I gave you.
<adeuring> abentley: maybe. When did you send it?
<benji> hatch: sorry, unity crash caused me to delay my QA a bit; still looking
 * hatch thinks benji needs new hardwares
<hatch> :)
<rick_h> says the man that needs new hardwares...
<abentley> adeuring: I believe I gave you the openstack credentials on a USB stick at the Oakland sprint, but I can mail them to you now.
<hatch> rick_h: hey mine doesn't crash :D
<hatch> it's just slow lol
<adeuring> abentley: OK, THANKS
<benji> unfortunately I think my issues (computer-wise at least) are all software-induced
<abentley> adeuring: Please associate GPG keys with your canonical acccount.
<frankban> gary_poster: IIRC, we try to avoid installing packages from pypi in the charm, correct?
<gary_poster> frankban, y
<frankban> gary_poster: ok thanks
<hatch> yui 3.11 being merged in to trunk
<hatch> jujugui ^
<adeuring> abentley: ? There is a key associated with my LP account. What do you mean?
<benji> is that Canadian for "hold onto your butts"?
<hatch> lol
<hatch> gary_poster: on the IE DD task now
<gary_poster> hatch, cool thx
<hatch> gary_poster: also curtis's branch is hanging out in maintenance review - could you ask him next time you see him what's up with it?
<rick_h> hatch: where's "above the click handlers" that you wanted a comment? 
<abentley> adeuring: Not your lp account.  Your canonical email account, abel.deuring@canonical.com.  It needs to be listed on your GPG key so that programs can pick that key automatically when sending mail to that account.  Right now, only your gmx.net and satzbau-gmbh.de accounts are listed.
<hatch> rick_h: well I'm assuming the a's had another click handler on them else where would they link to?
<rick_h> hatch: well, it's in the Y.Views and such. 
<hatch> ohh right pjax garbage
<adeuring> abentley: ah, right, I'll do it
<rick_h> hatch: and this is only overriding this in the context of the widgets in the autocomplete results
<rick_h> hatch: huh? pjax garbage? no, it's Views listening to events from widgets 
<gary_poster> hatch, benji said he approved it if he added a test for the nagios external master script.  Neither he nor anyone in webops knows how to write that test.
<hatch> oh haha ok, what should we do with the card? :)
 * benji looks at it.
<hatch> rick_h: so there is a view which is navigating on clicking those a's?
<rick_h> hatch: the charm-token widget is used EVERYWHERE so some places watch for that click to open the charm details/etc
<rick_h> hatch: in this view, clicking on the charm triggers teh autocomplete selection event and we don't want to do anything else with it
<rick_h> hatch: the tokens render with a <a> and a link in there. We just have to kill that for autocomplete to work. 
<hatch> ok I gota pop this open again
<hatch> one sec
<benji> gary_poster/hatch: they either misunderstood my request or have suffered a collective brain aneurysm.  The test is not of the script but of the endpoint the script gets as a liveness test. I.e., it would asssure that the URL the script hits stays there and continues to contain the text that the script expects.
<gary_poster> benji, cool thanks, sinzui says he can do that!
<hatch> rick_h: ohh now I see, it has a path in the href
<rick_h> hatch: right
<rick_h> hatch: so we're killing that, that's all
<hatch> could that be removed in favour of the charmid ?
<hatch> (not in this branch)
<Makyo> jujugui emergency vet trip in a few, but will bring laptop.  Still aiming to land the go-sandbox-deltas branch today
<hatch> uh oh! Hope puppy is ok
<rick_h> hatch: then we get into special casing, adding css for acting like a hover/clickable, etc
<BradCrittenden> Makyo: good luck
<Makyo> Conjunctivitis, nothing too bad, but sure is gross :P
<benji> heh
<rick_h> hatch: I don't think killing link clicks in a specific case is bad. 
<hatch> no but it's impossible to find out where it's being blocked if you want it to
<hatch> that's what my comment was about
<rick_h> but we don't want to. How in the world would an autocomplete option have an <a> you want to follow?
<rick_h> I'm missing how this causes any grief for later on trying to figure out "why is my click blocked"?
<sinzui> benji, gunoy deployed your changes. Do they looks good?
<benji> sinzui: cool!  looking
<benji> Cache-Control: max-age=0, public, must-revalidate
<benji> perfect
<benji> gary_poster: ^
<hatch> we probably wouldn't want to follow an a in an autocomplete (at least in this case)
<rick_h> hatch: I've updated the comment to call out the <a> part to help
<hatch> but prevented events in the middle of a script aren't clear when you're stepping through the code trying to find out wth is going on
<rick_h> hatch: but I want to keep the same css, :hover, dom structure as other charm tokens and would prefer to not tweak the template on it. 
<rick_h> hatch: understand. 
<hatch> so that's why I was commenting about putting a note on the real listener
<hatch> s
<hatch> but those don't exist
<hatch> heh
<rick_h> and been there done that
<rick_h> hatch: trust me, it took me a bit yesterday to figure out why things kept navigating :)
<hatch> ugh anchors!!
<hatch> semantic this!!
<rick_h> hah
<hatch> I still think the search is broken
<rick_h> stop calling it search
<rick_h> then it'll stop being broken
<rick_h> :P
<rick_h> it's not search
<hatch> then don't have a description that says 'Search for charms'
<hatch> :P
<rick_h> and when you complete your search it works just like you expect
<hatch> 'Autocomplete charm name here'
<sinzui> benji, The release was delayed because the stable branch diverged when the developer branch was merged. r69 was replaced with an identical but different revision and bzr choked.
<hatch> sorry you aren't going to convince me this time :)
<benji> sinzui: yes, yes... I understand some of those words
<rick_h> hatch: that's ok. It's good to be completely wrong somtimes and carry that with a badge of honor on your chest :)
<hatch> rick_h: http://yuilibrary.com/yui/docs/autocomplete/ look at the example image even!
<hatch> this is even used on Yahoo's own homepage!
<rick_h> hatch: and they do evvvvverything right :P
<sinzui> We need to think about the process to ensure we merge into stable, not replace stable. Your weren't  involved in the mixup BTW. It just happened and it block your request
 * hatch can't wait for the first public bug that the search is broken
<hatch> rick_h: ok I'm a little confused by your response about the empty left column
<rick_h> hatch: k
<hatch> I type ceph into the input
<hatch> hit enter
<hatch> it clears out the left column
<rick_h> hatch: you've done a search now
<rick_h> for the term "ceph"
<rick_h> it's showing you the search results
<hatch> oh man even I'm confused about this interaction, so it's a dual purpose input?
<hatch> it autocompletes from the start of a string and acts as a search box?
<rick_h> no, it's a search input. 
<rick_h> it's always been a search box
<rick_h> you've just autocompleted a search term for the user
<rick_h> this is why autocomplete != search
<hatch> but you haven't because if I click that it opens the charm not fills in the input
<rick_h> if I use google autocomplete on their search box "hatch is" it gives me suggestions, and then when I select one it does that search for me
<rick_h> hatch: second, need more details then. It should fill in the input, do a search, and show you the details 
<rick_h> hatch: it's search autocomplete
<hatch> ohhh NOW i see
<hatch> there is a bug in here somewhere
<rick_h> ok, I'm willing to admit there might be :/
<hatch> it was causing the sidebar to be emptied and then just showed the charm
<hatch> like....empty as in nothing in it
<rick_h> yea, that shouldn't happen 
<hatch> ok now how did I get it to do that
<hatch> man that was confusing for both of us there lol
<hatch> you thought I was an idiot, I thought you had gone crazy
<hatch> haha
<rick_h> "doctor it hurts when I do this." "stop doing that"
<teknico> and you both were right! ;-)
<hatch> lol!!!
<hatch> rick_h: ok I don't know what's up here but probably 20% of the time it has an empty sidebar ..... ugh worst bugs ever
<rick_h> hatch: ok, working on other parts of your review now. I'll peek at it in a sec
<rick_h> hatch: watch the network tab in the debugger and see if the search call is going out/has response
<hatch> yeah now I can't get it to do it at all
<adeuring> abentley: new problem:; "File "/usr/lib/python2.7/dist-packages/juju/providers/common/connect.py", line 43, in run
<adeuring>     client = yield self._internal_connect(share)
<adeuring> Error: [('PEM routines', 'PEM_read_bio', 'no start line')]"
<hatch> at least when it's working it makes sense :P
<abentley> adeuring: My guess is the paths to the included PEM files are wrong.  You should extract the contents of orangesquad.zip to a single directory and source the script from there.
<abentley> adeuring: No, wait...
<abentley> adeuring: Yes, look into the PEM file paths.
<adeuring> abentley: yeah, thanks!"
<adeuring> abentley: did not help; the files which the env vars point to exists...
<abentley> adeuring: Do the sha1 sums match? http://pastebin.ubuntu.com/5962937/
<adeuring> abentley: yes
<hatch> jujugui call in 10 kanban now
<abentley> adeuring: That's very weird.  I don't know what to suggest.  I don't know how it could claim those files have no start line.
<abentley> I've only seen that when the path was wrong.
 * Makyo returns.
<adeuring> abentley: sooo... could you update staging for me?
<abentley> adeuring: Sure.  What revno?
<adeuring> abentley: 339 please
<rick_h> hatch: updates to the other issues uploading now. If you can dupe please let me know and I'll try to fix. I'm working on trying to dupe it now.
<hatch> rick_h: ok after call
<rick_h> hatch: rgr
<abentley> adeuring: config changed.  Should be updated in a minute.
<hatch> jujugui guichat in 2
<adeuring> tahnks
<hatch> rick_h: \o/
<rick_h> hatch: yea, autocomplete/click a category, then go and autocomplete a charm not in that category
<rick_h> hatch: and you end up with empty results because the search for that charm name + category (from earlier) has no results
<abentley> hatch: are jujugui and guichat the same thing?
<Makyo> abentley, yes, but jujugui pings in irc.
<rick_h> abentley: yes, just that the second one doesn't ping the channel so easier for others not using it
<bac> but when you use both in the same message it is moot
<rick_h> lol
<hatch> abentley: there are jujugui and guihelp which ping the whole channel (if you set it up in your configs) and we changed to using guichat to reference the guichat boardroom so we woudln't ding everyone with it's old name (jujugui)
<Makyo> And now you have three pings \o/
<rick_h> will someone please smack him?
<hatch> rick_h: CHOO CHOOO
<Makyo> Ffffff
<hatch> rofl
<hatch> rick_h: lgtm'd
<rick_h> hatch: thanks
<hatch> I'm really glad you were able to dupe the bug haha
<rick_h> yea, better to catch it now while my head is in the code
<hatch> that was a pretty obscure one too
<hatch> rick_h: this was me trying to repro that error http://nodejsreactions.tumblr.com/post/57620383823/var-result-fs-readfile-data-json-function
<rick_h> lmao, that's awesome
<rick_h> man, I can leave that running all day
<hatch> haha yeah I laughed
<rick_h> hatch: ok, bug fix upload fyi
<hatch> heh such a easy fix
<Makyo> gary_poster, ping for docs/vids meeting?
<hatch> he forgot about us :'(
<Makyo> gary_poster, we ducked out, ping if it's moved.
<hatch> man native drag and drop is needlessly complex
<gary_poster> jujugui, Makyo, hatch, sorry.  Was suddenly called into meeting with Mark.  I'm exhausted so that's ok that we will not be calling. :-P  Lots more to talk about...our schedule will be changing more. :-)  CLI work is huge.  Will give more details soon.
<hatch> no problem :)
<hatch> right now I'm trying to decide if I hate virtualbox or windows 8
<hatch> one is buggy
<hatch> haha
<gary_poster> heh
<hatch> [object Object] THANKS IE!
<rick_h> go IE go!
<rick_h> isn't IE12 out yet to make dev work not suck? 
<hatch> with all the praise IE11 is getting you know it's gona suck somehow
<hatch> it's the same hype they had with IE10
<hatch> I actually got IE to drop on that empty canvas element
<hatch> but only by causing a type error
<hatch> lol
<gary_poster> teknico, ping?
<rick_h> thanks for the review bcsaller 
<bcsaller> np
<hatch> why does the media wiki icon always take way longer to load? :)
<rick_h> gary_poster: landing updated autocomplete now. Would love to get UX to look at if it's passible enough to un-feature flag it while we tweak the ui a little bit more. 
<rick_h> since people love it so much, let em have it :)
<gary_poster> rick_h, cool, let me know when it is on comingsoon and I'll call 'em over.  will that be good, or do you want me to merge?
<rick_h> gary_poster: yea, I'll let you know
<gary_poster> cool
<rick_h> go my little lboxes go!
<gary_poster> rick_h, if you could prep me with answers to "why does this not look like UX?"
<gary_poster> that would probably help the conversation along ;-)
<rick_h> gary_poster: sure thing, basically 'it's not in a google doc and rick couldn't find the place the mockup was at'
<gary_poster> heh
<rick_h> gary_poster: that + 'rick hasn't figured out how to do a seperator cleanly
<rick_h> should sum it up
<gary_poster> ok
<gary_poster> rick_h, heh :-) cool
<hatch> *sigh*
<Makyo> We can switch to this: http://tinysubversions.com/gaunt/
<hatch> lol
<frankban> Makyo: that should work beautifully as a template engine for whitespace: http://compsoc.dur.ac.uk/whitespace/
<Makyo> frankban, Hah: https://twitter.com/tinysubversions/status/365478093630095360
<frankban> heh
<hatch> lol!
<hatch> bcsaller: is the drap/drop import script supposed to support IE10?
<bcsaller> hatch: uhh sure, I guess. I don't remember if that was verified as that feature was never officially published
<bcsaller> hatch: I'm going to be changing the import stuff to be deployer format files in the next day or so if all goes well
<bcsaller> but that was my only plan there, at that point though I think it will be a 'real' feature 
<hatch> ok because IE10 doesn't support custom strings in getData()
<hatch> and that's causing other stuff to fall over
<hatch> var dataType = evt._event.dataTransfer.getData('dataType');
<hatch> so that needs to be 'Text'
<hatch> but then I think that'll break the actual functionality in modern browsers?
<hatch> ya know what though...it might not matter
<hatch> getting D&D to work with multiple drop targets in IE breaks it in chrome
<hatch> ooo I got it dropping now in chrome and ie
<hatch> now ff?
<rick_h> you wish!
<hatch> hey I didn't say the drop worked....just that it's actually 'dropping' lol
<hatch> but you are correct
<hatch> it doesn't work in FF at all
<hatch> oh wait
<hatch> it never did work in FF here
 * hatch switched to other FF
<hatch> yusss
<hatch> errors in all 3 browsers
<rick_h> hah, you broke them all now?
<hatch> yup!
<hatch> DD WORKS IN ALL 3 DD WORKS IN ALL 3!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
<hatch> it took 3 hours and probably broke every test we have but its working!
<rick_h> lies!
<hatch> well I'm going to take this time to review bc's branch
<hatch> bcsaller
<hatch> autocomplete fail
<hatch> bcsaller: .... slice = [].slice does that actually work? ;)
<bcsaller> hatch: with call it gets context
<bcsaller> or apply
<abentley> bac: Do you have a minute to hang out?  I'd like to make sure we're not treading on each others' feet.
<bac> hi abentley, yes i was just about to ask you the same
<abentley> bac: guichat open.
<hatch> bcsaller: I was referencing the FF issues of yesterday
<hatch> :)
<bac> abentley: i just saw you then you disappeared!
<hatch> rick_h: https://plus.google.com/u/0/109440437666972345229/posts/SN6PnrYV3d6
<hatch> man I'm so pumped DD works in all 3 browsers now
<rick_h> guihelp anyone a master of :nth css fun?
<hatch> rick_h:  http://fromanegg.com/post/57464448123/css-selectors-the-next-level ;)
<rick_h> k, hatch volunteers to help
<rick_h> yay hatch 
<rick_h> I really want a :last-with-class :/
<rick_h> hatch: got a sec for guichat?
<hatch> rick_h: nth-last-of-type
<hatch> sure
<hatch> guichat is busy
<rick_h> hatch: k, invite otw
 * hatch lunching
<abentley> bac: Could you please review https://code.launchpad.net/~abentley/charmworld/separate-text-queries/+merge/179261 ?
<bac> abentley: sure
<bac> abentley: r=me
<abentley> bac: Should land in 5 minutes.
<abentley> bac: Delayed due to testing of https://codereview.appspot.com/12634045
<benji> abentley: I'm struggling to understand why UpdateCharmJob.run() has this line of code payload['_id'] = payload['branch_spec']
<benji> I would have expected the _id to be consistent with (if not actually use) construct_charm_id()
<abentley> benji: construct_charm_id would cause the charm id to include the revision.  That's the plan, but we're not there yet.
<benji> hmm
<benji> abentley: so... construct_charm_id doesn't actually construct an ID for a charm?
<abentley> benji: It will.  I landed it first because other branches needed it.
<benji> I'll add a comment to that effect.
 * hatch shakes fist
<hatch> damnnn you multi dispatch
<hatch> 6 out of 1104 tests failing....not bad....not bad at all
<hatch> bcsaller: are you still hanging around?
<bcsaller> hatch: yeah
<hatch> have a few minutes to look at my dd ie work?
<bcsaller> hatch: sure
<hatch> https://code.launchpad.net/~hatch/juju-gui/ie-dd-fix commented out code still needs to be added back in and the tests need to be fixed
<hatch> just wanted to see if you had any negative comments about the approach taken
<bcsaller> hatch: pulling it down now and looking at diff
<bcsaller> hatch: chat for a sec, its basically fine but I wanted to mention something
<hatch> sure
 * Makyo dogwalks.
<hatch> *warning your site may look like absolute garbage if the user accidentally turns on 'compatibility mode'*
<hatch> jujugui looking for 2 reviews and a qa in IE https://codereview.appspot.com/12683044/ plz and thx
<huwshimi> Morning
<hatch> morning huwshimi
#juju-gui 2013-08-09
<hatch> hey huwshimi you have IE right? Can you QA something for me?
<huwshimi> hatch: Sure
<hatch> thanks! https://codereview.appspot.com/12683044/
<hatch> it fixes drag and drop in IE
<hatch> I coudln't make it break but....ya know....ie
<hatch> so I was hoping for another QA :)
<huwshimi> hatch: Sure, give me a few minutes to get it all set up
<hatch> yeah no rush, just comment on the review when you're done
<hatch> Im not going to do anything more on it until tomorrow
<huwshimi> ugh, the vm needs to do updates
<huwshimi> hatch: Just QAing that we can drop a charm onto the "start adding charms!" message?
<hatch> huwshimi: that's the specific bug that this fixes yes
<hatch> IE has a odd issue where depending on where you drag from it'll either drag the whole element, or just one of the text blocks
<hatch> that's not fixed and not a priority right now
<huwshimi> hatch: Updates look like they might have killed my vm :(
<huwshimi> Might have to rebuild it
<huwshimi> Oh, now it's doing more updates
<rick_h> hey huwshimi, having fun?
<huwshimi> rick_h: Soooo much fun
<rick_h> :)
<hatch> haha that happened to me earlier this week
<hatch> the updates just.....stopped it from working for a bit
<huwshimi> hatch: Yeah working now
<huwshimi> hatch: I can't get past the "Your browser is not fully supported" screen with the inspector flag turned on...
<huwshimi> Or even with the flag turned off now...
<huwshimi> Oh, I clicked some kind of compatibility mode thing
<huwshimi> hatch: QAs OK
<hatch> huwshimi: son of a B I did the EXACT same thing
<hatch> that's a blog post!
<hatch> seriously I spent like 20mins trying to figure out why the heck it wouldn't load
<huwshimi> hatch: :)
<teknico> gary_poster: pong
<teknico> gary_poster: sorry about yesterday afternoon, had to leave a little early
<gary_poster> teknico, np
<gary_poster> teknico, are you available for a hangout?
<teknico> gary_poster: yep
<gary_poster> teknico, ok will be using ipad so not guichat
<teknico> gary_poster: do you want me to setup one?
<gary_poster> teknico, I've tried to hangout with you twice :-P sure you try now
<teknico> ok, switching google accounts...
<rick_h> yay friday
<sinzui> Hi jujugui. I am seeing this error for every test ftest when I test the charm on canonistack
<sinzui> ERROR Missing config 'username', 'password', 'project-name' required for userpass auth\n"
<sinzui> Any clues?
<hazmat> sinzui, OS_ env vars for creds
<sinzui> hmm.
 * sinzui looks at novarc
<hazmat> sinzui, just source it, if you haven't already
<hazmat> env | grep OS_
<sinzui> hazmat, I did. I think I soured the wrong one
<sinzui> hazmat, I have confirmed I did source properly. I think my env is not ignored my make ftest. I can see that running that will destroy the juju environment I previously bootstrapped and deployed to
<rick_h> luca__: ping, around?
<rick_h> gary_poster: luca__ I'm trying to match up the design image as best I acn without actual dimensions and the fact that the category icons don't look like the ones used in the mock up. http://uploads.mitechie.com/lp/autocomplete_design.png is where I'm at. Please give it a look over. I've got some tests to write and then I'll put it up. 
<rick_h> jujugui review time please. Autocomplete for all. notes and qa instructions included along with link to the design reference. https://codereview.appspot.com/12545044
<jcsackett> rick_h: looking.
<rick_h> gary_poster: I'll hold off on landing until the screenshot is ok'd by design. 
<rick_h> thanks jcsackett 
<jcsackett> rick_h: confused about the "is Category" check. is the id this is looking at a charm id, e.g. soemthing like "cs:foo/bar"?
<rick_h> jcsackett: sorry, previous branch. We manually add categories into the results and build a manual id to make them work with charm-tokens
<jcsackett> maybe i'm not so much confused as surprised that "cat:foo/bar" is a valid charm id we get, if that's the case.
<jcsackett> ah, ok.
<rick_h> jcsackett: that id is cat:~gui/
<jcsackett> so this is more about shoe-horning in categories so they work with the charmtoken for autocomplete display.
<rick_h> jcsackett: see line 158 in that file/diff (expand all)
<rick_h> jcsackett: correct, this way categories get an icon, behave/look like charm-tokens
<jcsackett> rick_h: dig, that makes sense. thanks.
<rick_h> jcsackett: http://uploads.mitechie.com/lp/autocomplete_design.png for a screenshot (but please qa)
<gary_poster> rick_h, here.  just had one of those...interesting meetings. :-)  jamie will look at it in a few minutes
<rick_h> gary_poster: hah, it is friday where the most interesting ones take place :)
<jcsackett> ah, the ever growing use case of the charm token...who knew it would end up in so many palces ...
<rick_h> jcsackett: charm-token is the most reusable widget in the history of canonical widgets :)
<jcsackett> rick_h: whoo!
<jcsackett> (as long as you're willing to beat some data with a hammer for it)
<rick_h> jcsackett: hey, you have to agree to its API :)
<jcsackett> fair. :-P
<adeuring> abentley: could you have a look here: https://code.launchpad.net/~adeuring/charmworld/1204985-address-key-error/+merge/179443 ?
<abentley> adeuring: Sure.
<jcsackett> rick_h: code looks good, QAing now.
<jcsackett> rick_h: not a bug per se, but when i do 'apach' apache2-passenger is above apache2, which seems like an odd sorting.
<rick_h> jcsackett: yea, it's based on weighting from the server and such. We can file something upstream in charmworld but I just take it as I get it
<jcsackett> rick_h: review up. LGTM, QA ok, some notes.
<abentley> adeuring: Please update the comments to indicate that Charm.store_url has a revision and Charm.address does not.  With that change, r=me.
<adeuring> abentley: ack, thanks
<benji> abentley: I'm doing final QA of my branch; how do I give myself admin access to my local charmworld?
<abentley> benji: Admin access to the web site like charmers have?
<benji> yep
<abentley> benji: log in.  Anyone who's a member of juju-jitsu can log can act like a charmer on dev instances.
<abentley> s/can log can act/can act/
<benji> cool
<abentley> benji: including staging.
<benji> abentley: "403 Forbidden"; from https://launchpad.net/~juju-jitsu: "You are an indirect member of this team"
<abentley> benji: Wacky.  I am also an indirect member of the team.
<abentley> (but it works for me)
<benji> abentley: I'm visiting /charms/precise/apache2/featured/edit, if that makes any difference
<abentley> benji: The login operation should work the same everywhere.
<abentley> benji: I was able to mark a charm featured locally.
<abentley> benji: I did it just now.  (precise/apache2, in fact)
<benji> ok, thanks.  I'm building a fresh trunk to see if it is a problem on my branch.
<benji> I get a 403 on trunk too.
<abentley> benji: You get that error when you click "login" on your dev instance?
<benji> abentley: nope, after I login and I visit t/charms/precise/apache2/featured/edit
<benji> abentley: I figured it out: the team membership checkbox is not automatically checked when loggin in through two-factor auth so it wasn't sent to the app (that seems like something we should fix)
<abentley> benji: We have it fixed for production.  For dev instances, login.ubuntu.com does not trust your dev instance like it trusts launchpad, so it lets the user decide what info to communicate.
<benji> makes sense
<benji> in that case a big-ole message on login.ubuntu.com would be nice 
<abentley> benji: Sorry, I lied.  We have it fixed for *staging*, but not *production*.
<benji> k
<abentley> benji: What would the message say?
<benji> something along the lines of "UNLESS YOU CLICK ON THINGS BELOW, THIS PROBABLY WON'T DO WHAT YOU THING IT WILL DO"
<abentley> benji: In some cases, the site will continue happily along, in other cases, it will prompt you for the missing data.  Maybe we could trigger it on the teams extension, since that's a case where having the user supply the data later is not an acceptable alternative.
<benji> that would be nice
<jcsackett> jujugui: weekly now, right?
<benji> jcsackett: I figured we were skipping weekly because of no Gary, and having the daily at the same time
<jcsackett> benji: i'm just going by what's on the calendar.
<benji> pfft, calendars!  the next thing you know you'll be wanting style guides and tests
<rick_h> 'by the book' suckers :P
<hatch> jcsackett: sorry I was waiting until 9:#0
<hatch> keep it the same as the rest of the wk
<hatch> because we wont' really have much of a retrospective
<bcsaller> more time for coffee then
<jcsackett> this has been a week of mutiny.
<rick_h> how dare you attempt to cage me with your schedules, limits, and rules!
<hatch> lol
<hatch> jujugui guichat in 8 kanban now
<benji> call at 9:#0 huh?  I guess the capital "3" really emphasizes the time
<hatch> exactly what I was going for!
<hatch> jujugui guichat in 1
<hatch> jujugui starting without you
<teknico> http://www.youtube.com/watch?v=4FfXLMpr_DY
<abentley> benji, bac: Do you want to have another sync call today?
<bac> abentley: sure, after lunch?
<benji> abentley: sure; how about after you review the branch that I haven't proposed yet?
<abentley> bac: Works for me.
<rick_h> lol
<rick_h> bcsaller: https://codereview.appspot.com/12545044/ is the link for the review
<abentley> bac: My lunch is in 15 minutes.
<bcsaller> rick_h: thanks I was looking
<hatch> bcsaller: can you do that reviewon the ie branch? https://codereview.appspot.com/12683044/
<benji> abentley: when I visit /api/2/charms/interesting I get an error about "No mapping found for [downloads] in order to sort on".  I expect there is something I have to run to create and populate that index, do you know what it is?
<abentley> benji: charmworld/jobs/cstat.py will update that.  We should really add downloads to the mapping, though.
<benji> abentley: cool, thanks
<abentley> benji: np.
<hatch> hey do we have a guide to get the Go dev env up and running somewhere?
<hatch> what the shit ie is now giving me an 'unspecified error' on identical code from yesterday
<rick_h> thanks bcsaller 
<rick_h> hatch: you load IE in anger, you might be bitten :P
<hatch> I'm so bloody pissed off right now
<hatch> the error number is .... get this ...  -2147467259
<hatch> who uses NEGATIVE Numbers for error numbers
<benji> abentley-lunch: I would appreciate a review of my feature breakout branch: https://code.launchpad.net/~benji/charmworld/featured-breakout/+merge/179503
<abentley> benji: I just got back.  Are you psychic?
<benji> I get that a lot.
<abentley> benji: Your branch reintroduces the 'qa' attribute that I've removed.  Is that an accident?
<benji> abentley: yep; ignore that I must have fixed some conflicts wrong
<abentley> benji: at 215, I don't think CharmTestCase needs to derive from MongoTestBase
<hatch> jujugui can someone with IE10 pull down my ie branch and QA it? I can't get this branch to run at all anymore, even on revno's that passed QA
<abentley> benji: This looks good as far as it goes, but it doesn't introduce a migration, so it's not landable.
<abentley> benji: Also, I think I suggested using a modified construct_charm_id to generate revisionless charm ids.  I'm doing that in my upcoming branch, and it would be nice for the ids to line up.
<abentley> benji, bac: I'm up for a sync-up whenever you are.
<bac> abentley: sure
<bac> abentley: guichat now?
<abentley> bac: sure
<hatch> I was finally able to get it working again...
<benji> abentley: I forgot to bzr add the migration file, I've pushed a fix.  Lunching now.
<bac> abentley: does promulgated=true imply the owner is ~charmers?
<abentley> bac: It is common, but not always the case.
<bac> abentley: i'm wedged then.  in my current version i'm using the basket_id to be ~owner/basket/revno
<bac> abentley: for a promulgated bundle the url is /api/2/bundle/api/2/bundle/basket/revno/name
<bac> abentley: i mean: /api/2/bundle/basket/revno/name
<abentley> Right.  Well, I think it would make sense if the basket ID was not affected by promulgation.  Would that help?
<abentley> bac: An example of promulgated=True, owner !charmers is http://manage.jujucharms.com/charms/precise/juju-gui
<bac> abentley: right.  so i need to extract the owner from the basket_id.
<abentley> bac: I don't understand why.
<abentley> bac: The owner is in the payload/basket_data, so why not use it directly?
<bac> abentley: for the promulgated case i showed above, the query is:
<bac> query = {'basket': basket_id, 'name': path[2], 'promulgated': True}
<bac> abentley: the basket in mongo will be prefixed by the owner name.  in this lookup i don't know the owner's name
<abentley> bac: I had hoped you wouldn't need to basket itself when retrieving a bundle.  Can we fix it so you don't?
<bac> abentley: we have to support URLs like /api/2/bundle/basket/revno/name so we only have (basket, revno, name) to work with for the query.  i'm open to suggestions
<abentley> bac: Okay, so what data do you need, that's currently in the basket?
<jcsackett> jujugui: is anyone else getting a string of 304s when they run test-server? i've just updated from trunk, and hadn't yet today. observing the behavior in trunk as well as my own branches that updated.
<bac> abentley: chat?
<bac> might be faster
<benji> abentley: I pushed my branch with the un-added migration file added.
<abentley> bac: sure.
<hatch> jcsackett: yup lots-o-304
<abentley> benji: I saw that, but not a fix for the QA stuff.
<benji> abentley: oh, I forgot that :) 
<benji> fixing now
<jcsackett> hatch: does it move past hitting those two files over and over with 304 for you? i just keep getting test timeouts with that.
<hatch> GET /test/charm%20icon%20url 404 2ms
<hatch> GET /juju-ui/assets/svgs/service_module.svg 304 5ms
<hatch> lemme run the full suite
<hatch> sec
<hatch> jcsackett: the tests appear to be running as expected
<jcsackett> hatch: hrm. not for me.
<jcsackett> i do 304 on js-yaml over and over and then get a timeout.
<abentley> benji: Also, I posted earlier: I think I suggested using a modified construct_charm_id to generate revisionless charm ids.  I'm doing that in my upcoming branch, and it would be nice for the ids to line up.
<hatch> yup 100% finished on a very slightly modified version of trunk
<benji> abentley: will do 
<abentley> benji: I am just putting up a branch that modifies construct_charm_id
<benji> abentley: this is how I did it: http://paste.ubuntu.com/5967438/
<abentley> benji: This is how I did it: https://pastebin.canonical.com/95719/
<benji> abentley: given that we'll always be hardcoding the boolean parameter, two functions makes more sense to me; but it won't kill any kittens
<jcsackett> alright, clean checkout time.
<abentley> orangesquad, bac or benji: Could you please review https://code.launchpad.net/~abentley/charmworld/pre-versioned-ids-for-charms/+merge/179521 ?
<benji> abentley: I'll take a look
<hatch> jujugui looking for 2 very quick reviews and a quick qa on https://codereview.appspot.com/12704043/ plz and thx
 * hatch lunching
<abentley> benji: I've never really heard this "always be hardcoding" rationale before.  What's the virtue having two functions to avoid hardcoding?
<benji> the hardcoding rationale is mine, but the "a single boolean that changes the way a function works is an anti-pattern" thought has been around for a while
<benji> the virtue would be that having two named, straight-line (i.e., no loops or branches) functions is more straight-forward than one function that can do two things
<benji> this is a bikeshed, though, so we've probably already spilled enough digital ink over it ;)
<hatch> bcsaller: replied, and class changes being re-proposed
<bcsaller> hatch: thanks
<hatch> bcsaller: ok repropose finished
<hatch> jujugui also if there is anyone else available to review it, it's only like a 8line diff
<benji> hatch: I'll look
<hatch> thanks
<hatch> benji: lol
<benji> :)
<hatch> thanks for the review - I'd like to use a real name but 80chars
<hatch> I suppose I could store the string in a smaller var
<benji> hatch: you can use a longer name and split the line instead
<hatch> yeah it's fixed :)
<hatch> benji: do you know if we have a 'get started with go' guide for juju?
<benji> hatch: I don't think we have anything company-made
<hatch> ahh ok - I was thinking this weekend I might give Go a go
<hatch> I'll find something online
<hatch> don't know what I'll make
<hatch> what do people make with serverside languages now?
<hatch> lol
<hatch> everything I do has a gui
<abentley> hatch: I prefer to think of them as non-JavaScript languages :-)
<hatch> abentley: lol even my serverside is done in js now - but it's job is to respond to a gui lol
<hatch> oo a console based todo app
<hatch> that's what I'll do
<hatch> jcsackett: you should probably make sure the tests CAN fail ;)
<bac> abentley, benji: you're both near EOD but if you'd like to do a review: https://code.launchpad.net/~bac/charmworld/bundles-display/+merge/179541
<benji> bac: sure
<bac> thanks benji.  i'll bbiab
<hatch> bcsaller: so on the settings inspector page when I change a field it's background turns a light grey and I get a red star
<hatch> after clicking save, it should clear those ui changes no?
<bcsaller> hatch: yes, it should, the model should be set, that was working fine before
<bcsaller> maybe I broke something moving the viewlets about, there was a bit of merging there for that
<hatch> ok I'm on a fresh trunk checkout - the model is being updated on save
<bcsaller> I'll look into in a few if you're not on it
<hatch> I'm just working on the button bug right now
<hatch> that might expose the issue as well
<hatch> bcsaller: ahh this button issue does look related to the conflict stuff
<bac> dogwalk cut short by monsoon
<hatch> bcsaller: hey there must have been a bad merge if this ever did clear on save
<hatch> because it looks like that only happens on conflict resolution
<hatch> would you have an idea of where that method may be? Or if it was just forgot
<bcsaller>   hatch: this is vs trunk or should I look at your branch?
<hatch> bcsaller: might as well just look at trunk
<hatch> I only changed one string so far heh
<bcsaller> ok, checking into it now
<bcsaller> hatch: it looks like the config/constraints callbacks do trigger clearChangedValues still
<hatch> yep
<hatch> but it's not responsible for clearing the UI
<hatch> the conflict method in the viewlet is responsible for that
<bcsaller> yeah.. its not bound
<hatch> so do we have a slight architecture issue here?
<bcsaller> which has already been invoked
<bcsaller> looks like a minor one, I can cook up a fix for that 
<hatch> well I'm wondering if we shouldn't define a clear conflict UI method
<hatch> so kind of normalize this conflict method a bit
<bcsaller> I think in my testing I always pushed it down the conflict pipeline and that resovled it
<hatch> oh ok, do you want to tackle this bug?
<hatch> or would you like me to?
<bcsaller> hatch: either way, tell me what you'd prefer
<hatch> umm I can do it, lets have a quick chat in a minute to make sure I'm on the right page
<bcsaller> hatch: thought syncedFields might be the proper place
<bcsaller> look like you could loop the <input>s and clear that state
<hatch> in guichat
<bac> thanks benji
#juju-gui 2013-08-10
<MACscr> so is the gui actually functional in its current state?
<hatch> MACscr: you bet!
<MACscr> hatch: is the tool any good after its deployed?
<MACscr> i mean, can you really use it for anything
<MACscr> my biggest problem with trying to use it to deploy openstack is that i need some services to run on the same node
<MACscr> and im not sure how far that LXC support is yet
<hatch> I don't know the specifics of it but I know that there is some form of it in the current juju-core package
<hatch> you'd be best to ask in #juju about those details
<hatch> or also #juju-dev
<hatch> MACscr: the GUI has support for subordinates but I'm assuming that you are talking about full services
<rick_h> MACscr: the gui doesn't yet have --to support. It's really new to core see http://www.jorgecastro.org/2013/07/31/deploying-wordpress-to-the-cloud-with-juju/
<hatch> hey rick_h
#juju-gui 2013-08-11
<rick_h> hatch: howdy
<huwshimi> Morning
<rick_h> morning huwshimi 
#juju-gui 2014-08-04
<rick_h__> morning
<huwshimi> rick_h__: Morning
<rick_h__> huwshimi: hey, funny running into you there
<huwshimi> rick_h__: Yeah, strange to see you at this time :)
<huwshimi> rick_h__: How was the travel?
<rick_h__> huwshimi: you know, time in a tin can flying through the sky
<huwshimi> hehe
<rick_h__> working on catching up on sleep
<rogpeppe> mornin' all
<huwshimi> Morning
<urulama> morning all
<rogpeppe> urulama: hiya
<rogpeppe>  anyone with good http-fu know what's going on at line 1503 here? http://golang.org/src/pkg/net/http/server.go#L1503
<jcsackett> Makyo: do you know if a unit would ever *not* have a state outside of being uncommitted?
<Makyo> jcsackett, units should always have a state, I believe.  Is something going wrong?
<jcsackett> Makyo: no, not at all. that's a good answer. :)
<jcsackett> uncommitted units don't have agent_state, which makes sense.
<rogpeppe> urulama, jrwren: https://github.com/juju/charmstore/pull/52
<jcsackett> the QA issue you found was b/c the condition for identifying uncommitted units isn't correct once the service is deployed.
<rogpeppe> anyone know if frankban is around today?
<jcsackett> but since they don't have state, we can use that.
<jcsackett> and that's always accurate.
<rogpeppe> or bac
<Makyo> rogpeppe, frankban is out today on swap.
<rogpeppe> Makyo: ah, thanks
<Makyo> jcsackett, ah, yeah, that makes sense
<jcsackett> rogpeppe: bac is in nuremburg.
<Makyo> Boo, forgot about that.,
<Makyo> CI doesn't seem to be working for me.
<rogpeppe> jcsackett: ah, i'd forgotten about that 
<Makyo> Maybe jenkins needs a kick in the pants
<rogpeppe> i guess i'm just not gonna land anything today
 * rogpeppe goes to the pub :-)
 * jcsackett laughs
<jcsackett> rogpeppe: starved for reviews, or jenkins issues?
<rogpeppe> jcsackett: reviews
<rogpeppe> jcsackett: i think there's only one person around ( jrwren ) that can review the code, but i need two reviews for landing
<jcsackett> rogpeppe: can Makyo or hatch sub in for today, or do you need deep knowledge of the code base? they're both go-literate, if memory serves.
<jcsackett> (it's not ideal, but better than blocking)
<Makyo> jujugui call in 6
<urulama> rogpeppe: i'll try to do it
<urulama> rogpeppe: but it's a huge one and with interruptions, it might take a while :)
<rogpeppe> urulama: if you could, that would be great. unfortunately, it's a bit of a bad of bits.
<rogpeppe> perhaps i should try to split it up
<rogpeppe> anyone know of a good tool for splitting up branches?
 * urulama suggests an axe
<rogpeppe> lol
<Makyo> jujugui call now.
<jrwren> http://ci.jujugui.org:8080 its up
<jrwren> I have no answers for why it wasn't up.
<Makyo> jrwren, awesome, thanks
<kadams54> jcsackett: finished QAing your PR
<kadams54> Makyo: you mentioned running debug logging while setting the juju-gui-sourceâ¦ how do I do that?
<Makyo> juju debug-log
<kadams54> This is what I get: http://pastie.org/private/8kodvcgaorziu7fq9evxa
<kadams54> Seems to be an error right off the bat, maybe in fetching the new source from git?
<kadams54> guihelp: ^
<jcsackett> kadams54: thanks.
<rick_h__> hey all, anyone know what's the status of hatch's card and potential gui release?
<rick_h__> jujugui ^
<Makyo> rick_h__, working on QAing now, then checking on some problems with the charm, then I'll see about starting release prep.
<rick_h__> Makyo: awesome thanks. 
<rick_h__> Makyo: what's up with the charm?
<urulama> rogpeppe: i've looked your PR ... it's huge, for last parts /v4/stats.go and stats_test.go i need more time ... 
<Makyo> rick_h__, some folks are having trouble setting juju-gui-source - looks like it fails to start back up.
<Makyo> Going to research that.
<rogpeppe> urulama: yes, i'm sorry about that
<rogpeppe> urulama: i fixed lots of things in an organic way when trying to make the tests pass
<rick_h__> Makyo: note that only works in trusty and not precise due to git changes
<urulama> rogpeppe: yes, that's what i'm worried about
<urulama> need to go to dinner
<rogpeppe> urulama: i could spend a few hours splitting it up
<Makyo> rick_h__, Aha! Good to note.  kadams54 ^
<rick_h__> Makyo: yea, would love to get details on the series and the string used for that field to make sure it's supposed to work
<rick_h__> Makyo: so trusty + 'develop' should be trunk and be good to test with
<rick_h__> and should come up, if not there's a log file to check in /var/log/juju/all-?
<kadams54> rick_h__, Makyo: alas, I'm in trusty.
<kadams54> I didn't see anything obvious in the all-machines.log file, but I'm going to give it another go, this time tailing both that and running debug-log
 * rogpeppe is done for the day
<rogpeppe> g'night all
<Makyo> Can't seem to deploy the charm at all, hmm.
<kadams54> rick_h__, Makyo: And of course, this time, it appears to have worked for me. FWIW, I confirmed that my card, bug #1341653, seems to be fixed.
<Makyo> kadams54, Woo!
<Makyo> I might be running into a juju bug, not sure.  Trying on other computer.
<kadams54> I'm going to see if I can clear a few more cards out of the QA queue.
<Makyo> Yeah, seems to be something weird going on in tip, up and QAing juju-gui-source now.
<hatch> Makyo juju-core is failing CI atm so you'd best to use a stable release 
<Makyo> hatch, so I found.
<Makyo> Now go back to not working.
<Makyo> It's a holiday :)
<hatch> haha I am not working :) I have to do html's and css's for my dads website....bleh, I wonder if I could convince huw to do this for me lol
<hatch> right Monday Holiday
<kadams54> Provincial Day!
<tvansteenburgh> anyone in here familiar with the charmhelpers.contrib.jujugui python module?
<hatch> jujugui https://twitter.com/FromAnEgg/status/496158671710466049 hahaha 
<tvansteenburgh> i have a MR to remove it, wondering if anyone here cares
<hatch> tvansteenburgh I've never even heard of it :) what does it do?
<tvansteenburgh> nothing any more! muwhahaha
<hatch> lol w00t
<urulama> hi there, jujugui
 * urulama hears pings go all over the world ;)
<hatch> haha hey urulama how goes ze Germans?
<hatch> (little Top Gear reference there)
<urulama> ze Germanz are fine ... at least their bear and pork products are ;)
<urulama> s/bear/beer
 * urulama now wonders what a bear tastes like
<hatch> haha
<hatch> tastes pretty gamey 
<urulama> you had one?
<hatch> of course
<hatch> elk deer, etc etc
<hatch> I live in the North remember
<hatch> north of the wall ;)
<urulama> survival of the fittest :)
<urulama> i had deer and boar and whatnot, but not bears ... and we have a lot of them, just not allowed to eat them
<urulama> so how's it going? CI working now?
<hatch> no idea, I'm off today
 * kadams54 is going to start referring to hatch at "that wilder".
<rick_h__> howdy all
<kadams54> urulama: I just landed a branch for juju-gui, so that CI seems to be working
<kadams54> rick_h__: hey there
<urulama> hatch: remember the talk about being away from computer ... now's probably the time then :)
<urulama> kadams54: ok, good news 
<rick_h__> Makyo: issues? no release it sounds like?
<hatch> hey rick_h__ 
<hatch> urulama haha, I'm sitting in the back yard on the swingy chair with a beer working on my dads website.....it's pretty day-ofish :)
<rick_h__> hey hatch 
<Makyo> rick_h__, I think release is a go, pulling together changelog now.  May actually go out tomorrow.
<Makyo> (was on the patio, sorry)
<hatch> to submit forms on this vps I have to write a PHP script....
<hatch> I don't even think I remember how to write a form submission script in PHP any longer lol
<hatch> I can't even write it in python....
<hatch> what kind of vps restricts to ONLY php
<hatch> haha
<Makyo> Someone landed a branch while I was writing the change log and now there's a conflict >:/
<huwshimi> Morning
<huwshimi> hatch: Morning, in a test I have a beforeEach that sets "placeUnit: utils.makeStubFunction()". How would I go about having one test that has the real function there?
<Makyo> jujugui GUI release is done.  Going to get dinner prepped, then work on charm release.
<huwshimi> Makyo: Yay!
<Makyo> On going through the change log, decided on 1.1.1, since much of our work was done behind a feature flag meant for a larger release.
<hatch> huwshimi have a code sample? From that one there it looks like you're just passing in a fake stub not the actual ecs object?
<hatch> Makyo +1 Thanks for doing the release!
<huwshimi> hatch: Yeah, so it's stubbed out for all the tests, but it one test I don't want to stub it out...
<hatch> huwshimi well it looks like your not stubbing it out but passing a mock ecs in?
<huwshimi> hatch: https://github.com/juju/juju-gui/blob/develop/test/test_machine_view_panel.js#L223
<hatch> huwshimi ok yeah you're passing a mock in, you'll need to set the ecs to a real ecs object if you want to use the real placeUnit
<huwshimi> hatch: Ah ok, so any ideas on how to do that?
<huwshimi> Do we do this anywhere else?
<hatch> you can't really 'just' use placeUnit because it relies on the ecs instance in a lot of places
<hatch> well what are you testing?
<huwshimi> hatch: OK, so I'm trying to test that a container token is created when placeUnit occurs
<huwshimi> I'll push up my code
<hatch> well you don't really need to do that
<hatch> you just need to test that placeUnit is called with the proper data
<hatch> then there should be a test which takes said data and makes sure placeUnit does the proper stuff with it
<hatch> ^ huwshimi 
#juju-gui 2014-08-05
<rogpeppe1> mornin' all
<urulama> robbiew: morning
<urulama> robbiew: sorry ... meant rogpeppe1
<rogpeppe1> urulama: yo!
<urulama> rogpeppe1: i might have empty slot and continue reviewing your PR so that you're not blocked
<rogpeppe1> urulama: thank you v much. if it's too much, i will split it up like i should have done in the first place :-)
<urulama> rogpeppe1: i just have internal/v4/stats.go and tests, no problem
<rogpeppe1> frankban: hiya
<rogpeppe1> urulama, bac, jrwren, frankban: https://github.com/juju/charmstore/pull/53
<frankban> rogpeppe1: morning, on it
<rogpeppe1> frankban: thanks
<rogpeppe1> "Nice! It's great that go stdlib supports this out of the box."
<rogpeppe1> frankban: it wasn't immediately obvious how to take advantage of it for our use case...
<frankban> rogpeppe1: yeah, I see you required to mimic a FileSystem (and a File)
<rogpeppe1> frankban: yeah.
<frankban> rogpeppe1: done
<rogpeppe1> frankban: ta!
<rogpeppe1> frankban: and os.FileInfo...
<frankban> rogpeppe1: indeed
<rogpeppe1> frankban: fancy pairing on some charmstore stuff?
<frankban> rogpeppe1: sounds good, IIRC this week I will be working on the charmstore
<rogpeppe1> frankban: cool
<rogpeppe1> frankban: also, i'd quite like a review of https://github.com/juju/charmstore/pull/52 but i realise it's more sprawling than it should be
<rogpeppe1> frankban: https://plus.google.com/hangouts/_/canonical.com/gogogo?authuser=1 ?
<frankban> rogpeppe1: I'm there
<urulama> rogpeppe1: sorry, got sucked up in meetings ... no time for review till evening :(
<rogpeppe1> urulama: np. frankban is on it.
<urulama> rogpeppe1: ok, great, it can proceed! *happy now*
<rogpeppe1> urulama: :-)
<rogpeppe1> urulama: how's it going?
<urulama> intense
<urulama> but progress being made
<rogpeppe1> cool
<urulama> identity, authorization, different core parts, billing ... a lot of issues at least being started on and documented and agreed on initial plan
<frankban> rogpeppe1: review done
<rogpeppe1> frankban: brill, thanks
<rogpeppe1> frankban: am just making the changes
<frankban> rogpeppe1: cool
 * frankban lunches
<jrwren> rogpeppe1: I'll rev you if you rev me: https://github.com/CanonicalLtd/charmstore-charm/pull/1
<jrwren> rogpeppe1: j/k, I'll rev you either way.
<rogpeppe1> jrwren: looking
<frankban> rogpeppe1: ready when you are
<rogpeppe1> frankban: just reviewing jrwren's PR
<frankban> rogpeppe1, jrwren: I also need reviews for https://github.com/juju/charmstore/pull/54
<rogpeppe1> jrwren: reviewed
<jrwren> Is +1 an alias for LGTM ?
<rogpeppe1> jrwren: i think so
<rogpeppe1> frankban: reviewed
<rogpeppe1> frankban: hmm, the 'bot doesn't look too happy: http://ci.jujugui.org:8080/job/charmstore-merge/
<kadams54> rick_h__: soâ¦ are there any exceptions to having two reviews? I just finished QAing a PR from huw that is just an updated image fileâ¦
<rogpeppe1> kadams54, rick_h__: i also have a bit of a problem with the two review thing. when i've been pairing with frankban, obviously i can't get a review from him, but then there's only one other available reviewer.
<rogpeppe1> jrwren: https://github.com/juju/charm/pull/35
<rogpeppe1> well, with jenkins off line, i guess we can't land anything anyway, so it doesn't make much difference
<jrwren> jenkins is down again?
<jrwren> ugh
<rogpeppe1> jrwren: yeah
<jrwren> looking
<jrwren> rogpeppe1 and all: jenkins it building again
<rogpeppe1> jrwren: lol. we've just bypassed it :-)
<jrwren> Hopefully your bypass doesn't crash the lander.
<frankban> rogpeppe1: http://ci.jujugui.org:8080/job/charmstore/60/
<Makyo> jujugui call in 9
<hatch> jujugui call now
<Makyo> jcsackett, you in today?
<hatch> I think that huws cards in landing have landed
<frankban> rogpeppe1: gogogo in a minute
<rogpeppe1> frankban: am back in gogogo
<hatch> frankban there is a card in Project 1 with my head on it about adding a 'deleted' flag to machines and containers.....didn't you already do this?
<frankban> hatch: no
<hatch> frankban you just did services and units? 
<hatch> I'm trying to decide what card to pick up next
<frankban> hatch: I didn't add a deleted flag to anything
<hatch> wasn't there something you did about removing services? 
<frankban> hatch: if you are going to do that, I'd suggest to also add a isGhost flag
<frankban> hatch: it was about renaming services, not removing them
<frankban> hatch: we discussed about a possible solution for entities removal, and we agree don the db flags
<hatch> ohh ok so the removal stuff wrt the ecs is still all not done
<frankban> hatch: AFAICT yes
<hatch> frankban ok thanks
<hatch> Makyo Did you forget to add a release tag?
<hatch> :)
<hatch> hi luca 
<luca> hi hatch 
<Makyo> hatch, https://github.com/juju/juju-gui/releases/tag/1.1.1
<hatch> interesting, I don't have that tag.....hmmm
<luca> hatch: sup
<hatch> doh I forgot to fetch
<hatch> carryon....sorry :)
<hatch> luca oh just workin away on this darn machine view.....wish it would just be done already
<luca> hatch: me and you both bud
<luca> hatch: me and you both
<hatch> wish the designs would stop changing for a day or so....
<hatch> :P
<hatch> lol
<luca> hatch: rofl
<luca> hatch: donât make me send another revision!
<hatch> hahaha, "make you"? You mean you don't already HAVE another ready to go?
<hatch> lol
<hatch> jcsackett didn't you do something wrt the uncommitted units recently? https://bugs.launchpad.net/juju-gui/+bug/1352973 If you're still in that area you might want to see this bug
<jcsackett> hatch: i've moved on, but i can tackle that next--can you assign me to the card?
<hatch> sure will do
<jcsackett> hatch: thansk.
<jcsackett> er, thanks.
<hatch> jcsackett there is a util method for taking that id and getting the real name 
<jcsackett> hatch: cool.
<hatch> so should be easyish to do
<hatch> created
<hatch> hey fabulous 
<hatch> 1 more mo :)
<fabulous> yes
<fabulous> Still waiting for my exact end date :(
<fabulous> hi everyone
<rogpeppe1> jrwren, Makyo: https://github.com/juju/charmstore/pull/55
<kadams54> guihelp: where did things land on the uncommitted indicators? We're using text characters for those now, right?
<kadams54> hatch: ^
<hatch> kadams54 I think some are using png and some is a character
<kadams54> What's the character being used?
<hatch> look at the mv stuff it's a character there
<kadams54> &deg;
<hatch> nope
<kadams54> hatch: Well that's what it is in machine-token.handlebars :-)
<hatch> hmm check in the css 
<hatch> kadams54                     content: "\00B0";
<hatch> from juju-inspector.less
<hatch> it might be that we have to use one one place and one ther other
<kadams54> Yeah
<kadams54> That's likely the hex equivalent of &deg;
<kadams54> I also found a .uncommitted-circle in mixins.less
<hatch> ahh right it s
<kadams54> Makyo: The ticket I'm working on means truncating long names. Trying to figure out if that needs to happen in the JS or if it can happen via CSS in the charm SVG.
<hatch> kadams54 css has an elipsis overflow property
<Makyo> kadams54, hatch if that works well with SVG, then we should be good.
<kadams54> Makyo: as best I can tell, text-overflow: ellipsis doesn't work in SVG-land. Unless I'm missing something?
<hatch> well it's container needs a defined width for sure
<hatch> does it?
<kadams54> Yeah, I set a width on the container
<kadams54> width, overflow: hidden, and text-overflow: ellipsis
<kadams54> But they didn't seem to take. I noticed that some CSS stuff works for SVG elements, others do not.
<kadams54> border: 1px solid red, for example, does not work.
<Makyo> kadams54, hatch It might not, unfortunately.  May need to truncate the actual name, add an ellipsis (and then the pending indicator if necessary down the line)
<kadams54> But changing the font-size doese
<Makyo> Yeah, not everything's applicable with svg elements.
<hatch> boo
<Makyo> There isn't really a concept of inline/block for example.
<hatch> calculating the width of the text is going to be a pita
<kadams54> I think that's a bad route.
<Makyo> May just need to pick a number of characters to fit on the name of a service.
<kadams54> If we can't truncate in CSS, the next best option, IMO, is to truncate at a certain character count
<kadams54> hatch: "Guidelines from UX were to truncate names with ellipses but keep the indicator at the end whether or not truncated."
<hatch> so it'll always be ...? even if it's not truncated?
<kadams54> That's from the ticket. Does that mean they want the indicator moved to the end of the service name, or can I leave it at the beginning, where it currently is?
<Makyo> Yeah, calculating the width of the text wouldn't really work with variable-width text.
<Makyo> hatch, no, only when it's truncated.  If it's eg: 15 or more characters, truncate to 13, add ellipsis.
<kadams54> hatch: No, it'll only have the ellipsis if we truncate, which would happen after X characters
<hatch> I suppose we would then need to err on the side of caution and do at least a single extra character because of the variable width char set
<Makyo> Sure
<Makyo> Just need to find a good threshold.
<hatch> yeah might be tough cross browser/os hah
<Makyo> m is always going to be the widest character, so a service named mmmmmmmmmmm is a good place to start.
<Makyo> hatch, we're loading webfonts.
<hatch> yeah good point
<hatch> right, but osx/ubuntu render fonts very differently :)
<Makyo> They shouldn't in SVG-land, otherwise they wouldn't pass W3C spec.
<hatch> huw and I ran into that when doing the deg icon for uncommitted
<Makyo> Right, but in dom land.
<hatch> point to point in svg will be the same, but I'm pretty sure fonts are a separate case
<Makyo> Okay.
<kadams54> http://www.opera.com/docs/specs/presto25/svg/cssproperties/
<kadams54> Opera-specific, but stillâ¦
<kadams54> Not only does SVG not support all HTML CSS properties, but in SVG land some are different.
<kadams54> background-color becomes fill
<Makyo> Yes, because fill works differently.
<Makyo> If you have a non-flat polygon, there are fill-rules you have to worry about.
<kadams54> It looks like there's an overflow property, but it only applies to certain elements (i.e., not text or tspan).
<kadams54> And it's still not text-overflow: ellipsis
<kadams54> Looks like I'll have to truncate in JS
<hatch> boo urns!
<kadams54> Wow, with an all-m service nameâ¦ truncate after 7 characters.
<kadams54> Ouch.
<Makyo> kadams54, maybe hunt around for something that's a bit more intelligent about truncating in JS?  Like, a library of wide/narrow characters that can help?
<hatch> kadams54 yikes....
<hatch> Makyo that would be pretty highly dependant on the font
<hatch> kadams54 you COULD render it to the dom, measure it, then truncate really fast :)
<kadams54> Yeah, that's the standard workaround if you absolutely *must* have character width.
<kadams54> Make in hidden div, populate it with the text, get the width, then delete it.
<kadams54> But I hate that.
<hatch> have to be a hidden svg in this point :) because of scaling haha
<kadams54> Yup
<kadams54> Like I saidâ¦
<Makyo> Lets not get too in the weeds here.  Can we come up with a prototype or two along different lines of functionality?
<Makyo> Just a smash-and-bash here's-what-we-could-do thing.
<kadams54> https://github.com/jprichardson/d3-measure-text
<kadams54> Yeah, I'll see what I can hack up shortly.
<hatch> oh cool little script there
<hatch> still falls into what you 'dont' want to do :)
<hatch> kadams54 hey how goes the battle?
<kadams54> Truncation on character count works fine. Playing with that d3-measure-text plugin now to see how easy/hard it is to get something going with that.
<hatch> right - but doesn't that turn wordpress into wordpre.. ? :)
<kadams54> Yes, it does. I think that's the intent?
<kadams54> Well, actually, I went with a character limit of 10. So wordpress is untruncated
<jcsackett> when did we stop showing "new" in the charm results in GUI?
<kadams54> But "ubuntu-mirror" becomes "ubuntu-miâ¦"
<hatch> kadams54 yeah imho that's just not acceptable 
<hatch> I'd be interested to see how the size calculation bit works
<kadams54> hatch: what's unacceptable?
<hatch> jcsackett not sure I follow?
<hatch> kadams54 well maybe if we had it show the real name in an 'alt' on hover ?
<jcsackett> hatch: in the left hand browser. the editorial view. it used to have "featured", "recommended", and "new".
<hatch> looking
<hatch> jcsackett scroll down?
<kadams54> hatch: it shows the full name in the inspector.
<hatch> it's showing for me
<jcsackett> hatch: i have scrolled down. in development, on my machine, i'm not seeing "new".
<jcsackett> weird.
<hatch> kadams54 right - but people usually do things like 'mysql-foobar' and 'mysql-baz' so if it truncates off the differentiator then that's no good
<hatch> know what i mean?
<hatch> jcsackett what about on jujucharms? or comingsoon?
<kadams54> hatch: sounds to me like your issues is more with truncating at all rather than with how it's implemented (char count vs. pixel width) - is that accurate?
<jcsackett> does comingsoon still run the most recent build? don't we have some qa.something.something url for that?
<jcsackett> or am in conflating juju gui and charmworld urls?
<hatch> jcsackett conflating :)
<jcsackett> so, comingsoon i'm seeing the normal thing.
<hatch> ohhh wait a second comingsoon is behind...
<jcsackett> that's what i thought.
<jcsackett> so, i'm assuming this is something someone landed; b/c it's now "recommended" and "other"; i'm just wondering when we did that.
<hatch> interesting the version it's on isn't even in the develop tree....
<hatch> jcsackett I'm just checking locally as well
<hatch> jcsackett ok on develop I still see featured/popular/new
<hatch> on both flags
<hatch> jcsackett are you sure you don't have a search result?
<hatch> ?text= in the addybar
<jcsackett> oh bloody hell, yes i do.
<jcsackett> thanks, hatch.
<jcsackett> was getting quite confused. :p
<hatch> hahaha
<hatch> ahh it happens 
<hatch> :D
<kadams54> bbiab; off to pick the kiddos up from school
<hatch> lata
<hatch> brb rebooting
<hatch> jcsackett so do you have any idea what this new comingsoon url is?
<jcsackett> no idea.
<jcsackett> i believe there was an email from bac.
<jcsackett> i am digging for it now.
<jcsackett> but i haven't found anything yet.
<hatch> yeah I just did a quick search as well...no luck
<rick_h__> kadams54: yes, using a character for uncommitted
<rick_h__> howdy jujugui how goes?
<hatch> hey rick_h__ 
<hatch> tis trucking along well
<jrwren> going, going going...
<jcsackett> hola rick_h__, how's germany?
<rick_h__> it's ok, to warm for my tastes
<rick_h__> but I'm feeling a bit toasty after dinner and drinks
<rick_h__> so how goes the release plans?
<hatch> I think it's done...
<rick_h__> orly?
<hatch> last I heard this am Makyo was doing the charm
<rick_h__> cool
<hatch> https://github.com/juju/juju-gui/releases
<hatch> the gui release is done for sure...
<rick_h__> woot
<rick_h__> ok, will watch out for a charm update. 
<rick_h__> how goes things overall?
<hatch> doesn't look the charm update is done yet
<rick_h__> k
<hatch> good good - found some bugs this morning doing a quick qa
<rick_h__> bugs in the release?
<hatch> no in mv stuff
<rick_h__> or in MV?
<rick_h__> :/ wheeee
<hatch> tried to do some testing on a live env with my vagrant image and it was a pita so I switched to a vm which is now lagging and driving me nuts
<hatch> (can't win today) 
<hatch> :)
<rick_h__> heh :(:(
<hatch> there are so many possible interactions with mv
<hatch> we will need some serious checklist
<rick_h__> yea, definitely
<hatch> ohhh yeah, you use a synology NAS right?
<hatch> you should make sure you update it asap
<rick_h__> heh, yea it's offline atm
<hatch> ahh ok good
<rick_h__> I need to put it on the new router and hadn't gotten around to it
<hatch> ahh well in this case lazyness? has possibly saved you a big headache :D
<hatch> The rosetta spacecraft should be ready to get into orbit around a comet tomorrow 
<jcsackett> what's going on with synology?
<hatch> jcsackett randsomware
<jcsackett> ?
<hatch> there apparently is a hole in an old version where some dickheads could hack into the system and would encrypt your drives
<hatch> then they would ask for bitcoins to unlock it
<hatch> rick_h__ jcsackett  figured you'd get a big kick out of this https://twitter.com/pgte/status/496750687037169664
<jcsackett> hatch: that code is terrifying.
<hatch> haha tis
<Makyo> hatch, ping
<hatch> ping
<hatch> er pong
<Makyo> I think I figured it out, but just to be sure, the precise and trusty charms are the same except for their branch, right?
<hatch> correct
<Makyo> Cool, thanks.
<hatch> np 
<Makyo> Trusty charm is up, getting precise one updated.
<hatch> that reminds me, I should make the trusty charm for my ghost charm at some point
<urulama> jrwren: hi there, how's it going?
<hatch> guess not well... lol
<urulama> :)
<hatch> kadams54 you around?
<jrwren> urulama: I missed ya.
<huwshimi> Morning
<hatch> ahoy!
<hatch> I assigned you a card today huwshimi a bug from your auto-place branch
<huwshimi> hatch: Ah right, thanks
<hatch> blame whomever did the qa
<hatch> :)
<huwshimi> hatch: Can you give me a bit more on how to reproduce?
<huwshimi> hatch: Never mind
<hatch> nope that's all the steps
<hatch> ok
<hatch> :)
<huwshimi> hatch: It's got an attached bug :)
<hatch> oh haha, yeah
<Makyo> hatch, can't get functional tests to pass on the precise charm, keeps failing on test_legacy_server.  Any ideas?
<Makyo> (need to figure out how to run just that one, since a full run takes forever.
<Makyo> )
<hatch> Makyo sorry I have no idea, the last release (I think I did) went through without a hitch, is there any details about what the failure is caused by?
<hatch> legacy_server sounds like pyjuju which maybe we can just delete for now
<Makyo> Cannot connect to the environment.  Checking again on a fresh env
<Makyo> hatch, yeah, not really sure what's up
<Makyo> hatch, if I don't get this sorted this evening, I'm out tomorrow through Monday.  Can you at the very least delegate finishing it?  GUI is released, trusty charm is released, just the precise charm needs some love
<hatch> Makyo yeah sure I have to take off shortly so can you send me an email with the outcome
<Makyo> hatch, will do
<huwshimi> hatch: Any ideas on how to list to the changes to units for a particular service? Here we just do a data-bind: https://github.com/juju/juju-gui/blob/develop/app/templates/scale-up.handlebars#L8 but I need to display the committed state and be able to pluralise the lable etc.
<hatch> hmm
<hatch> looking
<hatch> huwshimi see service-overview.js
<hatch> line.....381
<hatch> er line 400
<hatch> when the units change this gets called
<hatch> try there
<huwshimi> hatch: Ah great!
<hatch> bbl
#juju-gui 2014-08-06
<hatch> kadams54 hey u around?
<kadams54> hatch: yup
<kadams54> What's up?
<hatch> I found a bug in the gui but I remmebr you doing some work on this area so wanted to check b4 I filed it
<hatch> so if I D&D a charm, switch to the mv and then click 'auto place' then deploy/confirm
<hatch> the machine doesn't get the service icon in it
<hatch> I have to switch away from mv then back again
<kadams54> *sigh*
<kadams54> You've reproduced this in something other than Chrome?
<kadams54> It seems like we're constantly squashing "missing icon" bugs
<kadams54> Huw did some work today that may fix that
<kadams54> https://github.com/juju/juju-gui/pull/476
<kadams54> Or rather, that PR landed today
<hatch> kadams54 this was in chrome
<hatch> it was this afternoon so running pretty new stuff
<kadams54> I remember noting when I QA'd it that the icon was added to the machine
<kadams54> Looks like he landed it at 23 hours ago
<kadams54> So I suspect we still have bugs to squash
<kadams54> Though I'd verify it in Safari first
<kadams54> Since I've seen missing icons only in Chrome
<hatch> hmm ok, what's the new comingsoon url?
<kadams54> Damn you Chrome and your SVG bugginess
<kadams54> I have no clue
<kadams54> I didn't know there was a new URL until that discussion this afternoon
<kadams54> :-)
<hatch> haha neither did i
<hatch> ok I'll have to remember to test in the am
<hatch> I have too many vm's spun up I don't want to risk hitting a kernel panick
<hatch> panic even
<kadams54> I've had that happen multiple times this week. I kinda suspect that's due to water damage, though it seems to happen when I have multiple VMs going.
<kadams54> lxc within a full trusty virtualbox image + vagrant
<hatch> I seem to have added an ubuntu juju vagrant image somehow and it's not shown in the vagrant box list
<hatch> and now it's borking new vm's
<hatch> argggg hah
<hatch> yeah I think our default vagrant image installs and boots juju with the gui by default...
<hatch> lazyPower you happen to be kicking around still?
<hatch> ahah found it
<urulama> rogpeppe1: morning
<rogpeppe1> urulama: hiya
<frankban> hi rogpeppe1 
<rogpeppe1> frankban: hiya
<rogpeppe1> frankban: shall we continue?
<frankban> rogpeppe1: sure, gogogo
<rogpeppe1> frankban: i'm there
<rogpeppe1> jrwren, bac, urulama, Makyo: https://github.com/juju/charmstore/pull/56
<urulama> rogpeppe1: LGTM, but go through comments, please
<rogpeppe1> urulama: "What do we do with it in the API?" - i don't understand the question
<rogpeppe1> urulama: thanks a lot for the review, BTW
<urulama> so, what do we do with the errgo.Any?
<urulama> rogpeppe1: it was fun to see the code and not just images and docs :)
<rogpeppe1> urulama: we allow resolveURL to return errors with a cause that's passed back to the caller.
<rogpeppe1> urulama: for example, resolveURL can return a not-found error
<rogpeppe1> urulama: which will end up as a 404
<urulama> rogpeppe1: oh, now i remember ... all clear ... sorry :)
<rogpeppe1> urulama: np
<urulama> but it could end up as 404, just not in an as elegant way
<rogpeppe1> urulama: really?
<rogpeppe1> frankban: https://github.com/juju/charmstore/pull/57
<rogpeppe1> urulama, jrwren, Makyo, bac: ^
<rogpeppe1> frankban, bac, jrwren: https://github.com/juju/charm/pull/36/files
<rogpeppe1> frankban, jrwren: https://github.com/juju/charmstore/pull/58
<frankban> jrwren: thanks for your reviews!
 * rogpeppe1 lunches
 * frankban lunches
 * jrwren breakfasts
 * bac has another tea
<frankban> rogpeppe1: ready when you are
<urulama> hi frankban
<urulama> how's it going?
<frankban> urulama: very well, we are working on the pub api and we ended up working on some pre-req branches.
<frankban> urulama: how is it foing in germany?
<frankban> urulama: if you have time, https://github.com/juju/charm/pull/36
<urulama> frankban: lot of talking here :)
<frankban> heh
<urulama> frankban: good to hear publish api
<urulama> frankban: add about in that sentence :)
<urulama> frankban: i'll take a look
<frankban> urulama: thanks
<urulama> frankban: ah, yes, the question about that check was more about the consequences about somehow adding an unverified bundle to the store ...  
<urulama> and if we didn't use validation before, and there is a good reason that we didn't, it's fine. 
<frankban> urulama: we didn't use that before. the publish API will take care of validating the bundle with respect to charms also
<urulama> frankban: all good then 
<frankban> urulama: cool
<urulama> frankban, rogpeppe1: i'm just thinking ... as there is no client of v3, maybe we don't need v4 ... with this tempo, we'll end up with v192 before end of year :)
<rogpeppe1> urulama: that was frankban's inclination too
<rogpeppe1> urulama: perhaps you're right. we haven't published v3 yet.
<urulama> i would say, until there is a usage of someone, do not increase version number
<rogpeppe1> urulama: but in general, i am wary of that approach
<frankban> urulama: but we agreed is good to not cheat also to exercise this kind of procedure/api management
<rogpeppe1> urulama: we actually do not know that noone is using v3
<rogpeppe1> urulama: and what frankban says.
<rogpeppe1> urulama: we need to get in the habit of doing this right.
<rogpeppe1> urulama: and if there's too much overhead from our procedures when doing this, then perhaps we need to think about how to improve that.
<urulama> rogpeppe1, frankban: i agree that from the purity point of view, this is ok, just thinking about the clients ... they use v2, then v12, and then v24 (the only published versions). it looks confusing.
<rogpeppe1> urulama: all the versions are available and published, really
<rogpeppe1> urulama: we just haven't announced them.
<rogpeppe1> urulama: from the p.o.v. of the rest of the world, only the latest version matters, whether it's v1 or v4
<frankban> urulama, rogpeppe1: it seems to me that, given the current "go get" limitations, and given the decision of using gopkg.in as a workaround for API stability and ability to build a project, what we are doing is fine: a new version branch if the public API changes. we kind of agreed on those premises, and if not, we need to find another way IMHO.
<rogpeppe1> frankban, urulama: i agree with that. we should mostly be able to avoid breaking API changes, I hope.
<urulama> rogpeppe1, frankban: sure. i'm just thinking if there's a better practice. for example. As we develop staff the charm API will change, and there is no guarantee that v5 will not hit in next hour. So. What if during "coding sprints" at which we know that they have high probability to change api, we work on a branch
<urulama> accumulate all the changes and then push version upgrade
<urulama> (unles gopkg.in cant do that)
<jrwren> urulama: I like that.
<rogpeppe1> urulama: i have actually come to like the explicit import-path-version-implies-compatible API approach
<rogpeppe1> urulama: it means that tip is always go-gettable
<rogpeppe1> urulama: (although it's true that v4 charmstore cannot currently be "go getted"
<rogpeppe1> )
<urulama> rogpeppe1: sure, i said i like the purity. just not the implications of changing multiple versions in short periods during developments of same end features (it's a different story when new features are rewuired) ... need to think about it
 * urulama needs to go to room for the power plug ... 
<rogpeppe1> urulama: yeah, i'm not entirely sure either.
<rogpeppe1> urulama: i thought we could try applying the rigorous rule to start with and see how it turned out
<rogpeppe1> jrwren: for the record, I don't dislike $@ - it's the only way to properly pass through a script or function's arguments to another command. i don't like it when it's not quoted though.
<jrwren> :)
<jrwren> I'm lucky package names can't have spaces in them.
<urulama> rogpeppe1: so i've talked about this with Gustavo, and he agrees about branches. we all agree with you that having branches in some way breaks the sole purpose of versions, and there you're right
<urulama> rogpeppe1: so my suggestion is this. let's try with branches and accumulated changes into one version
<urulama> and if it is too painful to use, let's just inc versions
<urulama> rogpeppe1: he uses branches as well
<urulama> or we can say v3-dev version and mark that it's in changing?
<rogpeppe1> urulama: that's a good idea
<urulama> which one :)
<urulama> dev?
<rogpeppe1> urulama: yeah
<urulama> rogpeppe1, frankban, jrwren: ok, let's agree on the -dev one and this is a message to user that it is not stable. You all ok with this?
<rogpeppe1> urulama: we can just mark on the branch somewhere (perhaps in the package doc at the top level) that the API at that version is currently unstable
<rogpeppe1> urulama: we can't have -dev as part of the import path
<urulama> rogpeppe1: sorry ... v3/dev?
<rogpeppe1> urulama: my suggestion is just to write in the package documentation that the API is unstable. When we decide to publish it, we remove that remark from the doc.
<rogpeppe1> urulama: but that would not require any clients to change
<urulama> rogpeppe1: +!
<urulama> ah
<urulama> rogpeppe1: +1
<frankban> urulama, rogpeppe1: what about using a "develop" branch for development. when required, we merge develop into the latest "v*" branch. if develop breaks the API, then we create the next version branch
<rogpeppe1> frankban: i'd prefer to use the actual versioned import paths
<rogpeppe1> frankban: for one thing, it makes it trivial to update with govers
<frankban> rogpeppe1: you still use the import path
<rogpeppe1> frankban: if you use a different branch, then go get can't work
<rogpeppe1> jrwren: are you still making changes to the charmstore charm?
<frankban> rogpeppe1: I know that. I was just suggesting that, rather than working directly on the latest "v*" branch, we could decide to treat those branches as published versions, and work on develop. when develop is ready to be published, we create or update a "v*" branch. clients always use versioned imports
<jrwren> rogpeppe1: not beyond what is already there. I want to move on.
<hatch> morning all
<frankban> hi hatch 
<hatch> frankban have you seen that email from Makyo about the release? Any idea on the error? I'm just about to start on it
<frankban> hatch: I didn't
<frankban> hatch: to gui peeps?
<hatch> oh hah he only sent it to me :D
<hatch> sec I'll forward to u
<frankban> ok
<hatch> ok sent
<frankban> hatch: so, did he release the trusty one?
<hatch> apparently so
<urulama> rogpeppe1, frankban, jrwren: the best practice of using gopkg.in is not here ... we should find one. let's experiment
<frankban> hatch: yes he did
<rogpeppe1> frankban: charmstore is a client
<frankban> hatch: I'd suggest to retry running the precise tests, that error can be spurious
<rogpeppe1> frankban: in our recent situation, what would we have done?
<hatch> frankban ok thanks I'll start there
<frankban> rogpeppe1: 1) update charm develop. 2) realize there is client code needing the last changes we made 3) start a charm release process 4) check what needs to be released, does it break the API? 5) if so, release a new version branch, if not update the latest version branch 6) update the client
<rogpeppe1> frankban: how would that change the workflow we just did?
<rogpeppe1> frankban: after all, charmstore is a client, and needed the changes we made in v3
<rogpeppe1> frankban: so in the workflow above, we'd have released a new v3 version. and then the same would have applied to v4.
<frankban> rogpeppe1: it does not change the "v*" workflow, it changes how the process is managed. developers know where trunk lives (develop) so they can create their branches form there. creating/updating version branches is now a process per-se, not part of a feature branch. so you have a card for releasing a new version, and everyone knows you are doing that. crazy clients that want to live on the edge can also import th
<frankban> e develop branch directly
<urulama> frankban, rogpeppe1: ok, let's step back and look at the http://labix.org/gopkg.in
<frankban> rogpeppe1: right now it is like 1) let's add this feature, 2) oh man, I need to change the public API 3) I'll just push "vX" to "vX+1", then propose gainst it. at the same time, another developer could do the same.
<rogpeppe1> frankban: they could, but they would immediately be aware of a problem, because their push would fail
<rogpeppe1> frankban: i'm just concerned that your proposed workflow makes things more complex (i'm still don't understand how go get would work) and doesn't seem to address urulama's concern about version numbers that increase more frequently than necessary
<urulama> rogpeppe1, frankban: ok, what about having v2. adding changes in the development like v2.0.x, v2.0.x+1 ... for small features
<rogpeppe1> frankban: i'm suggesting that every new API version branch is created as a "development" version.
<urulama> and when we finish we either bump that to v2.1 or if change is huge, push it to v3
<rogpeppe1> urulama: i don't think that helps
<rogpeppe1> urulama: we're specifically talking about changes that break the API here
<rogpeppe1> urulama: for changes that don't break the API, we can just push to the latest version anyway
<rogpeppe1> urulama: with no need for point versions
<frankban> rogpeppe1: I share your concern about complexity of that approach, I'd just like to make the process more clear, by separating the feature branch work from the "new version release" one.
<urulama> rogpeppe1: for me v2 to v3 is a huge api change, with old api-s being depricated, not just one ...
<urulama> esp. due to the fact that they happened in bulk
<rogpeppe1> frankban: my proposal is just to have a "// DEVELOPMENT VERSION." comment in the README
<rogpeppe1> urulama: i don't quite understand. v2 to v3 was just the Reference change, right?
<frankban> rogpeppe1: yeah, what I am saying is that usually people knows that a "develop" branch in github is the development version of that project
<rogpeppe1> frankban: but if we use a "develop" branch, then we can't make it go-gettable AFAICS.
<frankban> urulama: any public API change should increase the major version number (at least if we believe in semantic versioning)
<rogpeppe1> frankban: not quite
<rogpeppe1> frankban: any *backwardly-incompatible* API changes should increase the major version number
<frankban> rogpeppe1: yeah, and that's the rule we are following now
<rogpeppe1> frankban: agreed. but i'm trying to go along with urulama's suggestion that when there's a new version and we're developing the package in response to feature development in another repository, we might not need to increase the version every time we break the API
<urulama> ^^^
<urulama> rogpeppe1: ok, is version v3d allowed?
<rogpeppe1> urulama: i don't think so
<urulama> rogpeppe1: from the short specs i thought so, needed to ask
<rogpeppe1> urulama: and anyway, i don't think we necessarily want to change the import paths when an API is published
<rogpeppe1> urulama: the way i think about that is that we "bless" a branch, and from then on we can't change it in a backwardly incompatible way.
<urulama> rogpeppe1: ok ... let's end this ... too much time :) let's mark the version as development in the docs as suggested for now
<rogpeppe1> urulama: ok, so we'll stick with v3 for the time being, and mark the v3 branch as in development
<rogpeppe1> urulama, frankban: sgty?
<urulama> rogpeppe1: at least for now ... i'll try to catch Gustavo and talk about it a bit more
<rogpeppe1> urulama: good plan
<frankban> rogpeppe1: not really, we should make v4 the first development version IMHO
<rogpeppe1> urulama: i believe we can retrospectively apply the rule here :-)
<rogpeppe1> oops
<rogpeppe1> frankban: ^
<rogpeppe1> frankban: after all, we are 99.9999% certain no-one else is using v3
<rogpeppe1> frankban: i'm in gogogo
 * urulama deletes v3 from disk ... 
<urulama> :D
<rogpeppe1> urulama: you don't count :-)
<frankban> rogpeppe1: ok, I don't have a real preference, I am just worried about clients starting to use the dev version (like charmstore) and developers keeping changing the API without releasing a new version because, you know, this is a dev version...
<rogpeppe1> i should probably have said "no other packages are using v3"
<jrwren> isn't there an open PR for juju to use v3?
<urulama> rogpeppe1: i was going for another 9!
<rogpeppe1> jrwren: actually v2, but yes
<rogpeppe1> frankban: i agree, that's definitely a potential issue.
<jrwren> Ah, v2. ok.
<rogpeppe1> frankban: let's keep an eye on that
<urulama> frankban: yes, but the only client could be core ... and we'll talk about this later today ... so. if we don't "bless" new version, it is not stable
<rogpeppe1> frankban: luckily the charm store isn't usable yet :-)
<urulama> frankban: and if it turns out to be PITA, then inc(vers) on every api break will come into practice if no better alternative exists
<rogpeppe1> urulama: when creating a new version, we'll always add a "WARNING: UNSTABLE DEVELOPMENT VERSION" to the README.
<urulama> ^^^
<rogpeppe1> urulama: so, when retargeted to v3 and with that warning added, does the charm branch LGTY?
<urulama> and if it's README.md with # prefix even
<rogpeppe1> urulama: SGTM, i think (what does the # prefix mean in markdown?)
<urulama> rogpeppe1: title
<urulama> large bold letters
<frankban> scary bloody letters
<frankban> time for a coffee... then gogogo
<rogpeppe1> frankban: ok
<rogpeppe1> urulama: i've re-pushed the branch. https://github.com/juju/charm/pull/36
<urulama> rogpeppe1: so the branch will stay at v4?
<rogpeppe1> urulama: v3
<urulama> 	 rogpeppe  wants to merge 2 commits into juju:v4  from rogpeppe:012-no-verify-on-bundle-read
<rogpeppe1> urulama: ah, i guess the PR needs to be retargetted at v3
<rogpeppe1> urulama: will retarget
<rogpeppe1> urulama: i'll make a new PR
<rogpeppe1> urulama: if you post a LGTM on the original, i think that should be good enough
<jrwren> frankban: on https://github.com/CanonicalLtd/charmstore-charm/pull/1 do you feel strongly about the file write v. writelines or can I get a LGTY?
<rogpeppe1> urulama, frankban: https://github.com/juju/charm/pull/37
<urulama> rogpeppe1: i commented on the #36 ... 
<rogpeppe1> urulama: thanks
<frankban> jrwren: just merge it, I was more interested in having unit tests, but as I mentioned, this can be done in another branch
<hatch> jujugui call in 6
<rogpeppe1> "What if we also add this in a new line? The latest stable version is v2."
<rogpeppe1> urulama: i don't understand that
<urulama> rogpeppe1: i would add "The latest stable version is v2." sentence in a new line after the warning 
<rogpeppe1> urulama: FWIW, i still think the distinction between v2 and v3 is worth it, because they are quite distinct API changes and I don't want to lump the changes for both together when changing juju-core
<rogpeppe1> urulama: ah!
<urulama> v2 vs v3 is ok
<rogpeppe1> urulama: will do.
<urulama> tnx
<rogpeppe1> urulama: LGTY otherwise?
<urulama> rogpeppe1: sure ... it's in #37
<urulama> jrwren, frankban: the details are important, I agree, but could we focus on pushing functionally working charm out, so that we can do proper testing?
<jrwren> urulama: i just pushed it and moved card.
<hatch> jujugui call in 1
<urulama> jrwren: \o/
<lazyPower> hatch: o/ 
<hatch> ahoy
<lazyPower> something i can help with still, or did you resolve it?
<jcsackett> jujugui: wifi died; i was on my phone, outside where i get slightly better signal. my connectivity today may be spotty.
<hatch> oh I resolved it - for some reason my trusty vagrant images were pulling down the juju image
<hatch> jcsackett ohh, party at your place?
<jcsackett> hatch: neighbors place. students are starting to move back into the neighborhood, but classes haven't started yet.
<hatch> ohh - are you like that guy in that movie with the frat house next door? :)
<hatch> crap now I cn't remmeber what it is called
<jcsackett> not really; they tend to be reasonable about not partying a lot late at night, we try to be reasonable about not getting grumpy other times.
<lazyPower> hatch: ah, ok :)
<hatch> lazyPower I did have a question about a charm which always pulls from HEAD being a promoted charm
<hatch> there is a thing called Stellar (you may have heard about it, a new currency)
<hatch> so I was looking at charming up stellard
<hatch> but their iterating so fast that one has to pull from HEAD
<hatch> but that unfortunately means that it's likely not stable...
<jrwren> jcsackett: do you live in East Lansing?
<lazyPower> I dont think there's a problem with the charm being configured to deploy HEAD - ideally we'd rather it be configurable so you can deploy HEAD or a revisionno.
<lazyPower> as thats pretty simple to implement. but HEAD as a default is perfectly acceptable.
<jcsackett> jrwren: i must admit i do not get your reference.
<hatch> lazyPower even as a 'promoted' charm? Because currently their get up and running guide is 'git clone, vagrant up' so it would definitely need to be promoted so it could just be `juju deploy stellard` 
<rogpeppe1> urulama, jrwren, bac, Makyo: simple PR: https://github.com/juju/charmstore/pull/59
<hatch> rogpeppe1 Makyo isn't in for the rest of the week fyi
<rogpeppe1> hatch: ah, ok
<jrwren> jcsackett: Ooops, I'm getting your geoloc confused with someone else.
<jcsackett> jrwren: dig. :)
<lazyPower> hatch: i'd have to see the charm code before i can commit to anything
<lazyPower> but wrt just deploying head - thats not a blocker. give me config options so i can configure which rev its deploying and you're g2g on that front.
<hatch> lazyPower ok cool thanks
<jrwren> pretty simple copy from old w/ tiny change to make work with new: https://github.com/juju/charmstore/pull/60
<hatch> jcsackett can you take a look at the gui CI...it looks like it's failing on every branch with a isBrowserSupported error - which is usually just a spurious one
<jcsackett> hatch: sure.
<hatch> jcsackett thanks - it's failing all over the darn place :/
<urulama_> jrwren: mayber PR #60 should be v4 API adapted first before being pushed from _old?
<urulama_> s/mayber/maybe
<jrwren> urulama_: it is. I mean, all it does is call NewServer with V4 as a parameter.
<urulama_> jrwren: sorry, missed it
<urulama_> frankban, rogpeppe1: could you please take a look at https://github.com/juju/charmstore/pull/60 so that jrwren continues?
<urulama_> frankban, rogpeppe1: sorry, I know that you are in "go go go" mode :)
<rogpeppe1> urulama_: :-)
<rogpeppe1> urulama_: yeah, we are finally free to move forward...
<bac> hi jcsackett
<jcsackett> hi bac.
<hatch> bac welcome!
<bac> jcsackett: i see ci is a mess.  are you working on it?  did you upgrade jenkins?
<jcsackett> bac: i just started looking at it, and i don't have the juju bits for it so about all i can do is check the machine itself.
<bac> it's all pertier now
<hatch> bac oh I thought that's what you did
<hatch> lol
<hatch> since the pretty update I don't think anything has landed
<hatch> well who the heck updated it haha
<bac> hatch: i *may* have.  rick and i talked about it but i can't recall exactly
<jcsackett> ah, it is indeed updated; perhaps rick did it?
<bac> jcsackett: so you can ssh.
<hatch> yeah it's been broken since the update I think
<jcsackett> yeah, i'm on the machine now.
<bac> jcsackett: ok.
<bac> jcsackett: i'm surprised the 'post build step' is not marked 'Run script only if all previous steps were successful'
<bac> jcsackett: but that's not why it is failing
<hatch> urulama so I bought parallels
<hatch> it has some cool features over fusion, but it has the same delay so it must be an ubuntu thing...
<jcsackett> hatch: so it looks like it's just failed on two branches? that may just be the spurious biting you more often than you would like.
<hatch> I can trigger them again I guess
<jcsackett> hatch: i'm running the build again.
<jcsackett> (not the merge job, just the regular test run)
<hatch> ohh ok, well I'll try and land one again, see if it's still spurious
<jcsackett> ok
<hatch> it's just odd that there were so many failures in a row
<bac> hatch: in both jobs
<hatch> right
<bac> hatch, jcsackett: what does 'git branch' -> *(no branch) mean
<jcsackett> i hadn't seen all the failures in merge; this does seem a bit odder.
<jcsackett> bac: wehre do you see that?
<bac>  from ~jenkins/workspace/juju-gui-merge
<jcsackett> huh. i have no idea.
<jcsackett> presumably it's checking something out in headless, i think?
<BradCrittenden> jcsackett: so my assumption is a) the tests pass locally b) they don't pass on jenkins because the workspace is screwed up
<hatch> *sigh*
<BradCrittenden> jcsackett: there are also a ton of branches there.  looks like we're never cleaning up.  certainly not the problem.
<jcsackett> bac: possibly
<jcsackett> ...can we just blow away the dir's contents?
<jcsackett> bac: ^ will jenkins rebuild it, since it checks stuff out?
<bac> jcsackett: probably.  there is a button to destroy the workspace on the gui
<jcsackett> votes on whether or not to give it a try?
<bac> but it would be nice to possibly figureout what is actually wrong.
<jcsackett> bac: i don't how to investigate a busted git situation properly. we could give hatch ssh access, as he's our git-ish person, i guess. :p
<bac> jcsackett: why don't you do it on the juju-gui job and not the -merge job
<jcsackett> bac: that was my plan.
<hatch> I am thinking it might be a sauce labs issue
<hatch> did they update their stuff recently?
<hatch> it always fails in chrome with the isBrowserSupported error
<hatch> http://ci.jujugui.org:8080/job/juju-gui-merge/545/console
<bac> hatch: can you run them locally?
<hatch> bac I'm not set up to run them locally - working on it but new vm and all that 
<hatch> it'l take me a while
<bac> well, if anyone can try 'make ci-check' to see
<jcsackett> what entails being setup?
<jcsackett> i have an lxc for gui, so i can thrash that, but i don't know what else needs setting up.
<hatch> http://sauceio.com/index.php/2014/07/sauce-labs-selenium-chrome-updates-august-2/
<hatch> ^ there is our issue jcsackett  bac 
<jcsackett> new version of selenium?
<hatch> it seems that way
<hatch> and new chrome and chrome driver
<hatch> which might not have the isBrowserSupported option
<bac> jcsackett, hatch: my battery is about to die and i don't have an outlet available.
<jcsackett> so, it looks like we can a) update our test suite or b) try forcing selenium version.
<bac> good night and good luck.
<hatch> bac ok we can take over, have a good night
<jcsackett> bac: night dude.
<hatch> yeh lets force it to use the old version
<hatch> we are low on man power this week so lets just get it up and running and we can investigate the fix next week or so
<jcsackett> ok, where's our selenium config in the tree?
<hatch> I thought you knew? :P
<hatch> browser.py maybe...
<jcsackett> hatch: ok, i'll dig into this.
<hatch> thanks
<hatch> chrome keeps blacking out when I drag the window in Ubuntu, looks like I'm switching to Firefox
<rogpeppe1> jrwren: for future reference, we don't push the big green button to merge branches into the charm store
<rogpeppe1> jrwren: instead, add a comment with the sacred rune :shipit:
<rogpeppe1> jrwren: (we missed a few issues from your PR, which doesn't actually build correctly, unfortunately)
<hatch> its the shibolith 
<jrwren> rogpeppe1: yeah, i realized ci system does it AFTER I pushed that tempting shiny green button.
<rogpeppe1> jrwren: https://github.com/juju/charmstore/pull/61
<jrwren> rogpeppe1: ah, i missed adding the old config.go, which is what I was going to do. #fail.
<kadams54> Anyone know if the pending attribute on a Service is a reliable indicator of uncommitted/ghosted state?
<kadams54> guihelp: ^
<hatch> kadams54 it will be being changed to be isUncommitted or something 
<hatch> so that everything can use the same key
<kadams54> Can I use it as is?
<kadams54> Or rather, what's the best way currently to know, within a Service instance, if it's in an uncommitted state?
<hatch> yeah I believe so
<hatch> best is to test it though
<kadams54> yup
<hatch> jcsackett hey any luck with the CI?
<jcsackett> hatch: i think so--browser.py was indeed the place to set things, and i've gotten to a state where i can replicate the error locally. i'm locally testing the fix.
<jcsackett> or i guess "a fix" since i don't know if it works yet.
<hatch> excellent
<hatch> thanks for doing this!
<hatch> ugh still downloading the precise charm repo
<hatch> this thing is massssssive
<hatch> make that the trusty charm
<jrwren> you did a getall?
<hatch> I followed the instructions
<hatch> bzr branch lp: ....
<hatch> :)
<jrwren> i wonder if that is why the juju charm tools has getall.
<hatch> jcsackett so.....diditwork?huhhuhdidit?didithuh?
<jcsackett> hatch: no.
<jcsackett> hatch: it creates a new error.
<hatch> *sadface*
<jcsackett> it just flat out aborts, claiming the settings conflict with firefox. since the update post only references chrome, i'm trying it only setting the selenium version for chrome, and leaving firefox alone.
<jcsackett> given they test such an old v of firefox by default, perhaps they're pinning an older version of selenium for it.
<jcsackett> ...and i just got the results back, and it fails that way.
<jcsackett> ok, i need to read more docs to figure out why setting selenium breaks firefox; b/c clearly the old version *was* working for it once upon a time.
<hatch> jcsackett ok darn, anything I can do to help
<hatch> ?
<jcsackett> hatch: i'm beginning to think this isn't about selenium.
<hatch> no? because it seems to happen in the exact same space with the same error
<jcsackett> well, it's an error on selenium tests, sure.
<hatch> and the only changes I can see are the ones from sauce
<kadams54> jujugui: looking for reviews and QA on: https://github.com/juju/juju-gui/pull/480
<jcsackett> hatch: right, but the chrome change isn't the issue (b/c the error occurs on firefox) and it's starting to look like firefox was already using a diff selenium version.
<jcsackett> hatch: i haven't got concrete proof yet. just sharing my suspicions.
<hatch> hmm right I suppose - but didn't they also change the selenium version across the map? 
<hatch> are we using a version of FF that's too old? Maybe we should update it
<hatch> kadams54 review done
<hatch> I'll hold off on QA until you respond to the comments
<jcsackett> hatch: we're using version 25; not too old, but as long as i'm in here i can bump it to 30 (the current stable)
<jcsackett> er, 32
<jcsackett> dammit, i can't type.
<jcsackett> 31.
<jcsackett> there.
<hatch> haha
<hatch> jcsackett so the method isBrowserSupported is defined in the index.html file - as you can see in the saucelabs vid https://saucelabs.com/jobs/9b4a430af5744fd68fbbbea228b5838c the GUI is loaded so there should be no reason why that method is not defined
<jcsackett> hatch: yeah.
<hatch> unless of course there is a syntax error
<hatch> you were able to run it locally? Was there such error?
<kadams54> hatch: thanks. Replies posted.
<jcsackett> i think firefox 25 may just load a selenium version that is > 2.30.0 and < the new default.
<hatch> jcsackett I wonder if there was a change in chrome where it doesn't auto assign the isBrowserSupported to window if it's a global
<hatch> maybe try changing it to window.isBrowserSupported = ...
<jcsackett> hatch: the error is occuring in firefox.
<jcsackett> so it's not a chrome specific issue.
<hatch> oh? FF is passing fine in the latest CI run
<jcsackett> well great, then i'm not able to actually recreate what CI sees.
<hatch> kadams54 thanks, i'll qa shortly
<hatch> jcsackett http://ci.jujugui.org:8080/job/juju-gui-merge/545/console FF passes just before it fails in Chrome
<jcsackett> so, locally ff fails in the same way.
<jcsackett> well, "locally"
<hatch> well then...
<hatch> jcsackett so you set the selenium version back to 2.30.0? (just trying to get up to speed) 
<jcsackett> hatch: i have:
<jcsackett> 1) set the selenium version to 2.30.0, with the result that firefox tests abort b/c the selenium version is too old for the firefox and os version.
<jcsackett> 2) set the selenium version for *just* chrome, with the result that firefox fails on the isBrowserSupported thing.
<jcsackett> i am currently:
<jcsackett> 1) trying to isolate what version between 2.30.0 and 2.42.0 will actually work.
<hatch> *sigh* sorry this sucks
<jcsackett> yeah.
<hatch> lemme know if I can assist in any way
<jcsackett> and i'm basically a monkey hitting this with a branch to see what happens.
<hatch> lol
<jcsackett> i'm not really sure how i became backup CI guy. :p
<hatch> you touched it once
 * kadams54 makes a note to NEVER touch the CI server.
<jcsackett> i didn't, actually. :p i touched other CI stuff.
<hatch> jcsackett maybe it's something dumb as upping the timout from 20-30s on wait_for_script ?
<jcsackett> maybe, but i don't understand why that would come up now.
<jcsackett> i'll put it on my list of places to hit CI with a branch, though.
<hatch> sounds good :)
<hatch> jcsackett the other thing you could do is put a hook in there so you can pause it and check the window obj yourself
<kadams54> Maybe the problem is you're hitting it with a branch when you should be threatening it with an RPG.
<hatch> to see if all of our defined methods aren't there
<hatch> haha
<jcsackett> kadams54: this is not planet of the apes. monkeys don't have RPGs. :p
<jcsackett> hatch: how do i look at this through a hook, since it's being run by sauce?
<hatch> jcsackett it'll send u a url
<hatch> you can visit that url
<jcsackett> ah, ok.
<hatch> then click on it to take over
<hatch> or something along those lines
<jcsackett> just so i'm not really being stupid, is there any setup required for `make ci-check` to work?
<jcsackett> i read the docs, and it didn't say anything about preconditions.
<jcsackett> hatch ^ ?
<hatch> jcsackett well you need to have the dependencies installed but that's it
<jcsackett> ok.
<hatch> running into an issue?
<hatch> kadams54 some qa notes
<jcsackett> hatch: are you in a position to run ci-check?
<jcsackett> i just want to see if you see ff failing for you, outside of CI.
<hatch> I'm getting close to being
<hatch> jcsackett probably 15-20mins I can
<jcsackett> ...ok, nevermind. nothing will ever work on my setup, b/c i don't have sauce connect installed. this is the sort of thing i was looking for insofar as "other prep"
<jcsackett> :p
<hatch> I didn't think you needed sauce connect unless you were behind a firewall
<hatch> if it is indeed required it should be added to the hacking docs
<jcsackett> i think, by default, lxc's and vms are bridged.
<jcsackett> which is effectively a proxy.
<hatch> ok i'm trying to run it
<hatch> and it failed...
<hatch> heh
<hatch> hmm
<hatch> oh missing pkgs
<hatch> ok it appears to be runnin gnow....
<jcsackett> hatch: if you see only chrome failing, i'll tell you how to set selenium version for just chrome.
<hatch> ok it got most of the way through then ran into more missing pkgs
<jcsackett> :p
<hatch> not sure how long this will take if this keeps happening lol
<hatch> and agian!
<jcsackett> ok, i've gotten sc running, so i'm trying again.
<hatch> excellent I'm still running into dep issues
<hatch> i'll let you know when I get somewhere on it
<jcsackett> ok, *with* sc running, still FF failure.
<jcsackett> i have no idea now.
<jcsackett> i can't actually make saucelabs work from my lxc.
<jcsackett> this would have been good to know hours ago. :p
<hatch> lol
<hatch> time to spin up an ec2 instance
<jcsackett> which is a thing to do tomorrow, as there's no way i'll get that working before EoD.
<hatch> it's running here
<hatch> I think...
<hatch> in FF
<hatch> will see if it fails
<hatch> yup it fails
<hatch> ^ jcsackett 
<jcsackett> hatch: hit the url saucelabs gave you and make sure you're not seeing a lack of connection issue.
<hatch> trying
<hatch> apparently I need flash
<hatch> jcsackett oh I'm getting connection refused in the vid but the console is saying isBrowserSupported error
<jcsackett> hatch: yeah, that error is a lie.
<jcsackett> it's what errors when the test doesn't work.
<jcsackett> period.
<jcsackett> so: tomorrow morning i'll spin up ec2 and try there.
<hatch> I'll try with sauce connect
<hatch> oh wait
<hatch> that requires a ton of setup
<hatch> ok forget it
<jcsackett> yeah, we're blocked for tonight.
<jcsackett> unless you're going to bring up ec2 tonight--i don't have time to work post EoD today.
<hatch> I still need to get this release out :)
<hatch> hopefully
<jcsackett> this doesn't block release, right?
<hatch> I don't think so - I do need the tests to run
<hatch> but Makyo  was running into a different error
<hatch> so we'll see :)
<hatch> Trusty charm release has already been done
<jcsackett> hatch: if you get to a point where you want to monkey with selenium issue, https://github.com/jaycee/juju-gui/blob/set-selenium-version/test/browser.py#L125
<jcsackett> that's how you set it.
<jcsackett> i've gotta to go start making dinner.
<jcsackett> i'll continue on this tomorrow morning, barring any news.
<hatch> jcsackett ok thanks
<hatch> I'll email with news (if any)
<jcsackett> cool.
<jcsackett> have a good evening. :)
<hatch> u 222
<hatch> morning huwshimi 
<huwshimi> Morning
<hatch> so CI is all sorts busted
<hatch> that's why your stuff hasn't landed
<huwshimi> hatch: Ah right, I was wondering what was going on :)
<hatch> hopefully that won't block you too much
<huwshimi> it's all good
<hatch> huwshimi have you seen GSS ? 
<huwshimi> hatch: What's that?
<hatch> http://gridstylesheets.org/
<hatch> there is a video which does a better job of explaining it, but it's using a different type of language and interpreter to do page layout than CSS
<huwshimi> Oh yeah, I think I did see that
<hatch> it's pretty cool - CSS can't get any worse so I'm all for something new :)
#juju-gui 2014-08-07
<rogpeppe1> urulama: hiya
<urulama> rogpeppe1: morning
<rick_h__> morning party people
<rogpeppe1> rick_h__: yo!
<urulama> rogpeppe1: you're early today :)
<rogpeppe1> urulama: it happens :-)
<bac> rick_h__: ci is still dead, presumably selenium related.  did anyone send you an update yesterday?
<rick_h__> bac: no, writing an email now and have a run to see if we found the problem
<bac> rick_h__: you going to boardroom at 9:30
<rick_h__> bac: yes, the text based UI stuff?
<bac> y
<rick_h__> jujugui - email sent to peeps on CI issue, working branch has run through tests but is not fit for landing
<rogpeppe1> frankban: gogogo?
<frankban> rogpeppe1: sure, I'll be there in a minute
<urulama> morning frankban
<frankban> hi urulama 
<urulama> frankban, rogpeppe1: how's "publish" going?
<rogpeppe1> urulama: not bad. overwhelmed with overhead yesterday, but back onto the meat of it today. just the tests to write now.
<urulama> nice
<frankban> rogpeppe1: http://pastebin.ubuntu.com/7978769/
 * frankban lunches
 * jrwren coffees
 * urulama dreams of unicorns 
<rogpeppe1> urulama: https://www.youtube.com/watch?v=KPA1fH9wZIg
<frankban> rogpeppe1: gogogo?
<kadams54> jujugui: Morning all. Before I start another card, I thought I'd check to see if anyone's looking at CI and what, if anything, I could do to help.
<jcsackett> kadams54: i am still looking at CI, pursuing the selenium-version issue jeff identified yesterday.
<jcsackett> kadams54: if you are able to run make ci-check, and can actually see tests running via the selenium console (follow the url provided by make ci-check), then we might be able to speed things up.
<jcsackett> kadams54: wait, you're running a vm, right?
<jrwren> what is gogogo?
<kadams54> Something impatient people type before an match of League of Legends starts?
<kadams54> jcsackett: yes, though I can also see if I can get a dedicated Ubuntu machine up and running. It's something I've been meaning to do for awhile.
<jcsackett> kadams54: yeah; sauce and the machine running the tests need to be able to talk, which has been the source of our slowdown. both vms and lxcs (and anything on my home network, since timewarner is blocking the port i need) fail; i've got an ec2 machine coming up now, which is probably faster than you spinning up a dedicated ubuntu machine.
<rogpeppe1> frankban: indeed. i missed your ping, sorry
<jrwren> kadams54: LoL doesn't glhf?
<kadams54> Game starts in 5â¦ 4â¦ 3â¦ 2â¦gogogogogogogogogo
<kadams54> But yes, glhfs are out there too.
<jrwren> I see.
<bac> jcsackett: \o/
<jcsackett> bac: ?
<rick_h__> jcsackett: your branch/fix
<jcsackett> i may have been premature.
 * jcsackett is crossing his fingers that it does actually work in CI.
<jcsackett> save the hoorays for when it passes. :p
<jcsackett> ...and it just failed.
<rick_h__> jcsackett: what do you think of the removal in my reply?
<jcsackett> rick_h__: haven't seen your reply yet. 1 sec.
<jcsackett> rick_h__: so, the browser warning bit is about handling us popping up the "gui doesn't work on your browser" thing. i think if we remove the handle stuff, and that's the failure, we'll have a hard time sorting that out.
<bac> jcsackett: ok, i retract my whoo-hoo.  doesn't look like it did anything.
<jcsackett> bac: indeed not.
<rick_h__> jcsackett: but we'd have the sauce video that shows it?
<bac> s/did/fixed/
<rick_h__> jcsackett: e.g. in the video we see a browser warning for a browser that should have no warning?
<jcsackett> rick_h__: that's true, i suppose. it just doesn't feel good to me, but i'm happy to be overruled, if only to get back to the card iw as working on before. :p
<jcsackett> incidentally, there seems to be no way to run ci-check appropriately. at least not documented.
<rick_h__> jcsackett: you know our code has the isBrowserSupported function?
<rick_h__> in index.html?
<jcsackett> rick_h__: yes.
<hatch> it's a very odd issue, the GUI is rendered but it can't access the fn
<hatch> you can actually see the canvas and everything but it says the fn doesn't exist
<jcsackett> as i said, "isBrowserSupported" not being found is not actually the error. if you run ci-check without even being able to make the connection to sauce labs, you see isBrowserSupported being the failure.
<jcsackett> the failure message is useless.
<hatch> right - there is a bigger problem - because when CI fails with that error the GUI IS loaded
<rick_h__> call guys?
<rick_h__> hangout room?
<hatch> sure
<jcsackett> rick_h__: sure, one sec.
<hatch> jcsackett rick_h__  so yeah the isBrowserSupported method IS definitely there
<hatch> http://ci.jujugui.org:8888/ < jcsackett 
<jcsackett> everyone cross your fingers
 * urulama has problems typing now
<rick_h__> hatch: cool
<hatch> jcsackett interesting...in FF on OSX window.isBrowserSupported() is returning false
<jcsackett> hatch: google-chrome on linux is returing false as well.
<jcsackett> hatch: so, there's something else going on.
<jcsackett> b/c we're setting 2.30.0 for chrome on this thing and it's still dying.
<hatch> jcsackett oh you need to pass it `navigator.userAgent`
<hatch> at which point it works correctly
<hatch> jcsackett trigger another manual ci run, once the GUI is loaded open it in chrome and type `window.isBrowserSupported(navigator.userAgent)`
<hatch> chrome on ubuntu that is
<jcsackett> hatch: yeah, i saw that too.
<jcsackett> still, chrome, with the supposedly correct version of selenium, still fails.
<jcsackett> could be the new version of chromedriver/chrome
<jcsackett> in which case, we have to fix our test. b/c that would mean it just doesn't work on the latest version of chrome.
<hatch> right - but can you check to make sure the fn executes correctly? I'm wondering if it's not the driver that we are using....if the method is indeed there (Which I'm pretty sure it is) then it's the python driver not being able to send the proper command
<hatch> jcsackett we could also change that test in python to test for something that WILL be there like Object for example
<hatch> if it sill fails then we know for sure it's the driver
<jcsackett> hatch: there's a build running now; when it gets to the selenium bit i can see if it works.
<jcsackett> hatch: oh, as far as method being there, i can confirm that for sure.
<hatch> ahh ok
<hatch> brb 
<jcsackett> hatch: i just called it without the agent bit and it returned false. but it's there.
<hatch> and with the agent?
<hatch> ok so next thing to try is modify the browser.py to try and execute something that is DEFINITELY there :)
<hatch> jujugui call in 10, kanban now
<jcsackett> hatch: it works fine.
<hatch> jcsackett well what the deuce.....
<hatch> that doesn't make any sense....
<jcsackett> hatch: none of this makes sense.
<jcsackett> i'm going to try getting an earlier rev of develop to pass through--one that passed before the sauce changes.
<hatch> sure 
<hatch> jcsackett so what if we remove that test? Does it pass then or do other things fail?
<jcsackett> if we remove *every* call to handleBrowserWarning, it passes, as you can see in rick's branch.
<jcsackett> but, y'know. there's a reason we're checking on the browser warning stuff.
<hatch> yeah - if we supported IE11 we could drop it...
<jcsackett> hatch: i'm verifying the chromedriver thing by running a build that uses the old default chrome and chromedriver.
<hatch> ok excellent
<jcsackett> if that passes, i think the critical situation is over--we land that branch and add a card for investigating CI on chrome 35+
<jcsackett> b/c previously we've been running everything on the old default anyway, so we're not in any *worse* of a position.
<jcsackett> and we're unblocked. but we definitely don't want to be stuck on an increasingly old version of chrome.
<hatch> right - *crosses fingers*
<jcsackett> well, good news: my incidental upgrade to ff 31 passes.
<jcsackett> not the good news we want, but good news all the same.
<hatch> haha need every ittle win
<jcsackett> PASSED!!!
<jcsackett> well, the first test.
<jcsackett> but the first test was failing.
<hatch> ...
<jcsackett> so, this is looking good.
<hatch> ......
 * hatch is in suspense 
<jcsackett> passed the second one.
<jcsackett> chrome has passed.
<jcsackett> the new chrome/chromedriver is the issue, and this unblocks us.
<hatch> *phew*
<jcsackett> i'll tidy up the PR and ask for reviews, and make a card to investigate new chrome on CI.
<hatch> ok ping when it's up and I'll +1 it
<hatch> :)
<hatch> jcsackett can you also send out an email to peeps with the details?
<jcsackett> hatch: already writing it.
<hatch> u da man
<jcsackett> jujugui: 2 reviews, please. https://github.com/juju/juju-gui/pull/484
<hatch> on it
<kadams54> Ditto
<frankban> jcsackett: done
<jcsackett> thanks, all.
<hatch> jujugui I'll handle getting everything landed once this lands
<kadams54> hatch's new job title: PR Wrangler
<hatch> yeeeee haw
<kadams54> Excuse meâ¦ PR Herder
<kadams54> https://www.youtube.com/watch?v=1SmgLtg1Izw
<hatch> not sure what sound herders make
<kadams54> Yeeee haw is appropriate.
<hatch> dig
<jcsackett> wtf; something else just failed.
<hatch> looks to still be running...
<hatch> http://ci.jujugui.org:8080/job/juju-gui/1565/console
<jcsackett> hatch: that's the run triggered by comments.
<jcsackett> hatch: the run with the test change failed, but i think it's the spurious failure. we'll see what the comments one does.
<hatch> ohh that's a spurious failure
<hatch> yeah
 * jcsackett lets out a breath
<jcsackett> thank god.
<hatch> haha
<hatch> jcsackett pm me the email you want to use for KB
<rogpeppe1> urulama, jrwren: https://github.com/juju/charmstore/pull/62
<rogpeppe1> frankban: ^
<urulama> rogpeppe1: TBH, my brain is not capable to do PR right now ... in a few hours i can do it
<frankban> urulama: np, thanks
<frankban> rogpeppe1: we missed one test: wrong hash provided
<rogpeppe1> frankban: ah yes. good point.
<frankban> rogpeppe1: and actually it seems the check is not done by PutForEnvironment
<rogpeppe1> frankban: ah
<frankban> rogpeppe1: I was able to upload a charm using something like "curl -ikL --data-binary @$2 -H "Content-Type: application/zip" http://127.0.0.1:8080/v4/$1/archive?hash=ciao"
<rogpeppe1> frankban: ah, of course. PutForEnvironment doesn't know the hash that it's meant to be uploading
<rogpeppe1> frankban: hmm
<rogpeppe1> frankban: that means that we can't actually use juju/blobstore without changing it
<rogpeppe1> frankban: good catch. darn.
<rogpeppe1> frankban: at the least, we could change PutForEnvironment to return the actually created hash
<rogpeppe1> frankban: or to have an optional hash passed in that it could check
<frankban> rogpeppe1: yeah, I am surprised this check is not done already somewhere in managedstorage
<frankban> rogpeppe1: so, if the path and the hash are two different concepts in blobstore, it would be nice if we are able to inject a checker into PutForEnvironment. If PutForEnvironment to returns the actually created hash, that means for each blob with invalid hash we write it to mongo and then delete it. Providing an expectedHash seems specific to our use case at this point.
<rogpeppe1> frankban: yes
<hatch> heyyal what are you using in Ubuntu for irc? Quassel looks like a good candidate 
<jcsackett> in unity? xchat. otherwise weechat.
<hatch> yeah in Unity
<hatch> xchat is just so ugly
<hatch> :)
<lazyPower> hey hatch - gimme some PeerReview? http://askubuntu.com/questions/507521/juju-charm-relation-hooks-are-not-running/508158#508158
<hatch> lazyPower on it
<hatch> I already did
<hatch> see that upvote
<hatch> <---- this guy
<hatch> :D
<lazyPower> haha
<lazyPower> niiiiiice
<hatch> now I know why the charm reviews take so long - your busy writing proper AU responses :P
<lazyPower> :)
<lazyPower> i've had a slew of people contacting me privately in email for help. I'm redirecting them to AU for public knowledge
<frankban> rogpeppe1: something like http://pastebin.ubuntu.com/7981133/ ? It's bad that in that case we'd need to modify the ManagedStorage interface
<jcsackett> hatch: i change the color scheme; there are various themes.
<hatch> jcsackett have you used quassel? It really does look nicer 
<hatch> :)
<hatch> lazyPower excellent idea
<lazyPower> Quassel for the win. love it.
<lazyPower> use it on my phone, tablet, desktop, laptop
<hatch> android?
<jcsackett> hatch: it's a kde app, though, so the icons don't match up with everything else. or at least they didn't last time i installed it.
<hatch> or utouch
<lazyPower> droid. i dont see a utouch app for it.
<hatch> jcsackett ohh, I'll have to check, I bought the numix gtk3 light theme
<hatch> so it comes with a slew of icons
<hatch> still can't figure out why the unity dash takes so darn long to open
<hatch> when the task-search one is instant 
<hatch__> Yeah you're right the icons don't match at all heh
<jcsackett> yeah.
<jcsackett> these days i'm a big fan of weechat.
<jcsackett> but that's a terminal app, and if you're using unity, it doesn't integrate with the messagemenu at all, which is vexing.
<jrwren> irssi 4 life.
<jrwren> I may or may not have that tatoed on my person.
<hatch> lol, on your neck probably, amiright?
<rogpeppe1> frankban: i wouldn't make the checkers so general. i'd just pass in an expected hash
<rogpeppe1> frankban: which can be checked immediately after preprocessUpload
<frankban> rogpeppe1: and if empty the check is not done?
<rogpeppe1> frankban: yes
<frankban> rogpeppe1: that would work, sure
<rogpeppe1> frankban: perhaps a *blobstore.ResourceHash
<rogpeppe1> which is nil if the check isn't done
<hatch> spurious test failure....ugh.....I swear these branches will land eventually!
<hatch> can someone ping  juju gui and gui help for me so I can test my new alerts
<frankban> rogpeppe1: we will need a blobstore.v2 :-/
<rogpeppe1> frankban: well, blobstore isn't gopkg.in, so i guess it can just change in place
<kadams54> jujugui guihelp
<kadams54> guihelp
<hatch> well they highlighted but no ding or notification
<hatch> thanks kadams54
<hatch> guess I'll have to look into that
<frankban> rogpeppe1: well, my point is that we should put in gopkg.in. otherwise I'm not sure about when dependencies should be versioned and when not
<rogpeppe1> frankban: i agree.
<rogpeppe1> frankban: let's just call it v1
<frankban> rogpeppe1: sure, done for the day, have a nice night
<rogpeppe1> frankban: g'night
<hatch> man I'm having no luck with this charm release - I keep getting huge diffs which cause things to fail hard
<hatch> jujugui does anyone else want to take a stab at making the precise charm release? 
<hatch> jujugui anyone know how I undo a merge in bzr? I havent committed but I want to reset it to HEAD
<hatch> revert
<hatch> found it :)
<hatch> python ppl, what would cause the charm `make lint` to fail with a compiler error from pip?
<hatch> says no Python.h ?
<hatch> ^ jujugui
<jrwren> missing python-devel package
<kadams54> python-dev not installed
<hatch> thanks
<hatch> so....why does something in lint require building python from source?
<hatch> ok here is a new one
<hatch> python/apt_pkgmodule.h:14:28: fatal error: apt-pkg/hashes.h: No such file or directory
<jrwren> did you run make sysdeps?
<hatch> negative
<hatch> that's not in the instructions lol
<hatch> will try that
<kadams54> I suspect make lint is running a python library, which needs it and all its dependencies downloaded, optionally compiled, and installed.
<jrwren> make sysdeps would have installed a bunch of debs for you, including libapt-pkg-dev (which gives that missing file)  and would have got libpython-dev too.
<hatch> sounds like we should be including the compiled versions
<hatch> but hey lint passed
<hatch> kadams54:  hey any luck on that truncation stuff? 
<kadams54> hatch: no, though to be honest I kinda forgot about it and was starting on the other card.
<kadams54> Which reminds me that I was going to check in with you on what you'd found.
<hatch> yeah so this is actually a pretty large issue with how the callbacks are executed
<hatch> because we are creating 'ghost' models then removing them and allowing the new ones to be created via the delta
<hatch> the time between there there is no model and as such, no UI
<hatch> so the proper fix is to have the delta update the appropriate models instead of removing it
<hatch> which is an architectural change to how the ecs/env handles it now
<hatch> the other approach (which I don't like as much) is to wait until the delta comes in then remove the old one and create a new one
<hatch> kadams54:  that match the direction you were working on already?
<kadams54> Sure
<kadams54> ;-)
<kadams54> Why would you rather update than remove and re-create?
<kadams54> updating seems like asking for stale data
<hatch> there is a lot of infrastructure attached to the existance of the record
<hatch> so when they go away/come back lots of things happen
<hatch> at scale that could cause the thread to lock up
<kadams54> k
<kadams54> any gotchas?
<hatch> probably....it's the ecs/env
<hatch> :P
<hatch> that's as far as I got - it's a pretty big change - the env has used the same callback system since day one
<hatch> now we are changing it
<kadams54> ha haâ¦ *sobs
<hatch> if you like you could defer that to either frankban or i
<kadams54> i may
<hatch> or matt, I think he is back monday
<rick_h__> hatch: why don't you like doing the callback on seeing the new item?
<hatch> rick_h__:  that's not how it works, atm the callback is fired when juju says "yep I hear ya" we need to wait until the delta comes in then act
<rick_h__> hatch: right, but you mention you're not a fan of waiting for the delta to do the callback?
<hatch> sorry I meant that I didn't want to remove the old model and create a new one vs just updating the old one
<hatch> (after re-reading I see that wasn't clear)
<hatch> both approaches require acting when the delta comes in vs the OK from juju
<rick_h__> kadams54: definitely feel free to delay on it if you want. 
<rick_h__> hatch: right, we need to do some adjustment for sure.
<hatch> I THINK I've finally got the charm tests to pass successfully 
<hatch> will see in a bit :)
<rick_h__> charm tests? woot?
<rick_h__> what blew up the charm tests?
<hatch> for the precise release
<hatch> no idea....there were a ton of changes causing conflicts and whatnot - I emailed Matt to find out why there were so many changes
<hatch> but he is off so will have to wait to see
<hatch> I won't push it until I hear back though
<rick_h__> ok
<kadams54> hatch, rick_h__: OK, taking a different card
<hatch> LP even shows commits without diffs which is very odd
<hatch> so something got borked up real good
<hatch> somehow
<hatch> rick_h__:  good news is that CI is back up and running though 
<rick_h__> hatch: saw that, thanks for the work on that + jcsackett 
<hatch> it was mostly jcsackett - I was the monkey poking the other monkey with the stick
<hatch> I was *just
<hatch> :)
<rick_h__> :P
<hatch> *sigh* I spoke too soon the test failure for the precise charm is still there....
<rick_h__> hatch: if you're not sure what's up don't force it. A few more days to figure out the charm won't hurt. Maybe also lean on frankban if he's around tomorrow
<hatch> yeah I think I might do that - it's very odd because the code is identical between precise and trusty but precise is the only one which is failing
<hatch> I'll fire him an email, hopefully he will have some better luck - I would like to get some real work done :) 
<hatch> everyone should be on trusty anyways.....right?
<hatch> :)
<lazyPower> hey hatch, you got a minute?
<lazyPower> i'm getting a really strange error from the GUI about the bundle not being a zip file
<lazyPower> and i'm not sure if this is gui or deployer
<lazyPower> http://paste.ubuntu.com/7982560/
<lazyPower> but that bundle looks perfectly acceptable
<lazyPower> nevermind, looks like the charms weren't ingested yet
<hatch> lazyPower:  sorry stepped away for a sec
<lazyPower> its cool, we discovered the root of all evil is ingest
<hatch> yeah it's pretty horrible
<hatch> :)
<rick_h__> but it's going to go away so yay! :)
<hatch> haha
<hatch> jcsackett:  hey you use github hub right? Do you like it?
<hatch> doesn't look like anything quite beats the functionality of GRB
<jcsackett> hatch: i am a huge fan of hub.
<hatch> jcsackett:  so I frequetly use `grb create` and `grb delete` which creates a local branch, pushes it to the remote, and then tracks it
<hatch> the latter of course undoing that but only deleting the local if the source has been merged
<hatch> does hub have anything like that? it doesn't appear so
<jcsackett> not really, no.
<jcsackett> but hey, aliases.
<hatch> yeah, so what does hub give you that makes you be a fan?
<hatch> like what features do you find very useful
<jcsackett> hatch: git checkout $pullrequesturl
<jcsackett> it also just cleans up a lot of commands so it's easy to work with github style repos.
<jcsackett> also git pull-request -b develop -m "message"
<hatch> ahh yeah that one would be helpful
<hatch> hmm I'll have to give it a try
<huwshimi> Morning
<hatch> morning huwshimi
<hatch> CI is back up and running
<huwshimi> yay!
<hatch> huwshimi:  so how goes the x uncommitted branch?
<hatch> it's been hanging in starting for a while :)
<hatch> kadams54:  hey I also have input on your card in starting :D
<huwshimi> hatch: Yeah, that's because I keep starting other things because it's annoying
<hatch> haha - ok it's just been sitting there so haven't had anything to say in the standup
#juju-gui 2014-08-08
<hatch> huwshimi: I'm going to powerdown, need anything before I do?
<huwshimi> hatch: I think I'm good for the moment
<huwshimi> thanks
<hatch> okee have a good weekend
<rogpeppe1> mornin' all
<rogpeppe1> urulama: hiya
<huwshimi> rogpeppe1: Morning
<rogpeppe1> huwshimi: hiya
<urulama> rogpeppe1: hi
<urulama> rogpeppe1: trying to do the review, but get NMIs alll the time :)
<rogpeppe1> urulama: :-)
<rogpeppe1> urulama: you need to sort out your processor architecture
<urulama> rogpeppe1: yes, a stone brick model looks good
<urulama> rogpeppe1: i am still a bit puzzled about the UploadCharm/Bundle func and the need for it ... archive.go has it's own methods, which do not use Upload* functions but archive_test does ... 
<rogpeppe1> urulama: it's so that tests can create charms with known URLs, without going through the v4 API upload mechanism
<rogpeppe1> urulama: (which will get considerably more complex if we add challenge-response stuff)
<rogpeppe1> urulama: for example, all the tests in api_test.go use it
<rogpeppe1> urulama: it means that those tests can be independent of the API upload logic
<urulama> rogpeppe1: exactly, i'm just saying that tests are there and provide feeling that all is fine, but that might be false positives ... maybe noting in archive_test.go that, would be useful ... 
<urulama> rogpeppe1: all clear on why the funcs are there and why used, just saying, that we need to make sure that we do not end forgetting about proper archive tests
<rogpeppe1> urulama: the only archive test that uses UploadCharm is TestArchiveGet
<rogpeppe1> urulama: that's because it was written before the API upload code existed
<rogpeppe1> urulama: it should probably be changed to use the API upload, i guess, as it's part of that suite
<urulama> yes. that's what i was asking.
<urulama> i'll make a note
<rogpeppe1> urulama: ah, ok. you used plural tests, which i took to mean you thought all the archive tests suffered from that issue
<urulama> rogpeppe1: sorry, my head is a bit of a jello after these weeks :)
<rogpeppe1> urulama: np at all
<rogpeppe1> urulama: hope it's all gone ok
<urulama> rogpeppe1: extremely well, i think
<rogpeppe1> urulama: good to hear
<urulama> rogpeppe1: so, now that nothing uses store.UploadCharm and is not part of store_test.go ... could we move UploadCharm/Bundle to test code?
<urulama> rogpeppe1: or do we expect those to be useful in the future?
<rogpeppe1> urulama: api_test.go uses UploadCharm
<rogpeppe1> urulama: that's in the v4 package
<rogpeppe1> urulama: and i think it's useful for it to be independent of the API upload mechanism
<rogpeppe1> urulama: as you can probably see from the code, UploadCharm uses almost the same code paths as AddCharm - it just creates the blob as well as adding the entry
<urulama> rogpeppe1: ok, thinking about the names of the api. Code (functional point of view) is ok. ... Add* (adding just entry in db) and Upload* which is Add+blob ... feels redundant in a way ... not saying that it's wrong. Just feels redundant or that naming is wrong.
<rogpeppe1> urulama: yeah, you have a good point there.
<rogpeppe1> urulama: AddCharmWithArchive ?
<urulama> better by all means
<rogpeppe1> urulama: will change it
<rogpeppe1> "I really don't like the magic "blobhash" undocumented string here."
<rogpeppe1> urulama: did you delete that comment?
<urulama> rogpeppe1: i did
<rogpeppe1> urulama: ah, ok
<urulama> rogpeppe1: we use .series in referece to indicate it's a bundle?
<rogpeppe1> urulama: yes
<urulama> rogpeppe1: wouldn't it be cleaner if there would be a .type attribure?
<rogpeppe1> urulama: we discussed this quite a while ago
<urulama> rogpeppe1: before my time or in my time?
<rogpeppe1> urulama: hmm, perhaps a little before your time
<urulama> rogpeppe1: ok, so it's an agreement with core?
<rogpeppe1> urulama: yes
<rogpeppe1> urulama: by using series, we have a nice way of representing the "bundle-ness" of a url in the url itself
<urulama> ok. 
<urulama> fine
<rick_h__> except for the flat namespce which could be either?
<rick_h__> namespace
<rogpeppe1> rick_h__: that's true. but we wouldn't be able to tell then anyway. it's just like resolving other aspects of the charm or bundle url
<rick_h__> rogpeppe1: yea, nvm
<frankban> rogpeppe1: how is it going?
<rogpeppe1> frankban: just running the tests on the juju-core charm.v2 change before attempting to land it again...
<rogpeppe1> frankban: and making requested changes to our charmstore PR
<rogpeppe1> frankban: not bad altogether
<rogpeppe1> frankban: you?
<frankban> rogpeppe1: I have a branch ready for the serveArchiveFile endpoint. Waiting for changes on our charmstore branch, looking at the review
<rogpeppe1> frankban: nice!
<rogpeppe1> urulama: have you finished your review?
<rick_h__> rogpeppe1: he ran to lunch
<rick_h__> rogpeppe1: will poke him when he's back
<rogpeppe1> rick_h__: np
<rogpeppe1> rick_h__: i'm not really expecting much activity, just a faint hope :-)
<rogpeppe1> frankban, jrwren, dimitern, TheMue: https://github.com/juju/blobstore/pull/12
<dimitern> rogpeppe1, looking
<rogpeppe1> dimitern: thanks
<dimitern> rogpeppe1, first impression: you need a better PR description :)
<rogpeppe1> dimitern: the title doesn't count?
<dimitern> rogpeppe1, well, I'd like to see *why* it's needed maybe?
<rogpeppe1> dimitern: ok, doing that
<dimitern> rogpeppe1, ta
<dimitern> rogpeppe1, you've got a review
<rogpeppe1> dimitern: thanks!
 * frankban lunches
<rogpeppe1> "Yes, as a record in a Zombies collection."
<rogpeppe1> urulama: i don't understand that comment, sorry.
<urulama> rogpeppe1: oh, sorry, trying to be quick and on more than one place ... so. that's just a reminder for me. 
<rogpeppe1> urulama: ha ha
<rogpeppe1> urulama: i see
<urulama> rogpeppe1: what i had in mind is that todo should have implementation that stores sha of that blob into zombies collection (new one) maybe, so that cleanup can be easy
<urulama> rogpeppe1: what do you think?
<urulama> rogpeppe1: easieer that searching for non-referenced ones maybe
<rogpeppe1> urulama: i think that if the blob removal fails, it's almost certainly because the mongodb connection has gone away, so we're just adding more complexity for little likely gain
<rogpeppe1> urulama: because we're likely not to be ablr to add to the zombies collection either
<rogpeppe1> urulama: searching for non-referenced ones is pretty straightforward actually
<rogpeppe1> urulama: (i actually implemented it already elsewhere)
<urulama> rogpeppe1: agree on all points. i'll remove the comments
<rogpeppe1> urulama: cool
 * urulama sees 400 lines of tests for archive ... goes into the "that code works, the test pass, all is good" lazy mode for a moment :)
<rogpeppe1> urulama: :-)
<rogpeppe1> frankban: the charm upload branch has now landed
<rogpeppe1> frankban: next up: https://github.com/juju/charmstore/pull/63
<rogpeppe1> urulama, jrwren: https://github.com/juju/charmstore/pull/63
 * rogpeppe1 goes for some lunch
<frankban> rogpeppe1: cool, looking
<frankban> rogpeppe1, urulama, jrwren: https://github.com/juju/charmstore/pull/64
<urulama> frankban, rogpeppe1: 63 & 64 so soon :)
<frankban> heh
<hatch> morning
<kadams54> hatch: morning. Care to talk about https://bugs.launchpad.net/juju-gui/+bug/1342853 ?
<hatch> oh I already added it into the comments i Guess heh
<hatch> I don't have anything to add beyond that comment, did you have any questions?
<kadams54> Yeahâ¦ seems like I ought to be pursuing the band-aid fix for now, right?
<hatch> yeah - I'm not entirely sure how that's going to work though because right now whwnever the ecs is updated it fires an event which the deployer bar listens for
<hatch> so I'm not sure the best approach to debouce that so you can consolidate them
<kadams54> if (n % 2 === 0) { return; }
<hatch> you could consolidate on the end on render - but the little notification that shows up, will say 1 unit added 
<hatch> hah what?
<kadams54> I'll just drop every other event ;-)
<hatch> haha
<kadams54> hatch: i also did more playing around with left-aligned text in the charm yesterday. Posted my comments on the PR, but tldr is that I'm sticking with center-aligned for the time being.
<hatch> yeah? You don't think it looks funny being truncated with all that extra space on the right?
<kadams54> There really isn't very much extra space.
<kadams54> You could squeeze in an extra character depending on what letters are used in the name
<kadams54> Some names are going to leave more space, others less.
<kadams54> For example, here's what worst case scenario looks like with the current truncation limit: http://cl.ly/image/462m1L1f3908
<kadams54> This is more typical: http://cl.ly/image/003Z0w0p0K04
<kadams54> And to me, it doesn't look like extra space, but rather balanced. If I didn't know better, I'd just assume that space on the right was reserved for some other indicator/icon
<kadams54> Aside from that, I can only add one more character to the "typical" name before it starts squeezing the indicator and charm padding.
<kadams54> http://cl.ly/image/2n37173w0J0T
<hatch> oh wait a second, so the worst case scenario is still possible? 
<kadams54> If they name their charm using the widest characters in a font, yes.
<kadams54> Possible, but unlikely.
<frankban> rogpeppe1: could you take a look at https://github.com/juju/charmstore/pull/64 ? thanks
<frankban> rogpeppe1, jrwren: also https://github.com/juju/charmstore/pull/65 (quick)
<hatch> so that's not very good then
<kadams54> It's the worst way to truncate, except for all the others.
<hatch> measuring the width using that d3 script didn't work?
<hatch> it seems like that is the best way using a variable width font
<jrwren> frankban: nice catch.
<kadams54> hatch: it would be a very complicated solution.
<kadams54> The simple solution that works for 90% is better here.
<kadams54> You can't just calculate the width of the text, which the d3 plugin didâ¦ you also have to know the width of the container, which we don't until long after the text is added.
<hatch> what makes it complicated? take the width of the icon, the width of the blue circle, add to the width of the text, if it's too long, truncate the width of the text - and loop
<kadams54> Aside from that, the text gets wrapped in the parens, so you'd have to unwrap those, truncate, and then re-wrap
<hatch> and since it scales linearly you don't need to do it on scaling, only once on render
<hatch> well not really, you'd just use the original value and truncate it
<kadams54> (some-valuâ¦ vs. (some-valuâ¦)
<hatch> I would just much rather do it the best way and not have to deal with any potential fall out from doing it the easy way
<kadams54> IMO this is the best way.
<kadams54> Simple wins.
<kadams54> It works just fine for all but the most extreme scenario.
<frankban> hatch: I am running the charm functional tests in a precise env
<hatch> frankban thanks - it fails in the legacy server tests
<hatch> frankban did you merge in the develop trunk to the precise trunk?
<frankban> hatch: oh, so that's the problem, right?
<hatch> yeah it says that there isn't an environment connection
<kadams54> hatch: Look at it another wayâ¦ assuming we did things by calculating the width, all that it would get us, in the case of "block-storage-broker" is (block-storâ¦) instead of (block-stoâ¦) - and we'd have to maintain quite a bit more code for one more character.
<frankban> hatch: there so need to do that, we have a trusty release, and the code is the same, we just need to push that into the precise branch (when the tests pass)
<hatch> frankban right - but those tests do not pass when running on precise
<frankban> hatch: ok, I'll see them fail
<hatch> I tried taking the trusty code and deploying it via precise and the same failure
<hatch> did you notice the commits/diffs? 
<frankban> hatch: no
<hatch> kadams54 I'm not really worried about getting extra characters, I'm worried about the situation when a charm name spills into the icon
<frankban> hatch: I presume the tests pass when using a trusty env, correct?
<hatch> frankban correct
<frankban> hatch: ok, so maybe there is a regression on the legacy server on the legacy platform with the legacy code...
<hatch> lol!
<kadams54> hatch: If someone names their charm "mmmmmmmmmmmm", I can live with that happening.
<hatch> that's just the pyjuju stuff right?
<hatch> kadams54 but it's not even that - if you look at "hadoop-mapreduce" the truncated name touches the uncommitted icon
<rogpeppe1> frankban: looking
<hatch> kadams54 so yes truncating is working for the majority of the situations but it's not very resilient 
<hatch> even when things aren't crazy
<hatch> and people have called their video games AAAaaaaaAAAaaaaa :D
<hatch> so mmmmmmmm might not be too far off
<kadams54> hatch: you have an affinity for solutions that require architectural changes.
<kadams54> ;-)
<hatch> man chrome in ubuntu really does not like rendering svg's properly
<kadams54> Chrome anywhere does not. Check out the clipping on the icon: http://cl.ly/image/0b0G3r2I3A2i
<hatch> oops....
<hatch> kadams54 well I'd just rather not land something that could come back to bite us later because it doesn't go all the way
<kadams54> This is a pretty simple change, even more so because it consolidates logic (adding the parens) that had been scattered.
<kadams54> If it bites us, then we fix it.
<hatch> I envision a bug "service names sometimes under icon"
<kadams54> The bit isn't going to be a big one.
<hatch> and then we go "didn't we already fix that?"
<kadams54> That could be a generalized argument against incremental change
<hatch> except this is not an incremental change, it's a partial fix 
<hatch> I don't think we are going to agree here :)
<kadams54> Probably not :-)
<kadams54> incremental change, partial fixâ¦ to-may-to, to-mah-to
<hatch> ok add a note to the limitation to the PR and land it
<kadams54> One of the reasons for incremental change is that you don't invest a slew of time and code into fixing something the wrong way.
<kadams54> jujugui: need a second review/QA at https://github.com/juju/juju-gui/pull/480
<jrwren> kadams54: I looked at it.
<kadams54> jrwren: thanks
<hatch> frankban any luck? :)
<frankban> hatch: I saw the legacy test failing, trying to deploy it manually
<hatch> ok thanks - when I deployed it manually it seemed to work just fine
<hatch> jujugui call in 11 kanban now
<hatch> frankban I remember there was some discussion about deleting machines with services on them. ATM we can hit the trash can button on the machine but then committing fails because it has a service on it. Did we ever decide what the proper course of action was there?
<frankban> hatch: I don't remember. it's worth asking luca: I'd expect something like a warning message somewhere (at least)
<hatch> yeah will do, I could see a popup asking if they also want to remove the units on the machine, and if that leaves the service without machines....then ask if they want to remove the service as well
<hatch> jujugui call in 2
<hatch> jujugui call now
<hatch> rogpeppe1 you must love our quick standups :D
<rogpeppe1> hatch: oh yes
<jcsackett> i have become convinced that the entirety of durham has crap for internet this week.
<rogpeppe1> hatch: the juju-core standups were often interminable
<frankban> hatch: ISTM that the legacy server is broken
<hatch> rogpeppe1 haha, hardly a standup then :D
<rogpeppe1> hatch: indeed
<hatch> frankban so is legacy server pyjuju?
<hatch> I'm not really sure what legacy server even is
<frankban> hatch: I see websocket errors in the js console:  Error during WebSocket handshake: Unexpected response code: 404 
<frankban> hatch: no, the legacy server is haproxy + apache2
<hatch> ohh
<frankban> hatch: the regular server is the shiny python/tornado app, which always works ;-)
<hatch> frankban ok well if you take the develop-trunk and merge it into the precise-trunk you'll see a massive diff - maybe something in there busted it - tbh I didn't think we made any charm changes since the last release...
<hatch> lol oh u peeps and your pythons
<frankban> heh
<frankban> hatch: ugm, I don't see so many changes in the charm, mostly documentation and a new feature for testing locally (which seems broken, but it's not related to the current problem)
<frankban> uhm even
<hatch> but I don't even recall those docs being updated....
<hatch> I'm wondering if something got committed incorectly 
<hatch> incorrectly 
<frankban> hatch: I think the diff is sane, investigating on the ec2 machine about why websockets are broken
<hatch> allllright
<frankban> hatch: btw, yay functional tests, this is a real problem
<hatch> when do people use the legacy server?
<hatch> but yay!
<kadams54> bbiab: heading out for a run.
<hatch> enjoy
<frankban> hatch: jujucharms.com runs on the legacy server :-)
<hatch> of course it does 
<hatch> lol
<frankban> hatch: but would not hit this problem since it uses sandbox mode, so no real websockets
<hatch> so....does any real user use it? I don't even think it's enabled by default
<hatch> you'd have to explicitly turn it on, correct?
<frankban> hatch: yes
<hatch> I wonder if we couldn't just 'ignore' it 
<hatch> I mean, if it's going to be a ton of work to fix
<frankban> hatch: I don't know about real users. we dropped support for the legacy server on trusty. we still need to support it on precise
<hatch> ohh that's why it passes fine on trusty hah
<frankban> hatch: I guess so
<frankban> hatch: we skip that test on trusty
<frankban> hatch: haproxy sends a 404 to websocket upgrade requests :-/
<hatch> whaaa since when
<frankban> hatch: weird, the config file is unchanged from months, the haproxy version is the same...
<hatch> yeah....
<frankban> hatch: and I can connect to the juju websocket from the gui machine
<hatch> that is odd, so it's just haproxy that's causing the issue
<frankban> hatch: this is the haproxy configuration, do you see anything smelling?
<frankban> http://pastebin.ubuntu.com/7989894/
<hatch> looking
<hatch> frankban don't we now use wss ?
<hatch> I don't see a handler for wss only for ws
<frankban> hatch: not sure I understood
<frankban> use_backend juju if { path /ws }, we use the juju backend based on the request path
<hatch> maybe I'm misreading it because I thought we use wss: protocol 
<frankban> hatch: we use secure websocket indeed
<hatch> so does it need to redirect /wss or does the /ws handle that too?
<hatch> I'm just thinking that might be why it's 404ing
<hatch> grasping at straws really...
<frankban> hatch: /ws is just a path, not a protocol, the GUI uses that path for the websocket
<hatch> yeah ok
<hatch> in that case, I see nothing wrong with this config
<frankban> hatch: and this is the log of a single wss request: http://pastebin.ubuntu.com/7989981/ not really helpful
<hatch> frankban right - it looks like the /ws is 404ing
<hatch> but you said you could hit that directly right?
<frankban> hatch: no, I said I can hit directly the juju API address, which does not use /ws. In the haproxy conf, we strip away /ws before proxying to juju
<hatch> ohh
<frankban> hatch: juju.srvrep at line 9 makes me think the juju backend is actually invoked
<hatch> hmm - of course it doesn't show the request it's making
<hatch> can you throw a log in there?
<frankban> hatch: not sure
<frankban> hatch: I am already running it in debug mode
<frankban> hatch: ok it seems reqrep ^([^\ ]*)\ /ws/    \1\ / is not working
<hatch> damn regex....of curse it's the regex that you can't read.... :D
<frankban> but that regexp is the same from ages
<hatch> yeah I know....
<hatch> I really have no idea
<hatch> thats why I passed it to you  in hopes that you will have better luck :D
<frankban> hatch: it worked!!!
<hatch> whaaaat, what did you change?
<frankban> hatch: replacing that regexp with the magical words...
<hatch> lol
<frankban> reqrep ^GET\ /ws\ HTTP/1.1 GET\ /\ HTTP/1.1
<hatch> oh I'm totally at a loss as to why it failed NOW
<hatch> hah
<frankban> hatch: we should always ask why it failed... almost always... I am near my EOD, I can leave it to you if you want, otherwise I'll hack a patch on Monday
<hatch> well I think you're having better luck :)
<frankban> hatch: ok, I have a fix at least, will investigate further for the cause. is it possible that HTTP/1.1 was not sent before and it is now?
<hatch> that's very odd...
<hatch> but yeah at least there is a fix now
<frankban> done for the day, have a great weekend all!
<hatch> cya frankban have a good weekend
<hatch> thanks for finding the issue
<hatch> jujugui can someone remind me what a removed-but-uncommitted relation looks like? 
<kadams54> Hmmâ¦
<kadams54> hatch: just gave that a whirl and it looks the same as an un-removed relationship.
<kadams54> The change is listed in the change log, but there's no visual indicator on the relationship. Maybe something to bring up with design?
<hatch> It has been and they gave an answer, I just can't seem to find it in my email or in the designs heh
<kadams54> Blue line with status notification
<kadams54> Found the e-mail
<kadams54> (I think)
<kadams54> Subject: Representing removed relations on the juju-gui-peeps list, Luca's reply was on July 1
 * rogpeppe1 is done for the week
<rogpeppe1> g'night all
<kadams54> Now then, that saidâ¦ when you have a moment I'd like to chat more on my card.
<rogpeppe1> and happy weekends
<hatch> ok so everything needs a 'deleted' flag in their model then
<hatch> cya rogpeppe1 have a good one
<kadams54> rogpeppe1: ditto
<hatch> yeah I got moments
<kadams54> standup?
<kadams54> (Friday room)
<hatch> sure joining
<kadams54> jujugui: need reviews and QA on https://github.com/juju/juju-gui/pull/485
<kadams54> hatch: ^ that's the deployer bar consolidation stuff
<hatch> kadams54 on it
<kadams54> I've already placed my bets on which lines of code will get hatch comments ;-)
<hatch> lol so why don't you change them then :P
<kadams54> Gotta keep you honest :-)
<kadams54> CI build seems like YUI didn't load on the IE10 runâ¦ *sigh*
<hatch> kadams54 review done
<hatch> did I do what you thought I was gona do? :)
<kadams54> No, I lose.
<kadams54> But your suggestion is good.
<hatch> lol......yay?
<hatch> ok now I'm wondering, what did you think I was gona do
<hatch> say*
<kadams54> I thought for sure I'd get in trouble over the single letter variable names here: https://github.com/juju/juju-gui/pull/485/files#diff-e6baa739d19ae967f00d894884a065acR709
<kadams54> Though I feel like I'm just giving this away for whoever the second reviewer is ;-)
<hatch> haha - I was going to actually comment on moving the var declaration outside of the loop AND change the var name but I figured you had to re-write it based on my other comment anyways :P
<hatch> I'm not against single var names when it's easy to tell what they are for
<hatch> but everyone else is haha
<kadams54> I find that kind of funny because I picked it up from the pythonistas I knew.
<hatch> I figure if the var doesn't follow a convention (like e for event with YUI code) or is used more than 3-5 lines from its declaration or is used with other single char vars then it should be renamed
<hatch> ...I lead a simple life....
<hatch> lol
<jrwren> I thought this team was pro-single character variable names.
<kadams54> Maybe we have enough to swing the balance.
<kadams54> ;-)
<hatch> haha
<hatch> jrwren lol definitely no
<kadams54> jrwren: just use "e" everywhere for events. It's all good.
<hatch> I'm even getting out voted over that one
<hatch> no reason to pre-minify code really
<kadams54> Outvoted, out-shmoted.
<kadams54> Sure there is. Programmers are lazy.
<kadams54> I actually had no clue until the most recent IRC conversation. No one's objected to my use of "e" in code reviews.
<hatch> right, because of my lobbying for the e convention for events
<hatch> it's a YUI convention 
<hatch> I also use i, j, k for iterators 
<hatch> but don't do for loops often heh
<jrwren> I hope not. I miss that vim plugin that calls 1 length variable names an error.
<hatch> you use multi char vars for iterators?
<jrwren> no.
<hatch> what do you call them? loopCountOne?
<hatch> lol oh ok
<jrwren> i,j,k are fine of course.
<jrwren> it didn't flag those. Only top level names.
<jrwren> I think python-mode was the vim module that did it.
<hatch> oh intersting 
<kadams54> hatch: I can reduce it from three loops to two, but can't reduce it any further than that. Updated code's been pushed.
<hatch> kadams54 got it up somewheres?
<kadams54> Yeah, the PR's been updated.
<hatch> ok looking
<hatch> oh I see what you did, ok I had something else in mind
<hatch> umm how to esssplain
<hatch> ok I think I got it
<hatch> will comment on the PR
<hatch> kadams54 ok added comment to the PR
<hatch> I hope I did a reasonable job explaining it :)
<hatch> kadams54 using my suggested approach you'd also need to modify the template so feel free to tell me to shove-it and leave your code as is :)
<hatch> the hacks are at least now contained to a single method
<hatch> :)
#juju-gui 2014-08-10
<huwshimi> Morning
#juju-gui 2015-08-06
<frankban> tvansteenburgh, Makyo: could you please take a look at https://code.launchpad.net/~frankban/juju-deployer/unit-placement-fix/+merge/267187 ?
<tvansteenburgh> frankban: looking now, thanks!
<frankban> tvansteenburgh: ty!
<frankban> tvansteenburgh: ty for the review! patch_env_status is used to avoid the sleep loops on add_unit FYI
<frankban> tvansteenburgh: can I remove also the reloaded stuff?
<tvansteenburgh> frankban: yes please do!
<frankban> tvansteenburgh: cool I will
<frankban> tvansteenburgh: also I'd like to go ahead and release a 5.0.1 (pypi and juju stable ppa) after this is landed, if you agree
<tvansteenburgh> 0.5.1 i assume, and yes i agree
<frankban> yes 0.5.1 it is, thanks
<frankban> tvansteenburgh: mp updated, if you approve the branch I'll go ahead and merge/rlease it
<tvansteenburgh> frankban: looking
<tvansteenburgh> frankban: approved, thanks
<frankban> tvansteenburgh: great thank you, I'll ship 0.5.1 tomorrow
<tvansteenburgh> frankban: excellent
<frankban> tvansteenburgh: it seems that I cannot merge that branch: bzr: ERROR: Cannot lock LockDir(chroot-90063440:///%2Bbranch/juju-deployer/.bzr/branch/lock): Transport operation not possible: readonly transport
<tvansteenburgh> frankban: want me to try it?
<tvansteenburgh> frankban: merged
<frankban> tvansteenburgh: sorry was on call, ty!
<tvansteenburgh> frankban: np, would you like me to upload to pypi?
<frankban> tvansteenburgh: yes please, I'll make the PPA release tomorrow
<tvansteenburgh> frankban: done
<frankban> \o/
#juju-gui 2017-08-07
<dakj> hello guy, I'm trying to create a bundle of Openstack Okata with LXD (it is not present a ver. on juju store), I exported the yaml file of Openstack Base Xenial Okata removed the charms of Cinder and Cinder-Ceph and adding LXD. The new yaml file is that https://paste.ubuntu.com/25262004/. when I try to make the import of that receive an error. someone can help me? thanks
<dakj> the issue is that https://pasteboard.co/GEwTaWE.png
<rick_h> dakj: I think the machine number comes first. 5:lxd and then 5 had to be defined in the"machines"section of the bundle
<dakj> rick_h: in this way? https://paste.ubuntu.com/25262972/
<dakj> rick_h: I tried to make import and also with that changes the issue is always present
<dakj> rick_h: now it mades the import on gui but I don't see the charms
<dakj> rich_h: I'm trying directly on juju gui. I've added the bundle of ocata removing cinder and cinder-cepth and adding lxd. I'm waiting its finished for updates
<dakj> rich_h: here the result https://pasteboard.co/GEyH1gl.png. for the issue on neutron-gateway I've opened a post here https://github.com/openstack-charmers/openstack-bundles/issues/28 but never answer yet. 
<dakj> rick_h: I tried to create an instance and the result was right https://pasteboard.co/GEyRrwTh.png
<dakj> rich_h: I've resolved also this post https://askubuntu.com/questions/942058/openstack-new-instance-error-profile-is-currently-in-use. After I've added the bundle of Openstack LXD, removed LXD charm and then re-added that to the bundle, after the deploy, Openstack creates the instance. I don't know if that is just a my problem or someone had the same issue but removing that charm the problem has been resolved. thanks for your support.
#juju-gui 2017-08-08
<dakj> rick_h: hi, last update about my issue. I've re-maked for three time the same procedure, removing and re-adding the charm of LXD on bundle of Openstack LXD and in all tests the creation of new instance has completed the task without reported issue. Instead without make that procedure the issue on instance is still present. 
<dakj> rick_h: I'm making the export of bundle of Openstack Ocata with LXD from Juju GUI is there a way to publish that on Juju store as bundle? thanks
#juju-gui 2018-08-10
<mhilton> morning all
