| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-14 | |||
| 13:34:47 | leakypipes | figleaf: thx for the quick reviews on that series. I'll address those comments shortly. | |
| 13:35:19 | jangutter | sean-k-mooney: "Improve Nova-Neutron port binding through negotiation"... that title is a masterstroke. | |
| 13:35:39 | leakypipes | jangutter: that's one word to describe that... | |
| 13:36:40 | sean-k-mooney | jangutter: well its an attempt to sovle the fact that today unless you are carful it posible to deploy a fully working nova and a fully working neutron that are configure in such a way that they cannont work together | |
| 13:39:08 | sean-k-mooney | jangutter: the intent was to have nova/os-vif validate what binings can be supported by the hypervior and pass that info to neutron where neutron would compare that to what can be supported by the network backend and negociate a common binding by takeing the intersection of the two and selecting the first element of that intersect ordered by the values pass form nova | |
| 13:41:11 | sean-k-mooney | jangutter: anyway for your usecase i think we can introduce a new neutron VIF_TYPE but reuse the existing os-vif vif objects though i hope this will be the last or one of the last vif types we need to add to nova | |
| 13:42:28 | jangutter | sean-k-mooney: yeah, I had really wanted to have almost nothing touch the core, but it looks like there's always just one more bit left. | |
| 13:44:10 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Dump tracked version notifications when swap volume tests fail https://review.openstack.org/483939 | |
| 13:44:13 | sean-k-mooney | jangutter: actully could we just use VIF_TYPE vhost-user + Vnic_type virtio-forworder instead of the new VIF_type? | |
| 13:44:33 | sean-k-mooney | for the virtio_forworder case that is | |
| 13:44:37 | mriedem | melwitt: one of your patches failed a versioned notification swap volume functional test, unrelated, so https://review.openstack.org/#/c/483939/ is to help debug that | |
| 13:45:46 | sean-k-mooney | for the sriov case it would be vif_type ovs + vnic type direct as with melonox but no wew are missing passing the plugin for that to work... | |
| 13:45:52 | jangutter | sean-k-mooney: yeah, but how do you trigger the third-party OS-VIF plugin? | |
| 13:46:30 | sean-k-mooney | jangutter: yep alway one thing missing hehe VIF_TYPE is the only way until we have neutron pass the plugin | |
| 13:46:40 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Update URL home-page in documents according to document migration https://review.openstack.org/483757 | |
| 13:46:44 | sean-k-mooney | jangutter: or rather plugin name | |
| 13:48:14 | jangutter | sean-k-mooney: so I've also tested the vhost-user path, the ML2 plugin can tell Nova where it wants the socket and whether it's client or server mode. | |
| 13:49:42 | melwitt | mriedem: cool. looks like I have two legit func test failures on my counting instances patch too. gdi | |
| 13:49:54 | sean-k-mooney | jangutter: cool that will align your impentation with how dpdk alreay work when working with vhost user. do ye have support for server mode by the way? i would suggest making that the default if ye have | |
| 13:50:27 | jangutter | sean-k-mooney: I believe we do: it requires a fairly recent DPDK and QEMU I believe. | |
| 13:51:15 | sean-k-mooney | jangutter: it works with old version of qemu 2.1+ but you dont have reconnect until qemu 2.7 if i rember correctly | |
| 13:52:10 | sean-k-mooney | jangutter: do ye use dpdk to provide the vhos-user backend in the virtio forworder case or is that your own impelention of a vhost-user backend | |
| 13:52:10 | mriedem | bauzas: you want to send it in https://review.openstack.org/#/c/483133/1 ? | |
| 13:52:14 | jangutter | sean-k-mooney: yep, something like that. And RH's qemu has got tons of backports, so the version in the field doesn't necessarily mean it isn't capable. | |
| 13:52:24 | mriedem | superdan: easy +W https://review.openstack.org/#/c/483917/ | |
| 13:53:07 | jangutter | sean-k-mooney: from what I understand we use the DPDK vhostuser library, it's just not worth it implementing it yourself. | |
| 13:53:34 | superdan | mriedem: done | |
| 13:53:44 | sean-k-mooney | jangutter: tell me about it. there kernel is worse is a "3.10" kernel with back ports for at leat 4.4 that broke some older versions of dpdk that work with kernel 3.10 just not theres | |
| 13:54:22 | jangutter | sean-k-mooney: the term we use is "frankenkernel". | |
| 13:54:36 | jangutter | sean-k-mooney: sometimes affectionately, sometimes not. | |
| 13:56:26 | sean-k-mooney | jangutter: its a mixed blessing. some of the backports i like. and ya dpdk is ment to be a bunch of reusable libary that you use to build you own apps so it makes sense that you reuse it for the vhost backend | |
| 14:00:39 | sean-k-mooney | jangutter: leakypipes stephenfin mriedem im going to send a email to the mailing list on monday with a list of patchs that i would like to see mearged in of-vif before the client libary freeze | |
| 14:01:19 | leakypipes | sean-k-mooney: that would be awesome, thank you sir! | |
| 14:02:04 | jangutter | sean-k-mooney: thanks, on that note, I've got a question. | |
| 14:02:12 | sean-k-mooney | jangutter: leakypipes stephenfin mriedem, matt if we targeted wednesday to have the final release done of os-vif for pike that work from you to pull into novas requirements? | |
| 14:02:23 | sean-k-mooney | jangutter: sure | |
| 14:02:43 | stephenfin | sean-k-mooney: fine by me | |
| 14:02:59 | mriedem | sean-k-mooney: i think thursday is generally the final day, | |
| 14:03:00 | jangutter | sean-k-mooney: there's a patch to moshe's os-vif code that would make our (soon-to-be)upstreamed openvswitch support work out of the box. | |
| 14:03:09 | mriedem | so wed would work but you'd also have to coordinate the global-requirements update | |
| 14:03:25 | jangutter | sean-k-mooney: how would I propose that? | |
| 14:05:05 | sean-k-mooney | jangutter: jangutter is it this one https://review.openstack.org/#/c/478820/ or do you need a change in addtion to that one | |
| 14:05:38 | sean-k-mooney | jangutter: that was on my list of patches but if you need another change then simply rebase it on top of https://review.openstack.org/#/c/478820/ | |
| 14:07:00 | jangutter | sean-k-mooney: that's one. Moshe also makes an assumption about the representor lookup, and I've got some requests based on that. | |
| 14:07:36 | jangutter | sean-k-mooney: I could suggest, but moshel will have to test on his system. | |
| 14:08:15 | sean-k-mooney | mriedem: understood, is there someone on the requrements team i should flag this to so that we can do the requirements updates promtely | |
| 14:08:57 | mriedem | sean-k-mooney: i'm sure the reqs and release team are going to be aware of a flood of changes next week | |
| 14:09:01 | jangutter | sean-k-mooney: should I file a bug to propose the change? | |
| 14:09:14 | mriedem | which would be matthew thode, dims, dhellmann, etc | |
| 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) | |