| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-04-27 | |||
| 15:25:29 | dansmith | stephenfin: right but everyone needs to do that.. tripleo, kolla, debian, ubuntu, rdo, $mycustomthing | |
| 15:27:05 | zigo | stephenfin: This is going to be horrible to manage with puppet-nova... | |
| 15:27:06 | stephenfin | I didn't think we generated policy.json for RDO/OSP, and I assume Ubuntu will take whatever Debian does. I can't argue with $mycustomthing though, no | |
| 15:27:21 | zigo | stephenfin: You assume wrong ! :) | |
| 15:27:28 | zigo | Ubuntu do their own crap ... | |
| 15:27:34 | stephenfin | \o/ | |
| 15:27:44 | gmann | I was checking to remove 'system:all' from new default but that leads to over-permission issue | |
| 15:27:57 | zigo | I tried for years to fight this, it never worked, because of marketting reasons. | |
| 15:28:19 | zigo | And there's all sorts of issues because of this. :) | |
| 15:28:53 | zigo | Like, people trying to use whatever horizon plugin that I was packaging but they didn't, and it broke on Ubuntu, but they don't care because "it's not in main" ... | |
| 15:29:02 | zigo | The usual thing with Ubuntu... :) | |
| 15:29:28 | gmann | i thought policy-in-code was the time when we asked (or should) deployer to not to re-generate the complete policy file instead keep override rule only | |
| 15:29:49 | stephenfin | gmann: Yeah, I think that's the big disconnect here | |
| 15:30:19 | stephenfin | so doing different things for new installation/upgrade probably isn't an option | |
| 15:30:29 | stephenfin | an empty JSON is bad for users | |
| 15:31:09 | stephenfin | that leaves us with including a commented-out YAML, and modifying oslo-policy-generator to include deprecated rules, right? | |
| 15:31:12 | gmann | lbragstad: did you faced this issue for keystone also? newly generated file with new default only and old token broken as deprecated rule is disappeared | |
| 15:31:19 | stephenfin | fwiw, I really, really want to avoid the latter option :) | |
| 15:31:43 | gmann | stephenfin: true. | |
| 15:32:49 | gmann | later is kind of argument that people rely on 'no deprecated rule' in generated file to end up over permission and leak API | |
| 15:33:04 | zigo | stephenfin: This leaves us with "generate policy.json and nova.conf that are maching and working together by default" indeed ! | |
| 15:33:08 | gmann | so we may fix one upgrade but break other | |
| 15:35:13 | zigo | If I had such an option as "oslopolicy-sample-generator --use-scoped" and/or "--dont-use-scoped" then I would generate the config file twice, as a favor to Debian users, so they could see both ... | |
| 15:35:21 | openstackgerrit | Merged openstack/python-novaclient master: Remove future imports https://review.opendev.org/723153 | |
| 15:35:22 | zigo | It's probably too late in this cycle to do that, though. | |
| 15:36:40 | lbragstad | gmann isn't that the intended behavior you want? | |
| 15:38:04 | gmann | lbragstad: yeah, that is intended as per me :) but problem is for upgrade used to re-generated the fresh file and still think default works is broken | |
| 15:38:25 | gmann | zigo: we can do but still user need to change their script to add new option to that tool '--dont-use-scoped' or other. | |
| 15:38:36 | dansmith | gmann: lbragstad: to avoid me having to google.. what is the different thing that users have to do to get a scoped token? | |
| 15:39:29 | lbragstad | the request to keystone to get a token changes a bit, but users can invoke that with clients by setting a different property in their cloud config | |
| 15:40:10 | dansmith | okay so their openrc or clouds.yaml (or whatever) has to change | |
| 15:40:15 | lbragstad | yes | |
| 15:40:37 | dansmith | and are those two things getting generated as scoped by default nowadays? | |
| 15:41:03 | dansmith | or can you not ask for scoped until something else changes? | |
| 15:41:28 | lbragstad | i guess it depends on what generates those files | |
| 15:41:49 | lbragstad | you're asking if openrc or clouds.yaml is generated with project-scope by default? | |
| 15:43:55 | dansmith | lbragstad: yeah, like.. has everyone since stein (as an example) been getting scoped tokens and not knowing it? | |
| 15:44:06 | dansmith | just trying to figure out how impactful the move to requiring them will be | |
| 15:44:59 | lbragstad | dansmith yeah - to do anything useful, most people will need a scoped token of some form | |
| 15:45:17 | lbragstad | historically, that scope has always been project | |
| 15:45:42 | lbragstad | or - project-scope has been the standard for getting anything done, like booting a server | |
| 15:46:01 | dansmith | I'm confused | |
| 15:46:28 | dansmith | lbragstad: I thought that when we move to this new scoped policy that users need to be getting scoped tokens that they likely haven't been getting in the past? | |
| 15:46:41 | dansmith | which is why zigo's token immediately stopped working and launched us into this discussion | |
| 15:46:42 | lbragstad | dansmith sorry - let me back up | |
| 15:47:08 | lbragstad | keystone has supported scoped tokens for a long time - uses have always been able to get a scoped token | |
| 15:47:20 | lbragstad | in the past, that token has always been scoped to a project | |
| 15:47:22 | dansmith | sure, I get that | |
| 15:47:30 | lbragstad | the new system is using a different scope target | |
| 15:47:54 | lbragstad | and some APIs are going to require that new target, instead of a project-scoped tokne | |
| 15:48:12 | lbragstad | which is why zigo's old token (which i'm assuming is project-scoped) stopped workin | |
| 15:48:15 | lbragstad | working* | |
| 15:48:33 | zigo | If we require everyone to change something in their openrc, it *will* break a lot of user who wont understand. | |
| 15:48:33 | zigo | Maybe that's needed, I don't even understand what this scope thingy is for, but just warning everyone here. | |
| 15:48:33 | zigo | At least, if we're moving to that direction, then we must have some kind of correct error message output in the clients. | |
| 15:48:34 | gmann | but 'system' scope is not default user has to explicit request that | |
| 15:49:18 | dansmith | I'm trying to figure out if realistically everyone is going to need to change their openrc, or only people who got their openrc from horizon before some release, or ... | |
| 15:49:34 | dansmith | I know openrc can come from various places, but trying to figure out the "scope" of the impact | |
| 15:49:43 | dansmith | does devstack generate scope-having openrcs? | |
| 15:49:55 | lbragstad | yes | |
| 15:50:09 | zigo | lbragstad: What does it look like? | |
| 15:50:15 | zigo | export OS_SCOPE= ? | |
| 15:50:16 | lbragstad | it does it with clouds.yaml, actually | |
| 15:50:51 | lbragstad | https://opendev.org/openstack/devstack/src/branch/master/tools/update_clouds_yaml.py#L56 | |
| 15:51:04 | lbragstad | export OS_SYSTEM_SCOPE=all | |
| 15:51:30 | lbragstad | that's going to tell keystone to give you a system-scoped token instead of a project-scoped token | |
| 15:51:52 | zigo | lbragstad: So, that's to be added to the admin openrc ? | |
| 15:52:02 | dansmith | but most users want a project scoped token right? | |
| 15:52:05 | lbragstad | to get back to your impact question - changes to openrc are primarly admin related | |
| 15:52:08 | lbragstad | dansmith yes | |
| 15:52:22 | dansmith | lbragstad: ah, okay so admins need to tweak their openrc bug regular users will not? | |
| 15:52:33 | lbragstad | people who aren't accessing system-level APIs shouldn't need to set this new value and get system-scoped tokens | |
| 15:52:44 | gmann | true. otherwise it might be over permission issue for rule changed from admin->system-reader etc | |
| 15:53:01 | lbragstad | yes - for the most part | |
| 15:53:36 | dansmith | okay that wasn't clear to me before, so that's good news | |
| 15:53:44 | dansmith | zigo: I guess you were using an admin user? | |
| 15:54:07 | zigo | dansmith: not only myself, but puppet-openstack too, yeah ! | |
| 15:54:09 | openstackgerrit | Merged openstack/nova stable/ussuri: Update .gitreview for stable/ussuri https://review.opendev.org/722518 | |
| 15:54:15 | openstackgerrit | Merged openstack/nova stable/ussuri: Update TOX_CONSTRAINTS_FILE for stable/ussuri https://review.opendev.org/722520 | |
| 15:54:38 | zigo | dansmith: What first started breaking was puppet-octavia that couldn't create the Octavia flavor. | |
| 15:54:39 | dansmith | okay | |
| 15:54:54 | zigo | Then I tried as the admin user, and didn't understand what was going on... | |
| 15:55:13 | lbragstad | fwiw - we describe the concept and motivation behind all the scopes here - https://docs.openstack.org/keystone/latest/contributor/services.html#authorization-scopes | |
| 15:55:29 | zigo | lbragstad: Thanks, I'll read it all. | |
| 15:56:05 | dansmith | lbragstad: yeah I read that and I get it, | |
| 15:56:15 | dansmith | I thought there would still be a change to the user mechanics though | |
| 15:56:28 | dansmith | but likely because most of our discussions focus on our usage, which is generally admin | |
| 15:57:07 | lbragstad | dansmith unfortunately, because policy is completely configuration based, there could be deployments where this gets messy because the deployer wanted to let end users list hypervisors (or something weird like that) | |
| 15:58:06 | dansmith | yeah, so those users will need to learn something different now right? | |
| 15:58:23 | dansmith | does that mean they've lost (or will lose) the ability to list hypervisors and their instances with a single token? | |
| 15:58:59 | lbragstad | possibly - but it depends on how the deployer setup their custom policy | |
| 15:59:04 | dansmith | because I can imagine that sucking for scripts | |
| 15:59:13 | lbragstad | yeah - i completely agree | |
| 15:59:25 | gmann | yeah if both policy are override for same permission then they keep working | |
| 16:00:03 | gmann | if mix like one override and one was relying on default, now re-generated file will mesh up the single token | |
| 16:02:16 | lbragstad | zigo i typically put system users behind a different cloud profile, so i set system_scope: all in my clouds.yaml under a different name | |
| 16:02:50 | lbragstad | then i use --os-cloud system-admin or --os-cloud project-user (or whatever) | |
| 16:03:26 | lbragstad | ymmv - but if found that useful in the past when managing different scopes | |
| 16:03:32 | lbragstad | i found* | |
| 16:03:58 | dansmith | problem is, kinda, that we're enforcing our view on what is system-level information now in a way that they can't override | |