v1.5.0

What's new in Percona Everest 1.5.0

Warning

Google Container Registry (GCR) Deprecation
Google Container Registry (GCR) is scheduled to be deprecated and will officially shut down on March 18, 2025. All versions of Percona Everest prior to 1.4.0 depend on images hosted on GCR, meaning that downloading those images will fail after the shutdown date.
Action required
We strongly recommend upgrading to Percona Everest version 1.4.0 or higher as soon as possible. If you do not upgrade, Percona Everest will no longer function.
For more details, refer to the Container Registry Deprecation documentation.

➡️ New to Percona Everest? Get started with our Quickstart Guide.

🔑 Updates at a glance

#	Release summary	Description
1.	Role-based access control (RBAC) Generally Available (GA)	RBAC is now GA with Percona Everest 1.5.0
2.	RBAC: Integration with IdP groups	Assign RBAC policies to user groups obtained from an external IdP
3.	Operators support	Support for PXC operator 1.16.1 and PSMDB operator 1.19.1
4.	New features	Check out the new features introduced in Percona Everest 1.5.0
5.	Improvements	Discover all the enhancements featured in Percona Everest 1.5.0
6.	Bugs	Find out about all the bugs fixed in Percona Everest 1.5.0
7.	Known limitations	Discover all the known limitations in Percona Everest 1.5.0

Release highlights

Percona Everest: RBAC is now GA

We’re delighted to announce the General Availability of RBAC in Percona Everest 1.5.0.

With RBAC, only authorized individuals can access specific resources or perform certain actions based on their assigned roles. This update introduces:

• Granular access management: Allocate roles with detailed permissions to ensure precise access control.

• Enhanced security: Restrict access to authorized users and teams only.

• Enhanced IdP integration: Integrate with your Identity Provider to streamline the authentication process and effectively manage the assignment of user roles.

Streamlining RBAC with enhanced IdP group integration

Starting with Percona Everest 1.5.0, you can now assign RBAC policies to user groups obtained from the external IDP. This enhancement simplifies permissions management for external users without the need for unique sub IDs. To use IdP groups in Percona Everest RBAC, you must set up the groups claim in your IdP provider configuration.

Configure your Identity Provider (IdP) to provide the user's groups claim by following our documentation

To retrieve the IdP groups, you need to include the groups scope by specifying the following fields:

everestctl settings oidc configure --issuer-url=http://url.com --client-id=<your-app-client-id> --scopes openid,profile,email,groups

Take a look at the descriptions of the various fields in the table below:

Field	Description
openid	Grants access to the user’s identity, which is necessary for OIDC flows to issue an ID token with a unique identifier (subject sub).
profile	Grants access to basic profile information.
email	Grants access to the user’s email address and its verification status.
groups	Grants access to obtain information about the user’s group memberships.

🔍 To explore further, dive into our documentation.

Support for PSMDB 1.19.1 and PXC 1.16.1

Starting with Percona Everest 1.5.0, we are thrilled to announce that we have added support for PSMDB Operator v1.19.1 and PXC Operator v1.16.1.

New features

• EVEREST-1799: Starting with Percona Everest 1.5.0, you can now assign RBAC policies to user groups obtained from an external IDP. This change simplifies permissions management for external users without the need for unique sub IDs.

• EVEREST-1547: After performing an Everest upgrade, you will now receive a notification indicating that the upgrade has been completed. You can then access all the new features by clicking the Reload button.

• EVEREST-1549: We have added support for PXC operator v1.16.1.

• EVEREST-1884: We have added support for PSMDB operator v1.19.1.

• EVEREST-689: We have added a new option to hide and unhide the password in the password form field on the login page.

Improvements

• EVEREST-970: Our default backup schedule has been updated from Hourly to Daily, starting at 1:00 AM.

• EVEREST-1796: You can now see a more precise and informative message on the Backups & PITR widget if no active schedules exist.

• EVEREST-1579: We have enhanced the shard Topology by modifying the label from Nodes to Nodes per shard. This change provides greater clarity on the distribution of nodes across each shard. Additionally, we now display the total number of nodes within the Database summary panel, giving you a more complete and insightful overview of your database.

• EVEREST-1612:
  The everestctl version command has been updated to provide information about the version of the Everest server currently installed on your system, if applicable. This enhancement enables you to quickly verify the server version that is in use.

• EVEREST-1788,
  EVEREST-1790: The everestctl namespaces remove, and everestctl namespaces update commands now show a help message that guides you on how to use them.

• EVEREST-1794: We have improved the description of the help text for the --keep-namespace flag in the everestctl namespaces remove command. Previously, the flag did not clearly explain that it retains the namespace in Kubernetes while only removing everest-managed resources, which led to confusion.

• EVEREST-1795: When attempting to update a namespace using everestctl that was created with kubectl (not managed by Percona Everest), the error message was unclear. It did not provide actionable steps for the user to resolve the issue. We have improved the error message to give more insights into the issue.

• EVEREST-1190: You can now easily find out which account you’re using to log into Everest by clicking the Profile button. This button shows the user's name or email address used to log into Percona Everest.

Bugs

• EVEREST-1261: We fixed an issue where a user who had already added a backup storage location received an incorrect error message when trying to add another one with the same bucket name and URL.

• EVEREST-1401:
  Now, when you create/edit the database cluster with sharding enabled for PSMDB, it will display the correct resources required for the specified number of shards.

• EVEREST-1537:
  We have resolved an issue that caused Percona Everest uninstallation to fail when attempting to delete database clusters due to a timeout.

• EVEREST-1581: The database remained in a Deleting state despite all components being deleted. The issue has now been resolved.

• EVEREST-1588: We have fixed an issue where the PostgreSQL database was stuck in an initializing state after a restore.

• EVEREST-1589: We have fixed an issue in which the MySQL database remained stuck in an initializing state for a 1-node cluster.

• EVEREST-1647: Creating a monthly schedule on day 1 at 12:00 AM (the default option when choosing Monthly) led to an error for PSMDB. The issue has been resolved now.

• EVEREST-1674: The message **Enforce did ...

v1.4.0

What's new in Percona Everest 1.4.0

Warning

Google Container Registry (GCR) is scheduled to be deprecated and will officially shut down on March 18, 2025. All versions of Percona Everest prior to 1.4.0 depend on images hosted on GCR, meaning that downloading those images will fail after the shutdown date. We strongly recommend upgrading to Percona Everest version 1.4.0 as soon as possible. If you do not upgrade, Percona Everest will no longer function.

For more details, refer to the Container Registry Deprecation documentation.

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

Sr. No	Release summary	Description
1.	Helm charts	Simplify your Percona Everest deployments with Helm
2.	Namespace management	Manage your namespaces with new everestctl commands
3.	Improved edit database flow	Manage your namespaces with new everestctl commands
4.	Operators support	Support for Percona Operator for MongoDB v1.18.0 (PSMDB) and Percona Operator for PostgreSQL v2.5.0 (PG)
5.	New features	Check out the new features introduced in Percona Everest 1.4.0
6.	Improvements	Discover all the enhancements featured in Percona Everest 1.4.0
7.	Bugs	Find out about all the bugs fixed in Percona Everest 1.4.0
8.	Known limitations	Discover all the known limitations in Percona Everest 1.4.0

Release highlights

Simplify your Percona Everest deployments with Helm

We are excited to announce the launch of Helm charts in Percona Everest 1.4.0. Helm charts simplify the deployment process by packaging all necessary resources and configurations, making them ideal for automating and managing installations in Kubernetes environments.

Percona Helm charts can be found in percona/percona-helm-chartsrepository in Github.

If you're looking to get started with Percona Everest using Helm, check out our comprehensive documentation.

Additionally, check our Upgrade and Uninstall sections to find out how to upgrade or uninstall your Percona Everest instances using Helm.

Manage your namespaces with new everestctl commands

Namespace management is essential in Percona Everest for efficiently organizing, securing, and allocating resources, particularly in large and complex Kubernetes environments. By leveraging Kubernetes namespaces, Percona Everest achieves logical isolation, enhanced security, and better resource allocation for databases, backups, and monitoring setups.

Starting with Percona Everest 1.4.0, we have introduced new everestctl commands to manage your namespaces. These commands enable you to:

• Add new namespaces
• Update existing namespaces
• Delete any used namespaces

For a deep dive into managing namespaces for provisioning DB namespaces in Percona Everest, refer to our documentation.

Removal of the Edit DB Wizard for an enhanced User Experience

Starting with Percona Everest 1.4.0, we have removed the Edit DB wizard to provide a more streamlined user experience. You can now edit specific fields directly from the DB Overview page using our new editable widgets, eliminating the need to navigate through the entire Edit DB wizard.

Let's assume you want to make changes to Point-in-time-Recovery (PITR). First, navigate to the specific database. Then, go to Overview > Point-in-time-Recovery (PITR) and click Edit. Make the necessary changes and click Save.

Support for PSMDB 1.18.0 and PG 2.5.0

Starting with Percona Everest 1.4.0, we are thrilled to announce that we have added support for PSMDB Operator v1.18.0 and PG operator v2.5.0.

New features

• EVEREST-1511: We have introduced Helm charts, which simplify the Percona Everest deployment process by packaging all necessary resources and configurations. These charts are ideal for automating and managing installations in Kubernetes environments.

• EVEREST-1512: You can now seamlessly upgrade your Percona Everest installation using Helm, a package manager for Kubernetes. This streamlined process simplifies the upgrade experience.

• EVEREST-1673: Starting with Percona Everest 1.4.0, we have introduced new everestctl commands to manage your namespaces.

• EVEREST-908: Starting with Percona Everest 1.4.0, the Overview page now includes the Connection URL in the Connection Details widget, allowing you to copy it directly.

• EVEREST-1599: We have added support for PostgreSQL operator v2.5.0.

• EVEREST-1624: We have added support for PSMDB Operator v1.18.0.

Improvements

• EVEREST-1065: Starting with Percona Everest 1.4.0, we have removed the Edit button from the database list actions. This change provides a more streamlined user experience, allowing you to edit the database directly from the database Overview page without having to go through the entire edit wizard.

• EVEREST-1066: We have improved the Backups & PITR widget on the database Overview page. With this enhancement, you can now directly enable or disable PITR by clicking Edit from this page.

• EVEREST-1210: The Advanced Configuration panel on the DB Details widget is now more user-friendly than ever. You can edit or enable parameters directly from the database Overview page. Just click Edit, and and make your changes with ease.

• EVEREST-1304: We have simplified the create database wizard. When you click Create Database, a menu with the MySQL, PostgreSQL, and MongoDB options will appear under the button. After selecting a database type, you will be guided to the wizard with the chosen value pre-set.

• EVEREST-1546: You can see the number of proxies, routers, and bouncers, along with their resources, directly on the Database Summary and Overview pages. This enhancement provides greater visibility into the resources within your clusters.

• EVEREST-1683: The Backups on the Overview page are organized in descending order, making it easier to find your most recent backups by their start date and time.

• EVEREST-1686: We've adopted a 24-hour time format for our backups and restores to eliminate any potential confusion and ensure consistency across Percona Everest.

• EVEREST-1687: The label for the upgrade CRD button has been shortened to improve readability.

• EVEREST-1701: Starting with Percona Everest 1.4.0, when configuring RBAC policies, the resource name for database-cluster-backups now corresponds to the database name instead of the backup name. This change allows for a more intuitive configuration of permissions for backups at the database level.

• EVEREST-1702: Starting with Percona Everest 1.4.0, when configuring RBAC policies, the resource name for database-cluster-restores now corresponds to the database name instead of the restore name. This change allows for a more intuitive configuration of permissions for backups at the database level.

Bugs

• EVEREST-1688: If a user changed the value for the number of shards and ...

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...

v0.10.1

Fixed issues

Backups

• EVEREST-1061 - We fixed a race condition in the Everest operator where backups deleted due to retention policies were re-created. We fixed the issue and ensured that completed backups were not reconciled.
• EVEREST-1064 - While configuring a backup schedule for the MongoDB cluster, duplicate backups of the same data were generated in S3, whereas only a single backup was produced in Everest. The issue has been resolved now.

Restores

• EVEREST-1082 - Attempting to restore a MongoDB backup to a new database failed if the backup storage used a self-signed certificate. This issue has been resolved now.

• EVEREST-1054 - While restoring a PostgreSQL database cluster, we encountered an issue connecting to an S3-compatible bucket with a self-signed certificate. This problem caused the restored cluster to become unresponsive and enter an unknown state. The issue has been resolved now.

Retention copies

• EVEREST-979 - When the retention were specified in a backup schedule, the Everest operator successfully deleted the backup objects from Kubernetes. However, it failed to clean up the data on S3. This issue has been resolved now.

Known limitations

Backups for PostgreSQL do not work with GCP S3 compatible API.

v0.10.0

Release highlights

Simplified Percona Everest upgrades

Warning

• You need to download CLI version >=0.10.0 for the upgrade command to work.
• Upgrade works only if you have Percona Everest version 0.9.0 or higher installed.

We're thrilled to announce that you can now upgrade your Percona Everest instance using our Command Line Interface (CLI). The CLI upgrade process is simple and straightforward, enabling you to quickly upgrade your Everest to the latest version.

You can only upgrade one minor version at a time. For instance, you can upgrade from version 0.9.0 to version 0.10.0.

For more information on upgrading Percona Everest, see our documentation.

Streamlining traffic management with API rate limiting

Starting with Percona Everest 0.10.0 version, we have introduced a new feature called API rate limiting.

API rate limiting is one of the key aspects of managing API's. With this you can set a threshold for the number of requests your API can receive within a specific period. This means you can take control and regulate the incoming traffic, mitigating the risk of server overload or abuse.

The default rate limit for Percona Everest is 100 requests per second. However, you can customize these limits according to your usage patterns and requirements. To dive deep into this feature, see our comprehensive documentation.

Added control for TLS certificate validation

With the release of Percona Everest 0.10.0, you can add backup storages and monitoring instances without verifying the Transport Layer Security (TLS) certificate. TLS certificate verifies the server's certificate chain and hostname, ensuring its authenticity.

When using a self-signed TLS certificate, the TLS certificate validation will fail as the certificate has not been issued by a trusted authority. To overcome this issue, you may need to skip the TLS certificate validation.

Skipping certificate validation is recommended only when there is no need to ensure the authenticity of the server holding the certificate. For example, if you have a private network where you have complete control over everything, the identity check may not be required.

New features and improvements

• EVEREST-793 - Starting with Percona Everest 0.10.0, you can upgrade your Percona Everest instance using the CLI (everestctl).

• EVEREST-396 - You can now add monitoring instances without verifying the TLS certificates.

• EVEREST-964 - Starting with Percona Everest 0.10.0, we have introduced a new feature called API rate limiting. With this you can set a threshold for the number of requests your API can receive within a specific period.

• EVEREST-935 - Previously, the cancel button was disabled while editing anything in the wizard. This button is now enabled.

• EVEREST-928 - We have updated all the labels on the buttons to sentence case for consistency.

• EVEREST-938 - Restoring a database using PITR now includes a backup storage name.

Backups

• EVEREST-895 - You can now add backup storage without verifying the TLS certificates.

• EVEREST-919 - You can now access backup storage with path-style URLs.

• EVEREST-668 - We have introduced Retention copies while creating backup schedules. Retention copies refer to the number of backup instances that should be kept.

• EVEREST-819 - Due to the current limitation of PostgreSQL, you can only create up to 3 schedules. To avoid confusion, we have added a tooltip that states this limitation.

• EVEREST-911 - We added a new column to the database view displaying the time of the last backup.

• EVEREST-912 - We have added an icon and tooltip to the backups column.

Bugs fixed

• EVEREST-385 - Previously, there was an issue where the backup and pods associated with a database cluster were not being deleted when the cluster itself was deleted. The issue has been resolved now.

• EVEREST-846 - Fixed an issue where the new database contained the backups of the old database with the same name.

• EVEREST-921 - We have resolved an issue that prevented users from logging in immediately after logging out.

• EVEREST-947 - While attempting to uninstall Percona Everest, an error occurred which prevented the uninstallation process from completing successfully. The issue has now been resolved.

• EVEREST-948 - The actionable Alert button was not visible in the dark theme. The issue has been resolved now.

• EVEREST-967 - Fixed an issue where the last backup information was inaccurate.

• EVEREST-940 - The documentation link on Point-in-time recovery option for PostgreSQL was opening in the same tab. The issue has been resolved now.