19:07:42 <lbragstad> #startmeeting keystone-office-hours
19:07:43 <openstack> Meeting started Tue Nov 21 19:07:42 2017 UTC and is due to finish in 60 minutes.  The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:07:45 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:07:47 <openstack> The meeting name has been set to 'keystone_office_hours'
19:08:49 <kmalloc> 1) I can't create the resource at all. and now i am stuck because someone squatted/created/owns it
19:08:49 <kmalloc> 2) I error, but can still use the resource, but someone else can as well
19:08:49 <kmalloc> (one of two issues*)
19:08:49 <kmalloc> randomized creation explicitly dodged these issues.
19:08:49 <kmalloc> let me be clear, i am not going to block or say we are unable to add this feature
19:08:49 <kmalloc> we have to be *Very* careful if we are adding it
19:08:49 <kmalloc> and we have to consider interop between deployments/use
19:09:17 <KwozyMan> fair enough
19:09:20 <kmalloc> if some clouds allow you to create ids and some don't - it adds to the already awful UX we have where options change the API behavior
19:09:36 <josecastroleon> the concern I have with autoprovisioning is that the resources are not cleaned up
19:09:48 <josecastroleon> you lose track from the user because it's not yours
19:09:49 <kmalloc> josecastroleon: no resources are really auto-cleaned up
19:10:00 <josecastroleon> and on a public cloud you have your credit card
19:10:01 <kmalloc> you lose track the moment is is created in keystone.
19:10:04 <josecastroleon> so you don't care
19:10:10 <kmalloc> it is the CRM's job to track that stuff
19:10:23 <josecastroleon> yes
19:10:24 <kmalloc> (customer relations management software, aka salesforce or sugar, etc)
19:10:47 <lbragstad> another interesting side-effect of project IDs over the API is if a token is revoked in one region
19:10:50 <kmalloc> FTR: i disagreed with adding autoprovisioning
19:10:52 <lbragstad> it won't be revoked in another
19:11:23 <kmalloc> i wish i had been at the forum, so i could have worked w/ orange folks to understand the specific replication concerns
19:11:35 <kmalloc> it is likely that it is PII-specific not "zero replication"
19:11:46 <lbragstad> since the data base isn't replicated - if the token is revoked in region A it won't be revoked in region B
19:11:52 <kmalloc> which could lead towards isolation of data and certifying what is replicatable
19:12:13 <lbragstad> true - i asked for some more information on the actually restriction
19:12:20 <lbragstad> i'll be sure to send it out if i get it
19:12:28 <lbragstad> actual*
19:12:44 <kmalloc> i am fairly certain it is not "you cannot replicate" but most orgs default to that because it dodges issues with "well but we got item Y by accident"
19:13:36 <lbragstad> the other requirement was that authZ data can't come from the source of authN
19:13:59 <kmalloc> that was orange's requirement?
19:14:09 <kmalloc> eh, thats easy enough with some SSO things.
19:14:13 <lbragstad> not sure - it came up in discussion somewhere and i wrote it down
19:14:29 <lbragstad> but you could also do that today by not having a mapping
19:14:30 <kmalloc> i wonder if that means the authoritative authn or any authn
19:14:39 <lbragstad> and just manually managing role assignment on the shadow user
19:14:40 <kmalloc> because what if keystone is backed by ldap
19:14:49 <kmalloc> ldap is providing authn but by proxy to ldap
19:14:52 <kmalloc> is that sufficient
19:15:03 <kmalloc> and what you said about mapping
19:15:30 <kmalloc> in short, autogeneration of IDs is the best option for most of keystone's use-cases
19:15:35 <lbragstad> right authZ from an openstack perspective would be completely isolated from authN
19:16:13 <KwozyMan> Gentlemen, I have to retire now.
19:16:15 <kmalloc> i *might* be willing to add id-specification (for projects and users) as resource-options to a domain
19:16:22 <kmalloc> so you create the domain with that option set
19:16:29 <kmalloc> and then you're allowed to specify ids.
19:16:32 <lbragstad> KwozyMan: no worries - thanks for coming
19:16:34 <kmalloc> but it has to be discoverable
19:16:37 <KwozyMan> We'll try to rewrite the spec to consider your concerns
19:16:44 <kmalloc> KwozyMan: ^
19:16:58 <lbragstad> kmalloc: yeah - that'd be another way to go about it
19:17:15 <kmalloc> lbragstad: that makes me a bit happier since you can look at the domain object to know if it's allowed
19:17:24 <kmalloc> and then you can provide or not
19:17:33 <lbragstad> which should be specific to an idp
19:17:38 <kmalloc> it doesn't really break APIs and it makes it so it is every explicitly opted into
19:17:58 <lbragstad> which gets around the stealing of namespace before someone hooks things up from the Idp, right?
19:17:58 <kmalloc> now ids are still 100% globally unique
19:18:11 <kmalloc> so i would probably force a prefix that we can control
19:18:22 <kmalloc> do a UUID5(namespace-prefix, uuid4)
19:18:42 <kmalloc> so they can generate it but it must conform to a way we can avoid conflicts and we can reject uuids in other places that don't conform
19:19:02 <kmalloc> or prefix + uuid4[4:]
19:19:14 <josecastroleon> the project id will be then the uuid4 or the whole blob?
19:19:31 <kmalloc> josecastroleon: the id would be the whole blob. it makes this viable going forward
19:19:34 <lbragstad> it would be munged together
19:19:35 <kmalloc> not retroactively
19:19:52 <lbragstad> (token payloads would be a bit longer)
19:19:57 <kmalloc> lbragstad: nah
19:20:13 <kmalloc> lbragstad: we'd still 32 byte ids
19:20:27 <lbragstad> unless you deconstruct the token and serialize them separately?
19:20:29 <kmalloc> just say first 4 bytes would be restricted or frist 10
19:20:39 <kmalloc> lbragstad: ids are imuutable
19:20:43 <kmalloc> so 2 cases:
19:20:56 <kmalloc> auto creation of id, lets say 10-bytes unique (lots ot space)
19:21:12 <kmalloc> domain-specific-10-by-prefix + uuid4()[10:]
19:21:38 <kmalloc> so 1234567890 + uuid4() and drop the first 10 bytes of the uuid before munging
19:21:49 <josecastroleon> then they need to have the same domain id in both enviroments right?
19:21:56 <kmalloc> right
19:22:23 <kmalloc> we would need to address that, but domain-flagged projects, I'm more willing to be flexible on
19:22:27 <josecastroleon> but when you are creating it, would you be able to specify it?
19:22:36 <josecastroleon> i meant the domain
19:22:52 <kmalloc> ugh but we run into the same issues since domains and projects are the same type
19:23:01 <josecastroleon> yep
19:23:05 <kmalloc> josecastroleon: well you can specify domain-names for everything
19:23:15 <kmalloc> and you could specify the domain-prefix id
19:23:26 <kmalloc> this is awful.
19:23:47 <kmalloc> i don't think we can reasonably supply a consistent API to allow specification of IDs
19:24:42 <josecastroleon> can we do some kind of configuration option to allow them to go forward? with a very big warning message with all the things that will fail
19:25:00 <kmalloc> josecastroleon: i can't +2 that, but i can "not block it"
19:25:14 <kmalloc> because i never feel good with the "set an option that changes the API behavior"
19:25:54 <josecastroleon> it's more on orange side
19:26:11 <kmalloc> right. and it still comes down to a general purposew config to handle that use case
19:26:12 <josecastroleon> we can workaround it
19:26:51 <kmalloc> right.
19:27:20 <kmalloc> i think i need to know more about the orange restrictions
19:27:28 <kmalloc> what are the real limitations
19:27:41 <kmalloc> but that said... i understand what they're trying to do.
19:28:44 <lbragstad> yeah - if it is a law thing, we should hopefully be able to dig into some public documentation on it somewhere
19:29:00 <lbragstad> maybe that helps clarify requirements
19:31:37 <kmalloc> yep
19:31:48 <lbragstad> josecastroleon: either way - let's see if we can get this stuff captured somewhere
19:32:00 <lbragstad> especially since this conversation comes up frequently
19:32:06 <josecastroleon> sure
19:32:27 <lbragstad> it'll hopefully be easier to iterate towards a solution when we have things documented
19:32:39 <lbragstad> or come up with alternatives that work
19:35:01 <josecastroleon> thanks, i need to retire, it's getting late here :D
19:42:47 <lbragstad> josecastroleon: sounds good - thanks for sticking around
19:52:14 <lbragstad> for those here for office hours - i'll be working on bug triage
19:52:36 <lbragstad> i haven't done much of that in the last couple weeks with all the things going on, so i'll be catching up on that
19:52:58 <lbragstad> i have stumbled across several good candidates if anyone is looking for something though
21:07:55 <lbragstad> lamt: https://bugs.launchpad.net/oslo.cache/+bug/1731921
21:07:55 <openstack> Launchpad bug 1731921 in keystonemiddleware "memcache_socket_timeout is too high" [Undecided,In progress] - Assigned to Vincent Untz (vuntz)
21:08:09 <lbragstad> ^ that might be something that gets fixed once we port ksm to use oslo.cache
21:52:57 <lamt> lbragstad : am planning to start oslo.cache work after Thanksgiving
21:52:58 <lbragstad> i parsed most of the recent bug activity and updated various reports with office-hours tags https://bugs.launchpad.net/keystone/+bugs?field.tag=office-hours
21:53:05 <lbragstad> lamt: awesome
21:53:29 <lbragstad> most of those bugs seem like things that can be accomplished in a few hours
21:53:38 <lbragstad> if anyone is looking for bugs to work on
22:53:23 <openstackgerrit> Lance Bragstad proposed openstack/oslo.policy master: Add scope_types to RuleDefault objects  https://review.openstack.org/510222
23:02:52 <lbragstad> #endmeeting