[Story] KubernetesApi Discovery Mechanism

[andrewazores]

Describe the feature

3.0 should bring forward the Kubernetes API discovery system from 2.x, where Cryostat gains a dependency on the fabric8 client and uses a Watcher or Informer on Endpoints objects to discover suitable target applications.

Anything other information?

No response

[tthvo]

Hey @andrewazores, I wanna help out this issue if anyone is not taking on this yet.

[andrewazores]

You will probably find cryostatio/cryostat-helm#111 helpful for testing out cryostat3 and your progress in a k8s setup. There is also the k8s smoketest in this repo, but I haven't tried it in a long time and a lot of things have otherwise changed about the smoketest since, so I'm not confident that that still works.

[tthvo]

Ah thanks! I will look into! If anything, I could help update the smoketest long the way.

[andrewazores]

If you're motivated to do so then sure, but I think having -helm updated to deploy 3.0 is a good replacement for the k8s smoketest. I initially just put that k8s smoketest together because it was relatively simple and easy, but now that the smoketest.bash has gotten more complicated and uses compose file overrides and variable interpolations etc. it may not be so straightforward.

[tthvo]

Right, my knowledge of the smoketest is pretty outdated now so it would be pretty difficult indeed. I will utilize your changes on helm chart mostly. Tho, I guess if later on the operator/helm is fully updated to deploy 3.0 then we can use it for manual deploy and remove this k8s smoketest? If so, I might just not spend time on it.

[andrewazores]

Yea, I think longer term the k8s smoketest will go away, and we will just use -helm and -operator like before when we need to deploy into k8s/OpenShift.

[andrewazores]

There will be a bit of a behaviour change, planned for 2.4.1, that needs to be forward-ported to the new implementation as well:

https://github.com/cryostatio/cryostat/issues/1861

[andrewazores]

I think for 3.0 we can/should think about changing this default behaviour. Leaving the configuration for a list of port names and list of port numbers to match on makes sense, but perhaps we should default these both to empty lists and let it be up to the user to configure these. It is already the case in 3.0 that all the built-in discovery mechanisms are turned off by default and require the user to opt-in to each relevant one for their deployment scenario, so this change would also make sense from that angle.

[tthvo]

Sounds good to me! I will go in that direction to default to empty :))

[andrewazores]

@tthvo how's this going? Any progress to share yet?

[tthvo]

Oh sorry not much functional yet...still reading and porting parts from v2. I will wrap up the operator's scorecard asap and continue on this issue :))

[tthvo]

Opened #325 for progress tracking btw :D