Daniel Kłobuszewski

Hm... This makes me think about a couple of things: - Versioning should be consistent between main CA module and the new API module. Specifically, the k8s dependency should use...

> > Versioning should be consistent between main CA module and the new API module. Specifically, the k8s dependency should use the same tag. > > Since 1.29 was already...

If we need separate process for cutting releases of the new module, we need to document it as well. I was thinking it could be piggybacking on the existing CA...

Yes, that makes sense to me, thanks. While reading about this a bit more, I came across https://go.dev/wiki/Modules#faqs--multi-module-repositories (see `Is it possible to add a module to a multi-module repository?`...

The more I read about this, the more I wonder if it wouldn't be a better idea to put this module in a separate repo under kubernetes-sigs.

Yeah, I agree trying to follow in k/k footsteps here would be an overkill. Submodule is ok, just need to follow these extra steps. I see right now CA repo...

We can merge this, but CA deps are mostly coming from k/k repo and are updated from there on each patch release. I see this package has not been updated...

Actually, this only updates go.mod and doesn't touch vendor, so is really a no-op. Please use [update-vendor.sh](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/hack/update-vendor.sh) for dependency updates.

+1 to the above, it should either be cloudprovider implementation detail (i.e. cloud provider can decide whether how to handle `DeleteNodes` - really delete or just deallocate) or a first...

This is unrelated to scale down logic - this is called only to reduce target size on a node group without actually deleting any nodes. The error suggests that it...