22:01:23 #startmeeting Reddwarf 22:01:24 Meeting started Tue Jan 22 22:01:23 2013 UTC. The chair is vipul. Information about MeetBot at http://wiki.debian.org/MeetBot. 22:01:25 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 22:01:28 The meeting name has been set to 'reddwarf' 22:01:28 ohai 22:01:36 #link http://wiki.openstack.org/Meetings/RedDwarfMeeting 22:01:56 shall we get started? 22:02:08 yeah, let's do it 22:02:08 works for me 22:02:09 #topic Action Item Updates 22:02:26 k, first one was mine - Blueprint on Quotas 22:02:53 argh trying to find 22:03:03 #link https://blueprints.launchpad.net/reddwarf/+spec/quotas 22:03:17 completed, for now, probably need to add some more details 22:03:28 sweet 22:03:34 next item.. TestR blueprint 22:03:43 anyone get a chance to take a peek? 22:04:06 nope. ive been knee deep in cinder code... 22:04:17 nope, still a todo for me 22:04:21 well cinder conversations and code :D 22:04:22 esp: does this still need another pair of eyes? or is it good to go 22:04:36 which part? 22:04:37 can u link it? 22:04:40 link? 22:04:46 #link https://blueprints.launchpad.net/reddwarf/+spec/testr-unit-tests 22:04:52 thx 22:04:57 np 22:05:03 yeah it wouldn't hurt to have someone look at it. 22:05:07 I've got a question: last meeting we decided to use sqlite and mocks strategically, but I ntocied in the blue print it says to never use sqlite. 22:05:23 hmm.. that would be a mistake. 22:05:26 let me look 22:05:26 good thing we're taking a look at it :) 22:05:38 seems valid 22:05:48 I think we were moving along the lines for not mixing mocks and sqlite tests 22:06:01 +1 22:06:03 ive set to approved 22:06:15 k, good enough 22:06:18 Has Nova stopped using sqlite in their unit tests? 22:06:20 I would like to see tests segmented by unit and integration (incl sqllite 22:06:46 I personally prefer using sqllite, instead of just mocks all over the place 22:06:50 Me too 22:06:54 im not sure if they have, but i do see that python-mysql is now necessary for test-requires 22:06:58 grapex: I can see the confusion in there. we do want to use sqlite eventually just having got that far yet. 22:07:08 Ok, I know how we can add it easily 22:07:10 which is annoying to me personally :) 22:07:16 I just wrote a test in testr that makes use of it 22:07:27 Assuming sqlite can be used with multiple procs, we should be OK 22:07:37 yep shouldn't be a big deal. just don't want to mix paradigms with mock vs sqlite 22:07:41 For some integration tests, sql-lite does make sense. 22:08:00 A lot of the stuff in models, i'd rather have it make real sql calls 22:08:01 "unit" tests doesn't mean to only use mocks, its one tool in the box 22:08:13 SlickNik I agree that sqllite would be ok in integration but not unittests 22:08:14 nova seems to mock it 22:08:31 i think they tend to lean towards Fixtures 22:08:31 yeah, yer all correct. we need to do a better job of naming things. 22:08:33 not complete mock 22:08:37 grapex: doesn't have to use mock but shouldn't be using a database 22:08:38 i have some unitests for the guestagent... specifically for query-creation classes...should those be tested using sqlite? 22:08:38 https://github.com/openstack/nova/blob/master/tools/test-requires 22:08:38 https://github.com/openstack/nova/tree/master/nova/tests/db 22:08:56 maybe just break them out: mock tests, sqlite tests. 22:09:11 steveleon: I'd think those types of tests would be better against a sqllite 22:09:17 how about "int-lite" 22:09:32 juice: nice one. 22:09:45 ok looks like we need a longer discussion on this 22:09:48 steveleon: I was thinking of doing both 22:09:51 ya table it vipul 22:09:54 juice_: We could put tests like that in the existing tests that run before testr 22:09:56 #action Discuss use of mock/sqllite/fixtures 22:10:13 Ok, next item.. Mutlipel images 22:10:16 sounds good 22:10:21 i think we settled that 22:10:33 working on it now 22:10:37 Yeah, we had a discussion on that. 22:10:50 k, the agreement was that we'd push percona 'element' to RD-int 22:11:05 #agreed 22:11:12 next item.. dkehn, SlickNik: setting up CI 22:11:21 #agreed 22:11:42 SlickNik, has the changes in the vm-gate functions and I'm testing as we speack 22:11:53 once completed will move to CI upstream 22:12:00 So far I've got the post-devstack changes in for redstack. 22:12:11 And the simple tests are working. 22:12:23 cool 22:12:33 There are a few black-box tests that are failing on me that I'm still debugging. 22:12:50 #action dkehn, SlickNik to complete CI with devstack-vm-gate with blackbox tests 22:12:56 and dkehn is working on integrating upstream with the vmgate. 22:13:04 have yall gotten it working on cloud servers? 22:13:10 rax cloud servers :) 22:13:12 k, that's next 22:13:15 We're doing this on HPCloud server. 22:13:21 hpcloud only 22:13:22 anyone have a rax account :) 22:13:24 I don't have access to RAX cloud servers :) 22:13:30 ill gladly spawn u one 22:13:36 dkehn, me either 22:13:36 tomorrow just remind me 22:13:45 okay, hub_cap, I'll ping you. 22:13:50 np 22:13:53 good luck w/ networking 22:13:56 Will be good to see how/if they're different. 22:13:59 it seems completely broken 22:14:13 thats where i stopped :D 22:14:18 somehow the CI guys are able to run there though 22:14:23 they may be doing some hacks 22:14:27 ya but they dont do tests from _in_ teh guest 22:14:33 they just spawn a instance 22:14:34 oh i see 22:14:35 we can do that 22:14:45 ya... 22:14:51 maybe someone on your end tho has some fu 22:15:08 #action SlickNik to test on Rax Cloud Servers 22:15:21 next item.. update on HP CLoud Server and int-tests 22:15:22 i torqued it a few times too ;) 22:15:32 I still haven't been able to get a good run on hpcloud instance 22:15:37 wtf... 22:15:43 thats sucky 22:15:43 wiht "cheat codes" i was successful 22:15:55 vipul: how many tests fail? 22:15:56 oh thats at least good... but a full run is failing? 22:16:05 but the tests have some funky dependency and hard to pinpoint exactly which one 22:16:13 mainly the Stop Test 22:16:19 but that causes a couple of skips 22:16:31 all others pass on a full run 22:16:34 vipul: maybe we can shed some light... if u can give someone like tim a login to a machine maybe he can play around w/ it 22:16:36 or me when i get some time 22:16:46 K, that will help. 22:17:16 #action Vipul hub_cap and grapex to debug int-tests on hpcloud 22:17:19 word 22:17:24 next item: cheat codes 22:17:43 cp16net gave us a brief intro to them last meeting 22:17:58 i think we're good unless there are other tricks we should know 22:18:13 i think there were just 1 or 2 right? 22:18:21 the instance is already created one 22:18:24 is it "up - down - up - down - left - right - left - right - a - b - enter" ? 22:18:30 lol 22:18:32 juice_: select start 22:18:40 yes, that's the one i saw, what's the other? 22:18:42 no wonder it never worked 22:18:42 my gamepad has no enter key 22:18:50 grapex: is there another cheat code? 22:18:52 what are "cheat codes" 22:19:00 in this context? 22:19:12 running integration tests, without creating an instance during the run 22:19:13 juice_: special ways to alter the executiojn of the tests 22:19:16 The only other one is TESTS_DO_NOT_DELETE_INSTANCE 22:19:21 env variables that you can set to speed up tests 22:19:23 ah 22:19:30 Set that to True and it skips the delete. 22:19:33 and of course there is 22:19:35 There's really only two. 22:19:37 gots it 22:19:38 --group=blackbox --stop 22:19:43 grapex: I've found that one especially useful. 22:19:45 that one will stop tests on first failure 22:19:50 --stop is a nose argument 22:19:54 ya 22:20:03 cool, good stuff 22:20:05 next: hub_cap to talk to heckj and bcwaldon about how they are doing their next gen specs 22:20:08 ./redstack int-tests --group=blackbox --stop <--useful if u wantt to diagnose 22:20:18 have not done so yet, its on my list 22:20:31 #action hub_cap to talk to heckj and bcwaldon about how they are doing their next gen specs 22:20:34 ive talked /w my mgr and we are going to start drafting v2 22:20:38 next: hub_cap to get the featureset for V2 started, BP & wiki 22:20:39 next week i will have something 22:20:51 thats same. put it on the action items 22:20:56 they are really one in the same 22:21:07 the v2 api is my top prio after i finish cinder 22:21:18 so next week sometime 22:21:23 K, at some point we need to sync up regarding feature set for v2 22:21:41 hub_cap to talk to mikeA about timelines for v1 wadl 22:21:47 I think you mentioned that's coming? 22:21:58 ya 22:22:01 any timeline? 22:22:10 so let me first talk about v2 "sync" 22:22:18 i totally agree we need to sync up 22:22:31 ill give u guys teh wiki links so u can add/edit as u see fit adn we can discuss 22:22:50 i dont want this to be a autocratic spec 22:22:57 now that im off that soapbox, v1 22:23:13 mike A is working on it now. he should have it ready soon... he didnt give an exact timeline 22:23:24 hub_cap: also regarding use of wiki. 22:23:26 #link https://github.com/stackforge/database-api 22:23:41 Ok, works for me. Just need to make sure we're aligned as far as features, and we can iterate on the wiki if that's the way it's done 22:23:46 is there a place we can start putting some of the knowledge we're uncovering around setting up, running, etc? 22:24:00 vipul: ill find it out some way or antoher and keep u in the email chain/etc/... 22:24:11 jcooley: id say create some wiki.openstack pages 22:24:18 maybe we need a "landing" page for reddwarf 22:24:27 and to put links on that... i _hate_ the wiki they have 22:24:29 ok, didn't know if you had an area you were currently using for similar 22:25:00 i'm just seeing us create knowledge internally that we should be sharing with the community 22:25:00 #action, link Reddwarf wiki area (create one if necessary) to http://wiki.openstack.org/Projects 22:25:00 for instance, there is a page for incubated project 22:25:00 http://wiki.openstack.org/Heat 22:25:31 #link http://wiki.openstack.org/Reddwarf 22:25:36 is still not created, probably the place to start 22:25:45 http://wiki.openstack.org/Reddwarf 22:25:48 i jsut did 22:25:48 Probably a good idea. 22:25:53 god it so slow 22:26:25 ok, last item juice: percona elements 22:26:45 hub_cap: sweet 22:27:09 juice ^^? 22:27:28 juice_: ^ ^ 22:27:31 :D 22:27:38 sneaky 22:27:41 pete 22:27:44 lol 22:27:46 heh 22:27:48 let me throw something at juice 22:27:49 oh this isint word association :) 22:28:06 what is the question? 22:28:13 #action juice_ to push percona bits to Redddwarf-Int 22:28:15 oh, oh…Do I see projectiles... 22:28:26 nerd frisbee please 22:28:29 nerf 22:28:32 either way 22:28:33 ok done with action items.. 22:28:45 #topic CI Updates 22:28:46 juice: all I have over here are keyboards and rocks 22:29:09 I htink SlickNik and dkehn covered most of this 22:29:18 I think so 22:29:20 yeah covered it earlier. 22:29:20 wanna recap? 22:29:22 yup, and all thats left is me to spin up a cloud isntacne for yall 22:29:32 ok, we're good then 22:29:42 what about the other topic quotas 22:29:45 we're targetting this by end of week? to push upstream? 22:30:13 juice_: it's coming... http://wiki.openstack.org/Meetings/RedDwarfMeeting 22:30:37 dkehn was looking into pushing upstream, he probably has a better idea of the timeline for that…dkehn? 22:31:22 I'm targeting as ASAP, but we must get it working and then separate it out into their schema (wrapper, etc.. 22:31:44 but yes, as soon as possible, I'm not the only one involved with CI 22:32:03 just an FYI for hub_cap, grapex: We're going to push upstream while invoking simple-tests for now 22:32:11 until we verify that blackbox runs everywhere 22:32:20 as in, you are testing locally before u push right? 22:32:26 once in upstream then we can add things to it 22:32:26 oh nm, simple-tests 22:32:30 I've got the simple tests running successfully on an HP Cloud instance after a post devstack build. Will talk to grapex about some issues I'm running into with the full suite of black-box tests. 22:32:32 yes 22:32:43 well int-tests should work on the cloud isntance 22:32:50 but simple-tests wont even work for u as is 22:32:51 :) 22:32:58 right, _should_ 22:33:06 sure, we run em all the time :D 22:33:19 but we run on old networked cloud servers b4 the new nova switch 22:33:22 and using openvz 22:33:25 :D 22:33:26 vipul SlickNik: As long as running all of blackbox remains a goal I'm good. 22:33:27 should we rip out simple-tests ? 22:33:32 right :) 22:33:42 grapex: Yep, blackbox is the end goal 22:33:42 or should we wait... 22:33:45 once we get int-tests solid we should remove simple-tests 22:33:52 cool 22:33:52 grapex, I'm with you 100% we want to run all of blackbox. 22:34:09 id like to figure out why your int-tests are failing, and im volunteering grapex time :) (jk) 22:34:15 do you guys run int-tests in KVM? 22:34:20 ya 22:34:21 this is the first step so we can iron out issues with pushing CI upstream and work on the testing issues in parallel. 22:34:26 im 100% public these days 22:34:34 and your int-tests work in local env right? 22:34:43 right, just not in a cloud instance 22:34:47 coo 22:34:47 yeah, they run fine in vmware fusion 22:34:55 lets figure out what the deal is w/ that this wk 22:35:02 ill spare some time vipul tomorrow if u want to chat it up 22:35:10 and give me a login so i can watch em go 22:35:15 (or not go...) 22:35:23 ok, so in the meantime we dont' want that holding up, which is why we push with simple-tests, and change it up later 22:35:27 hub_cap: sounds good 22:35:30 sure 22:35:41 k, next topic 22:35:45 but simple-tests will fail on a cloud server too ;) 22:35:53 lets roll 22:35:57 #topic Unit Test updates 22:36:25 annashen and I have been adding unittests to the guest agents 22:36:27 so we've got lots of tests the python-reddwarfclient + guestagent 22:36:48 grapex: wanna discuss what we need to do push the last two reviews through? 22:36:57 Sure 22:37:05 yeah hub_cap I'll try and see if I can make the tests (networking) work on cloud server. Get me a login.. :) 22:37:12 I've been writing an email about it for awhile 22:37:20 SlickNik: ill one up u, ill give u a dedicated server! 22:37:54 So first off, I want to say I know the code can be confusing and I'm sorry. I also apologize that there are unused functions and cruft and junk in the code. :( 22:37:54 grapex: just got the email 22:38:32 hub_cap: sweet! thx, will ping you after the meeting. 22:38:39 That said, while writing unit tests, especially for the reference guest which has no coverage other than the public tests that just started running, feel free to delete methods if you believe they aren't used. 22:38:43 grapex: It's all good... It's been a very good experience for us :-) 22:38:50 The integration tests should catch big issues like that 22:39:18 Yep, the issue is we don't have a way to check coverage with Integration Tests, unless you go through every test 22:39:24 plus we'll catch it in the gerrit reviews, if not we're not doing a good job of reviewing the pull requests. 22:39:33 vipul: Yes, that is a problem. 22:40:07 Maybe we need to talk to Monty or someone about this, but is it necessary to cover even methods we really can't test in the unit test environment? 22:40:31 I think the code would be clearer if we just added no cover directives 22:40:53 Then made sure to hit those with either integration tests or functional tests 22:41:10 Yep, I agree there is a probably a good balance... 22:41:26 at the same time.. eventually I think we'd like to get to a point where we can gate on a Coverage % 22:41:27 Another thing about the reference guest - Sneaky Pete has functional tests which do things like make sure the utility code to hit a MySQL db or call other processes is actually working. 22:41:45 vipul: We could add no coverage directives and then make the case during the gerrit review as to why 22:42:07 That could work.. 22:42:16 vipul: lets be careful about gating on coverage %s too... does any other project do it? 22:42:23 if we also added integration or functional tests as we do that, it would be kosher 22:42:33 not yet, but they'd like to.. so not saying we're ready to yet.. but eventually 22:42:50 ok cool id like to watch a openstack project do it for a while first 22:42:56 see how it works (or doesnt) for them :D 22:43:18 Second thing I would like to propose is that we spend some time deleting code that isn't currently isn't covered by the coverage report of the int-tests as run in Tox 22:43:31 yah, was thinking we could be conservative. just to make sure the coverage doesn't slide as new code is added. 22:43:32 When I got the integration tests working in tox the coverage was something like 78% 22:43:55 When I looked at what wasn't covered, some of it seemed like it could be cruft 22:44:08 ++ 22:44:15 and we should set the entire openstack/common dir to nocover too :D 22:44:19 I'm worried that by leaving this junk in there we could be wasting people's time if they cover it. :( 22:44:24 hub_cap: Agreed 22:44:33 ++ 22:44:33 god why isisnt that a pip library :D 22:45:03 So maybe the thing to do is aggressively remove junk first- kind of like when you're trying to put on muscle, first you lose all the weight you can and make sure the pounds you're adding aren't fat. :) 22:45:09 #agreed grapex, we'll need your assistance in Identifying some of the cruft.. since we're in a 'scared to delete cuz we don't know enough about it yet' mode 22:45:42 #agreed lol, while I don't quite agree with your analogy grapex, I completely echo your sentiments :) 22:46:03 lol grapex 22:46:09 vipul: I really appreciate that you are being careful with deleting stuff, I think that's coming from the right place. However the goal of the integration tests is to find anything wrong in the "happy path" so if necessary code is missing we should find out quick. 22:46:22 grapex is quite aggressive 22:46:27 Plus if anyone deletes something we need we'll be quick to point it out. 22:46:55 I'm aggressive, like an inverted junk yard dog that destroys junk rather than protecting it! 22:47:05 Having dead code to maintain is no fun. 22:47:24 having terrible analogies to maintain is no fun either :P 22:47:29 Ok grapex: so let's do this... can you guys look over the two reviews.. let's figure out what shouldn't be unit tests.. and get some of that merged 22:47:45 vipul: Will do. 22:47:45 agreed. grapex is your man for those 22:47:58 grapex: I'll ping ya in a bit to see if we can figure stuff out 22:48:14 #action grapex to look over guestagent unit test reviews, work with steveleon to get them merged 22:48:29 alright.. let's move on to the next thing 22:48:34 ill take some of the comments and suggestion from grapex and apply them to my patches 22:48:35 #topic Quota / Rate limiting 22:48:57 Ok we're starting to look at adding supprot for quotas, rate limits in REddwarf this sprint 22:49:07 Just quickly looked over repose 22:49:36 i guess the discussion is: what should this look like? since Repose is another standalone service 22:49:44 do we want to do something lightweight instead? 22:49:53 anyone looked at 'turnstile'? 22:49:55 well id say that we should not reinvent the wheel here :) 22:50:08 so wrt turnstyle i know nova said they would move to it eventually 22:50:08 don't do another tier. either repose (ok, maybe turnstile). 22:50:15 turnstile here appeared to have limited functionality 22:50:18 but they are using repose currently 22:50:23 but we should use an openstack project if one exists. 22:50:26 so i really dont want to have a 3rd type 22:50:33 jcooley: thats repose :P 22:50:35 ish 22:50:47 turnstile != repose :) 22:50:54 thats what they are trying to do w/ repose 22:51:00 hub_cap: nova has their own quota class i thought 22:51:01 hub_cap: in agreement on no 3rd option 22:51:21 ya its legacy 22:51:24 we looked at the repose project at the OS conference in SD. 22:51:26 its been around for a VERY long time 22:51:29 looks pretty interesting. 22:51:35 another potential Issue.. Repose is java 22:51:50 ugh. yah, so was our global proxy tier :( 22:52:04 since it's standalone, probably not a big deal.. but surprised that Openstack is choosing that 22:52:28 well... repose is trying to get into openstack 22:52:41 and at rax we are using it as a quota system 22:52:41 we may actually have to run it in our prod environment due to the HP deltas from Keystone, but... don't want this in the reference implementation. want to keep that clean from corporate operational requirements 22:52:51 but ure right, its not _the_ defacto 22:53:06 so maybe its not a bad idea to have something, albeit small 22:53:08 https://github.com/openstack/nova/commits/master/nova/quota.py 22:53:37 any reason why this is not in oslo? 22:53:41 https://github.com/openstack/nova/commit/1cf475d7a135c1078cf7df11c261618af501dc37 :) 22:53:44 an embedded class over a standalone service 22:53:46 repose is solving the right requirements. want rate limiting, white-listing, black-listing, SSL termination, Keystone middleware 22:53:46 vipul: thats a good question 22:53:53 sounds like a good place to start 22:54:24 use something like nova-quota unless there is a clear direction 22:54:31 but even https://github.com/klmitch/turnstile is old as crap 22:54:42 juice_: nova quota has no per user quota support fyi 22:54:50 jcooley, hub_cap: sounds like we wnat both an embedded quota solution + a repose hook 22:55:02 oooh. need to have per-user or per-tenant 22:55:10 its VERY limited 22:55:20 can we just write our own for the time being in the likes of nova-quota? 22:55:27 vipul: ++ 22:55:40 well why not try to push something to oslo instead? 22:55:42 repose goes in front, so just need to turn off any embeded solution 22:56:14 #link https://github.com/openstack/cinder/blob/master/cinder/quota.py 22:56:31 yea, that's an option, push a generic framework to Oslo 22:56:43 ya i wouldnt necessarily use cinder as the golden child vipul 22:56:51 #link https://github.com/openstack/nova/commits/master/nova/quota.py 22:57:01 looks liek they all basically have their own 22:57:10 jcooley: Or use both for double protection and give ops the joy of ensuring the configs are in sync. :) 22:57:17 right lets do this 22:57:24 grapex: yah, that's it! 22:57:26 we shouldnt decide this w/o buyin from some core peeps 22:57:34 lets talk to core nova/cinder/oslo 22:57:53 and see how they feel about either 1) moving something into oslo, or 2) a external wsgi service 22:58:07 rather than hack up and have YAQS (yet another quota system) 22:58:18 exactly 22:58:30 #action hub_cap and juice_ to talk to core nova/cinder/oslo about generic quota embedded vs external service 22:58:30 (it's not just about quotas)... 22:58:38 ok works for me 22:58:42 thx vipul 22:58:43 right, need to take into account rate limits 22:59:01 need SSL term, DOS protection (white/black listing), etc 22:59:03 ya those are another form of quotas from repos's perslective 22:59:22 rate and absolute limits is what we need to start with 22:59:45 but we digress... lets just work it offline w/ the core teams 23:00:10 alright.. let's get the discussion started at least 23:00:11 who will take the reigns on that one 23:00:41 juice_: see above 23:00:44 its me and u 23:00:44 juice_ can you start by talking to mordred, and then we bring it up to the Oslo members 23:00:58 ill talk w/ nova/cinder/glance ptls 23:01:07 ok 23:01:09 adn we can reconvene in a day or 2 23:01:13 i'm sure this is something everyone's thought about 23:01:20 and eveyrone has a differing answer :D 23:01:26 woo openstack! 23:01:42 woot! 23:01:50 k, we got a plan... 23:01:53 word 23:01:55 i think that's all for items 23:02:00 #topic Open Discussion 23:02:01 that sounds good. 23:02:03 and i dont really have any "extra" items to discuss... 23:02:07 anything else people want to get off ther chest 23:02:18 nothing from my end. 23:02:21 Functional tests 23:02:29 k. 23:02:34 In the blue print, there's talk about creating some kind of new framework 23:02:55 I don't see the point. We can just add new groups in the RDI tests and run them as part of CI. 23:02:57 grapex: this is the testr thing right? 23:03:01 Yes. 23:03:11 brb 23:03:41 yeah, there were folks who wanted to get closer to what openstack is using. 23:03:52 We do that at Racks for some internal stuff relating to billing, things we need to access certain resources for. There's not that many great examples of using it in the public. 23:04:09 I think CI guys want to be able to run tests in parallel someday 23:04:29 esp1: CI does run in parallel 23:04:37 esp1: for some projects. Want it for ~all 23:04:46 Is this a question of whether to add non-integration tests to probosis? 23:04:57 I see. We'll next hackathon at Rackspace I'll be looking at making Proboscis integrate with testr and run non-dependent test series together. 23:04:59 lifeless: right not at the moment but I think it's a goal of their's in the future 23:05:32 esp1: hmm? nova tests *already* run in parallel in CI 23:05:51 esp1: I may be confused about what you mean. 23:06:02 ya fo sure 23:06:03 vipul: My point is we use proboscis to do that internally and it's proven easy. The benefits is that all of the setup code to communicate to the database and other resources already lives there. 23:06:20 hi lifeless :) 23:06:23 lifeless: sorry misread. but I mean that folks want to run reddwarf tests in parallel one day. 23:06:24 lifeless: I think esp1 is talking about the current reddwarf tests running through proboscis. 23:06:44 ah right 23:06:52 I see the concern about parallel testing though. I think we'll alleviate it by reducing use of "depends_on" (which is overused now) and getting testr to fire off every non-related series of methods. 23:06:54 grapex, esp1: Getting probosis to run testr may be the solution here... if we can do that _and not make them all depend on one another_ then i am ok with it 23:06:57 yes, doing that in parallel +1 ;). Happy to advise on any testr questions. 23:07:08 yes, want the tests to run in parallel. don't want to write tests in probosis; want to use testr. 23:07:09 lifeless: Thanks 23:07:27 [and other stuff, but I suspect the only new thing here for you folk is testr :P] 23:07:42 jcooley: Keep in mind testr is the runner...we can still make use of test tools and everything. 23:08:09 just don't want to see a) reinventing the wheel, or b) a bunch of red-dwarf-only tools 23:08:33 regarding question of "functional" tests we were thinking of creating a separate package for tests that make will make use of sqlite there. 23:08:47 jcooley: I agree, I don't want to rewrite tests we've been depending on. 23:08:54 testr is the pirate of tests for sure 23:08:54 perhaps functional is not a good name. 23:09:06 grapex: yep. 23:09:22 I think it is misleading to use functional in that context 23:09:33 keep what we have, migrate eventually if we can -- if it makes sense. 23:09:40 it seems like the current int-tests are more functional than int-tests 23:09:41 So are we talking about unittests + live resources? 23:09:55 juice_: yep. so how about sqlitetests? 23:10:01 grapex: sounds good, I'm okay with proboscis as long as we can parallelize with testr. 23:10:05 grapex: so how about this... new tests that are not integration tests for now are just testr tests 23:10:08 grapex: yeah 23:10:20 I want to exercise the actual code and not mocks 23:10:27 ++ 23:10:30 depends on your background but I think the more common definition would be unit tests, integration tests (sqllite with multiple classes) and functional (almost near production / use case based) 23:10:39 and things that are integration-tests, and ones that need the additional 'live resources' need to go in as probosis 23:11:29 ok so are we in agreement? 23:11:35 vipul: Agreed, for now let's just keep it to unit tests we can run in tox and integration tests we run in the VM. This will include things that might for example test reference guest methods like "start_mysql" 23:12:07 #agreed 23:12:24 #agreed 23:12:31 #agrease 23:12:49 Ok, if that's all, i'm going to wrap it up 23:13:00 put a bow on it vipul 23:13:03 #endmeeting