Ref #4513: Allow to remote debug the Operator

[essobedo]

fixes #4513

Motivation

Since the code refactoring for Camel-K 2, it is much harder to debug the operator, especially on MacOS. The goal of this task is to provide a way to remote debug the operator in order to be closer to the target environment and to be local OS agnostic.

Modifications:

• Add a debug mode in the makefile to add the required flags at build time to make the program compatible with the remote debugging
• Publish a specific image with delve installed in debug mode
• Configure the pod in such a way that the operator is launched through delve
• Add a doc describing how to use it
• Add MacOS files to git ignore

Release Note

Allow to remote debug the Operator

[essobedo]

@squakez here is the branch showing the idea, please tell me what you think of it. It is not too intrusive and will work whatever the local OS used

[squakez]

I think it's a great idea. I have some minor concerns however related to the fact we're including debugging bits in the production Docker container image. I'd prefer having a separate dockerfile, and a separate Make (ie, make images-debug) to take care of that. In this way the release process is not going to be affected and we still have the possibility to create a debugging image and a separate managment.

In the new Dockerfile, we can use the multistage and use FROM apache/camel-k... image in order to use it as a base. So, I guess the make images-debug will execute make images as a base and later "extend" the process with the new debugging options and a new image. WDYT?

We can leave the business logic and the CLI, that is not going to hurt, though I'd edit the description telling those are valid installation configuration only for a debugger image.

[essobedo]

I think it's a great idea. I have some minor concerns however related to the fact we're including debugging bits in the production Docker container image. I'd prefer having a separate dockerfile, and a separate Make (ie, make images-debug) to take care of that. In this way the release process is not going to be affected and we still have the possibility to create a debugging image and a separate management.

How the release process is affected? I don't get your remark. The content of the image if built with make images is the exact same as before so I don't get the idea of having a separate dockerfile the result will be the same. And if the image is built in debug mode, the tag name won't be the same as it is suffixed by "-debug" and it is only in that case that the image will include debugging bits if you believe that it is not clear enough, I could suffix the name of the image with "-debug" and leave the tag as it is

[squakez]

Okey, I missed the target parameter. It could be good then, though, for maintenance reason I still think it would be easier to have separate Dockerfile, but I leave this to your judgment.

[essobedo]

Okey, I missed the target parameter. It could be good then, though, for maintenance reason I still think it would be easier to have separate Dockerfile, but I leave this to your judgment.

It is not clear to me what is the drawback of this approach in terms of maintenance, could you please clarify? What I can tell is that having a separate Dockerfile means that I will need to deal with 2 Docker images (original + debug) instead of only one since I won't be able to rely on stages anymore which makes the whole debugging process much more cumbersome

[squakez]

Okey, I missed the target parameter. It could be good then, though, for maintenance reason I still think it would be easier to have separate Dockerfile, but I leave this to your judgment.

It is not clear to me what is the drawback of this approach in terms of maintenance, could you please clarify? What I can tell is that having a separate Dockerfile means that I will need to deal with 2 Docker images (original + debug) instead of only one since I won't be able to rely on stages anymore which makes the whole debugging process much more cumbersome

It's a matter of organization (at least the way I prefer organizing the stuff). Having 2 separate configuration makes easy (again, to me) understanding what are the requirement for a "normal" build and which are the ones for a "debug" build. The way I proposed was to have 2 separate dockerfiles, being the debug dockerfile inheriting from the "normal" build. Then, I think we can have a make images-debug that takes care to do 2 builds, the normal make images and some docker build and push of the new debug image.

Said that, it's my personal taste and opinion. I leave to your judgment if you want to follow up these advises or proceed with the PR the way it is.

[essobedo]

Okey, I missed the target parameter. It could be good then, though, for maintenance reason I still think it would be easier to have separate Dockerfile, but I leave this to your judgment.

Unless you have an idea to avoid having to deal with 2 docker images (I insist on that because, during the developing phase, we may need to update the image regularly so it needs to remain as simple as possible), if you don't mind, I rather prefer to keep it as it is, once again it is not too intrusive, it is only a few lines of code and it is even described as a typical use case of the multistage build

[squakez]

LGTM, thanks.