Please use the form below to provide your feedback. Because your feedback is valuable to us, the information you submit in this form is recorded in our issue tracking system (JIRA), which is publicly available. You can track the status of your feedback using the ticket number displayed in the dialog once you submit the form.

Release Notes for Couchbase Autonomous Operator 2.7

      +

      Autonomous Operator 2.7 release provides full support for Couchbase Server 7.6, and several improvements to Pod Scheduling and Networking, as well as a number of minor fixes.

      Take a look at the What’s New page for a list of new features and improvements that are available in this release.

      Installation

      For installation instructions, refer to:

      Upgrading to Autonomous Operator 2.7

      The necessary steps needed to upgrade to this release depend on which version of the Autonomous Operator you are upgrading from.

      Upgrading from 1.x, 2.0, or 2.1

      There is no direct upgrade path from versions prior to 2.2.0. To upgrade from a 1.x, 2.0.x, or 2.1.x release, you must first upgrade to 2.4.x, paying particular attention to supported Kubernetes platforms and Couchbase Server versions. Refer to the Operator 2.4 upgrade steps if upgrading from a pre-2.2 release.

      Upgrading from 2.2, 2.3, 2.4, 2.5, or 2.6

      There are no additional upgrade steps when upgrading from these versions, and you may follow the standard upgrade process. However, due to K8S-3097, all users will encounter a mandatory upgrade cycle when upgrading from a release older than 2.5.0, to versions 2.5.0, 2.5.1, or 2.6.0 through 2.6.3, to expose the missing Indexer HTTPS Port (see Detailed Port Description for network port requirements). This behavior has changed in versions 2.5.2, 2.6.4, and 2.7.0, and there is no mandatory upgrade cycle — the missing port is added the next time there is a regular maintenance activity that involves Pod creation.

      An upgrade cycle is a relatively heavyweight operation that requires all pods in the cluster to be replaced, and data transferred between the old and new pods. The time taken to perform this operation is dependent on network bandwidth, disk IO and the amount of data resident in the database. For large, production databases, ensure an adequate maintenance window is scheduled as to minimize any disruption to clients and other business critical functions.

      For further information read the Couchbase Upgrade concepts page.

      Release 2.7.0

      Couchbase Autonomous Operator 2.7.0 was released in August 2024.

      Changes in Behaviour

      Delta Recovery / In-Place Upgrades

      The DeltaRecovery upgrade strategy added in Operator 2.6 has been replaced by InPlaceUpgrade, to better reflect the actual behaviour (not every Service can be Delta Recovered), and DeltaRecovery is now deprecated.

      Storage Backend Migration

      In Server 7.6 it is now possible to migrate between the Couchstore and Magma storage backends, as described in Migrate a Bucket’s Storage Backend. Operator will automatically start the required Rebalances if it detects an unresolved Storage backend change. Storage Backend can also be configured using annotations, see Bucket Backend Configuration for more details.

      Query Service Settings

      Over time, a significant gap had appeared between the Query Service settings available in Couchbase Server, and the ones exposed via the CouchbaseCluster CRD in Autonomous Operator. This has been addressed in CAO 2.7.0, and the following cluster-wide settings are now available:

      • Server 6.5+: queryPipelineBatch, queryPipelineCap, queryScanCap, queryTimeout, queryPreparedLimit, queryCompletedLimit, queryCompletedThreshold, queryLogLevel, queryMaxParallelism.

      • Server 7.0+: queryTxTimeout, queryMemoryQuota, queryUseCBO, queryCleanupClientAttempts, queryCleanupLostAttempts, queryCleanupWindow, queryNumAtrs.

      • Server 7.6+: queryNodeQuota, queryUseReplica, queryNodeQuotaValPercent, queryNumCpus, queryCompletedMaxPlanSize.

      Note that queryNodeQuota is being exposed via the existing spec.cluster.queryServiceMemoryQuota. For Server versions prior to 7.6, this value is used to determine Pod resource requirements, and from version 7.6 onwards will also be used to set queryNodeQuota on the Couchbase Server cluster (see K8S-3436).

      Note that queryNumCpus requires a restart of the Query Service to take effect. In practice in a Kubernetes environment, this means that this will only affect Pods started after the setting has been updated.

      Prior to Operator 2.7.0, the above Query Service settings could still be set directly on the cluster.

      To avoid these being reset to default values during the CAO upgrade, any of the above settings that have been changed must be added to the CouchbaseCluster resource during the upgrade.

      Specifically, this needs to be done after updating the CRDs, and before installing the new Operator

      For further information see Update Existing Resources.

      Audit Log Pruning

      With the addition of native pruning of rotated Audit Logs in Server 7.6, the garbageCollection sidecar is now deprecated.

      Miscellaneous Changes

      Fixed Issues

      Issue Description

      K8S-3377

      Summary: Previously the TestTLSRotateCAKillPodAndKillOperator test was failing with Server 7.6.

      K8S-3391

      Summary: Previously the Operator was not correctly deleting un-managed XDCR Remote Cluster References.

      K8S-3452

      Summary: Previously the Operator was triggering a mandatory upgrade cycle when upgrading from 2.4.x or earlier.

      K8S-3587

      Summary: Previously the eventing_manage_functions RBAC role was missing from the list of cluster roles.

      Known Issues

      Issue Description

      K8S-3632

      Summary: It is not currently possible to set couchbasecollections.spec.maxTTL to -1 to disable expiry.

      K8S-3663

      Three tests: TestPersistentVolumeAutoRecovery, TestUpgradeSupportableKillStatefulPodOnCreate, and TestAutoscaleUpMandatoryMutualTLS may fail when running self-certification on Kubernetes 1.31.

      Feedback

      You can have a big impact on future versions of the Operator (and its documentation) by providing Couchbase with your direct feedback and observations. Please feel free to post your questions and comments to the Couchbase Forums.

      Licenses for Third-Party Components

      The complete list of licenses for Couchbase products is available on the Legal Agreements page. Couchbase is thankful to all of the individuals that have created these third-party components.

      More Information