Get rid of wget dependency

[jjyao]

We are planning to release slim version of Ray image which won't have wget available but kuberay depends on it. It should be possible to get rid of this dependency and use something else.

This means slim Ray image will only work with new versions of Kuberay but that's OK.

[andrewsykim]

There's a PR open to use http probes #2360

HTTP probes are probably what we want eventually, but the limitation is that it can only check a single endpoint and in some cases we need to check multiple endpoints, hence we are using wget in an exec probe. Will the slim version have an alternative tool we can use in the exec probe like curl?

[kevin85421]

This means slim Ray image will only work with new versions of Kuberay but that's OK.

what's the image tag? Does ray-project/ray:X.Y.Z still have wget?

[aslonnie]

Does ray-project/ray:X.Y.Z still have wget?

it still has wget, but we are looking into releasing and allowing users to use much smaller / minimized images, and will make having wget optional. smaller images are faster to build/load/autoscale/etc.

kqueue is already building their own min image. we have a promise to them to support minimized image in the future.

our most optimized min image will not have wget. having wget inside ray image should not be a required assumption.

[aslonnie]

HTTP probes are probably what we want eventually, but the limitation is that it can only check a single endpoint and in some cases we need to check multiple endpoints, hence we are using wget in an exec probe. Will the slim version have an alternative tool we can use in the exec probe like curl?

depending on curl does not feel right either.

what does the check look like now?

we can also:

• consider adding a (hidden?) subcommand in ray like ray healthprobe
• or say image can have a binary at /opt/ray/ray-healthprobe, and when it exists, then just use that; otherwise, fallback to wget
• or an image can have a binary at /opt/ray/ray-httpget, as a simple replacement for wget or curl

and bonus if it does not depend on the image having a bash in it either.

in principle, we would like to have protocol that does not depend on specific/extra/general stuff inside the image. we would like the kuberay <-> image interface to be narrow and clear.