Support for non-overlay components in codegen for pulumi-kubernetes provider

[EronWright]

Description

This PR enhances the codegen for dotnet to allow the pulumi-kubernetes provider to have non-overlay components. Previously all components were overlays and didn't require codegen.

The specific change is to not apply the KubernetesResource base class when the resource is a component. It is inappropriate to use KubernetesResource in this case because it extends CustomResource not ComponentResource.

The sdkgen test suite for kubernetes20 mode was updated with a new example resource:

• a non-overlay component resource (code)

The fix is manifested here.

Checklist

• I have run make tidy to update any new dependencies
• I have run make lint to verify my code passes the lint check
  • I have formatted my code using gofumpt

• I have added tests that prove my fix is effective or that my feature works

• I have run make changelog and committed the changelog/pending/<file> documenting my change

• Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version

[pulumi-bot]

Changelog

[uncommitted] (2024-03-04)

Features

• [sdkgen/dotnet] Support for non-overlay components in codegen for pulumi-kubernetes provider
  #15490

[EronWright]

@lblackstone would you happen to know the origin story of the KubernetesResource base class? e.g. would something break if a new component resource weren't extending it? I do see the KubernetesResource class being used in ParseYamlObject.

Also, I just noticed that the old ConfigGroup extends CollectionComponentResource (ref). But it seems to be related to resource references, and maybe the native system will work in lieu.

[lblackstone]

@lblackstone would you happen to know the origin story of the KubernetesResource base class? e.g. would something break if a new component resource weren't extending it? I do see the KubernetesResource class being used in ParseYamlObject.

Also, I just noticed that the old ConfigGroup extends CollectionComponentResource (ref). But it seems to be related to resource references, and maybe the native system will work in lieu.

As far as I recall, that was copied over from the original TS implementation. I think the extra base class may have added k8s-specific get methods, or something along those lines. I don't know offhand what the implications of changing it would be.

[Frassle]

This really ought to have a test in pkg/codegen/testing/test/testdata if just to make sure we don't break it.

[EronWright]

A follow-up about KubernetesResource, I came across some usage that, I think, illustrates its purpose:

    /// <summary>
    /// Base component for containers of Kubernetes resources.
    /// </summary>
    public abstract class CollectionComponentResource : ComponentResource
    {
        /// <summary>
        /// Returns a resource defined by the given name.
        /// </summary>
        /// <param name="name">Resource name.</param>
        /// <param name="namespaceName">Optional namespace, e.g. "kube-prometheus-exporter-kubernetes".</param>
        /// <typeparam name="T">The type of the resource.</typeparam>
        public Output<T> GetResource<T>(string name, string? namespaceName = null)
            where T : KubernetesResource
    
...

From this I would say that KubernetesResource is the base class for any resource that represents a Kubernetes object (or list). The component resources would not fall under that category, nor will the MLC ones extend CollectionComponentResource.