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