Adding Azure Oracle Autonomous Database resources

[BigGold1310]

Description of your changes

This PR adds the Azure Oracle Autonomous Database resources:

• azurerm_oracle_autonomous_database
• azurerm_oracle_autonomous_database_backup
• azurerm_oracle_autonomous_database_clone_from_backup
• azurerm_oracle_autonomous_database_clone_from_database

Fixes #1177

I have:

• Read and followed Crossplane's contribution process.
• Run make reviewable to ensure this PR is ready for review.

How has this code been tested

[jonasz-lasut]

I've added few comments for namespaced examples, the same should be done for cluster examples

[jonasz-lasut]

/test-examples="examples/oracle/namespaced/v1beta1/autonomousdatabasebackup.yaml"

[jonasz-lasut]

/test-examples="examples/oracle/namespaced/v1beta1/autonomousdatabasebackup.yaml"

[jonasz-lasut]

/test-examples="examples/oracle/namespaced/v1beta1/autonomousdatabasebackup.yaml"

[jonasz-lasut]

/test-examples="examples/oracle/namespaced/v1beta1/autonomousdatabasebackup.yaml

[erhancagirici]

just fyi, cluster-scoped examples had secretRef without namespace and network.azure/Subnet examples were using v1beta1 but were using embedded objects, not conforming schema.

Added d9b4dc2 to address those

[jonasz-lasut]

really appreciate it @erhancagirici
I was running tests for @BigGold1310 as they don't have the capability to locally run E2E tests, still need to do a review

[jonasz-lasut]

@erhancagirici 'Oracle.Database' namespace is not registered in the test Azure subscription, could you enable it when you have some time?

[plk]

I can perhaps run the tests locally if required - we really need this. I think you might need an OCI subscription linked to your Azure subscription too for this to work, testwise. I have that available if I can work out how to run the tests for this.

[plk]

I also noticed that in the main DB params, AdminPasswordSecretRef is not "omitempty" in init or standard params so it's not clear how one would set an initial password and then ignore it thereafter - wouldn't this param be required even if set in init?

[jonasz-lasut]

Thank you @plk for you proactive approach. You can run the E2E tests against your subscription by following this guide: https://github.com/crossplane/upjet/blob/main/docs/adding-new-resource.md#automated-tests---uptest

On the second topic - that's a known Upjet behavior, secretReferences are always required - crossplane/upjet#456

[jonasz-lasut]

If OCI subscription link is required for the tests to pass then I think we need to mark the resources as manual tests required @erhancagirici the E2E tests subscription is linked

[plk]

On the second topic - that's a known Upjet behavior, secretReferences are always required - crossplane/upjet#456

But does that mean it we set it in initparams, you also have to set it in params, thus defeating the purpose of initparams?

[jonasz-lasut]

Correct, you need to set it in both init and forProvider

[erhancagirici]

/test-examples="examples/oracle/namespaced/v1beta1/autonomousdatabasebackup.yaml"

[plk]

It's going to be very difficult apparently to set up Uptest in our environment - is there a way we can get/generate the xpgs for this PR and I can test a few things that way? The latest test error looks like it's related to not being able to deploy the DBs likely due to no OCI subscription?

[jonasz-lasut]

It is this error that is suggesting issues with OCI subscription? I've not used the autonomous databases on Azure

        async create failed: failed to create the resource: [{0 creating Autonomous Database (Subscription: "2895a7df-ae9f-41b8-9e78-3ce4926df838"
        Resource Group Name: "example"
        Autonomous Database Name: "example"): performing CreateOrUpdate: unexpected status 400 (400 Bad Request) with error: ResourceCreationValidateFailed: The resource validation failed. creating Autonomous Database (Subscription: "2895a7df-ae9f-41b8-9e78-3ce4926df838"
        Resource Group Name: "example"
        Autonomous Database Name: "example"): performing CreateOrUpdate: unexpected status 400 (400 Bad Request) with error: ResourceCreationValidateFailed: The resource validation failed. []}]

To build and publish the package to OCI registry you can run this:

make SUBPACKAGES="oracle" XPKG_REG_ORGS="my-oci-registry/repo" CONFIG_DEPENDENCY_REG_ORG="<registry-of-provider-family>" BRANCH_NAME="main" VERSION=<version-of-the-family-provider-that-you-run-in-cluster> build.all

make SUBPACKAGES="oracle" XPKG_REG_ORGS="my-oci-registry/repo" CONFIG_DEPENDENCY_REG_ORG="<registry-of-provider-family>" BRANCH_NAME="main" VERSION=<version-of-the-family-provider-that-you-run-in-cluster> publish

For "registry-of-provider-family" use for example xpkg.crossplane.io/crossplane-contrib

The image wil be available under my-oci-registry/repo/provider-azure-oracle:<version>

[plk]

I would bet that the 400 is caused by the OCI<->Azure connection not being present. Let me see if I can do some sort of test with an xpkg etc.

[plk]

After a lot of building, dies near the end with:

=> ERROR [2/2] RUN apk --no-cache add ca-certificates bash                0.7s
------                                                                          
 > [2/2] RUN apk --no-cache add ca-certificates bash:
0.294 exec /bin/sh: exec format error
------
Dockerfile:2
--------------------
   1 |     FROM alpine:3.23.3
   2 | >>> RUN apk --no-cache add ca-certificates bash
   3 |     
   4 |     ARG TARGETOS

Building on ubuntu, do I have to build on Alpine?

[jonasz-lasut]

Your host can be any operating system, I'm building it locally on Fedora 43 and MacOS depends on which laptop I have to use. Do you run docker behind a corporate proxy?

[plk]

Solved - had to restrict the PLATFORMS to stop it trying to build arm64.

[plk]

Problem seems to be in the dependency on the config/family provider - I am trying to use the already deployed v2.5.0 family provider - is there a way to remove this explicit dependency when creating the xpkg?

[jonasz-lasut]

If you were able to build it then you can deploy the pkg with spec.skipDependencyResolution: true

[jonasz-lasut]

But you should also be able to set the family dependency via CONFIG_DEPENDENCY_REG_ORG="" during build/publish steps

[erhancagirici]

If you were able to build it then you can deploy the pkg with spec.skipDependencyResolution: true
@plk in addition to above, you'll need the family package to come from the same registry. If not, sub-provider won't have the proper RBAC for common types. If not, you might want to build the family provider as well and push it to the same repo

SUBPACKAGES="config" or together SUBPACKAGES="config,oracle"

[plk]

I thought I was skipping dependencies but I wasn't ... now it works and I have deployed an Oracle ADB with the new provider. A bit more testing but looks good so far.

[plk]

Looks good - I have successfully deployed an Oracle ADB using the PR provider code. Do you need me to somehow attach proof?

[jonasz-lasut]

For resources that we can not test due to some limitations we require two things:

1. An annotation on affected resources that documents the reason for manual tests - in this case lack of oracle subscription configured. Here's an example: https://github.com/crossplane-contrib/provider-upjet-azure/blob/main/examples%2Fdbformysql%2Fnamespaced%2Fv1beta1%2Fflexibleserver.yaml#L10
2. Manual testing process followed with attached screenshots as we not only need to test creation but also imports and deletion, here's the guide: https://github.com/crossplane/upjet/blob/main/docs%2Fadding-new-resource.md#L352 (Manual Test)

[jonasz-lasut]

Really appreciate all the effort that you are putting into this feature @plk and @BigGold1310 !

[plk]

But if we manage to get the Uptest automated tests running here (I assume they are e2e and actually deploy things ...), then that would cover it?

[jonasz-lasut]

Yes, uptest would cover it

[plk]

It's a little tricky for uptest in our setup but I'm wondering if we can just splice out some of the uptest commands and run the tests against an existing cluster that has the provider already installed ...

[jonasz-lasut]

I think it would be easier to just run the tests manually then.

Just apply all resources added in this PR at once to the cluster, we don't need to run 4 separate runs as a lot of resources are common across the example/ files. Wait for creation, run the Import test and later delete. It'll most likely require less work than trying to make uptest work (speaking from experience as my company uses a proxy that makes it near impossible to properly run uptest)

[plk]

Same issue - proxies, firewalls, rootless podman etc. etc. Many thanks for the continuing swift responses - will look at the manual method.