| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-12-20 | |||
| 16:00:51 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Remove port allocation during detach https://review.openstack.org/622421 | |
| 16:00:52 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Refactor PortResourceRequestBasedSchedulingTestBase https://review.openstack.org/624080 | |
| 16:00:52 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Record requester in the InstancePCIRequest https://review.openstack.org/625310 | |
| 16:00:52 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Add pf_interface_name tag to passthrough_whitelist https://review.openstack.org/625311 | |
| 16:00:53 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Ensure that bandwidth and VF are from the same PF https://review.openstack.org/623543 | |
| 16:28:25 | openstackgerrit | Merged openstack/os-vif master: Change openstack-dev to openstack-discuss https://review.openstack.org/621825 | |
| 16:37:55 | cfriesen | sean-k-mooney_: you around? could you take another look at jackding's cpu model spec? | |
| 16:38:15 | sean-k-mooney_ | technically im on vacation but yes | |
| 16:38:26 | sean-k-mooney_ | i can take a look before i sign off | |
| 16:39:00 | sean-k-mooney_ | i have a pep8 issue on my own spec so i need to respin it again before i disapaer | |
| 16:42:44 | adrianc | sean-k-mooney_: Enjoy your vacation :) coming back after new year ? | |
| 16:42:48 | gibi | mriedem: I'm soon leave for the year. I don't know if you see the discussion in the ML thread about the feature flag. There are some complications. I introduced one possible solution to the patch that enables the boot with bandwidth | |
| 16:43:05 | sean-k-mooney_ | adrianc: ya the 3rd | |
| 16:43:31 | gibi | mriedem: anyhow I'm sure we will continue talking about next year. (I'm back on 7th Jan) | |
| 16:44:21 | sean-k-mooney_ | i may be online intermitently and take some time in excange after m2 if it makes sese but effectly im away for the next 2 weeks | |
| 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. | |