| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-14 | |||
| 14:09:20 | sean-k-mooney | jangutter: moshe has fortunetly got ther ci running so if you submit your patch and there ci does not explode then we just need to get him to review to confirm it did not miss anyting | |
| 14:10:40 | jangutter | sean-k-mooney: ok, let me see what I can whip up. | |
| 14:11:55 | sean-k-mooney | jangutter: yes. i will mark it as high proirity and review when it come in too. im assumeing your going to try and parse it there way(as an int) and if you get a vaule error fall back to your format? | |
| 14:13:08 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Add tags to instance.create Notification https://review.openstack.org/459493 | |
| 14:13:13 | jangutter | sean-k-mooney: yep, check if it's just and int, then search for "..vf(int)..", then just give up and cry in a corner. | |
| 14:13:42 | jangutter | sean-k-mooney: also, iterate through all the netdevs in the physfn directory, and check for the first one that has switchdev info. | |
| 14:15:02 | sean-k-mooney | jangutter: cool well when you get that working let us no. i need to head off soon but have you pushed you updated ml2 driver to github where you are passing the socket path and mode for vhost user? | |
| 14:15:21 | jangutter | sean-k-mooney: yep, that's also been updated. | |
| 14:17:16 | sean-k-mooney | jangutter: cool ill take a look over that too. one last question before i drop. is ther any way to "test" this without having one of your nics? i would not mind seting this up in a vm just to check it end to end but i guess the answer is no? | |
| 14:19:37 | jangutter | sean-k-mooney: not easily, no :-( it should be possible, but my estimation is that adding the dummy layer is going to take longer than shipping a NIC. | |
| 14:20:54 | jangutter | sean-k-mooney: you'll need to fake a vhost-user portion and a VF portion. You _can_ run everything and look at the errors (libvirt not running and os-vsctl failing). | |
| 14:20:56 | sean-k-mooney | jangutter: haha no worries, i just rembered you said somthing about the virtio-forwarder potentally working with any nic but i also assumed you menth the mechanisum not the impenation you have | |
| 14:21:57 | jangutter | sean-k-mooney: I'm fairly sure that virtio-forwarder will work for mech_sriov. | |
| 14:22:28 | jangutter | sean-k-mooney: provided you mod the ml2 in the right way, of course. | |
| 14:24:20 | sean-k-mooney | jangutter: are the virtio-forward change also planned to be upstreamed to the ovs-dpdk dataplane or will that remain in aligo ovs or as a seperate applicaiton? | |
| 14:25:38 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: use already loaded BDM in instance. |
|
| 14:25:54 | jangutter | sean-k-mooney: upstreaming virtio-forwarder is definitely the plan, but we don't have consensus over the form it will take. | |
| 14:28:30 | cdent | leakypipes: these still the right ones for your current thrust: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/placement-claims+owner:%22Jay+Pipes+%253Cjaypipes%2540gmail.com%253E%22 ? | |
| 14:28:57 | sean-k-mooney | jangutter: understood, when you get to that point let me know and i may be able to connet you with some people on our vswitch team who. we have done some work in the past on mapping vhost-user to hadware accleration so perhaps ye can collaberate when adding that support to upstream ovs | |
| 14:28:59 | leakypipes | cdent: ya. currently investigating the tempest failures (they are valid failures) | |
| 14:29:13 | sean-k-mooney | jangutter: anyway got to run | |
| 14:29:18 | cdent | ✔ | |
| 14:29:25 | jangutter | sean-k-mooney: thanks very much again! | |
| 14:31:27 | leakypipes | cdent, figleaf, mriedem, superdan: so... something I didn't quite anticipate (or rather, was ignoring and hoping we wouldn't run into it.) is resize to same host. With the code I added, we're getting NoValidHosts returning because the resize to same host operations are not taking resource claiming into account. | |
| 14:31:48 | leakypipes | cdent, figleaf, mriedem, superdan: I'm wondering if we need to just disable the scheduler claiming thing for move operations. | |
| 14:32:11 | cdent | oh yeah. I _think_ that’s one of the ideas we talked about in the past | |
| 14:32:48 | cdent | Is a bit annoying that yet another small piece of state needs to travel around, but life is hard | |
| 14:32:59 | figleaf | leakypipes: yeah, the scheduler is just used in those cases to ensure that the new host satisfies the original request | |
| 14:33:43 | leakypipes | figleaf: yeah. | |
| 14:33:48 | figleaf | leakypipes: but then again, why would that make things easier? | |
| 14:34:14 | leakypipes | figleaf: not sure it would... just brainfarting right now :) | |
| 14:34:25 | leakypipes | figleaf: investigating these few tempest failures. | |
| 14:34:31 | figleaf | leakypipes: ah | |
| 14:34:52 | figleaf | It's always better to have a single code path if possible | |
| 14:34:58 | openstackgerrit | Andrey Volkov proposed openstack/nova master: PoC: Select PCI devices with distinct tag values https://review.openstack.org/448008 | |
| 14:36:03 | cdent | if we had perfect memory we could recall all the conversations we had about this particular topic because it sure seems like we had a plan (short and long term) but my brain is grasping at nothing | |
| 14:36:29 | figleaf | cdent: I think the problem is that we have had several plans :) | |
| 14:36:41 | figleaf | Hard to keep them distinct | |
| 14:36:57 | cdent | I thinkin back all the way to early 2016 | |
| 14:37:10 | cdent | lost to the sands of time | |
| 14:37:18 | leakypipes | cdent: you mean the Crustacean period of OpenStack? | |
| 14:37:29 | cdent | wasn’t that the precambrian? | |
| 14:37:34 | leakypipes | cdent: lemme get my archeological shovel handy | |
| 14:38:25 | cdent | no, couldn’t have been precambrian, because big tent would have been in the cambrian explosion | |
| 14:38:44 | mriedem | resize to same host shouldn't be double claimed, as we already claimed it once | |
| 14:38:46 | mriedem | same with rebuild | |
| 14:38:57 | openstackgerrit | Jan Gutter proposed openstack/os-vif master: Add support for VIFPortProfileOVSRepresentor https://review.openstack.org/483921 | |
| 14:38:59 | mriedem | you have to consider rebuild to same host vs evacuate to another host - where evacuate is going to claim on the other host | |
| 14:39:09 | mriedem | where rebuild to same host is not going to claim again on the same host | |
| 14:39:35 | cdent | mriedem: we can’t double claim can we (unless we explicitily create a single claim with double values) because consumer uuids stay the same? | |
| 14:39:42 | cdent | (or is that not true) | |
| 14:40:05 | cdent | /o\ | |
| 14:40:20 | mriedem | i mean, in the compute manager today, it does a NopClaim if it's on the same host | |
| 14:41:43 | cdent | if anyone has any things they want to remind me of for today’s rp update, send me some mail, I’m going to go hime and write it | |
| 14:41:50 | cdent | home | |
| 14:41:58 | leakypipes | mriedem: well, not even rebuild/evacuate. it's also any move operation. because when claiming for the instance, we will end up overwriting the allocations for that instance_uuid. | |
| 14:42:49 | openstackgerrit | Jan Gutter proposed openstack/nova master: Netronome SmartNIC Enablement https://review.openstack.org/483459 | |
| 14:42:57 | mriedem | leakypipes: aren't the allocations for the instance + some RP? | |
| 14:42:58 | leakypipes | mriedem: which means that the resources will be claimed against the destination host resource provider and no longer on the source host as soon as scheduling happens. | |
| 14:43:25 | leakypipes | mriedem: no, an allocation is a set of resource consumed on one or more resource providers for a specific consumer. | |
| 14:43:36 | mriedem | sure, one or more | |
| 14:43:49 | mriedem | until we move, aren't we consuming on 2 RPs? | |
| 14:44:01 | mriedem | there is the allocation we're consuming on the source RP node, and the claim for the dest RP node | |
| 14:44:25 | leakypipes | mriedem: no. the key is the consumer UUID. so we overwrite all allocations for the consumer when we call PUT /allocations/{consumer_uuid} | |
| 14:44:28 | figleaf | mriedem: a consumer can only consume one set of allocations at a time | |
| 14:44:52 | mriedem | so....if it's still one or more RPs, | |
| 14:44:55 | mriedem | i don't see the problem, | |
| 14:44:55 | figleaf | leakypipes: we would have to combine the two sets and PUT that | |
| 14:45:05 | leakypipes | figleaf: right. so as soon as the scheduler claims resources against the newly-selected destination host for a move operation, the old allocations for the original source host are replaced. | |
| 14:45:14 | mriedem | we have an allocaiton for the instance on source RP node, and then we update that allocation to include the dest RP node | |
| 14:45:18 | leakypipes | figleaf: yeah, that's about all I can think to do. | |
| 14:45:35 | leakypipes | figleaf: which means the scheduler is going to need to know whether this is a move operation. | |
| 14:45:39 | mriedem | right i'm thinking the same, worded differently | |
| 14:45:41 | figleaf | leakypipes: or add a PATCH resource | |
| 14:45:49 | figleaf | :( | |
| 14:46:07 | leakypipes | figleaf: potentially, but the scheduler would still need to know it's a move operation, right? | |
| 14:46:16 | figleaf | yeah | |
| 14:46:38 | mriedem | i was going to send this to cdent https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L2779 | |
| 14:46:49 | mriedem | but ^ is what i was talking about with the nopclaim for rebuild on same host | |
| 14:46:58 | leakypipes | figleaf, mriedem: I think the "safest" thing to do is just disable claims in the scheduler for all move operations. so we'd just pass an indicator in the RequestSpec that this is a move operation and don't do any claiming if it is. | |
| 14:47:16 | mriedem | and then smartify it in queens? | |
| 14:47:20 | mriedem | because that's a short term hack right? | |
| 14:47:21 | leakypipes | yeah | |
| 14:47:36 | leakypipes | smartify it == the solution figleaf said above. | |
| 14:47:42 | figleaf | mriedem: I like smartifying stuff | |
| 14:47:57 | mriedem | can't we figure out if it's a move by checking if there are already existing allocations for that consumer? | |
| 14:48:12 | mriedem | or does that tread on retry territory | |
| 14:48:38 | leakypipes | mriedem: yes, but that would mean another set of HTTP communications for each scheduler request. | |
| 14:48:51 | leakypipes | mriedem: and we are already calling GET /allocation_candidates once per request. | |
| 14:48:53 | mriedem | yeah, so let's not do that then | |
| 14:49:11 | mriedem | if reqspec.movify: | |
| 14:49:12 | figleaf | leakypipes: true, but it might not mean dirtying as much code now | |
| 14:49:17 | melwitt | superdan: do you know if instance.old_flavor is a thing I can rely on to be there for an instance that's in VERIFY_RESIZE state? resized but not confirmed nor reverted? | |
| 14:49:27 | leakypipes | mriedem: especially since it's easy enough for the nova-api or conductor to add a field to the RequestSpec saying it's a move operation. | |
| 14:49:32 | mriedem | figleaf: it does mean a perf hit though | |
| 14:49:38 | mriedem | i'd rather pass a flag than take a perf hit | |
| 14:49:42 | mriedem | for ALL requests | |
| 14:49:43 | superdan | melwitt: yep, should be find if it's in any resize-related state I think | |
| 14:49:49 | melwitt | yesss | |
| 14:49:56 | figleaf | mriedem: yes, but small, but it will be smartified later! | |