quarkusio
Kubernetes extension evolution
Description
The Kubernetes extension is quite central to Quarkus. It has evolved with Quarkus itself quite organically. It is now quite complex and still contains compatibility layers for things that have been deprecated for more than 5 years. It would be quite beneficial to remove these compatibility layers to simplify the code and its maintenance.
Another aspect is the fact that it relies on dekorate, a project that is now more or less in maintenance mode, creating a fragile base to keep building on.
Finally, work on moving the Kubernetes client dev service the new architecture has uncovered fundamental incompatibilities with how the Kubernetes extension and the new Dev Service architecture function and their respective assumptions.
This issue is meant as a starting point to discuss work on the evolution of the Kubernetes support in Quarkus.
/cc @cescoffier @geoand @holly-cummins @ozangunalp
Analysis
Preliminary analysis of dekorate usage is that it would be a significant effort to remove it from the Kubernetes extension for several reasons:
- it's pretty deeply embedded in how the extension functions.
- it's exposed externally to 3rd party extensions via build items and is, at the very least, used in the Helm extension
![quarkus-bot[bot] avatar](https://avatars.githubusercontent.com/in/90234?v=4 "Published by a pub.dev verified publisher"){kind=small}
still contains compatibility layers for things that have been deprecated for more than 5 years
This one is quite easy, we should remove them :)
Another aspect is the fact that it relies on dekorate, a project that is now more or less in maintenance mode, creating a fragile base to keep building on.
If the implication is that we should use some other new project that does more or less the same thing, then I don't see how that's an improvement
Finally, https://github.com/quarkusio/quarkus/pull/49944 has uncovered fundamental incompatibilities with how the Kubernetes extension and the new Dev Service architecture function and their respective assumptions.
I read the discussion on the PR and couldn't really understand what those fundamental issues are. Care to elaborate?
Another aspect is the fact that it relies on dekorate, a project that is now more or less in maintenance mode, creating a fragile base to keep building on.
If the implication is that we should use some other new project that does more or less the same thing, then I don't see how that's an improvement
Agreed. The question is to determine how big of a change it would be to remove Quarkus' dependency on dekorate and, indeed, what to replace it with (if anything). Another aspect is that Quarkus also currently provides build items that leak and/or rely on dekorate so that's another thing to consider.
Finally, #49944 has uncovered fundamental incompatibilities with how the Kubernetes extension and the new Dev Service architecture function and their respective assumptions.
I read the discussion on the PR and couldn't really understand what those fundamental issues are. Care to elaborate?
The core of the issue is that the Kubernetes client extension fixes the client configuration at build time, which is fundamentally incompatible with exposing a client connecting to a dynamically created cluster. The gist of the discussion were centered around the fact that many there needs to be 2 different client instances: one used for deployment that could indeed be fixed at build time but that wouldn't be available to users, and another, made available to users, that could connect to clusters that are not known at build time.
Agreed. The question is to determine how big of a change it would be to remove Quarkus' dependency on dekorate and, indeed, what to replace it with (if anything). Another aspect is that Quarkus also currently provides build items that leak and/or rely on dekorate so that's another thing to consider.
I think this boils down to whether whoever wants this is willing to willing write something simpler and then maintain it
The core of the issue is that the Kubernetes client extension fixes the client configuration at build time, which is fundamentally incompatible with exposing a client connecting to a dynamically created cluster. The gist of the discussion were centered around the fact that many there needs to be 2 different client instances: one used for deployment that could indeed be fixed at build time but that wouldn't be available to users, and another, made available to users, that could connect to clusters that are not known at build time.
It sounds fixable, but I have to admit that I haven't looked at the Kubernetes code in a while
The core of the issue is that the Kubernetes client extension fixes the client configuration at build time, which is fundamentally incompatible with exposing a client connecting to a dynamically created cluster. The gist of the discussion were centered around the fact that many there needs to be 2 different client instances: one used for deployment that could indeed be fixed at build time but that wouldn't be available to users, and another, made available to users, that could connect to clusters that are not known at build time.
It sounds fixable, but I have to admit that I haven't looked at the Kubernetes code in a while
And that is another part of the issue. When we look at doing the conversion, step 1 is "this doesn't work," and step 2 is "ok, what is the kubernetes extension actually trying to do, and then we can make that work," and then we get stuck. :) Our understanding of what problem is being solved by the extension and its desired capabilities is ... limited.
The Kubernetes extension is quite central to Quarkus. It has evolved with Quarkus itself quite organically. It is now quite complex and still contains compatibility layers for things that have been deprecated for more than 5 years. It would be quite beneficial to remove these compatibility layers to simplify the code and its maintenance.
Let's remove them.
Another aspect is the fact that it relies on dekorate, a project that is now more or less in maintenance mode, creating a fragile base to keep building on.
Agreed, we just need a migration plan.
Finally, https://github.com/quarkusio/quarkus/pull/49944 has uncovered fundamental incompatibilities with how the Kubernetes extension and the new Dev Service architecture function and their respective assumptions.
This is a pretty annoying one. I'm not a user so, like @holly-cummins I'm not too sure what this is doing. Honestly, I would rater break/remove this feature if we don't understand it. We can re-add it later once we understand.
The Kubernetes extension is quite central to Quarkus. It has evolved with Quarkus itself quite organically. It is now quite complex and still contains compatibility layers for things that have been deprecated for more than 5 years. It would be quite beneficial to remove these compatibility layers to simplify the code and its maintenance.
Let's remove them.
Started on it. Think I might have found some issue in the process, PR(s) incoming.
Update: no issues found after all 😸
Regarding deprecations, there are confusing things… For example: https://github.com/quarkusio/quarkus/blob/7b130b0a664ded2f77368a84024b79a05b5f7ee9/extensions/kubernetes/vanilla/deployment/src/main/java/io/quarkus/kubernetes/deployment/OpenShiftConfig.java#L103 but that is still used logically in the property that is supposed to replace it: https://github.com/quarkusio/quarkus/blob/7b130b0a664ded2f77368a84024b79a05b5f7ee9/extensions/kubernetes/vanilla/deployment/src/main/java/io/quarkus/kubernetes/deployment/OpenShiftConfig.java#L111 so I'm not sure what the desired behavior is supposed to be here: either the first property shouldn't be deprecated or some other mechanism should be used to decide whether init tasks should be externalize as Jobs or something else?