Upstream process_list.yaml.sample, which was likely a source for the charm version, has slightly different binaries paths. This patch provides correct systemd service names and binaries locations for the masakari-process-monitor service. Closes-Bug: #1941644 Change-Id: Ic209723fe7bfdf030310cf8a3e5607caf6a73853
|2 months ago|
|src||2 months ago|
|unit_tests||1 year ago|
|.gitignore||3 years ago|
|.gitreview||2 years ago|
|.stestr.conf||3 years ago|
|.zuul.yaml||2 years ago|
|LICENSE||3 years ago|
|README.md||1 year ago|
|__init__.py||3 years ago|
|osci.yaml||4 months ago|
|rebuild||5 months ago|
|requirements.txt||3 months ago|
|test-requirements.txt||3 months ago|
|tox.ini||3 months ago|
Masakari is used to provide automated recovery of KVM-based OpenStack machine instances for deployments that use shared storage (volumes).
The masakari-monitors charm deploys Monitors for Masakari whose purpose is to detect hypervisor and instances failures and to inform Masakari about them.
Evacuation of instances (supported since OpenStack Stein)
In the event of hypervisor failure, instances can be migrated to another hypervisor.
Restarting of instances (supported since OpenStack Ussuri)
A failed instance can be restarted.
Note: The restarting of services (e.g. nova-compute) is not supported by the charm as it is considered a
config.yaml for the full list of configuration options, along with
their descriptions and default values.
To deploy masakari-monitors:
juju deploy masakari-monitors
Because this is a subordinate charm a relation will need to be added to another application to have the charm deployed on a machine.
This section lists Juju actions supported by the charm.
Actions allow specific operations to be performed on a per-unit basis. To
display action descriptions run
juju actions masakari. If the charm is
not deployed then see file
Please report bugs on Launchpad.
For general charm questions refer to the OpenStack Charm Guide.