| *** diablo_rojo is now known as Guest500 | 03:09 | |
| *** enick_952 is now known as diablo_rojo | 03:09 | |
| opendevreview | jamesjordanblack604@gmail.com proposed openstack/python-openstackclient master: Bug Fix, Default SG Rule Custom SG https://review.opendev.org/c/openstack/python-openstackclient/+/909815 | 04:17 |
|---|---|---|
| opendevreview | Lajos Katona proposed openstack/python-openstackclient master: Router flavor_id can be a name https://review.opendev.org/c/openstack/python-openstackclient/+/902654 | 08:37 |
| opendevreview | Lajos Katona proposed openstack/openstacksdk master: Add sort_key and sort_dir to core Neutron resources https://review.opendev.org/c/openstack/openstacksdk/+/909656 | 11:43 |
| stephenfin | gtema: You might know this. When would I want to use OS_USER_DOMAIN_ID or OS_PROJECT_DOMAIN_ID rather than OS_DOMAIN_ID? | 12:17 |
| gtema | USER_DOMAIN_ID is to tell which domain to search user in (auth part) | 12:18 |
| gtema | PROJECT_DOMAIN_ID is for project scope | 12:18 |
| gtema | DOMAIN_ID is for domain scope | 12:18 |
| stephenfin | If we have a clouds.yaml file without DOMAIN_ID provided, can we assume USER_DOMAIN_ID == DOMAIN_ID? | 12:18 |
| gtema | nope | 12:19 |
| gtema | then unscope auth would be used | 12:19 |
| stephenfin | Are there any domain-scoped APIs? I thought most APIs were project-scoped or system-scoped (where domain presumably doesn't matter)? | 12:23 |
| stephenfin | (btw, context is that gophercloud integration tests inside on a domain ID or name, but I've never seen a clouds.yaml with domain_id/domain_name defined so I'm trying to figure out why it needs it/if I can remove that requirement) | 12:25 |
| gtema | OpenTelekomCloud uses domain scope actively and currently in Keystone there is work on improving it | 12:26 |
| gtema | so you definitely should keep the stuff | 12:26 |
| stephenfin | sorry for being slow on the uptake, but could you give me an example of an API that would use domain scope? | 12:27 |
| stephenfin | you'd use it to...create a new project within a domain? | 12:28 |
| gtema | in OTC all of the Identity ops require domain scope, but lemme check in Keystone what is currently in works | 12:29 |
| gtema | https://review.opendev.org/c/openstack/keystone/+/908524 is one of the recent changes there | 12:33 |
| gtema | it is currently under the RBAC hat | 12:34 |
| gtema | but in principle you are right: creating a new user is a typical domain scope operation (it has no relation to the project) | 12:35 |
| opendevreview | Mridula Joshi proposed openstack/python-openstackclient master: Add CLI support for adding multiple tags https://review.opendev.org/c/openstack/python-openstackclient/+/909870 | 14:27 |
| opendevreview | jamesjordanblack604@gmail.com proposed openstack/python-openstackclient master: Bug Fix, Default SG Rule Custom SG https://review.opendev.org/c/openstack/python-openstackclient/+/909815 | 15:31 |
| opendevreview | jamesjordanblack604@gmail.com proposed openstack/python-openstackclient master: Bug Fix, Default SG Rule Custom SG https://review.opendev.org/c/openstack/python-openstackclient/+/909899 | 15:32 |
| johnsom | gtema On this DNS patch, what other methods are you talking about, can you provide an example? When this was added to the Designate API, designate was the only project that had this capability. | 16:43 |
| gtema | jonsom: I disagree with this statement. Nova (i.e. list servers), Neutron (i.e. list networks), Cinder (i.e. list volumes) support either same or some form of filtering by project_id (independent on whether endpoint already contains project_id) and some also support "all_projects" query parameter. And this is like that since (maybe) beginning? | 17:00 |
| gtema | johnsom ^^ (sorry for typo) | 17:00 |
| johnsom | Nova for example, has no way to create a server on behalf of another project. | 17:01 |
| johnsom | Likewise, nova has "all_tenants" as a query parameter on list, but neutron does not. | 17:01 |
| johnsom | I think this is a meta-issue across all of the services and something that should be standardized via the api-wg (if there is a member left) | 17:01 |
| johnsom | I was just adding that comment to the patch | 17:01 |
| johnsom | This isn't for filtering, those query params are the same. | 17:02 |
| johnsom | It's for impersonating a project or acting across projects | 17:02 |
| gtema | I am left in api-wg, but something like that will not be easy: there is no power to force projects to follow it | 17:02 |
| johnsom | Agreed, but if we at least document a "standard" it's a step in the right direction | 17:03 |
| johnsom | Then it could become a "goal" (not that I am a fan of those) | 17:03 |
| gtema | I agree with the problem and I see it in different places | 17:03 |
| gtema | token scoping is something many people have problem with | 17:03 |
| johnsom | I do | 17:03 |
| johnsom | Don't get me started on system scoped tokens. lol | 17:04 |
| gtema | I think idea of introducing headers is very bad, since once you go into the OpenAPI area this is just going to blow | 17:05 |
| gtema | better approach would be (my personal opinion) is to address token scoping itself | 17:05 |
| johnsom | At one time headers were all the rage in OpenStack. This is very old code in designate, at least 10 years old | 17:06 |
| gtema | it is also unclear in the current implementation: what is the effect for the regular user, can he also use "x-auth-sudo-project" if he do not have roles on that project | 17:06 |
| johnsom | We can't remove that, but if we standardize on another approach I think we would be open to adding it. token scoping is not the solution though, that just adds complexity | 17:07 |
| gtema | really 10 years? I somehow never noticed those | 17:07 |
| johnsom | sudo-project has RBAC rules in the middleware | 17:07 |
| johnsom | Yeah, it was in havana | 17:09 |
| gtema | hmm, I will need to think how to generally address that. I guess for listing "all_projects" and "project_id" as simple query parameter is a de-facto standard, and not headers. Impersonation is something we really need to discuss in wider round (maybe during vPTG) | 17:12 |
| johnsom | neutron does not use those query params | 17:12 |
| gtema | it has tenant_id/project_id | 17:13 |
| johnsom | as a filter on list maybe, but not for create, etc. | 17:13 |
| gtema | right, creation everywhere (well except Designate) is based on the token scope for the current project | 17:14 |
| johnsom | I think designate has that filter too, but they have different purposes. | 17:14 |
| gtema | well, I see Neutron does support setting project_id also for create resources | 17:14 |
| johnsom | Think of this use case, as an admin I want to create a zone for project 123 because they called the help line. | 17:14 |
| gtema | it just states: "Only administrative and users with advsvc role can specify a project ID other than their own. You cannot change this value through authorization policies." | 17:15 |
| johnsom | Right, and nova doesn't. It's just inconsistent across the projects. | 17:15 |
| gtema | well right in that sense. Nova does not allow this | 17:16 |
| gtema | cinder supports | 17:17 |
| gtema | Octavia supports | 17:17 |
| gtema | I think we can observe some mass of core projects that does support that | 17:17 |
| johnsom | Yeah, octavia mirrors neutron in a lot of ways as it had to be API compatible with neutron-lbaas | 17:18 |
| gtema | DNS is also related to networking ;-) | 17:19 |
| johnsom | So, on the designate patch, is it the addition of "headers" the the list method that is of concern or was it just that you thought the headers were new in designate? | 17:19 |
| gtema | as stated I thought it was something new | 17:20 |
| johnsom | Can we move forward with this patch and then work on an api-wg "standard" we can move all of the project towards in the future? | 17:20 |
| gtema | I think in this case it is "ok" | 17:21 |
| gtema | but I am surely very unhappy with that style | 17:21 |
| johnsom | Ok. I am also very happy to work together on creating a standard for this stuff. It would be nice to have a consistent way to do this across the projects. | 17:23 |
| gtema | great | 17:24 |
| johnsom | Hmmm, did the openstack/api-wg repo go away? | 17:26 |
| gtema | https://opendev.org/openstack/api-sig | 17:27 |
| johnsom | Yeah, just found that. The link on the https://specs.openstack.org/openstack/api-wg/ page is wrong | 17:27 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!