| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-03 | |||
| 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: WIP - placement: claim resources in scheduler https://review.openstack.org/476632 | |
| 14:20:24 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: support GET /allocation_candidates https://review.openstack.org/475448 | |
| 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 | sfinucan | moshele: Kind of. That's for PCI devices, but would that include VF devices? | |
| 14:33:45 | jaypipes | mriedem: I think that func test failure is fixed. | |
| 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 | moshele | |
| 14:34:00 | moshele | sfinucan | |
| 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 | 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: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 | 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: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: WIP - placement: claim resources in scheduler https://review.openstack.org/476632 | |
| 14:58:15 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: support GET /allocation_candidates https://review.openstack.org/475448 | |
| 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 | |
| 15:06:04 | jaypipes | sean-k-mooney: I think that kind of things is probably best left as a custom trait that you decorate a provider with. | |
| 15:06:20 | jaypipes | sean-k-mooney: CUSTOM_HIGH_FREQUENCY_CPUS or similar. | |
| 15:07:19 | sean-k-mooney | jaypipes: yep that is an option though i was just concerend that it might result in a lot of traits. that said they are just db row so not exeaclty the most expencive things in the world to create | |
| 15:08:21 | openstackgerrit | Ildiko Vancsa proposed openstack/nova master: WIP/POC Implement new attach Cinder flow https://review.openstack.org/330285 | |
| 15:09:23 | sean-k-mooney | there are a few other resouces capablityes that i can think of such as disk iops that would be better mapped with a key and value then just a lable but lables can still be used | |
| 15:11:07 | mriedem | jaypipes: yeah related | |
| 15:11:19 | mriedem | jaypipes: but they had some other things for nova+ironic, which is what we run in the public cloud | |
| 15:11:54 | mriedem | which leads me to other nova vm+bm questions for ops for johnthetubaguy | |
| 15:13:14 | sean-k-mooney | mriedem: are the bm guys perhapss modeling multi node chassies as a aggreagate which might be why they are interested in traits on aggreages? if so nested resouce providers sould support that usecase | |
| 15:13:22 | bauzas | jaypipes: could you please ACK'ing my comments here https://review.openstack.org/#/c/415920/15 so I could +W it ? | |
| 15:14:44 | bauzas | FWIW, hectic day | |
| 15:20:14 | openstackgerrit | Andrey Kurilin proposed openstack/python-novaclient master: DO NOT MERGE: debug failed test https://review.openstack.org/479818 | |
| 15:24:42 | openstackgerrit | Stephen Finucane proposed openstack/os-vif master: doc: Create directory structure for docs migration https://review.openstack.org/479861 | |
| 15:24:43 | openstackgerrit | Stephen Finucane proposed openstack/os-vif master: doc: Switch from oslosphinx to openstackdocstheme https://review.openstack.org/479862 | |
| 15:25:20 | sfinucan | jaypipes, sean-k-mooney, moshele: More docs fixes ^ | |
| 15:25:34 | sfinucan | (for https://specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration.html) | |
| 15:26:21 | sean-k-mooney | sfinucan: what is openstackdocstheme? | |
| 15:26:39 | sfinucan | sean-k-mooney: the theme that docs.openstack.org uses | |
| 15:27:17 | sfinucan | We're supposed to use it for any official OpenStack projects now | |
| 15:27:24 | sean-k-mooney | but is it a theme for sphinx that is maintined by the docs team for consitnecy across all offical docs? | |
| 15:27:32 | sean-k-mooney | ok cool | |
| 15:28:19 | mriedem | sean-k-mooney: i don't actually know what the use case is, | |
| 15:28:28 | mriedem | but nested RPs might be an option, it did come up too for BM | |
| 15:28:37 | mriedem | but not for multi-node chassis, | |