cdk8s synth pulls namespace from current context

[burner1024]

Description of the bug:

When using a Helm chart, namespace for resources would be taken from current context in ~/.kube/config.
That is unexpected.

Reproduction Steps:

        new Helm(this, 'karpenter', {
            chart: 'oci://public.ecr.aws/karpenter/karpenter',
            values: {
                serviceAccount: {
                    annotations:
                        { 'eks.amazonaws.com/role-arn': values.controllerRoleArn }
                },
                settings: {
                    clusterName: values.clusterName,
                    interruptionQueue: values.interruptionQueue,
                },
                webhook: { enabled: false },
            },
            version: values.version,
        });

Easily worked around by explicitly setting namespace = this.namespace.

But this is surprising behaviour, which will lead to generating different manifest from the same code on different machines.

Error Log:

Environment:

• Framework Version: 2.198.283
• OS:

Other:

---

This is 🐛 Bug Report

[shinebayar-g]

I believe this is how helm template works. It should be easily reproducible by running the equivalent helm template command.

[burner1024]

Maybe. But the very reason to use cdk8s is to forget the nightmare that Helm is.

[shinebayar-g]

Not maybe, it is. You're not escaping anything. You're literally calling helm template.

[burner1024]

Whatever, doesn't really matter, the ask stands.

[iliapolo]

I don't see this as an issue to be honest. We aren't trying to go against helm behavior by using the Helm construct, we're just trying to bring in helm alongside with cdk8s. Changing this would be a breaking change and may also be unexpected to some users.

Specifying the namespace property seems like a reasonable way to customize the helm behavior to whatever the user wants.

[burner1024]

Whether an issue is breaking or not should only influence when it's handled, not whether it's handled at all.

I don't know in which situation would the same code generating different result be expected and desirable.
I'm fairly sure this will come up again, though.
So, whatever you think is best.

[iliapolo]

Whether an issue is breaking or not should only influence when it's handled, not whether it's handled at all.

True.

I'm going to keep this open as a p2 to see what folks have to say.

For contributors though: Please do not submit a PR for this before checking in with the team, since this is technically a breaking change