Earlier  
Posted Nick Remark
#openstack-nova - 2020-04-27
09:56:31 zigo Not great ... :(
10:03:45 gibi I don't have any policy.json for nova in devstack
10:04:35 gibi do you have a stacktrace for the above HTTP 500?
10:21:07 gibi lyarwood: thanks for the stable/stein release proposal, I'm +1, when you have time, could you hit https://review.opendev.org/#/q/topic:create-ussuri+(status:open+OR+status:merged)+project:openstack/nova ?
11:04:40 frickler zigo: your command confuses me, do you have other options set via environment? setting some project option will override system-scope without a warning. make sure that with "token issue" you see a system scoped token, not project or domain
11:04:53 zigo Yes I do ! :)
11:05:17 zigo Ok, will try.
11:05:51 zigo I've restarted a cluster deployment from scratch, to see if Ussuri can be setup fully automatically again with my system, so can't try right now...
11:06:00 zigo Later this afternoon.
11:25:16 frickler zigo: fyi, I don't get your error by default in devstack, but I do get it if I add "[oslo_policy] enforce_scope = True" into nova.conf. in that case, creating a flavor only works with system scope
11:46:06 openstack Launchpad bug 1875287 in OpenStack Compute (nova) "VM unshelve failed if verify_glance_signatures enabled" [Undecided,Incomplete] - Assigned to Andrey Volkov (avolkov)
11:46:06 gibi avolkov: hi! I asked for some clarification in https://bugs.launchpad.net/nova/+bug/1875287
11:55:12 AJaeger stephenfin: is this what you wanted as babel cleanup: https://review.opendev.org/#/c/723206/2 ?
12:00:14 gibi bauzas: triaged the fresh bugs, nothing noteworthy so far. I'm releasing the (silently) held bug lock for the afternoon
12:05:06 nightmare_unreal can someone review this if they grt time : https://review.opendev.org/#/c/715395/
12:05:10 nightmare_unreal thanks
12:09:13 avolkov gibi: hi, updated. if possible please leave your opinion what should we do with that
12:11:59 gibi avolkov: thanks make more sense now
12:12:40 stephenfin AJaeger: Oh, so we don't need the babel.cfg file either?
12:16:47 gibi avolkov: do you agree that this bug is not a recent regression, it seems that we have the issue at least since rocky
12:16:53 gibi ?
12:20:56 gibi avolkov: in the meantime I confirmed the bug as I was able to reproduce it
12:31:37 AJaeger stephenfin: it's referenced from setup.cfg
12:31:50 AJaeger stephenfin: I don't think we need it, I checked locally with it removed
12:33:32 AJaeger stephenfin: I answered on the review
12:34:24 stephenfin AJaeger: Sweet, thanks
12:54:22 avolkov gibi: seems not a regression, I believe it was introduced with that verify_glance_signatures (mitaka?) or maybe with some refactoring further, it's definitely not urgent
12:54:40 gibi avolkov: thanks.
12:55:32 AJaeger any other nova core for two tiny cleanups, please? https://review.opendev.org/#/c/723206/2 and https://review.opendev.org/#/c/720725/1 ?
13:00:45 brinzhang_ AJeager:is this necessary? https://review.opendev.org/#/c/723295/
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)

Earlier   Later