Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2024-01-09
16:11:39 elodilles note: there is only os-vif with changes worth to release at Caracal-2 it seems: https://review.opendev.org/c/openstack/releases/+/904927
16:11:40 bauzas I'll try to look at all the already open specs but we already have a lot of accepted specs for this cycle : https://blueprints.launchpad.net/nova/2024.1
16:11:52 bauzas elodilles: I've seen the email, I'll look at it
16:12:12 elodilles bauzas: ++
16:14:24 bauzas anything people want to discuss about open specs ?
16:15:45 bauzas looks not
16:15:48 bauzas moving on
16:15:56 bauzas #topic Review priorities
16:16:00 bauzas #link https://etherpad.opendev.org/p/nova-caracal-status
16:16:05 bauzas folks, please look at the etherpad
16:16:14 bauzas I've added all the blueprints in it
16:17:26 bauzas (I actually forgot to add the last blueprint we agreed)
16:18:23 kashyap Thanks for the link; /me bookmarks
16:18:41 bauzas voila
16:18:45 bauzas moving on
16:18:58 bauzas #topic Stable Branches
16:19:02 bauzas elodilles: ?
16:19:14 elodilles #info stable gates are not blocked but patches on older branches can have many rechecks until they get merged
16:19:28 elodilles the usual, i would say.
16:19:36 elodilles #info nova stable Zed release: https://review.opendev.org/c/openstack/releases/+/899604
16:19:49 elodilles this is waiting for one last patch to merge afaik ^^^
16:19:52 bauzas indeed
16:19:59 elodilles +1
16:20:08 elodilles #info according to TC's plan (train and) ussuri branches are proposed to be End of Life if a team is OK with that: https://review.opendev.org/c/openstack/releases/+/903278
16:20:21 sean-k-mooney yep
16:20:26 sean-k-mooney can we proceed with that
16:21:02 bauzas I'll look at the Ussuri EOL change and if everything is OK, I'll +1 it
16:21:03 elodilles the patch needs a PTL / release liaison +1
16:21:14 elodilles otherwise i think it's OK
16:21:18 elodilles bauzas: thx
16:21:27 elodilles #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci
16:21:36 elodilles and that's all from me
16:21:43 bauzas cool
16:22:02 bauzas thanks elodilles for reporting
16:22:07 bauzas #topic vmwareapi 3rd-party CI efforts Highlights
16:22:15 fwiesel #Info Access to logs was blocked automatically thanks to corporate policy. Working on exemption.
16:22:24 bauzas cool
16:22:39 fwiesel So, the link I provided was promptly automatically shut down. Nothing says IaaS like introducing a ticket process on top of it.
16:22:53 fwiesel #Info Limited external network access from test infrastructure with allow-list (currently: opendev.org, pypi.org).
16:23:27 fwiesel The test infrastructure is now fairly locked down, we probably need to figure out, what we have to add to the allow-list.
16:23:44 fwiesel But at least, that way we feel more comfortable running essentially random stuff from the internet.
16:23:58 fwiesel That's it more or less from my side. Any questions?
16:24:16 bauzas nope for me :)
16:24:26 bauzas thanks for reporting :)
16:24:36 fwiesel You're welcome. Any happy new year.
16:24:40 bauzas you too
16:24:50 bauzas #topic Open discussion
16:24:56 auniyal bauzas, I have one bug to discuss/share
16:25:08 auniyal https://bugs.launchpad.net/nova/+bug/2048184
16:25:08 auniyal https://bugs.launchpad.net/nova/+bug/2048154
16:25:08 auniyal we got the bug w.r.t clean dangling volume patch
16:25:12 bauzas nothing in the wikipage, but kashyap had one point
16:25:17 kashyap Yeah
16:25:35 kashyap So it's about this specless blueprint - a suggestion that came from sean-k-mooney: https://blueprints.launchpad.net/nova/+spec/allow-disabling-ephemeral-disk-formatting
16:25:56 kashyap The main motivation (as I understand it) seems to be the following:
16:26:16 kashyap (1) To explore removal of libguestfs / and unneeded dependencies
16:26:38 kashyap (2) Doing so will help reduce security/package footprint from containers that might be shipping nova-compute.
16:27:20 kashyap Today libguestfs' usage seems to be in the area of file injection and ephemeral disk creation.
16:27:26 bauzas to be clear, the default would be "formatted", right?
16:27:42 kashyap I think so, yes. I need to check.
16:27:51 kashyap bauzas: That said, putting my upstream hat on:
16:28:25 bauzas we can't really change our current behaviour so I'd prefer to keep the current usage by default
16:28:56 bauzas but of course, if operators and products want to not use libguestfs, they can change the option value
16:29:19 kashyap We should also bear in mind that libguestfs provides many other "adjacent tools" (e.g. an incomplete list: https://paste.opendev.org/show/bfNahtW5QJVeYSQUNaFH/) that operators might be using.
16:29:35 bauzas there could be some nits on the values of the items for this config option
16:29:52 kashyap (These "adjacent tools" are all to do with disk images, etc. They're extremely useful. So even for downstreams I'd be wary of suggesting to 'drop' libguestfs.)
16:29:58 bauzas but looks to me some implementation question, not a design one
16:30:17 kashyap bauzas: Yeah, the nits could be worked out. But yeah, the devil is in the implementation indeed.
16:30:37 bauzas kashyap: do you remember the current defaults we have for ephemeral disks ? ext4 ?
16:31:12 kashyap Quickly checking...
16:31:19 bauzas this would mean that we would need to provide all the supported disk formats in the config option items
16:31:36 bauzas maybe people don't want this, right?
16:31:42 kashyap (I'd think so, it'd be one of ext3)
16:31:49 bauzas are we able to format our disks by something else but the default format ?
16:32:12 bauzas I can quickly look at the code
16:34:38 kashyap (There's several places the CONF.default_ephemeral_format is used - I guess you're looking for this?)
16:37:16 bauzas nope, I just wonder the negative value of 'unformatted' which then would be the default
16:38:10 kashyap bauzas: The current default is ext4, as I see it
16:38:23 bauzas everything seems to be handled by this module https://github.com/openstack/nova/blob/master/nova/virt/disk/vfs/guestfs.py
16:39:58 kashyap It depends on what you mean by "everything" :) I think you mean everything related to libguestfs. But we don't have to get into the details of it here.
16:39:59 bauzas anyway, I'm OK to approve this specless blueprint but we'll need to make sure that the default behaviour is continuing to support to format the ephemeral disk
16:40:15 bauzas sean-k-mooney: any concern by what I said ?
16:40:16 kashyap Please add that remark in the BP. I need to still explore what makes sense here
16:40:34 kashyap But also I need to hear if anyone actually needs this. We shouldn't do needless work
16:41:12 kashyap I have a hard stop in 5 minutes; afraid. I need to visit a friend in a hospital. Can discuss the rest afterwards
16:41:41 bauzas anyone not wanting to accept this blueprint ?
16:41:54 bauzas if not,
16:42:43 bauzas #agreed https://blueprints.launchpad.net/nova/+spec/allow-disabling-ephemeral-disk-formatting is approved as specless, provided it defaults to format the disks
16:42:49 bauzas kashyap: ^
16:43:03 kashyap Okay; for now we can go ahead; thank you
16:44:35 bauzas ++
16:44:42 bauzas auniyal: you wanted to discuss a specific bug ?
16:45:25 auniyal yeah - we got this bug https://bugs.launchpad.net/nova/+bug/2048154
16:45:42 auniyal similar to this - https://bugs.launchpad.net/nova/+bug/2048184
16:45:55 auniyal I have created a patch - https://review.opendev.org/c/openstack/nova/+/904817
16:46:24 bauzas add your patch proposals into https://etherpad.opendev.org/p/nova-caracal-status
16:46:41 auniyal sean-k-mooney for " source_type: snapshot and source_type:image"
16:46:47 auniyal is it snapshot image
16:47:28 auniyal I created snapshot of Vm then Vm from that snapshot, but their source_type was sa same as original vm
16:47:30 bauzas auniyal: add your patches into https://etherpad.opendev.org/p/nova-caracal-status#L114 so people could review them

Earlier   Later