authlete / terraform-provider-authlete

This is a terraform provider for managing Authlete configuration
https://www.authlete.com/
Mozilla Public License 2.0
5 stars 4 forks source link

avoid updating standard scopes #164

Closed YoloZoloo closed 6 days ago

YoloZoloo commented 2 weeks ago

closes #163

dcreado commented 1 week 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.

YoloZoloo commented 1 week ago

@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.

  1. We can force the developers to write the standard scopes in an exact way that conforms to the Authlete's behavior.
  2. Or suppress the non-empty plan.
dcreado commented 1 week ago

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.

dcreado commented 1 week ago

@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.

YoloZoloo commented 1 week ago

@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.

dcreado commented 1 week ago

@YoloZoloo I've pushed a skeleton for 3rd option.

YoloZoloo commented 6 days ago

@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?