Standard Mode Deployments¶
Only global administrators, promotion administrators and promotion users can deploy revisions. More information is available in the Authorization section.
Authentication against servers during a deployment are performed using Denodo Security Token. The servers must have token authentication configured.
A deployment process consists in executing all the changes defined in one or more revisions in the Denodo servers of an environment. More specifically:
If a revision includes Virtual DataPort elements, the corresponding VQL will be executed in all the enabled Virtual DataPort servers that belong to the environment.
If a revision includes Scheduler jobs, they will be created (for CREATE revisions) or removed (for DROP revisions) from the first enabled Scheduler server of each enabled cluster that belongs to the environment. When deploying CREATE revisions, the Scheduler jobs are executed if they were marked for execution in the revision.
If the environment has Data Catalog server synchronization configured, the corresponding Data Catalog servers’ metadata will be synchronized according to the provided configuration.
The Solution Manager executes first all the revisions in one server before continuing to the next one. The order in which the servers are selected depends on how they are arranged in the catalog. Therefore, the first enabled server of the first enabled cluster of the target environment will be the first server in updating its metadata.
Disabled clusters and clusters with no enabled Virtual DataPort servers will be ignored during the deployment process.
The Scheduler jobs are only created / removed and executed (if needed) in the first enabled Scheduler server of each enabled cluster of the environment.
The Scheduler jobs are executed after the changes are deployed in the first Virtual DataPort server of the cluster.
In order to work properly, each Scheduler job should be pointing to the first enabled Virtual DataPort server in the cluster. This is to make sure that the Scheduler job finishes correctly if it loads a view whose schema has changed.
The next picture summarizes the basic steps of a generic deployment process:
The deployment configuration of the target environment defines which actions are actually performed during the deployment process.
The Solution Manager checks the following before deploying a revision:
The user must have one of these privileges:
Deployments must be enabled in the configuration of the target environment.
There is no other deployment in progress in the target environment.
The target environment has at least one enabled cluster with at least one enabled Virtual DataPort server.
If a revision includes one or more Scheduler jobs, the environment must have at least one enabled Scheduler server on each enabled cluster.
If in the Deployments configuration of the target environment, Data Catalog synchronization is enabled, this environment must have at least one Data Catalog registered.
The target environment must define all the Virtual DataPort properties of the revision.
Every enabled cluster of the target environment with enabled Scheduler servers must define all the Scheduler properties of the revision.
The servers must have token authentication configured. See Configure the Connection to the Security Token Server from the Denodo Platform for more details.
The environment configuration has to match the current environment topology.
Additionally, the Solution Manager performs another validations depending on the deployment configuration of the environment. These validations are explained in the following section.
The Solution Manager offers several options for performing the deployment process. This section evaluates the advantages and trade-offs of each one of them.
This option assumes that the application service will not be available during the whole deployment process. It is intended for offline promotion scenarios.
The Solution Manager deploys the revisions in all the corresponding servers, without explicitly disabling any cluster or server in the load balancer.
There is no need to perform any additional validation in simple deployments.
Deployment Without Service Interruption¶
Intended for online promotion scenarios, this option maintains the application service available during the deployment process. However, there may be inconsistencies while the deployment lasts, since servers with old and new versions of the metadata might provide service at the same time.
To maintain the application service, the Solution Manager executes scripts to disable Virtual DataPort servers or clusters in the load balancer and to enable them again when the deployment finishes. There are two promotion strategies available that control the interaction with the load balancer:
One by one: The promotion is executed in an incremental way. Only one server or cluster is disabled (and then enabled) at a time. This results in longer times of inconsistency. The inconsistency time grows with the number of clusters or servers in the target environment.
Half by half: In this strategy half of the servers or clusters are disabled (and then enabled) at the same time. This results in inconsistency for a short time.
Take into account that the promotion strategy does not affect the deployment process duration. No matter how many servers or clusters are disabled in the load balancer at a time, the final servers will be updated one by one.
The Solution Manager only enables servers whose deployment process finished successfully. In the same way, the Solution Manager only enables those clusters where the deployment process was successful for all their servers.
The options available for the deployments without service interruption depend on the topology of the target environment.