terraform-provider-okta: Receiving a Status: 410 Gone Error for resource: "okta_email_sender" when enabling multibranding in Okta

It was a joke. It was not meant to be offensive nor directed toward you personally.

But since we’re on the topic, I am not offended by Okta or it’s staff although I would say that my company has every right to be offended.

We pay your company a lot of money to provide services and a portion of those services have been rendered useless for over three months by a breaking change introduced by Okta apparently because your API folks and Terraform folks aren’t communicating. Then to make matters worse, the fix offered up for the breaking change was designed with a new dependency, clearly untested, and documented poorly. And now you’re asking paying customers to troubleshoot whether or not it’s Okta’s Terraform or Okta’s API that isn’t working properly.

Okta’s mistakes have caused my company to burn through a minimum of 20 hours worth of labor for troubleshooting, finding work-arounds, and manually performing steps that were automatic CI/CD operations three months ago. And it’s not just my company that has been feeling this pain for the past three months, it’s every company that had the misfortune of using the okta_email_sender resource. I can’t imagine the total number of dollars and hours this breaking change has cost Okta’s customers but I’m certain it would be eye-popping.

I don’t know what person, group, process, procedure, or technology at Okta is to blame but the fact remains that a service which we all pay for is not available because of something that went wrong at Okta. At this point I’m done troubleshooting.

And although my description of the issue is accurate, I apologize for using words you find offensive. Again, it was not directed at you personally or any individual. It was referring to the situation and the interdependent layers of technology that have collectively failed.

Please let me and the rest of Okta’s customer’s know when the fix will be ready. Thank you for attending to this long outstanding issue. Clint Robinson

We are one more company waiting on this fix. Thanks for your hard work.

@ClintonianSunBlaster / all, @duytiennguyen-okta is finishing up a work around that will hopefully go out within the week. Definitely not on the back burner.

This feature appears to be broken due to using an undocumented API /api/v1/org/email/sender. (openapi docs https://github.com/okta/okta-sdk-golang/blob/v2.18.0/.generator/okta-management-APIs-oasv3-noEnums-inheritance.yaml ). This API had a breaking change causing this resource to break as described above.

I’m guessing the current api is the following: https://github.com/okta/okta-sdk-golang/blob/v3.0.2/okta/api_email_domain.go . Or you can look for the /api/v1/email-domains in the opanapi documentation https://github.com/okta/okta-sdk-golang/blob/v3.0.2/okta/api/openapi.yaml

I’m going to likely just delete this resource from terraform state to get my pipelines working. Hopefully there is an update to allow us to manage these in terraform again going forward.

@duytiennguyen-okta and @monde,

Sorry to pile on here but…

There appears to be another issue with the new okta_email_domain resource and it’s requirement for a brand_id.

okta_email_domain requires a “brand_id” but it appears the only way to retrieve a list of brand_ids is to use the okta_brand data resource which outputs a list of brands based on the okta_brands data resource output (see https://registry.terraform.io/providers/okta/okta/latest/docs/data-sources/brand). This creates a problem because okta_brand doesn’t have a reference attribute called “name” so there is no way to retrieve the brand id of a specific custom brand. Instead, you can only reference “tolist(data.okta_brands.test.brands)[x].id” which retrieves a brand id from a list based on a list index. It appears that index 0 always gets the brand id of the default brand which happens to be the first brand on the list. But, if you have multiple custom brands and would like the brand id of a specific one, it’s guesswork as to which index to use. And worse yet, if you’re managing multiple brands across multiple environments, then it’s entirely possible indexes could different between environments.

I think a fix would be to update the okta_brand data resource to include a returned attribute called “name” then I/us/we could use a locals that searches the list of brands returned from okta_brand for a brand which matches a specific name to get its specific brand_id? Once we have the correct brand_id we can then use it in the new okta_email_domain resource.

Thanks again, Clint

@duytiennguyen-okta and @monde,

This issue is “technically” fixed but the fix caused new issues as the new okta_email_domain resource appears to be misconfigured. Specifically, the dns_validation_records attribute contains a sub-attribute called “values” which is is incorrectly documented as “value” at https://registry.terraform.io/providers/okta/okta/latest/docs/resources/email_domain and the “values” attribute contains no data.

This creates an issue as we can no longer setup the associated DNS records with TF and thus the new okta_email_domain_validation resource always fails.

Please investigate and fix as soon as possible. Thanks!

Here is an example. Notice “values” and it’s empty values…

okta_email_domain = {
  "brand_id" = "bnd7h60x12vaCa1xxxx7"
  "display_name" = "NoReply"
  "dns_validation_records" = tolist([
    {
      "expiration" = ""
      "fqdn" = "_oktaverification.auth-test.****.com"
      "record_type" = "TXT"
      "values" = tolist([])
    },
    {
      "expiration" = ""
      "fqdn" = "mail.auth-test.****.com"
      "record_type" = "cname"
      "values" = tolist([])
    },
    {
      "expiration" = ""
      "fqdn" = "p06._domainkey.auth-test.****.com"
      "record_type" = "cname"
      "values" = tolist([])
    },
    {
      "expiration" = ""
      "fqdn" = "p36._domainkey.auth-test.****.com"
      "record_type" = "cname"
      "values" = tolist([])
    },
  ])
  "domain" = "auth-test.****.com"
  "id" = "OeD8mxsffffoooU41d7"
  "user_name" = "noreply"
  "validation_status" = "NOT_STARTED"
}

@monde,

This continues to be an issue. When will this be fixed?

It’s now been 80 days since Okta introduced this breaking change.

We were informed by Okta Support on on June 8th that the okta_email_sender api has been deprecated and replaced by the email_domain api (https://developer.okta.com/docs/api/openapi/okta-management/management/tag/EmailDomain/).

When will the okta_email-sender tf resource be updated to use the new API?

Thanks, Clint

@monde I’m happy to help debug if useful. But I’m hitting the same issue, this is the one for me: https://github.com/okta/terraform-provider-okta/blob/b4ad5a959aa1d5a81aa358f78beaa0edf783155c/sdk/email_sender.go#L72

/api/v1/org/email/sender/<whatever> seems to be deprecated

EDIT: Ok after reading a few more of this thread, I realize now that the other method was (silently?) deprecated and I’m supposed to use okta_domain_sender I’d add a note on the terraform documentation if possible.

@monde or @duytiennguyen-okta, can you bring @ClintonianSunBlaster feedback to the attention of Jeff Taylor and/or Nick Gamb. It is valid feedback since our team also lost time working around this issue, and it is best to have visibility, other than twittering to https://twitter.com/toddmckinnon. 🙃

Oh, I would also consider re-opening this issue @monde, IMO. 😸