| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-11-20 | |||
| 12:44:14 | sean-k-mooney | not hardware offloaded ovs | |
| 12:44:36 | jangutter | sean-k-mooney: that makes sense from that point of view. | |
| 12:45:17 | jangutter | sean-k-mooney: so what would a nice, intuitive, unambiguous way be to describe a packet processing pipeline that is run on a coprocessor? | |
| 12:45:37 | sean-k-mooney | it can also include things like ipsec offlaod too which does not show up in ethtool but is in the same vain as vxlan tunnel encap/decap offload | |
| 12:45:53 | jangutter | sean-k-mooney: it's a metric shedload of confusion. | |
| 12:46:36 | sean-k-mooney | well you could call it vswitch offload/accleration | |
| 12:47:01 | gibi | xek, jaosorior: please file a bug. I will go and try to reproduce it | |
| 12:47:17 | jangutter | sean-k-mooney: In my mind, I have broadly two classifications: things that happen "at the endpoint" (like TSO/ rx/tx checksum offload) and things that happen "before it hits the other endpoint". | |
| 12:47:55 | gibi | xek, jaosorior: I'm a bit on and off today | |
| 12:48:08 | jangutter | sean-k-mooney: yeah 'vswitch' is acceptable, I guess, but you don't necessarily need a vswitch. In theory, things like IPSEC/VXLAN would fit in my "second case" too. | |
| 12:48:28 | sean-k-mooney | jangutter: there is the offload phase the modifes the packet and the classifiact/switching pahses that desiced what modification to apply and where to send it | |
| 12:48:29 | jangutter | sean-k-mooney: if IPSEC is regarded as a tunnel... | |
| 12:49:05 | jangutter | sean-k-mooney: yeah, "more associated with the guest" and "more associated with the host". | |
| 12:49:41 | jangutter | sean-k-mooney: it would be awesome if we could classify them as "guest offloads" and "host offloads". | |
| 12:51:05 | sean-k-mooney | jangutter: i would be ok with that split | |
| 12:51:59 | jangutter | sean-k-mooney: only problem is that it's a bit ambiguous.... since obviously endpoints on the host can also make use of "guest offloads". | |
| 12:53:06 | sean-k-mooney | we could call the protocol offload instead and switching offloads | |
| 12:53:32 | jangutter | sean-k-mooney: hence why I thought "endpoint offloads" and "datapath offloads" are also good bikesheds.... | |
| 12:54:22 | jangutter | sean-k-mooney: "protocol offload" and VXLAN/IPSEC will cause a bit of confusion, but I'm fine with "switching/vswitch/eswitch offloads" | |
| 12:55:17 | sean-k-mooney | then network offloads and switching offloads? | |
| 12:55:31 | sean-k-mooney | i agree the tunnels are kind of both | |
| 12:55:36 | sean-k-mooney | they ware weird | |
| 12:55:55 | jangutter | sean-k-mooney: tell me about it. | |
| 12:57:10 | jangutter | sean-k-mooney: I almost want to call 'em "socket offloads". | |
| 12:57:35 | sean-k-mooney | so while we some of them dont work a l4 however | |
| 12:58:14 | sean-k-mooney | ignore the so while we | |
| 12:58:33 | sean-k-mooney | i need to full clear my buffer when i change what i was going to type | |
| 12:59:23 | sean-k-mooney | jangutter: since we are talking about nameing how do you feel about my nameing comments in https://review.openstack.org/#/c/572081/9/os_vif/objects/host_info.py@205 | |
| 13:00:04 | sean-k-mooney | e.g. the fact that the repsentor netdevs are really part of the contol plane not data plane since they do not transmit packets | |
| 13:00:29 | sean-k-mooney | the are kind of like the vhost-user sockets in that respect | |
| 13:00:59 | jangutter | sean-k-mooney: representors absolutely transmit packets. | |
| 13:01:02 | sean-k-mooney | the difference being if you implemented them correctly and ran tcpdump the kernel would actully allow you to sniff the packets | |
| 13:01:32 | sean-k-mooney | jangutter: the VF those but the netdev you add to ovs should not | |
| 13:01:36 | jangutter | sean-k-mooney: mainly, the first packet of a new flow, i.e. something that doesn't have a rule. | |
| 13:01:50 | sean-k-mooney | right the learning packet but not the rest | |
| 13:02:03 | sean-k-mooney | i forgot they are used for the exception path | |
| 13:02:10 | jangutter | sean-k-mooney: yep, and it's vital to things like tunnels... | |
| 13:02:33 | sean-k-mooney | networking is hard. | |
| 13:02:47 | sean-k-mooney | i need to respond to a downstream bug but ill be back in a while | |
| 13:02:52 | sean-k-mooney | did this help? | |
| 13:03:02 | jangutter | sean-k-mooney: thanks very much, this was very therapeutic! | |
| 13:03:34 | sean-k-mooney | ill try and review the spec today or at least this week i have it open on my monitor in anycase | |
| 13:04:22 | jangutter | sean-k-mooney: thanks, will be respinning to try to clarify that some "offloads" are more "off" than others. | |
| 13:12:51 | openstackgerrit | do3meli proposed openstack/nova master: Allow VMs to use unaddressed ports https://review.openstack.org/533249 | |
| 13:33:47 | dtantsur | hi folks! is there a high-level description of Placement API? /cc cdent | |
| 13:34:26 | bauzas | dtantsur: https://developer.openstack.org/api-ref/placement/ ? | |
| 13:35:18 | dtantsur | bauzas: this is low-level, it says how to use specific endpoints. I'm more interested in high-level flow. | |
| 13:36:06 | dtantsur | I want to make ironic optionally report to/consume placement | |
| 13:36:24 | dtantsur | I need to understand 1. what reporting actually means, 2. how a node can be reserved via Placement. | |
| 13:37:12 | bauzas | dtantsur: we also have https://docs.openstack.org/nova/latest/contributor/placement.html | |
| 13:37:57 | belmoreira | dtantsur are you tracking this work somewhere? | |
| 13:38:29 | dtantsur | belmoreira: mostly in my head for now.. the API design without placement bits is https://review.openstack.org/617953 | |
| 13:39:49 | dtantsur | let me try a specific question | |
| 13:40:10 | dtantsur | given that any Ironic node is represented by exactly one instance of a custom resource class | |
| 13:40:46 | dtantsur | to reserve a node I need: 1. GET /resource_providers?resources=CUSTOM_BAREMETAL:1&required=list,of,traits | |
| 13:40:57 | dtantsur | 2. POST /allocations with suitable UUID? | |
| 14:04:10 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Use long_rpc_timeout in select_destinations RPC call https://review.openstack.org/607735 | |
| 14:11:57 | mriedem | dansmith: a couple of questions in https://review.openstack.org/#/c/617898/ | |
| 14:20:14 | dansmith | jaypipes: you had feelings on this in the past, if you want to chime in ^ | |
| 14:27:19 | cdent | dtantsur: join us in #openstack-placement | |
| 14:37:25 | mriedem | dansmith: replied. i'd be +2 on that now unless you are going to update the little CRUD APIs thing | |
| 14:38:05 | mriedem | i could see value in trying to document your replies about alternatives to filtering on cell etc, but that might be more work than it's worth right now | |
| 14:39:14 | dansmith | mriedem: yep, I'll fix the crud wording first | |
| 14:40:13 | efried | prometheanfire, sean-k-mooney: If we're backporting that oslo.service change, we need to backport the nova fixage to those mocks. This was a pretty big PITA when we did it on master, requiring a weird lockstep of patches in nova and requirements. Let me find it quick... | |
| 14:42:49 | efried | Update nova to use the mocks and require the new release: https://review.openstack.org/#/c/615724/ | |
| 14:42:49 | efried | Update the requirements: https://review.openstack.org/#/c/616371/ | |
| 14:42:49 | efried | Remove the mocks from nova: https://review.openstack.org/#/c/616697/ | |
| 14:42:49 | efried | prometheanfire, sean-k-mooney: Okay, so I think it was, in this order: | |
| 14:43:39 | sean-k-mooney | efried: yes we would or we could not backport the oslo.service change at all | |
| 14:44:38 | efried | sean-k-mooney: Or we could just backport "remove the mocks". The only thing it affects is wallclock time for tox. The mocks are just avoiding real sleeps. | |
| 14:44:44 | sean-k-mooney | i would personally prefer to revet teh oslo change form the 1.31.x branch but that said it only breaks the unit test and does pass functional and tempest tests | |
| 14:45:11 | sean-k-mooney | efried: ya that is an option | |
| 14:45:31 | efried | yes, it's UT only. And it's because nova is mocking private things from oslo.service, and those private things are re/moved with that fix. | |
| 14:45:41 | efried | (and that was my bad, mocking the privates) | |
| 14:45:44 | openstackgerrit | Dan Smith proposed openstack/nova master: Add CellsV2 FAQ about API design decisions https://review.openstack.org/617898 | |
| 14:46:21 | sean-k-mooney | efried: yes but they were removed in a release of oslo.service that was above the max allowed by the upper-constratins for that release | |
| 14:47:14 | sean-k-mooney | efried: redhat has backported this internally and it broke everything so i know it will make lyarwood happy if we fixed nova upstream to work with that backport | |
| 14:48:23 | sean-k-mooney | efried: i guess https://review.openstack.org/#/c/616697/ is relitivly small | |
| 14:48:45 | efried | sean-k-mooney: I'm going to take the morning off. If you and/or dhellmann and/or prometheanfire want to fix it up, cool, or bug me about it later and I can propose whatever. | |
| 14:48:51 | efried | sean-k-mooney: Yes, it's trivial. | |
| 14:49:58 | sean-k-mooney | ok i can propose the backport for https://review.openstack.org/#/c/616697/2 | |
| 14:50:43 | sean-k-mooney | we cant bump to 1.33 on stable however | |
| 14:51:24 | sean-k-mooney | so we will need to get them to backport the sleep fixture. | |
| 14:52:13 | openstackgerrit | Eric Fried proposed openstack/nova master: Remove v1 check in Cinder client version lookup https://review.openstack.org/617927 | |
| 14:54:00 | openstackgerrit | Eric Fried proposed openstack/nova master: Consider root id is None in the database case https://review.openstack.org/613305 | |
| 14:59:25 | efried | sean-k-mooney: It looks like that's proposed anyway: https://review.openstack.org/#/c/617989/ | |
| 15:01:57 | sean-k-mooney | efried: yes chating to them on oslo channel | |
| 15:02:14 | sean-k-mooney | ill propse the backport for the 2 patches you suggested | |
| 15:02:24 | efried_pto | thanks sean-k-mooney | |
| 15:02:56 | sean-k-mooney | actully hberaud is gong to do it but ill keep an eye on it. enjoy your morning off | |
| 15:13:14 | jaypipes | dansmith: done | |
| 15:13:22 | jaypipes | dansmith: thx for the heads up on that. | |
| 15:19:40 | dansmith | jaypipes: thanks | |
| 15:19:48 | openstackgerrit | Chris Dent proposed openstack/nova master: WIP: Delete the placement code https://review.openstack.org/618215 | |
| 15:21:06 | openstack | Launchpad bug 1804253 in openstack-manuals "Capacity planning and scaling in Operations Guide - cells information is out of date" [Undecided,New] | |
| 15:21:06 | mriedem | if someone is looking to update the resurrected ops guide docs about cells https://bugs.launchpad.net/openstack-manuals/+bug/1804253 | |
| 15:21:13 | mriedem | ^ is still all cells v1 | |
| 15:26:21 | openstackgerrit | Hervé Beraud proposed openstack/nova stable/rocky: remove mocks of oslo.service private members https://review.openstack.org/619019 | |
| 15:26:59 | BjoernT | Hello, Is someone here aware of the implementation of ComputeManager._run_image_cache_manag as we run in to performance issues on a NFS mounted /var/lib/nova/instances directory and now had to increase rpc response timeout? | |
| 15:32:12 | sean-k-mooney | that ^ sound like an mdbooth kind of question but he does not seam to be about currently | |