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

Smart Computer Group resource does not work properly #3

Open
thisisnotgroiss opened this issue Feb 6, 2023 · 1 comment
Open

Smart Computer Group resource does not work properly #3

thisisnotgroiss opened this issue Feb 6, 2023 · 1 comment
Assignees
Labels
bug Something isn't working

Comments

@thisisnotgroiss
Copy link

Hi,

it seems like the provider has issues with the state of smart computer groups. the resource gets created in jamf, but TF seems to lose track of it.

Error: Provider produced inconsistent result after apply
When applying changes to jamf_smartComputerGroup.python_installed, provider
"provider[\"registry.terraform.io/yohan460/jamf\"]" produced an unexpected
new value: Root resource was present, but now absent.
This is a bug in the provider, which should be reported in the provider's
own issue tracker.
@Yohan460 Yohan460 added the bug Something isn't working label Mar 14, 2023
@w0de
Copy link
Collaborator

w0de commented Mar 27, 2024

Hi @thisisnotgroiss! Thanks for the issue! 👀

I can reproduce this issue in acceptance tests run against a Jamf Pro instance. It's also an issue (sometimes?) with jamf_policy and jamf_computerExtensionAttribute resources.

The root cause appears to be that Jamf's API is too slow:

Immediately after the remote state is updated, the provider reads it (as expected). However, Jamf's API (using the objects' respective classic endpoints) returns 404 resource not found. I added a hacky retry-on-404 (delta here) & the issue went away 🪄.

Open to suggestions for a proper fix. Ideas:

  • Just roll with the hacky retry logic copied across 3-4 resourceRead functions. This does keep the solution (which is just a work around) close to the problem (which is specific to TF provider implementation - no other API use case requires accurate reads so quickly)
  • Implement the retry logic in go-jamf-api, generalized in some sensible manner.
  • Generalize the retry logic in the provider, somehow. Maybe customize the HTTP client passed to the jamf.Client?
  • Hope the Pro API fixes this and put it off until this provider starts using same.
  • ??? Something better. cc @Yohan460

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants