fixed #1031 adds provision on demand

[iwarapter]

Hey @manicminer,

I have tested this with an AWS SSO configured app and it worked well, however I don't have access to an Azure tenant I can test the providers functional tests on. Not sure how best to proceed atm.

Terraform will perform the following actions:

  # azuread_synchronization_job_provision_on_demand.example will be created
  + resource "azuread_synchronization_job_provision_on_demand" "example" {
      + id                   = (known after apply)
      + job_id               = "aWSSingleSignon.hidden"
      + service_principal_id = "hidden"

      + parameters {
          + rule_id = "hidden"

          + subjects {
              + object_id        = "hidden"
              + object_type_name = "Group"
            }
        }
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

azuread_synchronization_job_provision_on_demand.example: Creating...
azuread_synchronization_job_provision_on_demand.example: Creation complete after 4s [id=d66c068e-2711-409e-068d-8b55b8bb852e]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

Contains existing PR changes for reference only, will rebase once they are merged.

[manicminer]

@iwarapter Thanks for working on this. If you aren't able to run acceptance tests that's no problem, we can run them in our testing tenant. I'm happy to make small fixes to the tests as needed and I can report test results back to you for potentially larger fixes.

On the whole this is looking good. We will need to rewrite the doc as the format/style produced by tfplugindocs unfortunately is different to the provider docs - I recommend copying an existing doc and changing it as needed. Additionally if you can look at the comments below, and finish up the Read, Update and Delete funcs, then I'll be happy to take another look. Thanks!

[iwarapter]

hey @manicminer, thanks for the feedback. I have addressed all the parts you raised. For the acceptance test i'd need to know what the rule_id are available in the databricks schema in order for it to run. We could also do with a data source for this, but didnt see it in the graph api lib - https://learn.microsoft.com/en-us/graph/api/synchronization-synchronizationschema-get?view=graph-rest-beta&tabs=http

[iwarapter]

@manicminer is there anything further I can do to help with this?

[manicminer]

@iwarapter Thanks, and apologies for the delayed reply. At this time I don't have the bandwidth to create tests for this, so if you could have a go at writing some acceptance tests that will help enormously. I don't mind kicking the tires and tweaking existing tests to get them working reliably, but this will be waiting a little while if I have to write the tests. Thanks!

[iwarapter]

hey @manicminer i had a quick stab - iwarapter@9da78c0 there are a few //TODO which i need extra info for

[iwarapter]

@manicminer have pushed the tests - from what i can see the databricks integration used for acctests isnt fully integrated so this can't be tested e2e with it (im just testing config and then the expected failure). is there another app the acctests can use to test full e2e provisioning?

[Dave-Snigier]

FWIW, this ID is the same in my tenant

[manicminer]

@iwarapter Apologies for the delay in re-reviewing this. I was originally anticipating the resource would have Read and Delete functions, but on closer inspection of the API and provisioning process, I see that there is no way to track a single "provision".

This makes it impossible to track state in Terraform for this operation, as this is more of a fire and forget task than a resource having some sort of lifecycle. With that in mind, I'm unsure whether this would be a good fit for Terraform unless we can find some other way to track state here? Alternatively, if the primary use case is to provision users, this could possibly make sense as an optional block in the azuread_user resource instead? That way, we'd have some tangible state to track after the sync job has been triggered. WDYT?

[iwarapter]

Hi @manicminer, thanks for getting back to this. Thats correct, but there is prior art for this style of resource - mainly the aws lambda invocation resource.

The only way you could check if the resource has been provisioned currently is by calling the provision api and checking the response code - but this is definitely not what we want in the READ part 😄. I certainly wouldn't bundle this into any other resources as the closest one is the azuread_synchronization_job.

I disagree that it's not a good fit for terraform as it enables a key part of fully managing resources across azuread and a given service provider. Here's a quick example use case:

Add a group to a azure application (all covered with this provider)
GAP
Assign a SCIM managed group to a given permission set within AWS (all covered with the AWS provider)

This resource solves the gap between the two where the group won't exist in AWS as you at the mercy of the SCIM scheduler. I deploy many hundreds of groups/role bindings and this is quite painful.

[manicminer]

@iwarapter Thanks for the context, I see now that the sync can happen in either direction and the resulting object(s) are not likely to be directly managed anyway. In which case this seems like a reasonable way to implement this. Do you think it's worth adding a triggers faux-meta argument (which is conventionally a map) to enable programmatic reprovisioning?

[iwarapter]

its not a bad shout, i cant think of any (personal) use cases for it. But simple enough to just add a map trigger

[iwarapter]

I'll try add this tomorrow morning

[iwarapter]

@manicminer lifted straight from the aws provider 😂

[manicminer]

@iwarapter Thanks, I pushed some minor style fixes and also a crash fix in expandSynchronizationJobApplicationParameters(). LGTM! 👍

[iwarapter]

cool glad to see this getting merged :)

[manicminer]

Test result