specify DM-worker instance when create upstream source

[csuzhangxc]

Feature Request

Is your feature request related to a problem? Please describe:

for operate-source create, we may want to ensure the specified DM-worker can handle/bound it.

like on DM-worker has more disk space to hold a large amount of full dumped data.

Describe the feature you'd like:

add a flag like -w to specify a DM-worker instance which prefers to be bounded.

Describe alternatives you've considered:

Teachability, Documentation, Adoption, Migration Strategy:

[jerrylisl]

if the specified worker is already bounded, should scheduler unbound the old source and bound the new one or return an error?

[lance6716]

This feature is not implemented, welcome to discuss and contribute!

Currently I think returning an error is OK, user can use transafer-source to trasnfer the old one and try binding again

[glorv]

Maybe we could provide a --force parameter🤔

[jerrylisl]

If the specified worker-name is invalid, the source will also be unbound(and return an error). Besides, operate-source create allows create multiple sources once, so the -worker can't be directly used in cmd, it may be added in the config.yaml, is this OK?

[lance6716]

If the specified worker-name is invalid, the source will also be unbound(and return an error). Besides, operate-source create allows create multiple sources once, so the -worker can't be directly used in cmd, it may be added in the config.yaml, is this OK?

we can limit the ability of this feature. In my option,

• if worker-name is invalid, we should not create the source. Because we may provide a "atomic" guarantee to some extent for this command.
• if --worker is provided, we only tolerate this command to have one source. User can call dmctl many times if he wants.
• We should not add this worker information in configuration file, because the file should merely contain information about upstream.

[jerrylisl]

• if --worker is provided, we only tolerate this command to have one source. User can call dmctl many times if he wants.
• We should not add this worker information in configuration file, because the file should merely contain information about upstream.

adding this limit makes more sense, if do so, current OperationSource req needs add a worker param

[jerrylisl]

• if worker-name is invalid, we should not create the source. Because we may provide a "atomic" guarantee to some extent for this command.

when the worker is invalid, source will not be create; and when the worker is already bound, source will be create, this may make this operation a little confused.