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

update version tag

v1.3.0-rc4

update version tag

v1.3.0-rc3

update version tag

v1.3.0-rc2

update version tag

v1.3.0-rc1

update version tag

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

update version tag

v1.2.0-rc7

update version tag

v1.2.0-rc6

update version tag