| opendevreview | melanie witt proposed openstack/nova master: Add encryption support to convert_image https://review.opendev.org/c/openstack/nova/+/870934 | 01:06 |
|---|---|---|
| opendevreview | Amit Uniyal proposed openstack/nova master: Adds device tagging functional tests https://review.opendev.org/c/openstack/nova/+/895162 | 05:52 |
| opendevreview | Amit Uniyal proposed openstack/nova master: Adds device tagging functional tests https://review.opendev.org/c/openstack/nova/+/895162 | 06:00 |
| opendevreview | Amit Uniyal proposed openstack/nova master: Adds device tagging functional tests https://review.opendev.org/c/openstack/nova/+/895162 | 06:35 |
| hamidlotfi_ | Hi there, | 07:13 |
| hamidlotfi_ | In the nova database, I see much `LOCK WAIT` on the `neutron.ports` table | 07:13 |
| hamidlotfi_ | and I putting a sample log for the lock wait | 07:13 |
| hamidlotfi_ | I want to know if is this a bug in the structure of a table or the script of the update or the user mistake. | 07:13 |
| hamidlotfi_ | https://www.irccloud.com/pastebin/o4HQQaEK/ | 07:13 |
| hamidlotfi_ | @dansmith @bauzas @sahid_ | 09:54 |
| *** ministry is now known as __ministry | 10:10 | |
| dvo-plv | sean-k-mooney, Are you here ? | 10:22 |
| sean-k-mooney | dvo-plv: o/ | 10:44 |
| dvo-plv | I wouldl iek to talk with you regarding out blueprint nt nic support, if you have free time for it | 10:45 |
| dvo-plv | previously we decided that we will try to pass socket name with ovs command for dpdk port type | 10:45 |
| sean-k-mooney | yes and i ask can we pass the name to ovs when addign the port so that we didn not have to compute one that matched the nic driver format | 10:47 |
| sean-k-mooney | we also discussed that some of the magic constant are actully discoverable form sysfs like the vf offset | 10:47 |
| dvo-plv | yes | 10:48 |
| dvo-plv | we spent some time on the investigation and this is not possible to do it for dpdk port type with ovs. there will be alot of changes, DPDK community will not approve it | 10:49 |
| sean-k-mooney | thats not ideal | 10:49 |
| dvo-plv | So I would like to get back to the separate os-vif plugin | 10:50 |
| dvo-plv | what do you think about that ? | 10:50 |
| sean-k-mooney | not nessiarly what that means is that nova needs to tell neutron the vf specific info | 10:50 |
| sean-k-mooney | so we need to pass info to the ml2 driver in the binding_profile | 10:51 |
| sean-k-mooney | neutron can then use that to generate the socket path. alternitivly we could jsut generate the path ourselve in nova | 10:51 |
| dvo-plv | path is not a problem, specific socket name is the root cause | 10:52 |
| sean-k-mooney | the socket name is path of the path :) | 10:52 |
| sean-k-mooney | but yes | 10:52 |
| dvo-plv | So, we can somehow use port binding profile for this purposes? | 10:54 |
| sean-k-mooney | yes that is what its for to pass info form nova to the network backend | 10:56 |
| sean-k-mooney | we normally sotre the pci_adress in it | 10:56 |
| sean-k-mooney | but we can have other fields like the offset ectra | 10:56 |
| sean-k-mooney | or we can just comppute the socket name and pass that | 10:56 |
| sean-k-mooney | which is proably the better option | 10:57 |
| sean-k-mooney | since nova does not have the base path (neutron/ovs does have that info) | 10:57 |
| sean-k-mooney | so we can provide the socket name in the binding profile and neutron can append that to the base socket path | 10:57 |
| sean-k-mooney | and then we will get the full path back which we can store in the xml | 10:58 |
| dvo-plv | okay, i see. but i have a question how we should handle pci. for socket name stdvio10, we need to use pci 0000:65:01.2. So we need vendor specific mechanism for parse socket name | 11:00 |
| sean-k-mooney | its the other way around | 11:00 |
| sean-k-mooney | we are selecting VFs in the pci tracker | 11:00 |
| sean-k-mooney | and you need to compute the socket name from the adress | 11:01 |
| sean-k-mooney | the main issue i think is still the multi device support | 11:01 |
| sean-k-mooney | since the previous algorthim did not support more hten one nic | 11:02 |
| dvo-plv | yes, currently we do not support multinic setup | 11:03 |
| sean-k-mooney | right so i dont think we should support this in nova until that is addressed | 11:03 |
| dvo-plv | Honestly, i forget about that, I will investigate internal if we have some plan how this should be done in the future, because as far as I know we have plan to provide this feature | 11:04 |
| dvo-plv | But if this is a limitation for be in the common code, what about to pass us with separate os-vif plugin, which will handle all this issuses ? | 11:06 |
| sean-k-mooney | a out of tree os-vif plugin will also reqiure your own ml2 driver in neutron | 11:06 |
| dvo-plv | yes, we can implement it too, like Agilio https://github.com/Netronome/agilio-ovs-openstack-plugin/tree/master/vif_plug_agilio_ovs | 11:08 |
| *** haleyb|away is now known as haleyb | 13:26 | |
| opendevreview | Dan Smith proposed openstack/nova master: WIP: Compile mdev samples for nova-next https://review.opendev.org/c/openstack/nova/+/897708 | 13:57 |
| dansmith | bauzas: this is getting close to working ^ | 13:58 |
| bauzas | dansmith: wow, thanks | 13:58 |
| dansmith | last round only failed because I didn't sudo something | 14:00 |
| sean-k-mooney | dansmith: would you mind in a followup allowing us to enabel other moduels | 14:01 |
| sean-k-mooney | i.e. mdpy or mbochs? | 14:02 |
| dansmith | sean-k-mooney: yeah I was going to do all the samples, I just wanted to get the mechanics working | 14:02 |
| dansmith | or do you mean *any* other module? | 14:02 |
| sean-k-mooney | i was thinking of makign CONFIG_SAMPLE_VFIO_MDEV_MTTY=m | 14:03 |
| sean-k-mooney | a list | 14:03 |
| sean-k-mooney | but mainly jsut the mtty samples | 14:03 |
| sean-k-mooney | it might be nice if the set of flags to enable in the kernel config was just a var you could set in the local.conf | 14:04 |
| sean-k-mooney | although | 14:04 |
| sean-k-mooney | looking at it again | 14:04 |
| dansmith | it's not that easy | 14:04 |
| sean-k-mooney | you alls need to call make per module | 14:04 |
| sean-k-mooney | so ya never mind | 14:04 |
| dansmith | unless you want to build the whole kernel, you need to know configs and target module files, and the deps | 14:04 |
| bauzas | fwiw, this will actually depend on what we can do with live-migration :) | 14:05 |
| dansmith | but yeah, I'll extend this to do all the mdev samples | 14:05 |
| sean-k-mooney | dansmith: ya lets keep it simple | 14:05 |
| bauzas | if that's done per mtty, cool | 14:05 |
| dansmith | bauzas: oh I know, but we could also apply a patch here | 14:05 |
| bauzas | yeah, let's just start this simple with mtty | 14:05 |
| sean-k-mooney | bauzas: so this is useful even without live migration | 14:05 |
| bauzas | yup, definitely | 14:05 |
| sean-k-mooney | it woudl be a majory win just to get any coverage of mdevs | 14:06 |
| sean-k-mooney | so ya we can add follow up patches to do the nova config generation to enabel them | 14:06 |
| sean-k-mooney | but that would be good to do in the devstack plugin to | 14:07 |
| dansmith | yeah, point me at what I need to do config-wise | 14:07 |
| sean-k-mooney | you technnially dont need that since we can just shove config snipit into config via local.conf | 14:07 |
| dansmith | ack, but if it can do something for each sample it finds or something... | 14:08 |
| sean-k-mooney | am [device]enabled_mdev_types ... | 14:08 |
| sean-k-mooney | https://docs.openstack.org/nova/latest/configuration/config.html#devices.enabled_mdev_types | 14:08 |
| sean-k-mooney | there is an example in teh help text | 14:08 |
| sean-k-mooney | ah that raises a diffent point | 14:09 |
| sean-k-mooney | right now nova required the parent of the mdev to be a pci adress | 14:09 |
| sean-k-mooney | to use these modules we need to lift that limiation | 14:09 |
| dansmith | I really know nothing about mdevs.. once I insert the module is there a list of those types somewhere? or will the type just be mtty? | 14:09 |
| sean-k-mooney | when you insert the module you will be able to see mdev type under /sys | 14:09 |
| sean-k-mooney | it will be mtty-1 or mtty-2 | 14:12 |
| sean-k-mooney | for 1 port or 2 port serial device | 14:12 |
| sean-k-mooney | you can show them with tree /sys/devices/virtual/mtty/mtty/ | 14:12 |
| dansmith | ack | 14:14 |
| sean-k-mooney | the modifciation to make nova mdev support work is minor but nova will need to be twaked slightly as the way we create teh placement RP currenlty usees the parent pci adress in teh rp name | 14:14 |
| dansmith | ack, well, maybe worth getting ahead of that | 14:15 |
| dansmith | grr, my jammy machine is doing unattended upgrades.. I effing hate that new default behavior | 14:15 |
| sean-k-mooney | its been enabled by default i think since 20.04 | 14:15 |
| sean-k-mooney | but ya it ocationally breaks devstack | 14:16 |
| sean-k-mooney | when the apt lock is held by it | 14:16 |
| dansmith | it's just not something I want without being asked, on really any machine | 14:16 |
| sean-k-mooney | i think it defaults to security updates only | 14:16 |
| sean-k-mooney | so i get there intent | 14:17 |
| dansmith | it's just not something I want without being asked, on really any machine | 14:17 |
| sean-k-mooney | its actully an install option too but the cloud images default to it. but ya i get that | 14:17 |
| bauzas | I need to get my daugter from school but I'll be back in a sec | 14:25 |
| opendevreview | Pavlo Shchelokovskyy proposed openstack/nova master: Update disk.info in finish_migration https://review.opendev.org/c/openstack/nova/+/897842 | 14:46 |
| bauzas | dansmith: if you want me to look at that, lemme know | 15:00 |
| bauzas | I'll also compile the module in my own devstack instance | 15:00 |
| dansmith | bauzas: look at what? fixing the nova pci parent requirement? | 15:00 |
| dansmith | I forgot, I still have one other thing I need to fix, which is getting the version of the module to match the running kernel.. I'm not sure why that's not working, but I think it's because it's outside the debian build system | 15:03 |
| bauzas | dansmith: wdym about the pci parent requirement ? | 15:04 |
| dansmith | bauzas: see above from sean-k-mooney | 15:05 |
| bauzas | ah | 15:06 |
| bauzas | shit indeed | 15:06 |
| bauzas | -ETOOMANYTHINGSTODOATSAME | 15:07 |
| bauzas | dansmith: sean-k-mooney: we need the parent address to know which GPU this is using | 15:09 |
| dansmith | I think sean-k-mooney was implying that these devices don't have a pci parent | 15:10 |
| bauzas | https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L8029 | 15:12 |
| bauzas | yeah, but I guess those devices have a parent fortunately | 15:12 |
| bauzas | from what I can read, the parent is "virtual'" | 15:13 |
| bauzas | https://docs.kernel.org/driver-api/vfio-mediated-device.html#directories-and-files-under-the-sysfs-for-each-physical-device | 15:13 |
| bauzas | actually, no, its name is "mtty" | 15:14 |
| bauzas | https://github.com/torvalds/linux/tree/master/samples/vfio-mdev#using-the-mtty-vfio-mdev-sample-code | 15:14 |
| bauzas | so, somehow we would need to modify nova to say "meh, if the pci address is "mtty", don't change it" | 15:14 |
| sean-k-mooney | dansmith: correct it wont create a pci device | 15:29 |
| sean-k-mooney | bauzas: yep something like that i was thinig of a centinal like "virtual" | 15:30 |
| sean-k-mooney | instead of allowing any string | 15:30 |
| bauzas | should be something easy | 15:30 |
| bauzas | we have a few things to change, but that may work | 15:30 |
| bauzas | provided we indeed have some kind of global attribute | 15:31 |
| sean-k-mooney | i looke at the code a while ago we only realy use this for the placement rp name | 15:31 |
| bauzas | we key dicts on pci address | 15:31 |
| bauzas | but 'virtual' or whatever else (say mtty) works | 15:31 |
| sean-k-mooney | yep so we just need a hashable key which cna be the mdev_type | 15:31 |
| bauzas | no | 15:31 |
| sean-k-mooney | well thats what mtty would be | 15:32 |
| bauzas | https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L7976 | 15:32 |
| bauzas | we key types per pci device | 15:32 |
| *** haleyb_ is now known as haleyb | 15:32 | |
| bauzas | but this can be "for mtty those are the types it supports'" | 15:32 |
| sean-k-mooney | yes but i dont think you understaood what i was suggesting | 15:32 |
| bauzas | my bad then | 15:33 |
| sean-k-mooney | basiclly when we see virtual for the pci adress on the config i was suggeting we generate a identify such as virtual_<mdev-type> | 15:33 |
| sean-k-mooney | to use everywhere we actully woudl use the pci adress | 15:33 |
| bauzas | ah | 15:33 |
| bauzas | well, technically the virtual device has N possible types | 15:34 |
| sean-k-mooney | but we could just leave it as a stirng and see on this is not a real pci adres just pass it as is | 15:34 |
| sean-k-mooney | ya it does and unlike some hardware | 15:34 |
| bauzas | for config options, we can just leave it to be 'virtual' | 15:34 |
| sean-k-mooney | they are consumable indepently i belive | 15:34 |
| bauzas | we just parse the option here https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L7971 | 15:35 |
| bauzas | but I guess we can accept if it's the global attribute name | 15:35 |
| bauzas | that said, nothing to be documented | 15:35 |
| sean-k-mooney | bauzas: for what tis worht the parent of the device is libvirt is going to be the root device | 15:35 |
| bauzas | sean-k-mooney: well, if I'm relying on sysfs, this is unfortunately 'mtty' if the path is /sys/devices/virtual/mtty/mtty/ | 15:38 |
| bauzas | https://docs.kernel.org/driver-api/vfio-mediated-device.html#directories-and-files-under-the-sysfs-for-each-physical-device | 15:38 |
| sean-k-mooney | yes | 15:39 |
| sean-k-mooney | the mtty module only create 1 virtual device | 15:40 |
| sean-k-mooney | so it will by mtty | 15:40 |
| sean-k-mooney | that also why i suggested using virtual as the placeholder :) | 15:40 |
| sean-k-mooney | so we could use virtual/mtty/mtty or simial as the place holder but i didnt really want to fully log the thing to the sys layout | 15:41 |
| sean-k-mooney | when using the netdev sim module for vdpa | 15:41 |
| sean-k-mooney | you can have it create muplie virutal devices | 15:41 |
| sean-k-mooney | i guess we can keep it simple and just start with one | 15:42 |
| bauzas | yeah, I don't disagree with you | 15:43 |
| bauzas | doh, forgot the reminder and the agenda | 15:53 |
| bauzas | reminder: nova meeting in 6 mins | 15:53 |
| bauzas | her. | 15:53 |
| bauzas | here. | 15:53 |
| * bauzas runs errand to write some agenda | 15:54 | |
| bauzas | #startmeeting nova | 16:00 |
| opendevmeet | Meeting started Tue Oct 10 16:00:13 2023 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 |
| bauzas | #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting | 16:00 |
| bauzas | hello everyone, a bit busy today but let's run it quickly | 16:00 |
| elodilles | o/ | 16:00 |
| han-guangyu | o/ | 16:00 |
| gmann | o/ | 16:01 |
| bauzas | ok, I guess we can softly start | 16:01 |
| bauzas | #topic Bugs (stuck/critical) | 16:02 |
| bauzas | #info No Critical bug | 16:02 |
| bauzas | #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 46 new untriaged bugs (+2 since the last meeting) | 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 | melwitt: around ? | 16:02 |
| Uggla | o/ | 16:03 |
| gibi | o~ | 16:04 |
| gibi | I did not manage to look at bugs. Sorry | 16:04 |
| bauzas | np | 16:05 |
| bauzas | okay let's continue | 16:07 |
| bauzas | #info bug baton is melwitt | 16:08 |
| bauzas | #info https://bugs.launchpad.net/nova/+bug/2026345 failed for nova few times. | 16:08 |
| bauzas | #topic Gate status | 16:09 |
| bauzas | #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs | 16:10 |
| bauzas | #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&pipeline=periodic-weekly Nova&Placement periodic jobs status | 16:10 |
| bauzas | #info Please look at the gate failures and file a bug report with the gate-failure tag. | 16:11 |
| bauzas | anything to discuss ? | 16:11 |
| bauzas | looks not | 16:12 |
| bauzas | #topic Release Planning | 16:12 |
| bauzas | #link https://releases.openstack.org/caracal/schedule.html | 16:12 |
| bauzas | #info Nova deadlines are not yet defined and will be once the PTG happens | 16:12 |
| bauzas | #info Caracal-1 milestone in 5 weeks | 16:12 |
| bauzas | again, any questions so far , | 16:12 |
| bauzas | ? | 16:12 |
| sean-k-mooney | nope | 16:13 |
| bauzas | continuing so | 16:13 |
| bauzas | #topic Caracal vPTG planning | 16:13 |
| bauzas | #info Sessions will be held virtually October 23-27 | 16:13 |
| bauzas | #info Register yourselves on https://ptg2023.openinfra.dev/ even if the event is free | 16:13 |
| bauzas | #link https://etherpad.opendev.org/p/nova-caracal-ptg PTG etherpad | 16:13 |
| bauzas | #info add your own topics into the above etherpad if you want them to be discussed at the PTG | 16:13 |
| bauzas | that's it | 16:13 |
| bauzas | we already have a few topics, thanks folks who added them | 16:14 |
| bauzas | but please continue to add some if you want | 16:14 |
| bauzas | #topic Review priorities | 16:14 |
| bauzas | #link https://review.opendev.org/q/status:open+(project:openstack/nova+OR+project:openstack/placement+OR+project:openstack/os-traits+OR+project:openstack/os-resource-classes+OR+project:openstack/os-vif+OR+project:openstack/python-novaclient+OR+project:openstack/osc-placement)+(label:Review-Priority%252B1+OR+label:Review-Priority%252B2) | 16:14 |
| bauzas | #info As a reminder, people eager to review changes can +1 to indicate their interest, +2 for asking cores to also review | 16:14 |
| bauzas | I said I was about to propose a Gerrit dashboard for those, I had no time yet to do it | 16:15 |
| bauzas | #action bauzas to propose a Gerrit dash | 16:15 |
| bauzas | #topic Stable Branches | 16:15 |
| bauzas | elodilles: ? | 16:15 |
| elodilles | yepp | 16:15 |
| elodilles | i'm not aware of any gate issue | 16:15 |
| elodilles | otherwise nothing else to report | 16:15 |
| elodilles | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | 16:15 |
| elodilles | please add stable gate issues if you see any ^^^ | 16:16 |
| bauzas | ++ | 16:16 |
| elodilles | that's all from me | 16:16 |
| bauzas | cool | 16:17 |
| bauzas | #topic Open discussion | 16:19 |
| bauzas | (bauzas) Specless blueprint approval for https://blueprints.launchpad.net/nova/+spec/aggregatemultitenancyisolation-to-support-unlimited-tenant | 16:19 |
| sean-k-mooney | hum | 16:20 |
| bauzas | wdyt about that ? | 16:20 |
| sean-k-mooney | dont we support having multiple keys | 16:21 |
| sean-k-mooney | so i didnt think there was an effective limit today | 16:21 |
| sean-k-mooney | or parhaps we require one aggreate per tenatnt today i would have to review the code | 16:22 |
| sean-k-mooney | the patch is basiclly enabling what i orgianlly tought already worked | 16:23 |
| sean-k-mooney | instead of looking for filter_tenant_id explictly | 16:23 |
| sean-k-mooney | just making that a prefix | 16:23 |
| sean-k-mooney | so you can have filter_tenant_id=<tenant-0> filter_tenant_id_1=<tenant-1> | 16:24 |
| sean-k-mooney | thats proably an ok change to make | 16:24 |
| * dansmith stumbles in late | 16:24 | |
| sean-k-mooney | tenant isolation shoudl be done via placement | 16:25 |
| sean-k-mooney | and we shoudl really be removing the filter based approch so im not sure | 16:25 |
| bauzas | sahid wanted to still use the filters | 16:27 |
| sean-k-mooney | i would be in favor of deprecateding it for removal in D if the current fucntionlaiy is supproted by the placment approch | 16:27 |
| sean-k-mooney | https://docs.openstack.org/nova/latest/admin/aggregates.html#tenant-isolation-with-placement | 16:28 |
| dansmith | tenant isolation can't be done entirely in placement right? | 16:28 |
| bauzas | I think sahid actually wanted to backport this | 16:28 |
| sean-k-mooney | i belive it can | 16:28 |
| dansmith | all we can do is select an aggregate and then get placement to limit for us | 16:29 |
| bauzas | you know what ? we can punt this until he can be around | 16:29 |
| sean-k-mooney | so given this dicussion i would say not a specless blueprint | 16:29 |
| sean-k-mooney | spec or ptg discussion | 16:29 |
| dansmith | right | 16:29 |
| sean-k-mooney | i think the fucntionaliyt is possible today withthe placement approch so i would question why we dont remove the filter | 16:30 |
| sean-k-mooney | so i would like to capture the answer to that | 16:30 |
| bauzas | okay, let's say this | 16:31 |
| bauzas | I'll tell this to sahid tomorrow | 16:31 |
| bauzas | and he could explain why he still wants to use filters | 16:32 |
| bauzas | (IMHO like I said, backports) | 16:32 |
| bauzas | do all agree ? | 16:32 |
| sean-k-mooney | backports are a downstream problem | 16:32 |
| bauzas | sure, but this is easier with a python module like a filter, right?. | 16:33 |
| sean-k-mooney | that is not a good reason to extend it upstream unless its useful upstream | 16:33 |
| bauzas | sure, we need to discuss the usecases | 16:33 |
| bauzas | but I'm not in favor of removing every single filter we have | 16:33 |
| dansmith | agree | 16:33 |
| bauzas | some operators still run filters on their choices | 16:33 |
| bauzas | anyway, let's punt this until PTG or when sahid can join us | 16:34 |
| dansmith | we have the prefilter for isolation, which uses placement's aggregates to do some isolation, but I'll have to revisit my understanding of the differences | 16:34 |
| bauzas | #agreed defer this agreement to the next PTG | 16:34 |
| bauzas | I'll add a topic in the PTG etherpad | 16:34 |
| sean-k-mooney | dansmith: we deveoped that prefilter to eventurlly remove this one | 16:34 |
| sean-k-mooney | https://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/placement-req-filter.html#proposed-change | 16:36 |
| bauzas | sean-k-mooney: well, for CPUFilter, I totally agree with removing it | 16:36 |
| sean-k-mooney | this was the first prefilter that you wote many moons ago | 16:36 |
| bauzas | I'm just saying that for non-allocatable filters (placing things) we may leave those if those are cheap to maintain | 16:37 |
| sean-k-mooney | right but this filter is know to be problematic | 16:37 |
| bauzas | because this is a python module and not another SQL query | 16:37 |
| sean-k-mooney | so i realy dont think this is a good example ot extned | 16:37 |
| dansmith | sean-k-mooney: I know, but I think there were limitations | 16:37 |
| bauzas | anyway, we punted the potential agreement to the next PTG | 16:38 |
| dansmith | I thought we agreed to punt until PTG ? | 16:38 |
| dansmith | yeah | 16:38 |
| bauzas | so let's stop for now | 16:38 |
| sean-k-mooney | sure | 16:38 |
| bauzas | and I'll give you all extra 20 mins of your time | 16:38 |
| bauzas | thanks all | 16:38 |
| bauzas | any other item before we close ? | 16:38 |
| sean-k-mooney | i just wanted to highlight i reporposed the healtcheck spec https://review.opendev.org/c/openstack/nova-specs/+/897225 | 16:39 |
| bauzas | oh right, I've seen it | 16:39 |
| sean-k-mooney | so if we can reappove that it would be good | 16:39 |
| bauzas | I just need to look at it | 16:39 |
| sean-k-mooney | ack | 16:39 |
| sean-k-mooney | thats all from me | 16:39 |
| bauzas | tuesdays are usually upstream days for me, but I was vamped into some crazy internal thing | 16:39 |
| bauzas | anyway, ending now | 16:39 |
| bauzas | thanks all | 16:40 |
| bauzas | #endmeeting | 16:40 |
| opendevmeet | Meeting ended Tue Oct 10 16:40:04 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:40 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2023/nova.2023-10-10-16.00.html | 16:40 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2023/nova.2023-10-10-16.00.txt | 16:40 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2023/nova.2023-10-10-16.00.log.html | 16:40 |
| sean-k-mooney | bauzas: if your looking at repoposals then https://review.opendev.org/c/openstack/nova-specs/+/895924 would be alos nice to look at | 16:40 |
| bauzas | yeah I need to do reviews | 16:40 |
| bauzas | my gerrit nova-specs dashboard misses me | 16:40 |
| opendevreview | Dan Smith proposed openstack/nova master: WIP: Compile mdev samples for nova-next https://review.opendev.org/c/openstack/nova/+/897708 | 16:42 |
| dansmith | okay locally mtty.ko gets built and inserted during devstack | 16:42 |
| bauzas | <3 | 16:43 |
| bauzas | if I have time tomorrow, I'll work on a nova WIP to change the libvirt driver to use a specific 'virtual' device for mtty | 16:44 |
| bauzas | so we shall be able to test | 16:45 |
| opendevreview | Dan Smith proposed openstack/nova master: WIP: Compile mdev samples for nova-next https://review.opendev.org/c/openstack/nova/+/897708 | 16:58 |
| dansmith | 2023-10-10 17:19:30.033749 | controller | ++ /opt/stack/nova/devstack/lib/mdev_samples:compile_mdev_samples:28 : grep mdev | 17:21 |
| dansmith | 2023-10-10 17:19:30.055298 | controller | mdev 28672 1 mtty | 17:21 |
| dansmith | \o/ | 17:21 |
| sean-k-mooney | cool | 17:42 |
| sean-k-mooney | we dont do a virsh nodedev-list in the ci logs do we | 17:42 |
| sean-k-mooney | i woudl assume not | 17:42 |
| dansmith | idk, but I just ran that locally and I don't see any mdev stuff in there | 17:54 |
| sean-k-mooney | i think they only show up when you create one | 17:54 |
| sean-k-mooney | its also cached when libvirt starts | 17:54 |
| sean-k-mooney | so if it starts before the module is loaded that could be an issue | 17:54 |
| sean-k-mooney | restarting libvirt clears the cache | 17:54 |
| sean-k-mooney | can you try " echo "83b8f4f2-509f-382f-3c1e-e6bfe0fa1001" > \ | 17:56 |
| sean-k-mooney | /sys/devices/virtual/mtty/mtty/mdev_supported_types/mtty-2/creat""" | 17:56 |
| dansmith | mdev_83b8f4f2_509f_382f_3c1e_e6bfe0fa1001_mtty | 17:57 |
| sean-k-mooney | cool | 17:57 |
| dansmith | looks like it works | 17:57 |
| sean-k-mooney | so nova has two modes of opertation | 17:57 |
| sean-k-mooney | you can either precreate the mdevs and it will use them | 17:57 |
| sean-k-mooney | or it will create tehm if you dont | 17:58 |
| sean-k-mooney | but ya from a qemu/libvirt point of view i think that means its workign | 17:58 |
| dansmith | sweert | 17:58 |
| sean-k-mooney | oh right it was out of tree.. | 18:03 |
| sean-k-mooney | for what its worht this is how you boot a vm in nova with hardware offloaded networkign using mdev before that is merged in qemu/libvirt/the kernel https://github.com/openstack/nova/commit/13de00c20477189201f102499cc6451f47765c5c | 18:07 |
| sean-k-mooney | that is not relevent beyond the fact i was checkign how we configured the mdevs and vf via the devstack plugin | 18:10 |
| sean-k-mooney | https://github.com/intel-orchestration-software/networking-vhost-vfio/blob/master/devstack/libs/vhost-vfio#L367-L393 | 18:10 |
| sean-k-mooney | so we just allocated the vf on the defice and created the mdevs dymically in nova | 18:11 |
| sean-k-mooney | so not really relevent in this case since there are no vfs to allcoate | 18:11 |
| tobias-urdin | any good idea's on how one should handle cputune.shares issues on stable releases? https://bugs.launchpad.net/nova/+bug/1978489 – last comment in https://gitlab.com/libvirt/libvirt/-/issues/161 aged well "...I think this problematic change is only now starting to hit people" oh yes it will :) | 18:22 |
| sean-k-mooney | we partly fixed this | 18:45 |
| sean-k-mooney | we stopped generating implcit cpu shares in zed i belvie | 18:45 |
| sean-k-mooney | and we basically say dont use the explit ones | 18:45 |
| sean-k-mooney | we have not removed/depreated the feature entirly | 18:46 |
| sean-k-mooney | simply because we have never done that before | 18:46 |
| sean-k-mooney | but perfonslly i would fix it by deprecateing them on master for caracal and delete the feature in D | 18:46 |
| sean-k-mooney | tobias-urdin: proably not waht you want to hear so the more helpful answer is | 18:46 |
| sean-k-mooney | you need to reize today before you upgrade | 18:47 |
| sean-k-mooney | we could also add a nova manage command liek https://github.com/openstack/nova/blob/master/nova/cmd/manage.py#L3211 | 18:47 |
| sean-k-mooney | to allow updating the embded flavor extra specs | 18:48 |
| sean-k-mooney | that not negerally safe but in this case it is | 18:48 |
| tobias-urdin | thanks, yeah it was an interesting read for sure and something i completely missed last year | 19:05 |
| tobias-urdin | imo the approach taken in libvirt is pretty bad, im kinda sad it wasn't better handled at all in https://gitlab.com/libvirt/libvirt/-/issues/161 either | 19:06 |
| tobias-urdin | fortunately is that we dont set it as extra specs but we do however have large instances that will be impacted just based on the cpu.shares value being greater than the limit there | 19:07 |
| tobias-urdin | so for us on yoga i guess i'll just have to carry that patch until i'm on zed, shouldn't be that long | 19:07 |
| tobias-urdin | im just a little bit scared about the impact for large instances removing that entirely but i guess i dont have a choice, i felt like scaling the value for cgroupv2 in cputune.shares and introducing a new cputune.weight was more elegant, anyway | 19:11 |
| * tobias-urdin signs out for today | 19:17 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!