| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-11-20 | |||
| 12:26:11 | sean-k-mooney | my understanding is oslo messaging will not buffer the notifaction to my knolage and retry sendign the notification to rabbit if it trys to send it and fail unless you code that on top yourself | |
| 12:27:39 | sean-k-mooney | i could be wrong about that however as this is a part of nova i have realy dealt with | |
| 12:28:25 | jaosorior | sean-k-mooney: got it, I guess the next step is to investigate how rabbitmq is being configured in devstack, and how to modify that configuration if necessary | |
| 12:28:31 | jaosorior | sean-k-mooney: thanks for the guidance! | |
| 12:35:51 | openstackgerrit | Chris Dent proposed openstack/nova master: Use external placement in functional tests https://review.openstack.org/617941 | |
| 12:35:52 | openstackgerrit | Chris Dent proposed openstack/nova master: WIP: Delete the placement code https://review.openstack.org/618215 | |
| 12:36:43 | openstackgerrit | Chris Dent proposed openstack/nova master: WIP: Delete the placement code https://review.openstack.org/618215 | |
| 12:36:54 | sean-k-mooney | jaosorior: xek for what its worth it looks like you can enable durable queues in the nova.conf and it default to false | |
| 12:36:56 | sean-k-mooney | https://docs.openstack.org/oslo.messaging/ocata/opts.html#oslo_messaging_rabbit.amqp_durable_queues | |
| 12:37:34 | sean-k-mooney | i should proably check the latest doc actully to see if that is still a thing | |
| 12:38:11 | jangutter | sean-k-mooney: would you perhaps be able to donate some of your copious free time towards the helping with the naming of things? | |
| 12:39:02 | jaosorior | sean-k-mooney: thanks! we'll check that out. | |
| 12:39:37 | sean-k-mooney | jangutter: hah i could stop procrastinating by looking at messaging stuff and look at nameing instead | |
| 12:40:11 | sean-k-mooney | jaosorior: https://docs.openstack.org/oslo.messaging/latest/configuration/opts.html#oslo_messaging_rabbit.amqp_durable_queues its there on latest too | |
| 12:40:13 | jangutter | sean-k-mooney: bring your bikeshed, it can be any colour as long as it's red. | |
| 12:40:58 | sean-k-mooney | haha | |
| 12:41:04 | sean-k-mooney | not pink | |
| 12:41:14 | jangutter | sean-k-mooney: I think we're close to peak confusion with what the heck "network offloads" mean. | |
| 12:41:16 | sean-k-mooney | jangutter: is this related to the os-vif spec | |
| 12:41:24 | sean-k-mooney | ah yes | |
| 12:42:16 | jangutter | sean-k-mooney: yaas.... anyone wanting to frighten their young'uns: https://review.openstack.org/#/c/607610/ | |
| 12:42:58 | sean-k-mooney | jay highlighted it to me yesterday | |
| 12:43:22 | jangutter | sean-k-mooney: googling NIC offloads leads me to: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/performance_tuning_guide/network-nic-offloads | |
| 12:43:59 | sean-k-mooney | yes when i think nic offload i think the things ethool say the nic can offload | |
| 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 | prometheanfire, sean-k-mooney: Okay, so I think it was, in this order: | |
| 14:42:49 | efried | Remove the mocks from nova: https://review.openstack.org/#/c/616697/ | |
| 14:42:49 | efried | Update the requirements: https://review.openstack.org/#/c/616371/ | |
| 14:42:49 | efried | Update nova to use the mocks and require the new release: https://review.openstack.org/#/c/615724/ | |
| 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 | |