Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-12-12
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
15:37:25 mriedem and is delete-old-placement-stuff checking for anything or just deleting records?
15:37:47 dansmith mriedem: no, just deleting.. figure if you're running a command like that you're opting in
15:38:50 mriedem so it's purely a signal to say yes i've migrated the placement tables from nova_api to placement back in stein (or whenever i upgraded) and i'm good to go,
15:38:54 mriedem and if not, i can't get to V
15:40:26 dansmith right
15:40:38 dansmith we could just nuke and drop and say "well, you should have known"
15:40:55 mriedem and in V+3 releases someone will be like, "wtf bro!"
15:40:57 dansmith but given the original prescription was to use this db as the way to migrate, it'd be super easy for people to have not moved
15:41:27 mriedem though thankfully you can rebuild the basic placement db stuff pretty easily as long as you're not using qos ports of cyborg thingies
15:41:38 mriedem *or cyborg thingies
15:41:56 mriedem ...or blazar...
15:42:15 mriedem or whatever VIO hacks into it for out of tree unicorns
15:42:18 mriedem it's all very stable
15:43:57 openstackgerrit Stephen Finucane proposed openstack/nova stable/train: Revert "docs: Highlight the current broken state of SEV" (partially) https://review.opendev.org/698746
15:49:47 openstack Launchpad bug 1853389 in OpenStack Compute (nova) "The ipv6 address in network_data.json within configdrive is wrong when using IronicDriver to deploy BM" [Undecided,Incomplete] - Assigned to Eric Lei (leiyashuai)
15:49:47 mriedem TheJulia: while you're about, i've marked this as incomplete but does it make any sense to you? https://bugs.launchpad.net/nova/+bug/1853389

Earlier   Later