| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-03-01 | |||
| 13:04:41 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Ensure that bandwidth and VF are from the same PF https://review.openstack.org/623543 | |
| 13:11:18 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Support server create with ports having resource request https://review.openstack.org/636360 | |
| 13:13:35 | giblet | jaypipes: Hi! I've replied in https://review.openstack.org/#/c/625310/31/nova/objects/instance_pci_requests.py@39 If you still think we should rename then let me know and I will jump on it | |
| 13:15:01 | jroll | efried: alex_xu: this was rebased, want to re-approve? https://review.openstack.org/#/c/636326/ | |
| 13:30:04 | bauzas | efried: alex_xu: jaypipes: others, I finally removed my -W because I'm not sure I can provide the fix for the problem I saw by this week | |
| 13:30:14 | bauzas | instead, I'll provide a documentation | |
| 13:35:45 | efried | jroll: done | |
| 13:36:01 | efried | bauzas: ack. My +2 is still on there... for now :P | |
| 13:36:02 | jroll | thanks | |
| 13:36:26 | bauzas | efried: heh thanks | |
| 13:36:31 | efried | jroll: you knew there was no way you were going to merge a patch at PS1. | |
| 13:37:02 | jroll | efried: so close though | |
| 13:46:20 | yonglihe | hope this would in reviewing queue -:) https://review.openstack.org/#/c/621476/ | |
| 13:46:21 | openstackgerrit | Merged openstack/nova master: fix up numa-topology live migration hypervisor check https://review.openstack.org/635350 | |
| 13:47:06 | mriedem | yonglihe: are you working on adding the related novaclient change for 2.70? | |
| 13:47:11 | mriedem | *2.71 i mean | |
| 13:50:49 | yonglihe | yeah, on my queue. | |
| 13:51:28 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/rocky: Move legacy-grenade-dsvm-neutron-multinode-live-migration in-tree https://review.openstack.org/640191 | |
| 13:51:39 | yonglihe | by default , it could show up. i need to dig how to good fit to nova client, might be some documentation work i guss. | |
| 13:51:41 | yonglihe | guess | |
| 13:52:22 | mriedem | it should just work, but you have to at least bump the supported api version and it would be good to modify the fakes response in unit tests to show it in the output for nova show/update/rebuild | |
| 13:52:45 | mriedem | so this https://github.com/openstack/python-novaclient/blob/master/novaclient/__init__.py#L28 | |
| 13:52:54 | yonglihe | sure, got it. | |
| 13:53:12 | mriedem | the fake responses for unit tests are here https://github.com/openstack/python-novaclient/blob/master/novaclient/tests/unit/v2/fakes.py | |
| 13:53:26 | yonglihe | nice, thanks. | |
| 13:53:52 | mriedem | so something like this https://github.com/openstack/python-novaclient/blob/master/novaclient/tests/unit/v2/fakes.py#L647 | |
| 13:53:55 | tssurya | mriedem, melwitt, dansmith: I have this very easy doc change on the archive nova-manage command just to clarify what max-rows means there: https://review.openstack.org/#/c/606995/. Please take a look at it when you have time, | |
| 13:54:10 | mriedem | yonglihe: you can check the requested microversion from the fake method and return the server_groups key in the response | |
| 13:54:48 | mriedem | like this https://github.com/openstack/python-novaclient/blob/master/novaclient/tests/unit/v2/fakes.py#L2023 | |
| 13:56:11 | yonglihe | mriedem: ok, thanks. | |
| 13:57:58 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Update --max-rows parameter description for archive_deleted_rows https://review.openstack.org/606995 | |
| 13:58:04 | mriedem | tssurya: done | |
| 14:14:27 | fried_rice | Hey folks, especially folks like sean-k-mooney: when we do a resize-to-same-host, do neutron ports get unbound and rebound or do we leave them alone? | |
| 14:15:10 | fried_rice | Sundar: ^ | |
| 14:16:54 | ttsiouts | mriedem: I tried to address your comments in https://review.openstack.org/#/c/570203/. would be great to hear your feedback when you have the time. thanks in advance | |
| 14:17:26 | sean-k-mooney | fried_rice: i would have to check they proable are not but it might be resonable to require that they are | |
| 14:17:55 | sean-k-mooney | i dont htink we allow changing vif_model via flavor im pretty sure that is image only | |
| 14:19:16 | fried_rice | sean-k-mooney: I'm thinking it could be problematic for bandwidth resources, if there are paths in which we would end up binding to different providers somehow - the allocations would wind up screwy. giblet, have you already considered this? | |
| 14:19:30 | sean-k-mooney | am if the numa toplogy changes as part of a resize then in the future the bandwith allcoation might need to be updated | |
| 14:19:39 | fried_rice | sean-k-mooney: And in anticipation of cyborg, similarly, if we had to unbind and rebind accelerators. | |
| 14:20:22 | sean-k-mooney | fried_rice: well we hit the schudler as part of a resize so if the flavor chagned the device-profile for example in the cyborge case we defiently would need to rebind the device | |
| 14:20:27 | giblet | fried_rice: do you mean changing the flavor might affect the port allocation? | |
| 14:21:08 | fried_rice | giblet: actually I'm more concerned about the case where changing the flavor does/should *not* affect the port allocation/binding. | |
| 14:21:08 | sean-k-mooney | it may | |
| 14:21:40 | fried_rice | like, if all I do is increase VCPU, is it possible that I wind up with my vifs being swizzled? | |
| 14:21:44 | Sundar | sean-k-mooney: What about rebuild? It could be on same host or different host. In the former case, AFAIK, it is only a detach but not an unbind. | |
| 14:22:02 | sean-k-mooney | Sundar: rebuild is confied to the same host | |
| 14:22:07 | sean-k-mooney | Sundar: it will never do a migrate | |
| 14:23:06 | Sundar | sean-k-mooney: If the rebuild changes the image, and the new image has different traits, is that not a problem? | |
| 14:23:14 | sean-k-mooney | fried_rice: i think there are edgecses such as changin numa toplogy that might require it if you have sriov port or hardwar offload ovs or you use the numa aware vswitch feature | |
| 14:23:33 | sean-k-mooney | Sundar: we will fail the rebuild if its not valid for the current host | |
| 14:23:40 | mriedem | rebuild doesn't mess with port bindings | |
| 14:23:43 | sean-k-mooney | rebuilt with same image bypasses the scheduler | |
| 14:23:50 | sean-k-mooney | rebuilt with different hits the schduler | |
| 14:23:59 | giblet | does resize-to-same host is just allows but never forces the resize to keep the server on the same host | |
| 14:24:05 | mriedem | resize to same host calls the same methods to change port bindings, but i think the neutron api code we have doesn't do the update if the host doesn't change | |
| 14:24:26 | mriedem | https://github.com/openstack/nova/blob/master/nova/network/neutronv2/api.py#L3230 | |
| 14:25:17 | sean-k-mooney | giblet: right if the resize was invalid on the same host it would do a cold migraton to a vliad host if one exits in that case | |
| 14:27:03 | sean-k-mooney | mriedem: in princiable a rebind with a new image could contain tratis that may affect the neutro ports but in practice we have never need to cater for that case todate so ya for rebuild we have never needed to touch the port bindings | |
| 14:27:28 | giblet | fried_rice: to answer your original question server move operations (even resize on same host) are not covered by the current implementation so your question needs to be answered during Train | |
| 14:27:51 | fried_rice | giblet: Okay, good to know. | |
| 14:28:37 | giblet | fried_rice: my general idea regarding move is, to re-query resoruce request from neutron ports, include it to the scheduling. conductor will transparently handle migration allocation for ports then. | |
| 14:28:59 | fried_rice | giblet: It would be nice to prefer candidates where the ports don't move. | |
| 14:29:12 | fried_rice | which sounds like more hacked up matching. | |
| 14:29:44 | giblet | fried_rice: so during resize-to-same-host case it would be nice to keep the ports allocated to from the same RP, I seenow | |
| 14:29:50 | sean-k-mooney | fried_rice: for what it worth the image trait edgecase for neutron port i am tink of would be a a required or forbding trati for a partacalr nic vendor when using sriov. we talked about this as a way for image to expres i have drivers for vendor X but not Y | |
| 14:30:56 | giblet | fried_rice: the problem with that is nova-scheduler always selects the first allocation for a host even if there is more than one candidate is returned for that host | |
| 14:30:59 | giblet | by placement | |
| 14:31:11 | sean-k-mooney | fried_rice: well its not really more hacked up match and more a weigher. | |
| 14:31:38 | fried_rice | weighers are by definition hacks | |
| 14:31:43 | fried_rice | ...said someone I'm sure | |
| 14:32:11 | sean-k-mooney | ha perhaps | |
| 14:32:49 | giblet | fried_rice: https://github.com/openstack/nova/blob/68d4cb44edfe7b5f85618254cc906dcef44f7ce3/nova/scheduler/filter_scheduler.py#L238 | |
| 14:33:07 | fried_rice | yup | |
| 14:33:14 | sean-k-mooney | but unlike filter they are intended to handel the optimisation of the best host rather then filter which is what we want in thiscase. although as giblet mething we might need to look at multiple allcoation candiates which the weigher dont play a role in | |
| 14:34:06 | giblet | nova filter scheduler does not filter and weigh allocation candidates today | |
| 14:34:13 | giblet | it filter and weigh hosts only | |
| 14:34:21 | sean-k-mooney | yes im aware | |
| 14:34:46 | sean-k-mooney | but i think what fried_rice was asserting sounded like a weigher of the allocation candiates | |
| 14:35:01 | giblet | so we cannot prefer the candidate that keeps the port allocated from the same RP during resize-to-same-host | |
| 14:35:12 | fried_rice | sean-k-mooney: right: prefer candidates with [these ports] | |
| 14:35:17 | fried_rice | giblet: yes. | |
| 14:35:26 | fried_rice | we can't, but we should. | |
| 14:35:39 | sean-k-mooney | can you use in_tree to help | |
| 14:35:51 | giblet | fried_rice: soo we have to extend the filter interface to know about allocation candidates not just hosts | |
| 14:35:52 | sean-k-mooney | i guess that would force the same host | |
| 14:35:53 | fried_rice | well, we should be using in_tree for resize-to-same-host anyway. | |
| 14:36:07 | fried_rice | But that's unrelated to the problem of not moving the ports. | |
| 14:36:21 | fried_rice | giblet: I was just talking to mriedem about that the other day. | |
| 14:36:27 | fried_rice | and Sundar as well. | |
| 14:36:45 | sean-k-mooney | fried_rice: were we not talking about a subtree version too i dont know if we could restict the neutron request to the same RPs they had previously | |
| 14:36:57 | fried_rice | sean-k-mooney: Yes, there's a spec up for that. | |
| 14:36:59 | sean-k-mooney | i dont think the placement sysntax is that granuarly | |
| 14:37:03 | giblet | fried_rice: can we tell our preference to placement about return those a_c first that keeps the port allocated from the same RP? | |
| 14:37:03 | fried_rice | nope, not today. | |
| 14:37:19 | fried_rice | giblet: Not yet, but with the subtree thing we might be able to. | |
| 14:37:56 | sean-k-mooney | ya so resize to same host would basice add in_tree to the numbered requst group for the prot resouce or whatever the spec says | |
| 14:38:41 | sean-k-mooney | fried_rice: sound like a thing to solve in train | |
| 14:38:43 | fried_rice | Re allocation candidates to filters: I was thinking we ought to extend BaseFliter with a new method that accepts the allocation candidate under consideration, as well as the (relevant subset of the) provider_summaries. We do the try/except NotImplemented and fall back to the old method so we don't break existing filters. But new filters can then be written to take that information into account. | |
| 14:39:00 | sean-k-mooney | fried_rice: ya that came up before | |