Scaffold APIKeys Key resource

[justinsb]

Implement the APIKeys Key resource via terraform (which is an oddity in terraform, implemented via DCL).

Also implement a mock.

[justinsb]

This requires isolated imports in mockgcp, as implemented in #863

panic: proto: file "google/api/apikeys/v2/resources.proto" is already registered
	previously from: "cloud.google.com/go/apikeys/apiv2/apikeyspb"
	currently from:  "github.com/GoogleCloudPlatform/k8s-config-connector/mockgcp/generated/google/api/apikeys/v2"
See https://protobuf.dev/reference/go/faq#namespace-conflict

[diviner524]

@justinsb I may have missed something obvious. This looks similar to how we add a TF based resource. What is the main difference when you mentioned "Manually scaffold"? For example do you plan to manually write the controller for this resource?

[google-oss-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: justinsb

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [justinsb]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[justinsb]

@diviner524 - sorry, by "manually scaffold" I mean adding support not via the TF autogen approach. I believe that TF autogen doesn't work for this resource because it is DCL based? I should double-check our instructions for how to add a TF resource though, it might answer some of my todos :-)

I do also intend to try implementing this one manually, but first I want to show that the terraform implementation has some problems.

[diviner524]

@diviner524 - sorry, by "manually scaffold" I mean adding support not via the TF autogen approach. I believe that TF autogen doesn't work for this resource because it is DCL based? I should double-check our instructions for how to add a TF resource though, it might answer some of my todos :-)

I do also intend to try implementing this one manually, but first I want to show that the terraform implementation has some problems.

I see, thanks for sharing!

[diviner524]

Since we are already manually adding it... Why not just mark the CRD as v1beta1? Do you see failing sample tests/integration tests when trying them locally? Or there are some fields with uncertainty?

IIUC this PR is basically doing the same as:

https://github.com/GoogleCloudPlatform/k8s-config-connector/blob/master/README.NewResourceFromTerraform.md

[justinsb]

This resource will only be as good as terraform, I think we have a higher bar for v1beta1? (Maybe we didn't enforce this bar before we introduced v1alpha1?)

[jingyih]

Hi Justin, is the generation of this CRD purely manual? Or is there some automation involved?

[justinsb]

It uses the "classic" generation mechanism (i.e. not automated generation) from a terraform resource

[justinsb]

Removing WIP. I believe as long as it's alpha it will be opt-in only.

[justinsb]

Rebased; I plan on doing the generation again though in case anything changed in terraform in the past 4 months. cc @cheftako

[justinsb]

Ran through generation again, I propose we look at #1168 instead, and then I'll rebase this one and see if there's anything left.

/hold

[yuwenma]

Shall we close this PR?