18:01:00 <dolphm> #startmeeting keystone 18:01:01 <openstack> Meeting started Tue Mar 18 18:01:00 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:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:01:05 <openstack> The meeting name has been set to 'keystone' 18:01:10 * ayoung here 18:01:12 <dolphm> #topic Reminder: Design summit session proposals open until April 20th 18:01:17 <dolphm> #link http://summit.openstack.org/ 18:01:26 <dolphm> this is for the *design* summit, not the conference 18:01:48 <ayoung> dolphm, I assume we are already at the point where we can start merging the proposals 18:02:00 <bknudson> lots of keystone topics already 18:02:08 <ayoung> 18 18:02:10 <dolphm> ayoung: i'd like to wait until after the deadline to accept/reject/merge anything so it's clear what we're working with 18:02:16 <stevemar> how many slots do we have? 18:02:19 <ayoung> assuming I can count, which is a big assumption 18:02:22 <ayoung> stevemar, 3 18:02:24 <dolphm> ayoung: otherwise it seems unfair to start shuffling things too early 18:02:24 <ayoung> :) 18:02:39 <ayoung> we had about 8 last time 18:02:45 <dolphm> stevemar: fewer than last time, as we're donating some time to a new cross-project track 18:02:53 <dolphm> stevemar: i don't think i have a final number yet 18:02:54 <ayoung> one days worth, spread over multiple days 18:03:15 <ayoung> our client stuff maybe can be merged with the Oslo common client 18:03:16 <stevemar> boooo... 18:03:37 <ayoung> and then we can make sure anything that is a server side topic at least addresses client side for that same topic 18:03:47 <dolphm> and as a reminder for what the *design* summit is all about if you'd like to propose something: this is for moderated collaborative discussions, not for powerpointy lectures :) 18:04:18 <stevemar> down with ppts 18:04:22 <gyee> and with prototype demos 18:04:24 <dolphm> i believe the deadline for proposing powerpointy lectures for the conference has passed 18:04:45 <dolphm> gyee: i'd submit that demos are best saved for lightning talks 18:04:52 <dolphm> which you don't need to register for in advance 18:05:02 <gyee> sounds reasonable 18:05:03 <ayoung> really, the week will be spent doing collaborative development in the dev lounge. the rest is just distractions 18:05:19 <dolphm> gyee: plus if your demo fails, you can sit down and just try again the next day :P 18:05:35 <gyee> dolphm, we'll do live debugging 18:05:43 <ayoung> Feature freeze for Keystone will be Juno 2. If you want a big feature in to Juno, you need to have it started before the summit 18:05:57 <ayoung> right morganfainberg ? 18:06:15 * ayoung thinking ephemeral tokens 18:06:30 <henrynash> ayoung: oh, yes please 18:06:34 <dolphm> the bigger the feature, the earlier the better 18:06:35 <gyee> that will be a *fun* discussion 18:06:38 <marekd> ayoung: and J-2 is happening when? 18:06:48 <dolphm> marekd: probably july, there's no schedule yet 18:07:03 <lbragstad> well find out the schedule at the summit right? 18:07:07 <lbragstad> or shortly after? 18:07:14 <bknudson> we'll need people doing reviews early, too, then 18:07:44 <dolphm> bknudson: we could do a very early feature proposal freeze, rather than feature freeze 18:08:24 <dolphm> this might be a conversation best saved for the summit, but it's good to give everyone an early warning here 18:08:32 <dolphm> #topic RC1-blocking issues 18:08:50 <dolphm> i wanted to run through what's on our plate for shipping an RC1 18:09:11 <dolphm> my goal is to have fixes for all RC1 issues at least in review by friday 18:09:39 <dolphm> #link https://launchpad.net/keystone/+milestone/icehouse-rc1 18:09:42 <dolphm> so let's run through the list 18:09:43 <morganfainberg> o/ here sorry 18:09:49 <dolphm> Bug 1291157: idp deletion should trigger token revocation 18:09:59 <dolphm> (no linky bot?) 18:10:01 <dolphm> #link https://bugs.launchpad.net/keystone/+bug/1291157 18:10:06 <morganfainberg> ayoung, ++ at least work on it 18:10:13 <morganfainberg> dolphm, bot has been dead for week+ 18:10:22 <dolphm> boo 18:10:49 <dolphm> marekd: ayoung: stevemar: i'm comfortable shipping icehouse with this as a known issue, but i'd be happy to see a fix if anyone wants to pursue 18:11:27 <dolphm> i'm worried we're going to get into api conversations, and it's far too late for that 18:11:33 <ayoung> dolphm, I don't want to do list_tokens_for_idp but doing it in the revocation events makes sense 18:11:36 <bknudson> is it going to require a schema change? 18:11:57 <dstanek> stevemar: does a revocation need to happen on ipd update too? 18:12:13 <dolphm> ayoung: i think it'd just be a matter of adding "OS-FEDERATION:identity_provider" 18:12:16 <stevemar> dstanek, it probably should 18:12:20 <ayoung> bknudson, for revocation events, it could probably be done with the domain ids, assuming they are valid. otherwise, yeah, I'd need to add an IOdP column 18:12:28 <dolphm> ... as an attribute of a revocation event 18:12:49 <dolphm> stevemar: dstanek: why? there's not too much to update, is there? 18:13:03 <ayoung> dolphm, what did we settle on as the relationship between IdPs and (identity) domains? 18:13:08 <dstanek> dolphm: i have to reasoning...it was mentioned in the issue 18:13:20 <dolphm> ayoung: no explicit relationship in icehouse 18:13:24 <stevemar> dolphm, if we use revoke instead of delete, wouldn't we then create a dependency on an optional extension? 18:13:25 <marekd> dolphm: stevemar dstanek actually you can only disable idp when you PATCH it 18:13:38 <stevemar> thanks marekd 18:13:40 <marekd> https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3-os-federation-ext.md#update-identity-provider-patch-os-federationidentity_providersidp_id 18:13:46 <ayoung> dolphm, do userids from Federation have a domain_id associated with them in icehouse? 18:13:55 <ayoung> stevemar, nope 18:14:18 <ayoung> stevemar, the event API insulates one from the other 18:14:23 <dolphm> stevemar: yes, but i'd say it's acceptable for extensions to depend on one another 18:14:35 <morganfainberg> dolphm, ++ 18:14:35 <ayoung> ah, you mean an implicit dep 18:15:05 <morganfainberg> ayoung, yeah, but even if it was an explicit dep, it wouldn't be horrible (though i think the code doesn't support it) 18:15:23 <ayoung> for now, I would say that an IdP needs to have some sort of domain id. Then we can treat it like a domain disable event 18:15:35 <ayoung> plus won't everything break if there is no domain_id? 18:15:43 <dolphm> ayoung: that's a viable solution, but not really for icehouse 18:15:59 <dolphm> ayoung: there's no domain_id now 18:16:01 <ayoung> dolphm, doesn't any user in Federation have to alreayd live in the Identity backend? 18:16:05 <dolphm> ayoung: no 18:16:13 <ayoung> just groups? 18:16:15 <marekd> ayoung: nooo? 18:16:18 <dolphm> ayoung: they "live" in the remote IdP are ephemeral in keystone 18:16:19 <marekd> ayoung: just groups 18:16:25 <dolphm> ayoung: authorization lives in keystone 18:16:44 <ayoung> make IdP ID == domain_id then 18:16:55 <dolphm> ayoung: that's the conversation we can have at the summit 18:16:59 <ayoung> put it in the tokens and get a disable domain event 18:17:06 <ayoung> OK 18:17:45 <dolphm> is anyone completely opposed to waiting until juno to address this? 18:18:10 <morganfainberg> dolphm, i'm actually more for addressing this in juno 18:18:19 <henrynash> ++ 18:18:22 <dolphm> morganfainberg: i am too 18:18:22 <bknudson> it's scary leaving this bug... there's no workaround? 18:18:35 <morganfainberg> dolphm, vs squeezing it in under the wire (unless we have a very very good reason not to) 18:18:45 <morganfainberg> bknudson, so is it just that we delete an idp and tokens aren't revoked? 18:19:01 <dolphm> bknudson: not a simple one 18:19:06 <bknudson> morganfainberg: yes, you delete or disable an idp and tokens aren't revoked 18:19:14 <morganfainberg> because, as aweful as it is we could do the same thing we do for oauth 18:19:31 <marekd> morganfainberg: and what's happening there? 18:19:35 <morganfainberg> oh nvm we can't 18:19:38 <morganfainberg> we'd need a new index. 18:19:43 <gyee> bknudson, disable a group would delete the tokens right? 18:19:46 <morganfainberg> we're not tracking by user. 18:19:56 <morganfainberg> gyee, which groups 18:19:58 <bknudson> gyee: right, disable a group or a user... or a domain 18:20:02 <gyee> assuming you keep track of Ide=group mappings 18:20:12 <marekd> gyee: we dont 18:20:16 <gyee> IdP user to group mapping I mean 18:20:47 <bknudson> I guess we'd know what groups are referenced by the mapping 18:20:50 <dolphm> gyee: we don't really track that, per se 18:20:52 <morganfainberg> hm. 18:21:01 <dolphm> bknudson: the mapping is mutable 18:21:05 <morganfainberg> can we add the IDP id to the token? 18:21:14 <dolphm> morganfainberg: it's already there 18:21:16 <bknudson> changing the mapping should probably invalidate tokens, too 18:21:20 <morganfainberg> can we make auth_token ask keystone if an IDP is valid on validating the idp? 18:21:21 <dolphm> morganfainberg: and i suspect what the revocation event should be based on 18:21:28 <marekd> morganfainberg: and later go through all the tokens and match them? 18:21:40 <dolphm> morganfainberg: token -> user -> OS-FEDERATION -> identity_provider -> id 18:21:52 <morganfainberg> or provide a list of active IDP IDs to auth_token? 18:21:56 <morganfainberg> internal to keystone this is easy 18:22:05 <morganfainberg> is IDP valid, nope? reject 18:22:11 <ayoung> loss of IdP is catastrophic, and revoke all tokens 18:22:22 <dolphm> ayoung: lol that's not a bad approach 18:22:35 <morganfainberg> ayoung, dolphm, for I i think we could expose a list of valid IDP ids 18:22:54 <dolphm> morganfainberg: GET /v3/OS-FEDERATION/identity_providers 18:23:05 <morganfainberg> dolphm, yeah 18:23:06 <morganfainberg> dolphm, make auth_token middleware track that 18:23:18 <morganfainberg> dolphm, just check if token_id is in that list. 18:23:35 <morganfainberg> it's a low risk / easy solution 18:23:45 <morganfainberg> and internal to keystone we can check IDP is valid for validation calls 18:23:50 <morganfainberg> if we don't already 18:23:55 <ayoung> dolphm, it is the sane approach for Icehouse 18:24:04 <dolphm> morganfainberg: ayoung: ++ 18:24:09 <dolphm> i'll add keystoneclient to that bug then 18:24:12 <morganfainberg> k 18:24:13 <gyee> morganfainberg, probably a separate middleware sitting behind auth_token 18:24:24 <morganfainberg> gyee, i don't think we want to do that. 18:24:26 <ayoung> morganfainberg, I'm unwilling to do that 18:24:35 <morganfainberg> gyee, getting everyone to load another middleware is bad 18:24:50 <ayoung> I thik that a list of valid IdPs as part of the check is getting into the revoke events space 18:24:50 <morganfainberg> this needs to be in auth_token 18:24:59 <ayoung> I'd rather just add it to revoke events 18:25:30 <dolphm> revised https://bugs.launchpad.net/python-keystoneclient/+bug/1291157 18:25:35 <morganfainberg> ayoung, but we don't have full revocation events now. 18:25:36 <morganfainberg> ayoung, and we need a solution for I 18:25:41 <gyee> morganfainberg, middleware is alreay overloaded, but I like ayoung's idea of having it in revoke events 18:25:51 <morganfainberg> long term i want it in revocation events 18:26:02 <ayoung> morganfainberg, we have revocation events, and I have a fledgling patch for the client side 18:26:38 <morganfainberg> ayoung, but we've stated revocation events are expirimental 18:26:38 <gyee> auth_token middleware refactoring is overdue :) 18:26:51 <dolphm> gyee: it's happening, slowly 18:26:52 <ayoung> morganfainberg, so is Federation in my book 18:27:04 <dolphm> so we need to move on, we have more bugs to discuss :) 18:27:07 <dolphm> Bug 1255321: v3 token requests result in 500 error when run in apache 18:27:08 <morganfainberg> ayoung, then we need to mark it in the docs 18:27:10 <dolphm> Bug 1291423: revocation events sync slows responses to all authenticated calls 18:27:13 <dolphm> Bug 1291047: Keystone returns traceback for db backend 18:27:20 <dolphm> #link https://bugs.launchpad.net/bugs/1255321 18:27:22 <dstanek> gyee: yes, i was looking at it yesterday and was very tempted to start hacking it up 18:27:23 <dolphm> #link https://bugs.launchpad.net/bugs/1291423 18:27:28 <dolphm> #link https://bugs.launchpad.net/bugs/1291047 18:27:35 <ayoung> https://review.openstack.org/#/c/81166/2 18:27:35 <morganfainberg> ayoung, will discuss more in -dev after meeting 18:27:43 <dolphm> ayoung: all three of these are assigned to you -- care to share the burden with anyone else? 18:27:56 <ayoung> dolphm, looking 18:28:22 <ayoung> dolphm, I'd be happy to hand them off 18:28:32 <ayoung> I'll keep https://bugs.launchpad.net/keystone/+bug/1291423 18:28:38 <dolphm> anyone want to volunteer to pick any of these up? 18:28:46 <ayoung> which is revocation events, and I think we already have a better approach 18:28:57 <gyee> the 500 error one is interesting, compressed token should help 18:29:23 <ayoung> gyee, yeah...but I don't think I can slip compressed tokens into the icehouse release 18:29:27 <dolphm> "Keystone returns traceback for db backend" is a regression that should be an easy fix if we can figure out where things went wrong 18:30:12 <jamielennox> dolphm: yea, that shouldn't happen with up to date requirements, it was initially filed on bugzilla and i put the same comment there but no response yet 18:30:14 <dolphm> ayoung: so should https://bugs.launchpad.net/keystone/+bug/1255321 be untargeted from rc1? 18:30:30 <ayoung> dolphm, well...maybe 18:30:33 <dolphm> jamielennox: have you tried to reproduce? 18:30:40 <ayoung> dolphm, I have a python33 issue, but assuming I solve that 18:30:49 <ayoung> the path needs to be clear to enabling compressed tokens on the server 18:30:57 <ayoung> I think that means a new config value 18:31:02 <gyee> ayoung, recommend endpoint filtering to reduce service catalog size, or nocatalog on token request 18:31:04 <ayoung> or, maybe a new token provider 18:31:16 <ayoung> gyee, suspect that none of that is going to make adifference 18:31:21 <jamielennox> dolphm: you'd have to get eventlet context switching at just the right time, i guess you could force that - but no 18:31:51 <gyee> its the service catalog that super sized the PKI token 18:32:09 <ayoung> dolphm, so, assuming I get compressed tokens working, I would probably make the server side be an alternative token provider, that looks just like the PKi provider, but that generates compressed tokens instead 18:32:09 <bknudson> users are going to need the service catalog 18:32:21 <ayoung> and then you would configure that in the config file as the token provider 18:32:40 <ayoung> if that is acceptable, (and I figure out the python33 issue) we can have an RC1 fix 18:32:42 <dolphm> gyee: nocatalog isn't a viable option for everyone 18:32:42 <gyee> bknudson, not the whole shebang, just the services user is interested in 18:32:46 <jamielennox> ayoung: i'm still not sure why this would need to be a provider rather than just a wrap/unwrap middleware option 18:32:58 <dolphm> jamielennox: ++ 18:33:27 <ayoung> jamielennox, OK...so we don't assume that the entire openstack deployment upgrades at once 18:33:35 <gyee> is there really a use case where the whole thing is needed? 18:33:36 <ayoung> if it doesn't we need to keep from breaking existing clients 18:33:51 <gyee> beside horizon, where they can get the catalog on a separate API 18:33:59 <ayoung> gyee, doesn't matter 18:34:08 <morganfainberg> can we make it a ?compressed=true 18:34:12 <morganfainberg> ? 18:34:13 <ayoung> so much code is written around the service catalog, we can't break that 18:34:19 <ayoung> morganfainberg, no 18:34:21 <jamielennox> ayoung: sure that just means you ahve to roll out the client updates before you can switch over the server - but that would be the same as a new provider 18:34:33 <jamielennox> morganfainberg: no, i don't think it should be optional at request time 18:34:35 <morganfainberg> ayoung, or we make it part of the accepts header 18:34:41 <ayoung> morganfainberg, it needs to be a different token format, and then auth token neeeds to handle both 18:34:49 <morganfainberg> ayoung, hm. 18:34:50 <dolphm> morganfainberg: i don't think it should be optional either -- it should happen transparently for end users 18:35:06 <morganfainberg> dolphm, oh right derp. sorry was thinking 18:35:08 <morganfainberg> dolphm, auth_token making the request 18:35:09 <ayoung> dolphm, defaults to uncompressed for Icehouse, compressed for juno 18:35:10 <morganfainberg> nope. 18:35:35 <ayoung> MII still needs to work 18:35:54 <ayoung> rem,ember, there is Java code out there that talks to openstack....we can't brak this 18:35:57 <ayoung> break 18:36:09 <dolphm> alright, so untargeted Bug 1255321 "v3 token requests result in 500 error when run in apache" from RC1 18:36:12 <ayoung> but we can make the mechanism possible, and publish it 18:36:23 <ayoung> dolphm, wrong call 18:36:29 <ayoung> the right call is to make it optional 18:36:44 <ayoung> just don't try to drop all the baggage at the same time 18:37:29 <dolphm> ayoung: you're advocating for compressed tokens to be a service-side feature, in which case it's too late for icehouse 18:37:39 <dolphm> ... correct me if i'm wrong 18:37:39 <ayoung> Fair enough 18:37:40 <jamielennox> ayoung: i don't disagree with the client needing updating and MII etc. My point is that as the logic behind PKI and compressed PKI tokens is exactly the same other than that last compress step it doesn't need to be a new 'provider' 18:38:08 <ayoung> jamielennox, the problem is that the old clients can't deal with the new format 18:38:17 <ayoung> its not just "the final step" 18:38:28 <dolphm> jamielennox: that's my intuition as well, but i haven't tried to make it happen to judge the actual required complexity :) 18:38:35 <jamielennox> ayoung: sure 18:38:37 <bknudson> ayoung: auth_token middleware? why do clients care in general? 18:38:49 <dolphm> bknudson: because auth_token has to unpack tokens to validate them offline 18:38:55 <dolphm> bknudson: clients == auth_token here 18:39:02 <ayoung> and compression is part of the unpacking 18:39:06 <jamielennox> dolphm: me neither, but i consider the provider to be the controller and compressed or not should be a view of it 18:39:11 <bknudson> right, just making sure it wasn't all clients that care. 18:39:23 <ayoung> bknudson, it will be...in Juno 18:39:50 <dolphm> bknudson: exactly, actual end users won't/shouldn't care 18:40:05 <ayoung> dolphm, OK, so I'll continue on with the compressed token work, but if anyone wants to use it, they will need to run an unsupported, out of tree token provider 18:40:10 <dolphm> alright then, so the other bug up for grabs was https://bugs.launchpad.net/keystone/+bug/1291047 18:40:26 <ayoung> we'll get the token provider into Juno 1, and backport if there is sufficient demand 18:40:27 <dolphm> jamielennox: do you think this should be incomplete? 18:40:44 <morganfainberg> this is a tough one to duplicate imo 18:41:10 <jamielennox> dolphm: i'm wondering from before if I could reproduce with some well place sleeps and a decent load 18:41:23 <morganfainberg> jamielennox, adding in sleep(0)'s? 18:41:25 <dolphm> it's not using SecurityError somehow, is it? and then the behavior is dependent on debug=true? 18:41:39 <jamielennox> morganfainberg: right - something that made eventlet switch to a new thread 18:41:42 <morganfainberg> jamielennox, it does force context switches 18:42:14 <jamielennox> morganfainberg: yea, i *think* you can do it with a call to eventlet as well but i dont know how 18:42:14 <dstanek> how does the context switch cause this error? 18:42:25 <jamielennox> i've tried to ignore eventlet as much as possible 18:42:47 * dolphm is confused between this bug and another one with a really similar title... 18:42:47 <morganfainberg> dstanek, when eventlet switches it's execution point, thread swap, it looks like it's clearing the exc. stack? 18:42:49 <jamielennox> dstanek: see linked eventlet bug: https://bitbucket.org/eventlet/eventlet/issue/118/exceptions-are-cleared-during 18:43:10 <morganfainberg> it's a fairly standard coroutine-like-code hell problem 18:43:35 <morganfainberg> thankfully eventlet has been mostly decent (lately) about not introducing/causing these 18:43:42 <jamielennox> but it shouldn't happen with new greenlet and global-requirements.txt has sufficient greenlet in it 18:44:05 <jamielennox> (from my understanding) 18:44:09 <morganfainberg> dolphm, how is this a security issue? 18:44:40 <dolphm> morganfainberg: leaking internal details unnecessarily 18:44:50 <morganfainberg> dolphm, ah ok phew, i thought i was missing something else 18:45:05 <morganfainberg> dolphm, i was concerned you were seeing a rollback issue causing a gap 18:45:22 <dolphm> (this is marked as a private security issue) but i marked it as a dupe of the public bug https://bugs.launchpad.net/keystone/+bug/1293113 18:45:43 <dolphm> it does actually vary a bit from https://bugs.launchpad.net/keystone/+bug/1291047 18:46:31 <bknudson> seems like keystone should trap all exceptions and return a generic 500 error 18:46:43 <morganfainberg> bknudson, that was what i was thinking would solve this 18:46:46 <bknudson> unless debug=True... but even then doesn't seem necessary if it's in the log 18:47:19 <morganfainberg> this just seems like we should tighten up what we pass back, make the returns much simpler 18:47:30 <dolphm> bknudson: so basically UnexpectedError should extend SecurityError ? 18:47:35 <morganfainberg> erm errors to the client 18:47:50 <bknudson> dolphm: that sounds safer to me. 18:47:50 <ayoung> dolphm, ++ 18:48:05 <morganfainberg> dolphm, ++ 18:48:26 <morganfainberg> dolphm, I'll take this one if you need. 18:48:31 <dolphm> morganfainberg: sure 18:48:36 <morganfainberg> dolphm, and chase down any external deps 18:48:50 <morganfainberg> hopefully it'll be minimal 18:49:26 <dolphm> morganfainberg: it looks like the only gotcha is that UnexpectedError currently expects %(exception)s in the string formatter 18:49:35 <morganfainberg> dolphm, yeah 18:49:44 <morganfainberg> dolphm, shouldn't be too bad (might require test massaging) 18:50:05 <morganfainberg> i'll link it against both the security bug and the regression one 18:50:39 <morganfainberg> oh wait no the security one is marked dup 18:50:45 <morganfainberg> haha don't need to. 18:50:46 <morganfainberg> cool 18:50:56 <dolphm> henrynash: o/ 18:51:02 <henrynash> hi 18:51:04 <dolphm> #link https://bugs.launchpad.net/keystone/+bug/1287219 18:51:17 <dolphm> Bug 1287219: scope of domain admin too broad in v3 policy sample 18:51:19 <henrynash> so fix merged 18:51:21 <ayoung> dolphm, https://review.openstack.org/#/c/81235/ should go in. YorikSar needsd to open a bug to describe the problem he is fixing, but I've been testing the code. It solves some issues that I was seeing, but had not yet been able to reproduce with a server side test 18:51:29 <dolphm> henrynash: you marked this as fixed, but there's no link to a fix as far as i can see? 18:51:43 <henrynash> hmm…ok let me fix thaat :-) 18:52:09 <morganfainberg> dolphm, the code merged, https://review.openstack.org/#/c/79897/ https://review.openstack.org/#/c/80769/ 18:52:10 <dolphm> ayoung: open a bug and track it against RC1 18:52:14 <ayoung> dolphm, ++ 18:52:14 <dolphm> YorikSar: ^ 18:52:35 <morganfainberg> sorry #link https://review.openstack.org/#/c/80769/ 18:52:43 <morganfainberg> #link https://review.openstack.org/#/c/79897/ 18:52:45 <YorikSar> dolphm, ayoung: ok 18:53:12 <dolphm> henrynash: morganfainberg: thanks 18:53:23 <dolphm> henrynash: must have been a fluke with the bot 18:53:32 <bknudson> can't trust bots 18:53:32 <dolphm> henrynash: i linked the to the review in the bug 18:53:42 <henrynash> dolphm: thx 18:53:57 <dolphm> and the last one... 18:54:04 <dolphm> #link https://bugs.launchpad.net/keystone/+bug/1273867 18:54:06 <henrynash> I do have one question on https://review.openstack.org/#/c/80769/, see last item of the agenda (cover it then) 18:54:11 <dolphm> Keystone API v3 lists disabled endpoints and services in catalog 18:54:23 <bknudson> dolphm: it's partially fixed... disabled endpoints 18:54:24 <dolphm> henrynash: ack 18:54:27 <bknudson> but not disabled services 18:54:46 <dolphm> bknudson: and i think endpoints are the more important piece, but do you think you'll have time to do the same for services? 18:54:49 <dolphm> (this week) 18:55:10 <bknudson> I can't promise I'd get services done this week 18:55:14 <bknudson> it's crazy around here. 18:55:29 <dolphm> bknudson: this is another one that i'm comfortable shipping with as a known issue, given that we have a solid workaround (disable all the endpoints for your "disabled" services prior to upgrading) 18:55:47 <bknudson> close the bug and open a new one? 18:55:53 <ayoung> ++ 18:55:54 <bknudson> a new one for services? 18:55:55 <morganfainberg> ++ 18:56:05 <morganfainberg> that sounds very reasonable 18:56:28 <gyee> and disable a region? 18:56:47 <dolphm> gyee: /v3/regions has no impact on the catalog, yet 18:57:00 <dstanek> bknudson: so endpoints is complete and we just have to implement services for this one? 18:57:04 <dolphm> gyee: i think that expectation will come, but not yet 18:57:05 <dolphm> dstanek: yes 18:57:05 <ayoung> gyee, separate bug for that too, i'd wager 18:57:22 <gyee> yeah 18:57:23 <dolphm> bknudson: it's going to be a parallel fix -- probably sharing a lot of code 18:57:24 <bknudson> dstanek: yes, disabled endpoints are not in the catalog anymore... but disabling a service has no effect 18:57:26 <dolphm> dstanek: ^ 18:57:55 <bknudson> for services, I don't think there's a tempest test that doesn't work like there was for endpoints 18:58:13 <dstanek> if you create a new bug you can assign it to me and can work on it 18:58:19 <dolphm> bknudson: good to know 18:58:23 <dolphm> dstanek: will do, thanks! 18:58:25 <dolphm> #topic Should domain_id be immutable by default? 18:58:29 <dolphm> (quickly) 18:58:29 <henrynash> so https://review.openstack.org/#/c/80769/ provides option to made domain_id immutable... 18:58:42 <henrynash> question is, should we really make it immutable by default 18:58:49 <henrynash> would change existing fucntionaliy 18:58:50 <dolphm> henrynash: are you asking about icehouse or juno? 18:58:54 <morganfainberg> dolphm, icehouse 18:58:56 <henrynash> icehouse 18:58:58 <dstanek> bknudson: is tempest ensuring that disabled endpoints don't appear? 18:59:21 <morganfainberg> i'm concerned about a security implication (talked w/ henrynash) due to the ability that you could move a user you control into a domain you don't control 18:59:26 <bknudson> dstanek: no, it was trying to set endpoint disabled to an invalid boolean value (by our XML translator) 18:59:45 <morganfainberg> and i'm not 100% sure we are guarding against admin in domain A with user moved to domain B clearly 18:59:57 <bknudson> dstanek: as far as I know there are no tempest tests for getting a catalog with disabled endpoints... otherwise we wouldn't have the bug 18:59:58 <jamielennox> henrynash: what's the logic behind it being mutable in the first place? 19:00:09 <dolphm> morganfainberg: ack; i'm not opposed to making it immutable in icehouse for that reason (it's a security improvement), and i'm very much in favor of making it immutable *by* juno 19:00:11 <morganfainberg> jamielennox, it shouldn't be. we just didn't make it immutible 19:00:13 <jamielennox> it wouldn't seem to work with the way our SQL/LDAP providers work 19:00:15 <henrynash> jamielennox: lsoat in the midst of time 19:00:31 <dolphm> jamielennox: there's not any ( morganfainberg++ ) 19:00:39 <morganfainberg> dolphm, in juno for sure immutible 19:00:45 <morganfainberg> i'd prefer to invert the option for I 19:00:54 <dolphm> henrynash: put the patch up to change the default and we'll vote on it :) 19:00:54 <morganfainberg> if someone _needs_ that, make a less secure deployment 19:01:04 <dolphm> we're over time 19:01:05 <dolphm> #endmeeting