| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-04-28 | |||
| 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 | openstack | Launchpad bug 1853170 in oslo.policy "Need documentation on recommended operator workflow for deprecated policies" [High,Triaged] | |
| 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: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 | bauzas | mmmm, amiwrong ? | |
| 15:48:25 | openstackgerrit | Merged openstack/nova master: Test multi create with vGPUs https://review.opendev.org/723858 | |
| 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 | dansmith | jsuchome: okay | |
| 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: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/ | |
| 16:00:33 | bauzas | gmann: but basically, yeah, code in python what you write in restructuredtext | |
| 16:00:59 | bauzas | because parsers aren't good with english syntax | |
| 16:01:06 | zzzeek | stephenfin: whats the quesiton, is contains() or startswith() faster? | |
| 16:01:27 | stephenfin | zzzeek: Yes, if there isn't an index on the column | |
| 16:01:48 | zzzeek | stephenfin: both contains() / startswith() are based on LIKE which is going to need a table scan | |
| 16:02:00 | artom | zzzeek, and more generally, if we're stuck doing text filtering on a column without an index, what would be the lest sucky way? | |
| 16:02:06 | artom | *least | |
| 16:02:18 | bauzas | gmann: I briefly looked at the note | |
| 16:02:25 | zzzeek | I don't see the db/model files here that we're talking about I just see objects files, is there a SQL query in those ? | |
| 16:02:42 | zzzeek | and is the issue that you don't wnat to add a new column with the indexed information you need ? | |
| 16:02:43 | bauzas | gmann: and unless I'm wrong, I don't see a technical problem for providing a nova-status check command verifying this | |
| 16:02:53 | stephenfin | zzzeek: sec, lemme drag up the model | |
| 16:03:04 | zzzeek | oh i see it | |
| 16:03:12 | zzzeek | .filter(~models.ComputeNode.numa_topology.startswith( | |
| 16:03:12 | zzzeek | compute_nodes = (context.session.query(models.ComputeNode) | |
| 16:03:12 | zzzeek | '{"nova_object.name"')) | |
| 16:03:12 | zzzeek | .filter(models.ComputeNode.numa_topology != null()) | |
| 16:03:16 | zzzeek | that ? yeah that's not great :) | |
| 16:03:22 | zzzeek | depends on number of rows | |
| 16:03:25 | zzzeek | < 1000, no problem | |
| 16:03:27 | bauzas | gmann: ie. look at the file, and if you find both old-style and new-style, yell it | |
| 16:03:30 | artom | zzzeek, well, all instances | |
| 16:03:44 | artom | So multiple thousands, maybe into the millions for large deployments | |
| 16:03:46 | zzzeek | including old ones that are offline ? | |
| 16:03:53 | zzzeek | artom: yeah that's not going to be fast | |
| 16:03:54 | stephenfin | artom: not deleted instances | |
| 16:04:06 | stephenfin | tbc | |
| 16:04:10 | zzzeek | you want to get the # of rows as low as possible before applying a like on it | |
| 16:04:14 | artom | stephenfin, does that filtering happen before or after the string filter? | |