QA (public) » openQA Project (public)

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).

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 .

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.

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.

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)

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

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.

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

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.