Fix aliases for several resource kinds

[lblackstone]

Proposed changes

The following resource Kinds had the wrong Group
specified in the aliases:

• ClusterRole
• ClusterRoleBinding
• Ingress
• NetworkPolicy
• PriorityClass
• Role
• RoleBinding

Related issues (optional)

Fixes #989

[lukehoban]

Is there a source of truth for this data we can use to make sure we are right here (and link to from source code)? Is it in Kubernetes API docs anywhere? Is it in Kubernetes source code anywhere?

[lblackstone]

Yeah, it's in the API docs

[lukehoban]

Yeah, it's in the API docs

Specifically - you mean the "Other API versions of this object exist:" annotations? Do we now map precisely the same kinds as specified in these docs? Can we pull this from API specs somehow? (that is - where is this data for the API docs sourced from, and why can't we source from the same place)?

[lblackstone]

Specifically - you mean the "Other API versions of this object exist:" annotations?

Yes

Do we now map precisely the same kinds as specified in these docs?

Yes

Can we pull this from API specs somehow? (that is - where is this data for the API docs sourced from, and why can't we source from the same place)?

It's generated from the OpenAPI spec, so it's doable with some caveats:

1. We don't currently alias every resource Kind. We were concerned that some apiVersions might not be compatible, so we started with the subset that we were sure about. I'm still unsure about this.
2. These don't change often, so that might be more work than it's worth.
3. Old, deprecated versions are sometimes removed from the OpenAPI specs, which means the aliases would also be removed (barring additional logic to work around that). That's probably not what we want.

[lukehoban]

We should take this PR as-is to fix the current issues.

That said:

We don't currently alias every resource Kind. We were concerned that some apiVersions might not be compatible, so we started with the subset that we were sure about. I'm still unsure about this.

It sounds rather suspicious to me that we are trying to outsmart Kubernetes' own notion of what resouce kinds are "the same". Any place we don't match we will run into very weird issues with Helm/YAML, and just with overall model compatibility. Barring any explicit Pulumi-specific issues, I'm inclined to align with the platform.

These don't change often, so that might be more work than it's worth.

I may be biased, but I think it is basically always going to be worth it to derive things from official specs than to rely on ourselves to do ongoing manual work. It removes so much risk around long term maintenance and just human error to derive these sorts of things programmatically.

Old, deprecated versions are sometimes removed from the OpenAPI spec

Seems we have to fundamentally solve for this anyway - we very much don't want to drop old resource types in general, even if they are deprecated.

[lblackstone]

Tracking further work in #828