Consolidate platform deploy into control-plane

[gciavarrini]

Summary

Move full-stack Compose and Helm packaging from api-gateway into

Details

• Compose: dcm-ui, optional SP profiles, API on :8080 (no Traefik)
• Helm chart migrated without gateway; routes hit control-plane directly
• compose-down disconnects Kind and cleans up legacy deploy_default
• Runbook and Kind setup docs under deploy/

Supersedes dcm-project/api-gateway#40

Fixes

FLPATH-4239

---

Assisted-By: Claude (Anthropic)
Signed-off-by: Gloria Ciavarrini gciavarrini@redhat.com

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0)

1. Broken Postgres probes ✓ Resolved 🐞 Bug ≡ Correctness

Description

The Helm Postgres StatefulSet readiness/liveness probes pass the literal string "$(POSTGRES_USER)"
to pg_isready, so Postgres will likely never become Ready/Healthy and the stack can’t start
correctly.

Code

deploy/helm/dcm/templates/postgres.yaml[R42-61]

+          readinessProbe:
+            exec:
+              command:
+                - pg_isready
+                - -U
+                - $(POSTGRES_USER)
+                - -d
+                - postgres
+            initialDelaySeconds: 5
+            periodSeconds: 5
+            timeoutSeconds: 5
+            failureThreshold: 5
+          livenessProbe:
+            exec:
+              command:
+                - pg_isready
+                - -U
+                - $(POSTGRES_USER)
+                - -d
+                - postgres

Evidence

The probes are exec-form and include $(POSTGRES_USER) as a literal argv element; nothing in the
manifest runs a shell to expand it, so pg_isready is called with the wrong username.

deploy/helm/dcm/templates/postgres.yaml[42-61]
deploy/helm/dcm/templates/secret-db.yaml[8-13]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`deploy/helm/dcm/templates/postgres.yaml` defines exec probes that include `$(POSTGRES_USER)` as an argument. Kubernetes exec probes do not perform shell expansion, so `pg_isready` receives the literal username and the probe fails.
### Issue Context
Postgres credentials are provided via env vars from the DB Secret. The probes should use the configured username value reliably.
### Fix Focus Areas
- deploy/helm/dcm/templates/postgres.yaml[42-61]
### Implementation notes
- Option A (simplest): template the username directly from values:
- replace `$(POSTGRES_USER)` with `{{ .Values.postgres.user }}`.
- Option B: use `sh -c` so env var expansion works:
- `command: ["sh","-c","pg_isready -U \"$POSTGRES_USER\" -d postgres"]` (and same for liveness).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. KubeVirt namespace env mismatch ✓ Resolved 🐞 Bug ≡ Correctness

Description

deploy/RUN.md tells users to set KUBERNETES_NAMESPACE, but deploy/compose.yaml reads
KUBEVIRT_NAMESPACE for interpolation, so following the runbook leaves the provider targeting the
default namespace.

Code

deploy/compose.yaml[R72-77]

+      NATS_URL: "nats://nats:4222"
+      SERVICE_MANAGER_ENDPOINT: *dcm-registration-url
+      PROVIDER_NAME: ${KUBEVIRT_PROVIDER_NAME:-kubevirt-service-provider}
+      PROVIDER_ENDPOINT: "http://${KUBEVIRT_PROVIDER_NAME:-kubevirt-service-provider}:8081/api/v1alpha1/vms"
+      KUBERNETES_NAMESPACE: ${KUBEVIRT_NAMESPACE:-default}
+      KUBERNETES_KUBECONFIG: /kubeconfig

Evidence

The compose file sets the container env var KUBERNETES_NAMESPACE from
${KUBEVIRT_NAMESPACE:-default}, but the runbook instructs exporting KUBERNETES_NAMESPACE, which
compose never references.

deploy/compose.yaml[66-79]
deploy/RUN.md[24-33]
deploy/RUN.md[160-166]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The runbook instructs `export KUBERNETES_NAMESPACE=...`, but the compose file uses `${KUBEVIRT_NAMESPACE:-default}` to populate the container's `KUBERNETES_NAMESPACE`. This makes the documented env var ineffective.
### Issue Context
The container env var name (`KUBERNETES_NAMESPACE`) is correct for the kubevirt-service-provider; the mismatch is in the host-side variable used for compose substitution.
### Fix Focus Areas
- deploy/compose.yaml[66-80]
- deploy/RUN.md[24-33]
- deploy/RUN.md[160-167]
### Implementation notes
Pick one consistent approach:
- Preferred: change compose to `KUBERNETES_NAMESPACE: ${KUBERNETES_NAMESPACE:-default}`.
- Or update the runbook + config table to instruct `KUBEVIRT_NAMESPACE` instead (less ideal, since it diverges from the in-container env var name).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Three-tier kubeconfig secret mismatch ✓ Resolved 🐞 Bug ≡ Correctness

Description

The Helm three-tier demo SP mounts the *-k8s-container-kubeconfig secret when
threeTierDemoServiceProvider.kubeconfig is set, but that secret is only created when
k8sContainerServiceProvider.kubeconfig is set; this can make the three-tier pod fail to schedule
due to a missing Secret.

Code

deploy/helm/dcm/templates/three-tier-demo-service-provider.yaml[R51-66]

+            {{- if .Values.threeTierDemoServiceProvider.kubeconfig }}
+            - name: SP_K8S_KUBECONFIG
+              value: /kubeconfig/kubeconfig
+            {{- end }}
+          {{- if .Values.threeTierDemoServiceProvider.kubeconfig }}
+          volumeMounts:
+            - name: kubeconfig
+              mountPath: /kubeconfig
+              readOnly: true
+          {{- end }}
+      {{- if .Values.threeTierDemoServiceProvider.kubeconfig }}
+      volumes:
+        - name: kubeconfig
+          secret:
+            secretName: {{ include "dcm.fullname" . }}-k8s-container-kubeconfig
+      {{- end }}

Evidence

The three-tier deployment references {{ fullname }}-k8s-container-kubeconfig for its volume, but
the only template that creates that Secret is the k8s-container SP template’s kubeconfig branch.

deploy/helm/dcm/templates/three-tier-demo-service-provider.yaml[51-66]
deploy/helm/dcm/templates/k8s-container-service-provider.yaml[44-55]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`three-tier-demo-service-provider.yaml` mounts `{{ fullname }}-k8s-container-kubeconfig` when `.Values.threeTierDemoServiceProvider.kubeconfig` is set, but the chart only creates that Secret when `.Values.k8sContainerServiceProvider.kubeconfig` is set. This creates a configuration-dependent install failure.
### Issue Context
The three-tier provider may need its own kubeconfig secret, or the chart should explicitly reuse the k8s-container secret only when it is guaranteed to exist.
### Fix Focus Areas
- deploy/helm/dcm/templates/three-tier-demo-service-provider.yaml[51-66]
- deploy/helm/dcm/templates/k8s-container-service-provider.yaml[44-55]
### Implementation notes
One of:
- Add a dedicated Secret for `threeTierDemoServiceProvider.kubeconfig` (e.g., `{{ fullname }}-three-tier-kubeconfig`) and mount that.
- Or change the three-tier template to mount `{{ fullname }}-k8s-container-kubeconfig` only when `k8sContainerServiceProvider.kubeconfig` is set (and document that requirement), otherwise omit the mount and rely on in-cluster config.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

4. compose-down not docker-safe ✓ Resolved 🐞 Bug ☼ Reliability

Description

make compose-down uses $(CONTAINER_ENGINE) network exists and force-removes networks, but
CONTAINER_ENGINE can be docker; the existence check/force flags are not portable and errors are
suppressed, so teardown can silently leave external containers connected and networks undeleted.

Code

Makefile[R59-71]

compose-down:
-	$(COMPOSE) -f $(COMPOSE_FILE) down -v
+	@for network in deploy_default $(COMPOSE_NETWORK); do \
+		if $(CONTAINER_ENGINE) network exists "$$network" 2>/dev/null; then \
+			for c in $$($(CONTAINER_ENGINE) ps -a --filter network=$$network -q 2>/dev/null); do \
+				$(CONTAINER_ENGINE) network disconnect -f "$$network" "$$c" 2>/dev/null || true; \
+			done; \
+		fi; \
+	done; \
+	COMPOSE_PROJECT_NAME=deploy $(COMPOSE) -f $(COMPOSE_FILE) down -v --remove-orphans 2>/dev/null || true; \
+	$(COMPOSE) -f $(COMPOSE_FILE) down -v --remove-orphans 2>/dev/null || true; \
+	for network in deploy_default $(COMPOSE_NETWORK); do \
+		$(CONTAINER_ENGINE) network rm -f "$$network" 2>/dev/null || true; \
+	done

Evidence

The Makefile auto-detects docker/podman but compose-down relies on network exists and forced
removal while suppressing errors, making teardown behavior diverge across engines and potentially
leaving stale state.

Makefile[3-9]
Makefile[59-71]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`compose-down` attempts to detect/remove networks using engine-specific commands and suppresses failures. When `CONTAINER_ENGINE=docker`, the disconnect/removal logic may not run as intended, leaving stale networks and making subsequent runs flaky.
### Issue Context
The Makefile explicitly supports both podman and docker, so teardown should use commands common to both engines (or branch per engine).
### Fix Focus Areas
- Makefile[3-9]
- Makefile[59-71]
### Implementation notes
- Replace `$(CONTAINER_ENGINE) network exists` with a portable inspect, e.g. `$(CONTAINER_ENGINE) network inspect $$network >/dev/null 2>&1`.
- Avoid non-portable flags (like `-f` on `network rm`) or apply them conditionally based on `CONTAINER_ENGINE`.
- Consider logging when cleanup actions are skipped/fail instead of blanket `2>/dev/null || true`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

[qodo-code-review]

PR Summary by Qodo

Consolidate DCM platform Compose + Helm deploy into control-plane repo
✨ Enhancement 📝 Documentation ⚙️ Configuration changes 🕐 40+ Minutes

Walkthroughs

Description

• Add full platform Docker Compose stack including dcm-ui and optional service providers.
• Migrate Helm chart into control-plane, removing Traefik/api-gateway and routing directly to
  control-plane.
• Document local runbook and Kind networking setup for service provider profiles and demos.

Diagram

graph TD
  Dev([Developer]) --> MF["Makefile targets"] --> Cfg["deploy/compose.yaml"] --> CP["control-plane API"] --> DS[("Postgres + NATS")]
  Cfg --> UI["dcm-ui"]
  Cfg --> SP[["Service providers"]]
  Dev --> Helm["deploy/helm/dcm"] --> K8s[("Kubernetes / OpenShift")]
  K8s --> CP --> DS
  K8s --> UI
  K8s --> SP
  subgraph Legend
    direction LR
    _act(["Actor"]) ~~~ _svc["Service"] ~~~ _db[("Datastore")] ~~~ _cfg["Config/Chart"]
  end

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Keep api-gateway/Traefik as the public entrypoint

• ➕ Centralizes routing/edge concerns in a dedicated component
• ➕ Avoids changing client assumptions about a gateway URL
• ➖ Adds an extra hop and operational component for local and cluster deploys
• ➖ Duplicates packaging across repos; harder to keep versions aligned

2. Publish Helm/Compose as a standalone 'deploy' repository or Helm dependency

• ➕ Clear separation between app code and deployment artifacts
• ➕ Makes it easier to share deploy assets across multiple repos
• ➖ Introduces another release/versioning surface and coordination overhead
• ➖ Harder for contributors to discover and update deploy assets alongside code changes

Recommendation: The PR’s approach (owning Compose + Helm packaging in control-plane and routing directly to control-plane) is the simplest operational model now that control-plane is the monolith entrypoint. The main thing to watch is keeping UI/provider environment variables and image-tag pinning consistent across Compose and Helm; otherwise the consolidation is a net reduction in moving parts versus maintaining an api-gateway/Traefik layer.

File Changes

Enhancement (1)

Makefile Add provider profile compose target and robust compose-down cleanup +26/-4

Add provider profile compose target and robust compose-down cleanup

• Introduces COMPOSE_PROJECT_NAME defaults and a compose-up-with-providers target for profile-based provider startup. Updates compose-down to disconnect external containers (e.g., Kind) and remove both legacy and current networks to avoid teardown failures.

Makefile

---

Documentation (6)

.env.example Point full-stack env configuration to deploy/.env.example +3/-0

Point full-stack env configuration to deploy/.env.example

• Adds guidance that full platform stack configuration (UI, providers, version pins) lives under deploy/ and references deploy/.env.example.

.env.example

---

README.md Document platform deploy layout, compose stack contents, and image tagging +37/-4

Document platform deploy layout, compose stack contents, and image tagging

• Updates repo structure and run instructions to describe the platform stack (including dcm-ui) and references deploy/.env.example. Adds a new Platform deploy section documenting Compose/Helm locations, direct :8080 API access (no Traefik), and image tag conventions/pinning.

README.md

---

RUN.md Add runbook for Compose-based platform and provider profiles +190/-0

Add runbook for Compose-based platform and provider profiles

• Provides a comprehensive local runbook for starting/stopping the platform stack and enabling each service provider via Compose profiles. Includes verification steps, configuration table, and pointers to Kind/provider docs and Helm installs.

deploy/RUN.md

---

k8s-container-sp-kind.md Document Kind networking workaround for Podman + Compose connectivity +97/-0

Document Kind networking workaround for Podman + Compose connectivity

• Adds step-by-step Kind setup instructions to connect the Kind control-plane container to the Compose network with a SAN-valid alias and generate a container-reachable kubeconfig. Explains why this is required and how compose-down cleans up networking.

deploy/docs/k8s-container-sp-kind.md

---

three-tier-app-kind.md Add end-to-end Kind guide for three-tier demo provider provisioning +271/-0

Add end-to-end Kind guide for three-tier demo provider provisioning

• Documents running the three-tier demo provider on Kind (dependent on k8s-container SP), registering placement policy, and provisioning a Pet Clinic catalog instance via CLI or curl. Includes verification and troubleshooting guidance.

deploy/docs/three-tier-app-kind.md

---

README.md Document Helm installation and enabling optional service providers +87/-0

Document Helm installation and enabling optional service providers

• Provides cluster install instructions for Kubernetes and OpenShift, including route/ingress guidance and port-forward examples. Documents enabling each optional service provider and uninstall behavior for persistent volumes.

deploy/helm/dcm/README.md

---

Other (16)

.env.example Add full platform env example for providers and image version pins +37/-0

Add full platform env example for providers and image version pins

• Adds a deploy-specific environment template including service provider variables, Kind/OpenShift-related settings, and per-service image version pinning.

deploy/.env.example

---

compose.override.example.yaml Provide optional OpenShift override for three-tier demo web exposure +17/-0

Provide optional OpenShift override for three-tier demo web exposure

• Adds an example Compose override enabling OpenShift Route-based exposure settings for the three-tier demo service provider, with kubeconfig mounting instructions.

deploy/compose.override.example.yaml

---

compose.yaml Expand Compose to full platform stack with UI, providers, and image pinning +115/-3

Expand Compose to full platform stack with UI, providers, and image pinning

• Reframes the Compose stack as the full DCM platform, adds image/pull_policy configuration and a shared DCM registration URL anchor. Introduces optional service providers behind profiles and adds dcm-ui wired directly to the control-plane service endpoint on :8080.

deploy/compose.yaml

---

Chart.yaml Introduce DCM Helm chart metadata +9/-0

Introduce DCM Helm chart metadata

• Adds Helm v2 chart definition for deploying the DCM platform components into Kubernetes/OpenShift.

deploy/helm/dcm/Chart.yaml

---

_helpers.tpl Add Helm helper templates for naming, labels, image tags, and init waits +59/-0

Add Helm helper templates for naming, labels, image tags, and init waits

• Defines reusable helpers for chart naming/labels, image tag resolution, selector labels, and a postgres readiness initContainer used by dependent deployments.

deploy/helm/dcm/templates/_helpers.tpl

---

acm-cluster-service-provider.yaml Add Helm template for ACM cluster service provider deployment +94/-0

Add Helm template for ACM cluster service provider deployment

• Creates an optional deployment/service for the ACM cluster service provider with environment-driven configuration and an optional kubeconfig Secret mount.

deploy/helm/dcm/templates/acm-cluster-service-provider.yaml

---

control-plane.yaml Add Helm template for control-plane deployment and exposure (Route/Ingress) +112/-0

Add Helm template for control-plane deployment and exposure (Route/Ingress)

• Defines the control-plane Deployment and Service, wiring DB and NATS settings and waiting for postgres readiness. Adds optional OpenShift Route and optional Kubernetes Ingress configuration.

deploy/helm/dcm/templates/control-plane.yaml

---

dcm-ui.yaml Add Helm template for DCM UI deployment and exposure (Route/Ingress) +99/-0

Add Helm template for DCM UI deployment and exposure (Route/Ingress)

• Defines an optional dcm-ui Deployment/Service with configuration pointing directly at the control-plane service. Adds optional OpenShift Route and optional Kubernetes Ingress configuration.

deploy/helm/dcm/templates/dcm-ui.yaml

---

k8s-container-service-provider.yaml Add Helm template for k8s-container service provider with RBAC or kubeconfig +125/-0

Add Helm template for k8s-container service provider with RBAC or kubeconfig

• Adds an optional k8s-container SP Deployment/Service. Supports either in-cluster RBAC via ServiceAccount/Role/RoleBinding or an explicit kubeconfig Secret, and exposes external service type configuration.

deploy/helm/dcm/templates/k8s-container-service-provider.yaml

---

kubevirt-service-provider.yaml Add Helm template for KubeVirt service provider deployment +61/-0

Add Helm template for KubeVirt service provider deployment

• Creates an optional KubeVirt service provider Deployment with NATS + registration wiring and optional kubeconfig Secret mount.

deploy/helm/dcm/templates/kubevirt-service-provider.yaml

---

nats.yaml Add Helm template for NATS StatefulSet with JetStream storage +60/-0

Add Helm template for NATS StatefulSet with JetStream storage

• Deploys NATS as a StatefulSet with persistent storage and a headless Service exposing client and monitoring ports.

deploy/helm/dcm/templates/nats.yaml

---

postgres.yaml Add Helm template for PostgreSQL StatefulSet and init SQL +96/-0

Add Helm template for PostgreSQL StatefulSet and init SQL

• Deploys PostgreSQL as a StatefulSet with readiness/liveness probes, persistent storage, and init scripts via ConfigMap to create required databases (control-plane and three-tier-sp).

deploy/helm/dcm/templates/postgres.yaml

---

secret-db.yaml Add Helm Secret for DB credentials shared by components +13/-0

Add Helm Secret for DB credentials shared by components

• Defines a Secret containing both application DB vars and POSTGRES_* vars for postgres, control-plane, and dependent services.

deploy/helm/dcm/templates/secret-db.yaml

---

three-tier-demo-service-provider.yaml Add Helm template for three-tier demo service provider deployment +81/-0

Add Helm template for three-tier demo service provider deployment

• Creates an optional three-tier demo SP Deployment/Service, including postgres readiness init, DB connectivity, dependency on k8s-container SP, and optional kubeconfig Secret mount.

deploy/helm/dcm/templates/three-tier-demo-service-provider.yaml

---

values.yaml Add Helm values for core services, exposure options, and optional providers +82/-0

Add Helm values for core services, exposure options, and optional providers

• Defines default images, storage sizes, global tag override, OpenShift route/Kubernetes ingress toggles, and per-provider enablement and configuration values.

deploy/helm/dcm/values.yaml

---

01-create-databases.sql Create three-tier demo provider database in local postgres init +1/-0

Create three-tier demo provider database in local postgres init

• Extends local postgres init SQL to create the three-tier-sp database alongside the control-plane database.

deploy/postgres-init/01-create-databases.sql

---

ⓘ You are approaching your monthly quota for Qodo. Upgrade your plan

[gabriel-farache]

Should the SP deployment files be there? I mean this is not related to the control plane in any way so it feels weird to have them here

[machacekondra]

Should the SP deployment files be there? I mean this is not related to the control plane in any way so it feels weird to have them here

Same it was for api-gateway. We need to add it somewhere, either here, or have some utilities repo, where the deployment script will be. But to me it make sense to have script to deploy control-plane and document how to plugin-in the providers here.

[gabriel-farache]

Should the SP deployment files be there? I mean this is not related to the control plane in any way so it feels weird to have them here

Same it was for api-gateway. We need to add it somewhere, either here, or have some utilities repo, where the deployment script will be. But to me it make sense to have script to deploy control-plane and document how to plugin-in the providers here.

Yes but in the api gateway it made sense as it was a collection of services that were "put into contact", here it's not the case

If the goal is to deploy the SP, then the deployments files should be in the SP repo no?
If the goal is to to have all the components the DCM project officially supports, then a dedicated repo make more sense to me.

And in any case, the "how to deploy" should be documented in the website

[machacekondra]

Yes but in the api gateway it made sense as it was a collection of services that were "put into contact", here it's not the case

Api-gateway was used to connect the "internal" services, like placement, policy, srpm and catalog. It was not used to connect the SPs and the "control-plane", that has it's own API. The deployment of SPs should not be there, with same logic as it should not be here.

If the goal is to to have all the components the DCM project officially supports, then a dedicated repo make more sense to me.

To me it's not. It should be more about deploy the control plane, and tell the user how to connect service providers. Rather then deploy everything in once, like we had it before.

[gabriel-farache]

Yes but in the api gateway it made sense as it was a collection of services that were "put into contact", here it's not the case

Api-gateway was used to connect the "internal" services, like placement, policy, srpm and catalog. It was not used to connect the SPs and the "control-plane", that has it's own API. The deployment of SPs should not be there, with same logic as it should not be here.

But the api gateway repo had the compôse file that started the core DCM components and the SP, I am not sure to follow you here

If the goal is to to have all the components the DCM project officially supports, then a dedicated repo make more sense to me.

To me it's not. It should be more about deploy the control plane, and tell the user how to connect service providers. Rather then deploy everything in once, like we had it before.

So IIUC, the helm charts related to the SP must be removed here and we should only keep the DCM control plane related ones, right?

and tell the user how to connect service providers

so doc and then charts can be placed in the SP repo, no?

[jenniferubah]

Related to the discussion above - Keeping DCM control-plane deployment independent and separate from the SPs make more sense to me.
Also, maybe we should consolidate all the SPs (4 and counting) into a single repo and have the deployment chart and documentation on how to connect to DCM inside the single SP repo. This will avoid duplication across the individual SP repo.

[gciavarrini]

Having one easy helm chart to use for deploy the full stack is helpful IMO.
If having it here or in a dedicated gh repo, well i don't have a preference.

so doc and then charts can be placed in the SP repo, no?

@gabriel-farache, regarding this there are multiple SPs, so how do you want to handle that?

Also, having the helm chart here and then moving them in a dedicated repo is feasible, so we may revise the decision later. I don't have a strong opinion TBH. Happy to follow what the majority prefers.

[gciavarrini]

Related to the discussion above - Keeping DCM control-plane deployment independent and separate from the SPs make more sense to me. Also, maybe we should consolidate all the SPs (4 and counting) into a single repo and have the deployment chart and documentation on how to connect to DCM inside the single SP repo. This will avoid duplication across the individual SP repo.

@jenniferubah not sure, having a dedicated GH repo for each SP it's very modular and may mimic the "community style".

Regarding the duplication, what part is concerning? for sure the registration and status update are duplicated, but what else?

[gabriel-farache]

Having one easy helm chart to use for deploy the full stack is helpful IMO. If having it here or in a dedicated gh repo, well i don't have a preference.

so doc and then charts can be placed in the SP repo, no?

@gabriel-farache, regarding this there are multiple SPs, so how do you want to handle that?

Also, having the helm chart here and then moving them in a dedicated repo is feasible, so we may revise the decision later. I don't have a strong opinion TBH. Happy to follow what the majority prefers.

Sure we can revisit, my main concern is that this repo is about control-plane, not the SP, not the whole solution for demo
AFAIK, the charts will be delivered to customers at some point, it's not just for local dev and demo, right?

I would put a chart in each SP repo with the proper doc on how to plug it to the control plane deployed resources.

The SP may disappear and be replaced by the agent soon but the same would apply

[machacekondra]

Sure we can revisit, my main concern is that this repo is about control-plane, not the SP, not the whole solution for demo

That's correct, the question is if the benefit of maintaining separate repo is worth it at current stage.

In general when user want to deploy DCM, he would deploy control-plane, and then he would go and deploy relevant service-providers, which he likes. I think that those service-providers(env agents) should have different deployment process then control-plane.
Let's say you want openshift agent(k8s, kubevirt, storage, ACM). You go to openshift and deploy a pod that handle those SPs.
Now let's say you want VMware agent, you go to VMware and deploy OVA agent that handle those SPs.
Same for Openstack, etc.

This IMHO should be eventually documented way of depoying DCM. So long term this looks like an "dcm-install" repo, with relevant script. But for now, to me it looks no issue to have those scripts in any folder here, or what would be the problem?

[gabriel-farache]

Sure we can revisit, my main concern is that this repo is about control-plane, not the SP, not the whole solution for demo

That's correct, the question is if the benefit of maintaining separate repo is worth it at current stage.

In general when user want to deploy DCM, he would deploy control-plane, and then he would go and deploy relevant service-providers, which he likes. I think that those service-providers(env agents) should have different deployment process then control-plane. Let's say you want openshift agent(k8s, kubevirt, storage, ACM). You go to openshift and deploy a pod that handle those SPs. Now let's say you want VMware agent, you go to VMware and deploy OVA agent that handle those SPs. Same for Openstack, etc.

This IMHO should be eventually documented way of depoying DCM. So long term this looks like an "dcm-install" repo, with relevant script. But for now, to me it looks no issue to have those scripts in any folder here, or what would be the problem?

no problem in term of deployment but more in term of logic and then maintenance and support when the charts become deliverables.
I will agree with you that at this point it's harmless to have all in the same repo, as long as we have an issue to track it and address it in jira at some point in the future (when we will have to provide maintainable deliverables) if we do not want to address it now

[gciavarrini]

Sure we can revisit, my main concern is that this repo is about control-plane, not the SP, not the whole solution for demo

That's correct, the question is if the benefit of maintaining separate repo is worth it at current stage.
In general when user want to deploy DCM, he would deploy control-plane, and then he would go and deploy relevant service-providers, which he likes. I think that those service-providers(env agents) should have different deployment process then control-plane. Let's say you want openshift agent(k8s, kubevirt, storage, ACM). You go to openshift and deploy a pod that handle those SPs. Now let's say you want VMware agent, you go to VMware and deploy OVA agent that handle those SPs. Same for Openstack, etc.
This IMHO should be eventually documented way of depoying DCM. So long term this looks like an "dcm-install" repo, with relevant script. But for now, to me it looks no issue to have those scripts in any folder here, or what would be the problem?

no problem in term of deployment but more in term of logic and then maintenance and support when the charts become deliverables. I will agree with you that at this point it's harmless to have all in the same repo, as long as we have an issue to track it and address it in jira at some point in the future (when we will have to provide maintainable deliverables) if we do not want to address it now

I've created this epic https://redhat.atlassian.net/browse/FLPATH-4400

Please take a look, and let me know what you think.
If the team agree, I think we can proceed with this PR as is and have a dedicated effort according to the jira epic.

@gabriel-farache @machacekondra @jenniferubah

[gabriel-farache]

with the epic to track the effort for PROD ready deployment (https://redhat.atlassian.net/browse/FLPATH-4400) I am good with this PR

[jenniferubah]

Related to the discussion above - Keeping DCM control-plane deployment independent and separate from the SPs make more sense to me. Also, maybe we should consolidate all the SPs (4 and counting) into a single repo and have the deployment chart and documentation on how to connect to DCM inside the single SP repo. This will avoid duplication across the individual SP repo.

@jenniferubah not sure, having a dedicated GH repo for each SP it's very modular and may mimic the "community style".

Good point - I was mostly thinking from an organizational perspective since we own/manage these SPs but forgot that these are individual domains which need to be maintained independently.

Regarding the duplication, what part is concerning? for sure the registration and status update are duplicated, but what else?

I was thinking deployment and documentation as well. However, you're right, it makes sense to keep SPs in separate GH repos.