[12:06] <frankban> hazmat: did you have a chance to take a look at https://code.launchpad.net/~hazmat/juju-deployer/refactor-placement-and-validate-feedback/+merge/195903 ?
[12:15] <rick_h__> morning frankban 
[12:15] <frankban> hi rick_h__ 
[12:19] <rick_h__> frankban: free for a hangout in a second? 
[12:19] <frankban> rick_h__: sure
[12:20] <rick_h__> frankban: https://plus.google.com/hangouts/_/76cpi22pojjntaagcr9vbpnl0s?authuser=1&hl=en
[13:17] <gary_poster> rick_h__, re: quickstart review and your comments, I think both you and frankban know that I generally offer my suggestions as only suggestions.  If that's only true in my imagination, please let me know. ;-)  Anyway, I do think that it's very much worth exploring significantly reducing OOP.  Go, Scala, Clojure, and even books like Functional JavaScript (http://shop.oreilly.com/product/0636920028857.do) all are goin
[13:17] <gary_poster> g in that direction to varying degrees.  All of those examples except Go are further advocating functional paradigms as a way to simplify reasoning about code.  I've been reading and playing with a functional style for years on my own time now, and I really think there's value to it.  In this particular example, re-introducing some OOP now that the basic pattern has been established won't kill kittens, as benji woul
[13:17] <gary_poster> d say.  If that's where the team wants to take stuff, cool.  I can be the crazy guy muttering in the corner. :-)
[13:18]  * benji watches the world-wide kitten-count as it holds steady.
[13:18] <gary_poster> lol
[13:21] <gary_poster> In other news YAY! jujucharms apparently is no longer borked!!
[13:22] <rick_h__> gary_poster: yea, I was just tossing my opinion reading through things. I talked to frankban about it. I had no background to it, but read the MP as "provide model layer" and it required tracking 3 different dicts of data. I was missing the abstraction/simplification. I tend to think of models as hiding some implmentation details and I had to know in my head the implementation more than I was expecting based on my reading of th
[13:23] <gary_poster> rick_h__, output was cut off after "I had to know in my head the implementation more than I was expecting based on my reading of th"
[13:23] <rick_h__> bah
[13:24] <frankban> gary_poster: we had a call this morning with rick_h__, we agreed on proceeding with the functional approach and see how it works. It should be easy to introduce some OOP/higher abstraction if we then find the view code to be too much ugly. As rick_h__ suggested, I'll change some name and above all I will try to get rid of the envs_meta datastructure, that can be retrieved directly by the functions that require it
[13:24] <frankban>  (e.g. normalize/validate). 
[13:25] <rick_h__> gary_poster: https://pastebin.canonical.com/101724/plain/
[13:27] <gary_poster> proceeding for now: cool.  Agreed it will be easy to add higher abstraction if desired (I'd argue that the fact that we agree it will be easy is suggestive that the current approach does have at least some aspects of simplicity). global envs_meta: not my preference, but cool if that's where we want to go.
[13:28] <rick_h__> gary_poster: yes, it's simple once you read the large comment blocks to understand what data ends up where. I just found the 'api' created as a dev a little more manual than I was expecting. 
[13:28] <rick_h__> it's fine and I LGTM'd, just was curious to discuss it. I didn't know the backstory of your pre-imp when I did the review
[13:31] <gary_poster> To be clear, hidden envs_meta is not my preference because (1) you have to know that there's a data structure guiding the behavior, while the current approach makes that quite explicit (maybe better names would help); and (2) testing the functions means you have to either stub the global data source or actually test the effect of the data source.
[13:38] <frankban> gary_poster: interesting. 1) makes sense, people reading the code immediately understand that envs_meta is something they have to deal with. and maybe some of the confusion is generated by the names, in which case... ideas for better names? :-)
[13:39] <frankban> gary_poster: envs_meta will include at least two pieces of information: the list of fields (welcome back OO) and a description for each provider type
[13:40] <gary_poster> rick_h__, I'm confident that someone with more functional experience would have some beautiful refactoring suggestions to offer.  Similarly, I think this point from your pastebin has merit: "Go has interfaces/types to help provide mental mapping of what to expect within the app and keeping track of 3 diff dicts didn't strike me as aiding in simplifying the model of what was going on."  Some Clojure programmers would
[13:40] <gary_poster>  disagree with you, I think, but others have expressed something like "ok, we made everything data, and now it's super easy to see how everything flows through the system, but harder to see what's flowing."  IMHO (I usually don't add the H because I'm already acknowledging that it is an O, but in this case I'm aslo acknowledging that I don't have as much experience here as I would like, though I have a decent amount
[13:40] <gary_poster>  of reading) that can very often be addressed by having good names and good keys in the data structure.  That's most of what an object provides here anyway--and in fact, in a dynamically-typed language like Python, arguably that's almost all of what it provides.
[13:40] <gary_poster> frankban, yeah cool, lemme go look and see if I have any name ideas.
[13:41] <frankban> gary_poster: thanks
[13:41] <rick_h__> gary_poster: yea, that fits what my thought process was. It was 'easy' but not 'simple' since it moved some complexity to tracking more parts. 
[13:43] <gary_poster> rick_h__, have you ever seen http://www.infoq.com/presentations/Simple-Made-Easy ?
[13:44] <rick_h__> gary_poster: yes, I think I watched that a while ago. 
[13:45] <gary_poster> rick_h__, right.  by his definitions, I think maybe we've done a decent job with simple, but you're arguing that we haven't managed easy.  probably unimportant semantics.
[13:46] <gary_poster> I mean
[13:46] <gary_poster> unimportant whether we say simple or easy: I understand your objection, whichever the word we use
[13:46] <rick_h__> sorry, yea I think it's flipped here. I tend to think "It's easy to just expose your database as your api, it's hard to make the api simple for people to use to perform tasks"
[13:47] <gary_poster> functional programming precisely argues that you shoudl be manipulating your data
[13:47] <gary_poster> I think
[13:47] <gary_poster> so if I'm right
[13:48] <gary_poster> this is just a mindset difference
[13:48] <rick_h__> yea
[13:49] <frankban> rick_h__, gary_poster : IMHO there is only one more piece of information you have to deal with with this functional approach (envs_meta). env_data is an environment (i.e. the instance. __dict__ in a OO approach), envs_dict is the YAML, and in a way or the other you have to deal with it. I think the effort here was to give developers an unsurprising datastructure and not an OO API
[13:50] <gary_poster> (I agree, but that's not surprising :-)
[13:50] <rick_h__> frankban: yes, that's cool. I was just not going into the review thinking "Let's do this in a functional approach and take this different mindset"
[13:51] <rick_h__> I'm not completely against these things, just that my mindset during review was "Let's providel models (and maybe I think too SQL Models off the bat) for dealing with envs"
[13:51] <rick_h__> and that implies, in my mindset, an api, or set of abstractions on the idea of an env from juju
[13:53] <frankban> rick_h__: yeah, sorry for the missing info in the MP description, and as I mentioned to you, the "alchemy" models pattern was my first approach as well
[13:54] <rick_h__> frankban: cool, yea carry on! :) Just leave the comments since they made it reasonable. 
[14:02] <gary_poster> frankban, rushing to call (late) but shared ideas in rv
[14:03] <gary_poster> oh bah
[14:03] <gary_poster> nevermind
[14:03] <gary_poster> call with mramm cancelled :-/
[14:07] <frankban> gary_poster: cool thanks, so in your suggestion env_type_db is envs_meta and you introduced a new get_env_metadata function to get the metadata for that env type, right?
[14:07] <gary_poster> frankban, exactly.
[14:08] <gary_poster> if you were doing this a lot, you could easily compose this with a partial.
[14:08] <gary_poster> import functools
[14:08] <gary_poster> get_environment = functools.partial(get_env_data, env_db)
[14:08] <gary_poster> get_metadata = functools.partial(get_env_metadata, env_type_db)
[14:11] <frankban> gary_poster: sounds good
[14:11] <gary_poster> cool
[14:15] <gary_poster> hatch, did you take a look at "Chosen Implementation" in https://docs.google.com/a/canonical.com/document/d/1TxnOCLPDqG6y3kCzmUGIkDr0tywXk1XQnHx7G6gO5tI/edit?disco=AAAAAHiLwwE# ?  It looks good to me, but I'd appreciate your review
[14:16] <hatch> gary_poster yeah he told me about it last night, just reading through the doc now
[14:16] <gary_poster> cool
[14:25] <gary_poster> abentley's reply to the charm download metric thread falls under the "bummer" category :-)
[14:26] <abentley> gary_poster: Sorry :-(
[14:27] <gary_poster> abentley, never apologize for the truth, or something, yeah? :-)
[14:27] <gary_poster> IOW, not your fault, but it is a bummer
[14:27] <abentley> gary_poster: Sorry for inflating the numbers in the first place.
[14:27] <benji> we have a mechanism to not count certain charmstore downloads, we should probably make use of it for CI downloads
[14:27] <gary_poster> yeah
[14:28] <gary_poster> we have enough of that going on from different quarters that it would be probably wise to build generically
[14:28] <gary_poster> benji, what is that mechanism?  is it in the charm store or in charmworld?  IIUC charm store is the sorce of truth here
[14:29] <benji> I'm pretty sure the store has a "don't count this download" option.
[14:30] <gary_poster> benji, cool.  we ought to use that for our own tests as well
[14:30] <gary_poster> though that may equally be a bummer :-P
[14:38] <hatch> yay odd hanging bug when loading the GUI is fixed
[14:38] <hatch> how weird was that one :/
[14:39] <gary_poster> yeah
[14:39] <gary_poster> makes sense in retrospect
[14:39] <gary_poster> as is often the case
[14:40] <hatch> well a 1s timeout is crazy long though heh
[14:40] <frankban> gary_poster: https://codereview.appspot.com/39380043/diff2/20001:40001/quickstart/models/envs.py
[14:40] <gary_poster> hatch, you tackling huw's sticky header branch per the call last night, or should we make a call for help?
[14:40] <gary_poster> looking
[14:41] <hatch> gary_poster well is his last few commits in the PR where he is leaving off? 
[14:41] <hatch> I can get to it after my current branch of rewriting fullscreen > sidebar 
[14:41] <hatch> just doing the tests now
[14:41] <gary_poster> hatch, not exactly super clear, but that was my assumption, since that's what we agreed yesterday on the call
[14:43] <gary_poster> frankban, looks pretty to me. you like it?
[14:45] <rick_h__> gary_poster: if you get a sec can you peek at https://github.com/juju/juju-gui/pull/10 and see if that helps with the process/notes.
[14:45] <gary_poster> on it
[14:46] <frankban> gary_poster: yes I do, because the resulting functions should be very short and simple, but this assumption can be confirmed only by my next branch
[14:46] <gary_poster> frankban, cool. good luck.:-)
[14:47] <hatch> rick_h__ so I've been using a slightly different flow that you have outlined there
[14:48] <rick_h__> hatch: that's cool. Using your tool?
[14:48] <hatch> after I've added the upstream I go into develop  then `git fetch upstream`
[14:48] <hatch> then branch from develop on my machine
[14:48] <frankban> :-) next branch with tail-recursion generated metaclasses, so that everyone is (un)happy 
[14:48] <rick_h__> hatch: upstream is your remote for the 'juju' repo?
[14:49] <hatch> oh you put the wrong repo in the docs heh
[14:49] <hatch> git remote add juju git@github.com:juju/jenkins-github-lander.git
[14:49] <rick_h__> hatch: bah, thanks for the catch
[14:49] <hatch> so I add the juju repo there, then add it as the upstream for my local develop
[14:49] <hatch> then in my local forked develop branch I `fetch upstream` which pulls in the updates
[14:49] <hatch> then I branch from my local develop
[14:50] <hatch> the outcome is the same just a different sequence I suppose
[14:50] <rick_h__> hatch: right, but that's the example same steps from what I can tell. Just /juju/upstream 
[14:50] <hatch> oh I thought you had it merging upstream into the new branch not the local develop
[14:51] <hatch> maybe I misread
[14:51] <rick_h__> hatch: no, it pulls upstream into develop and then forks from develop to a feature branch
[14:51] <rick_h__> at least that's what it's supposed to say, /me re-reads
[14:52] <hatch> rick_h__ oh the docs are missing the fetch I think
[14:53] <rick_h__> hatch: ah, well I have pull vs fetch
[14:53] <rick_h__> http://stackoverflow.com/questions/292357/whats-the-difference-between-git-pull-and-git-fetch
[14:54] <hatch> OHHHH now I see why I was so confused....you called `upstream` `juju`
[14:54] <rick_h__> hatch: right
[14:54] <hatch> clearly I need to have my morning coffee haha
[14:54] <rick_h__> hatch: I went with teh clarity that this was the "juju repo"
[14:55] <rick_h__> if upstream is more clean then I can change it. 
[14:55] <rick_h__> but juju was "definitely not mine" where upstream could be read as "you mean my branch up on github right?"
[14:55] <rick_h__> which is a fork of juju
[14:55] <hatch> personally I think of 'upstream' because it's a direct upstream from our fork not a secondary repo - but I could see the confusion
[14:56] <hatch> because you -can- add other unrelated remotes 
[14:56] <rick_h__> k, yea I mean you can call it 'borky' or whatever you want :)
[14:56] <hatch> right lol
[14:56] <rick_h__> hatch: right, but there's only one 'juju' remote. The github/juju/ fork
[14:56] <hatch> yeah
[14:56] <rick_h__> anyway, tomato...tomato...crap that doesn't work so well in typing :)
[14:56] <hatch> haha
[14:57] <hatch> tomaeto tomaato
[14:58] <rick_h__> man, I have to say, I'm loving having my tab complete in zsh all worky worky again. 
[14:58] <rick_h__> completing my aliases, branch names, remotes, wheeee
[15:01] <rick_h__> gary_poster: updated if you want to look again. 
[15:03] <gary_poster> rick_h__, cool.  still commenting on old one :-P  will refresh in a sec
[15:03] <rick_h__> gary_poster: oh sorry. 
[15:03] <gary_poster> np!
[15:05] <hatch> rick_h__ git rebase; git push -f :P
[15:14]  * gary_poster proposes github :+1: == LGTM
[15:14] <gary_poster> Because the thumb is so cute.
[15:14] <hatch> lol
[15:15] <rick_h__> hah
[15:15] <hatch> only if we can use the pile of poo one for -1 
[15:16] <gary_poster> heh, they don't have an auto-image for that do they?
[15:16] <hatch> 💩
[15:16] <hatch> in my font, it has eyes and a mouth
[15:16] <hatch> lol
[15:17] <gary_poster> ah yes, that is :poop:
[15:17] <hatch> use :poop:
[15:17] <hatch> right haha
[15:17] <gary_poster> we can also use :water_buffalo:
[15:17] <hatch> haha
[15:17] <gary_poster> http://www.emoji-cheat-sheet.com/
[15:18] <gary_poster> lol
[15:18] <gary_poster> Campfire also supports a few sounds
[15:18] <gary_poster>  /play trombone
[15:18]  * gary_poster assumes this is sad trombone
[15:18] <hatch> :shipit:
[15:18] <hatch> we must use that, its like a hamster with a hat
[15:19] <gary_poster> lol
[15:19] <gary_poster> I could get behind that
[15:20] <hatch> haha 
[15:20] <hatch> :shipit:
[15:21] <gary_poster> although I also like including things that make no sense and seem to require deep interpretation
[15:21] <gary_poster> :moyai:
[15:21] <gary_poster> easter island statue!  has t mean something important, right?
[15:21] <hatch> lol
[15:22] <hatch> ok and if it's so bad that there is no saving it :ambulance: 
[15:22] <gary_poster> That implies that paramedics might do something.  I was also thinking :recycle: could be the last word.
[15:23] <hatch> ok and for "your code is slowly killing me" :smoking:
[15:23] <gary_poster> lol
[15:23] <gary_poster> :no_good: goes back into cute territory, as does :person_with_pouting_face:
[15:24] <hatch> haha
[15:24]  * gary_poster departs land of emoji with :nail_care:
[15:26] <gary_poster> rick_h__, oops, you kept my suggested comment explaining qa-pr's usage but dropped the example that it explained
[15:27] <rick_h__> gary_poster: hmm, looking
[15:27] <rick_h__> oh doh
[15:28] <gary_poster> Looks good rick_h__ .  Thank you very much!
[15:28] <rick_h__> thanks for the proofing and providing the 'average team expectation' 
[15:29] <gary_poster> perhaps below average for the git stuff :-P but happy to help :-)
[15:29] <rick_h__> well the "not in rick's automatic assuming head" space
[15:30] <gary_poster> heh
[15:32] <rick_h__> bah, quit sending your cold air down here hatch. It's too early for -19C wind chills. That's late Jan stuff. 
[15:33] <hatch> heh it's -22C here right now w/o a wind chill so it must be warming up on the way down lol
[15:33]  * rick_h__ holds back comments about the hot air as it passes hatch's house :)
[15:34] <rick_h__> yea, only -12 here sans-wind chill
[15:34] <gary_poster> lol
[15:34] <hatch> haha
[15:35] <hatch> -12 is still pretty cold if you aren't acclimatized for it
[15:41] <bac> +1 on your s/LGTM/+1 gary_poster
[15:41]  * bac dude applying sealant on roof is messing with my internet
[15:50] <gary_poster> jujugui call in 10
[15:50] <benji> jujugui: I have a branch up for review at https://codereview.appspot.com/40190043/
[15:51] <benji> it has nice pre-review comments and everything.
[15:51] <gary_poster> everything?  dancing reindeer?
[15:51] <rick_h__> benji: but how for do we mrege this then? 
[15:51] <rick_h__> merge that is
[15:51] <benji> rick_h__: you tell me
[15:51] <gary_poster> heh
[15:51] <gary_poster> uh oh
[15:51] <benji> I don't know nuthing 'bout merging no github.
[15:51] <bac> rick_h__: ESL much?
[15:52] <gary_poster> lol
[15:52] <rick_h__> benji: by making a branch from your github fork and following the HACKING/process docs
[15:52] <rick_h__> bac: :)
[15:52] <benji> I must have missed the memo on the new process.
[15:52] <bac> rick_h__: was there a git for bzr-tards doc?  i vaguely recall mention of one
[15:52] <gary_poster> rick_h__, how would he do the bzr conversion?  export the diff from bzr and repply?
[15:52] <rick_h__> benji: I'd be happy to walk you through the process
[15:52] <gary_poster> reapply?
[15:53] <rick_h__> gary_poster: yes, maybe generate a patch and then apply it to a feature branch from the git repo
[15:53] <benji> rick_h__: I'll give it a shot and see if I have any questions.
[15:53] <rick_h__> benji: rgr
[15:53] <gary_poster> bac, HACKING doc is now pretty close to that because of my requests and rick's help
[15:53] <hatch> jujugui lf a review/qa https://github.com/juju/juju-gui/pull/11
[15:53] <bac> gary_poster: ok, great
[15:54] <hatch> gary_poster I'll work on huw's branch right now 
[15:54] <gary_poster> thanks hatch
[15:54] <rick_h__> hatch: looking
[15:54] <hatch> thanks
[15:54] <hatch> http://www.git-tower.com/blog/git-cheat-sheet-detail/
[15:55] <hatch> jujugui ^ 
[15:55] <frankban> hatch: cool thanks
[15:56] <gary_poster> I liked this one a lot
[15:56] <gary_poster> http://ndpsoftware.com/git-cheatsheet.html
[15:56] <gary_poster> keeps the info down
[15:57] <gary_poster> and organizes it in a way that was helpful to me, at least
[15:57] <hatch> that's pretty cool
[15:57] <hatch> shows the flow
[15:57] <gary_poster> right
[15:57] <rick_h__> that's interesting
[15:58] <Makyo> jujugui call in 2
[15:58] <gary_poster> ty
[16:09] <jcastro> hey rick_h__
[16:09] <rick_h__> jcastro: yep
[16:09] <jcastro> are you still "in charge" of the rating page on manage.?
[16:10] <rick_h__> jcastro: not really, it's not on the immediate map atm so not sure who's 'in charge' of it
[16:10] <jcastro> ok
[16:13] <jcastro> gary_poster, https://bugs.launchpad.net/juju-gui/+bug/1257878
[16:13] <_mup_> Bug #1257878: Revise charm feature bullets <juju-gui:New> <https://launchpad.net/bugs/1257878>
[16:13] <jcastro> can we put that on some map somewhere?
[16:19] <gary_poster> jcastro, will look soon still on call
[16:19] <jcastro> yeah no rush.
[16:19] <jcastro> I will keep track of the ratings for each charm in the audit by hand for now, it's not a rush thing
[16:19] <jcastro> so like, doesn't need to be this year, but april would suck. :p
[16:20] <gary_poster> heh ack
[16:31] <gary_poster> btw jcastro we are trying to treat your cloudfoundry issue--not coming up in searches on mjc--as urgent.  Is that correct from your perspective?  That is, it is very important that it be fixed within the next few days?
[16:31] <gary_poster> we think it is probably urgent anyway because it makes us nervous :-P but just wanted to check in with you
[16:31] <jcastro> well, considering we're in beta
[16:32] <jcastro> it's not that bad
[16:32] <gary_poster> ok
[16:32] <jcastro> really we're the only ones using bundles
[16:32] <gary_poster> ok cool
[16:32] <gary_poster> we'll hopefully get it fixed in a few days anyway
[16:33] <gary_poster> benji, is this a trivial change? https://bugs.launchpad.net/juju-gui/+bug/1257878 .  AIUI we can simply trash the existing data on charm features, and then reset the schema to the given one
[16:33] <_mup_> Bug #1257878: Revise charm feature bullets <juju-gui:New> <https://launchpad.net/bugs/1257878>
[16:33]  * benji looks
[16:34] <gary_poster> IIUC this is entirely in charmworld
[16:34] <rick_h__> gary_poster: benji we have to watch the form generation stuff. It expects a specific format and then a migratino to clear/reset the data in the charms themselves. 
[16:35] <gary_poster> vague ack :-P
[16:36] <benji> gary_poster: it will at least be non-hurculean, it will likely be not too bad
[16:36] <gary_poster> benji, heh ok.  I'll add that to the "high" list, jcastro.  Hopefully done before winter break
[16:46] <hatch> rick, does dolla-dolla-merge need to be the only thing in the message? 
[16:46] <hatch> rick_h__ ^
[16:56] <hatch> very cool WestJet video https://www.youtube.com/watch?v=zIEIvi2MuEk
[16:59] <gary_poster> hatch, no it does not
[16:59] <hatch> jujugui 792 views so far of my chat with the YUI guys
[16:59] <gary_poster> cool!
[16:59] <hatch> apparently that's double the most viewed other round table so far
[17:00] <hatch> and it's not even a week old haha
[17:00] <bac> hatch: i was out last week when you did it.  url?
[17:00] <rick_h__> hatch: no, just in the message
[17:00] <benji> ooh, git status --porcelain where have you been all my last-20-minutes
[17:01] <hatch> bac http://www.youtube.com/watch?v=lJPdH8xmOWg
[17:01] <jcastro> hatch, hey this video is cool
[17:01] <jcastro> I am going to share it
[17:02] <jcastro> hatch, also. Pocket Trains. 
[17:02] <hatch> jcastro :) thanks!
[17:02] <hatch> lol!
[17:02] <hatch> still playing that hey?
[17:07] <hatch> jcastro you must have all of the continents now?
[17:07] <jcastro> no, still in europe
[17:07] <hatch> whaaa? How is that possible lol
[17:07] <jcastro> I am not travelling enough to be on my phone that often
[17:07] <hatch> ohh haha
[17:53] <hatch> someone wake huw up
[17:54] <rick_h__> hatch: lol
[17:54] <rick_h__> call his butler for an early morning wake-up all?
[17:54] <rick_h__> "you need to get the president up, it's important"
[17:54] <hatch> yeah!
[17:55] <hatch> there is some uncommented funkyness in the code which when I 'fix' it it breaks
[17:56] <hatch> so /me is confused
[19:12] <Makyo> Oh man, this unit list thing is so broken :/
[19:13] <dimitern> hatch, fyi here's the CL with charm upload support https://codereview.appspot.com/40290044/
[19:13] <hatch> dimitern cool I'll take a peek
[19:13] <hatch> thanks
[19:13] <hatch> Makyo uh oh....details?
[19:14] <dimitern> hatch, i'll land it tomorrow though, i'm already +18h in today
[19:14] <dimitern> :)
[19:14] <hatch> haha you go!, what time is it there?
[19:15] <dimitern> it's 8.14 pm and i started like 4.30 am
[19:15] <hatch> oh so that's why you were up when I was just going to bed :D
[19:15] <Makyo> hatch, when we build up the categories of units, we're passing references to units into the lists; we then add category information to each unit.  When a unit is in multiple categories (as with landscape + running/etc), the category information is overwritten when it's added, since the unit is a reference, not a value.
[19:16] <Makyo> Going to see about storing the unit as a member of an object along with the category information, rather than injecting it in like that.
[19:16] <hatch> *facepalm*
[19:16] <rick_h__> lol
[19:17] <dimitern> hatch, yep
[19:29] <hatch> I have to admit, huw's technique is pretty darn smart
[19:29] <hatch> now if I could just figure out why it won't work on the search results
[19:29]  * hatch shakes fist at rick_h__  for making them different views
[19:30] <rick_h__> hatch: huh? they share a common base. 
[19:30] <rick_h__> only difference is one has two containers and interesting has 3
[19:31] <rick_h__> hatch: let me know if you need some eyeballs
[19:31] <hatch> right - they are separate views instead of the same view with different content
[19:32] <hatch> it's actually the 'home' button causing the issues
[19:32] <hatch> but it's easier to blame the whole stack :P
[19:32] <rick_h__> ah, well yea the home button is a tacked on thing due to keeping state in order
[19:33] <rick_h__> hatch: branch up to peek at?
[19:34] <hatch> ahh it's just fixing css stuff
[19:34] <rick_h__> selectors just a hair off?
[19:34] <benji> jujugui: after a little work and a break for lunch I have my branch up for review on github: https://github.com/juju/juju-gui/pull/12
[19:35] <rick_h__> benji: looking
[19:35] <benji> thanks
[19:35] <hatch> rick_h__ the odd positioning in the sidebar to make the scrollbars work is causing the calculations in the sticky headers to be way off when there is the home button
[19:35] <rick_h__> hatch: oh, yea, gotcha
[19:36] <rick_h__> hatch: so nothing to do with different views at all, it's with UX changes that are legit :P
[19:36] <hatch> rick_h__ except if they were a single view, it would be done already lol
[19:36] <rick_h__> carry on blaming something else
[19:36] <hatch> haha
[19:36] <rick_h__> hatch: except that then it wouldn't work because it'd have this conditional home button thing to deal with
[19:36] <hatch> that's fine - huw would have figured that out first :P
[19:37] <rick_h__> hah
[19:37] <rick_h__> benji: does the repeated setting of PYTHONPATH actually append? 
[19:38] <rick_h__> benji: I see it was that way before I guess, but I'd have assumed each would overwrite the others
[19:38] <rick_h__> bah, it's making a call on each one, ignore me
[19:39] <benji> :)
[19:52] <rick_h__> benji: LGTM with a note on the firefox dep. Ideally it could use phantom for that maybe?
[19:53] <benji> rick_h__: I replied about the firefox dependency.  Do those go to email?
[19:54] <rick_h__> benji: yes, and I replied again
[19:54] <rick_h__> :)
[19:54] <benji> ah, cool
[20:02] <rick_h__> hah, thanks benji, /me goes to re-uninstall firefox
[20:02] <benji> :)
[20:03] <rick_h__> I missed the updated commit coming in as I was looking at it
[20:10] <hatch> annnd fixed
[20:11] <hatch> I'm still going to wait to commit it until I can document some of these weird sections from huw
[20:14] <Makyo> Alright.  Down to 1.5s to open inspector with 2000 units, no delays in update..
[20:15] <benji> rick_h__: do I literally write "$$merge$$" as a comment on the pull request?
[20:15] <rick_h__> benji: yes
[20:15] <rick_h__> benji: anywhere in the comment will do
[20:16]  * benji prepairs a wall of text with "$$merge$$" hidden in the middle.
[20:16] <rick_h__> :)
[20:16] <hatch> Makyo right on! 
[20:16] <rick_h__> if settings.get('jenkins.merge.trigger') in message: 
[20:16] <hatch> I'm very intersted to see the code now
[20:18] <hatch> oh Firefox you irritate me
[20:18] <Makyo> It's the same filter, but on object attributes instead of DOM nodes, which I gather is the preferred way to filter; however, pushIntoUnitList now uses the unit as an attribute, rather than as the base object.  
[20:29] <hatch> ahh
[20:29] <hatch> so was there something wrong with what I did? or was it just the way we were passing the data in did not allow it to work?
[20:31] <Makyo> Your solution was okay given the way the data was being passed in, but I think that structure was wrong for d3, and also wrong because of pass-by-reference.  Better to let the framework do what it's good at then try and force it to do something it's not.
[20:32] <hatch> true good point, thanks for making it work :)
[21:03] <gary_poster> Makyo, "no delays in update" is huge.  cool.
[21:03] <Makyo> Yeah.  Now just to make tests work :T
[21:08] <hatch> crap forgot to rebase before pushing
[21:08] <hatch> oh well, next time
[21:10] <hatch> jujugui lf review/qa on the refactor of huws sticky header branch https://github.com/juju/juju-gui/pull/13 
[21:11] <hatch> ya know what....I'm going to try and rebase this...
[21:15] <hatch> yeah rebase isn't gona happen
[21:15] <hatch> to many intermixed commits :/
[21:19] <gary_poster> hatch, looking
[21:19] <hatch> thanks
[21:46] <jcastro> hey gary_poster
[21:46] <jcastro> so don't hate me, but I upgraded to trusty today
[21:46] <gary_poster> hey on call
[21:46] <jcastro> and all the good stuff in the PPA is missing on trusty, just FYI
[21:47] <jcastro> no worries, I like just typing in the channel, that way I can assume you are agreeing
[21:47] <gary_poster> lol
[21:47] <gary_poster> ack
[21:47] <hatch> haha
[21:47] <gary_poster> will investigate
[21:47] <jcastro> marco just updated the charm tools PPA
[21:47] <jcastro> I figure, we'll have to do it anyway
[21:47] <jcastro> and also, FYI, we kicked off the charm audit today though it won't affect you
[21:48] <jcastro> but you should start seeing updates to charms, READMEs, and a bunch of little things
[22:02] <Makyo> Dogwalk, then pull request adventures.
[22:06] <huwshimi> Morning
[22:08] <arosales> gary_poster, et all should I see a relation line between wordpress and nagios for a "juju-info" relation?
[22:08] <gary_poster> arosales, that's typically a subordinate
[22:08] <arosales> I see a relation line for mysql and nagios for a "monitors" relation
[22:09] <gary_poster> you see those by hovering over the wiggle thingon the subordinate
[22:09] <gary_poster> or by clicking on it
[22:09] <arosales> gary_poster, it doesn't looks like its being deployed by the gui as a sub
[22:09] <gary_poster> arosales, I thought nrpe was the subordinate for that case?
[22:10] <arosales> gary_poster, nrpe can be a sub to a service
[22:10] <arosales> that nagios can connect to, I think
[22:10] <arosales> but I don't see a clear way to make nagios a sub of wordpress, at least from the gui
[22:11] <gary_poster> arosales, I don't think you are supposed to.  I think you are supposed to make nrpe a sub of worspress and then connect nrpe to nagios
[22:12] <gary_poster> arosales, I have to go.  if you can confirm, then please file a bug and we will investigate.  AFAIK we are doing the right thing here, so please give me details if we are not
[22:12] <gary_poster> hatch, I ended up with calls :-(
[22:12] <gary_poster> and I have to go now
[22:12] <hatch> ok no problem
[22:12] <arosales> gary_poster, ok thanks
[22:14] <arosales> I see nagios looks to be a sub of mysql, but it isn't displayed in the canvas . . .
[22:14] <gary_poster> hatch I was going to look at consider whether we should do any of the operations on headings in aggregate before doing the calculations.  a probably wrong hunch, but that's been necessary for correct calculations in the past.  Otherwise I like how you structured the code.  Please consider you and Huw as reviewers: if Huw approves what you've done and can qa and branch is < 400 then :+1: :-)
[22:15] <hatch> thanks, I'll take a look at your notes
[22:15] <hatch> huwshimi here is the refactored branch https://github.com/juju/juju-gui/pull/13
[22:16] <gary_poster> arosales, nagios has a "monitors" relationship with mysql, not a subordinate
[22:16] <hatch> it's been cleaned up a bit but you'll notice that the functionality is still identical
[22:16] <huwshimi> hatch: Thanks so much for taking that on!
[22:16] <arosales> gary_poster, ack with mysql, but sub with wordpress
[22:16] <arosales> which isn't shown in the canvas
[22:16] <arosales> gary_poster, I'll let you go
[22:16] <gary_poster> ok ttyl
[22:17] <arosales> perhaps I can bother hatch or someone else willing to confirm.
[22:17] <hatch> arosales sorry I haven't been following....one sec
[22:17] <arosales> hatch basically
[22:17] <arosales> from the canvas
[22:17] <arosales> jujucharms.com
[22:17] <arosales> drag in wordpress
[22:17] <arosales> drag in nagios
[22:18] <arosales> relate the two
[22:18] <hatch> ok
[22:18] <arosales> ~should~ I see a subordinate relationship between the two?
[22:18] <arosales> right now I see nothing in chrome and firefox
[22:18] <arosales> wondering what is the expected behavior
[22:18] <hatch> hmm that's a good questioin
[22:19] <hatch> give me a minute here to take a look
[22:19] <arosales> hatch, I would have expected to see the "squiggle-line" subordinate relation
[22:19] <arosales> if in fact the relation between wordpress and nagios is a sub
[22:19] <arosales> hatch, thanks
[22:21] <hatch> I'm going to agree with you that there should be 'some' type of relation line there
[22:21] <hatch> as far as the GUI can see it's related as a subordinate on juju-info
[22:22] <hatch> however I'm not sure if this is how nagios is supposed to work
[22:23] <hatch> but I suppose that's beside this issue
[22:23] <hatch> there 'should' be some indication that there is a relation there
[22:23] <arosales> I am indeed may be using it incorrectly, but as you said from juju there is a valid relation between the two which I am not seeing
[22:23] <arosales> hatch, are you saying I probably should not be able to build that relation?
[22:24] <hatch> arosales if you deploy nrpe-external-master and relate it to wordpress you will see the line when you hover over the little squiggle thing
[22:25] <hatch> well you should be able to, but I'm not sure if it will actually work
[22:25] <hatch> I'm just looking at the charms metadata right now
[22:26] <arosales> hatch, ok different scenerio
[22:26] <arosales> hatch, https://jujucharms.com/sidebar/search/precise/nagios-4/?text=nagios#bws-readme
[22:26] <hatch> ahh ok I see the issue
[22:26] <arosales> in this case you can add a relation between an microblog (statusnet) and nagios
[22:26] <arosales> per the readme
[22:26] <arosales> *but* the relation is not shown on the canvas
[22:27] <hatch> the nagios charm doesn't specify the `scope` as `container` so we have no idea that it's a subordinate relation 
[22:27] <arosales> I can inspect the service and se there is a relation, but that is the only way
[22:27] <hatch> so this is definitely a bug in the GUI
[22:27] <hatch> one which I'm not sure we have a UX story for however :)
[22:27] <arosales> when I click on wordpress
[22:27] <arosales> and I look at the relation to nagios
[22:27] <hatch> the relation between wordpress and nagios is 'valid' but it's on juju-info which we don't show
[22:27] <arosales> i see the scope as "container"
[22:28] <arosales> interface "juju-info"
[22:28] <hatch> it's not showing as a subordinate because nagios doesn't say its a subordinate
[22:28] <hatch> right....so actually....there are a few issues here
[22:28] <hatch> 1) no relation line is showed because we don't show juju-info relations
[22:29] <hatch> 2) nagios is connecting to wordpress using juju-info which is specified as a container scope....but this is not a subordinate relation
[22:30] <hatch> s/few/couple :)
[22:30] <arosales> per 1) the relation line would be shown _if_ it were a sub correct?
[22:30] <hatch> right 
[22:30] <arosales> hatch, note the statusnet and nagios have the same relationtype
[22:30] <arosales> per the readme
[22:30] <hatch> so should we be showing juju-info relations?
[22:31] <arosales> I guess that is the fundamental question
[22:31] <arosales> there is a relationship
[22:31] <arosales> and it has to be made
[22:31] <hatch> I THINK the issue is with the nagios charm in this case
[22:32] <hatch> it's specifying a juju-info relationship for other nagios clients
[22:32] <hatch> and we are connecting wordpress to it
[22:32] <arosales> I would think if someone linked up the service and it is shown in the inspector it should be represented somehow on the canvas
[22:32] <hatch> at least as far as I understand how this is supposed to operate
[22:32] <arosales> hatch,  check the statusnet readme
[22:32] <hatch> checking
[22:33] <hatch> statusnet charms don't have a readme
[22:33] <arosales> hatch, sorry the nagios readme references statusnet
[22:33] <arosales> https://jujucharms.com/sidebar/search/precise/nagios-4/?text=nagios#bws-readme
[22:34] <hatch> ok checking
[22:34] <arosales> to connect it up to via a juju-info relation
[22:35] <hatch> it can only have a single juju-info relation
[22:35] <hatch> funny those two lines lined up exactly....
[22:35] <hatch> heh anyways!
[22:35] <arosales> ok
[22:36] <arosales> but still not shown on the canvas 
[22:36] <hatch> if we are allowing the relation to be made we should be showing it
[22:36] <hatch> I'm not sure 'how' we want to show it though....
[22:36] <hatch> it IS a real relation I suppose
[22:36] <hatch> so that would be my guess
[22:37] <arosales> if I just deploy statusnet
[22:37] <arosales> and nagios
[22:37] <arosales> and relate them
[22:37] <hatch> you should see a line
[22:37] <arosales> I see now indication on the canvas they are related
[22:37] <hatch> oh I don't
[22:37] <hatch> haha
[22:37] <arosales> only via the inspector do I see an indication of a relation
[22:37] <hatch> oh s/now/no
[22:37] <hatch> right
[22:38] <hatch> we should show a line
[22:38] <arosales> or something to signal a relationship has been made
[22:38] <hatch> I THINK it's supposed to be nagios > nrpe > wordpress
[22:38] <hatch> but that's not up to us as the tool
[22:39] <hatch> we should just show what's happening and leave it up to the user to know not to relate things incorrectly
[22:39] <hatch> so to answer your question....yes this is a bug :)
[22:39] <arosales> ok
[22:39] <hatch> are you going to create the ticket or would you like me to?
[22:40] <arosales> I can create it later tonight
[22:40] <arosales> I was actually preping for a demo tonight on showing the bundle to our user group
[22:40] <hatch> ohh, sorry :)
[22:40] <arosales> over 100 folks planning on being there and I was wondering why I didn't see these relations.
[22:41] <arosales> no worries I am probabaly just not connecting them up right ;-)
[22:41] <arosales> all the other bits are there
[22:41] <arosales> hatch, ping me if get the ticket created. If not  I will create one.
[22:42] <hatch> ok sounds good - you probably want to deploy nrpe, relate it to wordpress (the squiggly thing will show the relation lines) and then relate nrpe to nagios
[22:42] <hatch> but what do I know lol
[22:44] <arosales> we should update the nagios readme if that relation build between nagios and blog is indeed incorrect, or better recommend via nrpe
[22:45] <arosales> hatch, thanks for the help.
[22:45] <hatch> no problem, anytime
[22:47] <hatch> arosales here is the bug https://bugs.launchpad.net/juju-gui/+bug/1259720 feel free to expand with any thoughts or feelings on the matter cc gary_poster 
[22:47] <_mup_> Bug #1259720: Services related on juju-info don't show relation lines <juju-gui:New> <https://launchpad.net/bugs/1259720>
[22:49] <arosales> hatch, thanks
[22:52] <hatch> huwshimi do you have IE on your new machine yet? for qaing the sticky header branch?
[22:52] <huwshimi> hatch: Yep, just moved my vm over
[22:52] <hatch> cool, gota love that :)
[22:58] <huwshimi> hatch: Is that ready for me to review now?
[22:58] <hatch> yep ready to go
[22:59] <huwshimi> hatch: How do I get the branch for QA?
[23:00] <hatch> in your current repo type
[23:00] <hatch> git checkout -b hatched-sticky-header-redux develop
[23:00] <hatch> then
[23:00] <hatch> git pull https://github.com/hatched/juju-gui.git sticky-header-redux
[23:00] <hatch> then you are gtg
[23:01] <hatch> I gota take off for a bit
[23:01] <hatch> I'll check back in later
[23:02] <huwshimi> thanks
[23:37] <hatch> back huwshimi were you able to get it pulled down?
[23:41] <huwshimi> hatch: Yep, thanks!