1.0.0

fix binary dynamicaly linked (#25)

0.12.0

Changes in 0.12.0

Deprecations

• None

Improvements

• #11 Added support to define tolerations
• #10 Added support to define node selectors

Bug Fixes

• #13 Fixed bug to properly handle pods in error state after initialisation

0.11.0

Changes in 0.11.0

Deprecations

• Dropped support for Kubernetes versions prior to 1.13.

Improvements

• Added support for Kubernetes versions 1.13 and newer.
• Docker images are now based off of gcr.io/distroless/static instead of Alpine whenever possible.
• Added support for defining Aerospike server resource limits.
• Miscellaneous improvements to build and runtime, including bump to Go 1.12.5 and adopt Go modules.

Bug Fixes

• None

0.10.1

Changes in 0.10.1

Deprecations

• Deprecated the --admission-enabled and the --debug flags. These will be removed in a future version.

Improvements

• Added support for Aerospike 4.3.0.8 and 4.3.0.10.
• Updated aerospike/aerospike-client-go to 1.35.2.

Bug Fixes

• Fixed a bug which caused the reconcile loop to block for long periods of time when pods entered an error state.
• Fixed a bug which caused Aerospike 4.3.0.2 and later not to start if .spec.namespaces[0].memorySize was not explicitly set.

0.10.0

Changes in 0.10.0

Action required

• Before upgrading aerospike-operator, one MUST update the aerospike-operator cluster role using, e.g., kubectl apply -f docs/examples/00-prereqs.yml.

Breaking changes

• Dropped support for Kubernetes 1.10.

Improvements

• Promoted the API to aerospike.travelaudience.com/v1alpha2.
  • Existing aerospike.travelaudience.com/v1alpha1 resources are automatically converted to the new version when aerospike-operator starts.
  • One is strongly adivsed to update their manifests to reflect this change (i.e. replacing v1alpha1 with v1alpha2).
  • The aerospike.travelaudience.com/v1alpha1 API is being deprecated, and will be permanently disabled in a future version.
• Added the secretNamespace and secretKey fiels to BackupStorageSpec. This allows the secrets used to backup/restore to/from cloud storage to exist in a Kubernetes namespace different from the one holding the AerospikeCluster resource.
• Added the data-in-memory field to StorageSpec.
• Added additional printer colums to AerospikeCluster, AerospikeNamespaceBackup and AerospikeNamespaceRestore.
  • Listing AerospikeCluster resources now displays version, node count and age.
  • Listing AerospikeNamespaceBackup resources now displays target Aerospike cluster and namespace, as well as age.
  • Listing AerospikeNamespaceRestore resources now displays target Aerospike cluster and namespace, as well as age.
• Added support for the /scale and /status subresources.
  • It is now possible to scale an Aerospike cluster using kubectl scale.
• Added support for Aerospike 4.0.0.6, 4.1.0.6, 4.3.0.2, 4.3.0.4, 4.3.0.6 and 4.3.0.7.
• Updated aerospike/aerospike-client-go to 1.35.1.

Bug Fixes

• Fixed a bug which caused .status.conditions not to be reported in AerospikeCluster resources.

Documentation

• Usage: Improved the Installation Guide.

Other

• Tests: Introduced the GCS_SECRET_NAMESPACE and GCS_SECRET_KEY environment variables.

0.9.0

Changes in 0.9.0

WARNING: Running aerospike-operator in Kubernetes 1.10 is still possible. However, not all features are supported or stable. Kubernetes 1.10 support will be dropped in the 0.10.0 release.

Breaking changes

• Change in the API in order to support deletion of PVCs by the garbage collector.
  • Add persistentVolumeClaimTTL field to StorageSpec.
  • Action required: Persistent volume claims created in previous versions of aerospike-operator will be replaced by new ones when a restart or upgrade operation is performed on an AerospikeCluster resource. To avoid losing data for Aerospike namespaces whose replication factor is equal to 1, one must create a backup of all Aerospike namespaces whose replication factor is equal to 1 before upgrading aerospike-operator. Then, after upgrading aerospike-operator, one must restore these backups to new Aerospike clusters.

Improvements

• Add support for deletion of expired resources via introduction of a garbage collector.
  • Support deletion of expired PVCs.
  • Support deletion of expired AerospikeNamespaceBackups.
• Introduced asinit as a replacement to sed.
  • The image for the init container has been switched from busybox to quay.io/travelaudience/aerospike-operator-tools.
• aerospike-operator will now wait for a node to join the existing cluster before proceeding with restarting the next node during a rolling-restart or upgrade procedure.
• Add support for Aerospike 4.2.0.10.
• Use aerospike/aerospike-client-go 1.35.0.

Bug Fixes

• Fixed a bug which might under rare circumstances cause a node to form a separate cluster after being restarted.

Documentation

• Design: Add the Garbage Collection design document.
• Design: Updated the Architecture design document.

0.8.0

Changes in 0.8.0

Breaking changes

• Change the naming strategy for persistent volume claims to use GenerateName.
  ** Action required: Persistent volume claims created in previous versions of
  aerospike-operator will be replaced by new ones when a restart or upgrade
  operation is performed on an AerospikeCluster resource. To avoid losing data
  for Aerospike namespaces whose replication factor is equal to 1, one must
  create a backup of all Aerospike namespaces whose replication factor is equal to
  1 before upgrading aerospike-operator. Then, after upgrading
  aerospike-operator, one must restore these backups to new Aerospike clusters.

Improvements

• Add support for Kubernetes 1.11+.
• Add support for the device (raw) storage type.
  ** Device storage requires a Kubernetes 1.11 cluster with alpha features enabled.
• Use Aerospike Tools 3.15.3.14.
• Use aerospike/aerospike-client-go 1.34.1.
• Support running custom upgrade steps via the introduction of
  docs/design/upgrade-strategies.adoc#,upgrade strategies.
• Add support for Aerospike versions 4.0.0.4, 4.0.0.5, 4.1.0.1 and 4.2.0.5.

Documentation

• Design: Add an docs/design/upgrade-strategies.adoc#,Upgrade Strategies
  design document.

0.7.0

Release Notes

Changes since 0.6.0

Breaking changes

IMPORTANT: Before upgrading aerospike-operator to 0.7.0 or later, one
should perform the actions indicated by the Action required items below as
applicable.

• Enforce the existence of a single Aerospike namespace per Aerospike cluster.
  • Action required: Existing AerospikeCluster resources with two Aerospike
    namespaces must be backed-up and restored to two new, separate Aerospike
    clusters with a single Aerospike namespace each.

Improvements

• Use stable node IDs for Aerospike nodes.
• Prevent Aerospike from trying to establish heartbeat connections to IP
  addresses of pods that don't exist anymore.
• Support operating on up to six Aerospike clusters simultaneously instead of
  only two.
• Prevent the .status field of an AerospikeCluster resource from being
  deleted.
• Allow standby replicas of aerospike-operator to serve the validating
  admission webhook.
• Improving the handling of errors caused by the Kubernetes API forcibly closing
  open watch connections.
• Wait for endpoints for custom resource definitions to be available before
  starting the controllers.
• Improve logging when running with --debug=false.

Bug Fixes

• Fix panics that might occur if some optional fields were absent from a
  AerospikeCluster resource.

Documentation

• Design: Make it clear that .spec.backupSpec is only required when one
  wants to upgrade an Aerospike cluster.
• Design: Make it clear that .spec.nodeCount must be greater than or equal
  to .spec.namespaces[*].replicationFactor.
• Design: Add an OpenAPI spec for the
  aerospike.travelaudience.com/v1alpha1 API.
• Design/Usage: Address single namespace limitation.
• Usage: Briefly mention capacity planning as a precursor to the creation of
  AerospikeCluster resources.
• Usage: Make it clear that the secret used for backups and restores must
  contain a key.json entry.
• Usage: Fix the name of the .spec.namespaces[*].storage.storageClassName
  field.
• Usage: Add a "quickstart" subsection to the
  Installation Guide page.
• Examples: Add missing permissions to the example cluster role binding.
• Examples: Specify resource requests and limits for aerospike-operator pods
  in the example deployment.
• Other: Add links to README.md for better navigation.
• Other: Mention supported Aerospike versions in README.md.
• Other: List existing design documents in README.md.

Other

• Tests: Run end-to-end tests using a separate Kubernetes service account.