#juju-gui 2013-07-08
<hatch> hi huwshimi
<huwshimi> hatch: Hey
<hatch> so what's monday looking like?
<hatch> I'm trying to decide if I should fake sick tomorrow
<hatch> kidding of course :P
<huwshimi> hatch: haha.
<hatch> I actually need some code that's on bcsaller's computer lol
<huwshimi> hatch: That's gonna be a long drive.
<hatch> haha you're tellin me!
<hatch> so instead I played way to much MTG
<huwshimi> hatch: MTG?
<hatch> Magic The Gathering
<huwshimi> Ah
<hatch> bought the new planeswalker game for Android
<hatch> it's $10 and still has in app purchases lol
<hatch> oh and ads :/
<hatch> ads for their own stuff mind you
<hatch> but still ads
<huwshimi> hatch: is that a MTG game?
<hatch> https://play.google.com/store/apps/details?id=com.stainlessgames.D14&feature=nav_result#?t=W251bGwsMSwxLDMsImNvbS5zdGFpbmxlc3NnYW1lcy5EMTQiXQ..
<hatch> ^ huwshimi I'm going to assume it's available there too
<gary_poster> morning
<rick_h_> morning
<rick_h_> gary_poster: did my last reply to the icon bug report clear that up? /me goes to get the link
<rick_h_> #1197772 is the one
<_mup_> Bug #1197772: Weird charm icon in GUI <charmbrowser> <juju-gui:Triaged> <https://launchpad.net/bugs/1197772>
<gary_poster> thanks, haven't gotten to that in mail yet.  looking
<rick_h_> k, no hurry. I'll bring it up on our stand up about the proof tools side of things. 
<gary_poster> rick_h_, read, got it.  so, can we treat that bug as the css issue you described?
<rick_h_> gary_poster: well I'd like to treat it as charmworld provides poor data bug 
<rick_h_> gary_poster: otherwise we have to double up logic on 'what categories are valid' in several projects in several places
<gary_poster> rick_h_, because the proof thing won't stop that kind of error from happening, right?  it will just inform the user?  if they don't do anything then we lose
<rick_h_> gary_poster: well charmworld should not load known bad data on injest
<gary_poster> oh
<rick_h_> gary_poster: so it should either strip the categories or something
<gary_poster> oh
<gary_poster> ok
<gary_poster> I'm ok with stripping the bad categories rick_h_ as a solution, yeah
<rick_h_> so I'd like to move the bug up there. Still a bug, but not really about the icon but allowing bad categories in
<gary_poster> sure
<gary_poster> thanks!
<gary_poster> rick_h_, I think I have some bugs I want to report to ecosystems and ux, but wanted to run them past you.  when I search for mysql and then filter to databases, I get no results.  It appears that mysql is not categorized as a database.  so, related bugs.  (1) ecosystems: we should categorize mysql as a database. (2) ux: we should be able to see the category of the charm when we browse it (agree?  is that already fixed in ne
<gary_poster> w ux?  I don't think so...). Then I dug around a bit more.  If you click on a category and then do a search, you are searching within the category.  that makes sense, but you can't see anything alerting you of that in the sidebar unless you expand the filter section or look at the URL.  (3) UX: fix that <--- (agree?  is this already addressed somehow?)
<rick_h_> gary_poster: so definitely think we need to audit approved charms for categories pre-launch. Those at least, should be updated. 
<rick_h_> gary_poster: and for the filter UX, I really don't like the auto collapsing because of that. It's not clear what's going on, but it's what UX has requested we try out. 
<rick_h_> gary_poster: so I'm up for helping defend the user that it's a bad experience
<rick_h_> gary_poster: in fullscreen (browse now) it's much nicer. 
<rick_h_> gary_poster: one thing we tossed out was that searching with filters/etc would require the fullscreen UX to help make it work?
<gary_poster> rick_h_, ok, thanks.  I'll send an email about those bits to the various parties, cc-ing the juju-gui list.  you didn't reply to #2 though.  Maybe it was not clear?
<rick_h_> gary_poster: ah, well not sure on #2. It's never really come up as categories were really only intended to help us group for the browse experience. Charms can have multiple, and they're completely optional. So display is a bit...unclear 
<rick_h_> gary_poster: issues with category are more for the charm authors to know/correct and that's more in the back end than for all users of the gui
<rick_h_> imo and all that :)
<gary_poster> rick_h_, ack.  I thought of that but felt that, if someone were purely exploring it might be nice ("'storm'?  is that the twitter hadoop thing I read about? ...oh, no, it is a database, nevermind"). I'll leave it alone for now.
<gary_poster> rick_h_, apache2 has no icon now.  no idea why.  maybe another thing to raise on team call?
<rick_h_> gary_poster: last time I looked they had a bad image as their icon. It was an issue with the charm source
<gary_poster> rick_h_, ack, but can we do better on our side is the question (i.e., is this something it would be relatively easy to detect and provide a default image for?)  if it is not easy maybe a bug would be reasonable.  But I think we ought to treat an empty image as a bug in the GUI of one sort or another.
<rick_h_> gary_poster: yea, we're still working out how we're supposed to note issues we know about to charms upstream. 
<rick_h_> gary_poster: so in this case, the svg is invalid or something. I cannot download/load it locally from the source. 
<rick_h_> gary_poster: the only 'good' way I can think to prevent this is to find some sort of svg validation/sanity check library on injest. If the icon fails, don't load it into the charmworld backend
<rick_h_> gary_poster: in this case it's not that it's 0 bytes, named wrong, etc
<rick_h_> http://bazaar.launchpad.net/~charmers/charms/precise/apache2/trunk/view/head:/icon.svg 
<gary_poster> rick_h_, cool, ack.  I wonder if simply trying to convert it (e.g. https://pypi.python.org/pypi/svglib/) and handling conversion errors as the sanity check would be reasonable.  I'll file a bug for the GUI side for now, and send an email to ecosystems about the immediate problem.  thanks
<rick_h_> gary_poster: well, I'd file it against charmworld
<gary_poster> rick_h_, ah good point thanks
<rick_h_> gary_poster: that's where the convert/validate would need to be updated to occur
<gary_poster> right
<jcastro> gary_poster: if we need like an apache2 icon we ask alejandra's team, then I can just add it to the charm right?
<gary_poster> jcastro, hey.  yeah, I am pretty sure you can ask alejandra's team for the icon, and I know you can just add it to the charm once you have it.  Was the previous working icon we had bad for some reason?
<jcastro> I don't know, I could have sworn I remember seeing the feather icon in the store at some point
<gary_poster> It was definitely there jcastro, I remember it too
<rick_h_> yea, I thought it had an icon at some point but did it get 'updated' and removed? 
<rick_h_> can we just go back and pull the old icon from the bzr history?
<jcastro> gary_poster: mysql category is easy, on that. 
<gary_poster> cool thanks jcastro 
<rick_h_> jcastro: make sure it's the plural please. We've got some that are invalid atm using database vs databases
<jcastro> k
<jcastro> category: ["databases"]
<jcastro> is in mysql
<rick_h_> jcastro: rgr
<rick_h_> jcastro: orly? /me goes to look
<jcastro> I'm looking in lp:charms/precise/mysql
<rick_h_> categories: - databases
<rick_h_> jcastro: http://bazaar.launchpad.net/~charmers/charms/precise/postgresql/trunk/view/head:/metadata.yaml is working in pgsql charm
<rick_h_> jcastro: yea, it's categories
<jcastro> that format appears totally different than what I have been doing
<rick_h_> plural plural plural
<rick_h_> everything in the metadata is plural. 
<rick_h_> provides, requires, etc
<jcastro> ok pushed
<hatch> morning all
<benji> jujugui: review ahoy! https://codereview.appspot.com/11001043
<hatch> I'll take one
<hatch> benji: does this branch have trunk merged in prior to proposing?
<hatch> some of this diff looks like trunk code
<benji> hatch: ooh, good catch; it does not.  I'll fix that right now.
<hatch> thanks :)
<teknico1> hatch: can I look over your shoulder? :-)
<teknico1> hatch: I mean, how about you comment loudly what you see while you review, and I get to listen and maybe even ask questions?
<teknico1> I guess that might count as a second review of sorts :-)
<hatch> teknico1: heh well I don't think there will be that large of a diff
<hatch> oh benji does this fix the drag&drop bug in FF osx?
<benji> hatch: nope
<hatch> ok didn't think so, just wanted to check
<benji> (not intentionally at least)
<teknico> otoh, today's net connection instability is not very conducive to these sorts of things :-/
<benji> hatch: merged branch pushed
<hatch> teknico: you think you have bad wiring... http://www.networkworld.com/gibbsblog/IW2.jpg :)
 * benji makes an overdue coffee.
<hatch> thanks benji
<teknico> heh
<hatch> benji: topology/service.js:425 where is the code that we hack the DOM to make the icon show?
 * hatch will see if there is a better way
<benji> hatch: app/widgets/charm-token.js:99
<hatch> thanks
<hatch> ohhh right that hack
<hatch> benji: did you try setting display to none on the icon?
<hatch> or would that have caused the dragged icon to not show up?
<hatch> (thinking out loud)
<benji> hatch: I don't recall.  I tried a myriad of things.
<hatch> heh i bet :)
<benji> hatch: "display: none" doesn't work in FF, the drag image reverts to the default
<hatch> benji: ahh ok well thanks a lot for trying :)
<benji> most browsers have very limiting restrictions requiring the drag image to really, truely be visible
<hatch> yeah the spec is such a mess
<hatch> the webdev community really needs to start relying on polyfills first to iron out the bugs before they make it into the browsers
<abentley> sinzui: The mimetypes.guess_type function does not accept contents, just a url: http://docs.python.org/2/library/mimetypes.html
<hatch> gary_poster: so as it turns out the position fixed idea won't work for us, and the position sticky polyfills all need to be.....modified... to work :)
<hatch> I could fork one of them and enhance the polyfill -or- I can write a module which just absolutely positions the headers when required
<abentley> sinzui: However, for this use case, the imghdr module should suffice.
<sinzui> fab
<sinzui> abentley, in the proof tool case I wanted to validate the xml, check that it is SVG, and maybe check for evidence that it uses the template
<sinzui> abentley, The xml validation code we have in charmworld's test suite could be extracted as a helper for ingest and test
<rick_h_> abentley: did you want to have a chat then before I go to far into this autocomplete stuff?
<abentley> rick_h_: sure.
<gary_poster> hatch on extended call run...trying to read...
<hatch> gary_poster: no problem, whenever you get a chance
<gary_poster> hatch not polyfill because it is not standard
<gary_poster> IMO
<gary_poster> module makes sense to me
<hatch> that's what I was thinking - I'll see if I can extract some of the code out of the polyfills to save some dev time
<gary_poster> +1
<benji> hatch: will you unpack this sentence a bit for me "I believe if you use @property it will automatically pick the closest class" (from https://codereview.appspot.com/11001043/diff/4001/app/widgets/charm-token.js?column_width=80)
<hatch> benji: sure :)
<hatch> because you're assigning a property to the instance if you use @property <name> I believe that YUIDoc will reach out of the method and pick the closest class that it's being added too
<hatch> so then when we look at the api docs for that class that property will be available
<abentley> sinzui: Thanks for the reviews.
<sinzui> np
<abentley> sinzui: You may have been thinking of the "magic" package.  It's not part of the standard library, but I think it really should be.
<sinzui> abentley, bingo. I was
<hatch> gary_poster: if you noticed on the boards I haven't deleted the cards yet from the last release - wondering what the procedure was for that
<benji> hatch: I will need an unpacking of your unpacking.  Are you propsoing I add an @property comment to the initializer (or the class)?
<hatch> comment the this.<property> using @property <name>
<hatch> just like you would with @method or @attribute
<hatch> (the rest of the words after that was just explaining why I expected it to work) :)
<Makyo> jujugui Can I get one last look at https://codereview.appspot.com/10763045 ? Has two LGTMs, but I'd like a +1 on the tests bac requested.
<hatch> Makyo: looking
<Makyo> hatch, cool, thanks.
<abentley> rick_h_: Is the output of charmworld's "make doc" online anywhere?
<benji> hatch: ah, that clears it up; thanks
<rick_h_> abentley: no, one of those things meant to do. Just does it locally. make doc-open I think will open in a browser
<hatch> Makyo: this diff is wako
<abentley> rick_h_: Okay, thanks.
<Makyo> hatch, blah, did it do that again?
<hatch> I'll just do the tests
<Makyo> hatch,  https://codereview.appspot.com/10763045/diff/27001/test/test_inspector_overview.js is all that was added
 * hatch thinks there are too many people working on the same code, codereview can't keep up ;)
<hatch> Makyo: lgtm'd
<hatch> one q in there
<Makyo> hatch, cheers.
<Makyo> hatch, copied bac on that (restructured my tests to look like his since he landed first), will look into it.
<hatch> teknico: did you ever land that branch was supposed to cache the IO requests for the json charm data? I still see them in the test-debug logs
<hatch> Makyo: alright cool - it's probably not an issue but using real data is always going to be better of course :)
<Makyo> Sure.
<teknico> hatch: I'm not recalling any such branch right now, more context/timing?
<hatch> teknico: umm a couple weeks ago - around when you were doing the test cleanup
<hatch> maybe we talked about it but it was never implemented
<teknico> hatch: yeah, I can't dig up anything of the sort
<hatch> ahh ok then
<benji> I'm looking for one more review of https://codereview.appspot.com/11001043
<Makyo> benji, on it.
<benji> thanks
<gary_poster> Makyo, hatch, do you think we can steal any styling from the inspector of https://dl.dropboxusercontent.com/u/10004366/juju-gui/index.html ?  add a charm and then click on it
<hatch> ^ doesn't work in Chrome
<hatch> heh
<gary_poster> hatch, Makyo sorry, yes known.  Firefox only
<hatch> cool they have icons
<hatch> we need those
<Makyo> For just styling, yeah, probably.
<hatch> yeah was going to say we could take the styles
<hatch> I'm not sure the markup would work with what we want
<hatch> but it could....
<hatch> we actually know what the colour codes are using this ;)
<hatch> darn I was hoping that service icon was an svg already :D
<Makyo> Although that's curious, it looks like both service box SVGs are being used there.
<hatch> holy all of this html is like super semantic
<Makyo> Will clarify with luca before I implement.
<hatch> I don't think I've ever seen code this semantic before
<hatch> usually when I see prototype code (mine included) it's a bunch of divs with tons of classes lol
<hatch> is Ben going to be in today?
<Makyo> jujugui call in 10, kanban now.
<hatch> sometimes javascript irritates me
<hatch> seriously why do I have to do Array.prototype.forEach.call(elements, function() { ...}); when elements is a nodelist
<hatch> that's it! We are switching the GUI to.... to... to...
<hatch> hmmm
<hatch> Flash!
<Makyo> Fiiiiired.
<hatch> rofl
<hatch> so that's where they draw the line eh?
<gary_poster> jujugui call in 4
<gary_poster> kanban now
<gary_poster> oh sorry
<gary_poster> already done :-)
<gary_poster> thanks
<rick_h_> hatch: so why do that over nodelist.each?
<gary_poster> jujugui call now
<gary_poster> ish
<hatch> rick_h_: I'm using raw js
<rick_h_> hatch: but elements is a NodeList? or something else then?
<rick_h_> hatch: nvm, I thuoght you were saying you had a Y.NodeList
<rick_h_> confused me
<hatch> funny enough they are both called NodeList heh
<hatch> so yeah it is confusing
<hatch> bcsaller: so I should have asked if you have actually implemented that cleanup stuff yet
<hatch> I just didn't want to duplicate work
<bcsaller> hatch: makes sense, I have some of it done, I should be wrapping it up this morning, happy to talk about it after the call
<hatch> sure thing
<benji> gary_poster: who would be a good person to do pre-imp call with for "destroy controls to service inspector"
<gary_poster> benji, jeff or ben for tech.  me for goals, but on call for another 10 min.
<benji> gary_poster: cool; let me know when you have a minute
<gary_poster> will do
<hatch> gary_poster: http://jsbin.com/evehit/1/ - (prototype) it only works for the top right now but I don't foresee any issues adding the bottom as well - just scroll up and down in the scrolly box
<gary_poster> hatch, cool.  heading 2 and 3 hide behind upper headers before they stick for me, and heading 4 pushes 1 2 3 and off.  first fixable, second intentional?
<hatch> both fixable
<hatch> and both unintentional :)
<gary_poster> :-)
<hatch> http://jsbin.com/evehit/2/
<hatch> that should fix the second
<hatch> the first will take a little bit more js
<hatch> but regardless - I just wanted to confirm this was the functionality you were looking for
<gary_poster> hatch, cool, yeah that's the right direction.  can we also not obscure the scrollbar?
<hatch> I'm going to go with.....probably
<hatch> :)
<gary_poster> :-) seems important
<hatch> agreed
<hatch> heh ok I'll keep adding the remaining features and fixing the known bugs
<hatch> will report back with a fully functional proto
<hatch> writing raw js is hard
<hatch> I keep writing YUI methods by habit
<hatch> setStyle()
<hatch> heh
 * benji lunches.
<sinzui> abentley, are you deloying/testing mongodb changes to staging?
 * sinzui sees a mongodb database relation error
<abentley> sinzui: No, I'm not doing anything with staging at the moment.  Got failing tests on slow-migrations-2.
<sinzui> abentley, okay. I will kick staging
<gary_poster> benji, whe you are ready for call I am
<gary_poster> n
<gary_poster> sinzui any word from IS on the GUI deployment?
<sinzui> gary_poster, They are one person today and it is unlikely to happen
<sinzui> I reminded then that we want to do regular deployments over the next two weeks culminating with a DNS change for OSCON
<sinzui> I will press this issue again tomorrow morning
<gary_poster> sinzui, ack.  Could you keep me in the emails for that?  also, what's the plan for comingsoon.jujucharms.com--those are part of the planned DNS change?
<sinzui> I expect them to do that with this deploy or inform me that they want to treat it separately
<sinzui> gary_poster, There is no documentation about how to deploy the gui to prodstack. I think this contributes to the delay.
<gary_poster> sinzui, DNS change: cool
<sinzui> I get better service when I can point webops to the OSA doc about the standard practice
<gary_poster> sinzui, docs: dunno.  we got great service from wedgwood before.  Would it be helpful to try and dig up emails from stuff we did at the time?  Alternatively or in addition, can you draft these docs for the GUI charm, or ask us to do so?
<sinzui> wedwood isn't a webops now. Its a new squad. Old emails or the original rt would be grand, Rt would be best since they love rt
<gary_poster> ok lemme see what I can find
 * sinzui ponders writing the OSA draft as a subtle prod.
<benji> gary_poster: guichat is open
<gary_poster> benji https://drive.google.com/a/canonical.com/?tab=co#folders/0B7XG_QBXNwY1dEFVSWh3TWtQOUk
<sinzui> orangesquad: anyone have time to review https://code.launchpad.net/~sinzui/charmworld/sane-categories/+merge/173570
<abentley> sinzui: sure.
<abentley> sinzui: Code looks good.  I don't understand why handling it in "proof" would harm backward compatibility.  Even if it's not an error, it could be a warning.
<sinzui> abentley, I could be
<abentley> sinzui: Either way, if the API wants to guarantee that only official categories pass, it must enforce sanity, because the mongodb document isn't guaranteed to be sane.
<sinzui> abentley, I took the list from the very warning that proof uses
<abentley> sinzui: Oh.  Then I don't understand the comment.
<sinzui> We didn't have final sign-off on categories when proof was changed
<abentley> sinzui: Perhaps you should update the API doc to indicate that specific categories are enforced.
<abentley> sinzui: When you test categories, I think you should test API 2 as well.
<sinzui> abentley, okay
<abentley> sinzui: In fact, I wouldn't expect the old API to be affected by the change.
<sinzui> We never promised that the categories property would be verbatim or contain rubbish
<abentley> sinzui: No, I don't see how your changes could cause the old API to be affected.
<sinzui> abentley, the charm's YAML can contain categories: "misc" but we always represent that as a categories: ["misc"]
<sinzui> I see my change as a true bug fix rather than a change in contract
<abentley> sinzui: I'm not saying your change is wrong, I'm saying I don't think it will have any impact on the old API, because the old API doesn't use the Charm model object.
<sinzui> ah, okay
<abentley> orangesquad: Could you please review https://code.launchpad.net/~abentley/charms/precise/charmworld/slow-migrations/+merge/173580 ?
 * sinzui looks
<abentley> sinzui: btw, tarmac is down and matsubara is looking into it.
<sinzui> abentley, that's fine. I will be doing qa without apache it seems anyway
<sinzui> abentley, Do we dare destroy our apache instance? I have given up trying to access it from the nova level
<abentley> sinzui: I think we dare destroy it.  We will retain control of the external IP address.
<matsubara> abentley, I had to file an RT to get the VM checked. Larry is on holiday today and he usually takes care of that for me
<abentley> matsubara: Ack.
<abentley> sinzui: I will do a manual merge of the charmworld branches, since Tarmac will not be ready for a while.
<sinzui> abentley, ack
<abentley> sinzui: Any thoughts on https://code.launchpad.net/~abentley/charms/precise/charmworld/slow-migrations/+merge/17358 ?
<abentley> sinzui: nm
<gary_poster> sinzui, will you have a chance for a 15 min call in the next 45 minutes or so?
<sinzui> I can talk now if you like
<gary_poster> cool sinzui thanks.  guichat is free
<hatch> arg this header thing is so frustrating
<gary_poster> hatch, if it takes too much time we can (A) toss it to ant and see what he can give us and/or (B) push back on UX and request a cheaper initial approach
<gary_poster> I wish I liked the look of the scroll bar more in the FF demo :-/
<hatch> bcsaller: will review
<bcsaller> hatch: thanks, I expect there will be some questions, if you want to talk about anything lemme know
<hatch> bcsaller: O KAY
<hatch> I almost have this rediculous scrolling behavior cased
<hatch> lol
 * hatch actually thinks it's pretty cool
<hatch> http://jsbin.com/evehit/4/
<hatch> header 3 and 4 'trigger' at the wrong spot however
<gary_poster> hatch, cool :-)
<hatch> yeah 1 and 2 work really well
<hatch> for some reason the height calculation is off on 3 and 4
<hatch> bzr sure put some odd diff splits in here heh
<hatch> bcsaller: I see you moved the databinding into the view container - I remember we explicitly did not want to do that
<hatch> are you saying now that, for all intensive purposes, required of one another?
<bcsaller> vc state is needed to trigger some operations at the right time. We don't currently have any use-case for viewlets w/o databinding either 
<hatch> alright that's fine - I just wanted to make sure that decision was intentional
<hatch> that databinding is one complex beast :)
<bcsaller> its getting more complex, yes :(
<hatch> bcsaller: review done - mostly trivial but a few larger requests
<bcsaller> hatch: thanks, reading now
<hatch> header calculations solved
<hatch> bcsaller: it's my EOD so I'm stepping out for a bit but I should be back in about 15-20 if you have any q's or would like to chat about my comments
<bcsaller> hatch: I should have the reply + changes done in that timeframe
<huwshimi> Morning
<hatch> bcsaller: the reply looks good - I'm going to go through it again then QA after supper then I"ll LGTM it
<bcsaller> hatch: cool, thanks
<hatch> afterwards I'll merge it into my branch so that I can start on that in the AM
<hatch> I could also LGTM it now if you think you can get another review tonight :)
<bcsaller> I don't think anyone that can do it is still around
<hatch> alright np :) after supper it is
<hatch> talk to you in the am
#juju-gui 2013-07-09
<abentley> sinzui: How's it coming with staging?
<sinzui> abentley, ghastly
<abentley> sinzui: Anything I can do to help?
<sinzui> abentley, Two efforts to create apache have failed
<abentley> sinzui: Yikes.
<sinzui> abentley, Both deploys never got an IP, the agent state is pending
<abentley> sinzui: Is it the IP address shortage?  That would cause machines to fail to spin up at the nova level.
<sinzui> abentley, and somehow I lost my branch that sanitises categories
<sinzui> abentley, I have been using w3m and can confirm charmworld + mongodb + elasticsearch are happy
<rick_h> sinzui: one trick there is to expose the charmworld app and it'll be present on the port 6543 I think? or 2464, whatever we default to now. 
<abentley> sinzui: Well, we could tranfer the external IP address to the charmworld app server if necessary.
<sinzui> abentley, as rick_h wrote, the port will be 6543
<sinzui> abentley, Note I still see 645b2404-9179-4a8b-8136-7f238964aa6b | juju staging instance 4
<sinzui> ^ that is the zombie Juju thinks it destroyed
 * sinzui ponders nova as a means to decommission the instance
<abentley> sinzui: You used terminate-machine?  I am not sure whether it is reliable.
<abentley> sinzui: The problem with terminating via nova is that the IP address famine means someone could take the address of that machine and we'd be unable to start a replacement.
<sinzui> abentley, right
<abentley> sinzui: Perhaps we should move staging to lcy01, but we'll need a new external IP address, so we'll need to re-map DNS.
<sinzui> While I can use nova to suspend/resume, I cannot so anything that permits us to gain access to what runs in the vm. 
<abentley> sinzui: Rebooting doesn't help?
<sinzui> abentley, we cannot ssh into it
<abentley> sinzui: We cannot ssh into it in order to reboot it, or we cannot ssh into it after we reboot?
<sinzui> before
<sinzui> I could not ssh into it to see what was up and fallback to reboot
<sinzui> I didn't see an alternate means to get into the instance using nova
<abentley> sinzui: There is a "nova reboot" command.
<sinzui> Didn't do anything for me yesterday.
<abentley> sinzui: what about get-vnc-console?
<sinzui> I don't know about that
<sinzui> oh.
 * sinzui checks backscroll
<sinzui> abentley, we might have a chance now
<sinzui> reboot failed yesterday (while the instance was running), I destroyed two services since then and the reboot says I have an agent
<abentley> sinzui: woot!
<sinzui> We are now waiting for the third replacement apache to start and join charmworld
<hatch> morning
<rick_h> party on hatch 
<hatch> looks like haswells are starting to make it into the lenovo's http://www.engadget.com/2013/07/09/lenovos-t440s-thinkpad-coming-soon/
<abentley> sinzui: The options migration failed deployment.  I've rolled back to r298.  Should be simple to fix, so I won'd do a rollback.
<hatch> it will probably still only have an HDMI out making it useless for me heh
<abentley> sinzui: i.e. I won't land a revert for now.
<sinzui> abentley, understood
<rick_h> luca: gary_poster has there been talk about any limitations to the autocomplete results? For example, only reviewed charms?
<jcsackett> sinzui: chat?
<sinzui> yes
<jcsackett> sending invite.
<luca> rick_h: not along those lines, gary_poster might have a plan but I'm not sure
<hatch> rick_h: luca he is away today
<luca> rick_h: hatch want to talk it through in about 10 mins?
<hatch> well isn't it trivial to add filters to the ac results?
<rick_h> luca: that's ok. I just wanted to double check as the approach is a bit different each way. 
<rick_h> hatch: well, basically it comes down to using a full model and token widgets to display the completion suggestions vs not. 
<hatch> ohh - ok well I would say use the token widget and then if we need to use ones with less information we can handle that in the GUI
<rick_h> hatch: right, there's a bunch of logic on which icon to display, the reviewed badge, etc that would need to be duped and I'm trying to think through a DRY around all that. 
<rick_h> hatch: but, if we're only completing reviewed charm none of that logic matters so figured I'd ask :)
<hatch> what makes a charm 'reviewed'
<hatch> how long do they sit unreviewed?
<rick_h> hatch: they're reviewed by a couple of the ~charmers team and most will probably never be reviewed. 
<hatch> never be reviewed?
<rick_h> hatch: yea, if you fork the mysql charm and upload it to use it, it'll never really be reviewed as there's an official reviewed mysql charm out there. 
<hatch> ohh hmm
<hatch> so the AC will only show 'approved' charms but the full search results will show all of them?
<rick_h> hatch: yea, that's kind of the question. A/C is a method to shortcut to a selected charm. 
<rick_h> luca: hatch yea, let's chat if that's ok. I'd like to talk it out. 
<hatch> haha ok give me a few minutes
<hatch> rick_h: luca in guichat
<Makyo> luca, I've got a question when you have a moment.
<luca> hatch: rick_h do we need to talk about search? I'll have a prototype to show you in roughly 5 mins?
<hatch> sure pop in real quick
<rick_h> abentley: got a sec to chat?
<abentley> rick_h: Okay.
<rick_h> luca: can you join in this call real quick? https://plus.google.com/hangouts/_/8e337c1da033485408fb4e6723267db4247e4f42?hl=en
<luca> rick_h: sure
<Makyo> jujugui, Can I add libpeerconnection.log to .bzrignore?  It seems to be an empty file generated on test-server.
<bac> SGTM
<rick_h> sinzui: can you join the hangout ^^ please? Have a sec that is?
<teknico> Makyo: ok to me
<hatch> Makyo: let er rip
<Makyo> Thanks.  Will be in review in a mo'.,
<jcastro> augh, everytime I have to go to old jujucharms.com do to something I get disgusted.
<jcastro> new GUI is sooooo nice
 * hatch is glad that was before his time
<hatch> ;)
<abentley> orangesquad: Could you please review https://code.launchpad.net/~abentley/charmworld/config-storage-2/+merge/173757 >
<sinzui> I can
<sinzui> abentley, r-me
<sinzui> r=me
<rick_h> Makyo: looking at your branch. Are you only dealing with the icon if it's got one and not going to display the fallbacks then?
<Makyo> rick_h, for this branch, yes.  I need to get on to a first pass at updating the service block SVGs today.
<rick_h> Makyo: ok. 
<Makyo> luca, need to ask you about those when you have a chance.
<rick_h> Makyo: if you get to the fallbacks let me know. I'm finding that maybe that work should be abstracted out of the template file in charm-token.handlebars and more into a model or helper somewhere. 
<Makyo> rick_h, alright.  I didn't dig too much into that, but I will.
<rick_h> Makyo: yea, it's not in an easy place for you to reuse like this atm. 
<luca> Makyo: I'm free now if you are
<Makyo> luca, the email you sent had the black squircles with the connectors slightly extended.  however, in the UX/styling demo, it's that black outline surrounding the original service block. Which direction should I head in?
<abentley> sinzui: did you set the revno to 300?
<sinzui> abentley, I did not
<abentley> sinzui: Hmm.  Maybe tarmac's back, then.
<rick_h> abentley: yea, I assumed it came back up when I got the 'jenkins is back to normal' email
<luca> Makyo: the normal state should be this: https://docs.google.com/a/canonical.com/file/d/0B7XG_QBXNwY1QkNacGhCX0hXNW8/edit?usp=sharing
<luca> Makyo: clicked/hover state: https://docs.google.com/a/canonical.com/file/d/0B7XG_QBXNwY1eUIzbFNjZjdyMEU/edit?usp=sharing
<Makyo> luca, alright. Was just curious after seeing https://dl.dropboxusercontent.com/u/10004366/juju-gui/index.html
<luca> Makyo: When it's just been added to the canvas it should show the charm icon instead of the health circle
<Makyo> luca, the charm icon branch is in review right now.
<luca> Makyo: yeah, Ant hasn't implemented the block stuff yet
<luca> Makyo: nice :)
<abentley> rick_h: Oh.  I don't get those.
<Makyo> luca, alright, cool.  Will aim to have that for today.
<luca> Makyo: nice, thanks
<abentley> sinzui: second time's the charm with prepare-upgrade.
<Makyo> jujugui call in 8
<Makyo> Kanban now.
<hatch> what he said!
<luca> sinzui: who do I talk to about "Useful links"?
<hatch> google
<hatch> *snicker*
<Makyo> Brat :)
<luca> rofl
<sinzui> luca, me I think.
<luca> sinzui: ah, well, they are being moved to a section in the summary tab
<luca> sinzui: the designs will be finished tomorrow
<sinzui> understood luca
<luca> sinzui: cool, thanks :)
<sinzui> luca, jcastro, jcsackett. I just tested what users see when sharing a juju-gui URL using G+ itself. It was a private post with you so that we can see what the experience is like.
<hatch> jujugui guichat now
<jcastro> sinzui: oh yeah, there's some metadata G+ expects
<jcastro> we should make it so the charm's icon is automatically in there
<jcastro> I was just looking this up the other day, investigating
<sinzui> +1
<jcastro> sinzui: here it is
<jcastro> https://support.google.com/webmasters/answer/176035?hl=en
<jcastro> http://schema.org/docs/gs.html#microdata_how
<jcastro> https://www.google.com/webmasters/tools/richsnippets
<luca> sinzui: can we discuss sharing?
<teknico> Makyo: one thing I noticed is that the install hook does not install the python-cheetah package, which it indirectly uses
<Makyo> teknico, hmm.  Okay, will poke around there.
<teknico> Makyo: thanks
<Makyo> teknico, what I'm seeing from the GUI is it's not passing the cs: schema when it tries to deploy, so I get juju.charm.errors.CharmURLError: Bad charm URL u\'~marcoceppi/precise/discourse-18\': a URL with a user must specify a schema\n
<rick_h> Makyo: that might need tweaking when converting from BrowserCharm to Charm models during deploy
<rick_h> Makyo: that cs: url is in the BrowserCharm.code_source object I believe. 
<Makyo> rick_h, ah, alright.  I'll poke around the deploy stuff where it does that conversion.
<rick_h> Makyo: sorry, BrowserCharm.url is where it's at
<rick_h> that's the cs: url 
<rick_h> http://manage.jujucharms.com/api/2/charm/precise/apache2-2 shows an example json dump that turns into the model Makyo 
<Makyo> \o/ thanks
<Makyo> rick_h, teknico, in app/views/charm-panel.js line 873, the deployer is only getting the id attribute; is that where it would need the URL?
<Makyo> Deployer's the wrong word.  The deploy function that's passed to the browser.
<rick_h> Makyo: so yea, that charm model should have a url attribute. I'm not sure what you're doing the cs: stuff for so can't say what's up with _setPanel()
<teknico> Makyo: no, if the passed-in function is the one at line 760, it only needs the charm id
<luca> jcastro: sinzui rick_h who do I need to talk to about sharing?
<sinzui> I am one of them
<jcastro> luca: I am also one
<luca> jcastro: 
<jcastro> I did the little text for the twitter section
<luca> jcastro: wrong person
<luca> jcastro: oops
<luca> sinzui: lets talk quickly on a hangout?
<luca> jcastro: ^
<sinzui> okay
<Makyo> teknico, ah, okay.  Either way, it looks like the id is ~marcoceppi/precise/discourse, and it should have a schema on the beginning when it actually deploys.
<teknico> Makyo: right
<rick_h> Makyo: right, but we don't consider the schema part of the id in the model and the api. 
<rick_h> Makyo: so the id will never have that, it's the url 
<Makyo> rick_h, Yeah, so we should be able to just change that, I think.  Which is maaaaybe line 605?
<Makyo> var url = charm.get('id');
<luca> sinzui: https://plus.google.com/hangouts/_/2302ec8be280f94a7841473e1dbbc7e8e43cb204?authuser=1&hl=en
<luca> jcastro: https://plus.google.com/hangouts/_/2302ec8be280f94a7841473e1dbbc7e8e43cb204?authuser=1&hl=en
<rick_h> Makyo: looks ok from there, but not familiar enough to say 'go for it'
<jcastro> luca: I am EODing in a minute, only working a half day today and I have a charm championship page to do still
<jcastro> luca: whatever you guys decide just lmk
<teknico> uhm, how do we get the schema in there? I cannot see it
<Makyo> teknico, just change it to var url = charm.get('url'), looks like.
<Makyo> I set a breakpoint there and checked charm.getAttrs()
<teknico> oh, good to know, thanks
<rick_h> Makyo: teknico right, the url is the url not the id now. Should be good to pull from the model url. 
<teknico> Makyo: I wonder why it is only a problem with this specific charm, though
<rick_h> teknico: no, I think it's a change in the old charm model data vs the new. 
<Makyo> teknico, I'm thinking it's a problem with all user charms due to the change.
<rick_h> Makyo: the one thing I worry about is if an old instance can get in here, but since it's in deploy side I don't think it can
<teknico> Makyo: oh, ok then
<Makyo> rick_h, yeah.  I think the only way would be if they were to deploy from the old panel, which is now mutually exclusive from the browser.
<rick_h> Makyo: right, so I'm pretty sure you're safe with your one-liner change. 
<rick_h> Makyo: but want to make sure it's clear what the diff is and how it might cascade around a little bit
<Makyo> rick_h, Yeah.  I think it'd be good to go through a bunch of different types of charms and ways of deploying (DnD and add button) to make sure we're always getting the same sort of info.
<rick_h> Makyo: yea, anything that goes through the Browser code will be an instance of BrowserCharm cast into a Charm and that's what's in here. 
<rick_h> and the api promises that the url will be there. 
<Makyo> Cool, that should help, yeah.
<bcsaller> bac: I made review changes and reproposed if you have time to look that branch over again: https://codereview.appspot.com/11013043/
<bcsaller> hatch: you might want to look at the method renamings in that branch and see if you're still happy with them
<hatch> yup reading it now
<hatch> well reading the replies
<hatch> I have come to love rebind :)
<hatch> what's POJO?
<teknico> Makyo: great, thanks a lot for the help!
<Makyo> teknico, cheers
<hatch> bcsaller: I can't deploy a service and then view it using the new service inspector
<bcsaller> hatch: Plain Old Java(Script) Objects, comes from java but means plain Object derivatives 
<hatch> ohh
<hatch> DD ceph, click deploy, click it to view inspector...console error
<bcsaller> so something without the .get method in the case referenced
<bcsaller> hmm
<hatch> it was a fresh checkout/make of your branch
<hatch> Uncaught TypeError: Object [object Array] has no method 'toArray' service.js:1210
<teknico> and that charm is also tasteless, that is, it's testless ;-) and written in bash :-P
<bcsaller> hatch: able to reproduce locally, looking into it
<bcsaller> there is another error past that one
<sinzui> rick_h, jcsackett: Did this icon come from the old api (the <charm>/json url) or the new api http://uistage.jujucharms.com:8086/~nextrevision/precise/openvpn-3/
<rick_h> sinzui: the icons comes because it has a category of 'application' which is invalid. It needs to be applications (s)
<rick_h> sinzui: so the icon comes because of a broken sprite
<sinzui> rick_h, I know that...
<hatch> bcsaller: alrighty
<jcsackett> sinzui: i'm with rick_h, i don't think i understand what you're asking.
<rick_h> sinzui: ok, so everything on this page is from the new api
<rick_h> sinzui: I'm not 100% following the question I guess. 
<sinzui> rick_h, Did it get the category from api 2 or /json
<rick_h> sinzui: api2
<sinzui> rock. This is fixed on staging
 * sinzui is still scouring the network requests to convince himself the /json url was not called
<rick_h> sinzui: ah, yea. Use chrome, load the page with the network tab open, then click the 'xhr' button on the bottom of the tools
<sinzui> thank you for reminding me about the filter. I am incompetent rick_h
<bcsaller> hatch: ahh, shallow, the changes around model handling didn't propagate through the modellist handler properly, it was calling selectBindModel on its own product
<rick_h> sinzui: cool, darn handy tool in our network waterfall for sure. 
<hatch> bcsaller: ahhh
<bcsaller> hatch: I'm now able to create the error we talked about before where an old inspector (two services on canvas, switch to second) is still running in the background. Not related to this branch, but an issue
<hatch> crud I thought your branch would solve that
<hatch> arg
<hatch> *I hoped*
<hatch> I just got rank burnt by order of operations
 * hatch goes to grab the aloe and a grade 4 text book
<bcsaller> hatch: I think I see the fix though, its just not calling the right things in the inspector singleton mgmt code
<bcsaller> trying a fix now
<hatch> cool thanks
<luca> hatch: Makyo who do we need to talk about relations and building them?
<Makyo> luca, Sure.  At this point, I think we'll be able to implement most things reasonably quickly, just need a direction to head in.
<hatch> luca: I hear there are a lot of good dating sites in London
<Makyo> :P
<hatch> haha ok sorry
<hatch> yeah I am pretty confident the code is all there it's just the interaction we want to narrow down
<hatch> narrow/peg down
<hatch> right now the 'long click' isn't discoverable
<hatch> thenagain, neither was the menu
<luca> Makyo: we will join guichat in 2 mins :)
<Makyo> luca, alright
<hatch> can I join in on this too?
<Makyo> Sure
<hatch> cool
<hatch> http://jsbin.com/evehit/6
<hatch> pretty cool :)
<hatch> it looks/feels the best in firefox
<hatch> that's just because it has easing on it's scrolling
<Makyo> hatch, we're starting.
<hatch> sorry guichat was having issue connecting
<bcsaller> hatch: I pushed fixes to the outstanding issues, it properly unbind now
<hatch> awesome!
<hatch> thanks
 * Makyo runs out to pick up dogs.
<hatch> jcsackett: I saw your reply on the bug - are you in Chrome as well?
<rick_h> hatch: what version of chrome are you running? Maybe a version thing?
<hatch> OSX - 27.0
<rick_h> hatch: k, 29 here so shouldn't be a version issue then
<hatch> odd my Ubuntu Chrome is 28
<hatch> are you running the beta channel?
<rick_h> dev channel 
<hatch> ahh gotcha
<hatch> so many chrome versions haha
<rick_h> should only be 3 :)
<rick_h> stable, beta, dev
<hatch> yeah then for each OS
<hatch> haha
<rick_h> but they're released together
<hatch> who knows, maybe my osx hasn't made the rounds yet
<rick_h> 27 would be stabel, 28 beta, 29 dev
<hatch> yeah my Ubuntu is on stable I thought
<hatch> who knows
<rick_h> I'd guess not
<hatch> bcsaller: QA'ing again
<hatch> bcsaller: heh you're gona be maaaaad at me
<hatch> I found another bugt
<bcsaller> doh
<hatch> hmm can't repro now...
<hatch> possible cache issue
<hatch> ok nope there it is
<hatch> DD ceph, deploy, inspector, click <- S, E, D, Units
<hatch> then the toArray error shows in the console
<hatch> I think the error occurs when  a change comes in on the delta
<hatch> it's very odd I can't seem to repro all the time
<hatch> ahh if you follow those steps
<hatch> then just let it sit
<hatch> it'll eventually error
<bcsaller> hatch: I'd seen something like that as well, thought it was fixed, but looking into it now
<hatch> great
<bcsaller> I see the real issue
<benji> hatch: are you available for a short chat about transitions in a couple of minutes
<hatch> i am
<hatch> ^ benonsoftware
<hatch> benji:
<hatch> damn autocomplete
<hatch> benji: whenever you're ready
<benji> hatch: hatch I'm in guichat
<bcsaller> hatch: the model list handler was way too aggressive, I'm surprised we didn't see that issue sooner, tough it would have been hard to spot. It was calling render/update on way too many things including non-model list viewlets
<bcsaller> hatch: pushed the revision
<hatch> ohh heh so this code is way better now then
<hatch> haha
<bcsaller> hatch: there is still an issue in the updates, but yes as so as I have it properly resolved it will be 
<hatch> ahh ok
<hatch> (sorry was on call with benji)
<bcsaller> hatch: a fix is pushed if you can verify it as well when you have time
<bcsaller> seems to be working fine here
<hatch> ok will pull down
<hatch> bcsaller: looks good
<hatch> propose?
<bcsaller> hatch: I'll push it up again, just takes so long :(
<hatch> ohhh I know
<hatch> it would be cool if we could have some super powerful box sitting around we could get to pull down the branch and build
<hatch> I have a spare server that's probably faster but not by enough that it would make a difference having to 'build' to run the tests
<bcsaller> hatch: proposed again, quite a lot of fixes on that branch now
<hatch> haha yeah...
<hatch> bcsaller: do you think there should be tests for the edge cases which you just solved?
<bcsaller> hatch: ideally yes :-/
<hatch> you just want to land this branch don't you?
<hatch> ;)
<hatch> tbh I'd like to see this land so I can get on wit my branch
<hatch> followup with tests?
<abentley> orangesquad: Could you please review https://code.launchpad.net/~abentley/charmworld/autocomplete/+merge/173799 ?
<bcsaller> hatch: I'll make a carc
<bcsaller> hatch: I'll make a card
 * sinzui looks
<hatch> bcsaller: lgtm'd
<bcsaller> jujugui: one more +1 needed for https://codereview.appspot.com/11013043/
<benji> bcsaller: looking
<bcsaller> thanks
<hatch> careful....there be dragons
<hatch> now I fully expect my branch to explode after merging it in :)
<sinzui> abentley, what do you think will happen if the autocomplete query is for 'fo%20'. I think this becomes 'fo ' and it doesn't match anything and it doesn't break anything.
<sinzui> but maybe some smart function strips the trailing space
<abentley> sinzui: My guess is that it would match any charms whose names began with 'fo ', but we don't have any.
<sinzui> I think the gui needs to be certain to strip whitespace. A leading space will be confusing
<hatch> it would be cool if you could do a forEach on an array in reverse
<hatch> (without tricks)
<sinzui> abentley, r=me
<abentley> sinzui: Thanks.
<sinzui> abentley, This is my thoughts about the svg problem: http://pastebin.ubuntu.com/5859420/
<abentley> sinzui: I find the notion of a 96x96 vector graphic confusing.  Don't they just need to be square?
<sinzui> abentley, Yes in the big picture. The template svg specifies the default rendering is 96x96
<sinzui> we can detect if the default template was not used. I don't want to enforce the template
<sinzui> abentley, svgs DO have width and height attributes and even if the template is not used, detecting unsupported dimensions is trivial
<abentley> sinzui: Ok.
<sinzui> abentley, Do we care about file size? DoSing the gui is bad. Well, I think we know something about this because the wikimedia icon contains a fat png
<abentley> sinzui: I was going to just use python-magic and reject anything that wasn't svg.  Going so far as to validate images doesn't seem like it should be our problem.  Maybe proof should do that?
<sinzui> abentley, I think proof should do that. proof is run after we build the CharmFileSet
<sinzui> We can call magic as we build the set
<abentley> sinzui: As an advocate for the backend, my only concern about file size would be on the ingest side.  On output, we have solid caching.
<abentley> sinzui: In terms of the GUI, it shouldn't be an issue, because only promulgated charms are going to show their icons.
<sinzui> abentley, apache2 and wikimedia are both promulgated.
<sinzui> one has a png and the other has an embedded png
<sinzui> abentley, we wouldn't be treating this issue as a bug of the mistakes in the icons were fixed in April when we discovered the problem
<abentley> sinzui: Right, but the maintainers aren't malicious.  I assume the svg-with-embedded-PNG is a legitimate wikipedia logo that just happens to be big.  It's not a DoS, though, and is only going to affect those who encounter that charm.
<abentley> sinzui: If you want to cap file size, it's fine by me.
<sinzui> abentley, I think you prefer that we do the minimum to ingest to deal with this issue (use magic to reject liars). Update proof to demand the issue be fixed
<sinzui> I can update proof. I have other fixes I want to add to it
<abentley> sinzui: I think that's accurate.
 * sinzui ponders how proof could be taught to report that the maintainer is wrong because the branch owner is different
<sinzui> well that is not a good idea
<sinzui> Teams will often own charms, but they will rarely have email addresses
<abentley> sinzui: I don't think proof can know what the branch owner will be.
<abentley> sinzui: Unless we tell it, I suppose.
<sinzui> I really want to set my own juju agenda. The package-origin and maintainer-owner problems lead to confusion and are vulnerabilities that no one is talking about
<abentley> sinzui: Maybe we should overwrite maintainer with branch owner at ingest time?
<abentley> sinzui: I don't see a lot of value in having them vary.
<sinzui> That hides errors. But we could record that we know there is something wrong. Write now, we know it because we few can see the problem
<sinzui> right now ^
<abentley> sinzui: I go back and forth on whether the maintainer field has any value.  The fact that it's so often wrong suggests it's not important.
<sinzui> abentley, rick_h brought up the author/owner issue in regards to the charm token today. User do need to see both, and they need to know that something is wrong when they differ
<sinzui> abentley, juju certainly doesn't require it.
<abentley> sinzui: Author is a third thing.  That's something you get from bzr metadata :-)
<sinzui> The field is flawed since teams can own branched, but not have email addresses
<sinzui> indeed
<sinzui> abentley, I think the charm/branch owner is who juju and the community cares about. The maintainer field is a means for a the owner to provide the preferred contact address. This too is unneeded if juju and juju-gui could point to Lp about how to contact or contribute
<abentley> sinzui: Makes sense.
<abentley> rick_h: autocomplete is implemented on staging.
<abentley> sinzui: I am ready for new work and assume it should be versions.  Chat?
<sinzui> abentley, yes and yes
<bcsaller> hatch: that should be landed and ready for you to merge
<hatch> bcsaller: thanks yas
<hatch> bcsaller: Makyo I think you can drag your branches into the done column :)
<Makyo> hatch, yep, thnks
<hatch> Makyo: you aren't going to make us QA this SVG code are you? ;_
<hatch> ;)
<Makyo> hatch, I totally am.  Lucky for you, all it requires is for you to deploy a service.
<hatch> *phew*
<Makyo> Well, preferably two services, and create a relation.
<hatch> welllll O K
<hatch> :)
<hatch> reviewing
<hatch> Makyo: rgb color?
<Makyo> hatch, yanked from the demo.
<hatch> I don't care either way, we should probably stick with one or the other :)
<Makyo> hatch, I can see about converting, though.
<Makyo> hatch, yeah.
<hatch> colorpicker.com
<hatch> is what I use :)
<Makyo> Thanks.
<hatch> rgb(a) kind of makes more sense for our support matrix buuuuuuuut whichever :)
<Makyo> Yeah
<hatch> I care so litle about it I'm not even going to comment on the review :D
<hatch> twice today I've run 'make' in the root dir and wondered why there were no 'make targets'
<hatch> today is just not a good day for me
<hatch> heh
<hatch> Makyo: hmm....I kind of like the icon in there instead of the little circle :)
<hatch> although the functionality of it would be way less heh
<Makyo> I think that's the direction we're heading eventually.
<hatch> lgtm'd with a super trivial comment
<bcsaller> Makyo: is there a reason to not use the icon post ghosting? was that talked about or just an artifact or wires possibly not being updated?
<hatch> I dont' think it SHOULD be there because then the status indicators are gone
<hatch> and tha'ts the most important part :)
<bcsaller> 'it' being the icon?
<hatch> yeaaah
<hatch> hmm my a key is sticking
<bcsaller> I thought it was icon and centered under that the status color bar, but I've seen so many wires I can't keep it straight 
<hatch> ohh...hmm I didn't that one existed
<hatch> lol I'm in the same boat I guess haha
<hatch> jcastro: what is an 'Ubuntu Member' ? Could I be one and not know it?
<Makyo> We don't have any designs for that either way, bcsaller hatch.  I just have the two cards and don't want to put too much effort into trying to outguess london :)
<hatch> probably a good idea ;)
<hatch> I definitely don't have a good track record of anticipating their next move lol
<bcsaller> never try to outguess London ;)
<hatch> the new twitter app for android has a different font
<Makyo> Haha
<Makyo> Better, hatch?
<hatch> what's better?
<hatch> my coffee is still empty
<Makyo> Twitter font.
<hatch> ohh
<hatch> was gona say, if you were filling my coffee...then no
<Makyo> I only use it occasionally, but I like seeing what they do with design.
<hatch> wrt the twitter font - then yes :D
<Makyo> hatch, Gladly., as long as espresso's good
<hatch> sure - I usually just drink 'normal' which I think is called an americano
<hatch> because I'm sure a watered down espresso is the same as drip :)
<Makyo> Bah.  I think they taste totally different.
<Makyo> read: I totally like Americanos better.
<hatch> I'm not much of a connoisseur I guess
<rick_h> abentley: thanks!
<hatch> I just take whatever the drip is....black
<Makyo> Reflux made me appreciate tasty coffee that doesn't make me sick all that much more.  Espresso machine seems to be the best bet.
<Makyo> And tastiest.
<Makyo> Never got into cold-brew.
<rick_h> moka pot ftw is my new thing
<rick_h> that and a nespresso frother. best camping trip evar!
<hatch> frothed milk makes me kind want to hurl
<Makyo> I looove the coffee from those things, rick_h, but still a little too much for my stomach in the morning.
<rick_h> it doesn't froth soy very well, more that it warms it up to coffee temp so that it's not cold milk into hot coffee
<Makyo> Good post-breakfast coffee, though.
<rick_h> Makyo: yea, I've never been a home-coffee person but some vanilla soy into my moka pot brew has me saving the starbucks $$
<rick_h> and a LOT less than an espresso machine 
<bcsaller> ugh, you're all making me want more Espresso, back to the kitchen with me
<Makyo> rick_h, Definitely!  I'm more almond milk, myself, but yeah :)
<Makyo> \o/
<rick_h> Makyo: I want to try some of that next. I wish they had smaller containers at the store :/
<Makyo> rick_h, Yeah, half-gallons are all I can find.  Makes good white russians, though, so we tend to go through it quickly enough.
<rick_h> hah!
<rick_h> lovely, chrome won't open on the laptop :(
<hatch> uh oh
<rick_h> looks like it might be the new hangouts app installed on there. I'll have to look up how to start sans-apps/extensions and try to remove it
<hatch> time to format, install Windows
 * hatch runs
<hatch> hehe
<rick_h> heh, or use Firefox...ahhhhh!
<hatch> haha - I have noticed that FF is actually a rather enjoyable browsing experience
<hatch> chrome is still faster
<hatch> but ff is 'smoother' heh
<rick_h> hmmm, fails in incognito mode too :(
<hatch> uh oh
<rick_h> dev tools for me
<rick_h> chrome dev tools ftw
<hatch> delete and reinstall?
<hatch> oh yeah it's devtools are superior for suuure
<rick_h> ok, so starting with a fresh profile works so yea. Just time to reset it up and try to clear what's in it I guess. 
<huwshimi> Morning
<hatch> mornin huwshimi
<hatch> I'm so close to getting this sticky header thing done I don't think I'll quit until it's working
<huwshimi> hatch: Did you look how Ant did it in the prototype?
<hatch> and did it in the prototype already?
<hatch> lol damn
<hatch> have a link?
<hatch> huwshimi: I'm asking because the dropbox one doesn't implement this scrolling
<huwshimi> hatch: It might not happen in the inspector but does in the sidebar browser
<huwshimi> That's if you have the right link
<hatch> pass the link you mean plz
<hatch> :)
<huwshimi> just finding it
<hatch> https://dl.dropboxusercontent.com/u/10004366/juju-gui/index.html#
<hatch> is the one I have
<huwshimi> hatch: Yeah, that's the one
<hatch> ok then no different scrolling :)
<hatch> huwshimi: http://jsbin.com/evehit/7 the bottom stickyness requires overscolling (my calculations are wrong)
<hatch> but scroll up and down to see how it works :)
<huwshimi> hatch: Are you not trying to make the current heder on the inspector stick to the top as you scroll the inspector content down?
<huwshimi> hatch: Oh, you're trying to make them all stick. Are you sure that's correct?
<hatch> it better be
<hatch> lol
<hatch> but yeah that's what Gary said at least
<hatch> imho I think this is awesome
<huwshimi> hatch: It's just different to how the sticky headers work in the sidebar
<huwshimi> I can't tell from these mockups how that's supposed to work...
<hatch> ohh right yeah
<hatch> I'm pretty sure that's intentional
<hatch> my guess is that at some point they will want a 'click to scroll' functionality
<hatch> so you can click to scroll to the heading
<hatch> all I know.....you have to refresh jsbin every once and a while else it lags
<hatch> heh
<huwshimi> hatch: If you have the time you could add an option to make all the headers sticky or just one. Otherwise I can do it once your code lands so I can re-use it for the browser and charm details page.
<hatch> so once the second header gets to the top it would push the first one away?
<huwshimi> hatch: Yep
<hatch> that coudl be an option probably
<hatch> this is all raw js too so it'll be portable :)
<hatch> well for modern browsers
<hatch> old browsers can just deal with normal scrolling...
<hatch> huwshimi: http://jsbin.com/evehit/8/ done :)
<huwshimi> hatch: Nice work
<hatch> well
<hatch> done my requirement
<hatch> yours might take a bit of work yet
<hatch> thanks :)
<hatch> man that was a friggen pita
<hatch> huwshimi: ok so a single sticker header is probably going to be super easy
<huwshimi> hatch: Yay!
<hatch> I'm not sure it should be the same code though
<hatch> it would probably be a more basic implementation
<hatch> how soon does that need to be done?
<hatch> I'd like to get some other stuff landed first :)
<huwshimi> hatch: Well I would like to try and get something landed for the upcoming deadline, but if it's entirely different code I can write something myself if need be...
<hatch> well that's probably a little unncessary
<hatch> you 'could' even throw in a position sticky polyfil and be done
<hatch> uggggh conflicts
<hatch> sometimes bzr is so smart....othertimes....heh daymn
 * hatch spoiled by source control
#juju-gui 2013-07-10
<hatch> bcsaller: are you around still? I'm wondering how I get a configuration file to test the config file import of the inspector?
<bcsaller> hatch: you mean an export?
<hatch> well just a charm config export
<hatch> not an env export
<bcsaller> oh, config
<bcsaller> hatch: it would be a yaml file with the name of the service and then under that key/value pairs for the various values IIRC
<hatch> bcsaller: ahah I found the test
<hatch> sorry I read this a few times before asking I swear :)
<hatch> it's yaml with key/value pairs, doesn't look like it requires the service name
<hatch> at least as per the old test
<hatch>     var config_raw = 'tuning-level: \n expert';
<luca> anyone available help me branch something?
<rick_h> luca: branch something? 
<bac> hi luca.  did you get help?
<gary_poster> rick_h, hey. any chance you could expedite huw's branch?
<gary_poster> I'm happy to help, or arrange for help :-)
<gary_poster> rick_h, I mean expedite the review and landing
<rick_h> gary_poster: sure thing. I know luca was looking at it this morning. I'll jump on it now. 
<gary_poster> thank you rick_h 
<gary_poster> nice icon-in-the-ghost change Makyo :-)
<luca> bad	yes I did, thanks :)
<luca> gary_poster: rick_h theres a weird bug on hue's branch that when you open charm details, click configuration and then click a different charm token to open the charm details then it opens on configuration and not the summary tab
<luca> gary_poster is that a bug for Huw? or should I only be looking at styling?
<gary_poster> luca, if you can't dupe on uistage then it is a bug in Huw's branch.  We can address it today, rather than waiting for him.
<luca> gary_poster: I see
<luca> gary_poster: I'll test it
<gary_poster> luca, and whether or not it is in Huw's branch, we should fix it, of course :-)
<luca> gary_poster: it happens on uistage
<luca> gary_poster: I shall submit a bug
<gary_poster> luca ok cool.  perfect, thank you.  rick_h that means we don't need to treat that as a blocker for huw's branch, but it would be good to address today. 
<gary_poster> luca, would you like to talk about seeing if ant can add on a branch (or patch/diff) to Huw's work to move it farther along today?
<rick_h> gary_poster: k
<gary_poster> rick_h, will you or jcsackett have time to look at that today, or should I ask someone on GUI?  Either is fine
<rick_h> gary_poster: I'll see, I'm runing a little behind on auto complete so I'd like to keep on that today. But I know what the issue is and it's a quick one-line fix. 
<rick_h> gary_poster: so I'll try to squeeze it out after I qa this. 
<gary_poster> cool rick_h.  lemme know if we can help
<luca> for people who are interested the visuals for the browse mode can be seen here: https://drive.google.com/a/canonical.com/?tab=co#folders/0B7XG_QBXNwY1SUtlREw0aHlnbHc
<luca> and final inspector designs can be seen here: https://docs.google.com/a/canonical.com/file/d/0B7XG_QBXNwY1VHZyMlVlamtTTDA/edit?usp=sharing
<sinzui> thank you luca
<luca> sinzui: we have found a place for the social icons, who needs to seem them?
<sinzui> luca, jcsackett,
<rick_h> sinzui: mjc is blowing up on me at the moment with internal server error. 
<sinzui> rick_h, I am not seeing this
<sinzui> search works, the db is up
<rick_h> sinzui: https://manage.jujucharms.com/api/2/charms?series=precise&text=&type=approved fails
<rick_h> hmm, not sure why that url was generated atm though
<rick_h> luca: so some diff in your linked image and the branch from huw. There's no "Summary" section in the summary tab. There's a summary field we output to. It's a bit confusing to have the dual nested. 
<rick_h> luca: have we talked with the juju charm folks about not displaying the field from the metadata file? http://bazaar.launchpad.net/~charmers/charms/precise/lamp/trunk/view/head:/metadata.yaml
<rick_h> luca: I also don't see the back link in the image you shared there. 
<sinzui> rick_h, looks like search really wants categories in the params
<rick_h> sinzui: k, I'll file a bug to look into that more. I kind of hit that on accident while doing QA work 
<teknico> is anyone getting this when bootstrapping on ec2? error: cannot start bootstrap instance: no "precise" images in us-east-1 with arches [amd64 i386]
<rick_h> teknico: saw that over in #juju today I think
<teknico> rick_h: thanks, looking
<rick_h> teknico: 2.3hrs ago in #juju
<rick_h> ish
<luca> rick_h: which image are you referring to?
<rick_h> luca: https://drive.google.com/a/canonical.com/?tab=co#folders/0B7XG_QBXNwY1SUtlREw0aHlnbHc
<rick_h> luca: I'm comparing that link you shared with the qa I'm doing of huw's branch and finding some changes. 
<luca> rick_h I see, so these are brand new so there will be some discrepancies
<luca> rick_h: the nav had to change a fair bit from the last screens he saw
<rick_h> luca: ok
<sinzui> rick_h, I reproduced the error on staging and have the traceback
<sinzui> rick_h, I'll report the bug
<rick_h> luca: I do think the summary issue needs to be worked out. We can't remove the field, but having the tab and the section heading both say summary kind of sucks
<rick_h> sinzui: 1199780
<sinzui> thank you
<rick_h> luca: maybe we can drop the heading but keep the text. So it's just the initial text on the tab
<luca> rick_h: so your saying that 1) Currently there will be a Summary tab and then the first header under it will be Summary and 2) that we can't really stop that happening but we could choose to remove the first heading?
<rick_h> luca: yea, in my opinion 
<sinzui> rick_h, looks like the issue is 1 bad charm. The listings fail if the charm is in the search results. More misadventures with dict keys
<rick_h> luca: but that's up for debate/discussion. Just tossing out the best fix I can see at the moment. 
<sinzui> and __getitem__
<rick_h> sinzui: ah, joy of joys
<rick_h> gary_poster: so I've got a couple of qa issues with huw's branch. What's the opinion on things? Push it along and get follow ups since it's not 'broken' and not public facing?
<gary_poster> rick_h, get issues addressed by someone today, and get it landed.  I can reallocate resources: getting this landed properly ASAP is probably the top priority for the entire team, and if we can get things out of the way for Huw then we should.
<rick_h> gary_poster: ok. https://codereview.appspot.com/11104043/ has my screenshot links and notes. 
<rick_h> gary_poster: the share thing can probably slide as it looks like that's changing and it's not broken. The tab border issue should probably get a fix. 
<rick_h> luca: did you file a bug on the tab being kept through navigations?
<luca> rick_h: not yet, it's on my to-do list
<rick_h> luca: ok, I'll file so I can add it to our board. 
<luca> rick_h: ok thanks :)
<gary_poster> rick_h, cool thank you.  agree that the strange border should go.  agree with summary tab.  Maybe jcsackett can weigh in on what to do with share link?  I don't know what the graphical plan is there
<rick_h> gary_poster: per luca's updated image above it looks like it goes to seperate images. 
<rick_h> gary_poster: so I'd think this can be a temp place holder until a branch updating the sharing UI would be ok
<luca> rick_h: gary_poster wait
<luca> rick_h: gary_poster there is no longer a "share" word or anything
<luca> rick_h: gary_poster the icons are always visible
<rick_h> luca: but that's a future update and shouldn't hamper landing huw's work correct?
<luca> rick_h: well, yes, your right
<luca> rick_h: just making you guys aware that it's changed :)
<luca> rick_h: ok so
<luca> rick_h: we didn't know we could have bespoke icons for sharing
<luca> rick_h: so we used the standard API ones to be easy
<luca> rick_h: we kinda always wanted the bespoke ones...
<rick_h> luca: k
<luca> rick_h: so we are wondering if those icons can be 20x20px instead of the 32x32px and moved into the position that sharing is at here: https://docs.google.com/a/canonical.com/file/d/0B7XG_QBXNwY1RFdOb3lGdWc2b1E/edit?usp=sharing
<rick_h> luca: sure, file a bug with the assets and we can look into that.
<luca> rick_h: ok, thanks
<luca> rick_h: gary_poster the biggest issue that I can see wrong is actually the width of the narrow panel and the charm details
<luca> rick_h: gary_poster charm details is 50px too small and narrow panel is 60px too wide
<rick_h> hah, gary split. we lose
<adeuring> abentley: could you please join the hangout again for a minute?
<rick_h> luca: I noted your qa assessment here https://codereview.appspot.com/11104043/
<luca> rick_h: thanks, I'm writing them down in an email
<abentley> adeuring: Done.
<rick_h> luca: k, but I think gary mentioned that we'd try to get resources together to update and fix before huw gets back to work
<rick_h> luca: so not sure I'd mess wit hthe email. We'll note them in the review and see who has bandwidth to update and go from there. 
<rick_h> ok, I'm off to autocomplete-land. 
<hatch> gary_poster: http://jsbin.com/evehit/9
 * frankban back in a while
<gary_poster> hm
<sinzui> gary_poster, I think we need rt 62818 give a high priority. webops cite is it complex and needs to be scheduling. I don't know why I am hearing about this now since the rt has been in their queue for 9 days.
<Makyo> luca, let me know when you have a moment.
<gary_poster> hatch, luca, hey.  did my comments come through?  looks like I was dumped out of IRC
<gary_poster> sinzui, looking
<sinzui> gary_poster, Can we engage Marks super-powers to get the juju-gui charm and code updated
<hatch> gary_poster: no comments for a loooong time :)
<gary_poster> heh
<gary_poster> <gary_poster> hatch, perfect :-)
<gary_poster> <gary_poster> hatch, what is diff between "Array.prototype.forEach.call(headers, ...)" and "headers.forEach(...)"?  Is it that document.querySelectorAll('.header') doesn't actually return an Array?
<gary_poster> <gary_poster> luca, could you please confirm the header behavior in the link hatch gave above?
<luca> hatch: can you past the link again? :D
<hatch> ahh - querySelectorAll returns an array like object not an array
<hatch> luca: http://jsbin.com/evehit/9
<hatch> it looks the best in FF because FF has easing on it's scrolling :)
<luca> hatch: gary_poster sort of, the headers should not stack at the top
<luca> hatch: gary_poster or at the bottom
<hatch> I thought we decided on this interaction because what happens if the user is down at the bottom of a 1000 unit list and wants to get back to the top?
<hatch> they should be able to 'click' on the header and get back to it
<luca> hatch: lets talk on hangout :)
<luca> hatch: is guy chat available?
<gary_poster> luca, I agree with hatch on that.  if it's a misunderstanding, it's another one to add to our list. :-(
<hatch> yup
<hatch> in guichat
<gary_poster> luca, and an expensive misunderstanding
<hatch> lol I'd say
<gary_poster> hatch please ref bottom right of inspector wireframes in https://drive.google.com/a/canonical.com/?tab=co#folders/0B7XG_QBXNwY1dEFVSWh3TWtQOUk
<teknico-phone> wow, my UPS just stopped a lightning from frying the rest of my stuff
<teknico-phone> it sounds like an air raid today
<teknico-phone> Makyo: when you reproduced the problem with the discourse charm, yesterday, what env were you using? sandbox? also, what did you do exactly?
<Makyo> teknico-phone, I was using improv, and I saw the message from pyjuju in the improv terminal.
<Makyo> teknico-phone, then I noticed the cs: missing from the ghost of the charm on the canvas.
<teknico-phone> Makyo: it does not seem to happen in the sandbox, but for some reason I cannot set a breakpoint, so I'm not sure
<teknico-phone> Makyo: it's very weird, if I try to deploy it a second time I correctly get the notification that I can't, so the onCharmDeployClicked method is being executed, but it won't stop at the breakpoint
<Makyo> teknico-phone, Oh, hmm.  Anything in the JS console to indicate an error preventing it from getting to that point?
<benji> I need to access the db from a viewlet but it isn't obviously available, I cheated just to get unblocked but I am curious about the recommended way to do it.  Here is the code in question: http://paste.ubuntu.com/5861898/
<frankban> guihelp: could anyone please review https://codereview.appspot.com/11110043 ? thanks!
<bac> frankban: sure
<frankban> thank you bac
<rick_h> benji: I think there was an example bac did on that. 
<rick_h> bac and frankban went through 
<bac> benji: yes, there are examples
<hatch> frankban: I'm actually doing it right now :)
<benji> bac: this.inspector.get('db'); ?
<bac> benji: yeah, that looks like it!
<bcsaller> why fire db.update, we have databindings to avoid that
<frankban> cool thanks hatch 
<benji> cool, thanks
<benji> bcsaller: cargo culting; I'll remove it and see if it still works; thanks
<bcsaller> anything calling db.update is suspect under the new flags
<bcsaller> calling/firing
<hatch> s/suspect/not allowed ;)
<benji> bcsaller: it worked; thanks
 * benji makes mental note: "no more update events"
<frankban> hatch: added your nick to my card
<hatch> thanks, sorry I was in a call too
<hatch> too much multi tasking :)
<bcsaller> hatch: or we can just disconnect the handler when the flag is on ;)
<hatch> lol
<gary_poster> rick_h, am I right that OSCON autocomplete deliverable does not include categories?
<hatch> ^5
<gary_poster> rick_h, fwiw, I'm talking about what can be delivered this week.
<rick_h> gary_poster: yes, I'd like to not count on it. 
<gary_poster> rick_h, cool thanks
<hatch> frankban: reviewed
<frankban> hatch: thanks, I merged trunk from today, so it should be fine
<hatch> great
<frankban> hatch: and yes, that branch only implements the logic and does not involve ux/positioning. I'll create a card like "Move the constraints under the settings in the inspector service page", correct?
<hatch> frankban: yep - although that can't really be done until the scrolling story is implemented (which was just slightly changed this morning)
<hatch> I'm hoping to have the scrolling code done by EOD
<frankban> hatch: so, blocked on inspector scrilling
<frankban> scrolling even
<hatch> yup thx
<Makyo> luca, let me know when you have a second to check my work on SVGs.
<bac> frankban: done.  didn't mark it approved as there were some oddities (i thought) during QA
<bac> Makyo, hatch: either you have any experience with using a vertical YUI slider?  the thumb image (what i'd call the marker) is not rendering properly and i can't figure it out.
<Makyo> bac, not yet, but would be glad to take a look.
<Makyo> Is it rendering the thumb for the horizontal slider?
<frankban> bac: thanks will take a look
<bac> Makyo: thanks.  it is lp:~bac/juju-gui/move-zoom
<hatch> bac: sorry I have never used the slider code
<Makyo> jujugui call in 10 kanban now.
<Makyo> bac, is there a right-sidebar.partial?
<bac> sorry Makyo, let me add that and repush
<bac> Makyo: done
<Makyo> bac, cool, thanks.
<Makyo> jujugui call in 2
<luca> Makyo: I'm free now but your most probably in stand-up
<Makyo> Yep, just a sec.
<bac> hey we get mentioned in https://github.com/juju/charm-championship
<Makyo> luca, I'm in guichat,
<luca> Makyo: omw
<luca> Makyo: that sounds like a big dog =O
<adeuring> abentley: could a have a look at this MP: https://code.launchpad.net/~adeuring/charmworld/get-file-content-from-bzr/+merge/173987 ?
<Makyo> luca, she's medium sized, but really, really loud.
<abentley> adeuring: Sure.  OTP with sinzui at the moment.
<adeuring> abentley: np. I'm off soon for an "evening appointment".
<gary_poster> Makyo, when you are ready to look at Huw's branch let me know.  We can prioritize some bits.  Almost all of what luca said can pushed to another branch, but if we can fit some of them in now that would be cool too.
<hatch> hmm
<hatch> it appears that the casting of the new charm model to the old one got removed somehow
<hatch> benji: did you happen to move that somewhere ? ^
<rick_h> hatch: bzr grep "Charm\("
<rick_h> hatch: I still see it in browser/views/charm.js
<rick_h> hatch: if the deploy is going through some other section of code perhaps it needs to be added and wasn't?
<hatch> well it 'was' there
<hatch> I'm just trying to figure out if it was removed on purpose or as part of the merge
<rick_h> jcsackett: your code doesn't exist! https://codereview.appspot.com/11120043/ lol
<jcsackett> rick_h: yeah, had to delete the proposal when i looked at it and realized i had the wrong "for".
<jcsackett> and of course, this one time i forgot the -wip flag while i checked. :-P
<bcsaller> does http://jsbin.com/ivakuc/1 seem like a reasonable place to start for the status bar? anyone have any suggestions?
<rick_h> sinzui: let me know if/when you want to chat this afternoon. I'm set
<hatch> bcsaller: the animations seem inconsistent
<hatch> sometimes it drops them when I think it should animate
<hatch> other than that, I love the idea :)
<hatch> ok almost got this code back to where it was pre-merge
<bcsaller> hmm, not sure what you mean, but I'll look at it again
<hatch> somehow it thinks there is a conflict though after changing the views
<bcsaller> hatch: was it related directly to what I did or just a bad merge?
<hatch> bcsaller: well it was your code - but not your fault, just the merge
<hatch> I had to pretty much manually merge it
<hatch> bcsaller: so I make a change to the config, save it to the model, close the inspector, open the inspector, it says that field is in conflict....
<hatch> should closing the inspector not destroy it?
<hatch> it being the databinding class
<bcsaller> hatch: put a debugger in there, I think it should, yes
<hatch> hmm it does call unbind
<hatch> will have to look further
<benji> hatch: I was eating lunch (and technically still am for a minute or two) did you figure it out?
<hatch> benji: yep I think it was removed by the merge
<hatch> bcsaller: have a second for a quick call?
<bcsaller> hatch: hanging out
<benji> do we support IE9?  I need to get more RAM before it'll be usable, but I'm looking at setting up a VM for IE testing and am wondering if I should just do IE10 or if I need 9 too
<rick_h> benji: I thuoght 10
<gary_poster> benji no we do no support 9
<gary_poster> t
<benji> cool, thanks guys
<Makyo> bac, I can't figure out why the thumb on the slider isn't being styled properly.  I'm going to grab lunch in a few and should probably look at huw's branch with gary_poster to land what we can.  Just not quite sure what's going on with it.
 * gary_poster acks
<bac> Makyo: thanks for looking at it
<gary_poster> (IIUC you mean we will talk after lunch)
<Makyo> gary_poster, yeah.
<gary_poster> cool
<gary_poster> thanks
<benji> Where are the new assets?  I've scoured my email but can't find any reference to them.
<gary_poster> benji, if there are any they would be here: https://drive.google.com/a/canonical.com/?tab=co#folders/0B7XG_QBXNwY1Qi13X3RqR1dfaFE
<benji> thanks
<gary_poster> sinzui or someone else who knows, I want to make the haproxy in https://launchpad.net/~juju-gui/+archive/ppa/+packages to be available in raring now, in addition to precise.  I tried copying, but got "haproxy 1.5-dev17-1 in precise (same version already has published binaries in the destination archive)".  What's an easy and approximately correct way of doing this?
<sinzui> yuck
<benji> I know the wrong way to do it: append something fake onto the version number, like bump the "-1" to "-2" or add a "~1".
<sinzui> gary_poster, benji is correct if we cannot delete the existing binaries
<gary_poster> benji, gotcha.  so download the package, mutate it and re-upload.  ugh.
<benji> gary_poster: is this genereated by a recipe?
<gary_poster> benji, no
<gary_poster> don't think so
<gary_poster> oh wait
<gary_poster> maybe it is working?
<sinzui> gary_poster, maybe I mis-understand
<sinzui> https://launchpad.net/~juju-gui/+archive/ppa/+packages
<sinzui> gary_poster, I see the package is already available for raring
<sinzui> oh, pending
<gary_poster> sinzui, it is pending.  I tried rebuilding and it immediately complained as I described.  I'm trying to copy now in case that works.
<sinzui> yeah. me too.
<sinzui> We need to delete the pending one to make way for a replacement
<gary_poster> oh
<sinzui> gary_poster, https://launchpad.net/~juju-gui/+archive/ppa/+delete-packages?field.name_filter=&field.status_filter=&field.series_filter=raring
<sinzui> deleting can take a hour because the db and file system need cleaning
<gary_poster> sinzui, actually that is your copy there.  it might work?
<gary_poster> maybe we should let it try?
<sinzui> gary_poster, I tried a copy with rebuild (because the rebuild will conflict with the precise version)
<gary_poster> you tried a copy without rebuild, you mean?
<gary_poster> sinzui, it published!
<gary_poster> sorry, I should have tried to do it without rebuilding myself
<gary_poster> ok, thanks, giving this a try
<rick_h> sinzui: did you want to chat?
<sinzui> gary_poster, np. It is not obvious when rebuild will fail, but I think Lp could no and not offer the option
<gary_poster> yeah woud be nice
<gary_poster> l
<sinzui> rick_h, in 5?
<rick_h> sinzui: rgr
<sinzui> rick_h, I am ready
<rick_h> sinzui: https://plus.google.com/hangouts/_/e325fa1b54867af5f8bd68ddb8a8b235a4fb3887?hl=en
<rick_h> sorry, my usb went dead
<sinzui> rick_h, Ah. I was tried several times and just got your picture
<Makyo> gary_poster, I'm free to take a look at that branch.
<Makyo> Is it the visual-update-3 branch?
<gary_poster> Makyo, yes
<Makyo> Okay, pulling now.
<gary_poster> Makyo, https://codereview.appspot.com/11104043/ .  I'd like to address Rick's concerns ASAP and land, and then maybe talk through what to tackle from the remaining tasks from Luca.
<gary_poster> Luca's comments were a laundry list of things to be done
<gary_poster> oh, jcsackett should we just leave the share icon alone from Huw's branch or should we put something back?
<Makyo> gary_poster, cool, on it.
<gary_poster> Thanks Makyo 
 * hatch sitting waiting for lbox to finish.....notice that I didn't hit enter
<hatch> *facepalm*
<hatch> jujugui looking for reviews https://codereview.appspot.com/10872045/
<benji> hatch: I'll do one
<hatch> thanks
 * hatch rages because he wants to use the sticky header code he wrote
<hatch> :)
<hatch> grabbing lunch
<jcsackett> gary_poster: it's fine to be landed without the icon, but the call in views/charm.js should remove the call to the sharing widget, since it'll bork without a button.
<jcsackett> sorry for the delay in response; missed the alert earlier.
<jcsackett> gary_poster: i'm working on adding the new sharing stuff back in; it's much simpler, so the sharing widget goes away, but i'll do all the other cleanup in my branch, if huw's just kills the call to create the widget.
<gary_poster> np jcsackett.  is that the easiest fix, do you think?  sharing seems to be working in his branch
 * jcsackett blinks
<gary_poster> I could start a tweet just fine :-)
<jcsackett> one sec, lemme do a full QA on sharing on his.
 * jcsackett just glanced at the branch
<jcsackett> gary_poster: actually, this is all safe.
<jcsackett> ignore what i said earlier.
<jcsackett> the sharing buttons are getting re done, so there's no point in adding a new icon back in.
<gary_poster> jcsackett, cool.  so land as is, in this regard
<gary_poster> thank you
<jcsackett> indeed.
<jcsackett> yw.
<gary_poster> Makyo, ^^^
<Makyo> Thanks.
<bac> Makyo: you have time to chat?
<Makyo> bac, sure
<sinzui> abentley, How do we get a download-cache package change into production?
 * sinzui doesn't see any documents telling webops to pull the branch
<abentley> sinzui: err...
<abentley> sinzui: don't they just package our branch when they package the other tarball?
<abentley> sinzui: Package may be the wrong wore.
<abentley> s/wore/word/
<sinzui> abentley, I have not read what this command really does:
<sinzui> ./build-charmworld $REVNO
<sinzui> I know it pulls the app branch and makes a tarball from it.
<sinzui> I will as webops.
<gary_poster> bac, we have some metrics!
<gary_poster> quite a few metrics
<bac> gary_poster: oh, cool. i haven't looked in a while
<gary_poster> I'm now trying to remember how to look at the deployment info
<sinzui> abentley, I feel like I could save tie and just shell out to file to get the mime-type rather than add another dep
<gary_poster> ah right, events
<bac> gary_poster: i wired up my vietnamese site the other day and got interesting data from it too
<abentley> sinzui: I've never worried about it until now-- it's always just worked.
<sinzui> well then, abentley, I'll add python-magic to the requirements.txt and cache and cross my toes
<gary_poster> bac, heh, 22 people have deployed juju-gui from juju-gui.  should we be worried? :-)
<gary_poster> If you take away mysql, wordpress, haproxy, memcached, admediawiki, you have very few
<gary_poster> isn't that our example set?
<gary_poster> and they are all updates
<sinzui> gary_poster, that is madness. Do you think people are attempting to engineer a gui that behaves like read-only
<hatch> deployed the gui from the gui?
<hatch> is that like gui inception?
<gary_poster> :-)
<huwshimi> Morning
<gary_poster> hey huwshimi!  branch was great, thank you
<hatch> huwshimi: holy crap it's early there!
<hatch> :)
<gary_poster> I was writing an email to you
<huwshimi> :)
<gary_poster> huwshimi, Makyo is fixing up two small things from Rick's qa.  he then plans to land it before his EoD
<gary_poster> then for the laundry list from luca,
<hatch> gary_poster: just FYI about the scrollview indicator https://github.com/yui/yui3/issues/983
<gary_poster> hatch, cool, thanks, and interesting replies
<hatch> yeah....damn browsers are like a moving target haha
<gary_poster> :-)
<hatch> jujgui looking for another review https://codereview.appspot.com/10872045/ plz
<hatch> jujugui ^
<bac> gary_poster: i don't understand where you got that data.  from 'real time - events'?  it looks like those numbers are only for the last 30 minutes
<gary_poster> huwshimi, for that laundry list, you can outright dump three of them, and the rest simply gradually do what you can in a day and get it out there
<hatch> gary_poster: there was a leaked geekbench test for a 15" macbook pro with haswell which was almost identical to the current gen which means....same performance more battery life....yay!
<gary_poster> bac, no, content -> events -> overview -> event action -> update -> secondary dimension/events/label
<gary_poster> hatch, yeah I saw. sounds good to me :-)
<gary_poster> looks like it will come out with mavericks
<hatch> yeah and with the 5000 gpu plus the nvidia card it's going to be a powerhouse with good battery life
<gary_poster> huwshimi, will get back to email to give details :-)
<gary_poster> hatch, I saw some people questioning if it will have nvidia.  probably, but some question
<huwshimi> gary_poster: Thanks, just going through the comments now
<gary_poster> cool
<hatch> ohh really? dropping the separate card alltogether? or just going with another manufacturer?
<gary_poster> hatch it was pure fanboi speculation but the idea was dropping, because the intel high end chips have plenty of power to drive many use cases, including secondary retina monitor IIRC.  probably graphics people still need their nvidia though.
<hatch> ahh - yeah I suppose I could see the usecase for that - although then they could probably just get by with the Air
<huwshimi> gary_poster: Would you be happy with me landing all Luca's comments as a new branch?
<gary_poster> huwshimi, yes, that was what I was going to suggest.  As I said, Makyo is handling your current branch, so you can make a new one based off of trunk + yours and gradually make changes, and add what you can today
<huwshimi> gary_poster: Great!
<gary_poster> :-)
<gary_poster> huwshimi, to be clear, I think luca feels that what you have today is good enough that if we had to ship now, they would be happy enough.  he said ale was very happy too, but I don't know if she would go that far or not. :-)  but anyway, IMO the emergency has passed, is my point.
<gary_poster> thanks to your work
<gary_poster> oh meh
<huwshimi> gary_poster: No problems. I'll try and polish what we have now and maybe get a few additional things done on Friday, but not sure if that would get landed in time.
<gary_poster> cool huwshimi.  I think user tests will be on the basis of whatever you prepare for landing today.  OSCON will probably be roughly on the basis of whatever you prepare for landing on Friday.
<huwshimi> gary_poster: OK that sounds good. Was "oh meh" related to me?
<gary_poster> huwshimi, "oh meh" was because I thought freenode had dumped me or something, and you maybe hadn't heard me.  NickServ was giving me another auth challenge, and they have been attacked today
<huwshimi> gary_poster: Ah ok :)
<gary_poster> :-)
<hatch> next person to comment has to review my branch  https://codereview.appspot.com/10872045/
<hatch> mohohahaha
<gary_poster> hatch I will do so if I have time after finishing this email and before date night :-)
<hatch> haha that's ok
<hatch> Makyo: can do it
<hatch> :P
<gary_poster> heh
<gary_poster> he's busy with another crunch task :-P
<huwshimi> gary_poster: The new sharing format is probably not going to make it as I don't think I'll have time to implement such a change. Should we just remove the link for now?
<gary_poster> huwshimi, that's one of the things off your plate.  Jon is handling it.
<gary_poster> huwshimi, we will land what you have now in that regard, and that's the last you have to worry about it
<huwshimi> gary_poster: OK, I'll probably still need to place it correctly though.
<huwshimi> gary_poster: There are quite a few things from Luca's comments that won't make it. We don't have breadcrumbs so I'll have to add in back buttons, I can't removed the bottom bar as we're still using it for a bunch of things. etc.
<gary_poster> huwshimi, agreed.  Almost done with the email then we can confer
<huwshimi> gary_poster: Sure, I keep interrupting you :)
<gary_poster> lol, np
<hatch> does anyone have the wiki link to the sprint?
<hatch> the search is failing me
<Makyo> https://wiki.canonical.com/CDO/Juju/GUI/Sprints/July2013
<gary_poster> hatch, I am trying to keep links to all important bits on https://wiki.canonical.com/CDO/Juju/GUI fwiw
<hatch> Makyo: thanks
<hatch> gary_poster: ahh cool I'll bookmark that
<hatch> thx
<gary_poster> welcome
<Makyo> Gah, finally.  I hate pseudoselectors.
<Makyo> gary_poster, huwshimi Alright, some of rick_h 's comments addressed in lp:~makyo/juju-gui/visual-update-3  The outlines around tabs makes me feel dumb, since it was a UA style.
<gary_poster> great Makyo, will look.
<gary_poster> huwshimi, just sent email.  lemme know what you think pls
<huwshimi> gary_poster: Just looking
<huwshimi> gary_poster: Am I overloooking something with the back button? I don't see one in that mockup... or is it the breadcrumbs?
<hatch> afternoon marcoceppi
<hatch> photospheres on G+ are so cool
<hatch> can't wait until that's available on all android devices
<gary_poster> huwshimi, you are right.  If we can't do the breadcrumbs could we add home link alone in same location for now?  it is annoying to use without it
<gary_poster> IMO :-)
<huwshimi> gary_poster: Sure, I'll see what I can do.
<gary_poster> cool thank you huwshimi.  will reinstating the test results be problematic?
<huwshimi> gary_poster: At the moment they only appear if there are failures. I'll have to see if we can make it just change the status.
<gary_poster> huwshimi, oh right.  is that a question for orange, then?
<huwshimi> gary_poster: Well, that would give me one less (not necessarily simple) thing to change where I haven't touched the codebase yet...
<gary_poster> sinzui, ^^^ we are supposed to make test results show always, not merely when there are failures.  Could either rick_h or jcsackett tackle that?  It is an important one for ecosystems.  If it is a big task for them, let's talk, but if it can be done quickly that would be fantastic
<gary_poster> Makyo, ship it
 * hatch smashes red button on Makyo's keyboard "SHIP IT!"
<gary_poster> :-)
<sinzui> gary, yes we want to show all results on the QA view.
<Makyo> My keyboard! D:
<gary_poster> lol
<hatch> haha
<gary_poster> huwshimi, can you submit branches?  If so I'll LGTM your branch asking you to merge Makyo.  And then ask Makyo to LGTM also, in lieu of rick's LGTM
<huwshimi> gary_poster: Yeah
<gary_poster> well, maybe merge his branch, rather than Makyo himself
<gary_poster> cool
<gary_poster> on it
<gary_poster> huwshimi, LGTM'd
<huwshimi> gary_poster: Thanks!
<gary_poster> hatch, looking at your branch before I run because I feel sorry for you ;-)
<gary_poster> sinzui, do you know if that is an easy task?
<hatch> hey, I'll take what I can get! Although I don't want mrs Poster to be mad at me for making you late for date night
<gary_poster> :-)
<rick_h> gary_poster: it's easy. The data is there. It just needs to be adjusted in the tempalte side. 
<gary_poster> so far so good
<rick_h> gary_poster: the only big thing might be any asset related stuff as I've not seen the latest/greatest of designs
<huwshimi> rick_h: I can style it.
<sinzui> gary_poster, I think it is easy. about 2 branches get the info and then make links to it.
<gary_poster> rick_h, fantastic.  Would it faster for you (that is, in your own personal schedule) to do it (maybe make a branch and give it to me to get it landed) or to guide someone else to do it
<huwshimi> rick_h: Or rather provide a branch with styling in it for you guys
<huwshimi> huwshimi: Well, either way
<gary_poster> muttering to yourself now, are you?  uh oh
<rick_h> gary_poster: if someone can do it I can point if it needs to be done this week. Otherwise I can do it. I know where that part is as I wrote the failingProvider stuff
<huwshimi> gary_poster: I don't agree with all the changes in this branch....
<gary_poster> huwshimi, lol :-P
<rick_h> gary_poster: but hoping to push intiial autocomplete tomorrow and fix a few bugs we've found the last two days
<gary_poster> rick_h, exactly I don't want to be in your way
<rick_h> gary_poster: but bzr grep failingProviders points to where everything is currently. Just needs to not be failing, but all providers in the data set. 
<gary_poster> rick_h, ok.  I think/hope benji will be ready for this tomorrow morning-ish.  huwshimi, otoh, if that ^^^ helps you tackle it today, all the better. :-)
<gary_poster> thanks!
<huwshimi> gary_poster, rick_h: I'll take a look at providers today and email if I get to it.
<rick_h> huwshimi: rgr
<gary_poster> cool thanks huwshimi 
<huwshimi> gary_poster: One of the changes in this branch will break the fonts, one of them will break accessibility
<gary_poster> huwshimi, you mean in Makyo's branch?  Is it easy to fix?
<gary_poster> huwshimi, I thought you were joking that you didn't agree with yourself
<gary_poster> I assume the fonts is easy to fix
<gary_poster> just include the thing that Rick asked about and Matt probably omitted
<gary_poster> on that basis
<gary_poster> accessibility though...
<huwshimi> gary_poster: Yeah, I can just revert the changes. In fact what it leaves are not really QA issues and are trivial things I could fix up in a new branch (changing a CSS property to a variable and adding a heading)
<huwshimi> (the heading change is a guess as to what Luca wants anyway)
<gary_poster> huwshimi, the two improvements I cared about was removing the duplicated "summary" heading and removing the UA-driven link highlight
<gary_poster> can we keep those?
<gary_poster> s/was/were/
<huwshimi> gary_poster: If you remove that highlight you will stop any users from seeing where they have tabbed to
<huwshimi> they're only that ugly on Chrome
<gary_poster> huwshimi, that's our primary target though :-P
<gary_poster> huwshimi, so...
<gary_poster> huwshimi, is the problem that luca has not given us a design for indicating a selected tab?
<Makyo> Selected tab is indicated with an orange bottom border.
<huwshimi> huwshimi: No the problem is that the YUI tab has recieved focus and the way chrome represents that an element has focus is by adding a yellow outline
<huwshimi> gary_poster: ^
<huwshimi> I'm talking to myself again :P
<gary_poster> heh
<Makyo> You can focus on other tabs by clicking and dragging slightly.  It won't fire a click event, but will show UA focus.
<gary_poster> um
<Makyo> In fact, you can tab away from links to the sub-headings of the content of the tab and those will be outlined.
<gary_poster> huwshimi, I am afraid I don't understand the problem with removing the yellow outline, given the orange bottom border.  I'm sorry for not looking at the code, but I'm desperately trying to finish up for date night. :-)  Can't we disable the UA styling only for these tabs?  Perhaps that's what Makyo's already doing?
<huwshimi> gary_poster: That's what happens, but it adds an accessibility regression. If we're happy with that then it's fine to land
<gary_poster> huwshimi, accessibility for whom?  blind users?
<huwshimi> gary_poster: Anyone who is using the keyboard to navigate
<Makyo> Is it worth utilizing the :focus pseudoselector to introduce a less intrusive style to indicate focus?
<Makyo> A question for design, of course.
<gary_poster> sigh, I really need to go :-) but I don't understand. huwshimi are you available for super fast hangout?  Makyo you are welcome if you are up for it.
<gary_poster> guichat
<marcoceppi> o/ hatch
<hatch> hows the competition coming?
<gary_poster> hatch, LGTM with apology for no qa :-P
 * gary_poster runs away!
<gary_poster> bye all 
<gary_poster> ttyl
<hatch> have a good night, thanks
<marcoceppi> hatch: pretty good so far, I think the repo's been forked 10 times and a bunch of people "watching" it
<hatch> ahh great - I am trying to think of something to write
<marcoceppi> tbh, that's all mims and jorge, I'm just watching from afar
<hatch> but I can't think of any 'environment' to make
<hatch> I can think of a bunch of helpful charms but nothing that would make an environment
<huwshimi> rick_h: Any idea how to make the sidebar view navigate from search results or a category back to the initial content? I know I need to fire this.fire('viewNavigate'... but I don't know what value to set. I suspect we might have to add something, but not sure what.
#juju-gui 2013-07-11
<rick_h> huwshimi: yea, that's on my todo for autocomplete. Basically we'll need a viewNavigate with some sort of history flag that tells it to reload the previous state 
<rick_h> huwshimi: so it doesn't exist yet, and needs to be defined/coded into the bit that updates state to go off the old state first. 
<huwshimi> rick_h: Ah right. We need some breadcrumbs under the search box so I was going to start that with a home button but I'll leave that until your bits are in place.
<rick_h> huwshimi: ok
<huwshimi> (Unless doing breadcrumbs as part of your work makes sense)
<huwshimi> rick_h: ^
<rick_h> huwshimi: not really
<huwshimi> rick_h: Sure :)
<rick_h> huwshimi: honestly we're a bit out of the loop. We didn't think we'd still be on this and we've ignore much of the new design/etc. 
<huwshimi> rick_h: OK sure.
<rick_h> so breadcrumbs is 'what breadcrumbs?' :)
<huwshimi> rick_h: Fair enough :)
<huwshimi> rick_h: The latest visuals for the autocomplete have the breadcumbs in them, so hopefully you're building the right thing :P
<rick_h> huwshimi: https://drive.google.com/a/canonical.com/#folders/0B7XG_QBXNwY1ZmdTTDdTZEdFOGM is what I'm going off of. It's what I know about in the oscon deliverables folder and search
<rick_h> nothing there, so if ther's other stuff we need to be updated. 
<rick_h> and we should start killing off out of date visuals as there's too damn many things floating around in docs to keep up with
<huwshimi> rick_h: Agreed.
<huwshimi> rick_h: That's the latest one. The screen for when you've searched or when you're browsing a category has the breadcrumbs
<huwshimi> rick_h: I.e https://docs.google.com/a/canonical.com/file/d/0B7XG_QBXNwY1ZVpkRjVtY0luaE0/edit
<hatch> evening gui nightcrew
<hatch> aka huwshimi
<huwshimi> hatch: Night
<hatch> oh I was using evening as a greeting
<hatch> :)
<huwshimi> hatch: Oh, hello :)
<luca__> can someone help me bzr something? argh...
<rick_h> luca__: rgr
<luca__> rick_h: I was hoping you wouldn't help since I pestered you so much yesterday!
<rick_h> luca__: going to be slim pickings this morning :)
<luca__> rick_h: I've just typed "bzr branch lp:~huwshimi/juju-gui/visual-update-4"
<rick_h> though I don't know. Sometimes some of the guys are around in the moring but in quiet mode
<luca__> hehe yeah :(
<luca__> and it came back with "Branched 824 revisions. "
<rick_h> luca__: ok, and you have a visual-update-4 directory like yesterday?
<rick_h> luca__: ah heh, so you did that in some other path than the previous one?
<luca__> I have a update-4 directory in my files
<rick_h> luca__: ok
<luca__> but when I type "make devel" it says "make: *** No rule to make target `devel'. Stop.
<luca__> "
<luca__> it's never done that before
<rick_h> luca__: so you have to be in the directory in the project that has the Makefile in it
<rick_h> if you can't do an `ls` and see the Makefile then you're not going to be able to run make *
<luca__> right
<luca__> so I need to cd into the update-4 file?
<rick_h> luca__: correct
<luca__> ah "make devel" is doing something now
<luca__> I need to obviously update my instructions
<luca__> so, it should be:
<luca__> 1. cd .. (cd src/jujugui/)
<luca__> 2. run "bzr branch lp:~juju-gui/juju-gui/browser-default"
<luca__> 3. cd to file drectory
<luca__> 4. run "make devel"
<luca__> 5. Open browser and visit http://localhost:8888/
<rick_h> luca__: that looks good
<luca__> rick_h: nice
<luca__> rick_h: it's all up and running in the browser, thanks for your help again :D
<rick_h> luca__: np, glad to help :)
<luca__> rick_h: :)
<luca__> rick_h: do you have the link to that site where I can leave feedback for the branch?
<rick_h> luca__: sorry, missed your request there. https://codereview.appspot.com/11160043/ is the link
<luca__> rick_h: thanks :D
<rick_h> gary_poster: so huw's branch is a LGTM with the update branch I've linked into the comments. luca__ might have some other feedback. If someone can help usher that through that'd be great. 
<luca__> rick_h: I have 8 bugs so far
<gary_poster> fantastic, thanks for the update branch rick_h .  luca__ are any of them  showstoppers or ok to land separately?
<rick_h> luca__: k
<luca__> gary_poster: nothing serious, I'll send them to you in 2 seconds
<luca__> gary_poster: it looks very good
<gary_poster> luca__, awesome thanks
<luca__> gary_poster: sent
<gary_poster> thx, will look soon (on call)
<luca__> gary_poster: no worries
<jcsackett> sinzui: having issues with g+, be on standup soon.
<bac> gary_poster: let me know when you'd like to have our cal
<bac> our call, not our cal
<gary_poster> bac, yeah sorry finishing up
<bac> np
<gary_poster> luca__, is https://drive.google.com/a/canonical.com/?tab=co#folders/0B7XG_QBXNwY1Y3k3UWJibndUbHc narrow charm details the visual design for the vertical scrollbar?
<hatch> morning
<luca__> gary_poster: yep
<luca__> gary_poster: we're not entirely sure what we can do with a scroll bar soâ¦.if you guys have some good ideas then I would be really happy to see them.
<gary_poster> luca__, ok cool.  so we shouldn't worry too much with assets for now, but just get it working then, IIUC. bac ^^^
<bac> rt
<luca__> gary_poster: bac yeah, the most important thing is that it's unobtrusive
<luca__> gary_poster: bac we like chromes scroll bars which disappear 
<bac> luca__: actually, we're talking about the vertical zoom slider
<bac> luca__: gary_poster misspoke when he said scrollbar
<gary_poster> sorry
<luca__> gary_poster: bac oh!
<luca__> gary_poster: bac then yes, thats the one :D
<luca__> gary_poster: bac I can send you the assets if you need them
<gary_poster> luca__, +1
<bac> yes please
<gary_poster> rick_h, you available for a quick call about charm model issues?  will let you go asap I promise :-)
<rick_h> gary_poster: sure thing
<bac> luca__: with the slider marker (called the 'thumb' in yui-speak) have a drop shadow?
<abentley> adeuring: I believe your get-content-from-bzr branch will fix this bug: https://bugs.launchpad.net/charmworld/+bug/1199780 See comment #4
<_mup_> Bug #1199780: search requests errors when a charm has no last_change <charmworld:Triaged> <https://launchpad.net/bugs/1199780>
<luca__> bac: the little white circle does have a drop shadow
<luca__> bac: I'm sending you assets for this zoom bar https://docs.google.com/a/canonical.com/file/d/0B7XG_QBXNwY1QjdzNWMwUm9ENDg/edit?usp=sharing
<bac> luca__: yui requires the marker and shadow to be in one image as sprites.  i may need to work with you to get that done correctly.
<luca__> bac: ok
<adeuring> abentley: it _might_ fix the error  -- but it is also a reminder that I should test how the new code behaves for an empty branch
<abentley> adeuring: True.
<abentley> sinzui: If the charm store doesn't care which branch is promulgated, should we?
<sinzui> abentley, I don't think we want to care
<sinzui> abentley, I think the store is making zips from snapshots. It doesn't care about continuity.
<hatch> luca__: is the prototype scrolling wrong? I was under the impression that it should 'push' the previous one up? https://dl.dropboxusercontent.com/u/10004366/juju-gui/index.html#
<hatch> one being heading
<hatch> right now that prototype simply covers up the previous one
<luca__> hatch: that's correct, it should push the other header out like it does on iOS and instagram, Ant couldn't spend too much time on it.
<hatch> *phew* ok
<hatch> luca__: I should also mention that the 'push up' kind of looks like garbage when using a scroll wheel on a mouse with a large scroll value
<hatch> I'm wondering if we shouldn't trap the scroll and then animate it ourselves
<hatch> (this is of course way more work)
<hatch> ^ gary_poster if you're around you may want to weigh in
<luca__> hatch: the push seems to be really hard to animate
<luca__> hatch: as a compromise we was looking at possibly a fade state between the 2 colliding headers
<hatch> well yes the push is hard - but that's not really the issue
<gary_poster> hatch, trap scroll and animate: +1 as bug for later work
<hatch> ok I'll create that bug
<hatch> luca__: are you ok with that?
<luca__> hatch: do you mean something like that demo you showed me yesterday?
<hatch> when header 2 comes in contact with header one, it pushes header one up as it scrolls
<luca__> hatch: ok, that is what we want
<hatch> however when you use a scroll wheel it 'jumps' which looks bad because of the order of events that need to happen
<luca__> hatch: right
<hatch> so we will need to trap the scroll and then animate the scroll ourselves
<hatch> to smoothen it out
<luca__> hatch: that makes sense, thanks
<hatch> alllrighty
<sinzui> luca__, arosales_, rick_h: We appear to be accepting icons that are not based on the one true icon template: http://manage.jujucharms.com/charms/precise/postgresql shows the issue best. orangesquad discussed enforcing icons based on the template, and we concluded that would be too strict. We can revisit the decision.
<rick_h> sinzui: yea, I think it's great to help with the icons, but not sure it's great to enforce too much as many projects have established icons and not all charmers are going to be graphic artists to adjust/fix them?
<rick_h> basically we stand to take a hit on charm submissions/etc if we enforce it too much. Then again, we only show them for reviewed charms so that limits the numbers a bunch. 
<arosales_> sinzui, rick_h: I take it if the icon isn't in the correct format it is not picked up correctly in the charm browser?
<rick_h> arosales_: if it's not icon.svg and valid svg (coming soon) it won't get pulled in. 
<rick_h> arosales_: however, if it's a valid svg, but doesn't use the gradient/lighting guidelines we accept it currently
<sinzui> arosales_, the icon template has the squircle outline and sets the dimensions to 96x96
<sinzui> the template has a gradient. users may change it, but they must follow the guidelines
<arosales_> aiui as long as a charmer submits a valid svg, their icon will show up even if they don't follow the template/guidelines, correct?
<sinzui> no
<sinzui> arosales_, icons are only shown for reviewed charms. ~charmers approved the icon
<arosales_> sinzui, yes sorry. If they are ack'ed by the review process too.
<arosales_> sinzui, but if ~charmers don't catch the icon not being in the correct format and still ack it will show up in the store as long as its a valid svg
<arosales_> my question is around how much review ~charmers should be doing around the icon
<hatch> darn my trackpad is out of batteries
<sinzui> arosales, I don't see think document on juju.ubuntu.com. I thought it was added: https://docs.google.com/document/d/1hBTH_7RLUYMV-VhZOGxb-bFHICXyVRU4t8L79Dlea80/pub
<frankban> bac: could you please take another look at https://codereview.appspot.com/11110043 ?
<bac> frankban: sure
<frankban> thanks
<arosales> jcastro, did you icon guide get ported over to the new docs
<arosales> sinzui, ya I am not seeing it. We'll need to add that
<hatch> gary_poster: luca__ http://jsbin.com/utitov/2/ - this breaks in FF for some reason and has an odd offset issue when scrolling back but it's very close
<jcastro> we never added the icon guide to the docs
<jcastro> we just gave people the google doc
<jcastro> it never made it out of a google doc onto normal docs
<hatch> oh noes not another Google Doc ;)
<hatch> too soon?
<arosales> jcastro, ah
<arosales> jcastro, I'll sync up with evilnick on getting that google doc added to the docs
<jcastro> I believe we used the "I sent it to the list, therefore it's documented" method on that one, heh
<arosales> sinzui, in progress of adding it to the docs https://bugs.launchpad.net/juju-core/+bug/1199367
<_mup_> Bug #1199367: icon.svg isn't documented anywhere <juju-core:Triaged by evilnick> <juju-core docs:Triaged by evilnick> <https://launchpad.net/bugs/1199367>
<arosales> sinzui, any guidance on how much review of the icon ~charmers should do?  Must follow the template, can deviate a little, or any valid svg?
<gary_poster> luca__, I remembered what I was going to say: the way we *can* get reuse of ant's prototype in the GUI is to reuse his brain :-)  he will have solved the issues before so maybe can be faster.  (whew, remembering makes me feel better ;-) )
<hatch> hmm
<hatch> http://jsbin.com/utitov/3/
<hatch> is better but there is an issue
<luca__> gary_poster: haha well, feel free to speak to him, he's solely on Juju until the end of next week so he can work on anything Juju related
<gary_poster> cool luca__ :-) thanks
<luca__> hatch: that's better, there seems to be a tiny issue scrolling upwards
<hatch> it appears that scrolling fast and with different scroll values 'tricks' it into thinking it's in a different position than it should be
<hatch> luca__: yeah, which doesn't happen if you scroll slowly heh
<sinzui> arosales, sorry, webops pinged and I have waited 11 days to get their full attention
<luca__> hatch: hehe
<hatch> getting closer
<hatch> scrolling is friggen hard
<sinzui> arosales, per the guidelines in the url I pasted, I think the dos and don'ts section makes it easy to spot check.
<hatch> luca__: btw it works stunningly (not a word) in FF now
<hatch> heh
<sinzui> arosales, the postgresql example is clearly missing the squircle and background
<gary_poster> hatch, cool, I think I see the issue you mean
<gary_poster> hatch lemme know if you think we should discuss trapping the scroll etc.
<gary_poster> hatch just finished call.  going to your call :-P
<gary_poster> Makyo, will probably be late ^^^
<Makyo> gary_poster, ack, lmk
<gary_poster> will do
<luca__> bac: are the assets from jamie ok?
<bac> luca__: except for the sprite/shadow issue.  haven't plugged them in yet.
<luca__> bac: ok, let me know
<bac> frankban: the code looks good but i haven't qa'd it yet.  did the changes you made address the issues i raised?
<frankban> bac: yes, the should fix constraints order and unexpected conflicts
<frankban> s/the/they
<bac> frankban: great
<bac> done frankban
<frankban> great, thanks bac
<luca__> Category results and Search results for browse mode can be seen here: https://docs.google.com/a/canonical.com/file/d/0B7XG_QBXNwY1LS04ZTUyeUk1bEU/edit?usp=sharing
<arosales> sinzui, ok. so well try to take a strong stance on the guidlines in the doc
<Makyo> jujugui call in 10 kanban now
<hatch> luca__: can you tell me what the width of the inspector panel is and what the gap to the right of the inspector is
<luca__> hatch: width is 290px
<rick_h> I hate testing autocomplete. Talk about a mess of integration. 
<hatch> bcsaller: your status bar branch shows numbers for the units but the mockups don't - sorry I forgot to include that in my comments
<luca__> rick_h: but auto-complete is one of my most beloved features ^^
<rick_h> luca__: it's coming, just writing tests around it is a pita
<rick_h> :P
<luca__> hatch: the gap to the right hand side of the inspector is 20px
<hatch> luca__: ok 20px all around, got it
<sinzui> gary_poster, we are doing some in-place changes to the webops deployment script to gather all the pieces (release tarball and npm cache) into the charm for the deploy. I agreed to add a upgrade hook to support unpacking the tarballs for future deploys
<gary_poster> jujugui call now
<sinzui> np, just an fyi that I we are working on the deploy now
<gary_poster> sinzui, you should not need the npm cache for non-dev builds; that may be a regression
<sinzui> oh!
<gary_poster> bcsaller, call ping
<gary_poster> jcastro, bug 1194866 has fix going into review very soon
<_mup_> Bug #1194866: Cannot deploy http://jujucharms.com/~marcoceppi/precise/discourse from GUI <juju-gui:Triaged> <https://launchpad.net/bugs/1194866>
<marcoceppi> \o/
<marcoceppi> I can finally stop getting pings :P
<benji> bac: I'm far from a CSS expert, but I'll be glad to pitch in once my branch is reviewed/landed.
<bac> thanks benji
<rick_h> here comes autocomplete: reviews please sinzui jcsackett hatch and luca__, if you want to peek to start writing up the UX issues. I wasn't sure on exact sizes of things in the result set. https://codereview.appspot.com/11126043
<rick_h> this is sans-categories for an initial stab
<hatch> bcsaller: did you see my comment about the status bar branch showing numbers?
<gary_poster> frankban, how goes the arm stuff?
<luca__> rick_h: I can check it tomorrow
<frankban> gary_poster: Start in 1 hour -> https://launchpad.net/~frankban/+archive/ppa/+builds?build_text=&build_state=all
<rick_h> luca__: cool. I look forward to the checklist to update :)
<sinzui> orangesquad, does anyone have 5 minutes to review https://code.launchpad.net/~sinzui/charmworld/sane-icon/+merge/174058
<abentley> sinzui: Sure.
<abentley> sinzui: Since abel is in the middle of changing it so we don't use the on-disk file, could you use from_bufffer instead?
<sinzui> oh, yes I can
<hatch> rick_h:  the 'reviewed' flag looks like a 'favourite' button, especially because the pointer changes to a cursor when you hover over it
<rick_h> hatch: k, but the new design moves the reviewed badge over to a * on the right so it's just a fact of the charm-token for today
<hatch> rick_h: it is a * on the right now though?
<rick_h> hatch: huw's branch is up for review doing that. 
<hatch> no I mean, it is right now
<rick_h> hatch: so it's pointless for me to make any UX mods to the charm-token for this design issue. 
<rick_h> hatch: ah, I don't have it locally in my branch atm I guess then
<hatch> the first thing I thought was "oh cool you can favourite charms"
<hatch> :)
<rick_h> hatch: ok, well we can toss that to design, but not sure what to do about that atm
<bcsaller> hatch: sorry, missed that, yes, it has numbers, some of the mocks did in the past. I think it makes sense to include them but if we get feedback otherwise its simple to remove. The ratios shown reserve minimum space for small segments so 9999 running units and 1 in error doesn't end up being 1 pixel. Because of that the numbers can make it clear if its 1 unit or 30 or whatever
<hatch> bcsaller: yeah - I can see an argument for both, I just wanted to point it out in case it was accidental
<hatch> rick_h: yeah maybe we can switch the star to a badge with two lions fighting over a steak
<rick_h> hatch: ooh, needs moar shark!
<hatch> ok ok - a shark can be jumping over the lions
<hatch> benji: review done
<benji> cool, thanks
<sinzui> abentley, I had a bad push, If you look at the MP again you will see the code now reads from the handle provides and on 1k is read
<sinzui> PS, the test actually shows the bare minimum to pass a magic match for svg
<abentley> sinzui: RULES suggests that this branch enforces a 96x96 valid svg, when actually, that's being left to proof.
<sinzui> abentley, right, that is what we want to do
<abentley> sinzui: R=me.
<sinzui> after todays discovery, we may want to do more like verify the same ids as the template are present, or check for the squircle and gradient elements
<rick_h> teknico: review inbound
<teknico> rick_h: thank you
<sinzui> gary_poster, bac, juju-ui, the production deploy failed because the charm wants an npm cache: https://pastebin.canonical.com/94238/  This happens juju-gui-source changes. Is there another config setting that makes it clear we don't need the npm-cache? serve-tests=false perhaps?
<frankban> gary_poster: the binary packages for i386, armel and armhf are now in ppa:juju-gui-charmers/devel . amd64 is still pending. I'd like to test the new packages before copying them in stable. I'll do that tomorrow morning
<hatch> bcsaller: nice fix for the units
<bcsaller> hatch: thanks
<rick_h> anyone aware of the status bar code? I'm getting test failures, but only on test-prod in the views.StatusBar stuff?
<rick_h> https://pastebin.canonical.com/94254/ I've make clean'd and runs fine in browser/debug. 
<gary_poster> benji, any quick fix for sinzui's report above?  This is high priority
<benji> gary_poster: sorry for the slow response, I'm eating lunch and need to get back to it, but the quickest fix I can see is to wrap the fetch in a try/except that passes on a subprocess.CalledProcessError
<gary_poster> ack thanks benji
<sinzui> really
<sinzui> We will accept a timeout? Wont that slow the charm deploy by minutes?
<gary_poster> sinzui, yeah, we don't need it for stable releases.  The proper fix is to not do it at all.
<rick_h> bcsaller: is the statusbar yours? If I move it to the list of 3rd party files to load in merge-files it works.
<rick_h> bcsaller: curious how you got it to land. :)
<sinzui> gary_poster, okay. I can wrap the call and put it up for review to unblock webops
<bcsaller> 207318
<bcsaller> 645310
<rick_h> focus daniel-son :)
<bcsaller> woah
<gary_poster> lol
<bcsaller> rick_h: it worked fine here
<bcsaller> but I'll add it to that list
<rick_h> bcsaller: I'm trying to submit a quick branch. I'll include it here
<bcsaller> and submit a trivial 
<bcsaller> ahh, thanks
<rick_h> bcsaller: I just wanted to sanity check I'm not missing something. 
<rick_h> bcsaller: since it must have gone through to land, but I can't get it to combine at all after multiple clean/clean-all's 
<bcsaller> I suspect I had the test server running already when lbox check ran and it used the built files? I've seen that work around this issue in the past
<hatch> few things are as irritating as a Y.View not firing a render event.....
<hatch> cc rick_h ^
<hatch> ehh?? :)
<rick_h> hatch: :/ ?
<hatch> the fact that a Y.View doesn't fire a render event....is very irritating
<rick_h> meh, I've not had that big a problem with it that I can recall.
<hatch> lies
<rick_h> now the AC widget...
 * hatch walks away
<rick_h> :P
<hatch> haha
<abentley> hazmat: Part of ingest permits the branch name to be either 'trunk' or 'trunk-1
<abentley> hazmat: What's the rationale for that?  Doesn't it make the charm store address ambiguous?
<rick_h> hatch: don't walk away, you're supposed to be reviewing my branch :P https://codereview.appspot.com/11126043/
<hatch> ohhh am I now
<hatch> 4000ln difs are too big :P
<rick_h> oh bah, conflicts
<rick_h> was like "wtf...4000 lines?!"
<rick_h> oh, and you've learned by now to ignore test/data/autocomplete.json :P
<hatch> haa yup
<rick_h> bcsaller: https://codereview.appspot.com/10839044 has the change if you don't mind peeking at the other 4 lines while you're in there :)
<rick_h> sinzui: jcsackett can I get a second on ^^ as well please?
 * sinzui looks
<teknico> I get three errors in trunk when running "make test-prod": http://pastebin.ubuntu.com/5865679/
<rick_h> teknico: see the discussion with bcsaller ^^, branch is incoming
<teknico> rick_h: great, thanks
<rick_h> teknico: just as fast as lbox can run its little heart out 
<hazmat> abentley, ignore it.. it was for a branch a legacy issue from the charm distro on lp i found on a single charm when doing the initial impl
<hazmat> abentley, s/ignore/yank
<abentley> hazmat: Excellent.  So from here on out, only "trunk" branches are considered.
<hazmat> i think there was maybe two charms that exhibited that problem and they were from natty
<abentley> hazmat: I'm hitting it with ~zulcss/charms/oneiric/nagios/trunk and ~zulcss/charms/oneiric/nagios/trunk-1
<rick_h> grrr, branch switching confusing lbox fml
<teknico> rick_h: how about another look? https://codereview.appspot.com/10888048/
<rick_h> teknico: loaded up right now
<rick_h> teknico: LGTM thanks for the test changes/fixes.
<teknico> rick_h: thank *you*! :-)
<rick_h> teknico: the fix for the test failures is landing
<rick_h> teknico: so pulling from trunk should be good for that now
<teknico> rick_h: great. it's a bit late now, so if someone else will give the gift of a review, I'll merge trunk and land this later
<rick_h> teknico: rgr, have a good night
<hatch> rick_h: just fyi I am reviewing your branch right now, it's just taking a bit
<teknico> rick_h: thanks
<benji> gary_poster: I'm back from lunch.  Is there anything I can do to help on the NPM cache issue?
<rick_h> hatch: thanks, yea, it's a pita branch. I'm pushing a fix for the template conflict currently now that the test fix is in trunk
<gary_poster> benji, yes, gimme one sec
<benji> k
<gary_poster> benji, ok here.  maybe guichat?
<benji> gary_poster: k
<hatch> rick_h: is this branch supposed to be QAable?
<rick_h> hatch: yes
<rick_h> hatch: once the confilict is resolved. The template won't compile until then
<rick_h> hatch: pushed update should be there now. 
<hatch> hmm ok - well the error I get is actually a 406 http error
<rick_h> hatch: OH! right, no. You have to change the api enpoint to staging. in the config to QA
<rick_h> sorry, my mistake on the instructions. 
<rick_h> hatch: it's waiting on a release to production on the back end currently. 
<hatch> hmm
<hatch> when is that going to be released?
<rick_h> http://staging.jujucharms.com/ to be exact
<rick_h> hatch: any time. sinzui was looking at getting into the queue to get a release today. Not sure if it'll happen today/tomorrow. 
<rick_h> hatch: so obviously I won't land it until the back end supports it
<hatch> ok I'm asking because it causes other errors to cascade which we obviously can't have in trunk
<rick_h> hatch: rgr
<hatch> will check your new code
<hatch> rick_h: although this could be good
<hatch> the code should be able to handle this failure without throwing a console error
<sinzui> rick_h, hatch. We are in the queue. there is an incident in front of us.
<sinzui> I think we will have webops attention again in 2 hours
<hatch> sinzui: that's fine - I'm just saying that the GUI code shouldn't break if the api endpoint goes down so the AC failure code should be able to handle that inevitability cc) rick_h
<hatch> so this was a blessing in disquise :)
<hatch> we caught the issue ahead of time
<rick_h> hatch: gotcha
<rick_h> hatch: though if the store goes down it's far from a silent failure as you'll not get this far to get an AC widget, but ok :)
<hatch> haha well maybe it will go down after they got this far ;)
<hazmat> http://www.zdnet.com/verizon-backs-ubuntu-smartphone-7000017954/
<hatch> bac: do you have a 'positioned' vertical scroll bar?
<hatch> er
<hatch> slider
<hatch> I am trying to figure out how far left to position the inspector
<hatch> the values in the mockup and from Luca were wrong heh
<bac> hatch: i do...but i'm not sure where exactly it is going to go
<hatch> hazmat: that's awesome news!!
<bac> hatch: won't know until i get the new assets in place
<hatch> ok I'll just place it whereever then, it's a single line fix in a follow-up then  I guess
<hatch> thx
<bac> no verizon on the island. :(
<hatch> no verizon in Canada either
<hatch> buuuut
<hatch> as soon as there is a north american GSM band phone then we r golden
<bac> gary_poster: hurrah, i found the issue.  it was coming from bootstrap and was not on the element i'd been looking at.  img max-width:100%
<gary_poster> yay bac!!!
<hatch> we are so close to removing bootstrap :)
<hatch> doesn't Verizon have a horrible track record of loading a TON of bloatware on their phones?
<bac> yes, vzn is notorious for that i hear
<hatch> I'm kind of curious how the ubuntu smart phone will manage carrier garbage and lock ins while keeping an open platform
<bac> hatch: you should join the CAG
<hatch> I'll bring with it my nation(see house) wide cellular network(see wifi)
<bac> gary_poster: look at little old caktus listed with the big boys: http://us.pycon.org/2014/
<gary_poster> bac cool :-)
<bac> apparently they did the site
<bac> per calloway
<hatch> past employer?
<bac> no, a local little consulting shop that sponsors python user group stuff
<bac> by local, i mean NC
<hatch> ahh
<hatch> Montreal....that's near me
<hatch> only a 3h flight....lol
<hatch> actually there is a js conf in Vancouver in November
<jcastro> hey gary_poster 
<jcastro> search is busted on uistage
<jcastro> the new one, 8086
<hatch> the manage.jujucharms.com is 503'ing
<gary_poster> jcastro, thanks much.  sinzui, ^^^ deployment?
<hatch> gary_poster: can you head to 8086 and quickly drag the bottom of the window up to see if there is a scrollbar ?
<hatch> it's like the resize event doesn't always fire
<hatch> and I am just wondering if it's just me
<gary_poster> hatch confirmed it sometimes happens
<hatch> alright thanks, looking for the cause
<sinzui> gary_poster, They are waiting on a revised charm. I am putting that together now.
<gary_poster> sinzui, ah ok, no I meant the fact that search is broken on 8086
<gary_poster> sinzui, jcastro wfm now.  jcastro works for you?
<hatch> jcastro: wow osx port of juju? well done
<gary_poster> sinzui, bug and possible "proper" fix here: https://bugs.launchpad.net/juju-gui/+bug/1200337
<_mup_> Bug #1200337: gui charm should only get npm cache when building <juju-gui:Triaged> <https://launchpad.net/bugs/1200337>
<gary_poster> sinzui, have not tested
<jcastro> Charm API server did not respond
<jcastro> is what I get
<sinzui> rick_h, your autocomplete changes are in production as of this minutes, but I think squid has cached some of the old representations
<jcastro> oh dude, hard refresh fixes that, got it
<gary_poster> ok cool thanks jcastro
<sinzui> gary_poster, rick_h, what is the state of the autocomplete branch. The changes just went into production. I was not expecting regressions, only new features for autocomplete
<sinzui> gary_poster, I expected your charm changes to be based on the stable charm: https://code.launchpad.net/~juju-gui-charmers/charms/precise/juju-gui/trunk
<gary_poster> sinzui, sorry, no, but you probably can apply the revision
<sinzui> oh, fab, yes I can thanks gary
 * Makyo -> lunch
<hatch> my fan sounds like an old 486 when it changes directions
<hatch> maybe it is.....
<jcsackett> jujugui: can i get two reviews of https://codereview.appspot.com/10944045/, please?
<jcastro> hey guys how long does it take for the gui to show a change in the store?
<jcastro> I just added a bunch of categories
<rick_h> jcastro: 15min ish
<rick_h> sinzui: AC is in progress. Needs another review and some updates from me. I figure to get it landed in the morning hopefully
<sinzui> okay
<jcastro> rick_h: thanks
<sinzui>  I can participate when I webops doesn't need me
<rick_h> sinzui: https://codereview.appspot.com/11126043/ is the in progress review
<jcastro> ok so now that I am using the search for all these fixes
<rick_h> sinzui: ok
<jcastro> I am totally confused on how to navigate
<rick_h> jcastro: ?
<jcastro> ok so I click on the juju button
<jcastro> then I browse by category
<jcastro> say apps
<rick_h> jcastro: so once you start searching you're done for. 
<rick_h> jcastro: there's work in progress to add some breadcrumbs/better nav
<jcastro> yeah I need a way to go back
<jcastro> oh ok
<rick_h> jcastro: but yea, known issue
 * jcastro nods
<jcastro> also
<jcastro> I does anyone know what we put in "file-servers"? 
<rick_h> jcastro: ceph? samba? I'm not sure tbh
<rick_h> jcastro: feel free to use the back button to help nav. It should work to get you where you were
<jcastro> yeah
<rick_h> time to mow the lawn...yay me
<sinzui> rick_h, looking
<rick_h> sinzui: cool, thanks. I'll have the updates requested first thing in the morning and will get hatch to ok before he gets sidetracked :)
<hatch> too late, I've already been sidetracked for tomorrow
<hatch> the moment when you realize fixing tests is taking longer than the code you wrote
<bcsaller> hatch: only when I TDD can I avoid that but my TDD skills are not always up to the task
<jcsackett> bcsaller: thanks for the review. jujugui, can i get one more review on https://codereview.appspot.com/10944045/
<benji> jcsackett: I'll do one.
<jcsackett> benji: thanks!
<benji> jcsackett: LGTM
<jcsackett> thanks, benji.
<bac> jujugui: i need reviews on https://codereview.appspot.com/11182044 please
<benji> bac: I'll take one
<bac> thx
<jcastro> hey sinzui 
<jcastro> can we make `juju deploy ubuntu` do the right thing? It's an old bug where the store can't handle "ubuntu" 
<hatch> heh too much awesome in "ubuntu" ?
<bcsaller> still need one review on https://codereview.appspot.com/11181043
<bac> thanks bcsaller and benji
<benji> my pleasure
<bac> benji: that other guy sure messes up your nick tab completion
<benji> heh
<sinzui> jcastro, I don't hack on juju. How is that broken? I assume it deploys a charm named ubuntu (that presumably is a vanilla install)
<jcastro> yeah it's just a blank server
<hatch> jujugui looking for two reviews https://codereview.appspot.com/11186043/
<bcsaller> hatch: I can take one
<hatch> thanks
<jcsackett> hatch: i can take the other.
<hatch> awesomer
<gary_poster> hatch I qa'd fwiw.  nice
<sinzui> jcastro, I think I found your bug about deploying ubuntu. It certainly is in the store: https://store.juju.ubuntu.com/charm-info?charms=cs:precise/ubuntu&stats=0
<hatch> great thx
<jcsackett> inspector is looking pretty cool.
<hatch> yeah it's coming together nicely
<gary_poster> hatch, bcsaller, interesting bug to explore next week: 1000-unit service in sandbox with simulator on is unresponsive every 1 second (delta push?).  Made a card.  inspector-specific
<hatch> unpossible!
<gary_poster> :-)
<bcsaller> gary_poster: yes, I've seen that too, the timeline profile does indicate its tied to the delta
<gary_poster> something fun to debug, hopefully nothing paradigm shifting
<gary_poster> huwshimi, whoa man, you are starting earlier and earlier :-)
<huwshimi> gary_poster: Morning :)
<hatch> maybe he is moving west
<hatch> :)
<gary_poster> Makyo was working on getting your branch landed again, working with fixes from rick_h IIRC
<Makyo> Juuust pushed.
<arosales> gary_poster, I see the apache2 icon is showing the category instead of the icon.svg
<Makyo> lp:~makyo/juju-gui/visual-update-4
<jcastro> sinzui: I wonder if the new add-machine command means we don't need it anymore
<gary_poster> arosales, AIUI there is a problem with that svg.  I emailed you and jcastro about it.  The category icon is actually a new improvement thanks to sinzui: it was simply not rendering any image
<hatch> gary_poster: bcsaller the 'overview' viewlet is being touched 1000 times every second
<hatch> this might be related to the d3 thingy
<gary_poster> Makyo, awesome thanks.  huwshimi do you want to take it from here, or what?
<gary_poster> I'd like to get it landed asap one way or another, and it sounded like it needed some important fixes
<huwshimi> gary_poster: Can do, let me take a look
<gary_poster> thanks huwshimi.  ping us when you want us to review or approve or whatever is appropriate
<hatch> updated the card
<sinzui> jcastro, my local deploy is of ubuntu is fine. (juju deploy ubuntu)
<gary_poster> benji, hatch, what do we need to do to get the destroy branch landed?
<Makyo> huwshimi, gary_poster I adjusted some things based on comments, but I'm not sure where the original stuff came from; take those or leave those as you need.
<benji> gary_poster: I need the linter to stop abusing me
<Makyo> s/stuff/design
<Makyo> I guess I can use my big programmer words.
<gary_poster> lol
<benji> it will land in just a few seconds
<gary_poster> benji, awesome thanks
<hatch> benji: ping me when it's up and I'll do another QA
<arosales> gary_poster, was that email sent today. I am not finding it. But  I will take a look
<gary_poster> arosales, no, not today, looking
<sinzui> arosales, The category issue that cause a non-existent icon to appears is in user data...outside of our control. We fixed that by filtering out categories we don't know about. As of two hours ago, icon.svg files that don't convince magic that they are genuine svgs are ignored
<sinzui> ^ this last change address that fact that apache2's charm has a png claiming to be an svg
<hatch> benji: I think you applied the pointer:cursor to the wrong element other than that LGTM
<huwshimi> gary_poster: What's your opinion on how to know which changes to make? Do I go by the designs or on the feedback in the review?
<arosales> sinzui, hmm the apache2 icon ~should~ have been valid, but I'll re-upload the one design sent
<huwshimi> gary_poster: (And that's not me trying to pick a fight, I'm just trying to figure out which changes to make...)
<gary_poster> huwshimi, :-)
<benji> hatch: indeed, thanks
<sinzui> arosales, does "file icon.svg" say it is an svg?
<sinzui> it says it is a png for me
<gary_poster> huwshimi, want to have an early call in guichat?
 * Makyo walks dogs quick (or not so quick - so hot, gonna have to hose them off first).
<huwshimi> gary_poster: Sure
<sinzui> arosales, while nautilus wont show me the icon for apache's icon.svg, it will if I rename it to icon.png
<arosales> sinzui, http://pastebin.ubuntu.com/5866259/
<sinzui> yeah I just did the same. We agree
<sinzui> arosales, I think I have the charm template. I can try making a replacement as I queue for you division
 * sinzui has great hope that gui will be deployed in the next 20 minutes
<arosales> sinzui, I am little confused as to why the browser isn't currently parsing the current icon.svg
<arosales> sinzui, but really what ever we need to do go get to to render correctly I am a +1
<sinzui> arosales, the browser did parse it. I saw it lied and decided not to get involved with a possible malicious vulnerability
<sinzui> It saw the icon is a lie
<sinzui> arosales, pngs don't scale well either
<arosales> sinzui, do you need me to commit a version  I got from design which should be the same thing.
<sinzui> arosales, if you have a genuine svg, then go ahead and commit it. If not, I can make something. I just found the official apache logo svg that I can use with the templte
<sinzui> gary_poster, you might need to sit down for this...
<gary_poster> sinzui, uh oh
<sinzui> gary_poster, juju-gui is deployed and the right version...
<gary_poster> sinzui, YAY!
<gary_poster> sinzui, thanks, and thanks to IS!
<sinzui> No one, not even webops can see the site at the ip it is deployed too
<gary_poster> lol
<gary_poster> ok
<sinzui> thedac will try to ssh tunnel into to see the site render with the proper UI
<sinzui> I need to file an rt to get the IPs public
<arosales> sinzui, I'll confirm the one design sent is a _real_ svg
<arosales> if not I'll get that one and re commit
<hatch> bcsaller: mind finishing up that review? :)
<bcsaller> hatch: sorry, got sidetracked with the perf issue
<bcsaller> back on it
<hatch> hey that's for next week :P
<hatch> was it the d3 thingy?
<hatch> no matter how much I try to prepare I'm always way behind on house stuff for a sprint
<bcsaller> hatch: no, not d3 :-p   It looks like sandbox calls sendDelta for each new unit in the loop which calls update for units which renders the template 1000 times for 1000 units
<hatch> ohh lol
<hatch> glad it wasn't the d3 thing, that thing is cool
<arosales> sinzui, uploaded an svg for apache. We'll see if that helps.
<arosales> gary_poster, sinzui thanks for the explanation there
<gary_poster> thanks arosales 
<arosales> gary_poster, icons and categories are looking better. But if design can get us some more we will add those.
<arosales> I'll do another check post what design is able to give us in terms of icons.
<benji> gary_poster: branch landed (finally)
<gary_poster> benji, yay thanks! :-)
<sinzui> gary_poster, thedac confirmed that the gui is operational in production. I am now creating an rt to ask that the IPs be public
<gary_poster> sinzui, even better, thank you :-)
<hatch> hmm I can't submit this branch
<hatch> it says it's out of date but there are no changes when I pull
<hatch> and it says it's up to date when I use bzr update
<hatch> yeah it's definitely out of date
<hatch> cleared it out and trying again
<gary_poster> hatch could you give me the link of your most recent header prototype again pls?
<hatch> http://jsbin.com/utitov/3/edit
<gary_poster> ty
<hatch> I haven't done any work on it since this morning
<gary_poster> ack
<hatch> just playing around with trunk
<hatch> the inspector is comign along really nice
<hatch> keehee
<hatch> I can switch between inspectors all day long watching that status bar move around :)
<hatch> simple things....simple minds I guess :)
<rick_h> gary_poster: reply inbound. Taking the boy to dinner, but please let me know if that doesn't clear up the discussion.
<gary_poster> cool, thanks rick_h !
<hatch> gary_poster: next task on my list? I was thinking of working on the header of the inspector
<gary_poster> hatch, sounds good.  that will move the scroll down to the bottom div?
<gary_poster> a bottom section I mean, sorry
<hatch> yeah so we would have Status and Settings, as well as the header with the icon and title visible at all times
<hatch> to match v7 design
<gary_poster> cool
<hatch> bac: really cool technique on the slider but why didn't you set the slider orientation to vertical instead?
<gary_poster> jujugui if anyone wants to come to the call with huw that would normally be in 16 minutes, please come now! :-)
<Makyo> New bug, hopefully small fix: #1200412
<_mup_> Bug #1200412: drag-and-drop: dropping a service on a non-drop target leaves the token appended to the body <juju-gui:New> <https://launchpad.net/bugs/1200412>
<huwshimi> rick_h: Sorry for the confusion about the home/back link. Any pointers on what I need to set to get back to the initial screen for the sidebar. Fire viewNavigate something...
<hatch> gary_poster: did you let slip that we are doing another Friday EOD release? :P
<hatch> bcsaller: so are you thinking of creating a throttling method for update?
<hatch> so it only allows the ux to update once per second?
<hatch> UI
<bcsaller> hatch: there are a few related fixes, that one and making sure the bindings list we generate is unique 
<hatch> ahh great great
<huwshimi> gary_poster: Do I need another lgtm or is the one from rick_h and changes from Makyo enough?
<Makyo> LGTM :)
<huwshimi> Makyo: Thanks :)
<hatch> Makyo:  huwshimi here ya go http://i.qkme.me/3v5d87.jpg
<Makyo> Pff hahaha
<Makyo> Meanwhile: http://blog.anguscroll.com/if-kerouac-wrote-javascript
<hatch> lol
<huwshimi> haha
<huwshimi> hatch: Can I just use that for all my reviews from now on then?
<hatch> lol
<hatch> maybe
<rick_h> huwshimi: yea, to get back we'll need to fire viewNavigate with a valid change object. We can bind that link in the events object for the view it's rendered in
<rick_h> huwshimi: did the viewmode controls changes make sense?
<huwshimi> rick_h: Yeah that was great, thanks.
<rick_h> huwshimi: ok, going to put the little guy to bed/bath. I'll check in if yuo need anything else. 
<huwshimi> rick_h: Thanks, I'll see how I go.
#juju-gui 2013-07-12
<rick_h> huwshimi: so thought about it and viewNavigate isn't needed. Home is just the hard coded path of either /sidebar or /fullscreen based on the isFullscreen param
<rick_h> huwshimi: so I'd just make the template have those links and not try to fire custom stuff
<rick_h> that is what we mean by "Home" right?
<huwshimi> rick_h: Well, the sidebar needs to be able to navigate back from the search results or a category without closing the charm panel...
<rick_h> bcsaller: still around?
<bcsaller> rick_h: yes
<rick_h> bcsaller: looking at your branch with the icon, does that work? We never have an icon value so wondering where it's binding to/from?
<rick_h> huwshimi: right, so on search results, home would purely be a link to /sidebar or /fullscreen. 
<bcsaller> The ghost inspector sets it from the charm data onto the service so it works in that single case 
<rick_h> huwshimi: or what is the 'charm panel'?
<bcsaller> we have notes that we need a more general solution
<huwshimi> rick_h: I think it would need to be "/sidebar/precise/ceph-12/"
<rick_h> bcsaller: right, I'm with you on notes. Known issue and Makyo hit it with his work to include an icon but wasn't sure how this fit
<rick_h> huwshimi: ah, gotcha.
<rick_h> bcsaller: ok, so you're getting it from Makyo's work then which is getting it from the Store if it has it. Cool
<bcsaller> rick_h: yes, its based on that work
<rick_h> bcsaller: cool, that helps. Thanks.
<rick_h> huwshimi: so it sounds like the only thing we're changing is clearing search. So yea, a viewNavigate with a change object of {search: false; query: {};hash: undefined} would reset it
<rick_h> or query: undefined I guess is simpler
<huwshimi> rick_h: Ah, that sounds promising.
<rick_h> that would leave the viewmode and the charmid alone which are the two parts you want to keep consistent
<huwshimi> rick_h: I was thinking of building this inside charm-search.js. But inside that file, and its corresponding template it doesn't have the isFullscreen variable. Any idea how I might get access there?
<rick_h> huwshimi: sec
<rick_h> huwshimi: I was thinking it would be part of the sidebar/fullscreen views and that has it. It could go in subapp/views/view.js 
<rick_h> and be shared between them. 
<rick_h> Now I guess, when does "home" show up? Is it always there? Or only during a search?
<huwshimi> rick_h: It only apears during a search (including viewing a category), or if you're viewing a charm in full-screen mode
<rick_h> huwshimi: who's rendering the html link I guess?
<huwshimi> rick_h: The HTML needs to exist in that header (hence me wanting to put it in charm-search.js)
<rick_h> huwshimi: oh, in the charm-search widget?
<huwshimi> rick_h: Yeah
<rick_h> huwshimi: ah, so the *right* way to do that then is to create a new event in the widget, like the "search changed" event now that's a "GO_HOME" event. Then anyone that creates a new Search() widget needs to bind to that event and fire the viewNavigate when it happs. 
<rick_h> huwshimi: just like the SEARCH_CHANGED event works now
<huwshimi> rick_h: OK.
<rick_h> huwshimi: hmmm...so then the trick is that you need to supress that link from the widget when it's not a search/charm details view. :/
<huwshimi> rick_h: I'll still need to know when to hide/show that control, but I guess I can do that in the parent view
<huwshimi> heh
<rick_h> huwshimi: yea, thinking. We've not really had conditional stuff like that. 
<huwshimi> rick_h: Yeah, there are a few other cases I'm going to need to do similar stuff to change headers etc. depending on the particular view
<rick_h> huwshimi: ok, so the subapp/browser/views/view.js has a charmID attribute. So if that's set you're looking at a charm. 
<huwshimi> (stuff outside the view content)
<rick_h> huwshimi: that gets you part way there. 
<rick_h> huwshimi: so you'd need to add a flag in the _renderSearchWidget based on if there's a charmID...and then the other one is if you're in search mode or not. 
<rick_h> huwshimi: well, you want 1) "isFullscreen and charmID is set...show the link"
<rick_h> 2) "Search results are being shown"
<rick_h> 1) you're set on
<rick_h> 2) I'm looking
<rick_h> huwshimi: you can check the filters object. 
<rick_h> huwshimi: the same View has a filters ATTR, if those are set to something you should be in a search. 
<rick_h> huwshimi: the only problem with that is we still have default filters set. We've not removed them in a branch yet
<rick_h> huwshimi: so those have to go as well. 
<rick_h> then if any fitler is set, you're doing a search. 
<rick_h> huwshimi: because in the filters is the query being search, or the category selected when viewing a category
<huwshimi> rick_h: This is looking like a job that would probably take a day. So might not be feasible once I've gotten through my other list of things...
<rick_h> huwshimi: k, yea. It's not as simple as I'd hoped because of the new conditional rules. 
<huwshimi> :(
<rick_h> huwshimi: the other thing is to always show a home link to start out
<rick_h> and add the conditions as follow ups
<huwshimi> rick_h: I'm guessing the search/categories bug I filed is probably not trivial either?
<rick_h> huwshimi: I don't think it's hard. I think the category links need a more specific viewNavigate change object. 
<rick_h> huwshimi: it's not clearing out enough stuff. 
<huwshimi> rick_h: OK, I might take a look at that later if I get a chance.
<rick_h> huwshimi: yea, basically in browser/browser.js in the _getStateUrl it's merging the filters where it sounds like it should replace the data. 
<rick_h> line 81, this._filter.update(change.filter);
<rick_h> it wasn an update so that as you changed yuor checkboxes in the filter it would add/subtract one item at a time. 
<benji> bac: I have finished walking through the email quagmire and am soon to reach the caffeine castle.  Once that journey is complete I can help you battle the CSS dragon.
<bac> benji: the css quagmire was holding up the branch you reviewed yesterday.  the problem was a setting being inherited from bootstrap.
<bac> benji: thanks, though.
<benji> oh, good!
<benji> I'll have to find a different dragon then.
<gary_poster> benji, other dragons available.  ping me :-)
<benji> will do
<gary_poster> please review and land Huw's most recent branch ASAP: https://codereview.appspot.com/11209043/
<bac> i'm reviewing the above
<benji> I'll do a review too.
<gary_poster> thanks
<benji> jujugui: it is known that dragging of service inspectors is completely broken?
<benji> I thought it was just the branch I am reviewing, but it happens on trunk too
<gary_poster> luca__, rick_h I am swamped with meetings this morning.  I just sent out an email about the priorities for today.  Please review.  Also, could you please discuss together the home/back button issue and the search interaction issue between categories and text?  For each of these I would like an expedient solution we can implement today in an hour and land, which may require discussion.
<gary_poster> rick_h, luca, I think these experiences are broken ATM, and my goal is to not be broken for this release.
<gary_poster> benji, service inspectors are not draggable in Luca's design.  We may want them to be draggable to demo variation ideas from MS.  "Flexible"
<bac> benji: http://uistage.jujucharms.com:8086/:flags:/serviceInspector/ is really borked
<gary_poster> is goal
<luca__> gary_poster: sure, I'll get in touch with Rick
<benji> gary_poster: in that case they are broken on the trunk because they are partially draggable ;)
<gary_poster> ok thanks
<bac> benji: do you see the inspectors being completely broken on huw's branch?  no content for most 'tabs'.
<rick_h> gary_poster: will do, I'm afk a little bit this morning but will try to meet up with luca
<benji> bac: nope, I didn't click on any of the tabs; let me look real quick
<benji> bac: yep, very broken
<bac> benji: i'm unsure what we're supposed to be looking for.  luca__ do you know?
<rick_h> sinzui: I'm still getting setup at the dealer here and might not make the standup. My branch for autocomplete is updated ready for final review by you and hatch. 
<rick_h> sinzui: will try to get into the call as there's some important stuff flying around atm. 
<sinzui> thank you rick_h
<hatch> benji: bac inspectors are not supposed to be dragable
<hatch> 8086 is also working as expected here
<bac> hatch: some content drags and snaps back.  is that expected?
<benji> bac: did you find out if the empty inspector tab issue was introduced on this branch or pre-existing in trunk?  If not I can test it quickly.
<bac> benji: i did not yet
<benji> bac: I'll take a look.
<hatch> benji: it's a known issue - it happens when you open the inspector too quick after deployment
<benji> ah, ok
<benji> race conditions are fun
<rick_h> run faster!
<luca__> gary_poster: me and Ale have just had a meeting with MS and he's very happy with the inspector
<luca__> gary_poster: there are some content changes but overall he was pretty positive
<gary_poster> luca__, awesome :-)
<luca__> gary_poster: said the new Juju looks f'ing amazing
<gary_poster> lol :-)
<hatch> bac: the dragging is not expected - that's not a known bug :)
<luca__> bac: gary_poster do I need to look at anything?
<bac> luca__: benji and i are looking at huw's branch https://codereview.appspot.com/11209043
<bac> luca__: the description references some visual changes you requested but doesn't state what they are.  if you know and can verify the fix that would be helpful
<luca__> bac: I can try to bar it
<luca__> bac: bzr
<luca__> bac: checking it now against the list of bugs I sent off
<gary_poster> luca__, I need to have some help from you with the expedient plans for home/back and search interaction, but I'm swamped and rick_h is afk.  I will ping asap, 'cause these are biggest risks remaining IMO
<gary_poster> I'm swamped on calls I mean
<luca__> gary_poster: ok, I'm available most of the afternoon
<gary_poster> thank you luca__ 
<rick_h> luca__: gary_poster hopefully I can be free in the next hour
<gary_poster> thanks rick_h 
<luca__> bac: gary_poster I can confirm that all of the bugs I submitted yesterday have been fixed in visual-update-5 apart from the 2 that have been stated in gary's email
<gary_poster> luca__, great, thank you!
<gary_poster> bac could you land when you are satisfied please?
<bac> gary_poster: if there are small issues with the branch you want me to just fix them then land, i assume.
<gary_poster> bac yes please
<bac> cool.  i'll wait for benji's input (if it isn't there yet)
<benji> bac: I just posted (not LGTM, unfortunately; big problem with the test runner)
<bac> benji: rt
<benji> bac: "rt"?
<bac> benji: 'roger that'.  i think i've referenced my helicopter pilot fantasy before?
<benji> heh
<benji> gary_poster: I'm ready for a dragon quest.  Should I take up that NPM cache issue?
<gary_poster> bac, did you mention to luca about whatever different assets we need for the zoom widget?
<gary_poster> benji no one sec
<benji> k
<gary_poster> benji, oscon tasks have highest priority today.  I sent email and have new "urgent" kanban section.  If bac could use help in fixing Huw's branch, that would be best use of time.  Otherwise see urgent section of kanban
<bac> gary_poster: what we have may work, though limited to a fixed size slider.
<benji> gary_poster: will do
<benji> bac: I described the problem with the body styling and test runner in the review, but I could easily work up a patch.
<bac> gary_poster: this page has an example using very similar assets. http://yuilibrary.com/yui/docs/slider/slider-from-markup.html  the issue is the lack of separate images for the rail and end caps
<bac> benji: i'll ping you if that'll be more efficient
<benji> k
<gary_poster> bac, ack. luca, ^^^ is that enough info to ask jaime for what we need?  AIUI, as a convenience it would be great if he could simply slice the images per the example above
<gary_poster> sorry, luca__ ^^^
<bac> gary_poster: there is also the possible issue of the thumb image being a sprite with embedded shadow.  unsure how much of this YUI skinning should be pushed to jamie
<gary_poster> bac, when you say "unsure how much" you mean we possibly/probably should not push it to him, because we will be better able to identify what we need?
<gary_poster> and it is simply a matter of slicing?
<bac> gary_poster: i'm saying YUI skinning has very specific requirements and it is unclear who should ferret them out.
<gary_poster> bac ok.  luca__ scratch that scrollbar request for now :-) thank you
<jcsackett> jujugui: head's up, i have an appliance repair dude showing up at 11, so i'll be absent for the retrospective. i don't see any cards i have a strong feeling about, so you shouldn't feel my loss very keenly. :-P
 * benji feels a vague sense of loss.
 * jcsackett laughs
<benji> gary_poster: I would ideally tackle one of the two criticals that have yet to be claimed.  They both list needing to be discussed, have they been?
<bac> benji: how do i reproduce the test failure you saw?
<benji> bac: its not so much a test failure, but a failure of the tests.  Run the tests, wait for them to end, try to scroll up, feel frustrated and listless.
<bac> benji: i ran 'make test-server' and i can scroll around a-ok in chrome.  what am i missing?
<bac> benji: but i do feel listless
<benji> bac: let me replicate it again, one second
<hatch> lol
<luca__> gary_poster: was dealing with something, is there anything you need?
<hatch> luca__: I think the 'reviewed' icons look like 'favourite' buttons
<hatch> just sayin :)
<luca__> hatch: your not the only one to say that, we are testing it on monday and tuesday with 10 users from the inductry
<hatch> rick_h: and I decided a better symbol would be two lions fighting over a steak with a shark jumping overhead
<luca__> hatch: +1 I'll get jamie to mock something up :D
<hatch> lol
<hatch> so huw's branch added overflow: hidden to the body, but something added overflow: auto to the element
<hatch> causing the scroll bar to re-appear
<gary_poster> benji, they have not yet been discussed.  not ready
<benji> k
<gary_poster> luca__, nothing I need right now thanks, till Rick is ready
<rick_h> luca__: ping for when you get time to chat
<gary_poster> ooh ooh!
<rick_h> gary_poster: too since it makes him so happy :)
<gary_poster> :-)
<gary_poster> I will join if I can but I have another call for now.  Very excited about possibility of getting a reasonable quick resolution to those issues though :-)
<benji> bac: I can't reproduce the error now.  I don't know what happened.  So you can disregard the patch part of that comment, but the part about removing the now-redundant code still applies.
<rick_h> hatch: would really appreciate if you can re-look at the AC branch this morning so I can get that in/up. 
<bac> benji: done
<rick_h> gary_poster: heh, don't get your hopes way way way way up :P
<gary_poster> :-/
<gary_poster> ok
<rick_h> sinzui: while I wait to get some time with luca__ did you want to chat for a sec for anything hangout related?
<luca__> rick_h: I'm free you need anything
<rick_h> luca__: ok, will send an invite one sec
<luca__> rick_h: hatch is this better for the reviewed icon? https://docs.google.com/a/canonical.com/file/d/0B7XG_QBXNwY1WWwyd2cyLWtrWWc/edit?usp=sharing
<gary_poster> luca__, LOL!
<hatch> BAHAHAHAHAHA
<luca__> hehe
<rick_h> luca__: https://plus.google.com/hangouts/_/0c7a8746abe1e765bf1f06cd256f317702da126d?hl=en
<gary_poster> antdillon hey https://plus.google.com/hangouts/_/b00dc841a3b70c4f357210452e531a462a28841a
<hatch> do it do it!!!!
<rick_h> luca__: O...M...G on the icon
 * gary_poster still giggling
<antdillon> gary_poster, Im there
<bac> jujugui: what are the steps to use lbox to submit another's branch?  how does it link my local branch to huw's MP?
<hatch> bac: are you going to land huw's branch that you NLGTM'd?
<Makyo> bac, -adopt, I think
<bac> hatch: catch up man.  I changed my vote.
<hatch> ohh lol ok well one second
<bac> Makyo: is that really all that is requried
<hatch> there is a breaking change in my QA
<Makyo> bac, no clue :D
<Makyo> bac, the docs for lbox are...well...
<hatch> what...there are docs for lbox? ;)
<bac> Makyo: i branched trunk into a 'review' branch then merged his branch in.  can lbox really link it all together?
<bac> 'lbox submit -h' isn't too clear on what happens.  guess i can try.
<bac> hatch: so i'm waiting on a review from you?
<hatch> bac: I just qa'd see my comments as one thing needs to be fixed before it lands in trunk
<bac> hatch: the overflow issue is resolved per benji's review suggestion
<Makyo> bac, I've never had the chance to try, I juist know the option exists.
<bac> Makyo: ditto.  i'll report back.
<hatch> bac: ohh ok - I thought that would do the exact opposite of what we wanted
<hatch> the bigger issue is the small charm config when not under the flag
<bac> hatch: i don't understand what you mean.  wanna chat?  might be fastest
<hatch> sure
<hatch> in guichat
<bac> hatch: rejoining
<hatch-mobile> bac sorry it all crashed, rebooting
<rick_h> bac: so when I did his stuff I just created a branch under my name, merged his stuff in, pushed to my account, and re-lbox'd it references his codereview url in a self-LGTM as the dicussion was over there and then submitted it
<rick_h> sinzui: ok, off that call, shifting up what I'm working on based on emails and such. Let me know if we need to sync up. 
<bac> rick_h: sweet, thanks for the details
<bac> but now i'm super curious about -adopt
<sinzui> rick_h, I see you have already claimed one of the important issues on the board
<rick_h> sinzui: so I put back those as they're considered lower priority than fixing the home button according to luca and gary_poster's email
<sinzui> yep, I saw you do that
<rick_h> the other things lower on the priority list are all dependant on removing the filters UI and the default filter settings. So they're nice to have but will be more work than EOD will allow
<sinzui> kanban doesn't tell you who is watching
 * rick_h feels stalked
<rick_h> :P
<hatch> bac: ok I'm back now but I have to set my env back up - were you able to reproduce with mysql?
<bac> hatch: no, it looks good to me
<hatch> ok one minute I'll set this back up
<Makyo> jujugui call in 10 kanban now
<bcsaller> hopefully my lbox submit finishes before then :(
<hatch> jsbin is down :(
<gary_poster> rick_h, hey, you still talking?
<rick_h> gary_poster: done talking atm
<antdillon> gary_poster, Oh forgot to say, I am off on Monday (its my stag do this weekend) I will be starting on Tues
<gary_poster> antdillon, oh cool, congrats and have fun. :-) see you Tuesday then.  Maybe we'll have more for you to work with by then :-)
<gary_poster> rick_h, mind joining guichat real quick to summarize plans for me?
<rick_h> gary_poster: yep one sec
<bac> hatch: you still rebooting?
<gary_poster> thanks
<hatch> bac: yup just booting up the env
<hatch> (i really gota setup a script for this)
<rick_h> gary_poster: joining
<gary_poster> jujugui call in 3
<hatch> bac take a look at my screen for the bug
<rick_h> hatch: sinzui https://codereview.appspot.com/11126043/ is updated, comments replied to, tests updated. let me know if there's anything else needed. 
<bac> benji: you still have huw's branch marked bad.  do you want another pass or just land with your dissent?
<benji> bac: I'll re-mark now
<bac> but it'll be a lie!  :)
<sinzui> rick_h, criss-crossed. You got my LGTM
<bac> gary_poster: that sounds like a good check for 'charm proof'
<adeuring> abentley: could you please have another look at https://code.launchpad.net/~adeuring/charmworld/get-file-content-from-bzr/+merge/173987 ?
<abentley> adeuring: Sure.
<abentley> adeuring: I don't understand "I chose to return the branch's directory instead of the branch itself because the directory is needed as an entry in the charm_data dictionary during test setup".  You can get the directory from the branch, as I explained.
<adeuring> abentley: I know, but that's not what is needed in tests -- it's the directory
<abentley> adeuring: So you're saying it was for convenience?
<adeuring> abentley: yes
<abentley> OK
<abentley> adeuring: at 103, you are patching BZR_EMAIL into the environment, but bzr_isolation should do that for you.
<adeuring> abentley: ouch, forgot hat... I'll fix it
<abentley> adeuring: r=me.
<adeuring> abentley: thanks
<sinzui> Bugger. webops are creating unversioned tarballs.
<sinzui> gary_poster,  or bac: Webops asked that we add an upgrade hook  to the juju-gui stable charm to handle cases where we want to deploy a new release of the app. This seams easy enough, but now I see the webops scripts create unversioned tarballs. There is never a config change to indicate to the backend to unpack the tarball.
<gary_poster> sinzui, the tarballs are always named the same?
<sinzui> yes
<gary_poster> :-/
<bac> yes, :(
<sinzui> I see other problems with their script
<gary_poster> sinzui, easiest solution is to add revid to the tarball name
<gary_poster> if unversioned
<sinzui> the source is hardcoded. They need to edit the script each deploy.
<sinzui> I'll propose a replacement script that makes it easy for them and us to do a deploy of just the app
<gary_poster> sinzui, cool, thanks.  is this documented on your wiki page?
<sinzui> No.
<sinzui> I got a pastebin copy of the script. https://pastebin.canonical.com/94228/
<sinzui> The version was changed yesterday to my request, but the script will need to be edited again for the next request :(
<rick_h> luca__: around?
<gary_poster> bcsaller, could you let me know what you think about in terms of difficulty of getting those export issues addressed?
<gary_poster> when you've had time, of course
<bcsaller> gary_poster: I'm reviewing them now, there are some questions, like qualified charm name, precise/mysql-1 or cs:precise/mysql, including rev, etc? Just not sure yet, making notes on some of the bugs
<benji> Makyo: what browser were you using when you saw bug 1200412?
<_mup_> Bug #1200412: drag-and-drop: dropping a service on a non-drop target leaves the token appended to the body <juju-gui:In Progress by benji> <https://launchpad.net/bugs/1200412>
<Makyo> benji, Chrome v28
<benji> Makyo: hmm, I'm running the same and I can't reproduce the symptoms listed in the bug.
<rick_h> luca__: take two, would love a sec to chat. 
<Makyo> Checking..
<luca__> rick_h: sure
<luca__> rick_h: got a hangout?
<rick_h> couple of ? for you luca. Hangout?
<Makyo> benji, hmm, quick chat so I can screenshare?
<benji> Makyo: sure, guichat is open
<hatch_> sorry was dc'd
<hatch_> reposting - bcsaller: re your 250ms comment - I'm OK with either approach just curious if you were planning on changing to rate limiting vs debounce or leave it for now?
<bcsaller> hatch_: I left it for now, I think it will be fine the way it is, but we can keep an eye on it
<hatch_> alright sounds good :)
<hatch_> why do I have to add my ssh key to be able to pull from our bzr repo...did it get locked down by accident? :)
<bcsaller> hazmat: ping
<hazmat> bcsaller, pong
<bcsaller> hazmat: can you check the comment in https://bugs.launchpad.net/juju-gui/+bug/1200625 and see if that export matches your needs
<_mup_> Bug #1200625: gui export is exporting invalid config options / not respecting type when serializng <juju-gui:New> <https://launchpad.net/bugs/1200625>
<bcsaller> that includes service output, annotations and config changes
<hazmat> hmm
<hazmat> i was going against uistage.jujucharms.com:8086
<hazmat> maybe that's not on a cron
<hazmat> bcsaller, might be some noise then.. your comment export looks good to me,
 * hazmat checks trunk
<bcsaller> hazmat: that export is from my current branch, I didn't change the options handling but the other things were changed, I have to propose this
<hazmat> oh
<hazmat> gotcha
<bcsaller> if it looks good then it should be ready
<bcsaller> but the options handling seemed sane out of the box
<hazmat> bcsaller, the yes/no thing correspond to booleans in yaml
<hazmat> but the type is a string
<hazmat> ie when that gets passed to juju core it will barf on debug setting
<bcsaller> sounds like an import error ;)
<hazmat> since it per the charm config schema it should be a string, but comes in as a bool
<hazmat> not really
<hazmat> its two bugs
<hazmat> sorry phone call
<hazmat> exporting default 
<bcsaller> its going out as a string here, the parse side translates it to a bool in implicit conversion which is wrong 
<bcsaller> wait, you don't want me to export if its the default value on the charm? more work but I can do that 
<sinzui> gary_poster, http://comingsoon.jujucharms.com/ is up
<gary_poster> awesome thanks sinzui!
<gary_poster> hey luca, you really here? :-)
<luca> gary_poster: just leaving
<luca> gary_poster: if you send me an email ill pick it up
<gary_poster> cool thanks luca ttyl
<hatch> rick_h: https://bugs.launchpad.net/charmworld/+bug/1200704
<_mup_> Bug #1200704: charm search autocomplete has slow options request times <charmworld:New> <https://launchpad.net/bugs/1200704>
<rick_h> hatch: cool, will put on the board. Thanks. 
<hatch> rick_h: I LGTM'd the branch pending the css fix as everything else looked good - the clickoutside if you can't fix we can follow-up with a fix on that
<rick_h> hatch: ok, will look into it in a little bit. Almost done with this home branch. A 'testing' we shall go...a testing we shall go...
<rick_h> curses, luca left
<hatch> high ho the dairy o a testing we shall go
<hatch> not sure what a dairy o is
<hatch> it's probably something horrible
<rick_h> gary_poster: I've got the home link branch up here. lp:~rharding/juju-gui/home-link I was hoping to get luca to look before he left but :( 
<rick_h> gary_poster: I also found a decent fix for the search/category issue and have fixed it in there. I'm working on tests to support the changes but if anyone wants to QA in luca's place I'd love to hear it's what's expected.
<gary_poster> rick_h, home link: thank you!  shoot him a mail.  he said he would be checking.  I'm sending him a couple too.  I'll look soon too, though if you are happy with it then I'm +1 on starting the review process.  search/category: even more awesome! I guess I'm the only one who can at this point unless you get luca's reply.  
<gary_poster> I will do so asap, though I have two emails I'm trying to plow through before then
<rick_h> gary_poster: ok, will shoot him an email. Tests will add a little time but trying to get it going and up for review asap. 
<gary_poster> cool thanks you!
<rick_h> gary_poster: understood, just a heads up on where we're at and such. 
<gary_poster> great
<hatch> rofl https://twitter.com/horse_yui/status/355741939955544065
<gary_poster> :-)
<gary_poster> hey jcsackett , one of our goals that I'd forgotten about was that, when on jujucharms.com, instead of seeing "log out," you would see ...something else that I forgot.  A link to somewhere.  Did you do that as part of your default view work?
<rick_h> time to acquire food, brb
<arosales> gary_poster, could you or bac add additional details to https://bugs.launchpad.net/charm-tools/+bug/1200713 when you have an opportunity
<_mup_> Bug #1200713: Charm Proof: Ensure the default configs match the defined type <Juju Charm Tools:New> <https://launchpad.net/bugs/1200713>
<gary_poster> arosales, bac, added
<arosales> gary_poster thank you.
<hazmat> bcsaller, yes re default
<bac> arosales: done too
<bcsaller> hazmat: thats fine but it only masks this issue, doesn't prevent it
<hazmat> bcsaller, re serialization in general, it would be good to cast to the specified config type as well. arguably its  a bug in core and one in the charm
<bcsaller> yeah, re core
<hatch> bcsaller: I see when you added the icon to the inspector you used the databinding for the header information
<hatch> that information is not supposed to be in a viewlet
<hatch> can you think of a way to bind to the fields without requirng a viewlet?
<bcsaller> hatch: VC owns databinding, its can either add a slot for header with the viewlet or add the databinding with addBinding directly 
<bcsaller> I think a slot and a viewlet make sense, its just a slot we always show
<hatch> hmm
<hatch> yeah slot probably does make the most sense as far as separation of concerns is.....concerned
<hatch> will do that, thx
<benji> jujugui: small branch to fix a drag and drop issue: https://codereview.appspot.com/11138044
<bac> benji: i'll do one
<benji> thanks
<hatch> benji: got it
<benji> great
<hatch> position fixed on the body eh? heh
<hatch> I foresee issues in the future
<bac> benji: why is that overflow still in service.js?  it should've been removed in trunk
<benji> bac: it may have been a race with me branching.  I should have merged in trunk before proposing.  I'll do that now.
<bac> benji: doesn't lbox produce a diff against trunk?
<bac> i mean, you shouldn't have had to do anything.
<benji> <shrug>
<benji> I'm re-proposing the merged branch now.
<hatch> benji: I'm doing a QA, which revno are you on?
<hatch> just to make sure I have the right one
<Makyo> lbox produces a diff against :parent, which points to a revision of trunk.
<Makyo> That way new code doesn't show up as deleted.
<benji> hatch: 824; it's still in the process of proposing
<benji> hatch: ok, it's finished proposing
<hatch> got it thx
<bac> benji: cool, your diff is much smaller now
<benji> good
<hatch> benji: QA fails spectacularly
<benji> hatch: how so?
<hatch> drag and drop (so fixed gets applied)
<hatch> then d click on the inspector
<hatch> dclick on the service
<hatch> to view the fullpage inspector
<hatch> also the ghost inspector panel is way off position now
<Makyo> hatch, ghost inspector is way off position for me in trunk.
<hatch> ohh
<benji> hatch: double-click on the ghost inspector?  That doesn't appear to do anything.
<Makyo> Er.. as in clipped at the bottom; I'm not actually following along, sorry.  I'll keep my yap shut if that's not the case.
<hatch> sorry I meant dclick on the service after deployed
<hatch> ^ benji
<hatch> Makyo: the ginspector is probably 100px down from the top nav
<hatch> similar on trunk?
<hatch> it looks proper to me on trunk
<benji> hatch: gotcha, yep that's a bug.  I think I have a fix.
<Makyo> ~20px here, but it's clipping over the bottom bar.
<hatch> Makyo: ahh yeah that happens to me if I shrink my window too
<hatch> the overlap
<Makyo> hatch, running full screen full HD here.
<hatch> benji: I'm concerned that applying position fixed to the body is going to cause us more issues
<hatch> as fixed pulls it out of the flow of the page
<hatch> which can cause render performance issues too
<hatch> (not sure if they apply here)
<benji> hatch: yep, my fix is going to be to remove the fixed style after the drop, so it will only be applied while dragging
<benji> I'm open to other ways to keep the window from scrolling during a drag, but I haven't been able to find a sane one
<hatch> benji: so why doesn't the overflow: hidden on the body work? what am I missing? It appears to work as expected here
<benji> hatch: because if you drag down to the bottom (or right) of the window, the body will scroll
<hatch> hmm cannot repro - trying in Ubuntu
<hatch> nope
<hatch> OHHH
<Makyo> I can repro.  No scrollbars, just works the same way as other hidden, where if you select and drag.
<hatch> I see now
<hatch> man this DD is suck a mess
<hatch> (not your fault benji) :)
<hatch> such*
<hatch> Makyo: how are you handling dropping off the drop target?
 * hatch is curious
<Makyo> Not sure what you mean.
<gary_poster> uh
<gary_poster> not sure how I left
<gary_poster> jcsackett, you around?
<hatch> well when you drop a service off the drop zone, to remove the thumbnail
<hatch> I thought you were working on that...
<hatch> I could have been wrong :)
<Makyo> hatch, no, working on left hand panel for unit view.
<hatch> gary_poster: that happened to me 3 times today heh
<gary_poster> hatch benji was doing that
<hatch> ohhh ok
<hatch> ohhh
<bac> benji: done
<bac> gary_poster: looking for a task.  i can start the slider skinning but don't think it is landable today.  thoughts?
<gary_poster> looking bac
<hatch> bac: QA'd ok?
<hatch> should I re-make my branch?
<bac> hatch: yes.  i reproduced the problem on uistage but not in benji's branch.  did i miss something?
<hatch> hmm intersting - the full screen inspector views are all broken for me
<hatch> will try clearing cache and remaking
<bac> hatch, benji: the problem i saw on uistage was the body scroll up leaving a void.  doesn't happen with fix.
<hatch> ohh so you didn't QA the rest :)
 * bac thinks we could all write better merge proposals
<gary_poster> hatch, bac, Makyo any of following would be good to do:
 * bac describing the broken behavior
<hatch> bac: the merge proposal is fine - but it introduces a regression
<gary_poster> - QA Rick's branch (I can do that now I think)
<benji> gary_poster: I wasn't working on the garbage icon; I can take a look.
<hatch> so that's why we need to do a more thorough QA
<gary_poster> - sticky header icon
<bac> hatch: by 'better mp' i mean explicitly state the problem for people doing qa
<gary_poster> benji, bug 1200412?
<_mup_> Bug #1200412: drag-and-drop: dropping a service on a non-drop target leaves the token appended to the body <juju-gui:In Progress by benji> <https://launchpad.net/bugs/1200412>
<gary_poster> maybe I misunderstood the conversation, sorry
<gary_poster> - charm title ellipsis
<gary_poster> - CSS transitions
<bac> hatch: but you're right, i tried to exercise his problem but didn't do full qa of the app
<gary_poster> bcsaller, do you have the feedback you need from Kapil about the export issues?
<Makyo> For this next week, gary_poster ?  Don't want to switch now.
<bcsaller> gary_poster: I think so yes, it looks like we want some special processing around service options which is in progress, the rest already appears correct in my branch
<hatch> bac: this brings up a good question - should the reviewers be required to do that qa? or should the author of the proposal?
<gary_poster> Makyo, ack.  sorry, I was not clear that we could/should put aside inspector tasks if you've only just started.  My fault.  as you were--keep doing what you are doing
<bcsaller> gary_poster: even with the special processing for options though the real issue will still be in core
<rick_h> abentley: ignore my comment on that bug, I mis-read it at first. 
<benji> gary_poster: nope that bug is about scrolling; well that's the way I interpreted it, the scrolling breaks the app and is ugly, the left over icon isn't worth worrying about in my opinion.  People could drag hundreds of icons into non-target parts of the app and not be an issue
<bac> hatch: author should but he can't be trusted so the reviewers should.
<hatch> lol
<abentley> rick_h: sure thing.
<hatch> so after 3 qa's we better not be introducing any regressions lol
<gary_poster> bcsaller, ok cool thank you
<gary_poster> hatch, bac, not sure each review should be full exploratory review
<gary_poster> exploratory testing I mea
<gary_poster> n
<bac> gary_poster: the ellipsis card says you have some secret sauce
<gary_poster> bac, barely. was hoping luca could provide.  However...
<bac> gary_poster: i just meant to say if anyone is going to do it, it should be one of the reviewers.  as a developer i am a very tender QA person so i am not to be trusted, and i suspect others may have the same affliction.
<gary_poster> bac ack
<hatch> *note to self - get bac to review my horrible code*
<hatch> :P
<bac> hatch: no, i'm very thorough with other's code!
<hatch> ohhhh I see, you just let yourself off easy
<hatch> ;)
<bac> yessss
<hatch> haha
<gary_poster> hatch, could you review https://codereview.appspot.com/11138044/ pls?  want to make sure you don't have secret sauce about deleting elements there 
<hatch> gary_poster: I did, it failed QA , benji is working on the fix now
<gary_poster> hatch ok thaks
<gary_poster> rietveld is weird
<hatch> weird, or broken? ;)
<hatch> I swore that it used to tell me which areas I had commented on without refreshing
<hatch> then one day it just stopped
<hatch> *use tests to write code - who needs docs anyways!*
<benji> hatch: the branch has been updated
<hatch> awesome!
<hatch> pulling
<sinzui> thank you gary_poster, I did my Mp in the wrong order...I create the reitveld review request afterwards. I will remove it since the Lp MP was sufficient
<bac> gary_poster: so is the goal to have charm title in charm browser be a single line with ellipsis or two lines with ellipsis? if the former then 'postgresql-psql' would be one affected.
<gary_poster> cool sinzui
<gary_poster> bac single I think
<bac> gary_poster: k
<hatch> benji: nogo (sorry :( ) see review for the comment
<benji> hatch: thanks
<benji> I'm going to eat a late lunch now.
<hatch> I swear I'm not trying to be a pain
<hatch> :)
<benji> :)
<hatch> benji: alright - I am meeting some friends for lunch in about 30mins so just push up wheever you get to and I'll get to it as soon as I get back
<hatch> pending of course you find a solution
 * hatch contemplates making Benji a drag and drop dart board
<rick_h> hatch: bcsaller jcsackett anyone up for a review please? https://codereview.appspot.com/11224044
<rick_h> gary_poster: ^^ that's the home stuff
<hatch> Oh Kay
<gary_poster> thanks rick_h 
<rick_h> sinzui: I'm not 100% sure I can get autocomplete landed. We've hit yui3-skin-sam issues and a bug in clicking off AC suggestions. Will work on that here, but not sure how long I've got. 
<rick_h> yay long running branches that pick up more issues the longer it lives
<sinzui> indeed they do.
<gary_poster> rick_h, sinzui I've seen a few core charm browser issues too; and have been trying to ask jcsackett about a change I had forgotten about
<sinzui> rick_h, I think you are EoD
<gary_poster> yeah I was wondering about that :-)
<rick_h> sinzui: I've got some extra time today since I was afk this morning. 
<gary_poster> oh cool
<rick_h> gary_poster: what's that?
<jcsackett> gary_poster: what change is that?
<gary_poster> yay jcsackett!  ok first you
<gary_poster> we were supposed to make it so that, on jujucharms.com, logout button was replaced with [something I forget, maybe a link].  Was that part of your changes?
<gary_poster> I mean, the changes to set default view and stuff
<sinzui> rick_h, we let's emphasise quality and stability. I would rather postpone autocomplete if the effort to get it production ready would delay of issues we want in production early net week
<rick_h> sinzui: rgr, just wanted to give you a heads up. If the css issues are lighter than they look, and a workaround for the d3/svg/click bubbling is available in the next hour or so I'll try to get it landed. It's qa'd ok aside from those 
<rick_h> and I understand home/etc was higher priority so will get that landed before EOD if possible
<sinzui> understood
<gary_poster> rick_h, ok you now :-)
<gary_poster> I will qa in a sec but these are core charm browser issues I found.
<rick_h> gary_poster: woot
<gary_poster> (1) go to http://uistage.jujucharms.com:8086/fullscreen/search/precise/cinder-8/
<gary_poster> (2) click on Browse
<gary_poster> I get "Failed to load search results.
<gary_poster> Charm API server did not respond:
<gary_poster> "
<gary_poster> Another one...
<rick_h> gary_poster: hold up, I can't dupe
<jcsackett> gary_poster: no, that wasn't communicated in the card i had. all i've ended up doing was setup the option for fullscreen to be default and expose that as a config for the charm.
<gary_poster> rick_h, cool, will clear cache
<rick_h> gary_poster: clicking on browser does nothing for me. 
<rick_h> gary_poster: did you mean search? or something else?
<gary_poster> rick_h, oh sorry I meant build
<jcsackett> gary_poster: i can possibly take care of that change on monday, if i get more specifics.
<hatch> gary_poster: rick_h: I can repro
<rick_h> gary_poster: ok, known issue with bad charm and the work for that is in progress
<gary_poster> jcsackett, ack I'll try to dig it up
<gary_poster> thanks jcsackett 
<hatch> rick_h: it's an access control origin issue
<jcsackett> np.
<rick_h> gary_poster: though to be fair, how did you get to that url to start with?
<rick_h> hatch: no, it's an upstream error in the api because of bad data. See bug #1199780
<_mup_> Bug #1199780: search requests errors when a charm has no last_change <charmworld:Triaged> <https://launchpad.net/bugs/1199780>
<hatch> the browser is looking awesome btw :)
<rick_h> hatch: any search for "all charms" will error right now
<hatch> ohhh ok
<rick_h> due to that issue
<rick_h> gary_poster: ok, so 2) ?
<gary_poster> rick_h, my other story is how I got to that story actually.  so...
<gary_poster> (1) go to http://uistage.jujucharms.com:8086/precise/cinder-8/
<gary_poster> rick_h, scratch that, it is http://uistage.jujucharms.com:8086/fullscreen/precise/cinder-8/
<rick_h> gary_poster: rgr
<gary_poster> (2) search for cinder
<gary_poster> (3) click on cinder in results
<gary_poster> nothing happens
<rick_h> gary_poster: yea, that's a bug. 
<gary_poster> rick_h: Variant of that
<gary_poster> (1) go to http://uistage.jujucharms.com:8086/fullscreen/search/precise/cinder-8/?series=precise&text=cinder&type=approved
<gary_poster> (2) click on cinder
<gary_poster> nothing happens
<gary_poster> well, the url changes
<rick_h> gary_poster: right, that url change is a bug as well in the routing 
<gary_poster> cool
<rick_h> gary_poster: see #1199392
<_mup_> Bug #1199392: can't view fullscreen charm details from url <charmbrowser> <juju-gui:Triaged> <https://launchpad.net/bugs/1199392>
<rick_h> gary_poster: but that first variant is legit. I'll file a bug on it now. Should be some corner case around the state deciding what view to show. 
<rick_h> gary_poster: e.g. easy fix once found
<gary_poster> rick_h, cool thanks.  ok, going to look at your home branch...
<rick_h> gary_poster: #1200743 for tracking purposes. Thanks for the nice repo instructions
<_mup_> Bug #1200743: complex search/view interactions in fullscreen fail to work <charmbrowser> <juju-gui:Triaged> <https://launchpad.net/bugs/1200743>
<gary_poster> cool thank you!
<rick_h> sinzui: any word on the misbehaving charm data bug? I thought I heard something about abel's work might fix and saw he got a branch into review today?
<rick_h> sinzui: sorry to bug you but I don't see any card for him on the board
<hatch> rick_h: I'm about half way through review (then to QA) but I have to take off now for lunch, so you might be past EOD by the time I get it done, is that ok?
<sinzui> rick_h, he didn't get his branch landed. He was concerned about a corner case
<rick_h> hatch: yea, don't worry. I'll make sure I get it through before I hit bed tonight
<sinzui> rick_h, I will ask webops to delete the branch that is not a charm
<hatch> ok great
<rick_h> sinzui: ok, no problem. Just wanted to let gary_poster at least one of his three bugs was close to working :)
<rick_h> one easy fix, and one's a pita wheeee
<rick_h> I feel the need to get a 'bug hunting' fun to drop on the desk for times like this 
<gary_poster> :-)
<gary_poster> rick_h, I merged your branch with trunk and got conflict.  http://pastebin.ubuntu.com/5869067/ (tree is trunk,merge-source is you).  should I really delete that padding?
<rick_h> gary_poster: sec, looking
<rick_h> gary_poster: so I think that neesd to stay? I didn't add that code so guessing we both added at the same spot?
<gary_poster> rick_h, cool agree
<gary_poster> rick_h, with a similar level of confidence ;-)
<rick_h> I'll pull trunk here locally and merge in and make sure things are resolved
<rick_h> gary_poster: ok, wtf. I edited the file 30 lines below...no idea why bzr hates me
<gary_poster> :-)
<sinzui> rick_h, we will now wait for ingest to notice the empty branch is gone
<rick_h> bcsaller: thanks for the catch. I had a container.one vs a container.all on the event for that. Updating and adding another test now
<rick_h> gary_poster: so the Home link doesn't work :) but will in a sec
<bcsaller> thats an easy one to make, ha ha, get it ;)
<rick_h> ho ho ho ho
<gary_poster> cool rick_h 
<bcsaller> enough punishment 
<jcsackett> rick_h: sounds like you're addressing the one thing i found in my review. :-P
<rick_h> jcsackett: yep, pushing now, will have to wait for lbox to go through again before it shows up in reitveld
<bac> gary_poster: css-only ellipsis works for that field.  \o/  i now see that no one appears to be using gallery-ellipsis any more.  i'd like to rip it out.
<gary_poster> bac +1
<bac> gary_poster: will do in two branches
<gary_poster> bac +1
<jcsackett> rick_h: yay, lbox.
<jcsackett> it has been very slow for me today.
<rick_h> crap, now test failures. looks like something is cascading down
<gary_poster> rick_h, I see a number of issues--did you address them in the merge/update?  example: (1) http://localhost:8888/fullscreen/ (2) search for glance (3) click on glance. Problem: competing home links in header.  Example 2: (1) go to http://localhost:8888/ (we really can't hide the home link just on the home page, trivially? :-/ ) (2) search for mysql. Problem: a line covers up "search results"
<rick_h> gary_poster: looking, fighting test failures atm now. Will look at those in a sec. 
<gary_poster> rick_h, cool, sorry
 * benji dives back into the drag and drop swamp.
<rick_h> gary_poster: looking at issues. Thanks 1) is from breadcrumbs work. Looking for where huw put that since he didn't put it in the widget here. 2) there might be a hacky way, but nothing that I'd like to see live in trunk. 3) Looking into that. I'm double checking to see if that border rule can come out all together.
<sinzui> rick_h, the query is fixed in production and staging.
<rick_h> oh come on, he freaking absolute positioned the breadcrumbs way out of the View itself?! 
<rick_h> sinzui: awesome, thanks. 
<rick_h> gary_poster: I'm going to pull breadcrumbs right now. They're only on the charm details view and in a wrong place. 
<rick_h> gary_poster: any complains on trading Home link for breadcrumb on charm details?
<rick_h> complaints that is...ugh
<sinzui> abentley, rick_h, I took this opportunity to measure the time of deletion to ingestion, and cache clearing. Ingest takes 17 minutes in production. The search/cache was fixed within a minute of ingestion
<rick_h> sinzui: very cool. 
<abentley> sinzui: That is scary, because we ingest on 15 minute cycles.
<bac> jujugui: get the easiest review of the day here: https://codereview.appspot.com/10964045
<sinzui> abentley, We changed production to be just-in-time cycling I thought
<benji> bac: I'll take a look.
 * sinzui looks for rt
<abentley> sinzui: I assume production still runs enqueue every 15 minutes.  If it's doing it more often, then we're in really big trouble.
<benji> I learned a new term that I really like over lunch, the "grep test": http://jamie-wong.com/2013/07/12/grep-test/
<sinzui> abentley, worker-interval=1 in m.jc.com
<abentley> sinzui: So if I understand you correctly, we're filling the queue every 1 minute, but it takes 17 minutes to remove that from the queue.  Is that right?
<sinzui> abentley, I thought we had changed the process to get a lock  so that the queue would not be appended to while the lock was kept
<gary_poster> rick_h, I don't think so?
<gary_poster> rick_h, that's a step up, right?
<rick_h> gary_poster: I think so. That's updated, #3 is corrected as well. Just fighting test-debug and delegate for a final update. 
<abentley> sinzui: I don't know anything about the locking.  If so, we should be fine.
<sinzui> Do I dare go into #webops one more and ask for the count of what is in the queue?
<bac> jujugui: one more for https://codereview.appspot.com/10964045/ ?
<sinzui> maybe I should get a job as a webop
<gary_poster> bac, will look.  code looks fine; will try qa :-)
<sinzui> oh, I could put together the diagnostic page to tell us that all process are operating and what their size/capacity is
<rick_h> oh I'm a moron...ugh
<rick_h> gary_poster: updated branch pushing now. 
<gary_poster> bac LGTM
<bac> thx
<gary_poster> cool rick_h .  so it has fixes for #1 and # 3?
<rick_h> gary_poster: correct
<rick_h> gary_poster: looking close for #2, maybe a temp hack with an XXX
<gary_poster> rick_h, cool.  +1 on temp hack for #2.  pretty important to visuals to hide I think
<bac> sinzui: why does searching for 'postgres' not return 'postgresql-psql' ?
<gary_poster> bac postgresql does.  apparently not partial text
<gary_poster> discovered as well
<bac> oh
<rick_h> yea, search doesn't do paritals atm
<sinzui> bac, elasticsearch is not configured to search substring
<sinzui> bac, but it is configured to do that on autocomplete cases
 * gary_poster is happy with new alias:
<gary_poster> alias bzrevert='bzt revert && bzt revert --forget-merges'
<gary_poster> where bzt == bzr
 * bac bzr help revert
<bac> er, bzr revert help
<abentley> gary_poster: Since revert automatically forgets merges, I don't see the advantage of this.
<gary_poster> abentley, oh, it doesn't/didn't for me
<sinzui> abentley, ingest could has a lot of steps that are surely collecting redundant data. If the branch has not changed and proof has not changed, don't run proof. The same is also true for jenkins.
<gary_poster> abentley, perhaps this is merely remembered or even misremembered pain.  willinvestigate later
<abentley> gary_poster: If you revert a particular file or directory, it won't forget merges.  Otherwise, it will.
<sinzui> abentley, quick look, these have ingest times: http://manage.jujucharms.com/tools/store-missing
<gary_poster> abentley, cool thanks
<sinzui> looks like this phase is exactly 15 minutes
<abentley> sinzui: what about cs:~benji/precise/juju-gui ?  Looks more like 12 minutes to me.
<sinzui> yeah
<sinzui> we are network bound for Lp and jenkins so we can expect variations
<abentley> sinzui: Anyhow, I guess the locking acts as a de-facto ingest delay.
<abentley> sinzui: There is *lots* we are doing redundantly.  Like ingesting the charm files.  Every. Single. Time.
<sinzui> abentley, we clear the queue with every deploy, so al is we is we deploy often.
<rick_h> gary_poster: can't. Even an XXX hack will not work since the height is hard coded, the widget isn't redrawn in a search content vs a home context to catch the update. 
<gary_poster> rick_h, :-( I dunno if it is ok to land if it is on home. :-(  other issues are fine btw, though I think breadcrumbs will be better in future when we replace.
<gary_poster> I mean, I ad t
<gary_poster> qa'd
<gary_poster> it
<rick_h> gary_poster: definitely agree on breadcumbs. 
<rick_h> gary_poster: just not enough time to get it in there right atm. 
<gary_poster> ack
<rick_h> gary_poster: luca signed off on permanent home. I made sure to express to him that was the result of getting it in.
<gary_poster> rick_h, oh, you mean getting it at the top?
<gary_poster> sorry that made no sense
<gary_poster> other than <surprise> ;-)
 * rick_h isn't following still
<bac> jujugui: and another exciting review.  almost 500 lines of deletions.  https://codereview.appspot.com/11216044/
<rick_h> gary_poster: guichat?
<gary_poster> bcsaller, btw you should probably tell us how to qa service-options-viewlet branch
<gary_poster> rick_h, +1 thanks
<bcsaller> gary_poster: It was something I saw when looking at the home-link branch, but there may have been another issue there, the charm I thought would trigger it didn't on trunk just now
<rick_h> bcsaller: jcsackett updates up there
<jcsackett> rick_h: ack.
<jcsackett> rick_h: i'm seeing you completely removing the home button now, but not adding it back anywhere.
<rick_h> jcsackett: huh?
<gary_poster> rick_h, I ended up by saying everything was looking great :-)
<rick_h> gary_poster: ah, cool. Thanks, trying :)
<rick_h> jcsackett: you mean the event catch? It's changed to a delegate that catches both cases
<rick_h> jcsackett: and both of them are tested in the tests now
<rick_h> jcsackett: if you mean something else let me know 
<gary_poster> bcsaller, ok so I should just to code lgtm?  bac you need review too?
<jcsackett> rick_h: i am looking at the template.
<bac> gary_poster: i do, should be cake
<jcsackett> ah, rick_h, ignore me.
<jcsackett> wrong template.
<rick_h> jcsackett: ah yea, that' the breadcrumbs huw added I removed since they conflict
<jcsackett> rick_h: i was looking at where you ripped out breadcrumns.
<bcsaller> gary_poster: yeah, I think its a win, somehow that triggered before and you'd get an empty inspector.
<gary_poster> cool, on it
<gary_poster> bac, how was it actually turned on, anyway?
<bac> gary_poster: how was that ellipsis code used?
<rick_h> bcsaller: can you peek at the review now that the one/all issue is adjusted? https://codereview.appspot.com/11224044/
<bcsaller> sure
<rick_h> bcsaller: changed to .delegate and skip all that one/all business :)
<bcsaller> good call
<gary_poster> bac, I mean, what was the mechanism to turn the ellipsis code on?
<bac> gary_poster: like this:
<bac>  container.all('.charm-summary').ellipsis({'lines': 2});
<bac> gary_poster: you can see it in action with 'bzr diff -c 245'
<gary_poster> bac cool thx
<gary_poster> bac LGTM get somebody else :-)
<gary_poster> benji how did drag thing turn out?  did you get that landed?
<benji> gary_poster: nope, stilly trying to fix very subtile breakage
<gary_poster> benji, :-/ k.  when do you give up? :-)
<benji> soon
<gary_poster> k
<gary_poster> lemme know
<benji> k
<bac> benji: subtile, like in subflooring?
<rick_h> cement board
<bac> ha
<benji> heh
<rick_h> very nasty buggy stuff
<bac> is that the same as mud board?
<bac> jujugui: one more for https://codereview.appspot.com/11216044/ -- it's another fun one
<gary_poster> bcsaller, LGTM with a bug fix and maybe a test
 * bac has to step out.  bbiab to land my branch.
<gary_poster> bcsaller, ugh, missed your other one.  I will review it.  jujugui, could we have a second review of https://codereview.appspot.com/11227043/ ?  critical
<bac> bac: ok
<rick_h> gary_poster: looking
<gary_poster> bac, Makyo gave you an LGTM fwiw
<gary_poster> thanks rick_h 
<bac> gary_poster: just saw.  thanks Makyo
<bac> fwiw, i liked gallery-ellipsis... (no pun)
<jcsackett> jujugui: can i get two reviews on https://codereview.appspot.com/11230043 ? it's mostly deletions and icon changes.
<gary_poster> jcsackett, if no one has soon I will.  one or two ahead of you
<jcsackett> gary_poster: dig, thanks.
<jcsackett> sinzui: can you pick mine up, perchance? https://codereview.appspot.com/11230043
<sinzui> I can
<jcsackett> awesome, thanks.
<rick_h> gary_poster: can I get a second LGTM on here then? I've got to run get the boy from day care soon. https://codereview.appspot.com/11224044/
<gary_poster> rick_h, on it
<jcastro> man just our luck
<jcastro> finally get all those categories
<jcastro> and the dang icon guy goes on holiday for 2 weeks
<rick_h> jcastro: heh
<benji> hatch and gary_poster: as best I can tell, https://codereview.appspot.com/11138044 is fixed; still needs a good QAing though
<gary_poster> jcastro, heh :-)
<gary_poster> hatch, can you do that?  I've got a queue of three atm
<gary_poster> and I want rick and benji to be able to EoD
<rick_h> gary_poster: I know hatch said he was afk for a little bit and would get back. 
<gary_poster> oh right
<gary_poster> :-/
<gary_poster> ok benji, I'll try to qa it soon; if you need to run lemme know
<gary_poster> we can land it for you if need be
<gary_poster> rick_h, hack idea for later: listen for EV_SEARCH_...and friends and add and remove class there?
<rick_h> gary_poster: yea, code might be able to go into the code that fires the viewNavigate based on that. 
<jcsackett> sinzui: i have to run afk for a moment. if you have questions on the branch just drop 'em on rietveld.
<gary_poster> rick_h, LGTM with one old observation and one new observation
<gary_poster> thank you
<rick_h> gary_poster: the search clearning should happen now. It was part of the last minute squeeze in
<rick_h> gary_poster: and ty for the LGTM
<gary_poster> rick_h, oh sweet :-)
<rick_h> ok, I'm out. See you all on the other side...of the appalacians next week...
<gary_poster> bcsaller, LGTM with trivials
<gary_poster> rick_h, thanks!  see you sson
<gary_poster> soon
<gary_poster> on to jon's
<hatch> gary_poster: I am still not sure about this position fixed thing
<hatch> I'm pretty sure it'll cause issues on mobile heh
<sinzui> gary_poster, what is the lowest version of Firefox that is supported?
<hatch>  sinzui I want to say 21
<hatch> but I can't actually confirm that
<sinzui> 21 is the magic number for me
<sinzui> 20 is not magic at all
<hatch> haha well there ya go
<hatch> 21 there were some large changes with how FF works, and 22 is the most recent
<hatch> so you would have to be pretty far behind to be <21
<gary_poster> sinzui, 21 is good
<hatch> yusss i got it right
<gary_poster> hatch, position fixed for what, the headers?
<hatch> the body
<hatch> on benji's branch
<gary_poster> oh!
<hatch> I can't suggest an alternative
<hatch> but I think that that's going to cause us issues in the future
<hatch> so it may just be a bandaid
<sinzui> jcsackett, okay, I am will to trade a LGTM if you revise the use of window.location.origin to a cover IE10
<gary_poster> hatch, :-/ dunno.  if you don't have another suggestion though, maybe we should wait to fight that battle
<hatch> that's kind of what I was thinking
<hatch> do we have a tablet to test on?
<hatch> I only have my N7 with Android
<gary_poster> Makyo has an ubuntu touch.  I have an ipad.  one of those work for what you have in mind?
<hatch> well since the support matrix only includes the touch right now I was hoping we could QA in there to make sure there isn't any wakyness
<hatch> or do you think that's not necessary?
<Makyo> Should I bring the tablet, gary_poster ?
<gary_poster> Makyo, hatch, only for fun :-)  If you don't bring it no biggie Makyo, but +1 if it is easy
<hatch> gary_poster: Makyo: I can tell you that the UI is all sorts of broken with the position fixed on the body in Chrome for Android
<jcsackett> sinzui: by revise you mean replace it with using either origin or protocol + host?
<gary_poster> :-/
<hatch> but on trunk I can use it :)
<hatch> it's actually pretty cool heh
<gary_poster> hatch, that's pretty bad if this one change suddenly breaks Android :-/
<hatch> well it's because it pulls the whole body element out of the flow of the page which I'm going to assume cascades into some weirdness because that's never done
<hatch> I've never even heard of people going position fixed on the body before
<hatch> heh
<bcsaller> why does the token need to append to the body anyway rather than be its own floating div?
<hatch> I was thinking if we could position it where the mouse is...but then we might as well use the YUI DD module
<sinzui> jcsackett, yes, I think we should follow the example in the nod.js code
<jcsackett> sinzui: ok, per your comment?
<jcsackett> pushing that change now.
<hatch> bcsaller: it has to be visible in the DOM to be the dragable proxy
<hatch> it's pretty odd...
<bcsaller> top: -1000px left -100px with position absolute?
<rick_h> bcsaller: replies inbound
<hatch> bcsaller: I thought I tried that but maybe it was another bug
<hatch> one sec
<gary_poster> jcsackett, code LGTM but qa bad: "X" to close is in wrong place.  I also can't find an image from luca of where the icons should go but it doesn't look right there in the build mode--it looks like it should really be above the tabs
<gary_poster> jcsackett, want to guichat to see what I'm seeing?  I tried clearing cache
<jcsackett> gary_poster: per luca, below the tabs.
<jcsackett> gary_poster: sure, one moment
<gary_poster> jcsackett, does that seem as odd to you as it does to me?  is there an image?
<jcsackett> gary_poster: there is not. is guichat open?
<gary_poster> jcsackett, it is, see you there
<hatch> bcsaller: yep as I thought, it doesn't work - when it's positioned off the screen the drag proxy is invisible
 * bac gotta run.  see y'all in raleigh
<hatch> cya bac
<hatch> safe travels
<hatch> does anyone remember why we didn't use YUI DD for this drag stuff?
<bcsaller> was it just a preference for the HTML5 stuff? Not sure. really does seem like that native stuff should work but itsn't baked yet. 
<hatch> yeah I think the issues we are having are caused by workarounds around chrome being stupid
<hatch> whereas the YUI DD code absolutely positions an element under the cursor
<hatch> I gota say - with the exception of there being too much UI chrome on this new design, it works pretty darn well on a tablet
<hatch> side effect of us just being so awesome....right?? right????
<hatch> awwww yeahhhhh
<bcsaller> I'd like to cut over to the pointer events polyfill or something similar so we can pull in better touch support more easily 
<hatch> I'd like developing on something that isn't a moving target lol
<hatch> ahh who am I kidding....I'd get bored
<hatch> "what do you mean this just works?"
<hatch> lol
<jcsackett> gary_poster, sinzui: changes you've requested are up https://codereview.appspot.com/11230043
 * sinzui looks
<gary_poster> jcsackett, on it thanks
<gary_poster> hatch, what's the story for benji's branch?
<hatch> if we use it - it breaks mobile...bigtime - if we don't, we don't have a better sollution besides switching to YUI DD (which I'm not sure why we didn't go that route in the beginning)
<hatch> so maybe there was a reason YUI DD didn't work
<hatch> I can think of alternatives, but none that would be trivial (positioning the drag proxy under the cursor)
<benji> rick and I couldn't get YUI DND to work so we went with HTML5 instead
<hatch> ohh ok, do you remember what the issue was?
<hatch> and as a follow-up - can we use the actual icon in other browsers and just 'deal with it' until chrome fixes the cutoff icons issue?
<benji> the last thing I remember was trying to get the tokens to drag out of the sidebar , they wouldn't leave their container
<hatch> ahh
<benji> actually we are dealing with the cutoff issue, the cloning of the icon is to deal with firefox; it uses the default drag icon if we don't
<hatch> ohh odd, I've never seen the cutoff
<hatch> but hmm
<hatch> basically if we want to support mobile we can't use your fix
<hatch> benji: so in FF we can't point it to the icon in the DOM already?
<benji> the cutoff only happens with background images (not the per-charm custom icons)
<hatch> ok I'll hack on this a bit
<benji> hatch: right, if I recall correctly, FF didn't like that
<hatch> it's past your EOD
<benji> may the schwartz be with you
<hatch> lol well you are right, it doesn't like that
<hatch> ok that was an OSX bug
<hatch> got it to work
<hatch> without an extra cloned node
<hatch> I'll try these changes on trunk and then propose the branch if it works in all 3 browsers
<gary_poster> thanks benji, hatch.
<gary_poster> jcsackett, LGTM with one additional style hack that I give you specific numbers for.  Thank you very much!
<gary_poster> hatch, will be back soon if you need LGTM
<hatch> sure np - this is taking a little longer than expected because I have too many branches active heh
<hatch> jcsackett: except use a single line to apply those padding styles :P
<gary_poster> well, yeah, that would be fine :-P
<hatch> for some reason WIndows 8 is telling me what the weather is in New York
<hatch> it's raining if anyone cares
<hatch> :D
<hatch> oh IE you suck so much
<hatch> we had a comment in our ghost-inspector.js file which caused a js parse error....
<hatch> a comment....
<hatch> hmm
<hatch> this is a disaster lol
<hatch> gary_poster: would you like me to file IE10 bugs?
<gary_poster> hatch, yes
 * hatch schedules off next week to file bugs
<hatch> tee hee
<gary_poster> hatch, that bad, eh? :-/
<hatch> yeah it's pretty bad - good thing it's so standards compliant
<hatch> ....
<gary_poster> heh
<hatch> ok so I have fixed the primary issue but caused another one
<hatch> the icon in the middle of the ghost in FF is too large
<hatch> it's svg <image> tag has the proper dimensions
<hatch> but the image isn't scaling properly inside it
<hatch> has this happened to anyone else?
<bcsaller> hatch: I just took a peek at this myself, what about http://jsfiddle.net/p33KJ/1/ doesn't do what we need?
<gary_poster> Maybe Makyo has svg insight, hatch, dunno?
<hatch> bcsaller: I've actually already solved that issue
<hatch> heh sorry
<bcsaller> with the HTML5 codepath?
<hatch> yep
<bcsaller> ahh, ok
<hatch> https://gist.github.com/hatched/03c074ee0543b5f2d223
<hatch> bcsaller: ^
<hatch> look at line 8.....that caused IE to explode
<hatch> lol
<gary_poster> poor IE.  such a fragile flower
<hatch> so yeah this diff works....with the exception of the svg image resize issue in FF
<Makyo> gary_poster, hatch - Oh, foo.  Yeah.  We have to append 'px' to width and height attributes for FF to parse them.
<gary_poster> ah!  cool, thanks Makyo!  /me senses happy branch landing approaching...
<Makyo> I thiiink that's it.
<gary_poster> :-)
<gary_poster> bcsaller, when are you landing your branches?  you have two sets of LGTMs waiting for you. :-)
<hatch> Makyo: ahh cool I'll try that
<hatch> thanks :D
<bcsaller> gary_poster: I thought I had for some reason, must have failed on a merge, checking
<gary_poster> cool
<hatch> Makyo: so I don't see the x and y being set on the old version
<Makyo> Lines 1186-1187 in app/views/topology/service.js
<bcsaller> gary_poster: if the second LGTM is the options fix that needs one more review unless you think doesn't
<gary_poster> bcsaller, oh, right.  I personally think it verges on trivial.  I say try to get one more and if you don't land it anyway :-)
 * gary_poster steps away
<bcsaller> ahh, I see what happened, the trunk merge needed an npm update to run the tests successfully and submit died in one of my many open terminal tabs :(
<hatch> Makyo: ok thanks
<hatch> have a good weekend all - safe travels!
<gary_poster> you too hatch.  you closing up on the dnd branch till Monday?
<hatch> gary_poster: nope, I plan to propose it but I have supper plans which start in 2mins
<hatch> :)
<gary_poster> lol
<gary_poster> ok enjoy
<hatch> :) thanks
#juju-gui 2013-07-14
<rick_h> howdy gui folks
<huwshimi> Morning
#juju-gui 2014-07-07
<rogpeppe1> mornin' all
<urulama> morning
<huwshimi> morning
<rogpeppe1> urulama, huwshimi: hiya
<rogpeppe> frankban: yo!
<frankban> morning rogpeppe 
<rogpeppe> frankban: you up for continuing forward with the store stuff?
<frankban> rogpeppe: sure, coffee and I am ready
<rogpeppe> frankban: cool
<frankban> rogpeppe: I am in daily standup
<rogpeppe> frankban: joining
<frankban> urulama: could you please take a look at https://github.com/juju/charmstore/pull/12 ?
<frankban> urulama: (and morning ;-)
<urulama> frankban: morning
<urulama> frankban: looks fine, only small detail ... you use CharmArchive sometimes instead of Archive (all the rest cases) ... any particular reason for this?
<urulama> frankban: (ie, branch_test.go, line 83)
<frankban> urulama: we (will) also have BundleArchives
<urulama> frankban: all clear
<jrwren> mornin
<urulama> morning
<urulama> jujugui: anyone else having problems with the login window after getting 1.20.0 core in the update? can't enter password for user-admin on any browser (firefox, chrome, safari)
<frankban> urulama: trying to reproduce
<urulama> jujugui: whatever is typed is lost within a few sec (self erased)
<frankban> urulama: I am able to log in into the GUI in a local env
<urulama> frankban: ok, tnx. using manual here, switching to amazon now
<bac> hi frankban
<frankban> bac: morning, how are you doing?
<bac> frankban: good, thanks.  on friday, doing QA for quickstart i ran into bug 1316174 and suspended the release.  can't recall if i mentioned it or not.
<_mup_> Bug #1316174: 'precise-updates/cloud-tools' is invalid for APT::Default-Release <juju-core:Triaged> <https://launchpad.net/bugs/1316174>
<bac> frankban: it isn't a QS issue but i didn't want to do a friday release with an issue
<frankban> bac: isn't it something also affecting current release?
<bac> frankban: yes it does
<frankban> bac: so, a new release would keep failing on precise but at least would fix trusty IIUC
<bac> frankban: yes, it would be an improvement
<frankban> bac: in this case I'd be +1 on releasing anyway.
<bac> frankban: qa on trusty was fine
<bac> frankban: ok, unfortunately i am not here today.
<frankban> bac: oh, I can do that then, so missing bits are 1) QA on saucy 2) move the packages to juju stable PPA and 3) push the release to PyPI, correct?
<bac> frankban: and the homebrew bits
<frankban> bac: ok, I see the hacking file includes brew documentation. I'll take care of the release, thanks a lot for the heads up while on holiday. 
<bac> frankban: np
<rogpeppe> frankban: ready to continue whenever you are
<frankban> rogpeppe: joining
<urulama> frankban: seems like local, amazon & openstack env work properly, while manual has the issue with the login in juju-gui
<urulama> frankban: will test on some other machine, to see if i get the same error in manual env
<frankban> urulama: ok, let me know if you see the same
<hatch> morning all
<frankban> morning hatch 
<hatch> frankban I've gone through about 4 more versions of the 'runWhenCalled' testing implementation heh
<hatch> and still need to do one more :)
<frankban> hatch: after that, 3 more and I'd expect it to be just perfect
<hatch> haha - well I need it to finish these tests so those iterations better come quick :)
<hatch> the last iteration didn't work because it was hard to follow for many steps through the UI https://gist.github.com/hatched/087d9e30e3eb92a46657 see I added // #'s to illustrate that
<hatch> the current one does away with all that so you can write them synchronously 
<hatch> except for the initial async call has to be called last....which I don't like
<hatch> frankban maybe you have a better idea https://gist.github.com/hatched/42e60957927b7caddd8b#file-test-js-L14
<hatch> that's the current functionality
<hatch> I like how it's written synchronously but it's the initial 'trigger' that has to be put at the end which is a little funky - I was considering adding a `runner.step()` method which would parse the steps first then run a `runner.start()` but that's adding even more code to the test runner which I was really trying not to do
<hatch> jujugui call in 5
<hatch> jujugui call in 1
<hatch> jujugui call now
<hatch> kadams54 https://plus.google.com/hangouts/_/gwrfc6s6hbqazst3ovh3uaypeua?authuser=1&hl=en
<hatch> hurrroowwww
<jcsackett> jujugui: sorry i missed call time. have been knocked offline for last 30min and lost my phone.
<hatch> jcsackett np
<kadams54> hatch: soooooâ¦
<kadams54> hatch: it looks like we check for that 'new' prefix in other parts of the code
<kadams54> And use it to make decisions about whether the machine is committed yet or not.
<hatch> ok that's not going to work for the future
<kadams54> What should we be doing?
<hatch> we should inspect the model to see if it's a real-boy
<hatch> later on we will add the ability to name machines
<hatch> so we can't rely on a user input to know if something is new or not
<kadams54> Well, it's not really user input, since it's a standard string we prefix to all machine IDs.
<kadams54> (for uncommitted machines)
<kadams54> The one advantage I see is that it means we don't have to do a DB lookup
<hatch> right but that's not going to work
<hatch> unless we have newthisismymachinename
<hatch> or what if they name their machine 'newsuperbox'
<kadams54> Name doesn't matter
<kadams54> It's combining "new" + ID
<kadams54> And I think ID is an auto-generated sequence?
<hatch> can you link me to where this is happening
<kadams54> Just grep through machine-view-panel.js for 'new' (with single quotes included in the search) - it happens all over the place in there.
<kadams54> Also: I'm not seeing a connection between the IDs of committed machines and the IDs assigned to ghosted machines, which would mean more overlap.
<kadams54> The ghosted IDs are assigned via the _ghostCounter, which is just set to 0 when a MachineList is instantiated.
<hatch> but the name being displayed to the user is the id right?
<kadams54> Not really
<kadams54> It's just a temporary ID
<kadams54> Which is created from 'new' + _ghostCounter
<kadams54> And _ghostCounter has no connection to the actual IDs stored in the DB.
<kadams54> So a machine could be new0 when created
<kadams54> But 1 once actually deployed
<jcsackett> hatch: i'm looking through your review, and i'm wondering, how would you feel about the various "createInspector" methods dealing with destroying the old one after they make a new one?
<jcsackett> hatch: rather than the _inspector method tracking active and previous the whole way through?
<jcsackett> at the point where we're, say, making createServiceInspector responsible for sorting out quite a bit about the state of the service inspector, it seems tidier to me.
<hatch> kadams54 right, but what's being shown to the user? something is generating that
<hatch> jcsackett hmm lemme take a look
<kadams54> hatch: what's being shown to the user is exactly what I just said. 'new' + _ghostCounter
<hatch> kadams54 so your card is simply deleting that 'new' ?
<kadams54> Yes, and I'm saying it's not "simply" and we might want to re-think it.
<hatch> you think that we should leave the 'new' prefix?
<kadams54> 1) we have logic based on the 'new' prefix and 2) we'll end up with a confusing UX because the user will see two machines labeled "0" and the only diff between them is that one is blue.
<kadams54> hatch: yes.
<kadams54> hatch: keep the new prefix, unless there's a strong case for removing it. In which case we'll need to get creative with solutions.
<hatch> 1) this is not going to work in the future, we can't rely on something saying 'new' if the user can enter their own names
<hatch> 2) I propose that we dont' show id's at all for undeployed machines if we can't show a reliable id
<hatch> new0 is just as confusing as 0
<kadams54> hatch: is naming machines on the road map?
<hatch> yes, it's even in the bug report...
<kadams54> new0 isn't greatâ¦
<kadams54> But it's better than 0
<kadams54> It communicates something important about the machine's state
<kadams54> Something that distinguishes new0 from 0
<urulama> frankban: so, i've set up completely new set of machines for manual env and the "disappearing" password is no longer there. however, connecting to the juju environment fails now :(
<hatch> kadams54 right, but new0 seems like it's a new version of 0, when in fact it's an entirely different machine
<kadams54> hatch: I'll concede that point, but it's still better than having two machines labeled as "0"
<kadams54> hatch: I don't like the way things currently work, but I don't think "simply" removing the "new" prefix is a step in the right direction.
<hatch> jcsackett so instead of doing the previous inspector assignment in _inspector and then the previous.destroy in the _inspector you want to move that into the create methods?
<jcsackett> hatch, i think so. can you chat for a moment?
<hatch> kadams54 ok that's fine - so you need to send an email to design and peeps expressing your concerns and offering an alternative approach so that everyone can weigh in
<hatch> jcsackett sure just one minute I need to relocate
<kadams54> 1) We need to change the logic to look at a model attribute to determine uncommitted state and 2) we need to figure out how to differentiate (beyond blue color) ghosted machines from committed machines.
<jcsackett> hatch: cool.
<hatch> construction crews are making a ton of noise 
<kadams54> hatch: will do.
<jcsackett> always fun, the construction.
<frankban> rbasak: quickstart 1.4.1 is on PyPI
<hatch> jcsackett https://plus.google.com/hangouts/_/gs4t7bkjwkdpdylcfqa4a2nuwaa?authuser=1&hl=en
<hatch> jcsackett ok creating a new hangout
<hatch> jcsackett https://plus.google.com/hangouts/_/gvbizv4vjesvksrba5nljzslq4a?authuser=1&hl=en
<hatch> kadams54 thanks for the email
<kadams54> yup
<hatch> kadams54 I usually add luca directly to these emails as I'm not sure  he's on peeps, maybe keep that in mind and ping him next time you see to make sure he got it
<kadams54> Yeah, I CC'd him on this.
<kadams54> Rick had mentioned the same.
<hatch> oh I didn't see it in the list
<hatch> maybe you bcc'd?
<kadams54> From: Kyle Adams <kyle.adams@canonical.com>
<kadams54> To: "juju-gui-peeps@lists.launchpad.net" <juju-gui-peeps@lists.launchpad.net>
<kadams54> Cc: Luca Paulina <luca.paulina@canonical.com>
<kadams54> I suspect the list stripped off the CC.
<hatch> interesting I didn't know it did that
<hatch> in fact I didn't think that it did heh
<kadams54> Taking a lunch breakâ¦
 * rogpeppe is done for the day
<rogpeppe> g'night all
<hatch> cya rogpeppe 
<hatch> jujugui anyone around to take a look at a complicated test using my new 'resume' method? https://gist.github.com/hatched/a115fb081279c8856b9d
<hatch> this technique now allows you to test async UI interactions by writing synchronous code
<hatch> here is the changes to the utils methods and it in use https://gist.github.com/hatched/087d9e30e3eb92a46657
<jcsackett> hatch: FYI, won't have branch up before my usual EoD. Doc appt has been 2.5 hours and ain't over yet. 
<hatch> yikes, ok np
<hatch> lots of waiting room?
<hatch> jujugui looking for a review and qa https://github.com/juju/juju-gui/pull/425 plz and thanks
<hatch> I'm blocked on my next task until that branch lands
<hatch> well I can just continue from it, np
<hatch> jujugui does anyone know how the user will 'scale-down' with the new scale-up UI?
<rick_h__> bac: around? 
<hatch> hmm, does anyone know why a simulate() call wouldn't work in IE in a callback?
<hatch> rick_h__ no he is off today
<hatch> ended up working Friday instead
<rick_h__> hatch: ok cool
<hatch> and wb to the real world
<hatch> :)
<rick_h__> hah, no kidding
<rick_h__> wheeee
<rick_h__> start driving home and all the emails start to arrive
<hatch> haha, ding ding ding ding.......
<rick_h__> there's still places out there with no cell connectino
<hatch> yeah our cabin used to be one....unfortunately (fortunately?) it now has reception
<hatch> well I'm totally baffled by this test failure
<hatch> of course it has to be in IE10 too hah
<hatch> hmm it happens in all versions of IE
<hatch> even 11
<hatch> kadams54 wb
<hatch> well I'm at a total loss here maybe a night off will give me some fresh perspective 
<huwshimi> Morning
<rick_h__> morning huwshimi 
<rick_h__> how goes?
<huwshimi> rick_h__: Hey, good thanks. Have a nice break?
<rick_h__> huwshimi: yea, have 996 pictures to go through :)
<rick_h__> good times, a little crazy having no cell reception for days at a time
<rick_h__> but was good and exhausting times in the woods
<huwshimi> rick_h__: Great! It's cool to hear how you actually get away during your breaks :)
<huwshimi> I guess that usually doesn't stop you from working though :)
#juju-gui 2014-07-08
<hatch> huwshimi hey
<huwshimi> hatch: Hey
<hatch> thanks for the comment
<hatch> unfortunately that means I have to re-write a bunch of stuff...lol
<hatch> but it's a lot nicer approach 
<huwshimi> hatch: No problems. We seem to be heading in the direction of using these state classes for all our "widgets" that have multiple states. I figure it'd be good to stay consistent.
<huwshimi> hatch: Yeah, I know it's a bit of a pain
<hatch> so, the idea then is that any time there is a state change in the UI we wlll add a new class and appropriate nested stuff
<hatch> that was a question
<hatch> :)
<huwshimi> hatch: Well, swap out the state class, but yeah, I think this approach would work
<hatch> ok cool
<huwshimi> hatch: I'm pretty sure it was your idea :)
<hatch> lol this last little while has been nuts
<hatch> yay me? 
<hatch> nah, yay you!
<hatch> so my comment https://github.com/juju/juju-gui/pull/424 is because objects keys aren't in any order
<hatch> so just because you add two things in a row in an object doesn't mean they will be in that order
<hatch> it's likely that they will be in order but there is no guarantee
<hatch> only arrays are guaranteed to be in order 
<huwshimi> hatch: Yeah, but if we build this list in the dom based on the list of keys and then grab the first key to select the first item it seems to maintain the order
<hatch> it does, but it's not guaranteed 
<hatch> you can make two loops through an object's keys and get them in two different orders
<hatch> if we only have it in that format then it's the way it's got to be
<huwshimi> hatch: Yeah, I get that, I guess the other way to do it would be to grab the id off the first token in the dom
<hatch> well...what do you think?
<hatch> is there any real issue in selecting one that's not the first?
<huwshimi> hatch: Only that it would be weird to have a machine that is not at the top of the list selected by default
<hatch> well I'll leave it up to you :) 
<huwshimi> hatch: I can grab it from the dom, that would always do the right thing.
<hatch> ok cool
<huwshimi> hatch: I called out the state classes when I landed my branch, but I'll try make sure it's clearer next time so the person picking up the work can see them.
<hatch> cool
<hatch> huwshimi ok I'm taking off, have a good night
<huwshimi> hatch: Night!
<rogpeppe> frankban: up for continuing?
<frankban> rogpeppe: morning, sure!
<rogpeppe> frankban: i'm in the standup
<rogpeppe> frankban: back
<rick_h__> morning party people
<rick_h__> frankban: if you get a sec can I get the low down on the reproduction steps for the bug in quickstart you guys fixed against 1.20? We're working on trying to figure out some sort of CI
<rick_h__> frankban: and curious why we didn't hit that bug in normal use of quickstart against dev releases
<frankban> rick_h__: welcome back
<frankban> rick_h__: `chat? I am in the daily hangout
<rick_h__> frankban: help, tie me down before I run away!
<rick_h__> frankban: sure thing
 * frankban lunches
<rick_h__> rogpeppe: frankban email forwarded to peeps from carla about bundle details per the call last week with bac and I and UX.
<rogpeppe> rick_h__: thanks
<rick_h__> rogpeppe: frankban just as an fyi on some data UX needs for bundles eventually in case any of it fits current WIP. 
<rick_h__> rogpeppe: bac frankban make sure to check out https://github.com/juju/juju/pull/250 and provide any feedback we have on the style guide. 
<rick_h__> if approved and landed it's something we should be aware of and pick up I think. 
<urulama> rick_h__: where should i put the card for bug 1339005 ... maintenance/review?
<rick_h__> urulama: looking
<rick_h__> urulama: ok, so just file it and I'll traige and add a card. 
<rick_h__> urulama: I'll add it to the on deck backlog for maintenacne
<rick_h__> maintence
<rick_h__> bah
<rick_h__> urulama: we only use high and low importances. If it's high, we should try to fix it, if it's low, we ack it but don't promise to get to it any time soon (really ever) 
<rick_h__> urulama: when you get time let's catch up
<rick_h__> jrwren: same ^
<bac> morning
<rick_h__> morning bac, made it to NC safely?
<urulama> rick_h__: i'm gonna pick up my kids in 45min, change location. is 10AM ok for you?
<rick_h__> urulama: party
<rick_h__> urulama: I mean yes :)
<bac> rick_h__: eventually.  our original flight went through with no problems on friday but i'm still glad we postponed.  the thought of getting stuck in ATL was unpleasant.
<rick_h__> bac: hah, not a fan of our great south? :P
<bac> rick_h__: not a fan of sleeping in any airport
<rick_h__> bac: good call
<frankban> rogpeppe: I am back, please ping me when you are ready
<rogpeppe> frankban: will do. currently perusing rick_h__'s comments
<frankban> rick_h__: thanks for the link/email
<frankban> rick_h__: machine/unit counts can be easily calculated by clients IMHO, agree with you re: owner details, the current spec allows for easily adding customized API later
<rogpeppe> frankban: i'm in the hangout, BTW
<rick_h__> frankban: yea, maybe I'm getting ahead of myself. I have this fear that those counts will be filter/selection criteria for searches
<rick_h__> frankban: but they're not currently so you're right, for display purposes they can be client side calc'd
<bac> rick_h__: wanted you to be aware of bug 1316174 -- it affects users on precise trying to bootstrap local envs.  it's a juju-core issue but affects quickstart
<_mup_> Bug #1316174: 'precise-updates/cloud-tools' is invalid for APT::Default-Release <juju-core:Triaged> <https://launchpad.net/bugs/1316174>
<rick_h__> bac: looking
<hazmat> did we loose the ability to hide subordinate relation lines?
<hazmat> looks like we draw in gray with the little box to the side of the sub service, we used to be able to click the box and hide the sub rel lines, but it hasn't seem to worked in a while.
<rick_h__> hazmat: yes, we're supposed to be getting to controlling it with the deployed service inspector 
<rick_h__> hazmat: is the box still there? /me goes to try it out, been a while.
<hazmat> rick_h__, yes its still there
<rick_h__> hazmat: what UI box is there to hide then?
<rick_h__> them?
<rick_h__> bac: :/ ok. Will make sure it's brought up. 
<rick_h__> frankban: rogpeppe is there a card on the board for the current WIP? 
<frankban> rick_h__: no, I'll create one, thanks
<rick_h__> frankban: ty much
<hazmat> rick_h__, off subordinate services there is a ... line to a subordinate count box, that box is supposed to toggle display of that's sub service's relation lines
<rick_h__> hazmat: ah ok. checking existing bugs now.
<jrwren> rick_h__: you around in 10m?
<rick_h__> jrwren: on a call but can ping when I get off
<jrwren> perfect
<hazmat> rick_h__, don't think there is one.. its been broken for a long time (at least 6months).
<rick_h__> hazmat: right, I know we've talked a lot about showing/hiding lines including subordinates and we've got work this cycle to allow it with all services
<rick_h__> hazmat: I'll file a bug and see if there's a quick fix, some code that's not getting run or if it's actually been removed 
<hazmat> rick_h__, ok
<rick_h__> hazmat: https://bugs.launchpad.net/juju-gui/+bug/1339029
<_mup_> Bug #1339029: show/hide a subordinate relation line not functioning <juju-gui:Triaged by makyo> <https://launchpad.net/bugs/1339029>
<rick_h__> hazmat: will ask mayko to take a peek at it and see if it's something we can hook back up easily
<hazmat> rick_h__, even if there's a long term thought on rel display, subordinates are a special case given their cross cutting concerns in an env, ie. is has 6-8 subordinate rels to every service.
<hazmat> rick_h__, cool, thanks
<rick_h__> hazmat: the work to show/hide any rel line is scheduled late into the cycle so won't be updated soon. 
<rick_h__> hazmat: right, the idea is that you can show/hide the blocks and lines for any service in an environment
<rick_h__> luca: add a call to the meeting?
<luca> rick_h__: forgot, doing it now
<luca> rick_h__: https://plus.google.com/hangouts/_/canonical.com/jaas-catch-up?authuser=1
<rick_h__> luca: ty much
<urulama> jrwren: regarding the sprint in London - heard you're really close to rick_h__ (what's a 100km in usa ;)) , so, if calls would not suffice, you can probably just meet and get over details, so, don't worry about the sprint
 * urulama needs to pick up the kids now
<rick_h__> jrwren: ping
<jrwren> pong
<rick_h__> jrwren: meet in the standup hangout?
<jrwren> yes
<rick_h__> whoops, others are there
<jrwren> new room?
<rick_h__> yep, getting invite together
<rick_h__> https://plus.google.com/hangouts/_/g6xwjb53dpltyqiu66zdkmpnvma?authuser=1&hl=en
<rick_h__> change the authuser part of the url to your own google accounts
<jcsackett> hey, hatch__, i've pushed up all the work from yesterday we discussed. can you take a look? https://github.com/juju/juju-gui/pull/422
<hatch__> you bet
<hatch__> odd I can't change my name to hatch
<hatch__> jcsackett you didn't address my comment in viewlet-manager.js
<jcsackett> hatch__: ...actually i did. i don't know why that didn't get pushed up.
<hatch__> heh, welllllll push'r'up
<jcsackett> hatch__: huh. it pushed up the change to service-inspector but not viewlet...weird.
<rick_h__> hatch__: how goes, when you get a sec I'd like to meet up with you and kadams54 and get caught up on where we are with MV
<rick_h__> it looks like half the cards are blocked and now following why and want to make sure we plot a path through that asap
<hatch__> rick_h__ sure, 20mins? 
<rick_h__> hatch__: k
<urulama> rick_h__: ping
<rick_h__> urulama: howdy
<rick_h__> urulama: ready to chat?
<urulama> rick_h__: sure
<rick_h__> urulama: k, invite on the way
<rick_h__> urulama: https://plus.google.com/hangouts/_/g5fbbzj56dl7cjvipytcasn5zma?authuser=1&hl=en
<urulama> rick_h__: ok, tnx, see that the room is busy :D
<jcsackett> hatch__: pushed.
<hatch__> jcsackett man git really did the diff odd with your branch heh
<jcsackett> hatch: yes.
<jcsackett> i find git frequently does terrible things with diffs.
<hatch> it tries super hard to keep old lines even if they don't make any sense in the context heh
<hatch> "no you saved THIS curly bracket" lol
<jcsackett> hatch: yeah. and it seems super easily thrown off by lines moved around. 
<jcsackett> "you deleted this line and and move that one...better mark the whole file as a conflict!"
<hatch> rick_h__ I'm ready whenever you are
<rick_h__> hatch: coolio, kadams54 available?
<kadams54> rick_h__: yup
<rick_h__> kadams54: https://plus.google.com/hangouts/_/gsmrjulttdrhsdmyukjid7aenma?authuser=1&hl=en
<jcsackett> hatch: saw your comment on retry; how would retry get the inspectors object? because it just sets up y.later, which only returns a timer.
<hatch> jcsackett otp 
<rick_h__> luca: if you can file that bug with the roll overs I'll get huw to look at it tonight
<luca> rick_h__: awesome, Iâll do it now
<luca> rick_h__: https://bugs.launchpad.net/juju-gui/+bug/1339092
<_mup_> Bug #1339092: Implement roll over and states for machine view tokens <juju-gui:New> <https://launchpad.net/bugs/1339092>
<rick_h__> luca: ty 
<hatch> jcsackett ok done, I'll look into HOW to do what I mentioned heh
<hatch> it'll definitely require a bit of a refactoring 
<hatch> (reworking?) :)
<jcsackett> hatch: yeah, Y.later doesn't even let you set a callback or something for the function, which is both odd and vexing.
<jcsackett> hatch: i hope not much--this work has taken way too long to get through review already. :p
<hatch> I added one other comment as well
<jcsackett> hatch: if we don't find a simple way, then Y.later can just retry the dispatcher.
<hatch> right, but wasn't that what you were trying to avoid in the first place?
<jcsackett> hatch: well, it's what used to happen. this seemed better, but it sets up a problem.
<jcsackett> hatch: so we can fall back to what used to happen, which wasn't broken.
<rick_h__> jujugui call in 10, kanban please
<rick_h__> jcsackett: hatch why a retry loop? is this for when we load the env for the first time and the data's not there yet from the env?
<hatch> jcsackett the only 'simple' way is to call the inspector dispatcher again
<jcsackett> rick_h__: right.
<jcsackett> hatch: then i say that's what we do.
<hatch> the other way is way to complicated and whtnot
<rick_h__> jcsackett: can we not just tie up to the db events like we talked about before?
<hatch> agreed
<jcsackett> b/c i don't think spending much more time on this is valuable.
<hatch> yeah I'm find with switching it back, it's a simple fix then
<bac> rick_h__: the comingsoon to azure card, is that something you'd like to do now?
<jcsackett> rick_h__: as i recall, no, b/c the dispatcher doesn't wait on db.
<rick_h__> bac: yes, if you care to take it. 
<rick_h__> jcsackett: right, but who cares about the dispatcher? 
<hatch> dispatcher don't wait for nobody!
<jcsackett> rick_h__: this is all about dispatch.
<bac> rick_h__: i don't understand the second part of the description, but yeah.
<jcsackett> we have to retry, b/c dispatch doesn't wait for db and throws a fit when it can't find the data it needs.
<jcsackett> so we tell it to retry b/c the data will be there in a moment.
<rick_h__> bac: ah, the second part was a question on do we just serve out the jenkins workspace as a 'comingsoon' but that could be bad
<rick_h__> bac: the idea was that the -merge job would eaily update a local path and just serve out the gui
<rick_h__> bac: vs a new machine
<rick_h__> bac: meet in standup pre stand up and chat?
<bac> rick_h__: i just submitted an hr request for tomorrow as we discussed last week.
<rick_h__> bac: rgr
<rick_h__> jujugui call in 2 
<rick_h__> kadams54: ^
<kadams54> Joining
<urulama> rick_h__: when you finish with calls: what's machine view :D
<hatch> urulama http://comingsoon.jujucharms.com/machine/:flags:/mv/
<hatch> it show the actual juju machines and allows you to fiddle with the placement of units and whatnot
<hatch> this is a new feature in the GUI and apparently.....a very long one to implement :)
<urulama> hatch: tnx
<rick_h__> urulama: yea, it's manual placement for the GUI
<jcsackett> hatch: updated PR.
<hatch> jcsackett thanks will look again
<rick_h__> hey, there he is
<rick_h__> Makyo: I removed you from that bug fyi
<rick_h__> jrwren: responeded to the bug report, thanks for looking into that
<rick_h__> jrwren: can you go ahead with the update to the CN and file a bug on the gui for the user help?
<rick_h__> hatch: going to get food and then we can chat. 
<jrwren> sure, is it fixable?
<rick_h__> jrwren: is what fixable?
<hatch> rick_h__ cool thanks
<jrwren> oh, the bug is just for docs for this.  OK.
<jrwren> I was just thinking, "why file a bug, if it can't be fixed", but it can be documented
<rick_h__> jrwren: yea, the browser can try to do some detection and at least help point the user 'hey I can't connect you might check xxx'
<jrwren> ah, ok.
<rick_h__> right now the lack of user feedback makes them think juju is broken vs their browser
<jrwren> this bug is on juju-gui, should it just be this same bug, or a new one?
<rick_h__> jrwren: a new one, this one is on both the charm and the gui. I think having one aroudn the ssl cert for the charm is cool and the other for the gui being helpful
<jrwren> ok
<hatch> jcsackett two qa issues posted
<jcsackett> hatch: huh. haven't seen that. let me see if i broke something addressing last few comments.
<hatch> sure thing
<jcsackett> hatch: ok, that first one seems to be fallout i missed from moving the change event firing out of viewlet manager (and is in fact the reason that i put it in the viewlet manager in the first place. i'm digging into why it doesn't work now)
<jcsackett> that second one, i have no idea.
<jcsackett> this damn branch.
<hatch> jcsackett it's likely a state issue
<jcsackett> hatch: so, this is fallout from moving to the just checking model.id hasn't changed to see if we should re-render or make a new one.
<jcsackett> b/c we don't actually destroy this._inspector when the inspector closes.
<hatch> that's issue #2?
<jcsackett> yeah.
<hatch> well we should be destroying it
<jcsackett> hatch: i concur.
<hatch> +1
<hatch> be sure to add a test :PPP
<jcsackett> hatch: i'm looking into why it doesn't get destroyed.
<jcsackett> hatch: oh man, we've never destroyed it; it doesn't get destroyed in develop either. so it's not just a simple case of a broken dispatch change.
<jcsackett> hatch: safe to say that when state sees metadata with inspector: null we can kill this._activeInspector?
<hatch> jcsackett you bet - I'm curious though as to why it's not, the enptysectiona method should be destroying it
<hatch> ohhhh
<hatch> I bet that's what happened
<jcsackett> "that" == what now?
<hatch> oh wait nm you fixed that
<hatch> ok look into emptysectiona method
<hatch> it should be being called and destroying the inspector
<hatch> https://github.com/jaycee/juju-gui/blob/dispatch-details/app/subapps/browser/browser.js#L390
<jcsackett> hatch: this is fun.
<jcsackett> this._inspector.destroy() is getting called.
<jcsackett> immediately after which, you can still check this._inspector and find an object.
<jcsackett> same in develop if you look at this_activeInspector.
<hatch> oh...right, duh
<hatch> destroy() calls the destructor cycle, it doesn't null out the ref
<jcsackett> should empty section set it to undefined or something?
<hatch> null probably, yeah
<hatch> null....undefined....whatever
<hatch> heh
<jcsackett> yeah, that fixes that.
<jrwren> what we talked about: https://bugs.launchpad.net/juju-gui/+bug/1339155
<_mup_> Bug #1339155: gui should display help when wss fails due to incorrectly accepted certificate <juju-gui:New> <https://launchpad.net/bugs/1339155>
<jcsackett> hatch: so it looks like the onHide function in service-inspector isn't even being called? it's just jumping straight to viewlet managers hideSlot, despite my setting click on close-slot to onHide in the service inspector.
<jcsackett> thoughts?
<rick_h__> ty jrwren 
<urulama> rick_h__: i've added some suggestions to the "new hire" doc
<rick_h__> urulama: ty much
<jrwren> rick_h__: should I start working on that bug?
<rick_h__> jrwren: just the CN one in the charm
<jrwren> ah, did that.
<rick_h__> jrwren: so that it doesn't lead to juju.ubuntu.com but to their own env
<rick_h__> jrwren: ok, is that reviewed and landed then?
<jrwren> point me to docs on that process?
<rick_h__> jrwren: there's a hacking doc around the charm with some functional tests. 
<jrwren> got it.
<urulama> jrwren: please share
<rick_h__> jrwren: so you need to pull down the charm code, update it, push it up under your name space, create a merge request from launchpad, and ping to get a review 
<rick_h__> http://bazaar.launchpad.net/~juju-gui-charmers/charms/precise/juju-gui/trunk/files
<rick_h__> http://bazaar.launchpad.net/~juju-gui-charmers/charms/precise/juju-gui/trunk/view/head:/HACKING.md
<jrwren> guess I shouldn't have bzr push :parent then.  ooops
<urulama> rick_h__: tnx
<hatch> jcsackett hmm lemme take a look
<rick_h__> jrwren: heh, nope
<hatch> I'm not sure
<rick_h__> jrwren: urulama nothing ever lands without review and all stuff should be forked to your own name space (in github or LP) and a pull request/merge proposal created to be signed off on
<rick_h__> jrwren: urulama and we try hard to create a HACKING doc in each project to help describe the workflow for devs
<frankban> also for charm/quickstart development we use lbox
<rick_h__> can't promise them, but try to
<jrwren> i don't know lbox
<rick_h__> frankban: we do for the charm? 
<frankban> rick_h__: yes
<rick_h__> ok, looks like we need some updating to the hacking docs
<frankban> rick_h__: +1
<urulama> frankban: this lbox? https://launchpad.net/lbox
<rick_h__> urulama: yes
<rick_h__> urulama: jrwren lbox is a tool written to help push reviews through reitveld 
<rick_h__> it allows for some nicer code review tooling and lbox helps sync with the launchpad merge proposals/etc
 * urulama was happy for a minute not to have to deal with new stuff ... oh well ... :D
<jrwren> i wondered what that .lbox file was in the charm
<rick_h__> yea, it runs a pre-pull request hook basically to make sure tests pass locally before pushing
<rick_h__> quickstart docs don't mention lbox either :/ 
<hatch> jcsackett found it
<hatch> https://github.com/juju/juju-gui/blob/develop/app/views/viewlets/charm-details.js#L93
<hatch> jcsackett see the e.halt() in that method? That's why it's not being called....e.halt() is the devil which we need to use because I bet the X is an anchor tag
<rick_h__> jrwren: urulama ok, good finds some old docs on lbox :) https://github.com/juju/charm-tools/blob/master/HACKING.txt#L29
<rick_h__> jrwren: urulama and I think last time we had to go the go get lbox route
<hatch> jcsackett so if so the X needs to be changed from an anchor into a span, then that e.halt() can be removed and then it'll work 
<rick_h__> sudo go get launchpad.net/lbox will install it globally or you can do it local/etc
<urulama> rick_h__: why sudo? isn't the go/bin dir enough?
<rick_h__> urulama: that's what I mean, you choice
<hatch> jrwren damn that safari thing sure sucks....
<rick_h__> jrwren: so from here, can you make sure to run the functional tests of the charm with what you've landed
<rick_h__> jrwren: otherwise it's a minor change and should be good, just want to make sure no tests were relying/checking that
<jrwren> hatch: SECURITY! :)
<hatch> "SECURE ALL THE THINGS!!!!"
<jrwren> rick_h__: yes, doing that.
<rick_h__> jrwren: ty much
<rick_h__> jrwren: let me know when you've got time to chat
<jrwren> was JUST going to run out to lunch. 
<jrwren> lets chat, then I'll run.
<rick_h__> jrwren: sorry, was meant to be hatch 
<rick_h__> jrwren: go to lunch, we're good
<rick_h__> hatch: let me know when you've got time to chat
<jrwren> oh, in that case, I'm running out for a bit. brb in 45min or less.
<hatch> rick_h__ 1 min
<urulama> jujugui: bye all, fun day ;)
<rogpeppe> urulama: g'night
<bac> bye urulama
<rick_h__> urulama: night 
<hatch> rick_h__ standup room?
<rick_h__> hatch: k
 * urulama gets embarrassed for checking out during daytime ;)
<rick_h__> hatch: new room
<hatch> nope it's full
<hatch> heh
 * jcsackett discovers he was disconnected from znc for some reason.
<jcsackett> hatch: is there any fallout to always calling addTarget on viewlets to the view manager? then the viewlet's close can just fire the change event.
<hatch> man all these hangouts have killed my battery
<hatch> jcsackett the only issue is that it may fire an event that someone up the chain is listening for
<hatch> so it'll react accidentally to the event
<hatch> there is also a performance issue....but neither of these are very big negatives tbh
<hatch> if you had like 100's then yeah it would suck, but there is only one so...
<hatch> jcsackett ^
<hatch> rick_h__ sorry it wasn't the oatmeal it was http://techcrunch.com/2014/07/04/just-be-present/
<rick_h__> hatch: I do like this "Iâd bet youâll find most of the ones without people in them pretty boring."
<rick_h__> hatch: but yea nice post
<hatch> I just found it funny because it showed up right under your post about your fireworks pics
<rick_h__> :) sometimes I've got good timing 
<hatch> haha
<hatch> well you can take some solace in knowing that yours are awesome
<rick_h__> hatch: so based on our call, did you want to shuffle the cards around? move the coding one back and the other back to code?
<rick_h__> jcastro: and if your two cards are one chunk feel free to combine 
<rick_h__> bah jcsackett ^
<jcastro> oooh, you're going to let me move your cards around? I'd _love_ to reprioritize stuff!
<rick_h__> hah!
<rick_h__> you and Mark S can duke it out
<rick_h__> I'd pay to see that
<hatch> rick_h__ yep I'll re-org them
 * rogpeppe is done for the day
<rogpeppe> g'night all
<jcsackett> rick_h__: i can combine, but it's two branches, one done but dependent on changes from the one currently on review.
<rick_h__> jcsackett: ah ok cool
<rick_h__> jcsackett: I didn't realize it was two branches knew you were working through the review of one
<jrwren> http://bazaar.launchpad.net/~juju-gui-charmers/charms/precise/juju-gui/trunk/view/head:/HACKING.md says juju-test is part of charm tools, but... it does not seem to be for me.  did this change from ppa:juju/stable -> ppa:juju/dev
<rick_h__> jrwren: it used to be, I think it's just a single file and in the tree now? I don't think you need that. 
<jrwren> which tree?
<rick_h__> jrwren: the charm
<rick_h__> jrwren: sorry, new laptop and don't have the sources locally. Working on looking. 
<jrwren> i'm looking too
<jrwren> oh! my bad.
<jrwren> i need both juju/devel and juju/stable PPA
<jrwren> poor assumptions here.
<rick_h__> jrwren: no, this is what I mean by the documentation being out of date on that. Apologies on our end. 
<rick_h__> they should be copy/pastable 
<jrwren> they are.
<jrwren> i assummed that I didn't need hte ppa the documentation wrote, because stable v. devel
<jrwren> charm-tools is in stable ppa, but not devel ppa.  Its really my bad.
<rick_h__> ah gotcha
<jrwren> maybe I'll update HACKING.md with a note stating as much.
<rick_h__> jrwren: yea,a if it threw you off it's likely to catch someone else as well
<jrwren> whoa, selenium. cool.
<rick_h__> putting the functional into the functional tests wheeee
<marcoceppi> rick_h__: is there a special flag in the gui that will show the icon on personal branches?
<marcoceppi> also, if so, what is that flag
<marcoceppi> ps <3
<rick_h__> marcoceppi: no, it's never gotten done. Only for local charms deployed
<marcoceppi> whyyy have you all forsaken meeeeeeee
<rick_h__> marcoceppi: because you didn't send enough pie
 * marcoceppi bakes a ton of pie
<rick_h__> marcoceppi: honestly, because i added a branch do it it and then it actually broke things and I've never gotten to write code again and it's never gotten fixed :)
<marcoceppi> rick_h__: any way to get this in to gui? We're looking down teh barrel where people want to demo stuff and are putting pressure to promulgate charms because they can't see silly little icons, but these charms are demoware not store stuff
<Makyo> Damnit, got pinged for an appointment I forgot about.  Will be back in a bit.
<rick_h__> Makyo: have fun
<rick_h__> marcoceppi: not until after machine view is out
<rick_h__> marcoceppi: we're under the gun for this. I'm happy to make it a task after that
<marcoceppi> and that's not going to happen by the 18th?
<rick_h__> heh, I'm hoping, but only just by the 18th
<marcoceppi> rick_h__: cool, should I open a bug to track this request?
 * marcoceppi is excited for machine view
<rick_h__> and then we're out of town so we'd start it the week after that
<rick_h__> hmm, thought we had a bug. Let me look
<rick_h__> marcoceppi: https://bugs.launchpad.net/juju-gui/+bug/1260854
<_mup_> Bug #1260854: we really need to support icons for all charms, at least as an option <juju-gui:Triaged> <https://launchpad.net/bugs/1260854>
<rick_h__> marcoceppi: I did one branch that did it for charms, but then that broken icons for bundles and caused us to not release it 
<marcoceppi> rick_h__: cool, thanks man
<rick_h__> marcoceppi: but since local charms work, that's a great way to get things deployed for a demo and then they get icons
<rick_h__> marcoceppi: not sure on the full path of the demo/etc
<marcoceppi> rick_h__: yeah, but for this demo they're going to want to do the zero to drag and drop deploy
<rick_h__> marcoceppi: gotcha
<marcoceppi> I do really love that local shows icon
<marcoceppi> makes charm dev a nice experience
<rick_h__> kadams54: around? 
<kadams54> rick_h__: yup
<rick_h__> kadams54: got a sec to chat in the hangout on the machine naming business?
<kadams54> Sure
<kadams54> rick_h__: ^
<rick_h__> kadams54: hmm, sitting in there 
 * rick_h__ tries again
<rick_h__> kadams54: https://plus.google.com/hangouts/_/canonical.com/daily-standup?authuser=1
<hatch__> oo rick_h__  you're gona love this new impl
 * hatch__ also loves it like 1B times more than the original one
<rick_h__> hatch__: woot woot
<hatch__> https://gist.github.com/hatched/d56c0a585397e9d8ef73
<hatch__> there's the preliminary diff of the scale-up.js file
<rick_h__> hatch__: cool, glad the conversation was useful
<rick_h__> kadams54: marked the bug as invalid and replied to the thread. 
<rick_h__> kadams54: feel free to ditch the card and move on to something more interesting
<kadams54> Will do.
<hatch__> making logical commits as I was working is also making it very easy to remove commits which are no longer valid from this refactoring
<hatch__> saving a bunch of work
<hatch__> rick_h__ kadams54  we are no longer removing 'new' ?
<jcsackett> hatch__: ok, i've been able to sort out QA fixes. can you verify QA good now?
<hatch__> jcsackett
<hatch__> yes
<hatch__> :)
 * jcsackett crosses fingers that you'll actually see QA good. :p
<jcsackett> ...yes, hatch? :p
<jcsackett> heheh.
<hatch__> haha
<hatch__> r u going to rebase into logical commits before landing?
<hatch__> want to do that before I QA? just in case
<rick_h__> hatch__: no, we're not for now. See email thread. 
<hatch__> rick_h__ cool will look
<kadams54> rick_h__, hatch__ : https://bugs.launchpad.net/juju-gui/+bug/1339289 for the follow up bug to improve logic around committed/uncommitted.
<_mup_> Bug #1339289: Stop using ID to determine if a machine is uncommitted <juju-gui:New> <https://launchpad.net/bugs/1339289>
<rick_h__> kadams54: k, adding a card to the backlog to look into it
<hatch__> kadams54 thanks
<rick_h__> kadams54: feel free to use that with any XXX 
<kadams54> Yeah, I'll add XXX comments as drive-bys in my next branch.
<hatch__> I'm too old and overweight for my hobbies, crashed hard yesterday kiting and I'm paying for it today.....can I be 21 again?
<rick_h__> hatch__: heh, I'm sore from the camping weekend
<hatch__> sheesh, don't start kiting then lol
<rick_h__> hah
<hatch__> I got to hit the gym
<hatch__> maybe get one of those treadmill desks
<hatch__> I wonder if I can jog and type
<hatch__> lol
<hatch__> I have an elliptical but those just don't quite work for the whole....desk + treadmill thing :)
<jrwren> We had treadmill desks at my last job, in the office. They were nice.
<hatch__> you could concentrate while walking and typing?
<jrwren> yes.
<jrwren> it had a slow max speed.
<hatch__> I'm worried I'd have to turn it off to think
<hatch__> lol
<jrwren> i didn't use it much.
<jrwren> I prefer standing desk.
<hatch__> yeah I'm rocking two mdf boxes ontop of my normal desk as a standing desk :)
<jrwren> nice.
<jrwren> i'm still on laptop on cardboard for my standing desk, i'll upgrade to something almost that hacky soon.
<hatch__> haha  
<hatch__> it works well, just slow to convert back to a sitting desk
<jrwren> I've not converted yet.
<jrwren> i'm doing pretty good at standing all day.
<jrwren> maybe, sit for lunch.
<jrwren> Yesterday, I sat for 10m because the docs I needed to read were a bit long :)
<hatch__> haha - yeah I'm thinking of going for a motorized standing/sitting desk for more room and then putting a recliner in my office for deep thinking bouts 
<jrwren> awesome. when I sat for that doc reading it was in my Ikea POÃNG :)
<jcsackett> hatch__: logical commits pushed.
<rick_h__> hatch__: woot watch arrived
<hatch__> rick_h__ lucky!! mine is 'being held by ups'
<hatch__> watever that means :/
<hatch__> jcsackett cool will qa
<hatch__> jcsackett while I do this want to kick off a new CI build?
<hatch__> it failed right-away
<jcsackett> hatch__: yeah, what's up with that failure?
<hatch__> no idea...
<jcsackett> it's an npm thing taht doesn't happen locally.
<jcsackett> hatch__: don't bother QAing. i just noticed something else wrong.
<hatch__> jcsackett when I deploy a charm (without mv) the inspector doesn't have units...
<jcsackett> for some reason units are not now rendering...
<jcsackett> yeah.
<hatch__> ok :)
<jcsackett> ...
<hatch__> sorry :)
<hatch__> i feel your pain
<jcsackett> i'm growing to *really* hate the inspector, and dispatch, and viewlets, and...
<jcsackett> :p
<hatch__> just imagine what it was like before that :)
<jcsackett> hatch__: i think you're going to be blocked on your card in perpetuity man.
<hatch__> nah I have faith in you
 * rick_h__ runs away for the evening. 
<hatch__> stepping out for lunch bbl
<rick_h__> I'll be back later, but hatch__ Makyo if you see huw before I do I've assigned him a card for tonight to help UX
<rick_h__> hatch__: Makyo please point it out to him if you see him first 
<hatch__> will do
<bac> ugh, i just told my phone 'juju set a timer' instead of 'siri'.
<rick_h__> bac: lol
<hatch__> haha
<Makyo> Erk
<jcsackett> hatch__: found and fixed it, need to change locations to get a reliable enough internet connection to push changes. should be just a few moments.
<hatch__> heh where are you in a cave? ;)
<rick_h__> says the man who had to cell signal it up for a week :P
<hatch__> lol, now shut your mouth
<hatch__> I have no comeback
<hatch__> that's all you get
<hatch__> haha
<jcsackett> hatch__: ok, everything looks good on my end now, and i've pushed.
<jcsackett> hopefully i didn't miss anything this time around, and there's nothing new broken. :p
<hatch__> :)
<hatch__> will look
<hatch__> jcsackett did you happen to check this in a real env so you can see if /charm gets dispatched on load?
<jcsackett> hatch__: no, actually, i did not. do you have  real env to check against, by any chance?
<hatch__> I don't I can spin one up if needed though
<hatch__> I'll do that
<hatch__> maybe....
<hatch__> hmm
<hatch__> not sure if working...
<hatch__> oh there it goes
<hatch__> slow internets today I guess
 * jcsackett laughs
<jcsackett> hatch__: if it doesn't dispatch on load properly, i think let's deal with it as a follow up so we can get this moving and get you unblocked.
<hatch__> :-)
<hatch__> in that case you might as well shipit while I do this
<hatch__> I +1d
<hatch__> because local testing was ok
<jcsackett> oh, i missed that. well, i'm curious to know. if it fails in a simple way, i'm game for looking into it.
<jcsackett> naively, i think it should just work--the only issue is model loading, and that's already handled.
<hatch__> ok it'll probably be 20mins before this is up, amazon is slow
<jcsackett> hatch__: hm. ok. maybe i should just :shipit: so i can get the next dependent (but thankfully *much* smaller) branch up for PR.
<jcsackett> hatch__: when is your EoD/
<rick_h__> jcsackett: +1 if the tests pass and normal QA is good then feel free to shipit and follow up with a good QA tomorrow. 
<hatch__> technically 40mins, but I'm going to get my branch up for review before I'm done regardless
<jcsackett> rick_h__: ok.
<rick_h__> jcsackett: it won't hold anyone back and we're not looking to do a release tomorrow. 
<rick_h__> jcsackett: but it is a good idea to check it out as the issue is particularly with live envs
<hatch__> gui is pending
<jcsackett> hatch__: how long is gui likely to take to spin up? no more than 5 min or so, right?
<hatch__> jcsackett iunno depends on what I have my ec2 instances set up
<hatch__> on
<jcsackett> ah.
<hatch__> still pending
<hatch__> :)
<jcsackett> hatch__: well, i'll go ahead and :shipit: and if you tell me it doesn't work on live, i know what i'm doing tomorrow. :)
<jcsackett> and i'll get the other PR up so we can unblock your work.
<hatch__> sounds good
<hatch__> jcsackett gui up
<jcsackett> hatch__: awesome. merge job still going. :p
<jcsackett> how's /charm load up on persistent?
<hatch__> I'm having an odd issue with juju
<hatch__> it's saying the juju-gui machine doesn't exist
<hatch__> when it's in the status list...
<jcsackett> that's...bizarre.
<jcsackett> hatch__: what v of juju? they just did a release, could be a bug?
<hatch__> 1.18.4
<hatch__> jcsackett crud there is bugs in your branch
<jcsackett> hatch__: what?
<hatch__> can't load the inspector on load 
<hatch__> Uncaught TypeError: Cannot read property 'get' of null service-config.js:97
<jcsackett> hatch__: this is only with persistent env, though?
<jcsackett> or did we miss something in QA?
<hatch__> well...yeah a real env...like what people /actually/ use lol
<hatch__> so how do you want me to do this? Do you want me to file a bug or will you just give it a go in the morning and work on a fix?
<jcsackett> hatch__: i'll make a card saying it's an issue in persistent.
<jcsackett> and i'll deal in the morning.
<jcsackett> hatch__: if you're game, second branch https://github.com/juju/juju-gui/pull/426
<hatch__> ok sounds good, I'll tear down the env
<jcsackett> hatch__: second PR is *much* smaller. :)
<jcsackett> hatch__: also, if you don't have a reviewer for your upcoming PR, i can try to get to it sometime tonight, if not first thing in the morning which i believe is before your day starts.
<hatch__> ok that sounds like a plan
<hatch__> I'll get on your review in a few mins
<huwshimi> Morning
<rick_h__> huwshimi: morning, want to chat when you get settled this morning please
<huwshimi> rick_h__: Sure. Call?
<rick_h__> huwshimi: sure thing
<rick_h__> huwshimi: https://plus.google.com/hangouts/_/guoc2hcs3slor7fh67oxp764dea?authuser=1&hl=en
<hatch__> jcsackett just finishing up my branch - I'll do your review before your SOD 
<jcsackett> hatch__: don't stay up too late; if it has to wait till you start tomorrow, that's fine.
<jcsackett> :p
<jcsackett> i'm out for a bit.
<hatch__> jcsackett looks like you have a bonified CI failure
<hatch__> jujugui lf a review and qa on https://github.com/juju/juju-gui/pull/425
<hatch__> thanks
<huwshimi> hatch: So the point of those state classes is that you should only need to ever have one applied to the container. In your branch it seems that you need to have two bits of UI showing so you're adding an additional state class instead of modifying the CSS to fix the real issue
#juju-gui 2014-07-09
<huwshimi> hatch: I thought I had all those states correctly created, but I must have broken something
<huwshimi> hatch: You're branch will be a lot simpler then too.
<hatch> otp sec
<hatch> huwshimi nope I should only ever have one class applied
<hatch> where are you seeing two?
<huwshimi> hatch: Oh, I thought here you set two: https://github.com/juju/juju-gui/pull/425/files#diff-0ed25fe35627272b0f6b928691ad7f44R165
<hatch> hmm looking 
<hatch> huwshimi right I'm setting two there because I need the per machine constraints message shown but not the edit constraints inputs
<hatch> so what it does it basically cascade setting only the last one
<hatch> or is it....
<hatch> hmm
<hatch> maybe that's a typo
<hatch> heh sorry long day
<hatch> lemme check
<huwshimi> hatch: Yeah, it looks like it.
<huwshimi> hatch: Which begs the question, why do you track the state of all the classes then, why not just set the one you want?
<huwshimi> The whole point of setting a single state class is so that you don't have to track the state of the UI
<hatch> right so that was a typo
<hatch> and because of that you make a good point
<hatch> well that's irritating
<hatch> huwshimi thanks I'll fix this up tonight 
<hatch> it's clearly been a bad few days lol
<huwshimi> hatch: haha, everything OK?
<hatch> oh yeah, this is just the branch that doesn't end
<huwshimi> hatch: I think you're just over complicating it :)
<hatch> it's gone from level 10 complexity down to about a 2 after your comments haha
<huwshimi> hatch: i expect that diff will halve in size :)
<hatch> at least
<huwshimi> :)
<hatch> huwshimi hey when is your EOD/
<hatch> ?
<huwshimi> hatch: In four hours
<hatch> nice - want to do a review/qa on my branch when I finish it?
<huwshimi> hatch: Sure
<hatch> awesome thanks
<hatch> I went out so now I'm back to get this darn branch done
<hatch> haha
<huwshimi> hatch: Good luck!
<hatch> alllllmost done
<huwshimi> yay
<hatch> it's fast when you've done it so many times over already
<hatch> :D
<huwshimi> hehe
<hatch> huwshimi https://github.com/juju/juju-gui/pull/425 let'r'rip
<huwshimi> hatch: Looks like you need a rebase with all those commits there before it lands
<hatch> yeah I'll rebase it down to 1
<hatch> sec
<hatch> well...once you qa/review it
<hatch> having separate commits helps remove unused code
<hatch> haha
<huwshimi> hatch: Code looks good, just qaing
<huwshimi> hatch: Looks good. See that wasn't so hard :)
<hatch> lol
<hatch> and rebased
<hatch> huwshimi so once this lands there is the car 'finish styling for scale-up UI' is now unblocked for you
<huwshimi> hatch: Nice one. Thanks for sticking with it!
<huwshimi> hatch: Yep, thanks.
<hatch> it's much better now - good idea with the css, even if you think it's my idea
<hatch> :P
<huwshimi> hatch: It was!
<hatch> lol ooookkkkk
<hatch> if it works out at scale I'll take credit then
<hatch> up until then...your idea
<hatch> lol
<huwshimi> haha
<hatch> I'm heading out, have a good day huwshimi 
<hatch> cya
<huwshimi> hatch: Night
<urulama> huwshimi: hello australia
<huwshimi> urulama: Good morning Slovenia
 * urulama goes through mails, always fun to see how work moves with the Sun across the globe :D
<rogpeppe> urulama, huwshimi: mornin'
<huwshimi> rogpeppe: Morning
<urulama> morning, rogpeppe
<frankban> rogpeppe: morning, how are you doing?
<rogpeppe> frankban: hiya
<rogpeppe> frankban: good, thanks
<rogpeppe> frankban: shall we continue?
<frankban> rogpeppe: sure, I'll be in https://plus.google.com/hangouts/_/canonical.com/gogogo in one minute
<rogpeppe> urulama: have you finished reviewing?
<urulama> rogpeppe: em, yes, sorry, LGTM
<rogpeppe> urulama: could you add the LGTM to the review, please?
<frankban> urulama: cool thanks can you add a comment?
<rogpeppe> urulama: i've just made the README.md change, BTW
<urulama> rogpeppe: it's in the tests as well
<rogpeppe> urulama: yup
<rogpeppe> urulama: all changed
<rogpeppe> urulama: (it was also in the sample bundles under testing/repo
<rogpeppe> )
<urulama> rogpeppe: anything else needed then the comment on https://github.com/rogpeppe/charm/commit/62a7a846075d080e6a36d0025f7fe6e85cd12144 ?
<rogpeppe> urulama: sorry, i don't understand the question?
 * urulama is still learning the process
<rogpeppe> urulama: ah, no, LGTM is good
<rogpeppe> urulama: or :shipit:
<urulama> rogpeppe: :shipit", ... 3, 2, 1 ... off it goes ... kaboom ...
<rogpeppe> urulama: actually, you shouldn't be the one saying ":shipit:"
<rogpeppe> urulama: LGTM or +1
<urulama> rogpeppe: after only a week, i'm not sure my "LGTM" counts for much as well ;)
<rogpeppe> urulama: :-)
<rogpeppe> urulama: we'll get a review from someone on juju-core too
<rogpeppe> urulama: we're looking into the existing store code, getting an idea for how it works and how we might need to change it
<rogpeppe> urulama: we wondered if you might care to join us
<urulama> rogpeppe: sure, not that i think i'll help much :D
<urulama> this?
<urulama> https://plus.google.com/hangouts/_/canonical.com/gogogo
<urulama> rogpeppe: noone there :D
<urulama> rogpeppe: i mean, only empty seats :D
<urulama> frankban: http://pastebin.com/2T5Szyd1
<rick_h__> morning
<jrwren> morning
<rick_h__> jrwren: how goes? Did you get the charm tests to run yesterday?
<jrwren> I did not.
<jrwren> I was going to ask how most folks do it.
<jrwren> Lack of local is a real bummer.
<jrwren> Do folks just use AWS? or their home openstack?
<jrwren> I've not pointed juju at my devstack just yet.
<rick_h__> jrwren: yea, run it via ec2. juju bootstrap ec2 && make test -e ec2
<jrwren> such a bummer. I've been really digging local :)
<rick_h__> jrwren: you can expense each month a chunk of time for work related stuff. It's why the startup docs wanted to get credentials unique for work 
<jrwren> sounds good.
<rick_h__> jrwren: yea, local is a game changer for dev workflows
<jrwren> I'm more thinking of the speed of execution.
<rick_h__> right
<urulama> jrwren: frankban said that it took an hour and even more sometimes on a local. so. no that useful :(
<jrwren> really?!?
<urulama> i can't see why either.
<jrwren> i was even considering tinkering with manual
<rick_h__> I thought there was some technical limitation. Local doesn't support some of the test cases I thought. It's a bit of a step-child as it doesn't have provider storage/etc
<urulama> jrwren: writing manual with automatically bootstraped machines (without add-machine ssh:IP)?
<rick_h__> manual is even more step-child heh
<jrwren> i don't know. I'm not familiar with juju manual at all.
<rick_h__> I used it for the CI setup on rackspace for bookie since rackspace isn't a supported provider
<jrwren> oh cool. that is GTK rick_h__ !
<rick_h__> it's cool, nice to be able to use the charms
<rick_h__> but a pita to manual bring up the machines/etc. 
<rick_h__> hazmat: wrote a layer over digital oceans api to work with the manual provider which smooths out some edges. 
<jrwren> i got reasonably good with nova cli at my last gig
<rick_h__> so manual provider is cool and useful for those cases, but not something I look to use unless I have to :)
<urulama> rick_h__: what if only a switch would be added so that the env is not bootstraped, just used?
<rick_h__> urulama: for the charm tests?
<urulama> on manual
<rick_h__> on manual...I'm not following I guess. 
<rick_h__> If you don't bootstrap an env,  you don't have state tracking services to do anything? 
<urulama> rick_h__: the env could already be bootstraped, that was a suggestion
<rick_h__> urulama: ok, so it's bootstrapped by something, so you've manually brought up a machine, done the bootstrap step, and now it's in manual mode still. I'm missing the bit that's changed. 
<jrwren> urulama: you mean run charm tests against already bootstrapped env?
<urulama> jrwren: yes
<hazmat> manual provider to me is the bees knees ;-)
<hazmat> need storage, need networking, need flexibility for the real world.. manual provisioning and placement.. automated of course ;-)
<urulama> hazmat: +1
<urulama> hazmat: and for development, just fill your laptops and desktops with VMs and pretend to have a cluster with 10+ hosts :D
<hazmat> urulama, yup.. i do that with manual provider as well.. https://github.com/kapilt/juju-lxc/blob/master/juju_lxc/add.py#L37
<hazmat> urulama, its a bit rough around the edges.. but i can create containers/machines offline on an airplane with it.
<jrwren> i saw the post where someone ran different openstack services in containers and at first I said, "WAT?"
<hazmat> need upload-tools cause juju for reasons illogical wants to do a full tools lookup on every add-unit/deploy/add-machine.
<jrwren> but for dev it makes some good sense
<hazmat> jrwren, prod is going that way too
<hazmat> jrwren, it also makes sense
<jrwren> hazmat: all in the same KVM
<hazmat> jrwren, or spread in containers across multiple kvms
<jrwren> http://astokes.org/juju-deploy-to-lxc-and-kvm-in-the-local-provider/
<hazmat> its just density and portability
<jrwren> oh yes, it makes good sense.
<hazmat> jrwren, the openstack cloudinstaller does just that containers in kvm
<jrwren> running nova-compute and glance that way doesn't make sense to me.
<jrwren> O_O
<jrwren> it does?
<hazmat> jrwren, they switched up since that blog post.. no longer parallel containers and kvms, they nest lxc in kvm now.
<hazmat> jrwren, yup
<jrwren> doesn't make much sense to me.
<jrwren> oh, THAT cloud-installer.
<urulama> hazmat: yes, offline is nice ... we made a demo with juju & openfoam charm where emergency response people could create local hpc clusters from their laptops on the site of the flood ... it was really cool :D
<urulama> hazmat: used ubuntu live, with preinstalled juju and openfoam charms on a usb stick, just use swithc, use the usb in all of them and reboot ... hpc cluster of the fly :D
<hazmat> urulama, nice
<jrwren> The thing I don't grok re: charm ftest is why --to 0 for juju-gui?
<urulama> jrwren: i am only guessing, but would say that you know that it's already up there so deploy of the charm is quicker
<jrwren> if that is the only reason, seems like tests could detect local and not --to 0
<urulama> jrwren: just guessing
<jrwren> but, I thought same thing, and just tried to hack w/out --to 0 in test and use local, and no go :(
<jrwren> and I"m not sure why it failed. Hopefully good things to learn.
<urulama> jrwren: these are the errors? http://pastebin.com/2T5Szyd1
<frankban> urulama, jrwren: colocating ftests to the bootstrap node is a decision we made months ago, when local provider wasn't supported by Juju (IIRC, but surely it wasn't as fast as it is now with templates). Functional tests needs are implemented so that for each test the GUI is deployed, so switching to colocation resulted in a faster test run (~30mins vs ~120 mins) due to the fact we don't have to wait for machines t
<frankban> o be provisioned. At the time, juju-test was also the preferred/suggested test runner to use for charms: it handles bootstrapping and destroying environments. I'd also be +1 on adding the ability to reuse an already bootstrapped environment to it. For those two reasons, it is currently impossible to run ftests on local envs, but that can be fixed in a relatively easy way, given a time slot to do that we never had
<frankban>  ;-)
<jrwren> thanks for the background frankban 
<jrwren> urulama: yes, those errors
<jrwren> anyway, now I can answer 'yes' to rick_h__.  It runs fine in ec2.
<rick_h__> jrwren: woot
<rick_h__> jrwren: ok, do you have a branch with any updates to the docs then? 
<rick_h__> jrwren: and if so put that up for review via lbox and we can work on moving your card across for today 
<jrwren> i'm not sure how to do this becuase I already pushed :parent on Monday?
<jrwren> will lbox let me brach review based on a different revno ?
<jrwren> or maybe I can branch from a revno and push that to my own branch for review?
<frankban> urulama, jrwren: http://bazaar.launchpad.net/~juju-gui-charmers/charms/trusty/juju-gui/trunk/view/head:/HACKING.md#L75
<rick_h__> jrwren: right, that's done and gone. However, the idea now is to not push to :parent, but look at updating the docs based on any experience getting the tests ready and to add lbox notes to the docs based on getting lbox installed, working to submit a branch, etc
<rick_h__> jrwren: so you'll probably be working on the docs as you go through lbox process and need to update the merge proposal a couple of times 
<jrwren> frankban: right, i'd love to be able to remove lines 75-77 from that file :)
<jrwren> rick_h__: ah! got it.
<frankban> jrwren: cool
<frankban> rogpeppe: when you are ready, I am in gogogo
<rogpeppe> frankban: ok, cool. am just reviewing a branch elsewhere
<rogpeppe> frankban: be with you soon
<frankban> cool
<jrwren> anyone have a good git to bzr rosetta stone?
<rick_h__> jrwren: hmm, not sure. What are you trying to do?
<mbruzek> I am trying to deploy a bundle and I am getting an error.  Wondering if you guys could help me with the problem.
<jrwren> remove the default remote
<mbruzek> Running this command: juju quickstart -n nagios-mediawiki-mysql /home/mbruzek/workspace/bundles/nagios/bundle/bundles.yaml
<jrwren> so when I push it wont go to the place it was last.
<mbruzek> Getting no errors in the console, but the UI gives me the following notification
<mbruzek> An error occurred while deploying the bundle: ('No charm metadata @ %s', 'precise/local:precise/mediawiki/metadata.yaml') 
<mbruzek> I see that the path is an issue, but I have edited the bundle to get a correct path and still not working.  
<arosales> Hello juju gui folks
<arosales> I pushed a bundle last night
<arosales> https://code.launchpad.net/~a.rosales/charms/bundles/cf-bundle/bundle
<arosales> but I am not seeing it be ingested. I wanted to check here before opening a bug.
 * arosales also not seeing https://code.launchpad.net/~maarten-ectors/charms/bundles/storm/bundle in the charm store
<rick_h__> arosales: looking
<rick_h__> arosales: sorry, take a sec have to get charmtools/ppas on here
<rick_h__> arosales: check to make sure they pass proof
<jrwren> does lbox infer incorrect branch url on charms?
<rick_h__> jrwren: hmm, don't recall. There's a flag to specify. 
<rick_h__> I think it tries to infer based on the .bzr/locations information so if you haven't pushed it up to your namespace or what not it might not be 100% right
<arosales> rick_h__, will do
<rick_h__> arosales: the file name needs to be bundles.yaml
<rick_h__> (note the s)
<jrwren> rick_h__: indeed. a push --remember fixed it
<rick_h__> arosales: charm proof will yell about it not being a bundle
<rick_h__> arosales: that's the same for the other bundle as well
<jcsackett> hatch: didn't see any PRs from you this morning. you get taken care of?
<hatch> jcsackett yep landed
<hatch> am I the only one who reviews the closed pr's every day? maybe I have a problem...
<hatch> lol
<jcsackett> hatch: i certainly don't, but that sounds like a good idea.
 * rick_h__ changes location to head home from the coffee shop
<jcsackett> hatch: did you get a chance to look at my second PR? it has a test failure, but it's spurious--pushed new revs now to force a rebuild.
<hatch> I didn't I thought the error was a bonified one for once....oops sorry I'll take a look now
<hatch> you can also manually trigger a build without pushing changes by logging into jenkins
<hatch> jcsackett just one small comment, firing up for a qa now
<arosales> rick_h__, thanks giving that change a try now
 * arosales will wait at least 30 minutes
<hatch> jcsackett qa issue, commented in pr
<jcsackett> hatch: dammit. :p
<jcsackett> ok.
<jcsackett> thanks.
<jcsackett> hatch: i replied to your other comment.
<hatch> cool
<hatch> wow chrome is such a poor browser compared to safari on every level except the devtools and available plugins
<hatch> it's sad really
<jcsackett> the dev tools are really nice though.
<jcsackett> and the extension community is better.
<hatch> yep...well and that safari is only available on osx
<hatch> but it's proof that a browser CAN be better
<hatch> rick_h__ I don't think seeing this for my watch is a good sign... https://www.evernote.com/shard/s219/sh/afefea06-4715-4a44-ad3c-542d1a6cd5b7/a2b67c51dfeda456142e3ccc022498b3/res/a7400332-a8b5-4510-b42a-ac45805d4243/skitch.png
<kadams54> Makyo: just noticed you're working on delete for containers
<kadams54> We may want to collaborate, since I have delete for machines
<hatch> I'm pretty sure those two are one and the same :) or really really close to it
<hatch> heh
<kadams54> Yeah, I think they'll end up being pretty much the same
<hatch> well don't they make the same call in the env?
<hatch> I may be mis-remembering
<kadams54> I don't know about the env, but they both fire the same event and the code to remove the token itself will be 99% the same.
<hatch> jujugui call in 10
<kadams54> Yeah, containers and machines are the same function call in the env
<kadams54> So pretty much dupe cards
<Makyo> kadams54, yeah, I noticed that yesterday, we'll have to chat as to the best path forward.  Didn't get too far with that appointment
<Makyo> jujugui call in 1
<rick_h__> what he said ^
<rick_h__> hmm, I feel alone, no one else there? 
<rick_h__> or does chrome hate me?
<rick_h__> jrwren: rogpeppe frankban ^
<rick_h__> bac: kadams54 ^
<rogpeppe> uru-afk: standup...
<rick_h__> jrwren: kadams54 bac starting without you then
<kadams54> joining
<Makyo> kadams54, https://plus.google.com/hangouts/_/gtwlcpt2ysfo6qtjdgghqrjfbaa
<hatch> jcsackett ping when you get that up and I'll take a look again
<hatch> and someone is cooking ribs.......
<hatch> concentration gone....
<jcsackett> hatch: just a moment. waiting for test run to finish.
<jrwren> so... i have two factor on my personal google account too... :)  I'll have to figure out an app specific PW for google
<hatch> rick_h__ so in the scale-up UI, if the user chooses to scale up with automatically place, does that mean we need to go and create machines and place the units on them? Or just put them in unplaced and let it auto place on commit?
<hatch> I'm guessing create machines and place
<hatch> else it's the same as manually place but with setting the constraints
<rick_h__> hatch: heh, that went back and forth
<rick_h__> at one point, they wanted that to still take you to machine view, but with the machines populated with the units
<rick_h__> hatch: so yea, it's got to be in the machine regardless
<rick_h__> my debate was around if we force users through machine view in that case
<hatch> well if they manually place we can open the machine view on submit
<hatch> if they want to auto place we can probably skip that
<jrwren> huh, and the LP/google 2-factor integration is different than default google 2-factor, so I still have to user personal acct. 
<rick_h__> hatch: right, that's what I was arguing for
<rick_h__> jrwren: yea, it defers to our own auth system
<hatch> rick_h__ then that is what we will do :)
<rick_h__> :) 
<hatch> oh look at that, unplaced units don't show up in the machine view
<hatch> :/
<hatch> they have to be committed first then they show up in both placed and unplaced
<rick_h__> you're not making sense so I'm going to stop listening lalalalalala
<jrwren> i'm gonna head for an early lunch right now, unless you are read for next step call, rick_h__ ?
<hatch> that's probably for the best rick_h__ ....
<rick_h__> jrwren: have a good lunch, commenting on your MP right now and can pick up after food
<hatch> rick_h__ ok now this branch is blocked until the  add units backend is fixed... http://comingsoon.jujucharms.com/:flags:/mv/ deploy mysql, switch to machine view, use mass scale up UI and add 5 units (see it added into the ecs but no unplaced shows up in the list)
<rick_h__> hatch: ok, I see that the mass scale up thing is borked. That's not this card though, that's outside of the inspector. 
<rick_h__> hatch: I'm confused here
<hatch> the same methods that the inspector needs to call is the same methods that calls
<jcsackett> hatch: finally up. phantomjs/mocha is getting crashier for me.
<rick_h__> hatch: ok, so sounds like this card is blocked, we need a new one for the bug (I don't see a card for it on the board) and that card needs to get worked on first?
<hatch> yes we need to get the newly created units to show up in the unplaced column
<hatch> so they can actually be placed
<rick_h__> hatch: ok
<hatch> I can create a card, unsched? or...
<rick_h__> hatch: yes
<rick_h__> hatch: create a card, mark it unsched as it's a bug in stuff that used to work that's failing now and we need to get updated
<hatch> I'm guessing that this bug has existed for some time...ever since we added the ecs stuff
<rick_h__> hatch: then we fail at noticing, filing a bug/follow up cards on it :(
<hatch> friday card for selenium tests comin riiiiight up
<hatch> :)
<hatch> jcsackett ok cool will qa again
<hatch> jcsackett so I feel like the test change does not cover all of the cases in which this bug existed....
<hatch> I see three places the event payload was changed but only one test updated
<jcsackett> hatch: wasn't sure testing was actually necessary; that an individual pane goes away when it receives the appropriate null is tested, and that metadata gets put in the right spot is tested.
<jcsackett> i can add tests for this specific coverage if you like, though.
<hatch> jcsackett well I mean that the proper state objects are fired
<jcsackett> hatch: fair; i'll update.
<hatch> cool thanks
<hatch> jcsackett +1'd with those tests
<jcsackett> hatch: cool.
<jcsackett> thanks for the review. :)
<hatch> unfortunately you're not quite out in the clear just yet :)
<rick_h__> marcoceppi: lazyPower do you guys have any other charmworldlib clients than charmtools?
<rick_h__> rogpeppe: is there an api doc or something we can generate for the charmstore api?
<marcoceppi> rick_h__: yes
<rick_h__> marcoceppi: can you shoot me a list or any hints on them? I need to document the clients we're effecting with the v4 api work
<marcoceppi> Amulet, charmtools, are the two biggest. There's maybe 3-8 more smaller tools built around that
<marcoceppi> I'll email you a list
<rick_h__> marcoceppi: <3 ty much
<rick_h__> bac: regatta day across the wifi beam?
<rick_h__> bac: oh, right NC. microwave over the wifi? 
<rick_h__> abentley: does the reporting site use charmworldlib/charmworld api? Or is it only talking to the charmstore api?
<abentley> rick_h__: otp
<rick_h__> abentley: rgr, ty
<abentley> rick_h__: We do use the charmworld API.  We use it to get a list of all charms.  I think that is all we use it for.
<rick_h__> abentley: ok thanks
<rick_h__> luca__: I thought we agreed in vegas that we were only doing one level of nesting. 
<luca__> rick_h__: thatâs fine with me
<rick_h__> luca__: that doing more thatn that broke down the UX a bit and was a rare thing 
<rick_h__> luca__: at that point we'd encourage using the cli to manage that special case
<luca__> rick_h__: I donât mind, itâs super rare so Iâm not fused :)
<rick_h__> luca__: ok cool. 
<rick_h__> luca__: I just wanted to make sure you also remember this conversation before I put it down in stone in the bug :)
 * rick_h__ goes to grab some food stuffs
<luca__> rick_h__: thatâs all good, I knew we made a decision but I didnât have it documented anywhere
<kadams54> rick_h__: got a question about this change-version.svgâ¦
<rick_h__> kadams54: what's up?
<kadams54> Is this for the Change version link in the inspector?
<kadams54> Currently a yellow dot icon?
<rick_h__> kadams54: yes, it's an icon for that text
<kadams54> rick_h__: It's an SVG; the original is a PNG. It looks like the PNGs get all sprited up. Should I convert it to PNG, or is this part of a transition to SVGs?
<rick_h__> kadams54: yes, I'd add the svg to our assets directory, but I think a png will work peachy there
<kadams54> OK
<kadams54> rick_h__: OK, this is what I was afraid ofâ¦ the icon doesn't work on the dark background of the inspector. It seems like it was made for a light background?
<rick_h__> kadams54: looking for the wireframes/images of the full thing sec
<rick_h__> kadams54: so looking at https://drive.google.com/a/canonical.com/#folders/0B7XG_QBXNwY1Vmowb25PejhJOTg
<kadams54> Yup
<rick_h__> the icon is a white one for the dark background, you're right that this icon doesn't match that up at all
<rick_h__> so we should push back on UX/spencer. 
 * rick_h__ looks for email thread
<kadams54> The icon also looks slightly different from the one in the visuals here
<rick_h__> kadams54: k, replied to the thread from spencer
<rick_h__> kadams54: will watch for replies
<rick_h__> kadams54: yea, I wasn't worried about that, they had some change of heart/etc. 
<rick_h__> but the icon being a dark icon makes it darn hard to be valid
 * rogpeppe is done for the day
<rogpeppe> g'night all
<rick_h__> rogpeppe: hey, night. 
<rick_h__> rogpeppe: if you get a chance, I ping'd earlier about the api for the charmstore
<rick_h__> rogpeppe: if you can take a peek at something for the morning I'd appreciate it so I can get these notes together for gustavo
<hatch> kadams54 so it looks like you were the one who added the create machine stuff in machine view panel https://github.com/juju/juju-gui/blob/develop/app/widgets/machine-view-panel.js#L449 is there a reason why you put this here instead of in the ecs? I feel like it should be in the ecs so I'm looking for input
<kadams54> hatch: feel free to adjust separation of concern as you see fit.
<hatch> ok sounds good - I have to add a similar functionality to the units and it feels like it should be in the ecs so the consumer doesn't need to care about extra steps
<hatch> any thoughts?
<kadams54> hatch: I suspect when much of this was setup ECS was also under heavy development by you and Makyo. It could probably use some tweaking as things settle in.
<kadams54> hatch: my only thought is that it doesn't look like there's much to these methods as it is. There's a call to db.machines.addGhost that might be able to move over to the ECS side, but it pretty quickly this.get('env').addMachines().
<hatch> no it's not much at all, but anyone who calls add_machine has to know to also call these other methods which is not clear
<kadams54> hatch: it looks like you could eliminate the _createMachine method and just have _handleCreateMachine call into the ECS directly.
<hatch> exactly
<kadams54> But we'll still need the placeUnit call on line 452, right?
<kadams54> separate from the createMachine call
<kadams54> rick_h__: I edited the SVG directly to flip to a white version of the icon: http://cl.ly/image/350E3u470Q2X
<kadams54> Still looks off - needs to be a little beefier.
<kadams54> We'll see what Spencer replies with.
<rick_h__> kadams54: cool
<rick_h__> kadams54: I'm going to move that card back then 
<kadams54> OK, I was just getting ready to mark it as blocked and move it to tracking :-)
<rick_h__> jcsackett: did you get to peek at huw's stuff? Or kadams54 could you look then?
<kadams54> rick_h__: sure, I can look at them.
<hatch> kadams54 sorry I linked you the wrong line :) I meant moving this line into the ecs https://github.com/juju/juju-gui/blob/develop/app/widgets/machine-view-panel.js#L524 
<hatch> oopsssss
<hatch> I think the comments still hold true :)
<kadams54> Yeah, that's fine
<rick_h__> thanks kadams54 
<jrwren> https://twitter.com/JayRWren/status/486920538485321728
<hatch> bad link
<hatch> you tweet a lot
<hatch> :)
<hatch> followed
<jrwren> i had bad homonym in that tweet. Deleted it
<jrwren> https://twitter.com/JayRWren/status/486923301647052801
<hatch> haha
<hatch> ahh the internet
<hatch> jrwren so do you live in a country-like area? 
<frankban> done for today, have a great week all!
<rick_h__> have fun frankban!
<jrwren> hatch: no, that is 2.5 miles from downtown Ann Arbor. A city of 100,000+
<hatch> oh crazy
<rick_h__> jrwren: back from lunch? Did you get the feedback from the merge proposal then?
<rick_h__> kadams54: thanks for looking at that. 
<jrwren> yes back.
<jrwren> got the feedback. trying to document whatever I just did.
<rick_h__> ok cool
<rick_h__> thanks
<jrwren> if you get time, we can talk next too.
<rick_h__> jrwren: ok, have a call in 1min and will ping after that
<hatch> rick_h__ just relocating will be in the room shortly
<rick_h__> hatch: rgr
<mbruzek> Hey guys I am trying to deploy a bundle with local charms.  No errors in the console, but seeing the error in the GUI. An error occurred while deploying the bundle: ('No charm metadata @ %s', 'precise/local:precise/mediawiki/metadata.yaml') 
<rick_h__> it doesn't support local charms
<rick_h__> you have to use just the deployer and it has some limitations
<mbruzek> thanks for responding rick_h__ I see you are in meeting.  I need to use local charms on power, because of the limited network.
<mbruzek> rick_h__, The command I am using is juju quickstart -n nagios-mediawiki-mysql /home/mbruzek/workspace/bundles/nagios/bundle/bundles.yaml
<mbruzek> So that is not supported?
<rick_h__> correct
<rick_h__> that's not supported
<jrwren> what is the difference between charms/juju-gui and ~juju-gui/charms/trusty/juju-gui/trunk ?
<rick_h__> mbruzek: there's an issue with local charms support over the api via the gui because of the way the versioning works and a juju-core bug we hit up against
<rick_h__> jrwren: ready to chat when you are, meet in the standup hangout
<jrwren> ready
<rick_h__> jrwren: hmm, I don't think there is a juju-gui owned charm is there? /me goes to check.
<mbruzek> rick_h__, I don't doubt it, just trying to figure out what the equivalent juju-deployer
<mbruzek> command
<mbruzek> Looks like juju-deployer -c ../../bundles/nagios/bundle/bundles.yaml is working
<tvansteenburgh> hey guys, is there a way to query the charmworld api for "all bundles that contain charm X"?
<rick_h__> tvansteenburgh: no, it's one of the calls we're adding to the new api as it's needed
<rick_h__> tvansteenburgh: the charm names are indexed so you can try to do a search for bundle:mongodb
<rick_h__> and it should find bundles with a mongodb charm in it, but it's not able to find bundles with cs:trusty/mongodb in it
<tvansteenburgh> ah, ok, that'lll probably suffice for now, thanks rick_h__!
<jrwren> so... how do I delete a review?  how might I update one? I'm used to reviewboard.
<rick_h__> jrwren: using reitveld you can lbox propose again
<rick_h__> it should update the existing merge proposal
<jrwren> ok.
<jrwren> how would I squash commits?
<jrwren> or does bzr kinda of handle that when merging?
<rick_h__> jrwren: yea bzr does that on merging. You get to assign a new single commit message
<jrwren> that is what threw me.
<jrwren> its been at least 4yrs since I used much bzr
<rick_h__> hah, welcome to a dual vcs world
<rick_h__> though you're here at a good time when there are at least two 
<jrwren> 2 is less than 3 :)
<jrwren> !np
<jrwren> is there a charmstore charm? :)
<rick_h__> jrwren: nope, but it's on the todo list for the charmstore work 
<jcastro> hatch, FYI for your charm: https://nodesource.com/blog/chris-lea-joins-forces-with-nodesource
<rick_h__> ah crap, this is a sad day
<hatch> jcastro what the heck....
<rick_h__> we'll have to get IS to allow us to do a manual repo now
<rick_h__> sudo bash -
<rick_h__> when you just don't give a flying poo
<hatch> yeah....
<jrwren> sudo -i ?
<jrwren> why was that ppa so important?
<rick_h__> jrwren: because it was the only way to get recent nodejs in a stable way
<rick_h__> jrwren: the whole company's JS devs rely on that one
<rick_h__> jrwren: and because it's a PPA it goes through LP build farms and it 'less evil' than most things
<rick_h__> npm/etc don't support older revisions for long, you have to update and LTS updates are so out of date at release time it's sad
<jrwren> trusty ships 0.10.25... isn't that new enough for almost everything?
<kadams54> suck
<jrwren> as for precise... oh well.
<kadams54> rick_h__: was reading through some older e-mail threads; do you know of any card to make autoselect the first machine and container when rendering machine view?
<hatch> kadams54 huw did that
<rick_h__> kadams54: huw finished it
<kadams54> Oh, that's why I'm not finding it in backlog or on deck.
<kadams54> Never mind.
<rick_h__> :)
<kadams54> Did that land yet?
<hatch> yop
<rick_h__> should be on comingsoon
 * rick_h__ tests it out
<kadams54> Yes
<kadams54> OK, I realized what my problem was.
<kadams54> I had no machines, so there was nothing to autoselect
<rick_h__> yea, working here
<rick_h__> right
<kadams54> But we still display the "Add container" link
<rick_h__> you have to deploy a bundle first
<kadams54> Or just create an empty machine.
<kadams54> What do we want to do with that link when there's no machines?
<rick_h__> kadams54: we're working with UX on the empty story
<rick_h__> kadams54: and they're getting some mockups so I'd not worry about it atm 
<kadams54> k
<kadams54> rick_h__, hatch: Another question: are unplaced units supposed to be deployed when I click on the Deploy button?
<rick_h__> kadams54: no
<rick_h__> kadams54: that might be related to stuff hatch is looking at? Not sure
<hatch> kadams54 this is actually a problem I'm running into right now too
<kadams54> rick_h__, hatch: I think that might be really tricky. They get added to the ECS because they're ghosted services in service view, so we want them to deploy in that context.
<hatch> yeah exactly
<kadams54> But in machine view, we don't want them to deploy until the user actually places them.
<rick_h__> hatch: kadams54 so we need to throw an error in the deployment summary when there are unplaced units remaining
<rick_h__> and disable the confirm/deploy button
<kadams54> Even when in service view?
<rick_h__> we'll have more cases like this when we get to things that aren't allowed to happen, unresolved conflicts in config, etc
<kadams54> That's going to throw a wrench in the whole drag, drop, deploy flow.
<rick_h__> kadams54: well this gets to the thing I thought hatch was working on. If you just deploy 5 units and don't pick to manual place, they should be auto placed on machines
<rick_h__> and not as unplaced units
<kadams54> Well basically that's what happens right now. They get autoplaced.
<rick_h__> but it's part of the debate going on around having to go through machine view to do a deploy at all
<rick_h__> kadams54: right, but they shold show up that way in MV
<rick_h__> so the user sees what's up
<hatch> yeah
<kadams54> As already placed?
<rick_h__> kadams54: we need to talk to luca about it tomorrow. I know we've talked about it both ways
<rick_h__> 1) as already placed. The default is one unit per machine, so create those machines, put those units in it, and wait for the user to deploy
<rick_h__> this is needed for aws anyway since you can't manual place 
<rick_h__> 2) even on one unit per machine, auto create the machines, show the units, but allow them to unplace/remove and manual place. When they hit deploy from service view, they get sent to machine view. 
<rick_h__> but not sure how that makes things any easier/nicer 
<hatch> rick_h__ mind scheduling that call after I start tomorrow?
<hatch> I can also join a little early if needed 
<rick_h__> hatch: sure thing, I'll bug them about it :)
<rick_h__> Makyo: https://bugs.launchpad.net/juju-gui/+bug/1329149 is fix committed right?
<_mup_> Bug #1329149: Destroying a service does not use ecs <juju-gui:Triaged> <https://launchpad.net/bugs/1329149>
<hatch> committed right
<rick_h__> yay for bug triage day, abentley's motivated me to go do it. 
<Makyo> rick_h__, yep
<rick_h__> thanks for the confirmation 
<rick_h__> I think bac programmed an irc bot while he was away :P
 * rick_h__ runs away, have a good night all
<jcsackett> kadams54: saw you reviewed huw's branch. thanks--i got sidetracked hunting down QA errors and stuff in my branch and completely forgot about his.
<kadams54> jcsackett: no problem.
<hatch> jcsackett there were more qa issues?
<hatch> did I do a poor job reviewing? 
<jcsackett> hatch: no, i meant after having done those huw's branch slipped my mind. just now i went to update the kanban board and realized my goof.
<jcsackett> but kadams54 saved the day.
<hatch> ohhh ok :)
<jcsackett> jujugui: anyone have an actual environment with an up to date version of the develop branch for the gui? i need to verify something.
<hatch> jcsackett I can spin one up...I'm guessing yours is running?
<jcsackett> hatch: mine is running on an lxc env. i just switched it from one branch back to develop, so it got an up to date develop, and now the buggy behavior is gone.
<jcsackett> i'm not sure if i've got a screwy thing going on, or what.
<hatch> fire one up on amazon?
<jcsackett> or if it's something only presents sporadically and i'm just getting lucky all of a sudden.
<hatch> seems like you have lots of lxc issues :)
<jcsackett> hatch: i have lxc issues for dev.
<jcsackett> juju running an lxc env is golden--and earlier i observed what you described in LXC.
<jcsackett> but fair enough, i'll spin up an ec2 env.
<hatch> I mean, I can spin one up too if you need
<hatch> just takes some time
<jcsackett> hatch: no need. if no one has one just running for some reason, it's no faster than me spinning up an ec2.
<hatch> cool
<jrwren> i'm outtie.  chat ya'll tomorrow.
<hatch> cya jrwren 
<huwshimi> Morning
<hatch> morning huwshimi 
<huwshimi> hatch: Hey
<hatch> how goes the battle?
<huwshimi> Not bad, yourself?
<rick_h__> morning huwshimi 
<huwshimi> rick_h__: Hey
#juju-gui 2014-07-10
<hatch> huwshimi doing alright, the mrs is trying to plan a winter trip to somewhere warm.....I just don't get it
<hatch> winter is for snow
<hatch> snow-boarding, snow-mobiling, snow-shoveling
<hatch> I don't see snow-beaching anywhere
<huwshimi> :)
<hatch> my android watch is still sitting in Minneapolis with 'Exception' in red on the ups site....
<hatch> I wonder if these watches weren't cleared with some standards body or something 
<hatch> it's been there for 2 days
<rick_h__> hatch: doh
<hatch> yep
<hatch> very doh indeed 
<rick_h__> hatch: what was the topic from today to talk to UX about?
<rick_h__> hatch: nvm, the walk through from scale up UX to MV/etc
<hatch> the transition from manually placed and auto placed, what should the user see when they switch to the machine view, and should unplaced units auto place on commit
<hatch> yeah
<hatch> :)
<huwshimi> Is it just me or is it strange to ever see the inspector and the machine view at the same time?
<huwshimi> The inspector has lost its context (the service)
<rick_h__> huwshimi: yea, it'll be replaced by the deployed services view. 
<rick_h__> huwshimi: which we've decided we can release MV 1.0 without, but want to come back to as MV 1.5 later this cycle
<huwshimi> rick_h__: Ah cool
<hatch> huwshimi the issue is what to do when you click 'manually place' then scale up....you have to switch to the machine view....so that should probably happen right away
<rick_h__> yea, lots of love needed there 
<hatch> I think I've got this unit thing figured out - tomorrow I'll start the real implementation 
<rick_h__> cool
<hatch> this env stuff is like the shibboleth of the GUI 
<hatch> you're not REALLY a GUI dev until you can figure out how the env interactions work lol
<rick_h__> heh
<hatch> we should probably document the flow in a flowchart of some sort
<hatch> it's definitely complicated 
<rick_h__> which part is this? 
<hatch> the flow from delta to db and back again, and the UI interactions to delta/db and back again
<rick_h__> ah yea
<rick_h__> huwshimi: you rock. Going through bugs and see it's already marked fix committed :)
<huwshimi> rick_h__: I'd fixed it before it was reported :)
<rick_h__> huwshimi: you're even better than I realized! 
<urulama> checking Hacking.md file and there is a reference on /var/lib/juju/units ... however, units dir is no longer there, there are containers and agents, right?
<urulama> jujugui how does lbox work with github? or how is proposing/merging process done there?
<urulama> (probably through web interface, but, well, better to ask)
<rogpeppe> urulama: i haven't used lbox with github
<rogpeppe> urulama: mornin' BTW
<urulama> rogpeppe: g'day to you, sir
<urulama> rogpeppe: what's the process of api proposal now that Francesco is out for a week?
<rogpeppe> urulama: since frankban is away, do you perhaps fancy continuing the store work along with me?
<rogpeppe> urulama: i guess we'll address the comments we can
<urulama> rogpeppe: sure, we can try, but you'll spent more time on explaining the details, 'coz i'm not familiar with them. is that ok?
<rogpeppe> urulama: i think that will probably useful for both of us actually
<urulama> rogpeppe: agree. let me finish something in the ftests, then i'll grab a lunch and come back 
<rogpeppe> urulama: cool
<rogpeppe> urulama: i've got a few things to do first anyway
<urulama> rogpeppe: my father some mushrooms in the woods yesterday, it would be a waste not to eat them :D
<rogpeppe> urulama: nice!
<rogpeppe> urulama: what kind of mushrooms?
<urulama> rogpeppe: ah, translation ... just a sec
<rogpeppe> urulama: (i'm keen on hunting mushrooms too)
<urulama> rogpeppe: these ... http://www.gobe.si/slike/Boletus_appendiculatus.jpg
<rogpeppe> urulama: not Boletus Edulis?
<rogpeppe> urulama: i like boletes
<urulama> rogpeppe: you're right. it's edulis
<rogpeppe> urulama: perfect
<rogpeppe> urulama: we usually dry the good ones and eat the rest
<rogpeppe> urulama: enjoy!
<urulama> rogpeppe: have you tried just freezing them? the flavour is kept. those are great for risotto
<rogpeppe> urulama: we do that too - usually after sauteeing for a little bit
<rogpeppe> urulama: which reminds me, we've got a few bags still in the freezer that need eating
<urulama> :D
<urulama> rogpeppe: we can start international juju-gui mushroom day :D
<rogpeppe> what an excellent idea
<rogpeppe> it's not yet the season for boletes here, but we found a load of st. georges mushrooms earlier (Calocybe gambosa) which were delicious
<urulama> nice
<rick_h__> urulama: what do you mean the process of the api proposal?
<urulama> rick_h__: morning 
<rick_h__> urulama: morning
<jrwren> morning
<urulama> rick_h__: they were sometimes on hangouts, working together, and franban is out for some time now
<urulama> morning, jrwren
<urulama> jrwren: i've made a small change to ftest so that you can run on local
<rick_h__> rogpeppe: let me know when you've got time to chat, urulama can chat as well. I've finished going through the docs and such and would like to hash out some questions and such
<urulama> jrwren: will push proposal later when i test it with other env that everything still works
<rogpeppe> rick_h__: will do. 15 minutes?
<rick_h__> urulama: the goal would be to get the work discussed broken into small single branches of work and added to the kanban board, then started to work on. 
<rick_h__> rogpeppe: sounds good
<jrwren> urulama: oh cool!
<rick_h__> urulama: lbox is specific to launchpad (LP) and reitveld. 
<urulama> rick_h__: yes, went to see the code and found out :D
<rick_h__> urulama: the normal process for github related things is based on the GUI process https://github.com/juju/juju-gui/blob/develop/HACKING.rst#typical-github-workflow with small tweaks
<rick_h__> http://ci.jujugui.org:8080/ has the charmstore CI for instance and does the tests/landing
<rick_h__> we're working with core on it for other parts of the code
<urulama> rick_h__: tnx ... so, if i push proposal on LP, does this reflect the github repo?
<rick_h__> urulama: what project are you pushing to?
<rick_h__> urulama: LP and github are seperate. we use one or the other
<urulama> rick_h__: will push for juju-gui, ftests support for local (really trivial change, but works for local now as well if one requires)
<rick_h__> urulama: the charm?
<rick_h__> urulama: ok, so that's only in LP and yes, uses lbox. jrwren submitted some docs to it yesterday. The hacking doc should help with that process
<urulama> rick_h__: np with the lbox, just curious about the LP vs Github
<rick_h__> urulama: we used to have all code on LP and we're slowing moving new things (and the big projects like the GUI) to github
<rick_h__> urulama: so we live in a dual tool world. 
<rick_h__> urulama: but anything new should be in LP
<urulama> jrwren: https://code.launchpad.net/~uros-jovanovic/charms/trusty/juju-gui/hackingreview/+merge/226270
<urulama> that's the simple change
<urulama> and it doesn't take much time to run on local
<jrwren> i tried something similar - removing the forced_machine paramter to the juju_deploy call - and it failed for me
<jrwren> as long as this works, I'm happy :)
<urulama> jrwren: yes, the deploy.go checks the value and add --to if it is not None ... 
<rick_h__> urulama: but what does this do to the test time on non-local?
<rick_h__> urulama: the majority of our users are using the gui on various clouds. That's the more important functional test run to some opinions. 
<urulama> rick_h__: it is pushed to 0 if it is anything than local
<urulama> rick_h__: it's the same as before
<rick_h__> ah gotcha
 * urulama needs to make lunch now ... starving :D
<rick_h__> morning bac, any better interwebs today?
<urulama> rick_h__: btw, whoever came up with debug-hooks is a genius :D
<rbasak> urulama: +1. I love it.
<rick_h__> hey rbasak how goes? 
<rick_h__> jrwren: so can you QA the changes from urulama on both local/ec2 and review? 
<rick_h__> urulama: can you add a card to the kanban board in review/maint for the work please?
<urulama> rick_h__: sure. 
<rbasak> rick_h__: good thanks. Hoping to get juju 1.20 in Utopic soon :)
<rick_h__> rbasak: cool, any word on the quickstart update into trusty?
<rick_h__> rbasak: oh, nvm see it's fixed release in the bug now
<rbasak> rick_h__: it's uploaded and waiting on the SRU team now. I should chase them really - it's been a week now.
<rbasak> Fix Released for Utopic - waiting on Trusty SRU approval.
<rick_h__> rbasak: ah gotcha
<rogpeppe> rick_h__: sorry, call went on a little longer than the 10 minutes i thought it was going to
<rick_h__> rogpeppe: all good
<rogpeppe> rick_h__: we could do it now, or we could wait for uros to get back from lunch
<rick_h__> well let's chat and if he gets back in time to join we can bring him in.
 * rogpeppe has grilled halloumi salad, mmm.
<rick_h__> rogpeppe: hangout room?
<rogpeppe> rick_h__: sure
<urulama> rick_h__: want me to join?
<jrwren> pulling bzr branch lp:~uros-jovanovic/charms/trusty/juju-gui/hackingreview to test it
<rick_h__> urulama: sure thing
<jcsackett> morning all.
<jrwren> good morning jcsackett 
<bac> hi rick_h__
<rick_h__> bac: howdy
 * urulama runs for that lunch now
<bac> rick_h__: hi.  unping.
<rick_h__> unping?
<bac> rick_h__: nm
<rick_h__> hah
<bac> meaning i resolved my issue and don't need to bug you any longer
<rick_h__> woot
<urulama> jrwren: so, i'll change the ftest some more, coz it's not the name that counts, it should be the type of the env and I'll add another parameter like JUJU_ENV_TYPE and set a check if it's local.
<jrwren> urulama: oh, ok. I didn't mind the magic name.
<jrwren> I did get an error, although I am not convinced it is related.
<jrwren> http://pastebin.ubuntu.com/7775331/
<jrwren> while you are making changes, could you add charm-tools and firefox to SYSDEPS? :)
<hatch> apparently the guys who cut my power/phone lines are coming in a bit to schedule a fix so I might pop away for a few minutes if and when that happens :)
<kadams54> http://tholman.com/giflinks/
<hatch> lol
<hatch> definitely run that past the UX team
<jrwren> omg kadams54 that is great.
<kadams54> hatch: we should open the machine view ux sync meeting with that.
<hatch> lol
<urulama> btw, found two more core bugs in the morning, bug 1340077 and bug 1340133 
<_mup_> Bug #1340077: if "default" is named to undefined env, the parsing fails <config> <juju-core:Triaged> <https://launchpad.net/bugs/1340077>
<_mup_> Bug #1340133: debug-hooks don't work in manual env <debug-hooks> <juju-core:Triaged> <https://launchpad.net/bugs/1340133>
<rick_h__> urulama: I think debug hooks not working is a known issue/missing feature. 
<jrwren> urulama: indeed, that failed test was some other issue. It worked second time I ran.
<jrwren> and runs in 56% the time as on ec2.  yay local.
<urulama> jrwren: ;)
<hatch> rick_h__ #1340147 bug is really the same as card 1326193 in project 1
<_mup_> Bug #1340147: Ghost services should be available to scale out in the mass scaling UI <juju-gui:Triaged> <https://launchpad.net/bugs/1340147>
<hatch> at least I think they are one and the same
<rick_h__> hatch: yea, I was going to chat with you about it
<rick_h__> hatch: because it seemed like that to me :)
<hatch> ohhh wait that's the MV mass scaling UI?
<rick_h__> hatch: but wanted to get them down on record
<hatch> then that's what Im doing right now?
<hatch> heh
<rick_h__> hatch: right
<rick_h__> hatch: it's your WIP
<rick_h__> so I wanted to see if this fits into your current work or not
<rick_h__> but been on calls all morning, sorry
<hatch> no problemo, I think it'll be solved but I'll keep an eye on it
<rick_h__> hatch: ty much
<hatch> jrwren are you a C# guy? twitter seems to think you're similar to a lot of C# people :)
<jrwren> I am.
<jrwren> I wrote C# for 7 or so years.
<hatch> cool, I've dabbled in it for Unity (3D) could never get used to the different uppcercased methods for working with arrays
<jrwren> ha!
<jrwren> if that is the only gripe, you'd adapt very quickly.
<rick_h__> psh, you mean it wasn't javascript
<jrwren> UnityScript is pretty close to javascript.
<rick_h__> ah
<hatch> yeah other than that it was pretty nice - learning it was somewhat difficult because it was always hard to find stuff that -wasnt- about some .net framework or something
<jrwren> Unity still runs on Mono 2.6.x IIRC, so some features are lagging
<hatch> yeah I didn't like unity script
<hatch> felt that c# was a better lang for that stuff
<hatch> I would of course prefer golang now :)
<jrwren> hatch: why not?  too different from javascript or too similar?
<hatch> jrwren the tooling wasn't there 
<jrwren> ah. that makes sense
<hatch> c# provided a better dev/debug experience
<rogpeppe> taking a 5 min break before standup
<hatch> jrwren if I remember correctly there is a c# framework that abstracts away those utility method oddities?
<Makyo> jujugui call in 10
<jrwren> hatch: which utility method oddities?
<hatch> like requiring different utilities to loop through arrays vs multi-dimensional arrays
<jrwren> oh. there might be. But that should be straightforward.
<jrwren> everything I learned about such actions I mastered thanks to the perllol man page :)
<hatch> yeah I just remember it was very odd to have to choose different array utility methods based on it's dimensions
<jrwren> oh! yes, is... odd.
<jrwren> I guess i contrast to C where there are no such methods and you are on your own and I was happy to have those methods.
<rick_h__> jujugui call in 2 kanban please
<rick_h__> jujugui I might be a few min late, wrapping up cross team call now
<hatch> yeah good point
<hatch> rick_h__ np, we'll sit and wait for you like good children
 * hatch grabs a knife and sticks it in the outlet
<hatch> lol
<hatch> jcsackett yes that was some epic lag
<hatch> :)
<urulama> jrwren: no need to do the review, i'll provide another pathc
<urulama> patch
<rick_h__> hatch: stand up over?
<jcsackett> hatch: i'm at our local hackerspace, and someone is using *all* of the bandwidth.
<hatch> rick_h__ yup we r efficient 
<rick_h__> woot!
<jrwren> jcsackett: crack the router and lock them out :)
<rick_h__> jrwren: got a sec?
<jcsackett> jrwren: :p
<rick_h__> jrwren: I did get a list of api endpoints from rogpeppe today. http://paste.ubuntu.com/7774899/ so on your card, I think getting familiar with stuff is valuable to continue
<rick_h__> jrwren: but just fyi I did get some data and maybe you can compare against it for a wrap up of that card of work
<jrwren> rick_h__: i got secs.
<jrwren> rick_h__: thanks.
<hatch> man my watch is STILL sitting in what I can only assume is customs in Minneapolis 
<rick_h__> hatch: canadians get no love
<rick_h__> lucky they shipped it out to you at all
<hatch> lol truth
<hatch> UPS is always a disaster when it comes to crossing the border 
<hatch> $50 'customs' fees and all that bs
<jrwren> rick_h__: tests/20-functional.test:from selenium.webdriver import Firefox
<jrwren> the tests are firefox tests.
<rick_h__> jrwren: ah gotcha cool
<rick_h__> jrwren: ignore me then
<jrwren> Its a good question.
<rick_h__> on my machine I use firefox nightly and link firefox to firefox-trunk
<rick_h__> so the idea of apt-get install'ing firefox was :( to me
<jrwren> hrm... good point.
<jrwren> maybe a different way to meet that dependency?
<rick_h__> naw it's all good
<rick_h__> I'm a freaky case
<rick_h__> if I want to I can skip sysdeps and mange them manually
<jrwren> i think we all are freaky cases
<rick_h__> :)
<jrwren> rick_h__: so, i'm getting familiar. Is there anything you would like to see from that pastebin that is not already in https://github.com/juju/charmstore/blob/master/README.md ?  Those 4 endpoints are documented there with examples
<rick_h__> jrwren: lol, no. I guess just confirmation that's up to date
<jrwren> maybe details like "the request can have unspecified serious"
<rick_h__> jrwren: naw, that's enough for my needs
<luca> rick_h__: Iâm getting an error when I join the hangout
<luca> rick_h__: Iâm going to restart
<rick_h__> luca: rgr
<urulama> rick_h__: using COLO or even JUJU_ENV_TYPE is not that great ... the juju-test does not pass another parameter to the test and setting global attribute is not a good idea, so, i propose that local test requires an environment that is named "local" ...
<rick_h__> urulama: :( ok, then I'd suggest wording the docs around it to be about the local specific and less around colocation
<rick_h__> what struck me was that the sentences leading up to the command all mentioned colocation, but the command didn't have anything about colocation in it
<urulama> rick_h__: i'm not happy with the solution either, the solution is to change juju-test command to pass parameters to the .test file
<rick_h__> urulama: that's fine. I'd rather we move forward with the imperfect solution but make the docs match up/explain
<urulama> rick_h__: but for now, let's just to the "local" thing. it does speed up the tests 
<urulama> jrwren, rick_h__: i've also removed the firefox dependency
<rick_h__> urulama: I think it's ok
<jrwren> could have the sysdeps make target depend on /usr/bin/firefox :)
<jrwren> and a /usr/bin/firefox target that does apt-get install firefox :)
<urulama> jrwren: but then there are /usr/local or /opt or ... 
<urulama> let's keep it out for now
<jrwren> ok
<jrwren> we've talked about it so much, i'll never forget it now
<hatch> jcsackett any luck on increasing te # of tries?
 * Makyo goes to lay down for a bit
 * rick_h__ runs away for a while, finally done with phone calls for a bit
<jcsackett> hatch: no, that didn't work, but i've figured out the issue, i think. almost done with an experiment to verify.
<jcsackett> hatch: bad news is we may need a better solution to this whole quandry.
<hatch> cool i'll be interested to know what the issue was
<hatch> :(
<jcsackett> my ec2 env is taking a very long time to finish loading new source for my experiment.
<hatch> it does
<rick_h__> it hates you
<hatch> rick_h__ when you have -only- a ghost service the mass-scale-up UI in the MV is still there, it should be hidden because we don't allow mass-scale-up on ghost services (or we should allow it)
<hatch> only ghost service(s)
<hatch> that is
<rick_h__> hatch: so the bug we talked about htis morning is allowing mass scale up of ghost services
<rick_h__> hatch: so the idea is that a ghost counts as a scalable service
<hatch> ahh ok right
<hatch> looking into that
<hatch> oh we just simply skip them
<hatch> heh
<hatch> dddddd
<hatch> fixed
<hatch> :)
<rick_h__> hah, yay then
<rick_h__> hatch: make sure to update the bug/card to go along with this branch then please
<rick_h__> kadams54: call?
 * hatch grabbing a bite
<kadams54> rick_h__: Bah, sorry, I'm back. Went out for lunch and forgot my plan was just to stay at Panera and use their wifi for the call.
<rick_h__> jcsackett: call? 
<rick_h__> kadams54: k, let me know if you want to reschedule/chat or not then.
<kadams54> Things are good from my end.
 * rogpeppe is stepping out for 30 mins to grab some supper
 * rick_h__ is feeling unloved, back to back no shows
<kadams54> I am a jerk.
<rick_h__> rogpeppe: back for the resources call?
<rogpeppe> rick_h__: am now
<hatch> hmm....hmmmmmmmm
<hatch> so we have a slight problem with how the ecs was set up to handle units....each unit is its own record
<hatch> so I propose that we just 'deal' with it sending multiple 'add_unit' calls and then go back and refactor this later
<hatch> ^ rick_h__ 
<hatch> it's a pretty integral part to how the add unit ecs stuff was written, place unit, etc etc
<rick_h__> hatch: sec otp
<hatch> sure no rush
<rick_h__> hatch: ok, so who da what?
<jrwren> i'm outtie.  rick_h__ suggestion for next desired.
<rick_h__> jrwren: have a good day, let's catch up in the morning then
<jrwren> k
<hatch> call?
<rick_h__> hatch: sure
<rick_h__> but my ears are falling off :P
<rick_h__> ok, running away until the AU call later
 * rogpeppe is done for the day
<rogpeppe> g'night all
<Makyo> Had the branch working until I tried deleting a unit that hadn't been committed.  Damn.
<hatch> :(
<Makyo> Will do that in this branch, as it's a little broken otherwise.
<jcsackett> hatch: can you look at this WIP pr? i've got a changeState that isn't getting picked up.
<jcsackett> https://github.com/juju/juju-gui/pull/428
<hatch> sure
<hatch> jcsackett what's `this` when it's fired?
<hatch> is it the View?
<hatch> jcsackett and this isn't handled by the retry? 
<hatch> I'm not sure that bailing just because the charm hasn't loaded yet is a good experience
<hatch> they entered that url for a reason right?
<hatch> odd I can't create a card for #1340147 it says it's already on the board...but a ctrl+f doesn't find it
<_mup_> Bug #1340147: Ghost services should be available to scale out in the mass scaling UI <juju-gui:In Progress by hatch> <https://launchpad.net/bugs/1340147>
<hatch> and searching says it doesn't exist
<rick_h__> hatch: make sure to show the backlog
<hatch> ahah I found it
<hatch> odd I had to show the backlog for the search to work...
<rick_h__> hatch: and I told JC it's time to bail on these cards. They were nice to haves but not something blocking machine view and we need to move this work out of the way
<rick_h__> hatch: ajax baby
<rick_h__> hatch: so for now we'll bail, file a bug, and try to get back to it, but MV or bust
<hatch> lol I mean "their search" also didn't find it
<hatch> ohh ok
<jcsackett> hatch: this is the view.
<jcsackett> hatch: and no, this actually occurs regardless of the other retry.
<jcsackett> and was actually occuring *before* my other branches. they just exposed it as an issue.
<hatch> ohh ok
<hatch> hmm
<jcsackett> hatch: yeah, i'm perplexed.
<hatch> lemme look deeper
<jcsackett> hatch: ok. i'm running out to dinner--if you leave notes on the PR i can poke at it more tonight. want this on its way to done before i get started tomorrow so i can get cranking on MV.
<hatch> sounds good
<huwshimi> Morning
<rick_h__> morning huwshimi 
<huwshimi> rick_h__: Hey
<hatch> morning huwshimi 
<huwshimi> hatch: Hey
<rick_h__> hatch: Makyo either of you joining the AU call?
<hatch> omw
<huwshimi> hatch: So, my question is how to update the unit count in the new scaleup UI.
<huwshimi> hatch: In the old UI it has this data-bind https://github.com/juju/juju-gui/blob/develop/app/templates/serviceOverview.handlebars#L9
<hatch> huwshimi 2 seconds I've already written that I'll get you the diff :)
<huwshimi> hatch: But I can't see how that's updated, to re-use it for our new UI
<huwshimi> ah
<hatch> huwshimi so I put this branch on hold while I do the ones I'm currently on but here is the diff that I had https://gist.github.com/hatched/dbdf85c23eeafb9daa44
<hatch> or at least...whatever was left
<huwshimi> hatch: Oh great, I'll see if I can make that work.
<hatch> you should be able to....as it does work ;)
<hatch> but we don't want to put the databinding in the input as I understand it
<hatch> the input I think is only for units we want to add
<hatch> not the current number
<hatch> at least that's how it's playing in my head and the mockups seem to go along with that
<huwshimi> hatch: Yeah, that's right
<hatch> I'm stepping away for a bit
<hatch> bbl......likely
<huwshimi> hatch: Thanks
#juju-gui 2014-07-11
<urulama> is it ok for a charmworldlib to have series hardcoded to "precise" in a charm.py? 
<urulama> ah, i see that default series in core/store is "precise" as well
<rogpeppe> urulama: is this in a charm?
<urulama> rogpeppe: hi
<rogpeppe> urulama: hiya
<urulama> rogpeppe: charmworldlib source
<rogpeppe> urulama: is that the server side of charmworld?
<urulama> rogpeppe: and in juju-core/store/ go source
<urulama> rogpeppe: yes, looking at server side
<rogpeppe> urulama: juju-core/store ?
<urulama> go juju-core code ... /launchpad.net/juju-core/store/server.go has DefaultSeries set to "precise" as well
<rogpeppe> urulama: ah, launchpad.net/juju-core is no longer a thing
<urulama> github?
<rogpeppe> urulama: github.com/juju/charmstore is the new place for it
<urulama> great :/
<rogpeppe> urulama: juju-core has moved to github.com/juju/juju
<rick_h__> morning
<urulama> morning there
<rogpeppe> rick_h__: hiya
<rick_h__> charmworldlib is the python client for the charmworld api
<rogpeppe> urulama: it looks as if the store DefaultSeries is just a holdover from old code and is not actually used anywhere
<rogpeppe> urulama: the new logic chooses the most recent LTS series (see byPreferredSeries)
 * urulama waits to dl the code from git
<jrwren> morning ya'll
<urulama> rogpeppe: went to see if there is a warning that github code should be used for core ... 
<urulama> morning, jrwren
<rogpeppe> urulama: there definitely should be some kind of redirect message
 * urulama might be blind ... https://launchpad.net/juju-core
<urulama> rogpeppe: this is the only thing that i found about gridfs limitations ... "Working Set: Serving files along with your database content can significantly churn your memory working set. If you would not like to disturb your working set it might be best to serve your files from a different mongodb server"
<urulama> rogpeppe: (regarding the charm/bundle talk we had with frankban)
<rogpeppe> urulama: we should definitely preserve that possibility, but there are definite advantages for an environment to use the same (automatically HA'd) mongo server for the charm store too
<rick_h__> jrwren: bac you guys up for a call this morning?
<bac> rick_h__: sure
<bac> rick_h__: now? when?
 * bac fetches headset
<rick_h__> bac: was hoping now, waiting to see if jrwren sees our pings
<rick_h__> urulama: so re: the gridfs stuff. In a normal small env I don' think there's much file serving going on. mainly some icon files really
<rick_h__> urulama: and moving this to theblues channel
<bac> rick_h__: just ping me when you're ready
<rick_h__> bac: let's hangout then and you guys can sync up later
 * rick_h__ wants to go get some breakfast/coffee
<rick_h__> bac: just the friday standup room please
<jrwren> rick_h__: yes, I'm up for a call.
<rick_h__> jrwren: https://plus.google.com/hangouts/_/calendar/cmljay5oYXJkaW5nQGNhbm9uaWNhbC5jb20.t3m5giuddiv9epub48d9skdaso?authuser=1
 * rogpeppe lunches
<bac> rick_h__: you were right.  through the azure dashboard i could see there was no endpoint created for :80 even though it is open and exposed in juju.
<rick_h__> bac: :(
<bac> rick_h__: opened it via azure and now can get in
<rick_h__> bac: I had to manually open our CI ports for saucelabs (8888 and 8889) so had been poking in there before
<bac> rick_h__: their separation between 'cloud services' and 'vm
<bac> is weird
<rick_h__> yea, I really am not a fan of a lot of their dashboard stuff. 
<rick_h__> it's confusing and sometimes hard to get back to where you were at one point
 * rick_h__ migrates to the coffee shop afk for a few min
<jcsackett> rick_h__: neither hatch nor i have been able to figure out why the stupid event to clear the inspector when the charm won't load isn't being picked up. 
<jcsackett> or at least, i infer he didn't find anything.
<jcsackett> rick_h__: you want me to just mothball this card for now and move on to an MV thing, since even the simple fix is taking awhile?
<rick_h__> jcsackett: sounds good
<jcsackett> rick_h__: ok.
<jcsackett> mothballing.
<jrwren> bac: you had to open it in cloud services or in the VM part?
<jrwren> also, sounds like a bug. open-port should do that,IMO
<rick_h__> bac: is this setup without the availability sets turned on to allow you to do this colocating?
<rick_h__> bac: or can you place via the cli even with the availability sets enabled
<bac> jrwren: vm section
<bac> jrwren: bug 1340756 filed
<_mup_> Bug #1340756: [azure] Service deployed to existing machine do not expose properly <juju-core:New> <https://launchpad.net/bugs/1340756>
<jrwren> cool.
<bac> rick_h__: availability sets are on, per the default.  (meaning i didn't disable them)
<bac> rick_h__: i guess the --to is only disallowed for 0 ?
<rick_h__> bac: I think it's only blocked via the api :(
<bac> rick_h__: actually, i was kind of surprised it let me do it
<bac> but only after the fact
<rick_h__> bac: and since the --to cli is working around that it works but failed for us in the gui
<rick_h__> bac: yea, just clicked in my head 
<bac> right , since QS uses api
<rick_h__> right
<bac> rick_h__: if we were smart, we'd redo the whole setup to use availability sets properly...
<bac> if we were really smart we'd save the hassle and move to ec2
<rick_h__> bac: that'd require smarts :) and AS don't do us good with jenkins and such since we'd need to deal with multiple units and charms like jenkins don't do anything with multiple units that I'm aware of
 * bac buries head in sand.
<rick_h__> bac: and yea, I keep justifying the pita with azure by saying we're using a rarely used cloud, doing some good qa, getting a discount, etc
<jrwren> do we typically use ec2 autoscaling groups?
<bac> rick_h__: we are being good corporate citizens.
<rick_h__> but it's not easy to swallow sometimes and you take the brunt of it right now
<bac> and we've improved azure provider through our immense pain
<rick_h__> jrwren: the only stuff *we* use (UI Engineering) is this azure thing
<rick_h__> we test and such in ec2, but don't have anything running
<rick_h__> jrwren: our production stuff runs on prodstack, an internal run openstack cluster maintained out of london DC
<rick_h__> jrwren: so no, we don't use ec2 autoscaling groups or anything
<jrwren> what about juju-core support?  it supports the azure availability sets, does it also support autoscaling groups?
<rick_h__> jrwren: not that I'm aware of. We're only recently getting into cloud specific tooling. We've trie dto be agnostic, but users want constraints based on machine types/etc
<rick_h__> so work on ec2 machine times, azure availability sets, openstack networking, are more recent tasks
<rick_h__> ec2 machine types 
<jrwren> got it. Thanks.
<kadams54> jenkins seems to be grumpy. Build failed right away with permission denied errors on the build-prod directory.
<kadams54> guihelp: On a related note: very small QA needed: https://github.com/juju/juju-gui/pull/429
<rick_h__> kadams54: hmm, maybe related to what bac was doing
<rick_h__> bac: ^
<bac> hey, that sounds like me
<bac> kadams54: sorry about that.  should work now.
<kadams54> np
<bac> rick_h__: on jenkins juju-gui-merge step, you have an extra build step that marks the merge as a failure.  what specifies that it is run only on failure?
 * luca has a lovely stack of changes to machine view
<rick_h__> luca: and you've got a 'release blocker' and 'non-release blocker' for eaech?
<rick_h__> bac: looking
<rick_h__> bac: it's that log text
<rick_h__> bac: if that text appears in the build log, it's a failed build
<bac> oh
<luca> rick_h__: possiblyâ¦. if possible I would like jump on your standup and talk through them quickly
<rick_h__> luca: let's do a post-standup with just MV folks
<rick_h__> no need for everyone to go through tbh
<luca> rick_h__: ok, sounds good
<rick_h__> luca: I'll ping once we're wrapping up if that's cool?
<luca> rick_h__: fine by me
<hatch> my watch is still stuck at ups....ugh
<rick_h__> hatch: heh, well my new watchband for mine shows up today
<rick_h__> get rid of this default goop
<hatch> have you used the watch yet?
<rick_h__> hatch: yea ,been using it all week
<rick_h__> git it last friday? 
<rick_h__> no, when I got back from holiday, tues
<bac> jujugui: the landing step for juju-gui on jenkins has been updated to serve the new branch.  please keep your eyes peeled for any funny business on the next few landings.  apologies in advance for any implosions.
<rick_h__> so day 4
<rick_h__> bac:  thanks, I'll update the jujugui.org DNS
<rick_h__> bac: and once we know it's working we can figure out how to move the comingsoon url
<rick_h__> bac: is it looking for specific dns? 
<rick_h__> bac: if so can you add jujugui.org as a hostname?
<kadams54> bac: this doesn't seem good: http://cl.ly/image/1G2F1K0S1k0b Currently have a build stuck because it's waiting for an available executor.
<bac> rick_h__: yes, not yet
<rick_h__> kadams54: hmm, looking
<bac> kadams54: restarted.
<bac> kadams54: dumb error message: no space left on device.  i think it was a permissions problem instead.
<kadams54> OK - build seems to be going now, thanks.
<luca> hatch: what watch did you get?
<hatch> the LG one
<hatch> if it ever friggen shows up
<luca> hatch: oh, cool
<bac> rick_h__: what are you going to do with jujugui.org?
<rick_h__> bac: I was going to point jujugui.org to point to the same host as the ci one
<bac> rick_h__: when we're ready, we just need to move comingsoon.jujucharms.com
<bac> rick_h__: oh, you want to not use comingsoon anymore?
<rick_h__> so ci. is ci, no ci is the qa site off of ci
<rick_h__> bac: I figured we'd move that as well, but figured this was easy to do
<rick_h__> and can be shorter :) 
<rick_h__> but comingsoon is all over the company so not wanting to change that at the moment
<bac> rick_h__: ok, well let me know what you want the fqdn to be so i can update apache ServerName
<rick_h__> bac: hmm, nvm. Looks like hover won't let me do a CNAME for the root
<rick_h__> that's kind of a pita oh well. 
<rick_h__> bac: so ignore me, let's just go with comingsoon and carry on 
<rick_h__> bac: maybe we should look at a static ip in azure though for this
<bac> rick_h__: you can currently get to the jenkins version as ci.jujugui.org:80
<rick_h__> bac: so that we don't have to update dns if we need to bring up a new jenkins/etc
<bac> rick_h__: ok, i'll look at that after everything is stable
<rick_h__> bac	rgr
<jrwren> where does apache fit into this?
<rick_h__> bac: I get a permission denied error looking at that
<rick_h__> jrwren: the GUI needs to be served out, apache is being used to serve the production juju gui files
<jrwren> oh the gui! :)
<rick_h__> jrwren: for your needs you don't have the same requirements
<rick_h__> jrwren: but bac is doing this process with the gui so you two are a bit in parallel
<luca> Machine view enables you to customise the deployment of your services. Drag and drop unplaced units from the new units column to add services to a machine. [Create a machine]
<rick_h__> luca: you don't say. :) 
<luca> rick_h__: would that work as onboarding?
<rick_h__> luca: thinking
<rick_h__> There's a confusion of units and services in there. Thinking of what is off or what can be more clear
<rick_h__> "Drag and drop the unplaced units of your services"?
<rick_h__> getting long :/
<bac> rick_h__: yeah, it isn't building now.  errors from smash for d3 stuff
<rick_h__> bac: ah ok
<bac> rick_h__: does that make sense to you?
<rick_h__> bac: you had some issue with the file ownership of the deps?
<rick_h__> d3 deps
<bac> rick_h__: well i did a chown
<rick_h__> bac: so no, it's not clear, just that you told me it was 403'ing because it was building and stuff is going on
<jcsackett> Makyo: can i pick your brain for a few on the "block deployment for unresolved conflicts" card?
<hatch> jcsackett that's going to be a little complicated
<jcsackett> hatch: lovely. but: it's the only MV release related card on the board, so off i go.
<jcsackett> hatch: can i pick *your* brain, then?
<hatch> yep
<hatch> joining the standup room
<hatch> one sec
<jcsackett> hatch: standup hangout?
<rick_h__> jcsackett: feel free to poke at the backlog on deck as well tbh
<jcsackett> ...great minds, or something? :p
<jcsackett> rick_h__: is stuff there likely to be more important?
<hatch> haha
<jcsackett> rick_h__: or is this a release requirement?
<rick_h__> jcsackett: looking sec
<rick_h__> jcsackett: i'm debating on the release requirement. I think so, but it's not very visible as it only happens in real environments with multiple simultaneous users
<hatch> jcsackett I don't seee youuuuu
<rick_h__> jcsackett: so as far as requirements go it's down the list as far as getting sign off on MV
<jcsackett> hatch: not there yet, rick_h__ might be throwing a different card my way. :p
<hatch> ok ping when ready
<jcsackett> hatch: ok. sorry for the confusion.:p
 * rick_h__ joins call
<rick_h__> jcsackett: my fault
<rick_h__> jujugui call in 5 kanban please
<bac> rick_h__: http://ci.jujugui.org/ should work now, for now.
<rick_h__> bac: rock on
<bac> permissions is hard
<rick_h__> kadams54: bac please coordinate to track your branch and landing that and making sure it auto updates then
<rick_h__> hatch: or jcsackett can you peek at kadams54's branch to help move that forward
<rick_h__> ?
<hatch> I think it's just a asset change right?
<bac> jujugui: what's the url for determining the git version being served?
<hatch> juju-ui/version.js
<rick_h__> bac: juju-ui/version.js
<bac> ty
<Makyo> jujugui call in 2
<rick_h__> Makyo: or hatch can one of you guys run the call today please, fighting a headache and have a bunch of background noise. Not up to it
<Makyo> Sure
<hatch> heh yeah a coffee shop probably isn't the best place for that :)
<rick_h__> hatch: hoping some day light and getting out of the house helped
<jrwren> am I really teh first one there?
<rick_h__> jujugui call in 1/now jrwren Makyo hatch 
<rick_h__> jrwren: wrong url, friday is different for the longer call
<jrwren> oh
<rick_h__> jrwren: check the calendar link please
<bac> kadams54: have you marked it :shipit: yet?
<kadams54> bac: No, waiting for QA from someone. *ahem* jcsackett or hatch :-)
<bac> ah, ok
<hatch> kadams54 it's going to be a little tough for me to do a qa on it
<jcsackett> kadams54: i'll get to it just as soon as call ends.
<hatch> branches are kind of messed up atm
<hatch> thanks jcsackett 
<rick_h__> luca: ping for standup
<rick_h__> luca: going once, going twice
<hatch> and....gone!
<rick_h__> luca: ok, called off for now
<rick_h__> that coffee just cost you
<kadams54> So apparently MI will be hit by a polar vortex next week.
<kadams54> For which I blame hatch.
<rick_h__> <3
<jcsackett> ...so did everyone leave the standup room while i restarted ff, or is google just screwing with me now?
<rick_h__> no 90 degree days for me
<hatch> polar vortex....rofl you must be watching American news 
<rick_h__> jcsackett: ^ we called it off
<jcsackett> rick_h__: cool.
<rick_h__> hatch: yea, going to get a 20F drop in temps for a couple of days
<rick_h__> woto!
<rick_h__> woot!
<jcsackett> hatch: well, he does live in the US, so it stands to reason.
<jcsackett> damn, send the vortex this way.
<kadams54> jcsackett: it'll be Canada invading the South.
<hatch> lol
<jcsackett> kadams54: if it means it's not 101 w/ the heat index i'll take it.
<luca> rick_h__: sorry, was sorting the images with Spencer
<luca> rick_h__: Iâll be ready in 2 mins
<rick_h__> luca: need everyone? 
<kadams54> jcsackett: I'm seeing highs in the mid 80s for you by mid next week.
<luca> rick_h__: who is everyone?
<rick_h__> luca: or can we delegate a couple of short straws?
<luca> rick_h__: I donât mind
<rick_h__> luca: kadams54 hatch Makyo and jcsackett 
<luca> rick_h__: Iâm happy for whoever to come along
<rick_h__> ok, two volunteers to rejoint the hangout?
<kadams54> nowhammy nowhammy nowhammy!
<hatch> oki joining
<luca> rick_h__: itâs looking a lot nicer >:D
<kadams54> I'll join
<rick_h__> ty hatch 
<rick_h__> luca: :/ this doesn't sound like releasing next week levels of changes 
<rick_h__> ty kadams54 
<hatch> ok i'm here and there is noone else there
<hatch> :'(
<luca> rick_h__: thatâs not the smiley I wanted lol
<kadams54> Are we back in the same room?
<rick_h__> kadams54: rgr
<rick_h__> luca: ok we're all in the room waiting
<hatch> again... :P
<hatch> haha I'm so funny
<luca> rick_h__: hatch just waiting for the images, 2 secs!
<luca> rick_h__: hatch just tying up loose ends
<luca> rick_h__: hangout linky
<rick_h__> https://plus.google.com/hangouts/_/calendar/cmljay5oYXJkaW5nQGNhbm9uaWNhbC5jb20.t3m5giuddiv9epub48d9skdaso?authuser=1
<jcsackett> rick_h__: you're good, or you need more to jump in?
<jcsackett> i'll take silence as "good". :p
<kadams54> bac: shipped my PR. Let's see what blows up :-)
 * bac ducks.  covers.
<rick_h__> jcsackett: all good
<hatch> haha 
<luca> rick_h__: lol
<rick_h__> luca: sorry, hit the wrong button
<rick_h__> anyway, thanks got the updates
<luca> rick_h__: no worries, Iâll send it over
<rick_h__> it does look nicer
<hatch> yup I'm also a fan
<jrwren> lunch. bbiab
<bac> kadams54: whoo:  http://ci.jujugui.org/juju-ui/version.js
<rick_h__> bac: kadams54 awesome
<rick_h__> bac: once you get the DNS updated, please let hazmat know and we're moved and off 
<rick_h__> and owe hazmat some drinks in germany for running that for so long
<bac> rick_h__: by that you mean, once i look into fixed ip address?
<hazmat> wohoo!
<rick_h__> bac: ah, yes sorry
<rick_h__> jumping around too much
<bac> rick_h__: i doubt we can transition to fixed ip in situ
<rick_h__> hazmat: on the drinks or getting to shutdown the instance :P
<rick_h__> bac: situ?
<bac> rick_h__:  i mean, we may have to tear down and rebuild to get a fixed ip.
<bac> dunno.  i'll see after lunch
<rick_h__> bac: oh, I'd hoped it was like ec2 where you can get a floating IP and associate it with the instance
<rick_h__> and if we bring up a new instance you just move the floating IP to point to the new one
<bac> rick_h__: maybe it is.
<rick_h__> and DNS stays the same without updates
<rick_h__> bac: k, thanks
<bac> rt
 * rick_h__ goes home from the coffee shop. biab
<hatch> lazyPower hey, whenever you get a moment could you have a chat with your compatriots about the requirement for port 80 for the Ghost charm? It's kind of in limbo right now and I think that's the only blocker for promulgation
<lazyPower> port 80 is not a requirement for promulgation. was teh last interaction with jose?
<lazyPower> if thast teh case, dont worry about it. i'll be in teh queue today - i've been slammed all week. and i'll get the final review done.
<hatch> yeah - ok cool thanks - no rush 
<hatch> lazyPower I just wanted to open up a discussion about it if port 80 was indeed a blocker because I didn't really want to include a server in the charm
<lazyPower> the idea of your app is that it deploys behind a LB anyway, regardless of an nginx charm or apache - so any fuss about port 80 is moot
<hatch> right
<lazyPower> just make sure that you have thought about any asset pipeline mojo
<hatch> yeah I include the ghost blog asset in the charm
<hatch> I'll be adding the ability to supply a different version once I have at least a single external user haha
<lazyPower> perfect - by the end of following the deployment tut in the readme if i have a working ghost app, its good. (you dont run as root, you took care of schenanigans, and you're not using AWS Metadata right?) should be g2g
<hatch> kewl
<hatch> it 'should' just be drag and drop to deploy 
<hatch> but the only crappy part is that the user 'must' read the readme for configuration of the actual ghost account
<hatch> but I imagine that's a similar situation for WP
<hatch> jcsackett are you working on #1339798 ?
<_mup_> Bug #1339798: When using Firefox and you drag a unplaced unit onto any drop zone the page shows a bad request <juju-gui:In Progress by jcsackett> <https://launchpad.net/bugs/1339798>
<lazyPower> wp has a setup phase post deployment
<lazyPower> if you dont configure a user, you still get teh setup wizard
<lazyPower> if you set a user, it runs the wizard for you
<hatch> ahh, ghost doesn't really have a wizard
<lazyPower> yeah, its a config file edit iirc
<hatch> you have to visit a special url in your app to set it up
<hatch> juju actions should make that setup easier :)
<lazyPower> hatch: you can include a script to be used via juju-run
<lazyPower> corey_fu has done that with teh allura charm - which is a stop-gap pending juju actions
<hatch> yeah - well really it's just that the first time they use it they need to visit a special url, so they would even have to know about the script by the readme
<lazyPower> you'll have the same problem with teh action
<lazyPower> or is the gui going to expose the actions?
 * lazyPower has no concept of whats coming from the gui wrt to actions.
<hatch> lazyPower that's one of the plans
<lazyPower> I thought i heard that at vegas, but there's been a whole ocean of information since then
<lazyPower> i find myself crossing wires often about what i remember vs whats been decided post sprint
<hatch> haha yeah - well, it was talked about in vegas, who knows what's happened since :D
<lazyPower> hatch: sorry about the delay with the review, it'll get done today though. You'll have a response of +1 or 'wait whaaaat' today. 
<hatch> lol np
<urulama> jujugui have a nice weekend everyone, c u
<hatch> you too, cya urulama 
<kadams54> you too
<hatch> 70 lines of test setup....5 lines per test....aww yeah
<hatch> maybe this function is doing too much....
<hatch> ;)
<hatch> jujugui lf a review and qa on https://github.com/juju/juju-gui/pull/430 
<hatch> plz and thx
<rogpeppe> happy weekends all
<rick_h__> rogpeppe: have a good weekend
<hatch> jcsackett you around?
<rick_h__> jujugui fighting this headache and going to go afk. If you need something shoot me a message in hangouts (chat) and it'll ring
<hatch> cya rick_h__  get betta
<jrwren> feel better (not putting your nick, cuz I don't want to ping you)
<jrwren> bac: can I push to ~yellow/juju-gui/ci-environment/ or does that need to be reviewed?
<bac> jrwren: it is pretty informal.  but if you'd like me to have a look that'd be ok too.
<bac> jrwren: since it is just a private branch, we can't really do a merge proposal in launchpad
<bac> jrwren: what changes have you made? have you pulled from LP to merge the changes i've pushed?
<jrwren> its just adding that mongodb package to that tools list. nothing else.
<jrwren> everything else I did was jenkins config.
<jrwren> now I just need to figure out how to open the port.
<bac> jrwren: ah, that must be done via the azure web interface
<bac> jrwren: if you just changed the bundle then please merge in my changes (i made lots of changes to the bundle) and then push it directly.
<bac> jrwren: since it has keys and stuff please ensure you're pushing to that private branch, not one in your namespace.
<bac> jrwren: do you have access to the azure dashboard?
<jrwren> i'll find out.
<jrwren> i do not
<bac> jrwren: what port/s do you want opened
<jrwren> 8080
<bac> on trusty-slave, right?
<jrwren> yes
<bac> jrwren: try now
<jrwren> 8080 connection refused
<bac> boo
<bac> jrwren: and that is the message you got before
<jrwren> not sure, let me see if I tried before.
<bac> jrwren: on trusty-slave i see a listener on 127.0.0.1:8080.  i think it needs to be listening on the eth0 interface 10.0.0.36
<jrwren> oh.
<jrwren> yup, thanks.
<jrwren> i'm looking right at that.
<jrwren> i guess its been a long week
<jrwren> hrm, well maybe this shouldn't be internet exposed?
<jrwren> ok, looks good, thanks for help
<bac> jrwren: great.
<bac> jrwren: what does the colon do here:
<bac> rm -rf $charmstoregopath || :
<jrwren> true
<jrwren> i should have spelled out || true
<jrwren> first time run that path won't exist and it would fail, so this is that case.
<jrwren> ya know, I'm going to change that.
<jrwren> i should test for dir and rm and if rm fails, let it fail.
<bac> i don't think it will fail with -rf but being safe is better
<bac> jrwren: i do wonder about putting it in /tmp, though, since it could be deleted on reboot.
<bac> jrwren: want to do a quick hangout?
<jrwren> 2 fail cases I ran into: 1. DNE, rm will return 1 and because of set... script ends.   2. other user (ubuntu) owns dir and rm fails
<jrwren> sure, lets chat
<bac> jrwren: i'm in https://plus.google.com/hangouts/_/canonical.com/daily-standup
<jcsackett> jujugui: can someone look at https://github.com/juju/juju-gui/pull/431 for me?
<jcsackett> jujugui: can someone look at my PR? https://github.com/juju/juju-gui/pull/431
<hatch> jcsackett still need that review?
<hatch> looks like it
<hatch> :)
<jcsackett> hatch: i'm looking at yours still as well. got started a bit ago and then got sidetracked. i'm about to QA it.
<hatch> cool, I hope you didn't get too much of a headache with yours
<hatch> I knew what the issue was when you started but you musta been offline
<hatch> and replied to your comment
<jcsackett> hatch: no headache at all. just spent some time getting re-acquainted with mv code.
<hatch> coolio
<hatch> I will qa yours soon, having some technical issues heh
<jcsackett> hatch: follow up is good.
<hatch> I'll land it if it's all good
<jcsackett> (in ref to your reply)
<hatch> excellent
<jcsackett> hatch: 1 qa thing. when i deploy after scale up, shouldn't the text field reset? it stays at whatever number i put in.
<jcsackett> seems odd that it doesn't reset to the state it was in when i opened it.
<jcsackett> hatch: marked your PR as QA OK, but we should file a follow up to deal with scale out UI thing.
<jcsackett> i am going AFK, so i'll :shipit: on mine later if it's QA OK.
#juju-gui 2014-07-13
<huwshimi> Morning
#juju-gui 2015-07-08
<lazyPower> ping rick_h_
<rick_h_> lazyPower: pong
<lazyPower> Hey rick :) i was going through my GH notifications and i  saw #111 - have you guys considered using something like Google Tag Manager?
<rick_h_> lazyPower: you're going to have to help me more vs #111
<lazyPower> https://github.com/CanonicalLtd/jujucharms.com/issues/111
<rick_h_> lazyPower: no idea what google tag manager is, this request came in to us from marketing to we added it per request
<lazyPower> As marketing rolls out more campaigns you're going to get more pixel/script requests - GTM eliminates that request.
<rick_h_> will have to get the back story/etc on tag mgr
<lazyPower> you include one script, and set ACL's to users - like include the GTM script in the template for the site right?
<rick_h_> lazyPower: so this is something to setup in GA to ignore certain requests?
<lazyPower> they can set pages/conditions to fire the script, and paste in their own.
<lazyPower> it integrates with GA but is a sep. product all together.
<rick_h_> lazyPower: oh, interesting. Have never messed with it
<lazyPower> http://www.google.com/tagmanager/
<rick_h_> lazyPower: so the one Google request triggers the data for others in a cascade fashion?
<lazyPower> yup, it actually is computed on request.
 * rick_h_ hates marketing speak sites that don't say wtf 
<lazyPower> well
<lazyPower> i know it well enough :)
<rick_h_> lazyPower: hmm, sounds like you should chat with alexia/$cloud-marketing-dude-i'm-blanking-on-name-of
<lazyPower> tom?
<rick_h_> lazyPower: but cool good to konw
<rick_h_> lazyPower: yes, that's it!
<lazyPower> well i thought i'd run it by you first
<lazyPower> as you're the grand poobah of this project's production deployment ;)
<lazyPower> i dont want to suggest something to them that you dont approve of
<rick_h_> well, I'm a noob whenit comes to this stuff. I just run OSS stuff and marketing is a four letter word :)
<rick_h_> so I'm just doing what I'm told atm tbh
<lazyPower> hah
<lazyPower> ok, sounds good. 
<rick_h_> so educating the big dumb guy is +1
<rick_h_> lazyPower: while you're around anything we need to do on https://bugs.launchpad.net/charms/+bug/1459345 ? Got the +1 from cory but wanted to see whatnext steps were for it as it's been a bit?
<mup> Bug #1459345: Review/promulgation request for the Redis charm <Juju Charms Collection:New> <https://launchpad.net/bugs/1459345>
<lazyPower> rick_h_: let me run the paces in CI and if its good i'll land it
<rick_h_> lazyPower: <3 I'm happy to wait in the proper line. I just wanted a dbl check we're in the right line at the dmv :)
<lazyPower> rick_h_: test passed manually - ci failed. one line fix on the charm. 
<lazyPower> do you mind if i make that fix and push it? or do you want the feedback loop so frankban commits and i'll push it tomorrow?
<lazyPower> bah, i'm going to make this fix and push it. this is silly to hold it up on a one liner
<lazyPower> https://code.launchpad.net/~charmers/charms/trusty/redis/trunk
#juju-gui 2015-07-09
<rick_h_> lazyPower: <3 my hero
<rick_h_> ty
<firl> anyone know if there is a way to have juju gui/juju point to a local repo? or how to deploy my own internal repo?
<rick_h_> firl: sure thing, there's a juju-gui-source config that can fetch from github
<rick_h_> firl: oh sorry, you mean for charms
<firl> rick_h_ yeah I want to deploy charms to an internal server
<rick_h_> firl: so you can't do that from the GUI, you can do that from juju via local: charms. 
<rick_h_> firl: and the juju-deployer will do some more things like git repos for the charms and the like if I recall
<firl> gotcha, is it pretty involved in pretty much making a private juju charm repo for the gui to pull from
<firl> or is it going juju-gui -> juju  for the charm browsing
<rick_h_> rick_h_: well it's juju that has to talk to it and juju only talks to the public charmstore
<rick_h_> bah firl ^ 
<firl> haha :)
<firl> so juju-gui just transparently talks to juju for the charms, k
<firl> then I should be asking in the #juju room probably
<rick_h_> firl: right, the only path around the charmstore is the local charm setup on disk which the deployer uses to pull things down and do the local repo
<firl> yeah I can deploy local charms non issue, and it works well
<firl> but for juju-gui to deploy new services from the local repo doesnât quite work
<firl> correct?
<rick_h_> firl: right, because that involves uploading the zips and typically they're not zipped so the browser is a bit limited there
<firl> kk, and juju-gui canât replicate a service that already exists to duplicate it ( not add unit )
<firl> because I could âpre load" the services, and juju-gui can see them all
<rick_h_> right, we might be able to set something like that up but the use case is limited enough we've not added it
<firl> gotcha, I could also just have the âzipâ file and drag it to the UI ? http://askubuntu.com/questions/409637/how-do-i-deploy-a-local-charm-from-the-juju-gui
<rick_h_> yes
<firl> thank you so much, do you know if the ability to have an internal charm store to deploy from is something that is on the timelime ?
<rick_h_> we're definitely working on making things better for locked down/offline environments, but no timeline atm
<firl> gotcha, maybe if the PoC goes well it can be something I can help with; Iâve been really enjoying juju-gui for a while
<rick_h_> firl: <3 definitely happy to gather feedback and work with folks
<firl> thanks mate
<jcastro> jrwren: hey, jim pharis is visiting me and he's wondering what the UI uses as it's js framework
<jcastro> aka what did we pick post-YUI?
<jrwren> jcastro: its YUI
<jrwren> jcastro: It's still YUI. Nothing migrated.
<rick_h_> jcastro: we're working on more pure JS, react (soon), and limping along because nothing is a good YUI replacement
#juju-gui 2017-07-11
<ionutbalutoiu> Hello, guys! Juju charms icons are broken Google Chrome 59.0.3071.115. Is there a known with this particular version ?
<ionutbalutoiu> Icons are properly shown in Firefox. though.
<ionutbalutoiu> (.. broken in* Google Chrome ... known issue* with ...)
<rick_h> ionutbalutoiu: no known issue. can you check the dev console and see if there's an error or something in there of note?
<ionutbalutoiu> sure
<rick_h> ionutbalutoiu: what page are they broken in? Just all icons?
<rick_h> or specifically in bundle visualizations? or something else?
<rick_h> wfm, but I'm on v61
<ionutbalutoiu> http://balutoiu.com/ionut/icons.png
<ionutbalutoiu> All icons. Trying to see them after the deployment is finished.
<ionutbalutoiu> looking into the dev console
<rick_h> ah ok, so this isn in the GUI itself vs in jujucharms.com 
<rick_h> ionutbalutoiu: so they'll be broken if you can't reach the charmstore website perhaps there's some sort of proxy/firewall issue?
<ionutbalutoiu> I used local charms btw.
<ionutbalutoiu> for all of them
<ionutbalutoiu> And this is a local GUI endpoint from the controller as well.
<rick_h> ionutbalutoiu: oic
<rick_h> ionutbalutoiu: hmm, so the urls should be to the icons from the local charms served from the controller I think. 
<rick_h> ionutbalutoiu: it'd be interesting to see what the url is that's 404'ing to cause the broken icons. I've not tested local charms icons myself lately. 
<ionutbalutoiu> If i do an inspect element, and open that particular link for the icon in chrome
<ionutbalutoiu> all good
<ionutbalutoiu> I see the image. The issue is that it's broken in the canvas.
<ionutbalutoiu> Firefox works without any problem. For the same GUI endpoint.
<rick_h> ionutbalutoiu: huh? so the url is a good image but it's not showing in the canvas?
<ionutbalutoiu> exactly. This is what I see in the canvas -> http://balutoiu.com/ionut/icons.png
<rick_h> ionutbalutoiu: hmm, ok. Can you file a bug at https://github.com/juju/juju-gui with the notes on the local charm, a sample url, etc. 
<rick_h> ionutbalutoiu: yea, but it's puzzling that you can see the icon based off the same url when the GUI cannot load it. 
<ionutbalutoiu> bugs are tracked on github right ?
<ionutbalutoiu> cool :)
<rick_h> ionutbalutoiu: <3 
<ionutbalutoiu> Issue created: https://github.com/juju/juju-gui/issues/3067
#juju-gui 2017-07-14
<dakj> hello guy, one question why I dont' view juju gui on a VPN connection while I see MAAS dashboard an Openstack?
<dakj> here the screen https://pasteboard.co/GAWHSRn.png
<dakj> anyone can help me?
<dakj> any suggests?
<dakj> hello guys, I dont' view juju gui on a VPN connection, while with other dashboard I 've not issue. someone can help me? thanks
<dakj> I've open also a post here https://askubuntu.com/questions/936248/not-view-juju-gui-on-vpn-connection
