Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tool: improve types generator #3667

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

jingyih
Copy link
Collaborator

@jingyih jingyih commented Feb 13, 2025

  • Avoid generating a Go struct if all its fields are output-only and therefore should already be included in the ObservedState Go struct.
  • Improve the logic to correctly detect existing Go structs, as a proto message can now be split into two Go structs.
  • Made a minor adjustment to ensure a leading newline is added appropriately when writing fields.

Copy link
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign cheftako for approval. For more information see the Kubernetes Code Review Process.

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

Needs approval from an approver in each of these files:

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

@jingyih
Copy link
Collaborator Author

jingyih commented Feb 13, 2025

Fixes #3618

/assign @jasonvigil
/cc @maqiuyujoyce

@@ -23,6 +23,68 @@ import (

var AlloyDBClusterGVK = GroupVersion.WithKind("AlloyDBCluster")

// +kcc:proto=google.cloud.alloydb.v1beta.Cluster.PscConfig
type Cluster_PSCConfig struct {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm, I assume the change is made because of the acronym capitalization issue? Can I get an /lgtm for #3624? With this change, you shouldn't need to do manual modifications.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right. I'm not sure if we reached a consensus on which acronym to include in that PR, so I manually moved the Go structs in this PR to unblock the fix.

@jasonvigil
Copy link
Collaborator

/lgtm
thank you @jingyih

@google-oss-prow google-oss-prow bot added the lgtm label Feb 13, 2025
@@ -120,6 +120,11 @@ func (g *TypeGenerator) WriteVisitedMessages() error {
continue
}

if hasOnlyOutputFields(msg) {
klog.Infof("skipping generation of %q as it only contains output fields", msg.FullName())
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see why you want to do this. But it will cause rabbit holes if the existence of the field itself is configurable. PAM entitlement has one case where a field is structured but has no sub fields . I believe this function will skip that field.

Copy link
Collaborator

@yuwenma yuwenma left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My gut feeling is that this is going toward a magic machine. A lot of API logic is determined by the type generator, which itself determines the behavior based on best practice. I'm afraid this limits KCC ability to adjust the field in each resource level. e.g. the PAM entitlement exception.

@jingyih
Copy link
Collaborator Author

jingyih commented Feb 14, 2025

My gut feeling is that this is going toward a magic machine. A lot of API logic is determined by the type generator, which itself determines the behavior based on best practice. I'm afraid this limits KCC ability to adjust the field in each resource level. e.g. the PAM entitlement exception.

To correctly generate Go types from proto, I think some kind of magic machine is necessary—either explicitly building one or using an LLM. However, I don’t believe LLMs are yet producing Go types at a high enough quality, meaning fixing the generated code might take more time than just using this tool. Therefore I think there is value in fixing the bugs we found in the tool so it can be used on most resources.

For cases like the PAM entitlement you mentioned, we can decide whether to make the magic machine more complicated or just manually fix the generated code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants