Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-11-02
16:36:59 dansmith bauzas: yeah I think placement now has explicit defaults right?
16:37:02 bauzas I'm pretty sure we have some default value in the placement DB that says "16"
16:37:03 sean-k-mooney[m] but it still default to 16
16:37:07 dansmith sean-k-mooney[m]: right
16:37:17 sean-k-mooney[m] i think we can decrease inial to 4 for cpu an 1 for memory
16:37:22 dansmith so I think we can just move those and reno that operators who took those defualts years ago should change them likely
16:37:39 bauzas I don't wanna go procedural
16:37:39 sean-k-mooney[m] +1
16:37:51 bauzas so a specless BP could work for me but,
16:37:57 bauzas we need renos
16:38:01 dansmith sean-k-mooney[m]: yeah I think 4:1 CPU and 1:1 memory is fine for a default, we might need up to up for devstack I guess but that's where insane defaults should be :)
16:38:03 sean-k-mooney[m] yep i was thinking the same
16:38:10 bauzas + we need to ensure we consider the DB impact before
16:38:15 dansmith cool, specless bp and renos.. sounds good
16:38:37 bauzas if that becomes debatable in the reviews, we could go drafting more
16:38:42 sean-k-mooney[m] bauzas: i dont think there will be any
16:38:59 bauzas but here, we're talking of changing defaults, not changing existing deployments
16:39:00 sean-k-mooney[m] if we are just changing the initial values it wont affect existing RPs
16:39:02 dansmith yeah I think it'll be straightforward, but we can always revise the plan if needed
16:39:07 dansmith right
16:39:18 bauzas OK, looks to me we have a plan
16:39:24 dansmith #micdrop
16:39:40 bauzas #agreed changing overcommit CPU ratio to <16.0 can be a specless BP
16:39:49 bauzas yuriys: typey typey
16:40:16 bauzas and ping me on IRC once you have the Launchpad BP up so I can approve it
16:40:29 gibi OK
16:40:37 gibi is there anything else for today?
16:40:43 yuriys no idea what that means, but sounds good?
16:41:03 yuriys ill just coordinate through dan i suppose
16:41:16 gibi yuriys: you need a file a blueprint here https://blueprints.launchpad.net/nova/
16:41:33 gibi so we can track the work
16:41:41 dansmith yuriys: with just an overview of what we said, no big deal
16:41:46 gibi yepp
16:42:08 yuriys Ah sounds good. Dang, I thought I was going to have like do a whole speech and everything
16:42:14 yuriys just to win over votes
16:42:15 yuriys haha
16:42:18 gibi :)
16:42:26 dansmith yuriys: I told you it wouldn't be a big deal :)
16:42:44 gibi it is not a bid deal if dansmith is on your side ;)
16:42:45 yuriys yeah, i think the expandability still needs to be part of that doc btw
16:42:50 yuriys for dollar reasons
16:43:00 yuriys but ill throw up a BP and we'll go from there
16:43:11 gibi cool
16:43:28 gibi is there anything else for today? I don't see other topics on the agenda
16:44:12 gibi it seems not
16:44:19 gibi so then I have the noble job to close the meeting:)
16:44:29 gibi thank you all for joining today
16:44:40 opendevmeet Log: https://meetings.opendev.org/meetings/nova/2021/nova.2021-11-02-16.00.log.html
16:44:40 opendevmeet Minutes (text): https://meetings.opendev.org/meetings/nova/2021/nova.2021-11-02-16.00.txt
16:44:40 opendevmeet Minutes: https://meetings.opendev.org/meetings/nova/2021/nova.2021-11-02-16.00.html
16:44:40 opendevmeet Meeting ended Tue Nov 2 16:44:40 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
16:44:40 gibi #endmeeting
16:46:14 EugenMayer sean-k-mooney[m] what is the 'qemu' version. i guess nova-compute-qemu/stable 2:22.0.1-2 all is just management version of nova, not the actual qemu version
16:46:57 sean-k-mooney[m] try qemu-system-x86_64 —verions
16:47:18 EugenMayer sean-k-mooney[m] hmm, i use kolla, thus i guess libvirt is insite the docker package
16:47:52 sean-k-mooney[m] ah in that case you can docker exec into the nova_libvirt container
16:48:13 sean-k-mooney[m] it contians the libvirt and qemu binaries that are uesd
16:48:34 EugenMayer but that means that this is not controlled by me
16:49:11 EugenMayer sean-k-mooney[m] qemu-kvm 1:4.2-3ubuntu6.18 amd64 QEMU Full virtualization on x86 hardware
16:49:11 sean-k-mooney[m] well you could rebuild the container. do you have multiple servers with differnt cpus?
16:49:35 EugenMayer all main computes have the same (exact) - all have AMDs (there are smaller AMDs)
16:50:00 sean-k-mooney[m] if they are all exactly the same then there is no downside to using host-passthough
16:50:40 sean-k-mooney[m] it will give you the best performance but the limitation it imposes is you can only live migrate to other hosts with the exact same cpu
16:50:40 EugenMayer well i willh ave no live migrations
16:50:56 EugenMayer i have no live migrations since no shared block storage
16:51:11 EugenMayer (not planing to)
16:51:14 sean-k-mooney[m] you do not need shared storage for live migration
16:51:24 sean-k-mooney[m] it just makes it faster if you do
16:51:25 EugenMayer i guess a non-live migration from AMD-A to AMD-B should be no issue right
16:52:01 EugenMayer It tells me 'live migration is not available'
16:52:07 sean-k-mooney[m] cold migration has no cpu requirement beyond dont change the architeture i guess
16:52:37 sean-k-mooney[m] so ya you can always fall back to cold migration
16:52:42 EugenMayer sure, amd64 they all are, but most are the big ryzen, the others the little brothers
16:53:26 sean-k-mooney[m] so your other option is to find the closest cpu model that your qemu support and add in addtional cpu flags
16:53:34 EugenMayer 99% of live migration will happen between the main compute, all AMD Ryzen 9 5950X
16:54:02 EugenMayer doesnt host-passthrough also harm the security / encapsulation?
16:54:02 sean-k-mooney[m] you could group them in an az
16:54:30 EugenMayer yes, az planned for the big ones, the smaller ones are internal CI servers only (azure agents or concourse CI workers)
16:56:33 sean-k-mooney[m] no it just allows the vm to use all the cpu features
16:56:56 sean-k-mooney[m] host-model still allows the vm to know what model of cpu is used
16:57:08 EugenMayer hmm, all VMs are our VMs, no customers or such. so i know what runs on each of them
16:57:10 sean-k-mooney[m] so form a security point of view more or less the same
16:57:50 EugenMayer i guess passthrough and hosting freebsd could be an issue. What about running windows?
16:59:13 EugenMayer Thank you so much!
17:00:11 EugenMayer the only thing i disklike is that i would need to fix every compute and i'am not sure this configuration file is controlled by kolla, but they have overrides and in the end, i have chef, so this will do it in any case
17:01:31 sean-k-mooney[m] it is
17:02:11 sean-k-mooney[m] you can drop an override in /etc/kolla/config/nova.conf or in /etc/kolla/nova/nova-compute.conf i belvie
17:03:39 sean-k-mooney[m] https://docs.openstack.org/kolla-ansible/latest/admin/deployment-philosophy.html#kolla-s-solution-to-customization
17:03:53 sean-k-mooney[m] its basically the example they use
17:04:37 sean-k-mooney[m] its one of the reasons i like kolla
17:04:44 sean-k-mooney[m] it makes this type of config simple
17:04:48 yuriys there are way too many reasons to like kolla
17:24:26 EugenMayer sean-k-mooney[m] thanks. Did that with globa_pysical_mtu already
17:24:38 EugenMayer yuriys there also some to not do so. As with everything
17:33:42 EugenMayer sean-k-mooney[m] your right, nova.conf would work https://gist.github.com/EugenMayer/d74ffdc0b15db9c9c1af344bd27accd1
17:49:45 Zer0Byte hey @lyarwood are you there?
17:52:14 lyarwood \o evening, yeah
17:52:20 Zer0Byte hey
17:52:43 Zer0Byte https://bugs.launchpad.net/bugs/1949224
17:52:47 Zer0Byte is regarding about this bug

Earlier   Later