Bug 1000861 - More conservative deprecation strategy for implicit job sharing
More conservative deprecation strategy for implicit job sharing
Status: CLOSED CURRENTRELEASE
Product: Beaker
Classification: Community
Component: scheduler (Show other bugs)
develop
Unspecified Unspecified
unspecified Severity unspecified (vote)
: 0.15
: ---
Assigned To: Raymond Mancy
tools-bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-25 21:46 EDT by Nick Coghlan
Modified: 2018-02-05 19:41 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-02 22:27:08 EDT
Type: Bug
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 Nick Coghlan 2013-08-25 21:46:07 EDT
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-25 21:52:19 EDT
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-28 22:55:40 EDT
http://gerrit.beaker-project.org/#/c/2186/
Comment 4 Raymond Mancy 2013-08-30 08:12:07 EDT
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 04:18:20 EDT
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-02 22:27:08 EDT
Beaker 0.15 has been released.
Comment 7 Raymond Mancy 2013-10-25 01:57:26 EDT
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 02:21:19 EDT
(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 02:27:05 EDT
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 00:48:31 EST
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.

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