On 11 August 2014 18:20, William Reade <william.re...@canonical.com> wrote:
> I'd like to explore your use cases a bit more to see if we can find a clean > solution to your problems that doesn't go too far down the (2) road that I'm > nervous about. (The try-again-later mechanism is much smaller and cleaner > and I think we can accommodate that one pretty easily, fwiw -- but what are > the other problems you want to solve?) Memory related settings in PostgreSQL will only take effect when the database is bounced. I need to avoid bouncing the primary database: 1) when backups are in progress. 2) when a hot standby unit is being rebuilt from the primary. Being able to have a hook abort and be retried later would let me avoid blocking. A locking service would be useful too for units to signal certain operations (with locks automatically released when the hooks that took them exit). The in-progress update to the Cassandra charm has convoluted logic in its peer relation hooks to do rolling restarts of all the nodes, and I imagine MongoDB, Swift and many others have the same issue to solve. -- Stuart Bishop <stuart.bis...@canonical.com> -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
