Error with updating netskope_privateapps resource

[epalchan]

When making modifications to ONLY the host list of a netskope_privateapps resource the plan shows the expected change to the resource, but when applying an error comes up Error: app_name is not allowed to be modified..

The state then gets uploaded and future plans on the resource do not show the expected change. When checking in the actual tenant, the updated hosts list is not reflected either. Running a refresh of terraform state also doesn't reflect the drift when running a plan against the module.

Note- no change at all was made or shown to the app_name value, and the resource contains a for_each to create multiple private app configurations based on a passed in variable.

[iain-madder-frontiers]

Having the same issue and seems to be a double hitter.
The name error seems to be related to the private apps app_name getting wrapped in [ ] (you can confirm this via the /api/v2/steering/apps/private/api)
Adding [] to the private app app_name generation DOES NOT fix this. it just creates a private app with the name [[example_name]] and the error persists on all future changes

The state error is likely related to this separate issue I logged a while ago. I suspect there's a bigger issue with how state changes are handled

post edit: I've logged a support ticket with netskope to escalate this issue as it's a blocker for our workflows

[bcui-ns]

The logic in backend works like this:

1. For any existed private app, check if incoming app_name value is same to existed one. If not, it returns the above error. if the app_value doesn't follow the format as [xxx], it will add [] around the value.

To debug it, please create a ticket with mp, tenant id, and request payload so that backend engineers can pinpoint the root cause.

[iain-madder-frontiers]

Hey @bcui-ns , Thanks for the quick follow up. I can confirm I've logged a ticket in the support portal. fyi I do not believe that logic is working as you've described.
I already tested adding [] to my terraform logic and the PA that got created was shown as [[]] within the portal

# module.netskope_privateapps["PA-iain.test.host.net-default"].netskope_privateapps.privateapp will be created
  + resource "netskope_privateapps" "privateapp" {
      + app_name                = "[PA-iain.test.host.net-default-80_443]"
      + clientless_access       = false
      + host                    = "iain.test.host.net"
      + id                      = (known after apply)
      + trust_self_signed_certs = false
      + use_publisher_dns       = false

      + protocols {
          + port = "80, 443"
          + type = "TCP"
        }

      + publisher {
          + publisher_id   = "92"
          + publisher_name = "example_values"
        }

      + tags {
          + tag_name = "default"
        }
    }

Portal:

swagger:

{
  "data": {
    "allow_unauthenticated_cors": false,
    "app_id": 5648,
    "app_name": "[[PA-iain.test.host.net-default-80_443]]",
    "clientless_access": null,
    "host": "iain.test.host.net",
    "id": 5648,
    "is_user_portal_app": false,
    "modified_by": "apigw",
    "modify_time": "2024-03-08 16:31:47",
    "name": "[[PA-iain.test.host.net-default-80_443]]",
  }
}

[bcui-ns]

Hi @iain-madder-frontiers, can you give me your mp, tenant id so that i can take a look?

[iain-madder-frontiers]

Hey @bcui-ns , tenant id is frontiers-media. Not sure what you mean with "mp" ?

[jgournet]

Hey @bcui-ns and @iain-madder-frontiers , Just checking if you you managed to do any progress on this ? Thanks for you help !

[iain-madder-frontiers]

Hey @jgournet , Our ticket was escalated this morning. I'll update this ticket with any relevant information as it comes~

[iain-madder-frontiers]

@jgournet ,

Netskope have confirmed an issue their side and that a fix will be coming with netskope update 114 (my guess is in roughly a month). I'm asking for further elaboration of the application of this fix and the timeframe

[jgournet]

Thank you ! (as part of another ticket of ours, they said "R114, planned for May" - for what it's worth :) )

[nikskiz]

Is there a work around for this? Currently blocking our project and releasing a bunch of apps.

[nikskiz]

I have managed to get a workaround, which does require using terragrunt due to a specific feature that allows to re-try on error.

What I have noticed is on a re-try for error app_name is not allowed to be modified the resource will pass, however, it does not apply the intended changes. This is because the changes are applied in the statefile when it errors, so terraform thinks it has been applied on the second run and passes.

My work around is to invoke the API to make the changes instead:

1. in your terragrunt.hcl file add

   retryable_errors = [
   "app_name is not allowed to be modified"
   ]

2. In module add a shell script to make the intended changes calling the API (I only care about host updates).

   
   terraform {
   required_providers {
   shell = {
     source  = "scottwinkler/shell"
     version = "~> 1.7.0"
   }
   }
   }

resource "shell_script" "manage_app_hosts" { for_each = { for k, v in var.private_apps : k => v } lifecycle_commands { create = file("${path.module}/scripts/create-app-hosts.sh") delete = file("${path.module}/scripts/delete.sh") }

triggers = { hosts = netskope_privateapps.main[each.key].host }

environment = { hosts = netskope_privateapps.main[each.key].host appId = netskope_privateapps.main[each.key].id }

sensitive_environment = { apiKey = var.netskope_api_token } }

3. In module create script `scripts/create-app-hosts.sh` with the following content. replace `<TENANT>` with your tenant
```bash
#!/bin/bash

# Exit if any of the intermediate steps fail
set -e

# appId, hosts, apiKey are all set in the environment by the terraform shell resource

curl -X 'PATCH' \
  "https://<TENANT>.goskope.com/api/v2/steering/apps/private/${appId}" \
  -H 'accept: application/json' \
  -H 'Content-Type: application/json' \
  -H "Netskope-Api-Token: $apiKey" \
  -d "{
  \"id\": $appId,
  \"host\": \"${hosts}\"
}"

4. In module create script scripts/delete.sh with the following content (unfortunately the shell resources requires to have a delete script).

   
   #!/bin/bash

Exit if any of the intermediate steps fail

set -e

echo "do nothing"

[iain-madder-frontiers]

Hey @nikskiz / @jgournet / @epalchan

Looks like this issue has been fixed as of NPA 114 (released today I believe) without requiring any terraform provider updates.

Just tested adding and editing a new private_app and editing an existing private_app via a mix of adding/removing hosts, adding removing tags. All combinations worked.

It'd be good to get a second confirmation if you have the time

[jgournet]

Still getting "Error: app_name is not allowed to be modified" ... but our 114 update is scheduled for tomorrow, so that would explain it :)

[jgournet]

Finally, we got the update to 114 and it's working great now !!! I guess we can close this ticket

Thank you