#juju-gui 2012-12-17
<gary_poster> hey teknico, approved your holiday request
<gary_poster> benji, I was going to try and dupe teknico's report on your branch, unless you've already verified/duped.  have you?
<benji> gary_poster: nope, I have been trying things bug was just about to give up and ask for a pairing session
<gary_poster> ok benji, I'll be ready in just a few minutes & I can at least try to dupe with you.  pairing, or talking, with teknico afterwards might make sense (and I have another call in an hour)
<benji> k
<gary_poster> Something I meant to mention earlier to everyone: http://uistage.jujucharms.com:8080/juju-ui/version.js works now, and can be useful to confirm that you are verifying on QA what you expect
<gary_poster> I'll try to remember to mention this on the call
<gary_poster> mm, I'll send an email
<hazmat> g'morning
<hazmat> gary_poster, where would i put the card for annotation support given our current stories?
<gary_poster> hazmat, secondary story please (we need it there)
<gary_poster> hazmat, I was just writing an email, but you know the answer to this and can share it in five seconds I suspect.  From the email draft:
<gary_poster> On a related note, note that our README is not rendered properly in the charm store (unlike, say, http://jujucharms.com/charms/precise/wordpress).  I saw that ReST is supported (see "Creating a README File" in https://juju.ubuntu.com/docs/write-charm.html) so we're not doing something else right.  Maybe we just need to move the charm's README.txt to README.rst?
<gary_poster> Referring to http://jujucharms.com/~juju-gui/precise/juju-gui
<hazmat> gary_poster, only markdown is supported for rich formatting (client side) in the store atm
<gary_poster> oh ok hazmat.  So we should switch, maybe.  And maybe change the charm docs?
<gary_poster> I mean https://juju.ubuntu.com/docs/write-charm.html
<hazmat> gary_poster, we can add a card to the charm store for rst support, but its low priority
<gary_poster> right
<hazmat> gary_poster, we should switch and change the docs.. the gui is going to have the same issue rendering readme formatting
<gary_poster> hazmat, there is no JS ReST parser AFAICT either.
<gary_poster> Right was going to say the same thing
<hazmat> ie it needs a js renderer or pre rendered format
 * hazmat nods
<gary_poster> I think charm docs should say "Markdown"
<gary_poster> period
<gary_poster> If charm store and GUI don't support ReST, why would you write it?
<gary_poster> and how can we say we support it?
<benji> indeed
<hazmat> gary_poster, i agreed we should change it, it was originally written prior to these ecosystem of tools
<hazmat> gary_poster, we could support it via  a static pre-rendered pipeline
<hazmat> that serves up the asset from the charm store
<hazmat> er.. browser ;-)
<gary_poster> hazmat, sure, but what priority is that? :-)
<hazmat> indeed
<gary_poster> hazmat, I'll contact jorge and see if he wants a bug for this or if I should just keep this in a card for our own plans
<hazmat> gary_poster, https://code.launchpad.net/~hazmat/juju/markdown-only-readme/+merge/140203
<hazmat> not sure where the docs went to
<hazmat> they used to be a series off of.. https://launchpad.net/juju
<gary_poster> hazmat, awesome.  so I don't need to metion this to/convince jcastro then, and you'll get it merged?  or do you want us to help getting it merged?
<hazmat> ah.. got it.. its still there. i'm just inactive in the charmers team that owns it. fixed and done.
<gary_poster> awesome thank you hazmat
<hazmat> gary_poster, its merged, doc sites should update when their cron kciks in.
<gary_poster> great thanks again
<hazmat> gary_poster, np.. thanks for the summary writes up... good morning reading. i pushed the login stuff into review.. 
 * teknico is back from lunch
<gary_poster> great hazmat thanks
<hazmat> gary_poster, branch details are in the card if anyone's interested
<gary_poster> cool.  will look asap (other stuff in my queue atm)
<teknico> so we're switching the charm docs to markdown?
<teknico> great, maybe that'll help me making a fool of myself slightly less often :-)
<gary_poster> hazmat, one other question while I have you, in reference to the GUI hiding the GUI charm: you mentioned the GUI filtering by charm tag.  charm tags are not yet implemented, right?  So, for now, we'd need to filter by charm name?
<gary_poster> teknico, not sure what you mean about making a fool of yourself less often, but glad you are OK with it :-)
<teknico> gary_poster, referring to https://codereview.appspot.com/6945058/
<gary_poster> teknico, lol, gotcha.  np.  Other topic: I have not yet tried to dupe the problems you saw in benji's branch.  I think I can try to do that in just a few minutes.  Maybe you and he can have a chat soon to investigate that and also discuss the Makefile issue you raised face to face...or however benji wants to resolve that.
<teknico> gary_poster, yep, I was wondering whether I was the only one to see those prod test errors
<benji> teknico: do you have a moment to work on this?
<gary_poster> right.  I did not follow the process and did not run the tests.  bad reviewer :-(
<teknico> gary_poster, I reordered the cards in the primary ready to code lane, I wonder whether it helps or hinders :-)
<teknico> benji, sure
<gary_poster> teknico, cool.  unfortunately I find that orderings sometimes don't stay long in the kanban board, but I like what you did on the face of it
<gary_poster> thank you
<benji> teknico: cool; please run a "make clean && make prod" and then open chrome, clear the cache, and then open the front page of the app and see if there are any errors in the console (404s in particular)
<teknico> gary_poster, I know I'm prone to tweak things too much sometimes, and people might be thrown off by it :-)
<gary_poster> :-) np
<teknico> benji, ok
<teknico> benji, done, no 404 in sight
<teknico> benji, that's in your branch, not trunk, right?
<benji> teknico: great; now please stop the prod server and run "make test-prod"
<benji> teknico: yep, my branch
<teknico> benji, I see 404s on /juju-ui/assets/event-simulate.js and /juju-ui/assets/node-event-simulate.js
<benji> a clue!
<teknico> which is weird, because they are indeed included in test/index.html
<teknico> uhm, I'm being silly
<teknico> they are indeed not in the place where they are requested from, in build-prod
<benji> yep, I think I know what is going on; one second
<benji> if I am right, this is further evidence that we really need to get our caching story straight
<goodspud> Whoever is working on the login story, do you have the assets you need from our designers here?
<benji> if you want to try something for me while I do this you can stop the test server, start a devel server, reload the test page (it is ok if there are test errors for this excersize), stop the debug server, do a "make test-prod"
<benji> I bet the tests will pass.
<teknico> benji, trying
<benji> thanks
<gary_poster> goodspud, good question.  that will be benji, but he is looking at something else this second.  I was thinking that we would first try to do the corners in CSS (if designers could give the CSS to us it would save bunches of turn-around time but AFIAK that's not happening)
<gary_poster> If that doesn't work then we will need images for the corners
<gary_poster> godspud, otherwise we shoudl have some dimensions of the box
<gary_poster> ooh, godspud, now you have more spudly powers
<goodspud> gary_poster, I've been working on my super powers but spudly is all I can come up with for the moment
<goodspud> These things take time
<gary_poster> :-)
<gary_poster> goodspud, dimensions and font sizes of the header and so on would be convenient too...and info on the gradient and shadow
<benji> lol
<goodspud> gary_poster, I'll chase up Matt and Greg to get them to provide assets and dimensions, if not CSS if at all possible
<gary_poster> thank you very much goodspud
<goodspud> A pleasure
<teknico> benji, what you asked has two different problems. I tried reading between the words, but nothing changed :-)
<teknico> I'll wait for you to complete your intestigation
<benji> teknico: what were the problems?
<teknico> benji, 1) mentioning "devel" first and then "debug; 2) different ports on "proper" and test servers, so reloading the test page does not work
<teknico> (I guess I meant "reading between the lines" :-) )
<benji> teknico: mmm, indeed; thanks for trying.  Meanwhile my test validated the idea so I'll have a fix in the branch soon for you to try again
<teknico> benji, great
<teknico> benji, you fixed it, great job! :-)
<gary_poster> thanks teknico, benji.  have you two also resolved the Makefile discussion?
<teknico> gary_poster, not yet
<benji> teknico: ok, the branch should work for you now
<teknico> benji, ^^ :-)
<teknico> benji, now, about that other small issue... :-)
<gary_poster> cool
 * benji looks back at the review to remember "the Makefile discussion"
<teknico> benji, about copying versus linking yui assets
<teknico> benji, I see that you added a disclaimer in comments
<benji> ah!  I'm not against linking, it is just that the links previously created were not right; the prod and debug sites produced 404s
<benji> right, Gary and I decided that it wasn't worth the work right now to figure out how to get links instead of copies
<gary_poster> benji, btw did you make a bug for the prod CSS issues?  would like to have it on the board
<benji> gary_poster: I don't think so.  I will do so now.
<teknico> benji, gary_poster, that decision doesn't feel right, given the history of changes
<gary_poster> ty benji
<teknico> which does not mean it *is* not right, just that it does not *feel* so :-)
<teknico> benji, anyway, approved
<benji> teknico: the tweaked branch worked for you?
<teknico> benji, it did, as mentioned above
<teknico> and in the review
<benji> cool, thanks
<benji> I need to file another bug I discovered during this debug session.  The devel server generates 404s for /juju-ui/assets/combined-css/rail-x.png on the trunk.
<gary_poster> teknico (benji), symlinks vs. copies: I like the idea of symlinks for this.  however, benji found that the symlink approach we had was not working for these files.  I don't think that copies in this case are horrible--the Makefile is limited in what it can do in this case anyway, since we do not specify what files we actually care about--and I cared more about getting the prod tests working, so I was fine with a pra
<gary_poster> gmatic solution of reverting the change rather than investigating it.  I'd be fine with a bug to convert the copies to symlinks in the future, and I would thank whoever filed it, but I would triage it as low at this time.
<gary_poster> OTOH, since we don't have any build tests, changes like this are more expensive than they might appear
<gary_poster> s/OTOH, //
<teknico> gary_poster, when can we talk about build tests?
<gary_poster> teknico, there's a card for weekly retrospective
<teknico> gary_poster, great
<benji> speaking of build tests, while reading the make manual (I am easily entertained) I happened upon the --just-print, --question, and --what-if make options that might be useful for writing tests
<teknico> benji, I'm more easily entertained by searching for alternative build systems :-) (there actually went part of my weekend)
<teknico> and yes, I have read gary's blog posts, so I'm *not* raising the issue
<teknico> (at least not right now ;-) )
<gary_poster> bac bcsaller benji goodspud hazmat Makyo teknico call in 2
<bcsaller> Makyo: after you get off your next call ping me
<Makyo> bcsaller, alright
<Makyo> goodspud, ping
<goodspud> Whoops... missed the meeting
<goodspud> is it over?
<Makyo> Yes, but you and i were going to talk about fancy relations.
<gary_poster> goodspud, yes, but Makyo wants to talk to you now :-)
<Makyo> https://plus.google.com/hangouts/_/3bf1056afd2f9bc2b1f136097c5af5369a200312
<goodspud> Sorry guys. Chatting with Alejandra and we got distracted
<gary_poster> np
<goodspud> Makyo, joining
<hazmat> Makyo, cool re recess, looks nice
<gary_poster> hazmat, apologies if I missed it but did not see reply to following. in reference to the GUI hiding the GUI charm: you mentioned the GUI filtering by charm tag.  charm tags are not yet implemented, right?  So, for now, we'd need to filter by charm name?
<gary_poster> Also, you made a card titled "Error Collection" with description "Aggregate errors into collection."  I dragged that into "Needs Specification" because I didn't know what you meant
<hazmat> gary_poster, charm name is what i meant
<gary_poster> cool hazmat thansk
<hazmat> gary_poster, that's the javascript error collector
<gary_poster> hazmat, oh! the OOPS thing
<hazmat> gary_poster, yu
<hazmat> yup
<gary_poster> got it thanks
<gary_poster> hazmat, I still thank that needs to be specced--either directly by you or with goals from you and a proposal by us--but I changed the card to hopefully clarify the goal better--it helps me anyway.
<gary_poster> let me know how you want to proceed on specifying that
 * gary_poster has to step away from IRC for a phone call
<gary_poster> back in no later than an hour
<Makyo> bcsaller, ping
<bcsaller> Makyo: gimme a sec, have to reboot, unity is acting out
<Makyo> bcsaller, sure
<bcsaller> Makyo: let me open a hangout
<goodspud> gary_poster, I won't be able to attend the daily stand up tomorrow. Have to take the good woman to the eye hospital as part of a regular check up she has. 
<gary_poster> ok goodspud  thanks for heads up
<teknico> hazmat, I still owe you a review, however, the lp:~hazmat/juju/rapi-login is not proposed, where am I supposed to write the review?
<hazmat> teknico, good question..
<teknico> hazmat, also, the card says: "prior branch for diff: lp:~hazmat/juju/import-export" but bzr cannot find it
<hazmat> teknico, just pushed it
<hazmat> import-export
<teknico> not there yet, it'll maybe take a few minutes?
<hazmat> teknico, merge proposal -> https://codereview.appspot.com/6935068
<hazmat> teknico, https://code.launchpad.net/~hazmat/juju/export-import
<hazmat> not import-export
<hazmat> teknico, sorry about that. thanks
<teknico> hazmat, no worries, updating the card
<teknico> hazmat, about the wire protocol, point 4 includes 'result': 'success' , while points 5 and 6 use 'err': true, it looks a little weird
<hazmat> teknico, that's in keeping with the error handling across the other api methods
<hazmat> teknico, result: True would work as well
<teknico> hazmat, one would think choosing one of 'result': ['success'|'failure'], or 'err': ['true'|'false'] would be preferable
<teknico> I don't know whether there's any such consistency in the rest of the api
<hazmat> teknico, omission of err is false, we can change the result value
<hazmat> teknico, for error handling there is absolutely
<teknico> hazmat, great, so I'm just missing the bigger picture
<teknico> hazmat, so this is pyjuju code, my review will likely not be extremely authoritative :-)
<hazmat> teknico, error handling for other methods is an exception catch .. api context _on_error
<hazmat> teknico, fair enough.. given the lack of pyjuju devs, its probably sufficient unless gary_poster is chiming in/reviewing as well.
<gary_poster> mm
<gary_poster> hazmat, I trust teknico's review if that's all you'd like.  Ben is another option, of course, if you want a pyjuju dev.  But do what you think makes sense.
<gary_poster> I'm happy to look at it, but would be in an hour or so, and I like the idea of you being able to land this and move on
<teknico> hazmat, done, fwiw
<gary_poster> biab
<hazmat> teknico, thanks
<hazmat> bcsaller, do you have time to do a review on https://codereview.appspot.com/6935068
<bcsaller> hazmat: I can do that yes.
<bcsaller> Makyo: going to take that review quickly
<Makyo> bcsaller, alright, poking around translate.
<hazmat> bcsaller, thanks
 * hazmat lunches
<hazmat> http://www.sencha.com/blog/the-making-of-fastbook-an-html5-love-story
<hazmat> bcsaller, responded, hopefully that elucidates the intended scope and purpose which i think is a bit smaller than your comments were referencing.
<bcsaller> hazmat: I suspected that was the case
<hazmat> bcsaller, main purpose is to have a node with a restrictive acl that can only be accessed if the ws client has successfully authenticated.
<hazmat> a followup branch will require the ws client to before using the rapi api
<bcsaller> hazmat: yeah, thats what I was reading, but I wasn't sure of the scope
<bcsaller> sounds good, +1
<gary_poster> hazmat did you land rapi-login already? If so will move kanban card.
<gary_poster> bac, I can pair a bit. maybe worth trying?  though you only have a few more minutes before youe EoD don't you
<bac> gary_poster: juju-ui?
<gary_poster> k
<hazmat> gary_poster, not yet.. monday's are meetingful.. should be by EOD
<gary_poster> cool thanks
<bac> gary_poster: i'm going for a walk.  will be biab
<gary_poster> cool
<hazmat> hmm.. merging out of order in bzr pipeline.. is non trivial
<hazmat> gary_poster, did you want me to add the gui env api for login as well?
<hazmat> wasn't sure if you already had that in your branch
<gary_poster> hazmat, not my branch--benji will be doing it--but yes, please
<gary_poster> (IOW, please merge it)
<hazmat> ack
<gary_poster> hazmat, I did Markdown on a one-off and it rendered locally, but charm store is not happy (http://jujucharms.com/~juju-gui/precise/juju-gui).  Do I need to call the file README.md?  Looks like that's what the wordpress charm does...
<hazmat> gary_poster, yeah.. it looks like it wants the .md
<gary_poster> ok cool thanks
<hazmat> gary_poster, benji login merged to rapi-rollup fwiw
<gary_poster> thank you hazmat 
<benji> cool
<gary_poster> yay http://jujucharms.com/~juju-gui/precise/juju-gui
<bac> gary_poster: MP submitted.  lbox blew up so it isn't in RV.  one issue outstanding.
 * bac dinners
#juju-gui 2012-12-18
<hazmat> bcsaller, for tomorrow.. could use a review on the annotation support for persistent positions https://codereview.appspot.com/6936063/
<bac> hi frankban
<frankban> morning bac
<bac> morning frankban.  can we have a quick chat to discuss your branch and getting mine out of your way?
<frankban> bac: sure
<bac> juju-ui then
<frankban> frankban: joining
<frankban> bac: bzr+ssh://bazaar.launchpad.net/~frankban/charms/precise/juju-gui/bug-1088618-serve-releases/
<frankban> bac: https://code.launchpad.net/~frankban/charms/precise/juju-gui/bug-1088618-serve-releases
<gary_poster> frankban, bac, I hope I'm not making unnecessary problems.  Happy to do whatever you think might help
<bac> gary_poster: join G+ juju-ui
<bac> please
<gary_poster> :-)
<gary_poster> hey benji.  I wanted to make sure we were on the same page for your new card.  you have a second for juju-ui hangout?
<benji> gary_poster: sure, let me plug up my camera
<gary_poster> cool thanks
<gary_poster> goodspud, hey.  any timeline for getting the designer assets (hopefully largely CSS) for the login page?  We don't have to have it this week, but it would be convenient if we had it today or tomorrow morning at the latest.
<gary_poster> hazmat, just to let you know so you are not surprised: you made a "read-only mode" card in the primary story tasks.  that card/bug already exists in the secondary story.  it is in the secondary story because the refactoring is supposed to assist in that card, and so it is one of the user-facing improvements I associated with the refactoring.  shared position is also down in the secondary story for the same logic.
<goodspud> gary_poster - quite conveniently I've just been handed them
<gary_poster> Therefore I deleted the primary lane's version
<gary_poster> goodspud, yay :-)
<goodspud> gary_poster, just in the process of uploading.... please hold caller
<gary_poster> :-) goodspud, benji is working on this. As a heads up, I encouraged him to divide this up into a first cut effort that incorporated the functionality plus the low-hanging fruit of the design in one pass, and then a full-on design match in a second pass.  (Someone else might even do the second pass.)
<goodspud> gary_poster, benji - all the assets and guides are here: https://drive.google.com/a/canonical.com/#folders/0B1IM--9A1RkTd21pN2RxUHU3WEU
<goodspud> I'm about to leave the office for the afternoon but buzz Alejandra if you need any help. Greg (designer) isn't set up on IRC or email yet so best to go through her
<gary_poster> ack goodspud & thanks.  good luck at the dr
<benji> goodspud: thanks
<hazmat> gary_poster, cool, thanks
<hazmat> the kanban search is kind of cool
<hazmat> the pan to card effect
<gary_poster> yeah
<gary_poster> https://docs.google.com/a/canonical.com/file/d/0B1IM--9A1RkTRmw5NVBxeUgwZzA/edit looks liek an old-style macbook pro trackpad, upsidedown.
<hazmat> if anyone is up for a pyjuju review... this is the annotation support for persistent positions and landscape..  https://codereview.appspot.com/6936063/
<gary_poster> I'll look at it, at least for a non-pyjuju-reviewer review
<hazmat> gary_poster, on the subject of kanban org.. in the primary story we have (proto, code, & review) in the secondary (proto, code, review code).. are those meant to be the same?
<gary_poster> hazmat, yeah
<gary_poster> changed hazmat, thanks
<hazmat> np
<hazmat> i'm going to be out for our daily today to attend an omnibus review, for my next gui task i'm looking at working on read-only support 
<gary_poster> hazmat in GUI or in rapi?  That's only in GUI, do I remember correctly?
<gary_poster> In GUI, the read-only support would conflict with the refactoring work; that will either be largely done by Jan 3 (per blog post definitions of this week's goals) or pushed aside for later if we have time in the future
<hazmat> gary_poster, it shouldn't conflict
<gary_poster> you would only be doing env changes?
<hazmat> gary_poster, i'll be adding another store impl
<hazmat> s/store/env
<gary_poster> right, ok cool
<gary_poster> thanks
<bac> gary_poster: i've updated my branch and just tested it.  the new nginx upstart config seems to have fixed the issue i talked about.
<gary_poster> yay, bac!  Want an official approve from me?
<hazmat> gary_poster, re rapi support, long term vision would be the cli uses rapi too, so read only support there would still be advisory based on the gui
<hazmat> switching the conn to read only mode
<bac> i changed the juju-gui-branch out from under it and also switch from production to staging.  all worked.  this isn't to be confused with thorough testing, of course.
<bac> gary_poster: yes but waiting for a second from frankban
<hazmat> bac, cool, real config support!
<bac> i think "real" needs scare quotes.  it is a good start.
<gary_poster> oh, hazmat, I had a question about config-changed.  I saw confirmation from you somewher on the web that config-changed is called after install and before start
<gary_poster> if that's the case
<gary_poster> then in the common case install can be very very small, I would think
<gary_poster> because there's no need to dupe work in install and config
<gary_poster> More controversially,
<gary_poster> it also can replace start in some cases
<gary_poster> because that's in fact the simple way to implement it if config-changed has to restart
<gary_poster> a more sophisticated config-changed in that case woudl notice that nothing had been started yet
<gary_poster> and not restart
<gary_poster> but the super simple implementation is to just start/restart always
<gary_poster> which means that in that case start is redendant
<gary_poster> redundant
<gary_poster> hazmat, could you confirm or correct the above?
<hazmat> gary_poster, confirmed config-changed called b4 start
<hazmat> hook logic ordering is whatever make sense to the charm
<hazmat> many charms just have a single file symlinked to hook names so they can share logic easily
<gary_poster> so what I said makes sense to you, but is not the only way to look at it, is what you are saying?
<frankban> bac: is your branch ready for review?
<benji> hazmat: ping; I am trying to get the latest version of rapi-rollup to send "state": "login-required" and I am not having any luck
<hazmat> benji, poking
<hazmat> benji, using improv?
<hazmat> benji, atm login isn't required
<gary_poster> hazmat, out of curiosity, if we were doing it within the charm, how would you turn login on?
<gary_poster> /usr/bin/python -m juju.agents.api --help shows --secure
<hazmat> since it would break all the extant without gui support, what's there is to support implementing the gui bits
<hazmat> gary_poster, there will be a separate branch to require login for all rapi access
<hazmat> gary_poster, secure is for tls
<gary_poster> hazmat I thought we had a switch to turn on the login so we could test?
<hazmat> gary_poster, you can still login now
<gary_poster> hazmat, oh, but there is no way to turn on a challenge as in line 7 of http://paste.ubuntu.com/1397723/
<gary_poster> ?
<gary_poster> I was asking benji to make the GUI able to handle either the challenge
<gary_poster> or not the challenge
<gary_poster> which ought to be no problem
<hazmat> gary_poster, no... but the gui also needs to keep track of a user state
<gary_poster> AFAIK :-)
<hazmat> meeting..
<gary_poster> ok
<gary_poster> benji, I'm not sure id this is what hazmat means by user state, but one other aspect of this is that we want to stash the authentication credentials in memory
<benji> ok, I can fake it for the time being
<gary_poster> that way, if the socket dies
<gary_poster> we can reconnect
<benji> makes sense
<gary_poster> (but if the user refreshes the browser window, they have to reauthenticate)
<hazmat> gary_poster, auth creds in browser is what i meant by user state
<hazmat> gary_poster, session storage
<hazmat> or not...
<gary_poster> hazmat, we said session storage then you changed your mind in my memory
<gary_poster> browser in memory makes sense to me fwiw
<hazmat> gary_poster, yeah.. i recall as well. thinking now it would be nice to give  a voice to ux.. unless security is paramount
<gary_poster> hazmat, I think we can have rapi have a switch turn on login challenge.  let's talk when you are out of meeting
<gary_poster> agree on ux
<gary_poster> though a reasonable and easy first cut is browser in-memory
<hazmat> gary_poster, i'd rather avoid a switch for something not meant to be configurable...
<hazmat> but let's talk  in 1hr
<gary_poster> hazmat, right it would be for the transition period
<gary_poster> ok cool
<gary_poster> OIC
<gary_poster> So benji, I guess hazmat is saying that you can just always show the challenge
<gary_poster> it doesn't do anything really now
<gary_poster> but that's the transition story
<gary_poster> that's fine too
<gary_poster> make sense benji?
<benji> so we will always prompt for login but only relay it to the server if it asks?
<benji> will we land it that way (without validating that it actually works against the real server)?
<gary_poster> benji, no the server accepts the login now is what Kapil is saying
<gary_poster> benji so after line 7 of http://paste.ubuntu.com/1397723/
<gary_poster> I mean
<gary_poster> line 7 would not have  a challenge
<gary_poster> but you would send line 11 anyway
<gary_poster> expect lines 15-17
<gary_poster> or 21
<gary_poster> benji, I'm sure you will verify experimentally, but that's my understanding
<benji> oh, it accepts it but it does not challenge?  so my branch would always prompt for credentials but only send them if... what?
<gary_poster> you'd always send them after the greeting
<benji> or send them and ignore any "what you talkin' about Willis" errors?
<gary_poster> you'd treat the greeting response as if it had a challenge--as if it looked like line 7
<gary_poster> everything else (except for the rejection in line 28) should behave as described
<gary_poster> AIUI
<gary_poster> If I'm correct, there should be no "what you talkin' 'bout Willis" errors when you send line 11, benji
<gary_poster> if there are, we'll need to circle back around with Kapil
<gary_poster> is that clear?
<benji> gary_poster: even if the server does not understand credentials?  or are we ignoring non-credential-understanding backends?
<gary_poster> yes benji
<gary_poster> we control that particular horizontal/vertical
<gary_poster> we are ignoring non-credential-understanding backends
<benji> k
 * gary_poster withholds backend jokes
<benji> heh
<gary_poster> hey bcsaller, sorry. are you already in another hangout or do you want to join me in our calendar hangout?
<teknico> gary_poster, I have to leave in ten minutes, I likely won't be back in time for the daily call, only shortly thereafter
<gary_poster> ok teknico.  can you give me status on your branch?
<teknico> gary_poster, I gathered together the commands and config changes needed, am now tracking bac's branch to put my changes in
<gary_poster> teknico, oh!  you have to modify charm too, of course. :-/
<teknico> gary_poster, yep
<bac> gary_poster: mine is ready to land pending a second review
<gary_poster> teknico, if bac's branch lands in the next hour or so will you be able to land soon after, or will integration be more involved that that?
<gary_poster> bac, other than mine?
<bac> gary_poster: yes.  two required, right
<gary_poster> y
<gary_poster> bac, so do you know of any more issues lurking in your branch, or is everything hunky dory as far as you know?  You expressed reservations earlier today
<bac> gary_poster: i think it is good
<teknico> gary_poster, I hope to be able to propose today, yes
<gary_poster> teknico have you followed bac's branch closely, enough to give it a fast review before you leave, or should we just wait for frankban's return?
<gary_poster> teknico, great thanks
<teknico> gary_poster, yes, I was trying to do that
<teknico> bac, is there a rietveld proposal, or just lp?
<gary_poster> teknico, and I am keeping you from it. :-P sorry.  Just lp teknico 
<bac> just lp teknico
<bac> lbox blew up on me when authenticating to google
<teknico> ok, thanks
<frankban> gary_poster, bac: I am here
<gary_poster> hey frankban, we've got a second review from teknico, thank you.  You can keep on doing good stuff on your own branch :-)
<teknico> gary_poster, frankban, well, mine is more like a half review, though :-)
<teknico> and now I gotta go
<gary_poster> ok teknico see you in a bit
<gary_poster> bac, I think it's two reviews. ;-)
<bac> gary_poster: yep.  landing now.
<gary_poster> thanks bac
<gary_poster> bcsaller, ping
<bcsaller> gary_poster: hey
<gary_poster> oh hey, there you are bcsaller.  I was running late, then couldn't connect with you earlier.  Meet briefly in our usual hangout, or are you already somewhere else?
<bcsaller> gary_poster: usual is fine, grabbing the link
<gary_poster> cool
<bac> gary_poster, hazmat: i just pushed my branch.  unfortunately, since lbox is broken for me atm i had to do it manually and i inadvertantly polluted the revision history by including all of my development revisions.
<gary_poster> :-/
<gary_poster> bac, I don't know how to do that surgery, butr hazmat does.  mm, I think you can uncommit bac
<gary_poster> bac, try that: get a checkout of the trunk
<gary_poster> uncommit
<bac> gary_poster: i think i could fix it locally and do an --overwrite
<gary_poster> bac, if you have a plan then go for it
<bac> all ears if there is a better way
<gary_poster> bac, fwiw, I always do manual merges with a checkout.  That always seems to be more obvious to me
<gary_poster> Maybe just me though
<bac> gary_poster: yes, it is.  but i was lulled by lbox and then when it failed i messed up
<gary_poster> bac, cool.  but anyway, it is worth fixing, and it soulds like you have a reasonable plan for doing so, so go for it
<gary_poster> and let us know when you are done :-)
<gary_poster> bac note that you may need to fix up staging
<gary_poster> uistage
<gary_poster> manually
<bac> ok
<bac> gary_poster: my plan won't work as i'd merged from trunk last night and those revisions that it pulled in are not easily recovered as discrete checkins
<gary_poster> bac my plan was this:
<gary_poster> get checkout
<gary_poster> uncommit until we are where we were before you pushed
<gary_poster> merge your branch
<gary_poster> would that work?
<bac> no, #2 is the problem since one of my revisions is a merge from trunk.  it collapsed several revisions
<bac> you can see it here: http://bazaar.launchpad.net/~juju-gui/charms/precise/juju-gui/trunk/changes
<bac> at r 20
<gary_poster> right
<gary_poster> um
<gary_poster> bac, I have trunk as of r15, but lbox messages are not there for r 14 and r15
<gary_poster> frankban do you have a pristine charm trunk hanging around on your machine anywhere by chance?
<frankban> gary_poster: yes
<gary_poster> bac bcsaller benji frankban hazmat Makyo teknico (not here): call in 2
<teknico> ok, I made it :-)
<frankban> gary_poster: last revision: 15: Gary Poster 2012-12-17 [merge] Move markdown files to .md extension
<gary_poster> frankban, yeah that's it, I think.  bac, frankban has pristine charm trunk.  Could he push --overwrite to bzr+ssh://bazaar.launchpad.net/~juju-gui/charms/precise/juju-gui/trunk/ and get us back to a good place?
<bac> gary_poster: yes, i think so
<frankban> bac, gary_poster, trying: bzr push --overwrite bzr+ssh://bazaar.launchpad.net/~juju-gui/charms/precise/juju-gui/trunk/
<gary_poster> bac, frankban has fixed the world
<gary_poster> http://bazaar.launchpad.net/~juju-gui/charms/precise/juju-gui/trunk/changes
<gary_poster> benji, hazmat starting without you
<gary_poster> http://jujucharms.com/~juju-gui/precise/juju-gui
<bac> bcsaller: where is the lbox auth file?
<bcsaller> bac: I think its .lpad.auth or similar, checking
<bcsaller> bac: ~/.lpad_oauth
<bac> bcsaller: hmm, don't have one of those
<benji> gary_poster: my apologies for missing the meeting; I really wish my sound worked when not plugged in
<gary_poster> s'ok benji.  if it happens again, try an alarm :-)  
<gary_poster> hazmat, I did a two stage review of https://codereview.appspot.com/6936063/but am done.  I saw at least one thing you might want to address, but everything I wrote is just for your consideration, since I don't know all the details.
<hazmat> gary_poster, thanks, thats awesome.. naming is hard :-)
<gary_poster> :-)
<hazmat> gary_poster, i went with add because its clearly cumulative.. while set might be taken for an equality/total value
 * hazmat heads to reitveld to respond
<gary_poster> mm, I see what you mean :-/
<hazmat> gary_poster, s/(add|set)/update ?
<gary_poster> update_annotations...hazmat I like it better than add, but I think it falls into the same trap you mentioned for set: it is not clear that the annotations are merged
<hazmat> true though update tends to imply a merge to existing more than set
<gary_poster> hazmat, I think it is an improvement.  like you said, naming is hard
<bac> hi frankban, want to pair in a little while?
<frankban> bac, sure
<bac> frankban: ok, i'll ping you in a few minutes
<frankban> gary_poster: it seems that "make distfile" produces a tarball containing the "build" dir but not the "build-prod" and "build-debug" ones (which, AFAICT, are  required by the charm)
<bac> frankban: i started a hangout and invited you
<frankban> bac: joining
<hazmat> bac, just noticed your comment from earlier
<hazmat> re history.. eek
<bac> hazmat: it is cleaned now
<hazmat> bac, cool
<hazmat> bac, is that possible without an push --overwrite?
<hazmat> bac, just ping me when your done w/ frankban .. i've got some idle curiosity about it
<hazmat> gary_poster, benji did you want to discuss login challenges?
<benji> hazmat: I think I have a handle on things now.
<hazmat> benji, cool
<hazmat> benji, i was figuring the app needs a user object if it doesn't its doing login form, and retaining the creds, and using them on the conn, on a reconnect, it can just reauth with those creds on challenge
<hazmat> the reauth bit might need another branch after login-required lands in rapi
<hazmat> although possibly hanging off the reconnect logic callback in lib/reconnecting-ws.js
<benji> at the moment I don't have a distinct user object, but am retaining the creds so they can be resubmitted
<hazmat> explicit seems nicer though
<hazmat> benji, sounds good
<bac> hi hazmat
<hazmat> bac, greetings.. so this was an accidental push instead of merge that augmented the trunk history with your branch commits?
<bac> hazmat: yes, since lbox was broken for me i accidentally did a push from my dev branch.
<hazmat> bac, what went wrong with lbox?
<bac> hazmat: i've moved a vm to a new computer and here lbox throws exceptions when trying to authenticate with google
<bac> anyway, had i been working manually i would've merged into a local clean version of trunk and then pushed it.
<hazmat> bac, it should recover from that.. but you can manually delete the lbox google cache @ ~/.goetveld_codereview.appspot.com
<teknico> bac, remember that "build" function in the charm "install" hook? I lengthened it a bit :-) (but still no test)
<bac> teknico: that's ok, frankban has redone it anyway
<teknico> bac, oh no...
<hazmat> bac, if it happens again its probably helpful to pastebin the  lbox -debug output
<hazmat> bac, thanks 
<teknico> ok, more conflicts, get 'em all to me, I can handle them!
<gary_poster> teknico, don't you need to change exposing 80 to 443
<gary_poster> teknico, you will win :-)
<teknico> gary_poster, I'm sure there's broken stuff in there; unfortunately, I cannot seem to run charm tests :-/
<frankban> brace yourself, conflicts are coming...
<gary_poster> :-)
 * gary_poster hangs on to treadmill desk for dear life
<frankban> :-)
<teknico> gary_poster, and yes, that's one of them
<gary_poster> teknico, I had another few small comments from a code review, which I posted.  You should receive them soon if you have not already.  trying the charm itself now.
<hazmat> teknico, incidentally the rapi tls branches from frankban are merged and support specifying the cert directory
<teknico> gary_poster, yes, I just pushed a few changes
<gary_poster> cool
<teknico> hazmat, great, that's useful for the next card
<hazmat> teknico, if your having issues with the test runner jimbaker might be able to help
<jimbaker> gary_poster, i've been thinking of getting a treadmill desk in the new year
<teknico> hazmat, there were a few problems in my code, and then it's the usual slowness
<gary_poster> jimbaker, lately it's been a standing desk, but I generally like it and have gotten a lot of use out of it.  I had an existing treadmill and then added the desk on top of it
<teknico> I'm hoping frankban is fixing that, or has already fixed it by now
<jimbaker> teknico, re test runner (i assume using jitsu test), definitely interested in feedback
<teknico> I sure hope all those conflicts won't be for nothing!
<gary_poster> teknico, you fixing the conditional I pointed out too?
<jimbaker> note that there's some outstanding work on it, but seems like everything has a current workaround
<teknico> gary_poster, yes, thanks for that too
<jimbaker> before i push in the next version
<gary_poster> cool teknico 
<gary_poster> welcome
<jimbaker> gary_poster, i use the bar in my kitchen as my standing desk
<hazmat> jimbaker, we've been heavy users of it i think, doing tdd on the gui charm
<jimbaker> hazmat, excellent to hear that
<hazmat> i suspect some of the issues are just slowness around juju.. it would be nice if the apt_update/upgrade cloud config thing where an option.. because that eats up significant time on an instance startup and adds to test time
<jimbaker> hazmat, is that a controllable option from juju?
<bac> hi benji, got a second for a quick call regarding making releases?
<hazmat> jimbaker, no.. its a hard code
<jimbaker> hazmat, got it
<benji> bac: sure
<jimbaker> iirc there was a thread on this
<hazmat> jimbaker, we originally defaulted to not doing, do to an accidental key mispeling, but spampas fixed it in oct i think, now its pretty arn slow to do things.
<teknico> ok, I'm running tests again, let's see what happens
<bac> benji: normal hangout
<benji> k
<hazmat> it magnified the hp cloud instance startup time by almost double
<jimbaker> hazmat, got it
<frankban> bac: email sent
<bac> tahnks frankban
<gary_poster> ack jimbaker. :-)  re: speed, a big part of it is building the gui itself, we are pretty sure, so using releases should help a bunch.  re: testing with jitsu test, we have http://bazaar.launchpad.net/~juju-gui/charms/precise/juju-gui/trunk/view/head:/HACKING.md jimbaker, which might be good for other people to follow to get experience with the test command
<gary_poster> before it lands
<teknico> frankban, is your card out of the woo... I mean, prototyping now? ;-) Are those conflicts coming? :-P
<jimbaker> gary_poster, btw that version of jitsu test is in the ppa; however, i believe running it that way gets around a problem w/ autotools
<gary_poster> jimbaker, you mean running it the way we document gets around a problem?
<jimbaker> gary_poster, correct
<benji> bac: one of us froze 
<gary_poster> ok cool.
<frankban> teknico: yes and yes, moving the card to "coding"
<jimbaker> gary_poster, i'm sad to see the 40m timeout !
<jimbaker> but purely a function of the env
<gary_poster> jimbaker, yeah :-/ like I said, hopefully that is largely on our side.  I'm sure it will be slower than we want still, but we think a good chunk of that time is spent over the network getting things our build needs
<gary_poster> so we are fixing that
<jimbaker> gary_poster, yeah, it's definitely on the extreme side of things. i believe the default timeout for jitsu test is 10m, and this was based on empirical observation
<gary_poster> teknico: nice to have would be redirect from 80 to 443
<jimbaker> mediawiki on ec2
<gary_poster> teknico, easy nginx?
<gary_poster> easy on nginx I mean?
<gary_poster> jimbaker, yeah 10 would be a lot better than 40 :-)
<jimbaker> :)
<gary_poster> teknico, starting charm fwiw, to see how it works in practice
<teknico> gary_poster, yes, we can redirect from 80 to 443 if useful, it's easy
<teknico> gary_poster, I started it 25 minutes ago, still no dice :-/
<gary_poster> teknico, let's do the redirect.  I have an install-error.  want to look at it with me?  I have a call in 10
<gary_poster> teknico, http://pastebin.ubuntu.com/1448193/
<gary_poster> a naughty, naughty s
<teknico> gary_poster, looking
<teknico> oh, nice :-/
<teknico> gary_poster, no, the "s" is intended
<bac> benji: man, even having a shelve makes 'make distfile' unhappy
<gary_poster> ?
<bac> shelf?
<benji> bac: it may be that the current approach is too paranoid about checking cleanlyness; we may need to dial it back
<teknico> drats, it was os.makedirs :-P
<gary_poster> right
<gary_poster> changing locally and retrying
<bac> yeah, i think having shelves is pretty clean
<teknico> gary_poster, in what logfile did you get that output?
<gary_poster> teknico, on unit in /var/lib/juju/units/juju-gui/charm.log, or something like that
<gary_poster> teknico, /var/lib/juju/units/juju-gui-0/charm.log
<gary_poster> trying install again, from debug-hooks...
<teknico> uhm, why do I have no /var/lib/juju/ ?
<teknico> oh, on unit
<gary_poster> teknico, did you start on unit?  IOW, juju -hooks
<gary_poster> right
<gary_poster> juju debug-hooks, that is
<gary_poster> dum da dum.  waiting on install.
<gary_poster> alsohave call now
<teknico> pushed the directory creation fix, gotta go now
<teknico> I'll add the redirect tomorrow, with the conflict resolutions
<gary_poster> bac approved
<gary_poster> https://code.launchpad.net/~bac/juju-gui/1091787/+merge/140528
<bac> hazmat: lbox errors  https://pastebin.canonical.com/80719/ and https://pastebin.canonical.com/80720/
<bac> gary_poster: thanks.
<bac> benji: quick look ^^ ?
 * benji looks.
<bac> hazmat: it says auth fails but it is different if i use a clearly bad password
<benji> bac: my two-factor auth is broken, I will look if you put them somewhere I don't have to log in
 * benji goes to ask to get that fixed
<bac> sorry benji, i meant the MP link that gary posted
<benji> ah
<benji> sure
<bac> i hope you can still get to LP
<benji> my browser has stored credentials
<bac> hazmat: it looks like the same lbox problem y'all discussed here: http://irclogs.ubuntu.com/2012/10/11/%23juju-dev.html
<bac> gary_poster: what version of the lbox package do you have?
<bac> benji: is there still a 'make release' target?  i don't see it
<bac> maybe it is now 'make dist'
<benji> bac: right!  it is "make dist"; thanks for realizing my mistake
<bac> so i need to s/make distfile/make dist/ and then add a description of 'make distfile'
<benji> exactly
<gary_poster> bac, distfile is still valuable
<gary_poster> distfile is what frankban will need to make a local, temporary dist in the charm
<bac> gary_poster: yes.  that is included in what i said
<bac> yes
<gary_poster> ok sorry
<bac> buttinsky!  :)
<gary_poster> trying to see version of lbox now.  was on call...
<gary_poster> :-)
<bac> looks like the bug may have been fixed in precise but not quantal.  are you on Q?
<gary_poster> bac, I am on lbox 1.0-57.64.39.11~quantal1
<bac> hmm, me too
<bac> weirdness
<bac> am going to try to build my own
<gary_poster> k
<hazmat> bac, as i recall that was an issue with a golang broken http impl.. afaik that's been resolved (though it regressed and was subsequently fixed again)
<hazmat> bac, if you have a pastebin output of the error that with -v or -debug flags that would be helpful
<bac> hazmat: well, it sure looks the same
<bac> hazmat: i pasted them above
<hazmat> ah
 * hazmat backtracks more
<bac> 15:46
<hazmat> rogpeppe, ping
<hazmat> doh.. he's done already
<hazmat> bac, for your local compile what's the version from $ go version 
<bac> hazmat: haven't gotten a local compile to work yet
<bac> i set GOPATH=/usr/lib/go but that isn't working
<bac> hazmat: but it is go1.0.2
<hazmat> bac, hmm... i show go1.0.3
<bac> hazmat: it looks like my golang did not come from the PPA
<bac> hazmat: assuming i get 1.0.3, how do i actually build lbox?
<bac> my lbox is from the gophers ppa
<hazmat> bac, i think the all in one command for it is..
<hazmat>  set gopath to a user writeable directory and then just ->  go get -v launchpad.net/lbox
<bac> hazmat: oh, i downloaded it and tried to use 'make'
 * hazmat tries it out as well
<bac> which throws up
<hazmat> bac, yeah.. the go toolchain has evolved from makefiles to a builtin tool
<bac> hazmat: so the Makefile is just a trap?
 * hazmat nods
<hazmat> bac, for compiling on disk src.. go install 
<hazmat> or go build
<hazmat> IANAGE
<hazmat> i am not a go expert ;-)
<hazmat> its got some magic syntax for recursive compile of dependencies .. like go install ... 
<hazmat> triple dot is recurse to deps
<hazmat> anyways... the all in one command is much nicer ;-)
<hazmat> you have to set GOBIN to a place it can install lbox binary
<hazmat> yup.. that worked for me... GOBIN=$HOME/bin GOPATH=$HOME/golib  go get launchpad.net/lbox
<hazmat> the nice part is that it pull source, so you can modify it.. and then just go install launchpad.net/lbox and it does the recompile install thing
<bac> hazmat: i made a local version and it still fails: https://pastebin.canonical.com/80724/
<hazmat> bac, yeah.. i think go1.0.2 is the one with the regression around http client
<hazmat> bac, i'd try the go version from the ppa
<bac> oh, right, i need to grab 1.03 first
<bac> righto
<hazmat> bac, you might have to blow away the $GOPATH/pkg dir.. its got the link library for the go reitveld lib that's barfiing and needs recompilation
<bac> yep
<bac> so if gary has the same lbox from PPA for quantal, i wonder why he isn't seeing this problem?
<gary_poster> so, the periodic issue we have with d3.v2.min.js is something to do with the symlink not being created properly...
<gary_poster> charm/juju-gui/app/assets/javascripts/d3.v2.min.js -> /var/lib/juju/units/juju-gui-0/charm/node_modules/d3/d3.v2.min.js
<gary_poster> That second path should have 'juju-gui' in it, like /var/lib/juju/units/juju-gui-0/charm/juju-gui/node_modules/d3/d3.v2.min.js
<gary_poster> s/periodic/intermittent/
<gary_poster> it makes me suspect that the problem is the makefile not being run from the working directory we expect
<gary_poster> which could be addressed pretty simply in the charm
<gary_poster> the charm tries to address it...
<gary_poster> I wonder if -c would work better
<gary_poster> some tools don't honor the form of cd that we use
<bac> hazmat: got go1.0.3 from golang-stable PPA, rebuilt lbox, same issue.  frustrating.
<hazmat> bac, argh!
<bac> lands by hand.  stand back.
<hazmat> bac, sorry, i'll rendevous with some go folks in the AM and try to dig deeper.. afaics their predominantly europe based @ juju-core
<gary_poster> Voila
<gary_poster> >>> with shelltoolbox.environ(NO_BZR='1'):
<gary_poster> ...     with shelltoolbox.cd('juju-gui'):
<gary_poster> ...         shelltoolbox.run('make', 'pwd')
<gary_poster> ... 
<gary_poster> '/var/lib/juju/units/juju-gui-0/charm\n'
<gary_poster> actually make -C juju-gui isn't any better
<gary_poster> interesting
<bac> cool
<gary_poster> >>> with shelltoolbox.environ(NO_BZR='1'):
<gary_poster> ...     shelltoolbox.run('make', '-C', 'juju-gui', 'pwd')
<gary_poster> ... 
<gary_poster> "make: Entering directory `/var/lib/juju/units/juju-gui-0/charm/juju-gui'\n/var/lib/juju/units/juju-gui-0/charm\nmake: Leaving directory `/var/lib/juju/units/juju-gui-0/charm/juju-gui'\n"
<gary_poster> We want to see /var/lib/juju/units/juju-gui-0/charm/juju-gui
<gary_poster> oh, wow, weird
<gary_poster> >>> with shelltoolbox.environ(NO_BZR='1'):
<gary_poster> ...     with shelltoolbox.cd('juju-gui'):
<gary_poster> ...         shelltoolbox.run('pwd')
<gary_poster> ... 
<gary_poster> '/var/lib/juju/units/juju-gui-0/charm/juju-gui\n'
<gary_poster> so it's the makefile's use of pwd in a variable that breaks things
<gary_poster> This
<gary_poster> ifeq ($(PWD),)
<gary_poster>         PWD=$(shell pwd)
<gary_poster> endif
<gary_poster> ah ha
<gary_poster> $(shell pwd) is always correct
<gary_poster> $(PWD), if it is set, may be wrong
<gary_poster> So simply setting PWD=$(shell pwd) should fix this
<gary_poster> unconditionally
<benji> gary_poster: it's not so much that PWD may be wrong, it is that sudo clenses the environment before invoking the subprocess, removing PWD
<gary_poster> benji, no
<gary_poster> this is a separate issue
<benji> oh
<benji> how is PWD wrong?
<gary_poster> it shows the PWD that you ran Make in, benji.  It ignores -C tricks, like make -C juju-gui, and it ignores the trick we use in our shelltoolbox to change the current directory
<benji> ah, yep
#juju-gui 2012-12-19
<bac> frankban: were you able to grab my branch?
<frankban> bac: yes
<bac> frankban: good.  i hope it is helpful.
<bac> see you tomorrow
<frankban> bac: it is, thank you, have a good day
 * frankban lunches
<gary_poster> teknico, re-reviewed just for the heck of it.  Looks good.  I had an important thought for an upcoming branch.  Are tests running now?  Do you just need a second review?
 * gary_poster cheers bcsaller1 
<bcsaller1> gary_poster: :) There may still be some issues but its a real improvement and Makyo already has a start on the next branch stacked on that one
 * gary_poster also cheers for a GUI branch that does  not touch the Makefile :-P
<gary_poster> great bcsaller1 
<bcsaller1> indeed
<gary_poster> bcsaller1, for kanban board, which one is Makyo working on?  Will drag it into the coding lane
<bcsaller1> relations
<gary_poster> ok thanks
<gary_poster> bcsaller1, if you review hazmat's annotations branch then he will have two reviews and can land, and will clear up space in secondary story
<bcsaller1> gary_poster: I'll do that this morning then
<gary_poster> thanks
 * teknico is officially back to work :-)
<gary_poster> frankban, benji or Makyo if you could give teknico his second review that would help move things along also
<gary_poster> hey teknico :-)
 * benji looks
<teknico> gary_poster, I did not yet run tests, only had time to make changes and push them this morning
<gary_poster> ack teknico
<teknico> I'd like to test that code a little more, at least manually
<teknico> probably a unit test on the "build" function would also be appropriate
<teknico> but would delay things more
<teknico> gary_poster, I'd also like to clear my head about something that puzzles me quite a bit, this: https://code.launchpad.net/~bac/juju-gui/1091787/+merge/140528
<gary_poster> teknico, do what you think is necessary for this to be acceptable, pushing things to another branch where possible.  If you want to talk through that with someone, me or anyone else, feel free, but I leave that decision to you.
<gary_poster> teknico, MP: which part?
<teknico> gary_poster, all of it. Can we have a quick call on it, with bac and possibly you and/or benji?
<gary_poster> teknico, bac is out today
<teknico> oh, great :-/
<gary_poster> teknico, I think bac did it because of some issues that frankban and he encountered.  frankban does that sound right?  anyway teknico, why don't you and I talk it through and then we can figure out if we need more people in on it.  let's see if juju-ui is open
<teknico> gary_poster, anyway, you approved that branch, so you likely have some knowledge/opinion on it :-)
<gary_poster> yes
<gary_poster> I'm in juju-ui teknico 
<teknico> gary_poster, sure, maybe frankban could have a say too, if bac discussed it with him
<gary_poster> teknico, I'd like the two of us to talk about it first
<gary_poster> then we can bring others in if necessary
<goodspud> Quick question: if I can download an installer for Juju to my Mac and run it form my desktop... why can't I do this in Ubuntu?
<gary_poster> goodspud, juju is in software center/debs; would be the equivalent of being in the Mac app store
<gary_poster> bcsaller, I got sidetracked.  Would a daily call be helpful today, or is the current happy state relatively obvious?
<bcsaller> gary_poster: I think we are doing fine today
<gary_poster> cool bcsaller, thanks.  I'll get back to review...at 11:30.  If you get someone else to beat me to it that's fine
<gary_poster> bac bcsaller benji frankban goodspud hazmat Makyo teknico  call in 2
<gary_poster> bcsaller, also IMO and in yellow's past, pairing counted as a review.  If we all agree with that then your branch already has a review from Makyo, yeah?
<gary_poster> bcsaller, starting without you
<gary_poster> bcsaller, want to tell me the issues on hangout for your speed, or here?
<bcsaller> back to hangout :)
<hazmat> bac, so apparently its golang 1.0.3 which has the bug for http client.. sadly that s the latest version.. 1.0.2 should work
<frankban> gary_poster: to create a stable release without needing to change trunk, it is ok to just modify CHANGES.yaml (replacing "unreleased" with a version number, and then "BRANCH_IS_CLEAN=1 FINAL=1 PROD=1 make dist"?
<gary_poster> frankban, I want to be helpful, but I don't like it as a precedent or as part of history (we want to be able to relate a release to a revision).  Maybe there's another approach we could have to make this fast.  Quick hangout in juju-ui?
<frankban> gary_poster: sure
<frankban> gary_poster: could you please review another Makefile quick fix? https://codereview.appspot.com/6965048
<gary_poster> frankban, approved and I'm ok with you just landing
<frankban> thanks gary_poster 
<hazmat> gary_poster, blame canada ;-)
<gary_poster> :-)
<frankban> gary_poster: release failed :-( the error seems to be related to BRANCH_IS_CLEAN, which executes "bzr missing --this". the latter raises a "bzr: ERROR: No peer location known or specified" failure.
<gary_poster> :-( hm
<gary_poster> frankban, use BRANCH_IS_CLEAN=1 and I will file a bug
<frankban> gary_poster: ok 
<frankban> gary_poster: trying BRANCH_IS_GOOD, because also IS_TRUNK_BRANCH does not seem to work with checkouts
<frankban> (it tries to grep for the parent branch)
<gary_poster> frankban, :-( it worked at one point.  benji ^^ I'll file bugs for this stuff
<benji> hmm
<gary_poster> frankban, I'm guessing when you make a temporary release in the charm you already are saying BRANCH_IS_GOOD?
<frankban> gary_poster: no, I only use NO_BZR=1. 
<benji> frankban: the release machinery is meant to be used with a branch of trunk, not a checkout
<gary_poster> benji, oh, that's not the way I had it
<frankban> gary_poster: and it works...
<gary_poster> benji, sorry
<gary_poster> frankban, sorry
<benji> gary_poster: we discussed this and decided branches would be at least as good as a checkout and arguably better 
<gary_poster> frankban, if it works then that's all I care about :-)
<frankban> gary_poster: no. it works in the charm, when I create a local distfile from a lightweight checkout
<gary_poster> benji, ok.  Maybe you could connect with frankban after this is done to run though the releae process
<gary_poster> that we have documented
<gary_poster> and figure out what could be documented better
<benji> sure
<gary_poster> thanks
<frankban> gary_poster: ok. proceeding with BRANCH_IS_GOOD?
<gary_poster> frankban, yes.  If we have a revision that is distinctly associated with a release, I'm happy for now.
<gary_poster> teknico, I filed low priority bug 1092199 and bug 1092204 per our discussions
<_mup_> Bug #1092199: Makefile build target is misnamed <juju-gui:Triaged> < https://launchpad.net/bugs/1092199 >
<_mup_> Bug #1092204: We copy YUI assets rather than symlinking them <juju-gui:Triaged> < https://launchpad.net/bugs/1092204 >
<teknico> gary_poster, great, thanks!
<gary_poster> welcome, thank you
<gary_poster> lp2kanban appears to be dead
<gary_poster> I think bac is the one with the keys
<gary_poster> bcsaller, I filed bug 1092208, and put both it and Nick's bug 1091616 in the secondary story tasks
<_mup_> Bug #1092208: Pending relation line is not getting events <juju-gui:Triaged> < https://launchpad.net/bugs/1092208 >
<_mup_> Bug #1091616: Unusual drag/zoom behaviour <regression> <juju-gui:Triaged> < https://launchpad.net/bugs/1091616 >
<bcsaller> gary_poster: thanks
<gary_poster> welcome
<frankban> gary_poster: done! https://launchpad.net/juju-gui/stable
<gary_poster> benji, "Checklist for Making a Release" in trunk begins with  Get a checkout of the trunk:: ``bzr co lp:juju-gui``. :-) I am making a bug to update this, and will ask you to do it when you get a chance next
<gary_poster> yay frankban! L0(
<gary_poster> :-)
<gary_poster> one-off smiley
<frankban> :-)
<gary_poster> benji, filed bug 1092216.  I asked whoever tackles it to consult with you; alternatively you can clarify the process in the bug; alternatively you can consult with yourself :-)
<_mup_> Bug #1092216: Release documentation is incorrect <juju-gui:Triaged> < https://launchpad.net/bugs/1092216 >
<gary_poster> oh lp2kanban, where are thou
<benji> heh
 * gary_poster completes filing bugs and goes to have a bit of lunch before reviews
<teknico> gary_poster, quick questio, how long did it take from deploy/expose commands to finish?
<teknico> I can't deploy a working environment, for some reason :-/
<gary_poster> teknico, about 20 minutes
<gary_poster> teknico, what does juju status say?
<teknico> gary_poster, I need to wait a little more then
<teknico> gary_poster, always this: http://pastebin.ubuntu.com/1450398/
<gary_poster> teknico, it's been less than 20 minutes?  If not, I would ssh  to the machine and do a top or ps and see what's going on
<gary_poster> look at the log too of course
<gary_poster> which might show that it is doeing something in the Makefile, which is another file you can tail
<gary_poster> doing
<teknico> gary_poster, using juju-ssh juju-gui/0 , as you mentioned?
<gary_poster> teknico ``juju ssh 1``
<gary_poster> it's the machine number.  maybe unit works as well
<teknico> ok
 * gary_poster steps back to lunch break, trying to fix disposal :-)
<gary_poster> yay frankban :-)
<gary_poster> teknico, if you are heading to your EoD soon and you are still seeing problems with your branch, consider trying to pass it off to me to see if I can move it along any
<gary_poster> I'm willing, and might have some time
<teknico> gary_poster, that's probably a good idea
<teknico> gary_poster, 40m now, not yet started, and "juju ssh 1" does not work either :-(
<teknico> maybe something wrong in my environments.yaml file?
<frankban> gary_poster: heh, the diff is a bit long, I am sorry, but there are a lot of tests
<frankban> at least
<gary_poster> teknico, weird :-/ if you want to have a call let me know
<teknico> gary_poster, I need to fix this problem in short order, but you're right, no need to hold this up any more
<gary_poster> frankban, yeah, I think you are forgiven for the diff length ;-)
<teknico> gary_poster, so consider the branch passed off to you :-)
<teknico> gary_poster, I added the docs and fixed the other "build" invocation as discussed
<frankban> :-)
<teknico> gary_poster, yes, if you have time maybe a (hopefully short :-) ) call could help
<gary_poster> teknico, join me in juju-ui whenever you are ready
<gary_poster> bcsaller, for some reason every one of the rietveld pages for your branch shows "error: old chunk mismatch."  Example: https://codereview.appspot.com/6971045/diff/1/app/app.js
<gary_poster> Any idea why?  Makes it difficult to review :-)
<hazmat> gary_poster, i suspect it needs a merge from trunk.. i noticed that as well
<hazmat> gary_poster, so its kinda of wierd
<gary_poster> hazmat, ah ok.  bcsaller could you try and fix?
<hazmat> gary_poster, you can got at it from the backside and it works..
<gary_poster> or redo or something
<gary_poster> hazmat, backside do you mean MP or bzr branch or someth?
<hazmat> gary_poster, i think it might an issue in reitveld
<gary_poster> ah ok
<hazmat> if you start from the index in the middle its okay https://codereview.appspot.com/6971045/patch/1/6
<hazmat> but if you start at the top and use j/k to navigate they all show that error
<gary_poster> oh, it is the side-by-side that is broken
<hazmat> gary_poster, yeah
<gary_poster> still not so good for reviews :-P
<teknico> hazmat, fyi, the eu-west-1 region does not seem to work with juju, at least for the juju-gui charm
<teknico> and now I'll go
<gary_poster> hey jimbaker.  I asked jitsu test for verbose logging with -v and it's not been as verbose as I hoped for. This is all I've got, almost 40 minutes into the test: http://pastebin.ubuntu.com/1450714/
<gary_poster> Did I do something wrong, or could I get better logs, or is this a place where jitsu test could do a better job in the future
<benji> has anyone else seen this?  I am running my tests by requesting "http://localhost:8084/test/?grep=login%20mechanism".  It only works intermittently.  Most of the time I get a completely blank page.
<gary_poster> I have not benji, but I haven't used grep in a while.  bcsaller or Makyo would be people to ask
<gary_poster> benji, also a problem in trunk?
<benji> I haven't tried on trunk.
<gary_poster> jimbaker, also, it looks like we don't have stdout/stdin from the test so we can't run debuggers, like pdb, which is a drag.  I think the debugging story right now is the most difficult
<gary_poster> given the logging and break point issues
<gary_poster> I need to run.  I'm still trying to figure out the charm test situation with nicola's branch.  I hope frankban has some good tips
#juju-gui 2012-12-20
<dguerri> this might not be the right channelâ¦ but.. is there some docs about the juju RAPI?
<teknico> dguerri, hi
<dguerri> hi, teknico 
<teknico> dguerri, not that I know of
<frankban> dguerri: you could find some info on setting up the rapi-rollup agent in the documentation included in juju-gui: http://bazaar.launchpad.net/~juju-gui/juju-gui/trunk/view/head:/HACKING
<dguerri> thanks frankban but I'm thinking about writing a ruby binding for the juju restful API
<frankban> dguerri: it's a websocket API, it makes use of good rest principles, but still it's not a rest API. Unfortunately, my I am not aware of a place where the stream is documented.
<dguerri> mmmh, so it might not be the right interface for a lang binding â¦ 
<bac> morning frankban.  how goes the effort?
<frankban> bac: it's under review, you can glance at https://codereview.appspot.com/6977043/ . Tests results are different based on who runs the suite.
<bac> frankban: oh, that's good.  keeps people on their toes
<frankban> dguerri: I guess it depends on what you want to achieve
<frankban> bac: :-)
<bac> frankban: is lp2kanban busted?  i see your defect in done-done has a bug but it isn't populated
<frankban> bac: it seems so
<frankban> bac: the same for other two cards in "ready to code"
<bac> yep.  i'll look into it
 * frankban lunches
<bac> frankban: lp2kanban is undead again
<gary_poster> hey benji.  I thought a fun improvement I could tackle today in very limited time might be to update the release docs a bit.  if that sounds ok to you and you are available to talk through things with me so I can pick your brain sometime, lemme know
<benji> gary_poster: sounds like a plan
<gary_poster> cool
<gary_poster> ty
<gary_poster> bcsaller, did you see what I meant about the rietveld review?  In a bit I'll make my own diff
<frankban> bac: cool thanks
<bac> it is not very robust wrt ill configured boards and projects
<gary_poster> bac, what cam we improve for poor configuration
<gary_poster> thank you for fixing btw
<bac> gary_poster: i just added some exception handling around the call to the board processing.  so if someone (<cough> green) isn't configured their processing stops but other boards continue
<gary_poster> heh
<gary_poster> ok cool thanks bac.  you shot a note to gmb too?
<bac> i've pinged him, waiting for him to return from lunch
<gary_poster> cool
<bac> brits and their ill-timed lunches
<gary_poster> Europeans and their ill-timed lunches!  Americans and their ill-timed desire to sleep through till the morning!
<gary_poster> :-)
<benji> Humans and their ill-timed biological needs.
<bcsaller> gary_poster: I was able to fix it, still don't know why it happened before 
<gary_poster> bcsaller, cool, reviewing, thanks.
<gary_poster> teknico, you are going to start bug 1074413, I'm guessing
<_mup_> Bug #1074413: GUI charm should require HTTPS connections to the environment by default <deploy-story> <juju-gui:Triaged> < https://launchpad.net/bugs/1074413 >
<gary_poster> bac, I made room for you on secondary story to start tests ofthe pan/zoom module, based on bcsaller
<gary_poster> 's branch in review
<gary_poster> hazmat if you could land your branch that would really help us keep the flow moving
<hazmat> gary_poster, eta 1hr
<gary_poster> thanks
<teknico> gary_poster, yep
<bac> gary_poster: ok
<bac> gary_poster: there is a card for bug 1083935 but it is blocked by 1077050 and 1077051.  only the latter seems to be fixed.  unblock it and carry on?
<_mup_> Bug #1083935: Environment pan/zoom code is not tested sufficiently <juju-gui:Triaged> < https://launchpad.net/bugs/1083935 >
<gary_poster> bac, yes, that's based on plans that have been superceded.  You are still blocked on Ben's branch, but since you are working from it, it's ok
<gary_poster> bcsaller, quick checkin?
<bcsaller> yeah
<bac> hi bcsaller, i just grabbed your current branch.  when i try to run the tests i get a time out on the first test and it stops.  anything different about running tests with your new work?
<bcsaller> bac; left a .only on one of the test that _is_ having issues, reproposed the branch w/o that , sorry
<bac> bcsaller: np, will grab new version
<bac> bcsaller: cool, it now works except for that one test failure
<frankban> gary_poster: hum... it seems that our debug server does not contain everything needed. I see this in the js console after switching to staging in a deployed charm: http://pastebin.ubuntu.com/1452506/
<gary_poster> frankban, ack on call will look soon
<frankban> gary_poster: thanks, and... problems also in the production server: http://pastebin.ubuntu.com/1452512/
<gary_poster> teknico, ^^^ ?
<gary_poster> will look asap
<teknico> gary_poster, looking
<teknico> frankban, so, what files are missing?
<frankban> teknico: I don't know, my understanding is that https, refusing to load external insecure resources, exposes a problem we have: our releases don't contain everything required by the GUI, and the YUI loader tries to fetch libraries from the net (e.g. ellipsis, markdown, timer)
<teknico> ah, I see
<gary_poster> sorry I didn't QA enough to catch that
<gary_poster> teknico, previous call ran over, sorry.  talk after standup?
<teknico> gary_poster, sure
<gary_poster> frankban, teknico we may need to revert the https code to let frankban proceed :-/
<teknico> gary_poster, right. I still did not manage to see tests complete successfully :-/
<gary_poster> teknico, I am afraid that this is going to be a very serious problem 
<gary_poster> bac bcsaller benji frankban goodspud hazmat Makyo teknico call ni 2
<frankban> gary_poster: I am not blocked, and I already merged trunk and resolved conflicts. And, AFAICT, this is a bug of the GUI, not of the charm. However, is uistage broken?
<gary_poster> frankban, ui stage is not broken
<gary_poster> because not served from charm, or from httos
<gary_poster> https
<gary_poster> but this means that the charm is now unusable
<frankban> gary_poster: yes
<gary_poster> yes the bugfix goes in the gui
<gary_poster> but meanwhile the charm is broken
<gary_poster> frankban, bcsaller starting at X:31 :-)
<frankban> gary_poster: so you are right, better to revert the changes. Even better if someone can confirm what I see.
<hazmat> teknico, http://bazaar.launchpad.net/~hazmat/juju/rapi-rollup/view/head:/juju/agents/api.py#L153
<teknico> hazmat, great, thanks
<Makyo> bcsaller, I think I figured out the resize thing.
<bcsaller> Makyo: ha, sweet
<Makyo> bcsaller, it's a little unfortunate :|  Resize events are only fired when bound using Y.on(), which we're not doing with the module event binding because of publish.  If I bind it in initializer in mega.js how it used to be bound, it works.
<bcsaller> Makyo: look at the change in the yui bindings in d3-comp though, it should cover that case, thats where I was getting stuck
<Makyo> bcsaller, Ah, I see it now.  Passing window as context gets the event to fire, at least, but then this is set to the YUI window node, rather than the module.  Is that the problem?
<bcsaller> the handler won't be able to pull the state it needs to run I think
<goodspud> hazmat, let me know when you are free to talk about PPAs, login, etc
<hazmat> goodspud, ack, 5m max
<hazmat> eta
<goodspud> cool
<hazmat> goodspud, juju-ui hangout
<Makyo> bcsaller, after target = Y;, add handler.context = null; and it works.
<Makyo> Not...sure why it doesn't like the context in there.
<bcsaller> Makyo: changing the context on a window event breaks it maybe... that is odd
<gary_poster> teknico, would you like to have a call, or postpone to tomorrow, or...?
<Makyo> bcsaller, does that get us closer to where we need to be?
<bcsaller> Makyo: I think, let me finish testing it 
<teknico> gary_poster, a call today would be better, I'll get back to you in a few minutes, thanks
<bcsaller> Makyo: yes, thanks alot, that working
<Makyo> Whew
<bcsaller> Makyo: the test is still failing, but I can track that down now that the event is properly handled
<bcsaller> Makyo: got it, going to push again :)
<frankban> gary_poster: re tls, e have another problem: we want, in the GUI to fetch data from http://jujucharms.com/
<bcsaller> gary_poster: makyo found the issue and I've pushed the updates, should I go ahead and land it now?
<teknico> frankban, I guess we can ask webops to enable https://jujucharms.com/ :-)
<teknico> gary_poster, re: call, main thing would be making tests work, if you could help me there it'd be great, otherwise we can postpone
<gary_poster> bcsaller, please land, yes
<gary_poster> thank you
<gary_poster> frankban, :-( hazmat do you have control over jujucharms.com?  Can you set up a cert and give us https access?
<bcsaller> gary_poster: woot :)
<gary_poster> bcsaller, reminder to please make the bug/card to fix the initial prod test run, or ask me to (happy to)  :-)
<gary_poster> teknico, https://codereview.appspot.com/6977043/#msg5 has Francesco's charm debug notes.  They are very good.
<teknico> gary_poster, yes, I read that email and saved it for future reference :-)
<gary_poster> :-)
<teknico> gary_poster, at first sight it did not help with my problem though, I'll have another look
<gary_poster> teknico, pair for a few minutes?
<gary_poster> up to you, only if you want to
<hazmat> gary_poster, i do .. what do you need?
<teknico> gary_poster, sure
<hazmat> gary_poster, i'm  a little confused
<hazmat> gary_poster, g+ for  a few minutes ;-)
<gary_poster> hazmat, GUI over https needs to talk to jujucharms
<gary_poster> ok :-)
<hazmat> hmm
<hazmat> it would be good to do so.. yes
<hazmat> but required.. not sure.. 
<hazmat> does the browser toss up any thing for async ajax request 
<hazmat> if its not https from an https page?
<hazmat> well not required atm is the questoin
<gary_poster> don't think so, in Chrome anyway.  frankban, ^^ ?
<hazmat> if not then its more a pending task that we can toss in the kanban .. just trying to determine immediacy of action
<gary_poster> I mean, I think it fails silently.  frankban has immediate experience
<hazmat> hmm.. i guess the websocket is a subresource that fails .. so its similiar
<gary_poster> right
<hazmat> but thats still a bit different since that what's we wanted encrypted
<frankban> hazmat: each request to connect to jujucharms is blocked by the browser, including charm info (e.g. one of the service detail tabs).
<gary_poster> frankban, silently blocked, yeah? in chrome?
<gary_poster> I see silent blocks in chrome, generally, and warnings you can bypass in FF
<hazmat> the issue with the websocket was its encrypted but with an non user auth'd cert
<hazmat> hmm
<frankban> gary_poster: in chrome yes, errors can be seen only in the js console
<hazmat> frankban, what's the error msg in the console?
<frankban> hazmat: similar to this one, but pointing to jujucharms.com: http://pastebin.ubuntu.com/1452506/
<hazmat> we're sending cors headers but their use case is the reverse..
<hazmat> frankban, gotcha
<hazmat> ok so its immediate. checking cert prices
<frankban> gary_poster: commented the code enabling TLS in the charm, last test run and then I'll land the branch
<gary_poster> thanks frankban 
<teknico> gary_poster, progress! I see machines running already :-)
<gary_poster> teknico, excellent :-)
<gary_poster> frankban, do you have a plan for attacking the gui https bits we talked about?I might be able to push it forward after your EoD if you do.  If not, no worries
<frankban> gary_poster: I think a plan could be to found a way to configure the YUI loader so that it never tries to download dependencies from the outside world
<frankban> s/to found/to find/
<gary_poster> frankban, right.  That's what thiago tried at one point.  That's probably the thing to try first
<bac> bcsaller i started reading your code to understand what you did and then ended up doing a review.
<bcsaller> bac: thanks, its submitted, but I can make changes in the next branch if need be
 * gary_poster restarts then lunches
<bac> bcsaller: ok, that's be good
<goodspud> Happy Yule Time Hugs everyone. Enjoy your holidays. I'm out of here.
<gary_poster> benji, when you have a quick sec to explain/remind what the expected release pattern is, please lemme know
<frankban> gary_poster: the branch finally landed \o/ . It seems to me that some modules (like gallery-ellipsis or gallery-timer) are not included just because they cannot be found under node_modules/yui.
<gary_poster> yay frankban 
<gary_poster> hm
<gary_poster> frankban, so they are not in the compressed file either
<gary_poster> so perhaps we just copy them over and serve them
<gary_poster> I'll try that :-)
<gary_poster> if I have time
<gary_poster> thanks and have a good evening frankban 
<frankban> gary_poster: it seems so (they are not in all-yui.js). you too
<benji> gary_poster: I am back from lunch and available at any time.
<gary_poster> thanks benji.  ony 9 min till next call, so maybe later :-)
<benji> gary_poster: k
<gary_poster> bcsaller, ping
<bcsaller> gary_poster: hey, whats up?
<gary_poster> hey bcsaller.  I am doing exploration on the https issues and messing around with things.  modules-debug.js gives this warning, which I vaguely recall:
<gary_poster> / The "requires" property should not be used here because the javascript
<gary_poster> / minimizer will not parse it.
<gary_poster> juju-topology requires files here, and then dupes those in its own definition
<gary_poster> Is it OK with you to rip out the ones in modules-debug, since AFAICT they are a dupe, and can't be used?
<gary_poster> (when compressed)
<bcsaller> gary_poster: yeah
<gary_poster> cool thanks bcsaller 
<bcsaller> thank you
 * hazmat gary_poster fingers crossed
<hazmat> whhops
<hazmat> happy holidays folks
#juju-gui 2012-12-21
<bac> good morning frankban and teknico
<frankban> hi bac
<teknico> bac, good morning
<bac> no mayan sightings in italy i presume
<teknico> bac, none that I know of
<teknico> bac, trunk and uistage are both broken right now, gary_poster's branch in review fixes them
 * bac looks
<teknico> just a fyi
<bac> teknico: ok, i'll review it now
<bac> frankban: are you working on gary's card or just reviewing it?  (your face is on it)
<bac> teknico: how is staging broken?  is there anything heroic i can do to get it up in the short term?
<bac> i can try to figure it out but wondered if you had thoughts
<teknico> bac, frankban and I already reviewed that branch, we're only waiting for gary_poster to land it
<teknico> bac, since trunk is broken, I assume staging also is as a consequence
<bac> teknico: i don't see your review here: https://codereview.appspot.com/7005044
<bac> also neither of you added tags to the kanban card
<bac> so i didn't think it was fully reviewed
<bac> tsk, tsk
<teknico> bac, right, sorry, the tags
<teknico> bac, I'll add them now, it was a pair review, as apparent from the review text
<teknico> oh, you added frankban's tag already, ok
<teknico> I'm having lunch  now
 * gary_poster is about to land, teknico and bac
<bac> gary_poster: cool
<bac> gary_poster: i'm logged into uistaging so let me know when it lands and i'll kick it in the shins
<gary_poster> thanks bac.  double checking then will let it fly
<gary_poster> bac, done.  note that the "build" directory will need to be manually removed--it is now called "build-shared."  thanks again.
<bac> gary_poster: i'll just let the cron job do it's thing at :00
<gary_poster> ok bac, but you may need to manually remove build still.  Maybe after :00 though, yeah
<bac> gary_poster: the cron job may blow everything away.  let's wait and see
<bac> ooh the excitement
<gary_poster> ok
<gary_poster> :-)
<bac> T-75!
<gary_poster> the tooth I had a root canal on officially cracked all the way through yesterday :-/  Gonna try to find someone who can pull it for me today so I don't have to worry about all during break
<bac> ooh, yuck
<gary_poster> yeah :-/
<bac> there is nothing left to put a crown on?
<gary_poster> no, just two halves
<bac> ugh.  that's gross.  i'm very squeamish about teeth issues
<gary_poster> :-) sorry 
<gary_poster> dunno what uistage looked like before but seems to be happy now
<benji> ooh, gary_poster; sorry to hear that
<gary_poster> thanks :-/
<bac> gary_poster: so the update worked with no intervention
<gary_poster> bac, awesome. I didn't know it blew things away
<bac> that kapil is smrt
<gary_poster> I mean, I expected it to work, I just didn't expect it to clear out the old build dir
<gary_poster> :-)
<hazmat> any preference on commercial cert vendors? godaddy, namecheap, thawte?
<bac> thawte!
<bac> nah
<bac> not godaddy
<gary_poster> I have a bad taste in my mouth from godaddy for various reasons, but that probably shouldn't influence you
<bac> i like gandi.net for domain registration.  they probably do certs.
<hazmat> namecheap is like 10/usd yr.. comodo cert based
 * hazmat checks gandi
<bac> i have a weird testing issue i haven't seen before.  my 'before' gets called if i run the whole suite, but if i run just the one group of tests it does not.
<bac> it jumps right into beforeEach
<gary_poster> bac, benji has been having slightly related issues.  his solution *might* affect your problem
<bac> gary_poster: it seems to have happened after i merged your latest commit.  :(
<gary_poster> (if he doesn't jump in to describe it I remember what he told me :-) )
<gary_poster> huh
<gary_poster> not sure what I would have done to influence that
<bac> gary_poster: but i may have merged other versions of trunk earlier.  can't recall the ordering.
<gary_poster> bac, if you push your branch I can try to help
<benji> bac: which is defined first, the before or beforeEach?
<bac> before
<benji> actually, that shouldn't matter because the tests (I assume) are defined after both
<bac> before, beforeEach, afterEach, it, it
<teknico> hazmat, I use gandi too, certificates included
<teknico> hazmat, startcom is nice too: https://en.wikipedia.org/wiki/Comparison_of_SSL_certificates_for_web_servers
<hazmat> teknico, thanks
<bac> benji, gary_poster: more oddness.  the problem only occurs with test-debug but not test-prod
<benji> that is odd
<gary_poster> bac, dunno.  :-/ like I said, happy to dig in if you think it would help
<benji> maybe the minifier is doing bad things to... something
<gary_poster> he said prod was good, debug was bad
<gary_poster> the minifier is automatically fixing our problems!
<gary_poster> who knew that skynet started with a js minifier?
<bac> gary_poster: you wanna pair or just grab the branch?
<gary_poster> bac, your branch you choose.  can do both
<bac> let's go to g+:\\juju-ui
<gary_poster> k
<benji> heh
<frankban> gary_poster: maybe we could consider byg 1086822 fixed?
<frankban> bug 1086822
<_mup_> Bug #1086822: charm is very slow to start <juju-gui:Triaged> < https://launchpad.net/bugs/1086822 >
<gary_poster> frankban, yes!  thank you
<gary_poster> mark as fixed by frankban :-)
<frankban> Cool, :-) first bug fixed between the coffee and the cigarette
<bac> benji: fixed it.  added 'done' to before() and it works.  verified another test that didn't use 'done' was broken too and adding it was the cure.
<bac> benji: add that to your test hygiene stuff you're presenting
<benji> bac: interesting; was the before() doing anything asynchronous?  Well, I guess it was.  Rephrased: do you know what it was doing asynchronously?
 * benji wonders when he started doing a presentation.
<bac> no
<bac> benji: gary said you had a list of things to clean up tests.  perhaps i misinterpreted
<bac> benji: the before just grabbed namespace references
<bac> juju = Y.namespace('juju'), etc
<benji> bac: hmm, I wonder if the done() call is adding just enough delay that the YUI modules get loaded.  If you are interested in experimenting, remove the done() and put in a busy wait that counts to 100000 or so before the namespace grabbing.  I bet it will work just as well.
<bac> benji: any theories on why it only occurs when running a test in isolation?
<benji> my hypothesis is that when run with other tests the modules have already loaded before the test is even started, so there is no race; when run in isolation there is a race between the (asynchronous) test runner and the (asynchonous) YUI module loader
<bac> benji: i removed the done and added this:
<bac>       while (!Y.Lang.isValue(models)) {
<bac>         models = Y.namespace('juju.models');
<bac>       }
<bac> and it works
<benji> much more elegant than a busy wait
<bac> benji: but i put the trap around the getting of juju which happens before, and models was still undefined
<bac> i thought they might all come available about the same time, but no
<benji> nope... ASYNCHRONOUS!
<benji> in 1000 years "asynchonous" may be a swear word
<bcsaller1> ... still be a swear word
<bac> benji: i read your previous comment as "ASYNCHRONOUS, BABY!" in the voice of dick vitale, fwiw
<benji> heh
<bac> so, in summary, the use of 'done' is an unrelated hack that just happens to work and muddies the water?
<benji> that is my strong hunch
<hazmat> ugh
<hazmat> benji, bac  does it matter if we pass async: false to the loader
<benji> hazmat: that helps some (and that is what my branch does; which I hope to land today)
<benji> I believe there is still a race even with that.  And I haven't been able to figure out how to remove it.
<bac> benji: with your branch try running 'juju application notification' in isolation
<benji> k
<benji> bac: 10 runs, all passed
<bac> good.  in the name of science, try on trunk?
<benji> sure
<benji> bac: does test-prod or test-debug matter?
<bac> yes.  i only see it fail on test-debug
<benji> k, that is what I used for running the test on my branch
<benji> three good runs and then "Uncaught TypeError: Cannot read property 'Database' of undefined"
<benji> 10 runs, 1 with that error
<benji> not a statistically significant difference between the two tests
<bac> that is the error i see
<bac> but i get it all of the time
<benji> bac: one thing to remember is that I have a slow computer, so the races seem to affect me less
<hazmat> argh have to setup email on jujucharms.com to finish the cert setup
<bac> benji: well i'm on a fast, new, shiny computer but running in a vm
<hazmat> bac.. mac?
<hazmat> just curious
<bac> hazmat: yeah, i looked around, considered the sputnik but couldn't live with the lower res and smallish display
 * hazmat tries to remember how to setup a mail server
<hazmat> ah.. google you've made it so easy to forget so much
<benji> hazmat: step one, get a google apps account :)
<benji> heh
<hazmat> benji, i would have except now they want folks to pay for it.
 * hazmat bails out to postfix
<benji> yeah, I had been meaning to set up my kids' email for a while and now I had to pay for it :(
<benji> but I've been using apps for free for about five years, so I don't feel to bad about it
<gary_poster> bac bcsaller benji frankban hazmat Makyo teknico_ call in 2
<hazmat> ah.. email used to be so much simpler.. i think i need domain keys setup
<mattuk1972> see ya juju team -all the best for 2013 - its been a pleasure
<hazmat>  mattuk1972 have a good one
<hazmat> mattuk1972, its been fun, good luck on the future
<hazmat> bac, testing out notification tests in isolation
<gary_poster> I think everybody was on depressants for that call :-P
<bac> hazmat: yes, that test fails in isolation as written
<bac> hazmat: is that what you are asking?
<hazmat> bac, yes
<bac> hazmat: and for that particular test, adding 'done' to 'before' makes it work
<bac> it looks to be related to what benji described with YUI and mocha async interactions. that test has before using the YUI.use() style setup
<bac> hazmat: unrelated, you assigned a card to francis, which is probably not what you intended.
<hazmat> doh
<gary_poster> :-)
<hazmat> assigned a card to posterity, today's his last
<hazmat> bac, which card?
<hazmat> bac, there's also some interaction with the browser cache trying to make these tests work, i either get a blank page, js error loading utils.js (registerHandler for handlebars), the database undefined error, or working tests.
<hazmat> er blank page with the util.js error
<benji> yep, I think the behavior around caching is part of the (or "a") race; loading the resources changes the timeings a bit
<hazmat> isolating just the notifiy tests in index.html makes things a little bit more sane
<hazmat> <!-- other tests -->
<gary_poster> oh benji, I thought we had a card to discuss your test pattern :-/
<hazmat> leads to a new non failure, failure mode.. where the test runner finds no tests, and no console errors.
<gary_poster> I forgoy yp ask you to talk about it explicitly
<hazmat> but also run sometimes
<gary_poster> s/yp/to/
<benji> hazmat: that failure mode is the one I was getting in my branch 
<hazmat> benji, why are there two different styles here?
<hazmat> describe wrapper vs yui wrappre?
<hazmat> the describe wrappers seem to be better behaved with the async: false 
<benji> I don't know for sure, I suspect people just tried different things at different times.
<hazmat> benji, ic... from history you added it to the test_notifications.js ... i'm going to remove that .. that's the issue with the non failure / failure
<teknico> hazmat, anyone else, does it make sense to try to connect to rapi via wss (encrypted) if the gui browser access is not happening via https?
<hazmat> teknico, no
<hazmat> teknico, commonly the cert for the wss is not valid without user ack
<hazmat> so the wss won't load/connect
<teknico> oh right, was forgetting about that
 * hazmat grabs some coffee bbiam
<hazmat> benji, confirmed that was the issue
<hazmat> test notifications running reliably now..
<hazmat> hmm.. no reviews on that commit?
<hazmat> https://codereview.appspot.com/6845084
<hazmat> that turns the actual fix into a one liner.. 
<hazmat> hmm.. firefox doesn't like extra param to the replace
<gary_poster> hazmat the yui wrapper was the solution thiago had advocated, that we tried for a while and then agreed relatively recently to discard.  So basically reverting https://codereview.appspot.com/6845084/diff/2002/test/test_notifications.js is the fix you have found?  (I have been unable to dupe some people's errors, btw, so just because it works on one machine unfortunately does not guarantee it is a solution for others
<gary_poster> , IME on this stuff)
<hazmat> gary_poster, in conjunction with async: false.. i'm still playing with it.. trying to make tests run in firefox
<gary_poster> cool
<hazmat> teknico, frankban did you guys have success with the gallery / loader issue?
<teknico> hazmat, gary_poster did :-)
<hazmat> cool
<hazmat> gary_poster, what was the solution?
<gary_poster> hazmat, change the base and explicitly host the gallery files ourselves
<hazmat> cool
<gary_poster> lunch and car to shop.  biab
<hazmat> working in firefox reliably as well. needs a tweak to mocha timeout
<hazmat> still some odd interactions between suits
<hazmat> ugh.. ordering issues
<hazmat> running application_notifications  tests before notification tests fails, but works fine in reverse
<hazmat> apologies, i'm in blather mode
<teknico> hazmat, when I run "juju deploy local:precise/juju-gui" and I have changes in the local copy
<teknico> hazmat, what's deployed, the modified local copy, or the latest committed revision?
<hazmat> teknico, if its already been deployed in the env.. it will use the cache copy
<teknico> hazmat, I run "juju destroy _environment" every time
<hazmat> teknico, so two axis.. one is namespace.. cs:  vs local:
<hazmat> teknico, those are separate charms to juju so it will always deploy what you tell it
<hazmat> teknico, second axis.. juju caches charms in the environment.. so if you update a charm locally and try to deploy again without incrementing the revision, it will deploy the older version
<hazmat> teknico, there's a -u/--upgrade flag on deploy
<hazmat> teknico, that will automatically increment the revision
<teknico> hazmat, oh, right, the revision
<hazmat> teknico, i suggest always using deploy -u local:precise/juju-gui
<teknico> hazmat, and running destroy_environment does not change anything, right?
<hazmat> teknico, it doesn't.. its stored in the control bucket which survives the env
<teknico> hazmat, great, thanks for the -u tip
<hazmat> i heard some rumor that juju-core may end up storing/deploying all the charms via git
<hazmat> i presume to address this issue
<hazmat> of easy mutability
<teknico> hazmat, via git? ;-o
<teknico> while working with juju, gnome-keyring-daemon blowing up and forcing me to enter gazillion passphrases is not exactly helping...
<hazmat> teknico, bad session?
<teknico> hazmat, it's been happening right after login for a few days now
<teknico> hazmat, how do I clean up the session?
<hazmat> teknico, i'd retry logout/login
<hazmat> or reboot if that fails
<hazmat> teknico, alternatively use a passwordless ssh key
<teknico> hazmat, it's happened on login right after boot for a few mornings now
<hazmat> for the env
<hazmat> er.. juju
<teknico> hazmat, uhm, yeah, where's it configured?
<hazmat> teknico, https://juju.ubuntu.com/docs/provider-configuration-ec2.html see authorized-keys-path
<hazmat> or alternatively authorized-keys
<teknico> ok
<frankban> hum... I am seeing "error: old chunk mismatch" in all files in my MP (at least in the side by side view)...
<hazmat> frankban, we saw that a few days ago in another mp. i would suggest trying to propose again
<hazmat> not sure what triggers that
<frankban> hazmat: trying...
<frankban> hazmat: patch set #2 works, thanks
<teknico> uhm, I'm getting: "Uncaught INVALID_STATE_ERR : Pausing to reconnect websocket"
<teknico> I think I need a way to locally test encrypted connections to rapi first
<benji> has anyone seen this error when trying to send data down the websocket?  "INVALID_STATE_ERR: DOM Exception 11"
<benji> the Internet says that it is because the ws isn't ready, but I am gating the call on env.get('connected') which is set from the we.on_open handler, so it should really be ready.
<hazmat> benji, which browser / version?
<benji> hazmat: Chromium.
<benji> version = whatever is current in 12.10
<hazmat> 22 then.. offhand not sure, i'd check the logs from the improv/websocket side just as a sanity check.. or from the browser net panel
<bcsaller> https://github.com/mbostock/d3/wiki/3.0
<hazmat> bcsaller, benefits?
<bcsaller> hazmat: not clear yet how much it impacts us, but the delta to support it looks small so its worth tracking the upgrade
<bcsaller> the smooth zooming plugin made it in tough, we might want to use that 
<hazmat> bcsaller, yeah.. the upgrade notes dont look like they'll hit us that bad
<hazmat> https://github.com/mbostock/d3/wiki/Upgrading-to-3.0
<hazmat> not sure though.. haven't looked at the env code in a while
<benji> hazmat: ooh, it is something about the ws not being ready even though env.get('connected') is true: instead of calling the login RPC right away, I put it in a setTimeout for one second later and the call worked
<hazmat> benji, we've got a transparently reconnecting websocket.. as well.. so reconnects could be happening.. connected should work unless there's a reconnect happening
<hazmat> benji, does it fail reliably?
<hazmat> without the timeout
<benji> from the improve.py log it doesn't look there are any reconnects happening
<benji> yep, very reliably
<hazmat> i wonder if we're firing connected to early then
<hazmat> benji, login should happen after the server greeting
<benji> hazmat: hmm, that may be it, env.get('connected') means the WS is connected, not that the server is ready
<benji> I can change around my event sending so it will happen after the greeting
<benji> another question, does the server conform to this: http://paste.ubuntu.com/1397723/
<hazmat> hmm.. not quite.. the error suggests something more fundamental.. the message would still go down the wire to the server
<benji> ah, indeed
<hazmat> but  in the interests of being well behaved, we shouldn't login till we get a helo from the server
<benji> well, if I wait until after the welcome message it will work either way
<hazmat> that's fairly classic for network old-school net protocols (pop, imap, etc)
<benji> re. conforming interface: it doesn't look like it
<benji> yep
<hazmat> making good progress on the testing front fwiw
 * hazmat grabs some food
<benji> hazmat: does the login process work like this: http://paste.ubuntu.com/1397723/
<benji> or I should say, it doesn't look like it works like that
<hazmat> benji, right.. login isn't required atm, till we have the ability to login.. else everything would break.
<hazmat> benji, but the login flow should be the same 
<benji> hazmat: in particular I am not getting and {'op': 'login', 'result': 'success', ...} messages
<benji> s/and/any/
<hazmat> benji, that's a bug/broken then in rapi
<hazmat> benji, what do you get on the wire in response to send_rpc login?
<benji> hazmat: I get a {"log": [["info", "Login success"]], "request_id": 2, "user": "admin", "op": "login", "password": "admin", "result": true} back
<benji> I could use that to know if the login was successfull or not, but "log" messages sound like something that could be turned off.
<bac> hi bcsaller, i have questions about the zoomHandler and rescale
<hazmat> benji, yeah.. the current structure on the log messages isnt optional.. it was to help the wrapping on cli stuff for feedback, i could disable the message for the login method, but its still going to come back with an emty log array
<hazmat> so that looks correct just w/ a delta to the initial proposal
<bac> bcsaller: nm
<benji> so I should be using the log message to know whether or not the login was successful, right?
<hazmat> benji, result: true
<benji> cool, thanks
<hazmat> benji, if it fails .. there will be an err: true instead per the pastebin
<benji> k
<teknico> gary_poster, I proposed my branch, but maybe shouldn't have, I added some disclaimers to not land without further testing
<teknico> gary_poster, it's also going to conflict with frankban's branch, that I also reviewed
<teknico> since it's EOY now, I thought I'd better put it out there so that it can be completed
<gary_poster> thanks teknico 
<gary_poster> If I have time I might try to resolve for the heck of it
<gary_poster> it would be cool to have this stuff really done :-)
<teknico> and for the heck of the objectives, yeah :-)
<gary_poster> teknico, you say "Also, this is not yet working while deploying manually, and needs
<gary_poster> further testing. Do not land without checking first."
<gary_poster> so, my crazy story would be this:
<gary_poster> - get frankban's branch.
<gary_poster> - turn https back on
<gary_poster> (hacking branch)
<gary_poster> try it out
<gary_poster> - merge your branch
<gary_poster> -resolve whatever needs to be resolved
<gary_poster> - try it out
<gary_poster> - (you say it won't work without some tweaks)
<gary_poster> (so fix tweaks)
<gary_poster> - profit!
<gary_poster> which might mean trying to land the combined branches
<gary_poster> yeah?
<teknico> gary_poster, that sounds like an eminently reasonable plan :-)
<gary_poster> heh ok :-)
<gary_poster> thanks teknico 
<gary_poster> teknico, frankban have a great holiday break!
<gary_poster> see you in 2013
<teknico> well, frankban's branch will likely be landable without problems
<teknico> but that's details :-)
<teknico> so, happy holidays everyone, and see you in the new year!
<bac> bye teknico.  have a nice break
<frankban> bye all, and happy holidays
<hazmat> frankban, teknico happy holidays
 * hazmat tries to deciper.. TypeError: Cannot read property 'charm-search-result' of undefined
<gary_poster> template is not compiled/included?
<gary_poster> that assumption that Templates is on juju-views module might simply be fragile
<gary_poster> looks reasonable on the face of ith though
<Makyo> Things work, tests pass, yuidoc explodes.  Ah well.
<gary_poster> Makyo, you know we have the helper command to make that disappear, right?
<gary_poster> yuidoc-lint complaints, I mean--I assum that's what you are talking about
<hazmat> gary_poster, bad dependencies it looks like
<hazmat> gary_poster, charm-panel.js didn't declare its use of juju-templates
<Makyo> gary_poster, What was the command again? I can get the ones that are just improperly formatted, at least.
<gary_poster> hazmat, looks like I have to restart.  Makyo lemme see if I can find it before I do
<hazmat> ack
<gary_poster> Makyo, ``make undocumented``
<Makyo> Thanks
<benji> hazmat: that error is one I have seen too; it happens when the Templates data structure has not been define yet
<hazmat> benji, yeah.. it looks like charm-panel wasnt including the dep, i included and got to a diff errr
<Makyo> gary_poster, Should I propose and work on docs in the meanwhile?
<hazmat> gary_poster, instead of rebooting again, let's table to next year ?
<gary_poster> hazmat bah
<gary_poster> ok :-)
<gary_poster> have a nice holiday
<benji> I never could figure out how the templates got loaded.  I'm glad you fixed it.
<gary_poster> Makyo, you mean while you are waiting on reviews?  docs would be good, or maybe bac or bcsaller could use a pair?
<bac> i'm good.  just slogging through tests.
<Makyo> gary_poster, Yeah, that's what I was thinking.  On lunch now, but can do whatever's best after.
<gary_poster> Makyo, cool.  frankban and teknico have charm branches that need reviews.  If your branch is up for review I'll also try to get to it ASAP
<gary_poster> talk to you after lunch
 * gary_poster restarts :-/ (G+ hangouts normally are not quite this flaky for me!)
<hazmat> aha.. forgot to poke a hole in the security group for inbound mail
<hazmat> aha. working email
<gary_poster> hazmat, is this complaint from rapi? does it indicate anything to you? http://pastebin.ubuntu.com/1455528/
<gary_poster> that is from a test run
<gary_poster> Makyo, "with undocumented methods and custom events, may get larger yet": undocumented methods were pre-existing though, yeah?
<Makyo> gary_poster, Yes, they just moved to different files, so the undocuented file didn't list them.
<gary_poster> Makyo, then don't worry about it for this round :-)
<Makyo> gary_poster, Alright.  May still need to document events fired, as was done with panzoom, but something for later.
<bac> hi bcsaller
<hazmat> gary_poster, its indicating the ws client is not valid
<bcsaller> bac: one sec, on a call with gary
<bac> ok
<hazmat> gary_poster, and then terminating the connection
<hazmat> and yes its from rapi
<gary_poster> hazmat, oh, right.  that may be ok then.  tests are failing for me
<hazmat> i assume this is from a wget to the endpoint in a unit test
<bcsaller> bac: whats up?
<bac> bcsaller: in panzoom/rescale fcn at the end it fires a 'rescaled' event.  is anyone using that right now?
<gary_poster> hazmat, yeah.  charm tests use a simple http check to see if the ws is there, and expect an error.  That's a red herring for whatever the problem is.  thank you
<bcsaller> bac: not as of that branch, but the viewport code and some of the menu repositioning code in service will 
<bac> bcsaller: can we do a quick chat?
<bcsaller> yeah, I'll see if normal g+ is open
<bcsaller> bac: it is
<Makyo> bac, bcsaller relations uses it.
<bcsaller> bac: froze there
<Makyo> gary_poster, ready when you are for call.
<bcsaller> Makyo: when you're done with the call give me a ping please 
<Makyo> bcsaller, Free now.
<bcsaller> Makyo: getting on g+ 
<benji> allrighty, the login branch is available for review at https://codereview.appspot.com/7007047
<benji> after I take a short break I will see if anyone else needs reviews
<bac> hazmat: i just got golang 1.0.2 and rebuilt lbox using it.  i still see the same problem authenticating.
<hazmat> argh
<hazmat> bac, clean build, sure about the executable ?
<hazmat> its possible they've slipped for multiple releases but that's sad
<bac> hazmat: oh, wait it is an old executable
<hazmat> gary_poster, cert should be in place by eod, just configuring nginx
<hazmat> going to run an errand, bbiab
<gary_poster> thanks hazmat
 * gary_poster has to go back to car shop
<bac> Makyo: could you review my panzoom test branch?
<Makyo> bac, in a bit
<bac> thanks
<bac> maybe it'll be on rietveld by then
<benji> yow, after merging in the trunk I get massive test failures
<benji> "Uncaught TypeError: Cannot read property 'notifier' of undefined"
 * Makyo dogwalkinates.
<gary_poster> benji, any resolution on that?
<benji> gary_poster: nope; I am pretty sure it is another initialization race, but I haven't figured it out yet.
<gary_poster> ok benji.  I think hazmat may have a fix-all-the-tests branch coming up
<benji> hmm, that is interesting: GET /juju-ui/templates.js 404 1ms - 54
<gary_poster> but I know that's not very satisfactory
<hazmat> gary_poster, incidentally your consistency in testing may be the result of browser cache
<gary_poster> hazmat, maybe so
<gary_poster> though I do clear it out for various reasons
<benji> ahh, a "make clean" and "make build" cleared up the tempate.js 404; it must have moved
<benji> most of the tests pass on my branch now
<gary_poster> um.  I think d3 just changed all their file names in their npm package.
<gary_poster> ah.
<gary_poster> we are getting 3.0.0
<bac> i'm going to call it a day.  i'll check back later and land my branch if it gets favorable reviews.
<benji> well, I guess I have a race to fix in the new year; see you guys then
<gary_poster> sounds good bac.  I want to go take a break too.  Have a great holiday.  I'll shoot you a review in a bit if noone else has
<bac> hope everyone has a good break.
<gary_poster> benji have a great break
<benji> gary_poster: thanks, you too!
 * bac o/
<gary_poster> hazmat, bcsaller, Makyo, have a great holiday, & see you in 2013!
<Makyo> See ya :)
<bcsaller> :)
<hazmat> gary_poster, happy holidays
<hazmat> <hazmat> still a work in progress.. but its up.. https://jujucharms.com/
#juju-gui 2012-12-23
<hazmat> the environment view tests are in bad shape
<hazmat> for some reason the topology-canvas class is getting stripped 
<hazmat> odd
 * hazmat tries a clean build
<hazmat> ah.. that was the ticket
<hazmat> odd that it didn't rebuild
#juju-gui 2013-12-16
<bac> morning benji
<benji> morning bac
<rick_h__> you all get some snow? well, benji 
<bac> benji i'm about to ask for an update to manage.jujucharms.com.  should i wait on anything from you?
<rick_h__> https://twitter.com/Earth_Pics/status/412390440936415232 is crazy
<benji> bac: nope
<bac> rt
<benji> rick_h__: nope, no snow here
<bac> rick_h__: ha, at first i thought those were snow pyramids in TN based on your question to benji.
<benji> heh
<rick_h__> heh, well you know how they love their TN landmarks
<benji> we do have one pyramid: http://en.wikipedia.org/wiki/Pyramid_Arena
<rick_h__> hah!
<bac> benji: great, government subsidized bass pro shop.
<benji> they forgot to ask me whether or not they should do that
<bac> benji: not quite as grand a failure as http://en.wikipedia.org/wiki/Ryugyong_Hotel
<benji> heh, yeah
<benji> maybe pyramidal development is a bad idea; the originals were tombs, after all
<bac> benji: i've heard BPS are quite the bullies, usually demanding free land from shopping centers since they are such a draw
<bac> good deal if you can get it
<frankban> morning benji: thank you for the great review, I updated the branch accordingly, would you like to take a look at the changes/comments?
<benji> frankban: good timing, I'm looking at it now
<frankban> cool thanks
<benji> frankban: explanations and changes all look great, thanks!
<benji> (I commented on the review too)
<frankban> benji: great! thank you
<bac> benji: hmm, we haven't updated the mongo charm on manage.jjc in several revisions ... so now they don't want to update it b/c the diff is too big and scary.
<benji> bac: hmm; can we update it one revision at a time?  (we'll have to test that particular combination to make sure it's cool)
<bac> benji: they introduced changes after 29 that were not pushed back upstream, so now the merge has trivial conflicts which cause panic.  i'm going to replicate what they've done and upgrade staging from my local charm.
<benji> k
<gary_poster> jujugui, smallest possible review that has an actual change, and very quick QA? https://github.com/juju/juju-gui/pull/23
<bac> gary_poster: i'll do it
<gary_poster> thanks bac
<bac> gary_poster: sorry but i don't know how to get this version for qa.  where would i find the url to pull from?
<gary_poster> bac, I use the instructions in the hacking doc--see "Helpful Git tools and aliases".  In this case, given that I've set up "juju" as my remote for the official trunk, I would use ``git qa-pr juju 23 qa-gary`` after having set up that alias
<gary_poster> Setting up the "juju" remote is also in that doc, bac: "git remote add juju git@github.com:juju/juju-gui.git"
<gary_poster> wow, not only can I delete the comments of others, I can actually edit them.  That is *awesome*. 
<rick_h__> gary_poster: yea, everyone is an 'admin' level so I think we've got super powers
<gary_poster> all reviews of my code from here on out will mimic bac's comment: "Code looks superb. LGTM."  I might occasionally choose different superlatives
<rick_h__> dealing with trying to fine grain it would be a pain otherwise because the permissions aren't super fine grained
<gary_poster> :-) cool rick_h__ 
<bac> gary_poster: those are limited to one line deletions
<gary_poster> bac, not if I can edit everyone's review, they 're not!
<bac> oh, excellent
<bac> gary_poster: ok, 'git status' shows that i have an unpushed version from friday.  i thought my branch landed and got merged.  now i wonder if something didn't make it through.
<gary_poster> bac, uh.  I only pretend to  know what's going on because I can paste things from the hacking doc. Ask rick_h__ ? :-D
<gary_poster> bac, though...
<gary_poster> you may not need to worry if it is in the main branch
<gary_poster> juju/juju-gui develop
<rick_h__> bac: there's another alias I sent around friday that I've not put in the docs yet to help with that. 
<rick_h__> bac: it means that your branch landed in remote juju, but in your own remote (your username) it's not been pushed
<bac> rick_h__: looking at github i can't find a changelog.
<rick_h__> so you can correct it with a `git push origin develop`
<rick_h__> bac: it's the 'commits' heading
<rick_h__>     # Update the develop from juju
<rick_h__>     juju-sync = "!f() { git checkout develop && git pull juju develop && git push origin develop; }; f"
<bac> doh
<rick_h__> bac: ^ will give you a new command `git juju-sync` which will pull any updates to the main repository and then push them up to your own develop fork
<rick_h__> assuming your remote is 'juju' (unlike hatch)
<bac> rick_h__: i ran that and got conflicts which seems unlikely.
<rick_h__> bac: ok, did you hve uncommitted changes?
<bac> rick_h__: i mean it is just supposed to update my repo from the version where i made some post-review changes
<rick_h__> if you look at that command, it changes your current branch to develop
<bac> fiik
<rick_h__> which if you've got uncommited changes could cause a conflict between WIP and the updated branch
<bac> i'm almost certain i do not
 * rick_h__ ponders if it should do a git stash first or something
<rick_h__> bac: sorry, then I don't have enough info to diagnose. What branch are you sitting on, is the conflict in something that was changed recently? 
<bac> rick_h__: http://paste.ubuntu.com/6583528/
<bac> rick_h__:  i was in my fix-stuff branch from friday.  after running the juju-sync it shows i'm in develop
<rick_h__> bac: you've got the wrong project as your origin. Sorry
<rick_h__> it's looking at the jenkins-github-lander repository, not juju-gui
<rick_h__> From github.com:juju/jenkins-github-lander
<rick_h__> it should be what gary_poster posted: git remote add juju git@github.com:juju/juju-gui.git
<bac> rick_h__: how'd i do that?
<rick_h__> https://help.github.com/articles/removing-a-remote
<rick_h__> bac: maybe I did a bad paste?
<rick_h__> sorry, I've got both in my history jumping between projects lately
<bac> rick_h__: from HACKING
<bac>     git clone https://github.com/juju/jenkins-github-lander.git
<rick_h__> or I've got a typo in the docs :/
<bac> yeah, i meant to ask about that but just trusted it
<rick_h__> it's updated
<rick_h__> yea, that was fixed last week. The HACKING docs are updated for it. Sorry about it
<rick_h__> bac: so use the github link ^ to remove the remote and re-add it
<rick_h__> bac: then you should be able to `git juju-sync`
<bac> rick_h__:  i think i need to first revert the changes from that juju-sync
<bac> rick_h__: 'git revert'  seems to want options that i can't make sense of
<rick_h__> bac: `git reset --hard HEAD`
<rick_h__> bac: git revert is about generating a diff to revert a file to an earlier rev usually
<benji> bac: do you know anything about charmwolrd and proof?  Charmworld has a config for proof port but (apparently) doesn't bother to actually start anything on that port.
<rick_h__> benji: it's used for the ingest process. So that it can talk to localhost vs the root port 80 url
<bac> yeah
<rick_h__> localhost chamrworld runs on 6543, but when you hit it via the cli tool it's the apache proxied proces on 443 (https)
<benji> rick_h__: yep, I got that
<rick_h__> benji: so I'm guessing it's not set because the ingest process gets it from the currently running app config? the port in the ini that the app runs on? /me hasn't looked in a while
<bac> thanks rick_h__, that cleaned up my mistakes
<rick_h__> bac: sorry about that :/ I need to hand out 'thank you for beta testing' stickes to everyone 
<rick_h__> stickers
<bac> rick_h__: fwiw HACKING is missing a closing quote on the qa-pr definition.
<rick_h__> bac: thanks, will update with the docs card on deck.
<bac> gary_poster: qa done.  the deleted header does not get rendered.  congratulations.
<bac> you can delete with the best
<gary_poster> bac, my pride knows no bounds.  Thank you. :-)
<bac> sorry it took me the better part of the morning to get there
<gary_poster> :-) np
<rick_h__> jujugui small test update review please https://github.com/juju/juju-gui/pull/24
<rick_h__> jujugui note this requires a manual upgrade of mocha-phantomjs which is installed globally in the HACKING doc and will not auto update. `sudo npm install -g mocha-phantomjs@3.2.0`
<rick_h__> bac: I'm not seeing the missing quote, did you mean on another line? https://raw.github.com/juju/juju-gui/develop/HACKING.rst 
<bac> rick_h__: it must've been in a prior version
<rick_h__> bac: ok cool. thanks for double checking
<bac> rick_h__: you could s/stick-headers/sticky-headers/ while you're there.  just noticed it.  :)
<rick_h__> bac: thanks, will do
<rick_h__> jujugui one quick note, you can often tweak docs straight from the webui. Go to https://github.com/juju/juju-gui/blob/develop/HACKING.rst for instance and notice the 'edit' link next to 'raw/blame/history'. It allows you to edit inline for a quick drive-by without going through review/landing. 
<benji> marcoceppi: I thought my recent branch had been merged into the 1.2 branch but I don't see it there or on trunk
<marcoceppi> benji: let me check, it was merged
<benji> I'm looking at bzr+ssh://bazaar.launchpad.net/+branch/charm-tools/1.2/
<marcoceppi> benji: OH I remember now. There was a discrepency between the repos, I had meant to merge after getting the git stuff sync'd with bazaar again but it must have slipped my mind
<marcoceppi> benji: I re-organized the project on the way back from a conference a month or so ago, it just never made it in to bazaar
<rick_h__> jujugui call in 6 
 * rick_h__ is lost without the normal warnings
 * gary_pos` is having issues
 * bac is a-ok
<marcoceppi> benji: your changes will be merged and release with 1.2.6
<benji> marcoceppi: cool, thanks
 * garyposter is having MS hate flashbacks, while trying to get password fixed
<garyposter> account.live.com says it needs to authenticate me by emailing or texting or calling
<garyposter> I have it text me
<garyposter> it gives me a code
<garyposter> "That code didn't work. Check the code and try again."
<garyposter> I have it call me.
<garyposter> it gives me a code
<garyposter> "That code didn't work. Check the code and try again."
 * garyposter so happy
<gary_poster> jujugui call in 2
<bac> benji: before the netsplit i offered to pair on the stuck bundle if you want.  going to eat now, though.
<gary_poster> luca__, hi.  thank you for relation line image.  When someone clicks on relation in box (fourth example down) what happens?  Note we can take them to a relation inspector page for either side, so we may want to allow directing to both sides.  Also, remember that a single name is actually insufficient to describe the relation...and we need to show relations erroring on one side or the other
<gary_poster> luca__, maybe worth a quick call to expand on that?
<Makyo> rick_h__, lgtm
<rick_h__> Makyo: thanks, sorry, almost self-reviewed but meh
<benji> bac: If we don't care to diagnose the issue we can just run bin/dequeue to get rid of it.
<benji> I have a copy of the data that is stuck if we want to attempt a local repro (which is what I would try if we want to diagnose the issue)
<bac> benji: if that's the case why not fix manage.jjc now and then diagnose locally now or if it happens again?
<bac> s/or/or later/
<benji> bac: that would be fine with me; the only reason not to would be if we really want to know why it is happening we need to be sure we can repro before clearing it
<bac> benji: i'll let you mull it over while i eat lunch.
<bac> and it won't be liver
<benji> heh
<bac> or tripe
<benji> I don't think its worth tracking down now, so a simple dequeue is good with me
<benji> two great tastes that are better together
<benji> darn, now I'm hungry
<luca__> gary_poster: If you are free for a call now I can answer your questions, also, we need to talk about the stuff we've discussed with Mark
<gary_poster> luca__, cool, let's do it.  https://plus.google.com/hangouts/_/7acpienfehsrht2ggbiqk9i0og?hl=en
<rick_h__> Makyo: gary_poster one thing to think about with that networking, I'd keep in mind the possibility of people trying to do poor man's cross env relations that way. One big environment, multiple networks, working on an HA distributed setup
<rick_h__> gary_poster: or frankban avail for a pre-imp on the charm change for updating to pull from git?
 * gary_poster not
<gary_poster> calls calls calls :-)
<rick_h__> wheee
<frankban> rick_h__: sure
<rick_h__> frankban: https://plus.google.com/hangouts/_/76cpim4h6nlsceotisgs317kdo?authuser=1&hl=en
<benji> rick_h__: at this point I'm considering wiping and re-indexing ES, is that 1) insane 2) easy?
<rick_h__> benji: 2)
<rick_h__> benji: sec, I can get you the RT that had the commands used to clear things out
<benji> the options weren't mutually exclusive, but that's good to hear :)
<benji> that'd be great, thanks
<rick_h__> benji: well, I'd go for 3) :(
<benji> rick_h__: 3?
<rick_h__> benji: 1) insane 2) easy 3) :(
<benji> ah
<benji> rick_h__: I'm working on the "make CI run the local browser tests" card and I've looked over the jenkins-github-lander code a bit but I don't see the obvious place to make my changes.
<rick_h__> benji: it should just be in the jenkins job config
<benji> ah
<rick_h__> benji: so login and go to http://ci.jujugui.org:8080/job/juju-gui/configure
<rick_h__> and add steps to the "Build" shell commands that run
<rick_h__> the idea is that the command must exit non-0 and then the rest of the system should kick in. 
<rick_h__> it would need it in both the juju-gui and juju-gui-merge builds
<rick_h__> benji: for testing, there's a link on the page once you've logged in for "Build with parameters" to manually trigger a build. It just needs some git reference to know what you want to build
<rick_h__> benji: just putting 'develop' in there or a sha string should work
<benji> cool
<benji> rick_h__: would you mind if we add a "ci-check" make target?  It is nice that the actual test running bits stored in Jenkins are straight-forward and I'd like to keep it that way.
<rick_h__> benji: yea, works for me. Maybe a saucelabs specific target?
<rick_h__> or you want to ci-check vs check? 
<rick_h__> I was thinking we'd keep the same make check but then after make check succeeds do a second 'make saucelabs' or something so that it keeps with local dev practice
<benji> rick_h__: I was going to make ci-check first run check and then the in-browser tests
<rick_h__> k
<bac> jujugui: feeling unwell with what seems to be two competing headaches.  going to lie down.
<benji> bac: darn; feel better
<rick_h__> bac: good luck die headaches die
<Makyo> gary_poster, let me know if you have a moment for a call sometime in the next little bit.
<gary_poster> ack
<gary_poster> almost
<gary_poster> Makyo, ready when you are.  lemme know/
<Makyo> Now's good.
<Makyo> https://plus.google.com/hangouts/_/7ecpi5tmtfd0i12os0cp6tt6ro?hl=en
<hatch_> terminal in devtools http://www.html5rocks.com/en/tutorials/developertools/devtools-terminal/
<hatch> someone was sitting on my nickname :/ 
<hatch> bac hey are you around?
<bac> hatch: what's up?
<hatch> so I ended up picking up a new MBP but Ubuntu looks like total garbage, all blurry and stuff
<hatch> How did you get yours to look good?
<hatch> apparently windows 8 now has charms... https://www.evernote.com/shard/s219/sh/1ca90ff7-0b47-4bf2-a631-639873211aeb/fd8f3960433b917b405afc95d23bc0b3 
<benji> heh
<bac> hatch: you mean in a vm?
<hatch> bac well right now I'm running 12.04 in a parallels vm to even see if it's possible, then once I get that up and running I'll attempt to install it on metal
<hatch> is yours in a vm?
<bac> hatch: yes, i'm using fusion.  and it does not support retina very well.  it is usable but it ain't retina.
<hatch> ohh I thought that you ended up getting the retina to work
<hatch> at the high resolution it looks good but its soooooo small heh
<hatch> and any smaller it just gets blurry
<hatch> :(
<hatch> hopefully Trusty will add high dpi support
<bac> i use 1920x1200
<benji> rick_h__: I reversed course on the ci-check thing since I was able to make test-browser behave nicely enough to just add it to "check": https://github.com/juju/juju-gui/pull/27
<bac> there was a high dpi discussion on warthogs.  i think the outcome was not before unctious uakari
<hatch> Hmm I'll try that res
<hatch> lol
<hatch> that would be funny if that's what 14.10 is called
<hatch> basically 'greasy monkey' :P
<hatch> well 1920x1200 still looks blurry but it's better than it was before :) 
<gary_poster> houston I mean rick_h__ , we have azure account liftoff
<Makyo> gary_poster, looks like we're go for within the quickstart session, but not outside of it.  Will put in some text for instructions regarding that.
<gary_poster> Makyo, great!  sounds like a reasonable way forward
<evilnickveitch> Makyo, what was that thing we needed to do to make Inkscape icons for charms show up in the GUI properly? It seems to have dropped off the instructions
<rick_h__> benji: awesome
<rick_h__> gary_poster: rgr working on creating an account for the list
<Makyo> evilnickveitch, save as optimized svg, check enable viewboxing. https://code.launchpad.net/~makyo/juju-core/enable-viewboxing/+merge/180354
<evilnickveitch> Makyo, thanks! I'll make sure it doesn't get lost this time
<gary_poster> rick_h__, you mean on existing box?
<rick_h__> gary_poster: so is the password just SSO?
<rick_h__> gary_poster: well I got an email to verify my email address from MS so assumed it's related?
<gary_poster> rick_h__, for azure?  no, unfortunately not.  shared creds.  trying to send emails.  
<rick_h__> gary_poster: oh, that went to the list no me directly, gotcha
<Makyo> evilnickveitch, charmworld now does this automatically, per https://code.launchpad.net/~makyo/charmworld/svg-viewbox/+merge/180400 so I don't know if it's strictly necessary. gary_poster c/d?
<gary_poster> jujugui, if you get an email today from MS about verifying your email, you probably don't need to.  check that it is from the new list.  If so, I am handling it
<gary_poster> rick_h__, check mail
<rick_h__> gary_poster: got it
<gary_poster> cool
<rick_h__> benji: installed x11-utils and rerunning your tests. 
<rick_h__> benji: hmm, it wants local firefox. so will have to chat on it
<rick_h__> benji: or I'm mis-understanding. I thought this was to trigger saucelabs tests
<gary_poster> benji and rick_h__ , goal is saucelabs when run from jenkins, right?
<gary_poster> +1 rick_h__ 
<Makyo> Pretty hard to push to lp when you moved your SSH keys aside :T
<gary_poster> :-/
 * Makyo dogwalks briefly, will get tests cleaned up and propose after.
<benji> rick_h__ and gary_poster: I must have misunderstood "Hook up browser sandbox tests with Jenkins" but its not a big worry because making it run the tests in saucelabs should be a one-liner change.
<gary_poster> yay!
<rick_h__> benji: ok cool
<benji> I'll take a look at it tomorrow.  Have a good evening all.
<rick_h__> benji: night, thanks
<gary_poster> I'm running away also
<gary_poster> bye all
#juju-gui 2013-12-17
<Makyo> jujugui quickstart review (again) - ssh 2.5 and 3.0 cards all in one: https://codereview.appspot.com/39610049/
 * Makyo beers self.
<rick_h__> Makyo: very cool
<rick_h__> well deserved, was the juju-core stuff helpful?
<Makyo> rick_h__, Pointed me in the right direction, yeah. Will always need an SSH agent, from the way things look, subprocesses can't add keys to existing agents, and using an agent is the only way to both verify and use keys.
<rick_h__> Makyo: cool, glad to see it work out. 
<Makyo> rick_h__, thanks :)
<rick_h__> I'm heavily on pre-bed meds so can't look now but will see if I can peek at it in the morning if you still need a review
<rick_h__> maybe frankban will peek before I'm up and at em
<Makyo> rick_h__, no worries.  frankban and gary_poster|away  will be on it tomorrow; I'm sure they'll have guidance on user-facing messages, either way.
<rick_h__> coolio
 * rick_h__ raises a glass in cheers for beating down the roadblock
<frankban> guihelp: anyone available for reviews? I need two + QA for https://codereview.appspot.com/42600044 and one (no QA) for https://codereview.appspot.com/43380043 (both quickstart). Thanks!
<BradCrittenden> frankban: sure
<BradCrittenden> gah
<bac> frankban: more specifically, i'll start by taking the first
<frankban> bac: thanks!
<bac> oh, another zope-lite branch!  :)  :)
<frankban> bac: nooooo :-)
<gary_poster> heh
<gary_poster> frankban, I will try to fit one in in the next 30 min.  After that slammed with back to back calls
<frankban> gary_poster: great thanks, FWIW the first one is more interesting
<gary_poster> ok cool
 * gary_poster starts frankban's "Quickstart base structure for views." branch review
<gary_poster> frankban, "Ran out of time, but I think this looks great.  Count me as an LGTM 'cause I
<gary_poster> know bac will do a great review. :-)"  Had a couple of trivial ideas
<luca__> gary_poster: do we have a hangout?
<frankban> gary_poster: great thanks!
<gary_poster> luca__, hatch, Makyo https://plus.google.com/hangouts/_/canonical.com/juju-gui
<hatch> morning all
<hatch> gary_poster sorry having connection issues
<rick_h__> jujuhelp looking for a tip on converting .crt to .cer file? Looks like maybe just base64 encode it?
<rick_h__> nvm
<hatch> rick_h__ it's gui-help without the dash ;)
<rick_h__> hatch: doh
<rick_h__> sorry, out of it this morning
<gary_poster> hatch up to you
<hatch> gary_poster I'll sit back and watch just to get up to speed on it
<hatch> my net is shot this am for whatever reason
<gary_poster> ack hatch
<gary_poster> Makyo, if you can get another qa/review other than me, +1. slammed till the mid afternoon
<frankban> gary_poster, bac : thanks for the reviews. gary_poster: since it will be used a lot, I'd like to keep make_aggressive_thunk short, maybe just thunk (not sure)?
<gary_poster> frankban, sure.  I was kinda being silly.
<frankban> gary_poster: cool
<hazmat> luca__, hatch so it looks like we're just going to do sprint logistics in the  mtg and cut it short.. ie. not worth attending.
<hatch> ok cool 
<Makyo> Gah :/
<hatch> sorry!
<hatch> :P
<Makyo> gary_poster, sorry, I didn't see the meeting alert until I got out of the shower :(
<hatch> Makyo summary: networking is hard
<Makyo> hatch, haha
<hatch> I'm learning so many new acronyms haha
<gary_poster> np at all Makyo was very early for you
<Makyo> jujugui call in 10
<rick_h__>  benji if you get a sec can you verify you can log into http://juju-azure-4loyqnke3w.cloudapp.net:8080/ with your account please?
<benji> rick_h__: sure
<gary_poster> jujugui call in 2
<benji> rick_h__: I was thinking of eating lunch in about 30 minutes and working on the search issue after that, does that work with your schedule?
<rick_h__> benji: rgr, sounds good
<frankban> Makyo: link to the MP?
<Makyo> frankban, https://codereview.appspot.com/39610049/
<frankban> ok ty
<bac> http://www.youtube.com/watch?v=0RMoH55T-oI
<rick_h__> jujugui looks like dns caught up. I'll be watching things in case of issues in transfer but should be back to good for gui landings. http://ci.jujugui.org:8080/
<gary_poster> awesome
<hatch> rick_h__ turns out it was a double dispatch race condition, solved by pushing the route event to the top of the event stack
<hatch> the day we get rid of double dispatch we should have a party haha
<rick_h__> hatch: cool yea figured as much
<rick_h__> hatch: glad it was a simpl-ish fix
<hatch> yeah it's kind of a hack but shhhh don't tell anyone
<hatch> jujugui looking for a quick review/qa https://github.com/juju/juju-gui/pull/28
<Makyo> hatch,  on it.
<hatch> thanks
<hatch> jujugui there is one more card to remove the fullscreen code and that's to remove the fullscreen flag from the charm. Does anyone who's working on the charm right now want to do that as a drive-by? Is it a drive-by-able fix?
<rick_h__> hatch: I can look into it. I'm tinkering with the charm currently. 
<hatch> cool thanks I'll put your face on the card
<rick_h__> hatch: put my face on it but not sure if it'll be drive-by or a new branch. 
<hatch> yeah no problem
<Makyo> hatch, code LGTM, QAing now. 
<Makyo> After that, I need to redo my VM on the MBA - software update busted the networking.
<hatch> :/
<hatch> I feel your pain, I spent over a day trying to get my new vm's up and running
<hatch> I gave up and just installed 12.04 heh
<hatch> On another note - it looks like Google is building Dart into Chrome 
<hatch> still probably a year away though
<hazmat> no surprise there
<hatch> considering you can write chrome apps with dart, and chrome apps are coming to android, you'll soon be able to write android apps in dart heh
<gary_poster> call; logging off IRC till over
<benji> rick_h__: it tool longer than I expected, but https://github.com/juju/juju-gui/pull/27 is ready for review; I had to reinstate the ci-check target in order for it to work sanely
<rick_h__> benji: rgr, looking
<rick_h__> benji: ok, so CI should be running make ci-check but then it still needs make check for lint/test-debug/etc?
<rick_h__> and make check will run test-browser, but with local browser so CI will need firefox, etc to run?
<Makyo> hatch, +!
<Makyo> +1
<hatch> THANKS
<hatch> oops
<hatch> :)
 * Makyo rescinds +1 :T
<hatch> I love that we now use :shipit: lol
<hatch> wow we have a-lot of tickets
<hatch> hmm what card to do
<benji> rick_h__: is there a way to get Jenkins to do a run with a different config?  I want to switch to "ci-check" instead of check and then run my branch
<rick_h__> benji: just edit the config and trigger a manual build
<rick_h__> benji: the sha you can pass is origin/pr/27/merge
<benji> rick_h__: but that means that anyone else's test runs will fail, right?
<rick_h__> benji: or if you wanted true isolation you can create a new job by copying the current one and then doing whatever in there. I'm not sure it's worth it in the low traffic space atm
<benji> ok
<rick_h__> benji: right, but hatch's branch just landed and not seeing any others in progress
<hatch> and mine is the only ones which matter
<hatch> me good at engrish too apprently
<hatch> BAH
<benji> jujugui: Jenkins will be broken for a few minutes, if you see a failure about running the make target "ci-check", it's my fault
<benji> rick_h__: I was under the impression that the Jenkins machine has an externally-routable IP; is that not the case?  My code is reporting it as 10.0.0.12
<rick_h__> benji: hmm, on azure it's a nasty dns. I'd just use the ci.jujugui.org address
<rick_h__> benji: but yes, originally it had an IP
<benji> rick_h__: ok
<benji> thanks
<benji> rick_h__: is there a firewall that would prevent external access to port 8888?
<rick_h__> benji: no, not that I'm aware of. There's no firewall on the machine at all
<rick_h__> benji: is the daemon listening on 0.0.0.0 vs 127.0.0.1?
<rick_h__> daemon/web service
 * benji looks
<benji> <sigh>
<rick_h__> that good eh?
<benji> bin/http_server.py uses BaseHTTPServer.test to run itself, which, first, is insane, and second, doesn't seem to allow configuration of where to listen
<rick_h__> oh joy
<hatch> time to switch to Node
<hatch> no? :P
<rick_h__> benji: looks like there might be ports. Working on seeing if I can tweak them
<rick_h__> benji: so don't change it yet,
<rick_h__> still running
<rick_h__> benji: ok, 8888 should be opened up. 
<rick_h__> http://ci.jujugui.org:8888/index.html
<rick_h__> benji: sorry about that, difference between the rackspace vs azure setup
<rick_h__> benji: also opening up 8889 so we can run these on different ports for the test job and the -merge job
<rick_h__> benji: so we'll need to be able to adjust that from the jenkins build script config
<benji> thanks; we may still have a local vs. external IP issue (127.x vs. 0.x)
<benji> nope, that looks good
<rick_h__> benji: true, but I did a python -m SimpleHTTPServer on 8888 and it worked ok so at least it's open
<rick_h__> woot!
<benji> rick_h__: is that still running?
<rick_h__> benji: no, turned it off
<rick_h__> benji: is this running in simulator mode so it's not looking for the wss connection?
<rick_h__> oh, there it goes sweet
<benji> it's really slow for some reason
<rick_h__> this azure machine has seemed a lot slower than the rackspace one we were on :/
<hatch> rick_h__ what kind of azure machine are you using? there are quite a few different kinds
<rick_h__> hatch: I went witha 2-core basic one
<hatch> in typical MS fashion it's divided up into different complex levels of features
<rick_h__> "Medium" linux 
<hatch> right but which...umm branch?
<hatch> hmm
<hatch> now I can't remember what they were called heh
<hatch> there are ones like ec2, and ones for websites which it turns off 
<hatch> if it's not being used
<rick_h__> it's a virtual machine
<rick_h__> not a website
<hatch> ohh ok, so those should stay up all the time then
<hatch> and for $95/mo it should be fast lol
<rick_h__> :/
<hatch> so what were we talking about in the standup?
<hatch> do they take these down too?
<rick_h__> I've got a call to figure out what's up with that in a bit. I guess MS takes some zones down/away sometimes
<rick_h__> I'm not sure at what level that is and such
<rick_h__> so I'll find out in a bit
<hatch> ohh, I was under the impression it was only for websites
<rick_h__> maybe it is and that's the warning. I'm not sure on the details yet
<hatch> ohh ok - do we really need a 2core? are we threading now?
<benji> rick_h__: it seems that the extream slowness it causing the tests to fail
<hatch> :(
<rick_h__> benji: try using the azure dns bit vs the cname and see if that helps? juju-azure-4loyqnke3w.cloudapp.net
<rick_h__> benji: and I'll see if I can get a direct IP to the machine, the slowness seems network related 
<rick_h__> so curious if it's some sort of dns/routing layers in azure?
<benji> rick_h__: both of those names resolve to the same IP, so that is not a likely cause
<rick_h__> benji: yea, grasping at straws atm
<rick_h__> jenkins itself is responding fine, not sure on the gui. 
<rick_h__> benji: maybe try production vs debug? It took 14s for me to download the JS files to get things loaded running it manually
<hatch> jujugui lf review for trivial inline doc updates https://github.com/juju/juju-gui/pull/29
<rick_h__> 282 requests :/
<benji> rick_h__: good idea
<benji> rick_h__: that won't work because prod wants to connect to a real environment
<benji> I guess I could hack on the config, but this is getting crazy
<rick_h__> benji: ah, true. :/
<rick_h__> benji: why not do it with your branch just to test the theory
<rick_h__> benji: adjust the config, see if we can get saucelabs to run on it
<benji> rick_h__: already done
<rick_h__> if so, then we can see if we need a ci-config or something
<rick_h__> benji: awesome
<benji> rick_h__: faster but the same error was generated; I now suspect the test sucks
<rick_h__> benji: +1 I bet this is existing failures because of the onboarding masking things and such
<rick_h__> "Other element would receive the click: <div id="onboarding-header-screen-mask">...</div>"
<rick_h__> that's the onboarding mask that's intercepting what we're expecting the test to verify we can click on
<rick_h__> benji: so I'd say works, but tests then need update to pass
<benji> rick_h__: any idea what causes the onboarding to show up when run remotely but not locally (the tests pass for me locally)
<rick_h__> benji: because it's using your browser and if you've ever clicked 'continue' it stores a localstorage key that you've always say ok
 * hatch stepping away for lunch
<rick_h__> so new page loads will not show the onboarding, while sauce is a fresh browser each time without the local storage
<rick_h__> benji: so I'd suggest we create a new job in jenkins to work through getting the sace labs tests passing. 
 * benji holds his tongue.
<benji> rick_h__: yep
<rick_h__> benji: then do cards for fixing the tests, etc and once we get them to pass, go back and put the sace checks into the main lander test suite
<rick_h__> sace/sauce
<rick_h__> benji: heh, not a fan of the local storage onboarding stuff?
 * benji makes weird, muffled sounds; as if he is speaking while holding his tongue.
<rick_h__> lol
<rick_h__> ok, well when your tongue is free love to hear your thoughts. 
<benji> the CI is back to the old config (well, not quite: the environment variable needed for "ci-check" is still there, so we just have to change "check" to "ci-check" once we get the tests fixed)
<rick_h__> benji: rgr, thanks
<rick_h__> hatch: running your tests and doing your review
<benji> rick_h__: https://github.com/juju/juju-gui/pull/27 is now ready for review; I'll make another card for fixing the tests and enabling them in CI
<rick_h__> benji: k, will look in a second. Trying to see if I can get it to pass real quick
<gary_poster> hey rick_h__ .  Your "remove fullscreen flag from charm" card ends with "get IS to update charm after fullscreen removal".  Should't we just remove that IS part and make a card for a release tomorrow, hopefully?
<hatch> gary_poster I assigned the card to him
<hatch> don't think he has looked at it yet
<gary_poster> ok cool hatch thx
<gary_poster> I'll update
<hatch> but yes - as long as we are ok with jujucharms not being updated
<rick_h__> gary_poster: I'm not sure how removing config values and such work. But yes, the idea is to remove the option from the charm, but make sure that it's done/gone from the deployed config
<gary_poster> hatch, we want jujucharms to be updated but after a release.
<gary_poster> a gui release
<gary_poster> rick_h__, ack.  that means that https://wiki.canonical.com/InformationInfrastructure/WebOps/CDO/JujuGui should be updated
<gary_poster> I will note on card
<rick_h__> gary_poster: rgr
<hatch> right right ok cool
<rick_h__> thanks
<gary_poster> ty
<hatch> new humble bundle btw https://www.humblebundle.com/
<rick_h__> benji: got a sec?
<benji> rick_h__: sure
<rick_h__> benji: https://plus.google.com/hangouts/_/7ecpjvi3krvead11h93mc92ga8?hl=en
<rick_h__> bah, note to self, don't monkey with azure settings while waiting on a test run :/
<rick_h__> not proper multi-tasking
<hatch> hah
<rick_h__> benji: ping, can you peek at the end of the build http://ci.jujugui.org:8080/job/juju-gui/124/console ?
 * benji looks
<rick_h__> benji: it's failing, but it seems only because it can't kill the process it's starting?
<rick_h__> benji: do you think we can tweak that to be an || true or something and then we're set?
<benji> rick_h__: I intentionally didn't do that because it would mask the failure mode of a pre-existing server (e.g., from a previous test run) which would mean that the test run isn't valid
<rick_h__> benji: ah ok. It looks like jenkins auto kills off things based on the link and spawing processes from build? Or am I mis-understanding that perhaps?
<benji> I don't think Jenkins killed it, because the job wasn't over yet.  It would be insane for it to kill things while the job is still going.
<benji> I don't know why the process was gone when the kill was attempted.
<benji> the "Process leaked file descriptors." bit is curious as well
<rick_h__> yea, ok. I'm going to rerunand ssh in and watch the content of that pid file vs ps
<rick_h__> benji: ah ok, that pid is wrong
<rick_h__> in the file is 6406 but it tried to kill 6401
<benji> that doesn't seem possible
<rick_h__> cat ci-check-gui-server.pid 
<rick_h__> 6406
<rick_h__> # Stop the background processes.
<rick_h__> kill 6401
<rick_h__> benji: so 6406 is the ../bin/http_server.py 8888 process
<rick_h__> while the other is the shell Xvfb :34
<rick_h__> so it should be killing the ci-check-gui-server.pid right?
<benji> it should kill both
<rick_h__> ah, gotcha. So the first one passes
<rick_h__> the second one fails
<rick_h__> benji: ok, the Xvfb pid is invalid. It's not running 
<rick_h__> benji: what is that doing since we're not running the tests locally?
<benji> rick_h__: nothing 
<benji> it is there so the local ones will run
<benji> I guess we can remove it, at least for the time being, but it is important that these tests be easy to run locally too
<rick_h__> ah, ok it's not installed so it's failing
<rick_h__> benji: woot, got it to work once. Adding a longer timeout for that initial page load and I think we're in business. Running a final complete test runnow
<benji> cool
<benji> rick_h__: re. multiple browsers: we'll have to run them one at a time, that's what the charm tests do
<rick_h__> benji: rgr, makes sense. 
<hatch> has anyone ever seen mocha keep loading the test files in a loop before? 
<hatch> tis very odd
<hatch> it seems to happen if I put the .only on the describe for the sidebar view
<hatch> rick_h__ when doing the `git rebase -i --autosquash` I needed to specify the develop branch
<hatch> is this an error in the docs or in my repo?
<rick_h__> I've not needed to. Did you branch come from develop?
<rick_h__> maybe it's auto picking up the origin for your branch
<rick_h__> or you've changed the origin?
<hatch> well it says that there is no tracking branch for my branch
<rick_h__> hmm, maybe I've got tracking auto enabled? I thought git auto tracked these days
<rick_h__> hatch: not sure tbh
<hatch> ohhhh
<hatch> sorry I see the issue now
<hatch> when I did grb there was an error which didn't create the remote repo
<rick_h__> benji: I'm going to close your pull request, land mine that's tweaked. Update the -merge job to match the other test one, and I've created cards for multiple browsers and the timeout I coudn't get right
<Makyo> Early dog-walk, starting to get rectangular tunnel-vision.  I reproposed https://codereview.appspot.com/39610049/ in case folk think it needs another looking-through; will land after if not.
<hatch> jujugui looking for a review/qa on https://github.com/juju/juju-gui/pull/31 plz and thanks
<hatch> gary_poster any tasks in mind for me now? 
<rick_h__> hatch: your pr fell into the crack here sorry
<rick_h__> hatch: have to wait a minute for the merging branch to land until your tests can run successfully
<hatch> rick_h__ it's ok, a dev can still review/qa 
<hatch> even if CI isn't working yet
<rick_h__> hatch: rgr, just a heads up
<gary_poster> on call
<hatch> cool np
<hatch> rick_h__ this removes a lot more of your hard work :P
<rick_h__> hatch: quick one is to update the doc links for github :)
<hatch> haha is that really a quick one? :P
<rick_h__> edit docs, make links go to relative filename?
<rick_h__> maybe there's a hidden secret in there
<hatch> rick_h__ https://www.humblebundle.com/store/p/europauniversalis4_storefront great game for linux apparently, and 75% off
<hatch> yeah I can do that
<rick_h__> hatch: ok, ci should be happy
<hatch> cool, so you can review my branch then too? ;)
<rick_h__> jujugui ci is running sauce tests, it'll take longer and there's a chance of a timeout issue that there's a card to work on. If you hit it then retry
<rick_h__> hatch: sorry no, way past my EOD and I've got to get out of here. 
<rick_h__> hatch: I can look in the morning
<hatch> haha ok np :) thanks for getting CI back up
<rick_h__> benji: moved your card to done
<hatch> rick_h__ do you know how to create rst links on github?
<hatch> just manually?
<hatch> or can it generate the index somehow?
<hatch> I'm going to guess it's all manual :)
<hatch> jujugui lf a quick documentation review https://github.com/juju/juju-gui/pull/32
<benji> hatch: CI failed because of a doc error
<hatch> benji yup just pushed a fix
<hatch> I had to do some reading up on sphynx directives first
<hatch> benji looks like the failure is a python one 
<hatch> now
<hatch> http://ci.jujugui.org:8080/job/juju-gui/135/console
 * hazmat digs the domain
<hatch> :) I'm not sure where it came from but it is pretty cool
<benji> "TimeoutException"  Have you tried turning it off and on again?
<hatch> very cool css processor that polyfills real css http://www.myth.io/
<hatch> benji haha
<benji> ooh, that's nice; and I hate CSS
<rick_h__> hatch: that's the timeout issue atm
<rick_h__> just retry
<rick_h__> I'll look at that in the morning. Need to figure out how to set web driver's page load wait time
<hatch> rick_h__ can I retry from github or do I have to do it in jenkins?
<rick_h__> loading all the JS from Azure to AWS in debug mode takes a bit :/
<rick_h__> hatch: ah crap, right. You don't have an account atm do you
<rick_h__> k, sec
<rick_h__> hatch: triggered, watch this next build
<rick_h__> hatch: if it passes then you can :shipit:
<hatch> ok cool
<hatch> rick_h__ could we maybe add a :retryci: or something?
<rick_h__> hatch: yea, supposedly, but not tried it/hooked it up
<hatch> ok cool
<rick_h__> for the -merge job it's easy, you delete the comment that it's in progress
<benji> I :heart: :shipit:
<hatch> haha yeah it's pretty cool
<Makyo> http://www.emoji-cheat-sheet.com/
 * Makyo helpful
<Makyo> Just in case you need :diamond_shape_with_a_dot_inside: in a comment
<benji> maybe retry can be :pray:
<benji> heh
<hatch> haha
<benji> "please pass, please pass, please pass"
<Makyo> :rewind:?
<Makyo> Or :repeat:?
<benji> I like :repeat:
<Makyo> If our LGTM is going to be a squirrel in a fedora..
<benji> :recycle:
<hatch> :repeat_one: should probably be retry :)
<hatch> making a  release should be :baby_symbol: lol
<benji> heh
<hatch> benji rick_h__  I just tried to land my branch and I got this error http://ci.jujugui.org:8080/job/juju-gui-merge/35/console
<rick_h__> hatch: pull from trunk
<rick_h__> git juju-sync
<rick_h__> hatch: the ci-merge is in the juju develop branch now but you don't have it
<rick_h__> ci-check that is
<hatch> ohh ok one sec
<rick_h__> hmmm, that sucks though because it's supposed to update trunk before merging your branch.../me adds a card
<benji> yeah, that's important
<rick_h__> yea, thought it was working :/
<hatch> rick_h__ https://github.com/juju/juju-gui/pull/32 here is the pr in case you want a reference
<hatch> it's been updated and running the CI again
<rick_h__> hatch: yea, got it. I was looking at it to make sure things went ok
<rick_h__> :( for no rebase to clean up
<hatch> I haven't re merged yet
<hatch> I can 
<hatch> what's the command for that again?
<rick_h__> you've got shipit, it'll land all three commits
<rick_h__> git rebase -i --autosquash
<hatch> oh git push --force
<hatch> well it has the 'merge request accepted' flag
<hatch> doesn't that mean it wont try and merge again?
<rick_h__> hatch: you're right
<rick_h__> hatch: sorry, making dinner, helping the boy with his lego man, and trying to help this through at once. :)
<hatch> rick_h__ because it's been pushed rebase was a noop
<rick_h__> hatch: gotcha, well you can git rebase -i HEAD~~~ 
<rick_h__> or just leave it, worry about it later on. 
<hatch> oh nice ~~~ :)
<hatch> rebasing
<rick_h__> sorry, just noted the 3 commits for a docs branch when checking out the pul request
<hatch> I like a clean commit history too
<hatch> so this rebase has commits from develop in it...can I squash around them/move the commits around in the list? Ever tried that?
<hatch> I better not heh
<rick_h__> yea, you can move them so that your commits are in order at the end of the line
<rick_h__> if you need to go bac farther in the history use more ~~~~~~~
<hatch> that looks to be the same as HEAD~n
<rick_h__> yea
<rick_h__> sorry, for some reason I'm used to adding ~~~
<hatch> ok trying to push the rebase
<hatch> oh great I somehow added commits
<hatch> ahhhh
<hatch> lol
<hatch> hopefully git will notice that those commits are already in develop and not re-merge?
<hatch> https://github.com/juju/juju-gui/pull/32
<rick_h__> we'll see :/
<hatch> I just really hope it doesn't break develop
<hatch> after the ci finishes i'll delete the flag and see if it merges properly
<rick_h__> hatch: rgr, worst case we'll manually hit develop and clean it up
<hatch> yeah I have a clean develop branch if need be
<rick_h__> woot, thakns hatch 
<rick_h__> sorry for the issues there
<hatch> no prob, but it looks like it created new commits :/
<hatch> https://github.com/juju/juju-gui/commits/develop
<hatch> thats less than ideal
<rick_h__> oh well, sorry
<rick_h__> I led you astray in trying to clean it up
<hatch> well....does that mean any time we merge develop into our branches it'll do that?
<hatch> or I wonder if it's a side effect of the rebase because the commit sha's are different
<rick_h__> I'm not sure, I can't think clearly right now
<hatch> heh no problem, I'm also past EOD :)
<hatch> we can chat about it in the am
<rick_h__> did you move them past your commit?
<rick_h__> or before them?
<hatch> they were after 
<hatch> the same order they are in the commit history
<hatch> I didn't actually have to move them
<hatch> that's where they were
<rick_h__> gotcha, that's why
<hatch> I don't follow
<rick_h__> so the idea should have been to rebase your commits after everything else in trunk. All the way at the end
<rick_h__> you told it to take these commits, and make them after my changes. Which means the tree needed to dupe them in order to do that
<hatch> ohhh
<hatch> woops
<hatch> well guess I learned something new today :)
<rick_h__> I *think* anyway
<rick_h__> cleaned up
<rick_h__> force pushed, carry on
<hatch> :)
<gary_poster> rick_h__, probably a good/fun idea for future, when comingsoon is no longer ours: run trunk on the jenkins machine, update it based on successful merges (i.e.,from the jenkins job), and make trunk.jujugui.org or something
 * gary_poster runs away
<gary_poster> thank you rick_h__ and benji for fighting the good fight.  I'll hear the details tomorry
#juju-gui 2013-12-18
<rick_h__> gary_poster|away: yep, the idea crossed my mind setting up the azure stuff today. Could just be like charmworld staging but on the azure setup
<rick_h__> hatch: around?
<rick_h__> hatch: replied to your email, updated pull request to #33. Sorry for the trouble. Will look into it, but should unblock and be able to move forward while getting the patterns/workflow straight. 
<dimitern> hatch, you around?
<dimitern> or any gui guys in fact?
<dimitern> I'm in the process of changing ServiceDeploy not to upload charm store charms
<dimitern> there will be a dedicated AddCharm API call that will do that and needs to be called before ServiceDeploy
<dimitern> this is just a heads up, nothing changed yet
<dimitern> i'll send a mail as wel
<rick_h__> thanks for the heads up and appreciate the email dimitern 
<dimitern> sorry I didn't include you rick_h__ , I'll forward it
<rick_h__> dimitern: all, all good. I was just trying to let you know we're listening. Most of us are later time zones so it's an empty space time of day to catch us in irc :)
<dimitern> rick_h__, cheers
<gary_poster> dimitern, hi. ack.  sounds dangerous for backwards compatibility, though fine otherwise.  I'll look for the email and reply.  When you get a chance, I'd also like a reply from you to the thread with the subject "Proposed juju core feature: serve arbitrary charm contents, or only icon"
<dimitern> gary_poster, hi, so about the GET functionality of the API server to fetch a file from within the charm
<gary_poster> yeah
<dimitern> gary_poster, I think we decided you guys can do it?
<gary_poster> dimitern, yes, but the discussion is about the spelling and approach, I think.
<dimitern> gary_poster, ah, ok, will take a look one more time
<gary_poster> cool thanks
<dimitern> gary_poster, I couldn't see any specific naming suggestions
<dimitern> gary_poster, but I seem to recall from previous discussions we thought of something like GET /charms?url=<charm-url>
<gary_poster> and what would that return?
<gary_poster> and/or where could I read about that, or who would know more :-)
<dimitern> gary_poster, perhaps we can add a &file=icon.svg (or any path relative to the root of the charm)
<dimitern> gary_poster, well, if you need both the full charm and a specific file from it
<gary_poster> dimitern, all we need are two things
<gary_poster> (1) specific file
<dimitern> gary_poster, if no &file= is given, it'll return an application/zip body with the binary archive of the charm
<gary_poster> (2) ls-style functionality
<dimitern> gary_poster, ah
<dimitern> gary_poster, so for (1), both url= and file= should be given and it can return the content in the response body, with the corresponding Content-Type set
<gary_poster> where url is, e.g., "cs:precise/juju-gui"?
<dimitern> gary_poster, and for (2) I guess we can have url= and &list perhaps? returning something you can display 
<dimitern> gary_poster, yes
<dimitern> gary_poster, no, actually, it has to have a revision as well
<gary_poster> dimitern, I think it would be nicer if this were paths
<dimitern> gary_poster, so cs:precise/juju-gui-42
<gary_poster> GET /charms/cs/precise/juju-gui/42/icon.svg
<gary_poster> GET /charms/cs/precise/juju-gui/42/ (returns ls for that dir)
<gary_poster> GET /charms/cs/precise/juju-gui/42/hooks/start
<gary_poster> GET /charms/cs/precise/juju-gui/42/hooks/ (returns ls for that dir)
<gary_poster> with ContentType specifying json
<dimitern> gary_poster, so how about a json-encoded response in the form of {Files: [{Path: "rel-path-inside-charm"}, {Path: ...}]}
<dimitern> gary_poster, hmm
<dimitern> gary_poster, that might be a bit more difficult
<gary_poster> oh, too bad
<gary_poster> prettier in the abstract IMO, but practicality is important :-)
<dimitern> gary_poster, what's wrong with GET /charms?url=cs:precise/juju-gui-42&file=icon.svg ?
<dimitern> gary_poster, no conversions between charm urls and paths
<gary_poster> IMO that is a path
<gary_poster> you are dividing up the path into a query string
<gary_poster> when in reality there's a single resource you want
<dimitern> gary_poster, it can be a path, if properly escaped, but it really isn't
<gary_poster> which is great for a ptha
<gary_poster> how not?  a path identifies a resource
<dimitern> gary_poster, charm urls are more like urls than file names/paths
<dimitern> gary_poster, they have a schema for example
<dimitern> gary_poster, to do what you propose the server-side handler has to be able to handle /charms/ and anything below it and convert that to a charm URL, then validate it, and most importantly not allow arbitrary other paths, like /charms/something/or/other
<gary_poster> dimitern, that's exactly true for the other spelling.  I think we simply disagree on the fact that one maps cleanly to the other, and that a path is preferable to a query string for identifying a resource, when possible.
<gary_poster> dimitern, how would you suggest I proceed?
<dimitern> gary_poster, well, it's ultimately up to who implements it
<gary_poster> dimitern, is not. ;-)
<dimitern> gary_poster, I don't really strongly object towards having a bit weird urls that look like paths
<gary_poster> heh
<dimitern> gary_poster, inside state/apiserver/charms.go is the place to start basically
<dimitern> gary_poster, there's the POST handler, a similar one needs to be implemented for GET and the I can see 2 less-than-trivial bits in its implementation
<dimitern> gary_poster, the proper url parsing and the actual fetching and extracting what's needed (either not a big deal)
<gary_poster> dimitern, cool.  So here's my takeaway from our conversation.  (1) broadly, you like the idea of adding a GET to somewhat mirror the POST. (2) no-one needs the ability to download a zip, so we should not implement it right now. (3) We should discuss the spelling a bit more with you and WIlliam over email and see where it goes. (4) technical details above (doesn't sound too bad; thank you)
<gary_poster> dimitern, is there already an API that says "show me all the charms you currently have"?
<dimitern> gary_poster, no
<gary_poster> dimitern, that sounds like another one we'd need then
<gary_poster> dimitern, any technical challanges there?
<dimitern> gary_poster, re (2) above, we might eventually need the ability to get charms from the API server as the single normative source of all charms in the environment, but we don't need it right away
<gary_poster> dimitern, ah ok.  so we'd want to make sure the spelling supports it, even if we don't implement it yet
<dimitern> gary_poster, it depends on what do you mean by "all charms" ? - just the URLs currently in state and the environment or more?
<dimitern> gary_poster, yeah, and that's a point against using "canonical" urls/paths - how can you distinguish between "list me the files" and "get me the charm" ?
<gary_poster> dimitern, good question.  contenttype would be my first answer.
<dimitern> gary_poster, using a trickery like "no slash => get the charm", "with trailing slash => list the files" seems horrible :)
<dimitern> gary_poster, you mean Accepts ?
<gary_poster> application/zip: get the charm
<gary_poster> json: get the metadata
<gary_poster> yeah
<dimitern> gary_poster, that's possible i guess
 * dimitern sorry, brb
<gary_poster> dimitern, np.  when you return, "all charms": our only real interest right now is local charms. we want to know what non-charm-store (local) charms are available to deploy.
<gary_poster> in the future there's lots of other possibilities
<gary_poster> such as the environment replacing charm store and charm world as a source of truth
<gary_poster> for the GUI
<gary_poster> but that's not where we are right now
<dimitern> gary_poster, back
<gary_poster> cool
<dimitern> gary_poster, so we can have a call like ListCharmURLs(schema string) []string -> json returning all charm URLs with a given schema
<gary_poster> sounds perfect dimitern, yeah
<gary_poster> I assume that would be pretty easy?
<gary_poster> (for us to do)
<gary_poster> (in GUI :-) )
<dimitern> gary_poster, and re Accepts, etc. above, i'd still prefer to have a ?list or something as part of the url to mean "get me the file list" otherwise, we'll get the zip
<dimitern> gary_poster, it'll need a state call to list them all and a couple of server/client API methods, but doesn't look hard
<gary_poster> ok cool
<dimitern> gary_poster, using ?list as part of the url we make the urls idempotent, which is important for a rest api imho
<gary_poster> dimitern, re preferring list over Accepts: ack.  May I treat you as my technical contact for this, officially approving and blessing designs, or do I need to include William?
<gary_poster> dimitern, don't see how the Accepts approach hinders idempotence.  What do you mean?
<dimitern> gary_poster, by all means, include william as well :)
<gary_poster> ok :-)
<dimitern> gary_poster, i mean /charms/cs/precise/juju-gui/42/ as an URL means different things depending on headers, which apart from the authentication code shouldn't have to happen
<gary_poster> dimitern, that's pretty common AFAIK.  Might be wrong there, and happy to do some research (and maybe come up with a solution better than one off-the-cuff :-) ), but it doesn't affect idempotence in the slightest, yeah?
<dimitern> gary_poster, well, for me returning different response bodies for the same URL seems a violation of idempotence, but maybe it's just me :)
<gary_poster> dimitern, the calls don't mutate state, and always return the same value for path plus content type.  Idempotent, open and shut, afaik, but I'm leaving it. ;-) I'll document these two approaches and see if I can come up with any other good ideas with the GUI team and then send them to you and William.
<gary_poster> thank you for the discussion and help dimitern!  Really appreciate it.
<dimitern> gary_poster, great, thanks for the discussion!
<hatch> rick_h__ wow you were up late :)
<rick_h__> hatch: meh, drugs made me crash in the evening and ended up getting up for a bit 
<rick_h__> hatch: still trying to kick the last of this crud :/
<hatch> I hear ya, thanks for the fix
<hatch> last night I found out that python-selenium pkg is not available on 12.04
<hatch> is this something we should add to the hacking docs?
<rick_h__> it's in the archive in the tree
<rick_h__> so you don't get it from apt
<hatch> ohh, well the hacking docs say otherwise :)
 * rick_h__ knows because he's just updated to .39 in his current branch
<hatch> also python-yaml is already installed so we can remove that from the list
<rick_h__> that depends on the system?
<hatch> I THINK it is installed with juju
<gary_poster> email, email, email, email...email, email, email, email...come on, everybody can sing it! :-)
<benji> rick_h__: let me know when you have time to pair on the bundle indexing issue
<hatch> I basically went through the hacking docs from top to bottom
<rick_h__> hatch: which you don't have to have to dev on the gui
<rick_h__> benji: rgr, few minutes. 
<gary_poster> python-yaml would be installed with old juju but not juju-core I think
<hatch> I also didn't add the gophers/go ppa
<hatch> I'd also propose we remove the sudo from the npm -g install and instead add instructions on chowning the proper dir's
<hatch> I of course would be more than happy to modify the doc :)
<gary_poster> +1 on principle
<hatch> gary_poster is there anything specific you'd like me to do now?
<gary_poster> hatch, is "Get rid of full browser mode" done?  Green card is still there, but I know that is pretty far along, if not done
<hatch> gary_poster I left the green card there until the charm flag is removed
<hatch> other than that it's all gone
<hatch> I think the total result was a -1600ln diff :)
<hatch> it's like rick_h__  didn't do anything for a month or so lol
<hatch> now*
<rick_h__> hatch: careful buddy
<rick_h__> hatch: a lot of that was working around tools I was given by a certain member of the team :P
<hatch> hahaha
<hatch> maybe I could work on getting rid of double dispatch
<gary_poster> hatch, oh cool and yay.  Options: (1) get rid of pre-inspector code.  (2) consider getting rid of namespace routing. (3) display unit errors on relation tab (that's not done, right?) (4) get rid of double dispatch (5) inspector unit destroy story: add âX units being destroyedâ section
<rick_h__> hatch: I'm not going to get to the search results thing with show/hide the sidebar for a while
<rick_h__> hatch: and there's the bugs around fixing the quick search UX
<hatch> gary_poster 3) the aggregate unit status is shown on the relations tab. 5) it shows them in the 'dying' category (at least it did, does it not any longer?)
<gary_poster> we agreed those quick search bugs were lower in priority than the others I mentioned, I think, though could be wrong.
<rick_h__> gary_poster: yea sorry, typing while you're typing
<rick_h__> trying to keep hatch from deleting more crap I've done :P
<gary_poster> lol
<hatch> lol
<hatch> gary_poster I'll run through the code for 1)
<gary_poster> hatch, (3) great.  (5) I believe it does, but luca's design includes what I described in addition
<gary_poster> hatch, wait, (3)
<hatch> waiting
<gary_poster> hatch: that's supposed to show all units with errors as well--not just the aggregate.  that's what #3 is
<gary_poster> sorry, you can still do #1--that's my pref, actually--but wanted to clarify #3 :-)
<hatch> ohh, do we have a design for that? I dont' think I've seen anything along those lines before
<hatch> ok will do 1 until we clarify 3
<gary_poster> yeah, lemme go to the folder
<rick_h__> benji: going to get a drink and then can chat. Let me know how you want to connect. hangout/rtc/etc
<benji> rick_h__: cool; I'll make a hangout
<gary_poster> hatch, go to https://drive.google.com/a/canonical.com/?tab=co#folders/0B7XG_QBXNwY1cWQ4TmRmRXJBc0E , click on "Inspector," and see seventh inspector image from left
<hatch> ohh right
<gary_poster> #5 is on far right, hatch
<hatch> I think #5 is as simple as changing a few css classes and whatnot when the status is dying
<hatch> right now it's under the 'pending' styles
<gary_poster> well, plus the message at the top, yeah?  also trivial, but another item
<hatch> yes yes, ok I'll create cards for these
<rick_h__> benji: rgr
<gary_poster> thanks hatch.  those are in the spreadsheet, fwiw, I've only been transferring things when I thought we'd actually get to them ;-)
<hatch> haha, well I have 3 more days 
<hatch> so I'll start knocking them off as best I can
<rick_h__> benji: BradCrittenden the ingest queue's on mjc are huge? queued charms: 8992, queued baskets: 353.
<benji> rick_h__: pfft!  that's not huge, call me when it gets to 1 million (I'm not kidding) :)
<rick_h__> :/
<benji> the ingest might have died again
<rick_h__> it's a cron job, did it get removed?
<benji> I thought it was under suporvisord.  IIRC, last time supervisord decided it had failed one too many times and stopped running it
<benji> rick_h__: https://plus.google.com/hangouts/_/72cpj9hm6qk6ajmdqd78d81lrc?hl=en
<rick_h__> jujugui small review please for saucelabs ci timeout joys https://github.com/juju/juju-gui/pull/34
<gary_poster> rick_h__, +1
<hatch> in typical Sublime Text fashion, 6 months have passed so there is an update, *see you in 6 months*
<hatch> :P
<gary_poster> hatch if you follow the dev releases it's a bit more exciting :-)
<gary_poster> not a *lot* more exciting
<gary_poster> but a bit
<hatch> haha colour me skeptical :P
<gary_poster> about what?
<hatch> that anything will change after ST3's release 
<hatch> it'll probably stall again 
<gary_poster> oh
<gary_poster> maybe
<gary_poster> dev releases have been happening once every 1.5 months or so, not counting bug fixes
<hatch> yeah that's what ST2 was like too
<hatch> I have little faith :)
<rick_h__> could be vim releases... "Oh hey, a new vim release. I didn't think they were still working on that."
<gary_poster> heh
<hatch> rick_h__ haha right but they aren't selling vim :D
<rick_h__> it's more of a "wtf more could they possibly add to it?"
<hatch> sane defaults?
<hatch> ooooo zing!
<gary_poster> test failure: sadness, rick_h__ :-/
<rick_h__> don't get me started "I bought a new laptop and nothing works" boy :P
<gary_poster> oh looks...unrelated to the timeout
<rick_h__> gary_poster: ah, I missed adding the makefile update to the new version of the file
<hatch> rick_h__ lol!
<gary_poster> oh ok cool
<gary_poster> rick_h__, why did pr test work then?
<rick_h__> gary_poster: it's not make cleaning atm but the -merge one is 
<gary_poster> ah, gotcha
<rick_h__> gary_poster: wanted to see how it worked on -merge since it's the more careful one 
<gary_poster> gotcha
<rick_h__> so good job -merge job! caught it
<gary_poster> heh
<rick_h__> oh bah, why can't I get all cards done at once
<hatch> rick_h__ sounds like you need to goroutine your brain 
<rick_h__> having fragile ci is almost worse than no ci
<rick_h__> and man it's getting cold again, to the fireplace!
<gary_poster> fragile almost worse than no: yup
<frankban> guihelp: I need two reviews + QA for https://codereview.appspot.com/43860044 (quickstart Environment list/selection view). Anyone available? thank you!
<hatch> rick_h__ you should buy a toque :)
<gary_poster> I will
<gary_poster> review
<frankban> gary_poster: thanks
<gary_poster> welcome :-)
<rick_h__> hatch: :P I did just scratch my pebble badly dealing with the fireplace the other day
<rick_h__> frankban: looking
<frankban> rick_h__: thank you
<rick_h__> namedtuples ftw! :)
 * rick_h__ <3's them
<frankban> :-)
<gary_poster> jujugui call in 10
<hatch> one of the very odd things about this MBP is it has no-friggen-idea how much time is left on the battery
<hatch> the 'time to empty' will vary by hours over the course of just minutes
<gary_poster> hatch in os x or ubuntu?
<gary_poster> have found ubuntu to have no idea
<hatch> osx
<hatch> ubuntu has it down
<gary_poster> but is x to be reasonable
<gary_poster> huh
<hatch> I know right? haha, my experience was similar to yours on my other machine
<gary_poster> :-)
<hatch> for example 3 minutes ago I had 9:05H left on the battery, and now I have 3:50
<rick_h__> quit playing games on it :P
<gary_poster> :-( that sounds its worth taking it to the apple store
<gary_poster> it's
<hatch> Ubuntu says 4.9H which makes sense
<hatch> because there is 85% left
<gary_poster> jujugui call in 2
<hatch> BOOM http://www.youtube.com/watch?v=1cOT4T2jDho ! RABBIT!
<rick_h__> http://www.amazon.com/s/ref=nb_sb_noss_1?url=search-alias%3Daps&field-keywords=little%20bunny%20foo%20foo&sprefix=little+bun%2Caps&rh=i%3Aaps%2Ck%3Alittle%20bunny%20foo%20foo
<gary_poster> hatch, um, sorry, but http://en.wikipedia.org/wiki/Little_Rabbit_Foo_Foo redirects to http://en.wikipedia.org/wiki/Little_Bunny_Foo_Foo
<gary_poster> open and shut, man
<rick_h__> wikipedia smack down
<hatch> I dont' think so, this is clearly a video and a song which says Rabbit
<hatch> and with almost 500,000 views!
<rick_h__> *couugh* made by a canuck *cough*
<gary_poster> lol
<hatch> hahaha
<hatch> actually Michael Rosen is British
<rick_h__> ok fine, your kind then
<rick_h__> king
<hatch> lol
<hatch> thats a very odd cultural difference haha
<rick_h__> I'm tired, medicated, and you keep killing my work. Are you expecting better? :P
<hatch> haha
<rick_h__> and damn it Dell, a monitor doesn't need to be 'in production' for 3 days. Either you've got it in a box or you don't. *grumble*
<hatch> uh oh
<hatch> you bought the 4k didn't you?
<rick_h__> ummm, maybe...want to buy a HD 21.5" on a monitor arm?
<gary_poster> heh
 * gary_poster jealous
<gary_poster> my old Dell 27" flakes out now and then and is pixel-y but haven't felt the need to spend the $$
<hatch> haha nice
<hatch> I would like some monitor arms for my monitors
<hatch> but I have too many monitors sitting around to buy more
<rick_h__> <3 monitor arms. Helps with a large desk surface since you can bring the monitor closer 
<hatch> yeah for sure
<rick_h__> and for aligning nicely
<hatch> I need to find a cheapish one for my 31" though
<rick_h__> but the ones I have aren't meant for a 24" display 
<hatch> the monitor is very heavy and so the arms are very expensive :(
<rick_h__> remember it's the weight withuot the base on it
<hatch> yeah it's still heavy
<rick_h__> the new one is 20# but only 10# once the base is removed
<hatch> let me know what arms you pick
<hatch> :)
<rick_h__> http://goo.gl/OnG7mi
<rick_h__> it's on the way
<rick_h__> http://goo.gl/ytQhIw
<rick_h__> is what I have now
<hatch> That damn force field on the 49th parallel """Shipping: Currently, item can be shipped only within the U.S."""
<rick_h__> come on down, we've got snow and cold too
<hatch> lol
<hatch> rick_h__ so when merging upstream into my local develop branch there was a conflict caused by the rebase I think
<rick_h__> k
<BradCrittenden> benji: if you look at the staging heartbeat and refresh every few seconds you see the charm queued count go down.
<benji> bac: that makes me lean toward the "we can't keep up any more" hypothesis
<bac> benji: if we're just not keeping up, it should increase again *now* :45 and then start going down again
<benji> yep
<bac> benji: yes, when the q cron started it jumped by a few thousand, and now the charm count is slowly decreasing.
<bac> benji: i think we'll also see the bundle count always goes up and never decreases
<frankban> Makyo: perhaps ssh-add cannot find the agent because we don't pass the env vars (SSH_AGENT_PID, etc.) when we run call(... ?
<rick_h__> a few thousand? ouch. I didn't think we had that many to ingest still. Wasn't it in the 300's?
<bac> benji: i'm tempted to run dequeue on staging
<benji> so, the next question is "does the count go down continually or does it plateau?" 
<bac> rick_h__: but we're queueing charm * up to ten versions
<benji> if it plateaus, then for some reason the ingest job stops processing at some point
<benji> (suggesting it hits some bad data or a bug that stops it from draining the queue as much as it otherwise could)
<bac> benji: well we'd probably just have to watch for a 15 minute cycle
<Makyo> frankban, I thought so too, but it can if we run our own agent, so I'm not sure.  Running it manually in ipython always gives me rc 2 even if I start an agent manually before starting ipython.
<bac> benji, rick_h__: we may just be bumping against the design issues that curtis mentioned a few weeks ago wrt the way we handle versions and overloading
<Makyo> I'll keep investigating, though
<bac> benji: so the number of bundles went up from 1056 before the latest queue run to 1078, an increase of 22.
<benji> bac: and the bundle queue length never decreases?
<bac> benji: so assume we really have 22 bundles.  1078 / 22 = exactly 49.
<bac> so 49 runs ago we started seeing a backlog.  a little over 12 hours
<benji> if so, that suggests that the ingest is failing in the middle because charms are handled first and then bundles
<bac> it suggests to me that it doesn't mean we're simply too slow
<bac> benji: otherwise the backlog would've happened earlier. does that make sense?
<rick_h__> Makyo: can you link the qa you need please?
<Makyo> https://codereview.appspot.com/39610049/
<rick_h__> thanks
<benji> bac: yep that makes sense; in other words, if we were to graph the backlog there is no straight-line slope that would get us back to the last time the queue was empty, implying something happened in the meantime
<bac> benji: basket count just jumped by 22 again to 1100
<bac> benji: yes
<bac> more elegantly stated, but yes
<benji> so it would seem that ingest is stopping in the middle
<bac> without logging
<bac> unless that beaker exception is relevant
<bac> benji: http://paste.ubuntu.com/6595233/
<benji> bac: but that exception is in the web app, right?  not in the ingest job
<bac> benji: yep.  ingest is not creating any logs.  grasping here.
<hatch> finally working on the new machine....wow this thing is fast
<hatch> now I see what rick_h__  works like
<hatch> like holy crap it's easily 2x as fast
<gary_poster> frankban, you got two LGTMs :-)
<frankban> Makyo: 2 comments: 1) we should catch for KeyboardInterrupt also when keys are not found (create_keys = raw_input...) and 2) if I hit "s" and I create the key, quickstart asks me for a passphrase again, even if the agent is started. Is this ok?
<frankban> gary_poster: great, thank you
<Makyo> frankban, 1) on it. 2) I think so, though maybe we should be clear to the user about which command we're running when the passwords are asked.  This might be fixed by further investigation of agents.
<frankban> Makyo: +1
<frankban> gary_poster: the return value from the views is what show(view) returns if you hit ^X (as opposed to an explicit AppExit raised from the views). all the env views return (env_db, env_data), the latter being none if no environment has been selected. since each view can be used as an application entry point, even the return value from env_detail can be used. we might want to decide, e.g. that if quickstart is run wi
<frankban> th -e we start the app showing the environment details. thoughts?
 * gary_poster looking fwiw
<hatch> gary_poster https://bugs.launchpad.net/juju-gui/+bug/1262295 blocking release?
<_mup_> Bug #1262295: Logging out/in causes canvas help overlay to reappear <juju-gui:New> <https://launchpad.net/bugs/1262295>
<gary_poster> frankban, I guess I don't understand how the return values are consumed by the loop.  I assume it will work once we allow edits because we are mutating the (function-local copy of the) env_db dict?
<gary_poster> hatch, if it affects a live environment, blocking.  otherwise high.  it will not affect jujucharms because we don't have a logout button, so if it doesn't affect a live environment then it only affects dev and comingsoon
<hatch> ok I'll fire up a live env and give it a check
<gary_poster> thank you
<hatch> yay Saskatchewan http://www.techvibes.com/blog/first-province-to-allow-equity-based-crowdfunding-2013-12-09
<frankban> gary_poster: I think this needs to be changed, we need a more explicit way for views to set a return value for when the user quits with ^X, I'll think about that
<gary_poster> cool thanks frankban 
<hatch> oh right I have to deploy the new gui the hard way in the charm
<hatch> boooo
<hatch> hmm I'm having no luck setting this up on lxc using the `NO_BZR=1 BRANCH_IS_GOOD=1 make distfile` technique 
<hatch> after installing make and node/npm imagemagik won't run
<hatch> does that not work on lxc? ec2 only?
<gary_poster> NO_BZR=1 should no longer be necessary.  Note that you do this *on your dev box*
<gary_poster> is that what you are doing?
<gary_poster> 'Cause I don't quite understand your lxc/ec2 questions yet
<rick_h__> hatch: let me know if you want to hangout and walk through it
<rick_h__> hatch: I don't recall if we get a loading xv file right now since we don't yet have a tag. So might need to rename that file to be picked up during the make deploy in the charm
<hatch> I'm doing it in the lxc juju-gui instance
<rick_h__> hatch: and you can or cannot generate a xv file?
<hatch> rick_h__ hangout?
<rick_h__> hatch: rgr
<hatch> https://plus.google.com/hangouts/_/7acpj4qna7ell1e9ovto0fmj8g?hl=en
<hatch> new git alias `cf = "grep -n --color"` :)
<rick_h__> alias grep = "grep -n --color" :P
<rick_h__> pretty sure you can alias over itself
<hatch> negative
<hatch> tried that already heh
<rick_h__> Makyo: comments inbound. I got picky on the UX, let me know if it's more than you were looking for or anything is confusing/etc
<Makyo> rick_h__, cheers, that's fine.
<hatch> https://bugs.launchpad.net/juju-gui/+bug/1262315
<_mup_> Bug #1262315: inspector charm details breakout maxes at the max height of the inspector <juju-gui:New> <https://launchpad.net/bugs/1262315>
<gary_poster> argh.  worked through lunch again. :-(
<hatch> oh crap so did I
<hatch> haha
<gary_poster> heh
<bac> benji: we seem to have rallied.  charm queue down to ~10K from 24K two hours ago
<benji> heh
<bac> bundles still growing
<bac> benji: did you get a chance to look at the logging config?
<benji> bac: nope, I lunched too and then went back to the missing bundle issue
<benji> do you want to pair on this?
<bac> benji: yes
<bac> benji: give me 5 minutes?
<benji> Sure.  I bet today's hangout is still up.
<bac> benji: yep and i'm in there
<benji> on my way
<hatch> gary_poster test-prod is 20s so not much faster than your desktop :)
<gary_poster> hatch, that's awesome :-)
<hatch> that is only single core though, I have 4(8)....clearly there is room for improvement :P
<gary_poster> :-)
<hatch> rick_h__ hey so my develop fork is totally borked, the pr of my recent branch shows like 30 commits when there was only one...can I delete my current fork, create a new one then cherry pick the commit to apply to the new branch?
<gary_poster> yeah rick_h__ my local repo is hosed.  was going to ask you to help me work through it, but been busy with other things, and still want lunch :-P
 * gary_poster lunches
<rick_h__> hatch: rgr
<hatch> yeah? ok cool
<rick_h__> gary_poster: :( ok, let me know when you get back from lunch and will try to keep an eye out
<hatch> I'm going to grab some lunch now too then I'll give it a go
<rick_h__> hatch: yea, that's basically what I did last night
<rick_h__> created a new branch, cherry picked. You might have to pull down the bad branch into your local workspace so it knows the sha reference to cherry pick
<rick_h__> hatch: see my email from last night on it 
<hatch> cool will do
<hatch> so new rule "no rebasing develop"
<hatch> lol
<rick_h__> heh, yea
<rick_h__> though I do want to try to take the time to walk the process and make sure exactly what step led astray
<rick_h__> hatch: do me a favor though, look at the git log and see if it lines up with the github display
<rick_h__> the thing that got me last night was that git log seemed fine, but github seemed confused and I wonder if it's doing something 'magic' in pull requests that I missed/need to take into account
<hatch> rick_h__ these commits don't line up at all
<hatch> they are all from days ago 
<bac> benji: argh, we lost ground on staging b/c ingest run by hand finished!
<benji> heh
<bac> benji: at the end of the unified run, anything left in the queue can be declared to be stuck and purged.
<benji> bac: yep (and logged as an ERROR)
<bac> yeah, that too
<bac> benji: do you know what basket is stuck?
<benji> bac: I have it around here somewhere, but I have to leave now for my appointment
<bac> benji: i don't care as long as you do know.
<gary_poster> hey rick_h__ should I just delete my local repo and github repo and start again?
<rick_h__> gary_poster: that'll work. The other thing you can try to do is to delete just the develop branch
<rick_h__> git push origin :develop (make sure origin is YOUR fork)
<rick_h__> gary_poster: and then 
<gary_poster> rick_h__, locally, in github, or both
<rick_h__> git pull juju develop
<rick_h__> git push origin develop
<rick_h__> gary_poster: all commands from your local clone of your fork on github
<gary_poster> ack
<gary_poster> rick_h__, so the first thing I do is git brancgh -d develop, right?
<rick_h__> gary_poster: yes
<gary_poster> k trying
<gary_poster> argh
<rick_h__> gary_poster: hangout?
<gary_poster> sure
 * hatch would like to join as well
<rick_h__> hatch: https://plus.google.com/hangouts/_/7acpjddus2dgtntjhhvbmu6qvs?hl=en
<hatch> gary_poster hey re the charm details bug that you just closed - Do you think that maybe we should get their input on that? If you saw the photo you can see that it's hardly ideal :)
<hatch> jujugui I need two reviews/qa's on https://github.com/juju/juju-gui/pull/36 it removes all of the old inspector templates and code which was left
<gary_poster>  hatch, we already have gotten their input.  you know I go to them when we have an issue.  This is exactly what they told us to do.  We did something different at first and they had us change it.  If  you want to bring it up with Luca yourself, it's ok, but be aware of history, and for me it's closed.
<gary_poster> I mean, 
<gary_poster> for me, I think this issue is won't fix, as I marked the bug.
<hatch> alrighty no problem
<gary_poster> hatch I'll do a review
<gary_poster> 646 lines, woohoo
<hatch> haha yup and none of it is rick_h__ 's code lol
<hatch> see rick_h__  i'm an equal opportunity code remover ;)
<gary_poster> hatch trvial but I think you can remove line 1398 ("'juju-view-service',") from /home/gary/dev/juju-gui/app/views/inspector.js
<hatch> yes you're right, nice catch
<hatch> thanks
<gary_poster> welcome
<gary_poster> hatch, fwiw, it is all code deletion.  I think one review is OK if no one else has stepped up
<hatch> ok cool as long as it qa's ok, it all worked well here 
<gary_poster> yup
<gary_poster> shipit
<gary_poster> not the most useful graph: https://github.com/juju/juju-gui/graphs/code-frequency
<gary_poster> noise at the beginning
<hatch> haha
<hatch> gary_poster rick_h__ mind proofing before I send plz https://gist.github.com/hatched/1d624a34c13553882ee4
<gary_poster> reading
<gary_poster> I used push --force.  More explicit.  <shrug>
<hatch> changed
<gary_poster> actually hatch you can delete lines 24 and 25, and make line 31 have the --force.  That's what I did.  Fewer steos, and no downside that I see
<hatch> agreed
<rick_h__> hatch: step 1: git co master (or some branch other than develop)
<rick_h__> hatch: so you can do the deletion
<hatch> updated https://gist.github.com/hatched/1d624a34c13553882ee4
<rick_h__> hatch: https://gist.github.com/mitechie/0285d9d0b407ba3ab97f
<hatch> I think we both made the same change at the same time lol
<rick_h__> hatch: k, I also deduped a step since you only need to push once
<rick_h__> simpler > *
<hatch> yup I also removed that in the most recent version
<hatch> cool I'll send this version
<hatch> snet
<hatch> sent even
<rick_h__> cnblndriunvtnkivldurjldundhftejkr
<hatch> i agree
<hatch> lol
<gary_poster> hi yubico!  we missed you too
<gary_poster> and with that, I am off!  
<gary_poster> bye
<Makyo> rick_h__, if you're around, did things look good with your proposed changes?  Missed a portion of the afternoon and may be submitting late.
<Makyo> Figured I'd ask if you're still around :)
<hatch> Makyo hey so what time is it there now?
<hatch> 3?
<Makyo> 4.
<hatch> ohh ok
<hatch> I can't keep other timezones straight :)
<Makyo> Neither can I :)
<hatch> haha
<Makyo> Trying to taper meds, just lost track of a few hours.  Will get it in the next little bit, just may be late.
#juju-gui 2013-12-19
<hatch> jujugui lf a quick doc review https://github.com/juju/juju-gui/pull/37
<Makyo> On it.
<hatch> thanks
<hatch> looks like I need to make some changes to get the docs to compile so I'll make any other changes you find too
<Makyo> hatch, +1 otherwise.
<hatch> Makyo curious - it's under the Bit rotted instructions along with a lot of other stuff
<hatch> should I just leave it?
<rick_h__> Makyo: I'm out. I can qa again in the morning. I didn't see a reply back sorry
<Makyo> rick_h__, np, be well
<rick_h__> Makyo: have a good night. The stuff in there ok?
<Makyo> rick_h__, Yep, just making sure it was basically LGTM otherwise, could submit tonight with those changes, on for another few hours.
<rick_h__> Makyo: yea, sorry. I wasn't sure if there was back story to any of it and such. Like the escape things, the shortcuts used
<rick_h__> I'll LGTM with comments
<Makyo> Cool, thanks :)
<rick_h__> done
<Makyo> hatch, If the fix is quick, go ahead, otherwise, remove.
<rick_h__> hatch: if those aren't system installed don't you have to find the path in the node_modules to run them?
<rick_h__> e.g. lint and such?
<rick_h__> hatch: I'm nervous about that change off the top of my head without matching updates to some bin scripts
<hatch> rick_h__ when you install something with npm -g it's available to any node script
<rick_h__> hmmm, you still -g, but it has to be sudo do write to the lib dir
<hatch> not if you change the permissions
<rick_h__> it installs in /usr/lib doesn't it? only root can write there
<rick_h__> ugh, bad form to charm perms on /usr/lib man
<hatch> usr/local/lib
<hatch> and no, giving sudo to any node script on npm is bad form :P
<rick_h__> hmmm, http://paste.ubuntu.com/6597268/
<rick_h__> I'm not a fan of this move
<hatch> interesting...
<hatch> rick_h__ you must be running an older install https://npmjs.org/doc/files/npm-folders.html
<hatch> usr/local is the prefix now
<hatch> hmm the python tests are failing
<rick_h__> hatch: yea, this machine is still 13.04 I think. 
<rick_h__> hatch: but still, installing something globally in ubuntu is always a sudo thing
<hatch> I mean version of npm/node when it was installed originally 
<rick_h__> I'm not a fan of changing that by messing with permissions in system level directories (outside of ~)
<hatch> agree to disagree? ;P
<rick_h__> heh, not without a card to talk about it on standup so I can get reinforcements :)
<hatch> tbh I don't see where the disadvantage is here
<rick_h__> and the test that failed was saucelabs
<hatch> if anything, restricting it's permissions is better
<rick_h__> it's monkeying with standard linux practices
<rick_h__> the old issue you had to chown one directory in your home 
<rick_h__> this is playing outside of home, it's breaking multi-usre systems
<rick_h__> user
<rick_h__> if user rharding owns the global node modules, how can user mitechie install/use them
<rick_h__> it's kind of fundamental to how this stuff works 
<hatch> if root owns them neither user can without sudo
<rick_h__> right, but you can grant sudo to muliple users
<rick_h__> and if sudo does something, everyone gets access and shares
<hatch> you can also create a node-dev user group and assign it to them :)
<rick_h__> this is setting things to one user, and the wrong one. It's a big breach of linuxy
<rick_h__> fine, then update the instructions to use sudo to create a node-dev group, assign permissions to that folder to that group, and add your user account to that group :)
<rick_h__> bath time, bbl, but veto without discussion on the change please
<hatch> lol I think at that point the user knows what to do
<hatch> ok I'll leave the PR open
<rick_h__> and the user knew what to do the old way :)
<rick_h__> plus tests still don't pass :P
<hatch> hey thats your fault those are the sauce labs tests :P
<hatch> ok I could do something like "Don't want random js scripts from running with sudo? Then you can do this...." :P
<rick_h__> bah, it is a timeout isn't it. Crap
<rick_h__> I had hoped my branch today would stop that. Oh well, going to production tomorrow should help
<hatch> :) till tomorrow
<hatch> cya
<rick_h__> jujugui updating FF testing from 16 v16 to 26. Any objections?
<rick_h__> actually 25, they don't have 26
 * benji reboots to finish installing updates.
<gary_poster> frankban, rick_h__ sorry, family issues made me start late.  joining, frankban; may be late rick_h__ 
<frankban> gary_poster: np
<rick_h__> gary_poster: rgr
<bac> hey y'all it's quiz time.  who can guess why 'q' as a variable name is bad?
<benji> bac: because when you're in pdb you'll type "q" expecting to see its contents but instead you "q"uit the debugger
<benji> (not to mention that single-char variable names are almost always a bad idea)
<bac> benji: yes, you win a valuable prize!
<bac> benji: i've only done it three times this morning.  (not a quick learner.)
<benji> heh
<benji> I've tried to train mayself to use "p q" and "! q = foo" all the time in pdb so as not to have that problem.  I've not succeeded.
<bac> conflicts with other pdb commands are annoying but not quite as much as q.
<benji> I love the gmail mute-a-thread function.  It's great when someone leaves the company or has a baby.
<hatch> lol
<hatch> rick_h__ did you see http://stridercd.com/ looks like a node version of jenkins
<rick_h__> hatch: yea, and I talked with the dev about our landing issue
<rick_h__> hatch: and he was interested in getting a plugin to do it
<hatch> landing issue?
<rick_h__> hatch: but it's not charmed, running nodejs (non-approved tech technically), and was a bigger learning curve
<rick_h__> hatch: the jenkins-github-lander stuff. Automated github merge based on test run
<hatch> ohh right right
<rick_h__> so yea, I did look into it and talked with the dev. It's interesting, would have loved to had more time to follow that route as I'm not really a jenkins fan, but this was closer to working then strider for our needs
<hatch> you probably didnt choose it because it was node.js lol
<rick_h__> :P
<rick_h__> Honestly, the fact that it would make it harder to get into general use and for juju-core played a factor
<rick_h__> but personally, I went through the code and found it cool. 
<hatch> I wish we could have icons for unapproved charms
<hatch> totally unrelated heh
<hatch> but with these new must-have-tests rules my ghost charm will never get approced
<hatch> approved*
<hatch> jujugui I made some changes to the hacking doc which involve changing permissions on a /usr/local/lib dir instead of using npm with sudo, can you check it out and give your opinion plz https://github.com/juju/juju-gui/pull/37
<bac> hatch: why is using sudo to modify directory ownership better than using sudo to install globally?
<hatch> bac because when running npm under sudo your js script has root privileges - whereas the other way around it can only execute stuff your user can
<bac> hatch: excellent
<Makyo> We
<Makyo> We're not running our script under sudo ?.?
<Makyo> We shouldn't be, at least.
<hatch> Makyo `sudo npm -g install jshint` executes the install script under sudo
<hatch> so it can do what it wants
<rick_h__> right, and we've selected jshint to be able to do things...like install a system (all user) available bin/jshint
<Makyo> Isn't that part of the contract of using npm?  Same with apt-get, same with juju on a local provider...
<rick_h__> it's the way it works. Just as you sudo apt-get install xxxxx does the same
<rick_h__> or sudo pip install pyscss
<rick_h__> it's the expected process. We're not doing "sudo npm install -g $user-supplied-thing" 
<Makyo> If the node community doesn't have a framework for dealing with malicious packages in their management system, perhaps we should move away from node.
<hatch> ok how about this.... I'll change it back to read with sudo then add "If you are not comfortable with giving npm install scripts root you can change the permissions of these directories..."
<hatch> Makyo it doesn't anyone can upload anything to npm
<Makyo> Then perhaps we should move away from Node.
<hatch> you can even override old versions on npm with new code 
<rick_h__> then add it to to anything installing python or system packages as well hatch 
<rick_h__> any time you install any software you're doing this
<hatch> well I was under the assumption that the apt packages were reviewed 
<Makyo> I was under the impression that npm packages were reviewed :)
<hatch> haha, nope they are not
<Makyo> :T
<hatch> I'm assuming the same with apt then? :)
<Makyo> Apt's reviewed.  In order to make it in a release, a package has to be submitted and approved, thus juju-core requiring a PPA for a while.
<rick_h__> well, main is. universe isnot so much. pypi is not reviewed
<rick_h__> go get is definitely not reviewed
<hatch> I've never run go get with sudo before
<Makyo> Hah
<hatch> pypi requires sudo?
<Makyo> Outside of a virtualenv.
<rick_h__> to install globally, which is why we use virtualenvs
<rick_h__> what I would LOVE to see is using npm sans -g and building our scripts to use the node_modules dir
<rick_h__> that's the *right* fix imo
<rick_h__> this is just breaking linux for the sake of not doing ^
<Makyo> +1
<hatch> I'm assuming we don't because it's a heavy install?
<rick_h__> huh? no, we don't because -g means it's automatically on our system path
<rick_h__> and otherwise you have to find the bin/xxxx in the node_modules path
<rick_h__> at least that's my guess, I didn't write it out this way
<bac> gary_poster: call in a few?
<gary_poster> bac yes, almost
<bac> gary_poster: ok, ping me here when ready.  i'm there but not paying attention to it.
<gary_poster> ack
<gary_poster> bac, halloo
<rick_h__> benji: got a sec?
<benji> rick_h__: sure
<rick_h__> benji: I'm trying to see where the url the sauce labs tests hit gets set
<rick_h__> benji: it looks like in browser.py it looks for $APP_URL
<rick_h__> but I don't see it set anywhere
<benji> rick_h__: IIRC, the Jenkins config sets it when running "make ci-check"
<rick_h__> bah, that's right. gotcha
<Makyo> jujugui call in 10, kanban now.
<gary_poster> jujugui call in 1
<gary_poster> frankban, ping
<bac> Makyo: i'm interested to hear about your truck stop food.
<Makyo> bac, I convinced them to switch to Greek food, thankfully :D
<bac> a greek truck stop would be interesting
<gary_poster> rick_h__, chrome and ff tests working, yay :-)
<hatch> rick_h__ apparently Netfilix is going to start streaming 4k sometime soon....good for your new monitor ;)
<hatch> assuming of course you don't have one of those life sucking isps which limit your bandwidth
<rick_h__> hatch: :P
<rick_h__> hatch: heh, are there any other kinds
<rick_h__> and I don't watch tv on my monitors. I've actually got kind of low ens 720p tvs in the house
<rick_h__> maybe one day I'll upgrade to a 'real' tv
<hatch> hah, well it could be worse, we could life in the Orwellian future which is the UK's current internet
<rick_h__> speaking of...curse you dell! still in 'production'
<hatch> it'll probably be a while, it's very likely made in China, so it'll take a while to boat over here
<hatch> ohhh d3
<hatch> Makyo we should probably update d3 we are a few versions back
<Makyo> hatch, agreed.
<Makyo> Will look into it; should be just a drop-in-place.
<hatch> yeah we will need to make a new shrinkwrap so at the same time it probably wouldn't hurt to revisit the other deps
<hatch> yui and the like
<hatch> we HAVE to update YUI to 3.14.1 to support IE11 anyways
<hatch> heh
<rick_h__> hatch: heh, that answers a question about adding IE11 tests I guess then :)
<hatch> rick_h__ hah yup
<hatch> I mean to have us support it is pretty trivial upgrade
 * hatch crosses fingers
<hatch> heh
<hatch> anyone here use znc?
<rick_h__> hatch: I think jcsackett used to
<hatch> I can't figure out how to connect to it heh
<hatch> it 'should' work from what I can tell but I keep getting rejected
<rick_h__> jujugui anyone care to chat and help me think through a decent way of bending the make/build system to my will of running make prod but with the debug config.js?
<gary_poster> rick_h__, I can and would be happy to in a few--maybe 17 min.  
<rick_h__> gary_poster: rgr, appreciate it
<gary_poster> np
<gary_poster> if anyone else wants to do it that's cool too :-)
<rick_h__> definitely, someone must have a tricky non fugly way to to this hidden in their head. All mine suck
<hatch> rick_h__ make-prod --config debug then in the linked files have a switch :)
<hatch> of course that would be a lot easier if we didn't use make
<hatch> heh
 * rick_h__ is going to come over there and cut your new powercord
<hatch> hey it's a good idea!
<gary_poster> hey rick_h__ do you have a hangout or hall I make one?
<gary_poster> shall
<rick_h__> gary_poster: can make one up, sec
<gary_poster> cool
<rick_h__> https://plus.google.com/hangouts/_/7acpjrujr1s6qjbhlf3kvuegro?hl=en
<hatch> anyone know iptables well? I think my znc issue is that it's not allowing the data through the port https://gist.github.com/hatched/4c2effe2e92e9487bf13 can you see anything wrong with this output?
<frankban_> guihelp: I need two reviews + QA for https://codereview.appspot.com/44310043 (quickstart remove env). Anyone? no rush, thank you and have a nice evening!
<bac> frankban_: i'll do one later
<gary_poster> frankban I will take one later
<frankban_> bac, gary_poster thanks
<hatch> welp it's definitely a ip tables issue because I can't even get nc to connect
<hatch> but lunch over, back to work
<rick_h__> jujugui CI branch update review please. https://github.com/juju/juju-gui/pull/38
<rick_h__> two successful test runs in a row woot!
<gary_poster> woot :-)
<bac> yay
<hatch> on it
<hatch> wow two in a row? That's gota be a first in MONTHS!!!
<hatch> lol
<rick_h__> hah! 10min run time atm with all three browsers only on build prod
<rick_h__> added a card for adding back in build-debug, but was having timeout issues on that and prod is working nicely. Want to reevaluate once this proves stable-ish
<hatch> rick_h__ looks like IE is last?
<rick_h__> hatch: yes
<hatch> We used to run it first because it was the most likely to fail
<hatch> I'll add a comment but I wanted to hear if you had any input
<rick_h__> well, I figure if it's last then you know the test runs itself was good, just IE hates you
<rick_h__> if the first one blows up, you're not sure if it's CI in general or just IE failing a test
<rick_h__> and the time diff of a coupe of minutes isn't going to make a big diff imo
<gary_poster> rick_h__, +1 on prod only.  we can move debug to aggregated post-commit perhaps, at some point (and maybe prod too if it becaomes too annoying)
<rick_h__> I'll work on some instructions for running locally. I was running IE sauce tests from my local environment IE only so I think that's a "better" way to debug IE failures
<rick_h__> hatch: so I'm -1 on moving it up the list imo
<hatch> lgtmd
<rick_h__> hah, poking at the github graphs. Go hatch go "On develop, 50 files have changed and there have been 343 additions and 1,302 deletions"
<hatch> rick_h__ hah this is a little disturbing https://github.com/juju/juju-gui/graphs/contributors we remove more than 50% of the code we write!
<hatch> bac has almost removed 100% of the loc that he has written lol
<gary_poster> it's a good thing
<rick_h__> hah, well that's some damn fine refactoring
<hatch> lol is it? Aren't we supposed to do it right the first time....measure twice, cut once sort of thing ;)
<rick_h__> though you're getting credit for removing the code I wrote. So wonder how that balances out over time. 
<rick_h__> hatch: nope, we're agile. We build, test, refactor, build, test, refactor
 * bac rock!
<hatch> haha 
<gary_poster> hatch, our last project would not allow you to add code unless you had removed an equivalent amount
<hatch> haha oh really? Interesting 
<bac> gary_poster: did you ever track that?
<bac> gary_poster: it happened as we were fading away
<gary_poster> bac, true
<rick_h__> orange squad had a bzr command we ran so we could justify crap
<rick_h__> sucked because we kept claiming exceptions to get private projects finished
<rick_h__> "I know this adds code, but private projects must go on....move aside"
<bac> anyone using clef, phone-based oauth tool?
<rick_h__> nope, just lastpass mobile for that stuff
<gary_poster> yeah lp me 2
<rick_h__> well, I guess that's a 2fa ish lastpass merged thingy
<bac> yeah, but clef automates the communication between site and phone by talking via squiggly lines
<rick_h__> I don't get how it's 2fa though if it only requires your phone?
<rick_h__> what's the second factor?
<hatch> your FIST!
<bac> it's not 2fa afaict
<rick_h__> Secure, easy, passwordless 2-factor authentication in less than 10 minutes.
<rick_h__> from the website :/
<bac> oh
<bac> seems like they are just an oauth service and they use your phone as identity rather than a password
<bac> rick_h__: i guess they consider the 4 digit passcode to get into the app as 1 factor
<rick_h__> bac: ah, gotcha
<hatch> it's interesting
<hatch> I could see lastpass and that type of system working really well
<hatch> although pattern is far more secure than 4 digit pin heh
<bac> rick_h__: i'm proposing the charmworld qa branch.  would you have time to review it, being the godfather of all that stuff + migrations?
<rick_h__> bac: sure thing, ok for it to be first thing in the morning?
<bac> rick_h__: yeah, i guess.  charmworld isn't landing before monday
<bac> if then
<rick_h__> I just got CI landed with IE support and want to drop the mic and EOD feeling all badass atm. :) and I have to run an errand to get presents in the mail atm
<bac> np
<rick_h__> bac: thanks, I'll hit it up either later tonight or first thing in the morning. 
<rick_h__> jujugui all three browser saucelabs has landed. and if we want to add safari it's one step away as well. landing/test times are around 10min now 
<hatch> love it
 * rick_h__ runs away before something breaks
<gary_poster> thank you rick_h__ !  Very cool
<benji> very nice
<bac> cool
<hatch> I'm actually surprised we didn't have CI for so long and everything we have still passes
<hatch> how awesome are we???
<benji> level of awesome: lucky
<hatch> PFFT
<hazmat> very cool
<bac> benji i sometimes wish your irc comments came with a 'like' button.
<benji> That's how I'll make my millions: IRC + Like Button
<rick_h__> hatch: remember, we're running what, 6 tests?
<rick_h__> :P
<bac> i'd buy one.[*]
<bac> [*] requisite daily Raising Arizona reference
<bac> rick_h__: at your leisure https://codereview.appspot.com/44070045
<hatch> rick_h__ ohh you aren't running the unit tests in each browser?
<hatch> I can't seem to write d3 code that looks good
<hatch> no matter what chaining just looks horrible :/
<hatch> Makyo are you around?
<hatch> Makyo when you get back from lunch I have a question about d3 not noticing a data change
<Makyo> What's up?
<hatch> Makyo doh nm I screwed up, I forgot I was still in the d3 'enter' phase
<hatch> sorry to botha
<Makyo> Glad I could help :D
<hatch> haha rubber duck debugging :D
<hatch> I'm switching the relations tab to use d3....wow there is a LOT more loc than just using a template haha
#juju-gui 2013-12-20
 * benji does the I-finally-fixed-the-missing-bundle-from-search-bug dance.  It's not pretty.
<gary_poster> awesome benji.  what was story
<benji> gary_poster: I don't know how it happened, but the checkout of the bundle branch was updated to revno 2 (there are three revisions total) and the charmworld code looks at the number of revisions in the checkout vs the branch to decide if it needs to update the local checkout, since the local checkout has 3 (but is at 2) and the remote branch has 3 it decided there was nothing to do
<gary_poster> benji, oh, weird
<benji> it just so happened that revno 2 wouldn't pass proof so nothing would get loaded into the db or ES, but at some point in the past revno 3 had been loaded into the db (and perhaps ES as well, but had been perged from there)
<gary_poster> interesting
<benji> I will make a charmworld branch that will keep this from happening again.
<gary_poster> is there some way to prevent that in the future?  I'm guessing we were using bzr revno or equivalent already, and that was what was broken, somehow?
<gary_poster> sounds like answer to my first question is "yes" then :-)
<benji> :)
<rick_h__> benji: woot!
<benji> :)
<rick_h__> benji: hmm, wonder if when we wiped ES during the great crash that it caused that to happen
<rick_h__> only recent time of a greast ES purge lately
<rick_h__> well, until all this
<benji> we should just put an ES purge in cron, it would simplify things
<rick_h__> heh, es-update turns into a "we can nuke it...and rebuild it"
<gary_poster> hazmat, hi.  are we doing the UX catchup, with luca unavailable today?  won't be much of a UX catchup without him
<gary_poster> https://floobits.com/ : looks potentially awesome for pairing (real-time collaboration across emacs, vim, sublime text, and browser-based editor) once it's working on SublimeText/Linux (https://github.com/Floobits/floobits-sublime/issues/96)
<gary_poster> note that one person can be using vim and other person can be using sublime text simultaneously, for instance
<hazmat> gary_poster, i was planning on it.. ale requested.. will leave up to her
<gary_poster> hazmat, oh ok.  thx.  May ask Jeff and/or Matt to attend if it seems like meeting is going in a direction where it would be useful for them
<BradCrittenden> rick_h__: thanks for the review
<bac> benji: i just discovered ingest waits a full 15 minutes between finishing and starting again if --run-forever is used.  dopey.
<benji> pfft
<benji> that might put a damper on throughput
<rick_h__> bac: sorry, qa is taking a second, proof is blowing up. A bundle by jamespage isn't getting loaded and proof seems to have syntax/json issues right now
<bac> rick_h__: np
<rick_h__> benji: gary_poster heads up that proof goes boom currently ^
<benji> rick_h__: k
<gary_poster> :-( ack
<benji> rick_h__: do we fail open or closed?
<bac> benji: yeah, so the queue cronjob gets to run every 15 minutes but ingest runs much slower since time to run isn't considered
<rick_h__> benji: not computing atm. Right now proof has a syntax error and the current proof call from the cli is getting a 500 back from mjc. I'm trying tomanually form the proof call to see if someting in the bundle causes us to 500 or if proof itself is building a bad request
<benji> rick_h__: my intent was learn whether we reject all when proof fails or let all through when it fails.  I hope we reject everything.
<rick_h__> benji: we should be doing whatever we do with charms I believe. I'm not 100% sure. We don't get it in the store but can't speak if it's that half 'I know it's there but don't show it' business 
 * rick_h__ had to go look up fail open/close
<benji> :)
<hatch> so hows everyones morning?
<bac> hatch: i just dropped my yogurt, but until then everything was fine.
<hatch> oo ouch
<gary_poster> probably more like squish than ouch
<bac> splat and splurt.  landed on its side, open, and disgorged half the contents.  luckily i didn't step in it.
<hatch> I wonder how one decides between a splat and a splurt
<gary_poster> pure sound, I'd guess
<hatch> anyone know how to debug this http://askubuntu.com/questions/393371/juju-gui-problem-with-login ?
<hatch> in other news, clojure is a nice looking language https://github.com/swannodette/todomvc/blob/om/labs/architecture-examples/om/src/todomvc/app.cljs
<hatch> purely visual, I have no idea what it's doing :D
<rick_h__> lol
<hatch> I'm really not sure how all of these clojure > js compilers enforce immutability "with no cloning" 
<rick_h__> hatch: you have to get into clojure data types
<benji> I like lisps, and Om sounds like it is well thought out.
<rick_h__> because you're in that language you're using it's methods of things which is performing the operations for you in JS
<hatch> rick_h__ well i'm thinking purely from the javascript side
<hatch> you either clone the object, or remake it....not much getting around that
<rick_h__> right, but you never touch/look at the JS
<hatch> oh so these statements are purely from the libraries point of view
<hatch> not the underlying functionality
<rick_h__> how I read it but maybe I'm mistaken. I've only looked at closure and not the script side
<rick_h__> I can't get past all the () in the lisp stuff 
<hatch> jeesh it's a darn good thing you're in the python world lol
<rick_h__> I chose python (or it chose me) 
<hatch> I'm actually pretty interested in lispy stuff, I'll probably be pending some time over the break giving it a go
<rick_h__> I did php, javascript, asp for more than a couple of years before I busted my $#@$#@ to get a job in python
<hatch> closure seems like the best candidate
<rick_h__> yea, clojure (closure is the google JS framwork)
<benji> hatch: the concept the datastructures use is called "persistence" but it's not the "store in a database" kind of persistence.  Referring you to this will save me some typing: http://en.wikipedia.org/wiki/Persistent_data_structure
<hatch> benji right, but in js you must clone the object to do that
<hatch> so these docs must be referencing the higher level api's in the libraries
<benji> hatch: I don't know how ClojureScript is implemented, but you may be right, that or they don't use the JS datastructures at all and can therefore assure true imutability
<hatch> yeah clojure :) sorry, I was spelling things properly for once lol
<rick_h__> jujugui added a pair of proof bugs for ingesting bundles to the board. One should be small, one medium. Got around mostly to get james's bundle to load work in jujucharms.com, but can't currently be ingested. 
<gary_poster> ack thanks.  I saw.  that's been waiting for us.
<rick_h__> yea, he built a serious bundle there
<rick_h__> openstack-on-openstack 
<gary_poster> heh, wow
<rick_h__> I think we found our new test bundle :)
<gary_poster> awesome :-)
<rick_h__> "if that works then $#@$#@ everything better work"
<gary_poster> lol
<hatch> haha
<bac> rick_h__: does this mean my qa is doa?
<rick_h__> bac: no, it means I'm just now getting to it
<rick_h__> the fire is in control on the james side. 
<rick_h__> bac: sorry for the delay
 * rick_h__ needs to learn to let irc be more :)
<bac> rick_h__: thx
<hatch> rick_h__ "Should proof as valid"
<hatch> ;)
<bac> 'tis the season...
<rick_h__> hatch: sssh it's friday
<bac> to shout in a bullhorn
<hatch> haha
<bac> this week we've had noisy protests from dairy farmers and teachers and now the bus drivers are on strike
<rick_h__> bac: I changed grocery stores for the last bit because I got sick of the bell outside of the closest one
<rick_h__> ugh
<hatch> oh d3
<hatch> I MIGHT have found a clean way to write d3 code
<hatch> the linter probably won't like it
<hatch>     relationWrapper.append('h4')
<hatch>                    .text(function(d) { return 'Interface: ' + d.interface; });
<hatch> well that didn't work
<Makyo> Yeah, the linter kinda hates chaining/.
<hatch> and I'm with it
<hatch> haha
<rick_h__> bac: are there qa instructions? From where my db is I can't upgrade I get an error that : Exodus index "charms_pending_019" does not exist.
<rick_h__> bac: and in looking around the migrate stuff has changed a bunch and not sure if I should be able to upgrade from current state or have to do a reset?
<hatch> annnnnnd relations tab has been converted to d3
<hatch> now to cssify it
<rick_h__> bac: and the makefile has no migrate commands any more :/
<bac> rick_h__: i thought there used to be makefile support for migrate stuff.  boo.
<bac> rick_h__: you want to chat?
<rick_h__> bac: sure
<rick_h__> bac: https://plus.google.com/hangouts/_/7ecpiqltgarlsn4gsp09jd6i2c?hl=en
<hatch> holy itunes is such a garbage app
<hatch> jujugui call in 10
<gary_poster> ty
<gary_poster> jujugui call in 2
<gary_poster> benji Makyo ping
<hatch> rick_h__ I have a blog post I wrote a while ago on TDD that people have said has been really helpful
<hatch> I think it helps answer some of your issues
<rick_h__> hatch: linky, I'm happy to look. My point was less in theory though and what I tend to run into in practice
<rick_h__> in theory pure TDD seems great, but in practice you end up really needing a first prototype like gary_poster mentioned to get an idea of what it should look like first
<rick_h__> and then go back at it, but by then you've put some pre-thought more into things than without a prototype. If you sit down to add feature X to the browser and just start TDD'ing I find that really often the code api is horrible 
<gary_poster> I think TDD embraces that, or at least some/many practitioners do
<rick_h__> and maybe I've just had really bad experience with it :)
<rick_h__> yea, the post-refactor should help some, so I don't really have issues with the full pure TDD in theory. 
<gary_poster> That is, you can do TDD without prototyping, but you can still call it TDD with it
<rick_h__> ah, yea 
<hatch> http://fromanegg.com/post/54890090207/test-driven-development-the-easy-way
<rick_h__> hatch: yea, this kind of fits in with what I'm saying. I really find I like to sit down and work out 'what is the code I want to write to make feature XX happen'
<rick_h__> and then write that with TDD, but establish most of an 'api' first
<hatch> well the TDD is supposed to help you design the api
<hatch> if you need these X things to happen you need at least X functions
<hatch> because a function should only have a single role
<hatch> (in a perfect world)
<hatch> it also then helps you prototype because you can use the test to send a datastructure to that function
<hatch> so you can iterate very fast
<hatch> TDD is hard to do because we just want to get in there and DO something :D
<hatch> I suppose that's BDD? heh
<hatch> gary_poster would you say that clojure is a good language to learn to get a better understanding of these persistent data structure ideas? 
<benji> rick_h__: If you want a different perspective, I really like documentation-driven development (especially for libraries, but I consider almost everything a library even if it only has one user)
<benji> this guy's writing states it pretty well: http://tom.preston-werner.com/2010/08/23/readme-driven-development.html
<hatch> TDD, BDD, DDD
<hatch> how many DD's are there? heh
<benji> but I think it should be taken one step further: your documentation should be tested so that it isn't lying about the code (https://pypi.python.org/pypi/manuel/)
<hatch> just write Go with godoc then ;)
<benji> even better than DDD, I like ZDD (zealot-driven development)
<rick_h__> woot! how can I sign up for that
<benji> hatch: godoc doesn't let you have a real naritive structure, think more like literate programming, but literate tests
<hatch> :)
<hatch> Makyo got a second to look at some d3 code? https://gist.github.com/hatched/5466e333d47b7b459486 
<benji> rick_h__: I'm not kidding, if a group of people really like something (a language, a library, a methodology) it is a good way for the group to be very productive
<rick_h__> I think I'm feeling like I'm missing something though because many of the quickstart reviews I've had a hard time with. 
<rick_h__> though it seems a LOT of design/discussion has gone into them ahead of time 
<Makyo> hatch, sure.
 * benji stops talking about this before he suggests regex-driven-development.
<rick_h__> so I'll get back to going through the functional JS book and see if I can open my brain up a bit more, but man sometimes I can't help but think what a different version would be written like
<hatch> the unitlist exit isn't working....just wondering if there is something obvious I'm missing
<hatch> line 71
<Makyo> hatch, try storing the enter in a different variable.  line57: var units = unitList.enter(); units.append [...]
<hatch> the unit property is entirely going away as well, think that could be it
<hatch> so line 52 would return undefined
<hatch> I can try the new var though
<Makyo> Oh, hm.
 * Makyo goes through expenses, sheepishly submits three items :(
<hatch> yeah that didnt help so it must be that units is undefined when there are no unit errors
<hatch> so I'll leave that as an empty array
<Makyo> Oh, okay.
<Makyo> Yeah, that makes sense.
<hatch> hmm ln 111 is throwing a d3 .length error...I might need to use filter there
<Makyo> There is no line 111.  Options are filter or empty array, seems like.
<Makyo> why not return d.units || [] or something?
<hatch> the data structure not has units as an empty array 
<hatch> but line 51 is throwing the error sorry
<hatch> my guess is that the selectAll is returning undefined
<hatch> so it can't call length on it
<Makyo> Can break and run it in isolation?
<Makyo> selectAll should return an empty array.
<hatch> cool got it working
<hatch> man you're a good rubber duck
<hatch> :P
<hatch> Makyo is there a way to debug things like these select and selectAll calls? 
<hatch> besides console logging their output?
<hatch> I'm hoping for some kind of debugger; injection :)
<Makyo> Debugger line 48, relationWrappers is now in scope in the console. Don't know what else you need.
<hatch> well say I wanted to keep the chaining going but inspect the data as it progresses through each step
<hatch> I could assign each to a variable of course but that's kind of a lot of work :)
<Makyo> You were given an up-arrow and console history for a reason :)
<Makyo> do the .select(), then uparrow and add the .selectAll()
<hatch> ohhhhh kayyy
<Makyo> Given that the debugger works differently depending on browsers, actual injection would be kind of huge.
<hatch> yeah
<hatch> a guy can dream I suppose :)
<hatch> make lint......kaboom!
<frankban> Makyo: EOD for me, time to go. I know you are already busy mon and tue, so, the following is just for reference: my current branch is in lp:~frankban/juju-quickstart/env-manage-edit . it's almost done (some tests missing). If you want to take a look, good, if not good again, and I'll finish the work on Jan.
<Makyo> frankban, Cool, I'll pick it up next week pending this branch.
<gary_poster> frankban, happy holidays!
<Makyo> James' brake calipers froze, going to get him to the shop in a few over lunch, will be afk during.
<frankban> cool, thank you gary_poster, you too! happy holidays everyone!
<gary_poster> ack
<gary_poster> :-)
<hatch> anyone available for a quick pre-test-writing review?
<gary_poster> happy holidays to everyone in jujugui.  I'll see a couple of you Monday.  I'm going to go lie down
<hatch> frankban merry christmas!
<Makyo> Cheers.  Happy merry.
<hatch> lol
<frankban> :-)
<hatch> Makyo might have jumped into the sauce a little early
<benji> gary_poster: Merry Christmas and a Happy New Year!
<Makyo> Hah!
<hatch> https://github.com/hatched/juju-gui/compare/juju:develop...hatched:relation-unit-errors?expand=1
<hatch> ^ Makyo wana take a quick peek? 
<Makyo> Sure.
<hatch> thanks
<hatch> The tests aren't in that of course but just want to make sure you agree with the code before I write them 
<Makyo> That seems reasonable, yeah.
<hatch> kewlio
<hatch> now to lunch
 * Makyo runs away to help James.
<bac> benji: thanks for the qa-ing
<benji> np
 * bac walks dog between downpours
#juju-gui 2013-12-21
<Makyo> guihelp small review for subordinate relations: https://github.com/juju/juju-gui/pull/39
<hatch> I can do it
<Makyo> Cool, thanks.
<Makyo> Ran into all sorts of problems with git.
<Makyo> Decided I wasn't going to take any guff from that swine, took a patch, rebuilt dev env, applied :P
<Makyo> Which, for future reference, is git diff develop > ../patch; cd ..; rm -rf env; git clone ...; git checkout -b ...; git apply ../patch
<Makyo> The problem being that a juju-sync that leads to conflicts will leave your history dirty after you resolve them.
<rick_h__> Makyo: yea, that was the email that went around I think. 
<Makyo> Yeah.  Just had it happen in a weird stage of working.
<rick_h__> Makyo: we (I) had made a mistake in helping hatch earlier in the week so several of us walked through it and then hatch sent the email with the notes on how to fix
<hatch> yeah sheesh don't you read your emails ;)
<rick_h__> I more meant it was to be expected :)
<rick_h__> and apologize some more for it 
<Makyo> I don't see it, for what its worth.
<Makyo> It's fine, I got it working.
<Makyo> Just didn' tknow how to patch/apply with git untilnow
<hatch> it's pretty cool using cherry-pick too
<rick_h__> the other thing was to cherry-pick. I walked hatch through that way and it was cool
<Makyo> Yeah, even with cherry-pick I was getting history.
<Makyo> I think because my origin got messed up.
<Makyo> Had to clone off juju/juju-gui.git, then fix origin.
<hatch> ahhh yeah
<hatch> that was the first part
<rick_h__> yea, had to blow away the develop branch, recreate it from the juju version, and then cherry pick the commits across to a fresh feature branch
<Makyo> Yeah.
<Makyo> I already had the patch, so that was fast at least.
<rick_h__> damn dell, I've got a monitor arm, a display port 1.2 cable for a monitor...but no monitor
<hatch> hehe boooooo
<rick_h__> first review is out though
<rick_h__> http://uk.hardware.info/reviews/5100/dell-ultrasharp-up2414q-review-24-inch-uhd--4k-monitor
<rick_h__> it'll be interesting. The mention of it showing up on some hardware as two 1920x2160 displays makes me wonder if Ubuntu/X will see it so. And I'll have 'dual monitors' on one screen. 
#juju-gui 2014-12-15
<hatch> lazyPower: mbruzek one more blocker resolved towards some ghost bundles http://fromanegg.com/post/105250564587/how-to-rewrite-and-redirect-with-haproxy
<mbruzek> Thanks hatch I will give that read!
<hatch> mbruzek: now I have to make some big modifications to the haproxy charm but I have to formulate a plan for that yet
<hatch> rick_h_: the gui bug in FF from adam turns out is only reproducible on his laptop 
<hatch> so probably not a bug 
<hatch> :)
<rick_h_> uiteam call in 10 kankan please
<hatch> rick_h_: ok finished the updates to that branch, did you want to take another look or should I just shippit?
<rick_h_> hatch: did my stuff make sense on the dupes?
<rick_h_> hatch: have a call atm but can look after
<hatch> yeah it's all done now - works really well
<hatch> I was thinking i'd pick up some smaller stuff now
<hatch> since the quickstart stuff has been picked up
<hatch> I could also moved to the charm details pane but that might take longer than a day
<hatch> rick_h_: have you had a chance to look at the PR yet? 
<hatch> or have a preference on my next card
<rick_h_> hatch: no still otp
<rick_h_> looong meeting yay
<hatch> oh haha
<hatch> so I'll just work on a smaller card
<rick_h_> cool
<rick_h_> hatch the ~charmers is invalid
<hatch> how do you mean? The id contains ~charmers
<hatch> cs:~charmers/precise/foo
<hatch> this filters out the ~charmers duplicate charms and leaves the cs:precise/foo ones in the list
<hatch> when the api is updated to remove those then that conditional can go away
<rick_h_> hatch: not all are ~charmers
<hatch> the only other one which is duplicated is the ~juju-gui-charmers which no longer shows up in the results for some reason
<rick_h_> cs:juju-gui-7 is the same as cs:juju-gui-charmers/juju-gui-7
<rick_h_> openstack-charmers, landscape-charmers, big-data-charmers
<hatch> did it show up in the list? I couldn't get a duplicate result with the new querystring
<rick_h_> no, I just know it's incomplete logic
<rick_h_> if this call ends we can chat and I'll explain
<rick_h_> my one hand isn't making this clear :)
<hatch> right but if people can add random '*-charmers' people then by hardcoding it in the GUI will always be wrong
<hatch> if it's always in the ~(*)charmers
<hatch> then we could filter off that
<rick_h_> hatch: standup
<hatch> well I suppose ~([a-zA-Z\-)+charmers
<hatch> ok
<hatch> regexr.com is an awesome tool for working on regex's
<hatch> rick_h_: just about to push that fix - shal I shippit after?
<hatch> pushed
<rick_h_> hatch: yes if you have qa from jcastro 
<hatch> oh ok ping jcastro  :)
<rick_h_> bah jcsackett 
<rick_h_> no poking fun of the one handed typist
<hatch> oh lol!
<jcastro> hatch, yp
<jcastro> err, yo
<rick_h_> did jcsackett review/qa? /me is going off memory and could be wrong
<hatch> rick_h_: kadams54-away did
<hatch> jcastro: turns out rick had a autocomplete failure :) We don't need you any longer
<rick_h_> hatch: oh ok then
<hatch> unless of course you want to qa the gui :)
<jcastro> Nope!
<hatch> haha 
<hatch> kadams54-away: back yet? :)
<hatch> we should use this :) https://www.sqwiggle.com/
<hatch> uiteam lf review and qa on https://github.com/juju/juju-gui/pull/678 thx
<hatch> well NOW whatamigunado
<sinzui> hi hatch Makyo: I am seeing errors like this when I use quickstart 1.3.1 with juju 1.20.11. : 
<sinzui> juju-quickstart: error: unable to connect to the Juju API server on wss://ec2-54-224-222-48.compute-1.amazonaws.com:17070: [Errno 1] _ssl.c:510: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
<sinzui> ERROR subprocess encountered error code 1
<sinzui> Is my configuration wrong or is Juju being bad
<hatch> I've never actually seen that error
<sinzui> I know deployer can deploy the same bundle
 * sinzui tries quickstart from ppa
<hatch> sinzui: does that version of quickstart work for you if you just use it for the basic functionality? setup & gui install?
<hatch> or does it only fail when deploying the bundle
<sinzui> hatch, the failure was at the start of the deployment. Bootstrapp completed, but we couldn't talk to the api server on joyent or aws
<hatch> that is very odd...
<hatch> let me see what version I have
<hatch> 1.5.0
<hatch> hrh
<hatch> heh you're behind :)
<sinzui> hatch, I was using 1.20.15 and 1.5 last week with great success
<sinzui> hatch, I was using 1.20.14 and 1.5 last week with great success
<sinzui> I hope .15 never exists
<hatch> lol - so why did you downgrade your quickstart?
<sinzui> hatch, I am doing acceptance testing for Ubuntu. It ships with the old version
<hatch> ohh
<hatch> ok so the best guy to talk to about that stuff is frankban
<hatch> maybe best to fire him (or peeps) an email with all the details
<hatch> or file a bug for that matter heh 
<hatch> I know we're all pretty busy with various stuff this week :)
<sinzui> thank you hatch
<sinzui> I am beginning to think I have a config error. I hope the problem is just me.
<hatch> sorry I couldn't be of more help it's been a while since I've been in the quickstart world
<hatch> :) 
#juju-gui 2014-12-16
<rick_h_> hatch: miss another reviewq/qa before landing?
<hatch> oh yeah woops :/ I think I got the two mixed up 
<hatch> although 677 still needs that final qa
<rick_h_> hatch: k, can try tomorrow
<rick_h_> hatch: don't forget you had a review today too
<rick_h_> first thing
<rick_h_> hatch: and we can check with frankban but I think the charm is fine and we can start the gui release first thing tomorrow
<rick_h_> just so you're not bored tomorrow
<rick_h_> :)
 * rick_h_ considers caught up enough for tonight
<hatch> haha 
<hatch> kadams54: can you do another review of 677 so I can land it?
<kadams54> hatch: Sure, taking a look
<kadams54> hatch: is the juju-gui charm supposed to be filtered out?
<hatch> kadams54: I didn't because it only shows up sometimes now
<kadams54> k
<hatch> ooo ghost added xml sitemaps
<kadams54> QA is OK
<hatch> thanks
<hatch> rick_h_: hey you mentioned that I should start looking at doing a gui release? 
<hatch> still looking like that's good?
<rick_h_> hatch: let's verify with frankban but last I recall we don't need gui charm changes so release is unblocked
<frankban> rick_h_: confirmed
<hatch> oh? none of the quickstart changes effect the gui?
<hatch> nice
<hatch> ok I'll start qa'ing
<hatch> the related charms section in charm details page has all the icons broken 
<hatch> will need to fix that
<rick_h_> hatch: rgr
<rick_h_> hatch: can you add a card please?
<hatch> already done :)
<rick_h_> ty
<rick_h_> uiteam call in 10 kanban please
<hatch> https://api.jujucharms.com/charmstore/v4/yui_3_11_0_1_1418744920875_6993/icon.svg
<hatch> heh nope that's not right
<hatch> :)
<hatch> boom fixed!
<hatch> I still think this page makes no sense
<hatch> lol
<hatch> another time!
<frankban> uiteam: I need reviews/QA for https://codereview.appspot.com/188300043 (quickstart / python). anyone available?
<hatch> uiteam I need a review and qa for a small bug fix (release blocker)
<hatch> https://github.com/juju/juju-gui/pull/679
<hatch> ok just need qa now 
<hatch> now this next bug is interesting....quite interesting indeed
<hatch> uiteam ok I now need reviews on #679 and #680 both release blockers
<hatch> now onto flag removal
<hatch> rick_h_: do we have mockups for the login stuff? The markup that the 'showGetJujuButton' references is no longer there
<rick_h_> hatch: kadams54 jcsackett ^
<kadams54> hatch: Looking at both.
<hatch> we'll need to update the gui charm to not set that config value
<hatch> there is some conflicting comments in the code around the logout-trigger button too
<hatch> some areas say it can be removed but it's actually being used
<hatch> kadams54: ok I'm ready to push the removal of this flags stuff - any word on the mockups?
<kadams54> hatch: I'm very confused at this point. Do you mean mockups for login work in GUI or blues browser?
<hatch> gui
<hatch> this is the gui channel afterall :)
<hatch> I just can't find anything searching in the drive
<kadams54> hatch: Not that I've seen.
<kadams54> Or can remember ;-)
<hatch> haha hmm
<hatch> maybe it's in the email somewhere
<hatch> yup email hah
<hatch> man we need to make a rule that this stuff needs to go in one spot
<hatch> rick_h_: ok yeah so it looks like the charm will need to be updated to not set this flag 'showGetJujuButton'
<hatch> card created
<hatch> will get on that next
<hatch> uiteam reviews and qa's on #680 #681 :D 
<kadams54> Looking
<kadams54> Just out of curiosity, how many more of these we got left?
<hatch> 0 for the GUI, 1 for the charm
<hatch> but of course I still need to do another round of qa
<hatch> so....TBD :P
<hatch> kadams54: fyi you were sent the email with the logout dropdown :P
<hatch> forgot - new computer, no guicharm branches locally
<hatch> cya in 2 weeks :P
<hatch> uiteam I need one more review on #680
<hatch> kadams54: will you be able to review/qa 681 as well?
<kadams54> hatch: In progress
<hatch> thanks
<hatch> rick_h_: changes to the charm get done in lp:~juju-gui/charms/trusty/juju-gui/trunk/ then merged into precise?
<hatch> It's been a while since I've done charm work 
<rick_h_> hatch: yes 
 * rick_h_ has to get food finally off calls
<hatch> thanks
<hatch> :)
<kadams54> hatch: Done on 681.
<hatch> kadams54: thanks
<hatch> kadams54: turns out the test failure is because the new logout button is hidden so I need to update the selenium test to open the dropdown first
<rick_h_> hatch: have reviews?
<rick_h_> hatch: no pr link in the card in review
<hatch> doh did I miss one
<hatch> updating
<hatch> updated
<hatch> 680 is in need of another review
<hatch> 681 has a selenium failure which I'm fixing
<rick_h_> k
<hatch> so a review can hold off on that
<hatch> ok pushed the fix for the selenium tests, hope it works ;)
<rick_h_> :)
<hatch> replied
<hatch> annnd charm modified
<hatch> bleh selenium test changes didn't work - looks like I'll have to set it up locally and test
<hatch> but first, lunch
<hatch> uiteam lf reviews and qa on https://github.com/juju/juju-gui/pull/682
<hatch> thx
<hatch> ^ rick_h_ the fruits of our discussion (from the GUI side)
<rick_h_> hatch: ty will look
#juju-gui 2014-12-17
<rick_h_> lazyPower: sexy demo :)
<lazyPower> rick_h_: yeah man - the GUI made that so simple to illustrate
<lazyPower> hi5 on machine view - I've been looking for an excuse to showcase it
<rick_h_> loved the containers and icons popping up :)
<hatch> ooo demo? 
<lazyPower> hatch: yeah - its up on plus. I didn't intend to pull the trigger on publishing it yet - i was goign to wait for the AM when all the IT jockeys are hangin out reading email and sipping coffee trolling ycombinator.
<lazyPower> looks like that plan was fail :P
<hatch> lol
<rick_h_> :P
<hatch> will take a look
<lazyPower> https://www.youtube.com/watch?v=bCvl-TsxVXA&feature=youtu.be
<hatch> your intro!
 * hatch busts out his glow sticks
<rick_h_> lol
<hatch> after effects?
<hatch> audio sounds awesome too
<lazyPower> hatch: Nope - i dont have a windows box 
<lazyPower> found a dude on fiverr - sent him what i wanted in a rough sketch - got that back 32 hours later for $5
<hatch> serious?
<hatch> awesome!!!
<hatch> I didn't know this site existed
<hatch> lazyPower: curious why you picked etcd vs any of the other k/v stores?
<hatch> lazyPower: it's awesome seeing the containers come up and stuff in the gui as you do it in the console :D
<lazyPower> hatch: flannel requires etc
<lazyPower> *etcd
<hatch> ahh ok
<lazyPower> hatch: plus, stands to reason they would dogfood their own services - https://github.com/coreos/etcd
<hatch> heh yeah true true
<urulama_> uiteam: food for thought ... lastpass does not recognise juju-gui login as login window :)
<fabrice> you're here as urulama_ and urulama|out
<fabrice> so in or out ?
<urulama_> fabrice: yes, i have a split personality :)
<urulama_> fabrice: i'm out (officially) 
<fabrice> so get out
<urulama_> fabrice: :) i will
<rick_h_> urulama|out: interesting
<hatch> rick_h_: urulama|out its' because the fields don't have 'name' parameters of "username" and "password"
<hatch> it's a trivial template fix
<rick_h_> hatch: yea figured
<rick_h_> but have to watch if anything relies on current names
<rick_h_> hatch: but for another day
<hatch> rick_h_: we just need to add `name="username"` and `name="password"` 
<hatch> there are no name attributes right now
<rick_h_> oh no name attr at all?
<rick_h_> heh
<hatch> nope
<urulama|out> hey, hatch, rick_h_: i just wanted to start a conversation, whether it would make sense to be able to store those to lastpass at all. but yeah, maybe fixing that template so that people are able to store them if needed would be a good thing
<hatch> yeah, it really can't hurt :)
<rick_h_> urulama|out: yea good note
<hatch> uiteam lf a review and qa https://github.com/juju/juju-gui/pull/682
<rick_h_> uiteam call in 10 kanban please
<hatch> kadams54: are you able to hop on #682? It's a pretty quick one
<kadams54> hatch: yes, but I want to wrap up my current work before I switch contexts. Give me five minutes.
<hatch> sure np 
<hatch> thx
<Makyo> hatch, what can I do to help?
<kadams54> hatch: Done on #682 with comments
<hatch> kadams54: thanks
<hatch> Makyo: you could get the drag and drop working again?
<Makyo> hatch, on it
<hatch> thanks - card is in urgent
<hatch> kadams54: depressed state? it doesn't look highlighted to me
<hatch> oh
<hatch> now I see
<hatch> (need moar contrast)
<kadams54> It actually looks inset
<hatch> yeah
<kadams54> Plus no hover state
<hatch> I'm going to say intentional because if you look at the old button http://comingsoon.jujucharms.com/ it's also inset
<hatch> kadams54: if you like you could file a bug about it - the mocks don't really show what this is supposed to look like so we're just making it reasonable :)
<kadams54> hatch: OK, sounds good to me.
<hatch> thx
<hatch> Makyo: if you have any questions about that card just let me know
<hatch> uiteam lf review and qa on https://github.com/juju/juju-gui/pull/683 2 liner
<hatch> Makyo: think while you're doing this bundle stuff you could qa frankban's guicharm branch? I don't have 1.21 installed
<Makyo> hatch, I can maybe take a look in a bit, trying not to get too scattered.
<hatch> sure no problem
<hatch> that drag and drop stuff is deeply intertwined 
<Makyo> hatch, fwiw, it might be worth upgrading.  `apt-add-repository ppa:juju/devel && apt-get update; apt-get upgrade` and see https://launchpad.net/~juju/+archive/ubuntu/devel
<hatch> yeah I can do that in a container
<hatch> I just didn't want to set a container up :)
<hatch> guess I could do that
<hatch> yeah ok I'll just container it up
<Makyo> Whine whine whine :)
 * hatch stomps his feet
<Makyo> I just think it'd be worth having around with the user stuff
<hatch> rick_h_: I forget the lxc command to mount the user dir during lxc creationg
<hatch> I really should write this down
<jrwren> hatch: -b username ?
<hatch> -b is it? 
<hatch> cool
<jrwren> sudo lxc-create -t ubuntu -n awesomelxc -- -b hatch
<hatch> oh the -- I was missing
<hatch> what's the -- for?
<jrwren> its a template option
<hatch> yeah that doesn't clear it up much :)
<jrwren> hatch: it gets passed as an argument to /usr/share/lxc/templates/lxc-ubuntu
<hatch> ohh
<jrwren> -t WHATEVER tells lxc-create to use /usr/share/lxc/templates/lxc-WHATEVER
<hatch> yep this api is worse than I originally thought
<jrwren> hatch: lolz
<hatch> doh lint error
<rick_h_> you lose
<hatch> big time!
<hatch> Makyo: when you're available mind giving me an update on your branch? I'm wondering if the bundle yaml deploy part can be done in your branch or is separate.
<Makyo> hatch, I think the bundle yaml thing should be able to fit, at least as an iteration, then deployer will need an update.
<Makyo> Got the charm bit already done.
<hatch> awesome 
<hatch> ok I won't start on the yaml part then
<hatch> I just didn't want to dupe work
<hatch> thanks
<Makyo> hatch, yep, sounds good.
<Makyo> Going to duck out for lunch for a few, gotta hit the post office.
<hatch> :)
<hatch> lata
<hatch> hey what app are you guys using for epub on ubuntu?
<hatch> reading it
<rick_h_> ummm, kindle?
<rick_h_> :P
<mbruzek> Hi rick_h_ I just updated the information on this bug https://bugs.launchpad.net/juju-gui/+bug/1402061
<mup> Bug #1402061: The juju-gui charm fails automated testing <audit> <auto-test> <juju-gui:Triaged> <https://launchpad.net/bugs/1402061>
<rick_h_> mbruzek: rgr ty
<mbruzek> rick_h_: I ran additional automated tests to see if the results changed and they did not.
<rick_h_> mbruzek: understand, we'll look into it. 
<rick_h_> mbruzek: it was just odd since there haven't been charm changes and when looking it was odd how the different clouds weren't consistent that I could tell/etc
<mbruzek> rick_h_: Yeah this automated system has all kinds of quirks.
<mbruzek> rick_h_: Interesting to note that I could not even run "make lint" successfully on my system.
<rick_h_> we'll look into it. We run the tests on every release and we're prepping another one so we'll be curious to see what we get.
<rick_h_> mbruzek: right, we had some deps issues that aisrael fixed a while back
<rick_h_> mbruzek: that's when we first went to passing after some of the sysdeps/etc was worked out with the way the tests run
<mbruzek> rick_h_: I can run additional tests on a launchpad branch if you need some pre-publish result
<mbruzek> s
<rick_h_> mbruzek: naw, we'll take care of it. We definitely want a charm that passes our own tests/lint
<rick_h_> if it doesn't that's on us to fix
<rick_h_> ty for the heads up and check on info
<mbruzek> rick_h_: Let me know if there is anything I can do to help
<rick_h_> <3
<mbruzek> I have 48 other charm authors to chase down for the automated test failures
<rick_h_> well we've always prided ourselves a bit on setting a good example. We'll try to make sure we get off the list. :)
<mbruzek> rick_h_: I have no doubt
<hatch> mbruzek: I can run make lint here I have a fresh checkout
<hatch> running
<mbruzek> hatch: no one trusts you gui guy's environments
<rick_h_> hatch: added the card into maint urgent. As we do the release we should check out wtf is up
<hatch> lol
<rick_h_> hatch: but we can work it out as we do our tests/etc as part of the release
<hatch> sure thing
<mbruzek> hatch: rick_h_ I have no doubt it works for you guys, just noting that it did not run in my system.  Perhaps there is a dependency that you have installed that I do not
<hatch> gnugcc failure heh
<hatch> bzrlib/_annotator_pyx.c:4:20: fatal error: Python.h: No such file or directory
<hatch> looks like the make target is missing something
<mbruzek> hatch: if you come up with a fix and want to  test it on someones system, I am happy to test your branches
<rick_h_> hatch: the sysdeps, python-dev is where that comes from
<hatch> mbruzek: well I actually need this specific issue fixed for my upcoming guicharm branch
<rick_h_> hatch: we had a commit from aisrael a while back that set it up for us 
<rick_h_> at leasts for the test system
<hatch> mbruzek: so does the tests run make sysdeps first?
<rick_h_> we normally manually run make sysdeps
<rick_h_> hatch: no, there's a test file that lists the deps
<hatch> right - so if this system is to be automated then that's where the issue is
<hatch> or at least where 'a' issue is
<rick_h_> hatch: rgr
<mbruzek> hatch: the automated test only run `make lint`, `make test`, and runs all the executable files in the juju-gui/tests directory
<hatch> ahah 
<mbruzek> hatch: I do not believe it runs 'make sysdeps' but I suspect you could make lint depend on that target
<hatch> tbh I haven't looked at the makefile in forever
<rick_h_> hatch: looking for the commit that added the test file and not seeing it
<rick_h_> maybe we had a merge failure in release
<rick_h_> http://bazaar.launchpad.net/~juju-gui-charmers/charms/trusty/juju-gui/trunk/revision/101
<rick_h_> hatch: ^
<hatch> hmm
<rick_h_> hatch: so that is supposed to take care of our 'sysdeps' target for the automated test system
<rick_h_> hatch: if it's not we need to see why/etc
<hatch> hmm
<hatch> looks like that allowed the lint tests to run
<hatch> mbruzek: is there any way I can simulate the test env locally?
<hatch> or a machine I can deploy to
<hatch> etc 
<mbruzek> hatch absolutely
<mbruzek> To run locally, install bundletester this way
<mbruzek> https://github.com/juju-solutions/bundletester
<mbruzek> Then you can run $ bundletester -F -e local -l DEBUG -v
<hatch>  but the gui is just a charm, not a bundle
<mbruzek> hatch: poor choice of names for our automated testing tool
<mbruzek> It handles bundles as well as charms
<hatch> oh lol yes...fail
<hatch> haha thanks
#juju-gui 2014-12-18
<hatch> uiteam still need 2 for https://github.com/juju/juju-gui/pull/683 thx
<hatch> uiteam ok now I just need a qa
<rick_h_> hatch: try to get Makyo to qa please
<hatch> I need a wall of clocks to know when people get in every day
<kadams54> hatch: I can also QA.
<hatch> kadams54: thanks
<hatch>  new startup idea - company that doesn't do timezones
<kadams54> hatch: isn't Makyo in your timezone? ;-)
<hatch> kadams54: only part of the year :)
<hatch> but I don't know which part lol
<kadams54> Gah! You don't do DST?
<hatch> nope GMT-6 year round
<hatch> it's dark when we go to work and come home from work so DST wouldn't help haha
<hatch> kadams54: downside is we can't say we forgot about the tz change and skip the first hour of work for a week
<hatch> haha
<kadams54> I hate DST, so more power to ya.
<hatch> does anyone know how to get `bzr grep` to have colour output like `git grep` ?
<rick_h_> bzr grep | grep 
<rick_h_> my grep has color
<hatch> pipe the grep to grep?
<rick_h_> grep has color :)
<hatch> haha
<hatch> ohh functional charm tests
<hatch> you take so long
<hatch> rick_h_: when you ran the functional charm tests did you get a few which had the following error: skipped 'admin secret was not found'
<rick_h_> hatch: don't reca;; check with frankban please otp
<frankban> hatch: looking
<hatch> the env it's deploying to is aws if that matters
<frankban> hatch: ok so the charm skips tests requiring authentication if the environment you use to run the tests does not have an admin-secret defined in ~/.juju/environments.yaml
<hatch> doh! I wrote this config manually
<hatch> so I missed that
<frankban> hatch: this can be improved instructing the charm to retrieve the password from the jenv file, but there where no jenv files at the time those tests where initially written
<hatch> I guess I'll need to restart this now
<hatch> thanks
<hatch> ok I've got the changes to the charm made and the tests/lint pass
<kadams54> hatch: just +1'd https://github.com/juju/juju-gui/pull/683
<hatch> kadams54: thanks
<hatch> frankban: so now that I have these changes made and committed how do I get it up for review without lbox? :)
<hatch> push to my 'branch' and make a merge on LP?
<frankban> hatch: you can propose it in launchpad
<frankban> hatch: against lp:~juju-gui/charms/trusty/juju-gui/trunk
<frankban> hatch: reviewers should run make unittest and make lint since that's what usually lbox run 
<hatch> ok thanks
<hatch> frankban: this done properly? https://code.launchpad.net/~hatch/charms/trusty/juju-gui/hide-login-button/+merge/245137
<frankban> hatch: the target should be lp:~juju-gui/charms/trusty/juju-gui/trunk
<hatch> trying again https://code.launchpad.net/~hatch/charms/trusty/juju-gui/hide-login-button/+merge/245138
<hatch> :)
<frankban> hatch: better :-) just set a commit message and a description please
<hatch> cool
<hatch> uiteam lf review and qa on my guicharm changes https://code.launchpad.net/~hatch/charms/trusty/juju-gui/hide-login-button/+merge/245138
<hatch> Makyo: should I move the bundle yaml card into coding with your head on it?
<Makyo> hatch, I don't think they should be separate cards.  One card per branch is my preference.
<hatch> cool, updated your card and deleted the old one
<hatch> back to queue eh!
<hatch> ^ british canadian version of qa
<hatch> there is a weird bug in the guicharm where if you change the source before it's deployed it'll fail to build the source
<hatch> but it appears to be random as to when the bug happens
<frankban> hatch: never encountered that
<hatch> after logging in using the latest charm and gui I get an http auth popup?
<hatch> https://admin:<the admin secret>@10.0.3.10/juju-core/charms?url=local:trusty/juju-gui-0&file=icon.svg
<hatch> because of this request
<hatch> any ideas?
<hatch> hmm the code that's generating that icon path is definitely not right
<frankban> hatch: why it isn't?
<frankban> hatch: and shouldn't the user in basic http auth be user-admin rather than just admin?
<hatch> frankban: well it needs to be able to make the request without the extra http auth
<frankban> hatch: you are requesting the local charm icon from juju-core, and that requires auth
<hatch> so I don't recall any of that code being changed
<frankban> hatch: perhaps I am wrong, but the user there should be user-admin. could you try? maybe Makyo can help with the user stuff in the GUI
<hatch> oh maybe that was changed with the login stuff
<hatch> if it's supposed to be user-admin
<hatch> that's somewhere to start
<hatch> thanks
<frankban> np
<hatch> frankban: yes it's that it should be user-admin
<hatch> frankban: so for all users should it be prefixed with 'user-' ?
<hatch> or only admin
<frankban> hatch: cool, all users
<hatch> thanks
<frankban> done for the day, good night all!
<hatch> night frankban 
<hatch> it's interesting how the terminal and sublime are using the same fonts at the same size but they look completely different
<hatch> we should find some time to go through the entire test suit and remove the foo.should.equal() stuff 
<hatch> uiteam lf 2x review and a qa for https://github.com/juju/juju-gui/pull/684
<hatch> ok here is to hoping that's all the bugs heh
<hatch> uiteam I also still need one qa on https://code.launchpad.net/~hatch/charms/trusty/juju-gui/hide-login-button/+merge/245138
<hatch> guicharm change
<hatch> I think that that's all the gui bugs
<hatch> besides the ones we already know about it seems pretty stable
<hatch> update your gits https://github.com/blog/1938-vulnerability-announced-update-your-git-clients
<hatch> anyone use an apple 'magicpad' with ubuntu? It seems to fail the sync
<hatch> bleh I had to install blueman - apparently the default ubuntu bluetooth software is no good
#juju-gui 2014-12-19
<hatch> frankban: thanks for the reveiw I replied 
<frankban> hatch: I see
<frankban> hatch: could you add an XXX then?
<hatch> I can, thanks
<hatch> uiteam still need one more review here https://github.com/juju/juju-gui/pull/684
<jcsackett> hatch: i can look.
<hatch> thanks
<hatch> and my link to my charm branch was removed from the card....awesome
<hatch> bac: why u remove my link?
 * hatch crys
<bac> hatch: i put it where it belongs
<hatch> oh now I see
<bac> right-clicky -> link to
<hatch> interesting, I didn't know about that
<urulama> hatch: done :)
<hatch> bac: I do need a hand landing it, I thought there would be a 'merge' button :) Do I have to do it manually?
<bac> hatch: since you couldn't use lbox then we'll have to hand land it
<bac> hatch: it requires a few steps.  get a clean trunk, merge your dev branch into it with the message "[r=frankban,bac] blah blah description", then push that branch back to trunk on LP
<hatch> urulama: you and frankban both want it as a constant....Where would you like it placed?
<hatch> bac: ok I can do that
<urulama> hatch: it's just all over the code and it looks like something that could be "global" 
<hatch> urulama: well it's actually only in a single place in the code, but all over in the tests
<hatch> the only way to possibly protect from that is to use a global which introduces other issues
<urulama> hatch: yes, you can change that in that one place, but the test will work anyway even if the actual code fails
<urulama> yeah, probably too much "go-like" requirement anyway
<urulama> i just noticed that you can change main code and break it but the test will still work
<hatch> There are places where globals would be nice but we don't really have a 'safe' place to put them 
<hatch> I was sure the tests would fail if I changed the code, lemme take another look
<rick_h_> hatch: what is this?
<hatch> rick_h_: https://github.com/juju/juju-gui/pull/684/files
<hatch> first comments
<rick_h_> hatch: hmmm, yea seems it'd be api specific so a go.js thing
<hatch> unfortunately that's what caused the original issue :) it being go.js specific haha
<hatch> I COULD move it back in there
<hatch> but every time it makes a request in any method it would have to get the credentials and then check the username
<hatch> so this is quite a bit more dry
<rick_h_> hatch: so can you just make it a constant in this file?
<rick_h_> API_USER_TAG
<hatch> sure 
<rick_h_> = 'user-'
<hatch> just not sure the 2 places it's used really warrant a constant :) 
<hatch> but 4:1 I lose :P
<rick_h_> :)
<frankban> hatch: yeah I agree with 2 places is not a parameter point, but in this case I value more the documentation aspects, i.e. we are not adding prefixes just because, we know this is how juju builds the freaking user entity tags ;-)
<hatch> lol
<hatch> it is very odd
<hatch> I've noticed phantom crashing quite a lot lately
<Makyo> Me too. It's a pain
<hatch> now to try and merge my guicharm changes without blowing it all up
 * hatch starts the Mission Impossible theme song
<Makyo> I was thinking more along the lines of Yackety Sax.
<hatch> lol!
<Makyo> Or http://www.youtube.com/watch?v=V66m52YFZBg
<hatch> Hah I don't know that one
<rick_h_> uiteamm call in 10 kanban please
 * hatch is going to be a golang master after the break
<hatch> bac: the branch that I worked in was branched from lp:~juju-gui/charms/trusty/juju-gui/trunk and there is only a single commit - can I jush push it back up without doing all the merge business?
<rick_h_> kadams54: call
 * Makyo runs to coffee
<hatch> Makyo: once you get back and get your branch all figured out lemme know and I can re-review
<Makyo> Sure thing
<hatch> enjoy!
<hatch> rick_h_: http://2014.jsconf.eu/speakers/rob-ashton-got-make.html :)
<rick_h_> lol /me queues up on the chromecast
<hatch> http://css-tricks.com/icon-fonts-vs-svg/ TLDR use SVG 
<mbruzek> Hey hatch
<mbruzek> I need your help
<mbruzek> Is there a way to get a list of maintianers for some given charms?
<hatch> mbruzek: hey
<hatch> umm got a charm in mind?
<hatch> I can see
<mbruzek> hatch: ALL of them
<mbruzek> you guys have all the crazy apis
<mbruzek> varnish for example
<hatch> ok lemme see what's available
<hatch> mbruzek: well I don't think that those are listed yet
<hatch> at least I can't find anything which has them
<hatch> mbruzek: you might want to fire an email about that one
<mbruzek> hatch: thanks.  I figured with your API knowledge you might be able to find some kind of query like that.
<hatch> mbruzek: yeah it doesn't appear to be in the api *shrugs*
<hatch> so either I'm missing something or it's actually not there :)
<mbruzek> hatch: it would probably be:  get_charm(), get_metadata()['maintainer']
<mbruzek> something like that.  I suspect that would be really resource intensive, what rick_h_ told me going inside the charms was expensive
<mbruzek> but it beats what I am doing now.  $ charm getall && grep -h maintainer */metadata.yaml | cut -d : -f 2 | sort | uniq > charmers_email.list
<hatch> haha not gona lie anything done with the api wouldn't be much better :D
<mbruzek> charm getall branches ALL the files of ALL the charms
<hatch> you'd have to request them one/one (or in batches)
<hatch> well blame bzr for that nonsense :P
<hatch> mbruzek: you could probably rig up some type of a script to request the metadata.yaml html page from LP
<hatch> and then you could parse from there
#juju-gui 2015-12-15
<tvansteenburgh> frankban: juju-deployer-0.6.1 released to pypi, can you please add to the ppa at your convenience?
<frankban> tvansteenburgh: sure, I'll try to do that this week
<tvansteenburgh> frankban: thanks!
#juju-gui 2015-12-16
<arosales> hello
<arosales> I had a question come in from david duffey re an mp @ https://code.launchpad.net/~david-duffey/juju-quickstart/packaging/+merge/277392
<arosales> is there any other action needed to help move this MP forward?
<rick_h_> bac can you look at ^ please?
<BradCrittenden> hello
 * bac looking
<bac> arosales, rick_h_: the MP looks pretty straightforward.  i suspect it just fell off francesco's radar.  i'll try to grab it and QA this afternoon
<arosales> bac: no rush, just came up in conversation if they were following the correct process
<arosales> bac: if you have any questions dduffey is the author of that patch
<bac> arosales: yes, thanks for the heads up
<arosales> bac: np, thanks for the help
<bac> arosales: i see frankban has a task to release a new quickstart shortly.  we'll try to get this included
<dduffey> bac, that would be cool!  It shouldn't effect anything since it is just dropping in an icon and desktop file
<bac> dduffey: gotcha
#juju-gui 2015-12-17
<jrwren> anyone else a little worried right now?
<urulama> jrwren: ?
<urulama> jrwren: irc server?
<jrwren> not just irc server. www.jujucharms.com is down too. makes me think a whole DC is down
<urulama> jrwren: oh!
<rick_h_> boom
<rick_h_> hmm, ubuntu.com, wiki works
<bac> pow
<jrwren> whew
<rick_h_> ubuntu insights is down though
<rick_h_> so yea, big boom
<bac> launchpad i sup
<bac> is up
<jrwren> i wonder if ubuntu.com is cloudflair fronted :)
<jrwren> oh, yeah lp!
<rick_h_> LP seems up
<bac> join freenode #canonical-sysadmin
<rick_h_> and SSO
<urulama> login.ubuntu.com as well
<rick_h_> bac: or urulama can you please see about updating topics in juju related channels for the outage?
<bac> rick_h_: yes
* urulama changed the topic of #juju-gui to: Juju GUI - Mailing List  https://lists.ubuntu.com/mailman/listinfo/juju-gui - Note: jujucharms.com is down
<rick_h_> urulama: rumor is "ps4.5 went boom"
 * rick_h_ dies a little more inside
<rick_h_> urulama: bac jcsackett we need to have a plan for a redo on mojo/prodstack just in case please. 
<bac> rick_h_: i'm not sure what such a plan would look like.  our current mojo is fully deployable from scratch
<jcsackett> so then, that's our plan. :p
<bac> rick_h_: IOW, if we have new machines it should be good to go
<urulama> let's see, it sounds it's a networking issue
<rick_h_> jcsackett: bac urulama I guess maybe I mean more...let's have folks on deck ready to help walk/deal with any issues getting a rebuild
<bac> rick_h_: certainly
<rick_h_> urulama: rumor in telegram is "openvswitch auto upgrade"
<urulama> lovely. so content should be fine
<rick_h_> urulama: hopefully
<urulama> but yeah, i'll be around ... it's been months since we had real issues :)
<bac> uiteam: the topic in #canonical-sysadmin was changed to "network issues".  so cross fingers that the actual machines are still there
<frankban_> yeah
 * rick_h_ starts to open/air a bottle of wine
<bac> urulama: haha, too bad you're not on telegram.  <ducks>
<frankban_> urulama: on the other hand, great news in mail about cmr
<urulama> bac: one more reason not to be there :)
<bac> urulama: chicken
<urulama> frankban_: \o/
<jrwren> lol @ "auto upgrade"
<bac> urulama: should we tweet a status message
<urulama> bac: please do
 * bac looks for credentials
<bac> urulama: done
<urulama> bac: ty much!
<bac> incident report opened: https://wiki.canonical.com/IncidentReports/2015-12-17-ps45-networking-issues
<bac> no content yet
<urulama> we need to have 2 envs in two reagions
<urulama> at least
<jrwren> cross env relations are coming :p
<urulama> heh, old clients (< 1.24) can still deploy
<urulama> https://manage.jujucharms.com/api/3/charm/trusty/juju-gui
<urulama> :)
<frankban_> urulama: not without the legacy charm store
<urulama> frankban_: hah, right
<fabrice> urulama: let's ave our own region on aws 
<bac> urulama: that's great news that the old charmworld is alive.  i'd hate to have to bring it back up
<urulama> exactly! that's why i wanted to check it out
<bac> mthaddon posted an update.  restarting neutron on affected machines
<fabrice> humm neutrron update, sounds familiar
<urulama> uiteam: irc is up
<frankban_> urulama: the charm store is up
<fabrice> jujucharms.com is up
<jcsackett> \o/
<jrwren> nice recovery!
<urulama> jrwren: it's still down
<jrwren> oh.
<urulama> or better, it's down again
* urulama changed the topic of #juju-gui to: Juju GUI - Mailing List  https://lists.ubuntu.com/mailman/listinfo/juju-gui
<rogpeppe1> fabrice|school: how can you say i'm not on vacation?! that's *fun. :)
<frankban_> uiteam call in 10
<urulama> hey there, rogpeppe1
<urulama> how's it going?
<rogpeppe1> urulama: yo!
<rogpeppe1> urulama: good thanks
<rogpeppe1> urulama: made some good progress with my hydro project this week
<rogpeppe1> urulama: (and just got distracted with the letsencrypt thing :-])
<rogpeppe1> urulama: how's it going in topazland?
<urulama> rogpeppe1: all good apart from current outage :)
<urulama> rogpeppe1: where are you at with hydro project? 
<rogpeppe1> urulama: i have linked frontend and backend, so i can edit stuff in frontend and i see relays turn on and off (well, notionally, on my fake eth8020 relay server)
<rogpeppe1> urulama: the frontend still looks shit tho
<urulama> cool!
<urulama> will you make a snap in the end?
<rogpeppe1> urulama: and i'm not quite sure what kind of approach to use for "intermediate values" (i.e. user is modifying stuff; it *will* be valid but isn't yet)
<rogpeppe1> urulama: yeah, that's the idea
<fabrice> rogpeppe1: we have fun everyday !
<rogpeppe1> urulama: although i'm still not sure how to work the persistent data thing
<rogpeppe1> fabrice: yeah, of course, forgot :)
<jrwren> hydroponics?
<rogpeppe1> jrwren: that's right. an automated control system for my 13 acre marijuana plot
<rogpeppe1> jrwren: :)
<rogpeppe1> jrwren: hydro-electric
<jrwren> 13 acres! i wouldn't have to grow marijuana if I had that much land.
<jrwren> err, I mean, I wouldn't want to.
<rogpeppe1> lol
