Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-10-20
16:09:49 superdan fried_rice: we'd need to implement it before we do anything that could change topology I guess
16:10:57 leakypipes superdan: right.
16:10:59 fried_rice superdan Agreed. If we just implement "set parent if null", then we can at least "change topology" from "flat".
16:11:21 fried_rice But we don't need to be able to change topology beyond that in the near term, IMO.
16:11:38 finucannot sean-k-mooney: You about?
16:12:21 superdan fried_rice: I dunno, what are the first few nested providers we expect? numa nodes, and SRIOV nics /VGPUs right?
16:12:41 fried_rice superdan reckon so, yeah.
16:12:54 superdan let's say we expose a VGPU for something like vmware or xen,
16:12:54 fried_rice superdan Early in R, network bw stuff mebbe.
16:13:06 superdan but we don't have numa information until a week later
16:13:14 superdan then we have to reparent the vgpu provider under the numa node
16:13:16 sean-k-mooney finucannot: yes
16:13:38 fried_rice superdan Oh, are we actually concerned about being able to rework existing deployments on the master branch?
16:13:53 superdan fried_rice: always
16:14:07 finucannot sean-k-mooney: Quick one - I've got two identical PCI devices and I want to disable one of them at least from a nova perspective. Any ideas on how that could be accomplished?
16:14:15 finucannot Only got access to the host OS - not the BIOS
16:14:37 fried_rice finucannot [pci]passthrough_whitelist by PCI address
16:15:02 finucannot fried_rice: Oh, can you do PCI address too?
16:15:03 cfriesen echo 0 > /sys/bus/pci/slot/$N/power
16:15:09 fried_rice finucannot yup
16:15:34 finucannot cfriesen: That's what I tried but alas, no power file
16:15:36 fried_rice finucannot e.g. https://docs.openstack.org/nova/pike/admin/pci-passthrough.html#configure-pci-devices-compute
16:15:59 sean-k-mooney finucannot: pci adress was the first thing the whiteliset support i think
16:16:30 fried_rice finucannot You can also put * in for any of those.
16:16:52 finucannot fried_rice: Serious case of RTFM there. Thanks for the link :)
16:17:01 fried_rice finucannot yahyoubetcha
16:17:47 sean-k-mooney finucannot: you needed to "disable" it so that openstack would not use it right and not for some other reason
16:18:57 finucannot sean-k-mooney: I want disable the PCI devices on node 0 to make sure non-PCI-needing devices use node 1 CPUs
16:19:20 sean-k-mooney finucannot: ah ok
16:19:27 sean-k-mooney you can do that another way
16:19:33 finucannot Validating that PCI weigher spec from last cycle again, but this time without a server beside me that I can unplug the NIC from :)
16:19:47 finucannot sean-k-mooney: Do tell
16:20:23 sean-k-mooney the numa node value in sysfs is writeable so you can lable the device as part of the other numa node or set it to -1 which means no numa affinity
16:21:32 finucannot Hahaha
16:21:47 leakypipes superdan: first nested resources are PFs which are children of the compute nodes.
16:21:49 finucannot That's even better though, because it can be scripted
16:21:56 finucannot from the perspective of automating this in the future
16:22:21 superdan leakypipes: right, and then we'll want them under numa nodes ASAP, so -> reparent
16:22:34 sean-k-mooney finucannot: true but you should check if the change get reflected into virsh nodedev list
16:23:35 sean-k-mooney fried_rice: intra master is the same as stable brance minor upgrades
16:24:17 fried_rice Which I *guess* is why we need microversions within a release.
16:24:21 finucannot fried_rice, cfriesen, sean-k-mooney: One more q: I noticed that adding 'physical_network' to the 'passthrough_whitelist' option and specifying '"device_type": "type-PCI"' for 'alias' resulted in 'type-PF'
16:24:22 superdan fried_rice: we have always done this.. like mriedem said earlier, each commit is a release
16:24:41 fried_rice superdan Good to know. I truly didn't realize that.
16:24:44 finucannot I haven't tried it again and know I shouldn't have set 'physical_network', but does that ring a bell?
16:25:19 mriedem i say lots of things
16:25:21 finucannot Want to make sure it's not a "feature" before I go tracking down a possible bug
16:25:24 sean-k-mooney finucannot: if you dont have vfs allocated that is expected
16:25:33 fried_rice finucannot Oh, please do not fix "bugs" in the PCI manager.
16:25:54 mriedem rm -rf nova/pci && echo "fixed"
16:25:55 mriedem ?
16:26:08 fried_rice Yeah, except for that fix.
16:26:13 superdan mriedem: ++
16:26:35 sean-k-mooney finucannot: stephen if the pf does not have VF that is the correct value because we supprot neutron vnic type direct_physical
16:27:16 finucannot curl --data "salary=0" https://api.salary.redhat.com/sfinucan
16:27:20 sean-k-mooney finucannot: that means pretend we are doing sriov but really do a full pci passthrough and update neutron port the the phisical mac
16:27:50 superdan finucannot: I get an overflow error every time I try to use that api
16:27:54 cdent have a good weekend all
16:27:55 finucannot sean-k-mooney: Even though I explicitly set 'device_type' in the alias?
16:27:56 superdan something about not fitting into a 32-bit int
16:28:23 sean-k-mooney finucannot: you set the device type to type-PCI a pf is a pci device
16:29:45 sean-k-mooney but looking at the docs again i think you ment "device_type":"type-PF" or "device_type":"type-VF" not type-PCI
16:29:47 finucannot sean-k-mooney: Right, but 'type-PCI' != 'type-PF', so attempting to use the alias in a flavor's extra specs results in a failure to boot
16:29:50 leakypipes superdan: right. I'm not saying reparenting isn't important. just that for this first patch, I would like to disable it.
16:30:05 leakypipes superdan: with a TODO of course
16:31:21 finucannot Ah, wait - maybe I'm getting things mixed up here
16:31:47 sean-k-mooney finucannot: right when you added the physnet it made it useable for neutron sriov passthough and diabled nova pci passthough
16:32:04 finucannot sean-k-mooney: and marks it as 'type-PF'?
16:32:34 finucannot So the alias is simply that, an alias, so my alias is simply wrong?
16:33:05 sean-k-mooney yep if you change it to type-PF it will work
16:33:13 finucannot (y)
16:33:45 finucannot We should probably note how we decide what device_type to mark a device as somewhere
16:34:09 finucannot I thought it was done via the alias but I see the error of my ways now
16:35:04 sean-k-mooney yes it was foolish to try to understand how our pci passthrough code works :)
16:37:39 leakypipes superdan: would you be cool with that?
16:41:56 openstackgerrit Merged openstack/nova master: Cleanup mount / umount and associated rmdir calls https://review.openstack.org/494423
16:44:26 openstackgerrit Merged openstack/nova master: Move lvm handling to privsep. https://review.openstack.org/495516
16:56:59 openstackgerrit Ildiko Vancsa proposed openstack/nova master: Implement new attach Cinder flow https://review.openstack.org/330285
17:06:30 openstackgerrit Elod Illes proposed openstack/nova master: Transform instance.trigger_crash_dump notification https://review.openstack.org/396225
17:13:48 superdan leakypipes: no real choice so yeah sure :)
17:57:34 openstackgerrit Andreas Jaeger proposed openstack/nova master: DNM: Test api-refs https://review.openstack.org/513819
17:57:43 cfriesen when running ironic, does it require configuring nova-scheduler differently than normal? The existance of nova/scheduler/ironic_host_manager.py, makes me wonder.
18:09:49 MikeW Hey which components of the nova services emit these notifications to rabbitmq: compute.instance.create.end and compute.instance.delete.start?
18:10:20 MikeW Wondering on what I need to touch to integrate designate-sink in my system and hoping I can void compute hosts, and just modify like nova-scheduler or nova-api
18:43:26 MikeW Anyone here have experience with nova/designate integration over the message queue?
18:49:01 mriedem mlavalle: remind me, can you live migrate from an ovs vif type to a linuxbridge vif type, or vice versa, today? or does that require a reboot once the instance is on the dest host?
18:49:30 mriedem i thought no because the source host doesn't know the dest host vif type to use to configure the guest before the live migration starts - which is part of what sean's spec is trying to fix
18:49:45 mlavalle that's my understanding as well
18:50:07 mriedem cool - just working on project update slides
18:50:15 mlavalle :-)
18:50:19 mriedem want to make sure i correctly promise the world
18:50:28 mlavalle LOL
18:58:55 superdan mriedem: correct
19:13:52 openstackgerrit Ildiko Vancsa proposed openstack/nova master: Implement new attach Cinder flow https://review.openstack.org/330285
19:31:19 openstackgerrit Eric Fried proposed openstack/nova master: Refactor test_resource_provider https://review.openstack.org/513834
19:38:13 mriedem superdan: this doesn't seem kosher https://review.openstack.org/#/c/509107/2/os_vif/objects/subnet.py
19:38:36 superdan mriedem: that's because it's not
20:15:58 openstackgerrit Eric Fried proposed openstack/nova master: Include /resource_providers/uuid/allocations link https://review.openstack.org/499826
20:21:16 openstackgerrit Merged openstack/nova master: console: introduce basic framework for security proxying https://review.openstack.org/345396
20:27:43 mriedem anthonyper: https://review.openstack.org/#/c/465160/ - talks about only allowing numa in the libvirt driver if using kvm

Earlier   Later