ckcp and ingress

[fgiloux]

context

#68 makes possible to run kcp in a pod on an OpenShift cluster. This does however not provide a global loadbalancer, which redirects traffic to the right workload cluster. there is a PoC in kcp, which leverages envoy.

goal

To extend the capabilities of ckcp to have a central point for ingresses.

rational

This is needed among others for Tekton triggers and services that leverage it.

[adambkaplan]

I think we will need this for our "Tekton Results" proxy in addition to the Triggers use case. The results proxy will behave more like a true stateless app envisioned by the proof of concept.

[bnallapeta]

@fgiloux with the latest merge of #117, is this issue fixed? Or you want to keep it open until kcp release-0.7 until ingress is thoroughly tested?

[fgiloux]

@bnallapeta:

• yes we need to wait for kcp 0.7 to fix the ingress issue
• we then need to call what is provided in #117 as part of the ckcp deployment

[Roming22]

@fgiloux My understanding is that this issue can be closed since we've integrated the glbc and PaC. Is that correct?

[fgiloux]

@Roming22 this issue was specifically for ckcp. Things have evolved on the kcp side from envoy to kcp-glbc. I would see it as complete when kcp-glbc gets deployed with ckcp. I don't think it is the case today.

[Mo3m3n]

I have already started testing kcp-glbc with ckcp locally. Now that am reading about this, I have assigned it to myself and will try to come with a PR in the future

[gabemontero]

@Mo3m3n and I just had a discussion in slack around ckcp/ingress and this tracker cam up in the discussion, so I'm placing some bread crumbs here, (even though we will need associated Jiras to make the work trackers happy)

I've mentioned the scenario that drove my interest before in the Oct 4 cabal, and we'll discuss again in the Nov 1 cabal. Specifically the hacbs jvm build service also is a scenario that will benefit from this work.

Why does hacbs jvm build service need it (a revisit of that Oct 4 discussion)?

• the analysis of build dependencies done by jvm build service starts from an appstudio build pipelinerun sending its maven download dependency http requests to a maven proxy provided by the jvm build service
• this proxy is separate from the jvm build service controller
• an instance of it will run in each user's hacbs user workspace in kcp, not the hacbs service workspace the jvm build service controller runs in
• as such, this maven proxy cache can ultimately run in a different workload cluster then the build's pipeline run
• hence the need for ingress vs. the local cluster DNS name for the proxy's associated k8s service object that is currently used

How will hacbs jvm build service team use this ckcp/kcp-glbc/ingress setup?

• we are at the point now where the "developer flow" for hacbs jvm build service on top of kcp works off of: -- ckcp + openshift -- a bootstrap in preview mode from https://github.com/redhat-appstudio/infra-deployments where we tell the boostrap to automatically deploy pipeline-service into the openshift cluster -- which lead to a call to https://github.com/redhat-appstudio/infra-deployments/blob/main/hack/install-pipeline-service.sh -- where we hope after this item is done, that install of pipeline service includes kcp-glbc and ingress support
• and we can then add the definition of ingress, apibinding objects, etc. to the list of objects related to that maven proxy deployment that are populated into hacbs user workspace as part of its setup
• where the first question ^^ is what load balancer do we deploy in the workload cluster for jvm-build-service (i.e. do we exactly follow suit to what is being done for PaC and/or Tekton Results or do we diverge?)
• and once all of this is tested in this fashion, we can move to deploying things to kcp cps stable.

@stuartwdouglas @ralphbean @sbose78 @adambkaplan @Michkov FYI

[Roming22]

KCP being out of the picture, I'm closing this issue as deprecated.