Added RedisAccessPolicies and RedisAccessPolicyAssignment resources

[knutejoh]

Description of your changes

Fixes #700

I have:

• [X] Read and followed Crossplane's [contribution process].
• [X] Run make reviewable to ensure this PR is ready for review.
• [ ] Added backport release-x.y labels to auto-backport this PR if necessary.

How has this code been tested

Setup kind with the new resources make run Create the resources manualy Crossplane successfully created the resources in Azure, and status is good

knutejoh@:~/code/provider-upjet-azure$ kubectl get rediscacheaccesspolicyassignment.cache.azure.upbound.io/example NAME SYNCED READY EXTERNAL-NAME AGE example True True example 107s

knutejoh@:~/code/provider-upjet-azure$ kubectl get rediscacheaccesspolicy.cache.azure.upbound.io/examplepolicy NAME SYNCED READY EXTERNAL-NAME AGE examplepolicy True True examplepolicy 8m17s

[knutejoh]

/test-examples="examples/cache/v1beta1/rediscacheaccesspolicy.yaml"

[knutejoh]

/test-examples="examples/cache/v1beta1/rediscacheaccesspolicyassignment.yaml"

[knutejoh]

/test-examples="examples/cache/v1beta1/rediscacheaccesspolicyassignment.yaml"

[erhancagirici]

@knutejoh e2e tests is still in a update loop, however the problems related to external name seems to be resolved. This time, the diff is only on the permissions. The manifest specifies permissions: +@read +@connection +cluster|info but the current state at the azure API seems to be permissions: +@read +@connection +cluster|info allkeys. The update calls seem to be successful without errors, but seem to have no effect, as the next cycle detects the same diff. I don't know how this particular Azure API is working internally, but I suggest to check whether permissions have some kind of defaulting/mutation at the Azure API side, or some external entity managing it. There is either a race, or the updates are rejected/is no-op without an error. Also, maybe try to run the e2e's one by one, waiting for one to finish.

[knutejoh]

/test-examples="examples/cache/v1beta1/rediscacheaccesspolicyassignment.yaml"

[knutejoh]

/test-examples="examples/cache/v1beta1/rediscacheaccesspolicyassignment.yaml"

[knutejoh]

@erhancagirici I've updated the examples to match the automatically added "allkeys" value, but now it looks like the test either fails or times out when deleting the RedisCache. i see that the original RedisCache tests has the manual-intervention label on them, but it refers to an issue which I can't find anymore, upjet.upbound.io/manual-intervention: "https://github.com/upbound/official-providers/issues/625" Perhaps I should just add this to my tests as well?

[knutejoh]

/test-examples="examples/cache/v1beta1/rediscacheaccesspolicyassignment.yaml"

[knutejoh]

/test-examples="examples/cache/v1beta1/rediscacheaccesspolicyassignment.yaml"

[knutejoh]

Not sure how to proceed here. Any input @erhancagirici @ulucinar @sergenyalcin @turkenf ?

[erhancagirici]

@knutejoh seems like the e2e's are actually running fine. Creations succeed, and deletions are initiated correctly. However, I can see that the deletions for the Caches are stuck at the Azure side, all are in "Deleting" state in the console. Could not see any meaningful log or error message at the Azure. Could be a bug on azure side. I am not an Azure expert, so I am unable to debug further on Azure side.

@knutejoh Were you able to delete the RedisCaches too, when you were doing local testing? I wonder whether the "access policies" you introduced somehow prevent deletion?

[turkenf]

/test-examples="examples/cache/v1beta1/rediscacheaccesspolicy.yaml"

[turkenf]

/test-examples="examples/cache/v1beta1/rediscacheaccesspolicyassignment.yaml"

[turkenf]

/test-examples="examples/cache/v1beta1/rediscacheaccesspolicy.yaml"

[erhancagirici]

/test-examples="examples/cache/v1beta1/rediscacheaccesspolicyassignment.yaml"

[erhancagirici]

uptest run for RedisCacheAccessPolicyAssignment has also passed. @knutejoh thanks for the contribution!