[00:04] <hatch> huwshimi thanks for the QA, are you doing a review too?
[00:06] <huwshimi> hatch: I'm not sure I know enough to give you a good review
[00:06] <hatch> alright no problem
[00:06] <hatch> thanks
[00:07] <huwshimi> hatch: I mean, there's some red bits and some green bits and the green bits could be a little more green. Does that help?
[00:07] <hatch> lol
[00:11] <rick_h_> huwshimi: hey, side note and heads up. We'll be having the weekly AU call this week. And we'll be doing our 1-1 to go over annual review stuff
[00:11] <huwshimi> rick_h_: Sure!
[00:11] <rick_h_> huwshimi: I know we've fallen a bit off the wagon on those and I want to get back on track after the demo/vegas and such
[00:11] <bac> hey huwshimi
[00:12] <huwshimi> rick_h_: It's all good :)
[00:12] <bac> rick_h_: i'm still working to get the charmworld jenkins working again.  lots of fiddly bits.  i've also requested production be completely restarted to see if that'll solve the unknown issue.
[00:13] <rick_h_> bac: ok, thanks for the heads up. If there's issues with the charmworld jenkins and we can't recover we can look at just taking it over and moving it into our CI. Of course that would probably mean a move to git as well, but wtf. 
[00:14] <rick_h_> kind of bummed to have lost a day on it now. 
[00:14] <rick_h_> bac: do we know what the issue is on the jenkins side?
[00:14] <bac> rick_h_: it should be recoverable, i've just never launched it from scratch before
[00:14] <rick_h_> bac: ah, ok. So you did have to rebuild the env from scratch?
[00:14] <bac> rick_h_: yes.  state server went awol so i had to tear down the env
[00:14] <rick_h_> :(
[00:15] <rick_h_> bac: when we do get it back up let me know. I recover from issues on the gui side by backing up all of /var/lib/jenkins and wonder if there's any backusp of that in the charmworld CI that would help shorten things up. 
[00:17] <huwshimi> rick_h_: Should cancel in the deployer bar really clear all your uncommitted changes or is it just cancelling the deploy?
[00:18] <huwshimi> rick_h_: It seems to me that there should be two actions. 'Cancel deploy' and 'clear uncommitted changes'
[00:19] <bac> rick_h_: jenkins seems to be mostly functional now.  looks like the migration may have introduced a spurious test failure.
[00:25] <rick_h_> huwshimi: hmm, not that cancel. There's supposed to be a cancel on the actual bar while you're working I thought
[00:26] <rick_h_> huwshimi: right, from the summary page, when you hit deploy, I would expect cancel to dump me back to my environment with uncommitted work still there
[00:26] <rick_h_> huwshimi: /me goes to look at designs
[00:26] <huwshimi> rick_h_: https://drive.google.com/a/canonical.com/?usp=folder#folders/0B7XG_QBXNwY1WGlyVzN2LWtrcmM
[00:26] <huwshimi> rick_h_: I can't see anything there.
[00:26] <rick_h_> bac: :/ yay, it's running but now tests don't pass? 
[00:27] <rick_h_> huwshimi: sorry, it was in some mockup I was using to make the cards I guess but isn't there now
[00:27] <rick_h_> huwshimi: maybe shoot luca an email just to make sure and put this card under 'needs specification' in the board
[00:27] <huwshimi> rick_h_: Yeah, I thought there was a clear button as well.
[00:27] <bac> rick_h_: yes.  i'm pushing a branch to disable the new test.
[00:27] <huwshimi> rick_h_: OK, will do.
[00:28] <rick_h_> huwshimi: cool thanks
[00:28] <rick_h_> bac: ok, and then create a card/bug to look into that new test?
[00:28] <bac> yes
[00:28] <rick_h_> bac: sounds like a good plan, thanks for dealing with the pita
[00:29] <bac> umm, pita
[00:30] <rick_h_> pain in the booty
[00:30] <rick_h_> :)
[00:30] <rick_h_> ci issues always strike me as a pita. it's there to just run and run and take a beating and not spend a bunch of time on. I guess everything breaks though. 
[00:39] <huwshimi> rick_h_: I can't reproduce this card: "with il flag: deploy a service, click on a unit from the inspector for the unit details, the charm results shows up." 
[00:39] <rick_h_> huwshimi: ok, I think it's part of the work hatch is doing anyway
[00:40] <rick_h_> huwshimi: just remove that card then please
[00:40] <huwshimi> rick_h_: The 'Upgrade service' links do open the charm details, but I'm pretty sure they're supposed to.
[00:40] <rick_h_> huwshimi: I think it came up during out mad dash around demo material and we must have cleaned it up some
[00:40] <rick_h_> huwshimi: right, it was in the sidebar that the charms shows up
[00:40] <huwshimi> Ah I see
[00:40] <rick_h_> huwshimi: so you'd be in the inspector, click on a unit, and then the sidebar would turn into charm results vs inspector
[00:40] <huwshimi> Yeah, that's not happening anymore
[00:41] <rick_h_> huwshimi: ok, cool then please remove the card
[00:41] <huwshimi> Great!
[00:54] <rick_h_> huwshimi: have you done vegas expenses?
[00:54] <huwshimi> rick_h_: Oh, no I haven't I'll do that now.
[00:54] <rick_h_> huwshimi: thanks
[00:55] <rick_h_> phew, almost done for tonight. One more task. 
[00:56] <hatch> to review my branch???? :P
[00:56] <rick_h_> hatch: ugh, sorry no. I'm going to pass tonight. Brain is about done 
[00:56]  * rick_h_ checks morning schedule
[00:57] <rick_h_> hatch: I should be able to review it before you start tomorrow
[00:57] <hatch> :) np have a good night
[00:57] <rick_h_> hatch: assign it my way or something so I don't forget
[00:58] <rick_h_> man, I had my email under control this morning I swear
[01:01] <rick_h_> Makyo: any chance you're still around? Did you check out Menno's notes in the email?
[01:24] <rick_h_> huwshimi: approived
[01:24] <rick_h_> approved that is
[01:29] <huwshimi> rick_h_: Thanks :)
[01:30] <rick_h_> huwshimi: thanks, amke sure to move the kanban card for that please
[01:36] <huwshimi> ah yes
[03:22] <hatch> anyone have any book recommendations from oreilly? I have a free book and not sure what to get
[03:30] <hatch> hey kadams54  any book recommendations from oreilly? 
[03:31] <kadams54> Seems like I should have since I stopped by their booth and talked awhile at Pycon, but right now I'm drawing a blank… why?
[03:32] <hatch> I have a free book from gophercon
[03:33] <hatch> I'm trying to decide between Python, Clojure, or something-else-totally-not-related
[03:33] <hatch> like R
[03:33] <hatch> could maybe learn some webgl too
[03:33] <hatch> so many options
[03:33] <hatch> so little time
[03:41] <hatch> learning python....1600 pages.....lol
[11:19] <rick_h_> morning frankban 
[11:20] <frankban> hi rick_h_ 
[11:20] <rick_h_> frankban: talked with Ian yesterday and he's offered us any help we need in our refactor/pull apart modules work. 
[11:20] <frankban> rick_h_: great
[11:20] <rick_h_> frankban: ian/wallyworld 
[11:20] <rick_h_> so I feel a nice bit better about that side of things. 
[11:21] <rick_h_> and sounds like work is already started as dave pulled out the 'thirdparty' stuff I think last night
[11:26] <frankban> rick_h_: cool
[11:36] <frankban> uhm freenode keeps disconnecting me
[11:37] <frankban> repeating my last message, not sure if I was disconnected
[11:37] <frankban> rick_h_, redir: I wrote a simple bash script which can help migrating subfolders while juju-core is still bzr: http://pastebin.ubuntu.com/7496993/
[11:46] <rick_h_> frankban: very cool
[12:06] <redir> frankban_: awesome
[12:06] <redir> frankban_: I think that 73 can just be git filter-branch --subdirectory-filter store -- --all
[12:07] <redir> where store is the folder you want to promote
[12:07] <redir> so git filter-branch --subdirectory-filter $folder -- --all
[12:28] <frankban_> redir: cool thanks
[12:30] <frankban_> rick_h_: so, fo we want to preserve the history even for packages that we need to add to existing git project? e.g. juju-core/testing/filetesting -> github/juju/testing/filetetsting
[12:30] <frankban_> s/fo/do
[12:33] <rick_h_> frankban_: I think so if we can
[12:33] <rick_h_> frankban_: we can check with the core team as they've been pulling some other deps out how/what they've been doing for it
[12:33] <rick_h_> there's the conversation around cmd lately for instance
[12:34] <frankban_> rick_h_: I think we can: http://stackoverflow.com/questions/1425892/how-do-you-merge-two-git-repositories
[12:35] <rick_h_> frankban_: cool yea I think it's valuable to be able to go back and git blame/etc a file down the road
[12:35] <frankban_> rick_h_: +1
[12:36] <redir> I haven't done it but I know you can. Which is how a repo can have to parent-less commits
[12:36] <redir> s/to/two 
[12:37] <redir> sorry more than one parent
[12:37]  * redir drinks more coffee
[12:38] <redir> no wait yes two parentless (initial) commits is a repo that is a merge of projects
[12:43] <rick_h_> coffee sounds good, /me goes and gets some
[12:49] <redir> brb
[13:00] <bac> redir, rick_h_: jenkins lander successfully tested and landed a branch.  woo.  qa.mjc is now on r514
[13:01] <bac> after doing some qa on it i'll do a deploy to staging in a little while
[13:02] <bac> need to step afk for a bit.  bbiab.
[13:06] <redir> uh, I'll ask abou the failing ES thing when you're back
[13:07] <rick_h_> bac: woot
[13:12] <redir> rick_h_: frankban_ fwiw: https://github.com/reedobrien/juju-core a core imort with store removed...
[13:15] <frankban_> redir: cool! what command did you use?
[13:17] <redir> frankban_: should we share a doc or a repo or something?
[13:17] <redir> http://paste.ubuntu.com/7497303/
[13:20] <frankban_> redir: maybe so. I guess when we remove code from juju-core we don't want to rewrite its history
[13:21] <redir> frankban_: maybe. I don't know. 
[13:21] <redir> I mean  probably not repeatedly
[13:26] <frankban_> redir: yeah, while I see a value in not having all the unrelated history when we create a new project from a package in core, I guess in juju-core we still want the rm change to be there
[13:26] <redir> you could just `git rm store`
[13:26] <rick_h_> yea, I think you want all the history and such because you want to be able to git co 1.0 
[13:26] <rick_h_> and have it all there/happy
[13:26] <redir> oh tags
[13:27] <redir> I didn't push the tags
[13:27] <rick_h_> I don't see us as rewriting any history in core
[13:27] <redir> fine by me
[13:27] <rick_h_> what's the bonus or advantage? /me is still getting through coffee and not seeing the forest
[13:28] <redir> I don't know that there is. 
[13:28] <redir> less cruft
[13:28] <rick_h_> ok, then yea let's not worry about that
[13:29] <rick_h_> redir: bac there are two cards in landing from yesterday. Are those up to date? Did they land or still waiting on something?
[13:29] <rick_h_> now that the charmworld lander is back up and running
[13:29] <redir> I am not fighting for it... just if I migrate something out, I would migrate it out
[13:30] <rick_h_> redir: yea I don't know it's migrating but moving
[13:30] <rick_h_> and moving doens't write history 
[13:30] <redir> when bac is bac I'll ask about that 027 card
[13:30] <rick_h_> ok cool
[13:30] <redir> rick_h_: true but histlry in store and history in core store may not line up anymore
[13:30] <rick_h_> what about the landing card about the 'migration for ngrams index change'
[13:30] <redir> which history is right?
[13:31] <redir> rick_h_: I think that is held up by 027
[13:31] <rick_h_> redir: ah, gotcha
[13:31] <redir> it may have landed but with that test skipped
[13:32]  * rick_h_ follows links in card to investigate
[13:32] <rick_h_> yep, merged will move card
[13:38] <frankban_> rick_h_, redir: I just completed an investigation about migrating juju-core/testing/filetesting: http://pastebin.ubuntu.com/7497346/  What do you think?
[13:40] <rick_h_> frankban_: that looks good/sound to me. I think we should add that as a doc in the juju-core code on the first one of these we do
[13:40] <rick_h_> frankban_: and then we need to make sure we work with either sinzui or ourselves to get the new package into CI so that we run tests on branches/pull requests of that package
[13:41] <bac> redir: bac is back
[13:42] <frankban_> rick_h_: +1 on adding a doc to juju-core when we have a complete migration document (not just an investigation)
[13:42] <frankban_> rick_h_: could you please review the sanity of the vcs commands? especially git ones
[13:45] <rick_h_> frankban_: so I think the push would need to be git push frankban add-filetesting:add-filetesting
[13:46] <rick_h_> frankban_: well I'd so it that way at least. I'd git co -b add-filetesting
[13:46] <rick_h_> do the merge
[13:46] <rick_h_> and then push it to your fork
[13:46] <rick_h_> and then pull request that back to the origin juju/testing
[13:48] <frankban_> rick_h_: git push worked for me and pushed the changes to frankban/testing. yeah, in the real migration we want to then make a pull request and wait for the branch to land
[13:49] <rick_h_> frankban_: right, I think because you created the branch as a remote branch by adding the frankban/master to the checkout -b command
[13:49] <rick_h_> frankban_: I'm just stating in the more typical workflow you'd have it local, push it to your fork, and then pull request it back to the origin
[13:50] <frankban_> rick_h_: ack
[13:50] <frankban_> rick_h_: I'd ping Ian too for a review of that document if you agree
[13:51] <rick_h_> frankban_: sounds good to me. 
[13:51] <frankban_> rick_h_: cool thanks
[13:51] <rick_h_> frankban_: just make sure we ack that we'll have to adjust that to git-based soon
[13:51] <rick_h_> as he wanted to make that point clear, I think he'd prefer we didn't move forward until that work was done, but I don't think we can handle the delay 
[13:52] <rick_h_> frankban_: also make sure to include sinzui
[13:53] <rick_h_> frankban_: I think there was an issue where a moved dep broke older versions of juju from running because they referred to a dep in the wrong place or something
[13:53] <rick_h_> I don't think we'll hit this as we're moving from within core to outside, and not two different places outside core
[13:53] <rick_h_> but I'd like to make sure
[13:54] <frankban_> rick_h_: yes, we must pay particular attention when we propose the juju-core change
[13:56] <redir> bac: how can I reproduce that fail?
[13:57] <redir> lost scroll I thought it was just really quiet in here.
[13:57] <redir> :)
[13:57] <bac> redir: well, jenkins spins up a fresh system.  perhaps delete everything out of ES and then run 'make test'
[13:59] <redir> bac also a fresh mongo?
[14:00] <bac> redir: well it was specifically complaining about ES.  but, sure.
[14:07] <redir> bac passes
[14:09] <bac> redir: did you see in the output where a lot of the ES values were _na_?
[14:09] <redir> yeah
[14:09] <bac> odd, no?
[14:10] <redir> bac WAG at not being in a green state
[14:10] <redir> maybe we can try waiting for that
[14:11] <bac> we've been down that road...
[14:11] <bac> redir: try running via: bin/test -v -s -x --with-id  charmworld
[14:11] <bac> that's what jenkins does.  maybe it runs in a different order
[14:16] <bac> redir: i'm going to proceed with a rollout to staging.  having r514 on qa.mjc does not show constant server restarts but staging and prod do.
[14:16] <frankban_> rick_h_, redir: email sent
[14:16] <rick_h_> frankban_: ty
[14:17] <bac> redir: if you want to follow along, the guide is at https://docs.google.com/a/canonical.com/document/d/1G6IoLyDz3VSw7lMRL7QUbaKKXropxyVm3uOFYsqKSeU/edit
[14:17] <redir> frankban_: late now, but the paste LGTM...
[14:18] <hatch> I decided last night to go with Introducing Python http://shop.oreilly.com/product/0636920028659.do
[14:18] <frankban_> redir: thank you
[14:18] <rick_h_> hah, we'll make a python dev out of hatch yet
[14:19] <hatch> rick_h_ haha, well I'm interested in machine learning stuff and it seems like people use Python a lot for it
[14:19] <hatch> (for some reason)
[14:19] <redir> bac jenkins flags pass too
[14:19] <rick_h_> hatch: +1
[14:19] <redir> hatch: NLTK FTW
[14:19] <rick_h_> redir: heh, using that for our suggested tags stuff in bookie
[14:19] <hatch> I'll have to check that out
[14:20] <redir> :) 
[14:20] <hatch> R is also very popular for it but I figured Python would do better for my career :)
[14:20] <jcsackett> hatch: yeah, R is not really a growth language. :p
[14:21] <jcsackett> outside of actual labs, anyway.
[14:21] <hatch> closure was also on the list....but maybe after python & go
[14:22] <jcsackett> clojure is neat
[14:22] <hatch> The book hasn't arrived so I'm finally getting to reading Functional Javascript 
[14:23] <hatch> I'll let y'all know how it is in a couple days
[14:23] <rick_h_> cool
[14:24] <redir> bac reading
[14:25] <bac> redir, i created the RT then went to #webops on the canonical IRC and called it to their attention
[14:26] <bac> redir: for your bug, the next thing i can think to do would be to spin  up a fresh container and see if it fails there
[14:26] <redir> bac hal
[14:26] <redir> bac on 12.04 right?
[14:26] <bac> yeah
[14:27] <redir> will do
[14:27] <bac> hal?
[14:27] <redir> bot in #webops
[14:36] <bac> oh, yes, i hadn't paid attention to its name. poor hal, toiling unappreciated.
[14:38] <rick_h_> guihelp tiny review please https://github.com/juju/jenkins-github-lander/pull/11
[14:38] <kadams54> Looking…
[14:39] <hatch> lgtm
[14:39] <hatch> nice the lander has tests
[14:39] <hatch> :)
[14:39] <redir> bac should be completed in 1-2 weeks
[14:39] <bac> redir: the lxc?
[14:39] <rick_h_> hatch: :)
[14:47] <redir> bac the ticket
[14:48] <redir> bac where can I see what the lander "does"
[14:50] <rick_h_> jujugui fyi, updated the lander with that fix. The next person to try to submit a pr and merge/landing please keep an eye out for strange things
[14:50] <redir> jujugui call in 10
[14:50] <rick_h_> monsters and errors and the like
[14:52] <bac> redir: bzr+ssh://chinstrap.canonical.com/~abentley/jenkins-lander
[14:54] <bac> redir: i've pulled the good parts here: https://pastebin.canonical.com/110543/
[14:54] <redir> great b/c I get permission denied..
[14:54] <rick_h_> redir: to what? I'll work out the missing team/etc memberships
[14:55] <rick_h_> oh, chinstrap, not sure about that one
[14:57] <redir> np just trying to reproduce the 027 fail in a container...
[14:57] <redir> like the lander does
[14:59] <rick_h_> jujugui call in 1
[14:59] <bac> redir: you should get access to chinstrap
[15:00] <rick_h_> redir: ^
[15:01] <redir> looks like I have it not on the container
[15:01] <redir> but on my actual machine. bac rick_h_ 
[15:01] <rick_h_> redir: call now?
[15:02] <redir> doho
[15:08] <bac> redir, rick_h_: we should talk about how much effort to put into this test fix.  the migration has worked on prodstack so spending time on that test may not make great sense.
[15:08] <rick_h_> bac: rgr
[15:14] <redir> bac #192 Putting new mapping without creating the filter and analyzer ... ok
[15:15] <redir> in precise container
[15:16] <redir> I love the standups. They are so efficient
[15:16] <redir> and fast
[15:18] <rick_h_> redir: bac so is that ok? let's timebox the test issue to today and if we can't dupe or get anywhere we take another look at the value of the test and move on?
[15:18] <rick_h_> redir: heh, we try to suck everyone's time away 
[15:19] <bac> rick_h_: so do we wait on this test to be fixed before deploying to production?
[15:19] <redir> rick_h_: bac if I had to guess:) Because we like WAGs
[15:19] <rick_h_> bac: no, I think if we've got this working in practice and on the prodstack staging we can call this a follow up card?
[15:19] <bac> rick_h_: b/c after deploying the migration will have been done and the test has no value.
[15:19] <redir> rick_h_: bac: I would guess there is an environmentdifference where that failure occurs
[15:20] <rick_h_> redir: yes, which we should be aware of for sure. However if that env difference doesn't effect prodstack deployments it's an env issue we can solve out of band 
[15:20] <rick_h_> imo and all that 
[15:21] <bac> rick_h_: my biggest issue for now is the constant server restarting on production and staging, but not QA.  staging and qa have the same code base.
[15:22] <rick_h_> bac: right, so we'll see if a deploy catching something? 
[15:22]  * redir has an idea
[15:22] <rick_h_> bac: shall we jump back in the standup hangout?
[15:22] <bac> rick_h_: i didn't understand what you wrote
[15:22] <bac> rick_h_: ok
[15:22] <rick_h_> redir: ^
[15:26] <frankban_> rick_h_: I forgot to add a quickstart card to the backlog. It might be interesting to have some integration tests for quickstart. This way, having the suite included in the juju-core CI, we will be able to actually test quickstart on live environments using both current and development versions of juju. It could be a nice idea to include this work in the future development (midterm?)
[15:30] <hatch> has anyone used the Kobo aura hd? http://www.kobo.com/koboaurahd
[15:32] <rick_h_> I have a friend that had a kobo for a few years and they angered him and he has left them
[15:33] <hatch> everyone I know has kobos and has sold their kindles for them, but none have the aura hd
[15:33] <hatch> what did they do to anger him?
[15:33] <hatch> bad hardware?
[15:34] <rick_h_> they had some software bugs and they at first tried sending different devices and after still having issues basically told him to $$$$ off
[15:34] <hatch> ahh - that's no good
[15:34] <hatch> I dislike reading on a tablet but I have so many ebooks now I need some way to read them that doesn't suck
[15:35] <hatch> and so far I've not been impressed with the eink hardware
[15:35] <hatch> but this aura looks fancy
[15:36] <hatch> it looks like amazon has dropped eink? https://kindle.amazon.com/ only a big image for the tablet
[15:36] <rick_h_> heh, paperwhite is the best kindle
[15:38] <hatch> spec wise the aura beats anythign else on the market it looks like
[15:38] <hatch> quite a bit heavier than the paperwhite though
[15:39] <hatch> but bigger and higher resolution screen on the aura
[15:39] <hatch> heh
[15:39] <rick_h_> <3 my paperwhite though for tech books the size isn't the best
[15:39] <rick_h_> I mainly use the paperwhite for fiction/wordy reading vs tech code and the like
[15:41] <hatch> oh kindle doesn't do epub?
[15:41] <hatch> well that's a deal breaker right there hah
[15:41] <rick_h_> no :(
[15:41] <hatch> all of my books are epubs
[15:45] <Makyo> jujugui quick review/QA https://github.com/juju/juju-gui/pull/337
[15:45] <redir> all your books are belong to us
[15:45] <hatch> Makyo no qa instructions? *sadface*
[15:45] <hatch> redir no DRM here!
[15:45] <Makyo> hatch, Oops, sorry, forgot that.  ONe sec, will add a comment.
[15:46] <kadams54> jujugui Anyone know how the ID on the ServiceUnit model gets set?
[15:47] <Makyo> hatch, added, see https://bugs.launchpad.net/juju-gui/+bug/1292454
[15:47] <_mup_> Bug #1292454: Subordinate relationship lines show green until moved on the canvas <juju-gui:Triaged> <https://launchpad.net/bugs/1292454>
[15:48] <redir> bac should that 207 fail be attached to a bug or anythign
[15:48] <redir> >
[15:48]  * Makyo makes another coffee, since the first one didn't do the job
[15:48] <redir> ?
[15:48] <hatch> kadams54 when it's added to the modellist
[15:49]  * redir need another pot of coffee
[15:49] <redir> or tea
[15:49] <frankban_> kadams54: it gets set when the mega-watcher data arrives, in handlers.js
[15:49] <bac> redir: 207?
[15:49] <redir> bac sorry 027 migration fail
[15:50] <bac> redir: there is a card for it.  sure be sufficient
[15:50] <bac> s/sure/should/
[15:50] <hatch> yay no more renderTo
[15:50] <bac> redir: bugs are nice but i think we agreed they are only required if it is a longer-term issue or if it won't be started pretty much immediately
[15:52] <kadams54> hatch: I didn't see any code (specifically in _setDefaultsAndCalculatedValues) that would set the ID when adding to the ModelList. frankban: in the unitInfo method (line 183)?
[15:52] <bac> rick_h_: the charmworld charm start hook just calls charmworld/scripts/run which uses gunicorn_paster -D -- does that automatically restart workers?
[15:52] <hatch> kadams54 yes 183 is correct
[15:52] <hatch> see the db.units.process_delta() method
[15:53] <hatch> for how it processes the delta
[15:53] <kadams54> Got it, thanks…
[15:53] <hatch> but you see in the unitInfo method that it assigns the value from change.Name to id
[15:54] <rick_h_> bac: looking, the -D it just daemonize. I don't think it does any auto restarting
[15:55] <redir> bac cool, just wanted to make sure before I commited
[15:55] <redir> push is hanging...
[15:56] <rick_h_> bac: ok, so the scripts/run in charmworld has a max-requests of 250
[15:57] <rick_h_> bac: so ever 250 requests the worker is restarted
[15:57] <rick_h_> bac: and there's supposed to be 3 workers running at any given time
[15:57] <bac> rick_h_: yep
[15:57] <rick_h_> bac: but this restarting thing seemed bigger than just gunicorn doing worker management?
[15:58] <rick_h_> bac: I guess we can test it by watching top for hte worker processes and hitting the site with 1k requests and seeing if we can force the issue
[15:58] <bac> rick_h_: it is registering a new init every 2-3 minutes
[15:58] <rick_h_> bac: is it exact or just roughtly? what is a 'new init'?
[15:59] <rick_h_> bac: maybe we're getting hammered from outside traffic? Seems odd though. Ingest maybe? hitting for proof?
[15:59] <bac> rick_h_: charmworld init puts the server start time into mongo.  by looking at /heartbeat you can see the last start time.  it seems to be every couple of minutes.  any new worker would overwrite that time
[16:00] <bac> rick_h_: but i'm not just chasing this academically.  we have seen performance issues.
[16:00] <rick_h_> bac: ok, so I'd be curious to look at the apache request logs in front of the service?
[16:03] <redir> is bazaar.launchpad.com:22 not working? 
[16:03] <redir> can't push or pull
[16:03] <rick_h_> redir: testing
[16:03] <rick_h_> redir: bzr branch lp:charmworld just worked for me
[16:05] <redir> -v does nothing
[16:05] <redir> mmm
[16:06] <bac> redir: what cmd are you using?
[16:06] <redir> pretty complicated one
[16:06] <redir> bzr push
[16:07] <bac> can you try using the lp: addressing?
[16:07] <rick_h_> redir: can you just bzr branch lp:charmworld? 
[16:07] <rick_h_> into a tmp dir?
[16:08] <redir> says: Using saved push location: lp:~reedobrien/charmworld/027test-fails
[16:08] <redir> and hangs
[16:09] <redir> whup
[16:10] <redir> hangon
[16:10] <rick_h_> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~reedobrien/charmworld/027test-fails/"
[16:10] <rick_h_> when I try to pull it down
[16:10] <redir> rick_h_: was just pushing for the first time
[16:10] <rick_h_> redir: ah, gotcha
[16:11] <redir> ssh controlsocket issue
[16:11] <redir> just pushed again
[16:11] <redir> controlmaster socket
[16:17]  * rick_h_ lunches
[16:17] <redir> bac: http://bit.ly/1nf0yAo
[16:18] <redir> ^merge request
[16:18] <redir> or should I just do that myself
[16:21] <hatch> rick_h_ are you ok with me leaving caching out of this conversion since it's to be re-written this cycle?
[16:21] <redir> thanks for testing that rick_h_
[16:23] <redir> bac: self approved...
[16:29] <hatch> jujugui has anyone run into an issue where the linter thinks something is undocumented when it is documented?
[16:32] <kadams54> nope
[16:32] <rick_h_> hatch: yes, I think so. There are cards to revisit it and I think pulling it is legit for this brfanch
[16:33] <hatch> rick_h_ ok thx - now I just need to figure out why the heck I can't get lint to pass
[16:34] <rick_h_> hatch: if it's not obvious throw up the pull request and reviewer comment the issue and can help look/get eyeballs on it
[16:35] <hatch> whats the make command for generating the undocumented list?
[16:36] <hatch> ahh undocumented
[16:38] <redir> bac wait for green status FTW
[16:40] <hatch> rick_h_ https://github.com/juju/juju-gui/pull/338/files no tests yet but 100% functional 
[16:40] <hatch> well....80% (no cache)
[16:40] <rick_h_> hatch: cool, will look in a few min
[16:40] <hatch> sure, no rush, I'm going to review/qa Makyo's branch now
[16:41] <rick_h_> hatch: existing tests pass?
[16:41] <hatch> only because I haven't removed the old code
[16:41] <hatch> they will need to be entirely re-written
[16:41] <hatch> well....ported I guess
[16:41] <rick_h_> ok, i like that wording better :)
[16:42] <hatch> haha
[16:47] <hatch> Makyo the qa is doing the same issue as it does before....did I need to use any of the flags?
[16:47] <hatch> ie) the lines don't turn grey until they are moved
[16:48] <hatch> and it's making requests for the relation icons all the time again....I thought this was fixed?
[16:48] <hatch> anywho's lemme know when you pop back
[16:48] <rick_h_> hatch: check the icons on comingsono and see if it's just a regression in the current branch
[16:50] <hatch> appears to be doing it on comingsoon as well
[16:51] <rick_h_> hatch: k, bug/card please and we'll address it. I thought it was fixed. I think I reviewed the branch. 
[16:51] <rick_h_> but we might have regressed on it and will see
[16:52] <hatch> ok now it's not doing it on comingsoon
[16:52] <rick_h_> lol
[16:52] <hatch> the lines are also grey on comingsoon
[16:52] <hatch> iunno what's going on
[17:03] <Makyo> Man, what the hell.
[17:03] <Makyo> It was working this morning.
[17:03] <Makyo> Wonder if the diff got messed up.
[17:06] <Makyo> hatch, it's a race with some async stuff, so if comingsoon is running slower, it'll appear to work there.
[17:06] <hatch> Makyo ok cool
[17:07] <hatch> can you reproduce that it doesn't work on your branch though?
[17:07] <Makyo> hatch, rick_h_ ditto the relation icons.  It will appear to load them twice - as soon as the env receives data that the relation is actually a subordinate (that info isn't part of the bundles), it will re-request the icons for its relation lines.
[17:07] <Makyo> Yeah.  My guess is that my computer was running slower this morning when it was working, and now things have speeded up.  I haaaate this >:/
[17:07] <hatch> Makyo with the simulator running it will continue to request the icons over and over
[17:08] <Makyo> Not seeing that.
[17:08] <Makyo> One thing at a time, though, please.
[17:08] <hatch> watch the terminal logs with the simulator running with the complex web example
[17:08] <Makyo> One thing at a time, though, please :)
[17:08] <hatch> or the network tab for that matter
[17:08] <hatch> right - I'm just saying this branch (somehow) re-introduced that
[17:08] <Makyo> Sure, but I can't focus on that right now.
[17:22] <Makyo> Something goin on with charmworld?
[17:23] <Makyo> I'm getting random undefined charms.
[17:23] <Makyo> jujugui ^
[17:24] <rick_h_> Makyo: it's got a restarting issue that is being investigated
[17:24] <hatch> Makyo I haven't seen that here yet, but yesterday charms were disappearing and appearing 
[17:24] <Makyo> Okay.
[17:24] <hatch> now to....port tests
[17:24] <hatch> ugh
[17:25] <hatch> I suppose the easiest way would be to just delete the file and see what fails :D
[17:26] <redir> bac the test passes. I don't know why it runs twice and fails itself the second time, apparently because there isn't really a merge.
[17:26] <redir> I am going to take myself for a walk before tackling the next thing. bbiab.
[17:27] <Makyo> Okay, I'm going to make food.  Disappearing charms making me crazy.
[17:27] <Makyo> As soon as I say that, they come back.
[17:28] <hatch> haha
[17:31] <hatch> rick_h_ replied to your comments
[17:33] <rick_h_> hatch: coolio
[17:36] <bac> redir: yeah, i saw that before.  unsure what jenkins is thinking.  thanks for getting the test to work.
[17:36] <kadams54> AFK for a lunch break.
[17:39] <bac> redir: you'll see jenkins did the same for 75/76
[17:39] <hatch> rick_h_ re bug #1321838 I have no idea what you're saying :) 
[17:39] <_mup_> Bug #1321838: gui exports a export.yaml vs a bundle.yaml <juju-gui:Triaged> <https://launchpad.net/bugs/1321838>
[17:39] <rick_h_> hatch: hit export and the file is called export.yaml
[17:40] <rick_h_> hatch: but to submit a bundle you need a file named bundle.yaml
[17:40] <rick_h_> hatch: it's one more step for no good reason 
[17:40] <rick_h_> to rename the file
[17:40] <rick_h_> hatch: wording advice welcome 
[17:40] <hatch> ohhh ok now I get it
[17:43] <hatch> rick_h_ reworded for my feeble brain 
[17:43] <rick_h_> hatch: ty
[17:56] <redir> bac yeah I looked back through a couple and saw that
[18:09] <redir> chromium keeps crashing today:(
[18:16] <kadams54> guihelp: is a unit's ID changed in any way once it gets placed on a machine?
[18:17] <bac> rick_h_: it looks like the server start issue may just be a red herring.  over the last 11 hours apache has logged about 152 req/min, so with three workers and 250 max-request we'd expect to see a natural death every 4.9 minutes.  of course those requests are not evenly spaced, probably bunched up after US came on-line today.  so, i think what we are seeing is not an issue.
[18:17] <Makyo> kadams54, no.  Units and services can't be renamed.
[18:17] <bac> redir: ^^
[18:18] <kadams54> Makyo: thanks
[18:18] <bac> rick_h_: it *did* seem to coincide with performance issues...
[18:18] <redir> bac OK
[18:18] <bac> redir: that make sense or am i mad?
[18:18] <redir> still weird that the app thinks it restarted
[18:18] <redir> nothing in the logs?
[18:18] <redir> no errors?
[18:19] <bac> no
[18:19] <bac> logging on charmworld is a huge wart
[18:19] <redir> though there wouldnt' be app errors i nteh log if not using mod_wsgi
[18:19] <bac> redir: quick hangout?
[18:19] <redir> bac There must be a witch under all those warts, since it "works".
[18:19] <redir> sure
[18:19] <bac> redir: normal bat channel
[18:36] <hatch> jcastro are you around?
[18:40] <jcastro> YO
[18:41] <hatch> jcastro: if a guy asks "how do i get started with Juju" where do you point them?
[18:41] <jcastro> https://juju.ubuntu.com/docs/getting-started.html
[18:41] <jcastro> come on dude, the URL is literally getting started. :)
[18:42] <jcastro> has inline videos and everything
[18:42] <rick_h_> lol
[18:42] <hatch> haha, well it's a few steps to get there from juju.ubuntu.com
[18:44] <jcastro> yeah, but I don't have control over that. :-/
[18:45] <hatch> it's a known problem? :)
[18:45] <hatch> I've never really looked before heh
[18:46] <jcastro> hatch, if you guys can get me quickstart on osx and windows I can really trim that page
[18:46] <bac> jcastro: os x is underway
[18:47] <rick_h_> bac: is our hero
[18:47] <rick_h_> osx hero
[18:55] <redir> bac, rick_h_ : I can see the start time update each time I send a slew of requests at it locally
[18:55] <redir> I think rick_h_ was right, each 250 requests the procs get killed and restarted
[18:56] <redir> with a new start time
[18:56] <bac> thanks for confirming redir
[18:57] <bac> i'm making a slack task for cleaning up /heartbeat to be less confusing.  includes rewording that entry and removing the API2 featured entry since it is data-driven and not a measure of health
[19:00] <rick_h_> redir: bac yea, we should get the apache logs and make sure we're not getting spammed or something as well
[19:00] <bac> rick_h_: i have the logs and posted summary a little while ago
[19:00] <rick_h_> redir: bac especially as something is causing the site to misbehave. charms were leaving/arriving again and Makyo was hitting issues with getting responses
[19:03] <bac> rick_h_: 70% of the traffic is from gsa-crawler
[19:04] <redir> bac is that google-bot?
[19:04] <redir> or the gov't crawler?
[19:05] <bac> google search appliance
[19:05] <redir> I can see the problem of 3 simultaneous requests coming in and all 3 procs getting killed and restarted impacting performance too bac, rick_h_ 
[19:05] <redir> OIC internal
[19:07] <bac> redir: gsa implies it is an internal appliance?
[19:10] <redir> bac my only experience with gsa is -- it is a blue box you buy^H^H^Hlease from google, stick in a rack and point at sites to crawl
[19:10] <redir> unliess this is a different appliance
[19:12] <bac> redir, rick_h_: confirmed it is an internal search appliance that is pounding charmworld
[19:13] <redir> bac IIRC you pay by documents indexed, so I haven't heard of anyone pointing it outside their own domain
[19:13] <redir> we used them in gov't to index non public docs...
[19:14] <redir> so what to work on next
[19:14]  * redir goes to look at kan ban
[19:27] <rick_h_> redir: can you setup a hangout? I've got something for you :)
[19:42] <hatch> a cookie? can I have a cookie?
[19:42] <hatch> :P
[19:47]  * redir hands hatch a cookie
[19:47] <hatch> yussss!
[19:48] <hatch> http://i.imgur.com/7BbY4.gif
[19:51] <bac> rick_h_: the internal appliance was updated last friday.  IS is turning it down from '4' to '2'
[19:53] <rick_h_> bac: ok
[19:54] <rick_h_> bac: I still think something else is up. I'm not sure why this would cause charms to appear/disappear as Makyo and hatch have noticed the last two days
[19:55] <redir> bac where is your localcharm doc?
[19:55] <redir> rick_h_: will login access be needed?
[19:56] <bac> redir: i'm not sure what you want
[19:56] <redir> mmm
[19:56] <redir> me neither
[19:56] <rick_h_> redir: login to what?
[19:56] <bac> the doc for deploying charmworld in an lxc?
[19:56] <redir> you added the ability to imoprt localcharms.
[19:56] <rick_h_> bac redir the local charms laoded into charmworld
[19:56] <bac> ah, that
[19:56] <redir> that is doc'ed somewhere right, bac?
[19:57] <redir> rick_h_: will charmworld login access be needed?
[19:57] <redir> by the dude
[19:57] <bac> https://docs.google.com/a/canonical.com/document/d/1KZoFKN7-Qo9AIyBrPnSak-1iAX4QepfbEO3qtfn2xxs/edit#heading=h.m1v3i5yotjq3
[19:57] <bac> redir, rick_h_: ^^  -- it references a doc that was specific to the ATL demo, i.e. deploying to MAAS
[19:58] <rick_h_> thanks bac, redir needs to crib it for a partner that needs to be able to do something like this
[19:58] <bac> redir: local ingestion is also discussed briefly in charmworld/docs/index.rst
[19:59] <redir> merci bac
[19:59] <bac> de nada
[19:59] <rick_h_> bah, I looked all over but not in index
[20:39] <kadams54> guihelp: https://github.com/juju/juju-gui/pull/339 is ready for QA and review
[20:45] <hatch> kadams54 I can, but I'm powering on my own tests right now, so if noone steps up I'll get it done before my EOD
[20:47] <rick_h_> kadams54: hitting my EOD, if needed I can look in the morning
[20:47] <rick_h_> to which I say, have a good night all, /me runs away
[20:51] <bac> redir: could you QA the ngram stuff against staging.manage.jujucharms.com?  i'm hoping to release r154 first thing in the a.m.
[20:51] <bac> s/r154/r514/
[20:52] <redir> bac that means setting up juju gui and pointing it at that?
[20:52] <redir> rightt?
[20:52] <bac> redir: or just curling
[20:53] <redir> duh
[20:53]  * redir pulls foot from mouth
[21:06]  * bac walk
[21:16] <redir> bac are there any bundles up there?
[21:32] <redir> bac so ngrams work
[21:33] <redir> http://staging.manage.jujucharms.com/api/3/search?text=ngrams:sql
[21:34] <redir> gets me a bunch of sql
[21:34] <redir> http://staging.manage.jujucharms.com/api/3/search?text=ouc does not however
[21:35] <redir> http://staging.manage.jujucharms.com/api/3/search?text=ngrams:sql%20AND%20series:trusty 
[21:36] <redir> gets me all kinds of sql things, but only from the trusty distro series
[21:37] <redir> and http://staging.manage.jujucharms.com/api/3/search?text=ngrams:sql%20AND%20series:trusty%20NOT%20categories:databases
[21:37] <redir> gets me things with sql in the name from the trusty series not listed as databases in categories
[22:22] <hatch> 13 test downs, 5 more to go
[22:31] <hatch> I've found that if I run this mbp on the highest resolution setting chrome doesn't tear while scrolling
[22:31] <hatch> interesting...
[22:34] <rick_h_> redir: bac so we need to create a follow up card to enable ngram search in the gui it looks like?
[22:34] <rick_h_> redir: bac how does a search for charm:sugar get to work with ngrams? 
[23:03] <huwshimi> Morning
[23:04] <rick_h_> morning huwshimi 
[23:14] <hatch> morning huwshimi 
[23:15] <hatch> I have finally finished the first leg of this conversion
[23:15] <hatch> phew*
[23:21] <hatch> jujugui I'm looking for a review/qa on the first step of converging the curated(editorial) and search results views https://github.com/juju/juju-gui/pull/338
[23:22] <hatch> rick_h_ I won't be able to get to kadams branch today, sorry you'll have to do it in the am :)
[23:22] <hatch> or someone :)
[23:36] <hazmat> hatch, where was that conversation? #general?
[23:51] <hatch> hazmat are you in the Slack community?
[23:51] <hazmat> hatch, no idea what that is
[23:52] <hazmat> hatch, also btw +1 awesome
[23:52] <hatch> :-) thanks
[23:52] <hatch> https://slack.com/
[23:52] <hatch> this is slack
[23:52] <hatch> one sec while I get you the info to get signed up
[23:52] <hatch> you need to email them
[23:52] <hazmat> oh.. this like hipchat?
[23:53] <hatch> http://blog.gopheracademy.com/gophers-slack-community
[23:53]  * hazmat is constantly amazed at the many reimplemnations of irc ;-)
[23:53] <hatch> yeah, or like the 100 other versions of the same thing
[23:53] <hatch> haha
[23:53] <hatch> yeah - I'm not a huge proponent of it, but it has some cool features and the community is great, so if it allows them to keep the riffraff out I'm ok with it :)
[23:54]  * hazmat hands +mod
[23:54] <hazmat> every startup i've talked to in the last year is using hipchat.com .. basically as more universal irc
[23:55] <hatch> ahh, when I was contracting a lot I worked with were using https://www.flowdock.com/
[23:56] <hatch> I'm not really sure what the difference is, but Slack has this cool bot which asks you questions in a chat to fill out your profile hah
[23:56] <hatch> I thought it was pretty cool
[23:56] <hazmat> nice
[23:57] <hatch> it's great when people who are totally unrelated to the project use it and are blown away