Consolidate HA manage mode and observe mode logic#98
Merged
Conversation
bertschinger
force-pushed
the
consolidate_ha
branch
5 times, most recently
from
4ac533d to
13096d3
Compare
Because the home node and failover node are always the same for every resource in a resource group, the data model is clearer and more consistent if those fields live on struct ResourceGroup instead of struct Resource.
bertschinger
force-pushed
the
consolidate_ha
branch
9 times, most recently
from
8fa77db to
2ad5a22
Compare
When a resource transitions from unmanaged to managed, the manager should clear any prior knowledge it had about the resource and rediscover its state "from scratch." This is because while the resource was still unmanaged, the admin could have manually moved it between the last time the manager checked on it, and setting the managed flag. If the manager acted on now out-of-date information, it could lead to an illegal situation like starting the resource on multiple nodes.
When a network error occurs while managing a resource group, the network error might occur partway through traversing the resource group tree. In that case, some of the resources might keep a "Running" status while others transition to "Unknown". Since a network error effectively means the entire resource group status is unknown, this makes the resource statuses more accurately reflect the condition.
These routines are very similar, with slightly different behavior depending on whether the resource is managed or unmanaged. Simplify the code by consolidating these into one routine, which always does the right thing based on the resource's management status as well as knowledge of whether the resource is known to be stopped on the partner node.
The startup logic was handled with a special case, but it actually requires the same logic as other cases that occur during runtime. For example, if a resource was unmanaged but becomes managed, the manager cannot make any assumptions about where it might be running so it basically has to do the same logic as it does at startup. This removes the startup logic in favor of just using the same code paths used to discover resource state during runtime.
Observe mode now uses the same code as manage mode, because manage mode has to support observe-only behavior anyways for unmanaged resources.
When a host is deactivated, the manager tries to move any resources running on it over to the partner. But if some of the resources are unmanaged, it is illegal for HALO to move them. This enforces the policy that unmanaged status dominates deactivated status, so HALO will not move an unmanaged resource even if the Host that currently hosts it is deactivated.
bertschinger
force-pushed
the
consolidate_ha
branch
from
2ad5a22 to
ba1432e
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
To simplify the codebase and make it more resilient, and facilitate future changes, this will consolidate manage mode and observe mode logic into the same module.
This is important because a resource can be unmanaged (== observe mode for that resource) even while the cluster is in managed mode. If the code has separate implementations for resource-specific unmanaged mode vs. cluster wide managed mode, it introduces opportunities for those two logics to diverge and produce bugs.