| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-26 | |||
| 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/ | |
| 15:03:38 | mriedem | edleafe: wondering if we should use the existing SchedulerLimits object to contain the limits/numa_limit fields | |
| 15:03:41 | mriedem | like the reqspec | |
| 15:04:18 | openstackgerrit | Merged openstack/nova master: Accept all standard resource classes in flavor extra specs https://review.openstack.org/514942 | |
| 15:04:25 | edleafe | mriedem: things have come full circle :) | |
| 15:04:34 | mriedem | you started with that? | |
| 15:04:49 | edleafe | Is the plan that limits would be something that is not going away? | |
| 15:05:10 | mriedem | they aren't going away in the near future | |
| 15:05:14 | mriedem | why does that matter? | |
| 15:05:26 | bauzas | -ETOOMANYTHINGSTODO | |
| 15:06:11 | edleafe | It was Jay's comment that limits are going away that got me to drop limits | |
| 15:07:08 | dansmith | what does that have to do with how we put it in the object, if we know we need them for the short term? | |
| 15:07:19 | mriedem | right - we need to pass limits down either way | |
| 15:07:24 | mriedem | we are still supporting the caching scheduler | |