| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-12-12 | |||
| 15:06:35 | efried | mriedem: URLs allow repetition of keys; dicts don't. | |
| 15:06:45 | efried | mriedem: querystrings are also ordered. | |
| 15:06:50 | mriedem | oh guh | |
| 15:06:56 | mriedem | didn't even think about the duplicate keys | |
| 15:06:58 | efried | So old encoders just kinda went with it | |
| 15:07:09 | efried | but good code should be explicit | |
| 15:07:44 | huaqiang | stephenfin: so I want to reach consitency on these two questions. | |
| 15:08:52 | KeithMnemonic | Hello mridem. Do you think there will be any movement on the queens/pike cherry picks of your "marker" fix? https://review.opendev.org/#/c/690725/2. I know those are EOL but since the patches were created was not sure if you thought they could still get in? | |
| 15:09:08 | KeithMnemonic | argh mriedem: | |
| 15:09:34 | awalende | Anyone knows what nova-compute wants to tell me when trying to attach a volume to a new instance on a freshly deployed ubuntu 18.04 compute node?: unable to execute QEMU command 'device_add': Property 'virtio-blk-device.drive' can't find value 'drive-virtio-disk1' | |
| 15:11:13 | mriedem | KeithMnemonic: you have to ask stable cores | |
| 15:11:31 | KeithMnemonic | ok thanks | |
| 15:11:38 | mriedem | those branches aren't EOL either, | |
| 15:11:42 | mriedem | they are EM = extended maintenance | |
| 15:11:53 | mriedem | https://review.opendev.org/#/admin/groups/540,members | |
| 15:15:52 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Don't hardcore Python versions in test https://review.opendev.org/698732 | |
| 15:15:58 | KeithMnemonic | mriedem is there a preferred way to ping the "stable cores" | |
| 15:16:08 | efried | stephenfin: I thought you were going to fix that commit title? | |
| 15:16:10 | KeithMnemonic | should i attend the next IRC meeting? | |
| 15:16:21 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Use reasonable name for provider mapping https://review.opendev.org/698735 | |
| 15:16:26 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Don't hardcode Python versions in test https://review.opendev.org/698732 | |
| 15:16:39 | efried | KeithMnemonic: you might be waiting a while. bauzas dansmith melwitt lyarwood | |
| 15:16:44 | stephenfin | efried: yeah, done | |
| 15:16:58 | efried | stephenfin: though I rather liked it the way it was before. | |
| 15:17:40 | efried | ah | |
| 15:17:54 | dansmith | KeithMnemonic: I've reviewed the other backports of this | |
| 15:18:05 | dansmith | mriedem: any concern about the queens one to keep me from slamming this? | |
| 15:18:11 | mriedem | stephenfin: "hardcore" | |
| 15:18:12 | KeithMnemonic | thanks efried: | |
| 15:18:12 | mriedem | filthy | |
| 15:18:19 | efried | yahyoubetcha | |
| 15:20:51 | mriedem | Intel OpenStack CI is failing on merge conflicts - it must be patching something into the CI | |
| 15:21:04 | mriedem | isn't that the one asking for vpmem live migration support? | |
| 15:21:12 | stephenfin | mriedem: Can you restore this for me? https://review.opendev.org/#/c/685756/ | |
| 15:21:25 | efried | luyao: ---^ | |
| 15:21:30 | mriedem | stephenfin: done | |
| 15:21:31 | stephenfin | (Gerrit won't let me backport the fixes otherwise) | |
| 15:21:32 | stephenfin | ta | |
| 15:21:47 | openstackgerrit | Stephen Finucane proposed openstack/nova stable/train: Switch to uses_virtio to enable iommu driver for AMD SEV https://review.opendev.org/698738 | |
| 15:21:47 | openstackgerrit | Stephen Finucane proposed openstack/nova stable/train: Also enable iommu for virtio controllers and video in libvirt https://review.opendev.org/685756 | |
| 15:21:48 | openstackgerrit | Stephen Finucane proposed openstack/nova stable/train: Create a controller for qga when SEV is used https://review.opendev.org/698739 | |
| 15:23:03 | mriedem | dansmith: when is the last time we actually dropped old tables? https://review.opendev.org/#/q/topic:db-cleanup+(status:open+OR+status:merged) | |
| 15:23:18 | bbobrov | oh nice | |
| 15:23:19 | dansmith | tables? | |
| 15:23:25 | bbobrov | so we backport the fixes to train | |
| 15:23:37 | dansmith | never? | |
| 15:23:44 | mriedem | that's what i thought | |
| 15:23:47 | stephenfin | bbobrov: You mean you (SUSE) have done it already | |
| 15:23:55 | stephenfin | dansmith: You sit on a throne of LIES | |
| 15:25:01 | stephenfin | Search for 'assertTableNotExists' | |
| 15:25:10 | stephenfin | in 'nova/tests/unit/db/test_migrations.py' | |
| 15:25:10 | mriedem | i guess there are some old migrations that dropped really old tables | |
| 15:25:19 | mriedem | 232, 233 | |
| 15:25:25 | dansmith | mriedem: what were the tables? | |
| 15:25:30 | stephenfin | 346 | |
| 15:25:40 | stephenfin | https://review.opendev.org/#/c/698705/1/nova/tests/unit/db/test_migrations.py@234 | |
| 15:25:44 | mriedem | dump_*, compute_node_stats, instance_group_metadata | |
| 15:26:14 | mriedem | iscsi_targets, volumes | |
| 15:26:30 | mriedem | 292 was the most recent table drop migration | |
| 15:26:31 | dansmith | oh, gosh of course, from glance and cinder splits | |
| 15:26:49 | mriedem | https://review.opendev.org/#/c/166214/ being the most recent | |
| 15:26:50 | dansmith | stephenfin: 346 was a column | |
| 15:27:25 | mriedem | liberty, 2015 | |
| 15:27:28 | stephenfin | ah, that explains why it told me I wasn't allowed drop a column when I was dropping a table. Same heuristic, I guess | |
| 15:27:30 | mriedem | the wild west of yore | |
| 15:28:02 | stephenfin | I assume there's a reason not to drop tables? | |
| 15:28:13 | dansmith | mriedem: liberty was the 292? | |
| 15:28:18 | mriedem | dansmith: yeah | |
| 15:28:26 | dansmith | mriedem: if so, those tables must've been unused for longer than that | |
| 15:28:32 | stephenfin | The big scary comments say don't do it but not why | |
| 15:28:41 | mriedem | dansmith: likely since grizzly/folsom after the cinder split | |
| 15:29:05 | dansmith | stephenfin: for the same reasons as not dropping columns, but if the code is gone it's different | |
| 15:29:25 | dansmith | stephenfin: so the only thing that worries me is doing the models and the migrations at the same time | |
| 15:30:08 | dansmith | i.e. I worry about applying the migrations from U to T at runtime (which we should be able to do) and then introspection being mad | |
| 15:30:16 | mriedem | https://review.opendev.org/#/c/698705/ (snapshots table) should have likely gone with the 292 migration since it's related to volume snapshots | |
| 15:30:45 | dansmith | stephenfin: so if you can do the migrations first and the model drops after and not have anything complain, that'd be a good test | |
| 15:31:08 | stephenfin | I'll give that a lash | |
| 15:31:14 | stephenfin | Need some TLC anyway, clearly | |
| 15:31:17 | stephenfin | *needs | |
| 15:31:19 | mriedem | stephenfin: in case you're taking notes, quota tables are in the api db too https://review.opendev.org/#/c/698706/1 | |
| 15:31:24 | dansmith | stephenfin: also, I know you're just going for stats, but there's no reason to add a bunch of new migrations each to drop a thing | |
| 15:31:59 | dansmith | stephenfin: so, it'd be better if you put the drops all in one patch ahead of these, and then you can remove the models character by character in the following patches if you want | |
| 15:32:25 | dansmith | each migration slows down the process of building the schema on a new machine | |
| 15:32:47 | stephenfin | Kewl. I was trying to separate them logically | |
| 15:32:54 | stephenfin | didn't think about perf | |
| 15:33:18 | stephenfin | do we need to still care about placement-related tables? | |
| 15:33:42 | stephenfin | i.e. will the separate placement service ever use nova's DB? | |
| 15:33:53 | dansmith | well, I was going to say no, | |
| 15:34:08 | dansmith | but... people could easily have just pointed placement at nova and kept going, until some point | |
| 15:34:16 | mriedem | the cutover was stein, you'd use the nova api db during the upgrade, but yeah..that | |
| 15:34:16 | dansmith | has placement had a db migration since they left? | |
| 15:34:23 | mriedem | i think so | |
| 15:34:36 | dansmith | either way, probably worth a healthy warning | |
| 15:35:06 | mriedem | placement added a couple of blocker migrations | |
| 15:35:07 | dansmith | and tbh, if we're being very responsible, we might want a nova-manage delete-old-placement-stuff, which empties the tables and then drop the tables in the next release, contingent on them being empty | |
| 15:35:31 | stephenfin | your call | |
| 15:36:02 | TheJulia | melwitt: to your cpu arch question, I suspect you can rip out shipping the cpu arch from nova to ironic. Most of the code seems to rely upon stated properties of the machine's cpuarch and not the instance_info's cpu arch which makes sense from a deployment standpoint. | |
| 15:36:34 | TheJulia | melwitt: worth trying and making sure ironic doesn't explode with a test change? | |
| 15:36:45 | mriedem | dansmith: and what happens if someone doesn't run delete-old-placement-stuff? does the drop migration in V become a blocker migration until delete-old-placement-stuff is run? | |
| 15:37:09 | dansmith | mriedem: yeah, the drop just fails because we check for emptiness and raise | |