-
Notifications
You must be signed in to change notification settings - Fork 117
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
helm: apply namespace default transformation #217
Comments
To recap offline discussion, I am guessing that This should be doable, let me see if we can fit it into M18. |
As a workaround for now, you should be able to use a transformation to update the namespace. function addNamespace(o: any) {
if (o !== undefined) {
if (o.metadata !== undefined) {
o.metadata.namespace = "my-new-namespace";
} else {
o.metadata = {namespace: "my-new-namespace"}
}
}
}
const nginxController = new k8s.helm.v2.Chart(
"nginx-ingress",
{
repo: "stable",
version: "0.31.0",
chart: "nginx-ingress",
transformations: [addNamespace]
}); |
I ran into further complications trying to implement default behavior for the
Considering these factors, I'm going to close out this issue as "won't fix". There are several possible workarounds depending on the chart:
const provider = new k8s.Provider("foo", {namespace: "bar"});
const chart = new k8s.helm.v2.Chart("example", {
repo: "stable",
chart: "not-a-real-chart",
}, {providers: {kubernetes: provider}});
|
This is really unfortunate to see. I think a good middle ground would be to introduce an option At least this way working with helm will be a lot easier (everyone won't have to implement the transformation themselves). |
@lblackstone If It doesn't seem okay to just not have charts behave the same when deployed through Pulumi as when deployed "normally" through Helm. Other thoughts on how to address the user concerns here if fixing this namespacing issue directly really isn't an issue? |
In our case, and I think in most people’s case these days, we don’t want to use tiller. This was actually a huge point as to why we just adopted helm through Pulumi. Helm 3 actually does away with tiller. I’m not sure how they are solving the same issue, but I would look into replicating their logic. |
I had the same issue and ended up adding the |
Do you know if helm is really looking to do that? I found this issue via helm/charts#14773 when I reported that Jenkins wasn't working as intended. |
There are quite a few instances where charts have done that already: https://github.com/helm/charts/search?l=YAML&q=Release.namespace I suspect they'd accept a PR, considering that Tiller is going away and anybody using More relevant links: |
FWIW: here is my workaround transformer: export const addNamespace = (namespace: string) => (obj: any) => {
if (!obj) return;
if (
[
"ServiceAccount",
"Role",
"RoleBinding",
"ConfigMap",
"Service",
"DaemonSet",
"Deployment"
].includes(obj.kind)
) {
if (!obj.metadata) {
obj.metadata = { namespace };
} else {
if (!obj.metadata.namespace) obj.metadata.namespace = namespace;
}
}
}; To be used like: ...
transformations: [addNamespace("some-namespace")]
... It only defaults namespace for those specific resource kinds (so no CRD handling). |
To expand on @pjoe's answer. This is what I needed to get things working: import { ResourceTransformation } from '@pulumi/pulumi'
/** addNamespace transformation sets namespace to desired string.
* Useful for helm charts `transformations: [addNamespace('ns')]` */
export const addNamespace = (namespace: string): ResourceTransformation => (
args
) => {
if (!args) return args
if (
[
'Binding',
'ConfigMap',
'Endpoints',
'Event',
'LimitRange',
'PersistentVolumeClaim',
'Pod',
'PodTemplate',
'ReplicationController',
'ResourceQuota',
'Secret',
'ServiceAccount',
'Service',
'Challenge',
'Order',
'ControllerRevision',
'DaemonSet',
'Deployment',
'ReplicaSet',
'StatefulSet',
'LocalSubjectAccessReview',
'HorizontalPodAutoscaler',
'CronJob',
'Job',
'SealedSecret',
'CertificateRequest',
'Certificate',
'Issuer',
'Order',
'Lease',
'AuthCode',
'AuthRequest',
'Connector',
'OAuth2Client',
'OfflineSessions',
'Password',
'RefreshToken',
'SigningKey',
'Event',
'Ingress',
'PodMetrics',
'Ingress',
'NetworkPolicy',
'PodDisruptionBudget',
'RoleBinding',
'Role',
].includes(args.props.kind)
) {
if (!args.props.metadata) {
args.props.metadata = { namespace }
} else {
if (!args.props.metadata.namespace)
args.props.metadata.namespace = namespace
}
}
return args
} You can find all namespaced resources with: |
Reactivating this - as it continues to be a pain point. It’s unclear how Helm 3 (without Tiller) handles this - and why Pulumi can’t do something compatible with Helm 3 to have better compatibility with charts without the need for manual transformations. If we do believe there is nothing we can do in Pulumi - we should audit top 20 charts and contribute fixes to them to improve our compatibility. |
I think what helm 3 is basically doing when installing a chart is something like:
So the namespace is not applied during templating (except for |
I took another look at this, and have a WIP PR up based on the input from @pjoe and @brandonkal. It needs some more testing, but I think it should handle the majority of cases. The main problem will be |
This should be fixed now, including for CustomResource kinds. If you encounter cases where this isn't working properly, please open a new issue with details. |
Had to temporarily revert this PR, so reopening the issue until the next release, which will include this fix again. |
It would be great if |
When I specify
namespace
on a chart via pulumi it seems this only populates theRelease.Namespace
template variable, whereas when runninghelm install --namespace <namespace>
tiller seems to actively add anmetadata.namespace
entry before applying the templates to the cluster. Many charts unfortunately don’t have theRelease.Namespace
variable but instead rely on the aforementioned tiller transformation.Pulumi should apply the same transformation as default, if the
namespace
attribute has been set on the component. This providers better UX, is closer tohelm install
and avoids a lot of surprises for new pulumi users.The default may be as simple as
Corresponding slack conversation: https://pulumi-community.slack.com/archives/C84L4E3N1/p1537573095000100
The text was updated successfully, but these errors were encountered: