Skip to content
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

azurerm_automation_job_schedule needs to be recreated after azurerm_automation_runbook is updated #7555

Merged
merged 10 commits into from
Jul 24, 2020

Conversation

yupwei68
Copy link
Contributor

@yupwei68 yupwei68 commented Jul 2, 2020

Fix: #7130

Local test the issue scenario with pass.

Job_schedule is a link from runbook to schedule. Once runbook has been updated, all its related job_schedule will update all linked job schedule id.
First terraform apply, one change to update runbook, terraform apply with success.
Second terraform apply, one create to create job_schedule, (Because job schedule id has been updated, the job schedule reading from its elder job schedule id doesn't exist any more. Here we delete its linked job schedule and recreate this job schedule ), terraform apply with success.

@ghost ghost added the size/S label Jul 2, 2020
Copy link
Contributor

@manicminer manicminer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @yupwei68, thanks for this fix. It mostly LGTM, but I think we will need to add some tests to cover this case - i.e. something like: create runbook, create schedule, create job_schedule, import, update runbook, import

It's probably also worth mentioning in the docs that job_schedule_id can change when not explicitly configured.

@yupwei68
Copy link
Contributor Author

yupwei68 commented Jul 7, 2020

Hi @manicminer , it seems that Terraform doesn't have replace_on_change lifecycle , according to hashicorp/terraform#8099, to make this resource azurerm_autoamtion_job_schedule forcenew when there are updates in azurerm_automation_runbook. Thus, this scenario can't be written in acctest. Because it needs 2 terraform apply. When updating azurerm_automation_runbook at the first tf apply, the resource azurerm_autoamtion_job_schedule will not exist.(it reads its job schedule id, it set itself empty id when api returns not exist) On fact, runbook has changed the job schedule id. The second tf apply, this resource will be created.

@ghost ghost removed the waiting-response label Jul 7, 2020
@manicminer
Copy link
Contributor

Ah I see, thanks for clarifying. Attempting consistency across a single apply is important and this approach doesn't feel right to me. Given that there can only be one job_schedule per runbook, and the schedule seems to be a child resource, would it make sense to have this as an optional block on the runbook resource rather than a standalone resource?

@ghost ghost added size/XL and removed size/S labels Jul 15, 2020
yupwei68 added 2 commits July 15, 2020 14:26
@yupwei68
Copy link
Contributor Author

Hi @manicminer Thanks for your comments. Corresponding changes have been pushed. Please continue reviewing.
=== RUN TestAccAzureRMAutomationRunbook_PSWorkflow
=== PAUSE TestAccAzureRMAutomationRunbook_PSWorkflow
=== CONT TestAccAzureRMAutomationRunbook_PSWorkflow
--- PASS: TestAccAzureRMAutomationRunbook_PSWorkflow (133.85s)
=== RUN TestAccAzureRMAutomationRunbook_requiresImport
=== PAUSE TestAccAzureRMAutomationRunbook_requiresImport
=== CONT TestAccAzureRMAutomationRunbook_requiresImport
--- PASS: TestAccAzureRMAutomationRunbook_requiresImport (146.93s)
=== RUN TestAccAzureRMAutomationRunbook_PSWorkflowWithHash
=== PAUSE TestAccAzureRMAutomationRunbook_PSWorkflowWithHash
=== CONT TestAccAzureRMAutomationRunbook_PSWorkflowWithHash
--- PASS: TestAccAzureRMAutomationRunbook_PSWorkflowWithHash (134.25s)
=== RUN TestAccAzureRMAutomationRunbook_PSWithContent
=== PAUSE TestAccAzureRMAutomationRunbook_PSWithContent
=== CONT TestAccAzureRMAutomationRunbook_PSWithContent
--- PASS: TestAccAzureRMAutomationRunbook_PSWithContent (134.12s)
=== RUN TestAccAzureRMAutomationRunbook_withJobSchedule
=== PAUSE TestAccAzureRMAutomationRunbook_withJobSchedule
=== CONT TestAccAzureRMAutomationRunbook_withJobSchedule
--- PASS: TestAccAzureRMAutomationRunbook_withJobSchedule (307.08s)

=== RUN TestAccAzureRMAutomationJobSchedule_basic
=== PAUSE TestAccAzureRMAutomationJobSchedule_basic
=== CONT TestAccAzureRMAutomationJobSchedule_basic
--- PASS: TestAccAzureRMAutomationJobSchedule_basic (137.11s)
=== RUN TestAccAzureRMAutomationJobSchedule_complete
=== PAUSE TestAccAzureRMAutomationJobSchedule_complete
=== CONT TestAccAzureRMAutomationJobSchedule_complete
--- PASS: TestAccAzureRMAutomationJobSchedule_complete (138.11s)
=== RUN TestAccAzureRMAutomationJobSchedule_update
=== PAUSE TestAccAzureRMAutomationJobSchedule_update
=== CONT TestAccAzureRMAutomationJobSchedule_update
--- PASS: TestAccAzureRMAutomationJobSchedule_update (219.72s)
=== RUN TestAccAzureRMAutomationJobSchedule_requiresImport
=== PAUSE TestAccAzureRMAutomationJobSchedule_requiresImport
=== CONT TestAccAzureRMAutomationJobSchedule_requiresImport
--- PASS: TestAccAzureRMAutomationJobSchedule_requiresImport (152.57s)

@ghost ghost removed the waiting-response label Jul 15, 2020
@yupwei68 yupwei68 requested a review from manicminer July 16, 2020 01:48
@manicminer
Copy link
Contributor

Thanks @yupwei68, this looks great!

@manicminer
Copy link
Contributor

Test results:

Screen Shot 2020-07-23 at 23 40 45
Screen Shot 2020-07-23 at 23 40 56

@katbyte katbyte added this to the v2.21.0 milestone Jul 24, 2020
@katbyte katbyte merged commit de6606d into hashicorp:master Jul 24, 2020
katbyte added a commit that referenced this pull request Jul 24, 2020
@ghost
Copy link

ghost commented Jul 31, 2020

This has been released in version 2.21.0 of the provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading. As an example:

provider "azurerm" {
    version = "~> 2.21.0"
}
# ... other configuration ...

@ghost
Copy link

ghost commented Aug 23, 2020

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!

@ghost ghost locked and limited conversation to collaborators Aug 23, 2020
@yupwei68 yupwei68 deleted the wyp-automation-job-scheduel branch June 7, 2021 06:45
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
3 participants