-
Notifications
You must be signed in to change notification settings - Fork 132
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add references to launch templates from EKS node groups #853
Add references to launch templates from EKS node groups #853
Conversation
Signed-off-by: Matt Snyder <[email protected]>
I have read the crossplane and upjet contribution guides. I'm still not certain of the most efficient path for testing changes to a provider. Specifically, is there tooling or commands available that offer an efficient path for standing up a local dev environment for testing provider changes? |
Hi @oblogic7, Thank you for your contribution. Here is a guide on how you can test it, are you aware of it? You must be a contributor to trigger the automatic test specified in the guide. If the resource or feature you add is uptestable, we can leave this comment for you in your first PR. Let's talk about this PR, here we add reference configuration for
In both cases we should test |
/test-examples="examples/eks/nodegroup.yaml" |
1 similar comment
/test-examples="examples/eks/nodegroup.yaml" |
@oblogic7 uptest run failed due to the dependent resources did not exist in the example manifest, we should test manually. |
Type: "github.com/upbound/provider-aws/apis/ec2/v1beta1.LaunchTemplate", | ||
RefFieldName: "LaunchTemplateIDRefs", | ||
SelectorFieldName: "LaunchTemplateIDSelector", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Type: "github.com/upbound/provider-aws/apis/ec2/v1beta1.LaunchTemplate", | |
RefFieldName: "LaunchTemplateIDRefs", | |
SelectorFieldName: "LaunchTemplateIDSelector", | |
Type: "github.com/upbound/provider-aws/apis/ec2/v1beta1.LaunchTemplate", | |
TerraformName: "aws_kinesis_stream", | |
Extractor: common.PathTerraformIDExtractor, |
The better way to use TerraformName
even if it is difficult, in order not to be affected by any group changes.
And we'd better not use RefFieldName
and SelectorFieldName
unless you have a specific reason to come up with it that way. It is used in the configuration you added as follows:
spec:
launchTemplate:
launchTemplateIdSelector:
matchLabels:
testing.upbound.io/example-name: ....
But as recommended:
spec:
launchTemplate:
IDSelector:
matchLabels:
testing.upbound.io/example-name: ....
What do you think?
r.References["launch_template.name"] = config.Reference{ | ||
Type: "github.com/upbound/provider-aws/apis/ec2/v1beta1.LaunchTemplate", | ||
RefFieldName: "LaunchTemplateNameRefs", | ||
SelectorFieldName: "LaunchTemplateNameSelector", | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We may not add this as name and id cannot be used together.
@oblogic7, if you are considering taking this PR forward, please check the comments. |
I am closing this now if you want to take forward feel free to reopen it. |
Description of your changes
Fixes #851
I have:
make reviewable test
to ensure this PR is ready for review.How has this code been tested
Guidance needed.