16:00:09 <gibi> #startmeeting nova
16:00:10 <openstack> Meeting started Thu Oct 15 16:00:09 2020 UTC and is due to finish in 60 minutes.  The chair is gibi. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:13 <openstack> The meeting name has been set to 'nova'
16:00:24 <gibi> o/
16:00:27 <melwitt> o/
16:00:30 <dansmith> o/
16:00:41 <bauzas> \o
16:01:22 <elod> o/
16:01:39 <gibi> lets get started
16:01:40 <gibi> #topic Bugs (stuck/critical)
16:01:46 <gibi> No critical bugs
16:01:52 <gibi> #link 6 new untriaged bugs (0 since the last meeting): https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New
16:02:12 <gibi> is there any specific bug we need to talk about?
16:02:17 <melwitt> I have a bug to bring up
16:02:32 <artom> o/
16:02:44 <melwitt> https://bugs.launchpad.net/nova/+bug/1799298 is two years old but recently flagged as a security issue downstream,
16:02:46 <openstack> Launchpad bug 1799298 in OpenStack Compute (nova) rocky "Metadata API cross joining instance_metadata and instance_system_metadata" [Medium,Triaged]
16:03:06 <melwitt> just wanted to bring it to attention and ask for help in solving it as it does not look straightforward based on the past bug comments
16:03:57 <dansmith> we don't join those tables for pulling the instance,
16:04:03 <dansmith> and haven't since icehouse-ish
16:04:20 <dansmith> is this a query specifically that metadata uses that is still doing a join?
16:05:18 <melwitt> there is a query and they confirmed it's this one... and they said they also found it present in train
16:06:59 <gibi> reading the bug mriedem said that the instance password is needed from the system_metadata
16:07:29 <dansmith> right, but when we load an instance now, we actually query the instance, then query metadata, then sysmeta, and squash them together
16:07:37 <dansmith> that's what instances_fill_metadata() is
16:08:47 <melwitt> would this not do the join with system_metadata? https://github.com/openstack/nova/blob/master/nova/api/metadata/base.py#L675
16:08:52 <dansmith> so I'm wondering if there's a specific db api method that metadata uses to pull the instance, which is somehow letting those columns get into the initial query, but shouldn't?
16:09:21 <dansmith> melwitt: well, those are supposed to be treated differently down the stack,
16:09:41 <dansmith> they are for instance_get(), but my point is maybe this metadata-only query is bypassing that somehow
16:09:47 <melwitt> ack
16:10:39 <dansmith> anyway, we should probably not derail the meeting and can discuss in -nova
16:11:01 <melwitt> yep, thanks, at least there's some thread to pull now
16:11:11 <gibi> OK
16:11:18 <gibi> is there any other bug we need to talk about?
16:12:18 <gibi> #topic Release Planning
16:12:23 <gibi> Victoria has been released
16:12:26 <gibi> Thank you all for your valuable contributions
16:12:41 <gibi> master is now fully open for Wallaby
16:12:58 <gibi> and we should focus on reviewing incoming specs and preparing for the PTG
16:13:20 <gibi> I will create the wallaby runway etherpad tomorrw
16:13:49 <gibi> anything else about Victoria or Wallaby?
16:14:46 <gibi> #topic Stable Branches
16:14:58 <gibi> elod left comments on the wiki ...
16:15:04 <gibi> "Victoria is now a fully normal stable branch, and the normal stable policy now applies."
16:15:10 <gibi> stable/stein will transition to Extended Maintenance in 2020-11-11
16:15:16 <gibi> should prepare a final release from Stein
16:15:22 <gibi> consider which patches should be part of the final release
16:15:30 <gibi> current list of patches: https://etherpad.opendev.org/p/nova-stable-stein-em
16:16:05 <elod> yepp, that's all, actually,
16:16:16 <elod> I'll focus on Stein in the coming weeks
16:16:43 <gibi> thanks
16:16:44 <elod> let me know if you see any patch that should be definitely be part of the final release
16:16:53 <elod> np
16:17:13 <gibi> #topic Sub/related team Highlights
16:17:25 <gibi> skipping API as gmann cannot join today
16:17:30 <gibi> Libvirt (bauzas)
16:19:49 <gibi> I guess the silence means no news
16:19:53 <gibi> #topic PTG and Forum planning
16:19:58 <gibi> Next week is Summit week: #link https://www.openstack.org/summit/2020/summit-schedule
16:20:09 <gibi> Week after next week is PTG # link https://etherpad.opendev.org/p/nova-wallaby-ptg
16:21:01 <gibi> is there anything we need to discuss regarding these events?
16:21:19 <gibi> I will focus my time on Fishbowls during next week
16:22:30 <gibi> #topic Open discussion
16:22:37 <gibi> we have one topic from stephenfin
16:22:42 <gibi> (stephenfin) Specless BP approval for https://blueprints.launchpad.net/nova/+spec/compact-db-migrations-wallaby
16:22:53 <gibi> tl;dr: I want to go at least as far as Train, and then rework any Ussuri or Victoria migrations to use alembic. Initial cleanup work available at https://review.opendev.org/#/q/topic:bp/compact-db-migrations-wallaby
16:23:34 <gibi> can we approve this specless bp?
16:24:06 <dansmith> I suspect this will be a lot more work than it seems,
16:24:16 <artom> My paranoid nature is immediately skeptical of changing something as crucial as DB schema in stable releases
16:24:30 <gibi> artom: this compacts the old migration on master
16:24:34 <dansmith> as my experience from briefly touching alembic in glance is that the replicability of the schema stuff can get weird in things like unit tests
16:24:55 <dansmith> artom: right, not actually touching older releases,
16:25:02 <artom> Ah, sorry, *facepalm*
16:25:07 <dansmith> just squashing everything into state as of train
16:25:11 <melwitt> yeah, I made a note on the ptg etherpad but basically I know we've talked about this before, and IIRC the conclusion was it wouldn't be a good idea to convert everything to alembic. but I'd have to go see if I can find artifacts from those discussions
16:25:13 <gibi> dansmith: as far as I understand the current bp only propose the compaction not the alembic migration
16:25:44 <dansmith> gibi: yeah, but using alembic going forward right?
16:26:00 <dansmith> my point is just about converting all our db fixture stuff to alembic, multi-cells and all
16:26:03 <gibi> dansmith: this would enable to move to alembic, yes
16:26:31 <gibi> dansmith: but that move would be still a separate bp
16:26:48 <dansmith> I totally recognize the need to compact, but I want to make sure we're super sure that the schema ends the same as it is now, so I hope we'll be very diligent about approving that compaction only after lots of review
16:26:55 <bauzas> gibi: sorry, parenting urgent issue
16:26:57 <dansmith> gibi: ack, okay
16:27:01 <bauzas> gibi: nothing to report
16:27:07 <gibi> bauzas: OK, thanks
16:27:22 <dansmith> gibi: if the specless bp is just for the compaction, then that's fine with me
16:27:23 <gibi> dansmith: I do suggest to talk about the alembic plans during the PTG
16:27:54 <bauzas> I think there are two asks
16:28:02 <bauzas> #1 for packing DB upgrades
16:28:03 <artom> dansmith, we could do something with tests, I think. This stuff is supposed to be 100% deterministic, so... run the old uncompacted migrations, run the news one, starting the the exact same schema, and assert the resulting schema is the same?
16:28:11 <bauzas> #2 for using alembic
16:28:19 <bauzas> fwiw, #1 seems good to me, but for #2, meh
16:28:20 <dansmith> artom: yes
16:28:33 <artom> This wouldn't apply to data migrations, right?
16:28:46 <dansmith> artom: my point is, it's easy to say "the tests pass that used to pass, so they must be identical" and that's not enough,
16:28:54 <bauzas> actually, I have the same opinion than dansmith
16:28:59 <dansmith> artom: we need to make sure they emit the same schema
16:29:05 <dansmith> artom: this has nothing to do with data migrations
16:29:41 <artom> Ack
16:30:08 <artom> So, if we can have a one-time test that asserts the new thing results in the same schema as the old thing, I don't see why not
16:30:22 <dansmith> that's what I'm saying
16:30:37 <artom> That's what *I'm* saying ;)
16:30:51 <dansmith> literally diff the mysqldump from a run generated with the current, and compacted thing, and they should be zero
16:31:37 <bauzas> are we discussing about how to compacting the DB upgrades ? then yes ^
16:31:50 <dansmith> bauzas: how to *verify* the compaction
16:32:18 <bauzas> how to verify* indeed, my bad
16:32:25 <gibi> I dont see any objection against approving stephenfin's bp with a comment that it only covers the compaction of the migrations and not the alembic move.
16:32:33 <bauzas> ++
16:32:35 <gibi> do I see it right?
16:32:39 <bauzas> good luck tho
16:32:49 <bauzas> I don't think it will be simple
16:32:55 <bauzas> but meh
16:33:01 <dansmith> gibi: yes, just footnote that we should be super review-y on the compaction please
16:33:11 <gibi> dansmith: ack I will add that comment too
16:34:00 <gibi> nothing else on the agenda for toda
16:34:00 <gibi> y
16:34:10 <gibi> anything else in the room to discuss?
16:34:44 * artom throws a small flat round object
16:35:22 <gibi> what do you have there artom ? :)
16:35:35 <artom> A pun is what I have
16:35:38 <gibi> :D
16:36:00 <gibi> then thanks for joining today
16:36:15 <gibi> o/
16:36:37 <gibi> #endmeeting