| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-03-28 | |||
| 17:37:51 | bauzas | melwitt: btw. given your tz, don't hesitate to add your nick on the topics you want to attend | |
| 17:38:24 | bauzas | I know how 1pm UTC is damn early for you, so please help me making sure you can join the most important ones for you :) | |
| 17:38:37 | melwitt | I am thinking to create a specless blueprint (or something) to propose it and people can see what they think. it would be basically implementing the last bit of the spec and removing the "experimental do not use this driver" phrase on the config option help | |
| 17:38:58 | melwitt | bauzas: sure, thank you | |
| 17:39:25 | bauzas | melwitt: sounds good to me about the specless bp, and that's a good signal flag that I won't miss when writing the cycle highlights | |
| 17:39:42 | melwitt | ack | |
| 17:40:00 | bauzas | melwitt: that said, hold on, considering the fact that Bobcat is non-SLURP | |
| 17:40:19 | melwitt | bauzas: ah right, good point. I wondered about that too | |
| 17:40:20 | bauzas | if we flip the defaults now, we'll now to forward-port that in our C release notes | |
| 17:40:40 | bauzas | because ops would miss the B relnotes if they jump straight | |
| 17:41:03 | bauzas | melwitt: I'm not opposed to flip the defaults in B | |
| 17:41:25 | bauzas | melwitt: I just wanna discuss with the team about how we ensure we don't miss anything in the C relnotes | |
| 17:42:33 | melwitt | ++ | |
| 17:43:42 | bauzas | dansmith: do you know btw. if the reno team worked on some reno magical flag for saying 'this is something you should also document for the next branch' ? | |
| 17:43:55 | melwitt | bauzas: to be clear, I'm not thinking of changing the defaults in B but to just add the "migrate nova quota limits to keystone" script and the docs. maybe it would be best to let that bake for B before flipping defaults in C? not sure | |
| 17:44:12 | bauzas | hah, my bad | |
| 17:44:36 | bauzas | then the problem remains, the migration would need to be performed in C if not done in B | |
| 17:46:10 | melwitt | the migration isn't mandatory fwiw, operators can today just add their limits via the keystone API. the script would just be to make it extra easy if they want to use it | |
| 17:46:49 | bauzas | yeah I remember | |
| 17:46:50 | melwitt | they will either way have to add their own limits via keystone API to add other placement resources such as vGPU or whatever they want | |
| 17:46:55 | melwitt | kk | |
| 17:53:56 | melwitt | (thinking out loud) maybe it would be good to hook the forklift script into online_data_migrations in C if we decide to flip the default in C ... bc unified limits default closed (limit of 0) so if they don't make their limits in keystone, all their quota would start being denied. it would be a major major problem to miss that upgrade step of adding limits in keystone if the default is changing. I'll write all of this up in the | |
| 17:53:56 | melwitt | blueprint for discussion or maybe a small spec | |
| 18:02:16 | bauzas | looks like we have an ovn agent gone on grenade-multinode job | |
| 18:13:54 | dansmith | bauzas: nope, I dunno | |
| 18:53:44 | opendevreview | sean mooney proposed openstack/nova master: Allow discard with virtio-blk https://review.opendev.org/c/openstack/nova/+/878795 | |
| 19:18:32 | opendevreview | Carl Morris proposed openstack/nova master: Fix a typo in this URL: https://docs.openstack.org/nova/latest/admin/availability-zones.html https://review.opendev.org/c/openstack/nova/+/878797 | |
| #openstack-nova - 2023-03-29 | |||
| 02:20:31 | opendevreview | Nobuhiro MIKI proposed openstack/nova master: libvirt: Add 'COMPUTE_ADDRESS_SPACE_*' traits support https://review.opendev.org/c/openstack/nova/+/873221 | |
| 05:50:21 | opendevreview | Amit Uniyal proposed openstack/placement master: Bugtracker link update https://review.opendev.org/c/openstack/placement/+/876768 | |
| 05:58:53 | opendevreview | Amit Uniyal proposed openstack/placement master: Bugtracker link update https://review.opendev.org/c/openstack/placement/+/876768 | |
| 06:38:39 | opendevreview | Amit Uniyal proposed openstack/nova-specs master: Add cleanup flag to remove dangling volumes https://review.opendev.org/c/openstack/nova-specs/+/878757 | |
| 06:52:52 | opendevreview | Amit Uniyal proposed openstack/nova-specs master: Add cleanup flag to remove dangling volumes https://review.opendev.org/c/openstack/nova-specs/+/878757 | |
| 06:55:58 | opendevreview | Amit Uniyal proposed openstack/nova-specs master: Add cleanup flag to remove dangling volumes https://review.opendev.org/c/openstack/nova-specs/+/878757 | |
| 08:02:44 | opendevreview | Jorge San Emeterio proposed openstack/nova master: Have host look for CPU controller of cgroupsv2 location. https://review.opendev.org/c/openstack/nova/+/873127 | |
| 08:53:05 | opendevreview | Moritz Wanzenböck proposed openstack/nova master: Implement extend_volume for local devices https://review.opendev.org/c/openstack/nova/+/878763 | |
| 08:53:05 | opendevreview | Moritz Wanzenböck proposed openstack/nova master: Implement extend_volume for local devices https://review.opendev.org/c/openstack/nova/+/878763 | |
| 09:24:38 | opendevreview | Moritz Wanzenböck proposed openstack/nova master: Implement extend_volume for local devices https://review.opendev.org/c/openstack/nova/+/878763 | |
| 12:31:17 | bauzas | reminder : nova vPTG restarts in 30 mins | |
| 12:31:45 | bauzas | in case people haven't seen it , today's packed agenda https://lists.openstack.org/pipermail/openstack-discuss/2023-March/033013.html | |
| 12:32:07 | bauzas | I'll probably hardstop some discussions if we need | |
| 13:02:30 | bauzas | we're starting to discuss today for the vTPG | |
| 13:02:33 | bauzas | vPTG | |
| 13:26:36 | frickler | this is weird, why is bobcat at the top but antelope at the bottom? https://launchpad.net/nova/+series | |
| 13:47:06 | bauzas | frickler: good question, honestly I dunno | |
| 13:49:05 | d34dh0r53 | sean-k-mooney1: ping | |
| 14:16:21 | d34dh0r53 | we're discussing the new keystone endpoint type "service" in icehouse right now and have some questions, is anyone able to join for a couple of minutes? | |
| 14:31:21 | opendevreview | Merged openstack/nova master: mypy: Fix implicit optional usage https://review.opendev.org/c/openstack/nova/+/878693 | |
| 14:48:29 | bauzas | wowoooh ^ \o/ | |
| 14:52:18 | bauzas | d34dh0r53: the nova team has their meetings for the day until 5pm UTC, how can we help ?" | |
| 14:55:08 | d34dh0r53 | bauzas: I think we're good, we've got answers on the etherpad. Thanks for getting back | |
| 14:57:31 | whoami-rajat | bauzas, hey, for tomorrow's cross project, does nova team has any session during 1500-1600 UTC? | |
| 14:59:54 | bauzas | whoami-rajat: a short one https://etherpad.opendev.org/p/nova-bobcat-ptg#L58 | |
| 15:00:59 | whoami-rajat | bauzas, ok, how about doing the cinder cross project from 1530-1630 then? we don't have anything after 1500 UTC and it's a 1 hour gap in between so was thinking if we can reschedule it? | |
| 15:01:49 | bauzas | whoami-rajat: we agreed on a cinder-nova session previously at 1600UTC | |
| 15:01:53 | bauzas | do you want more time ? | |
| 15:02:12 | whoami-rajat | bauzas, yes we did, no not more time but doing it half an hour before | |
| 15:02:19 | whoami-rajat | at 1530 | |
| 15:05:59 | bauzas | whoami-rajat: sorry, you mean you want to move the session half a hour before ? | |
| 15:06:17 | whoami-rajat | bauzas, yes correct, at 1530 UTC | |
| 15:06:27 | bauzas | whoami-rajat: ok, and for how many time ? | |
| 15:06:30 | bauzas | 1 hour ? | |
| 15:06:33 | whoami-rajat | yep | |
| 15:06:38 | bauzas | ie. 1530-1630 ? | |
| 15:06:38 | whoami-rajat | we've 2 topics so 1 hour should do | |
| 15:06:42 | bauzas | ok | |
| 15:06:55 | bauzas | moving it then on the nova etherpad :) | |
| 15:07:48 | bauzas | whoami-rajat: done https://etherpad.opendev.org/p/nova-bobcat-ptg#L59 | |
| 15:08:16 | whoami-rajat | bauzas, great, thanks for the changing on a short notice :) | |
| 16:41:44 | opendevreview | Amit Uniyal proposed openstack/placement master: Bugtracker link update https://review.opendev.org/c/openstack/placement/+/876768 | |
| 18:39:56 | melwitt | frickler: re: the launchpad page, it appears to be sorting non-active-development series in reverse alphabetical order (I notice that "trunk" is located between "ussuri" and "train"). I haven't been able to guess a reason it sorts alphabetically instead of by the milestone dates set on each series though | |
| 18:40:39 | melwitt | and I don't see a way to change it | |
| 20:56:29 | opendevreview | Sylvain Bauza proposed openstack/nova master: Verify a move operation for cross_az_attach=False https://review.opendev.org/c/openstack/nova/+/878948 | |
| #openstack-nova - 2023-03-30 | |||
| 05:38:52 | opendevreview | Amit Uniyal proposed openstack/placement master: Bugtracker link update https://review.opendev.org/c/openstack/placement/+/876768 | |
| 06:03:36 | frickler | melwitt: that at least sounds plausible, thanks for checking | |
| 06:18:08 | opendevreview | Tobias Urdin proposed openstack/nova master: Remove libvirt tunnelled migration https://review.opendev.org/c/openstack/nova/+/879021 | |
| 09:34:42 | opendevreview | Tobias Urdin proposed openstack/nova master: Remove libvirt tunnelled migration https://review.opendev.org/c/openstack/nova/+/879021 | |
| 09:35:18 | bauzas | if people are OK, I'd like to add a functest for testing cross_az_attach https://review.opendev.org/c/openstack/nova/+/878948 | |
| 09:41:19 | gibi | bauzas: I will be absent from the vPTG from 15:00 UTC hopefully only for half an hour due to a downstream call | |
| 09:44:18 | bauzas | ack | |
| 09:44:30 | bauzas | we'll discuss with glance | |
| 09:44:41 | bauzas | see the agenda I posted on the ML | |
| 09:44:57 | bauzas | we'll discuss with glance *at that time* | |
| 10:15:23 | gibi | ack | |
| 10:27:15 | opendevreview | yatin proposed openstack/nova master: [DNM] Test lower tb cache https://review.opendev.org/c/openstack/nova/+/868419 | |
| 10:41:36 | tobias-urdin | i have a conundrum that i cannot wrap my head around, i've been looking at the possibility of removing the need for remotefs (rsync/scp over ssh) when doing live migrations, that should be possible but requires some RPC changes to get rid of testing if instance dir is on shared storage and some other stuff, just out of curiosity i checked the | |
| 10:41:37 | tobias-urdin | remotefs usage all around and we also use it for config drive migrations (as qemu (libvirt blocks us) does not allow migrating read-only ISO source file), fetching kernel and ramdisk, copying vtpm data, copying cached images from other compute nodes(?) etc | |
| 10:42:38 | tobias-urdin | so while what I want to do, to remove the need for SSH key distribution for live migrations is possible, getting it completely removed in libvirt driver seems hard, because I cannot wrap my head around what we could replace that logic in terms of copying files around | |
| 10:43:54 | tobias-urdin | if only libvirt had a copy file implementation in their protocol we wouldn't need anything else for remote access and could get tls etc, theoretically could be done with block devices using storage pools but that would be even worse imo | |
| 11:13:34 | jrosser | tobias-urdin: key distribution can be avoided by using signed keys | |
| 11:21:21 | zigo | bauzas: You remember I couldn't do some live-migration with some of my VMs? It turns out that: | |
| 11:21:21 | zigo | - It only happens with SOME images, like Rocky Linux 8.7 | |
| 11:21:21 | zigo | - upgrading both source and destination from Qemu 5.2 to 7.2 (from bullseye-backports) fixes the issue ! \o/ | |
| 11:23:19 | tobias-urdin | jrosser: yeah, but it's also more to it than that, what about lateral movement between compute nodes; being able to essentially wipe instance disks of another compute node, or what about a operating system with no ssh running, sure could run ssh in a container and expose nova dir but then point #1 still applies, hard problem | |
| 11:38:30 | sean-k-mooney1 | zigo: glad its fixed but odd that it depeneded on the image | |
| 11:39:05 | zigo | sean-k-mooney1: According to the people from #qemu, it's likely that the image is using some new feature of the virtio stuff. | |
| 11:39:16 | zigo | What's weird is that with Roky Linux 9, I didn't have the issue... | |
| 11:39:51 | sean-k-mooney1 | its proably using the transitional virtio device or something like that | |
| 11:40:14 | sean-k-mooney1 | as it the driver is proably negocating an older feature set | |
| 11:40:34 | zigo | sean-k-mooney1: I'll upgrade all my cluster to the newer version of Qemu and will migrate (non-live) the problematic instances ... | |
| 11:41:17 | zigo | Still very annoying, but lucky, only very few instances are affected. | |