[state-driver] check driver daemons startup status through sentinel file

[tariq1890]

This change is accompanied by the driver-container PR NVIDIA/gpu-driver-container#913.

We introduce a new sentinel file called .driver-daemons-status which will help the driver container ensure that the Fabric Manager and other daemons are all fully up and running before the driver container goes into the Running state.

For reasons of backward compatibility, we only enforce this check if the .driver-daemons-status file is present. This way, the operator will continue to work with other driver containers that don't have this capability

[coveralls]

coverage: 38.385% (-0.08%) from 38.466% — daemons-status-file into main

[shivamerla]

looks good to me!

[rahulait]

LGTM

[rahulait]

One quick question: what will happen if the user started with newer operator and newer driver image, then driver image wrote NotReady to that status file and fails to start the daemons correctly. If the user has to switch to an older image say which is working fine, will the operator be able to proceed in that case as the status file still exists on node with NotReady state? Or, will it be able to clear it and continue.

[tariq1890]

It's a valid concern. I am thinking that it may be best to clear the .driver-daemons-status once the driver container does a non-zero exit.

[rahulait]

It's a valid concern. I am thinking that it may be best to clear the .driver-daemons-status once the driver container does a non-zero exit.

Can we add it here?

gpu-operator/assets/state-driver/0500_daemonset.yaml

Line 153 in 144e6c4

command: ["/bin/sh", "-c", "rm -f /run/nvidia/validations/.driver-ctr-ready"]

[shivamerla]

It's a valid concern. I am thinking that it may be best to clear the .driver-daemons-status once the driver container does a non-zero exit.

I guess initially your PR was adding it under /run/nvidia/driver or the driver root itself which could have avoided this issue.

[tariq1890]

Can we add it here?

Done