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