Policy resource and profile resource: resources are redeployed even if there is no change

[ecanault]

Description

After applying successfully the whole plan, performing again terraform plan updates policies and configuration profiles despite the fact they are not modified.

Expected behavior

Without any changes, terraform plan should display: Plan: 0 to add, 0 to change, 0 to destroy.

Actual behavior

Without any changes, terraform plan actually display: Plan: 0 to add, 33 to change, 0 to destroy.

33 is the number of policies and configuration profiles.

Here is an output for a policy for example:

# jamf_policy.policies[15] will be updated in-place
~ resource "jamf_policy" "policies" {
      id = "290"

    - files_and_processes {
        - delete_file            = false -> null
        - kill_process           = false -> null
        - update_locate_database = false -> null
      }
    + files_and_processes {}

    - general {
        - enabled                       = true -> null
        - frequency                     = "Once every day" -> null
        - id                            = 290 -> null
        - location_user_only            = false -> null
        - name                          = "p_update_inventory" -> null
        - network_requirements          = "Any" -> null
        - notify_on_each_failed_retry   = false -> null
        - offline                       = false -> null
        - retry_attempts                = -1 -> null
        - retry_event                   = "none" -> null
        - target_drive                  = "/" -> null
        - trigger                       = "CHECKIN" -> null
        - trigger_checkin               = true -> null
        - trigger_enrollment_complete   = false -> null
        - trigger_login                 = false -> null
        - trigger_logout                = false -> null
        - trigger_network_state_changed = false -> null
        - trigger_startup               = false -> null

        - category {
            - id   = "451" -> null
            - name = "Configuration" -> null
          }

        - network_limitations {
            - any_ip_address             = true -> null
            - minimum_network_connection = "No Minimum" -> null
          }

        - override_default_settings {
            - distribution_point = "default" -> null
            - force_afp_smb      = false -> null
            - sus                = "default" -> null
            - target_drive       = "/" -> null
          }

        - site {
            -id    = -1 ->null
            - name = "None" -> null
          }
      }
    + general {
        + enabled                       = true
        + frequency                     = "Once every day"
        + id                            = (known after apply)
        + location_user_only            = false
        + name                          = "p_update_inventory"
        + network_requirements          = "Any"
        + notify_on_each_failed_retry   = false
        + offline                       = false
        + retry_attempts                = 0
        + retry_event                   = "none"
        + target_drive                  = "/"
        + trigger                       = "EVENT"
        + trigger_checkin               = true
        + trigger_enrollment_complete   = false
        + trigger_login                 = false
        + trigger_logout                = false
        + trigger_network_state_changed = false
        + trigger_startup               = false

        + category {
            + id   = "451"
            + name = "Configuration"
          }

        + network_limitations {
            + any_ip_address             = true
            + minimum_network_connection = "No Minimum"
          }

        + override_default_settings {
            + force_afp_smb      = false
            + netboot_server     = "current"
            + sus                = "default"
            + target_drive       = "default"
          }

        + site {
            +id    = -1
            + name = (known after apply)
          }
      }

    - self_service {
        - feature_on_main_page            = false -> null
        - force_users_to_view_description = false -> null
        - install_button_text             = "Install" -> null
        - reinstall_button_text           = "Reinstall" -> null
        - use_for_self_service            = false -> null

        - self_service_category {
            - display_in = true -> null
            - feature_in = false -> null
            - id         = 451 -> null
            - name       = "Configuration" -> null
          }

        - self_service_icon {
           - id = 0 -> null
          }
      }
    + self_service {
        + feature_on_main_page            = false
        + force_users_to_view_description = false
        + install_button_text             = "Install"
        + reinstall_button_text           = "Reinstall"
        + use_for_self_service            = false

        + self_service_category {
            + id   = 451
            + name = (known after apply)
          }

        + self_service_icon {
            + filename = (known after apply)
            + id       = 0
            + uri      = (known after apply)
          }
      }

    - user_interaction {
        - allow_deferral_minutes = 0 -> null
        - allow_users_to_defer   = false -> null
      }
    + user_interaction {}

      # (3 unchanged blocks hidden)
    }

Plan: 0 to add, 33 to change, 0 to destroy.

The side effect is that when I perform a terraform apply the policies and the profiles are redeployed. Below the creation and the unwanted update (see capture #1).

It’s problematic for profiles because as you can see they are redeployed to devices, which obviously is not a good idea (see capture #2).

Possible explanation

?

Possible fix

?

[PatchMickle]

It's possible the "id" fields need to be stringed

"id": {
	Type:     schema.TypeInt, -> _**schema.TypeString**_
	Computed: true,
}

[w0de]

After you ran apply for this plan, the next plan was identical - is this correct, @ecanault?

Presently, I can't reproduce such an issue. I'll need more details. Can you still reproduce? If so, could you please share the relevant .tf config & the output of TF_LOG=DEBUG terraform {plan,apply} ...? Also - some questions:

• Is there any chance the change to general.trigger (CHECKIN -> EVENT) in the example was genuine? (And/or the other changes, listed below.)
• By what mechanism would updating this policy cause a profile to be redeployed (and could that mechanism be correctly triggered immediately by the policy's new EVENT trigger)?

In this example, on jamf_policy.policies[15]:

• general.override_default_settings.{netboot_server,distribution_point,target_drive} change
• general.{trigger,files_and_processes} change
• self_service.self_service_category.{display_in,feature_in} change
• user_interaction changes

(If any one property of a top level schema attributes (general, self_service user_interaction) changes, the entire attribute block is replaced in the plan.)

[w0de]

Ah! I was able to reproduce (maybe) this, @ecanault :) No need for the additional logs/above questions. As an immediate workaround, try setting self_service.self_service_icon.id to a number > 0 on impacted policies.

The bug I found occurs when trying to change self_service.self_service_icon.id to 0 on an existing policy. Only on newly created policies does a 0 icon id work properly* (by creating a policy without any icon).

*But that's not really proper. A reasonable user might expect 0 to be a reference to a valid icon ID, the first in the index (I did). And the Jamf API simply returns an empty icon property when none is set. This is certainly a bug, though the workaround isn't difficult. Will address, but can't take priority atm.