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

update version tag

v1.4.0-rc5

update version tag

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.