18:01:55 <samueldmq> #startmeeting keystone
18:01:56 <openstack> Meeting started Tue Jun  7 18:01:55 2016 UTC and is due to finish in 60 minutes.  The chair is samueldmq. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:57 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:00 <openstack> The meeting name has been set to 'keystone'
18:02:01 <shaleh> \o
18:02:07 <samueldmq> welcome everyone
18:02:24 <nk2527> o/
18:02:26 <samueldmq> we have 4 topics to discuss today
18:02:35 <samueldmq> #topic Mapping shadow users into projects and roles
18:02:41 <samueldmq> dolphm: o/
18:02:41 <notmorgan> samueldmq: i have an open topic at the end to add
18:02:50 <notmorgan> samueldmq: so just save me ~5m at the end pl
18:02:52 <notmorgan> z
18:02:59 <samueldmq> notmorgan: sure
18:03:24 <samueldmq> is dolphm around ? otherwise we can just start with another topic and then circle back
18:03:36 <ayoung> this is autoprovisioning.
18:03:48 <dolphm> yes
18:03:50 <ayoung> We've had a request for this for a long time
18:04:02 <samueldmq> dolphm: nice, the floor is yours
18:04:31 <dolphm> #link https://review.openstack.org/#/c/324055/
18:04:46 <dolphm> so, this spec came directly out of the austin summit
18:05:15 <dolphm> the gist is that it makes a lot of sense to do some basic provisioning of authorization-related things in mapping, especially for federation use cases
18:05:24 <dolphm> since we have a chicken & egg problem otherwise
18:05:53 <dolphm> ayoung's "Federated query APIs" specification has a pretty good illustration of that chicken & egg problem
18:05:58 <notmorgan> dolphm: imnsho +2.
18:05:58 <topol> dolphm +++
18:06:10 <notmorgan> (imnsho = in my not so humble opinion)
18:06:20 <ayoung> dolphm, question...is control of this going to be managed solely by the mapping file, or will we use an additional domain specific config to "gate" whether a projedct can be automatically created within a specific domain?
18:06:38 <dolphm> so, the solution here is basically to lazily provision things like projects and role assignments during the auth process - after a user has been authenticated, but before we give them a token for the first time
18:06:45 <rodrigods> ayoung, there is a domain attribute
18:06:47 <dolphm> so that token can actually be immediately useful, with a project, roles, and all
18:07:11 <ayoung> Actually...I'd like to see a domain specific config value "allowed_idps" for mapping in general, and then autocreate is on top of that
18:07:30 <notmorgan> ayoung: that is a fair request.
18:07:35 <notmorgan> ayoung: i think.
18:07:41 <dolphm> ayoung: as part of the spec, i'm envisioning mapping files to become a bit more domain-specific, if that makes sense. i think domain admins should be able to manage their own mapping files
18:07:50 <rodrigods> idps should be tied to domains since the beginning
18:07:50 <notmorgan> dolphm: ++
18:07:50 <ayoung> notmorgan, yeah, with the config options in the database, this is more practical, too
18:07:52 <rodrigods> they are domains
18:07:56 <henrynash_> dolphm: so (as you know) I support this (although have a follow up concern whcih is next on teh agenda, but that doesn’t stop the conceptual idea here)
18:08:00 <ayoung> dolphm, 10000% yes
18:08:09 <dolphm> so, there's a domain ID attribute in the mapping which is the key to that notion
18:08:21 <notmorgan> henrynash_: and i have a very strong view on that. but i'll hold until your topic.
18:08:35 <henrynash_> notmorgan: cool
18:08:46 <shaleh> so where is the disagreement here?
18:08:49 <dstanek> dolphm: could this eventually solve the "i project 1234 here and when i federation there i also get project 1234"?
18:08:58 <samueldmq> shaleh: I don't think there is one :)
18:08:58 <ayoung> dolphm, I think that if we say "create the domain, create the domain specific config, specify idps for domain, allow auto provisioning"  in that order we are on the right track
18:09:24 <shaleh> are we doing on demand creation to save DB space or something?
18:09:28 <dolphm> shaleh: this spec is new since last meeting, so i was just looking for an opportunity to socialize it, and answer any questions
18:09:40 <shaleh> dolphm: k
18:09:44 <lbragstad> i'm on board
18:09:46 <ayoung> then the mapping can be uploaded safely, as it can only map to specific domains
18:09:55 <notmorgan> shaleh: on demand or pre-create doesn't really change the nature of the spec.
18:10:04 <dolphm> shaleh: to save space versus pre-provisioning a bunch of projects you may not need?
18:10:08 <shaleh> notmorgan: agreed. I was asking about the detail
18:10:21 <ayoung> henrynash_, you are the Domain specific config guru.  Does what I say make sense?  is it practical?
18:10:32 <lbragstad> and also to get around the weird ux of having a user hit keystone (uselessly) in order to assign them stuff
18:10:37 <samueldmq> would it be a good idea to let admins explicitly set when a project is expected to exist ?
18:10:43 <samueldmq> in the mapping ? ^ dolphm
18:11:01 <shaleh> samueldmq: expand on that
18:11:02 <dolphm> samueldmq: i replied to your comment in the review
18:11:15 <rodrigods> samueldmq, good point
18:11:17 <dolphm> samueldmq: L141
18:11:28 * samueldmq nods, looking
18:11:54 <shaleh> on first read this sounds reasonable. I need to think about it some.
18:11:56 <ayoung> dolphm, I'll respond to the review request with these suggestions.
18:12:02 <dolphm> samueldmq: rodrigods: the suggestion implies a lot of complexity without a well defined use case to support it
18:12:04 <henrynash_> ayoung: probably…but need to dig in deeper
18:12:19 <dolphm> shaleh: cool - you'll have plenty of time to digest :)
18:12:22 <rodrigods> dolphm, good point too in the reply :)
18:12:28 <rodrigods> dolphm, did you consider HMT?
18:12:37 <rodrigods> i mean... the mapping is flat
18:12:44 <shaleh> rodrigods: nah, who wants that :-)
18:13:03 <dolphm> rodrigods: it's a list of projects, and each project object could have a parent ID, description, etc -- the other things a project requires
18:13:09 <samueldmq> dolphm: default would be true, but if it's set to create=False and it exists... mapping invalid ?
18:13:11 <rodrigods> dolphm, ++
18:13:17 <samueldmq> dolphm: that doesn't work, I agree that just adds complexity
18:13:24 <jamielennox> still reading but in general i like it
18:13:42 <rodrigods> dolphm, and... inherited roles? the same?
18:13:50 <dolphm> jamielennox: i believe it's what you were describing on the mailing list
18:14:02 <dolphm> in the thread with amakarov
18:14:20 <jamielennox> dolphm: whilst i need to think about the domain admins managing this - why does that need to be part of this spec??
18:14:22 <notmorgan> dolphm: this seems to cover a chunk of the provisioning concerns. so i am a fan.
18:14:33 <jamielennox> dolphm: yea, but i assumed it would be more difficult than this :)
18:14:57 <dolphm> rodrigods: i imagine inherited roles could be expressed as an attribute on the role object in the project definition? so for example, inherited=True (or whatever the attribute is called in the role assignment API) on L144 for example
18:15:11 <rodrigods> dolphm, yeah, makes sense
18:15:19 <rodrigods> dolphm, suggest just to add a note about them there
18:15:54 <dolphm> jamielennox: good question. the constraint is not a hard requirement, but it simplifies the mapping definition (otherwise, you'd have to specify a bunch of domain IDs in the mapping, for each project and all)
18:16:25 <dolphm> jamielennox: doing it once at the top seems to solve everyone's use cases that i've talked to, and simplifies the security model quite a bit
18:16:44 <notmorgan> dolphm: ++
18:16:54 <dolphm> notmorgan: a chunk? where would you want to take it next / what does it not cover?
18:17:02 <samueldmq> nice, any other concerns on this spec ? I think we seem to have an agreement on it
18:17:05 <dolphm> notmorgan: i assume you agree this is MVP for the idea
18:17:09 <notmorgan> dolphm: yes.
18:17:14 <notmorgan> dolphm: and can be built on.
18:17:14 <ayoung> henrynash_, I'd be OK with, instead of them being domain specific config options, they go on the domain object in the resource backend.
18:17:23 * topol felt very MVP to me as well
18:17:31 <notmorgan> dolphm: i don't see anything clearly needing to be added now. a good starting place
18:17:35 <dolphm> notmorgan: ack
18:17:36 <dolphm> samueldmq: thanks, we can move on
18:17:42 <samueldmq> dolphm: perfect
18:17:45 <notmorgan> dolphm: and like i said +2 :)
18:17:52 <samueldmq> so please review the spec, and let's move on
18:17:53 <henrynash_> ayoung: but could you write policy rule to control management?
18:17:58 <jamielennox> dolphm: yea, in general i would think it simplifies most peoples case and helps the domain admin model, but there is some additional validation i think you would want to see like if you specify a domain id for a whole mapping then you shouldn't be able to specify a different domain id for any project or role
18:18:03 <ayoung> henrynash_, I don't think you need to.
18:18:07 <samueldmq> #topic Should shadowing users be optional?
18:18:12 <jamielennox> dolphm: to the point where it should almost be a different spec
18:18:13 <samueldmq> henrynash_: o/
18:18:16 * notmorgan grabs soapbox.
18:18:20 <henrynash_> ah oops
18:18:21 <ayoung> henrynash_, it could be enforced by the rules engine at mapping time, or even confirmed when the mapping is uploaded
18:18:31 <henrynash_> ayoung: later, i’;m up
18:18:49 <jamielennox> also where is that domain name immutable flag
18:19:06 <ayoung> jamielennox, that is a global value
18:19:16 <dolphm> jamielennox: agree, and i forgot about that flag
18:19:18 <notmorgan> ok, please coninute this convo on the spec
18:19:23 <henrynash_> so my concern here is about whether we NEED to have shadow users…what If I don’t want local direct assigments…and have multidatcentres….don;t I know have another bigs table to replicate?
18:19:24 <dolphm> notmorgan: ++
18:19:29 <samueldmq> notmorgan: ++
18:19:35 <notmorgan> henrynash_: yes. we do.
18:19:39 <samueldmq> let's focus on the current topic
18:19:44 <ayoung> henrynash_, would that be on a per Idp basis?
18:19:45 <notmorgan> henrynash_: this should not be optional
18:19:49 <BroNeed> What is this place?
18:19:53 <henrynash_> notmorgan: becasue....
18:20:09 <notmorgan> the data doesn't move that fast, it simplifies out internal code paths AND security model
18:20:20 <notmorgan> and it prevents us from many many extra edge cases
18:20:25 <BroNeed> AND you say?
18:20:29 <rderose> notmorgan: ++
18:20:30 <dstanek> henrynash_: replication shouldn't be terrible unless you are adding/removing users at lightning speed
18:20:30 <dolphm> henrynash_: so... your use case is that you have separate clouds that should not have replicated identity data?
18:20:41 <dolphm> henrynash_: why are you replicating in the first place?
18:20:48 <notmorgan> have multiple code paths, security models, etc all means we're battling a lot of possible paths of maintenance and optimisation
18:20:49 <BroNeed> many many you say?
18:20:59 <henrynash_> dolphm: I am assuming federation, but replication projects and assignments
18:21:11 <jamielennox> yea, i don't think shadow users should be optional
18:21:15 <BroNeed> optimization u say?
18:21:30 <BroNeed> shadow users you say?
18:21:30 <notmorgan> fungi, jeblair, mordred, might need a kick here in this channel (cc anyone who is op)
18:21:32 <jamielennox> there are too many things that will hopefully rely upon it like direct role assignment
18:21:36 <shaleh> can we find a way to prevent the need to replicate?
18:21:58 <ayoung> shaleh, no,  I don't think so
18:22:01 <henrynash_> so why do we need direct role assignment if we have this mapping faciity we sjust discussed?
18:22:03 <ayoung> shaleh, actuallllly
18:22:04 <ayoung> yes
18:22:17 <notmorgan> fungi, jeblair, mordred: will ping if it becomes really important. (thnx)
18:22:21 <samueldmq> notmorgan: thanks
18:22:22 <BroNeed> Do any of you know what are you are talkibg about or arw you just using fancy words with no meaning?
18:22:27 <ayoung> henrynash_, so, what if we forced the id_mapping approach on shadow users
18:22:30 <dolphm> BroNeed: are you here for an actual discussion, or are you just spamming the channel?
18:22:38 <BroNeed> Yes
18:22:51 <BroNeed> I asked what is this place
18:22:53 <rderose> henrynash_: mapping relies on direct role assignments
18:22:54 <henrynash_> (don’t ecnourage it)
18:23:01 <ayoung> dolphm, pretty sure it is a bot
18:23:08 <dolphm> ayoung: agree
18:23:09 <BroNeed> Lol no
18:23:14 <BroNeed> I am no bot.
18:23:22 <dolphm> BroNeed: please don't disrupt the meeting unless you have something to contribute
18:23:33 <BroNeed> Just asking what this placw is
18:23:40 <shaleh> ^topic
18:23:44 <BroNeed> Yes mam
18:23:52 <dstanek> ayoung: you think we can do away with the replication?
18:23:57 <ayoung> dstanek, yep
18:24:05 <ayoung> if the userid is deterministic
18:24:12 <ayoung> it will be the same in all places
18:24:16 <ayoung> for LDAP idMapping we do
18:24:18 <dolphm> henrynash_: i don't see the data being created by shadow users to be particularly burdensome for replication
18:24:19 <henrynash_> redrose: if the mapping is going to create an assignment (whcih is what we just dsicused), why couldn’t it use teh epemeral user_id created by the mappoing
18:24:22 <shaleh> considering all the work Fernet puts into limiting replication, I'd rather not add more
18:24:31 <ayoung> sha256{userid, domainid}
18:24:42 <ayoung> we'd make Federation use idp instead
18:24:43 <dolphm> henrynash_: as usual, there will be bursts of writes when new users arrive, but that's true today anyway
18:24:47 <ayoung> sha256{userid, idpid}
18:24:54 <ayoung> with the userid value the value from the assertion
18:24:58 <jamielennox> user id being deterministic doesn't get you things like role assignments that were created
18:25:06 <notmorgan> jamielennox: ++
18:25:21 <notmorgan> but role assignments could be replicated without too much worry --
18:25:29 <jamielennox> notmorgan: so could user ids
18:25:35 <notmorgan> jamielennox: sure.
18:25:43 <notmorgan> jamielennox: i'd argue you'd probably replicate it all.
18:26:05 <notmorgan> but i see this as non-optional, is my only point, not digging into replicate-or-not-to-replicate
18:26:17 <dolphm> shaleh: it's also the difference between rather static data (users, roles, projects), and highly disposable data (tokens)
18:26:18 <ayoung> jamielennox, but if there are explicit role assignments, those would have to be replicated anyway.  henrynash_ 's complaint is that his setup does not have direct role assignments in the normal case
18:26:23 <henrynash_> i’d just seems really odd that we have federation, then we require keystone to replaciate around shadow versions of this same info
18:26:26 <dstanek> i'm a firm -1 here because it just makes things too complicated.
18:26:34 <shaleh> dolphm: understood
18:26:36 <dstanek> at what scale is user replication problematic?
18:26:39 <notmorgan> dstanek: -1 on optional?
18:26:47 <dstanek> yes
18:26:48 <notmorgan> dstanek: or -1 on required?
18:26:53 <notmorgan> dstanek: :P
18:26:57 <dstanek> it needs to be required
18:26:59 <lbragstad> you'd have to be creating thousands of users a second, no
18:27:00 <lbragstad> ?
18:27:01 <notmorgan> ok cool.
18:27:08 <dstanek> lbragstad: maybe?
18:27:21 <notmorgan> replication of even a few thousand rows is not that much
18:27:24 <notmorgan> fwiw.
18:27:32 <shaleh> lbragstad: new group onboarding, M&A, etc.
18:27:33 <dstanek> is this an actual problem that we can quantify and solve or is it theoretical right now?
18:27:37 <jamielennox> ayoung: but therefore what you can have keystones without replicating data? what about projects etc?
18:27:42 * notmorgan steps off the soapbox.
18:27:51 * notmorgan shoves the soapbox back under the desk
18:28:07 <dolphm> dstanek: ++
18:28:12 <gyee> you can also configure selective replication right? doesn't have to be all tables
18:28:22 <samueldmq> dstanek: good question
18:28:25 <ayoung> jamielennox, it would work like this:
18:28:28 <notmorgan> gyee: you can.
18:28:40 <rderose> henrynash_: yeah, it's possible, but I think the goal is to eventually treat federated users like any other users and not have these special edge cases (ephemeral).
18:28:49 <notmorgan> samueldmq: 30m in (fyi)
18:28:56 <topol> do we have use cases for all these fancy replication bells and whistles?
18:29:04 <gyee> notmorgan, then we don't need to do anything special on the keystone side
18:29:07 <ayoung> don't replicate shadow user, but replicate role assignment./  User goes from instance 1, where they have a shadow user record, to instance 2 where they do now.  Shadow user record is created, and mataches id in role assignment
18:29:10 <notmorgan> gyee: exactly
18:29:12 <samueldmq> notmorgan: thnaks, we're changing topics now
18:29:31 <notmorgan> topol: replication is deployer choices and out of scope of keystone imo
18:29:34 <samueldmq> so, we don't seem to have a 100% agreement on this right now, henrynash_ please post comments on the spec and continue discussion there
18:29:38 <samueldmq> we need to move on
18:29:41 <ayoung> dolphm, do you have any strong objection to the userid generation scheme I proposed?
18:29:42 <henrynash_> ayoung: assuming you don’t have something liek service users in your default domain, which you probably do
18:29:46 <shaleh> ayoung: that sounds like what we all discussed happening in Tokyo
18:29:49 <bknudson> we're likely going to need to figure out a way to replicate users, projects, etc., so that we can share tokens between datacenters. database replication doesn't work when the code is at different levels.
18:29:52 <ayoung> henrynash_, will still work
18:30:09 <jamielennox> yea, -1 on making this optional, you already replicate a lot of data to make this work, users is not a big deal and simplifies our code a lot
18:30:11 <samueldmq> please continue in dolphm's spec
18:30:15 <samueldmq> #topic SAML2 Middleware
18:30:19 <henrynash_> ok, thx
18:30:21 <samueldmq> dstanek: o/
18:30:30 <gyee> bknudson, don't share, trust :-)
18:30:36 <dstanek> samueldmq: o/
18:30:46 <dstanek> #link https://github.com/dstanek/keystone-saml2-experiment/tree/testshib-hacking (experimental hacking)
18:30:55 <dstanek> this is something i've been working on and wanted to give an update and collect some input
18:30:57 <topol> notmorgan yes those bells and whistles were scaring me a little
18:31:06 <dstanek> i need the IdPs that a Keystone SP can use to be highly dynamic and controlled by an API
18:31:16 <dstanek> i want to limit Apache restarts
18:31:23 <lbragstad> ++
18:31:24 <dstanek> i want to limit the need to use Keystone's API to manipulate thirdparty configuration
18:31:33 <dstanek> i want centralized control over the IdP configuration (read: database not distributed XML files)
18:31:58 <dstanek> so...i started working on middleware to replace mod_shib/shibboleth - that is mostly backed by pysaml2
18:32:22 <topol> dstanek very cool!
18:32:23 <shaleh> dstanek: less dependence on apache too???
18:32:25 <ayoung> dstanek, could you tackle this in mod_auth_mellon instead
18:32:30 <ayoung> please
18:32:38 <dolphm> ayoung: in?
18:32:39 <gyee> dstanek, we went over this awhile back
18:32:42 <ayoung> the world needs this. It is not a Keystone specific requirement
18:32:46 <gyee> I remember we hit a few critical issues
18:32:47 <dstanek> right now i can almost do a round trip using testship (will be done by the end of the day)
18:33:04 <ayoung> dolphm, anything that needs SSO needs to be able to mananage the Idps
18:33:05 <gyee> 1) how to prevent replay attack
18:33:08 <dstanek> i did lots of experiments with shib and mellon, but not a lot of good results
18:33:29 <dstanek> ayoung: i will provide for the world!
18:33:31 <dolphm> gyee: a replay of what against what?
18:33:37 <samueldmq> dstanek: this is a great idea
18:33:38 <ayoung> dstanek, we have a team that works on that kind of stuff.
18:33:48 <gyee> dolphm, submit the saml doc twice
18:33:58 <dstanek> gyee: that's not terrible. you just need a list of open requests.
18:34:00 <gyee> like managing the relay state
18:34:11 <dstanek> samueldmq: not my idea :-) i'm just hacking on it
18:34:13 <ayoung> its a python specific approach.  I have real concerns with doing crypto heavy operations in python
18:34:29 <ayoung> but, that is not the real issue
18:34:42 <samueldmq> dstanek: hacking on it in keystone is your great idea ;)
18:34:42 <dstanek> gyee: right now my demo code does this with a process cache, but in a real impl i would have to use the database
18:34:46 <dolphm> gyee: so after breaking the SSL connection between the client and keystone, you want to prevent a third party from sending that same request?
18:35:05 <jamielennox> gyee: i don't remember there being a nonce or anything in saml2? is there?
18:35:08 <ayoung> the real issue is that having SAML handled by a module for Apache that needs config file changes is too static
18:35:20 <dstanek> dolphm: yes. because clients are stupid and may log saml or whatever
18:35:20 <gyee> there's a relay state management in shibd
18:35:22 <jamielennox> gyee: there's a validity period on the assertion, but nothing that the server does specifically for replays
18:35:42 <gyee> it also includes trust originator
18:35:54 <gyee> like the entire request URL is part of the signature itself
18:36:02 <ayoung> I don't want to get Keystone into the world of  general SAML support unless we are going to use SAML to replace tokens
18:36:08 <bknudson> is this a new library or does it live in keystone?
18:36:14 <gyee> I remember we were having trouble with it when fronted by a proxy
18:36:31 <bknudson> probably has to live in keystone if it's got a db
18:36:43 <dolphm> gyee: how does shib / mellon solve that problem?
18:36:56 <dstanek> bknudson: i would like it to live in keystone since i think it would be generally useful
18:37:10 <gyee> dolphm, it validates what's in the relay state against the caller
18:37:21 <ayoung> this is the wrong community for this dstanek .  SAML is only one of several Federation protocols.  We've had more requests for openicd lately than SAML
18:37:27 <gyee> like the request URL, time stamp, etc
18:37:28 <dstanek> ayoung: do you mean writing code to parse and interpret saml or writing code that uses a library to do that?
18:37:49 <samueldmq> dstanek: is there a spec up for review so we can review/use for discussions ?
18:37:54 <gyee> if we implement relay state in middleware that would be awesomer
18:37:54 <ayoung> dstanek, even the second part
18:38:01 <ayoung> its not a keystone specific problem
18:38:24 <dstanek> ayoung: we already do this for k2k - this just brings it full circle
18:38:34 <ayoung> dstanek, I know. and it was a mistake then
18:38:35 <bknudson> is restarting apache that big of a deal? you spin up a new instance and shut down the old one.
18:38:38 <rodrigods> k2k is crippled saml
18:38:44 <dolphm> ayoung: the keystone specific problem is managing one or more trusted IdP's per domain via the API as a domain admin without having to be the cloud operator, etc, right?
18:38:50 <dstanek> samueldmq: no, but there can be
18:38:58 <dolphm> bknudson: as a domain admin, i don't have the ability to do that
18:39:01 <samueldmq> dstanek: I think that would be useful
18:39:12 <jamielennox> also k2k is an saml idp which is an easier problem
18:39:24 <dstanek> samueldmq: couldn't design it before digging in
18:39:25 <ayoung> dolphm, even that is a general problem, we just solve it as an abstraction layer for the rest of openstack
18:39:43 <dstanek> jamielennox: an SP is actually pretty easy too
18:39:46 <gyee> just use PKI tokens :-)
18:39:47 <ayoung> well...ok you mean domain as an Openstack specific object, so yes you are right
18:39:50 <samueldmq> dstanek: got it
18:39:55 <dolphm> ayoung: yes, that's what i meant
18:39:56 <dstanek> the hardest thing is dealing with shibboleth
18:40:06 <gyee> ain't kidding
18:40:11 <ayoung> dstanek, I am working on a POC with a different IdP right now
18:40:14 <rodrigods> dstanek, not worried about implementing saml but regarding the whole security of such authenticator involves
18:40:19 <ayoung> I've worked with both Ipsilon and Keycloak
18:40:25 <rodrigods> gyee gave few examples
18:40:38 <ayoung> and the mod_mellon part is being extracted by jdennis
18:40:40 <samueldmq> #action dstanek to post a spec on SAML2 Middleware up to review
18:40:51 <gyee> rodrigods, PKI token are S/MIME doc essentially
18:40:55 <dolphm> ayoung: extracted to where?
18:41:00 <Wundrlnd> This has got to be the gayest nerd network tranny shit I have ever stumbled across I am going back to Dalnet where the pussy is.
18:41:00 <gyee> S/MIME's being around since the beginning of time
18:41:02 * notmorgan doesn't have a strong opinion on this front.
18:41:03 <dstanek> bknudson: the other issue is that it's easy for me to crash shib and i wouldn't want domain admins to be able to do that
18:41:04 <ayoung> there is registration code for mod_mellon to talk to Ipsilon as part of the ipsilon proejct, and he's done a standa lone for keycloak.
18:41:06 <ayoung> I'll link
18:41:34 <dstanek> rodrigods: is it any worse than what we already do?
18:41:51 <ayoung> https://github.com/jdennis/keycloak-httpd-client-install
18:42:07 <dstanek> does anyone have an hardcore "this is stupid" or "i hate you" type of feedback?
18:42:22 <dstanek> otherwise i'm just going to proceed
18:42:23 <ayoung> nkinder, dstanek is proposing moving the SAML processing to a middleware inside of keystone
18:42:27 <gyee> no, middleware is a great idea!
18:42:37 <gyee> if we get it to cover the bases
18:42:39 <ayoung> dstanek, I have a hard "please don't do it in keystone" feedback
18:42:40 <jamielennox> dstanek: so first thing is i don't see any management urls, but i assume they are an easy problem after getting the authenticator to work
18:42:52 <rodrigods> the problem is to know the whole base upfront
18:42:55 <ayoung> I don't think you are  stupid and I don't hate you, dstanek
18:42:56 <dstanek> i've started looking into shibboleth's dynamic federations, but it seems to be too complicated for actual use
18:42:57 <rderose> dstanek: i think you should proceed, it can just be another option
18:42:57 <rodrigods> gyee, ^
18:43:03 <notmorgan> just keep in mind python sucks at crypto work
18:43:11 <dolphm> ayoung: do you object to the domain-admin use case for managing federations, or to the implementation?
18:43:12 <samueldmq> so ayoung and dstanek (and others) please keep in the discussion in -keystone ?
18:43:12 <jamielennox> dstanek: i've in the past said to implement it elsewhere and i know you've looked into it so if you really have to do it in middleware i'd prefer it to live upstream in keystone
18:43:22 <ayoung> dolphm, implementation
18:43:22 <dstanek> ayoung: not moving...this is all new stuff for a SP
18:43:27 <notmorgan> well, likely will get better if we get some JIT added and/or asyncio+uvloop
18:43:28 <samueldmq> it should have a general agreement so dstanek can proceed with the spec/implementation
18:43:31 <samueldmq> we gotta move
18:43:32 <notmorgan> but just keep that in mind.
18:43:47 <samueldmq> #topic Performance testing patches up for review
18:43:49 <jamielennox> dstanek: but mostly i'd want to make sure this becomes something in contrib that people _can_ use, i don't think we should ever recommend it as the default
18:43:59 <samueldmq> lbragstad: o/
18:44:03 <dolphm> ayoung: i'm not clear on how an alternative implementation would satisfy the domain-admin-federation-manager use case, then
18:44:08 <lbragstad> so performance has been coming up ... a lt
18:44:09 <dstanek> jamielennox: ++
18:44:10 <lbragstad> lot*
18:44:15 <ayoung> dolphm, I want a general solution to SSO.  I want to have mod_mellon do exactly what dstanek is proposing anyway
18:44:22 <dolphm> ayoung: or at least, i'm not clear on what that alternative should look like
18:44:25 <notmorgan> samueldmq: can you timebox this at 10 min instead of 15 [for my last minute topic]
18:44:25 <lbragstad> i wanted to try and get something written that would allow us to test performance the same way
18:44:32 <lbragstad> that way we can get recreateable results
18:44:38 <notmorgan> lbragstad: ++ and i like it
18:44:42 <lbragstad> and hopefully tie it into reviews
18:44:47 <lbragstad> with something like leaving commit
18:44:50 <lbragstad> comment*
18:44:50 <samueldmq> notmorgan: sure, I will do that and leave your 5 mins at the end
18:44:51 <rodrigods> lbragstad, nice
18:45:00 <samueldmq> lbragstad: you have 10 mins :)
18:45:04 <lbragstad> like "recheck" but "check performance"
18:45:11 <gyee> rodrigods, bases as in managing and validating relay states
18:45:12 <ayoung> dolphm, so, accepting a new IdP is an operator level operation.  Lets assume we can make it far more managable than shibboleth does today.  jdennis 's tool is for that exact problem in keuycloak
18:45:15 <notmorgan> lbragstad: 3rd party CI can trigger on any event
18:45:16 <ayoung> and is based on the ipsilon approach
18:45:30 <lbragstad> so I start contributing what i have to one of my own repos https://github.com/lbragstad/keystone-performance
18:45:38 <ayoung> the two really should be merged into a single tool that knows about multiple Idps, but the amount of Idp specific logic is high right now
18:45:48 <lbragstad> ^ that will go through and set up keystone using openstack ansible
18:45:48 <shaleh> dstanek: even if it goes no where official, the code is worth exploring.
18:45:54 <ayoung> so...that is something that can be done by ansible fairly simply
18:45:56 <notmorgan> ayoung: we need to continue on, this convo will need to continue in -keystone or on a spec
18:46:01 <ayoung> notmorgan, ++
18:46:03 <notmorgan> ayoung: sorry. just keeping things moving.
18:46:07 <shaleh> dstanek: maybe it gets folded into another project, maybe it becomes a project. Still of value.
18:46:14 <jamielennox> lbragstad: so is this 3rd party or going to be on infra resources?
18:46:18 <lbragstad> the performance tests are extremely basic but I wanted to throw it out there so that people can play wiht it
18:46:18 <samueldmq> notmorgan: ayoung ++
18:46:24 <jamielennox> lbragstad: also i think it's beneficial
18:46:27 <lbragstad> jamielennox i might be able to get some bare metal resources
18:46:30 <notmorgan> jamielennox: it can't be in infra unless there is hardware dedicated to it.
18:46:31 <henrynash_> lbragstad: it’s a GREAT start
18:46:37 <bknudson> lbragstad: this is going to be really useful
18:46:43 <henrynash_> lbragstad: and we really neeed this
18:46:56 <notmorgan> jamielennox: it needs to be consistent hardware that isn't affected by bad neighbor/different provider
18:47:02 <bknudson> we'll likely wind up implementing something like this for our cloud, too.
18:47:02 <samueldmq> lbragstad: thanks for the initiative, and for sharing it
18:47:06 <jamielennox> notmorgan: ++
18:47:12 <gyee> are we talking about rally gate?
18:47:13 <notmorgan> jamielennox: or it needs to be run at least in consistent providers on consistent flavors
18:47:15 <lbragstad> so please play wiht it, open bugs against the plays, etc..
18:47:18 <notmorgan> gyee: no.
18:47:18 <bknudson> and hopefully we can share the tests, although every deployment is going to be different
18:47:31 <notmorgan> gyee: rally has failed to meet what lbragstad is proposing.
18:47:35 <jamielennox> notmorgan: mostly i was just thinking it's a lot easier problem if we just consider it a 3rd party job
18:47:36 <lbragstad> my next step is to write something that would kick of infra per patch
18:47:42 <shaleh> lbragstad: thanks for sharing the work you have
18:47:47 <notmorgan> jamielennox: i would like this ot be 3rd party tbh
18:48:11 <rodrigods> it needs dedicated hardware
18:48:15 <lbragstad> yep
18:48:16 <lbragstad> it is
18:48:26 <notmorgan> jamielennox: i am happy to ask -infra about taking it on, but right now they aren't (afaik) in  aplace for supporting this
18:48:29 <lbragstad> it's hosted on rackspace dedicated bare metal servers
18:48:29 <rodrigods> it needs to run lots of times, to get "real world" reports
18:48:39 <notmorgan> once infra-cloud is in a place it might be a topic worth considering with them.
18:48:54 <amakarov> lbragstad, why not to use rally for that? The only issue - it uses devstack
18:49:01 <lbragstad> exactly
18:49:01 <jamielennox> notmorgan: no, i'm thinking 3rd party is good, particularly if we have hardware in rax and rax people to fix it
18:49:03 <notmorgan> but there are lots of questions about running real bare-metal resources that i wouldn't want to lump on them until thye have a clear plan/story for it
18:49:09 <notmorgan> jamielennox: ++
18:49:22 <bknudson> if we can get rally to help out then we should take that
18:49:28 <bknudson> but as it is our needs are pretty simple.
18:49:39 <gyee> trouble with performance tests is really environment isolation and consistency
18:49:40 <bknudson> not that hard to write a script to validate a token
18:49:44 <gyee> something we can't do well with VMs
18:49:45 <notmorgan> i'm fine with rally being used. i wont support it being a "rally" job
18:49:47 * topol trust me henrynash really needs this performance stuff :-)
18:49:59 <henrynash_> topol: :-)
18:50:09 <notmorgan> i support it being "use appropriate technology" behind the scenes, regardless of what it is
18:50:11 <notmorgan> amakarov: ^
18:50:11 <jamielennox> lbragstad: have you got code somewhere for what will be run?
18:50:11 <samueldmq> topol: henrynash_ :)
18:50:14 <dolphm> gyee: hence, lbragstad is going straight to dedicated bare metal
18:50:21 <gyee> dolphm, no argument here
18:50:27 <jamielennox> lbragstad: what scope do you expect? just token validate?
18:50:33 <bknudson> jamielennox: https://github.com/lbragstad/keystone-performance/blob/master/validate.py
18:50:33 <amakarov> notmorgan, why not?
18:50:37 <notmorgan> jamielennox: token issue, token validate
18:50:46 <notmorgan> amakarov: because it doesn't matter what tech is used.
18:50:57 <notmorgan> amakarov: i will be very against calling it a "rally gate"
18:51:07 <notmorgan> amakarov: let the team decide what they'll use
18:51:07 <jamielennox> bknudson: doh - thanks
18:51:10 <notmorgan> it can be rally.
18:51:15 <notmorgan> it can be something else
18:51:18 <amakarov> notmorgan, understood
18:51:21 <lbragstad> jamielennox it does authenticate 1000 times and valiate 1000 times
18:51:22 <notmorgan> but if you lock it in as rally, i'm -2
18:51:27 <samueldmq> notmorgan: ++
18:51:43 <lbragstad> jamielennox https://github.com/lbragstad/keystone-performance
18:51:43 <notmorgan> amakarov: and rally very well might be the right tool :)
18:51:48 <samueldmq> lbragstad: nice, so basically make people aware of the performance tests
18:51:53 <samueldmq> lbragstad: you done ?
18:51:59 <lbragstad> samueldmq yep
18:52:02 <samueldmq> lbragstad: thanks
18:52:07 <notmorgan> lbragstad: make sure you get a proper 3rd party CI account
18:52:07 <bknudson> so one thing that's going to be tricky is dealing with larger config changes... e.g., switch from uuid to fernet for example
18:52:09 <lbragstad> all, ping me if you have questions
18:52:16 <samueldmq> #topic Open Discussion
18:52:18 <dolphm> bknudson: ++
18:52:20 <jamielennox> lbragstad: and somewhere to push results to, for pretty graphs?
18:52:22 <samueldmq> notmorgan: o/
18:52:25 <notmorgan> ok
18:52:27 <notmorgan> so
18:52:35 <notmorgan> going to harp on review numbers again
18:52:36 <dolphm> bknudson: i think the configuration that we use for testing needs to be "opinionated" for exactly that reason
18:52:44 <dolphm> bknudson: testing sqlite is not useful, for example
18:52:47 <notmorgan> #link http://paste.openstack.org/show/508737/
18:52:48 <gyee> so I am a bit concerned about this patch https://review.openstack.org/#/c/309146/
18:52:54 <lbragstad> dolphm so OSA is what I chose but I'm open to other opinions
18:53:03 <gyee> it will change the behavior of fernet tokens
18:53:15 <notmorgan> there have been 59 business days or so since RC1 of mitaka
18:53:34 <notmorgan> it is not unreasonable that all cores should be at 1-review-per-business day (newton)
18:53:39 <samueldmq> please let's focus on notmorgan's topic, just to keep moving :)
18:53:45 <notmorgan> people are doing better.
18:53:54 <notmorgan> but still calling to action - review.
18:54:10 <notmorgan> i will be administratively abandoning old reviews with no movement very soon.
18:54:19 <notmorgan> but please review.
18:54:29 <gyee> sir yes sir
18:54:46 <notmorgan> everyone should review. -1s, +1s, +0 all matters to us and helps
18:54:50 <topol> yep. will do
18:54:57 <samueldmq> notmorgan: ++
18:55:04 <dolphm> #goteam
18:55:06 <samueldmq> cores and non-cores are more than welcome to review
18:55:06 * dstanek hangs his head in shame
18:55:16 * dolphm joins dstanek
18:55:21 <notmorgan> I've been working with steve to keep an eye for potential new cores as well
18:55:22 <rodrigods> for non-cores, review is the best way to learn
18:55:22 <shaleh> dstanek: can't code all day :-)
18:55:41 <dstanek> shaleh: challenge accepted
18:55:42 * topol topol cant believe gyee reviewed more than he did....
18:55:43 <notmorgan> also if you CANT remain core, or don't want to, you can step down and be fast-tracked back in if you have time again
18:55:45 <dolphm> shaleh: what is the alternate universe you speak of
18:55:59 <shaleh> dolphm: married life :-)
18:56:09 <gyee> topol, the day ain't over yet
18:56:15 <notmorgan> just keep it in mind that we want you to be able to contribute
18:56:28 <notmorgan> and feel successful at it
18:56:31 <notmorgan> reviews, code, etc
18:56:37 <dstanek> shaleh: "sorry honey, but i really need to code right now."
18:56:51 <samueldmq> notmorgan: ++
18:56:57 <dolphm> memorize it!
18:57:05 <notmorgan> what ever makes it easiest for you to succeed.
18:57:17 <samueldmq> #action everyone to review/contribute code!
18:57:22 <notmorgan> core, non-core, etc, that is what we (core team, PTL, etc) is for.
18:57:32 <notmorgan> heck even bug triage
18:57:43 <gyee> dolphm, its MEMOIZE
18:57:43 <notmorgan> s/heck even/also
18:58:20 <samueldmq> notmorgan: keystone says: challenge accepted!
18:58:23 <notmorgan> i'm using stackalytics Newton cycle
18:58:32 <notmorgan> and http://www.timeanddate.com/date/workdays.html to figure out the number of "business days"
18:58:38 <amakarov> gyee, memoize also innvolves "invalidate" and "expire" :)
18:58:45 <gyee> there will be a draw at the end of the cycle for a free trip to barcelona
18:58:49 <gyee> drawing
18:58:54 <notmorgan> usually it's not quantity over quality, but when the numbers are this low... quantity matters too :)
18:58:54 <rodrigods> brazil has far less working days fwiw :)
18:59:01 <rodrigods> lots of holidays
18:59:07 <samueldmq> so, we're running out of time
18:59:12 <notmorgan> rodrigods: still 59 reviews since March 16th isn't unreasonable :P
18:59:13 <shaleh> rodrigods: even more time for review then :-)
18:59:15 <samueldmq> thanks everyone, it was a pleasure to ru nthis meeting :)
18:59:23 <notmorgan> rodrigods: in newton
18:59:27 <bknudson> don't forget to vote.
18:59:28 <notmorgan> (across all keystone repos)
18:59:28 <topol> good job samuelmdq
18:59:33 <samueldmq> #endmeeting