Skip to content

Conversation

@alexcristi
Copy link

Issue #, if available: aws-controllers-k8s/community#2665

Description of changes:

Added support for ManagedPrefixLists. This was validated with a KIND local cluster, and here are the results:

  • Controller logs
$ kubectl -n ack-system logs ack-ec2-controller-6f9ff4897-nxlpb | grep prefix
{"level":"info","ts":"2025-10-28T10:56:18.991Z","msg":"Starting EventSource","controller":"managedprefixlist","controllerGroup":"ec2.services.k8s.aws","controllerKind":"ManagedPrefixList","source":"kind source: *v1alpha1.ManagedPrefixList"}
{"level":"info","ts":"2025-10-28T10:56:19.193Z","msg":"Starting Controller","controller":"managedprefixlist","controllerGroup":"ec2.services.k8s.aws","controllerKind":"ManagedPrefixList"}
{"level":"info","ts":"2025-10-28T10:56:19.193Z","msg":"Starting workers","controller":"managedprefixlist","controllerGroup":"ec2.services.k8s.aws","controllerKind":"ManagedPrefixList","worker count":1}
  • ManagedPrefixList status
$ kubectl get ManagedPrefixLists
NAME                      ID                     NAME                   STATE             VERSION
ack-managed-prefix-list   pl-0e02e7c2410655ae5   ack-final-test-11184   create-complete   1

apiVersion: ec2.services.k8s.aws/v1alpha1
kind: ManagedPrefixList
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"ec2.services.k8s.aws/v1alpha1","kind":"ManagedPrefixList","metadata":{"annotations":{},"name":"ack-managed-prefix-list","namespace":"default"},"spec":{"addressFamily":"IPv4","entries":[{"cidr":"10.250.0.0/24","description":"ACK Created - Network 1"},{"cidr":"10.250.1.0/24","description":"ACK Created - Network 2"},{"cidr":"10.250.2.0/24","description":"ACK Created - Network 3"}],"maxEntries":10,"prefixListName":"ack-final-test-11184","tags":[{"key":"Environment","value":"production"},{"key":"ManagedBy","value":"ACK-Controller"},{"key":"Purpose","value":"Demo"}]}}
  creationTimestamp: "2025-10-28T10:54:38Z"
  finalizers:
  - finalizers.ec2.services.k8s.aws/ManagedPrefixList
  generation: 1
  name: ack-managed-prefix-list
  namespace: default
  resourceVersion: "3836"
  uid: 16681e81-40cd-4137-ad0f-ff06ed0ec060
spec:
  addressFamily: IPv4
  entries:
  - cidr: 10.250.0.0/24
    description: ACK Created - Network 1
  - cidr: 10.250.1.0/24
    description: ACK Created - Network 2
  - cidr: 10.250.2.0/24
    description: ACK Created - Network 3
  maxEntries: 10
  prefixListName: ack-final-test-11184
  tags:
  - key: ManagedBy
    value: ACK-Controller
  - key: Purpose
    value: Demo
status:
  ackResourceMetadata:
    ownerAccountID: "258057316678"
    region: us-west-2
  conditions:
  - lastTransitionTime: "2025-10-28T10:56:20Z"
    message: Resource synced successfully
    reason: ""
    status: "True"
    type: ACK.ResourceSynced
  ownerID: "258057316678"
  prefixListARN: arn:aws:ec2:us-west-2:258057316678:prefix-list/pl-0e02e7c2410655ae5
  prefixListID: pl-0e02e7c2410655ae5
  state: create-complete
  version: 1
  • ManagedPrefixList created in AWS
image
  • ManagedPrefixList updated
image
  • ManagedPrefixList deleted
image

@ack-prow ack-prow bot added the needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. label Oct 29, 2025
@ack-prow
Copy link

ack-prow bot commented Oct 29, 2025

Hi @alexcristi. Thanks for your PR.

I'm waiting for a aws-controllers-k8s member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@ack-prow ack-prow bot requested review from jlbutler and rushmash91 October 29, 2025 10:05
@ack-prow
Copy link

ack-prow bot commented Oct 29, 2025

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: alexcristi
Once this PR has been reviewed and has the lgtm label, please assign a-hilaly for approval by writing /assign @a-hilaly in a comment. 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

@a-hilaly
Copy link
Member

/ok-to-test

@ack-prow ack-prow bot added ok-to-test Indicates a non-member PR verified by an org member that is safe to test. and removed needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels Oct 29, 2025
@knottnt
Copy link
Contributor

knottnt commented Oct 29, 2025

@alexcristi: It looks like there's some compilation issues with these changes. Any chance there's some un-pushed commits?

 32.93 pkg/resource/managed_prefix_list/sdk.go:179:23: invalid operation: elem.State != nil (mismatched types "github.com/aws/aws-sdk-go-v2/service/ec2/types".PrefixListState and untyped nil)
32.93 pkg/resource/managed_prefix_list/sdk.go:180:25: cannot use elem.State (variable of string type "github.com/aws/aws-sdk-go-v2/service/ec2/types".PrefixListState) as *string value in assignment
32.93 pkg/resource/managed_prefix_list/sdk.go:195:28: cannot use elem.MaxEntries (variable of type *int32) as *int64 value in assignment
32.93 pkg/resource/managed_prefix_list/sdk.go:380:31: invalid operation: resp.PrefixList.State != nil (mismatched types "github.com/aws/aws-sdk-go-v2/service/ec2/types".PrefixListState and untyped nil)
32.93 pkg/resource/managed_prefix_list/sdk.go:381:22: cannot use resp.PrefixList.State (variable of string type "github.com/aws/aws-sdk-go-v2/service/ec2/types".PrefixListState) as *string value in assignment
32.93 pkg/resource/managed_prefix_list/sdk.go:665:22: cannot use desired.ko.Spec.MaxEntries (variable of type *int64) as *int32 value in assignment
32.93 pkg/resource/managed_prefix_list/sdk.go:746:32: invalid operation: resp.PrefixList.State != nil (mismatched types "github.com/aws/aws-sdk-go-v2/service/ec2/types".PrefixListState and untyped nil)
32.93 pkg/resource/managed_prefix_list/sdk.go:747:31: cannot use resp.PrefixList.State (variable of string type "github.com/aws/aws-sdk-go-v2/service/ec2/types".PrefixListState) as *string value in assignment
32.93 pkg/resource/managed_prefix_list/sdk.go:757:16: rm.syncTags undefined (type *resourceManager has no field or method syncTags)
32.93 pkg/resource/managed_prefix_list/sdk.go:757:16: too many errors 

@alexcristi
Copy link
Author

alexcristi commented Oct 29, 2025

Thank you for taking time to look at this @knottnt, really appreciate it!
I see what happened, when I built it locally for testing, I fixed the errors directly in the sdk.go file, and when I ran the generator again of course my changes were overwritten. Now fixed it in the template files.

@alexcristi
Copy link
Author

Hold on, I need to test it again

@alexcristi
Copy link
Author

/retest

@alexcristi
Copy link
Author

@knottnt - Also, what do you want me to do with ec2-verify-code-gen? Do you want me to rebuild with v0.19.0? If I do so, are we okay with committing changes on other resources than the one this PR is purposed for?

@knottnt
Copy link
Contributor

knottnt commented Nov 3, 2025

@knottnt - Also, what do you want me to do with ec2-verify-code-gen? Do you want me to rebuild with v0.19.0? If I do so, are we okay with committing changes on other resources than the one this PR is purposed for?

@alexcristi That's a new optional PR check that we're testing out. Right now it's just informational for the reviewer. Since, the ec2-controller hasn't been rebuilt with v0.19.0 yet I'm fine with keeping it as-is and applying that change in a future PR. But no there wouldn't be an issue with you using v0.19.0 as long as the change to the other CRDs is limited to the controller-gen.kubebuilder.io/version annotation.

@alexcristi
Copy link
Author

/retest

2 similar comments
@alexcristi
Copy link
Author

/retest

@alexcristi
Copy link
Author

/retest

@knottnt
Copy link
Contributor

knottnt commented Nov 5, 2025

/test ec2-kind-e2e

@alexcristi
Copy link
Author

/test ec2-verify-code-gen

1 similar comment
@alexcristi
Copy link
Author

/test ec2-verify-code-gen

@alexcristi
Copy link
Author

@knottnt, I am bit confused to what's going on with the ec2-verify-code-gen check; I generated with both v0.16.2 and v0.19.0, yet the check complains about the same diffs in both cases:

diff --git a/config/crd/bases/ec2.services.k8s.aws_capacityreservations.yaml b/config/crd/bases/ec2.services.k8s.aws_capacityreservations.yaml
index 5ac7de8..94f7a44 100644
--- a/config/crd/bases/ec2.services.k8s.aws_capacityreservations.yaml
+++ b/config/crd/bases/ec2.services.k8s.aws_capacityreservations.yaml
@@ -3,7 +3,7 @@ apiVersion: apiextensions.k8s.io/v1
 kind: CustomResourceDefinition
 metadata:
   annotations:
-    controller-gen.kubebuilder.io/version: v0.16.2
+    controller-gen.kubebuilder.io/version: v0.19.0
   name: capacityreservations.ec2.services.k8s.aws
 spec:
   group: ec2.services.k8s.aws

@knottnt
Copy link
Contributor

knottnt commented Nov 7, 2025

@knottnt, I am bit confused to what's going on with the ec2-verify-code-gen check; I generated with both v0.16.2 and v0.19.0, yet the check complains about the same diffs in both cases:

diff --git a/config/crd/bases/ec2.services.k8s.aws_capacityreservations.yaml b/config/crd/bases/ec2.services.k8s.aws_capacityreservations.yaml
index 5ac7de8..94f7a44 100644
--- a/config/crd/bases/ec2.services.k8s.aws_capacityreservations.yaml
+++ b/config/crd/bases/ec2.services.k8s.aws_capacityreservations.yaml
@@ -3,7 +3,7 @@ apiVersion: apiextensions.k8s.io/v1
 kind: CustomResourceDefinition
 metadata:
   annotations:
-    controller-gen.kubebuilder.io/version: v0.16.2
+    controller-gen.kubebuilder.io/version: v0.19.0
   name: capacityreservations.ec2.services.k8s.aws
 spec:
   group: ec2.services.k8s.aws

@alexcristi Looking at the verifying-code-gen job runs they are highlighting different diffs. In the run for commit 9e72d1a the job finds diffs for only aws_adoptedresources and aws_field_export under config/crd/common/bases in addition to the diffs under /helm/crds/. Which makes sense as the helm crds were still annotated with v0.16.2 since the commit regenerating with v0.19.0 only appears to have applied to the /config/crd/bases/ folder. In the latest run we see diffs for the CRDs under /config/crd/bases return.

Out of curiosity how are you triggering the code-gen tool? Are you using make build-controller SERVICE=ec2 as shown in the contributor docs?

@alexcristi
Copy link
Author

alexcristi commented Nov 8, 2025

@knottnt, I am bit confused to what's going on with the ec2-verify-code-gen check; I generated with both v0.16.2 and v0.19.0, yet the check complains about the same diffs in both cases:

diff --git a/config/crd/bases/ec2.services.k8s.aws_capacityreservations.yaml b/config/crd/bases/ec2.services.k8s.aws_capacityreservations.yaml
index 5ac7de8..94f7a44 100644
--- a/config/crd/bases/ec2.services.k8s.aws_capacityreservations.yaml
+++ b/config/crd/bases/ec2.services.k8s.aws_capacityreservations.yaml
@@ -3,7 +3,7 @@ apiVersion: apiextensions.k8s.io/v1
 kind: CustomResourceDefinition
 metadata:
   annotations:
-    controller-gen.kubebuilder.io/version: v0.16.2
+    controller-gen.kubebuilder.io/version: v0.19.0
   name: capacityreservations.ec2.services.k8s.aws
 spec:
   group: ec2.services.k8s.aws

@alexcristi Looking at the verifying-code-gen job runs they are highlighting different diffs. In the run for commit 9e72d1a the job finds diffs for only aws_adoptedresources and aws_field_export under config/crd/common/bases in addition to the diffs under /helm/crds/. Which makes sense as the helm crds were still annotated with v0.16.2 since the commit regenerating with v0.19.0 only appears to have applied to the /config/crd/bases/ folder. In the latest run we see diffs for the CRDs under /config/crd/bases return.

Out of curiosity how are you triggering the code-gen tool? Are you using make build-controller SERVICE=ec2 as shown in the contributor docs?

Thank you @knottnt for the hint, it was helpful; on my attempt to preserve the version I managed to mess up with the generator configuration; restored to upstream and ran again

@alexcristi
Copy link
Author

/test ec2-kind-e2e

1 similar comment
@alexcristi
Copy link
Author

/test ec2-kind-e2e

@ack-prow
Copy link

ack-prow bot commented Nov 8, 2025

@alexcristi: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name Commit Details Required Rerun command
ec2-verify-code-gen b83ac9f link false /test ec2-verify-code-gen
ec2-kind-e2e b83ac9f link true /test ec2-kind-e2e

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ok-to-test Indicates a non-member PR verified by an org member that is safe to test.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants