-
Notifications
You must be signed in to change notification settings - Fork 89
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
Observe with Terraform Import when Observe Only #168
Conversation
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.
Thanks @turkenh I asked a question
Signed-off-by: Hasan Turken <[email protected]>
Signed-off-by: Hasan Turken <[email protected]>
Signed-off-by: Hasan Turken <[email protected]>
Rebased on latest main. |
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.
Thank you @turkenh, left some comments for you to consider.
// way we can do it for now. Terraform import does not return a proper exit code for this case or | ||
// does not support -json flag to parse the returning error in a better way. | ||
// https://github.com/hashicorp/terraform/blob/93f9cff99ffbb8d536b276a1be40a2c45ca4a67f/internal/terraform/node_resource_import.go#L235 | ||
if strings.Contains(string(out), "Cannot import non-existent remote object") { |
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.
Is it possible to reliably use the Terraform state to deduce a non-existent external resource in this case?
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.
Probably, but I didn't feel good about reading/parsing terraform state after getting an error to my import command.
// internal/features. This is a reasonable assumption for now | ||
// but we may want to make it configurable in the future. | ||
featuresPkgPath := fmt.Sprintf("%s/internal/features", pc.ModulePath) | ||
ctrlPkgPath, err := ctrlGen.Generate(resources[name], versionGen.Package().Path(), featuresPkgPath) |
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.
If I understand this correctly, we will also need the upjet-based provider to supply an EnableAlphaManagementPolicies
feature flag in this internal/features
package looking at the changes in the controller template pkg/pipeline/templates/controller.go.tmpl
.
If this is correct, we will also need a corresponding change in the template repository.
I would prefer a backward-compatible change here by defaulting to not enabling the observe-only resources feature unless a provider maintainer introduces the corresponding command-line flag & the corresponding machinery for this alpha feature to avoid confusion in those who bump their upjet versions not knowing about this change. A field in config.Provider
may control this behavior (defaulting to false
so that plain upjet version bumps without introducing an observe-only feature flag will not break anything). What do you think? Or do we want to force the provider maintainers to support observe-only resources in their providers when they bump their upjet versions?
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.
Just pushed 462dd33 for backward compatibility as you suggested.
Signed-off-by: Hasan Turken <[email protected]>
…ility Signed-off-by: Hasan Turken <[email protected]>
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.
Thanks @turkenh, lgtm.
Description of your changes
This PR add support Observe Only management policy to the upjet common controller.
I have:
make reviewable
to ensure this PR is ready for review.backport release-x.y
labels to auto-backport this PR if necessary.How has this code been tested
By following the procedure here and observing some resources, AWS VPC, AWS EKS Cluster ...