Updates to Kind with GPUs setup #21
Conversation
|
@rohanarora We did have a valid reason for wanting to be able to set it up without sudo, because we did not have sudo on a bunch of the machines @mal-zurich was using for her experiments. that said, looking at the pre-requisite steps here, I think this stuff is probably already there on those machines and if not, we could ask it to be setup. and it is indeed better to not be using a fork of kind. |
| --set driver.enabled=false \ | ||
| --set mig.strategy=none \ | ||
| --version 23.3.1 | ||
| --set driver.enabled=false |
There was a problem hiding this comment.
Are we sure it is OK to remove:
--set mig.strategy=none \
--version 23.3.1
Missing these two options caused many problems for us in the past.
There was a problem hiding this comment.
It has worked without those options for me in both MIG and non-MIG environments on different machines.
Ir-respective for environments which have GPUs with MIG enabled, the key seems to be to create GPU MIG instances prior to installing the operator other-wise the CUDA validator fails.
| ``` | ||
|
|
||
| And verify the installation: | ||
| ```shell | ||
| $ which kind | ||
| ~/bin/kind | ||
| /usr/local/bin/kind |
Thomas (@tdoublep), As a result of this development, the use of
kindclusters with GPUs has been streamlined. The use of the forked version ofkindcan now be avoided.But it requires the prerequisite steps to be done and those need
sudoprivileges. Should we consider switching to this approach?