| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-26 | |||
| 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 | alex_xu | cdent: yea, always be interrupted, like meeting... | |
| 14:06:35 | sahid | dansmith is right | |
| 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 | bauzas | but we could workaround that by asking operators to restart their libvirt deamon | |
| 14:09:47 | openstackgerrit | Hongbin Lu proposed openstack/nova stable/pike: Handle exception on adding secgroup https://review.openstack.org/515418 | |
| 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 | bauzas | yup, that https://libvirt.org/drvnodedev.html#MDEVCap | |
| 14:59:49 | sahid | list of dict, no? | |
| 14:59:57 | bauzas | that's what I wrote :p | |
| 15:00:21 | sahid | :) | |
| 15:00:21 | bauzas | the brackets could have confused you but it's not a list of tuples | |
| 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 | |
| 15:07:39 | mriedem | so do we pass them differently from the requestspec when we already have an object that handles the exact same thing? | |
| 15:07:45 | mriedem | i'd rather just re-use SchedulerLimits | |
| 15:08:27 | edleafe | ok, if that's the current feeling | |
| 15:08:35 | edleafe | I'll get started on that soon | |
| 15:09:10 | mriedem | cool. i also tried to document some of the discussion we had in irc with dansmith a week or two ago about how redundant this all is with passing limits to compute in 3 different ways now, | |
| 15:09:16 | mriedem | and that there isn't really a way around that for the time being | |
| 15:09:25 | mriedem | and eventually the legacy filter props *should* go away | |
| 15:09:45 | dansmith | ah | |
| 15:10:09 | dansmith | edleafe: that SchedulerLimits object calls out the few limits we have specifically, which is better than just a dict of ints, yeah | |
| 15:10:12 | dansmith | even more confined | |
| 15:10:19 | dansmith | I didn't realize we had this | |
| 15:10:24 | edleafe | dansmith: gotcha | |
| 15:10:33 | edleafe | dansmith: I didn't know about it either | |
| 15:14:14 | jaypipes | mriedem: so this one of your comments on a previous patchset should be ignored? "Given that, I think it's OK to restrict the limits field value to only things that we know about for in-tree filters and how limits are used in the claim/resource tracker code. Filters are pluggable, but the resource tracker is not." | |
| 15:15:14 | dansmith | no? | |
| 15:15:35 | dansmith | we're still talking about restricting the limits to the ones we know about | |
| 15:15:40 | dansmith | we just can't get rid of them just yet | |
| 15:15:43 | jaypipes | dansmith: ok. | |
| 15:16:08 | jaypipes | dansmith: but we're only keeping them for the caching scheduler users, *not* because of out of tree filters. correct? | |
| 15:16:20 | edleafe | dansmith: question: if SchedulerLimits is already part of the reqspec object, why is it needed in the Seleciton object at all? | |
| 15:16:21 | dansmith | jaypipes: that's what his comment is saying | |
| 15:16:26 | jaypipes | dansmith: ok. | |
| 15:16:34 | dansmith | edleafe: because it differs per host | |
| 15:17:06 | dansmith | edleafe: and because we have to pass at least ten copies of limits to the compute node or we lose our heavyweight championship title | |