18:00:01 <lbragstad> #startmeeting keystone
18:00:02 <openstack> Meeting started Tue Dec 12 18:00:01 2017 UTC and is due to finish in 60 minutes.  The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:05 <openstack> The meeting name has been set to 'keystone'
18:00:08 <lbragstad> #link https://etherpad.openstack.org/p/keystone-weekly-meeting
18:00:11 <lbragstad> agenda ^
18:00:27 <lbragstad> ping ayoung, breton, cmurphy, dstanek, edmondsw, gagehugo, henrynash, hrybacki, knikolla, lamt, lbragstad, lwanderley, kmalloc, rderose, rodrigods, samueldmq, spilla, aselius, dpar
18:00:43 <hrybacki> o/
18:00:57 <gagehugo> o/
18:00:59 <tlam_> o/
18:01:09 <knikolla> o/
18:01:56 <kmalloc> zzzz
18:01:59 <spilla> o/
18:02:56 <lbragstad> #topic PTG security SIG meeting
18:02:58 <lbragstad> gagehugo: o/
18:03:12 <gagehugo> so
18:03:19 <aselius> o/
18:03:29 <cleong> o/
18:03:55 <gagehugo> the security team/SIG will likely be meeting at the PTG, and was wanting to know if keystone had anything they wanted to bring to attention
18:04:15 <gagehugo> anything that is cross-project or cross-collaberation
18:05:00 <gagehugo> if there is anything either let me or lhinds know
18:05:24 <gagehugo> that's all I got
18:05:39 <lbragstad> nothing is coming to mind at the moment, the last i talked to the security folks i wanted to get an opinion on the policy roadmap we had for security
18:06:02 <gagehugo> I can bring that to the meeting thurday
18:06:34 <lbragstad> cool - i just wanted another set of eyes on it from a security perspective, nothing that's a hard requirement though
18:06:46 <lbragstad> gagehugo: anything else?
18:06:56 <gagehugo> nope
18:07:04 <lbragstad> #topic User defined project IDs
18:07:25 <lbragstad> ruan_he wanted to drive this topic during the meeting
18:07:32 <lbragstad> but I don't see him online
18:07:47 <lbragstad> either way
18:08:02 <lbragstad> several folks from Orange posted their usecases in https://review.openstack.org/#/c/323499/
18:08:10 <lbragstad> to keep the context in a single place
18:08:33 <lbragstad> the previous reviews on that spec were asking for use cases
18:08:48 <gagehugo> I think we had one of the same use cases
18:08:51 <lbragstad> but they also included a couple requirements
18:08:53 <gagehugo> distributed keystones
18:08:57 <lbragstad> yeah...
18:09:03 <gagehugo> and it used to work in kilo?
18:09:09 <lbragstad> that was news to me
18:09:17 <gagehugo> or before
18:09:30 <lbragstad> i parsed the code base looking for the code that allowed that and i came up with nothing
18:09:38 <gagehugo> yeah idk
18:09:45 <lbragstad> i looked through the project API dating back to diablo
18:09:46 <kmalloc> wait, what?
18:09:49 <kmalloc> it worked in kilo?
18:09:57 <lbragstad> i couldn't find proof of that
18:09:58 <gagehugo> it worked in an earlier release
18:10:07 <kmalloc> unlikely
18:10:15 <lbragstad> but i could have been looking in the wrong place?
18:10:23 <kmalloc> i'll take a gander
18:10:34 <kmalloc> but i seriously doubt it
18:10:40 <kmalloc> short of someone changing the code
18:10:59 <gagehugo> It may have broke in kilo
18:11:00 <lbragstad> afaik, we never allowed project IDs to be specified over the API
18:11:06 <gagehugo> since that is when it came up for us
18:11:12 <lbragstad> oh - really?
18:11:15 <gagehugo> so perhaps before then
18:11:22 <gagehugo> is when it worked?
18:11:49 <kmalloc> in v2 we allowed it
18:12:06 <kmalloc> https://github.com/openstack/keystone/blob/juno-eol/keystone/assignment/controllers.py#L114
18:12:12 <kmalloc> known reason we also discontinued v2
18:12:17 <lbragstad> the review says the functionality worked in Juno https://review.openstack.org/#/c/323499/4/specs/keystone/backlog/admin-to-create-project-with-id.rst@77
18:12:21 <gagehugo> oh there we go
18:12:26 <gagehugo> kmalloc nice
18:12:26 <kmalloc> security
18:12:32 <lbragstad> oh
18:12:40 <kmalloc> v3 NEVER supported it afaict
18:12:44 <lbragstad> ++
18:12:51 <gagehugo> interesting
18:12:53 <lbragstad> that's consistent with everywhere i dug
18:12:56 <tlam_> yes, when we upgraded from Juno to Kilo, it stopped working, and it was one thing that was raised
18:13:29 <kmalloc> yep, v2 only
18:13:36 <kmalloc> v3 never supported this.
18:13:40 <kmalloc> looking at kilo now
18:14:32 <kmalloc> yep, in kilo v2 still supported it
18:14:50 <lbragstad> ok - good to know
18:14:57 <kmalloc> tl;dr, moving to v3 disabled that support, v3 never supported it (confirmed back to grizzly)
18:15:07 <lbragstad> cool
18:15:11 <gagehugo> ah ok
18:15:22 <lbragstad> that's consistent with what i found with v3 support, too
18:15:33 <knikolla> interesting
18:16:03 <kmalloc> and this was planned - it had a lot of implications for folks squatting on project ids, and that they weren't conforming to UUIDs (which is a requirement we started asserting for compatibility everywhere)
18:16:56 <kmalloc> if we support this we need to ensure / assert the ids are UUID conforming.
18:17:13 <lbragstad> i'm curious what other folks think of the reproposed specification
18:17:24 <lbragstad> since it includes usecases
18:17:29 <lbragstad> and requirements
18:17:38 <lbragstad> also - if there are any alternatives that come out of it
18:17:44 <kmalloc> so, the use-case for restoration of a deleted id, that can be soft deletes (cringe)
18:18:17 <lbragstad> or disable/enable
18:18:27 <kmalloc> i also want to be clear, I don't want creation of specific ids to be a "general" like domain-admin concept.
18:19:57 <lbragstad> the other requirement i found interesting was the database replication restriction
18:20:04 <kmalloc> the hard part here is *even* if the ids can be specified, across deployments -- it is not possible to guarantee the ID isn't used in another deployment
18:20:17 <kmalloc> and IDs must be unique within the keystone
18:20:51 <lbragstad> https://review.openstack.org/#/c/323499/4/specs/keystone/backlog/admin-to-create-project-with-id.rst@22
18:21:44 <kmalloc> the only real solution i can think of is something like allow for a deployment to register a prefix or do a federated source of ids for resource subsystem
18:22:17 <lbragstad> register a prefix?
18:22:35 <kmalloc> aka, France cloud (for example) starts with AAEECC
18:22:48 <kmalloc> so all projects have that, and no other cloud participating does.
18:22:54 <kmalloc> it's soft enforcement
18:23:34 <breton> that's some half-done replication
18:23:37 <kmalloc> i think we're going to simply run into issues where IDs are going to conflict and it will put us into a worse state than every deployment is random
18:23:45 <kmalloc> breton: no, look at the spec, no replication
18:23:46 <breton> without all constraints a real replication has
18:23:56 <kmalloc> it can't happen.
18:24:08 <kmalloc> so it's admin-created and it's rough
18:24:19 <lbragstad> according to law the replication at the db layer can't happen
18:24:44 <kmalloc> I somehow doubt that is in-fact the law, i think it's overly cautious lawyering. but i can't change that.
18:24:57 <kmalloc> if there was clear isolation of exactly what was replicated [separate DBs]
18:25:05 <kmalloc> it probably would fly just fine
18:25:14 <kmalloc> but cautious lawyers would probably still nix it
18:25:40 <lbragstad> hmm
18:25:52 <lbragstad> i asked for a link there if it is public so we can dig into it a bit more
18:26:43 <kmalloc> now...... isolating resource is a big job
18:26:46 <kmalloc> because FK issues
18:27:01 <kmalloc> we basically nixed that last cycle for "this is hell to make happen in a migration"
18:27:40 <lbragstad> yeah..
18:27:42 <kmalloc> i could probably spin up a patch that would isolate each subsystem behind a different DB connection  so folks can run each subsystem in a different db.
18:28:05 <kmalloc> and our testing would simply be different dbs so no FKs would ever work.
18:28:11 <kmalloc> but that is a lot of work.
18:28:14 <lbragstad> yeah...
18:28:18 <lbragstad> that feels heavy handed
18:28:22 <kmalloc> the whole migration repos would need to be split up
18:28:46 <kmalloc> not the worst thing, just a "well....."
18:28:55 <lbragstad> but - i'm curious to hear what people think of the reproposed spec
18:29:03 <kmalloc> i dislike it greatly
18:29:07 <lbragstad> we've had it come up several times
18:29:13 <lbragstad> from different people
18:29:37 <lbragstad> i'd like to find a solution or alternative that addresses the problem
18:29:46 <kmalloc> but from a maintainability standpoint -- it doesn't solve problems, it mitigates some edge cases but causes a lot of headaches and i think we're going to see a lot of other requests ceom from it because it isn't really maintainable
18:29:48 <kmalloc> as an operator
18:30:14 <kmalloc> the best solution is allowing for a centralized source of truth that keystones can reference for the IDs
18:30:26 <kmalloc> but E_WHAT_IS_THAT
18:30:52 <lbragstad> one of the other requirements is that authZ information can't come from the same place authN does
18:32:54 <lbragstad> regardless, let me know if you have questions on the spec, it'd be good to get the conversation started early
18:33:08 <lbragstad> #topic
18:33:14 * lbragstad sigh
18:33:17 <lbragstad> #topic Unified limits API specification exception
18:33:27 <lbragstad> #link #link http://lists.openstack.org/pipermail/openstack-dev/2017-December/125331.html
18:33:32 <lbragstad> #link https://review.openstack.org/#/c/455709/
18:33:55 <lbragstad> for those who missed it, we had a super productive conversation last friday around unified limits and the initial model to target for it
18:34:10 <lbragstad> wxy: repropose the specification
18:34:39 <lbragstad> I submitted a specification freeze exception for it
18:34:51 <lbragstad> and based on what people say we can move forward with it this week
18:35:23 <lbragstad> if you missed the conversation in irc be sure to checkout
18:35:25 <lbragstad> #link http://eavesdrop.openstack.org/irclogs/%23openstack-dev/%23openstack-dev.2017-12-08.log.html#t2017-12-08T15:00:28
18:35:35 * lbragstad found it super helpful
18:36:19 <lbragstad> #topic open discussion
18:36:54 <kmalloc> proposal: remove past keystohne meeting data from the etherpad when we roll over cycles
18:37:01 <kmalloc> just to make the etherpad load less slowly.
18:37:08 <lbragstad> ++
18:37:30 <lbragstad> yeah - we're up to 1582 lines
18:38:06 <lbragstad> when we have our last meeting to queens i'll back up the content and remove it
18:38:10 <gagehugo> 09-27-16 meeting was jam packed
18:39:40 <lbragstad> yeah - stevemar had long meetings :)
18:41:00 <lbragstad> does anyone else have anything before we start office hours in 20 minutes?
18:42:03 <lbragstad> sounds good - thanks for coming
18:42:06 <lbragstad> #endmeeting