Kibana: [ML] DFA clone usability issues

[sophiec20]

Found in 8.0.0-SNAPSHOT "build_hash" : "5de0ed9432f4b41b697c9f3bc28953834cd3eae1", "build_date" : "2020-08-06T12:34:55.776311Z",

Collection of usability issues in DFA clone.

1. DFA clone fails silently if index pattern is missing

If the kibana index pattern is missing, then you can still select to clone a data frame analytics job. However nothing happens. There is no error message to explain the missing index pattern.

Steps to reproduce.

1. Create a DFA job
2. Delete the kibana index pattern
3. Try to clone this job - nothing happens, no visible errors.

In anomaly detection, we disable the clone option if the index pattern is missing - this has led to multiple support questions asking why it is disabled. I would personally favour an error message that explains why I cannot clone, rather than to disable the menu option. However I also favour conformity. Happy to discuss.

Please also check behaviour in Transforms.

2. Clone fails to recognise job type

If I try to clone a job that was created using the API, it does not recognise the type of job etc. Looking at the JSON, it seems that if analyzed_fields is not present then the clone cannot tell job type or dependent variable, even though the JSON is valid.

Whilst this is less likely to impact end users, it would be useful to resolve as it is fairly common in internal troubleshooting to try to clone jobs that were created using scripts.

3. Changing the results field should have less prominence

The default value for the results field is ml. Changing the results field is a less common requirement, and would mainly only be needed if there was already an ml field in existence. Is there a way we can make it more obvious that there is no need to change this in general usage? Potentially hide behind an option, similar to Destination index same as Job ID. This is minor.

[elasticmachine]

Pinging @elastic/ml-ui (:ml)

[peteharverson]

I just hit case (2) above by doing the following steps:

• Run the QA df_analytics suite.
• Clone the grid_regression_1 job, keeping the config the same, but do not start the job immediately
• Back on the Jobs list page, edit the model memory limit of the job
• Attempt to start the job

The job fails to start and the following error is seen:

[sophiec20]

We are investigating a possible backend issue which might be causing this. In this case g1 was defined in includes fields, but the explain API thinks it isn't. The error above might not be related to (2) if analyzed_fields is defined in the cloned job.