goutamadwant commented on issue #17167: URL: https://github.com/apache/dolphinscheduler/issues/17167#issuecomment-5675822705
@ruanwenjun @davidzollo I reproduced the current behavior on 3.4.1 with two tenants and two ordinary users. Both users can see both worker groups and tenants, and all four tenant/group combinations execute successfully. Two additional checks confirmed that an explicit task group takes precedence over the workflow launch group, and that selecting another execution tenant works independently of the user's default tenant. The fixture used one physical worker, so this establishes logical placement behavior rather than physical resource separation. For a first version, I propose: - Add an optional `tenant_id` to administrator-managed database worker groups, with fresh-install and upgrade SQL for MySQL, PostgreSQL, and H2. Existing unbound groups remain shared. - Validate compatibility against each task's resolved worker group and effective workflow execution tenant. Include API preflight and an authoritative master check before dispatch, covering task overrides, schedules, backfill, subworkflows, and retries/restarts. Reject mismatches explicitly without silently falling back to `default`. - Let administrators manage all groups, while applying the same compatibility checks to administrator-triggered executions. - Add tenant selection to worker-group management. Refresh compatible project-scoped groups when the execution tenant changes in workflow-start and schedule configuration. - In task authoring, display each group's tenant requirement. Task definitions do not determine the eventual execution tenant, so filtering solely by the editor's default tenant could exclude valid workflows. - Prevent tenant deletion while groups remain bound. Keep reserved `default` and configuration-derived groups shared in this first version, and document that limitation. Existing project authorization and tenant-selection behavior would be preserved. Before implementation, could you clarify: 1. Should compatibility follow the selected execution tenant, or should ordinary users also be restricted to their default tenant? The latter changes current tenant-selection behavior. 2. Is optional single-tenant binding with shared legacy/default groups acceptable? 3. Should binding changes require a drained group, or may incompatible undispatched work fail at subsequent validation? 4. Is displaying tenant requirements during task authoring acceptable until an execution tenant is known? Regression coverage would include matching and mismatched bindings, task overrides, retained retry placement, administrator execution, existing permission denials, legacy groups, tenant deletion, and supported database upgrades. Let me know your thoughts. thanks! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
