This is probably related to T172333 where keyholder_key: deploy_service is added.

All subtasks closed. Closing this one out.

In T129148#3616198, @Krinkle wrote:

I've updated https://wikitech.wikimedia.org/wiki/Jobrunner#Deployment. Please review https://wikitech.wikimedia.org/w/index.php?title=Jobrunner&type=revision&diff=1770333&oldid=1766155.

Closing this task as invalid for now as tests for mathoid container are defined within the mathoid test entry point as built by blubber and not in scope for releng to define.

In T175293#3599497, @hashar wrote:

Potentially the required upstream package could be added to a new component (eg: docker17) or one has to figure out how to upgrade Docker on other pieces of the infra relying on it.

In T129142#3610052, @MoritzMuehlenhoff wrote:

Is the plan to still move ocg to scap3 despite it's remaining two weeks of lifetime or is it acceptable to dismantle the deployment basis of ocg starting the week of the 25th?

Able to build, new inline lintian nitpicks.

Deployed! Thanks @Gehel !

In T129149#3605208, @ksmith wrote:

This was mentioned in Scrum-of-scrums. Who would actually do the work to get it migrated?

Deployed!

deployed!

space around version number to make tox happy

Added 2 new memcached instances: deployment-memc06 and deployment-memc07 (already had a memc5). Both running memcached ran into T153468 but apart from that role::memcached seems to be all they needed.

Remove commented out code, remove else block in docker compile

Use fmt.Errorf vs errors.New(fmt.Sprintf, document ExpandVariant

I like moving the artifacts to using InstructionsForPhase. I have Weird Feelings™ about the defaultArtifacts method. Comments inline.

In T129134#3585936, @Niharika wrote:

Sure thing. To confirm - this part still follows the old deployment steps, doesn't it? Here are the notes I have from the couple of times I did this with @bd808:

Deployment steps (on tin):
cd /srv/deployment/scholarships/scholarships
git fetch // Fetches the latest things from master
git log --stat HEAD..@{upstream} // Magic that lets you see the new stuff

In T129134#3560849, @thcipriani wrote:

Code reviewed the patches that are outstanding for scholarships. One thing I noticed in my review is that krypton may not be accessible from tin via ssh(?):

[thcipriani@tin ~]$ nc -vz krypton.eqiad.wmnet -w 1 22                               
krypton.eqiad.wmnet [10.64.32.182] 22 (ssh) : Connection timed out

In which case we'd have to add some ferm rules in the puppet patch (https://gerrit.wikimedia.org/r/#/c/326461/5) to allow access from the deployment hosts.

Since D766: Add scap3 deployment support landed I think this should be good to deploy whenever the puppet patches merged.

The fix for this went out with scap 3.7.0-1 on Monday.

Now that scap 3.7.0-1 is live, this should be fixed. To use a specific keyholder key, use the keyholder_key configuration value with the value that is the same as key_name for scap::target in puppet. e.g., for gerrit:

Now that scap 3.7.0-1 is live, the configuration variable require_valid_service should ensure that scap does not attempt to restart a service when systemctl show --property LoadState [service] comes back either not-found or masked.

The core issue here is that scap locking failed and allowed two sync* processes to happen at the same time. This caused some weird behavior as there are some race conditions within the deployment since it is not meant to run concurrently with itself.

I think the problem was caused by (from SAL):

So there a few items in the output that are red herrings:

Hrm, so it's failing at:

Looks good from the scap side. IEGReview code matches what was done with scholarships, lgtm although I have no experience with the application.

in favor of D765: Recursive variant expansion

Hi @fgiunchedi just tagged debian/3.7.0-1 on scap's release branch. Could you update scap on carbon please? Puppet patch on the way!

In T173999#3569473, @hashar wrote:

Volans pinged me about it and I went with a basic implementation based on Tyler comment above.

For clarification, can this task be removed as a blocker for sunsetting salt?

Calling this one done, blubber has an example yaml format that can generate Dockerfiles: https://phabricator.wikimedia.org/source/blubber/browse/master/blubber.example.yaml

Now that we have locked down the security for Jenkins a bit, contint1001 seems like a logical place to store credentials and run builds. We've discussed this a bit in the deployment pipeline meetings.

In T167104#3566055, @gerritbot wrote:

Change 374822 merged by Alexandros Kosiaris:

wfm

I remember talking about the necessity for this directory.

Code reviewed the patches that are outstanding for scholarships. One thing I noticed in my review is that krypton may not be accessible from tin via ssh(?):

minor nit + the golint errors, but overall lgtm!

In T170032#3541765, @Jdforrester-WMF wrote:

Would it be more natural to "just" switch everything over to Stretch?

@fgiunchedi gave me feedback on my previous plan that led to the creation of D743.

It looks like this commit added mw as an undefined reference to that script: https://gerrit.wikimedia.org/r/#/c/372496/

instead of continuing the pattern inside the parameter_functions.py file of hard-coding repository names, i.e.:

You can inject environmental variables in a job inside the set_parameters function inside parameter_functions in the integration/config repo.

Added as blocking task to wmf.16 so that it doesn't slip off the radar.

Re-cherry picked the change to the wmf.14 branch to wmf.15.

The assertion has been active for these jobs for 2 weeks:

In T170839#3545140, @fgiunchedi wrote:

We can nuke the repo, it was deprecated in T104208: alternative Cassandra metrics reporting and https://gerrit.wikimedia.org/r/#/c/223041/