[08:05] <rick_h> Makyo: http://jsbin.com/ENIbojO/1/ checking console logs
[09:08] <gary_poster> rick_h, http://www.tasrestaurants.co.uk/pide.html
[09:50] <antdillon> gary_poster, Do you by any chance have admin rights for juju.ubuntu.com?
[09:50] <gary_poster> no, sorry antdillon 
[09:50] <antdillon> gary_poster, Thanks
[09:50] <gary_poster> ...for nothing ;-)
[09:53] <bac> adeuring: the wait_for_green effort is not workable.  jenkins is taking over 3 hours to test and land branches.  sinzui and i decided it is best for now to revert your branch.  would you have time to prepare a rollback branch and propose it?
[09:55] <adeuring> bac: yes, though "yellow" will help only partially. I think I have meanwhile an idea what is wrong: the core setup. /etc/elasticsearch/elasticsearch.yml allows to set the parameters number_of_replicas and number_of_shards. The default is 5 and 1, respectively, and at least our dev environment has no replicas...
[09:55] <adeuring> Using the value 1 and zero helps. 
[09:56] <adeuring> But I'd like to set this in create_index(), but xould not yet figure out the right parameters...
[10:29] <huwshimi> luca__: Icons required: eye, spanner, cog (plus hover states if applicable) and trash can.
[10:47] <adeuring> bac: can you have a look here https://code.launchpad.net/~adeuring/charmworld/set_n_replicas_and_shards/+merge/183846  (and please test the branch too ;)
[10:50] <hatch> http://askubuntu.com/questions/73589/higher-screen-resolution-for-virtualbox
[11:13] <huwshimi> jujugui: Can I have a review of my inspector changes? https://codereview.appspot.com/13521043/
[12:07] <bac> adeuring: i ran your new branch and got:
[12:07] <bac> Ran 726 tests in 88.575s
[12:07] <bac> FAILED (errors=7, failures=4)
[12:08] <bac> so it is faster
[12:09] <adeuring> bac: great. Can you show me the errors?
[12:10] <bac> adeuring: many refer to es client not having 'multi_get'.  http://paste.ubuntu.com/6062400/
[12:11] <adeuring> bac: thanks. 
[12:14] <adeuring> bac: WHich version of pyelasticsearch is installed on your machine? It's 0.6 on my machine and multgi_get is defined there.
[12:16] <bac> adeuring: it is installed by charmworld setup in the venv.  requirements.txt:pyelasticsearch==0.6
[12:16] <adeuring> weird...
[12:16] <bac> i do not have it installed in my system python
[12:20] <adeuring> bac: right; but it is  strange that class ElasticSearch defines a method multi_get() and we get a failure like this AttributeError... I'm just trying to figure out how this can happen
[12:20] <bac> adeuring: i'll drop into pdb and see if i can figure it out
[12:21] <Makyo> rick_h, https://gist.github.com/makyo/6436215
[12:21] <benji> back and adeuring: let me know if there is anything I can do
[12:23] <adeuring> benji: I am really puzlled by most of these errors: http://paste.ubuntu.com/6062400/ If you can reproduce them (using lp:~adeuring/charmworld/set_n_replicas_and_shards) and try to figure out what's causing them -- that would be great.
[12:24] <benji> adeuring: I'll see if I can repro
[12:24] <adeuring> thanks
[12:25] <adeuring> be, bac: The last error (in test_search_charm_sort_newest) looks familiar. I think it is caused by search() not using any yorting by defualt.
[12:28] <Makyo> hatch, huwshimi http://www.popvssoda.com/
[12:28] <bac> adeuring: turns out my pyelasticsearch was still 0.4.1.  i didn't do a 'make deps' after it got upgraded
[12:28] <adeuring> bac, benji: ah, that explains a few problems ;)
[12:29] <benji> ooh
[12:30] <benji> deps really should be a dependency of install
[12:36] <benji> adeuring: after a "make deps" I only get one failure: http://paste.ubuntu.com/6062493/
[12:38] <adeuring> benji: cool. can you reproduce this eror more or less reliably? In that case, could you try to add index_client.wait_for-green_status() before the get_:mapping() call in this test?
[12:39] <benji> I'm doing a second run now to see.  If so I'll add that call and see.
[12:50] <bac> adeuring, benji: running abel's branch i get only one failure http://paste.ubuntu.com/6062553/
[12:51] <bac> different from benji's
[12:51] <benji> heh
[12:51] <benji> and my tests are still slow :(
[12:52] <bac> that test fails in isolation?
[12:52] <adeuring> bac: sounds great. I think we need a better test setup here. I can this error too occasionally... I believe that api_search() does not specify any sort order by default.
[12:52] <bac> benji: still slow?  huh.  mine are at 100s or so
[12:52] <benji> bac: I haven't checked that one
[12:53] <bac> adeuring, benji: also, i have a simple fix to the openid log pollution in the test output
[12:53] <benji> after a "make distclean"... wait!  I was running in the wrong darn branch
[12:53] <adeuring> benji: did you try to restart the ES server?
[12:53] <benji> bac and adeuring: ooh, and I noticed that I have two failures, not one.  And the one I missed is the same bac had
[12:54]  * benji needs to go for a mind-clearing jog or something.
[12:54] <adeuring> benji: I'll look into this "sort issue"
[12:55] <benji> bac and adeuring: I get bac's failure when I run that test in isolation
[12:55] <bac> adeuring: would you have a look at lp:~bac/charmworld/timeout-values ?  reviewing the documentation it seems for the health checks the timeout values should be strings
[12:55]  * adeuring is looking
[12:57] <bac> jcsackett: do you know if sinzui is in today?
[12:57] <bac> jcsackett: do you have access to charmworld staging?
[12:58] <bac> jcsackett: management access via juju, i mean
[12:58] <adeuring> bac: Right, I think I've tried this before but then thought that I could specify integers (meaning milliseconds) too. But explicitly speicfying a unit sounds reasonable.
[12:59] <bac> adeuring: other calls indicate they want an integer specifying seconds not milliseconds
[12:59] <bac> adeuring: please merge that branch into yours for a single landing if you agree
[12:59] <bac> adeuring: do you have access to staging via juju?
[13:01] <adeuring> bac: sure, i'll merge it. But I am a bit puzzled that an integer would mean seconds, not millisecondes. And yes, I have meanwhile juju access to staging.
[13:01] <bac> adeuring: i'm seeing this when trying to access staging
[13:01] <bac> 2013-09-04 09:01:17,726 INFO Connecting to environment...
[13:01] <bac> 2013-09-04 09:01:19,284 ERROR juju environment not found: is the environment bootstrapped?
[13:02] <bac> when running  /usr/bin/juju status -e staging
[13:02] <bac> adeuring: can you see if you can simply get status via juju?
[13:03] <adeuring> bac: I'm getting the same error.
[13:03] <bac> ugh
[13:03] <bac> yay!
[13:03] <bac> good morning sinzui!
[13:04] <sinzui> Good? I am not going to commit to such an accusation. I will simply state the obvious. Morning bac
[13:05] <bac> sinzui: it is good b/c you're here.  hey, both adeuring and i are inable to access staging via juju.  "juju status -e staging" reports the environment isn't up
[13:05] <bac> s/inable/unable
[13:05] <sinzui> ah
[13:06]  * sinzui wonders if canonistack has toppled juju
[13:06] <benji> bac and adeuring: test run time for me is 115s and on the last run I only got bac's failure
[13:07] <adeuring> \o/
[13:07] <bac> sinzui: the web app is running
[13:07] <bac> benji: let's not call this 'bac's failure'
[13:07] <benji> heh
[13:08] <benji> "the bacobian abnormality"
[13:08] <sinzui> bac, adeuring :( I was tempted to write kirkland to say canonistack has bad weeks and good months. We have completed a good month. This is out bad week
[13:09] <adeuring> yeah... though I found one setup issue we had with elasticsearch since we began to use it...
[13:09] <sinzui> bac, adeuring. I suspect the state server and possibly the agents are zombies. I have fixed this situation in the past by rebooting the the instances via nova
[13:09]  * sinzui checks that he documented this
[13:12] <bac> adeuring, benji: i propose abel disable the failing test, land the branch, and then leisurely try to fix the test.  the rest of us need the test speed-up now.
[13:12] <benji> +1
[13:12] <adeuring> ok, let me just save the fixes i have in place. ES is real fun to work with :(
[13:14] <bac> benji: fwiw i'm now seeing the full suite run in ~90s
[13:14] <sinzui> bac: I think this issue is like the first 3 reported problems in https://docs.google.com/a/canonical.com/document/d/190xKLPpEPSrlVix4D9eX_aTciiKFo12h0u7MpzqI28I/edit# . Per the doc, I just sshed and rebooted the state server (instance 0)
[13:14] <benji> bac: sounds good (my machine is a tad slow, so I would expect mine to give slightly longer run times)
[13:15] <rick_h> abentley: ping, got a sec to chat search?
[13:16] <abentley> rick_h: sure.  juju-gui?
[13:16] <rick_h> abentley: well figured I'd ask here. I noticed the docs note some extra fields to search on, summary, etc?
[13:16] <bac> sinzui: i didn't realize i could ssh natively, thought i had to use 'juju ssh'.
[13:16] <rick_h> abentley: but it comes back as not supported: http://staging.jujucharms.com/api/2/charms?summary=apache
[13:17] <rick_h> abentley: and http://staging.jujucharms.com/api/3/search?summary=apache
[13:17] <sinzui> bac, yeah. We always have the cloud's tools to use, but I too am not as versed in them as I am Juju
[13:17] <rick_h> abentley: is this intended to work? I was looking at the bugs around m_3 about wanting to search more data and I was trying to see how we might do that currently.
[13:17] <abentley> rick_h: What the docs mean is that if you do http://staging.jujucharms.com/api/3/search?text=apache, one of the the things searched is the summary field.
[13:17] <rick_h> abentley: ooooh, ok. 
[13:18] <bac> sinzui: can you grant me edit to that doc?
[13:18] <adeuring> bac, benji, sinzui: so, here is the MP: https://code.launchpad.net/~adeuring/charmworld/set_n_replicas_and_shards/+merge/183846
[13:18] <sinzui> bac: done
[13:18] <benji> adeuring: I'll review it
[13:19] <sinzui> The state servers logs still say they cannot talk to the zookeeper. Looks like the monkeys are loose.
[13:21] <sinzui> abentley, bac, benji, adeuring. If I don't have this sorted out soon, I propose we redeploy the stack since that is 20 minutes at most
[13:21] <benji> +1
[13:23] <benji> adeuring: the branch looks good to me; I had a question that is bigger than the branch and shouldn't block its landing
[13:24] <abentley> sinzui: This is probably not the right time, but now that canonistack has a much larger floating IP range, we can start looking at using gojuju instead of pyjuju.
[13:24] <sinzui> abentley, I disagree. This might be the right time.
[13:25] <sinzui> I think we want to ask webops if they are prepared to redeploy charmworld on juju 1.x
[13:25] <adeuring> benji: thanks!
[13:25]  * sinzui wants to remove pyjuju and zookeeper from his computers
[13:26] <bac> sinzui: can you update that doc with instructions for what you tried?  i'm unsure.
[13:26] <abentley> sinzui: Yes, maybe it's time.
[13:29] <bac> adeuring: i thought you were going to include my timeout-values branch.  do you not think it is needed?
[13:30] <bac> adeuring: but perhaps i should land it separately, so never mind
[13:30] <adeuring> bac: sorry, simply forgot it :( 
[13:30] <bac> adeuring: i'll do it once yours lands
[13:30] <bac> better actually
[13:31] <bac> adeuring: and thanks a million for figuring out the underlying problem!
[13:37] <bac> benji, adeuring: please have a look https://code.launchpad.net/~bac/charmworld/timeout-values/+merge/183877
[13:37] <adeuring> bac: on standup call right now; I'll look asap
[13:38]  * benji looks
[13:41] <benji> bac: looks good
[13:56] <sinzui> bac benji: I am inclined to teardown the staging env and rebuild it with gojuju. bac you have an instance in it. Can I remove it too?
[13:57] <bac> sinzui: yes
[13:57] <benji> sinzui: sounds like a good idea; we need to be transitioning to gojuju
[13:57] <bac> sinzui: there will be some setup changes
[13:58] <bac> a missing cert, i believe, that gojuju wants
[13:58] <sinzui> hmm
[13:59] <sinzui> I need to learn about that. This is the script we used in the last few deploys of the stack: https://pastebin.canonical.com/91952/
[13:59] <bac> benji: i'm back to looking at your bundle-feature-ui branch.  it has a conflict.
[13:59] <benji> bac: oh, yeah; I had forgotten about that.  I'll look at it now.
[14:00] <bac> benji: i've fixed it locally about three times...  :)
[14:10] <bac> benji: your branch fails this test repeatedly: http://paste.ubuntu.com/6062793/
[14:10] <benji> bac: yep, I'm seeing the same thing.
[14:21] <bac> sinzui: does the charm deploy charmworld trunk or a fixed revno?
[14:22] <sinzui> bac by default it deploys tip (-1). we call set to increment the revno
[14:22] <bac> sinzui: cool, tip is what we want
[14:23] <sinzui> I see staging is finally gone. I will update my config and try gojuju
[14:48] <rick_h> jujugui review time please https://codereview.appspot.com/13237052
[14:48] <jcsackett> sinzui: i'm looking at the audit charms card. i'm assuming anywhere a queue is referred to here, we're talking about charmworld tools?
[14:52] <benji> bac: all tests are passing: https://code.launchpad.net/~benji/charmworld/bundle-feature-ui/+merge/183709
[14:54] <bac> benji: great
[14:59]  * bac reboots
[15:06] <frankban> hatch: https://code.launchpad.net/~frankban/juju-gui/ci-activate-inspector/+merge/183898
[15:12] <Makyo> jujugui https://codereview.appspot.com/13527043/ fairly small
[15:12] <benji> Makyo: I'll take a look
[15:12] <Makyo> benji, Thanks
[15:16] <abentley> sinzui: Got a build running the tests: http://162.213.35.27:8080/job/test-charmworld/1/console
[15:26] <frankban> Makyo: https://codereview.appspot.com/13313044
[15:28] <bac> benji: at line 206 of your diff, does that assignment of form last until the end of the method or is the scope just the exception handler?
[15:28]  * benji looks
[15:29] <benji> bac: end of the method (that code was moved during the refactor, I don't think I touched it)
[15:30] <sinzui> jcsackett, Yes, I believe queue == Tools.
[15:30] <bac> benji: that is overly clever and confusing, i think.
[15:30] <jcsackett> sinzui: ok; any idea what this "build 2nd queue or combined queue" means?
[15:30] <sinzui> abentley, \o/
[15:31] <jcsackett> seems like maybe a redundant bullet point, given the first one is about building a new queue? or is it referring to something else?
[15:31] <benji> bac: I agree.  Smuggling return values through exceptions isn't exactly something that should be done lightly.
[15:31] <benji> it's a pretty big refactor though (or at least a pretty big task to understand the form validation system)
[15:32] <benji> I would be inclined to have a bug/card along the lines of "revamp and potentially replace form validation logic with third party library".
[15:33] <sinzui> jcsackett, we want to re-review everything. charmers need a way to burn a list of charms down. The review criteria is more strict than the past. The goal is to record what needs to be done (bug reports?). charmers have a queue of MPs, but these are only the active development charms
[15:33] <abentley> sinzui: 1x1?
[15:34] <jcsackett> sinzui: ah, ok.
[15:35] <sinzui> jcsackett, We can choose to build a new queue or augment the current queue. The effort is one time so we can plan for a way to get a list of items to do. We can discuss this later in a 1x1
[15:35] <jcsackett> sinzui: sounds good.
[15:35] <sinzui> abentley, yes our 1x1...but i need a few minutes to find caffeine
[15:35] <abentley> sinzui: :-)
[15:38] <sinzui> abentley, I am ready, shall I call?
[15:38] <abentley> sinzui: sure.
[15:42] <rick_h> abentley: so we want to put the owner on the charm token but I recall there was a reason that was bad?
[15:43] <rick_h> jcastro: ^^ as well
[15:43] <bac> benji:  http://127.0.0.1:2464/bundles/wiki/wiki/featured/edit  this url should work but doesn't b/c that bundle is not promulgated, right?
[15:43] <abentley> rick_h: otp
[15:43] <rick_h> we're pondering "If this is not a reviewed charm, put the owner name on the charm token"
[15:43] <rick_h> abentley: rgr
[15:44]  * benji looks
[15:57] <benji> bac: I can't get that bundle to show up after I've cleared my DB.  Any hints?  I ran bin/enqueue --prefix '~charmers/charms/precise' --limit=100; bin/ingest-queued
[15:58] <bac> benji: this is what i run: http://paste.ubuntu.com/6063136/
[15:58] <bac> benji: but first i change charmworld.ini to limit to 10 instead of 110 charms
[15:58] <benji> k
[15:59] <benji> me thinks we need a script for setting up a dev DB; something like what you have there
[16:00] <bac> jujugui are we having a call?
[16:00] <bac> or am i having lunch?
[16:00]  * bac roots for the latter
[16:00] <gary_poster> bac benji I am in guichat.  I think.
[16:01] <bac> gary_poster: yay
[16:02] <hatch> ahoy Goodspud 
[16:02] <Goodspud> Aloha 
[16:02] <hatch> how are you?
[16:04] <Goodspud> All is good in my world. I hear there are some of the crew on London? 
[16:04] <Goodspud> Er, *in 
[16:05] <hatch> yup - it's expensive here :P
[16:10] <adeuring> bac, benji, abentley: could one of you have a look at this MP: https://code.launchpad.net/~adeuring/charmworld/fix-more-spurious-failures/+merge/183919 ?
[16:21] <hatch> jujugui could I get a review on https://codereview.appspot.com/13237053 plz
[16:26] <bac> sinzui: what't the status of staging?
[16:27] <sinzui> My deploy failed a few minutes ago. I see an error in my config
[16:38] <benji> bac: was the "needs fixing" because of the overly clever form validation bit?
[16:57] <Goodspud> Apologies hatch, I lost my connection on my phone 
[16:58]  * benji suspects bac is lunching, so he does the same.
[17:01] <sinzui> bac: sorry for the delay. I need to do a few hacks to deploy because the much promised public ips aren't here yet
[17:30]  * benji is back after a short lunch
[17:30] <benji> back let me know when you're around
[17:55] <bac> benji: no, the needs fixing was due to the uncaught exception being raised.  sorry i wasn't clear.
[17:55] <benji> bac: cool, in that case it is ready for you to look at again
[17:55] <bac> dang, i should've said 'both'
[17:57] <benji> bac: I don't follow.  "both" what?
[18:00] <bac> benji: both issues.  assigning form in the exception and not raising the 404.
[18:00] <bac> benji: but it looks good.  r=me
[18:01] <benji> yay
[18:01] <benji> bac: I'm looking at your bundles icon branch; do you have a moment for a call about it?
[18:02] <bac> sure
[18:32] <jcsackett> jujugui: is there a simple way to determine what series the juju-GUI app is running on within the app code?
[18:46] <hazmat> jcsackett, it can look for itself within the env
[18:46] <hazmat> jcsackett, ie examine its own charm, doesn't work against the fake/mems
[20:30] <bac> how goes the battle sinzui?  (sorry i got disconnected and distracted.)
[20:30] <sinzui> bac: ingestion just started. maybe 15 minutes?
[20:31] <sinzui> bac: abentley: I think the authorized keys option is bad, or just obtuse: https://wiki.canonical.com/InformationInfrastructure/IS/CanonicalOpenstack/CanonistackWithJujuCore
[20:31] <sinzui> ^ When I set it, such as with the staging key we use, I get locked out.
[20:32] <sinzui> The successful setup lets juju choose keys
[20:33] <abentley> sinzui: You're putting the contents of the public key there?
[20:34] <sinzui> abentley, I added the path to the staging public key
[20:35] <abentley> sinzui: The way I read it, it's not a path, it's the actual contents of the key.
[20:35] <abentley> sinzui: That's why I said it would make distributing environments.yaml more convenient in the future.
[20:36] <sinzui> abentley, a list of the keys? well I might tear this down in a few hours and try again
[20:50] <rick_h> jcsackett: did you get it figured out?
[20:51] <jcsackett> rick_h: not yet; made note of hazmat's suggestion, but that does nothing for sandbox mode.
[20:52] <jcsackett> rick_h: working on it alongside other things; hope to deal with it tomorrow morning.
[20:52] <rick_h> jcsackett: app.env.get('defaultSeries')
[20:52] <jcastro> rick_h: I just found a shitty bug
[20:52] <jcastro> rick_h: ok so in the jujucharms.com search box
[20:52] <jcsackett> rick_h: well then.
[20:52] <jcsackett> that's easier. :-P
[20:52] <rick_h> jcastro: hopefully something we can address or have addressed. Lots of bug finding lately
[20:52] <sinzui> bac: looks like mongodb has an agent-state error. charmworld is waiting to mongodb
[20:52] <jcastro> search for "rabbit" = nothing. search for "rabbitmq" returns rabbitmq-server
[20:53] <jcastro> how come rabbit doesn't return anything?
[20:53] <rick_h> jcastro: yea, it matches full names, partial matches in fields like summary/etc
[20:53] <bac> sinzui: ok
[20:53] <rick_h> jcastro: because rabbit is part of the word. We don't tokenize it. I think it's something we'll look at changing as trying ot get better search, but not set in stone atm
[21:42] <hazmat> jcsackett, another option its part of the config . and the charm can write it out, or default value from config for fake/mems
[21:42] <hazmat> rick_h, default doesn't nesc. correspond to the gui series though
[21:43] <jcsackett> hazmat: i think rick_h's approach fits my needs; we just want to grab the env series. i think my question garbled my intent.
[21:43] <rick_h> hazmat: true, but for what jcsackett is doing I think works. It's basically a helper to plus up the series you're working 'in'. 
[21:43] <hazmat> ah cool
[21:43] <rick_h> for search results ranking a little bit