Allow specify request and limit in sginstanceprofile for non-production

Currently sginstanceprofile only allow to specify a single value for cpu and memory that will be used for both request and limit each of those resources.

Some non-production environment requires to specify both to make it possible to create a cluster that can be deployed in node with less resources and are not critical environment.

Proposed change for the SGInstanceProfile CRD to allow to specify a request for resources different from the limit:

apiVersion: stackgres.io/v1
kind: SGInstanceProfile
spec:
  cpu: <string> # CPU(s) (cores) limit for every Pod of an `SGCluster`. Please note that
     # every Pod contains not only the `patroni` (Patroni and Postgres) container, but
     # several other sidecar containers. While the majority of the resources are
     # devoted to the main Postgres container, some CPU is needed for the
     # sidecars.
     # 
     # The number of cores set is applied only to the `patroni` container of each Pod while the
     # other sidecars will not be subjected to any resource restriction.
     # 
     # A minimum of 2 cores is recommended.
  memory: <string> # RAM limit for every Pod of an `SGCluster`. The suffix `Mi` or `Gi`
     # specifies Mebibytes or Gibibytes, respectively. Please note that every
     # Pod contains not only the `patroni` (Patroni and Postgres) container, but several
     # other sidecar containers. While the majority of the resources are devoted
     # to the main Postgres container, some RAM is needed for the sidecars.
     # 
     # The amount of RAM set is applied only to the `patroni` container of each Pod while the
     # other sidecars will not be subjected to any resource restriction.
     # 
     # A minimum of 2-4Gi is recommended.
  requests:
    cpu: <string> # CPU(s) (cores) requested for every Pod of an `SGCluster`. Please note that
       # every Pod contains not only the `patroni` (Patroni and Postgres) container, but
       # several other sidecar containers. While the majority of the resources are
       # devoted to the main Postgres container, some CPU is needed for the
       # sidecars.
       # 
       # The number of cores set is applied only to the `patroni` container of each Pod while the
       # other sidecars will not be subjected to any resource restriction.
       # 
       # A minimum of 2 cores is recommended.
       #
       # If not specified or if field `.spec.nonProductionOptions.enableInstanceProfileRequests`
       # is not set to `true` in the associated `SGCluster` will be equals to `.spec.cpu`.
    memory: <string> # RAM requested for every Pod of an `SGCluster`. The suffix `Mi` or `Gi`
       # specifies Mebibytes or Gibibytes, respectively. Please note that every
       # Pod contains not only the `patroni` (Patroni and Postgres) container, but several
       # other sidecar containers. While the majority of the resources are devoted
       # to the main Postgres container, some RAM is needed for the sidecars.
       # 
       # The amount of RAM set is applied only to the `patroni` container of each Pod while the
       # other sidecars will not be subjected to any resource restriction.
       # 
       # A minimum of 2-4Gi is recommended.
       #
       # If not specified or if field `.spec.nonProductionOptions.enableInstanceProfileRequests`
       # is not set to `true` in the associated `SGCluster` will be equals to `.spec.memory`.

The fields .spec.requests.cpu and .spec.requests.memory will be optional and their values will be the same as respectively .spec.cpu and .spec.memory if the former are not specified.

A flag enableInstanceProfileRequests will be added under section .spec.nonProductionOptions in SGCluster in order to be able to use the new proposed fields of SGInstanceProfile.

apiVersion: stackgres.io/v1
kind: SGCluster
spec:
  nonProductionOptions:
    enableInstanceProfileRequests: <boolean> # If true, will allow to use fields `.spec.requests.cpu` and `.spec.requests.memory` from `SGInstanceProfile`. By default is `false`.

Acceptance criteria:

  • Implement the feature
  • Test the feature
  • Create issue for UI @jose_oss_pg TODO
Edited by Jose OSS