Juju Actions - Use Cases

[Stuart Bishop]

On 10 September 2014 11:23, Tim Penhey <tim.penhey at canonical.com> wrote:
> On 10/09/14 06:59, John Weldon wrote:
>> We're looking for use cases for Juju Actions, mostly to make sure we
>> expose the right API.
>>
>> I'm hoping for a few different use cases from the Juju Web UI folks, but
>> I'd appreciate input from anyone wanting to use Juju Actions in their
>> charms too.
>>
>> I've started a document with some example use cases to prime the pump:
>> please contribute to this document and don't feel constrained to the
>> style or layout I adopted for the examples.
>>
>>
>> If you have any interest or investment in using or publishing Actions
>> for Juju please review and contribute!
>>
>> Google Docs Link
>> <https://docs.google.com/document/d/1uYffkkGA1njQ1oego_h8BYBMrlGpmN_lwsnrOZFxE9Q/edit?usp=sharing>
>
> I'd love to see explicit backup/restore actions for the postgresql charm.

For the PostgreSQL charm, off the top of my head:

backup-start
    - May be a logical backup or filesystem level backup, so perhaps 2 actions
    - May take hours or days.
    - Scheduled in cron, in addition to on demand.
    - Should it return immediately, or emit status while the backup progresses?
    - Can backups be streamed back to the user? If not, the charm has
to support many storage options.

backup-cancel
    - Cancel a running backup
    - The charm might need to cancel a backup, eg. if failover has
been triggered.

backup-status
    - Status of running backups

backup-recover
    - Destroy the master database, rebuilding using the backup
    - May take hours or days, multi-terrabyte databases are not uncommon.
    - Can the backup be streamed from the user? If not, the charm has
to support many storage options.
    - If backup is filesystem level, optionally recover to a specific
point in time.
    - Does not require location of backup, as default would be the
automatic backups.
    - Only makes sense running on a unit in the master service if
using cascading replica services
    - Recovery does not have to happen on the master unit in the
master service. If recovery is done on a hot standby unit in the
master service, that hot standby will be promoted to master when it
completes.
    - Once recovery is complete, all hot standbys need to be rebuilt
from the master

failover
    - Promote a specific unit to be the master.

rebuild
    - Rebuild a hot standby unit from the master unit.
    - This may rarely need to be done by an end user, eg. if a unit
has desynchronized during an extended netsplit and the data required
to catch up is no longer available.
    - More likely, this action will be invoked by the backup-recover action
    - Most likely, this action will be invoked by the
peer-relation-joined and slave-relation-joined hooks, allowing the
rebuild to be done asynchronously rather than the current situation
where the hooks may take hours or days to complete.


For the pgbouncer charm, matching the main pgbouncer actions:

    stop
      - Stop the pgbouncer daemon.
      - Big hammer if the 'disable, kill, pause, resume, enable' dance
is not your style.

    start
      - Start the daemon.

    disable [db]
        - Disable new client connections to a given database

    kill [db]
        - Immediately drop all client and server connections on a
given database.

    enable [db]
        - Reenable a database after a 'disable'

    pause [db]
        - Disconnect from a database, first waiting for queries to complete.

    resume [db]
        - Resume after a previous 'pause'.


The storage and storage-subordinate charms could have some interesting
use cases, although these might end up being swallowed by juju-core
rather than become actions. At the moment the storage-subordinate
informs the charm when the requested filesystem mount is ready, and it
is the host charm's responsibility to shut down daemons, move
datafiles to the new mount, and restart. If there were standard
actions to stop and start the system, then the subordinate could do
everything and the only burden placed on the host charm is advertising
a patch that contains all of its data files. Perhaps these start/stop
actions already exist in the form of the start/stop hooks.

-- 
Stuart Bishop <stuart.bishop at canonical.com>