About the Upgrade Process for Non-Replicated Configurations

For non-replicated configurations where the image upgrade strategy is:

  • Auto: The upgrade process is automated. The TimesTen Operator does not take immediate action. Rather, Kubernetes takes action and automatically begins terminating Pods and replacing them with new ones. The new Pods run the upgraded TimesTen image.

    The number of Pods that Kubernetes terminates and replaces is dependent on the value of the .spec.ttspec.rollingUpdatePartition datum. In particular, Kubernetes upgrades Pods whose ordinal value is greater than or equal to the value of .spec.ttspec.rollingUpdatePartition. Pods whose ordinal value is less than the value of .spec.ttspec.rollingUpdatePartition are not upgraded. For example, if you have three non-replicated Pods (replicas = 3 where the ordinal value of the Pods are -0, -1, and -2) and the value of .spec.ttspec.rollingUpdatePartition is 2, the -2 Pod is upgraded, but the -1 and -0 Pods are not. The default for .spec.ttspec.rollingUpdatePartition is 0.

    You have the option of specifying the .spec.ttspec.rollingUpdatePartition datum when you define the attributes for your TimesTenClassic object. If you do not specify the datum, the default is 0. See About Defining TimesTenClassic Objects.

    You also have the option of changing the value of the .spec.ttspec.rollingUpdatePartition datum as part of the upgrade procedure. There is an example later in the chapter that illustrates how to do this.

  • Manual: The upgrade process is manual. Neither Kubernetes nor the TimesTen Operator takes immediate action. You are responsible for initiating the upgrade by deleting one or more Pods. For manual upgrades, the .spec.ttspec.rollingUpdatePartition datum is ignored.

There are two examples later in the chapter that show you how to perform an automated and a manual upgrade for non-replicated TimesTenClassic objects. The examples are in the following sections: