=== _mup__ is now known as _mup_ [08:05] Makyo: http://jsbin.com/ENIbojO/1/ checking console logs === schwuk_away is now known as schwuk [09:08] rick_h, http://www.tasrestaurants.co.uk/pide.html [09:50] gary_poster, Do you by any chance have admin rights for juju.ubuntu.com? [09:50] no, sorry antdillon [09:50] gary_poster, Thanks [09:50] ...for nothing ;-) [09:53] 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] 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] Using the value 1 and zero helps. [09:56] But I'd like to set this in create_index(), but xould not yet figure out the right parameters... [10:29] luca__: Icons required: eye, spanner, cog (plus hover states if applicable) and trash can. [10:47] 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] http://askubuntu.com/questions/73589/higher-screen-resolution-for-virtualbox [11:13] jujugui: Can I have a review of my inspector changes? https://codereview.appspot.com/13521043/ [12:07] adeuring: i ran your new branch and got: [12:07] Ran 726 tests in 88.575s [12:07] FAILED (errors=7, failures=4) [12:08] so it is faster [12:09] bac: great. Can you show me the errors? [12:10] adeuring: many refer to es client not having 'multi_get'. http://paste.ubuntu.com/6062400/ [12:11] bac: thanks. [12:14] 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] adeuring: it is installed by charmworld setup in the venv. requirements.txt:pyelasticsearch==0.6 [12:16] weird... [12:16] i do not have it installed in my system python [12:20] 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] adeuring: i'll drop into pdb and see if i can figure it out [12:21] rick_h, https://gist.github.com/makyo/6436215 [12:21] back and adeuring: let me know if there is anything I can do [12:23] 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] adeuring: I'll see if I can repro [12:24] thanks [12:25] 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] hatch, huwshimi http://www.popvssoda.com/ [12:28] adeuring: turns out my pyelasticsearch was still 0.4.1. i didn't do a 'make deps' after it got upgraded [12:28] bac, benji: ah, that explains a few problems ;) [12:29] ooh [12:30] deps really should be a dependency of install [12:36] adeuring: after a "make deps" I only get one failure: http://paste.ubuntu.com/6062493/ [12:38] 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] I'm doing a second run now to see. If so I'll add that call and see. [12:50] adeuring, benji: running abel's branch i get only one failure http://paste.ubuntu.com/6062553/ [12:51] different from benji's [12:51] heh [12:51] and my tests are still slow :( [12:52] that test fails in isolation? [12:52] 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] benji: still slow? huh. mine are at 100s or so [12:52] bac: I haven't checked that one [12:53] adeuring, benji: also, i have a simple fix to the openid log pollution in the test output [12:53] after a "make distclean"... wait! I was running in the wrong darn branch [12:53] benji: did you try to restart the ES server? [12:53] 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] benji: I'll look into this "sort issue" [12:55] bac and adeuring: I get bac's failure when I run that test in isolation [12:55] 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] jcsackett: do you know if sinzui is in today? [12:57] jcsackett: do you have access to charmworld staging? [12:58] jcsackett: management access via juju, i mean [12:58] 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] adeuring: other calls indicate they want an integer specifying seconds not milliseconds [12:59] adeuring: please merge that branch into yours for a single landing if you agree [12:59] adeuring: do you have access to staging via juju? [13:01] 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] adeuring: i'm seeing this when trying to access staging [13:01] 2013-09-04 09:01:17,726 INFO Connecting to environment... [13:01] 2013-09-04 09:01:19,284 ERROR juju environment not found: is the environment bootstrapped? [13:02] when running /usr/bin/juju status -e staging [13:02] adeuring: can you see if you can simply get status via juju? [13:03] bac: I'm getting the same error. [13:03] ugh [13:03] yay! [13:03] good morning sinzui! [13:04] Good? I am not going to commit to such an accusation. I will simply state the obvious. Morning bac [13:05] 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] s/inable/unable [13:05] ah [13:06] * sinzui wonders if canonistack has toppled juju [13:06] bac and adeuring: test run time for me is 115s and on the last run I only got bac's failure [13:07] \o/ [13:07] sinzui: the web app is running [13:07] benji: let's not call this 'bac's failure' [13:07] heh [13:08] "the bacobian abnormality" [13:08] 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] yeah... though I found one setup issue we had with elasticsearch since we began to use it... [13:09] 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] 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] +1 [13:12] ok, let me just save the fixes i have in place. ES is real fun to work with :( [13:14] benji: fwiw i'm now seeing the full suite run in ~90s [13:14] 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] bac: sounds good (my machine is a tad slow, so I would expect mine to give slightly longer run times) [13:15] abentley: ping, got a sec to chat search? [13:16] rick_h: sure. juju-gui? [13:16] abentley: well figured I'd ask here. I noticed the docs note some extra fields to search on, summary, etc? [13:16] sinzui: i didn't realize i could ssh natively, thought i had to use 'juju ssh'. [13:16] abentley: but it comes back as not supported: http://staging.jujucharms.com/api/2/charms?summary=apache [13:17] abentley: and http://staging.jujucharms.com/api/3/search?summary=apache [13:17] 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] 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] 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] abentley: ooooh, ok. [13:18] sinzui: can you grant me edit to that doc? [13:18] bac, benji, sinzui: so, here is the MP: https://code.launchpad.net/~adeuring/charmworld/set_n_replicas_and_shards/+merge/183846 [13:18] bac: done [13:18] adeuring: I'll review it [13:19] The state servers logs still say they cannot talk to the zookeeper. Looks like the monkeys are loose. [13:21] 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] +1 [13:23] 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] 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] abentley, I disagree. This might be the right time. [13:25] I think we want to ask webops if they are prepared to redeploy charmworld on juju 1.x [13:25] benji: thanks! [13:25] * sinzui wants to remove pyjuju and zookeeper from his computers [13:26] sinzui: can you update that doc with instructions for what you tried? i'm unsure. [13:26] sinzui: Yes, maybe it's time. [13:29] adeuring: i thought you were going to include my timeout-values branch. do you not think it is needed? [13:30] adeuring: but perhaps i should land it separately, so never mind [13:30] bac: sorry, simply forgot it :( [13:30] adeuring: i'll do it once yours lands [13:30] better actually [13:31] adeuring: and thanks a million for figuring out the underlying problem! [13:37] benji, adeuring: please have a look https://code.launchpad.net/~bac/charmworld/timeout-values/+merge/183877 [13:37] bac: on standup call right now; I'll look asap [13:38] * benji looks [13:41] bac: looks good [13:56] 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] sinzui: yes [13:57] sinzui: sounds like a good idea; we need to be transitioning to gojuju [13:57] sinzui: there will be some setup changes [13:58] a missing cert, i believe, that gojuju wants [13:58] hmm [13:59] 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] benji: i'm back to looking at your bundle-feature-ui branch. it has a conflict. [13:59] bac: oh, yeah; I had forgotten about that. I'll look at it now. [14:00] benji: i've fixed it locally about three times... :) [14:10] benji: your branch fails this test repeatedly: http://paste.ubuntu.com/6062793/ [14:10] bac: yep, I'm seeing the same thing. [14:21] sinzui: does the charm deploy charmworld trunk or a fixed revno? [14:22] bac by default it deploys tip (-1). we call set to increment the revno [14:22] sinzui: cool, tip is what we want [14:23] I see staging is finally gone. I will update my config and try gojuju [14:48] jujugui review time please https://codereview.appspot.com/13237052 [14:48] 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] bac: all tests are passing: https://code.launchpad.net/~benji/charmworld/bundle-feature-ui/+merge/183709 [14:54] benji: great [14:59] * bac reboots [15:06] hatch: https://code.launchpad.net/~frankban/juju-gui/ci-activate-inspector/+merge/183898 [15:12] jujugui https://codereview.appspot.com/13527043/ fairly small [15:12] Makyo: I'll take a look [15:12] benji, Thanks [15:16] sinzui: Got a build running the tests: http://162.213.35.27:8080/job/test-charmworld/1/console [15:26] Makyo: https://codereview.appspot.com/13313044 [15:28] 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] bac: end of the method (that code was moved during the refactor, I don't think I touched it) [15:30] jcsackett, Yes, I believe queue == Tools. [15:30] benji: that is overly clever and confusing, i think. [15:30] sinzui: ok; any idea what this "build 2nd queue or combined queue" means? [15:30] abentley, \o/ [15:31] 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] bac: I agree. Smuggling return values through exceptions isn't exactly something that should be done lightly. [15:31] it's a pretty big refactor though (or at least a pretty big task to understand the form validation system) [15:32] 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] 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] sinzui: 1x1? [15:34] sinzui: ah, ok. [15:35] 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] sinzui: sounds good. [15:35] abentley, yes our 1x1...but i need a few minutes to find caffeine [15:35] sinzui: :-) [15:38] abentley, I am ready, shall I call? [15:38] sinzui: sure. [15:42] abentley: so we want to put the owner on the charm token but I recall there was a reason that was bad? [15:43] jcastro: ^^ as well [15:43] 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] rick_h: otp [15:43] we're pondering "If this is not a reviewed charm, put the owner name on the charm token" [15:43] abentley: rgr [15:44] * benji looks [15:57] 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] benji: this is what i run: http://paste.ubuntu.com/6063136/ [15:58] benji: but first i change charmworld.ini to limit to 10 instead of 110 charms [15:58] k [15:59] me thinks we need a script for setting up a dev DB; something like what you have there [16:00] jujugui are we having a call? [16:00] or am i having lunch? [16:00] * bac roots for the latter [16:00] bac benji I am in guichat. I think. [16:01] gary_poster: yay [16:02] ahoy Goodspud [16:02] Aloha [16:02] how are you? [16:04] All is good in my world. I hear there are some of the crew on London? [16:04] Er, *in [16:05] yup - it's expensive here :P [16:10] 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] jujugui could I get a review on https://codereview.appspot.com/13237053 plz [16:26] sinzui: what't the status of staging? [16:27] My deploy failed a few minutes ago. I see an error in my config [16:38] bac: was the "needs fixing" because of the overly clever form validation bit? [16:57] Apologies hatch, I lost my connection on my phone [16:58] * benji suspects bac is lunching, so he does the same. [17:01] 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] back let me know when you're around [17:55] benji: no, the needs fixing was due to the uncaught exception being raised. sorry i wasn't clear. [17:55] bac: cool, in that case it is ready for you to look at again [17:55] dang, i should've said 'both' [17:57] bac: I don't follow. "both" what? [18:00] benji: both issues. assigning form in the exception and not raising the 404. [18:00] benji: but it looks good. r=me [18:01] yay [18:01] bac: I'm looking at your bundles icon branch; do you have a moment for a call about it? [18:02] sure === schwuk is now known as schwuk_away [18:32] jujugui: is there a simple way to determine what series the juju-GUI app is running on within the app code? [18:46] jcsackett, it can look for itself within the env [18:46] jcsackett, ie examine its own charm, doesn't work against the fake/mems [20:30] how goes the battle sinzui? (sorry i got disconnected and distracted.) [20:30] bac: ingestion just started. maybe 15 minutes? [20:31] bac: abentley: I think the authorized keys option is bad, or just obtuse: https://wiki.canonical.com/InformationInfrastructure/IS/CanonicalOpenstack/CanonistackWithJujuCore [20:31] ^ When I set it, such as with the staging key we use, I get locked out. [20:32] The successful setup lets juju choose keys [20:33] sinzui: You're putting the contents of the public key there? [20:34] abentley, I added the path to the staging public key [20:35] sinzui: The way I read it, it's not a path, it's the actual contents of the key. [20:35] sinzui: That's why I said it would make distributing environments.yaml more convenient in the future. [20:36] abentley, a list of the keys? well I might tear this down in a few hours and try again [20:50] jcsackett: did you get it figured out? [20:51] rick_h: not yet; made note of hazmat's suggestion, but that does nothing for sandbox mode. [20:52] rick_h: working on it alongside other things; hope to deal with it tomorrow morning. [20:52] jcsackett: app.env.get('defaultSeries') [20:52] rick_h: I just found a shitty bug [20:52] rick_h: ok so in the jujucharms.com search box [20:52] rick_h: well then. [20:52] that's easier. :-P [20:52] jcastro: hopefully something we can address or have addressed. Lots of bug finding lately [20:52] bac: looks like mongodb has an agent-state error. charmworld is waiting to mongodb [20:52] search for "rabbit" = nothing. search for "rabbitmq" returns rabbitmq-server [20:53] how come rabbit doesn't return anything? [20:53] jcastro: yea, it matches full names, partial matches in fields like summary/etc [20:53] sinzui: ok [20:53] 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] 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] rick_h, default doesn't nesc. correspond to the gui series though [21:43] 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] 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] ah cool [21:43] for search results ranking a little bit