| opendevreview | Kien Nguyen proposed openstack/python-novaclient master: support get and list server's metadata https://review.opendev.org/c/openstack/python-novaclient/+/915977 | 02:47 |
|---|---|---|
| bauzas | tkajinam: I'm doing some spec paperwork for reviews but I don't see any blueprint created for https://specs.openstack.org/openstack/nova-specs/specs/2024.2/approved/libvirt-stateless-firmware.html | 08:38 |
| bauzas | tkajinam: have you created one or no ? | 08:38 |
| tkajinam | bauzas, there is the one https://blueprints.launchpad.net/nova/+spec/libvirt-stateless-firmware | 08:48 |
| bauzas | excellent | 08:49 |
| bauzas | so we only need to update the spec | 08:49 |
| tkajinam | Ugh/. I thought I added the link but didn't. let me push a change so that you can +2 it | 08:49 |
| bauzas | cool, I'll even +W it | 08:50 |
| opendevreview | Takashi Kajinami proposed openstack/nova-specs master: Fix missing blueprint link https://review.opendev.org/c/openstack/nova-specs/+/920612 | 08:52 |
| bauzas | +Wd | 08:54 |
| tkajinam | thanks ! | 08:59 |
| opendevreview | Merged openstack/nova master: libvirt: Ensure both swtpm and swtpm_setup exist for vTPM support https://review.opendev.org/c/openstack/nova/+/908541 | 09:07 |
| opendevreview | Merged openstack/nova-specs master: Fix missing blueprint link https://review.opendev.org/c/openstack/nova-specs/+/920612 | 09:11 |
| zigo | What's the directive that tells nova-compute to use Ceph as a backend for the system disk of instances? | 09:11 |
| zigo | I see in the logs that nova-compute is reporting the local storage space instead of what's in Ceph, so I'm wondering if it's set properly ... | 09:12 |
| frickler | zigo: "[libvirt] images_type = rbd" iirc | 10:01 |
| sean-k-mooney | yep just images_type=rbd | 10:21 |
| sean-k-mooney | with that config every comptue node will report the total ceph pool stoage as its local storage instead | 10:21 |
| wncslln | morning nova o/, I'm solving this bug https://bugs.launchpad.net/nova/+bug/1994139 | 11:19 |
| wncslln | I've changed the neutron client to openstacksdk client and a bunch of tests are broken with the message: "keystoneauth1.exceptions.auth_plugins.MissingAuthPlugin: An auth plugin is required to determine endpoint URL" | 11:19 |
| wncslln | I need to change the way that the auth plugin is loaded too? | 11:19 |
| sean-k-mooney | yep that is part of changing to the client | 11:20 |
| sean-k-mooney | *form the client to the sdk | 11:20 |
| sean-k-mooney | we already converged form ironic client ot neutron client last cycle | 11:21 |
| JayF | ironic client -> openstacksdk | 11:21 |
| sean-k-mooney | the likely needed to do the same converation ill see if i can find any patches related to it | 11:21 |
| JayF | don't put neutron on me ;) | 11:21 |
| sean-k-mooney | sorry yes ironic to sdk | 11:21 |
| JayF | There are examples of openstacksdk to an external service in Ironic, but I don't think we preserve user context -- you all may need that for Neutron (?) | 11:22 |
| sean-k-mooney | yes in general | 11:22 |
| JayF | **Ironic driver | 11:22 |
| sean-k-mooney | ironic is kind of special in that its kind of admin only | 11:22 |
| JayF | *was admin only | 11:22 |
| sean-k-mooney | i.e. we cant just use the users token | 11:22 |
| wncslln | hahahaha | 11:22 |
| wncslln | i have find this patch on ironic https://review.opendev.org/c/openstack/ironic/+/900265/22/ironic/common/cinder.py#94 | 11:23 |
| wncslln | but i think is kind a different from nova | 11:23 |
| JayF | honestly that's probably not a bad example I suspect | 11:23 |
| JayF | but I was talking more about https://opendev.org/openstack/nova/src/branch/master/nova/virt/ironic | 11:24 |
| JayF | (various commits over the last 2-3 cycles to migrate from openstacksdk, completed last cycle) | 11:24 |
| sean-k-mooney | the delta is that nova is using keystoneauth directly in some cases | 11:26 |
| sean-k-mooney | because there were gaps in neutronclient | 11:26 |
| sean-k-mooney | so we needed ot use the keystoneauth client to make raw http requests | 11:26 |
| JayF | Sounds ... fun | 11:27 |
| sean-k-mooney | we also did it to be able to normalise the config | 11:27 |
| sean-k-mooney | i.e. by using keytone auth even with the existing clients it allowed use to have effefctivly the same config section for each of the service clients | 11:28 |
| sean-k-mooney | and auto lookup the urls in the keystone cataloge ectra | 11:28 |
| sean-k-mooney | the question is do we have an example fo confverting that to the sdk yet | 11:29 |
| sean-k-mooney | wncslln: sahid started trying to do the convertion a year ago but didnt get that far https://review.opendev.org/c/openstack/nova/+/882714 | 11:33 |
| sean-k-mooney | wncslln: it might be good to push the WIP patches you ahve so we can review the test failures and advise on how to adapt them | 11:33 |
| wncslln | ack. later I push the WIP and request for review | 11:35 |
| sean-k-mooney | looking at the neutron module | 11:35 |
| sean-k-mooney | we are only using keyston auth in two places | 11:35 |
| sean-k-mooney | and im not entirly sure we need to remove t | 11:35 |
| sean-k-mooney | Uggla is currently adding new usage of the sdk in there manilla series | 11:36 |
| sean-k-mooney | so we shoudl look at how they are intialising the sdk connection ectra | 11:36 |
| wncslln | already have some patch with these changes on manilla? | 11:38 |
| sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/831194/46/nova/share/manila.py | 11:38 |
| sean-k-mooney | so i have not reviewd that yet but that is where they are building the abstraction to talk to manilla using the sdk | 11:39 |
| zigo | frickler: Thanks! :_ | 11:39 |
| sean-k-mooney | and they should be loading auth parmters from the config in that patch i belive | 11:39 |
| sean-k-mooney | wncslln: they are using utils.get_sdk_adapter('shared-file-system', check_service=True) https://review.opendev.org/c/openstack/nova/+/831194/46/nova/share/manila.py#41 | 11:39 |
| sean-k-mooney | wncslln: which if i recall correctly replaces _get_session and https://github.com/openstack/nova/blob/master/nova/network/neutron.py#L261-L268 and https://github.com/openstack/nova/blob/master/nova/network/neutron.py#L70-L88 | 11:41 |
| sean-k-mooney | once we have converted to callign utils.get_sdk_adapter some of the auth exceptions will change form keystoneauth exception to sdk ones i think | 11:41 |
| sean-k-mooney | so we will still need to update tests for that change but that should be fine | 11:42 |
| sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/utils.py#L969-L995 is the defintion of get_sdk_adapter | 11:42 |
| wncslln | in a first moment, I'll try to change to get_sdk_adapter and see what comes, after that I push the WIP | 11:43 |
| wncslln | what you think? | 11:43 |
| sean-k-mooney | sure | 11:43 |
| sean-k-mooney | sound good | 11:43 |
| zigo | I'm having a hard time setting a CPU model on computes with 2x "AMD EPYC 9734 112-Core Processor" in bookworm (worked with the EPYC-Rome under bullseye). Is this a known issue ? I'm getting: | 12:49 |
| zigo | "Error starting thread.: nova.exception.InvalidCPUInfo: Configured CPU model: EPYC and CPU Flags [] ar not compatible with host CPU. Please correct your config and try again. Unacceptable CPU info: CPU doesn't have compatibility." | 12:49 |
| zigo | Even Opteron_G1-v1 doesn't work ... :/ | 12:58 |
| sean-k-mooney | so this depends on your libvirt version and the models it knwo about to some degree at least | 13:02 |
| sean-k-mooney | if you do virsh capabilities | 13:02 |
| sean-k-mooney | spelled correctly of couse | 13:03 |
| zigo | It tells: | 13:03 |
| zigo | <cpu> | 13:03 |
| zigo | <arch>x86_64</arch> | 13:03 |
| zigo | <model>EPYC-Milan</model> | 13:03 |
| sean-k-mooney | then it will print the closet model too the host cpu in the output | 13:03 |
| zigo | <vendor>AMD</vendor> | 13:03 |
| zigo | <microcode version='178258451'/> | 13:03 |
| zigo | <signature family='25' model='160' stepping='2'/> | 13:03 |
| sean-k-mooney | ack so EPYC-Milan is what would be used if you use the default which is host_model | 13:03 |
| zigo | So you'd recommend to use host-model ? | 13:04 |
| sean-k-mooney | well that is the default if you dont set anything (indirectly but its effectivly the same) | 13:05 |
| sean-k-mooney | the installer/package should not be setting a model by default | 13:06 |
| zigo | By default, I'm setting host-passthrough, then things can be overridden on cluster level or per compute level. | 13:06 |
| *** haleyb|out is now known as haleyb | 13:25 | |
| sean-k-mooney | zigo: i would not ship with host-passthrough, as a default in an installer or package. it will increase performance but severly limit livemigration | 15:39 |
| zigo | sean-k-mooney: Yeah, I may switch to host-model as default. | 15:39 |
| sean-k-mooney | i personlly use host-passthrough but i dont need live migration in my home setup. for a disto default just not settting naything or host-model will work better for more peopel | 15:41 |
| sean-k-mooney | host-passthrough is good if you have effectivly all the same generation of hardware | 15:41 |
| bauzas | reminder : nova meeting in 13 mins here | 15:47 |
| opendevreview | Maxime Lubin proposed openstack/nova-specs master: USB over IP https://review.opendev.org/c/openstack/nova-specs/+/920687 | 16:00 |
| bauzas | #startmeeting nova | 16:00 |
| opendevmeet | Meeting started Tue May 28 16:00:36 2024 UTC and is due to finish in 60 minutes. The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:00 |
| opendevmeet | The meeting name has been set to 'nova' | 16:00 |
| sean-k-mooney | o/ | 16:00 |
| bauzas | welcome folks | 16:00 |
| fwiesel | \o | 16:00 |
| bauzas | #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting | 16:00 |
| bauzas | I missed you last week :) | 16:01 |
| sean-k-mooney | aw | 16:01 |
| sean-k-mooney | it was quiter without you | 16:01 |
| bauzas | :) | 16:01 |
| sean-k-mooney | im not sure if we have folks form the us or not today | 16:01 |
| bauzas | awaiting a few people before starting | 16:01 |
| dansmith | o/ | 16:02 |
| elodilles | o/ | 16:02 |
| bauzas | okay, let's start | 16:02 |
| bauzas | shall be quick | 16:02 |
| bauzas | #topic Bugs (stuck/critical) | 16:02 |
| bauzas | #info No Critical bug | 16:02 |
| gibi | o/ | 16:02 |
| bauzas | #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster | 16:02 |
| bauzas | I can try to dent at some new bugs next week | 16:03 |
| bauzas | apart from that, anything to discuss about bugs ? | 16:03 |
| gibi | I saw https://bugs.launchpad.net/nova/+bug/2061701 happening in my Antelope env | 16:04 |
| gibi | it is strange it really happen only once | 16:04 |
| bauzas | huh | 16:04 |
| gibi | I will try to dig into it a bit later this week | 16:04 |
| bauzas | okay | 16:05 |
| gibi | But if it rings a bell for someone then ping me | 16:05 |
| bauzas | okay | 16:05 |
| bauzas | moving on ? | 16:06 |
| elodilles | gibi: i remember some discussion about this will hit us in the future... but nothing more o:) | 16:06 |
| elodilles | maybe future is now :) | 16:06 |
| * gibi needs a timemachine | 16:06 | |
| bauzas | lol | 16:07 |
| bauzas | #topic Gate status | 16:07 |
| sean-k-mooney | that bug would imply someone is using config_drive with vfat? | 16:07 |
| bauzas | #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs | 16:07 |
| bauzas | #link https://etherpad.opendev.org/p/nova-ci-failures-minimal | 16:07 |
| bauzas | #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&pipeline=periodic-weekly Nova&Placement periodic jobs status | 16:07 |
| sean-k-mooney | oh no an ephmeral disk with the encyption format set to vfat which i think is the default | 16:07 |
| bauzas | (all greens except nova-emulation for zed ) | 16:08 |
| bauzas | #info Please look at the gate failures and file a bug report with the gate-failure tag. | 16:08 |
| bauzas | #info Please try to provide meaningful comment when you recheck | 16:08 |
| bauzas | voila | 16:08 |
| bauzas | about the bug, we can continue to discuss about it on the open discussion section :) | 16:08 |
| bauzas | #topic Release Planning | 16:09 |
| bauzas | #link https://releases.openstack.org/dalmatian/schedule.html | 16:09 |
| bauzas | #info nova deadlines are now there ^ | 16:09 |
| bauzas | #info Dalmatian-2 in 5 weeks | 16:09 |
| bauzas | that's it | 16:09 |
| bauzas | moving on | 16:10 |
| bauzas | #topic Review priorities | 16:10 |
| bauzas | #link https://etherpad.opendev.org/p/nova-dalmatian-status | 16:10 |
| bauzas | you can now look at it | 16:10 |
| bauzas | I provided all the series for all the specs that were accepted | 16:10 |
| bauzas | we also have a few bugfixes for CI and other stuff in there | 16:11 |
| bauzas | fwiw, I'll continue to review some of the series | 16:11 |
| bauzas | #topic Stable Branches | 16:12 |
| bauzas | elodilles: your time | 16:12 |
| elodilles | i haven't seen much activity in stable/202*.* branches, but last time their gate were OK, so hopefully they are in the same state | 16:12 |
| elodilles | that's all from me | 16:13 |
| elodilles | about stable. | 16:13 |
| bauzas | ++ | 16:15 |
| bauzas | #topic vmwareapi 3rd-party CI efforts Highlights | 16:15 |
| bauzas | fwiesel: anything to say ? | 16:15 |
| fwiesel | #info Hand-Over to operations of CI required some (internal) migration. Working on backlog jobs. | 16:15 |
| fwiesel | So, if you see delays, that's the reason. | 16:15 |
| fwiesel | Any questions? | 16:15 |
| bauzas | not from me | 16:16 |
| fwiesel | Okay, then that's from my side. Hopefully that is done soon, and I can focus on the bugs again. | 16:16 |
| bauzas | ++ | 16:17 |
| bauzas | #topic Open discussion | 16:17 |
| bauzas | nothing on the agenda | 16:17 |
| bauzas | anything anyone ? | 16:17 |
| bauzas | looks not | 16:19 |
| bauzas | sean-k-mooney: gibi: want to continue discussion the vfat bug ? | 16:19 |
| bauzas | or, can we close ? | 16:19 |
| sean-k-mooney | we can close im updating the bug with some comments | 16:19 |
| bauzas | ++ | 16:20 |
| bauzas | thanks all then | 16:20 |
| bauzas | #endmeeting | 16:20 |
| opendevmeet | Meeting ended Tue May 28 16:20:37 2024 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:20 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2024/nova.2024-05-28-16.00.html | 16:20 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2024/nova.2024-05-28-16.00.txt | 16:20 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2024/nova.2024-05-28-16.00.log.html | 16:20 |
| fwiesel | Thank you too | 16:20 |
| elodilles | thanks o/ | 16:21 |
| gibi | sean-k-mooney: thanks | 16:22 |
| sean-k-mooney | gibi: ok i think i see where the bug is but im not sure how long its been that way | 16:32 |
| sean-k-mooney | commented in the bug but i think its https://github.com/openstack/nova/blob/96268d4e7a0dd1872c77641a634a94f599d59fe0/nova/virt/libvirt/driver.py#L11588-L11601 | 16:33 |
| sean-k-mooney | we are passing cache_name = os.path.basename(info['backing_file']) as the fs_lable | 16:33 |
| sean-k-mooney | which will generally be over 11 charters | 16:33 |
| sean-k-mooney | gibi: which was changed in https://github.com/openstack/nova/commit/4289b645970 | 16:39 |
| sean-k-mooney | gibi: my inlication is to mark this as valid but which list since i think the bug predates me working on openstack and litrally ahs been there in nova since 2012 and is now a proble because of a new mkfs release that actully treats it as an error | 16:48 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!