v1.4.0-rc4

update version tag

v1.4.0-rc3

update version tag

v1.4.0-rc2

update version tag

v1.4.0-rc1

update version tag

v1.3.0

What's new in Percona Everest 1.3.0

To begin your journey with Percona Everest, check out the Quickstart Guide for Percona Everest.

Release summary

Sr. No	Release summary	Description
1.	Configure proxy nodes	Configure proxy nodes and define their resource limits
2.	MongoDB Sharding	Introducing sharding in Percona Everest: Optimize your MongoDB databases with sharding
3.	Database status	Check your database status from the database details page
4.	PSMDB Operator v1.17.0 support	Support for PSMDB Operator v1.17.0 in Percona Everest
4.	New features	Check out the new features introduced in Percona Everest 1.3.0
5.	Improvements	Discover all the enhancements featured in Percona Everest 1.3.0
6.	Deprecated APIs	Discover all the Deprecated APIs from Percona Everest 1.3.0
7.	Bugs	Find out about all the bugs fixed in Percona Everest 1.3.0
8.	Known limitations	Discover all the known limitations in Percona Everest 1.3.0

Release highlights

Capability to configure proxy nodes and define their resource limits

Starting with Percona Everest 1.3.0, we have introduced a new feature that permits you to customize the number of proxies and their resources, including the allocation of CPU and RAM for each proxy. This feature mirrors the existing capability to customize the number of database engine replicas and allocate resources to them.

With this feature, you now have more flexibility to customize the resources allocated to proxies according to your needs, thus providing more control over your Percona Everest deployments.

Optimize MongoDB with sharding in Percona Everest

Warning

Sharding is currently in Technical Preview. Early adopters are advised to use this feature only for testing purposes and not in production environments.
Check out the known limitations section for important information about the limitations of sharding.
If you reshard or unshard a collection, create a new backup to avoid data inconsistency and restore failure.

We're excited to announce that we've achieved another milestone with the implementation of MongoDB sharding in Percona Everest 1.3.0. You can now harness the benefits of sharding for your MongoDB databases with Percona Everest.

Sharding is used for horizontal database scaling. It distributes a database horizontally across multiple nodes or servers, known as shards. Each shard manages a portion of the data, forming a sharded cluster, which enables MongoDB to handle large datasets and high user concurrency effectively.

The key components of MongoDB sharding are:

• Shard: Each shard has a subset of the data.
• Mongos: The query router directs the client queries to the proper shard(s)
• Config servers: The configuration servers store the cluster's metadata and configuration settings.

Here's how you can enable sharding:

On the Create Database wizard, select MongoDB database and turn on the Sharded Cluster toggle.

If you're looking to dive deeper into MongoDB sharding, check out the documentation.

Database status at a glance

Starting with Percona Everest version 1.3.0, you can now quickly monitor the status of your databases right from the database details page for your specific database. This feature saves you time by enabling you to keep an eye on your databases without having to switch to the database view page.

Support for PSMDB Operator v1.17.0

Starting with Percona Everest 1.3.0, we are thrilled to announce that we have added support for PSMDB Operator v1.17.0.

New features

• EVEREST-1303: We have introduced MongoDB sharding in Percona Everest 1.3.0. Now, you can leverage sharding for your MongoDB databases with Percona Everest.

• EVEREST-777: Previously, you could only customize the database engine replicas and their resources. Now, you have the ability to customize the number of proxy replicas and their resources, including CPU and RAM, during the database creation.

• EVEREST-1310: Previously, you could only customize the database engine replicas and their resources. Now, you have the ability to customize the number of proxy replicas and their resources, including CPU and RAM, while editing the database.

• EVEREST-1239: Starting with Percona Everest, we’ve added support for PSMDB Operator v1.17.0.

Improvements

• EVEREST-1006 - You can now view your database status right from the database details page.

• EVEREST-1208 - You can upgrade the database version directly from the Overview page. However, the Upgrade option will only be visible if you have the necessary permissions. When you click Upgrade, a pop-up will appear, prompting you to select the version of the database to which you want to upgrade.

• EVEREST-1211 - You can now easily edit your resources directly from the Overview page. There’s no longer a need to navigate the entire database wizard, saving you time and simplifying the process.

• EVEREST-1459 - We have added a link to Percona Support on the Percona Everest home page, making it easier for you to contact support if needed.

• EVEREST-1460 - To make your experience with Percona Everest even smoother, we've added convenient links right on the login page. Discover everything from Support and a Quickstart guide to our Forum, the K8s Squad program, and our GitHub repository.

• EVEREST-1470 - The rbac validate command has been enhanced to accept the ConfigMap YAML file. This enables you to validate role-based access control (RBAC) configurations by leveraging the structured data provided in a ConfigMap format.

• EVEREST-1533 - Users with read-only permissions for a namespace, including all database engines and database clusters within that namespace, currently cannot access the Upgrade option in the user interface. This restriction prevents them from viewing upgrade prerequisites, such as the versions of database clusters that may need to be upgraded.

  However, starting with Percona Everest 1.3.0, the Upgrade button is clickable for these users. This enables them to view details about the upgrade plan, including any necessary changes for the database clusters, which can help inform administrators about required preparations. However, the option to upgrade the operator remains unclickable for users without the upgrade permissions.

Deprecated API endpoints

This is the list of the API endpoints deprecated in Percona Everest v1.2.0 and removed from v1.3.0:

No	API endpoints	Method
a.	/monitoring-instances	1.GET 2.POST
b.	/monitoring-instances/{name}	1.GET 2. PATCH 3.DELETE
c.	/backup-storages	1.GET 2.POST
d.	/backup-storages/{name}	1.GET 2. PATCH 3.DELETE

Bugs

• EVEREST-1187 - When creating a PostgreSQL database, if backup schedules were not created initially but added later after the database was created, Point-in-Time Recovery (PITR) was disabled. We have now resolved the issue, and PITR has now been enabled.

• EVEREST-1266 - On the Components page, the Pod icon now shows the correct color: green if the status is Running and all containers are ready and yellow if the status is Running while some containers are not ready.

• EVEREST-1384 - The Overview page now displays resources more clearly for an enhanced UI.

• EVEREST-1390 - We’ve addressed an issue that caused the Components page to get stuck in a loop, refreshing endlessly whenever a database was suspended.

• EVEREST-1398 - The time format is now unified across all backups and restores, ensuring consistency and clarity.

• [EVEREST-1399](htt...

v1.2.0

What's new in Percona Everest 1.2.0

To begin your journey with Percona Everest, check out the Quickstart Guide for Percona Everest.

Warning

Percona Everest v1.2.0 introduces breaking changes to the API. Once you upgrade to version 1.2.0, the process cannot be reversed.

Release summary

Sr. No	Release summary	Description
1.	Role-based access control (RBAC)	Introducing RBAC in Percona Everest: Ensure security and simplify database access management
2.	Breaking API changes	Percona Everest v1.2.0: A deep dive into Breaking API changes
3.	Operator upgrades	Improved multiple operator upgrades
4.	New features	Check out the new features introduced in Percona Everest 1.2.0
5.	Improvements	Discover all the enhancements featured in Percona Everest 1.2.0
6.	New and deprecated API's	Discover all the new APIs that have been added to Percona Everest 1.2.0, as well as any deprecated APIs
7.	Bugs	Find out about all the bugs fixed in Percona Everest 1.2.0
8.	Known limitations	Discover all the known limitations in Percona Everest 1.2.0

Release highlights

Percona Everest 1.2.0: A deep dive into Breaking API changes

Beginning with Percona Everest v1.2.0, breaking changes are being introduced to the API for monitoring-instances and backup-storages resources. These updates include:

• Before the launch of Percona Everest 1.2.0, the resources monitoring-instances and backup-storages had a global scope. Percona Everest used a .spec.allowedNamespaces field to control access to these global resources. This field defined the namespaces where the resources could be accessed, thus providing some degree of access control.

• With the upgrade to Percona Everest version 1.2.0, the transition from global scope to the designated namespaces for these resources is an important change in the way access control is managed. This improves security as the resources are only accessible within their designated namespaces. The database clusters can only use monitoring-instances and backup-storages located within the same namespace as the cluster.

• When upgrading to 1.2.0 using the CLI command everestctl upgrade, all your existing backup-storages and monitoring-instances will be automatically migrated to the namespaces specified in their .spec.allowedNamespaces fields.

Note

After the upgrade to Percona Everest 1.2.0, you will only be able to access these resources through the new API endpoints.

Check out our documentation for in-depth details on the Breaking API changes.

Introducing RBAC in Percona Everest: Ensure security and simplify database access management

Warning

• RBAC is currently in Technical Preview. Early adopters are advised to use this feature only for testing purposes and not in production environments.
• Check out the known limitations section for important information about the limitations of RBAC.

Starting with Percona Everest 1.2.0, we’ve enhanced our platform by introducing Role-Based Access Control (RBAC), which regulates resource access for better management and security.

With RBAC, only authorized individuals can access specific resources or perform certain actions based on their assigned roles. This method improves security by minimizing the risk of unauthorized access and helps manage permissions more efficiently across Percona Everest.

To enable or disable RBAC in Percona Everest, you can use a configuration flag that allows switching between RBAC-enabled and RBAC-disabled modes. By default, RBAC is disabled.

Here's a breakdown of the key concepts in RBAC:

• Roles - Roles are a set of permissions that allow users to access and carry out various tasks within Percona Everest.

• RBAC resources and privileges: Resources are the entities or objects within Percona Everest that require controlled access. Privileges specify the particular actions that a role is able to perform on a resource.

• Policy definition: RBAC policies are the rules and guidelines that define how roles, permissions, and users are managed within RBAC.

The policy definition in Percona Everest is:

    p, <subject>, <resource-type>, <action>, <resource-name>

• Role assignment: Assigning specific roles to individual users within Percona Everest is crucial for the roles to be effective.

The syntax for assigning a role is as follows:

    g, username, rolename

Explore our comprehensive documentation for everything you need to know about RBAC.

Improved multiple operator upgrades

Starting with Percona Everest 1.2.0, it's important to note that due to limitations with the Operator Lifecycle Manager (OLM), it is now required to upgrade all database operators concurrently with their components across any namespace. The upgrade process can be accomplished using our intuitive UI.
Before initiating the upgrade process, Percona Everest provides a comprehensive list of tasks that must be completed to ensure a seamless transition of your clusters to the next version of the database operators.

New features

• EVEREST-1103: Starting with Percona Everest 1.2.0, we've restricted actions based on RBAC roles, ensuring that users are explicitly granted access to the resources required for their specific roles. This enhances security and simplifies access control processes.

• EVEREST-1142: We have now added a new command for validating your RBAC policy to ensure that your RBAC policies are working as expected.

• EVEREST-1240: We have added support for PostgreSQL operator version 2.4.1.

• EVEREST-1298: We have added support for MySQL operator version 1.15.0.

• EVEREST-1035: We've now included Retention copies for PostgreSQL as well when setting up backup schedules.

Improvements

• EVEREST-1165- Due to limitations with the Operator Lifecycle Manager (OLM), it is now required to upgrade all database operators concurrently with their components across any namespace.

• EVEREST-1212 - Starting with Percona Everest 1.2.0, you can now directly edit the monitoring endpoint from the database overview page, instead of having to use the Edit database wizard.

• EVEREST-1230: We've updated the Resources panel on the Database overview page to be independent instead of part of the DB Details panel and improved the overall look and feel of this page.

The latest in APIs: What’s new and what’s deprecated

Newly added API endpoints

Check out the new API endpoints we've added in Percona Everest 1.2.0:

No	API endpoints	Method
1.	/namespaces/{namespace}/monitoring-instances	a.GET b.POST
2.	/namespaces/{namespace}/monitoring-instances/{name}	a.GET b. PATCH c.DELETE
3.	/namespaces/{namespace}/backup-storages	a.GET b. POST
4.	/namespaces/{namespace}/backup-storages/{name}	a.GET b.POST
5.	/permissions	a.GET

Deprecated API endpoints

This is the list of the API endpoints deprecated from Percona Everest:

No	API endpoints	Method
1.	Endpoints deprecated in Percona Everest v1.1.0 and removed in v1.2.0:
a.	/namespaces/{namespace}/database-engines/{name}/operator-version/preflight	1.GET
b.	/namespaces/{namespace}/database-engines/{name}/operator-version	1.GET 2.PUT
2.	Endpoints deprecated in v1.2.0:
c.	/monitoring-instances	1.GET 2.POST
d.	/monitoring-instances/{name}	1.GET 2. PATCH 3.DELETE
e.	/backup-storages	1.GET 2.POST
f.	/backup-storages/{name}	1....

v1.1.1

Upgrade instructions

Warning

If you are using everestctl v1.1.1 to upgrade from a version prior to v1.0.0 you need to run the following command before upgrading:

kubectl get deployments everest-operator-controller-manager -n everest-system -o jsonpath='{.spec.template.spec.containers[?(@.name=="manager")].env[?(@.name=="DB_NAMESPACES")].value}' | xargs -d ',' -I {} kubectl label namespaces {} app.kubernetes.io/managed-by=everest

Release highlights

Important

Percona Everest 1.1.1 comes with its own set of limitations that you should be aware of (see the Known Limitations section below).

Fixed issues

• EVEREST-1349 - While attempting to delete a database cluster after upgrading from Percona Everest version 1.0.x to 1.1.0, the databases provisioned in v1.0.x were stuck in the Deleting state. The issue has been resolved now.

Known limitations

You can't use the same URL, bucket, and region in two different backup storages. Doing so may cause issues with restoring from the existing backups.

Here’s what you need to know:

Scenario 1

If you have multiple storages with the same bucket, URL, and region, you won’t be able to edit them after the 1.1.1 update. You’ll need to delete the duplicates.

To check whether your existing Everest installation has any backup storages using the same bucket, region, and endpoint URL, execute the following command:

curl -sS "https://raw.githubusercontent.com/percona/everest-doc/main/tools/bin/check-duplicated-storages.sh" | bash

Scenario 2

What to do if you have schedules or backups that are using duplicated storages in different database technologies.

• MongoDB, MySQL: create a new backup using a different backup storage. Then, delete the old schedules and backups that use the duplicated storage.
• PG: Any backups using duplicated backup storages should be deleted. First, delete the backups from both backup storages, then delete the backup schedules, and finally, delete the backup storages themselves. Then, create a new backup storage and take backups using the new backup storage.

v1.1.0

Upgrade instructions

Warning

If you are using everestctl v1.1.0 to upgrade from a version prior to v1.0.0 you need to run the following command before upgrading:

kubectl get deployments everest-operator-controller-manager -n everest-system -o jsonpath='{.spec.template.spec.containers[?(@.name=="manager")].env[?(@.name=="DB_NAMESPACES")].value}' | xargs -d ',' -I {} kubectl label namespaces {} app.kubernetes.io/managed-by=everest

Release highlights

Important

Percona Everest 1.1.0 comes with its own set of limitations that you should be aware of (see the Known Limitations section below).

Enhancements for PostgreSQL disaster recovery

We've made our backups and restores more reliable by setting limits on how we manage backup storage. This proactive approach ensures that we can prevent potential issues from being triggered in edge-case scenarios.

Here's how it works:

• You can have up to three backup storages in use at a time, across both on-demand backups and schedules.

  Example:
  If you already have two scheduled backups using storage bucket-1 and bucket-2, and an on-demand backup using bucket-3, you’ll need to use one of these three storages for any new on-demand backup or schedule.

  

  

  

• You can only create up to three backup schedules for PostgreSQL.

  

• You cannot change the storage location in existing schedules.

• You cannot use the same storage location for multiple backup schedules.

Improvements

• EVEREST-1259 - We've implemented a rate limiter to control how many API requests you can make within a set time frame. If you exceed this limit on the login page, you'll receive an error message.

• EVEREST-1134 --Starting with Percona Everest 1.1.0, you can now upgrade the database version directly from the Namespaces page, skipping the need to use the edit DB wizard.

• EVEREST-1153 - We've improved the CLI experience for install, upgrade, and uninstall commands by streamlining it with concise loading animations and spinners.

• EVEREST-1088 - We've removed the icons from the Technology column in the database list table.

• EVEREST-1196 - We've added a confirmation dialog that appears when you try to exit the wizard using the side navigation.

• EVEREST-1070 - We've updated the restore icon across Percona Everest for a consistent look.

• EVEREST-247 - We've updated the Postgresql database icon on the UI for better clarity and visibility.

Backups and schedules

• EVEREST-1092 - Starting with Percona Everest 1.1.0, you can no longer initiate an on-demand backup while another backup is in progress. This change helps maintain data integrity and minimizes potential impact on database performance.

• EVEREST-1220 - In Percona Everest 1.1.0, you're limited to using a maximum of three different backup storages for PostgreSQL, including those used in existing backup schedules. This restriction ensures reliable backup restoration.

• EVEREST-1071- We've introduced a Deleting state that remains active until all resources associated with the backup are fully removed.

• EVEREST-1214 - We've made it easier to manage backup schedules by removing the restriction on deleting PostgreSQL schedules.

• EVEREST-1223 - Starting with Percona Everest 1.1.0, you cannot edit the region and bucket for the existing backup storage.

• EVEREST-1226 - Starting with Percona Everest 1.1.0, you cannot create backup storages with the same bucket, region, and URL.

• EVEREST-1229 - For a better user experience, you can now see which backup storage is being used for both on-demand backups and schedules.

• EVEREST-910 - The schedule name and storage location for scheduled backups are now displayed on the UI.

Bugs fixed

• EVEREST-1233 - You will now see the correct error message when attempting to downgrade a major database version.

• EVEREST-740 - MySQL is now correctly selected as the default database engine when creating a database, even if it wasn't the first operator installed.

• EVEREST-1181 - The option to upgrade the major version of the database engine for MongoDB and PostgreSQL is now correctly disabled in the database edit section, reflecting the intended functionality.

• EVEREST-859 - The issue causing an error during namespace deletion while uninstalling Percona Everest has been resolved.

• EVEREST-1074 - The backup page performance is now optimized for adding and editing backup.

• EVEREST-1141 - Backup files in the S3 bucket are now properly removed when the corresponding database is deleted.

• EVEREST-1144 - While editing the backup storage in a PostgreSQL database backup schedule, an error was encountered after three backup schedules were created. The issue has been resolved now.

• EVEREST-1050 - The restore page now correctly updates the restore information.

• EVEREST-1244 - While attempting to restore a database, there was a discrepancy between the messages indicating the status of the restoration process and the actual actions being taken by Percona Everest. The issue has been resolved now.

• EVEREST-307 - CLI errors now display more user-friendly messages without exceptions and stack traces.

Known limitations

You can't use the same URL, bucket, and region in two different backup storages. Doing so may cause issues with restoring from the existing backups.

Here’s what you need to know:

Scenario 1

If you have multiple storages with the same bucket, URL, and region, you won’t be able to edit them after the 1.1.0 update. You’ll need to delete the duplicates.

To check whether your existing Everest installation has any backup storages using the same bucket, region, and endpoint URL, execute the following command:

curl -sS "https://raw.githubusercontent.com/percona/everest-doc/main/tools/bin/check-duplicated-storages.sh" | bash

Scenario 2

What to do if you have schedules or backups that are using duplicated storages in different database technologies.

• MongoDB, MySQL: create a new backup using a different backup storage. Then, delete the old schedules and backups that use the duplicated storage.
• PG: Any backups using duplicated backup storages should be deleted. First, delete the backups from both backup storages, then delete the backup schedules, and finally, delete the backup storages themselves. Then, create a new backup storage and take backups using the new backup storage.

v1.0.1

Fixed issues

Telemetry

• EVEREST-1231 - We've addressed an issue that was causing our telemetry to be disabled.

v1.0.0

What's new in Percona Everest 1.0.0

We proudly announce that Percona Everest has officially hit the general availability (GA) milestone with the release of version 1.0.0.

To begin your journey with Percona Everest, check out the Quickstart Guide for Percona Everest.

Percona Everest is an open source cloud native database platform that helps provision and manage databases faster, scale deployments rapidly, and reduce database administration overhead. Plus, you can regain control over your data, database configuration, and DBaaS costs.

Upgrading to Percona Everest 1.0.0

Note

Despite being a major version upgrade, we fully support upgrading from Percona Everest 0.10.1 to 1.0.0.

Check out our comprehensive documentation for all the details on how to upgrade to Percona Everest 1.0.0.

Release highlights

Version 1.0.0 introduces the following changes:

Simplified database operator upgrades

We are excited to announce that you can now upgrade database operators and all their components across any namespace with just a single click using our intuitive UI.

Moreover, before initiating the upgrade process, Everest provides a comprehensive list of tasks that must be completed to ensure a seamless transition of your clusters to the next version of the database operators.

For a deep dive into this feature, see our comprehensive documentation.

User management

Percona Everest 1.0.0 introduces user management features, enabling you to securely log in to the platform through either the Percona Everest user interface or the API. So, get ready for a more secure and user-friendly experience with this update.

Local user management involves administering Percona Everest users to ensure secure access to database resources. This encompasses tasks such as creating and deleting users, updating their passwords, etc.

If you’re looking for in-depth insights into this feature, see our documentation.

IdP integration for enhanced security

Starting with Percona Everest 1.0.0, you can now integrate your Percona Everest instance using an external identity provider (IdP). This enables centralized authentication and authorization management, streamlining and simplifying user access. By tapping into IdP integration, you can ensure that users are authenticated and authorized securely.

Percona Everest uses OpenID Connect (OIDC) Protocol to integrate with external Identity Providers (IdP).

To integrate IdP with Percona Everest, first install Percona Everest and then configure OIDC on the IdP's side as well as the Percona Everest side.

To explore the depths of this feature, delve into our documentation.

All new components page

We're always striving to enhance user experience, and we're excited to announce our latest addition – the Components page! This new page is your go-to destination for in-depth details about the pods and containers, such as their status, type, age, and much more.

New features

• EVEREST-816 - Starting with Percona Everest 1.0.0, you can now upgrade database operators and all their components across any namespace with just a single click using our intuitive UI.

• EVEREST-1087 - You can now integrate your Percona Everest instance using an external identity provider (IdP). This enables centralized authentication and authorization management, streamlining and simplifying user access.

• EVEREST-1025 - We introduced the user management feature with Percona Everest 1.0.0, enabling you to securely log in to the platform through either the user interface or the API.

• EVEREST-974 - Everest now supports editing the DB Engine version after a cluster has been created. However, it's important to note the following restrictions:

  • You are unable to upgrade to a different major version.
  • Downgrading the DB Engine version is not supported.

• EVEREST-1069 - We've recently introduced a new page - the components page. This page provides detailed information about the pods and containers, including their status, type, age, and more.

• EVEREST-866 - Starting with Percona Everest 1.0.0, you can restore your database from a full backup or using the PITR. However, if you choose a backup other than the latest backup, the PITR option becomes unavailable.

• EVEREST-872 - When deleting a backup, you can now choose to delete the data from the backup storage as well.

• EVEREST-873 - When attempting to delete a database, you now have the option to delete the data as well from the backup storage. However, for PostgreSQL databases, the backup storage data is retained.

• EVEREST-731 - Added support for customizing load balancer source ranges in PostgreSQL clusters.

Improvements

• EVEREST-909 - Percona Everest now validates scheduled backups if another backup is already scheduled for the same time and location.

• EVEREST-924 - Starting with Percona Everest 1.0.0, you now have the option to create multiple backup schedules using the wizard.

• EVEREST-931 - When you go through a wizard, return to a specific step, and delete something from a mandatory field, the editing functionality is now disabled.

• EVEREST-1055 - Starting with Percona Everest 1.0.0, we have introduced a new deleting state. This state will persist until all resources associated with the database have been removed.

• EVEREST-953 - For an improved user interface (UI) experience, we have consolidated backups and PITR on the same page.

• EVEREST-971 - Access and secret key inputs are now visible on the UI when adding a storage location. You can use the eye icon to toggle between making the keys visible or hidden. This feature allows you to conveniently view the S3 keys directly from the UI.

• EVEREST-1007 - For an improved user experience, the Actions button has been moved to the Database Details tab on the right side of the database name.

• EVEREST-937 - We have made some improvements in our telemetry, including sending telemetry data about the DB cluster every time a user creates one and adding information about the Everest version reported for the instance ID.

Bugs

• EVEREST-807 - Fixed an issue where PITR did not display the storage location being used when enabling PITR during database creation or editing.

• EVEREST-837 - We have now updated the help for the Command Line Interface (CLI) commands to include the descriptions.

• EVEREST-841 - Fixed an issue where the user interface (UI) could not identify the correct operator/database cluster for different namespaces.

• EVEREST-869 - Fixed an issue where everestctl install failed to revert to the default namespace when the namespace was left blank.

• EVEREST-870 - When running the everestctl install command, the installation wizard asked for values such as namespaces and operators, even though the values were already provided by flags (--namespaces=everest --operator.mongodb=false --operator.postgresql=false --operator.xtradb-cluster=true). The issue has been resolved now.

• EVEREST-1003 - Resolved an issue where the installation of operators in a new namespace was failing.

• EVEREST-1016 - We updated the Last backup status from inactive to scheduled because it was confusing for the users.

• EVEREST-1034 - The Restores page did not display the restores in a sorted order. The issue has been resolved now.

• [EVE...