#juju-gui 2013-08-12
<marcoceppi|away> help, anyone around?
<marcoceppi|away> Dragging and dropping an exported yaml from gui doesn't accept the file, I simply get  the file downloaded again
<marcoceppi|away> Google Chrome
<marcoceppi|away> and Firefox
<marcoceppi|away> about to demo, using jujucharms.com public deployment
<huwshimi> marcoceppi|away: Seeing the same thing. http://comingsoon.jujucharms.com is erroring when I try it too.
<marcoceppi|away> huwshimi: this is really unfortunate :\
<huwshimi> marcoceppi|away: Can you drag charms from the sidebar onto the canvas?
<marcoceppi|away> huwshimi: I can, I did mocked a large HA OpenStack deployment earlier
<marcoceppi|away> it works and it's up, but I've dropped internet connection a few times so I wanted to reload the page to get the last missing charm
<marcoceppi|away> I'm going to just wing it though for now
<marcoceppi|away> If it's not working post-meeting I'll open a bug
<huwshimi> marcoceppi|away: OK. I'm not getting any errors so the drop targets might not be working somehow. If you can check if it works in  http://comingsoon.jujucharms.com
<huwshimi> that would be good
<marcoceppi|away> huwshimi: I get an environment import failed, Unparsable environment data
<huwshimi> marcoceppi|away: OK, that's what I get too
<marcoceppi|away> which is a step up from it not accepting the target
<marcoceppi|away> for refernce: http://paste.ubuntu.com/5975549/
<marcoceppi|away> huwshimi: thanks for confirming, about to demo
<huwshimi> marcoceppi|away: Hope it goes well!
<marcoceppi|away> huwshimi: any idea on IE support paths?
<huwshimi> marcoceppi|away: For this issue?
<marcoceppi|away> huwshimi: no, just in general
<marcoceppi|away> what's the lowest (if any) supported version of IE?
<huwshimi> We try and support IE10 fully, but there are some outstanding bugs (https://bugs.launchpad.net/juju-gui/+bugs?field.tag=ie10)
<huwshimi> We are working towards them at the moment
<rick_h> marcoceppi|away: is the feature complete? I know there's work around deployer formats and such in progress
<rick_h> marcoceppi|away: I had that same issue while testing in sprints and was told it wasn't done yet
<rick_h> marcoceppi|away: if you got the unparseable environment data that might be the format switch 
<rick_h> marcoceppi|away: ie10 is only supported version and some known bugs in progress. https://bugs.launchpad.net/juju-gui/+bugs?field.tag=ie10
<marcoceppi|away> rick_h: well the file came from juju-gui
<marcoceppi|away> rick_h: I assuemd it could read what it created
<marcoceppi|away> rick_h: thanks for the info!
<rick_h> marcoceppi|away: right, but in the last month the format changed around? I'm only vaguely familiar
<rick_h> marcoceppi|away: https://canonical.leankit.com/Boards/View/102529849 is a card in progress
<marcoceppi|away> rick_h: yaml support was added, but I'm not aware of format changes. I don't follow the deployment that closely
 * rick_h isn't sure if you can read that :/
<rick_h> marcoceppi|away: yea, me either while is hurting getting you help
<rick_h> but a card in progress from bcsaller right now is titled "import deployer format"
<marcoceppi|away> rick_h: well that's good to know, since i'm writing an abstration layer for deployer files
<marcoceppi|away> rick_h: it's okay, I've still got the original deployment in a browser tab
<marcoceppi|away> we can make it through this
<rick_h> marcoceppi|away: yea, sorry. You can cli that?
 * rick_h isn't sure how that works cli -> gui and back
<marcoceppi|away> rick_h: well, I don't want to actually deploy it, since it's a huge openstack install
<rick_h> marcoceppi|away: ah, gotcha
<marcoceppi|away> rick_h: no, it was jujucharms.com gui -> disk -> gui (error)
<marcoceppi|away> I haven't actually done that deployment
<marcoceppi|away> just wanted to be flashy about it
<rick_h> I see
<marcoceppi|away> rick_h: huwshimi: thanks!
<benji> abentley: good morning; I have fixed up my branch, if you have a moment to look it over: https://code.launchpad.net/~benji/charmworld/featured-breakout/+merge/179503
<abentley> benji: Have you pushed your branch?  I don't see the fixes you're talking about.
<benji> "Pushed up to revision 343."
<abentley> benji: The current diff is still adding qa: None
<abentley> Line 104 of the diff
<abentley> My IRC app is flaking out.  Back in a sec.
<jcsackett> ccccccbljtrvvbbchjvnjubrkcnjhuhvbkrbvihcuunj
<jcsackett> ccccccbljtrvhgivfevfvkdfkbjegleuutfhchunbkkv
<jcsackett> =]\['\]
<jcsackett> ...i walk away from the computer. i come back and my dog is pawing at it on the coffee table.
<benji> abentley: fixed and pushed 
<jcsackett> ....when did my dog become a cat?
<gary_poster> heh
<abentley> benji: Also at 486
<benji> yow!  I really botched that merge.
<benji> fixed and pushed
<gary_poster> dentist, biab.  I am tweaking Huw's branch.
<abentley> benji: r=me
<abentley> benji: Wait a sec, I don't think this works, because you're storing charm_ids.
<abentley> benji: And I'm making charm-ids versioned.
<abentley> benji: So we would have to update the featured charm-id every time.
<abentley> benji: I.e. every time we ingest.  Which is exactly the kind of thing we don't want to do.
<rick_h> hatch: ping for when you get in. Need to chat login code. 
<benji> abentley: I thought that the (revisionless) charm ID would be good for featured charms, since only ownership changes or series changes would affect the ID
<abentley> benji: You are storing the soon-to-be-revisioned charm-id as an attribute at line 68, AIUI.
<benji> abentley: I am, and when it is revisioned we'll have to change that
<abentley> benji: I proposed that you store name, owner and series in the document.  That will work now, and it will work in the future, too.  But if we do it in the future, we also have to do a migration to change it.
<abentley> benji: So let's do it now, so we don't have to do the migration later.
<benji> abentley: my concern with that approach is that constructing the set of featured charms for the API would then become N searches, one for each charm.  Is that going to be fast enough?
<abentley> benji: I think we could construct a single search with an OR block at the top, so that we could use a single search to find all the charms.
<sinzui> orangesquad, can everyone join a hangout in a few minutes?
<rick_h> sinzui: rgr
<abentley> sinzui: Sure.
<jcsackett> sinzui: rgr.
<rick_h> sinzui: our standup hangout?
<sinzui> rick_h, Do you still have a link to it?
 * sinzui looks in browser history
<rick_h> sinzui: yea, in my calender sec
<hatch> rick_h: hey, just going to grab a coffee then ready to chat
<rick_h> oh shoot, I did but guess not. 
<benji> abentley: ok, I'll take a stab at that approach.  To be clear, running that query would result in all revisions of all featured charms and we would then drop the non-latest, right?  Or is there a way to query for only the latest revision?
<rick_h> hatch: will be a few
<rick_h> hatch: sorry
<sinzui> oh. maybe I do remember it
<rick_h> sinzui: https://plus.google.com/hangouts/_/9e4f8e4352c744b862c522c70e8fdde42f531f57
<rick_h> orangesquad ^
<jcsackett> orangesquad: be there in a moment.
<sinzui> adeuring, can you join this hangout ^
 * adeuring is coming...
<benji> abentley: can a revision of a charm ever be removed?
<abentley> benji: I am assuming no, for a given instance of charmworld
<sinzui> https://docs.google.com/a/canonical.com/document/d/1IP02eriK3TlaIeyL_3gXnCmPQphRDrtUi3jAm0kpGeU/edit
<hatch> sometimes I wish js had real interfaces
<rick_h> hatch: I'm about to relocate but while I'm in transit let me know if there's any reason I shouldn't do http://paste.mitechie.com/show/998/ to fix #1199392
<_mup_> Bug #1199392: can't view fullscreen charm details from url <charmbrowser> <juju-gui:In Progress by rharding> <https://launchpad.net/bugs/1199392>
<sinzui> orangesquad, I I think saucy decided the meeting is over.
<sinzui> I have nothing left to say
<rick_h> sinzui: thanks for he info. Going ot relocate back to real interwebs back home then. 
<abentley> benji: Sorry, was in a meeting.
<adeuring> abentley: could you please update staging to r341?
<abentley> benji: Yes, when charms are versioned "running that query would result in all revisions of all featured charms and we would then drop the non-latest", just as we're doing with other searches.  We might switch it to Elasticsearch later, since that's versionless.
<abentley> adeuring: Sure.
<benji> abentley: ok, thanks
<hatch> rick_h: i dont see any issue pending QA is ok
<abentley> adeuring: done.
<adeuring> abentley: thanks!
<rick_h> hatch: k, I wasn't sure on this login event and why this is going on. I'm not sure how best to get some tests in there because I have to url mangle and the test suite won't like it
<hatch> rick_h: yeah this is all wako becuase the login comes from the ws
<rick_h> hatch: k, thanks for the sanity check
<hatch> rick_h: maybe we should create our own 'url manager' which handles fetching things like window.location
<hatch> so that we can actually test these things
<rick_h> hatch: well I'd expect it in the ns-routing
<rick_h> hatch: but his code is diong it's own dispatch call
<rick_h> hatch: and only dispatching the small little path it knows/wants to know about
<hatch> well I'm just saying we can't unit test this login method because it pulls right from window.location which asyou said will bust up the tests if we change that
<hatch> so if we had it pull from 'fake().window.location'
<hatch> then we could mock it
<hatch> I'm not saying you should do this now
<hatch> :)
<rick_h> hatch: ugh, well I'd rather that it didn't use pathname at all, but it's fed that already upstream
<rick_h> but use the whole url
<hatch> yeah I was thinking that too but then we have to deal with parsing out multitutes of base urls
<rick_h> hatch: right
<hatch> still doesn't make it any easier to test though
<rick_h> hatch: well then I don't need my change at all :)
<rick_h> I just need to get the whole url into the navigate call
<hatch> I suppose you could change the regex's to parse the full url
<hatch> not sure if that's any less work though
<rick_h> hmm, maybe I don't care about that. If we hit this else block why can't I just use window.location.url?
<rick_h> vs the redirectPath. 
<hatch> because the redirectPath can be set by external stuff
<rick_h> hatch: guichat?
<hatch> sure
<Makyo> jujugui call in 10 kanban now
<gary_poster> Thanks Makyo.  Also, jujugui, orangesquad, early warning that this meeting may go over a bit, reviewing some of the changes from the past week..
<rick_h> story time!
<hatch> weeeee!
<gary_poster> :-)
 * hatch grabs his blanky
<gary_poster> lol
<rick_h> as my son would say "
<rick_h> "criss cross apple sauce with a bubble in your mouth"
<gary_poster> heh
<hatch> lol what?
<rick_h> it's how the kids sit at day care. Sit on the floor with criss-crossed legs and your mouth closed as if it had a bubble in your mouth
<hatch> ahh - smart teacher
<rick_h> and keep it closed tight so the bubble doesn't get out
<gary_poster> lol
<rick_h> oh yea, great for story time
<bac> so where does the apple sauce come in?
<rick_h> rhyming, kids love it
 * bac likes apple sauce
<gary_poster> jujugui call in 2
<gary_poster> sinzui jcsackett call ping
<sinzui> gary_poster, google refuses to believe I am logged in
<gary_poster> ack sinzui :-( proceeding with kanban for now but let us know if you want us to wait on anything
<Makyo> gary_poster, May be misreading the UX by unit bit, actually.  It looks like it's listing charms, rather than units.
<gary_poster> Makyo, ah, yes
<Makyo> gary_poster, Which we can do for up/downgrade, but not cross-grade, which I guess is okay.
<hatch> review time!
<Makyo> That would leave cross-grade as some manual step for CLI.
<gary_poster> Makyo, right, I thought crossgrade would be a bit much for the GUI
<Makyo> Yep.
<gary_poster> at least for now
<gary_poster> cool, thanks for reviewing it again Makyo.
<hatch> jcsackett: url for your branch?
<hatch> sorry my email is being dumb
<rick_h> hatch: https://codereview.appspot.com/12768043/
<hatch> thanks
<hatch> jcsackett, did you merge trunk into your branch?
<jcsackett> hatch: i believe so.
<jcsackett> hatch: what makes you ask?
<hatch> just curious
<hatch> I also added a note tot he code review wondering if we should rename it from browsercharm in the cleanup
<hatch> thinking that browser is going away :)
<jcsackett> hatch: we want to keep a distinction between browsercharm and charm right now.
<jcsackett> when we remove the charm model code we'll also rename browsercharm.
<hatch> right right of course
<gary_poster> hatch, I didn't understand what you meant in #1211356.  could you be a bit more concrete in bug?
<_mup_> Bug #1211356: service configuration is used in too many formats <juju-gui:New> <https://launchpad.net/bugs/1211356>
<hatch> gary_poster, sure - I added a card to talk about it on Friday as well
<gary_poster> cool thanks hatch (but I won't be there, so I want a clue too ;-) )
<hatch> gary_poster, oh right....ok updated
<hatch> gary_poster, does the new description make a little more sense?
<gary_poster> hatch maybe :-P .  on a charm, the config is about schema, while on the service, the config is about values, so that seems reasonable to be different, unless there's a simple way to unify them.  The template diff sounds clearer on the face of it.
<hatch> yeah this is mostly about requiring you to run a util parse method on the service data in order to render it
<hatch> Makyo, is there any QA required for your branch?
<Makyo> hatch, if you would be so kind: change 'python' to 'go' in app/config-debug.js and deploy a service - it should have units in the inspector, a health graph on the service, etc.  Should be quick.
<hatch> will do!
<hatch> rick_h, do you use irssi for irc?
<rick_h> hatch: yes
<hatch> I'm trying to decide between that or quassel 
<rick_h> hatch: weechat is the one to check out these days
<rick_h> hatch: I've just not bothered to switch my config over atm
<rick_h> since I've had this setup for so long
<hatch> it's been around for 10 years and isn't even at version 1
<hatch> lol
<rick_h> welcome to OSS
<hatch> what is this...a nodejs script?
<hatch> Makyo, review and qa done
<hatch> rick_h, hmm it looks pretty cool
<rick_h> jcsackett: qa issue: http://gui:8888/:gui:/charms/charms/precise/ceph-14/json/ auto reloads over and over
<hatch> nice UI....console
<rick_h> hatch: yea, if I didn't already have a setup I'd be using weechat and one day when I'm bored I'll port over
<hatch> I really want to setup a irc client which is always running so I can just hook into it as I move from computer to computer
<rick_h> hatch: yea, <3 
<Makyo> hatch, Until pyjuju is fully deprecated, I would assume the pyjuju sandbox will remain, but perhaps someone else from jujugui can comment.  +1 on splitting into separate files if possible, though.  Will make a slack task.
<hatch> have you used/looked into quassel? 
<hatch> Makyo, yeah I kind of figured as much, cool
<rick_h> hatch: graphical? no...I've not looked at it
<hatch> jujugui lf two reviews on https://codereview.appspot.com/12770043/
<hatch> rick_h, well it also has a server component 
<rick_h> yea, no thanks
<rick_h> just use weechat and be happy
<hatch> I'm going to built up my terminal and try and go cold turkey
<rick_h> let me know when you need a hang :)
<rick_h> hand
<hatch> tmux, weechat(I guess :P), vim?  
<rick_h> yep
<rick_h> when you get ready for mutt let me know :)
<Makyo> Haha
<hatch> haha no 
<hatch> that'll never happen
<rick_h> best email client out there!
 * rick_h hugs mutt
<hatch> ya know I say that.....but who knows!
<hatch> your horrible terminalness is rubbing off on me 
<rick_h> I'm a horrible influence, just ask the locals around me
<hatch> gary_poster, shall I continue on the inspector tasks? Did you want anything in particular done right now?
<hatch> I bet!
<hatch> rick_h, I love how mutt's feature list includes 'color support' lol
<rick_h> hatch: yea, very handy
<Makyo> Need to switch from screen to tmux one of these days.
<hatch> Makyo, yeah, even I know that's the right move :)
<Makyo> I'm just so used to screen.  Will take some effort.
<rick_h> Makyo: the pragmatic prog tmux book helped me switch. Really handy read
<hatch> rick_h, how does mutt handle html emails?
<rick_h> hatch: so I patch it through to w3m for the most part, or else I open them in chrome through mutt
<hatch> ahh ok - just curious really
<rick_h> yea, most I can read in w3m, a command line browser. Otherwise you can write the message out to /tmp and them chrome them
<hatch> the reason I'm considering vim at all is that I pretty much navigate through sublime with keyboard shortcuts anyways and switching between irc/sublime/terminal is getting to be a pita
<rick_h> have you ever heard of a tiling window manager? /me runs away cackling
<hatch> lol yes
<Makyo> So...vim + ctrlp \o/
<rick_h> Makyo: glad you like it :)
<Makyo> Yeah!
 * hatch goes to google ctrlp
<rick_h> see, this is what's great about sprints. You walk away with new side things that are awesome
<hatch> rick_h, Makyo ahh yes sublime does that with ctrl+p :D
<hatch> guess I could have assumed lol
<hatch> rick_h, I know I asked this before but I can't remember the answer - do you use a vim window manager or tmux for different windows
<rick_h> hatch: I use my tiling WM and lots of splits in vim. I don't use tmux to window/split
<hatch> ahh right right
<hatch> and is there anything in vim which has the idea of a 'project'
<rick_h> jcsackett: nvm I guess. I can't dupe now. The code is going away soon as well so carry on!
<rick_h> meh, that stuff is too much imo
<gary_poster> hatch, bcsaller, would it be reasonable for hatch to tackle the scale up/down ux?
<bcsaller> gary_poster: Thats fine with me, but I can get to it once I've finished this import stuff
<gary_poster> bcsaller, if hatch thinks scale up/scale down is a good task, then you could prototype how to use the sandbox + topologies to display bundles in the charm browser
<bcsaller> gary_poster: that sounds like a good use of time to me
<gary_poster> cool bcsaller 
<bcsaller> and fits well with the import story
<gary_poster> y
<hatch> alright I'll take the scaleup/down
<gary_poster> cool thanks hatch, bcsaller 
<rick_h> sinzui: wanted to check in on the deploy docs and process for charmworld? 
<hatch> bcsaller, did you have any work done on it yet?
<sinzui> abentley, I see staging is at r341. Do you have any reservations if we deploy it for rick_h?
<bcsaller> hatch: I didn't take it very far, I'd just started with the template. Mostly I moved to the import stuff. I'm happy to do a pre-imp call though
<abentley> sinzui: Let me check...
<rick_h> sinzui: I'm looking at 342 as my icon branch didn't really require updating staging. 
<abentley> sinzui: No, I'm happy.
<sinzui> abentley, fab.
<sinzui> rick_h, are you saying staging is 1 rev behind?
<rick_h> sinzui: yes
<hatch> bcsaller, sure in a bit - I'm just fixing some IE test failures
<sinzui> rick_h, we need to see it on staging to verify the charm can stop and start for the rev
<abentley> sinzui: Staging still isn't auto-updating on branch landings.
<sinzui> abentley, I was going to run the tests for 342 then juju set revno
<abentley> sinzui: Yes, that's what we have to do right now.
<rick_h> sinzui: ok
<abentley> sinzui: But you could also go straight to 344.
<sinzui> works for me
<rick_h> jujugui 2 reviews please for tiny diff to fix #1199392 https://codereview.appspot.com/12791043
<_mup_> Bug #1199392: can't view fullscreen charm details from url <charmbrowser> <juju-gui:In Progress by rharding> <https://launchpad.net/bugs/1199392>
<bac> rick_h: i'll do one
<rick_h> bac: thanks
<hatch> bcsaller, the upgrade story is on mockup v11 or did we have a different one for it?
<bcsaller> hatch: upgrade charm ux?
<gary_poster> hatch this isn't the upgrade story but the scale up/down story
<hatch> ohh ok so we are using the v11 version?
<Makyo> hatch, upgrade charm ux: https://www.dropbox.com/s/d6sc200adk2dszs/juju-gui-2-inspector-09.jpg
<gary_poster> think so.  verifying
<Makyo> Just so you can diff them
<hatch> yup pretty close thanks
<hatch> ok I'm going to grab lunch first then get started on this
<gary_poster> cool.  and yes, v11 should be it
<sinzui> rick_h, staging updated. Are you satisfied it has the feature you need?
<rick_h> sinzui: yes, thanks!
<rick_h> jcsackett: hatch can I interest either of you into a small itty bitty review? https://codereview.appspot.com/12791043
<hatch> mayyyybe
<hatch> rick_h, so you're going this way instead of a util method eh?
<rick_h> hatch: yes, a util method isn't needed and needs a home, and doesn't get me anything as then it needs tests that muck with the url
<hatch> I'm not sure I agree because this way we can't unit test this method
<hatch> although we had this discussion already
<hatch> haha
<rick_h> sure we can, override the getter as we talked about. It's 'a util method'
<rick_h> just in an attr atm right next to the code using it that needs it
<hatch> we can override the getter?
<rick_h> but it's ugly, I give you that
<rick_h> hmm, can't you override the getter of an ATTR?
<hatch> I didn't think so
<hatch> maybe you can and I've been missing out...
 * rick_h didn't look I guess. It's a function, why not be able to override it
<hatch> I think you have to pass in a named fn and override that one because I am pretty sure YUI doesn't give you access to the getter fn's after instantiation
<rick_h> ok, well this can be pulled into a util when someone else needs it. For now it seems like fixing this special onLogin event issue with a sledgehammer
<rick_h> and woot, autocomplete landing. /me keeps refreshing comingsoon 
<hatch> lgtm'd
<rick_h> thanks
<rick_h> gary_poster: sinzui so autocomplete is out the door and bug fix. Is there a priority from here I should take into account? inspector cards? other browser bugs? should we chat on some of the new ones that came out of IoM?
<gary_poster> rick_h, awesome~
<gary_poster> !
<gary_poster> rick_h, working up answer.  have a glass of water. ;-)
<rick_h> gary_poster: np
<gary_poster> rick_h, how about (dun dun dun!) the STICKY HEADER CODE! <sound echoes>
<gary_poster> rick_h, you can say no, but, your mission, should you choose to accept it...
 * rick_h pretends gary_poster was talking to hatch :P
<gary_poster> lol
 * hatch pretends he doesn't exist and can't be assigned this tasks
<gary_poster> lol
<rick_h> gary_poster: k, I don't have all the background. If you can link me to the notes/info I can look into it. I've seen a couple of links of demos from hatch 
<hatch> rick hop into guichat I can give you a rundown
<gary_poster> ...would be to get a simple variant of sticky headers working in the inspector and the charm browser.
<rick_h> hatch: k
<rick_h> gary_poster: ok, yea I've seen the card about a demo, but know there was some confusion abuot when/how it was used as well?
<gary_poster> hatch, do you have a link of the FF demo?  Please emphasize that we should go with something quick rather than something perfect--we can negotiate with  UX, but the user testing said load and clear that the sticky headers were helpful
<hatch> yep definitely
<hatch> I think I have the link somewhere I'll have to look
<gary_poster> thanks hatch.  rick_h, the confusion was that we thought it needed to be implemented a certain way.  what UX actually wanted seemed easier and more common, but turned out to be harder.  hatch knows where the bodies are buried.  I can hop on the call at a moments notice if desired
<rick_h> gary_poster: k, thanks. Chatting now
<gary_poster> bcsaller, I suspect you want to do this almost as much cutting your fingernails to the quick, but we do have you done for "Write documentation for Databinding Engine and Controller" and that is something that both of your reviewers requested.
<gary_poster> s/done/down/
<gary_poster> That would be a good task to complete before you move to the prototype.
<bac> hi sinzui
<sinzui> hi bac
<bac> sinzui: you got a sec so i can pick your brain?
<sinzui> yes
<bac> sinzui: guichat is occupied.  i'll make a hangout
<bac> sinzui: you are unavailable.  :(
<sinzui> I am here
<sinzui> in g+
<sinzui> I am trying to call you
<gary_poster> jujugui, could I have two volunteers for charm reviews today of frankban's branch, please?  https://codereview.appspot.com/12770044/
<bac> sinzui: it thinks i'm in a call with both of your identities and it won't let me join either!
<benji> gary_poster: I'll take one
<gary_poster> thanks benji
<sinzui> bac, ring me again?
<bac> yes, the non-canonical you
<bac> gah, killed ff and am trying again
<hatch> bcsaller, have a moment for that pre-imp?
<rick_h> gary_poster: autocomplete is on comingsoon. Do we still have the css build issue on there as it looks funky? I've got to run but will look into it in the morning if needed. fyi
<gary_poster> rick_h, ack, thanks, will investigate
<gary_poster> rick_h, was a conflict *and* a build issue. :-) resolved
<bcsaller> hatch: sorry, was at lunch, want that call now?
<hatch> yup lets do it
<bcsaller> http://pastebin.ubuntu.com/5959504/
<hatch> gary_poster: want to pop into guichat for a second?
<benji> abentley: I've upadated my branch to not depend on charm ID
<gary_poster> hatch will be there in 5
<abentley> benji: Looking...
<abentley> benji: While waiting on your branch, I've been working on removing doctype: https://bugs.launchpad.net/charmworld/+bug/1208477
<_mup_> Bug #1208477: Bundle metadata contains redundant "doctype" attribute <charmworld:In Progress by abentley> <https://launchpad.net/bugs/1208477>
<benji> abentley: hmm, I think doctype is pretty important for my branch
<abentley> benji: The caller should know what the document type is.
<benji> abentley: right, but how will the FeaturedSource know what kind of document it has been given?
<benji> abentley: I'm sorry, but I really have to run an errand right now, I'll be back later but I suspect we'll have to iron this out in the morning
<abentley> benji: The caller can pass that info in.  It already does for get_featured.
<abentley> sinzui: Could you please review https://code.launchpad.net/~abentley/charmworld/remove-doctype-attribute/+merge/179814 ?
 * sinzui does
<sinzui> abentley, r=me
<sinzui> that was nice without a single surprise
<abentley> sinzui: The surprise for me was that Elasticsearch doesn't support bulk updates.
<bac> sinzui: could you review https://code.launchpad.net/~bac/charmworld/create_replacemet-bundle-aware/+merge/179816 ?  it is the fix we discussed, i just pulled it out into a bite-sized branch.
 * sinzui looks
<bac> sinzui: with this fix, bundles added before running bin/es-update survive.
<sinzui> bac: Your have two tests of similar name, but they do different things with create_replacement()
<sinzui> bac maybe the names could be test_create_replacement_default_bundles() and test_create_replacement_with_bundles()
<bac> sinzui: i followed the existing pattern with charm/charms.
<sinzui> hmm.
<bac> sinzui: but i'm happy to change the names of them all to be clearer
<sinzui> bac, could you? That's all I ask. r=me
<bac> sure.  thanks sinzui
<hatch> bcsaller: what do you use for vim to allow you to use the mouse the way you do?
<hatch> do you use gvim?
<bcsaller> hatch: no, console vim. I think its :set mouse a
<bcsaller> for 
<bcsaller> all modes
<bcsaller> :help mouse will tell you 
<hatch> what was after 'its' my irc client turned it into an emoticon
<rick_h> hatch: colonset mouse a
<rick_h> gary_poster: thanks! looks much nicer
<hatch> rick_h: thanks :) I finally got zsh running on my laptop, it didn't want to run
<hatch> now trying to find a theme
<rick_h> hatch: theme? for the prompt?
<rick_h> hatch: because the colors are the terminal colors
<hatch> yeah alanpeabody is what I went with
<hatch> ehh I don't like that one either
<hatch> looks like I'll end up making my own hah
<huwshimi> Morning
<hatch> morning huwshimi
#juju-gui 2013-08-13
<gary_poster> hey huwshimi.  I tried to tweak some text in your branch.  Lemme get it up, one sec.
<huwshimi> gary_poster: Is this for the interfaces tab?
<huwshimi> (now related charms)
<gary_poster> huwshimi, hadn't gotten to that.  was on features
<huwshimi> ah right
<hatch> rick_h: still around?
<rick_h> hatch: kinda
<hatch> I'm trying to start up tmux with a config but it appears to be ignoring the tmux.conf
<hatch> my startup command is `gnome-terminal -e tmux --maximize`
<rick_h> hatch: it's .tmux.conf?
<hatch> it is
<rick_h> and in your ~ dir?
<hatch> if I go `tmux source-file .tmux.conf` once it starts
<rick_h> so start a terminal (gnome-terminal)
<hatch> then it executes it properly
<rick_h> and then `tmux` and see if you get any errors?
<hatch> well I'm in tmux
<hatch> `-e tmux`
<hatch> actually if I do that again
<rick_h> hatch: right, just wondering if launching it that way isn't displaying some error in the conf file
<hatch> it also doesn't open it
<hatch> ohh
<hatch> ahh there we go
<rick_h> cool
<hatch> I had a detached session
<hatch> so it wasn't re-loading it
<hatch> sorry to bother :)
<rick_h> gotcha, cool
<hatch> trying to figure out how to make a real shortcut for ctrlp
<hatch> having to type :CtrlP is a little excessive
<rick_h> hatch: ctrl-p should do it
<rick_h> unless you've got something else on the keymapping
<hatch> yup I had
<hatch> fixed
<hatch> heh
<gary_poster> huwshimi, https://codereview.appspot.com/12734043/ LGTM with comments, only one of which might be annoying to address
<huwshimi> gary_poster: Thanks, I'll take a look
<gary_poster> Thanks huwshimi.  I won't be around (hopefully!) so if you need to make a change to what I've done, consider yourself to have received a blanket blessing. :-)
<huwshimi> gary_poster: Thanks :)
<hatch> don't worry, I'll be back in a couple hours
<hatch> so I can reject it for you
<hatch> :P
<gary_poster> :-P
<frankban> gary_poster: morning, do you have time for a quick call?
<gary_poster> hey frankban, absolutely
<gary_poster> frankban, in guichat
<frankban> gary_poster: cool thanks
<gary_poster> rick_h, thanks for taking up huw's branch.  want me to take a look at it, or are you just going to land it?  either would be fine
<gary_poster> (I mean your version of the branch)
<rick_h> gary_poster: if you're ok with the change at the bottom of https://codereview.appspot.com/12853043/diff/1/app/subapps/browser/views/charm.js?column_width=80 I'm happy to land it from here
<rick_h> gary_poster: basically I think the real issue was trying to activate a non-existant tab and wanted to check/fix that
<rick_h> gary_poster: this means old urls will default to the summary tab vs the 'redirect' approach
<gary_poster> rick_h, sounds good to me, and code looks good.  ship it. :-)
<rick_h> gary_poster: rgr, thanks
<frankban> gary_poster: I was thinking: do we really need to watch a single deployment or is it ok to watch them all, leaving to the client the joy to filter changes if it is interested in only one deployment? 
<gary_poster> frankban, lol
<gary_poster> frankban, uh, I guess it could be all?  And then the client remembers which one it cared about?
<gary_poster> and if you reload the page, it doesn't matter, because it is all the same anyway?
<jcsackett> gary_poster: hopefully quick question for you on a todo you've noted in models/charm.js. it's the bit about verifying if is_subordinate or subordinate is passed from the env.
<gary_poster> jcsackett, gotcha, yeah?
<jcsackett> i was wondering how to go about verifying that on both py and go? i need to verify two other things being passed up as well.
<jcsackett> i'm *guessing* i can check py with rapi.
<jcsackett> but i have no idea about go.
<jcsackett> thoughts?
<frankban> gary_poster: yes, and the first message when you watch all is the complete history  of all the deployments, except for the completed ones, in which case you just see them in a completed status
<jcsackett> alternatively we can punt on this and leave the checks in place for now; i've audited the code and there was no meaningful cleanup to do until we delete models.Charm, and this stood out as one possible leftover, but i suppose it's not pressing.
<gary_poster> jcsackett, yeah you can use rapi.  For go, three thoughts.  First, IIRC if you start the GUI up in dev mode the log will include socket communications.  You could certainly hack it to do so.  Second, in Chrome I think you can see the socket communications. Third, benji added a control-shift-d option to save the websocket log to a file.  I don't remember the details, but it might be ideal.
<gary_poster> jcsackett, if it's easy and/or relatively easy and interesting, sure, let's do it. :-)
<jcsackett> gary_poster: would that approach work in sandbox? or do i need to set up a juju deployment of some sort with gojuju?
<gary_poster> frankban, huh...all completed deployments since the beginning of time?
<gary_poster> jcsackett, if we have implemented this in the sandbox, then yes.  actually...
<gary_poster> one sec
<gary_poster> looking
<frankban> gary_poster: we can set a timeout to clean up old deployments, this is something we need to do also in the case we watch a single deployment
<gary_poster> jcsackett, no sandbox is not good enough.  the sandbox is the thing we need to change, if we are wrong.
<jcsackett> gary_poster: ah, so i need to get a working gojuju and deploy out with that, then inspect a deployment.
<gary_poster> jcsackett, right now the sandbox sends is_subordinate but I think it is wrong, for py, go, or both
<gary_poster> jcsackett, exactly
<benji> gary_poster: did I miss the fact that Aaron was going to be out today?
<jcsackett> gary_poster: ok.
 * jcsackett goes to look up juju docs for getting a working go juju.
<gary_poster> benji, I dunno.  I don't remember Aaron being out today.  jcsackett or adeuring do you happen to know?
<jcsackett> gary_poster, benji: i don't remember him saying he was out today...next week or this friday, maybe.
 * jcsackett checks canonicaladmin
<adeuring> I can't remeber this either...
<gary_poster> frankban, true...I didn't think that we would need it for the single deployment case but I see what you meamn
<gary_poster> frankban, so yeah, I caould buy that :-)
<jcsackett> benji: he's listed out next week, not today (or any of this week).
<benji> I didn't know canonicaladmin would tell me that.  Thanks.
<gary_poster> thanks jcsackett (I was thinking I didn't have canonicaladmin visibility because I didn't manage...silly me).  Yeah benji, the calendar link lets you see the next two weeks
<jcsackett> benji: mind you, it's not always accurate.
<gary_poster> heh
<gary_poster> yeah
<jcsackett> it once reported me as being out on "national holiday leave" for three months.
<gary_poster> my holiday is not in, and none of my previous holidays are in because they have not been formally approved :-/
<gary_poster> benji ^^^
<benji> k
<benji> abentley: good morning; let me know when you get settled, I'd like a quick call about my branch
<abentley> benji: I'm free to chat.
<benji> abentley: cool, I have to go outside to get my camera :) one second and I'll be there
<hatch> morning
<gary_poster> morning
<hatch> I set up zsh, tmux, vim yesterday
<hatch> well 'started'
<hatch> it's pretty cool, I can now type tgui and it opens up a new tmux window with it ready to dev on the gui
<gary_poster> hatch, on a vm you mean
<hatch> nope in ubuntu
<hatch> opening up the terminal opens it up automatically in a new zsh tmux session
<hatch> then I navigate to the dir I want to work in and `tgui`
<hatch> wait a few seconds and then it's all set up
<hatch> I still can't use vim very fast though :)
<gary_poster> hatch, I guess I don't see what is all set up :-) other than vi in a tmux
<hatch> oh well it splits the window, makes, the builds, sets the root dir for ctrlp
<gary_poster> oh, ok, cool
<hatch> and because I found I switch branches a lot
<hatch> all I need to do is navigate to a new branch and type `tgui` and it opens up a new window ready to go
<hatch> so I can switch between them using ctrl+b+[0-9]
<hatch> I fully expect something to break because it went a little too smooth setting this all up
<antdillon> bcsaller, Makyo Hi, do either of you guys have sometime to help me with new relation behaviour?
<hatch> antdillon: I believe your 2 to 1h early respecitvely
<hatch> anything I can help you with?
<Makyo> I'm in, but don't know anything more about it at the moment.  At least, not off the top of my head.
<antdillon> Makyo, hatch, Thanks, its about adding drag and touch to create a relation between the service blocks
<Makyo> antdillon, is there a document somewhere for this?
<antdillon> Makyo, hatch I have the hit detection working 
<antdillon> Makyo, Unfortunately not, Luca asked me to create a fork of the gui and get a prototype of some thoughts working
<antdillon> Makyo, All he told me was he wanted to drag a server block to touch another then to wait a second or two to create a relation
<Makyo> antdillon, just wrt touch interaction?  Touch has been on the plate since I started at Canonical almost a  year ago, and I even have one of our N10s for that work :)
<hatch> so what's the question? :)
<antdillon> hatch, Makyo Is there a simple way to create a relation between two service blocks without a line?
<rick_h> hatch: the issue when I tried to help him was that he can detect a hit, but he wants to create the relation line aftter that point and the code is setup that it's based off the click/drag start/end and not a good way I could see to suggest "call XXX to get the relation line going"
<antdillon> Makyo, Oh you have plans for this work already?
<luca> Makyo: hatch not using Ubuntu touch, nothing to do with mobile
<Makyo> antdillon, no, different touch.
<Makyo> luca, antdillon, does this take into account ambiguous relation types, or selection of available relate-able services?
<Makyo> Because, at the very least, all you should need to do are fire the proper events against the topo.
<Makyo> That will create lines, pop up menus, etc.
<hatch> yeah I was just reviewing the code here
<antdillon> Makyo, I started to us the ambiguousAddRelationCheck function but seems tided in with the dragged line
<hatch> so you want to drag one service onto another service to create a relation
<hatch> the services then....bounce appart?
<antdillon> Makyo, I can't seem to find a function that takes 2 service ids connects them if they pass the tests
<antdillon> hatch, At the moment all I want is to create a relation if they overlap
<Makyo> antdillon, alright.  hatch, you seem really eager, and I think we're going to step on each other's toes if we keep this up.  You want to take this?
<hatch> antdillon: see 'addRelationEnd' in topology/relation.js
 * Makyo bows out.
<hatch> Makyo: sure.....unelss you wanted
<hatch> :)
<hatch> sorry
<Makyo> hatch, go ahead, I'm not going to just add to this mayhem.
<hatch> haha
<antdillon> hatch, Yes got 'addRelationEnd'
<hatch> antdillon: ok then you see the db.relations.create() call
<antdillon> Makyo, Thanks for helping so early in your day
<antdillon> hatch, Yes, that does the work
<Makyo> antdillon, I start at 8, so 20 minutes ago, not so early :)
<hatch> oh right Makyo we r on the same time
<hatch> this day....
<Makyo> hatch, YEah, except for one week or whatever.  Yesterday was recovery from travel, so I was in an hour late, working an hour late.
<hatch> oh where did ya go?
<antdillon> hatch, So you think creating a new function in relation.js to take two ids and just run the db code?
<hatch> well no heh
<Makyo> Just down to Denver.
<hatch> Makyo: ahh
<hatch> antdillon: you also need to add relation wrt the env
<hatch> so that it will update everything via the deltas
<hatch> when it returns
<hatch> that's the key part there
<hatch> buuuut
<hatch> you might be able to hack it
<hatch> by copying the code on line 881
<hatch> db.relations.create() and then firing db.fire('update')
<hatch> I believe that'll then fire the proper UI methods to draw the relation
<Makyo> hatch, antdillon - you will also have to guess at the relation type, FYI.
<Makyo> While we're being hacky.
<hatch> Makyo: yeah I was gona say to create a relation with two services, copy those values
<hatch> ^ antdillon
<hatch> then use those as static values in your 'drop' method
<hatch> since it's just a prototype and all
<antdillon> hatch, Ok I'll copy the code on and re-factor a new function
<hatch> antdillon: the only catch to this approach is that you will need to always pick the same two services in your demo else it'll break :D
<hatch> but it's easier to write hah
<antdillon> hatch, Yeah, I'll get it working for 2 services that I know can connect then get some checks in before. Think luca wants the service to grey out if they are not compatible as you drag one around
<hatch> I'm a little concerned
<hatch> what happens when you drag one over another one but you're just reorganizing them
<hatch> or you accidentally drop it on another one
<hatch> just throwing those out there :)
<hatch> I actually like the idea I'm just not sure how it will work in reality
<antdillon> You have to be holding the service block to connect and when you touch them luca wants a timer to appear and if you keep them connected it makes the relation
<antdillon> I suppose the example I think of is menu items on xbox kinect
<hatch> ok well the kinext interaction is irritating :P
<hatch> lol
<hatch> I always want to 'push' in the air to select the menu
<antdillon> Lol me too! but been asked to try it :)
<hatch> kinext enabled gui?
<hatch> :P
<antdillon> Think, minority report :)
<antdillon> hatch, Think I could fake it by calling addRelationEnd with the endpoints?
<hatch> how we are talkin!
<antdillon> hatch, Just need to work out what module is meant to be
<hatch> I think it's the environment
<hatch> sec I'll start up an instance
<hatch> aww crap it's not made yet....making
<antdillon> I've got the endpoints array to send through
<hatch> ok almost there
<hatch> antdillon: it's actually a RelationModule
<antdillon> hatch, Which would be created on start drag?
<hatch> just looking that up for ya
<hatch> your actually going to be IN the relation module
<antdillon> Thing is the hit code is in service.js which needs to call relation.js
<hatch> antdillon: looks like the second param to scene {} events in relation is the relation module
<hatch> in relation.js
<hatch> so can you move your call there?
<antdillon> I can call there form service.js?
<hatch> if you do that then you'll probably need to pull the relation module instance from the topology modules object
<hatch> the topo stuff is organized a little odd because it's done by composition
<hatch> topo is like brown playdo because it's full of all the other colours
<antdillon> hatch, Yeah seems like the super controller of all the modules
<antdillon> Odd, topo.models is undefined ?
<hatch> antdillon: guichat? it'll probably be easyer :)
<antdillon> hatch, Sure, hangout?
<hatch> antdillon: hangouts crashed :/
<antdillon> hatch, Ah, branch is here: c
<antdillon> lp:~ya-bo-ng/juju-gui/test-prototype
<hatch> ok on it, give me a second to look at it
<hatch> and by second I mean a few minutes for it to make
<hatch> heh
<antdillon> hatch, Thanks, I'll get tea
<gary_poster> jujugui call in 10, kanban now
<hatch> yeah....what he said!
<gary_poster> hatch, :-) do you mind if I run today since I'll be gone a week and a half afterwards? :-)
<hatch> not-at-all
<gary_poster> thanks
<hatch> it's a tough crowd
<hatch> good luck
<hatch> :)
<gary_poster> lol thanks
<gary_poster> he luca, I'll ping you for a quick call in about 35 minutes or so?
<gary_poster> Also, is ale coming back or is she gone for day?
<gary_poster> hey rick_h, huw's css most recent change to summary page was wrong :-( now change log and description ignores whitespace
<gary_poster> that was something he added; it was working when I gave it to him last night
<gary_poster> rick_h, not your problem.  sorry.  I'll email him
<rick_h> gary_poster: ah, noticed that change and meant to qa it but had your ok. sorry about that
<gary_poster> arosales, could you take a look at charm details and see if you are OK with new "Related Charms" "Code" and "Features" tabs?  Features tab has biggest diff to content
<gary_poster> jujugui orangesquad call in 1
<gary_poster> np rick_h 
<luca> gary_poster: Ale is out for the day
<gary_poster> luca, darn.  ok will send email
<luca> gary_poster: no problem for pinging me in a bit for a call
<gary_poster> thx
<arosales> gary_poster, will do. In a meeting atm
<arosales> do you mind if i get you that feedback by eod?
<gary_poster> arosales, not at all.  I'm out for a week and half starting tomorrow, so please give it the juju-gui list
<benji> the October sprint page says to book flights by July 8.
 * benji fires up the time machine.
<jcsackett> Makyo: calling now.
<jcsackett> Makyo: it claims you are not available.
<Makyo> jcsackett, probably pidgin getting in the way.
<rick_h> jujugui who wants to chat sticky headers? meet up in guichat
<hatch> there
<arosales> gary_poster, will do, thanks for the ping.
<gary_poster> rick_h, hatch you done?  if not, you want me around?
<hatch> we are done
<gary_poster> what's the resolution?
<hatch> the timebox will need to be like 4 days
<hatch> :)
<gary_poster> ok
<hatch> so in our oppinion it's probably low priority compared to others
<gary_poster> would it help to pair or is this a single engineer task?  I get the impression that pairing might be good on this.
<gary_poster> wellll...it's low priority compared to getting the inspector done on time
<hatch> yeah I think pairing would help
<hatch> there are so many issues surrounding the dynamic content
<hatch> I can run them past you if you want
<hatch> i'm in guichat
<gary_poster> do you have possible solutions?
<gary_poster> ok I'll join
<rick_h> gary_poster: yea, want a summary? I'd like your feedback on if we can push back slightly for a less fluent version
<gary_poster> rick_h, yeah, guichat?
<rick_h> gary_poster: rgr
<rick_h> hatch: so I'm going to grab that checkbox bug to get my feet wet. Let me know if there's something else you think I should hunt at
<hatch> sure thing - just remember that's a little more involved because of the databinding
<rick_h> hatch: yea, hoping it'll get my feet wet on that stuff
<rick_h> and at least has some limited scope to keep inside of
<hatch> a potentially easier one would be 'import config file does not work'
<rick_h> hatch: ok, will take your advice
<bac> benji, abentley: i'm seeing odd behavior with the enqueue script.  can either of you explain http://paste.ubuntu.com/5982047/  noting that ~bac != ~abentley
<abentley> bac: The prefix controls charms, but not bundles.
<abentley> bac: So you will get my bundle no matter what you do.
<bac> abentley: so any running of enqueue will get all of the bundles all of the time?
<abentley> bac: Yes.  I consider it a minor bug, but if we get significant numbers of bundles, we'll probably want to fix it.
<bac> abentley: well it is a bit surprising.  but now that i know what's happening i can adjust.
<benji> abentley: I'm having some late-breaking test failures on my branch, but we should probably put together our plan for the rest of thsi week and next so Gary can see/comment upon it today.
<abentley> benji: let's do a call in 15.
<benji> sounds good
<bac> gary_poster: my appt got canceled so i'm not going to be out.
<gary_poster> bac, ok, thanks for heads up
<hatch> we really need to shrink the footer and header of the gui
<hatch> with browser chrome on my laptop I have maybe 500px of vertical height hah
<hatch> a higher resolution laptop would also solve that problem :)
<hatch> does anyone remember who styled the zoom controls?
<hatch> ^ rick_h it was you right?
<rick_h> hatch: I reviewed/landed ant's changes
<hatch> ahh ok, well he isn't on the kanban so looks like you're getting the credit :P
<rick_h> wheee
<gary_poster> heh
<gary_poster> rick_h, +1 on the bugfix you are working on.  Afterwards, the only big thing to do for being feature complete is to add the constraint section to the ghost inspector--or are you doing that hatch?  Otherwise I'd suggest hatch giving a pre-imp on that
<hatch> either or - I can preimp regardless
<gary_poster> hatch, is it roughly separate from the rest of what you are doing?  the scale up/down is post-deployment, so separate, yeah?
<hatch> yeah it's totally separate
<gary_poster> cool
<hatch> there might be some template sharing
<hatch> will*
<gary_poster> right, that's where the pre-imp would come in handy
<hatch>  should?
<hatch> heh
<rick_h> gary_poster: k, thanks for the heads up
<gary_poster> :-)
<hatch> now that the viewlets are split out they sure looks awesome
<hatch> they have regained some of their previous glory
<bac> abentley, benji: care to do a review: https://code.launchpad.net/~bac/charmworld/bundle-results/+merge/179987
<abentley> bac: Will do.
<bac> thanks abentley
<hatch> bcsaller: kickin around?
<bcsaller> hatch: yeah, was going to eat soon though
<bcsaller> whats up?
<hatch> ok real quick
<hatch> unit_count is not firing change events through the databinding when it's value is changed
<hatch> was wondering the best way to track this down
<hatch> the bindings are being 'added'
<bcsaller> it was though, that is your memory as well?
<hatch> so it sets the proper initial value
<hatch> at first I thought so
<hatch> but I'm not so sure it was ever working
<bcsaller> hatch: that initial value isn't just the template?
<hatch> nope
<bcsaller> I'd thought it was showing the number of units when we tested scaling with the current UX
<hatch> well why don't you go eat I'll work on another part and when you're back we can run through this
<bcsaller> I'd put a log in _updateDOM and start there 
<bcsaller> ok
<bcsaller> I'll ping later
<hatch> enjoy!
<hatch> bcsaller: I got it....of course right after I ask lol
<hatch> enjoy your lunch
<bac> abentley: i see the ingester complains about the bonnie charm.  do we give feedback to ~charmers when problems are seen?
<abentley> bac: No.
<bcsaller> hatch: what was it?
<hatch> bcsaller: if you open the inspector too fast it doesn't work
<bcsaller> hatch: our init routine is broken?
<hatch> yeah I haven't had a chance to really narrow it down but if you deploy a service and right away dclick it to open the inspector it doesn't update
<bcsaller> hmm, that will need a card if you don't track it down now, that will hit people
<hatch> yeah I'm trying to find a real way to repro 'do all this really fast' isn't really an acceptable repro step :)
<gary_poster> hatch, fwiw there is a card with this description: "ghost inspector: when you click "confirm" and successfully convert to a real service, close the ghost inspector and automatically open the service inspector (or similar)"
<gary_poster> hatch, that's a great way to trigger the problem you describe, it sounds like :-)
 * gary_poster stepping away for a bit but will be back to finish a couple of emails
<bac> abentley: thanks for the _id explanation
<abentley> bac: np.
<abentley> bac: I was actually wrong, in that the code you changed was already broken, because it was indexing before _id was set.
<bac> abentley: your solution sounds good
<abentley> bac: Cool.
<hatch> so they say that the Chevy Volt has 10M lines of code controlling it
<hatch> using the mythical 10 lines per day
<hatch> that would have taken 1M days
 * hatch is skeptical of their claim :P
<hatch> make that 1M developer days
<bac> hatch: have you seen how productive rick_h is?  those detroit dudes are agile and adroit.
<abentley> hatch: Did they say they wrote all the code from scratch?
<hatch> bac: sure but sometimes they need a few $B from the government because they forget what they were doing for 10years :P
<abentley> bac: The version I've heard is that average developers produce about 10 LOC, great developers 100 LOC and poor developers 1 LOC.
<hatch> abentley: I hope not haha
<hatch> 100 LOC/day? maybe for a code monkey
<abentley> hatch: 100 LOC isn't absurd.  I don't hit that every day, but I often do.
<hatch> well I suppose
<hatch> we have ~45k loc in js in the gui
<hatch> which is much less than 100loc/day but I'm not sure how many ft ppl could say we were on it
<hatch> 4?
<hatch> but that includes comments and closing curly brackets hah
<bac> abentley: your change works.  thanks.
 * bac dogwalks
<hatch> abentley: yeah I suppose I could see 100loc if you include curly's and comments
<hatch> bcsaller: do you have any objection to me sending the prevVal through to the viewlet update method?
<bcsaller> hatch: you have to properly pull it from POJO observe changes as well (it is there but called different) if its part of the interface
<bcsaller> I had that in the original conflict branch as well so I think its a fair idea
<hatch> oh right I forgot about the POJO stuff
<hatch> bcsaller: ot: do you also use ctrlp for your file searching needs?
<bcsaller> hatch: I use http://vim.spf13.com/ which includes CtrlP
<hatch> ahh cool I'll have to look into that
<hatch> I see all these fancy themes and then I look at mine
<hatch> heh
<hatch> using zsh and tmux I have no idea where half of the settings are coming from lol
<bcsaller> spf13 was me not wanting to learn about the world of vim plugins, I mostly haven't had to
<hatch> what does your terminal 'stack' look like?
<huwshimi> Morning
<rick_h> huwshimi: morning
<rick_h> huwshimi: landed your branch with a tweak for the hash urls. gary_poster mentioned that the css changes broke the white-space respecting bits of the changelog and such. not sure if he emailed you about that or not
<huwshimi> rick_h: Ah thanks. He did not :(
<gary_poster> huwshimi, hey, sorry, yeah.  The way the whitespace was for the description and changelog was intentional
<gary_poster> and (at least somewhat) important
<gary_poster> pre-something or other?
<huwshimi> gary_poster: Being proken onto three lines?
<huwshimi> broken
<gary_poster> it looked right in my branch
<gary_poster> huwshimi, maybe there was a case it which it was bad, and I'd be happy to look at it
<gary_poster> huwshimi, but the goal is:
<rick_h> huwshimi: if there's a newline in the changelog content, or the desciption, we respect it in the html output
<gary_poster> we honor whitespace, we still let it wrap, and we wrap long words (usually urls) if necessary
<rick_h> basically it was people doing - lists in changelogs and such and not having them go into a single line of output when displayed
<gary_poster> right, and descriptions too
<bcsaller> hatch: I didn't understand the question. I run a vim terminal with 3 or 4 windows and then on another tab I'll run a split console with make devel, make test-server and a shell each in one split using terminator.
<rick_h> huwshimi: see https://jujucharms.com/precise/memcached-7/ vs http://comingsoon.jujucharms.com/precise/memcached-7/ changelog output
<rick_h> (you have to open up the changelog to see the one in particular)
<huwshimi> gary_poster: Ah I see
<gary_poster> thanks huwshimi, rick_h 
<gary_poster> biab
<huwshimi> gary_poster: Probably worth getting Luca to take a look at what we should do, it looked a bit funny having the description broken onto a new line.
<huwshimi> Also, there where semantic html issue with that specific implementation, but that's not an issue
<huwshimi> (as in, easily fixed)
<hatch1> rick_h: I ended up getting weechat to work by adding the stable ppa and installing the most recent version
<hatch1> just in case you were also looking at doing it, you'll want to run the same ppa
<gary_poster> huwshimi, ack.  I am out for next week and a half.  Please fix up to where it was roughly before, and then shoot out an email to Luca with the other issue you see.
<huwshimi> gary_poster: OK will do
#juju-gui 2013-08-14
<gary_poster> bcsaller, you around?
<bcsaller>  gary_poster I am 
<gary_poster> hey bcsaller.  How is your import support intended to be used within the context of our current goals?
<bcsaller> gary_poster: For the store, you create a new db and a topo configured for a bundle, import the YAML into the db and render the topo into some container in the store
<bcsaller> gary_poster: its not about trying to replicate what the server side deployer does, though that option could exist down the road 
<gary_poster> bcsaller, ah!  I see.  looking around
<gary_poster> bcsaller, this branch does not actually hook up the YAML parsing, right?  If it does, I'm missing it
<bcsaller> gary_poster: no, there is no UI on it yet and the YAML isn't required to trigger the function, but the tests show what the parsed YAML looks like, its just imported deployer styled data
<gary_poster> bcsaller, cool.  thanks, was trying to see where it fit in.
<gary_poster> won't get a chance to review it myself: finishing up closing email with goals etc,
<bcsaller> I could connect the import code to it though (which makes sense) but we can't really transform many ghosts into real deploys yet
<bcsaller> for example I don't think we have any special support around pending relations yet (though this can tag those)
<bcsaller> gary_poster: this is a needed step to rendering bundles in the store
<gary_poster> and we'll want the import spelling to match what frankban is building in the charm server
<gary_poster> right bcsaller, got it now.  It will also help with letting the fakebackend dupe the deployer
<gary_poster> but we are not there yet
<bcsaller> should be easy to change, but its in sync what what is exported now
<bcsaller> right
<gary_poster> cool, thank you!  by "import spelling" I just mean the APIs that we will use to pass the YAML to the server
<bcsaller> ahh, ok
<bcsaller> thanks for taking a peek :)
<gary_poster> np :-)
<gary_poster> hey huwshimi, I assigned you to #1207045, #1207041, and #1207039.  Do you want to be unassigned from any of them?  We need to have them resolved by end of next week.
<_mup_> Bug #1207045: Lots of whitespace below the charms on the landing page of the charm browser in fullscreen <charmbrowser> <ie10> <juju-gui:Triaged by huwshimi> <https://launchpad.net/bugs/1207045>
<_mup_> Bug #1207041: Opening up charm browser details view shifts environment left in IE10 <charmbrowser> <ie10> <juju-gui:Triaged by huwshimi> <https://launchpad.net/bugs/1207041>
<_mup_> Bug #1207039: Inspector settings viewlet has nested scroll bars in IE10 <ie10> <juju-gui:In Progress by huwshimi> <https://launchpad.net/bugs/1207039>
<huwshimi> gary_poster: I started work on them but put it aside to work on other things. I can pick that up again. I wasn't able to figure out Bug #1207041
<_mup_> Bug #1207041: Opening up charm browser details view shifts environment left in IE10 <charmbrowser> <ie10> <juju-gui:Triaged by huwshimi> <https://launchpad.net/bugs/1207041>
<gary_poster> huwshimi, I don't want to shift you around randomly, but we do need it done when I said, and the sooner the better.  What is a reasonable schedule, given your other goals?
<gary_poster> huwshimi, I will take your name off that one now
<huwshimi> gary_poster: I can pick it up again this afternoon
<gary_poster> cool thanks huwshimi 
<huwshimi> np
<gary_poster> hatch you around?
<bac> benji: is aaron out today?
<benji> bac: nope, I expect he'll be in momentarily
<rick_h> yea, next week he's out
<bac> rt
<bac> hi abentley, to avoid having staging get the multiple ingesting of baskets bug (due to id vs _id) i'd like to merge the branch you reviewed last night but with the bundle display disabled in search.pt to avoid having a 404 link.  seems safer than waiting for my next branch to land, which will be no earlier than tomorrow.
<abentley> bac: That sounds fine to me.  It's not just staging, though.  Production also has this bug.
<bac> abentley: sorry, i got disconnected.  did you reply to my question?
<abentley> bac: Yes.  "That sounds fine to me.  It's not just staging, though.  Production also has this bug."
<bac> abentley: ok.  i'll merge it now.
<hatch> morning
<rick_h> morning
<antdillon> hatch, Morning
<frankban> bac, benji, or anyone else who wants to look at some python code: could you please review https://codereview.appspot.com/12903044 ?
<bac> frankban: sure
<benji> darn, I was too slow
<frankban> benji: i need two reviews ;-)
<benji> yay!
<frankban> heh, thank you both
<hatch> sooo hows everyones day so far?
<rick_h> I get to go fishing after work today so the later the day goes the better it gets :P
<hatch> oh awesome - I almost made it out kiting yesterday but the wind started to die after work so I wasn't going to make the drive
<hatch> I need to start work about 2h ealier in the off chance that there will be wind
<hatch> haha
<hatch> rick_h: what kind of fish are by you?
<rick_h> the lake I go to is pike, bass, crappie. There's a lot more around the area though
<hatch> ahh cool
<rick_h> honestly, I just like going out by the lake as it's really low traffic and chilling for a while
<hatch> yeah for sure - I hear there are private lakes in the US in the south
<abentley> sinzui: 1x1?
<sinzui> abentley, yep
 * hatch really misses his second monitor
<rick_h> jcsackett: bac has access to the analytics I think. I was hoping he'd reply to the email but he's afk it looks like
<rick_h> noooooooooo, lbox hanging....oh the hate
<hatch> jujugui guichat in 10, kanban now
<Makyo> Pff.
<rick_h> jujugui reviews please https://codereview.appspot.com/12797046 will swap reviews for reviews
<Makyo> rick_h, you're on.
<hatch> rick_h: got one
<Makyo> https://codereview.appspot.com/12900043/
<hatch> Makyo: mohohahaha I beat you
<Makyo> hatch, My clock STILL says 9:49!
<Makyo> Just flipped over.
<rick_h> oh noes! my first go review
<rick_h> Makyo: just either lucked out or is doomed
<Makyo> Thankfully still in JS :o)
<rick_h> ah, tricky filenames with go...just not at the end
<rick_h> there's bac! get him
<hatch> AHHHHH
<hatch> that was me charging
<bac> er?
<bac> bad internet day
<hatch> rick_h: review done
<rick_h> hatch: thanks
<hatch> next time qa before you propose :P
 * hatch internet slaps rick_h
<rick_h> whoa, hatch advocating more tests?
<hatch> I know right? lol
<rick_h> hatch: :P yea, that z is embarrassing
<hatch> lol
<bac> rick_h: did you need something?
<rick_h> hatch: oh well, at least my code has tests
<hatch> haha
<rick_h> bac: was going to hit you up on the call, mramm is asking about analytics on jujucharms.com and I thought you had access
<rick_h> bac: wanted to see if you could reply to the email if you do?
<rick_h> bac: was to the -peeps mailing list
<Makyo> jujugui call in2
<hatch> rick_h: do you have a yaml file for qa? then I can qa once you update
<rick_h> hatch: no, I was looking around and didn't find one. 
<bac> rick_h: oh, ok
<Makyo> frankban, starting without you
<bcsaller> bac: just ping me when you want to talk then
<hatch> rick_h: are you planning on expanding those tests? (I just saw that you updated the propose)
<bac> bcsaller: ok.  we don't need to talk if you're just going to say "be aware but you don't really need to do anything now."
<rick_h> hatch: I'll look at it. 
<rick_h> hatch: I don'pt want to get too 'test all the things' in one test
<hatch> the extra asserts should be pretty trivial to add
<bcsaller> bac: thats about the size of it, there will be a method you call with a container node and some bundle data and this will draw it
<bcsaller> at some point in the future 
<rick_h> hatch: but if they're not touching too many parts at once I'll add them
<bac> bcsaller: ok, then lets defer
<bcsaller> fair enough
<hatch> rick_h: yeah - my idea was that we just want to make sure the plumbing is hooked up :)
<hatch> rick_h: I lgtm;d so you can submit whenever
<hatch> afternoon luca
<rick_h> grabbing food, will have review day afterwards. 
<luca> hatch: Hi Jeff
<luca> hatch: How's it going?
<hatch> it's going good, and you?
<hatch> bcsaller: in my hacking on this databinding stuff I've found some very odd bugs....like where we will have 80+ bindings in `this._bindings`
<hatch> but I can't find out how to repro them :/
<hatch> so I just wanted to make you aware
<luca> hatch: I'm good :)
<bcsaller> hatch: remember that we bind each node with a valueChange, not just the container, so its possible for something with many config values to see a lot, but 80 does sound high
<hatch> yeah the one that was 88 had 32 bindings the next time
<hatch> so that system needs a refactor....or something
<hatch> but we already knew that
<hatch> I'm just surprised it has no negative effects haha
<bcsaller> hatch: I was thinking about it but haven't verified this yet. I think the fillSlot stuff might bind again because the DOM for the slot can be re-rendered. It might be rebinding the whole set at that point w/o clearing the list first. If thats the case it would take some thought to fix because clearing the list would break the contract (bindings can store state as this.whatever). 
<bcsaller> But I think that might be the issue and we could manually clear the old bindings for the inspector in the slot being filled
<hatch> yeah there is a UI repercussion of this in which the unit_count does not get updated when opening the inspector
<hatch> so we will have to fix this before we release off flag
<rick_h> jcsackett: qusetion in bound with my LGTM though
<hatch> bcsaller: sorry just trying to do something else atm so I haven't put any thought into it
<bcsaller> I was just trying to think how it could happen
<hatch> yeah it happens probably 50% of the time
<hatch> so the inconsistency is my biggest worry
<hatch> I was so totally just burnt by loose typing js
<hatch> ouch it hurts
<rick_h> don't do that
<bac> this is my favorite docstring ever:
<bac> """Ensure the future is done and it contains the expected results."""
<hatch> bcsaller: should this not trigger the update function?  app.env.add_unit('mediawiki', 10) - it adds the units into the db and the status bar ...
<benji> that's pretty good
<bcsaller> hatch: which update method, the bindings.unit_count.update one? it should happen after the delta comes back
<hatch> yeah
<hatch> it's definitely not
<hatch> :/
<hatch> at least I'm not goin nuts
<bcsaller> in the console try a change listener on the value and do it manually
<hatch> sory I don't follow
<hatch> guichat?
<bcsaller> taken
<hatch> ring ring
<rick_h> bcsaller: review inbound, let me know if I'm missing stuff and we can chat. 
<bcsaller> rick_h: thanks, on a call now
<benji> bac, abentley, sinzui: ready to finish our discussion?
<abentley> benji: Sure.
 * sinzui finds drink
 * bac does same
<bac> benji, abentley, sinzui: the doc is at https://docs.google.com/a/canonical.com/document/d/17bgbReU6JJMoUHSJeo8egG5zoSM0fpPIs7U8F1-Piyk  -- in case i cannot reopen it inside the hangout
<sinzui> benji, you might recall my nagios branch. I have a separate merge into the unstable charm where I resolved conflicts. Do you have time to review it? https://codereview.appspot.com/12942043
<benji> sinzui: my pleasure
<benji> sinzui: oh, I forgot to mention that since the shell script uses [[ you don't have to quote the variable to avoid expansion
<sinzui> oh yes. Thanks benji.
<abentley> sinzui: Could you please review https://code.launchpad.net/~abentley/charmworld/versioned-ids-for-charms/+merge/180225 ?
<abentley> sinzui: Sorry about the size.  It's gotten hard to break out bits.
 * sinzui looks
<hatch> nice post Makyo
<Makyo> Just figured i'd brag :)
<hatch> isn't that what blogs are for?
<Makyo> Yep!
<hatch> jujugui has anyone started on any of the IE cards yet?
<Makyo> hatch, doing investigation of the viewBox attribute now.
<hatch> kewl
<sinzui> abentley, sorry the the delay. I replied with a question.
<abentley> sinzui: No worries.  This branch took weeks to finish, so an hour reviewing it is nothing :-)
<hatch> a
<hatch> bcsaller: if user is looking at the inspector and someone else ups the units...should it up the input as well?
<hatch> I'm thinking yes
<hatch> that inputs story is a little confusing
<hatch> bcsaller: another bug - when I deploy a service then open the inspector fast - the line that we changed in model.js var sum = service.get('units').size(); throws an error that service.get('units') is undefined
<hatch> I lied, it also happens when deploying a ghost from dragging
<hatch> I can repro it 100% of the time now so I"ll make a ticket
<hatch> uh oh someone broke ci!!!!!
<bcsaller> hatch: yes to the first one.  for the second that list is added on the first delta of a unit of that service I think. We can see the other case when the binding is setup so it would be units = service.get('units'); sum = units && units.size() || 0;
<hatch> https://bugs.launchpad.net/juju-gui/+bug/1212443
<_mup_> Bug #1212443: Drag to deploy to soon after pageload and throws console error <juju-gui:New> <https://launchpad.net/bugs/1212443>
<hatch> ahh that makes sense
<bcsaller> The CI looks like it might be a saucelabs issue, might just queue another and see what happens
<hatch> bcsaller: looks like you were right :)
<hatch> jujugui has anyone started on adding constraints to the ghost?
<hatch> jcsackett: kickin around?
<huwshimi> Morning
<hatch> morning huwshimi
<hatch> what are you workin on today?
<huwshimi> hatch: Finishing off some IE10 stuff
<hatch> great - so you were saying that the browser shifting things left you wanted to pass off?
 * hazmat starts playing  the story of the ghost in the background
<huwshimi> hatch: Well, at this point I haven't figured it out. I left a note on the bug from what I discovered but I haven't managed to figure out the real cause. If someone else wants to take  a look that'd be great :)
<hatch> hazmat: diggin a little Phish at EOD? :)
<hazmat> hatch, indeed
<hazmat> hatch, no constraints though ;-)
<hatch> huwshimi: ok cool - I've been stuck in service constraint and databinding land - it seems like everything I've had to touch is broken lol
<hatch> so I want to make sure we can get this stuff delievered on time
<hatch> hazmat: :)
#juju-gui 2013-08-15
<rick_h> hatch: no, it was what I was going to start but IE bugs come first
<hatch> fishing done?
<rick_h> hatch: yes...why yes it does
<hatch> catch anything?
<rick_h> hatch: no, it was not a good trip 
<hatch> oh...?
<rick_h> lost my pole/reel into the lake... /me isn't proud
<hatch> haha darn I hate it when that happens
<rick_h> new rod/reel, just over a week old. Not feeling the love of today
<hatch> rick_h: last year 2 of my buddies went out fishing in a canoe with all brand new gear - an hour later they returned soaked....they tipped the canoe and lost everything
<rick_h> doh
<hatch> counting cell phones and glasses it was probably a $3000 tip
<hatch> haha
<rick_h> ouch
<hatch> yup that was an expensive weekend!
<Makyo> Good news, everyone.
<rick_h> Makyo: I like good news
<Makyo> The viewBox attr on SVGs fixes both FF and IE10
<rick_h> Makyo: sweet!
<Makyo> rick_h, Going to correct the default icons first, then we can figure out a story for charm/icon.svg
<bcsaller> Makyo: I think the api server can patch them on ingest 
<rick_h> bcsaller: yea, it completely can. Just needs to be added
<rick_h> bcsaller: and should get it added to the demo/template provided in the docs perhaps
<Makyo> bcsaller, yeah, that's what I was thinking.  Gary was concerned about that as a solution over requesting charm authors to do it themselves.
<bcsaller> charm authors no more known what they SVG editors save as does than... well... I bet they don't know
<Makyo> Hah, fair.
<rick_h> right
<Makyo> Where's the template, rick_h ? The attribute would change based on the final width/height values, curious how those are specified.
<rick_h> we'll never have it 'fixed' if we rely 100% on charm authors
<rick_h> Makyo: sec, in the juju docs. Looking. 
<rick_h> Makyo: https://juju.ubuntu.com/docs/authors-charm-icon.html
<Makyo> I like that the title is "None" :P
<rick_h> heh
<rick_h> but the template is at https://juju.ubuntu.com/docs/media/icon.svg I bet jcastro or marcoceppi can update that if we need. 
<Makyo> rick_h, Alright.  From the looks of it, authors may be editing the width/height in Inkscape, as well.  I may prowl around through there and see if there's an option in Inkscape itself for viewBox.
<rick_h> hatch: I submitted without the extra tests but poked at the env and db. Would like to chat about how those 'work' tomorrow if you've got time
<rick_h> Makyo: cool
<rick_h> thanks for looking into it. 
<rick_h> hatch: e.g. getting a charm from the db doesn't have the config values in it that I could tell. And there wasn't an idea of fetching the charm from the env I could see either
<Makyo> rick_h, Okay, found it.  Hopefully it's this easy!
<hatch> rick_h: yeah remind me when I get in and I'll fill ya in
<hatch> unless you're around now
<hatch> Makyo: thanks :D
<rick_h> hatch: around now but past my bed time. I'll hit you up tomorrow
<marcoceppi> rick_h: what did I do?
<rick_h> heh, well it's closer I guess. Friend was trying to convince me FF was faster than chrome now. Except test suite 37s in chrome and 56s in FF
<rick_h> it used to be twice as much though, so getting better
<bac> abentley, benji, sinzui: in a fit of OCD i reorganized the task list on our google doc from yesterday.  i also made cards for my tasks in kanban.  might be nice to add the ones you've been assigned too.  i'll make cards for the unassigned ones.
<benji> thanks; oh, yeah, I need to add a card for mine too
<sinzui> thank you bac
<rick_h> lol, love fits of OCD
<bac> or CDO as jeff bailey calls it.  everything should be alphabetized.
<rick_h> yay! I have defeated IE! Where is my victory parade?
<bac> sinzui: if you understand #10 on the list could you re-write it to make sense?  it is currently gibberish to me.
<jcsackett> jujugui: can someone else with ie10 ready confirm that bug 1112783 appears to be fixed? i have tried to reproduce and it works for me. if it works for someone else i'll mark it resolved.
<_mup_> Bug #1112783: 'destroy service' never returns from confirmation dialog <ie10> <juju-gui:Triaged> <https://launchpad.net/bugs/1112783>
<rick_h> jcsackett: sec, will in just a min
<jcsackett> rick_h: thanks.
<abentley> bac: ack
<rick_h> jujugui IE QA/review please https://codereview.appspot.com/12871046
<benji> rick_h: looking
<sinzui> bac, I cannot edit it
<rick_h> jcsackett: cannot reproduce
<rick_h> jcsackett: it's from Feb so not surprised we've fixed something between now and then
<jcsackett> rick_h: huzzah!
<jcsackett> rick_h: move the card to releasable, or just delete it?
<bac> sinzui: your gmail id had edit permission.  now your canonical does too
<rick_h> jcsackett: I'd just delete. 
<rick_h> jcsackett: and mark the bug as invalid. If it's releaseable then we'd do fix-released I'd think
<jcsackett> rick_h: i would say it's fix-released; it wasn't invalid, we just fixed it at some point. but i'll delete the card.
<rick_h> jcsackett: k
<rick_h> jcsackett: then keep the card and get bi-weekly bug credit :)
<jcsackett> :-P
<jcsackett> Makyo: i see you assigned to the card for bug 1207035, but assigned in LP to 1207036; are you working on both?
<_mup_> Bug #1207035: Some charm icons are improperly sized in IE10 <charmbrowser> <ie10> <charmworld:Triaged> <juju-gui:Triaged by makyo> <https://launchpad.net/bugs/1207035>
<jcsackett> oops, mup didn't pick up the second one. bug 1207036.
<_mup_> Bug #1207036: Service SVG icon in inspector is stretched vertically <ie10> <juju-gui:Triaged by makyo> <https://launchpad.net/bugs/1207036>
<rick_h> jcsackett: he thinks he's got a fix for both with one change
<rick_h> jcsackett: so those should be good coming soon
<rick_h> though might need a charmworld branch as well. 
<abentley> bac: Could you please give me edit rights on Charmworld URLs and Pages notes?
<bac> abentley: your gmail identity has them.  i think it automatically granted to all identities in the original chat.
<bac> abentley: you want me to add your canonical?
<abentley> bac: Yes, please.
<bac> abentley: try now
<abentley> bac: Looks good.
<bac> abentley: cool.  just got smart and opened to all canonical
<rick_h> jcsackett: can you qa https://codereview.appspot.com/12871046 for me in your fresh IE setup please? 
<jcsackett> rick_h: sure.
<jcsackett> rick_h: have you seen this happen on IE10 before? happened after i hit the search bar in fullscreen. http://d.pr/i/PpyH
<rick_h> jcsackett: looking
<rick_h> jcsackett: oh...interesting...not seen that one
<jcsackett> rick_h: i'm checking if that happens in trunk. can't imagine it's related to your branch.
<rick_h> jcsackett: so it does it every time?
<rick_h> ah, I can dupe it. In fullscreen, missed tghat part
<jcsackett> rick_h: it does it in trunk, so it's not your branch.
<rick_h> jcsackett: yea, I bet it's the autocomplete widget which is on comingsoon, but not jujucharms. Will need to file that as a new one
<rick_h> ugh
<jcsackett> also, in IE10 if i just load jujugui and click the "browse" button i'm not going to fullscreen.
<hatch> morning
<jcsackett> rick_h: can you reproduce that?
 * jcsackett hopes its something weird locally.
<rick_h> jcsackett: no, it changes modes for me
<jcsackett> huzzah!
<jcsackett> morning, hatch.
<rick_h> jcsackett: ok, will file the AC bug and add a card for that
<jcsackett> rick_h: ok.
<jcsackett> i'll update your MP with my QA ok.
<hatch> brb
<jcsackett> rick_h: got any notions of why AC pushes down the rest of the screen? i'm free to pursue the bug, but would like pointers if you've got 'em.
<rick_h> jcsackett: thanks for the search link then
<rick_h> jcsackett: errr, the notion that it's used in search as well
<rick_h> jcsackett: so basically going to be something in the css of the autocomplete that's not being position absolute I guess. 
<rick_h> jcsackett: I'd just start going through the .aclist* classes and nodes and seeing if they can be tweaked
<jcsackett> rick_h: ok.
<jcsackett> rick_h: i'm actually less free than i thought--hatch emailed me a bug last night i need to look into as it appears to be browsercharm fallout.
<jcsackett> probably simple though, so i should be able to get to AC soon.
<rick_h> jcsackett: rgr
<jcsackett> hatch: i saw your email and the bug, but i can't reproduce.
<hazmat> sinzui, incidentally that rack charm store issue is caused by a bug in the charm itself
<sinzui> hazmat, great.
<sinzui> hazmat, details
<sinzui> or update the bug
<hazmat> sinzui, i replyd via email, its going to take a few for lp to publish
<sinzui> thanks
<hatch> jcsackett: hmm I just did http://comingsoon.jujucharms.com/:flags:/serviceInspector/ dd mediawiki, click 'destroy service' click 'confirm', see error in console
<jcsackett> hatch: i missed destroy was available before deploying.
<hatch> :)
<jcsackett> hatch: btw, it's "Jon" not "John". :-P
<hatch> yeah....well.....
<hatch> yeah I got nothin
<hatch> oops :)
<abentley> jcsackett: I always thought jc was short for Jesus Christ :-P
<jcsackett> only in my most meglomaniacal moments.
<rick_h> I have slain the mighty IE! All bow before my...oh wait...my bad
 * jcsackett laughs
<hatch> or that his last name was Penney
<jcsackett> yes, because none of these are jokes i have heard a thousand times. :-P
<hatch> or Chasez
<hatch> have you heard THAT one?
<jcsackett> i have not. well played.
<jcsackett> only half credit though, as it's just a variation on a theme. :-P
<hatch> lol true true
<jcsackett> hatch: fix up for that bug https://codereview.appspot.com/12795046
<jcsackett> can you review?
<hatch> on it
<jcsackett> jujugui: i suppose even though it's one line, i need one other reviewer.:-P  ^
<hatch> there are two now
<rick_h> jcsackett: already done, but figured you'd trivial it
<jcsackett> rick_h: i usually eschew trivial when the fix is for actual breakage.
<jcsackett> and thanks for the review.
<rick_h> np
<hatch> rick_h: when did you want to go over the db stuff
<rick_h> hatch: after the standup call ok?
<hatch> yep no problem
<sinzui> abentley, jc is short for our lord and savour John Cleese.
<jcsackett> ok, *that* one is new.
<hatch> jcsackett: oh crud it's a little late now but we should have added a test for that bug
 * hatch hasn't had his coffee yet
<abentley> sinzui: chat?
<hatch> jcsackett: I can add that test
<jcsackett> hatch: ok, i'm pursuing a css issue with AC in IE10. if you've not gotten around to the test before i'm done with that, i can pick it up then.
<hatch> I'll start on it now, I need a break from this constraints stuff
<sinzui> abentley, in 15? I am in meetings
<abentley> sinzui: sure.
<abentley> sinzui: How's it going?
<sinzui> abentley, all clear. we can talk
<abentley> sinzui: hangout at https://plus.google.com/hangouts/_/666d51fb65e7f2ce7442c104ad381044fefac89a?hl=en-GB
<marcoceppi> Hi juju-gui people. Question about the canvas in gui. (well, two)
<Makyo> Shoot, marcoceppi 
<marcoceppi> One, is it worth filing a bug to disable right-click context menu from the browser on the gui? We had 21 users who were operating under the assumption that in order to bring up the menus they needed to right click (they also though that the long click was right click only) and were getting frustrated by having the browser menu pop up when using right click
<marcoceppi> after showing them it was all Mouse 1 they got it, so I'm just doing due diligence as I said I'd bring it up with you guys
<Makyo> marcoceppi, jujugui, I say file it, and then we can triage it during calls.  From my point of view, it makes enough sense, at least on the canvas.
<marcoceppi> thanks
<hatch> yeah that's a tough one from past experience
<hatch> if you're going to disable it, it needs to have a custom one
<hatch> else I've found people get equally frustrated hah
 * hatch included
<rick_h> why would people right-click on the web? /me never would have even thought of thatr
<hatch> lol
<benji> if that's what the users expect, we could also actually make right click bring up the menu
<hatch> benji: right
<marcoceppi> the second question is more of a bug, but I wanted a sanity check on it. Currently I can't highlight text when drilling down in to the unit view (ie, click on service, click on unit, try to select IP address to copy), is this a known issue? Expected behavior? If not I'll also file a bug
<rick_h> Makyo: hmm, maybe we can deploy flag something like that? /me doesn't want to lose 'right-click - inspect element' even in the canvas
<marcoceppi> rick_h: maybe enable a "developer" mode which doesn't override right click?
<marcoceppi> Any event I'll create a bug for you guys to track it
<hatch> marcoceppi: I think the selection was disabled, checking
<hazmat> the inspector mode will change that
<Makyo> rick_h, agreed.
<hatch> marcoceppi: just to confirm this is in the new inspector?
<marcoceppi> hatch: I've just been deploying cs:precise/juju-gui
<marcoceppi> So whatever that constitues
<hazmat> the old unit/service view it sounds like
<hatch> but do you add /:flags:/serviceInspector to the url?
<Makyo> hatch, marcoceppi - no, drilling down is old behavior.
<marcoceppi> If there's a new inspector coming I'll just let them know that new cool shit is coming and to just dealwithit.gif
<Makyo> hatch, yeah, stuff under feature flags wouldn't be used in these contexts, I don't think
<hatch> marcoceppi: fyi on comingsoon.jujucharms.com I can't repro your select issue
<hatch> but yes big changes coming down the pipe soon :)
 * marcoceppi peeks
<marcoceppi> I like the slider
<marcoceppi> hatch: ah, yeah selecting text works. Thanks!
<marcoceppi> We had about 25 people using the GUI for the first time, all really overwhelmingly good feedback outside of the above questions!
<hatch> oh that's so awesome to hear :)
<rick_h> marcoceppi: good to hear
<marcoceppi> I saw them using it more than they were the cli ;)
<Makyo> Excellent :)
<hatch> haha perfect ;)
<jcsackett> rick_h: i think i have a fix up for the AC thing. care to review? https://codereview.appspot.com/12760045/
<rick_h> jcsackett: sure thing, doing the lbox dance with mine right now. Will pull/check it out when it's done
<rick_h> and swap you reviews :)
<rick_h> jcsackett: oh, can you see if that fixes the home bug I filed as well then? Seems it might be related. #1212695
<_mup_> Bug #1212695: home link moves during search in ie10 <ie10> <juju-gui:Triaged> <https://launchpad.net/bugs/1212695>
<rick_h> jcsackett: maybe not, nvn
<jcsackett> rick_h: i'll look.
<jcsackett> but yeah.
<jcsackett> rick_h: nvm on my MP. 
<jcsackett> in looking at yours i've realized mine introduces a new horror.
<jcsackett> (your bug, not your MP)
<jcsackett> goddamn IE requiring absolute positioning...
<hatch> jujugui guichat in 10 kanban now
<rick_h> jcsackett: ugh, yea I was afraid of that. 
<rick_h> jujugui couple of reviews please, not IE specific. Happens in all browsers. https://codereview.appspot.com/12997043 but the bug was noted in IE
<jcsackett> rick_h: looking.
<Makyo> rick_h, on it.
<rick_h> thanks guys
<hatch> jujugui looking for 2 very quick reviews on https://codereview.appspot.com/12998043/ as well
<Makyo> hatch, on it
<hatch> thanks
<bcsaller> think its already got two :)
<hatch> jujugui guichat in 2
<Makyo> bcsaller, hatch Well...bonus!
<bcsaller> everyone likes more tests
<Makyo> \o/
<hatch> jujugui guichat on now
<jcsackett> ok. i'm going to get lunch. IE10 has temporarily dispirited me.
<rick_h> jcsackett: hah, don't let it beat you down!
<hatch> are constraints supposed to be 'dumb' right now? Or are we supposed to be pulling the options from juju?
<rick_h> no idea
<hatch> I love lines that are 80 characters long
<hatch> such - a -rebel
<rick_h> down with him!
<hatch> ugh I can't wait until we switch to sass and have sourcemaps for our css
<lovea> Quick question about charm deployments - Juju client run on node that has internet access and on isolated internal LAN, Juju boostrap node on isolated LAN/no internet access, Juju-GUI node on isolated LAN/no internet access. Q1: Does Juju client pull charms from the charm store and push to Juju bootstrap node? Q2: Is Juju-GUI node useless without an internet connection to pull pickable charms from?
<rick_h> lovea: the final point is true. The Gui needs access to https://manage.jujucharms.com to show the list of available charms to pick from. 
<rick_h> icons and data are pulled from that data endpoint
<lovea> rick_h: ok, thought so
<rick_h> hatch: Makyo do you guys know how a 'deploy' goes down? Does the gui send the charm over to the bootstrap node? Or do we just tell it to fetch it?
<Makyo> rick_h, we just tell it to fetch it.
<hatch> just fetch it
<rick_h> Makyo: cool, thanks. What I assumed. 
<rick_h> lovea: so does that answer the other part then?
<lovea> Forgive my ignorance but would the theory be that, given an internet enabled Juju-GUI node, I could wire up my charms to meet my specific deployment needs as a "model", export the "model", use the Juju client to actually implement the "model" in my isolated environment.
<Makyo> rick_h, lovea GUI will work as a monitoring tool behind the firewall, would still show the environment, but charm-store would be empty.
<Makyo> lovea, yes.  You can use the GUI and then export (or even just write down) your environment to be deployed elsewhere.
<Makyo> lovea, There is a section on "Deploying behind a firewall" at https://jujucharms.com/fullscreen/search/precise/juju-gui-74/?series=precise&text=juju-gui&type=approved#bws-readme
<lovea> or are we saying that Juju bootstrap node also needs to be internet enabled because it gets fetch instructions from Juju client?
<lovea> Makyo: ok I'll read up on this. Many thanks
<Makyo> lovea, the bootstrap node would only need internet if deploying charms from the charmstore (eg: "cs:precise/mysql").  Using the CLI, one can deploy local charms, however.
<lovea> rick_h, Makyo: Thans for te clarifications
<Makyo> Cheers.
<lovea> quit
<benji> abentley: the bundle API tweak branch is up for review if you have a moment (after lunch): https://code.launchpad.net/~benji/charmworld/update-bundle-api/+merge/180384
<abentley> benji: Okay.
<hatch> rick_h: what was the trick you used to get templates auto generating again?
<rick_h> hatch: there was a typo in the dir name in the config of places to look?
<hatch> ahh right
<rick_h> manually I'd do rm build-shared/juju-ui/templates.js  && make build-shared/juju-ui/templates.js
<hatch> yeah that's it, I'll try that
<abentley> benji: I have an important call in 15 and I need to do some prep.  Is it cool if I delay your review by an hour or so?
<abentley> benji: I have some thoughts, but haven't gotten everything done.
<benji> abentley: sure
<hatch> bcsaller: this collective event stuff has gota be fixed lol
<jcsackett> does IE have any sort of dev tools?
<hatch> F12
<rick_h> jcsackett: yea, in the options is "developer tools"
<hatch> they are 'sort of dev tools'
<rick_h> (right side gear)
<hatch> F12 opens it
<rick_h> yea, I noticed 'debugger;' didn't do me any good :(
<rick_h> and the element selector only half works
<hatch> nope you have to click 'start debugging'
<hatch> the element selector works only if you hit 'refresh' in the devtools first
<jcsackett> rick_h: i do not have a developer tools option in my gear menu. f12 worked though.
<hatch> jcsackett: they actually market it as "The F12 Developer Tools" :D
<rick_h> jcsackett: oh, ok then
 * jcsackett continues to loathe IE.
<rick_h> carry on
<hatch> they say the IE11 ones are actually real devtools
 * hatch is hoping
<hatch> I used to have to support IE7+
 * jcsackett is hoping to never need IE11 tools, b/c he's hoping to never to IE work again.
<hatch> AND the 'simulator' in IE10 doesn't even come close to simulating IE8,9 properly
<hatch> sorry :)
<jcsackett> rick_h: got a bit to chat? my current approach is so error prone i think i need to step back and maybe hear other ideas.
<rick_h> the 9 one did a good job with 8
<rick_h> jcsackett: sure thing
<jcsackett> rick_h: guichat is open.
<hatch> rick_h: also lemme know when you want to chat about the db stuff
<Makyo> Hm.  Good news, bad news.
<Makyo> Good news: ingest now adds viewBox to icons.  It works in FF and IE.
<Makyo> Bad news: it only MOSTLY works in IE.
<Makyo> This wouldn't be easy >:/
<hatch> what's mostly? :)
<Makyo> It fixes the icons in the service blocks, but not in the browser (which might be because they're not styled with a size - investigating), and not in the inspector (for potentially the same reason)
<hatch> ARG!!!! I can't propose my branch until I upgrade jshint so I can tell it about globals......
<hatch> Makyo: ahh ok, well good luck :)
<Makyo> What globals?
<hatch> this._unitSpinner = new Spinner({
<Makyo> Oh, and Spinner isn't provided by YUI or anything?  I mean, that's how we get d3.
<hatch> I should be able to do /* global Spinner */
<hatch> I think d3 is defined by the namespace methods
<hatch> so it's not actually a global
<hatch> we dont jslint the html so that's why this hasn't come up before
<hatch> :/
<Makyo> Nah, not that I can see.  It's just used immediately in app/topology/topology.js
<Makyo> Oh well, though.
<Makyo> We've used the spinner before in JS, though.  It hasn't come up yet?
<hatch> hmm you're right
<hatch> nope the spinner is only ever used in index.html
<hatch> and in my new code
<hatch> ohh wait
<hatch> I was grepping crappy
<Makyo> and app/widgets/overlay-indicator.js
<hatch> guess I'll have to make this spinner in the index.html as well
<hatch> :/
<hatch> I am curious as to how d3 is being defined there
<hatch> in topology.js
<hatch> as in why the linter isn't going wako
<Makyo> What is Y.spinner.getSpinner()?
<hatch> I guess I could refactor that to be a generator
<Makyo> It's already there, that's what I'm saying.
<hatch> but even there it's not blowing up...
<Makyo> I'm sure you'll figure it out.  We're all counting on you.,
<hatch> lol
<hatch>  /rage
<Makyo> So why won't Y.spinner.getSpinner() work in your case?
<hatch> it's mergingness of it's options will not work for some of the options i need
<Makyo> Can't you provide an options object?
<hatch> so I can fix that....but I'm not sure if that's the right place
<Makyo> I'm not sure what you mean by mergingness, so...
<hatch> it merges it's defaults with the config that I need
<hatch> so I'll either need to specify more options resetting them to other defautls
<hatch> or patch the file
<hatch> script*
<rick_h> jcsackett: http://paste.mitechie.com/show/1002/
<Makyo> Patching sounds notsogood.  Is there an issue with specifying all the options you need?
<hatch> well nothing beyond I have to go find out what the defaults are
<hatch> when the issue at hand is really the tools
<Makyo> That's fair, and perhaps working with upstream is required, but working with tools is kinda what we do.
<rick_h> hatch: reuse the existing spinner. What's wrong with it?
<hatch> it doesn't fit in an input box and isn't blue :)
<bcsaller> hatch: can't you just use an animated gif for the little in <input> field spinner you need?
<rick_h> well, wtf is 'blue' a thing? Spinner is standardized.
<rick_h> and we can adjust the size in the widget if we need I believe
<rick_h> ah, nvm. We use the same animated gif, not js spinner. We had a bug for that at some point
<hatch> bcsaller: only if you have one :)
<bcsaller> hatch: http://www.ajaxload.info/ ;)
<hatch> lol
<rick_h> hatch: why are we spinning a single input box?
<hatch> indicator to let the user know units are being spun up
<rick_h> link to the UX mockup?
<hatch> v11
<hatch> oh it's on the dropbox one
<hatch> I don't have the link on this machine
<bcsaller> in google drive if you search inspector and pull the v11 hit though its there
<rick_h> yea, loading/looking
<hatch> it's ok I have updated the linter already
<hatch> there is only 2145 errors!
<rick_h> the little blue refresh-looking thing?
<hatch> oh that was only 33% of the files heh
<hatch> I think it needs some config options
<hatch> rick_h: yes
<rick_h> hatch: well where's the assets for it then :P
<rick_h> why are you complaining about Spinner when you can't use that anyway
 * rick_h is confused
<Makyo> This sounds like a less than ideal path, and also counter to what we've done in the past of two-step implement-and-then-style branches.
<hatch> so drop the spinner?
<rick_h> yea, until you have the assets to implement it imo
<Makyo> Or implement A Spinner, and style it later.
<rick_h> yea, I guess I'd do it textual with a "replace with gif when available"
<hatch> it is implemented heh
<Makyo> Eh, nevermind, I'm out.  Gotta eat, then propose the charmworld stuff.
<hatch> bcsaller: I'm going to grab the asset from there I guess :)
<hatch> interesting the old jshint accepted our json files, the new one does not
<hatch> looks like it doesn't accept the old config file
<hatch> yeah it'll take a bit to reconstruct this config
<hatch> bcsaller: it appears that the databinding system doesn't like to have multiple fields bound to the same value
<hatch> ohh wait nm
<hatch> wait nope it's definitely broken
<hatch> it only ever calls the update method once regardless of how many fields are bound
<hatch> the 'target' gets overridden by the last element with the binding set to it
<Makyo> jujugui charmworld branch for viewbox on icons (default and ingested) https://codereview.appspot.com/13001044
<benji> Makyo: I assume you're looking for a review.  I'll take a look.
<hatch> looks good to me but I'm not really qualified :)
<bac> Makyo: i'll look
<Makyo> benji, bac Yes, thanks.
<bac> Makyo: have you run 'make lint'?
<Makyo> bac, not yet, had assumed .lbox.check did that, will do it now.
<bac> Makyo: hey you could add that to .lbox.check if you wanted.  but, the charmworlders are not generally using lbox.
<Makyo> bac, Oh, okay, maybe I'll do that.
<bac> Makyo: actuallly, charmworld is using tarmac to land, triggered by the merge proposal on LP.  so using lbox is actually problematic.
<Makyo> bac, Only once the MP is marked approved, though, right?
<bac> Makyo: i'll go vote approved on LP.  you'll then need to set a commit message and mark the whole thing Approved when you're ready to land.
<Makyo> bac, so propose shouldn't affect it, just don't submit?
<Makyo> bac, okay.  Only done this once before :/
<bac> Makyo: votes need to be recorded over there too.  btw, charmworld is only requiring one review
<Makyo> Oh, okay.
<bac> Makyo: for now, it may make sense to change .lbox.check to be only run /bin/false
<Makyo> benji, single/double quotes: the processing instruction is generated by ElementTree with single quotes, but attributes are generated with double quotes.  I could switch to single quotes and escape the internal ones, but I figured this was cleaner.
<benji> Makyo: that makes sense; maybe it's worth commenting
<Makyo> benji, Alright.  As for the logs issue, I was under the impression that we should be adding the attribute on ingest, since we can as long as we have width/height (it's just 0 0 <width> <height> every time).  Should I log it anyway, or die, or..?
<benji> Makyo: ah, so we just need the attributes, even if they are 0?  If so, a warning (or info, or nothing) seems fine.  I would add a comment about why we're doing what we're doing though.
<Makyo> benji, I can check for 0 as well, since that would be a malformed SVG.  Logging and commenting sound fine too.
<benji> well, you can use lbox for inline code reviews if you want, but landing has to be done through LP
<Makyo> Alright.
<abentley> sinzui: I just landed versioned charm-ids.
<abentley> sinzui: Or rather, deployed them to staging.
<sinzui> \o/
<hatch> awesome!
<hatch> bcsaller: I'm going to work around this now but I'd like your input whenever you have some spare time https://bugs.launchpad.net/juju-gui/+bug/1212813
<_mup_> Bug #1212813: databinding only allows a single field to be bound to an attribute <juju-gui:New> <https://launchpad.net/bugs/1212813>
<sinzui> abentley, benji: do either of you have time to review my unsexy branch that adds the concept of API3 https://code.launchpad.net/~sinzui/charmworld/add-api-3/+merge/180426
<abentley> sinzui: Sure.
<abentley> sinzui: For the test_health changes, it looks like thge test cases are almost identical.  Have you considered using two TestCases and just overriding the check_api call?
<sinzui> abentley, I can do that.
<abentley> sinzui: The indentation at 173-174 looks odd to me.  I'd expect it to line up with the opening paren, or else for it to be indented once.
<abentley> sinzui: check_api3 isn't used yet, right?
<sinzui> abentley, nasty pep8 check wanted the if continuation separated from the lines executed
<sinzui> abentley, check_api3 is used by the /heartbeat view
<sinzui> Its check though uses the same rules as API2
<sinzui> almost the same rules
<sinzui> all the checks have a common control structure
<abentley> sinzui: How does check_api3 get referenced by /heartbeat?
<abentley> sinzui: nm, found it.
<sinzui> line 244
<abentley> sinzui: r=me.
<sinzui> abentley, thanks. I'll refactor the tests before landing
<Makyo> Good news everybody.
<bcsaller> hatch: having looked at it I don't see why that would be true (it used to be when we used a map for _bindings, but now its an array)
<Makyo> I was actually insane when I said things didn't work on Chrome.  Thinks work fine :)
<Makyo> s/chrome/IE10
<hatch> Makyo: yay for insanity!
<Makyo> "things are actually alright" is the best kind of insanity.
<hatch> I think that's insanity after the medication
<Makyo> Hah! I reverted my config change before I checked the icons last time.
<Makyo> It looks like the branch approved earlier fixes most icon issues.
<Makyo> Minus the one in the inspector, but that appears to be styled wrong.
<Makyo> jujugui need one quick review for trivial: https://codereview.appspot.com/12828045/
<hatch> Makyo: lgtm
<Makyo> hatch, thanks.
 * hatch is furious - sent my wifes HTC One in for repairs because the screen is separating and they just called saying that the repair depo says it's physical damage and that it'll be $250
<hatch> but of course I can't talk to anyone about this bs until tomorrow
<hatch> good thing I took pictures of the device before it was shipped
 * Makyo finally dogwalks
<hatch> bcsaller: hmm not sure - I've been fighting getting the tests to pass again so I haven't looked into it much but I know that the 'update' method was only called with a single value (the last one) so we'll just have to look at that sometime in the future
<bcsaller> hatch: I'll try adding a test for it to what I'm doing now. Does your branch already include the change to sum up the changeKeys between updateDOM intervals, because this would look like that as well I think
<hatch> bcsaller: here is my branch https://code.launchpad.net/~hatch/juju-gui/scale-up-ui
<hatch> a....plethora of tests fail now hah
<hatch> if plethora was 7
<hatch> well...7 is when it stops
<hatch> there is probably a lot more
<hatch> arg I broke the databinding
<hatch> bcsaller: have a minute to take a look at my databinding code?
<hatch> I'm sure I'm missing something obvious
<bcsaller> hatch: what part do you want me to look at?
<hatch> http://bazaar.launchpad.net/~hatch/juju-gui/scale-up-ui/view/head:/app/views/databinding.js#L194
<hatch> for some reason this causes the conflict code to apply the conflict style to the wrong element
<hatch> which element....I'm not sure....possibly the mirror one?
<hatch> bcsaller: if I comment out 194-204 it works as expected
<bcsaller> hatch: I think you put the key collapse code in the wrong place though, I saw this living in modelChangeHandler (dealing only with keys) and cleared in updateDOM. By dealing only with keys at that layer we can select all bindings that match those keys in deltaFromChange
<bcsaller> does that make sense?
<bcsaller> you try and remove dup bindings, but this is the binding, not the change, we just want all the bindings matching a key at this point
<bcsaller> (or a set of keys)
<bcsaller> if you'd like I can take a stab at it
<hatch> hmm maybe I've been staring at this too long because I was under the impression that I was aggregating the deltas using this technique
<bcsaller> deltasFromChange is only the delta in the keyspace of the model, not the change events
<bcsaller> you are close though
<hatch> ok I am totally missunderstanding what's happening here then - maybe if you wouldn't mind fixing it so I can see what I'm missing
 * hatch slides a pint of beer across the table
<hatch> how about now?
<hatch> :)
<bcsaller> hatch: happy to, I'll write it now and you can merge when I have it ready
<bcsaller> virtual beer... 
<hatch> awwwwsuuuummmm
<hatch> next sprint - real beer
<huwshimi> Morning
<hatch> hey huwshimi how are you doing?
<huwshimi> hatch: Good thanks, yourself?
<hatch> could be better :)
<huwshimi> hatch: Are you sick?
<hatch> nah, just stupid things happening today
<huwshimi> oh
<hatch> HTC repair depo not wanting to fix my wifes One set me off
<hatch> huwshimi: so hows that IE stuff coming?
<bcsaller> hatch: so I *think* this should fix it, but I didn't generate a full test for the multiple key case as getting the timing right on that would delay you actually testing it. lp:~bcsaller/juju-gui/databinding-safeupdate 
<hatch> bcsaller: ok looking thanks
<bcsaller> hatch: if that doesn't help I'll keep at it with you
<hatch> bcsaller: ok I gota merge this in manually so it'll take a second
<bcsaller> hatch: if you didn't change databindings.js for anything else take that version
<hatch> yeah I added the prev value stuff
<huwshimi> hatch: Our animating input fields are being a pain. We need to set the inputs in the inspector to a flexible width as the size of the scrollbars varies between browsers.
<bcsaller> router issue, might lose wifi here
<hatch> ok merged...trying
<hatch> bcsaller: awesome, fixed
<bcsaller> sweet
<hatch> thanks a ton
<hatch> now to figure out the difference
<hatch> I think I saw it though
<bcsaller> yeah, I was going to ask
<hatch> ahhhh now I see now I see
<bcsaller> this just accumulates keys until updateDOM is called
<hatch> you only deal with the keys not the datasets
<bcsaller> yeah
<bcsaller> keeps it simple
<hatch> I'm not entirely clear why my technique broke it though
<hatch> clearly it was wrong...but I don't know why....
<bcsaller> you thought delta in deltaFromChange means ws delta changes or something
<bcsaller> we are selecting the binding objects for model change keys here
<bcsaller> so a set of keys becomes a set of bindings
<bcsaller> not change events
<hatch> ohh that's why it was pointing to the incorrect element
<hatch> ok got it now
<bcsaller> the delta is vs the keyspace of the model in this case. I'm open to renaming it so this doesn't happen to another dev
<bcsaller> bindingsFromModelChange or  somesuch
<hatch> yeah it's not  bad idea....now I"m going to tackle the remaining failures :)
<hatch> thanks again!
<hatch> ohh my prevValue code doesn't support pojo's
<hatch> huwshimi: did you need a hand or need to bounce any ideas off anyone for that?
<huwshimi> hatch: It's ok I just need to modify the scrolling code which is all fairly hardcoded to be more flexible
<huwshimi> scrolling/animating
<hatch> ahh ok, I think there was a scrolling change landed today
<hatch> so you might want to merge trunk
<huwshimi> hatch: Ah right, thanks
#juju-gui 2013-08-16
<hatch> hmph I found a databinding test that was passing by accident
<hatch> hehe oops
<hatch> only 99 more test failures to go!
<hatch> 99 test failures on the wal....99 test failures
<hatch> you knock one down, re-run the tests, there's 98 test failures on the wall
<hatch> 98
<hatch> :)
<hatch> 86 aww yeah
<rick_h> lol, what did you do to break things so?
<hatch> 70!!
<hatch> aww man I'm killin it
<hatch> rick_h: haha too many flybys
<hatch> I'm not even finished this branch but I have to land it because of the flyby bug fixes/enhancements
<hatch> yup so many failing tests because of small driveby fixes
<hatch> bcsaller: still around by chance?
<bcsaller> yeah
<hatch> so I think the unit count driveby broke the google analytics code
<hatch> because we no longer use ServiceUnitList correct?
<hatch> the test that's failing is test_model.js:158
<bcsaller> looking
<hatch> my mind is fried I should probably take a break
<hatch> after this test!
<bcsaller> hatch: iirc we didn't remove the global list (I wasn't sure what was using it) so the delta should update both
<bcsaller> and the update_agg... method does get called, we saw that yesterday
<hatch> yup but I think that the || 0 is causing the test to fail
<bcsaller> ahh, because it was changed to take the current unit list size so prev never differs from sum
<hatch> well sort of
<hatch> in investigating sum is 0 instead of 1
<bcsaller> I think its an ordering issue, it was using the cached value of unit_count, but taking the size of that unit_list directly depends on the order of the update in the delta code 
<hatch> just grabbing the old code to look at it
<hatch> ahh
<hatch> aggregate
<hatch> Object {pending: 1}
<hatch> so yep you're right...
<hatch> hmm
<hatch> so we still need a 'total' sum for analytics
<hatch> ick that doesn't feel right
<bcsaller> we have total, its the prev value thats getting lost
<hatch> well no at the time of the check there are 0 units in the service
<hatch> but there is 1 in pending in the aggregate
<bcsaller> service.units.size() is total, but the old size of that list is the thing in question
<hatch> prev_total_units is undefined in the test
<bcsaller> ahh, sounds like the order is opposite from what I thought it would be then
<hatch> yeah so it should probably be reverted then?
<hatch> I'm thinking that to properly fix this is going to be more than a quick driveby
<bcsaller> that is simplest or move the _gaq code into the handlers module and do it on a serviceunitslist after change 
<bcsaller> yeah, I'm fine with a rollback
<hatch> heh gaq
<hatch> I think that's the proper place to move it but this branch has so many drivebys already
<hatch> how about I create a ticket for this change?
<hatch> https://bugs.launchpad.net/juju-gui/+bug/1212897
<_mup_> Bug #1212897: Update service unit aggregate function to use new service unit location  <juju-gui:New> <https://launchpad.net/bugs/1212897>
<hatch> only 1 failure now!
<hatch> AssertionError: expected '2w' to equal '3'
<hatch> uhh wut?
<hatch> lol
<hatch> w00t 0!
<hatch> now to make sure the app still works after I fixed all the tests lol
<hatch> *sigh*
<hatch> bcsaller: I think there is a bug in your fix
<hatch> the prevValue stuff is now reporting the incorrect key sometimes
<bcsaller> hatch: unexpected or wrong, if you queue two changes to a key in a single window what do you expect to see, the first value or the second?
<hatch> do you have a second to look at the code? I can push it up
<hatch> bzr branch lp:~hatch/juju-gui/scale-up-ui
<hatch> databinding.js:172 the bindingName and the e.changed object sometimes don't match
<bcsaller> hatch: looking now
<bcsaller> hatch: you set it on the binding, which is the object describing the relationship between the model and the DOM, it is not a per-change datastructure
<bcsaller> so the issue in the preVal stuff
<bcsaller> need a hand with a fix?
<hatch> haha I guess I thought that this was the place to modify the delta
<hatch> I essentially wanted to augment the detla object with it's previous value
<bcsaller> yeah, there isn't really an object like that because the updateDOM handles that relationship in a fixed way. Getting the preVal and saying its the first value of a buffered update window to change on the model makes sense to add, but it would have to be managed in the event layer, not the in bindings
<hatch> so is it looking like adding the prev value stuff now is going to be an issue?
<hatch> as in not just a few lines?
<huwshimi> Turns out what I thought I'd broken behaves the same in trunk...
<rick_h> huwshimi: yay! / booo!
<huwshimi> rick_h: Yeah, what a waste of time! :)
<rick_h> huwshimi: make sure you keep up the current work on the cards so jcsackett and I don't dupe IE work 
<huwshimi> rick_h: Sure
<rick_h> huwshimi: thanks
<huwshimi> rick_h: Although apparently we can only have two active cards :(
<bcsaller> hatch: I think it might still be a few lines, just different lines, we'd keep a mapping like we do with the keys that exists between updateDOM intervals, when we get a change for a key not in the map we record its preVal in that map and then feed that as an additional argument to update calls, then clear it at the end of updateDOM
<rick_h> huwshimi: I've been overriding with the exception "Die IE Die"
<huwshimi> rick_h: haha
<rogpeppe> does anyone know how to use the new charm browser to list all available charms?
<rick_h> rogpeppe: hit enter in the search box
<rick_h> rogpeppe: and if you want *all* uncheck the reviewed/series default checkboxes in the filters
<rick_h> rogpeppe: https://jujucharms.com/fullscreen/search/?text= is the url that you end up with. 
<rogpeppe> rick_h: thanks. i was sure i tried that...
<rogpeppe> rick_h: i actually ended up using the charm tool, ("charm list" followed by a fair amount of manual text mangling)
<rick_h> rogpeppe: k
<rogpeppe> rick_h: i'd still like to be able to fetch a definitive list of all the charm urls in the charm store
<rogpeppe> rick_h: i've just realised i've probably missed a load, as i only fetched charms in ~charmers or in lp:charm/xxx
<rick_h> rogpeppe: http://manage.jujucharms.com/api/2/charms?text=
<rick_h> rogpeppe: you can use the api like the gui does. Sec, let me get the docs
<rick_h> rogpeppe: http://bazaar.launchpad.net/~juju-jitsu/charmworld/trunk/view/head:/docs/api.rst
<rogpeppe> rick_h: awesome! that's just what i want, i think
<rogpeppe> rick_h: thanks a lot
<rick_h> rogpeppe: get what you need? we do have this bug out there, but it sounds like you wanted the urls directly so not sure it would have helped. #1202306
<_mup_> Bug #1202306: We need an "all" category <juju-gui:Triaged by lucapaulina> <https://launchpad.net/bugs/1202306>
<rogpeppe> rick_h: yeah, it looks exactly what i need, and a nice regular format, trivial to parse in go.
<rick_h> rogpeppe: cool, the only ones missing would be bad charms we can't import. Just a disclaimer to the final list
<rogpeppe> rick_h: ah, well, i don't mind too much about them.
<rogpeppe> rick_h: FWIW, here's my little script that downloads all known charms from the store: http://paste.ubuntu.com/5992556/
<rick_h> rogpeppe: cool, apis ftw
<rogpeppe> rick_h: they weren't all valid
<rogpeppe> rick_h: but i successfully got 663
<rogpeppe> rick_h: yeah!
<sinzui> bac, abentley. Do either of you have time to review https://code.launchpad.net/~sinzui/charmworld/modern-py/+merge/180562
<abentley> sinzui: Sure.
<abentley> sinzui: r=me.
<hatch> morning
<rick_h> morning party people
<jcsackett> morning all.
<hatch> yay for IE fixes you guys rock
<rick_h> :P
<rick_h> hatch: can you do the second review on huw's this morning please?
<hatch> I can yep
<rick_h> I think with that, Makyo's icon fixes, and jcsackett's in progrss branch that closes up the ones we had cards for at least
<rick_h> just that drag/drop 'odd' one left in launchpad
<hatch> rick_h: that one is fixed
<hatch> I landed a fix for that last week
<hatch> updated the ticket
<hatch> sry
<hatch> having fix committed and in progress the same color makes it hard to scan...
<rick_h> hatch: ah, gotcha
<rick_h> oops, my bad jcsackett. I was going through reviews this morning and it was open with the old code
<hatch> horrible person allert
<jcsackett> rick_h: it's up with the right code for review now.
<jcsackett> https://codereview.appspot.com/12760045/
<rick_h> jcsackett: thanks looking
<rick_h> "You do not have permission to view this issue"?
<hatch> that's what you get for being a horrible person :P
<rick_h> jcsackett: is there a note on what the span with class absolute is for?
<jcsackett> rick_h: zuh? that's deleted.
<jcsackett> i don't see it in the MP when i'm looking.
<rick_h> jcsackett: looking at the LP review
<rick_h> https://code.launchpad.net/~jcsackett/juju-gui/ac-moves-the-screen-down/+merge/180363 ?
<jcsackett> rick_h: go to https://codereview.appspot.com/12760045/
<rick_h> jcsackett: I can't, see error above ^
<jcsackett> rick_h: nuts to this. i'm deleting it all, will ping when i've got it resubmitted.
<jcsackett> i have no idea why LP is showing one thing and rietveld is showing another.
<rick_h> jcsackett: ugh and ugh. Thanks
<benji> abentley: thanks for the good review of my branch, it is in the process of merging, but I though you might be interested in the tweaks I made to address the points you raised: http://bazaar.launchpad.net/~benji/charmworld/update-bundle-api/revision/350
<abentley> benji: Have you tested that non-dict values are jsonified correctly?  Because lists and strings and bools are instances of object.
<hatch> jcsackett: I was pretty sure that the autocomplete list box was set to position absolute by default
<hatch> are we sure we aren't missing any classes?
<jcsackett> hatch: rick_h and i both looked at this. it is set by default in all browser but IE10
<benji> abentley: ooh, that's a good question; I'll add tests to that effect and see what comes
<hatch> seriously?
<hatch> ugh
<hatch> that sounds like a YUI bug
<rick_h> hatch: so somehting was setting it in the actual element with style="xxx yyy position: relative"
<rick_h> hatch: I couldn't dupe it in defualt yui examples in IE
<rick_h> in other browsers there was no edits to the element with a manual style=""
<rick_h> hatch: so not sure where it was coming from tbh
<rick_h> hatch: and since chrome/etc aren't doing it I can't set a breakpoint on dom changes 
<hatch> aww damn that sucks
<rick_h> hatch: yea, it's hacky, and no idea why it's mis-behaving. but it works :/
<hatch> I'll take one review/qa on it
<hatch> rick_h: are you going to land huw's branch?
<rick_h> hatch: I wasn't going to no. I figured it's not a rush and he can land it as long as he gets the two reviews
<hatch> ehh that won't be until monday
<hatch> I can do it later
<antdillon> Hi guys, I have a prototype for Luca and he would like it hosted somewhere. How do you host a fork of the juju-gui?
<rick_h> hatch: but it's friday. I'm not going ot notice it :)
<jcsackett> rick_h, hatch: the MP is back up. https://codereview.appspot.com/12932044
<hatch> rick_h: haha - well if I have time I'll land it...we'll see :)
<rick_h> jcsackett: thanks
<luca> Makyo: bcsaller hey, are you guys there?
<hatch> antdillon: luca if it's just for a short time you could put it on ec2
<hatch> I'm not sure if you have your juju env's set up though
<rick_h> antdillon: yea, normally we run them on ec2 or something and point everyone at the url
<hatch> I used git yesterday - I had to look up the equiv for 'bzr info' heh oh boy I'm out of touch
<rick_h> hatch: lol
<hatch> I even know how to diff in bzr now like a boss...
<hatch> I have leveled up
<antdillon> rick_h, hatch Cool, how would I get it on ec2?
<hatch> antdillon: hopes and dreams.....hopes and dreams
<hatch> but for real....do you have a juju env set up?
<hatch> :)
<antdillon> hatch, Ran out of them a long time ago
<hatch> haha
<antdillon> hatch, Locally I do, nothing else where
<rick_h> antdillon: heh, you can be a docs guinea pig for marcoceppi and company :) https://juju.ubuntu.com/docs/getting-started.html
<hatch> ok so yeah you can follow those docs
<hatch> or try and find one of us with some time to put it up for you :)
<antdillon> hatch, I'll trail the docs and see how I get on :)
<Makyo> luca, hey, sorry, little late.  Here now.
<antdillon> rick_h, Thanks
<hatch> antdillon: sure thing - let us know if you run into any issues
<hatch> you'll require an ec2 account of course
<hatch> jcsackett: LGTM QA OK
<hatch> oh Windows 8.... "Shutdown" "Update and restart" umm I think it's missing an option there
<hatch> except I think shutting down also installs the updates heh
<hatch> rick_h: at the sprint/ sometime else I'd like a hand fixing my vim/terminal setup, somehow I managed to turn http://vim.spf13.com/ into a white background with white text in vim
<hatch> lol
<rick_h> hatch: lol, ok. Sounds good
<hatch> I'm sure I'm missing something but I just can't figure out where these styles get applied
<rick_h> :colorscheme
<rick_h> :colorscheme <tab> to get a lits of ones available
<luca> Makyo: can we talk scaling?
<rick_h> and maybe that can get you unstuck for a moment
<Makyo> luca, sure.
<hatch> rick_h: yeah I have to do :color ir_black every time I open it
<hatch> https://github.com/seebi/tmux-colors-solarized I attempted this first
<hatch> also with varying degress of success
<hatch> heh
<hatch> man I can not type today
<rick_h> hatch: well look for 'colorscheme' in your ~/.vimrc
<rick_h> hatch: it should be set in there, maybe twice if running different colors for cmd-line vs gui
<hatch> I think there is a conflict between the colorschemes and the tmux/zsh themes
<luca> Makyo: guichat?
<Makyo> luca, sure, on my way.
<hatch> luca: are you talking the sclaeup/down?
<hatch> I'm working on that right now, mind if I join?
<benji> abentley: I added tests for serializing non-mapping types and made them pass; thanks
<abentley> benji: Cool.
<Makyo> jujugui call in 10
<Makyo> Kanabaaaaaaaan!
<hatch> this....is.....kannnabaaaaaaaan
<hatch> Makyo: I was really hoping I could drop this upgrade units stuff off a cliff instead of pick up another card :P
<Makyo> hatch, Well, you can defer it for another...three minutes?
 * Makyo helpful
<hatch> lol
<Makyo> jujugui call in 1
<Makyo> abentley, call now
<hatch> bcsaller: once I'm done with rick then we can chat
<benji> abentley: I need to take a quick break and then do you want to chat about handoff of your current card?
<sinzui> adeuring, We have a call scheduled in 75 minutes, but I think Mark R is off today
<sinzui> We can show up, but I suspect we need to reschedule.
<adeuring> sinzui: ok
<abentley> benji: was going to take lunch in a few.  How about 68 minutes from now?
<benji> abentley: sounds good
<bcsaller> hatch: just let me know, I'll  have some coffee in the meantime
<hatch> bcsaller:  ok in guichat
<hatch> so hows everyones day going?
<hatch> that good hey? ;)
<hatch> yusss https://www.webkit.org/blog/2910/improved-support-for-high-resolution-displays-with-the-srcset-image-attribute/
<bac> hah, typo of the day from an email i just received:  "If I click on the undicode it brings up the glyph"
<hatch> jujugui could I get two reviews on https://codereview.appspot.com/12784046/ pllllzzzzz
<benji> hatch: I'll do one
<bac> sure
<hatch> thanks guys
<abentley> benji: lp:~abentley/charmworld/bundle-heads
<benji> cool
<abentley> benji: It has a bunch of refactoring  because I wanted to be able to test the bundle docs, to ensure they had the both the mongo id and the elasticsearch id.  But I'm not wedded to that approach.
<benji> ok
<hatch> hmm something just dinged me but I don't show any messages :/
<abentley> sinzui: I doubt that we will ever be able to implement  #1086551 since updating a readme means pushing to launchpad.  (Doing it locally would lead to conflicts when the branch's copy of the readme changed.)
<_mup_> Bug #1086551: Allow inline editing of a charm's README <charmworld:Triaged> <https://launchpad.net/bugs/1086551>
<sinzui> abentley, indeed
<hatch> so funny story jshint now has indentation support and it thinks it should be done differently then gjshint
<hatch> lol
<hatch> the new jshint is crazy fast though
<hatch> even if all it's doing now is throwing 15027 errors
<sinzui> abentley, I think the bug implies ownership. I think an oauth proc would be required. It would branch, patch, and push in the name of the oauth
<sinzui> abentley, I don't see anyone building that when charmers review every charm before reading the webui
<Makyo> jujugui 1 review for trivial: https://codereview.appspot.com/13069043
<abentley> sinzui: In order for it to do that, it would have to be part of Launchpad, because the only way Launchpad currently supports updating a branch is via SSH.
<abentley> sinzui: Or we'd need to update Launchpad's SSH to support OAUTH.
<hatch> jujugui is there a reason why we jshint our json mocks?
<hatch> I'd like to remove them as json now follows the same config as js
<bcsaller> I can't think of a good reason
<Makyo> hatch, +1  If the mocks are broken, it will be reflected in the tests.
<bac> hatch: so to qa your branch i'll need to load it up in ec2?
<hatch> bac: no I can give you a script
<hatch> one sec
<hatch> sorry
<hatch> bac: here is the code that will throttle the add unit creation https://gist.github.com/hatched/118a91ba19be71bde4f2
<sinzui> abentley, I thought there was a comparable bug for Lp or loggerhead, but I cannot find one. I wanted to dup the issue
<hatch> it's a hack so you'll have to do it manually
<hatch> bcsaller: Makyo ok thanks for the sanity check, removing them from JSFILES in the makefile
<hatch> oh boy this is one heck of a command
<hatch> haha
<hatch> hmm
<hatch> it 'should' be ignoring them now
<hatch> I think...
<benji> abentley: I'm going away now, but I don't see anything in your branch that raises any questions -- instead I'm sure that'll happen when you're not here to answer them ;)
<abentley> benji: okay, have fun.  If you do have questions, sinzui's mental model is close to mine.
<benji> cool
<hatch> benji: lol fyi `e` is the convention in YUI for event object :)
<benji> I'll be sure to donate some of our lottery winnings to the YUI project then.
<hatch> haha - belive me I'm definitely a fan of the real variables
<hatch> maybe it's just habit
<hatch> so funny thing - after fixing the config and the makefile for the new jshint - the new one actually caught more errors
<hatch> so my guess is that it would have caught the one nicola found
<abentley> orangesquad or bac: Could you please review https://code.launchpad.net/~abentley/charmworld/remove-redudant-id/+merge/180642 ?
<sinzui> I can
<sinzui> abentley, \o/ I can remove an xxx from by branch when your lands
<abentley> sinzui: :-)
<sinzui> abentley, r=me
<abentley> sinzui: Thanks.
<hatch> wow...there were quite a few errors that this version is making me fix
<hatch> jujugui looking for two reviews on the upgrade jshint branch https://codereview.appspot.com/13072043/ Thanks
<jcsackett> hatch: you've got oen.
<jcsackett> s/oen/one/
<hatch> thanks sir
<hatch> bac: I agree that we should pluralize that but right now I reaaaaaly want to land this branch so in a follow-up :)
<bac> hatch: a-ok
<hatch> I'd also like a QA of that jshint upgrade branch......just to be safe :)
<hatch> basically make sure it can still 'make' and 'make lint'
<hatch> anyone else able to take a peek/qa of that jshint branch?
<hatch> it went up 2 major versions so could use another qa :)
 * sinzui thinks elasticsearch tests get slow after repeated test runs
<sinzui> 31s, 44s, 49s, 57s, 79s, 168s
<hatch> haha
<hatch> that's odd
<hatch> rick_h: Makyo: I'm going to land huw's changes now
<Makyo> Good luck.
<Makyo> Yer gonna need it.
<hatch> lol am I?
<Makyo> Well, no, probably not.
<hatch> haha
<Makyo> Just trying to branch out from Airplane! to Star Wars.
<hatch> you should try anchorman
<hatch> stay classy san diego
<Makyo> Hah, I have yet to see that, actually.
<Makyo> James won't watch it with me, though.
<hatch> no? is he a hater?
<Makyo> Hahaha
<hatch> a Will Ferrell hater that is
<hatch> they are out there
<Makyo> I have to be honest, there's only one Will Ferrell movie I've liked so far.
<hatch> oh so you're one of 'THEM'
<Makyo> Yep :)
<hatch> lol I pretty much like all of his stuff
<Makyo> I did like Stranger Than Fiction well enough.
<Makyo> Mostly because that's some of the least typecast work I've seen.
<hatch>  haha
<Makyo> He wasn't even against type, just not 100% goofball.
<hatch> ahh yeah true true
<hatch> did the autocomplete pushdown bug in IE get landed?
<Makyo> Looks like.
 * Makyo dogwalks
<hatch> bcsaller: I have a viewlet idea I'd like to bounce off of you, you around?
<bcsaller> yeah, I'll hop on chat
<hatch> cool I'm there
<hatch> of course there is a new IE bug
<hatch> https://bugs.launchpad.net/juju-gui/+bug/1213260
<_mup_> Bug #1213260: DDing a charm renders service icon under sidebar <ie10> <juju-gui:New> <https://launchpad.net/bugs/1213260>
<hatch> https://bugs.launchpad.net/juju-gui/+bug/1213262
<_mup_> Bug #1213262: Text is too large in ghost inspector name field <ie10> <juju-gui:New> <https://launchpad.net/bugs/1213262>
<hatch> https://bugs.launchpad.net/juju-gui/+bug/1213264
<_mup_> Bug #1213264: Overview Inspector has horizontal scroll bar in IE10 <ie10> <juju-gui:New> <https://launchpad.net/bugs/1213264>
<hatch> nice fresh stream of IE bugs coming in on a Friday :)
<Makyo> None of these are so high priority as to freak out about, thankfully.
<hatch> nope, functionally it's going well
<hatch> Makyo: although the charm icons still are only 1/4 on trunk
<hatch> I'm going to assume that hasn't landed yet?
<Makyo> hatch, That fix was in charmworld, not gui.
<hatch> ohh ok so it's still 'landing'
<hatch> gotcha
<Makyo> hatch, According to sinzui today, once that hits production with other work, a max of 15 minutes until icons are rebuilt.
<hatch> great - we'll have to keep an eye on it next week
<hatch> https://bugs.launchpad.net/juju-gui/+bug/1213267
<_mup_> Bug #1213267: Unit scale up constraints dialogue wraps <ie10> <juju-gui:New> <https://launchpad.net/bugs/1213267>
<Makyo> Ugh, IE :|
<hatch> lol I know right?
<hatch> hey no js errors yet
<hatch> that's gota be something
<hatch> lol
<hatch> IE has this odd thing where it puts an X on the right of an input box to clear it...?
<Makyo> Yeah, for touch stuff.
<Makyo> I switch out of metro first thing, now.
<hatch> oh I'm not in metro
<hatch> I'm in desktop ie
<hatch> I just updated it though so mayvbe it's a new feature
<Makyo> Oh, yeah, updating now.
<Makyo> Maybe I'll get them, too.
<hatch> https://bugs.launchpad.net/juju-gui/+bug/1213270 here is the bug if you want to comment
<_mup_> Bug #1213270: IE10 has native 'Clear Input' X while input is focused in inspector <ie10> <juju-gui:New> <https://launchpad.net/bugs/1213270>
<Makyo> Will.  Dunno if we can do anything about it, but we'll see.  There are some attributes added to input elements now that might help.
<Makyo> Like the no-autocomplete and no-spellcheck or whatever.
<hatch> yeah I was thinking there might be a flag like no autocomplete
<hatch> haha
#juju-gui 2013-08-18
<huwshimi> Morning
#juju-gui 2014-08-11
<rogpeppe1> mornin' all
<rogpeppe> frankban: hiya
<rogpeppe> frankban: https://github.com/juju/charmstore/pull/66
<frankban> rogpeppe: morning, on it
<rogpeppe> frankban: ta
<frankban> rogpeppe: LGTM
<rogpeppe> frankban: ta!
<rogpeppe> frankban: next up: https://github.com/juju/charmstore/pull/67
<rogpeppe> frankban, dimitern, TheMue, jrwren: a little fix: https://github.com/juju/charm/pull/38
<TheMue> rogpeppe: one moment, meeting
<rogpeppe> TheMue: np
<TheMue> rogpeppe: quickly done, has been nicely small
<rogpeppe> TheMue: ta!
<frankban> rogpeppe: done
<rogpeppe> frankban: thank you
<rogpeppe> frankban: there's no CI set up on the charm package, is there?
<frankban> rogpeppe: AFAIK there isn't
 * frankban lunches
<rogpeppe> frankban, TheMue, dimitern, jrwren, fwereade: update juju-core to use charm.v3: https://github.com/juju/juju/pull/489
<dimitern> rogpeppe, reviewed
<rogpeppe> dimitern: thanks!
<TheMue> ah, I can step out, just started with review
<TheMue> first shrugged about the number of files :)
<rogpeppe> TheMue: it's almost all just import path changes
<TheMue> rogpeppe: yeah, Iâve seen, additionally only those parts where the API changed
<rogpeppe> TheMue: yup
<frankban> rogpeppe, jrwren: could you please review https://github.com/juju/charmstore/pull/68 ? thanks
<rogpeppe> frankban: looking
<frankban> ty
<rogpeppe> frankban: reviewed
<rogpeppe> lc
<frankban> rogpeppe: thanks
<rogpeppe> frankban, jrwren: would appreciate a review of https://github.com/juju/juju/pull/489 please
<rogpeppe> frankban: (the charm.v2 branch finally landed!)
<frankban> rogpeppe: cool, and this is v3
<rogpeppe> frankban: yup
<frankban> rogpeppe: do we want core to use unstable v3?
<rogpeppe> frankban: once core starts using it, it will no longer be unstable
<frankban> rogpeppe: ok
<jrwren> rogpeppe: done. I had looked earlier, but given its core, I didn't think I should +1.
<rogpeppe> jrwren: please add your +1 - i'll wait for frankban's review too
<jrwren> rogpeppe: done.
<frankban> rogpeppe: done
<rogpeppe> jrwren, frankban: thanks
<rogpeppe> oh shit
<rogpeppe> darn, forgot to update dependencies.tsv
<rogpeppe> it won't land
<frankban> rogpeppe: heh
 * rogpeppe wishes there was some way of cancelling a jenkins job that's already started
<rogpeppe> ha, no need, it's failed already
<frankban> jrwren: I tried to not fully duplicate the manifest logic on the test side: that's probably the reason why you are confused
<jrwren> frankban: Sounds good. I commented because I wanted to make sure it wasn't accidental.
<frankban> jrwren: cool
 * rogpeppe wants a merge tool that is a bit cleverer about go imports
<jrwren> I didn't notice until now that running tests spins up its own mongod to run. Cool.
 * rogpeppe goes for lunch
<hatch> frankban can you remind me how I go about qa'ing your precise branch? 
<hatch> I can't remember the best practice for pulling it down
<frankban> hatch: thanks for looking at it
<frankban> hatch: do you have a charm GUI shared repo?
<frankban> GUI charm even
<hatch> frankban I don't
<hatch> can I check out just HEAD somehow?
<frankban> hatch: so, time to create one ;-)
<frankban> hatch: bzr init-repo juju-gui-charm
<hatch> lol *sigh* I haven't had to set my vm up for bzr stuff again in a while
<frankban> hatch: cd juju-gui-charm
<hatch> ok got that far :)
<frankban> hatch: bzr branch lp:~juju-gui/charms/trusty/juju-gui/trunk trunk
<hatch> that's gona take a while :D
<hatch> see u in 10 years :P
<frankban> hatch: bzr checkout --lightweight trunk sandbox
<hatch> I do that after it's done downloading the entire repo, correct?
<frankban> hatch: bzr branch lp:~frankban/charms/trusty/juju-gui/fix-legacy-server
<frankban> yes
<frankban> hatch: cd sandbox
<frankban> hatch: bzr switch ../fix-legacy-server
<hatch> kadams54 looks like your branch has a test failure
<frankban> make
<jcsackett> kadams54: you need a second review, right?
<kadams54_> jcsackett: yeah, and to figure out why one test is failing.
<jcsackett> kadams54_: shall i wait till you've got that fixed?
<kadams54_> jcsackett: I think it's safe to QA.
<jcsackett> kadams54_: ok, i'll start reviewing now then.
<kadams54_> jcsackett: thanks
<hatch> jcsackett which view actually renders the charm details tabview when you click on the url?
<jcsackett> hatch: i don't understand your question. you mean the charm url in the inspector?
<hatch> when you click the charm url in the inspector
<hatch> it opens a view
<hatch> which view is that
<jcsackett> hatch: it uses showViewelet to open the charmDetails viewlet.
<jcsackett> which, in turn, uses browsercharmview...which in turn uses browserentitydetails, ircc.
<jcsackett> turtles, all the way down.
<luca__> when Juju is bootstrapped does the user have to define a name for it?
<hatch> luca__ it is in the environments.yaml
<hatch> we use that name in the GUI
<luca__> hatch: I see, thanks.
<luca__> hatch: and the user can have any name they want
<luca__> hatch: ?
<hatch> yep
<hatch> it's used as the key to the environment config
<hatch> so for example I have a `juju bootstrap ec2-precise` 
<hatch> which is an ec2 env using precise as the default series 
<hatch> there is also an ec2-trusty 
<hatch> etc
<hatch> jcsackett so why didn't you just prevent any click event on the anchor tags in the headers from bubbling from the tabview?
<jcsackett> hatch: b/c we want it to dispatch to set the hash.
<jcsackett> with the new dispatch model there's no reason those should be special cased from the other version of charm details.
<hatch> right, but a hash should just be able to be added to the end of the url all easy like
<hatch> jujugui call in 10
<jcsackett> hatch: that's not how it appears to work in charm details land off the charmbrowser.
<hatch> I was under the impression that the issue was that pjax was picking up the click and re dispatching?
<jcsackett> hatch: talk after the call?
<hatch> when it really should just be able to update the hash in the url, 
<hatch> yeah sure
<hatch> since we can't load the inspector in a real env I'm not sure how we can qa most of this anyways :)
<jcsackett> we can't load the inspector in a real env?
 * jcsackett thinks he missed something.
<jcsackett> and anyway, this was a bug with fakebackend too.
<hatch> nope it opens to a white sidebar and the charm details pane open - also blank
<jcsackett> when did that start happening?
<jcsackett> (you can still qa this against fakebackend--a real env wasn't necessary to create the bug)
<hatch> you were fixing it, and stopped because we were trying to get something else done....or something along those lines
<hatch> :)
 * jcsackett blinks.
<jcsackett> i haven't seen this happen in a real env, and don't recall what you're talking about.
<jcsackett> i recall a bug about this awhile ago, but i recall fixing that.
<hatch> if you visit a /inspector url in a real env you'll see it
<hatch> you fixed something in there by adding a retry 
<hatch> but this was something else i remeber you saying
<jcsackett> do we have a bug/card? b/c the only thing i recall related to this was quite old.
<hatch> yeah I can find it
<jcsackett> kadams54_: is your bug only about the deploy summary? the changelog is still showing individual everything.
<hatch> https://bugs.launchpad.net/juju-gui/+bug/1349565
<kadams54_> jcsackett: Correct. Deploy summary is condensed, changelog shows everything.
<jcsackett> kadams54_: cool.
<kadams54_> That's what hatch and I decided after talking through the bug.
<luca__> hatch: have you finished the new scale up journey
<luca__> hatch: ?
<hatch> luca__ in the inspector?
<hatch> or in the machine view?
<luca__> hatch: in the inspector
<hatch> yes that's done with the exception of Huw's branch in review which adds the "1 unit (3 uncommitted)"
<hatch> stuff
<hatch> that should be landing during his day as there are a couple issues with it atm
<hatch> frankban how do I check what branches I have/ what branch I'm on?
<frankban> hatch: bzr info
<hatch> thanks
<hatch> :)
<frankban> hatch: also bzr branches can help
<hatch> frankban so what does the bzr switch do? Is it like a merge?
<rogpeppe> hatch: bzr switch is a cobzr extension (unless the native bzr has it now)
<rogpeppe> hatch: it's just like git checkout
<hatch> oh ok - native bzr must have it because I didn't install cobzr
<frankban> hatch: it switches to another branch, so that you can always work on sandbox
<hatch> frankban ok so make has been completed so now I can just deploy this as a normal charm?
<frankban> hatch: now you can follow the instructions on my MP
<frankban> hatch: in particular, make deploy lets you deploy what's on sandbox without having to setup a local juju repo
<hatch> great 
<frankban> hatch: and from now on, you can "bzr branch" GUI charm branches from inside the shared repo, and it will be cheap and fast
<hatch> note to self- DO NOT DELETE FOLDER
<hatch> :)
<frankban> hatch: for instance, if you want to work on a new GUI charm branch, you: 1) cd to sandbox 2) ensure there are no uncommitted changes 3) bzr switch ../trunk 4) bzr pull and 5) bzr switch -b my-feature-branch
<hatch> sounds a lot like how bzr should work by default :)
<frankban> hatch: it supports lightweight checkouts by default actually, no need for cobzr or stuff like that
<frankban> hatch: all my bzr repos are set up like that. lightweight checkouts are not as fast as git named branches, but they are good enough
<frankban> guihelp: any of you do use zsh? I'd like to give it a try
<kadams54_> I do, though I'm not really a power user
<hatch> frankban rick does, I did but it kept borking with my tmux stuff
<hatch> now that I'm back working in Ubuntu full time I will likely give it a go again
<frankban> hatch: hmm, I also use tmux
<frankban> hatch: it seems autocomplete, hostory search and such work much better
<hatch> frankban I think the issue was that there are just so many layers running when you have zsh and tmux that they clashed for me because I kept customizing them
<frankban> kadams54_: ^^^
<frankban> I am taking a look at https://github.com/robbyrussell/oh-my-zsh
<kadams54_> Yeah, that's what I use
<kadams54_> https://github.com/kadams54/dotfiles - feel free to poke around in my zshrc
<frankban> kadams54_: great thanks
<hatch> I find the hardest thing to do is colouring
<hatch> terminal + zsh + tmux = colour hell
<kadams54_> I agree: colouring = hell. Coloring, on the other hand, is as easy as pie.
<kadams54_> ;-)
<jrwren> I don't use zsh, how does it affect colour?
<hatch> lol
<hatch> jrwren because you can set themes in it
<hatch> so you have three things setting colours so when something is wrong it's hard to track down what is setting the colour
<jrwren> What is there to theme other than a prompt?
<hatch> typical linux boy
<hatch> :P
<jrwren> Its true, as I sit at my OSX terminal :)
<hatch> hahaha
<hatch> lemme guess it's iterm2 isn't it?
<jrwren> yes.
<jrwren> You win a prize!
<hatch> man I wish Ubuntu had an iterm2 clone
<kadams54_> frankban: https://github.com/scrogson/dotfiles is a friend of mine who does a lot more with tmux and zsh.
<jrwren> hatch: quake key is built in!
<hatch> jrwren not quite the same :)
<hatch> atm I'm really struggling with the font rendering in Ubuntu, trying to find something to make it prettier 
<hatch> jujugui does anyone know how to hide the comments in a PR on GH?
<rogpeppe> hatch: rebase :-)
<hatch> lol
<kadams54_> OK, driving back home. Be back online in about two hours.
<hatch> frankban "unable to get bundle deployment statuses" notification and the juju-gui charm has no icon
<hatch> are these to be expected on the legacy server?
<frankban> hatch: yes
<hatch> cool
<hatch> +1'd shippppit
<hatch> jcsackett qa issue with your branch 
<hatch> repro instructions in the pr
<frankban> hatch: thanks!
<jcsackett> hatch: huh.
<jcsackett> hatch: well, that's annoying.
<hatch> :) sorry
<jcsackett> i'll figure it out post-lunch.
<jcsackett> all good, better to catch it now than after landing. :p
<frankban> hatch: I am starting the process for a new charm release
<hatch> thanks a lot! 
<hatch> these charm releases are kind of a pita :)
<rick_h__> guten tag
<rick_h__> frankban: zsh <3
<rick_h__> frankban: I'll try to get you some sample stuff sometime.https://github.com/mitechie/zshrc
<rick_h__> frankban: ^ is a lighting talk I gave long ago on some reasons to <3 zsh
<frankban> rick_h__: nice thanks!
<rick_h__> frankban: but when I get back can get my zshrc out if you need anything
<frankban> rick_h__: cool
<hatch> rick_h__ AHOY!
<rick_h__> hatch: howdy!
<rick_h__> train wifi is stinky on this return trip
<hatch> choo choo
<rick_h__> and now the train is stopped...hmmm
<rick_h__> hatch: how goes?
<rick_h__> sent an email to the list, basically a big high-five
<hatch> it's going, saw your mountain picture, still jealous NBD!
<hatch> :)
<rick_h__> MV almost done :P 
<hatch> slowly but surely 
<hatch> doing a lot of reviews and qa's so something must be getting done :)
<rick_h__> damn net keeps dropping
<rick_h__> anyway, reminder I'm afk for a bit. Uros can answer stuff tomorrow but not much to say for now. 
<hatch> yep np, you go enjoy your vacation
 * rogpeppe is done for the day
<rogpeppe> g'night all
 * kadams54 is back
<jcsackett> hatch: i just realized i didin't commit and push my qa-fix. so i've done that, if you want to look at the PR again. :p
<hatch> haha sure ok
<jrwren> https://github.com/CanonicalLtd/charmstore-charm/pull/2
<jrwren> err..
<hatch> jcsackett big fix lol
<jcsackett> hatch: right?
<jcsackett> just huge. :p
<hatch> haha
<hatch> jcsackett so I see you set rendered to false in the charm details....that means that we are using the same instance of charm details all the time?
<hatch> after a class has been 'destroyed' typically you don't revive it again
<jcsackett> hatch: yeah, instead we keep creating new browsercharmdetail views.
<jcsackett> hatch: i believe this is true predating this branch; i think it's something to do with how we're creating viewlets, mixed with how inspector has evolved.
<jcsackett> 1 more for the "we need to clean up slots/viewlets" pile.
<hatch> ohh so the issue is that the pointer to the charmView to check if it should create new or update is still pointing to the destroyed version
<jcsackett> hatch: where? happy to fix that now.
<hatch> jcsackett I added a comment to the line I THINK is the right place
<hatch> basically you are having to set rendered to false when something is destroyed when really we should just be checking if it was destroyed 
<jcsackett> hatch: i find it non-intuitive that a "destroyed" object still exists so i can check it.
<jcsackett> :p
<hatch> jcsackett haha blame javascript
<jcsackett> oh, i do. i do.
<jcsackett> :p
<hatch> in python when you destroy a class instance does it destroy all references to it as well?
<jcsackett> for so *many* things.
<hatch> I guess python has NATIVE classes though
 * jcsackett nods
<hatch> jcsackett we could always switch to Dart :) 
<jcsackett> i don't know enough about Dart to immediately nix that, but i'm going to guess it's not worth the rewrite. :p
<hatch> haha no, no it's not
<hatch> but if we were starting new I would seriously consider it
<hatch> the GUI is now sufficiently complicated I can no longer keep its execution flow in my head
<hatch> *sadface*
<jcsackett> hatch: i hear that.
<hatch> time to go pick up a copy of visio and graph it all :P
<hatch> jcsackett +1'd with trivials, lemme know if the test request makes sense
<jcsackett> hatch: i may have to keep the 'rendered' in destroy hack; doing it with checking 'destroyed' is leading to the pane opening with no content on the second click.
<jcsackett> i think the slot system doesn't clean up after itself right this way--we're forcing it do things it's not really built for.
<hatch> son-of-a
<hatch> ok then, I think my test request still holds
<jcsackett> hatch: do you mean add a test showing that it handles the destructor thing? because this path doesn't involve the destruction cycle.
<jcsackett> this, for example, might be clicking one tab and then another.
<jcsackett> if you mean "update the test to include seeing what destroy does" +1, if you mean something else, i don't follow. :)
<hatch> yeah sorry - I meant test the destructor cycle, because we had to add that into there to make sure it did what it was supposed to do
<jcsackett> hatch: and i can now confirm that showViewlet is reviving the "destroyed" viewlet, so rendered needs to be set to false. i'll add an XXX to explain that the viewlet stuff isn't destroying things properly.
<hatch> excellent thanks
<hatch> ubuntu looks about 1M x better on a non-retina screen :)
<hatch> I wonder who I poke to see about getting that fixed
<hatch> the font rendering that is
<hatch> jujugui do we have any UI for removing units from machines? 
<kadams54> I don't think so
<hatch> kadams54 so the only way atm to remove a unit is via the services inspector?
<kadams54> Yes
<hatch> hmm then the lazy remove unit method is incorrect
<hatch> *sigh*
<hatch> in fact, I don't see how it was ever right hah
<hatch> actually kadams54  looks like you wrote it....do you remember when you wrote the remove unit method in the ECS? 
<kadams54> Sure
<hatch> ok one sec 
<hatch> kadams54 https://github.com/juju/juju-gui/blob/develop/app/utils/environment-change-set.js#L691 so right here you assign args[0] to service then use it as a service.....but args[0] was always an array of units to remove...
<hatch> or am I missing something
<hatch> I'll create a follow-up card to fix this but atm there is no way this could work to remove ghost units....at least I don't see how it could
<hatch> weird it does work
<hatch> lol
<kadams54> I see what you mean, but I'm not sure why it wouldn't work
<kadams54> It seems like it would, just maybe not with the API it should have
<hatch> well because args[0] is an array
<hatch> and you're checking if command.args[0] === args[0] 
<hatch> so it can only ever remove a single unit if a single unit was added
<hatch> it'll work for a real unit, but not for ghosted stuff
<hatch> does that sound right?
<kadams54> No?
<kadams54> Seems to me like it'll work for a single unit but not multiple. Ghosted or not doesn't matter.
<kadams54> Ah, OK, I seeâ¦ that comparison only happens when checking for ghosted.
<hatch> well the real units it would just pass to the changeset and execute the args via the backend
<hatch> yeah
<hatch> :)
<kadams54> But if you only pass a single ghosted, that should still work
<hatch> yeah ok I'll file a bug/card so we don't forget about this and release it
<hatch> heh
<hatch> kadams54 https://bugs.launchpad.net/juju-gui/+bug/1355440
<hatch> does that make sense? :) 
<hatch> card created in project 1 - if it doesn't please update it 
<jcsackett> jujugui: i need another review on https://github.com/juju/juju-gui/pull/487 
<hatch> don't everyone jump at once ;)
<hatch> jcsackett do you know when matt is back?
<hatch> jujugui does anyone else get a drop error when trying to drag and drop in chrome on ubuntu?
<hatch> happens about 50% of the time for me
<hatch> I have to drag and drop fast for it to not it seems
<huwshimi> Morning
<hatch> morning huwshimi 
<huwshimi> hatch: How's things?
<hatch> truckin along, spent a lot of time today doing qa heh
<hatch> I looked at your branch and was getting a failure in a totally different spot than you mentioned
<hatch> so I figured I better wait to see what you said
<huwshimi> oh dear
<huwshimi> hatch: What error did you get?
<hatch> same one that's listed in the CI failure
<huwshimi> hatch: Yeah, that's the same thing, I just pointed to where the tests are actually failing
<hatch> oh....damn
<hatch> huwshimi ok so I can look into this when I get back in a couple hours, have to go run some errands and whatnot
<huwshimi> hatch: sure, no problems. Much appreciated.
<hatch> bbl cya
<jcsackett> hatch: https://bugs.launchpad.net/juju-gui/+bug/1323924
#juju-gui 2014-08-12
<hatch> jcsackett ahh thanks
<hatch> huwshimi so any luck tackling it on your own?
<huwshimi> hatch: I didn't mange to figure out anything yesterday :(
<hatch> ok cool, I'll take a look
<huwshimi> thanks heaps
<hatch> huwshimi what if you include the juju-templates?
<hatch> asically the error is because it can't find the element in the dom
<huwshimi> I'll try
<huwshimi> hatch: No change
<hatch> blarg
<hatch> ok I've pulled it down
<hatch> will investimagate
<huwshimi> hatch: Feel free to leave it to your work day, I have plenty to go on with.
<hatch> huwshimi it's because it's rendering without the mv flag
<hatch> it's rendering the old scaleup UI
<hatch> if you put a debugger in the method that's failing and inspect the innerHTML of the container you can see this
<huwshimi> Oh
<hatch> huwshimi that's because the createServiceInspector method is no longer how we render the inspectors while under mv
<hatch> so this is actually testing a path which is no longer valid
<hatch> so really - the proper fix is to fix the way inspectors are rendered
<hatch> for tests
<hatch> but you may be able to hax around it by setting the mv flag and doing some other bits
<huwshimi> yep, trying
<hatch> huwshimi any luck?
<huwshimi> hatch: Just having some lunch...
<hatch> ok cool, I think I'm gona head and watch some tv, if you can't get it just leave the PR and I'll take a look in the am
<hatch> have a good one
<rogpeppe> urulama: morning!
<urulama> rogpeppe: hey there
<urulama> rogpeppe: how's it going? 
<huwshimi> rogpeppe, urulama: Morning
<rogpeppe> urulama: not bad thanks
<urulama> rogpeppe: i'm trying to finish the "sprint summary" document so that i can move forward with the implementation part, but it's taking tiiiiime :)
<rogpeppe> urulama: have you recovered from last week yet?
<urulama> huwshimi: good evening ;)
<huwshimi> :)
<urulama> rogpeppe: em ... partly recovered. progress bar at around 33% :)
<rogpeppe> urulama: :-)
<urulama> rogpeppe: we have a national holiday on Friday, might help to move to 50% :) and it's good to put things on paper as long as they are still in memory
<rogpeppe> urulama: definitely
<urulama> rogpeppe: i plan to jump on PRs and current implementation around noon (in 2h) ... would that be ok? any open questions or anything until then?
<rogpeppe> urulama: no, all's good
<urulama> rogpeppe: great to hear ... ok, back to tasks for the next 2 months
<urulama> rogpeppe: oh, btw, how far have you and Francesco come regarding uploads?
<rogpeppe> urulama: uploads now work
<urulama> rogpeppe: as in "zip properly formatted dir" and upload and new charm is in charmstore?
<rogpeppe> urulama: and you can now download individual archive files too
<rogpeppe> urulama: yup
<urulama> \o/
<rogpeppe> urulama: ah, the only thing that's not done is that we don't currently verify bundles against the existing charms
<urulama> rogpeppe: as in when bundle is uploaded it is not checked wether the charms are in the CS?
<rogpeppe> urulama: yes
<rogpeppe> urulama: we deliberately left it for a later PR - but it does need doing
<rogpeppe> urulama: and there's also something i thought of in bed this morning
<rogpeppe> urulama: which is that we can't always start revision numbers from zero
<urulama> morning, frankban
<frankban> morning urulama 
<frankban> urulama: are you able to connect to canonical IRC servers?
<urulama> yes
<urulama> frankban: but i've seen others being disconnected
<frankban> urulama: uhm, ok
 * TheMue has troubles too, also with SSO
<frankban> urulama: I see "Connection failed. Error: Connection refused"
<frankban> will try again later
<frankban> switched to zsh, let's see how it works
<urulama> frankban: next step acme? :)
<frankban> urulama: http://www.nooooooooooooooo.com/
<frankban> ;-)
<urulama> :) :) :)
 * urulama bookmarks the page for future use
<urulama> frankban: ok, i have problems with cannonical irc as well, however, it manages to reconnect 
<frankban> urulama: ok
<frankban> urulama, rogpeppe, jrwren: https://github.com/juju/charmstore/pull/69
<urulama> frankban: finishing a doc, then lunch, then PR. ok with you? can move PR first if it is blocking anything else
<frankban> urulama: it's ok thanks
<rogpeppe> frankban: reviewed
<frankban> rogpeppe: thanks
 * urulama goes on short lunch
<urulama> frankban: the tests currently check mostly if the time is there ... could we create a bit more complex test? starting with a charm revision at time 0, then upload new revision, one in the period T of time? Then, check if all revisions have proper n*T archive-upload time?
<frankban> urulama: not sure if I understand. at the store level, we already check that the time is the expected one (in a specified timeframe)
<urulama> frankban: suggestion is to have a "possible" reggression test, that adds a charm (addCharm), multiple times, and check proper revisions and timestamps
<urulama> frankban: on the api level 
<frankban> urulama: so, we publish a charm with the same id two times and we check the id is incremented and t2> t1?
<urulama> frankban: yes, maybe also with "sleep" of time T between publishing
<frankban> urulama: why sleeping?
<rogpeppe> urulama: i don't really see what that test would be adding
<rogpeppe> urulama: given that we're testing that the upload time is within a very short period
<rogpeppe> urulama: (assuming frankban applies my suggested change)
<frankban> rogpeppe: I did
 * frankban lunches
 * rogpeppe also lunches
<bac> ha, this is a nice tool:  http://www.downforeveryoneorjustme.com/lastpass.com
<rogpeppe> bac: should be www.downfordownforeveryoneorjustme.com :-)
<bac> rogpeppe: i don't get it
<rogpeppe> bac: well, really, it would be an infinitely long name
<rogpeppe> bac: the point being that it's only that web site that makes the check
<bac> rogpeppe: true
<rogpeppe> bac: so it could be down for everyone except me and their server
<bac> rogpeppe: regardless of the inaccuracy of their naming, it is a nice check, especially when you have reason to believe it is just you.
<bac> as i often do
<rogpeppe> bac: absolutely. i've found it very useful in the past, although i'd forgotten about it of late
<hatch> wb Makyo 
<frankban> rogpeppe: I am going to change BulkIncludeHandler to receive a request rather than a method and flags
<rogpeppe> frankban: i started off doing that
<rogpeppe> frankban: but it didn't work out
<frankban> rogpeppe: we need access to req.Body e.g. for the extra info stuff
<frankban> rogpeppe: why?
<rogpeppe> frankban: really?
<frankban> rogpeppe: extra-info PUT 
<rogpeppe> frankban: hmm, i guess i thought that stuff would be in the flags, but you're probably right
<frankban> rogpeppe: anyway, I'd feel the framework to be more friendly if it gives the request to you anyway
<rogpeppe> frankban: the reason it didn't work out was because of Router.GetMetadata
<rogpeppe> frankban: and that it seemed wrong to be making up Requests for bulk metadata requests
<hatch> jujugui call in 10
<rogpeppe> frankban: are you planning to do extra-info ?
<rogpeppe> frankban: i was working towards that
<frankban> rogpeppe: I was just taking a look at the framework and realized that. If you want to tackle it I'll live it to you
<frankban> rogpeppe: I'll look at something else, like verifyWithCharms in publish API
<rogpeppe> frankban: i'd be happy to pair on it if you like. i'm wading through mud currently.
<frankban> rogpeppe: sounds good
<rogpeppe> frankban: cool, let's do that.
<rogpeppe> frankban: after the standup?
<frankban> rogpeppe: sure
<rogpeppe> frankban: BTW, if we used a standard "application/x-www-form-urlencoded" MIME type, then the PUT arguments will end up in the flags argument
<rogpeppe> frankban: we don't say much about how the PUT values are encoded in the spec
<urulama> rogpeppe: good point, we dont
<hatch> jujugui anyone else getting "party is over" error?
<rogpeppe> hatch: yup
<hatch> worked now
<hatch> just keep trying I guess
<hatch> heh
<rogpeppe> urulama, frankban: we could standardise on using a single form attribute, say "value" containing the JSON-encoded value to PUT.
<frankban> rogpeppe: It's doable, still not sure if I like it over just sending the json in the body
<jrwren> "It's taking too long to connect you to this video call. Try again in a few minutes."
<urulama> jrwren: daily standup :)
<jrwren> "please wait..>"
<frankban> rogpeppe: gogogo in 5
<rogpeppe> frankban: ok
<rogpeppe> frankban: i'm there, BTW
<hatch> man somethin is munchin on my internets
<jcsackett> hatch: this is the second day, if we're going by your sign on/sign off.
<hatch> yeah it is :/ 
<hatch> good thing I don't pay for QOS
<hatch> oh wait....
<hatch> rogpeppe your card that's in landing....is it still landing or blocked? Maybe it should be moved into tracking?
<rogpeppe> hatch: i'm trying to land it but it's blocked
<rogpeppe> hatch: if tracking is a better place for that, then by all means move it there
<hatch> rogpeppe yeah I think that lane is for actively landing....whereas yours might sit there for a week? :)
<kadams54> hatch: completely befuddled on this test I'm trying to fix. Ping me when you have a few moments.
<hatch> kadams54 you're in luck I just finished a review
<hatch> what's up?
<kadams54> this is the currently breaking code: https://github.com/juju/juju-gui/blob/develop/app/widgets/deployer-bar.js#L257
<kadams54> It loops through a set of keys and checks to see if any of their values have a length.
<hatch> ok
<hatch> is there more to this story?
<hatch> :)
<kadams54> The problem is that my code adds a new key who's property is an int
<kadams54> So I thought I'd just add an Array.isArray check before we look at length
<kadams54> It's false, but hasChange is still getting set to true
<hatch> ok looking
<kadams54> Should I push my changes up so you can see them?
<kadams54> Or would you prefer something like a gist?
<hatch> well I'm just trying to figure out what this is doing
<kadams54> This screenshot pretty much summarizes my confusion: http://cl.ly/image/20132A2e051Z
<kadams54> Both conditions for the if statement eval to false, yet we're inside and hasChange is set to true.
<hatch> that might be an issue with how watches are evaluated
<hatch> what if you run those in the console?
<hatch> and you'll want to use Y.Array.isArray() I'm not sure if Array.isArray() is supported everywhere yet
<hatch> what is this even testing for? What makes it a major change? If any of the objects have something in them then major change is true?
<jcsackett> thanks for the review, Makyo. :)
<kadams54> hatch: we're using an object as a hash here. The original code makes an assumption that all the values in the hash are arrays of changes. If any of the arrays have a non-zero length, then we have major changes and need to display the summary panel in addition to the changelog.
<hatch> ok but that basically means that if there is anything in changes then we need to show it...what tasks aren't shown?
<hatch> what I'm getting at is this method isn't necessary
<hatch> because if you do anything it will return true
<hatch> if any of the changes keys have values it's true
<jcsackett> jujugui: i need 2 reviews on this (very short) PR. https://github.com/juju/juju-gui/pull/491
<kadams54> But not all of the keys in the hash are arrays of changes.
<hatch> jcsackett no test? :)
<jcsackett> hatch: nope--there's no meaningful way to get in and test the d3 logic.
<hatch> kadams54 right - but what I'm saying is that this method is causing you issues.....I don't think this method is necessary because if there is anything in the changes object then it's shown
<jcsackett> i can break out the logic about what to show into a separate method and test that, if you like.
<kadams54> hatch: not necessarily the case.
<hatch> jcsackett well that's just not true :) we test the unit list somewhere
<hatch> kadams54 ok what is the case where it isn't?
<kadams54> hatch: for example, if the user just adds a container, we only show the changelog. We don't show the summary panel.
<jcsackett> hatch: we set up some stuff using the generateAndBind, but we don't inspect those contents.
<kadams54> In that case, all of the arrays in the changes hash would have a 0 length.
<kadams54> i.e., no "major" changes
<jcsackett> hatch: which is reasonable, b/c it's just testing "does d3 set an a tag when i tell it to set an a tag.
<jcsackett> hatch: as i said, if you like i can break that change out into a "chooseDisplayName" method for units, and test *that*.
<hatch> jcsackett I'm pretty sure we have a test which renders the unit list and then checks the dom to make sure there are x number of units rendered 
<hatch> maybe inspector overview or something
<hatch> kadams54 ok and you have added something to changes.addUnits?
<kadams54> Yeahâ¦ totalUnitsâ¦
<jcsackett> hatch: that's where i looked. unless you
<kadams54> Which is an int
<jcsackett> hatch: unless you're talking the scale out tests, which arne't qute the same kettle of fish.
<kadams54> hatch: sorry, I didn't add anything to changes.addUnits. I added it to changes. So changes now has changes.addUnits and changes.totalUnits.
<hatch> kadams54 ok so you could have getChanges return an object where one property is the changes and the other is the total units
<hatch> then you don't have to modify this method
<hatch> which is what I would recommend because your putting stuff in the changes property that doesn't really fit with the rest of the dataset 
<kadams54> OK, will do
<hatch> sounds good?
<hatch> ok cool
<hatch> jcsackett I'm just saying it would be nice if we could test that when we pass an uncommitted model into the d3 stuff it renders the proper name 
<hatch> and the other way 
<hatch> it was what the bug was about afterall
<jcsackett> hatch: i'm not disagreeing, but the test for that will be ridiculous. like i said, i can break out the logic part of it into another method, and test that it returns the right thing; after that it's a matter of believing d3 does the right thing or not.
<hatch> I'll try and find the test
<hatch> you may be able to copy it
<hatch> one sec
<hatch> but I agree if you have to write it all
<hatch> no good :)
<jcsackett> i'm reading through inspector_overview and not seeing anything that looks right.
<hatch> jcsackett test_inspector_overview.js:477
<hatch> the test is massive but  you can likely modify it to use one uncommitted unit model as well as the regular others
<hatch> or add another unit to the list 
<jcsackett> hatch: i'll see--i don't think the return from that is quite right to see what's rendered in the lists, but you might be right.
<jcsackett> oh, i see, it's dumping the whole damn mess.
<jcsackett> ok.
<hatch> so you should be able to just add an uncommitted unit to this and test that that unit is rendered properly and that another one is rendered property too
 * rogpeppe is done for the day
<rogpeppe> g'night all
<jcsackett> hatch: done.
<jcsackett> thanks for helping sort out where to test it; that block is impenetrable when you're scanning without being certain what you're looking for. :p
<hatch> haha yeah it is np
<hatch> ok will qa
<hatch> jcsackett lint error
<hatch> lol
<hatch> we should make a rule - if your tests fail with a lint error you got to buy everyone a coffee :P
<jcsackett> i honestly am not sure of the utility of lint being run on every test--on merge, sure, but it's just noise to me.
<hatch> I always run the full suite before pushing - and now that I'm in Ubuntu the tests don't fail randomly lol
<jcsackett> hatch: i always run the tests; i don't always run check.
<hatch> oh right cuz it's really slow for you isn't it?
<jcsackett> hatch: sufficiently slow.
<jcsackett> slow enough that i end up waiting a while, not long enough to do anything meaningful while it runs.
<hatch> time for an ssd?
<kadams54> hatch: looks like huw needs second reviews on a couple PRs?
<hatch> kadams54 the x uncommitted one I need to write the fix for it to get it to land
<hatch> but the mv scale up one does
<hatch> is yours all good to go?
<hatch> looks good
<hatch> once the tests pass you can land it
<kadams54> Yeah
<kadams54> I was noticing we had a build-up of cards in review
<kadams54> I'll dig into the mv scale up one.
<kadams54> Looks like the scale up one needs to be rebased and have some conflicts resolved
<hatch> telcos should have a flag on peoples accounts which mark their level of expertise
<hatch> so when you call with a problem they don't ask you if you have restarted your router and make you do it again for kicks
<hatch> jcsackett can you rebase your branch and shippit?
<hatch> #491 that is
<jrwren> I actually called Comcast once after I did some basic troubleshooting. I had forgot to reset my cable modem. 
<jrwren> The support person saying "Turn it off and back on again" actually solved my problem.
<hatch> lol
<urulama-afk> jrwren: config-changed error: http://pastebin.ubuntu.com/8029262/
<urulama-afk> jrwren: relations in charms: http://pastebin.ubuntu.com/8029269/
<jrwren> urulama-afk: that doesn't look like an error. :(
<urulama-afk> error: no relation id specified
<urulama-afk> maybe it's enough to trigger the hooks and to leave the charm in "installed" but not "started" state
<jrwren> urulama-afk: I'll try to reproduce. Thanks.
<jrwren> urulama-afk: I'm still new enough to charming that I don't remember all this stuff. I can't recall if that error: is valid or not.
<urulama-afk> jrwren: me and you both :)
<jrwren> jrwren: Still, and invalid error message is a bug, so I'll fix it.
<jrwren> s/and/an/
<urulama-afk> jrwren: yes, i can exit the tmux and then the status is "started"
<jrwren> urulama-afk: can you curl that ip on the listen port?
<urulama-afk> jrwren: it gets stuck on most of the hook scripts, but running them manually and exiting tmux produces service in a "started" state, and curl works
<jrwren> hrm. it gets stuck and you have to resolved --retry?
<urulama-afk> jrwren: i mean, the CS is empty, but there are "error" codes to show that it works
<jrwren> urulama-afk: that is VERY weird.
<jrwren> urulama-afk: Empty and responsive is my goal.
<urulama> jrwren: i haven't tried deploying without debug-hooks, let me add another unit, it might just as well work
<urulama> jrwren: indeed ... seems like debug-hooks interpret your error messages as true errors ... without them, the charm starts and is in "started" mode
<jrwren> urulama: Good, that is what I thought.
<hatch> you guys ok with all this? I've done some charm work, can maybe offer some input
<hatch> jcsackett thanks
<urulama> jrwren: ok, so fixing that is simple, just changing error to "warning" or something, as they are not true errors
<urulama> hatch: thx
<jcsackett> hatch: no worries; hadn't noticed i had all my reviews for it. :)
<jcsackett> thanks for pinging me.
<jrwren> urulama: its charmhelpers.
<urulama> jrwren: khm. then it might not be that innocent after all :) 
<jrwren> hatch: What is the right way to use charmhelpers.core.hookenv.relation_get ?
<hatch> what's this python mumbo jumbo...I just shell out to the real relation get
<hatch> https://github.com/hatched/ghost-charm/blob/master/hooks/db-relation-changed
<hatch> so sorry, I have never used charmhelpers :)
<jrwren> hatch: I'm pretty sure I was told to use this.
<hatch> yeah you likely were
<hatch> sometimes the abstraction is more work though
<hatch> case-and-point :)
<jrwren> hatch: Are you sure it is only sometimes? :)
<hatch> haha
<hatch> jrwren you'll probably have some luck asking in #Juju-dev
<urulama> hatch: do not lead jrwren into temptations! :)
<jrwren> It is likely as simple as if not relation_ids(): before those relation_get calls'
<hatch> urulama haha sorry - I've written charms in node and bash, and fixed the gui one which is in python so never really used charmhelpers and the like
<urulama> hatch: i deploy charms from CLI, that doesn't mean GUI is useless :D
<hatch> urulama definitely not, after about the 1000th time of writing `juju set some-really-big-charm-name some-really-big-config-name="some really long value"` you'll just use quickstart and use the GUI exclusively 
<hatch> lol
<urulama> :D :D
<urulama> ok, time to really EOD ... see you all tomorrow, jujugui (and irc clients go 'ping' all over the globe)
<bac> later urulama
<jrwren> urulama: good night. TY.
<hatch> haha cya urulama 
<rick_h__> jrwren: ask in #juju of marcoceppi or mbruzek around that. Maybe tvansteenburgh as well. They work on and maintain the charmhelpers
<rick_h__> hatch: helps us use/make better our own tools :P
<marcoceppi> o/
<hatch> rick_h__ I'm not sure anything that's 3 levels deep for a simple shell-out call is a valid abstraction :D
<rick_h__> hatch: time to make it better? 
<rick_h__> hatch: shell out with proper catching of return values, logging integration, etc can be worth it
<rick_h__> however I have a lack of context in this matter so I wave my hands around in a general fashion
<hatch> honestly I have no idea what it does under the hood, never used it :) 
<mbruzek> ask me what?
<rick_h__> mbruzek: jrwren is having some issues with relation-get and charmhelpers or the like
<rick_h__> mbruzek: just volunteering you for support of jrwren gets stuck :)
 * mbruzek nods
<hatch> maybe I should write a charm in python to learn about these helpers-of-the-charm
<marcoceppi> hatch: ALL HAIL THE HELPERS OF THE CHARM
<jrwren> hatch: If you are a cranky programmer like me, it might just annoy you that it isn't in bash. ;]
<hatch> jrwren bash MAKES a cranky programmer
<hatch> marcoceppi lol
<hatch> rick_h__ you still around?
 * jrwren uses /dev/tcp in bash instead of curl 
<hatch> lol
<hatch> jcsackett Makyo kadams54 want to weigh in on https://github.com/juju/juju-gui/pull/486#issuecomment-51975411 ? 
<rick_h__> hatch: sure
<rick_h__> hatch: packing up, flight home in the morn
<hatch> rick_h__ want to weigh in on that? ^
<kadams54> hatch: lgtm
<rick_h__> hatch: looking
<rick_h__> hatch: "update a template which doesn't exist" ?
<hatch> rick_h__ the real issue is that it's not the template which doesn't exist, it's that it's using the old inspector rendering code
<hatch> so we have to write a new test mock for generating the inspector to use the NEW mv style inspector rendering code
<hatch> which has to be done anyways but will block this branch 
<rick_h__> hatch: that seems like something we'll need anyway? (a new helper for generating a new inspector)
<rick_h__> hatch: ok, but this comment is about waiting until MV is released, not about a missing test helper?
<rick_h__> nothing here is documenting/adding that we need the helper as the 'right' fix?
<hatch> yeah sorry that wasn't clear
<rick_h__> or am I mis-reading that?
 * rick_h__ loads up kanban
<hatch> so this branch either needs to wait until the new inspector mock test thingy is written or apply the included patch to land it now
<hatch> I gather the new inspector mock thingy will take 1day and then moving all the tests to use it will be....2?
<rick_h__> hatch: ok, I'm cool with the patch with a proper XXX, documenting the place the needs updating, and a follow up card at the top of the lane
<hatch> ok I'll work on the inspector thingy, I added a friday card to chat about it
<hatch> thx
<rick_h__> hatch: coolio, thanks. 
<hatch> safe travels!
<rick_h__> wheeeee
<rick_h__> can't wait to have my own pillows again
<hatch> lol
<hatch> it's the small things, right?
<rick_h__> you know it
<rick_h__> like AC that works
<rick_h__> getting sick of always sweating in EU
<hatch> haha, I never would have thought that would be an issue
<rick_h__> us norhern folks don't like it so hot, my basement office is calling me
<hatch> haha
<hatch> I'm with you on that one!
<hatch> Makyo good choice in cards :)
<rick_h__> well I'm out, have fun all. See you soon. 
<hatch> cya rick_h__  safe travels
<hatch> jujugui lf a review (no qa) https://github.com/juju/juju-gui/pull/492
<huwshimi> Morning
<hatch> morning huwshimi 
<hatch> huwshimi all reviews are done and comments made so you should be able to land both of your branches
<hatch> today
<hatch> and if you could also do a quick review on mine that would be great because mine provides the hooks you will need to mark up the UI with the 'deleted' attributes
<hatch> ^ huwshimi 
<jrwren> huwshimi: Good morning.
<jrwren> My wife and child just reminded me that today is my last day living at the age of 36 years old.
<hatch> WHAAAAA
<hatch> I thought you were like.......26
<hatch> lol
<jrwren> Whaaa???
<hatch> haha yeah
<huwshimi> hatch: Yep no problems, just doing a little qa
<huwshimi> hatch: So to use that flag would we have to update this to use lazyDestroyMachines? https://github.com/juju/juju-gui/blob/develop/app/widgets/machine-view-panel.js#L710
#juju-gui 2014-08-13
<hatch> huwshimi sorry?
<hatch> no the env destroy calls call the ecs 
<huwshimi> ah
<hatch> huwshimi https://github.com/juju/juju-gui/blob/develop/app/store/env/go.js#L1070
<huwshimi> hatch: Oh, I see my confusion is from the uncommitted machines just get removed directly
<hatch> yeah it's almost impossible to keep the execution flow of this app in the head now haha
<hatch> huwshimi hey I'm going to take off, need anything before I do?
<huwshimi> hatch: I don't think so. Thanks for those reviews, all that stuff has landed.
<huwshimi> hatch: I'll hook up your deleted state stuff tomorrow
<hatch> sounds good, I'll do the copy/paste fix in the morning and have it landed for you
<huwshimi> hatch: Have a good night
<hatch> you too, cyas
<rogpeppe> mornin' all
<urulama> rogpeppe: morning
<rogpeppe> urulama: hiya
<urulama> so, push(hash), push(hash), remove(hash) results with a CS without (hash) blob?
<urulama> rogpeppe: i'm a bit lost in what you wrote yesterday. I thought that we used names with blobstore, just that names are hashes. so, what's the difference between "file name" and "file name as a hash"?
<rogpeppe> urulama: the issue is that the refcount is maintained on the hash, not on the name
<rogpeppe> urulama: ManagedResource (the juju/blobstore exposed API) deals only in names
<rogpeppe> urulama: we use the hash for the name, but that doesn't actually help
<urulama> rogpeppe: ok. stay with me here, i've been in document/talk land for too long in last weeks to see the implementation code before my eyes :) 
<urulama> rogpeppe: so. if i push (hash-of-wp) and push(hash-of-wp), don't i get two WP-s with different revision numbers?
<rogpeppe> urulama: WP?
<urulama> or what happens with push(H), push(H), remove(H)?
<urulama> WP = wordpress
<rogpeppe> urulama: by "push" you mean "post" ?
<rogpeppe> urulama: i'm not quite sure what level you're talking about here
<urulama> rogpeppe: sorry, yes, s/push/put
<rogpeppe> urulama: in the underlying blobstore, if you do PutForEnvironment(wp); PutForEnvironment(wp); RemoveForEnvironment(wp), then wp will be removed
<rogpeppe> urulama: those are not the semantics we'd like
<rogpeppe> urulama: and i'd been stupidly assuming that the above sequence would result in a blob in the blobstore with refcount=1
<urulama> rogpeppe: why do we need to ref-count? what's the use case that if I put something in twice, and remove once, that it should stay there?
<rogpeppe> urulama: if two charms or bundles or resources are identical, we want them to share the blob and not duplicate the storage space for that
<urulama> rogpeppe: ah, ok, that explains all of it.
<rogpeppe> urulama: i actually think that ref counting is questionable given our requirements.
<urulama> rogpeppe: why?
<rogpeppe> urulama: my first thought was not to ref count, but just do a simple GC
<rogpeppe> urulama: because even with ref counting, you'll need a GC
<rogpeppe> urulama: and if you don't need to ref count, everything becomes simpler (and quicker)
<urulama> rogpeppe: GC as in ... if there's a blob "hanging" without reference, just remove it, and do this once-in-a-while?
<rogpeppe> urulama: the reason you need a GC even with ref counting, is that there are always going to be windows where you've incremented a ref count, but not added the catalog entry
<rogpeppe> urulama: yup
<rogpeppe> s/windows/time windows/
<urulama> rogpeppe: ok, gc seems fine and simple/controllable solution. however, how does it help with put/put/remove example?
<rogpeppe> urulama: well, Remove is a no-op on the (well, my) blob store. We just remove the catalog entry (outside of the blob store)
<rogpeppe> urulama: ref counting is ok too, really (though, as I've said, you probably want a GC too). ref counting assures timely collection of resources.
<rogpeppe> urulama: but what isn't great is that juju/blobstore doesn't provide us with the capability to refcount hashes directly
<urulama> frankban: morning 
<frankban> urulama: morning
<urulama> frankban: nice PR ... looking
<frankban> urulama: thanks!
<frankban> rogpeppe: could you please take a look at https://github.com/juju/charmstore/pull/70 ?
<rogpeppe> frankban: looking
<frankban> thanks
<urulama> frankban: sent you a summary of a blobstore discussion with rogpeppe this morning in case you are interested. feedback welcome.
<frankban> urulama: interesting thanks
<frankban> rogpeppe: good idea re just using the entity doc. do we want to send url.Revision as entityCharm.Revision()?
<kadams54> hatch: you around?
<hatch> I am
<kadams54> The args that are included in an ECS commandâ¦ ['django', 1]
<kadams54> The first one seems to be the service name, but what's the second? The integer?
<hatch> kadams54 they map to the respective env call
<jcsackett> hatch: bug 1349565--did you spot that on ec2, or local?
<mup> Bug #1349565: visiting a /inspector url in a real env causes the charmbrowser to be blank <juju-gui:Triaged> <https://launchpad.net/bugs/1349565>
<hatch> jcsackett ec2 although I don't think it would matter
<kadams54> hatch: Ah, so in this case (add unit), it would be (service, numUnits, toMachine, callback, options)
<hatch> options is an ecs argument, it gets stripped off before saving into the changeset
<hatch> https://github.com/juju/juju-gui/blob/develop/app/store/env/go.js#L1237
<jcsackett> hatch: i was looking through the code to see about the refactor we talked about yesterday and realized i should probably try to actually reproduce, and it appears resolved on local. i'm trying ec2 now.
<hatch> jujugui call in 7
<hatch> jcsackett interesting....I don't recall anyone doing any work on it, so you could visit the url like /inspector/mysql/charm for example?
<jcsackett> hatch: yeah, going straight to /inspector/juju-gui or /inspector/juju-gui/charm worked fine.
<hatch> mm interesting, when you get the ec2 version up, if it works i'd like to give it a try just to be sure it wasn't one computer vs another or something
<hatch> I don't recall anything landing that would fix the problem
<hatch> jujugui call in 2
<kadams54> "It's taking too long to connect you to this video call. Try again in a few minutes."
<hatch> urulama kadams54 call
<kadams54> hatch: trying ^^^
<kadams54> Attempt #2 also seems to be stalled.
<jcsackett> hatch: boo. ec2 does indeed fail.
<hatch> jcsackett phew*
<hatch> :)
<jcsackett> hatch: phew? why phew.
<jcsackett> that's *bad*.
<jcsackett> :p
<jcsackett> it means i have to go fix it now.
<hatch> lol I suppose, but also good because if it was fixed....by nothing....it might have been a spurious error
<hatch> jcsackett so this might be part of the real fix stuff to just render the inspector and have it wait for data
<jcsackett> hatch: yeah, i think that's the case, but there are, as always, edge cases. :p
<hatch> luca so this added services thing would only be visible when mv is visible?
<luca> hatch: ah no, I should of said in the email...
<hatch> yes....yes you should have :P
<luca> hatch: the added services sidebar is the default sidebar for the canvas
<luca> hatch: you will be able to click a button (not shown in the prototype) that shows the charm browser
<hatch> http://giphy.com/gifs/what-despicable-me-minion-4JseZwbYRmq2Y
<luca> hatch: rofl
<hatch> lol
<hatch> ok lets gloss over that little bit for a second.....
<hatch> what purpose does this serve vs the canvas? I kind of feel like the only thing the canvas does now is show general relations
<hatch> if both are visible at the same time....it's kind of like a duplicate of information 
<hatch> I can reply to this in the email, just figured we could chat about it first :)
<luca> hatch: well, in the first iteration this allows you to a) show/hide a service from view and b) highlight a service and itâs related services AND which services it can connect to.
<hatch> ahh so it's kind of like a filtererer
<luca> hatch: when viewing MV, this will allow you to filter your list of machines. If you donât want to see machines with Apache on it then you can turn that service off and it will hide the machines it is on, if it is the only service on that machine.
<luca> hatch: youâll be able to switch them all off for instance and then switch wordpress on and only see wordpress machines
<luca> hatch: and in future iterations networks will also be listed in the added services bar, this means that user could be able to hide networks and the services inside them all at once.
<hatch> hmm ok as a filter I could see this being a pretty cool feature
<luca> hatch: weâve also spoken about being able to group services and this would act in the same way as networks
<luca> hatch: yeah
<hatch> so now as far as it being the default....
<luca> hatch: it also exposes key information like, how many units a service has and other environment wide services.
<hatch> I'm thinking that maybe the charmbrowser should be the default but it remember which one you have active....I don't want new people to have to 'find' the charmbrowser
<hatch> so this way once the user has switched to this view, then it remembers it and stays here
<hatch> Makyo how goes the review? :)
<Makyo> hatch, I thought jcsackett took it, saw his tag.  I can look now if you want though.
<jcsackett> Makyo: i took my tag off thinking you would take it.
<jcsackett> :p
<jcsackett> review volunteer collision. :Pp
<Makyo> I'm on it, then!\
 * jcsackett laughs
<jcsackett> sorry about that.
<hatch> lol
<Makyo> Done
<hatch> thanks
<kadams54> guihelp: looking for someone with ECS experience to do a pre-impl chat on this "don't autoplace units" work.
<hatch> sure
<hatch> standup?
<kadams54> Sure
<hatch> I'm there
<kadams54> Out for lunch
<jrwren> bac: https://github.com/CanonicalLtd/charmstore-charm/pull/2/files#r16115122
 * bac looks
<bac> jrwren: do you have that charm currently running?
<bac> i mean, do you currently have it deployed somewhere?
<jrwren> bac: No, I just removed it.
<jrwren> bac: would you like me to deploy it somewhere?
<bac> jrwren: next time you have it running do a 'juju get charmstore'.  i think you'll see the descriptions for the items in config.yaml are not rendered very well.  but, i may be wrong.  have you tried that?  is that why you didn't put in line-breaks?
<jrwren> bac: I have tried it, and that is why I didn't put in line breaks.
<jrwren> bac: if I put in line breaks I get very terrible rendering.
<bac> jrwren: ok, cool.
<bac> jrwren: so, like this 'juju get' will dtrt?
<jrwren> bac: I'm tempted to file a bug about it. I feel like the yaml should be able to be more readable
<bac> +1
<jrwren> bac: yes, juju get charmstore inserts line wraps.
<jrwren> bac: I wanted to use yaml | line wrap feature, but if I do that, then it ruins the juju get line wrap inserting
<jrwren> bac: Output of juju get charmstore: http://pastebin.ubuntu.com/8037699/
<bac> nice
<bac> yeah, i wish they would dedent the description before doing their own wrapping
<jrwren> bac: *gasp*. I now think it was my fault. I should have used > instead of |
<jrwren> using | is ugly: http://pastebin.ubuntu.com/8037729/
<jrwren> using > is a little less ugly, but it is not good: http://pastebin.ubuntu.com/8037742/
<jrwren> bac: Do you think I should file a bug?
<bac> jrwren: why the single-quotes?
<bac> yeah, i'd file a bug.  the charm author should not have to go through such hoops to get nice output.
<kadams54> hatch: back from my run when you're ready to chat
<hatch> cool, almost done writing a psudo spec
<jrwren> bac: I don't know from where those single quotes come. They are not written in the yaml.
<jrwren> bac: filing a bug.
<jrwren> bac: I updated that PR with your suggestions. Thank you for them.
<bac> np
<bac> thanks for the branch!
<hatch> kadams54 https://gist.github.com/hatched/101a2b25a2558fd5f6c2
<kadams54> Is there a real need for a public method to return a list of unplaced units in the ECS?
<kadams54> Right now I just do db.filterByMachine(null)
<kadams54> Would there ever be a situation where the list of unplaced units in the ECS would differ from the DB?
<hatch> hmm
<hatch> not if everything is working properly
<hatch> :)
<hatch> good point though
<hatch> kadams54 so this looks like 4 branches too so you can split it up into 4 cards and tackle the smaller problems 
<kadams54> Will do
<rogpeppe> g'night all
<jcsackett> hatch: what do you think of having the db have a loaded attribute that gets set once data syncs the first time?
<hatch> jcsackett the issue is that we can't know when that is
<hatch> it's only 'deltas' 
<hatch> there is nothing saying that 'this' is a special delta
<hatch> I mean - technically the first big delta is that one - but there is no guarantee 
<jcsackett> hatch: sure, but this is a bit better than the inspector waiting on an add signal or something.
 * hatch puts thinking cap on
<hatch> gimme a couple mins to think this one through 
<jcsackett> hatch: b/c that way, the inspector fires up, sees no model, waits on data, but if the charm doesn't exist, data is never coming and we'll need a wait timer.
<jcsackett> hatch: whereas if the db says "units are ready" after the signal, inspector can say "are units ready? yes, okay this just doesn't exist."
<jcsackett> and if units aren't ready, render and set once() for loading the data once it's ready.
<jcsackett> s/units/services or s/units/charms in everything i just said.
<hatch> :)
<hatch> jcsackett ok for the best user experience we need to make it feel fast even if it's not, and not showing the inspector then rendering it when the data comes in will make it feel laggy
<hatch> so....
<hatch> we should render the inspector into a 'waiting for data' state
<hatch> once it's data shows up then populate the proper elements
<jcsackett> hatch: ok, but sometimes data will never come.
<hatch> if the data doesn't show up in some pre-determined time then we will close it and throw a notification
<hatch> at least we are saying "you asked for an inspector, here it is, oh, your data doesn't exist you fool....closing"
<hatch> :)
<jcsackett> hatch: but that requries a wait timer, which is generally sub-par.
<hatch> probably don't call them a fool in the notificaton though
<hatch> :)
<jcsackett> hatch: i'm not sold that doing so is superior to the 'loaded' attribute idea.
<hatch> the loaded attribute is a non-starter because the charm data they are requesting may not come in the initial load
<hatch> you could add a listener on the db waiting for any change events, then parsing them for the data the inspector needs
<hatch> then it's not a poll 
<jcsackett> that doesn't solve the the case of /inspector/this-charm-never-existed
<jcsackett> that way we'll still need a wait timer; and given the fun we've had with those i'm -1 on it.
<hatch> sure, we put a setTImeout on that listener, if it's not called within.....5s? 10s? then we close the inspector and throw a notification
<jcsackett> hatch: realistically in the first delta how often is the data not going to arrive?
<hatch> no idea, but it's a bug that'll be impossible to track down because joe-user will say "visited linked url and it just loaded a blank block"
<hatch> I much prefer the more resiliant approach
<jcsackett> hatch: it won't load a blank block; if you go to /inspector/charm-does-not-exist and the insepctor sees there should be data, we throw up a notification and close the inspector.
<jcsackett> hatch: and i find bugs around timers to be equally frustrating for joe user and us to sort.
<jcsackett> (the throw up inspector is what we do now in the case where after 30s the data still hasn't loaded)
<jcsackett> s/throw up inspector/throw up notification/
<hatch> right, so your approach is identical to mine except mine isn't dependent on the data showing up all at once 
<hatch> if juju-core ever decides to change how that initial delta is sent out we're in trouble
<hatch> we don't treat any deltas as 'special' now
<hatch> so I'd prefer to not start
<jcsackett> i wouldn't say this is treating one as special. it's a relative indication that data has come through.
<hatch> data has come through, but not what data
<jcsackett> and it's not on the delta; it's on db.services:add happening.
<jcsackett> or db.services:charms
<jcsackett> dammit, i cannot type today.
<hatch> haha 
<jcsackett> anyway, i don't want to (and have no idea how to) listen for *a* delta coming through.
<jcsackett> i'm interested in watching for when services gets a service loaded. or charms gets a charm loaded.
<hatch> so you want to create an attribute in db.charms which means 'initial load completed' ?
<jcsackett> and setting "ready" flags on those.
<hatch> I'm just not sure we can rely on the first call to db.charms.add to trigger that it's done it's initial load
<jcsackett> hatch: call?
<hatch> sure standup
<jcsackett> cool
<hatch> quiet in here :)
<jcsackett> hatch: i think this may need to wait until after MV 1.0
<hatch> jcsackett yeah? 
<hatch> too indepth?
<jcsackett> ccccccbljtrvggekgghgkkfkvbcrbhflnvuilfgvhcnko check the model to determine whether we're going 
<jcsackett> dammit.
<jcsackett> so, we need to get rid of the ghost inspector first.
<jcsackett> as in, release that.
<jcsackett> b/c everything we discussed should be, i think, the responsibility of the service inspector.
<jcsackett> but we need to get the service model before we create the inspector now to check if we're doing a regular or a ghost.
<jcsackett> hatch: unless you think it's reasonable for the browser.js dispatch code to partially render the inspector, etc etc etc.
<hatch> ahhh so all of the old code is messing it up
<jcsackett> a bit.
<hatch> well I think that the inspector should handle its own rendering 
<hatch> so that you just pass it data and it does with it what it should
<jcsackett> hatch: yeah.
<hatch> jcsackett what if you put the retries in the inspector to be like 10s? 
<hatch> as a temp fix
<jcsackett> i'll give that a try and throw it at ec2.
<jcsackett> oh, wait, no. it won't work.
<jcsackett> b/c the retry is for the service, and it's not finding the charm that's the issue (once we're inside the inspector code)
<jcsackett> i could update the check to be for model *and* charm, and enter retry if we don't have both.
<jcsackett> that might be the right shim for now, actually.
<jcsackett> and we'll throw in a card that's blocked on MV 1.0 for doing this the right way.
<jcsackett> ...or just leave this one if that doesn't work, i suppose.
<jcsackett> (there is a reasonable chance it will not work :p)
<jcsackett> hatch: you down with more temporary shimming with a card for 1.0 proper fix as we discussed?
<hatch> haha yeah I was just going to suggest doing the temp fix with looping for both things to be ready
<hatch> I'd prefer a temp fix than it brick the app if someone hits the seemingly valid url
<jcsackett> hatch: yeah.
<hatch> cool with doing the temp fix?
<jcsackett> i am.
<jcsackett> disappointed, but cool with it.
<jcsackett> esp since we now have a fully fleshed out idea for the *right* way once MV is released.
<hatch> yeah - I think we have bigger fish to fry to try and get mv 1.0 out
<hatch> right
<jcsackett> yeah, this got huge and hairy with a quickness.
<jcsackett> ok, i'll do the temp. it'll take me awhile to test it, but i think that should largely work.
<hatch> Makyo I think I found a case where your impl doesn't cover, commented in the pr
<Makyo> kk
<hatch> goooood morning huwshimi 
<huwshimi> Morning
<Makyo> hatch, good catch (except we can't delete uncommitted units yet).  I'll poke at it tomorrow.
<hatch> Makyo right, but that will be coming in mv 1.0 though
<Makyo> That's why I'll poke at it tomorrow.
<Makyo> Gotta get James' car from the shop now.
<hatch> what? NO DO IT NOW!!!!
<hatch> :P
<hatch> uh oh, broke car?
<Makyo> A gasket in his turbo busted and leaked oil into it, so he's been burning oil.
<hatch> ouch, expensive fix
<hatch> huwshimi the deleted flag branch has landed, do....your.....worst!
<huwshimi> hatch: A brilliant, thanks for that!
<huwshimi> hatch: How do you mock an object so that you can use .get() for the properties?
<huwshimi> (in this case 'env')
<hatch> ok sec
<huwshimi> hatch: Also has your daylight savings time changed?
<hatch> huwshimi https://gist.github.com/hatched/ee86418459e37e60ca24
<hatch> huwshimi no we don't do DST
<huwshimi> hatch: Oh, I was sure I sure I used to start before your EOD
<hatch> it's 5:12pm here now
<hatch> you usually start at 4:30
<hatch> I just assumed you were starting later
<hatch> :)
<hatch> huwshimi my example there assumes you want to return different values depending on the key passed in
<huwshimi> Maybe I haven't noticed since DST changed in April :)
<hatch> you can skip all that switch bs if that's not the case
<huwshimi> hatch: No that's what I want to do,
<hatch> great
<hatch> heh yeah we don't do DST, in the summer, it's light no matter what, in winter it's dark
<hatch> switching one hour either way would make no difference 
#juju-gui 2014-08-14
<rick_h__> huwshimi: howdy
<rick_h__> jrwren: bac please make sure to use the approp channel for conversations around projects
<huwshimi> rick_h__: Hello!
<rick_h__> huwshimi: how goes? 
<huwshimi> rick_h__: Good thanks. Trip went well?
<rick_h__> yea, little hiccup on the way home, but all ends well
<rick_h__> now just very very tired
<rick_h__> in the TZ I started the day it's now 3:30am :)
<huwshimi> haha, oh dear
<rick_h__> anyway, back in town. Will probably stick my nose where it doesn't belong tomorrow. 
<rick_h__> but will not be on the AU call/etc
<rick_h__> huwshimi: but if you want/need to chat let me know and I'll try to make sure to sync up tomorrow night
<huwshimi> rick_h__: No problems. Everything is good at the moment. Plenty to do.
<rick_h__> huwshimi: cool, did you get a chance to poke at the 'more menu' at all?
<rick_h__> I didn't see anything that looked like it, wanted to check if we've broken ground on that?
<huwshimi> rick_h__: I haven't got that yet. I can tackle that next.
<rick_h__> huwshimi: ok cool 
<huwshimi> rick_h__: Happy for it to be a widget, correct?
<rick_h__> huwshimi: yea, I think so
<rick_h__> huwshimi: we'll leave it for hatch to find a hole in the logic :P
<huwshimi> rick_h__: hehe, no problems.
<hatch> blarg
<huwshimi> hehe
<hatch> I'd vote to remove everything widget :)
<rick_h__> hatch: and when I'm less tired we can chat on the 'why'. Banning X just on principal seems a bit weak and doing a tooltip as a View seems :/
<hatch> yeah get some sleep :)
<rick_h__> :) zzzzz
<hatch> huwshimi http://codepen.io/ziga-miklic/blog/pure-css-tic-tac-toe/
<huwshimi> nice
<urulama> rogpeppe1: morning. fyi: i'm driving the kids to their grandma, they had some stomach issues during the night ... be back in 1h max.
<rogpeppe1> urulama: ok, thanks
<rogpeppe1> urulama: morning too, BTW
<frankban> rogpeppe1: morning, I reviewed your branch
<rogpeppe1> frankban: ta!
<rogpeppe1> frankban: oh twats, it looks like i mixed up two branches
<frankban> rogpeppe1: yeah I had that impression
<rogpeppe1> frankban: this one should be better: https://github.com/juju/charmstore/pull/73
<frankban> rogpeppe1: done
<rogpeppe1> urulama: do you want to have a look before I merge?
<urulama> rogpeppe1: that's the one from yesterday evening?
<rogpeppe1> urulama: yup
<rogpeppe1> urulama: although it's got a different PR number now
<urulama> rogpeppe1: it was fine yesterday :)
<rogpeppe1> urulama: ok, cool. you didn't comment on it yesterday, so i thought you hadn't looked through it.
<rogpeppe1> urulama: (actually, it wasn't fine yesterday, as frankban cannily pointed out - i'd mixed in another branch)
<urulama> rogpeppe1: i didn't review it, just skip through it as a first glance
<rogpeppe1> urulama: np
<rogpeppe1> urulama, frankban: i'd appreciate a review of https://github.com/juju/charmstore/pull/72 please
<rogpeppe1> (it's pretty trivial)
<frankban> rogpeppe1: so also charms and utils are updated to newer versions on that branch, correct?
<rogpeppe1> frankban: yes, because they have also been updated to use gopkg.in/yaml.v1
<frankban> rogpeppe1: cool, LGTM
<rogpeppe1> frankban: thanks
<urulama> rogpeppe1: done
<rogpeppe1> urulama: ta!
<urulama> rogpeppe1: who changed charms.v3 to yaml?
<rogpeppe1> urulama: kat
<rogpeppe1> urulama: ha, which reminds me, we should remove that UNSTABLE DEVELOPMENT VERSION notice
<urulama> rogpeppe1: should we? :)
<rogpeppe1> urulama: https://github.com/juju/charm/pull/39
<rogpeppe1> urulama: yes, we must
<rogpeppe1> urulama: because it's now used by juju-core
<rogpeppe1> urulama, frankban: https://github.com/juju/charm/pull/40
<urulama> rogpeppe1: so if a need to verify bundle on read arises (this is not the case now, we rely on a client, iirc), would that be v4 then?
<rogpeppe1> urulama: i don't think i understand the question
<urulama> rogpeppe1: would such change (adding bundle verification on read) bump the charm version to charm.v4? i guess not, as the api does not change, just asking
<rogpeppe1> urulama: yeah, i don't think that would need a version change
<rogpeppe> urulama: so are you ok with the PR https://github.com/juju/charm/pull/40 ?
<urulama> rogpeppe: i guess we don't have a choice on that, do we :)
<rogpeppe> urulama: i don't think so
<urulama> rogpeppe: but i also do not see any breaking changes in the near future at this moment 
<rogpeppe> urulama: neither me
<rogpeppe> urulama: and even if there were, we would need to make a new version
<urulama> rogpeppe: that you also don't see it makes me a little more at ease saying it's "stable"
<rogpeppe> urulama: good. (i think - i'm having difficulty parsing that sentence :-])
<urulama> rogpeppe: ah, yes, thoughts in slavic directly transformed to english, sorry :)
<rogpeppe> urulama: :-)
<frankban> urulama: FWIW your sentence works in Italian too ;-)
<urulama> frankban: :)
<rogpeppe> i'm still trying to work out what "that you also don't see" means :-)
<urulama> rogpeppe: something like this: the fact, that you also don't see breaking changes to the charm.v3 in the near future, ... 
<urulama> :)
<rogpeppe> urulama: ah, got it, thanks
<urulama> rogpeppe: do we have a doc with possible keys for id/stats/counter/ ?
<rogpeppe> urulama: it's mentioned in the charm API doc AFAIR
<urulama> rogpeppe: indeed, down in the text. tnx
<rogpeppe> urulama: we can easily add to that BTW
<urulama> rogpeppe, frankban: good news, i'm QA-ing the charmstore charm with a related mongodb charm ... and seems like i can put stuff in and retrieve the info
<rogpeppe> urulama: cool
<urulama> rogpeppe: wasn't id/expand-id API already implemented? was it lost? (it's probably just me with false recollections of expandId activity)
<rogpeppe> urulama: no, i don't think so
<urulama> rogpeppe: tnx
 * urulama adds a card
<urulama> rogpeppe: seems like stats are not working
<rogpeppe> urulama: we currently don't update any stats
<rogpeppe> urulama: the machinery is in place, but we don't actually use it yet
<urulama> rogpeppe: understood.
<urulama> rogpeppe: btw, now that stats was moved to v4 api, do we still need _old directory or can it be removed?
<rogpeppe> urulama: i think we should probably remove it
<rogpeppe> urulama: it was when i started removing it that i added stats
<rogpeppe> urulama: but never got around to removing it...
<urulama> rogpeppe: np, it's not important, just aesthetics ...
<urulama> rogpeppe: and i'm glad we can get rid of old code :)
<rogpeppe> urulama: well, there's still some code in there that we might want
<rogpeppe> urulama: but it's easy enough to find it agin
<rogpeppe> again
<rick_h__> morning party people
<urulama> morning there, rick_h__
<urulama> rick_h__: hope the weather up there is better then here on the south
<rick_h__> urulama: the weather here in Michigan is pretty nice
<rick_h__> though we had flooding earlier in the week that shut down a section of the highway I take home
<urulama> rick_h__: oooh, home already. 
<rick_h__> so after the flight had to detour for a long while :/
<rick_h__> yea, today is recovery day 
<urulama> rick_h__: hehe, enjoy
<rick_h__> but I will be in/out (loading pictures wheee) if anyone needs anything
<urulama> rick_h__: some good news, QA[pchamrstore charm accepts 
<urulama> ah
<urulama> rogpeppe: did we miss the /meta/any int he api?
<urulama> rogpeppe: or did just i miss the handler call for it?
<rogpeppe> urulama: i think it's implemented, isn't it?
<rogpeppe> urulama: it's implemented by the router
<jrwren> bac: It turns out that juju get formatting bug was a duplicate which I couldn't find: https://bugs.launchpad.net/juju-core/+bug/1292116
<mup> Bug #1292116: juju get output is ugly (broken line wrapping and escape characters) <canonical-is> <config> <papercut> <juju-core:Triaged> <https://launchpad.net/bugs/1292116>
<kadams54> guihelp: how do I make a stub (created via makeStubMethod) return a certain value?
<hatch> pass it in 
<frankban> kadams54: IIRC you just pass the value as the third argument
<hatch> var stub = utils.makeStubFunction('returnVal')
<hatch> or
<hatch> var stub = utils.makeStubMethod(obj, method, returnVal)
 * frankban bbiab
<hatch> the return val param is actually n...
<hatch> so if you specify 3 additional arguments then each time it's called it'll pass the next one
<kadams54> Thanks
<hatch> kadams54 I recommend checking out the source for those methods, it's pretty cool how it works
<kadams54> hatch: I've looked at them before, I was just feeling lazy this morning :-)
<hatch> I wrote a 'continue with "this" when "that" is done' addition to it but never landed it because we found a workaround to the problem
<hatch> jujugui call in 10 kanban now
<hatch> jujugui call in 2
<bac> hatch: mojo stuff is proceeding.  good talk with liam today, confirmed what i suspected: the spec as written will not work locally.  it expects you are operating in an openstack environment -- which is where IS developed it.  will talk to michael nelson when he is available tonight.
<hatch> bac thanks
<bac> hatch: couldn't get hangouts to recognize my headset or headphones... grrr
<hatch> blarg
<hatch> i've had that happen before
<hatch> usually a browser restart is all that's necessary
<Makyo> jujugui sorry I missed the call, lost track of time walking the dogs.
<kadams54> hatch: Soâ¦ buildHierarchy now filters out unplaced units, but that causes a problem on down the road. Once the service is deployed (but not the unit), its ID changes, which breaks the relationship between the two.
<kadams54> That causes an error to be thrown later, once the unit is placed.
<hatch> right, you'll have to use `prepare` handler
<kadams54> hatch: Potential solution would be to setup an event handler in the service model on ID changes that also updates related IDs in the units collection.
<hatch> see lazyAddMachines 
<hatch> kadams54 before it had the 'onParentResults' handler called which would update the appropriate fields
<hatch> now we need to add the 'prepare' handler in the event that that handler isn't called
<hatch> kadams54 the prepare handler is called before the command is run to make any changes to the record
<kadams54> hatch: yeah, I see that, just trying to figure out where this would fit inâ¦
<hatch> what do you mean? 
<hatch> oh there might be an issue here....
<kadams54> If I understand correctly, you want a prepare handler on the deploy service commands, which would update the unit model to the new service ID?
<hatch> no on the add unit commands
<hatch> which actually won't work 
<hatch> becuase I don't think we will know that the ghost service id matches the service id
<kadams54> Yeah
<kadams54> We need it before then
<kadams54> When doing operations with the undeployed unit
<kadams54> For example: looking up the service icon for an unplaced unit
<hatch> can you gist the data that is in the service db for the deployed service and the add unit command? 
<hatch> there may be something we can key off of
<hatch> if not I'll have to take another look into the execution order of this after I finish these reviews
<kadams54> hatch: https://gist.github.com/kadams54/74a0c7c0a7e2c0b18b8b
<kadams54> hatch: looks like we could match on unplacedUnit.charmUrl == service.charm
<hatch> yeah that won't work though - you can deploy the same charm twice under two different services
<hatch> crud
<kadams54> But that would mean changing a lot of places (like icon logic) that currently use unplacedUnit.service
<hatch> kadams54 ok looking
<hatch> hmmmmmmmmm
<hatch> kadams54 can I see what you have so far?
<kadams54> Sure
<kadams54> https://github.com/juju/juju-gui/pull/496
<rogpeppe> jrwren: what series is the charmstore charm designed to run on?
<jrwren> rogpeppe: trusy only. rick_h__ said it was OK to not support precise.
<hatch> thx looking
<hatch> kadams54 this was not designed for this....
<hatch> lol
<kadams54> :-)
<kadams54> What would be the harm in having an event handler update the unit's service field when a service ID changes?
<kadams54> hatch: ^
<hatch> scalability 
<hatch> and we actually destroy/re-create the models
<hatch> so that won't work :)
<hatch> so kadams54  what needs to be done is the _updateChangesetFromResults call needs to be done changeset wide
<kadams54> Not just at specific levels?
<hatch> well think about this on the big picture
<hatch> no wait
<hatch> WAIIIIT
<hatch> it's coming to me
<hatch> oh yeah this is good
<hatch> :)
<hatch> actually this was an idea already on the place
<hatch> plate
<kadams54> hatch: I have a bad feeling about thisâ¦
<kadams54> ;-)
<hatch> lol
<hatch> the units need access to the service model itself
<hatch> not just the id
<hatch> problem is that we destroy the model
<hatch> and create a new one with a new id
<hatch> this is actually the problem with one of our other bugs/cards
<hatch> kadams54 that's going to be quite the undertaking
<hatch> so I have an idea which you may be able to investigate
<hatch> you generate a list of unplaced units and their id's
<jcsackett> huh...CI lint caught an error that local lint did not...
<hatch> oh wait that's not gona work.....
 * hatch grabs the white erase marker and starts over
<kadams54> lol
<hatch> jcsackett don't like ;) 
<jcsackett> hatch: i was so excited--i remembered to run it this time, and still no love. :p
<hatch> lol!
<jcsackett> jujugui: can i get two reviews on https://github.com/juju/juju-gui/pull/497 ?
<jcsackett> Makyo: do you need a second on your PR, or are you still addressing hatch's notes?
<kadams54> jcsackett: I'll take a look.
<Makyo> jcsackett, still addressing notes, though feel free to take a look
<hatch> kadams54 none of my ideas work thanks to Makyo 
<hatch> blame him
<hatch> :P
<jcsackett> Makyo: cool, i'll look now.
<hatch> kadams54 quick call?
<kadams54> hatch: sure, standup?
<hatch> yup
<kadams54> And now I think I'm going to go for a run.
<kadams54> ;-)
<hatch> :D
<hatch> thanks for the chat
<hatch> I should start running
<hatch> kadams54 do you use any apps or anything
<kadams54> Nike for run tracking/logging and couch-to-5K for interval training.
<kadams54> Or couch-to-10K, depending on whether I have a 10K race coming up.
<hatch> jeebz
<hatch> I doubt I could do 1k
<hatch> :D
<hatch> I wonder if there is a couch-to-fridge app
<hatch> :D
<hatch> jcsackett your branch.....does it work?
<hatch> :)
<rick_h__> lol
<hatch> love the simplicity 
<rick_h__> good question
<hatch> wb rick_h__ 
<rick_h__> sleep is good
<hatch> haha it is!
<hatch> I'm spinning up an instance for qa atm
<hatch> has anyone ever seen this failure when trying to change the juju-gui-source? 
<hatch> 2014-08-14 17:13:44 INFO juju-log fatal: git fetch-pack: expected shallow list
<jcsackett> hatch: it does.
<jcsackett> hatch: i don't like it, but it works.
<hatch> jcsackett I can't qa it....for some reason I can't change the repo....
<hatch> it doesn't like your branch or something...
<rick_h__> hatch: precise or trusty?
<hatch> precise
<rick_h__> hatch: the git checkout source stuff only works on trusty due to git changes from precise to trusty
<hatch> ohhh
<hatch> well NOW you tell me :)
<rick_h__> been that way since the trusty charm :P
<hatch> for reals? 
<rick_h__> yep
<hatch> interesting
<rick_h__> the git stuff broke and I had to fix it for trusty, but then it broke precise since we were trying to do lightweight checkouts for speed/etc
<hatch> ahh gotcha
 * rogpeppe is done for the day
<rogpeppe> g'night all
<hatch> night rogpeppe 
<jcsackett> hatch, rick_h__: you can get around it on trusty by using a sha instead of a branch name.
<jcsackett> er, on precise.
<hatch> ahh
<rick_h__> jcsackett: ah cool
<jcsackett> rick_h__: you're not actually here, right?
<jcsackett> rick_h__: as in, we're not supposed to be doing a call?
<rick_h__> jcsackett: right, I'm doing bills atm and watching pics upload :)
<rick_h__> recovering
<jcsackett> cool.
<rick_h__> jcsackett: unless you want to chat then I can do that too :)
<hatch> I definitely want to see these pics rick_h__  :) be sure to share 
<jcsackett> rick_h__: naw, i'm good. just making sure i wasn't leaving you hanging. :)
<hatch> kadams54 hey things going well with that update?
<kadams54> hatch: trying to figure out why this method was setup like thisâ¦
<hatch> well originally we only ever had to do things top-down
<kadams54> Why only walk the hierarchy? Why not just walk through the entire changeset?
<kadams54> Trying to make sure I understand what the ramifications of changing that approach will be
<hatch> the hierarchy WAS a formatted changeset up until today
<hatch> :)
<hatch> lunching
<kadams54> hatch: let me know when you're back. I think I fully understand what needs to happen here :-)
<hatch> kadams54 still here, wassup
<hatch> call? 
<kadams54> hatch: one moment. Working up a gist.
<kadams54> hatch: go get lunch :-)
<kadams54> hatch: I figured I'd have at least a few minutes to get a psuedo spec worked up :-)
<hatch> haha ok
<hatch> bbl
<kadams54> hatch: ping me once you've refueled and we'll hop on a call. Gist is here: https://gist.github.com/kadams54/d04ca02e2ccf4005a03a
<hatch> kadams54 gist looks good
<kadams54> Great
<kadams54> Working on the tests right now
<kadams54> hatch: FYI, pushed the new updateChangesetFromResults out to the PR. Going to add an onParentResult to unit records now.
<huwshimi> Morning
<hatch> morning huwshimi 
<hatch> huwshimi https://github.com/juju/juju-gui/pull/486/files#diff-f05fb78d550f50174f5355a05130fa02R183 I'm now working on making this test work with the new inspector rendering but the uncommitted element is empty
<hatch> any idea what I need to add to the unit list to make an uncommitted unit?
<huwshimi> hmmm...
<hatch> tbh I'm not sure how it worked before haha
<hatch> probably because it just glazed over it
<huwshimi> hatch: The unit you've added there should be uncommitted. It has no agent_state
<hatch> ok I'll step through
<huwshimi> hatch: https://github.com/juju/juju-gui/blob/develop/app/views/viewlets/service-overview.js#L895
<hatch> hmm I only have the three with agent_states
<hatch> odd
<hatch> huwshimi doh I fixed it
<huwshimi> hatch: Oh, what was it?
<hatch> I was adding the unit after it was rendered
<hatch> so the databinding probably didn't kick in before it did it's assertion
<huwshimi> OH
<hatch> I have 1/3 of the inspector overview tests passing
<hatch> this conversion is gona be h e double hockeysticks
<huwshimi> :)
#juju-gui 2014-08-15
<rogpeppe> mornin' all
<rogpeppe> huwshimi: do you, by any chance, know the name/address of the calendar that we should add leave to?
<dimitern> rogpeppe, morning
<rogpeppe> dimitern: hiya
<rogpeppe> dimitern: how's tricks?
<dimitern> rogpeppe, I wanted to ask you for a while.. 
<dimitern> rogpeppe, why do you usually send a mail twice to the same lists - once normally and once forwarding it to the same list? :)
<rogpeppe> dimitern: because i very often forget to send it from my canonical address
<dimitern> rogpeppe, ah :)
<rogpeppe> dimitern: and i believe that it bounces when i send from my normal gmail address
<rogpeppe> dimitern: so i *think* you'll see two messages only when you're directly CC'd
<dimitern> rogpeppe, so godeps now does both fetching/pulling new revisions and go getting missing packages?
<rogpeppe> dimitern: if you're seeing two messages otherwise, then perhaps i don't need to resend the messages after all...
<rogpeppe> dimitern: yeah
<dimitern> rogpeppe, nope, I always see 2 msgs
<rogpeppe> dimitern: hmm, maybe that means that rogpeppe@gmail.com is actually subscribed to both
<dimitern> rogpeppe, good, I'll give it a try to see if it solves my previous issues
<dimitern> rogpeppe, most likely :)
<huwshimi> rogpeppe: Hey, I'm not aware that there is one.
<rogpeppe> dimitern: it doesn't always work, unfortunately, and i'm not quite sure why. there's something weird going on.
<dimitern> rogpeppe, sorry about bashing godeps a bit in the msg I sent btw (^^)
<rogpeppe> dimitern: hrmph :-)
<rogpeppe> dimitern: it's open source and i develop it in my spare time - you're free to contribute too :-)
<dimitern> rogpeppe, with git, you're using fetch rather than pull, right?
 * rogpeppe checks
<dimitern> rogpeppe, yep, I was thinking about it
<rogpeppe> dimitern: it's not that big either - only 718 lines
<dimitern> rogpeppe, I'll have a look at the source
<rogpeppe> dimitern: i'm using pull. yeah, i should definitely use fetch there, i think.
<dimitern> rogpeppe, yeah, it's safer - no changes to work dir
<rogpeppe> dimitern: yeah, but... which remote to fetch?
<rogpeppe> dimitern: i guess i could always fetch origin
<rogpeppe> dimitern: ha, "origin" is the default anyway
<dimitern> rogpeppe, with a properly set up local repo (i.e. as a result of go get or git clone), the remote is already implicitly defined, so just git fetch should work
<dimitern> rogpeppe, that's what I'm using in my up-dep script for git repos
<rogpeppe> dimitern: i'm not sure.
<rogpeppe>        When no remote is specified, by default the origin remote will be used,
<rogpeppe>        unless thereâs an upstream branch configured for the current branch.
<rogpeppe> so it's possible that someone might have configured an upstream branch
<rogpeppe> i think just "git fetch origin" is probably the way forward
<dimitern> rogpeppe, this can only happen if you're doing development on that dependency
<rogpeppe> dimitern: yeah, but that might happen, i guess
<dimitern> rogpeppe, i.e. have both origin and upstream remotes, like we have for juju/juju
<rogpeppe> dimitern: yeah
<dimitern> rogpeppe, and in that case it is still safer to fetch origin, as it should be configured on github to track upstream anyway
<rogpeppe> dimitern: i actually never have an "upstream" remote - i think it's confusing
<rogpeppe> dimitern: i just have "origin" and remotes named after the person
<rogpeppe> dimitern: yeah, i think "origin" is probably the right thing to do, as we really want to fetch updates from the shared origin.
<dimitern> rogpeppe, having upstream remote locally configured can help you looking for changes/logs/diffs between local branches/origin and upstream
<rogpeppe> dimitern: does it make a difference that it's called "upstream" instead of "rogpeppe" ?
<dimitern> rogpeppe, also, because I kinda don't trust github magically keeping my origin for up-to-date, I usually fetch upstream/master, push to origin/master, and pull origin/master into my local master
<rogpeppe> dimitern: (i can never remember which way the "stream" flows, so "upstream" isn't a useful name for me)
<dimitern> rogpeppe, no special meaning about the name
<rogpeppe> dimitern: but upstream is configured to your own github fork, right?
<dimitern> rogpeppe, :) it's even harder for me, as it different in bulgarian; but what I remembered is upstream=close to the original source :)
<dimitern> rogpeppe, nope, upstream is the main juju/juju repo, origin is dimitern/juju (i.e. my github fork of the main repo)
<rogpeppe> dimitern: oh, that's really weird then :-)
<rogpeppe> dimitern: and that means that my proposed godeps fix would fail in your situation
<rogpeppe> :-\
<dimitern> rogpeppe, how so?
<rogpeppe> dimitern: because it means that "git fetch origin" won't fetch any new updates that have been pushed by other people.
<rogpeppe> dimitern: for me, origin is always the main repo that everyone forks from
<rogpeppe> dimitern: that's automatically set up when i "go get" something
<rogpeppe> dimitern: then i add a named remote for any fork
<rogpeppe> dimitern: darn, i'm not sure that i can make automatic godeps fetching work in general then
<rogpeppe> dimitern: assuming yours is a common pattern
<rogpeppe> dimitern: i suppose i could fetch all
<rogpeppe> dimitern: so do you usually configure your upstream as the default upstream remote for your branches?
<rogpeppe> dimitern: if so (and assuming that's the common pattern), then perhaps i should just do "git fetch" (no args). i think that's probably better.
<dimitern> rogpeppe, nope
<rogpeppe> dimitern: oh
<dimitern> rogpeppe, usually origin is the remote you cloned from
<rogpeppe> dimitern: but do you usually clone from your fork, or from the original branch?
<dimitern> rogpeppe, and in our workflow origin is you fork of the main repo in github, which is supposed to automatically track upstream
<dimitern> rogpeppe, always from my fork, precisely for the reason origin tracks upstream
<rogpeppe> dimitern: by "track" you mean that it automatically gets updates from its upstream branch?
<dimitern> rogpeppe, yes, master is tracked by default, and you can add other tracking branches
<rogpeppe> dimitern: (i.e. github does some magic behind the scenes to do that?)
<rogpeppe> dimitern: i didn't know about tracking branches.
 * rogpeppe googles it
<dimitern> rogpeppe, that's the magic really - the fork is a local repo on github servers that has a master branch tracking upstream/master
<rogpeppe> dimitern: so if you "git fetch" your fork repo, you should always get any changes that have been made upstream too?
<dimitern> rogpeppe, that's how it's supposed to work - i.e. you're not expected to pull upstream/master into origin/master locally and then push to origin/master, but I do that, just in case :)
<rogpeppe> dimitern: but... origin/master surely can't be the name of the remote tracking branch?
<rogpeppe> dimitern: because that's where you've got your own changes
 * rogpeppe experiments
<dimitern> rogpeppe, well it is "remote" wrt your local repo, and it is also "remote" wrt upstream, in a different way :)
 * rogpeppe is still confused :-)
<rogpeppe> ... and i thought i had this git thing sussed :-)
<dimitern> rogpeppe, locally, you have origin/master (I have upstream/master as well), both of these (locally speaking) are tracking branches for the origin and upstream repos
<dimitern> rogpeppe, on github, where your fork lives, locally (there) origin/master is a remote tracking branch for the upstream repo (juju/juju)
<rogpeppe> dimitern: so how would I refer to that remote remote?
<dimitern> (i.e. origin/master@github tracks juju/juju/ master @github)
<dimitern> rogpeppe, you don't need to
<dimitern> rogpeppe, you need to track the place you cloned from (your fork), and your fork needs to track upstream, so 2 levels of indirection
<rogpeppe> dimitern: so where's the HEAD reference to juju/juju master in my local repo?
<dimitern> rogpeppe, unless you have an upstream remote to juju/juju, you don't have direct reference to the upstream/master HEAD
<dimitern> rogpeppe, that's what I have: http://paste.ubuntu.com/8051647/
<rogpeppe> dimitern: but you're saying that doing a "git fetch" of origin (my fork) will automatically fetch any commits that have been made upstream?
<rogpeppe> dimitern: that's what i expected to see
<dimitern> rogpeppe, yes, because origin tracks upstream
<rogpeppe> dimitern: this is what mine looks like http://paste.ubuntu.com/8051665/ :-)
<dimitern> rogpeppe, but I find this a little magical, so instead, I do: git checkout master (locally), git pull --ff-only upstream master (into my local master), git push origin master
<rogpeppe> dimitern: i just can't quite work out where the references are kept locally. i.e. how are those double-remote tracking branches represented in my local repo?
<dimitern> rogpeppe, hah :) interesting, but it's just different naming - your origin is actually my upstream, and your rogpeppe is like my origin
<rogpeppe> dimitern: yeah
<rogpeppe> dimitern: but that scales better
<rogpeppe> dimitern: because i actually own quite a few github accounts
<rogpeppe> dimitern: and it means that any repo that i've done "go get" with is already half set up for development
<rogpeppe> dimitern: (i just need to fork it on github and add the "rogpeppe" remote)
<dimitern> rogpeppe, I don't think it will scale as well if you need to have multiple origin remotes (say juju/juju and juju/names/ - you need to work on both at some point)
<rogpeppe> dimitern: both of those will be in separate directories
<dimitern> rogpeppe, no, sorry - yeah :)
<rogpeppe> "there can only be one origin" :-)
<dimitern> respect the origin for it shall prevail :)
<rogpeppe> dimitern: hmm, i can't reproduce the behaviour you're expecting
<dimitern> rogpeppe, which one?
<rogpeppe> dimitern: it looks like doing a fetch of a github fork does not fetch commits made in the original master
<rogpeppe> dimitern: so i did this experiment:
<rogpeppe> dimitern: i forked a github repo (github.com/go-errgo/errgo) into my own git account (github.com/rogpeppe/errgo)
<rogpeppe> dimitern: i cloned github.com/rogpeppe/errgo into a new directory
<rogpeppe> dimitern: oops, no, scratch that!
<rogpeppe> dimitern: i cloned github.com/go-errgo/errgo into a new directory
<dimitern> rogpeppe, why the fork then?
<rogpeppe> dimitern: i had another clone
<dimitern> rogpeppe, you're supposed to clone the fork, not upstream for the tracking to work I think
<rogpeppe> dimitern: with two remotes
<rogpeppe> dimitern: github.com/go-errgo/errgo and github.com/rogpeppe/errgo
<rogpeppe> dimitern: which i named origin and rogpeppe, according to my usual convention
<dimitern> rogpeppe, ok
<rogpeppe> dimitern: then, in the first cloned directory, i made a change, and pushed that (to github.com/go-errgo/errgo)
<rogpeppe> dimitern: then in the directory with two remotes, i did "git fetch rogpeppe"
<rogpeppe> dimitern: now that, if i understood you correctly, *should* have fetched the commit that was made in master
<rogpeppe> dimitern: but it didn't
<dimitern> rogpeppe, it depends what is the rogpeppe remote tracking
<dimitern> rogpeppe, do git branch -r in the double-remote dir
<rogpeppe> dimitern: the rogpeppe remote was tracking the fork (github.com/rogpeppe/errgo)
<dimitern> rogpeppe, this will show you all remote tracking branches
<rogpeppe> % git branch -r
<rogpeppe>   origin/master
<rogpeppe>   origin/v1
<rogpeppe>   rogpeppe/master
<rogpeppe>   rogpeppe/v1
<dimitern> rogpeppe, ok, once upstream changed, if you go to rogpeppe/errgo does it show the commit (on github)
<rogpeppe> dimitern: yeah, it says "This branch is 1 commit behind go-errgo:v1
<rogpeppe> "
<dimitern> rogpeppe, hmmm.. so maybe I don't get what "tracking" means :)
<dimitern> rogpeppe, it doesn't pull revisions, just tells you if you need to
<rogpeppe> dimitern: i think "tracking" just means that it refers to a remote repo; if you fetch it (explicitly), it'll get all branches from that (and by implication all the commits the HEADs of those branches refer to)
<dimitern> rogpeppe, so what I'm doing with my "git sync" script - pulling upstream/master and pushing to origin/master is the right thing to do
 * rogpeppe goes back to look at the sync script
<dimitern> rogpeppe, heh :) what do you know - quite an interesting morning discussion, thank you
<rogpeppe> dimitern: indeed - git is a complex beast, and noone quite understands it :-)
<rogpeppe> dimitern: your sync script looks reasonable. but i'm not sure why you bother pushing to origin/master.
<rogpeppe> dimitern: in general, i just use named branches in my github fork, and just use the original (my "origin", your "upstream") tracking branch as a source
<dimitern> rogpeppe, I push to origin to make sure it's up-to-date (on github) with all upstream commits; that way I can always use either the github UI or git commands locally on origin for diffs etc.
<rogpeppe> dimitern: i don't quite get that. what's an example command that you might run that needs origin/master pushed?
<rogpeppe> dimitern: (i often don't have an rogpeppe/master branch at all, BTW)
<dimitern> rogpeppe, like git difftool origin/master (or something)
 * rogpeppe looks up git difftool
<rogpeppe> dimitern: presumably you could always do "git difftool upstream/master" instead?
<rogpeppe> dimitern: which i'm guessing more directly represents what you actually want to do
<dimitern> rogpeppe, good point, yes
<rogpeppe> dimitern: so, i've just changed godeps to use "git fetch" rather than "git pull"
<dimitern> rogpeppe, cheers!
<rick_h__> morning all
<rick_h__> rogpeppe: I added the leave for you. It's the juju ui engineering calendar
<rogpeppe> rick_h__: thanks a lot
<rick_h__> np, went through and approved that stuff last night so should be good
<rogpeppe> rick_h__: have you got a reference for that calendar? (i think calendars have email addresses, right?)
<rick_h__> rogpeppe: looking
<rick_h__> rogpeppe: just shared it out to you
<rogpeppe> rick_h__: i think i'm seeing the standup entries because i'm subscribed to frankban's calendar :-)
<rogpeppe> rick_h__: thanks
<rick_h__> oh hmm, standup is different. You should see those. I thought I invited you to those
<rick_h__> yea, standup should be on your own. You're an invited person
<rick_h__> jujugui wife has a migraine this morning. I've got to take the boy into day care for her and then get her up to the urgent care. Will be a bit afk this morning. Email if you need anything
 * rogpeppe tries to work out how to find a reference to the calendar so i can add it to mine
<rogpeppe> hmm, reloaded and it seems to have added it
<rogpeppe> calendars are a kinda black magic
<rogpeppe> dammit, my headphones just broke
<rogpeppe> ... and i thought they were so well built
<rogpeppe> ha, i wondered why the charmstore charm wasn't responding as i expected
<rogpeppe> it uses the old charm store by default!
 * rogpeppe lunches
<jrwren> rogpeppe: I think I should change the default to v4.
 * rick_h__ is back around
<jrwren> rick_h__: welcome back.
<rick_h__> jrwren: thanks
<rogpeppe> jrwren: sorry, i didn't see the git change in PR#2 (though to be fair it wasn't mentioned in the description)
<kadams54> jujugui: Morning all. Has anyone done anything with CI this morning? I had a build late last night that froze up on one of the tests. Ended up killing it after 1.5 hours, but it seems like a process is still out there hanging onto a port. Subsequent builds are failing with "port in use" errors.
<rick_h__> kadams54: it knew I was back and wanted to blow up on me 
<rick_h__> kadams54: sec, looknig
<kadams54> rick_h__: welcome back :-)
<rick_h__> wheeee
<rick_h__> kadams54: process killed
<kadams54> THanks
<rick_h__> morning hatch__ 
<hatch__> mornin rick_h__ 
<rick_h__> hatch__: pics finally made it up overnight https://www.flickr.com/photos/7508761@N03/
<rick_h__> killed poor flickr's api lol
<hatch__> haha nice!
<rick_h__> had to restart it 4 times yesterday
<hatch__> lol!
<hatch__> why flicker and not, say G+?
<rick_h__> G+ pissed me off when they did the picasa to G+ photos crap
<rick_h__> they botched that hard core and so moved all my stuff to flickr
<rick_h__> plus there's no G+ import from other apps/programs
<hatch__> ahhh
<rick_h__> I tend to find the highlights and upload them to G+ for easier/thinned out sharing
<rick_h__> but takes more time
<jrwren> rick_h__: ah, you did bring the wife. Where is the boy?
<rick_h__> jrwren: he stayed at home! 
<jrwren> rick_h__: excellent choice! :)
<rick_h__> he's going on his first plane ride next week though. 
<rick_h__> will be fun to see how that goes
<hatch__> I've found kids are either pro's or absolutely horrible
<hatch__> when it comes to flying
<hatch__> (from my friends with kids)
<rick_h__> lol
<hatch__> they don't usually understand that they are going 600MPH 35,000 ft up
<hatch__> lol
<rick_h__> jrwren: do you have a card in progress?
<rick_h__> jrwren: or the one charm one in review?
<jrwren> rick_h__: not really. yes, that in review.
<rick_h__> jrwren: cool, have a hacky friday project if you're interested
<rick_h__> jrwren: meet back in standup?
<jrwren> rick_h__: I'm sold. What do you have?
<jrwren> rick_h__: ok
<rick_h__> https://plus.google.com/hangouts/_/calendar/cmljay5oYXJkaW5nQGNhbm9uaWNhbC5jb20.t3m5giuddiv9epub48d9skdaso?authuser=1
<rick_h__> bah, wrong one
<rick_h__> https://docs.google.com/a/canonical.com/spreadsheets/d/1szaU3S4r72DRzDr9TAsMS57FJ8AUaN84q1ov2rNLxZ8/edit#gid=0
<hatch> kadams54:  when you qa'd https://github.com/juju/juju-gui/pull/494 the issues I mentioned were still there?
<rick_h__> https://juju.ubuntu.com/docs/charms-deploying.html#deploying-to-specific-machines-and-containers
<hatch> I ask because huw pushed a commit 
<kadams54> hatch: yeah, although since then I've QA'd the card that fixes container count
<hatch> wait, what?
<kadams54> https://github.com/juju/juju-gui/pull/499
<hatch> so does #494 have to land before #499?
<hatch> or the other way?
<hatch> confused...
<kadams54> I don't think it matters
<kadams54> As long as they both land eventually :-)
<hatch> oh it was an existing issue...
<hatch> ok I'll pick up the second reviews on these and get them landed
<kadams54> It does seem odd to me that we're calling bare metal "root container" but not incrementing the container count.
<kadams54> Great
<kadams54> It'll be nice to have all of these landed.
<kadams54> FYI, I'm re-running the CI build for https://github.com/juju/juju-gui/pull/499
<hatch> aye 
<hatch> sounds good
<hatch> in order to get my keybindings in ubuntu to be what I want it makes the OSX host completely unusable lol
<hatch> looks like I'll have to investigate only modifying the keybindings in the vm
<jrwren> other than caps lock as ctrl, I gave up on custom keybindings a decade ago :)
<hatch> kadams54:  just fyi I'm not going to ship 494 until 499 lands and I can re-qa
<kadams54> k
<hatch> jrwren:  so I have caps as ctrl, alt as super, super as alt, plus some others I had to shift around to make that work :) 
<hatch> command, option (in osx) etc
<jrwren> hatch: I was about to say, "Sounds like a Mac"
<hatch> jrwren:  well it is mac hardware :) 
<hatch> but of course I use a PC keyboard which makes it even more complicated
<jrwren> hatch: using a PC keyboard on a Mac was one of the most frustrating things I've ever done in my life. I hate macminis to this day largely as a result of that experience.
<hatch> I'm thinking i need a new ergo keyboard and entirely remap it so that doing the ctrl+ combos aren't so messed up
<hatch> lol
<hatch> I remapped so that alt was cmd and super was option
 * rick_h__ gets annoyed with my 'photo' air with the thinkpad external keyboard on it
<hatch> then it was ok
<rick_h__> damn 'command/option' crap
<hatch> I was going to just keep fighting to get ubuntu on metal but then I coudln't qa in windows without booting into osx, running ubuntu and windows in a vm
<hatch> so....yeah
<hatch> tough life I suppose...
<hatch> :)
<hatch> kadams54:  do you have a good test run of #496?
<kadams54> That'll be the next CI build, but no, not yet
<hatch> ok np
<jrwren> rick_h__: where would this matrix code go?
<rick_h__> jrwren: in a spreadsheet, just put it in a doc for now and maybe we'll dump it to a doc or something once we go through it
<jrwren> ok
<rick_h__> jrwren: so we might add a doc/containers or osmething with the script, results, etc
<hatch> jujugui call in 8, don't be late, rick_h__ is here now ;)
<rick_h__> woot!
<hatch> jujugui call in 2
<rick_h__> antdillon: around for call?
<hatch> allllright back to doin qa's
<hatch> darn, looks like there is some conflicts
<hatch> fixing, will issue a new pr
<hatch> kadams54:  comments made to your PR
 * kadams54 sticks his fingers in his ears.
<kadams54> "La la la"
<hatch> lol
<hatch> +1'd with changes and qa ok
<hatch> lol all of huw's branches are failing when landing because of conflicts and failing tests
<hatch> I think they will have to wait until he gets in to get them fixed and landed
<kadams54> :-(
<kadams54> Lunch break for me
<rick_h__> hatch: yea, I cut down the WIP limits on there. That was a few too many branches in review at once 
<hatch> rick_h__:  I think it was just a symptom of huw combining cards
<hatch> into branches
<hatch> but probably not a bad idea :)
<rogpeppe> rick_h__: what's do you think is a reasonable behaviour when an http PUT request partially succeeds? should we return an error http status, but have some indication of which things have succeeded in the response body; or should we return a 200 status, but have some indication of errors in the response body?
<rick_h__> rogpeppe: I'd expect it to be some sort of 500 error with some information in the body. 
<rick_h__> rogpeppe: how does one 'partially succeed'? 
<rick_h__> e.g. we got the metadata but didn't finish getting a blob or something?
<rogpeppe> rick_h__: if we've got a PUT to meta/any, it might involve several database writes; one or more may fail
<hatch> imho the entire thing should fail (500)
<rick_h__> rogpeppe: gotcha, hmm, so it might be more a 400 things vs a 500?
<rogpeppe> hatch: i think i agree with that.
<hatch> 400 - you screwed up, 500 - we screwed up :)
<rick_h__> yea, I can get behind that. 
<rick_h__> hatch: right, but that's what I mean. If they supply bad data for the 4th document and we fail it should be a 400 "bad request"
<rogpeppe> rick_h__: yeah, that's a difficult one
<rick_h__> hatch: but if we fail because of conflicting user, db issues of our own, timeout, etc that'd be more 500 on us
<rogpeppe> rick_h__: the 4th document might have bad data, but the 5th document might have correct data but a db write error
<rick_h__> but I do agree that I think we fail in some error code way, and try to make sure a subsequent request has a chance of succeeding
<rick_h__> rogpeppe: right, but we'd return on first fail?
<rick_h__> rogpeppe: vs trying to push on?
<rogpeppe> rick_h__: we may not be able to do that
<rick_h__> oh hmm, double sucky
<rogpeppe> rick_h__: as we want to be able to this stuff concurrently
<hatch> yeah it should and then roll back to a clean state
<rogpeppe> hatch: we may not be able to roll back either (no transactions)
<rick_h__> rogpeppe: yea, I think a safe default is a 500 with message info
<hatch> rogpeppe:  right but you'll have to implement them in the Go side
<hatch> you can't have a bunch of broken records in the db because the user supplied incorrect data 
<rick_h__> rogpeppe: yea, we might need to be able to call out ids/records we know is in a fubar state or something
<rogpeppe> hatch: if it's a db error, it's likely the database connection is down, so we'll be a bit stuffed if we try to roll back
<rick_h__> rogpeppe: or else how does a subsequent api call not get back half rev 3 data and half rev 4 data?
<rogpeppe> rick_h__: i think it should be possible to avoid anything getting in a fubar state
<rick_h__> rogpeppe: cool, yea I'm +1 on starting with a 500 + message body
<rogpeppe> rick_h__: sgtm
<hatch> +1
<rogpeppe> rick_h__, hatch: thanks
<rogpeppe> only one other thing that concerns me: currently we are totally consistent when we send back an error response - it looks like {"Code": "something", "Message": "an error message"}. In this one case, we'd need to send back a set of errors, not just one. this makes me more inclined towards a different error code.
<rogpeppe> the consensus from a brief glance at these search results seems to be that some kind of 200 response might be more appropriate: https://www.google.co.uk/search?q=http+status+partial+failure&oq=http+status+partial+failure&aqs=chrome..69i57.4301j0j7&sourceid=chrome&es_sm=93&ie=UTF-8
<rogpeppe> specifically: http://stackoverflow.com/questions/8472935/http-status-code-for-a-partial-successful-request
<rogpeppe> rick_h__, hatch: ^
<hatch> rogpeppe:  the issue is that we shouldn't have a partial record created
<rick_h__> rogpeppe: right, but in that case resending to users would be harmful
<hatch> if you only create half of the required stuff it's going to cause issues
<rick_h__> rogpeppe: while in our case, resetting the data should be ok and safe
<rick_h__> rogpeppe: so there's no need to split out the next request to only supply data for docs 4 and 5 since 1-3 are already updated
<rick_h__> rogpeppe: I think a partial update of a charm is a failed update
<rick_h__> imo and all that
<hatch> agree
<rogpeppe> rick_h__: so we don't bother telling the client which elements of the bulk request have failed?
<hatch> we have to do everything we can to maintain a quality data set
<rogpeppe> rick_h__: we just say it all failed, even though some elements have actually succeeded?
<rick_h__> rogpeppe: right, the message might contain some info, but we're not going to expose to them "don't bother sending fields x,y,z, they're ok
<hatch> rogpeppe:  we would return the first thing that failed
<rogpeppe> hatch: we don't necessarily apply them all sequentially
<rick_h__> rogpeppe: the clients would have to be able to take that response, adjust a subsequent request, and submit again?
<rogpeppe> rick_h__: well, they'd have that freedom
<rick_h__> rogpeppe: right, but I think it's overkill for what we're doing
<rogpeppe> rick_h__: or they could just send the whole request again
<hatch> rogpeppe:  I'm confused, so you would leave partial incorrect data in the db?
<rick_h__> rogpeppe: and a ton of client complexity for what win? request size?
<rogpeppe> hatch: yes - i don't think there's any way around that possibiity
<hatch> rogpeppe:  of course there is
<rick_h__> hatch: welcome to document dbs sans transactions across docs :) 
<rogpeppe> rick_h__: i'm just wary of saying to the client "this failed" when some changes have actually been made
<hatch> no just because the db doesn't support it doesn't mean that the app layer cant implement it
<rick_h__> rogpeppe: right, but the client requested "change this metadata on an object" and that failed to occur and the client should notify the user, give them the info to try again with the hopes they can succeed.
<rogpeppe> hatch: if one change has been made, then the db connection goes down before you can make the next change, how're you gonna revert the first change?
<rick_h__> and it's too much for me to hink clients will not just check '200 success' but '200 but hey, did every field get updated?'
<rogpeppe> hatch: also, reverting the data is hard when you've got other concurrent clients. you might revert other clients' deliberate changes.
<rogpeppe> hatch: because the only way of reverting is by writing some data that you retrieved some time ago, since when it might have changed.
<hatch> rogpeppe:  so you have updated the db with bad data, now you go and request that data - oops the app fell over because of the bad data
<rick_h__> hatch: we can work on methods of mitigating. 
<rick_h__> hatch: let's concentrate on the initial question at hand. 
<rogpeppe> hatch: i don't think that we'll ever update the db with bad data here
<hatch> oh i thought the initial question was solved
<hatch> :)
<rick_h__> and we can debate ACID different :)
<rick_h__> hatch: well, rogpeppe was showing us the other examples in stack overflow and we were discussing how this is a bit different
<hatch> oh ok yeah 
<rick_h__> anyway, on that note I definitely think an erorr code on a failed update is still appropriate. 
<rogpeppe> rick_h__: this is different because we don't trust our clients? :-)
<hatch> no the workload to implement it in every client is not worth it
<hatch> imho
<rogpeppe> (to read the docs and response body)
<rick_h__> rogpeppe: this is different because redoing the work a second time in their case is 'ungood' 
<rick_h__> rogpeppe: so I'd consider their case an exception to the rule vs a standard 
<rogpeppe> rick_h__: there's just something that seems wrong in my bones about discarding error info like that, when one error might be "permission denied" and another might be "database failed", and the client would want to retry the latter but not the former.
<rick_h__> I'm not saying throw away the info. I don't see why we can't work out getting the errors to the user
<rick_h__> the only thing I'm against is a 200 when we know it failed 
<rogpeppe> rick_h__: ah, ok.
<hatch> rogpeppe:  the first is a 4** the second is a 5**
<rick_h__> I'm all for getting good error to the user
<rogpeppe> rick_h__: can we choose a different 500 error then?
<rogpeppe> rick_h__: i guess we'd have to choose a number ourselves
<rogpeppe> rick_h__: or... just encode it in the string i suppose
<rick_h__> rogpeppe: yea, nothing else 'fits' I can see
<rick_h__> where did you shoot me the current message object?
<rick_h__>  {"Code":  "something", "Message": "an error message"}
<rick_h__> so can we not update that in any way?
<rick_h__> with a details key, or allowing Message to be a list?
<rogpeppe> rick_h__: one possibility, which we've already explored a little way, is double-encoding json in the message
<rick_h__> :(
<hatch> so on submit you're going to wait untill all the 'transactions' are complete before returning to the user a list of the 'tasks' and their outcome?
<rick_h__> hatch: so they're going to fiure off 4 workers to update 4 docs and when all 4 come back build a response
<rogpeppe> hatch: yeah
<rick_h__> hatch: it might be all 4 are good, 200, or 3 good, one bad with a message, or 1 good 3 bad with 3 messages
<rogpeppe> rick_h__: allowing Message to be a list doesn't quite cut it.
<hatch> rogpeppe:  can one transaction fail with a 400 while the other is a 500?
<rick_h__> rogpeppe: k, I'm tempted to extend it a bit and say we have the code, a message "applying changes failed" and some details object that's more complex clients could use to provide the better list of feedback
<rogpeppe> rick_h__: we actually want to return a map from id to error in some cases, and from id to endpoint to error in some others
<rick_h__> rogpeppe: and for simple cases, the complex obj is just empty
<rogpeppe> hatch: yeah
<rick_h__> rogpeppe: but that's just what I would do. I can be talked into a different custom error code number or whatever
<rogpeppe> rick_h__: i think that's probably a reasonable approach. need to think it through a little more.
<hatch> I think this is all moot, the validation should happen prior to the db request so it will 400 before anything could 500
<hatch> so you only have 2 options, 200 for all, or 400 for one+ (which makes the responce 400)
<hatch> response*
<rogpeppe> hatch: for example, consider a PUT to /v4/meta/extra-info/foo of {"precise/wordpress-23": "val1", "precise/badcharm": "val2"}
<hatch> ok
<rogpeppe> hatch: that makes it considerably less efficient (and it can still fail) because you've got two db round trips where you only need one, and the object might still have disappeared when you actually make the request
<rogpeppe> hatch: (talking about pre-request validation there, BTW)
<hatch> but what I'm saying is that you should know that precise/badcharm is a bad charm before making the db request
<rogpeppe> hatch: you can't know that
<rogpeppe> hatch: maybe it was good but when you actually do the request for real, it's been removed
<hatch> *sigh*
<hatch> lol
<rick_h__> race condition turtles all the way down :)
<rogpeppe> rick_h__: yeah.
<hatch> sounds like wrong-tool-for-the-job syndrome 
<rogpeppe> hatch: it's ok really.
<rogpeppe> hatch: just treat them as independent requests, even though they're bundled up into one
<hatch> ok so return a list of error messages (in whatever format) and the request response status would be 200 < 500 < 400 
<hatch> so if they broke it, even if there is a 500, it returns a 400
<hatch> it couldn't continue anyways because they did something wrong
<hatch>  (we are still talking about the original request response code right? )
<rogpeppe> hatch: there are different classes of "wrong"
<rogpeppe> hatch: yeah
<hatch> well, unrecoverable wrong is a 400
<hatch> ok let me rephrase
<hatch> when would we want to return a 500 if there is also a 400?
<hatch> so they sent us bad data, and our db was down for example...
<rogpeppe> i'm somewhat inclined towards rick_h__'s p.o.v. that we should only return a 200 if everything went according to plan
<hatch> well yeah
<hatch> I didn't know that was even off  the table lol
<rogpeppe> and i think that if someone is generating bulk requests, they should be prepared to deal with the results
<hatch> agreed
<rogpeppe> hatch: well, that's what the SO post was suggesting (200 with result errors)
<hatch> oh, no imho that's bonkers
<hatch> :D\
<hatch> :D
<hatch> (I don't have strong beliefs at-all!)
<hatch> rogpeppe:  I suppose in the case where it would be alright if only one succeded then maybe...but even then i'd be pretty far on the side of returning a 4/500
<rick_h__> it makes sense in that case. If the api call sends emails out to users you don't want to resend to the same users again
<rogpeppe> so i'm thinking that for a bulk request, you'll always get a 500 error, and you have to look at the error details to find your individual error codes
<rick_h__> seems reasonable
<hatch> rogpeppe: well.... what if they had 400 errors and no 500 errors?
<hatch> so it was actually all their fault
<rogpeppe> hatch: i don't think it matters that much
<hatch> a 500 they may just re-submit the data even though it's faulty 
<rogpeppe> hatch: they can determine that by looking at the individual codes
<rogpeppe> hatch: which is logic they're going to have to write anyway
<rogpeppe> hatch: so it actually simplifies both server and client code, i think
<rogpeppe> hatch: (to have a single error code for a bulk request, that is)
<rogpeppe> s/code/status/
<hatch> ok I gotcha
<hatch> agree
<hatch> 200 or 500 with a list
<rogpeppe> hatch: yeah
<rogpeppe> hatch: and i will look into providing more arbitrary error objects in the error response
<hatch> yeah It would be nice if there was an array of errors or the lke
<hatch> I think rick_h__ mentioned that earlier 
<rogpeppe> hatch: definitely. that's the plan (actually a map/object of errors)
<hatch> what would the keys be? (curious)
<rogpeppe> hatch: in the /meta endpoint, the requested ids. in the /meta/any endpoint, the requested "include" endpoints.
<rogpeppe> hatch: and those can nest, i think
<hatch> ahh ok cool
<hatch> yeah +1's all around
<rogpeppe> hatch: so you could do: PUT /meta/any with the body {"precise/wordpress-23": {"extra-info/foo": 123, "extra-info/bar": true}, "precise/bad-435": {"extra-info/ppp", 345}}
<rogpeppe> hatch: and get the error response:
<rogpeppe> oops, let's rephrase that
<rogpeppe> {"precise/wordpress-23": {"extra-info/foo": 123, "bad-endpoint": true}, "precise/bad-435": {"extra-info/ppp", 345}}
<rogpeppe> possible error response:
<rogpeppe> {"Message": "partial failure", "Code": "partial failure", "Details": {"precise-wordpress-23": {"extra-info/foo": {}, "bad-endpoint": {"Message": "bad endpoint", "Code": "not found"}}, "precise/bad-435": {"extra-info/ppp": {"Message": "charm not found", "Code": "not found"}}}
<rogpeppe> perhaps...
<rogpeppe> i think that's the most complex scenario that there is
<rogpeppe> anyway, i need to stop now :-)
<hatch> looks easily parsable, although that would be a full failure :)
<rogpeppe> hatch: not quite - "precise/wordpress-23/extra-info/foo" was successfully changed to 123...
<rogpeppe> g'night all and happy weekends and mondays too.
<hatch> night rogpeppe see ya tuesday
<rogpeppe> hatch: see ya
<jrwren> juju status nil pointer reference.  I'm good at breaking things.
<rick_h__> hah
<hatch> lol
<lazyPower> hey hatch, question for you - is there already work being done to get ghost on series=trusty?
<hatch> lazyPower: by work.....do you mean.....me not being lazy?
<hatch> :D
<lazyPower> your words not mine ^_^
<lazyPower> apperance of lazyness is just applied efficiency
<hatch> haha - tbh it deploys jsut fine on trusty I just need to make a repo for it
<lazyPower> you also need tests
<lazyPower> Amulet testing of the ghost charm would be pretty simple. just some config set validation, and port 2364 (default) validation w/ port change requests validation and it should be g2g.    Throw in a haproxy relationship verify the reverse:proxy relationship is g2g and sounds like a winner for trusty
<hatch> oh yeah I need to learn amulet
<jrwren> friday rant: juju drives me to drink.
<rick_h__> jrwren: good day for it?
<rick_h__> jrwren: anything we can help out with?
<jrwren> rick_h__: just venting. I'm frustrated becuase I just wasted what feels like 2 hrs trying to make azure work.
<jrwren> rick_h__: isn't juju supposed to read updated environments.yaml ? somehow I had a stale environments/azure.jenv
<rick_h__> jrwren: yea, they're trying to remove environments.yaml
<rick_h__> and the jenv is the true source of truth
<jrwren> ah.
<jrwren> that is too bad.
<rick_h__> hopefully things will get better. Trying to get rid of the jenv as well. We'll see how that shakes out
<jrwren> that will be sweet :)
<hatch> Makyo:  hey any luck with the investigation of the multi unit removal?
<Makyo> hatch, yeah, I don't think we have enough information for much other than an XXX Comment now.  We don't know how the modelIds will look, and we'll need to allow people to remove specific units if they're on specific machine constraints.
<hatch> ahhh
<hatch> that's a good point
<hatch> darn - we really need that removal functionality :/ 
<hatch> I mean, it's not HORRIBLE heh
<hatch> but.....ya know
<Makyo> Yeah, for sure.
<Makyo> So let me push up real quick and get your opinion
<Makyo> Pushed
<hatch> checking
<hatch> +1'd
<Makyo> Will fix up that test, then
 * rick_h__ heads out for the day
<rick_h__> have a nice weekend all
<hatch> you too, cya
<hatch> man I'm just having no luck with the internets this week
<jrwren> I'm off. Have a good weekend ya'll.
<hatch> cya jrwren
<hatch> you too
#juju-gui 2014-08-17
<huwshimi> Morning
<hatch> morning huwshimi 
<hatch> you will want to take a look at the pr's some work to be done there :)
<huwshimi> hatch: Yeah, trying to land with my conflicts at the moment. One branch at a time.
<huwshimi> I knew there would be conflicts...
<hatch> I started doing it but I figured a rebase would be much easier for you than me manually re organizing the commits :)
<huwshimi> hatch: Yeah, thanks, it's not so bad
#juju-gui 2015-08-10
<bogdanteleaga> hello everybody
<bogdanteleaga> can somebody help me with adding win2012r2 to this dropbox menu and making it work? http://postimg.org/image/to2m0mtpn/
<bogdanteleaga> I've tried downloading the charm-zip, untarring the archive in releases/ and modifying https://github.com/juju/juju-gui/blob/develop/app/store/env/go.js#L158
<bogdanteleaga> however I'm not sure whether: a) that's the correct place to update, b) that archiving it back and deploying it would actually create that change without going through some make steps
<frankban> hi bogdanteleaga 
<frankban> looking
<frankban> bogdanteleaga: I confirm that's the place to be updated to add more choices to the series drop down when uploading a local charm archive
<bogdanteleaga> frankban: so what other steps should I do to get it up?
<bogdanteleaga> frankban: as I said, I tried modifying that repackaging the archive and deploying the local charm
<frankban> bogdanteleaga: do you need that now or can you wait a couple of days for a new gui release (including the charm)?
<frankban> bogdanteleaga: or do you just need a temporary hack to get those choices in your environment?
<bogdanteleaga> frankban: we've got a demo at the end of the week, I'd like to at least try it out if it's not that complicated
<frankban> bogdanteleaga: in this demo, do you demonstrate the GUI deployment or do you just need an initial environment with the GUI already there and the choices for new series?
<bogdanteleaga> frankban: we'd like to demonstrate the steps for the gui deployment, it is windows after all :P
<bogdanteleaga> frankban: I could just deploy from the CLI and show the gui result
<bogdanteleaga> frankban: oh, I misunderstood, sorry
<bogdanteleaga> frankban: the second one
<frankban> bogdanteleaga: so you can hack in the GUI unit before starting the demo, correct?
<bogdanteleaga> frankban: yup
<frankban> cool, so I have an idea bogdanteleaga, I am setting up a local env with quickstart right now, so that I can try while I expose it to you
<bogdanteleaga> frankban: cool, thanks
<frankban> bogdanteleaga: before we start, I'll try to get someone to update that list and I hope to be able to do a GUI release this week, so it's possible that at the end of the week you'll have a GUI with the new series out of the box
<bogdanteleaga> frankban: that'd be awesome as well
<frankban> bogdanteleaga: but if this does not happen, let's try to hack the new series in
<bogdanteleaga> frankban: https://github.com/juju/juju/blob/master/version/supportedseries.go#L77
<frankban> bogdanteleaga: cool thanks
<bogdanteleaga> frankban: you should toss centos7 in there :)
<bogdanteleaga> frankban: arch is CLI only at this point
<frankban> bogdanteleaga: so, assuming you have an environment with the juju-gui in it
<bogdanteleaga> we might need only win2012r2 and win2012hvr2 I'll get back to you with that one
<bogdanteleaga> yes
<frankban> bogdanteleaga: fir step is to "juju set juju-gui juju-gui-debug=true" so that the GUI is served via its non-minified version
<frankban> bogdanteleaga: then we can proceed and change the file you already found in the GUI unit: "juju ssh juju-gui/0 sudo nano /var/lib/juju-gui/juju-gui/build-debug/juju-ui/store/env/go.js"
<frankban> (replace nano with a textual editor of your choice)
<frankban> bogdanteleaga: then refresh the GUI page very well in your browser (shift+ctrl+r usually works) and the new series should be available when dragging and dropping a zip archive
<frankban> bogdanteleaga: I'll ping you when we have a new GUI release including this fix
<bogdanteleaga> hmm
<bogdanteleaga> frankban: it seems it was already there when I tried editing the file
<bogdanteleaga> frankban: and now it's in the browser as well
<bogdanteleaga> frankban: I could swear it wasn't there after I deployed it
<frankban> bogdanteleaga: is this your customized local charm?
<bogdanteleaga> frankban: yeah the one where I unpacked, modified and repacked
<bogdanteleaga> frankban: could it be the debug flag that did it or am I just tired? :)
<frankban> bogdanteleaga: it can be, anyway, my instructions work from scratch, without the need to deploy a local charm
<bogdanteleaga> frankban: yup, that's true
<frankban> bogdanteleaga: you are basically editing the files served by the GUI server running in the unit
<bogdanteleaga> frankban: thanks a lot :)
<bogdanteleaga> frankban: I'll get back to you later with the series that should get in
<frankban> bogdanteleaga: that's ugly but hopefully you won;t need it by the eow
<bogdanteleaga> frankban: I have a feeling we only want the CLI on win8, 8.1 and 7
<frankban> bogdanteleaga: I am planning about adding all the series listed in juju-core, except for centos and arch, is that ok?
<frankban> bogdanteleaga: so basically series: [
<frankban>       'precise', 'quantal', 'raring', 'saucy', 'trusty', 'utopic', 'vivid',
<frankban>       'win2012hvr2', 'win2012hv', 'win2012r2', 'win2012', 'win7', 'win8',
<frankban>       'win81'],
<alexpilotti> bogdanteleaga: dont forget Win10
<alexpilotti> and win2016
<bogdanteleaga> alexpilotti, frankban: yes, we should get those in core soon
<alexpilotti> win10 now, as itâs publicly awailable
<bogdanteleaga> alexpilotti: but only the server versions are for charms right?
<alexpilotti> not really, VDI woks on client too
<alexpilotti> AD, SQL Server, SP, etc only server of course
<frankban> bogdanteleaga: for now, I'd keep wily and win10 out of the GUI if they are not in core yet
<bogdanteleaga> alexpilotti: hmm, we should have some guards then somewhere to prevent faulty deployment
<frankban> bogdanteleaga: is your demo ok with the list above?
<bogdanteleaga> frankban: yes
<alexpilotti> but win2016 and win2016hv are out now in TP2
<frankban> cool
<alexpilotti> so we should get them in now already IMO
<urulama> alexpilotti: you guys have charms for win2016* already? we can include those series in new charmstore release this week if needed
<bogdanteleaga> alexpilotti: we need to get them in core before gui I think
<bogdanteleaga> urulama: there shouldn't be anything preventing the current ones from working
<alexpilotti> urulama: yep, we run tests on them, especially hyper-v
<urulama> bogdanteleaga: just asking if we need to add the win2016* and win10 to "unblock" you
<urulama> alexpilotti, bogdanteleaga: so, just to verify: new series are win10, win2016 and win2016hv?
<alexpilotti> thereâs also: win2016nano
<urulama> alexpilotti: what's that? :) the IoT thingy?
<alexpilotti> thatâs the NanoServer, Windows Server on a 300-400MB image
<urulama> hah, ok
<alexpilotti> we tested the Juju agent quite some time ago, but we need to run more tests
<alexpilotti> consider that this stuff is getting rolled out publicly via technical previews (we have TP2 in April)
<alexpilotti> and will get a final release next year
<lazyPower> frankban: rick_h_: That JujuGui stacktrace is back again about websocket closed - http://paste.ubuntu.com/12048618/
<lazyPower> i'm getting this consistently in CI across 2 substrates, GCE and AWS
<frankban> lazyPower: on call, I'll look, at first sight this is something I cannot dupe on ec2. juju quickstart and juju versions?
<lazyPower> frankban: pulling more details now, 1 sec
<lazyPower> frankban: juju-1.24.3, juju-quickstart 2.2.0
<frankban> lazyPower: is the error intermittent?
<lazyPower> i've triggered it twice, running a third time to capture the output
<frankban> lazyPower: dpkg -l python-websocket ?
<lazyPower> ii  python-websocket     0.18.0-0ubuntu0 all             WebSocket client library for python
<frankban> lazyPower: I have 0.18.0-2 which should be basically the same
<frankban> so for some reason juju-core closes the ws connection
<frankban> lazyPower: what's the output if you pass --debug to quickstart?
<lazyPower> http://drone.dasroot.net/github.com/chuckbutler/kubernetes-juju-builder/master/c6b3dbd3e0a8f2e792bbd926eb4d4fb981398b94
<lazyPower> not sure, but if you want to follow along at home - threaten it with developer debugging goggles, maybe it'll behave and stop stacktracing at me
<lazyPower> its going to hand off to quickstart momentarily
<lazyPower> if you opened your browser, it appears to have been the magic sauce to get it to behave
<lazyPower> it just bootstrapped and completed without stacktracing me :-|
<lazyPower> silly intermittant issues
<frankban> lazyPower: yeah, no errors now
<lazyPower> i'm calling schenanigans on juju
<frankban> lazyPower: if you can add --debug to your script then maybe the next time we have more info. looking at that tracebakc, it could be anything from juju-core oddities to python-websocket issues to network disconnections
<lazyPower> i think 1.24 had this issue in an earlier revision
<lazyPower> it might have been a cached image problem running an older juju
<frankban> lazyPower: that sounds like a great explanation ;-)
<lazyPower> weird that i pulled the updated image and it still tanked, but again, its probably a caching problem
<lazyPower> 90% of my issues are due to something being old hanging around w/ my aggressive caching strategy
#juju-gui 2015-08-12
<frankban> bogdanteleaga: new GUI charms released: precise/juju-gui-121 and trusty/juju-gui-38. they include the changes your suggested re deploying local charm archives
<frankban> suggested changes
<frankban> urulama_: ^^^
<urulama_> frankban: great
<frankban> urulama_: https://jujucharms.com/juju-gui/trusty now shows New charm release (1.4.3). commit which is two commits ago, so at least it's consistent ;-)
<urulama_> :D
<urulama_> frankban: https://manage.jujucharms.com/api/3/charm/trusty/juju-gui
<urulama_> :S
<urulama_> there's the source
<urulama_> (of the problem)
<frankban> ack
#juju-gui 2015-08-13
<bogdanteleaga> frankban: yup, everything's good, thanks
<frankban> bogdanteleaga: cool, mp
<arosales> where is the correct place to submit features for quickstart
<frankban> arosales: quickstart is at https://launchpad.net/juju-quickstart
<arosales> frankban, 
<arosales> thanks
<frankban> np
