HackMD
Understanding generator.yaml Configuration
This document describes the various configuration fields in a generator.yaml file that can be used to control the API inference and code generation for an ACK controller.
We will show examples of configuring specific ACK controllers to highlight various configuration options.
Generate a resource manager package
For this section, we will use ECR as our example service API.
When creating a new ACK controller, after running the controller-bootstrap program, you will be left with a generator.yaml that has all inferred API resources ignored.
For the ECR controller, the generator.yaml file would look like this:
If we ran make build-controller SERVICE=ecr with the above generator.yaml file, we would have some basic directories and files created:
To begin generating a particular resource manager, comment out the name of the resource from the ignore list and run make build-controller SERVICE=$SERVICE.
After doing so, the resource manager for Repository resources will have been generated in the ecr-controller source code repository.
Note the new files under pkg/resource/repository/, apis/v1alpha1/repository.go and config/crd/bases/. These files represent the Go type for the generated Repository custom resource definition (CRD), the resource manager package and the YAML representation for the CRD, respectively.
Renaming things
Why might we want to rename fields or resources? Generally, there are two reasons for this:
- reducing stutter in the input shape
- correcting instances where a field is named differently in the input and output shapes
The first reason is to reduce "stutter" (or redundancy) in naming. For example, the ECR Repository resource has a field called RepositoryName. This field is redundantly named because the resource itself is called Repository. Every Kubernetes object has a Metadata.Name field and we like to align resource "name fields" with this simple Name moniker.
For this example, let's go ahead and "destutter" the RepositoryName field. To do this, we use the renames configuration option, specifying the input and output shapes and their members that we want to rename:
📝 Note that we must tell the code generator which fields to rename in the input shapes for each API operation that the resource manager will call. In the case of ECR
Repositoryresources, the resource manager calls theCreateRepository,DeleteRepositoryandDescribeRepositoriesAPI calls and so we need specify theRepositoryNamemember field in each of those input shapes should be renamed toName.
After calling make build-controller SERVICE=ecr, we see the above generator configuration items produced the following diff:
You will note that there were changes made to the repository.go file, the pkg/resource/repository/sdk.go.
Renaming things with different names in input and output shapes
The second reason we might need to rename a field is when the same field goes by different names in the shapes (i.e., expected syntax) of the input and output. An hypothetical example of this might be a field that is called EnableEncryption in an input shape and EncryptionEnabled in an output shape. In order to inform the code generator that these fields are actually the same, we would rename one of the fields to match the other.
[TODO this needs a concrete example of renaming with both input_fields and output_fields]
Ignoring things
Sometimes you want to instruct the code generator to simply ignore a particular API Operation, or a particular field in an API Shape. See here for a real world motivating example of such a need.
You will use the ignore: block of configuration options to do this.
To ignore a specific field in an API Shape, you can list the field via fieldpath in the ignore.fieldpaths configuration option.
An example of this can be found in the S3 controller's generator.yaml file:
When you specify a field path in ignore.field_paths, the code generator will skip over that field when inferring custom resource definition Spec and Status structures.
Tags
Most resources in AWS service APIs can have one or more tags associated with them. Tags are typically simple string key/value pairs; however, the representation of tags across different AWS service APIs is not consistent. Some APIs use a map[string]string to represent tags. Others use a []struct{} where the struct has a Key and a Value field. Others use more complex structures.
Telling ACK code generator that a resource does not support tags
There are some API resources that do not support tags at all, and we want a way to skip the generation of code that handles tagging for those resources. By default, for all resources, ACK generates some code that handles conversion between the ACK standard representation of tags (i.e., map[string]string) and the AWS service-specific representation of tags (e.g., []struct{}, etc).
If you attempt to generate a resource manager for a resource that does not support tags, you will receive an error from the code generator. ECR's PassThroughCacheRule is an example of a resource that does not support tags. If we unignore the PassThroughCacheRule resource in the ECR controller's generator.yaml file and regenerate the controller, we will stumble upon this error:
To fix this error, we used the tags.ignore configuration option in generator.yaml:
Resource configuration
Understanding resource identifying fields
All resources in the AWS world have one or more fields that serve as primary key identifiers. Most people are familiar with the ARN fields that most modern AWS resources have. However, the ARN field is not the only field that can serve as a primary key for a resource. ACK's code generator reads an API model file and attempts to determine which fields on a resource can be used to uniquely identify that resource. Sometimes, though, the code generator needs to be instructed which field or fields comprise this primary key. See below for an example from ECR's PullThroughCacheRule.
There are resource-level and field-level configuration options that inform the code generator about identifying fields.
Resource-level configuration of identifying fields
The resources[$resource].is_arn_primary_key configuration option is a boolean, defaulting to false that instructs the code generator to use the ARN field when calling the "ReadOne" (i.e., "Describe" or "Get") operation for that resource. When false, the code generator will look for "identifier fields" with field names such as ID or Name (along with variants that include the resource name as a prefix, e.g., "BucketName").
Use the is_arn_primary_key=true configuration option when the resource has no other identifying fields. An example of this is SageMaker's ModelPackage resource that has no Name or ID field and can only be identified via an ARN field:
[NOTE(jaypipes): Probably want to reevaluate this particular config option and use the field-centric is_primary_key option instead…]
Field-level configuration of identifying fields
Sometimes a resource's primary key field is non-obvious (like Name or ID). Use the resources[$resource]fields[$field].is_primary_key configuration option to tell the code generator about these fields.
An example here is ECR's PullThroughCacheRule resource, which has a primary key field called ECRRepositoryPrefix:
[NOTE(jljaco): If we discard is_arn_primary_key in favor of only is_primary_key, this sub-section should be moved into the Field Configuration section]
Correcting exception codes
An ACK controller needs to understand which HTTP exception code means "this resource was not found"; otherwise, the controller's logic that determines whether to create or update a resource falls apart.
For the majority of AWS service APIs, the ACK code generator can figure out which HTTP exception codes map to which HTTP fault behaviours. However, some AWS service API model definitions do not include exception metadata. Other service API models include straight-up incorrect information that does not match what the actual AWS service returns.
To address these issues, you can use the resources[$resource].exceptions configuration block.
An example of an API model that does not indicate the exception code representing a resource not found is DynamoDB. When calling DynamoDB's DescribeTable API call with a table name that does not exist, you will get back a 400 error code instead of 404 and the exception code string is ResourceNotFoundException.
To tell the ACK code generator how to deal with this, use the exceptions configuration option:
This configuration instructs the code generator to produce code that looks for ResourceNotFoundException in the error response of the API call and interprets it properly as a 404 or "resource not found" error.
Specifying terminal codes to indicate terminal state
An ACK.Terminal Condition is placed on a custom resource (inside of its Status) when the controller realizes that, without the user changing the resource's Spec, the resource will not be able to be reconciled (i.e., the desired state will never match the actual state).
When an ACK controller gets a response back from an AWS service containing an error code, the controller evaluates whether that error code should result in the ACK.Terminal Condition being placed on the resource. Examples of these "terminal codes" are things such as:
- improper input being supplied
- a duplicate resource already existing
- conflicting input values
AWS service API responses having a 4XX HTTP status code will have a corresponding exception string code (e.g., InvalidParameterValue or EntityExistsException). Use the resources[$resource].exceptions.terminal_codes configuration option to tell the code generation which of these exception string codes it should consider to be a terminal state for the resource.
Here is an example from the RDS controller, where we indicate the set of exception string code that will set the resource into a terminal state:
Controlling reconciliation and requeue logic
By default, an ACK controller will requeue a resource for future reconciliation only when the resource is in some transitional state.
For example, when you create an RDS DBInstance resource, the resource initially goes into a CREATING transitional state and then eventually will arrive at an AVAILABLE state. When the RDS controller for ACK initially creates the RDS DBInstance resource, it calls the RDS CreateDBInstance API call, sees the state of the DB instance is CREATING, adds an ACK.ResourceSynced=False Condition to the resource and requeues the resource to be processed again in a few seconds.
When the resource is processed in the next reconciliation loop, the controller calls the DescribeDBInstance API endpoint and checks to see if the DB instance is in the AVAILABLE state. If it is not, then the controller requeues the resource again. If it is in the AVAILABLE state, then the controller sets the ACK.ResourceSynced Condition to True, which is the indication to the ACK runtime that the resource should not be requeued.
Sometimes, you may want to have the ACK controller requeue certain resources even after a successful reconciliation loop that leaves the resource in the ACK.ResourceSynced=True state. If this is the case, you should use the resources[$resource].reconcile.requeue_on_success_seconds configuration option. The value of this option should be the amount of time (in seconds) after which the reconciler should requeue the resource.
Here is an example of this configuration option as used in the SageMaker controller's NotebookInstance resource:
We set this requeue_on_success_seconds value to 60 here because the values of various fields in this Sagemaker resource tend to change often and we want the Status section of our custom resource to contain values that are fresher than the default requeue period (10 hours as of this writing).
Field configuration
When ack-generate first infers the definition of a resource from the AWS API model, it collects the various member fields of a resource. This documentation section discusses the configuration options that instruct the code generator about a particular resource field.
Manually marking a field as belonging to the resource Status struct
During API inference, ack-generate automatically determines which fields belong in the custom resource definition's Spec or Status struct. Fields that can be modified by the user go in the Spec and fields that cannot be modified go in the Status.
Use the resources[$resource].fields[$field].is_read_only configuration option to override whether a field should go in the Status struct.
Here is an example from the Lambda controller's generator.yaml file that instructs the code generator to treat the LayerStatuses field as a read-only field (and thus should belong in the Status struct for the Function resource):
Typically, you will see this configuration option used for fields that have two different Go types representing the modifiable version of the field and the non-modifiable version of the field (as is the case for a Lambda Function's Layers information) or when you need to create a custom field.
Marking a field as required
If an AWS API model file marks a particular member field as required, ack-generate will usually infer that the associated custom resource field is required. Sometimes, however, you may want to override whether or not a field should be required. Use the resources[$resource].fields[$field].is_required configuration option to do so.
Here is an example from the EC2 controller's generator.yaml file that instructs the code generator to treat the Instance custom resource's MinCount and MaxCount fields as not required, even though the API model definition marks these fields as required in the Create Operation's Input shape.
NOTE: The reason for this is because the EC2 controller only deals with single Instance resources, not batches of instances
Controlling a field's Go type
Use the resources[$resource].fields[$field].type configuration option to override a field's Go type. You will typically use this configuration option for custom fields that are not inferred by ack-generate by looking at the AWS API model definition.
An example of this is the Policies field for a Role custom resource definition in the IAM controller. The IAM controller uses some custom hook code to allow a Kubernetes user to specify one or more Policy ARNs for a Role simply by specifying Spec.Policies. To define this custom field as a list of string pointers, the IAM controller's generator.yaml file uses the following:
Controlling how a field's values are compared
Use the resources[$resource].fields[$field].compare configuration option to control how the value of a field is compared between two resources. This configuration option has two boolean subfields, is_ignored and nil_equals_zero_value (TODO(jljaco): nil_equals_zero_value not yet implemented or used).
Marking a field as ignored
Use the is_ignored subfield to instruct the code generator to exclude this particular field from automatic value comparisons when building the Delta struct that compares two resources.
Typically, you will want to mark a field as ignored for comparison operations because the Go type of the field does not natively support deterministic equality operations. For example, a slice of Tag structs where the code generator does not know how to sort the slice means that the default reflect.DeepEqual call will produce non-deterministic results. These types of fields you will want to mark with compare.is_ignored: true and include a custom comparison function using the delta_pre_compare hook, as this example from the IAM controller's generator.yaml does for the Role resource:
Mutable vs. immutable fields
Use the resources[$resource].fields[$field].is_immutable configuration option to mark a field as immutable – meaning the user cannot update the field after initially setting its value.
A good example of the use of is_immutable comes from the RDS controller's DBInstance resource's AvailabilityZone field:
In the case of an DBInstance resource, once the AvailabilityZone field is set by the user, it cannot be modified.
By telling the code generator that this field is immutable, it will generate code in the sdk.go file that checks for whether a user has modified any immutable fields and set a Condition on the resource if so:
Controlling where a field's definition comes from
During API inference, ack-generate inspects the AWS service API model definition and discovers resource fields by looking at the Input and Output shapes of the Create API call for that resource. Members of the Input shape will go in the Spec and members of the Output shape that are not also in the Input shape will go into the Status.
This works for a majority of the field definitions, however sometimes you want to "grab a field" from a different location (i.e., other than either the Input or Output shapes of the Create API call).
Each Resource typically also has a ReadOne Operation. The ACK service controller will call this ReadOne Operation to get the latest observed state of a particular resource in the backend AWS API service. The service controller sets the observed Resource's Spec and Status fields from the Output shape of the ReadOne Operation. The code generator is responsible for producing the Go code that performs these "setter" methods on the Resource.
The way the code generator determines how to set the Spec or Status fields from the Output shape's member fields is by looking at the data type of the Spec or Status field with the same name as the Output shape's member field.
Importantly, in producing this "setter" Go code the code generator assumes that the data types (Go types) in the source (the Output shape's member field) and target (the Spec or Status field) are the same.
There are some APIs, however, where the Go type of the field in the Create Operation's Input shape is actually different from the same-named field in the ReadOne Operation's Output shape. A good example of this is the Lambda CreateFunction API call, which has a Code member of its Input shape that looks like this:
The GetFunction API call's Output shape has a same-named field called Code in it, but this field looks like this:
This presents a conundrum to the ACK code generator, which, as noted above, assumes the data types of same-named fields in the Create Operation's Input shape and ReadOne Operation's Output shape are the same.
Use the resources[$resource].fields[$field].from configuration option to handle these situations.
For the Lambda Function Resource's Code field, we can inform the code generator to create three new Status fields (read-only) from the Location, RepositoryType and ResolvedImageUri fields in the Code member of the ReadOne Operation's Output shape:
NOTE on maintainability: Another way of solving this particular problem would be to use a completely new custom field. However, we only use this as a last resort. The reason why we prefer to use the from: configuration option is because this approach will adapt over time with changes to the AWS service API model, including documentation about those fields, whereas completely new custom fields will always need to be hand-rolled and no API documentation will be auto-generated for them.
Annotating a field as a "Printer Column"
When we want to control which of a Resource's fields appear in the output of a kubectl get command, we can annotate that field's configuration by adding a print: section. An example of this is in the EC2 controller's ElasticIPAddress Resource, for which we would like to include the PublicIP field in the output of kubectl get:
Including this configuration in the field's definition within generator.yaml will cause the code generator to produce kubebuilder:printcolumn markers in the appropriate place in its generated code, which will result in the field being included in the kubectl get output.
TODO(jljaco) note about additional columns here? or reference to another part?
Controlling field "late initialization"
Late initialization of a field is a Kubernetes Resource Model concept that allows for a nil-valued field to be defaulted to some value after the resource has been successfully created. This is akin to a database table field's "default value".
Late initialized fields are slightly awkward for an ACK controller to handle, primarily because late initialized fields end up being erroneously identified as having different values in the Delta comparisons (TODO(jljaco) link to section below on Deltas). The desired state of the field is nil but the server-side default value of that field is some non-nil value.
ACK's code generator can output Go code that handles this server-side defaulting behaviour (we call this "late initialization"). To instruct the code generator to generate late initialization code for a field, use the resources[$resource].fields[$field].late_initialize configuration option.
A good example of late initialization can be found in the RDS controller. For DBInstance resources, if the user does not specify an availability zone when creating the DBInstance, RDS chooses one for the user. To ensure that the RDS controller understands that the availability zone field is set to a default value after creation, the following configuration (TODO(jljaco) link here) is set in the generator.yaml:
Note that the late_initialize configuration option is currently a struct with a couple member fields that are not yet implemented (as of Dec 2022), which is why you need to use the {} notation.
Informing the code generator that a field refers to another Resource
One custom resource can refer to another custom resource using something called Resource References. The Go code that handles the validation and resolution of Resource References is generated by ack-generate.
Use the resources[$resource].fields[$field].references configuration option to inform the code generator what kind of Resource a field references and which field within that Resource is the identifier field.
Here is an example from the API Gateway v2 controller that shows an Integration Resource referencing an API and a VPCLink Resource:
After regenerating the controller, the Integration resource will have two new fields, one called APIRef and another called ConnectionRef. The Go type of these fields will be a pointer to an AWSResourceReferenceWrapper:
NOTE: The generated name of the reference fields will always be the field name, stripped of any "Id", "Name", or "ARN" suffix, plus "Ref".
In the above example, both the API and VPCLink Resources are managed by the API Gateway v2 controller. It is possible to reference Resources that are managed by a different ACK controller by specifying the resources[$resource].fields[$field].references.service_name configuration option, as shown in this example from the RDS controller, which has the DBCluster resource reference the KMS controller's Key resource:
Adding custom fields
resources[$resource].fields[$field].type overrides the inferred Go type of a field. This is required for custom fields that are not inferred (either as a Create Input/Output shape or via the SourceFieldConfig attribute).
As an example, assume you have a Role Resource where you want to add a custom Spec field called Policies that is a slice of string pointers.
The generator.yaml file for the IAM controller looks like this:
There is no Policies field in either the CreateRole Input or Output shapes, therefore in order to create a new custom field, we simply add a Policies object in the fields configuration mapping and tell the code generator what Go type this new field will have – in this case, []*string.
NOTE on maintainability: Use custom fields as a last resort! When you use custom fields, you will not get the benefit of auto-generated documentation for your field like you will with auto-inferred or from:-configured fields. You will be required to use custom code hooks to populate and set any custom fields.
NOTE: (DEPRECATED) This can also be accomplished by using custom_field:, however we intend to move away from this approach.
Relevant TODO for combining CustomShape stuff into type: override
Custom code hook points
The code generator will generate Go code that implements the aws-sdk-go SDK "binding" calls. Sometimes you will want to inject bits of custom code at various points in the code generation pipeline.
Custom code hook points do this injection. They should be preferred versus using complete overrides (e.g., resources[$resource].update_operation.custom_method_name). The reason that custom code hooks are preferred is because you generally want to maximize the amount of generated code and minimize the amount of hand-written code in each controller. [NOTE(jljaco): decide later whether to bother documenting complete overrides via update_operation.custom_method_name]
The sdk.go hook points
First, some background. Within the pkg/resources/$resource/sdk.go file, there are 4 primary resource manager methods that control CRUD operations on a resource:
sdkFindreads a single resource record from a backend AWS service API, then populates a custom resource representation of that record and returns it back to the reconciler.sdkCreatetakes the desired custom resource state (in theSpecstruct of the CR). It calls AWS service APIs to create the resource in AWS, then sets certain fields on the custom resource'sStatusstruct that represent the latest observed state of that resource.sdkUpdatetakes the desired custom resource state (from theSpecstruct of the CR), the latest observed resource state, and a representation of the differences between those (called aDeltastruct). It calls one or more AWS service APIs to modify a resource's attributes, then populates the custom resource'sStatusstruct with the latest (post-modification) observed state of the resource.sdkDeletecalls one or more AWS service APIs to delete a resource.
For all 4 of these main ResourceManager methods, there is a consistent code path that looks like this:
- Construct the SDK Input shape. For
sdkFindandsdkDelete, this Input shape will contain the identifier of the resource (e.g. anARN). ForsdkCreateandsdkUpdate, this Input shape will also contain various desired state fields for the resource. This is called the "Set SDK" stage and corresponds to code generator functions in code-generator'spkg/generate/code/set_sdk.go. - Pass the SDK Input shape to the
aws-sdk-goAPI method.- For
sdkFind, this API method will be either theReadOneoperation for the resource (e.g., ECR'sGetRepositoryor RDS'sDescribeDBInstance) or theReadManyoperation (e.g., S3'sListBucketsor EC2'sDescribeInstances). - For the
sdkCreate,sdkUpdateandsdkDeletemethods, the API operation will correspond to theCreate,UpdateandDeleteoperation types.
- For
- Process the error/return code from the API call. If there is an error that appears in the list of Terminal codes (TODO link to docs), then the custom resource will have a Terminal condition applied to it, and a Terminal error is returned to the reconciler. The reconciler will subsequently add a
ACK.TerminalCondition to the custom resource. - Process the Output shape from the API call. If no error was returned from the API call, the Output shape representing the HTTP response content will then be processed, resulting in fields in either the
SpecorStatusof the custom resource being set to the value of matching fields on the Output shape. This is called the "Set Resource" stage and corresponds to code generator functions in code-generator'spkg/generate/code/set_resource.go.
Along with the above 4 main ResourceManager methods, there are a number of generated helper methods and functions that will:
- create the SDK input shape used when making HTTP requests to AWS APIs
- process responses from those AWS APIs
sdk_*_pre_build_request
The sdk_*_pre_build_request hooks are called before the call to construct the Input shape that is used in the API operation and therefore before any call to validate that Input shape.
Use this custom hook point if you want to short-circuit the processing of the resource for some reason OR if you want to process certain resource fields (e.g., Tags) separately from the main resource fields.
Example: Short-circuiting
Here is an example from the DynamoDB controller's generator.yaml file that uses a pre_build_request custom code hook for Table resources:
As you can see, the hook is for the Delete operation. You can specify the filepath to a template which contains Go code that you wish to inject at this custom hook point. Here is the Go code from that template:
The snippet of Go code above simply requeues the resource to be deleted in the future if the Table is currently either being updated (via UpdateTable) or deleted (via DeleteTable).
After running make build-controller for DynamoDB, the above generator.yaml configuration and corresponding template file produces the following Go code implementation for sdkDelete inside of the sdk.go file for Table resources:
In the example above, we've highlighted the lines (with >) that were injected into the sdkDelete method using this custom hook point.
Example: Custom field processing
Another example of a pre_build_request custom hook comes from the IAM controller's Role resource and this generator.yaml snippet:
which has the following Go code in the template file:
What you can see above is the use of the pre_build_request hook point to update the Role's policy collection, tag collection, and permissions boundary before calling the UpdateRole API call. The reason for this is because a Role's policies, tags, and permissions boundary are set using a different set of AWS API calls.
TOP TIP (1):
Note the use ofdelta.DifferentAt()in the code above. This is the recommended best practice for determining whether a particular field at a supplied field path has diverged between the desired and latest observed resource state.
sdk_*_post_build_request
The post_build_request hooks are called AFTER the call to construct the Input shape but before the API operation.
Use this custom hook point if you want to add custom validation of the Input shape.
Here's an example of a post_build_request custom hook point from the RDS controller's DBInstance resource:
and here's the Go code in that template:
As you can see, we add some custom validation and normalization of the Input shape for a DBInstance before calling the ModifyDBInstance API call.
TOP TIP (2):
Note the verbose usage of nil-checks. This is very important.aws-sdk-godoes not have automatic protection againstnilpointer dereferencing. All fields in anaws-sdk-goshape are pointer types. This means you should always do your own nil-checks when dereferencing any field in any shape.
sdk_*_post_request
The post_request hooks are called IMMEDIATELY AFTER the API operation aws-sdk-go client call. These hooks will have access to a Go variable named resp that refers to the aws-sdk-go client response and a Go variable named respErr that refers to any error returned from the aws-sdk-go client call.
sdk_*_pre_set_output
The pre_set_output hooks are called BEFORE the code that processes the Outputshape (the pkg/generate/code.SetOutput function). These hooks will have access to a Go variable named ko that represents the concrete Kubernetes CR object that will be returned from the main method (sdkFind, sdkCreate, etc). This ko variable will have been defined immediately before the pre_set_output hooks as a copy of the resource that is supplied to the main method, like so:
sdk_*_post_set_output
The post_set_output hooks are called AFTER the the information from the API call is merged with the copy of the original Kubernetes object. These hooks will have access to the updated Kubernetes object ko, the response of the API call (and the original Kubernetes CR object if it's sdkUpdate).
sdk_file_end
The sdk_file_end is a generic hook point that occurs outside the scope of any specific AWSResourceManager method and can be used to place commonly-generated code inside the sdk.go file.
NOTE(jaypipes): This is the weirdest of the hooks… need to cleanly explain this!
The comparison hook points
delta_pre_compare
The delta_pre_compare hooks are called before the generated code that compares two resources.
NOTE: If you specified that a particular field should have its comparison code ignored, you almost always will want to use a delta_pre_compare hook to handle the comparison logic for that field. See the example above in the section on "Marking a field as ignored" for an illustration of this.
The canonical example of when and how to use this custom code hook point is for handling the correct comparison of slices of Tag structs.
By default, if the code generator does not know how to generate specialized comparison code for a Go type, it will generate a call to reflect.DeepEqual for this comparison. However, for some types (e.g., lists-of-structs), reflect.DeepEqual will return true even when the only difference between two lists lies in the order by which the structs are sorted. This sort order needs to be ignored in order that the comparison logic properly returns false for lists-of-structs that are identical regardless of sort order.
The IAM controller's generator.yaml file contains this snippet:
and the delta_pre_compare hook code is an inline Go code function call to compareTags. This function is defined in the hooks.go file for the Role resource and looks like this:
commonutil.EqualTags properly handles the comparison of lists of Tag structs.
delta_post_compare
The delta_post_compare hooks are called after the generated code that compares two resources.
This hook is not commonly used, since the delta_pre_compare custom code hook point is generally used to inject custom code for comparing special fields.
However, the delta_post_compare hook point can be useful if you want to add some code that can post-process the Delta struct after all fields have been compared. For example, if you wanted to output some debugging information about the comparison operations.
The late initialization hook points
late_initialize_pre_read_one
The late_initialize_pre_read_one hooks are called before making the readOne call inside the AWSResourceManager.LateInitialize() method.
TODO
late_initialize_post_read_one
The late_initialize_post_read_one hooks are called after making the readOne call inside the AWSResourceManager.LateInitialize() method.
TODO
The reference hook points
references_pre_resolve
The references_pre_resolve hook is called before resolving the references for all Reference fields inside the AWSResourceManager.ResolveReferences() method.
TODO
references_post_resolve
The references_post_resolve hook is called after resolving the references for all Reference fields inside the AWSResourceManager.ResolveReferences() method.
TODO
The tags hook points
ensure_tags
The ensure_tags hook provides a complete custom implementation for the AWSResourceManager.EnsureTags() method.
TODO
convert_tags
The convert_tags hook provides a complete custom implementation for the ToACKTags and FromACKTags methods.
TODO
convert_tags_pre_to_ack_tags
The convert_tags_pre_to_ack_tags hooks are called before converting the K8s resource tags into ACK tags.
TODO
convert_tags_post_to_ack_tags
The convert_tags_post_to_ack_tags hooks are called after converting the K8s resource tags into ACK tags.
TODO
convert_tags_pre_from_ack_tags
The convert_tags_pre_from_ack_tags hooks are called before converting the ACK tags into K8s resource tags.
TODO
convert_tags_post_from_ack_tags
The convert_tags_post_from_ack_tags hooks are called after converting the ACK tags into K8s resource tags.
TODO
Attribute-based APIs
OMG TODO.
