action #57170

No ability to delete Job Group

Added by asmorodskyi 5 months ago. Updated 19 days ago.

Status:WorkableStart date:23/09/2019
Priority:LowDue date:
Assignee:-% Done:

0%

Category:Feature requests
Target version:QA - future
Difficulty:easy
Duration:

Description

Motivation

There is no UI functionality allowing to delete job group.

Acceptance criteria

  • AC1: It is possible to delete a job group with no referenced job templates from the UI
  • AC2: Like AC1 but for job groups with job templates
  • AC3: The user is warned at least pointing out that the job results will be deleted according to the default retention policy
  • AC4: The user is warned that the deletion can not be undone by openQA
  • AC5: The user is warned that milestone tags will be gone

Suggestions

  • Add automatic tests for the ACs
  • Add a button for deleting job group
  • Provide a hint to the user with all necessary warnings, e.g. popup, when the delete button is pressed, and ask for confirmation
  • Ensure all related database entries are deleted, e.g. job templates, job group templates, but not test suites, etc.

History

#1 Updated by coolo 5 months ago

  • Category set to Feature requests
  • Priority changed from Normal to Low
  • Target version set to Ready
  • Difficulty set to easy

the main reason why is because it's unclear what the user expects from deleting a job group. There are various things, some are more obvious than others:

  • the job templates / yaml
  • the job results
  • the comments
  • the exclusively held assets

I guess we need a popup with at least pointing out that the job results will fade away (as the default retention will apply and the milestone tags will be gone). And a confirmation about the fact that it's not recoverable.

#2 Updated by cdywan 5 months ago

We had a conversation on Rocket about this last week, where these points came up:

  • In the table-based editor, you click x on all of the machines in the entire job group. The end result is an empty job group. Then you can delete via an API call.
  • In the YAML editor you can "empty" the group by specifying scenarios: {} or variations to that effect. Deleting the entire YAML however results in an error. As a follow-up step once again an API call is required to delete the job group.

So as per my understanding of this it results in the following user story:

  • Alex wants to delete a job group in order to prevent all scenarios within the group from being scheduled (creating jobs).

I think it's fair to not require users to know the details of "emptying" a group.

Note that with YAML we actually get a diff for free, so deleting as a proper feature would give us a backup and if we wanted to even the option of recovery via the audit log (although it's not particularly user-friendly for that purpose right now).

#3 Updated by asmorodskyi 5 months ago

cdywan wrote:

We had a conversation on Rocket about this last week, where these points came up:


  • In the table-based editor, you click x on all of the machines in the entire job group. The end result is an empty job group. Then you can delete via an API call.
  • In the YAML editor you can "empty" the group by specifying scenarios: {} or variations to that effect. Deleting the entire YAML however results in an error. As a follow-up step once again an API call is required to delete the job group.

So as per my understanding of this it results in the following user story:


  • Alex wants to delete a job group in order to prevent all scenarios within the group from being scheduled (creating jobs).

I think you missing the fact that not only schedules needs to be deleted but also all job results of all jobs was run in this Job Group ever otherwise you will get broken DB. And for me it is more important use case - to avoid confusion when people will look into "wrong" job group for previous results or will try to add new schedules in "wrong" job group .

#4 Updated by cdywan 5 months ago

asmorodskyi wrote:

cdywan wrote:

  • Alex wants to delete a job group in order to prevent all scenarios within the group from being scheduled (creating jobs).

I think you missing the fact that not only schedules needs to be deleted but also all job results of all jobs was run in this Job Group ever otherwise you will get broken DB. And for me it is more important use case - to avoid confusion when people will look into "wrong" job group for previous results or will try to add new schedules in "wrong" job group .

Thanks for pointing that out! From our previous conversation it hadn't been clear to me that deletion of the results should also be covered.

I should add in this case that my mention of a diff/backup of the last state of the group would not include any of the results, merely the definition of the job group.

#5 Updated by okurz 5 months ago

I am not sure if deleting the results is necessary (or ever covered). I would simply delete the job group connection – if that is even necessary – and leave the jobs alone. In any case, the priority is "Low" so we should not invest effort now.

#6 Updated by coolo 5 months ago

You can't delete the job group without deleting the job group connection - without node no edge.

But from what I understand, the real blocker is that you can't empty yaml groups. This needs to be fixed - but is strange without intenting deletion, so perhaps the priority isn't as low (as blocking the blocker)

#7 Updated by okurz 5 months ago

yes, that makes sense. Would it work to simply fall back to scenarios: {} whenever a user empties the complete YAML document?

#8 Updated by cdywan 5 months ago

okurz wrote:

yes, that makes sense. Would it work to simply fall back to scenarios: {} whenever a user empties the complete YAML document?

We could handle the special-case of an empty document to mean that, and it would cover uses of the editor as well as the API. Although I seem to recall us not wanting to do that from a previous conversation.

Or the editor could reset to a minimum viable YAML automatically, ie. with products: and scenarios defined but empty, whenever someone tries to preview/save an actual empty document.

#9 Updated by cdywan 4 months ago

Semi-related: gh#os-autoinst/openQA#2394 documents the case of an empty job group in terms of YAML explicitly.

#10 Updated by okurz 3 months ago

  • Description updated (diff)
  • Status changed from New to Workable

#11 Updated by cdywan about 1 month ago

  • Assignee set to cdywan

I'm going to make the editor "do the right thing" here and make it fill in the minimum YAML when a user empties the document.

#12 Updated by cdywan 25 days ago

  • Status changed from Workable to In Progress
  • Target version changed from Ready to Current Sprint

#13 Updated by cdywan 22 days ago

  • Status changed from In Progress to Feedback

#14 Updated by cdywan 19 days ago

Since the question came up in the PR as well:

The above fix makes the editor "do the right thing" and ensure the YAML is valid when the text area is emptied. Going by the above conversation, my understand is that we're okay with continuing to use the API route to delete job groups, and there's little interest in deleting a job group (and its results) graphically.

This assessment doesn't reflect my opinion. Please correct me if I'm wrong.

#15 Updated by okurz 19 days ago

  • Status changed from Feedback to Workable
  • Assignee deleted (cdywan)
  • Target version changed from Current Sprint to future

I am ok with that. I understand the consequence is that we unassign and set to "future" for the rest

Also available in: Atom PDF