Wikimedia Release Engineering Team/SSD Sync Up/2019-02-12

2019-02-12

Last Time: 2019-02-05

•  Done TODO: Create task about base policy file https://phabricator.wikimedia.org/T215319
•  Done 'TODO: Task for per-repo jobs https://phabricator.wikimedia.org/T215320

Discussion

• We have a place to put meeting notes: https://www.mediawiki.org/wiki/Wikimedia_Release_Engineering_Team/SSD_Sync_Up
  • I archived this etherpad there

• thcipriani: Pipeline feedback https://phabricator.wikimedia.org/T177868
  • Badges demo https://jsfiddle.net/nraxzg46/4
  • IRL implementation: http://gerrit.tylercipriani.com:8080/c/sshecret/+/22/#message-e9b75674f0401ce5c64afe241f55d1a2410f583a
  • Patches forthcoming:
    • Update commentlink
    • Update gerrit css
    • Groovy in pipeline/libpipeline for commenting on Jenkins
    • Bot created for commenting https://wikitech.wikimedia.org/wiki/User:PipelineBot

• Dan libpipeline
  • Review comments on https://gerrit.wikimedia.org/r/c/integration/pipelinelib/+/480689
  • Experimenting with Jenkinsfile for testing pipelinelib https://gerrit.wikimedia.org/r/c/integration/pipelinelib/+/489760/6
    • Dan: Seems to work, only question is is it safe enough to run? We could add it to a whitelisted pipeline as well as having a jenkins sandbox
    • Thcipriani: how does the sandbox work?
    • Dan: made a couple of jobs, one is a trigger job 
    • random rumbling about triggers
    • Dan: made a job with the "sandbox: true" flag to make this work
    • thcipriani: TODO review

• Once we start using the continuous deployment pipeline for real, should we start reaching out to the developer community, perhaps training them for CDep?
  • James: I think having a plan for communicating this work is a good idea -- an email saying "hey this is happening" would be a good thing. We'll need to have answers for inevitable questions that devs will post (e.g., how do you do X? what is the plan for Y?)
  • James volunteers!!!
  • LIW: pictures with videos and pictures -- this will help although it may be unusual for Wikimedia
  • Mmodell: +1
  • Tyler: Documentation update task at https://phabricator.wikimedia.org/T213090 overall and https://phabricator.wikimedia.org/T213198 for Blubber; we should put stuff on wikitech, no particular opinion on ways.
  • liw: +1 to wikitech. Format less important than content. Content should be task oriented, i.e., I have a Service™ -- what do I do? This is something that should be refined and kept up-to-date.
  • Dan: might be good to have a higher-level introduction, i.e., what is the pipeline and what can it do for me?
  • James_F: first question to answer: why are we moving to images at all? We're currently a CI team and we're moving to CD{ep,delivery}
  • Dan: and then move into task-based stuff
  • James_F: Let's do it as a wikipage with TODOs of what to write: https://wikitech.wikimedia.org/w/index.php?title=Release_pipeline or whatever?
  • TODO liw to create wikipage with questions cf: https://phabricator.wikimedia.org/T213090

• Tyler: Updates from Jeena about developer tooling, filesystem mounts?
  • Jeena: Trying to get sshfs running in a container (inside minikube) but having issues, possibly kernel-related.
  • Maybe could run just inside the minikube VM itself? Would need a script to ssh into the VM to get that running, might be a better idea.
  • Mukunda: Tried it on Debian laptop, apt installing the project and the mount – worked seamlessly. Probably mis-match between kernel and container was causing problems?
  • Tyler: Saw an issue in the minikube project to "remove the mount sub-command" because everyone has issues with the plan9(?) fileserver; maintainer said they weren't going to remove, but wanted to replace with better technology. 
  • Brennen, Mukunda: Let's not use NFS?
  • Dan: sshfs in the minikube iso or?
  • Mukunda: sshfs in container, connect to sshd on the host
  • Dan: I'm a little worried about an ssh key
  • liw: ssh server has nice features like chroots
  • mmodell: it only needs sftp-server
  • mmodell: there are bugs with sshfs -- permissions -- there are weird race-conditions where it violates POSIX-expectations, but for our purposes should work perfectly