-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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 status argument (RUNNING/TERMINATED) to google_compute_instance #4797
Add status argument (RUNNING/TERMINATED) to google_compute_instance #4797
Conversation
- defaults to RUNNING - cannot create instance with status TERMINATED - when updating, wait until the instance reach the expected status
Bumping this up. Is there anything else I can do for this PR? |
I'll review this soon. |
Hello @tysen, did you get a chance to look at the updates I made after your first review? |
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.
Hey @norbjd! Sorry for the delay in getting to this once I was assigned, I'm taking over as reviewer of this PR.
I've left a handful of comments that broadly move us from a joint status
field that outputs the current status + can be set to a desired_status
field that users can opt-in to using and that avoids some unfortunate interactions with regards to existing infrastructure.
If you'd like to output the current status as status
, feel free to do that as well.
I haven't looked at the tests yet, nor the stopping_for_update
section of the PR. I'd prefer to try out the change to desired_status
first, and then work out the specifics of those parts afterwards.
- rename status to desired_status - add CustomizeDiff to deny TERMINATED desired_status on instance creation - update acceptance tests
Hello @rileykarson, thanks for your review. I made some changes according to your comments. To sum up :
|
Hello @rileykarson, just updated the PR with your helpful comments 😄 To sum up, the biggest update was to handle all cases that requires stopping the instance before updating some of the attributes. Introducing
|
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.
Looking great, and thanks for the thorough enumeration + testing of all those cases. I have a couple small thoughts, as well as some comments that can help reduce the amount of redundant test code a little.
- extract common method startInstanceOperation to start instance (with or without pulling encryption keys) - refacto tests : reuse configs + extract common helper method
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.
LGTM. Thanks for working through this @norbjd! Configuration of states on a resource has had no precedents in Terraform that I'm aware of. The best one is the issue for AWS instances (/ the original issue), and that's as-of-yet unresolved. Great work!
I'm going to upstream this to Magic Modules so these changes make it to the google-beta
provider as well, and merge this PR after the MM PR has been approved. I'm going to need a reviewer there, so if they have any suggestions I'll apply them upstream during the merge process, they'll be applied to this repo as well by our syncing tool.
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks! |
Hello,
I added a
status
argument ongoogle_compute_instance
to be able tostart/stop instances using Terraform, therefore answering :
When searching I noticed that there is an open PR on that topic but sadly it looks like it has been abandoned (no update since 2019/03/13), so I've decided to implement it by following the valuable advices written by @rileykarson in this PR.
This is my first PR here so I gladly accept any comment :)
Recap
I added a
status
field accepting only valuesRUNNING
(default) orTERMINATED
.There are many other existing states :
PROVISIONING
,STAGING
,STOPPING
,REPAIRING
(from the docs), and I have also seenSTOPPED
,SUSPENDED
orSUSPENDING
on Compute Go client (https://godoc.org/google.golang.org/api/compute/v1#Instance, checkStatus
field). Nevertheless, I think that onlyRUNNING
andTERMINATED
have sense here, because other are kind of "transition" states.Instance creation
On instance creation, I have chosen to tolerate only
RUNNING
status, because this is the default behavior in the current provider, and because I did not have an example that came to my mind where it is needed to create aTERMINATED
instance. Also, modifications should have been more important (I think) if the possibiility to createTERMINATED
instances were given.On instance creation (or update), in order to wait for the instance to reach the expected
status
, I usedresource.StateChangeConf
and theWaitForState()
function to avoid reinventing the wheel, but I don't know if parameters are correct here (Delay
,Timeout
, and evenPending
states). I'm open to any suggestion.Instance update
On instance update, I have done two things :
status
changes fromTERMINATED
toRUNNING
, and stop the instance ifstatus
changes fromRUNNING
toTERMINATED
TERMINATED
status, and when updating fields requiring the instance to be stopped (like changingmachine_type
,min_cpu_platform
, ...), do not try to stop (and after restart) the instance because it is already stopped (TERMINATED
status)Acceptance tests
Finally, I have written acceptance tests covering and passing the following cases :
RUNNING
instance is createdTERMINATED
(RUNNING
=>TERMINATED
)TERMINATED
status (TERMINATED
=>RUNNING
)TERMINATED
instance is updated :labels
,metadata
, ...)machine_type
)TERMINATED
instance is deletedTERMINATED
instance cannot be created (expected to beRUNNING
when creating)I don't think adding this
status
field will impact the previous behavior of the provider (maybe wait a little more when creating an instance because it needs to wait until the instance isRUNNING
, though when testing I've noticed that the instance was alwaysRUNNING
when it reached the part of the code waiting for the status). However, I did not run the whole acceptance tests suite (like in other PR I believe), so I'm wondering, is there a process that will run all tests before merging any PR to ensure that the modification did not break something unexpected?I look forward to reading your comments.