[Registries configuration page] No "Stop scan" button when scan is in progress

[williamshen9999]

Please refer to #322

However, I would want to double confirm again if there will be chance to fix (or even improve) before v1.0.0?
For 322:
No "Stop scan" button... Ex: What if user accidentally scans a huge repo and wants to stop the scan?...

[fabriziosestito]

Stopping a scan is done by deleting the ScanJob resource. This follows the same pattern as Kubernetes batchv1 Jobs. In Kubernetes, a resource represents the desired state. When you delete that resource, you're saying that state is no longer desired.

[williamshen9999]

Hi @xingzhang-suse ,

according to @fabriziosestito 's comment above,
Stopping a scan is done by deleting the ScanJob resource. This follows the same pattern as Kubernetes batchv1 Jobs. In Kubernetes, a resource represents the desired state. When you delete that resource, you're saying that state is no longer desired.

Could you help to confirm if it will achieve by UI side? If yes, then just let me know the rough date to achieve. Thank you.

[fabriziosestito]

You can already delete ScanJobs, and they will stop running.

[williamshen9999]

Hi @fabriziosestito ,
Thanks for info. It's good to know that user can stop scanning by backend; however, I would still wonder if UI can also achieve? I think it would be a better experience for user~
Anyway, thanks for your info!

[xingzhang-suse]

I'm discussing with the UX designer about the user experience.
If user stop scan by this way, the current scan record will be gone. We should discuss if it is expected in common use case.
For example, NeuVector scanner remains the part of scanned results while user stop the scan.

[fabriziosestito]

Kubernetes’ built-in Jobs can be stopped simply by deleting the Job itself.
This is why we designed the ScanJob to behave this way.

The use case, meaning a user wanting to stop the Job and then view its history, is extremely niche, especially given that workload scanning will be the primary way the scanner is used.

Of course, it’s technically possible to implement, but I would wait until there is a strong business case, since it consumes time and adds complexity.
For this reason, I propose renaming the Stop button to Delete if that hasn’t already been done.

Additionally:
A ScanJob is ephemeral, it doesn’t contain meaningful information when it’s stopped. There are no logs or historical data, as it’s essentially just a trigger with a status.
We expect 99% of Jobs to be triggered automatically, without the user continuously watching them run, either by scanInterval or the workload's feature autolearn.
When we add telemetry with OpenTelemetry, metrics and traces for past deleted Jobs will be available through observability.

[oboc-sts]

The use case, meaning a user wanting to stop the Job and then view its history, is extremely niche, especially given that workload scanning will be the primary way the scanner is used.

Of course, it’s technically possible to implement, but I would wait until there is a strong business case, since it consumes time and adds complexity. For this reason, I propose renaming the Stop button to Delete if that hasn’t already been done.

Agree ^.