The question must be asked... do we allow anyone to remove any test? or will it be restricted and if so, how?

My initial opinion is that although there is some risk in allowing anyone to remove any test... it shouldn't really be a major problem if there's a clear 'are you sure!' dialogue :)

If anyone accidentaly removes a test, they can easily re-add it. Maybe even, there should be a 'disabled' state first, which then, if an accident occurs, one can 'undo' the removal. And if the test remains disabled for X days... it would be auto-deleted.

... end of friday brain dump ...

We will probably just mark the "task/test" as unavailable.  Especially if there are previous task runs which point to this task. We will remove the rpm of course.

It might be nice if an audit tool run say once a week sent out to an
appropriate email list(s)
 - tests/tasks queued for removal next week
 - tests/tasks removed this week

Maybe somehow with a/the supporting comment on why the test is being removed

Can this be also implemented into the beaker command line client for example as bkr task-del ?

Renaming tasks because of a typo makes sense.

Would we be creating more problems by deleting tasks than we would be solving? 

What if the creator of the task deems it unneeded, but there are other unknown people who still use it? Do I really need to sign up to a mailing list that monitors removal of tasks?

It may be cool, but it might also cause an unnecessary headache :-)

Hi, any update on this? Is there some workaround I can use before this is
implemented? Thanks.

Sorry Ales, we have not made any further progress with this. You'll have to continue doing whatever workarounds you are currently doing.

Hello,
ticket https://engineering.redhat.com/rt3/Ticket/Display.html?id=81684 was closed as "duplicate" of this bug. Adding myself as a requester here.

(In reply to comment #8)
> Hello,
> ticket https://engineering.redhat.com/rt3/Ticket/Display.html?id=81684 was
> closed as "duplicate" of this bug. Adding myself as a requester here.

This is a regression - in RHTS time we could at least bug eng-ops and they'd remove tests manually. All we can do now is watch our unmaintainable test-suites slowly becoming polluted by all the unwanted tests.

Please look into this

Any update on this issue please? I need a couple of tests that mess up the machine removed ASAP.

code pushed to gerrit for review.

Hello, 
Your ticket is ready for testing and is currently running on
https://beaker-stage.app.eng.bos.redhat.com

Please ensure your request for beaker has been adequately addressed by testing
it on the above machine. 

Testing will be available up until COB on the 20th April.

Thank you
Beaker development team

Can you please be more specific? The only difference I see is "Valid: yes" in task details. Is that it? How can I change it to "no"?

thanks

Hi Ales,

This requires admin access currently, Assuming this was production you would put in a ticket for the removal.  We can simulate that here by you telling me which task you need disabled and I'll do that.  This will remove the rpms and flip the DB entry so it doesn't show up or make it available for the scheduler.

Hmm, I have a feeling this is not fixed yet properly:

One of my tasks was deleted ~ a week ago:
/CoreOS/openssh/Regression/bz598671-ssh-X-Y-does-not-work-with-pam-namespace

I cannot see it via the web interface:
https://beaker.engineering.redhat.com/tasks/?simplesearch=openssh&search=Search

Though via "bkr task-list --package openssh" it gets still listed:
{'arches': [], 'name': '/CoreOS/openssh/initscript/stop-status'}
{'arches': [], 'name': '/CoreOS/openssh/initscript/safe-stop'}
{'arches': [], 'name': '/CoreOS/openssh/Sanity/init-scripts-LSB'}
{'arches': [], 'name': '/CoreOS/openssh/Sanity/sftp-selinux-context'}
{'arches': [], 'name': '/CoreOS/openssh/Sanity/ssh-copy-id-correct-selinux-labels'}
{'arches': [], 'name': '/CoreOS/openssh/Sanity/selftest'}
{'arches': [], 'name': '/CoreOS/openssh/Sanity/ssh-logins-visible-in-audit-log'}
{'arches': [], 'name': '/CoreOS/openssh/sshd/sanity'}
{'arches': [], 'name': '/CoreOS/openssh/scp/double-expand'}
{'arches': [], 'name': '/CoreOS/openssh/sftp/bz247802'}
{'arches': [], 'name': '/CoreOS/openssh/sftp/bz178923'}
{'arches': [], 'name': '/CoreOS/openssh/security/CVE-2009-2904-ChrootDirectory-restrictions'}
{'arches': [], 'name': '/CoreOS/openssh/security/CVE-2006-5052'}
{'arches': [], 'name': '/CoreOS/openssh/security/CVE-2007-3102'}
{'arches': [], 'name': '/CoreOS/openssh/Regression/bz120285-openssh-response-with-patch-level-info'}
{'arches': [], 'name': '/CoreOS/openssh/Regression/bz472493-sshd_config-accepts-match-parameter'}
{'arches': [], 'name': '/CoreOS/openssh/pam/session-close'}
{'arches': [], 'name': '/CoreOS/openssh/Multihost/ipv6-sanity-test'}
{'arches': [], 'name': '/CoreOS/openssh/Regression/bz594084-wrong-users-and-groups-creation-in-spec-file'}
{'arches': [], 'name': '/CoreOS/openssh/Regression/bz613627-authorized_keys_patch'}
{'arches': [], 'name': '/CoreOS/openssh/Regression/bz598814-Public-Key-authentication-fails'}
{'arches': ['ppc', 'x86_64', 'i386', 'ppc64', 'ia64'], 'name': '/CoreOS/openssh/Regression/bz594815-openssh-can-use-CPACF-via-ibmca-module'}
{'arches': [], 'name': '/CoreOS/openssh/Regression/bz559542-leaked-tcp_socket-file-descriptor'}
{'arches': [], 'name': '/CoreOS/openssh/Regression/bz532559-ForceCommand-directive-in-openssh'}
{'arches': [], 'name': '/CoreOS/openssh/Regression/bz576765-sftp-fails-if-users-bashrc-outputs-to-stderr'}
{'arches': [], 'name': '/CoreOS/openssh/Regression/bz616396-lastlog-is-not-recorded-with-the-big-uid'}
{'arches': [], 'name': '/CoreOS/openssh/Regression/bz598671-ssh-X-Y-does-not-work-with-pam-namespace'}
{'arches': [], 'name': '/CoreOS/openssh/Regression/bz632402-audit-crypto-usage'}
{'arches': [], 'name': '/CoreOS/openssh/Sanity/gssapi-with-mic'}
{'arches': [], 'name': '/CoreOS/openssh/Sanity/bz659242-escape-sequences-work'}
{'arches': [], 'name': '/CoreOS/openssh/Regression/bz661669-sshd-can-run-under-non-root-account'}
{'arches': [], 'name': '/CoreOS/openssh/Regression/bz680722-hanging-ssh-notty-flooding-audit'}
{'arches': [], 'name': '/CoreOS/openssh/Regression/bz642927-add-relro-flag'}
{'arches': [], 'name': '/CoreOS/openssh/Regression/bz676665-ssh-pubkey-with-polyinstantiation'}
{'arches': [], 'name': '/CoreOS/openssh/Regression/bz657059-add-umask-capabilities'}
{'arches': [], 'name': '/CoreOS/openssh/Sanity/bz455350-support-centralized-management-of-keys'}
{'arches': [], 'name': '/CoreOS/openssh/Regression/bz681296-SSH_USE_STRONG_RNG-for-seeding-from-dev-random'}
{'arches': [], 'name': '/CoreOS/openssh/Regression/bz691320-sshd-segfaults-if-other-instance-already-running'}
{'arches': [], 'name': '/CoreOS/openssh/Regression/bz656415-pam_ssh_agent_auth-does-not-properly-restore-euid-if-connect-to-the-ssh-agent-socket-fails'}

The bkr task-list command should probably pass {'valid': True} in the filter argument to tasks.filter().

--- a/Client/src/bkr/client/commands/cmd_task_list.py
+++ b/Client/src/bkr/client/commands/cmd_task_list.py
@@ -51,6 +51,7 @@ def run(self, *args, **kwargs):
         filter['types'] = kwargs.pop("type", None)
         filter['packages'] = kwargs.pop("package", None)
         filter['install_name'] = kwargs.pop("install_name", None)
+        filter['valid'] = True
         params = kwargs.pop("params", [])
         xml = kwargs.pop("xml")
 
---

We could also add an option --include-invalid that overrides this behaviour (returning both valid and invalid tasks) but I don't think there would be any use for that. Users should not be concerned with disabled/invalid/deleted tasks I think.