Bug 590033 - [RFE] removing tasks from task library
Summary: [RFE] removing tasks from task library
Alias: None
Product: Beaker
Classification: Community
Component: tests
Version: 0.5
Hardware: All
OS: Linux
low vote
Target Milestone: ---
Assignee: Dan Callaghan
QA Contact:
Depends On:
Blocks: 545868 593663 607708
TreeView+ depends on / blocked
Reported: 2010-05-07 14:58 UTC by Ales Zelinka
Modified: 2019-05-22 13:39 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-06-16 00:51:46 UTC

Attachments (Terms of Use)

Description Ales Zelinka 2010-05-07 14:58:06 UTC
It would be cool to be able to remove tasks from task library. 
few use-cases:
 * obsoleted tests no longer needed in task library
 * rename/fix name test (just today I've submitted /CoreOS/Sanity/Sanity/.. instead of /CoreOS/<component>/Sanity by mistake)
 * semi-automated tests not needed in library but added during mass import

Comment 1 Chris Ward 2010-05-07 15:10:12 UTC
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 ...

Comment 2 Bill Peck 2010-05-07 15:53:09 UTC
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.

Comment 3 Martin Jenner 2010-05-07 16:04:53 UTC
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

Comment 4 Zbysek MRAZ 2010-06-09 12:36:43 UTC
Can this be also implemented into the beaker command line client for example as bkr task-del ?

Comment 5 Raymond Mancy 2010-06-28 03:34:31 UTC
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 :-)

Comment 6 Ales Zelinka 2010-11-22 10:43:21 UTC
Hi, any update on this? Is there some workaround I can use before this is
implemented? Thanks.

Comment 7 Raymond Mancy 2010-11-23 00:53:31 UTC
Sorry Ales, we have not made any further progress with this. You'll have to continue doing whatever workarounds you are currently doing.

Comment 8 Jan Hutař 2011-01-28 07:05:03 UTC
ticket https://engineering.redhat.com/rt3/Ticket/Display.html?id=81684 was closed as "duplicate" of this bug. Adding myself as a requester here.

Comment 9 Ales Zelinka 2011-03-07 11:11:16 UTC
(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

Comment 10 Miroslav Vadkerti 2011-04-21 08:21:07 UTC
Any update on this issue please? I need a couple of tests that mess up the machine removed ASAP.

Comment 11 Bill Peck 2011-05-12 14:05:57 UTC
code pushed to gerrit for review.

Comment 12 Bill Peck 2011-05-16 20:16:02 UTC
Your ticket is ready for testing and is currently running on

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

Comment 13 Ales Zelinka 2011-05-17 10:01:13 UTC
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"?


Comment 14 Bill Peck 2011-05-17 10:48:14 UTC
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.

Comment 15 Miroslav Vadkerti 2011-05-31 08:47:17 UTC
Hmm, I have a feeling this is not fixed yet properly:

One of my tasks was deleted ~ a week ago:

I cannot see it via the web interface:

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'}

Comment 16 Dan Callaghan 2011-06-01 04:48:23 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.