Bug 1000861

Summary:	More conservative deprecation strategy for implicit job sharing
Product:	[Retired] Beaker	Reporter:	Nick Coghlan <ncoghlan>
Component:	scheduler	Assignee:	Raymond Mancy <rmancy>
Status:	CLOSED CURRENTRELEASE	QA Contact:	tools-bugs <tools-bugs>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	develop	CC:	aigao, asaha, dcallagh, ebaak, jingwang, llim, qwan, rmancy, xjia
Target Milestone:	0.15
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-10-03 02:27:08 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:

Description Nick Coghlan 2013-08-26 01:46:07 UTC

The implementation of bug 970501 completely removed the old implicit job sharing model from Beaker 0.15.

While explicit job sharing has been available since Beaker 0.13 (and implicit job sharing deprecated in the documentation), I'm concerned that there's been no *programmatic* indication to users that they're relying on a deprecated feature.

Since we don't provide the job activity logs needed for installation admins to tell if anyone is still relying on this behaviour (see bug 995012), that means I believe we need to be more conservative with how we remove it.

Specifically, I believe we need to add the feature back for 0.15, but behind a configuration flag that turns it on. The "_can_administer_old" method would check the flag and always return False if the feature was disabled.

That way, new installations will have it turned off by default, but existing installations will easily be able to turn it back on if the removal of the feature causes problems for their users.

Comment 1 Nick Coghlan 2013-08-26 01:52:19 UTC

Actually, lets be even more conservative:

- on by default in 0.15, but can be switched off
- off by default in 0.16, but can be switched back on
- removed entirely in 0.17

Comment 2 Raymond Mancy 2013-08-29 02:55:40 UTC

http://gerrit.beaker-project.org/#/c/2186/

Comment 4 Raymond Mancy 2013-08-30 12:12:07 UTC

Steps to verify:

- Create two users (e.g user1, user2), put them in the same group. Make sure these users do not have admin privileges.
- Login as user1, submit JobA (not a group job!)
- Login as user2. 
- You should be able to 'administer' the job (i.e ack/nak, delete, cancel etc)

Now add the following to the config file

  beaker.deprecated_job_group_permissions.on = False

- Restart apache
- user2 should not be able to 'administer' JobA

Comment 5 xjia 2013-09-02 08:18:20 UTC

Verify:
Create group "BZ1000861“ , add shajiang and tfeng in this group.
By default: beaker.deprecated_job_group_permissions.on = True
J:1276 tfeng create this job, and cancel this job. shajiang can be able to update the whiteboard and nack/ack , and 

Set beaker.deprecated_job_group_permissions.on = False, and restart http service.

J:1277 tfeng create this job, and cancle it. shajiang can't update the whiteboard, and nack/ack and delete.


So verify this bug.

Comment 6 Nick Coghlan 2013-10-03 02:27:08 UTC

Beaker 0.15 has been released.

Comment 7 Raymond Mancy 2013-10-25 05:57:26 UTC

Apologies, just to clarify, the 'administer' actions are limited to changing:

-priority
-whiteboard
-product
-retention tag
-deleting
-ack/nak

Comment 8 wangjing 2013-10-25 06:21:19 UTC

(In reply to Raymond Mancy from comment #7)
> Apologies, just to clarify, the 'administer' actions are limited to changing:
> 
> -priority
> -whiteboard
> -product
> -retention tag
> -deleting
> -ack/nak

why only not apply to permission 'cancel' even administer User2 can delete the job. I think  both  cancel and delete should be included in administer permissions which should be a suite of administer functions.
then it feels much more clearly, right?

Comment 9 Nick Coghlan 2013-10-25 06:27:05 UTC

The legacy permissions *didn't* really make sense when considered as a whole (they'd just accumulated over the years in response to specific feature requests).

The right way to share job access now is to submit a group job instead, which *does* grant full access to other group members (including the ability to cancel the job, as well as adding all group member's ssh keys to the provisioned systems).

Comment 10 Dan Callaghan 2015-11-11 05:48:31 UTC

I just noticed we never followed through with this. I filed bug 1280178 for flipping the default to off, so that we can eventually remove it entirely.