Page MenuHomePhabricator

Scap should abort early when Keyholder is not armed
Open, MediumPublic

Description

Scap should abort/error out (with a clear message of issue) when the Keyholder system is not armed. That will make it more obvious than the "permission denied" lines embedded in some long output (especially in the beta-scap-eqiad CI job).

Can be as simple as running keyholder status according to https://wikitech.wikimedia.org/wiki/Keyholder though it always exit 0. We could use check_keyholder which uses for monitoring and does exit non Zero in case of trouble.

note: Beta Cluster monitoring task is T111064: Monitor keyholder on deployment-prep deployment servers

Event Timeline

hashar assigned this task to bd808.
hashar removed bd808 as the assignee of this task.
hashar raised the priority of this task from to Medium.
hashar updated the task description. (Show Details)
hashar added subscribers: JanZerebecki, hashar, gerritbot and 5 others.

See also T110794 for production, and also T110791 T110793 for related error messes

hashar set Security to None.

That is a good idea, also for production, so perhaps scap should do that?

That is a good idea, also for production, so perhaps scap should do that?

I agree, and related to what @Reedy linked (namely T110791).

greg renamed this task from Jenkins job beta-scap-eqiad should abort early when Keyholder is not armed to Scap should abort early when Keyholder is not armed.Sep 1 2015, 8:59 PM
Aklapper added a subscriber: thcipriani.

@thcipriani: A good first task is a self-contained, non-controversial task with a clear approach and links to documentation and the codebase (see the project description). Given the current task description I'm removing the good first task tag.