Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 590033 - [RFE] removing tasks from task library
[RFE] removing tasks from task library
Status: CLOSED CURRENTRELEASE
Product: Beaker
Classification: Community
Component: tests (Show other bugs)
0.5
All Linux
low Severity low (vote)
: 0.6.13
: ---
Assigned To: Dan Callaghan
: Reopened
Depends On:
Blocks: 545868 593663 607708
  Show dependency treegraph
 
Reported: 2010-05-07 10:58 EDT by Ales Zelinka
Modified: 2011-06-15 20:51 EDT (History)
18 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-06-15 20:51:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ales Zelinka 2010-05-07 10:58:06 EDT
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 11:10:12 EDT
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 11:53:09 EDT
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 12:04:53 EDT
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 08:36:43 EDT
Can this be also implemented into the beaker command line client for example as bkr task-del ?
Comment 5 Raymond Mancy 2010-06-27 23:34:31 EDT
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 05:43:21 EST
Hi, any update on this? Is there some workaround I can use before this is
implemented? Thanks.
Comment 7 Raymond Mancy 2010-11-22 19:53:31 EST
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 02:05:03 EST
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.
Comment 9 Ales Zelinka 2011-03-07 06:11:16 EST
(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 04:21:07 EDT
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 10:05:57 EDT
code pushed to gerrit for review.
Comment 12 Bill Peck 2011-05-16 16:16:02 EDT
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
Comment 13 Ales Zelinka 2011-05-17 06:01:13 EDT
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
Comment 14 Bill Peck 2011-05-17 06:48:14 EDT
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 04:47:17 EDT
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'}
Comment 16 Dan Callaghan 2011-06-01 00:48:23 EDT
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.