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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
else this can break an upgrade for unrelated reasons.
this also mimics debhelper behaviour more (which we only not use here because
of lack of reload support) - restructured the snippet to be more similar with
an explicit `if` as well.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Part of what caused bug #4984. Make the code future-proof and warn
when the node was never registered in the plugin, similar to what the
'static' usage plugin already does.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
[ TL: rework commit message subject ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Otherwise, when using the 'basic' plugin, this would lead to
auto-vilification of the $target node in the Perl hash tracking the
usage and it would wrongly be considered online when selecting the
recovery node.
The 'static' plugin was not affected, because it would check and warn
before adding usage to a node that was not registered with add_node()
first. Doing the same in the 'basic' plugin will be done by another
patch.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
[ TL: shorten commit message subject ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
... instead of using sendmail directly.
If the new 'notify.target-fencing' parameter from datacenter config
is set, we use it as a target for notifications. If it is not set,
we send the notification to the default target (mail-to-root).
There is also a new 'notify.fencing' paramter which controls if
notifications should be sent at all. If it is not set, we
default to the old behavior, which is to send.
Also add dependency to the `libpve-notify-perl` package to d/control.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
Currently, the maintenance node for a service is only cleared when the
service is started on another node. In the edge case of a simultaneous
cluster shutdown however, it might be that the service never was
started anywhere else after the maintenance node was recorded, because
the other nodes were already in the process of being shut down too.
If a user ends up in this edge case, it would be rather surprising
that the service would be automatically migrated back to the
"maintenance node" which actually is not in maintenance mode anymore
after a migration away from it.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
In the test log, it can be seen that the service will unexpectedly be
migrated back. This is caused by the service's maintainance node
property being set by the initial shutdown, but never cleared, because
that currently happens only when the service is started on a different
node. The next commit will address the issue.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Instead, use the new get_derived_property() method to get the same
information in a way that is robust regarding changes in the
configuration structure.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
The fact that no 'items' was specified made the api-viewer throw a
JavaScript exception: retinf.items is undefined
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
As reported in the community forum[0], currently, a newly added
service that's already running is shut down, offline migrated and
started again if rebalance selects a new node for it. This is
unexpected.
An improvement would be online migrating the service, but rebalance
is only supposed to happen for a stopped->start transition[1], so the
service should not being migrated at all.
The cleanest solution would be for the CRM to use the state 'started'
instead of 'request_start' for newly added services that are already
running, i.e. restore the behavior from before commit c2f2b9c
("manager: set new request_start state for services freshly added to
HA") for such services. But currently, there is no mechanism for the
CRM to check if the service is already running, because it could be on
a different node. For now, avoiding the migration has to be handled in
the LRM instead. If the CRM ever has access to the necessary
information in the future, to solution mentioned above can be
re-considered.
Note that the CRM log message relies on the fact that the LRM only
returns the IGNORED status in this case, but it's more user-friendly
than using a generic message like "migration ignored (check LRM
log)".
[0]: https://forum.proxmox.com/threads/125597/
[1]: https://pve.proxmox.com/pve-docs/chapter-ha-manager.html#_crs_scheduling_points
Suggested-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
[ T: split out adding the test to a previous commit so that one can
see in git what the original bad behavior was and how it's now ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Split out from Fiona's original series, to better show what actually
changes with her fix.
Currently, a newly added service that's already running is shut down,
offline migrated and started again if rebalance selects a new node
for it. This is unexpected and should be fixed, encode that behavior
as a test now, showing still the undesired behavior, and fix it in
the next commit
Originally-by: Fiona Ebner <f.ebner@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Will be used to ignore rebalance-on-start when an already running
service is newly added to HA.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Will be used in a test for balance on start, where it should make a
difference if the service is running or not.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The DEB_HOST_ARCH is the one the package is actually built for, the
DEB_BUILD_ARCH is the one of the build host; having this correct
makes cross-building easier, but otherwise it makes no difference.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
We did not handle being in maintenance mode explicitly with shutdown
policies, which is in practice not often an issue as most that use
the maintenance mode also switched over the shutdown policy to
'migrate', which keeps the maintenance mode, but for all those
evaluating HA or only using the manual maintenance mode it meant that
on shutdown the mode was set to 'restart' or 'shutdown', which made
the active manager think that the node got out of the maintenance
state again, and marked it as online – but as it wasn't really online
(and on the way to shutdown), this not only cleared the maintenance
mode by mistake, it also had a chance to cause fencing - if any
service was still on the node – i.e., maintenance mode wasn't reached
yet, but still in-progress of moving HA services (guests).
Fix that by checking if maintenance mode is requested, or already
active (we currently don't differ those two explicitly, but could be
determined from active service count if required), and avoid changing
the mode in the shutdown and restart case. Log that also explicitly
so admins can understand what happened and why.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Encode what happens if a node is in maintenance and gets shutdown
with a shutdown policy other than 'migrate' (= maintenance mode)
active.
Currently it's causing disabling the maintenance mode and also might
make a fence even possible (if not all service got moved already).
This will be addressed in the next commit.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
We do not just take the full CRM status of the old master if a new
one gets active, we only take over the most relevant parts like node
state. But the relative new node_request object entry is also
important, as without that a maintenance state request may get lost
if a new CRM becomes the active master.
Simply copy it over on initial manager construction, if it exists.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
this encode the current bad behavior of the maintenance mode getting
lost on active CRM switch, due to the request node state not being
transferred. Will be fixed in the next commit.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
the change as of now is a no-op, as we only ever switched to
maintenance mode on shutdown-request, and there we exited immediately
if no active service and worker where around anyway.
So this is mostly preparing for a manual maintenance mode without any
pending shutdown.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
useful for re-balanacing on start, where we do not want to exclude
the current node like setting the $try_next param does, but also
don't want to favor it like not setting the $try_next param does.
We might want to transform both, `try_next` and `best_scored` into a
single `mode` parameter to reduce complexity and make it more
explicit what we want here.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
We always check for re-starting a service if its in the started
state, but for those that go from a (request_)stop to the stopped
state it can be useful to explicitly have a separate transition.
The newly introduced `request_start` state can also be used for CRS
to opt-into starting a service up on a load-wise better suited node
in the future.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
