Dependency order to follow
- [x] gateway (routing)
- [x] swh-storage (db, swh-storage service)
- [x] swh-objstorage (disks, swh-objstorage service)
- [x] swh-indexer storage (db, service)
- [x] swh-web
- [x] swh-scheduler (db, rabbitmq, swh-scheduler services)
- [x] swh-deposit (db, service)
- [x] 1 worker with at least 1 loader (worker0 & worker1 with loader-git)
- [x] swh-vault
- [x] update workers with checker/loader deposit
- [ ] update workers with 1 lister
- [ ] update workers with 1 indexer
- [ ] Make icinga checks green on the expected origins (parmap, cpython, etc...)
Note:
- Should be a matter of creating the right branch ('staging' for example) in swh-site's repository
- calling the right environment when `puppet agent --test --noop --environment='staging'
- production code should only be modified if there are issues identified (there was ;)
- in the end the `staging` branch should be merged into production (without any impact on production, that's somehow has been my implicit plan)
Plan:
From provisioning node (creation in our hypervisor) to delegating puppet for the configuration/installation services
For some of our services, this is ambitious:
- [x] postgres: puppetized the db creation and user done
- [ ] ~~postgres: bootstrap db schema (-> this one needs work upfront in our different services to have a common use interface)~~ [1]
- [x] rabbitmq: server installation with users setup
- [x] rabbitmq: improve the configuration option to be in sync with our current instance (P493)
Tests:
- [x] from webapp: save code now -> browsing ok
- [ ] push a deposit via deposit client cli -> browsing in webapp ok
- [x] from webapp: request vault cooking -> download in webapp ok
[1] I consider this out of scope (i need to draw a line somewhere ;)
Also we as a team started this, that needs to be finalized IIRC.