#juju-gui 2012-10-23
<benji> Hello from KÃ¸benhavn.
#juju-gui 2012-10-25
<Makyo> frankban, xgamma -rgamma 0.85 -bgamma 0.95
<Makyo> Can put that in an xinitrc or whatever
<frankban> Makyo: cool, thanks
<hazmat> frankban, woot! re tls
<frankban> hazmat: :-)
<teknico> hazmat, woot indeed! :-)
<jovan2> bcsaller hi, do you have that link to the CSS iPhone?
#juju-gui 2012-10-26
<teknico> hazmat, you available/reachable?
#juju-gui 2012-10-28
<Makyo> gary_poster, ping
<gary_poster> Hey Makyo.  I just realized that I was changing the card you had just changed--sorrt about that
<Makyo> gary_poster, That's okay!
<Makyo> Just trying to distill it down to a sentence: be more efficient and keep forward momentum in exchanges.
<gary_poster> Makyo, cool.  From my perspective, positive/encouraging attitude/atmosphere is an element as well, but that's more fuzzy
<Makyo> gary_poster, yeah, I couldn't figure out how to fit that in and still sound pithy
<gary_poster> :-)
<Makyo> gary_poster, I think I'm fighting the lp2kanban bot on one of my cards because I missed 'in progress' and hit 'fix committed'.  Even though I changed it back, the bot seems to think it belongs in UX Review.  I'm trying again today, hopefully it'll stay
<hazmat> gary_poster, how you feeling today?
<Makyo> Nope
<gary_poster> Makyo, :-/ bring it up with bac
<gary_poster> hazmat, fever broke sometime last night, but I think I feel it coming back
<gary_poster> :-(
<Makyo> gary_poster, Alright.  Well, for now, that card still needs a review.  Should be quick.
<gary_poster> Makyo, ok can look
<gary_poster> Makyo, link so I can be lazy :-D
<hazmat> gary_poster, i've got multi-vitamins and advil if its of use
<Makyo> gary_poster, https://codereview.appspot.com/6776052
<gary_poster> thanks hazmat.  I've got advil if I need it
<gary_poster> ack Makyo on it
<Makyo> I have emergen-C, too, should it be needed.
<gary_poster> I dunno if that helps fever.  This seems like what my older son had about two or three weeks ago.  It lasted a long time and we finally took him to the dr simply because he wsn't getting better and dr said that there was a weird virus going around.  Doesn't produce scary temperatures, but takes a while to leave.
<Makyo> Ahh, boo
<gary_poster> the school policy is 24 hours without a fever of 100.6 or something before you come back
<gary_poster> I'll probably try to follow that
<gary_poster> don't want to get other people sick
<gary_poster> benji is getting me a thermometer this afternoon on his adventures
<gary_poster> ok reviewing...
<gary_poster> Makyo, I had to read up on appcache.  What you did looks good.  Did you consider using touch rather than putting the timestamp explicitly in the file?  I think that would be simpler but maybe it is insufficient or less attractive for some reason
<gary_poster> I'll approve with that as a question.  Either way is ok by me.
<Makyo> gary_poster, I suppose it also gives us an indicator in the file we can see from the browser if need be, but now that I think about it, that's kind of a weird case :)
<gary_poster> :-) Up to you Makyo.  I've sent the appspot review and approving in the MP...
<Makyo> gary_poster, Thank you :)
<Makyo> Moving over to more comfortable area, back in af ew.
<gary_poster> np, thank you for the change.
<gary_poster> cool
<gary_poster> Makyo, just realized downside of this approach: every branch/commit will have the appcache included
<gary_poster> because file always changes on install
<gary_poster> Don't know if touch would solve this, but it might.  Maybe it is broken in other ways though
<Makyo> gary_poster, This is true.  Research suggests that some servers will not send the manifest unless the file contents are modified, so it's a trade-off.  Its up to you all if it's one that we're willing to make, but I feel that, given that we already ignore the [revision details] entry in the code review, also ignoring the manifest should be alright.
<gary_poster> Makyo, I see :-/
<gary_poster> I figured it was something like that :-)
<gary_poster> Makyo, does the appcache change mean I need to clear the cache explicitly now in dev?  I did in order to see a change to index.html
<Makyo> No, only if changes are made to cached files (currently only svgs)
<gary_poster> ok cool
<Makyo> Everything else is explicitly not cached.
<gary_poster> I wonder why I had to clear the cache to get index.html up.  Maybe it is not handled the same as our js in the server
<gary_poster> ...doesn't look like it
<gary_poster> that is, I don't see special casing
 * Makyo tests
<gary_poster> hm, restarting server and then reloading works
<Makyo> Make server will update the appcache.
 * Makyo finds: Regardless of whether you include the address of the current page in the manifest, it will be cached.
<Makyo> So index.html is automatically cached.
<Makyo> But all resources such as scripts are not.
<gary_poster> ah right
<gary_poster> I saw that too
<gary_poster> but did not make the connection
<gary_poster> Makyo, might be worth an email to group or something about the two issues: why the appcache will be part of all of our commits (unlike the revision details, this will be an annoying source of conflicts unless we can figure out a way to tell bzr to just be quiet and use the newest version...), and how to make index.html reload
<Makyo> I know we can do  bzr resolve --take-other app/assets/manifest.appcache though that is an extra step.  I'll read up on it.
<Makyo> Or shelve before commit.
<Makyo> Or the appcache target could do the shelve.
<Makyo> gary_poster, ^^^
<gary_poster> Makyo, interesting.  The last option wouldn't help though, would it?  Seems like that would update the file and then immediately hide the change, which isn't what you want.  shelving before a commit would work but for this bzr revert would seem more appropriate...  Makyo, here's another idea.  Instead of modifying in place, we have a manifest.appcache.in.  the makefile adds the timestamp to that file and puts copies it to the expected place.  We bzr ig
<gary_poster> nore that generated file
<gary_poster> what do you think of that one?
<gary_poster> (so, IOW, manifest.appcache.in never has a timestamp and is only modified by devs; and manifest.appcache is only generated, and ignored by bzr)
<gary_poster> (and has a timestamp)
<Makyo> gary_poster, I see.   Then if we make a change, just copy the .appcache.in to the .appcache, and make will add the timestamp
<Makyo> ?
<gary_poster> Makyo, or just rerun make appcache: if the Makefile says that .appcache depends on .appcache.in, then it will know to regenerate the .appcache when .appcache.in changes
 * Makyo nod, tests.
<gary_poster> Makyo, actually now that I am in Makefile frame of mind, I suggest that you make a change like this one also, just to be more proper and to help with this kind of thing...one second, making changes for a pastebin
<gary_poster> Makyo, https://pastebin.canonical.com/77359/ .  I have no idea if the actual cp/sed approach I sketched there works.  My main point is that appcache should be a phony target, pointing to the real file as a target, which points to the .in file.  With the changes I gave in that pastebin, the assumption is that the .in file would live in the same directory as the Makefile.  Don't have to do that, but it was the easiest thing to do for a sketch
<gary_poster> notice I put appcache in .PHONY
<gary_poster> That is 100% untested :-)
<Makyo> gary_poster, That's basically what I was working on, just using $(APPCACHE).in 
<gary_poster> oh, yeah, that's nicer
<gary_poster> well, as long as it is ok to serve the .in :-)
<gary_poster> I'm sure it is, just slightly messy
<gary_poster> I'd lean towards not serving the .in myself
<Makyo> That's fine, then
<Makyo> Seems to work pretty well.
<gary_poster> cool
<Makyo> So then bzr add manifest.appcache.in; bzr rm app/assets/manifest.appcache; add 'app/assets/manifest.appcache' to .bzrignore ?
<gary_poster> yes, and you can spell the last step as bzr ignore app/assets/manifest.appcach if you want to
<gary_poster> but they are equivalent
<Makyo> Ah, cool.
<Makyo> gary_poster, Thanks for the help!
<gary_poster> Makyo, cool, thank you.  Another topic: I made a change that is just slightly too big for a self-review, in my own estimation, but maybe if you approve it I can squeeze it in. :-)  Pastebin is here: https://pastebin.canonical.com/77360/ .  Main question for you is how offended you are by the "required"/"valid" hack I used to get what I wanted without JS
<Makyo> I don't know how I made it so long before having to do anything with make
<gary_poster> heh
<gary_poster> Maybe I'll still put it in for review, but I'd still like to know what you think
<gary_poster> My make-fu is a lot higher since I joined Canonical.  It's a finicky program, but within a certain class of usage I think I can treat it as "simple" :-)
<Makyo> gary_poster, I think it looks good, personally.  I think all of the browsers we're aiming to support will take :valid
<gary_poster> ok cool Makyo thx
<Makyo> gary_poster, reproposing to get another look.  Added an appcache-force so that if someone updates the index.html file but not the manifest, they can just run that and it will do the update
<Makyo> Gonna grab a walk around the open space before it gets dark.  Will resubmit/email after a +1
 * Makyo returns, colder.
<gary_poster> Makyo, sorry was away from computer.  Just approved with two trivial suggestions.
<gary_poster> Where "away" == about three feet away, granted
<gary_poster> But I have the computer muted :-)
<Makyo> gary_poster, Thanks :)  Will do those and submit before we get a bunch of manifest.appcache things.
<gary_poster> good idea
#juju-gui 2013-10-21
<rick_h_> hatch: party
<jcsackett> rick_h_: looks like charm tokens are needed on landscape too. :-p
<rick_h_> jcsackett: bwuhahahahaha
<rick_h_> jcsackett: but surely they'll just re-invent it :P
<rick_h_> bac: can you flush comingsoon as we have to do once in a while with css/etc issues?
<rick_h_> bac: I htink that's why onboarding isn't working
<bac> y
<rick_h_> bac: since trunk with a fresh make clean-all && make works here locally
<rick_h_> ty much kind sir bac 
<bac> rick_h_: i don't see anything wrong.  you want i should 'make clean devel' anyway?
<bac> what's the url with feature flag?
<rick_h_> :flags:/onboard/
<rick_h_> bac: ok, yea maybe there's something else there. Thanks for trying. 
<rick_h_> just annoyed it's working locally but not in comingsoon :/
<rick_h_> bac: hmm, there's one other flag I can see strictBundle:
<rick_h_> not sure what that 'does'
<bac> rick_h_: that error may have been spurious during the rebuild.  i'm not seeing it now.  onboard doesn't work but nginx isn't spewing that error
<rick_h_> well, charmworldv3 is a flag right? and that works
<rick_h_> bac: can we set debug mode in comingsoon to get at uncompressed files?
<rick_h_> bac: /me wants to debugger/walk through it 
<bac> rick_h_: how's that done, the debug mode?
<rick_h_> juju-gui-debug is hte charm config to do it
<rick_h_> bac: I'm looking in the config.js for it but not seeing it right now 
<bac> make build-debug
<rick_h_> bac: where is comingsoon run on? If you just make devel will it run on a port we can hit to test/debug?
<bac> http://comingsoon.jujucharms.com:8888/:flags:/onboard/
<rick_h_> ok, very cool that it's there, but what happened?
<rick_h_> hmm, wondered if there was a modules-debug.js issue
<rick_h_> but I don't think so
<rick_h_> it looks right
<rick_h_> running make prod locally to see if it works/not
<rick_h_> huwshimi: https://codereview.appspot.com/14700043/
<huwshimi> rick_h_: https://lists.canonical.com/mailman/listinfo/frontend-web-devel
<rick_h_> antdillon: lp:~rharding/juju-gui/fix-onboarding
<rick_h_> hatch: jsbin for the promise error catcher?
<Makyo> rick_h_: http://jsbin.com/udiMIXo/2/edit ?
<rick_h_> hatch: https://juju.ubuntu.com/docs/authors-charm-store.html
#juju-gui 2013-10-22
<rick_h_> bac #1237025
<_mup_> Bug #1237025: Using the ViewTestBase.enable_routes in API tests causes the  test_homeview to fail <charmworld:Triaged> <https://launchpad.net/bugs/1237025>
<hatch> jcsackett, YO!
<bac> benji: https://docs.google.com/a/canonical.com/document/d/1paE70HEVgKA6LIjngzMa83OYr5jkZrOJ0hVNrYUuva0/edit#
<garyposter> Makyo, http://paste.ubuntu.com/6284711/
<jcsackett> hatch: PUSH YOUR REPO.
<jcsackett> hatch: :-P
<hatch> jcsackett, oh crap sorry I forgot haha
<hatch> SAY MY NAM!
<Makyo> hatch: 
<hatch> lol
 * jcsackett laughs
<Makyo> hatch: you're fired.
<hatch> jcsackett, I'll push it pretty soon
<jcsackett> hatch: uh huh.
<jcsackett> i'll believe it when i clone it.
<antdillon> rick_h_, Hey, could you cr this please? https://code.launchpad.net/~ya-bo-ng/juju-gui/onboarding-continued/+merge/192247
<rick_h_> jujugui review please https://codereview.appspot.com/15210050 on charmworld refactor
<bac> rick_h_: chunk mismatch.  :(
<rick_h_> bac: damn, that was my second attempt at this
<rick_h_> and it was there, I left review comments and then submitted again :/
<rick_h_> bac: trying to push again I guess. 
<Makyo> hatch: 224347
<jcsackett> hatch: you still working on ghost? i'm thinking of taking a stab at mysql, but don't want to duplicate effort.
<Makyo> jcsackett: hatch is taking notes now, don't think so
<jcsackett> Makyo: thanks. :-)
<Makyo> arosales: ping; Jamie is going to try and make it here for a sync at 6. Sent email, but email is hard to keep up on for me now.
#juju-gui 2013-10-23
<antdillon> hatch, https://code.launchpad.net/~ya-bo-ng/juju-gui/onboarding-continued/+merge/192247
<hatch> jcsackett, ping
<jcsackett> hatch: pong.
<hatch> https://github.com/rosskukulinski/ghost-ansible/blob/master/templates/ghost.upstart.tmpl
<hatch> was this the upstart script?
<jcsackett> hatch: no.
<jcsackett> one sec.
<jcsackett> hatch: it's on this page http://docs.ghost.org/installation/deploy/
<hatch> thanks
<jcsackett> it's under the "Init Script" heading.
<hatch> internet.....is......so.......slow........
<hatch> wow that's.....deep man
<hatch> lol I guess I'll see if I can copy it mostly wholesale
<antdillon> hatch, Can you very nicely lbox this for me: lp:~ya-bo-ng/juju-gui/onboarding-continued
<antdillon> hatch, Ok branch is ready. Could you lbox for me please?
<jcsackett> hatch: how do you feel about the ghost charm just not supporting sqlite deployments? b/c the added complexity at this stage doesn't see worth it.
<huwshimi> hatch: Choo choo!
 * jcsackett laughs
#juju-gui 2013-10-24
<hatch> http://browser.primatelabs.com/mac-benchmarks
<hatch> http://browser.primatelabs.com/mac-benchmarks
<Makyo> hatch: (and other vim users) http://blog.superuser.com/2012/03/06/understanding-the-improved-in-vim/
<rick_h_> hatch: https://github.com/mitechie/pyvim
<antdillon> hatch, https://code.launchpad.net/~ya-bo-ng/juju-gui/onboarding-continued/+merge/192247
<bac> benji: https://codereview.appspot.com/16690043
<huwshimi> http://staging.jujucharms.com/api/2/charm/precise/hadoop-HEAD
#juju-gui 2013-10-25
<huwshimi> jujugui: Review please! https://codereview.appspot.com/16940043
<Makyo> On it
<benji> bac: https://codereview.appspot.com/16950043 !!!!!!!!
<bac> benji: finally
<bac> benji: i approved it a while ago but forgot to ping you
<benji> bac: ok, looking now
<rick_h_> hatch: ping
<hatch> yo
<Makyo> rick_h_: The Face of JS at Canonical
<rick_h_> Makyo: sssh
<Makyo> Hahah, sorry :)
<rick_h_> Makyo: look, it's a playground, leave me alone :P
<Makyo> Hahaa
<hatch> rofl
<rick_h_> hatch: said the same exact thing 60s ago
<rick_h_> it's my first time doing an org, don't konw wtf I'm doing :P
<hatch> haha
<hatch> maybe you shouldn't be championing this :P
<rick_h_> it's doooomed!
<Makyo> Pff, it's fine.
<hatch> haha
<rick_h_> anyway, as you guys can see. Added you to some space to play with testing things. Gathering info, links, hints/tips
<rick_h_> please feel free to submit additional information
<hatch> yeah -  we gota figure out how to keep the commit history clean
<rick_h_> and start to pull together the full checklist/etc and we should probably talk about this in #cloud-dev
<hatch> I'm not really sure the best approach for that
<rick_h_> so that's the end of the conversation for in here :)
<hatch> sounds like a plan
<hatch> rick_h_, so I'm trying to rebase jc's PR but it looks like he merged in master a few times 
<hatch> any idea how to do this?
<rick_h_> right, that's what I mean. It gets messy. So you should create a new branch from master, cherry pick his commits
<rick_h_> you can do is rebase the ones in a row down to one so you can narrow the number of cherry picks required
<rick_h_> hatch: I *think* you can rebase the merges or something, but have to try it out 
<hatch> yeah I'm not having any luck, I'll keep at er
<rick_h_> let me know if you want me to pull down and try it out
<hatch> rick_h_, ok if you'd like :) I'm at a loss https://github.com/jaycee/ghost-charm it's the add-mysql branch
<rick_h_> hatch: so you want to just rebase it?
<hatch> yeah so his PR is 16 commits
<hatch> I'd like it down to logical commits
<hatch> or just 1 
<hatch> but whenever I try it's like it thinks it's already been rebased
<hatch> I'm sure I'm just missing something - it's been quite a while since I've had to do this
<rick_h_> yea, working on it sec
<rick_h_> hatch: what do you want the message squashed down to?
<hatch> adding db-relation-changed and departed hooks for mysql
<hatch> that pretty much sums it up
<hatch> id' be very interested to know the commands you used to do that too
<rick_h_> yea, sec
<rick_h_> bah, what a mess
<hatch> right? haha
<rick_h_> well I rebased a bit too far :)
<rick_h_> oh, actually it might be good
<hatch> :) So these are the types of things we will have to figure out how to avoid 
<rick_h_> https://github.com/mitechie/ghost-charm/tree/add-mysql
<rick_h_> so I've got it cleaned up, I tried to then merge in trunk but have conflicts to handle
<rick_h_> hatch: http://paste.mitechie.com/show/1053/ is what I went through
<rick_h_> hatch: so each of my commits is resolving rebase conflict issue steps
<rick_h_> that might even be able to be shortened but seemed ok atm
<rick_h_> anyway, getting late. 
<hatch> cool thanks I'll give this a go
<hatch> gnt
<huwshimi> luca__: http://10.155.45.150:8888/
<hatch> jujugui looking for a review https://codereview.appspot.com/17340043/
<antdillon> hatch, lp:~ya-bo-ng/juju-gui/onboarding-continued
<abentley> bac: Could you please review https://code.launchpad.net/~abentley/charmworld/remove-018-migration/+merge/192749
<bac> abentley: done
<abentley> bac: Thanks!
<abentley> bac, revno 231 is now deployed.
<abentley> to staging.
#juju-gui 2013-10-26
<hazmat> gary_poster, could you come upstairs to the mark room
<hazmat> Broom 2
#juju-gui 2014-10-20
<frankban> hi luca: how do you want the "Your service has been added" to be dismissed? for the current ghost inspector? once for all future added services (onboarding style)? for a specific service?
<luca> frankban: are you talking about the black pop-up?
<frankban> luca: I am talking about https://bugs.launchpad.net/juju-gui/+bug/1379655
<mup> Bug #1379655: The "this service has been added" notification can't be dismissed permanently <juju-gui:Triaged> <https://launchpad.net/bugs/1379655>
<luca> frankban: oh! right!
<rick_h_> morning
<rick_h_> hatch: ! hey, you disappeared for a week :P
<hatch> *yawn*
<hatch> hey rick_h_ :) I did!
<hatch> as ordered :P
<rick_h_> hah
<rick_h_> welcome back to one week before launch. Get to work! :P
<hatch> tbh I spent 1/2 of it in bed with a cold :/
<hatch> lol
<rick_h_> hatch: :( 
<rick_h_> hatch: when you get caught up let me know and we can chat. We're in crazy pre-launch mode
<hatch> you bet, I'm going to 'start' in 15m, just catching up on the remaining emails 
<rick_h_> hatch: rgr
 * rick_h_ goes to make some coffee
<hatch> rick_h_: alll ready
<rick_h_> hatch: k, standup roomn
<hatch> rick_h_: https://github.com/hatched/juju-gui/tree/react-spike there is only a single commit so you can get the entire diff by going to https://github.com/hatched/juju-gui/commit/7db9fa3d3f976a1d052d9320dd82140c21262c6d
<rick_h_> hatch: ty
<hatch> just of course keep in mind that this is not the 'proper' way :) 
<rick_h_> oh course
<rick_h_> jujugui call in 10
<rick_h_> errr 6
<jcsackett> :p
<jcsackett> was just about to say the timestamp disagrees.
<hatch> 4 here
<hatch> :P
<jrwren> rick_h_: ntptrace plz.
<hatch> but my clock is off and I can't change it for some reason lol
<jcsackett> rick_h_: standup. :p
<hatch> mannnnn I'm 1500 points away from the next Altitude level with Air Canada :/ rick_h_ can we shoehorn a sprint in before the end of the year? :)
<kadams54> hatch: I'm taking a weekend trip out to Seattle for just that purpose :-)
<hatch> lol
<kadams54> Makyo: right now one of the added services bugs is that dragging the canvas unfades any faded services. Any pointers on where to look?
<hatch> kadams54: look in topology.js (I think)
<hatch> I'm pretty sure that's where it sets the translate
<hatch> and then calls the d3 methods
<hatch> going from memory here :)
<hatch> I'm pretty bummed that apple didn't release a 4k cinema display but instead a cobbled together 5k in an imac :/
<kadams54> hatch: It's a hard-knock life.
<Makyo> kadams54, grep for 'show' in app/views/topology
<hatch> I'm actually very surprised they did the 5k display
<hatch> they had to overdrive the thunderbolt to be able to do it
<hatch> seems like an odd choice 
<Makyo> kadams54, I'm hunting too
<kadams54> Makyo, hatch: yeah, I did look around for "show" but didn't find anything.
<Makyo> kadams54, Try breaking service.js:1508
<Makyo> I'm wondering if it's registering a click along with the drop handler, and clearing the state(which shows all services)
<Makyo> kadams54, that occurs in relation.js:722
<lazyPower> rick_h_: are you ready for some awesomely amusing news?
<rick_h_> lazyPower: maybe
<lazyPower> rick_h_: friend reaches out over email - "The juju gui just ate all my units, what happened? I just see one service and i cant move it on the canvas" -- i reply "Juju upgrade juju-gui" - response: "Awesome! that worked. ta"
<lazyPower> i have no idea which version they were running, but thats third party verification you guys fixed it
<hatch> lol
<hatch> we fixed a bug we may or may not have known existed
<hatch> awww yeah *puts on sunglasses*
<lazyPower> actually, come to think of it, i deployed that environment around the same time i upgraded my DO env to machine view....
<lazyPower> hah i may be the only one breaking the gui with whatever i was doing on manual envs.
<jrwren> hatch: TP-LINK TL-WDR4300 rocks
<lazyPower> hatch: new tagline - "juju gui team, fixing lazypowers broken deploys since 2014"
<hatch> lazyPower: haha
<hatch> jrwren:  I was thinking of getting the new monster linksys 
<rick_h_> lazyPower: yea, manual provider and such needs more love but getting better
<hatch> jrwren: but I like the price of this one better :)
<lazyPower> rick_h_: its definately getting better. This cycle with juju-alpha builds, and the new gui have been an exceptional experience.
<rick_h_> lazyPower: <3
<jrwren> hatch: remember, linksys:cisco::toyota:lexus :p
<jrwren> hatch: the tp-link also supposedly runs openwrt very nicely. I just haven't found the need to change from default firmware yet.
<hatch> jrwren: since I own two Toyota's that means I should buy the linksys right?
<hatch> mount it on the back as a spoiler
<hatch> jrwren: however unlike Toyota's I've had to replace every one of my old linksys routers after a year because of failures. :)
<jrwren> hatch: terrible analogy. I fail.
<hatch> lol
<hatch> It also fails in that the linksys router has a TON of features whereas Toyota's ususally fall short on the feature category :P
<hatch> So maybe in my experience if linksys routers they are the Chevy of the router world lol :P
<hatch> kadams54: there appears to be some added services bar tests that block the test runner - are there any running settimeouts?
<jrwren> yeah, always failing.
<hatch> I have finally found a use for  generators in javascript
<hatch> wow that took too many years
<hatch> :P
<hatch> note to self: when spamming 'enter' make sure you don'thave any pending updates which may ask to install
<hatch> nope, still don't like the white sidebar :P
<rick_h_> lol
<hatch> rick_h_:  crit bug before release https://bugs.launchpad.net/juju-gui/+bug/1383381
<mup> Bug #1383381: autoplaced units don't show up in machine list <juju-gui:New> <https://launchpad.net/bugs/1383381>
<kadams54> hatch: on the tests, no, no setTimeouts, just ones that are waiting for an event to fire before calling done().
<hatch> kadams54:  yeah ok thanks I saw that after (sorry I forgot to postback) it looks like some of the events were taking forever to propagate in the branch I was working in 
<kadams54> :-()
<kadams54> Smiley fail
<kadams54> :-(
<hatch> lol
<hatch> it's fixed now - not sure why the branch I was working on caused those events to hang
<hatch> not even related haha
<hatch> oh our test suite....
<frankban> rogpeppe: do we want GetArchive to return a complete id or to modify in place the given one?
<rogpeppe> frankban: let's return a new id
<frankban> rogpeppe: +1
<rick_h_> frankban: rogpeppe other chan
<stokachu> rick_h_: feature request to re-write juju-gui in go using https://github.com/robertkrimen/otto
<stokachu> :X
<stokachu> j/k btw
<rick_h_> ummm, wow
<stokachu> lol crazy right
<rick_h_> well, better option that dart :P
 * rick_h_ pokes hatch in the ribs
<hatch> ouch
<hatch> lol
<hatch> dart syntax is nicer than go :P
<stokachu> hah
<stokachu> any syntax > go
<stokachu> :X
<hatch> lol!!
<rick_h_> lies! perl < go < *
<rick_h_> :P
<stokachu> haha
<hatch> haha - perl CAN be written nicely
<hatch> go can't :P
<stokachu> i wrote juju bindings in perl :(
<stokachu> im so ashamed
<hatch> did it look like #$^&*(*&^%$%^&*&^%$%^&*
<hatch> :D
<stokachu> haha
<rick_h_> no, that's how you make an ajax request over cgi
<hatch> rofl
<rick_h_> not a juju websocket connection :P
<stokachu> my eyes only bled a little
<jrwren> just remember, go syntax is ugly like that because the C compiler is too slow, so we have to help the compiler be fast. Its just a slight improvement over nasm.
<hatch> haha
<hatch> test_fakebackend is over 3k lines :/
<hatch> and now to make it bigger! :P
<rick_h_> bwuahahahaha
<hatch> good news is that it now supports bundles with multiple relations per endpoint
<hatch> from a bundle yaml file
<hatch> :P
<hatch> and all the current tests pass
<hatch> so yay
<hatch> kadams54: hey does added services still need to be under a flag?
<hatch> it's close enough that it'll definitely be in the next release right?
 * hatch just keeps forgetting to use the flag ;)
<hatch> I bet it was quiet in here last week
<hatch> aren't you all happy I'm back??
<hatch> :P
<rick_h_> hatch: yes, still behind a flag until it's ready for release :)
<rick_h_> hopefully EOW
<hatch> ahh that's how we're doing it? cool
<rick_h_> hatch: well there's still a few cards of work
<hatch> ohh
<hatch> looked done to me lol
<rick_h_> we had UX updates last week and there's the 'remember me' stuff still
<hatch> ohh gotcha
<hatch> don't suppose those UX updates change the background colour? ;)
<rick_h_> :P
<hatch> in lucas blog post there were some awesome mockups
<hatch> after seeing them I wonder why we didn't use those hah
<hatch> I should probably keep quiet or we'll get a new UI this week
<hatch> lol
<rick_h_> the new images are in the email? Or card?
<rick_h_> https://drive.google.com/drive/u/1/#folders/0BwDPGKe0SiMbU0RfOXZIXzJlODg/0B7XG_QBXNwY1V3B3dDNvYXJGRE0/0B7XG_QBXNwY1NEtGaHJYZGM4enM/0B7XG_QBXNwY1N3Rld2RvdkFUMWs
<hatch> oo new google drive ui
<hatch> added services w/machine view is sure nice
<hatch> ppl will like that
<hatch> jujugui lf a review and qa https://gist.github.com/bcsaller/131454a8fabb9e0f8154
<hatch> oops
<hatch> https://github.com/juju/juju-gui/pull/623
<hatch> ^ that one
<rick_h_> hatch: will try to look tonight after the boy goes to bed
<hatch> sure np, it's not blocking anything else
<hatch> thanks
<hatch> jujugui anyone around? for a loop at a wip?
<hatch> Luca: hey
<Luca> hatch: heya
<Luca> hatch: how's it going?
<hatch> I read your blog post - looks good
<hatch> some of the prototypes looked awesome :)
<Luca> hatch: thanks
<hatch> definitely want some of that stuff! lol
<Luca> Haha
<hatch> yeah some of those look really good
<hatch> are some of those ideas going to come back?
<hatch> morning huwshimi
<huwshimi> Morning
<Luca> Which ideas are you talking about? :O
<Luca> Morning  huwshimi 
<hatch> Luca:  well they go by so fast....but they all have the black inspector open
<huwshimi> Luca: Morning
<rick_h_> Luca: I tweaked your bugs today, let me know if we need to chat on any of them (and that can be tomorrow)
<hatch> rick_h_: https://github.com/hatched/juju-gui/compare/juju:develop...hatched:deploy-target?expand=1 initial go at the state stuff - thoughts?
<Luca> hatch: oh! The gif. I'm not site if any of them will come back, I would love to see analytics though.
<hatch> aww darn - I just like the styling of some of the tokens - they look 'tighter' 
<Luca> rick_h_: OK, did you tweak them in GH or Kanban?
<rick_h_> Luca: GH and turned them into kanban
<rick_h_> Luca: per the email I sent out to you and the guys working on the items
<hatch> huwshimi:  isn't it very early there?
<Luca> rick_h_: cool, I'll check it out
<huwshimi> hatch: 9:12am
<hatch> oh did the tz's change?
<huwshimi> hatch: Yeah, we changed to dst
<hatch> ohh ok
<Luca> rick_h_: I just saw your email. Thanks, the more eyes the better :) if we add some new ones do I just leave them unsigned or assign them to you do you know that I've added them?
<rick_h_> Luca: definitely, I'll track the emails as they come in and triage them
<rick_h_> Luca: but I had to cut down a bit. We had 36 high priority bugs for 3 peopla and 5 days of work
<Luca> rick_h_: cool, I'll do that
<rick_h_> Luca: so I'm trying to help get it down to the ones required for the guys to do over the next 4 days to get to release
<Luca> rick_h_: yeah, I can't see many being added but the guys are some design bits which should be wrapped up tomorrow
<rick_h_> Luca: rgr
<rick_h_> the question will be are they release blockers or not and how they line up with current release blocking tasks
<Luca> Well, its the Get Started page and 404 page and some content updates
<Luca> We could launch without Get Started and add it for ODS
<rick_h_> Luca: ok, I think those are on the current list. 
<Luca> rick_h_: cool
<hatch> rick_h_:  is it safe to assume people would specify the 'bundle:' prefix when using deploy-target?
<hatch> so it would be a trivial flag to determine if it's a bundle or not
<rick_h_> hatch: no, the urls that will come in will have ~user/bundle I think for now, but I think that'll be going away
<hatch> I'm trying to figure out a way to determine simply from the id string whether it's a bundle or not
<hatch> unfortunately we have too many optional fields lol
<rick_h_> hatch: so figure out what we want it to be and we can update the front end to send it
<hatch> well if it can send the fully qualified id bundle:mediawiki/7/single and cs:precise/mysql-48 etc
<hatch> then we'd be golden
<hatch> easy to indexOf on the prefix
<hatch> can we do that?
<rick_h_> yes, just make sure we document it so we can make sure we do that on the other end
<rick_h_> hatch: at least for initial release
<hatch> sounds good
<Luca> Night all
<hatch> bundle deploys - aww yeah
<Makyo> Super interesting, if depressing: http://www.npr.org/blogs/money/2014/10/17/356944145/episode-576-when-women-stopped-coding
<hatch> Makyo: tldl ?
<Makyo> hatch, still listening :P
<hatch> oh lol
<hatch> that topic is in-vogue so I try to avoid it at all costs
<Makyo> Got hooked by the graph.  I always get hooked by graphs :/
<hatch> so many idiots 
<hatch> like why can't we all just be friends? :)
<rick_h_> because there are canadians in the world? :P
<rick_h_> bwu-ha-ha-ha!
<hatch> hahaha
<hatch> oh u suck
<hatch> Well I'm taking off - see you all in the am
#juju-gui 2014-10-21
<rick_h_> morning party people
<luca> frankban: Hey, Sorry for not replying yesterday, I was sidetracked when you asked me a question, did you need anything from me?
<frankban> luca: doing something different now, I was asking about how the sidebar message should be hidden: once per session, per model or once forevere
<luca> frankban: I think it should be once per model for the time being
<luca> frankban: though I can imagine it getting really annoying quite fast lol
<luca> frankban: though it would be good to test
<frankban> luca: ok, good to know, could you add this info to the bug?
<luca> frankban: sure
<frankban> thanks
<rick_h_> Makyo: or frankban can you do a second review of https://github.com/juju/juju-gui/pull/623 qa already done
<frankban> rick_h_: sure
<rick_h_> ty frankban 
<kadams54> On my way to the dentist. May not be back in time for standup.
<rick_h_> kadams54: rgr
<rick_h_> kadams54: let's sync up when you get back then
<hatch> jrwren: when we were ragging on Go syntax yesterday you said that it was because the gcc compiler is slow so we need to help it - do you have any references for that?
<jrwren> hatch: one of Rob Pike's early go presentations. I think from google io 2010
<hatch> ohh yeah I remember that one - unfortunately he doesn't give any examples
<jrwren> sure he did.
<hatch> did he? 
<hatch> hmm
<jrwren> he said they have C++ projects which take minutes or into the hours to compile and the same thing in go is seconds.
<hatch> right - but how does the ugly syntax have anything to do with that
<jrwren> hatch: maybe we think different thing are ugly?
<jrwren> hatch: the language was designed wiht parsing and compilation as a top concern, hence, ugly syntax to help the parser be fast.
<jrwren> I swear he went into some details, but admittedly parsing is pretty fast and easy. Its more the package reference system that speeds it up.
<hatch> yeah
<hatch> maybe my issue with the syntax is gofmt
<hatch> if I have to horizontally scroll github....the line is too long ;)
<jrwren> oh! I totally agree. we should still follow 79 column limit.
<jrwren> but that is a nit.
<jrwren> Do you follow that in js?
<rick_h_> jrwren: yes
<rick_h_> jrwren: I think the only exception is html and that we try hard to but sometimes the nesting goes too far where it's less readable
<jrwren> you can't exactly extract a function in html to fix that.
<rick_h_> right
<rick_h_> so we're a bit more lenient on that side, but there will still be review comments sometimes to indent/break up the html a bit
<hatch> rick_h_:  so when doing a charm with deploy-target it needs to be comitted and the machine auto placed?
<rick_h_> hatch: yes
<rick_h_> jujugui call in 8 kanban please
<rick_h_> Makyo: standup?
<hatch> jujugui have we ever programatically auto-committed anything from the browser.js portion of the app? The deployer bar doesn't appear to be passed into the browser.js nor can I find any events
<rick_h_> hatch: don't think so. The times we've had to communicate like that we've event chained up through app and down into browser like the inspector "page takeover" event stuff
<rick_h_> hatch: does it have to happen from browser.js? Can it not just be from state?
<hatch> browser.js is the only component which handles the state dispatches
<hatch> but the deployer bar is rendered in the app.js
<hatch> I can fire an event from browser.js and listen in app.js
<hatch> just didn't want to duplicate work
<rick_h_> hmmm, yea I think that'd be the best path
<rick_h_> off the top of my head
<hatch> state instantiation should probably be moved into the app layer
<hatch> buuuuuuut
<hatch> yeah
<hatch> no
<hatch> :P
<rick_h_> hah, one thing at a time. 
<hatch> Makyo: bring me back some good beers!
<hatch> oh wait....
<hatch> :P
<Makyo> I think we've got better beer in Colorado, personally, but I'm biased.
<hatch> only a little :)
<hatch> plus I'm not sure if CA has any water to make beer
<hatch> boo yeah, charms deploy
<hatch> jrwren: grep for switch :'( https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/let
<jrwren> hatch: http://people.mozilla.org/~jorendorff/es6-draft.html#sec-switch-statement-static-semantics-lexicallyscopeddeclarations
<hatch> well then...
<hatch> give it time
<hatch> they have time to wreck it yet
<hatch> :P
<jrwren> hatch: This is why having beers is good. I had beers with semjs group last Monday and learned about exactly this :)
<hatch> I am really not sure why we can't have more 'statement switches' like 'use strict' to avoid javascript turning into php with run away operators
<hatch> 'use strict bools' 'use lexical scope'  ex
<jrwren> hatch: I said the same thing. I got a reasonable answer, but I don't recall what it was.
<hatch> they will break with old browsers
<hatch> so yes actually i am sure I know why - not that I agree :)
<hatch> it's purely acceptable to have your page break on certain browsers if they don't support certain features
<hatch> s/purely/perfectly 
<jrwren> hatch: not to mention, i was told there are compilers to go to ES3 to target old browsers.
<hatch> yeah they are not perfect but they do exist
<hatch> jrwren:  https://twitter.com/FromAnEgg/status/524589297643835393 maybe I'll get a real answer :)
<jrwren> hatch: that page doesn't exist.
<arosales> rick_h_: in the readme for bundles
<hatch> oops sorry I had to fix a typo, thought it would just update it https://twitter.com/FromAnEgg/status/524589600879411201
<arosales> luca would like more human readmable bundle name
<hatch> finally!
<lazyPower> hatch: *eyeballs suspiciously*
<hatch> lazyPower: wutulookinat??
<hatch> willis
<lazyPower> i'mlookinatyouethel
<hatch> wutulookinatwillis
<arosales> rick_h_: so my question is you mentioned in the new charm store you would be able to parse more metadata
<arosales> what are those fields, can we assume the same as charms?
<arosales> if same as charm does the name field have to match the parent directory?
<hatch> lazyPower: did you see http://techcrunch.com/2014/10/20/crate-lets-developers-set-up-big-data-backends-in-minutes/
<rick_h_> arosales: description and tags right now
<rick_h_> arosales: if we need more we can work on that
 * hatch waves at teslanick
<lazyPower> hatch: that'll generate some buzz, i'll be watching this closer
<lazyPower> hatch: we saw a fwe other companies presenting similar tech @ hadoop world that go as far as dropping a slick dashboard on top of it when you're done
<hatch> lazyPower: I was thinking we should respond with a blog post *caugh* onyourblog *caugh*
<hatch> cough even 
<lazyPower> hatch: what i see as a problem with this - is it has an end of the sidewalk effect with your deployment tooling
<hatch> yeah I agree
<lazyPower> as you only deploy/scale your big data stack with it, which segments your deployment tooling
<hatch> but they are getting at least a bit of traction 
<lazyPower> using juju you could wrap this and get teh best of the universe
<lazyPower> but i dont want to chase buzz - i want to chase solutions. If this gets any kind of adoption i'll respond with a bundle that wraps crate, because its *so* easy to use, they claim. Shouldn't take more than a few weeks to charm up.
<lazyPower> hatch: i'm already scheduled this week to interview hazmat and talk about his rudder/flannel density story + an emerging kubernetes story next week
<lazyPower> and as far as i can tell that'll attract a lot of attention because... docker docker docker
<hatch> I don't really see the point of kubernetes with juju
<hatch> but that's just me
<lazyPower> buzzword/buzzfeed
<lazyPower> inb4 google announcement
<hatch> lol
<lazyPower> google compute engine + kubernates = "the future of now" according to some.
 * hatch rolls eyeballs into neck
<hatch> that's how far they rolled back....right into my neck!!
<lazyPower> personally, i'm kind of sick of hearing about docker and how a delivery mechanism is going to make everything amazing. I still think a hybrid CM+IBW = the winner. There's enough out there you just *dont want* to image up and ship as immutable.
<jrwren> hadoop is over for 99% of its use cases now that azure launched their G-series. Just run it on a Standard_G5 :p   
<lazyPower> but thats me and my opinions again
<lazyPower> jrwren: actually the prediction of hadoop is its going to 'go away' - and turn into invisible plumbing that nobody talks about anymore
<jrwren> lazyPower: i'm sick of hearing about hadoop & docker, but... yeah, opinions :)
<lazyPower> now that off teh shelf solutions are starting to mature on top of hadoop.
<jrwren> lazyPower: its still a waste. avoid the jvm.
<lazyPower> jrwren: java = enterprise. Good luck winning that battle.
<lazyPower> its like trying to convert a .net shop into a ruby shop ;)
<lazyPower> it can be done, but its uphill both ways
<jrwren> lazyPower: didn't you already do that? :)
<lazyPower> ^
<jrwren> lazyPower: why go backwards like that? :)
<lazyPower> My eyes opened to so much @ hadoop world
<jrwren> lazyPower: oh no, drinking the kool-aide?
<jrwren> lazyPower: did you write a report?
<lazyPower> it cracks me up that people vendoring stuff @ the conf still have no idea what 'big data' really is.
<hatch> jrwren: rofl
<lazyPower> jrwren: sure did, sent it out the first day. it's on canonical-tech and clodus
<lazyPower> *clouds
<hatch> oh I read that as a joke on enterprise and writing reports :D
<hazmat> hatch, its like openstack or any other platform for workloads..
<hazmat> hatch, part of the story there is going into the docker community, and being like hey.. dog.. i heard you like orchestration frameworks ;-)
<jrwren> lazyPower: ah, I read that. I didn't read too much koolaide in it.
<hazmat> hatch, a little more seriously they have dozens.. and we can position juju as the easy way to collect/try them all
<lazyPower> jrwren: because i didn't drink it. i challenged what they were telling me and found there's more just under the surface
<hazmat> s/dog/dawg
<hatch> hazmat:  right, but why use any of them at all and instead just use juju?
<lazyPower> hazmat: did you read my response to crate? thats how i'm looking at all of this IBW buzz - we're gonig to find the sweet spots and enable them
<lazyPower> i'm working a pittsburgh client to upgrade their chef-server opscode hosted infra to juju powered chef-solo charms. 
<lazyPower> give me anotehr month and i bet i have them in our pocket
<hazmat> hatch, because they do more things than we do wrt to some aspect of a workflow.. or because their docker centric instead of charm centric.. docker image authoring is falling off a log.. good charm authoring.. a bit harder.
<arosales> rick_h_: sorry, my network got dropped
<hatch> hazmat: true true
<hazmat> hatch, ie. kubernetes will do round robin image upgrades etc, and persistent storage.
<rick_h_> arosales: description and tags right now, we can do more if needed
<arosales> rick_h_: I think we talked about author and name
<arosales> or at least author
<lazyPower> rick_h_: was thsi outlined in that doc you sent me @ brussels?
<lazyPower> i'll read the spec and update our bundles accordingly
<arosales> as they branch owner is not always the author/maintainer
<rick_h_> lazyPower: yes
<lazyPower> <3 ty for giving me more info than i knew i needed early
<hatch> hazmat: yeah those are two features we would be nice to have
<arosales> rick_h_: good example is ~charmers
<arosales> right now the charm store is calling ~charmers the author/maintainer when in fact that is not correct
<rick_h_> arosales: right, that's part of juju publish
<arosales> and currently pulling the name from the directory structure too
<lazyPower> what the... can anyone else get to google drive atm? mine is throwing errors at me
<lazyPower> rick_h_: we're going to see juju publish 1q of next year right? or is that coming sooner?
<arosales> rick_h_: I think regardless of publish though the bundle should state who is the author/maintainer
<hatch> definitely - i've always hated that with ~charmers
<lazyPower> arosales: sending you a link to the bundle spec in private
<arosales> rick_h_: we'll run into the same problem with publish when a charmer "reviews" a charm
<arosales> lazyPower: still dont' see author or name in that spec
<lazyPower> rick_h_: if its buried in the struct code, i'm too ignorant to parse it out. where do we define this?
<jrwren> apache-spark... because 138MB jar files are awesome. *sigh*
<lazyPower> jrwren: then use HPCC
<jrwren> lazyPower: i don't know anything about this stuff. I only know I don't like it :p 
<lazyPower> jrwren: you're not the data scientist target for these tools ;)
<jrwren> brew search hpcc says no formula. it doesn't exist :p
<jrwren> lazyPower: data scientists aren't the target for these tools either.
<lazyPower> jrwren: http://hpccsystems.com/
<lazyPower> i beg to differ
<hatch> jujugui could I get a wip review before I go fix/write all the tests on the deploy-target stuff https://github.com/juju/juju-gui/pull/624/files
<rick_h_> arosales: lazyPower otp atm back in a sec
<lazyPower> ack
<rick_h_> arosales: yes, we talked about that in brussels. We need to get work done to not call the ~charmers the author/maintainer and it's part of fugure work and won't be available for the release next week
<rick_h_> arosales: putting anything in the bundles.yaml is just like metadata.yaml. It lies on first fork and so we don't trust it and we have a path to a better way but it's work to do 
<rick_h_> lazyPower: yes, it's on the todo starting in Nov
<rick_h_> lazyPower: we'll get docs updated in the bundles docs here shortly. As we're working towards the release next week, docs are always last sorry
<rick_h_> lazyPower: but adding a card to update bundle docs for our post-release updates to do
<lazyPower> arosales, rick_h_: so what i'm parsing from our conversation is that we're not ready for me to just stuff in metadata, and should work towards a solution that 'works today' and monitor this story as it emerges?
<arosales> lazyPower: ya for luca's charm store lauch it sounds like the new bundle format with any meta data won't be available.
<rick_h_> lazyPower: correct, new fields in metadata need to be 100% good across forks (like tags/description) and any more we need we can support. However, the authoship problem is a bigger problem with a known solution that's planned in work upcoming in Nov
<lazyPower> that will satisfy luca's needs, and get us 3/4 of the way for when the new bundle spec lands - when we can update with a complete spec 
<lazyPower> ok. Thanks for the heads up rick_h_
<rick_h_> arosales: the new bundle format is available for launch, just not the owner stuff. The placement updates need an update to deployer as well that'll be part of that follow up work. 
<arosales> rick_h_: but we should certainly add the maintainer field and name to the bundle metadata (weather that lives in the bundles.yaml or someplace else I leave to the implementors)  -- do you agree?
<rick_h_> arosales: the idea is that with identity that's automatically figure-out-able other than the promulgated in which case we allow charmers to specify during the cli to promulgate something
<rick_h_> arosales: lazyPower let me know if jumping on a hangout would help explain this better 
<lazyPower> rick_h_: i think it would settle this up quicker
<lazyPower> arosales: do you have time to join or do you want me to spear head this and re-educate at standup?
<arosales> lazyPower: sorry I may have missed a invite, join which meeting?
<arosales> rick_h_: but that doesn't live in source
<rick_h_> arosales: yes, that's what we want. For it to not live in the source code. 
<arosales> rick_h_: and we still have a naming issue, specifically where do we pull a bundle name from?
<kadams54> rick_h_: Back, though the left side of my face is numb :-\
<arosales> rick_h_: well my feedback is the author name should live in source in the metadata.yaml
<rick_h_> arosales: huh? what's the issue with that?
<arosales> not just in the store
<arosales> name currently just gets pulled from the dir structure, correct?
<rick_h_> arosales: and our feedback on that is that having it in the source code, unless we go in and update it on the fly, tells users completely false information. 
<rick_h_> arosales: no, the bundle has a name in the top of the yaml format
<rick_h_> arosales: but we agreed that when we download it we'll name the zip/directory created with the bundle name
<arosales> rick_h_: ok. I think luca may be pulling the dir name . .  . we should confirm on that but agree the bundle top-level should be the correct name.
<rick_h_> arosales: https://manage.jujucharms.com/api/3/bundle/~charmers/mongodb/5/cluster/file/bundles.yaml 'cluster' is the name
<rick_h_> arosales: +1
<arosales> rick_h_: agreed in manage, but looks different on new-jujucharms qa site
<rick_h_> arosales: link?
<arosales> rick_h_: take it fwiw but I really feel in-source we should have the author named specifically
<arosales> just to try to get  attribution correct when downloading source
<arosales> unless you ae going to inject that somehow when folks download
<rick_h_> arosales: so for every upload of the bundle, at the top, you want to put the 'owner' as the source in that file?
<rick_h_> arosales: if it has to be in the source like that I'd just propose we have a server generated CONTACT or OWNER document that we do on download/etc 
<lazyPower> rick_h_: i'm missing the purpose of de-coupling this information... and i apologize if you've already covered this.
<rick_h_> lazyPower: arosales https://plus.google.com/hangouts/_/gyt4mcw4h3dci67wr243sbdkaea?authuser=1&hl=en
<lazyPower> when we say identity thats auto-figure-outable - is this so juju publish stamps the charms you push?
<hatch> jujugui still looking for someone to take a look at this wip https://github.com/juju/juju-gui/pull/624
<kadams54> hatch: I'll take a look
<hatch> thanks
<hatch> coding is done, working on tests now - but would rather catch any oddities before I finish these tests :)
<lazyPower> rick_h_: quick question about current store display - did this meet some kind of wrapping line length to shift display? https://jujucharms.com/bundle/~lazypower/big-data-logger/4/hortonworks-logging-demo/?text=hdp
<rick_h_> lazyPower: it just didn't fit, it's wrapped bug below the icon image
<lazyPower> http://i.imgur.com/uufBi9P.png - is what i see. and it looks like wrapping.
<rick_h_> lazyPower: right, it is too long to fit between the icon and the deploy button
<lazyPower> thats what i figured. Ok - ta.   new store display will make this go away.
<rick_h_> lazyPower: we should trunkcate it I guess. 
<rick_h_> lazyPower: well, it will in teh store but not the GUI
<lazyPower> oooo
<lazyPower> good point
<lazyPower> i'll file a bug report
<rick_h_> +1
<rick_h_> thuogh I'm nervous about truncating as well as many bundles might start out with less important text, guess we should try to auto shrink the font size or something better
<lazyPower> https://bugs.launchpad.net/juju-gui/+bug/1383816
<mup> Bug #1383816: line wrapping alters bundle name display <juju-gui:New> <https://launchpad.net/bugs/1383816>
<hatch> eww that's ugly
 * rick_h_ goes to find some lunch now, biab
<kadams54> hatch: just finished looking over https://github.com/juju/juju-gui/pull/624 - everything looks good.
<hatch> kadams54: thanks
<kadams54> guihelp: is there any easy way to snag all unrelated services (i.e., deployed services that are NOT related to a given serviceName)?
<hatch> kadams54: at the moment I don't think there is an inverse method for that
<kadams54> hatch: kthnx
<hatch> you could use the related services method and then take the ones which it doesn't return
<hatch> might be the easiest 
<hatch> rick_h_: after looking at using immediate: true it doesnt really get us any further because then i'd have to create the machine and place the unit on it anyways
<hatch> so it's 6/1 6/12 of another
<rick_h_> hatch: right, ok that's what I figured. at the start I had hoped it would be useful here
<hatch> yeah I had blanked on it and thought MAYBE we'd get lucky :)
<jrwren> lol @ 6/1
<hatch> haha u like that?
<hatch> jrwren: rick_h_ wow your govt is corrupt too http://jalopnik.com/michigan-governor-signs-anti-tesla-bill-into-law-1648978048
<kadams54> hatch: yeah, can't say it's all that surprising in a state that's home to the Big Three.
<hatch> from an outsider these ban's seem very anti-usa
<hatch> being such a pro capitalism country and all
<jrwren> too?
<hatch> jrwren: along with every other state that's banned it
<jrwren> hatch: the USA is super corrupt. Every politician is bought and paid for by special interests.
<jrwren> hatch: oh, Michigan.  Yes, them too.
<kadams54> jrwren: I'd say our corruption levels are on par with most of the world ;-)
<hatch> oh i thought you were in michigan jrwren
<jrwren> hatch: I refuse to say 'us'.
<hatch> ohh lol
<jrwren> hatch: i didn't vote for these jerks.
<kadams54> hatch: you find that sort of ideology kind of goes out the window when special interests (i.e. the people who vote you into office) come into play.
<kadams54> hatch: "I'm for small, efficient government! Just don't close the military base in my home state."
<hatch> lol
<hatch> this tesla thing is just baffling though
<jrwren> The law is almost certainly unconstitutional under the interstate commerce clause, but this is law until it is challenged. 
<hatch> if they had franchise dealerships then it would be ok? It doesn't make any sense
<hatch> who cares who owns the dealership
<kadams54> hatch: What's baffling? It's the old guard protecting the status quo.
<kadams54> That's what the old guard always does.
<hatch> kadams54: true but if I moved to michigan and opened a tesla dealership then it would be ok?
<hatch> (assuming tesla would do that)
<kadams54> Yeah, I think so. Tesla wouldn't do that, but yes.
<kadams54> The best option Tesla has is to sell a buttload of cars in non-restricted states
<kadams54> Depriving the restricted states of tax revenue
<hatch> right so if that's the case then I don't see how this changes anything
<jrwren> gas prices are so low now, who wants a tesla? I'll stick with a vette :p
<hatch> Elon could just open up a dealership chain of tesla dealers
<hatch> that's not owned by tesla
<hatch> essentially skirting the bs law
<kadams54> Yeah, I have no clue what sort of corporate shennanigans are possible.
<hatch> so this is why it's baffling, I dont' see how anyone benefits from this ban - if only to delay the inevitable 
<kadams54> I know Gordon Food Service's trucks were leased to GFS by another company, which was also owned by the Gordon family. The whole thing was to limit GFS' liability in case of an accident. So those sort of things do happen.
<hatch> oh yeah for sure - tons of airlines are actually many small companies being hired by the big ones 
<hatch> to do the same
<kadams54> Dragged kicking and screaming into the 21st century.
<hatch> lol
<kadams54> hatch: Ok, I'm not finding a related service method.
<hatch> kadams54: hmm it definitely exists because that's how it knows what it can relate to
<kadams54> I'm pretty sure one exists and I'm pretty sure I've seen it used elsewhere, but my ack skills are not turning up anything.
<kadams54> I'll poke around in code
<hatch> well doesn't the 'fade service' use it?
<hatch> that fades the service and it's relation lines
<kadams54> utils.getRelationDataForService() is the winner.
<hatch> there we go
<kadams54> hatch: for highlight, we need to fade all unrelated services, in addition to highlighting the selected service and its relations.
<hatch> ohh ok
<hatch> that's interesting
<urulama> jujugui: anyone needing mycomiclife CS running? I see some activity ... can it go down for 5min?
<rick_h_> kadams54: did that branch get up for WIP eyeballs?
<kadams54> rick_h_: not yetâ¦ hit a dead end, had to backtrack, getting close again.
<huwshimi> Morning
<kadams54> huwshimi: morning
<huwshimi> kadams54: Hey :)
<hatch> hey huwshimi
<huwshimi> hatch: Hey
<kadams54> Whoa. Google Canary: if you long click on the reload button, a menu pops up that lets you choose which type of reload you want to do.
<kadams54> Normal Reload, Hard Reload, or Empty Cache and Hard Reload.
<hatch> nice
<hatch> stepping away for a bit, I'll bbl to get this branch finished and up for review
<kadams54> guihelp: https://github.com/juju/juju-gui/pull/625 needs QA. Right now the code is a mess, which is why it's a WIP, so just stick to the QA.
#juju-gui 2014-10-22
<rick_h_> morning
<frankban> guihelp: I need reviews + QA for a quick branch: https://github.com/juju/juju-gui/pull/626
<kadams54> frankban: checking
<frankban> ty
<kadams54> guihelp: I need a QA on a WIP: https://github.com/juju/juju-gui/pull/625 - no need for a review yet.
<rick_h_> frankban: able to peek at ^ ?
<frankban> rick_h_: sure
<rick_h_> hatch: around?
<hatch> yeah sorry just having technical issues 
<hatch> almost back up
<rick_h_> hatch: oh party
<hatch> apple quality and all that
<rick_h_> hah
<hatch> ok good enough
<hatch> wassssuuupppp:
<hatch> ?
<rick_h_> hatch: I want demo url calls to the gui from your branch to put into the card to update the storefront
<rick_h_> hatch: and then wondered if your branch was ok to land then?
<hatch> I am still fighting with some tests but the code is stable
<rick_h_> hatch: ok, can you give me a sample bundle and charm url to put into the card for the other guys?
<hatch> so we could land it as is
<hatch> yup
<hatch> sec
<rick_h_> nah, tests need love too. Take your time
<rick_h_> just want to make sure I've got the work laid out 
<hatch> ?text=apache&deploy-target=bundle:elasticsearch/15/cluster
<hatch> ?deploy-target=cs:precise/apache2-25
<hatch> the first one shows that it's also functional with other query params
<hatch> top one bundle, second charm
<rick_h_> ty much
<kadams54> frankban: thanks for the QA!
<frankban> kadams54: np, looking at the code now
<rick_h_> jujugui call in 10 kanban please
<jcastro> rick_h_, 
<rick_h_> jcastro: party
<jcastro> for tags, in the metadata.yaml, is it "tag: foo, bar, baz" or "tags: foo, bar, baz"
<jcastro> writing up the docs for tags now
<rick_h_> jcastro: exact same as categories
<rick_h_> just s/categories/tags
<jcastro> ok but tags with an s right
 * rick_h_ double checks
<jcastro> that's what I wanted to doublecheck
<rick_h_> jcastro: yes, with an s
<jcastro> how do you want people to define multiple ones
<jcastro> commas or a list like we do with categories?
<rick_h_> a list is great
<jcastro> ok, one more question, how do I explain freeform?
<jcastro> do I say "also feel free to just make up your own but these are the default ones" or something?
<rick_h_> I thought we weren't doing freeform atm
<rick_h_> just starting with the white listed set and others would be ignored
<jcastro> ok
<hatch> how the heck do I change the time in Ubuntu? lol When I change it in the time control panel it never changes it just stays at the old value
<hatch> Webstorm 9 sure has some awesome looking features for FE/js dev
<hatch> not sure I want yet another IDE
<hatch> though
<hatch> oh our test suite
<hatch> AssertionError: expected { opt1: 'opt1default' } to equal { opt1: 'opt1default' }
<rharper> Hi Folks,  I heard that there was a tool that would take a bundle yaml file and generate a png juju-gui style with the charm icons and relations  -- anyone here heard of that ?
<rick_h_> rharper: https://github.com/juju/jujusvg is the work in progress. It's not 100% ready yet
<rharper> rick_h_: cool, thanks!
<rick_h_> rharper: but it's what we want to build out to do that
<marcoceppi> rick_h_: tags. Are they going to be in metadata or only in the charm store?
<rick_h_> marcoceppi: in the metadata
<rick_h_> marcoceppi: s/categories/tags in the metadata done
<marcoceppi> why
<rick_h_> marcoceppi: well, except for the list of tags we support
<rick_h_> marcoceppi: huh?
<marcoceppi> well, if it's living in the metadata why even bother renaming
<marcoceppi> secondly, it totally shouldn't live in the metadata at all, to add a new tag I have to rev the charm
<marcoceppi> seems so silly
<rick_h_> because it's added to bundles and the naming in the UI is tags now so the idea is to use a consistent term from UI, bundle.yaml, and metadata.yaml
<rick_h_> marcoceppi: ok, but when you fork a charm does a tag still apply?
<rick_h_> marcoceppi: so when you fork/push we want those to carry through so having them in the metadata makes sense
<marcoceppi> I was hoping we could use tags for additionaly bits
<rick_h_> 'additionaly bits'?
<marcoceppi> additional bits
<marcoceppi> god I wish I can remember who I was talking to who said this was going to live in store
<rick_h_> marcoceppi: so tags turn into clickable searches in the UI
<rick_h_> marcoceppi: so the idea is tags are a more fleshed out category idea that's limited at first to a sec of approved 'searches' and over time we'd allow more freeform when we can help guide users like stackoverflow tags
<rick_h_>  s/sec/set
<rick_h_> I'm not sure what 'additional bits' you were thinking?
<marcoceppi> right, so tags and question edits are decoupled
<marcoceppi> editing a tag on a question does not rev the question
<rick_h_> marcoceppi: understood, but you also don't fork a question and want to keep the tags on the followup
<rick_h_> marcoceppi: I can see it both ways, the way we're going for helps one case vs the other. 
<rick_h_> marcoceppi: we can look at adding tags as live updatable metadata, we've got longer term plans for that, description/etc in the future
<rick_h_> marcoceppi: but for now, they're in the metadata.yaml
<marcoceppi> had I known this was the course of action I would have been more vocal about it earlier
<marcoceppi> oh well.
<rick_h_> marcoceppi: sorry man, we can look at things after the fact, but days before launch is a bit short to rethink it. 
<rick_h_> marcoceppi: if there's a communication lesson we can learn from this please let me know. 
<marcoceppi> I know it is, I'm just sad I misunderstood the change
<marcoceppi> and wanted to clarify before making changes to charm proof
<jrwren> marcoceppi: was it me? an admin can put any metadata one wants in the store in a place we call extra-info
<rharper> rick_h_: looking at the jujusvg repo,  I need to write out that simple go program from the readme to have it generate the svg?
<rick_h_> Makyo: can you help rharper put together a quick something to try out using the jujusvg stuff? ^
<Makyo> rharper, correct.  jujusvg is meant to be a library - something can read a bundle and pass it to NewFromBundle and receive an SVG in return.
<rick_h_> Makyo: I've rharper it's not quite ready yet as a cli tool, but if you can help him put together a pastebin script with a couple of steps to try it out that'd be great. 
<rharper> yeah, that'd be very helpful
<Makyo> rharper, rick_h_ Sure, let me pull something together real quick.
 * rick_h_ goes afk for a bit
<hatch> jujugui looking for reviews and qa on https://github.com/juju/juju-gui/pull/624 thanks
<Makyo> rharper, https://gist.github.com/makyo/3a5e4428dc2351115a26 I've pulled together a sample program that uses the jujusvg library and a sample bundle that you can run that program on.  You should be able to type `go get -u -v -t github.com/juju/jujusvg/...` then `go run 00-svg-test.go` and as long as bundle.yaml is in the same directory, it should build the SVG for you.
<rharper> Makyo: very coo;
<hatch> Makyo:  got a second to join a chat?
<Makyo> rharper, the readme on jujusvg is out of date, it appears.  I'll update that.
<Makyo> hatch, surew
<hatch> in standup
<rharper> Makyo: yeah, was just hacking through that looking at the svgjuju test.go 
<rharper> when I put my openstack bundle through it, it says, at least one service must be specified ... any idea what that means?
<rharper> Makyo: this is my bundle: http://paste.ubuntu.com/8631892/
<Makyo> rharper, it looks like this was generated by hand, or at least without the GUI.  Since it does not have position annotations, jujusvg will, by default, stack the services on top of each other.  The GUI uses a circle-packing algorithm to position services without position annotations, but jujusvg doesn't yet know how to do that
<rharper> Makyo: ok, I have another that I exported fro juju gui and it says the same thing
<rharper> http://paste.ubuntu.com/8631918/
<rharper> Makyo: that last one, I can export from gui, import back into gui fine, but running on the svg tool says
<rharper> 2014/10/22 15:29:25 Error generating canvas: cannot verify bundle: at least one service must be specified
<Makyo> rharper, ahah, there is work currently in the GUI to export a bundle without the old "basket" syntax.  You can fix that simply in the bundle.yaml file by removing the top-level yaml node (env-export) and dedenting everything once below it.  There's a sea-change on how bundles are handled throughout the juju ecosystem
<rharper> ok, lemme try that
<rharper> Makyo: that fixed it, but the icons aren't there (viewing svg via eog) 
<rharper> just the lines
<Makyo> rharper, try with $BROWSER; the svg renders the icons as images with references as URLs, so it will only work with internet-aware viewers
<rharper> yeah, I see that
<rharper> interesting
<Makyo> In the future, we may include the icon SVGs when possible as SVG <ref>s, though that will make for a very big SVG
<rharper> Makyo: nice
<rharper> any way to get the service name too ?
<Makyo> rharper, not yet, unfortunately.  jujusvg is pretty new.
<rharper> ok
<rharper> Makyo: yeah, would be nice to have it handle the current jujugui export (ie, throw away the top level to find services), write the service name;  and since I'm asking for ponies, emit out a png so I can put these in slides and other stuff showing the bundles off.
<rharper> Makyo: thank you for putting that together quickly, that helps
<hatch> PONIES!!!
 * hatch might land an easter egg in the GUI in which a pony walks across the screen 
<Makyo> rharper, np.  For the first part, jujugui will start exporting the new format $soon (hatch, right?), and the PNG work will be coming up $later, as we'll be adding the ability to email a bundle with a preview png
<rharper> very nice
<hatch> Makyo: there is a new export format? :)
<Makyo> hatch, I thought that was part of the work for Ben, may be wrong.
<Makyo> I'll go back to my code cage, if so.
<hatch> Makyo: ohh that was to support multiple relation endpoints on a single endpoint
 * Makyo goes back to code cage u.u
<hatch> lol
<Makyo> hatch, just means getting rid of the 'env-export' top level YAML node
<hatch> ohh - yeah i'd love to get rid of that
<hatch> jujugui I stll need some reviews and qa on https://github.com/juju/juju-gui/pull/624 
<huwshimi> Morning
<rick_h_> morning huwshimi 
<huwshimi> rick_h_: Hey :)
#juju-gui 2014-10-23
<frankban> guihelp: another quick fix to the GUI: https://github.com/juju/juju-gui/pull/627
<kadams54> frankban: taking a look
<frankban> ty
<kadams54> frankban: looks good.
<frankban> kadams54: great thanks
<kadams54> hatch: let me know when you're available.
<hatch> kadams54: just responding to your replys
<kadams54> hatch: yesterday you talked about moving the event handling into an extensionâ¦ why?
<kadams54> Or maybe I'm misunderstanding?
<hatch> just the handlers
<hatch> it's because these views are getting unweildy and difficult to test
<kadams54> OK
<kadams54> Agreed.
<hatch> as an extension we can easily test the handlers separate from it all
<hatch> kadams54: also this branch is missing tests
<hatch> did you forget to add them to the commit?
<kadams54> No.
<kadams54> I'm adding tests in my current branch.
<hatch> oh they should probably go in this one if I'm going to be building on top of this code and possibly modifying it
<hatch> kadams54: I have a wierd issue with the machine view qa
<hatch> if I highlight two services then no machines are visible
<kadams54> hatch: You confident enough in our approach to wrap it in tests?
<kadams54> hatch: yeah, don't do that.
<hatch> it's just a utility method
<hatch> lol what do you mean don't do that? Is this a bug?
<kadams54> Stuff involving multiple buttons being pushed doesn't work yet.
<kadams54> The spec is divided up into 3 sections: hiding, highlighting, and cross over (multiple states invoked at once)
<kadams54> cross over wasn't addressed by this card
<hatch> ahh yeah we don't modify the db for machines anywhere
<hatch> kadams54: didn't we get a new icon for the highlight?
<kadams54> hatch: not sure what you mean by "it's just a utility method". findUnrelatedServices() needs tests for sure, but that's not what I'm worried about. It's the changes in renderUnits() in both contianer-token.js and machine-token.js.
<kadams54> hatch: not yet. We were promised one, but it has not arrived. luca?
<hatch> kadams54: findUnrelatedServices has a very similar usecase to getRelationDataForService
<hatch> the latter is a util method so why isn't the former
<hatch> the former needs access to things it coudln't possibly know about
<hatch> db and utils
<kadams54> Becasue I don't think the latter should be a util method.
<kadams54> And I reject your assertion that it couldn't, because it does :-)
<hatch> methods on a model should only ever interact with the data in that model
<kadams54> False
<kadams54> Model methods can also deal with relations that the model has to other models
<hatch> no because then you have to pass that in
<hatch> you then have to stub all that in tests
<hatch> it's a clear hierarchy that's being violated 
<hatch> the child (model) shouldn't need to know about it's parent (modellist) or grandparent (db)
<kadams54> It's possible that I'm just not groking the hiearchy here, but I was kinda surprised that the models here had no way to refer back to the DB.
<hatch> that's intentional 
<kadams54> That's not my experience with models in other MVC frameworks
<kadams54> How do you deal with one-to-many relations?
<kadams54> i.e., a machine that contains many units?
<hatch> YUI is based on OOP
<kadams54> I agree that it's less than ideal to pass the DB in, but IMO that's only because the model ought to have a way to get back to the DB baked in.
<kadams54> LOL
<hatch> in OOP you don't know about your parents
<hatch> one to many relations are pushed up the stack
<hatch> either to the modellist or to the db
<kadams54> That restriction, that models can only operate on their own internal data, seems to relegate them to pretty dumb objects.
<hatch> exactly
<hatch> that's the whole point 
<hatch> take a look at Lazy Model Lists - they ARE just objects 
<kadams54> Sure, but I thought that was a concession for performance
<rick_h_> dumb objects ftw
<kadams54> rick_h_: bah
<rick_h_> :)
<kadams54> In my experience, particularly in the Java world, dumb data objects lead to incredible code bloat.
<rick_h_> ime dumb objects lead to great testability, easy resuability, and easier debugging
<hatch> "...in the Java world...incredible code bloat..." there I fixed it for you :P
<kadams54> They couldn't do anything, so you had to write all these other classes that manipulated them. DOs were wrapped by DAOs so you could do data query operations. Then the controllers took the DOs out of the DAOs and re-wrapped them in some other view object whose name escapes me, to prep the object for the view.
<kadams54> Don't get me wrong. Fat models are also bad.
<kadams54> But the truth is in the middle.
<rick_h_> kadams54: hatch I'm not up on the whole conversation, just speaking in general terms the GUI's been bitten by parts that were too smart for their own good and we've learned that dumber parts (widgets, models, etc) have helped the gui over the long run
<kadams54> I'll do it as a util method, but under protest. util methods suck.
 * rick_h_ reads more of backlog
<hatch> I'm ok with that :)
<kadams54> Just as a general conceptâ¦ I tend to be opposed to putting things in utils because all too often it turns into an unwieldy dumping ground for code bloat.
<hatch> yeah I agree with that
<kadams54> So your objects are all nice and clean and shiny because you just outsourced the crufty stuff to a monster 5000 line mish-mash of "utils"
<hatch> but you could put it in the db
<hatch> and typically you have multiple utils files 
<hatch> (we only have 3) :P
<kadams54> IMO the DB ought not know about the relations within it. ServicesList seems like the better fit to me.
<rick_h_> hmm, so just reading the backlog, the method findUnrelatedServices seems like it'd be something I'd call on a db passing in a service.
<kadams54> Though, per my comment on the PR, it doesn't seem like the type of aggregate operation that is intended for ModelList.
<rick_h_> someone link me to the source?
<kadams54> https://github.com/kadams54/juju-gui/blob/hide-highlight-tweaks/app/models/models.js#L313-L328
<hatch> rick_h_: I also commented on your question in my PR https://github.com/juju/juju-gui/pull/624#discussion_r19251726
<rick_h_> so yea, anti it being on service, but +1 on it being up the stack there in the service list/db.services
<rick_h_> vs a util
<hatch> I'll go with that
<rick_h_> just to toss in my .02
 * hatch throws in his .02 
 * hatch hopes kadams54 isn't rich
<kadams54> hatch is in luck.
<hatch> lol
<hatch> I was waiting for you to drop $1 on there :P
<kadams54> OK, I'll move it up to the servicelist and add a test.
<hatch> udaman
<kadams54> Anything else needed to land this branch?
<hatch> well I'm curious about your concern for the render method
<hatch> it looked fine to me
<hatch> am I missing something? :)
<kadams54> The changes need to be tested, but the underlying code seemed very hacky to meâ¦
<kadams54> Though that was before our chat yesterday.
<kadams54> I was going to write more functional-ish tests that exercised the UI-facing bits of code as part of moving away from custom events and towards database changes.
<hatch> ahh - well the render code looks good - I think that once we make the 'db the source of truth' stuff then it's easy to reason about 
<kadams54> Yeah, sounds good. Test findUnrelatedServices in this branch, test the rendering in subsequent branches.
<kadams54> Is that a correct summary?
<rick_h_> hatch: kadams54 and I'm going to pull the 'remember my settings' card for now. I want us to focus on using the feature/etc over that
<hatch> kadams54: yep that fine - just make sure those tests get in there later ;)
<kadams54> I'm not familiar with that card?
<hatch> rick_h_: kadams54 yep that's good I already marked it as low
<kadams54> Oh, nevermind
<hatch> :)
<kadams54> I thought you meant a "card" as in "I'm pulling the team lead, master-of-the-universe card.", not as in an actual kanban card. :-)
<rick_h_> kadams54: oh, no I try to keep my 'team lead' cards in a box on the desk
<hatch> when that box drops, you'll know
<kadams54> Right next to the Crimes Against Humanity box, right?
<kadams54> ;-)
<hatch> california will finally split from the US via an earthquake 
<Makyo> jujugui call in 6
 * hatch just realize hatch and Makyo are the same character length
<Makyo> It's only been, what, a year and a half?
<hatch> pretty close to 2 yep :)
<hatch> trying to join
<rick_h_> kadams54: frankban Makyo ^
<hatch__> guess I'm going to have to spin up a new vm with utopic on it now
<hatch> I'm really curious if we could do the canvas with react...
<hatch> frankban: +1 on your GUI branch
<hatch> my GigE router has a max transfer rate of about 50MB/s
<hatch> lol false advert much?
<frankban> hatch: thanks
<jrwren> hatch: that is max gigE
<jrwren> hatch: to go higher than that you need to enable jumbo frames, which you probably do not want to do.
<hatch> 50MB/s is the max?
<jrwren> hatch: with a 1500byte MTU, yes.
<hatch> well what the deuce 
<hatch> Do you know how long it takes to back up 100GB at 50MB\s
<hatch> long time!
<hatch> that's how long
<jrwren> hatch: there is a pretty bad discussion about it here: http://arstechnica.com/civis/viewtopic.php?t=343089
<hatch> so basically I'm SOL if I want anything faster :)
<hatch> well, I suppose I could buy a thunderbolt equipped NAS and park it beside my laptop
<hatch> :)
<jrwren> 10gig is getting cheaper.
<jrwren> or I could be completely wrong.
<hatch> tbh I had no idea that gige was so slow
<hatch> no wonder server networks are all fiber
<jrwren> its gigabit, not gigabyte.
<jrwren> you are getting about 50% of that, because your default MTU is 1500
<jrwren> gigE supports going to 9k MTU.
<hatch> right but that's huge
<jrwren> IME server networks aren't all fiber.
<hatch> heh
<jrwren> the server networks can run 9k MTU though.
<hatch> is it still TCP? So it would do the ramp up to 9k?
<jrwren> no, that is ethernet MTU
<hatch> intersting....
<hatch> so what are the downsides to increasing the MTU? Some things may not support it?
<hatch> kadams54: I can't find any reason why the service items unhide when pan'd
<hatch> this stuff is very opaque with everything being controlled by events firing everywhere heh
<hatch> kadams54: there is a bug when you try and hide/highlight a ghost service - is this known?
<hatch> Uncaught TypeError: Cannot set property 'highlighted' of undefined service.js:1439
<hatch> annnd now I have found why it's being shown again :)
<jrwren> hatch: your rather has to be able to fragment packets, which ipv6 doesn't allow, so anything ipv6 will be broken.  your inet router presumably is not gigabit, and so supports MTU of 1500, and that ends up as a lot of fragments, which slows things down.
<jrwren> hatch: fragment reassembly is expensive.
<jrwren> hatch: it may be worth cautiously playing with :)
<kadams54> hatch: a bug on highlighting a ghosted service is new to me.
<hatch> lol 
<hatch> maybe
<hatch> kadams54: ok I'll file it
<hatch> kadams54: https://bugs.launchpad.net/juju-gui/+bug/1384819
<mup> Bug #1384819: Hiding ghost services throws console error <juju-gui:New> <https://launchpad.net/bugs/1384819>
<rick_h_> hatch: feel free to triage that as high and add a card for it
<hatch> doing
<rick_h_> ty much
<kadams54> hatch: test added and findUnrelatedServices moved. I rebased before pushing and then realized I should not have, so sorry about that.
<hatch> s'ok i'll take a look
<hatch> odd my ubuntu clock is accurate today
<hatch> kadams54: one comment
<hatch> just thought of it reading your tests
<kadams54> I don't know what peer relations are?
<kadams54> How this handles different types of relationships (subordinate and otherwise) probably depends on how getRelationDataForService handles them.
<kadams54> If it reports them as a related service, then they will be excluded from the set of unrelated services.
<hatch> hmm
<hatch> a peer relation is essentially a relation between itself
<hatch> then there are subordinate relations
<hatch> which I think work as expected....
<hatch> we should definitely add these relation types to that test
<hatch> just to be safe
<hatch> I have somehow made my irc client go fullscreen and I can't get out of it
<rick_h_> lol
<jcw4> hatch: I think quassel has bugs around full screen
<hatch> yeah...hmm
<hatch> I can't even close it lol
<jcw4> I kept crashing or getting it stuck so I quit using f11
<jcw4> teh suk
<jcw4> hatch: the additional bummer is even if you kill it it may start in full screen again because of preferences
<hatch> well here is to hoping I don't do THAT again
<hatch> yeah I got lucky
<hatch> I was worried about that
<hatch> kadams54: so I don't know off hand what the syntax for peer or subordinate relations are - so you might want to deploy wordpress to get the peer relation data
<hatch> and I think nagios has a subordinate charm
<hatch> so you could do that one for that data
<hatch> I wish there was a Textual for Ubuntu
<hatch> Textual is a killer IRC client
<jcw4> Textual is my favourite too... I just like quassel because I have quassel core running on an always-on ec2 instance so I don't lose history
<hatch> yeah Textual has deep ZNC integration
<hatch> but it doesn't run on Ubuntu
<hatch> :)
<kadams54> hatch: do you think that's relevant to the function being tested?
<kadams54> Seems like it would be more appropriate in tests for getRelationDataForService
<hatch> well that function needs to work properly to return the unrelated services - if it's returning unrelated that are actually related 
<hatch> well no the getRelationData method returns the relation data
<hatch> at least as I understand it
<hatch> technically it's returning all 'related' services then it's up to something else to act on that
<kadams54> Ah, so you think the data for a peer or subordinte relation would not be structured as { far: { service: 'foobar'}}
<hatch> I'm not sure tbh :)
<hatch> it just came to mind while reading the test
<kadams54> I thought your concern was that the set of related services might not include everything it should.
<hatch> I would hate if a subordinate wasn't hidden (or was) when it wasn't suppsoed to be
<kadams54> But it sounds like that's not right; what you're actually worried about is that the data in that set could look different for different types of relationships. Is that correct?
<hatch> right
<kadams54> I'll verify
<hatch> if you're filtering on 'far' but 'subordinate' is still shown
<hatch> then that'll be a UI bug
<hatch> but not sure if that's a real issue :)
<hatch> thanks for looking into it'
<hatch> I know know where the canvas bugs are comign from but still groking how best to fix
<hatch> lunching
<kadams54> hatch: verified that subordinate and peer relationships use the same data structure.
<hatch> kadams54: awesome thanks
<kadams54> hatch: you a +1 to land that?
<hatch> oh yeah
<hatch> :)
<hatch> sorry
<urulama> nice to see CS surviving floods of icon requests :D
<rick_h_> :)
<hatch> moar pichures
<urulama> :D :D
<hatch> rick_h_: jcsackett do you guys know if I can install GUI'd applications in an lxc?
<rick_h_> huh?
<rick_h_> what's a GUI'd application?
<hatch> well anything with a GUI, say Eclipse IDE
<urulama> hatch: ssh -X ?
<hatch> or sublime, etc
<rick_h_> yea, probably have to do X forwarding/etc but sure
<rick_h_> hatch: I think serge had a blog post on doing that
<rick_h_> https://www.stgraber.org/2014/02/09/lxc-1-0-gui-in-containers/ 
<hatch> essentially I'm wondering if I could create a charm for developing with dart which would include the ide and such
<rick_h_> hatch: ^
<hatch> ahh excellent
<hatch> yet another weekend project that may or may not get started on :)
<hatch> it would be super awesome to juju bootstrap local; juju deploy dart-dev-env :)
<hatch> I'm just using dart as an example - this could be very helpful for many different dev envuironments
<huwshimi> Morning
<hatch> yooooo
<rick_h_> huwshimi: morning 
<rick_h_> huwshimi: hatch sorry, doing dishes and lost track of time
<huwshimi> rick_h_: Hey, no problems
<rick_h_> hatch: did you need to do weekly call?
<rick_h_> huwshimi: let's just meet there in case he wants to jump in
<rick_h_> https://plus.google.com/hangouts/_/calendar/cmljay5oYXJkaW5nQGNhbm9uaWNhbC5jb20.dd77sn7kjl6unba21lutdr0p70?authuser=1
<huwshimi> rick_h_: Yep, just joined
<huwshimi> oh
<huwshimi> joinoing
<huwshimi> rick_h_: The issue from Maddison's branch is actually an issue already on trunk, so I might just ship his branch and then do a tiny followup branch to fix the issue. Sound OK?
<rick_h_> huwshimi: rgr
<rick_h_> huwshimi: thanks!
<huwshimi> rick_h_: np, thank you!
#juju-gui 2014-10-24
<huwshimi> OK, any ideas how we can view bundles anymore, it seems even the few urls with series in them have now disappeared!
<huwshimi> Ah, hacking the routes.py workes for now
<hatch> sooooooo anyone else in today? :)
<hatch> jujugui call in 4?
<frankban> hatch: why not?
<hatch> any other guiers today?
<hatch> :)
<hatch> oh hey frankban
<hatch> :)
<frankban> hi there, you'll never walk alone
<hatch> lol
<hatch> kadams54: calling `this.get('topo').update();` from within the browser.js context will fire off the update methods for all of the components in the topology - so the service AND relations
<hatch> kadams54: but with that said - I'll do that as the final thing in my branch :) calling it now breaks things haha
<kadams54> lol
<hatch> kadams54: someone could go from 'hidden' to 'highlight' in the canvas right?
<kadams54> hatch: yes, and potentially have both states
<kadams54> Well, strike thatâ¦
<kadams54> Hmm
<kadams54> I don't think you can have both states at the same time, but you can be related to a highlighted service and be hidden yourself.
<kadams54> So then you need to be faded to .2 opacity
<hatch> hah hmm ok
<hatch> thanks
<jcastro> hatch, ping
<hatch> jcastro: sup
<jcastro> do we have a pile new screenshots of the new machine view etc?
<jcastro> the linuxjournal guys are writing up the gui and need hero shots of the machine view, containers, etc.
<hatch> eta on release?
<hatch> we have some but each has their own
<hatch> so would have to reach out to the team
<jcastro> asap
<jcastro> they're shooting for monday to publish, sorry so last minute
<hatch> darn - design is probably the best to get in touch with
<jcastro> ok
<hatch> rick_h_: ping u around?
<jcastro> he's off today
<hatch> just seeing if he is around - he had some from orange box 
<hatch> yeah
<hatch> jcastro: do you still have the OB?
<jcastro> nope
<hatch> darn - see the reason we need the OB is so that we can get machine details in the tokens in the MV
<hatch> else they would be easy to make in sandbox mode
<hatch> other than that we have to spin up a ton of ec2 instances heh
<hatch> do we know if we can get access to one?
<hatch> jcastro: http://design.canonical.com/2014/10/designing-machine-view/
<hatch> these look pretty nice
<jcastro> oh dude!
<jcastro> perfect, thanks!
<hatch> :D
<hatch> just make sure not to use the animated one
<hatch> those are prototypes haha
<hatch> glad I could help - anything to get the Juju word out :)
<hatch> lazyPower: hey are you around?
#juju-gui 2014-10-25
<rick_h_> jcastro: you have the shared dropbox folder with the screenshots from out blog posts/etc in it
<rick_h_> jcastro: I shared that out to you and sally, it's all the 'mass screenshots' we've got right now
<rick_h_> jcastro: plus the two videos we did for release
#juju-gui 2015-10-19
<bac> hey rick_h_, i just filed for some vacation .
<rick_h_> bac: rgr will peek
<bac> ty
#juju-gui 2015-10-20
<lazypower> rick_h_, crap
<lazypower> rick_h_, i didnt mean to resolve that comment ;_;
<rick_h_> lazypower: ?
<lazypower> in the juju terms doc
<lazypower> i resolved one of your comments re; hook tool
<lazypower> and i cant figure out how to get it back
<rick_h_> lazypower: go to the comments button in the top right
<rick_h_> lazypower: find the comment and you can reopen it
<rick_h_> lazypower: I reopened it
<rick_h_> lazypower: got a sec to chat?
<lazypower> thank you, sorry about that
<lazypower> sure
<rick_h_> https://plus.google.com/hangouts/_/canonical.com/rick?authuser=1
<rick_h_> adjust authuser/etc
#juju-gui 2017-10-23
<mhilton> ng all
