Create users on Linux system using tenant_id to solve user confusion caused by k8s environment service restart or physical machine environment service migration

[wjmmjr]

Purpose of the pull request

This pull request aims to address the issue of user confusion caused by k8s environment service restart or physical machine environment service migration

Brief change log

Add tenantId to ProcessInstance.java and TaskExecutionContext.java
Add method "createUser(int userId, String userName)" and "createUserIfAbsent(int userId, String userName)" and "createLinuxUser(int userId, String userName, String userGroup)" to OSUtils.java
Modify method createTenant of TenantServiceImpl.java
Modify method handleCommand of ProcessServiceImpl.java,add code "processInstance.setTenantId"
Modify method buildProcessInstanceRelatedInfo of TaskExecutionContextBuilder.java,add code "taskExecutionContext.setTenantId"
Modify method getOrCreateTenant of TaskExecutionContextUtils.java, add user by tenantId

Verify this pull request

This pull request is code cleanup without any test coverage.

[SbloodyS]

Please use English in title and link this PR to your issue. @wjmmjr

[ruanwenjun]

-1 to this PR, you need to create DSIP first, I am not clear why this will cause user confusion and why set the uid can solve this?

[wjmmjr]

-1 to this PR, you need to create DSIP first, I am not clear why this will cause user confusion and why set the uid can solve this?

When deploying worker services using k8s, the user information in the container will be cleared after restarting the worker service, and the newly created users will not correspond to the users in the metadata table. Migrating services to new physical machines may also cause this issue. You can use native code for testing

[ruanwenjun]

-1 to this PR, you need to create DSIP first, I am not clear why this will cause user confusion and why set the uid can solve this?

When deploying worker services using k8s, the user information in the container will be cleared after restarting the worker service, and the newly created users will not correspond to the users in the metadata table. Migrating services to new physical machines may also cause this issue. You can use native code for testing

The main change in this pr is set the uid, please describe why the uid will affect this. We didn't meet this problem before.

[SbloodyS]

When deploying worker services using k8s, the user information in the container will be cleared after restarting the worker service, and the newly created users will not correspond to the users in the metadata table. Migrating services to new physical machines may also cause this issue. You can use native code for testing

DS tenants map linux user names, not uids, which I understand won't have any conflicts.

[ruanwenjun]

When deploying worker services using k8s, the user information in the container will be cleared after restarting the worker service, and the newly created users will not correspond to the users in the metadata table. Migrating services to new physical machines may also cause this issue. You can use native code for testing

DS tenants map linux user names, not uids, which I understand won't have any conflicts.

+1, the uid is transparent to ds.

[wjmmjr]

-1 to this PR, you need to create DSIP first, I am not clear why this will cause user confusion and why set the uid can solve this?

When deploying worker services using k8s, the user information in the container will be cleared after restarting the worker service, and the newly created users will not correspond to the users in the metadata table. Migrating services to new physical machines may also cause this issue. You can use native code for testing

The main change in this pr is set the uid, please describe why the uid will affect this. We didn't meet this problem before.

When deploying the dolphinscheduler worker service in a k8s environment and mounting PVC, all files in the PVC have corresponding users. When the dolphinscheduler worker service restarts, the users in the container are cleared, and the users are recreated in order of connecting to the dolphinscheduler worker. At this time, the username and userid are not consistent with the situation before restarting. Due to the username and userid matching in the PVC file, the user corresponding to the PVC file is incorrect after restarting the container

[wjmmjr]

When deploying worker services using k8s, the user information in the container will be cleared after restarting the worker service, and the newly created users will not correspond to the users in the metadata table. Migrating services to new physical machines may also cause this issue. You can use native code for testing

DS tenants map linux user names, not uids, which I understand won't have any conflicts.

The code I modified is tenant id, which corresponds to the UID of Linux

[SbloodyS]

The code I modified is tenant id, which corresponds to the UID of Linux

AS wenjun said the uid is transparent to ds.

When deploying the dolphinscheduler worker service in a k8s environment and mounting PVC, all files in the PVC have corresponding users. When the dolphinscheduler worker service restarts, the users in the container are cleared, and the users are recreated in order of connecting to the dolphinscheduler worker. At this time, the username and userid are not consistent with the situation before restarting. Due to the username and userid matching in the PVC file, the user corresponding to the PVC file is incorrect after restarting the container

You can specify mounting permissions for the pvc file to ensure that the permissions for the content mounted to different containers are consistent.