Earlier  
Posted Nick Remark
#openstack-nova - 2017-10-26
13:59:45 bauzas sahid: unless mediated devices become persistent upon reboot :)
14:00:08 sahid bauzas: what i could say is that, for SR-IOV we ask operator to allocate the VFs
14:00:16 openstackgerrit Alex Xu proposed openstack/nova master: Add _get_traits_by_rp_ids method https://review.openstack.org/511184
14:00:16 openstackgerrit Alex Xu proposed openstack/nova master: Enable _get_usages_by_provider_and_rc not filter on the resource class id https://review.openstack.org/514649
14:00:17 openstackgerrit Alex Xu proposed openstack/nova master: Add more caches for the ProviderSummary and ProviderSummaryList https://review.openstack.org/514199
14:00:17 openstackgerrit Alex Xu proposed openstack/nova master: Add ProviderSummaryList object https://review.openstack.org/514198
14:00:18 openstackgerrit Alex Xu proposed openstack/nova master: Add has_resources method to the AggregatedProviderSummary object https://review.openstack.org/514650
14:00:18 openstackgerrit Alex Xu proposed openstack/nova master: Add AggregatedProviderSummary and AggregatedProviderSummaryList objects https://review.openstack.org/514200
14:00:19 openstackgerrit Alex Xu proposed openstack/nova master: placement: rewrite AllocationCandidates.get_by_filters https://review.openstack.org/479766
14:00:19 openstackgerrit Alex Xu proposed openstack/nova master: Add as_allocation_request_obj method to AggregatedProvierSummary obj https://review.openstack.org/514651
14:00:20 openstackgerrit Eric Fried proposed openstack/nova master: Reformat _get_all_with_shared https://review.openstack.org/512799
14:00:25 sahid if host is rebooting the operator can have the module to pre-allocate VFs anyway
14:00:37 sahid but without the insurance that the PCI addresses will be the same as previously
14:00:47 bauzas sahid: but the domain XML will be incorrect then, right?
14:00:51 dansmith stephenfin: can you fix that typo in the commit message and then I'll fast approve?
14:00:52 sahid right
14:01:00 bauzas sahid: if the VF is on the wrong PCI device
14:01:01 sahid so operator have to deal with that
14:01:09 bauzas sahid: how can they deal with that ?
14:01:09 alex_xu efried: ^ more todo, some of them is more interest than unittest,
14:01:21 openstackgerrit Stephen Finucane proposed openstack/nova master: conf: Move additional nova-net opts to 'network' https://review.openstack.org/499168
14:01:22 sahid reboot --force
14:01:22 dansmith stephenfin: or I can just do it in the ui I guess
14:01:29 stephenfin dansmith: Done
14:01:30 bauzas sahid: they dump all the instances XML before starting nova-compute?
14:01:32 stephenfin ...from the UI :)
14:01:52 efried alex_xu Ack
14:01:54 dansmith stephenfin: done
14:01:59 bauzas sahid: but a reboot breaks existing instances using VFs, right?
14:02:29 bauzas since as you said, there is no guarantee that the newly created VF will match the one descibed in the domain XML
14:02:44 sahid bauzas: there are some limitations, it's clear... what i'm trying to say is, if you can make them clear for your implementation so operator could deal with them
14:03:55 sahid the libvirt design merged upstream for pci devices does not manage the devices
14:04:13 bauzas sahid: I'm thinking about the fact that if I'm implementing something like nova creating the mdevs directly, we could just ask the operator to restart their libvirt deamon right after they start nova-computez
14:04:14 sahid you could try to do it in nova
14:04:19 sahid but that seems to be complicated
14:04:48 sahid bauzas: what about to ask operator to do a force reboot?
14:05:01 dansmith bauzas: restarting libvirt after nova-compute isn't reasonable, IMHO
14:05:09 dansmith or starting
14:05:27 sahid we have to double check but with a force-reboot we recreating the domainXML from scratch
14:06:35 sahid dansmith is right
14:06:35 alex_xu cdent: yea, always be interrupted, like meeting...
14:06:53 bauzas dansmith: that's a separate problem
14:07:06 bauzas dansmith: there are two issues with libvirt managing mdevs
14:07:40 bauzas dansmith: #1 is that mdevs aren't persistent upon reboots
14:08:03 bauzas dansmith: #2 is that there is a kernel bug that prevents newly created mdevs to be seen by libvirt
14:08:39 bauzas for #1, my take is that we shouldn't leave the operators deal with the mess of recreating specific mdevs based on specific UUIDs
14:08:52 bauzas rather, it should be nova that should deal with that
14:09:06 dansmith yeah
14:09:08 bauzas for #2, it's just a kernel bug that is tackled by https://bugzilla.redhat.com/show_bug.cgi?id=1463285#c6
14:09:09 openstack bugzilla.redhat.com bug 1463285 in libvirt "mediated devices are not shown in nodedev-list --cap mdev output" [High,Post] - Assigned to eskultet
14:09:23 bauzas then, it's unrelated to nova
14:09:35 dansmith if restarting libvirt is a requirement as a workaround for a bug that will be fixed, then that's fine
14:09:47 openstackgerrit Hongbin Lu proposed openstack/nova stable/pike: Handle exception on adding secgroup https://review.openstack.org/515418
14:09:47 bauzas but we could workaround that by asking operators to restart their libvirt deamon
14:10:00 dansmith but yeah, if nova is creating mdevs with uuids and then we lose those on reboot, we have to recreate them, IMHO
14:10:03 bauzas dansmith: that's my point, it's just a stupid workaround
14:10:09 dansmith ack, makes sense
14:11:01 bauzas and with some hope, distributions would ship the right fixed kernel
14:11:28 bauzas or the fix could be backported in the supported kernel, either way
14:12:12 bauzas sahid: dansmith: wait, I have another idea
14:12:38 bauzas oVirt does get the mdev list by not calling the libvirt API, but rather directly checking the FS
14:12:58 bauzas that's why they're not impacted by the bug
14:13:14 bauzas that could be another idea
14:13:28 bauzas although I definitely prefer to use the libvirt API
14:13:40 openstackgerrit Hongbin Lu proposed openstack/nova stable/ocata: Handle exception on adding secgroup https://review.openstack.org/515421
14:14:13 dansmith bauzas: it would be better to use libvirt too, but using sysfs directly isn't terrible.. however, if it's just a bug that will be fixed, it's not worth spending time on, IMHO
14:14:24 bauzas yeah hopefully
14:14:50 bauzas it's just a matter of correctly designing the interface for getting the mdevs
14:15:05 bauzas how we're getting them is just an implementation detail
14:19:48 openstackgerrit sean mooney proposed openstack/nova master: [WIP] add vif info to migration object https://review.openstack.org/515423
14:20:42 cdent jaypipes: responded to your query about empty allocations, it’s for the eventual use in POST, and at the api level it is only allowed in POST, not PUT. dansmith may have additional input.
14:21:26 dansmith cdent: jaypipes: we need to be able to *atomically* replace an allocation with one from a different consumer, so we need to be able to nuke one and replace one in a single post
14:24:32 mriedem bauzas: you could add a workarounds config option to fallback to check the filesystem using privsep if you can't discover mdevs via the libvirt api
14:24:42 mriedem so people affected by the bug could turn that option on
14:24:48 mriedem and it sets a timer on when we remove the workaround
14:26:46 bauzas mriedem: I thought on that, glad we're on the same page
14:27:00 bauzas mriedem: I'll either way need to use privsep for creating the mdev
14:27:15 bauzas mriedem: because there is nothing in the libvirt API, that's a sysfs call
14:30:40 mriedem stvnoyes: https://review.openstack.org/515426
14:47:04 openstackgerrit Sylvain Bauza proposed openstack/nova master: vgpu: add enabled white list https://review.openstack.org/512580
14:54:22 openstackgerrit Stephen Finucane proposed openstack/nova master: conf: Remove 'vendordata_driver' opt https://review.openstack.org/397835
14:55:01 bauzas sahid: I don't understand exactly what you want as a format for https://review.openstack.org/#/c/514763/5/nova/virt/libvirt/config.py@2481
14:55:13 bauzas sahid: you want a dictionary of dictionaries ?
14:55:48 bauzas I'm fully open to ideas for a clear attribute
14:58:29 sahid bauzas: we have an instance of this class for each mdev device, right? no need of dictionary of dictionaries, a dictionary is enough
14:58:53 bauzas sahid: no
14:59:06 bauzas sahid: we have the list of all the supported types for that specific device
14:59:32 bauzas sahid: with each type, we get the deviceAPI, availableInstances and the optional name
14:59:34 sahid oh yes it's the mdev capabilities of the pci device
14:59:49 sahid list of dict, no?
14:59:49 bauzas yup, that https://libvirt.org/drvnodedev.html#MDEVCap
14:59:57 bauzas that's what I wrote :p
15:00:21 bauzas the brackets could have confused you but it's not a list of tuples
15:00:21 sahid :)
15:00:40 bauzas I'll remove them to clarify
15:01:09 sahid no no it's your comment the example which confused me, but it's my mistake I should have read better than that
15:01:56 bauzas I do wonder if I should use a namedtuple
15:02:08 bauzas but let's see what other think
15:02:12 bauzas others*
15:03:24 mriedem edleafe: bauzas: dansmith: jaypipes: a shmorgasbord of comments in the Selection object patch https://review.openstack.org/#/c/499239/

Earlier   Later