| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-04-28 | |||
| 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 | |
| 15:57:32 | bauzas | 2/ T->U and no policy.json changes | |
| 15:57:45 | bauzas | 3/ T->U and specific policy.json | |
| 15:57:49 | artom | stephenfin, yeah, I left a follow-up comment. I guess I just don't know enough in this case, and what I've been able to learn isn't enough | |
| 15:57:52 | bauzas | gmann: amirite ? | |
| 15:57:58 | gmann | bauzas: policy file with new defaults only (no deprecated old default) cover two case 1. this broken case 2. people move to new defaults intentionally. | |
| 15:57:58 | dansmith | jsuchome: okay | |
| 15:58:23 | gmann | bauzas: 3rd one has ^^ above cases | |
| 15:58:27 | bauzas | gmann: sure, but that's not the case you wanna warn, right? | |
| 15:58:40 | tobiash | jsuchome: feel free to take it, atm I unfortunately I don't have time to work on it | |
| 15:58:41 | stephenfin | zzzeek: I know you're busy, but any chance you'd be able to shine a light on https://review.opendev.org/#/c/537414/ at some point? | |
| 15:58:46 | stephenfin | zzzeek: please and thank you :) | |
| 15:59:32 | gmann | bauzas: yeah, so we just say in nova-status what we are saying in reno ? | |
| 15:59:45 | gmann | i mean new reno - https://review.opendev.org/#/c/723645/ | |