| SpamapS | RoAkSoAx: you've been quiet.. I trust things are going well? | 00:11 |
|---|---|---|
| _mup_ | ensemble/security-connection r282 committed by kapil.thangavelu@canonical.com | 00:14 |
| _mup_ | additional tests for security policy connection integration. | 00:14 |
| _mup_ | Bug #813856 was filed: Security policies need to be integrated into zookeeper connections <Ensemble:In Progress by hazmat> < https://launchpad.net/bugs/813856 > | 00:16 |
| _mup_ | ensemble/security-connection r283 committed by kapil.thangavelu@canonical.com | 00:18 |
| _mup_ | mixin the security policy connection integration into the existing ssh zk client. | 00:18 |
| adam_g | any reason why relation-changed would fire two or more times in a row? is a relation-changed fired for every relation-set on the other side of the relationship? | 00:21 |
| hazmat | adam_g, relation changed gets fired after relation-joined as well | 00:26 |
| adam_g | hazmat: in all cases, on both ends? | 00:26 |
| hazmat | adam_g, yes.. it also gets fired when a hook does a relation-set (although only once for the hook, regardless of how many times it does relation-set in the hook) | 00:27 |
| adam_g | hmm. ok | 00:29 |
| hazmat | we used not to do after joined automatically, but noticed some of the formulas where getting their behavior wrong, as they where waiting on values in relation-changed.. but those values may have already been set by the remote end by the time the relation-joined hook fired locally so the relation-changed wouldn't have ever fired... ideally the hooks should have checked for the values in relation-joined and we could have avoided the spurious relation- | 00:29 |
| hazmat | change, but we figured it would be easier for formula authors this way (fire the relation-changed after a relation-join) | 00:29 |
| hazmat | re relation-set multiple times within a hook, the sets are all buffered to after the hook is executed so there's a single change event for all the related units. | 00:30 |
| smoser | hallyn, did you really just say "jaunty" ? | 00:38 |
| RoAkSoAx | SpampS yeah everything is going well... changes made by william william have improved some things and some others have tp be rewritt | 01:06 |
| RoAkSoAx | argh from cell phonr | 01:06 |
| hallyn | smoser: I did indeed | 01:41 |
| fwereade | does anyone recall the details of the test failure in which "<ClientEvent changed at blah state:connected>" != "<ClientEvent changed at blah>" | 09:13 |
| fwereade | I seem to recall it's something to do with the packages we're using | 09:13 |
| === daker_ is now known as daker | ||
| === _mup__ is now known as _mup_ | ||
| hazmat | fwereade, it needs an update of txzookeeper | 09:54 |
| hazmat | fwereade, the __repr__ of client event changed | 09:54 |
| fwereade | hazmat: I appear to be up to date | 09:54 |
| hazmat | fwereade, you should check if that's the version/checkout being used | 09:55 |
| fwereade | hazmat: I have my PYTHONPATH set; is there anything else I should do? | 09:55 |
| hazmat | fwereade, you can startup python, import txzookeeper, print txzookeeper it will show the on disk location, verify that version is the one you think and is the latest | 09:56 |
| hazmat | sometimes if your mix packages, or do setup.py install you'll end up with a different copy on your system | 09:57 |
| hazmat | fwereade, you installed txzookeeper from? | 09:58 |
| hazmat | ppa or bzr? | 09:58 |
| fwereade | hazmat: ppa | 09:58 |
| fwereade | should it be in /usr/lib/pymodules/python2.7? | 09:58 |
| fwereade | or does that indicate I have the wrong one again somehow? | 09:58 |
| hazmat | fwereade, what version of the package do you have? | 09:59 |
| fwereade | hazmat: 0.8.0 | 10:00 |
| fwereade | hazmat: is there somewhere I can check what version I *should* have without asking people? | 10:00 |
| hazmat | fwereade, the bzr revision number should be in the package versionthere.. so as far being able to determine this by yourself, the package version bzr revision should match that of txzookeeper trunk (rev 43) | 10:02 |
| fwereade | hazmat: hm, good to know | 10:02 |
| fwereade | hazmat: so my life would probably be easier if I just kept a checkout of txzookeeper and installed that whenever it changed? | 10:03 |
| fwereade | hazmat: or should I actually be watching trunk for many things? | 10:03 |
| hazmat | fwereade, txzookeeper is pretty stable, maybe one change every couple months at this point. i use virtualenvs and run it with python setup.py develop which links the source tree into the python package dir, so updating the source tree is sufficient. | 10:04 |
| hazmat | fwereade, can you confirm the exact package version ? | 10:05 |
| hazmat | s/exact/full | 10:05 |
| fwereade | hazmat: 0.8.0 is what I get from txzookeeper.version | 10:06 |
| hazmat | fwereade, apt-cache show txzookeeper will show the package version | 10:06 |
| * fwereade raises eyebrow ("no packages found") | 10:07 | |
| hazmat | fwereade, so that would imply it wasn't installed by ppa | 10:08 |
| fwereade | hazmat: hmm | 10:09 |
| fwereade | hazmat: I just re-added the repository and updated again | 10:09 |
| hazmat | or maybe its python-txzookeeper | 10:09 |
| fwereade | hazmat: ooh, that rings a bell | 10:09 |
| hazmat | doesn't look like it from here.. https://launchpad.net/~ensemble/+archive/ppa?field.series_filter=natty but it sounds sensible ;-) | 10:09 |
| fwereade | hazmat: 0.8.0-0ensemble43~natty1 | 10:09 |
| hazmat | hmm.. that's the latest | 10:10 |
| fwereade | hazmat: which looks right based on what you've been saying | 10:10 |
| hazmat | fwereade, which test is it that's failing | 10:10 |
| fwereade | hazmat: sorry, bad time for system to fall over | 10:15 |
| fwereade | hazmat: let me recover my state... | 10:15 |
| hazmat | fwereade, no worries | 10:15 |
| fwereade | hazmat: rerunning suite now, but you can find it by grepping for ClientEvent | 10:15 |
| fwereade | ensemble.state.tests.test_relation.???.test_watch_user_callback_invocation_delays_node_watch | 10:17 |
| fwereade | UnitRelationStateTest | 10:18 |
| fwereade | hazmat: trunk works for you then? | 10:18 |
| hazmat | fwereade, yeah.. works fine for me | 10:23 |
| fwereade | hazmat: bah :) | 10:23 |
| fwereade | hazmat: well, not to worry for now, I'll poke around and see if I can figure something out | 10:25 |
| fwereade | hazmat: thanks for your help | 10:25 |
| hazmat | fwereade, yeah.. i'm not sure what the issue is.. i'm firing up an ensemble instance to verify the unit tests there | 10:26 |
| hazmat | fwereade, just verified the failure using txzk package on ec2 | 11:28 |
| hazmat | hmm | 11:30 |
| hazmat | it looks like i'm pushing and pulling from different branches | 11:32 |
| hazmat | they have the same content though | 11:32 |
| daker | hey i am blocked at preseed conf file for my formula, can anyone explain how it works ? | 11:51 |
| _mup_ | ensemble/trunk-merge r271 committed by kapil.thangavelu@canonical.com | 12:13 |
| _mup_ | merge trunk | 12:13 |
| fwereade | hazmat: hey, soory I missed you | 13:03 |
| fwereade | hazmat: yeah, I verified that from my perspective it really is the tests that are wrong (all the txzookeepers I can find repr with state: connected), and thought I'd wait to hear back | 13:04 |
| hazmat | fwereade, it looks like that test is broken | 13:13 |
| hazmat | fwereade, the repr of the client event now has the connection status | 13:13 |
| hazmat | the test needs an update to reflect that | 13:13 |
| fwereade | hazmat: cool (well, not cool, but at least it's not my own mistake :p) | 13:13 |
| fwereade | hazmat: I already have a local fix, shall I create a bug and propose a merge? | 13:14 |
| fwereade | hazmat: or should we complain to whoever last merged? | 13:14 |
| hazmat | fwereade, its a trivial, typically just paste the diff, get an ack, and commit to trunk | 13:14 |
| fwereade | hazmat: http://paste.ubuntu.com/649098/ look ok to you? | 13:15 |
| hazmat | hmm.. looks like ben merged the failed test in last rev | 13:16 |
| hazmat | fwereade, looks good +1 | 13:16 |
| fwereade | hazmat: cheers | 13:16 |
| fwereade | hazmat: just rerunning the tests for paranoia's sake | 13:16 |
| hazmat | it looks like some other test logic got removed in that merge | 13:18 |
| hazmat | unrelated to this fix | 13:18 |
| RoAkSoAx | fwereade: o/ I have a few issues to show you in just a second | 13:47 |
| fwereade | RoAkSoAx: cool, just shout when you need me | 13:47 |
| RoAkSoAx | fwereade: will do in just a few secs | 13:49 |
| RoAkSoAx | or minutes :) | 13:49 |
| RoAkSoAx | fwereade: can I start using trunk to test the orchestra integration instead of the bootstrap branch? | 13:51 |
| RoAkSoAx | fwereade: as all your change shave already been merged tright? | 13:51 |
| RoAkSoAx | and I think I might use of a couple of bugfixes | 13:51 |
| fwereade | RoAkSoAx: trunk has the big refactoring | 13:52 |
| fwereade | RoAkSoAx: there's some stuff in lp:~fwereade/ensemble/cobbler-connect-production that might be of use to you | 13:53 |
| RoAkSoAx | fwereade: so is it safe to use my work with that branch? | 13:53 |
| fwereade | RoAkSoAx: it's a hopefully-useful CobblerConnect implemented with twisted | 13:53 |
| fwereade | RoAkSoAx: and it should be just enough to maunch a machine, without passing anything useful to it whatsoever | 13:54 |
| RoAkSoAx | fwereade: right now im getting erros that doesn't seem related to the refactoring | 13:54 |
| RoAkSoAx | that's why I'm asking | 13:54 |
| fwereade | RoAkSoAx: I'm going to give it a final once-over and then propose a merge | 13:54 |
| fwereade | RoAkSoAx: like what? | 13:55 |
| RoAkSoAx | fwereade: unhasable dict | 13:55 |
| RoAkSoAx | error | 13:55 |
| RoAkSoAx | when trying to deploy | 13:55 |
| fwereade | RoAkSoAx: sorry, doesn't ring a bell :( | 13:56 |
| fwereade | RoAkSoAx: paste a traceback? | 13:56 |
| RoAkSoAx | fwereade: yeah I'm gonna reproduce with a clean zookeeper machine | 13:57 |
| RoAkSoAx | I'm deploying it atm | 13:57 |
| RoAkSoAx | fwereade: now I can't even bootstrap | 14:07 |
| RoAkSoAx | http://pastebin.ubuntu.com/649146/ | 14:07 |
| fwereade | RoAkSoAx: is that on trunk? | 14:07 |
| RoAkSoAx | fwereade: bot, ensemble-bootstrap | 14:08 |
| fwereade | RoAkSoAx: what it (probably) means is that OrchestraLaunchMachine is returning a string (name?) instead of a deferred list of OrchestraMachines | 14:09 |
| Daviey | eek | 14:10 |
| RoAkSoAx | fwereade: yeah, and the thing is that from yesterday till today nothing changed and yesterday there was no error :) | 14:10 |
| fwereade | RoAkSoAx: wait, I misread | 14:12 |
| fwereade | RoAkSoAx: that's the result of get_zookeeper_machines | 14:13 |
| RoAkSoAx | fwereade: heh never mind found the error. the same thing that's giving error when launching machines, is the thing that's giving error when bootstrapping if I comment out the first thing | 14:13 |
| RoAkSoAx | fwereade: but yeah, I've bumped into stuff that seems to still be ec2 specific | 14:14 |
| RoAkSoAx | let me re-check | 14:14 |
| fwereade | RoAkSoAx: very probable... I did my best, but it's still all a bit new to me ;) what in particular | 14:14 |
| RoAkSoAx | fwereade: yeah we are both learning our way here:) | 14:17 |
| daker | fwereade, yo i have just pushed the changes https://code.launchpad.net/~daker/ensemble/small-fix/+merge/68038 | 14:17 |
| fwereade | daker: cool, thanks, I'll take a look | 14:17 |
| fwereade | daker: tiny tweaks :) | 14:22 |
| fwereade | RoAkSoAx: I'm just firming up my tests a little, shout if I can help | 14:23 |
| daker | fwereade, ah you mean that between the two sub_parser.add_argument there should a break, right ? | 14:24 |
| fwereade | daker: sorry, no | 14:24 |
| fwereade | daker: I just meant that the original source line was over 80 chars | 14:25 |
| daker | and ? the help text should be reduced ? | 14:25 |
| fwereade | daker: and so a line break, probably just before the "help=", would make the code nice without needing to touch the text | 14:26 |
| fwereade | daker: the text looks fine to me | 14:26 |
| fwereade | daker: if the source is still over 80 characters even with that break, you can just do something like the following (give me a moment...) | 14:27 |
| daker | fwereade, is it good like that http://paste.ubuntu.com/649169/ ? | 14:28 |
| fwereade | daker: that just breaks 80 chars, how about http://paste.ubuntu.com/649177/ | 14:29 |
| daker | ah ok i understand now! | 14:30 |
| hazmat | bcsaller, the merge of config-set-lifecycle looks like it had some testing regressions added | 14:30 |
| hazmat | bcsaller, fwereade took care of the failing test, but it looks like (as noted in review) that some other tests also lost some of their logic | 14:31 |
| RoAkSoAx | fwereade: what should __check_state from findzookeepers.py return? | 14:45 |
| fwereade | RoAkSoAx: thinking | 14:47 |
| fwereade | RoAkSoAx: it should *eventually* return a list of OrchestraMachines | 14:48 |
| === jamespage1 is now known as jamespage | ||
| fwereade | RoAkSoAx: (with just one element for now) | 14:48 |
| fwereade | RoAkSoAx: ...ok, I put that badly | 14:48 |
| fwereade | RoAkSoAx: it can return whatever it wants, but the callback should be able to turn *that* into a list of etc | 14:48 |
| fwereade | RoAkSoAx: the callback chain should end up returning a list of machines | 14:49 |
| fwereade | RoAkSoAx: am I making sense? | 14:49 |
| RoAkSoAx | fwereade: i think so :) yes! | 14:50 |
| fwereade | RoAkSoAx: cool :) | 14:51 |
| fwereade | RoAkSoAx: as long as we get the expected results/errors from .run(), how you do it is up to you | 14:51 |
| fwereade | jimbaker: hi | 15:04 |
| fwereade | jimbaker: I haven't managed to induce any errors in EC2BootstrapTest, try as I might | 15:06 |
| fwereade | jimbaker: any pointers? | 15:06 |
| fwereade | jimbaker: however, I *have* found a different test that will fail pretty soon if run with -u | 15:06 |
| fwereade | RoAkSoAx: you know the kickstart file on the cobbler server? | 15:15 |
| fwereade | RoAkSoAx: that I had to make a little change to to get past the system install step? | 15:16 |
| fwereade | RoAkSoAx: such a file must have a certain set of properties before we can actually deploy an ensemble machine running it, right? | 15:17 |
| fwereade | RoAkSoAx: ...but those files are not actually part of ensemble | 15:18 |
| bcsaller | hazmat: all the tests on trunk are passing for me. I thought I did it properly, though I did have to clear .pyc files before it worked | 15:19 |
| bcsaller | hazmat: maybe you can point me at what you're seeing? | 15:19 |
| fwereade | bcsaller: is your txzookeeper up to date? | 15:24 |
| daker | fwereade, can you take a look now https://code.launchpad.net/~daker/ensemble/small-fix/+merge/68038 ? | 15:24 |
| fwereade | bcsaller: if you search the source for ClientEvent you'll find the test | 15:24 |
| bcsaller | fwereade: ahh, the state stuff in the repr | 15:25 |
| fwereade | bcsaller: yep | 15:25 |
| fwereade | bcsaller: I know there was something funny -- I hit something similar on the sprint -- and niemeyer went off, discussed packaging with someone, and magically fixed it | 15:26 |
| fwereade | bcsaller: ...but I don't know the details | 15:26 |
| fwereade | bcsaller: regardless: the current version does have "state: connected" in the __str__, so I changed the test to expect it | 15:27 |
| bcsaller | fwereade: I updated my txzk, I'll give it another pass | 15:27 |
| fwereade | bcsaller: that one's already fixed, I think hazmat was concerned about something else, but I didn't review so I don't know what it is | 15:27 |
| jimbaker | fwereade, which test is that? | 15:27 |
| hazmat | bzr qdiff -c -1 on trunk will show the fix from fwereade, the fix that remains is for the tests that have lost logic.. as per bzr qdiff -c -2 | 15:28 |
| fwereade | jimbaker: ensemble.state.tests.test_agent.AgentDomainTest.test_connect_agent | 15:28 |
| jimbaker | fwereade, yes that one fails on a regular basis | 15:28 |
| fwereade | jimbaker: ah, cool :) | 15:28 |
| fwereade | jimbaker: well, not cool :p | 15:29 |
| jimbaker | fwereade, just wonder why the bootstrap tests fail for me | 15:29 |
| hazmat | most of these bits are missing from test_hook https://pastebin.canonical.com/50069/ | 15:29 |
| hazmat | bcsaller, ^ | 15:29 |
| bcsaller | fwereade: yeah, didn't realize there was a txzk version issue there, its working on trunk now. | 15:29 |
| bcsaller | hazmat: those bits don't apply, we inlined and removed that api | 15:29 |
| fwereade | jimbaker: how often are you seeing the bootstrap failure? | 15:30 |
| hazmat | bcsaller, the flush logic at the top does | 15:30 |
| jimbaker | if i run -u, it will eventually fail | 15:30 |
| hazmat | fwereade, also the tests now fail if you run them disconnected | 15:30 |
| jimbaker | seems like less than 10 iterations | 15:30 |
| hazmat | the calls to determine the image id aren't being mocked | 15:31 |
| fwereade | jimbaker: for that specific test method? | 15:31 |
| jimbaker | fwereade, when i ran just the bootstrap tests, for example | 15:31 |
| fwereade | hazmat: I have noticed that, I didn't think it was me, but given that I was hitting that code most recently I guess it was | 15:31 |
| fwereade | jimbaker: weord, I've tried with all variants from .providers on up | 15:32 |
| fwereade | jimbaker: quick thought | 15:32 |
| jimbaker | fwereade, which is generally how i will isolate: run a section of tests w/ -u (test/test suite/script if possible) | 15:32 |
| fwereade | jimbaker: is your machine under noticeably low or high load? | 15:33 |
| jimbaker | fwereade, low load | 15:33 |
| fwereade | jimbaker: bah, so has mine been | 15:33 |
| jimbaker | fwereade, however i will retry now, on both my laptop and desktop | 15:33 |
| fwereade | hazmat: shall I pick that issue up? | 15:34 |
| jimbaker | fwereade, curiously i was seeing it fail in the same place on my macbook pro yesterday | 15:34 |
| fwereade | jimbaker: I'm sure it's a real problem, I just wish I could figure out how to repro it | 15:34 |
| hazmat | fwereade, if you want/time allows, else just file an issue for it | 15:34 |
| hazmat | fwereade, the cobbler work is higher priority | 15:34 |
| jimbaker | SpamapS, you had asked earlier about osx, the 2.7ism that apparently snuck in was around argparse | 15:35 |
| fwereade | hazmat: true | 15:35 |
| fwereade | hazmat: cheers | 15:35 |
| fwereade | bbs, diconnecting to get the error list | 15:35 |
| jimbaker | SpamapS, this shouldn't impact actualy client usage however - it's just testing against specific error messages, and these got changed in 2.7 | 15:35 |
| jimbaker | probably need to change the tests | 15:36 |
| RoAkSoAx | SpamapS: ping | 15:36 |
| jimbaker | the actual mac failures were all about different temp file paths | 15:36 |
| jimbaker | and also uninteresting | 15:37 |
| _mup_ | Bug #814144 was filed: test errors when no network available <Ensemble:New> < https://launchpad.net/bugs/814144 > | 15:40 |
| jimbaker | fwereade, given the network dependency in bug 814144 on the same tests mentioned earlier as having looping problems (./test -u ensemble.providers.ec2.tests.test_bootstrap), maybe this theory explains things | 16:06 |
| _mup_ | Bug #814144: test errors when no network available <Ensemble:New> < https://launchpad.net/bugs/814144 > | 16:06 |
| jimbaker | 1. yesterday i was running the tests at a coffee shop w/ a so-so network, and they were eventually failing, maybe because of additional timing | 16:07 |
| jimbaker | 2. today, i'm running them at home w/ a good low-latency network, no failures | 16:07 |
| fwereade | jimbaker: ah-ha! | 16:11 |
| fwereade | jimbaker: very plausible | 16:11 |
| fwereade | jimbaker: consider me on it | 16:12 |
| jimbaker | fwereade, sounds good | 16:12 |
| daker | fwereade, is my MP good now ? | 16:14 |
| fwereade | daker: so sorry, I think I lost you in a context switch | 16:14 |
| daker | no worries https://code.launchpad.net/~daker/ensemble/small-fix/+merge/68038 | 16:15 |
| fwereade | daker: would be good to lose the spaces before the colons, sorry I notied them late | 16:15 |
| fwereade | if confirmed..., if value.strip()... | 16:16 |
| fwereade | but lgtm otherwise | 16:16 |
| jimbaker | shang, we met in budapest, right? | 16:16 |
| daker | fwereade, i am lost :/ | 16:18 |
| fwereade | daker: sorry again | 16:24 |
| fwereade | if confirmed is False : | 16:25 |
| fwereade | should read | 16:25 |
| fwereade | if confirmed is False : | 16:25 |
| fwereade | if confirmed is False: | 16:25 |
| * fwereade winces | 16:25 | |
| fwereade | ...and there's another one a couple of lines later | 16:25 |
| fwereade | it's just for consistency's sake ;) | 16:26 |
| jimbaker | i'm pretty certain anything like that would be picked up by the pep8 tool | 16:29 |
| jimbaker | i recommend always running pep8/pyflakes (reviewers certainly do) | 16:29 |
| jimbaker | also, in this particular case, best to say something like: if confirmed: ... | 16:32 |
| jimbaker | no need to say is False, certainly the argparse setting ensures it's True or False, and if even if it didn't, i don't see that it would matter if it were 0 or None | 16:33 |
| SpamapS | RoAkSoAx: pong, sup? | 16:51 |
| RoAkSoAx | SpamapS: howdy!! I was working on the load_state stuff, and doing that, http://pastebin.ubuntu.com/649258/, returns something like: exceptions.AttributeError: 'str' object has no attribute 'get' | 16:54 |
| RoAkSoAx | any ideas? | 16:54 |
| SpamapS | RoAkSoAx: reading now | 17:03 |
| hazmat | RoAkSoAx, the state being returned by load_state is a string it appears, does the error happen if you remove the bottom line | 17:04 |
| hazmat | RoAkSoAx, you also can't do this interactively since there are deferreds in the mix | 17:04 |
| daker | fwereade, sorry again, can you give a final look https://code.launchpad.net/~daker/ensemble/small-fix/+merge/68038 ? | 17:05 |
| SpamapS | Its possible the state that was saved wasn't properly serialized | 17:05 |
| hazmat | the reactor needs to be started and the result processed either with a callback or with @inlineCallbacks and yield | 17:05 |
| RoAkSoAx | hazmat: yeah I'm working on that ;) | 17:05 |
| fwereade | daker: looks great to me, my approve stands :) | 17:08 |
| hazmat | daker, just added a review comment to it | 17:10 |
| daker | hazmat, i hope it's good now ツ | 17:18 |
| * daker crosse his fingers | 17:19 | |
| hazmat | daker, looks good, except for the missing test | 17:28 |
| fwereade | hazmat: golly, we even have tests for the command line, I didn't even think to demand them... | 17:30 |
| fwereade | hazmat: I think the laxity at my last place has damaged my brain :/ | 17:30 |
| fwereade | hazmat: I used to test *everything* | 17:30 |
| fwereade | hazmat: ...I'm so happy to be here :D | 17:31 |
| hazmat | fwereade, in this case the cli is our primary interface, if we're not testing it.... then bad things ;-) | 17:31 |
| fwereade | hazmat: quite... I just got used to being happy when tests for *anything* showed up ;) | 17:31 |
| fwereade | hazmat: ok, that's not fair, but we didn't test anything like as much as we did at the place before | 17:32 |
| fwereade | anyway, I think I'm degenerating into friday evening rambling, and I should be off | 17:33 |
| fwereade | bye all :) | 17:33 |
| robbiew | Friday? | 17:33 |
| robbiew | lol | 17:33 |
| * robbiew notes that fwereade is on holiday tomorrow | 17:33 | |
| _mup_ | Bug #814194 was filed: Implement support for expose and unexpose hooks <Ensemble:New> < https://launchpad.net/bugs/814194 > | 17:34 |
| hazmat | daker, here's a test for it btw, if you could add this to your branch in ensemble/control/tests/test_shutdown the branch should be good.. https://pastebin.canonical.com/50078/ | 17:34 |
| daker | oh good thanls hazmat | 17:35 |
| hazmat | daker, np, thanks for working on it | 17:36 |
| daker | hazmat, would be good if you can put it on paste.u.c, i don't have permission access that site | 17:36 |
| daker | to* | 17:37 |
| hazmat | daker, http://pastebin.ubuntu.com/649319/ | 17:37 |
| daker | hazmat, one last question, how can i run the test ? | 17:39 |
| hazmat | daker, the easiest option assuming you have the zookeeper package installed (and the zk server running) is just trial ensemble/control/tests/test_shutdown.py | 17:40 |
| daker | ok | 17:40 |
| daker | any thoughts http://paste.ubuntu.com/649326/ ? | 17:48 |
| daker | hazmat, ^ | 17:49 |
| hazmat | PYTHONPATH=/home/daker/Projects/small-fix/ trial ensemble/control/tests/test_shutdown.py | 17:49 |
| hazmat | daker, ^ | 17:49 |
| hazmat | trial is from the twisted pkg | 17:49 |
| daker | hazmat, is the test includes the -y argument ? | 17:50 |
| hazmat | daker, the test i pasted does | 17:50 |
| daker | ok hazmat the test succeed | 17:51 |
| hazmat | daker, the error is because the test is being run directly, which A) isn't going to work as the test runner won't be invoked b) relative imports need a fully qualified reference to work correctly when the script is being run this way the current module doesn't really know its package | 17:51 |
| hazmat | daker, cool, i tested before i pasted, but its good to have confirmation ;-) | 17:51 |
| daker | hazmat, done! https://code.launchpad.net/~daker/ensemble/small-fix/+merge/68038 | 17:57 |
| niemeyer | Yo all | 18:03 |
| jimbaker | niemeyer, hi | 18:04 |
| _mup_ | ensemble/security-groups r285 committed by kapil.thangavelu@canonical.com | 18:07 |
| _mup_ | security groups | 18:07 |
| === daker is now known as daker_ | ||
| _mup_ | ensemble/security-groups r286 committed by kapil.thangavelu@canonical.com | 19:22 |
| _mup_ | group principal membership management and connection attaching. | 19:22 |
| _mup_ | Bug #814260 was filed: Ensemble security group principals <Ensemble:New for hazmat> < https://launchpad.net/bugs/814260 > | 20:02 |
| _mup_ | ensemble/security-groups r287 committed by kapil.thangavelu@canonical.com | 20:12 |
| _mup_ | add get_token to groupprincipal for parity with normal principal | 20:12 |
| _mup_ | ensemble/trunk-merge r272 committed by kapil.thangavelu@canonical.com | 20:16 |
| _mup_ | merge trunk | 20:16 |
| _mup_ | ensemble/security-otp-principal r289 committed by kapil.thangavelu@canonical.com | 21:06 |
| _mup_ | otp principal for passing credentials via insecure channels | 21:06 |
| _mup_ | ensemble/robust-hook-exit r281 committed by jim.baker@canonical.com | 21:18 |
| _mup_ | Use processExited as the normal end of the process, while making processEnded available for purposes like testing | 21:18 |
| _mup_ | ensemble/robust-hook-exit r282 committed by jim.baker@canonical.com | 21:28 |
| _mup_ | PEP8 | 21:28 |
| _mup_ | ensemble/robust-hook-exit r283 committed by jim.baker@canonical.com | 21:40 |
| _mup_ | Doc string | 21:40 |
| _mup_ | ensemble/security-otp-principal r290 committed by kapil.thangavelu@canonical.com | 22:02 |
| _mup_ | minimal principal interface for otp, using the otp consumes it | 22:02 |
| _mup_ | Bug #814320 was filed: Need OTP for passing credentials to an external process <Ensemble:In Progress by hazmat> < https://launchpad.net/bugs/814320 > | 22:07 |
| hazmat | phew.. i think thats all the core security machinery needed | 22:09 |
| hazmat | sigh.. "Launchpad encountered an internal error during the following operation: generating the diff for a merge proposal. It was logged with id OOPS-2028MPJ3. Sorry for the inconvenience. | 22:09 |
| hazmat | " | 22:09 |
| hazmat | oh well | 22:09 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!