Kerberos¶

Check this:

1. If you enabled Kerberos authentication in any of the Denodo Platform components (e.g. Virtual DataPort, Scheduler…) or in the Solution Manager.

2. And any of the components of the new version (version 9) is going to be accessed using a different host name than in the previous version.

If all these conditions are met, you have to create a new service account in Active Directory, define its Service Principal Name (SPN) and generate a Kerberos keytab for this new account.

If you are going to install the new version on the same computers that you have the version 8.0, you can reuse the service account, the same SPN and the same keytab.

Let us say that in Denodo 8.0, you have a cluster of four Denodo servers and the client applications connect to them using the host name of the load balancer. In this case, the Service Principal Name (SPN) matches the host name of the load balancer. If you install the new Denodo Platform on different computers but they are going to be accessed using the same host name defined in the load balancer, then, you do not have to do anything. That is, you can reuse the service account, the same SPN and the same keytab.

Virtual DataPort: Select a Catalog/Schema for the Cache Engine¶

If you use the cache engine of Virtual DataPort, there are two alternatives:

1. Create a new catalog/schema for the cache database of the Denodo Platform 9.

2. Or use the same catalog/schema for the cache database that you are already using.

   Virtual DataPort 9 is compatible with the cache database created with 8.0 and 7.0.

Benefits of option a)

• You can run Virtual DataPort 8.0 and 9 simultaneously because the cache data is isolated.

Disadvantages of a)

• You need to create a new catalog/schema in the cache database, which may involve using a significant amount of disk space.

• You have to populate the cache again. However, this may not be an inconvenient if the volume of data is relatively low.

Benefits of option b)

• You do not need to create a catalog/schema.

• You do not have to populate the cache again. This is very beneficial if you are dealing with a high volume of data.

Disadvantages of b)

• Virtual DataPort 8.0 cannot run at the same time as Virtual DataPort 9.

  Both versions can be connected to the same cache database simultaneously and the cached data will remain in place and accessible. During the upgrade process, after importing the metadata into 9, you can shut down Virtual DataPort 8.0, start 9 and test that the cached data is still accessible.

  If you pick option b), consider this:

  1. After importing the metadata into 9, do not use 8.0 to do any action that implies modifying the cache database. This may cause queries that use the cache to fail. E.g. do not modify the structure of a cached view (do not add/modify/delete fields from the view), do not enable/disable the cache on a view, do not change the cache mode of a view, etc. That is because Virtual DataPort 9 will not be aware of these changes.

  2. Minimize the time both versions are running. This is to avoid that, accidentally, different users perform actions that cause Virtual DataPort 9 and 8.0 to modify simultaneously the data stored in the cache database.

  Any action that implies modifying the cached data should only be done in version 9.

Virtual DataPort: Create a Repository for Version Control¶

If you use the support for version control (VCS), create a repository for Virtual DataPort 9. You cannot reuse the existing one, nor create a branch in that repository. This is because some VQL statements of Virtual DataPort 9 do not work on previous versions and vice versa.

Solution Manager: Create a Git Repository or Branch for Version Control¶

If you use the support for Git, create a repository or a branch for the Solution Manager 9.

Solution Manager: Create a Catalog/Schema on the External Database¶

If you configured Solution Manager 8.0 to use an external database, create a catalog/schema for the version 9.