18:01:30 <dolphm> #startmeeting keystone
18:01:31 <openstack> Meeting started Tue Mar 11 18:01:30 2014 UTC and is due to finish in 60 minutes.  The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:33 <bknudson> dolphm: hi
18:01:34 <openstack> The meeting name has been set to 'keystone'
18:01:36 <fmarco76> hi
18:01:44 <dolphm> #topic Feature freeze
18:02:07 <bknudson> and string freeze
18:02:09 <gyee> \o
18:02:12 <dolphm> so, overview of how feature freeze works for those that are new or just haven't been impacted in the past...
18:02:18 <dolphm> bknudson: ++ and string freeze!
18:02:19 <marekd> \o/
18:02:42 <marekd> what's that string freeze?
18:02:45 <dolphm> feature-y changes (especially those tracked against blueprints or wishlist bugs) get -2'd until the master branch is re-opened for juno development
18:03:32 <dolphm> and the master branch stays frozen until the list of release-blocking bugs is fully Fix Committed: https://launchpad.net/keystone/+milestone/icehouse-rc1
18:03:49 <ayoung> So everyone swtich from Server work to client work
18:03:49 <dolphm> string freeze: https://wiki.openstack.org/wiki/StringFreeze
18:04:02 <marekd> dolphm: thanks.
18:04:11 <ayoung> switch.
18:04:16 <dstanek> no freeze on the client code?
18:04:28 <dolphm> ayoung: ideally, everyone is focused on fixing bugs in the service so we have a stable release
18:04:39 <dolphm> string freeze basically gives the translation folks some time to catch up with string translations as they will appear in a stable/* release
18:04:40 <ayoung> Hehe
18:05:06 <marekd> dolphm: OK
18:05:49 <dolphm> #topic Review blocked feature-y changes
18:06:09 <dolphm> so there are inevitably bug fixes that appear feature-y for whatever reason
18:06:16 <dolphm> i have two on the agenda i wanted to review
18:07:12 <ayoung> if it says LDAP in the review, it is almost certainly a Bug fix.  If you see one with out a bugID, -2 it with "file a bug"
18:07:18 <dolphm> if we deem these changes to be incredibly safe, and we have a generally overwhelming desire to land them in icehouse, we can do so
18:07:31 <dolphm> first up...
18:07:31 <dolphm> #link https://review.openstack.org/#/c/76568/
18:07:34 <stevemar> dstanek, afaik you can play with client all you want, but try to fix server side bugs
18:08:13 <dolphm> this one is implementing previously NotImplemented methods in the assignment ldap driver
18:08:32 <bknudson> the unimplemented methods in the ldap backend are scary to me.
18:08:32 <ayoung> hmmm
18:08:41 <dolphm> actually i think that's a lie -- but it's introducing substantial functionality to the ldap assignment driver
18:09:16 <dolphm> this one doesn't look safe to me at first glance, but i wanted to raise it here in case anyone wanted to strongly advocate for it
18:09:29 <bknudson> I'd think https://review.openstack.org/#/c/76568/2/keystone/tests/test_backend_ldap.py would remove a bunch of skipped tests.
18:09:33 <dolphm> i definitely haven't done a thorough review so i can't speak to it
18:10:10 <gyee> "_get_global_roles_for_group", nice :)
18:10:18 <dolphm> yeah...
18:10:22 <gyee> I did't know global roles are supported
18:10:26 <ayoung> Any LDAP review that does not list me as a reviewer will get -2ed out of sheer spite
18:10:35 <gyee> that, or the method name is misleading
18:10:49 <ayoung> Nah, old stuff, needs top go away
18:10:52 <henrynash> so I was Ok with this patch when it was just adding in group roles….the "global roles" bit confuses me
18:11:03 <ayoung> LDAP needs domain scoping. Juno
18:11:36 <dolphm> henrynash: ++ i inquired in one of the bugs about the precedence it claims to be following -- i haven't gotten a response yet
18:12:22 <dolphm> doesn't sound like anyone is immediately comfortable with this one, so let's continue to hold it until juno
18:12:30 <dolphm> #link https://review.openstack.org/#/c/78521/
18:12:47 <dolphm> this one introduced a new config option, but it's a clean simple patch otherwise
18:12:52 <ayoung> that one is a new config option
18:12:55 <dolphm> if it lands, it should land ASAP (ideally last week)
18:12:57 <bknudson> dolphm: I think https://review.openstack.org/#/c/78521/ would be safe.
18:13:03 <dolphm> bknudson: ++
18:13:06 <bknudson> and also pretty desirable.
18:13:22 <dolphm> i'd like to advocate for this one on the basis that i'm aware of several deployments carrying custom patches to solve this problem :(
18:13:25 <ayoung> I can drop the -2 if you are all comfortable
18:14:08 <ayoung> should we /vote?
18:14:23 <henrynash> I'm for it
18:14:31 * ayoung has not gotten to use the vote option in a meeting yet
18:14:56 <dolphm> ayoung: ideally hold your -2 until there's overwhelming +2's on the review
18:15:05 <dolphm> ayoung: your -2 is completely appropriate given the config impact
18:15:10 <bknudson> hopefully the submitter will update it..
18:15:19 <ayoung> dolphm, lets use the vote option!
18:15:25 <ayoung> http://ci.openstack.org/meetbot.html#voting
18:15:29 <bknudson> (or if others agree with my suggestions I could make the updates)
18:15:34 <dolphm> ayoung: gerrit already has voting, and that's where it counts
18:15:37 <dolphm> bknudson: would you update it for them?
18:15:38 <dolphm> bknudson: ++
18:16:03 <dolphm> bknudson: so if it's not None, then set the config option in python-ldap?
18:16:12 <bknudson> dolphm: right
18:16:16 <dolphm> bknudson: in other words, no one is impacted by this change at all, which is perfect
18:16:41 <lbragstad> cjellick_: is the owner
18:17:14 <dolphm> lbragstad: awesome
18:17:37 <dolphm> cjellick_: if you're around, can you work with bknudson to make the above change? or he'll make it for you so we can land https://review.openstack.org/#/c/78521/ ASAP :)
18:18:08 <stevemar> it doesn't look too bad, at first glance
18:18:34 <dolphm> are there any other blocked reviews that anyone wants to consider? (that's the end of my list on the agenda)
18:18:46 <dolphm> if not, we'll just do open discussion until our time is up
18:19:20 <dolphm> dstanek: IIRC, you called me out on something i blocked last week?
18:19:35 <dstanek> dolphm: did i?
18:19:36 <gyee> dolphm, https://review.openstack.org/#/c/76476/
18:19:44 <jamielennox> https://review.openstack.org/#/c/78068/
18:19:46 <dstanek> don't recall
18:19:56 <dolphm> dstanek: you asked why i blocked something, and my answer was that i didn't think about it too hard
18:20:00 <ayoung> dolphm, I'd consider gyee 's review there a bugfix
18:20:31 <gyee> ec2 middleware should really be in keystoneclient
18:20:34 <ayoung> same rules as the LDAP one:  would not affect anyone
18:20:41 <jamielennox> gyee's i would be ok with
18:20:47 <dolphm> gyee: that's a good one
18:20:51 <jamielennox> mine i kind of think should be -2
18:20:53 <dstanek> dolphm: that's possible; i doubt it was anything i cared about; more likely that i'm trying to see the boundries of the process
18:21:04 <ayoung> welll...actually, no.  That one will break
18:21:05 <dolphm> gyee: ec2 runs on keystone, so i don't think that's true
18:21:14 <gyee> dolphm, but that's middleware
18:21:15 <dolphm> dstanek: ack
18:21:23 <dolphm> gyee: middleware that runs on top of keystone, yes
18:21:44 <gyee> dolphm, I don't think that one runs on top of keystone
18:21:55 <dolphm> gyee: oh i think you're right
18:22:00 <bknudson> would be nice if there were some unit tests covering ec2_token.
18:22:01 <dolphm> gyee: i wasn't looking at the file
18:22:23 <ayoung> gyee, only should be moved to keystoneclient if other services are going to pull that middleware in, too
18:22:45 <bknudson> looks like ec2_token doesn't use identity_api or anything?
18:23:00 <dolphm> bknudson: correct, it's like auth_token
18:23:04 <gyee> ayoung, not sure, I am getting conflicting messages about ec2 support in general
18:23:05 <ayoung> gyee, how about submitting a client review
18:23:16 <bknudson> so moving to keystoneclient makes sense to me
18:23:18 <ayoung> you could easily put https://review.openstack.org/#/c/76476/6/keystone/middleware/ec2_token.py  into the client
18:23:51 <ayoung> question is whether other services besides keystone are going to use it
18:23:53 <gyee> at one point I was told OpenStack no longer supports s3 and ec2
18:24:04 <gyee> but others continue to use them
18:24:06 <ayoung> I know Heat would love it if everyone did
18:24:10 <bknudson> the change in https://review.openstack.org/#/c/76476/6/keystone/middleware/ec2_token.py looks pretty straightforward to me
18:24:13 <bknudson> and it improves security
18:24:23 <gyee> s3 has to be used in conjunction with the s3 emulator, which no longer part of Swift
18:24:30 <ayoung> bknudson, and will break existing deployments because of that
18:24:45 <ayoung> we need to make the defaults the insecure ones for Icehouse
18:24:48 <jamielennox> i'm happy with that change to go  into icehouse
18:24:52 <ayoung> and crank it to secure for Juno
18:25:03 <bknudson> ayoung: I'm good with that plan.
18:25:18 <ayoung> gyee, no good deed goes unpunished
18:25:26 <gyee> heh
18:25:31 <jamielennox> ayoung: we haven't done that for other things, when doing certs in auth_token we just did it
18:25:40 <jamielennox> this will have far less impact than that
18:25:49 <ayoung> jamielennox, yeah, but not during feature freeze
18:25:59 <jamielennox> true
18:26:05 <ayoung> all the puppetization etc need to catch up with it
18:26:38 <gyee> ayoung, we can't pull the rug under ppl during feature freeze?!!! :)
18:26:45 <bknudson> there's no feature freeze for auth_token since it's in the client.
18:27:03 <ayoung> gyee, do you agree?  We let the change in but with the defaults such that an existing config would work, and then switch the defaults in juno?
18:27:22 <gyee> ayoung, no argument here
18:27:25 <bknudson> can we get someone to validate that the defaults work?
18:27:38 <bknudson> sorry, that an existing config will work?
18:27:50 <dolphm> the way 'verify' is determined in that patch is really confusing
18:28:02 <dolphm> it has a default in two places, and then it gets overridden...
18:28:06 <bknudson> I'm worried because there are no tests.
18:28:50 <ayoung> ++
18:28:58 <jamielennox> dolphm: that's kind of how the verify works, either it's true/false or it's the CA certs
18:29:31 <jamielennox> bknudson: ++ - i've no idea how to test it either
18:29:57 <jamielennox> (what's correct to test)
18:32:02 <dolphm> bknudson: seems like the defaults would be breaking
18:32:54 <dolphm> bknudson: for better or worse... keystone_ec2_insecure defaults to False (contrary to the existing behavior), so requests attempts verification against system CA without a cert/key ?
18:33:23 <bknudson> dolphm: it's not looking at the _url anymore to see if using ssl
18:33:30 <gyee> dolphm, yes, it will look for the system CA certs
18:33:57 <jamielennox> yes, we would want to set insecure=True to be compatible with current options
18:34:07 <dolphm> jamielennox: i'm not opposed to breaking deployments in the name of better security though...
18:34:08 <bknudson> or is SSL/not SSL handled by requests.post?
18:34:27 <dolphm> jamielennox: as long as it's a matter of setting _insecure = True to opt back into the old behavior
18:34:28 <gyee> bknudson, yes, it it handled by requests
18:34:36 <dolphm> gyee:++
18:34:41 <gyee> looking at the URL is not very reliable
18:34:55 <gyee> as start-TLS, for example, starts with http
18:35:06 <gyee> then switch over to TLS
18:35:10 <jamielennox> looking at the URL in the original doesn't do anything i think, it's just whether to use the http or https handler
18:35:32 <jamielennox> i don't *think* there is any actual extra security imposed by the HTTPSConnection
18:35:41 <bknudson> the verify=verify and cert=cert parameters are ignored if the url is http (and not https)?
18:36:51 <gyee> that's would be unawesome
18:36:59 <ayoung> marekd, bring it up here once the current conversation is done
18:37:05 <dolphm> why is this a Partial-Bug?
18:37:08 <gyee> https tunnel via http proxy won't work
18:37:22 <bknudson> dolphm: I think because it affects multiple projects.
18:38:27 <jamielennox> bknudson: yes they should be
18:39:11 <ayoung> so marekd has an issue with SAML.  Can it be brought up here?
18:39:38 <stevemar> ayoung, i think so, not much has happened in a few minutes
18:39:48 <ayoung> https://review.openstack.org/79284
18:39:51 <jamielennox> dolphm: is https://review.openstack.org/#/c/78068/ not -2ed because we want it to land in icehouse?
18:39:58 <bknudson> dolphm: since the arguments are ignored with http:// I think the behavior will not change.
18:40:01 <ayoung> I think this is a mistake, but don't want to break things for others
18:40:13 <ayoung> the SAML approach assumes that all of the identity Data is external to keystone
18:40:22 <ayoung> looking for groups in Keystone makes no sense to me
18:40:59 <bknudson> what's the reasoning that the group has to exist?
18:41:03 <bknudson> to catch invalid config?
18:41:14 <dstanek> ayoung: i thought the whole idea was to map SAML stuff into Keystone groups
18:41:20 <ayoung> marekd, what is your assumption:  that users will be defined in SAML but groups will be in Keystone?
18:41:28 <dolphm> bknudson: yes
18:41:29 <jamielennox> bknudson: the default will change because it will default to verify=True for https connections and so will do CA verification
18:41:32 <ayoung> dstanek, but I don't think that makes sense
18:41:43 <ayoung> dstanek, groups are per domain
18:41:44 <dolphm> ayoung: you're getting ahead of the current approach
18:41:50 <marekd> ayoung: yes, groups should be configured/created prior to federation configuration...
18:42:08 <marekd> ayoung: and not regular users...ephemeral-like users.
18:42:28 <dolphm> jamielennox: what if you do http:// + verify=True ?
18:42:35 <jamielennox> dolphm: no change
18:42:52 <jamielennox> dolphm: it should be ignored
18:43:10 <dolphm> jamielennox: cool
18:43:38 <ayoung> marekd, and "ephemeral users" is a mistake....ugh.  Not sure we want to reinforce this.  I'm afraid we'll be stuck with something broken we have to live with.  But I guess the existing SAML approach is already there.
18:44:01 <marekd> ayoung: it in the master.
18:44:33 <ayoung> But yeah...and I was sorely tempted to -2 it for this very reason.  But I am not he-who-should-not-be-named-in-irc
18:44:46 <marekd> ayoung: i said ephemeral-like users...something, a set of roles that can access some domains/projects as long as the token is valid and later disappears.
18:44:46 <ayoung> We need to fix in J1
18:44:54 * dolphm unblocked the ec2_token patch and targeted bug at RC1
18:45:09 <dolphm> i'd +2 except for the commit message thing
18:45:25 <marekd> ayoung: you wanted to -2 what? federation patches/
18:45:27 <marekd> ?
18:45:44 <ayoung> marekd, yeah....I wanted to redo the token creation pipeline first
18:46:01 <ayoung> but couldn't get to it in time.
18:46:11 <gyee> ayoung, marekd, the questions is if users are managed outside of Keystone, what's the use of shadowing them in Keystone?
18:46:14 <dolphm> ayoung: btw, please don't reimplement paste - just take advantage of wsgi
18:46:20 <gyee> for metering & billing, tracking?
18:46:37 <marekd> gyee: you dont shadow any user information...
18:46:46 <ayoung> dolphm, for the token pipeline?
18:46:50 <dolphm> ayoung: yes
18:46:56 <dolphm> ayoung: i think you filed a wishlist bug to that effect
18:47:01 <gyee> if I am reading ayoung correctly, he wants to shadow them in Keystone
18:47:09 <dolphm> gyee: i haven't gotten a great answer to that question either
18:47:13 <marekd> gyee: he wants to remove identity :D
18:47:24 <dolphm> marekd: me too, but not today!
18:47:30 <gyee> haha
18:47:56 <ayoung> dolphm, I think I alluded to "something like paste if paste can't suit our needs"  or something appropriatlley vague.  I suspect one of the more pythonic members of our community will have the right solution, not I.
18:48:10 <marekd> gyee: we don't shadow any user information...the only 'shadowing' if we can call it that way is groups/roles configuration
18:48:19 <dolphm> ayoung: paste is the answer you're looking for ;)
18:48:37 <dolphm> ayoung: more specifically wsgi in general, but paste makes wsgi sufficiently easy
18:48:56 <marekd> gyee: basically RuleProcessor, courtesy of stevemar, maps SAML2 assertion into set of group id
18:48:59 <marekd> ids
18:49:04 <gyee> marekd, that's how it is usually done
18:49:15 <gyee> Keystone manage the "personas"
18:49:26 <ayoung> dolphm, It may well be.  I think can see how it will solve the token-pipeline configuration
18:49:32 <gyee> personas are pre-determined
18:50:09 <dolphm> #topic open discussion
18:50:12 <marekd> gyee: agreed. So in this use-case, there is not new User record
18:50:20 <marekd> gyee: a group may be.
18:50:21 <ayoung> gyee, that sounds a lot like "define the users in SAML and the groups in Keystone" to me
18:50:27 <jamielennox> dolphm: https://review.openstack.org/#/c/78068/ ?
18:50:43 <gyee> ayoung, right, defining groups in kesytone
18:51:00 <marekd> gyee: but even if we skip groups, and map directly from saml2 to role we still sometimes need create roles dedicated for federated users...
18:51:05 <dolphm> jamielennox: are you asking for a review or with regard to blocking until juno?
18:51:09 <marekd> gyee: to me it again smells like 'shadowing'
18:51:12 <ayoung> gyee, we can do that now  with the mapping layer, but we could make a persona or group a first class entity in that layer
18:51:25 <jamielennox> dolphm: regarding whether it's blocked, you did a review the other day without a  -2
18:51:35 <dolphm> jamielennox: intentional :)
18:51:44 <jamielennox> dolphm: if it's blocked i'll probably abandon and do it with pecan when that happens
18:51:47 <gyee> marekd, you don't want to directly assign user roles, just ask your auditing ppl
18:52:07 <jamielennox> dolphm: it got bigger and uglier than i though it would
18:52:11 <marekd> saml2->roles was ayoung's idea
18:52:19 <dolphm> jamielennox: i haven't given it a thorough review, but don't see a reason for it to be blocked
18:52:23 <gyee> it will be a nightmare to do auditing/forensics
18:52:23 <bknudson> jamielennox: so the links in all the elements are broken?
18:52:54 <jamielennox> bknudson: it means that if you don't put admin_host_url in config you get links that are like http://localhost/blah
18:53:05 <ayoung> gyee, not if we keep the userid mapping clean.
18:53:08 <dolphm> jamielennox: i'm just not sure how to triage the bug, or if it should be targeted at RC1
18:53:43 <gyee> ayoung, you don't really need user id
18:53:45 <jamielennox> bknudson: the patch defaults that to using whatever host you connected to it with so if you requests.get('http://keystone/v3/users') links will be relative to http://keystone/v3
18:53:56 <dolphm> jamielennox: after all, you just have to provide configuration for it work as expected, right?
18:53:57 <ayoung> gyee, all the other projects need userid
18:54:02 <ayoung> so, yes we do
18:54:11 <marekd> ayoung: ++
18:54:13 <gyee> in SAML land, a user is unique identified by a collection of attributes
18:54:24 <jamielennox> dtroyer and i have discussed in the past that it's unset by default in real deployments and no one notices because it's only ued by links and discovery
18:54:25 <ayoung> gyee, and a userid is the shortcut
18:54:30 <marekd> gyee: but in the keystone world by unique string...
18:54:34 <bknudson> jamielennox: what do you mean? a relative link?
18:54:46 <bknudson> like /v3/users ?
18:54:48 <ayoung> gyee, even in SAML, each user has a unique identifier
18:54:59 <ayoung> lets not quibble, I have no patience for it today
18:55:03 <jamielennox> bknudson: sorry shouldn't have used relative
18:55:13 <dolphm> jamielennox: i thought you were getting the host url out of the wsgi env, not using relative urls?
18:55:19 <fmarco76> gyee: actually in SAML user are identified by an ID, gnerally the EPTID or EPPN
18:55:27 <dwaite> seems to me there are two approaches - expect the IDP to send roles which are defined by keystone, or the IDP will send user roles over and keystone will interpret them and map them into its own role concept.
18:55:31 <marekd> ayoung: anything else regarding federation you wanted to discuss now?
18:55:31 <jamielennox> if you connect to url 'http://keystone:5000/v3/users' then request.host_url is http://keystone:5000
18:55:47 <ayoung> marekd, nope..it can all wait to Atlanta
18:55:50 <dolphm> dwaite: \o/ long time no see
18:55:57 <dwaite> hi dolphm!
18:56:02 <jamielennox> bknudson: so i want to default the public and admin urls to the request.host_url
18:56:16 <bknudson> jamielennox: that sounds like the right way to do it.
18:56:21 <jamielennox> rather than http://localhost:%(public_port) which it is now
18:56:35 <bknudson> jamielennox: but you can override with  http://localhost:%(public_port) ?
18:56:40 <jamielennox> so it shouldn't change anything for deployments
18:56:40 <dolphm> jamielennox: which could be something like "http://hostname:port/path" -- correct?
18:56:41 <jamielennox> bknudson: ++
18:56:46 <bknudson> jamielennox: that's great.
18:56:59 <gyee> more federation fun in Atlanta I guess
18:57:02 <jamielennox> dolphm: right it you have a /path you will still need to set the config option
18:57:03 <fmarco76> ayoung, just a question, do you have a plan to provide token after federate authentication as post to an external service?
18:57:05 <bknudson> jamielennox: IMO this is fixing a bug.
18:57:07 <stevemar> gyee, for sure
18:57:08 <dolphm> gyee: of course!
18:57:17 <gyee> I think we really need to get that user_id question straighten out
18:57:23 <gyee> what is it used for?
18:57:28 <dolphm> jamielennox: oh - i assumed /path would be included
18:57:31 <jamielennox> dolphm: i don't know how to fix that without some bigger rearchitecting
18:57:35 <stevemar> gyee, auditing mostly
18:57:37 <dolphm> jamielennox: fair enough
18:57:38 <bknudson> jamielennox: why can't we get the path?
18:57:54 <jamielennox> bknudson: you can't do it as a drop in replacement at least
18:58:12 <jamielennox> all the link rendering is done based on the config option
18:58:32 <marekd> ayoung: allrighty, i am headong home. should be online again soon.
18:58:37 <marekd> heading*
18:58:48 <jamielennox> if we put some effort in in Juno we can get the whole request url but everything build up there own path relative to a base
18:59:23 <gyee> dolphm, are you accepting design session proposals now?
18:59:36 <dolphm> gyee: since friday http://summit.openstack.org/
18:59:37 <jamielennox> rephrase: all the controllers currently builds the URLs assuming the base up
18:59:53 * dolphm < 1 min
18:59:55 <marekd|away> dolphm: until?
18:59:56 <jamielennox> we would have to change all that
19:00:08 <dolphm> marekd|away: ... late april
19:00:13 <marekd|away> dolphm: ok!
19:00:24 <dolphm> marekd|away: april 19? april 29? i should have written the date down, but i'll give a heads up when we get close
19:00:31 <dolphm> #endmeeting