Open yogeek opened 1 year ago
This provider repo does not have enough maintainers to address every issue. Since there has been no activity in the last 90 days it is now marked as stale
. It will be closed in 14 days if no further activity occurs. Leaving a comment starting with /fresh
will mark this issue as not stale.
This is still quite the problem, I was porting a terraform module to Crossplane today and the missing field is quite important.
resource "aws_vpc_endpoint" "ptfe_service" {
vpc_id = var.vpc_id
service_name = var.ptfe_service
vpc_endpoint_type = "Interface"
security_group_ids = [
aws_security_group.ptfe_service.id,
]
subnet_ids = [local.subnet_ids]
private_dns_enabled = false
}
It's a lot more work to produce 5+ objects (one endpoint, 3 subnet associations, 1+n security group associations) compared to the terraform object above.
A follow up question; are we not expecting the shape of objects in Upjet generated modules to be matching their Terraform counterparts, just in general?
This provider repo does not have enough maintainers to address every issue. Since there has been no activity in the last 90 days it is now marked as stale
. It will be closed in 14 days if no further activity occurs. Leaving a comment starting with /fresh
will mark this issue as not stale.
/fresh
What happened?
To create a VPCEndpoint resource, we used to specify the
subnetIds[]
in the contrib crossplane provider but it is missing in the Upbound official provider which we migrated to. Plus, this field is also present in the AWS terraform provider.Crossplane provider AWS : https://doc.crds.dev/github.com/crossplane/provider-aws/ec2.aws.crossplane.io/VPCEndpoint/v1alpha1@v0.42.0 Upbound officiel provider AWS : https://marketplace.upbound.io/providers/upbound/provider-aws/v0.40.0/resources/ec2.aws.upbound.io/VPCEndpoint/v1beta1 Terraform provider AWS : https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/vpc_endpoint.html#subnet_ids
I am aware of the VPCEndpointSubnetAssociations resource but in our case, the subnets already exist (not created by crossplane) and their numbers can vary depending on the environment. Consequently, handling dynamically the number of associations in a composition is easier if subnets are defined as a list in 1 resource than if they are defined in multiple association resources...
I guess we could use composition functions for this but we try to keep things as simple as possible and in this particular case, the official provider adds complexity comparing to the previous provider or to terraform corresponding resource
Even if
subnetIds
andVPCEndpointSubnetAssociations
are exclusive, is it not possible to keep them both and to let users the way they want to specify it ? Plus, it would allow the VPCendpoint resource with crossplane to be as close as possible as the experience in the AWS console where the subnets can be chosen in a list, and also as the corresponding terraform provider, which would ease migration to crossplane for users.What environment did it happen in ?
Crossplane version : 1.12 Provider version : 0.40 K8s version : 1.24