17:00:28 <knikolla> #startmeeting keystone
17:00:28 <openstack> Meeting started Tue Dec 15 17:00:28 2020 UTC and is due to finish in 60 minutes.  The chair is knikolla. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:29 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:31 <openstack> The meeting name has been set to 'keystone'
17:00:32 <knikolla> o/
17:00:49 <rafaelweingartne> \o
17:08:16 <knikolla> cmurphy, lbragstad, gagehugo: around?
17:08:28 <lbragstad> o/
17:08:31 <lbragstad> i am - sorry
17:08:52 <cmurphy> o/
17:09:09 <gagehugo> o/ I'm on vacation but usually around :)
17:09:25 <knikolla> gagehugo: enjoy your vacation!
17:09:39 <knikolla> #topic Lower-constraints job failing
17:09:57 <knikolla> The new pip dependency resolver is much stricter and is causing our lower-constraints job to fail
17:10:41 <knikolla> I am working on fixing it, but I'm not super well versed in it, so it's taking me quite some time of whackamoling.
17:12:00 <cmurphy> it looks like other projects are facing the same problem
17:12:16 <knikolla> yeah, there is a discussion on the mailing list
17:12:29 <knikolla> there didn't seem to be any consensus on how best to approach it though
17:12:38 <rafaelweingartne> Yes, I fixed for cloudkitty
17:13:12 <rafaelweingartne> but I took the lazy route, and just bumped them up as most of them were pretty outdated already
17:13:52 <knikolla> I'm trying to be more conservative, since a lot of things import keystoneauth or client
17:14:18 <knikolla> so I'm relaxing some constraints and trying to bump a few things
17:14:31 <knikolla> not fun
17:15:08 <knikolla> I miss the requirements bot
17:17:47 <knikolla> #topic Open Discussion
17:20:31 <knikolla> cmurphy: did you get a chance to re-review rafaelweingartne specs?
17:24:19 <cmurphy> i left some feedback earlier but i don't really have time to keep going back and forth on it, i'll support what the rest of the cores agree with. my only discomfort with 748042 was that it seems to make the domain attribute of a mapping behave differently from the project attribute, i.e. project is for role assignments but domain is the default namespace for users and groups rather than a
17:24:21 <cmurphy> target for role assignments. if other cores are okay with those semantics i won't fuss over it.
17:27:23 <knikolla> rafaelweingartne: the projects_json spec depends only on the versioned mappings or also by the domain attribute?
17:27:38 <rafaelweingartne> only on the versioned mappings
17:27:55 <rafaelweingartne> but if you want to use more complex things, such as a default domain, and then overriding it in some projects
17:28:02 <rafaelweingartne> then, yes, you would need it as well
17:28:29 <knikolla> but without it, the default domain would be implied to be the domain of the idp
17:28:33 <knikolla> right?
17:28:56 <rafaelweingartne> if we remove that, yes
17:29:03 <rafaelweingartne> I did not implement this way though
17:29:51 <rafaelweingartne> I really do not see the problem on using the domain on projects definition as well. That domain element is already used by the group definition
17:30:28 <cmurphy> that's very different, that's part of the group object
17:30:40 <cmurphy> groups and users are always identified by a name and domain
17:30:48 <cmurphy> so the group object contains a domain reference
17:31:07 <rafaelweingartne> but projects also have a domain, don't they?
17:31:15 <rafaelweingartne> they belong to a domain
17:32:10 <rafaelweingartne> is it possible to create a project without a domain? I have not checked that
17:32:44 <knikolla> if i understand cmurphy reservation correctly, is that in the mapping definition  project/group have a domain attribute. project and group are themselves top-level objects in the mapping.
17:33:04 <rafaelweingartne> yes
17:33:07 <cmurphy> right
17:33:13 <knikolla> however domain as a top level attribute would act fundamentally differently, since it would change things of other objects in the mapping.
17:33:24 <rafaelweingartne> it is already like that
17:33:36 <rafaelweingartne> you can define a domain in the top level of the mapping
17:34:13 <rafaelweingartne> also, this behavior would only be activated in the 1.1 version. Therefore, for everybody using it, they would still get the behavior we have right now
17:34:19 <knikolla> https://github.com/openstack/keystone/blob/a98f006f854be02e5682390012d8bb917f4f3940/keystone/federation/utils.py#L118
17:34:22 <knikolla> i believe you're referring to this
17:34:31 <knikolla> the fact that we already accept a domain in the mapping, but it doesn't do anything
17:34:32 <rafaelweingartne> yes
17:34:39 <rafaelweingartne> exactly
17:36:44 <knikolla> I do see cmurphy's reservation, and I do share it. However I think none of the cores have either felt too strongly against it, or super okay with it, and are therefore waiting on someone else to take the charge in either approving or shutting it down.
17:37:08 <cmurphy> if it currently doesn't do anything then there is no "already" to set any precedent, so now is when we define what it should be doing and i think the proposed definition doesn't make sense
17:38:03 <rafaelweingartne> I disagree, I really do not see why so much resistance on this one. It would not be activated by default.
17:38:26 <knikolla> rafaelweingartne: one question. if the domain is specified for the whole mapping, and you have one mapping per protocol/idp, why not use the idp domain as the default?
17:39:52 <knikolla> rafaelweingartne: I don't think the reservation is not with it being enabled by default. It is with it not matching the way that the other attributes/objects are defined in the mapping.
17:41:12 <rafaelweingartne> that domain value is used here: https://github.com/openstack/keystone/blob/a98f006f854be02e5682390012d8bb917f4f3940/keystone/federation/utils.py#L591
17:43:12 <rafaelweingartne> Probably I am misinterpreting things because I see groups and projects being bound to a domain; therefore, I would expect them to use/adopt this "domain" option in the same manner
17:47:38 <knikolla> rafaelweingartne: i need to dig deeper in that section of the code. so you've found that the domain there does provide a domain to the groups, but not projects
17:47:54 <rafaelweingartne> exactly
17:47:56 <knikolla> meaning, the top-level domain does provide the default domain for the groups, attribute
17:48:02 <rafaelweingartne> yes
17:48:04 <rafaelweingartne> exactly
17:48:18 <rafaelweingartne> and we extended it further, and provided this to projects as well
17:48:33 <rafaelweingartne> and then, also a method to override it in the project if needed
17:48:48 <knikolla> cmurphy: does it make more sense to you in this context?
17:50:01 <cmurphy> if it's the case that that domain is already used that way then yes that makes in this context, before we were saying that domain attribute doesn't get used so i was confused
17:50:48 <knikolla> yeah, sorry for causing the confusion. i had misunderstood.
17:50:50 <rafaelweingartne> well, to be fair
17:50:55 <rafaelweingartne> it is the first sentence I have there
17:51:05 <rafaelweingartne> Currently, Keystone identity provider (IdP) attribute mapping schema onlyuses the "domain" attribute mapping as a default configuration for the domainof groups being mapped
17:51:35 <knikolla> rafaelweingartne: you are completely right!
17:53:03 <knikolla> any other questions concerns while we're here?
17:53:10 <cmurphy> https://review.opendev.org/c/openstack/keystone-specs/+/748042/4/specs/keystone/wallaby/versioning-for-attribute-mapping-schema.rst#38 "The default domain definition in the "local" property of the attribute mapping rule was not being used." was where i interpreted that, sorry for the confusion
17:53:26 <knikolla> ++, i think that's what got me too
17:54:44 <knikolla> rafaelweingartne: so domain provides a default for the groups attribute. does it provide a default for "group" as well?
17:55:24 <knikolla> or in that one if only name is provided, the domain attribute must be inside the group object?
17:55:31 <rafaelweingartne> it has been a while that I did this implementation
17:55:36 <knikolla> (i should already know these things, sorry for asking)
17:55:39 <rafaelweingartne> I do not remember by heart, I would need to check
17:56:01 <rafaelweingartne> I would like to say yes
17:56:18 <rafaelweingartne> but that part of the code is a bit hard to me to read, so I would rather check it first
17:56:47 <knikolla> if we are having that be the default for projects, it feels like it should be the default for group as well, otherwise there is inconsistency
17:57:24 <knikolla> i will do some poking as well
17:58:10 <rafaelweingartne> In our implementation that is how it is working now, but in master I am not sure
17:58:10 <knikolla> sorry for taking this long to providing more feedback on the specs
17:58:37 <rafaelweingartne> we normalized the use of that variable, then it became consistent across the different elements
17:58:59 <knikolla> i see
17:59:21 <knikolla> alright, we're out of time. thanks all! thanks rafaelweingartne and cmurphy for the discussion.
17:59:32 <rafaelweingartne> welcome
17:59:42 <rafaelweingartne> we can keep exchanging in the spec there
17:59:53 <knikolla> #endmeeting