IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Add the zsh command completion generation for the ha-manager CLI tools.
This adds the automatic generation of the autocompletion scripts for zsh
Signed-off-by: Christian Ebner <c.ebner@proxmox.com>
in this package we provide api functions, thus we want to activate
the pve-api-update trigger, so that packages like pve-manager get
notified about it. But we also use api functions directly so we setup
an interest in the pve-api-update trigger. This results in an lintian
error (lintian version from buster or newer) which we can override:
> [...]
> This tag is also triggered if the package has an activate trigger
> for something on which it also declares an interest. The only (but
> rather unlikely) reason to do this is if another package also
> declares an interest and this package needs to activate that other
> package. If the package is using it for this exact purpose, then
> please use a Lintian override to state this.
-- https://lintian.debian.org/tags/repeated-trigger-name.html
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
use dpkg-buildpackage and debhelper properly, add missing dependencies and
embed used perl modules from libpve-common-perl to make pve-ha-simulator
standalone.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
This was introduced for cleaning up an possible left over systemd
watchdog mux enable link, which is gone for good now.
Then it was extended with trigger targets, as the HA Manager services
now restart when the pve-api-update trigger fires.
As the autogenerated postinst does the same unconditionally for the
pve-ha-lrm.service and pve-ha-crm.service already we may remove it
too.
The only difference is that try-restart is used by the auto generated
script, not reload-or-try-restart, but this does not matter, as the
HA services have currently no reload ability.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This was copied by accident when adding the transitional code for
removing the left over of the systemd managed watchdog mux in
commit f8a3fc80af
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This transitional code was added first with
commit f8a3fc80af
and fixed up with
commit ecc145c972
during Proxmox VE 4.1 and 4.2 to remove the problematic systemd
managed watchdog mux socket.
As each system going for an distribution upgrade must first upgrade
to 4.4, where this gets handled, we can remove it now.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
as it's a static unit dh_systemd_starting it is not possible - but it gets
pulled in and started by pve-ha-crm/pve-ha-lrm anyway.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Reviewed-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
otherwise it gets confused and enables pve-ha-crm twice in the postinst.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Reviewed-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
To ensure that the LRM and CRM services get reloaded when
pve-api-update trigger gets activated.
Important, as we directly use perl API modules from qemu-server,
pve-container, pve-common and really want to avoid to run outdated,
possible problematic or deprecated, code.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
we must shut all services down when stopping the LRM for a host
shutdown, this can take longer than 95 seconds and should not
get interrupted to ensure a gracefull poweroff.
The watchdog is still active untill all services got stopped so we
still are safe from a freeze or equivalent failure.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
It is important that all storages stop after pve-ha-lrm.
If the storages stop too early the vm loses disks and can not shutdown.
This can end in fencing the node.
watchdog-mux.socket was removed in f8a3fc80af but the
postinstall script used -e instead of -L to test for the
symlink, which fails since the destination is already
removed at that point.
Use -L and remove the dead symlink if it exists.
Reported-by: Alexandre Derumier <aderumier@odiso.com>
The use of an systemd socket unit for the watchdog socket is not
necessary for us it even generates problems as the socket already
runs and accepts input when the watchdog-mux daemon itself is not
running. So the LRM/CRM could successfully open and update the
watchdog even if it was not running!
This patch removes the unit file, adds a postinst script which
handles the removal of the links generated from systemd itself
and removes also the code from watchdog-mux which handled
the systemd socket unit.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>