Releases: deploymenttheory/terraform-provider-jamfpro
v0.0.55
v0.0.55
Bug fix release for account groups, macOS config profiles and mobile device config profiles. This release brings field names changes for config profiles and policies to align more closely with the jamf pro gui
What's Changed
- rebasing dev branch by @ShocOne in #237
- Schema fixes for config profiles mac and mobile by @ShocOne in #238
- Terraform plugin sdk v2 by @ShocOne in #239
- Refactored macOs config profiles to be declarative by @ShocOne in #241
- chore: Update directory service usergroup IDs in macOS and mobile dev… by @ShocOne in #243
- Computer groups minor overhaul by @thejoeker12 in #244
- Fixed small bug due to shared scope schema change by @thejoeker12 in #246
- small fix to stop force positive plan loop by @thejoeker12 in #247
- chores for fixing issues with macos config profile state management by @ShocOne in #248
Full Changelog: v0.0.54...v0.0.55
Contributors
Assets 19
v0.0.54
v0.0.54
What's Changed
- Packages Working (EARLY) by @thejoeker12 in #219
- refactored mobile device config profiles to follow hcl pattern by @ShocOne in #220
- Small diag fix by @thejoeker12 in #221
- rebasing dev branch from main by @ShocOne in #222
- Scripts works with a lot of errors (not my fault) by @thejoeker12 in #223
- Bump hashicorp/ghaction-terraform-provider-release from 4.0.0 to 4.0.1 by @dependabot in #225
- Bump github.com/hashicorp/terraform-plugin-sdk/v2 from 2.33.0 to 2.34.0 by @dependabot in #224
- Policies working with Packages and Scripts by @thejoeker12 in #229
- Added support for correctly managing mobile device configuration profiles by @ShocOne in #230
- fix for data source schema by @ShocOne in #231
- Refactor mobile device configuration profiles to update field require… by @ShocOne in #232
- name fix by @thejoeker12 in #233
- remove name from stating in policies to avoid false positive plans by @thejoeker12 in #234
- computer extension attributes: removed case sensitive validation by @thejoeker12 in #235
Full Changelog: v0.0.53...v0.0.54
Contributors
Assets 19
v0.0.53
v0.0.53
What's Changed
- chore: Set some default values for computerextensionattributes resource by @kenchan0130 in #205
- Update apiroles_resource.go by @mhrono in #207
- Rebasing branch by @ShocOne in #209
- Terraform plugin sdk v2 by @ShocOne in #210
- Computer groups bug by @w0de in #214
- Bump hashicorp/ghaction-terraform-provider-release from 3.0.1 to 4.0.0 by @dependabot in #213
- Bump github.com/hashicorp/terraform-plugin-docs from 0.19.1 to 0.19.2 by @dependabot in #206
- rebasing dev branch with changes by @ShocOne in #215
- Added restricted software to provider, updated docs , updated dependancies by @ShocOne in #216
- Added restricted software management to docs by @ShocOne in #217
New Contributors
- @kenchan0130 made their first contribution in #205
- @mhrono made their first contribution in #207
Full Changelog: v0.0.52...v0.0.53
Contributors
Assets 19
v0.0.52
v0.0.51
v0.0.51
- restored previous macos configprofile behaviour from v0.0.49. This is a short term fix while we find a proper solution for managing configuration profile state management. Reverted behaviour will correctly deploy payloads and will honour .hcl updates to the config profiles, but doesn't track any changes to the config profile payload on the jamf side. So do not change the resource on the gui side for the time being as the terraform management of the resource is not truly declarative.
- support for classic api webhooks with examples
- support for setting custom cookies e.g "jpro-ingress" for hard coding a specific jamf web app for every session.
- Numerous bug fixes and better log propagating from the http client to the provider for troubleshooting
What's Changed
- rebasing branch from main by @ShocOne in #188
- Added jamf pro webhook resource to provider by @ShocOne in #191
- Custom cookies in provider (only 1 for now) by @thejoeker12 in #192
- rebasing branch from main by @ShocOne in #193
- Merge pull request #193 from deploymenttheory/main by @ShocOne in #194
- Bug fixes for webhooks and computergroups by @ShocOne in #195
- Added httpclient log propagation to stdout and logging file output path for troubleshooting by @ShocOne in #196
- code organization fixes by @ShocOne in #197
- updated provider example with custom_cookie field by @ShocOne in #198
Full Changelog: v0.0.50...v0.0.51
Contributors
Assets 19
v0.0.50
v0.0.50
What's Changed
- policy schema blocks migrated into individual files (incomplete) by @thejoeker12 in #177
- Policy Schema Migration by @thejoeker12 in #178
- Refactored computer groups to support additional scenarios by @ShocOne in #180
- jamfpro_macos_configuration_profile: enable
redeploy_on_update, and read payload content from API by @w0de in #185 - updated readme to includes references to mac admins slack by @ShocOne in #186
- updated dependancies by @ShocOne in #187
Full Changelog: v0.0.49...v0.0.50
Contributors
Assets 19
v0.0.49
v0.0.49
What's Changed
- Refactored mobile device configuration profiles and added documentation by @ShocOne in #167
- Refactor mobile device configuration profile data source to use compu… by @ShocOne in #168
- Documentation fixes by @ShocOne in #169
- Refactor multiple resources to follow new read fuction pattern and to… by @ShocOne in #170
- Refactor centralise handle resource not found error by @ShocOne in #171
- Refactor to standardize state setting by @ShocOne in #173
- Refactor site object construction and stating to a centralised form by @ShocOne in #175
- Standardised Schemas by @thejoeker12 in #174
Full Changelog: v0.0.48...v0.0.49
Contributors
Assets 19
v0.0.48
v0.0.48
Bug fixes for some refactor errors from the previous release.
Experimental version of mobile device configuration profiles implemented
Updated jamf pro sdk version to latest version
Updated documentation
What's Changed
Full Changelog: v0.0.47...v0.0.48
Contributors
Assets 19
v0.0.47
v0.0.47
With this release, we are making some changes to resource deployment timings. Jamf Pro hosted in JamfCloud is load balanced with two web applications as standard and there is a resource propagation time of exactly 60s of any changes to all web applications.
This is important as it's possible for terraform to create a resource successfully, but when it comes to stating the resource it has a 50 / 50 chance that it might reach a web app that hasn't been propagated to yet. This can lead to a resource being created but not stated correctly and leads to orphaned resource scenario's.
To resolve this, I have implemented two approaches that work together based on preference, but first some context. Terraform by default creates a http client for a terraform plan operation and a separate http client for terraform apply. The terraform apply http client once initialised is used for all operations for a given run. This is useful as it means we can implement support for sticky sessions.
Therefore:
Change # 1 - Support has been added for sticky sessions within the http client used by this terraform provider.
Change # 2 - Enforce a 60 second propagation delay for resource creation tf operations when sticky sessions are disabled
This setting can be enabled / disabled like this:
enable_cookie_jar = true // or false
Behaviour Description [False] When disabled, the http client doesn't use sticky sessions and will honor the 60s propagation time of jamf pro in jamf cloud contexts to ensure successful TF resource stating. This results in a given resource creation task taking circa 1 minute to deploy across the board. This approach keeps the load on jamf pro light and when deploying during business hours, this may be the preferred configuration to ensure that jamf pro api resources are available for various device management activities outside of terraform. The down side of this however is that will take longer for a terraform apply to complete which is pertinent during pipeline runs.
Behaviour Description [True] When enabled, the http client uses sticky sessions and will target all operations to a single jamf pro web app. This negates Jamf Pro's load balancing and results in increased load on the targeted web app. However it provides the benefit that resources can be deployed and stated faster. This is due to the assurance that the web app api that was targeted for resource creation, will always be the same as the web app api used for TF resource stating. The propagation time in this scenario is set to 5 rather than 60 seconds.
Special note: Terraform parallelism
By default terraform runs 10 operations in parallel. During load testing I have observed that when terraform performs operations above 1 against jamf pro it frequently results in unreliable resource deployment behavior. E.g resources deployed with partial configuration or stating failure. Consequently I advise when possible to run terraform with the following
terraform apply -parallelism=1
From load testing with 500 resource creations, across 10 different resource types. When the cookie jar is enabled I was able to deploy successfully and state all resources.
If you are unable to control the parallelism of terraform when proceed cautiously when creating resources in batches.
What's Changed
- Update resource timeouts for all jamf pro resources by @ShocOne in #163
- Added support for sticky sessions when running TF plan and applies by @ShocOne in #164
- Docs update by @ShocOne in #165
Full Changelog: v0.0.45...v0.0.47
Contributors
Assets 19
v0.0.45
v0.0.45
What's Changed
- adds a "more than" smart group criterion search type by @w0de in #154
- Adds 'member of' search types to user groups & remove erroneous extension attribute data_type validation by @w0de in #157
- Updated dependancies for jamf api sdk by @ShocOne in #158
- Rebasing dev branch from main by @ShocOne in #159
- Added support for LDAP / iDP Server to account groups by @ShocOne in #160
New Contributors
Full Changelog: v0.0.44...v0.0.45