| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-06-13 | |||
| 19:06:38 | mriedem | mostly to poke the bear and air grievances | |
| 19:06:43 | mriedem | it wasn't even festivus | |
| 19:07:14 | mriedem | and now look at him, in front of congress and all | |
| 19:07:17 | mriedem | we really showed him | |
| 19:07:32 | dansmith | because congress has such high standads | |
| 19:07:34 | dansmith | *standards | |
| 19:08:17 | mriedem | like garth brooks, sean has friends in low places | |
| 19:08:33 | dansmith | heh | |
| 19:09:22 | melwitt | remember chris gaines | |
| 19:10:37 | mriedem | how could i forget | |
| 19:10:50 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Avoid unnecessary joins in delete_resource_provider https://review.opendev.org/657021 | |
| 19:10:50 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Delete resource providers for all nodes when deleting compute service https://review.opendev.org/657016 | |
| 19:10:51 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Optimize SchedulerReportClient.delete_resource_provider https://review.opendev.org/657070 | |
| 19:11:20 | mriedem | remember...THIS?! https://www.youtube.com/watch?v=oGpFcHTxjZs | |
| 19:12:17 | dansmith | man.. bad hair day | |
| 19:12:34 | melwitt | the intro made it look like the panpipe sound was coming from the tugboat lol | |
| 19:12:43 | mriedem | maya got her first exposure to that in the car last night, with me singing along to it | |
| 19:12:44 | melwitt | peruvian panpipes | |
| 19:13:05 | mriedem | and laura telling me to shut up | |
| 19:13:46 | melwitt | did you dance too? I remember you said that's a favorite for car trips with the family | |
| 19:14:03 | mriedem | i did the shoulder shake sure | |
| 19:14:09 | mriedem | it cannot be stopped | |
| 19:16:51 | melwitt | yeah, that's what I meant. shoulder shake was the thing they are a fan of | |
| 19:20:06 | efried | mriedem: http://paste.openstack.org/show/752899/ | |
| 19:20:09 | efried | not sure what else to say | |
| 19:21:27 | mriedem | efried: looks fine to me | |
| 19:21:33 | efried | ight, thx | |
| 19:31:53 | mriedem | lyarwood: efried: did anyone talk about case here? https://review.opendev.org/#/c/663011/17/nova/virt/libvirt/blockinfo.py@275 | |
| 19:34:04 | efried | mriedem: doesn't look like it's ever uppercase, but I really don't know. | |
| 19:35:33 | mriedem | yeah the image meta props don't define an enum | |
| 19:37:52 | mriedem | looks like libvirt / qemu uses q35 though http://logs.openstack.org/11/663011/17/check/tempest-full-py3/6a826d2/controller/logs/screen-n-cpu.txt.gz#_Jun_12_22_24_13_577256 | |
| 19:38:09 | openstackgerrit | Merged openstack/nova stable/rocky: Move get_pci_mapping_for_migration to MigrationContext https://review.opendev.org/661499 | |
| 19:38:17 | openstackgerrit | Merged openstack/nova stable/rocky: Allow driver to properly unplug VIFs on destination on confirm resize https://review.opendev.org/661500 | |
| 19:38:26 | openstackgerrit | Merged openstack/nova stable/rocky: Fixes multi-registry config in Quobyte driver https://review.opendev.org/662695 | |
| 19:38:34 | openstackgerrit | Merged openstack/nova stable/rocky: tox: Use basepython of python3.5 https://review.opendev.org/663887 | |
| 19:38:42 | openstackgerrit | Merged openstack/nova stable/rocky: docs: Don't version links to reno docs https://review.opendev.org/662178 | |
| 19:38:50 | openstackgerrit | Merged openstack/nova stable/rocky: Include all network devices in nova diagnostics https://review.opendev.org/661962 | |
| 20:01:07 | openstackgerrit | Merged openstack/nova master: Api-guide: Add Block Device Mapping https://review.opendev.org/522084 | |
| 20:07:38 | spatel | sean-k-mooney: Question | |
| 20:08:45 | spatel | building new cloud so should i go with linuxbridge or OVS ( any performance difference here? other than features) | |
| 20:15:07 | mriedem | efried: fwiw i'm going through stephen's metadata docs change now | |
| 20:15:22 | efried | mriedem: cool, thanks for that. | |
| 20:15:32 | efried | mriedem: It still hasn't rendered, right? | |
| 20:15:44 | efried | I guess I could pull it down and build it myself... | |
| 20:15:49 | mriedem | that's what i did | |
| 20:17:57 | mriedem | the docs are failing to build locally for me | |
| 20:32:52 | mriedem | i see why now | |
| 20:52:42 | mriedem | gdi i've only made it 10 of 22 files in this change | |
| 21:02:35 | sean-k-mooney | spatel: linuxbirdge is not that well tested i personally am much more comfortable with ovs however some large public cloud have use linux birdge like rackspace | |
| 21:03:12 | sean-k-mooney | spatel: in generall linuxbrige will have fewer fancy networking feature and tends not to scale beyond 10G | |
| 21:03:26 | sean-k-mooney | but its also simpler | |
| 21:04:07 | sean-k-mooney | so depending on your netwroking backgorund and the team that will be maintaining the clould you could be trading performace for lower operationgs costs | |
| 21:04:36 | spatel | sean-k-mooney: thank you, i am already using LinuxBridge in my cloud but yes its very simple, first time i am going to play with OVS so not sure what and where i am going to face complexity | |
| 21:05:12 | spatel | I may planning to use DPDK so i have to learn OVS | |
| 21:06:03 | sean-k-mooney | if your starting out with ovs its simpler to start with kernel ovs and learn how to use ovs-dpdk after you are comfortable with openflow and ovs in general | |
| 21:06:23 | sean-k-mooney | it just helps not to add dpdk to the learning curve | |
| 21:06:59 | sean-k-mooney | ovs is the default netrok backend for like 80% of all deployments in one form or another | |
| 21:07:45 | spatel | sean-k-mooney: hmm | |
| 21:08:48 | spatel | Is it possible i deploy ovs with general configuration and then slowly rollout ovs-dpdk compute by compute | |
| 21:09:18 | spatel | Can i have mix environment like currently i have SR-IOV with general compute | |
| 21:10:58 | sean-k-mooney | spatel: yes you can mix ovs and ovs-dpdk in the same cloud and you can also have sr-iov in that cloud | |
| 21:11:20 | sean-k-mooney | generally you will use a different host aggage to seperate your dpdk nodes that need hugepages form the rest that dont | |
| 21:11:30 | spatel | I think i should go with OVS so i can have all kind of function and feature available.. | |
| 21:12:00 | spatel | what are the basic requirement for dpdk? | |
| 21:12:11 | mriedem | efried: please don't fix the docs build break | |
| 21:12:16 | mriedem | i just dumped 42 comments on that change | |
| 21:12:34 | efried | mriedem: okay | |
| 21:12:37 | spatel | NIC support, hugepages etc.. | |
| 21:13:19 | sean-k-mooney | most nicst that support sriov support dpdk but there is a list here | |
| 21:13:20 | sean-k-mooney | https://core.dpdk.org/supported/ | |
| 21:13:47 | sean-k-mooney | that is more a list of driver but you likely have a nic that is supported | |
| 21:14:17 | sean-k-mooney | hugepages are needed for the guest and for the vswtich | |
| 21:14:25 | sean-k-mooney | other then that there are no special requiremetns | |
| 21:14:45 | mriedem | with that i think i'm done for the day | |
| 21:14:58 | spatel | I have - 04:00.0 Ethernet controller: Intel Corporation 82599 10 Gigabit Dual Port Backplane Connection (rev 01) | |
| 21:15:29 | sean-k-mooney | spatel: yep they use the ixgbe dirver and are supported | |
| 21:15:29 | spatel | How much hugepage required for vswitch? | |
| 21:15:46 | spatel | My all compute nodes are 32G memory ( some 64G) | |
| 21:16:25 | sean-k-mooney | dpending on your workload 2-4 G if you are using jumbo frams 1-2G is fine for standard 1500b packets | |
| 21:16:34 | sean-k-mooney | i have tunned it to less in the past | |
| 21:16:54 | sean-k-mooney | it jsut depends on your data rates and how long your queuse are going to be | |
| 21:17:36 | spatel | When you saying hugepage for vswitch does that means i have to give some dedicated hugepage to vSwitch right? | |
| 21:17:50 | sean-k-mooney | spatel: https://developers.redhat.com/blog/2018/03/16/ovs-dpdk-hugepage-memory/ | |
| 21:17:58 | sean-k-mooney | spatel: yes | |
| 21:18:40 | spatel | Nice doc.. | |
| 21:18:54 | sean-k-mooney | ovs-dpdk uses hugepage memroy to process packets so that it can DMA transfer packets directly to and from the nic bypassing the kernel | |
| 21:18:58 | spatel | sean-k-mooney: do i also need to give some dedicated CPU to vSwitch? | |
| 21:19:56 | sean-k-mooney | yes ideally 1 PMD(poll mode driver) core per numa node | |
| 21:20:41 | sean-k-mooney | ovs-dpdk scalse effectivly liniarly with the number of cpu cores you give it so you can tune it up or down depending on your data rates | |
| 21:20:52 | spatel | I have two numa zone so i have to give 2 CPU core right? is that CPU core will be pin with vSwitch? | |
| 21:21:30 | sean-k-mooney | yes dpdk will run in a bussy loop waiting for packets and will consume the full core | |
| 21:21:45 | sean-k-mooney | even when idel | |
| 21:22:15 | sean-k-mooney | it does that to miniumese latency but it basically means you cant run other thing on the core at the same time | |
| 21:23:06 | sean-k-mooney | per packet ovs-dpdk is much more efficent then kernel ovs however kernel ovs use kernel thread to process the packet and does not consume cpus cycles when idel | |
| 21:23:12 | sean-k-mooney | so its a trade off | |
| 21:23:25 | sean-k-mooney | ovs-dpdk cpu usage will be fixed based on the cores you allcoate it | |
| 21:24:00 | spatel | core allocation process is automatic or part of configuration? | |
| 21:24:01 | sean-k-mooney | kernel ovs will use less or more cpus as needed includeing stealing cpu cycles form the guests if you do not tune the kernel to prevent that | |
| 21:24:10 | sean-k-mooney | spatel: part of the configuration | |
| 21:24:32 | spatel | ah! ok.. | |