Uploaded image for project: 'OpenShift GitOps'
  1. OpenShift GitOps
  2. GITOPS-7416

Provide option for editing resource requests and limits for gitops-plugin component

XMLWordPrintable

    • Provide option for editing resource requests and limits for gitops-plugin component
    • L
    • False
    • Hide

      None

      Show
      None
    • False
    • RFE-7543Ability to edit gitops-plugin & cluster components resource request/limit
    • In Progress
    • 0% To Do, 0% In Progress, 100% Done
    • Hide
      With this update, the resource requests and limits for the cluster and the GitOps plugin component, can now be configured through the GitopsService Custom Resource (CR) using the following fields:
        - spec.consolePlugin.backend.resources
        - spec.consolePlugin.gitopsPlugin.resources

      This enhancement allows administrators to define distinct or identical resource allocations for the GitOps Plugin component and GitOps plugin components, providing greater flexibility in resource management.

      For more information, see the documentation<add main documentation link once merged>

      Example:
      ```
      apiVersion: pipelines.openshift.io/v1alpha1
      kind: GitopsService
      metadata:
        name: cluster
      spec:
        consolePlugin:
          backend:
            resources:
              limits:
                cpu: 100m
                memory: 1Gi
              requests:
                cpu: 100m
                memory: 1Gi
          gitopsPlugin:
            resources:
              limits:
                cpu: 200m
                memory: 2Gi
              requests:
                cpu: 100m
                memory: 1Gi
      ```


      Show
      With this update, the resource requests and limits for the cluster and the GitOps plugin component, can now be configured through the GitopsService Custom Resource (CR) using the following fields:   - spec.consolePlugin.backend.resources   - spec.consolePlugin.gitopsPlugin.resources This enhancement allows administrators to define distinct or identical resource allocations for the GitOps Plugin component and GitOps plugin components, providing greater flexibility in resource management. For more information, see the documentation<add main documentation link once merged> Example: ``` apiVersion: pipelines.openshift.io/v1alpha1 kind: GitopsService metadata:   name: cluster spec:   consolePlugin:     backend:       resources:         limits:           cpu: 100m           memory: 1Gi         requests:           cpu: 100m           memory: 1Gi     gitopsPlugin:       resources:         limits:           cpu: 200m           memory: 2Gi         requests:           cpu: 100m           memory: 1Gi ```

      Epic Goal

      As a GitOps user, I would like to configure resource requests and limits for the gitops-plugin component. This is already supported for other GitOps components such as repo-server and application-controller.

      Why is this important?

      See parent JIRA

      Scenarios

      1. ...

      Other Considerations

      • <Call out anything explicitly as Out of Scope?>
      • <Call out internal and external dependencies?>
      • <Are there any known previous works?>
      • <Any unanswered questions?>

      Definition of Ready

      • The epic has been broken down into stories.
      • Stories have been scoped.
      • The epic has been stack ranked.

      Definition of Done

      • Code Complete:
        • All code has been written, reviewed, and approved.
      • Tested:
        • Unit tests have been written and passed.
        • Integration tests have been completed.
        • System tests have been conducted, and all critical bugs have been fixed.
        • Tested on OpenShift either upstream or downstream on a local build.
      • Documentation:
        • User documentation or release notes have been written.
      • Build:
        • Code has been successfully built and integrated into the main repository / project.
      • Review:
        • Code has been peer-reviewed and meets coding standards.
        • All acceptance criteria defined in the user story have been met.
        • Tested by reviewer on OpenShift.
      • Deployment:
        • The feature has been deployed on OpenShift cluster for testing.
      • Acceptance:
        • Product Manager or stakeholder has reviewed and accepted the work.

              rh-ee-nakhil Nittala Akhil
              rh-ee-anjoseph Anand Francis Joseph
              Crimson
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated:
                Resolved: