| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-04-27 | |||
| 15:17:30 | dansmith | the yaml is better in every respect, except for compatibility | |
| 15:17:33 | gmann | https://github.com/openstack/nova/blob/347d656c35fdf0c309039a7c1f352f82c6950868/nova/policies/base.py#L36 | |
| 15:17:38 | stephenfin | yaml++ | |
| 15:17:47 | bnemec | gmann: Why? Isn't the scope check built-in to the policy enough? | |
| 15:17:52 | zigo | stephenfin: Looks like you're right yeah. | |
| 15:18:07 | gibi | dansmith: I need to read back after my current call | |
| 15:18:20 | gmann | bnemec: when enforce_scope is true then yes otherwise we need to differentiate the system vs project - https://github.com/openstack/nova/blob/347d656c35fdf0c309039a7c1f352f82c6950868/nova/policies/base.py#L36 | |
| 15:18:24 | zigo | stephenfin: How would we make oslo-generate-policy to use non-scoped policies then? | |
| 15:18:26 | dansmith | gibi: definitely needs your review | |
| 15:18:50 | bnemec | That seems like it's completely defeating the purpose of enforce_scope. | |
| 15:18:57 | stephenfin | zigo: not sure you want to do that | |
| 15:19:07 | stephenfin | you'd be generated deprecated configuration | |
| 15:19:11 | stephenfin | *generating | |
| 15:19:22 | dansmith | stephenfin: the deprecated form is supposed to be the default we assume if no policy file | |
| 15:19:34 | zigo | stephenfin: If nova.conf defaults to non-scoped, but policy.json to scoped, then we do have a problem. | |
| 15:19:41 | zigo | Choose your side comrade ! :) | |
| 15:20:07 | gmann | zigo: yeah, agree. | |
| 15:20:27 | stephenfin | dansmith: Yes, because we care about upgrades. New deployments would ideally be overriding nova's defaults though | |
| 15:20:41 | stephenfin | zigo: I assume there's no way to distinguish between new installs and upgrades? | |
| 15:20:47 | dansmith | stephenfin: he generates those for upgrades too he just said | |
| 15:20:59 | zigo | stephenfin: There is, if you're talking about packaging. | |
| 15:21:06 | stephenfin | I am | |
| 15:21:08 | dansmith | stephenfin: and, unless we default the enforce_scope on, and detail the differences between scoped tokens for users of new deployments, it's not that cut and dried | |
| 15:21:18 | zigo | That's an argument given to the .postinst script of the package. | |
| 15:22:18 | stephenfin | dansmith: it sounds like we can do that for a new installation (default enforce_scope to on) | |
| 15:22:18 | zigo | It's defined here: https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#summary-of-ways-maintainer-scripts-are-called | |
| 15:22:36 | dansmith | stephenfin: we don't now though, AFAIK | |
| 15:22:57 | stephenfin | we wouldn't do it - the package would | |
| 15:23:04 | stephenfin | it would override the nova default | |
| 15:23:06 | zigo | I'd very much you give operators at least one more cycle to enforce this. | |
| 15:23:32 | zigo | Then just set enforce_scope to True by default in Victoria ... | |
| 15:23:52 | stephenfin | zigo: I'd like to know if the following combination is possible/makes sense | |
| 15:23:54 | dansmith | stephenfin: not sure how you could coordinate that across every deployment tool | |
| 15:24:25 | stephenfin | new installation: enforce_scope = True (override), use Ussuri policy.json | |
| 15:24:43 | stephenfin | upgrade: enforce_scope = False (nova default), use Train policy.json | |
| 15:24:44 | stephenfin | ? | |
| 15:25:06 | stephenfin | dansmith: we do that kind of stuff in TripleO, albeit higher than the package level | |
| 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 | |