Remove nameOverride from helm chart. The reason lies in the implementation of operator:
The fullname of the alluxio cluster depends on the nameOverride, according helm chart logic.
The name of a load job will include the fullname of the alluxio cluster, so that the user would be able to know which data the job is loading.
The load crd, which provides the parameters to launch underlying load job, only has the name of the alluxio cluster as a parameter. So to construct the underlying load job name, we grab the alluxio cluster, find nameOverride, and then construct the fullname.
When we destroy the underlying load job, the request doesn't contain the name of the alluxio cluster anymore, and thus there's no way for us to find the name of the underlying load job.
Therefore, by removing nameOverride, the name of the underlying load job doesn't depend on the nameOverride anymore, and thus we are able to find and delete the underlying load job.
nameOverride should not be modified in usual case anyways.
Nvm the fullname still depends on the name of the alluxio cluster. The only solution is to make the load job name doesn't contain the alluxio cluster name.
Remove
nameOverride
from helm chart. The reason lies in the implementation of operator:nameOverride
, according helm chart logic.load
job will include the fullname of the alluxio cluster, so that the user would be able to know which data the job is loading.load crd
, which provides the parameters to launch underlyingload job
, only has the name of the alluxio cluster as a parameter. So to construct the underlyingload job
name, we grab the alluxio cluster, findnameOverride
, and then construct the fullname.load job
, the request doesn't contain the name of the alluxio cluster anymore, and thus there's no way for us to find the name of the underlyingload job
.nameOverride
, the name of the underlyingload job
doesn't depend on thenameOverride
anymore, and thus we are able to find and delete the underlying load job.nameOverride
should not be modified in usual case anyways.