Kubernetes extension evolution

[metacosm]

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

To be added…

(links to analysis docs containing architecture design work, requirements gathering, etc)

[quarkus-bot]

/cc @geoand (kubernetes)

[geoand]

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, #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?

[metacosm]

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.

[geoand]

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

[holly-cummins]

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.