Closed YoloZoloo closed 6 days ago
let me comment here for visibility. I think that requiring every services managed by the terraform provider to include that list of standard scopes is not reasonable. The full list of supported scopes should be as the service console, where it is up to the customer to decide without any constraint it. The not empty change list seems to be a different problem and marking the tests to ignore, will not fix issue.
@dcreado, all valid points. If you have a good alternative solution, we can implement your idea.
As mentioned in https://github.com/authlete/terraform-provider-authlete/issues/163, terraform apply
yields a non-empty plan because the Authlete server treats the standard scopes slightly differently than the custom scopes.
If we put openid
or email
in the scope's name field, the Authlete server will enable those scopes. The main culprit is what Authlete responds to the get-service requests. The get-service response includes the standard scopes, which have the predefined value in the description, attributes, and default_entry, along with everything that is related to that standard scope. The terraform plan will not be empty if this predefined value doesn't match what the terraform configuration defines.
I think the problem is that we are replacing the supported scope array of the schema.ResourceData when syncing the server -> local definition.... as the object is a different one, terraform will report that the plan is not empty.
@YoloZoloo I've changed the implementation and noticed a quiet odd behavior of API server... When creating the service, the API auto populate the descriptions and description attributes of the "standard" supported scopes.
Marking the "description" as computed fix the problem for that attribute, but for the "descriptions" there will not work.
I think there are some options:
The second one seems to me the best, as we force the supported_scope to match the definition of terraform resource.
@dcreado Yes. The behavior you described is what I tried to circumvent in this PR. As we both agree that the Authlete API treats standard scopes differently than other scopes.
As for the mentioned solutions, I would opt for the third one. The second approach seems a bit intrusive to Authlete code base. Let's first decide on which approach is the most suitable, then work it from there.
@YoloZoloo I've pushed a skeleton for 3rd option.
@dcreado Thanks for the skeleton. I made a few changes based on your code and pushed the new code. Can you review it and share your opinion?
closes #163