The default bug view has changed. See this FAQ.

Add sheriffs to the vpn_releng_self_serve LDAP group so they can deploy trychooser

VERIFIED FIXED

Status

Release Engineering
Other
VERIFIED FIXED
3 years ago
11 months ago

People

(Reporter: emorley, Unassigned)

Tracking

({sheriffing-P3})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [kanban:https://kanbanize.com/ctrl_board/4/139] )

To avoid sheriffs having to bother releng (and so things like bug 1015063 don't get caught in limbo), it would be great if sheriffs were able to deploy trychooser - either manually or via a red button 'Chief' approach similar to that used by TBPL.

If it helps, there is an existing group for the sheriffs, 'vpn_sheriff'.
Over to relops, who manage the machine that does these deployments.
Assignee: nobody → relops
Component: Tools → RelOps
Product: Release Engineering → Infrastructure & Operations
QA Contact: hwine → arich
Version: unspecified → other
How do you folks typically push changes to things like tbpl?  We'll try to make it look the same.
We use the Chief tool.
OK -- I don't know how that works, but it's a webops cluster so it should be possible.

Over to you, fine folks of webops!
Assignee: relops → server-ops-webops
Component: RelOps → WebOps: Other
QA Contact: arich → nmaul
Whiteboard: [kanban:https://kanbanize.com/ctrl_board/4/139]
:relops,

Per convo with coop/laura today we want to give employee-sheriffs this access now, rather than wait for time for Chief to be implemented (though that is the ideal solution).

This access will be a bit broader than needed here, but is *ok* per same managers.

The easy ability to grant access was designed/created in Bug 1055727 with relops made owners of the LDAP group.

ACTION ITEM:
Please grant vpn_releng_self_serve to:
 * emorley@m.c
 * rvandermeulen@m.c
 * wkocher@m.c
 * dburns@m.c

===
For :sheriffs

Instructions for deployment are at https://wiki.mozilla.org/ReleaseEngineering/How_To/Update_the_Try_Syntax 

All updates to that are logged at https://changelog.paas.allizom.org/#criticality=&hours_ago=1&until=-1&category=&description= as well

(e.g. https://changelog.paas.allizom.org/#criticality=&hours_ago=1000&until=1409681465&category=&description=trychooser )
Assignee: server-ops-webops → relops
Component: WebOps: Other → RelOps
QA Contact: nmaul → arich
Can we add cbook@m.c to the sheriff list too please
(In reply to David Burns :automatedtester from comment #6)
> Can we add cbook@m.c to the sheriff list too please

a+=me, fwiw. (I mentally selected employee sheriffs, and he slipped my mind due to pure neglect on my part)
This was mistakenly moved to relops when it's still a webops service/controlled service.
Assignee: relops → server-ops-webops
Component: RelOps → WebOps: Other
QA Contact: arich → nmaul
(In reply to Amy Rich [:arich] [:arr] from comment #8)
> This was mistakenly moved to relops when it's still a webops
> service/controlled service.

No not mistakenly...

(In reply to Justin Wood (:Callek) from comment #5)
> The easy ability to grant access was designed/created in Bug 1055727 with
> relops made owners of the LDAP group.

So, based on that discussion relops owns adding/removing users from that LDAP group, which is how we will solve this bug. Please perform that work.
Assignee: server-ops-webops → relops
Component: WebOps: Other → RelOps
QA Contact: nmaul → arich
Summary: Give sheriffs access to deploy trychooser → Add sheriffs to the vpn_releng_self_serve LDAP group so they can deploy trychooser
That discussion apparently happened without relops. I've tracked back to the original bug and I've asked IT to give all releng access to modify that group, so you can self serve here.
Assignee: relops → nobody
Component: RelOps → Other
Product: Infrastructure & Operations → Release Engineering
QA Contact: arich → pmoore
All employed sheriffs should have access as soon as the ldap/puppet propagation happens.

please feel encouraged to chat with releng for the first few deploys you do yourselves.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
ssh and sudoers permissions confirmed working, thank you :-)
Status: RESOLVED → VERIFIED
QA Contact: pmoore → mshal
Blocks: 1266704
You need to log in before you can comment on or make changes to this bug.