| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-03 | |||
| 13:36:08 | sfinucan | once we've executed that many attach operations, that is | |
| 13:36:16 | jaypipes | sfinucan: oh, I see what you mean... meh, not sure I'm too concerned about that. | |
| 13:36:51 | sfinucan | jaypipes: Think it's a small enough edge case to ignore so? | |
| 13:37:08 | jaypipes | sfinucan: yeah. considering rebooting the VM would "clear that out", right? | |
| 13:38:08 | sfinucan | jaypipes: I don't think so? The XML isn't rebuilt on a reboot, right? Only a resize/migrate? | |
| 13:38:35 | jaypipes | sfinucan: is it? I thought it was rebuilt on reboot... | |
| 13:42:51 | sfinucan | jaypipes: Looks like the complete rebuild only happens if libvirt doesn't support 'reset' https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L2422-L2424 | |
| 13:43:30 | sfinucan | However, it is an edge case. I'll wait an see what sahid says and if he's OK with it, it can slide | |
| 13:44:28 | jaypipes | https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L2428 | |
| 13:44:31 | jaypipes | sfinucan: ^ | |
| 13:45:20 | openstackgerrit | Ildiko Vancsa proposed openstack/nova master: WIP/POC Implement new attach Cinder flow https://review.openstack.org/330285 | |
| 13:45:28 | sfinucan | jaypipes: The comments lie. Grr | |
| 13:47:28 | sfinucan | That wouldn't be the case for soft_reboot though, I guess - I've yet to see any undefine calls yet https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L2384-L2385 | |
| 13:48:26 | jaypipes | sfinucan: no, I'm referring to a hard reboot. | |
| 13:53:15 | sfinucan | Folks with +2 permissions: would appreciate reviews on this series today --> https://review.openstack.org/#/q/topic:doc-migration+project:openstack/nova | |
| 13:53:20 | sfinucan | I want to get started on moving the guides from openstack-manuals in here this week | |
| 14:02:27 | alex_xu | looks like we don't have scheduler meeting today | |
| 14:02:37 | jaypipes | sfinucan: ++ | |
| 14:02:54 | jaypipes | alex_xu: I'm always happy to chat about scheduler :) | |
| 14:03:02 | jaypipes | alex_xu: but yeah, a number of US folks are out. | |
| 14:03:19 | alex_xu | jaypipes: ah, holiday? | |
| 14:04:34 | jaypipes | alex_xu: July 4th tomorrow so lots of folks taking today off too. | |
| 14:04:48 | alex_xu | jaypipes: cool, got it | |
| 14:18:03 | sfinucan | moshele: You about. I've a question about SR-IOV devices and PCI affinity | |
| 14:19:29 | sfinucan | moshele: Namely, if I boot a VM with an SR-IOV device, then will that VM be forced to use CPUs from the same NUMA node as the actual PCI device. I thought this was the case | |
| 14:20:23 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: scheduler uses allocation candidates https://review.openstack.org/476631 | |
| 14:20:24 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: support GET /allocation_candidates https://review.openstack.org/475448 | |
| 14:20:24 | openstackgerrit | Jay Pipes proposed openstack/nova master: WIP - placement: claim resources in scheduler https://review.openstack.org/476632 | |
| 14:21:41 | openstackgerrit | dane-fichter proposed openstack/nova master: Mask password when logging connection_info during swap volume https://review.openstack.org/466533 | |
| 14:27:32 | moshele | sfinucan: this is what was implemented https://review.openstack.org/#/c/140290/ | |
| 14:29:30 | mriedem | wubba wubba wubba | |
| 14:30:13 | moshele | sfinucan: is that answer you question? | |
| 14:31:10 | mriedem | jaypipes: so you fixed the pep8 issue in https://review.openstack.org/#/c/475448/ but did you see the functional tests failing listing traits? | |
| 14:31:18 | mriedem | something going on with the lock or loading traits from the library it seems | |
| 14:31:38 | mriedem | http://logs.openstack.org/48/475448/21/check/gate-nova-tox-functional-ubuntu-xenial/59c59c0/console.html#_2017-07-01_01_12_45_285206 | |
| 14:31:45 | mriedem | i could recreate it locally, but couldn't figure out what was causing it | |
| 14:32:46 | jaypipes | mriedem: I thought edleafe- had fixed that in a patch last week... lemme check. | |
| 14:33:26 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: scheduler uses allocation candidates https://review.openstack.org/476631 | |
| 14:33:27 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: support GET /allocation_candidates https://review.openstack.org/475448 | |
| 14:33:28 | openstackgerrit | Jay Pipes proposed openstack/nova master: WIP - placement: claim resources in scheduler https://review.openstack.org/476632 | |
| 14:33:32 | jaypipes | mriedem: pulled in master ^^ | |
| 14:33:45 | jaypipes | mriedem: I think that func test failure is fixed. | |
| 14:33:45 | sfinucan | moshele: Kind of. That's for PCI devices, but would that include VF devices? | |
| 14:33:47 | sfinucan | I guess | |
| 14:33:51 | jaypipes | mriedem: will see in about an hour ;) | |
| 14:33:58 | sfinucan | * I assume it would, but I'm not sure | |
| 14:34:00 | moshele | sfinucan | |
| 14:34:00 | moshele | moshele | |
| 14:34:06 | mriedem | jaypipes: ok i can hunt for a recent change related to that | |
| 14:34:11 | mriedem | unless edleafe- can point it out quick | |
| 14:34:12 | moshele | sfinucan: yes it is the same code | |
| 14:34:21 | jaypipes | mriedem: gimme a sec. | |
| 14:34:31 | moshele | sfinucan: VF is eventually a pci device | |
| 14:35:02 | jaypipes | mriedem: edl | |
| 14:35:08 | jaypipes | mriedem: edl | |
| 14:35:11 | jaypipes | oh ffs. | |
| 14:35:18 | jaypipes | https://review.openstack.org/#/c/478564/ | |
| 14:35:20 | jaypipes | mriedem: ^^ | |
| 14:35:28 | jaypipes | `damn paste buffers. | |
| 14:35:29 | sfinucan | moshele: Right, that's what I thought. However, I've an instance with an OVS-DPDK-managed PCI device on node 1, and it's booting on node 0 | |
| 14:35:44 | sfinucan | Must be something to do with OVS-DPDK aspect of it, and how it's being attached to the instance | |
| 14:35:47 | mriedem | jaypipes: oh nice | |
| 14:35:49 | mriedem | whew | |
| 14:36:15 | moshele | sfinucan: did you puth the numa filter ? and what libvirt verions are you using? | |
| 14:36:48 | jaypipes | back in a bit. | |
| 14:37:26 | sfinucan | moshele: I'm not doing it personally, but I'd assume you'd need that filter for things to even boot. I will ask though | |
| 14:38:23 | sfinucan | fwiw, all the logs are here. I'm guessing it's accessible outside RH? https://bugzilla.redhat.com/show_bug.cgi?id=1459543 | |
| 14:38:23 | openstack | bugzilla.redhat.com bug 1459543 in openstack-nova "Virt NUMA placements on NUMA1 using flavor extra specs - places Virt guest on NUMA0" [Medium,Assigned] - Assigned to sfinucan | |
| 14:38:23 | mriedem | jaypipes: fix this up and i'll +W the change https://review.openstack.org/#/c/475448/23/nova/api/openstack/placement/rest_api_version_history.rst | |
| 14:40:14 | sfinucan | mriedem: Per openstackstatus above, would appreciate reviews on this series to get those redirects working --> https://review.openstack.org/#/q/topic:doc-migration+project:openstack/nova | |
| 14:40:34 | sfinucan | At least, I _think_ that means we need to do those now to fix those build | |
| 14:41:57 | mriedem | yeah probably | |
| 14:43:16 | mriedem | sfinucan: sdague isn't around but you guys are going to need to sort out https://review.openstack.org/#/c/478468/ which is the bottom change in your series | |
| 14:44:11 | sfinucan | mriedem: Damn. I think I can kick that to the end. The rest should be a-OK | |
| 14:44:35 | moshele | mriedem: hi, now that https://review.openstack.org/#/c/478923/ is merge how do I update the requirement file? is it done automatically | |
| 14:45:11 | sfinucan | moshele: Looks like they're using libvirt 2.0 but they don't have the NUMA filter on. I'll ping em. Thanks for the tip :) | |
| 14:45:36 | sfinucan | AR me: Put note that NUMA affinity is supported in the SR-IOV admin guide | |
| 14:45:53 | mriedem | moshele: you have to update the global-requirements file in the openstack/requirements repo | |
| 14:46:04 | mriedem | moshele: this https://github.com/openstack/requirements/blob/master/global-requirements.txt#L161 | |
| 14:46:13 | mriedem | and the related entry in upper-constraints in that same repo | |
| 14:46:36 | mriedem | moshele: once it's merged in global-requirements it will get auto-synced to nova | |
| 14:47:37 | moshele | sfinucan: np :) | |
| 14:48:03 | moshele | mriedem: cool thanks | |
| 14:49:16 | sfinucan | Yup, Googling for openstack-docs is not a thing atm :'( | |
| 14:58:14 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: scheduler uses allocation candidates https://review.openstack.org/476631 | |
| 14:58:15 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: support GET /allocation_candidates https://review.openstack.org/475448 | |
| 14:58:15 | openstackgerrit | Jay Pipes proposed openstack/nova master: WIP - placement: claim resources in scheduler https://review.openstack.org/476632 | |
| 14:58:17 | jaypipes | mriedem: done. | |
| 15:00:13 | mriedem | thanks, +W | |
| 15:02:09 | sean-k-mooney | jaypipes: o/ since your about just wanted to run something past you regrading the traits api. what would your opipion be on extending traits to allow tag that are key value pairs with stardadised keys? e.g. standardised HW_CPU_FREQUENCY key with integer or string value field | |
| 15:02:33 | jaypipes | sean-k-mooney: I would be opposed to that. | |
| 15:02:46 | sean-k-mooney | ok good to know :) | |
| 15:03:24 | jaypipes | sean-k-mooney: what would the CPU frequency be used for w.r.t. scheduling? | |
| 15:03:29 | mriedem | jaypipes: alex_xu: that reminds me, something that came up in shenzhen last week, and i'm sure there is a reason for it, but why don't we allow traits on resource provider aggregates? | |
| 15:03:53 | mriedem | we have talked about a distance trait on an aggregate | |
| 15:03:55 | mriedem | for affinity | |
| 15:03:59 | jaypipes | mriedem: because the aggregates are simply groups of resource providers. they aren't things in and of themselves. | |
| 15:04:47 | mriedem | ok this question was coming from some guys doing baremetal, i'm not exactly sure what the use case was though, so i'd have to follow up | |
| 15:04:56 | jaypipes | mriedem: you mean Mogan? :) | |
| 15:05:10 | sean-k-mooney | jaypipes: for latence reasons i may not want to secheld to a node with a specific frequence below X but it more useful for adative power management. where i coudl declare teh maxium and minium frequence support by a specic cpu | |