TF errors after upgrading provider to 1.45.0

[Ihor]

We are getting the following errors while running terraform plan after upgrarding the tf provider to the latest version 1.45.0

Error: Conflicting configuration arguments

with module.email_routes.genesyscloud_routing_email_route.email_routes["xxx"]

on email_routes/email_routes.tf line 78, in resource "genesyscloud_routing_email_route" "email_routes":

resource "genesyscloud_routing_email_route" "email_routes" {

"reply_email_address": conflicts with from_email

Here is a terraform config we use no changes were done to it. It was working in the previous provider version(1.30.2) that we used:

resource "genesyscloud_routing_email_route" "reply_email_env" {
domain_id = var.EMAIL_XXX_COM_DOMAIN_ID
spam_flow_id = var.architectFlows.spam_email_routing_flow.id
flow_id = var.architectFlows.email_routing_flow.id
pattern = "reply"
from_name = "yyyy"
from_email = var.FROM_EMAIL

}

locals {
mailboxes = {
"xxx" = { email_id = "xxx", from_name = "yyyy", pattern = "qqqqq", from_email = "qqq" }
.....
}
}

resource "genesyscloud_routing_email_route" "email_routes" {
for_each = local.mailboxes

domain_id = var.EMAIL_XXX_COM_DOMAIN_ID
spam_flow_id = var.architectFlows.spam_email_routing_flow.id
flow_id = var.architectFlows.email_routing_flow.id
from_name = each.value.from_name
pattern = each.value.pattern
from_email = var.FROM_EMAIL

reply_email_address {
domain_id = var.EMAIL_XXX_COM_DOMAIN_ID
route_id = genesyscloud_routing_email_route.reply_email_env.id
}

}

[charlie.conneely]

Hi @Ihor

A few months ago we specified that those fields conflict with each other to reflect some rules defined by the API. However, I just tested it out myself and the API did not complain when I provided both from_email and reply_email_address, so we are going to remove this constraint.

Thanks for reporting!

-Charlie

(Tracking with DEVTOOLING-803)

[charlie.conneely]

Update: This has been fixed. Our next release (v1.46.0) is scheduled for next Tuesday the 27th. After upgrading to that version, your issue will be resolved. Thanks again for reporting!

[Ihor]

Hi @charlie.conneely
I've upgraded to 1.46.0 version and now the terraform plans runs for ~an hour and eventually fails with no errors.

[John_Carnell]

@charlie.conneely

DEVTOOLING-80

Hi Ihor,

Sorry. Charlie was on PTO last week, so a direct reference to him was not going to help . Do you have the TF_LOG=debug set? Even if the plan is running, there should be output that you can capture. I have never seen a Terraform plan fail without some output.

So everyone is gone for the weekend but will be around on Sunday night so as soon as you can give us some more details, I will ensure someone gets engaged. Please send @PremkumarNarayanasam any screenshots or logs you can give us and I will get someone from my team assigned to it.

Thanks,
John Carnell
Director, Developer Engagement

[John_Carnell]

Hi @Ihor

I went through the logs you sent Prem Kumar and it looks it gets through the plan successfully but then dies when it hits the Sentinel step. Did you guys just recently introduce Sentinel to your environment? Could you disable it and see if you are able to successfully deploy. The reason I am curious here is that:

At the end of the log we see:

0 to add, 4454 to change, 21 to destroy.

Which would indicate that the plan successfully completed. We do see some deprecation warnings. However, we immediately see:

Organization policy check:

An error occurred: unexpected EOF

If I look at the screen shot you sent it is Sentinel that is failed. If you can not get additional logs around Sentinel I would open a ticket with Hashicorp to find out how to get that information. Otherwise, we are flying blind and we can provide further guidance because we don't use Sentinel and we don't test with Sentinel.

Thanks,
John Carnell
Director, Developer Engagement

[Ihor]

Hi John!

I've just tried to update the tf provider to 1.48.0 version.
The terraform plan was running for more than 1 hour and eventually failed. Sentinel policy check didn't even started. I'll share terraform plan log with you.
I am wondering why the terraform plan starts running so long after the provider's upgrade?
Also I am seeing a lot of warnings like below:

Warning: Argument is deprecated

with module.queues.genesyscloud_routing_queue.QUEUE_Q

on queues/V1_QUEUES_Part_6.tf line 1873, in resource "genesyscloud_routing_queue" "QUEUE_Q":

resource "genesyscloud_routing_queue" "QUEUE_Q" {

outbound_email_address is deprecated in genesyscloud_routing_queue. OEA is now a standalone resource, please set ENABLE_STANDALONE_EMAIL_ADDRESS in your environment variables to enable and use genesyscloud_routing_queue_outbound_email_address.

How can i use genesyscloud_routing_queue_outbound_email_address resource if it requires to specify queue_id but there are many queues configured with the same outbound_email_address. How can i configure genesyscloud_routing_queue_outbound_email_address for many queues?

[John_Carnell]

Hi Ihor,

Please send me the logs. I will talk to my team today and see if we can set up a call. We might need to to reproduce your environment locally as you are the only one reporting these issues.

Thanks,
John Carnell
Director, Developer Engagement

[Hemanth]

Hi Ihor

While we wait for your logs and further information on the main problem with terraform plan

wanted to answer the other query you had on genesyscloud_routing_queue_outbound_email_address .

You can ENABLE_STANDALONE_EMAIL_ADDRESS to true and if you have many queues that have to be configured with the same outbound_email_address

You can then create mutiple genesyscloud_routing_queue_outbound_email_address resources with different resource names eg: queue.Name + "-email-address" and tie the relevant queue.id to the queue_id attribute of outbound_email_address resource

resource "genesyscloud_routing_queue_outbound_email_address" "queue1--email-address" {
queue_id = genesyscloud_routing_queue.queue1.id
domain_id = genesyscloud_routing_email_domain.main.id
route_id = genesyscloud_routing_email_route.support.id
}

resource "genesyscloud_routing_queue_outbound_email_address" "queue2-email-address" {
queue_id = genesyscloud_routing_queue.queue2.id
domain_id = genesyscloud_routing_email_domain.main.id
route_id = genesyscloud_routing_email_route.support.id
}

Thanks.

[charlie.conneely]

Hi @Ihor

We noticed in the provided logs that a data source lookup seems to be hanging.

{"@level":"info","@message":"module.skillgroups.data.genesyscloud_auth_division.home: Still refreshing... [1h12m50s elapsed]"

Could you try using the data source genesyscloud_auth_division_home (here's a link to the docs for this data source) instead of genesyscloud_auth_division? (I assume you're looking up the home division based on the fact that the ID of the data source is "home")

genesyscloud_auth_division will gather all the divisions in an org whose name partially match the value passed to the data source, and then loop through all of these to find an exact match, whereas genesyscloud_auth_division_home makes a single API call to GET /api/v2/authorization/divisions/home to instantly retrieve details of the home division.

Let me know if you can make this change and if it fixes your issue, and in the meantime, we will continue searching for the root cause.

Thanks
-Charlie