:shipit:🚀 Okta Terraform Provider Roadmap 🚀:shipit:

[monde]

Last updated: 2022-05-25

We will be keeping the community up to date with our development roadmap for the Okta Terraform Provider in this sticky issue.

Our priorities can be broken down into three categories

• New features
• Performance Improvements
• Bug fixes

New features

The Terraform team at Okta is actively adding more API coverage to the Okta Terraform Provider. We will continue to add new data sources and resources and we’ll announce them as our plans become more concrete.

Performance improvements

We are aware of a number of performance issues dealing with Okta API’s rate limits and how some of the provider’s data sources and resources are too greedy in their implementation. We are working to improve the Okta Terraform Provider itself in this regard. We also have teams working on this holistically including those working on Okta’s service stack, Okta's public API, and Okta's Developer Experience.

Bug fixes

Over the last twelve months we have had a big push to support Okta’s new Identity Engine in addition to Okta Classic. There has been a small bit of drift in how okta-sdk-golang has supported the API as well as it adding additional models and methods. These items and other priorities needing attention have let our bug count creep a little higher than we would like. We aim to continue to address issues in the Okta Terraform Provider by incorporating bug fixing into our internal backlog so they can be managed in our team’s sprint planning.

We are committed to improving and maturing this provider that has brought so much value to our customers by including a mix of new features, performance enhancements and bug fixes in our upcoming releases. As always, please continue to log issues and remember to upvote existing issues that are relevant to your use of the Okta Terraform Provider.

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 5 days

[antonmos]

Could you please share an update on fixing the rate limit issues?

[monde]

@antonmos can you describe what rate limit issues you are having and with which data source or resource? We've made a number of optimizations since May. Knowing your specific use case can reveal if the issue out of the provider's control in which case you'll need to open a support ticket to ask for rate limit exceptions on your org.

[antonmos]

I am seeing issue similar to https://github.com/okta/terraform-provider-okta/issues/1008

• getting rate limit warning for /api/v1/apps* and seeing /api/v1/apps/<id>/users?limit=200 in uri in the Okta log debug data.
• we have 49 okta_app_oauth resources and a handful of others
• we have only 2 users in "people", 1 group. Neither user is assigned to any of the okta_app_oauth or the group.

[dkulchinsky]

I am seeing issue similar to #1008

• getting rate limit warning for /api/v1/apps* and seeing /api/v1/apps/<id>/users?limit=200 in uri in the Okta log debug data.
• we have 49 okta_app_oauth resources and a handful of others
• we have only 2 users in "people", 1 group. Neither user is assigned to any of the okta_app_oauth or the group.

@antonmos have you tried setting skip_users and skip_groups to true? this helped us to some degree.

[antonmos]

adding skip_groups to our 49 okta_app_oauth resources seems to have done the trick! Thank you very much for the suggestion!

[antonmos]

Unfortunately, it seems that when I tested it (twice!) on Friday, I got lucky (i am guessing the requests got split between two rate limit intervals). So, the warning is happening again because my terraform plan generates 97 requests to /api/v1/apps*

[antonmos]

Okta support pointed me to https://registry.terraform.io/providers/oktadeveloper/okta/latest/docs#max_api_capacity and it seems to have worked!

[dkulchinsky]

@antonmos setting max_api_capacity to 100 didn't help in our case, however the following change had a huge impact:

okta_user data sources, add:

skip_groups = true
skip_roles  = true

the above may not be suitable for all use cases (i.e. if you need the groups & roles as part of the data source query), but in our case it was not needed and it reduced to plan time from ~14 minutes to ~6 minutes.

@monde it still feels like some of the other resources are potentially being too aggressive with API calls and we constantly hit the rate limits, wondering if there's any additional tuning or optimization we an consider to reduce the impact and decrease the run time.