Wednesday, 2022-10-26

« Tuesday, 2022-10-25 Index Thursday, 2022-10-27 »
*** tkajinam is now known as Guest396600:09
*** dasm|rover is now known as dasm|off01:18
*** tkajinam is now known as Guest397201:47
*** tkajinam is now known as Guest398605:43
*** tkajinam is now known as Guest398806:53
sahido/ technical detail regarding the new behavior for evacuate, wondering what kind of parameter for the API, any idea?08:07
sahids//what kind of parameter should I use08:07
sahidcurrently I'm passing target_state={active|stop}, but I'm not sure if that sound right now08:08
sahideven if I force it to stop for the new microversion08:09
sahidperhaps, target_behavior={old, stop}08:10
sahidsean-k-mooney: ^ in case that you have something in head08:10
sahidor I can just keep target_state with {None, stop}, where None will be the old behavior and stop the new behavior, stop will be forced for new API08:11
sean-k-mooneysahid: well with the old microverion you shoudl not pass target_state at all at the rpc layer it will default ot none12:18
opendevreviewBalazs Gibizer proposed openstack/nova master: Reproduce asym NUMA mixed CPU policy bug  https://review.opendev.org/c/openstack/nova/+/86268612:18
opendevreviewBalazs Gibizer proposed openstack/nova master: Handle zero pinned CPU in a cell with mixed policy  https://review.opendev.org/c/openstack/nova/+/86268712:18
sean-k-mooneyand then for the new microverion you can pass the flag it can be target_state="stop"12:18
sean-k-mooneyyou shoudl not need to ever pass started or old12:19
sahidsean-k-mooney: i see, so basically i kept the actual impl but update the REST API part + ofcourse some tests on compute API part12:44
sahids/kept/keep12:44
sean-k-mooneyyep12:44
sahidlet's make a try, thanks12:45
sean-k-mooney99% of what you have should not need to be changed12:45
sahid++12:45
*** dasm|off is now known as dasm|rover13:38
fricklernot sure if everyone is subscribed, discussion about the storyboard issue is now happening here https://lists.opendev.org/pipermail/service-discuss/2022-October/000370.html , sean-k-mooney has already given a good summary of UX issues13:47
sean-k-mooneyhopefully that wont derail things too much14:04
sean-k-mooneyfrickler: while that discussion is happening im more then happy to hold of doing anything with placment ectra14:06
sean-k-mooneybauzas: https://blueprints.launchpad.net/nova/+spec/libvirt-cpu-hotplug this is not hotplug14:07
sean-k-mooneyplease do not use that terminology anywhere near this14:08
sean-k-mooneyeven at teh kernel level that is incorrect14:08
bauzassean-k-mooney: well, https://www.kernel.org/doc/html/latest/core-api/cpu_hotplug.html seems the correct term14:08
sean-k-mooneyhotplug usussaly refer to addign or removing cpu pacakges14:08
sean-k-mooneyi.e. entire chips14:08
sean-k-mooneynot just onlineing/offlining indivuguale cores14:09
bauzasand https://lwn.net/Articles/537570/14:09
bauzassean-k-mooney: I know, but this is the official terminology, right?14:09
sean-k-mooneyi dont want to confust this with hotpluging cpus in the guest14:09
sean-k-mooneyits ambiguous in a nova context14:09
sean-k-mooneyif its the host or guest cpu that is hotplugged14:10
sean-k-mooneywhich si why i strongly dislike using it here14:10
bauzashttps://www.qemu.org/docs/master/system/cpu-hotplug.html <= yup because qemu supersedes this term14:10
fricklersean-k-mooney: given that nova is on LP and not considering changing that, reverting placement to LP too seems the only sane solution to me. by extension I also think that holds for any OpenStack project that is unlucky on storyboard. the question is who will invest in tooling to migrate issues back. or whether it is o.k. to just discard them14:10
sean-k-mooneythat why i prefer cpu-online-state-management or similr14:10
sean-k-mooneyfrickler: well for placement i was proposing explictly not merging any of them back14:11
bauzassean-k-mooney: I understand your concern, I'll change it but in the spec, I'll explain this is a cpu hotplug from the kernel, not for QEMU14:11
sean-k-mooneybauzas: i could live with that but i think its still the wrong terminology to use14:12
sean-k-mooneyare managing the onlien state14:12
bauzassean-k-mooney: ask the kernel team to change it :p14:12
bauzasbecause QEMU14:12
bauzasthey'd love this :p14:13
sean-k-mooneywe are doing echo 0 > /sys/devices/system/cpu/cpu4/online14:13
sean-k-mooneyits not wrong to refer to it as online state managemnt14:13
bauzassure, hence me renaming the blueprint name14:13
sean-k-mooneyhttps://www.kernel.org/doc/html/latest/core-api/cpu_hotplug.html#cpu-online-offline-operations14:14
bauzasbut as I said, unless I misunderstand, this is based on the CPU hotplug feature named like this in the kernel, right?14:14
sean-k-mooneythe also use the online offline termonology14:14
sean-k-mooneyit uses the same machinary the build for adding and removing phsyical cpu pakcages to orchstrate turing on and off indivugual hyperthread/cores yes14:14
bauzassean-k-mooney: true, again, I'm not opposed to the term change, I'll just explain in the spec what we refer by "online state management" 14:14
bauzaswfy ?14:15
sean-k-mooneyyep works for me14:15
sean-k-mooneywe had another request for "virtical scaleing" form a custoemr i.e. hotpluging a cpu to a vm based on load already this week14:16
bauzascloud, my ass14:16
* bauzas facepalms14:16
bauzaswe call it 'resize"14:16
sean-k-mooneyand variation on live resize ectra often come up so thats why im sensitive to this nameing14:16
fricklersean-k-mooney: o.k., so technically that should be very easy then. just a question of how much coordination/common policy is wanted14:16
bauzassean-k-mooney: yup, I understand your valid concern, let's not nitpick it14:17
bauzassean-k-mooney: but for your customer not understanding the cloud principles, please also tell him to rephrase correctly14:17
sean-k-mooneyfrickler: we might port some thing by hand if we need too but if we did i would want to treat it as a bug scrub exersize14:17
sean-k-mooneywe have less then 30 stories for placment i think total14:18
sean-k-mooney+ a couple for osc-placment plugin 14:18
sean-k-mooneyso thats the other reason im not too worried about tooling14:18
sean-k-mooneyother project are proably not as lucky14:18
fricklersean-k-mooney: that sounds manageable indeed and combining with scrubbing is a good idea, too14:19
sean-k-mooneybauzas: well i just tool them not until at least osp 20+14:21
sean-k-mooneyfor non redhattser we released 17 recently :)14:21
sean-k-mooneyin ohter words if we get to it it wont be for a few years14:22
bauzassean-k-mooney: that's a long ask for live-resize14:22
bauzasmy only concern is not whether we should do it, but about the term too14:22
bauzas'can I attach a new cpu live to a running guest" is an acceptable QEMU feature, but this is horribly not cloudy14:23
bauzas'can I resize my running instance with a new flavor so I could have one more CPU' is the correct way to ask14:23
sean-k-mooneyya libvirt and qemu can do it althogh you need to know the maxium number of cpu you might have ahead of time14:23
sean-k-mooneybut agree on the not very cloudy aspect14:24
bauzasI mean, if we nitpick on the hotplug term (that QEMU just hijacked), then I can nitpick on the customer ask saying he doesn't know what a cloud is, then :)14:24
sean-k-mooneywell hotplug did not come form the cpu side it came from pci devices orgianly as far as im aware 14:25
sean-k-mooneybut more relevent topic14:25
sean-k-mooneycan you add me to the spec when you push it or ping me14:25
sean-k-mooneyill add it to my review list14:26
bauzassure14:26
bauzasI'm now working on the prototype14:26
bauzasI was considering a new package structure in hardware14:26
sean-k-mooneyyou mean creating a folder in the libvirt driver for it?14:27
sean-k-mooneyhttps://github.com/openstack/nova/tree/master/nova/virt/libvirt14:27
sean-k-mooneybecide storage and volume14:27
sean-k-mooneyif so that proably makes sense yes14:28
bauzasno, turning hardware to be a package14:28
bauzasnot a single module14:28
bauzasvirt.hardware14:28
sean-k-mooneyin theory that is ment to work across drivers14:28
bauzasso we could have virt.hardware.cpu14:28
sean-k-mooneyas in parts of it are used by not libvirt14:28
bauzascorrect, but I guess cpu online state can be independent14:28
sean-k-mooneybut ok you could14:28
sean-k-mooneywell it woudl work on any linux14:29
bauzasthat tho relies on the kernel and sysds14:29
sean-k-mooneyso maybe powervm14:29
sean-k-mooneyor zvm14:29
bauzastrue, that was my current concerns14:29
sean-k-mooneywe dont really have any other driver that woudl use it anymore14:30
bauzaswell, actually, you're right, and this would confuse people14:30
bauzaswe agreed at the PTG to have this libvirt-specifc14:30
bauzasthen, nevermind14:30
bauzasI'll just create a package under libvirt14:30
bauzaslibvirt.cpu14:30
sean-k-mooneyack14:30
sean-k-mooneythat or put the function into host.py14:31
sean-k-mooneyhttps://github.com/openstack/nova/blob/master/nova/virt/libvirt/host.py14:31
sean-k-mooneybut its own thing proably is simpler14:31
sean-k-mooneywell cleaner14:31
bauzaswell, the host module is mostly for talking to the host libvirt API right?14:31
sean-k-mooneymostly but not entirly14:31
bauzastrue14:31
bauzasI just want to have some interface 14:32
sean-k-mooneywe lookup the firmware files for uefi there and i think some vtpm stuff14:32
bauzasbut I need to think it more14:32
sean-k-mooneyhonestly poc it however you feel is best14:32
sean-k-mooneywe can debttate it later but i think under the libvirt driver somewhere is the right approch14:32
bauzastru14:32
bauzastrue*14:32
sean-k-mooneybeyond that as long as you dont just put it in driver.py im more or less ok with it14:33
sean-k-mooneydriver.py is already too big14:33
bauzas:)14:33
sean-k-mooneyi know we will never get around to doing this but some day i would like to split up driver.py14:34
sean-k-mooney10k loc is excessive14:34
bauzasdon't (git) blame me :)14:37
Ugglaagree driver.py is a bit long. ;)14:54
*** han-guangyu is now known as Guest411223:08
« Tuesday, 2022-10-25 Index Thursday, 2022-10-27 »

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!