adding deployment yamls

[shekhar316]

This PR adds deployment YAMLs with desired configuration for optimizer.

Summary by Sourcery

Add Kubernetes manifests to deploy the kruize-optimizer service on Kubernetes and OpenShift clusters.

Deployment:

• Introduce a Kubernetes deployment and ClusterIP service manifest for kruize-optimizer in the monitoring namespace.
• Add an OpenShift-specific deployment manifest for kruize-optimizer with Swagger disabled and a shared ClusterIP service configuration.

[sourcery-ai]

Reviewer's Guide

Adds Kubernetes/OpenShift deployment and service YAMLs for the kruize-optimizer component, defining how it runs, which image and ports it uses, and the environment configuration for its runtime behavior.

Sequence diagram for kruize-optimizer bulk scheduling and webhook flow

sequenceDiagram
    participant Scheduler
    participant Kruize_optimizer
    participant Kruize_service
    participant Webhook_consumer

    Scheduler->>Kruize_optimizer: Trigger bulk API at interval KRUIZE_BULK_SCHEDULER_INTERVAL
    Kruize_optimizer->>Kruize_service: Call bulk API using KRUIZE_URL
    Kruize_service-->>Kruize_optimizer: Return optimization results
    Kruize_optimizer->>Webhook_consumer: POST callback to KRUIZE_WEBHOOK_URL

Loading

File-Level Changes

Change	Details	Files
Introduce a standard Kubernetes deployment and service manifest for kruize-optimizer in the monitoring namespace.	Create a Deployment running a single kruize-optimizer replica using the quay.io/rh-ee-shesaxen/optimizer:0.1-test image with port 8080 exposed. Configure environment variables for Swagger, Kruize service URL, state refresh, bulk scheduler behavior, webhook URL, target label handling, and default datasource/metadata/metric profiles. Define a ClusterIP Service selecting the kruize-optimizer pod by label and exposing port 8080.	deployment/deployment_kind.yaml
Introduce an OpenShift-specific deployment manifest for kruize-optimizer with Swagger disabled but sharing similar runtime configuration, plus a Service definition.	Create an OpenShift Deployment for kruize-optimizer (namespace: openshift) using the same image, port configuration, and environment variables but with Swagger disabled. Provide the same scheduler, webhook, label, and default profile configuration as the Kubernetes deployment. Define a ClusterIP Service for kruize-optimizer in the monitoring namespace exposing port 8080 and selecting pods via the app label.	deployment/deployment_openshift.yaml

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey - I've found 2 issues, and left some high level feedback:

• In deployment_openshift.yaml, the Deployment is created in the openshift namespace while the Service is created in the monitoring namespace, which will prevent the Service from selecting the pods as written; consider aligning these namespaces.
• The two deployment YAMLs share a lot of duplicated configuration; consider extracting common parts (e.g., via kustomize bases/overlays or a single template with environment-specific patches) to reduce drift and make future changes easier.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- In `deployment_openshift.yaml`, the Deployment is created in the `openshift` namespace while the Service is created in the `monitoring` namespace, which will prevent the Service from selecting the pods as written; consider aligning these namespaces.
- The two deployment YAMLs share a lot of duplicated configuration; consider extracting common parts (e.g., via kustomize bases/overlays or a single template with environment-specific patches) to reduce drift and make future changes easier.

## Individual Comments

### Comment 1
<location path="deployment/deployment_openshift.yaml" line_range="20-21" />
<code_context>
+    spec:
+      containers:
+        - name: kruize-optimizer
+          image: quay.io/rh-ee-shesaxen/optimizer:0.1-test
+          imagePullPolicy: Always
+          ports:
+            - containerPort: 8080
</code_context>
<issue_to_address>
**suggestion (bug_risk):** Reconsider hard-coded test image tag with `imagePullPolicy: Always` for non-dev environments

Using a mutable `0.1-test` tag with `imagePullPolicy: Always` can lead to non-reproducible rollbacks and unexpected image changes in shared/production-like clusters. If this is used beyond local/dev, switch to a stable, immutable tag (or digest) and adjust the pull policy, ideally parameterized per environment.

Suggested implementation:

```
        - name: kruize-optimizer
          # Use a stable, immutable tag here; override per environment via your deployment tooling (Helm values, kustomize overlays, or env-specific manifests)
          image: quay.io/rh-ee-shesaxen/optimizer:0.1
          imagePullPolicy: IfNotPresent

```

To fully implement environment-specific behavior:
1. In your deployment tooling (e.g., Helm, kustomize, or overlay manifests), make `image` and `imagePullPolicy` configurable so that:
   - Dev can use a `-test` tag and `Always`.
   - Non-dev/prod uses an immutable tag (or digest) and `IfNotPresent`.
2. Ensure any CI/CD pipelines or environment overlays override this base manifest with the appropriate values for each environment.
</issue_to_address>

### Comment 2
<location path="deployment/deployment_kind.yaml" line_range="1-10" />
<code_context>
+apiVersion: apps/v1
</code_context>
<issue_to_address>
**suggestion:** The two deployment manifests duplicate a lot of config that could be templatized

`deployment_kind.yaml` and `deployment_openshift.yaml` differ only in a few env-specific values (e.g., namespace, ENABLE_SWAGGER), which makes config drift likely. Consider extracting a shared base and expressing env differences via overlays/values (e.g., kustomize bases/overlays, Helm, or env substitution) so env vars, ports, and image settings are defined in one place.

Suggested implementation:

```
metadata:
  name: kruize-optimizer
  # Namespace is set via kustomize/overlays or environment-specific tooling
  # to avoid duplicating manifests per environment.
  # namespace:
  labels:

```

To fully implement your suggestion and remove config drift between `deployment_kind.yaml` and `deployment_openshift.yaml`, you will also need to:

1. **Introduce kustomize (recommended) or similar templating:**
   - Create a `deployment/base/kustomization.yaml` that lists `deployment_kind.yaml` as a resource.
   - For each environment (e.g., kind, OpenShift), create overlays:
     - `deployment/overlays/kind/kustomization.yaml` with:
       - `namespace: monitoring` (or appropriate namespace).
       - Any `patches` or `configMapGenerator`/`secretGenerator` needed for env-specific values like `ENABLE_SWAGGER`.
     - `deployment/overlays/openshift/kustomization.yaml` with:
       - `namespace: <openshift-namespace>`.
       - Patches that set `ENABLE_SWAGGER`, service account, securityContext, etc.

2. **Refactor `deployment_openshift.yaml`:**
   - Either:
     - Remove the duplicated full Deployment manifest and replace it with an overlay that patches the shared base (`deployment_kind.yaml`).
     - Or convert it into a kustomize overlay patch (e.g., strategic merge patch) that only contains the differing fields (namespace, env vars, possibly ports or image overrides).

3. **Template env vars and other duplicated fields:**
   - In the parts of `deployment_kind.yaml` you didn’t show (containers, env, ports, image), keep only the common values.
   - Move env-specific fields like `ENABLE_SWAGGER`, image tag overrides, or OpenShift-specific annotations into the overlays as patches.

This will ensure that Deployment configuration (env vars, ports, image settings) is defined in one place and environment differences are expressed in small, focused overlays.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[dinogun]

@shekhar316 Lets use kustomize for this as there is a lot of duplication. Also needed when we support additional targets

[shekhar316]

@dinogun I have updated the deployment scripts to use Kustomize. Can you please review it again? Thanks.