17:59:58 #startmeeting keystone 17:59:58 Meeting started Tue Apr 5 17:59:58 2016 UTC and is due to finish in 60 minutes. The chair is stevemar. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:59:59 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:01 o/ 18:00:01 o/ 18:00:02 The meeting name has been set to 'keystone' 18:00:02 \o 18:00:07 hi 18:00:11 o/ 18:00:16 o/ 18:00:24 o/ 18:00:33 O/ 18:00:55 o/ 18:01:09 \o 18:01:15 agenda: https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting 18:01:19 \o/ 18:01:41 not much on the agenda today 18:01:47 o/ 18:01:50 \o 18:01:52 assuming there isn't much open disucssion we can cut the meeting short 18:02:01 #topic Enforcing the code of conduct 18:02:04 ayoung: ^ 18:02:49 * stevemar pokes ayoung 18:02:59 hey 18:03:04 there you are! 18:03:09 I hope ayoung isn't going to kick me out of openstack 18:03:16 so...had an interesting exchange last week 18:03:23 that's putting it lightly 18:03:35 does poking comply with code of conduct? 18:03:37 we had someone in the chatroom asking for help, morgan was doing his part, and I chimed in 18:03:42 and proceeded to get abused 18:03:43 breton: :) 18:03:51 did i miss something good last week? 18:03:54 now...if it is going to happen to anyone, I want it to be me 18:03:58 dstanek: not good. 18:04:04 I think we all know that I can take it. 18:04:06 But... 18:04:09 its not about me. 18:04:21 No one should have to take it 18:04:28 Even if they can. 18:04:28 And I think that I made a mistake in letting the other person off. 18:04:33 Its about the community 18:04:46 and the environment in the chat room, and the project 18:05:00 later, stevemar kick banned this person 18:05:06 Fwiw, this incident was also escalated to the foundation (fungi, thingee, and others) 18:05:23 I've been working with them on this front as well. 18:05:28 so, we were caught unprepared, and, fortunately, no real harm done 18:05:49 if something like this happens again...here is how I think we should react 18:05:50 yes, a situation to be taken seriously no matter the perceived impact 18:06:09 on the first time someone says something that is a personal attack, the conversation stops. 18:06:25 We make it point blank clear that this is not the acceptable way to communicate 18:06:46 and, it should not be the person attacked responsibility to respond 18:06:58 it should be the other cores, especially Ops in the room 18:07:06 sounds like what we teach our kids in school about bullies 18:07:18 +1 18:07:26 IOW, reasonable and appropriate 18:07:26 o/ 18:07:37 works for me. 18:07:44 ++ 18:07:46 I got a few people sending me personal messages of support. While I do appreciate that, in retrospect, it would have been better to be public about even that 18:07:53 #link https://www.openstack.org/legal/community-code-of-conduct/ 18:07:59 fwiw https://www.openstack.org/legal/community-code-of-conduct/ 18:08:04 Dolph, Steve, and I are ops and if none of us are around infra has a the ability to handle these things as well 18:08:05 doh 18:08:11 ayoung, ++ had 2 of them this week 18:08:14 never tell the person that is being attacked that they should be the one to back down or leave, unless they are actively contributing 18:08:28 hi 18:08:37 also unsurprisingly, there was some pattern of escalation. i found another less severe conversation from january i think it was where there were some comments verging on being personal attacks against developers responsible for some patch. if it had been made clear then that it was unacceptable behavior, the individual responsible may not have taken things even further in this more recent incident 18:08:40 and, let me be clear, you can always call on me if there is a question 18:08:59 yeah, let's not try to engage and throw rocks bad 18:09:01 back* 18:09:08 just raise a flag to the ops 18:09:11 regardless of how ayoung wanted to handle it, there were several things that hit our code of conduct. I'd rather stop it there and make it clear. 18:09:18 thingee: ++ 18:09:23 thingee, exactly. 18:09:36 And, as a final point, thanks for being such a great community about this. 18:09:49 As I said, we were caught unware, which means our responses were unrehersed 18:10:00 so, maybe they were a bit slow, but they were the right responses 18:10:17 a special kudos to stevemar who had to be the heavy this time. It is a tough thing to do 18:10:24 It thankfully is rare enough in the community. But we will be better about it if something happens again like this 18:10:25 ayoung: (and others who were engaged in that particular exchange) thanks for being level-headed, professional and non-combative 18:10:37 happy to 18:10:43 one last point 18:10:51 its easy to feel sorry for the person that we kick banned 18:10:59 "oh he was probably a dumb kid" or whatever 18:11:03 na - he had it coming 18:11:09 heh your one last point of a final point. :) 18:11:14 but remember, there are many, many people that get abused and just dissapear 18:11:36 ok, thats all 18:11:49 * morgan runs to get through airport security. 18:11:49 thanks ayoung 18:11:59 the greatest impact is often on others who are simply seeing it unfold, and not directly engaged in the discussion 18:12:10 ++ 18:12:43 alrighty, now for a much more fun topic... testing! 18:13:04 lol 18:13:06 thanks for chiming in fungi and thingee 18:13:09 nice...i have 20 minutes left before i have to drop off for a meeting 18:13:16 #topic Migrate keystone tempest tests into keystone tree 18:13:20 rodrigods you have the floor 18:13:33 hi guys... just want your feedback about this 18:13:38 should we move everything to our repo? 18:13:46 define everything? 18:13:58 already have a patch for it: https://review.openstack.org/#/c/301398/ 18:14:00 ayoung: thanks for bringing that up 18:14:02 shaleh, all keystone API tests 18:14:04 last time we discussed moving negative tests 18:14:14 I don't think we should move everything to our repo, since then it can't be part of the defcore or whatever it is. 18:14:30 bknudson, how so? 18:14:38 bknudson, well, what repo? 18:14:42 keystone server? 18:14:48 this is something that is being done by another projects 18:14:49 or should it be aseparate repo, managed by us 18:14:54 its like 6K lines 18:14:54 rodrigods: right, why move more than the negative tests? 18:14:58 for example: https://github.com/openstack/ironic/commit/57e3ba1af8c6a939cab18d0255a26f6a1eca0d49 18:15:17 dstanek, so we don't occupy the gate of other projects 18:15:24 rodrigods: good question. I don't know how defcore works so I can't say that I have any idea what effect this is going to have. 18:15:32 i'm still confused about the tempest vs /functional/tests 18:15:46 maybe it should be broken into several patches 18:15:57 ayoung: my understanding is that tests need to be in tempest in order to be included in defcore. 18:15:58 because reviewing 6k LOC is terrible. 18:15:59 knikolla, tempest *are* functional tests, just in an external project 18:15:59 is tempest doing this for all projects? 18:16:00 breton, it should be easy to review 18:16:23 stevemar, this is not required 18:16:29 ayoung, right, and there is a spec to move them inside keystone and outside of tempest 18:16:31 knikolla: i think this is where we can put our functional tests. tempest didn't want them in their source tree 18:16:37 it is just an option 18:16:51 i wanted to write new tests for our tempest plugin 18:16:53 before we approve this there should be a review posted to tempest to remove the tests. 18:17:05 i got stuck in copying stuff of tempest (a lot of stuff) 18:17:29 then i remembered this was being done by other projects and thought to get your opinion about it 18:17:53 maybe move only v3? or move none (just move the configs and clients) 18:17:58 rodrigods: my push back would be to see what tempest wants in their tests because i can't imagine that they don't want at least the defcore stuff 18:18:26 i was referring to this: https://github.com/openstack/keystone-specs/blob/master/specs/keystone/ongoing/functional-testing.rst 18:18:41 dstanek, agreed 18:19:00 dstanek, what would you think would be the dividing line between something that was a functional test in keystone vs tempest? 18:19:05 so... what should be the approach? copy stuff when needed? 18:19:37 why do we need to copy? don't they provide a library? 18:20:12 bknudson, is it ok to import their clients over? 18:20:19 rodrigods: why not? 18:20:22 ayoung: my understanding what that most of the tests we wanted to do don't fit their roadmap (error conditions, complicated keystone-only flows, etc) 18:20:52 rodrigods: yes 18:21:18 so we need at least a good chunk of the Tempest tests anyway? 18:21:18 if so... i think we only need configs and minor stuff 18:21:33 ayoung, i guess we need to move only the negative ones 18:21:50 ayoung: nobody seems good at drawing this line. but it seems to be that any negative testing and single project tests (except defcore) are not really wanted 18:21:56 btw... tempest-lib is going to be deprecated 18:22:00 we should use tempest directly 18:22:28 I'm tempted to take everything, but put it into a separate repo: keystone-testing 18:22:35 I have no idea why tempest came up with admin/v3 tests... makes no sense 18:22:48 I kindof want our test code to be able to test both server and client, maybe CLI too 18:22:56 bknudson, just because was the only place to put the integration tests 18:23:20 bknudson: we regularily get questions about v3 and admin ports/pipeline/api 18:23:55 does anyone have a strong opinion that the functional tests should *not* be in a separate, but Keystone team managed, repo? 18:23:57 i kinda like the idea of a separate repo for testing 18:24:07 +1 18:24:13 the only advantage in having them in the same repo 18:24:19 is that we can require integration tests 18:24:23 for the features 18:24:43 rodrigods, so, I would like it to work like this: 18:24:55 having them in the same repo can test proposed reviews 18:24:56 we initially decided to keep it in the same repo to make sure their was parity (because v3 tests would go away in favor or functional tests) 18:24:59 1. Submite your patch to Keystone. It gets -1 Needs tests 18:25:00 with new tests 18:25:14 2. Submit your patch to test repo. It passes with patched, does not pass with master 18:25:20 you can test proposed reviews in a separate repo using depends-on. 18:25:24 these known failures are marked as "pending..." 18:25:28 and we thought it would be easy to split later as opposed to making infra to work just to undo it if we changed our minds 18:25:36 bknudson, right. 18:25:44 and then, once the patch merges, the tests that failed before are not passing 18:25:50 er 18:25:54 are *now* passing 18:26:00 (btw... please take a look at https://review.openstack.org/#/c/298696/) 18:26:09 its more like double-entry accounting? 18:26:32 ayoung, the tests would need to be merged later or with some skip decorator 18:26:39 rodrigods, right 18:26:55 so we won't move everything, right? 18:26:57 skip decorator is a good approach, I think? 18:27:28 you can use depends-on to show that your tests work with the new code 18:27:34 dstanek, any opinion? You kindof kicked off this landslide 18:27:50 bknudson, ++ 18:27:58 o/ 18:28:02 we should document, but is the overall approach something we can all get behind? 18:28:16 this should be clear to all reviewers 18:28:17 ayoung: not really. i still like the rationale of defering to see if we need to, but i'd be ok adding another repo if we think we need it 18:28:28 ayoung: we constantly change our minds here :-) 18:28:32 I'm fine with it in the same repo or a separate repo. 18:28:49 not only for the core team and most active ones 18:28:55 tempest thought that it would work well to have tempest-lib separate and then they had to bring it back in. 18:28:57 so, the rational for a separate repo is that we can make tests like we used to have for different versions of libraries and servers 18:29:26 ayoung: let's make sure all the testing we want to do can be handled by a separate repo 18:29:31 and it's easy to move the code out to a library from keystone. 18:29:42 not saying we need 100% backwards compat, but it does make it possible 18:29:44 bknudson, +1 18:29:51 separate repo makes dev workflow harder 18:29:56 not just tempest tests, but keystoneclient functional tests, and keystone functional tests 18:30:12 keystoneauth ? 18:30:15 keystonemiddleware ? 18:30:17 #link http://docs.openstack.org/developer/tempest/plugin.html#standalone-plugin-vs-in-repo-plugin 18:30:22 yep and yep 18:30:25 they even have a doc about it :P 18:30:33 bknudson: right, that's what we said last time. split later if needed instead of doing it because we thought we would need it 18:30:39 with middleware, we could spin up the echo service 18:31:26 bknudson: you know it 18:31:58 so, I don't want rodrigods spinning his wheels here. We should make a decision of some sort that he can act on. Move the tempest tests into Keystone server? 18:32:00 so the proposal is a single repo for functional testing of all keystone projects? That's a new one to me. 18:32:46 I think we should put the tests in keystone for now so we can get started more quickly. 18:32:54 we can start requiring to have the integration tests once the gate job is merged 18:32:59 and we see how it goes 18:33:19 i'm okay with the tests in keystone for now with the plan to split them later 18:33:36 OK. And, to be honest, I thimnk I'd like us to just approve the bulk transfer of the tests now, and then do any winnowing by removal 18:33:52 I'd rather double cover than have a period with no coverage 18:33:58 merge the tests as they are and remove them works for me, too. 18:34:10 ++ 18:34:48 rodrigods, any last thoughts? 18:34:50 not a fan of the potential double maintenance for a while, but hopefully we can get things sorted out quickly enough 18:34:52 ayoung, makes sense 18:34:58 nope 18:35:07 stevemar, want to #action that? 18:35:08 it is a huge review, but it is easy to review 18:35:23 (just need to check the diffs between keystone's and tempest's trees) 18:35:26 just do a diff to see what changed. 18:35:33 the command is in the commit message 18:36:11 besides that, only the README 18:36:13 #action merge the tests as they are and scope out to see if a new repo makes sense 18:36:27 and documentation 18:37:03 i would need to check bknudson's suggestion of importing the clients, instead of copying them 18:37:13 or we should copy them? 18:37:34 rodrigods: ask qa if they think we should copy or not. 18:37:44 bknudson, ok 18:38:11 * morgan back now through airport security 18:38:24 copy for now, 18:38:32 stevemar: ++ on keeping in keystone for now, and looking at split later 18:38:44 we could end up with a circular dependency otherwise, no? 18:38:49 and... anyone with experience with gate jobs 18:38:51 stevemar: ++ 18:39:04 please review https://review.openstack.org/#/c/298696/ 18:39:35 O 18:39:43 I still think it should be keystone/tempest_plugin rather than keystone/keystone_tempest_plugin. 18:40:29 bknudson: ++ 18:40:36 kinda self explanatory 18:40:38 bknudson: ++ 18:40:39 bknudson, not sure if we would be able to run with 'tox -e all-plugin -- keystone' 18:40:56 but... i can test locally and send a follow up patch to fix that 18:41:01 bknudson: ++ 18:41:10 rodrigods: sounds good 18:41:55 OK...we done? 18:42:03 ayoung, i guess :) 18:42:10 yes, merge this and get the gate job going 18:42:16 bknudson, ++ 18:42:52 Yay 18:43:02 knikolla, roxanaghe BTW, good work on the LDAP Python3 stuff. That is going to be "critical path" as python3 is getting to be essential 18:43:23 and the LDAP gate job should probably tie in with this functional test effort, too 18:43:42 ayoung, ++ 18:43:47 btw... knikolla and i were discussing about federation tests 18:43:50 and infra 18:43:55 if we get our ldap3 driver working, should we deprecate ldap (old one) right away? 18:44:02 we added a topic for the newton summit design sessions 18:44:03 stevemar, sort of 18:44:14 stevemar, if the old one and the new one support the same interface, no 18:44:23 let's deprecate the ldap driver when the ldap3 one is ready 18:44:26 ayoung: the new one will have to 18:44:26 instead, we replace old one with new, and update the entrypoint 18:44:37 bknudson: ++ 18:44:54 knikolla: have you looked to see if ldap3 has ldap pooling? 18:44:55 Oh..yeah, I guess we can leave the etnrypioint, and just deprecate the code though, right? 18:45:00 I doubt the drivers are going to have the same interface. 18:45:02 ayoung: yep 18:45:08 especially config options 18:45:19 stevemar, it has, i've got in running. but not for auth. 18:45:23 it* 18:45:37 BTW, has anyone made sure all of the authnentication code works correctly with ldap3? 18:45:39 sasl? 18:46:39 http://adam.younglogic.com/2012/02/exteranl-sasl/ 18:46:43 is list_limit here supported? 18:46:44 knikolla: not for auth? that's strange 18:47:07 *there, in ldap3 backend 18:47:20 #topic open discussion 18:47:29 (forgot to update the topic) 18:47:30 breton, for ldap? 18:47:37 ayoung: yes 18:47:53 stevemar, when i try pulling in the authenticate method it doesn't through me away, even with wrong credentials. I'm looking into that. 18:47:53 rderose: breton have you guys looked at a fix for this bug? https://bugs.launchpad.net/keystone/+bug/1566282 18:47:54 Launchpad bug 1566282 in OpenStack Identity (keystone) "Returning federated user fails to authenticate with HTTP 500" [Undecided,In progress] - Assigned to Boris Bobrov (bbobrov) 18:47:56 please triage https://review.openstack.org/301795 and review the fix 18:48:05 breton, should be part of the protocol. I would expect it to be, but should be something we confirm, too 18:48:07 throw* 18:48:12 oh, other way around 18:48:21 stevemar: there is ldappool built into LDAP 3 lib 18:48:21 breton: ha, just mentioned that too 18:48:26 morgan: nice 18:48:35 stevemar: looking... 18:48:37 ayoung: no, i mean the option list_limit 18:48:38 rderose: dolphm ^ https://review.openstack.org/#/c/301795/ 18:48:47 ayoung: i implemented it for existing ldap backend 18:48:54 Needs to be explicitly used but it is there vs a separate lib 18:48:59 ayoung: is it supported in the new one? 18:49:25 breton, then yes 18:49:54 breton, is there a unit test for it? If so, then roxanaghe 's work is defined by that 18:50:22 ayoung: unit tests are for ldap backend 18:50:30 ayoung: not general afaik 18:50:58 ayoung, I've seen code around that but haven't gotten that far 18:51:08 because it works differently for LDAP and SQL, and i didn't have time to unify the tests 18:52:05 breton, unit tests are using a fakeldap we built to simulate ldap responses 18:52:40 we can do functional tests though, i've subclassed the ldap3 driver with a writeable implementation. 18:53:04 if we have a writable implementation why not just support it? 18:53:24 bknudson, so we were thinking that writable was just for testing 18:53:37 but in general, LDAP should not be writable. 18:53:50 open discussion is a copy of openstack-keystone :) 3 subjects are being discussed at the same time 18:53:51 it lowers the support threshold 18:53:59 ok, lets moeve there 18:54:04 stevemar, want to close out here? 18:54:14 knikolla, I think the writable apis will be useful for unit tests 18:54:18 ayoung: yeah, was just tpying that up 18:54:20 thanks all o/ 18:54:23 i think we're all doing other stuff 18:54:24 o/ 18:54:35 lets close this out and move to #openstack-keystone 18:54:40 ++ 18:54:44 thanks for showing up everyone 18:54:47 #endmeeting