Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1104491

Summary:	Document beaker-log-delete
Product:	[Retired] Beaker	Reporter:	Dan Callaghan <dcallagh>
Component:	general	Assignee:	beaker-dev-list
Status:	CLOSED NOTABUG	QA Contact:	tools-bugs <tools-bugs>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	0.16	CC:	tklohna
Target Milestone:	---	Keywords:	Documentation, EasyFix, Triaged
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-04-15 12:28:36 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	968828
Bug Blocks:

Description Dan Callaghan 2014-06-04 07:00:03 UTC

Description of problem:
When using Kerberos authentication, beaker-log-delete prints a line like

   Kerberos initialization for HTTP/hostname@REALM

This is a problem because we expect the admin to call this command in a cron job, and cron jobs should be silent unless something goes wrong. beaker-log-delete should therefore be silent by default, unless something goes wrong.

It could potentially have a --debug or --verbose option like some of the server commands, if that is desired.

Version-Release number of selected component (if applicable):
0.16.2

How reproducible:
always

Steps to Reproduce:
1. Configure beaker-log-delete to use Kerberos authentication for talking to the archive server
2. Run beaker-log-delete

Actual results:
Prints output.

Expected results:
Silent unless failure.

Additional info:
I think the output comes from requests-kerberos.

Comment 2 Dan Callaghan 2014-06-04 07:08:16 UTC

I would like us to fix this ASAP since it is currently making it difficult to find failures in log-delete (which we are also experiencing, it seems).

Comment 3 Dan Callaghan 2014-06-04 07:19:16 UTC

Actually I just realised this output is probably from k5start. Need to figure out:

* do we document the use of k5start anywhere? if not, it should be
* can we pass k5start an option to suppress the message? if not, need to do something like redirect stdout to /dev/null... either way add it to the docs

Comment 5 Dan Callaghan 2014-06-04 07:26:06 UTC

It's -q.