| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-08-23 | |||
| 12:27:36 | ykarel | mriedem, no prob, Thanks | |
| 12:27:47 | ykarel | rocky is more priority now | |
| 12:28:00 | mriedem | zigo: i'd guess the wsgi-intercept library | |
| 12:28:02 | mriedem | cdent: ^ | |
| 12:28:05 | mriedem | http://paste.openstack.org/show/728679/ | |
| 12:29:14 | mriedem | well best_matches = req.accept.acceptable_offers(types) is clearly in placement code | |
| 12:29:21 | cdent | zigo, looks webob | |
| 12:29:30 | mriedem | yeah | |
| 12:29:30 | sahid | moshele: hum... it's complicated, because if you set it to None, the LibvirtConfig will not generate the tx/rx args | |
| 12:29:42 | cdent | acceptable_offer is new in webob 1.8.x I think | |
| 12:30:02 | mriedem | sahid: but it looks like we default to vhost if rx/tx is configured https://github.com/openstack/nova/blob/34956bea4beb8e5ba474b42ba777eb88a5eadd76/nova/virt/libvirt/vif.py#L166-L176 | |
| 12:30:10 | mriedem | so driver_name will always be at least vhost? | |
| 12:30:25 | mriedem | which doesn't work for net_type == 'hostdev'? | |
| 12:30:42 | cdent | zigo: my guess is that the webob is not up to date with minimum requirements? | |
| 12:30:53 | zigo | cdent: Yeah, that should be it, thanks! | |
| 12:31:05 | mriedem | https://github.com/openstack/nova/blob/master/lower-constraints.txt#L170 fwiw | |
| 12:31:08 | mriedem | 1.8.2 | |
| 12:31:09 | zigo | Debian version is 1:1.7.3-2 | |
| 12:31:11 | cdent | zigo: I'm glad it was that easy :) | |
| 12:31:12 | zigo | Thanks guys. | |
| 12:31:14 | zigo | Will update it. | |
| 12:31:22 | sahid | yes yes, it's just i don't think we should specically set it to vfio, i think we should not set it at all for hostdev | |
| 12:31:40 | sahid | but if we do that tx/rx are then ignored | |
| 12:31:54 | jroll | mriedem: ykarel: I'm looking at this, I'm confused what is special about tripleo jobs here, as this works fine in our ironic jobs | |
| 12:32:08 | sahid | https://github.com/openstack/nova/blob/34956bea4beb8e5ba474b42ba777eb88a5eadd76/nova/virt/libvirt/config.py#L1390 | |
| 12:32:17 | jroll | oh wait, it's probably the flavors | |
| 12:32:24 | mriedem | sahid: yup | |
| 12:33:13 | mriedem | but if rx is configured, | |
| 12:33:15 | mriedem | and driver is None, | |
| 12:33:20 | mriedem | we hard-code to vhost | |
| 12:33:21 | mriedem | https://github.com/openstack/nova/blob/34956bea4beb8e5ba474b42ba777eb88a5eadd76/nova/virt/libvirt/vif.py#L169 | |
| 12:33:39 | mriedem | : libvirtError: unsupported configuration: Unknown PCI device <driver name='vhost'/> has been specified | |
| 12:33:39 | mriedem | but apparently that doesn't work | |
| 12:33:45 | mriedem | http://paste.openstack.org/show/728666/ | |
| 12:34:14 | sahid | can't we do something like that? https://github.com/openstack/nova/blob/34956bea4beb8e5ba474b42ba777eb88a5eadd76/nova/virt/libvirt/vif.py#L432 | |
| 12:34:53 | mriedem | heh, that TODO is overwriting the thing done in get_base_config which is based on another TODO | |
| 12:35:28 | mriedem | and here https://github.com/openstack/nova/blob/34956bea4beb8e5ba474b42ba777eb88a5eadd76/nova/virt/libvirt/vif.py#L519 | |
| 12:35:42 | moshele | sahid.mriedem : we can skip it for vnic_type direct in https://github.com/openstack/nova/blob/34956bea4beb8e5ba474b42ba777eb88a5eadd76/nova/virt/libvirt/vif.py#L166-L176 | |
| 12:35:48 | mriedem | sahid: which vnic_type did you test the rx queue stuff with? | |
| 12:36:04 | jroll | ykarel: posted a comment on the bug | |
| 12:36:07 | moshele | sahid, mriedem ^ | |
| 12:36:13 | ykarel | jroll, checking | |
| 12:36:27 | mriedem | moshele: but what about the other sriov types? https://github.com/openstack/nova/blob/34956bea4beb8e5ba474b42ba777eb88a5eadd76/nova/network/model.py#L111 | |
| 12:36:35 | sahid | get_config_vhostuser and _set_config_VIFHostUser are the same thing, one is native Nova the other for os-vif | |
| 12:36:45 | mriedem | i know | |
| 12:37:01 | sahid | ah sorry i did not have undersdoot the qustion so | |
| 12:37:11 | mriedem | so are direct and macvtap the only supported vnic types for rx/tx queues? | |
| 12:37:29 | moshele | mriedem: they are got beacuse the macvtap is also virtio and also the virtio forwarder | |
| 12:37:40 | moshele | mriedem: s/got/good | |
| 12:37:46 | sahid | all vnic that are using virtio | |
| 12:37:56 | sahid | can have rc/tx queues | |
| 12:38:12 | moshele | sahid: SR-IOV passthrough is not virtio | |
| 12:38:25 | moshele | sahid: meaning vnic_type direct | |
| 12:38:39 | sahid | yes, but you are talking about SRIOV+mactap right? | |
| 12:38:39 | mriedem | alright, i'm clearly in over my head here in the nfv waters. my main concern is today is rc3 and it doesn't sound like we know what the correct solution is. so i'm wondering if we should just release note a known limitation and put something in the rx/tx config option help saying it's only supported by one specifiv vnic_type for now based on the one we know that works | |
| 12:38:42 | moshele | sahid: also direct_physocal should work | |
| 12:38:56 | mriedem | i would rather release rocky stating *what we know works* | |
| 12:39:03 | mriedem | not what *should* or *might* work | |
| 12:39:12 | moshele | sahid: not it breack SR-IOV passthoght | |
| 12:39:33 | moshele | mriedem: agree we need more time on this to find a good solution | |
| 12:39:38 | sahid | yes | |
| 12:40:26 | mriedem | so what do we know works? vnic_type='macvtap'? | |
| 12:41:08 | moshele | mriedem: I will check it with Mellanox QA hope to have answer next week | |
| 12:41:56 | moshele | mriedem: as I see it we need to skip such config for vnic_type direct and physical_direct, but I will check to be sure ... | |
| 12:42:50 | ykarel | jroll, flavors created like: https://logs.rdoproject.org/openstack-periodic/git.openstack.org/openstack-infra/tripleo-ci/master/legacy-periodic-tripleo-ci-centos-7-ovb-1ctlr_1comp-featureset002-master-upload/9a25ebd/logs/undercloud/home/zuul/overcloud_prep_images.log.txt.gz#_2018-08-21_13_14_01 | |
| 12:42:57 | ykarel | jroll, is that wrong ? | |
| 12:43:27 | moshele | sahid, mriedem: I have to go I will update you guys next week | |
| 12:44:37 | jroll | ykarel: hm, that looks right. looks like maybe there's a bug in nova that doesn't override flavor.ram with flavor.properties['resources:MEMORY_MB']? this definitely used to work | |
| 12:44:49 | jroll | ykarel: I don't have time to dig into that code right now though, sorry | |
| 12:44:53 | ykarel | jroll, what can be reason for phys_ram=0:- phys_ram=0MB used_ram=0MB phys_disk=0GB used_disk=0GB total_vcpus=0 used_vcpus=0 pci_stats=[] | |
| 12:45:09 | openstackgerrit | Merged openstack/nova master: [placement] Regex consts for placement schema https://review.openstack.org/591863 | |
| 12:45:12 | ykarel | jroll, no issue, ^^ | |
| 12:45:22 | jroll | ykarel: baremetal resources no longer report ram/cpu/disk, we only rely on resource classes | |
| 12:45:44 | ykarel | jroll, in devstack ironic i saw phys_ram=384 | |
| 12:46:21 | jroll | ykarel: on master? I'd like to see that :) | |
| 12:46:51 | ykarel | jroll, yes http://logs.openstack.org/42/588942/1/check/ironic-tempest-dsvm-ipa-wholedisk-agent_ipmitool-tinyipa-multinode/4e2e0d5/logs/subnode-2/screen-n-cpu.txt.gz#_Aug_22_03_30_57_227367 | |
| 12:47:29 | mriedem | ok so moshele said rx/tx isn't support for vnic_type direct* is what i heard | |
| 12:47:30 | jroll | ykarel: that's a stable/pike patch | |
| 12:47:36 | ykarel | :( | |
| 12:47:42 | sean-k-mooney | jroll: the code works the otherway in nova. we calulate teh resources dictionary from flavor if not set not the other way around | |
| 12:47:55 | ykarel | jroll, okk, will check some master one :) | |
| 12:48:44 | jaypipes | mriedem: weird how vif plugging succeeds before the libvirt XML file is even defined...? | |
| 12:48:57 | jroll | sean-k-mooney: we explicitly agreed at some point that those resource classes in the flavor's properties would override the direct flavor properties. so I say it's a bug, if nova agrees that it isn't a bug, then ironic has docs bugs and ironic flavors have a UX problem :( | |
| 12:49:14 | jroll | sean-k-mooney: and the code did work this way in the past | |
| 12:49:32 | jaypipes | sean-k-mooney: I trust whatever jroll says and remembers. | |
| 12:50:09 | jroll | jaypipes: I'm putting that on my wall and will remember it in the future :D | |
| 12:50:14 | sean-k-mooney | im not that familar with the ironic code path so your proably right | |
| 12:50:27 | ykarel | jroll, correct in master phys_ram=0, jroll ok will try to understand placement now :) and see i can find anything there | |
| 12:50:38 | ykarel | then | |
| 12:50:44 | jaypipes | jroll: deal. :) | |
| 12:51:21 | mriedem | i also remember the flavor override thing | |
| 12:51:27 | ykarel | jroll, can this be the possible cause:- Details: There are no compute resource providers in the Placement | | |
| 12:51:28 | ykarel | | See | |
| 12:51:28 | ykarel | | Placement service and need to be upgraded and/or fixed. | | |
| 12:51:28 | ykarel | | This means no compute nodes are reporting into the | | |
| 12:51:28 | ykarel | | service but there are 2 compute nodes in the deployment. | | |
| 12:51:33 | mriedem | not sure if it was in a spec though, if not - probably in some old ptg etherpad | |
| 12:51:35 | jroll | whoops | |
| 12:52:04 | mriedem | i'm pretty sure edleafe had included the flavor overwrite stuff in the utility method for this... | |
| 12:52:28 | jroll | ykarel: the cause is a bug in the code that does overrides in the flavor, I'm sure of it :) | |