| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-11-20 | |||
| 12:18:05 | sean-k-mooney | xek: going froward i belive we are droping support for unverioned notifications. i dont belive we intend to remvoed them but we had discussed freezeing the code and not fixing new buts | |
| 12:18:08 | sean-k-mooney | *bugs | |
| 12:19:33 | jaosorior | sean-k-mooney: thanks, we're aware of the unversioned notifications deprecation. Hence why we started testing the versioned ones. instance.delete.end should be in the versioned notifications too (according to the list in the doc xek pointed at). So... if it's not being emmited, I think it's a bug. We'll file it up. | |
| 12:19:39 | jaosorior | unless that doc is outdated :/ | |
| 12:20:09 | sean-k-mooney | jaosorior: if the versioned notifcation is not beeing emited its a bug yes | |
| 12:20:45 | sean-k-mooney | that said the notifacion may have been lost in rabbitmq if you dont have perstency | |
| 12:20:51 | sean-k-mooney | i assume its repeatable | |
| 12:21:02 | jaosorior | sean-k-mooney: can yo ellaborate on that? | |
| 12:21:57 | sean-k-mooney | jaosorior: you can configure rabbitmq to persist each message to disk until its dequeued or it can keep them just in memory | |
| 12:22:26 | sean-k-mooney | using durable queue is a significant perfromace hit but if rabbit is restarted messages are not lost | |
| 12:22:40 | sean-k-mooney | i do not belive the queue used for notifcation are durabel | |
| 12:23:21 | jaosorior | sean-k-mooney: so, a bit of context: xek is working on getting functional tests for novajoin (a vendordata plugin for nova). These functional tests are being set up on top of devstack.... do you happen to know if this would be an issue that would hit a small devstack deployment? | |
| 12:23:47 | xek | sean-k-mooney, we saw some heartbeat misses and thus connectivity issues in the logs, but we didn't restart rabbitmq | |
| 12:23:54 | jaosorior | sean-k-mooney: we ultimately use it in TripleO, however, we haven't actually had issues with the notifications (yet). So I guess the rabbitmq settings are OK :D | |
| 12:23:58 | xek | sean-k-mooney, and it's pretty consistent | |
| 12:24:07 | sean-k-mooney | no idea unfortunetly i dont know what the default is | |
| 12:24:28 | xek | the default is non-persistent | |
| 12:24:45 | sean-k-mooney | oslo messaging and rabit by default do not gurantee message delivery as far as i am aware | |
| 12:24:59 | sean-k-mooney | if there was a tempary network issue the notifcaion could have been lost | |
| 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 | |