[Lambda ACK] Add FunctionVersionRef to Lambda Alias CR to avoid hard-coded version number for deployments

[acaremrullah]

Hi ACK Lambda team, I would like to raise a feature request about functionVersion spec for Alias. I'm happy to contribute for it, but I would like to hear your opinions first before coming with a PR since it has introduce a completely new field. Looking forward for your feedbacks.

Is your feature request related to a problem?

The current Alias CRD requires a hard-coded string value for spec.functionVersion, which makes it difficult to implement GitOps-based canary deployments with tools like Argo Rollouts or with custom controllers.

Current Problem:

apiVersion: lambda.services.k8s.aws/v1alpha1
kind: Alias
metadata:
  name: my-app
spec:
  functionName: my-app
  functionVersion: "5"  # Hard-coded string - requires manual updates

When implementing canary deployments, I need to:

1. Publish a new Lambda version using the Version CR
2. Update the Alias CR to point to that new version
3. Gradually shift traffic using weighted routing

However, the Version CR automatically gets a version number assigned by AWS Lambda that can be retrieved in its status.version field. I cannot predict this version number beforehand, which means:

• I cannot declare the version in a GitOps workflow without knowing what Lambda will assign
• I have to manually find the version number from the Version CR status after it's created
• This breaks the declarative GitOps model and requires manual intervention or complex scripting

Real-World Use Case: Canary Deployment with Argo Rollouts

I want to use Argo Rollouts with a Lambda traffic routing plugin for canary deployments:

1. Deploy new code as a new Version CR (let's call it my-app-blue)
2. Point a canary Alias to this new version using a reference (not a hard-coded version number)
3. Use Argo Rollouts to gradually shift traffic from stable to canary
4. Promote or rollback by updating which Version CR the alias references

This workflow is not possible today because I cannot reference the Version CR's status.version field from the Alias CR.

Describe the solution you'd like

Describe the solution you'd like

Add a new field functionVersionRef to the Alias CRD that allows referencing a Version CR. The controller would automatically resolve the reference and use the status.version field from the referenced Version CR.

Proposed API:

---
apiVersion: lambda.services.k8s.aws/v1alpha1
kind: Alias
metadata:
  name: my-app-canary
spec:
  name: canary
  functionRef:
    from:
      name: my-app
  functionVersionRef:  # NEW: Reference to Version CR
    from:
      name: my-app-blue
  routingConfig:
    additionalVersionWeights:
      - functionVersion: "5" # This will be changed by canary deployment tool. E.g. ArgoRollout 
        weight: 0.9 

Key Requirements:

1. functionVersionRef should reference only the Version CR (not Function CR) to avoid ambiguity
2. The controller should read status.version from the referenced Version CR
3. Either functionVersion OR functionVersionRef must be provided (mutual exclusivity)
4. The feature should be backward compatible - existing hard-coded functionVersion values continue to work

Implementation in generator.yaml:

resources:
  Alias:
    fields:
      FunctionVersion:
        is_required: false  # Change from true to allow FunctionVersionRef
      FunctionVersionRef:
        references:
          resource: Version
          path: Status.Version

Describe alternatives you've considered

Alternative 1: External Controller/Operator

Create a custom controller that watches Version CRs and updates Alias CRs with hard-coded version numbers.

Drawbacks:

• Adds complexity and another component to maintain
• Not a native Kubernetes pattern
• Requires additional RBAC permissions
• Doesn't leverage ACK's existing reference resolution mechanism

Alternative 2: Use Function CR's status.version

Instead of referencing Version CR, reference the Function CR's status.version field.

Drawbacks:

• Function.status.version represents the latest version, which may not be the one you want for canary
• Cannot maintain multiple version CRs (blue/green) and switch between them
• Ambiguity: both Version and Function CRs could have the same name in the same namespace

Alternative 3: Manual Scripts/CI Pipeline

Use CI/CD scripts to:

1. Create Version CR
2. Wait for it to be synced
3. Query the status.version field
4. Update Alias CR with the hard-coded version number

Drawbacks:

• Not declarative/GitOps-friendly
• Requires complex scripting
• Breaks the Kubernetes reconciliation model
• Harder to rollback (requires re-running scripts)

Alternative 4: Use Alias ARN with $LATEST

Just use $LATEST as the version.

Drawbacks:

• Cannot do canary deployments with weighted routing
• All traffic goes to the latest version immediately (no gradual rollout)
• No ability to test new version with a small percentage of traffic

Benefits of the Proposed Solution

1. GitOps-Friendly: Version changes are tracked in Git via Version CR updates
2. Declarative: No manual intervention or scripts needed
3. Type-Safe: Kubernetes validates references before applying
4. Automatic Resolution: Controller handles version lookup automatically
5. Backward Compatible: Existing hard-coded functionVersion values continue to work
6. Enables Advanced Deployment Strategies: Supports canary, blue/green, and progressive delivery with Argo Rollouts
7. Consistent with ACK Patterns: Uses the same reference mechanism as other ACK controllers (e.g., functionRef, roleRef)

[github-actions]

Hello @acaremrullah 👋 Thank you for opening an issue in ACK! A maintainer will triage this issue soon.

We encourage community contributions, so if you're interested in tackling this yourself or suggesting a solution, please check out our Contribution and Code of Conduct guidelines.

You can find more information about ACK on our website.

[knottnt]

@acaremrullah Yes, it I believe adding support for referencing status.version from a Version resource would make sense for this use case. Would definitely appreciate the contribution!

[acaremrullah]

Thank you @knottnt Happy to hear that. I'll raise a PR in upcoming days with reference of this issue