Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-12-20
16:48:55 mriedem gibi: i haven't gone through the ML thread yet, but i will,
16:49:13 mriedem gibi: in general i'm not supportive of feature flags in the API (smells like config-driven API behavior)
16:49:26 mriedem unless it's policy or something
16:49:38 mriedem gibi: coincidentally, i will be on vacation the week of jan 7 :)
16:50:53 gibi mriedem: if you leave me reasonable suggestion I can try to implement that on the week of Jan you are off
16:51:30 mriedem i'll make it your xmas gift
16:51:35 gibi mriedem: thanks
16:51:37 gibi :)
17:03:41 mriedem jmlowe: i duped one of those bugs against the other so it's just https://bugs.launchpad.net/nova/+bug/1642537 now
17:03:41 openstack Launchpad bug 1642537 in OpenStack Compute (nova) "finish_resize fails with DBDeadlock on migrations table" [Undecided,Confirmed]
17:03:43 mriedem which is migrate_update
17:13:05 openstackgerrit Jack Ding proposed openstack/nova-specs master: Select cpu model from a list of cpu models https://review.openstack.org/620959
17:28:51 mriedem yonglihe: cfriesen: comments in the show server numa topo spec https://review.openstack.org/#/c/612256/
17:29:52 mriedem seems i've asked some of the same questions bauzas did, i.e. wanting details about how the information is going to be retrieved, which will definitely impact performance
17:30:37 cfriesen mriedem: thanks for taking a look.
17:32:16 sean-k-mooney_ cfriesen: https://review.openstack.org/#/c/620959 looks fine to me. its a short spec but a small feature so i think its fine
17:35:49 sean-k-mooney_ so nowone has changed the laws of number lately 78 is still less the 79...
17:36:29 sean-k-mooney_ my spec failed pep8 in the gate on a line lenght issue where the line is actully 78 colums wide and it passes localy.
17:40:33 sean-k-mooney_ ok never mind i was looking at the previous patchset locally
17:41:57 openstackgerrit sean mooney proposed openstack/nova-specs master: Add spec for sriov live migration https://review.openstack.org/605116
17:43:23 sean-k-mooney_ cfriesen: by the way i dont know if you have seen https://review.openstack.org/#/c/605116 but hopefully it is to your likeing also.
17:43:40 openstackgerrit Merged openstack/nova master: Remove legacy RequestSpec compat from conductor unshelve_instance https://review.openstack.org/625706
17:43:48 openstackgerrit Merged openstack/nova master: Remove legacy RequestSpec compat from conductor rebuild_instance https://review.openstack.org/625707
17:45:58 cfriesen sean-k-mooney: oooh, fun. will take a look. hadn't seen it yet
17:48:20 sean-k-mooney cfriesen: adrianc has working poc code up for macvtap. i will hopfully get the vnic_type=direct|direct-physical code up in early january
17:49:50 cfriesen for direct/direct-physical how does that even work in the guest kernel? does it see a device detach/attach?
17:50:15 sean-k-mooney yep exactly as it does for suspend
17:50:51 sean-k-mooney if you want to prevent loss of netwroking you have to create a bond in the guest with a livemigratable port
17:51:11 sean-k-mooney that can either be a macvtap sriov port or a vswitch port
17:51:37 cfriesen I guess you'd need to have a hook in the end-user app to detect the port changes and check the tags on the newly-attached device
17:51:50 cfriesen to figure out which ports should be used for what
17:52:29 sean-k-mooney ya i have left that as an exercise for the end user. i dont want to add it to the spec as there are a few ways to do it
17:52:47 cfriesen sean-k-mooney: arguably you'll lose networking anways in some cases since vswitch/macvtap won't be able to handle the same throughput
17:52:54 cfriesen right, not needed in spec
17:53:16 sean-k-mooney ya that is ture it woudl be degraded
17:53:35 sean-k-mooney the intent is to keep bgp peering session ectra alive
17:53:46 sean-k-mooney rather then nessisarlly maintain kpis
17:53:59 cfriesen I guess you'd need some sort of prioritization to drop the less important stuff while letting the important stuff through
17:54:23 sean-k-mooney you could do that with dscp perhaps but yes.
17:55:05 sean-k-mooney you are always better to drain instance before moving them when they are vnf but its less impactful then cold migration
17:55:49 cfriesen I assume this would depend on the stuff artom is doing for resource tracking over live migration?
17:55:55 sean-k-mooney there are some technologes under developement that will replace sriov in the future which do supprot livemigration natively
17:56:04 sean-k-mooney cfriesen: not really
17:56:09 sean-k-mooney its related
17:56:15 sean-k-mooney but there is not direct dependcy
17:56:34 sean-k-mooney cfriesen: artom is looking jsut at the numa aspect
17:56:34 cfriesen both of them are adding resource claims in the "check can live migrate" code, and both are modifying XML on the source
17:56:53 sean-k-mooney yes they are
17:57:14 sean-k-mooney well actull we dont ned to mofiy the xml for the sriov case
17:57:24 sean-k-mooney in macvtap the code already exits to handel it
17:57:40 sean-k-mooney for direct mode we do a detach and attach before/after the migration
17:57:46 sean-k-mooney so the code is there for that also
17:58:04 cfriesen the spec says "second, nova does not modify
17:58:04 cfriesen the guest XML to reflect the host PCI address on the destination"
17:58:41 sean-k-mooney correct
17:59:03 sean-k-mooney but the ording is imporant
17:59:06 cfriesen okay, I guess you could view the attach after the migration as modifying the xml. :)
17:59:22 sean-k-mooney yes it is in a way
18:00:02 sean-k-mooney its is not modifing it in a sense that the fuction that normally modify the xml on migration will not be modifying the xml to do the detach/attach
18:00:25 sean-k-mooney its basically detach, migrate then attach
18:00:44 sean-k-mooney the actul migration happens with out the sriov interfaces
18:01:29 sean-k-mooney well in directmode in macvtap we dont doe the detach/atach and the code that already is there fixes the xml if the netdev name changes
18:01:32 cfriesen what is "indirect mode SR-IOV"?
18:01:45 sean-k-mooney vnic_type=macvtap
18:02:03 sean-k-mooney or vnic_type=virtio-forwarder
18:02:46 sean-k-mooney the guest sees a virtio-net-pci device in both cases atach to the vf on the host via a macvtap or vhost-user interface
18:05:46 openstackgerrit Andrey Volkov proposed openstack/nova stable/queens: Exclude build request marker from server listing https://review.openstack.org/626585
18:08:34 openstackgerrit Andrey Volkov proposed openstack/nova stable/rocky: Exclude build request marker from server listing https://review.openstack.org/626584
19:28:15 openstackgerrit melanie witt proposed openstack/nova master: Add configuration of maximum disk devices to attach https://review.openstack.org/616777
20:40:46 mriedem melwitt: Kevin_Zheng: thanks for reviewing the cross-cell resize spec, replies inline https://review.openstack.org/#/c/616037/
20:41:20 mriedem my plan is to further split the large patch into compute / conductor / api parts, and then i'll start thinking about how to write new stuff for the compute layer since the conductor/api stuff might remain mostly unchanged
20:41:45 mriedem melwitt: are you running the nova meeting today or am i?
21:22:28 mriedem jackding: should really have kashyap look at this https://review.openstack.org/#/c/620959/
21:22:43 mriedem but he's probably on PTO
21:40:47 mriedem jackding: cfriesen: question inline about the performance impact of the cpu_models spec https://review.openstack.org/#/c/620959/
22:20:50 cfriesen mriedem: responded in the review. thanks for the +W
22:22:48 openstackgerrit Merged openstack/nova-specs master: Select cpu model from a list of cpu models https://review.openstack.org/620959
22:48:27 mriedem jaypipes: i've got a head scratcher in a functional test i wrote https://review.openstack.org/#/c/619123/ - i have a single host which is reporting 2 VCPU to inventory. i create a server on it with 1 VCPU and then resize to a flavor with 2 VCPU to trigger no valid host due to insufficient capacity,
22:48:51 mriedem however, i'm sort of wondering why the cpu_allocation_ratio (16.0) isn't being taken into account, to really say the VCPU inventory is 32
22:49:06 jaypipes mriedem: hmm.
22:49:07 mriedem i don't see anything setting global allocation ratios in our fake virt driver or test fixtures
22:49:19 mriedem the test fails as i wanted, but now i'm sort of wondering why
22:49:22 jaypipes mriedem: what gets written to compute_nodes table?
22:49:35 mriedem i'll add some debug
22:49:40 jaypipes compute_nodes.cpu_allocation_ratio that is.
22:50:02 mriedem debug shows this as well
22:50:03 mriedem Updating ProviderTree inventory for provider c79d1a42-b934-43c3-9e5d-fed394e98d46 from _refresh_and_get_inventory using data: {'VCPU': {'max_unit': 2, 'min_unit': 1, 'step_size': 1, 'reserved': 0, 'total': 2, 'allocation_ratio': 16.0}, 'DISK_GB': {'max_unit': 1028, 'min_unit': 1, 'step_size': 1, 'reserved': 0, 'total': 1028, 'allocation_ratio': 1.0}, 'MEMORY_MB': {'max_unit': 8192, 'min_unit': 1, 'step_size': 1, 'reserved': 5
22:50:03 mriedem 'total': 8192, 'allocation_ratio': 1.5}}"
22:53:37 jaypipes mriedem: max_unit is 2.
22:53:41 jaypipes mriedem: that's the reason.
22:54:04 mriedem ah, yeah
22:54:18 mriedem fake virt driver implements upt and it reports max_unit = total
22:54:56 mriedem hmm, but i'm requesting 2 when it fails
22:55:21 mriedem and the resource provider inventory capacity in placement is: int((self.total - self.reserved) * self.allocation_ratio)
22:57:44 mriedem http://paste.openstack.org/show/737810/ is the placement GET /a_c debug logs
22:57:54 mriedem ha it's disk that is the problem
22:57:55 mriedem found 0 providers with available 1028 DISK_GB'
22:58:03 mriedem b/c disk_allocation_ratio=1
22:58:10 mriedem saved by the disk!
22:58:47 jaypipes tada

Earlier   Later