| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-04-27 | |||
| 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. | |
| 15:01:42 | dansmith | zigo: yup | |
| 15:01:42 | gmann | as per my expectation, 'generate-then-tweak ' case also need operator review if something auto-re-generated is ok or not | |
| 15:01:57 | dansmith | gmann: not if they don't know they need to review | |
| 15:02:07 | dansmith | gmann: they could have been doing this approach for years with no problem | |
| 15:02:12 | gmann | humm | |
| 15:02:12 | bnemec | Is this on a fresh install? If so, why isn't everything configured to handle the new policies? | |
| 15:02:28 | dansmith | bnemec: no, not necessarily fresh deploy | |
| 15:02:34 | zigo | I very much agree that it's the operator's responsibility to refresh the policy.json and re-tweak it carefully on each upgrade. | |
| 15:02:43 | gmann | dansmith: they had same problem when policy was deprecated. here we did all policy changed instead of one or two | |
| 15:03:19 | dansmith | gmann: you mean when the full policy file was deprecated? | |
| 15:03:20 | bnemec | I mean, that deployment method hasn't been recommended since policy in code went in however many years ago. | |
| 15:03:29 | dansmith | AFAIK, plenty of people never migrated to empty policy files | |
| 15:03:37 | zigo | bnemec: On a *fresh* install, with the currently default generated policy.json, things a broken. That's the issue I've reported to begin with! :) | |
| 15:03:52 | dansmith | bnemec: but not everyone likes that, and distros still generate full policy files, which is why we're here | |
| 15:04:01 | gmann | dansmith: for example, single policy was changed in some cycle. | |
| 15:04:20 | bnemec | So that's a problem anyway. Ussuri installs should be configured correctly to handle the new policy. | |
| 15:04:31 | dansmith | gmann: which is why it's quite likely that people's deployment scripts moved to generate-and-tweak.. like, generate and then sed, sed, sed | |
| 15:04:38 | bnemec | Even if we include the deprecated rules in the generated policy, it just pushes the breakage off one release. | |
| 15:04:56 | gmann | i mean that was always problem in past also. | |
| 15:05:04 | dansmith | bnemec: but it involves a change in user behavior right? | |
| 15:05:05 | dansmith | they have to now get scoped tokens? | |
| 15:05:14 | bnemec | Once the deprecated rule is dropped in the subsequent release you break then instead of now. | |
| 15:05:34 | bnemec | I think that's only true if enforce_scope is true. | |
| 15:05:41 | gmann | true, scope token in this case and changed in admin->non-admin etc in past | |
| 15:05:53 | dansmith | but that's the whole reason we're here, because zigo is taking all the defaults, and it's broken | |
| 15:06:02 | dansmith | bnemec: ^ | |
| 15:06:25 | gmann | 'taking all the defaults' not default but only new default without deprecated things. | |
| 15:06:44 | gmann | 'default' still mean 'new + old' | |
| 15:07:17 | dansmith | gmann: sorry I don't understand those two comments | |
| 15:07:25 | zigo | Bug filled: https://bugs.launchpad.net/nova/+bug/1875418 | |
| 15:07:25 | openstack | Launchpad bug 1875418 in OpenStack Compute (nova) "Generated policy.json in Ussuri is broken by default" [Undecided,New] | |
| 15:07:31 | stephenfin | zigo: why can't we just stop including a generated policy file in the package? | |
| 15:07:49 | dansmith | he can, he said that | |
| 15:07:50 | zigo | stephenfin: How are operators supposed to double-guess what they can use? | |
| 15:07:55 | gmann | dansmith: i mean current defaults are "new default + old deprecated defaults" and file generated was half bald with 'new defaults' only | |
| 15:08:21 | zigo | stephenfin: That's actually exactly what I'll be doing: provide an empty policy.json. But that's really not user friendly. | |
| 15:08:29 | stephenfin | zigo: You have a openstack-nova-doc package, yeah? It's documented in there | |
| 15:08:41 | zigo | stephenfin: I'd very much prefer having a policy.json that reflects what's currently enforced in Nova. | |
| 15:08:46 | gmann | i might be wrong but re-generating the policy file is something you are intentionally changing so adopt all change instead of half | |
| 15:08:53 | dansmith | stephenfin: he's saying that's a sucky user experience, and he's right despite how clean it seems to us | |
| 15:10:13 | dansmith | gmann: before this, generating the file and tweaking the rules you want ended up with all things at the same generation. If you tweaked a rule that we removed, then sure it's broken, but now people will be introducing old "syntax" to a generated file of new "syntax", and also not realize that as soon as they generate the file, they need scoped tokens right? | |
| 15:10:13 | gmann | and this is always a problem from starting if deployer rely on re-generated file which does not include the deprecated-but-supported rule | |
| 15:10:16 | zigo | stephenfin: Just did that and uploaded the package: https://salsa.debian.org/openstack-team/services/nova/-/commit/48bc8889ae8a787104b76e95c3e1dfc5893d146b | |
| 15:11:20 | zigo | Though really, that's really not user friendly to do that. | |
| 15:11:24 | gmann | dansmith: right. | |
| 15:11:51 | dansmith | gmann: so another question.. if I don't take the generated file, continue to run with the deprecated defaults, but need to tweak something.. how do I see the generated old defaults file? is there a flag to the tool? or do I have to look at train docs? | |
| 15:11:59 | gmann | but how to fix all those script to generate file, we can do something on oslopolicy-sample-generator | |
| 15:12:11 | stephenfin | zigo: Forgive me but is that not the normal way config files work? They're used for overrides, not defaults | |
| 15:12:51 | dansmith | stephenfin: but they're usually fully commented-out so you can see all the options in place while you're overriding | |
| 15:12:54 | zigo | stephenfin: If I'm listening to you, then my Nova package should ship an empty /etc/nova/nova.conf? Are you serious ?!? | |
| 15:13:02 | zigo | :) | |
| 15:13:06 | gmann | dansmith: train doc, or nova policy reference file. | |
| 15:13:16 | dansmith | gmann: that sucks | |
| 15:13:30 | gmann | yeah, tool is not adding them | |
| 15:13:43 | zigo | I think I'll give another try with the yaml thing, see if that works, and if I can ship a fully commented out one. | |
| 15:14:10 | zigo | That's still not nice, because it'd be supposed to work if all comments get removed ... If you know what I mean. | |
| 15:14:13 | dansmith | zigo: do you treat policy like config or what? what if they've modified their policy file? | |
| 15:14:20 | stephenfin | zigo: Not empty, but IMO we shouldn't be including values with defaults ¯\_(ツ)_/¯ | |
| 15:14:25 | zigo | Just same as in for nova.conf, where commented out stuff are supposed to be the default. | |
| 15:14:37 | stephenfin | I mean, that's how other config files works | |
| 15:14:42 | dansmith | stephenfin: that's the developer-focused "look at how clean this is" approach, but it sucks for admins | |
| 15:14:57 | stephenfin | znc.conf jumps to mind, since I was hacking on over the weekend | |
| 15:15:04 | stephenfin | ditto for sssd.conf | |
| 15:15:09 | stephenfin | or krb5.conf | |
| 15:15:11 | zigo | dansmith: For most packages, I don't have them as CONFFILES (these files, marked by dpkg as "prompt user if there's a change on upgrade...). | |
| 15:15:30 | gmann | stephenfin: if oslopolicy-sample-generator add complete default (new + deprecated) then config case is same otherwise it is issue | |
| 15:15:55 | stephenfin | dansmith: yeah, maybe. I just figured everyone was doing 'man [app].conf' | |
| 15:15:57 | zigo | So policy.json files live in /usr/share/FOO-common/policy.json and are copied to /etc/FOO only if /etc/FOO doesn't have a policy.json file. | |
| 15:16:05 | bnemec | I'm still confused why this would be failing on scope. enforce_scope is false by default. | |
| 15:16:06 | zigo | This way, no prompt on upgrade, and the old version is kept. | |
| 15:16:16 | zigo | Except I didn't do that for Nova, I don't know why ... | |
| 15:16:29 | zigo | So in the Nova case, /etc/nova/policy.json *IS* a CONFFILE. | |
| 15:16:34 | gmann | bnemec: we have 'system:all' string in check_str for new defaults of system scope role | |
| 15:16:42 | dansmith | gmann: so it sounds like we need a big warning reno about this at the very least | |
| 15:16:45 | zigo | (and then dpkg will prompt on upgrade if there's some diff) | |
| 15:17:04 | dansmith | gmann: we probably also should switch to yaml by default, and make sure our CI jobs are using them that way | |
| 15:17:21 | gmann | bnemec: https://github.com/openstack/nova/blob/347d656c35fdf0c309039a7c1f352f82c6950868/nova/policies/base.py#L104 | |
| 15:17:22 | stephenfin | bnemec: I suspect the oslo-generate-policy command is using the scoped policies, but nova is still defaulting to non-scoped (to avoid breaking upgrades, funnily enough) | |
| 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 | |