-
Notifications
You must be signed in to change notification settings - Fork 9.2k
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 new resources: aws_lightsail_container_service
and aws_lightsail_container_service_deployment_version
#20625
Add new resources: aws_lightsail_container_service
and aws_lightsail_container_service_deployment_version
#20625
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.
Welcome @KaguraKagura 👋
It looks like this is your first Pull Request submission to the Terraform AWS Provider! If you haven’t already done so please make sure you have checked out our CONTRIBUTING guide and FAQ to make sure your contribution is adhering to best practice and has all the necessary elements in place for a successful approval.
Also take a look at our FAQ which details how we prioritize Pull Requests for inclusion.
Thanks again, and welcome to the community! 😃
AWS contribution. |
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.
Take a Look at my suggestions regarding moving your waiters to an internal waiter service.
return diag.FromErr(err) | ||
} | ||
|
||
stateChangeConf := &resource.StateChangeConf{ |
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.
Awesome! excited to see this change (Big Lighsail Fan). I was actually going to work on this myself once i had time. This will pair well with my aws_lightsail_database
resource i have an open PR for. Might I suggest migrating waiters to an internal service waiter like in my PR? https://github.com/hashicorp/terraform-provider-aws/pull/18663/files aws/internal/service/lightsail/waiter/status.go. This way the same waiter can be used for all lightsail resources without having to re-write it on each CRUD operation.
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.
Hi Brittan, thank you for being a Lightsail fan! I also like Lightsail very much! 😎
For the StateChangeConf
, the reason I rewrite them is that Lightsail container service does not return Operation
like some other Lightsail resources, and Lightsail container service has relatively more complicated Pending
and Target
(there are 7 StateChangeConf
in total and 6 of them are different). My thinking is that it might be better to leave them there and provide some context in the comments. But my lightsailContainerServiceRefreshFunc
can definitely be moved to aws/internal/service/lightsail/waiter/status.go
in future after the merge of your PR.
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.
I agree that the logic should be moved to the aws/internal/service/lightsail/waiter/status.go
.
Check out how we did the multiple pending states and single target state in StorageGateway:
https://github.com/hashicorp/terraform-provider-aws/blob/main/aws/internal/service/storagegateway/waiter/waiter.go
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.
I support @KaguraKagura's plan
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.
Makes sense @KaguraKagura. I am glad we have another lightsail fan working on adding functionality to the provider =) . Hopefully with this PR getting so much attention, some other Lightsail PRs that have been sitting for a while will get some attention as well.
Pull request #21306 has significantly refactored the AWS Provider codebase. As a result, most PRs opened prior to the refactor now have merge conflicts that must be resolved before proceeding. Specifically, PR #21306 relocated the code for all AWS resources and data sources from a single We recognize that many pull requests have been open for some time without yet being addressed by our maintainers. Therefore, we want to make it clear that resolving these conflicts in no way affects the prioritization of a particular pull request. Once a pull request has been prioritized for review, the necessary changes will be made by a maintainer -- either directly or in collaboration with the pull request author. For a more complete description of this refactor, including examples of how old filepaths and function names correspond to their new counterparts: please refer to issue #20000. For a quick guide on how to amend your pull request to resolve the merge conflicts resulting from this refactor and bring it in line with our new code patterns: please refer to our Service Package Refactor Pull Request Guide. |
@KaguraKagura @AdamTylerLynch you did huge amount of work. Do you guys plan to resolve merge conflicts in the near future? It would be awesome to see more Lightsail representation in Terraform. |
… into f-lightsail-container-service while resolving the conflicts introduced by the refactor in hashicorp#20000
@mac-r Thanks for reminding me of this PR! It surely has been a long time since I first opened it last summer! |
Acctests after resolving the conflicts introduced by the refactor in #20000:
|
@KaguraKagura For Awareness I am working on making an entirely separate provider for AWS Lightsail. This way it will get its own dedicated attentions when it comes to PRs and development. I would like to allow you the opportunity to submit this resource as a PR before I do it myself. Not much refactoring should be needed other than the lightsail provider is using the aws-sdk-go-v2. Here is the repo : https://github.com/DeYoungTech/terraform-provider-awslightsail The provider is published here: https://registry.terraform.io/providers/DeYoungTech/awslightsail/latest I already have resource Parity with the current aws provider for lightsail resources and have added a couple additional ones that I had open PRs for ( for over a year with no reviews). |
It'd be good to get this change into your Lightsail-specific provider, but it would be ideal if we can get this change into the main Terraform AWS provider, so that users don't have to use a separate provider for Lightsail than they do for other AWS services. Is there anything blocking this from being merged to the main AWS provider? If so, I'm happy to resolve them. |
I agree @mlburggr it would be ideal to get these resources into the main AWS provider. However, I have open pull requests for Lightsail resources that have been open for over a year and refactored multiple times as required with no reviews. This is what brought me to start a separate Lightsail provider. I would love for some pull requests for lightsail on the main AWS provider to get some love. For awareness this resource is now published with the latest version of the I decided to split it into three separate resources: I tagged @KaguraKagura as a co-author on relevant resources. Tried to give credit, where credit was due as I used a lot of this pull request when making these resources. |
Reviewing Now. |
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.
Really thorough PR. I have asked for a few changes. Once those have been made ping me, and I will conduct another review.
Required: true, | ||
Elem: &schema.Resource{ | ||
Schema: map[string]*schema.Schema{ | ||
"container_name": { |
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.
The AWS Public API documentation for Container
does not have container_name
? Please verify.
I do see it defined on the public_endpoint
, maybe a documentation issue?
https://docs.aws.amazon.com/lightsail/2016-11-28/api-reference/API_Container.html
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.
In here https://docs.aws.amazon.com/lightsail/2016-11-28/api-reference/API_CreateContainerServiceDeployment.html, I think containers
is a "String to Container object map", where that string is the container's name. Terraform requires a concrete name, and so I just give it the name container_name
.
|
||
command = [] | ||
|
||
environment { |
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.
Can you provide a sample command. Maybe just yum update -y
?
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.
specify are used when you create a deployment with a container configured as the public endpoint of your container | ||
service. If you don't specify public domain names, then you can use the default domain of the container service. | ||
Defined below. | ||
* WARNING: You must create and validate an SSL/TLS certificate before you can use public domain names with your |
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.
Can a certificate be created via Terraform for this to help the user do everything through the HCL interface?
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.
When I was doing this pull request as an intern at Lightsail, it was not possible then. Perhaps @mlburggr has newer information.
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.
@AdamTylerLynch and @KaguraKagura I currently have an implementation of the certificate
resource in my separate lightsail provider and plan on opening up a PR to this provider with the resource as soon as my other PR is merged #18663 as this PR has internal waiters written that I would like to use when writing other lightsail resources. The example of the certificate
resource is currently here: https://github.com/DeYoungTech/terraform-provider-awslightsail/blob/main/internal/lightsail/certificate.go
"availability_zone": { | ||
Type: schema.TypeString, | ||
Computed: true, | ||
}, |
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.
I would expect to see created_at, isDisabled, state_detail.
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.
Any other elements returned from the payload.
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_disabled
was there; added created_at
. I omitted state_detail
because in here https://docs.aws.amazon.com/lightsail/2016-11-28/api-reference/API_ContainerServiceStateDetail.html, it says
Note
The state detail is populated only when a container service is in a PENDING, DEPLOYING, or UPDATING state.
and for Lightsail container service in terreform, all operations won't return unless the state moves out of the above states.
Sorry I clicked the wrong button and closed this PR, but I reopened it now... |
No worries @KaguraKagura thanks for your response! I'll push up a commit to remove the deployment logic then and aim to get this into an upcoming release since the PR already went through review. |
b066a4f
to
28ab845
Compare
28ab845
to
e9d5e06
Compare
7598492
to
249f89f
Compare
249f89f
to
0bf975d
Compare
Output of acceptance tests (commercial):
|
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 again @KaguraKagura for your contributions and @brittandeyoung for your feedback! I've gone ahead and done the refactoring bits to pull out the deployment configuration as a standalone resource, namely aws_lightsail_container_service_deployment_version
as the Lightsail service treats each deployment as a new version.
aws_lightsail_container_service
and aws_lightsail_container_service_deployment_version
This functionality has been released in v4.19.0 of the Terraform AWS Provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading. For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template. Thank you! |
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. |
Community Note
For TestAcc, because Lightsail container service only allows at most 5 container services being in creating/updating state, I am running the tests section by section, instead of using a single
$ make testacc
command.Output from acceptance testing: