Source Code Availability for Bridge to Kubernetes

[Blackclaws]

Is your feature request related to a problem? Please describe. I've ran into a policy that software directly accessing kubernetes clusters must be vetted/vettable down to the source code.

Describe the solution you'd like Source code for the kubernetes bridge is released so it can be vetted.

Describe alternatives you've considered Not using bridge to kubernetes.

So in general I think this comes down to what the long-term strategy for this project is and what the internal politics around this project are. If it is designed mainly as a driver towards vscode / visual studio and thus source is kept under wraps I guess we won't have sources. If it just isn't ready for general release maybe you can give a timeframe.

If you don't see this happening anytime in the foreseeable future it would help if that would be documented somewhere more prominently, especially because this repository is linked from the official extension page in the vscode marketplace as the repository for the extension,

[daniv-msft]

Thanks @Blackclaws for opening this issue. We indeed plan to make Bridge to Kubernetes open source, and it's just a matter of engineering resources. From a high level view, I'd estimate we will be open source in the next 6 months.

[Blackclaws]

Awesome, great to hear. Looking forward to the release then! If we as the community can provide any help let us know.

[irperez]

@daniv-msft I'm looking forward to that day!

[UnwashedMeme]

I've been trying to get this working in the last couple days and I wanted to see more about what the task types bridge-to-kubernetes.service and bridge-to-kubernetes.resource did. Are there other task types? Why does setting an environment variable on the launch config still appear to get eclipsed by the deployments info? I have 2 services that need seperate KubernetesLocalProcessConfig files -- how are those looked up? is there a param on the task?

In the end I gave up because 1. This doesn't seem to be documented anywhere; 2. I can't even read the code. It's just an opaque non-working system.

We already know the code isn't perfect, you can release it anyways.

[pragyamehta]

Hi @UnwashedMeme, thanks for bringing up your concerns. Currently, we only support the task type bridge-to-kubernetes.resource which is a rename of the earlier one (bridge-to-kubernetes.service).

Regarding the environment variable, please use KubernetesLocalProcessConfig.yaml to set any environment variables that you need during debugging. They will override the environment variable set in the deployment or pod. Below is an example of how to set the same: version: 0.1 env:

• name: FOO value: bar

Depending on the service you are debugging, you may have different configurations for each and thus will have different KubernetesLocalProcessConfig.yamlfiles. Just keep the KubernetesLocalProcessConfig.yamlfile at the root of the folder that you open for debugging the corresponding service and we will detect its presence when you start debugging. For more information, please refer to our documentation documentation. Could you elaborate what we could add to the docs that might be missing?

Going open source is quite close from the top of our backlog. We’re getting there, but we need a bit more time to line up the engineering resources to make it happen. Thanks for your patience!

[UnwashedMeme]

Hi @UnwashedMeme, thanks for bringing up your concerns.

Depending on the service you are debugging, you may have different configurations for each and thus will have different KubernetesLocalProcessConfig.yamlfiles. Just keep the KubernetesLocalProcessConfig.yamlfile at the root of the folder that you open for debugging the corresponding service and we will detect its presence when you start debugging.
...

For more information, please refer to our documentation documentation. Could you elaborate what we could add to the docs that might be missing?

I have two different services with the same root folder (essentially the same build running as two diff pods with two diff args+envvars) -- I added an extra task that bridge-to-kubernetes.resource depends on to cp KubernetesLocalProcessConfig-svc-a.yaml KubernetesLocalProcessConfig.yaml. I had hoped env vars in launch.json would have precendence since the bridge is a preLaunchTask, but alas no.

I tried following https://code.visualstudio.com/docs/containers/parallel-services (vs/vscode doc separation is kinda annoying) but that doesn't seem to work; probably b/c my root folder isn't distinct enough.

Thanks for the awesome work!

[pragyamehta]

Hi @UnwashedMeme Thanks for the additional info! I have opened a bug for not respecting the environment variables in launch config. I believe we used to support it, but I did confirm it is not working anymore. Thanks for bringing it to our notice! I have also logged a bug about there being confusion between VS and VSCode docs because of the interlinking (I presume?). If you could elaborate on what aspects seem confusing, that would help a lot!

The scenario you are trying to enable is an interesting one. This is the first time I have seen anyone use it the way you are describing it. Can you provide the exact repro steps you used, so that we can try to repro it ourselves? I don't think one can open the same folder in a workspace twice, so I am assuming you open the same folder in separate VSCode instances and try to debug both at the same time? I would imagine that might create problems since you are trying to debug the same code from different VSCode instances. What errors do you see? We may not be handling this scenario and showing user-friendly errors in this case. It would be great if you could provide the repro steps!

Thanks!

[daniv-msft]

It took longer than expected, but Bridge to Kubernetes is finally open source! You can find the announcement here: https://github.com/microsoft/mindaro/issues/349

Thank you everyone for your patience, and thank you @elenavillamil, @hsubramanianaks and @qpetraroia for making it happen!