Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-03-01
16:26:54 giblet sean-k-mooney: if the bandwidth is represented in placement then nova, by selectin an a_c, actually forces a PF
16:27:23 sean-k-mooney yes it will...
16:28:26 sean-k-mooney sice we have a bug in our pci affinity policies it wont break existing workloads
16:28:47 giblet so when the allocation is done in placement nova needs to drive the pci claim mechanism to select VF from the same PF as the bandwidth is allocated from
16:29:30 sean-k-mooney yes i know i raised that point a few tiems when i argured we could not remove the reosuce tracker
16:29:51 giblet one way to drive it is to know which RP was used for the bandwidth, get the name of it, and from the name learn the pf device name
16:30:20 sean-k-mooney giblet: so the request in the neutron port does not contain a devename right
16:30:29 giblet sean-k-mooney: right.
16:30:49 sean-k-mooney ok so its placemetn that choses the bandwtih resouce provider and we are just corralting it
16:31:17 giblet sean-k-mooney: yes
16:31:56 giblet sean-k-mooney: we have to make sure the pci claim chooses the same PF as placement
16:32:02 sean-k-mooney i would still prefer if we looked up the pf name automatically in the driver and populated the tag rather then making it a manual step in the whitelist
16:32:05 stephenfin sean-k-mooney: Out of curiosity, doesn't systemd solve the "attach to guest, detach, and still have the same name" issue? https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
16:32:31 stephenfin sean-k-mooney, giblet: I must say, so would I
16:32:52 sean-k-mooney no not in all cases
16:33:02 giblet sean-k-mooney: for that nova needs to select the same device name as the neutron admin selected in the neutron config
16:33:13 stephenfin Given that it's information that's very easy to extract, and the only reason I see not to do that is because of a weird bug in an effectively EOL card
16:33:22 sean-k-mooney if the pf is not rebound to the nic driver after its bound to vfio-pci it will not have a netdev anymore
16:34:18 sean-k-mooney giblet: yes that is not that hard to do
16:34:50 giblet sean-k-mooney, stephenfin: is it doable in 4 effective day before FF?
16:35:04 sean-k-mooney we have similar code to do that in os-vif already https://github.com/openstack/os-vif/blob/master/vif_plug_ovs/linux_net.py#L313-L334
16:36:42 cfriesen could I get some eyes on https://review.openstack.org/#/c/620706/ ? It's on a runway.
16:36:59 sean-k-mooney giblet: we need to look up netdev names form pci address to make hardware offload ovs work
16:38:22 sean-k-mooney giblet: you jsut do open( "/sys/bus/pci/devices/%s/physfn/net" % (pci_addr)).readline().strip()
16:39:10 giblet sean-k-mooney: is it fine to do that during the startup of the nova-compute service while parsing the passthrough_whitelist?
16:39:51 sean-k-mooney i dont know. we do it every time we plug a hardwar offloaed ovs-port and we plug all ports on startup
16:40:58 sean-k-mooney granted its os-vif that executing it but os-vif is run as part of the nova comptue agent so it shoudl be fine
16:41:47 stephenfin giblet: I'm guessing we could just slot it in here https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L5926-L5940
16:44:00 giblet stephenfin, sean-k-mooney: thanks for the pointers I have to sit down with a clear mind and play with that codepath to see how can I inject the extra info there in a way that it will be used by the pci claim
16:44:33 sean-k-mooney giblet we also have a call to lookup device by name just after that
16:44:34 sean-k-mooney https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L5958
16:44:41 sean-k-mooney so doing the invers should be fine
16:44:42 openstackgerrit Ben Nemec proposed openstack/nova master: Add oslo.privsep to config-generator list https://review.openstack.org/640404
16:45:51 sean-k-mooney giblet: im not really objecting to useing a tag by the way
16:46:04 sean-k-mooney giblet: i think we can just automate it
16:46:37 stephenfin giblet: Sounds good. If you can't make progress fairly quickly, I'd be willing to hold my nose so we could get it in. Would be good to try avoid it though, given the few issues there are already
16:46:41 giblet sean-k-mooney: I think I understand. I agree in general to automate it if possible.
16:47:08 giblet sean-k-mooney: I'm more affraid that I will not be able to make it work
16:47:45 giblet stephenfin: alternatively I can remove this patch from the series, declare the two PF on the same compute on the same physnet as not-supported in Stein
16:47:49 stephenfin e.g. confusion with 'devname', issues if you whitelist more than PF and need for extra (possibly unnecessary) configuration, the first two of which probably need additional code to fix
16:48:33 stephenfin giblet: Aye, I was wondering if it was possible to shove this to the end and de-risk it. If that's an option, it might be a good one
16:48:43 sean-k-mooney giblet: i think that is what we did for vgpus
16:49:18 sean-k-mooney its not ideal but it would work. i would be good to ask leakypipes or dansmith
16:49:32 sean-k-mooney they tend to have stong opipions on this topic
16:50:07 giblet stephenfin: yeah, I think the sortness of time will push me to remove this patch from the critical path
16:50:10 sean-k-mooney actully maybe you shouldnt ask them :)
16:51:45 sean-k-mooney giblet: i can try and hack something up at the weekend to do auto tagging and then you can decide on monday
16:52:46 giblet sean-k-mooney: if you hack someting up then I will definitly look at it on Monday but please don't spend your free time on this crazy things :)
16:54:03 sean-k-mooney i spent my free time last weekend trying to autoamte a tox nutika enviorment ot automaticlaly compile nova and then execute the unit test.
16:54:11 sean-k-mooney this might be a less crazy
16:54:20 giblet sean-k-mooney: :)
16:54:34 sean-k-mooney i got it to work for os-vif but nova make it explode
16:55:44 leakypipes sean-k-mooney, stephenfin: ask me what?
16:56:45 stephenfin leakypipes: We're not overly happy about this patch and think pf_interface_name could be figured out dynamically by the driver https://review.openstack.org/#/c/625311/29
16:57:21 sean-k-mooney noting you will like. unless your opipion on adding tags to the pci whitelist has changed recently
16:57:31 stephenfin leakypipes: giblet is concerned about time constraints though and think maybe declaring that two PF on the same compute on the same physnet as not-supported in Stein would be a safer option
16:58:05 stephenfin *maybe declaring two PFs
16:58:30 leakypipes stephenfin: ok, that patch is near the top of my queue. will try to comment on it this afternoon.
16:59:11 giblet I'm not too affraid of saying that this edge case is not supported in Stein
16:59:12 sean-k-mooney we are already doing auto discovery of nic offloads exctra on startup and we have code to discover the name of pf form vfs in os-vif so i was suggesing just looking up the pf name on startup as part of the pci device discovery
17:01:42 giblet however I will only be able to declare this case unsupported in the documentation as I don't see an easy way to detect the case from code and reject or just fail the boot request
17:02:26 giblet so if the admin ignores the doc then she can create a situation when the bandwidth is allocated from a PF while the VF is allocated from other PF for the same port
17:04:13 stephenfin giblet: Is there a file missing from https://review.openstack.org/#/c/623543/ ?
17:04:48 stephenfin I'm trying to figure out where "Then the pci claim will enforce that the PF interface name in the request matches the interface name of the PF from where the VF is selected from." happens
17:04:56 stephenfin (from the commit message, line 53)
17:05:21 giblet stephenfin: I think the pci claim matches the request with the device spec field by field
17:05:25 stephenfin Oh, wait, tags
17:05:36 stephenfin yup. duh
17:05:36 giblet so if the pf_interface_name is in the request as well as in the device spec then it will be matched
17:05:40 stephenfin It's clearly Friday :)
17:05:45 giblet soo Friday
17:06:41 sean-k-mooney https://www.youtube.com/watch?v=kfVsfOSbJY0
17:07:03 sean-k-mooney its stuck in my head so i give it to you too
17:11:23 giblet it is heavy stuff :)
17:20:52 openstackgerrit Jim Rollenhagen proposed openstack/nova master: ironic: check fresh data when sync_power_state doesn't line up https://review.openstack.org/636699
17:20:53 openstackgerrit Jim Rollenhagen proposed openstack/nova master: Remove TypeError handling for get_info https://review.openstack.org/640043
17:25:47 openstackgerrit Matt Riedemann proposed openstack/nova master: Check hosts have no instances for AZ rename https://review.openstack.org/509206
17:28:11 mriedem bauzas: i'm good with ^ again
17:28:21 mriedem we should all thank avolkov for his persistence
17:41:09 openstackgerrit Matt Riedemann proposed openstack/nova master: api-ref: explain aggregate set_metadata semantics https://review.openstack.org/640460
17:44:42 mriedem stephenfin: cfriesen: can one of you backport https://review.openstack.org/#/c/635350/ to stable/rocky?
17:44:58 cfriesen mriedem: can do
17:45:01 openstackgerrit Stephen Finucane proposed openstack/nova stable/rocky: fix up numa-topology live migration hypervisor check https://review.openstack.org/640462
17:45:05 cfriesen okay
17:45:09 cfriesen :)
17:45:19 stephenfin no merge conflicts :)
17:46:35 temka stephenfin, hey, sean-k-mooney's saying on the mailing list that you somehow managed to get different configs to different services in func tests. Any recollection of that?
17:46:56 stephenfin ummm...
17:47:00 temka (No link to ML post because the web UI is apparently lagging behind)
17:47:25 temka stephenfin, I'm normally artom, btw, in case you're wondering
17:49:03 stephenfin temka: I'm _guessing_ he's referring to 45662d77a2da77714f8e792e86ebd64a52270ef5
17:50:44 stephenfin temka: I don't think it's possible to have different nova.conf configurations in functional tests though
17:51:24 temka (Okay, turns out this friday nick idea wasn't necessarily the best, because 'temka' is normally what my mom calls me)
17:51:27 stephenfin that config is global so as soon as you'd change it, every service would see the change
17:51:42 temka stephenfin, that's what I thought
17:54:33 aspiers melwitt, mriedem: if we are retargeting SEV for Train, what is the correct approach to updating the spec/bp?
17:55:06 mriedem https://specs.openstack.org/openstack/nova-specs/readme.html#previously-approved-specifications
17:55:24 aspiers hah, sorry - still asking newbie FAQs :)
17:55:51 aspiers breton: ^^^
18:20:09 openstackgerrit Adam Spiers proposed openstack/nova master: fix bug with XML matcher handling missing children https://review.openstack.org/640411

Earlier   Later