Closed tusharshahrs closed 1 year ago
Found a similar issue, where -
is used instead of _
. Looks like we'd need this to be fixed in upstream pulumi/pulumi.
The SDK generators generally expect type and property names in the Pulumi schema to be PascalCase and camelCase respectively.
For type names, there's no reason why crd2pulumi
couldn't make the names PascalCase, since type names are meaningless at runtime in terms of what is serialized and passed through to the engine to the provider.
Right now the in-memory representation of the schema that crd2pulumi
is generating has types named like:
"types": {
"kubernetes:juice.box.com/v1alpha1:NetworkPolicySpecApps_incoming": {
}
}
When instead it could be named as:
"types": {
"kubernetes:juice.box.com/v1alpha1:NetworkPolicySpecAppsIncoming": {
}
}
For property names, I don't think crd2pulumi
could change the names to camelCase since the property names are passed along to the k8s provider as-is and I don't think the k8s provider is doing any tweaking of property names at runtime.
So for a property like apps_incoming
, crd2pulumi
would have to keep it named like that in the Pulumi schema.
For Python, the property will be emitted in the SDK as apps_incoming
, which is fine for Python, but for other SDKs like Go and Node, the property name will look out-of-place:
type NetworkPolicySpecArgs struct {
Apps_incoming NetworkPolicySpecAppsIncomingArrayInput `pulumi:"apps_incoming"`
}
export interface NetworkPolicySpecArgs {
apps_incoming?: pulumi.Input<pulumi.Input<inputs.juice.v1alpha1.NetworkPolicySpecAppsIncomingArgs>[]>;
}
For Go, we could consider changing the SDK gen to make apps_incoming
be emitted as a field named AppsIncoming
because there is a struct tag on the field which specifies the name that should be used during marshaling, which in this case could remain apps_incoming
. We could similarly change C# SDK gen to do the same.
However, I don't think we can do anything for TypeScript right now since there isn't currently a way to add extra metadata to indicate a different name to use during marshaling, so it'd have to remain apps_incoming
there.
Thanks for the added context, @justinvp - it seems like we ought to be able to do as much as we can here (in crd2pulumi
) and live with the small bit of remaining pain associated with this.
It looks like there may not be much action item within the crd2pulumi
repository in that case. The type names being generated are derived from the Group, Version and Kind of the custom resource in question.
To me, it doesn't make sense to convert a snake cased Kind to pascal case if the CRD explicitly defines a CR with snake case. It would only add confusion when users run a Pulumi output and see a mismatch in GVK in the preview, against what is in the live cluster.
For example:
# pulumi preview when we normalise the Pulumi type to pascal case:
pulumi:pulumi:Stack template-dev create
+ └─ kubernetes:stable.example.com/v1:CronTab cronTabInstance create
GVK: stable.example.com/v1:cron_tab
Furthermore, official k8s API naming conventions strongly suggest that camel casing should be used for field names.
@kpitzen WDYT would be the next best steps here?
I think the fix is as simple as this: https://github.com/pulumi/crd2pulumi/commit/f90e016d105d3ed8e11ed0ceb61494878eb2de4c
With that change, I get:
__all__ = [
'NetworkPolicySpecAppsIncomingArgs',
'NetworkPolicySpecAppsOutgoingArgs',
'NetworkPolicySpecNamespacesIncomingArgs',
'NetworkPolicySpecNamespacesOutgoingArgs',
'NetworkPolicySpecArgs',
]
It would only add confusion when users run a Pulumi output and see a mismatch in GVK in the preview, against what is in the live cluster.
This isn't about changing the names of resources. It's about changing the names of nested types, which get erased when the values are serialized and sent to the engine (they essentially turn into a map[string]any). These type names will not be displayed as part of a Pulumi operation.
@justinvp Ah, gotcha. Yes, I believe that one line fix would do it. I was testing with a simplified CRD, that didn't have nested fields, so there were no nested types to modify. Thanks for the clarification. Do you want to submit a PR for that change?
What happened?
CRD has fields named with underscores: For example, the networkpolicy.yaml will have:
The main thing is the
_
inapps_incoming
. We need to translate lower snake case to camel and back dynamically. The fields to be named properly per language, but translate back to the proper names in the provider.This is what the
networkpolicies/pulumi_crds/juice/v1alpha1/_inputs.py
will end up as after crd2pulumi is ran:This is what the
networkpolicies/pulumi_crds/juice/v1alpha1/outputs.py
will end up as:Expected Behavior
When using the snippet below
after running crd2pulumi, the python generated code at:
networkpolicies/pulumi_crds/juice/v1alpha1/__inputs.py
would show up as:There are no
_
anymore and now everything is camelCase.The code for
networkpolicies/pulumi_crds/juice/v1alpha1/outputs.py
would also be correct:There are no
_
anymore and now everything is camelCase.Steps to reproduce
networkpolicy.yaml
with the following code:Run
crd2pulumi --pythonPath ./networkpolicies networkpolicy.yaml
Check out the new crds that are created: cd networkpolicies/pulumi_crds/pulumi_crds/juice/v1alpha1
Go to where the
_inputs.py outputs.py
are:cd networkpolicies/pulumi_crds/juice/v1alpha1/
The output for
_inputs.py
will show up in theall
block as:Notice that there is a
_
and no camelCasing for the first 4 items.The output from
outputs.py
will show up asNotice that there is a
_
and no camelCasing for the last 4 items.Output of
pulumi about
Output from ❯ crd2pulumi version
Additional context
No response
Contributing
Vote on this issue by adding a 👍 reaction. To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).