| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-04-27 | |||
| 14:36:29 | zigo | dansmith: What would happen if a rule is defined in both /etc/nova/policy.json and /etc/nova/policy.d/foo-operator.json ? | |
| 14:36:41 | zigo | Will the policy.d have priority? | |
| 14:36:49 | dansmith | no idea.. I didn't know we had a policy.d, tbh | |
| 14:36:54 | zigo | Beause that'd be the most convenient way for everyone. | |
| 14:37:13 | zigo | We do need a way to tell operators what they can and cannot write in their config. | |
| 14:37:20 | dansmith | but I would expect a distro to install an empty policy.d directory, and not have to write an empty base policy file to avoid a 500 | |
| 14:38:07 | zigo | dansmith: What I'm going to do is to write an empty policy.json (to avoid what I consider a bug), ship the generated policy.json in /usr/share/nova-common as an example, and create the policy.d folder. | |
| 14:38:30 | zigo | I still think it's wrong that I can't use the generated policy.json though... | |
| 14:38:42 | dansmith | zigo: ack, but if the behavior is changed, we need a bug filed | |
| 14:39:14 | zigo | It really is changed. I use to ship the /etc/nova/policy.json on all of my Nova packages, and so far, it wasn't a problem. | |
| 14:39:15 | dansmith | zigo: well, we're trying to get people to have overrides and not hard-coded everything, but I understand.. what prevents you from using the generated file? deprecation warnings? | |
| 14:39:44 | zigo | It simply does *not* work. | |
| 14:39:56 | gmann | dansmith: zigo file generated from tool is kind of override rule. default only work if rule not in file | |
| 14:40:33 | dansmith | zigo: but why is the generated file not working? | |
| 14:41:03 | gmann | zigo: did that worked for any deprecated rule for you, if you rule in file the if any rule deprecated in fast had same issue itthunk | |
| 14:41:45 | zigo | root@C1-z-controller-1>_ ~ # openstack flavor create --ram 12288 --disk 10 --vcpus 4 cpu4-ram12-disk10 | |
| 14:41:46 | zigo | Policy doesn't allow os_compute_api:os-flavor-manage:create to be performed. (HTTP 403) (Request-ID: req-7f1c4c5b-8df2-4ef7-8a88-8f2cae1899f1) | |
| 14:41:48 | zigo | dansmith: ^ | |
| 14:42:15 | zigo | That's with the default policy.json file as per https://salsa.debian.org/openstack-team/services/nova/-/blob/debian/ussuri/debian/rules#L64 ... | |
| 14:42:24 | dansmith | I don't know why that would be, although I'm not very familiar with policy stuff | |
| 14:42:36 | dansmith | if that's the case, however, we've broken upgrade which we have to fix | |
| 14:43:00 | gmann | dansmith: generated file from oslo tool does not add the deprecated rule so nova consider those rule as override rule and only new token pass | |
| 14:43:24 | dansmith | gmann: same would go for any existing overrides the deployer has then? | |
| 14:43:29 | gmann | dansmith: if no file and rely on default then there is no cange | |
| 14:43:30 | gmann | change | |
| 14:43:50 | gmann | dansmith: if they have override all the rules then yes as they do not rely on default. | |
| 14:44:16 | gmann | oslo does not add deprecated rule if they are present in file. | |
| 14:44:22 | dansmith | gmann: the we broke upgrade for anyone using a distro's generated file from <=Ussuri right? | |
| 14:45:08 | dansmith | I'm not sure what "override all the rules" has to do with this, or why it's different than "override one rule" | |
| 14:45:13 | gmann | dansmith: "distro's generated file" is something i doubt that it is correct way or not. it is same issue they had in all the previous changed policy | |
| 14:45:40 | dansmith | gmann: doubt what is correct? | |
| 14:45:41 | zigo | dansmith: Correct ! :) | |
| 14:45:54 | gmann | dansmith: in case of "override one rule" other rule should not be in file. if they are then oslo cannot add deprecated rule | |
| 14:46:23 | dansmith | gmann: I don't understand what you're saying | |
| 14:46:31 | zigo | Also, how are operators supposed to double-guess what's currently in place, if I can't, as a package maintainer, generate what's currently in? | |
| 14:46:43 | dansmith | if they have one override in their file, everything is fine, but if they override all the rules then ...broken? | |
| 14:47:13 | zigo | If I understand correctly, the issue is to not show what's deprecated in the policy. Well, can't we simply add an option to the generator, so it also adds the deprecated things? | |
| 14:47:22 | gmann | dansmith: if they override one of all rule then rules with changed default will consider only override value not default right | |
| 14:47:31 | dansmith | zigo: presumably they look at the /usr/share version and add what they want into their file, but I think ideally we'd want a file fully commented-out where things can be uncommented and changed, but our json format probably doesn't allow that | |
| 14:47:58 | gmann | yeah, that ^^ | |
| 14:48:18 | zigo | dansmith: As much as I know, there's no way to add comments in a .json file. | |
| 14:48:21 | zigo | Indeed. | |
| 14:48:29 | dansmith | gmann: but I think zigo is saying that debian has taken the more user-friendly approach of just putting the generated file in place, and letting them alter it in-place | |
| 14:48:40 | gmann | hummm | |
| 14:48:48 | dansmith | zigo: right, it's frustrating, so I understand why the debian packages are the way they are | |
| 14:48:49 | zigo | dansmith: Exactly what I was doing so far ! :) | |
| 14:48:59 | dansmith | zigo: I'm sure you're not the only one | |
| 14:49:01 | gmann | because oslo tool generate the rule with all commented | |
| 14:49:03 | openstackgerrit | Stephen Finucane proposed openstack/nova master: objects: Add MigrationTypeField https://review.opendev.org/706013 | |
| 14:49:03 | openstackgerrit | Stephen Finucane proposed openstack/nova master: objects: Remove 'NovaObjectDictCompat' from 'Migration' https://review.opendev.org/723572 | |
| 14:49:04 | openstackgerrit | Stephen Finucane proposed openstack/nova master: objects: Remove 'NovaObjectDictCompat' from 'InstancePCIRequest' https://review.opendev.org/723573 | |
| 14:49:05 | openstackgerrit | Artom Lifshitz proposed openstack/nova stable/stein: DNM: Add a placement audit command https://review.opendev.org/720839 | |
| 14:49:17 | dansmith | I would not be surprised if people generating their own packages or installing from pip do the same for audit reasons | |
| 14:49:37 | dansmith | gmann: does it? how do you comment in json? | |
| 14:50:01 | beekneemech | It uses YAML. | |
| 14:50:25 | zigo | bnemec: As much as I know, there's no way to get services to load .yaml files, is there? | |
| 14:50:42 | bnemec | zigo: Yes, YAML works fine. | |
| 14:50:44 | zigo | Unless this has changed recently ... | |
| 14:50:47 | gmann | ah its yaml generated - https://docs.openstack.org/nova/latest/configuration/sample-policy.html | |
| 14:50:50 | dansmith | I've never seen it deployed in yaml file on a real system | |
| 14:50:51 | bnemec | I think the default is still JSON though. | |
| 14:51:11 | bnemec | IIRC, some service actually overrides that default so they get YAML by default. | |
| 14:51:13 | zigo | bnemec: Last time I tried, maybe 2 or 3 releases ago, it didn't work. | |
| 14:51:31 | zigo | Commented yaml would work for me. | |
| 14:51:44 | dansmith | zigo: except we can't require people to convert that as part of an upgrade | |
| 14:51:51 | bnemec | It's always possible there's a bug. YAML is definitely supposed to work. | |
| 14:52:03 | dansmith | bnemec: do any CI jobs use yaml? | |
| 14:53:10 | gmann | one things we can do is always add deprecated rule from oslopolicy-sample-generator | |
| 14:53:22 | dansmith | just checked one I had handy and the only service with a policy file is neutron, and it's json | |
| 14:53:38 | dansmith | gmann: but ... people with existing policy files can't be broken by this upgrade | |
| 14:53:42 | openstackgerrit | Artom Lifshitz proposed openstack/nova stable/rocky: DNM: Add a placement audit command https://review.opendev.org/720842 | |
| 14:53:56 | gmann | but again not all people use this or some other way to generate file like editing the old file | |
| 14:54:52 | gmann | dansmith: true, existing policy should not break, here zigo case is it get generated newly with oslo tool which had new defaults but not deprecated | |
| 14:55:23 | dansmith | gmann: I'm still trying to understand if people with a train-generated full policy file are going to be broken | |
| 14:55:30 | dansmith | I've not understood your answers there | |
| 14:55:31 | gmann | if it is not re-generated then old policy keep working in both case 1. they have override different rule 2. or reply on default even have rule in fule | |
| 14:55:40 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Modify PciDevice.uuid generation code https://review.opendev.org/530487 | |
| 14:55:40 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Add an online migration for PciDevice.uuid https://review.opendev.org/530905 | |
| 14:55:53 | nightmare_unreal | what can cause nova-live-migration zuul build to fail ?? | |
| 14:55:54 | gmann | dansmith: train generated file should keep working as it is. | |
| 14:56:53 | gmann | what happened here is, policy file is generated freshly which had new 'system rule' but token are not refreshed | |
| 14:57:01 | dansmith | gmann: what if someone's deploy script generates the file from the tooling, applies their two or three rule tweaks? then they're broken? | |
| 14:57:50 | dansmith | I see, the broken part is because the newly generated file will be rules that require scoped tokens or whatever? | |
| 14:57:57 | gmann | dansmith: and they have other rule with new value present in file then broken. and that is case that they have override the rule but token not refreshed | |
| 14:58:08 | gmann | dansmith: correct | |
| 14:58:25 | bnemec | Right. This is why the deprecated rule behavior ORs with the old rule. | |
| 14:58:29 | gmann | train policy will still have adimin_rule and keep working | |
| 14:58:45 | dansmith | gmann: okay, understand why train configs still work, which is good | |
| 14:59:04 | dansmith | gmann: I would expect the generate-then-tweak process is fairly widespread | |
| 14:59:32 | zigo | dansmith: Yes, "then they're broken" ... | |
| 14:59:35 | gmann | humm and generate with 'oslopolicy-sample-generator' tool right ? | |
| 14:59:40 | zigo | (ie: my case...) | |
| 14:59:49 | zigo | Which I think is really wrong. | |
| 15:00:11 | openstackgerrit | Stephen Finucane proposed openstack/nova master: objects: Add online migration for legacy NUMA objects https://review.opendev.org/537414 | |
| 15:00:15 | gmann | i mean we can explicitly add deprecated rule in that tool logic. but not sure if that solve all the cases | |
| 15:00:30 | dansmith | gmann: yes | |
| 15:00:49 | AJaeger | any nova core available for two tiny cleanups related to Babel/translations, please? https://review.opendev.org/#/c/723206/2 and https://review.opendev.org/#/c/720725/1 ? | |
| 15:00:55 | dansmith | I dunno what to do about this though, since it's really a problem spread across multiple projects, lots of code, and some human assumptions | |
| 15:01:13 | bnemec | We can't always do that though or there's no way for deployers to get the new rule alone. | |
| 15:01:30 | zigo | dansmith: I also expect the generated-then-not-touched case is also fairly widespread (my case in my CI) and it is broken as well currently. | |