Fix update loop for Function.lambda resource

[turkenf]

Description of your changes

This PR fixes the update loop in the Function.lambda resource.

Fixes: #1027

I have:

• Read and followed Crossplane's contribution process.
• Run make reviewable to ensure this PR is ready for review.
• Added backport release-x.y labels to auto-backport this PR if necessary.

How has this code been tested

• Create a Repository.ecr resource by applying the following:

apiVersion: ecr.aws.upbound.io/v1beta1
kind: Repository
metadata:
  name: test-repo
spec:
  forProvider:
    region: us-east-1
    imageTagMutability: "IMMUTABLE"

• Push an image to the repository:
  • Retrieve an authentication token and authenticate your Docker client to your registry. Use the AWS CLI: aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin <account_id>.dkr.ecr.us-east-1.amazonaws.com
  • Build your Docker image using the following command. For information on building a Docker file from scratch see the instructions here . You can skip this step if your image is already built: docker build -t test-repo .
  • After the build completes, tag your image so you can push the image to this repository: docker tag test-repo:latest <account_id>.dkr.ecr.us-east-1.amazonaws.com/test-repo:latest
  • Run the following command to push this image to your newly created AWS repository: docker push <account_id>.dkr.ecr.us-east-1.amazonaws.com/test-repo:latest
• Create a Function.lambda resource by applying the following:

apiVersion: lambda.aws.upbound.io/v1beta1
kind: Function
metadata:
  name: example-ft-test
spec:
  forProvider:
    imageUri: <redacted>.dkr.ecr.us-east-1.amazonaws.com/ft-test-repo:latest
    packageType: Image
    region: us-east-1
    roleSelector:
      matchLabels:
        testing.upbound.io/example-name: role
    timeout: 60

• Once the resource has been created successfully, create and push a different image with a tag using the steps above.
• Change the imageUri in the Function.lambda resource with the new one.

2024-04-16T19:22:57+03:00	DEBUG	provider-aws	External resource is up to date	{"controller": "managed/lambda.aws.upbound.io/v1beta1, kind=function", "request": {"name":"example-ft-test"}, "uid": "786b127b-d342-423f-89b0-9e45c61b1d77", "version": "36662", "external-name": "example-ft-test", "requeue-after": "2024-04-16T19:33:03+03:00"}

  conditions:
  - lastTransitionTime: "2024-04-16T16:21:44Z"
    reason: Available
    status: "True"
    type: Ready
  - lastTransitionTime: "2024-04-16T16:21:35Z"
    reason: ReconcileSuccess
    status: "True"
    type: Synced
  - lastTransitionTime: "2024-04-16T16:21:42Z"
    reason: Success
    status: "True"
    type: LastAsyncOperation
  - lastTransitionTime: "2024-04-16T16:22:57Z"
    reason: UpToDate
    status: "True"
    type: Test

[ulucinar]

Thank you @turkenf, left some comments for discussion. If the discussions are correct, then I think this works more or less as intended and to improve the situation, we can disable the late-initialization for the hash field (so that users don't have to update the hash if they don't care about it) because late-initialization forces them to care about the field :)

[ulucinar]

@turkenf, thanks for documenting the manual testing steps. We should also consider capturing this know-how in the uptest manifests (probably by executing them via the pre hooks) and automating the testing. We may even consider using an already available test image (I don't know its cost implications tbh).

[mbbush]

I'm very supportive of @ulucinar's suggestion to fix this by disabling late initialization. It seems like that should fix the issues, but I'd also like to try some creative ideas to break it that will hopefully fail, both for zip lambdas and image-based ones.

AWS Lambda requires that its images come from AWS ECR in the same region as the lambda, but they can be from any aws account, as long as permissions are set appropriately. So I think it would work well to have a small, static lambda image hosted in ECR in a different aws account than is used for testing (so it doesn't get cloud-nuke'd), that we could use for testing from any aws account. It's worth checking, but I'd expect the cost to be minimal.

[turkenf]

/test-examples="examples/lambda/v1beta1/function.yaml"

[ulucinar]

Hi @turkenf,
It could be great if we could also extend the Go field documentation (which also becomes the CRD field documentation) to explain the requirement on the sourceCodeHash (that it should be the actual computed hash if specified).

[turkenf]

I close and re-open to trigger jobs.

[turkenf]

/test-examples="examples/lambda/v1beta1/function.yaml"

Uptest run: https://github.com/crossplane-contrib/provider-upjet-aws/actions/runs/8818842854