Open mikhail-sakhnov opened 1 month ago
FYI, @sharnoff We discussed with @Omrigan that it would be great to reflect the currently used cpuScalingMode in status or annotations for better observability plus probably we want to restart pod if the cpuScalingMode was changed - that actually would allow us to perform gradual testing manually without switching default mode.
Impacted Packages | Coverage Δ | :robot: |
---|---|---|
github.com/neondatabase/autoscaling/neonvm-controller/cmd | 0.00% (ø) | |
github.com/neondatabase/autoscaling/neonvm-daemon/cmd | 0.00% (ø) | |
github.com/neondatabase/autoscaling/neonvm-runner/cmd | 0.00% (ø) | |
github.com/neondatabase/autoscaling/neonvm/apis/neonvm/v1 | 0.56% (-0.00%) | :thumbsdown: |
github.com/neondatabase/autoscaling/pkg/neonvm/controllers | 11.74% (-0.05%) | :thumbsdown: |
github.com/neondatabase/autoscaling/pkg/neonvm/controllers/functests | 0.00% (ø) | |
github.com/neondatabase/autoscaling/pkg/neonvm/cpuscaling | 0.00% (ø) |
@sharnoff @Omrigan I noticed we don't have readiness probe for the vm pod. Wdyt about adding readiness probe to check neonvm-daemon socket availability?
@Omrigan
Didn't do another full pass yet, but a couple of notes: There are couple of unaddressed comments, maybe they slipped from you because they are on now-outdated code. They are visible in "Conversation" tab.
As I mentined, I haven't found any more unaddressed comments.
Do you plan to merge it with rebase or with squash?
I don't have any specific preference here, what do you suggest?
Introduce separate CPU scaling flow based on the vmSpec.cpuScalingMode
If vmSpec.cpuScalingMode is equal to
qmpScaling
the logic of the scaling is preserved as before:if vmSpec.cpuScalingMode is equal to
sysfsScaling
all cpu scaling requests go directly to the vm-runner /cpu_change, which in that configuration goes to the neonvm-daemon to reconcile required amount of online CPUs.Value
cpuSysfsStateScaling
also modifies the qemu and the kernel arguments to enable plug all CPUs but mark as online only first one.