Stein Series Release Notes¶
This release alters the cluster_scale_in and cluster_scale_out actions to no longer place the action into the actions table when a conflict is detected. This behavior is an improvement on the old way actions are processed as the requester will now receive immediate feedback from the API when an action cannot be processed. This release also honors the scaling action cooldown in the same manner by erring via the API when a scaling action cannot be processed due to cooldown.
This release alters the behavior of cluster and node APIs which create, update or delete either resource. In the previous release those API calls would be accepted even if the target resource was already locked by another action. The old implementation would wait until the other action released the lock and then continue to execute the desired action. With the new implementation any API calls for cluster or node that modify said resource will be rejected with 409 conflict.
Health policy v1.1 implements multiple detection modes. This implementation is incompatible with health policy v1.0.
Added new tool
senlin-status upgrade check.
action_purgesubcommand is added to
senlin-managetool for purging actions from the actions table.
[blueprint action-update] A new action update API is added to allow the action status to be updated. The only valid status value for update is CANCELLED.
[bug 1815540] Cluster recovery and node recovery API request bodies are changed to only accept a single operation. Optional parameters for this operation are set in operation_params.
[blueprint scaling-action-acceptance] Scaling actions (IN or OUT) now validate that there is no conflicting action already being processed and will return an error via the API informing the end user if a conflict is detected. A conflicting action is detected when new action of either CLUSTER_SCALE_IN or CLUSTER_SCALE_OUT is attempted while there is already cluster scaling action in the action table in a pending status (READY, RUNNING, WAITING, ACTION_WAITING_LIFECYCLE_COMPLETION). Additionally the cooldown will be checked and enforced when a scaling action is requested. If the cooldown is being observed the requester will be informed of this when submitting the action via an error.
[blueprint fail-fast-locked-resource] POST, PATCH or DELETE API calls for clusters or nodes that require a lock are rejected with 409 resource conflict if another action is already holding a lock on the target resource.
[blueprint multiple-detection-modes] Health policy v1.1 now supports multiple detection types. The user can combine node status poll and node poll url types in the health policy in order to have both checked before a node is considered unhealthy.
New framework for
senlin-status upgrade checkcommand is added. This framework allows adding various checks which can be run before a Senlin upgrade to ensure if the upgrade can be performed safely.
This release makes changes to the health policy properties that are incompatible with health policy v1.0. Any existing policies of type health policy v1.0 must be removed before upgrading to this release. After upgrading, the health policies conforming to v1.0 must be recreated following health policy v1.1 format.
Operator can now use new CLI tool
senlin-status upgrade checkto check if Senlin deployment can be safely upgraded from N-1 to N release.
[bug 1789488] Perform deep validation of profile and policy schemas so that errors in spec properties are detected.
[bug 1811161] Perform policy post-op even if action failed. This allows the health policy to reenable health checks even if an action that failed.
[bug 1811294] Set owner field for actions created to wait for lifecycle completion. This allows these actions to be cleaned up when the engine is restarted.
[bug 1813089] This change picks the address when adding a node to a load balancer based on the subnet ip version. This fix adds supports for nodes with dual stack network.
[bug 1817379] Delete ports before recovering a node.
[bug 1817604] Fixes major performance bugs within senlin by improving database interaction. This was completed by updating the database models to properly take advantage of relationships. Additionally removes unnecessary database calls and prefers joins instead to retrieve object data.
Fixes the logic within the health manager to prevent duplicate health checks from running on the same cluster.
Adds a configuration option to the health manager to control the maximum amount of threads that can be created by the health manager.