Clarify how k8s.yaml.ConfigFile.resourcePrefix works

[jkodroff]

File: themes/default/content/registry/packages/kubernetes/api-docs/yaml/configfile/_index.md

We should add a little note for clarity that explained that resourcePrefix applies to the names of the Pulumi child resources of the ConfigGroup, not the metadata.name of the K8s resources.

I would also maybe add some text to the description that explain a little more explicitly how the resource works (i.e. that it creates a Pulumi resource for each K8s resource in the target file).

[jkodroff]

This should be moved to pulumi/kubernetes - my bad for clicking the "Request a Change" link.

[jkodroff]

@lblackstone If you can confirm that I just need to hand-edit the schema (or whatever the way to fix is), I can fix this.

[lblackstone]

I transferred the issue for you. You're correct about needing to edit the schema, but I can't recall if it's directly in the pulumi-kubernetes repo, or if there was a separate place for overlay docs. @rquitales or @EronWright should be able to point you in the right direction.

[EronWright]

To add some background, the ConfigGroup resource is implemented separately for each language SDK, and the behavior of resourcePrefix seems to vary across the SDKs. I believe that in the dotnet SDK, the resourcePrefix is indeed applied to the object name, but not in the other SDKs.

I think we should provide the following guidance:

1. Users should set resourcePrefix to the component name, as recommended in the docs:

In general, the name of the component resource instance itself (the name parameter passed into the component resource constructor) should be used as part of the name of the child resources.

2. The resourcePrefix property should be considered immutable. If a change to the prefix is necessary, be sure to apply aliases to the new resources.

A good default:

const configGroup = new kubernetes.yaml.ConfigGroup("my-config-group", {
    resourcePrefix: "my-config-group",
});

I'm currently developing a "v2" of the ConfigGroup resource, that is MLC-based and will be available side-by-side with the current implementations. I don't plan to apply the prefix to the object name in this implementation.
#2844