Support redundancy.
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
reviewboard (Juju Charms Collection) |
Triaged
|
Wishlist
|
Unassigned |
Bug Description
Code review is a pretty significant part of the development workflow for projects using reviewboard. So I'm sure anyone using the charm would greatly appreciate support for redundancy.
Redundancy here relates to 2 scenarios:
* The related DB service becomes unrecoverably unavailable.
- So an existing service should be able to handle switching to a new postgresql service (i.e. host).
- It would be nice to have the RB charm support auto-detecting this and switching to a failover DB (also part of a relation), but that would be a lot to ask. :)
* The reviewboard service becomes unrecoverably unavailable.
- You should be able to add-relation with a postgresql service that has an existing ReviewBoard DB on it.
- This would also be helpful in the bootstrap-
For the latter case, part of the challenge is that rb-site does not appear to support using an existing DB. I found this out by trying to add-relation with a postgres service that already has the ReviewBoard DB. Basically, the rb-site call in install_rb_site() (via config-changed) can't handle it. Perhaps it's just a matter of calling rb-site with a dummy DB and then updating the DB host to the actual one.
If you can already achieve all this already then that's great. I'm pretty new to juju so I miss stuff all the time still. :) In that case I'd just recommend adding a "howto: redundancy" to the reviewboard page in the charm store.
That said, I'm pretty sure it's not supported. "juju add-unit reviewboard" doesn't work. I expect similar results for "juju add-relation postgresql:db reviewboard" when the postgresql service has multiple units.
FYI, I'm planning on tackling redundancy manually for now. Something like this:
1. add a postgresql unit (for the failover DB);
2. set up a second reviewboard service related to the failover DB;
3. set up replication from the primary DB to the failover one;
4. in the event the primary goes down, update DNS/reverse-proxy to point to the failover RB instance.