| *** mhen_ is now known as mhen | 01:56 | |
| gtema | cardoe, I think you need to describe your issue differently, I do not get what you mean/want to achieve. Manager role is a very special one with different meanings being granted on domain and on project. Actually there is big difference granting role on project(s) and on domain | 04:53 |
|---|---|---|
| TheJulia | o/ Hey Guys, is https://etherpad.opendev.org/p/oct2024-ptg-keystone the right etherpad? | 06:33 |
| gtema | TheJulia yupp | 06:41 |
| noonedeadpunk | gtema: manager though implies member iirc | 06:44 |
| noonedeadpunk | so if you assign it - you should also get member stuff | 06:44 |
| gtema | noonedeadpunk, yes, my statement was about different fact (scoping) | 06:44 |
| noonedeadpunk | oh, yes, scoping is very different indeed | 06:45 |
| noonedeadpunk | but it should not be about role assignment, rather how you issue a token | 06:45 |
| gtema | Wrong, assignment of manager role on domain doesn't give you manager on project, independent on what you request | 06:46 |
| * noonedeadpunk reading statement again | 06:47 | |
| noonedeadpunk | ok, yes, you're right | 06:47 |
| noonedeadpunk | or well | 06:47 |
| noonedeadpunk | should not you get member on project if you assing manager inherited? | 06:48 |
| noonedeadpunk | and manager on domain will come with that as well? | 06:48 |
| noonedeadpunk | and then - it's only about how you issue a token? | 06:48 |
| gtema | My point is that cardoe seems to mix few different things in his statement and I want to get precise description of what he wants to achieve | 06:48 |
| noonedeadpunk | so "had manager on a domain but it wasn't inherited" seems as a right description of the issue - if it's inherited it should work | 06:49 |
| gtema | I just don't want to speculate about something what feels like wrong understanding of what person is trying to reach | 06:49 |
| TheJulia | I think business folks perceive domain manager gives self service rights to view/manage resources under projects, so if that spreads *outside* of keystone (which is possibly they way customers might percieve it), then projects which need to or might be able to support that access translation, it would be helpful to streamline the calls/interaction. | 06:57 |
| TheJulia | I also realize this is likely still being "designed" | 06:57 |
| TheJulia | ahh, I see the earlier manager role discussion | 06:58 |
| TheJulia | but relates nicely | 06:58 |
| opendevreview | Artem Goncharov proposed openstack/keystone master: Ruff the code https://review.opendev.org/c/openstack/keystone/+/931959 | 07:03 |
| TheJulia | gtema: just a gentle reminder, if cardoe is coming with a perception, he has others behind him with the same perception. He is just the bearer of operator perception, and thus with greater weight of urgency for community to remedy disconnects and perception challenges. | 07:05 |
| gtema | repeating myself again: I ask him to rephrase what is he willing to achieve in details without mixing different concepts in a single question. I want to help, but this is ONLY possible once I understand what the person is doing | 07:06 |
| TheJulia | It is a two way street. I'm just pointing out that others likely have the same perception, and you both need to work to mutual clarity. | 07:09 |
| gtema | believe me I know | 07:10 |
| noonedeadpunk | TheJulia: that statement feels quite off, sounds like cardoe is _the only_ operator around which should be prioritized over other operators | 07:10 |
| noonedeadpunk | I don't feel the same way, that ones should be percepted in a different way then others | 07:11 |
| TheJulia | Oh, to be clear, all operators. I just know from other discussion he is trying to move various items forward with quite a bit of urgency. | 07:11 |
| gtema | people - please STOP. Do not speculate | 07:11 |
| opendevreview | Artem Goncharov proposed openstack/keystone master: Ruff the code https://review.opendev.org/c/openstack/keystone/+/931959 | 10:00 |
| opendevreview | Artem Goncharov proposed openstack/keystone master: Ruff the code https://review.opendev.org/c/openstack/keystone/+/931959 | 10:35 |
| cardoe | Hello all. Sorry I missed the convo it was the middle of the night for me. | 12:00 |
| opendevreview | Artem Goncharov proposed openstack/keystone master: [WIP] Add new keystone.wsgi module https://review.opendev.org/c/openstack/keystone/+/932060 | 12:03 |
| cardoe | So I know we (code maintainers) often get zero context in bug reports or questions and it's frustrating so I apologize for not providing enough. I was trying to keep it brief since it was the project team meeting. Somewhere deep in the scroll back when I first asked about OIDC is the full context but no one ever replied to me save for a few folks private messaging me about their setups. | 12:05 |
| cardoe | So today our usage (and this is just my area of focus and not all usage) of Ironic and other bits of OpenStack are run more like bifrost (and some are actually bifrost) where there is no Keystone. Users aren't really hitting the Ironic API directly. Things have grown up around all this and business processes and tools live atop this. | 12:10 |
| cardoe | In my role now I own a bunch of those systems and the folks that maintain them and so being the evil PHB that I am I've asked "Why's this all not just OpenStack?" | 12:12 |
| cardoe | I'm clearly oversharing here but just hoping this makes it a bit smoother. | 12:13 |
| cardoe | The organization I'm talking about is Rackspace. I know a bunch of folks here have had some interaction with Rackspace whether it's working for them or dealing with people working for them so I recognize there's some attached feelings here as well. | 12:14 |
| cardoe | And again I'll over share.... Rackspace has this weird attitude internally towards OpenStack as well in that its something to be avoided. Sure you've got the James Denton and Kevin Carter's but they're off in our literal internal OpenStack org. While I'm what's called "main line org". | 12:18 |
| cardoe | Keystone is a funny one for Rackspace as well. Since it really grew up from Rackspace. It's Rackspace's "customer identity" system. But Rackspace doesn't use Keystone afaik. I think it's a Java implementation and it's only using v2. However a lot of the v3 functionality is implemented as extensions on v2. | 12:20 |
| cardoe | So outside of the OpenStack org, we're clueless as to what real Keystone does. So I'm just tinkering on a keystone. | 12:21 |
| cardoe | I know I mentioned "3 operators are using websso". I'm not counting Rackspace in those 3. I'm counting Vexxhost because that's where the code is hosted. And then 2 others that have messaged me and told me about it when I asked my original OIDC questions. | 12:22 |
| cardoe | So what I'm trying to achieve is that we have this system CORE (for those former Rackers) where there are accounts which are buckets that hold different types of hardware. | 12:24 |
| cardoe | Very high-level it sounds to me like those are OpenStack projects and devices can be assigned to them. | 12:25 |
| cardoe | But these accounts don't have users for them. Our employees manipulate them and they have access to it through Microsoft Entra (I think that's the name for their Azure hosted Active Directory now). | 12:26 |
| cardoe | If you're a member of group X you can do A, B, and C to all CORE accounts. And you'll gain that permission automatically for any new ones created. | 12:27 |
| cardoe | But it's not really all CORE accounts because there's ACLs. We've got name prefixes on accounts and then different groups are done that way. | 12:29 |
| cardoe | Then there's some accounts that have a name prefix and a suffix. | 12:30 |
| cardoe | But the prefix determines what ACL group that should be in. It's a lot like https://opendev.org/openstack/project-config stuff where it's not really automatic, someone has to make a git commit to add it to that group. | 12:31 |
| cardoe | But from my high-level it looked like these accounts could map to Keystone via Domains for the prefix and then sub-projects are the accounts with suffix | 12:36 |
| cardoe | But I wanted to make the permissions work the same way. So it would be all projects in a domain are allowed to be touched by users with access to that domain | 12:37 |
| cardoe | So I'm just tinkering. I'm also messing with the manager role like TheJulia talked about. And yeah I perceived that manager meant more than just to Keystone. So I gave myself manager in my test Keystone. Forgot about it when I had an issue with the project permission inheritance. | 12:40 |
| cardoe | I asked if my understanding of inheritance was correct because it wasn't working for me. I read the docs and things weren't clear at all. So I asked. | 12:43 |
| cardoe | No one really knew and told me I needed to ask specific people. Which I hope we can agree isn't ideal. Then I was suggested to try an API endpoint. So I was reporting back that yes that API endpoint works. This was the CLI command that pokes it. My issue was a misconfiguration on my part. It was just suppose to be a thank you to close the loop. | 12:45 |
| cardoe | So I'm trying to use OIDC which will get the groups claim to give people permissions to domains and by extension projects. I fully expect we'll be writing custom roles and custom policies. | 12:48 |
| cardoe | As part of the overall effort I'm pushing my people to contribute back to OpenStack. I'm seeing a lot of forks or downstream work without a lot flowing back up. I think the overall OpenStack project is seeing the same with the number of contributors going down each year for the past few years. So I'm trying to help reverse that trend. | 12:54 |
| cardoe | I'm personal friends with a number of folks at different infrastructure operators that I know use OpenStack and so I'm challenging them to contribute back. I've been met with a lot of "you do it and tell me how it goes" | 12:56 |
| opendevreview | Artem Goncharov proposed openstack/keystone master: [WIP] Add new keystone.wsgi module https://review.opendev.org/c/openstack/keystone/+/932060 | 12:57 |
| cardoe | And if I'm being honest it's been quite a mixed bag. Some projects have said "hey thanks for your contribution but it's wrong cause XYZ" and some have been quite the cold shoulder. I've been told that I won't get a +2 from a commit from an @rackspace.com email address so you'll notice I don't contribute patches from that address any more. | 12:58 |
| cardoe | The folks that work for me all don't contribute patches from their rackspace emails. | 12:58 |
| cardoe | I listen to the prior TC and the talk about more diversity and getting more contributors and I totally agree. And then when the actual encounter meets the projects there's a difference. | 12:59 |
| cardoe | My people's complaint has been that OpenStack doesn't feel like regular Python development. It's all different tooling and conventions and such. | 13:00 |
| cardoe | So my push has been to try and get more contributors and more operator contributors and making it easier from a dev experience. A couple people told me I should throw my hat into the TC election on that platform so I did. | 13:01 |
| cardoe | Last bit of context to the whole convo I think is my 1 docs patch to Keystone. | 13:01 |
| cardoe | gtema: you told me you have an issue with my patch because countless others have figured out how to use it just fine. That seems problematic to me overall because it raises the bar to entry. I've not been the only person asking in here about OIDC configuration issues. There's someone on the ML having SAML configuration issues as well. | 13:03 |
| gtema | cardoe: thanks for clarification. I asked for more clarifications because I have not properly understood the message in your "report" | 13:04 |
| gtema | I strongly suggest you to join PTG Keystone meeting on federation. There are so many things there that people are just not aware of | 13:04 |
| cardoe | The docs today say "we're gonna use Google as an example. Here's a blob of config to use." They define what some of the options are or mean. So I went and added descriptions to the other options. | 13:05 |
| gtema | look, the problem is: the doc as well as the implementation were mostly done by people with half a knowledge in the topic and as such it is simply terribly wrong | 13:05 |
| gtema | it works, yes, but it is simply wrong to go this way on my personal opinion after spending more then a year deep in the federation topic | 13:06 |
| cardoe | Lastly the mapping docs (so different page from the federation config) say that any list based data must be delimited by a ; but the default in mod_auth_oidc is to use a , so I added the config option to use ; | 13:06 |
| cardoe | I won't disagree with you. It seems awkward with an Apache module and it not being native to keystone. I'm all for helping land better support. BUT I just want to document how the code works today at the same time. | 13:07 |
| gtema | thanks. I hear first time the detail that mod_auth_oidc defaults_to ",". I think if you would have mentioned this in your change it would give some hints to why. Second is that there are some tests with keycloak federation that work now (as well as real deployments), so without adding more tests proving things are working is also necessary. | 13:12 |
| cardoe | To what TheJulia said about urgency. A couple of us have stuck our necks out in advocacy of OpenStack in a less than friendly to OpenStack environment and we've gotta start showing the benefits and proving the naysayers wrong. We've rejoined OpenInfra and have had folks attend events again so the start of the investment from us is there. We just need to show some progress to continue the investment. | 13:12 |
| cardoe | So I'm trying to make things happen today with code that exists today. | 13:13 |
| gtema | In the current state it looks to me like: I have tried something out and found that it doesn't work for me the described way, so I propose to change the doc without proving I myself did the things right way (disclaimer - no offence) | 13:13 |
| cardoe | gtema: I literally put that in the commit message. | 13:14 |
| gtema | I do not read it this way | 13:14 |
| cardoe | it uses a comma as its delimiter by default. But keystone uses ; as it's delimiter when using a field in a mapping as a list. So the user must configure mod_auth_openidc to use a ; instead of a , | 13:15 |
| cardoe | That's copy and paste. | 13:15 |
| gtema | ok, after you pointed that and I literally re-read the sentence few times I see where you mean it | 13:15 |
| TheJulia | cardoe: Thank you for that level of detail, honesty and clarity. I just want to ensure you understand your not the only person or even operator I'm hearing similar concerns/issues/frustrations and ultimately needs from. The words are a little different, but the overall need, intent, and challenges aligns with slightly different details. | 13:22 |
| cardoe | I appreciate it. Overall I want to see OpenStack be successful and do my best to help the project. | 13:33 |
| opendevreview | Merged openstack/oslo.policy master: Add timeout in HTTP requests https://review.opendev.org/c/openstack/oslo.policy/+/914740 | 13:47 |
| opendevreview | Merged openstack/oslo.limit master: Query endpoint id from keystone https://review.opendev.org/c/openstack/oslo.limit/+/914783 | 13:55 |
| opendevreview | Artem Goncharov proposed openstack/keystone master: [WIP] Add new keystone.wsgi module https://review.opendev.org/c/openstack/keystone/+/932060 | 15:11 |
| opendevreview | Antonia Gaete proposed openstack/keystone master: Add JSON schema to `trust` and validation decorators to trust resource. https://review.opendev.org/c/openstack/keystone/+/930361 | 19:31 |
| opendevreview | Oria Weng proposed openstack/keystone master: Add JSON schema to `limits` https://review.opendev.org/c/openstack/keystone/+/931528 | 19:42 |
| opendevreview | Antonia Gaete proposed openstack/keystone master: Add JSON schema to `service provider` and validation decorators to service provider resource. https://review.opendev.org/c/openstack/keystone/+/930610 | 19:47 |
| opendevreview | Antonia Gaete proposed openstack/keystone master: Add JSON schema to `identity provider` and validation decorators to identity provider resource. https://review.opendev.org/c/openstack/keystone/+/930633 | 20:45 |
| opendevreview | Antonia Gaete proposed openstack/keystone master: Add JSON schema to `trust` and validation decorators to trust resource. https://review.opendev.org/c/openstack/keystone/+/930361 | 20:59 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!