Dependency order to follow
1. [x] gateway (routing)
1. [x] swh-storage (db, swh-storage service)
1. [x] swh-objstorage (disks, swh-objstorage service)
2. [x] swh-web
3. [x] swh-scheduler (db, rabbitmq, swh-scheduler services)
4. [x] swh-deposit (db)
5. [x] 1 worker with at least 1 loader (worker0 & worker1 with loader-git)
7. [x] swh-vault
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` [2] 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
- [ ] rabbitmq: improve the configuration option to be in sync with our current instance (P493)
Test:
- [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.
[2] the current staging branch is new_staging but meh, that will be `staging` in the end ;)