17:03:43 #startmeeting qa 17:03:44 Meeting started Thu Apr 4 17:03:43 2013 UTC. The chair is davidkranz. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:03:46 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:03:48 The meeting name has been set to 'qa' 17:03:59 #topic Summit 17:04:28 I just saw an email to the qa list about a scenarios session. 17:04:39 unreviewed 17:04:41 I don't know when that session was submitted. 17:04:51 hi 17:05:07 I don't think it was there when we discussed the sessions. 17:05:11 i think 10days ago 17:05:14 hey 17:05:29 davidkranz: yeah, I think it was a bit of a latecomer 17:05:41 I am still not sure I understand what the real purpose is. 17:06:23 My understanding was talking about more project integration tests (nova/cinder integration tests, etc) 17:07:09 dwalleck: If they are currently deficient they should be improved but that is already a clear part of Tempest's mission. 17:07:22 davidkranz: agreed 17:07:34 ++ 17:07:43 So perhaps this should be discussed as part of the last session which is to discuss missing tests. 17:08:01 ravikumar_hp: I think you submitted that one. 17:08:10 yes. test gaps 17:08:20 davidkranz: either that, or we continue to discuss it in the mailing list thread and make it clear that just because something may be long-running doesn't mean it doesn't belong in tempest 17:08:40 to convert to blueprints that will address in Havava . 17:08:57 ravikumar_hp: I think blueprints for missing tests is the right approach. 17:09:32 ok. 17:09:41 jaypipes: I hope we hash out the whole "what tests should be in tempest" issue at the summit. 17:09:46 davidkranz: no session needed ? 17:10:02 ravikumar_hp: I don't think so but you can bring this up in your gap session. 17:10:29 ravikumar_hp: I just don't see it as a new concept that we need a separate session for. 17:10:37 I agree. 17:10:51 ok 17:10:59 ravikumar_hp: Great. 17:11:19 I think it would be good for session proposers to put up etherpads before the summit. 17:11:37 makes sense] 17:11:43 Is there some "official" place to put such etherpads. 17:12:08 isn't there an openstack etherpad? 17:12:40 dwalleck: Yes, I meant the links so people can find them. 17:13:09 dwalleck: to the individual session etherpads. Ideally they would be in the session descriptions online. 17:13:37 We could ask ttx about that. 17:14:37 dwalleck: Are you guys going to post the new stuff you talked about before the summit? 17:15:07 davidkranz: we're working out getting it right now. Sam? 17:15:16 Hey David. It's been posted to StackForge. I've finished the the zuul, build configuration, etc... and it's waiting on Approval 17:15:23 https://review.openstack.org/#/c/25870/ 17:15:46 When that goes through, the repositories will be hosted on StackForge 17:16:21 RAX-Sam: OK, it would be really helpful if we could take a look before the summit so the discussion can be better informed. 17:16:36 Absolutely. Has been our goal. :-) 17:17:02 RAX-Sam: If there is some kind of holdup in the official process perhaps you could point us at an informal link to the code. 17:17:36 #topic General Discussion 17:17:39 There has been some activity and review today. If it hasn't been merged by today I'll email some links around tomorrow 17:17:47 RAX-Sam: Thanks! 17:18:06 Any one have a topic to bring up? 17:18:22 https://blueprints.launchpad.net/tempest/+spec/update-expected-exception-tests is implemented can someone with previleges close it? 17:19:23 related to the scenario testing the policy.json mentioned by ykaul 17:19:49 donaldngo_hp: Just did that. 17:20:12 thank you 17:20:18 afazekas: Not sure what you are pointing at. 17:20:33 We should extend the default policy.json 's in-order to have a user type which is member of tenant but does not have permission to do anything 17:21:17 by the default policy many operation is doable by everyone 17:21:47 we do not test the code path when the operation rejected by the policy module 17:22:09 afazekas: Oh, I see. 17:22:11 I think the policy module itself is tested by unit test 17:22:35 I think the trick is that there's no guarantee in a given environment what the policy.json is 17:22:48 afazekas: Doesn't trying to do an admin thing as non-admin cover that? 17:23:01 I do not thing so 17:23:26 some cases yes, but in many case it is not 17:23:32 You could do generated tests from a policy.json, but that would definitely need a lot of work 17:23:41 yes 17:23:43 afazekas: Which code path are you saying is not covered? It is potentially different for each project, no? 17:24:01 when the policy module rejects on operation 17:24:05 davidkranz: here now sorry, lunch went long 17:24:15 dwalleck: Isn't that unit-test territory? 17:24:22 we have test cases for attemting operations from differnt tenent, but it is differnt decision 17:24:47 davidkranz: Not necessarily 17:25:05 davidkranz: the correctness of the policy module itself is a unit test territory imho 17:25:19 but the usage of the policy module is not 17:25:50 afazekas: So this heads back to the issue of how complete a functional api test tempest is supposed to be. 17:26:02 afazekas: There seem to be many opinions about this. 17:26:08 https://blueprints.launchpad.net/tempest/+spec/add-glance-policy-tests 17:26:44 davidkranz: yes to policy module allow us to define very crazy polices 17:27:31 afazekas: Where would you like to see this discussion end up? 17:28:16 I would like to add to have two type of "regular" users 17:28:18 I think the difference is "Does policy.json work?" vs. "Do I have the expected policy.json deployed and does it enforce the permissions I expect?" 17:28:47 the "nobody" type, who does not have any permission, but can authenticate 17:29:19 and the "somebody" , who has the same capability what the default users have now 17:29:30 and the admin users .. 17:30:48 afazekas: The blueprint you pointed to does this with admin/non-admin users. 17:31:09 afazekas: I must be missing something because I don't understand the difference in code path with nobody/regular user. 17:31:11 davidkranz: yes, but compare it with the default devstack policy.json 17:32:04 http://www.fpaste.org/R9d3/ 17:32:33 I do would like to use different policy than in the blueprint 17:32:45 "default": "role:sombody", 17:33:12 the "demo" user should have this right 17:34:55 the policy.json which is in the blueprint is copied from an openstack documantion 17:35:08 http://docs.openstack.org/developer/glance/policies.html 17:35:11 afazekas: I see that. 17:35:23 dwalleck: Do you have a comment about this? 17:36:59 afazekas: How about you propose something specific. 17:37:17 afazekas: I don't think there is any objection, just not clear about what needs to be changed. 17:37:23 davidkranz: I see both sides. I'm thinking. If we have this specific config, then we're really just testing that specific configuration 17:37:46 dwalleck: Yes, and for that particular project. 17:38:26 But we could have devstack use a policy file that has more meat for testing. 17:38:42 I think that is what afazekas wants. 17:38:46 I started a longer e-mail about the scenario stress and policy testing .., but I did not finished it and probably I will rephrase it 17:39:03 davidkranz: yes 17:39:25 afazekas: OK, sounds good. We can continue in email. 17:39:34 ok 17:40:00 Anything else to bring up? 17:41:33 OK, I guess we are done for today then. 17:41:36 not from me, just looking forward for portland 17:42:07 sdague: Me too. 17:42:51 I hope some of us can take a look at the new RAX stuff. 17:43:06 See you all next week. 17:43:12 #endmeeting