Select Pod Scheduling Policy in DB creation wizard

This ticket is dedicated to implementing the functionality to cover use cases:

• Use Case 3 - Apply Pod Scheduling Policy on new DB cluster

!!! THE DESCRIPTION BELOW IS OUTDATED !!!

User Story:

As a database administrator, I want to configure Kubernetes affinity rules for specific database components through the Advanced Configuration section of the DB creation wizard, so I can control workload distribution across the Kubernetes cluster, optimize resource usage, and achieve high availability for each component independently.

Context:

In the Advanced Configuration tab of the DB creation wizard, users should be able to set Kubernetes affinity rules within the "Affinity" section. The components available for affinity configuration vary based on the selected database engine and whether sharding is enabled (in the case of MongoDB).

• For MySQL and PostgreSQL, users can set affinity rules for the DB nodes and Proxies components.

• For MongoDB, if sharding is off, only the DB nodes component is available. If sharding is on, users can configure rules for DB nodes, Proxies, and Config Servers components.

Each component has a default affinity rule of type Pod Anti-Affinity with:

• Priority set to Preferred

• Weight of 1

• Topology Key of "kubernetes.io/hostname"

A single "Add new rule" button at the top of the Affinity section opens a modal, where users can select the component the rule applies to based on the available options for their chosen database engine and configuration.

Acceptance Criteria:

1. Affinity Section Structure:

   • The "Affinity" section in the Advanced Configuration tab contains tables for each component available to the selected database engine.

     • MySQL and PostgreSQL: The section displays tables for DB nodes and Proxies components.

     • MongoDB without sharding: The section displays a single table for the DB nodes component.

     • MongoDB with sharding: The section displays tables for DB nodes, Proxies, and Config Servers components.

   • Each table lists the affinity rules for its respective component, with columns for "Type", “Topology Key” (if applicable), “Key” (if set), “Operator” (if “Key” was set), “Value” (if applicable) "Priority", and "Weight" (if applicable).

2. Default Affinity Rule:

   • Each component (DB nodes, Proxies, and Config Servers) has a default affinity rule of type Pod Anti-Affinity with:

     • Priority set to Preferred

     • Weight set to 1

     • Topology Key set to "kubernetes.io/hostname"

   • The default rule is displayed in each component’s table under the Affinity section.

   • The default rule can be edited or deleted by the user.

3. Single "Add New Rule" Button:

   • A single "Add new rule" button is located at the top of the Affinity section.

   • When clicked, this button opens a modal dialog to configure a new affinity rule.

4. Add Affinity Rule (Modal Configuration):

   • In the modal, the user must select which component the rule applies to, with available options depending on the selected database engine:

     • MySQL and PostgreSQL: Options are DB nodes and Proxies.

     • MongoDB without sharding: The only option is DB nodes.

     • MongoDB with sharding: Options are DB nodes, Proxies, and Config Servers.

   • The modal allows the user to:

     • Select the affinity type, with options: "Node Affinity", "Pod Affinity", and "Pod Anti-Affinity".

     • Select the priority for the rule, with options: Required or Preferred.

       • If "Required" is selected, no "Weight" input field is shown (since "Required" rules do not require weighting).

       • If "Preferred" is selected, a "Weight" input field appears, allowing the user to enter a value between 1 and 100 to indicate the priority of the rule.

     • Define rule details based on the selected affinity type:

       • Node Affinity:

         • "Key" and "Operator" fields are mandatory.

         • "Value" is only available (and mandatory) if the selected operator is "In" or "Not In".

       • Pod Affinity / Pod Anti-Affinity:

         • "Topology Key" is mandatory and must be filled.

         • "Key", "Operator", and "Value" fields are optional.

         • If "Key" is empty "Operator", and "Value" are disabled (grayed out)

         • "Value" is only available (and mandatory) if the selected operator is "In" or "Not In".

   • The "Operator" dropdown options include: "In", "Not In", "Exists", "Does Not Exist".

     • If the user selects "Exists" or "Does Not Exist", the "Value" input is hidden as it is not applicable.

   • At the top of the modal there is a description of what affinity rules are and a link to the kubernetes affinity documentation.

5. Edit Affinity Rule (Per Component):

   • Each rule in the tables for available components (based on the selected engine) has an "Edit" icon that opens an edit modal.

   • The edit modal is pre-populated with the current settings of the selected rule, allowing the user to modify the configuration and save changes.

   • The default rule for each component (Pod Anti-Affinity, Preferred, Weight=1, Topology Key="kubernetes.io/hostname") can also be edited.

6. Delete Affinity Rule (Per Component):

   • Each rule in the tables has a "Delete" icon that allows the user to remove the rule from the component.

   • A confirmation prompt appears before the rule is deleted.

   • Users can delete the default rule, but they will be warned that this may affect default workload distribution.

7. Validation and Constraints:

   • If "Preferred" is selected, the "Weight" field exists and only accepts values from 1 to 100.

   • For Node Affinity, "Key" and "Operator" fields are mandatory, while "Value" is optional unless required by the operator (if the selected operator is "In" or "Not In").

   • For Pod Affinity and Pod Anti-Affinity, the "Topology Key" field is mandatory, while "Key", "Operator", and "Value" are optional. "Value" is only available (and mandatory) if the selected operator is "In" or "Not In".

   • When "Exists" or "Does Not Exist" is selected for the "Operator", the "Value" field is hidden as it is not applicable.

   • Each table operates independently, so rules in the "DB nodes" table do not affect rules in the "Proxies" or "Config Servers" tables.

Design (Figma link):

Tech Documentation:

Limitations: