Is it possible to inject new fields during code generation?

[ulucinar]

Is your feature request related to a problem? Similar to being able to ignore certain resources or field paths during code generation by specifying them under ignore.resource_names or ignore.field_paths in a generator_config.yaml file, is it/would it be possible to introduce new fields at specified paths with specified types & tags?

For example, while using the crossplane pipeline, we can have referencer fields that enable us to refer to another custom resource via a label selector or its name. The use case would be to introduce these extra "referencer" fields during code generation.

Describe the solution you'd like To be able to define extra fields at specified paths with specified types (possibly a type unknown to the code-generator pipeline) and with specified tags.

Describe alternatives you've considered One alternative might be to have the code-generator ignore the type/field which we need to expand and manually define those types/fields. But we would then not be utilizing the code generator. There are also other alternatives for the problem at hand in the crossplane context but it seems to be extending the code-generator with such functionality (if not already provided) will open up other possibilities.

For more context, the original context of the problem is a CloudFront Distribution can have multiple CacheBehaviors, each of which can refer to a (possibly distinct) CachePolicy. Now if we have a Distribution CR and multiple CachePolicy CRs to which we would like to refer to from the Distribution, I think it makes most sense to introduce the references fields (e.g., CachePolicy CR name and/or label selector) in the generated CacheBehavior struct. What I'm planning to implement for this PR at the moment is to introduce an index field that will point to the CacheBehavior object in the cacheBehaviors array for which a reference is being defined (assuming cachePolicyID is optional for a CacheBehavior).

Thank you very much.

[jaypipes]

Hi @ulucinar! This is a great feature suggestion. Can you make it to the next ACK community meeting on Zoom on Monday @12pm EDT? Details are here:

https://github.com/aws-controllers-k8s/community/#community-meeting

Would be great to discuss this feature request with you. We can currently inject fields into a CR's Spec or Status that are in other AWS SDK shapes but not yet have the ability to override the Go type that is inferred by looking at that Shape's member fields. That said, I'd be open to adding this type of configuration to the generator conf.

[ulucinar]

Hi @jaypipes, I was not available last week but I will try to do it today. Thank you very much.

[jaypipes]

As mentioned in the community meeting this morning, we should refine this GH issue to talk specifically about new fields for a CR that do not appear in any shape from the aws-sdk-go API model files. I will work on that refinement later today or tomorrow.

[RedbackThomson]

I'm interested in taking this on, as an effort to complete the S3 bucket specification. My early implementation would probably accept a string, as part of the generator config, that specifies the Go type. I'm also going to assume this type is in the resource's package, which is where we typically place the hooks. This removes the need to handle custom importing, which complicates things quite a lot.

[RedbackThomson]

I have merged https://github.com/aws-controllers-k8s/code-generator/pull/222 , which provides an initial implementation of new fields. It only supports new list or map fields of existing AWS SDK shapes, though.

Once we have https://github.com/aws-controllers-k8s/community/issues/545 designed and implemented, we can look into also supporting your use case:

The use case would be to introduce these extra "referencer" fields during code generation.