You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment
Preamble
There is an existing issue for this that was a victim of the old stalebot - #1195
I decided to create this issue rather than commenting on the now closed issue as a comment on the now closed issue relies on people not missing the Github Notification for the comment
Prior Context
Provisioning applications can mutate their base or custom schema when provisioning is enabled for the first time
This leads to a few problems for the provider (more details in #1805):
Duplicate config may or may not produce a duplicate result
difficulty in accounting for this non-determinism in Multiple workspace deployment pipelines
Current Behaviour
Currently to work around the state of an application's schema being unknowable I must use terraform.workspace or okta_app_saml.features to infer the state of schrodinger's app schema in bodgy workarounds
Importing the attributes is a non-starter because while this will work for the application at hand.
If a colleague ever duplicates your configuration to create another app instance, their deployment will fail due to the attempted modification of the application base schema
Proposed Solution
To work around this behaviour of OIN applications, the provider should include a DataSource that facilitates checking the application schema during a Terraform plan or Terraform apply
@exitcode0 so this is related to the OIN app? Similar to #1805? Or you just want to expose the schema through datasource? I am a bit confused?
@duytiennguyen-okta It is related, but I guess this is for a slightly different ask
If I can't create the application in its final state, it would be good to be able to determine if the application is in the pre or post schema mutation
Community Note
Preamble
There is an existing issue for this that was a victim of the old stalebot - #1195
I decided to create this issue rather than commenting on the now closed issue as a comment on the now closed issue relies on people not missing the Github Notification for the comment
Prior Context
Provisioning applications can mutate their base or custom schema when provisioning is enabled for the first time
This leads to a few problems for the provider (more details in #1805):
Current Behaviour
Currently to work around the state of an application's schema being unknowable I must use
terraform.workspace
orokta_app_saml.features
to infer the state of schrodinger's app schema in bodgy workaroundsCurrent Workarounds
Click to expand
Alternative solutions
Importing the Attributes
Importing the attributes is a non-starter because while this will work for the application at hand.
If a colleague ever duplicates your configuration to create another app instance, their deployment will fail due to the attempted modification of the application base schema
Proposed Solution
To work around this behaviour of OIN applications, the provider should include a DataSource that facilitates checking the application schema during a
Terraform plan
orTerraform apply
New or Affected Resource(s)
okta_app_user_base_schema
okta_app_user_custom_schema
okta_app_user_schema
Potential Terraform Configuration
Click to expand
References
The text was updated successfully, but these errors were encountered: