The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
Where should we go
Issues we have now
We currently don't have a "mediawiki version"
<user> We are taking over mediawiki-config deployment for the s3 failover, please talk to us before deploying anything
Related Phab tasks
Scap
Sources distributed to appservers
mediawiki-config
various subdirectories named php-1.XX.YY-wmf.Z
PrivateSettings.php which is managed by puppet
possibly security patches
symlinks like php => php-1.XX.YY-wmf.Z
Concerns
some things need to be deployed to 100% fast (eg depooling db servers), where scap file is useful
what if we keep a version tag/number/whatever for each repo
keep a "scap run" number on each server
we don't need a percentage of traffic for sync-file/sync-dir only for full scap sync
sync-file is still needed, e.g., a memcached server goes down during train and we do a percentage based rollout (which takes some time) we'll need to run a sync file during the train
we may be able to get atomic rollouts for free with php7
keep individual versions of each repo, i.e., scap can figure out changes
canary deploys for train, i.e., scap train command
a mediawiki deploy directory vs a mediawiki config directory, so what's deployed is the individual states of multiple deployed repositories
we could progressively rollout wikimediaversions with a new scap subcommand for train deploys
could use canaries during the train keeping Tues-Thursday the same wrt to the train except using a progressive rollout
Scope of focusing on sync-wikiversions would be train-only
we should combine this with restructuring of repos
If we are able to have something that indicates which version is deployed/running, a server could check every X minutes if it is running the proper version, and if yes, do a scap pull
Decoupling
operational state - this eventually moves to a local proxy
