1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
|
- Fix "run" function in hooks.py to log error rather than exiting silently
(exceptions emitted at INFO level)
- Pick a better way to get machine specs than hacky bash functions - facter?
- Specify usernames when adding a relation, rather than generating them
automagically. This will interact better with connection poolers.
- If we have three services deployed, related via master/slave, then the
repmgr command line tools only work on the service containing the master
unit, as the slave-only services have neither ssh nor postgresql access
to each other. This may only be a problem with master/slave relationships
between services and failover, and it is unclear how that would work
anyway (get failover working fist for units within a service).
- Drop config_change_command from config.yaml, or make it work.
"restart" should be the default, as there may be required config changes
to get replication working. "reload" would mean blocking a hook requesting
config changes requireing a restart, emitting warnings so the admin can
do the restart manually. Is this good juju? An admin can already control
when restarts happen by when they change the juju configuration, and can
avoid unnecessary restarts when adding replicas by ensuring required
configuration changes are made before hand.
- No hook is invoked when removing a unit, leaving the host standby PostgreSQL
cluster running and attempting to replicate from a master that is refusing
its connections. Bug #872264.
|