71.0.1
Fixed
- all services: a9s SPIs: Fix the issue that caused custom parameter configuration set at Service Plan level to be used for all plans, as it overwrote the referenced object in memory as well.
a9s Generally Available (GA). For
more information, see a9s Platform Operator - Sunrise Sunset.tls13_cipher_suites custom parameter. This maps
to the MongoDB opensslCipherSuiteConfig startup parameter.tls13_cipher_suites to support the MongoDB
opensslCipherSuiteConfig startup parameter.bootstrap_initialized.lock File.outdated Service Instances to include stopped Service
Instances.update strategy, using the outdated
instance type, to skip all stopped Service Instances. The output of the errand has also been extended to reflect this
additional Service Instance state. For more information, see a9s Deployment Updater - Update.Secure attribute to session cookie, which is set after the Oauth Handshake between
CF UAA and a9s Public API.keyvalue to valkey in the enable-service-instances-aws-instance-profiles.yml
Ops file.create-admin and update-admin scripts for a9s MongoDB 8.0 BOSH
release.a9s Cloud Foundry CLI Plugin. For more information, see Disaster Recovery.keyvalue to valkey in the "Extending the a9s Data Services'
Templates" section. For more information, see Using AWS Instance Profiles.1.1107, for internal tests of all supported services.deploying, which prevented further operations from taking place...a9s Release Candidate.state and locked to the script instance-information.instance-information script documentation to include the new
fields, state and locked. For more information, see a9s Service Broker - Retrieve Service Instance Information.instance-information.erb in the a9s Service
Broker BOSH release to provide the context of a Service Instance instead of the metadata.addons/mongodbsspl/ops/add-mongodb-sspl.yml with the
following new properties to introduce a9s MongoDB 8.0 SSPL (Add-on) as an a9s Release Candidate:
error to info for
better visibility.operations endpoints of the Stop/Start Experimental
Feature to allow to forward pagination related query parameters. For more information, see
Experimental Features - Stop/Start Feature.messaging41 to messaging4.ssl_ciphers custom parameter to ensure no malicious
strings can be injected into the configuration.ssl_ciphers custom parameter to ensure no
malicious strings can be injected into the configuration.1.1065 for internal tests of all supported services.a9s Redis®: Deprecation: Deprecate the following Data Service:
The whole Data Service will be discontinued and no new versions will be released for it. Please ensure that you organize the migration of your existing Service Instances to the supported a9s KeyValue Data Service:
Existing a9s Redis® Service Instances can be migrated to a9s KeyValue by forking them using the Disaster Recovery feature, or by applying manual migration steps. For more information about the available migration options, please see the Forking and Migration documentation page.
This deprecation follows the announcement in v67.0.0. The deprecation phase is planned to last until v73.0.0 (expected end of May). With that release, the unsupport phase of the deprecated Data Service will start. The creation of new a9s Data Service Instances for this Data Service will be disabled by default in the a9s Data Service Bundle when the unsupport occurs in v76.0.0 (expected end of August) and we will not provide regular support for this Data Service. The corresponding documentation will also be removed. Therefore, we strongly recommend that you start your migrations to a supported Data Service as soon as possible and complete them until the end of the deprecation phase. For more information see a9s Platform Operator Sunrise Sunset.
note admonition in the max_connections custom parameter
section by properly closing it. For more information, see a9s PosgreSQL - Custom Parameters - max_connections.a9s PostgreSQL: End of Support: Terminate support, starting from anynines deployment v73.0.0 (expected end of May 2026), for the following deprecated a9s Data Service version:
The creation of new a9s Data Service Instances for this deprecated version will be disabled by default in the a9s Data Service Bundle, and we will not provide regular support for this version. The corresponding documentation will also be removed.
Although we will not intentionally break running Service Instances of this unsupported version, it cannot be guaranteed that they still work as expected after an update to v73.0.0.
anynines-deployment release. For more information, see
Experimental Features.messaging41-* which contain the latest version of RabbitMQ 4.1. Once RabbitMQ
4.3 is supported, these legacy templates will be removed and new templates messaging42-* will be created. These
templates provide a last resort rollback to the previous minor version of RabbitMQ, in case there are problems with
the latest version of a9s Messaging. For more information, see a9s Messaging - Rollback to Legacy Version.CHECKPOINT before stopping replication, in order to facilitate
the conditions for a graceful shutdown during an update. For more information, see CHECKPOINT.rabbitmq_event_exchange to the available plugins list. For more
information, see a9s Messaging - Custom Parameters.plugins, and how any of the
bundled plugins of the vendored OpenSearch can be enabled at the discretion of the Platform Operator. For more
information, see a9s Search - Custom Parameters.1.1028 for internal tests of all supported services.task-handler process to avoid deadlocking single Service Instances.
This prevents it from immediately rescheduling a backup that is already running, ensuring continuous processing
without repeatedly picking the same Service Instance.LOCK TABLES error when restoring an a9s MariaDB backup, by adding
--skip-add-locks to the backup's creation command. The function of LOCK TABLES is already covered by the internal
restore-prepare step already ensures that no connections are made to MariaDB, which protects the tables as they are
being restored.i_agree_with_the_underlying_license_agreement property. Although the
license agreement must be accepted in order to deploy the Data Service deployment, a default value is necessary to
properly output the error for not accepting the license.net_read_timeout and net_write_timeout parameters configurable through custom parameters.
For more information, see a9s MariaDB.GUID filter to enable the viewing of metrics for one or all Service Instances.net_read_timeout and
net_write_timeout. For more information, see a9s MariaDB.net_read_timeout and
net_write_timeout. For more information, see a9s MariaDB.AppDynamics support. For more
information, see a9s PostgreSQL Enable AppDynamics Supportforbid-automatic-update-of-service-instance.yml Ops
file to enable-ad-to-manage-maintenance-updates.yml to better align with the underlying functionality.messaging40* to messaging4*. These templates will always
contain the latest supported version of RabbitMQ 4.X.a9s-messaging40 to
a9s-messaging4 in the Service Instance manifests.rabbitmq40 to rabbitmq4 and reset its version number
(latest version:1.0.2). The latest version of a9s Messaging will always be available with rabbitmq4.GET /v2/service_usage_events to only include
events that are relevant for a9s Billing; transitional events such as CREATING or UPDATING are omitted. This
reduces the response size and as a result the size of the usage_data file in offline environments.bin/rotate_ca_certificate.rb script to include a parameter for the CA name. For more
information, see rotate_ca_certificate.rb.GET /v2/service_instances/:instance_id/service_bindings/:binding_id to also include the credentials.net_read_timeout and net_write_timeout.skipped_metrics, ensuring that failed
metric fetches are properly tracked and logged. For more information, see Metrics - General Metrics.primary/secondary role names and
add information about the naming conventions the Data Service vendors use for node roles.a9s-messaging40 to a9s-messaging4.rabbitmq_webmqtt to rabbitmq_web_mqtt and
rabbitmq_webstomp to rabbitmq_web_stomp). For more information, see a9s Messaging - Service Instance Access.max_connections and max_wal_senders. For more information, see:
a9s_public_components_ca. For more
information, see Root CAs.primary/secondary role names and add
information about the naming conventions the Data Service vendors use for node roles.a9s-messaging40 to a9s-messaging4.AppDynamics support into an
admonition. For more information, see a9s MongoDB Enable AppDynamics Supportmax_connections and max_wal_senders. For more information, see:
1.999 for internal tests of all supported services.asg_guid is not missing, and that it is properly
synced between the CF Service Guard and Cloud Foundry after an update.max_connections and
max_wal_senders parameters. This enables safe adjustment of their values, both increases and decreases, resolving
the previous issues where increasing these parameters caused downtime and decreasing them resulted in update failures.max_connections and
max_wal_senders parameters. This enables safe adjustment of their values, both increases and decreases, resolving
the previous issues where increasing these parameters caused downtime and decreasing them resulted in update failures.binlog_expire_days custom parameter section. For more information, see a9s MariaDB.disable-backup-download.yml Ops file. For more information, see
Disable Backup Downloads in the a9s Service Dashboard.GET /v1/instances/:instance_id endpoint to keep the response consistent.continuous_archiving or basic backups. This information is used in the a9s Service Dashboard to load
the correct form in the UI.shovels.
For more information, see a9s Messaging - Forking and Migration.messages_unacknowledged_details to
messages_unacknowledged_details.rate, as it is emitted by a9s Messaging.
For more information, see a9s Messaging - Service Instance Metrics.1.954 for internal tests of all supported services.prometheus2:
prometheus-legacy:
promgraf2:
a9s PostgreSQL: Deprecation: Deprecate the following a9s Data Service version:
Please ensure that you organize the migration of your existing Service Instances to a more up-to-date version of the same a9s Data Service:
This deprecation follows the announcement in v64.0.0. The deprecation phase is planned to last until v70.0.0 (expected end of February 2026), in which the unsupport phase of the deprecated version will start. The creation of new a9s Data Service Instances for this particular version will then be disabled by default in the a9s Data Service Bundle and we will not provide regular support for this version. The corresponding documentation will also be removed. Therefore, we strongly recommend that you start your migrations to a supported GA version as soon as possible and complete them until the end of the deprecation phase. For more information see a9s Platform Operator - Sunrise Sunset.
To inquire about extended support for a deprecated version, please get in contact with our sales department at
sales@anynines.com.
partitioned.
For more information, see a9s Messaging - Service Instance Metrics.initialize_backup_deletion_job job from the a9s
Backup Manager worker's queues list, as it is no longer supported. For more information, see
a9s Backup Manager - Queues.failed.backup_date, minutes_since_last_backup, and last_backup_time_store for a9s Search and a9s LogMe2.max_allowed_packet property, used by the mariadb-dump, to match the client
configuration. This fixes an issue that can occur when backing up databases that contain binary data (e.g of type
longblob).backup-manager-service-instance-id and
encryption-key parameters across multiple pages.a9s Messaging: In-Place Version Upgrade with Breaking Changes planned for v69.0.0 (End of January 2026):
Within a9s Messaging 4, RabbitMQ 4.1 will be replaced with RabbitMQ 4.2. There are now Breaking Changes between Minor Versions of RabbitMQ 4, which usually only affect the client side, but require attention. Nevertheless, these RabbitMQ Minor Versions will be released as Minor Versions of a9s Messaging 4.
Due to recent changes in the RabbitMQ release policy, Minor Versions of RabbitMQ 4 now have a maintenance overlap period of 3 months. Previous versions of RabbitMQ 4 did not have any maintenance overlap period.
As a consequence of the Data Service vendor's decision to make the maintenance overlap periods for the open source version of RabbitMQ 4 unusually short, we have decided with the release of a9s Messaging 4 to treat each minor version of RabbitMQ 4 as a minor version of a9s Messaging 4 as well, although some breaking changes between these minor versions may occur.
Therefore we do not follow our usual process for releasing, deprecating and unsupporting these versions as Major Versions: RabbitMQ 4.1 will not be deprecated and unsupported with our default processes, due to the aforementioned situation.
The version upgrade from RabbitMQ 4.1 to 4.2 will be handled as fully automatic in-place upgrade of the a9s Messaging 4 Service Instances, as is currently the case for all minor version upgrades of our Data Services. Thus, RabbitMQ 4.1 will be unsupported, as soon as RabbitMQ 4.2 is available with a9s Data Services.
a9s Data Service will only support one minor version of RabbitMQ 4 (offered as a9s Messaging 4) at any given time. Breaking Changes about future Minor Versions of RabbitMQ will be announced in the Upcoming section of the CHANGELOG to give all customers enough time to prepare for this in-place version upgrade.
This message has the purpose to inform you and recommends to already take the required actions now to be compatible with the new RabbitMQ Minor Version that will be rolled out with v69.0.0 (End of January 2026):
The following Breaking Changes must be considered and the Recommended Actions must be take before upgrading to v69.0.0. We recommend to take care of these changes immediately to ensure a smooth transition.
Default Value for AMQP 1.0 durable Field.
Starting with RabbitMQ 4.2, if a sending client omits the header section, RabbitMQ assumes the durable field to be
false complying with the AMQP 1.0 spec:
<field name="durable" type="boolean" default="false"/>
AMQP 1.0 applications, or client libraries, must set the durable field of the header section to true to mark
the message as durable.
The RabbitMQ team recommends client libraries to send messages as durable by default. None of the
AMQP 1.0 client libraries maintained by the RabbitMQ team
are affected, as they send all messages as durable by default.
Some clients however, do not specify in the header when a message is durable, as they expect the RabbitMQ server
to set any message as durable by default, if the durable field was not set. This is the behavior with versions
previous to RabbitMQ 4.2.
This changes in RabbitMQ 4.2, as messages that do not have the durable field specified in the header will be set
to transient (durable=false) by default.
Scope and Recommendation
These breaking changes only affect the AMQP 1.0 protocol. The difference between the AMQP 1.0 and AMQP 0.9.1 is further explained here.
To verify if the AMQP 1.0 protocol is in use, the following command can be executed on the RabbitMQ Service Instance:
$ rabbitmq-plugins list -e | grep amqp1_0
E*] rabbitmq_amqp1_0 4.1.4
If the AMQP 1.0 protocol is used, all used client libraries must be checked to see if they recognize this change
and set the durable field by default to true, if the message is durable. Otherwise, a message may be sent
without thedurable field specified in the header. Then, this message will be transient, which means it will be
lost in case of any server restart, system crash, or power outage (only with classical queues).
If the field is omitted, the client should not be used. For more details, check this Github page.
Frequently Asked Questions
Are the messages that I push into a durable (classic) queue still durable after the automated update to RabbitMQ 4.2 or are these new messages now transient by default?
Answer: Messages that have been added as durable before the upgrade (no matter if they are durable because the client set them durable or because the client omitted the durable header field and the server set the message as durable by default) are still durable. Messages that are added after the update that do not have the durable field set by the client will be transient by default.
The client libraries I use set the durability field for each message (i.e. with the official clients) - does this affect me?
Answer: No, if the client sets the durability field for each message, then there is no change in behavior.
What happens after a graceful restart of a RabbitMQ Single Instance , e.g. due to a parameter change, with transient messages inside of durable (classic) queues? Are those lost or not?
Answer: Messages published as transient will be discarded during reboot, even if they were stored in durable queues. This is the default behavior of RabbitMQ that has been there before.
What happens after a graceful restart of a RabbitMQ Cluster, e.g. due to a parameter change, with transient messages inside of durable (classic) queues? Are those lost or not?
Answer: By default, queues are not replicated across cluster nodes. Therefore, messages in these queues are not replicated either. To replicate queues across nodes in a cluster, use a queue type that supports replication (e.g. Quorum Queues). With Quorum Queues, your messages will also be replicated across all cluster nodes.
How is the durability specified with AMQP 0.9.1?
Answer: With AMQP 0.9.1, the durability is determined by the message property delivery mode. This is a required
property for each message, therefore nothing changes for the AMQP 0.9.1 protocol. More information about the
message properties for AMQP 0.9.1 can be found here.
Is there any queue type that ensures that messages are durable by default?
Answer: Yes, for Quorum queues, all messages are durable by default, regardless of the message's durability setting (transient or persistent).
What happens when I combine non-durable (classic) queues with durable messages and vice versa?
Answer: Queues and messages can be durable or transient. The durability setting of the queues does NOT affect the durability of the messages. A transient message will be lost after a system shutdown, regardless of whether it is in a durable or a transient queue. For more information about queue and message durability, check the RabbitMQ documentation about Durability.
The RabbitMQ documentation states here that support for transient queues will be removed in RabbitMQ 4.0. Why do these changes even matter then?
Answer: There seems to be a discrepancy in the information from the RabbitMQ documentation, as it is still possible to create transient queues which will also disappear after a restart. A transient queue could be for example created like this:
rabbitmqadmin declare queue name=my-transient-queue durable=false arguments='{"x-queue-type":"classic"}'
Keep in mind, that this likely to change in the upcoming releases of RabbitMQ.
How can I check if my queues are durable or transient or if I have quorum queues?
Answer: The rabbitmqctl or the rabbitmqadmin CLI tools can be used to check for all queues and their status:
rabbitmqctl list_queues name durable arguments
Timeout: 60.0 seconds ...
Listing queues for vhost / ...
name durable arguments
my-transient-queue false [{"x-queue-type","classic"}]
my-quorum-queue true [{"x-queue-type","quorum"}]
rabbitmqadmin list queues name durable arguments
+--------------------+---------+-----------+
| name | durable | arguments |
+--------------------+---------+-----------+
| my-quorum-queue | True | |
| my-transient-queue | False | |
Mandatory Flag in Direct Reply-To
If an AMQP 0.9.1 Direct Reply-To responder (RPC server) publishes with the mandatory flag set, then
amq.rabbitmq.reply-to.* is treated as a queue. Whether the requester (RPC client) is still there to consume the
reply is not checked at routing time. In other words, if the responder publishes to only this queue name, then the
message will be considered "routed" and RabbitMQ will therefore not send a basic.return.
Scope and Recommendation
This breaking change only affects the AMQP 0.9.1 protocol. Other protocols are not affected. More information about the difference between AMQP 1.0 and AMQP 0.9.1 is available here. If Direct Reply-To is not used, then the RabbitMQ Instance is also not affected.
It must be checked if RPC Clients are used as publishers and RPC servers are used as consumers. Furthermore it
should be checked, if any RPC server is configured to send replies with the mandatory flag set. If this is the
case, then the reply message may be lost in case the client disconnects. To mitigate this problem, the client
could automatically send the message again in case he disconnects from the message broker.
Frequently Asked Questions
What is Direct Reply-To?
Answer: Usually, when using RabbitMQs as a message queue for a client and a RPC server, the client needs to define
a reply queue in the message which is then used by the RPC server to send the reply. The name of this queue is
stored in the reply-to message header. As creating queues is a quite expensive operation, there is a way for the
RPC server to send the answer without a custom queue.
Direct Reply-To eliminates the need for a reply queue. This benefits the request-reply implementations with short-lived queues and transient responses at the cost of giving up all control over how the responses are stored. With Direct Reply-To, RPC clients will receive replies directly from their RPC server, without going through a reply queue. "Directly" here still means going through the same channel and a RabbitMQ node; there is no direct network connection between RPC client and RPC server processes.
How does the client receive the message with Direct Reply-To?
Client-side:
amq.rabbitmq.reply-to in no-ack mode.reply-to property in their request message to amq.rabbitmq.reply-to.Server:
"") with the routing key set to this value (i.e. just as if it were sending to a reply queue as
usual). The message will then be sent straight to the client consumer.Can I use Direct Reply-To with AMQP 1.0?
Answer: Yes, with RabbitMQ 4.2, Direct Reply-To support was added for AMQP 1.0, alongside the existing AMQP 0.9.1 implementation.
What where the Limitations of Direct-Reply-To with RabbitMQ 4.1?
Answer: With RabbitMQ 4.1, Reply messages sent using this mechanism were in general not fault-tolerant; they will
be discarded if the client that published the original request subsequently disconnects. The assumption is that an
RPC client will reconnect and submit another request in this case. If the RPC server publishes with the mandatory
flag set then amq.rabbitmq.reply-to.* is not treated as a queue; i.e. if the server only publishes to this name
then the message will be considered "not routed"; a basic.return will be sent if the mandatory flag was set.
For more information, see here.
Very Rarely Used *.cacerts Settings are Removed from rabbitmq.conf
*.cacerts (not to be confused with cacertfile) settings in rabbitmq.conf did not have the expected effect and
were removed to eliminate confusion.
Scope and Recommendation
By default, a9s Messaging does not use the *.cacerts setting in rabbitmq.conf and it is also not possible to
activate this setting using the a9s Messaging SPI. Therefore, customers of anynines are not affected by this
change.
Quorum Queue Metric Changes
Metrics emitted for Ra-based components (quorum queues, Khepri, Stream Coordinator) have changed. Some metrics were
removed, many were added, some changed their names. Users relying on Prometheus metrics starting with
rabbitmq_raft or rabbitmq_detailed_raft will need to update their dashboards and/or alerts.
If the RabbitMQ-Quorum-Queues-Raft dashboard
is used, please update it to the latest version for RabbitMQ 4.2 compatibility.
Scope and Recommendation
This change only affects metrics that are emitted for observability purposes.
When metrics are collected and dashboards or alerts created based on them (i.e. with a9s Prometheus), then it should be checked if any metrics that are not supported anymore are used. A list of all supported metrics can be found here.
Frequently Asked Questions
What are Ra-based components?
Answer: RabbitMQ Ra-based components refer to the elements within RabbitMQ that leverage the Ra library (a robust implementation of the Raft consensus algorithm) to provide distributed, fault-tolerant state machines for highly available messaging features such as quorum queues, stream queues, and metadata storage. More information is available here.
For more detailed information, see the official RabbitMQ 4.2 release notes.
a9s Redis®: Deprecation: Prepare for the upcoming deprecation, planned for the release v70.0.0 (expected end of February 2026):
The whole Data Service will be discontinued and no new versions will be released for it. Please ensure that you organize the migration of your existing Service Instances to the supported a9s KeyValue Data Service:
Existing a9s Redis® Service Instances can be migrated to a9s KeyValue by forking them using the Disaster Recovery feature, or by applying manual migration steps. For more information about the available migration options, please see the Forking and Migration documentation page.
The deprecation phase is planned to last until v73.0.0 (expected end of May 2026). With this release, the unsupport phase of the deprecated Data Service will start. The creation of new a9s Data Service Instances for the a9s Redis® Data Service will be disabled by default in the a9s Data Service Bundle, when the unsupport occurs in v76.0.0 (expected end of August 2026) and we will not provide regular support for this Data Service. The corresponding documentation will also be removed. Therefore, we strongly recommend that you start your migration to a supported Data Service as soon as possible and complete it until the end of the deprecation phase. For more information see a9s Platform Operator Sunrise Sunset.
PATCH /v1/instances/:instance_id/broker/edit in order to allow
Application Developers to more easily block or forbid Maintenance (aka Automatic) Updates. For more information, see
API V1 Endpoints - Update Instance Settings.GET /v2/service_bindings/:binding_id following the
specifications set in OSBAPI specification - Fetching a Service Binding.pg_squeeze extension for a9s PostgreSQL 15 and a9s PostgreSQL 17. For more
information, see Metrics - pg_squeeze Requirements and Usage.pg_squeeze extension using custom parameters, and set the fn_squeezer
function, allowing binding users to use the extension.pg_squeeze to the list of available PostgreSQL extensions and describe its required
parameters, usage and limitations. For more information, see Service Instance Metrics - Available Extensions.
and Migration Matrix.anynines_service_broker.service_broker.redact_parameters. For more information, see
a9s Service Broker - Properties.service-dashboard BOSH Instance Group to public-api.
This reflects the refactoring of a9s Dashboard API, a9s DS API Gateway, and a9s SSO Proxy into a9s Public API.backup_id and backup_guid parameters on the
"Forking a Service Instance" documentation. For more information, see
Forking a Service Instance - Retrieving the Wanted Backup's ID.automatic reload feature. For more information, see Automatic Reload.service-dashboard to public-api. For more
information, see Required Ports.1.926 for internal tests of all supported services.prometheus2:
prometheus-legacy:
promgraf2:
Browser Compatibility section from the
a9s Service Dashboard Considerations documentation page.restored_from time of Disaster Recovery restores to use the time when
source backup file was last modified.min_wal_size and max_wal_size to their original default value, 80MB and
1GB, respectively. The default values of the parameters are being reverted, so that smaller plans do not consume more
resources than necessary during data manipulation processes.max_replication_slots custom parameter, and clarify its
description. Update the documented default value of max_replication_slots to 0, as the previous value was
incorrectly stated in the documentation. For more information, see max_replication_slots.modifiable value of the custom parameters
repl-backlog-size, min-replicas-to-write, and min-replicas-max-lag. For more information, see
a9s KeyValue SPI Configuration.java_maxmetaspace custom parameter.
For more information, see a9s LogMe2 SPI Configuration.modifiable value of the databases custom parameter. For
more information, see a9s MariaDB SPI Configuration.GET /v2/service_instances/:instance_id following the
specifications set in OSBAPI specification - Fetch a Service Instance.
This endpoint is used to retrieve the configuration parameters of a Service Instance that have been set or changed by
the Application Developer, via the Cloud Foundry CLI. This feature is currently available only for a9s PostgreSQL.0 B and why this does not indicate a failure of the backup process.
For more information, see a9s Search - Backups and Restores.backup-service-without-backup-monit.yml
and enable-backup-manager-audit-logs.yml to use the latest a9s
Logstash 8 version. The variable audit_endpoints must be adapted to comply with the new format that is described in
the Audit Logs documentation page.enable-service-broker-audit-logs.yml to
use the a9s Logstash 8 version. The variable audit_endpoints must be adapted to comply with the new format that is
described in the Audit Logs documentation page.instances_retrievable in the a9s Service Broker catalog for all Service
Offerings.global_syslog_endpoints
parameter. For more information, see Template Uploader Errand.1.906 for internal tests of all supported services.a9s Messaging: End of Support: Terminate support for the following deprecated a9s Data Service versions:
The creation of new a9s Data Service Instances for these deprecated versions is now disabled by default in the a9s Data Service Bundle and we no longer provide regular support for these versions. The corresponding documentation has been removed.
Although we will not intentionally break running Service Instances of these unsupported versions, it cannot be guaranteed that they still work as expected after an update to this release.
host:port format. Any other forms, such as username:password@host:port, will be rejected. For more
information, see Set Up Monitoring.Open.Source.Disclosure.File.txt file has been fixed to only include the correct BSD3 licence for
Redis®.Started At column to the backup panel to help with the visualization of
backups, by showing when the actual backup process started.started_at timestamp to backups to show when the actual backup process
started.maxmemory, repl-backlog-size, min-replicas-to-write and
min-replicas-max-lag for fine-tuning of the Service Instances.started_at timestamp to backup objects. For more information, see
a9s Public API - API V1 Endpoints.maxmemory,
repl-backlog-size, min-replicas-to-write and min-replicas-max-lag. For more information, see
a9s KeyValue - Custom Parameters.maxmemory,
repl-backlog-size, min-replicas-to-write and min-replicas-max-lag. For more information, see SPI Configuration.ops/forbid-automatic-update-of-service-instance.yml to match the current
configuration of the dashboard-app.backup_services_iam_vm_extension from CredHub in the corresponding Ops Files.vm_extension_name to the more specific name
backup_services_iam_vm_extension in the documentation. For more information, see Using AWS Instance Profiles.backup_services_iam_vm_extension from CredHub in the related Ops Files. For more information, see
Using AWS Instance Profiles.1.894 for internal tests of all supported services.last_update_day_limit parameter in the /v2/instances endpoint of
the a9s Service Broker API.a9s PostgreSQL: Deprecation: Prepare for the upcoming deprecation phase, planned for the release v67.0.0 (expected end of November 2025), of the following a9s Data Service version:
Please ensure that you organize the migration of your existing instances to a more up-to-date version of the same a9s Data Service:
The deprecation phase is planned to last until v70.0.0 (expected end of February 2026), in which the deprecated version will become unsupported. The creation of new a9s Data Service instances for this particular version will then be disabled by default in the a9s Data Service Bundle and we will not provide regular support for this version. The corresponding documentation will also be removed. Therefore, we strongly recommend that you start your migration to a supported GA version as soon as possible and complete it until the end of the deprecation phase. For more information see a9s Platform Operator Sunrise Sunset.
To inquire about extended support for a deprecated version, please get in contact with our sales department at sales@anynines.com.
bin/rotate_ca_certificate.rb to handle the interactions with CredHub in each step
during the CA rotation. For more information, see Certificate Rotation - CA Certificate Rotation.a9s_private_components_ca CA to simplify the CA certificate rotation via the bin/rotate_ca_certificate.rb script.
For more information, see Certificate Rotation - CA Certificate Rotation.service-smoke-tests.service.graphite_timeout to make the
timeout interval for the graphite logs configurable. This addresses the case where streaming the system metrics, under
the heavy load of the smoke-tests, would exceed the default graphite timeout, causing the tests to fail.
For more information, see General Smoke Tests Properties.custom_roles that allows the user to apply additional roles
like clusterMonitor to the service-keys and service-bindings. For more information, see
a9s MongoDB - Custom Parameters.custom_roles parameter to apply custom roles
to service-keys and service-bindings. For more information, see a9s MongoDB - Custom Parameters.custom_roles parameter. For more information, see
a9s MongoDB - SPI Configurationservice-smoke-tests.service.graphite_timeout property for graphite
logs to the documentation. For more information, see General Smoke Tests Properties.migrate-deployer-encrypted-database-fields errand needs to be run for each Data Service.migrate-deployer-encrypted-database-fields is now part of the deployer-api instance group and
therefore its dedicated instance group has been removed.migrate-deployer-encrypted-database-fields errand needs to be run for each Data Service.migrate-deployer-encrypted-database-fields is now part of the deployer-api instance group and
therefore its dedicated instance group has been removed.migrate-deployer-encrypted-database-fields errand needs to be run for each Data Service.migrate-deployer-encrypted-database-fields is now part of the deployer-api instance group and
therefore its dedicated instance group has been removed.pre-start logic to improve the upgrade and the bootstraping of a new cluster.1.866 for internal tests of all supported services.4-26.4.22.4-26.4.22.breaking change all services: Ubuntu Bionic stemcell: End of Support: Terminate support for the following deprecated stemcell version:
We no longer provide support for this stemcell. The corresponding documentation has been removed. We strongly recommend migrating to a newer stemcell (Ubuntu Jammy).
Although we will not intentionally break running Service Instances using this stemcell, it cannot be guaranteed that they still work as expected after an update to this release.
cf_billing_api_password password is set by using a BOSH variable as a credential
property instead of dynamically generating it, to reduce the time it takes to deploy.migrate_manual_dump_restore.rb script and add missing
information in the a9s KeyValue migration documentation. For more information, see Service Instance Migration.migrate_manual_dump_restore.rb script and add missing
information in the a9s Redis migration documentation. For more information, see Service Instance Migration.