#juju-gui 2013-03-18
<hatch> morning
<frankban> hi hatch 
<frankban> rogpeppe: I am encountering 8 failures in juju-core trunk tests, all related to uniter_test.go
<frankban> rogpeppe: and hi :-)
<rogpeppe> frankban: hiya
<rogpeppe> frankban: you're best raising this in juju-dev, i think. i'll just check that i see the same thing first though.
<frankban> rogpeppe: thanks
<frankban> Makyo: good morning, re annotations branch, we are almost there :-)
<Makyo> frankban, \o/
<Makyo> I will need at least one more coffee before I can understand Go.
<rogpeppe> frankban: uniter tests pass for me in trunk
<rogpeppe> frankban: could you paste me your errors?
<frankban> rogpeppe: trying, re-running the whole suite, failures include lots of debug messages
<frankban> rogpeppe: http://pastebin.ubuntu.com/5625282/
<rogpeppe> frankban: interesting. i'll pass it over to dimiter and william, who've been working on the uniter stuff
<frankban> rogpeppe: thanks
<gary_poster> rogpeppe, hi!  Exciting seeing the allwatcher branches move through.  On a mostly unrelated topic, we will want the GUI to expose upgrade charm from both pyjuju and juju-core.  AFAIK it is not yet implemented at all in juju-core, even as a command.  Am I right?  If so, do you know who will be responsible for that implementation?  I have some questions from the designers that I'd like to get answers for (http://paste
<gary_poster> bin.ubuntu.com/5625286/)
<rogpeppe> gary_poster: in a meeting currently
<gary_poster> rogpeppe, ack np 
<gary_poster> jujugui call in 2 in guichatr
<gary_poster> guichat
<benji> gary_poster: my browser doesn't want to connect to the hangout; I'll be there as soon as possible
<gary_poster> ack benji
<rogpeppe> gary_poster: dimitern is implementing charm upgrading. i think it's going pretty well
<gary_poster> rogpeppe, great will ping him later
<gary_poster> benji,  how goes set_constraints
<rogpeppe> gary_poster: i'd still be interested in any comments you have on the allwatcher reviews, BTW. i'm going to be submitting https://codereview.appspot.com/7815044/ shortly, but if you want to take a look, i'll hold off for a while.
<benji> gary_poster: pretty good; once I figure out this import loop it should be smooth sailing
<gary_poster> ok great thanks both
 * benji reboots while giving the Google Hangouts plugin the evil eye.
<rogpeppe> frankban: i'm presuming you saw those uniter test failures on the latest version of trunk (1012) ?
<frankban> rogpeppe: yes, running the suite again using 1013
<rogpeppe> frankban: perhaps you could liaise with dimitern on #juju-dev to try to resolve this, as you seem to be able to reliable reproduce the issue.
<rogpeppe> frankban: i'm going for lunch now
<frankban> rogpeppe: I will, thanks
<andreas__> hi, is this a known bug? http://i.imagebanana.com/img/2sphe691/Selection_001.png
<andreas__> the clutter, and the fact that there are no relations drawn
<ahasenack> if I drill down on a box (double click), the relation is displayed
<Makyo> ahasenack, Not seen that before.  What browser and version of the gui?
<ahasenack> Makyo: chrome, gui "stable" according to the charm
<ahasenack> just deployed
<Makyo> guihelp ^^^
<ahasenack> Google Chrome	25.0.1364.172 (Official Build 187217) 
<Makyo> ahasenack, Alright.  Give me a sec take a look on my side real quick
<gary_poster> ahasenack, never seen.  Makyo thanks for looking.  A URL for Makyo would help if you can share it ahasenack 
<ahasenack> gary_poster: I don't think I can, it's deep within a private network
<gary_poster> ahasenack, ack
<Makyo> ahasenack, Is there anything in the JS console? Ctrl+Shift+J
<ahasenack> Makyo: hm, yes
<ahasenack> Makyo: http://pastebin.ubuntu.com/5625372/
<ahasenack> http://pastebin.ubuntu.com/5625378/ when I reload the page
<Makyo> ahasenack, Ah, thanks.
<hatch> Makyo: I am thinking that might be caused by views/landscape.js ln 19
 * hatch grumbles because he can't get the IE tests to fail again
<Makyo> hatch, Yeah, that's the exception.  Looks like  we're passing undefined to it from getLandscapeURL, though.  Digging into that.
<ahasenack> landscape itself might be having problems in sending down some annotations, we have a bug open to track a traceback
<Makyo> ahasenack, Yeah.  From the looks of it, the services do not have a landscape-computers annotation coming from juju (app/views/landscape.js:123 for those keeping track) which is causing the drawing of services to fail part-way through.  There should be a check on that annotation in there as well.
<ahasenack> Makyo: ok, so that is breaking the rendering
<Makyo> ahasenack, Yep.  The services being cluttered is a separate issue, FWIW, but that is what's stopping the services from rendering completely with the health graphs, proper name placement, etc.
<ahasenack> ok
<Makyo> Filed #1156662, will do a quick branch to at least add the check.
<_mup_> Bug #1156662: getLandscapeURL is not checking annotations on models other than environment <juju-gui:New for makyo> < https://launchpad.net/bugs/1156662 >
<hatch> Makyo: I wonder if we shouldn't notify the user that there is a problem?
<ahasenack> Makyo: thanks
<gary_poster> ahasenack, the services being cluttered is something that the user is supposed to be able to address by dragging them around.  Not ideal, but workable, and only painful initially (the service locations are shared and persistent)
<Makyo> hatch, Yeah, we don't have any requirements yet around that story.  Any suggestions, guihelp, ahasenack, goodspud?
<hatch> alert('Landscape broked - tell boss');
<ahasenack> well, I will have to see how it looks when the rendering is complete
<bac> gary_poster: lp2kanban is having buildout issues.  can you quickly diagnose it?  https://pastebin.canonical.com/87040/
<hatch> Makyo: do we have a story for warnings in general? something akin to http://twitter.github.com/bootstrap/components.html#alerts
<bac> gary_poster: if not i'll dig into it in a bit, after getting my real branch re-proposed
<gary_poster> bac afraid completely booked
<bac> gary_poster: ok, p
<bac> np
<Makyo> hatch, two: notifications and alert widgets (though the latter are generally used in a confirmation sense).
<Makyo> hatch, You can try removing a subordinate relation to see one used in a warning sense, though.
<hatch> ahh ok - I wonder if it makes sense to use that type of warning?
<Makyo> hatch, Perhaps.  While it's a good indicator that something's fairly wrong, we've been using notifications for something wrong with the data we've received.
<hatch> ahhh yeah I suppose it's not an issue with the gui itself but with the data being received
<Makyo> ahasenack, Is a screenshot helpful? http://ubuntuone.com/3KzgiaR1qBqjWpv2Sj4D3r  If you need more, I can see what I can do.
<hatch> jcsackett: are you around?
<benji> rogpeppe: I have an import loop that I'm having problems solving; here is the diff that generates it: http://paste.ubuntu.com/5625502/
<ahasenack> Makyo: what is that screenshot about? That 1 alert?
<rogpeppe> benji: it might be worth compiling against go tip - the go tool should tell you what the import cycle is.
<Makyo> ahasenack, The completed rendering.
<rogpeppe> benji: if you don't want to, paste us the branch and i'll do it.
<benji> rogpeppe: any tips on how to install go tip?
<gary_poster> ahasenack, I think he was replying to your "I will have to see how it looks when the rendering is complete."  You'll want to see it in full QA of course
<ahasenack> Makyo: ah, sure, it looks fine. I meant that I would have to see how mine looks, with so many units
<Makyo> ahasenack, Ah, okay.
<gary_poster> ahasenack, how many services is that?
<benji> is installing tip reversable?  will it lead to other problems working on go code if the others on the team aren't using tip?
<ahasenack> and how hard it will/would be to unclutter it
<ahasenack> gary_poster: 29 or so
<rogpeppe> benji: i install go tip inside $HOME/go; and yeah it's reversible by simply deleting that directory.
<gary_poster> ahasenack, that's at the top limit of what we say we support.  You should still be able to get it to work.  Does that collection represent some real-world-ish use case?
<benji> rogpeppe: cool, is there a web page that describes how do do that?
<rogpeppe> benji: assuming you've got mercurial installed, hg clone https://code.google.com/p/go/; cd go/src; ./all.bash
<ahasenack> gary_poster: yes
<rogpeppe> benji: should do the trick
<rogpeppe> benji: one mo, i'll look
<benji> rogpeppe: cool, I'll give it a try
<gary_poster> ahasenack, cool.  Do you mind telling me what the use case is?  It would be good for us to document a real world use case of that size
<ahasenack> gary_poster: openstack deployment
<rogpeppe> benji: you *might* have to do 'hg update tip' before building
<rogpeppe> benji: oh yes, you'll need to set $GOROOT to the root of the go source tree
<benji> ah
<gary_poster> ahasenack, wow!  I thought that was under 10.  Maybe once you have that running with proper rendering I can ask you for a screen shot so I can see how they all interconnect.
<rogpeppe> benji: i regularly use two copies of go root - one running 1.0.2, one running tip
<ahasenack> gary_poster: yeah, I have more than one unit per service here
<rogpeppe> benji: here's the shell script i use for switching to use 1.0.2 http://paste.ubuntu.com/5625516/
<gary_poster> ahasenack, you use multiple units within a service
<ahasenack> gary_poster: like 4 compute nodes, for example
<benji> cool
<rogpeppe> benji: it's worth having a separate GOPATH to use with the separate go version, i think.
<gary_poster> ahasenack, so unless there's something unusual with what you are doing, the compute node should be a single service
<gary_poster> ahasenack, with 4 units
<ahasenack> gary_poster: and each unit is one computer
<gary_poster> ahasenack, yes
<ahasenack> openstack has many services
<rogpeppe> benji: i generally develop against tip and test against 1.0.2 before proposing (or when i want to run tests while i'm switched to another branch)
<gary_poster> ahasenack, right but < 10 yeah?
<frankban> Makyo: ping
<rogpeppe> benji: ah, here are the official installation instructions: http://golang.org/doc/install/source
<rogpeppe> benji: they basically amount to what i said, i think
<Makyo> frankban, Hey
<gary_poster> then if you expand them out, you expand them *within* the services.  Am I missing something basic about what you are doing?  Should we have a call instead?
<benji> rogpeppe: thanks, that looks helpful
<frankban> Makyo: could you please branch lp:~frankban/juju-core/ann-doc/ and check all tests pass?
<Makyo> frankban, yep, on it.
<ahasenack> let's see, compute, quantum, dashboard, keystone, rabbit, ceph, cinder, glance, juju-gui, mysql, cloud-controller, swift-proxy, swift-storage
<gary_poster> ahasenack, ok cool, 13 is still in my rough mental model :-)
<ahasenack> :)
<ahasenack> juju-gui not strictly being openstack, I was just going over juju status
<gary_poster> ahasenack, ah, cool! so you have 13 services, using 29 machines using some distribution or other?
<frankban> Makyo: thanks
<gary_poster> I mean, a distribution so that compute nodes have 4 machines, and dashboard gets 1, and so on
<ahasenack> gary_poster: yes, most have more than one unit
<ahasenack> otherwise it wouldn't be fun, that's the power of juju
<ahasenack> I also have landscape-client on each unit as a subordinate
<gary_poster> ahasenack, cool, ok.   agreed.  13 services--ok, right, 14 with Landscape-- shouldn't be too bad to arrange at all.  We have something like that for our own demos.  If you arrange it before the demo it can even look pretty when the audience sees it. :-)
<ahasenack> :)
<gary_poster> thanks ahasenack.  so your work is done until Landscape engineers add the missing annotation, right?
<gary_poster> I mean the work for QAing this, of course :-)
<ahasenack> gary_poster: yes, in fact I have a workaround to try in landscape that someone just gave me, I'm about to try that
<gary_poster> ahasenack, excellent!
<ahasenack> gary_poster: thanks for the help
<gary_poster> ahasenack, np, thank you
<hatch> so our city had a massive watermain break Friday which caused the city to issue a 'boil water' warning - no big deal except that all of the coffee shops are shut down because the water in their machines is piped right in from the city water
<Makyo> frankban, Everything but uniter_tests.go passes.
<frankban> Makyo: could you please try the same in the master branch (most recent trunk)?
<Makyo> frankban, yep.
<frankban> Makyo: thanks again.
<hatch> w00t w00t - found the CI issue
 * hatch does the happy dance
<hatch> http://www.hblewett.com/blog/wp-content/uploads/2011/06/Snoopy-Happy-Dance.jpg
<frankban> hatch: cool! what was the problem?
<Makyo> frankban, same failures in trunk.
<frankban> Makyo: :-/ 8 failures?
<hatch> frankban: missing dependencies which would be auto resolved on our local machines
<hatch> ben and I are looking into the solution now
<Makyo> frankban, Yep.
<benji> rogpeppe: I have go version devel +43eb97ed849a but am still getting the standard terse import cycle error.  Is there a switch I have to throw to get more info?
<rogpeppe> benji: hmm. it might depend where in the import cycle you're compiling :-|
 * benji laughs an acidic laugh.
<rogpeppe> benji: beforehand i remember sometimes not being shown the cycle, but i can't remember when or why
<rogpeppe> benji: could you push your branch and i'll take a look?
<rogpeppe> benji: when i add the state import to api/params, i see this:
<rogpeppe> can't load package: package launchpad.net/juju-core/state/api/params
<rogpeppe> 	imports launchpad.net/juju-core/state
<rogpeppe> 	imports launchpad.net/juju-core/state/api/params: import cycle not allowed
<rogpeppe> benji: so i see where your problem is now
<frankban> Makyo: can you confirm tests in state/. pass?
<frankban> Makyo: (in the ann branch)
<rogpeppe> benji: ok, i have a solution for you
<Makyo> frankban, Yeah, they pass.
<frankban> ok, Makyo: maybe it's time for some pairing, let's use termbeamer, what's your jabber/gtalk account? could you add me please?
<frankban> Makyo: mine is frankban@gmail.com
<Makyo> frankban, drab.makyo@gmail.com
<rogpeppe> benji: suggestion: from the juju-core root: mkdir constraints; bzr mv state/constraints*.go constraints; fix everything in state to import the new package and use constraints.Constraints not state.Constraints.
<rogpeppe> benji: modification: as above, but rename Constraints to Value along the way.
<rogpeppe> benji: ping
<benji> rogpeppe: (I was eating lunch while you guys figured that out.) cool, thanks
<rogpeppe> benji: ah, i wondered
<rogpeppe> benji: np. does that seem reasonable?
<benji> rogpeppe: yep I think it's reasonable; if I find out otherwise I'll be sure to let you know ;)
<rogpeppe> benji: :-)
<hatch> jujugui if anyone has a moment for a 5 line diff review :) https://codereview.appspot.com/7621045/
<benji> hatch: I do
<hatch> thanks
<bac> gary_poster: http://stackoverflow.com/questions/14801416/zc-buildout-stopped-working-importerror-no-module-named-apport-fileutils  << this was the problem
<gary_poster> ack bac.  sorry it took time
<hatch> gary_poster: remember when I was saying guys can get huge air kiteboarding? This takes it to a whole other level http://www.youtube.com/watch?v=3JWi78hk8oQ :)
<gary_poster> hatch, :-) cool will look in a few
 * benji enjoys the very exciting thunderstorm going on here.
<ahasenack> gary_poster: the workaround worked, I see the relations drawn in the juju-gui "picture" now. I'll look for the landscape stuff now
<gary_poster> great ahasenack!  If you don't see "Landscape" logo in the bottom right then it's not showing up.  It's pretty obvious.
<ahasenack> gary_poster: I see it
<gary_poster> oh, great
<ahasenack> gary_poster: aren't the words reversed?
<ahasenack> gary_poster: I read "environment\nlandscape"
<gary_poster> ahasenack, not clear what you mean yet, sorry.  screenshot?  Or maybe the one Matt gave earlier could be used to make your point?
 * gary_poster has to go back to other computer to find the image
<ahasenack> gary_poster: I mean, I would say "Landscape Environment", not "Environment Landscape"
<gary_poster> ahasenack, Landscape is not the environment...I think I know what you mean (from memory; not looking atm).  That is the link to the environment information within landscape--the information about the environment that landscape knows about.  If you double click on a service (or single click -> "View") then you will see that show as "Service"
<gary_poster> ahasenack, this is good feedback for our design people though.  Would it be too much to ask for an email about the things that confused you?
<gary_poster> The "Landscape" text is just indicating that this is Landscape-specific information
<ahasenack> gary_poster: I know, it's a link to the juju environment in landscape
<gary_poster> hatch, that's pretty insane :-)
<hatch> Haha especially considering those kites are designed to fly lol
<gary_poster> hatch, not designed to, you mean,right?
<ahasenack> gary_poster: isn't it better to file a bug? It can be closed if they don't agree
<ahasenack> I do find that wording incorrect, though: "environment LANDSCAPE"
<ahasenack> makes no sense :)
<hatch> gary_poster: oh yeah, definitely -not-
<hatch> :)
<gary_poster> ahasenack, +1.  I would fill the bug out for you, but I don't understand the position yet--perhaps stared at this too much :-)
<gary_poster> so your explanation--why it seems obviously incorrect--would be valuable
<ahasenack> gary_poster: bottom-right corner: http://i.imagebanana.com/img/wq182eee/Selection_001.png
<gary_poster> cool ahasenack, right, thx.
<ahasenack> gary_poster: bug coming up
<gary_poster> great
<gary_poster> hatch did that IE fix make everything better, or just was incremental improvement?
<hatch> Ben is still working on the timeout bug but this should fix the IE bugs - I'm just about to trigger another build to test
<benji> rogpeppe: Moving the Constraint.Value methods won't work because they take state.State arguments, inducing a new import cycle.  Should I just move the data type only and leave the methods in the state package?
<rogpeppe> benji: looking
<rogpeppe> benji: i think those functions (create, read and writeConstraints) should remain in state, as they're directly to do with mongo interactions
<rogpeppe> benji: the Constraints type and its methods can (i think!) move ok
<benji> rogpeppe: makes sense, thanks
<rogpeppe> benji: in fact, everything from 'type constraintsDoc' onwards should remain in state
<benji> k
<hatch> bcsaller__: it looks like the sauce labs IE instance is caching stuff - this last run had the same issue we see if we don't clear IE's cache
<bcsaller__> hatch: I saw that on Thursday as well. It didn't make sense as it should be a new VM but they might go through a caching proxy 
<hatch> yep - well I'm going to grab some lunch and then I'll investigate this when I get back
<hatch> just wanted to let you know where it left off
<hatch> before I go - anyone know how to make a newline on the wiki?
<gary_poster> hatch, new lines, I think? :-)
<benji> the go import system leaves something to be desired; a name like "constraints.Value" makes sense for all packages except the one in which it is defined (where it is simply named "Value" which is somewhat informationless).
<benji> I guess that's the same problem that the Python import system has; I wonder why I don't remember tripping over it there; different naming conventions perhaps?
<hatch> gary_poster: hah I tried that, I ended up just putting a line between the other lines....double space :)
<rogpeppe> gary_poster: next branch here - in the next branch we'll actually hook it up to the API! https://codereview.appspot.com/7650048
<gary_poster> hatch, heh.  I
<gary_poster> 'll look at it if you want.
<gary_poster> rogpeppe, awesome!
<bac> guihelp: anyone have a moment for a review?  https://codereview.appspot.com/7871044
<hatch> Yep
<gary_poster> bac, on it
<Makyo> bac, On it.
<Makyo> Too late!
<gary_poster> :-)
<bac> wow!  such enthusiasm
<bac> i love that we had a bug where we try to beautify prettify.js
<gary_poster> :-)
<bac> or, better that prettify needs beautifying
<gary_poster> bac LGTM with trivial
<bac> thanks gary_poster
<gary_poster> benji did you get unblocked with circular import?
<benji> gary_poster: yep; I just had a 100% passing full test run; now I just have to write the code to do the actual thing the branch is supposed to do ;)
<gary_poster> benji, heh, cool-ish ;-)
<benji> I'm contemplating posting the branch as-is for review.  (The combination of cobzr and lbox make me shudder at the thought though.)
<gary_poster> :-)
<bac> hatch: i've got to pass a context, and since it isn't used we decided a week or so ago that null was a pretty good choice.
<bac> hatch: is there a better option?
<hatch> sorry - I meant to say, why do you need to pass a context at all
<hatch> why can't you just call the method?
<gary_poster> he's making a partial without making a closure
<bac> i'm using Y.bind to curry the values of the other params
<bac> yeah, that
<gary_poster> yeah, that
<hatch> oh ok then - could you comment as such? That's not a very common pattern so someone may come by and remove that in the future :)
<gary_poster> hatch, what's the way you would have done that?
<gary_poster> closure?
<hatch> yeah I would have done a closure - but I'm going to guess that this method does need to be called externally at some point?
<gary_poster> nope
<gary_poster> just trying to keep code divided up nicely
<gary_poster> you could still do that with a closure
<gary_poster> wrapping the other function
<gary_poster> this._send_rpc(..., function(data) {this.handleRemoveRelation(callback, endpoint_a, endpoint_b, data); })
<bac> hatch: that function is commented as: // Curry the endpoints.  No context is passed.
<hatch> damn
<bac> and, it is a common practice.  i did it 8 times in that one module.  :)
 * hatch bows his head in shame
<hatch> lol
<gary_poster> hatch, why?
<bac> gary_poster: are you proposing that change?
<gary_poster> bac, no.  you'd have to push the if in there too
<gary_poster> or something
<hatch> I read the comment and it didn't click :)
<gary_poster> oh :-)
<hatch> ok then just change the names to camelCase :P
<gary_poster> heh
<gary_poster> this is legacy support
<bac> hatch: as to the camel case, the existing call sites use endpoint_a and endpoint_b.  i'd rather not make the change and have a mismatch
<gary_poster> we need to do a mass remove_relation -> removerRelation
<gary_poster> removeRelation
<gary_poster> which we can do
<hatch> OK FINE!!!!
<hatch> :P
<gary_poster> but separately :-)
<bac> remove_relation -> destroyRelation
<hatch> lol
<gary_poster> heh
<hatch> I'll put LGTM on it
<hatch> :)
<gary_poster> :-)
<bac> destroy is the canonical name.  remove is an alias.
<gary_poster> sorry for weighing in.  I think I might be procrastinating.
<hatch> haha
<hatch> bcsaller__: ok now that all the tests pass in the CI it's all good but for some reason it's still timing out even though it hits 100% then just sits there
<hatch> I think we need a 'complete' flag or something
<bcsaller__> hatch: you're not seeing a request to login in the video? Thats why the timeout
<hatch> nope - it's just sitting here until the timeout hits
<hatch> gotcha - that's the part you were mentioning about earlier
<hatch> so is there anything else that I should be doing on this? Or is the rest in your wheelhouse?
<bcsaller__> hatch: I think I can handle the last step
<hatch> ok great - I'll finish up these CI docs then - lemme know if you want to bounce any ideas around
<hatch> jujugui I need one more review for the CI documentation https://codereview.appspot.com/7678048/ anyone have a few minutes?
 * gary_poster did first one :-)
<Makyo> hatch, sure.
 * BradCrittenden dang
<hatch> thanks
<Makyo> Hah!
<gary_poster> hatch, I'm going to try to give you a patch to hook up with docs, gimme a bit
<bac> interactive testing of the go api with firefox is a real pain...but very gratifying when it works
<gary_poster> hatch if you apply http://paste.ubuntu.com/5626260/ (in particular the docs/index.rst change) then you will be able to run make view-docs and go to the new doc from the (non-YUI) index page
<gary_poster> oops
 * benji wades through 2,154 lines of test runner output.
 * gary_poster , knowing benji, knows that this is not hyperbole
<hatch> gary_poster: sure I'll make these changes then run the make
 * bac dogwalk
<gary_poster> cool hatch.  The only point of running the make is to show you that it works generally, works specifically with your new file, and might be useful. :-)
 * benji wishes it were.
<benji> The whole "hey one of your tests failed, here is the unrelated output of everything that has ever been logged in the history of the universe; you're welcome" thing is not so great
<gary_poster> heh
<hatch> gary_poster: that worked well - the docs actually look pretty good *brushes shoulder like a boss*
<gary_poster> hatch, they do :-)
<hatch> haha
<hatch> ok changes have been pushed
#juju-gui 2013-03-19
<gary_poster> regression/stop the line: bug 1157138
<_mup_> Bug #1157138: deploying a new service does not update service name in environment view <juju-gui:Triaged> < https://launchpad.net/bugs/1157138 >
<gary_poster> jujugui ^^
 * benji attempts to duplicate
<BradCrittenden> benji, gary_poster: are y'all working on the regression?  can i help?
<benji> I'm looking at it independently at the moment.
<benji> I have a hypothesis that the updateGhostServiceName function which is wired up to a "blur" event (seems odd) isn't being called.
<benji> hypothesis denied!  It is being cvalled, it's just not effective for some reason
<teknico> bac, hi, has your juju-gui remove_relation branch landed?
<bac> teknico: yes, i believe so
<bac> that was my intent
<teknico> bac, I don't see the code in trunk though
<bac> teknico: me neither.  submitting again.
<gary_poster> benji thank you for looking at it
<gary_poster> benji did you try reverting to see what revision introduced it?
<benji> gary_poster: yep, trying that now
<gary_poster> cool benji
<bac> teknico: submitting now.  not sure what happened yesterday
<teknico> bac, great, thanks
<teknico> bac, while I'm pestering you, :-) are you also landing the destroy-relation juju-core branch?
<bac> teknico: i am trying desparately.  i'm in the review grinder.
<bac> teknico: soon, i hope
<teknico> bac, thanks (the interest comes from two branches of mine tailing your ones, and both are likely to conflict)
<bac> teknico: understood
<bac> teknico: my juju-gui branch is in trunk now
<gary_poster> benji, any luck on determining version with the problem?  do you want to pair?
<benji> it works in r387, does not work in r431
<gary_poster> benji, heh
<benji> re. pairing: sure; I hear the coffee machine finishing, let me grab a cup and we can hang out
<gary_poster> ok cool
<gary_poster> 400 is ok...
<gary_poster> 420 is ok
<benji> gary_poster: regular hangout?
<gary_poster> sure
<gary_poster> 415 not 420, sorry
<ahasenack> gary_poster: around?
<gary_poster> ahasenack, yes.  btw, I think we are going to produce mockups with your suggested approach and see which one people prefer
<gary_poster> s/prefer/understand better/
<ahasenack> ok :)
<ahasenack> gary_poster: the same happens when viewing a unit, btw, it say "unit LANDSCAPE"
<gary_poster> ahasenack, yes, as designed
<gary_poster> ahasenack, and that's what we would invert
<ahasenack> gary_poster: but anyway, here is something else. I'm visualizing a unit (screenshot: https://inst-005.virtual-maas.com/charms/charms//json)
<ahasenack> gary_poster: see that link to the charm? local:....?
<gary_poster> ahasenack, cannot access that screenshot :-/
<ahasenack> gary_poster: oh, sorry, I inverted things
<ahasenack> gary_poster: http://i.imagebanana.com/img/gco9lr5r/Selection_002.png screenshot
<ahasenack> gary_poster: see that link to the charm? local:....?
<gary_poster> ahasenack, yes
<ahasenack> gary_poster: that link points to https://inst-005.virtual-maas.com/charms/charms//json, which doesn't load, looks like something is wrong with it
<ahasenack> maybe because of the local:?
<gary_poster> ahasenack, maybe.  That charm page has been lame for some time.  Not Landscape specific.  Thank you for finding it.  Are you willing to file a bug or shall I?
<ahasenack> sure, I can file one
<ahasenack> gary_poster: and I have another question too
<ahasenack> let me prep another screenshot
<gary_poster> ahasenack, fwiw, that's not specific to local charms: http://uistage.jujucharms.com:8080/unit/memcached-0/
<ahasenack> gary_poster: ok
<ahasenack> gary_poster: so I clicked on "view all notifications"
<ahasenack> gary_poster: partial screen: http://i.imagebanana.com/img/u2t2fp6g/Selection_004.png
<ahasenack> gary_poster: why does it say "Problem with"? It looks ok
<gary_poster> lol ahasenack because we never look at this unless there are problems.  another bug!  thanks again
<ahasenack> I note there are two places in "juju status" where agent-state is mentioned: one in the list of machines (where "running" is good)
<ahasenack> and another in the list of services (where "started" is good)
<ahasenack> ok, I'll file it :)
<frankban> Makyo: our second branch (SetAnnotations) works, please ping me when you are available for an hangout
<bac> exciting discovery: lbox submit and propose send off draft comments you've entered into rietveld, avoiding the race of trying to do send them manually.
<hatch> has anyone taken the stopline bug yet?
<bac> teknico: my destroy-relation bug is now being submitted to juju-core
<bac> hatch: benji and gary_poster are looking at it
<hatch> ahh ok sounds good
<teknico> bac, great, thanks
<gary_poster> hatch, thanks.  we have a fix.  getting tests to pass
<hatch> if bzr has a bisect it 'should' be easy to find :)
<hatch> oh :)
<hatch> excellent
<hatch> jcsackett: are you here today?
<gary_poster> jujugui call  in 1
<gary_poster> review needed of https://codereview.appspot.com/7885045 <<< benji plus one more
<gary_poster> please :-)
<gary_poster> bcsaller_, starting without you
<rick_h_> gary_poster: will miss today
<gary_poster> ack rick_h_ 
<rogpeppe> gary_poster: you might want to try this branch - it actually hooks up the StateWatcher.
<rogpeppe> https://codereview.appspot.com/7663048
<gary_poster> wow
<rick_h_> hatch: when your call is done wonder if you can peek at something for me please
<hatch> definitely - I also wanted to have a quick chat with you about your paths
<hatch> for the charmstore stuff
<rick_h_> hatch: rgr, I actually want to have a bigger overall chat this afternoon once I'm done here at the dealer on things like a global regestry/etc
<hatch> ahh - what you doing at the dealer? busted car?
<rick_h_> regular 30 day service for the new thing. but yea...did bust a part/light after running a ditch due to some ice the other day as well. 
<rick_h_> nothing bad, but ugh
<gary_poster> https://codereview.appspot.com/7885045
<hatch> I can do it
<hatch> bcsaller_: so is there anything I can help with with the deploy test bug?
<Makyo> frankban, Oops, want to head back to hangout, or see-emily-code?
<bcsaller_> hatch: https://saucelabs.com/jobs/cf322461890c4645af4f3f05072a60b8 around 30 sec into the video it shows the issue
<frankban> Makyo: emily in 9?
<Makyo> frankban, Sure.
<hatch> ok loading
<bcsaller_> hatch: if you have any ideas I'm open, I was trying to figure out if the unit tests time out it could leave things in a state where it then needed the login on the next screen. I might try a run w/o the unit-tests on just to see if its any different.
<hatch> so it's not entering the proper creds?
<hatch> and why does this FF look so funny? It's like it's running in Windows 95 :D
<jcsackett> hatch: i am around, i'm about to be on a call. talk after that?
<bcsaller_> hatch: it shouldn't ask at all
<hatch> jcsackett: ok np, I was just going to say that I needed to add scrollview-base-ie to make your carousel stuff pass it's tests in IE - so I Just wanted to update you on that change
<jcsackett> hatch: ok. i'm working with TabView now; i'll check if we need similar things for that.
<hatch> bcsaller_: so viewing the chrome tests I see it doesn't ask in Chrome, only in FF?
<bcsaller_> hatch: that appears to be the case, there is now a different issue in Chrome showing up in the same test (which appears very similar to what we were seeing in IE (which I find oddly encouraging))
<hatch> oh jeeze - if you run on EC2 do they all pass?
<hatch> just wondering if it's maybe a canonistack issue
<hatch> not sure how it would be....
<hatch> but who knows
<hatch> rick_h_ so what did you need me to look at?
<rick_h_> hatch: nvm, got it. new Y.Node !== Y.Node.create :(
<rick_h_> out yesterday is giving me a case of the mondays
<hatch> ohh :)
<bcsaller_> hatch: haven't tried EC2 in a while
<hatch> rick_h_ will the charmstore stuff be under /bws as well?
<hatch> or is that just for these custom views?
<rick_h_> hatch: ok, so for the moment it's there to 'feature flag' the work in progress. 
<hatch> oh ok so at some point the bws will go
<hatch> ?
<rick_h_> hatch: I think at some point closer to release we'll chat on making sure urls are generated correctly and drop them
<hatch> gotcha
<rick_h_> hatch: rgr, from the looks of things it should be a simple one-day'er to drop/update those
<hatch> ok I'm working on the routing bug from the sprint and making up url stories
<rick_h_> and for now we want them hidden so keeping it around
<rick_h_> ah, well to help QA things we want them to work under bws/ I think
<rick_h_> but we can work on something else if that causes you more work/bugs on your end
<hatch> nope that's fine it's just a path
<hatch> but in making the stories it didn't make sense to keep them
<hatch> so I'm glad to see they will probably be going :)
<rick_h_> yea, add the "hide in progress work from people using the charm for production" story :)
<hatch> lol
<frankban> gary_poster: do you have a minute for a quick hangout?
<gary_poster> sure frankban 
<frankban> gary_poster: thanks, I am juju gui hangout
<frankban> *I am in the
<gary_poster> bcsaller_, hatch, whoa!  "Jenkins is back to normal" in some better universe where passing tests is normal!  yay! :-)
<bcsaller_> gary_poster: umm...
<hatch> lol - well the unit tests all pass
<bcsaller_> I can't make sense of this new world but I feel like I should enter some kind of lottery very soon
<hatch> hey Chromebooks will FINALLY be available in Canada
<hatch> bcsaller_: lol dooo it!
<hatch> bcsaller_: did we decide that /notifications/ should be under :gui: ?
<bcsaller_> hatch: I don't recall that, there are two views through, the persistent one on every page and the view all one. View All won't have other namespaces active if the design stays the same and the persistent view will call next() anyway
<hatch> alright and we decided that show_environment will be on *
<hatch> right?
<bcsaller_> hatch: there is some drift between the designs of today and tomorrow. If by * you just mean an open match at the end we can make a case for that, but its not present on pages like /service/x and /charm/x now
<hatch> hmm I updated chrome and now I get no console logs...
<frankban> hi rogpeppe: if you have time, could you please review https://codereview.appspot.com/7598043/ ?
<rogpeppe> frankban: looking
<frankban> rogpeppe: thanks
<hatch> bcsaller_: do you know where the event listener for the juju logo is?
<bcsaller_> hatch: think its just an <a/>
<hatch> oh woops so it is
<hatch> :)
<hatch> looks like it's still being captured by the app
<hatch> anyways...the issue with it is that it's supposed to drop back to 'root' but what IS root supposed to be :)
<hatch> I would say the environment
<hatch> but if you're on juju:8888/:gui:/service/memcached/ and click that button it stays there
<hatch> because it's not editing the namespaced paths
<bcsaller_> hatch: the navigate event handler would catch all the <a/>'s
<hatch> yeah - I'm just talking
<hatch> :)
<hatch> I think I'll create a route on / to show the environment view
<hatch> bcsaller_: I know you need a break from your CI stuff ;) Can you take a look at http://bazaar.launchpad.net/~hatch/juju-gui/ns-routing/revision/436 and let me know what you think of my approach
<bcsaller_> hatch: a welcome chance to do something else 
<hatch> feel free to tell me it's wrong ;) but then you better have a better way :P
<gary_poster> bcsaller_, figure out some way to wrap up what you have done and we'll do some kind of handoff to someone tomorrow
<gary_poster> someone may be me :-P we'll see
<gary_poster> bcsaller_, if "wrap up" means "we pair for a little bit and you show me what you've learned" so be it
<bcsaller_> gary_poster: I'll do one more round of tests and then we can talk if you have time
<gary_poster> bcsaller_, ok.  Would prefer to wait till tomorrow when hopefully I will be more rested.  Happy to let you have a break though.  If you have a small slack task in mind (including reading up on some at-least-slightly relevant technology :-) ), fine, or we can talk through something.
<bcsaller_> gary_poster: tomorrow is fine
<gary_poster> cool thanks
<hatch> bcsaller_: so what do you think?
<bcsaller_> hatch: we have code like that in check_credentials, so its already ok, I'd refactor to use the one call in both places for now
<bcsaller_> hatch: and I'd prefer using the url() method of router to build the url in service
<hatch> oh right - I agree
<hatch> and I'll look into the check credentials fn
<hatch> thanks
<rick_h_> hatch: got time for that chat now?
<hatch> yup, see u in guichat?
<rick_h_> hatch: yep
<rogpeppe> frankban: you have a review
<frankban> thanks rogpeppe!
<rogpeppe> frankban: np. i'll be really glad to see that branch land!
<rogpeppe> frankban: i'm off now
<rogpeppe> frankban: g'night
<gary_poster> night rogpeppe 
<frankban> rogpeppe: good night
<hatch> rick_h_: camelCase..... :P
 * hatch ducks
<rick_h_droid> yea I will. 
<rick_h_droid> that's cleanup work
<hatch> hmm and I can't see anything in your code that stands out as 'will break other code'
<rick_h_> yea, wtf...oh well keep poking it with a stick
<hatch> ok I'm going to take lunch, when I get back I'll revert my env back to 0.8.x and then run those tests again
<rick_h_> hatch: ok, in looking the exception is through the scrollview-paginator-debug. So I think maybe what's going on is I'm not cleaning up after myself in my tests that use a slider widget on it
<rick_h_> hatch: found it! thanks for taking a look that I wasn't insane.
<hatch> haha what was it?
<rick_h_> hatch: so the slider doesn't like not having any items in its list
<hatch> ohh, no it doesn't
<hatch> :)
<rick_h_> so in testing, it would die trying to scroll to with no first index item and cause issues
<hatch> woops
<rick_h_> since I gave it no data to test with 
<rick_h_> yea...will have to chat with jcsackett about seeing what we can do to make it 0-item safe
<rick_h_> pita for testing to know that you need to popular a widget buried in a view 
<rick_h_> popular/populate
<hatch> bcsaller_: the url method on _Router is only available in the parent app.js does the service view have a reference somewhere to that app?
<bcsaller_> hatch: no, we push deps down from the app, we don't just bind the top level object
<BradCrittenden> hi gary_poster, have a moment to talk about get_endpoints?
<gary_poster> sure bac
<bac> guichat?
<gary_poster> bac, yes it is free
<hatch> gary_poster: can I delete some tasks which no longer apply on the kanban?
<gary_poster> hatch, yes.  If they are linked to bugs please mark them is won't fix or invalid or fix released as appropriate
<hatch> sounds good
<gary_poster> *as
<hatch> rick_h_ do you want this ticket assigned to you or is it no longer required? https://bugs.launchpad.net/juju-gui/+bug/1130791
<_mup_> Bug #1130791: Add open/close api to Y.SubApp <juju-gui:Triaged by hatch> < https://launchpad.net/bugs/1130791 >
<rick_h_droid> hatch: I think no longer required 
<hatch> alright - I remember we chatted about it, but I wasn't sure if the api would still be required in general or not
 * bac -> dog walk, ship spotting
 * Makyo dogwalkinate.
<hatch> bcsaller_: in /service/:id you can click on the units, what handles that event? I can't seem to find it
<hatch> ugh
<hatch> I just did
<hatch> *facepalm*
<hatch> I Just ran into this issue with my namespace work https://bugs.launchpad.net/juju-gui/+bug/1157199
<_mup_> Bug #1157199: Invalid charm link when viewing a unit <juju-gui:New> < https://launchpad.net/bugs/1157199 >
<hatch> so I need to fix it first
<hatch> can someone who is running node 0.8.22 tell me which version of npm they are using?
<hatch> jujugui^
<hatch> node --version; npm --version
<bcsaller_> hatch: v0.8.22
<bcsaller_> 1.2.14
<hatch> thanks
<hatch> I just had some package issues when reverting so I wanted to make sure I picked versions that were working for others
<hatch> I am really starting to like tmux
<hatch> it's just so easy
<hatch> wrt bug #1157199 where is that link 'supposed' to go to?
<_mup_> Bug #1157199: Invalid charm link when viewing a unit <juju-gui:Triaged by hatch> < https://launchpad.net/bugs/1157199 >
<hatch> the code is attempting to pull the json from jujucharms which isn't allowing the CORS request
<bcsaller_> hatch: isn't it http://uistage.jujucharms.com:8080/charms/charms/precise/mediawiki-3/json/ being generated improperly?
<hatch> yes the url is wrong, and I've fixed that - but it requires the CORS request to go through properly but jujucharms.com is rejecting it
<bcsaller_> at the service level the charm link is generated properly and seems to work
<hatch> ok let me try again
<hatch> oh doh, I needed to regen the templates
<hatch> heh
<hatch> fixed
<hatch> :)
<hatch> If anyone wants some easy code reviewing before they head off for the day https://codereview.appspot.com/7546053/ 8ln diff :)
<hazmat> jujugui i'm going to modify the staging server to use an environment with a thousand units and increase the refresh cycle on it to 30m
<hatch> zomg!
<bac> hatch: ok
<bac> hatch: done
<hatch> thanks sir
<hatch> hazmat: I've always wondered, is this actually creating these instances or is it just a simulation?
<hazmat> hatch, simulator
<hazmat> hatch, otherwise gui dev would be alot more expensive ;-)
<hatch> haha understood
<hatch> is it even possible to run multiple instances on one machine?
<gary_poster> hazmat, sounds good
<hazmat> gary_poster, i'm trying it out right now.. still in progress.. it takes about 10m to create a set that large in the simulator.. 
<gary_poster> I bet
<hazmat> hatch, yes.. lxc or virtual-maas
<hazmat> hatch, or if you met multiple simulators yes.. that's possible to.
<hatch> cool - I could see that being helpful for people who want to setup a small blog with caching
<hatch> or simple webserver etc
<hazmat> gary_poster, re stage server.. its about 15m for the simulator.. to keep this scale present, it would need to divorce the gui updates from the content reset, continue the former every 15m, the later maybe 6hrs.. 
<hazmat> hmm.. maybe 20m
<hazmat> ugh.. maybe i should just give up the ghost on this..
<hatch> that would be pretty cool though
<hazmat> i got it working locally but didn't time the simulator all the way through
<hazmat> the gui was fast though
<hatch> at that level I'd be concerned about memory creep
<hatch> but that's for another time :)
<hazmat> aha.. its active..
<hazmat> http://uistage.jujucharms.com:8080/
<hatch> lol
<hatch> yeah don't leave that open too long ;)
<hatch> it's crashing my tab
<hatch> but it loaded the first time
<hatch> ok it doesn't crash if the inspector isn't open
<hatch> hazmat: is this for a demo?
<hazmat> hatch, no just trying to show the gui is usable at this size
<hazmat> for discussion
<hatch> ohh - well it's gone up 10MB since I opened it
<hatch> lol
<hatch> we have some work to do ;)\
<hazmat> although evidence of the opposite is also progress
<hatch> hmm there is some oddness here
<hazmat> hatch, i only show about 65k of mem usage
<hazmat> less than my gmail tabs
<hatch> the application seems rather stable in the heap shots but the realtime inspector is steadily increasing
<hatch> 65k? it's using ~12.4MB :)
<hazmat> interesting for me memory usage is decreased without active focus
<hazmat> down to 49k
<hazmat> hatch, which browser are you using?
<hatch> that's normal
<hatch> Chrome
<hatch> you can't use the system inspector to view the resource usage of tabs
<hatch> because it offloads things to different processes
<hatch> in the dev tools click the 'Profiles' tab
<hatch> then take heap snapshot
<hatch> that will give you the memory usage of the page
<hatch> then you can do things, and take another heap to see if it goes up
<hazmat> hatch, i'm using the chrome task mangaer
<hazmat> hatch, tools like profiles perturb the observed behavior
<hazmat> hatch, ie they account for a significant memory consumption by themselves
<hatch> task manager is showing me 141MB usage for the tab vs 12.4 in the heap snapshot :)
<hazmat> hatch, it would be nice to verify those numbers without any profiling
<hazmat> which can account for significant memory by itself
<hatch> bcsaller_: looks like my changes to the routing code has also fixed the history navigation issues we were seeing at the sprint
<bcsaller_> hatch: interesting, be nice to see what you had to change
<hatch> bcsaller_: I'm proposing it as a WIP soon
<hatch> hazmat: I've always used the heap snapshots in the past to monitor memory usage over an apps lifetime
<hatch> and it's served me well
<hazmat> ack
<hatch> it might not be 100% but it's at least consistent haha
<hazmat> hatch, we're seeing such *wildly* different numbers ... i went to look for causes
<hatch> when you took a heap snapshot did you not get ~12MB?
<hazmat> i do
<hatch> oh ok perfect then - I think the task manager takes into consideration the whole tab instance on the OS
<hatch> but as far as your 65K - I don't know about that, a photo is larger than 65K ;)
<hazmat> hmm.. maybe that's 65k *k
<hatch> oh maybe
<hatch> I'm in OSX also
<hazmat> but os process manager shows 121mb for the chrome in total
<hatch> so there might be some difference there
<hatch> oh ok so mine showed ~140MB so we are pretty close on that
<hatch> assuming that the task manager and process manager are close
<hatch> s/close/reporting the same thing
<hazmat> yeah.. that seems more reasonable
 * hazmat tries the staging site on a phone
<hatch> hehe I was just loading it on an N7
<hazmat> hatch, chrome or android browser?
 * hazmat is trying safari 6
<hatch> chrome
<hatch> it loads and displays the UI but it doesn't appear that I can click on anything
<hatch> yeah the SVG elements aren't triggering any of the events
<hatch> but the top navigation is functional
<hazmat> hatch, can you drag elements?
<hatch> the bottom navigation isnt' on the screen
<hatch> negative - but I can pan the environment
<hatch> oh wait
<hatch> two finger drag
<hatch> the elements
<hatch> but twofinger tap doesn't trigger the click
<hatch> bcsaller_: doesn't look like I'll be getting this branch proposed...the tests are failing and proving to be difficult to solve
<bcsaller_> hatch: I can still glance at the WIP if you want
<bcsaller_> just push and give me a link :) up to you
<hatch> https://code.launchpad.net/~hatch/juju-gui/ns-routing
<hatch> sure - I was going to propose so it would give you a proper diff
<hatch> unless you can somehow diff trunk easily in LP
<hatch> hazmat: looks like it needs a little work to get it working on mobile but shouldn't be too much
<hatch> how was it on safari?
<hazmat> hatch, not so hot... chrome a little bit better, never got to the rendered graph in either but gave up after 3m
<hatch> hmm - was that on an ipad?
<hatch> or iphone?
<hazmat> iphone5
<hatch> ahh - I'll try FF on my old android phone
<hatch> I don't have high hopes heh
<hazmat> i was demoing the normal staging gui on the phone earlier it worked reasonably well
<hazmat> rendered, drag, pan and zoom
<hatch> oh ok - so the proc/ram increase must have put it into limp mode
<hatch> ok FF on Android 2.2 works
<hatch> I can even get the popups
<hatch> actually it looks like I can do everything
<hatch> it appears to be working as a desktop browser
<hatch> it's even reasonably fast ui rendering
<hatch> but it gave me a 'script taking too long' error at first
<hazmat> k, downsizing to the 100unit env
<hazmat> and keeping 30m refresh/reset
<hatch> that's pretty cool how well it works at that level without any real work done to improve performance
<hazmat> interesting.. the heap delta from 1000k to 100 is from 11.8mb to 11.0-10.4mb (both fresh)
<hazmat> almost the same 11.8mb on one..
<hazmat> hatch, can you confirm re heap size on current uistage site
<hatch> sure one second
<hatch> 10.9MB on raw load
<hatch> so it looks like it's not the ram causing issues but the adding processing of 900 extra units
<hatch> that can be remedied however
#juju-gui 2013-03-20
<frankban> hi rogpeppe: I am fixing the branch, and I was thinking about the AuthName method you suggested.
<rogpeppe> frankban: ok
<frankban> rogpeppe: especially in relation to bug 1156715
<_mup_> Bug #1156715: Replace EntityName() with something else. <juju-core:Triaged> <juju-gui:Triaged> < https://launchpad.net/bugs/1156715 >
<rogpeppe> frankban: was it william's suggestion to report that bug?
<rogpeppe> (out of interest)
<frankban> rogpeppe: if we are going to replace EntityName with something better (e.g. GlobalName, APIName, ExternalName...), maybe it's worth making that change contextually
<rogpeppe> frankban: i'm not sure
<frankban> rogpeppe: I proposed to work on that once the annotations stuff is ready. IIRC, he suggested to find a better name for that method
<rogpeppe> frankban: the problem is that now we've got two methods now: State.Entity and State.Authenticator, and we can't just assume that the names are the same for each
<rogpeppe> frankban: ah, we've lost State.Entity, i see
<frankban> rogpeppe: you mean State.Annotator and State.Authenticator
<rogpeppe> frankban: yeah
<rogpeppe> frankban: the problem is that the same "get name" method isn't necessarily appropriate for both
<rogpeppe> fwereade: what are your thoughts here?
<rogpeppe> fwereade: i'm suggesting that entities that can be returned from State.Authenticator have an AuthName method; and (if needed) entities that can be returned by State.Annotator have an AnnotatorName method. both methods would simply return the entity name as it is currently. i *think* this is what you might have suggested before.
<fwereade> rogpeppe, +1
<fwereade> rogpeppe, I think it's better to have the two clear names for the two distinct contexts -- they can still directly share an implementation
<frankban> rogpeppe, fwereade: ok. in this branch the AnnotatorName is not defined or required. We just include the EntityName() method in ad-hoc interfaced for tests. No problem in introducing an AuthName for authenticators, and no problem in closing that bug as invalid or wontfix. Sound good?
<fwereade> frankban, I'd like to be consistent across Auth and Annotate, and ideally to drop the string EntityName across the board, but I'm not sure if that's a reasonable request in this context
<fwereade> frankban, are there lots of clients using EntityName that aren't clearly asking in either an auth or an annotate context?
<frankban> fwereade: I'd have to take a look, I don't think so, I guess EntityName is only used in the API context, and in the API we just have annotators and authenticators. Maybe rogpeppe can confirm.
<rogpeppe> fwereade, frankban: actually EntityName is used in other contexts too
<fwereade> frankban, hmm, I think it might be too big
<rogpeppe> fwereade: in particular, it's used in the original way that it was created (to talk about a state entity in general, that might be a unit or a machine)
<fwereade> frankban, rogpeppe: I think that if we're adding AuthName, though, I rather feel we should fix the instances of EntityName that are really AuthNames
<rogpeppe> fwereade: sure
<fwereade> rogpeppe, I may be changing my mind here
 * rogpeppe still thinks that a single EntityName method makes sense (and saves us code)
<fwereade> rogpeppe, I think your motivation is sane but the name "EntityName" is not helpful
<fwereade> rogpeppe, can we reconsider the list of possibly-sane alternatives?
<rogpeppe> fwereade: ok
<frankban> fwereade, rogpeppe: so, bug 1156715 is still valid
<_mup_> Bug #1156715: Replace EntityName() with something else. <juju-core:Triaged> <juju-gui:Triaged> < https://launchpad.net/bugs/1156715 >
<fwereade> rogpeppe, I am feeling a gentle pull towards GlobalName but this opinion is not held strongly
<rogpeppe> fwereade: i don't like GlobalName because it's not global - it's only "global" with respect to a given state.
<rogpeppe> fwereade: and in the future it's quite possible we might have *real* global (including uuid) names
<rogpeppe> fwereade: how about ExtName ?
<fwereade> rogpeppe, true; hmm. LongName? :)
<rogpeppe> fwereade: it's not too long, and abstract enough that it doesn't have any significant unwanted connotations
<rogpeppe> fwereade: TaggedName ?
<fwereade> rogpeppe, I could live with that :)
<rogpeppe> fwereade: not that keen on LongName, i don't think
<rogpeppe> nor on TaggedName really
<fwereade> rogpeppe, fair enough, but ExtName is too unclear IMO
<fwereade> rogpeppe, Nametag() :)
<rogpeppe> fwereade: it's only unclear if it's documented unclearly IMHO
<rogpeppe> fwereade: Tag() :-)
<fwereade> rogpeppe, hum, yeah, that's not bad, is it?
<rogpeppe> State.Authenticator(tag string) (Authenticator, error)
<fwereade> rogpeppe, we'll want to fix a couple of things like DeployerName to DeployerTag but I think it works nicely
<rogpeppe> fwereade: yeah, i could live with that
<rogpeppe> type Tagger interface {Tag() string}
<fwereade> rogpeppe, that SGTM, if you can live with it
<frankban> fwereade, rogpeppe: so, should the Tagger interface be embedded in Authenticator and Annotator?
<fwereade> frankban, yeah, it seems sensible I think
<rogpeppe> frankban: i don't think so, otherwise you won't be able to do interface { Authenticator; Annotator }
<fwereade> rogpeppe, oh, blast
<fwereade> rogpeppe, well
<frankban> rogpeppe: so TaggedAuthenticator, TaggedAnnotator?
<rogpeppe> fwereade: but i have no problem with type TaggedAnnotator interface { Tagger; Annotator}
<fwereade> rogpeppe, how often do we want both features in play at the same time?
<rogpeppe> fwereade: i don't want to preclude i
<rogpeppe> t
<fwereade> frankban, rogpeppe: ok, fair enough
<rogpeppe> fwereade: in general, other than at leaf level, you want either all-embedded or all-method interface types, i think.
<fwereade> rogpeppe, yeah, sounds sane, ++composability
<rogpeppe> fwereade: exactly
<frankban> rogpeppe: i.e. in the API layer, we will always use Tagged(Authenticator|Annotator)
<frankban> ?
<rogpeppe> frankban: yes, and i think that the State.Authenticator should return TaggedAuthenticator
<frankban> rogpeppe: cool
<frankban> rogpeppe: and the same for State.Annotator i guess
<rogpeppe> frankban: yup
<frankban> rogpeppe, fwereade: what do you think about: 1) I land my current branch as is, with minor fixes (it's well over 1000 lines of diff) 2) I change that bug to be this Tag() and Tagger refactoring 3) I start working on that new bug, also replacing all the NamedAuthenticators and Annotators used in tests
<fwereade> frankban, +1
<rogpeppe> frankban: i think that's a reasonable approach, except i'd like to see the entityName field go
<rogpeppe> frankban: and i think that's an easier fix than making the code access it safely.
<rogpeppe> frankban: (so it would use EntityName as i suggested in the review)
<rogpeppe> frankban: and then it would change to use Tag in the later branch
<frankban> rogpeppe: you mean in apiserver.go? so do you want me to temporarily add the EntityName to the Authenticator interface>
<rogpeppe> frankban: i think that would be fine
<frankban> rogpeppe, fwereade: thanks, I think we have a plan.
<rogpeppe> frankban: wonderful
<fwereade> frankban, sgtm
<frankban> rogpeppe: could you confirm those notes are correct? https://bugs.launchpad.net/juju-gui/+bug/1156715/comments/1
<_mup_> Bug #1156715: Replace EntityName() with something else. <juju-core:Triaged> <juju-gui:Triaged> < https://launchpad.net/bugs/1156715 >
<rogpeppe> frankban: yup, seems good. there are other knock on effects of changing EntityName - various places use it and will need to change
<frankban> rogpeppe: isn't enough s/EntityName/Tag for these cases?
<rogpeppe> frankban: more or less - there are some variable and field names that will want renaming too
<frankban> rogpeppe: maybe we'll need to take care of this case by case, with your help
<rogpeppe> frankban: it should be fairly obvious, i hope - recursive grep -i entityname, and fix
<frankban> rogpeppe: sounds good
<frankban> rogpeppe: reproposed, would you like to take another look?
<rogpeppe> frankban: will do
<frankban> thanks
<BradCrittenden> guihelp: in go, what is the relationship between packages and directories?  in apiserver there is "package apiserver" and "package apiserver_test" and that is a-ok.  if i add another package in that directory it complains.  anyone here know?
<gary_poster> I thought there was no connection, so obviously I'm no help
<BradCrittenden> gah, my stupid nick
<hazmat> bac, if your adding another test i suggest reusing apiserver_test
<hazmat> in general my understand is that its 1 to 1 directory containing src to pkg  with dirname == pkg at least by convention, and that splitting out tests basically allows for stripping it from the binary and is specially handled by the test runner conventions.
<bac> hazmat: i understand all of that from a hygiene perspective.  i'm trying to understand the rules.  it clearly isn't 1:1 so i'm confused why i cannot create a separate package, even if it is a bad idea.
<hazmat> bac i think <package>_test is handled distinctly
<hazmat> by the same convention that <name>_test.go is
<bac> ok
<hazmat> but that's guess work on my part.. 
<rogpeppe> teknico: did you run go test in your recent branch before submitting?
<rogpeppe> teknico: because it broke trunk and i'm can't see how the tests could ever have passed... :-)
<hazmat> rogpeppe, any comments on bac's question above re package naming
<jcsackett> hatch: what sort of thing should i be looking for if tests pass under test-debug but fail under test-prod in the beforeAll with an apparent dependencies problem?
<jcsackett> e.g. "extend failed; check dependencies."
<jcsackett> i can't find anything missing in a requires, nor in the yui.use
<rogpeppe> bac: hazmat is right. there can only be x and x_test in a given directory
<rick_h_> jcsackett: make sure you've pulled from trunk recently. 
<teknico> rogpeppe, I did run tests, and I plead guilty of insufficient scrutiny, because I did see failures that I interpreted as intermittent and unrelated
<jcsackett> rick_h_: just merged, no difference.
<teknico> rogpeppe, what's the overall tests status? are all of them supposed to pass all of the time, currently?
<rick_h_> jcsackett: make sure you make clean-all and rebuild as well. I guess it was a problem fixed on monday. 
<rogpeppe> teknico: yes
<rick_h_> jcsackett: and verify that tests pass on trunk if they still fail
<rogpeppe> teknico: but with your branch as submitted, it cannot have passed the tests even once :-)
<benji> the age-old story of untrusted tests; this is one of the reasons that tests need to be absolutely rock-solid
<rick_h_> jcsackett: I had a mess around tests like this yesterday I was going to bring up the on the stand up
<rogpeppe> teknico: if you see a test failure, we want to know about it!
<bac> thanks rogpeppe
<teknico> rogpeppe, right, I will make a point to let you know :-)
<teknico> (not about the failures in my code, though ;-) )
<teknico> or rather, in my changes
<rogpeppe> teknico: BTW ISTM that both opClientAddRelation and opClientDestroyRelation are bogus, because neither of them undo the operation that they've performed.
<teknico> rogpeppe, uhm. bac might be interested too ^^
<rogpeppe> teknico: i'm not sure when DestroyRelation came in. i should've been reviewing more branches, sorry!
<teknico> rogpeppe, very recently too
<bac> rogpeppe: oopsie
<bac> rogpeppe: that one had lots of eyes on it.  sorry you didn't get a chance to weigh in and catch that omission
<teknico> it'll teach me landing changes right before lunch, ttyl :-)
<rogpeppe> bac, teknico: in general, the func return from the op* functions is to reset the state back to the original. so if you make a successful change, you need to return a function to undo that change.
<rogpeppe> i know it's awkward, and it would be nicer just to reset the whole thing each time, but unfortunately that's prohibitively slow.
<teknico> rogpeppe, ISTR you mentioning that most op* functions could go away anyway
<jcsackett> rick_h_: ok, i'll deal with email till standup.
<rogpeppe> teknico: i discussed it with fwereade_ and he reckoned that it was worthwhile keeping them in
<teknico> rogpeppe, good to know, thanks
<hatch> jcsackett: get the problem fixed?
<jcsackett> hatch: not yet. i'm double checking that the right modules are in my require
<hatch> ok what you want to do is `make clean-all` `sh test-server.sh prod true`
<hatch> then if you have dependency issues they will show up right away in those tests
<hatch> frankban am I supposed to know what your email is about? Or did you sent it to the wrong person? :)
<frankban> hatch: what email?
<hatch> William and Roger agreed on using Tag().  ....
<frankban> hatch: that's a comment on a bug
<hatch> odd...it just came through as an email from you
<hatch> heh
<hatch> ok no problem :D
<hatch> bcsaller: did you end up checking out my branch last night?
<bcsaller> hatch: I did, but I haven't written anything up 
<hatch> oh ok - well we can chat in a hangout to save you the typing if you like
<bcsaller> hatch: the way you assign _nsRouter to juju isn't how we typically do things though, you'd pass that down as an attribute. Its ok to attach constructors to the namespaces but usually not instances
<hatch> Yeah I didn't like that either but that fn is being used in so many places that it's quite a lot of passing around for a single fn
<hatch> I was almost thinking that we need a Y.juju.utils object
<jcsackett> rick_h_: you see anything this file is missing for its require? http://bazaar.launchpad.net/~jcsackett/juju-gui/tab-widget/view/head:/app/widgets/tabview.js
<jcsackett> rick_h_: this is the testfile, as well: http://bazaar.launchpad.net/~jcsackett/juju-gui/tab-widget/view/head:/test/test_tabview.js
<hatch> jcsackett: does it actually say 'verrify dependencies' ?
<jcsackett> hatch: Error: extend failed, verify dependencies
<jcsackett> it's dying in the before() method in my test.
<hatch> ok that means the Y.Base failed because it can't extend Y.Tab
<hatch> Y.Base.create
<hatch> there is no 'tab' module
<jcsackett> hatch: i can't find any docs of where Y.Tab is defined--that's based on one blogpost i found about extending tab.
<jcsackett> what should i include?
<hatch> hmmmmmm
<jcsackett> cause i can't find anything; it would be nice if TabView had a require, but alas.
<hatch> ok I'm just getting to the tabview source
<hatch> you need base-build and tabview
<jcsackett> hatch: nope, same problem.
<hatch> hehe _callbackMaybe 'call me maybe' ;)
<jcsackett> hatch: that wasn't intentional, but once i realized the joke i became fond of the method. :-P
<hatch> ok and does this happen only in the tests?
<hatch> haha
<gary_poster> jujugui call in 2
<jcsackett> hatch: i only get this in test-prod
 * benji struggles with the Google Talk plugin again.
 * benji gives up and just reboots.
<hatch> ohh - whatabout make clean-all; make prod; ?
<gary_poster> rick_h_ starting without you
<rick_h_> gary_poster: k, sec
<hatch> jcsackett: the reason I'm hoping it happens with make prod is because then you can test to see if Y.Tab and Y.TabView are defined at the top of your closure
<jcsackett> hatch: i'm not seeing anything. that could be because the tabview's not wired into anything else though.
<hatch> hmm this sounds very odd
<rick_h_> hatch: do you have that nodejs bug handy from the npm issues?
<rick_h_> hatch: nvm, found it
<hatch> I tweeted it
<hatch> oh ok
<jcsackett> hatch: could Y.Tab simply not be exposed in a way that it can be extended?
<hatch> https://github.com/yui/yui3/blob/master/build/tabview/tabview-debug.js
<hatch> there is the source
<hatch> you'll see that it's exposed on Y.Tab
<jcsackett> well, i suppose if that were the case my tests would die in test-debug as well.
<hatch> ok here is what you can do
<hatch> remove your tabview code from the app, open up the network tab in debug mode and look to see what files are being requested from yahooapis.com
<hatch> then add it back in, and compare
<hatch> our yui dep script doesn't catch all deps I've found
<jcsackett> hatch: not sure what you mean by "open up the network tab in debug mode"
<hatch> network tab in chrome = app built with make devel
<hatch> s/=/0
<hatch> blah
<hatch> I can't type
<hatch> s/=/-
<hatch> :)
<hatch> basically you want to see if it's pulling in extra modules from yahooapis.com which it can't do under make prod
<jcsackett> ah, ok.
<hatch> FYI it pulls in some right now so you will need to compare
<jcsackett> that will work even though tabview isn't wired in, so opening the app doesn't create any tabviews?
<hatch> if it's in the 'use' then it'll pull in the code
<hatch> I'm also assuming that you have linted this code :)
<hatch> juuuuuuust to be sure ;)
<jcsackett> hatch: yeah.
<rick_h_> jcsackett: is the latest pushed?
<jcsackett> rick_h_: yes.
<rick_h_> I'll pull it down and try it out here localy
<rick_h_> jcsackett: so all tests pass for me. test-server and test-prod
<jcsackett> ...
<jcsackett> well, wtf.
<rick_h_> http://paste.mitechie.com/show/908/
<rick_h_> ^^ is from test-prod
<jcsackett> ima kill my branch and check it out again.
<rick_h_> jcsackett: yea, I just grabbed trunk, created a branch, merged yours in, and make test-prod 
<hatch> lol
<hatch> man I hate it when that happens
<jcsackett> this is maddening.
<jcsackett> a completely clean checkout of mine fails.
<jcsackett> evidently only on my machien.
<jcsackett> *machine
<jcsackett> welp, that's it. time to burn my computers and turn to a life of goatherding.
<jcsackett> :-P
<gary_poster> 2 review requested of https://codereview.appspot.com/7621048
<gary_poster> card is in high-priority maintenance review lane
<hatch> gary_poster: I'll take one
<gary_poster> ty
<hatch> while I'm doing that - is there a way I can flatten commits with bzr?
<Makyo> I'll take one.
<hatch> aka like a rebase with git
<gary_poster> hatch, rebase was frowned upon within bzr, because commits are hierarchical
<gary_poster> I think there's a way to do it but I've never done it
<hatch> ahh - I just did a number of small commits and looking at the branch now it's hard to tell what the diff is
<hatch> no biggy I guess :)
<gary_poster> hatch, instead you can simply branch trunk again, and then merge in your old branch
<hatch> oh that will do one commit?
<hatch> not merge all of the commits?
<gary_poster> hatch, that will give you what you want, while maintaining history hierarchically
<gary_poster> imagine a big commit, which, if you really look at it, can be subdivided into your old smaller commits
<jcsackett> rick_h_: any notion what might be busted that would let it pass for you not for me? surely YUI require doesn't vary b/c of an lxc...
<gary_poster> but the default view will be what you want
<hatch> ahh ok perfect thanks
<hatch> and a little OT - what
<hatch> 's a spike?
<hatch> you mention it in your branch
<gary_poster> hatch, XP term (as if we do XP): http://www.extremeprogramming.org/rules/spike.html .  Short translation: code that you write to figure something out and prove it works, and then expect to throw away
<rick_h_> jcsackett: not sure tbh. What's npm --version?
<jcsackett> 1.2.11
<hatch> gary_poster: ohh ok - I just call those prototypes ;)
<jcsackett> rick_h_: ^
<hatch> jcsackett: node version?
<rick_h_> jcsackett: yea, not sure. I'm .14 but as long as you're not newer you're ok
<rick_h_> there's a known issue with node 1.0 and the npm with it
<gary_poster> hatch, +1
<jcsackett> hatch: v0.8.20
<hatch> hehe
<rick_h_> jcsackett: but at this point, I cna't say since it doesn't break for me. Only thing I can think is to try a new lxc from scratch and if it works a diff directory v directory
<hatch> jcsackett: odd - after this review I'll also check it out to see
<jcsackett> hatch: ok. ping me with results. i'm going to go have some lunch.
<gary_poster> hatch, you'll be happy to know that I ran my tests on IE 10 as well :-)
<gary_poster> (and they passed)
<hatch> haha awesome
<hatch> jcsackett: good news - make test-prod fails for your branch here as well
<jcsackett> hatch: huh. so what's magical about rick_h_'s setup...
<hatch> he probably lied and ran make test-debug :P
<hatch> jcsackett: ok for some reason in your tests Y.Tab() isn't a constructor
<hatch> neither is TabView for that matter
<hatch> so you'll need to evaluate why there is no tabview on prod
<rick_h_> orly? I pasted my test results :P
<hatch> rick_h_ was that make test-prod?
<rick_h_> hatch: yea
<hatch> well how odd is that
<rick_h_> .zshhistory http://paste.mitechie.com/show/909/
<rick_h_> :)
<hatch> merge?
<rick_h_> yea, merged his changes into a local branch
<hatch> oh - well that's not a clean checkout then is it? ;)
<rick_h_> oh...well no...but it is test-prod with success
<hatch> lol
<hatch> ok diff those two branches and we might find the missing link
<rick_h_> which two? This is jcsackett's branch. 
<hatch> whatever your local branch was
<rick_h_> http://paste.mitechie.com/show/910/ here, that's more complete. It was just trunk
<hatch> ohh ok
<hatch> I'll try merging into trunk
<jcsackett> hatch, rick_h_: i did the same steps i see in rick_h_'s paste but no dice.
<hatch> jcsackett: also no luck here
<jcsackett> so rick_h_ is magical.
<hatch> for whatever reason it doesn't appear that the tabview files are being loaded into the prod rollup
<rick_h_> lol, YUI auto loads to my commands because I rule
<hatch> lol
<hatch> jcsackett: i'd try to manually include the tabview files in the rollup
<hatch> see if that solves the issue
<hatch> see the merge-files script
<jcsackett> hatch: ok.
<hatch> sorry I'm just trying to do this namespace routing stuff at the same time
<hatch> :)
<jcsackett> hatch: success!
<hatch> werd up!
<hatch> what was it?
<jcsackett> adding to merge-files
<jcsackett> manually pushing 'tabview' into reqs fixed it.
<hatch> ugh - that's the second time that script has failed us this week
<jcsackett> and as several other modules are in there, i think this is not the first time someone has encountered this.
<hatch> it's GOTA GO!
<hatch> jcsackett: how I got to that point was to ack Y.TabView in the rollup
<hatch> and when it wasn't found that was a big red flag
<jcsackett> hatch: dig. i'll remember that if i hit this again.
<jcsackett> hatch, rick_h_: can you fine folks take a look at https://codereview.appspot.com/7663050 when you have a moment and see what else might be wrong with this code? :-P
<rick_h_> jcsackett: what's wrong now? 
<rick_h_> jcsackett: or you just mean general review
<jcsackett> rick_h_: the latter. i was just being self-deprecating.
<jcsackett> which, admittedly, is misleading in this instance.
<rick_h_> jcsackett: heh, ok will peek in a minute
<rick_h_> jcsackett: yea, nothing to get down about. I spent half of yesterday debugging stuff just as well
<rick_h_> poor hatch gets brought into them with no hope :)
<jcsackett> rick_h_: not down at all. quite pleased in fact to have sorted it. :-)
<jcsackett> as long as i'm eventually getting stuff done, i'm happy/
<rick_h_> jcsackett: heh, and I think I see your issue. http://yuilibrary.com/yui/docs/tabview/
<rick_h_> you used a name already in the YUI namespace
<rick_h_> nvm, I guess it is 'browser-tabview'
<hatch> one of these days I'll have to look into that script
<hatch> to see why it misses things
<jcsackett> yeah, the file is the same, but the ns is different because our browser prefix.
<rick_h_> jcsackett: right
<hatch> review done
<hatch> now if I can get back to MY OWN WORK!!
<hatch> :P
<hatch> lol
<benji> "16 conflicts encountered."  This branch may never end.  I always thought my life's work would be something more substantial than adding a single command to an API.
<rogpeppe> gary_poster: ping
<gary_poster> hey rogpeppe 
<hatch> benji: lol
<benji> :)
<rogpeppe> gary_poster: so... the most significant allWatcher branch has just landed.
<rogpeppe> gary_poster: and you *might* be able to see something actually working
<rogpeppe> gary_poster: i wondered if you wanted a chat about where we want to go from here
<gary_poster> rogpeppe, I saw the one earlier today that had the machinery.  now we have the one that actually hooks it up too?
<rogpeppe> gary_poster: yup
<gary_poster> awesome!
<benji> yay!
<rogpeppe> gary_poster: i'll believe it when i see the black triangle :-)
<gary_poster> rogpeppe, sure, we can chat.  http://tinyurl.com/guichat
<rogpeppe> gary_poster: i'm there...
<rick_h_> jcsackett: review heading your way. I think there might be some more to clear up though on the way it works
<rick_h_> honestly, now that I look closely I think a tabview that allows vertical was all we need. 
<rick_h_> jcsackett: sec, heading home from coffee shop and we can do a hangout in 10
<hatch> bcsaller: is the best way to get data into topology/service.js to pass the options in via the addModule() call in views/environment.js ?
<bcsaller> hatch: we typically pass data to the env view and then from that to the topology. All modules will have access to their topology.
<hatch> gotcha
<hatch> damn you dependency injection
<hatch> global variables for everyone!
<gary_poster> benji, quick call in guichat?
<gary_poster> benji, re https://code.launchpad.net/~gary/juju-gui/megawatcher
<gary_poster> you are probably lunching, as I should be
<hatch> lunch smunch
<gary_poster> :-)
<hatch> bcsaller: ok I pushed my changes to use dep injection, now I'm still trying to track down why this test is failing
<hatch> I REALLY wish mocha would stop squashing console.log
<bcsaller> hatch: mocha or the console handler in app? on a prod build the console is off by default
<bcsaller> mocha shouldn't touch it
<gary_poster> hatch, we have a fake console now...I bet we could make the tests turn off the console (i.e., switch to the no-op console) if we are running in mocha
<gary_poster> that way we can log whatever we want
<hatch> bcsaller: well when you run sh test-server.sh debug true no console.logs() are output to the console
<hatch> gary_poster: ahh
<gary_poster> sounds like you are encountering a different issue than what I thought you were talking about though...maybe related
<hatch> when you run the tests in the browser do you get any logs in the devtools?
<gary_poster> I think so.  looking (I usually use breakpoints instead)
<hatch> odd - debugger; also doesn't trigger it to stop
<hatch> for me
<gary_poster> hatch I have lots of "loader: has Skin?" things
<gary_poster> that's it
<hatch> yeah I don't even get those in the tests
<hatch> wierd!!!
<gary_poster> huh, weird
<hatch> weird even
<hatch> :P
<gary_poster> Maybe we turn our fake console on?  Looking...
<gary_poster> hatch, our console manager is set to noop for our tests somewhere...finding where
<gary_poster> hatch, heh
<gary_poster> I see why
<gary_poster> we are running app tests
<gary_poster> the app, when instantiated, defaults to turning the console off
<gary_poster> unless you explicitly tell it to turn on
<gary_poster> so hatch, the easy small solution is, in your test that you want to see console output in, call consoleManager.native()
<gary_poster> (consoleManager is stuffed on window)
<hatch> oh :) awesome thanks
<gary_poster> to fix this generally...we'd have to do something in app to be more conditional about this somehow
<gary_poster> we could set a global flag in the test file, for instance, and have app look for that
<gary_poster> but anyway, that will get you going for now
<hatch> yeah thanks - I just fixed the bug - but that will definitely speed me up :)
<gary_poster> cool
<hatch> well I fixed A bug :)
<gary_poster> hatch if you want to contemplate better ideas, app/view/utils has the consoleManager and app.js uses it (just search for it)
<hatch> sure I'll take a look at it
<hatch> oy....102 failures
<hatch> ok apparently a number of tests rely on routing
<hatch> who knew!!
<benji> gary_poster: hey, was lunching; call now?
<gary_poster> benji, sure
<benji> gary_poster: ahhhhh! Hangout problems; one minute
<gary_poster> np
 * benji reboots.
 * benji plays IT Crowd to get into the mood for "turning it off and on again"
<hatch> haha oh the IT Crowd
<hatch> boo yeah tests pass
<hatch> Could anyone familiar with the namespace routing code review https://codereview.appspot.com/7719052 please :) Thanks in advance
<hatch> I'd also be intersted in a quick QA if possible
<Makyo> Taking a look.
<hatch> thanks
<hatch> rick_h_ this latest branch will allow the url state to be maintained across the charmstore and gui however you'll notice that your views are now pushed offscreen
<hatch> so that's just a markup/css issue to fix on your end once this lands
<hatch> just FYI
<rick_h_> hatch: ok, thanks for the heads up
<gary_poster> hatch I gave code review.  About to try it, then will hopefully give a final stamp of approval
<hatch> thanks - I was using the _ because that's how it was done elsewhere in the application
<hatch> if it's alright i'd like to land with it then change after - as it'll need to be changed elsewhere in the application
<gary_poster> hatch I know.  But if we are passing it around everywhere, it definitely is not "protected" any more.  change after: sure.  Next branch though, pls.
<hatch> yep will do
<hatch> which story should I put that ticket under?
<gary_poster> hatch, top
<gary_poster> hatch, qa problem:
<gary_poster> click on alerts
<gary_poster> then "View All Notifications"
<gary_poster> Takes you to http://localhost:8888/notifications/:gui:/service/haproxy/
<gary_poster> which does not work
<gary_poster> sorry bad repro instructions
<gary_poster> before all that, click on a unit or service
<hatch> yep I missed that one, good catch
<hatch> thanks
<gary_poster> hatch here's another one,  from unit page (e.g. http://localhost:8888/:gui:/unit/memcached-0/) click on relation link.  url goes to http://localhost:8888/:gui:/unit/memcached-0/mediawiki/relations/ and view shows environment (?!)
<gary_poster> hatch one more
<hatch> gary_poster: that's what it did before if I remember correctly
<hatch> I thought it was intentional
<hatch> do we have a relations view? :)
<gary_poster> from service page (e.g. http://localhost:8888/:gui:/service/memcached/relations/) click on relations tab and then click on a link (like to mediawiki)
<gary_poster> url changes to http://localhost:8888/service/mediawiki/:gui:/service/memcached/relations/
<gary_poster> and does not go anywhere at all
<gary_poster> hatch we do have a relations tab, see above :-)
<gary_poster> hatch, all of that behavior works properly in trunk/on uistage, so it is specific to your branch
<hatch> oh I see :)
<hatch> too....many.....links
<hatch> :)
<gary_poster> :-)
<gary_poster> hatch, logout does not work on your branch afaict: takes me to an empty page
<gary_poster> should take you to login
<gary_poster> works in trunk
 * hatch wonders if he got anything working properly
<hatch> ;)
<gary_poster> hatch, that's all I can find.  everything else is AOK
<gary_poster> lemme know when you have addressed those and I'm happy to re-QA hatch
<hatch> there is anything else? lol
<gary_poster> :-P
<hatch> nothing more frustrating than tests that only fail when they are run with the full suite
<benji> yep; inter-test state dependencies are a major pain
<hatch> yeah - the thing is that there shouldn't be any haha
<hatch> anyone remember who wrote the notifier widget?
<hatch> I'm trying to figure out why it's calling the notification view when there is no reference anywhere in the test or widget
<bac> guihelp: dumb question: how do you clone a map in go?  equivalent of python's newdict = dict(olddict)
<Makyo> hatch, bcsaller and frankban, I believe.
<bcsaller> hatch: my guess is its being subscribed in one of the app tests and then triggered later
<hazmat> bac, iter old and set into new
<bac> hazmat: oh.  painful.
<hazmat> its not too bad.. extra 3-4 lines.
<hatch> bcsaller: it LOOKS like it's being rendered because of some type of event listener?
<hatch> the traceback doesn't show much
<hatch> ahah
<hatch> that's exactly what's happening - now to find out where it's being instantiated at all
<hatch> which may pose to be a bigger issue as it's probably one of the other tests hah
<gary_poster> benji, yay on merge :-)
<benji> :)
<hatch> fixed!
<hatch> Friday card created
<hatch> lol
<hatch> gary_poster: fixed code should be up - however I coudln't reproduce your logout issue - if you could try it again and let me know if it's fixed that would be appreciated :)
<gary_poster> hatch, ok on it
<hatch> thanks
<gary_poster> hatch confirmed everything works now except logout.  I'm using make prod: you try that?
<gary_poster> I will try make devel now...
<hatch> yeah works on both - dumps me at the login screen
<gary_poster> hatch, duped on devel but I have more repro instructions: log out from inner page
<gary_poster> hatch, verified that logout works from inner page on uistage
<hatch> so an inner page like /:gui:/unit/memcached-0/ ?
<gary_poster> hatch yes
<gary_poster> hatch you are not seeing?  If so will kill cache 1 sec
<hatch> *closes as can't reproduce*
<hatch> ;)
<hatch> nope I honestly can't
<hatch> it works everywhere I try it
<gary_poster> hatch, just duped again after killing cache...
<gary_poster> hatch screenshare to make sure we are on same page?
<gary_poster> hatch, guichat
<hatch> sure
<hatch> gary_poster: it appears to be a linux issue
<hatch> I can reproduce it there
<hatch> well....linux chrome
<hatch> ok there is some combination of linux chrome and prod which is causing the blank screen (yay at least it can now be reproduced)
<hatch> on logout on prod it's destroying the application container
<hatch> so it doesn't have anything to render into
<gary_poster> glad you could dupe hatch
<hatch> yep I've tracked it down to a single line
<gary_poster> that sounds important for our audience
<hatch> app.js ln 703 this.loggingOut is never true
<gary_poster> huh
<hatch> exactly
<hatch> :)
<hatch> if you put a debugger; statement on line 699 of app.js you can see that the login screen is actually rendered - then after check_user_credentials is called about 4 times it's gone
<hatch> so that's how far I've gotten
<hatch> ok it doesn't look like that's the cause
<hatch> so yeah...
<hatch> ok this.env.getCredentials() is null
<gary_poster> it should be
<hatch> fixed
<hatch> I don't know WHY it broke but I fixed it
<gary_poster> heh, hatch, you want me to look at it and bless it so you can land this thing and run away?
<hatch> yup if you don't mind
<gary_poster> on it
<hatch> ok just lboxing now
<gary_poster> oh ok lemme know
<gary_poster> helping son with homework so in and out
<hatch> sure no problem
<hatch> annnnnd it's up
<gary_poster> ok trying
 * hatch crosses fingers
<gary_poster> hatch worked for me!  crazy that this new else block is necessary in this one case.  I will suggest that you comment it in the review, but otherwise LGTM.  Thank you!
<hatch> w0000000t!!
<hatch> that one took forever to track down
<hatch> glad that's done
<hatch> well in reality it was only 30 minutes - why did it feel longer than that
<hatch> lol
<hatch> in this debugging however I found a number of performance improvements we can do in the future
<gary_poster> hatch, cool, write em down in a card pls :-) .  Meanwhile LGTM.  Gave some trivial comments because wasn't quite sure why you opted for ../../ but probably good.  it certainly works, so I suggest you just leave it
<hatch> thank yas - well the place where those are located nested two deep from the parent context - I don't like it either but unless you know of a way to get the parent context I don't think we have any other option
<hatch> for the record, I didn't like doing that either :)
<hatch> I noticed you said / does that mean 'top context' ?
<hatch> blarg - ok, that 'fix' that I did breaks other things in the app
<hatch> wait no it didn't
<hatch> O K it's time to call it a day haha
#juju-gui 2013-03-21
<frankban> morning rogpeppe: could you please review https://codereview.appspot.com/7644043/ ?
<rogpeppe> frankban: will do, after i've finished the review i'm currently on
<frankban> thanks rogpeppe 
<rogpeppe> frankban: LGTM
<frankban> rogpeppe: great, thanks
<frankban> rogpeppe: I am trying to add retries to setAnnotations, in order to avoid possible race conditions. could you ping me when you have a minute?
<rogpeppe> frankban: now's good
<frankban> cool rogpeppe, thanks: this is a prototype, not sure if it makes sense: http://pastebin.ubuntu.com/5633877/
<rogpeppe> frankban: looking
<rogpeppe> frankban: that looks good, although i think i'd use a slightly higher iteration count
<rogpeppe> frankban: in fact, that makes me think
 * BradCrittenden reboots
<benji> man, lately my email has exceeded even the hights of the Launchpad firehose
<rogpeppe> frankban: maybe... we should never remove values
<rogpeppe> frankban: because removed values are the main thing that can cause contention here.
<rogpeppe> frankban: and, honestly, do we care about a little garbage left over from blank values?
<rogpeppe> frankban: what do you think?
<frankban> rogpeppe: contention can be caused also by DocMissing/DocExists interaction, right?
<rogpeppe> frankban: yes, but that automatically resolves itself after one iteration, because we don't remove the doc when it's empty AFAICS
<rogpeppe> frankban: but if two things are both trying to set an attribute, one to "x" and the other to "", they can iterate forever AFAICS
<rogpeppe> frankban: well, i may be exaggerating there - i haven't properly gone through it.
<frankban> rogpeppe: why do you expect them to iterate? doesn't the second just win?
<frankban> rogpeppe: i.e. isn't ErrAborted returned only if one of the assertions fail?
<rogpeppe> frankban: the point is that if we never remove an attribute, then there can *never* be more than two iterations, regardless of what anyone else is doing, AFAICS
<frankban> rogpeppe: confused, how to calculate the number of required iterations is the first of my questions, the second one being: how am I supposed to test contention. I supposed that, since both updates and removals assert the same thing (DocExist), they would never interact in a way that causes the transaction to abort.
<rogpeppe> frankban: currently we don't test contention anywhere. i'm not sure how to do so reliably, because it inherently relies on a race, but i think we should definitely think more about that
<rogpeppe> updates and removals *can* cause the transaction to abort
<rogpeppe> frankban: because removal removes the doc, and update is checking that the doc exists.
<frankban> rogpeppe: AFAICT removals removes key/value pairs from the doc, not the doc itself
<frankban> s/removes/remove
<rogpeppe> frankban: that's a bloody good point, and one i hadn't realised.
<rogpeppe> frankban: so... i think all's good
<frankban> rogpeppe: cool, so, about the number of retries, should I just decrease them to 2?
<rogpeppe> frankban: yes, i think so, and add a comment why that's the right number
<frankban> rogpeppe: cool, thanks
<rogpeppe> frankban: one thing occurs to me:
<rogpeppe> frankban: could you do the $set and the $unset within the same Op?
<rogpeppe> frankban: so it would look like: Update: D{{"$unset", toRemove}, {"$set", toUpdate}}
<frankban> rogpeppe: aha, good point, that way we always have a single op
<rogpeppe> frankban: yeah
<frankban> rogpeppe: and I can rename the helper function to setAnnotationsOp. I'll try this
<rogpeppe> frankban: yeah, sounds good
<rogpeppe> frankban: one other thing: i'm not sure quite what you're trying to do with hasAnnotations there. perhaps you could explain it?
<frankban> rogpeppe: eh, that was another question, I was reading the draft from William, and he wrote someting like "if mongodb is already in a state consistent with the transaction having already been run -- which is *always* possible -- you should return immediately without error."
<frankban> rogpeppe: I am thinking at the case when a client tries to set the same annotations simultaneously two times and the doc is missing
<rogpeppe> frankban: i think that'll just work.
<frankban> rogpeppe: yes, I agree, we write two times the same pairs in mongo and that just works. So, no need to avoid the second transaction?
<rogpeppe> frankban: yeah
<rogpeppe> frankban: i think there's no need for another round trip
<rogpeppe> frankban: if the transaction fails the first time, it can only be because the document does not exist, so we run it again, and then we know we're ok
<frankban> rogpeppe: ok, last thing: should we check that the entity still exists? if, e.g., a service is destroyed, we can have a race (the document no longer exists)
<rogpeppe> frankban: yes, i think so, for precisely that reason.
<rogpeppe> frankban: although...
<rogpeppe> frankban: i don't know if any harm will come if we don't check that
<rogpeppe> frankban: the only problem might come if a service is destroyed and then immediately recreated with the same name
<frankban> rogpeppe: in that case, it is possible that we update annotations on the new service, is it so bad?
<rogpeppe> frankban: well, if someone is constantly adding and removing a service with the same name, we could go more than 2 iterations around the loop...
<rogpeppe> frankban: i think that in the future, we'll hopefully move towards having a unique id for everything, so this issue will go way
<rogpeppe> s/way/away/
<frankban> rogpeppe: yes
<rogpeppe> frankban: i think let's not worry about it for now
<rogpeppe> frankban: though fwereade__ may well call us out on it :-)
<frankban> rogpeppe: ok
<rogpeppe> frankban: anyway, it's trivial to fix either way (increase iter count / add DocExists assertion)
<frankban> rogpeppe:  add DocExists assertion? 
<rogpeppe> frankban: currently there's a DocExists assertion for the $set/$unset ops. i'm not sure it's needed.
<rogpeppe> frankban: if you're changing annotations on a service which has been destroyed, i think it's fine to drop them on the ground.
<frankban> rogpeppe: I was thinking about: after two retries, if there's still an ErrAborted, we call Annotator(name) to check if the entity exists. If it exists, return ErrExcessiveContention, otherwise, return another error message
<rogpeppe> frankban: that sounds great.
<rogpeppe> frankban: except i'd probably use Count rather than calling Annotator
<frankban> rogpeppe: if this makes sense, then we still need  DocExists on updates/removals
<rogpeppe> frankban: yeah, true.
<rogpeppe> frankban: sounds good.
<frankban> rogpeppe: re Count, yes, better
<frankban> rogpeppe: and the custom error is something like "entity $entityname no longer exists"
<rogpeppe> frankban: yeah, or actually, just "$entityname no longer exists"
<rogpeppe> frankban: given that entity names are fairly self-describin
<rogpeppe> g
<frankban> rogpeppe: cool
 * frankban lunches
<benji> heh, "a runtime error occured in hr-self-service application"
<hatch> a runtime error heh - I haven't seen one of those in a long time
<gary_poster> jujugui call in 1
 * benji hopes the Google Talk plugin spirits smile upon him.
<gary_poster> rick_h_ starting
<hatch> hey rick_h_ I saw your tweet (at least I think it was you) I use an aeron char
<hatch> and I love it
<hatch> worth every penny
<rick_h_> goodspud: cool I see it on my calendar but don't recall seeing hte email. Is there anything I need to prep for it?
<rick_h_> hatch: cool, yea I think I'm settling on the ergohuman v2 but want it with the headrest as I'm told it's more useful than you'd think. 
<rick_h_> but looking for one to order still
<goodspud> rick_h_, we are wanting to understand what information you need from us to work on the "make it look pretty" side of things (match the visual design)
<hatch> ahh yeah the headrests can be nice
<goodspud> rick_h_, and the best format for that information
<hatch> gary_poster: so I'm going to do the _nsRouter ticket now but then I'm out of thinks on my list - anything specific you need completed or should I Just spin around in my chair and pick one at random? :)
<rick_h_> goodspud: ok cool. see you in 15 then
<gary_poster> hatch, spinning around in your chair until you induce nausea might be fun.
<hatch> best.....job.....ever!
<hatch> weeeeee
<gary_poster> lol. hatch, do you have any kind of tablet?
<hatch> N7
<gary_poster> hatch, maybe a good task for you would be to connect with Makyo about his old touch branch and see what you can do to (a) identify touch issues that need to be addressed, divided by technical issues and design issues; and (b) resolve some of the low hanging fruit.
<gary_poster> wdyt?
<hatch> sure thing - I checked it out the other day with hazmat and found some interesting things across platforms and browsers
<gary_poster> cool, hatch, thanks.  I have another task I can put you on next week, if you solve all problems and/or want to switch gears
<gary_poster> (it would be to contribute to the in-browser-memory juju stuff I've been starting, that you reviewed a branch of yesterday_)
<hatch> sounds good
<hazmat> hatch, another datapoint to add works fine on an ipad2/chrome.. current staging doesn't load for me on iphone5 (although it has in the past with more minimal content est)
<hazmat> set
<hatch> hazmat: interesting - especially considering ios chrome is just a wrapper around webview heh
<hazmat> indeed. though this is hardware delta iphone 5 vs ipad2.. 
<hatch> true - do you -ever- get script running to long errors on ios safari?
<hatch> I have never seen one
<gary_poster> I've never seen them
<hatch> so I was thinking maybe it's squashed and just kills it
<gary_poster> heh maybe so
<hatch> iunno this is just speculation :)
<hazmat> hatch, hmm.. actually it just loaded on the iphone5 after a reload (chrome).
<hazmat> but no.. never seen any error dialogs when it doesn't load
<hatch> and on my phone it gave me a script running too long error and asked if I wanted to continue - then loaded properly
<hatch> iunno just an idea
<hatch> will take some testing
<hatch> I have an iphone 3g which I can test on too if we want to support that far back
<gary_poster> tablet chrome is all we want atm.  hopefully more later.
<gary_poster> like second half of year kind of thing
<hatch> cool - tablet firefox works better right now ;)
<hatch> actually for the phone it does too
<gary_poster> hatch, interesting.
<hatch> I just found it funny because it worked better and was faster and gave a warning that it's not supported hehe
<gary_poster> :-)
<gary_poster> we can remove that warning for FF once CI tests are up, IMO
<hatch> yeah I'd agree - lately it looks like FF has been closer to the spec than chrome
<hatch> or maybe mozilla just has a better marketing department
<hatch> :D
<gary_poster> heh
<hatch> rick_h_ also if you come across any odd path/route issues plz let me know - I tried to account for all the typical use cases but it's entirely possible that i miss one
<rick_h_> hatch: rgr
<hatch> rick_h_ do you have any idea when you might have a subapp with multiple functional routes? I'd like to demo this namespace stuff but it doesn't really show it's coolness untill there are two functional apps. Do you think in a couple weeks?
<hatch> no rush or anything i'm just curious
<frankban> rogpeppe: hi, I have to handle this case: I have a function returning a txn.Op and an error. Sometimes, even without errors, there is no Op to be performed (so a zero value txn.Op is returned). The caller must check if it needs to run the Op. I see 4 possible solutions: 1) check that one field is not the zero value 2) the function returns a slice of operations (even if that slice will contain only zero or one ops)
<frankban>  and the caller check len(ops) 3) the function returns a *txn.Op and the caller check != nil 4) the function returns (op.txn.Op, required bool, error)
<rogpeppe> frankban: one other possibility: define var errNoOperationRequired = errors.New("no operation required") and check for that explicitly
<rogpeppe> frankban: when is there no op to be performed?
<rick_h_> hatch: well, I've got two views that 'render' right now and this branch I'm trying to get up today. 
<rick_h_> hatch: so in theory if I bind a click event you can swap between two views this week
<frankban> rogpeppe: aha! when the document is missing and the request contains only removals
<hatch> oh very cool - ok cool I'll make a note for next week
<rick_h_> gary_poster: is there a staging besides uistage that's got a more recent deploy of trunk? /me isn't sure how staging/etc is working.
<hatch> I want to demo it for the YUI Round Table
<rick_h_> hatch: hah, well....as I just showed goodspud "it ain't pretty" 
<hatch> oh haha
<gary_poster> rick_h_, uistage used to be updated every half hour from trunk.  checking.  otherwise, I or you can spin up a charm
<rogpeppe> frankban: i wonder if you could create the document in that case anyway (with an empty set of annotations)
<rick_h_> gary_poster: ah ok. Yea my url/route isn't working on it but it works locally. I figured it was just out of date. Maybe there's a bug I didn't know of in production then
<rogpeppe> frankban: then we preserve the invariant that if you call SetAnnotations, the document must exist afterwards.
<rick_h_> gary_poster: ah nvm, it's got hatch's changes so it's down below
<gary_poster> rick_h_, oh ok cool
<rick_h_> and mousewheel scrolling fooled me
<hatch> lol
<rick_h_> goodspud: so yea, you can see the stuff load under the environment at http://uistage.jujucharms.com:8080/bws/sidebar and http://uistage.jujucharms.com:8080/bws/fullscreen
<rick_h_> goodspud: it's just off the page
<frankban> rogpeppe: it's doable, but do we care about that invariant?
<rogpeppe> frankban: doesn't it make the code a little simpler? you then don't need to worry about returning no ops
<rogpeppe> frankban: and though strictly a little less efficient, i can't see that it matters.
<gary_poster> rick_h_, (it is every half hour still fwiw)
<rick_h_> gary_poster: thanks, yep ignore me. it's just working better than I thought :)
<gary_poster> :-) cool
<goodspud> rick_h_, cheers buddy
<frankban> rogpeppe: +1, it's achievable just removing an "if"
<rogpeppe> frankban: thought so
<frankban> rogpeppe: thanks. anyway, it's nice to know how to handle similar situations using a custom error
<rogpeppe> frankban: yeah, it's a useful technique
<hatch> if anyone has a few minutes to review https://codereview.appspot.com/7946043 trivial attribute namechange
<benji> hatch: I'll take a look.  Is there a card on the board I should tag?
<hatch> yup in the top row
<benji> done and done
<hatch> thank you!
<benji> I don't like the "LGTM" bit.  I need to write up an RFC that codifies +/- 1/0 then we can all file bugs when apps don't "comply with the standard".
<benji> heh, I just noticed that our board has a "Story 1" and a "Story A".  I approve.
<gary_poster> :-)
<hatch> inside joke?
<hatch> oooookk one more reviewer for https://codereview.appspot.com/7946043   going.....going.....
<Makyo> Gone.
<hatch> ^5
<Makyo> Need a micro-review or two (hatch did one, think it's an LGTM? Not sure) - https://codereview.appspot.com/7884044/
<hatch> yes sorry - I just didn't want to put LGTM if that was a typo
<Makyo> No worries.  Units just work a little differently.
<gary_poster> bcsaller_, new Jenkins failures are worse: they never get past "subprocess.CalledProcessError: Command '['juju', 'status', '--environment', 'juju-gui-testing', '--format', 'json']' returned non-zero exit "
<bcsaller_> gary_poster: yeah, its no longer even building an environment from shell on the machine, I've been looking into it
<gary_poster> ok thanks
<gary_poster> hatch give the man (==Makyo, on https://codereview.appspot.com/7884044/) a LGTM :-)
<gary_poster> (or not, if there's an issue)
<hatch> oops :) done
<hatch> hmm I don't think this current UI is going to work on a 7" tablet
<gary_poster> hatch, that goes in the "design issues" category then :-)
<rogpeppe> frankban: you have a revieew
<rogpeppe> review, even!
<hatch> :) ok so what I'll do is create a google doc with the issues for chrome and ff on this tablet
<hatch> then we can generate tasks from that
<gary_poster> cool hatch thanks
<frankban> rogpeppe: thanks, nice comment suggestion!
<rogpeppe> frankban: np
<rogpeppe> gary_poster: i've got the CL in review that adds annotations to the StateWatcher. you might want to have a look, as it defines the format you'll see on the wire. https://codereview.appspot.com/7948043
<gary_poster> ack, thanks rogpeppe.  benji ^^^
<gary_poster> rogpeppe, "arble":"" == deletion, I assume?
<rogpeppe> gary_poster: hmm, good point. that shouldn't be possible in practice - a bad test case.
<gary_poster> rogpeppe, cool.  So each annotation change always sends us all values, AIUI, right?  So we should replace any previous values, and so a deletion semantic is unnecessary.
<rogpeppe> gary_poster: yes
<gary_poster> cool
<gary_poster> LGTM rogpeppe thanks
<rogpeppe> gary_poster: thanks!
<rick_h_> hatch: I thought that only the defined ATTRS would be set from an initializer(cfg) but it looks like anything in cfg is getting an ATTR created for it?
<hatch> yep
<hatch> however - I consider it bad practice to not define the ATTR - else the code is referencing undocumented attributes
<rick_h_> hatch: ok, yea I just got through chasing down wtf views were getting their this.get('db') from and threw me for a loop
<hatch> sorry, bad practice to not define an ATTR that you're using
<hatch> yep I just dealt with the same thing....."where the heck is his attribute coming from" hehe
<rick_h_> all good, now that I realize they still work not being defined it'll be easier. 
<rick_h_> stop looking in this file, find the calling piont
<hatch> I have always had an issue with that because of the performance implications
<hatch> but whatever
<hatch> I belive as long asyou don't define a value it'll be lazily created
<hatch> I can't remember the exact sequence though
<rick_h_> yea, but I guess the assumption is normally you pass fewer iterations through cfg than exist on an object in ATTRS
<hatch> yeah - I have always had a small issue with it because all values passed to the initializer end up as attributes
<hatch> imho the initializer should split them off into attributes and properties
<rick_h_> ok, after I figured out self.db the notification thing is sweet. Nice and easy to way to get a popup like that. :)
<hatch> :)
<gary_poster> bcsaller_, frankban ^^^ :-)
<bcsaller_> :)
<frankban> cool
<hatch> 72km winds right now....I'd probably kill myself if I went kiting haha
<rick_h_> great, the rest of us have "what docs do you have in case you're hit by a bus" and for hatch it's "what docs have you left in case you fly a kite?"
<hatch> haha
<hatch> my kite is only rated to 40kph by the manufacturer - so I'm not even sure it would be able to be controlled :D
<rogpeppe> benji, gary_poster: here's a CL that adds a field to Service, by way of an introductory example of how to add more info to the AllWatcher: https://codereview.appspot.com/7950044/
<benji> cool
<benji> (the whole fancy spacing thing is irritating in diffs, especially when you can't control the whitespace sensitivty of the diff-producer)
<rogpeppe> benji: agreed. i would have been happy with no field alignment, but there y'go.
<rogpeppe> benji: turning off ws sensitivity is problematic for other reasons, unless you have a diff that's knows about lang specific quoting rules.
<rogpeppe> that brings me neatly to eod; g'night all
<benji> 'night rogpeppe 
<gary_poster> night
<hatch> Makyo: are you around?
<hatch> to talk about mobile
<Makyo> hatch, making lunch now. Will be around to type in a few, hangout after.  Unless you want to watch me eat noodles or something.
<hatch> haha it's ok I pmd you some lunch reading
<hatch> :)
<hatch> lemme know when you're done lunch, no rush
<Makyo> hatch, cool, thanks.
<Makyo> hatch, ping
<hatch> yo
<hatch> guichat?
<Makyo> hatch, yep, on my way.
<hatch> fyi all - it looks like node and npm have been updated to fix the error we were seeing
<bcsaller_> ahh, good
<hatch> so someone can update that...or I can later
<hatch> :)
<hatch> any idea which mailing list I should ask about which browser ubuntu phone uses?
<hatch> ubuntu tech?
<hatch> Online I am seeing showshoe and webkit
<hatch> although snowshoe IS webkit I think
<rick_h_> hatch: good ? I was wondering about the browser on there. I've ping'd aquarius about it but he's EU so might not hear back until tomorrow. 
<hatch> ahh ok - I can wait
<hatch> I am trying to figure out what sets the height of the environment
<hatch> bcsaller_: are we defining the height of the environment somewhere?
<bcsaller_> hatch: the viewport module handles that stuff
<hatch> ah hah
<hatch> of course the only one I haden't looked in yet
<hatch> :D
<rick_h_> hatch: so told you want to chat with osomon about the browser. 
<rick_h_> and let me know what you find out as I'm very curious :)
<hatch> sure thing - doesn't look like he is online right now
<rick_h_> hatch: yep, spain so have to catch tomorrow
<hatch> good news is that I have it so you can actually use most of the gui in FF already
<hatch> in horizontal view
<hatch> we aren't setup for vertical view
<rick_h_> yea, wouldn't expect it
<rick_h_> hatch: jcsackett https://codereview.appspot.com/7947045 for your consideration if you guys get time. Know it's late so maybe tomorrow. 
<hatch> yep I can do it now
<hatch> it's only 2:$4 here
<hatch> 2:44
<rick_h_> hatch: oh, well 2hrs ahead here so I'll be heading out soon :)
<hatch> does this need qa or just code review?
<rick_h_> hatch: I think just review. It doesn't effect anyone else. 
<hatch> alrighty
<rick_h_> hatch: if you QA it I need to check the status of the charmworld staging to make sure it's got the update for the ajax requests to pass
<hatch> it's alright
<hatch> :)
<rick_h_> which I will do tomorrow though. Next branch I'll wire up the button to swap between sidebar/full screen view and get that landed so it can be loaded with a button that does something :)
<hatch> kewl
<hatch> do you know when we should expect the yui responsive grid change?
<rick_h_> hatch: no...honestly had hoped to have it yesterday, then today, now hoping tomorrow. 
<hatch> alright no problem - was just making css changes for this mobile stuff so I'm not sure if they will still be there come the changeover :)
<rick_h_> yea, I'm going to guess it'll be a mess to merge. I imagine his branch is going to be lots of little edits all over
<rick_h_> hatch: https://code.launchpad.net/~huwshimi/juju-gui/replace-with-yui-grids looks like his branch pushed up yesterday
<rick_h_> for an idea
<hatch> oh cool I'll check that out
<jcsackett> rick_h_: i'm looking now as well.
<rick_h_> yea, always good to know you can go do http://code.lp.net/~username and see what branches they've got ;)
<rick_h_> thanks jcsackett 
<rick_h_> heh, actually the branch is smaller than I would have thought hatch 
<rick_h_> well I'm out. Have fun guys. 
<hatch> cya
<hatch> I think I'm going to write a plugin for the linter which doesn't allow my_var :P
<rick_h_> hatch: now careful, I happened to look at things in config-debug/prod and I see a bunch of my_var :P
<rick_h_> so look around before you knock it, I might be keeping with 'convention' for the thing at hand 
<hatch> I'm pretty sure the convention was changed to be camelCase
<hatch> to match javascript in the rest of the world :P
<hatch> so there is a lot of legacy my_var
<rick_h_> ok, just saying I did go through and look through my code to try to make it camelHappy... :P
<hatch> I think you missed a few files when you went through it :)
<rick_h_> hatch: ok, that's possible then as well ;)
<hatch> haha - don't worry I'm not going to write 'camelCase' at every instance
<hatch> just in the notes :P
<hatch> did you use writeOnce because it could be set multiple times by accident?
<hatch> or just as a precaution?
<rick_h_> hatch: no, honestly I don't think it's true of 99% of the attrs
<rick_h_> but it's on every single other attr so I added it along with it
<hatch> ok I'm pretty sure there is a performance hit setting them to writeOnce
<rick_h_> yea, I'm on board with wiping that off the face of the models tbh
<rick_h_> just noise 
<hatch> haha ok I'll make a note in the review
<hatch> I just wanted to ask first :)
<rick_h_> no, it's because the models are created from api data but there's no 'save' back to the store
<rick_h_> so none of those attributes from the model should be 'writable' but I think we can just ack it and move along vs writeOnce on each attr
<rick_h_> doh, I said I was gone...really am this time lol
<hatch> haha
<hatch> cya
<gary_poster> hatch and Makyo, or whomever is still around, https://codereview.appspot.com/7896045 is available for review.
<Makyo> gary_poster, on it.
<gary_poster> thank you very much Makyo 
<hatch> okee
<gary_poster> thank you
<hatch> there should be a warning at the end of that url
<hatch> lol
<hatch> gary_poster: have you ran these tests?
<gary_poster> hatch, yes, locally and in ie10
<hatch> and a follow-up does it have the new:gui: namespace stuff in this branch
<hatch> ?
<hatch> The init of the juju app now looks for an element in the index.html file which isn't there right now
<gary_poster> hatch, yes, the diff is from when I branched, which was from before your branch.  Did I add a test that will conflict with your changes?  I could merge trunk preemptively and check
<hatch> so this test should fail
<gary_poster> ah ok.  I'll merge trunk and look, thanks
<gary_poster> that will mess up the future diff but hopefully that is ok
<hatch> well
<hatch> I could give you the line to fix it
<gary_poster> sure, that would help!  thanks. :-) I'll still need to manually merge though
<hatch> http://bazaar.launchpad.net/~juju-gui/juju-gui/trunk/view/head:/test/test_notifications.js#L76
<hatch> yeah
<hatch> I don't really like this - this is going to happen every time we instantiate app now
<hatch> I'll create a ticket for me to find a better place to attach that listener in app.js which is causing the issue
<gary_poster> hatch, tests passed
<gary_poster> trying again with lots of refreshing...
<hatch> really...interesting
<hatch> http://bazaar.launchpad.net/~juju-gui/juju-gui/trunk/view/head:/app/app.js#L389
<hatch> that should cause it to fail without that element on the page
<gary_poster> agreed.  dunno.  will put a break point in test
<gary_poster> oh weird
<gary_poster> test fails in isolation but passes together.  Something is not isolated properly. :-/
<hatch> ahh darn
<hatch> my guess is that element is hanging around - I must have screwed up and forgot to destroy it after one of the previous tests
<gary_poster> welll...
<gary_poster> ah, hatch, yes
<gary_poster> and hatch, I could make it fail by changing line 389 to this.get('container').one('#nav-brand-env').on ...
<gary_poster> oh...
<gary_poster> but that is not supposed to be in the container is it
<gary_poster> back in a few
<hatch> nope it's outside of the container
<gary_poster> back
<hatch> So the purpose behind that event listener is to make sure that we capture any clicks to that logo so that we can display the environment view properly
<hatch> unfortunately that element is always on the page because it's in the index not in a template
<hatch> so maybe we could move it into a rendered template?
<hatch> and then it woudln't break our tests
<hatch> brb in 15
<gary_poster> we could also simply conditionally test for that element. <shrug>
<hatch> yeah we COULD do that
<gary_poster> hatch I'm removing the nav-brand-env after each test to see what passes then...
<gary_poster> ooh, bunches
<gary_poster> hatch, how do you want to resolve this?
<hatch> could you edit the app.js file to put a conditional around that event listener?
<hatch> that probably makes the most sense else every time we create a new instance of app we'll have to make sure that it's in the dom
<gary_poster> yeah, that's what I was gonig to try next.  Then I would rip out the test addition, because you don't seem to look at
<gary_poster> it in the test
<hatch> yeah sorry about that
<hatch> tonight I'm going to set up remote debugging for my tablet in hopes I can solve that click issue in the environment tomorrow
<gary_poster> awesome.  Then you can show me how to do that later :-)
<gary_poster> that change makes all tests pass
<hatch> haha can do!
#juju-gui 2013-03-22
<gary_poster> Making 1000 units is fun and easy in the in-memory GUI :-)
<gary_poster> Now I have 5000!
<gary_poster> It's big
<hatch> haha
 * hatch waits for it to crash
<gary_poster> :-) I was wondering about that.
<gary_poster> I'll try 10000
<gary_poster> still ok
<gary_poster> really big boxes
<hatch> lol
<gary_poster> I have a chromium browser process using 825.5 M.  Maybe that's it?  I'll make 30000...
<hatch> hahahaha
<gary_poster> no, it was the one using 400M, 556M now
<gary_poster> and that's a double database
<gary_poster> one for in-memory juju, one for the GUI side
<hatch> that's pretty good
<gary_poster> 46000 units total
<hatch> lol - I would be worried that the ws would be very bogged down trying to communicate that many changes
<gary_poster> yeah
<gary_poster> that's the bigger concern I think
<hatch> well and the svg rendering
<gary_poster> nah
<gary_poster> we're talking units not services
<gary_poster> I only have four services
<hatch> ohh ok
<gary_poster> the biggest use case we've heard of is about 14 services
<gary_poster> and we expect to nolonger support > 30
<gary_poster> s/nolonger/not/
<hatch> woah ...did you just edit that line?
<gary_poster> hatch how can I get your LGTM.  You want me to push, even with the merge, and point out what I changed?
 * hatch just entered the danger zone I think
<hatch> oh no I'll just add it
<gary_poster> hatch, that's your irc client.  It probably honors the vi style substitutions
<gary_poster> I said s/nolonger/not/
<gary_poster> and it did what I asked :-)
<hatch> hahaha wow
<gary_poster> but over the wire it is still as I sent it
<hatch> I thought I was going bonkers
<gary_poster> originally
<gary_poster> well, no guarantees for not going bonkers :-)
<hatch> haha so true
<hatch> chome devtools remote debugging is so cool
<rick_h_> hatch: agreed
<rick_h_> I need to set it up actually though still. 
<hatch> I messed around trying to solve these android bugs for a while this afternoon - found what caused it to fail in about 1min after setting that up
<hatch> haha
<hatch> no idea how to fix it yet
<hatch> but found the root cause :)
<rick_h_> lol, well knowing wtf is broken is half the battle :)
<rick_h_> I'm too tired to think straight but we should look at https://bugs.launchpad.net/juju-gui/+bug/1158613 first thing in the morning
<_mup_> Bug #1158613: timestamp handling is not TZ aware <juju-gui:Triaged> < https://launchpad.net/bugs/1158613 >
<rick_h_> poor huw in australia can't land a branch due to a bad test around timezone conversion lol
<hatch> ugh I spent months working on timezone aware date stuff and swore i'd never do it again
<hatch> apparently I didn't swear loud enough
<hatch> lol
<rick_h_> lol, then you never saw this ... 
 * hatch has been waiting impatiently for the reveil
<hatch> reveal even
<rick_h_> reveal?
<hatch> I was waiting for you to link to something
<hatch> :)
<rick_h_> the bug above?
<hatch> no some library that solved timezone issues in javascript
<rick_h_> oh no, just the bug comes about due to his browser/timezone saying the date is the 10th, but the test thinks it should be the 9th
<rick_h_> so he can never pass the tests
<rick_h_> and thus lbox denies him
<hatch> oh right - because the test doesn't specify timezone
<rick_h_> right
<rick_h_> so when it's not past bedtime I'll look I guess at what the code does vs the test does and see what needs to get updated
<rick_h_> just find it funny the poor guy can't land a branch because of his TZ
<rick_h_> or put it up for code review even
<hatch> lol see timezones-the-devil
<hatch> http://i10.photobucket.com/albums/a121/Elvislover01/Elvislover03/TheWaterboy.jpg
<frankban> morning fwereade__, thanks for your review
<fwereade__> frankban, heyhey
<fwereade__> frankban, helpful I hope?
<frankban> fwereade__: absolutely
<frankban> fwereade__: re "you'll need to be able to map from entity name back to collection/_id", can I assume coll/_id == entityName.split('-') and then coll += 's'?
<frankban> fwereade__: do we have that kind of convention?
<fwereade__> frankban, hmm, I'm not sure we do
<fwereade__> frankban, we *might*
<fwereade__> frankban, but it is not something I have thought about consciously
<frankban> fwereade__: it seems fragile, except if there is a strong convention in that sense
<fwereade__> frankban, indeed
<fwereade__> frankban, probably best to make it explicit
<frankban> fwereade__: are you thinking about two functions, probably living in state, e.g. makeEntityName(id, coll string) string and parseEntityName(name string) (string string error)?
<frankban> fwereade__: and maybe a map that maps collection names to entityName prefixes
<fwereade__> frankban, I think you only need the second function for now
<fwereade__> frankban, but, yeah, it probably deserves to be a top-level (but unexported) function in state
<frankban> fwereade__: ok. so that function will explicitly use a map[entityname-prefix]coll-name, right?
<fwereade__> frankban, implement it as it pleases you to do, I just care that it's in one place and explicit of purpose
<frankban> fwereade__: cool, thanks
<gary_poster> bcsaller, I'm ready to talk any time.  I have my vpn up and am staring mutely at the most recent failure
<gary_poster> but no rush at all :-)
<bcsaller> gary_poster: thats a good place to start :) I can join the chat in a second
<gary_poster> cool
<bcsaller> gary_poster: in chat when you're ready
<hatch> good morning
<rick_h_> hatch: morning, comments for you in the review. Let me know if anything doesn't make sense. :)
<hatch> okee
<hatch> rick_h_ thanks - what I meant about that check in the setter was if somehow it gets passed in "@#$%" it will still pass your check and then output NaN
<hatch> so the only thing it pretects from is empty strings
<hatch> protects
<hatch> and undefined I guess
<rick_h_> hatch: ah gotcha. I mean these are coming from a known source. I don't know it's worth going crazy on it. I guess I can run through Y.Lang.isString || Number ?
<hatch> well I would just dump the check all together - like you said, it's coming from a known source, and if it's ok if it has NaN/undefined as a value then it really doesn't matter
<rick_h_> hatch: cool
<hatch> hehe Url vs URL - that one has also always bugged me, I can't decide which one I like better - jcsackett
<hatch> :)
<rick_h_> I prefer lower because it starts to look too constant-y for my tastes, but it's a preference thing. Don't want to get hung up on it
<jcsackett> rick_h_: yeah, it's not a big deal. my english major side jumped out and said "that's an acronym!". feel free to ignore the english major side. :-P
<hatch> yay no more writeonce
<hatch> rick_h_ I didn't know about the linter causing issues on named methods like that
<hatch> thats...lame
<rick_h_> hatch: yea, I guess I can move the callbacks into methods on the class but seemed...unnecessary
<hatch> yeah I'm going to say that I THINK the preferred way is to specify a string for the fn name in the class to promote lazy loading the attributes
<hatch> but I'm not sure the specifics on that right now
<hatch> I mean, it doesn't apply at all in this situation
<hatch> :)
<hatch> gary_poster: wrt https://bugs.launchpad.net/juju-gui/+bug/1158613 would you prefer we build the string that it's supposed to look like in the test?
<_mup_> Bug #1158613: timestamp handling is not TZ aware <juju-gui:Triaged by hatch> < https://launchpad.net/bugs/1158613 >
<gary_poster> hatch, yes
<gary_poster> make sense to you, hatch?
<hatch> yep that makes the most sense if we want to display the date in their local timezone
<gary_poster> cool
<Makyo> jujugui call now?
<hatch> yup
<teknico> rogpeppe, any idea about these test errors in trunk? http://pastebin.ubuntu.com/5637181/
<rogpeppe> teknico: something to do with the recent stuff around version.Current, i think. you're running quantal, presumably?
<teknico> rogpeppe, yep
<rogpeppe> teknico: looks like it's been broken not that long ago. there's no test image data for quantal 386
<rogpeppe> teknico: this should be fixed very soon.
<teknico> rogpeppe, great, thanks
<bac> frankban: can you provide a reference in juju-core where your errors.New trick is used and checked?
<frankban> bac: my code changed so I didn't use that technique directly. however a quick search for errors.New gave me this example: ErrSilent in cmd/cmd.go
<hatch> gary_poster: you asked me to teach you how to do remote debugging - https://developers.google.com/chrome-developer-tools/docs/remote-debugging this does a better job than I caould :D
<hatch> could* damn I can't talk today
<gary_poster> hatch, ok awesome thanks :-)
<hatch> if you run into issues then maybe I can help debug but as far as a step by step guide goes it's pretty awesome
<bac> frankban: sorry, but my internet dropped out after i sent you that request.  if you posted something could you post it again?
<frankban> bac: my code changed so I didn't use that technique directly. however a quick search for errors.New gave me this example: ErrSilent in cmd/cmd.go
<bac> thanks frankban
<hatch> gary_poster what date format are we using? ISO 8601?
<hatch> YYYY-DD-MM
<hatch> er
<gary_poster> typically yyyy-mm-dd hatch
<hatch> YYYY-MM-DD
<gary_poster> y
<hatch> anyone looking for a break to do a small review? https://codereview.appspot.com/7722045/
<rick_h_> hatch: looking
<hatch> thanks
<hatch> one more?? bueller....bueller?
<gary_poster> looking hatch
<hatch> why thank you
<hazmat> wrt to the jenkins tests we should ideally execute juju with verbose options and stdout/stderr captured so we have  a bit more context than cmd failed
<hatch> oh believe me
<hatch> we've tried
<hatch> ;)
<hatch> jenkins is all like 'debug output? - NO!'
<hazmat> jenkins isn't the issue ..
<hazmat> its the way shelltoolbox is being used along with the cli args to juju
<hazmat> jenkins is clearly capturing the traceback from shelltoolbox.. but the underlying output isn't being sent back
<hatch> ohh
<benji> hatch: here is a diff that will remove the irritating message from the end of the gjslint output: http://paste.ubuntu.com/5637488/
<hatch> benji: awesome :)
<benji> (it also makes the file name line number messages nicer, I (and others I assume) have tools that interpret file locations like those)
<benji> it's a bit of a hack, but it should be good enough
<hazmat> added a card for capturing useful output on testing
<hatch> oh great
<teknico> benji, thank you :-)
<gary_poster> hatch LGTM with changes
 * gary_poster goes to eat something before calls
<hatch> thanks
<hatch> bcsaller: do you have some time today to give me a runthrough of how the d3 and yui events are set up?
<bcsaller> hatch: yeah, wanna say in 10 minutes in chat?
<hatch> sounds good to me
<hatch> I can't even get the popup to display by simulating the click right on the service because it's being prevented somewhere so a guide would REALLy help :D
<bcsaller> hatch: sounds like you have a call with gary now
<hatch> yup sorry :)
<Makyo> I'm at 1.5kloc diff and only a third done.  This branch is getting out of hand.
<hatch> lol
<hatch> bcsaller: ok all done, meet in guichat?
<bcsaller> hatch: heading there now
<rogpeppe> bac: ping
<bac> hi rogpeppe
<rogpeppe> bac: just looking at the GetEndpoints proposal
<bac> me too
<rogpeppe> bac: i'm just wondering why it's not just ServiceCharmInfo
<rogpeppe> bac: returning the same thing that CharmInfo does for each service
 * bac looks at CharmInfo
<rogpeppe> bac: essentially it looks like you're reconstructing almost all of the information within the charm metadata
<bac> rogpeppe: it is a subset and we want the ability to get for all services at once, rather than having to make multiple calls
<rogpeppe> bac: in fact... i'm wondering if something that simply returned the charm url for each requested service might be better.
<rogpeppe> bac: then you can call CharmInfo for each unique url found
<bac> rogpeppe: also, i read my task to be to implement the same functionality hazmat had made available in pyjuju
<rogpeppe> bac: i'm concerned that there's considerable overlapping of functionality here without much gain that i can see
<hazmat> this is the get_service method?
<bac> hazmat: get_endpoints
<rogpeppe> bac: if we had a ServiceInfo call that returned a []struct{Name string; CharmURL string; other possible service info}, then i think that would be useful and then CharmInfo remains the definitive place to find endpoint info
<rogpeppe> hazmat: perhaps you have a different perspective on why get_endpoints is useful though?
<benji> gary_poster: is my branch going to have massive conflicts with your in-memory environment branch?
<hazmat> rogpeppe, it was an optimization, to prevent the gui having to fetch every charm's info separately, instead just getting interface prov/requires by svc
<hazmat> in a single call
<hazmat> otherwise you end up with the gui having to do N + N round trips (get service info, get charm info)
<rogpeppe> hazmat: if we have many services sharing the same charm, it might be a false optimisation :-)
<rogpeppe> hazmat: i don't think so. if we allowed ServiceInfo to return many services, then i think only 2 round trips are required.
<gary_poster> benji don't know but mine landed
<hazmat> rogpeppe, that's not that common in general re many svcs using the same charm. possible though
<rogpeppe> hazmat: there's no problem with launching N API calls concurrently
<benji> gary_poster: oh, cool; in that case I've already merged it and didn't feel much pain  :)
<gary_poster> great
<rogpeppe> hazmat: although i suppose the js client interface might not have allowed for that possibility
<hazmat> rogpeppe, its not a question of feasibility but of latency till the info can be processed.
<hazmat> rogpeppe, it does
<hazmat> all commands are async to the gui
<hazmat> but i don't think there is a notion of launch N and wait till N has completed .. ie group deferred/promise
<rogpeppe> hazmat: it wouldn't be hard to do
<rogpeppe> hazmat: i'm not sure that two round trips is too bad, is it?
<hazmat> rogpeppe, you'll have to be a bit more explicit
<hazmat> rogpeppe, you saying a ServiceInfos method returning list of service infos and a CharmInfos method returning list of charm infos for a given set of charm urls?
<rogpeppe> hazmat: yes to the former, no to the latter
<hazmat> this info feeds into a gui endpoint solver which determines what the valid relations are for the env to allow for drag/drop relations with appropriate ui (disable invalid targest, etc)
<rogpeppe> hazmat: the former because it's good to be able to ask for all services. the latter because we don't want to enumerate all charms, and sending N CharmInfo calls at once should not be a problem.
<hazmat> rogpeppe, why the distinction?
<hazmat> ie what's wrong with CharmInfos([list-of-charm-urls])
<rogpeppe> hazmat: why bother?
<hazmat> but thats okay with ServiceInfos  returning a list?
<rogpeppe> hazmat: we need some way of finding out all the current services
<rogpeppe> hazmat: but i don't think we need a way to find out all charms in the State.
<hazmat> rogpeppe, it was parameterized.. not all in the state.. all in use by current services
<hazmat> but paramterized so the gui can just fetch those it doesn't hvae info for
<hazmat> the notion also grows more murky as you consider things like upgrades
<hazmat> you need the service watch to inform on charm changes
<rogpeppe> hazmat: yes, it will (and actually does currently)
<hazmat> cool
<rogpeppe> hazmat: that's why i see CharmInfo as more important than GetEndpoints
<rogpeppe> hazmat: it seems right that the GUI (as well as the state) keeps a notion of what charms it currently has information about
<rogpeppe> hazmat: and invokes CharmInfo for any it doesn't
<hazmat> that's seems okay.. bac the client side implementation can basically keep the same interface and internally fetch for what it doesn't have, invoking callback when complete.
<rogpeppe> hazmat: in fact, that's another reason why GetEndpoints isn't that useful - the AllWatcher will tell us about all current services
<hazmat> that's not its purpose..
<rogpeppe> hazmat: isn't that how the GUI finds out about everything to start with?
<hazmat> its purpose is to determine the endpoints when the allwatcher fires and the service set changes
<hazmat> rogpeppe, yes the gui uses the delta stream to populate. i was referencing the method being discussed.. get_endpoints
<bac> rogpeppe, hazmat: so, in juju-core GetEndpoints is thrown away.  do we then need new APIs to provide the required information or do those exist already?
<rogpeppe> hazmat: yes, so the service set changes - we see the new charm urls and fetch information for them, which gives us the endpoints associated with the services, no?
<rogpeppe> bac: i *think* you already have all you need
<hazmat> rogpeppe, yes, that's fine the gui client side go implementation can implement this ontop of the primitives
<hazmat> namely CharmInfo(charm_url)
<rogpeppe> hazmat: yup
<hazmat> bac, so effectively on get_endpoints in the go env impl client side.. you'll call CharmInfo(charm_url) for any services known that don't have charm info fetched, and then flatten that metadata back into provides:[interfaces], requires:[interfaces]
<hazmat> and then invoke the callback for the result, that should satisfy the interface for the valid endpoint solver.
<rogpeppe> bac: sorry to push back on this (and your implementation was fine!) but i do think that GetEndpoints isn't necessary, and i'd like to keep overall the surface area small if possible.
<bac> hazmat: what is the equivalent of get_endpoints() [no services specified]?  where will i get the list of services we're interested in?
<hazmat> bac, if none are spec'd its whatever are known to the gui
<bac> rogpeppe: makes sense.  wish we'd talked before the work was done
<bac> hazmat: yeah, ok
<hazmat> bac, ic the env impl doesn't have a client db handle to determine that? is that the concern?
<bac> hazmat: don't know yet.  not that familiar with it and will have to look
<rogpeppe> bac: yes, sorry. perhaps we should have a meeting about upcoming proposed API additions, so we can find issues like this earlier
<hazmat> bac you can walk up the parent tree of event targets... although explicit component lookup would be nicer.
<rogpeppe> bac: i'm really sorry; i know how frustrating it is!
<gary_poster> bac, I guess this is where you write the JS version and then we steal it for the in-browser-memory Python version too.  
 * rogpeppe has got to weekend time
<rogpeppe> g'night all
<bac> bye rogpeppe
<frankban> have a great weekend all
<hatch> Makyo: you mentioned yesterday that you implemented the two finger touch - mind pointing me to where that's done?
<hatch> I'm slowly making progress on this :)
<Makyo> hatch, D3 implements that.  Just a sec.
<hatch> oh alright
<Makyo> https://github.com/mbostock/d3/blob/master/src/behavior/drag.js 
<hatch> thanks
<hatch> OOOoo
 * hatch takes one step closer to a solution
<hatch> ok I found the problem
<hatch> unfortunately a sollution won't be ideal
<hatch> ok it looks like chrome android doesn't convert the touchstart to a click like firefox does - AND touchstart doesn't bubble on svg elements either
<hatch> so it's kind of like a double edged sword
<benji> I swear, firefox is a piece of crap
<hatch> firefox is doing it properly ;)
<hatch> THIS time
<hatch> lol
<benji> I was speaking apropos of my recent experiences.
<hatch> ahh - time for "works best in ..." images again
<hatch> haha
<hatch> Boo Yeah!
<hatch> got er fixed...it's ugly as sin though so I'll have to figure a better way haha
<hatch> bcsaller: is there a way I can go from the svg .service element and get the object instance associated with it?
<hatch> essentially I need to manually build the 'box' param in serviceClick
<bcsaller> hatch: chat?
<hatch> sure
 * bac -> early dog walk.  bbiab.
<hatch> ok going to take lunch
<hatch> bak
<hatch> sooo anyone have any big plans for the weekend?
<gary_poster> stop being sick, & actually sleep through the night
<hatch> pfft a full nights sleep is WAY overrated
<hatch> so close to getting this to work
<hatch> MOHOHOHAHAHAHAHA
 * hatch yells at chome android "AND STAY DOWN!"
<hatch> bcsaller: you kickin around still?
<hatch> jcsackett: is this branch ready for review?
<rick_h_droid> hatch how does 0.0.0.0 fail on your machine? 
<hatch> localhost points to the 'localhost' that I need not to 0.0.0.0
<rick_h_droid> right so local host reeves to 127.0.0.1 right? 
<hatch> nope, totally different internal ip
<rick_h_droid> and 0.0.0.0 will bind to all network addresses and work on 127.0.0.1 
<rick_h_droid> hmm and 0.0.0.0 doesn't bind to this address? 
<hatch> lemme see
<hatch> nope
<hatch> actually I'm not even sure what it's binding to
<hatch> I should look into that
<rick_h_droid> ugh what have you got set up :p
<hatch> I used to be a contractor - who knows what kind of setup I have screwed up here lol
<rick_h_droid> generally you use the 0s trick to bond both local and external addresses so you can test from remote machines like IE in  vm oe windows machine. 
<rick_h_droid> so jcsackett 's change was probably done to run tests from another machine. but it shouldn't break local host. 
<hatch> ahh I gotcha - yeah see I have localhost pointing to a specific local ip
<hatch> so if that gets changed to a real ip then it breaks
<rick_h_droid> hmm so normally changing local host can cause issues. surprised you've got it changed up. 
<rick_h_droid> but yea. it's intentional but usually not an issue so not done with any intent to change how things work. 
<hatch> yeah I figured it was committed by accident that's why I commented
<hatch> well and that it'll break the first time i use it haha
<hatch> but i should look into what's going on with 0.0.0.0
<rick_h_droid> very handy trick to  know 
<hatch> I was once working on three different apache/php based projects at once
<hatch> just imagine the headache setting THAT up
<hatch> ugh
<rick_h_droid> heh used to do php so I understand
<hatch> the best part about not doing php - is not having to deal with apache for that stuff
<hatch> being able to create your own server at whatever port you want is a huge plus
<hatch> so just so I get this right, you're saying that 0.0.0.0 should be pointing to any of the ip's that the machine thinks it has
<hatch> so 0.0.0.0 should be pointing to 127.0.0.1
<hatch> yeah I definitely broke something somewhere
<hatch> well you know what that means....time for a new computer....obviously!
#juju-gui 2014-03-17
<frankban> guihelp: I need one review/QA for https://codereview.appspot.com/75190044 (charm, not so much to review, mostly QA). thanks
 * frankban lunches
<frankban> oh hatch, morning
<hatch> morning!
<hatch> how are you?
<frankban> hatch: what do you think about pairing on juju-core stuff after my lunch?
<hatch> hmm
<hatch> one sec, I aven't actually started working yet :)
<hatch> rick_h_ did you happen to add in any time on the schedule for me to pair with frankban on some core stuff?
<hatch> frankban go for lunch, I'm sure we can work something out :)
<hatch> if not it's not a huge deal :)
<rick_h_> hatch: it's all good
<rick_h_> hatch: I didn't schedule but I think it's valuable and support it. 
<hatch> cool thanks
<hatch> https://www.kickstarter.com/projects/499144433/the-cardboard-standing-desk-stand-up-for-creativit
<frankban> rick_h_: cool, and great quickstart article!
<rick_h_> frankban: woot
<rick_h_> frankban: thank you sir for the great work. It's getting rave reviews around everwhere
<rick_h_> we'll be up on juju.ubuntu.com later today and there will be an insights blog post as well
<rick_h_> it's "big quickstart + bundle" announcement day!
<frankban> rick_h_: awesome, and, if new juju-core lands in trusty universe, we could also release quickstart 1.2
<rick_h_> frankban: yea, saw they got 1.17.5 out 
<rick_h_> frankban: so was going to bring that up
<frankban> rick_h_: cool, thanks
<jcastro> hey rick_h_
<rick_h_> jcastro: howdy
<jcastro> let me confirm bundle URLs before the press release goes out
<jcastro> juju quickstart bundle:~charmers/mondodb/cluster
<jcastro> with ~charmers removed over time
<rick_h_> jcastro: yea, once 1.17.5 hits we should have ~charmers gone this week
<jcastro> ok
<jcastro> so what URLs should we give people to link to from the announcement?
<rick_h_> jcastro: but yes, that's good
<jcastro> just the tab in the bundle?
<rick_h_> yea, we should include ~charmers. We're just not sync'd up
<jcastro> no worries, that's not a big deal
<rick_h_> oh, as far as for the jujucharms urls?
<rick_h_> jcastro: I mean quickstart is that url ^ and is good. 
<jcastro> yeah I would prefer they show the quickstart URLs I think
<rick_h_> jcastro: if you want to link them to the GUI and a bundle let me know which ones and I'll get you a short url. https://jujucharms.com/bundle/~charmers/mongodb/cluster/ for instance
<rick_h_> it's just the jujucharms.com/bundle/<quickstart url>
<jcastro> nice, and I am assuming ~charmers will go away from that too?
<rick_h_> jcastro: yes
<jcastro> rick_h_, ok, let me feature 2 more, what was the feature URL for bundles again?
<frankban> rick_h_, jcastro: yeah, FWIW, this will be the quickstart help for the new release: http://pastebin.ubuntu.com/7108268/
<rick_h_> jcastro: http://manage.jujucharms.com/bundle/mediawiki/single/featured/edit
<rick_h_> jcastro: note there's a lag in checking the box and them showing up. I think it's apache server cache stuff but should be ok after 20-30min
<jcastro> ack
<hatch> hey rick_h_  I had no luck with the other kernel, curious as to how you got that bug output so I can add mine to the ticket as well
<frankban> hatch: let me know when you want to start, no rush
<hatch> frankban: sure, I had to install bzr and now it's checking out the repo
<hatch> unfortunately my plans to be on Ubuntu this week have been foiled
<hatch> frankban https://plus.google.com/hangouts/_/76cpi8r5qpbciv15ulg0da6lj8?authuser=1&hl=en whenever
<jcastro> rick_h_, what was the TLDR on elasticsearch this weekend?
<Makyo> jujugui call in 10
<rick_h_> jcastro: IS brought up a staging environment that corrupted our production environment and the index needed to be rebuilt
<rick_h_> jcastro: that's the TL;DR version
<jcastro> oh ok so something caused it
<jcastro> it just didn't like, crash or something
<rick_h_> jcastro: yep, that's the thought at least. I can't prove it 100%
<rick_h_> jujugui http://insights.ubuntu.com/news/juju-bundles-and-quickstart-create-an-entire-cloud-environment-in-seconds/ for the announcement 
<Makyo> \o/
<rick_h_> jujugui call in 3 just added the hangout link. Not sure where it went. 
<benji> Makyo: how do we get to the hangout now?  The card doesn't have a "Video Conference" link and the tinyurl link leads to a "The Party's Over" page.
<benji> heh
<Makyo> benji, I have to open the event to see the link: https://plus.google.com/hangouts/_/canonical.com/daily-standup?authuser=1&hceid=cmljay5oYXJkaW5nQGNhbm9uaWNhbC5jb20.j0rk5d371ph8331ijtf48t2uj0
<jcastro> hey rick_h_
<jcastro> http://bazaar.launchpad.net/~ian-clark/charms/bundles/importio-to-elasticsearch/bundle/files
<jcastro> can you see if that bundle is not being ingested?
<jcastro> I bet it's erroring out
<rick_h_> jcastro: checking
<rick_h_> E: envExport/importio: Could not find charm for service.
<rick_h_> E: envExport: Invalid relation to charm: importio not found.
<rick_h_> jcastro: proof fails because the charm is not there. 
<rick_h_> it's a local charm, we don't support that in the store
<jcastro> ack
<bac> jujugui: robbie is running the pool again for the b'ball tournament.  get your picks in at http://ubun2.mayhem.cbssports.com  let's keep the trophy within Juju GUI again!
<hatch> I pick whoever is statistically most likely to win
<bac> hatch: there is a button for that
<hatch> lol
<hatch> I don't think I've ever watched more than 1/4 of a basketball game :)
<hatch> I need to step out real quick, be back in about 20
<jcastro> I will win
<jcastro> actually, I have a critical mistake where all my submissions are with MSU coming out on top
<rick_h_> lol
<jcastro> I have UM/MSU in the national championship game in one bracket
<jcastro> that's how far I am willing to go
<rick_h_> go blue!
<jcastro> you guys did awesome yesterday
<hatch> back
<bac> jcastro: i ditched loyalties this year and have UNC losing 2nd round.
<hatch> rick_h_ did you see the response on your kernel bug?
<rick_h_> hatch: yea, will have to find time to work through that process
<rick_h_> bac: ping when you get a sec. Trying to figure out why I've got no index in charmworld. This get_aliased thing isn't ringing with a lot of sense atm
<bac> hi rick_h_
<rick_h_> bac: oh howdy
<bac> chat?
<rick_h_> bac: can see if it's up
<rick_h_> bac: looks like still down
<bac> hangouts is down?
<rick_h_> I've got a call coming up. I can try to bug you later. Bad timing on my part. 
<rick_h_> bac: yes, email went out about it. 
<rick_h_> bac: yay call cancelled. Basically I'm getting this trace when trying to run charmworld? https://pastebin.canonical.com/106593/ seen anything like it? It's complaining that the real_index charms-55269 doesn't exist. Which I guess it doesn't? Not sure why it's doing that though. I thought it was just charms/
<bac> rick_h_: the aliased indices is really confusing.  but, no, i've never seen one not exist like that.
<bac> rick_h_: is the interview still on?
<rick_h_> bac: I'm hoping so. Hangouts is kind of required for that. Not sure what we'd fall back to
<rick_h_> bac: so if hangouts aren't operating I think we'll try to reschedule and send frankban a few cookies for putting up with us
<rick_h_> bac:  oh hmm, I've got no indicies after es-update. 
<benji> frankban: I am under the impression that the GUI charm's NRPE code (in scripts/charmsupport/) is from an external project; is that true?
 * benji realizes frankban is probably past his EOD.
<frankban> benji: I am here
<benji> ah, cool
<frankban> benji: yes, that sounds correct to me
<benji> thanks
<frankban> benji: https://bazaar.launchpad.net/~juju-gui-charmers/charms/precise/juju-gui/trunk/revision/74
<benji> cool, thanks
<bac> rick_h_: hangouts still down.  no-go on interview?
<rick_h_> bac: yea was just checking the stats dashboard. 
<rick_h_> bac: surprised they've had things down for multiple hours. 
<bac> t-30 is a good time to decide
<rick_h_> bac: I'll email and reschedule. Sorry. Just not going to be the same sans-hangout
<rick_h_> bac: +1
<bac> thanks
<rick_h_> frankban: bac Makyo so sent cancel email and will reschedule for later in the week
<rick_h_> frankban: sorry about that :/
<frankban> rick_h_: np, have a nice evening all!
<Makyo> Okay, sounds good!
<hatch> rick_h_ have a moment to go through my proposal? https://github.com/hatched/esm-docs/blob/master/esm-outline.md
<rick_h_> hatch: looking
<hatch> thanks
<rick_h_> hatch: not sure how to comment on this so just gonig to edit it and I guess we can diff it?
<hatch> oh hmm
<hatch> ohh
<rick_h_> hatch: not sure this is the best format for these things since you can't add comments/questions in line and such like a code review or doc
<hatch> rick_h_ I'll create a PR on the juju-gui project?
<hatch> I tried google docs but it doesn't do code formatting
<hatch> ok give me one min I'll create a new branch of the gui and add it to the docs
<rick_h_> hatch: I'll see how the editing goes. We'll figure something out
<hatch> ok so no pr?
<rick_h_> hatch: ideally we'd hangout and chat over it lol
<rick_h_> hatch: no, I don't think so
<hatch> lol
<hatch> ok np
<hatch> I could install Skype? lol
<rick_h_> I'm not willing to go that far lol
<hatch> hahaha
<rick_h_> hatch: crappy edit/update. Let me know what you think though.
<rick_h_> hatch: overall very nice but couple of questions and different opinions
<rick_h_> https://github.com/hatched/esm-docs/pull/1
<hatch> cool thanks will look
<hatch> hmm
<hatch> rick_h_ so personally I much prefer real function calls to doSomeCommand('commandName') type of syntax because it's far easier to grep and parse through without executing (we use this structure in the app in a couple places and I've had to run the app to get the possible `commandName` values to figure out how the code flows)
<rick_h_> hatch: oh, I've got hangouts if you want to try
<hatch> oh cool sure
<hatch> (sure, after I typed all that out) lol
<rick_h_> bwuhahaha https://plus.google.com/hangouts/_/72cpir00hj4j06la9mff158qnk?hl=en
<Makyo> jujugui looking for two reviews (for my sanity's sake) and a QA of https://github.com/juju/juju-gui/pull/181 hatch can you be at least one of the reviewers?
<rick_h_> Makyo: looking
<rick_h_> Makyo: lint errors for CI 
<Makyo> Oh for pete's sake.
<Makyo> On it.
<hatch> Makyo on it
<Makyo> I was just TOO EXCITED
<hatch> lol
<rick_h_> Makyo: lol
<rick_h_> hatch: will you do QA?
<hatch> I can
<rick_h_> hatch: ty sir :)
<hatch> Makyo what do you think of the inspector setup now that you have had a chance to use it?
<Makyo> hatch, after going down a very, very wrong path, I like it.  I got super frustrated with it, until I found my mistake.  I really like it, so much simpler
<hatch> :) what was the mistake? something I could have avoided?
<rick_h_> Makyo: what was the mistake? Something we should catch/error/hint?
<rick_h_> heh
<hatch> haha
<Makyo> Just kind of a listening problem on my end.  When you were talking about adding the RequestSeriesView to the LocalNewUpgradeView, I thought misunderstood, when you meant just add it to the views attribute.
<Makyo> 'thought' is an extra word, ignore it.  Ostracize it.
<rick_h_> ok, so one time learning thing then. 
<rick_h_> nothing to really catch/update 
<rick_h_> it sounds like?
<Makyo> It'd be nice to have some more documentation around that (and the potential problem of object values ordering) and how we support multiple views in there.
<Makyo> But I think that's an existing comment.
<rick_h_> Makyo: ok cool
<hatch> lnui
<hatch> lol
<hatch> I love it
<rick_h_> you guys hate me ;P
<hatch> sounds like a name from a JRPG
<hatch> hahaha
<Makyo> Hey, it was the logical next step from (the appropriately named) rsi
<hatch> hahahaha
<hatch> so much awsesome
<rick_h_> I keep reading that one was repetive stress injury
<rick_h_> I had to swallow so hard to :+1: that one
<Makyo> Hahaha
<hatch> hahaha
<Makyo> rick_h_, hatch with two +1s, can I land as is and do a follow-on for the missing view tests?
<hatch> Makyo sure - but you should probably fix that one which was a copy/paste fail
<hatch> :)
<hatch> I mean, it doesn't do any harm if you're going to do the follow-up right away I suppose
<Makyo> hatch, done, just about to push.
<rick_h_> Makyo: I'm kind of either way on it. I guess it's ok, but seems the missing tests are small now that you don't need the whole view tests I thought might be missing
<Makyo> rick_h_, sure, if you think those can wait for their own follow on, I can get just the test you mentioned in.
<rick_h_> Makyo: well, the one I mentioned hatch says exists elsewhere
<rick_h_> Makyo: so the only ones missing are the ones hatch mentioned
<rick_h_> maybe /me is confused now. 
<Makyo> I don't think it does.  I read hatch 's comment as "this isn't the job of this suite", but as far as I can tell, no such other suite exists.
<rick_h_> Makyo: ah ok. In that case then +1 on follow up
<rick_h_> Makyo: but -1 on skipping the render tests he references in his comment
<rick_h_> that's specific for this branch
<Makyo> Oh, yeah, those are what I'm getting ready to push.
<rick_h_> ok, ignore me than. Plan sounds good :)
<hatch> rick_h_ Makyo  it's the inspectors job to render it's views....it's not supposed to determine what views to show. That's done externally by telling another inspector subclass to render instead of this one
<rick_h_> hatch: rgr
<hatch> and no I'm not going to add that functionality into viewlet manager :P
<hatch> haha
 * hatch puts feets down
 * rick_h_ gets hatch a soapbox
<hatch> lol
 * hatch writes sublime plugin which bans him from opening viewletmanager.js
<Makyo> Yeah, not going to worry about that.  Just need to write the equivalent of test/test_request_series_view.js for local_new_upgrade
<rick_h_> BradCrittenden: you working on the remove_bundle feature with your head on it?
<BradCrittenden> rick_h_: yes, i am using my head
<hatch> sorry about that I'm not sure how that got missed
<Makyo> No biggie, just deciding on what's next.  Shouldn't take long.
<rick_h_> bac: :) sorry just moving my card in and making sure I'm not stomping on WIP limits
<bac> rick_h_: sorry i forgot to move it
<rick_h_> bac: all good thanks
<rick_h_> bac: did you get my PM re moving 1-1?
<bac> y
<bac> wait, no
<rick_h_> bac: k, let me know which works best for you
<bac> 9 am is good
 * hatch is going to add another file into assets/ don't tell benji
<rick_h_> k, thanks bac 
 * bac tattles to benji.
 * rick_h_ runs away for the day. where did the last 2hrs go?!
<hatch> intersting, bundles are now featured
<hatch> wow, I can't believe this works
 * hatch does a happy dance
<huwshimi> Morning
<hatch> holy sh*t
 * hatch taps on monitor
<hatch> (is this thing working)
<hatch> :P morning huwshimi 
<huwshimi> hatch: Hey!
<hatch> hows de bebe!
<hatch> and congrats :)
<huwshimi> hatch: Good thanks.
<hatch> lots has changed since you left :)
<huwshimi> hatch: Thankyou!
<huwshimi> hatch: Oh really!
<huwshimi> hatch: What's been happening?
<hatch> gary is gone, rick_h_  is now the all mighty overlord 
<hatch> machine view is almost ready to be implemented
<hatch> rick_h_ if you get a chance tonight let me know what you think of this first pass https://github.com/juju/juju-gui/pull/182
<huwshimi> Great, a crash already
<hatch> jujugui anyone interested in the queue for the deployer bar implementation feel free to check out that wip ^
<hatch> huwshimi lol
<huwshimi> OK, only 477 emails to read...
<hatch> haha nice
<huwshimi> hatch: And those are the ones that weren't auto archived...
<rick_h_> huwshimi: hey, I'll check in with you after the boy goes to bed in 2ish hrs?
<rick_h_> huwshimi: sound good?
<rick_h_> hatch: will do
<huwshimi> rick_h_: Sure!
<rick_h_> off to dinner for now, biab
<huwshimi> hatch: Did you break the tabs again?
<hatch> huwshimi haha, I'm not sure when that happened but I'm pretty confident I didn't do it this time :P
<hatch> sounds like a good task for you on your first day back lol
<huwshimi> hatch: Brilliant... thanks!
<huwshimi> hatch: Oh, they don't even animate anymore (just looking at Rick's commit)!
#juju-gui 2014-03-18
<hatch> I think that was to fix a bug of some sort
<hatch> sory I've been head down in other stuff for a couple weeks
<huwshimi> So they're not getting the transition events anymore to update the height...
<rick_h_> hatch: huwshimi yea was a browser issue
<huwshimi> rick_h_: Yeah, so the firefox, IE comment
<rick_h_> had to kill the animation in order to work in IE/FF properly
<hatch> ohh right now I remember - it was not stopping at the correct place
<rick_h_> yea, was a CSS animation issue that seemed browser bug related
<rick_h_> huwshimi: got time to hangout?
<huwshimi> rick_h_: Sure!
<rick_h_> huwshimi: https://plus.google.com/hangouts/_/lite/7ecpifrssat4mpruhen6751ibs?hl=en
<huwshimi> rick_h_: One sec, doing a little dance to get a webcam going
<rick_h_> huwshimi: rgr
<huwshimi> rick_h_: Oh, can you invite me with my canonical address?
<huwshimi> rick_h_: I think that's the problem...
<huwshimi> (unrelated to the webcam)
<rick_h_> https://plus.google.com/hangouts/_/7ecpijovag9m0l96n1f26f6vvk?authuser=1&hl=en
 * rick_h_ heads to bed...zzzzz
<rick_h_> frankban: in following some emails it seems the delay in 1.17.5 hitting trusty is that it has to build for the new archs 
<rick_h_> frankban: so longer delay in getting uploaded this release. 
<frankban> rick_h_: :-/ ok thanks for looking
<rick_h_> benji: or bac is there a good trick to launchpad auth lbox from an lxc? Did anyone find anything there?
<BradCrittenden> rick_h_: not sure about your question.  i've never used lbox w/in an lxc
<benji> rick_h_: most clients print the URL for you to navigate to yourself, does lbox not do that?
<rick_h_> benji: no, just get Go to your browser now and authorize access to Launchpad.
<rick_h_> Press [ENTER] after authorization is confirmed... 
<benji> that's poor form
<rick_h_> and I had hoped it'd show in the LP webui around auth'd apps as waiting but no luck
<benji> if the lxc shares a filesystem with the host you could run lbox there to do the auth and then stop it and restart in the lxc
<bac> rick_h_: ah, heck, i found a link about how to do lplib auth without a browser and gave it to matt the other day.
<rick_h_> yea it does share. Was avoiding installing lbox on the main system
<rick_h_> keeping everything in the lxc, but maybe that's a pipe dream
<bac> rick_h_: look at the echo example here https://help.launchpad.net/API/EndUserHints
<rick_h_> bac:  thanks looking
<rick_h_> ooh
<rick_h_> :( no luck 
 * frankban lunches
<rick_h_> benji: or bac can I get a charmworld review when you get time in LP while I wait to see if Makyo has any LP auth tips for lbox? https://code.launchpad.net/~rharding/charmworld/apply-cowboys/+merge/211517
<benji> rick_h_: I'll take a look
<bac> rick_h_: darn, i'd hoped that would work
<rick_h_> benji: ty much
<bac> rick_h_: you need just one?
<rick_h_> bac: yea, seems like a good idea
<rick_h_> bac: yea, just applying the cowboys from the weekend 
<rick_h_> bac: did get the min_score in ES to work out so nice we don't have to pull as much data down
<bac> rick_h_: so the 'min_score' is not just for ES 1.0?  the docs, as i read them, sure implied as much.
<rick_h_> bac: yes, it's not for just 1.0. I think the docs keeps pointing us there. As I mentioned, I saw it in the book I bought this weekend which was .20
<rick_h_> bac: it also has a flag to always output scores, even with a sort, so added that as well for future reference
<bac> yeah, i see that.  good on you for digging up those tweaks
<bac> rick_h_: as far as interactively playing with the queries, you can pass '&min_score=0.1' as query string
<rick_h_> bac: ah very cool then. Missed that
<rick_h_> that'll help instead of needing to add the &debug=true idea
 * rick_h_ heads back to the office from the coffee shop
<frankban> rogpeppe: when you have time, could you please take a look at https://codereview.appspot.com/77420043 ? thanks
<rogpeppe> will do
<hatch__> jcastro are you aware of anyone working on a promoted nginx charm?
<hatch> jujugui call in 10
<jcastro> hatch, negatron
<negatron> yes?
<hatch> :)
<jcastro> hatch, some people want one as a sub, but I think mostly it's like, for whatever you are charming, provide a web server, config option to swap out the two
<jcastro> I think the ability to sub on whatever webserver you prefer could also be badass
<hatch> hmm - I did some work on the ghost charm last night, working towards getting the fixes for promotion. I need to provide something so I was thinking nginx
<hatch> nginx won't work as a sub because you could do load balancing with it
<jcastro> hatch, we've had the argument back and forth in ~charmers about an nginx charm for about .... 2 years
<hatch> sounds like the person to put the code into the charm gets to decide then ;)
<jcastro> indeed
<hatch> ok well for the ghost charm purposes I'll need to find something which provides an http interface for apache first I guess
<hatch> try and figure that beast out
<Makyo> jujugui call in 2
<bac> benji: any objection to removing the remove_charm.py script when we can do it via the GUI?
<benji> bac: nope, sounds good
<rick_h_> Makyo: let me know if you get time and want to chat on the app state card if you're heading that way after the tests and such. 
<Makyo> rick_h_, sure. Can chat whenever, expect another 45 mins or so on this.
<rick_h_> Makyo: ok, I've got calls in 3hr on so want to make sure I don't block you today
<Makyo> Alright, will make sure it's before then
<hatch> rick_h_ so the only issue I can think of moving the ecs into the env is that it will then not support pyjuju (because it will only be in the go env) I'm sure this is ok just want to make you ware
<hatch> aware 
<rick_h_> hatch: yep, works for me. If we had time I'd add cards to start yanking pyjuju code 
<hatch> ohh the env doesn't have reference to the db
<rick_h_> hatch: oh, okay then
<hatch> now should it?.....hmm
<rick_h_> hatch: hmm, have to look at that. 
<hatch> I'm thinking no
<hatch> it hasn't had to modify or reference anything outside of it's little world
<rick_h_> hatch: works for me
<hatch> I'm going to leave it in app for now - it can be moved later if we feel it should 
<Makyo> rick_h_, time for a call?
<rick_h_> Makyo: sure thing, give me 2min
<Makyo> Sure/
<rick_h_> Makyo: k, shoot me a link?
<Makyo> Once G+ figures out what it;s doing
<Makyo> https://plus.google.com/hangouts/_/76cpihh3ddg7hsj76kq3s5v7i8?authuser=1&hl=en
<hatch> rick_h_ I figured you'd get a kick out of https://github.com/visionmedia/mocha/commit/a2968bf64e13cf15ccd33b8d395947a305fbd461 221-235 :)
<rick_h_> ugh!
<hatch> lol
<hatch> done done done done done........done?
<rick_h_> yea, so much nicer and easier for sure!
<hatch> lol
<rick_h_> I nee some more done with my done
<rick_h_> cause it's not really done
<hatch> done all the things!
<hatch> heh I forgot how much work it was going to be to create a utils directory
 * hatch proposes we switch to Grunt
<rick_h_> for what?
<hatch> our makefile
<hatch> binary has to be easier to follow than this
<hatch> lol
<rick_h_> :)
<hatch> there is some wako stuff going on here
<hatch> build-debug/juju-ui/assets/tabview/assets
<hatch> tabview is an asset?
<rick_h_> umm, thought it was a widget
<hatch> yeah there is some funkyness going on in there
<hatch> there are a bunch of yui modules in there
 * hatch throws hands up in the air
<rick_h_> hatch: need another set of eyeballs? What's up?
<hatch> oh I got it
<hatch> I had it a long time ago
<rick_h_> k
<hatch> but for whatever reason -f wasn't -fing
<hatch> when all else fails....make clean-all
<rick_h_> heh
<hatch> there really is some funkyness in that makefile though
<hatch> it's including direct references to odd yui files
<hatch> I'm sure there is a reason....but none is listed
<hatch> I love it when a deepequals fails but doesn't tell you what failed heh
<Makyo> jujugui small review, tests only: https://github.com/juju/juju-gui/pull/183
<hatch> sure
<hatch> ooo interesting - inline functions in an array are parsed as strings 
<hatch> Makyo all done
<Makyo> Whoa, Yahoo bought Vizify and are shutting it down.
<hatch> cool passThroughToOriginalMethod I didnt even know we had this 
<hatch> Makyo oh darn it looks like they made a cool product
<Makyo> Yeah, hopefully it picks back up as something else under Yahoo.
<hatch> probably just a gui in some admin panel somewhere heh
<Makyo> jujugui just found out we have a water leak between the meter and the house, losing about a gallon a second. Going to step away to start calling around, since the water district won't repair it.
<hatch> ouch! good luck!
<hatch> interestingly enough our water meters are inside our houses, so when something breaks between the meter and the outside the city has to come and dig a hole in the front yard to shut it off 
<benji> yow, that's a lot of water; good luck
<Makyo> 76,000 gallons in February.
 * bac wishes he could lose a gallon a second
<hatch> holy crap!
<rick_h_> we had a leak in our sprinkler system. Since we got quarterly water bills didn't know until the $900 bill arrived
<rick_h_> we think it was only going for the weeks prior to the bill. 
<hatch> ouch
<Makyo> Yeah, our sewer company informed us we were using 127% of annual allotment.
<hatch> well sheesh at least someone told you! 
<hatch> that could have been expensive
<Makyo> It is expensive.  The water company won't credit us, so bills are at $250, and we have to fix it ourselves.
<hatch> :/ 
<hatch> lunching
<hatch> oo unity 5 preorder http://unity3d.com/5
<hatch> I remember when it was Unity 3D :P
<lazyPower> hatch: when native unity lands in teh browser, ar eyou going to be a mesh rendering machine?
<hatch> haha probably not - a while ago I dabbled in C# to make a game in Unity but then got side tracked :)
<lazyPower> mono flavored C# or .Net?
<hatch> mono 
<lazyPower> i ask because I have done both :)
<hatch> I still don't understand .Net
<lazyPower> meh, its just the kitchen sink
<lazyPower> nbd
<hatch> it's a framework...but not....but is....
<hatch> :)
<lazyPower> think of it as a big tree made of hate with strongly typed datatypes
<lazyPower> thats all you need to know
<hatch> lol
<hatch> I liked C# but it has some very odd things
<hatch> like using different methods for arrays and  multi dimensional arrays
<lazyPower> this is where .Net trumps mono. Linq made all of that dead simple
<lazyPower> and it was stupid fast
<lazyPower> s/was/is
<hatch> ahh, well then, it's not made of 'only' hate then :P
<lazyPower> linq will bite you eventually
<lazyPower> so my statement still stands
<hatch> haha ok I'll take your word on it
<hatch> I have some ideas for games and whatnot but can never find a designer to partner with
<hatch> lots of coders but designers never seem to want to pair up :)
<bac> rick_h_, benji: i'm seeing errors like http://paste.ubuntu.com/7116218/ when running the charmworld test suite.  chameleon creates temp python files in /tmp and they aren't getting cleaned up.  i added some new form tests and perhaps pushed us over some threshold.  ideas?
<rick_h_> bac: hmm, not seen it. I'd assume it's not the templates that's causing it? Do we have some other process creating too much junk?
<rick_h_> bac: http://stackoverflow.com/questions/16526783/python-subprocess-too-many-open-files notes updating limits to get around it, but will have to chase down the root there to 'fix' it. 
<bac> rick_h_: well, there are definitely chameleon template files laying around.
<bac> rick_h_: huh, lsof shows that process has 1024 files open but in CLOSE_WAIT
<bac> so, these aren't files but sockets...
 * rick_h_ runs away to get the boy from day care. 
<rick_h_> bac: sorry, I'm not sure off the top of my head. It talkes to mongo and ES over tcp/ip not sockets. So not sure what it'd be using
<Makyo> Argh, I just need a plumber.  Apparently they're ALL in another castle today.
<hatch> Makyo can you shut off the water at the meter at least?
<hatch> sucks to not have water...but better than leaking I guess
<Makyo> Yeah, that's the last resort.  It's not running fast enough to make it worth having to turn it back on every time we need to use the restroom, yet.
<Makyo> (Rechecked the meter, there's a decimal place in there.  1/100th of a gallon a second)
<bac> makyo but you get one free flush per toilet!
<Makyo> Hah!
<hatch> haha
<hatch> jujugui looking for a review on the Environment Change Set branch https://github.com/juju/juju-gui/pull/184 (more branches to come)
<hatch> tests passed
<rick_h_> Makyo: can you peek at ^? I want to make sure we get feedback from others on a big important part
<rick_h_> hatch: and maybe frankban as well. Maybe not
<Makyo> rick_h_, sure, 1sec.
<hatch> rick_h_ sure I can send him an email to review
<rick_h_> Makyo: no rush, just know hatch and I have gone through it, and want to get other eyeballs to help make sure we think all things through and not get blinded by previous discussions
<Makyo> Yep, sounds good.
<rick_h_> it'll set a big path for us that will effect a bunch of other cards off of this
<rick_h_> thanks Makyo 
<huwshimi> Morning
<rick_h_> mornining huwshimi 
#juju-gui 2014-03-19
<bac> hi huwshimi
<huwshimi> bac: Hey!
<bac> huwshimi: you coming to vegas?
<huwshimi> bac: Yep!
<bac> cool.  look forward to seeing you there.
 * bac dinners
<bac> bye
<huwshimi> seeya
<rick_h_> huwshimi: are you cool or did you need a chat or another pair of eyes?
<huwshimi> rick_h_: I'm not quite sure what's going on, but I'm sure I can figure it out.
<huwshimi> rick_h_: Did you have specific things you wanted me to test, there's not really anything going on at the moment...
<rick_h_> huwshimi: ok, well going offline for the night. 
<huwshimi> rick_h_: Yeah, head off, it sounds like tonight you shouldn't be working :)
<rick_h_> huwshimi: just that the render works ok, maybe verify some of the height calc stuff if we need to. 
<huwshimi> rick_h_: OK sure
<huwshimi> rick_h_: Night
<rick_h_> huwshimi: mostly basics, nothing specific in my head yet. It'll get a lot more as we integrate with other things. 
<rick_h_> huwshimi: have a good day
<huwshimi> rick_h_: OK sure. Will do.
<rick_h_> morning
<frankban> hi rick_h_ 
<rick_h_> we having fun yet frankban ?
<rick_h_> frankban: you able to make the rescheduled interview tonight?
<frankban> rick_h_: sure
<rick_h_> frankban: cool thanks
<dimitern> benji, hey, have you used teambeamer in trusty?
<benji> dimitern: nope, I haven't (I just installed trusty recently)
<dimitern> benji, I'm wondering how difficult it is to set it up on trusty - perhaps building from source?
<benji> I don't think it'll be too hard.  Termbemer itself is trivial to "build" because it is Python, but the dependencies might give you some trouble.
<benji> have you tried installing from the PPA?
 * benji tries
<bac> rick_h_: actually I'm inclined to go with the default values for MongoClient, which is fsync of False.
<rick_h_> bac: ok, we can try it. worst case we know where the code is
<bac> rick_h_: the defaults for MongoClient are "safe writes" as opposed to the unacknowledged unsafe writes of the defaults for Connection()
<rick_h_> bac: gotcha, than that's great. I just remember debugging strange test issues too much from Connection() as the unsafe default writes made it a headache
<bac> rick_h_: Even without fsync=True you'll still get a fail message on conflicts.  the reading i've done says avoid fsync "if you can help it".  our use should allow it to be safe.
<bac> rick_h_: i'll push the latest changes for you to eyeball on RV
<rick_h_> bac: ok thanks
<bac> rick_h_: it looks like defaults are sane.  using w=0 is the only thing that gets you into trouble, breaks locks, etc
<rick_h_> ok
<rick_h_> yea, I worried we went too far safe with w=1
<bac> tmi.  :)
<rick_h_> but knew we originally added the safe=true for hard to debug test failures
<rick_h_> hwody kadams54, welcome to jujugui
<rick_h_> err howdy
<kadams54> Morning all.
<benji> dimitern: the PPA wasn't set up to build packages for trusty, I have set that up now; we'll see if they build without error
<dimitern> benji, cheers!
<dimitern> benji, I see python-vte is being built right now, but can't see pending builds for termbeamer, here: https://code.launchpad.net/~benji/+archive/termbeamer/+packages
<benji> dimitern: build started
<benji> (and the VTE build worked, which is the one I was worried about, so that's a good sign)
<dimitern> benji, great!
<bac> welcome kadams54
<frankban> rogpeppe: morning, do you have time today for reviewing https://codereview.appspot.com/77420043 ? thanks a lot
<frankban> kadams54: welcome!
<hatch> thanks for the review frankban! 
<frankban> hatch: mp
 * frankban lunches
<rick_h_> hatch: when you have the else you don't need the return :P
<rick_h_> hatch: having BOTH is the issue
<hatch> I like it being explicit in case someone adds code outside of the conditional 
<rick_h_> right, but it's harder to find the return value of a func when it's returning all over the place
<rick_h_> "oh, this function has a condition on line 10 that returns something else"
<rick_h_> I generally have a dislike for those, but I admit it's a personal pref
<rick_h_> especially because you were just using the return to avoid an else in this case. There's no explicit return value
<hatch> heh and I prefer to use returns :)
<rick_h_> s/return/break and maybe...
<rick_h_> empty returns are so semantically just broken
<hatch> a break could potentially introduce the issue I was trying to avoid
<hatch> lol no they aren't
<rick_h_> "yea, here's you're return value...nothing, and never will be...booya"
<rick_h_> "but if you add a return value in one case, better go grepping through the whole function in case we return in othre places you're not looking in"
<rick_h_> ugh :P
<hatch> well it's returning undefined :) but in this case it's acting as a short on the function
<rick_h_> right, like an if else 
<hatch> lol the function is only 10 lines long
<rick_h_> if x do a else do b
<hatch>  // don't add extra code outside of this if block 
<hatch> vs
<hatch> return; 
<rick_h_> it's the principal of the thing! /me gets his soap box
<hatch> :)
 * hatch gets bigger soap box
<hatch> (and the soap box arms race begins)
<hatch> lol
<rick_h_> lol, canadaians, bigger? never!
<rick_h_> bah canadians
<hatch> hah fine - I'll remove the return.....under duress! 
<rick_h_> lol
<rick_h_> hatch: Huw's branch isn't quite ready, I turned it into a pull request and it's failing CI, but if you get time could you pull it down and review/qa please?
<rick_h_> hatch: and we can provide feedback for him to try to get that landed tonight
<hatch> rick_h_ yeah sure
<rick_h_> hatch: thanks
<bac> rick_h_: vacation request submitted for 1/2 week before sprint
<rick_h_> bac: thanks
<rick_h_> kadams54: you should have an invite for kanban, let me know when you accept so I can give your account permissions
<kadams54> rick_h_: Accepted.
<rick_h_> kadams54: awesome thanks
<frankban> rick_h_, hatch: I agree it's a personal preference. I also like return to exit the function faster and then the rest of code being not nested, i.e. from now on I can read the function without thinking about conditionals. it's just that return + nested else seems a bit unclear to me 
<hatch> hmm
<hatch> :)
<rick_h_> kadams54: ok, you should be able to load the kanban board now
<rick_h_> kadams54: please verify before the standup in 40
<kadams54> rick_h_: Yup, I'm in and looking it over.
<rick_h_> kadams54: oh, you need to get travel setup as well
<hatch> frankban wow I don't think I've ever typed so much in a code review :P Mind taking a look and seeing if I answered all of your questions
<hatch> and btw - you found a serious bug :) thanks
<hatch> welcome kadams54 
<frankban> hatch: I'll take a look asap
<hatch> rick_h_ il? "Yo man this feature is so ILL"
<rick_h_> hatch: :P
<hatch> lol
<rick_h_> good way to remember it
<hatch> haha
<hatch> my next feature flag will be steezin 
<lazyPower> rick_h_: did you see ppetraki's comments in #juju-dev?
<lazyPower> the charm store is exporting null bundles
<ppetraki>  has anyone tried to download a bundle lately from the charm store? I've tried to export several different ones and all I'm getting is
<ppetraki>  envExport: 
<ppetraki>    services: {}
<ppetraki>    relations: []
<ppetraki>    series: precise
<lazyPower> that one ^
<rick_h_> lazyPower: no, what's up?
<rick_h_> ppetraki: oh looking
<rick_h_> ppetraki: hmm, how are you downloading? Is this when you build an environment on jujucharms.com and hit export?
 * ppetraki digs up example
<rick_h_> ppetraki: I just did a qiuck test and it worked. I wonder if you're trying to do something differently or with something that's not working? 
<rick_h_> ppetraki: screenshot of your environment would be useful to replicate on jujucharms.com to test out
<ppetraki> ack
<rick_h_> ppetraki: thanks, we'll help look into it for sure. Thanks for the report of the issue.
 * rick_h_ goes afk for a few to migrate home from coffee shop
<ppetraki> rick_h_, http://picpaste.com/upload-guibad-aN53Tvlj.png
<ppetraki> rick_h_, I just visit the bundle, click the '^', and open the file it downloaded
<Makyo> ppetraki, deploy the bundle to the GUI first.  The ^ button exports the canvas, not the charm or bundle you are viewing.
<Makyo> Will take a note, though, that's worth clarifying.
 * hatch is also relocating
<Makyo> ppetraki, if you wish to grab a bundle's code from the store without deploying, you can go to the code tab, eg https://jujucharms.com/bundle/~charmers/mediawiki/6/single/#code and select the bundle.yaml file.
<ppetraki> Makyo, it says it'll be deployed to my local provider immediately, does that mean my current juju-env?
<Makyo> ppetraki, if you are viewing it at jujucharms.com, the provider is the demonstration provider, which is just a sandbox within the browser.
<ppetraki> Makyo, yeah, as a regular user I have no idea what the difference is
<ppetraki> and assumed the worse
 * ppetraki well, im not exactly a regular user
<Makyo> ppetraki, that's totally fair.  We'll see if there's a way to make that more clear.
<ppetraki> Makyo, thanks
<Makyo> jujugui call in 10
<lazyPower> ah thats something I didnt think about, that charms are transient until you actually "deploy" them on the gui
<lazyPower> see? this is why you guys make the big bucks. 
 * lazyPower thumbs up
<Makyo> https://bugs.launchpad.net/juju-gui/+bug/1294694 cc ppetraki 
<_mup_> Bug #1294694: Bundle deployment in sandbox is confusing <juju-gui:New> <https://launchpad.net/bugs/1294694>
 * Makyo coffees self thoroughly before call.
<ppetraki> Makyo, sub'd, thanks
<hatch> jujugui call in 3
<frankban> hatch: thanks. also your comments look good. what do you think about my last proposal (re: functional approach)?
<hatch> yeah I think that will be a good change
<hatch> sorry I meant to comment on that :)
<rick_h_> kadams54: https://plus.google.com/hangouts/_/canonical.com/daily-standup?authuser=1 in case you can't see the link in the calendar 
<frankban> hatch: oh, and it would be nice if the changeSet hierarchical structure is documented in that branch
<frankban> thanks for that branch hatch 
<rick_h_> benji: standup pingu
<hatch> yeah I can do that - I kind of didn't on purpose because I figured the structure might change a bit
<hatch> luca is there an overview image of the new zoom assets?
<luca> hatch: like a mock up?
<hatch> luca yeah, you mention getting rid of the slider, so are there just going to be two buttons floating there now?
<luca> yeah, sec
<hatch> can you add it to the bug plz and thanks :)
<luca> hatch: same style as the bundle visualisation zoom slider
<luca> https://docs.google.com/a/canonical.com/file/d/0B_l975nRB6BuSEVfQXhxU2g2SXc/edit
<hatch> ahh ok cool
<hatch> I'll update the ticket
<luca> ok, thanks
<rick_h_> hatch: try to upload the orig png please
<rick_h_> hatch: as the gdocs link isn't public bug the bugs are
<rick_h_> hatch: so it keeps more info in the open
<hatch> ok cool
<luca> ah
<luca> right
<luca> sorry
<rick_h_> luca: np, just want to keep us all nice and open for community/etc 
<rick_h_> thanks for the update and bug report!
<hatch> addeed
<rick_h_> thanks hatch 
<hatch> I really need to figure out how to setup znc 
<hatch> someone just parked a van across the street on the sidewalk and snowbank......intentionally....
<hatch> that's got to be a first
<lazyPower> hatch: its the nsa!
<lazyPower> hatch: also - have you looked at quassel? the ZNC component is dead simple to setup/use
<hatch> lol - or a, now-stuck, idiot
<lazyPower> + it has a mobile component for those of us on the go that like to keep irc in our pockets.
<hatch> lazyPower well I'd like to set up a ZNC bouncer so that I could log into it with textual in osx and something like quassel in Ubuntu
<lazyPower> quassel has a osx client to...
<hatch> oh? 
<hatch> interesting
<lazyPower> yeah it runs on every flavor of OS, i'm pretty sure there's a chrome extension being dev'd too
<hatch> I really like how textual uses safari so you can theme using css
<hatch> safari webview that is
<lazyPower> hatch: well, DO has you covered - https://www.digitalocean.com/community/articles/how-to-install-znc-an-irc-bouncer-on-an-ubuntu-vps
<lazyPower> and that smells of an opportunity to be charmed
 * lazyPower nudges gently
<hatch> oh awesome
<hatch> lol - I need way more hours in the day
<lazyPower> you and me both brother
<hatch> I wish DO had a juju provider
<lazyPower> uhm
<hatch> hazmat wrote one
<lazyPower> hazmat has written an alpha provider plugin
<hatch> :)
<lazyPower> yeah
<lazyPower> https://github.com/kapilt/juju-digitalocean
<hazmat> hatch, jump on in.. its fresh out of the oven ;-)
<hazmat> that's when the cookies are best
<hatch> lol 
<hatch> it's true!
<hatch> hazmat does it support deploying using --to ? :)
<hatch> bootstrap + gui + znc + whatever other garbage I want to put on their smallest node :P
<hazmat> hatch, ofc.. its a little differrent than a normal provider.. you $ juju docean bootstrap .. $ juju docean add-machine -n 5 
<rick_h_> heh 512mb isn't much of a node
<hazmat> before deploying.. and then you can do deploy to .. etc
<hazmat> hatch, you can even do envs that span the globe ;-).. i did one env split between ams and nyc.
<lazyPower> nice
<hazmat> manual provisioning solves everything :-)
<hatch> hazmat is that a decision you made or a technical limitation of DO not being able to deploy and auto add machines?
<hazmat> hatch, its a limitation of juju's ability to do external provisioning plugins
 * rick_h_ goes to nuke lunchables
<hazmat> hatch, i'd have to api intercept to do more interesting things
<hatch> ahh
<hazmat> hatch, but really its a trivial burden imo.. to type one extra line to allocate machines before deploying or add-unit. 
<hatch> yeah for sure
<hatch> I'd have to think of something else to put on that node.....$60/yr for a znc bouncer is a little nuts haha
<lazyPower> hatch: if you go the route of quassel i'd have no problem putting you on my bouncer
<lazyPower> but you have this need for textual - sooooo
<hatch> can I trust you not to read my messages?????
<hatch> CAN I!!!
<lazyPower> no
<lazyPower> i'm the nsa dude
<lazyPower> :P
<hatch> I knew it
<lazyPower> haha, yeah man idc
<lazyPower> i never mess with the db
<lazyPower> if you trust me i trust you kinda trust
<hatch> interesting that there are no 'znc as a service' startups
<hatch> lol
<lazyPower> such a niche market
<hatch> I bet people would pay $5-10 a year
<hatch> oh right..... znc and food picture sharing as a service
<hatch> ^ startup idea
<hatch> *patented*
<lazyPower> hatch: i'll sync with antonio i'll ping you with the quassel core details
<lazyPower> s/i'll/after my
<hatch> cool thanks
<lazyPower> np 
<hatch> frankban https://gist.github.com/3dd5ddad7b0e765af3e5 a litle more functional
<hatch> thoughts?
<frankban> hatch: looking
<hatch> thanks
<frankban> hatch: looks good
 * Makyo runs to grab prescription, will have other laptop at coffeeshop.
<hatch> cool - now to fix all the tests
<hatch> bac https://twitter.com/dam/status/446323090612420608 hehehe
<frankban> guihelp: I need one review/QA for https://github.com/juju/juju-gui/pull/186 Anyone available? thanks!
<hatch> sure I can
<frankban> thanks hatch 
<benji> frankban: I'll take a look at your review and perhaps you'll have time to look at https://codereview.appspot.com/76860047 while I do that
<benji> frankban: oh, you already have a reviewer, well, I'll let you review my branch anyway
<frankban> benji: sure, I'll take a look
<benji> frankban: note that the branch has undergone extensive QA, so you can feel free to skip that if you feel so inclined
<frankban> benji: cool, ok, I'll just look at the code
<rick_h_> frankban: did you determine if we should file a -core bug on the issue?
<frankban> rick_h_: I planned to investigate that in core and file a bug if required, with instructions to dupe
<rick_h_> frankban: ok cool thanks
<rick_h_> DrabMakyo always has me looking for ShinyMakyo
<ShinyMakyo> Given that this is the Air, I might as well.
<hatch> lol
<rick_h_> lol
<hatch> frankban +1 but I can't QA right now unfortunately
<ShinyMakyo> Damn, missed opportunity for FabMakyo
<rick_h_> hah!
<frankban> hatch: thanks. benji: could you please QA my branch? (only if you have local envs up and running)
<benji> frankban: I don't have local set up yet.  I am willing to get it set up if you don't think it'll be too painful.
<hatch> ooo move state out of browser.... I like the sound of that card ShinyMakyo :)
<ShinyMakyo> Haha.
<ShinyMakyo> Part of the other card with my face on it.
<frankban> benji: well, I am not on trusty, but maybe it's worth trying the following: sudo add-apt-repository ppa:juju/stable && sudo apt-get update && sudo apt-get install juju-quickstart && juju-quickstart
 * benji tries
<hatch> ShinyMakyo what I have been doing is, when I create a sub card, add a count to it and then subtract that from the 'parent' card....I'm not sure if it works yet but it at least keeps the estimated work somewhat accurate
<ShinyMakyo> Ah, yeah, that makes sense.
<rick_h_> hatch: ShinyMakyo yes please
<ShinyMakyo> Done and done
<hatch> lately I've been getting test failures where the traceback points to another test entirely.....very odd
<frankban> benji: I am not sure about how that nrpe hooks work. did you create relation-broken/departed sym links in your branch?
<benji> frankban: I did
<frankban> benji: oh, ok, Rietveld does not show that :-/
<benji> frankban: quickstart is bootstrapping ec2, is that expected?  Should I set up a local environment config and make that the default?
<rick_h_> benji: I tend to
<rick_h_> benji: as it's a lot faster and nicer to work with and doesn't cost $$
<frankban> benji: yes, so you already had an environment. so now you can stop quickstart, destroy the ec2 env, and then create a local one with "juju quickstart -i"
<frankban> benji: also, since you already have juju configured, before running quickstart -i, it's better to apt-get install mongodb-server lxc
<hatch> frankban I pushed the latest changes up, mind taking a look for a +1 ?
<benji> frankban: too late, but quickstart told me to install it, which is nice
<frankban> cool
<frankban> benji: review done
<benji> thanks
<ShinyMakyo> Okay, prescription's ready.  Will be back home in a few.
<benji> frankban: local environment setup seems to be working (but not done yet)
<benji> once it's done and I'm sure it's working I'll QA your branch
<frankban> benji: cool, setting up a local env with the GUI is also the first step of my QA instructions
<benji> I'm glad you told me because I would have destroyed it before looking at the QA instructions :)
<benji> frankban: uh oh: juju-quickstart: error: juju-gui/0 is in an error state: error: hook failed: "install"
<frankban> benji: interesting, what's in ~/.juju/local/log/unit-juju-gui-0.log?
<benji> frankban: oops, I have already destroyed the environment and am trying again
<benji> frankban: http://paste.ubuntu.com/7121143/
<hatch> Makyo did you ever get a chance to look at my branch?
<frankban> benji: so apt failed. juju status?
<benji> frankban: http://paste.ubuntu.com/7121162/
<frankban> benji: ok, so the lxc is precise and that's correct. next step is trying the same command from inside the lxc: juju ssh juju-gui/0; sudo -i; apt-get -y install libapt-pkg-dev python-apt python-launchpadlib python-tempita python-yaml
<Makyo> hatch, Yes, but not with changes.  Let me prowl through again.
<frankban> let's see what the real error is
<benji> frankban: there's the problem: No space left on device
<frankban> oh...
<benji> who needs a root partition larger than 20 gig I said, that would be crazy I said
<frankban> :-)
<benji> I think you'll have to look somewhere else for your QA
<frankban> ok. rick_h_, Makyo, bac: ^^^ anyone available for QAing https://github.com/juju/juju-gui/pull/186 ?
<bac> doubtful
<Makyo> frankban, I can.
<frankban> Makyo: thanks
<bac> benji: it needs 20G free?
<benji> bac: I only have 20G total... oh, I only have 10G total on that partiion
<bac> benji: yeah, i had to go through the resize dance on my vm.  was doable but unpleasant
<hatch> Makyo ok cool thanks, I just want to get it landed
<rick_h_> frankban: let me know I can after calls today if you still need someone
<Makyo> hatch, ack.  
<frankban> rick_h_: thanks, Makyo is doing the QA
<hatch> frankban yeah sorry about the QA, updating juju borked my machine so I need to upgrade it and haven't had the time :/
<hatch> well juju and my machine are borked together :)
<frankban> hatch: np, thanks for the review
 * hatch lunching
<frankban> benji: very good plot twist :-)
<benji> heh
<Makyo> frankban, I can't reproduce the first error
<Makyo> Let me get more info.
<Makyo> juju 1.17.4
<Makyo> frankban, (ping re interview, though)
<frankban> Makyo: maybe it's intermittent. uhm. I was using stable
<Makyo> frankban, ack, will keep poking.
<frankban> Makyo: thanks
<hatch> rick_h_ around?
<rick_h_> hatch: otp, what's up?
<hatch> ok I'll type :) was gona request a hangout
<hatch> sec
<hatch> when a user is calling setConfig we allow them to pass in a queued service or a real service. If the service is queued and they use the `immediate` flag, should we A) disregard or B) deploy the service and set the config? I vote A with a console warning
<hatch> kadams54 hey just fyi you're still running through sourceforge's vpn for irc :)
<rick_h_> hatch: hmm, throw an error for now?
<kadams54> hatch: lol, thanks man :-)
<rick_h_> hatch: I mean we don't have a use case for this atm
<hatch> rick_h_ throw as in throw()?
<hatch> right, I just want to cover the bases 
<rick_h_> hatch: so it seems like a case of problems we don't have atm
<hatch> haha I'm avoiding them before they are :)
<rick_h_> yea, +1 on thinking about it, but don't want to get hung up on it
<hatch> I think that the 'immedaite' is a real usecase and it's really not much more work to do it at the same time
<rick_h_> the only use case I see is testing?
<rick_h_> or is there more I'm missing?
<hatch> well just if we want to give the user the ability to bypass the deployer bar for any request
<rick_h_> right but that's not in any design for now
<hatch> and testing
<rick_h_> there's not  real use case for the user to select it
<rick_h_> and testing I think we can throw the error that shows "you forgit an immedite on the service, fix that in your setup"
<rick_h_> forgot
<hatch> ok I'll throw for now
<rick_h_> does that make sense?
<hatch> yep it does - I am pretty sure that it's an interaction we will want to allow though 
<rick_h_> hatch: k, yea that's why I'm fine thinking on it, but until we have a use case to walk through I'm not sure how to handle it 
<hatch> right ok cool
 * hatch grumbles about using if/else vs multiple returns
<hatch> :P
<rick_h_> hatch: I give, if you and frankban like it I'll give. :P
<hatch> VICTORY!
<hatch> lol
<hatch> how about short variable names?
<hatch> too far?
<rick_h_> NO!
<hatch> lol
<hatch> hahaha
<rick_h_> or something like that
<kadams54> Not to start any holy wars, butâ¦ what are some of the different dev setups you guys use? I've been playing around with several different ones today (vagrant, regular Ubuntu VM, dual boot) and trying to figure out where I'm going to be most productive.
<hatch> kadams54 atm I'm using OSX with the gui's vagrant config
<hatch> I also have a box in the basement running Ubuntu to do real env testing
<hatch> I also have a Ubuntu VM for various ubuntu stuff locally
<hatch> I am trying to run Ubuntu on metal but the current kernel doesn't work on the new Apple haswell cpu's
<hatch> but you will find that working IN Ubuntu is a lot less work when working with charms, juju-core hacking, etc
<hatch> so...depending on your laptop the answer may be made for you :)
<Makyo> rick_h_, lost hangouts, sorry
<Makyo> Or maybe I lost Internet...
<hatch> I see u
<hatch> messages that is :)
<hatch> jujugui I need a pre-imp call with someone about the set_config interaction with a ghost service
<hatch> anyone available?
<kadams54> Another question: I'm not going through SF VPN, but I do have a SF cloak. Does Canonical have cloaks?
<kadams54> Yeah, I may setup a spare desktop I have lying around to run Ubuntu on the bare metal. Right now I'm leaning towards vagrant on my MacBook.
<kadams54> It's an older MacBook, but I use some stuff that's OS X-onlyâ¦ like coreStorage to tie together an SSD and a traditional HD into a single logical volume.
<hatch> that's a good question - I have seen it....I just assumed they were running through the vpn
<kadams54> Hah, no.
<kadams54> And there was also the hitch this morning with getting my webcam to work in Ubuntuâ¦
<hatch> some may give you a hard time about it.....I have a ubuntu logo on my Apple symbol lol
<hatch> dogfooding and all that :)
<kadams54> Yeah, I'm beginning to realize that :-) My intention is to spend as much time in Ubuntu as possible.
<hatch> hmm there are quite a few ghost service interactions that need to be thought out for this state manager
<rick_h_> hatch: :)
<hatch> rick_h_ when you have a second lets have a hangout
<rick_h_> hatch: k, shoot me a link 
<hatch> https://plus.google.com/hangouts/_/76cpiohup8sdmhrmvej1p946sg?hl=en
<hatch> Makyo poke
<Makyo> hatch, sorry, got wrapped up :(  5 minutes?
<hatch> haha yeah sure - I'm working on a new branch, I just branched off of it
<hatch> no problem
 * rick_h_ runs away for the day. I'll be back.
<hatch> lol such a lie
<rick_h_> hatch: hey, I'll be gone a solid hour at least :P
<hatch> haha
<rick_h_> then I've got a bunch of emails to go through and send out :/
<Makyo> hatch, lgtm
<hatch> bah CI got backed up again
 * Makyo walks dogs quickly
<bac> rick_h_: i've added some notes to the google doc on the candidate.  i've also changed the view permissions to invite only.
<rick_h_> bac: rgr thanks for the update and thought on perms
<rick_h_> good call
 * bac dogwalks
<hatch> jujugui CI is back running again it'll take about 40mins to clear through its queue
<hatch> kadams54 did you add 'jujugui' and 'guihelp' to your notifications in your IRC client?
<hatch> evening luca
<kadams54> hatch: yup
<hatch> awesome - just don't want you to miss out on all the awesome dings to break your concentration :P
<kadams54> lol
<hatch> what time is it there? Are you on the same tz as rick_h_ ?
<kadams54> I'm US Eastern, so it's 5:30 here
<kadams54> Yeah, same state even :-)
<kadams54> We're going to be meeting up at a coworking spot all next week.
<hatch> yeah I hear it's a drive
<kadams54> 45 minutes for me, not sure exactly where rick_h_ is coming from.
<hatch> yeah he said about that for him too
<kadams54> I was impressed that the town we'll be meeting up in has a coworking spot.
<hatch> that's good though, it was just over a month before my first get together and it was a full blown sprint 
<hatch> haha yeah they are pretty rare 
<kadams54> FYI, I'll be signing off shortly, once pizza arrives for family night.
<hatch> no problem
<kadams54> I'm diving into my first ticket now, replicating the issue and getting familiar with the codebase, so tomorrow should see some actual coding :-)
<hatch> excellent, which ticket are you on?
<kadams54> https://bugs.launchpad.net/juju-gui/+bug/1269381
<_mup_> Bug #1269381: keybinding for centering canvas is actually S-) <bitesize> <juju-gui:Triaged by kadams54> <https://launchpad.net/bugs/1269381>
<kadams54> What would be normal process for picking up a bug? Assign it to myself and mark as in progress?
<hatch> kadams54 has Rick got you set up on the kanban board yet?
<kadams54> Yeah
<hatch> ok so then you would create a card in High (because that's not part of an active project) put your head on it and drag the card into the Active lane
<hatch> you'd also mark the bug as in progress and assigned to you in launchpad
<hatch> in the High block.... right click > add card > defect > put the bug # in Card ID, put the bug title in Title and assign to you
<kadams54> Oh, that reminds me - how do I change my avatar in leankit? Looked around a bit for a way to change it, made sure I'd added my canonical email to gravatars in case it used that, but I'm still a generic "KA".
<hatch> hmm....
<hatch> there is a 'manage account settings' button but it's not clickable heh
<rick_h_> the avatar is hooked to gravatar
<rick_h_> so you need to set a gravatar for that email addresss
<kadams54> Yeah, I did.
<kadams54> I suspect there's a cache somewhere that needs refreshing
<hatch> or lk is just broken...that happens :)
<hatch> lazyPower you picked up a new sputnik?
<lazyPower> hatch: sure did
<hatch> I didn't know they updated it?
<lazyPower> haswell i7 
<lazyPower> that update came in what... november?
<hatch> oh interesting :) HiDPI screen too?
<lazyPower> its sexy with its touch support
<lazyPower> now i have finger prints all over my monitor
<hatch> hmm ok you're going to have to link me to these details
<hatch> lol
<lazyPower> http://www.dell.com/us/business/p/xps-13-linux/pd.aspx
<hatch> what kind of battery life are you getting?
<lazyPower> ~ 4.5 hours with reasonable dim on display + disabling keyboard lights
<hatch> intersting
<hatch> well glad that it's working out well - hopefully more come with Ubuntu as time goes on
<lazyPower> Indeed. My only complaint is hte ram is soldered to the board
<lazyPower> so i wasn't able to give it a 16gb ram upgrade, but it does what i need it to do as is :)
<hatch> well hey everything is glued together on mine so nothing is being changed.....ever
<hatch> lol
<huwshimi> Morning
<hatch> morning huwshimi 
<hatch> I commented up your branch :)
<huwshimi> hatch: Ah, thanks
<rick_h_> huwshimi: yea thanks for the updates. I made a pull request to get a qa and review
<rick_h_> huwshimi: hatch brought up a couple of points, let me know what we can to do get it landed
<rick_h_> huwshimi: and morning and all that :)
<huwshimi> rick_h_: No problems, taking a look now.
<huwshimi> Do we have any way to test things in app/index.html?
<huwshimi> I that test_startup.js?
<huwshimi> *Is
<hatch> huwshimi yup
<huwshimi> OK :)
<Makyo> Unity reset desperately needed.  May disconnect :T
<hatch> eod'ing a touch early, brain not working...will bbl
<Makyo> Whew, I still have a desktop.
<huwshimi> The setup of test_startup.js is misery and loathing to all that might venture near...
<huwshimi> Partially because of the index.html and all its inline code...
#juju-gui 2014-03-20
<frankban> rogpeppe: ping. any chance to get my branch reviewed soon? That's blocking some tasks on our side, and it would be nice to know if it's in the queue (sorry to bother you).
<rogpeppe> frankban: sorry, i will do - i've been concentrating on moving HA forward
<frankban> rogpeppe: thanks!
<rogpeppe> frankban: link?
<frankban> rogpeppe: https://codereview.appspot.com/77420043
<frankban> rick_h_: bug 1210035 describes our exact issue
<_mup_> Bug #1210035: event stream from watcher should have logical ordering. <juju-core:Triaged> <juju-gui:Triaged> <https://launchpad.net/bugs/1210035>
<rick_h_> frankban: ah nice
<marco-traveling> rick_h_: is there a way to show icons for non promulgated charms in the gui? Got a demo today
<rick_h_> marco-traveling: no, it's not working yet. There's a bug in it that I've not gotten a chance to look into
 * marco-traveling considers shot-gun promulgation and unpromulgation shortly after
 * marco-traveling reconsiders and wont' be dumb
 * frankban lunches
<bac> rick_h_: 1:1?
<rick_h_> bac: yea, did I join the wrong room?
<bac> no, i'm just joining now
<rick_h_> bac: ah gotcha
<hatch> relocating
<hatch> it's sure quiet out there
<rick_h_> sshhhhh
<rick_h_> frankban: found out 1.17.5 isn't going into trusty due to juju-mongodb breakage. We need to wait/watch for 1.17.6 and sinzui is looking at getting that out asap
<frankban> rick_h_: ack, thanks
<frankban> rick_h_: is Matthew out today?
<rick_h_> frankban: not that I know of, /me looks 
<rick_h_> frankban: not that I know
<frankban> rick_h_: ok thanks
<frankban> rick_h_: I'd be inclined to land https://github.com/juju/juju-gui/pull/186 if the test passes, it's difficult to QA because the bug can be intermittent, but I duped that several times
<rick_h_> frankban: looking
<rick_h_> frankban: k, if you're confident go ahead. 
<frankban> rick_h_: cool
<Makyo> frankban, rick_h_ I wasn't able to dupe when I tried, but the code LGTM.  Sorry frankban 
<rick_h_> Makyo: thanks for the +1
<frankban> Makyo: ack, thanks
<Makyo> jujugui call in 10
<hatch> hm hmm hhmm hhmmm hhhmmm
<bac> benji or rick_h_: could you review my branch when you get a chance?  it's almost 800 lines so maybe two reviews would be good.  https://codereview.appspot.com/78220043/
<bac> note there are reviewer notes, but they only show for patch set 1
<benji> bac: sure; I'll do it after the call
<rick_h_> bac: k, will do. Will be a few I've got a call after the standup and then can look
<bac> thanks
<Makyo> jujugui call in 2
<rick_h_> kadams54: found his way back today? 
<hatch> https://plus.google.com/hangouts/_/72cpiitf46rduhiu3ruoe0jl0c?hl=en
<hatch> ^ rick_h_ 
<kadams54> jujuhelp any volunteers for a pre-implementation chat on https://bugs.launchpad.net/juju-gui/+bug/1269381 ?
<_mup_> Bug #1269381: keybinding for centering canvas is actually S-) <bitesize> <juju-gui:In Progress by kadams54> <https://launchpad.net/bugs/1269381>
<kadams54> Bah
<kadams54> guihelp any volunteers for ^^^
<Makyo> kadams54, sure.
<hatch> relocating
<hatch> man chrome is a power hog
<hatch> who still needs a roomie for the sprint?
<Makyo> I'm free, if you're game again.
<hatch> added!
<rick_h_> ruh roh
<rick_h_> Makyo: will be asking for a new room by Tues night :P
<rick_h_> those canadians 
<Makyo> I'm just curious to see what the topic of late-night research will be this time.
<rick_h_> lol
<Makyo> Last time it was "Which MacBook should I get?"
<hatch> lol
<hatch> that's a whole month away now
<hatch> who knows what's going to happen by then
<hatch> atm I'm trying to find a solution to hosting a bunch of basic websites with having to get a vps with cpanel
<hatch> 'a bunch' being ~5 :)
<Makyo> I use Linode and DreamHost (the latter mostly for a crapload of cheap wordpress sites)
<hatch> yeah that's basically what these are
<hatch> dreamhost hey....
<hatch> $9/mo.....too much :P
<hatch> ohh that is for unlimited domains
<hatch> ok now we are talkin
<hatch> all of these sites maybe get 500 views per month so we aren't talking big load here lol
<rick_h_> s3 
<hatch> views per month....combined :)
<Makyo> Reasonable uptime, cheap, nice enough panel, unlimited DBs/domains/subdomains, django/rails-able... that's about it, granted.  I wouldn't host anything too crazy there. 
<rick_h_> http://docs.aws.amazon.com/AmazonS3/latest/dev/WebsiteHosting.html
<hatch> innnteresting
<Makyo> I'd use S3 for static sites, though.
<rick_h_> or at that rate, put them in github projects and let them host it
<rick_h_> if it's static that is
<hatch> they have real domains though
<Makyo> Well, you can do that with S3 too.
<rick_h_> but yea, I've used s3 for hosting static docs and it's about as cheap as you can get
<Makyo> And GH Pages, for sure.
<rick_h_> and no server maint overhead
<hatch> GH pages doesn't allow real domain names though
<hatch> or do they now?
<rick_h_> s3 does
<Makyo> They do now, I believe.
<Makyo> But yeah, that or S3 for static.  DH for cheap one-offs like WP or ZenPhoto or something, Linode or EC2 for other things.
<hatch> interesting, I'll have a look at both those options 
<hatch> heh yeah S3 does look pretty cheap for static sites
<rick_h_> bac: did you have routes updates for the delete urls? Or am I blind to them atm?
<rick_h_> benji: are you looking into QA on it?
<benji> I am not doing QA.  I can though.
<rick_h_> benji: that'd be great if you get a few min to qa please. 
<benji> rick_h_: sure.  I'll have to be after lunch though (which I am just about to start).  Is that ok bac?
<rick_h_> benji: ty much
<bac> sure benji
<bac> rick_h_: yes, routes.py changed.  do you not see it?
<rick_h_> bac: sorry I do see it. Must have just been blind sorry
<rick_h_> wow, /me rubs eyes
<bac> rick_h_: what do you mean by "The links and bundle warning"?
<rick_h_> bac: sorry, in my other comment I replied to your last minute question on removing charms that a bundle depends on
<rick_h_> bac: so I was saying that a warning in the charm delete confirmation that these bundles will be affected would be cool imo. What did you think? Those could be links to the bundles if you wanted to remove them as well
<bac> rick_h_: oh, ok. that might make a good follow on branch.
<rick_h_> bac: right, that's what I was trying to say poorly
<bac> okey doke
<rick_h_> jujugui the evening AU call will likely be pushed back 30min. If anyone want to join feel free but it'll be after I kick someone out of the house vs right at 6:30
<kadams54> AU call?
<hatch> I'll try and make it
<rick_h_> australia sorry
<hatch> Huw lives in Australia 
<hatch> huwshimi
<rick_h_> kadams54: I'll mention it on our 1-1
<rick_h_> optional call every week
<kadams54> Got it
<kadams54> Getting re-acquainted with YUI here; been 5 years since I last used it. If I have a NodeList, what's the best way to check for a string within each Node.text? myList.each() with a function that sets a found flag?
<hatch> kadams54 5 years...so that would have been YUI2 :)
<kadams54> Yeah
<kadams54> 3 was just on its way out
<kadams54> I read through a lot of the docs and was familiar with the big changes
<kadams54> But never got to write any code with 3
<kadams54> It looked like a really good overhaul
<hatch> list.each(function(node) { if (node.get('text') === 'foo') { ... } });
<hatch> yeah it was a complete rewrite
<kadams54> Yeah, that's my approach; good to know I didn't miss anything in the docs.
<rick_h_> kadams54: in the hangout when you're ready
<hatch> jujugui looking for a review for https://github.com/juju/juju-gui/pull/188 thanks
<hatch> stepping away for lunch
<rick_h_> hatch: when you get back I'll trade you a review for a look at the new urgent maint card please? 
<rick_h_> hatch: seems there's a potential error when using our vagrant image to install quickstart per the quickstart docs. I want to see if it's a doc issue or something we need to fix in quickstart please.
<hatch> rick_h_ back
<hatch> rick_h_ so you are saying the GUI's vagrant image or the Juju one?
<rick_h_> hatch: cool, kadams54 ran into an issue when using quickstart from the vagrant image. You've run the vagrant stuff right?
<rick_h_> hatch: the GUI one, but the idea was that quckstart didn't run per docs in that image
<hatch> yeah but I don't use the GUI's image for anything but the gui
<hatch> I can look into it though
<rick_h_> hatch: and I want to verify if it's something we don't have to worry about because it's vagrant specific, or a real bug to deal with
<hatch> ok, do we have official quickstart docs somewhere I can follow?
<rick_h_> kadams54: can you link hatch the steps you followed please?
<hatch> preferably the steps kadams54 took
<hatch> :)
<rick_h_> jujugui I'm running out to the dentist...biab
<kadams54> hatch: https://launchpad.net/juju-quickstart
<hatch> ahh ok 
<kadams54> Specifically, the part that starts: "To install and start Juju Quickstart, run the following:"
<kadams54> I ran those in a fresh vagrant image.
<kadams54> In the juju-gui code
<hatch> ok and what was the issue?
<hatch> ohh i see
<hatch> it won't run :)
<kadams54> Yeah, it was a python error
<kadams54> Couldn't find a particular class
<kadams54> I can reproduce and get the exact error if needed
<hatch> nope I got it
<hatch> I might have a sollution 
<hatch> just trying now
<hatch> kadams54 ok two things to try
<hatch> `sudo pip install --upgrade urwid`
<hatch> and/or `sudo apt-get install python-dev`
<rick_h_> hatch: yea, that's a bug then. We can't fetch pip urwid to make it work. Or else we need to make sure we don't support the older ubuntu version
 * rick_h_ hasn't left yet...boy is brushing teeth wheeee
<hatch> rick_h_ why can't we? /me doesn't know much about pip
<benji> bac: I'm afraid I have to cut bait on the QA: my charmworld LXC is messed up because of my low-disk condition the other day and I've spend an hour trying to fix it
<hatch> benji sounds like you need a new machine
<hatch> :)
<bac> hatch: shh, he's touchy
<hatch> ohh ok :)
<benji> I need a linux distribution that doesn't want more than 10 gig.
<bac> benji: ok.  i've discovered my bundle featured link is borked.  i'll fix that then land
<bac> benji: RHEL?
<hatch> lol
 * benji installs Puppy Linux
<benji> hmm, if OpenBSD will run virtualbox, I might do that (only half kidding)
<rick_h_> bac: I can try out QA when I get back
<hatch> ssd's aren't that expensive anymore :)
<rick_h_> hatch: because it should apt-get install without extra things
<rick_h_> hatch: can you file a high bug on quickstart and add it to the urgent lane please?
<rick_h_> or use that same card
<hatch> rick_h_ understood, on it
<bac> rick_h_: you want i should wait for your qa?  i'm ok either way.
<Makyo> I can QA, too, in a pinch.
<hatch> rick_h_ bug & card created
<hatch> kadams54 so are you up and running with quickstart now?
<kadams54> No
<hatch> more errors?
<kadams54> Haven't tried it yet
<hatch> ohh hah ok
<kadams54> I'll give it a whirl in a bit and let you know how it goesâ¦
<kadams54> OK, newb question: how to run a single test? I tried just running mocha straight up and got an error about the GlobalConfig object not being defined.
<hatch> oh...yeah
<hatch> sorry our test suite is....odd
<kadams54> lol
<hatch> it.only() vs it()
<hatch> describe.only() vs describe()
<hatch> make test-debug
<hatch> then it'll only run the test with .only
<kadams54> The test I modified is not a .only
<hatch> it will be once you add it :)
<bac> Makyo: if you are still offering, would you mind doing the QA for https://codereview.appspot.com/78220043/ ?  i'd like to get this out of my hair
<Makyo> bac, sure, on it/.
<bac> Makyo: it is charmworld and you'll need to ingest some bundles
<hatch> it.only('this test does something', function() { ... }); for example
<Makyo> Can do.
<hatch> kadams54 if you are running a single test/suite a number of times, it'll be faster to use `make test-server` because the browser will cache the dependencies whereas phantomjs doesn't
<kadams54> OK
<hatch> the url for the test suite in that case is 192.168.33.10:8888/test/index.html
<bac> Makyo: http://paste.ubuntu.com/7126893/ might be a good minimal set that is not too time consuming
<Makyo> bac, should have some already ingested from previous work, but thanks, will do that if not.
<hatch> rick_h_ I looked at huw's branch and it'll be easier for him to fix it in his fork than us try to do it externally so I can help him when he gets him
<hatch> kadams54 if you can't get it we can have a hangout and I can guide you through it
<kadams54> I got it - my test is failing :-)
<hatch> awesome - at least you know it fails :)
<kadams54> Out of curiosity, has anyone looked at getting a test runner like testem or karma working with the code?
<hatch> kadams54 yes but priorities....
<hatch> :(
<kadams54> Yup, I understandâ¦
<hatch> it's very legacy, the suite was setup well before i started
<kadams54> I like that JS test code written in Mocha is "legacy" :-)
<hatch> lol
<hatch> it's over a year old....it's legacy
<hatch> haha
<kadams54> totally
<kadams54> Sometimes the JS world is like that
<hatch> we really want to get code coverage up and running as well
<Makyo> Yes. Good.  https://jujucharms.com/sidebar/search/precise/nyancat-3/?text=nyancat
<Makyo> Just what we needed.
<hatch> Makyo rofl
<kadams54> I only just found out that Grunt is now old school.
<hatch> lol yeah the hype machine moved to Gulp
<Makyo> Scalable cloud-based Nyancat telnet server, ready for EC2 and HP Cloud.
<hatch> kadams54 although I think Gulp and Grunt serve two different purposes....the hype machine don't care :P
<hatch> Makyo somehow it got recommended without an icon *gasp*
<Makyo> Haha
<Makyo> Well, bit of a bug.  Lemme see if I can get it on vine or something.
<hatch> Makyo do you know anything about moving the inspector into the side panel?
<hatch> as in, what happens to the url when we render it in there?
<Makyo> hatch, https://docs.google.com/a/canonical.com/document/d/1QSYjfcAwg54zZMJyGAOo-bqVnnLZJ55dd0UZGMDf9Ig/edit
<Makyo> EG /inspector/apache2/service
<hatch> like a boss
<hatch> oh wait, this card is to update the inspectors to gfit
<hatch> blarg
<hatch> ok nm I get it now
<Makyo> jujugui little silly, but worth mentioning, since it happens at default window height in chrome on a 13" display for me: https://bugs.launchpad.net/juju-gui/+bug/1295341
<_mup_> Bug #1295341: GUI stutters on charm details if window isn't tall enough to scroll very far <juju-gui:New> <https://launchpad.net/bugs/1295341>
<hatch> Makyo "Could not locate object" in u1
<Makyo> Yeah I forgot to make it public, sorry x.x
<Makyo> http://ubuntuone.com/7eJkrPv3NwWJ609FUuoEsA
<Makyo> Edited bug to reflect that.
<Makyo> Nice, it's upside down.
<hatch> lol
<hatch> ok I think I know what's happening there
<hatch> should be easy enough to fix 
<Makyo> Should just be a min-height right?
<hatch> yep
<hatch> (famous last words)
<Makyo> bac, +1
<Makyo> hatch, preferably only if it's already scrolling, though, right?
<bac> Makyo: coolio.  could you add to RV?
<Makyo> Did
<hatch> Makyo well when the header shrinks it then pulls the scroll away so it expands again
<bac> Makyo:  did i ask you about the github os x tool? do you use it?
<Makyo> hatch, oh, right.
<hatch> so either setting the min-height of the content to 'something' or adding to the height when the header gets minimized would work
<Makyo> bac, I've only used the windows one, which was okay!
<Makyo> bac, let me try the osx one, might as well.
<bac> this one looks good.  but i'm afraid it'll just be a crutch.
<bac> but i thought i'd try it since i need to do the vagrant thing
<Makyo> Yeah.  Having learned git on the cli, I found it got in the way more than helped on windows, but that was...a year ago?  Maybe better now
<hatch> I have been trying to use the git/gist plugins in sublime now for my gitting but any real git work still works better in the cli imho
<hatch> benji I can take over for your card
<kadams54> Any particular format for commit messages?
<benji> hatch: cool
<kadams54> Aside from the normal Git conventionsâ¦
<hatch> kadams54 no porn
<kadams54> lol
<Makyo> Pff
<Makyo> kadams54, nah, no format.
<hatch> lol
<Makyo> kadams54, we try to rebase before initial proposal.
<kadams54> Yeah, this ticket only has one commit :-)
<Makyo> Bonus~
<hatch> yes rebasing is the git holy war :) we are firmly on the 'rebase out checkpoint commits into logical commits' camp
<kadams54> Had a similar workflow on the previous job: task branch, rebase to cleanup commits
<hatch> awesome
<Makyo> Yeah.  Don't need to go all out (reduces the need for push -f that way, and leaves comments on old commits)
<hatch> kadams54 I also use a tool called 'grb' but we also have a few aliases in the hacking docs to simplify some things if you prefer
<hatch> rick_h_ probably mentioned this already though
<Makyo> Everything git makes for osx is huge.
<Makyo> Their client is 18MB zipped.
<Makyo> Atom was 110 or something.
<hatch> probably all the HIDPI assets?
<Makyo> Ohhh, right
<hatch> for us elitist retina people
<Makyo> Pff
<kadams54> I'm a big fan of git_remote_branch
<Makyo> Oh, by the way, I still have atom.io and keybase.io keys if anyone's interested.
<hatch> hah suckit people +1 for team grb!
<hatch> :P
<hatch> hmm atom doesn't interest me but keybase does
<Makyo> Email?
<bac> hatch Makyo: git question.  trying to get repo setup on os x.  when i run 'git sync-juju' i get queried for github username/password.  i enter 'bac' and my password but get auth failure.  Q: any idea why? Q: i've got a valid token in my .gitconfig, so why is it asking?
<kadams54> Funny story that I probably shouldn't tell on my second day: shortly after I started my last job, we migrated from SVN to git. One day I was assigned to do some branch cleanup work, so I grabbed grb and started to work.
<hatch> Makyo pm'd
<bac> Makyo: atom.io pls
<hatch> bac you need to have your ssh keys setup
<bac> hatch: done
<Makyo> bac, Are you checking out using https?  Should work with ssh (git@github.com:juju/juju-gui) with ssh keys
<kadams54> I figured that "grb delete" would let me specify which branch I wanted to delete, so I switched out of the soon-to-be-deleted branch and back on to master. Then I ran it.
<kadams54> And deleted master.
<hatch> lol ouch!
<bac> Makyo: i cloned my repo fine.  it is the 'git sync-juju' step
<kadams54> After that, nobody else on the team ever gave grb a try.
<kadams54> ;-)
<hatch> haha
<Makyo> bac, Oh, hmm.  Is your juju remote https maybe?
<Makyo> git remote -v
<kadams54> Fortunately, since it's version control, I was able to revert the branch deletion.
<kadams54> But that's my "screwed production up" story
<bac> Makyo: yes, https
<Makyo> bac, git remote set-url juju git@github.com:juju/juju-gui
<Makyo> bac, invited
<Makyo> Sent it to work address, hope that works
<kadams54> Alright, I'm ready to submit my first pull requestâ¦ I think?
<bac> Makyo: https://pastebin.canonical.com/106892/
<Makyo> bac, oh, sorry.  git remote seturl origin git@github.com:bac/juju-gui.git
<bac> Makyo: that was it, thanks
<bac> Makyo: fwiw, i checked out that repo using the github gui tool.
<Makyo> Oh, boo.  Wonder if there's an option to prefer ssh
<bac> Makyo: no invite yet.  assume it'll arrive eventually.  thanks, though.
<Makyo> Oh, says it's "queued"
<hatch> kadams54 on it
<hatch> btw typically you would say something like "jujugui looking for a review on <link>" :)
<kadams54> Will do
<hatch> kadams54 and now you would move your card into the "Review List" column
<BradCrittenden> Makyo: for atom do you just get two invites or do they refill?
<Makyo> bac, I had three, when I invited you today, so I'm assuming they refill eventually
<hatch> kadams54 review done 
<hatch> so basically what these symbols mean is:
<hatch> :+1: you can land it
<hatch> QA OK qa was ok
<hatch> 'with trivials' means that you can land it with the trivial changes made
<Makyo> Land by using :shipit: in a comment
<hatch> and then of course answer any lagging questions in the review comments
<hatch> I usually rebase my changes back into the stack so I don't have a 'review changes commit' but that's personal preference
<hatch> what's the format of the service config yaml files? is it simply:
<hatch> name
<hatch>     value
<hatch> ?
<bac> hatch: i'm looking at the juju-quickstart /urwid problem
<hatch> oh kay
<bac> hatch: it doesn't seem to affect trusty.
<bac> and i'm unsure what to do for raring.  it is a packaging issue.
<hatch> trusty probably has a more updated version 
<bac> i think we'd have to backport urwid and make a PPA for it
<hatch> ick
<hatch> can quickstart run pip install?
<hatch> well I mean
<hatch> do we want it to
<bac> i think not
<hatch> the odd thing is what I am running quickstart on precise without issue....maybe it's an older version?
<bac> you don't really want to mix ubuntu packages and pip
<hatch> yeah true
<bac> i'm eod, so i'll have a round with fb tomorrow and figure it out
<hatch> bac what about checking the urwid version, if it's too old then not allow -i ?
<bac> s/fb/frankban/
<bac> the PPA solution is probably not hard
<bac> anyway, see you all tomorrow
<hatch> well as long as we can get it into the same juju repo
<hatch> yep have a good one
<hatch> now with everyone EOD'ing so early I want to quit earlier hah
<bac> hatch: well stop sleeping in!
<rick_h_> hatch: hah, you must keep going!
<hatch> haha 
<rick_h_> bac: thanks for looking. Yep I assume it's packaging and we either need to not support an older release or update a ppa to support it
<hatch> I'd much rather prefer the latter
<rick_h_> hatch: yea, have to figure out what options is available
<bac> can't we just update our vagrant to be trusty?  problem solved!
 * bac really gone now
<hatch> rick_h_ btw I took over benji's card, just finishing up the functionality now then to write tests
<rick_h_> bac: :P
<rick_h_> hatch: ok awesome thanks
<rick_h_> hatch: sorry for quiting mid-review of your branch
<rick_h_> I'll try go look here shortly. Past EOD but I've got meetings and interviews tonight so will be in/out
<hatch> heh np - I also took a look at huw's git issues
<hatch> he shoudl be able to fix on his side with `git rebase develop` then rebase his commits
<hatch> but I can guide him through when he gets in
<rick_h_> hatch: awesome, yea if you can help with that I'd love to get htat card cleared so he can move on
<rick_h_> the help delay is hurting on that a bit
<hatch> now to figure out what the yaml format is for service configs
<rick_h_> look at a config.yaml?
<hatch> got it
<hatch> we have a config.yaml?
<hatch> nice
<hatch> lol
<kadams54> hatch: FWIW, I finally got around to trying the fixes you posted and I can now run juju-quickstart successfully.
<kadams54> Had to do both though - got compile errors due to missing Python.h if I didn't have python-dev installed
<rick_h_> kadams54: ugh yea that's what we need to avoid
<rick_h_> that's ok for a dev env, but not for a production instructions
<hatch> kadams54 excellent
<hatch> yeah quickstart probably shouldn't require python-dev :)
<kadams54> That's one hell of a dependency :-)
<kadams54> Hmm, I spoke too soon. I ran into one other error during provisioning:
<kadams54> cp: cannot stat '/usr/lib/locale/locale-archive': No such file or directory; failed to execute template 'ubuntu-cloud'; aborted
<hatch> kadams54 so now that your branch has passed review and qa and CI you can comment with a message with :shipit: in the PR and CI will land it
<hatch> kadams54 are you trying to run lxc in vagrant? 
<kadams54> I suspect so :-)
<hatch> well typically you thank the reviewer(s) (/me bows) and then :shipit:
<rick_h_> hatch: hah!
<hatch> lol
<kadams54> I just went with the default option in the dialog that come up, something about provisioning a new environment
<rick_h_> but he's right
<kadams54> Which I'm guess goes with lxc?
<hatch> kadams54 yeah I don't think vagrant images support lxc - you'll probably have to set up an ec2 account
<rick_h_> hmm, does the vagrant thing support lxc and the like? I'd assume so
<hatch> yeah lxc is not installed in my image
<hatch> but juju is
<rick_h_> hatch: yea, you have to install lxc-local which the latest (blocked) quickstart does
<rick_h_> sorry
<rick_h_> juju-local
<hatch> ^ kadams54 
<kadams54> Shippedâ¦
<rick_h_> kadams54: cool, there should be a follow up comment that it's accepted in a minute
<rick_h_> kadams54: then it takes about 25min in the jenkins ci run to merge
<rick_h_> kadams54: you can follow it at the ci url and should see it get picked up
<kadams54> I looked over some of the closed pull requests to get a feel for how things went.
<kadams54> I'll keep an eye on it
<rick_h_> coolio
<rick_h_> congrats on your first landing!
<kadams54> Always nice to end the day by landing a ticket
<rick_h_> almost...in 25min
<rick_h_> :)
<kadams54> :-)
<rick_h_> kadams54: make sure to move your kanban card and update the bug with 'fix committed' once it merges
<kadams54> Will do
<rick_h_> remember clikcing on the bug number on the card will take you straight there
<kadams54> Taking a break for dinner while I wait on CI
<rick_h_> hmm, why for it not pick it up?
<kadams54> My squirrel's sitting there, looking dapper in his fedora.
<rick_h_> oh!
<rick_h_> you've got to make your membership public!
<hatch> haha
 * rick_h_ goes to look for the button for that
<hatch> oh woops we missed that
<rick_h_> kadams54: yea, it checks you're in the right group to land
<rick_h_> kadams54: but it uses an api that needs to have your org membership public
<hatch> not entirely sure why :shipit: is a squirrel in a fedora but I'm not complaining :)
<kadams54> Hmmâ¦ how do I do that? Not seeing anything on first glace.
<rick_h_> kadams54: https://github.com/orgs/juju/members
<rick_h_> can you see a link in the column by your name?
<kadams54> Alrighty, done.
<hatch> hmm it's shown as public here
<kadams54> No whammie, no whammie, no whammie
<kadams54> hatch: I beat you :-)
<hatch> rick_h_ huw is marked as private
<hatch> hah
<rick_h_> hatch: heh well have to udpate that as well
<rick_h_> hatch: noather thing for you to help with
<rick_h_> :P
<hatch> since i"ll be here ALL ALONE!
<kadams54> Do I need to post another :shipit: comment, or will CI pick up now that I'm publicly a member?
<rick_h_> it should pick it up
<rick_h_> there we go
<rick_h_> it's started
<hatch> there it goes
<rick_h_> sorry for missing that kadams54, first time kinks and all
<hatch> http://www.engadget.com/2014/03/20/facebook-hack-programming-language/?ncid=rss_truncated
<rick_h_> I'm not looking hatch. I've heard and don't want to know more
<hatch> lol
<hatch> apparently the other 100 languages to choose from weren't good enough
<rick_h_> k, family dinner time
<rick_h_> back later for AU calls
<hatch> lata
<kadams54> LOL: "Essentially, this means you theoretically could have access to websites that are faster and more reliable."
<kadams54> All we need to do is sprinkle some Hack magic pixie dust and the site will be faster and more reliable.
<kadams54> Essentially. In theory.
<huwshimi> Morning
<hatch> hey huwshimi 
<hatch> kadams54 hahaha
<hatch> huwshimi I can help you get your git issues straightened out
<hatch> assuming your branch is still the same as your PR
<huwshimi> hatch: Ah great!
<hatch> quick hangout?
<huwshimi> hatch: Sure.
<hatch> ok one sec hangouts is being slow
<hatch> huwshimi https://plus.google.com/hangouts/_/72cpi8ni98evoi6l2vif03kk6c?hl=en
<hatch> huwshimi you can ignore that CI failure email - it was from your previous force push
<hatch> the 'real' one is running now
<hatch> http://ci.jujugui.org:8080/job/juju-gui/583/console
<huwshimi> Ah ok
<huwshimi> hatch: So now commit and rebase before each time I push?
<hatch> well you only need to rebase if the commit isn't one which you would be ok with landing on in a bisect :)
<hatch> the last thing you'd want to do is have to bisect 10 more commits because of lint commits heh
<lazyPower> dont git-blame me!
<hatch> lol lazyPower I don't hink you have comitted to the GUI so you're probably safe
<lazyPower> yeah but i'm all over the other repositories 
 * lazyPower rubs his hands together
<hatch> haha
<hatch> huwshimi if you can ever help it always `git rebase develop` instead of merging develop in (merging in is what causes issues with rebasing)
<huwshimi> hatch: Ah ok, the hacking instructions have been updated to say that now anyway
<huwshimi> rick_h_: Are we having a GUI call now?
<rick_h_> huwshimi: sorry, told everyone else but you wren't there I guess
<rick_h_> huwshimi: yes, starting up now
<rick_h_> hatch: if you want to join in there as well, up to you
<rick_h_> yay kadams54 thing landed
<kadams54> Yeah, I saw. Hoping on to update the board and ticket.
<kadams54> Hopping even.
<rick_h_> hop hop
<rick_h_> darn, huwshimi ran off. Ooops
<huwshimi> rick_h_: I'm here
<rick_h_> huwshimi: oh hey, I'm in the call now :) sorry I told everyone in the stand up it'd be late but...missed you there
<huwshimi> rick_h_: Oh, I guess we're joining the link in the calendar :)
 * rick_h_ has to get used to that
<hatch> ok joining
<rick_h_> huwshimi: yes please
<hatch> huwshimi https://github.com/orgs/juju/members
<rick_h_> hatch: where's the quickstart card?
<hatch> bac is working on it
<hatch> he has it in coding
<hatch> huwshimi looks like your last push passed CI
<huwshimi> hatch: Yay!
<huwshimi> Merging!
<hatch> :shipit:
<hatch> oops
<hatch> ur not supposed to do that :)
<huwshimi> I'm not supposed to do what?
<hatch> to merge you should type :shipit: in a comment and then CI will land it for you
<hatch> clicking the merge button skips the final CI run
<hatch> not a huge deal in this case because there are no other pending merges
<huwshimi> Oh
<huwshimi> DON'T PRESS THE GIANT GREEN BUTTON
<hatch> lol exactly
<hatch> apparently we can't turn it off
<hatch> unfortunately
<huwshimi> That can't possibly be the correct thing to do!
<hatch> lol
<hatch> yeah it's not a huge issue in this case, but the CI queues up branches so that they land in order and have the tests run in order
<hatch> so if there was another branch in the queue then it could have broken something
<hatch> possibly
<hatch> :)
#juju-gui 2014-03-21
 * hazmat looks at charmworld indexing code..
<rick_h_> hazmat: run away! :)
<rick_h_> hazmat: what's the issue?
<hazmat> rick_h_, just curious about the mapping explosion you mentioned
<hazmat> rick_h_, that's not normal
<rick_h_> hazmat: yea, it's hard to debug without knowing what all went on during them bringing up the new ES instance and how they tried to correct it
<hazmat> also just getting familiar with the latest code version, it looks better
<rick_h_> hazmat: it's still a 'theory' on that's the issue
<rick_h_> yea, spent some time cleaning things. Learning more about ES, getting ES to do better scoring, filtering on scoring, etc. 
<rick_h_> stuff we should have spent the time to get into ages ago
<hazmat> rick_h_, how much pain would it be to tighten up results on search api... 184k for 20 results.. on charms.. ie. not serialize every charm on a result, but instead have the gui fetch details beyond collections.
<hazmat> not needed.. just curious.. 
<rick_h_> hazmat: not sure, it's on the todo list to look at. Bundles are painful in results right now and it's getting to be something we want to address
<rick_h_> hazmat: just looking I bet 90% of that is changelogs and config options. Wonder if we can lazy fetch those and still get that nice instant load when clicking a charm (though there's a know bug #1290580)
<_mup_> Bug #1290580: Viewing charm details makes another request even though it should be cached <juju-gui:New> <https://launchpad.net/bugs/1290580>
<rick_h_> hazmat: so I'd say we could cut it down a big chunk easily
 * rick_h_ runs away for the night
<rogpeppe> frankban: reviewed https://codereview.appspot.com/77420043/
<rogpeppe> frankban: sorry it took a while
<frankban> rogpeppe: thanks!, looking at your review, looking at it. I am not sure about "won't m.SupportedContainers still be the expected (nil) value if SupportedContainersKnown is false?"
<frankban> rogpeppe: the idea is: supported unknown -> nil, supported known -> [] or [lxc] ... it seems to work like this
<rogpeppe> frankban: hmm, i think it would probably be better not to rely on nil vs [] like that
<rogpeppe> frankban: and to expose SupportedContainersKnown in the allwatcher
<frankban> rogpeppe: ok, I'll make this change, so basically I'll just add bith fields in the initial structure
<rogpeppe> frankban: thanks
<frankban> rogpeppe: re jobs I fugured out we would need it to know where it is possible to host units, so, if I am not missing something, I'd be inclined to keep that included
<rogpeppe> frankban: yeah, and when we've got HA, it will be useful to know which machines are state servers, i think
<frankban> rogpeppe: that's something we also need to pass in the addMachines API, so it's not completely internal, yeah, and for HA too
<frankban> cool
<frankban> oh, totally missed params.Alive. cool
<frankban> fwereade: morning, I am working on a branch which adds more fields to the mega-watcher for machines. One of those fields is Jobs: it seems good to have since with that the GUI can safely know where it is possible to host units, and it can be valuable also from the HA perspective. It is also something we already need to handle when using the addMachines API. How does it sound?
<frankban> rogpeppe: re machineJobsFromParams, I guess you intended paramsFromMachineJobs, right?
<rogpeppe> frankban: perhaps paramsJobsFromJobs ?
<frankban> rogpeppe: ok
<fwereade> frankban, I think +1 to that, but I have a minor concern which is drift between the gui and the cli -- would you add them to the status API as well, please?
<frankban> fwereade: sure, if you agree I'll create another card, so that the current one can land and we are unblocked
<fwereade> frankban, that's great, thanks
<frankban> fwereade: cool thank you
<frankban> fwereade, rogpeppe: after merging from trunk, I am encountering "launchpad.net/juju-core/testing/testbase.PatchEnvPathPrepend(0): not defined" and similar when testing juju-core
<frankban> also testbase.Restorer(0) is not defined
<rogpeppe> frankban: have you updated your dependencies?
<rogpeppe> frankban: (in the juju-core root, run godeps -u dependencies.tsv)
<frankban> rogpeppe: this is after running godeps -u dependencies.tsv
<frankban> yeah
<rogpeppe> frankban: what's the actual compiler output?
<frankban> rogpeppe: core compiles well, and the when I launch tests I see this -> http://pastebin.ubuntu.com/7129851/
<frankban> (also in trunk)
<rogpeppe> frankban: that's odd - there are no file:line messages
<rogpeppe> frankban: if you cd to cloudinit and run go test, what do you see
<rogpeppe> ?
<frankban> rogpeppe: it seems I fixed this by removing pkg/linux_amd64/
<rogpeppe> frankban: ah
<rogpeppe> frankban: that can happen
<frankban> rogpeppe: yeah, thank you
<frankban> fwereade: IIUC, the cli status structure is in cmd/juju/machineStatus. is this correct? If so, since MachineInfo will also include SupportedContainers and SupportedContainersKnown, do you want those to be included there too?
 * fwereade reads code
<fwereade> frankban, hmm, so the deal with supportedcontainers is as follows
<fwereade> frankban, we don't know what containers can be added until we've actually got a machine agent running, and able to check
<fwereade> frankban, so to begin with we have the list empty, and known false, and we just let you do whatever you like
<fwereade> frankban, and any bad requests will fail at provisioning time
<fwereade> frankban, later we set known to true, and at the point the supportedcontainers list is actually accurate
<frankban> fwereade: yeah I figured that out
<fwereade> frankban, *just* exposing those 2 fields doesn't seem like an ideal way of informing users though
<fwereade> frankban, sorry, I had to remind myself :)
<frankban> fwereade: np, thanks for making that explicit
<fwereade> frankban, oh hell standup
<frankban> fwereade: so in theory, for `juju status`, we could only show supported containers after they are known
<fwereade> frankban, you know what? don't worry about CLI status, but please file a bug against juju-core and we'll figure out priority and appropriate response
<fwereade> frankban, status is bloated enough already
<fwereade> frankban, at some stage we'll get around to adding flags to filter fields
<fwereade> frankban, but just adding them willy-nilly isn't such a great idea
<frankban> fwereade: sounds good, thanks
<frankban> agreed
<frankban> rogpeppe: branch updated and re-proposed
<rick_h_> frankban: if you get a minute can you review hatch's branch here please? https://github.com/juju/juju-gui/pull/188
<rick_h_> frankban: I started but got pulled away yesterday. Figure I'll trade you a review :)
<frankban> rick_h_: sure, will do
<rogpeppe> frankban: LGTM
<frankban> rogpeppe: \o/ thanks, approving
<bac> hi frankban, did you see the issue about quickstart on raring wrt urwid?
<frankban> bac: no, but it would not work in raring, apparently we do not support raring, it is disabled in the juju stable PPA, so there is no urwid backport for raring in there. I presume an old urwid would be used resulting in a nice python crash. 
<bac> frankban: you are correct
<bac> frankban: so do we state somewhere that raring is not supported?
<rick_h_> frankban: ok if we don't support it then I'm game for documenting and doing whatever we can to prevent installing it
<frankban> bac: to be clear, the package works on precise, quantal, saucy and trusty -> the juju stable PPA includes urwid backports for precise and quantal. saucy and trusty already have the right urwid version
<bac> frankban: https://launchpad.net/~juju/+archive/stable/+packages shows that we have a juju-quickstart PPA for raring
<bac> frankban: so, i guess we either need to delete it or supply the urwid backport, no?
<frankban> bac, rick_h_: requested deletion of juju-quickstart 1.0.0+bzr48+ppa10~ubuntu13.04.1
<frankban> that's also an old version
<bac> rick_h_, frankban: perhaps i should take my head off the card and let frankban pict it up.
<rick_h_> bac: fine with me. I just want to see what we can do to prevent new users (kadams in this case) from following the docs but not having things work. 
<frankban> bac, rick_h_: ok, that's done. bac: you could also complete the card just adding that piece of documentation
<bac> frankban: ok, sure.  to the quickstart readme you mean?
<bac> rick_h_: but we are in a bit of a pickle since our juju-gui vagrant image is only raring
<kadams54> Seems like we should also update the vagrant image in juju-gui?
<kadams54> bac: hah, yeahâ¦ beat me to it.
 * rick_h_ goes to check, is raring EOL?
<frankban> rick_h_: since I deleted the PPA package, the docs would not work at all (juju-quickstart package not found) if you are in raring. 
<frankban> bac: let me check
<rick_h_> frankban: bac ok sorry, yes raring is EOL and so I think updating the vagrant image is ok
<bac> rick_h_: ok, i'll do that too under this card
<frankban> bac: yeah, README.rst and the quickstart description in launchpad seem the right places to put that information. It would be nice to have both pip and apt-get instructions added to those. Note that README.rst is also used to display the nice description in https://pypi.python.org/pypi/juju-quickstart
<bac> frankban: it seems odd that we're supporting quantal but not raring.  should we remove support for quantal leaving precise (LTS), saucy (current) and trusty (beta) ?
<bac> that's a more consistent story
<frankban> bac: +1 quantal and not raring is weird, let's document the new story and I'll exclude quantal in my next build. I guess I'll leave the current quantal release in the stable PPA, but updates will be only precise/saucy/trusty. how does it sound?
<bac> perfect
<frankban> cool bac thanks
<bac> frankban: if quickstart is installed via pip should we tell them to use:
<bac> sudo pip install urwid juju-quickstart
<bac> ?
<frankban> pip install juju-quickstart should be sufficient
<bac> cool
<frankban> bac: see comments in requirements.pip
<frankban> bac: also, in trusty installing the PPA is not required
<bac> frankban: right, just for precise
<frankban> bac: precise and saucy
<bac> er?
<bac> oh, right
<frankban> is github having difficulties also in the US?
<hatch> frankban "see below" in your review.....did you forget to hit send on a comment? :)
<frankban> hatch: no, I did not forget, github is down here :-/
<hatch> ohh darn ok
<hatch> no problem
<bac> frankban: can you look at the doc change at https://codereview.appspot.com/78830044 ?
<frankban> and now it's up again, they finished to recompile rubu
<frankban> ruby even
<frankban> bac: sure
<frankban> bac: done
<bac> frankban: double spaces don't get a <shrug>? :)
<frankban> bac: :-) double spaces are serious things to deal with
<bac> agreed and done
<bac> rick_h_: were you aware there are 85 members of ~charmers?  80 of them are in ~inactive-charmers.  i'm a little surprised about the numbers.
<rick_h_> bac: yea, there's some discussion on how to clean that up at some point
<bac> rm ~inactive-charmers
<bac> or create an ~active-charmers and use that group for permissions
<rick_h_> bac: yea I recall an email thread where marcoceppi had a good reason for not doing that
<marcoceppi> bac: I once removed in-active charmers from charmers
<marcoceppi> and I got yelled at
<marcoceppi> My goal is to get them seperated one day, I just don't have the time for it
<rick_h_> bac: https://pastebin.canonical.com/106930/
<rick_h_> is the end of the thread that I found
<rick_h_> bac: so know issue and discussion taking place but not a great solution atm to just remove inactives
<frankban> fwereade: filed bug 1295682
<_mup_> Bug #1295682: Handle missing fields in CLI status <juju-core:New> <https://launchpad.net/bugs/1295682>
<frankban> hatch: I'll finish your review after the call, grabbing some food now, ok?
 * marcoceppi should get back on that thread and get some action items going
<fwereade> frankban, thanks
 * frankban lunches
<bac> rick_h_: fyi, i found a bug on staging regarding bundle featuring.  should be a trivial fix.  made card.
<hatch> frankban yeah no problem
<bac> marcoceppi: we've added UI on staging.charmworld.com for deleting charms and deleting and featuring bundles.  it'll probably be released to production next week but thought you might want to see it on staging first.
<bac> jcastro: ^^
<rick_h_> bac: cool thanks for the heads up
<hatch> so hows everyones morning
<jcastro> bac, that is awesome, thanks!
<rick_h_> jcastro: marcoceppi realize this deletes it from charmworld, but not launchpad/etc. So it will just reingest if you hit delete
<jcastro> all I really need is the ability to feature/unfeature bundles
<rick_h_> jcastro: yea, that's there as well
<bac> jcastro: you can feature/unfeature bundles if they are owned by ~charmers
<rick_h_> bac: yea, he just means the links for his use
<rick_h_> generating urls isn't much fun :)
<bac> i don't understand
<rick_h_> bac: production doens't have the feature/unfeature links
<rick_h_> bac: jcastro misses those, but you've added them on staging
<bac> rick_h_: you saw that i declined the interview for next week
<rick_h_> bac: yes, my fault. Wasn't thinking about your time away
<bac> rick_h_: patience
<rick_h_> bac: right, just letting him know that's on staging as well
<jcastro> that's fine, I only needed them for the announcement last week, so mangling is fine
<jcastro> It's not like I'll be featuring and unfeaturing new stuff
<bac> yeah, sorry we didn't get them done earlier
<rick_h_> jujugui call in 10 please kanban
<frankban> hatch: review done, I decided lunch can wait, sorry for the stream of consciousness
<hatch> haha np - I appear to be having internet issues as well
<hatch> hopefully they are back up
<bac> frankban: quickstart works on vagrant now, but it is a bit ugly.  https://dl.dropboxusercontent.com/u/420990/jjqs-vagrant.png
<rick_h_> woot
<bac> rick likes ugly
<hatch> lol it's not that ugly in iterm....must be a terminal thing
<hatch> linux people like ugly
<hatch> :P
<rick_h_> hatch: pssst you're a linux person now
<bac> hatch: we keep you around
<rick_h_> welcome to the party
<hatch> yeah but my desire for uglyness hasn't hit yet
<bac> now you ran off luca
<hatch> haha
<frankban> bac: vargrant box locale issue?
<hatch> frankban thanks for the suggestions I'll have to put some thought into those
<bac> am i in the wrong place?
<rick_h_> bac: https://plus.google.com/hangouts/_/calendar/cmljay5oYXJkaW5nQGNhbm9uaWNhbC5jb20.t3m5giuddiv9epub48d9skdaso
<frankban> bac: vagrant local issue?
<frankban> locale
<bac> ah, so we use the regular spot everyday but friday?
<bac> rick_h_: for the record, i'm not relying on vagrant.  just spun it up for testing.  may do so in the future if i decide i like atom, github gui, etc.
<kadams54> Oh, speaking of atomâ¦ who had the invites? And are there more?
<rick_h_> bac: ok cool. Yea it just seems to be getting some uptick in dev use so figured we should treat it as a bit more important. 
<rick_h_> kadams54: I think Makyo had one at some point
<rick_h_> if you need one post to twitter and I can RT you. I know a bunch of folks on there have them 
<Makyo> kadams54, sure, email?
<rick_h_> luca__: meet kadams54, he's tinering with some of your UI bugs and might come bugging for info/assets at some point
 * frankban bbiab
<hatch> I was less than impressed with atom - felt like an incomplete and slow sublime text
<hatch> I suppose that's what they are going for
<Makyo> It's in alpha :P
<Makyo> Or I guess beta now that they've got invites.
<hatch> right, but haven't they been at it since 08?
<hatch> :)
<luca__> rick_h_: I'm doing user testing at the moment, will say hi over a call in a bit
<luca__> kadams54: Hi!
<rick_h_> luca__: all good just wanted you to recognize the irc nick 
<kadams54> luca__: Hi!
<hatch> I'm just gona go to Wendy's....
<rick_h_> hatch: not a good plan...not a good plan at all
<hatch> lol
<kadams54> Better than White Castle.
<kadams54> ;-)
<hatch> we don't have White Castle here unfortunately
<hatch> fortunately? 
<hatch> heh
<bac> hatch, Makyo: the change to use NFS on vagrant was easy-peasy for os x.  testing on ubuntu host now.
<bac> did require 'sudo touch /etc/exports'
<kadams54> bac: good the hear
<hatch> bac awesomer
<Makyo> Oh, rock on.
<bac> kadams54: git is already installed on the guest.  but when you brought vagrant up it wasn't there?
<hatch> faster lint and test runs here we come
<rick_h_> hatch: *cough*native*cough*
<hatch> rick_h_ hey I tried - I blame whomever writes the kernel :P
<hatch> I'd be rocking trusty by now
<Makyo> It's in the provision script, at least.
<rick_h_> hah, not whoever bought the laptop?
<Makyo> Haha
<kadams54> bac: I was seeing "command not found" errors for it when running makefile stuffâ¦ which went away after running "sudo apt-get install git"
<kadams54> But it's entirely possible I made a newbie mistake
<hatch> well MAYBE someone else should produce quality hardware?
<bac> Makyo: currently /vagrant is only the juju-gui directory.  it might be nice to make it '..' instead so you could have access to other software you may be working on
<bac> hatch: rule of thumb, if you want your laptop to work with ubuntu natively, buy whatever hardware pitti runs.
<hatch> hmm
<kadams54> lol
<bac> cannot go wrong
<hatch> haha 
<Makyo> bac, That presupposes a certain directory structure, but if we're aiming to make the vagrant more universal for quickstart and the like, that could be nice.
<bac> Makyo: well, it does make a bit of an assumption.  it assumes your juju-gui is contained within '..'  -- if you happen to put other stuff there, all the better.  :)
<kadams54> Mayko: As long as it's in the provision scriptâ¦ I had a similar problem where node wasn't found, even though it's also in the provision script. Very possible for this to be PIBKAC.
<hatch> PEBKAC looks better
<hatch> :P
<hatch> E = exists 
<kadams54> :-)
<hatch> kadams54 I actually use git in osx not in vagrant
<bac> kadams54: i haven't tried making yet on my new image.  let me try before we blame the new guy.  :
<Makyo> bac, yeah, sounds good.  I just use juju-gui/work as a relic from bzr
<hatch> I do ~/canonical/<project>
<bac> Makyo: i'm sure we can work out something that suits us all.  worthy goal, i'd think
<Makyo> bac, yep, sounds good.  I'm just behind, is all.
<kadams54> hatch: as do I, but I saw the errors when running "make devel" in the image
<hatch> ohh interesting...
<kadams54> ~/Code/project
<Makyo> hatch, yeah, ~/work/<project>/, but bzr projects are ~/work/<project>/<bzr branches by user>, and work is the lightweight checkout of whatever I'm working on.
<hatch> I've been thinking of doing that structure - I need to come up with a good one for my $GOPATH
<bac> well, heck, why don't we just mount $HOME as /vagrant?
<bac> not being smarty...
<kadams54> I think it's worth playing around withâ¦ no rule we can't change it back :-)
<bac> ok, kadams54, in my shiny new vagrant instance i just ran make devel with no intervention and it worked.
<kadams54> bac: yeah, same here. Not sure what happened yesterday.
<bac> ok, call it a non-issue until it appears again
<kadams54> Also "which git" shows it installed.
<hatch> bac honestly that's not such a bad idea
<hatch> +1
 * bac tries
<kadams54> guihelp I'm ready for another pre-implementation chat on bug 1290312
<hatch> bug #1290312
<Makyo> _mup_, you okay buddy?
<hatch> oh c'mon mup what ya doin
<Makyo> https://bugs.launchpad.net/juju-gui/+bug/1290312 _mup_ 
<Makyo> Oh well.
<hatch> kadams54 I'm getting up to speed on the card
<Makyo> kadams54, I recommend splitting 3 into its own card
<kadams54> Separate card, separate ticket as well?
<hatch> single ticket is fine imho
<Makyo> Yeah, leave the ticket intact, just have separate cards for units of work.
<kadams54> k
<hatch> https://plus.google.com/hangouts/_/72cpikq3qfse972qd7v4npvkuo?authuser=1&hl=en
<hatch> ^ kadams54 
<Makyo> Should be able to do 1 & 2 today, not have to leave 3 hanging
<hatch> luca__ ping?
<luca__> hatch: not avail at the moment, I'm in user testing
<rick_h_> hatch: something I can help with?
<hatch> ok ping when you are, kadams54 just needs a garbage can asset
<rick_h_> kadams54: hatch please email luca and copy spencer on it for the need. And just use a place holder of something else for the moment to move the branch forward. 
<hatch> rick_h_ yup going to use a placeholder for now
<hatch> I'll send the email 
<kadams54> thanks
<hatch> kadams54 can you ping me your canonical email, it's not in my directory for whatever reason
 * rick_h_ goes to locate lunchables
<hatch> quality lunch right there
<hatch> I think I'm going to alias `ssh vagrant` to `vagrant ssh` :/
<hatch> http://venturebeat.com/2014/03/20/docker-delivers-its-first-commercial-service-since-its-big-pivot-last-year/
<hatch> kadams54 you should have received the trash can asset
<kadams54> hatch: confirmed
<kadams54> Going to run some lunch errands - bbiab
<hatch> we need a 'willBeCalled' assertion :)
<hatch> assert.willbeCalled(myFunction);
<hatch> would save from writing a setinterval
<rick_h_> hatch: would need to be like assertCalledWith? 
<rick_h_> hatch: ugh, can't we avoid that by direct calls?
<hatch> the test I'm doing now requires the inspector 'save' button to be clicked, then wait for the env method to be called
<hatch> so it's async and needs to poll until the stubMethod.calledOnce() returns true
<hatch> I'm trying to avoid that
<hatch> I don't see anyway around it
<rick_h_> hatch: so the around would be to split the tests. Something you're doing start a process to get to the env?
<hatch> a really fast setInterval shouldn't be an issue though....it can poll every 10ms or something
<rick_h_> hatch: and then you want something that verifies if that call is made, the env does the right thing
<hatch> right but this needs an integration test (thats why this was missed last time)
<rick_h_> so you test each end of the middle man, and skip the async in the middle
<rick_h_> ah
<hatch> I'm going to do a setInterval then in review if anyone can come up with something better I'm all for it
<rick_h_> hatch: :)
<frankban> hatch: what about mocking the env method, putting the assertions in there and then calling done?
<hatch> frankban, u win the internets
 * hatch switches to old-school mocking
<frankban> :-)
<hatch> wow I can't believe I didn't think of that
 * hatch bows head in shame
<rick_h_> yea, it's rare you can't work around a setInterval type thing. If you can't usually there's something bigger to look at. 
<rick_h_> frankban: ftw :)
<rick_h_> frankban: shouldn't you be off enjoying your weekend by now? 
 * hatch is glad he isnt' gone yet haha
<frankban> rick_h_: no, I usually stop at 6pm UTC, 7pm here
<rick_h_> frankban: ah, gotcha
<rick_h_> frankban: oh, with that time switch you moved an hour on me. 
<rick_h_> and ouch that's late anyway
<frankban> rick_h_: yeah but I like starting later in the morning, and this way there is more overlap with US timezones
<rick_h_> frankban: cool, it is nice on that end. 
<hatch> I wonder if someones job could be to write tests
<hatch> there is clearly an advantage for the code author to write the tests
<rick_h_> well there are test engineers
<hatch> but there may be an advantage of someone who doesn't know the code to write the tests
<hatch> because they see the hard 'corners'
<rick_h_> hatch: I'm not sure, too often bad/hard to write tests are signs the author is barking up the wrong tree
<rick_h_> hatch: to implement the feature and not get that feedback until done would be painful and lots of rewriting
<hatch> true true
<rick_h_> and that's a LONG way from TDD
<rick_h_> :)
<hatch> lol
<hatch> yeah just thinking outlou
<hatch> d
<rick_h_> yep, same here 
<rick_h_> I do wonder what 'test engineers' really do now that you mention it
<hatch> maybe they do the exact opposite of TDD :)
<hatch> CDT
<hatch> code driven tests
<rick_h_> that would be a sucky job, to be handed code and "make the tests that make this code be valid"
<hatch> lol
<hatch> rick_h_ maybe they write tests to match the spec and then the code needs to match that
<hatch> I know in big enterprise apps people write class specs *yuck*
<kadams54> We had a test engineer for awhileâ¦
<kadams54> They mostly focus on functional testing
<rick_h_> there you go hatch, make your full time job selenium work...in python :P
<hatch> kadams54 how did they know what the function was supposed to return?
<hatch> jujugui I need a review/qa on https://github.com/juju/juju-gui/pull/191 plz and thanks
<hatch> rick_h_ lol noooooo thanks
<kadams54> hatch: that's too low level - they worked more on the "you're supposed to click here and the app will do X, Y Z" level
<rick_h_> kadams54: have bandwidth to peek at it as a first review? I'll also go through it as well. 
<hatch> ohhh
<kadams54> Selenium, CasperJS, WebTestâ¦ on that level
<hatch> ahh gotcha
<kadams54> rick_h_: sure
<kadams54> hatch: you get to be my review guinea pig :-)
<hatch> haha, giver! When it comes to QA I can guide you through pulling down the branch
<hatch> it's pretty easy
<kadams54> I just setup my git aliases this morning :-)
<bac> git folk, i accidentally did all of my work in develop -- forgot to create a new branch -- and have pushed it up to github.  how do i unwind and do it right?
<hatch> bac heh oops :)
<rick_h_> bac: take your develop, and create a branch from it
<kadams54> git revert <hash>
<rick_h_> git co -b my-workd
<hatch> I'd cherrypick
<rick_h_> and then push that up as a new branch
<hatch> or that
<rick_h_> git push origin mybranch:mybranch
<rick_h_> and then pull request from that
<hatch> lol there are so many ways....I like rick's approach though
<kadams54> `git revert <hash>` will remove it from develop
<bac> ok
<rick_h_> and then go back to develeop and remove it per kadams54 
<hatch> weeeeee
<rick_h_> but do the new branch first so you don't lose work
<kadams54> +1
<kadams54> hatch: what's this about ghost inspector and service inspector?
<hatch> kadams54 pre-deployment = ghost inspector post deployment = service inspector
<hatch> (legacy talk) the icons used to be ghosted
<kadams54> Ah, got it
<hatch> frankban did you want to have a call about your comments - I think some are handled already by this structure but would like to discuss further than some github comments :)
<frankban> hatch: sure
<hatch> https://plus.google.com/hangouts/_/72cpi2tcd0t3a61utkp6p1g32s?authuser=1&hl=en
<bac> hey rick_h_, when i try to rebase i get https://pastebin.canonical.com/106946/
<bac> i already pushed to github, so i need to get it rebased and push with --force?
<rick_h_> bac looking
<bac> rick_h_: and my branch now looks like https://pastebin.canonical.com/106948/
<rick_h_> bac: because you branched from develop there's nothing to rebase on there
<bac> ah
<rick_h_> bac: right you branched after you did the revert
<rick_h_> bac: as I mentioned, do the branch first, then remove the commit on develop
<bac> will that create another revert checkin?
<bac> is there no equivalent of 'bzr uncommit; bzr revert'?
<rick_h_> bac: which commit do you want to keep?
<rick_h_> bac: which commit(s) need to end up in trunk?
<bac> in vagrant-fixes i want the older three.  the revert was a mistake
<bac> so, i'd like a clean develop, and those three commits in my branch squashed into one
<rick_h_> bac k sec
<hatch> kadams54 hmm looking at your qa failure
<rick_h_> bac: https://pastebin.canonical.com/106949/ 
<rick_h_> bac: that should get you going
<hatch> kadams54 hmm I can reproduce....looking
<hatch> thanks
<rick_h_> bac: obviously untested, let me know if you hit an issue
<hatch> kadams54 ohh right - woops this is a limitation of the fakebackend
<hatch> I'll reply in the PR
<hazmat> how do you search charm by series?
<hazmat> in the gui, or directly against the charmworld api
<hazmat> attempting to use api versions that used to support this.. gets unsupported api version
<hatch> I think that functionality was removed
<bac> rick_h_: ok, that should work but i'll commit to trunk with no rebase
<rick_h_> hazmat: you don't in the gui. http://manage.jujucharms.com/api/3/search/?text=mysql&series=precise in charmworld
<rick_h_> http://manage.jujucharms.com/api/3/search/?text=&series=precise for all precise for instance
<rick_h_> hmm, might need to flip the limit off 
<hazmat> rick_h_, any keyword to type that into manage.jujucharms.com html search box?
<rick_h_> http://manage.jujucharms.com/api/3/search/?text=charm&series=precise looks better
<hazmat> rick_h_, http://manage.jujucharms.com/api/3/search/?series=saucy ?
<rick_h_> hazmat: no, filters were removed and the idea of supported 'tags' isn't designed/done
<rick_h_> hazmat: trying http://manage.jujucharms.com/api/3/search/?text=charm&series=saucy 
<rick_h_> hazmat: so yea, no saucy
<hazmat> rick_h_, try any non precise series..
<rick_h_> http://manage.jujucharms.com/api/3/search/?text=charm&series=oneiric shows some
<bac> juju-gui / makyo: review request https://github.com/juju/juju-gui/pull/192
<hazmat> rick_h_, they are there.
 * hazmat gives up.. and uses launchpad
<hazmat> rick_h_, that does work btw.. http://manage.jujucharms.com/api/3/search/?series=quantal
<hazmat> rick_h_, the problem is there is no saucy series for the charms distro 
<rick_h_> hazmat: right, but limited to 20 matches unless you add text=charm to get all results
<hazmat> in lp
<hatch> bac it's juju-gui without the - :)
<bac> hatch: nfm
<rick_h_> hazmat: so yea, I get results for quantal, oneiric, no saucy
<hatch> love that you added nfs support :)
<hatch> kadams54 do you have a ec2 juju credentials set up yet?
<bac> hatch: it solved your problem and the saucy problem
<bac> made sense
<hatch> like a boss 
<hatch> :-)
<hatch> odd quickstart error https://gist.github.com/hatched/ab4431b789e67a0f7ef8
<hatch> bac I can qa your branch a little later - running with parallels right now so I don't want a kernel panic :)
<hatch> unless someone else gets to it first
<hatch> :)
<rick_h_> hatch: calls and calls, not getting to the review atm. If you can find someone else awesome else I'll get at it eventually
<hatch> rick_h_ re my branch that frankban did?
<rick_h_> hatch: no, the one that kadams54 looked at
<rick_h_> I was going to double review you, until everone else wanted to talk to me first
<hatch> ohh ok yeah I'm just qa'ing in a real env to confirm that the issue is a fakebackend limitation
<hatch> I'm pretty confident but I want to be sure
<hatch> oh and we NEEED to talk about my other branch.....:P jk whenever you have time I'll fill you in on what frankban and I discussed
<rick_h_> hatch: heh, well I figure kadams might let you sneak by something crazy since he's not up on all the linting/history stuff
<hatch> lol
 * hatch goes and changes all his short var names
<rick_h_> see I knew it!
<kadams54> lol
<kadams54> hatch: no, no ec2 credentials (at least not that I know of)
<hatch> we just use our own then expense it
<hatch> well...usually the bills are like $2 so it's not worth it
<hatch> lol
<kadams54> OK, in the process of signing up right now
<hatch> https://juju.ubuntu.com/docs/config-aws.html
<hatch>  or use `juju-quickstart -i` :)
<kadams54> Hah
<hatch> lunching
<kadams54> Change of location
<hatch> bak
<bac> jujugui: i'm trying to QA my vagrant changes with an ubuntu host but having a hard time getting virtualbox installed.  if someone else with a pre-configured machine could try it i'd be grateful.
<bac> is that a 'bac ack'
<hatch> lol
<hatch> bac I can qa it now
<bac> thanks hazmat
<bac> s/hazmat/hatch/
<hatch> mounting works - I need to try with saucy now so that'll take a bit
<hatch> blarg it keeps picking up my existing vm
<hatch> gona need to delete it I guess
<hatch> doooownloading 
 * hatch needs faster internet
<hatch> 600KBps is just not cutting it
<hatch> jcastro have you seen that codinghorror.com has switched to using discourse for comments? It's a pretty cool idea, forces people to go elsewhere to -make- the comment but it's still shown in the article
<hatch> ex) http://blog.codinghorror.com/please-read-the-comments/
<jcastro> yeah we use that on insights.ubuntu.com
<hatch> ohhh I thought it was just a link, I didn't know it also reported the comments back to the main thread
<hatch> is insights a ghost blog?
<jcastro> no, wordpress
<hatch> ohh ok, he said his was a ghost blog so just curious
<hatch> it's a pretty cool idea - hopefully help to trim out some of the idiots
<rick_h_> hatch: did we need to chat?
<hatch> we did!
<hatch> vewwwy impotant
<rick_h_> hatch: ok, your up then
<rick_h_> shoot me a link please
<hatch> on it
<rick_h_> or just shoot me :P
<hatch> lol
<hatch> https://plus.google.com/hangouts/_/72cpi1j10275vvu1nppqkc6tnc?authuser=1&hl=en
<rick_h_> oops, check you later hatch :)
<hatch> lol
<hatch> cya
<rick_h_> note to self, don't drop your hand on the keyboard when the cursor is on the disconnect button
<rick_h_> you will rudely run away 
<hatch> bac still around?
<rick_h_> hatch: +1 on the config button branch thanks
<bac> hatch: yep
<hatch> bac :+1: 
<hatch> :) it's awesome
<hatch> so friggen fast
<bac> hatch: could you actually do the review too?
<hatch> I did
<bac> oh, cool.
<hatch> that's what the :+1: is
<hatch> QA OK is the qa being ok :D
<hatch> I had no comments re the code heh
<hatch> oh man this is so awesome
<bac> no, i know.  i hadn't looked at the pull request.  thanks!
<hatch> :-) 
<rick_h_> hatch: ok, I'm really cranky with them now. The talk of lack of $$ for a security audit until they got funding is insulting. http://blog.npmjs.org/post/80277229932/newly-paranoid-maintainers
<hatch> reading...
<hatch> so basically the money that was raised was -only- used for hosting not working on the platform
<rick_h_> hatch: yea, guess so. But to claim the poor house after that but before funding is bad form imo
<rick_h_> not to mention it demonstrated that the community was willing to fund work on npm
<hatch> yeah I think the whole series of events was a huge mess
<rick_h_> no kidding
<rick_h_> ok, with that I'm out of here and before 5pm yay!
<hatch> lol have a good weekend
<rick_h_> everyone have a good weekend, look forward to hanging out next week ka
<rick_h_> bah tab fail
<hatch> haha he isn't here
<rick_h_> how dare he not let me tab complete his nick
<bac> jcastro: how does cbs do the scoring for the bracket?  in first round people with same number correct have different scores.
<bac> jcastro: congrats on your current lead.
<bac> hatch: fancy a charmworld review? https://codereview.appspot.com/78940044  mighty simple
<hatch> I can take a peek
<bac> hatch: not even any python, just template
<hatch> bac done
<bac> excellent catch hatch!
<hatch> :)
<hatch> bac can you send an email to the juju-gui list about the vagrant update? People will need to have it download the new image etc
<bac> hatch: i can, but won't it just dtrt the next time they 'vagrant up'?
<hatch> bac it didn't for me, I had to `vagrant delete && vagrant up`
<bac> oi
<hatch> it did the file sharing on the next up
<hatch> but didn't use the new image
<bac> okey doke, i'll do it
<hatch> cool thanks
<hatch> bac sorry it was `vagrant destroy`
<hatch> not delete
<bac> hatch: did
<bac> and with that i wish you a good weekend.  see you week after next.
<hatch> enjoy your break! cya
<hatch> sooo last one in the office eh
 * hatch turns the tunes up
<kadams54> hatch: Running into something frustratingâ¦ the local juju-gui seems to change the relationship status every couple of seconds
<hatch> oh yeah
<hatch> sorry
<hatch> heh
<kadams54> That's destroying and recreating the DOM that I'm trying to debug. What's the best way to make it stop?
<kadams54> :-)
<hatch> hit ctrl+s in the gui
<hatch> it'll shut off the simulator
<kadams54> Thanks
<hatch> the simulator is very nice for when you want to make sure what you're working on will change states properly etc
<hatch> but yeah, can be a hassle 
 * hatch would like to note that that shortcut was in the code you just changed :P
<hatch> lol
<kadams54> :-b
<hatch> kadams54 so how are you finding the code? Easy enough to follow?
<kadams54> Yeah, as long as I limit myself to the constraints of the bug I'm working on
<kadams54> Also helps that I'm being picky about which ones I pick up :-)
<hatch> haha yeah - it'll take a bit of getting used to - there are a few different systems at work 
<kadams54> hatch: another question: what, if any, resources are auto-reloaded when running `make devel`?
<kadams54> Right now I've just been doing ctrl-C and running `make devel` again once I save changes
<hatch> ohh no no
<hatch> js is auto reloaded, css and templates aren't in vagrant 
<hatch> (not sure why)
<hatch> in normal ubuntu the css and templates reload too
<hatch> I'm sure you have the 'disable cache' flag set in chrome's devtools ?
<kadams54> yes
<hatch> yeah - so in that case js should auto-reload, but css and templates will need make devel to be re-run
<hatch> at least until someone fixes it
<hatch> there are a number of those things unfortunately :)
<hatch> we don't get to the 'slack' tasks as often as we'd like hah
<hatch> man I wish my standing desk was motorized
<rick_h_> hatch: yea, I do love that
<rick_h_> with more meetings I use it back and forth a lot more now
<hatch> the mdf blocks just aren't cutting it for me anymore :)
<hatch> the price is right however....
<rick_h_> yea
<rick_h_> have to get yourself a big birthday present
<hatch> haha I think the MBP was big enough for a while yet
<hatch> the mrs would not be pleased if I bought one :D
<hatch> lol @ tweet
<hatch> it's all been in response to this http://igo.herokuapp.com/
<hatch> https://twitter.com/NateTheFinch/status/447119466363912192
<hatch> oh man nfs is so fast 
<kadams54> Alright, I'm out for the weekendâ¦ have a good one!
<hatch> and me as well cya 
#juju-gui 2014-03-23
<huwshimi> Morning
<rick_h_> morning huwshimi 
#juju-gui 2015-03-16
<jw4> is it possible in 1.23 to trigger juju actions from the GUI?
<rick_h_> jw4: so 1.23 is when it's released in Juju 
<rick_h_> jw4: and we've got on our roadmap over the next two months to do some work on the inspector in the gui where we'll look to add actions support
<rick_h_> jw4: but that won't be done when 1.23 is released end of month, it'll probably be towards the end of april
<jw4> rick_h_: cool, thanks
<jw4> rick_h_: I'm just reviewing the 1.23 release docs and wanted to make sure the messaging was right
<rick_h_> jw4: ah cool
<hatch> uiteam lf two reviews and qas for the bounceback service icon branch https://github.com/juju/juju-gui/pull/707
<hatch> bug #1430242
<mup> Bug #1430242: cannot change charm location most of the time <landscape> <juju-gui:In Progress by hatch> <https://launchpad.net/bugs/1430242>
<hatch> Makyo: 706 is ready for another qa
<Makyo> hatch, okay, will take a look at both in a few.
<hatch> thanks
#juju-gui 2015-03-17
<lazyPower> http://askubuntu.com/questions/597826/difference-between-deploying-bundle-with-quickstart-or-juju-deployer/597835#597835 - needs citation/approval from UX team 
<rick_h_> lazyPower: rgr will do ty
<lazyPower> if its totally wrong - i blame hatch.
 * lazyPower sips coffee and awates flame-on mode when hatch shows up
<lazyPower> *awaits
<rick_h_> hah
<rick_h_> lazyPower: ok, edits in, let me know what you think
<rick_h_> lazyPower: I know that the question was quickstart vs deployer, but I wanted to try to pull out that quickstart was designed/built for that single command to get started with juju, vs just another bundle deployment tool. 
<rick_h_> lazyPower: http://askubuntu.com/review/suggested-edits/390134
<lazyPower> rick_h_: approved!
<lazyPower> ta
<rick_h_> lazyPower: feel free to edit back and such as I've not had coffee yet
<lazyPower> this is why i made sure to follow up - let the UX peeps shine
<rick_h_> hah, ty for catching the question
<rick_h_> I have a SO email but it's too much junk I end up auto deleting. I guess I've not set one up for AU
<lazyPower> i listen for mup
<lazyPower> or the ask bot - i forget which drops in #juju with the links
<rick_h_> ah right, yea I've caught that sometimes but don't watch them overnight/etc
<lazyPower> highlights are amazing for channel scanning :D
<lazyPower> but i'm maybe 1/4 as popular as you are
<lazyPower> so it may not be  agood method for you
<rick_h_> heh, /me ducks and hides in a corner
<lazyPower> :)
<beisner> good morning.  bug 1413654 is marked fix-released, but i'm still seeing the issue as of cs:trusty/juju-gui-21.   is there a known work-around, or alternate branch that includes the fix?
<mup> Bug #1413654: Bundle Export link broken in Juju-Gui 16+ <juju-gui:Fix Released by hatch> <https://launchpad.net/bugs/1413654>
<beisner> fyi hatch ^
<rick_h_> beisner: is this a deployed gui or the demo?
<rick_h_> beisner: and what is the stack you've got you're exporting? 
<beisner> rick_h_, deployed.
<rick_h_> beisner: a quick test on the demo site with one deployed charm works so might be something in one of the charms is having a hard time getting serialized
<rick_h_> beisner: would love to have a screenshot or details on what's in the stack there to reproduce
<beisner> rick_h_, it's a full stack openstack bundle that i'm validating in prep for charm store
<beisner> i'll link you to it shortly.
<rick_h_> beisner: ty
<rick_h_> beisner: yea, going to guess the "to" error is around placement 
<rick_h_> beisner: so some bug specific to the placement of the services in your bundle we'll have to replicate/trace down
<beisner> rick_h_, here are the juju stats  http://paste.ubuntu.com/10615355/
<rick_h_> beisner: ok yea the direct placement stuff is still in progress as we update the deployer and have to update the gui export once that lands. It shouldn't traceback at you though for sure while we get that working
<beisner> rick_h_, ok i see - something is in-flight.   let me know if there's more i can do to help on the bug.
<rick_h_> beisner: np, ty for the report and prod on it. 
<beisner> rick_h_, it's really not critical, i was going to use it mostly for x/y coords instead of thinking hard about those coords.  ;-)
<beisner> rick_h_, i think it will gather add'l heat though, as we come up with additional openstack bundles for the charm store.   holler back if you need to to throw something at it.
<rick_h_> beisner: ok to use your pastebin in the new bug report?
<beisner> rick_h_, ha!  just posted it.
<rick_h_> beisner: ok, I'm going to move it to a new bug around the placement directive stuff
<rick_h_> beisner: just to split it as it's a different line of work/issue
<beisner> rick_h_, ok thank you
<rick_h_> beisner: https://bugs.launchpad.net/juju-gui/+bug/1433096 is the new bug and https://code.launchpad.net/~makyo/juju-deployer/machines-and-placement/+merge/251857 is the WIP on the deployer side to let us export stuff that has machine placement stuff in it
<mup> Bug #1433096: bundle export link fails when placement is involved <juju-gui:Triaged> <https://launchpad.net/bugs/1433096>
<beisner> rick_h_, great, thanks again.
<beisner> rick_h_, the jujucharms.com authors page advises "Refer to the Bundles page for instructions on how to create bundles of charms and submit them to the store."   But the link is broken (https://jujucharms.com/docs/charms-bundles.html).  Do I need to raise a bug somewhere?
<beisner> Not sure which channel/team to ask.
<beisner> Referring page = https://jujucharms.com/docs/authors-charm-store
<rick_h_> beisner: sec looking. 
<rick_h_> beisner: yea, it's in the nav link as well, and only that page seems to not route
<rick_h_> but does exist in the docs so filing a bug for us to inviestigate and if it's docs related we'll move the bug to the docs
<rick_h_> beisner: we've also got a release we're working on getting out that fixing some routing so might be fix on the way but will verify
<rick_h_> beisner: https://github.com/CanonicalLtd/jujucharms.com/issues/58
<beisner> rick_h_, is there a working (perhaps not-yet-linked) url for the bundles page?
<rick_h_> fabrice: can you peek at https://github.com/CanonicalLtd/jujucharms.com/issues/58 and chase that please?
<rick_h_> beisner: it should be https://github.com/juju/docs/blob/master/src/en/charms-bundles.md
<beisner> rick_h_, ack, thanks again!
<rick_h_> np
<rick_h_> beisner: yea, looks like it's working on our QA site http://qa.storefront.theblues.io:6543/docs/1.20/charms-bundles so that fix is probably on the way in the deployment
<beisner> sweet
<fabrice> rick_h_: so I have nothing to look at :)
<rick_h_> fabrice: yea, looks like not sorry
<fabrice> rick_h_: I like it 
<marcoceppi> How do you look up bundles in v4 api?
<hatch> marcoceppi: just query for bundle
<rick_h_> marcoceppi: type=bundle
<hatch> oh woops sorry heh the api not the website :)
<rick_h_> https://api.jujucharms.com/v4/search?type=bundle&limit=1000
<marcoceppi> so, how does that look in the URL? https://api.jujucharms.com/v4/mediawiki-scalable ?
<rick_h_> marcoceppi: ^
 * hatch goes away
<marcoceppi> yeah, but if I wanted to get the bundle.yaml file for a bundle
<marcoceppi> I'd need to know it's address, right?
<rick_h_> https://api.jujucharms.com/v4/bundle/mediawiki-scalable-9/archive/bundle.yaml and https://api.jujucharms.com/v4/bundle/mediawiki-scalable-9/archive/bundles.yaml.orig
<marcoceppi> ah, so the whole not found message for bundle/mediawiki-scalable-9 is because I didn't give it a query?
<rick_h_> marcoceppi: https://api.jujucharms.com/v4/bundle/mediawiki-scalable/meta/any for just checking if it exists
<rick_h_> marcoceppi: right, you need to ask for something
<marcoceppi> there we go, thank you
<rick_h_> https://api.jujucharms.com/v4/bundle/mediawiki-scalable/meta/id for instance
<rick_h_> np
<rick_h_> marcoceppi: and jcsackett is working today on pulling the python lib out so hopefully be end of week we'll have the open source client in the juju org
<marcoceppi> rick_h_: I finally got around to doing that jujusvg as a webservice, just adding some finishing touches
<rick_h_> marcoceppi: ah nice
 * rick_h_ will be eager to check it out
<marcoceppi> <3 the jujusvg code btw frankban
<rick_h_> that's Makyo 
<rick_h_> ^
<marcoceppi> fuuuu
<marcoceppi> w/e all those who hath made it
<hatch> I reviewed a branch of it once...
<rick_h_> well his baby
<hatch> yay me!!
<rick_h_> hah!
<hatch> haha
<rick_h_> hatch: photo bombs the credit reel on jujusvg
<hatch> lol bingo
<rick_h_> jcsackett: so let's keep marcoceppi in the loop on the progress and pr and such when we get things pulled apart ^
<marcoceppi> yes pls, righ tnow I'm just hitting endpoints but having the API library would be boss
<jcsackett> rick_h_: ack
<rick_h_> jcsackett: <3
<marcoceppi> also I can start moving our tools over
<jcsackett> marcoceppi: we should be able to help you out real soon. 
<marcoceppi> \o/
<jcsackett> And I look forwards to people outside our team using it. 
<marcoceppi> Does the v4 api give a status code other than the json Message/Code?
<marcoceppi> nvm, yes it does
<hatch> :)
<aisrael> This may already be a known issue (and I opened a bug in case it's not), but this page is a 404: https://jujucharms.com/docs/tools-charm-tools/
<jcastro> aisrael, where do you see that link referenced?
<jcastro> oh, in the sidebar
<jcastro> https://jujucharms.com/docs/tools-amulet/ is also busted
<rick_h_> aisrael: yep, we're working on getting a deployment that has that fix in for some routing issues with trailing slashes and such http://qa.storefront.theblues.io:6543/docs/1.20/tools-charm-tools
<aisrael> jcastro: https://jujucharms.com/docs/, http://pythonhosted.org/charmhelpers/getting-started.html#installing-charm-tools
<rick_h_> jcastro: aisrael yep, hit it with the bundle one as well
<aisrael> rick_h_: awesome, thanks
<jcastro> rick_h_, do we have a way of just spitting out everything with a 404?
<rick_h_> jcastro: not yet
<rick_h_> jcastro: we've got the sitemap stuff and once we have that we want to start link crawling and referencing that against the sitemap which would bring up the 404s
<jcastro> I found a few yesterday I fixed by hand
<rick_h_> k
<rick_h_> yea, we need to toss a link crawler at the site but waiting on the current fixes + the sitemap stuff
<jcastro> after we sort it it would be nice to just have the docs builder or whatever autofile a bug on new 404's
<rick_h_> rgr
#juju-gui 2015-03-18
<lazyPower> rick_h_: did GUI / StoreAPi get a new release today?
<rick_h_> lazyPower: no, locked up in mojo CI atm
<rick_h_> lazyPower: still working on it
<lazyPower> cs:bundle/data-analytics-with-sql-like-6 is failing deployment on GUI when i click "Deploy this bundle" 
<lazyPower> i'll file a bug and circle back with the ticket #
<rick_h_> lazyPower: otp one sec
<lazyPower> https://bugs.launchpad.net/juju-gui/+bug/1433706
<mup> Bug #1433706:  invalid request: bundle "bundle-deploy" not found <juju-gui:New> <https://launchpad.net/bugs/1433706>
<hatch>  lazyPower hey I saw your bug - do you have a browser console stacktrace available?
<lazyPower> hatch: i've got the gui instance up, do i need to enable any flags?
<hatch> lazyPower: nope, just open the browser console (ctrl+shift+i)
<lazyPower> got that, 1 sec
<hatch> and when you get the notification error there should be one in the console
<lazyPower> let me ss the stack
<lazyPower> http://i.imgur.com/l8xM58y.png
<hatch> ok can you switch to the network tab and see if there are any 404s or the like?
<hatch> that error you're seeing is just a parsing issue so it doesn't help heh
<hatch> it just tells us what we already know (that it's' broken) :D
<lazyPower> hatch: no 404's
<lazyPower> clean cache fully dumped
<hatch> hmm ok then that's odd - will have to fire up an env here to try and repro
<lazyPower> hatch: i just got out of daily - have you been successful in repro?
<hatch> lazyPower: sorry was just ea5ting lunch 
<hatch> will be trying it soon
<hatch> lazyPower: running the test now - was it any bundle in particular? 
<lazyPower> hatch: any/every bundle i've tried has resulted in the same error
<lazyPower> i tried mw-scalable, sql-like
<lazyPower> and a couple others that i dont recall off the top of my head
<lazyPower> i think web-infra-in-a-box
<lazyPower> and mongo
<lazyPower> they all reported teh same error, seems like something is awry between the gui sending the command and / or the api response.
<hatch> alright - should be spun up shortly here
<hatch> lazyPower: I can reproduce
<hatch> will look into it shortly thanks
<lazyPower> cheers hatch
<hatch> I also know what's causing the issue - not sure how to fix though
<hatch> lazyPower: working on the fix now - hoping to get it done for tomorrow then MAYBE a release tomorrow, if not then Monday for sure
<hatch> ^ rick_h_ 
#juju-gui 2015-03-19
<hatch> lazyPower: https://jujugui.wordpress.com/2015/03/19/juju-gui-1-3-4-not-so-sticky-release/
<lazyPower> hatch: \o/ 
<lazyPower> will read after dinner
<lazyPower> (FIX) Bundle deploys no longer fail with invalid name error. <- ok so i lied. Best fix ever. have a puppy
<lazyPower> https://www.care.com/img/cms/web/content/articlephotos/2012/08-aug/img-article-puppy-care-stages.jpg
<hatch> lol
#juju-gui 2017-03-24
<arosales> juju gui question :-)
<arosales> I am setting up a new juju client in AWS to which I will then deploy applications from
<arosales> I have the following model: http://paste.ubuntu.com/24242482/
<arosales> but `juju gui` gives me what looks like an internal address
<arosales> http://paste.ubuntu.com/24242489/
<arosales> so I can't hit 172.31.9.240. However, if I issue `juju status -m controller` I see the controller on 52.14.181.137
<arosales> using that in my browser I can hit the gui, ie https://52.14.181.137:17070/gui/u/admin/saiku-hadoop-spark
<arosales> any thoughts on why juju gui is giving me an internal address and not an external one?
<rick_h> arosales: bug!
<arosales> rick_h: one cavet, I did use juju to set up my instance in AWS, but I hope that wouldn't matter
<arosales> so from my desktop I deployed the ubuntu charm, juju ssh ubuntu/0, and then set up the client from there
<arosales> bit I'll log a bug
<arosales> rick_h: thanks
