Deployment tooling/Cabal/2016-09-19
< Deployment tooling | Cabal
2016-09-19
[edit]Next release/blocking
[edit]Goal early next week end of this week—ops has an offsite next week
Done Allow per-environment config-override- Local config deploys should use the target's current version
- TODO: Break out proposed solution to separate task
- TODO: Store DEPLOY_HEAD on target
- Scap config management: Jinja2 fills templates with Pythonic values
- Workaround available, but a nasty one
- May not make next release
- Should be high priority
Task prioritization
[edit]Factors to consider:
- Highest priority: data-loss/security issues/blocking extended use
- Incorrect functionality vs. Enhancement
- Workaround available vs. None
- Frequency of occurance (affects all scap users vs. affects some)
Tasks to prioritize
[edit]- Scap3 submodule space issues (all users, no workaround, enhancement)
- ORES uses 5 GB IIRC
- SCB shares space with lots of other services
- Stored with logs
- scap to reload a service instead of restart (all users, command workaround, enhancement)
- Scap3 config references to deployed directory (all users, no workaround, incorrect/non-obvious functionality)
- puppet should run deploy-init command once after cloning the deploy repo (already done, just need full path))
As Always
[edit]- Phase 2
- Phase 1
- Workboard https://phabricator.wikimedia.org/tag/scap3/
- Etherpad backed up to https://www.mediawiki.org/wiki/Deployment_tooling/Cabal
- Future document https://www.mediawiki.org/wiki/Deployment_tooling/Future
- Spreadsheet: https://docs.google.com/spreadsheets/d/1MlEsFxrLvdZdV_G82WEAIvBXr7ArO7nCEKaFClHhJEw/edit#gid=0