4.12.0 AppUserBaseSchemaProperty adds new attributes permissions, union and userType

[notdodo]

Describe what happened

Hi,

the update from 4.11.0 to 4.12.0 shows changes to add new attributes on AppUserBaseSchemaProperty resource.

but import those resources will fail since the resource doesn't match.
I've already created an issue on Okta TF provider: okta/terraform-provider-okta#2102

Sample program

#772 (comment)

Log output

No response

Affected Resource(s)

No response

Output of pulumi about

CLI
Version      3.142.0
Go Version   go1.23.3
Go Compiler  gc

Plugins
KIND      NAME    VERSION
resource  okta    4.12.0
language  python  3.142.0

Host
OS       darwin
Version  15.1.1
Arch     arm64

This project is written in python: executable='/Users/notdodo/Desktop/okta_poc/pulumi/.venv/bin/python' version='3.13.0'

Current Stack: organization/poc/dev

Found no resources associated with dev

Found no pending operations associated with dev

Backend
Name           notdodo
URL            file://.
User           notdodo
Organizations
Token type     personal

Dependencies:
NAME         VERSION
pip          24.2
pulumi_okta  4.12.0

Pulumi locates its logs in /var/folders/jm/htlczymd62x5_cqcq4vb3sy00000gn/T/ by default

Additional context

No response

Contributing

Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

[VenelinMartinov]

Hey @notdodo, thanks for reporting the issue and sorry you've hit this.

I can see the upstream issue is closed as "working as intended", which is unfortunate.

Can you please add a bit more detail about:

1. What exactly fails here?
2. How does this work in TF?

[notdodo]

Hei @VenelinMartinov

yeah sure; I was in a rush hoping that someone already looked at it.
I'll try to create a small POC

[notdodo]

Here it is.
It's the same behavior shown on the TF provider issue.

First test:

import pulumi_okta as okta

import pulumi

okta.AppUserSchemaProperty(
    "example",
    app_id="<id>",
    index="EmployeeInfoSubcompany",
    title="EmployeeInfoSubcompany",
    external_name="EmployeeInfoSubcompany",
    type="string",
    description="string",
    master="PROFILE_MASTER",
    scope="NONE",
    opts=pulumi.ResourceOptions(import_="<id>/EmployeeInfoSubcompany"),
)

during pulumi up I get:

Previewing update (dev):
     Type                                 Name     Plan       Info
 +   pulumi:pulumi:Stack                  poc-dev  create
 =   └─ okta:index:AppUserSchemaProperty  example  import     [diff: +permissions,union,userType]; 1 warning

Diagnostics:
  okta:index:AppUserSchemaProperty (example):
    warning: inputs to import do not match the existing resource: [permissions union userType]; importing this resource will fail

Resources:
    + 1 to create
    = 1 to import
    2 changes

Do you want to perform this update? details
+ pulumi:pulumi:Stack: (create)
    [urn=urn:pulumi:dev::poc::pulumi:pulumi:Stack::poc-dev]
    = okta:index/appUserSchemaProperty:AppUserSchemaProperty: (import)
        [id=<id>/EmployeeInfoSubcompany]
        [urn=urn:pulumi:dev::poc::okta:index/appUserSchemaProperty:AppUserSchemaProperty::example]
        [provider=urn:pulumi:dev::poc::pulumi:providers:okta::default_4_12_0::04da6b54-80e4-46f7-96ec-b56ff0331ba9]
      + permissions: "READ_ONLY"
      + union      : false
      + userType   : "default"

the import will fail due to permissions, union and userType.

Second try adding those attributes to the code:

import pulumi_okta as okta

import pulumi

okta.AppUserSchemaProperty(
    "example",
    app_id="<id>",
    index="EmployeeInfoSubcompany",
    title="EmployeeInfoSubcompany",
    external_name="EmployeeInfoSubcompany",
    type="string",
    description="string",
    master="PROFILE_MASTER",
    scope="NONE",
    permissions="READ_ONLY",
    union=False,
    user_type="default",
    opts=pulumi.ResourceOptions(import_="<id>/EmployeeInfoSubcompany"),
)

Same outcome:

Previewing update (dev):
     Type                                 Name     Plan       Info
 +   pulumi:pulumi:Stack                  poc-dev  create
 =   └─ okta:index:AppUserSchemaProperty  example  import     [diff: +permissions,union,userType]; 1 warning

Diagnostics:
  okta:index:AppUserSchemaProperty (example):
    warning: inputs to import do not match the existing resource: [permissions union userType]; importing this resource will fail

Resources:
    + 1 to create
    = 1 to import
    2 changes

Do you want to perform this update? details
+ pulumi:pulumi:Stack: (create)
    [urn=urn:pulumi:dev::poc::pulumi:pulumi:Stack::poc-dev]
    = okta:index/appUserSchemaProperty:AppUserSchemaProperty: (import)
        [id=<id>/EmployeeInfoSubcompany]
        [urn=urn:pulumi:dev::poc::okta:index/appUserSchemaProperty:AppUserSchemaProperty::example]
        [provider=urn:pulumi:dev::poc::pulumi:providers:okta::default_4_12_0::04da6b54-80e4-46f7-96ec-b56ff0331ba9]
      + permissions: "READ_ONLY"
      + union      : false
      + userType   : "default"

even if the attributes are defined on the code the import see drifts.

[VenelinMartinov]

@notdodo I see that you are using the import resource option. Is there a reason not to use pulumi import for this? Does that help unblock you here?

[notdodo]

@notdodo I see that you are using the import resource option. Is there a reason not to use pulumi import for this? Does that help unblock you here?

unfortunately it doesn't (it works tho) since we'd like to only use pipelines for IaC and not manual interaction with the state which is a bad practice.

[VenelinMartinov]

I see, good to hear that pulumi import works. You have correctly identified that the terraform provider is not quite doing the right thing here.

Unfortunately, we do currently give users the tools to work around the issue on our side either. I think the best you can do is manually import the resource to work around the limitation.

Some of the issues connected to this. Feel free to upvote:

pulumi/pulumi-terraform-bridge#2272 - this is about giving bridged providers the ability to work around this problem.
pulumi/pulumi#16397 - adding some ability in the pulumi engine to ignore these warnings