Skip to main content

Licensing

Datastrato Enterprise requires a license key. The sections below cover obtaining one, supplying it, replacing it, and what happens when one expires.

Obtain a key​

Trial keys are issued at the Datastrato trial page and are time limited. Production keys come from your account team and are tied to the entitlement in your agreement.

A key is a single opaque string. Treat it as a credential: it belongs in a secret rather than in a values file committed to a repository.

Supply the key​

The key is passed to the Datastrato Enterprise Helm chart at install time, as the value gravitino.license.key. The chart stores it in a Secret and hands it to the server. The commands use the variables and files from step 1 of Install.

Install with the license key
helm upgrade --install "$RELEASE" "./enterprise-helm-$VERSION.tgz" -n "$NAMESPACE" -f my-values.yaml \
  --set-string gravitino.license.key="$(tr -d '\n' < "$LICENSE_FILE")" \
  --timeout 15m 2>&1 | tee helm-install.log

Use --set-string rather than --set. A license key can contain characters Helm's type inference will mangle, and the failure appears later as an invalid key rather than as a parse error. The tr strips the key file's trailing newline; a key with a newline in it is rejected as malformed.

Use a secret​

To keep the key out of the command line and the Helm release record, put it in a Secret you manage and point the chart at it. The chart then creates no Secret of its own.

Create the license Secret
kubectl -n "$NAMESPACE" create secret generic datastrato-license \
  --from-literal=license-key="$(tr -d '\n' < "$LICENSE_FILE")"
my-values.yaml
gravitino:
  license:
    existingSecret: datastrato-license
    secretKey: license-key

secretKey names the entry in the Secret that holds the key, license-key by default. Install without the --set-string gravitino.license.key argument.

Verify activation​

The server checks the key at startup and logs the result, including who the key is issued to, its expiry date and its node limit. A missing, malformed or fully expired key stops the server at startup, so a server pod that restarts repeatedly is the first thing to check against its license.

Check the license state in the logs
kubectl -n "$NAMESPACE" logs deployment/"$RELEASE"-gravitino | grep -i license

Replace a key​

Renewal, an entitlement change, or a trial converting to production all mean a new key. With the key on the command line, run the install command again with the new key file. With your own Secret, update the Secret and restart the server, which reads the key only at startup.

Replace the key in your Secret and restart
kubectl -n "$NAMESPACE" create secret generic datastrato-license \
  --from-literal=license-key="$(tr -d '\n' < {new_license_file})" \
  --dry-run=client -o yaml | kubectl apply -f -
kubectl -n "$NAMESPACE" rollout restart deployment/"$RELEASE"-gravitino

Expiry​

An expired license does not delete anything. Your metalakes, catalogs, tags, policies, and grants remain in the metadata database, and the underlying sources are untouched, since Gravitino never held your data in the first place.

What stops is service. From 30 days before the expiry date the server logs a warning. After the expiry date it keeps running through the grace period set in the key, logging how many days remain, and at the end of the grace period it shuts down with exit code 78. Applying a valid key and restarting restores the deployment to where it was.

Plan renewal ahead of the expiry date rather than relying on the grace period.

A key can also limit how many server replicas run at once. A replica started beyond that limit shuts down with the same exit code 78.

Last updated on