giseldo/neodataset huggingface dataset:
Review and adjust tooltips that won't match reverse-logic specs on the web console

## Summary

On the web console, when showing boolean specs which are related to disabling options like `disableMetricsExporter` or `disableClusterPodAntiaffinity`, the UI acts in a "reverse" manner, in the sense that to "disable" the corresponding spec you must set the value to false.

![image](/uploads/e27915d6f1f5af80a1d1567e72dd5f26/image.png)

For such reasons, some tooltips might not match properly the information shown on the web console:

![image](/uploads/bc8dbdfcfb2215197ce3bba95e9939ca/image.png)


## Proposed Solution

We should review such specs and their corresponding tooltips and rewrite on the web console those who do not match.


## Acceptance criteria

- [ ] Implement the proposed solution

Story points: 2.0
Pods and time range selectors missing on monitoring tab

### Summary

Pods and time range selector missing on monitoring tab

![image](/uploads/0d641e6aa7bd1f79453e33292f014c22/image.png)



#### Steps to reproduce

- Enter the web console
- Select any cluster with one or more active pods
- Enter the "Monitoring" tab
- The "Time Range" and "Pods" dropdown selectors are not shown

### Expected Behaviour

Both dropdown selectors should appear on the right side of the cluster tabs


### Possible Solution

- The code for such selectors is missing after the changes introduced on https://gitlab.com/ongresinc/stackgres/-/merge_requests/1084

### Environment

- StackGres version: `1.2.0`

Story points: 2.0
Grafana tab is visible even if Monitoring is not enabled

### Summary
Grafana tab is visible even if Monitoring is not available. 

This happens when clusters are created without enabling `prometheusAutobind`, which causes the tab to appear and show all graphs with "No data" messages on them

### Environment
- StackGres version: 1.2.0

### Relevant logs and/or screenshots
![image](/uploads/0cfe4b3033c8a14c4ce30bfd78407477/image.png)

Story points: 2.0
Update and improve the UI Connection Info popup

Current pop-up looks like this:

![image](/uploads/f49c7a1427b4fbe1283fa2b9807aeec0/image.png)

There are two ideas to update/improve here:

* ~The DNS proposed is still using the legacy `${clusterName}-primary` DNS name. Should be replaced by the now current `${clusterName}`.~ (will fixed by #1868)
* If the cluster is created with the Babelfish flavor, an additional text should appear to explain how to connect via the SQL Server protocol. The command should look like `kubectl -n ${namespace} run usql --rm -it --image ongres/postgres-util --restart=Never -- usql --password ms://babelfish@${clusterName}:1433` and include information on how to retrieve the secret (`kubectl -n ${namespace} get secret ${clusterName} --template '{{ printf "%s" (index .data "babelfish-password" | base64decode) }}'`)

Acceptance criteria:
* [x] Implement the change

Story points: 4.0
Namespace selector won't stay open

### Summary

Sometimes, after navigating through different sections of the web console, when clicking the namespace selector on the sidebar, it won't remain open.

![namespace-error](/uploads/38399c76e954410726b6b977f1f67824/namespace-error.mov)


#### Steps to reproduce

- Enter the web console
- Navigate to any section on any namespace
- Go to Namespaces Overview (click on StackGres logo)
- Navigate to any section on any namespace
- Click on the namespace selector on the sidebar

### Expected Behaviour

The behavior on the namespace selector should be consistent and it should remain open when toggling such mode.


### Environment

- StackGres version: `1.2.0`

Story points: 1.0
Details about Distributed logs configuration not shown in logs server section

### Summary

In a cluster with distributed logs configured in a different namespace of the SGCluster, the information is not show in the Logs servers section. 

![image](/uploads/4a6c85e656ae2c56e915733478194684/image.png)

But the configuration exist(SGCluster configurations): 

![image](/uploads/38a9358ae7015efdb716f53d70b87b68/image.png)


and it is working: 

![image](/uploads/4a4afa5929a3fd7b94f4d5889a828561/image.png)

if you go to `/namespace/SGDistributedLogs/monitoring.distributedlogs`: 

![image](/uploads/301cbee8a031223d780b224b17275aa1/image.png)


#### Steps to reproduce

1- Configure a SGCluster with a SGDistributed logs in a different namespace: 

```
apiVersion: stackgres.io/v1
kind: SGDistributedLogs
metadata:
  name: distributedlogs
  namespace: monitoring
spec:
  persistentVolume:
    size: 100Gi
```

2. Add to the SGCluster definition: 

```
 distributedLogs:
    sgDistributedLogs: 'monitoring.distributedlogs'
    retention: "15 days"
```
3. Then check the UI Logs server section.

### Expected Behaviour

The UI show information about the SGDistributedlogs configured in the Cluster. 

### Possible Solution

For the UI the Logs Servers section information should be global and not namespace dependent. 

### Environment

- StackGres version: 1.2.0
- Kubernetes version: 1.21
- Cloud provider or hardware configuration: GKE


### Relevant logs and/or screenshots
```
kubectl get pods -n monitoring distributedlogs-0 

NAME                READY   STATUS    RESTARTS   AGE
distributedlogs-0   3/3     Running   0          23h
```

Story points: 1.0
Lower the initial param autovacuum_work_mem

The objective of this change is lower the amount of memory allocated to the parameter: `autovacuum_work_mem` to the value 512 MB. Currently, our initial setup is 2 GB.

For reference: https://postgresqlco.nf/doc/en/param/autovacuum_work_mem/


**Acceptance criteria:**
- [ ] Set the new lower value 
- [ ] Test the new default config

Story points: 4.0
Remove support for 1.0

Remove support for version 1.0 of StackGres

## Acceptance Criteria

* [ ] Remove the version 1.0 from `StackGresVersion` and `Components` classes
* [ ] Remove all the code that is specifically handling the 1.0 version (conciliation, conversion, validation and mutation)
* [ ] Remove all 1.0 E2E tests

Story points: 2.0
Monitoring tab is empty when there are no active pods

### Summary

When there are no active pods for a cluster, the monitoring tab appears empty with no information whatsoever.

![image](/uploads/88aa9ee41e56ae8c73eb390787811240/image.png)



#### Steps to reproduce

- Enter the web console
- Look for any cluster which has no active pods
- Enter the "Monitoring" tab
- The tab shows no content

### Expected Behaviour

- If there is no actual data or reports coming from Grafana, there should be some kind of message shown to the user


### Environment

- StackGres version: `1.2.0`


### Acceptance criteria

* [x] Fix the bug

Story points: 1.0
Not Found appears on top of Header on Details views

### Summary
When requesting details of a non-existing CRD, the Not Found section appears on top of the Header section. 
This only happens on the Details views.

#### Steps to reproduce
1. Modify the URL of any Details view to point to a non-existing CRD.
2. The Not Found section will appear on top of the Header.

### Expected Behaviour
The Header section should not be displayed on Not Found.

### Environment
- StackGres version: 1.2.0

### Relevant logs and/or screenshots
![Screenshot_2022-05-25_at_14.49.34](/uploads/b81ed861e2de5e48d54065df60c8ad6f/Screenshot_2022-05-25_at_14.49.34.png)


Acceptance criteria:
 - [x] Implement the feature.
 - [x] Create tests

Story points: 2.0
Error message for pods scheduling is repeated during SGCluster creation

### Summary

When creating an SGCluster with errors on the `operator` spec for `spec.pods.scheduling.tolerations`, the text for the error message coming from the REST API is repeated.

- How it looks on the web console:

![image](/uploads/8b37c232f17f4d311e1c5fc982cd9d0e/image.png)


- How it comes on the REST API response:

```
{
   "type":"https://stackgres.io/doc/1.2-dev/api/responses/error#constraint-violation",
   "title":"Some fields do not comply with the syntactic rules",
   "detail":"operator must be Exists when key is empty.\noperator must be Exists when key is empty.",
   "status":422,
   "fields":[
      "spec.pods.scheduling.tolerations[0].key",
      "spec.pods.scheduling.tolerations[0].operator"
   ]
}
``` 


#### Steps to reproduce

- Enter the web console
- Enter the Create Cluster form
- Try to create a cluster with a toleration with no key set


### Expected Behaviour

- The text should only appear once on the REST API response



### Environment

- StackGres version: `1.2.0`

Story points: 4.0
Implement "ManagedSQL" as a new SGScripts CRD.

The description on the task is on the epic#18.

The goal is to implement "ManagedSQL" as a new SGScripts CRD.

The implementation is defined on the epic &18

**Acceptance criteria:**
- [ ] Implement the feature
- [ ] Create the tests
- [ ] Add the docuementation

Story points: 24.0
View Connection Info is not styled for clusters with no active pods

### Summary
When no pods are available yet for a cluster, the `View Connection Info` popup appears unstyled.

#### Steps to reproduce
1. Go to a cluster that has no active pods.
2. Click on `View Connection Info`.
3. A popup appears, but it is not styled.

### Expected Behaviour
The same styles should be applied, no matter if pods are available or not.

### Environment

- StackGres version: `1.2.0`

### Relevant logs and/or screenshots
![Screenshot_2022-05-20_at_15.08.17](/uploads/598c5584dbc7e1b8105c5ae17cf057ea/Screenshot_2022-05-20_at_15.08.17.png)

Story points: 1.0
Parameter max_wal_senders not applied during cluster creation

### Summary

Parameter [`max_wal_senders`](https://postgresqlco.nf/doc/en/param/max_wal_senders/) is not applied on a new SGCluster.

#### Steps to reproduce

1. Create a SGPostgresConfig with `max_wal_senders` set to 50
2. Create an SGCluster referencing the above configuration

### Expected Behaviour

Parameter [`max_wal_senders`](https://postgresqlco.nf/doc/en/param/max_wal_senders/) is applied to the new SGCluster.

### Environment

- StackGres version: 1.1.0
- Kubernetes version: ?
- Cloud provider or hardware configuration: ?

Acceptance criteria:
- [ ] Fix the bug
- [ ] Create the test

Story points: 4.0
"Create Resource" option available on SGCluster form when user has no permissions

### Summary

When creating an SGCluster from the web console, it is possible for users to create configurations and other resources by clicking on the "Create New" from the dropdown selectors. Even for users who have no permission to create the specified resource, this option is still available.

![image](/uploads/2924367c98757bd40731804acb52bacb/image.png)


#### Steps to reproduce

- Create a user with permissions to create SGClusters but no permissions to create dependencies (SGInstanceProfiles, SGPostgresConfigs, etc.)
- Log in to the web console with the specified user
- Enter the Create Cluster form
- Toggle the corresponding dependencies dropdown
- The option to create the dependency will appear even though it shouldn't

### Expected Behaviour

There should be no CTAs on the web console for operations the user is not allowed to do

### Possible Solution

Validate RBAC permissions before loading the "create" option

### Environment

- StackGres version: `1.2.0-RC`

Story points: 1.0
Allow to start cluster pods in parallel

### Problem to solve

SGCluster Pods are started using the [OrderedReady management policy of the StatefulSet](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#orderedready-pod-management). In some scenario a user may want to spin up a cluster and his replicas as soon as possible by starting them in parallel using the [Parallel management policy of the StatefulSet](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#parallel-pod-management). This may also benefit the CI/CD pipepline (see #630)

### Proposal

Add property `.spec.pods.managementPolicy` that default to `OrderedReady` and can be also set to `Parallel`

### Testing

Set the default as Parallel for testing

## Acceptance Criteria

* [x] Implement the feature
* [x] Set the feature behavior as default in tests
* [ ] Review and merge !1112

Story points: 1.0
Cluster cloning fails when scripts include references to configMaps

### Summary

The web console implements cloning configurations for a SGCluster.

Even though the cloning process works fine, there might be cases on which the cluster to clone contains references to configMaps, which causes the request to fail because of extra information included in the payload.

![image](/uploads/278d9f73b71a09fe9b9456356ff6b226/image.png)


The reason why this fails is because the request includes both, the reference to the configMap and the script associated to it. The later shouldn't be included on the payload.

```
   "spec":{
      ...
      "initialData":{
         "scripts":[
            {
               "name":"map",
               "database":"db",
               "scriptFrom":{
                  "configMapScript":"CREATE USER pguser2 WITH PASSWORD 'pguser2';",
                  "configMapKeyRef":{
                     "key":"script-key",
                     "name":"script-configmap"
                  }
               }
            }
         ]
      }
      ...
   },
```


#### Steps to reproduce

- Enter the web console
- Create any cluster with script references to configMaps
- Clone the created cluster
- An error like the one on the image above will appear

### Expected Behaviour

The cloning should work fine even when referencing configMaps

### Possible Solution

Remove the additional `configMapScript` property from the payload

### Environment

- StackGres version: `1.2.0`

Story points: 1.0
Improve operator helm chart install / upgrade times

Currentrly the operator helm chart takes between 1 and 2 minutes regardless the fact that it needs to update CRDs or not (it always update them) or it has to recreate the certificate or not (it always recreate the certificate). Also the secret for the Web Console user is recreated regardless of the fact that it already exists or not.

## Implementation plan

Detect if CRDs exists and are already upgraded to the latest version by annotating them using the helm chart version. If the CRDs already exists and they are all annotated with the latest version they are considered to be valid.
 Create a flag in order to indicate that the certificate have to be created and in such case

## Acceptance Criteria

* [x] Implement skip of CRD upgrade
* [x] Implement skip of certificate upgrade
* [x] Implement skip of Web Console secret upgrade

Story points: 1.0
Prevent showing multiple notifications for the same error message

### Summary

Whenever there's an error response coming from the REST API, the web console shows a notification related to it. 

There might be cases where a `502 Bad Gateway` error affects the whole set of requests made to the API, which generates several notifications with the exact same message.

![image](/uploads/933add537f99c8cfa44e98e6beee6c5c/image.png) 


### Expected Behaviour

If there is more than one message with the exact same info, only one message should be shown to the user.

### Environment

- StackGres version: `1.1.0`

**Acceptance criteria:**
- [x] Fix the bug

Story points: 2.0
Add missing resources to the can-i REST API endpoint

### Summary

The `/stackgres/can-i` REST API endpoint does not return permissions for the following resources:

- stats
- events
- logs
- pod/exec

Some permission dependencies related to those resources are required by the web console in order to ensure proper access restrictions.


#### Steps to reproduce

1. Call the `/stackgres/can-i` REST API endpoint
2. The response won't include any of the resources listed above


### Expected Behaviour

The `/stackgres/can-i` REST API endpoint returns permissions for every resource directly accesible via the REST API


### Possible Solution

Add `events`, `stats`, `logs` and `pod/exec` to the list of resources for which permissions are returned in the `caniList()` method of the class `RbacResource`.

### Environment

- StackGres version: 1.2.0
- Kubernetes version: ?
- Cloud provider or hardware configuration: ?

Story points: 4.0
Web console won't match field validations on repeaters

### Summary

When receiving error responses for POST/PUT requests made to the REST API, the web console might receive information about the fields that caused the error. In such cases, the web console highlights the input with a red border, letting the user know which fields are causing the issue.

This works fine for single fields which appear only once on the form, but when matching fields contained inside repeaters, the web console does not consider the index of the field coming from the REST API response.


### Expected Behaviour

Web console should match the index of the field coming from the REST API response.


### Environment

- StackGres version: `1.1.0`

**Acceptance criteria:**
- [x] Fix the bug
- [x] Create a test

Story points: 2.0
Backup creation should fail validation if the referenced cluster is not configured for backups and is not a copy of another backup


### Summary

Creating a cluster without any backup config allow to create backup from the Web Console and they only show a `pending` state without showing any validation message. 

![image](/uploads/a78a5318f9b646f8442bb5bf6ac3f2df/image.png)

![image](/uploads/4de8ef65f55ccad6d0d01966506930f2/image.png)

K8s events shows the validation message:

```
0s          Warning   BackupConfigFailed                sgbackup/test-backup-1                                         Missing SGBackupConfig for cluster demo-db.demo-db
0s          Warning   BackupConfigFailed                sgbackup/test-backup-1                                         Backup reconciliation cycle failed: SGBackup demo-db/test-backup-1 target SGCluster demo-db without a SGBackupConfig

```

Web console events also does not show any backups events:

![image](/uploads/2a40cbb24d2e00dfb7909f83d8b53a8e/image.png)

#### Steps to reproduce

1- Create a SGCluster without a Backup Config

2- Create a Backup from the Web console 

3- Check the state from the Web Console

4- Check the k8s Events

### Expected Behaviour

Web console showing a message indicating that Backup config is missing.  

### Possible Solution

Check that a `SGBackupConfig` is referenced by the associated `SGCluster` in the validating webhook during creation of any `SGBackup` that does not have section `status.sgBackupConfig` defined. If, in such case, there is no `SGBackupConfig` reference in the associated `SGCluster` a validation error is returned saying "To create a backup you must first configure the SGCluster for backups".

### Environment

- StackGres version: 1.2.0-beta1
<!-- if you have used helm, you can use:  `helm get notes -n stackgres stackgres-operator` 
more generic: `kubectl get deployments -n stackgres stackgres-operator --template '{{ printf "%s\n" (index .spec.template.spec.containers 0).image }}'`
-->
- Kubernetes version: 1.21
<!--(use `kubectl version`) -->
- Cloud provider or hardware configuration: Minikube


### Relevant logs and/or screenshots

<!-- (Paste any relevant logs - please use code blocks (```) to format console output,
logs, and code as it's very hard to read otherwise.) -->

Story points: 8.0
Certificate Singing Request does not return the certificate after approval in EKS 1.22

Using EKS 1.22 the certified is approved but not issued:

```
❯ kubectl get csr -n stackgres
NAME                 AGE     SIGNERNAME                      REQUESTOR                                                 
stackgres-operator   2m39s   kubernetes.io/kubelet-serving   system:serviceaccount:stackgres:stackgres-operator-init   <none>              Approved
```

```
kubectl version
Client Version: version.Info{Major:"1", Minor:"23", GitVersion:"v1.23.5", GitCommit:"c285e781331a3785a7f436042c65c5641ce8a9e9", GitTreeState:"clean", BuildDate:"2022-03-16T15:51:05Z", GoVersion:"go1.17.8", Compiler:"gc", Platform:"darwin/arm64"}
Server Version: version.Info{Major:"1", Minor:"22+", GitVersion:"v1.22.6-eks-7d68063", GitCommit:"f24e667e49fb137336f7b064dba897beed639bad", GitTreeState:"clean", BuildDate:"2022-02-23T19:29:12Z", GoVersion:"go1.16.12", Compiler:"gc", Platform:"linux/amd64"}
```

**Acceptance criteria:**
- [ ] Fix the issue

Story points: 3.0
Upgrade E2E framework to use kind 0.14.0

The following discussion from !1089 should be addressed:

- [ ] @jorsol started a [discussion](https://gitlab.com/ongresinc/stackgres/-/merge_requests/1089#note_919378721):  (+1 comment)

    > Ideally use 1.18.20 that resolve a regression introduced in 1.18.19

Acceptance criteria 
- [  ] execute upgrade

Story points: 8.0
Tolerations for SGDbOps

<!--
Please read this!

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Feature Request" label.

Issue tracker:

- https://gitlab.com/ongresinc/stackgres/-/issues?label_name=Feature%20Request 
and verify the issue you're about to submit isn't a duplicate.
-->

### Problem to solve

Currently, we are running StackGres Cluster on our k8s cluster where all the nodes have taints. There is a need to add taints to even the pods for SGDbOps.
Currently, this is not supported and it would be helpful to add these tolerations to all the SGDbOps.



### Further details

<!-- Include use cases, benefits, and/or goals -->
Consider a case where all the nodes are tainted in a cluster and we need to run SGDbOps on this cluster.

### Proposal

<!-- How could we going to solve the problem? -->
Please add tolerations capability for SGDbOps.

SGCluster example:

```yaml
sgCluster:
scheduling:
  tolerations:
    items:
      key:
      operator:
      value:
      effect:
      tolerationSeconds:
```

### Testing

<!-- What risks does this change pose? How might it affect the quality of the product?  -->
Seems like a minor change that wouldn't affect the functionality much.


**Acceptance Criteria:**
- [ ] Able to add tolerations to any type of SGDbOps.
- [ ] Update documentation of the CRD
- [ ] Test the implementation

Story points: 16.0
Enhance Web Console's usability/discoverability of the "enable monitoring" option when creating a cluster

Monitoring is one of the most important features you may want from a Postgres cluster. In SG it is not enabled by default, and that's probably fine. It also depends on the user installing the optional dependencies that the user requires for monitoring, and we don't have much control over that.

However, if you have installed the dependencies, discovering how to enable monitoring for the cluster is not immediate. It is "hidden" under `Advanced options` and then `Sidecars`. Not very intuitive.

It actually makes sense where it is, since it requires deploying a sidecar. However, we should *also* make it more accessible. Therefore I propose to add in the main screen, `Cluster` section, at the bottom, a simple checkbox with the following text and tooltip:

* Text: _Enable monitoring_
* Tooltip: _StackGres supports enabling automatic monitoring for your Postgres cluster, but you need to provide or install the [Prometheus stack as a pre-requisite](https://stackgres.io/doc/latest/install/prerequisites/monitoring/). Then, check this option to configure automatically sending metrics to the Prometheus stack_.

This won't change anything under the `Sidecars` section, other than the enabled/disabled status in both the `Cluster` and `Sidecars` section needs to stay in sync.

**Acceptance criteria:**
- [x] Adapt the UI to attend the request
- [x] Tests of the implementation

Story points: 2.0