| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-04-28 | |||
| 15:28:27 | dansmith | indeed :/ | |
| 15:29:19 | gibi | gmann: do you mean that use the new generated file and configure nova and keystone with scopes? | |
| 15:29:36 | gibi | gmann: I think that is a valid use case | |
| 15:29:43 | dansmith | we can't do that in the upgrade I think | |
| 15:29:55 | dansmith | because people with non-scoped current policy files will break | |
| 15:30:04 | gmann | yes. and in past also if we deprecate any policy rule and operator want to move to new defalt, policy overwrite is the option they had | |
| 15:30:06 | gibi | dansmith: true, not for the upgrade, but for the new deployments | |
| 15:30:23 | dansmith | gibi: only distros have the ability to do something different for upgrade vs. new I think | |
| 15:30:33 | dansmith | gibi: we the nova project have to assume upgrade | |
| 15:30:40 | gmann | yeah | |
| 15:30:59 | dansmith | I think what we can do is set up for the most default case, which is where we are now, and accept that the case where you're using the generation tool is going to break | |
| 15:31:12 | dansmith | it's likely common, but less common than all the other cases I think | |
| 15:32:05 | dansmith | accept, and document/warn about the potential problem I mean | |
| 15:32:29 | openstackgerrit | Merged openstack/nova stable/ussuri: Imported Translations from Zanata https://review.opendev.org/723160 | |
| 15:32:34 | gibi | OK, I see. thanks. I will summarize it in the bug | |
| 15:32:42 | gmann | dansmith: i agree it might be common to re-generate policy file and end up no deprecated rule but is not that wrong usage ? and some point we have to tell them its not right one | |
| 15:33:26 | dansmith | gmann: no, I don't think it's wrong.. it's not what we want people to do, but what we want them to do isn't very convenient or user-friendly, which is why I think it's likely common | |
| 15:33:48 | dansmith | gibi: also the other action item is to switch to yaml policy by default going forward I think, and encourage people to move to that | |
| 15:33:51 | gmann | and it is like it was not reported before when few policy default were changed. i am not sure if new default were superset of old so that same problem would occur | |
| 15:34:22 | gmann | dansmith: +1 on switch yaml. | |
| 15:34:30 | gmann | and this bug - https://bugs.launchpad.net/oslo.policy/+bug/1853170 | |
| 15:34:30 | openstack | Launchpad bug 1853170 in oslo.policy "Need documentation on recommended operator workflow for deprecated policies" [High,Triaged] | |
| 15:34:30 | gibi | dansmith: good point about yaml, adding that to the PTG etherpad | |
| 15:34:30 | dansmith | gmann: this we can all agree on :P | |
| 15:34:50 | gmann | we need some consistent usage guide also | |
| 15:35:10 | gmann | gibi: its there, in cross project section | |
| 15:35:24 | gibi | gmann: even the yaml usage? | |
| 15:36:08 | gmann | gibi: ah i thought it is written in description but i missed. please add | |
| 15:36:29 | gibi | done :) | |
| 15:36:34 | gmann | thanks | |
| 15:38:21 | gmann | dansmith: gibi new flag aded in ussuri (https://bugs.launchpad.net/nova/+bug/1875418) to switch to new default instead of overwriting the policy file can improve the usage at some extend. | |
| 15:38:21 | openstack | Launchpad bug 1875418 in OpenStack Compute (nova) "Generated policy.json in Ussuri is broken by default" [High,In progress] - Assigned to Ghanshyam Mann (ghanshyammann) | |
| 15:38:35 | gmann | sorry, this flag - 'oslo_policy.enforce_new_defaults' | |
| 15:39:22 | dansmith | gmann: this is separate from the full switch to only scoped policies right | |
| 15:39:23 | dansmith | ? | |
| 15:39:31 | gmann | dansmith: yes. | |
| 15:39:47 | dansmith | so, I think maybe we should just go ahead and shut the door in V on using the old stuff | |
| 15:40:12 | dansmith | because this is now a failure on the upgrade "policy" we should just hard pivot over to the new stuff in V, | |
| 15:40:21 | dansmith | apologize for the short notice, and move on | |
| 15:40:41 | dansmith | and maybe our U renos need to state that.. "might as well go ahead and convert in U to avoid this again in V" | |
| 15:41:10 | bauzas | gibi: others: procedural question but https://bugs.launchpad.net/nova/+bug/1875418 should have a ussuri-rc-candidate tag or not ? | |
| 15:41:10 | openstack | Launchpad bug 1875418 in OpenStack Compute (nova) "Generated policy.json in Ussuri is broken by default" [High,In progress] - Assigned to Ghanshyam Mann (ghanshyammann) | |
| 15:42:13 | gmann | dansmith: yeah mentioning V upgrade in reno is good idea. but removing old stuff in V might be difficult now as we have conveyed the old support till W in few wanrings and original reno | |
| 15:42:23 | gibi | bauzas: as far as I see we will keep the bug open after Ussuri so it should not be tagged | |
| 15:42:34 | dansmith | gmann: we still have time to correct those warnings though right? | |
| 15:43:45 | gmann | dansmith: humm, we can do and bakport. but i am thinking if that is too early for people not re-generating the file. i mean they need to adopt new scope token which is very new things. | |
| 15:43:48 | gibi | I've updated the policy bug with the current agreement above. I have to leave for today, will read back tomorrow | |
| 15:43:52 | bauzas | honestly, this bug scares me | |
| 15:44:24 | bauzas | couldn't we just tell that we won't support new policies until V ? | |
| 15:44:27 | dansmith | gmann: well, it just feels like extending this any longer than necessary is worse than concentrating al the pain | |
| 15:44:38 | dansmith | bauzas: we've already broken a set of users though, | |
| 15:44:44 | bauzas | chances are that operators wouldn't read relnotes | |
| 15:44:50 | bauzas | dansmith: :( | |
| 15:45:01 | dansmith | so I was going to say instead of breaking 25% of them now, and then 75% of them later, we should just get it over with | |
| 15:45:27 | bauzas | like, "take a pill, and suffer in silence" ? :) | |
| 15:45:35 | dansmith | or "rip off the bandage" | |
| 15:46:06 | bauzas | I guess we can't obviously make it a pre-upgrade check | |
| 15:46:12 | gmann | or we add the oslo guide on best handle the deprecated rule in file - https://bugs.launchpad.net/oslo.policy/+bug/1853170 | |
| 15:46:12 | openstack | Launchpad bug 1853170 in oslo.policy "Need documentation on recommended operator workflow for deprecated policies" [High,Triaged] | |
| 15:46:41 | bauzas | this would require us to write some Train patch and a release | |
| 15:47:07 | bauzas | but this would be nice, they'd get the warnings before upgrading to U | |
| 15:47:37 | dansmith | bauzas: we could definitely do some nova-status guessing, yeah | |
| 15:48:06 | dansmith | bauzas: not a train patch, a U patch.. nova-status from U helps warn about things from T->U | |
| 15:48:11 | bauzas | dansmith: but this would be a pre-Victoria check, right ? (unless we backport to Train the patch itself) | |
| 15:48:18 | openstackgerrit | Merged openstack/nova master: Switch to TOX_CONSTRAINTS_FILE https://review.opendev.org/722814 | |
| 15:48:25 | openstackgerrit | Merged openstack/nova master: Test multi create with vGPUs https://review.opendev.org/723858 | |
| 15:48:25 | bauzas | mmmm, amiwrong ? | |
| 15:48:27 | dansmith | bauzas: depends on which bit you're talking about warning for | |
| 15:48:33 | openstackgerrit | Merged openstack/nova master: Update contributor guide for Victoria https://review.opendev.org/722647 | |
| 15:48:41 | dansmith | bauzas: the stuff we're breaking in U would be a nova-status U patch to warn the T people | |
| 15:49:02 | bauzas | this would require a U install somewhere but okay | |
| 15:49:13 | dansmith | that's the way nova-status works | |
| 15:49:21 | bauzas | I'm then confused | |
| 15:49:29 | bauzas | then, it's all good | |
| 15:49:47 | bauzas | let's make it a nova-status upgrade check and yell something is wrong | |
| 15:50:04 | bauzas | double this with relnotes | |
| 15:50:11 | bauzas | and gosh saves the rest | |
| 15:50:33 | bauzas | gmann: ^ | |
| 15:51:12 | jsuchome | efried, bauzas, dansmith: Hi, could we please get https://review.opendev.org/#/c/572805/ reopen _again_ ? | |
| 15:51:16 | gmann | how we will differentiate the upgrade with re-generated file vs new deployment/upgrade moving to new system | |
| 15:51:30 | openstackgerrit | Stephen Finucane proposed openstack/nova master: objects: Add online migration for legacy NUMA objects https://review.opendev.org/537414 | |
| 15:51:38 | bauzas | gmann: greenfields don't run the nova-status check | |
| 15:52:12 | dansmith | ah, yeah I guess gmann has a point | |
| 15:52:34 | bauzas | make it a flag (c) | |
| 15:52:35 | efried | gmann: restored | |
| 15:53:02 | dansmith | jsuchome: are you going to work on it yourself? | |
| 15:53:50 | jsuchome | unless tobiash has time to pick it up ... | |
| 15:53:51 | stephenfin | artom: I switched that to startswith which is as optimal as I can get, aside from enumerating every possible legacy NUMA topology configuration :) | |
| 15:54:01 | artom | stephenfin, hehe | |
| 15:54:23 | gmann | I still feel (dansmith might be angry on me saying this again and again ) this usage of re-generated file is wrong thought common and telling them to use it in right way (with consistent guide on oslo side) can correct the things for long term too. | |
| 15:54:41 | gmann | *though | |
| 15:54:53 | dansmith | gmann: the right way is to switch to yaml, fully commented :) | |
| 15:55:57 | bauzas | gmann: the ship has sailed. | |
| 15:56:03 | dansmith | bauzas: agree :) | |
| 15:56:38 | gmann | yeah, yaml and they can un-comment the rule with new values if they want. Honestly satying, that the way i was thinking people using policy file after policy-in-code | |
| 15:56:43 | gmann | humm | |
| 15:56:50 | bauzas | gmann: can you please clarify the problem you have for distinguishing the different upgrade cases ? | |
| 15:57:06 | bauzas | I see three cases | |
| 15:57:15 | bauzas | 1/ Ussuri greenfields | |
| 15:57:29 | jsuchome | dansmith: so last time it was tobiash, let's wait if we wants to continue and if not, I would start myself | |