| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-04-27 | |||
| 13:00:54 | brinzhang_ | if not, I will abandon it | |
| 13:08:56 | openstackgerrit | Merged openstack/python-novaclient master: doc: Update Testing document https://review.opendev.org/723078 | |
| 13:18:41 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Use compression by default for 'SshDriver' https://review.opendev.org/684393 | |
| 13:25:24 | stephenfin | sean-k-mooney: can you bump your vote on https://review.opendev.org/#/c/716223/ now? | |
| 13:27:48 | sean-k-mooney | stephenfin: yes i guess so did rc 1 go out on thursday | |
| 13:28:07 | stephenfin | sure did | |
| 13:28:14 | sean-k-mooney | cool +w | |
| 13:28:24 | stephenfin | ta | |
| 13:39:46 | gmann | nightmare_unreal: lyarwood yeah there was some window when grenade job merge and one more fix. now it is all green | |
| 13:40:24 | nightmare_unreal | yeah I just did recheck :) thanks | |
| 13:46:37 | gmann | zigo: hi, was that policy overridden ? that mentioned patch fixed the bug of passing the context project_id itself so that it is not allowed for all. | |
| 13:47:35 | zigo | gmann: The /etc/nova/policy.json file is the pristine one generated by the package (well, oslopolicy, this means). | |
| 13:48:16 | gmann | zigo: ok, can you paste that policy line for flavor manage ? | |
| 13:48:34 | AJaeger | brinzhang_: It's not necessary | |
| 13:49:38 | zigo | gmann: "os_compute_api:os-flavor-extra-specs:create": "rule:system_admin_api" | |
| 13:50:08 | zigo | "system_admin_api": "role:admin and system_scope:all" | |
| 13:50:08 | zigo | On top of the file, there is: | |
| 13:50:09 | gmann | zigo: ok, and 'system_admin_api' rule ? | |
| 13:50:56 | gmann | humm there should be deprecated rule of old RULE_ADMIN_API that is what we have as default | |
| 13:51:57 | gmann | but you said you generated the file via oslo policy tool right? it is oslopolicy-sample-generator correct | |
| 13:52:08 | zigo | Right ! | |
| 13:52:55 | zigo | https://salsa.debian.org/openstack-team/services/nova/-/blob/debian/ussuri/debian/rules#L64 | |
| 13:52:55 | zigo | gmann: That's what I did: | |
| 13:53:14 | zigo | (later, the postinst of the package takes that file from nova-common and puts it in /etc/nova) | |
| 13:53:36 | zigo | Hum... not even ... | |
| 13:53:45 | zigo | Directly pacakged into /etc/nova | |
| 13:54:11 | zigo | I should do the former, to have the file owned by root:nova / 640 though ... | |
| 13:56:45 | gmann | zigo: let me check if that tool adding the default rule or not. | |
| 13:59:25 | zigo | gmann: I've sent the generated policy.json file to our swift cluster if you want to look at it: https://www.swisstransfer.com/d/b80904d3-1f15-4f1f-98f0-7e1db308bb53 | |
| 14:13:59 | openstackgerrit | Kevin Zhao proposed openstack/nova master: [WIP] CI: add tempest-integrated-compute-aarch64 job https://review.opendev.org/714439 | |
| 14:14:40 | gmann | zigo: got it. that tool does not add the deprecated rules in sample file. | |
| 14:15:10 | zigo | gmann: And that's the issue ?!? | |
| 14:15:22 | gmann | zigo: expectation is you keep only override rule in the policy file and other rule let it rely on defaults | |
| 14:15:49 | zigo | Right. | |
| 14:15:51 | gmann | zigo: not issue i think. because you are providing the file with rule override with new defaults | |
| 14:16:55 | gmann | if you generate the file with that tool you get all the rule commented and you are supposed to un-comment the one you want to override. | |
| 14:17:34 | gmann | here what happen, nova get the rule in file and skip the default value with consideration that rule in file is what operator want | |
| 14:18:12 | gmann | if you remove the rules from file which you want to reply on defaults then your old token will keep working. | |
| 14:23:31 | gmann | zigo: also if rule is present in file then oslo skip deprecated rule to add. and I hope you generated file before nova start which initialize the policy | |
| 14:29:42 | zigo | [pid: 1708|app: 0|req: 10/40] 192.168.101.2 () {32 vars in 628 bytes} [Mon Apr 27 14:29:08 2020] GET /v2.1/flavors/detail => generated 128 bytes in 91 msecs (HTTP/1.1 500) 3 headers in 215 bytes | |
| 14:29:42 | zigo | gmann: If I remove the policy.json, then I get an error 500: | |
| 14:29:47 | zigo | Nothing more in the logs ... | |
| 14:32:48 | zigo | gmann: The file needs to exist, though if it's empty, it looks like working ! :) | |
| 14:32:56 | zigo | gmann: Should I keep an empty file then?!? | |
| 14:33:22 | zigo | IMO this is still a bug, because operators need to see what's currently in the policy, and can't guess the defaults. | |
| 14:33:46 | zigo | I do want to provide such a policy file if possible. | |
| 14:33:59 | zigo | gmann: An empty policy.json is safe, right? | |
| 14:34:00 | dansmith | if operators currently have to do anything to their policy file during an upgrade, then we have a real problem | |
| 14:34:28 | dansmith | zigo: AFAIK, the policy file should be empty to take all the defaults, but I'm surprised it has to be present-but-empty.. not sure if that is new or not | |
| 14:34:52 | zigo | dansmith: I expect operators to use /etc/nova/policy.d, and I thought about explicitly shipping such a folder in the Nova Debian package. | |
| 14:35:17 | zigo | As much as I can tell, this is a new bug ! :P | |
| 14:35:25 | zigo | (would have to check Train though...) | |
| 14:35:27 | dansmith | zigo: and thus have no files in there nor an empty base file right? | |
| 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 | |