cfxDimensions v2.2.20

Macaw Platform - v2.2.20

Release Date: August 26, 2021

cfxDimensions Platform Features - v2.2.20

v2.2.20 release is a backward-compatible release with the previous releases v2.1.18, v2.1.17.

New Features in v2.2.20

macaw CLI history

• This release adds functionality to keep a history of user-executed macaw CLI commands in the /home/macaw/.macawcli file.

macaw application --insecure start <app-id>

• This release adds functionality/command that will start all the clusters pertaining to an application in the order which was provisioned using the CloudFabrix application blueprint (services were initially deployed using a standard CloudFabrix application template/blueprint)

macaw application --insecure rolling-update --tag <tag> [--input INPUT_FILE] [--deployment-flavor DEPLOYMENT_FLAVOR] [--wait ROLLING_UPDATE_COMPLETION_TIMEOUT] < app-id>

• This command can be used to perform a rolling update on all clusters of an application (e.g.cfxOIA), from CLI.

  • app-id is the id of the application which we can get from the ‘macaw application --insecure status’ command.

  • If a user wants to change service-configs of any cluster, then input files can be used to give modified configs. These are the same values that are seen in console-ui during deployment/rolling-update. If there are no config changes during rolling-update, then we can skip the input json file. Service-id, config names can be taken from the blueprint json file.

  • --deployment parameter If a user wants to change the deployment flavor, then users can use --deployment flavor. This is an optional parameter.

  • --wait parameter --wait is optional. This parameter provides the number of seconds for the command to wait after triggering the rolling update. During this time, if the provisioner completes the upgrade, then the command will return a success message. This optional parameter is useful when a user prefers to use this command in a script.

Service Provisioner enhancement

• After the rolling update operation is performed, users no longer see old clusters in the Inactive tab (via console-ui and are now are hidden) When a user performs rolling updates, the system now considers/selects the exact count of instances from the actual instance (provisioned) count. If scale-up/scale-down operation was performed by the user to a service cluster after initial provisioning, then this new count will be considered for rolling-update.

CFDs

• Service Registry bug fix to connect back to the MariaDB automatically when it loses connectivity during runtime (intermittently Service Registry disconnects with the MariaDB database)

• The issue with paused cluster instance - Rolling Update on clusters with multiple Unreachable/Registered instances, is leaving one paused instance in the old cluster (MACAW-3583).