#juju-gui 2013-09-23
 * frankban lunches
<gary_poster> upgrade...reboot...aaand we're back
<gary_poster> welcome back frankban! :-) have a nice time?
<frankban> gary_poster: it's good to be back, and yes, thank you, very nice time
<gary_poster> great :-)
<frankban> guihelp: I need two reviews (python, mostly code removal) for https://codereview.appspot.com/13824045 . Thank you!
<bac> frankban: will do
<frankban> bac: thanks
 * bac reboots
<gary_poster> frankban, looking now also.
<frankban> gary_poster: thanks!
<hatch> g'morning
<gary_poster> morning
 * hatch isn't here, he just woke up too early
<gary_poster> :-) sorry
<hatch> haha, it happens
<gary_poster> brb
<gary_poster> (switching locations)
<bac> frankban: tips on QA for your branch?
<frankban> bac: for that branch, I think there is no need to QA, it's mostly moving code around. However I can quickly write 3/4 QA steps if you want to try the deployer support
<bac> frankban: i feel the same about the branch
<frankban> bac: cool
<hatch> Do we have someone who's responsibility it is to approach providers and get them to write charms for their products?
<benji> I keep having test runs abort in the middle with no status reported.  Does anyone know anything about that?
<gary_poster> I don't, other than that there is a timer for the tests that we've had to extend in the past benji.  I'm also back, fwiw.
<gary_poster> if anybody said anything between my "brb" and now I didn't see it--backlog is upstairs.  (hm, I can fix that for next time)
<hatch> https://gist.github.com/hatched/a215f0d96fed6f41d165
<hatch> ^ gary_poster
<hatch> (chat log)
<gary_poster> thanks hatch! the people are the charmers--Antonio's team and Jorge
<hatch> cool I'll ping him
<hatch> thanks
<abentley> bac, benji: We have a replacement ready for the charmworld lander.  Unless you object, we will start trying to use it today.  Cool?
<bac> abentley: that sounds good.  i won't have any branches for cw landing today
<gary_poster> jujugui, fwiw we have five urgent inspector bugs to tackle.  I have some calls this morning and am trying to move the two pending reviews (huwshimi, hatch) through, but afterwards will help.  When people can take one of the urgent cards, please do.  These are not "drop your current branch" cards but "do next" cards.
<Makyo> jujugui call in 10 kanban now
<bac> gary_poster: no mongolian bbq for you.  bali hai burns.
<gary_poster> bac, lol, what?
<gary_poster> jujugui call in 2
<bac> you never went there?  on 6 forks
<bac> for the nerd engineers it was more about stacking the plate than eating
<gary_poster> heh, yeah never went.  too bad it burned
<gary_poster> hatch ping
 * hatch pokes head up
<bac> winter in TN now benji?
<hatch> I'm just watching edgeconf
<benji> bac: fall has fell
<gary_poster> hatch oh are you out today?
<hatch> yep, did I forget to add it to the calendar?
<hatch> oops
<gary_poster> hatch oh cool.  ttyl
<hatch> I'll be around if you need me
<gary_poster> cool thx
<benji> gary_poster: oops
<gary_poster> benji lol
<gary_poster> thx
<arosales> gary_poster, any way to pass a login URL for the juju-gui?
<gary_poster> arosales, if someone needs to log in then the main url should challenge them.  if not, bug
 * gary_poster goes for quick walk
<hatch> to elaborate a little bit - any url should redirect them to a login url
<hatch> if they aren't logged in
<arosales> gary_poster, sorry. I didn't phrase my question right. I was wondering if there were options to the GUI url to pass in auth
<arosales> gary_poster, user story, is we are working on a juju quick start image, and want to be opinionated as much as possible. With that we went to have the GUI up and running, but we currently block in the GUI auth. We know what the username and password is, so we just wanted to see if we could improve the story there.
<arosales> hatch, ^
<hatch> arosales: you can provide it in the config file
<hatch> is that possible in your image?
<arosales> hatch, yes I think so
<hatch> arosales: http://bazaar.launchpad.net/~juju-gui/juju-gui/trunk/view/head:/app/config-debug.js take a peek at the `user` and `password` properties
<arosales> hatch, we'll give that a try. We are boarding between the GUI being displayed on the host env and Juju operating in a VM
<hatch> the charm auto generates the config though which may cause an issue
<hatch> oh intersting
<hatch> I've never attempted that
<arosales> hatch, sorry when you said config I thought of https://jujucharms.com/precise/juju-gui/#bws-configuration
<hatch> ahh - it's been a while since I've been in the charm
<hatch> lemme see if there is a way for you to customize that
<arosales> hatch, I would be fine with going http://bazaar.launchpad.net/~juju-gui/juju-gui/trunk/view/head:/app/config-debug.js route, not sure how to implement that in a 'juju deploy'
<hatch> yeah just looking if we implemented a way to modify that
<hatch> arosales: doesn't look like it :/
<hatch> http://bazaar.launchpad.net/~juju-gui-charmers/charms/precise/juju-gui/trunk/view/head:/hooks/utils.py#L404
<hatch> the only real option is to deploy it with staging=true
<hatch> but that doesn't really work
<hatch> because then it goes to a sandbox mode
<arosales> hatch, basically my end to goal is to by-pass auth for this user story (local dev), and we can provide creds if needed since we are setting the env up anyways.
<hatch> gary_poster: ^ any thoughts on the 'proper' approach?
<hatch> all I can think of are ugly fragile hacks
<hatch> I suppose the best way would be to add the u/p as a config option
<hatch> but I don't think thats a quick addition :)
<arosales> hatch, and there are no extra url parameters that get parsed for login, correct?
<hatch> correct
<hatch> arosales: a possible easy sollution could be to log out their secret from the environments.yaml to the console during the script process to tell them that that's there password
<arosales> yup, we had that in our back-pocket, but just wanted to check with the experts here if there was any options we were overlooking
<arosales> hatch, thanks. sounds like, atm, it is not possible to pass authentication via url or cham config to the GUI.
<hatch> yeah unfortunately no - I'd probably vote for providing it as a config options
<hatch> s/a//
<hatch>  s/a//
<hatch> I'm not sure if that came through
<hatch> yeah unfortunately no - i'd probably vote for providing it as config options
<hatch> :)
<benji> At lunch I determined that my new headphones don't have a rattle.  I also determined that the headphone jack of my laptop has a short.
<arosales> hatch, +1 on a config opt to the charm if that is possible.
 * arosales realizes that would be dev work needed, but there are some local dev use cases. 
<gary_poster> arosales, hatch there is one now pretty sure.  looking
 * arosales awaits gary_poster's search
<gary_poster> arosales, hatch, right, there's one in the GUI but we have not exposed in the charm.  would be pretty easy to add.  what's the timeframe & what's the benefit?
<gary_poster> arosales, I understand use case, I mean in your estimation how valable is that story to the quick start story?
<arosales> gary_poster, hmm
<arosales> its the the cost of having the user look in the console, then copy/paste into the GUI.  
<arosales> gary_poster, so not huge 
<gary_poster> arosales, ack.  I want something like this in our quick start story too.  what is your timeframe?
<gary_poster> I could have it done in probably 2-3 days.  I should get four or five urgent bugs fixed and released first
<gary_poster> but after that this would be a quick task
<arosales> gary_poster, we may go out with an image this week and then we can keep improving on it when you land features.
<gary_poster> arosales, ack.  I'll try to sneak it in over the next couple of days.  will ping you when it is in, and might ask for qa to verify
<arosales> gary_poster, we would be happy to.  Let us (arosales and utlemming) when we should test. Thanks for working on squeezing it in. 
<gary_poster> cool arosales, welcome
<hatch> :)
<bac> ha, the ikea delivery man couldn't find our house so he invoked a non-existent ban on deliveries in the old city after 1pm and went back to the warehouse.  my evening just freed up.  i was looking forward to some cheap furniture assembling.
<benji> heh; customer service does seem a bit lacking in your present neck of the woods
<hatch> heh around here they will just leave the paper on the door and not knock because they assume I'm not home
<hatch> very frustrating
<bac> argh, lbox is causing my tests to crash again.  so annoying.
<huwshimi> Morning
#juju-gui 2013-09-24
<bac> benji: could you do a 2nd on https://codereview.appspot.com/13660050 when you have time?
<benji> bac: sure
<bac> itunes has a page for your app purchases with a big 'Report a problem' button.  when you press it, the button disappears but nothing else happens.  cunning.
<benji> bac: that's because at that point there is no need for the button any more, you have reported yourself to be a problem.
<bac> it is only 99 cents but i want the developer punished
<benji> BradCrittenden: I just saw this comment in the charm model code.  Do you know what this means for the bundle model?
<benji>   // XXX jcsackett Aug 12 2013 Charm model is only being kept while we observe
<benji>   // the effects of the changeover to Browsercharm. This can be deleted once we
<benji>   // ascertain there is no fallout.
<BradCrittenden> benji: i saw it too.  it should have no affect on bundles
<jcsackett> benji, bac: i think rick_h_ completed that changeover, so maybe that comment can go away?
<benji> jcsackett: you may be right: I just checked for BrowserCharm and it doesn't appear in the code base (other than a substring of BrowserCharmView, which should probably be renamed)
<bac> benji: but the comment mentioned a transition TO browsercharm
<rick_h_> benji: bac jcsackett is correct. Missed that in my changeover 
<benji> bac: I think BrowserCharm became Charm and the old Charm model went away (or they were merged or something similar)
<rick_h_> it's not camel cased so missed it in my grep for BorwserCharm
<rick_h_> with better spelling...
<bac> so the model that begins like the following is the keeper:
<bac> models.Charm = Y.Base.create('browser-charm', Y.Model, [], {
<bac> rick_h_: ^^
<rick_h_> bac: right, that's the one true model used for everything 
<bac> rick_h_: cool.  i may do a quick follow on branch to kill the other as it is way confusing
<rick_h_> bac: rgr, comment should go away for sure
<bac> if i can get lbox to not blow up.  /me crosses fingers
<bac> rick_h_: does android allow per number call blocking?
<jcsackett> bac, rick_h_: There is still the old charm model in that file too, and it can die. (var Charm = Y.Base.create ...)
<bac> jcsackett: yep.  thanks for confirming.
<jcsackett> and it looks like the old CharmList is there too; you want to keep the instantiation that starts with models.CharmList, rather than var CharmList 
<rick_h_> jcsackett: huh? We still use charmlist?
<rick_h_> bac: so I don't know. I know google voice does (which I use) but not checked on the device itself
<rick_h_> bah, this 3g lag is crazy
<jcsackett> rick_h_: yes. BrowserCharmList became CharmList when BrowserCharm became Charm.
<rick_h_> jcsackett: right, and BrowserCharmList is still there?
<jcsackett> rick_h_: doesn't look like it.
<jcsackett> there are just two declarations for CharmList
<jcsackett> but only one is attached to the namespace.
<jcsackett> it's a source of confusion in reading the code, i think, but not an issue per se.
<rick_h_> jcsackett: ah gotcha. ignore me then. 
<jcsackett> ah, the damage a typo does. my XXX comment helped not at all when you were killing all of this. :-P
<rick_h_> well, my fault for rushing to do it before I left and just reading off grep
<abentley> bac, benji: We believe the new lander is working properly.  Please let me know if you have any issues.  It's at http://162.213.35.27:8080/ btw.
<benji> abentley: do we just mark MPs as approved and it lands them?
<abentley> benji: Yes, and then it updates staging.
<benji> abentley: cool!  And I guess (hope) it runs the tests before landing/updating
<Makyo> Sigh.  NB: make clean is your friend.  Always has been, always will be.
<abentley> benji: Right.
<benji> Makyo: the guy that wrote one of the best books on make says that make clean shouldn't ever be a thing and the real make clean is "rm -rf" and re-check-out the project. :)  I tend to agree with him.
<Makyo> benji, Hah!  That was going to be my next step out of frustration :)
<Makyo> I just rebuilt my env last week, though.
<Makyo> Though I'm sure that works with lightweight checkouts without having to redo everything.
<hatch_> lightweight checkouts are da bomb!
<hatch_> I don't know how they work but aww yeahhh
<Makyo> Hahah
<hatch_> lol
<Makyo> Spent the end of yesterday and beginning of this morning debugging a 404 on a test file that only showed up in test-debug/prod, but not test-server. Oh well~
<Makyo> jujugui review/QA please https://codereview.appspot.com/13705045/
<hatch> I'll take one
<hatch> what was the issue?
<Makyo> make clean fixed it.  It was requesting an asset from an old location, I guess.
<hatch> could I get a very quick review on the hacking docs update https://codereview.appspot.com/13828044/
<hatch> jujugui ^
<Makyo> On it
<hatch> thanks
<benji> hatch: I don't think sudo on the lbox install is neccesary (and probably not a good idea)
<hatch> benji: it was under sudo before so I just left it as such
<hatch> can it even be installed without sudo?
<benji> hmm, in that case I would default to leaving it too, but I'm suspicious
<hatch> someone with 12.04 can check :)
<benji> hatch: mine is installed without sudo
<hatch> oh alright then, I can remove it
<Makyo> As long as your $GOPATH is where your user can write it.
<hatch> mm goo point
<hatch> maybe I'll just leave it
<hatch> :)
<hatch> does anyone know of a charm that's very basic? now that I have juju core set up to test it would be nice to use charms which install fast :)
<hatch> bac: ci failure in firefox
<Makyo> hatch, does $GOPATH default to something?  Can you `go get` and `go install` without it?  That used to not be the case, but perhaps that's changed?  Blanket use of sudo aside, it'd be nice to make sure we're right in our docs :)
<hatch> usr/lib i think
<hatch> but darn now I can't remember
<Makyo> hatch, I've got a fresh Ubuntu server vm, want me to check?
<hatch> if you have the time
<hatch> no rush
<Makyo> hatch, Sure, give me a few.
<bac> hatch: looking
<bac> jcsackett, rick_h_: could one of you look at this deletion branch https://codereview.appspot.com/13255052
<Makyo> hatch, no default $GOPATH. I'd suggest something like adding "Set your GOPATH environment variable to something like $HOME/bin/go" and then you can remove the sudos.
<Makyo> hatch, Will also have to modify $PATH, will get that info to you in a sec.
<hatch> ok, I accidentally hit submit instead of propose :/ but I'll still update :)
<Makyo> hatch, That's fine.
<hatch> oh and re zookeeper, I'm not sure, I ended up running it anyways
<hatch> so I'm not sure if it's not required or not
<hatch> might be for 12.04 but not 13.04
<Makyo> hatch, export $PATH=$PATH:$GOPATH/bin:$HOME/bin/go/bin
<Makyo> WAIT
<Makyo> That's what I get for typing from memory.
<Makyo> export $PATH=$PATH:$GOROOT/bin:$GOPATH/bin
<Makyo> (Which is for bash, ofc. May want to type that out in words, like "Add $GOROOT/bin and $GOPATH/bin to your PATH environment variable")
<hatch> Makyo: if you don't mind, could you gist that for me? my irc client is turning it into an emoticon mess
<Makyo> hahah, sure :)
<luca__> gary_poster: when are you starting work on project: I scream, you scream, we all scream for ice cream?
<Makyo> hatch, https://gist.github.com/makyo/6686500
<gary_poster> lol, one sec, on call about it luca__ 
<hatch> lol
<hatch> Makyo: thanks
<hatch> :)
<luca__> gary_poster: ah, are you talking to emma and mark?
<gary_poster> y
<hatch> hmm /me has not met this emma yet
<hatch> I think it's time for another London trip
<Makyo> Pff.
<hatch> yeah you're right, lets do Ireland or something
<Makyo> I do need to take James to London.  Helps that there's the office there to work at.  Maybe we'll figure something out next year.
<hatch> Friend of mine just had a corporate meeting in Banff
<Makyo> Hahaha, I'm not opposed to that, either!
<hatch> nope!
<bac> hatch: i have a real error in my test.  done() called before the end.  odd that chrome was happy with it.
<hatch> bac: darn - I was really hoping it was a glitch
<bac> hatch: i prefer the explainable
<bac> even if the explanation is that i goofed.
<hatch> yeah good point :)
<hatch> Makyo: you know you don't 'need' an office to work at ;) All you really need is wifi and a power outlet (mostly because your laptop won't last 30mins on a charge :P )
<Makyo> hatch, I'm slowly getting my dev env set up on the MBA!  The only problem I've run into with that is that it goes to sleep thirty seconds after plugging in/unplugging for some reason, regardless of activity.
<Makyo> hatch, Though I just imagine that working in the office would be more conducive to actually working than working in, say, a hotel lobby.
<Makyo> Though those heights, man...
<hatch> well I'd probably bank on a building falling over before a mountain falling over
<hatch> so probably a safe bet
<hatch> Makyo: search for Caffeine - it's a must have app for osx
<hatch> http://lightheadsw.com/
<Makyo> hatch, I'll look into it.  This seems more like a bug than anything - it'll go to sleep in the middle of typing - but that may be handy otherwise.
<hatch> ohh - yeah that's definitely not normal
<Makyo> Though there was a recent software update, will see if that fixes it.
<hatch> are you able to run an ubuntu vm on it?
<Makyo> Yeah, I have an ubuntu server VM for running the dev env/bzr/lbox.  Files are shared over NFS so I can work on the MBA itself.
<hatch> cool cool
<hatch> that's what I'm doing right now as well
<hatch> although every time I switch to the 13.04 desktop I like it more and more
<hatch> although the thing that I hate the most os the header bars for the windows
<hatch> they don't match the rest of the OS at-all
<hatch> pretty pretty pretty - O M G WHAT HAPPENED
<hatch> that's what happens to me
<hatch> lol
<Makyo> Hah.  They match well enough for me, so maybe you've just got a weird theme going on.
<Makyo> jujugui call in 10 kanban now
<Makyo> hatch, re: your comments on my branch, I'll check on the errors, though I wasn't getting them.  The rest is for the next card.
<hatch> hmm i was on a fresh pull
<hatch> I can try again
<Makyo> hatch, I don't doubt it, I'll keep investigating.
<hatch> Makyo: oh yeah on my laptop I don't think I run a single stock UI element haha
<Makyo> hatch, Well, no wonder it looks all wonky :)
<hatch> oh no I'm talking the stock UI
<hatch> the black embossed headers don't match the rest of the UI
<gary_poster> luca__, hey.  I should give a quick summary to you of call I just had with Mark Baker and Emma
<Makyo> hatch, Huh?  They do for me..
<gary_poster> luca__, you coming to daily call, or are you around in 15 or 20?
<hatch> Makyo: really? the rest of the UI is flat/square and they are rounded and embossed
<gary_poster> alejandraobregon will want to know too, but it is fairly simple so can tell you, you can tell her, and I can also write email about it later today
<Makyo> hatch, rest of the UI is rounded and embossed for me, too.
<hatch> oh weird
<Makyo> hatch, buttons are embossed squircles, dash has rounded corners, folders are glossy, etc.
<hatch> yeah not here - maybe I installed something and don't remember
<hatch> which is entirely possible
<gary_poster> jujugui call in 2
<gary_poster> benji you around?
<benji> gary_poster: no
<gary_poster> benji, :-P
<benji> quote of the day right there: "fukushima brand sushi"
<hatch> yeah and it wasn't from me!.... yussss
 * hatch passes torch to Makyo
<Makyo> Hahahaha
<hatch> I think I still need a roomie for SFO, not sure if anyone else is still looking
<Makyo> I don't think I have one yet.
<hatch> sup roomie!
<Makyo> Yo.
<hatch> http://www.engadget.com/2013/09/24/zboard-San-Francisco-Special-gets-crowdfunded/ next step the hover board from Back To The Future?
<abentley> I do not know whether to be proud or ashamed: http://bazaar.launchpad.net/~abentley/charms/precise/packages/trunk/view/head:/README
<hatch> oo new imacs....maybe this means new mbp's are finally coming
<hatch> abentley: are they REALLY mutually exclusive? ;)
<hatch> bcsaller: can I send a remove-service delta from the console?
<bcsaller> hatch: you could if you took app.env.ws.onmessage({delta}) I think
<bcsaller> hatch: or calling the method on the fakebackend
<hatch> alright - I just now need to figure out what the format of the request is
<bcsaller> hatch: the tests will show that
<bcsaller> the go sandbox tests would show the message format
<gary_poster> abentley, heh, wow, yeah, maybe both, but sounds cool :-)
<hatch> bcsaller: so I haven't had any luck using onmessage but I figured that calling app.env.destroy_service('liferay') should trigger a delta in sandbox...no?
<gary_poster> hey hatch, I have a viewlet test that is leaving something dirty.  wondering if you have seen before, because I am ready to get this done and have some lunch. :-)  you available? 
<hatch> yeah I'm not getting anywhere while I wait for my core instance to boot up
<gary_poster> hatch cool 
<gary_poster> https://plus.google.com/hangouts/_/5a21fc24877892fe2bd5ba462ce6f47f9c2bce2e
<bcsaller> hatch: yes, that is exactly as if you'd destroyed the service from the inspector though
<hatch> ohh so that's intentional
<hatch> ok got it
<hatch> jujugui does anyone know a 'juju' way to access exposed services from inside a 'local' deployment inside a vm without an ssh tunnel?
<hatch> something like exposing the local service to the hosts ip?
<gary_poster> hatch, it Just Works for me
<hatch> mine gives me 10.0.X.X ip's
<hatch> which are only accessable from the host vm
<gary_poster> hatch, oh you mean to the parent
<hatch> yeah
<hatch> from within the vm, no problem
<hatch> I have too many levels of recursion :D
<hatch> I can tunnel, it's not an issue but just wondering if there is a juju way to do it
<hatch> it feels like there should be
<gary_poster> hatch, I always use vms that share networks with surrounding.  I forget the setting name, but that alleviates issues like that IME
<gary_poster> not a juju issue I don't think
<bcsaller> that should also work though, there isn't a local firewall so expose isn't even needed. you can't go directly to that ip on the right port?
<hatch> well I need to create an ssh tunnel from the juju-gui 'machine' to its host
<hatch> like...
<hatch> ssh -N -p 22 -c 3des devbox@localip -L 1234/10.0.X.X/443
<hatch> then when I go from my desktop machine to access the 'localip' of the devbox it works as expected
<bcsaller> nah, the lxc network should be bridged by default, it used you be, `route -n |grep lxcbr0`
<hatch> 10.0.3.0        0.0.0.0         255.255.255.0   U     0      0        0 lxcbr0
<hazmat> hatch, you can do that (ssh forward) or do iptables port forward if you want something more transparent
<hatch> hazmat: should exposing a service on juju local automatically port forward?
<hatch> it feels to me like it should 'just work'
<hazmat> hatch, no, juju does not touch iptables
<hazmat> hatch, local provider .. hint was meant for local usage, where its not nesc.
<hazmat> hatch, the use of lxc containers (via juju add-machine lxc:0) on non local providers is pretty new, and only works out of the box for baremetal
<hatch> ohh ok
<Makyo> hatch, when you get a chance, I can't dupe the errors, though I did see them during development.  Can you tell me the process that led to them?
<hatch> I'm wondering if this is going to cuase confusion to others who might be using a remote box and trying lxc versions
<hatch> ^ hazmat
<hatch> Makyo: will repro and get back to you
<Makyo> hatch, thx
<gary_poster> hatch are you doing add-machines or just environements.yaml type:local?
<hatch> juju boostrap -e local
<hatch> so the latter
<gary_poster> right
<hatch> Makyo: http://HOSTIP:8888/:flags:/upgradeCharm ; DD liferay ; deploy ; errors errors and more
<Makyo> hatch, oh, that's right, hold on.
<benji> jujugui: I have a review up at https://codereview.appspot.com/13860044
<Makyo> hatch, forgot to take note, had forgotten.  I see that every time with liferay, but only liferay.
<hatch> ohh.....lol crazy that I chose it in my QA then haha
<hatch> typically I don't choose it for some reason
<Makyo> Same!
<Makyo> Will look into it.
<hatch> gary_poster: hazmat so once add-machine works on lxc this issue will no longer be?
<gary_poster> hatch, no, on my side just was confused by why hazmat raised add-machine
<gary_poster> separate issue AFAIK
<hatch> ohh - ok then yeah I'm confused too :D
<hatch> I'll ssh tunnel it for now - no big deal, but maybe could be worth a note in the lxc docs or a blog post or something
<hatch> darn just ran into this bug https://bugs.launchpad.net/juju-core/+bug/1210054
<_mup_> Bug #1210054: juju terminate-machine with local provider doesn't destroy machine <juju-core:Triaged> <juju-core (Ubuntu):Triaged> <juju-core (Ubuntu Saucy):Triaged> <https://launchpad.net/bugs/1210054>
<hatch> rebooted the host and now the ssh tunnel doesn't work :/
<hatch> clearly today is not my day hah
<hatch> the machines instance-state is 'missing' is that supposed to be like that on lxc?
<gary_poster> hrh, no
<gary_poster> heh
<gary_poster> jujugui, looking for one review/qa of https://codereview.appspot.com/13841044 .  Meanwhile, getting some lunch
<gary_poster> then will do reviews myself, if any are around :-)
<hatch> gary_poster: I can do it
<hatch> maybe I'll then ask in juju about this oddity
<hatch> """The local provider has been enabled. There is currently one serious restriction with it right now, IP addresses are not available on the machines shown in status. This means that youâll see âinstance-state: missingâ for the machines in âjuju statusâ."""
<hatch> gary_poster: reviews done - funny how the only real QA issue was the 'cool' feature you added ;)
<benji> jujugui: I'm looking for a review of https://codereview.appspot.com/13860044
<bac> benji: ok
<benji> thanks
<bac> benji: your RV is full of chunk mismatch.  i'm not sure how that is fixed.
<benji> bac: hmm; were you able to review it or should I look into fixing the MP?
<bac> benji: i did not review it
<benji> bac: k, I'll see about fixing it
<benji> bac: I've fixed it.  Also, note that the only real non-mechanical (but still relatively trivial) changes are in app/widgets/token.js
<bac> why do power supplies not have unique tips based on output?  just fried my usb 3  hub.
<bac> ok
<hatch> bac: because you would need about 1M different ends :)
<hatch> and that might be on the low side :P
<bac> hatch: that raises a whole different issue...
<hatch> haha oh so true so true
<bac> dear EE grads, you can have 5V or 12V, that should be sufficient for all designs
<hatch> don't you mean
<hatch> OEE grads
<hatch> Over electrical engineer :P
<hatch> honestly I have a very limited knowledge about it, but my guess is if you have to step down from 12v to say 6v you would essentially just be converting it to heat
<hatch> which isn't very efficient
<bac> use 12V or 5V components, avoid the step down
<hatch> right but if you don't need the current it's going to go to waste somewhere
<bac> like my fried hub?  that's waste!  :)
<hatch> lol
<hatch> good call
<bac> Makyo: fwiw, 'make clean; lbox submit' still fails in that same way.
<Makyo> bac, Gah :/
<bac> but only 4/5 times.
<hatch> lol 80% failure rate is not good
<hatch> :/ ok after updating Juju nothing I can do will give me access to this exposed juju-gui instance
<hatch> bac: mind telling me the setup you used again to get your tunnel working
<hatch> I'm sure I'm using the identical code but the tunnel does not work :/
<bac> hatch: do you have 'ssh tunnel manager' for os x?  pretty handy.
<bac> ssh -N -p 22 -c 3des bac@saucy64.local -L 8888/10.0.3.162/80
<hatch> and you run that from osx?
<bac> yes
<hatch> what version of juju are you using?
<hatch> yeah nothing....it's not even hitting the tunnel :/
<bac> that seems beside the point but i sometimes run the packaged juju (1.14.1-saucy-amd64) and sometimes i run my $GOPATH/bin/juju hand-built version
<bac> hatch: and your trying https://localhost:8888 ?
<bac> ick, i said 'your'
<hatch> well it's not localhost, it's another machine
<hatch> so I'm visiting that machine
<bac> but the tunnel is your machine
<gary_poster> hatch, hey.  thank you very much for review and qa. I can't dupe your qa bad, or maybe we have different expectations.  also one code comment made me want to talk with you.  you available in https://plus.google.com/hangouts/_/23d50444baecceeabfa7ec461380e05ea8123912 ?
<bac> the entry to the tunnel is localhost, i.e. the machine safari is on
<bac> that's what the -L means
<hatch> oh jeebus
<hatch> what a stupid mistake
<hatch>  /face-desk
<bac> benji: i did the review and sent it but haven't even pulled your branch yet.  i'm still struggling to get one landed first.
<bac> so, i'm saying i didn't do qa or even run the tests.
<benji> bac: it's ok, everything works fine
<benji> ;P
 * benji goes to an appointment.
<hatch> bcsaller: can you join gary and us in the chat above?
<Makyo> hatch, when you get a chance, re-pull/test for liferay fix
<hatch> thanks will do
<hatch> every time I use the GUI on a real env I am impressed :)
<hatch> the simulator is cool...but the real thing is so much better
<hatch> ^ taken out of context that statement....rules
<hatch> jujugui didn't we have an option in the charm to enable unminified code NOT on the simulator?
<gary_poster> hatch, yes, frankban added it, though it is probably only on ~juju-gui charm atm.  lookin
<gary_poster> wow the new charm tokens from 0.10 are way better to use
<gary_poster> hatch, yes, look on https://jujucharms.com/~juju-gui/precise/juju-gui-106#bws-configuration for juju-gui-debug option
<hatch> ahh ok and it looks like I'm running version 76
<hatch> wow that's behind haha
<hatch> (we should probably fix that ;) )
<gary_poster> hatch, no you are using official release
<gary_poster> ~juju-gui-charmers
<gary_poster> that's what you get by default
<hatch> ohh
<gary_poster> moving charm from ~juju-gui to ~juju-gui-charmers is equivalent to making a release
<gary_poster> ~juju-gui is trunk
<hatch> so it looks like you can't upgrade the GUI from within the GUI?
<hatch> known issue?
<gary_poster> that's what Makyo is working on, if you've noticed :-)
<hatch> oh...right...duh
 * hatch fail
<gary_poster> :-)
<hatch> gary_poster: don't agree with my personal preference of if (!value) { return; } ? ;)
<hatch> it doesn't look like I can set the debug option in the GUI
<hatch> although seeing the GUI move when I alter it from the console is pretty cool :D
<bac> benji: can we chat first thing tomorrow about next steps?
<gary_poster> hatch, yeah, I lean towards preferring to return at the end of the function. Maybe silly.  <shrug>  Not being able to set the debug option in GUI is odd.  I wonder if that's a bug with our bool handling. :-/
<hatch> quite possibly
<gary_poster> landing huwshimi's branch.  running for now.  bye all
<hatch> cya
<hatch> Makyo: there was a branch recently which closed the little 'make relation' menu on the canvas, can you point me to where that code is?
<hatch> basically it's being left in the canvas when a service is being removed from the console
<hatch> so I want to make sure that it gets hooked in with the inspector closing code
<hatch> found it
<Makyo> Oops, sorry, was dogwalking.
<hatch> no problem
<hatch> hmmmmm
<hatch> so we 'remove' these service models but don't destroy them
<hatch> quite innnnteresting
<bac> now gary_poster has killed jenkins
<hatch> haha, looks like it might be a canonistack issue
<arosales> any recommendations on the work-flow to add a unit to a service in the GUI (looks like the inspector is the way to do it in).
<arosales> nevermind that is the inspector
<huwshimi> Morning
<hatch> it's not really clear where to find that information being that the Service is the primary
<hatch> all of these are great bugs to open btw so that we can take them to UX and say 'seeeeeeee' others say so too :D
<arosales> ya I thought I would confirm and then file bugs and let you guys triage accordingly
<hatch> awesome
<hatch> btw I'm slowly working on that charm
<arosales> hatch, thanks for following up though
#juju-gui 2013-09-25
<hatch> no problemo
<frankban> guihelp: I need two reviews for https://codereview.appspot.com/13890044 . Anyone available? thanks!
<bac> hi frankban, i'll look
<gary_poster> writing emails, but will look soon if no one ha claimed
<frankban> bac, gary_poster thanks
<frankban> gary_poster: re bug 1229939: it's a little more generic than juju-gui-debug. I think at the moment the GUI is not able to change any settings option in juju-core (we are sending an incorrect API request). I'd mark that as critical and start working on it.
<_mup_> Bug #1229939: Cannot set juju-gui-debug from GUI <charm> <juju-gui:Triaged> <https://launchpad.net/bugs/1229939>
<gary_poster> frankban, that was my assumption as well.  The card is in urgent on kanban.  have at it, and thank you! :-)
<frankban> oh I see, yes, ok thanks
<gary_poster> frankban, bac and I both gave you code LGTMs but with similar suggestions.  bac is still running tests
<bac> frankban: my tests had to be restarted.  my new environments.yaml file had problems with ec2
<frankban> gary_poster, bac: thanks for the review. re splitting the test, I am +1 on testing errors separately. I'd like to keep the two deployments story in a single test. I intended that test as a story indeed, but I agree with you that test separation is something we should always pursue
<bac> frankban: +1
<bac> gary_poster: did you run frankban's tests?
<gary_poster> bac no; on call
<bac> ok
<bac> frankban: i'm seeing failures.  since gary didn't run them i'll investigate
<frankban> bac: can I help?
<bac> frankban: http://paste.ubuntu.com/6154594/
<frankban> bac: are you using juju-core trunk?
<bac> frankban: yes.
<bac> frankban: should i retry with /usr/bin/juju?
<frankban> bac: is /usr/bin/juju the last juju-core release?
<bac> 1.14.1-saucy-amd64
<frankban> bac: cool, yes, that could be better, but at this point, if you agree, I'd suggest you to wait until I divided the test as suggested in the reviews
<bac> frankban: ok
<frankban> bac: thanks
<frankban> bac: fwiw, I am experiencing problems with juju-core trunk, and I reverted to r1750. Also filed a bug two days ago: bug 1229286
<_mup_> Bug #1229286: debug-log and boolean options are broken in trunk <juju-core:New> <https://launchpad.net/bugs/1229286>
<bac> ok
<hatch> yeah I think there is something broken in general with the settings
<hatch> I couldn't get them to work for the debug switch either on the gui
<frankban> hatch: yes I know, I am working on the bug you filed
<hatch> oh awesome thanks
<hatch> I'd be interested to know the issue
<hatch> once you're done of course :)
<frankban> hatch: quite easy, we are sending Params.Config where juju-core expects Params.Options. While I was there I decided to switch from ServiceSet to ServiceUpdate  too. The former will be eventually be deprecated.
<hatch> ohh darn, that was a fail :)
<frankban> hatch: the weird think is that juju-core seems to just ignore the unexpected parameter and return a ok-response rather than an error
<frankban> s/think/thing
<hatch> yeah that sounds like a core bug
<frankban> anyway, config, options, settings, we use too many terms for the same concept
<hatch> ^ truth!
<hatch> at least we now have a single model :D
<luca__> gary_poster: what files can be imported to the GUI?
<gary_poster> luca__, config.yaml for charms, and bundle yaml
<luca__> ok
<bac> hey benji, you free to chat?
<benji> bac: sure
<benji> your hangout or mine?
<bac> i'll start one
<hatch> wow - there are a lot of versions of the GUI on the charmstore
<benji> bac: if you haven't gotten into your next task, here is a short review of the stand-in bundle token branch: https://codereview.appspot.com/13910043
<bac> ok
<gary_poster> benji is there a way to qa?
<benji> gary_poster: nope, it is not wired up enough to do that yet
<benji> (that's our next step)
<gary_poster> ok cool benji thx
<bac> benji: did
<gary_poster> frankban, is the fix for bug 1229939 something that you can get done today, or will you need to hand it off?  Also, I want to talk to you about bug 1229215 but don't want to distract you on this task.  maybe tomorrow.
<_mup_> Bug #1229939: Cannot set juju-gui-debug from GUI <charm> <juju-gui:Triaged> <https://launchpad.net/bugs/1229939>
<_mup_> Bug #1229215: Confusing unit retry/resolve UX <juju-gui:Triaged> <https://launchpad.net/bugs/1229215>
<bac> gary_poster: did huw's branch get merged?
<gary_poster> bac yes
<bac> gary_poster: is that not the one that is in active coding?
<gary_poster> bac I thought so but that branch looked more like a prep branch.  I can make a new one instead and rewrite this one.  will do so.
<frankban> gary_poster: I am proposing the fix now. Then let's do a call when you want
<gary_poster> cool thanks frankban!
<hatch> frankban: is there any way I can provide my current GUI branch (which is on launchpad) to my local GUI charm?
<hatch> the path is lp:~hatch/juju-gui/close-inspector-1228410
<hatch> when I Set the juju-gui-source it appears to work....but doesn't :)
<gary_poster> hatch it takes about 10 minutes to build
<gary_poster> and wfm as of last week
<frankban> hatch: it should work, yeah, you have to be patient
<hatch> ok so while it's building the 'old' GUI is still functional? (I reloaded and everything is back to normal)
<gary_poster> yes
<hatch> ahh ok - so I wonder how we can indicate that something is happening
<luca__> gary_poster: in the inspector the typeface seems to be wrong, it's bolder than the visuals.
<hatch> Juju nor the GUI has any indication that anything is happening
<frankban> hatch: juju ssh juju-gui/0 tailf /var/log/juju/unit-juju-gui-0.log
<gary_poster> hatch, yeah juju doesn't give us the visibility.  It's where the log idea came from--letting charms say what files should be exposed
<gary_poster> luca__, is this a regression?
<luca__> gary_poster: don't think so, though I've only just noticed it
<hatch> Hmm I think I have an issue with my local setup juju ssh juju-gui/0 -e local throws error: environment has no access-key or secret-key
<gary_poster> luca__, ack.  Could you shoot huw an email with details, cc'ing peeps?  I don't see it on the face of it, but I'm sure he will if you point him in the right direction
<luca__> gary_poster: sure, will do
<frankban> hatch: try to put "-e local" after "ssh"
<gary_poster> thanks luca__ 
<hatch> frankban: same error - typically I add the -e local to stop this error
<hatch> lemme check my yaml file
<frankban> hatch: anyway, with "juju switch" you can avoid passing -e each time
<hatch> hmm I definitely have an admin-secret
<frankban> hatch: you should be able to just ssh into the juju-gui lxc, user ubuntu
<hatch> frankban: when I try that it says Permission denied (publickey).
<frankban> weird, what command are you using?
<hatch> I just tried to ssh into the ip of the machine
<frankban> user ubuntu?
<frankban> hatch: ^^^
<hatch> oh darn I typo'd
<hatch> haha woops
<frankban> you wrote redhat?
<hatch> lol
<hatch> ubnutu
<frankban> guihelp: anyone available for one QA + one review of https://codereview.appspot.com/13900044 ?
<gary_poster> frankban, on it
<frankban> thanks gary_poster 
<Makyo> jujugui call in 10
<hatch> ok now I can say it definitely did not work
<hatch> I'll try from the console see if that triggers it
<frankban> hatch: oh, you changed the juju-gui-source from the GUI?
<frankban> hatch: if so, that's the same bug you reported for juju-gui-debug. changing options does not work at all in juju-core
<hatch> doh!
<hatch> :)
<frankban> :-)
<hatch> now it looks like it's running
<frankban> gary_poster: hum... I am reconsidering my decision to switch to ServiceUpdate: using that we no longer support older juju-core releases... If that's a problem, I have no problem quickly set up another branch that just fixes ServiceSet
<gary_poster> frankban, ack, we can talk after call
<gary_poster> jujugui call in 2
<bac> oh
<hatch> change the setting in the console.....watch it change in the gui....oh I love it
<hatch> gary_poster: while I wait for these things to spin up - is there another task you'd like me on?
<gary_poster> hatch on call, will thank after
<hatch> sounds good
<gary_poster> hatch how much time do you have do you think?
<gary_poster> hey luca__ do you have a few minutes to talk about bug 1229215?
<_mup_> Bug #1229215: Confusing unit retry/resolve UX <juju-gui:Triaged> <https://launchpad.net/bugs/1229215>
<gary_poster> luca nm I have a call :-P
<gary_poster> luca__, I will shoot you a note
<luca__> gary_poster: ok, Jamie is finalising all of the buttons in the GUI at the moment
<hatch> gary_poster: sorry missed the ding - well I can start on anything - if this QA passes then i'll be ready to propose
<luca__> gary_poster: so that will fix most of that issue
<hatch> umm I resolved a service in error and it destroyed the service?
<gary_poster> luca__, oh ok cool.  will that include confirmation messages for removing and resolving?  If so, I have some input on text for the confirmation dialog in the error removal case.  basically, we need to clarify that we are resolving the error and removing the unit, so people familiar with juju CLI are not too surprised
<gary_poster> hatch that typically means that you  tried to remove it first
<gary_poster> juju core waits until the error is resolved
<hatch> which I did...:D
<hatch> haha
<gary_poster> which is exactly what I was talking about and one of the points to the bug I mentioned :-)
<luca__> gary_poster: I didn't know we needed confirmation messages for those buttons, so it won't include them but if you send us more information we can look at it.
<gary_poster> luca__, ack.  I'll state as problems rather than solutions.
<hatch> benji: did you see the ci failure....very odd....
<benji> hatch: hmm, no; looking now
<benji> hatch: yeah, that is very odd
<gary_poster> luca__, sent email with details
<gary_poster> hatch ask benji if there is a bundle task you can take.  bundle detail stub view looks good to me on the face of it, and then you can follow up with integrating Ben's bundle visualization, but check with benji
<hatch> ohhhhh benji iiiiiiiiiiiiiii
<benji> yep, bundle detail stub view would be a good one
<hatch> are there any bundles in the charm store?
<hatch> I know very little of the bundle stuff so far
<hatch> been on inspector duty for a while :)
<gary_poster> yes, two at least.  search in manage for "bac"
<gary_poster> http://manage.jujucharms.com/~bac/bundle/wiki/wiki
<gary_poster> the other I know about: http://manage.jujucharms.com/~abentley/bundle/wiki-bundle/wiki
<gary_poster> sorry for all the pinging, everyone
<hatch> :)
<hatch> thanks
<hatch> *sigh* the qa failed
 * benji wonders where bac went.
<hatch> ok I think I have a fix landed - now onto the bundle stuff
<hatch> gary_poster: I was thinking when the GUI looses connection we should highlight the background of the canvas red or something so that they know that they are no longer receiving updates
<gary_poster> hatch, +1, file a bug
<hatch> cool will do
<hatch> luca__: https://bugs.launchpad.net/juju-gui/+bug/1230410 to keep in mind :)
<_mup_> Bug #1230410: There is no indication in the GUI when the user looses connection to Juju <juju-gui:New> <https://launchpad.net/bugs/1230410>
<hatch> benji: do we have UX as to what this detail page is supposed to look like?
<benji> hatch: not that I am aware of, your current card is simply to create a stand-in
<hatch> gotcha
<benji> I wish we would move assets out of app so my greps won't return stray hits from minimized third-party code all on one long line.
<hatch> benji: grep harder!
<benji> heh
<hatch> benji: ok so I've got a new dev branch here now how do I get the bundles to show up in the 'build' list ?
<hatch> build charm list that is
<benji> hatch: you can't; not yet at least
<hatch> oh - ok so with no data, and no design - what exactly am I supposed to write ;)
<benji> you'll either have to hack up some test data to be able to see the views in-browser or do test-driven development
<hatch> gotcha  :)
<hatch> how far away are we from getting them in the search results?
<frankban> gary_poster: here is the new MP: https://codereview.appspot.com/13917043
<benji> hatch: bac is working on a card which is a prerequisite of getting them in the search results
<hatch> oh ok cool
<hatch> so I should be able to make a json query to manage to get the meta data though right?
<gary_poster> frankban, ack will run with it.  thank you!
<hatch> bcsaller: have a second for a quick chat about deltas?
<bcsaller> hatch: sure
<hatch> calling
<hatch> https://plus.google.com/hangouts/_/64aa4ab508ffc6cd26933070e433ddac3a5248de?hl=en
<Makyo> gary_poster, ping
<gary_poster> yeah hey Makyo coming
<Makyo> Cool, np
<hatch> bcsaller: we had a huge delay haha
<hatch> I didn't notice until the end...lol
<bcsaller> hatch: who knows what I agreed to in that case 
<hatch> rofl
<hatch> gary_poster: in hangout, ready whenever
<frankban> bac: I updated the charm branch and re-proposed, you can do the QA when you want
<hatch> bcsaller: so the decision was that we will flag off of the 'life' attribute and when it changes to dying then destroy the inspector/menu instead of keeping it around and having a dying state
<hatch> jujugui anyone around who can QA on juju-core ? https://codereview.appspot.com/13938043/
<hatch> does anyone know how to make a json request for bundle data?
<hatch> https://manage.jujucharms.com/api/3/bundle/precise/wiki
<hatch> I would have assumed that?
<hatch> but no luck
<hatch> ahh the url in the source is wrong but I found it
<hatch> http://manage.jujucharms.com/api/3/bundle/~bac/wiki/wiki
<bac> hatch: where is the url wrong in the source?
<hatch> bundle.js:22
<hatch> ^ bac
<hatch> I've updated it in my local branch
<hatch> I'm just trying to navigate through this browser code...I'm very lost - lol
<bac> http://manage.jujucharms.com/api/3/bundle/~bac/wiki/wiki works for me
<hatch> yeah that's the proper url
<hatch> that's not what's in the source
<hatch> :)
<bac> well http://staging.jujucharms.com/api/3/bundle/~bac/wiki/wiki would work if it were answering
<hatch> ohh
<hatch> :)
<bac> not sure why staging is donw
<bac> down
<bac> will look in a bit
<hatch> sure np
<huwshimi> Morning
#juju-gui 2013-09-26
<hatch> morning huwshimi
<hatch> "bold all the things!"
<gary_poster> morning huwshimi :-)
<hatch> http://orteil.dashnet.org/cookieclicker/
 * hatch is a pusher
<rick_h_> hmm, won't load here. Wifi is pretty bad
<hatch> rick_h_: oh you're missing it, it's the perfect game for on vacation :D
<rick_h_> playing with my moto x :P
<hatch> OOooo you went with the x hey?
<hatch> how is it?
<rick_h_> nice, really quick. Love the small touches
<hatch> does that run stock android?
<rick_h_> pick it up and it goes to the unlock screen vs waiting for you to hit the power button
<hatch> oh very cool
<rick_h_> auto unlocks when my pebble is attached so no pin code
<rick_h_> it's pretty stock. The notification thingy and the always listening for google now are non-stock currently
<rick_h_> but I'd expect those to hit 4.4 tbh
<rick_h_> picking up the DC metro/zoo apps for tomorow
<rick_h_> we live in the future heh
<hatch> heh always listening....ehhh
<hatch> *caugh*no-privacy*caugh* :P
<rick_h_> yea, getting the griffin car dock. Full hands free use with it
<rick_h_> since you can wake it from sleep with you voice, tell it to write out a text, done
<hatch> that is pretty cool
<hatch> I'm paranoid though that it would be recording me :)
<rick_h_> yea, oh well. They can hear me tell the wife I'm on my way :P
<hatch> lol
<hatch> good point
<hatch> rick_h_: while I have you here, can you tell me what actually shows the Tokens? I see the token-container.js but I don't see what is actually showing each child
<rick_h_> hatch: it uses the YUI parent/child widget relationship. 
<rick_h_> hatch: there are Views that create the TokenContainers based on a bunch of data
<rick_h_> and the TokenContainers use YUI to create the Tokens since they're the child widget
<rick_h_> hatch: so the container.items is the list of data for Tokens
<hatch> so are they all shown by default?
<hatch> and hideSomeChildren hides the specific ones?
<rick_h_> hatch: no, the container gets called with a limit to show by default
<rick_h_> hatch: well yea, they're all rendered and the container controls how many are visible (not display: none;) and the events for show/hide the rest
<hatch> right, but I can't find what actually renders each child
<hatch> ohh ok so they are all visible, then we hide the extras
<rick_h_> hatch: right, it's behind the scenes in the container. Once the container is rendered, YUI renders the tokens
<rick_h_> as the children of the parent widget
<hatch> I didn't know that the parent auto-rendered the children
<hatch> good to know
<hatch> thanks
<rick_h_> http://yuilibrary.com/yui/docs/api/files/widget-parent_js_Widget-Parent.js.html#l713 maybe? when the child is added it auto renders
<hatch> I haven't used widgetparent/child in like....ohhhh 3 years
<hatch> haha
<rick_h_> hatch: yea, it was a really nice fit for our needs though
<rick_h_> made a lot of sense and helped with the container/token split
<rick_h_> some things do toksn on their own, related charms, autocomplete suggestions for instance
<hatch> yeah I was actually thinking of a refactor for this area last night
<hatch> was thinking about things like rendering just the markup and then enhancing it
<hatch> wondering if we could do it simpler
<rick_h_> careful, what's there is nice/works imo. I don't want to viewlet it :P
<hatch> this is assuming fullscreen goes away of course
<hatch> oh yeah I'm not actually proposing we do it
<hatch> just thinking about it
<hatch> :)
<rick_h_> ok, well I'm all for chatting on things. I was hoping to be more involved when bundles came along but alas
<hatch> did you see the email thread that huwshimi started about the animations?
<hatch> I figured you would have some input on it and my response
<rick_h_> I kind of saw it. I figure I don't have the ime to give a great response atm. Animations is involved. :/ and it seemed limited to the tabs themselves which should be easier to deal with
<hatch> yeah basically it involved a refactor haha
<rick_h_> animations anywhere will. Animations require both bits to be visible at once and nothing we've done works that way. tab widget, browser Y.Views, etc
<hatch> right
<rick_h_> it needs an overseer to handle all loading/unloading of bits
<rick_h_> and that needs to get baked one layer above the things you want to animate
<rick_h_> refactor time
<hatch> you're not doing anything right now...get at it :P
<rick_h_> hah, I'm planning a trip into washington DC right now :P
<hatch> with your phone that listens to you no need - they will already know you're coming
<hatch> haha
<rick_h_> hah, well they're not going to give me a transit plan when I show up at the bus station tomorrow
<rick_h_> even if they already know what I want to do
<hatch> give it time....give it time
<rick_h_> lol
<rick_h_> night, time to head in and start locking things down. Getting chilly out here
<hatch> alrighty, have a good one
<gary_poster> hey frankban.  I struggled against local provider issues all afternoon when I was not on calls, so I never was able to qa.  apparently local on saucy might have issues.  I gave Tim details.  I will try one more time this morning on local and then will go to ec2 while on calls.  If you can find someone in a better position to qa then you are welcome to. :-)
<gary_poster> But, sorry. :-/
<frankban> gary_poster: np, fwiw lxc works for me using revno 1750 of juju-core. but I am on raring
<frankban> I also have problems with trunk, i.e. 1229286
<frankban> bug 1229286
<_mup_> Bug #1229286: debug-log and boolean options are broken in trunk <juju-core:New> <https://launchpad.net/bugs/1229286>
<gary_poster> frankban, I am on call with juju mgrs right now.  I just raised that one to tim and william fwiw
<frankban> gary_poster: cool thanks
<gary_poster> frankban, config issue looks like bug.  Wm is on it, I think.  Tim says log issue is as designed.  He will write email about it tomorow but he gave this summary: "effectively our logging is now more "productiony"
<gary_poster> you can set the log level when you bootstrap, and that is used for the environment
<gary_poster> or set it later using "juju set-env""
<frankban> gary_poster: yes, he explained the same in #juju-dev
<gary_poster> frankban, oh! I see, cool :-)
<gary_poster> frankban, with you soon--2 or 3 more minutes late, sorry
<frankban> gary_poster: np
<bac> hey gary_poster, staging.jc.com is dead,dead,dead.  there is no good reason for that, right?
<gary_poster> correct bac
<bac> gary_poster: cool.  i'll try go to get it alive again.  its death looks somewhat premediated: http://paste.ubuntu.com/6158533/
<gary_poster> bac thank you
<hatch> frankban: thanks a lot for the QA
<frankban> hatch: welcome
<bac> hi abentley, do you know why staging would be shutdown?  i've been trying to deploy it using the staging-tools scripts but not having any luck.
<abentley> bac: Yes.  See #is topic.  OTP
<bac> thanks
<bac> abentley: please ping me when you are free.
<gary_poster> hey hatch, you could merge/include huw's https://codereview.appspot.com/13954043/ in your bundle detail page work if you want, or we can do it separately later
<gary_poster> hey luca__ .  what's status of approved bundle token ux/visuals?  if we can get ux at least no later than today that would be great.  is that possible?
<hatch> frankban: so I had no idea that services can go into an error state on destroy
<hatch> ohh nm I missread your qa
<frankban> hatch: the problem I highlighted is for services already in an error state, but I confirm a service can go in an error state also on destroy (i.e. if the stop hook exits with an error)
<frankban> hatch: in both cases the service will be dying, but not removed
<abentley> bac: free now.
<hatch> gary_poster: mind taking a peek at frankban's QA of my branch when you have a second - I think we'll need to switch to the original plan
<gary_poster> on call but will in a bit hatch
<luca__> gary_poster: are you after the bundle token?
<gary_poster> luca__, yeah
<luca__> gary_poster: It's been signed off, I'll send it through in 10 mins
<gary_poster> cool ty
<frankban> guihelp: how do you dismiss a ghost service block? The cancel button in the ghost inspector doesn't work for me in https://jujucharms.com/sidebar/ : it closes the inspector but the service block is still there.
<hatch> frankban: destroy the service
<hatch> gary_poster: if you want me to try juju on my Saucy VM I can try and give it some more ram and see if it works
<gary_poster> hatch cool.  if you can unblock frankban by qa'ing his branch that would be fab
<hatch> yeah I can do that
<frankban> hatch: thanks
<frankban> hatch: locally, with make devel, destroying a ghost gives me a weird error notification, and leaves the ghost block
<hatch> with my branch?
<frankban> hatch: no, in trunk
<frankban> Error destroying service: Service name: 55274347$
<hatch> ok that makes sense....
<hatch> but it shouldn't be erroring
<hatch> can you create a ticket plz
<frankban> hatch: sure
<hatch> and I'll see what's up after QA'ing your branch
<frankban> hatch: is this something specific to the go sandbox, or to the go env in general?
<hatch> frankban: it's a symptom of switching to a single service model - ghosts are given a random unique id so they -cannot- clash with anything potentially returned from juju-core
<hatch> and so that you can have multiple ghosts with the same name
<hatch> as to why it can't destroy it - I have no idea
<frankban> hatch: ok, but it's a regression, in jujucharms works, in comingsoon is broken
<hatch> yeah it was done after release
<hatch> it's definitely not supposed to throw an error :)
<frankban> cool
<frankban> hatch: filed bug 1231487
<_mup_> Bug #1231487: Error while trying to destroy a ghost service from the inspector <juju-gui:Triaged> <https://launchpad.net/bugs/1231487>
<hatch> thanks!
<luca__> gary_poster: just sent you the Bundle token
<gary_poster> looking while on call luca__ ;-) thank you!
<benji> adeuring: hi, I have a question about charmworld's elastic search.  Where in charmworld do we configure ES?  Is there an initialization script or something similar?  I ask because we're considering enabling n-gram tokenization to get better substring searching.
<gary_poster> oh luca__ I had feedback on your email from yesterday that I didn't get around to sending :-(
<gary_poster> not a big chagnge but will right it out,  in short, only bundle yaml is pertinent for the functionality that you are describing
<hatch> frankban: I can't seem to get your branch to save any config changes - do I need to be on a certain charm version?
<frankban> hatch: what version of juju-core are you using?
<hatch> cs:precise/juju-gui-76
<adeuring> benji: We have right now just two config parameters: number of shards and number of replicas; that's defined in the .ini file-
<hatch> umm sec
<hatch> 1.14.1-precise-amd64
<adeuring> benji: additionally, we should define the ES cluster name, but that's done vie "juju config"
<frankban> hatch: weird. have you switched the charm to my branch?
<hatch> yep it says it's your branch
<hatch> oh wait a second....
<benji> adeuring: ok, I saw those but wondered if there were more.  If we were to want to enable n-gram tokenization how do you suggest that would work?  I assume we would need both to set the configuration on a new deployment and a script to reindex the existing production ES.
<hatch> frankban: ok when I change the setting 'juju-gui-console-enabled' in the GUI it clears out every config field
<hatch> then on refresh it's now saved
<hatch> so yes it works....but it breaks the GUI
<hatch> I'll reply on the review
<gary_poster> luca__, is that bundle icon finalized?  if so, could we have the svg?
<luca__> gary_poster: sure
<gary_poster> thanks luca__ 
<frankban> hatch: I'm not sure I understood the problem
<adeuring> benji:  I am not very familiar with ES myself, but I assume that you need to create a new index with the right parameters. That would probably be similar to the put_mapping() call, which is already a sort of configuration (in addition to the shards/replicas) too.
<adeuring> benji: and the best mechanism there is to run an "exodus"
<benji> ok, that makes sense
<hatch> frankban: responded with repro steps in the review
<frankban> hatch: pl
<frankban> ok even
<hatch> :)
<luca__> gary_poster: sent it over
<gary_poster> luca__, button states & bundle tokens look great.  I thik we need one other bundle state for inspector notifications list button: "in progress" or something like that.  If I click on "Resolve" or similar it may take a few (10?) seconds to actually complete
<adeuring> benji: migration 019 is an example -- that's a really trivial exodus (in the sense that the exodus machinery does all the tricky stuff but you don't have to care about it)
<benji> adeuring: I thought "migration" and "exodus" were different things.
<gary_poster> luca__, thanks for icon!
<hatch> luca__: we will need assets for those checkbox states FYI
<luca__> gary_poster: can you email me about the "in progress" thing, then I can just pass it on the jamie.
<hatch> the little ones for the unit list that is
<gary_poster> luca__, will do thx
<hatch> and nice bundle icon :)
<hatch> icon/token
<gary_poster> hatch do we have/need the orange "recommended" triangle, do you know?
<hatch> we can do it in css
<luca__> hatch: the checkboxes are in the document
<hatch> luca__: document?
<adeuring> benji: the exodus  is a migrations, where you can apply all changes to new mongoDB collections/ES indexes, while the old data is still in use.
<benji> hmm, I must not understand something about the mechanism
<luca__> hatch: in the button states document
<gary_poster> luca__, the doc is a png though
<luca__> gary_poster: oh! right, assets, duh
<luca__> gary_poster: haha
<gary_poster> :-)
<luca__> gary_poster: hatch sorry
<hatch> :) gotcha
<hatch> np
<gary_poster> np :-)
<luca__> hatch: how do you want them supplied?
<luca__> hatch: I thought it was just code
<hatch> silver platter
<hatch> :P
<luca__> :P
<hatch> nah, we can't actually style checkboxes cross browser reliably
<luca__> no cushion?
<hatch> I MIGHT be able to re-create those with markup/css
<frankban> hatch: could you please try to deploy another charm and check if the behavior you described happens also there?
<luca__> hatch: ok, if you need them just email Jamie (cc me)
<hatch> frankban: sure trying now
<frankban> hatch: thanks
<hatch> luca__: ok sure thanks
<hatch> luca__: could we get some colour codes?
<frankban> hatch: thanks
<frankban> ops
<gary_poster> hatch on calls calls calls, but saw frankban's qa of your branch.  we talked about this case.  I'll ping you asap to talk through.
<hatch> gary_poster: yep np
<hatch> I'm not -doing nothing- yet :D
<hatch> at that point I'll get antsy
<luca__> hatch: sure, we created the document to make it easy to catalogue all of this so we can expand it and improve it
<hatch> haha
<gary_poster> :-) k
<hatch> frankban: deploying mediawiki - it'll be probably 10mins or so
<gary_poster> luca__, yes, +1 and thank your that btw.  the catalog is a great approach I think
<hatch> yeah I really like the idea of the overview in a single place
<gary_poster> "thank your that" == "thank you for that" :-P
<frankban> hatch: but you can try changing options even when it's pending
<hatch> frankban: yup, change the option and they dissapear
<hatch> I can screenshare if you like?
<frankban> hatch: I am trying to dupe
<hatch> luca__: are my eyes playing tricks or is the 'Notificatios list button' pre-depressed?
<hatch> man I really like the new tokens....
<gary_poster> hatch that's the suru style
<gary_poster> you depress somethat's already depressed.  you really hit em when they are down...
<hatch> lol!!
<frankban> hatch: reproduced, but I think it's not my branch. this is another bug, I guess we do not handle correctly delta streams in the inspector
<hatch> well as soon as I click save it wipes the rest out
<hatch> I'm pretty sure this didn't happen before
<hatch> maybe because it was failing
<hatch> haha
<hatch> could you take a look to see if it was your branch which caused it?
<hatch> or if it should be a follow-up
<hatch> I'm ok if it's going to be a follow-up, I'd just like to not introduce a bug if possible :)
<frankban> hatch: my branch just changes a parameter in an API call in the env layer: it does not interact with the form in any way
<hatch> right - but I 'think' the form uses the old params to fetch the config options
<hatch> so if they are empty - then the fields will be empty
<hatch> the databinding would have updated causing it to wipe clean
<frankban> hatch: juju sends back something like {"RequestId":5,"Response":{"Deltas":[["service","change",{"Name":"mediawiki","Exposed":false,"CharmURL":"cs:precise/mediawiki-10","Life":"alive","MinUnits":0,"Constraints":{},"Config":{"name":"asd"}}]]}}
<frankban> hatch: so Config is just {"name":"asd"}, and my first impression is that the i the handler the other default settings are ignored.
<hatch> You need to refresh the GUI to get the configs back
<frankban> hatch: the machinery to fetch the settings is not changed in my branch
<hatch> yeah - I'm saying it might need to be
<hatch> if you wait long enough the settings come back
<hatch> on the next delta i'd presume
<hatch>  frankban might be https://codereview.appspot.com/13917043/diff/1/app/store/env/go.js ln 1027
<hatch> because the bindings are listening on 'config'
<frankban> hatch: hum, perhaps inspector.js line 755?
<frankban> hatch: ISTM it sets service.config to only the new values
<hatch> ahhh so it's responsing with only the changed values and then we are clearing out the model and setting it to only that
<hatch> right
<hatch> ok definitely not from your branch
<hatch> then
<hatch> :)
<frankban> hatch: so, it was pre-existent, if you agree, I'll land this and work on a fix for this new bug
<hatch> done and done
<frankban> hatch: thanks
<frankban> great QA, I missed that
<hatch> frankban: re your review of my branch - if a user in the console destroys a service which then goes into an error state you would expect the inspector to stay open as long as the icon is on the canvas, correct?
<hatch> so we need to listen to lifeChange and being removed and then check to see if it has any errors on its units
<frankban> hatch: yes
<hatch> poop
<hatch> :)
<hatch> thanks
<frankban> hatch: speaking of poop, utils.removeUnchangedConfigOptions modifies the config in place
<frankban> and then returns the config
<frankban> leaving on you that oppressive sense of bitterness
<hatch> lol
<frankban> hatch: and that's the real emptied inputs problem.
<hatch> should that method not only be called when sending the values to the server?
<hatch> ohh I see what you're saying
<frankban> hatch: yes, but it modifies an object in place, and that object is then propagated in the callback.
<hatch> right right
<hatch> should we maybe 'mix' the incoming deltas in as well?
<hatch> this definitely needs to be fixed
<hatch> but should we mix the two also?
<Makyo> jujugui call in 10 kanban now
<frankban> hatch: I think we have 2 easy fixes: 1) do not modify in place the new config (so that the callback will receive the whole config object) or 2) mix the current config and the new values in the callback
<hatch> 3) both
<hatch> :P
<hatch> honestly though 1) definitely needs to be done
<hatch> 2) if you wanted
<hatch> not sure if doing #2 will gain us anything after #1 is fixed
<frankban> hatch: I am ok with modify objects in place if that's documented and the function returns undefined. I am confused instead when a function changes an object in place AND returns the changed object
<frankban> hatch: and maybe there is some value in the callback receiving only the new values
<hatch> frankban: yeah that happens a lot in javascript apps ive found
<hatch> maybe
<hatch> I'll leave the implementation up to you
<frankban> hatch: ok thanks
<gary_poster> ugh, I have meeting ennui :-)
<hatch> I just googled it
<hatch> you used that word wrong
<hatch> lol
<gary_poster> hatch, in what way?
<hatch> ok maybe not
<hatch> I found another example
<hatch> dammmnnnn youuuuuuu
<gary_poster> lol.  meeting-induced ennui might be more accurate, but I think what I said is close enough
<gary_poster> jujugui call in 2
<hatch> haha yes it is
<bac> benji: the charmworld new lander works just like the old lander
<benji> heh, k
<hatch> Makyo: https://plus.google.com/hangouts/_/f3152089747387222abf5a2f310ec7fdf4473cb6?authuser=1
<hatch> I wonder if that's an android thing - if you use up 95% of the 'disk space' it gets very very slow
<hatch> stepping out for about 20
<hatch> bbl
<bac> hi bcsaller, can i ask you about a change you made to makeFakeStore?
<bcsaller> yeah, let me pull it up
<bcsaller> ok, whats up?
<bac> you added the cache parameter, and it is used in one test suite.  but, looking at it i don't see it ever used.
<bac> bcsaller: i'm not sure what you intended.  removing it doesn't break any tests...
<bcsaller> the actual store charm methods take a cache
<bac> bcsaller: what i wrote was confusing.  i mean one call site passes in a cache but i don't see makeFakeStore using it
<bcsaller> the idea is only to accumulate the charms into a model list, tests don't have such a list to keep things for the most part
<bcsaller> it might be good to do all the imports on load though with a real model list and have fakestore resolve them from there to speed up the tests
<hatch> yes!!
<hatch> :)
<bac> bcsaller: yeah but in http://paste.ubuntu.com/6159694/ the cache in line 1 is not the same one used in 3-19.
<bac> so i think i see your intent but (unless i'm confused) don't think it got implemented correctly
<bcsaller> bac: have you looked at app/store/charm.js:202?
<bac> bcsaller: yes
<bcsaller> I think it was just to mimic the actual call, if we never use it we can remove it from the mock, but I'd have thought we did
<bac> bcsaller: if i rewrite makeFakeStore like http://paste.ubuntu.com/6159728/ i think it is clearer that the param is never used
<bac> bcsaller: i'm happy to fix it to do what you intended...but i'm not sure how.
<bcsaller> ahh, I didn't see what you meant, I'm being dense, I see it now
<bcsaller> yeah, I'm not sure what the best thing to do there is, if the top level cache was passed in we could update that (after changing that argument name) and adding it to that list as well 
<bcsaller> or just take it out
<bcsaller> the real fix would be to reduce the IO in there when cached_charms are computed
<bac> bcsaller: ok, thanks
<bcsaller> bac: sorry I wasn't more helpful. but I can make changes as a fly by on the branch I'm working on now if you'd rather
<bac> bcsaller: maybe just paste a snippet of what you're thinking.  i need to change the signature too, so i'd rather do it in my branch
<Makyo> jujugui Anyone else (bac, I think?) having issues with `make check` running into a 404 trying to get /login/data/wordpress.json on the test-debug step?
<Makyo> If so, I think I found a solution but...I don't understand it.
<hatch> I'm not, but interested to hear
<bcsaller> bac: well for now removing the first unused cache should be enough based on what you said. 
<bac> ok
<Makyo> check runs test-prod test-debug in that order.  If I swap them, I can't reproduce the error.
<Makyo> prerequisite rules are run synchronously, correct?
<hatch> correct
<hatch> and shouldn't have any effect on eachother
<Makyo> Exactly.
<hatch> benji: will the ngram tokenizer give us fuzzy style searching?
<Makyo> I don't get the error if I `make test-prod; make test-debug`.
<bac> hatch, you want fuzzy logic?  buy a rice cooker.
<hatch> bac: shroden cooker you mean - you don't know if it's done until you look at it
<Makyo> Now it's happening on test-prod.  I hate everything.
<benji> hatch: [sorry, I was AFK] It depends on what you mean by "fuzzy".
<hatch> benji: package name: foobarbaz search: bar
<hatch> would match
<benji> yep
<hatch> SHIP IT!
<benji> :)
<benji> bac: what is the status of v3 API bundle output?  I'm looking for something to do and was considering one of the wire-it-up cards.
<bac> benji: coming along but i got sidetracked a bit.  something end of day i hope.
<benji> k
<hatch> I don't know who fixed 'make devel' but it's so fast now
<hatch> +1 whoever that was
<hatch> in huws notification branch he removed the events but didn't remove the methods which those events call
<hatch> does anyone know if he plans to do that in a followup?
<hatch> jujugui ^
<gary_poster> hatch, he added a card to high kanban group that looks pertinent
<gary_poster> "Remove remaining notification page(s) and code"
<hatch> ohh woops I missed that
<hatch> thanks
<hatch> qa'd ok so I'm going to land
<hatch> anyone else getting a bunch of old RT emails?
<gary_poster> not i
 * Makyo fails at proposing for the umpteenth time, tries from other computer.
<hatch> ok so my latest branch has failed on juju-core with a hook failed error
<hatch> how should I debug this?
<hatch> ssh into the machine and read the juju log?
<hatch> got it
<hatch> man I wish juju would tell you if it's doing something
<Makyo> There's debug-log for that, right?  And a ticket in for hook logs in debug-log, I think...
<hatch> well I was thinking status should tell you if there are any active hooks on a service
<hatch> service/machine
<hatch> somehow my gui instance is stuck on dying
<hatch> juju pull-the-plug juju-gui --forceful
<hatch> :D
<gary_poster> :-)
<Makyo> Aaaargh, everything works from the branch dir, just not the lightweight checkout.
<hatch> Makyo: I'll review your branch
<hatch> waiting for core-y stuff
<Makyo> hatch, cool, thanks.
<gary_poster> ok, I need to stop now.  be back in 3 hours or so
<hatch> Makyo: review done - have some q's before QA
<Makyo> hatch, first question - it does.  Visibility is bound to charmChanged.
<hatch> oh ok - I didn't see that, must have been from a previous branch?
<Makyo> hatch, second question - Good point.  Will think about it.
<hatch> cool thanks
<Makyo> hatch, What about the instance of someone clicking close right as the 'service was upgraded' message comes in?  If they open the inspector again to read the message, it won't be there.  Since, in this case, that link doesn't do anything but dismiss the message, it seems a small thing to just leave it there.
<Makyo> hatch, wording isn't final, fyi, just a functional branch until we have bandwidth from design to nail that down.
<hatch> right but won't the configChanged attribute still be true?
<Makyo> configChanged?
<hatch> er
<Makyo> hatch, charmChanged?
<hatch> charmChanged
<hatch> yeah
<Makyo> hatch, Yes, but the only reason for that attribute is to control the visibility of that message.
<hatch> ohh - so then can I propose it be renamed?
<hatch> I assumed it had greater purpose
<Makyo> You can propose, but that's exactly what has happened - the charm for the service has been changed.  If you can think of something better that still gets that idea across, be my guest.
<Makyo> That is, if we need to rely on it later and it's something like "showThisStupidMessage", I'll probably veto :)
<hatch> ok so....
<hatch> if userX upgrades, then closes the inspector via the X then never goes back
<hatch> the model will be in 'charmChanged' true state
<hatch> then what happens if a new charm comes available?
<Makyo> If they then open the inspector, they'll see the message "service has been upgraded to service-n", and below that they'll see "a new upgrade is available", which will be charm-(n+1)
<Makyo> If they haven't closed their browser, etc. etc.
<hatch> right
<hatch> right
<hatch> yeah ok I guess that's not horrible
<Makyo> Buuuuut that won't ever happen.
<Makyo> So nevermind.
<Makyo> Only if way that UX would show is if they downgraded, or if they upgraded to not-the-latest.
<hatch> or a new charm was uploaded?
<Makyo> No, because we don't receive events for that.
<Makyo> We only ever request data from charm store - we never receive it un-asked-for.
<Makyo> And we only ever do that on the service-add delta, which only happens once.
<hatch> ahh ok gotcha
<hatch> I suppose as a user I might think that closing and re-opening the inspector is akin to refreshing
<hatch> but maybe not
<hatch> ok code LGTM
<hatch> will qa soon :)
<Makyo> Yeah, that's a question we already have for design; I just picked random words :)
<hatch> lol
<hatch> boat starfish desk credit card -refresh- bottle window paint sign
<hatch> I think it gets the point across
<Makyo> Working on  a project for a friend right now that pops up random bits of idea stubs that you can string together into an idea as a prompt for creative writing, actually, so basically that :D
<Makyo> Well, not RIGHT now.
<hatch> lol
<hatch> Makyo: no luck on the QA - hitting refresh wipes out the config
<hatch> so it's empty
<Makyo> As in just a black rectangle, or as in the fields are empty?
<Makyo> Because I had the black rectangle problem earlier on.
<hatch> well everything else is there
<Makyo> YEah, just config I mean
<hatch> and the template renders the proper markup
<hatch> ohh yeah
<hatch> I see the issue
<hatch> I'll reply in review
<Makyo> Okay.  Works for me, so be specific.
<hatch> really? it shouldn't :)
<Makyo> You still haven't even answered my question, so I'm having to guess what you mean. :P
<hatch> oh sorry
<hatch> the viewlet is empty
<Makyo> It's not for me.
<Makyo> I'm going through the diff now to make sure it's not a problem from having to lbox from the branch, rather than the checkout.
<hatch> ahh ok - yeah because it's definitely broken here with and w/o the flag in the url
<hatch> and reading the code it definitely shouldn't work
<Makyo> Huh, seems to match what I have.  Curious as to why it works for me but not for you.
<hatch> yeah - if you see the render method of the viewlet you can see why it 'shouldn't work
<hatch> because it's creating a new container and rendering into that
<hatch> which is never attached to the DOM
<Makyo> This is why we had the call :/
<Makyo> Why it works for me aside, what's the next step?
<Makyo> Calling show?
<hatch> if(!this.container) { Y.Node.create(this.templateWrapper); }
<hatch> line 85 of service-config.js
<hatch> I'll test that to see if it works here
<hatch> Makyo: yep that's the fix
<Makyo> Hell if I can test.
<hatch> bah although then the events are not bound properly
<hatch> for real - it's working for you?
<Makyo> Oh for pete's sake.
<Makyo> Yes.
<Makyo> I'm going for a walk.  This is a bit too much.
<hatch> sure - lemme know when you're back and I'll tell you the next steps
<hatch> Makyo: here is a diff which fixes the expanding textarea and blacking out issue: https://gist.github.com/hatched/6720366 I don't know where the code is attached which causes the 'cancel/save' butons to popup is attached
<bac> gary_poster: would you moderate my mailing list message and add my brad.crittenden address?
<bac> i think it gives you the option when approving
<gary_poster> bac done
<bac> ty
<bac> mail aliases seemed like a good idea
<bac> benji: i'll propose this branch in a little bit so it'll be ready for review first thing tomorrow
<benji> cool
<hatch> gary_poster: huwshimi call in 10?
<huwshimi> Morning
<hatch> morning
 * bcsaller goes to hide after posting the embarrassingly large https://codereview.appspot.com/13997043
<hatch> you...suck
<hatch> lol
<hatch> I GUESSS I'll do it
<bcsaller> ha, sorry
<bcsaller> owe you beer
<hatch> good thing we're going to CA, I hear they like beer there
<bcsaller> to be fair  38 files changed, 1293 insertions(+), 6413 deletions(-)
<bcsaller> mostly removes code
<hatch> before I start is there anywhere you think would bennefit from some reviwer notes?
<hatch> reviewer even
<bcsaller> I'll do a pass over the CR, but its mostly not so complex
<huwshimi> hatch: What url are we using today?
<huwshimi> (For the hangout)
<hatch> we use the ones in the calendar link
<hatch> it has a 'join this hangout' button
<hatch> I don't think gary_poster is around yet though
<bcsaller> hatch: there are notes now
<hatch> cool thanks
#juju-gui 2013-09-27
<hatch> bcsaller: hey if you're in - I am getting chunk missmatch on your code review
<bcsaller> hatch: on which file? When I self reviewed it things looked ok
<hatch> yeah that's the odd thing
<hatch> hah
<hatch> oh did you use the unified diffs?
<hatch> it's the side/side ones that are messed up
<bcsaller> very odd
<hatch> I can do the review on the diff itself no problem
<hatch> yeah, right?
<hatch> red on white is not the most contrasting colour however :)
<bcsaller> heh
<hatch> so how's your night?
<bcsaller> oh, off in the other room cooking dinner mostly :)
<bcsaller> what about you? why you still working?
<hatch> just checking in :)
<bac> benji: care to have a look at https://codereview.appspot.com/14036044
<bac>  ?
<gary_poster> bac, you need two or is one sufficient?
<benji> bac: sure
<bac> gary_poster: one is sufficient.  it is 422 lines but a lot of those are s/api/API/ in comments
<gary_poster> bac cool.  Why do we even need to filter things out in in transformResults?  What else is in the original result list?
<gary_poster> Maybe worth commentng the answer in case it is not obvious to others in the future
<gary_poster> but also I'm curious :-)
<bac> gary_poster: goodish question.
<bac> i'm not sure if that was originally there just to be super safe or if there are other things that we expect to be in that reply
<gary_poster> it seems like it used to filter out nundles, but we don't need to do that anymore
<gary_poster> bundles even
<bac> hey, i like nundles better.  or cundles, which is charms + bundles
<gary_poster> heh
<bac> gary_poster: i'll do some archeology and see when that filtering was addded
<gary_poster> cool bac thx
<frankban> guihelp: could anyone please review and QA https://codereview.appspot.com/14033043 ? thanks!
<gary_poster> frankban, on it
<frankban> gary_poster: thanks
<gary_poster> frankban, LGTM with trivials and QA ok
<gary_poster> luca__, hey.  Huw noted something about the new bundle icon for the token: "I forgot to mention that the icon asset supplied seems to be black instead of light grey as it is in the mockup. I've included it as is, but not sure why it is different."  We'll use the black, but if you want to give us a gray one, send it over. :-)
<luca__> gary_poster: ah, it's meant to be grey...
<gary_poster> luca__, cool.   send it over and I'll replace it in the branch
<frankban> gary_poster: thanks! getUnchanged... so I also started to name functions in reverse meaning :-/
<gary_poster> frankban, :-) an easy mistake to make in context.  Nice branch though.
<gary_poster> back in a few.  cat needs meds
<bac> thanks benji
<benji> my pleasure
<bac> benji: before i go digging, do you know anything about the filtering being done in that method?  was it there just to toss bundles?  gary was curious.
<bac> i mean if we really only expect charms and bundles now i could remove the screen
<benji> bac: yeah, I added the filtering because of the bundles.  +1 on just removing it
<bac> rt
<bac> gary_poster: ^^
<gary_poster> cool bac, benji, thx
 * benji notes to himself that he should have commented the code so that the question didn't have to be asked.
<bac> lots of saucy updates today
<gary_poster> frankban, interesting about Object.create(null).  thanks for info.  I may start doing as well, though I wish it were more concise
<frankban> gary_poster: yeah, a = {} is far more expressive and concise
<hatch> they are different
<hatch> Object.create(null) has null as a prototype
<hatch> whereas a = {} has Object.prototype as a prototype
<hatch> just FYI
<frankban> hatch: yes, {} == Object.create(Object.prototype), right?
<hatch> in modern browsers yep
<hatch> tbh I really have no idea why you would want to do Object.create(null)
<hatch> I'm really not sure when not having Object.prototype is a good idea
<hatch> but I'm totally open to ideas :)
<frankban> hatch: I did that in a branch currently in review
<hatch> ohh ok - why?
<hatch> any specific reason?
<frankban> hatch: pasting from the review comments: it seems to me more clean and lightweight in the cases you will use the result only as a "dict" data structure.
<hatch> ahhh I suppose there is a case to be made for that
<hatch> although it might be a micro optomization
<hatch> optimization even
<frankban> hatch: also being able to iterate over the object without having to do the hasOwnProperty dance is convenient sometimes imho
<hatch> this is true, this is true
<frankban> hatch: also intersting: http://www.devthought.com/2012/01/18/an-object-is-not-a-hash/ and http://jsperf.com/object-create-null-iteration/2
<hatch> so the 'props' on the perf are almost identical
<hatch> as are the emptys
<hatch> so there really isn't much of a perf gain
<hatch> although some interesting numbers on FF though
<frankban> hum, did not try with FF
<hatch> scroll down the page to the results
<hatch> you can see what others have done
<gary_poster> bah, firefox :-P :-)
<frankban> heh, if I read that correctly, FF is the only one where the literals are far faster
<gary_poster> right
<hatch> yep so that means you should always use literals because the perf hit on Chrome/Safari is minimal (at best) and way more performance on FF
<hatch> :P
<gary_poster> wellll
<gary_poster> disagree: optimization opportunity
<gary_poster> if you see a problem, or have an inner loop, sure
<gary_poster> but cleanliness of empty instance is pretty compelling IMO
<hatch> but it's a huge performance hit, not an opportunity for FF
<hatch> so you pick the best for everyone :)
<frankban> hatch: we might suppose that stats will change, Object.create(prototype) seems the new trend for OOP in js
<hatch> (i realize that I'm talking about 100ths of a ms here)
<hatch> I'm pretty curious as to where Google is going to go with Android development
<hatch> I see them switching to either Go or Dart at some point
<hatch> if they choose Dart, and if Dart lands in Chrome
<gary_poster> but it is not best for everyone.  point of other artickle is that empty instances have better semantics.  switching from better semantics of empty instance to better performance of {} is an optomization opportunity, if you as I do, prefer to code towards better semantics as a starting position
<hatch> that's going to push it's adoption rate huge
<hatch> oh I didn't read the article yet :)
<gary_poster> well, I only skimmed it ;-)
<gary_poster> I'm skeptical of Dart's chances myself
<hatch> I am pretty sure it's better at a technical level
<hatch> it's the adoption which will kill it
<hatch> or make it
<gary_poster> sure
<hatch> I think Go probably has a better chance of making it into Android
<hatch> if they are going to be moving away from Java - which I'm sure they have at least discussed
<gary_poster> Go has better broader mindshare it seems yeah.  Switching from Java?  ISTM that would be a huge disruption, but what do I know
<hatch> it would - but aren't they fighting Oracle all the time in the courts about it
<hatch> Java - that is
<gary_poster> yeah, but without Java wouldn't it be essentially a new OS?
<hatch> AIUI Java compiled into something else
<gary_poster> well, a new development platform 
<gary_poster> that's just another Java compiler, hatch?  the JVM is pretty integral to code that targets Java AIUI
<hatch> ahh you might be right - they might just use a special compiler
<gary_poster> I don't know if that would actually get them away fromOracle, but maybe
<hatch> all I know is that I don't enjoy Obj-C or Java so I'm relegated to making mobile apps in webivews :P
<gary_poster> heh
<hatch> bcsaller: odly enough I ran 'make lint' on your branch and it failed - how did it get proposed? heh
<hatch> oh, it's way early for him yet :)
<gary_poster> I'm trying to review it too hatch.  side-by-side diffs are hosed for me so I am using  other view, so I can see his comments. same for you?
<hatch> yep, I lgtm'd the code, just qa'ing now
<gary_poster> cool
<bcsaller> hatch: trying it now, worked for me here
<hatch> while doing (hopefully) the final qa on my branch
<frankban> hatch: alternatives are http://kivy.org/#home and the ubuntu sdk ;-)
<hatch> they were 'unused variable' errors
<hatch> frankban: haha - ok but I NEED curly brackets
<hatch> lol
<frankban> hatch: oh... that's why you also prefers object literals :-)
<hatch> haha....bingo!
<hatch> bracket all the things!
<hatch> bcsaller: if yours doesn't pick it up https://gist.github.com/hatched/034dd267a139da6ded9f
<bcsaller> maybe I still have an old global install of jshint or something
<hatch> oh maybe - the new version is far better
<hatch> (and faster)
<hatch> frankban: I've been meaning to look at the Ubuntu SDK
<bcsaller> gjslint needed an update, had to clean out the virtualenv in the branch
<hatch> sandbox qa looks ok for your branch
<hatch> but I can't test the go side for about an hour
<gary_poster> jujugui call in 10
<hatch> lol - I was JUST about to hit enter
<gary_poster> :-)\
<Makyo> A race! A race!  It's a race!
<hatch> haha
<Makyo> Now I want to watch Rat Race again :P
<gary_poster> heh
<gary_poster> bcsaller, "LGTM with largely irrelevant comments."
<hatch> those are the best kind!
<gary_poster> :-)
<gary_poster> jujugui call in 2
<hatch> gary_poster:  https://plus.google.com/hangouts/_/effdeeca8cca6ceeeb46d444ea075113f1f80f89?hl=en when you can
<gary_poster> luca__, you around by chance?  we could use your input on a bug resolution.  https://plus.google.com/hangouts/_/effdeeca8cca6ceeeb46d444ea075113f1f80f89?hl=en
<benji>  /lastlog benji
<benji> heh
<benji> Just checking to see if I missed anyone talking to me.  Move along.
<gary_poster> jujugui notes on bug tracker conversation: http://jujugui.wordpress.com/wp-admin/post.php?post=422&action=edit&message=6&postpost=v2
<jcastro> I can't deploy stuff from jujucharms.com site
<jcastro> in the mock environment I mean
<jcastro> I deploy 2 things, then I try to deploy redis-master and it just works
<gary_poster> jcastro, I can deploy anything other than redis-master on jujucharms.  you?
<gary_poster> jcastro, known bug, if so, and fixed on coming soon: we had a bug deploying charms without options.
<gary_poster> we will have a rollout next week with a bunch of fixes
<hatch> bcsaller: has anyone been able to QA your branch on core yet?
<hatch> nm I see it's submitted
<hatch> :)
<bcsaller> err... sorry
<bcsaller> I had the 2 lgtm and I'd run through it here, but not with core
<hatch> np - I'll just blame you for every core bug that comes up
<hatch> :P
<bcsaller> of course
<hatch> haha
<jcastro> oh man, redis-master
<jcastro> yeah that's the one I got caught up on
<hatch> Makyo: were you able to find where the 'button popup' event was attached?
<Makyo> hatch, yeah, ConflictMixin
<Makyo> app/views/inspector.js:1180
<hatch> in trying to merge trunk it's conflicting on charm-panel.js and service.js
<hatch> so I deleted the THIS files
<hatch> and resolved
<hatch> but it won't resolve
<hatch> it says that the files don't exist :/
<hatch> any ideas on how to force resolve this?
<bcsaller> bzr rm them
<bcsaller> not sure, I didn't hit that when I merged it
<hatch> thanks
<hatch> looks to have worked
<hatch> hehe this looks so odd
<hatch> '*:agent_stateChange'
<hatch> oh poo
<hatch> we can't listen to changes to arrtributes on a lazy model lists's model
<hatch> becasue it's a pojo
<hatch> so unless we 'revive' it first then set the config
<hatch> ^ bcsaller am I on the right track here or am I missing something totally obvious
<bcsaller> hatch: have process delta for the services sub-list fire 'change'
<hatch> ewww
<hatch> :)
<hatch> but ok I dont' see any other way around it
<bcsaller> it makes sense, we know when we update a given service list and it is scoped to only units of a given service 
<hatch> right but then I need to parse the unit lists for agent_state's which are 'error'
<hatch> which I suppose isn't horrible
<hatch> jujugui when destroying a service on comingsoon it throws an error: Uncaught TypeError: Cannot call method 'get' of null handlers.js:127
<hatch> I think this was introduced recently?
<Makyo> hatch, isn't that covered by one of bcsaller's branches?  There was a card for it, after all.
<Makyo> But maybe I'm going crazy.
<bcsaller> that does appear to be related to the changes I made, I didn't tests the pyDelta path very much, but the code looks sane
<bcsaller> it seems like the unit delta is getting handled after the service remove for that to happen
<hatch> odly enough it's on the go sandbox
<bcsaller> I can take a look at it
<Makyo> go sandbox sorts deltas fyi
<Makyo> Services go first, otherwise units go into oblivion on add/change
<bcsaller> Makyo: but in the case of remove the opposite should be true, no?
<Makyo> bcsaller, apparently :)
<bcsaller> heh
<Makyo> I just added the sort because core was broken.
<Makyo> And it was eminently important that core not be broken.
<bcsaller> I recall that
<bcsaller> yeah, I'll take a look, I can either shore up that code, or make a service destroy explicitly clear its own units model list and then bypass the error
<bcsaller> investigating
<hatch> bcsaller: I found a bug with your test server changes - I can't start a test server on my vm and open it on my desktop
<hatch> oh wait
<hatch> nm
<hatch> my fault
<hatch> carry-on  :)
<hatch> Makyo: so I'm waiting for my core env to come up - anything you need a hand with on your branch to get it out the door?
<benji> bac: do you want to do a quick review (https://codereview.appspot.com/14031045) and then sync up via hangout?
<bac> benji: sure
<hatch> sweet finally caught all edge cases while destroying these services
<hatch> man there are a lot of interactions
<bac> benji: done
<benji> bac: I'll create a hangout.
<bac> so much beeping
<benji> bac: https://plus.google.com/hangouts/_/a4803e143faddd68f8c7ceb02e589d0054ab5b37?hl=en
<benji> heh
<Makyo> hatch, Sorry, need to run and deposit housemate's rent before he overdraws his account, I may ping when I get back, but it's just a matter of getting everything set back up in the viewlet.
<benji> hatch: are you around and available for a quick bundle planning call?
<hatch> Makyo: ok cool np, lemme know if you need a hand
<hatch> benji: yeah, can you give me a few I just have some review comments to file
<benji> k
<hatch> gary_poster: bcsaller if you have a moment plz :) https://codereview.appspot.com/13938043/
<gary_poster> on call will look soon
<hatch> benji: ok ready whenever
<benji> hatch: https://plus.google.com/hangouts/_/a4803e143faddd68f8c7ceb02e589d0054ab5b37?hl=en
<bac> gary_poster: what is the status of huw's card in review lane?  can i help get it landed if readyish?
<gary_poster> bac, sorry it is landed.  move the card
<bac> oh, yay
<hatch> bcsaller: around?
<hatch> https://plus.google.com/hangouts/_/a4803e143faddd68f8c7ceb02e589d0054ab5b37?hl=en
<hatch> just about the bundle card
<bcsaller> ahh, ok, one sec
<gary_poster> hatch looking at your review now
<hatch> thanks
<gary_poster> yw
<hatch> gary_poster: so looking for the next task whenever you're available
<hatch> I'm*
<gary_poster> hatch, hook up the bundle token, if benji says it is visible now?
<gary_poster> hatch, I mean, make the charm tokens visible and stuff like that
<hatch> I think that's done?
<hatch> ^ benji
<gary_poster> hatch not quite.  Card is "Make bundle token  realer" (sorry :-P )
<hatch> with no description.....lol
<bac> benji: so how do i see a bundle in search results?
<hatch> gary_poster: oh I should probably fix this https://bugs.launchpad.net/juju-gui/+bug/1231487
<_mup_> Bug #1231487: Error while trying to destroy a ghost service from the inspector <juju-gui:Triaged> <https://launchpad.net/bugs/1231487>
<gary_poster> hatch, benji added the do-nothing bundle token.  huw customized it to show stuff
<gary_poster> hatch, oh, yes should be urgent, please
<hatch> ok updated and will do that now
<gary_poster> hatch "LGTM with rambles."
<hatch> thnks
<gary_poster> wlcm
<bac> benji: nm
<hatch> lol
 * benji never minds.
<gary_poster> bac, what is answer?  search for bac?
<bac> gary_poster: after using charmworldv3 flag
<bac> so with that flag turned on most of the normal charm icons are broken.
<gary_poster> not good
<bac> gary_poster: http://localhost:8888/sidebar/search/:flags:/charmworldv3/?text=wiki
<bac> search for 'wiki' to get two bundles
<gary_poster> cool thanks bac
<bac> http://manage.jujucharms.com/charms/precise/liferay
<bac> not *that* is a logo, dammit
<bac> no beating around the bush
<bac> we are LIFERAY...deal!
<hatch> haha
<bac> gary_poster: turns out charmworldv3 is simply not returning the default icon if none an icon is not available for the charm.  if an icon is there it is returned.
<gary_poster> bac, ok.  thank you for investigating.  easy fix, yeah?
<bac> gary_poster: should be.
<gary_poster> cool bac will make card
<bac> gary_poster: already did
<gary_poster> thanks bac :-)
<bac> i guess charmworld needs to put size constraints in the image css like juju-gui does...
<bac> huh, preview won't open svg files.  silly.
<hatch> preview is a silly problem
<hatch> Makyo: qa'ing again
<Makyo> hatch, thanks again.
<Makyo> Look over code, too, please.  I found an easy route, but eh..
<Makyo> If it really was that easy, great.  I just wonder.
<hatch> ok will do
<hatch> Makyo: there is a very odd bug with your branch
<Makyo> hatch, you're a very odd bug :/
<hatch> can you see if you can repro... instructions...
<Makyo> hatch, what is it?
<hatch> lol
<hatch> deploy liferay
<hatch> use console trigger
<hatch> click 'reload'
<hatch> go to 'config'
<Makyo> Flag or no?  I just realized I forgot testing without :(
<hatch> change the top input to 'asd'
<hatch> this is w/o
<Makyo> Ahhh butts.
<hatch> then click 'save'
<hatch> the large input gets wiped out
<hatch> then fills again
<hatch> but doesn't on comingsoon
<hatch> Makyo: actually you don't need to use the console trigger
<hatch> it just happens
<Makyo> hatch, Think that might be from the changes from your diff, where we were re-attaching the events to textareas?
<Makyo> (I can't enter asd there without an error because it's a numeric field)
<hatch> Makyo: I think it's the databinding being re-attached
<hatch> sorry I mean't 123
<hatch> :)
<hatch> meant
<Makyo> hatch, but the databinding isn't being re-attached, the entire view is being re-rendered.
<Makyo> But I'm not destroying the old.  Crap.  Sorry.
<Makyo> Uh...hmm.  I can't repro.
<hatch> hmm
<hatch> lemme try again
<hatch> Deploy liferay, click wrench, focus top field, type 123, save changes -> bottom input gets emptied, minimizes, then gets filled again and expands
<hatch> try those, less steps
<Makyo> hatch, Wait, I see what you mean by large input.
<Makyo> Yeah, okay, that I can repro.
<hatch> it actually looks pretty cool haha
<hatch> but I'm guessing it's probably doing some nastyness under the hood :)
<Makyo> hatch, Yeah.  I'll poke around at destroying first.
<bac> gary_poster: charmworld icon fix is easy.
<Makyo> hatch, Still all sorts of frumpy that 'render' is just the slightest nod at view.render, but I don't have the bandwidth to normalize all viewlets.
<gary_poster> yay, thanks bac
<hatch> Makyo: yes - this viewlet is virtually a Y.View
 * bac -> walkies
<Makyo> hatch, just that all of the viewlets work differently.
<Makyo> Oh, crap, I should walk dogs D:
<hatch> yeah!
<hatch> Makyo: yeah - the convention hasn't really been enforced on that regard
<Makyo> (also, new meds are making me all sorts of jittery and talkative, sorry for the last few days)
<Makyo> https://groups.google.com/forum/#!msg/net.unix-wizards/8twfRPM79u0/1xlglzrWrU0J
<Makyo> Thirty years ago today.
<Makyo> I kind of hate databinding.
<Makyo> hatch, would you be amenable to making this a separate branch?  It's less than ideal, for sure, but I'd like to be able to focus on just that.
<hatch> Makyo: which part? I'm concerned that we are introducing a bug into the system which didn't exist before - maybe what we need instead is to push this branch and land a branch which solves the underlying issue first
<Makyo> Fine.  Whatever.  Lets do something.  I've been stuck on this damn thing since April and I want it done.
<Makyo> I'd love to have done this in a much more incremental manner, but the lack of docs and any defined pattern of behavior make that a little hard.
#juju-gui 2013-09-28
<hatch> I really have no idea what's wrong atm but I can look into it
<Makyo> Next week.
<hatch> maybe :)
<hatch> sometimes I get stuck on an idea and need to solve it haha
<Makyo> We should nail down why render isn't idempotent (or why it is in a few cases if it shouldn't be), why you can't unbind/rebind events, ditto data-binding, etc. etc.  None of these are clear, and so effort is being spent in blind alleys.
<Makyo> That's fair. I'll be around this weekend on personal projects, ping me if you come up with things and I can set those aside.
<hatch> Makyo: yeah I agree - seems to be the m.o. with viewlets - these use cases keep poping up which it was never intended to be used for
<hatch> so we never set out guidelines for these things
<Makyo> Yeah, that's fair.  Maybe if I get some free time one of these weekends, I'll do a thorough documentation of viewlets so we at least know what's there, even if there isn't a pattern.
<hatch> We are skirting the line of Views now
<hatch> the line is getting thinner and thinner :)
<hatch> bcsaller: review and qa done - just one q
<bcsaller> hatch: while I agree, that is the actual system state, if we want to list pending actions in a better way that what notifications should do
<bcsaller> almost all of our actions have real world delays, drawing something else in the meantime isn't really the answer
<bcsaller> its the same principal as with the Dying state we talked about today
<hatch> right - but any indicator of the dying state isn't coming for a while, so right now (if the delay is long) the user may click on it and attempt to destroy it, wondering why it's not working
<hatch> so while I think what you did is what we want to move towards - it might be a little premature
<hatch> I can be convinced otherwise I suppose
<bcsaller> hatch: maybe some improvement to the notification story should happen first
<hatch> agreed
<hatch> I envision a coloured dot which flys from the users interaction point to the notification bar when there is a notification :)
#juju-gui 2013-09-29
<hatch> Makyo: curious as to why we can't just close/re-open the inspector -or- tell the user to do so. I say this because when an update comes down on any of the Google properties it says to refresh the page
<Makyo> hatch, That was my question :)
<hatch> well then! great minds think alike
<hatch> lol
<Makyo> hatch, If there's a way to close/reopen automagically, I'm game.
<Makyo> That solves a couple of problems, or at least solves one and defers the others.
<Makyo> </techdebt>
<hatch> I bet there is :) I'll just boot up my VM and take a peek
<hatch> Makyo: https://gist.github.com/hatched/e4eb81cd13df5e96063a
<Makyo> \o/!
<hatch> Makyo: haha - it's pretty untested though so you will want to run it through its paces to make sure there is no hidden dragons
<Makyo> I will.  Thanks for the patch, though.
<hatch> yeah no problem
 * hatch stepping away now
<huwshimi> Morning
<hatch> morning huwshimi
#juju-gui 2014-09-22
<rick_h_> morning huwshimi 
<huwshimi> rick_h_: Hey!
<rick_h_> have a good weekend huwshimi ?
<huwshimi> rick_h_: Yeah it was good, the weather is picking up now
<huwshimi> rick_h_: How was your single dad weekend? :)
<rick_h_> nice, we've got fall in full swing here
<huwshimi> rick_h_: Is it getting cold yet?
<rick_h_> yea, down into the 50s (10C) and heading down. Will be interesting. Normally this chilly around Halloween but a little bit to go still
<huwshimi> ouch
<fabrice> morning
<rick_h_> morning wheeee
<rick_h_> gah the email, the email!
<rick_h_> frankban: partying in the new place?
<frankban> rick_h_: no, not yet, still no internet connection there :-/
<frankban> rick_h_: hope they will be able to fix stuff this week
<rick_h_> frankban: ouch /me crosses fingers for you
<frankban> rick_h_: thanks
<jcsackett> morning, jujugui--can i get some reviews on https://github.com/juju/juju-gui/pull/570 ?
<kadams54> jcsackett: sure
<jcsackett> thanks, kadams54.
<jcsackett> kadams54: note, there are two lint errors, i've got a fix in place but won't push while you're reviewing.
<jcsackett> rick_h_: am i still part of "all hands on" for MV release, or should i move back to the other thing? losing track of where my focus should be. :p
<rick_h_> jcsackett: looking
<rick_h_> jcsackett: if you want to start removing the FF while kadams54 picks up the card on the boolean fields in the inspector that'd be great
<jcsackett> rick_h_: i would be delighted to start killing the feature flag. the other cards on the board don't block that?
<rick_h_> jcsackett: no, basically we're going into it being available with the couple of bugs
<jcsackett> rick_h_: dig.
<rick_h_> jcsackett: there might be some small conflicts to resolve, but hopefully small
<rick_h_> jcsackett: and we know we're releasing so worst case trunk has issues for 2 days
 * jcsackett nods
<jcsackett> awesome.
<kadams54> jcsackett: QA and review is finished. You're all clear to ship!
<jcsackett> kadams54: awesome, thanks. :)
<kadams54> guihelp: I have a comparison. The type on one side can be a string, boolean, or int. The type on the other is always a string. What's the safest way to coerce the first side into a string? Concat an empty string? Call 'toString()'? If statement based on value returned by typeof?
<frankban> kadams54: I am not sure about the meaning of comparing a bool to a string
<kadams54> false == 'false'
<kadams54> Which is false
<kadams54> What I want is: 'false' == 'false'
<kadams54> Which will yield true
<frankban> kadams54: for int vs string, one way is to zero fill the int while converting it to a string (and in this case "+ ''" does the job)
<fabrice> there is also String()
<kadams54> Yeah, there are a slew of ways I *could* do it, I'm just wondering which is the safest :-)
<hatch> what r u trying to do?
<fabrice> kadams54: +'' is safe if it's number boolean or string
<hatch> I prefer String() it's more explicit
<hatch> when glacing through
<fabrice> I agree
<hatch> buut I don't know what it's being used for yet :)
<kadams54> hatch: take a look at https://github.com/juju/juju-gui/pull/571
<hatch> kadams54: uhh why don't you do if (typeof config[key] === 'boolean') {  ... }
<kadams54> hatch: you came in just after my initial question: "I have a comparison. The type on one side can be a string, boolean, or int. The type on the other is always a string. What's the safest way to coerce the first side into a string? Concat an empty string? Call 'toString()'? If statement based on value returned by typeof?"
<hatch> ok well yes then using String() is my preferred method 
<hatch> but I think in this case you should be checking the type and doing a proper comparison
<kadams54> And comparing one string to another isn't a proper comparison?
<fabrice> kadams54: all methods would be safe for number Boolean or String , the issue comes with functions or other objects. String() is kind of explicit 
<hatch> kadams54: it is, but why not test for a boolean then do the proper comparison for the data type
<kadams54> Because it achieves the same result with more lines of code?
<hatch> well technically it's different
<hatch> but yes the end result is the same
<hatch> I'd still prefer sticking with the proper type
<hatch> maybe that's my typed lang experience coming back
<hatch> hah
<kadams54> Here's what sways meâ¦
<hatch> type cooersion is slow, string comparisons are slow
<kadams54> The reference spec we're comparing against is a string and is always a string.
<kadams54> So that makes me want to convert everything to the same data type being used in the ref.
<kadams54> That is, the proper "type" here is actually String.
<hatch> really? juju sends us boolean values as strings?
<kadams54> We're comparing two Objects of config values to determine which config settings have changed. One, the new values, stores booleans as booleans. The other, the old values, stores them as strings.
<kadams54> I'm not sure where the old values are coming fromâ¦ someplace else in the GUI? Juju? But they're stored as strings and that's what we're comparing against.
<hatch> hmm something seems broken there
<kadams54> So I'm inclined to convert the new values to String as well.
<hatch> I'm pretty sure when we parse the data from juju true === true
<hatch> kadams54: I'd look into why there is a type discrepency 
<hatch> *caugh* this wouldn't happen with Dart *caugh*
<hatch> ;)
<rick_h_> jujugui call in 10 please kanban
<hatch> oh I love it when old tests fail but it works in the real app
<rick_h_> jujugui otp atm might be a minute or two late
<rick_h_> boom, 12min call with 14 people
<rick_h_> we rule! :P
<hatch> and the internet claims standups are broken
<hatch> clearly they aren't doing it properly
<rick_h_> lol
<hatch> jcsackett: first step to removing the flag is to set it as the default and then start removing the conditionals
<rick_h_> hatch: you still on for the blog post for MV? I've got a marketing meeting with sally tomorrow and want to make sure we'll still have 3 posts
<jcsackett> hatch: what do you meant "set it as the default"? is that separate from just ensuring we always go down the MV path on a conditional (e.g. sanely remove it)
<hatch> rick_h_: yup I haven't started on it yet but I'll have it ready to go for thurs
<rick_h_> hatch: ok cool
<hatch> jcsackett: in the index.html set the window.flags.mv as true
<hatch> then visit the gui without the mv flag in the url
<jcsackett> hatch: ah.
<hatch> this way you can take steps towards removing the flag without having to do it whole hog
<hatch> huuuuge time/sanity saver
<jcsackett> hatch: ah. does that make it safe to land pieces at a time, then?
<hatch> jcsackett: you bet
<jcsackett> hatch: awesome.
<hatch> because according to the user it's already the default
<hatch> we can (and have) shipped like that too
<jcsackett> hatch: cool. well then, i think my one enormous card just became several smaller ones.
<hatch> :)
 * rick_h_ heads to the doc, biab everyone
 * rick_h_ heads to the doc for real this time
<lazyPower> hatch: hope you're ready for more eyes on the ghost charm ;)  You were featured sir!
<hatch> oh crap
<hatch> :)
<lazyPower> <3
<hatch> I guess I should probably push the new version then
<lazyPower> the 12 people that watch the video will be alllllll about ghost.
<hatch> I wish you could upload extra files into charms - think templates
 * lazyPower snickers
<hatch> lol
<lazyPower> you can
<lazyPower> however, thats a prime candidate for a subordinate relationship eh?
<lazyPower> juju deploy ghost-templates
<lazyPower> juju add-relation ghost ghost-templates
<lazyPower> juju set ghost-template theme="rocco"
<hatch> well I don't really want to force people to make a charm just to deploy their template
<lazyPower> ok, then make templates git deployable
<hatch> but then they have to upload it to a public repo
<hatch> heh
<lazyPower> and the problem with that is?
<hatch> say you are a real brand using Ghost as your blog
<hatch> you don't want any joe running your template
<lazyPower> then add deploy key support
<lazyPower> juju set ghost deploy_key=(base 64 encoded ssh key)
<hatch> is that encrypted?
<hatch> from the cli
<hatch> it would be 100x easier if you could upload a binary as a config option
<hatch> kadams54: looks like my test failures after I fix a databinding bug will be fixed by your fix
<kadams54> hatch: :-b
<hatch> somehow a config option is "                                   false"
<hatch> like wth
<kadams54> lol
<hatch> something is seriously broken
<hatch> odly enough though it works outside of tests
<kadams54> Maybe I should throw a trim() in there?
<hatch> well no we need to figure out why it's that
<kadams54> I did some digging around and it looks like the values are stored as strings far more often then not
<hatch> I don't just want to bandaid over the problem
<kadams54> That is, the *only* place where they weren't being stored as strings, that I found, was in the chunk of code I was working in. Strings everywhere else.
<hatch> I want to find what's setting it to these invalid values
<kadams54> Fine. Don't review my PR ;-)
<hatch> a checkbox toggle is boolean
<hatch> plain and simple
<hatch> somehow it's  being set to "                           false"
<hatch> so there is a real problem here somewhere
<kadams54> It's not plain and simple though, right?
<kadams54> Can't those config values also come from a yaml file?
<kadams54> Ditto for JSON
<hatch> typeof checkbox.get('checked') === 'boolean'
<hatch> always
<kadams54> false
<hatch> ??
<kadams54> Well, OK, true enough for checkboxes
<hatch> when is a checkbox not either true or false
<hatch> exactly
<kadams54> But checkboxes !== a boolean config setting
<kadams54> The boolean config setting can also be set by a "true" string in a yaml file
<hatch> if there is a boolean config setting which is not being represented as a checkbox then it's a broken charm
<hatch> or it's not a boolean config
<hatch> kadams54: for example
<hatch> http://bazaar.launchpad.net/~juju-gui-charmers/charms/precise/juju-gui/trunk/view/head:/config.yaml#L50
<kadams54> Sure, but when the yaml is parsed, is config['juju-gui-console-enabled']['default'] 'false' or false?
<hatch> kadams54: in handlers.js there is a method called serviceInfo put a debugger in there in a real env with the gui deployed and see what it has
<kadams54> It has a string.
<hatch> well there ya go
<hatch> :)
<hatch> kadams54: so we should convert all boolean values to their true boolean values for use in the gui
<kadams54> Checking something elseâ¦
<hatch> then when we send it back we stringify it out anyways
<kadams54> Whoops, gotta run for dr appt, back in an hour
<lazyPower> hatch: another option would be to encapsulate this as a juju action
<lazyPower> (i know, an hour later i come up with another thought)
<hatch> lazyPower: haha, how would a juju action work? You 'd have to run it every time you scaled
<hatch> no?
<lazyPower> correct
<hatch> yeah I just think this is a bug
<hatch> or a missing feature
<lazyPower> but you're basically asking the end user to break auto-upgrade notifications
<lazyPower> "fork the charm locally, plug in your theme, deploy"
<hatch> heh right
<lazyPower> which is why a subordinate would be prime for this. If the subordinate is responsible for understanding where ghost is installed, and auto-deploy the theme you've defeated the scale issue.
<lazyPower> and you dont have to push it into a subordinate. You've just moved a large chunk of logic out of the parent charm into a supporting role.
<lazyPower> and fwiw, if you make the sub support binary package delivery, such a placing a tarball in files/  - who cares if the theme deployer gets an update. unless its breaking ghost, you're g2g after you've deployed it.  Set it and forget it (tm)
<hatch> right but that's a horrible story considering that the user who is used to ghost just logs into their control panel and uploads the zip
<hatch> rick_h_: ping me when you get back - I think that my issue will be resolved if we don't care about conflicts on boolean values
<hatch> lazyPower: I'm probably going to file a feature request with juju to add binary config value support
<hatch> tbh this could benefit a lot of different charms - expecially ones with complex values.....like the apache charm with a large virtual env config
<lazyPower> hatch: that exists today as base64 encoding. 
<lazyPower> not great, but fair enough that it would be easier to say "attach thing"
<lazyPower> validation of those "things" is going to be hairy. 
<hatch> base64 encode a zip of a template....lol
<lazyPower> you can do it
<hatch> why does it need to be validated?
<hatch> couldn't we add another config type 'binary'?
<lazyPower> well you just said a "large vhost file"
<lazyPower> which is text to begin with, do you want someone to upload a picture of their cat and have the apache charm barf because they uploaded the wrong MIME type of file?
<hatch> well I just picked an example 
<hatch> they could upload a .txt file
 * lazyPower pulls out the paint brush and gets ready to paint the bikeshed
<hatch> if they uploaded a cat picture instead...well then too bad for them
<hatch> that would be the same as copy\pasting an invalid virtual env config
<hatch> lazyPower: I'm creating a bug atm - so we can move the discussion there 
<hatch> better to have any questions/comments documented
<lazyPower> hatch: unless it includes a screenshot with the caption "Schenanigans" - i reject your bug
<lazyPower> <3
<lazyPower> i had no idea the gui did that btw. that blew my mind
<lazyPower> i pinned a card on our canban to talk about that in today's standup
<lazyPower> *kanban
<lazyPower> as nobody else knew why it was doing that either. I'm gonna blow some minds today
<hatch> lol what?
<lazyPower> https://bugs.launchpad.net/juju-gui/+bug/1371821
<mup> Bug #1371821: Juju GUI isn't displaying namespaced recommended charms as featured <display> <grouping> <juju-gui:Invalid> <https://launchpad.net/bugs/1371821>
<hatch> ohh heh yeah 
<hatch> I wrote the sort for it so it's my fault
<lazyPower> s/fault/feature
<hatch> tbh I'm not entirely convinced for cases when there isn't a valid 'trusty' charm but there is a precise one
<hatch> but I didn't want to get too complicated as it should probably be sorted in charmworld
<hatch> lazyPower: https://bugs.launchpad.net/juju-core/+bug/1372566
<mup> Bug #1372566: Add a config field type 'binary' <juju-core:New> <https://launchpad.net/bugs/1372566>
<hatch> it looks like work on sublime text 3 has started again http://www.sublimetext.com/3
<hatch> and in another year I bet another update will come out lol
<rick_h_> hatch: pong
<hatch> rick_h_: hey I want to propose dropping conflict resolution/notifications for boolean values. call in standup?
<rick_h_> hatch: k
<hatch> kadams54: I was able to get this to work regardless of the outcome of your branch - so yay 
<hatch> lunching
<rick_h_> lazyPower: the hive-mysql one didn't seem to ingest? The other two I see (from your email)
<lazyPower> rick_h_: they were pushed really recently, it might still be in the ingest-o-tron
<rick_h_> lazyPower: it passed proof and such?
<lazyPower> si
<rick_h_> lazyPower: ok
<lazyPower> charles@desktop:~/tmp/charms/bundles/hdp-hadoop-hive-mysqlâ« charm proof
<lazyPower> charles@desktop:~/tmp/charms/bundles/hdp-hadoop-hive-mysqlâ« 
<lazyPower> i called that out at the top that they are recent and might be waiting for ingestion. We should see the hive-msyql one show up in ~ another 10 minutes or so.
<rick_h_> k
<rick_h_> lazyPower: yea, was checking and saw the other two are there
<rick_h_> want to make sure it gets in ok
<hatch> boo
<rick_h_> hoo
<hatch> lazyPower: my bug was marked as low ;'(
<lazyPower> hatch: mine was markes as invalid :'(
<hatch> lol well yours WAS invalid :P
<hatch> I suppose mine IS low haha
<rick_h_> ouch
<rick_h_> hah, love dual'ing PRs
<hatch> jujugui I need a review and qa on https://github.com/juju/juju-gui/pull/573 
<hatch> rick_h_: haha you mean because mine and Makyo's landed at the same time?
<rick_h_> hatch: yea, got two new emails right next to each other
<Makyo> Yep :D
<hatch> great minds think alike.....eh Makyo? eh???
<Makyo> On that note, jujugui need reviews/QA on https://github.com/juju/juju-gui/pull/572 (real env)
<hatch> trade ya!
<Makyo> Sure thing
<hatch> Makyo: u gona give me some qa notes? 
<Makyo> Hadn't hit enter yet, sorry
<hatch> noooo prob
<Makyo> hatch, I think your branch is okay, but it's not matching your QA instructions, so I'd like to verify.
<Makyo> Like, I think it's good, I just think your QA instructions might be mixed up.
<hatch> Makyo: oh ok
<hatch> whats up?
<Makyo> hatch, I changed debug to baz in the inspector.  After changing it to foo on the cli, the inspector should still show 'baz', right?  Because it's showing the changes that exist in the ECS?
<Makyo> I just think foo and baz got mixed up in your instructions.
<hatch> ohh yes you are correct it should still show baz
<hatch> I'll fix that in the docs
<Makyo> Good.  YEah, I think this branch is good.
<hatch> thanks
<hatch> awesome good catch :)
<hatch> just about to spin up to qa yours
<hatch> jujugui anyone know why the first lxc instance takes quite a while to boot but then subsequent ones are really fast? Is this something with lxc or my setup being busted?
<jrwren_> hatch: first on a new system?
<jcsackett> hatch: how long is "very long"? i've given up on juju w/ lxc on my machine thinking it was busted.
<hatch> like 15mins for the first instance
<hatch> then 1m for the second
<bac> hatch: first as in 'download the OS for use by lxc' or first after reboot?
<jrwren_> hatch: it downloads the cloudimg from simplestreams, extracts it and builds the base lxc from which everything else is cloned.
<hatch> I've created/torn down an env a few times today
<hatch> so it's not caching the images?
<bac> hatch: it should be
<jrwren_> hatch: oh, no. that should happen once per host system. So that isn't it.
<jrwren_> /var/lib/lxc/juju-{precise,trusty}-template 
<hatch> yeah those are there
<jrwren_> lxc-clone: true ? lxc-clone-aufs: true ?
<hatch> there is a lxc-clone but no lxc-clone-aufs
<jrwren_> hatch: I like the aufs option, which is false by default.
<rick_h_> is that only on btrfs?
<jrwren_> hatch: also, depending upon which version of juju you run, apt-get update/upgrade may or may not run on system image deploy
<hatch> yeah it took 10mins to spin up this time....second machine will be about a minute
<jrwren_> rick_h_: aufs is an alternative to btrfs
<rick_h_> oic
<jrwren_> hatch: no, that first machine taking 10 and second machien taking 1 doesn't add up to using these options.
<hatch> jrwren_: ok thanks...I think
<hatch> haha
<hatch> I was hoping this was normal
<hatch> lol
<jrwren_> I didn't think juju had a "normal"
<hatch> haha 
<jrwren_> hatch: do you notice it is slow if you add machine instead of deploy a charm?
<hatch> jrwren_: I'll have to check in a bit
<hatch> that machine was 1.5min
<hatch> so weird
<hatch> I wonder if there is some funkyness because I'm in a parallels vm
<hatch> Makyo: what's this containers flag you speak of?
<hatch> oh look at that
<hatch> hmph
<hatch> lol
<jrwren_> i'm afk. have a good evening ya'll. Happy Equinox.
<hatch> cyaaaa
<hatch> ok something is totally borked with my env
<hatch> Makyo: review and qa done
<hatch> jujugui anyone else available for a review? https://github.com/juju/juju-gui/pull/573
<rick_h_> hatch: will do at some point, otp right now
<hatch> ok sounds good - I'm going to move on with it assuming it's ok :(
<hatch> :)
<hatch> er
<hatch> :)
<rick_h_> kadams bah not here
<hatch> maybe doc appt didn't go well
<hatch> "sorry, you have semicolon pinky - you will need to change programming languages"
<hatch> NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
<hatch> going to grab a coffee, back in ~15
<rick_h_> hatch: off phone, but leaving for son/dinner so will try to get to code review later tonight
 * rick_h_ runs away
<hatch> back
<hatch> rick_h_: cool np enjoy
<huwshimi> Morning
<rick_h_> huwshimi: morning, can you make sure to check for any reviews of the storeferont stuff from ant/robin as part of the daily workflow?
<huwshimi> rick_h_: Hey, sure np
#juju-gui 2014-09-23
<hatch> hey huwshimi 
<rick_h_> huwshimi: actually could you do me a favor today please? There's one card in there "The complete changelog doesn't indicate"
<rick_h_> huwshimi: could you look at that card in MV tonight? It's a small counting one that I think would be a nice to have and small to do
<huwshimi> rick_h_: Yep np
<rick_h_> huwshimi: ty much
<huwshimi> no problems at all
<rick_h_> morning
<fabrice> rick_h_: morning
<rick_h_> how goes fabrice?
<rick_h_> fabrice: any luck on the charm front?
<fabrice> rick_h_: I have the scripts wrapped but I am still trying to get it running under a vm ubuntu server utopic  which launch lxc utopic
<fabrice> rick_h_: my changes are at least working  on trusty
<fabrice> rick_h_: I would love to have an apt cache of some sort :)
<fabrice> rick_h_: this will be ready sometimes this afternoon after the test
<fabrice> but first lunch
<rick_h_> fabrice|lunch: enjoy
<hatch> quiet in here!
<rick_h_> ssshhhh
<hatch> :P
<jcsackett> rick_h_: i left the "remove mv flag" card in coding--should i park that there and create a new card for each bit i put up for review, or keep creating new cards in coding and move them along?
<rick_h_> jcsackett: park it, there's WIP room
<jcsackett> rick_h_: cool.
<rick_h_> just make sure you get reviews as needed
<rick_h_> jcsackett: are there a couple coming up? 
<rick_h_> jcsackett: I got the first one
<jcsackett> rick_h_: i saw, and replied.
<rick_h_> jcsackett: rgr, shipping it now. 
<jcsackett> rick_h_: well damn. good thing i QAed before proposing. :p
<rick_h_> I'll call it trivial. :)
<jcsackett> rick_h_: yeah, but you shipit'ed before i actually pushed my update, since i was going to wait on second review. :p
<jcsackett> i'll fold it into the next branch.
<hatch> lol
<rick_h_> jujugui call in 7 please kanban
<jcsackett> hrm. i miss bzr/launchpad support for pipes and prerequisite branches in prs.
<rick_h_> mhilton: standup time
<rick_h_> kadams54: ping got a sec?
<kadams54> rick_h_: sure
<rick_h_> Makyo: can you email a link to your raw video to sally and myself please 
<kadams54> guihelp: I'm ready for a pre-impl call on my card. Somehow, when you delete a relation, the aggregatedStatus attribute on a *different* relationship (or no relationship at all) is getting set to "pending-healthy".
<hatch> that's odd
<hatch> kadams54: do you have any idea where?
<hatch> like have you traced the delete code?
<kadams54> Yesâ¦ it doesn't appear to be happening in the delete code.
<hatch> you sure you have the simulator off?
<hatch> :)
<kadams54> This is in EC2
<kadams54> Rather, it happens as part of the topo update that gets called from _dbChangedHandler in app.js
<kadams54> Which is triggered by the delete
<kadams54> Things go off the tracks here: https://github.com/juju/juju-gui/blob/develop/app/views/topology/relation.js#L410
<kadams54> So relation.aggregatedStatus is set to "pending-healthy" for the incorrect relation when the class gets set. But I'm not sure where/when aggregatedStatus is being changed to the wrong value.
<hatch> kadams54: you can attach a change event handler to the attribute
<hatch> put a debugger in the callback and you'll get a good async traceback
<kadams54> Yeahâ¦ since I'm debugging in a real env I'm trying to do all the digging before changing code.
<hatch> ahh right right
<kadams54> But I suppose I could switch back to sandbox since I've confirmed this happens in both places. I'm just leary given all the sandbox-only bugs we've found.
<hatch> good news is that aggregatedStatus is only touched in 5 places in the cod3e
<hatch> agregatedStatus has a complex getter
<hatch> I'd probably start in there
<kadams54> Yeah, I'm looking in there. Right now it seems like relation.pending is still set to false on the relation I just deleted.
<kadams54> Strike thatâ¦ the pending attribute doesn't come into play here. Rather, the deleted attribute is what's important, and that is set incorrectly (to true) on the wrong relation.
<kadams54> Time to do more digging to find out who's setting thatâ¦
<jcsackett> jujugui: can i get 2 reviews and a QA on https://github.com/juju/juju-gui/pull/576 ? it's mostly deletes.
<hatch> yeah that;s odd
<hatch> jcsackett: sure
<kadams54> jcsackett: Sure. My head is starting to hurt on my card anyhow :-)
<jcsackett> thanks, hatch, kadams54.
<hatch> jcsackett: sad to see all this work go
<hatch> :)
<jcsackett> :p
<hatch> although the git diff is wako
<hatch> jcsackett: just one comment could you investigate it plz
<jcsackett> hatch: it's used in topology/service.js
<jcsackett> in a tangled mess with relations and stuff.
<jcsackett> it may very well be able to go, but it requires research outside of the scope of removing the MV flag.
<jcsackett> one has to suss out the whole topology set.
<hatch> jcsackett: ahh ok that's what I was worried about thanks
<hatch> could you create a bug around that so we know to go revisit it at a later time?
<hatch> and +1
<hatch> Makyo: well I tried :) maybe one of these days we'll get named params in js
<Makyo> It'd be nice!
<hatch> oh well - I always have Dart
<hatch> hmm this conflict UI stuff might be a little more work than I had thought
<hatch> jujugui is there anywhere else in the app that we use the conflict resolution besides in the config? I can't find anything so just confirming
<rick_h_> hatch: no, that's it
<hatch> ok - this would probably lend itself well to something like react now with a conflict ui layer on top
<hatch> this databinding is....complex
<hatch> :)
<kadams54> lunching
<hatch> jujugui anyone want to sit and listen to me reason about my implementation for the new conflict resolution fixes?
<rick_h_> hatch: otp for the next hour but happy to after that
<hatch> ok I'm going to start hacking on this and then whenever you have a moment ping me and I'll run through it
<rick_h_> hatch: rgr
<hatch> rick_h_: timeoff request posted
<hatch> jus a piddly little thing
<hatch> :)
<Makyo> jujugui would like another quick look at https://github.com/juju/juju-gui/pull/572 if someone's got a chance.
<hatch> Makyo: +1
<rick_h_> Makyo: if hatch says +1 you've got mine thanks!
<rick_h_> hatch: call time? I've got 15
<hatch> rick_h_: sure joining standup
 * rick_h_ goes off to dr again, biab
<kadams54_> hatch: I think I've got the bug accurately captured in a failing testâ¦ can you take a look and verify that I'm on the right track?
<kadams54_> hatch: https://gist.github.com/kadams54/8a32eeee81e62031f17c
<hatch> looking
<kadams54_> The test sets up two endpoint sets that have one endpoint in common, but the other endpoint differs on the ID. The compareRelationEndpoints should return false because only one endpoint matches, but it does not.
<hatch> kadams54_: I don't think this test makes sense
<kadams54_> Chat?
<hatch> they can't relate because they require/provide the same thing
<hatch> ok i'll hop in the standup
<hatch> kadams54_: ping me when you get back if you get stuck - I'm interested in the resolution of this, relations are a pita :)
<kadams54_> hatch: will do. I'm pretty sure I know how to fix it, but I still don't know exactly why it's breaking the way it is, and that bugs me :-)
<hatch> haha - well...best of  luck
<hatch> lemme know if you need another sounding board
<kadams54_> hatch: I don't think the problem is in flipping the endpoints, though I agree with your assessment that it's not doing what it's intended to do.
<hatch> damn
<kadams54_> Rather, the problem seems to be with the nested .some() functions that are looping through both sets of endpoints on line 1627-1631
<hatch> this was written in a rush for a demo I believe so it's entirely possible an edge case was missed (obviously)
<hatch> heh 
<kadams54_> If I read them right, if any of the endpoints in the set match, then it will return true, when it should require *all* of the endpoints in the set to match.
<hatch> damn I love writing code like this but wow is it hard to reason about later
<hatch> well only one on each side needs to match
<hatch> ohh nm rght
<kadams54_> I need a good stiff drink and some painkillers
<hatch> lol - who needs a liver anyways
<rick_h_> kadams54_: hatch anything I can help with?
<hatch> not here
<kadams54_> Ditto - all good.
<kadams54_> Unless you have some vicodin.
<rick_h_> no, I've got the blue stuff 
 * rick_h_ can't recall the name now...
<rick_h_> valium, that's it
<hatch> moms little helper
<kadams54_> This relations-induced headache keeps reminding me of Lucille Bluth's misinterpretation of the prescription warnings as "winking eye drink with alcohol" instructions.
<hatch> that's valium right?
<hatch> or how was it marketed....it was something like that
<rick_h_> jcsackett: if MV flag gone gone?
<hatch> yup valium http://en.wikipedia.org/wiki/Mother's_Little_Helpers
<jcsackett> rick_h_: should be gone gone early tomorrow. 
<rick_h_> hatch: heh, well there you go. It's part of my anti-migraine regiment :)
<rick_h_> jcsackett: ah ok. I saw no open cards for you and got curious
<rick_h_> oh bah
<hatch> :)
<rick_h_> jcsackett: ignore me, I was looking at the top grouping
<rick_h_> moving things around fooled me all up
<jcsackett> rick_h_ it's done that to me a time or two as well. 
<rick_h_> Makyo: can I change your card to not blocked? Are we good now to update the button as appropriate?
<rick_h_> can you tell when I get done with calls, all of a sudden very curious in everyone's cards :P
<jcsackett> :p
<rick_h_> antdillon: get our of here
<rick_h_> bah, I need ops to kick him out of here
<rick_h_> +ops
<hatch> lol
<rick_h_> stupid irc
<hatch> antdillon: has a worse work/life balance than I do
<Makyo> rick_h_, thought I did, must not have hit submit, so yeah.
<rick_h_> and he's about to have no sleep in life when the kid shows up
<Makyo> Just about to propose, anyway
<rick_h_> Makyo: ok cool, card seem to be in good shape now with your last change?
<Makyo> One line fix, now :)
<rick_h_> Makyo: ooh, yay. I was hoping that'd be easy now but was scared...nothing is easy these days
<antdillon> rick_h_, lol I have +1's damn it!
<rick_h_> Makyo: cool, and then the notification card as a follow up on that one for tomorrow?
<rick_h_> antdillon: :P
<rick_h_> antdillon: apologize to robin for me. Poor guy got huw'd hard today
<Makyo> rick_h_, Yep.
<antdillon> rick_h_, lol hes been writing charms for IS with them reviewing ... your review it nice in comparison
<rick_h_> antdillon: hah! ok, well normally we'd break someone new in a little easier 
 * rick_h_ runs away for a bit. I'll be back on tonight working in the blog post and such though if people need a hand/reviews in 3hrs
<Makyo> jujugui small review, QA in real env: https://github.com/juju/juju-gui/pull/577
<hatch> Makyo: lol
<hatch> I recall that line being there at some point
<Makyo> Well, it's back :)
<Makyo> Going to exercise dogs, back in a few.
<kadams54_> hatch: this relation comparison has turned into a real pita. It's seems like its not just a bug, but potentially a fundamental change in how we compare relations.
<kadams54_> That is, the way we currently compare relations doesn't work when you have multiple relations that share one endpoint, but not the other.
<hatch> kadams54_: I don't think you can have multiple relations sharing a single endpoint
<kadams54_> Mongo cluster bundle
<hatch> looking
<kadams54_> All of the relations between the shards and the master all share one endpoint (the master) but have different endpoints at each of the shards.
<hatch> ahhh
<hatch> so yeah that's definitely not going to work with this 
<hatch> tbh I didn't know that was even possible
<kadams54_> I'm going to need to think harder about this.
<kadams54_> But that'll have to happen tonight. It's dinner time on the east coast.
<huwshimi> Morning
<hatch> mornin
<Makyo> jujugui another small one https://github.com/juju/juju-gui/pull/578
<rick_h_> Makyo: <3
<rick_h_> morning huwshimi 
<rick_h_> Makyo: comments in
<hatch> Makyo: review done
#juju-gui 2014-09-24
<hatch__> huwshimi: how goes the battle?
<huwshimi> hatch__: Setting up handlebars...
<Makyo> bleck, that stupid test took forever, know what I'm doing on catchup week.
<Makyo> jujugui if anyone's around, https://github.com/juju/juju-gui/pull/578 is ready for rereview
<hatch__> Makyo:  the notification tests?
<hatch__> huwshimi:  setting it up....that should be easy???
<hatch__> I suppose maybe not heh
<hatch__> Makyo:  sure
<hatch__> Makyo:  why the changes to pass the index through?
<Makyo> hatch__, per rick_h_ 's comment
<huwshimi> hatch__: It's not a problem, just a little hassle, having not done it before
<hatch__> Makyo:  gotcha
<hatch__> huwshimi: ahh yes
<hatch__> huwshimi:  you've sure been dipping ways out of your comfort zone lately :) good to see
<Makyo> No tests around _waitOnLevel or whatever.  Will have to get some in there.
<huwshimi> hatch__: There's 70 thousand ways to set it up
<hatch__> lol tis true...tis true
<hatch__> considering it's just a templating language there are also as many different processors hah
<huwshimi> hatch__: I've gone for a non-YUI way to reduce the dependency
<rick_h_> hatch__: yea, the idea is to help the user tell stacks of changesets apart a little to help make the notification seem like it's not a true repeat/etc
<hatch__> rick_h_:  yeah np I just didn't see the comment
<hatch__> so running Ubuntu on metal on this thing I get 3.5H battery life max....running Ubuntu in Parallels I get 5.5H max
<hatch__> lol
<huwshimi> rick_h: Reading your blog post and got to the first screenshot of the machine view and now that we've removed the "Machines" title from the top of the list it makes it unclear that what you're looking at is a list of machines.
<rick_h_> huwshimi: yea, I break it down into smaller bits, I just think the screenshot will get pushed down to 600px or so and you won't really read it at that level
<rick_h_> so each screenshot after that is just a 'section' 
<rick_h_> to aid in blog-friendly sizing
<huwshimi> rick_h_: I think this is a problem with the interface, not with your post
<rick_h_> huwshimi: oh, you mean the machine column poist?
<rick_h_> bah
<rick_h_> huwshimi: I think it'll be more clear with the hardware info there 
<rick_h_> huwshimi: and the nav button is machine
<rick_h_> huwshimi: so in usage I think it'll be ok, but we'll find out from the users for sure. 
<huwshimi> rick_h_: You can figure it out, but it's now implicit
<rick_h_> huwshimi: true
<rick_h_> ok, /me is toast and going to head to bed. See you all for release day tomorrow. 
<huwshimi> rick_h_: Night
<rick_h_> morning 
 * rick_h_ heads to take boy to day care and move to coffee shop for emergency injections
 * rick_h_ is back
<jcsackett> Makyo: you around/available to chat?
<rick_h_> jcsackett: probably a bit early yet. Anything I can help with?
<rick_h_> jcsackett: I'd expect him in about 1.5hr ish
<jcsackett> rick_h_: i'm cleaning up tests, looking in test_environment_view.js
<jcsackett> it has tests for "remove relation" and "confirm" buttons, which are gone with MV (we just have the delete icon on the relation now when you click, and no confirm.
<rick_h_> jcsackett: ah ok
<jcsackett> i'm trying to figure out if this needs to be rewritten, or if we have tests for the new function and these can just be deleted.
<jcsackett> i'm also trying to make sure i'm right about what these are testing. :p
<rick_h_> jcsackett: gotcha, check out 969dd69e7c52d911b55d98ceda37e97465af9c7e
<jcsackett> line 1004 or thereabouts "must be able to remove a relation between services" if you want to look.
<rick_h_> jcsackett: and c9beb0576b03fdd395a4dfd3085f68963d173d06
<rick_h_> jcsackett: and 5b6a94999f21c1039d86f89bc4cb9f263439602a 
<rick_h_> jcsackett: and 45f9c937529e87b9adadb257a3d21d9f1b822066
 * jcsackett laughs
<jcsackett> this is a lot hashes. :p
<rick_h_> jcsackett: so those have commits that seem to be about removing relation stuff
<rick_h_> well, it's 4 commits
<rick_h_> and I'd check and see what tests those commits have in them
<rick_h_> and it might point you towards the idea that it's well tested elsewhere
<rick_h_> or it might give you no hope and have you thinking of rewriting what's there
<jcsackett> rick_h_: what's the best way to look at what changed in a single commit? "git diff sha1" shows me the diff between my branch and that sha, which is not great.
<rick_h_> jcsackett: 'git log -p $sha'
<jcsackett> rick_h_: fantastic, thanks.
<rick_h_> kadams might be interested in those commits as well I guess
<jcsackett> huzzah, did need to rewrite, but just remove the parts about confirming, since the parts about removing are still valid.
 * jcsackett continues on
<rick_h_> jcsackett: yay
 * jcsackett groans at tests that pass on test-prod locally and fail on jenkins
<rick_h_> jcsackett: hmm, that's new
<jcsackett> rick_h_: has to be an isolation thing; the tests legitemately don't have an ecs set up, so that failure should happen, but doesn't happen locally.
<jcsackett> which is fun.
<jcsackett> should be an easy fix, at least.
<rick_h_> jcsackett: heh, /me can't wait for a week of cleanup...
 * jcsackett nods
<jcsackett> rick_h_: oh this is annoying.
<rick_h_> jcsackett: ugh, notifier tests hitting timing issues on you. Retry :/
<rick_h_> that one is the #1 code to get ripped out 
<rick_h_> bac: when you're up and about appreciate some english skills on the blog post please. 
<rick_h_> bac: since it was written a bit late I don't trust myself :)
<bac> rick_h_: i'm about
<bac> rick_h_: looking now
<rick_h_> bac: sorry, meant that more as a 'when you have time, no rush' than anything
<bac> rick_h_: you prefer comments or edit in place?
<rick_h_> bac: feel free to edit in place
<bac> rt
<rick_h_> bac: comments if you're not sure or it's a big change you'd suggest. I can go update it. 
<rick_h_> kadams54: how goes, did the relation stuff make any better sense later on?
<kadams54> rick_h_: Going well. Should be wrapping up on it soon.
<rick_h_> kadams54: awesome
 * rick_h_ heads back home from the coffee shop
<jcsackett> jujugui: can i get one more review and QA on https://github.com/juju/juju-gui/pull/580
<rick_h_> hazmat: getting ping'd by PR and such on machine view stuff and the question came up about comparing to tools available for puppet/chef. It looks like chef is in silent development mode. Is there anything I should make sure to watch as something similar I'd be expected to know/compare it to?
<rick_h_> hazmat: last stuff I poked around was the basic ui for docker and I guess the AMZ stuff that has the ability to build out the services. 
<frankban> guihelp: need reviews for https://github.com/juju/juju-gui/pull/581 anyone?
<rick_h_> frankban: looking
<frankban> thanks
<rick_h_> frankban: have a sec to chat as well? standup room when you get a sec
<frankban> rick_h_: sure joining
 * frankban bbiab
<hatch> jujugui call in 10
<rick_h_> says you :P
<hatch> 8?
<hatch> :)
<rick_h_> jujugui call now!
<rick_h_> wheee
<rick_h_> rogpeppe: ^
<hatch> looks like the save config command no longer sends only the changed fields...but instead sends all of them
<hatch> not really an issue but we may want to look into that
<hatch> wait nm ignore that
<jcsackett> rick_h_: can you look at my reply on https://github.com/juju/juju-gui/pull/582 when you have a chance? want to make sure we're on the same page.
<rick_h_> jcsackett: looking at the diff there's the green lines of adding in the stuff in taht if statement
<rick_h_> rmrelation_dialog.hide()
<rick_h_> ...
<rick_h_> jcsackett: so it appears that only the if itself was removed vs the code it contained?
<jcsackett> rick_h_: bah, misread side-by-side.
<jcsackett> rick_h_: you're right. updating.
<rick_h_> jcsackett: cool, thanks for the double check
<jcsackett> rick_h_: removing flags gets a bit confusing. :p
<rick_h_> 100%
<kadams54> guihelp: Looking for reviews and QA on https://github.com/juju/juju-gui/pull/583
<kadams54> hatch: ^^^ I'm sure you'll have an opinion :-)
<hatch> kadams54: heh I'll look a little later
<kadams54> hatch: oh yeah, heads downâ¦ get back to work! ;-)
<kadams54> Going to lunch and then starting in on lots of QAing <- jcsackett, frankban 
<rick_h_> frankban: Makyo if you guys could peek at ^ that'd be great please. The relation stuff is tricky 
<frankban> kadams54: looking
<Makyo> rick_h_, kadams54 sure
<rick_h_> ty all
<jcsackett> kadams54: thanks.
<Makyo> jujugui any further thoughts on https://github.com/juju/juju-gui/pull/577 ?  It's trivial, may just ship it
<rick_h_> Makyo: feel fre
<Makyo> Cool, thanks
<frankban> kadams54: reviewed
<frankban> kadams54: I have to go in 5, if my branch looks good to you please feel free to shipit later
<kadams54> frankban: Thanks! Will do.
 * rick_h_ goes to make up some lunch
<rogpeppe> jaasteam: trivial lppublish bug fix: https://github.com/juju/charmstore/pull/117
<rogpeppe> if anyone is, like me, interested in studying the current charm and bundle "corpus", here's a script that downloads all charms and bundles: http://paste.ubuntu.com/8419426/
<hatch> phew I think all done this now
<hatch> what a mess
<hatch> oh well
<hatch> *stretch*
<rogpeppe> and here *are* all currently known bundles, in one lump: http://paste.ubuntu.com/8419463/
<hatch> rick_h_: so far the only known bug this will create moving forward is that once you resolve a conflict the setConfig record is still there even if the value which was changed is no longer changed - but it is set to the appropriate values as a workaround
<hatch> but I figure that this is a limited use case anyways....and that isssue is even MORE limited
<hatch> heh
<hatch> Marky Mark and the Funky Bunch - Good Vibrations (feat. Loleatta Holloway)
<hatch> https://www.youtube.com/watch?v=-eSN8Cwit_s
<urulama-afk> so, rogpeppe, how are we going to deal with the first "cloud" charm, as it has orangebox bundle inside?
<rogpeppe> urulama-afk: it would turn into two charms with the names ~kirkland/bundle/transcode-cluster-cloud and ~kirkland/bundle/transcode-cluster-orange-box
<rogpeppe> s/two charms/two bundles/
<urulama-afk> rogpeppe: ok, and to my actual question: can we reference one bundle from another?
<rogpeppe> urulama-afk: no, bundles can only refer to charms
<rogpeppe> urulama-afk: unless... oh yes, there might be some kind of inheritance thing going o
<rogpeppe> urulama-afk: but only within a set of bundles within the same file
 * rogpeppe tries to remember where the original bundle specification was documented
<rogpeppe> hazmat: any idea?
<urulama-afk> rogpeppe: so instead of juju deploy ~kirkland/bundle/transcode-cluster, we need juju deploy ~kirkland/bundle/transcode-cluster-orangebox and then ~kirkland/bundle/transcode-cluster-cloud
<urulama-afk> rogpeppe: is that correct?
<rogpeppe> urulama-afk: the first one wouldn't be valid anyway
<rick_h_> hatch: yea, sounds good to me 
<hatch> jujugui I need two QA's on this branch https://github.com/juju/juju-gui/pull/584 no review yet - I still need to write the tests, but the qa should have quite a bit of exploratory work around it.
<jcsackett> hatch: can "modifyUnits" in service-overview.js be removed? it's part of the old scale up system, right?
<hatch> sec otp
<jcsackett> line 511, or thereabouts when you have a moment.
<hatch> ok looking
<hatch> jcsackett: yeah looks like it was only part of the old stuff
<jcsackett> hatch: whoo. that's good news, means i can start resolving some test issues by ripping that out. :)
<hatch> awesome - also the template and the _modifyUnits stuff
<jcsackett> hatch: second question for you, b/c i can't remember. is this one of our spurious issues? http://ci.jujugui.org:8080/job/juju-gui/1943/console
<hatch> I'm pretty sure the spurious ones were only in ie now
<jcsackett> fantastic. why doesn't this show the failure output in a useful fashion? :p
<hatch> jcsackett: yeah that looks like a real error
<rick_h_> jcsackett: don't think so. It has a failure on 'ecs methods - is instantiable'
<jcsackett> rick_h_: where are you seeing that?
<jcsackett> i've stared at this so much i just see text without meaning.
<hatch> in the sauce video
<rick_h_> jcsackett: clicking on the link to the sauce labs, clicking on the screenshots
<jcsackett> aaaah
<hatch> or the screenshots
<hatch> heh :)
<rick_h_> start with screenshots and then go to video when they skip what you want to see ime
<jcsackett> ok, i badly need lunch and then i'll return to this.
 * hatch puts his HTC One in his front pocket and goes to lunch without any fear of it bending...
<rick_h_> lol
<kadams54> lol 
<hatch> :D
<hazmat> rick_h_, re competing guis.. see panamax.io for docker from telco centurylnk
<rick_h_> hazmat: ty
<hazmat> rick_h_, also ansible tower though its a different focus
<hazmat> re puppet/chef the chef ui is as minimalist as ever.. no changes really. salt has halite (https://github.com/saltstack/halite) which is also minimal but functionaly.. there's a couple more polished ones for puppet 
<hatch> we really need a better container story...
<rick_h_> hatch: you up for air or want to pass on meeting today?
<hatch> ummm I have nothing to chat about, could keep on this test fixing unless u have something?
<rick_h_> hatch: rgr
<rick_h_> hatch: sounds good, thanks
<hatch> jujugui speaking of which I still need some qa's on my PR so we can get it landed as soon as I finish these tests
<kadams54> hatch: QA-ing another card right now; I can start in on yours in about 10 minutes or so.
<hatch> cool thx
<hatch> my qa is time consuming - lots of possible interactions
<hatch> so wanted to get as much of a head start as possible :)
<kadams54> hatch: my favorite kind :-)
<rick_h_> hatch: post YUI javascript session added to brussels and noted you'll have research to present. 
<hatch> as marky mark would say "word-to-your-motha"
<Makyo> ...
<rick_h_> ummm, wow
<hatch> Makyo: did you miss my previous link to the video?
<hatch> lol
<hatch> ok maybe that was only funny in my head
 * hatch goes back to clown college 
<Makyo> Hahaha
<hatch> ok after wiping the tomatoes off my face after that performance I'm going back head down to get this finished :)
<Makyo> Deploying the mongo bundle to local provider was a bad idea.  My laptop is supremely unhappy.
<hatch> :) io is probably hammered
<Makyo> It just turned off :P
<hatch> lol nooooo
<hatch> jujugui we have tests for conflicts in the inspector constraints UI....this doesn't even exist any longer does it? cc jcsackett
<jcsackett> hatch: there's constraints editing stuff in the scale up UI--if it's not that, then no.
<hatch> right....but that's not databound
<hatch> so ok this is all for the old UI
<hatch> ctrl+a del+
<hatch> it's so nice working directly in Ubuntu
<rick_h_> hatch: <3
<hatch> :)
<rick_h_> jcsackett: how you doing? need a hand duping tests on that one branch still or anything?
<jcsackett> rick_h_: i was able to replicate them, with some pain, locally, and i think i fixed them. watching CI again now.
<jcsackett> rick_h_: and fortunately working on the last of the mv work as i wait, so things continue along.
<jcsackett> rick_h_: that stupid branch, man.
<rick_h_> jcsackett: ok, ping if you need anything
<rick_h_> Makyo: did you replicate frankban's QA issue at all?
<Makyo> rick_h_, Oh, hm, I didn't try that.  Back up and running, will focus.
<Makyo> rick_h_, it's existing, shouldn't block kadams54 - I'll get on that right now.
<rick_h_> Makyo: ty!
<rick_h_> kadams54: can you let me know when you address frankban's comments then and go ahead and land that one please?
<kadams54> rick_h_: sure. Was planning on doing that after I finished QA on hatch's PR.
<rick_h_> kadams54: ok cool thanks
<hatch> ugh just waisted an hour on tests which don't matter
 * hatch throws a "our test suite is a mess" hissy fit
<hatch> kadams54: I'm just about ready to push up the tests - any big issues?
<kadams54> hatch: Don't know.
<kadams54> hatch: Or: yes.
<hatch> wait I lied...I have another failing test
<hatch> there is an issue?
<kadams54> hatch: I ran into an uncaught error while just trying to deploy mysql. I'm not sure if it's on your branch or a regression in develop. I'm checking develop now.
<hatch> hmm I can deploy it here so I hope it's develop heh
<kadams54> guihelp: well fudge. develop seems to have a pretty serious regression on it. This is what I get when I just try to drag-n-drop a service to the canvas (selecting auto-deploy in the deploy summary for the units):
<kadams54> "Uncaught TypeError: Cannot read property 'apply' of undefined", environment-change-set.js:244
<rick_h_> kadams54: I can replicate here, in the function call the env is a list vs a single environment
<rick_h_> jujugui http://paste.ubuntu.com/8420601/ is the breakage point and the value of env is a list of two items long
<kadams54> rick_h_: Maybe introduced by the multi-ecs work then? I haven't done any deeper digging (bisecting) so that's purely a guess.
<rick_h_> yep, here  Y.soon(Y.bind(this._commitNext, this, [env, currentIndex]));
<rick_h_> that is broken and passing env, index around as env
<rick_h_> _commitNext: function(env, currentIndex) { is the signature
<rick_h_> so the [] is not needed
<rick_h_> or is off or something
<hatch> +129  â390   awww yeah
<rick_h_> kadams54: ok, keep going on QA, I'm going to do a quick test removing the [] and make sure that fixes it
<kadams54> rick_h_: will do
<hatch> jujugui my branch is completely finished now and ready for reviews/qa https://github.com/juju/juju-gui/pull/584
<rick_h_> hatch: rgr
<hatch> rick_h_: where is your test :PPP
<hatch> rick_h_: what would you like me on?
<rick_h_> hatch: so general QA and reach out if anyone needs a hand like jcsackett with the FF or Makyo with the relation line issue. 
 * hatch opens arms "come to me with your problems"
<rick_h_> hah
<hatch> I can hop on some more reviews once your fix lands
<hatch> the ci box is just burrrrnin
<rick_h_> we've got 5 branches in the queue to get through CI and then I can work on the release tonight at the coffee shop
<kadams54> jujugui: FYI, I'm going to have to leave for dinner/family stuff around 5, but should be back on around 6.
<rick_h_> kadams54: ok, what's left on your plate between now and 5?
<hatch> I cleared my schedule (because it was SOOOO full) for tonight if we need extra backup
<rick_h_> hatch: hah, no kiting to celebrate pre-release?
<hatch> no wind!
<kadams54> rick_h_: I just addressed frankban's comments on my PR#583. Hopefully the merge build will go through fine and I'll be able to ship that.
<rick_h_> kadams54: ok cool
<rick_h_> kadams54: then enjoy dinner and if anything goes boom we'll get it covered. Thanks for the work today!
<kadams54> rick_h_: Currently QAing Jeff's in a real env (i.e., off his branch and not with latest from develop merged in) and trying to figure why I'm not seeing an orange exclamation mark.
<rick_h_> kadams54: ok, I'm loading a live env as well atm
<kadams54> Yeah, that's why I'm not yelling at hatch yet :-)
<kadams54> Since you didn't run into any problems.
<rick_h_> kadams54: yea, maybe check the source and it's a build issue where the css has an issue or something
<Makyo> jujugui https://github.com/juju/juju-gui/pull/586 quick relations thing, just moving some code to the right place.
<rick_h_> Makyo: looking while the source updates on jeff's live env
 * Makyo runs to exercise dogs real quick
<kadams54> *sigh* Just had to explain to my second grader that whacking the iPhone is not going to solve the problems he's experiencing.
<rick_h_> lol
<rick_h_> "does it bend?! I mean blend?!"
<hatch> lol
<kadams54> He seems determined to prove that even 5Ses are prone to bendingâ¦
<kadams54> Provided you whack them repeatedly when Minecraft freezes up.
<hatch> give him an 80's Nintendo controller - those things were bullet proof
<rick_h_> "I TOLD you this one's dead I need a new one!"
<hatch> haha
<kadams54> Too bad the cartredges weren't ;-)
<hatch> truth
<hatch> but the crt tv screens were very strong so you could huck that controller at it
<kadams54> None of the "Wiimote through the brand new flatscreen" problems.
<hatch> exactly....things just aren't made like they used to be
<rick_h_> woot! hatch qa ok on a live env here
<kadams54> hatch: I don't see any related CSS. Does the orange exclamation mark come from _showConflictUI?
<hatch> yusssss
<rick_h_> orange point works for me
<hatch> kadams54: it's always been there
<rick_h_> in both dev and live lxc env
<hatch> that was all the oldschool UI I just hooked up
<kadams54> Ok
<kadams54> Holy crap hatch, you weren't kidding when you said CI was on fire.
<hatch> haha yup
<rick_h_> shhhh, she's behaving at the moment
<rick_h_> go baby go!
<hatch> lol right
<kadams54> hatch, rick_h_: Well I gotta pack up. I'll have to circle back on Jeff's branch and the problems I'm having later tonight. I'll also check on my PR and make sure the merge build went through OK.
<kadams54> It may take until 6 before that thing actually builds :-)
<hatch> haha
<kadams54> See ya'll in a bit.
<rick_h_> kadams54: all good, Makyo can you do a second opinion  on hatch's branch please?
<rick_h_> hatch: you looking to be a second on Makyo's branch?
<rick_h_> hatch: I did QA so just need second review
<hatch> on it
<rick_h_> jujugui wife is tied up at work so I have to get the boy. Carry on and I'll be back shortly. 
<jrwren_> I'm EOD. I'll chat ya'll tomorrow.
<hatch> cya jrwren_
<jcsackett> hatch: can you look at the cursed branch? it finally finished its CI run and now has *more* errors.
<jcsackett> at this point i think i might be breaking it rather than fixing it.
<hatch> jcsackett: haha ok looking
<hatch> jcsackett: very odd....
<jcsackett> Not so much odd as a damn mess. 
<hatch> jcsackett: can you land it in smaller bits? Or is this all required?
<jcsackett> I mean, that *is* one small bit. 
<hatch> yeah I mean there isn't much code changes for all the tests that need changing
<hatch> are all the test changes necessary with that code change?
<hatch> jcsackett: well the good news is that I can reproduce the failure locally
<jcsackett> Really? Cause I can't. That passed. 
<jcsackett> What did you do?
<hatch> just ran them in FF
<hatch> failed hard first run
<hatch> that's where they are failing in CI too
<hatch> they pass fine for you?
<jcsackett> Yeah. Or I wouldn't have submitted. 
<rick_h_> hatch: can you pick it up since you can dupe please?
<rick_h_> jcsackett: and you can run with the otehrs 
<jcsackett> Works for me, if that works for hatch. 
<rick_h_> I'll bribe him with a mouse 
<hatch> lol
<hatch> you could pay for my geekdesk? :P
<hatch> yeah I'll take over on this
<rick_h_> lol, man price of a bribe is going way up
<rick_h_> jcsackett: can you get hatch the starter commit sha?
<hatch> haha - other cheaper options include a PS4
<rick_h_> jcsackett: I think maybe all the work to 'make them pass' might have left things worst than they started out at
<hatch> Destiny for PS4
<hatch> hmm....that's all for now
<hatch> I will just start from scratch
<hatch> jic
<jcsackett> hatch: i can send you the initial branch. 
<hatch> nah it's ok I got the commits
<jcsackett> hatch: basically just grab the app/app.js flag stuff. the endpoints bit can be ignored.
<jcsackett> and it's the app setting the ecs on by default that started all this fallout.
<hatch> cool
<Makyo> We wearing jenkins out?
<rick_h_> npm out
<rick_h_> npm is getting angry at all the downloading
<Makyo> Boo
<rick_h_> Makyo: how went the QA of hatch's stuff?
<Makyo> Oh, it went okay, one sec.
<rick_h_> Makyo: lint error in your branch killing CI
<rick_h_> Makyo: sorry, I misread it the first time I looked
<rick_h_> test/test_environment_view.js: line 1032, col 51, Missing semicolon. (W033)
<rick_h_> Makyo: ^
<Makyo> rick_h_, ack, on it
<rick_h_> jujugui I'm going to head off to the coffeee shop for CHC tonight. I'll check in from there in 45ish. Makyo if QA goes well please ship hatch's and if anyone sees kadams back ask about his branch. He's pushed another commit of comments, but not sure if it's ready foir landing
<Makyo> Sounds good.  SEe ya later
<hatch> jcsackett: so here is the problem....as far as what's causing it...I have no idea       `  http://0.0.0.0:8888/login/undefinedapi/3/search/interesting `
<jcsackett> hatch: should i run my localhost for that, or is taht something else?
<jcsackett> oh!
<jcsackett> i missed the undefined.
<jcsackett> that's...*really* weird.
<hatch> it happens when I add the ecs to the env
<hatch> for the endpoints
<hatch> (which needs to be done else it fails even sooner)
<hatch> jcsackett: even if I skip the ecs and just stub out the deployer bar instantiate method I get the same issue
<hatch> going to take a bit longer
<jcsackett> hatch: if you're still grinding after i finish off the other flag locations i'll start poking back at it.
<hatch> jcsackett: ok so for some reason the test is passing...but then comes back and fails in the 'after' because the url was changed to /login
<hatch> lol
<hatch> jcsackett: solved that one
<hatch> the env had no creds so it would redirect the user away
<jcsackett> hatch: interesting.
<jcsackett> i wonder why removing the mv flag would cause that.
<hatch> who the heck knows
<hatch> another failure down....
<hatch> lets see if this works
<hatch> oo it passed all the tests in debug
<jcsackett> hatch: hopefully you won't have my situation where that means *nothing*. :p
<hatch> hahaha
<jcsackett> and if it does, i'm removing my LXC and going to go the vagrant route.
<jcsackett> er, and if you don't, rather.
<hatch> well my fixes are totally different than yours
<hatch> well...same idea
<hatch> different approach
<hatch> jcsackett: well....it failed spectacularly in the browser
<jcsackett> hatch: i'm sorry to hear that.
<hatch> like...ka....fricken...boom!
<hatch> good news
<hatch> different tests failed
<hatch> lol
<hatch> progress??
<hatch> oo only 15 failures in the browser now
<hatch> why are they always part of notifications...sonofa
<hatch> jcsackett: got it
<jcsackett> hatch: nice.
<jcsackett> i can review it.
<hatch> just running lint then I'll push up
<hatch> jcsackett: https://github.com/juju/juju-gui/pull/587
 * hatch crosses fingers it works in CI
<rick_h_> poor poor CI
 * rick_h_ remembered that he needs to generate the changelog...o...m...g
<hatch> lol
<rick_h_> woot! my big picture frames of the CA trip shipped. 
<rick_h_> Tomorrow is going to be win win win
<hatch> riiiight on
<hatch> amazon.com has the playstation pkg I want but they won't ship to Canada :///////
<hatch> I could understand if amazon.ca had them....but seriously they ship from the same damn warehouse
<hatch> oh I also have to do that blog post tonight
<rick_h_> hatch: :P
<rick_h_> hatch: though you can do friday as well if you need
<rick_h_> hatch: do it during the day tomorrow
<rick_h_> hatch: lots of time :)
<rick_h_> lol https://www.youtube.com/watch?v=IROcoJeVfSI#t=348 well my new motox won't bend at least :)
<hatch> gooood idea
<rick_h_> ok, land all the things, anger the CI gods for a few more branches
<rick_h_> time to get changelogging
<hatch> I can't believe I'm watching this
<rick_h_> lol
<rick_h_> I didn't have sound so you've got more info than me
<hatch> 3 branches to go......go go ci go
<jcsackett> rick_h_: are we comfortable releasing without all the MV cleanup done?
<hatch> jcsackett: I don't think there would be much issue
<hatch> some code bloat but I don't think there is any real side effects
<hatch> not that you were asking ME
<hatch> :P
<rick_h_> jcsackett: yes
<rick_h_> jcsackett: and I think we can plan on another release next week
<rick_h_> jcsackett: with some cleanup and bug fixes/etc
<rick_h_> jcsackett: so don't go all night if you're not going to make it
<rick_h_> well, I take that back. Don't go all night even if you will make it
<hatch> haha
<jcsackett> rick_h_: i'm going to keep hacking at this b/c i'm mad at it, but good to know. :)
<rick_h_> jcsackett: it's 7:30pm man. Go to dinner followed by bed 
<rick_h_> if we hit any issues tomorrow I'll need you all to help
<rick_h_> jcsackett: and getting this done isn't going to change anything release-wise
<rick_h_> seriously, go rub your wife's feet or something :P
 * jcsackett laughs
<hatch> OR
<hatch> she could rub yours!
<jcsackett> she's not home yet. when she gets home, i'll kick off.
<jcsackett> hatch: that's not going to happen. :p
<hatch> lol well it was worth a try
<rick_h_> ok commit log isn't all that bad actually
<rick_h_> since 1.1.1 we've basically worked out $#$#@ off on MV
<hatch> oh no huw today
<rick_h_> oh yea, it's his thurs
<rick_h_> he's finally swap daying london
<hatch> yeah I got to do that!!
 * hatch looks at calendar
<hatch> ugh my branch failed
<hatch> wth it passed in everything locally
<rick_h_> hatch: yea, giving it another shot
<hatch> nah it'll fail
<rick_h_> hatch: but if you want to see if you can dupe that'd be cool
<hatch> I know how to fix it
<hatch> but I can't dupe
<rick_h_> party
 * rick_h_ runs away
<hatch> so will just have to be a hope and a dream hah
<rick_h_> hah, hopes and dreams, we're UI Engineering
#juju-gui 2014-09-25
<jcsackett> so are hopes and dreams our stock in trade?
<rick_h_> hatch: you're right, both test and lander failed very close to the same
<rick_h_> hatch: are you poking at it?
<hatch> rick_h_: yes fix has been pushed
<hatch> will see how this goes
<rick_h_> hatch: coolio
<rick_h_> hatch: no hury, I'm doing release now. It can move forward without it 
<hatch> oh you sure? ok
<rick_h_> hatch: yea, at 30min a test run it'll be a bit to verify/etc and I'm going to move forward. We'll get it landed tomorrow and such
<rick_h_> hatch: thanks for updating and we'll see how it goes
<hatch> sounds like a plan
<rick_h_> go go bzr go go 
<rick_h_> go go bzr go go go ...bzr be good
 * rick_h_ starts up the live charm tests...go go go
 * rick_h_ crosses fingers
<jcastro> has anyone had issues with the inspector not showing up on click?
<rick_h_> jcsastro: not that I'm aware of at the moment. 
<rick_h_> jcastro: is this the new charm that went out today? 
<jcastro> yeah
<jcastro> but jujucharms seems to work
<jcastro> don't worry, only on my laptop, not in front of anyone. :)
<rick_h_> hmm, ok
<jcastro> rick_h_, you have an upcoming release right?
<jcastro> I'd like to realign the ob's to use the latest stable one
<jcastro> currently they're on older ones
<rick_h_> jcastro: yes, charm and site went out around midnight EST 
<fabrice> rick_h_:  you are not sleeping ?
<rick_h_> we're working with marketing to make a huge splash today
<rick_h_> fabrice: I did, now I have a meeting, then back to sleep
<jcastro> <3
<jcastro> nice work dude
<fabrice> rick_h_: :)
<rick_h_> jcastro: <3
<rick_h_> jcastro: let me know if you see something though, we'll be poking at it some more now that the release is put together but nothing came out in QA last few days 
<jcastro> yeah it just feels like the inspector summoning/banishing is flakey 
<jcastro> both on chrome stable and unstable
<jcastro> also in general sometimes I want to click and I still get the relation popup thing, but that's a design issue I think, that can wait until later
<rick_h_> rgr, we will look into it thanks jcastro 
<rick_h_> frankban: do you have a few min to see if you can verify in any way. 
<rick_h_> jcastro: this is on a real deployed version?
<jcastro> yeah, on my local machine
<rick_h_> jcastro: sorry, a live environment you're seeing this 
<rick_h_> jcastro: rgr
<frankban> rick_h_: I'll take a look if I can dupe inspector not showing up in a real env
<rick_h_> frankban: ty
<frankban> rick_h_: in the meanwhile, jujucharms.com updated!
<rick_h_> frankban: ty for the deploy as well yay! 
<frankban> rick_h_: there was a hook problem in upgrading the charm, jacekn filed a bug, I am creating a card for that
<rick_h_> frankban: rgr, I tried to load that bug but it failed to come up. curious what's up
<frankban> rick_h_: can you see it now? https://bugs.launchpad.net/charms/+source/juju-gui/+bug/1373875
<rick_h_> frankban: no, says "lost something" and getting 404
<frankban> rick_h_: it's a private bug, I subscribed you, can you see it now?
<rick_h_> frankban: ah ty 
<rick_h_> frankban: yes I can see it now
<frankban> rick_h_: cool
<frankban> jcastro: I am not beeing able to dupe the inspector bug on a local env with three deployed services using both chrome and firefox. any specific steps?
<jcastro> I'll follow up with you after we finish here with these customers
<frankban> jcastro: cpp;
<frankban> cool even
<jcastro> frankban, what version of the charm should we be on?
<frankban> jcastro: I am trying with cs:trusty/juju-gui-8
<rick_h_> frankban: available to start our call a couple of min early?
 * rick_h_ has a break for nap time slotted after it :)
<frankban> rick_h_: now is ok
<frankban> rick_h_: I am in the hangout
 * frankban lunches
<rick_h_> luca: jujucharms.com is updated and stuff is live
<rick_h_> luca__: sally will start hunting you for your blog post, congrats and yay
<luca__> rick_h_: haha thanks
<luca__> rick_h_: has it all been released?
<rick_h_> morning take two
<hatch> mornin 
<hatch> jcsackett: rick_h_ so it seems that everywhere where we create a new environment needs the ecs passed in - I'll continue fixing those up this morning
<rick_h_> hatch: k, one thing to think about is either having that do some default work or making a factory method that handles that
<jcsackett> morning.
<jcsackett> hatch: yeah, i was encountering the same sort of issue when i was trying to fix that.
<hatch> rick_h_: I was thinking that but it is only a couple lines per test and some tests use mocks
<hatch> so I think a factory won't get us much
<rick_h_> hatch: rgr
<jcsackett> hatch: if you start hitting env/go.js related stuff, let me know. that's the part i'm currently working on and we might need to coordinate.
<jcsackett> hatch: don't know about you, but i am discovering that `make test-debug` is not remotely reliable for tracking failures in this work.
<hatch> jcsackett: tbh I can't figure out why it doesn't fail
<hatch> I think it's too fast
 * jcsackett nods
<hatch> and even in the browser it's too fast
<hatch> app.js is poorly constructed anyways - but we've always known that
<jcsackett> hatch: i've also found that it'll crash out and report significantly fewer errors then there actually are.
<hatch> jcsackett: yeah - but that also happens in the browser
<jcsackett> hatch: oh goody.
<hatch> that's because of how mocha works and how we have structured the tests
<jcsackett> well, i haven't seen that happen in the browser yet, at least.
<jcsackett> hatch: so, basically our tests are riddled with structural problems that make this harder? awesome! :p
<hatch> and our code
<hatch> the next season of House of Cards will be about the GUI
<rick_h_> die mocha die
<hatch> haha it's only partly mochas fault
<hatch> tbh there isn't exactly a better alternative
<rick_h_> meh, I still want it to die
<jcsackett> +100000000
<jcsackett> if only b/c at this point i'm feeling vindictive towards it.
<jcsackett> :p
<rick_h_> anger leads to hate, hate leads to wanting it to die
<jcsackett> wanting it do die leads to the dark side?
<rick_h_> psh, I'm working on getting promoted up the dark side chain of command and gaining choke powers
<jcsackett> let me know when you get lightning powers--i have a neighbor i could use your help with.
<rick_h_> jujugui call in 10
<rick_h_> frankban: you've got the call today
<rick_h_> jujugui I won't be joining, I have more crazy calls to do today 
<rick_h_> and I'm fix releasing bugs so watch out for the email onslaught!
<frankban> kadams54, urulama-afk: hangout?
<kadams54> frankban: will be there in a moment, as soon as Google lets me in :-\
<hatch> jcsackett: er mah gerd https://github.com/juju/juju-gui/pull/587#issuecomment-56832589
<jcsackett> hatch: WHOOOOO!!!!
<hatch> now to rebase and ship
<rick_h_> :)
<hatch> I'm going to wait on the rebased tests to pass before shipping just to be safe
<hatch> don't want something spurious to get into develop
<hatch> jujugui who has a ps4? More importantly who has a PS version of Destiny?
<jcsackett> hatch: you are really into the whole destiny thing, huh? :p
<hatch> no I just want what I want - since I can't get what I want for a price I want I'm getting  what I don't want 
<hatch> want
<hatch> :
<hatch> P
<kadams54> Well, that makes as much sense as everything else hatch says.
<kadams54> ;-)
<hatch> it's true
<hatch> so 
<kadams54> lol
<hatch> no other gamers eh?
<kadams54> Umâ¦ does Boom Beach count?
<hatch> I
<hatch>  don't even want to google that
<kadams54> lol
<kadams54> Having kids has curtailed my gaming activities. Icksnay on the time-sucking massively multiplayer type games.
<hatch> you don't have them gaming?
<hatch> or too young?
<frankban> hatch: I have a ps4 but I don't think I am going to buy that game, it seems diablo-like, too much life consuming
<jrwren> There is only starcraft2.
<frankban> hatch: I played the last of us on the ps4 and it is quite impressive FYI
<hatch> frankban: well it's more like a FPS with mmo like elements
<hatch> jrwren: lol - we should have a lan party in brussels :P
<hatch> can you even have lan parties anymore?
<hatch> I'm betting it all has to go through a central server
<jrwren> hatch: DreamHack is this weekend, but LAN only is no longer a thing. All the games require internet connections.
<hatch> :(
<jrwren> hatch: we can still play in same room in brussels. Its still fun.
<hatch> if the internet is fast enough
<hatch> I'll do the lag hack on you and win
<hatch> it really is the only way I'll be able to
<hatch> frankban: atm the only ps4 pkg is the Last Of Us package - so it's worth getting?
<frankban> hatch: I got the last of us at about 45 euros, and it includes the nice "left behind" dlc. I think it's really worth playing it
<hatch> cool
<hatch> I've had only xbox since release day of 'Xbox''
<hatch> switching camps is sad to see all those gamerpoints go
<hatch> jcsackett: passed after refactoring so I'm shipping it
<hatch> feel free to pull my changes into your branch if you like
<rick_h_> luca__: you hear from sally at all?
<luca__> rick_h_: no, I was going to speak to her
<rick_h_> luca__: ok, my understanding was release today, homepage takeover tomorrow
<luca__> rick_h_: My blog post will be going for review with Ale in about half an hour
<rick_h_> but it's feeling late in your day for that. Maybe it's all for tomorrow?
<luca__> rick_h_: ok
<luca__> rick_h_: Iâll go and speak with her
<luca__> rick_h_: sec
<rick_h_> luca__: cool thanks
<rick_h_> hatch: how's your blog post?
<hatch> rick_h_: working on it now - just got the other branch to be landable
<rick_h_> hatch: cool
<hatch> thanks to 
<hatch> tinder every time I log into tumblr I think I'm visiting a porn site
<rick_h_> hatch: kadams54 jcsackett Makyo can you guys jump in the standup hangout for a sec?
<hatch> joining
<kadams54> sure
<rick_h_> jcsackett: ping when you get back/around
<jcsackett> rick_h_: i just jumped in the hangout as people logged out.
<jcsackett> sorry, was packing things up for a meeting
<jcsackett> rick_h_: i can talk now if it's short or ping you about 1:30ish?
<rick_h_> jcsackett: sure jump back in
<luca__> rick_h_: all posts and takeovers are going up tomorrow
<rick_h_> luca__: ah, ok. well :P
<rick_h_> hatch: ^
<rick_h_> hatch: so if you could be ready with your post and space to embed the video once it's up it'd be great
<hatch> yeah for sure - I was also hoping to get links to the other articles and such to link to
<rick_h_> hatch: yep, sounds like I won't have urls for those until tomorrow
<hatch> yeah np - I can add them in after, I'll also not make it public until tomorrow 
<hatch> I could time the release for EU morning too if we wanted
<rick_h_> hatch: well let's do it in your AM if that's cool. 
<rick_h_> then it'll be a follow up vs all at the same time
<hatch> yep np
<rick_h_> or even later in the day, when you get a chance
<rick_h_> mad rush of things with canonical logos, then a follow up without 
<hatch> well I can do it on a timer vs manual if we wanted a specific time
 * luca__ has just seen his spamed up emailâ¦
<rick_h_> bwuhahhaha, mark all luca__'s bugs as invalid!
<hatch> lol
<luca__> rick_h_: haha
<rick_h_> luca__: wine time tonight!
<rick_h_> jcsackett: kadams54 can we punt on today's calls as s/1-1 call/happy release dance ?
<kadams54> Sure.
<rick_h_> jcsackett: kadams54 and if not no problem, we can chat
<rick_h_> but I'll be doing a happy dance while we chat, fair warning :P
<kadams54> :-b
<kadams54> Break out the glowsticks
<kadams54> https://www.youtube.com/watch?v=Zx1eDmuYQg8
<rick_h_> woot
<rick_h_> hatch: can you point me at the bug you fixed recently around the config options and the GUI that caused your mysql issues?
<hatch> ohh
<hatch> hmm
<hatch> gimme a few
<rick_h_> hatch: rgr, looking here as well but I think the title was a bit off from the end result if I recall
<hatch> holy the kanban is clean
<lazyPower> so
<lazyPower> i just deployed the new gui, and noticed machine view is in there
<mbruzek> rick_h_: I just saw the new GUI, that looks AWESOME!
<lazyPower> i have one hashtag for you guys
<lazyPower> #badass
<hatch> :D
<rick_h_> lazyPower: yes, we'll have full announcements and videos and blog posts tomorrow coordinated with pr
<mbruzek> The machine view is bad ass
<lazyPower> 1 suggestion, and this may be a deal breaker - the cookie notifier hides stuff from me
<rick_h_> yes, we're hoping we can create some new gui users over this. 
<lazyPower> i was looking for commit and it was all tucked away under the UK Mandated cookie banner
<rick_h_> lazyPower: yes, we're working with UX on it. We have to have it and are trying to find a way to make it less painful
<mbruzek> Love the change log too
<lazyPower> <3
<lazyPower> you guys did awesome
<lazyPower> and *are doing* awesome
<mbruzek> nice
<rick_h_> Makyo: have a link to your youtube handy for lazyPower and mbruzek while we wait on pr for tomorrow?
<rick_h_> lazyPower: mbruzek thanks for checking it out and if you love it please help spread the word. We know a lot of people don't feel the gui fits their uses but with MV we're hoping some poeple will give it another shot and rethink it
<Makyo> rick_h_, lazyPower mbruzek https://www.youtube.com/watch?v=rEiwKLfzlX8
<rick_h_> lazyPower: mbruzek and comments from people not on our team as appreciated towards that end
<rick_h_> thanks Makyo 
<mbruzek> Thanks for the link.
<rick_h_> we'll be making a big fuss tomorrow with a ton of links and material to introduce it so keep an eye out
<hatch> rick_h_: https://bugs.launchpad.net/juju-gui/+bug/1365205
<mup> Bug #1365205: Charm cannot be deployed, fails on install hook with gpg error <juju-gui:Fix Released> <mysql (Juju Charms Collection):Invalid> <https://launchpad.net/bugs/1365205>
<rick_h_> hatch: <3 ty
<rick_h_> jujugui heads up no AU calls tonight. Huw is afk today. 
<hatch> a o k
<hatch> first post release bug report https://bugs.launchpad.net/juju-gui/+bug/1374050
<mup> Bug #1374050: Inspector stays open after destroying a ghost service <juju-gui:New> <https://launchpad.net/bugs/1374050>
<hatch> I win
<rick_h_> lol
<rick_h_> ok, smallish one. I can live with that. 
<rick_h_> Makyo: up for taking a peek? ^
<rick_h_> BradCrittenden: speaking of sorry, we wanted to sync up. Do you have time?
<hatch> rick_h_:  my branches landing failure is legit - but it only happens while merging :/
<hatch> I'll push up some updates soon
<rick_h_> hatch: rgr
<BradCrittenden> rick_h_: chat in a few minutes?
<rick_h_> bac: k
<bac> rick_h_: https://plus.google.com/hangouts/_/canonical.com/rick?authuser=0
<rick_h_> go go gadget chrome
<Makyo> rick_h_, sorry, was outside.  Got it.
<rick_h_> Makyo: all good, thanks
<rick_h_> go go gadget firefox
<rick_h_> bac: ok, made it in
 * jcsackett finally checks email, grins at the ton of bug mail.
<rick_h_> close em all!
<rick_h_> well, all but 210 of them :/
 * rick_h_ needs to spend some more bug time tomorrow
<rick_h_> bac: died on me here. 
 * hatch stepping out for lunch
<Makyo> Huh, can't reproduce this bug, is the description missing a step?
<rick_h_> jujugui going to get lunch and then dr apt at 3pm so probably won't be back until late tonight if anyone needs anything
<marcoceppi> rick_h_:  et al
<marcoceppi> did machine view launch?
<Makyo> marcoceppi, deployed to jujucharms.com, official release stuff is tomorrow.
<Makyo> hatch, do you have any more detail on that bug?  Can't reproduce for the life of me.
<hatch> Makyo: on sandbox?
<Makyo> hatch, yep. Destroying a service clears state for me
<hatch> hmm lemme try again
<hatch> Makyo: well wth
<hatch> I also can no longer reproduce
<hatch> so sorry
<hatch> I don't know what happened
<Makyo> No, that's a good thing :)
<hatch> haha I suppose
<hatch> bah we are having serious power/internet issues atm
<hatch> well not serious
<hatch> but irritating
<hatch> haha
<rick_h_> marcoceppi: yep, what Makyo said. PR push is tomorrow but the code is out today
<rick_h_> marcoceppi: I see you're doing a talk, feel free to show MV there
<rick_h_> marcoceppi: if it's something that fits your presentatoin
<hatch> it sure seems like people are going to like this mv
<hatch> cant wait to see what else people have to say about it heh
<marcoceppi> rick_h_: it just popped up in my gui for the demo
<marcoceppi> so I was like, uhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
<marcoceppi> but I'm definitely going to use it for the demo
<marcoceppi> rock on
<marcoceppi> Makyo: hatch rick_h_ team, etc, et al, really fucking fantastic job on the machine view stuff
<rick_h_> marcoceppi: cool
<rick_h_> marcoceppi: glad you like it :)
<marcoceppi> it's going to make my talks soooo much easier to explain and may have me permenantly move to gui for working with juju ;)
<rick_h_> well, you can wait until we add debug log into there later this cycle before you move GUI only :P
<marcoceppi> :O
<marcoceppi> if you could find a way to put debug hooks in there ;) I'd never use the command line again :P
<rick_h_> marcoceppi: one thing to be aware of, we disable containers for most providers (other than maas) right now since you can't route network traffic to the public
<marcoceppi> rick_h_: cool
<rick_h_> marcoceppi: so that users don't put wordpress in a container, expose it, and think they can view it from their browser
<rick_h_> marcoceppi: but we've got a flag to override that /:flags:/containers
<rick_h_> marcoceppi: so add that to the url and it'll over ride it. So if you know what you're doing, and put haproxy on the root, mysql and wordpress in lxc containers, you can do nice demos on ec2 for instance
<rick_h_> then only expose haproxy and everything works
<marcoceppi> gotchya, I won't be doing anything crazy like that
<marcoceppi> I'll wait for juju to figure all that out
<marcoceppi> good to know
<rick_h_> cool
 * rick_h_ hits eod and goes to get the boy from day care
<marcoceppi> hum, commit doesn't seem to be working
<marcoceppi> oh, there it goes
<hatch> marcoceppi: if you run into any oddities plz do let us know :)
#juju-gui 2014-09-26
<marcoceppi> hazmat: I ran in to an issue
<marcoceppi> hatch ^^
<marcoceppi> but he's offline
<marcoceppi> I'll file bugs
<rick_h_> marcoceppi: definitely, anything big?
<marcoceppi> rick_h_: well, commit doesn't tell me anything
<marcoceppi> like I press commit
<marcoceppi> then wait
<marcoceppi> and hope
<marcoceppi> and pray
<rick_h_> huh? you don't get the summary? 
<marcoceppi> well, I get summary
<rick_h_> and then all the blue circles should turn yellow
<marcoceppi> then I'm like "make it so"
<marcoceppi> not after some time of lag
<rick_h_> and then they turn off the cirlces as Juju takes the commands?
<marcoceppi> and it says X items to commit at the bottom
<marcoceppi> needs like a spinner
<marcoceppi> or something on the commit button
<rick_h_> marcoceppi: hmm, ok. We'll take a look at it. 
<marcoceppi> so I know it's working
<rick_h_> it should be resetting the button after you commit
<marcoceppi> a few times I tried to deploy and never got the confirmation screen on commit
<rick_h_> we allow you to stack sets of changes, you don't have to wait for one to complete before starting another one
<marcoceppi> had to hard refresh and try again
<marcoceppi> interesting
<marcoceppi> I didn't capture any debug output
<marcoceppi> I'll try again to replicate
<rick_h_> ok, what provider was this? Was the network slow? I want to try to match up our QA/replication. 
<marcoceppi> yeah
<marcoceppi> it was local provider and I was connect to my home machine over sshuttle
<rick_h_> marcoceppi: ok, thanks a ton for the feedback. I can see where there might be some issues to make more solid there. 
<marcoceppi> since I was 25 machines deep
<marcoceppi> rick_h_: np, I'll try to videotape/record the issue with deploying a service if it crops up again
<marcoceppi> hard to explain
<rick_h_> ok, we can try to replicate some slower network and do some more looking at it. Most of our QA is just our machine on lxc, ec2, azure, and maas
<marcoceppi> otherwise it was a great experience
<rick_h_> ok cool, hopefully worth the growing pains of a new release the day of
<marcoceppi> Iw as able to answer the density question by using the machine view
<rick_h_> we'll get it more polished for sure
<marcoceppi> hah, worth it
<marcoceppi> I explained that this was like brand new
<marcoceppi> and played it down
<marcoceppi> everyone loves a live demo anyways
<rick_h_> lol
<rick_h_> you know it
<rick_h_> yea, please do file bugs with as much info as you can pull together and we'll look into it. 
<marcoceppi> def
 * fabrice going for lunch with friends
<rick_h_> morning
<rick_h_> boom! https://insights.ubuntu.com/2014/09/26/juju-machine-view-more-control-at-your-fingertips/
<rick_h_> go team go, go team go!
<rick_h_> luca__: ok email to canonical-tech sent
<luca__> rick_h_: nice
 * rick_h_ ducks
<rick_h_> ok, posts out, email out, sharing has begun, filed over at the juju reddit...now time for breakfast
<jcsackett> there's a juju reddit?
<jcsackett> huh. i'll be damned. neat.
<rick_h_> hah
<rick_h_> Makyo's video is outpacing mine. They love his professional tones! :)
<jcsackett> Makyo does have a very good "presenting" voice.
<jcsackett> rick_h_: did we test the charm with charm-upgrade? b/c for grins i upgraded my installation this morning (for my blog and stuff) and i'm not seeing changes. :(
<jcsackett> upgraded to cs:trusty/juju-gui-8
<rick_h_> jcsackett: so it worked on staging and had an error on production
<rick_h_> jcsackett: check for an error with a symlink command. frankban was looking into it and seeing it he could replicate it
<jcsackett> rick_h_: did it come up in `juju status`? b/c i'm getting no errors reported.
<rick_h_> jcsackett: not sure, it was noted in the RT that they hit the error and worked around it by killing the directory and resolving/retry. 
<frankban> jcsackett: have you set juju-gui-source to 1.2.0?
<rick_h_> which I guess means it hit an error
<rick_h_> frankban: oh that's a good point, we have those notes in the prodstack stuff but that's non-obvious if people just try to upgrade their charm :/
<rick_h_> ugh, that's a horrible ux sorry jcsackett. Never thought about that 
<jcsackett> frankban: my gui-source appears to be "local".
<frankban> rick_h_: yeah updating the charm does not mean updating the GUI currently, and that's not obvious
<rick_h_> jcsackett: yea, set it to 1.2.0
<rick_h_> and then watch out
<jcsackett> frankban, rick_h_: does setting gui-source to stable work, or explicit revision required?
<frankban> jcsackett: yeah, but since it didn't change, config-changed does not re-run the GUI installation
<frankban> jcsackett: stable should work
<jcsackett> frankban: well, it's "local" now, so switching to "stable" will run config-changed for me, right?
<rick_h_> jcsackett: right, you have to trigger some sort of 'change' and in production we set a hard value. 
<frankban> jcsackett: but then next time you'll still have to change "stable" to something else, so I'd prefer the specific version
<jcsackett> ah, but then i'll have to set it again to update next time. ok, explicit revision it is. :)
<jcsackett> frankban: indeed. :p
<rick_h_> that darn disconnect between a charm and what it does vs the software contained. 
 * jcsackett nods
<jcsackett> rick_h_: it actually makes sense, if i stopped to think about it.
<rick_h_> jcsackett: yea, but it is still a horrible UX. I'm trying to think of how one would make that more seemless
<jcsackett> rick_h_: i wouldn't want my charm to be tied to the version of the software it installs. ghost is that way now (version is set in the charm and it's a bit of a pain.
<rick_h_> jcsackett: yea, it's not an easy fix for sure
<jcsackett> yeah.
<frankban> rick_h_: we could introduce a new "latest" juju-gui-source option, meaning each time the charm is updated the last revision is downloaded from lp
<jcsackett> whoo! update worked, no problems.
<rick_h_> frankban: hmm, and cron up something that watches it?
<rick_h_> frankban: I was thinking the ideal way would be to get a notification into the GUI itself on charm upgrade or something
<rick_h_> frankban: "There's a new version of the GUI available, would you like to upgrade?"
<rick_h_> frankban: and then the gui can set the source on itself :)
<rick_h_> jcsackett: awesome, <3
<jcsackett> that would be pretty cool, actually.
<frankban> rick_h_: not really a cron, I'd still prefer an explicit user action. it should just run when you upgrade the charm
<rick_h_> but I'm not sure how the GUI would know it had a new source available or something. And what happened if you intentionally set an older version
<rick_h_> frankban: that's true, if you upgrade the charm and the old source isn't there and a new one is, upgrading that source seems resonable at first glance
<rick_h_> the tarball that is, in the releases folder
<hazmat> Makyo, nice work on the voice over the screencast.. you got some complements on it
<rick_h_> sweet
<luca__> Is this sentence true or false? âIn the CLI (command line interface) each unit has to be placed using a specific command, this tends to be quite laborious with most developers scripting it. â
<rick_h_> luca__: not sure checking if add-unit can take a list of placement directives
<luca__> rick_h_: cool :)
<rick_h_> luca__: hmm, help text isn't clear, I'll have to test it out biab
<luca__> rick_h_: ok
<luca__> rick_h_: I just wanted to express the problem
<rick_h_> luca__: yea, I think that's true, but don't want to lie to you
<luca__> rick_h_: Iâll run with it for now
<luca__> >:)
<rick_h_> luca__: bah, hitting ec2 issues due to the big reboot today 
<lazyPower> rick_h_: at some point today, you guys need to pull together an animated gif team photo of your team in front of the machine view gui, and all of you just drop the mic and walk off frame.
<rick_h_> lazyPower: lol
<hatch> holy we have the main page
<rick_h_> :)
<rick_h_> hatch: when you get your post up let me know and I'll make sure to reshare things out as much as I can
<hatch> yeah sure I'll just make some updates now
<rick_h_> np
<hatch> rick_h_:  was there one from design somhwere too?
<rick_h_> luca__: ^
<rick_h_> and Makyo's video races ahead to 100 views https://www.youtube.com/user/celebrateubuntu wheee
<luca__> rick_h_: mine is out for review
<rick_h_> luca__: gotcha hatch ^
<hatch> cool, luca will it be up today?
<Makyo> \o/
<Makyo> Not a big deal, but any chance of changing my name on the post?  It's fine if not, just a bit of a clash with the video.
<rick_h_> Makyo: on the insights one? Did I use matt?
<Makyo> rick_h_, yeah, toward the bottom. Maybe it's just the title of the video, not sure.
<rick_h_> Makyo: I've put in a request for update 
<Makyo> Not a big deal.
<Makyo> Ah, thanks rick_h_ :)
<rick_h_> no, it's a good deal. Sorry about that. It wasn't in my write up but they probably grabbed it from somewhere internalaly
<Makyo> YEah, that's fine!  Since it's taking forever to change it legally, it hasn't propagated.
<rick_h_> https://docs.google.com/a/canonical.com/forms/d/14pS3d21OKnaYVkKV6eLoLtW77GwWEMgPr-sMimoUYNk/viewform
<hatch> luca__: do you think it'll be live today?
<rick_h_> heh, the luca__ tell all book of the century! or blog post forced upon him by peer pressure :P
<hatch> lol
<luca__> hatch: yes
<luca__> haha
<luca__> itâll be done!
<luca__> writting blog posts is so hard
<rick_h_> luca__: what time are we all meeting at the bar?
<luca__> I can never dedicate time for it
<luca__> haha
<luca__> 11am? :D
 * rick_h_ heads for early lunch biab
<hatch> luca__: ok when you're thing is up can you ping me with the url so i can add it to my post?
<luca__> hatch: sure thing, Ale is just reading it now
<hatch> This is interesting http://www.getpostman.com/ looks like CURL but for the browser
<rick_h_> Makyo: name updated
<luca__> rick_h_: hatch ale has had to run off so Iâm not sure if sheâll read it today but Iâve the doc with you guys. If you can read it and give feedback that would be great.
<hatch> ok sure sounds good
<Makyo> rick_h_, thanks!
<rick_h_> jujugui I'm going to EOD early and head out. Thanks again for the great release day! Have a good weekend
<lazyPower> https://plus.google.com/100016143571682046224/posts/PaVGh51FYCR - i'm just going to leave this here...
<jcsackett> lazyPower: awesome!
<fabrice> have a good week end everyone
<sebas5384> what a nice surprise to see the "machine view" in the https://jujucharms.com :)
<sebas5384> what a beautiful work! 
<sebas5384> \o/
<rick_h_> sebas5384: <3 
<sebas5384> rick_h_: :D
<sebas5384> rick_h_: I think we have some problems with the charm store search
<sebas5384> some charms where missing
<rick_h_> sebas5384: let me know which ones are missing and I'll look. We can check if they pass proof (they won't show if they don't) or something else. 
<sebas5384> rick_h_: i think they are back to normal now
<rick_h_> sebas5384: ah ok, sometimes when the stuff updates and the fulltext index is hit they fade for a few min
<sebas5384> ahh ok
<sebas5384> :)
<sebas5384> rick_h_: we started to work in a juju client api
<sebas5384> in javascript
<sebas5384> https://github.com/TallerWebSolutions/macumba.js/tree/promised-based-api
<sebas5384> inspired in the macumba project :P
<sebas5384> but we are a little dependent of the socket opened by the juju-gui
<rick_h_> sebas5384: ok, we've been removing promises as we hit some issues with them in use if they are to the A+ spec
<rick_h_> sebas5384: https://github.com/juju/juju-gui/blob/develop/app/store/env/go.js is our api 
<sebas5384> hmmm rick_h_ good to know
#juju-gui 2014-09-27
<lazyPower> is there a way to auto-arrange icons in the juju-gui? 
<lazyPower> googling yields the answer 'no'
<rick_h_> lazyPower: it's supposed to do some work to keep overlapping down but it needs some love 
<rick_h_> I'll take that response even if it's missing a word in the middle https://twitter.com/esacteksab/status/515895888791621632
#juju-gui 2014-09-28
<rick_h_> closing in on 2k views over the weekend! https://www.youtube.com/user/celebrateubuntu
<huwshimi> Morning
#juju-gui 2015-09-21
<lazypower> rick_h_, ping
<lazypower> urulama, or if you have a moment, ping
<rick_h_> lazypower: what's up?
<rick_h_> lazypower: standup starts in 8 but got a sec until that call starts
<urulama> lazypower: pong
<lazypower> https://bugs.launchpad.net/charms/+bug/1459555 - this is a CPP submission, their charms have landed but they depend on /next branches of the openstack charms
<mup> Bug #1459555: PLUMgrid charms bundle review required <Juju Charms Collection:Fix Committed> <https://launchpad.net/bugs/1459555>
<lazypower> we dont typically promote this, but this also directly reflects their presence at ODS Tokyo, they've been fatigued already by being asked to rewrite their charm suite once, and this has been a 7 month process - is there anything we can do to accomodate them in this extraneous circumstance?
<rick_h_> lazypower: I'm not following. What's the actual issue that's blocking?
<lazypower> rick_h_, that its pointing to non /TRUNK branches of charms
<lazypower> (not theirs, the openstack components)
<rick_h_> lazypower: so in looking 1: they're fixing, 2: they're fixing, 3: ...
<rick_h_> lazypower: oh, the bundle uses non-trunk versions so they're not in the store?
<rick_h_> lazypower: so a couple of paths: 1) they vendor the next charms into their namespace as /trunk and use those for the bundle
<lazypower> right, the plumgrid charms are. they did everything required to land those. There were modifications to openstack itself to support them, and those ar ein /NEXT until end of next month when the OS charms promulgate
<rick_h_> lazypower: 2) they go the local deploy route and use deployer
<rick_h_> lazypower: we can't pull in non-trunk charms. It requires code/changes to charmstore and means every dev branch would be ingested killing the store
<rick_h_> lazypower: so we have to find some path that pulls the charms they need into the store through a normal path. 
<lazypower> ok, so the preferred method would be to "fork" those openstack charms into the plumgrid-team namespace, update the bundle w/ those paths, and we can then push those
<lazypower> once the /next branches land, they nuke those charms and update the bundle to point at ~recommended charms?
<rick_h_> lazypower: yes, vendor them for now until the OS ones move up and then update the bundle to point to the approved ones. Else go local deploy
<rick_h_> lazypower: which if they're doing demo stuff at ODS they should probably do anyway
<rick_h_> lazypower: in case of charmstore lag/network connectivity issues
<rick_h_> lazypower: and if they want folks to use it at ODS, the OS charms will be updated by then correct?
<lazypower> i dont know if the OS charm release will be before ODS Tokyo
<rick_h_> lazypower: yea, I mean you're kind of asking us to get dev charms into teh store for folks to see/use before they think they're ready for folks to see/use?
<lazypower> Oh I wasn't asking if you could rewrite the charm store - i just kno we dont do this and was asking for a recommended path forward for them so a) they get a nice concise handout for consumers @ their booth b) we dont further fatigue them with our process
<lazypower> so it was more for a work around for the month they will be in limbo while /next branches land
<rick_h_> lazypower: understood, yea the vendoring would be the best thing I can suggest, but they should make clear these are non-final/ready OS branches folks really shouldn't use 
<lazypower> Ack, thanks for the clarification rick_h_ 
<rick_h_> lazypower: one good note is that with bundles landing in core we're working on a path that would allow local bundles to include a local copy of charms as well
<rick_h_> lazypower: so we'll be closer to something nicer for a dev/one off case like this...in a few months :/
<lazypower> ack - its not a terrible story where we are right now, its just unfortunate that their timing always seems to coincide with bad news
<rick_h_> lazypower: agreed, wish I had something better. 
<lazypower> rick_h_, this was a pretty specific issue - but i was just re-clued into this being a thing - https://jujucharms.com/u/openstack-charmers-next/     so we may be able to circumnavigate any issues with these branches :)
<rick_h_> lazypower: ah ok
<rick_h_> lazypower: even better
<rick_h_> lazypower: along those lines it falls a bit into https://docs.google.com/document/d/19ndRpWSojtv6kyokeppnRE0MFEMFqd69XeAXp72jBdo/edit if you've got time to read/feedback
<rick_h_> lazypower: e.g. the development channel
<lazypower> will do :)
<rick_h_> lazypower: please let me konw when you poke at thata bundle. It's a known issue we've not been able to get past atm. If that doesn't work then maybe there's another bug I'm not seeing. 
#juju-gui 2015-09-22
<mbruzek> hello rick_h_
<mbruzek> I have a question about your response to https://github.com/CanonicalLtd/jujucharms.com/issues/158
<mbruzek> please ping me when you have time to talk
<hatch> hey mbruzek did you ever get that GUI issue solved?
<rick_h_> mbruzek: shoot
<mbruzek> rick_h_: I get that charmworld does not support v4 bundle format yet.  But what confuses me is the bundle.yaml found at https://code.launchpad.net/%7Echarmers/charms/bundles/plumgrid-ons/bundle looks to me as a v3 bundle format, because I see the bundle name at the top.
<rick_h_> mbruzek: ah, but hte filename is wrong for v3, charmworld only looks for bundles.yaml
<mbruzek> If I am mistaken please educate me, but I thought v4 bundle format == no name
<rick_h_> (with an s)
<rick_h_> mbruzek: and yes you're right
<rick_h_> so the bundle is all kinds of confused
<mbruzek> ack
<rick_h_> mbruzek: honestly I didn't open it, I just looked at the file listing and saw bundle.yaml and replied
<mbruzek> rick_h_: OK.  I was just confused.
<rick_h_> mbruzek: but yes, atm we've got contention with not killing off charmworld/v3 api yet and it's causing this issue in migrating
<rick_h_> mbruzek: for good reasons, it's not simple and I apologize. Once we kill of v3 it'll be normal
<mbruzek> So your answer is still have both v3 and v4 bundle for now until we can fix the system?
<rick_h_> mbruzek: you just need enough v3 to make charmworld happy
<rick_h_> mbruzek: the charmstore will default to using the v4 if it sees it
<rick_h_> mbruzek: and ignore the v3
<mbruzek> Ok
<rick_h_> mbruzek: it could just be a v3 file with one service and nothing else tbh
<mbruzek> In another bundle we have a v3 bundle named bundles_v3.yaml and we have a bundle.yaml 
<rick_h_> mbruzek: did that ingest properly?
<mbruzek> Is that sufficient or do we need to name the v3 bundle, bundles.yaml.
<rick_h_> charmworld only looks for 'bundles.yaml'
<rick_h_> so I would not expect anything else to work
<mbruzek> https://jujucharms.com/u/kubernetes/kubernetes-cluster
<mbruzek> it appears to work but if you recommend naming it bundles.yaml that is what we will do
<mbruzek> and by work, I mean I can see it on the web site.
<rick_h_> mbruzek: did that go through ingestion or get uploaded?
<mbruzek> hatch: no we never resolved that GUI bug, and the customer did not open a bug for it.
<rick_h_> mbruzek: that's the other route
<rick_h_> skip ingestion, use the store upload command
<mbruzek> rick_h_: This is a personal namespace bundle, we haven't promulagated it 
<mbruzek> rick_h_: I don't understand the difference
<rick_h_> mbruzek: after the format it fixed
<rick_h_> juju store upload talks directly to the charmstore and doesn't involve synciung with charmworld or pulling in updates from bzr
<lazypower> rick_h_, i recall this, we were going ot do store upload for some of the bundles in k8's repo
<lazypower> but we haven't got there yet
<rick_h_> lazypower: ah ok
<lazypower> I'll propose a fix for the plumgrid bundle before i EOD today, and get that fixed up
<lazypower> moving forward, would you prefer to get the exercising in on the upload bits?
<rick_h_> lazypower: you poke at the spec for the future upload work?
<rick_h_> lazypower: hopefully will provide good things for your folks
<rick_h_> lazypower: makes no difference to me to be honest
<lazypower> i took a real brief glance over it, i need to dedicate some brain cells to it. I've been sick since i got back from DC :|
<rick_h_> lazypower: understand
<rick_h_> thanks for taking some time
<lazypower> i'll give it more brain power today and land comments
<lazypower> we've been grasping at straws trying to get the CWR working for k8's bundles presently
<rick_h_> cwr?
<lazypower> our github => launchpad promotion process has left us with some inconsistencies
<lazypower> Yeah, Cloud Weather Report
<rick_h_> ah ok
<lazypower> so, in short, store upload decoupling cant come fast enough if this is our chosen path forward :)
<lazypower> stick our upload logic in CI and call it a day for things being out of sync.
<rick_h_> lazypower: yes, that's why I'm pushing for feedback. Some of the team have already started on small bits and we want to plow forward and get it out to folks to use when we kill v3/charmworld at the end of hte year
<lazypower> i'm +1 for that
<lazypower> now if i remember orrectly
<lazypower> once i store upload, that branch is pretty much forever tied to that new workload
<lazypower> s/workload/workflow
<rick_h_> huh?
<rick_h_> oh hmm...pretty much
<lazypower> once the store finds it in its own data store, it no longer looks @ charmworld for data, right?
<lazypower> i think mbruzek and I will be +1 for adopting that workflow and killing off the porting between VCS tools.
<lazypower> it skips review process though
<rick_h_> lazypower: right
<rick_h_> lazypower: on both accounts
<lazypower> mbruzek, any thoughts/comments on this? ^
<lazypower> shall we be guinea pigs on this and reduce our cost of ownership to port between GH and LP?
<rick_h_> lazypower: that's the issue is getting the review queue work pulled in. Talked to marcoceppi and tvansteenburgh on that a bit yesterday. 
<lazypower> yeah, it was a topic at our standup too
<rick_h_> so increase in manual watching over review/udpates
<lazypower> i think we can gate through CI to do this though
<lazypower> and have the CI process be our source of truth until the new revq lands
<lazypower> its ~ a day of engineering to land that work when coupled with tvansteenburgh's jenkins scripts
<rick_h_> lazypower: ok, let me know what we can do to help
<lazypower> i think i've identified a blocker though: we have no way to push our branches from namespace to ~recommended
<lazypower> and what this has in terms of implications on CWR/CI
<rick_h_> lazypower: ah, we have a promulgation command/api call
<rick_h_> lazypower: might have to check how to get you able to use it
<lazypower> ok
<lazypower> and CI/CWR? i guess we need to do a litmus charm/bundle and see whats missing?
<rick_h_> lazypower: shoot an email to urulama rogpeppe and myself
<lazypower> will do
<rick_h_> we'll try to unblock you
#juju-gui 2015-09-25
<mbruzek> rick_h_: who do I ask charmworld questions to?
<rick_h_> mbruzek: me or bac really I guess
<rick_h_> mbruzek: we're both holding the gun to shoot it in the head
<mbruzek> rick_h_: Understand
<rick_h_> what's she done this time? :)
<mbruzek> rick_h_: We pushed some code to a personal namespace last night (~kubernetes) and I don't see the revision bump in the charm store.  I figure that is a charmworld ingestion problem? But educate me if I am wrong.
<rick_h_> mbruzek: looking
<rick_h_> mbruzek: what code? 
<mbruzek> I know they don't match bzr 1 for 1, but I would have expected to see a revision bump with Charles Butler's commit message there. https://jujucharms.com/u/kubernetes/kubernetes/trusty
<mbruzek> Also https://jujucharms.com/u/kubernetes/kubernetes-master/trusty 
<rick_h_> mbruzek: yes, there's a bug in pulling the bzr rev info from charmworld. 
<rick_h_> mbruzek: checking the code vs the code in the charmstore
<mbruzek> rick_h_: how are you doing that?  Teach me to fish and I will leave you alone
<rick_h_> mbruzek: so what I'm doing is going to the file list on the right side of the page
<rick_h_> and clicking the "View Code"
<mbruzek> ahh
<rick_h_> mbruzek: and then looking at the last commit
<rick_h_> mbruzek: and then based on the files changed, see if that file looks right in the actual file in the charmstore (from that list of files)
<rick_h_> mbruzek: basically "ignoring what the page says is the last commit, is the content actually correct"
<lazypower> thats what i did :D
<rick_h_> mbruzek: so looking at that, the change you made tothe test_install on the -master is there
<lazypower> mbruzek, i can verify the k8's master was not pushed yesterday as we thought, it landed in a personal branch of mine... i pushed the k8's master charm code about 30 minutes ago
<mbruzek> rick_h_:  that is fine by me but we are building bundles for the Cloud Weather Report (a high priority for our team right now). And our bundles have to have Specific revision numbers to pull the right code
<lazypower> but the k8's charm has revved to -7, as it should be. we're just pending k8's master to rev
<rick_h_> mbruzek: lazypower the other thing I was doing is chceking the changes api to see if an update was pulled https://api.jujucharms.com/charmstore/v4/changes/published?limit=1000
<mbruzek> rick_h_: Those revision numbers in the charm store are the same as _before_ we pushed those changes, and we want the bundle to pull the right code
<lazypower> nice
<lazypower> k8s-master just revved to -9 as it should
<lazypower> mbruzek, the charms are where they need to be now. check the bundle vs whats available
<lazypower> the revnos match
<rick_h_> mbruzek: lazypower huh? So the charmstore rev number did not increment?
<lazypower> nah they did increment
<rick_h_> oh ok
<mbruzek> rick_h_: kuberentes-master is still on 8, I see 9 in that api link that Rick just posted
<lazypower> Kubernetes went from 6 => 7 yesterday.
<rick_h_> scared me as we've not chnaged anything in a bit and that would be scary. 
<lazypower> Kubernetes-master will be moving from 8=>9 as soon as the store updates its display
<lazypower> but the deliverable should be shipping revno 9 already
<rick_h_> mbruzek: it's 9 now https://jujucharms.com/u/kubernetes/kubernetes-master/
<lazypower> s/deliverable/api/
<lazypower> or rick_h_ can call schenanigans and prove us both wrong :D
<rick_h_> juju deploy cs:~kubernetes/trusty/kubernetes-master-9 is the deploy command right now as I loaded the -master page
<mbruzek> rick_h_: it seems to have *just* happened.  
<mbruzek> rick_h_: when I started this converstation it was 8, maybe since the boss looked at it charmworld started acting right
<rick_h_> mbruzek: stale http cache? 
<rick_h_> mbruzek: I'm more tempted to think it's a caching issue tbh
<rick_h_> we've got a http cache in there and wonder if it got 'stuck' until a few reloads updated things
<mbruzek> rick_h_: possibly, I did refresh before I talked with you but I didn't force refresh
<rick_h_> the charmworld/charmstore data and the api was good when hit it seemed (like that changes api call)
<rick_h_> mbruzek: let me know if you hit that again. Maybe we've gone too agreesive. Since the data is essentially 'static' (the page for -8 will never change until it goes to -9) maybe we need ot fix the rules morefor pages without a revision number
<mbruzek> rick_h_: everything looks correct now.
<mbruzek> thanks!
#juju-gui 2016-09-26
<mhilton> anyone else having problems with canonical irc?
<frankban> uiteam are you able to connect to canonical irc?
<rogpeppe> frankban, mhilton: no, it's down
<mhilton> frankban: I can't
<fabrice> down
<frankban> ok
<rogpeppe> frankban, mhilton: see discussion on #juju-dev
<rogpeppe> uiteam: sorry, i don't think I made it clear - I'll need this to be approved and landed before the testing changes: https://github.com/juju/utils/pull/242
<hatch_> kadams54: you could take another look at that revision branch you were working on and switch it from using the setup.py to not
<rick_h_> and this channel comes alive :P
<kadams54> hatch_: Yeah, that's what I'm doing at the moment. Just didn't know if there was anything that should take precedent.
<kadams54> rick_h_: I know! I saw the notification for hatch's message and then couldn't find it ;-)
<hatch_> kadams54: here is how you can get the version in the Makefile
<hatch_> $(eval GUI_VERSION=$(shell sed -n -e '/current_version =/ s/.*\= *//p' .bumpversion.cfg))
<hatch_> kadams54: I'd also like it to grab the current git sha and include it in the file
<hatch> probably in a json format
<hatch> or js
<Guest72453> { "version": "2.1.13", "sha": "asdfasdfasdf" }
<Guest72453> bah
<kadams54> hatch: Yeah, so... when we talked last, we wanted to use the same version that goes on the tarball. That version is pulled from setup.py (`python setup.py sdist --formats=bztar` in the fast-dist target), which is why I took the approach I did. .bumpversion.cfg updates setup.py when you run `make bumpversion`, so I'd like to keep both the dist and version
<kadams54> targets using the same approach.
<hatch> there we go
<hatch> kadams54: sorry did you see my messages there? I was having issues :)
<kadams54> ha ha, no, I did not.
<hatch> last one was about the version in json?
<hatch> or in js
<kadams54> sha in json
<kadams54> hatch: The message you sent as Guest72453
<kadams54> ;-)
<frankban> uiteam call in 10
<bac> kadams54, antdillon: standup
<frankban> hatch: I am now available for any GUI tasks that you need for 2.2. I am near my EOD but please fire me an email before your EOD with anything I can help doing tomorrow
<hatch> frankban: sure thing - honestly the big thing right now I think is that subordinate issue
<hatch> frankban: the DF was working quite well
<hatch> so I haven't had enough time to really try and break it
<hatch> :D
<hatch> kadams54: 
<hatch> kadams54: did you need any help?
<hatch> on your charm?
<hatch> frankban: so if you remember that subordinat issue lazypower had actually brought it up again
<hatch> and then ther ewas also the juju-info issue with subordinates
<hatch> not being able to create them
<hatch> frankban: does this sound like something you'd be interested in?
<kadams54> hatch: on my charm? You mean on the version stuff?
<hatch> yeah the version stuff
<hatch> did that sed stuff work for you?
<hatch> kadams54: I was working on it for when I was generating a custom tarball not using setup.py
<kadams54> hatch: probably if I'd put it in place yet :-) working on the route issue first.
<frankban> hatch: sure, is this https://github.com/juju/juju-gui/issues/1483 ?
<hatch> frankban: yeah that's the juju-info one thanks
<kadams54> hatch: still not sold on that approach. If we change that I feel like we ought to change the fast-dist target
<frankban> hatch: ok I'll take a look at that one tomorrow
<hatch> kadams54: yeah totally it's all going to change - but it's going to be a slack task
<hatch> thanks frankban 
<hatch> I'm sure lazypower would be very happy :D
<hatch> frankban: plus there are some bundles that can't be made in the GUI, and this will fix that
<hatch> bac: let me know when you have a moment and I can fill you in on the charm release stuff
<hatch> for whatever reason it wasn't working for me (even after jrwren got me settled on the proper charm version)
<hatch> jrwren: you had mentioned something about azure and python from js? But I couldn't find a js version of those tools
<hatch> or maybe that was jcsackett ?
<hatch> frankban: maybe while you're in there you could take a look at https://github.com/juju/juju-gui/issues/1975
<hatch> assuming it is indeed in that area
<frankban> hatch: sure
<hatch> frankban: we're down under 90 open issues now :)
<hatch> yay
<hatch> Makyo: have you experienced this in a while https://github.com/juju/juju-gui/issues/1767
<hatch> since you're now back on the gui stuff?
<Makyo> hatch: uh, hmm.  I think so, but I'll keep an eye on it.
<hatch> Makyo: sure thing, it might have been another one of those vagrant only issues
<hatch> since i haven't actually ever experienced it :)
<kadams54> Taking a quick lunch break.
<hatch> mm
<hatch> oh I can qa these using local charms :)
<hatch> great
<hatch> frankban: https://jujucharms.com/docs/stable/authors-subordinate-services#declaring-subordinate-charms here is some information about the 'container vs scope' it sort of helps haha
<frankban> :-) sort of
<jrwren> hatch: https://www.npmjs.com/package/azure has lots of cli tools and used to be the official cli tools for azure.
<hatch> jrwren: oh I always thought this was a library for use with node tools
<hatch> not a cli tool
<jrwren> hatch: https://azure.microsoft.com/en-us/documentation/articles/xplat-cli-install/
<hatch> interesting
<jrwren> hatch: nice how juju hides all that cmdline stuff for you, eh?
<hatch> haha oh yes, yes Juju is pretty awesome there
<hatch> jrwren: so they aren't going to support this any longer and switch exclusively to the Python implementation?
<jrwren> hatch: i don't know. I expect they will tell us, eventually. Maybe they will support both?
<jrwren> hatch: the github calls the python one "2.0 - preview" so maybe they are abandoning the node cli tools and moving it all to the new python ones for 2.0. That was my assumption.
<hatch> that's a good guess
<hatch> I could see the advantage
<hatch> everyone has python ;)
<jrwren> hatch: that isn't true. no one on windows has python OOTB. so its just as much a support nightmare for their 99% use case.
<hatch> ohh, that's a good point!
#juju-gui 2016-09-28
<arosales> hello folks
<arosales> if I want to use the gui with RC1 do I need to do a charm upgrade?
<rick_h_> arosales: a juju upgrade-gui yes. 
<rick_h_> hatch: ^ the latest release is all rc1 friendly right?
<hatch> arosales: with Juju 2 you do not need to use the GUI charm
<rick_h_> arosales: https://github.com/juju/juju-gui/releases/download/2.1.13/jujugui-2.1.13.tar.bz2
<hatch> you can simply download the latest dist and upgrade it from there
<hatch> ^
<rick_h_> arosales: download and juju upgrde-gui that file
<arosales> rick_h_: thanks. I wasn't able to switch models
<hatch> arosales: with the 2.1.13 release it should work properly for you - if not, we've got a new one coming tomorrow ;)
<arosales> gotcha, and good to hear
<hatch> arosales: after running `juju upgrade-gui /path/to/tar.bz2` then you can run `juju gui --show-credentials` 
<hatch> it'll open up a browser window and show you your u/p in the console
<arosales> going to be showing your guys goodness here in NY ina bit
<hatch> uh oh
<hatch> :)
<hatch> do us proud :D
 * arosales will try
<hatch> arosales: also if you have any issues with that, I can cut you a dist from the release branch for tomorrow which definitely works heh
<arosales> ah much better
<arosales> I can switch models now
<hatch> great :)
<arosales> good stuff 
<hatch> arosales: I'll be around for a while yet so if you run into any more issues just ping 
<arosales> hatch: rick_h_ thanks
<hatch> anytime
