giseldo/neodataset huggingface dataset:
Annotations, affinity, tolerations, and nodeSelector to be added in operator helm chart

Requesting a change to the operator helm chart.

The helm chart is missing these scheduling properties (affinity, tolerations and nodeSelector) and the ability to add annotations to Pods, Services and ServiceAccounts.

These are required if it is preferred for the StackGres operator to be deployed to a particular node only or for any special configuration that some tools or cloud environments provide.

# Proposal

Add the following sections to the operator helm chart `values.yaml`

```yaml
operator:
  annotations: {}
  service:
    annotations: {}
  serviceAccount:
    annotations: {}
  affinity: {}
  tolerations: {}
  nodeSelector: {}
restapi:
  annotations: {}
  service:
    annotations: {}
  serviceAccount:
    annotations: {}
  affinity: {}
  tolerations: {}
  nodeSelector: {}
jobs:
  annotations: {}
  service:
    annotations: {}
  serviceAccount:
    annotations: {}
  affinity: {}
  tolerations: {}
  nodeSelector: {}
```

**Acceptance criteria:**
- [x] Add the node property on the helm chart
- [ ] Update the documentation on the CRD
- [ ] Test the implementation

Story points: 8.0
Validate cloning of resources from the web console when the resource contains references to secrets

### The Problem

The web console implements cloning features for most of the CRDs supported by StackGres.

Even though the cloning process works fine, there might be cases on which the resource to clone contains references to secrets which cannot be accessed from the REST API, so it is quite possible that the cloned resource does not take into account such specs.


### The Request

We should validate what would happen for such cases and, if needed, create an issue to implement any adjustments that might be needed to let the user know about such limitations during the cloning process.

**Acceptance criteria:**
- [x] Make a POC to verify there is a bug

Story points: 1.0
Allow specify loadBalancerIP for postgres services

### Problem to solve

Currently, it is not possible to specify a custom load balancer IP for the Postgres services, the idea of this is to be able to set a custom load balancer IP for R/W and R/O connections, this also allows to keep the same IP in case if it's necessary to recreate the services.

### Proposal

In the SGCluster services section allows to add a custom load balancer IP (SGCluster and DistributedLogs)

```yaml
postgresServices:
    primary:
      type: LoadBalancer
      loadBalancerIP: 80.11.12.10
    replicas:
      type: LoadBalancer
      loadBalancerIP: 80.11.12.11
```

And generate a service like: 

```yaml
apiVersion: v1
kind: Service
metadata:
  name: my-cluster
spec:
  selector:
    app: StackGresCluster
    cluster-name: my-cluster
    role: master
  ports:
    - name: pgport
      protocol: TCP
      port: 5432
      targetPort: pgport
  loadBalancerIP: 80.11.12.10
```

### Links / references

https://kubernetes.io/docs/concepts/services-networking/service/#loadbalancer

**Acceptance criteria:**
- [x] Implement the CRDs (SGCluster and DistributedLogs) 
- [x] Implement the change on the REST API(SGCluster and DistributedLogs)
- [x] Implement the change on the cluster demo helm chart(SGCluster and DistributedLogs)
- [ ] Create an Issue for the UI @jose_oss_pg todo
- [x] Create tests
- [x] Documentation(SGCluster and DistributedLogs)

Story points: 16.0
Create SGObjectStorage CRD

Related to #862.

This issue only require the following feature:

* Create an `SGObjectStorage` CRD extracting the model from `SGBackupConfig` `.spec.storage` into the field `.spec` of the new `SGObjectStorage`.
* Add endpoints in the REST API to list, get, create, patch and delete `SGObjectStorage`.

**Acceptance criteria:**
- [x] Implement the CRD
- [x] Implement REST API
- [x] Document the implementation
- [x] Test the implementation

Story points: 24.0
Support new backup configuration in SGCluster on the web console

When #862 is done, apply the following proposed spec on the SGCluster CRD:

```yaml
spec:
  configurations:
    sgBackupConfig: <string> # this does not change bu will be deprecated and mutually exclusive with `backups` field.
    backups:
    - path: <string>
      compression: <string>
      cronSchedule: <string>
      performance:
        maxDiskBandwitdh: <integer>
        maxNetworkBandwitdh: <integer>
        uploadDiskConcurrency: <integer>
      retention: <integer>
      sgObjectStorage: <string> # name of an SGObjectStorage in the same namespace
```

**Implementation plan:**

- [ ] Detail the CRUD model for this CRD.

**Acceptance criteria:**
- [x] Implement the CRUD.
- [x] Implement some tests.

Story points: 16.0
Set default log_statement value to none for SGPostgresConfig

Default `log_statement` value is set to `ddl` when creating an `SGPostgresConfig`. With such configuration value users passwords will be logged during creation or modification of users. This is a security flaw allowing someone with access to the database logs to see users credentials if the statement is not protected by setting `log_statement` to `none` for local session prior execution of any of those commands. 

## Implementation plan

Set default `log_statement` to `none` for `SGPostgresConfig`.

Story points: 4.0
Allow specify resources to assign to Distributedlogs pods


### Problem to solve

Currently, it is not possible to specify the amount of resources assigned to distributed logs pod. 

### Further details

Some environments generate a lot of logs and log database grow very fast and getting information from the logs becomes very slow. 

### Proposal

Allow apply an `SGInstanceProfile` to Distributed logs and also an `SGPostgresConfig`. 

```yaml
apiVersion: stackgres.io/v1
kind: SGDistributedLogs
metadata:
  name: distributedlogs
spec:
  sgInstanceProfile: 'size-m'
  configurations:
    sgPostgresConfig: 'pgconfig'
  persistentVolume:
    size: 100Gi
```

## Acceptance Criteria

- [ ] Implement the feature in the CRD
- [ ] Implement the logic in the mutating and validating webhook similar to the one existing for `SGCluster` CRD
- [ ] Implement the change in the REST API
- [ ] Add tests

Story points: 2.0
Set default_toast_compression=lz4 on PostgreSQL 14's default config

Based on the benchmarks on this [post](https://www.postgresql.fastware.com/blog/what-is-the-new-lz4-toast-compression-in-postgresql-14) I consider LZ4 highly beneficial compared to PGLZ.

For this reason I'd propose making it the default TOAST compression algorithm for Postgres 14, adding to our default configuration (only for v14 and future later versions) [`default_toast_compression=lz4`](https://postgresqlco.nf/doc/en/param/default_toast_compression/).

Story points: 4.0
Refactor and improve unit test data fixtures

We have many files in the `test-util` module.

We want to have test classes to:

* Load such files with strong typing (e.g. return a `StackGresCluster` class instance)
* Enumerate all the available fixtures for ease of use
* Reuse the fixture data instance in all the StackGres Java modules
* Introduce fixture variations easier to be placed using code instead to create a full copy of JSON file with small differences

Other possible uses:

* Generate random values by default depending on the fixture (since random values should be used or not depending on the test usage of the fixture)

# Proposition

Move JSON files in the `common` module and wrap them in fixture classes. Make the `common` module install the `test-jar` package following this guide: https://maven.apache.org/guides/mini/guide-attached-tests.html

Story points: 1.0
Generated prometheus stats services return ambiguous stats

Currently two service are create for each cluster. One points to Envoy port 8008 and other point to Postgres Exporter port 9187:

```shell
$ kubectl get service -n operator-upgrade-5f60a6c7 | grep 'prometheus'
operator-upgrade-3-prometheus-envoy               ClusterIP   10.111.97.168    <none>        8001/TCP            19m
operator-upgrade-3-prometheus-postgres-exporter   ClusterIP   10.99.148.144    <none>        9187/TCP            19m
```

The service points to every pod in the cluster so that stats returned are from the pod that is routed by the service during the call. This lead to ambiguous result.

```shell
$ curl -s operator-upgrade-3-prometheus-postgres-exporter:9187/metrics | grep pg_wal_
# HELP pg_wal_position_bytes Postgres LSN (log sequence number) being generated on primary or replayed on replica (truncated to low 52 bits)
# TYPE pg_wal_position_bytes counter
pg_wal_position_bytes{server="/var/run/postgresql:5432"} 1.006666e+08
$ curl -s operator-upgrade-3-prometheus-postgres-exporter:9187/metrics | grep pg_wal_
# HELP pg_stat_replication_pg_wal_lsn_diff Lag in bytes between master and slave
# TYPE pg_stat_replication_pg_wal_lsn_diff gauge
pg_stat_replication_pg_wal_lsn_diff{application_name="operator-upgrade-3-0",client_addr="127.0.0.1",server="/var/run/postgresql:5432",slot_name="169",state="streaming"} 0
pg_stat_replication_pg_wal_lsn_diff{application_name="operator-upgrade-3-2",client_addr="127.0.0.1",server="/var/run/postgresql:5432",slot_name="168",state="streaming"} 0
# HELP pg_wal_position_bytes Postgres LSN (log sequence number) being generated on primary or replayed on replica (truncated to low 52 bits)
# TYPE pg_wal_position_bytes counter
pg_wal_position_bytes{server="/var/run/postgresql:5432"} 1.006666e+08
$
```

Those services are not used currently so the proposal is to only point service to the primary pod.

**Acceptance criteria:**
- [x] fix the bug 
- [x] Create a test

Story points: 8.0
Validate and integrate into tests OpenShift 4.9+

Acceptance criteria:

- [x] Create the e2e test environment using one of the following options:
    - Use [Code Ready Containers](https://github.com/code-ready/crc) using a [Google Cloud Nested Virtualization Instance](https://cloud.google.com/compute/docs/instances/nested-virtualization/overview). :white_check_mark: 
    - Use [Rosa](https://docs.openshift.com/rosa/welcome/index.html).
- [x] all the StackGres e2e tests should pass for the latest stable release
    - Except operator-demo and ui (due to cypress out of memory bug)

Story points: 5.0
SGBackups list won't load when start time is not present on a backup

### Summary

At the moment the web console reads the SGBackups list from the REST API, it calculates the time it takes to create each backup. This causes the UI to fail loading the complete backups list if any of the properties used to calculate such time doesn't exist.

An error like the following might be seen on the browser's console.

![image](/uploads/24ed1363afc36d965309252ffbb27752/image.png)


### Expected Behaviour

The web console should list every backup regardless of the possibility to calculate its duration or not.


### Environment

- StackGres version: `1.4.2`

Story points: 4.0
Show secretKeySelectors for GCS service account json on edit mode

### Summary

When editing a GCS SGObjectStorage, even when the `serviceAccountJSON` has been set, the UI shows a file input as if it wasn't.

![image](/uploads/f72d8107e77963d28317b2dc28584d59/image.png)

Instead of just showing the plain input with no file associated, the form should show the `secretKeySelectors` that match the uploaded file, while also giving the user the option to replace such selectors by uploading a new file.


#### Steps to reproduce

- Enter the web console
- Create a GCS SGObjectStorage with an associated `serviceAccountJSON`
- Edit the recently created resource
- No secret key selectors info is shown


### Expected Behaviour

Even though the `secretKeySelectors` are generally the same for every GCS storage, there should be a way to show users that the credentials have been set.


### Environment

- StackGres version: `1.5.0-beta1`

Story points: 8.0
Script content not shown on summary when set from a ConfigMap

### Summary

When editing an SGCluster from the web console, if the resource has any scripts associated to it which have been read from a ConfigMap, once the user clicks on "View Summary", te reference to the ConfigMap is shown, but not the script itself (even though it shows on the form)


#### Steps to reproduce

- Enter the web console
- Enter the Create SGCluster form
- Create any cluster with at least one script associated to a ConfigMap
- Edit the cluster
- The script should appear on the "Scripts" step
- Click on "View Summary"
- The script is not shown, only the ConfigMap references 


### Expected Behaviour

Whenever the web console has access to the script, it should be shown on the summary


### Environment

- StackGres version: `1.5.0-beta1`

### Relevant logs and/or screenshots

![image](/uploads/5057e6c65dc3f62b6b8344043a032121/image.png)

![image](/uploads/8ac7be53d979b45d043e5099dcc2e2ae/image.png)

Story points: 4.0
Replace instances dropdown with numeric input on SGCluster form

### Summary

When creating or editing SGClusters on the web console, the number of instances is defined by using a dropdown list with a maximum of 10 instances, even though there's no actual limit of instances for StackGres.

![image](/uploads/a980eac99e7b3ac072e6bba1da18da52/image.png)


### Possible Solution

Replace the dropdown with a numeric input.

### Environment

- StackGres version: `1.4.x`

Story points: 4.0
Backup path is not updated after major version upgrade

### Summary

After performing a major version upgrade the backup `path` parameter is not updated and this leads to errors when starting the cluster.

![image](/uploads/8075a5d50259bb2c26a0812236570864/image.png)

### Current Behaviour 

If the backup path is set even with the default values, if you have a cluster with pg 14 and upgrade it to pg 15, the value is not updated

before upgrade (pg14):

```
spec:
  configurations:
    backups:
    - compression: lz4
      cronSchedule: 30 01 * * 6
      path: sgbackups.stackgres.io/my-db/my-db/14
```

after upgrade (pg15): 

```
spec:
  configurations:
    backups:
    - compression: lz4
      cronSchedule: 30 01 * * 6
      path: sgbackups.stackgres.io/my-db/my-db/14
```

The cluster does not start and throws the next type of error: 

```
/var/run/postgresql:5432 - rejecting connections
ERROR: 2023/03/02 13:06:37.118279 Archive '00000003000002D800000001' does not exist.
ERROR: 2023/03/02 13:06:37.347286 Archive '00000002000002D800000001' does not exist.
ERROR: 2023/03/02 13:06:37.588631 Archive '00000001000002D800000001' does not exist.
2023-03-02 13:06:37 UTC [7051]: db=,user=,app=,client= FATAL:  requested timeline 5 is not a child of this server's history
2023-03-02 13:06:37 UTC [7051]: db=,user=,app=,client= DETAIL:  Latest checkpoint is at 2D8/1000228 on timeline 1, but in the history of the requested timeline, the server forked off from that timeline at 2D7/EF00E128.
```

```
NAME                                            READY   STATUS      RESTARTS        AGE
my-db-0                                         6/7     Running     0               1h
```

After changing the value of the backup path to the new version the cluster starts normally. 

```
spec:
  configurations:
    backups:
    - compression: lz4
      cronSchedule: 30 01 * * 6
      path: sgbackups.stackgres.io/my-db/my-db/15
```


```
NAME                                            READY   STATUS      RESTARTS        AGE
my-db-0                                         7/7     Running     0               1m
```


#### Steps to reproduce

1. Create a cluster with the backup configuration (pg14)
2. Execute a Major version upgrade from pg14 to pg15
3. Check the backup `path` parameter

### Expected Behaviour

If the value is not set, the operator also upgrades the value to the newer version in order to avoid cluster issues. 

### Environment

- StackGres version: 1.4.0
- Kubernetes version: 1.24
- Cloud provider or hardware configuration: DO and AWS

Story points: 2.0
[UI] Support user-supplied sidecars for pods customVolumes

Implement support for user-supplied sidecars on SGCluster pods' customVolumes based on the following spec proposal:

```yaml
apiVersion: stackgres.io/v1
kind: SGCluster
spec:
  pods:
    customVolumes:
    - name: <string>
      emptyDir:
        medium: <string>
        sizeLimit: <string>
      configMap:
        name: <string>
        optional: <boolean>
        defaultMode: <string>
        items:
        - key: <string>
          mode: <string>
          path: <string>
      secret:
        secretName: <string>
        optional: <boolean>
        defaultMode: <string>
        items:
        - key: <string>
          mode: <string>
          path: <string>
```

For more info see #538

**Acceptance criteria:**

* [ ] Implement the proposed changes on the UI
* [ ] Setup test for this feature

Story points: 24.0
[UI] Support user-supplied sidecars for SGCluster services

Implement support for user-supplied sidecars on SGCluster services based on the following spec proposal:

```yaml
apiVersion: stackgres.io/v1
kind: SGCluster
spec:
  postgresServices:
    primary:
      customPorts: # The list of extra ports that will be exposed by the primary service
      - appProtocol: <string>
        name: <string>
        nodePort: <integer>
        port: <integer>
        protocol: <string>
        targetPort: <string>
    replicas:
      customPorts: # The list of extra ports that will be exposed by the replicas service
      - appProtocol: <string>
        name: <string>
        nodePort: <integer>
        port: <integer>
        protocol: <string>
        targetPort: <string>
```

For more info see #538

**Acceptance criteria:**

* [x] Implement the proposed changes on the UI
* [x] Setup test for this feature

Story points: 16.0
Web console sends each script entry as a base script source

### Summary

When more than one script entry is set for a given script during cluster creation, the web console sends each entry as a single script containing all of the sibling entries.


#### Steps to reproduce

* Enter the web console
* Enter the "Create Cluster" form
* Click on the "ManagedSQL" step
* Create one script with two or more script entries
* Click on create cluster
* The request sent to the API includes one script set for each single script entry

### Expected Behaviour

Script Entries from the same parent script should all be sent in a single script set

### Possible Solution

Review `cleanupScripts` function on the `CreateSGClusters.vue` file

### Environment

- StackGres version: `1.4.0`

Story points: 8.0
Script source not cleared when deleting a script from the web console

### Summary

When creating a cluster with ManagedSQL specs, users can define one or more scripts. These scripts can be chosen from already existent SGScripts, or created inline by the user. But when one of the scripts is deleted from the set, the index for such script source is kept on memory, which causes inconsistencies on the scripts source set. 


#### Steps to reproduce

- Enter the web console
- Enter the "Create Cluster" form
- Click on the "ManagedSQL" step
- Create/choose two or more scripts
- Delete any of the scripts from the set
- A mismatch will appear on the set of sources, because the source from the deleted script has not been removed


### Expected Behaviour

When a script is deleted, its source reference should be deleted also.


### Environment

- StackGres version: `1.4.0`

Story points: 8.0
Web console allows setting PITR specs when it's not possible

### Summary

As stated [on the SG docs](https://stackgres.io/doc/latest/reference/crd/sgcluster/#restore-from-backup):

> It is possible to restore the database to its state at any time since your backup was taken using Point-in-Time Recovery (PITR) **as long as another backup newer than the PITR requested restoration date does not exists.**

Yet the web console allows for users to set PITR specs even if one or several backups have been taken after the backup chosen for the initialization.


#### Steps to reproduce

- Enter the web console

- **Create Base Backups:**
  - Create backup `X` for any cluster
  - Wait for backup `X` to be completed
  - Crate backup `Y` for the same cluster
  - Wait for backup `Y` to be completed
 
- Enter the "Create Cluster" form:
  - Enable Advanced Options
  - Click on the "Initialization" step
  - Select backup `X` from the dropdown

- PITR inputs will appear, even though backup `Y` exists and it has been taken after backup `X`


### Expected Behaviour

PITR inputs can only be shown if no backups have been taken after the one chosen for cluster initialization


### Environment

- StackGres version: `1.4.0`

Story points: 4.0
Fix Extensions table layout

### Summary
On the Cluster form, the Extensions table layout is too narrow and the names of the extensions do not fit properly.

### Possible Solution
Add ellipsis for long extension names.

### Environment
- StackGres version: 1\.4.0

### Relevant logs and/or screenshots
![Screenshot_2023-01-17_at_14.49.13](/uploads/411779ce9b95900b1684b71824ef2e4d/Screenshot_2023-01-17_at_14.49.13.png)

Story points: 4.0
Cluster name on SGDbOp details is not clickable

### Summary

When listing details for any CRD, if there's any reference to another CRD on the web console, the name should be clickable and take the user to the corresponding CRD details page. 

This is not the case for cluster names on the SGDbOp screen.

![image](/uploads/d9cb25a69bab9e5e12994866730ea793/image.png)



#### Steps to reproduce

- Enter the web console
- Create any SGDbOp
- Enter the op details
- Cluster name is not clickable


### Expected Behaviour

Any CRD listed on the web console should include a link to see its details.

### Note:
Same issue spotted on SGBackups details.

### Environment

- StackGres version: `1.4.0`

Story points: 4.0
Unify click behavious when clicked on a switch and on its label

### Summary
On the Web Console, clicking on the label of a switch and on the switch itself has the same effect. This is not the case for the `Enable Path Style Addressing` switch: when clicked on the label, the click has no effect.

**Note:** Although this issue was spotted on the `Enable Path Style Addressing` switch, we need to make sure it does not happen on other switches as well.

### Expected Behaviour
Clicking on the label of a switch and on the switch itself should have the same effect.

### Environment
- StackGres version: 1\.4.0

Story points: 8.0
Remove Advanced switch from Azure section

### Summary
On the Object Storage form, the Azure section has an `Advanced Options` switch, but Azure has no Advanced Options. The switch has no effect.

### Possible Solution
Remove the `Advanced Options` switch from the Azure section.

### Environment
- StackGres version: 1\.4.0


### Relevant logs and/or screenshots
![Screenshot_2023-01-16_at_17.02.03](/uploads/54603b16c4b411520e1e29a786dc98bb/Screenshot_2023-01-16_at_17.02.03.png)

Story points: 4.0