Is there a way to freeze Kubernetes configuration on Kubernetes dev services extension ?

[philippart-s]

Hi,

When I use the dev services with the Kubernetes extension it generates a KUBECONFIG configuration, which works fine.
But (there is always a but 😉) when Quarkus reloads, the default port and certificats are regenerated and change.

It's not very practical as all other tools (for example kubectl) need to be updated with the new values.

Is there a way to freeze the Kubernetes configuration?

Thanks

[quarkus-bot[bot]]

/cc @geoand (devservices,kubernetes), @holly-cummins (devservices), @iocanel (kubernetes), @ozangunalp (devservices), @radcortez (config)

[geoand]

cc @metacosm @LarsSven

[LarsSven]

I think this is a fair comment, working with kubectl and the dev service is a very common usecase for inspecting the state during testing, and it's quite tedious I have to say.

I admittedly don't use live reload that much, but especially for shutdown and startup this would be hard to freeze. The fact that dev services run on a random port is a good thing (though it can be overridden).

Wouldn't it be better to simplify the process of connecting to a new dev service instance, e.g. through the dev UI? Rather than freezing an existing config. Maybe have an in-UI terminal that immediately works, or a direct kubeconfig download that has ports and credentials preconfigured?

[LarsSven]

Of course freezing the credentials cross-run could also be quite doable, maybe add a config option for preconfigured credentials for the dev service cluster?

[philippart-s]

The fact that dev services run on a random port is a good thing (though it can be overridden)

@LarsSven in the dev services documentation (The fact that dev services run on a random port is a good thing (though it can be overridden) I don't find the parameter that allows to fix the port?

Maybe have an in-UI terminal that immediately works, or a direct kubeconfig download that has ports and credentials preconfigured?

Not sure because, for my usage, I have also another applications, for example an Insomnia that send requests, and it must be re-configure at each reload.

[LarsSven]

If you have external applications that aren't quarkus applications, wouldn't it make more sense to make quarkus dev point at an external cluster, rather than pointing the external application at the dev service cluster?

You can make the k8s dev service be an existing running cluster

[LarsSven]

Also the kubernetes extension indeed doesn't seem to have a port override, like some other extensions do have

[philippart-s]

If you have external applications that aren't quarkus applications, wouldn't it make more sense to make quarkus dev point at an external cluster, rather than pointing the external application at the dev service cluster?

You can make the k8s dev service be an existing running cluster

yes you're right, it's that as I use JOSK extension, I can test the whole things (the operator and the app that the operator manage) with my dev services K8s.
I know it's laziness 😉