Michael
Michael
Having this problem as well.
Just for the record, I finally figured out what the issue was. We had a newer version of `btcutil` installed because we were previously using a [different HD wallet package](https://github.com/miguelmota/go-ethereum-hdwallet)...
Just coming back to this to post what we're currently using as a workaround (honestly works better than what we had before): Instead of using local timestamps and physically waiting...
First off, no coincidence with a recent update—I froze both the API server on my cluster and my local CLI install on `1.0.0.dev20250413` due to an API mismatch issue when...
Not sure if this is helpful (i.e. if it's the about same for all automatic Ray installs done by SkyPilot), but this is the full command that's logged: ```I 04-22...
Looks like the Ray opts in question are templated at `sky/provision/kubernetes/instance.py:1059`. Problem more broadly seems to be that one can't just take Kubernetes resource claims and pass them as Ray...
Ah woops, thought this was an issue with RP instances and not the controller 🤦♂ Inspected the controller pod and it was indeed using 0.5 cores, despite my most recent...
Also excuse my ignorance about the implementation details here, but why is the k8s cpu claim passed directly on the second `ray start` attempt?
Misdiagnosed the cause of this; the feature request remains the same